From: Kinton Connelly (kinton@xxxxxxxxxxxx)
Date: Thu May 04 2000 - 17:41:56 GMT-3
Hi Lekan. Yes, using a stub area is one of the ways to make it stop. But
there was something else happening in lab8 for me - I was redistributing
connected interfaces and wasn't using a route-map to filter out the BRI
interface. Once I filtered out the BRI interface from being redistributed
as a connected interface, ospf demand-circuit worked like I expected.
Kinton
At 5/4/00, you wrote:
>Kinton,
>
>I had the same problem when I attempted CCIEbootcamp Lab5b. However when I
>attempted the advance OSPF lab on fatkid.com with te bri interfaces in the
>backbone area, I was able to keep the ISDN line quite.
>
>When I check the Cisco site, it says that the implementation consideration
>for ops f demand circuit is to make the bri interfeces to be in a stub
>area, that the LSAs don't get passed to area unnecessarily.
>
>Lekan
>
>
>
>>From: Kinton Connelly <kinton@oldmedia.com>
>>Reply-To: Kinton Connelly <kinton@oldmedia.com>
>>To: ccielab@groupstudy.com
>>Subject: Re: ccie bootcamp lab5b
>>Date: Thu, 04 May 2000 12:52:18 -0400
>>
>>Hi, Joe. I tested this out again this morning and you're right - it's
>>definitely redistribution that's causing the line to go up and down.
>>
>>But here's my problem - the only thing I'm redistributing is connected
>>routes (redistribute connected subnets metric-type 1 metric 100).
>>
>>Here's a sample debug of what's happening using "debug ip ospf lsa" and
>>"debug ip routing":
>>
>>(we start with the isdn interface just as it's going down)
>>
>>01:38:26: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 4671001
>>r5, ca
>>ll lasted 64 seconds
>>01:38:26: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
>>01:38:26: RT: del 137.20.224.5/32 via 0.0.0.0, connected metric [0/0]
>>01:38:26: RT: delete subnet route to 137.20.224.5/32
>>01:38:26: OSPF: Generate external LSA 137.20.224.5, mask 255.255.255.255,
>>type 5, age 3600, metric 16777215, seq 0x80000018
>>01:38:27: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
>>01:38:27: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 4671001
>>01:38:27: RT: add 137.20.224.5/32 via 0.0.0.0, connected metric [0/0]
>>01:38:32: OSPF: Generate external LSA 137.20.224.5, mask 255.255.255.255,
>>type 5, age 0, metric 100, seq 0x80000019
>>01:38:33: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 4671001 r5
>>
>>As you can see, the line goes down, the route is deleted, an LSA is
>>generated, the line is brought up, etc.
>>
>>Any ideas?
>>
>>Thanks,
>>
>>Kinton
>>
>>At 5/3/00, you wrote:
>>>I've always seen OSPF demand circuit function, but its easy to think its
>>>not. When doing redistribution, you must carefully prevent routes from OSPF
>>>from being leaked back into OSPF. When this leakage occurs, LSAs are
>>>generated causing the circuit to dial up. To test this, stop redistribution
>>>from the OTHER routing protocols into OSPF and see what happens.
>>>
>>>Hope it helps,
>>>
>>>JOE
>>>
>>>----- Original Message -----
>>>From: "Kinton Connelly" <kinton@oldmedia.com>
>>>To: "Fred" <fd200@bellatlantic.net>; <ccielab@groupstudy.com>
>>>Sent: Wednesday, May 03, 2000 7:56 PM
>>>Subject: Re: ccie bootcamp lab5b
>>>
>>>
>>> > Fred, I've had a lot of problems getting ospf demand-circuit to work
>>> > especially with CCIE Boot Camp's lab 8 with the way they have the ISDN
>>> > interfaces in area 0. Even when I set up my configs to match theirs, the
>>> > ISDN connection would never stay down.
>>> >
>>> > Here's what I saw with debugs: the ISDN connection (with demand-circuit)
>>> > would come up because of ip traffic to 224.0.0.5 (ospf). The connection
>>> > would time out at 120 seconds and the line would drop. But when the line
>>> > dropped, OSPF would generate an LSA (don't know what kind) and that LSA
>>> > would be flooded out the ISDN interface, bringing it up. This nasty
>>> circle
>>> > would go on and on.
>>> >
>>> > What I did to get it to work was put the ISDN interfaces in their own
>>> area
>>> > and make it a stub area. After that, demand-circuit worked as advertised.
>>> >
>>> > So maybe that's what they need to do - make sure the interfaces are in
>>> > their own stub areas.
>>> >
>>> > Maybe someone on the list can better explain the exact mechanics of ospf
>>> > demand-circuit - all I know is that without the stub area, the line goes
>>>up
>>> > and down forever - with the stub area, it works as advertised.
>>> >
>>> > Kinton
>>> >
>>> > At 5/3/00, you wrote:
>>> > >Guys,
>>> > >
>>> > >For those who did the cciebootcamp lab5b, regarding the DDR in a
>>> > >difference area other than the backbone. They claim they haven't figure
>>> > >out what was the problem with it, so I am just wonder if any of you
>>> > >figure that out already. Thanks
>>> > >
>>> > >Fred
>>> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:27 GMT-3