Supervisor module issue on a dual sup chassis

[d.muccillo]

We have an issue with the active sup32 module showing up as unknown and rebooting. The standby sup has taken over. We are about to swap the sup32 but i have a question regarding procedure as this sup module was taken directly out of stuck and potentially is not running the same code as on the existing sup in active mode. Is there a procedure/best practices on swapping a bad sup module and loading correct code onto this? Once the new module is inserted with the different code will it affect existing service? Any help would be appreciated?

[JORGE RODRIGUEZ]

Go to this link and scroll down to   "Troubleshooting Hardware"  section   ,  also other links within  on replacing failed sup engines  etc..

http://www.cisco.com/en/US/partner/products/hw/switches/ps708/prod_tech_notes_list.html

If your sup is in hybrid usually  when you have highavailability versioning enabled on the sup engine it will copy the code from active sup to the newly installed sup, as for the layer 3 you probably have to manually update ,  but go over the link provided.

Good luck

Regards

[Pavol Golis]

Inserting new standby sup might cause some packets to be dropped, as Sup32 has no fabric all traffic is going via shared chassis bus, hence once standby is inserted those busses got jammed for short period of time. When you insert sup with old version it will bootup in RPR redundancy mode, you can load correct image on it from active sup via copy sup-bootdisk: slavesup-bootdisk: or any location you store image at. Once done reload standby via "redundancy peer reload" or "show redundancy"-identify standby slot & "hw-module module X reset", it should come up with correct IOS version and in SSO mode.