From: Sean (sean_ccie@yahoo.com.cn)
Date: Mon Sep 16 2002 - 22:58:35 GMT-3
Now I see something different.
I don't use Dialer Profile, I use legacy DDR (see my config sent to the group
a few minutes ago). Could it be necessary to fix the ospf cost when using
Dialer Profile with multilink ppp? I am not sure, I will try that. But it
seems, for legacy DDR, it is not.
Sean
--- "Logan, Harold" <loganh@mccfl.edu> 5DU}ND#:> Could this be an IOS issue? A
couple groupstudy members and I labbed
> something like this up about 6 months ago or so. I've seen OSPF cause an ISDN
> line to flap, but we were using PPP multilink on an interface that was a
> member of a dialer profile. The bandwidth of the dialer interface would
> change from 64 to 128 when the second B channel came up. It had a different
> bandwidth value when neither line was up... don't remember what it was, but
> it wasn't 0. Either way, the change in bandwidth (and ensuing change in OSPF
> cost) was causing the link to come back up because of the LSA's. This was on
> a 2621 and a 1720 running 12.1(5) if I remember correctly.
>
> hth,
> Hal
>
> -----Original Message-----
> From: Sean [mailto:sean_ccie@yahoo.com.cn]
> Sent: Mon 9/16/2002 4:49 PM
> To: Nick Shah; Castelino, Flavian; Frank Maisano; Jim Brown;
> ccielab@groupstudy.com
> Cc: ccielab@groupstudy.com
> Subject: Re: OSPF Demand-Circuit Oddity (How do I keep it quiet)
>
>
>
> Nick,
>
> I doubt about this. In my lab, I did not use "ip ospf cost #" to specify
> the cost under bri int, and I used ppp multilink. It keeps quiet w/o any
> problem. When I ping through the isdn bri, I can see both bri0:1 and bri0:2
> up, and yet the "show ip ospf int bri 0" still show the cost of 1564 (for
> single B channel of 64kbps).
>
> I don't think ppp multilink will change ospf cost over bri line since when
> multilink is enabled and up, a virtual-access interface is dynamically
> created
> to bundle the traffic, so the original bri cost is not touched.
>
> I suggest Jim do a "debug ip ospf monitor" to see whether there is any
> change
> LSA when the isdn line is in active.
>
> Thanks,
>
> Sean
>
>
>
>
> --- Nick Shah <nshah@connect.com.au> 5DU}ND#:> When using MLPP, a change in
> bandwidth (when 2 links come up) is considered
> > a change in OSPF cost of an interface, hence a change LSA is generated.
> What
> > you need to do in this case is to either nail the bandwidth as 128 or
> > explicitly specify a cost 9999 (for historic reasons, specify 9999, even
> > though in this case since there are no parallel paths you can specify
> actual
> > cost)
> >
> > Nick
> > ----- Original Message -----
> > From: "Castelino, Flavian" <Flavian.Castelino@nexinnovations.com>
> > To: "Frank Maisano" <FrankM@netarch.com>; "Jim Brown"
> > <Jim.Brown@caselogic.com>; <ccielab@groupstudy.com>
> > Sent: Thursday, September 05, 2002 3:31 AM
> > Subject: RE: OSPF Demand-Circuit Oddity (How do I keep it quiet)
> >
> >
> > > Try ospf cost <a high number for ex. 9999> on the BRI interface...
> > >
> > > Flavian
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Frank Maisano [mailto:FrankM@netarch.com]
> > > Sent: Wednesday, September 04, 2002 12:45 PM
> > > To: 'Jim Brown'; ccielab@groupstudy.com
> > > Subject: RE: OSPF Demand-Circuit Oddity (How do I keep it quiet)
> > >
> > >
> > > Do you have any other routing protocols being redistributed on either
> > > router?
> > >
> > > Did you try reseting the ospf process after applying the demand-circuit
> > > command?
> > >
> > > I have run into this problem and I do not recall exactly how I fixed it.
> > >
> > > Also see:
> > >
> > > http://www.cisco.com/warp/public/104/dcprob.html
> > >
> > > --Frank
> > >
> > > -----Original Message-----
> > > From: Jim Brown [mailto:Jim.Brown@caselogic.com]
> > > Sent: Wednesday, September 04, 2002 9:01 AM
> > > To: ccielab@groupstudy.com
> > > Subject: OSPF Demand-Circuit Oddity (How do I keep it quiet)
> > >
> > >
> > > Gang,
> > >
> > > I cannot make the demand circuit stay quiet!
> > >
> > > I'm probably a little clueless and probably cannot see the forest
> because
> > of
> > > the trees. I configured an ISDN connection between two routers, R5 and
> R6.
> > > It is configured so only R5 can call R6. There aren't any dialer map
> > > statements on R6 for it to call if it wanted too.
> > >
> > > Packets destined for the OSPF multicast address 224.0.0.5 continue to
> > bring
> > > the line up after I configure the interface as a demand circuit?
> > >
> > > I tried the usual, no peer neighbor route on the interface to eliminate
> > > feedback from an classfull protocol.
> > >
> > > I then thought I must be missing something somewhere an began to shut
> down
> > > the interfaces on R5 one by one to eliminate any feedback?
> > >
> > > After I shut down every interface except for the BRI, it sill won't stay
> > > quiet!
> > >
> > > What is the deal?
> > >
> > > I have attached all of the relevant information below. Any help or
> clarity
> > > is greatly appreciated. I'm stumped!!!!!
> > >
> > >
> > > IOS Version 12.1.1
> > >
> > > r5#show isdn act
> > >
> --------------------------------------------------------------------------
> > --
> > > ----
> > > ISDN ACTIVE CALLS
> > >
> --------------------------------------------------------------------------
> > --
> > > ----
> > > Call Calling Called Remote Seconds Seconds Seconds
> Charges
> > > Type Number Number Name Used Left Idle
> > > Units/Currency
> > >
> --------------------------------------------------------------------------
> > --
> > > ----
> > > Out 5552001 r6 89 0 0
> > > Out 5552001 r6 88 0 0
> > >
> --------------------------------------------------------------------------
> > --
> > > ----
> > >
> > > r5#show run interface bri0
> > > Building configuration...
> > >
> > > Current configuration:
> > > !
> > > interface BRI0
> > > ip address 150.10.65.1 255.255.255.252
> > > encapsulation ppp
> > > ip ospf demand-circuit
> > > dialer map ip 150.10.65.2 broadcast 5552001
> > > dialer load-threshold 1 outbound
> > > dialer-group 1
> > > isdn switch-type basic-dms100
> > > isdn spid1 30355530010101 5553001
> > > isdn spid2 30355530020101 5553002
> > > no peer neighbor-route
> > > ppp authentication chap callin
> > > ppp chap hostname cisco5
> > > ppp multilink
> > > end
> > >
> > > r5#show ip interface brief
> > > Interface IP-Address OK? Method Status
> > > Protocol
> > > BRI0 150.10.65.1 YES NVRAM up
> > > up
> > > BRI0:1 unassigned YES unset up
> > > up
> > > BRI0:2 unassigned YES unset up
> > > up
> > > Ethernet0 150.10.50.5 YES NVRAM administratively
> > down
> > > down
> > > Loopback0 150.10.5.5 YES NVRAM administratively
> > down
> > > down
> > > Loopback1 200.150.150.5 YES NVRAM administratively
> > down
> > > down
> > > Serial0 unassigned YES NVRAM administratively
> > down
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:54 GMT-3