From: Logan, Harold (loganh@mccfl.edu)
Date: Mon Sep 16 2002 - 18:26:27 GMT-3
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
> > 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