HowToFixMe
Cisco Real World Problems

How to upgrade IOS XE on Catalyst 9500 ISSU on FTD

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

⚡ At a glance
BrandFTD
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 9500 with ISSU on a FTD (Firepower Threat Defense) 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 FTD (Firepower Threat Defense) fleet at the Redington Mumbai DC. 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 22,000 / USD 260 in licences and INR 12,500 / USD 150 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 FTD (Firepower Threat Defense) 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

Back in 2024, a Vashi peering point change-window slot opened at 02:15 and our FTD (Firepower Threat Defense) refused to come back without the bootflash:packages.conf, I had to SecureCRT into the redundant supervisor and run the recovery from there. Two-hour lesson in why we preserve packages.conf, never just .bin.

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 FTD (Firepower Threat Defense) 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 1.4 lakh / USD 1,680 Catalyst 9300-24T renewal from Redington have saved more FTD (Firepower Threat Defense) change windows than any vendor dashboard.

What ISSU is: and what it is not

In-Service Software Upgrade (ISSU) on the Catalyst 9500 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 9500 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 8,000 / USD 95 of Putty Pro lifetime + a pair of console cables pays for itself the first time you need to diff configs at 2 AM.

The ISSU command sequence on Catalyst 9500

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 9500 units at the Redington Mumbai DC 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 9500:

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 Redington Mumbai DC 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 FTD (Firepower Threat Defense) 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 Whitefield POP:

Frequently asked questions

Can I do this on a FTD (Firepower Threat Defense) 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 FTD (Firepower Threat Defense), 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 FTD (Firepower Threat Defense)). 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 FTD (Firepower Threat Defense) 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: