RE: ip ospf deamd-circuit (CCBOOT 5b)

From: Joseph Ezerski (jezerski@xxxxxxxxxxxx)
Date: Tue Sep 04 2001 - 21:00:44 GMT-3


   
If you are doing LAB 5b here is what i found out.

The loop is happening at R5 and it is because of the IGRP/OSPF
Redistribution. If you look in your OSPF database (for r5) you see your
ISDN network (172.168.65.0) as a type 5 LSA. Type 5's are always external,
but yet this ISDN subnet is directly attached. Therein lies the problem.

So, to fix it, I added a route-map in r5.

access-list 1 permit 172.168.40.0 0.0.0.255

route-map igrp2ospf permit 10
 match ip address 1

router ospf 1
 area 10 virtual-link 172.168.31.33
 redistribute igrp 1 metric 20 metric-type 1 subnets route-map igrp2ospf
 network 137.20.20.2 0.0.0.0 area 0
 network 172.168.65.2 0.0.0.0 area 10
 network 172.168.100.5 0.0.0.0 area 10

What this is saying is..."only allow the one known subnet coming from r4 via
IGRP and do not listen to any routes I may already know about through my own
local routing protocol"

The screwed up part is that IGRP has a better administrative distance than
OSPF so its routes will be preferred.

Check your OSPF Database and the Type 5 entry for 172.168.65.0 should be
gone.

-Joe

PS- Thanks to Adam Brzyski for steering me right.

-----Original Message-----
From: David Siwula [mailto:DSiwula@ceira.com]
Sent: Tuesday, September 04, 2001 4:23 PM
To: Joseph Ezerski
Subject: RE: ip ospf deamd-circuit

What route maps were you using...
I could not get mine to work....
Would you mind sending me yours....
Dave

-----Original Message-----
From: Joseph Ezerski [mailto:jezerski@broadcom.com]
Sent: Tuesday, September 04, 2001 3:41 PM
To: 'BRZYSKI, ADAM E (SWBT)'; 'John Elias'; ccielab@groupstudy.com
Subject: RE: ip ospf deamd-circuit

Damn, I was seeing the same thing! I was doing Bootcamp lab 5 and I
also
filtered out 224.0.0.5 to stop the DDR link from coming up. However,
Adam's
explanation answers a lot of questions for me. Thanks!

-Joe

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
BRZYSKI, ADAM E (SWBT)
Sent: Tuesday, September 04, 2001 2:22 PM
To: John Elias; ccielab@groupstudy.com
Subject: RE: ip ospf deamd-circuit

What you area doing kind of works as you described below. However your
approach negates the purpose of a ip OSPF demand circuit. Note that the
demand circuit suppresses hellos and LSA as long as there are no
topology
changes. Once a change happens the change is send over the demand
circuit.
I am assuming that you are redistributing to a different routing
protocol
somewhere within your topology. If this is true what you are really
dealing
with is a routing loop. If you do show ip OSPF database you will
probably
see the ISDN IP network in the type-5 LSA table. What is happening is
that
you are redistributing to another routing protocol and that protocol is
in
turn redistributing the information back to OSPF. This is what causes
the
demand circuit to go up and down. Use a route map or a distribute list
to
filter the other routing protocol from advertising the ISDN IP network
back
to OSPF. Once you do that you'll notice that the ISDN will stay down.
The
best way to verify your filtering is to make sure that the ISDN IP
network
does not appear in the OPSF database under type-5 LSA's. Hope this
helps!

Adam Brzyski
Design Engineer II
CCIE #8082, NNCDE

-----Original Message-----
From: John Elias [mailto:jelias_@hotmail.com]
Sent: Tuesday, September 04, 2001 3:35 PM
To: ccielab@groupstudy.com
Subject: ip ospf deamd-circuit

Guys,
   I know this question was asked before, but I need a definit answer.
The
ip ospf demand-circuit command when running it over bri interfaces, does
not

work for me. It seems that I need to filter out ospf multicasts so that
the

line does not come up again. The only problem is that when the serial
goes
down, the bri interface does not come up. I have to ping the other side
to
get the bri interface to come up. Can someone please post a config that
might work.

John



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:14 GMT-3