From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Tue Jul 05 2005 - 13:44:46 GMT-3
Scott,
I agree with the points you make on filtering routes not helping, but I
am not seeing the behavior you describe regarding the network
configuration for OSPF in a lab. While the ISDN link is up, the /32
appears in the routing table as a connected route, but not in the OSPF
database. When the link goes down, the /32 disappears from the routing
table, but does not trigger a redial, as it was never part of the OSPF
database.
I have configured the following between R1 and R2:
R1
Dialer-list 1 protocol ip permit
!
interface BRI0/0
ip address 172.19.25.1 255.255.255.0
encapsulation ppp
ip ospf demand-circuit
dialer map ip 172.19.25.2 broadcast 8358662
dialer-group 1
isdn switch-type basic-ni
isdn spid1 0835866101 8358661
isdn spid2 0835866301 8358663
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 172.19.25.0 0.0.0.255 area 0
R2
Dialer-list 1 protocol ip permit
!
interface BRI0/0
ip address 172.19.25.2 255.255.255.0
encapsulation ppp
dialer map ip 172.19.25.1 broadcast 8358661
dialer-group 1
isdn switch-type basic-ni
isdn spid1 0835866201 8358662
isdn spid2 0835866401 8358664
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 172.19.25.0 0.0.0.255 area 0
This is how the OSPF database looks
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link
count
1.1.1.1 1.1.1.1 1023 0x80000002 0x002CF4 2
2.2.2.2 2.2.2.2 5 (DNA) 0x80000002 0x00CB50 2
The neighbors and interface state show the OSPF demand circuit is
functioning with a neighbor formed and the BRI odwn:
R1#sho ip ospf nei
Neighbor ID Pri State Dead Time Address
Interface
2.2.2.2 1 FULL/ - - 172.19.25.2 BRI0/0
R1#sho ip int brie
Interface IP-Address OK? Method Status
Protocol
FastEthernet0/0 30.13.10.1 YES manual up
up
Serial0/0 unassigned YES manual up
up
Serial0/0.123 30.13.0.1 YES manual up
up
BRI0/0 172.19.25.1 YES manual up
up
BRI0/0:1 unassigned YES unset down
down
So if I read your text correctly, I should see the /32 appear and
disappear in the OSPF database, causing the link to flap. Neither occurs
in my setup shown above. FWIW I looked at Aleksander's configs and it
looks to me that the cause of his link flapping is RIP being enabled on
one side of his ISDN link and its not related to the /32 peer route.
What is my lab missing to demonstarte the effect you describe?
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Monday, July 04, 2005 8:33 PM
To: 'Schulz, Dave'; nobody@groupstudy.com; '''Aleksander Klessa' ' ';
ccielab@groupstudy.com
Subject: RE: ISDN ODC Area 0 - cant use "no peer neighobr-route"
But filtering it from the routing table doesn't help you. it just makes
your routing table not care. The LSA will already be there. And that's
the trigger. You want to make the LSA not be generated.
Remember that LSAs are generated by things being placed into the OSPF
process. Things get placed into the OSPF process either through
redistribution (as Brian M. pointed out) or through the network command.
If your ISDN line is 100.100.100.0/30 as an example. You have .1 on one
side, and .2 on the other. If you can't turn off the peer neighbor
route, your routing table when the BRI line is up will contain two
CONNECTED
routes:
100.100.100.0/30 and 100.100.100.x/32 where x is the other side who
called you.
The problem with LSA generation comes in how you put your network
statement in OSPF. If you have configured "network 100.100.100.0
0.0.0.3 area 12" as an example. This is telling OSPF that any interface
with an IP address in that range is participating in OSPF and you will
generate an LSA for it.
When the BRI line is up, there are TWO "interfaces" that fall in that
range.
One /30 and one /32. If I generate an LSA for it, life is fine until
the line goes down. No virtual access interface, no /32 connected
route. LSA disappearing causes reason to dial under the demand-circuit
rules.
Call back, and magically that /32 comes back again. So the whole
process repeats itself every 2 minutes.
So it goes back to how you specify things. Remember that in your IGP's,
the network command doesn't directly cause a route to be advertised. It
causes an interface to participate in the routing protocol, and once
that occurs the actual net and mask is brought into the RIB. So, in
OSPF if you used "network 100.100.100.y 0.0.0.0 area 12" where y is your
own IP address, this would still cause the /30 LSA to be generated. but
when you had this additional /32 CONNECTED interface appearing, OSPF
would NOT be generating an LSA for it, so you would avoid the problem.
This is also why some people claim to never have to use the peer
neighbor route commands. If their habit is to use 0.0.0.0 masks, they
never create the problem to see it occur! ;)
If you are redistributing as Brian pointed out, you may have this issue
as well, but you'll have to look at your specifics and do a little more
tracing things down!
HTH,
Scott
_____
From: Schulz, Dave [mailto:DSchulz@dpsciences.com]
Sent: Monday, July 04, 2005 8:58 PM
To: Scott Morris ; nobody@groupstudy.com; ''Aleksander Klessa' ' ;
ccielab@groupstudy.com
Subject: RE: ISDN ODC Area 0 - cant use "no peer neighobr-route"
Scott,
I would say that is I use a distribute list, and apply it through a
distribute list (in), then the database would still be accordingly (to
OSPF), and, this route (the /32) should be filtered from the route
table.
Correct?
Dave
-----Original Message-----
From: Scott Morris
To: Schulz, Dave; nobody@groupstudy.com; ''Aleksander Klessa' ';
ccielab@groupstudy.com
Sent: 7/4/2005 2:48 PM
Subject: RE: ISDN ODC Area 0 - cant use "no peer neighobr-route"
How would you apply that? OSPF rules are that everyone in the area
needs to
have an identical database... So if I generate an LSA I have to tell
you
about it (causing the dial). You can filter if from appearing in your
routing table but must appear in the database.
You're on the right track since we're talking about the /32... But how
would I stop the route from being generated to begin with as an LSA?
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Schulz, Dave
Sent: Monday, July 04, 2005 2:03 PM
To: Scott Morris ; nobody@groupstudy.com; 'Aleksander Klessa' ;
ccielab@groupstudy.com
Subject: RE: ISDN ODC Area 0 - cant use "no peer neighobr-route"
Interesting question! I'll just throw this out as a
possibility....since we
are looking to stop anything with a /32 route (peer route), would it
make
sense to use a prefix list, and deny any routes in the dialer list with
a 32
bit mask?
Dave
-----Original Message-----
From: nobody@groupstudy.com
To: 'Aleksander Klessa'; ccielab@groupstudy.com
Sent: 7/4/2005 10:53 AM
Subject: RE: ISDN ODC Area 0 - cant use "no peer neighobr-route"
Since you're thinking about "no peer neighbor-route" you know what is
causing the flap. So think about the solution.
What causes the dial is an LSA change. What LSA is changing (be very
specific)???
Now, why would either router be generating the LSA in question? What
command causes a router to generate an LSA?
Now, think about making this command more specific so the LSA in
question
doesn't ever get generated.
POOF! No flapping.
;)
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Aleksander Klessa
Sent: Monday, July 04, 2005 4:41 AM
To: ccielab@groupstudy.com
Subject: ISDN ODC Area 0 - cant use "no peer neighobr-route"
hi GS,
i have an isdn connectivity between 2 routers. the isdn network is in
Area
0. i cant use "no peer neighbor-route" and should avoid continous link
flaps.
the problem is that both routers install the remote IP ADDR as a
connected
and with disconnect they remove that from routing table.
any idea???
olo
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:29 GMT-3