Scope and disclaimer

This blog post is primarily to explain and show the process of upgrading a Quad-sup 6807 VSS-cluster using the In Service Software Upgrade (ISSU) feature, also known as Enchanged Fast Software Upgrade(EFSU) in VSS terminology.

The entire process is very painless as long as the cabling is done right.

Requirements

Dual homed equipment

To achieve minimal and/or no downtime, everything connected the VSS-cluster must be dual homed. This is an obvious requirement, as the line cards will have to be reloaded at some point.

VSL

There must at least be a connection from each supervisor to the other chassis.
The VSL connection between the units must be present and best practice is to ensure both supervisors of both chassis is connected to the two other supervisors of the other chassis as depicted below.

Image compatability

Not all images are compatible for such an ISSU-upgrade, but a spread sheet over software trains SX SY EFSU Compatibility Matrix exists at Cisco’s.

Uninterrupted upgrade

The upgrade itself is fairly straight forward and relatively painless. In order to achieve mininmal downtime, you ought to use Staggered upgrade.

Staggered versus Tandem

Tandem/Dual Sup VSS upgrade is also possible, but will render one chassis down for the entire boot time of the supervisors.

Staggered mode, which is the default mode for Sup2T, will reload one supervisor at the time. This means, when the line cards are ready to reload, there will already be a supervisor present running that version. This gives the chassis a much smaller downtime, as the line cards reload much faster than the supervisors.
It also means there will be a supervisor present running the old software, which gives a much quicker rollback time if need be.

The Staggered mode is default method for Sup2T and can be verified with the command

show issu state

The staggered upgrade method can be disabled using the following command

no issu upgrade staggered

Commands

Commands used for the upgrade

Copy .bin file onto bootdisk.
Copy of .bin file to other supervisors. Ics-bootdisk, sw1-slot3-bootdisk, sw1-slot4-slavebootdisk
Issu loadversion bootdisk:/.bin
Issu runversion
Issu acceptversion
Issu commitversion

Commands used to verify

Show issu state
Show redundancy
show modules switch 1
show modules switch 2

Commands and associated actions

In this scenario, we got a quad-sup VSS setup in slot 3 and 4, which means we got two chassis with two supervisors in each chassis.
Switch 1 A – Active Chassis supervisor
Switch 2 S – Standby Chassis supervisor
Switch 1 A-ICS – Active-ICS (In Chassis Standby of the Active chassis)
Switch 2 S-ICS – Standby-ICS (In Chassis Standby of the Standby chassis)

Copy software to the supervisors

First of all we copy the .bin file over to the bootdisk of all the supervisors.

Copy ftp://suchAndSuch/softwarefile.bin bootdisk:/
Copy bootdisk/softwarefile.bin ics-bootdisk:/
Copy bootdisk/softwarefile.bin sw2-slot3-bootdisk:/
Copy bootdisk/softwarefile.bin sw2-slot4-bootdisk:/

Loadversion

Next we load the software file and now S-ICS will reload with new software.
Linecards of Standby-switch also reloads with new software.

Switch# Issu loadversion bootdisk:/softwarefile.bin

Afterwards, the modules will be running software as depicted her:

Runversion

When instructing the VSS-cluster to start running the new version, the active supervisor of active chassis reboots and the active supervisor of standby-chassis starts running. The chassis is now running new software and the Standby-chassis has become the Active-chassis.

Switch# issu runversion

Acceptversion

Unless we are now encountering any bugs, we accept the version.
This command resets the rollback-timer (show issu rollback-timer)

Switch# issu acceptversion

Commitversion

To finalize the upgrade, we commit to version.
The redundant supervisor of the active chassis (Switch 2) reboots and starts to use new version.
After that is done, the line cards, as well as the remaining supervisor, of the standby-chassis (Switch 1) reboots with new version.
When the line cards are up, the last supervisor of the active (switch 2) chassis upgrades.

Switch# issu commitversion

Commands and associated %ISSU log entries

VSS-cluster#issu loadversion bootdisk:s2t54-advipservicesk9-mz.SPA.152-1.SY5.bin
Oct 4 19:45:15.996: %ISSU_PROCESS-SW1-3-LOADVERSION: Staggered loadversion sequence will begin in 60 seconds. Enter ‘issu abortversion’ to cancel.
Oct 4 19:45:42.504: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: Resetting Standby-ICS shortly
Oct 4 19:45:42.504: %ISSU_PROCESS-SW2-3_STBY-6-SELF_RELOAD: slot 35 countdown to self-reload started, 30 second delay
Oct 4 19:46:18.153: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: Standby-ICS has gone offline, wait for reboot
Oct 4 19:48:12.501: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: Standby-ICS is back online, wait for terminal state
Oct 4 19:49:57.506: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: Resetting Standby shortly
Oct 4 19:49:57.510: %ISSU_PROCESS-SW2_STBY-6-SELF_RELOAD: slot 36 countdown to self-reload started, 30 second delay
Oct 4 19:51:12.503: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: New Standby has responded after switchover, wait for terminal state
Oct 4 19:54:57.506: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: New Standby has reached terminal state
Oct 4 19:55:12.562: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: Wait for new Standby-ICS terminal state
Oct 4 19:57:12.507: %ISSU_PROCESS-SW1-6-LOADVERSION_INFO: Loadversion has completed. Please issue the ‘issu runversion’ command after all modules come online.
VSS-cluster#issu runversion
%issu runversion initiated successfully
Oct 4 20:32:38.237: %ISSU_PROCESS-SW2-6-RUNVERSION_INFO: Runversion has completed. Please issue the ‘issu acceptversion’ command
VSS-cluster# issu acceptversion
VSS-cluster# issu commitversion
%issu commitversion initiated successfully, upgrade sequence will continue shortly
Oct 4 20:35:06.101: %ISSU_PROCESS-SW2-3-COMMITVERSION: issu commitversion; Staggered commitversion sequence will begin in 60 seconds. Enter ‘issu abortversion’ to cancel.
Oct 4 20:35:23.205: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Resetting Standby-ICS shortly
Oct 4 20:35:23.193: %ISSU_PROCESS-SW1-4_STBY-6-SELF_RELOAD: slot 20 countdown to self-reload started, 30 second delay
Oct 4 20:36:08.201: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Standby-ICS has gone offline, wait for reboot
Oct 4 20:37:53.201: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Standby-ICS is back online, wait for terminal state
Oct 4 20:39:38.205: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Resetting Standby shortly
Oct 4 20:39:38.197: %ISSU_PROCESS-SW1_STBY-6-SELF_RELOAD: slot 19 countdown to self-reload started, 30 second delay
Oct 4 20:40:53.197: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: New Standby has responded after switchover, wait for terminal state
Oct 4 20:44:53.197: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: New Standby has reached terminal state
Oct 4 20:45:08.201: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Wait for new Standby-ICS terminal state
Oct 4 20:47:08.203: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Resetting Active ICS shortly
Oct 4 20:47:08.206: %ISSU_PROCESS-SW2-4_STBY-6-SELF_RELOAD: slot 36 countdown to self-reload started, 30 second delay
Oct 4 20:47:53.219: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Active ICS has gone offline, wait for reboot
Oct 4 20:49:38.225: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Active-ICS is back online, wait for terminal state
Oct 4 20:51:53.255: %ISSU_PROCESS-SW2-6-COMMITVERSION_INFO: Upgrade has completed, updating boot configuration