From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Tue Jul 05 2005 - 16:58:19 GMT-3
Hmmm, I'm not convinced :)
I don't think it is reasonable to conclude that an LSA being sent is the
cause of the line being bright up if the LSA does not show up in the
debug. What does the output of debug dialer say when the linnk is going
up and down?
Chris
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Tuesday, July 05, 2005 2:29 PM
To: Chris Lewis (chrlewis); 'Schulz, Dave'; nobody@groupstudy.com;
'''Aleksander Klessa' ' '; ccielab@groupstudy.com
Subject: RE: ISDN ODC Area 0 - cant use "no peer neighobr-route"
Interesting that you aren't seeing the same results. I threw this up
really quickly here to make sure I wasn't going insane! (and drinking
caffeine as well to help brain flow!)
Very simple setup with two routers (my R6 and R8) running OSPF over the
BRI circuit. 10.1.1.0/30 is the network configured.
emanon-R8#sh ip o d
OSPF Router with ID (88.88.88.88) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link
count
66.66.66.66 66.66.66.66 10 0x80000003 0x00A253 1
88.88.88.88 88.88.88.88 2 0x80000002 0x00F30E 2
Notice that no entry for 10.1.1.0 network(s) show up here, even though
they run OSPF over it! It's a connected route here, but not showing up
as learned locally.
emanon-R8#sh cdp n
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port
ID
Emanon-R6 BRI1/0 156 R 3620
BRI0/0
emanon-R8#sh run int bri1/0
Building configuration...
Current configuration : 346 bytes
!
interface BRI1/0
ip address 10.1.1.1 255.255.255.252
encapsulation ppp
dialer map ip 10.1.1.2 name emanon-R6 broadcast 2756002 dialer map ip
10.1.1.2 name emanon-R6 broadcast 2756022 dialer-group 1 isdn
switch-type basic-ni isdn spid1 85927560030101 isdn spid2
85927560230101 isdn calling-number 275-6003 ppp authentication chap
end
emanon-R8#
Add another router out the Ethernet to expand areas (R5) :
emanon-R8#sh ip o d
OSPF Router with ID (88.88.88.88) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link
count
66.66.66.66 66.66.66.66 609 0x80000004 0x007BDB 2
88.88.88.88 88.88.88.88 168 0x80000004 0x00C796 3
172.17.155.5 172.17.155.5 168 0x80000002 0x00B891 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
113.13.13.5 172.17.155.5 169 0x80000001 0x00B1D9
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.17.155.0 172.17.155.5 230 0x80000001 0x00D074
emanon-R8#
Note: Still no listing of the 10.1.1.0/30 network, even though we know
it exists on this router.
On R5, it does show up:
Emanon-R5#sh ip o d
OSPF Router with ID (172.17.155.5) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link
count
66.66.66.66 66.66.66.66 660 0x80000004 0x007BDB 2
88.88.88.88 88.88.88.88 218 0x80000004 0x00C796 3
172.17.155.5 172.17.155.5 218 0x80000002 0x00B891 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
113.13.13.5 172.17.155.5 218 0x80000001 0x00B1D9
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.17.155.0 172.17.155.5 279 0x80000001 0x00D074
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link
count
172.17.155.5 172.17.155.5 278 0x80000002 0x00BA20 1
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.1.0 172.17.155.5 205 0x80000001 0x008328
113.13.13.0 172.17.155.5 210 0x80000003 0x000146
Emanon-R5#
Emanon-R5#sh ip ro os
10.0.0.0/30 is subnetted, 1 subnets
O 10.1.1.0 [110/1572] via 113.13.13.108, 00:03:44, Ethernet0/0
Emanon-R5#
So by the summary, it would make sense that this wouldn't occur since
only one summary and route is showing up there. The config here is
really simplistic!
No flapping at the moment though 'cause I'm keeping the line up all the
time. Let's add OSPF Demand Circuit.
emanon-R8#sh ip o i bri1/0
BRI1/0 is up, line protocol is up (spoofing)
Internet Address 10.1.1.1/30, Area 0
Process ID 1, Router ID 88.88.88.88, Network Type POINT_TO_POINT,
Cost:
1562
Configured as demand circuit.
Run as demand circuit.
DoNotAge LSA allowed.
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:07
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 66.66.66.66 (Hello suppressed)
Suppress hello for 1 neighbor(s)
emanon-R8#
emanon-R8#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
113.0.0.0/24 is subnetted, 1 subnets
C 113.13.13.0 is directly connected, Ethernet0/0
172.17.0.0/24 is subnetted, 1 subnets
O IA 172.17.155.0 [110/74] via 113.13.13.5, 00:00:54, Ethernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.1.2/32 is directly connected, BRI1/0
C 10.1.1.0/30 is directly connected, BRI1/0
emanon-R8#
But it goes up and down now. Nothing else has changed, no other
redistribution has been done.
As soon as EITHER "no peer neighbor-route" or "network 10.1.1.x 0.0.0.0
area 0" the flapping disappears. Interestingly enough, nothing shows up
with debugs for LSA generation. ;) Go figure.
2w3d: %ISDN-6-DISCONNECT: Interface BRI1/0:1 disconnected from 2756002
Emanon-R6, call lasted 124 seconds
2w3d: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to down
2w3d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/0:1, changed
state to down emanon-R8#
2w3d: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to up
2w3d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/0:1, changed
state to up
2w3d: %ISDN-6-CONNECT: Interface BRI1/0:1 is now connected to 2756002
Emanon-R6
emanon-R8#
emanon-R8#sh deb
IP routing:
OSPF summary lsa generation debugging is on
emanon-R8#
2w3d: %ISDN-6-DISCONNECT: Interface BRI1/0:1 disconnected from 2756002
Emanon-R6, call lasted 124 seconds
2w3d: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to down
2w3d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/0:1, changed
state to down emanon-R8#
2w3d: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to up
2w3d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/0:1, changed
state to up
2w3d: %ISDN-6-CONNECT: Interface BRI1/0:1 is now connected to 2756002
Emanon-R6
emanon-R8#
2w3d: %ISDN-6-DISCONNECT: Interface BRI1/0:1 disconnected from 2756002
Emanon-R6, call lasted 124 seconds
2w3d: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to down
2w3d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI1/0:1, changed
state to down
emanon-R8#sh ip ro c
113.0.0.0/24 is subnetted, 1 subnets
C 113.13.13.0 is directly connected, Ethernet0/0
10.0.0.0/30 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, BRI1/0
emanon-R8#
I'm not sure what else to add other than my experiences with it, and
just playing around with it. I'm running 12.2(15)T9 on 3620's with an
Enterprise load.
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chris Lewis (chrlewis)
Sent: Tuesday, July 05, 2005 12:45 PM
To: Scott Morris; Schulz, Dave; nobody@groupstudy.com; ''Aleksander
Klessa'
' ; ccielab@groupstudy.com
Subject: RE: ISDN ODC Area 0 - cant use "no peer neighobr-route"
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