4507R Failover issues

gabewatson · ‎11-12-2010

I am doing some failover testing on all our 4507R's in the field. I have 2 separate issues that have happened. Both units have SUP IV's in them and we are running in SSO mode. Line cards are WS-X4448-GB-SFP and WS-X4424-GB-RJ45

First issue: When failing over from one sup to another line cards lock up or go into an unknown state. Traffic does not pass and I have to either pull and re-seat card or reset the slot via hwmodule command. Once that is done traffic starts passing again, but that should not have to happen when in SSO mode. The card does not reboot itself like in RPR mode. I am running 2 different versions of code on these 2 4507's. 12.2(44)SG and 12.2(53)SG1

Second issue: Last night we tested the unit with 12.2(44)SG and after failing over the new standby SUP would post, boot all the way to the point were it was synchronizing the running configs and then would reboot again. If I changed the redundancy mode from SSO to RPR the SUP would but just fine. I did a debug on redundancy and found that it was having a problem with 1 line in the configuration for SNMP.

snmp-server enable traps config

there were 3 lines that started off like this, but it would not let me say just NO to the above. I had to turn off all SNMP and then re-enable minus that particular command.

Any ideas as to why cards are going to never-never land? Will send show mod's etc... if needed.

thanks.

glen.grant · ‎11-12-2010

First step is to get them both running the same IOS preferrably the higher one . You should be able to just do a copy function to do this and then reload the backup so they are both running the same version. I would go thru the SSO config doc to see if you have everything configured correctly.

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/25ew/configuration/guide/RPR.html

gabewatson · ‎11-12-2010

I might have not been clear enough on that. 2 separate 4507R's with redundant SUP IV's in each. Code is the same on each node, just 2 different nodes. I mentioned that because I don't think it is a software issue, but a hardware or firmware issue on the chassis or line cards. If it had just happened on 1 version of code, I would have updated and gone from there. thanks for your help.