From: ccie2be (ccie2be@nyc.rr.com)
Date: Thu Oct 14 2004 - 15:44:08 GMT-3
Hi Lai,
Thanks for looking into this. I really appreciate it.
After you mentioned that maybe it's a bug in IOS, I figured maybe I should
just reboot the router - in this case R1. After rebooting R1 and doing a
show ip rip database, almost all those routes which weren't there before
suddenly appeared. Then I looked at SW2's route table and sure enough, now
SW2 had 2 paths to almost all the routes.
I've had other problems where I couldn't figure out why something wasn't
working and was going crazy because of it. Then, someone would tell me to
reboot or just for the heck of it, I would reboot the router and then
everything was fine.
My problem is that 95% of the time when something isn't working properly,
it's because of something I've done wrong, so I'm kind of mentally
conditioned to think there's a mistake I need to find and correct.
Unfortunately, a small percentage of the time, the routers and switches are
configured 100% correctly but I don't realize that and think to reboot the
problem router or switch.
Somehow, I've got to remember "If all else fails, reboot."
Thanks, Tim
----- Original Message -----
From: "Kian Wah, Lai" <kian_wah@qala.com.sg>
To: "'ccie2be'" <ccie2be@nyc.rr.com>
Sent: Thursday, October 14, 2004 2:06 PM
Subject: RE: Rip v2 path selection criteria
> I tested it out, here are the results. I didn't follow the topo and ip
> addressing. Attached you'll find the topo of what I've used to test.
> Routers are 2621 and they're running c2600-js-mz.122-6.bin
>
> BB1 and BB2 is injecting the routes
> 112.0.0.0/8 - 119.0.0.0/8
>
> I tried to follow your config as closely to what I can do.
>
> -- sw2 routing table
> R 119.0.0.0/8 [120/1] via 10.3.3.3, 00:00:19, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:01, FastEthernet0/0
> R 118.0.0.0/8 [120/1] via 10.3.3.3, 00:00:19, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:01, FastEthernet0/0
> R 117.0.0.0/8 [120/1] via 10.3.3.3, 00:00:19, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:01, FastEthernet0/0
> R 116.0.0.0/8 [120/1] via 10.3.3.3, 00:00:19, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:01, FastEthernet0/0
> R 115.0.0.0/8 [120/1] via 10.3.3.3, 00:00:20, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:02, FastEthernet0/0
> R 114.0.0.0/8 [120/1] via 10.3.3.3, 00:00:20, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:02, FastEthernet0/0
> R 113.0.0.0/8 [120/1] via 10.3.3.3, 00:00:20, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:02, FastEthernet0/0
> 172.16.0.0/24 is subnetted, 1 subnets
> R 172.16.1.0 [120/1] via 10.3.3.3, 00:00:23, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:05, FastEthernet0/0
> R 112.0.0.0/8 [120/1] via 10.3.3.3, 00:00:23, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:05, FastEthernet0/0
> 10.0.0.0/24 is subnetted, 2 subnets
> C 10.3.3.0 is directly connected, FastEthernet0/1
> C 10.1.1.0 is directly connected, FastEthernet0/0
> R 192.168.1.0/24 [120/1] via 10.3.3.3, 00:00:23, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:05, FastEthernet0/0
> R 192.168.2.0/24 [120/1] via 10.3.3.3, 00:00:23, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:05, FastEthernet0/0
> 150.1.0.0/24 is subnetted, 3 subnets
> R 150.1.3.0 [120/1] via 10.3.3.3, 00:00:23, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:05, FastEthernet0/0
> R 150.1.1.0 [120/1] via 10.3.3.3, 00:00:24, FastEthernet0/1
> [120/1] via 10.1.1.1, 00:00:06, FastEthernet0/0
> C 150.1.8.0 is directly connected, Loopback0
> sw2#
>
> show ip rip database on sw2
> 112.0.0.0/8 auto-summary
> 112.0.0.0/8
> [1] via 10.1.1.1, 00:00:27, FastEthernet0/0
> [1] via 10.3.3.3, 00:00:18, FastEthernet0/1
> 113.0.0.0/8 auto-summary
> 113.0.0.0/8
> [1] via 10.1.1.1, 00:00:27, FastEthernet0/0
> [1] via 10.3.3.3, 00:00:18, FastEthernet0/1
> 114.0.0.0/8 auto-summary
> 114.0.0.0/8
> [1] via 10.1.1.1, 00:00:27, FastEthernet0/0
> [1] via 10.3.3.3, 00:00:18, FastEthernet0/1
> And so on.
>
> Thus, I think is the IOS issue :) if you want me to show you the config or
> you want more information, you can contact me.
>
> Regards,
> Kian Wah
> Singapore Cisco User Group
> http://www.sgcug.org
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Friday, October 15, 2004 12:30 AM
> To: Kian Wah, Lai
> Subject: Re: Rip v2 path selection criteria
>
> This is IE lab 7.
>
> Attached are the configs for all the routers and switches.
>
> Thanks. If you can figure this out and explain this to me, I'd be so
happy
> I can't even tell you.
>
> Tim
> ----- Original Message -----
> From: "Kian Wah, Lai" <kian_wah@qala.com.sg>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>
> Sent: Thursday, October 14, 2004 12:22 PM
> Subject: RE: Rip v2 path selection criteria
>
>
> > Hi,
> >
> > Which IE lab is this? Or is it your own lab?
> >
> > Sometimes things don't work could be due to IOS problem. Once I
> > redistributed OSPF into EIGRP in one of the IE lab and when I did show
ip
> > eigrp topo, it doesn't even have the routes!!!
> >
> > If you can, send me your config so I can test it out tomorrow using
> > different routers to determine if it is really the IOS issue.
> >
> > Regards,
> > Kian Wah
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > ccie2be
> > Sent: Thursday, October 14, 2004 11:58 PM
> > To: Group Study; Hoonpongsimanont, Chalermchai
> > Cc: Brian McGahan
> > Subject: Re: Rip v2 path selection criteria
> >
> > 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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:47 GMT-3