From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Oct 13 2004 - 11:10:26 GMT-3
Hi guys,
I'm trying to understand how a rip router decides what route to add its the
route table when it's learning the routes from 2 sources.
I have a situation where a RIP router, sw2, is learning the same routes from
R1 and R3 from 2 different links.
By default, the maximun paths for rip is 4.
Except for the directly connected subnets, sw2 is learning all its routes from
R1 and R3.
R1 and R3 both have the collection of routes in their route table which they
learned via isis. And, both R1 and R3 are redist all their isis routes into
rip with a metric of 1.
What I expected was that sw2 would have 2 paths for each of the isis routes
that were redist into rip on R1 and R3. What I found is that sw2 with a
couple of exceptions has only 1 path to each route and it's the path via R3,
163.3.38.3/24. See sw2 route table below.
Gateway of last resort is not set
R 204.12.3.0/24 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
163.3.0.0/16 is variably subnetted, 12 subnets, 2 masks
R 163.3.35.0/24 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
C 163.3.38.0/24 is directly connected, FastEthernet0/14
R 163.3.45.0/29 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
R 163.3.54.0/24 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
R 163.3.57.0/24 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
R 163.3.4.0/24 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
R 163.3.5.0/24 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
R 163.3.6.0/24 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
R 163.3.7.0/24 [120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
R 163.3.12.0/24 [120/1] via 163.3.18.1, 00:00:21, FastEthernet0/15
[120/1] via 163.3.38.3, 00:00:02, FastEthernet0/14
R 163.3.13.0/24 [120/1] via 163.3.18.1, 00:00:25, FastEthernet0/15
[120/1] via 163.3.38.3, 00:00:07, FastEthernet0/14
C 163.3.18.0/24 is directly connected, FastEthernet0/15
R 192.10.3.0/24 [120/1] via 163.3.38.3, 00:00:08, FastEthernet0/14
150.3.0.0/24 is subnetted, 8 subnets
R 150.3.5.0 [120/1] via 163.3.38.3, 00:00:08, FastEthernet0/14
R 150.3.6.0 [120/1] via 163.3.38.3, 00:00:19, FastEthernet0/14
R 150.3.1.0 [120/1] via 163.3.18.1, 00:00:16, FastEthernet0/15
[120/1] via 163.3.38.3, 00:00:19, FastEthernet0/14
R 150.3.3.0 [120/1] via 163.3.38.3, 00:00:19, FastEthernet0/14
R 150.3.2.0 [120/1] via 163.3.38.3, 00:00:19, FastEthernet0/14
C 150.3.8.0 is directly connected, Loopback0
R 150.3.4.0 [120/1] via 163.3.38.3, 00:00:10, FastEthernet0/14
R 150.3.7.0 [120/1] via 163.3.38.3, 00:00:10, FastEthernet0/14
To try to figure this out I ran debup ip rip on both R1 and R3. Here's R1's
debug output.
Rack1R1#deb ip rip
RIP protocol debugging is on
Rack1R1#clear ip ro *
Rack1R1#
*Mar 1 15:10:06.715: RIP: sending request on Ethernet0/0 to 224.0.0.9
*Mar 1 15:10:06.735: RIP: ignored v2 packet from 163.3.18.8 (not enabled on
Eth
ernet0/0)
*Mar 1 15:10:06.755: RIP: sending request on Ethernet0/0 to 224.0.0.9
*Mar 1 15:10:06.755: RIP: received v2 update from 163.3.18.8 on Ethernet0/0
*Mar 1 15:10:06.759: 150.3.2.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.759: 150.3.3.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.763: 150.3.4.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.763: 150.3.5.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.767: 150.3.6.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.767: 150.3.7.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.771: 150.3.8.0/24 via 0.0.0.0 in 1 hops
*Mar 1 15:10:06.771: 163.3.4.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.775: 163.3.5.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.775: 163.3.6.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.779: 163.3.7.0/24 via 0.0.0.0 in
Rack1R1# 2 hops
*Mar 1 15:10:06.783: 163.3.35.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.783: 163.3.38.0/24 via 0.0.0.0 in 1 hops
*Mar 1 15:10:06.787: 163.3.45.0/29 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.787: 163.3.54.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.791: 163.3.57.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.795: 192.10.3.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:06.795: 204.12.3.0/24 via 0.0.0.0 in 2 hops
Rack1R1#
*Mar 1 15:10:08.742: RIP: sending v2 flash update to 224.0.0.9 via
Ethernet0/0
(163.3.18.1)
*Mar 1 15:10:08.742: RIP: build flash update entries
*Mar 1 15:10:08.742: 150.3.1.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:10:08.742: 163.3.12.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:10:08.742: 163.3.13.0/24 via 0.0.0.0, metric 1, tag 0
Rack1R1#
*Mar 1 15:10:14.876: RIP: sending v2 update to 224.0.0.9 via Ethernet0/0
(163.3
.18.1)
*Mar 1 15:10:14.876: RIP: build update entries
*Mar 1 15:10:14.876: 150.3.1.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:10:14.876: 163.3.12.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:10:14.880: 163.3.13.0/24 via 0.0.0.0, metric 1, tag 0
Rack1R1#
*Mar 1 15:10:20.446: RIP: received v2 update from 163.3.18.8 on Ethernet0/0
*Mar 1 15:10:20.446: 150.3.2.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.446: 150.3.3.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.450: 150.3.4.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.450: 150.3.5.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.450: 150.3.6.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.450: 150.3.7.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.450: 150.3.8.0/24 via 0.0.0.0 in 1 hops
*Mar 1 15:10:20.454: 163.3.4.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.454: 163.3.5.0/24 via 0.0.0.0 in 2 hops
Rack1R1#
*Mar 1 15:10:20.454: 163.3.6.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.454: 163.3.7.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.458: 163.3.35.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.458: 163.3.38.0/24 via 0.0.0.0 in 1 hops
*Mar 1 15:10:20.458: 163.3.45.0/29 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.458: 163.3.54.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.458: 163.3.57.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.458: 192.10.3.0/24 via 0.0.0.0 in 2 hops
*Mar 1 15:10:20.462: 204.12.3.0/24 via 0.0.0.0 in 2 hops
Rack1R1#un all
I also ran a the debug on R3. Here's R3's output.
Rack1R3#deb ip rip
RIP protocol debugging is on
Rack1R3#
*Mar 1 15:04:10.880: RIP: sending v2 update to 224.0.0.9 via Ethernet0/0
(163.3
.38.3)
*Mar 1 15:04:10.880: RIP: build update entries
*Mar 1 15:04:10.880: 150.3.1.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.880: 150.3.2.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.880: 150.3.3.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.884: 150.3.4.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.884: 150.3.5.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.884: 150.3.6.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.884: 150.3.7.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.884: 150.3.8.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.888: 163.3.4.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.888: 163.3.5.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.888: 163.3.6.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.888: 163.3.7.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.888: 163.3.12.0/24 via 0.0.0.0, metric 1, tag 0
*
Rack1R3#Mar 1 15:04:10.892: 163.3.13.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.892: 163.3.18.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.892: 163.3.35.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.892: 163.3.45.0/29 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.896: 163.3.54.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.896: 163.3.57.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.896: 192.10.3.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:10.896: 204.12.3.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:11.709: RIP: received v2 update from 163.3.38.8 on Ethernet0/0
*Mar 1 15:04:11.709: 150.3.8.0/24 via 0.0.0.0 in 1 hops
*Mar 1 15:04:11.709: 163.3.18.0/24 via 0.0.0.0 in 1 hops
Rack1R3#
*Mar 1 15:04:40.853: RIP: sending v2 update to 224.0.0.9 via Ethernet0/0
(163.3
.38.3)
*Mar 1 15:04:40.853: RIP: build update entries
*Mar 1 15:04:40.853: 150.3.1.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.853: 150.3.2.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.853: 150.3.3.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.857: 150.3.4.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.857: 150.3.5.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.857: 150.3.6.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.857: 150.3.7.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.857: 150.3.8.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.861: 163.3.4.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.861: 163.3.5.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.861: 163.3.6.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.861: 163.3.7.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.861: 163.3.12.0/24 via 0.0.0.0, metric 1, tag 0
*
Rack1R3#Mar 1 15:04:40.865: 163.3.13.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.865: 163.3.18.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.865: 163.3.35.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.865: 163.3.45.0/29 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.869: 163.3.54.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.869: 163.3.57.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.869: 192.10.3.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:40.869: 204.12.3.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 15:04:41.141: RIP: received v2 update from 163.3.38.8 on Ethernet0/0
*Mar 1 15:04:41.141: 150.3.8.0/24 via 0.0.0.0 in 1 hops
*Mar 1 15:04:41.141: 163.3.18.0/24 via 0.0.0.0 in 1 hops
Rack1R3#un all
All possible debugging has been turned off
Rack1R3#
Now, I noticed that R1 is only sending 3 routes to sw2 but I'm not sure why.
R1's route table is the same as R3's and both are redist the same routes into
rip. Could this be a timing issue? In other words, is this possibly because
when R3 redist it's isis routes into rip and advertises them to sw2, sw2 in
turn advertises these same routes to R1 and because of split horizon R1
doesn't advertise these same routes back to SW2?
If this is the case, then why are there any exceptions? Why does sw2 have 2
paths for 3 routes instead of just 1 path for these routes?
Any insight would be greatly appreciated.
Thanks, Tim
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:47 GMT-3