issue with 3550 switches and management IP address

[D0nprintup_2]

I have about 50+ 3550 switches running several year old IOS. Now in my network I have several vlans.

Vlan 1 - Data

Vlan 10 - Voice

Vlan 100 - switch management.

each switch has an IP of 10.0.0.XXX /24

THis is placed on each switches int vlan100

The problem I am having is we use a tool for remote monitoring. We monitor the switch IP and I keep getting switches that " go down". We lose the management IP, we cannot ping or telnet to it. If we reboot the switch it comes back up. Now it is only that IP.  When the switch is not pingable, every other VLAN on that switch works. The end uses/phones do not have an issue.

Originally the uplink ports had the following config

int <uplinnk>

switchport mode dynamic desirable

On the other end of the uplink (The core switch) we set switchport mode trunk

Now i was reading and found something that said i need to set a native vlan of hte management vlan across all uplinks and this will correct that problem. So i spend most of last week rebooting or telneting to each switch. I added the following command, switchp[ort native vlan 100. So each switch now looks like

int <uplinnk>

switchport mode dynamic desirable

switchport trunk native vlan 100

And the same command was added to the core too.

This appears to correct the issue but this AM i find several switches are not responding again. Has anyone seen this? Is this a freaking bug in the IOS? Am i missing a command?

[Latchum Naidu]

Hi,

Please remove the following interface command on uplink "switchport mode dynamic desirable" and configure as simple "switch port mode trunk"

HTH
Please click on the correct answer if this answered your question.
Regards,
Naidu.

[D0nprintup_2]

Hi

I have done that on some of the switches and the same thing happens.

[manju.cisco]

Hi,

weird

Were you able to get a traceroute to the failed switch when your monitoring tools shows the switch as down? Was the traceroute dropping at the peer switch of the failed switch?

Did you try to ping to the failed device ip address from a peer switch? or any nearby switch?

[D0nprintup_2]

yes i ping from the peer switch and it fails. a trace just shows time outs (From the peer switch) Now the peer switch is the core switch they all come off.

Now says I have this

Core switch ---- Switch 1 ---- switch 2

                              |

                              |

                          Switch 3

Now switch 1 is not pingable nor can we telnet. Switch two the same way but switch 3 we can get to it. So switch 1 passes traffic and works. Its just the management vlan.

before I added the switchport trunk native vlan 100 to it. A show CDP nei would show native vlan 1. So this is the main reason why i thought I needed the native vlan 100 command. After that command was added, a show cdp nei will show native vlan 100 but the switch is still dropping after a period of time.

[Jon Marshall]

The native vlan is not particularly relevant in terms of ping as long as both ends of the trunk link agree on the native vlan ie. in my last place we had the native vlan set to 999 and use vlan 2 as the management vlan and this worked fine so the native vlan is a bit of a red herring.

Bear in mind that a ping to the switch itself is handled in software and not hardware. Traffic passing through the switch from a client to another client is normally hardware switched. So whether the switch responds to a ping itself depends on how busy the switch is in terms of main CPU ie. software. Appreciate it's difficult to check CPU usage when you cannot telnet into the switch but when you can get in would be worth checking CPU history usage.

Jon

[D0nprintup_2]

that is why i beleive it to be IOS or something. THese switches are not going over 30%. You can console into them and do s show proc cpu and even a history and it does go over 30. On rare occaion its near 50% but nothing i would think will take down a ping to its managment vlan interface.

[paul driver]

can you clarify your stp topology? are the switches using the same stp version?

on your trunks links set enacpsullation to dot1q
disable DTP -switchport nonegotiate

enabel trunk mode - switchport mode trunk

make sure your core switch is the stp root.

res

Paul

[D0nprintup_2]

core switch is STP root

No switch has any links back, its not double homed for redunant paths yet.

Originally I was setting both sides to switchport mode trunk

switchport trunk encap dot1q

switchport native vlan 100

but that still didnt do it. The switches came up and went back down after a few days.

I was thinking about if it was IOS so thats why i posted here. I didnt want to start to roll out new IOS if i was only missing commands.

Now It is only like 10 or so switches that do this. THere are some that have been up for months and they are fine.

[paul driver]

Hi,

I assume stp is all the same mode on all switches? what is that mode? 802.1d /w /s?

Is Udld enabled?

Any stp port security? - why i am saying this is also it doesnt stop your users creating a loop.

Please make sure ip routing isnt enabled when in host mode ( ip default-gateway) on any of the switches.

Is proxy arp disabled?

what do the logs state when the interface goes down? 
What error state are they in?

check the cam table and aging ...

res

Paul