Each device is shipped with the Cisco NX-OS software preinstalled. The Cisco NX-OS software consists of one NX-OS software image. The image filename begins with "nxos" (for example, nxos.9.2.1.bin). Only this image is required to load the Cisco NX-OS operating system.

The Cisco Nexus 9000 Series switches and the Cisco Nexus 3132C-Z, 3132Q-V, 3164Q, 3232C, 3264C-E, 3264Q, 31108PC-V, 31108TC-V, 31128PQ, and 34180YC switches support disruptive software upgrades and downgrades by default.

Note

Another type of binary file is the software maintenance upgrade (SMU) package file. SMUs contain fixes for specific defects. They are created to respond to immediate issues and do not include new features. SMU package files are available for download from Cisco.com and generally include the ID number of the resolved defect in the filename (for example, n9000-dk9.2.1.CSCab00001.gbin). For more information on SMUs, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.

Note

Cisco also provides electronic programmable logic device (EPLD) image upgrades to enhance hardware functionality or to resolve known hardware issues. The EPLD image upgrades are independent from the Cisco NX-OS software upgrades. For more information on EPLD images and the upgrade process, see the Cisco Nexus 9000 Series FPGA/EPLD Upgrade Release Notes.

An ISSU allows you to upgrade the device software while the switch continues to forward traffic. ISSU reduces or eliminates the downtime typically caused by software upgrades. You can perform an in-service software upgrade (ISSU), also known as a nondisruptive upgrade, for some switches. (See the Cisco NX-OS Software Upgrade Guidelines for a complete list of supported platforms.)

The default upgrade process is disruptive. Therefore, ISSU needs to be enabled using the command-line interface (CLI), as described in the configuration section of this document. Using the nondisruptive option helps ensure a nondisruptive upgrade. The guest shell is disabled during the ISSU process and it is later reactivated after the upgrade.

Enhanced ISSUs are supported for some Cisco Nexus 9000 Series switches and the Cisco Nexus 3164Q, 31128PQ, 3132Q-V, 31108PC-V, and 31108TC-V switches.

The following ISSU scenarios are supported:

• Performing standard ISSU on Top-of-Rack (ToR) switches with a single supervisor

• Performing standard ISSU on End-of-Row (EoR) switches with two supervisors

• Performing enhanced ISSU on Top-of-Rack (ToR) switches with a single supervisor

Performing Standard ISSU on End-of-Row (EoR) Switches with Two Supervisors

Cisco Nexus 9500 Series switches are the modular EoR switches that require two supervisors for ISSU. The minimum configuration required is two system controllers and two fabric modules.

Cisco Nexus 9500 Series switches support parallel upgrade as the default method. The parallel method upgrades the modules in the batches (as outlined in the following illustration) instead of upgrading the modules one after the other.

The steps for the parallel upgrade process on Cisco Nexus 9500 Series switches are:

• First the supervisors are upgraded (This procedure requires a switchover). Then the line cards, the fabric modules, the system controllers, and the FEX are upgraded.

• After the switchover is performed in a parallel upgrade, the secondary supervisor takes over. The installer determines the current line cards and the fabric modules.

• The installer then divides the components into the buckets. It places the first half of the line cards in the first bucket, the first half of the fabric modules in the second bucket, the second half of line cards in the third bucket, the second half of the fabric modules in the fourth bucket, the first system controller in the fifth bucket, and the second system controller in the sixth bucket.

• Each bucket is upgraded successfully before an upgrade process starts for the next bucket.

• The console displays the modules with the bucket assignments and the status of the upgrade.

The user also has the option to choose a serial upgrade using the CLI.

While performing standard ISSU for the modular switches, the data plane traffic is not disrupted. The control plane downtime is approximately less than 6 Seconds.

Note

The minimum requirement for a modular Cisco Nexus 9000 Series switch undergoing ISSU is two supervisors, two system controllers, and two fabric modules. The Cisco Nexus 9400 line cards can have a partially connected fabric module. In this case, if only two fabric modules are used with the Cisco Nexus 9400 line cards, the fabric modules should not be in slots 21 and 25. They should be in slots 22, 23, 24, or 26. This allows for the system to maintain high availability during ISSU.

Performing Enhanced ISSU on Top-of-Rack (ToR) Switches with a Single Supervisor

Note	Enhanced ISSU to Cisco NX-OS Release 9.2(x) is not supported as there are kernel fixes that cannot take effect without reloading the underlying kernel.

The Cisco NX-OS software normally runs directly on the hardware. However, configuring enhanced or container-based ISSU on single supervisor ToRs is accomplished by creating virtual instances of the supervisor modules and the line cards. With enhanced ISSU, the software runs inside a separate Linux container (LXC) for the supervisors and the line cards. A third container is created as part of the ISSU procedure, and it is brought up as a standby supervisor.

The virtual instances (or the Linux containers) communicate with each other using an emulated Ethernet connection. In the normal state, only two Linux containers are instantiated: vSup1 (a virtual SUP container in an active role) and vLC (a virtual linecard container). Enhanced ISSU requires 16G memory on the switch.

Note

To enable booting in the enhanced ISSU (LXC) mode, use the [no] boot mode lxc command. This command is executed in the config mode. See the following sample configuration for more information: switch(config)# boot mode lxc Using LXC boot mode Please save the configuration and reload system to switch into the LXC mode. switch(config)# copy r s [########################################] 100% Copy complete.

Note	When you are enabling enhanced ISSU for the first time, you have to reload the switch first.

During the software upgrade with enhanced ISSU, the supervisor control plane stays up with minimal switchover downtime disruption and the forwarding state of the network is maintained accurately during the upgrade. The supervisor is upgraded first and the line card is upgraded next.

The data plane traffic is not disrupted during the ISSU process. The control plane downtime is less than 6 seconds.

Note	In-service software downgrades (ISSDs), also known as nondisruptive downgrades, are not supported.

For information on ISSU and high availability, see the Cisco Nexus 9000 Series NX-OS High Availability and Redundancy Guide.

Cisco recommends performing a Nexus Health and Configuration Check before performing an upgrade. The benefits include identification of potential issues, susceptible Field Notices and Security Vulnerabilities, missing recommended configurations and so on. For more information about the procedure, see Perform Nexus Health and Configuration Check.

Upgrading the Cisco NX-OS software has the following prerequisites:

• For ISSU compatibility for all releases, see the Cisco Nexus 9000 and 3000 Upgrade and ISSU Matrix.

• Ensure that everyone who has access to the device or the network is not configuring the device or the network during this time. You cannot configure a device during an upgrade. Use the show configuration session summary command to verify that you have no active configuration sessions.

• Save, commit, or discard any active configuration sessions before upgrading or downgrading the Cisco NX-OS software image on your device. On a device with dual supervisors, the active supervisor module cannot switch over to the standby supervisor module during the Cisco NX-OS software upgrade if you have an active configuration session.

• To transfer NX-OS software images to the Nexus switch through a file transfer protocol (such as TFTP, FTP, SFTP, SCP, etc.), verify that the Nexus switch can connect to the remote file server where the NX-OS software images are stored. If you do not have a router to route traffic between subnets, ensure that the Nexus switch and the remote file server are on the same subnetwork. To verify connectivity to the remote server, transfer a test file using a file transfer protocol of your choice or use the ping command if the remote file server is configured to respond to ICMP Echo Request packets. An example of using the ping command to verify connectivity to a remote file server 192.0.2.100 is shown below:

  switch# ping 192.0.2.100 vrf management
  PING 192.0.2.100 (192.0.2.100): 56 data bytes
  64 bytes from 192.0.2.100: icmp_seq=0 ttl=239 time=106.647 ms
  64 bytes from 192.0.2.100: icmp_seq=1 ttl=239 time=76.807 ms
  64 bytes from 192.0.2.100: icmp_seq=2 ttl=239 time=76.593 ms
  64 bytes from 192.0.2.100: icmp_seq=3 ttl=239 time=81.679 ms
  64 bytes from 192.0.2.100: icmp_seq=4 ttl=239 time=76.5 ms
  
  --- 192.0.2.100 ping statistics ---
  5 packets transmitted, 5 packets received, 0.00% packet loss
  round-trip min/avg/max = 76.5/83.645/106.647 ms
  
  

• For non-disruptive ISSU in spanning tree topology, before running the show spanning-tree issu-impact command, verify the following criteria:

  • No Topology change must be active in any STP instance

  • Bridge assurance(BA) should not be active on any port (except MCT and vPC peer link)

  • There should not be any Non-Edge Designated Forwarding port (except MCT and vPC peer link)

  • ISSU criteria must be met on the vPC peer switch

For more information on configuration sessions, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide specific to your release.

Downgrading the Cisco NX-OS software has the following prerequisites:

• Before you downgrade from a Cisco NX-OS release that supports the Control Plane Policing (CoPP) feature to an earlier Cisco NX-OS release that does not support the CoPP feature, you should verify compatibility using the show incompatibility nxos bootflash:filename command. If an incompatibility exists, disable any features that are incompatible with the downgrade image before downgrading the software.

Note	The Cisco Nexus 9000 Series NX-OS Release Notes contain specific upgrade guidelines for each release. See the Release Notes for the target upgrade release before starting the upgrade.

• The compressed image of Cisco Nexus 3000-series is hardware dependent and can only be used on the same device that it got compressed or downloaded from CCO. Do not use the Nexus 3000-series compressed image on Nexus 9000-series

Before attempting to upgrade to any software image, follow these guidelines:

• Schedule the upgrade when your network is stable and steady.

• Avoid any power interruption, which could corrupt the software image, during the installation procedure.

• On devices with dual supervisor modules, both supervisor modules must have connections on the console ports to maintain connectivity when switchovers occur during a software upgrade. See the Hardware Installation Guide for your specific chassis.

• Perform the installation on the active supervisor module, not the standby supervisor module.

• The install all command is the recommended method for software upgrades because it performs configuration compatibility checks and BIOS upgrades automatically. In contrast, changing the boot variables and reloading the device bypasses these checks and the BIOS upgrade and therefore is not recommended.

  Note

  For Cisco Nexus 9500 platform switches with -R line cards, you must perform a write erase and reload the device to upgrade from any release prior to Cisco NX-OS Release 7.0(3)F3(4). To upgrade from Cisco NX-OS Release 7.0(3)F3(4) or 9.2(x) to any later release, we recommend that you use the install all command. iCAM must be disabled before upgrading from Release 7.0(3)I7(1) → Release 9.2(x) or Release 9.3(x). Only Release 9.2(4) → Release 9.3(1) can be performed if iCAM is enabled.

• Detect a bad software image before performing an ISSU upgrade from an old release to a new release by checking the md5sum after downloading the new image (with seg6).

• When upgrading from Cisco Nexus 94xx, 95xx, and 96xx line cards to Cisco Nexus 9732C-EX line cards and their fabric modules, upgrade the Cisco NX-OS software before inserting the line cards and fabric modules. Failure to do so can cause a diagnostic failure on the line card and no TCAM space to be allocated. You must use the write_erase command followed by the reload command.

• If you upgrade from a Cisco NX-OS release that supports the CoPP feature to a Cisco NX-OS release that supports the CoPP feature with additional classes for new protocols, you must either run the setup utility using the setup command or use the copp profile command for the new CoPP classes to be available. For more information on these commands, see the "Configuring Control Plane Policing" chapter in the Cisco Nexus 9000 Series NX-OS Security Configuration Guide, Release 9.x.

• For secure POAP, ensure that DHCP snooping is enabled and set firewall rules to block unintended or malicious DHCP servers. For more information on POAP, see the Cisco Nexus 9000 Series Fundamentals Configuration Guide.

• When you upgrade from an earlier release to a Cisco NX-OS release that supports switch profiles, you have the option to move some of the running-configuration commands to a switch profile. For more information, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide, Release 9.x.

• When upgrading from Cisco NX-OS Release 9.2(4) or earlier releases to Cisco NX-OS Release 9.3(4) or later, running configuration contains extra TCAM configuration lines. You can ignore these extra lines as they do not have an effect on the upgrade and configuration.

• On Nexus 9500 switches with N9508-E2 Fabric module, downgrade from any 9.x or 10.x supported releases to any unsupported releases of 7.x is not supported.

• By default, the software upgrade process is disruptive.

• OpenFlow and LACP fast timer rate configurations are not supported for Non-Disruptive ISSU.

• Guest Shell is disabled during an ISSU and reactivated after the upgrade.

• ISSU supports only default hold timers for BGP peers.

• During an ISSU on a Cisco Nexus 3164Q, 31128PQ, or 9300 platform switch, all First-Hop Redundancy Protocols (FHRPs) will cause the other peer to become active if the node undergoing the ISSU is active.

• Make sure that both vPC peers are in the same mode (regular mode or enhanced mode) before performing a nondisruptive upgrade.

  Note	vPC peering between an enhanced ISSU mode (boot mode lxc) configured switch and a non-enhanced ISSU mode switch is not supported.

• During an ISSU, the software reload process on the first vPC device locks its vPC peer device by using CFS messaging over the vPC communications channel. Only one device at a time is upgraded. When the first device completes its upgrade, it unlocks its peer device. The second device then performs the upgrade process, locking the first device as it does so. During the upgrade, the two vPC devices temporarily run different releases of Cisco NX-OS; however, the system functions correctly because of its backward compatibility support.

• When redistributing static routes, Cisco NX-OS requires the default-information originate command to successfully redistribute the default static route starting in 7.0(3)I7(6).

• ISSU is not supported when onePK is enabled. You can run the show feature | include onep command to verify that this feature is disabled before performing an ISSU or enhanced ISSU.

• In general, ISSUs are supported for the following:

  • From a major release to any associated maintenance release.

  • From the last two maintenance releases to the next two major releases.

  • From an earlier maintenance release to the next two major releases.

  Note	For a list of specific releases from which you can perform an ISSU, see the Cisco Nexus 9000 Series NX-OS Release Notes for your particular release.

• After performing ISSU on Cisco Nexus 9300 platform switches and the Cisco Nexus 3164Q switches, you may see the MTS_OPC_CLISH message on the vPC peers. MTS_OPC_CLISH is the last MTS code that is sent from the back-end component to the VSH to specify the end of the show command output.

  If the user executes a show command that produces more output and keeps the session on for more than 3 minutes, the following warning message may be displayed on the console. As a workaround, you can set the terminal length as 0 using the terminal length 0 command or the show <command> | no-more option.

  
  --More--2018 Jun 5 19:11:21 Th-agg1 %$ VDC-1 %$ Jun 5 19:11:20 %KERN-2-SYSTEM_MSG: [12633.219113] 
  App vsh.bin on slot 1 vdc 1 SUP sap 64098(cli_api queue) did not drop MTS_OPC_CLISH with 
  msg_id 0x675ecf from sender sap 64132(NULL) in 180 sec, contact app owner - kernel
  

  
  (config)# show ip mroute detail 
  IP Multicast Routing Table for VRF "default"
  
  Total number of routes: 4801
  Total number of (*,G) routes: 2400
  Total number of (S,G) routes: 2400
  Total number of (*,G-prefix) routes: 1
  
  (*, 225.0.0.1/32), uptime: 00:09:32, igmp(1) pim(0) ip(0) 
    RPF-Source: 10.10.10.3 [11/110]
    Data Created: No
    VPC Flags
      RPF-Source Forwarder
    Stats: 15/720 [Packets/Bytes], 0.000   bps
    Stats: Inactive Flow
    Incoming interface: Ethernet1/1, RPF nbr: 12.0.0.2
    LISP dest context id: 0  Outgoing interface list: (count: 1) (bridge-only: 0)
      Vlan2001, uptime: 00:09:32, igmp (vpc-svi) 
  
  
  (60.60.60.2/32, 225.0.0.1/32), uptime: 00:09:31, ip(0) mrib(1) pim(0) 
    RPF-Source: 60.60.60.2 [20/110]
    Data Created: Yes
    VPC Flags
  --More--2018 Jun  5 19:11:21 Th-agg1 %$ VDC-1 %$ Jun  5 19:11:20 %KERN-2-SYSTEM_MSG: [12633.219113] App vsh.bin on slot 1 vdc 1 SUP 
  sap 64098(cli_api queue) did not drop MTS_OPC_CLISH with msg_id 0x675ecf from sender sap 64132(NULL) in 180 sec, 
  contact app owner - kernel
  

  There is no functionality impact or traffic loss due to this issue. All the MTS messages are drained once the show command displays the complete output, the user enters CTRL+c, or the session gets closed.

• Occasionally, while the switch is operationally Up and running, the Device not found logs are displayed on the console. These logs were disabled in releases prior to 9.2(1). This issue is observed because the switch attempts to find an older ASIC version and the error messages for the PCI probe failure are enabled in the code. There is no functionality impact or traffic loss due to this issue.

• ISSU is not supported if EPLD is not at Cisco NX-OS Release 7.0(3)I3(1) or later.

• Beginning with Cisco NX-OS Release 9.2(1), a simplified NX-OS numbering format is used for the platforms that are supported in the release. In order to support a software upgrade from releases prior to Cisco NX-OS Release 7.0(3)I7(4) that have the old release format, an installer feature supplies an I9(x) label as a suffix to the actual release during the install all operation. This label is printed as part of the image during the install operation from any release prior to Cisco NX-OS Release 7.0(3)I7(4) to 9.2(x), and it can be ignored. See the following example.

  switch# install all nxos bootflash:nxos.9.2.1.bin
  Installer will perform compatibility check first. Please wait. 
  Installer is forced disruptive
  
  Verifying image bootflash:/nxos.9.2.1.bin for boot variable "nxos".
  [####################] 100% -- SUCCESS
  
  Verifying image type.
  [####################] 100% -- SUCCESS
  
  Preparing "nxos" version info using image bootflash:/nxos.9.2.1.bin.
  [####################] 100% -- SUCCESS
  
  Preparing "bios" version info using image bootflash:/nxos.9.2.1.bin.
  [####################] 100% -- SUCCESS
  
  Performing module support checks.
  [####################] 100% -- SUCCESS
  
  Notifying services about system upgrade.
  [####################] 100% -- SUCCESS
  
  Compatibility check is done:
  Module  bootable   Impact       Install-type  Reason
  ------  --------  ------------  ------------  ------
    1       yes      disruptive     reset       Incompatible image for ISSU
  
  Images will be upgraded according to following table:
  Module   Image                 Running-Version(pri:alt)  New-Version          Upg-Required
  ------  -------  -------------------------------------- --------------------  ------------
    1      nxos                               7.0(3)I7(3)          9.2(1)I9(1)           yes
    1      bios     v05.31(05/17/2018):v05.26(11/06/2017)   v05.31(05/17/2018)            no
  
  
  Switch will be reloaded for disruptive upgrade.
  Do you want to continue with the installation (y/n)?  [n] y
  

• On performing a non-disruptive ISSU from Cisco NX-OS Release 7.0(3)I6(1) to any higher version, a traffic loss might occur based on the number of VLANs configured. To avoid traffic loss, it is recommended to increase the routing protocol's graceful restart timer to higher value. The recommended value of the graceful restart timer is 600 seconds. You can further increase or decrease this value based on the scale of the configuration.

• ISSUs are supported on the following platforms:

  Note

  An enhanced ISSU can be performed only from a Cisco NX-OS Release 7.0(3)I5(1) to a later image. The upgrade will be disruptive. A non-disruptive standard ISSU is supported from Cisco NX-OS Release 7.0(3)I7(4), 7.0(3)I7(5), or 9.2(x) to a Cisco NX-OS 9.2(x) release. A non-disruptive enhanced ISSU to a Cisco NX-OS 9.2(x) release is not supported as there are kernel fixes that cannot take effect without reloading the underlying kernel. The upgrade will be disruptive. For more information, see the ISSU Support Matrix.

  Series	Supported Platforms	Initial Release That Supports ISSU 1	Features Not Supported with ISSU2
  Cisco Nexus 9200	Standard and enhanced ISSU: Cisco Nexus 9236C, 9272Q, 92160YC-X, 92300YC, and 92304QC	Standard ISSU: 7.0(3)I6(1) Enhanced ISSU: 7.0(3)I7(3)	Segment routing, and Tetration
  Cisco Nexus 9300	Standard and enhanced ISSU: Cisco Nexus 9332PQ, 9372PX, 9372PX-E, 9372TX, 9372TX-E, 9396PX, 9396TX, 93120TX, and 93128TX Note   ISSU on one of these Cisco Nexus 9300 platform switches is supported when the switch is the spanning tree root. You can use the show spanning-tree issu-impact command to verify if the switch meets this criteria.	Standard ISSU: 7.0(3)I3(1) Enhanced ISSU: 7.0(3)I5(1)	Dual-homed FEX, segment routing, MACsec, and VXLAN Note   Straight-through FEX is supported on Cisco Nexus 9372PX and 9396PX switches starting with Cisco NX-OS Release 7.0(3)I4(1).
  Cisco Nexus 9300-EX	Standard and enhanced ISSU: Cisco Nexus 93108TC-EX, 93180LC-EX, and 93180YC-EX	Standard ISSU for Cisco Nexus 93108TC-EX and 93180YC-EX: 7.0(3)I6(1) Standard ISSU for Cisco Nexus 93180LC-EX: 7.0(3)I7(1) Enhanced ISSU: 7.0(3)I7(3)	Straight-through and dual-homed FEX, segment routing, MACsec, and Tetration
  Cisco Nexus 9300-FX	Standard ISSU: None Enhanced ISSU: None		MACsec
  Cisco Nexus 9500	Standard ISSU: Cisco Nexus 9504, 9508, and 9516 with 9432PQ, 9464PX, 9464TX, 9536PQ, 9564PX, 9564TX, or 9636PQ line cards, dual supervisor modules, and a minimum of two system controllers and two fabric modules Note   Cisco Nexus 9500 platform switches with -R, -EX, and -FX line cards do not support ISSU. Enhanced ISSU: None	Standard ISSU: 7.0(3)I3(1)	Dual-homed FEX, segment routing, and VXLAN Note   Straight-through FEX is supported on Cisco Nexus 9500 platform switches with a Cisco Nexus 9464PX or 9564PX line card starting with Cisco NX-OS Release 7.0(3)I4(1).
  Cisco Nexus 3000 that run Cisco Nexus 9000 NX-OS software	Standard ISSU: Cisco Nexus 3164Q, 31128PQ, 3132Q-V, 31108PC-V, 31108TC-V, 3232C, and 3264Q Enhanced ISSU: 3164Q, 31128PQ, 3132Q-V, 31108PC-V, and 31108TC-V	Standard ISSU for Cisco Nexus 3164Q and 31128PQ: 7.0(3)I3(1) Standard ISSU for 3132Q-V, 31108PC-V,31108TC-V, 3232C, and 3264Q: 7.0(3)I6(1) Enhanced ISSU for 3164Q, 31128PQ, 3132Q-V, 31108PC-V, and 31108TC-V: 7.0(3)I5(1)	Segment routing, and VXLAN for Cisco Nexus 3164Q and 31128PQ Segment routing for Cisco Nexus 3232C and 3264Q

  ¹ Enhanced ISSU is disruptive.

  ² ISSU is disruptive for these features.

• Segment list configuration fails to apply after you cold boot upgrade from Cisco NX-OS 9.2x Releases. It is recommended to upgrade using "install all" command.

Before attempting to downgrade to an earlier software release, follow these guidelines:

• The only supported method of downgrading a Cisco Nexus 9000 Series switch is to utilize the install all command. Changing the boot variables, saving the configuration, and reloading the switch is not a supported method to downgrade the switch.

• Disable the Guest Shell if you need to downgrade from Cisco NX-OS Release 7.0(3)I7(7) to an earlier release.

• Software downgrades should be performed using the install all command. Changing the boot variables, saving the configuration, and reloading the switch is not a supported method to downgrade the switch.

• iCAM must be disabled before downgrading from Release Release 9.2(x) or Release 9.3(x) → 7.0(3)I7(1). Only Release 9.3(1) → Release 9.2(4) can be performed if iCAM is enabled.

• On devices with dual supervisor modules, both supervisor modules must have connections on the console ports to maintain connectivity when switchovers occur during a software downgrade. See the Hardware Installation Guide for your specific chassis.

• Cisco NX-OS automatically installs and enables the guest shell by default. However, if the device is reloaded with a Cisco NX-OS image that does not provide guest shell support, the existing guest shell is automatically removed and a %VMAN-2-INVALID_PACKAGE message is issued. As a best practice, remove the guest shell with the guestshell destroy command before downgrading to an earlier Cisco NX-OS image.

• You must delete the switch profile (if configured) when downgrading from a Cisco NX-OS release that supports switch profiles to a release that does not. For more information, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.

• Software downgrades are disruptive. In-service software downgrades (ISSDs), also known as nondisruptive downgrades, are not supported.

• Downgrading with PVLANs (Private VLANs) configured is only supported with Cisco NX-OS 6.1(2)I3(4x) releases.

• For a boot-variable change and reload to Cisco NX-OS Release 7.0(3)I1(1x), the PVLAN process is not brought up, and the PVLAN ports are kept down. For a boot-variable change to the Cisco NX-OS Release 6.1(2)I3(3) and earlier, an ASCII replay will be tried, but feature PVLANs and other PVLAN configurations will fail.

For ISSU compatibility for all releases, see the Cisco NX-OS ISSU Support Matrix.