VLAN Trunk Problem with CatOS 8.1 on 6500

[michael76]

Recently we upgraded to CatOS 8.1. We use a 6509 as a core and two 6513 as distros. My mang. VlAN is trunked over multi ports with Dot1q enc from the Distros to the core where all L3 takes place. Int sc0 is used to support all vlans in the distros. On one switch we have no active interfaces other than sc0 in our mang. VLAN. Before the code upgrade everything functioned properly and connectivity was fine. Since the upgrade unless you ping out first from the affected 6513 it cannot be contacted. No arp restrictions are set and no ACL issues are involved as the were not changed. Also pruning isn't enabled. I can't get the 6513 without physical devices to keep mac addresses even after I connect a physical device locally to the Mang. vlan. Anyone experience anything like this with this code yet? Any TAC cases?

[benhur.p]

I am same using the same version but not sure if there is any problem becuase our primary use is to connect a physical device locally...

[michael76]

Hmm... We also did a full reboot to no avail. TAC seems to be pretty baffled as well. When we ping sc0 on the affected 6513 we see no traffic... in or out. However, when we ping a device on the switch we see the traffic on the trunk. It's as ifthere is no commumication between the sc0 interface(cpu) and the physical trunk. Does anyone know of a way to watch the threading or something to debug cpu interupts from the os. I know that may sound a little crazy but we've tried just about everything else short of a rollback. I don't think the rollback would be as beneficial seeing that everything works fine on the other 6513 in this configuration. Anybody have any better ideas? Thanks for the help guys.

Mike

[mark.weaver]

I have just upgraded to 8.2.1 on a 6509 with redundant supervisor 1a and msfc2. Things seemed ok after the supervisor upgrade, i then upgraded an msfc to 12.1.19E and had problems with not being able to ping some ip addresses on vlan interfaces despite the fact that they were forwarding traffic as normal. Some interfaces respond to one ping and then time out, the other msfc that had not been upgraded was performing as normal.

I the rolled back the upgrade on the msfc reset the msfc but the same problem remained, i did a cold boot on the entire switch and the problem remained.

A debug ip icmp shows that the msfc is sending replies to a standard ping to three or four different addresses.

My supplier is totally baffled as to why this is happening, we do not have smartnet so i am unable to open a tac case so i will continue to investigate but this has all happened since the catOS upgrade.

regards

mark