- 1 Scope and disclaimer
- 2 Requirements
- 3 Uninterrupted upgrade
- 4 Commands
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.
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.
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.
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.
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 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
Commands used to verify
Show issu state
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:/
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:
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
Unless we are now encountering any bugs, we accept the version.
This command resets the rollback-timer (show issu rollback-timer)
Switch# issu acceptversion
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.
%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