Cisco Nexus 7000 Series NX-OS 8.x, Release Notes
Guidelines and Limitations - Cisco NX-OS Release 8.2(9)
Guidelines and Limitations—Cisco NX-OS Release 8.2(3)
Guidelines and Limitations—Cisco NX-OS Release 8.2(2)
Guidelines and Limitations—Cisco NX-OS Release 8.2(1)
Guidelines and Limitations—Cisco NX-OS Release 8.1(1)
Guidelines and Limitations—Cisco NX-OS Release 8.0(1)
Guidelines and Limitations Common for Cisco NX-OS Release 8.0(1) and Cisco NX-OS Release 8.1(1)
Upgrade and Downgrade Paths and Caveats
Supported Upgrade and Downgrade Paths
ISSU Paths for Cisco NX-OS Release 8.2(11)
ISSU Paths for Cisco NX-OS Release 8.2(10)
ISSU Paths for Cisco NX-OS Release 8.2(9)
ISSU Paths for Cisco NX-OS Release 8.2(8)
ISSU Paths for Cisco NX-OS Release 8.2(7a)
ISSU Paths for Cisco NX-OS Release 8.2(6)
ISSU Paths for Cisco NX-OS Release 8.2(5)
ISSU Paths for Cisco NX-OS Release 8.2(4)
ISSU Paths for Cisco NX-OS Release 8.2(3)
ISSU Paths for Cisco NX-OS Release 8.2(2)
ISSU Paths for Cisco NX-OS Release 8.1(2a)
ISSU Paths for Cisco NX-OS Release 8.1(2)
ISSU Paths for Cisco NX-OS Release 8.2(1)
ISSU Paths for Cisco NX-OS Release 8.1(1)
ISSU Paths for Cisco NX-OS Release 8.0(1)
In-Service Software Upgrade (ISSU) Caveats
Non-ISSU Upgrade/Cold Boot Upgrade
Non-In-Service Software Upgrade (Non-ISSU)/Cold Boot Upgrade Caveats
Erasable Programmable Logic Device Images
New and Enhanced Software Features
Cisco NX-OS Release 8.2(8) Software Features
Cisco NX-OS Release 8.2(6) Software Features
Cisco NX-OS Release 8.2(4) Software Features
Cisco NX-OS Release 8.2(3) Software Features
Cisco NX-OS Release 8.1(2) Software Features
Cisco NX-OS Release 8.2(1) Software Features
Cisco NX-OS Release 8.1(1) Software Features
Cisco NX-OS Release 8.0(1) Software Features
Intelligent CAM Analytics and Machine-learning (iCAM)
X.509v3 Certificate-Based SSH Authentication
Flexible ACL TCAM bank chaining feature for M3
SGACL Policy Enforcement Per Interface
Integrity Measurement Architecture (IMA)/Runtime Integrity
IPv6 First-Hop Security Features
vPC enhancements for Hitless vPC role change
Fault Management (Trigger Based Auto Capture of Logs and MTS Statistics Collection)
EtherChannel Symmetric Hash for Ipv6
Open Caveats—Cisco NX-OS Release 8.2(7a)
Open Caveats—Cisco NX-OS Release 8.2(5)
Open Caveats—Cisco NX-OS Release 8.2(4)
Open Caveats—Cisco NX-OS Release 8.2(3)
Open Caveats—Cisco NX-OS Release 8.2(2)
Open Caveats—Cisco NX-OS Release 8.1(2)
Open Caveats—Cisco NX-OS Release 8.2(1)
Open Caveats—Cisco NX-OS Release 8.1(1)
Open Caveats—Cisco NX-OS Release 8.0(1)
Resolved Caveats-Cisco NX-OS Release 8.2(11)
Resolved Caveats-Cisco NX-OS Release 8.2(10)
Resolved Caveats—Cisco NX-OS Release 8.2(9)
Resolved Caveats—Cisco NX-OS Release 8.2(8)
Resolved Caveats—Cisco NX-OS Release 8.2(7a)
Resolved Caveats—Cisco NX-OS Release 8.2(6)
Resolved Caveats—Cisco NX-OS Release 8.2(5)
Resolved Caveats—Cisco NX-OS Release 8.2(4)
Resolved Caveats—Cisco NX-OS Release 8.2(3)
Resolved Caveats—Cisco NX-OS Release 8.2(2)
Resolved Caveats—Cisco NX-OS Release 8.1(2a)
Resolved Caveats—Cisco NX-OS Release 8.1(2)
Resolved Caveats—Cisco NX-OS Release 8.2(1)
Resolved Caveats—Cisco NX-OS Release 8.1(1)
Resolved Caveats—Cisco NX-OS Release 8.0(1)
Obtaining Documentation and Submitting a Service Request
First Published: December 22, 2016
Last Modified: February 16, 2024
This document describes the features, caveats, and limitations for Cisco NX-OS software for use on the Cisco Nexus 7000 Series Switches. Use this document in combination with documents listed in Related Documentation.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.
Note Release notes are sometimes updated with new information about restrictions and caveats. See the following website for the most recent version of the Cisco Nexus 7000 Series NX-OS Release Notes:
http://www.cisco.com/c/en/us/support/switches/nexus-7000-series-switches/products-release-notes-list.html
Table 1 shows the online change history for this document.
Updated the Supported Upgrade and Downgrade Paths section to include Cisco NX-OS Release 7.3(8)D1(1). |
|
Updated the Supported Upgrade and Downgrade Paths section to include Cisco NX-OS Release 7.3(7)D1(1). |
|
Updated the Supported Upgrade and Downgrade Paths section to include Cisco NX-OS Release 7.3(6)D1(1). |
|
Updated the Supported Upgrade and Downgrade Paths section to include Cisco NX-OS Release 7.3(5)D1(1). |
|
Updated the Supported Upgrade and Downgrade Paths section to include Cisco NX-OS Release 7.3(3)D1(1). |
|
Updated the Supported Upgrade and Downgrade Paths section to include Cisco NX-OS Release 7.3(2)D1(3a). |
|
Updated the Supported Upgrade and Downgrade Paths section to include Cisco NX-OS Release 7.3(2)D1(3). |
|
Updated the Cisco NX-OS Release 8.2(3) supports the following cold boot support matrix: section to include Cisco NX-OS Release 7.3(2)D1(1). |
|
Updated the Upgrade and Downgrade Paths and Caveats section to include Cisco NX-OS Release 6.2(18). |
|
This document includes the following sections:
The Cisco NX-OS software for the Cisco Nexus 7000 Series fulfills the routing, switching, and storage networking requirements of data centers and provides an Extensible Markup Language (XML) interface and a command-line interface (CLI) similar to Cisco IOS software.
This section includes the following topic:
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.
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.
48-port 1-/10-Gigabit Ethernet SFP+ I/O M3 Series module (N7K-M348XP-25L) 24-port 40-Gigabit Ethernet QSFP+ I/O M3 Series module (N7K-M324FQ-25L) |
||
12-port 40-Gigabit Ethernet QSFP I/O F3 Series module (N7k-F312FQ-25) |
N2K-B22HP1 |
|
6-port 40-Gigabit Ethernet I/O M2 Series module XL (N7K-M206FQ-23L) |
||
Breakout (4*10G) mode 40-Gigabit Ethernet I/O M2 Series module XL (N7K-M206FQ-23L) |
||
24-port 10-Gigabit Ethernet I/O M2 Series module XL (N7K-M224XP-23L) |
||
48-port 1/10 Gigabit Ethernet SFP+ I/O F3 Series module (N7K-F348XP-25) |
||
Enhanced 48-port 1/10 Gigabit Ethernet SFP+ I/O module (F2E Series) (N7K-F248XP-25E) |
||
48-port 1/10 Gigabit Ethernet SFP+ I/O module (F2E Series) (N77-F248XP-23E) |
||
24-port Cisco Nexus 7700 F3 Series 40-Gigabit Ethernet QSFP I/O module (N77-F324FQ-25) |
||
48-port Cisco Nexus 7700 F3 Series 1/10-Gigabit Ethernet SFP+ I/O module (N77-F348XP-23) |
||
48-Port 1/10 Gigabit Ethernet SFP+ I/O M3 Series module (N77-M348XP-23L) 24-Port 40 Gigabit Ethernet QSFP+ I/O M3 Series module (N77-M324FQ-25L) |
||
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).
Note For a complete list of supported optical transceivers, see the Cisco Transceiver Module Compatibility Information page.
This section includes the following topics:
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:
This section describes the guidelines and limitations for the Cisco Nexus 7000 Series in Cisco NX-OS Release 8.2(3).
This section describes the guidelines and limitations for the Cisco Nexus 7000 Series in Cisco NX-OS Release 8.2(2).
This section describes the guidelines and limitations for the Cisco Nexus 7000 Series in Cisco NX-OS Release 8.2(1).
For more information and workaround details refer to CSCvg09282.
In order to check and confirm if you come across this issue, look for the exact failure reason using the sh module internal exceptionlog module <mod_num> command.
This defect can affect a Cisco Nexus 7000 or Cisco Nexus 7700 chassis running M3 modules under the following condition. (This issue is specific to M3 modules and not applicable to F3 or any other modules.)
– OTV or VXLAN with scaled configuration close to 2K VLANs/BD extended.
– Network churn in a short period of time (multiple overlay flaps within 10 minutes) which involves bringing down the tunnels and recreating them in the system might lead to above symptoms.
The workaround for this issue is to reload the affected M3 module. To avoid re-occurrence of this problem, reduce the number of VLANs/BD extended over DCI.
A SMU for this fix is being tested and validated and will be published to the field.
VXLAN BGP EVPN and OTV inter operation feature has the following limitations on M3 modules for in Cisco NX-OS Release 8.2(1):
This section describes the guidelines and limitations in Cisco NX-OS Release 8.1(1) for the Cisco Nexus 7000 Series.
The number of VLANs per Fabric Extender server interface is 300 for M3 modules.
M3 FEX does not support the following features in Cisco NX-OS Release 8.1(1):
The following features are not supported on a VDC that has an M3 module:
This section describes the guidelines and limitations in Cisco NX-OS Release 8.0(1) for the Cisco Nexus 7000 Series.
The following features are not supported on a VDC that has an M3 module:
Cisco Nexus 7000 Series Network Analysis Module (NAM-NX1) is not supported.
The following guidelines and limitations are applicable to both the Cisco NX-OS Release 8.0(1) and Cisco NX-OS Release 8.1(1).
Beginning with Cisco NX-OS Release 8.0(1), the following M1-Series I/O modules are not supported:
Beginning with Cisco NX-OS Release 8.0(1), the following F2-Series I/O modules are not supported:
The following features are not supported for VXLAN BGP EVPN in VDCs having M3 modules:
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 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. This issue occurs on the following conditions:
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,
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.
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:
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:
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 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.
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:
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.
This limitation does not apply to a binary configuration, which is the recommended approach, only for an ASCII configuration.
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.
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 is not supported in a vPC environment in the following scenarios:
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.
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.
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.
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.
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.
The M Series modules support only 7 entries for Layer-4 protocols (L4Ops).
F2 Series I/O modules do not support per-VLAN statistics. Therefore, the show interface command will not display per-VLAN Rx or Tx counters or statistics for switch virtual interfaces (SVIs).
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.
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 Cisco Nexus 7700 switch, packet drops can occur. This limitation is not applicable to Cisco Nexus 7702 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.
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 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.
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.
This section includes information about upgrading and downgrading Cisco NX-OS software on Cisco Nexus 7000 Series switches. It includes the following sections:
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.
See Table 5 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(11).Only the ISSU paths/combinations in Table 5 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.
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.
See Table 6 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(10).Only the ISSU paths/combinations in Table 6 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.
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.
See Table 7 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(9).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.
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.
See Table 8 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(8).Only the ISSU paths/combinations in Table 8 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.
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.
See Table 9 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(7a).Only the ISSU paths/combinations in Table 9 have been tested and are supported.
Note After ISSU from 8.2(7) to 8.2(7a) and if SCALABLE_SERVICES_PKG is installed and is 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.
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.
See Table 10 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(6).
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.
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.
See Table 11 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(5).
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.
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.
See Table 12 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(4).
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.
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.
See Table 13 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(3).
Note Only the ISSU paths/combinations in Table 13 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.
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.
See Table 14 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(2).
Note Only the ISSU paths/combinations in Table 14 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.
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.
See Table 15 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.1(2a).
Note Only the ISSU paths/combinations in Table 15 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.
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.
See Table 16 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.1(2).
Note Only the ISSU paths/combinations in Table 16 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.
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.
See Table 17 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.2(1).
Note Only the ISSU paths/combinations in Table 17 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.
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.
See Table 18 for the in-service software upgrade (ISSU) path for Cisco NX-OS Release 8.1(1).
Note Only the ISSU combinations in the following table, Table 18 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.
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.
See Table 19 for the in-service software upgrade (ISSU) path for Cisco NX-OS Release 8.0(1).
Note Only the ISSU combinations in the following table, Table 19 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.
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.
To perform an ISSU to Cisco NX-OS Release 8.0(1) and later releases, follow these steps:
1. Enter the show running-config aclmgr inactive-if-config command for all VDCs.
2. Enter the clear inactive-config acl command for all VDCs.
3. If the configuration has any mac packet-classify configurations on any interfaces, remove all of the configurations by entering the no mac packet-classify command.
– RISE configuration must be removed prior to starting your upgrade to Cisco NX-OS Release 8.0(1). ISSU performs compatibility check and blocks the upgrade if RISE is configured.
ISSU upgrade from Cisco NX-OS 7.3.x releases to Cisco NX-OS Release 8.0(1) with VXLAN configuration in a vPC setup can result in a traffic loss when the second vPC peer is upgraded.
The following upgrade steps are recommended as the workaround for this issue:
– Shutdown vPC on the vPC secondary and reload with 8.0(1).
– Perform no shut vpc after the system is operational,
– Perform a vPC role change so that vPC secondary becomes a vPC primary.
– Shutdown vPC on the other peer that is still running 7.3 release and reload with 8.0(1).
– Perform no shut vpc after the system is operational,
– Optionally, a vPC role change can be performed to get the latest peer back to vPC primary.
– rlogin to the failing FEX—rlogin 192.0.2.<FEX-ID> -l root
– mount -t jffs2 -rw /dev/mtdblock5 /mnt/cfg
The mount command enables you to mount a file from a source folder to a destination folder.
– After ISSU upgrade, you must change the port-channel load balance for FEX, that is, from default VDC, in order to apply load balancing for SAN traffic:
Device(config)# port-channel load-balance src-dst mac fex 101
– You can revert back to the default load balance after changing the load balance for FEX.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/62_nx-os_release_note.html#pgfId-812362.
Cisco NX-OS Release 8.2(11) supports the following cold boot support matrix:
Table 20 Supported Cold Boot Matrix in Cisco NX-OS Release 8.2(11)
Cisco NX-OS Release 8.2(10) supports the following cold boot support matrix:
Table 21 Supported Cold Boot Matrix in Cisco NX-OS Release 8.2(10)
Cisco NX-OS Release 8.2(9) supports the following cold boot support matrix:
Cisco NX-OS Release 8.2(8) supports the following cold boot support matrix:
Cisco NX-OS Release 8.2(7a) supports the following cold boot support matrix:
Note After ISSU from 8.2(7) to 8.2(7a) and if SCALABLE_SERVICES_PKG is installed and is in use, you must reload M2 linecard.
Cisco NX-OS Release 8.2(6) supports the following cold boot support matrix:
Table 25 Supported Cold Boot Matrix in Cisco NX-OS Release 8.2(6)
Cisco NX-OS Release 8.2(5) supports the following cold boot support matrix:
Table 26 Supported Cold Boot Matrix in Cisco NX-OS Release 8.2(5)
Cisco NX-OS Release 8.2(4) supports the following cold boot support matrix:
Table 27 Supported Cold Boot Matrix in Cisco NX-OS Release 8.2(4)
Cisco NX-OS Release 8.2(3) supports the following cold boot support matrix:
Table 28 Supported Cold Boot Matrix in Cisco NX-OS Release 8.2(3)
Cisco NX-OS Release 8.2(2) supports the following cold boot support matrix:
Table 29 Supported Cold Boot Matrix in Cisco NX-OS Release 8.2(2)
Cisco NX-OS Release 8.1(2a) supports the following cold boot support matrix
Table 30 Supported Cold Boot Matrix in Cisco NX-OS Release 8.1(2a)
Cisco NX-OS Release 8.1(2) supports the following cold boot support matrix:
Table 31 Supported Cold Boot Matrix in Cisco NX-OS Release 8.1(2)
Cisco NX-OS Release 8.2(1) supports the following cold boot support matrix:
Table 32 Supported Cold Boot Matrix in Cisco NX-OS Release 8.2(1)
Cisco NX-OS Release 8.1(1) has the following cold boot support matrix:
Table 33 Supported Cold Boot Matrix in Cisco NX-OS Release 8.1(1)
Cisco NX-OS Release 8.0(1) has the following cold boot support matrix:
Table 34 Supported Cold Boot Matrix in Cisco NX-OS Release 8.0(1)
Note Non-ISSU upgrades are also referred to as cold boot upgrade.
To perform a non-ISSU upgrade (cold boot upgrade) to Cisco NX-OS Release 8.0(1) and later releases from any prior supported releases in Table 34 follow these steps:
1. Change the boot variable, as shown here:
Example for Cisco NX-OS Release 8.2(1)
boot kickstart bootflash:/n7000-s2-kickstart.8.2.1.bin sup-1
boot system bootflash:/n7000-s2-dk9.8.2.1.bin sup-1
boot kickstart bootflash:/n7000-s2-kickstart.8.2.1.bin sup-2
boot system bootflash:/n7000-s2-dk9.8.2.1.bin sup-2
Example for Cisco NX-OS Release 8.1(1)
boot kickstart bootflash:/n7000-s2-kickstart.8.1.1.bin sup-1
boot system bootflash:/n7000-s2-dk9.8.1.1.bin sup-1
boot kickstart bootflash:/n7000-s2-kickstart.8.1.1.bin sup-2
boot system bootflash:/n7000-s2-dk9.8.1.1.bin sup-2
Example for Cisco NX-OS Release 8.0(1)
2. Enter the copy running-config startup-config vdc-all command.
3. Enter the reload command to reload the switch.
Note Allow some time after the reload for the configuration to be applied.
Reload based NXOS downgrades involve rebuilding the internal binary configuration from the text-based startup configuration. This is done to ensure compatibility between the binary configuration and the downgraded software version. As a result, certain specific configuration may be missing from the configuration, after downgrade, due to ASCII replay process. This would include FEX HIF port configuration and VTP database configuration. Furthermore, NX-OS configurations that require VDC or switch reload to take effect may require additional reload when applied during the downgrade process. Examples of this include URIB/MRIB shared memory tuning, custom reserved VLAN range and Fabricpath Transit Mode feature. In order to mitigate this during downgrade, you should copy your full configuration to bootflash/tftpserver.
Any features introduced in a release must be disabled before downgrading to a release that does not support those features.
When manually downgrading from a Cisco NX-OS Release to an earlier release, first power down all modules that are unsupported in the downgrade image. Then, purge the configuration of the unsupported modules using the purge module module_number running-config command.
For complete instructions on upgrading your software, see the Cisco Nexus 7000 Series NX-OS Upgrade Downgrade Guide .
Cold boot/Reload upgrades from Cisco NX-OS 7.3.x releases to Cisco NX-OS Release 8.0(1) and Cisco NX-OS Release 8.1(1) with RISE Configuration:
– RISE configuration must be removed prior to starting your upgrade to Cisco NX-OS Release 8.0(1)/Cisco NX-OS Release 8.1(1). ISSU performs compatibility check and blocks the upgrade if RISE is configured. There is no warning displayed or prevention for the reload upgrade. Therefore make sure to remove RISE configuration before the reload upgrade.
– Steps to identify the error condition:
Even if the show feature command output shows RISE as enabled, no output will be displayed if you run the show rise and show run services sc_engine commands.
– Steps to recover:
The only way to recover from this condition is to do a reload ascii on the switch.
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.
The following steps list the workaround for this limitation:
– Configure one of the clients as the server.
– Complete the following steps:
This limitation does not apply to a binary configuration, which is the recommended approach, but only to an ASCII configuration. In addition, this limitation applies to all Cisco NX-OS software releases for the Cisco Nexus 7000 series.
Rebind Interfaces command is not automatically executed when Replaying ASCII configuration in Cisco NX-OS Release 6.2(x):
The rebind interfaces command introduced in Cisco NX-OS Release 6.2(2) is needed to ensure the proper functionality of interfaces in certain circumstances. The command might be required when you change the module type of a VDC. However, because of the disruptive nature of the rebind interfaces command, for Cisco NX-OS Release 6.2(x) prior to Cisco NX-OS Release 6.2(8), this limitation applies only when all of the following conditions are met:
The following steps list the workaround for this limitation:
Note If you boot up the switch without any startup configuration, this limitation might apply to an ASCII replay. The reason is that without a startup configuration, the default VDC might still have certain interfaces automatically allocated. Because of this possibility, follow the approaches to work around the limitation.
Instructions provided below list the steps for the cold boot (non-ISSU) downgrade. The example provided below is for a cold boot downgrade for the following:
Refer to theASCII Configuration Replay caveats section for specific configuration caveats.
– Enter copy running-config bootflash:<config.txt> vdc-all command.
Once the switch and all the modules are up with the target image, do the following:
– Enter the copy bootflash:<config.txt> running-config command.
Cisco NX-OS Release 8.2(1) includes the following Erasable Programmable Logic Device (EPLD) images:
Cisco NX-OS Release 8.1(1) includes the following Erasable Programmable Logic Device (EPLD) images:
Cisco NX-OS Release 8.0(1) includes the following Erasable Programmable Logic Device (EPLD) images:
Table 35 shows the modules that are supported in Cisco NX-OS Release 8.0(1), Cisco NX-OS Release 8.1(1), and Cisco NX-OS Release 8.2(1) and later releases:
Table 35 Supported Modules with the FPGA
For more information about upgrading to a new EPLD image, see the Cisco Nexus 7000 Series FPGA/EPLD Upgrade Release Notes, Release 8.x.
Cisco Nexus 7700 switches have an EPLD image that is programmed on the switches. This EPLD image is different than the EPLD image for the Cisco Nexus 7000 switches.
This section briefly describes the new hardware and hardware enhancements introduced in Cisco NX-OS Release 8.2(1), Cisco NX-OS Release 8.1(1) and in Cisco NX-OS Release 8.0(1). For detailed information about the new hardware, see the Cisco Nexus 7000 Series Hardware Installation and Reference Guide.
From Cisco NX-OS Release 8.2(1), the Cisco Nexus B22 Fabric Extender (N2K-B22DELL-P) and the Cisco Nexus Fabric Extender, N2k-C2348TQ-E are supported on the F3 Series and M3 Series I/O modules.
The 38mm fans do not meet NEBS compliance when the Cisco Nexus 7700 12-port 100-Gigabit Ethernet I/O Module (N77-M312CQ-26L) is used in a Nexus 7700 6-slot, 10-slot, or 18-slot chassis. The new 76mm fans are required to meet NEBS compliance when the M3 12-port 100 Gigabit I/O Module (N77-M312CQ-26L) is used in a Nexus 7700 6-slot, 10-slot, or 18-slot chassis.
Starting from Cisco NX-OS Release 8.1(1), the following M3-Series I/O modules are supported on the Cisco Nexus 7004 switch:
The following modules are supported in Cisco NX-OS Release 8.0(1):
The QSFP-100G-PSM4-S transceiver is supported with the M3-Series 12-Port 100-Gigabit Ethernet (N77-M312-CQ-26L) I/O module.
This section includes the following topics:
The Secure Erase feature is introduced to erase all customer information for Nexus 7000 series switches from Cisco NX-OS Release 8.2(8).
From this release, you can use factory reset command to erase customer information.
Secure Erase is an operation to remove all the identifiable customer information on Cisco NX-OS devices in conditions of product removal due to Return Merchandise Authorization (RMA), or upgrade or replacement, or system end-of-life.
A CoPP class to match all uRPF exception packets and police them as per the policy is introduced from Cisco NX-OS Release 8.2(6).
Bloom Filter Support for Glean Adjacencies is also supported in Cisco NX-OS Release 8.2(6). This feature is supported on M3 and F4 modules. To avoid this punting of the supervisor module, the L3 engine hashes a flow to set a bit in a leak table to indicate that the packet has been punted to the supervisor module. Subsequent frames are dropped until the software clears the leak table bit. This helps to forward the packets without any further delay.
Starting from Cisco NX-OS Release 8.2(4), static IPv6 route with VxLAN route as the next-hop is supported.
Starting from Cisco NX-OS Release 8.2(4), Honor Mode Licensing is supported on Cisco Nexus 7000 Series switches. Honor mode licensing allows you to enable or continue using a feature without having a valid license for that feature. In such a scenario, a syslog is generated once every 7 days until you acquire the required license.
The number of interfaces validated with LACP Fast Timers in Cisco NX-OS Release 8.2(4) are:
Cisco NX-OS Release 8.2(3) has the following MACSEC enhancements:
The following methods/commands are introduced to protect the supervisor from excessive mac move:
This enhancement enables you to configure a different interface as the source interface by using the ip dhcp relay source-interface interface-name command.
Cisco NX-OS Release 8.1(2) has the following scale enhancement:
250,000 OSPF LSA is supported only with specific below listed parameters:
From Cisco NX-OS Release 8.2(1), you can configure the Intelligent CAM (iCAM) analytics and machine-learning monitor interval and obtain the following traffic analytics on TCAM entries and resources:
iCAM provides the above listed analytics for the following features:
GUI for iCAM is available in DCNM as an experimental feature (click on Monitor --> iCAM).
MACsec is a standard, which can be set up using Cisco security association (SA) protocol or MACsec Key Agreement (MKA). The SA protocol was used to set up the MACsec standard prior to Cisco NX-OS Release 8.2(1). MACsec can also use the MKA protocol in Cisco NX-OS Release 8.2(1) to exchange session keys and manage encryption keys. MKA is supported only on physical ports and port channels.
MKA supports the following point-to-point use cases:
Using MKA, you can also secure a CE to multiple CEs using an MPLS or VPLS network, which is a point-to-multi point deployment.
From Cisco NX-OS Release 8.2(1), the Flexible ACL TCAM Bank Chaining feature is supported on the M2 Series modules.
From Cisco NX-OS Release 8.2(1), you can use the ip dhcp redirect-response command on the DHCP server-facing interface to redirect the packets to the correct switch. When you enable this command, the relay agent on a border node includes source locater and VNI ID of the client segment as remote ID option in request packets, and relays it to the DHCP server. When the DHCP server sends the OFFER packets, the border node uses the information from the same remote ID option to create a VXLAN header. This header includes the source locater set as the outer destination address and the VNI ID of the client segment. This helps the border node to send the OFFER packet to the correct switch.
The congestion drop timeout and pause frame timeout commands are modified for FCoE to align with the commands used in Fibre Channel.
The following commands are modified:
This feature enables you to configure VXLAN and OTV on the same device (a single-box solution). The VXLAN and OTV overlays are stitched together in the device, ensuring that the Layer-2 traffic between the tunnels is within the bridge domain.
VXLAN fabric supports external connectivity. Data centers in different sites can be connected using the Data Center Interconnect (DCI) functionality. In the MPLS hand off scenario, the VXLAN encapped packet is terminated and reoriginated to MPLS.
ACI WAN Interconnect feature is supported on M3 modules in Cisco NX-OS Release 8.2(1).
Policy-based routing (PBR) support is provided for the VXLAN BGP EVPN fabric. PBR allows you to configure a defined policy for IPv4 and IPv6 traffic flows, lessening the reliance on routes derived from the routing protocols. All the packets received on an interface with policy-based routing enabled are passed through enhanced packet filters or route maps. The route maps dictate the policy, determining the destination to forward packets. PBR configurations have to be enabled on relevant ToR or leaf switches, and spine switches in the VXLAN BGP EVPN fabric.
Network plug and play (PnP) is a software application that runs on a Cisco Nexus 7000 switch. The PnP feature provides a simple, secure, unified, and integrated offering to ease new branch or campus roll-outs, and for provisioning updates to an existing network. This feature provides a unified approach to provision networks that comprise different devices with a near zero-touch deployment experience.
Consistency checker compares the software state with the hardware state in a module and if there is any inconsistency, it flags the issue immediately. This helps to reduce troubleshooting time at a later period. The consistency checker enables users to perform basic troubleshooting and identify issues before reaching out to support teams for resolution thereby reducing the mean time to resolve issues.
Except for Persistent Storage Service (PSS) consistency checker all other features are supported since Cisco NX-OS Release 8.0(1) and are enhanced in Cisco NX-OS Release 8.2(1). Consistency checker is supported on M3 and F3 modules. Users can execute the show consistency-checker all command to perform consistency check for all components/features.
The following consistency checker components are supported in Cisco NX-OS Release 8.2(1):
Distributed Packet Tracer (DPT) enables users to find and track specific traffic flow across all network devices from a single-point server or network controller or network management system (NMS).
The DPT framework uses a central controller device (CCD) to communicate with an on-switch software module called On-Switch-DPT. The CCD gets the input from the network administrator to trace a given packet in a network. CCD then communicates this information to each of the switches in the network. The On-Switch-DPT traces the packet and passes the information to CCD.
The CCD then collates all the information from various switches and analyzes them before presenting the result to users.
The Configure Replace (CR) feature enables a Nexus 7000 Series switch to replace the running configuration with a user provided configuration without reloading. Device reload may be required only when a configuration itself requires a reload. A user provided configuration is running configuration taken from a Cisco NXOS switch. CR replaces the entire running configuration with new configuration provided by a user. In case of failure in CR the original configuration is restored in the switch.
From Cisco NX-OS Release 8.2(1), all Cisco Nexus 7000 Series I/O modules support hardware forwarding of IP-directed broadcast packets. This feature is limited to the virtual device contexts (VDC) on which this feature is applied. You cannot configure both software and hardware forwarding of IP-directed broadcast packets on the same interface.
From Cisco NX-OS Release 8.2(1), Layer 3 routing over vPC is supported in the M3 Series I/O modules for IPv6 unicast traffic.
The IP TCP Maximum Segment Size (MSS) feature enables the configuration of a maximum segment size for all TCP connections that originate from or are terminated in a Cisco Nexus 7000 Series switch.
From Cisco NX-OS Release 8.2(1), Precision Time Protocol (PTP) can be enabled in the M3 Series I/O modules.
Catena works in transparent, routed, and mixed modes, which means each Catena instance can forward traffic through a mix of Layer 2 and Layer 3 devices. Failover using probing is supported for traffic redirection. Catena solution supports hash-based load balancing across appliances in the transparent mode.
Data flow through these appliances is based on traffic type which is qualified by access control lists. Each Catena service contains many chains of appliances, and each chain of appliance contains many sequences of access-lists based on vlan-group, port-group, and device-group identifiers.
From Cisco NX-OS Release 8.2(1), subscription-based licensing is available on Cisco Nexus 7000 Series switches. This enables the user to purchase licenses for any period of time.
From Cisco NX-OS Release 8.2(1), the Intelligent CAM Analytics and Machine-learning (iCAM) feature is available under the ENHANCED_LAYER2_PKG license.
From Cisco NX-OS Release 8.2(1), all Virtual Private LAN Service (VPLS) functionalities, except Ethernet Flow Points, (EFP), service instances and bridge domains, are supported in the M3 Series I/O modules.
From Cisco NX-OS Release 8.2(1), all Ethernet over Multiprotocol Label Switching (EoMPLS) functionalities, except EFPs, service instances and bridge domains, are supported in the M3 Series I/O modules.
From Cisco NX-OS Release 8.2(1), Cisco Nexus 7000 Series switches support Private VLAN (PVLAN) that is extended over the Overlay Transport Virtualization (OTV) overlay. This allows a device to extend Layer 2 VLANs across Layer 3 IP networks. Transmission occurs in a Layer2 frame attached to a Layer 3 header. In an OTV overlay, this feature allows two VLANs to communicate, based on the PVLAN association.
From Cisco NX-OS Release 8.2(1), Cisco Nexus 7000 Series switches aim to achieve sub-sec convergence delay for 16K (S, G) running on F3 and M3 Modules, using the Multicast only Fast Re-Route (MoFRR) feature. This feature allows faster programming and improved convergence.
From Cisco NX-OS Release 8.2(1) Web Cache Communication Protocol (WCCP) version 2 feature is supported on bridge domain interfaces (BDIs) as an ingress feature.
HTTP probes are supported to probe each node periodically to monitor their health.
With multicast extranet, the RPF lookup for multicast route in the receiver VRF can be carried out in a source VRF, thereby allowing the return of a valid RPF interface. This forms a source or RP tree from the receiver VRF to the source VRF, thus enabling the traffic originating from the source VRF to be forwarded to the OIFs in the receiver VRF.
From Cisco NX-OS Release 8.2(1), you can configure peer-keepalive link using an IPv4 or IPv6 address.
From Cisco NX-OS Release 8.2(1), Intelligent Traffic Director (ITD) is supported on M3 modules.
From Cisco NX-OS Release 8.2(1), Locator/ID Separation Protocol (LISP) is supported on M3 modules.
From Cisco NX-OS Release 8.2(1), the ITD VIP knob for static route feature allows you to configure a Virtual IP Address (VIP) for ITD device group, with route creation based on the health of a device group node. With a VIP knob, creation and deletion of routes is automatic and is triggered based on the health of the ITD device group.
The Disjoint Routing Locator (RLOC) feature facilitates inter-fabric LISP traffic support by ensuring that the LISP mapping system is aware of multiple fabrics. Each fabric is defined by a locator scope that groups a range of RLOC (or fabric underlay) addresses that routers within the fabric are associated with.
From Cisco NX-OS release 8.1(1), routing over vPC for IPv4 unicast traffic is supported on the M3 Series modules.
From Cisco NX-OS release 8.1(1), you can exempt the Layer 2 (L2) control plane protocols from SGT tagging when interlinking with ports.
This is to ensure that the packets from L2 control protocols are transmitted untagged from Ethernet peers to ports.
The Bidirectional Forwarding Detection (BFD) Multi-hop feature enables detection of IPv4 network failure between paths that are not directly connected. This feature also enables users to configure IPv4 BFD sessions over multi-hop routes.
If a BFD session is up (that is, the next-hop destination is reachable), IPv4 static routes that are associated with IPv4 static BFD configuration are added to a routing table. If the BFD session is down, the routing table removes all associated static routes from the routing table.
BFD notifies BGP when the path goes down. The path to reach the destination (BGP neighbor) is through a static route only (with no IGP support).
The multi-hop BFD feature supports only the static routes in Cisco NX-OS release 8.1(1),
VXLAN BGP EVPN fabrics with a Cisco Nexus 7000 Series border leaf switch having an M3 module can use the MPLS L3VPN network for WAN connectivity or for Layer-3 Data Center Interconnect.
The VXLAN OAM – Ping functionality is used to detect errors and path failures for traffic from a leaf/ToR switch VTEP to an attached end host, to another leaf/ToR switch VTEP, or to an end host attached to a VTEP.
VXLAN OAM – Traceroute/Pathtrace functionality is used for fault isolation in the VXLAN overlay. Traceroute is an ICMP based solution that provides more information regarding the ingress and egress interface paths. The traceroute command uses ICMP packets (channel-1) to trace the path the packet traverses in the VXLAN BGP EVPN fabric overlay, and the pathtrace command traces the path the packet traverses in the VXLAN overlay using the NVO3 channel (channel-2).
This feature provides a provision to view interface and error verification statistics, when the pathtrace function is used.
Pervasive Load Balancing (PLB) is a fabric feature that provides Layer-3 and Layer-4 load balancing at terabits speed without the need for any virtual or physical external load balancer equipment. Servers, VMs and containers (specific to a given service) attached to different ToR/leaf switches might be distributed across the fabric and this feature enables the switching fabric to load balance client-specific service requests to these servers.
In this feature, the same virtual IP (VIP) is assigned to the group of servers that might be distributed across the fabric. When different clients (local to the fabric or from a remote location) send requests for a given service, these requests are destined to the VIP of these servers.
In the fabric, ToR/leaf switches matches these clients’ IP address bits/mask, the VIP and relevant Layer3/Layer4 fields to load balance these requests among the servers.
Beginning with Cisco NX-OS Release 8.0.1, on the Cisco Nexus 7000/7700 Series Switches the Intelligent CAM Analytics and Machine-learning (iCAM) feature is supported. The iCAM feature enables you to view the traffic analytics per feature, Ternary Content-Addressable Memory (TCAM) resources and entries. Prior to the introduction of iCAM feature, it was difficult to get an overall view of how many TCAM/SRAM resource entries were used/free with various features and how much traffic was flowing through the various subnets/applications.
iCAM can be used to view historical TCAM data. iCAM analyses this historical data using machine learning algorithms to predict TCAM usage and traffic stats at a future date and time.
This feature helps in chaining of devices so that packets are redirected through multiple devices. These devices can be appliances like firewall, IPS, IDS and Load balancer, and so on. The devices are inserted in the data path in such a way that there are no topological changes, or changes to existing configuration. This feature can support scalability with many number of appliances in the data path.
Data flow through these appliances is based on traffic type which is qualified by access control lists. Each Catena service contains many chains of appliances, and each chain of appliance contains many sequences of access-lists based on vlan-group and port-group identifiers.
The VPN Multipath Support for Inter-AS VPNs feature enables the switch to pick one path as the best path and mark the other legitimate paths between Autonomous System Boundary Routers (ASBRs) as multi path. This feature enables load sharing of traffic among the different multi paths and the best path to reach the destination.
A delay has been added before the after_maintenance snapshot is taken. A visible CLI indicator has been added to display when the system is in the maintenance mode. Support for SNMP traps has been added when the device moves from the maintenance mode to the normal mode and vice-versa through CLI reload, or system reset.
You can configure SSH authentication using X.509v3 certificates (RFC 6187). X.509v3 certificate-based SSH authentication uses certificates combined with a smart card to enable two-factor authentication for Cisco device access.
M3 Series modules support Flexible ACL TCAM bank chaining feature.
This feature provides support to enable or disable SGACL policy enforcement on L3 interfaces and L3 port-channels.
System security monitoring functionality monitors and provides visibilities to the following system related security technologies:
The Integrity Measurement Architecture (IMA)/Runtime Integrity feature provides assurance about authenticity of Cisco NX-OS system and its components. This feature ensures that the system has not been exposed to tampered code by measuring the Cisco NX-OS system and its components. You can verify authenticity by comparing the measured value against a known standard value.
The IPv6 RA Guard feature provides support for allowing the network administrator to block or reject unwanted or rogue router advertisement (RA) guard messages that arrive at the network device platform.
The DHCPv6 Guard feature blocks reply and advertisement messages that come from unauthorized DHCP servers and relay agents.
The IPv6 Snooping feature bundles several Layer 2 IPv6 first-hop security features, including IPv6 neighbor discovery inspection, IPv6 device tracking, IPv6 address glean, and IPv6 binding table recovery, to provide security and scalability. IPv6 ND inspection operates at Layer 2, or between Layer 2 and Layer 3, to provide IPv6 functions with security and scalability.
Cisco TrustSec SXP version 4 (SXPv4) enhances the functionality of SXP by adding a loop detection and prevention mechanism to prevent stale binding in the network. In addition, Cisco TrustSec with SXPv4 supports SGT inline tagging, which allows propagation of SGT embedded in clear-text (unencrypted) Ethernet packets.
The SGACLs downloaded by using Integrated Services Engine (ISE) and configured by using CLI can co-exist. You can prioritize whether to use SGACLs downloaded from ISE or configured SGACLs by using CLI. By default, the SGACLs configured by using CLI have higher priority in Cisco NX-OS.
Cisco Smart Licensing is a flexible licensing model that provides you with an easier, faster, and more consistent way to purchase and manage software across the Cisco portfolio and across your organization. And it’s secure – you control what users can access. With Smart Licensing you get:
To use Smart Licensing, you must first set up a Smart Account on Cisco Software Central ( software.cisco.com).
For a more detailed overview on Cisco Licensing, go to cisco.com/go/licensingguide.
The vPC hitless role change feature provides a framework to switch vPC roles between vPC peers without impacting traffic flows. The vPC role swapping is done based on the role priority value of the device under the vPC domain. A vPC peer device with lower role priority is selected as the primary vPC device when the vpc role preempt command is executed.
The BGP PIC Edge feature creates and stores a backup path in the routing information base (RIB) and forwarding information base (FIB) so that when a failure on an eBGP link to SP is detected (the primary path fails), the backup path can immediately take over, enabling fast fail over in the forwarding plane. BGP PIC Edge feature supports both IPv4 and IPv6 address families.
Modified the soft-reconfiguration inbound command, which was used to configure a soft reconfiguration for inbound policy changes. The modified command is soft-reconfiguration inbound always. The always option was added in this release and must be used for complete soft-reconfiguration inbound functionality.
Binary tech support is a log-collecting framework that collects logs internally from all Cisco NX-OS processes that are running on the device. Enter the show tech-support all binary <uri> command to collect logs from across the entire device, including virtual device contexts (VDCs), and modules. Binary tech support can either be parsed within the device or moved to an external log server where it can be parsed off line. If a module fails during the log collection, binary tech support continues to collect logs from all remaining modules and VDCs.
The message and transaction service (MTS) is a high-performance interprocess communications (IPC) message broker that specializes in high-availability semantics. MTS handles message routing and queuing between services on and across modules and between supervisors. MTS facilitates the exchange of messages such as event notification, synchronization, and message persistency between system services and system components. MTS can maintain persistent messages and logged messages in queues for access even after a service restart.
MTS provides extensive serviceability features. For instance, MTS provides notifications to inform an application when its queue has reached a predefined limitation. Corresponding to each notification, a default callback action is defined in MTS. From Cisco NX-OS Release 8.0(1), the System Message Logging contains new logs that indicates the highest MTS memory users. These logs are set to severity level 4. In addition, detailed memory usage stats with timestamps are collected per application. You can use the command show sys int mts sup sap APP_SAP_NUM queue_stats to collect the technical support, if an application contains an issue.
Link OAM is supported only on F2+M3 modules. This feature allows service providers to monitor and troubleshoot a single physical point-to-point Ethernet link. Service providers can monitor specific events, take actions on events, and troubleshoot. Ethernet link OAM operates on a single, physical link and it can be configured to monitor either side or both sides of that link.
Consistency checker is a tool that checks for system consistency, helps in root cause analysis and fault isolation, checks for software versus hardware programming, and includes on demand trigger through CLI.
The Fault-Management System is used to enhance the Cisco NX-OS serviceability by providing an efficient means to capture data relevant and adequate to debug issues being reported at the earliest possible time, without any manual intervention.
This feature enables fair distribution of traffic across all members of a port channel. This feature is applicable to Cisco Nexus 7000 48-Port 1 and 10 Gigabit Ethernet F2-Series Modules and Cisco Nexus 7000 Enhanced F2-Series 48-Port Fiber 1 and 10 Gigabit Ethernet Modules only.
Cisco NX-API allows HTTP-based programmatic access to the Cisco Nexus platform. NX-API extends the capability of running CLIs for configuration management using HTTP/HTTPS. NX-API embeds the commands into the body of XML, JSON or JSONRPC requests and executes them by spawning VSH sessions.
The following enhancements have been made to NX-API:
– Validate-Only—Validates the configuration only; will not set the configuration.
– Validate-and-Set—Validates the configuration, if successful it applies the configuration on the switch.
– Stop-on-error—Stops on the first CLI that fails.
– Continue-on-error—Ignores and continues with other CLIs.
– Rollback-on-error—Rolls back to the previous state the system had before executing the commands
The OTV Loopback Join Interface feature allows the overlay to use a loopback interface as the Join Interface. This feature adds multicast based OTV control plane into the multicast core by using a loopback as join interface. This also allows to have multiple physical uplinks into the provider multicast core. This feature has the following enhancements:
The OTV Loopback Join Interface feature has the following limitations:
Note: You must create a custom control plane policing (CoPP) policy to change the Committed Information Rate (CIR) to allow more control plane packets.
Change the u6route-mem command value for VDC from 64 to the default value of 24.
Refer to Cisco Nexus 7000 Series NX-OS Verified Scalability Guide for other Cisco NX-OS Release 8.0(1) scale enhancements.
Smart Licensing feature is introduced in Cisco NX-OS Release 8.0(1).
Refer to the “Smart Licensing Chapter” in the Cisco NX-OS Licensing Guide. for more details on the Smart Licensing feature.
For details on licensing information for earlier releases, see the “Licensing Cisco NX-OS Software Features” chapter in the Cisco NX-OS Licensing Guide.
For a more detailed overview on Cisco Licensing, go to cisco.com/go/licensingguide.
The following topics provide a list of open and resolved caveats:
Note Release note information is sometimes updated after the product Release Notes document is published. Use the Cisco Bug Toolkit to see the most up-to-date release note information for any caveat listed in this document.
NX-OS: mts recv_q SNMP Response SAP - stp+dot1dBridge+qBridge |
|
Cisco Nexus 7000 Message of the Day (MOTD) Telnet Login Vulnerability |
|
Cisco Nexus 7000 VDC Authenticated Privilege Escalation Vulnerability |
|
Route-leak (inter-vrf) - hmm route not flushed on host vMotion |
|
Cisco NX-OS Software CLI Arbitrary Command Execution Vulnerability |
|
ARP memory leak @ LIBBL_MEM_bitfield_malloc_t & LIBSLAB_MEM_create_slab |
|
MTS buffers' leak while constantly polling objects in BRIDGE-MIB |
|
Cisco NX-OS Software Bash Shell RBAC Privileged Escalation Vulnerability |
|
Cisco FXOS and NX-OS Software CLI Command Injection Vulnerability (CVE-2019-1611) |
|
N7k - SPAN Destination traffic leaves untagged in setup with bridge-domain |
|
cannot rewrite vlan at dual-active exclude interface-vlan-bridge-domain |
|
N9000 prefers mBGP route over directly connected one causing mcast traffic black holing |
|
ISIS does not advertise local or learned routes to neighbors after upgrade and coming out of mmode |
|
can not change AD for ISIS ipv6 routes using distance command under ipv6 address family |
|
Regarding ISIS redistribute maximum-prefix less than static route number |
|
Service "AAA Daemon" failed to store its configuration (error-id 0x80480018) |
|
Vlan not added to flood list, when new vlans are created in FL ingress-replication VXLAN |
|
With passive TWINAX cable N2K-C2348TQ-10G-E reports the Fan Failure |
|
Nexus9000 Mcast pim spt-threshold infinity not honored when LHR transits from non-DR to DR |
|
NVE failed to learn remote VTEP RMAC after ISSU aborted or canceled |
|
N3000 generates IGMP report with source 0.0.0.0 preventing the mcast group from timeout |
|
VXLAN IPv6 packets loop due to NVE invalid source-intf state while peerlink is down or unconfigured. |
|
VXLAN:NGMVPN service crashes due to could not allocate slab for fabric mroute |
|
N7K-PPM: Issues seen under interface when port-profile is inherited. |
|
Egress packet loss from CPU when dest is recursive through EVPN |
|
Output of "show mpls ldp igp sync" inconsistent with configuration |
|
N9k BGP - When changing export map on VRF, RT does not always update in EVPN AF |
|
Linecard CPU utilization is displayed incorrectly for some processes |
|
VPC: Type2 EVPN route advertised with primary IP of Loopback as next-hop |
|
Stale arp entry/route after VM move from one VPC domain to other due to HMM update failure |
|
NX-SNMP: Random Auth failure when performing snmp-walk (via TCP) using SNMPv3 users. |
|
IGMP v2/v3 mix: shutdown igmpv2 receivers and igmpv3 receivers are also removed from mrib oifl |
|
Target Address on IP SLA (udp) probes is getting changed to a new IP other than the configured one |
|
N9k do not age out Snooping entry against vPC Peer link port after receipt of GSQ |
|
N7K replaces the default mpls-vpn route with the type-7 default route |
|
"no ip redirects" configurable on L3 port-channel member port |
|
BFD session goes down upon changing IP address of unrelated interface |
|
Irvine : vsh core seen in steady state with traffic running [without any triggers] |
|
n7k/F2: EEM to ignore interrupt during EG recovery (CSCux90737/CSCug39011/CSCux08154/CSCud43503) |
|
Mcast trafffic loss seen sometimes with module reload and other triggers |
|
Error of 'system bridge-domain add' CLI due to existing vlan deletes all existing bridge-domains |
|
The port-channel cannot be controlled by this input policy after removed the port-channel members. |
|
leak-route doesn't happen leading to leak-route installation failure |
|
BGP process crash with aggregate-address config without summary-only option under VRF |
|
mrib crash when collecting mcast show tech with N7K in SDA border role. |
|
Memory leak is seen in DHCP process when show run is executed on a VLAN |
|
80% packets loss in route leaking environment after changing SVI IP address |
|
Reverted breakout interface on N77-M324FQ-25L fails to come up. |
|
LR transceiver stops transmitting laser when port unshut after a long shut |
|
ISIS Default route advertised to N7K won't be installed to RIB. |
|
Race in Flanker/MTM/L2FM can lead to learning gateway mac out local interface while SVI Up |
|
After upgrade from 7.3(2)D1(3a) to 8.2.2 on N7K, show tech/show tech det is not getting complete. |
|
N7K: cryptographic-algorithm HMAC-SHA-xxx keys show up as unknown |
|
DATACORRUPTION Tracebacks when adding N7K to SNMP Management |
|
N7k PIXM/PIXMc should attempt to recover if they get out of sync |
Table 59 Cisco NX-OS Release 8.0(1) Closed Caveats
To perform a software upgrade or downgrade, follow the instructions in the Cisco Nexus 7000 Series NX-OS Software Upgrade and Downgrade Guide, Release 8(x). For information about an In Service Software Upgrade (ISSU), see https://www.cisco.com/c/dam/en/us/td/docs/dcn/tools/nexus-7k-issu-matrix/index.html
http://www.cisco.com/c/en/us/support/switches/nexus-7000-series-switches/tsd-products-support-series-home.html
The Release Notes for upgrading the FPGA/EPLD is available at the following URL:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/7_x/epld/epld_rn_72.html
Cisco Nexus 7000 series configuration guides are available at the following URL:
http://www.cisco.com/c/en/us/support/switches/nexus-7000-series-switches/products-installation-and-configuration-guides-list.html
Cisco Nexus 7000 series command references are available at the following URL:
http://www.cisco.com/c/en/us/support/switches/nexus-7000-series-switches/products-command-reference-list.html
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What’s New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.