Is there a possibility to prevent a downtime of the complete VSS pair?
Not remotely possible. When you have a blade booting up with a different IOS with the active supervisor, the second blade will immediately go into ROMmon.
Does quad-sup VSS solve this problem?
No it doesn't. It only complicates the matter even further.
We already read the current Sup2T configuration guide and also the Borderless Campus Design Guide but did not found information about how to act when ios versions are not EFSU compatible.
FSU, or even eFSU, is very good if it works at all. If it doesn't work ... let's say the process to go around this can make you stay up all night.
The work-around we've developed works. And it works far better than FSU/eFSU. The downside with the work-around is you need to reboot the entire chassis. It's not like FSU/eFSU where one chassis will go down with the other blade takes over.
Before I discuss the process, there's a mandatory requirement: Make sure your the MD5 hash value of your IOS matches with the MD5 hash value found in the Cisco website. The MD5 hash value is a sure-fire guarantee the IOS you have in your TFTP server is not corrupt and is complete.
Here's the work-around process:
1. Copy the IOS from your TFTP server to the active supervisor card: copy tftp://IOS_filename.bin sup-bootflash:
2. Copy the IOS from your TFTP server to the standby supervisor card: copy tftp://IOS_filename.bin slavesup-bootflash:
3. Remove the old bootstring, change the bootstring to reflect the new IOS and (optionally) configuring the old bootstring for backup. The command sequence are:
config t
no boot system flash sup-bootflash:OLD_IOS_filename.bin
boot system flash sup-bootflash:NEW_IOS_filename.bin
boot system flash sup-bootflash:OLD_IOS_filename.bin
end
wr
4. Reboot.
