cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1019
Views
0
Helpful
1
Replies

Prime 3.1 software distribution to 4500 with SSO

eglinsky2012
Spotlight
Spotlight

I'm new to distributing software with Prime 3.1.6 with device pack 13. I'm pleased with how efficiently and intelligently it seems to work; I upgraded a dozen 2960s and 3560X's with ease. If the flash already has 2 images, it'll delete the older one, and make the boot variable point first to the newer image, then the previously-new (currently running) version as a backup.

 

I did try a 4500 with Sup8 with redundant supervisors in SSO (not VSS). I did the activation and boot variable change within the distribution, not separately. Prime was smart enough to put the image on the slavebootflash as well as the bootflash.

 

However, with the ISSU option enabled, this error appeared. If I recall, neither supervisor rebooted, and both were still set to boot the old image.

The status of peer device after In Service Software Upgrade loadversion is not in any of the states 1.StandByHot or 2.Redundancy mode is not in SSO or 3.current active device unit state is not in the active state, to proceed with In Service Software Upgrade runversion.

So, I performed the distribution again, this time unchecking the ISSU option despite the warning that this is not the ideal way to upgrade ISSU-capable devices. Sup1 (active) did reboot and came back running the new image and the slave (Sup2) did become active. However, Sup1 never became active again and Sup2 never rebooted, staying on the old code.

 

Come to find out, Prime 3.1 (and beyond) does not support software distribution on 4500s with redundant supervisors. That's unfortunate, since we have many of these and they're so cumbersome to upgrade via CLI.

 

Does anyone know if I can make this work? Is a 4500 with redundant supervisors actually supported in 3.1.7, or a later patched software version? Perhaps a "redundancy reload shelf" command can be integrated with the distribution to ensure a complete reboot with the new software, or run as a CLI template after?

1 Reply 1

Leo Laohoo
Hall of Fame
Hall of Fame
Never use PI to push IOS with dual supervisor cards.
The reason is PI will use ISSU or FSU/eFSU and some of us know that this process doesn't work (well) all the time.