Cisco Nexus 7000 Series NX-OS Release Notes, Release 8.4

---

Table 1 Change History

Date	Description
August 13, 2024	Created release notes for Cisco NX-OS Release 8.4(10).
December 08, 2023	Created release notes for Cisco NX-OS Release 8.4(9).
August 10, 2023	Created release notes for Cisco NX-OS Release 8.4(8).
May 26, 2023	Added Cisco NX-OS Release 8.2(10) to theUpgrade and Downgrade Paths and Caveats section.
February 03, 2023	Created release notes for Cisco NX-OS Release 8.4(7).
December 08, 2022	Created release notes for Cisco NX-OS Release 8.4(6a).
September 30, 2022	Added Cisco NX-OS Release 8.2(9) to theUpgrade and Downgrade Paths and Caveats section.
June 03, 2022	Created release notes for Cisco NX-OS Release 8.4(6).
Feb 02, 2022	Added Cisco NX-OS Release 7.3(9)D1(1) to theUpgrade and Downgrade Paths and Caveats section.
December 03, 2021	Added Cisco NX-OS Release 8.2(8) to theUpgrade and Downgrade Paths and Caveats section.
August 30, 2021	Created release notes for Cisco NX-OS Release 8.4(5).
July 12, 2021	Created release notes for Cisco NX-OS Release 8.4(4a).
July 02, 2021	Added Cisco NX-OS Release 7.3(8)D1(1) to theUpgrade and Downgrade Paths and Caveats section.
June 25, 2021	Added Cisco NX-OS Release 8.2(7a) to theUpgrade and Downgrade Paths and Caveats section.
February 22, 2021	Created release notes for Cisco NX-OS Release 8.4(4).
January 08, 2021	Added Cisco NX-OS Release 7.3(7)D1(1) to the Upgrade and Downgrade Paths and Caveats section.
October 06, 2020	Added N77-F312CK-26 to the “Cisco Nexus 7000 Series Switches and Cisco Nexus 7700 Switches Hardware Support” table.
September 23, 2020	Created release notes for Cisco NX-OS Release 8.4(3).
July 24, 2020	Added Cisco NX-OS Release 8.2(6) to theUpgrade and Downgrade Paths and Caveats section.
April 17, 2020	Added Cisco NX-OS Release 7.3(6)D1(1) to theUpgrade and Downgrade Paths and Caveats section.
March 26, 2020	Created release notes for Cisco NX-OS Release 8.4(2).
July 10, 2019	Created release notes for Cisco NX-OS Release 8.4(1).

Supported Device Hardware

The Cisco NX-OS software supports the Cisco Nexus 7000 Series that includes Cisco Nexus 7000 switches and Cisco Nexus 7700 switches. You can find detailed information about supported hardware in the Cisco Nexus 7000 Series Hardware Installation and Reference Guide.

---

Note Cisco Nexus 7000 Supervisor 1 modules, M1 series modules (XL and non-XL modes), FAB-1 modules, F2 series modules are not supported in Cisco NX-OS Release 8.x.

---

Note There are no new hardware features introduced in Cisco NX-OS Release 8.4(1) and in Cisco NX-OS Release 8.4(2).

Table 2 shows the Cisco Nexus 7000 Series Switch and Cisco Nexus 7700 Switch hardware support details.

Table 3 shows the Fabric Extender (FEX) modules supported by the Cisco Nexus 7000 and Cisco Nexus 7700 I/O modules.

Table 4 shows the transceiver devices supported in each release of Cisco Nexus 7000 Series.

For a list of minimum recommended Cisco NX-OS software releases for use with Cisco Nexus 7000 Series switches, see the document titled Minimum Recommended Cisco NX-OS Releases for Cisco Nexus 7000 Series Switches.

1.FEX server-facing interfaces should be configured in autonegotiate mode. Do not force a specific data rate.

---

Note The Cisco Nexus 7000 Enhanced F2 Series 48-port 1/10 GBASE-T RJ-45 Module (N7K-F248XT-25E) does not support Cisco Nexus 2000 FEXs.

---

Note FEX modules does not support M3 series modules in Cisco NX-OS Release 7.3(0)DX(1), Cisco NX-OS Release 7.3(1)D1, and in Cisco NX-OS Release 8.0(1).

 

 

¹ Minimum version supported is -02.

² CWDM-SFP-xxxx is supported only with 1-Gigabit Ethernet I/O modules.

³ DWDM-SFP10G-C is not supported.

⁴ For Cisco NX-OS 8.x releases, CPAK-100G-SR4 is supported from Cisco NX-OS Release 8.1(1).

^# If you remove and reinsert a CPAK, reinsertion must be delayed by at least 30 seconds. This enables the device to discharge completely and power up properly upon reinsertion.

---

Note For a complete list of supported optical transceivers, see the Cisco Transceiver Module Compatibility Information page.

Guidelines and Limitations—Cisco NX-OS Release 8.4(10)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(10). The guidelines listed for Cisco NX-OS Release 8.4(6) is also applicable to Cisco NX-OS Release 8.4(10).

Guidelines and Limitations—Cisco NX-OS Release 8.4(9)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(9). The guidelines listed for Cisco NX-OS Release 8.4(6) is also applicable to Cisco NX-OS Release 8.4(9).

Guidelines and Limitations—Cisco NX-OS Release 8.4(8)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(8). The guidelines listed for Cisco NX-OS Release 8.4(6) is also applicable to Cisco NX-OS Release 8.4(8).

Guidelines and Limitations—Cisco NX-OS Release 8.4(7)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(7). The guidelines listed for Cisco NX-OS Release 8.4(6) is also applicable to Cisco NX-OS Release 8.4(7).

Guidelines and Limitations—Cisco NX-OS Release 8.4(6a)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(6a). The guidelines listed for Cisco NX-OS Release 8.4(6) is also applicable to Cisco NX-OS Release 8.4(6a).

Guidelines and Limitations—Cisco NX-OS Release 8.4(6)

For Cisco NX-OS Release 8.4(6), when you attempt to add 5th VDC when system is running on low memory, an error message is displayed.

Guidelines and Limitations—Cisco NX-OS Release 8.4(5)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(5).The guidelines listed for Cisco NX-OS Release 8.4(2) is also applicable to Cisco NX-OS Release 8.4(5).

Guidelines and Limitations—Cisco NX-OS Release 8.4(4a)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(4a).The guidelines listed for Cisco NX-OS Release 8.4(2) is also applicable to Cisco NX-OS Release 8.4(4a).

Guidelines and Limitations—Cisco NX-OS Release 8.4(4)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(4).The guidelines listed for Cisco NX-OS Release 8.4(2) is also applicable to Cisco NX-OS Release 8.4(4).

Guidelines and Limitations—Cisco NX-OS Release 8.4(3)

There are no specific guidelines and limitations applicable to Cisco NX-OS Release 8.4(3).The guidelines listed for Cisco NX-OS Release 8.4(2) is also applicable to Cisco NX-OS Release 8.4(3).

Guidelines and Limitations—Cisco NX-OS Release 8.4(2)

For Cisco NX-OS Releases 8.4(2) when you attempt to add 5th VDC when system is running on low memory, the system crashes.

Guidelines and Limitations—Cisco NX-OS Release 8.4(1)

The following guidelines and limitations are applicable to Cisco NX-OS Release 8.4(1):

• A system configured with EIGRP 64bit metric version and having 32bit metric version neighbors precision in delay conversion from 64bit metric to 32bit metric and from 32bit metric to 64bit metric is improved. It implies that the 32bit metric of prefixes in the 64bit EIGRP system and 64bit metric of prefixed in 32bit EIGRP system changes from previous releases. This is not applicable for the 32bit metric EIGRP system or if all neighbors are the 64bit metric version.
• Support for the RISE feature has been deprecated in Cisco NX-OS Release 8.4(1).
• In a system with large routing table of approximately 250K routes and over, a M3 module upon reload may go online before the full routing table is populated in its TCAM. This issue is fixed in CSCvn25428.However, even with the fix in CSCvn25428, if multiple M3 modules reload in tandem, some of the modules may go online without the full routing table in TCAM. There is no fix for this case. This is a known limitation.
• Beginning with Cisco NX-OS Release 8.4(1), it is recommended to use agent-less configuration management systems such as Puppet or Ansible with the Cisco Nexus 7000 Series switches; as the Open Agent Container (OAC) support will be deprecated in the future releases. This OAC feature was added in the Cisco NX-OS Release 7.3(0)D1(1) with the purpose of providing and execution space for configuration management. For more details see Cisco Nexus 7000 Series NX-OS Programmability Guide.
• Cisco NX-OS Release 8.4(1) addresses a vulnerability, CVE-2019-1649 in N77-SUP3E platform.  After upgrading or booting to Cisco NX-OS Release 8.4(1), an explicit EPLD upgrade needs to be done to address this vulnerability effectively. EPLD upgrade can be initiated using the install module sup_module_no epld system path_of_system_image command. This step is not needed if the setup has auto epld upgrade option enabled. 
• When you upgrade Supervisor 2, Supervisor 2E, and Supervisor 3E to Cisco NX-OS Release 8.4(1) with dual supervisors, the management interface of the of HA-Standby supervisor flaps every 30 minutes. The flap is detected on the peer switch interface, which is connected to the mgmt 0 interface of HA-Standby as link down event.
  The flap occurs because of the new feature introduced in Cisco NX-OS Release 8.4(1) where the management loopback test is run periodically on the HA-Standby supervisor. This is an expected behaviour.
  In order stop the link flap on peer switch this loopback test has to be disabled. To disable the loopback test for standby supervisor run the no diagnostic monitor module <standby sup module number> test 15 command on the active supervisor.
• With the new BIOS, the image name length for Supervisor 2, Supervisor 2E, and Supervisor 3E modules is changed to a maximum of 256 characters. Meanwhile, the image name length is still restricted to 128 characters for kick start and system images. Hence make sure that you do not use more than 128 characters in image names.
• During the supervisor 2 to supervisor 3 module migration do not disturb the testbed, i.e., do not plug in or plug out, power down, reload, and reset the modules and ports. If you do any of these tasks the migration might fail or might give undesirable results. You can use only the show commands during the migration.
• The default max-bundle value has been enhanced to 32 for Cisco Nexus 7000 Series switch from Cisco NX-OS Release 8.4(1). The previous max-bundle value of 16 is now considered as non-default and this value is displayed in the show running configuration and show running all configuration output after the upgrade to Cisco NX-OS Release 8.4(1). You can configure no lacp max-bundle 16 on previously configured port-channel to reflect system default to 32.

For information on features related to Cisco NX-OS Release 8.4(1) see New and Enhanced Software Features - Cisco NX-OS Release 8.4(1).

Guidelines and Limitations Common for Cisco NX-OS Release 8.x

The following guidelines and limitations are applicable to Cisco NX-OS Release 8.0(1) and later releases.

Beginning with Cisco NX-OS Release 8.0(1), the following M1-Series I/O modules are not supported:

• Cisco Nexus 7000 M1-Series 48-port Gigabit Ethernet Module with XL Option (SFP optics) (N7K-M148GS-11L)
• Cisco Nexus 7000 M1-Series 48-port 10/100/1000 Ethernet Module with XL Option (RJ45) (N7K-M148GT-11L)
• Cisco Nexus 7000 M1-Series 32 Port 10GbE with XL Option, 80G Fabric (requires SFP+) (N7K-M132XP-12L)
• Cisco Nexus 7000 M1-Series 8-Port 10 Gigabit Ethernet Module with XL Option (requires X2) (N7K-M108X2-12L)

Beginning with Cisco NX-OS Release 8.0(1), the following F2-Series I/O modules are not supported:

• Nexus 7000 F2-Series 48 Port 1G/10G Ethernet Module, SFP/SFP+ (and spare) (N7K-F248XP-25, N7K-F248XP-25=)

N7K-SUP2

Cisco NX-OS Release 8.x utilizes more memory than earlier NX-OS releases. As a result, N7K-SUP2 (Non-enhanced) experiences low memory condition with multi-dimensional scale.

Refer to Cisco Nexus 7000 Series NX-OS Verified Scalability Guide for more information.

Starting from NX-OS Release 8.2(9) and Release 8.4(6), low memory syslog threshold alerts are set as mentioned below:

Prior to Release 8.2(9) and Release 8.4(6) in release 8.x train the thresholds must be configured through NX-OS CLI:

system memory-thresholds minor 80 severe 85 critical 91

You can use the following NX-OS commands to monitor memory usage:

VXLAN BGP EVPN in VDCs having M3 modules

The following features are not supported for VXLAN BGP EVPN in VDCs having M3 modules:

• EVPN VXLAN leaf functionality (except Border Leaf functionality) is not supported.
• LISP hand off is not supported.
• Hosts connected behind FEX is not supported.

EVPN Border Leaf Hand Off Limitation in M3 Module

This limitation is on the EVPN to VRF lite hand off.

If EVPN fabric connected interface is on a M3 module and VRF lite interface is on F3 module, south to north traffic will be dropped on the border leaf.

Smart Licensing Show Commands are Missing on Non-Default VDC Context

Smart Licensing show commands are missing on the non-default VDC context. The work around is to use the default VDC to verify license related show outputs.

OTV Traffic Fails on VXLAN EVPN Border Leaf Due To ARP Resolution Failure

OTV traffic fails on VXLAN EVPN border leaf due to ARP resolution failure. This issue occurs on the following conditions:

• Dual switch VPC Border Leaf
• M3 only VDC setup
• vPC legs connected to OTV VDC
• Reloading the switch
• Using shutdown and no shutdown commands on the port-channel logical interface

The workaround to his issue is to do a ‘shutdown’ and ‘no shutdown’ of vPC port-channel member interfaces from both the vPC switches and then re-send the ARP for the flows.

---

Note Port-channel interface shut and no shut may not work,

Native VLAN Change Causes Link Flap

Changing the native VLAN on an access port or trunk port will flap the interface. This behavior is expected.

Passive Copper Optic Cables are not Supported on the Non EDC Ports

Passive copper optic cables are not supported on the non-EDC ports.

The delay in link up event in SFP+ implementation is due to a factor called Electronic Dispersion Compensation (EDC). EDC ports mitigate power penalties associated with optical link budgets. Receivers without EDC (for example - SFP, where there is no delay in bringing the port up) can recover an optical signal only if the dispersion is less than approximately one-half Unit Interval (UI) over the length of fiber.

QSFP passive copper (QSFP-H40G-CU1M, QSFP-H40G-CU3M, QSFP-H40G-CU5M), and copper breakout cables (QSFP-4SFP10G-CU1M, QSFP-4SFP10G-CU3M, QSFP-4SFP10G-CU5M) are not supported on the following modules:

– N7K-M206FQ-23L

– N7K-F312FQ-25

– N77-F324FQ-25

The workaround to this limitation is to use active optical cables (QSFP-H40G-AOC1M, QSFP-H40G-AOC3M, QSFP-H40G-AOC5M) and active optical breakout cables (QSFP-4X10G-AOC1M, QSFP-4X10G-AOC3M, QSFP-4X10G-AOC5M).

The passive optics (N7K M3 40G, N77 M3 40G, and N77 M3 100G) are not supported on the following modules:

– N7K-M324FQ-25L

– N77-M324FQ-25L

– N77-M312CQ-26L

MPLS over GRE

MPLS over GRE is not supported on F3 modules.

VLAN Translation on Fabric Extender Is Not Supported

VLAN translation on fabric extender is not supported. If you need to map a VLAN, you must move the interface to the parent switch and then configure the VLAN translation on the switches directly. The VLAN translation configuration is applicable for trunk ports connecting two data centers.

The no hardware ejector enable Command is Not Recommended for Long-Term Use

The no hardware ejector enable command cannot be configured and persistently saved in the startup configuration. This command is intended for temporary usage.

To work around this limitation, do not physically remove an active supervisor. Instead, use the system switchover command to switch to the standby supervisor.

This applies only to the Cisco Nexus 7700 Series switches.

Saving VLAN Configuration Information

Because a VLAN configuration can be learned from the network while the VLAN Trunking Protocol (VTP) is in a server/client mode, the VLAN configuration is not stored in the running configuration. If you copy the running configuration to a file and apply this configuration at a later point, including after a switch reload, the VLANs will not be restored. However, the VLAN configuration will be erased if the switch is the only server in the VTP domain.

To work around this limitation, perform one of the following tasks:

• Configure one of the clients as the server.
• Complete these steps:

1. Copy the VTP data file to the bootflash: data file by executing the copy vtp-datafile bootflash:vtp-datafile command.

2. Copy the ASCII configuration to the startup configuration by executing the copy ascii-cfg-file startup-config command.

3. Reload the switch.

This limitation does not apply to a binary configuration, which is the recommended approach, only for an ASCII configuration.

Behavior of Control Plane Packets in an F2e Series Module

To support the coexistence of an F2e Series module with an M Series module in the same VDC, the F2e Series module operates in a proxy mode so that all the Layer 3 traffic is sent to an M Series module in the same VDC. For F2e proxy mode, having routing adjacencies connected through F2e interfaces with an M1 Series module is not supported. However, routing adjacencies connected through F2e interfaces with an M2 Series module is supported.

Error Appears When Copying a File to the Running Configuration

Copying a file to the running configuration can trigger an error and the following message is displayed:

 

This issue might occur if the configuration contains SNMP-related configurations to send traps or notifications, and if the file that is to be copied to the running configuration contains only EXEC show commands.

When the following message is displayed, enter y.

 

Note that there is no operational impact and no configuration loss when the switch reloads.

PONG in a vPC Environment

PONG is not supported in a vPC environment in the following scenarios:

• In a vPC environment, a PONG to an access switch or from an access switch might fail. To work around this issue, use the interface option while executing a PONG from an access switch to a vPC peer. The interface can be one that does not have to go over the peer link, such as an interface that is directly connected to the primary switch.
• When FabricPath is enabled and there are two parallel links on an F2 Series module, PONG might fail. To work around this issue, form a port channel with the two links as members.

For more details on PONG, refer to the Cisco Nexus 7000 Series NX-OS Troubleshooting Guide.

LISP Traffic

A Layer 3 link is required between aggregation switches when deploying LISP host mobility on redundant LISP Tunnel Routers (xTRs) that are a part of a vPC. In rare (but possible) scenarios, failure to deploy this Layer 3 link might result in traffic being moved to the CPU and potentially dropped by the Control Plane Policing (CoPP) rate limiters.

Standby Supervisor Might Reset with a Feature-Set Operation

The standby supervisor might reload when a feature-set operation (install, uninstall, enable, or disable) is performed if the high availability (HA) state of the standby supervisor is not “HA standby” at the time of the feature-set operation. To prevent the reload, ensure that the state of the standby supervisor is “HA standby.” To check the HA state for the specific virtual device context (VDC) where the feature-set operation is performed, enter the show system redundancy ha status command on the active supervisor.

A reload of the standby supervisor has no operational impact because the active supervisor is not affected.

In addition, if you perform a feature-set operation while modules are in the process of coming up, then those modules are power cycled. Modules that are up and in the OK state are not power cycled when you perform a feature-set operation.

Unfair Traffic Distribution for Flood Traffic

Uneven load balancing of flood traffic occurs when you have a seven-member port channel. This behavior is expected, and occurs on all M Series and F Series modules. In addition, M Series modules do not support Result Bundle Hash (RBH) distribution for multicast traffic.

BFD Not Supported on the MTI Interface

If bidirectional forwarding detection (BFD) on Protocol Independent Multicast (PIM) is configured together with MPLS multicast VPN (MVPN), the following error might appear:

 

This error is benign. To avoid the error, disable BFD on the multicast tunnel interface (MTI) interface.

For every multicast domain of which an multicast VRF is a part, the PE router creates a MTI. MTI is an interface the multicast VRF uses to access the multicast domain.

Role-Based Access Control

You can configure role-based access control (RBAC) in the Cisco Nexus 7000 storage VDC using Cisco NX-OS CLI commands. You cannot configure RBAC in the Cisco Nexus 7000 storage VDC using Cisco Data Center Network Manager (DCNM). Note that RBAC in the storage VDC and in the Cisco Nexus 7000 Series switches is the same, which is different from that for the Cisco MDS 9500 Series Multilayer Directors.

RBAC CLI scripts used in Cisco MDS 9500 Series Multilayer Directors cannot be applied to the storage VDC configured for a Cisco Nexus 7000 Series switch.

You cannot distribute the RBAC configuration between a Cisco MDS 9500 Series switch and the storage VDC configured for a Cisco Nexus 7000 Series switch. To prevent this distribution, assign RBAC in Cisco MDS and the Cisco Nexus 7000 storage VDC to different Cisco Fabric Services (CFS) regions.

Limitation on the Level 4 Protocol Entries on the M Series Modules

The M Series modules support only 7 entries for Layer-4 protocols (L4Ops).

Network Analysis Module (NAM-NX1)

Cisco Nexus 7000 Series Network Analysis Module (NAM-NX1) is not supported.

SVI Statistics on an F2 Series Module

From Cisco NX-OS Release 8.2(4), F2 Series I/O modules support per-VLAN statistics. The show interface command will display per-VLAN Rx or Tx counters or statistics for switch virtual interfaces (SVIs).

TrustSec SGT on the F3 Series Modules

F3 Series I/O modules require a dot1q header to be present for proper processing and transport of SGT-tagged packets. For Layer 2 switch ports use trunked interfaces instead of an access VLAN. Layer 3 interfaces should be configured as an L3 subinterface to force the dot1q over the L3 interconnection.

Fabric Module Removal on the Cisco Nexus 7700 Switches

When a fabric module is power cycled or removed momentarily during an online insertion and removal (OIR) from slot 5 or slot 6 on a Fabric 2 module in a Cisco Nexus 7700 switch, packet drops can occur. This limitation is not applicable to Cisco Nexus 7702 Switches.

Fabric Utilization on the Cisco Nexus 7700 Switches

When traffic ingresses from a module on the Cisco Nexus 7700 switch at a rate much below the line rate, uniform fabric utilization does not occur across the fabric modules. This behavior is expected and reflects normal operation based on the fabric autospreading technology used in the Cisco Nexus 7700 switch.

MTU Changes do not Take Effect on FEX Queues

When you change the interface MTU on a fabric port, the configured MTU on the FEX ports are not configured to the same value. This issue occurs when the interface MTU changes on a fabric port.

The configured MTU for the FEX ports is controlled by the network QoS policy. To change the MTU that is configured on the FEX ports, modify the network QoS policy to also change when the fabric port MTU is changed.

Multicast Traffic is Forwarded to FEX Ports

Multicast traffic that is sent to Optimized Multicast Flooding (OMF) Local Targeting Logic (LTL) is forwarded to FEX ports that are not a part of the bridge domain (BD). This issue occurs when multicast traffic is sent to OMF LTL, which occurs if an unknown unicast flooding occurs when OMF is enabled.

FEX interfaces can support multicast routers, but OMF must be disabled on those VLANs. If there is a multicast MAC address mismatch on the VLAN, traffic will be flooded in the VLAN and will eventually reach the router behind the FEX port.

F2 Connectivity Restrictions on Connecting Ports to an FEX

If an ASCII configuration has incompatible ports, such as when the configuration is created with ports that are added to an FEX from different modules or VDC types, the ports might be added without warnings.

When connecting F2 Series ports to the same FEX, make sure the VDC type is the same as in the source configuration that is being replicated.

DHCP Snooping and vPC+ FEX

DHCP snooping is not supported when the vPC+ FEX feature is enabled.

Supported Upgrade and Downgrade Paths

Before you upgrade or downgrade your Cisco NX-OS software, we recommend that you read the complete list of caveats in this section to understand how an upgrade or downgrade might affect your network, depending on the features that you have configured.

---

Note Do not change any configuration settings or network settings during a software upgrade. Changes to the network settings might cause a disruptive upgrade.

Releases that are not listed for a particular release train do not support a direct ISSU.

Non-disruptive in-service software downgrades (ISSD) are not supported in the Cisco NX-OS 8.x releases.

---

Note For a nondisruptive upgrade dual supervisor modules are required.

ISSU Paths for Cisco NX-OS Release 8.4(10)

See Table 5 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(10).

---

Note Only the ISSU paths/combinations in Table 5 have been tested and are supported.

Table 6 Supported ISSU Paths for Cisco Nexus 7000 Series Switches and Cisco Nexus 7700 Switch (Cisco NX-OS Release 8.4(9)

ISSU Paths for Cisco NX-OS Release 8.4(9)

See Table 7 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(9).

---

Note Only the ISSU paths/combinations in Table 7 have been tested and are supported.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(8)

See Table 8 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(8).

---

Note Only the ISSU paths/combinations in Table 8 have been tested and are supported.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(7)

See Table 9 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(7).

---

Note Only the ISSU paths/combinations in Table 9 have been tested and are supported.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(6a)

See Table 10 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(6a).

---

Note Only the ISSU paths/combinations in Table 10 have been tested and are supported.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(6)

See Table 11 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(6).

---

Note Only the ISSU paths/combinations in Table 11 have been tested and are supported.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(5)

See Table 12 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(5).

---

Note Only the ISSU paths/combinations in Table 12 have been tested and are supported.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(4a)

See Table 13 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(4a).

---

Note Only the ISSU paths/combinations in Table 13 have been tested and are supported.

---

Note ISSU from 8.2(8) to any higher releases like 8.3(1), 8.3(2), 8.4(1), 8.4(2), 8.4(3), 8.4(4), 8.4(4a) will be disruptive if M3 linecards are present.

---

Note After ISSU from 8.2(7) or 8.4(4) to 8.4(4a) and if SCALABLE_SERVICES_PKG is installed and in use, you must reload M2 linecard.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(4)

See Table 14 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(4).

---

Note Only the ISSU paths/combinations in Table 14 have been tested and are supported.

---

Note ISSU from 8.2(8) to any higher releases like 8.3(1), 8.3(2), 8.4(1), 8.4(2), 8.4(3), 8.4(4), 8.4(4a) will be disruptive if M3 linecards are present.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(3)

See Table 15 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(3).

---

Note Only the ISSU paths/combinations in Table 15 have been tested and are supported.

 

---

Note ISSU from 8.2(8) to any higher releases like 8.3(1), 8.3(2), 8.4(1), 8.4(2), 8.4(3), 8.4(4), 8.4(4a) will be disruptive if M3 linecards are present.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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

ISSU Paths for Cisco NX-OS Release 8.4(2)

See Table 16 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.4(2).

---

Note Only the ISSU paths/combinations in Table 16 have been tested and are supported.

 

---

Note ISSU from 8.2(8) to any higher releases like 8.3(1), 8.3(2), 8.4(1), 8.4(2), 8.4(3), 8.4(4), 8.4(4a) will be disruptive if M3 linecards are present.

If you are doing ISSU from a release other than the non-disruptive upgrade releases listed in the above table, that ISSU is disruptive in quality and requires the switch to reload.

If two successive ISSUs are performed between major releases (Multi-hop ISSU), a switch reload is required before the second ISSU.

Note

1. Multi-hop ISSU term refers to two successive ISSUs between major releases.

2. A major release introduces significant new software features, hardware platforms.
The different major releases of Nexus 7000/7700 are 6.0.x, 6.1.x, 6.2.x, 7.0.x, 7.1.x, 7.2.x, 7.3.x, 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x.
For example - Consider an upgrade from 8.1(1) TO 8.4(5).
The upgrade path - ISSU from 8.1(1) to 8.2(3) followed by ISSU from 8.2(3) to 8.2(5) and then followed by ISSU from 8.2(5) to 8.4(5) regardless of the timeframe.
The procedure for the ISSU upgrade path is as follows:

Step 1 ISSU from major release 8.1(1) to another major release 8.2(3).

Step 2 ISSU from 8.2(3) to 8.2(5) is within the same major release 8.2.x.

Step 3 ISSU from major release 8.2(5) to another major release 8.4(5).

Step 4 Step 1 and 3 are successive ISSUs between two different major releases. Hence before Step 3, a reload is required.

You will be prompted with the below information during the second ISSU. You must abort the ISSU, do a switch reload, and then proceed with the ISSU.

Multiple Major ISSU has been performed on this switch. We recommend doing a binary reload instead of upgrading.

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