Re: 4500 with strange route table issue

m.coakley · ‎11-02-2005

I have a strange problem with a 4500 switch where I have a configured VLAN that is not appearing correctly in the routing table. Here is some output from the switch:

switch#s ver

Cisco Internetwork Operating System Software

IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-I9S-M), Version 12.1(19)EW1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

TAC Support: http://www.cisco.com/tac

Compiled Mon 28-Jul-03 16:10 by eaarmas

Image text-base: 0x00000000, data-base: 0x00F12E30

ROM: 12.1(12r)EW

Dagobah Revision 86, Swamp Revision 28

switch uptime is 1 year, 24 weeks, 2 days, 8 hours, 56 minutes

System returned to ROM by power-on

System image file is "bootflash:cat4000-i9s-mz.121-19.EW1.bin"

cisco WS-C4503 (XPC8245) processor (revision 7) with 524288K bytes of memory.

Processor board ID FOX074004SS

Last reset from PowerUp

98 Gigabit Ethernet/IEEE 802.3 interface(s)

403K bytes of non-volatile configuration memory.

Configuration register is 0x2102

switch#s running

...

interface Vlan10

ip address 192.168.0.10 255.255.255.0

!

...

switch#s ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is 192.168.0.1 to network 0.0.0.0

...

D 192.168.12.0/24 [90/2419200] via 192.168.0.5, 2w3d, Vlan10

D 192.168.13.0/24 [90/3181056] via 192.168.0.5, 1w0d, Vlan10

D 192.168.14.0/24 [90/2419200] via 192.168.0.5, 2w3d, Vlan10

192.168.0.0/24 is subnetted, 1 subnets

C 192.168.0.0 is directly connected, Vlan10

S* 0.0.0.0/0 [1/0] via 192.168.0.1

See how the 192.168.0.0/24 network is being reported as a subnetted network. It obviously isn't but it is being reported as subnetted in the routing table. This seems to be causing an issue with EIGRP.

Anyone have any ideas?

Thanks,

Mike

Richard Burts · ‎11-02-2005

Mike

I am not sure why it is showing the network as subnetted. I wonder if it has something to do with the fact that the subnet is present as a connected network and also that the next hop for the static default route is in that network.

I do not have a 4503 to check it on. I did replicate the situation of a connected network and a static default route with next hop in that network on an IOS router and it did not report the network as subnetted. So I do not know if it is something about the 4500 or if it might be something in the specific release that you are running.

What kind of issues is it causing with EIGRP?

HTH

Rick

HTH

Rick

m.coakley · ‎11-02-2005

Rick,

To add a little more information... I have 2 4503 switches that are identical with the same IOS version. One has the 192.168.0.10 IP address and the other has a 192.168.0.11 IP address on VLAN 10. The second one does not report the 192.168.0.0/24 network as subnetted. (That drives me crazy.)

The issue with EIGRP is that it is giving me the error message that it is receiving EIGRP messages on a different subnet. Which is obviously not the case, BUT EIGRP is not working between the two switches.

Thanks,

Mike

thisisshanky · ‎11-02-2005

Mike,

Can you paste the EIGRP not on same subnet error (exact syslog message) ? WHen you configured EIGRP, did u specify a mask as, "network 192.168.0.0 mask 255.255.255.0" ?

Sankar Nair
UC Solutions Architect
Pacific Northwest | CDW
CCIE Collaboration #17135 Emeritus

Richard Burts · ‎11-02-2005

Mike

I think it would also be helpful if you would post the output of show cdp neighbor detail.

HTH

Rick

HTH

Rick

m.coakley · ‎11-03-2005

Maybe I'm a bad Cisco tech... but I turn off CDP typically. I can turn it on but just out of curiosity what should I be looking for with that output?

Thanks,

Mike

Richard Burts · ‎11-03-2005

Mike

In particular I think CDP neighbor detail might be helpful because it includes interface information and the IP address configured on the interface. I have found this helpful in the past in diagnosing misconfigured interfaces, or cables not connected where we think they should be which may produce mismatched neighbors.

It also occurs to me to wonder if the switch has been rebooted since the problem started. I have seen situations where something got out of sync with other parts of the IOS, producing strange inconsistencies like this, which went away when the box was rebooted.

HTH

Rick

HTH

Rick

m.coakley · ‎11-03-2005

Rick,

I understand and I assumed that is where you were going with the CDP information. To answer your question about the reboot, I am going to assume no. I am assuming since I inherited this problem from another service company and it appears that the switch has been up for about 1.5 years. I also thought about rebooting the switch after looking at everything in the configuration and comparing it to the other identical switch. I just hate falling into the Windows mentallity of "reboot" and wanted to make sure that a reboot was a reasonable solution.

Considering the reboot and things in the IOS getting "out of sync" Russ (another person posting to this thread) had some good advice on what I am looking for also.

Thanks,

Mike

m.coakley · ‎11-03-2005

"thisisshanky",

Actually, I only included the EIGRP information because it was an example of the problems I believe the issue with the interface being reporting incorrectly to the routing table is causing. But to give you a clear example view this URL: http://www.ciscopress.com/articles/printerfriendly.asp?p=27839. In this article it will discuss the EIGRP error "uncommon subnet". That is the error I was getting. I've gone through my configs and performed the diagnostics given. This does not appear to be an config error.

Thanks,

Mike

ruwhite · ‎11-03-2005

My guess is the interface is reporting the interface wrong, for some reason, to the routing table. But, there's only way to split the problem between the interface driver code and the routing table code:

-- Turn on debug ip routing

-- Shut the interface

-- Bring the interface back up

See what the debug says about the network mask/etc on the interface, from the routing table's perspective. I don't think a clear ip route will work to produce the debugs you need to look at.

Now, if the interface is correctly reporting a /24 to the routing table, it sounds like the routing table has a hung descriptor. It's kindof hard to explain, but the routing table is generally made up of a few types of data structures--network descriptors, subnet descriptors, and a few other things of this type. If the network descriptor has a subnet descriptor linked to it, we assume it's a subnetted network, and put it in the table that way. It's odd, but it looks like, somehow or another, that the network descriptor, in this case, has a subnet descriptor attached to it, and shouldn't.

Anyway, I hope that's helpful. There's no real logging you can use to diagnose this. It would be useful to try and remember how you configured things, and see if repeating those steps, exactly, will cause the problem again, if you can get it to clear in the first place.

HTH.

:-)

Russ

m.coakley · ‎11-03-2005

Russ,

Thanks for the input. I will try this out. I have to get some downtime as the switch is in production. I inherited this problem from another service company who fixed the routing issues with static routes and ignored the route problem. We are now rolling out a new network design and the migration is stopped at this point because I need to ensure that their operations does not stop.

Thanks,

Mike