From: Kian Wah, Lai (kian_wah@qala.com.sg)
Date: Mon Oct 18 2004 - 14:11:51 GMT-3
Type 'tclquit' :) Brian showed it in the previous replies.
Regards,
Kian Wah
Singapore Cisco User Group
http://www.sgcug.org
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Edwards, Andrew M
Sent: Tuesday, October 19, 2004 1:00 AM
To: Brian McGahan; Kian Wah, Lai; ccie2be
Cc: ccielab@groupstudy.com
Subject: RE: If all else fails, reboot
Wait a minute... I have had this happen to me too.
But the router didn't say it initiated the tcl script... Like this:
Rx(tcl)>
So, how do you kill the TCL process? How do we know we even invoked it?
I thought it would say Rx(tcl)> if we invoked the TCL process....
Alright, I'm rambling, but I wonder if you could expand on this just a
little so I wont have to reboot anymore to clear the problem 8)
andy
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian McGahan
Sent: Saturday, October 16, 2004 11:25 AM
To: Kian Wah, Lai; ccie2be
Cc: ccielab@groupstudy.com
Subject: RE: If all else fails, reboot
> 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.
This is because you invoked the TCL shell before setting the
variable. Once TCL is running it thinks you are trying to set an
environment variable. I.e. the variable "local-preference" to the value
"x". Reloading kills the TCL process.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Kian Wah, Lai
> Sent: Thursday, October 14, 2004 11:06 PM
> To: 'ccie2be'
> Cc: ccielab@groupstudy.com
> Subject: RE: If all else fails, reboot
>
> 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:49 GMT-3