From: Kian Wah, Lai (kian_wah@qala.com.sg)
Date: Fri Oct 15 2004 - 01:06:28 GMT-3
Oops, didn't notice you cc to groupstudy and my rule sent it to another
folder. Ignore my previous email to you.
I thought you would reboot it first before posting the problem. T train IOS
are not very stable yet so most of the time a reboot would solve the issue.
During the lab, you'll encounter some problems with the IOS, most likely I
guess. I had problems with it for my both attempts. Without finding the
proctor and asking 'AHHH IT'T CAN'T WORK' or spending *lots* of time
troubleshooting, I would reboot first. Try to think of other problems or
take a rest during the reboot period. If the problem still exist means it's
likely your config or an IOS bug. Try to troubleshoot first (don't spend too
much time) before asking the proctor.
One example I experienced is:
Route-map aaa
Set local-preference x
The router replied me with 'set local-preference x'. Before going crazy, I
rebooted the router and it solved the problem.
Regards,
Kian Wah
Singapore Cisco User Group
http://www.sgcug.org
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Friday, October 15, 2004 2:44 AM
To: Kian Wah, Lai
Cc: Group Study
Subject: Re: If all else fails, reboot
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:48 GMT-3