From: Nitro Drops (nitrodrops@hotmail.com)
Date: Sun Jan 11 2009 - 21:16:16 ARST
Hi All,
Thanks for all the kind replies. Arigato Gozaimashita!
Let me input a few more points.
I am using Dynamips (CPU 55%) for this test. Just want to ensure i know how to
fix recursive routing for the IGP, after watching COD, where Brian McCahan
fixed it on the RIP.
Configs is purely running OSPF, with the distribute-list, GRE tunnel.
This is what i noticed, i PURPOSELY created recursive routing using OSPF, by
advertising all interfaces (Connected, Tunnel, Loopback) in OSPF.
R1 F0/0 .1 >> 155.1.37.0 >> .2 F0/0 R2 F0/1 .2 >>
155.1.0.0 >> .3 F0/0 R3
R1
interface Tunnel0
ip address 155.1.57.1 255.255.255.0
tunnel source 155.1.37.1
tunnel destination 155.1.0.3
!
router ospf 1
network 155.1.0.0 0.0.255.255 area 0
distribute-list 2 in Tunnel0
!
access-list 2 deny 155.1.0.0 0.0.0.255
access-list 2 deny 155.1.37.0 0.0.0.255
access-list 2 permit any
R3
interface Tunnel0
ip address 155.1.57.3 255.255.255.0
tunnel source 155.1.0.3
tunnel destination 155.1.37.1
!
router ospf 1
network 155.1.0.0 0.0.255.255 area 0
distribute-list 2 in Tunnel0
!
access-list 2 deny 155.1.0.0 0.0.0.255
access-list 2 deny 155.1.37.0 0.0.0.255
access-list 2 permit any
Without using the distribute-list, i can see the 'recursive error' logs
generated.
Captured from R1
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
%OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from LOADING to FULL,
Loading Done
%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to
down
%OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from FULL to DOWN,
Neighbor Down: Interface down or detach
Qns : At this stage, if i do a 'sh ip route 155.1.0.3' on R1 or 'sh ip route
155.1.37.1' on R3, i should be able to
see the next hop as the tunnel interface or maybe loadbalance right? when the
tunnel0 changed state to up again? I have changed the IP OSPF cost on the
connected and Tun0 to be the same.
R1#sh ip ospf int br
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Tu0 1 0 155.1.57.1/24 60000 P2P 1/1
Lo0 1 0 155.1.1.1/24 60000 LOOP 0/0
Fa0/0 1 0 155.1.37.1/24 60000 BDR 1/1
R1#
However i cant see the next hop recurse to tunnel0 when the tunnel0 changed
state to up.
*Mar 1 10:02:46.885: %OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from
LOADING to FULL, Loading Done
sh ip route 155.1.37.1
Routing entry for 155.1.37.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1
Next, to prevent recursive routing, i apply the distribute-list inbound under
OSPF process, to prevent learning the 'Tunnel destination' from Tunnel0.
R1 & R3
access-list 2 deny 155.1.0.0 0.0.0.255
access-list 2 deny 155.1.37.0 0.0.0.255
access-list 2 permit any
router ospf
distribute-list 2 in Tunnel0
After applying, distribute-list, i DONT see 'recursive error' logs generating
anymore, however Tun0 keeps flapping up/down. THIS IS WHAT I ENCOUNTERED
DURING MY INITIAL TESTS. SO I ASSUME 'RECURSIVE ROUTING HAS
NOT BEEN FIXED'. But technically, it seems to be fixed already without seeing
the recursive error' logs.
Tun0 flaps pretty often and recovers pretty fast, cant be due to dynamic where
the CPU is seen at 55%.
R1(config-if)#do ping 155.1.57.3 rep 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 155.1.57.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
*Mar 1 10:15:21.709: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0,
changed state to down
*Mar 1 10:15:21.725: %OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from
FULL to DOWN, Neighbor Down: Interface down or detached.!!!!!
*Mar 1 10:15:24.709: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0,
changed state to up!!!!!!!
*Mar 1 10:15:25.841: %OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from
LOADING to FULL, Loading
Done!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
*Mar 1 10:15:39.709: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0,
changed state to down
*Mar 1 10:15:39.725: %OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from
FULL to DOWN, Neighbor Down: Interface down or detached...!
*Mar 1 10:15:45.709: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0,
changed state to up!!!!!
*Mar 1 10:15:46.953: %OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from
LOADING to FULL, Loading Done!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!.
*Mar 1 10:16:00.709: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0,
changed state to down
*Mar 1 10:16:00.725: %OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from
FULL to DOWN, Neighbor Down: Interface down or detached.!!!!!
*Mar 1 10:16:03.709: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0,
changed state to up
*Mar 1 10:16:04.693: %OSPF-5-ADJCHG: Process 1, Nbr 155.1.3.3 on Tunnel0 from
LOADING to FULL, Loading Done!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 97 percent (342/350), round-trip min/avg/max = 4/112/572 ms
QNS : What i noticed is, after i changed the 'ip ospf cost to 60000' on tun0
to loadbalance them, i dont encounter this tunnel flapping anymore. Is
changing the 'IP OSPF cost' part of the requirements to fix 'recursive
routings' in OSPF?
R1(config-if)#do sh ip ospf int br
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Tu0 1 0 155.1.57.1/24 6000 P2P 1/1
Lo0 1 0 155.1.1.1/24 6000 LOOP 0/0
Fa0/0 1 0 155.1.37.1/24 60000 BDR 1/1
R1(config-if)#do ping 155.1.57.3 rep 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 155.1.57.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
Success rate is 99 percent (201/202), round-trip min/avg/max = 28/93/260 ms
R1(config-if)#
Thanks for your time.
Cheers
Nit
From: smorris@internetworkexpert.com
To: madsen.jason@gmail.com
CC: nitrodrops@hotmail.com; ccielab@groupstudy.com
Subject: RE: Recursive Routing
Date: Sun, 11 Jan 2009 16:26:47 -0500
I just figured there was something not posted that was
important. :)
From: Jason Madsen
[mailto:madsen.jason@gmail.com]
Sent: Sunday, January 11, 2009 3:44 PM
To: Scott Morris
Cc: Nitro Drops; ccielab@groupstudy.com
Subject: Re: Recursive Routing
true nuf. it
appears he used area 0 ONLY however and used default GRE tunnel and OSPF
values
(ospf cost of 11111) so with his endpoint being only a couple of hops away,
he
never should've "preferred" the tunnel for his endpoints in the first
place with or without the distribute list. I'm willing to be he used
GNS3 and it's a gliche or something unless there's more to his config' that
he
didnt' post.
Jason
On Sun, Jan 11, 2009 at 12:42 PM, Scott Morris
<smorris@internetworkexpert.com>
wrote:
The rule is that whatever you are using for your destination
address needs
to NOT be preferred through the tunnel.
With that in mind, you look at how you learn the route originally:
1. If via a different protocol, then you can use things like
ACL/distribute-lists or even changing the AD (so I don't care if it's
learned, it won't get used by routing table)
2. If it's via the same protocol then you need to look differently.
Some
(RIP, EIGRP) it may simply involve changing the metric. Others (like
OSPF)
you have further analysis to look at about whether it's the SAME route you
are learning (instead of a /24 vs. /32 if loopback) as well as other fun
things like intra-area vs. inter-area vs. external route.
But once you understand how the router learned/chose the router ORIGINALLY
(pre-tunnel) and then understand what is changing the tunnel becomes up...
Compare the two and you should be good.
Cheers,
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nitro Drops
Sent: Sunday, January 11, 2009 8:27 AM
Subject: Recursive Routing
Hi All,
Have been trying to fix my recursive routing for OSPF in the last 2 hours.
R1 F0/0 .1 >> 155.1.37.0 >> .2 F0/0 R2 F0/1 .2 >>
155.1.0.0 >> .3 F0/0 R3
GRE tunnel created between R1 and R3
R1
interface Tunnel0
ip address 155.1.57.1 255.255.255.0
tunnel source 155.1.37.1
tunnel destination 155.1.0.3
router ospf 1
network 155.1.0.0 0.0.255.255 area 0
distribute-list 2 in Tunnel0
access-list 2 deny 155.1.0.0 0.0.0.255
access-list 2 deny 155.1.37.0 0.0.0.255
access-list 2 permit any
R3
interface Tunnel0
ip address 155.1.57.3 255.255.255.0
tunnel source 155.1.0.3
tunnel destination 155.1.37.1
router ospf 1
network 155.1.0.0 0.0.255.255 area 0
distribute-list 2 in Tunnel0
access-list 2 deny 155.1.0.0 0.0.0.255
access-list 2 deny 155.1.37.0 0.0.0.255
access-list 2 permit any
To prevent recursive routing, i have used a distribute-list to prevent
learning the tunnel destination from the tunnel interface. However, my int
tunnel keeps on flapping (Debug IP routing as attached), did i missed out
anything on my configs or did i use the wrong method? I used the same method
on RIP & EIGRP, distribute-list works fine on both of them, distribute-list
applying in/out to stop the tunnel destination from advertising/learning
from
the tunnel interface.
Except on OSPF, i can only prevent the router from learning from the tunnel
destination, CANT stop advertising the tunnel destination out of the tunnel
interface, as the OSPF distribute-list only works for inbound.
Cheers
Nit
IP routing debugging is on
R1#
*Mar 1 08:54:30.021: %OSPF-5-ADJCHG: Process 1, Nbr 15.2.2.2 on Tunnel0
from
LOADING to FULL, Loading Done
*Mar 1 08:54:41.541: RT: del 155.1.0.0/24
via 155.1.37.2, ospf metric
[110/120000]
*Mar 1 08:54:41.545: RT: delete subnet route to 155.1.0.0/24
*Mar 1 08:54:41.549: RT: NET-RED 155.1.0.0/24
*Mar 1 08:54:48.869: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Tunnel0,
changed state to down
*Mar 1 08:54:48.881: RT: is_up: Tunnel0 0 state: 4 sub state: 1 line: 0
has_route: True
*Mar 1 08:54:48.885: %OSPF-5-ADJCHG: Process 1, Nbr 15.2.2.2 on Tunnel0
from
FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 1 08:54:48.893: RT: interface Tunnel0 removed from routing table
*Mar 1 08:54:48.893: RT: del 155.1.57.0/24 via 0.0.0.0, connected metric
[0/0]
*Mar 1 08:54:48.897: RT: delete subnet route to 155.1.57.0/24
*Mar 1 08:54:48.901: RT: NET-RED 155.1.57.0/24
*Mar 1 08:54:51.553: RT: SET_LAST_RDB for 155.1.0.0/24
NEW rdb: via 155.1.37.2
*Mar 1 08:54:51.561: RT: add 155.1.0.0/24
via 155.1.37.2, ospf metric
[110/120000]
*Mar 1 08:54:51.561: RT: NET-RED 155.1.0.0/24
*Mar 1 08:54:57.869: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Tunnel0,
changed state to up
*Mar 1 08:54:57.881: RT: is_up: Tunnel0 1 state: 4 sub state: 1 line: 0
has_route: False
*Mar 1 08:54:57.885: RT: SET_LAST_RDB for 155.1.57.0/24
NEW rdb: is directly connected
*Mar 1 08:54:57.889: RT: add 155.1.57.0/24 via 0.0.0.0, connected metric
[0/0]
*Mar 1 08:54:57.893: RT: NET-RED 155.1.57.0/24
*Mar 1 08:54:57.897: RT: interface Tunnel0 added to routing table
*Mar 1 08:54:58.973: %OSPF-5-ADJCHG: Process 1, Nbr 15.2.2.2 on Tunnel0
from
LOADING to FULL, Loading Done
*Mar 1 08:55:11.577: RT: del 155.1.0.0/24
via 155.1.37.2, ospf metric
[110/120000]
*Mar 1 08:55:11.581: RT: delete subnet route to 155.1.0.0/24
*Mar 1 08:55:11.585: RT: NET-RED 155.1.0.0/24
R1#undebug
*Mar 1 08:55:17.901: %OSPF-5-ADJCHG: Process 1, Nbr 15.2.2.2 on Tunnel0
from
FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 1 08:55:18.869: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Tunnel0,
changed state to down
*Mar 1 08:55:18.877: RT: is_up: Tunnel0 0 state: 4 sub state: 1 line: 0
has_route: True
*Mar 1 08:55:18.881: RT: interface Tunnel0 removed from routing table
*Mar 1 08:55:18.885: RT: del 155.1.57.0/24 via 0.0.0.0, connected metric
[0/0]
*Mar 1 08:55:18.889: RT: delete subnet route to 155.1.57.0/24
*Mar 1 08:55:18.889: RT: NET-RED 155.1.57.0/24
R1#undebug al
*Mar 1 08:55:21.589: RT: SET_LAST_RDB for 155.1.0.0/24
NEW rdb: via 155.1.37.2
*Mar 1 08:55:21.597: RT: add 155.1.0.0/24
via 155.1.37.2, ospf metric
[110/120000]
*Mar 1 08:55:21.597: RT: NET-RED 155.1.0.0/24l
All possible debugging has been turned off
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:37 ARST