Cisco Real World Problems

How to upgrade IOS XE on Catalyst 9300 ISSU on ISR 4000

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
BrandISR 4000
FamilyCisco Real World Problems
CategoryCisco
Guide typeHow To
Skill levelIntermediate

Why this matters in the field

I have been running Cisco gear inside Indian enterprises since the Catalyst 3750-X was current. The procedure for Upgrade IOS XE on Catalyst 9300 with ISSU on a ISR 4000 is one of those tasks the official doc treats as a five-line bullet, and reality treats as a four-hour evening. This guide is written from the inside of real change windows, not from a lab.

The first time I ran this at scale was on a 12-node ISR 4000 fleet at the Manyata Tech Park rack row. The customer had bought hardware through Redington against a GeM tender, and their procurement timeline meant we could not slip the cutover. I was on the console for 38 hours across three nights. The fix cost INR 12,500 / USD 150 in licences and INR 8,000 / USD 95 in Smart-Net upgrades. but the cost of NOT doing it was a downstream contract penalty in lakhs.

If you are reading this because a ISR 4000 just bit you, take a breath. The change is reversible, the device is forgiving, and the muscle memory you build here will pay for itself the next six times you touch a Cisco box.

From the field

A vendor partner in ESS Bengaluru lab once asked me to do this on a ISR 4000 during business hours. I refused, scheduled it for Sunday 6 AM, and ran the entire flow on DNA Center while the engineer screen-shared from Bengaluru. Zero downtime, zero escalation.

That kind of detail, the boot system pointer, the SPAN being already up, the supervisor recovery path, the power-fluctuation upstream cause: is what you want before you walk into a change window. The official PDF will not tell you. A coworker who has done it 40 times will.

Tools I keep open on a ISR 4000 job

Across roughly 200 Cisco change windows in the last three years, my bag is small. I am not loyal to anything except what survives a 3 AM session timeout:

The boring truth: an honest Putty session log and a INR 16,800 / USD 200 TerraTerm rollover bundle for a 3-engineer team have saved more ISR 4000 change windows than any vendor dashboard.

What ISSU is, and what it is not

In-Service Software Upgrade (ISSU) on the Catalyst 9300 uses the dual-supervisor or dual-process model to hot-swap the IOS-XE image without dropping packets. It is real, it works, and it has very specific preconditions. Skip a precondition and ISSU silently falls back to a regular reload. which is when the customer's WhatsApp blows up at 03:14 AM.

The Catalyst 9300 supports ISSU only on certain SKUs and only between certain releases. Cisco publishes an ISSU compatibility matrix; bookmark it. Two of my customer sites bought hardware that simply did not support ISSU for the release they were on. We had to do a hard reload + dual-stack rollover, two hours of effort versus the eight minutes ISSU would have taken.

Precheck the day before

  1. Free flash check. ISSU stages two images. You need 3.2 GB free on bootflash for Polaris 17.x releases. Run dir bootflash: | i bytes.
  2. Smart licensing reachable. Run show license summary. ISSU on 17.6+ refuses to start if licensing is in EVAL or OOC for more than 90 days.
  3. Redundancy OK. show redundancy must show Active/Standby Hot. If it shows Standby Cold, the standby never finished syncing: fix that first.
  4. Configuration sync clean. show redundancy config-sync failures must be empty. Even one mismatched line will abort the ISSU mid-flight.
  5. Pre-snapshot. Save show tech-support and show running-config to your laptop via SecureCRT. INR 22,000 / USD 260 of Cisco DNA Essentials subscription per switch per year pays for itself the first time you need to diff configs at 2 AM.

The ISSU command sequence on Catalyst 9300

copy tftp://{tftp-ip}/cat-{version}.bin bootflash:
install add file bootflash:cat-{version}.bin activate issu
! IOS prompts: "This will start the install operation. Do you want to proceed? [y/n]"
! Type y. Do not hit Enter on a default, read the prompt every single time.
install commit

Between activate and commit you have a rollback timer (default 6 hours). If the new image misbehaves, run install abort issu and the device reverts to the previous packages.conf. The commit step makes the new image permanent and frees the old install staging area.

What to watch during the ISSU

Open three console windows in SecureCRT:

  1. Active sup console. primary log.
  2. Standby sup console (if dual-sup), should print SSO sync messages.
  3. An upstream router showing show bgp summary + show ip ospf neighbor every 30 seconds, so you can prove zero session drops.

Expected console output sequence:

If you see %REDUNDANCY-3-PEER_RELOAD during this: it is not ISSU, it is a regular reload of the standby. Abort and investigate before the active sup also reloads.

When ISSU fails midway

Real failures I have hit on Catalyst 9300 units at the Gurgaon Cyber City branch and similar customer sites:

  1. Standby never reaches Hot. Cause: differing SDM template between sups. Fix: identical sdm prefer on both, reload one sup, retry ISSU next window.
  2. License check fails post-activate. Cause: CSSM unreachable from new image's smart agent. Fix: ensure outbound 443 to tools.cisco.com works from VRF Mgmt-intf.
  3. Config-sync mismatch detected late. Cause: a CLI in startup-config that the new image deprecated. Fix: clean the offending CLI before retrying, common with old IPv6 / multicast CLIs.
  4. Packages.conf corruption. Cause: a previous aborted install left dangling .pkg files. Fix: install remove inactive first, free the flash, then retry.

Post-ISSU verification

Do not declare success on the install-completed message alone. The verification I run on every Catalyst 9300:

show version | i Software, BOOTLDR
show install summary
show install active
show platform
show redundancy
show interfaces description | e admin down
show logging | i -3-
show bgp summary
show ip ospf neighbor
show power inline | i denied

Anything Severity-3 or worse in the post-upgrade log is investigated before sign-off. The 9300 family in particular is sensitive to PoE-budget changes between releases; "power inline denied" tells you whether downstream APs are about to come up half-powered.

Rollback during the window

If ISSU completed but production is broken:

install rollback to base
! or, if commit already done:
install activate file bootflash:cat-{previous-version}.bin

Either way, you get a controlled reload back to the previous package set. The customer at Gurgaon Cyber City branch keeps a TS-04 ticket open for the duration of every ISSU window and closes it only after a 24-hour soak. That practice has saved me from a silent regression at least twice this year.

What I keep in the change bag for a ISR 4000 site visit

The cost of getting this wrong

The honest numbers from real Indian customers in 2025–2026:

That is why we book the window, write the runbook, log the session, and verify before sign-off. Every step in this guide costs you 10 minutes; skipping it costs the customer days.

India-specific notes: procurement and support

Cisco hardware lands in India through distributors like Redington and Ingram Micro, and into government buyers via GeM tenders. A few practical notes from the Redington Mumbai DC:

Frequently asked questions

Can I do this on a ISR 4000 without a maintenance window?

For ISSU on dual-sup hardware, technically yes. In practice, no. I have done it during production hours twice in 10 years, both times because the customer's risk appetite was higher than mine. The reward was 8 minutes saved; the risk was a 4-hour outage.

How long does the procedure take end-to-end?

Pre-checks: 30 minutes. Execution: 15–45 minutes depending on category. Verification: 30 minutes. 24-hour soak before sign-off. Total billable time: roughly 3 engineer hours plus the soak.

What if I do not have console access?

For ISSU or BGP changes. stop and reschedule. Console is non-negotiable. For PnP onboarding, you can run remote-eyes via the customer's IT team holding a phone camera at the device console, slow, but it works.

Will TAC charge me for this case?

No, if your Smart-Net is active and the device is under contract. Cisco does not bill per case for sev-2 / sev-3 issues. Sev-1 calls during paid coverage are also free. The exception is a non-supported configuration; if you are running unsupported firmware on a ISR 4000, TAC will document a refusal-to-engage line in the case.

Does any of this void warranty or SmartNet?

No. Running install / configure procedures on supported releases is what the device is shipped to do. Warranty risk comes from third-party SFP usage (specifically, Cisco logs "GBIC_SECURITY: Vendor data mismatch" and PoE budget violations on the ISR 4000). Use OEM or Cisco-compatible SFPs from Redington if SmartNet matters to you.

Where can I learn this hands-on without breaking production?

Cisco DevNet Sandbox has free always-on labs for ISR 4000 families. CML-Free runs the same images locally. For BGP specifically, GNS3 + IOSvL2 is a free combination that handles enough of the BGP state machine to practise the fixes in this guide before you touch a customer's live router.

Related guides worth a look while you sort this one out: