From: Chirag Patel (chipatel@xxxxxxxxx)
Date: Thu May 04 2000 - 14:30:09 GMT-3
Just make sure you don't redistribute bri or dialer profile as connected
route, because when you have line up it has /32 route for this interface and
when demand circuit brings line down this route goes away and that changes
the ospf database and would bring up the line again to sync up the database
and this would happen repeatedly.
Chirag
CCIE# 5853
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Kinton Connelly
Sent: Thursday, May 04, 2000 12:52 PM
To: ccielab@groupstudy.com
Subject: Re: ccie bootcamp lab5b
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