From: Nick Shah (nshah@connect.com.au)
Date: Wed Sep 04 2002 - 20:35:41 GMT-3
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#
This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:44 GMT-3