I recently did a few eFSU upgrades on VSS pairs of Catalyst 6807 switches with single SUP6T in each chassis, and a few C6800-32P10G-XL linecards. An eFSU upgrade occurs on the standby supervisor first, which boots up into standby hot mode and is capable of an SSO switchover. This means second(s) of downtime, which is what we’re looking for. These upgrades involve changing code in the same train and are very picky in regards to what pre- and post-upgrade versions are supported. The compatibility matrix for eFSU upgrades can be found in the Cisco config guides…
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-5SY/release_notes/release_notes_15_5_SY.html
https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/catalyst6500/ios/SX_SY_EFSU_Compatibility_Matrix.xlsx
…the second link is the .xlsx file, with code trains as worksheets. Find the right code train and ensure that there is a C in the box of your upgrade. If this is not the case, you will likely need to perform several upgrades that are compatible. If that is not possible, you’re stuck doing a Fast Software Upgrade – which doesn’t seem to be so fast at all, with downtime in the minutes rather than second(s). This is due to the standby supervisor coming back after the upgrade in RPR mode rather than SSO mode. I’ll be doing this type of upgrade in the future, but can’t really speak much on it now.
My experience with eFSU on C6807 in the 15.5 code train was actually very pleasant. I was worried about split-brain, dual-active nightmares but it was a mostly pleasant experience. The only issue I encountered was when the supervisor in one chassis failed to boot following the issu loadversion command. The total time to boot the new code on the supervisor and all linecards was roughly 20 minutes, and after 20 minutes the supervisor had a red status LED and the management NIC was lit up green. All other LEDs were dead. Not good. The active supervisor logged that the ISSU had failed and it was aborting. I was unsure what version of code the standby would come up on if we power cycled it, or if it would even boot at all! I decided to pull the line cards, remove the links from the standby supervisor, and power cycle it. This way it would be completely detached from the network.
The standby supervisor came up on the new code! That was good, but the ISSU process had been aborted on the active supervisor. I wasn’t sure if they would sync up correctly in this state – and I didn’t want to take any chances. So I changed the boot variable on the standby (offline) supervisor to match the active supervisor’s code and reloaded it. When it came back online on the old code, I was confident that it could be powered down, the supervisor (containing VSL links) could be cabled back together, and the switch could be brought back online. Only when it came back online and was standby hot status with sso redundancy mode did I insert the old line cards and watch them come back online. They had not been upgraded previously so I knew they would be fine.
I proceeded to perform the eFSU change one more time and it went off without a hitch and I was able to still hit my change window, with less than a second of network outage.
