Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

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 lab

Task 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 once

Switch# 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 role

ContinuousTrafficGen> [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 caused

Switch# 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 process

Key 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.