From: Nick Shah (nshah@connect.com.au)
Date: Mon Sep 16 2002 - 18:31:38 GMT-3
Sean
I had labbed it up a while ago, and every time the second channel kicked in
(depending on load-threshold), we had a change in bandwidth, so 'nailing'
the bandwidth seemed a good idea (we can use b/w or cost to accomplish
this).
There was a long thread a while ago, check it out.
However, now that I see that you have done your tests, I would think that it
would more likely be an IOS issue.
rgds
Nick
----- Original Message -----
From: Sean <sean_ccie@yahoo.com.cn>
To: Nick Shah <nshah@connect.com.au>; Castelino, Flavian
<Flavian.Castelino@nexinnovations.com>; Frank Maisano <FrankM@netarch.com>;
Jim Brown <Jim.Brown@caselogic.com>; <ccielab@groupstudy.com>
Cc: <ccielab@groupstudy.com>
Sent: Tuesday, September 17, 2002 6:49 AM
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
> > > down
> > > Serial0.1 150.10.60.5 YES NVRAM administratively
> > down
> > > down
> > > Serial0.2 150.10.10.5 YES NVRAM administratively
> > down
> > > down
> > > Serial0.3 150.10.40.5 YES NVRAM administratively
> > down
> > > down
> > > Serial1 unassigned YES NVRAM administratively
> > down
> > > down
> > > Virtual-Access1 unassigned YES TFTP up
> > > up
> > >
> > >
> > > 08:46:34: IP: s=150.10.65.1 (local), d=224.0.0.5 (BRI0), len 64,
sending
> > > broad/multicast
> > > 08:46:34: IP: s=150.10.65.1 (local), d=224.0.0.5 (BRI0), len 64,
> > > encapsulation failed
> > > 08:46:35: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
> > > 08:46:35: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
up
> > > 08:46:35: is_up: 1 state: 4 sub state: 1 line: 0
> > > 08:46:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed
> > > state to up
> > > 08:46:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1,
> > > changed state to up
> > > 08:46:36: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
> > > 08:46:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2,
changed
> > > state to up
> > > 08:46:42: %ISDN-6-CONNECT: Interface BRI0:2 is now connected to
5552001 r6
> > >
> > > r5#sh ip ospf int bri0
> > > BRI0 is up, line protocol is up (spoofing)
> > > Internet Address 150.10.65.1/30, Area 5
> > > Process ID 64, Router ID 150.10.65.1, Network Type POINT_TO_POINT,
Cost:
> > > 1562
> > > Configured as demand circuit.
> > > Run as demand circuit.
> > > DoNotAge LSA allowed.
> > > Transmit Delay is 1 sec, State DOWN,
> > > Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
> > > Hello due in 00:00:26 (using PollInterval of 40)
> > > r5#
> _________________________________________________________
> Do You Yahoo!?
> PBOJ5=5W,Si@V5=<R - QE;"MF3vCb7QSi@V5gWSV\1(!
> http://cn.ent.yahoo.com/newsletter/index.html
This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:53 GMT-3