Home › Resources › Field Guides › Cisco MDS NX-OS Upgrade Runbook

Field Guide · Storage Operations

Cisco MDS NX-OS Upgrade Runbook: Non-Disruptive Firmware Upgrades on a Live SAN Fabric

An MDS firmware upgrade is one of the few procedures where a SAN engineer deliberately reloads the brain of a production fabric switch while hosts keep doing I/O through it. Done in order, it is routine: the data plane keeps forwarding frames while the control plane restarts, and the multipath design absorbs anything that goes wrong. Done out of order — images unverified, impact unchecked, both fabrics in one window — it is how a firmware update becomes a storage outage. This runbook is the order.

Who this is for: SAN engineers · storage administrators · field engineers performing on-site upgrades

Worked example: MDS 9148V, NX-OS 9.3(2a) → 9.4(5) · method identical across 9100/9300/9700 series · consult the release-notes upgrade matrix for your exact path · Reviewed by WUC Storage Infrastructure Engineering · Last validated: 2026-07-20

FocusNX-OS ISSU · install all · dual-fabric sequencing
PlatformMDS 9148V worked example · 9132T/9396V · directors in appendix
Path9.3(2a) → 9.4(5), single hop
InterfacesCLI over SSH · console for field method
Read time18 min

!!Command safety model

An upgrade has a point of no return, and the installer tells you exactly where it is. Everything before the line Upgrade can no longer be aborted can be stopped and leaves the switch running its old code. Everything after it must complete — a power pull or supervisor failure past that line turns a non-disruptive upgrade into a disruptive recovery. The badges below rate each command in this guide; the install itself is rated by the impact check, not by hope.
BadgeMeaning
Read-onlyInspects state, or writes only copies and backups. Safe in production, any time.
DisruptiveRestarts a control plane, reloads code, or fails over a supervisor. Recoverable, but belongs inside a change window.
DestructiveDeletes files or state. Verify the target twice; there is no undo on bootflash.

ENVReference fabric

Every output below comes from a dual-fabric SAN at the Boston site: two independent MDS 9148V fabric switches — bos-mds-a (Fabric A, VSAN 10, mgmt 10.10.20.11) and bos-mds-b (Fabric B, VSAN 20, mgmt 10.10.20.12) — each carrying one path from every host HBA to a NetApp AFF pair (aff-01a / aff-01b). The fabrics share no ISLs, no zoning, no fate. That independence is the entire upgrade strategy: upgrade Fabric B first, verify, soak, then Fabric A — so that even a worst-case failure on the switch being upgraded costs one path, not the storage.

Boston dual-fabric SAN — upgrade order: Fabric B first, then Fabric A esx-01 HBA0 · HBA1 esx-02 HBA0 · HBA1 bos-mds-a — Fabric A MDS 9148V · VSAN 10 mgmt0 10.10.20.11 upgrade SECOND bos-mds-b — Fabric B MDS 9148V · VSAN 20 mgmt0 10.10.20.12 upgrade FIRST · 9.3(2a) → 9.4(5) aff-01a NetApp AFF aff-01b NetApp AFF tftp 10.10.20.25 image staging (or field laptop) All hostnames, domains, users, IPs and serials in this guide are synthetic reference values.
Dual-fabric reference SAN. Every host reaches storage through both fabrics; the fabrics are otherwise fully independent. Because multipath survives the loss of either fabric, the upgrade order — B first, soak, then A — means the fabric being upgraded is never the only path. If your environment has a single fabric, every step below still applies, but the upgrade window is a genuine at-risk window and should be treated as one.
Why Fabric B first? Convention, not physics — most estates treat Fabric A as "primary" in monitoring and muscle memory, so B is where you learn that 9.4(5) has a surprise. What matters is not which letter goes first; it is that one goes first, gets verified, and soaks before the other is touched. Never both in the same window.

01Why "non-disruptive" actually works

On a fixed-configuration switch like the 9148V there is one supervisor — so how does the switch survive its own brain transplant? The answer is separation of planes. install all saves the runtime state of every process, upgrades the BIOS and bootloader if needed, and then restarts the control plane on the new kernel while the forwarding ASICs keep switching Fibre Channel frames from the state they already hold. Hosts keep doing I/O. What stops, briefly, is everything that thinks: the CLI, SSH sessions, SNMP, and the ability to react to fabric changes. Cisco's design target for that control-plane restart is well under the FC timeout budget — which is why the impact check can honestly print non-disruptive for a switch about to reload its kernel.

Non-disruptive is conditional, and the conditions are checked, not assumed. The installer verifies the images, the upgrade path, module support, and the state of the compact flash before committing — and if any check fails, it refuses or declares the upgrade disruptive. Your job is to run that check before the window (section 05) and believe its verdict. Three practices keep the "non-disruptive" label honest:

  1. One fabric at a time, always. The switch should survive its upgrade without dropping a frame. The dual-fabric design exists for the day it does not.
  2. No fabric changes during the window. No zoning commits, no VSAN changes, no new device logins you can avoid. The control plane is briefly not listening; do not schedule things for it to miss.
  3. Console access ready. If anything goes wrong mid-install, the console is where the switch talks to you. On-site or terminal server — know how you would reach it before you start.

02Pre-flight checks & evidence capture

Everything in this family is read-only or writes only backups. The goal is twofold: prove the switch is healthy enough to upgrade, and capture its pre-upgrade state so that "is everything back?" is a comparison, not a feeling. All examples run on bos-mds-b — Fabric B goes first.

show module Read-only

The hardware gate. Every module must show ok or active before you upgrade — a module in any failed state makes the impact check unreliable and the upgrade a gamble. On a fixed switch there is one line to read; on a director there are many (see section 09).

Command
show module
Output
Mod  Ports  Module-Type                         Model              Status
---  -----  ----------------------------------- ------------------ ----------
1    48     48x64G FC/Sup-4                     DS-C9148V-K9       active *

Mod  Sw               Hw     World-Wide-Name(s) (WWN)
---  ---------------  -----  --------------------------------------------------
1    9.3(2a)          1.0    20:01:8c:94:1f:aa:bb:00 to 20:30:8c:94:1f:aa:bb:00

show version Read-only

Records the starting point — running release, BIOS, uptime, and the last reset reason. Uptime matters: a switch that rebooted recently for reasons nobody can explain has a pre-existing problem that an upgrade will complicate, not cure.

Command
show version
Output
Cisco Nexus Operating System (NX-OS) Software
...
Software
  BIOS: version 1.11.0
  system:  version 9.3(2a)
Hardware
  cisco MDS 9148V 48X64G FC (1 RU) Chassis ("48X8/16/32/64 Gbps FC/Sup-4")
  Intel(R) Xeon(R) CPU D-1564N @ 2.30GHz with 16325232 kB of memory.
  Processor Board ID FDO29470ABC
  Device name: bos-mds-b
  bootflash:    7364608 kB
Kernel uptime is 214 day(s), 6 hour(s), 12 minute(s), 40 second(s)
Last reset
  Reason: Unknown
  System version: 9.3(2a)

dir bootflash: Read-only

The space check. A 9.4.x kickstart-plus-system pair needs roughly 2 GB of bootflash between them; the copy fails ungracefully if the space is not there. Read the bytes free line before you start a transfer, not after it dies at 97%.

Command
dir bootflash:
Output
    4096    Jan 11 08:02:12 2026  .rpmstore/
138412032  Jan 11 08:14:55 2026  m9148v-s8ek9-kickstart-mz.9.3.2a.bin
1610612736 Jan 11 08:19:31 2026  m9148v-s8ek9-mz.9.3.2a.bin
     980    Jul 19 22:04:18 2026  bos-mds-b-startup-20260719

Usage for bootflash://sup-local
 2214592512 bytes used
 5326917632 bytes free
 7541510144 bytes total

delete bootflash:<filename> Destructive

Only if the space check demands it. Delete old images that are no longer referenced by the boot variables — never the release you are currently running until the new release is installed and verified. Check show boot first if there is any doubt about which files the boot variables point at. There is no undelete on bootflash.

bos-mds-b# show boot
kickstart variable = bootflash:/m9148v-s8ek9-kickstart-mz.9.3.2a.bin
system variable    = bootflash:/m9148v-s8ek9-mz.9.3.2a.bin

bos-mds-b# delete bootflash:m9148v-s8ek9-mz.9.2.1.bin      <-- an old, unreferenced image only

copy running-config startup-config Read-only

Persist the running config before anything else. The installer performs a configuration copy of its own during the upgrade, but the discipline of an explicit save first means the startup-config you are about to back up off-box is exactly what is running.

Command
copy running-config startup-config
Output
[########################################] 100%
Copy complete.

copy startup-config tftp:// — off-box config backup Read-only

The rollback artifact that survives the switch. Name it with hostname and date so the restore, months from now under pressure, is unambiguous. Substitute your TFTP server's address.

Command
copy startup-config tftp://10.10.20.25/bos-mds-b-startup-20260720
Output
Trying to connect to tftp server......
Connection to server Established. Copying Started.....
TFTP put operation was successful

Pre-state evidence capture Read-only

Four commands whose output you will compare, line for line, after the upgrade. The FLOGI count is the single most important number on this page: it is how many devices are logged into this fabric right now, and the post-upgrade question is simply "is it the same?" terminal length 0 disables paging so your terminal emulator's session log captures everything cleanly; a full show tech-support details redirected to bootflash is the deep-evidence artifact if anything later needs a Cisco TAC case.

bos-mds-b# terminal length 0
bos-mds-b# show interface brief          | # note which fc ports are up
bos-mds-b# show flogi database           | # count the logins — write the number down
bos-mds-b# show zoneset active vsan 20   | # the zoning state that must survive
bos-mds-b# show tech-support details > bootflash:bos-mds-b-pretech-20260720.txt
Output — the number that matters
bos-mds-b# show flogi database
--------------------------------------------------------------------------------
INTERFACE  VSAN  FCID      PORT NAME                NODE NAME
--------------------------------------------------------------------------------
fc1/1      20    0x640000  20:00:00:25:b5:0b:00:0f  20:00:00:25:b5:0b:00:0e
fc1/2      20    0x640020  20:00:00:25:b5:0b:00:1f  20:00:00:25:b5:0b:00:1e
...
Total number of flogi = 14
Why evidence beats memory. After the switch comes back, something will look slightly different — it always does. The only way to know whether "different" means "broken" is a pre-state capture taken minutes before the change. Thirty seconds of show commands buys you a definitive answer at 2 a.m.

03Getting the images onto the switch

Every NX-OS release is a matched pair: a kickstart image (the bootloader and kernel) and a system image (everything else). They install together, they must be the same release, and both must reach bootflash before anything else happens. Two ways to get them there.

Method A — datacenter TFTP/SCP server Read-only

The normal case: the images sit on a staging server reachable from the switch management network. Copy the kickstart first, then the system image — the system image is ~1.6 GB and takes the longer of the two. The switch prompt returns only after the file is flushed to flash; the pause after "saving to disk" is normal.

Command — kickstart image
copy tftp://10.10.20.25/m9148v-s8ek9-kickstart-mz.9.4.5.bin bootflash:m9148v-s8ek9-kickstart-mz.9.4.5.bin
Output
Trying to connect to tftp server......
Connection to server Established. Copying Started.....
TFTP get operation was successful
Copy complete, now saving to disk (please wait)...
Command — system image
copy tftp://10.10.20.25/m9148v-s8ek9-mz.9.4.5.bin bootflash:m9148v-s8ek9-mz.9.4.5.bin
Output
Trying to connect to tftp server......
Connection to server Established. Copying Started.....
TFTP get operation was successful
Copy complete, now saving to disk (please wait)...
SCP is the better protocol when you have the choice. TFTP is unauthenticated, unencrypted, and slow on large images. The same copy over SCP: copy scp://svc-deploy@10.10.20.25/images/m9148v-s8ek9-mz.9.4.5.bin bootflash: — the syntax is identical apart from the scheme, and the transfer is both faster and authenticated. TFTP earns its place in the field method below, where the server is a laptop you control end to end.

Method B — the field-laptop method Read-only

The on-site case: no reachable staging server, a switch in a customer rack, and a laptop. This is the classic field-service procedure and it still works on every MDS generation — it is also the only method when the management network is down or the switch is being commissioned bare.

  1. Start a TFTP server on the laptop with the two image files in its serving directory (tftpd64 on Windows, tftpd/dnsmasq on macOS/Linux).
  2. Console in: console cable from the laptop's serial adapter (COM1 in the classic setup) to the switch console port — 9600 8-N-1. This is your session for the whole procedure; it survives the upgrade, SSH does not.
  3. Cable the laptop to mgmt0: Ethernet from the laptop NIC to the switch management port. The traditional instruction says crossover cable; every modern NIC auto-crosses (Auto-MDIX), so a straight cable works too — carry a crossover anyway for the pre-2010 gear this method gets used on.
  4. Address the laptop adjacent to the switch: same subnet, a couple of addresses away — switch mgmt0 10.10.20.12/24 → laptop 10.10.20.30/24. Ping the switch from the laptop before going further.
  5. Log in and copy, exactly as Method A but pointing at the laptop's address: copy tftp://10.10.20.30/m9148v-s8ek9-kickstart-mz.9.4.5.bin bootflash:... and again for the system image.
On default credentials. The classic field doc says "default username is admin, password is admin" — true only of legacy SAN-OS/early NX-OS trains and of switches someone left unconfigured. Modern NX-OS forces an admin password at initial setup. If you find any production fabric switch accepting factory-default credentials, that is a finding to report and fix before the upgrade, not a convenience to enjoy.
Legacy image naming. On older 9100/9200-series hardware the same procedure moves differently-named pairs — e.g. m9100-s2ek9-kickstart-mz.3.3.1c.bin / m9100-s2ek9-mz.3.3.1c.bin on a 9134 running SAN-OS 3.x. The platform prefix (m9100, m9148v) and image family (s1ek9, s2ek9, s8ek9) must match your hardware exactly — a mismatched family fails verification, at best.

04Verifying the images before you trust them

A truncated TFTP transfer produces a file that exists, has a plausible size, and will not boot. show version image makes the switch checksum the file and tell you what is inside it. Run it against both images, and read three things: the MD5 verdict, the version, and that the filename you typed is the file you meant.

Command — system image
show version image bootflash:m9148v-s8ek9-mz.9.4.5.bin
Output
MD5 Verification Passed
image name: m9148v-s8ek9-mz.9.4.5.bin
bios:       v1.11.0(11/27/2024)
system:     version 9.4(5)
compiled:   2/11/2026 12:00:00 [02/24/2026 22:37:35]
Command — kickstart image
show version image bootflash:m9148v-s8ek9-kickstart-mz.9.4.5.bin
Output
MD5 Verification Passed
image name: m9148v-s8ek9-kickstart-mz.9.4.5.bin
kickstart:  version 9.4(5)
loader:     version N/A
Verify the file you are about to install — the exact filename. A real field document we reviewed copied 3.3.1c images to the switch and then ran show version image against the old 3.1.2 files still sitting in bootflash. Both commands succeed; the verification is worthless. If MD5 fails, or the version printed is not the release you intend, delete the file and re-transfer — never install an image that failed or skipped verification. For a second opinion, compare against the MD5 published on the Cisco download page for the release.

05The impact check — your go/no-go gate

show install all impact runs the entire pre-install analysis — image verification, module support, upgrade-path validation, compact flash and TCAM sanity — and then tells you, per module, whether the real install would be disruptive, without changing anything. This is the command that converts "should be fine" into a documented verdict. Run it in the days before the window, and again at the start of it.

Command
show install all impact system bootflash:m9148v-s8ek9-mz.9.4.5.bin kickstart bootflash:m9148v-s8ek9-kickstart-mz.9.4.5.bin
Output
Installer will perform impact only check. Please wait.

Verifying image bootflash:/m9148v-s8ek9-kickstart-mz.9.4.5.bin for boot variable "kickstart".
[####################] 100% -- SUCCESS

Verifying image bootflash:/m9148v-s8ek9-mz.9.4.5.bin for boot variable "system".
[####################] 100% -- SUCCESS

Performing module support checks.        [####################] 100% -- SUCCESS
Verifying image type.                    [####################] 100% -- SUCCESS
Extracting "system" version.             [####################] 100% -- SUCCESS
Extracting "kickstart" version.          [####################] 100% -- SUCCESS
Extracting "bios" version.               [####################] 100% -- SUCCESS
Performing Compact Flash and TCAM sanity test.
[####################] 100% -- SUCCESS
Notifying services about system upgrade. [####################] 100% -- SUCCESS

Compatibility check is done:
Module  bootable       Impact  Install-type  Reason
------  --------  -----------  ------------  ------
1       yes       non-disruptive     reset

Images will be upgraded according to following table:
Module  Image      Running-Version(pri:alt)                  New-Version  Upg-Required
------  ---------  ----------------------------------------  -----------  ------------
1       system     9.3(2a)                                   9.4(5)       yes
1       kickstart  9.3(2a)                                   9.4(5)       yes
1       bios       v1.11.0(11/27/2024):v1.11.0(11/27/2024)   v1.11.0      no

How to read the verdict: bootable yes — the new images will boot this hardware. Impact non-disruptive — the installer commits to keeping the data plane forwarding; this is the line the whole procedure hinges on. Install-type reset — the control plane will restart (expected on a fixed switch; this is the ISSU mechanism from section 01, not a disruption). The version table is your final sanity check that the installer sees the same from→to path you intend, and the bios … no row shows the BIOS is already current — when it is not, the installer flashes it as part of the same run.

If Impact says disruptive, stop. The reason column tells you why — an unsupported upgrade path, a module that cannot ISSU, a pending incompatible configuration. Resolve the reason or schedule a disruptive window with the business's knowledge. Proceeding "anyway" on a disruptive verdict, on a production fabric, during what was sold as a non-disruptive window, is how careers end.

06install all — the upgrade itself Disruptive

The install re-runs every check from section 05, shows you the same tables, and asks once. From the y to the login prompt is typically 10–20 minutes on a fixed switch. Run it from the console if you can; if you run it over SSH, expect the line All telnet and ssh connections will now be temporarily terminated to mean your session — the install continues without you watching.

Command
install all system bootflash:m9148v-s8ek9-mz.9.4.5.bin kickstart bootflash:m9148v-s8ek9-kickstart-mz.9.4.5.bin
Output — annotated
Installer will perform compatibility check first. Please wait.

  ... identical checks and tables to section 05 ...

Do you want to continue with the installation (y/n)?  [n] y

Install is in progress, please wait.

Performing runtime checks.               [####################] 100% -- SUCCESS
Notifying services about the upgrade.    [####################] 100% -- SUCCESS
Setting boot variables.                  [####################] 100% -- SUCCESS
Performing configuration copy.           [####################] 100% -- SUCCESS

Module 1: Refreshing compact flash and Upgrading bios/loader/bootrom/power-seq.
Warning: please do not remove or power off the module at this time.
[####################] 100% -- SUCCESS

Upgrade can no longer be aborted, any failure will result in a disruptive upgrade.   <-- POINT OF NO RETURN

Freeing memory in the file system.       [####################] 100% -- SUCCESS
Loading images into memory.              [####################] 100% -- SUCCESS
Saving linecard runtime state.           [####################] 100% -- SUCCESS
Saving supervisor runtime state.         [####################] 100% -- SUCCESS
Saving mts state.                        [####################] 100% -- SUCCESS

Reloading the kernel to proceed with the upgrade.
All telnet and ssh connections will now be temporarily terminated.
  1. Before the marked line — the install can be aborted and the switch is untouched: boot variables not yet pointing at new code, old kernel running.
  2. The BIOS/flash phase — the one window where a power loss genuinely hurts. The installer says do not remove or power off; believe it. UPS-protected racks and patient hands.
  3. After the marked line — the upgrade must complete. Do not power-cycle a switch that seems quiet: the kernel reload takes minutes during which mgmt0 is down and the console shows boot output. Watch the console, not the ping.
  4. Session drop is expected. SSH dies at the kernel reload. The console session (9600 8-N-1) shows the whole boot; log back in when the prompt returns.

07Post-upgrade verification battery

The switch is back when the console shows a login prompt — but "back" is not "verified". Work the battery top to bottom; each command answers one question, and the pre-state capture from section 02 is the answer key. Do not hand the window back until the FLOGI count matches.

show version Read-only

Is the switch actually running the new code? Read the system version and the uptime — minutes, not days, proves the reload happened.

Command
show version
Output
Software
  BIOS: version 1.11.0
  system:  version 9.4(5)
...
Kernel uptime is 0 day(s), 0 hour(s), 9 minute(s), 41 second(s)
Last reset
  Reason: Reset due to upgrade
  System version: 9.3(2a)

show module Read-only

Hardware healthy on the new release — every module ok/active, and the Sw column now reads 9.4(5).

Command
show module
Output
Mod  Ports  Module-Type                         Model              Status
---  -----  ----------------------------------- ------------------ ----------
1    48     48x64G FC/Sup-4                     DS-C9148V-K9       active *

Mod  Sw               Hw
---  ---------------  -----
1    9.4(5)           1.0

show system health Read-only

The platform's own health monitor — per-module tests, all of which should report enabled and passing. Anything failing here after an upgrade is a TAC case, not a curiosity.

Command
show system health
Output
Current health information for module 1.

Test                     Frequency    Status        Action
-----------------------  -----------  ------------  -----------
Bootflash                5 Sec        Running       Enabled
Management Port          5 Sec        Running       Enabled
Inband                   5 Sec        Running       Enabled
ASIC Loopback            20 Min       Running       Enabled

show interface brief Read-only

Every fc port that was up before must be up now — compare against the pre-state capture, port by port. A port that came back down usually means the attached device gave up during the control-plane restart and needs its link bounced from the host side.

Command
show interface brief
Output
Interface  Vsan  Admin  Admin  Status  SFP    Oper   Oper    Port
                 Mode   Trunk          Mode   Speed  Channel
                        Mode                  (Gbps)
---------------------------------------------------------------------
fc1/1      20    auto   on     up      swl    F      64      --
fc1/2      20    auto   on     up      swl    F      64      --
fc1/3      20    auto   on     up      swl    F      32      --

show flogi database Read-only

The verdict command. The total at the bottom must equal the number you wrote down in section 02. Fourteen before, fourteen after — every HBA and storage port that was logged into this fabric still is, which is the definition of a non-disruptive upgrade from where the hosts sit.

Command
show flogi database
Output
--------------------------------------------------------------------------------
INTERFACE  VSAN  FCID      PORT NAME                NODE NAME
--------------------------------------------------------------------------------
fc1/1      20    0x640000  20:00:00:25:b5:0b:00:0f  20:00:00:25:b5:0b:00:0e
fc1/2      20    0x640020  20:00:00:25:b5:0b:00:1f  20:00:00:25:b5:0b:00:1e
...
Total number of flogi = 14                                    <-- matches pre-upgrade

show zoneset active vsan 20 Read-only

The active zoneset survived the reload intact — same zoneset name, same zone count, members showing * (logged in). Diff against the pre-capture.

Command
show zoneset active vsan 20

show logging last 50 Read-only

The switch's own account of the upgrade — expect the orderly shutdown, the boot on the new kernel, services restarting, and interfaces coming up. What you are looking for is what should not be there: license complaints, module diagnostics failures, anything at severity 2 or worse after the boot completed.

Command
show logging last 50

show logging nvram Read-only

Severe messages persisted across the reload. The buffer log dies with the reboot; NVRAM keeps severity-critical history. Empty of new entries is the good answer.

Command
show logging nvram

show interface mgmt 0 Read-only

Management path healthy — up, correct address, counters incrementing without errors. This is also implicit proof your monitoring can see the switch again.

Command
show interface mgmt 0
Output
mgmt0 is up
    Internet Address is 10.10.20.12/24
    MTU 1500 bytes, BW 1000000 Kbit
    1240 packets input, 158230 bytes
    0 input errors, 0 CRC errors
    987 packets output, 224180 bytes
    0 output errors

Post-state evidence capture Read-only

Close the loop the same way it opened — a full capture on the new release, kept alongside the pre-capture. If anything surfaces in the following days, the before/after pair answers "did the upgrade do this?" definitively.

bos-mds-b# terminal length 0
bos-mds-b# show tech-support details > bootflash:bos-mds-b-posttech-20260720.txt
bos-mds-b# copy running-config startup-config
Then: soak, verify from the hosts, and only then Fabric A. Confirm at the host layer (ESXi storage-path view, Linux multipath -ll, NetApp storage path show-equivalents) that every path through Fabric B is back and active. Let B run for at least 24 hours — long enough for a latent issue to surface — then repeat this entire runbook on bos-mds-a. The soak is not caution theatre; it is the only test of the new release under your real workload.

08Rollback Disruptive

A rollback is the same procedure pointed backwards: the old images are still in bootflash (you deliberately did not delete them), and install all will downgrade exactly as it upgraded — including an impact check that tells you whether the downgrade is non-disruptive. Two honest caveats: downgrade paths have their own support matrix in the release notes, and any configuration that used a 9.4-only feature will not survive the trip back — which is why the off-box startup-config backup from section 02 exists.

bos-mds-b# show install all impact system bootflash:m9148v-s8ek9-mz.9.3.2a.bin kickstart bootflash:m9148v-s8ek9-kickstart-mz.9.3.2a.bin
bos-mds-b# install all system bootflash:m9148v-s8ek9-mz.9.3.2a.bin kickstart bootflash:m9148v-s8ek9-kickstart-mz.9.3.2a.bin

# If configuration must also be restored to the pre-upgrade state:
bos-mds-b# copy tftp://10.10.20.25/bos-mds-b-startup-20260720 startup-config
bos-mds-b# reload
When to roll back at all. Almost never for cosmetic differences — a changed CLI default or new log message is not a rollback trigger. Roll back for functional regressions the fabric cannot live with: path flaps under load, interop failures with attached devices, or a defect matching a release-note caveat you now wish you had read. If Fabric B soak caught it, Fabric A never sees it — that is the payoff of the sequencing.

09Director-class & legacy platform appendix

On a director (9706/9710/9718) the same install all upgrades both supervisors and every linecard in one orchestrated run — the standby supervisor upgrades first, a switchover moves control to it, then the former active follows. Non-disruptive here means genuinely hitless. What changes for the operator is bookkeeping: two supervisors means two bootflashes, and both need space for the image pair.

attach module — reaching the standby supervisor Read-only

The standby's bootflash is not directly visible from the active session. attach module opens a shell on it — identify the standby slot with show module (the supervisor without the *), then clean up its bootflash exactly as you would the active's. exit returns to the active supervisor.

bos-mds9710# show module | include Sup
5    0    Supervisor Module-3        DS-X97-SF1-K9      active *
6    0    Supervisor Module-3        DS-X97-SF1-K9      ha-standby

bos-mds9710# attach module 6
Attaching to module 6 ...
bos-mds9710(standby)# dir bootflash:
bos-mds9710(standby)# delete bootflash:m9700-sf3ek9-mz.9.2.1.bin     <-- old, unreferenced only
bos-mds9710(standby)# exit

system switchover Disruptive

Forces the standby supervisor to become active. Legitimately used to validate HA before an upgrade window and during supervisor maintenance — but understand it restarts the control plane's residence, and a fabric mid-anything will notice. Confirm show system redundancy status reports ha-standby ready before issuing it, and expect your session to drop.

Command
system switchover

Legacy-era commands you will meet in old runbooks Read-only

Two commands from the SAN-OS/early NX-OS generation survive in circulated field documents. They are harmless, occasionally useful, and mostly inapplicable to current hardware — annotated here so an old runbook does not send you hunting for missing output.

# SSM = Storage Services Module (Gen-2 9200/9500 chassis only).
# On any fixed switch or current director this returns nothing of interest.
switch# show ssm provisioning

# Legacy build fingerprint from the SAN-OS era; modern equivalent data
# is in "show version" itself.
switch# show version internal build-identifier

RBRunbook · condensed dual-fabric sequence

  1. T-minus days: release notes read, upgrade path confirmed in the matrix, images downloaded, MD5s noted. show install all impact run on both switches — both verdicts non-disruptive.
  2. Fabric B window opens: show module all ok · dir bootflash: space confirmed · copy run start · startup-config backed up off-box · pre-state captured (show interface brief, show flogi database count, show zoneset active, tech-support to bootflash).
  3. Stage + verify: both images copied to bootflash · show version image on both — MD5 passed, versions correct.
  4. Gate: show install all impact re-run inside the window — still non-disruptive.
  5. Install: install all system … kickstart … → y · watch the console · no power events past the point of no return.
  6. Verify: full battery from section 07 — version, module, health, interfaces, FLOGI count matches, zoneset intact, logs clean, host-side paths restored.
  7. Soak ≥ 24 h with host-layer path monitoring. Any regression → rollback, and Fabric A is never touched.
  8. Fabric A: repeat steps 2–7 on bos-mds-a. Close the change with both post-tech captures archived.

Fabric upgrades overdue because nobody owns them?

WUC engineers plan and execute MDS NX-OS upgrade campaigns — path validation, dual-fabric sequencing, host-layer verification, and rollback planning — across estates inside and outside OEM support, including platforms Cisco has end-of-lifed.

Talk to engineering →

FAQFrequently asked questions

Q01Is it really non-disruptive with only one supervisor?

Yes, for the data plane — the forwarding ASICs keep switching frames from installed state while the control plane restarts on the new kernel. What drops is management: SSH, SNMP, and the CLI, for the minutes the reload takes. Hosts doing I/O through the switch do not see a path failure. Treat it as a maintenance window anyway: the impact check's promise holds for the happy path, and windows exist for the other one.

Q02How long does one switch take?

Ten to twenty minutes from y to login prompt on a fixed switch, plus your verification battery. Budget an hour per switch in the change record and be pleasantly early, not embarrassingly late.

Q03Can I go straight from 9.3(2a) to 9.4(5)?

In the worked example, yes — and the installer's compatibility check enforces the truth regardless of what this page says. The authoritative answer for your pair of releases is the upgrade-path matrix in the target release's notes. Some paths require an intermediate hop; the impact check refuses unsupported paths rather than guessing.

Q04The impact check says disruptive. Can I proceed anyway?

You can, and the fabric will take the hit the check predicted. Do not. Read the Reason column, fix what it names — unsupported path, incompatible feature configuration, a module that cannot ISSU — or renegotiate the window as a disruptive one with the business informed. The check is the contract; proceeding against it converts a firmware task into an unplanned outage with your name on the change record.

Q05Do I really need both kickstart and system images?

Yes. They are a matched pair from the same release — kickstart is the bootloader and kernel, system is everything above it. install all takes both arguments, validates they match, and sets both boot variables. Supplying only one, or mixing releases, fails the compatibility check.

Q06Not enough bootflash space for the new images — what do I delete?

Old image files that the boot variables no longer reference — confirm with show boot before deleting anything. Keep the currently-running pair until the new release is installed, verified, and soaked; it is your fastest rollback. On directors, remember the standby supervisor's bootflash needs the same housekeeping via attach module.

Q07Can I do both fabrics in the same window and go home early?

The whole value of a dual-fabric SAN during an upgrade is that one fabric is always untouched. Upgrade both in one window and any release-level defect hits every path at once — the exact scenario the architecture was bought to prevent. B, verify, soak, then A. Go home early next week.

Q08What about EPLD upgrades?

Separate image, separate decision. EPLD (programmable logic) upgrades are disruptive per module — ports on the module go down while it flashes — and are only needed when release notes or TAC say so for a specific fix. Never bundle an EPLD flash into a routine ISSU window on assumption; schedule it deliberately with its own impact acknowledged.

RFReferences

  1. Cisco MDS 9000 NX-OS — Software Upgrade and Downgrade Guides (per release)
  2. Cisco MDS 9000 NX-OS — Release Notes (upgrade-path matrix per release)
  3. Cisco MDS 9000 Series Multilayer Switches — product documentation

→From the same practice

WE

About WUC Engineering

SAN engineers at WUC Technologies operate Cisco MDS fabrics — from legacy 9100/9200-series through current 9148V/9700-series — under post-OEM network maintenance and storage maintenance engagements across enterprise data centers.

Running fabric switches on firmware older than your interns?

Most SAN estates we assess are several releases behind — usually because the last upgrade was scary and undocumented. WUC engineers deliver MDS upgrade campaigns as change-controlled engagements: path validation, impact verification, dual-fabric sequencing, host-layer path verification, and rollback plans that have actually been rehearsed.

  • NX-OS currency assessment across the fabric estate
  • Upgrade-path planning against the Cisco support matrix
  • Change-window execution with host-layer verification
  • End-of-life platform support beyond OEM cutoff
e.g. Cisco, Dell, NetApp - and when your next contract renews.

Prefer to talk it through first? Book a technical consultation → · View managed services

All hostnames, domains, users, paths, serial numbers and IP addresses in this guide are synthetic reference values. No customer environment is depicted.

Get a Custom Solution

Ready to Transform Your IT Infrastructure?

Get enterprise-grade support backed by seasoned infrastructure engineering.

Request a Quote Email Support

We respond within 1 business day. No spam, ever. • 15+ years • 99.9% uptime guaranteed