Lab Objective
Initiate an ISSU on a three-member StackWise stack, observe each member reload and rejoin sequentially while the stack as a whole continues forwarding traffic, and verify all members run the new IOS version once the process completes without any single point of total outage.
Lab Purpose
The IOS upgrade lab covered earlier in this series required a full reload, causing a complete outage on that single device during the upgrade window. ISSU on a stack takes advantage of having multiple physical members to upgrade and reload them one at a time, keeping the overall stack operational throughout — a capability with no equivalent on a single standalone router or switch.
Lab Topology
Three-member StackWise stack from the
earlier stacking lab, currently running
IOS version 16.9.1, to be upgraded to 16.9.4
New image already copied to flash on all
three members, as covered in the earlier
IOS upgrade labTask 1: Verify Current IOS Version Across All Members
Confirm all three stack members currently run the same, older IOS version.
Task 2: Initiate the ISSU Process
Issue the ISSU load command specifying the new image, targeting the stack.
Task 3: Monitor the Sequential Member Reload Process
Observe members reloading one at a time rather than simultaneously, watching stack connectivity throughout.
Task 4: Verify Continuous Traffic Forwarding During the Upgrade
Generate continuous traffic through the stack during the upgrade window and confirm no sustained interruption occurs.
Task 5: Verify All Members Run the New Version
Once the process completes, confirm every stack member reports the new IOS version.
Solution and Verification
Switch# show version | include Version
Cisco IOS Software, Version 16.9.1
-- (Confirmed consistent across "show
-- switch" member details as well --
-- all three members on the same version)Switch# issu loadversion 1 flash:cat9k_16.09.04.SPA.bin
2 flash:cat9k_16.09.04.SPA.bin
3 flash:cat9k_16.09.04.SPA.bin
-- ISSU is directed to load the new image
-- on all three members, but the process
-- itself will apply it sequentially rather
-- than reloading the entire stack at onceSwitch# show issu state detail
Slot Image Version Status
1 16.09.04 STANDBY
2 16.09.04 STANDBY
3(active) 16.09.01 RUNNING
-- Members prepare the new image while
-- remaining on the current running
-- version, staging the upgrade before any
-- disruptive reload begins-- ISSU proceeds to reload members
-- one at a time, starting with the
-- non-active members first:
*Member 1 reloading...*
*Member 1 rejoined stack, running 16.09.04*
*Member 2 reloading...*
*Member 2 rejoined stack, running 16.09.04*
-- Only after the non-master members have
-- successfully rejoined does the process
-- move to reload the current master last,
-- triggering a final controlled switchover
-- of the master roleContinuousTrafficGen> [pings continuously
through the stack
throughout the entire
ISSU process]
Ping statistics: 1,842 sent, 1,839 received,
0.16% loss (brief loss only
during final master
switchover, a few hundred
milliseconds)
-- Traffic continued flowing throughout
-- almost the entire upgrade -- the only
-- brief interruption occurred during the
-- final master role transition, vastly
-- shorter than the multi-minute outage a
-- full stack reload would have causedSwitch# show switch
Switch# Role Version State
------------------------------------
1 Member 16.09.04 Ready
2 Member 16.09.04 Ready
*3 Master 16.09.04 Ready
-- All three members now confirmed running
-- the new IOS version, with the stack
-- having remained operational throughout
-- the entire upgrade processKey Takeaway
ISSU's near-zero-downtime capability depends entirely on having redundant physical members to sequence through — a capability unique to stacked or chassis-redundant platforms, with no equivalent on the single standalone routers upgraded via the straightforward copy/reload process covered in an earlier lab; the brief interruption during the final master switchover is typically far shorter than any TCP session timeout, making ISSU effectively transparent to most applications despite technically not being perfectly zero-impact.