Cisco Nexus 7000 Series NX-OS 8.3, Release Notes
Guidelines and Limitations—Cisco NX-OS Release 8.3(2)
Guidelines and Limitations—Cisco NX-OS Release 8.3(1)
Guidelines and Limitations Common for Cisco NX-OS Release 8.x
Upgrade and Downgrade Paths and Caveats
Supported Upgrade and Downgrade Paths
ISSU Paths for Cisco NX-OS Release 8.3(2)
ISSU Paths for Cisco NX-OS Release 8.3(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 Hardware - Cisco NX-OS Release 8.3(2)
New Hardware - Cisco NX-OS Release 8.3(1)
New and Enhanced Software Features - Cisco NX-OS Release 8.3(1)
Open Caveats—Cisco NX-OS Release 8.3(2)
Open Caveats—Cisco NX-OS Release 8.3(1)
Resolved Caveats—Cisco NX-OS Release 8.3(2)
Resolved Caveats—Cisco NX-OS Release 8.3(1)
Obtaining Documentation and Submitting a Service Request
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 .
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.
Added Cisco NX-OS Release 8.2(8) to the “Upgrade and Downgrade Paths and Caveats” section. |
|
Added Cisco NX-OS Release 7.3(8)D1(1) to the “Upgrade and Downgrade Paths and Caveats” section. |
|
Added Cisco NX-OS Release 8.2(7a) to the “Upgrade and Downgrade Paths and Caveats” section. |
|
Added Cisco NX-OS Release 7.3(7)D1(1) to the “Upgrade and Downgrade Paths and Caveats” section. |
|
Added N77-F312CK-26 to the “Cisco Nexus 7000 Series Switches and Cisco Nexus 7700 Switches Hardware Support” table. |
|
Added Cisco NX-OS Release 8.2(6) to the “Upgrade and Downgrade Paths and Caveats” section. |
|
Added Cisco NX-OS Release 7.3(6)D1(1) to the “Upgrade and Downgrade Paths and Caveats” section. |
|
Updated the “Upgrade and Downgrade Paths and Caveats” section to include Cisco NX-OS Release 8.2(5) and Cisco NX-OS Release 7.3(5)D1(3). |
|
Updated the “Supported Device Hardware” section to include F4 Series Module details. |
|
Updated the “Upgrade and Downgrade Paths and Caveats” section to include Cisco NX-OS Release 7.3(3)D1(3). |
|
Updated the “Upgrade and Downgrade Paths and Caveats” section to include Cisco NX-OS Release 7.3(2)D1(3a). |
|
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:
This section describes the guidelines and limitations for the Cisco Nexus 7000 Series in Cisco NX-OS Release 8.3(2).
This section describes the guidelines and limitations for the Cisco Nexus 7000 Series in Cisco NX-OS Release 8.3(1).
– vPC Peer Keep Alive IPv6 Support
– OTV Scale Enhancements - F4 parity with F3 (Refer to Cisco Nexus 7000 Series NX-OS Verified Scalability Guide)
Note For EPLDs available for Cisco NX-OS Release 8.3(1), see EPLDs Available for Release 8.x section in the Cisco Nexus 7000 Series FPGA/EPLD Upgrade Release Notes, Release 8.x.
- There are no updates in Nexus 7000 Sup2 EPLD images. Hence n7000-s2-epld.8.3.1.img is not posted to https://www.cisco.com.
- If you decide to upgrade EPLD anyway, or it is determined necessary in your environment, then the following guidelines should be followed.
- For Cisco NX-OS Release 6.2(10) and later releases it is recommended to perform EPLD upgrade with the current image before upgrading to Cisco NX-OS Release 8.3(1).
- For releases prior to Cisco NX-OS Release 6.2(10), you need to first upgrade to Cisco NX-OS Release 6.2(10) or later releases and perform EPLD upgrade with the current image before upgrading to Cisco NX-OS Release 8.3(1).
- The above guidelines and limitations do not apply to the Nexus 7700 series switches, and their EPLD can be upgraded through the standard process if needed.
Please see CSCvk35999 under the Open Caveats—Cisco NX-OS Release 8.3(1) for more details.
This section describes the guidelines and limitations for the Cisco Nexus 7000 Series in Cisco NX-OS Release 8.2(1) and later releases.
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) and later releases:
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:
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:
For more details on PONG, refer to the Cisco Nexus 7000 Series NX-OS Troubleshooting Guide.
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).
Cisco Nexus 7000 Series Network Analysis Module (NAM-NX1) is not supported.
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 Fabric 2 module in 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.3(2).
Note Only the ISSU paths/combinations in Table 5 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 6 for the In-Service Software Upgrade (ISSU) paths for Cisco NX-OS Release 8.3(1).
Note Only the ISSU paths/combinations in Table 6 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.
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) and later releases. 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) and later releases 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.
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 6 and Table 7 follow these steps:
1. Change the boot variable, as shown here:
Example for Cisco NX-OS Release 8.3(1)
boot kickstart bootflash:/n7000-s2-kickstart.8.3.1.bin sup-2
boot system bootflash:/n7000-s2-dk9.8.3.1.bin sup-2
boot kickstart bootflash:/n7000-s2-kickstart.8.3.1.bin sup-2e
boot system bootflash:/n7000-s2-dk9.8.3.1.bin sup-2e
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 later releases 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) and later releases. 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.3(2) includes the following Erasable Programmable Logic Device (EPLD) images:
Cisco NX-OS Release 8.3(1) includes the following Erasable Programmable Logic Device (EPLD) images:
Table 9 shows the modules that are supported in Cisco NX-OS Release 8.3(1):
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.
Starting from Cisco NX-OS Release 8.3(2), the Cisco Nexus 7700 F4-Series 30-port 100-Gigabit Ethernet I/O module (N77-F430CQ-36) supports 40-Gigabit Ethernet link also. For detailed information about the hardware, see the Cisco Nexus 7000 Series Hardware Installation and Reference Guide.
This section briefly describes the new hardware and hardware enhancements introduced in Cisco NX-OS Release 8.3(1). For detailed information about the new hardware, see the Cisco Nexus 7000 Series Hardware Installation and Reference Guide.
The Proportional Multipath for VNF feature enables advertising of all the available next hops to a given destination network. This feature enables the switch to consider all paths to a given route as equal cost multipath (ECMP) allowing the traffic to be forwarded using all the available links stretched across multiple ToRs.
The MPLS over GRE feature provides a mechanism for tunneling Multiprotocol Label Switching (MPLS) packets over a non-MPLS network. Starting from Cisco NX-OS Release 8.3(1), MPLS over GRE is supported on M3-Series I/O modules.
Starting from Cisco NX-OS Release 8.3(1), the ITD fail action feature is enhanced to optimally pre-fetch the status of the service nodes before reassigning the failed node’s buckets to the next available active nodes. When a node is down, instead of assigning it to the next available active node, the pre-fetch optimization internally fetches the status of all the available nodes and then reassigns the failed node to an active node. Similarly, in a least bucket node fail reassignment, the pre-fetch optimization fetches the status of all the nodes before reassigning the failed node buckets to the least bucketed node.
Prior to Cisco NX-OS Release 8.3(1), when the node is down, the bucket associated with the node is reassigned to the first active node found in the configured set of nodes. If the newly reassigned node also fails, the traffic bucket is reassigned to the next available active node. The reassignment is done in a round robin fashion across nodes. The delay in reassigning the failed node bucket to an active node impacts the network performance.
Currently, the pre-fetch optimization is enabled for failaction node least-bucket and failaction node per-bucket features.
Starting from Cisco NX-OS Release 8.3(1), Cisco enables networks with WAN MACsec to change the EAPoL destination address, and Ethernet type values to non-standard values. The EAPoL destination Ethernet type can be changed to an alternate value from the default Ethernet type of 0x88E5, or the EAPoL destination MAC address can be changed to an alternate value from the default DMAC of 01:80:C2:00:00:03, to avoid being consumed by a provider bridge.
Starting with Cisco NX-OS 8.3(1), the Locator ID Separation Protocol (LISP) supports the redistribution of RIB routes into the LISP feature. This feature allows LISP to import Layer 3 RIB routes in use for internal applications. Importing information from the RIBs allows for proactive learning of LISP prefixes in the control plane. This eliminates the need to statically specify prefixes to be used for map-caches or databases in LISP.
With the LISP Extranets feature, users can specify policies that allow host and resources residing in one VRF (IID) domain to communicate with hosts in a separate VRF (IID) domain.
With LISP Extranets, policies are specified in the Mapping System and the xTRs (Ingress Tunnel Router + Egress Tunnel Router) discover the leaked routes on demand, as part of the regular route discovery process.
The implementation of LISP Extranets on LISP includes the following features:
The TWAMP responder feature enables you to configure the TWAMP server and the session-reflector on a Cisco device for measuring the round-trip performance between an IP SLAs TWAMP responder and a non-Cisco TWAMP control device in your network.
Telemetry enables a push model for continuously streaming data from the show commands that are XMLized.
N77-M312CQ-26L supports 100G and 40G. 4x10G breakout port is supported in 40G mode, similar to breakout feature in N77-F324FQ-25 / N77-M324FQ-25L.
Starting from Cisco NX-OS Release 8.3(1), the Distributed Packet Tracer (DPT) feature is supported on the F4 series modules.
Cisco NX-OS Release 8.3(1) has the following scale enhancements:
The default COPP limit for ARP is unchanged. To achieve 3000 ARP PPS with a single module, ARP COPP needs to be changed accordingly. As the COPP is applied at the module, this 3000 PPS can be achieved with multiple modules with the default COPP limits. 3000 ARP PPS is system-level supported PPS.
M3 ACL Label scale for M3 module
Total number of FIB entries supported in a M3 module is 1.7 million IPv4 routes or 500k IPv6 routes or 1.1 million IPv4 Routes along with 300K IPv6 Routes.
Refer to Cisco Nexus 7000 Series NX-OS Verified Scalability Guide for other Cisco NX-OS Release scale enhancements.
For details on licensing information, see the “Licensing Cisco NX-OS Software Features” chapter in the Cisco NX-OS Licensing Guide.
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.
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
Cisco Nexus 7000 documentation is available at the following URL:
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 NX-OS documents include the following:
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.