From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Sat Mar 08 2008 - 16:41:51 ARST
Very interesting Paul. So can we generalize the case? Something like:
"When redistributing any IGP into OSPF, and OSPF has multiple points of
redistribution with another IGP, manipulate distance to ensure a preference
for the "native" routes due to the potential for route feedback."
Or even:
"When redistributing any IGP into OSPF, and OSPF has three or more sum total
points of redistribution, manipulate distance to ensure a preference for the
"native" routes due to the potential for route feedback."
Something like that?
Thanks again Paul!
Cheers,
Scott
(Hehe, apologize in advance if any "extra config" threads spin off from
this...)
-----Original Message-----
From: Paul Cosgrove [mailto:paul.cosgrove@heanet.ie]
Sent: Saturday, March 08, 2008 9:12 AM
To: Scott Vermillion
Cc: 'Timothy Chin'; 'John'; 'Sadiq Yakasai'; 'Hash Aminu'; 'Carlos Alberto
Trujillo Jimenez'; ccielab@groupstudy.com
Subject: Re: redistribution
You can trigger the problem other ways, for instance in my lab setup
simply clearing OSPF on either R1 or R3 was enough to trigger the
problem. Again though, the issue does not occur every single time, I
presume because of differences sequences occuring during the neighbor
re-establishment process. You may not need multiple interfaces in OSPF,
and you will not if OSPF is only cleared; consequently R2 should be able
to trigger the issue as well.
If R3 was instead rebooted then I guess the same thing may occur,
although the timings will be different in the IE lab example as they are
using slower EIGRP links. If on reboot the EIGRP neighbor relationship
is formed first, then the 204.12.1.0/24 can still be redistributed into
OSPF and advertised back to R1 when the OSPF neighbor relationships are
established.
Paul.
Scott Vermillion wrote:
> Oh, those naughty, naughty little routers! Paul, this is way cool man.
> Thanks for taking the time to put this together in your lab and to post
all
> of these results. Very nice.
>
> One final question:
>
> Is there a chance of this happening if you simply reboot R3? Or must you
> follow this exact sequence to wind up with the looped topology?
>
> Cheers,
>
> Scott
>
> -----Original Message-----
> From: Paul Cosgrove [mailto:paul.cosgrove@heanet.ie]
> Sent: Thursday, March 06, 2008 6:13 PM
> To: Scott Vermillion
> Cc: 'Timothy Chin'; 'John'; 'Sadiq Yakasai'; 'Hash Aminu'; 'Carlos Alberto
> Trujillo Jimenez'; ccielab@groupstudy.com
> Subject: Re: redistribution
>
> Hi Scott,
>
> Thanks for your help with the additional information about the topology
> in this scenario. I setup a similar (smaller) scenario in my lab, using
> a loopback on my switch to originate 204.12.1.0/24 into RIP to R1. R1
> redistributes into a full mesh point-to-multipoint OSPF area containing
> R1, R2, R3 & R4. R2 and R3 share an ethernet interface running EIGRP.
> I've used the same OSPF config which was mentioned in the earlier emails.
>
> router eigrp 10
> redistribute ospf 1 metric 100000 10 255 1 1500
> network 132.1.23.0 0.0.0.255
> auto-summary
> !
> router ospf 1
> log-adjacency-changes
> redistribute eigrp 10 subnets
> network 132.1.0.0 0.0.0.255 area 0
> distance ospf external 171
> distance 110 0.0.0.0 255.255.255.255 EXT_OSPF
> !
> ip access-list standard EXT_OSPF
> permit 132.1.17.0
> permit 204.12.1.0
> !
>
> The distance ospf external 171 doesn't actually do anything in this case
> as the E2 routes from R1 are matched by the ACL. Left it there anyway
> for completeness.
>
> I've ran a few tests and found that the issue does occur, but it seems
> harder to reproduce on point-to-multipoint than with a point-to-point
> link on the router where I shutdown the link. The topology in NMC lab 1
> has a point-to-point interface which I was shutting down, and that
> reproduces the issue every time, point to multipoint seems to be much
> less reliable at breaking things (about 50/50). I guess this is because
> it comes down to a timing issue of who advertises to who first, but
> don't see a clear explaination in the RFC.
>
> I'm using the following method to try to trigger the routing loop:
> - shutdown the s0 interface on R3
> - clear ip ospf process on R3
> - no shut s0 again.
>
> To reset between attempts I was shutting down the ethernet interface I
> have EIGRP running on before repeating the same.
>
> In the topologies I've been using the loop is permanent, as once R1
> overrides its own OSPF E2 route with one learned from R3, it will not
> reinstall its own until the R3 is removed (e.g. by shutting down an
> interface).
>
> The following example may help to clarify what I've done:
>
> Paul.
>
> Router3(config-if)#do sh ip ro
> O E2 204.12.1.0/24 [110/20] via 132.1.0.1, 00:00:08, Serial0
> 132.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
> O 132.1.0.4/32 [110/128] via 132.1.0.1, 00:00:08, Serial0
> [110/128] via 132.1.0.2, 00:00:08, Serial0
> O 132.1.0.1/32 [110/64] via 132.1.0.1, 00:00:08, Serial0
> C 132.1.0.0/24 is directly connected, Serial0
> O 132.1.0.2/32 [110/64] via 132.1.0.2, 00:00:08, Serial0
> C 132.1.23.0/24 is directly connected, Ethernet1
> O E2 132.1.17.0/24 [110/20] via 132.1.0.1, 00:00:09, Serial0
> Router3(config-if)#int s0
> Router3(config-if)#shut
> Router3(config-if)#do c
> Mar 7 00:04:23.743: %OSPF-5-ADJCHG: Process 1, Nbr 132.1.23.4 on
> Serial0 from FULL to DOWN, Neighbor Down: Interface do
> wn or detached
> Mar 7 00:04:23.751: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.102.1 on
> Serial0 from FULL to DOWN, Neighbor Down: Interface
> down or detached
> Mar 7 00:04:23.755: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.101.1 on
> Serial0 from FULL to DOWN, Neighbor Down: Interface
> down or detachedlear ip o
> Mar 7 00:04:25.735: %LINK-5-CHANGED: Interface Serial0, changed state
> to administratively down
> Mar 7 00:04:26.735: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> Serial0, changed state to downspf process
> Reset ALL OSPF processes? [no]: y
> Router3(config-if)#do sh ip ospf da | b Type-5
> Type-5 AS External Link States
>
> Link ID ADV Router Age Seq# Checksum Tag
> 132.1.0.0 172.16.103.1 64 0x80000001 0x00B441 0
> 132.1.0.1 172.16.103.1 64 0x80000001 0x00AA4A 0
> 132.1.0.4 172.16.103.1 64 0x80000001 0x008C65 0
> 132.1.17.0 172.16.103.1 64 0x80000001 0x00F8EB 0
> 132.1.23.0 172.16.103.1 64 0x80000001 0x00B628 0
> 204.12.1.0 172.16.103.1 64 0x80000001 0x007928 0
> Router3(config-if)#no shut
> Router3(config-if)#
> Mar 7 00:05:44.815: %LINK-3-UPDOWN: Interface Serial0, changed state to
up
> Mar 7 00:05:45.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> Serial0, changed state to up
> Mar 7 00:06:10.231: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.102.1 on
> Serial0 from LOADING to FULL, Loading Done
> Mar 7 00:06:13.091: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.101.1 on
> Serial0 from LOADING to FULL, Loading Done
> Mar 7 00:06:18.387: %OSPF-5-ADJCHG: Process 1, Nbr 132.1.23.4 on
> Serial0 from LOADING to FULL, Loading Done
> Router3(config-if)#
> Router3(config-if)#
> Router3(config-if)#do sh ip ro
> D EX 204.12.1.0/24 [170/284160] via 132.1.23.2, 00:02:08, Ethernet1
> 132.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
> O 132.1.0.4/32 [110/64] via 132.1.0.4, 00:00:07, Serial0
> O 132.1.0.1/32 [110/64] via 132.1.0.1, 00:00:07, Serial0
> C 132.1.0.0/24 is directly connected, Serial0
> O 132.1.0.2/32 [110/64] via 132.1.0.2, 00:00:07, Serial0
> C 132.1.23.0/24 is directly connected, Ethernet1
> O E2 132.1.17.0/24 [110/20] via 132.1.0.1, 00:00:07, Serial0
> Router3(config-if)#do sh clock
> 00:06:43.027 UTC Fri Mar 7 2008
> Router3#traceroute 204.12.1.1
>
> Type escape sequence to abort.
> Tracing the route to 204.12.1.1
>
> 1 132.1.23.2 4 msec 4 msec 4 msec
> 2 132.1.0.3 32 msec 16 msec 12 msec
> 3 132.1.23.2 20 msec 12 msec 12 msec
> 4 132.1.0.3 28 msec 24 msec 24 msec
> 5 132.1.23.2 24 msec 24 msec 24 msec
> 6 132.1.0.3 36 msec 36 msec 36 msec
> 7 132.1.23.2 36 msec 36 msec 32 msec
> Router3#
>
> Router3#sh ip ro
> D EX 204.12.1.0/24 [170/284160] via 132.1.23.2, 01:07:33, Ethernet1
> 132.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
> O 132.1.0.4/32 [110/64] via 132.1.0.4, 00:06:36, Serial0
> O 132.1.0.1/32 [110/64] via 132.1.0.1, 00:06:36, Serial0
> C 132.1.0.0/24 is directly connected, Serial0
> O 132.1.0.2/32 [110/64] via 132.1.0.2, 00:06:36, Serial0
> C 132.1.23.0/24 is directly connected, Ethernet1
> O E2 132.1.17.0/24 [110/20] via 132.1.0.1, 00:06:36, Serial0
> Router3#sh clock
> 01:12:06.479 UTC Fri Mar 7 2008
> Router3#
> Router1#sh ip ro
> O E2 204.12.1.0/24 [110/20] via 132.1.0.3, 01:04:51, Serial0/0/0
> 132.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
> O 132.1.0.4/32 [110/64] via 132.1.0.4, 01:04:51, Serial0/0/0
> C 132.1.0.0/24 is directly connected, Serial0/0/0
> O 132.1.0.3/32 [110/64] via 132.1.0.3, 01:04:51, Serial0/0/0
> O 132.1.0.2/32 [110/64] via 132.1.0.2, 01:04:51, Serial0/0/0
> O E2 132.1.23.0/24 [110/20] via 132.1.0.3, 01:04:51, Serial0/0/0
> [110/20] via 132.1.0.2, 01:04:51, Serial0/0/0
> C 132.1.17.0/24 is directly connected, FastEthernet0/0
> Router1#
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART