Cisco IOS XE Install Mode Upgrade: add, activate, commit

Bundle mode boots one monolithic .bin and keeps the entire image in memory; install mode unpacks that same .bin into packages, boots faster, uses less RAM and - most importantly - gives you a rollback command. Every current Catalyst 9000 and IOS XE platform ships in install mode, and understanding install add / activate / commit is now a core operational skill. This guide covers the one-step upgrade, how to split it into three steps for a safer change window, how to roll back, and what to verify afterwards.

Bundle mode vs install mode

Before you start

show version | include Version|Install Mode|System Image
show bootvar
show install summary
dir bootflash: | include .bin
show flash: | include free
ping vrf Mgmt-vrf 10.10.50.10               ! server reachability
copy running-config startup-config

Check free space: install mode needs room for the .bin and the expanded packages. Confirm your boot variable points at packages.conf, not the .bin - booting an inactive package is the fastest way to a recovery situation. And always save the running configuration first.

One-step upgrade (the common case)

Switch# copy tftp://10.10.50.10/cat9k_iosxe.17.15.03.SPA.bin bootflash:
Switch# verify /md5 bootflash:cat9k_iosxe.17.15.03.SPA.bin

Switch# install add file bootflash:cat9k_iosxe.17.15.03.SPA.bin activate commit
# prompting:
#   Do you want to proceed? [y/n]  y
#   This operation may require a reload. Continue? [y/n] y

install_add_activate_commit: START
--- Starting Add --- Add: Passed on [1]
--- Starting Activate --- Activate: Passed on [1]
--- Starting Commit --- Commit: Passed on [1]
Finished Commit
SUCCESS: install_add_activate_commit

The device adds (copies and expands), activates (makes the image the running one, reloading the switch) and commits (makes it the boot image) in one command. In a stack, the operation runs on all members - give the console session a timeout that comfortably exceeds expected convergence, because the reload takes longer than a normal boot.

Three-step upgrade for a controlled window

Switch# install add file bootflash:cat9k_iosxe.17.15.03.SPA.bin
Switch# show install summary                  ! new image is Inactive
Switch# install activate                       ! reloads when you confirm
Switch# show install summary                  ! new image Active, old Committed
Switch# install commit                         ! make it persistent

# if something is wrong after activation:
Switch# install rollback to committed
Switch# install rollback to base

Splitting the operations gives you a review point between each: after add you can inspect the package set, after activate you can test for a defined period while the old image remains committed, and only then do you commit. This is the recommended pattern for production - the one-step form is convenient for labs.

Verify the upgrade

show version | include Version|Uptime
show install summary
show bootvar
show boot system
show platform software status control-processor brief
show interfaces counters errors
show ip bgp summary | include established
show etherchannel summary
show redundancy
show logging | include INSTALL|ROLLBACK

Check the version string, the boot variable, the committed state, and then the operational layer: interfaces up, protocols re-established, stack and redundancy healthy. Keep the previous image on bootflash until the next maintenance window has passed - it is your fastest rollback path.

Reading the install logs: what each phase actually does

The three verbs are worth understanding as three separate filesystem operations, because each one fails in a different way and leaves the device in a different state.

• add copies the .bin to bootflash, expands it into a set of .pkg files, writes a new packages.conf and records the new image as Inactive. Nothing about the running system changes, so an add failure is harmless — the device keeps booting exactly the image it booted before. Almost every add failure is free space, an MD5 mismatch, or a signature the platform rejects.
• activate builds a packages.conf from the added packages, points the next boot at it and reloads the device. This is the phase where traffic drops, so it belongs at the start of a maintenance window rather than in the last ten minutes of one.
• commit marks the active image as the committed boot image. Until you commit, the previous release is still the committed one and install rollback to committed is a single command away. Committing removes that safety net.

That asymmetry is the whole reason the three-step form exists. After add you can walk away and think about it. After activate you are running the new code but still have a guaranteed exit. commit is a deliberate, separate decision made once you have tested.

Choosing the image and avoiding the compatibility traps

show version | include ROM|Version|System Image
show romvar
show platform
show license summary
show bootvar

Three things bite people at this step, and none of them are about the install command itself.

First, use the Cisco-recommended release for the platform rather than simply the newest image in a train. The recommended release is the one that has been field-tested long enough for the worst early defects to have surfaced; the newest build in a train is where those defects are still being discovered. Read the open caveats in the release notes before you copy anything, and write down the ones that affect features you actually run.

Second, check the ROMMON and CPLD/FPGA versions the release expects. IOS XE upgrades frequently require a ROMMON upgrade first, and the install operation will warn or outright refuse when the low-level firmware is behind what the packages expect. Many platforms stage ROMMON automatically as part of install add ... activate commit, but only when the new image contains a ROMMON payload and the platform supports a field upgrade. Confirm rather than assume.

Third, check the licensing state before and after. Moving images can leave a device in "Eval mode" or reporting out of compliance until it re-registers with CSSM or your on-premises Smart Software Manager. A device past its evaluation can keep forwarding traffic while quietly refusing new features, which is an unpleasant thing to find a week later.

Stacks, StackWise Virtual and ISSU

How long the outage lasts depends less on the image than on the platform architecture.

In a fixed stack (StackWise-480 and similar), the install operation runs across every member and all of them reload together. The whole stack is down for the duration of a boot — typically eight to fifteen minutes on a busy Catalyst 9000 — and nothing forwards during that time. Plan a full service window, confirm the stack is healthy before you start, and check stack ports and member state so that you are not debugging an unrelated split-stack on top of an upgrade.

show switch
show switch detail
show switch stack-ports summary
show redundancy
show redundancy history | include switchover

On a StackWise Virtual pair, or on a chassis with dual supervisors, the story is different. Members reload one at a time, the control plane stays up across the pair, and forwarding continues with a short blip rather than a full outage. That is the pattern to reach for when a change window genuinely cannot afford a full service interruption. It does depend on a healthy redundancy state before you begin: if the standby has been out of sync, or the switchover history shows recent unplanned failovers, fix that first. An upgrade window is the worst possible time to discover that the standby was never ready to take over.

When the upgrade fails: the failure modes you will actually see

show install log
show install log detail
show logging | include %INSTALL|%BOOT|%SIGNATURE|%PLATFORM|%PKG
dir bootflash: | include .bin
show boot system

• Insufficient space. Install mode needs the original .bin and the expanded packages at the same time. On a single-supervisor chassis with modest bootflash, clear out old .bin files and stale package directories before you start copying, and re-check free space after the copy rather than trusting the pre-copy figure.
• Signature or integrity failure. Usually a truncated transfer or a file for the wrong platform. Re-verify with verify /md5 against the value published on the download page; never trust the transfer's own success message, because TFTP in particular will report completion on a truncated file.
• Boot variable left pointing at the .bin. The device comes up in bundle mode and the packages you just installed are simply not used. Correct the boot variable before the reload, not after — this is the most common way a routine upgrade turns into an unplanned recovery.
• Activation succeeded but the application is broken. Almost always a configuration or feature change in the new train, not a failure of the install mechanism. That is what the review window before commit exists for: test routing adjacencies, AAA, management reachability and every protocol you depend on while the old release is still the committed one.

Automating the upgrade window

event manager applet PRE_UPGRADE
 event none
 action 001 cli command "enable"
 action 002 cli command "copy running-config startup-config"
 action 003 cli command "copy running-config bootflash:pre-upgrade.cfg"
 action 004 cli command "show install summary"
 action 005 cli command "show ip interface brief"
 action 006 syslog msg "Pre-upgrade snapshot saved"
!

Whatever you script, the non-negotiable part is the pre-upgrade snapshot: running-config saved to startup and to a dated file on bootflash, plus the text output of show version, show install summary, show bootvar, show ip route summary and interface counters. That snapshot is what lets you prove afterwards that a missing route or a flapping interface was already like that before the change, instead of relitigating it during the incident call.

Everything else — image transfer, MD5 verification, the ordering of add, activate and commit, and the post-checks — can be driven from network automation tooling. The goal is a repeatable runbook that produces the same evidence every time, not a clever one-off command that only its author understands. Whatever tooling you use, redirect the entire console session to a file: every credible post-mortem of a failed upgrade is built from the console log, and that log disappears the moment someone closes the terminal window.

Rollback strategy and keeping a fallback

show install summary            ! note the Committed and Active releases
install rollback to committed   ! revert to the previously committed release
install rollback to base        ! revert to the shipped / factory image
install remove inactive         ! reclaim space by deleting inactive packages

Two rules turn rollback from a theoretical option into a real one.

Keep the previous image on bootflash until at least one full maintenance cycle has passed. Running install remove inactive to clean up space during the change window destroys your cheapest exit route, and the irony is that the space it frees is exactly the space a rollback would need.

Decide the rollback criteria before the window opens: which services must be up, how long you will wait for them, and who has the authority to call the revert. Teams that skip this end up making those decisions at 2 a.m. under pressure, which is how a thirty-minute upgrade becomes a multi-hour outage and an argument the next morning about whether rolling back was the right call.

Frequently asked questions

Can I copy the image from a USB drive? Yes. copy usbflash0:cat9k_iosxe.17.15.03.SPA.bin bootflash: works and is often the fastest option at sites with poor WAN throughput or a slow TFTP server. Verify the MD5 either way; the transport does not change the integrity requirement.

Do I need to reload twice? No. That is bundle-mode thinking carried over. In install mode the reload is part of activate, and the commit afterwards is a bookkeeping change, not a boot event.

What if the switch does not come back after activate? Get into ROMMON and point the boot variable at the previous packages.conf, or once you have CLI access use install rollback to committed. This is exactly the scenario the boot-loop recovery procedure covers, and it is why you keep the old image on flash.

Can I upgrade with no outage at all? Only on a platform with real supervisor redundancy. On a fixed stack there is no zero-outage path; the honest answer is a short maintenance window, not a clever workaround.

Related reading: recovering from a boot loop on IOS XR, NX-OS checkpoint and rollback, IOS XR commit replace and Junos software upgrade.

原文链接：https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9500-series-switches/224890-change-between-bundle-install-mode-on.html