Cisco IOS XE Upgrade Guide for Switches and Routers
No single command sequence upgrades every IOS XE device safely. Establish the exact platform, current release, operating mode, boot mode, redundancy design, target release, and firmware path first. Catalyst 9000 switches and Catalyst 8000 Edge routers both accept the install add, install activate, and install commit workflow, but their prerequisites, recovery paths, and low-downtime options are not interchangeable.
Upgrades get scheduled for one of five reasons — security fixes, defect correction, new hardware or feature support, lifecycle planning, or management-platform compatibility. Each points at a different target, and the right release is the one that satisfies the actual requirement for that exact device. The newest available image rarely is.
Two procedures are worked end to end below: a Catalyst 9300 switch in Install Mode on IOS XE 16.6.2 or later, standalone or in a healthy StackWise stack, and an autonomous Catalyst 8000 Edge router in Install Mode. Everything else — ISR 4000, ISR 1000, ASR 1000, Catalyst SD-WAN, Bundle Mode, redundant chassis — gets its divergence points named so you know where to stop copying. Classic Cisco IOS, NX-OS, IOS XR, and the full controller-managed SD-WAN command set are out of scope.
| Device state | Correct starting point |
|---|---|
| C9300 in Install Mode on IOS XE 16.6.2 or later | The Catalyst 9300 procedure below |
| C9200/C9400/C9500/C9600 | The shared planning checks, then that platform’s target release notes |
| C8200/C8300/C8500/C8500L/C8000V in autonomous Install Mode | The Catalyst 8000 Edge procedure below |
| Catalyst 8000 Edge on IOS XE 17.6 or earlier | Confirm the documented Bundle Mode or conversion path first |
| ISR 4000 or ISR 1000 | The router-family release notes and install guide; intermediate-release rules may apply |
| ASR 1000 | Select by route processor, chassis redundancy, and consolidated or subpackage mode |
| Controller-managed Catalyst SD-WAN edge | Cisco SD-WAN Manager and the release-pair guidance, not this autonomous CLI procedure |
Which Platforms This Guide Covers
One Operating System, Several Upgrade Procedures
IOS XE runs on current Catalyst campus switches and on several enterprise routing families, which makes the product name a poor guide to the procedure. Hardware, release train, package mode, redundancy design, firmware level, and management mode all move the answer.
The planning sections apply to Catalyst 9000 switches, Catalyst 8000 Edge routers, ISR 4000 and ISR 1000, ASR 1000, C8000V, and Catalyst SD-WAN edges. The command examples are deliberately narrower, because a worked example that tries to cover six families ends up safe on none of them.
One boundary is worth stating plainly. Older switches and routers whose software is casually called “Cisco IOS” do not run this workflow at all: packages.conf, install add, and IOS XE package states have no meaning there. NX-OS and IOS XR use different image, validation, and recovery models again.
Establish the Model, Release, and Operating Mode
Start with the complete product ID. A family nickname will not survive the first compatibility check. “Catalyst 8000” covers the C8200, C8300, C8500, C8500L, and virtual C8000V, and those platforms do not handle ROMMON the same way. “Catalyst 9000” covers a fixed access switch, a StackWise stack, a StackWise Virtual pair, and a modular chassis with redundant supervisors. Where the hardware choice is still open, the Catalyst 9000 series guide maps the switch families before you build a software plan.
Collect these facts before downloading anything:
| Fact | Typical command or source | Why it changes the procedure |
|---|---|---|
| Exact PID and installed hardware | show inventory, show version | Defines image, release, ROMMON, module, and memory support |
| Current IOS XE release | show version | Sets the command family, and whether an intermediate release is mandatory |
| Autonomous or controller-managed router | show version plus management inventory | A Catalyst SD-WAN edge belongs in the controller workflow |
| Install or Bundle Mode | show version, show boot | Decides whether the device boots packages.conf or a consolidated .bin |
| Current install state | show install summary where supported | An unfinished transaction has to be resolved before another one starts |
| Stack, supervisor, or route-processor state | show switch, show redundancy, platform HA commands | Governs outage behaviour and ISSU eligibility |
| ROMMON, FPGA, and CPLD state | Platform release notes, ROMMON command | May add a firmware step, or rule out the direct path |
| Storage and recovery images | dir flash: or dir bootflash: | Determines whether staging costs you the fallback |
The pattern across those rows is that none of them are answered by the model name on the faceplate. Two switches with identical labels take different commands when they start from different releases, and a stack behaves differently from a standalone unit at almost every step below.
Record the Whole Topology
For a switch stack, capture every member: role, priority, software state, and flash filesystem. For a chassis or StackWise Virtual pair, confirm supervisor and redundancy health before anything else. For a router, identify the route processors, interface modules, WAN transports, virtual routing instances, and any encrypted or voice service that has to come back after the reload.
Then separate an autonomous router from a controller-managed Catalyst SD-WAN edge. A controller-managed edge has to stay compatible with its SD-WAN Manager and controller release pair, so upgrading it as an isolated CLI device puts it outside the supported matrix even when the upgrade itself succeeds.
Stop before staging if the PID is uncertain, a stack member or standby control plane is unhealthy, the management mode is unclear, or an install transaction is still open. An upgrade is an expensive way to discover what platform you actually have.
Choosing the Upgrade Method
Install Mode vs Bundle Mode
Bundle Mode boots a consolidated .bin file. Install Mode expands that image into packages and boots from a local packages.conf. Both appear on switches and enterprise routers, and the supported conversion path between them depends on platform and starting release.
Cisco recommends Install Mode on supported modern platforms, and the reasons are practical: package validation, distinct activation and commit states, retained rollback points, and software maintenance packages. What it does not give you is a universal command set. C9300, Catalyst 8000 Edge, ISR 4000, and ASR 1000 documentation each draw their own release and hardware boundaries around the same verbs.
Catalyst 8000 Edge platforms ship in Install Mode by default from IOS XE 17.7.1a, and Cisco recommends Install Mode from the 17.7 train onward; a system coming from 17.6 or earlier should follow the documented Bundle Mode path before conversion. On Catalyst 9000, the starting release and switch family decide whether install or the older request platform software commands apply.
One-Step or Three-Step Install
The one-step form adds, activates, and commits in a single operation:
install add file <filesystem>:<image.bin> activate commit
The three-step form separates staging, activation, validation, and commit:
install add file <filesystem>:<image.bin>
install activate auto-abort-timer 120
install commit
| Workflow | Main advantage | Main tradeoff |
|---|---|---|
| One-step | Fewer operator actions, persistent result after one reload | Commits before application and service acceptance can finish |
| Three-step | Preserves an explicit validation window before commit | Needs active monitoring and a commit-or-abort decision before the timer expires |
The choice is really about where acceptance lives. Automated fleet rollouts with standardised post-checks have their acceptance criteria outside the CLI session, so the one-step form costs them nothing. A single branch router carrying live tunnels has its acceptance in the hands of whoever is watching traffic, and collapsing the workflow removes the moment where that person can still say no. Use only the command form documented for your exact platform and starting release; the examples here are not evidence that every IOS XE device shares the syntax.
Where ISSU and xFSU Actually Apply
ISSU is not a universal IOS XE feature, and the opposite claim — that IOS XE routers cannot do it — is equally wrong. Eligibility turns on platform, redundancy, operating mode, configuration, and the specific source-and-target release pair.
| Platform and topology | Option to investigate | Boundary check that decides it |
|---|---|---|
| Supported C9400/C9500/C9600 redundant design | ISSU | Eligible release pair, Install Mode, supported supervisors, healthy HA state |
| Supported C9300 access deployment | xFSU | Target-train feature availability, topology, configuration eligibility |
| Supported redundant ASR 1000 chassis | ASR-specific ISSU | Supported chassis, route processors, software mode, release-pair matrix |
| C8200/C8300/C8500 with no documented hitless path | Maintenance reload | Planned service impact and verified WAN recovery |
Read that table as a set of hurdles. Every row makes the fast path conditional on something an ordinary campus or branch network breaks routinely, so the number that belongs in the change record is the one that assumes a full reload. Redundant hardware on its own proves nothing here, least of all where traffic still depends on a single forwarding path.
Choosing the Target Release
Recommended Releases, With the Date Attached
Use Cisco’s recommendation page for the product family, then confirm the release on the Software Download page for the exact PID. What follows is a dated snapshot, verified 18 August 2026.
| Platform family | Cisco recommendation snapshot | Source date |
|---|---|---|
| Listed Catalyst 9200/9300/9400/9500/9600 variants | IOS XE 17.15.5 | Switching recommendation current as of April 2026 |
| Catalyst 8200/8200L/8300/8500/8500L/8000V | IOS XE 17.12.7b or 17.15.5, depending on features | Enterprise-routing recommendation updated 15 June 2026 |
| ASR 1000 with RP3 | IOS XE 17.15.5 | 15 June 2026 |
| ASR 1000 with RP2 | IOS XE 17.9.8; 17.9 is the final train for the listed RP2-era platforms | 15 June 2026 |
| ISR 4461 | IOS XE 17.12.6 or 17.15.4c | 15 June 2026 |
| ISR 4200/4300/4431/4451 | IOS XE 17.9.8 or 17.12.7b | 15 June 2026 |
| ISR 1100 | IOS XE 17.12.7b or 17.15.5 | 15 June 2026 |
Those figures come from Cisco’s recommended Catalyst 9000 releases and stable releases for enterprise routing platforms, and both pages move. Copy the date into your change record alongside the version, because a recommendation with no date attached is the reason someone eventually upgrades to a release that stopped being recommended eight months ago.
A recommended release can still be the wrong release. An open caveat, a missing feature, an unsupported module, a management-system dependency, or a hardware PID newer than the image will each override the recommendation, and the model-specific download page and target release notes settle it. Note also that Cisco calls its longer-lived trains Extended-Support releases; “LTS” is not Cisco’s term and does not appear in the documentation you will be quoting. Where lifecycle enters the decision, the IOS XE lifecycle tool locates the published records, though it answers no compatibility question.
When an Intermediate Release Is Mandatory
A direct path on one IOS XE device proves nothing about the next one. The target release notes for that exact platform, starting version, image mode, module set, and control-plane design are the only place this gets settled, and current examples show how far apart the answers sit.
The Catalyst 9400 17.15.x release notes send a chassis starting on 16.6.1 to 16.6.3 first, and warn against upgrading dual supervisors simultaneously from that release because hardware damage may result. On the router side, Cisco does not recommend a direct Bundle Mode upgrade to 17.15.x or 17.18.x on a C8200 or C8200L whose ROMMON sits below 17.6(8.1r), offering instead an intermediate 17.12.5-or-later rebuild or a manual ROMMON update, with a different automatic path in Install Mode. A C8300 below the ROMMON minimum for those trains goes through 17.12.5 or later for the same reason. An ISR 1100 on 17.4 or earlier has to reach something in the 17.5 to 17.10 range before 17.11 or later becomes available.
Treat the intermediate release as part of the upgrade. It brings its own image transfer, reload, validation window, and recovery plan, and a change record that budgets for one reload when the path needs two is the most common way this work overruns.
ROMMON and Bootloader Are a Separate Question
Software and platform firmware move independently, and C8200/C8200L, C8300, C8500, C8500L, Catalyst 9000, ISR, and ASR platforms share no single automatic-ROMMON rule.
On Catalyst 8200 and 8300, the required behaviour shifts with model, starting ROMMON, target train, and Install or Bundle Mode. Catalyst 8500 downloads and installs ROMMON separately, so the IOS XE image never updates it, and some versions cannot be downgraded once applied. Catalyst 8500L integrates ROMMON with the IOS XE bundle, while keeping minimum and recommended versions specific to model and release. Catalyst 9000 bootloader behaviour depends on switch family and hardware revision, and a later bootloader can remain in place after an IOS XE downgrade.
Read the target release notes for ROMMON, CPLD, FPGA, microcode, memory, and hardware-revision requirements before approving the path. A successful IOS XE boot is not evidence that every firmware component reached the version the plan assumed.
Hardware, Licensing, and Cryptography Compatibility
Check that the target release still supports what makes the device useful, not just what makes it boot: supervisors and route processors, interface and service modules, and the services running across them.
Two of these bite harder than the rest. Some enterprise routers moving to IOS XE 17.11.1a or later carry an older PAK license with no recorded snapshot, and completing the license conversion needs an intermediate 17.6.x or 17.9.x release; verify the device’s actual licensing state before assuming Smart Licensing has already tidied it. The Catalyst 8000 Edge upgrade guide also flags the removal of weak cryptographic options beginning at 17.11.1a. Audit the algorithms genuinely in use before upgrading a router carrying IPsec, DMVPN, GETVPN, legacy SSH, or partner VPNs. A router that boots cleanly and can no longer negotiate its tunnels has failed the change as completely as one that never came back.
Preparing the Change
Back Up the Configuration and Baseline the Network
Save the running configuration and copy it to an external system. A local copy on the same boot device helps during recovery and is not a backup.
Capture a baseline matched to the device’s role, because the evidence you need at 2 a.m. is whatever proves the network looked different an hour earlier.
| Area | Catalyst switch baseline | IOS XE router baseline |
|---|---|---|
| Software | IOS XE, ROMMON, boot variable, install state | IOS XE, ROMMON/CPLD/FPGA as applicable, boot variable, install state |
| Hardware | Stack members, supervisors, line cards, power supplies | Route processors, ESPs, interface modules, memory, VM resources |
| Interfaces | Uplinks, trunks, port-channels, access ports, PoE | WAN/LAN interfaces, subinterfaces, port-channels, tunnels |
| Control plane | STP, routing neighbours, FHRP | BGP/OSPF/EIGRP, VRFs, FHRP, route counts |
| Services | AAA, DHCP snooping, telemetry, management | NAT, IPsec/DMVPN, CUBE/voice, application visibility, AAA, telemetry |
| Acceptance | Critical endpoint and application tests | WAN reachability, tunnel establishment, convergence, branch application tests |
Name two people while you are still writing the plan: whoever can approve the commit, and whoever can order the rollback. The first has to be watching business traffic during the uncommitted period, which is a different job from being reachable once the timer has nearly run out.
Verify the Image Before You Trust It
Download the image for the exact PID and compare it with the checksum Cisco publishes beside it, using the storage prefix the device actually reports:
copy tftp://<server>/<target-image.bin> flash:
verify /md5 flash:<target-image.bin>
or, on a router using bootflash::
copy tftp://<server>/<target-image.bin> bootflash:
verify /md5 bootflash:<target-image.bin>
Where Cisco publishes a different algorithm for the file you selected, match the verification method to it. Confirm both file size and checksum before touching install or boot state.
Calculate Storage, Then Decide About Cleanup
Work the space requirement from the real numbers: the image itself, the expanded packages, the packages already installed, crash files, and the recovery assets you intend to keep. There is no universal figure, and a standalone switch, a multi-member stack, a hardware router, and a virtual router can each answer differently on filesystems that are not even named the same way.
install remove inactive deserves a deliberate decision. It previews the files it will delete, and those files are frequently the rollback path someone assumed was still there. Read the proposed deletion list against the installation points you plan to keep, approve it explicitly, and verify the destination on every affected member before running it.
Console Access and Window Length
Test console or out-of-band access before the window opens. The window itself has to cover image processing, at least one reload, validation, and a second reload if rollback is called, which is roughly double what teams usually book.
For a remote branch router the arithmetic gets sharper, because the WAN path that fails is often the management path you would use to diagnose it. Document the old boot target, recovery image location, console procedure, rollback decision point, auto-abort timer, and escalation contact. If your access depends on the same uplink or tunnel being upgraded, you have a plan with no recovery path in it.
Re-Check Platform Health Immediately Before Staging
Repeat the health checks right before the image goes on. Confirm that every expected stack member, supervisor, route processor, line card, and interface module is present and stable, review show install summary where the platform supports it, and clear any active or unexpected install transaction before starting a new one.
Compare what you see against the baseline you captured. A missing stack member, a failed standby supervisor, an unstable adjacency, or a pre-existing crash is a fault in its own right, and folding it into a software change means you will spend the window debugging two problems while believing you have one.
Worked Example: Catalyst 9300 in Install Mode
Scope and Prerequisites
This procedure covers the C9300 family already running Install Mode, starting on IOS XE 16.6.2 or later, standalone or in a healthy StackWise stack. Other Catalyst 9000 families use their own target release notes. It follows Cisco’s Catalyst 9300 upgrade guide and Catalyst 9000 Install Mode reference, and it is derived from Cisco’s documentation.
Confirm before continuing that every stack member is ready, the target image is valid for the exact PID, the switch boots from flash:packages.conf, and the starting release supports the install family used below.
Step 1: Copy and Verify the Image
copy tftp://<server>/<cat9k-image.bin> flash:
dir flash:<cat9k-image.bin>
verify /md5 flash:<cat9k-image.bin>
Expected result: the image is present in flash and its checksum matches Cisco’s published value for that exact platform image.
Step 2: Verify Boot Settings
show boot
show install summary
Expected result: the switch boots from flash:packages.conf, manual boot is disabled, and no unexpected transaction is active.
Where the saved settings need correcting, use the documented sequence:
configure terminal
no boot system
boot system flash:packages.conf
no boot manual
end
write memory
show boot
Never hand-edit packages.conf or point the boot variable at an inactive package set.
Step 3: Add the Image
install add file flash:<cat9k-image.bin>
show install summary
Expected result: the image passes compatibility checks and appears as inactive (I) beside the current committed (C) image.
Stop if: the add fails on any member, the image is missing from the summary, or a member enters an unexpected software state. Where the source image sits on a member rather than the active switch, name that filesystem explicitly, such as flash-3:.
Step 4: Activate with an Auto-Abort Timer
install activate auto-abort-timer 120
Activation reloads the switch or stack. After reconnecting:
show version
show install summary
show switch
Expected result: the target release is running, the new image shows as activated and uncommitted (U), the timer is counting, and every expected member has returned in the correct role.
The uncommitted period is the only part of this procedure that behaves like a safety net — and it is worth exactly as much as the validation plan you are ready to run inside it. Settle before the window opens which tests must pass and who is authorised to commit.
The One-Step Form
Cisco also documents the combined command:
install add file flash:<cat9k-image.bin> activate commit
Reserve it for rollouts with an external, standardised acceptance and remediation process. It commits during the operation, which removes the manual go/no-go point the split workflow exists to provide.
Bundle Mode and StackWise Notes
Bundle Mode boots the consolidated .bin rather than packages.conf, with its own boot-variable and reload procedure, and the image has to reach every affected stack member. Mixing its instructions into the Install Mode package workflow above produces a switch that boots something nobody planned.
Older C9300 starting releases may also require request platform software commands instead of install. For a stack, verify source filesystem, free space, image distribution, member health, and post-reload role state on every member, and follow the target release documentation directly when the starting release predates the scope of this example.
Worked Example: Catalyst 8000 Edge Router in Install Mode
Scope and ROMMON Requirements
This procedure covers an autonomous-mode C8200, C8200L, C8300, C8500, C8500L, or C8000V using Install Mode. Check the platform’s ROMMON table and target release notes before running any of it; a controller-managed Catalyst SD-WAN edge follows a different workflow entirely.
show inventory
show version
show install summary
dir bootflash:
On a physical platform that exposes hardware ROMMON, add:
show rom-monitor r0
C8000V is virtual and has different prerequisites again. Compare the physical platform’s result against Cisco’s current ROMMON matrix; an automatic update cannot be assumed, since C8200/C8300, C8500, and C8500L each behave differently.
Confirm that the router runs autonomous IOS XE, boots through Install Mode, has sufficient bootflash: capacity, and carries no uncommitted transaction. Verify too that the target release supports every installed NIM, service module, interface, license-dependent feature, and management platform.
Step 1: Copy and Verify the Image
copy tftp://<server>/<c8000-image.bin> bootflash:
dir bootflash:<c8000-image.bin>
verify /md5 bootflash:<c8000-image.bin>
Expected result: the image is present in bootflash: with a checksum matching Cisco’s published value.
Step 2: Add the Image
install add file bootflash:<c8000-image.bin>
show install summary
Expected result: platform validation succeeds and the new image appears as inactive.
Stop if: the ROMMON requirement is unresolved, the image belongs to another platform, validation fails, or the install state differs from the expected inactive-and-committed pair.
Step 3: Activate with an Auto-Abort Timer
install activate auto-abort-timer 120
The router reloads. Reconnect over the tested path, then:
show version
show install summary
On applicable physical platforms, re-run show rom-monitor r0 as a separate firmware check.
Expected result: the target release is running, the image is activated and uncommitted, the timer is counting, and any ROMMON reading matches the planned behaviour for that platform. On C8500 the ROMMON package is a separate operation, so the IOS XE version alone says nothing about whether the firmware step succeeded.
Converting from Bundle Mode
For a Catalyst 8000 Edge device still in Bundle Mode, Cisco’s current guide requires the one-step form for the initial conversion:
install add file bootflash:<c8000-image.bin> activate commit
That conversion commits as part of the workflow, so confirm the documented starting-release path, ROMMON requirements, boot storage, recovery method, and exact image before running it. Later Install Mode upgrades can use either variant.
Where ISR, ASR, and SD-WAN Diverge
ISR 4000 and ISR 1000
Cisco’s ISR 4000 install-command guide records that install commands arrived in IOS XE 16.6.2 and that the older request platform software workflows were deprecated from 16.10.1. Shared verbs are not a shared procedure: the exact ISR model, starting release, package mode, ROMMON and CPLD requirements, voice and interface modules, licensing state, and target release notes all still shape the plan.
ISR 1000 carries its own intermediate-release rule, sending a C11xx on 17.4 or earlier through something in the 17.5 to 17.10 range before 17.11 or later. Older IOS-only ISR generations sit outside this guide entirely, and applying an IOS XE package workflow to a classic IOS router will not end well.
ASR 1000 and ISSU
Cisco documents ISSU for supported redundant ASR 1000 configurations, including eligible ASR 1006, ASR 1006-X, ASR 1009-X, and ASR 1013 designs. Nonredundant ASR 1001 and 1002-class platforms behave differently and need a service-impacting plan.
Beyond that, ASR procedures vary by route processor, chassis redundancy, consolidated or subpackage mode, release pair, and the ISSU compatibility matrix. Work from Cisco’s ASR 1000 software-upgrade process guide ; neither worked example above adapts cleanly.
Catalyst SD-WAN Edges and C8000V
For a controller-managed WAN edge, validate the release pair against Cisco’s recommended Catalyst SD-WAN software versions and drive the upgrade from SD-WAN Manager. Device image, controller compatibility, orchestration order, and rollback behaviour form one coordinated change, and an autonomous CLI upgrade can leave the edge outside the supported controller matrix while looking entirely healthy from the console.
C8000V accepts the same add, activate, and commit model, but hypervisor version, virtual disk layout, available resources, cloud marketplace image, and migration restrictions take the place of ROMMON checks. Plan it as its own deployment type, with its own prerequisites.
Validating the Upgrade and Committing It
What show version Does Not Tell You
show version confirms which image booted. It says nothing about whether a campus network, WAN edge, VPN service, or voice gateway is working, which is the question the commit decision actually turns on.
| Check | Catalyst switch | IOS XE router | Pass condition before commit |
|---|---|---|---|
| Software and install state | show version, show install summary | Same | Exact target running and uncommitted; timer state understood |
| Boot state | show boot | Platform boot-variable check | Intended Install Mode provisioning file will persist |
| Hardware | show switch, show redundancy | show platform, show redundancy where applicable | Every expected member, RP, module, and interface healthy |
| Interfaces | Uplinks, trunks, port-channels, critical access ports | WAN/LAN links, subinterfaces, tunnels, port-channels | Matches the pre-upgrade baseline |
| Control plane | STP, routing adjacencies, FHRP | Route count, BGP/OSPF/EIGRP, VRFs, FHRP | Expected topology and routes reconverged |
| Services | PoE, AAA, DHCP and security features | NAT, IPsec/DMVPN, voice/CUBE, AAA as applicable | Critical services pass their defined tests |
| Management | SSH, SNMP, telemetry, controller reachability | Same | Out-of-band and production monitoring recovered |
| Stability | Logs, uptime, reload reason, crash files | Same | No new crash or repeating fault |
The right-hand column is the working logic here. Anything that would justify returning to the old image belongs before the commit; anything you would fix forward belongs after it. Filing a check in the wrong column is how teams end up committed to a release they never actually accepted.
Switch-Side Checks
On a standalone switch, confirm the intended uplinks, port-channels, trunks, VLANs, STP state, routing neighbours, FHRP state, critical access ports, and management access. On a stack, verify that every expected member returned with the right role and software state.
Then test something a user would notice. Healthy uplinks say nothing about whether a phone drew power or a badge reader authenticated, and those are the failures that generate tickets after the window closes.
Router-Side Checks
Push real traffic across every critical WAN transport and VRF, then compare interface state, route counts, adjacencies, FHRP, NAT, policy routing, QoS, and application paths against the baseline. Confirm that IPsec, DMVPN, GETVPN, and partner tunnels renegotiate with their peers, which matters most on any path crossing the 17.11.1a cryptography changes. Validate voice and CUBE services where they are deployed.
Licensing and Management Systems
Confirm that licensing state, SSH, AAA, SNMP, telemetry, logging, configuration management, and controller reachability have all come back. A device forwarding traffic while invisible to its management systems is not ready for commit.
The Cisco Smart Licensing guide helps separate registration, authorisation, and reporting states when something returns looking wrong. Release-specific PAK migration requirements are a different matter, and they belong to the planning stage.
Commit
For the three-step workflow:
install commit
show install summary
Expected result: the new image shows as activated and committed (C), and the auto-abort timer is inactive.
Commit makes the package set persistent and ends automatic rollback for that transaction. Save any approved configuration changes, confirm the boot state will survive another reload, and record the running release, install state, validation results, approver, and completion time while they are still in front of you.
Rollback and Downgrade
Before Commit: install abort
When validation fails while the image is activated and uncommitted:
show install summary
install abort
On the two workflows scoped above, install abort terminates the activation and reloads to the last committed software state. The auto-abort timer reaches the same outcome unattended, which makes an uncommitted switch left overnight a decision handed to a countdown. Confirm the prior files and install state are intact before running it, and keep time in the window to validate the old release after the second reload.
Where validation is simply running long on an otherwise stable release, install auto-abort-timer stop halts the countdown while leaving the image uncommitted. That buys time and settles nothing; a commit-or-abort decision is still owed.
After Commit: Rollback Points
For Catalyst 9000, Cisco demonstrates listing the retained installation points, inspecting the target, and selecting it by ID:
show install rollback
show install rollback id <id>
install rollback to id <id>
For Catalyst 8000 Edge, the Install Mode documentation covers rollback to the last committed state alongside saved installation targets:
show install rollback
install rollback to committed
These are platform syntaxes, not interchangeable universals. Verify the displayed target, exact command form, retained packages, and reload impact in that release’s documentation before executing. Where no valid installation point survives, the path is a planned downgrade carrying the same image, compatibility, firmware, storage, and validation controls as the upgrade did.
What a Downgrade Does Not Undo
Cleanup may already have removed the inactive files a rollback needed. Firmware is the other half of the problem: ROMMON, FPGA, CPLD, or microcode can stay at the newer level after the software goes back. Cisco’s C9300 17.15.x release notes state that C9300 ROMMON does not automatically downgrade with IOS XE, and the Catalyst 8000 guide identifies C8500 ROMMON versions that cannot be downgraded at all. Treat software rollback and firmware rollback as two questions with two answers.
When the Device Will Not Boot
Use the tested console path and capture the complete boot output before changing a single file or boot variable. The cause is usually on a short list — an invalid boot target, a missing or damaged packages.conf, an incomplete package state, an unreadable image, a firmware incompatibility, or genuine hardware failure. Reloading repeatedly diagnoses none of them and burns the window that still held evidence.
Move to the platform recovery procedure or Cisco TAC once the device enters ROMMON, boot-loops, loses package integrity, cannot restore its stack or control-plane state, or shows a firmware condition the documentation does not describe. Deleting package files or rewriting packages.conf during recovery is a step the platform procedure has to authorise.
Common Upgrade Failures
Insufficient Flash or Bootflash Space
An image can copy successfully and still leave too little room for package expansion. Check the real destination filesystem, the expansion requirement, current installation points, crash files, and recovery assets, and do it on every stack member. Treating install remove inactive as harmless preparation is what turns a space problem into a rollback problem.
Invalid Image, Checksum, or Platform Mismatch
Recheck the full PID, filename, file size, checksum, download source, and target release notes. A filename that resembles another Catalyst or ISR image proves nothing about compatibility. When install add rejects an image, keep the output and resolve what it reported; pointing the boot variable at the rejected file to get past validation is how a maintenance window becomes an RMA.
packages.conf and Boot Variable Errors
An Install Mode device should boot the provisioning file the supported install process created, normally packages.conf, and a Bundle Mode device boots the consolidated .bin. Verify the current mode and saved boot settings with the platform command before reload, and leave packages.conf alone.
Stack Member and Install-State Mismatches
Do not activate while a stack member, standby supervisor, route processor, or required module is missing or unstable, and resolve any unfinished transaction before starting another. Where an image lives on a member rather than the active switch, name that member’s filesystem exactly, such as flash-3:, when the platform documentation calls for it.
ROMMON and Intermediate-Release Errors
An unmet ROMMON minimum or a mandatory intermediate release is a path-design problem, and retrying the same command will not resolve it. Stop, rebuild the sequence from the current software and firmware versions, and put each intermediate image, firmware action, reload, validation point, and downgrade restriction into the rollback plan alongside it.
Post-Upgrade Routing, VPN, and Connectivity Faults
Diagnose the failing service against the pre-upgrade baseline. Work through interface state, routes, adjacencies, VRFs, NAT, VPN negotiation, cryptographic algorithms, voice services, AAA, licensing, and management reachability. When a critical acceptance test fails inside the uncommitted window, take the approved abort rather than committing to buy troubleshooting time, because committing converts a reversible problem into a project.
Upgrade Checklist
Before the window. Confirm exact PIDs, operating mode, boot mode, topology, current release, and target release. Verify the image, any intermediate releases, ROMMON/CPLD/FPGA requirements, hardware support, licensing, cryptography, and management compatibility. Collect external backups and a role-specific baseline. Confirm checksum, storage capacity, rollback files, console access, window length, acceptance owner, and abort criteria. Check that every member, supervisor, route processor, and required module is healthy with no unresolved install transaction.
During activation and reload. Watch the console and capture install, reload, and boot messages. Track the auto-abort deadline and keep the commit-or-abort owner available. Confirm the target image and expected install state once the device returns. Stop if a member, supervisor, route processor, firmware component, or critical interface fails to recover as planned.
After the upgrade. Compare hardware, interfaces, routing, VPN, voice, access services, management, licensing, logs, and real application traffic against the baseline. Commit only once every acceptance criterion passes and the named owner approves. Confirm the install state is committed, boot state persistent, monitoring healthy, and no new or repeating fault present. Save the final configuration and new baseline, update the change record, and assign someone to watch the device afterwards.
Where the release you need cannot support the installed hardware, modules, licensing model, or security requirements, no further software command will fix it. The Cisco switch EOL migration guide and the Cisco router selection guide cover the replacement path from there.
