From: Lekan Magbagbeola (lekkyl@xxxxxxxxxxx)
Date: Thu May 04 2000 - 17:36:06 GMT-3
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