Why Software Upgrades on the Cat9K Are Different
If you’ve ever upgraded an older Catalyst 2960 or 3750 stack, you know the drill: copy the image to flash, change the boot statement, reload. Simple, but painful — especially when that switch is carrying production traffic and you’re staring down a maintenance window at 2 AM.
The Catalyst 9000 series (Cat9200, Cat9300, Cat9400, Cat9500, Cat9600) changed everything. Cisco rewrote the upgrade architecture from the ground up when they moved these platforms to IOS-XE. You now have two fundamentally different operating modes, a patching system that doesn’t require a full reload in many cases, and an in-service upgrade path for high-availability stacks. Understanding the differences — and when to use which — will save you hours of downtime and prevent the kind of mistakes that result in a switch stuck at rommon.
This guide walks through the full upgrade lifecycle: Bundle Mode vs. Install Mode, SMU patches, ISSU on stacked Cat9300s, and golden image practices that keep your fleet consistent. All CLI examples are real IOS-XE 17.x syntax you can use directly.
Bundle Mode vs. Install Mode: The Foundation
Before you can think about upgrading, you need to know which mode your switch is running. This is the single most important thing to verify before doing anything else.
Bundle Mode
In Bundle Mode, the switch boots directly from a monolithic .bin file. The entire OS lives in one file on flash. This is the legacy behavior — familiar, predictable, but inflexible. You cannot use SMU patches, and ISSU is not supported. Bundle Mode is essentially deprecated for Cat9K, but many switches are still running it, especially if they shipped with an older IOS-XE version or were upgraded the “old way.”
To check:
SW1# show version | include mode
Switch is in BUNDLE modeOr look at the boot statement:
SW1# show running-config | include boot system
boot system switch all flash:cat9k_iosxe.17.09.04a.SPA.binIf you see a .bin file in the boot statement with no packages.conf reference, you’re in Bundle Mode.
Install Mode
Install Mode is the modern way. Instead of one monolithic binary, IOS-XE is broken into individual software packages — the base OS, the optional packages, and the ROMMON image. These are tracked by a packages.conf file that acts as the manifest.
SW1# show version | include mode
Switch is in INSTALL mode
SW1# show install summary
[ R0 ] Installed Package(s) Information:
State (St): I - Inactive, U - Activated & Uncommitted,
C - Activated & Committed, D - Deactivated & Uncommitted
--------------------------------------------------------------------------------
Type St Filename/Version
--------------------------------------------------------------------------------
IMG C 17.09.04a.0.4
IMG I 17.12.03a.0.5
--------------------------------------------------------------------------------
Auto abort timer: inactiveInstall Mode gives you:
- SMU support — apply hot patches without a reload
- ISSU — upgrade stacks with sub-minute traffic interruption
- Rollback — instantly revert to the previous committed version if something goes wrong
- Dual image tracking — the switch tracks both the active and inactive image simultaneously
If you’re still in Bundle Mode, the first thing you should do is convert to Install Mode. We’ll cover that below.
Converting from Bundle Mode to Install Mode
This is a one-time operation that requires a reload. Once done, you’ll never go back.
! Step 1: Verify available flash space
SW1# dir flash: | include bytes
2097152000 bytes total (1843200000 bytes free)
! Step 2: Extract the .bin into packages
SW1# software expand running to flash:
! Step 3: Verify packages.conf was created
SW1# dir flash: | include packages
-rw- 3456 packages.conf
! Step 4: Set boot to packages.conf
SW1# conf t
SW1(config)# no boot system
SW1(config)# boot system switch all flash:packages.conf
SW1(config)# end
SW1# write memory
! Step 5: Reload
SW1# reloadAfter the reload, confirm you’re in Install Mode with show version | include mode. Now you can use the full install workflow.
Standard IOS-XE Upgrade Workflow (Install Mode)
This is the procedure you’ll use for the vast majority of upgrades — moving from one major release to another (e.g., 17.9 to 17.12).
Step 1: Copy the image to flash
SW1# copy tftp://10.10.0.5/cat9k_iosxe.17.12.03a.SPA.bin flash:
Destination filename [cat9k_iosxe.17.12.03a.SPA.bin]?
Accessing tftp://10.10.0.5/cat9k_iosxe.17.12.03a.SPA.bin...
Loading cat9k_iosxe.17.12.03a.SPA.bin from 10.10.0.5 (via GigabitEthernet0/0): !!!!!
[OK - 923456512 bytes]Step 2: Verify the MD5 hash
SW1# verify /md5 flash:cat9k_iosxe.17.12.03a.SPA.bin
..........Done!
verify /md5 (flash:cat9k_iosxe.17.12.03a.SPA.bin) = a3f4d2b8c9e1f5a7d2b8c9e1f5a7d2b8Compare this against the MD5 on Cisco’s software download page. Never skip this step — a corrupted image will rommon your switch on reload.
Step 3: Add the new image
SW1# install add file flash:cat9k_iosxe.17.12.03a.SPA.bin activate commit
install_add_activate_commit: Adding PACKAGE
install_add_activate_commit: Checking whether new add is allowed ....
--- Starting initial file syncing ---
Copying flash:cat9k_iosxe.17.12.03a.SPA.bin from R0 to:
[R1] finished
--- Done copying to stack members ---
install_add_activate_commit: Activating PACKAGE
--- Starting Activate ---
Performing Activate on all members
[R0] Activate package(s) on R0:
-- Starting list of software package changes ---
Old files list:
Removed cat9k-cc_srdriver.17.09.04a.SPA.pkg
Removed cat9k-srdriver.17.09.04a.SPA.pkg
New files list:
Added cat9k-cc_srdriver.17.12.03a.SPA.pkg
Added cat9k-srdriver.17.12.03a.SPA.pkg
[R0] Finished Activate on R0
[R1] Activate package(s) on R1
[R1] Finished Activate on R1
Executing Pre-Provision of PACKAGE
[Stage] Pre-Provision 0/0
Checking mandatory pre-provision for switch 2
--- Done ---
install_add_activate_commit: Committing PACKAGE
--- Starting Commit ---
Performing Commit on all members
[R0] Commit package(s) on R0:
[R0] Finished Commit on R0
[R1] Commit package(s) on R1:
[R1] Finished Commit on R1
Checking status of Commit on [R0 R1]
Commit: Passed on [R0 R1]
--- Done ---
Bannerline: PACKAGE COMMITTED
[R0]: Install add activate commit completed successfully
[R1]: Install add activate commit completed successfully
SUCCESS: install_add_activate_commit Mon Aug 15 03:45:23 UTC 2026
*Aug 15 03:45:30.012: %INSTALL-5-INSTALL_COMPLETED_INFO: R0/0: install_engine: Completed install add activate commit for slot 0
--- Done ---Note: For major version upgrades, the switch will reload automatically. For minor releases on the same train, it may not. Always check the release notes.
Step 4: Verify the upgrade
SW1# show version | include Version
Cisco IOS XE Software, Version 17.12.03a
Cisco IOS Software [Dublin], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.12.03a
SW1# show install summary
[ R0 ] Installed Package(s) Information:
Type St Filename/Version
IMG C 17.12.03a.0.5Committed (C) means the image is fully installed and will survive a reload. You’re done.
Cleaning up old packages
SW1# install remove inactive
install_remove: START Mon Aug 15 03:50:00 UTC 2026
Cleaning up unnecessary package files
Scanning boot directory for packages ... done.
Preparing packages list to delete ... done.
The following files will be deleted:
[R0]:
/flash/cat9k_iosxe.17.09.04a.SPA.bin
/flash/cat9k-cc_srdriver.17.09.04a.SPA.pkg
/flash/cat9k-srdriver.17.09.04a.SPA.pkg
Are you sure you want to remove the above files? [y/n] y
[R0]: Deleting file flash:cat9k_iosxe.17.09.04a.SPA.bin ... done.
SUCCESS: install_remove Mon Aug 15 03:50:22 UTC 2026Reclaim that flash space after every upgrade. Cat9300 flash is plentiful (32GB on most models) but the packages accumulate.
SMU: Software Maintenance Updates
An SMU (Software Maintenance Update) is a targeted patch for a specific bug or CVE, delivered as a small file you apply without upgrading the entire IOS-XE version. This is where Install Mode really shines. If Cisco publishes a security advisory and an SMU is available for your train, you can patch production in minutes instead of scheduling a full maintenance window.
SMUs are hot-patching in some cases (no reload) or require a reload in others. The SMU description on Cisco’s security advisory will tell you which.
Check for available SMUs
Go to Cisco’s Software Download page: software.cisco.com → Catalyst 9000 → your platform → IOS XE → your release → SMU. Download the .smu.bin file.
Apply an SMU
! Copy SMU to flash
SW1# copy tftp://10.10.0.5/cat9k_iosxe.17.12.03a.CSCwh12345.SPA.smu.bin flash:
! Install the SMU (no-reload SMU)
SW1# install add file flash:cat9k_iosxe.17.12.03a.CSCwh12345.SPA.smu.bin activate commit
install_add_activate_commit: Adding PACKAGE
[R0]: Adding SMU package cat9k_iosxe.17.12.03a.CSCwh12345.SPA.smu.bin
install_add_activate_commit: Activating PACKAGE
[R0]: Activating SMU...
install_add_activate_commit: Committing PACKAGE
SUCCESS: SMU committed (no reload required)
! Verify
SW1# show install summary
Type St Filename/Version
IMG C 17.12.03a.0.5
SMU C cat9k_iosxe.17.12.03a.CSCwh12345.SPA.smu.binRemove an SMU
SW1# install deactivate file flash:cat9k_iosxe.17.12.03a.CSCwh12345.SPA.smu.bin
SW1# install commit
SW1# install remove file flash:cat9k_iosxe.17.12.03a.CSCwh12345.SPA.smu.binSMU rollback is clean and fast. This is how you handle emergency CVE patches — apply the SMU now, schedule the full image upgrade for the next window.
ISSU: In-Service Software Upgrade on Cat9300 Stacks
ISSU (In-Service Software Upgrade) is the gold standard for Cat9K stacks. It allows you to upgrade a StackWise stack from one IOS-XE version to another with less than 30 seconds of control-plane interruption and near-zero data-plane impact for most traffic types.
ISSU works by upgrading stack members one at a time while the active supervisor stays up. The standby switches reload with the new image, then the active performs a graceful switchover, the old active becomes standby and reloads.
Prerequisites
- IOS-XE 16.12+ (Cat9300); 17.3+ strongly recommended
- SSO (Stateful Switchover) must be enabled and synchronized
- Source and target images must be in the “supported” ISSU matrix (same major train, generally)
- Stack must be in Install Mode
- No active console session on non-active stack members during the upgrade
Pre-ISSU verification
! Verify SSO state
SW1# show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 1
Redundancy Protocol (Operational) = Route Processor Redundancy Plus (RPR+)
Redundancy Protocol (Configured) = Stateful Switchover
! Verify stack sync
SW1# show switch stack-ports
Stack Port Status Neighbors
Switch # Port 1 Port 2 Port 1 Port 2
1 OK OK 2 3
2 OK OK 3 1
3 OK OK 1 2
! Check ISSU eligibility
SW1# show issu state detail
--- Starting Show ISSU State ---
ERP Status:
Slot = R0, image = cat9k_iosxe.17.09.04a.SPA.bin, state = Active Extranet
Slot = R1, image = cat9k_iosxe.17.09.04a.SPA.bin, state = Standby Extranet
Load for five secs: 3%/0%; one minute: 2%; five minutes: 2%
ISSU state: InitRunning ISSU
! Add and activate new image — but DO NOT use "commit" yet
SW1# install add file flash:cat9k_iosxe.17.12.03a.SPA.bin activate issu
--- Starting ISSU ---
The above activate will cause an ISSU operation.
All affected members will be upgraded. Members that cannot
complete ISSU will be reloaded.
Do you want to proceed? [y/n]: y
--- Starting Add ---
Finished adding file flash:cat9k_iosxe.17.12.03a.SPA.bin
--- Done ---
--- ISSU sequence in progress ---
Step 1: Load New Software on Standby
[R1] Loading cat9k_iosxe.17.12.03a.SPA.bin on standby ...
[R1] Standby reloading with new image ...
[R1] Standby came up with new image 17.12.03a ...
[R1] Standby synced with Active, SSO ready ...
Step 2: Switchover to Standby (new image)
Initiating graceful switchover ...
**** Control-plane switchover occurs here (< 30 seconds) ****
Step 3: Active (now standby) reloads with new image
[R0] Loading cat9k_iosxe.17.12.03a.SPA.bin ...
[R0] Came up with new image 17.12.03a ...
ISSU complete. Both switches now running 17.12.03a.
! Verify before committing
SW1# show version | include Version
Cisco IOS XE Software, Version 17.12.03a
! Commit once satisfied
SW1# install commit
install_commit: Committing PACKAGE
Checking status of Commit on [R0 R1]
Commit: Passed on [R0 R1]
! ROLLBACK if needed (must do before commit)
! SW1# install rollback to committedCritical: Do NOT commit immediately. Let the switch run for 5–15 minutes under normal traffic, check your monitoring, then commit. Before you commit, install rollback to committed will instantly revert both stack members to the previous version with another brief switchover. Once committed, rollback requires a full reload.
Golden Image Management: Keeping Your Fleet Consistent
Once you find a stable, tested IOS-XE version for your Cat9K fleet, you want every switch running exactly that version. Here's the operational discipline that keeps sprawl under control.
Track your golden version in a config variable
We use a simple Netmiko script across the fleet to audit versions — see our post on network automation with Python, Netmiko, NAPALM, and Nornir for the full pattern. The key command to pull per device:
show version | include Version
show install summaryAutomate compliance checks with EEM
You can use Cisco EEM to alert when a switch comes up running a non-golden version — useful for switches that get swapped in from spares. See our guide on Cisco EEM scripts for IOS-XE automation for the pattern:
event manager applet CHECK_VERSION
event syslog pattern "SYS-5-RESTART"
action 1.0 cli command "enable"
action 1.5 cli command "show version | include Version"
action 2.0 set golden_ver "17.12.03a"
action 2.5 if $_cli_result ne $golden_ver
action 3.0 syslog msg "WARNING: Non-golden IOS-XE version detected"
action 3.5 mail server "10.10.0.10" to "noc@company.com" from "switch@company.com" subject "Version Mismatch Alert"
action 4.0 endFlash pre-staging
For large fleets, pre-stage the golden image on every switch's flash during a low-traffic period using install add (without activate). The image is verified, extracted, and ready to activate — then when the maintenance window opens, you only need the activate + commit step, which is much faster.
! Pre-stage without activating
SW1# install add file tftp://10.10.0.5/cat9k_iosxe.17.12.03a.SPA.bin
! Later during the window, just activate
SW1# install activateCommon Gotchas and How to Avoid Them
1. Insufficient flash space
The Cat9300 needs roughly 1.5× the image size free to extract packages. If you're tight on space, delete old inactive packages first with install remove inactive.
2. Boot variable pointing to wrong file
After converting to Install Mode, always verify show boot shows packages.conf, not a .bin file. A stale boot variable will drop you into Bundle Mode on next reload.
SW1# show boot
BOOT variable = flash:packages.conf;
Configuration register is 0x1023. Stack member incompatibility during ISSU
ISSU has a compatibility matrix. Generally you can ISSU within a major release (17.9.x to 17.9.y, or 17.9.x to 17.12.x on the same long-lived train). Cross-train jumps (16.x to 17.x) require a standard reload upgrade. Check the ISSU compatibility matrix in the release notes before assuming it's supported.
4. SMU not showing as committed after reload
SMUs that require a reload must be re-applied after the reload if they weren't committed first. Always run install commit after applying any SMU, even reload-required ones, to make them persistent.
5. Forgetting to sync stack members before ISSU
If SSO is not in STANDBY HOT state, ISSU will either fail or fall back to a disruptive upgrade. Fix any stack sync issues with redundancy reload shelf on the standby before attempting ISSU.
Quick Reference: Upgrade Decision Tree
- Applying a CVE patch, no downtime available: Use SMU (if available for your train)
- Minor/maintenance release on a 2-member+ stack, SSO is healthy: Use ISSU
- Major version jump (e.g., 16.x → 17.x), or single switch: Standard install add/activate/commit with reload
- Still in Bundle Mode: Convert to Install Mode first, then follow above
Wrapping Up
The Catalyst 9000 upgrade model is genuinely one of the best things Cisco built into IOS-XE. Install Mode gives you the flexibility that Bundle Mode never could — targeted patching with SMUs, near-hitless upgrades with ISSU, and clean rollback when something unexpected happens. The learning curve is front-loaded: once you've done the Bundle-to-Install conversion and run your first ISSU, the workflow is repeatable and reliable.
If you're managing a mix of platforms and want to automate version auditing across your fleet, the Netmiko/NAPALM/Nornir pattern covered earlier is the right starting point. And if you haven't locked down your management plane yet — SSH key auth, VTY ACLs, TACACS+ — our guide on Control Plane Policing on IOS-XE covers the hardening baseline that should sit alongside any major upgrade.
Keep your golden image list updated, pre-stage on your spares, and don't commit until you've verified traffic is healthy. The reload you prevent with ISSU is the one you'll thank yourself for at 3 AM.
Leave a Reply