From: ccie2be (ccie2be@nyc.rr.com)
Date: Thu Oct 14 2004 - 12:58:04 GMT-3
Hi David,
Thanks for thinking about this issue.
All isis routes are level 2 and both r1 and r3 are using a metric of 1.
Here's R1's and R3's rip config (they're exactly the same):
router rip
version 2
redistribute connected metric 1
redistribute isis metric 1
passive-interface default
no passive-interface Ethernet0/0
network 163.3.0.0
no auto-summary
As you suggested, I did a show ip rip database on both R1 and R3 and they're
very different which I don't understand because both R1 and R3 have almost
identical route tables. For some reason I don't know, R1 isn't redist most
of the isis routes while R3 is as you can see.
Here's R1's output for show ip rip database:
Rack1R1#sh ip rip da
Rack1R1#sh ip rip database
150.3.0.0/16 auto-summary
150.3.1.0/24 redistributed
[1] via 0.0.0.0,
150.3.6.0/24
[2] via 163.3.18.8, 00:00:09, Ethernet0/0
150.3.7.0/24
[2] via 163.3.18.8, 00:00:09, Ethernet0/0
150.3.8.0/24
[1] via 163.3.18.8, 00:00:09, Ethernet0/0
163.3.0.0/16 auto-summary
163.3.6.0/24
[2] via 163.3.18.8, 00:00:09, Ethernet0/0
163.3.7.0/24
[2] via 163.3.18.8, 00:00:09, Ethernet0/0
163.3.12.0/24 directly connected, Serial0/0
163.3.13.0/24 directly connected, Serial0/1
163.3.18.0/24 directly connected, Ethernet0/0
Rack1R1#
As you can see, not that many routes are redist into rip.
Here's R3's output for the same:
Rack1R3#sh ip rip dat
150.3.0.0/16 auto-summary
150.3.1.0/24 redistributed
[1] via 150.3.1.1,
150.3.2.0/24 redistributed
[1] via 150.3.2.2,
150.3.3.0/24 redistributed
[1] via 0.0.0.0,
150.3.4.0/24 redistributed
[1] via 150.3.4.4,
150.3.5.0/24 redistributed
[1] via 150.3.5.5,
150.3.6.0/24 redistributed
[1] via 150.3.1.1,
150.3.7.0/24 redistributed
[1] via 150.3.1.1,
150.3.8.0/24 redistributed
[1] via 150.3.1.1,
163.3.0.0/16 auto-summary
163.3.4.0/24 redistributed
[1] via 150.3.4.4,
163.3.5.0/24 redistributed
[1] via 150.3.5.5,
163.3.6.0/24 redistributed
[1] via 150.3.1.1,
163.3.7.0/24 redistributed
[1] via 150.3.1.1,
163.3.12.0/24 redistributed
[1] via 150.3.1.1,
163.3.13.0/24 directly connected, Serial1/2
163.3.18.0/24 redistributed
[1] via 150.3.1.1,
163.3.35.0/24 directly connected, Serial1/0
163.3.38.0/24 directly connected, Ethernet0/0
163.3.45.0/29 redistributed
[1] via 150.3.4.4,
163.3.54.0/24 redistributed
[1] via 150.3.5.5,
163.3.57.0/24 redistributed
[1] via 150.3.5.5,
192.10.3.0/24 auto-summary
192.10.3.0/24 redistributed
[1] via 150.3.4.4,
204.12.3.0/24 auto-summary
204.12.3.0/24 redistributed
[1] via 150.3.2.2,
Rack1R3#
What's really got me confused and bewildered is that all those routes with
"redistributed" next to them are in the route table of R1 as well.
Another strange thing is this: When I first redist isis into rip on both R1
and R3 and then looked at SW2's route table, all those routes showed up with
2 paths - 1 via R1 and another via R3. Then after a few minutes without
having made any config changes on R1 or R3, I looked again at sw2's route
table and almost all the routes appeared but with just 1 path via R3. I
don't get it.
Any ideas?
Thanks, Tim
----- Original Message -----
From: "Hoonpongsimanont, Chalermchai"
<chalermchai.hoonpongsimanont@atosorigin.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study" <ccielab@groupstudy.com>
Sent: Thursday, October 14, 2004 11:14 AM
Subject: RE: Rip v2 path selection criteria
> Hi,
>
> Interesting! Are is-is route in r1, r3 same level? If not, you may want to
> check as, by default, is-is will redistribute only L2 route.
>
> Can you show ip rip database on r1, to make sure that is-is routes are
> properly redistributed into rip.
>
> Also make sure that metric are set to 1 on both r1, r3 when
redistribution.
>
> Cheers,
> David
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Wednesday, October 13, 2004 9:10 PM
> To: Group Study
> Subject: Rip v2 path selection criteria
>
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:47 GMT-3