MDS 9000 Series Firmware Upgrade

It is always good practice to read the software ‘release notes’ before proceeding with an upgrade. The ‘Cisco MDS 9000 NX-OS and SAN-OS Software’ release notes can be found here.

These are the steps I follow when upgrading:

1. Open an SSH session to the switch.

2. Take a backup of your configuration. Firstly ensure that your running configuration has been applied to the startup-config:
copy running-config startup-config
Then backup your startup configuration. In this example we are backing up to an ftp server:
copy system:startup-config ftp://FTPserver_IP/startup-config.cfg

3. Ensure the switch is in a healthy state before proceeding:

If the MDS is a Director Level switch, then check the redundancy and module status:
show system redundancy status
show module

During the upgrade the standby supervisor is upgraded first. Once the upgrade has completed on the standby then an automatic switchover occurs and the upgraded standby becomes primary while the other supervisor is upgraded. The odd time I have experienced with a Director switch that the supervisor does not switch back to the original primary after the code upgrade has completed. In this scenario simply use these cmds to switch manually:
attach module #
system switchover (if running on standby)

4. Check the current firmware version:

5. Change directory to bootflash and upload the new bin files to the switch. This example uses an ftp transfer:
copy ftp://user@IP_Address/m9100-s3ek9-kickstart-mz.5.2.8c.bin m9100-s3ek9-kickstart-mz.5.2.8c.bin
copy ftp://user@IP_Address/m9100-s3ek9-mz.5.2.8c.bin m9100-s3ek9-mz.5.2.8c.bin

6. Ensure the code was uploaded to the bootflash directory successfully:

7. Determine if the upgrade will be non-disruptive:
show install all impact system bootflash:///m9100-s3ek9-mz.5.2.8c.bin
For a non-disruptive upgrade the switches are designed in such a way that the ports will remain connected and traffic flow will continue non-disrupted throughout the upgrade. This is so because the switch has been engineered in such a way that the control plane is separate to the data plane. In the case of a director level switch the modules are upgraded and rebooted in a rolling fashion one at a time non-disruptively(non-disruptively due to the separation of the control and data planes).

8. Check the MD5 and confirm the files validity:
show version image bootflash:///m9100-s3ek9-mz.5.2.8c.bin
show version image bootflash:///m9100-s3ek9-kickstart-mz.5.2.8c.bin

9. Check for any incompatibilities between the running and the upgrade code versions. This will check for features that are currently running on the switch but are not supported on the upgrade code level:
show incompatibility system bootflash:///m9500-sf2ek9-mz.5.2.8c.bin

10. Enter the following command to install the new firmware on the switch:
install all system m9100-s3ek9-mz.5.2.8c.bin kickstart m9100-s3ek9-kickstart-mz.5.2.8c.bin

11. Display the status of the upgrade:
‘show install all status’

12. Run ‘show version’ to ensure the switch is now running at the upgraded code level. As you can see from the below example the ‘system version’ is still on the previous firmware level – a reload is required to apply the upgrade. NOTE: A reload is disruptive to traffic flow (As pointed out by @dynamoxxx below). This is not common and I have only identified this with the 9148 Switch when upgrading from 5.0.x to 5.8.x.

After reload the system version should be at the upgraded version:

It is good practice to delete the old install files from the bootflash directory:
cd bootflash:
delete m9100-s3ek9-kickstart-mz.5.0.1a.bin
delete m9100-s3ek9-mz.5.0.1a.bin