cat6000supk8.8-2-1.bin seems to have a bug

[mark.weaver]

I recently upgraded a 6509 from cat6000sup.6-1-1b.bin to cat6000supk8.8-2-1.bin and encountered an unusual issue.

This 6509 has redundant supervisor 1A and msfc2's with the msfc2's running c6msfc2-ds-mz.121-2.E.bin.

After upgrading the supervisors i found that several vlan interfaces on the msfc on the redundant supervisor either totally failed to respond to pings are would respond to only one ping and then time out despite a sh ip int br showing all interfaces up and sh standby showing that this msfc had some interfaces that were the active router for certain vlans and were forwarding traffic for that vlan.

A ping to a vlan interface from a pc in that vlan always produced a response.

The msfc on the active supervisor performed as normal.

I have rolled back the upgrade and everything seems to performing fine now.

Unfortunately we do not have smartnet - not my decision - i cannot open a tac case directly with cisco although my supplier is working with me on this but has not come across this scenario before.

This post is more for information than anything but if anybody else has experienced this before i would be pleased to hear your solution.

regards

mark

[skarundi]

Have you completely followed the guidelines described in the Cisco.com document titled "Understanding Internal MSFC Redundancy on Hybrid Mode Catalyst 6000 Switches" ?

8.2.x Code is strict about the way vlans are configured. Both MSFCs must have the same vlans configured on each msfc. ACL and routing config must be the same on both MSFCs.

If you are running config-sync on the MSFCs, then you may be are running bug ID CSCed20613.

Downgrade to 6.4(7) if this is the case.

[mark.weaver]

I will go over this again to make sure but the configs were the same on the msfcs before the upgrade and were working ok.

I am running hsrp for redundancy, downgrading to 6.4(7) is not an option as i have new hardware to support which recommends 7.x (cannot remember exactly) but my supplier says these images are not for sale any more.

This is not the first time somebody has recommended using 6.4(7) instead of 8.x - is there something funny about these images?

regards

mark

[skarundi]

No there is nothing wrong with 8.x. It sounds like you are not using the MSFC config-sync feature. So perhaps the guidelines specified in the document provided earlier were not followed. I mentioned 6.4(7) because the MSFC config-sync bug is not present in that code.

[mark.weaver]

The image on my msfc's did not support config-sync - support for this did not start until 12.1(3a)E1 and i had been using 12.1(2)E

Although as i said before this setup had been working fine this most mean that 8.2.x has picked up something that 6.1.x did not.

I am now running 12.1(8b)E15 so i could try using config-sync.

regards

mark