Cisco IOS XE Install Mode: Upgrade and Rollback Guide

Since IOS XE 16.x, Catalyst switches manage software as installable packages rather than a single monolithic image. The model is better - atomic operations, rollback, and In-Service Software Upgrade on supported platforms - but only if you understand the three-step lifecycle. This is what each command does, what happens if you stop halfway, and how to recover.

The Three Steps

The critical property: until you commit, the switch keeps a rollback point. If the new software misbehaves after a reload, you can return to the previous version. After commit, that escape hatch is gone.

# 1. stage the new image
copy tftp://10.10.10.9/cat9k_iosxe.17.12.04.SPA.bin flash:
install add file flash:cat9k_iosxe.17.12.04.SPA.bin activate commit

# the combined form above is convenient but skips your review point.
# The explicit form is safer on production:
install add file flash:cat9k_iosxe.17.12.04.SPA.bin
show install summary
install activate
reload                      # activate takes effect on reload
install commit               # only after you have verified the new software

Install Modes: INSTALL vs BUNDLE

Switches can run in install mode or bundle mode. Bundle mode boots the single .bin directly, which is simpler but loses the install/activate/commit lifecycle and per-package management. Check with show version - the 'Installation mode' line tells you which one you are in - and convert deliberately:

show version | include Installation mode
show install summary
show boot
show bootvar

ISSU vs Cold Reload

In-Service Software Upgrade keeps forwarding during the upgrade, but only for specific source/destination release pairs on specific platforms. Do not assume that 'install activate' is hitless: on most Catalyst 9000 upgrades it still requires a reload and a data-plane interruption. Verify in the release notes for your exact version pair, and if you need hitless, plan the stack/redundancy behaviour as well (StackWise Virtual and dual-RP designs are what actually make it hitless).

Rollback

# before commit: return to the previous package set
install rollback to committed
reload

# or, once the new version is running but not committed:
install rollback to base
reload

Two rules make rollback actually available when you need it:

1. Do not commit until you have verified. Verify routing adjacencies, uplinks, PoE, AAA and anything else the site depends on - then commit.
2. Keep the old image in flash. Space is usually available; deleting it to 'save space' is what turns a rollback into a service call.

What Went Wrong? Reading the Install Log

show install log
show install summary
show install active
show install inactive
show platform software install-manager
show logging | include INSTALL

The common failure paths: an install add that ran out of flash (verify with dir flash: first - you need roughly 2x the image size free); an activation that was interrupted by a power event, leaving the switch in a mixed package state; and a version mismatch between the packages and the boot variable. All three are recoverable, but not by rebooting repeatedly - check show install summary and complete or roll back the transaction deliberately.

Pre-Change Checklist

• Back up: copy running-config startup-config plus an off-box copy of the configuration.
• Record show version, show boot, show install summary and dir flash: before you start.
• Verify the target image matches the platform and licence level.
• Confirm there is a maintenance window and a rollback plan that someone other than you can execute at 3 a.m.
• After the upgrade: verify spanning tree, uplinks, PoE budget and AAA before committing.

Related reading: IOS XR commit and rollback for the equivalent discipline on service-provider platforms, and Catalyst 9300 StackWise and VSS options when planning an upgrade that must not interrupt forwarding.

原文链接：https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iosxe_install/configuration/xe-16/iei-xe-16-book.html