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

---

Table 1 Online History Change

Date	Description
June 18, 2015	Created release notes for Cisco NX-OS Release 7.2(0)D1(1).
September 7, 2015	Updated the “Resolved Caveats—Cisco NX-OS Release 7.2(0)D1(1)” section to add CSCuq28545.
September 22, 2015	Reorganized the “New and Enhanced Software Features” section based on feature groupings.
October 29, 2015	Updated the release notes for Cisco NX-OS Release 7.2(1)D1(1). Updated the “Cisco NX-OS Release 7.2(1)D1(1) – Software Features” and “Caveats” section.
November 12, 2015	Updated the “Transceivers Supported by Cisco NX-OS Software Releases” table to add a footnote for CPAK-100G-LR4 and CPAK-100G-SR10.
July 15, 2016	Updated the release notes for Cisco NX-OS Release 7.2(2)D1(1). Updated the “Upgrade/Downgrade Paths and Caveats” and “Caveats” section.
August 5, 2016	Updated the release notes for Cisco NX-OS Release 7.2(2)D1(2). Updated the “Caveats” section.
August 17, 2016	Updated the “Transceivers Supported by Cisco NX-OS Software Releases” table to include information for CVR-QSFP-SFP10G.
November 8, 2016	Updated the “Resolved Caveats—Cisco NX-OS Release 7.2(0)D1(1)” section to add CSCun41202.
December 8, 2016	Updated Table 2 —Cisco Nexus 7000 and 7700 Series Hardware Supported by Cisco NX-OS Software to add N7K-C7018-FAB-1 and N7K-F132XP-15.
February 21, 2017	Updated the “Upgrade/Downgrade Paths and Caveats”section to include Cisco NX-OS Release 6.2(18).
December 8, 2017	Updated the “Upgrade/Downgrade Paths and Caveats”section to include Cisco NX-OS Release 6.2(20).
August 3, 2018	Updated the “Upgrade/Downgrade Paths and Caveats”section to include Cisco NX-OS Release 6.2(20a).
February 15, 2019	Updated the “Upgrade/Downgrade Paths and Caveats”section to include Cisco NX-OS Release 6.2(22).
February 14, 2020	Updated the “Upgrade/Downgrade Paths and Caveats”section to include Cisco NX-OS Release 6.2(24).
May 11, 2020	Updated the “Upgrade/Downgrade Paths and Caveats”section to include Cisco NX-OS Release 6.2(24a).

Supported Device Hardware

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

Table 2 shows the Cisco Nexus 7000 and 7700 Series hardware supported by Cisco NX-OS Release 7.2.x and earlier releases.

Table 3 shows the FEX modules supported by the Cisco Nexus 7000 and 7700 Series I/O modules.

Table 4 shows the Service Modules Supported by Cisco Nexus 7000 Series Switches

Table 5 shows the transceiver devices supported by each release.

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

1.Requires the Cisco Nexus 7010 Scalable Feature Package license (N7K-C7010-XL) or the Cisco Nexus 7018 Scalable Feature Package license (N7K-C7018-XL), depending on the chassis, to enable all XL-capable I/O modules to operate in XL mode.

2.FEX server-facing interfaces should be configured in autonegotiate mode. Do not force a specific data rate. See DDTS CSCuj84520 for additional information.

---

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 Fabric Extenders.

 

 

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

² Minimum version supported is -02.

³ DWDM-SFP10G-C is not supported.

 

Unsupported Hardware

The following list provides the unsupported hardware for Cisco NX-OS Release 7.2(0)D1(1):

• Cisco Nexus 7000 Supervisor 1 Module

FabricPath Bidirectional Forwarding Detection (BFD)

Refer to CSCut89986 bug fix for the FabricPath BFD behavior.

Native VLAN Change Causes Link Flap

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

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

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

– N7K-M206FQ-23L

– N7K-F312FQ-25

– N77-F324FQ-25

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

---

Note Electronic dispersion compensation (EDC) is a method for mitigating the effects of chromatic dispersion in fiber-optic communication links with electronic components in the receiver. The delay in link up event in SFP+ implementation is due to EDC that can mitigate power penalties associated with optical link budgets. On ports or receivers without EDC/non EDC (for example - SFP, where there is no delay in bringing the port up) optical signal can be recovered only if the dispersion is less than approximately one-half Unit Interval (UI) over the length of fiber.

MPLS over GRE

MPLS over GRE is not supported on F3 and M3 modules.

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

The no hardware ejector enable command cannot be a configured command in both the startup configuration and the runtime configuration. This command is a debugging command and should not be configured for long-term use.

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

This applies only to the Cisco Nexus 7700 Series devices.

Routing over VPC

Routing protocol adjacency over a FabricPath VLAN is not supported.

Saving VLAN Configuration Information

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

To work around this limitation, do one of the following:

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

– Copy the VTP data file to the bootflash: data file by entering the copy vtp-datafile bootflash:vtp-datafile command.

– Copy the ASCII configuration to the startup configuration by entering the copy ascii-cfg-file startup-config command.

– Reload the switch.

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

Behavior of Control Plane Packets on an F2e Series Module

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

Error Appears When Copying a File to the Running Configuration

Copying a file to the running configuration can trigger the following error:

 

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

Enter Yes to the prompt “This command will reboot the system. (y/n)? [n] y.”

There is no operational impact and no configuration loss when the switch reloads.

PONG in a vPC Environment

There are two situations where PONG is not supported in a vPC environment:

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

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

LISP Traffic

A Layer 3 link is required between aggregation switches when deploying LISP host mobility on redundant LISP Tunnel Routers (xTRs) that are 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 CoPP rate limiters.

Standby Supervisor Can Reset with Feature-Set Operation

The standby supervisor might reload when a feature-set operation (install, uninstall, enable, or disable) is performed if the 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 VDC where the feature-set operation is performed, enter the show system redundancy ha status command on the active supervisor.

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

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

Unfair Traffic Distribution for Flood Traffic

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

BFD Not Supported on the MTI Interface

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

2012 Jan 3 15:16:35 dc3_sw2-dc3_sw2-2 %PIM-3-BFD_REMOVE_FAIL: pim [22512] Session remove request for neighbor 11.0.3.1 on interface Ethernet2/17 failed (not enough memory)

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

Role-Based Access Control

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

RBAC CLI scripts used in Cisco MDS 9500 Series switches 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, make sure to assign RBAC in Cisco MDS and the Cisco Nexus 7000 storage VDC to different Cisco Fabric Services (CFS) regions.

Level 4 Protocol Entries on the M Series Modules

There is a limitation of using 7 entries for Level 4 protocols on the M Series modules.

Proxy Limitation for the N7K-F132XP-15 Module

When the 6-port 40-Gigabit Ethernet I/O module XL (M2 Series) (N7K-M206FQ-23L) acts as a proxy for more than 90 G traffic from the 32-port 10-Gigabit Ethernet I/O module XL (N7K-F132XP-15), packet drops can occur. You might experience this issue if ports are oversubscribed on the N7K-F132XP-15 F1 Series module.

SVI Statistics on an F2 Series Module

F2 Series I/O modules do not support per-VLAN statistics. Therefore, the show interface command will not display per-VLAN Rx/Tx counters or statistics for switch virtual interfaces (SVIs).

TrustSec SGT on the F3 Series Modules

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

Fabric Module Removal on the Cisco Nexus 7700 Series

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

Fabric Utilization on the Cisco Nexus 7700 Series

When traffic ingresses from a module on the Cisco Nexus 7700 Series 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 Series switch.

MTU Changes Do Not Take Effect on FEX Queues

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

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

Clearing FEX Queuing Statistics Is Not Supported

Cisco NX-OS Release 7.2(0)D1.1 does not support clearing queuing statistics for FEX host interfaces.

Multicast Traffic Is Forwarded to FEX Ports

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

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

F2 Connectivity Restrictions on Connecting Ports to a FEX

If an ASCII configuration has incompatible ports, such as when the configuration is created with ports that are added to the FEX from different line cards or VDC type, 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 replayed.

DSCP Queuing with FEX and M1 Series Modules

Differentiated services code point (DSCP) based queuing does not work for FEX uplinks to the 32-port 10-Gigabit Ethernet SFP+ I/O module (N7K-M132XP-12) or the 32-port 10-Gigabit Ethernet SFP+ I/O module XL (N7K-M132XP-12L). All FEX data traffic will be in the default queue.

This limitation applies only when a FEX is attached to ports on a N7K-M132XP-12 or N7K-M132XP-12L module. It does not affect COS based queuing.

DHCP Snooping with vPC+ FEX

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

Storm-control Suppresses Unicast Traffic

When you use the storm-control unicast level percentage command in a module, both the unknown and known unicast traffic gets discarded after reaching the threshold value.

Supported Upgrade and Downgrade Paths

---

Note 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.

Do not change any configuration settings or network settings during a software upgrade. Any changes in the network settings might cause a disruptive upgrade.

See Table 7 for the in-service software upgrade (ISSU) path to Cisco NX-OS Release 7.2(2)D1(1). Releases that are not listed for a particular release train do not support a direct ISSU.

See Table 8 for the ISSU path to Cisco NX-OS Release 7.2(1)D1(1). Releases that are not listed for a particular release train do not support a direct ISSU.

See Table 9 for the ISSU path to Cisco NX-OS Release 7.2(0)D1(1). 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 7.2(0)D1(1) and later releases.

SMUs are dependent on the version of Cisco NX-OS software release installed. You need to install SMUs compatible with your release. Moving to another Cisco NX-OS software release using reload or ISSU will inactivate the SMUs installed for the previously installed Cisco NX-OS software release. For example, if you have SMUs for Cisco NX-OS Release 7.2.0 in your Supervisor 2 setup, moving to an image of another release, say Cisco NX-OS Release 7.2.2 will cause the SMU to become inactive.

However, once the upgraded system is running the new target code, the fix from SMU will no longer be activated. If your new upgraded version does not have the fix from the SMU, you can obtain and install the SMU corresponding to your new release. See the Guidelines and Limitation of SMU for details on installing SMU.

---

Note For a non-disruptive upgrade dual supervisor modules are required.

ISSU Paths for Cisco NX-OS Release 7.2(2)D1(2)

See Table 6 for the in-service software upgrade (ISSU) path to Cisco NX-OS Release 7.2(2)D1(2).

---

Note Only the ISSU combinations in the following table have been tested and are supported.

 

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

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

Note

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

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

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

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

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

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

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

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

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

ISSU Paths for Cisco NX-OS Release 7.2(2)D1(1)

---

Note Only the ISSU combinations in the following table have been tested and are supported.

 

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

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

Note

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

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

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

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

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

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

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

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

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

ISSU Paths for Cisco NX-OS Release 7.2(1)D1(1)

---

Note Only the ISSU combinations in the following table have been tested and are supported.

 

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

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

Note

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

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

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

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

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

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

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

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

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

ISSU Paths for Cisco NX-OS Release 7.2(0)D1(1)

---

Note Only the ISSU combinations in the following table have been tested and are supported.

 

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

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

Note

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

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

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

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

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

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

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

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

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

In-Service Software Upgrade (ISSU)

To perform an ISSU upgrade to Cisco NX-OS Release 7.2(x) from one of the ISSU supported releases listed in the tables in the preceding section, 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.

4. Start the ISSU procedure.

In-Service Software Upgrade (ISSU) Caveats

• When you upgrade to Cisco NX-OS Release 7.x and if you are using a non-default native VLAN (other than vlan 1), ensure you have the VLAN created on the switch, otherwise spanning tree BPDUs will be dropped.
• When you perform ISSU in a set up where the Routing Information Protocol (RIP) has dependency on other protocols for redistribution, you should adjust the RIP timers because RIP does not support stateful restart. Use the timers basic update invalid holddown flush command in the address-family-mode under the router configuration mode to adjust the timer values.
• SMU on the F3 module bound process is not supported in Cisco NX-OS Release 7.2(1)D1(1). After you install, activate, commit, and reload the switch, SMU on an F3 module will not be active. SMU on the F3 module bound process is supported from Cisco NX-OS Release 7.2(2)D1(1) onwards.
• When you upgrade to either Cisco NX-OS Release 7.2(0) or Cisco NX-OS Release 7.2(1) you need to remove any existing FabricPath BFD configuration. FabricPath BFD is not supported in Cisco NX-OS Release 7.2(0) and Cisco NX-OS Release 7.2(1). FabricPath BFD is supported from Cisco NX-OS Release 7.2(2) onwards.
• FCoE FEX

– Post ISSU you need to change port-channel load-balance for FEX, 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 default load-balance after changing the load-balance for FEX.

• Before downgrading to unsupported release, F3 FCoE License installed in the 7.2(0) release should be uninstalled.
• For the ISSU support details for VXLAN flood and learn deployment, refer to the following: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/vxlan/configuration/guide/b_NX-OS_VXLAN_Configuration_Guide/configuring_vxlan_flood_and_learn.html#concept_A7EB2DCC739E4E24AF24E20E7A6BF4F8.
• ISSU from 6.2.X to 7.2(0) with MPLS L2VPN configuration:

– After upgrading ISSU to 7.2(0)D1(1) MPLS L2VPN/L3VPN service updates are not processed in F3 modules.This happens when F3 module is a part of a VDC that already has MPLS configured in it. To resolve this issue, reload the F3 module after ISSU and before you do any further updates on MPLS L2VPN/L3VPN.

• 6.2.X to 7.2(0) ISSU support for OTV/GRE/ERSPAN on F3 series modules:

– ISSU is blocked and it requires cold boot from 6.2.X to 7.2(0) when OTV/GRE/ERSPAN is enabled on F3.

• ISSU from releases prior to Cisco NX-OS Release 7.2(0)D1(1) is not supported when OTV, GRE or ERSPAN are configured on the F3 series modules:

– The tunneling architecture for the F3 series module has been changed in the Cisco NX-OS Release 7.2(0)D1(1) in such a way that upgrading from 5.x or 6.x to 7.2.(0) is a disruptive process. Therefore ISSU is not supported from releases prior to the Cisco NX-OS Release 7.2(0)D1(1) release if OTV, GRE or ERSPAN have been enabled in VDCs where F3 series module interfaces have been allocated.

– There are two approaches to re-enabling ISSU support:

i) Completely remove the OTV, GRE, and/or ERSPAN configurations from VDCs where F3 series module interfaces are allocated.

ii) Removing the F3 series module interfaces from VDCs where OTV, GRE, and/or EERSPAN have been deployed on non-F3 series modules.

– ISSU is still fully supported if these features (OTV/GRE/ERSPAN) are enabled in VDCs with non-F3 series modules.

• For multi-hop ISSU scenario for releases earlier than Cisco NX-OS Release 7.2(0) refer to the following:

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

Non In-Service Software Upgrade (ISSU) Steps

To perform a non-ISSU upgrade to Release 7.2(x) from any supported Cisco NX-OS release prior to Release 7.2(0), follow these steps:

1. Change the boot variable.

Example:

2. Enter the copy running-config startup-config vdc-all command.

3. Enter the reload command to reload the switch.

---

Note Allow time after the reload for the configuration to be applied.

To perform a non-ISSU upgrade from any supported Cisco NX-OS release PRIOR to Release 6.2(2) or 6.2(2a), 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. Change the boot variable to boot Release 7.2(0)D1(1).

4. Enter the copy running-config startup-config vdc-all command.

5. Enter the reload command to reload the switch.

---

Note Allow time after the reload for the configuration to be applied.

6. Once all modules come up, enter the show running-config aclmgr command in all VDCs.

7. Enter the clear inactive-config acl command for all VDCs.

8. Enter the copy bootflash:/vdc_x/aclmgr-inactive-config.cfg running-config command for all VDCs.

For complete instructions on upgrading your software, see the Cisco Nexus 7000 Series NX-OS Upgrade Downgrade Guide.

---

Note Non-ISSU upgrades/downgrades are also referred to as cold boot. During a cold boot, the network administrator changes the boot variables for the system image and the kickstart image followed by a switch reload.

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, NXOS 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.

Feature Support:

Any features introduced in a release must be disabled before downgrading to a release that does not support those features.

Unsupported Modules:

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.

Cisco NX-OS Release 7.2(2)D1(2) has the following cold boot support matrix:

Cisco NX-OS Release 7.2(2)D1(1) has the following cold boot support matrix:

Cisco NX-OS Release 7.2(1)D1(1) has the following cold boot support matrix:

Non In-Service Software Downgrade (non-ISSU)/Cold Boot Downgrade Steps

Instructions provided below list the steps for the cold boot (non-ISSU) downgrade. This is an example of a cold boot downgrade of a switch that is running Cisco NX-OS Release 7.2(x) and needs to reload with Cisco NX-OS Release 6.2 (12).

• Save the switch configuration.

– Enter copy running-config bootflash:<config.txt> vdc-all command.

• Change the boot variable to boot the target release.
• Enter copy running-config startup-config vdc-all command to save the boot variable.
• Enter write erase command to erase running configuration on the switch.
• Enter reload 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.
• Verify that the switch is configured correctly.
• Replay the configuration copy to check if fex interfaces exist.

– Enter the copy bootflash:<config.txt> running-config command.

Cisco Nexus 7702 Switch

The Cisco Nexus 7702 switch is a 2-slot switch with 1 slot for a supervisor module and 1 slot for an I/O module. It supports Supervisor 2E modules and F3 series I/O modules. It does not support F2E series I/O modules. The Cisco Nexus 7702 switch supports NX-OS patching, Graceful Insertion and Removal, and disruptive upgrade with installer. The Cisco Nexus 7702 switch has two power supply module slots and supports all power supply redundancy modes.

The Cisco Nexus 7702 switch has one fan-tray which has 3 variable speed fans.

– If one fan fails, the remaining two fans run at full speed to keep the switch operational. An alert will also be displayed every 10 seconds.

– If two or more fans fail, the switch will shut down in 120 seconds.

– If the fan-tray is removed, the switch will shut down in 120 seconds.

• All Supervisor 2E modules shipped with the Nexus 7702 switch will be shipped with FPGA version 1.4.

– If you install a spare Supervisor 2E module on the Nexus 7702 switch you must upgrade the FPGA version to 1.4.

– In such a situation you will be notified with alert: “<<%PLATFORM-1-PFM_ALERT>> Incompatible Sup FPGA(12), upgrade FPGA >= 0x14 “.

---

Note I/O Module cannot be used till the Sup2E upgrade is completed.

Cisco NX-OS Release 7.2(2)D1(1)

Cisco NX-OS Release 7.2(2)D1(1) does not have any new feature and this is a bug fix only release.

Cisco NX-OS Release 7.2(1)D1(1) – Software Features

Cisco NX-OS Release 7.2(1)D1(1) includes the following features:

• BFD FSA Offload on F3
• Cisco TrustSec MACSec over FabricPath on F3
• ITD Destination NAT
• Multiple Device-Groups within an ITD Service
• Scale Limit Monitoring

BFD FSA Offload on F3

The BFD Fabric Services Accelerator (FSA) Offload on F3 Line Card feature allows the offload of asynchronous BFD transmission (Tx) and reception (Rx) to the network processing unit on the F3 line card. The BFD FSA Offload on F3 Line Card feature improves scale and reduces the overall network convergence time by sending rapid failure detection packets (messages) to the routing protocols for recalculating the routing table.

Cisco TrustSec MACSec over FabricPath on F3

Cisco TrustSec MACSec is supported over FabricPath via native VLAN tagging on trunk and FabricPath ports feature. Native VLAN tagging can be configured either globally or on an interface for control packets and data packets.

Starting from Cisco NX-OS Release 7.2(1)D1(1), Cisco TrustSec MACsec support on FabricPath is available on F3 modules.

ITD Destination NAT

Network Address Translation (NAT) is a commonly deployed feature in load balancing, firewall, and service appliances. Destination NAT is one of the types of NAT that is used in load balancing because of the following advantages it provides:

• The traffic from source or client to the virtual IP address is rewritten and redirected to server.
• The traffic from the source or client to the destination or server, which is the forward path, is handled as follows: the traffic from the source or client to virtual IP address is translated and redirected as the traffic from source to the destination or server.
• The traffic from the destination to the source or client, which is the reverse path, is re-translated with the virtual IP address as the source IP address. That is, the traffic from the server or source to the client or destination is translated as client or source to client or destination.

Multiple Device-Groups within an ITD Service

The feature, by enabling the existence of multiple device-groups per service on the same interface, allows the ITD to scale. The traffic from one ingress interface is distributed based on both VIPs and device-groups.

An ITD service generates a single route-map that has next hops point to nodes from different device-groups.

Scale Limit Monitoring

Cisco NX-OS Release 7.2(1)D1(1) introduced support for scale limit monitoring on Cisco Nexus 7000 Supervisor 2 and Supervisor 2E and on Cisco Nexus 7700 switches. The Scale Limit Monitoring feature enables you to monitor the scale limit both at the system level and the VDC level. This feature monitors the scale limits for various features across different VDCs on the device and alerts you if the system crosses the permissible scale limit.

Cisco NX-OS Release 7.2(0)D1(1) – Software Features

Cisco NX-OS Release 7.2(0)D1(1) includes the following features:

• Dynamic Fabric Automation (DFA)
• Enhancements on the F3 Module
• FCoE Enhancements
• Platform Enhancements

Dynamic Fabric Automation (DFA)

This software release is the first release to support Cisco's Evolutionary Data Center Fabric solution called Dynamic Fabric Automation (DFA). DFA is evolutionary and is based on the industry leading Unified Fabric solution.

DFA focuses on simplifying, optimizing and automating data center fabric environments by offering an architecture based on four major pillars namely Fabric Management, Workload Automation, Optimized Networking and Virtual Fabrics. Each of these pillars provide a set of modular functions which can be used together or independently for easiness of adoption of new technologies in the data center environment.

Complete details on the DFA architecture can be found at: http://www.cisco.com/go/dfa.

DFA allows optimization of data centers through integration of Fabric Management, Workload Automation, Optimized Networking using enhanced forwarding and Anycast distributed gateway functionality and Virtual Fabrics. For more information on DFA configuration refer Cisco Dynamic Fabric Automation Configuration Guide.

Multi-tenancy

Multi-tenancy is a concept that refers to the logical isolation of shared virtual compute, storage, and network resources. In multi-tenant data center, tenants subscribe to virtual data center (VDC), and based on the services hosted by the tenants within the virtual data center, each virtual data center can have multiple VN-Segments.

Multi-tenant data center handles the traffic segregation between different tenants, and also within tenant traffic, for security and privacy.

Conversational Learning

You can enable conversational learning on all leaf nodes by using the fabric forwarding conversational-learning all command. For this command to work, the subnet needs to be instantiated on the leaf. But in case of a border leaf, this is not true as the border leaf might not have any hosts connected to it. So, the routes will always get installed in forwarding information base (FIB). But border leaf is the point of heavy load in the network and needs to conserve precious forwarding space. In this regard, we can add configuration at the border leaf for each subnet using the fabric forwarding aggregate-subnet-prefix command.

To enable Layer-3 conversational learning-based route download into the forwarding information base (FIB), use the fabric forwarding conversational-learning all command. And to configure the conversational aging timeout value, use the fabric forwarding conversational-aging timeout command.

Auto Configuration

Auto Configuration simplifies the management of the VRF and VLAN/BD configurations. Auto configuration can be triggered by:

• Any data frame Frame snooping
• VDP signaling from the server

Single Point of Management (SPOM)

Single Point of Management (SPOM) feature provides a single point of access from any switch to any other switches in the fabric.

SPOM utilizes XMPP as a communication protocol. SPOM feature allows customers to use XMPP chat clients running on laptops, mobile devices to talk to SPOM feature enabled switches in the network and execute the CLI commands remotely from XMPP clients.

Extensible Messaging and Presence Protocol (XMPP)

Extensible Messaging and Presence Protocol (XMPP) is a communication protocol. XMPP clients set up TCP based XMPP connection to XMPP server. XMPP server forwards the messages from one client to another client or a group of clients based on the configuration and request.

This XMPP protocol is adopted by DFA, so the administrator can manage (by issuing CLI commands) a device or group of devices in the network from the administrator’s XMPP connection with a single point of management with no separate login required for each device. Each device is a XMPP client that can be configured to connect to XMPP server. The administrator issues the CLI command and the device receives the CLI commands. Device processes the CLI commands and sends CLI output back to the administrator XMPP client.

XMPP client support is added to the Cisco NX-OS operating system with DFA from 7.2(0)D1(1) for Cisco Nexus 7000 Series Switches.

Cable Management

In a highly meshed network such as Clos topology based network fabric, miscabling can be a pragmatic problem leading to painful troubleshooting without sufficient support. The cable management feature calls out for two mechanisms to address the miscabling issues caused due to human errors. The first mechanism is based on the tier-based checks and the second mechanism is based on a user-defined cabling plan.

Enhancements on the F3 Module

VXLAN (L2/L3 gateway and BGP EVPN)

VXLAN is MAC in IP (IP/UDP) encapsulation technique with a 24-bit segment identifier in the form of a VNID (VXLAN Network Identifier). The larger VNID allows LAN segments to scale to 16 million in a cloud network. In addition, the IP/UDP encapsulation allows each LAN segment to be extended across existing Layer 3 network making use of L3 ECMP.

This feature set includes; Flood and Learn using outer multicast group for Broadcast, unknown unicast and multicast traffic, and L2/L3 VXLAN Gateway.

VXLAN with the MP-BGP/EVPN control plane is supported with the Cisco Nexus 7000 series switch acting as border-leaf with no L2 gateway functionality, vPC or ingress replication support.

MPLS on F3

Support for the following MPLS features has been added to F3 modules- MPLS L2VPN, MPLS L3VPN, MPLS TE, MPLS TE-CBTS, MPLS QoS, 6PE/6VPE and MVPN. The forwarding scale for these features is limited to the size of hardware tables (TCAM and adjacencies - 64K) on F3 modules. Control plane scale-like number of VRFs remains same as M Series modules.

EVC infrastructure has also been added for F3 modules.

MPLS Inter AS option B

With inter AS option A solution, back-to-back VRF between ASBR needs to be configured for routing exchange for each VRF. With Inter AS option B, there will be single eBGP VPNV4 connection between ASBRs and they can exchange routes associated with all VRFs.

This feature is supported on F3, M1, and M2 modules.

LISP support on F3

The following features are supported:

• ITR, ETR, and Host Mobility support on F3 modules.
• Hand off between VXLAN and LISP encapsulations is supported on F3 modules.
• Selective VRF is also supported for LISP.

Physical Port vPC for F3

Enables physical port virtual port channel for F3 modules.

F3 ERSPAN Termination

This feature supports termination of ERSPAN traffic entering F3 interfaces. It is supported for both ERSPAN type II and type III.

FCoE Enhancements

FCoE on F3

This feature brings support for T11’s FC-BB_E standard FCoE over lossless Ethernet on F3-series module variants to Cisco Nexus 7000 series and Cisco Nexus 7700 series platforms in storage VDC.

The following F3 cards are supported on FCoE:

• N77-F348XP-23 (48 port 10G card for Cisco Nexus 7700 Series)
• N77-F324FQ-25 (24 port 40G card for Cisco Nexus 7700 Series)
• N7K-F312FQ-25 (12 port 40G card for Cisco Nexus 7000 Series)

Refer to Table 3 for more details on the FEX modules supported by the Cisco Nexus 7000 Series I/O modules.

FCoE FEX

The FCoE over Fabric Extenders (FEX) feature allows Fibre Channel traffic to be carried on a FEX port. To enable this feature, the FEX port is shared with the storage Virtual Device Context (VDC). The FEX is connected to the Cisco Nexus 7000/7700 device through a Fabric Port Channel (FPC). FCoE over FEX enables provision of FCoE on host connections.

The following FCoE FEX models are supported:

• N2K-C2232PP-10GE
• N2K-B22HP-P

Refer to Table 3 for more details on the FEX modules supported by the Cisco Nexus 7000 Series I/O modules. Refer to Cisco NX-OS FCoE Configuration Guide for FCoE FEX configuration details.

FCoE on FabricPath over Spine

Fibre Channel over Ethernet (FCoE) enables I/O consolidation. It permits both LAN and SAN traffic to coexist on the same switch and the same wire. This feature enables you to consolidate multiple separate networks into a single converged infrastructure.

Beginning with Cisco NX-OS Release 7.2(0)D1(1), you can use a Cisco Nexus 7000/7700 device as a spine in an FCoE over FabricPath network. Quality of Service (QoS) settings are enabled on the spine. Refer to Cisco NX-OS FCoE Configuration Guide for more details on FCoE on FabricPath over Spine.

FCoE Scale

Refer to Cisco Nexus 7000 Series NX-OS Verified Scalability Guide for FCoE over FEX scale numbers for Cisco NX-OS Release 7.2(0)D1(1).

Platform Enhancements

Graceful Insertion and Removal (GIR)

You can use GIR to isolate a switch from the network in order to perform debugging or an upgrade. When switch maintenance is complete, you can return the switch to normal mode. When you place the switch in GIR/maintenance mode, all protocols are gracefully brought down and all physical ports are shut down. When normal mode is restored, all the protocols and ports are brought back up.

The following protocols are supported:

• Border Gateway Protocol (BGP)
• BGPv6
• Enhanced Interior Gateway Routing Protocol (EIGRP)
• EIGRPv6
• Intermediate System-to-Intermediate System (ISIS)
• Open Shortest Path First (OSPF)
• OSPFv3

The following features are also supported:

• Virtual port channel (vPC)
• Interfaces
• FabricPath

You can create a GIR/maintenance mode profile file before you put the switch in maintenance mode or you can allow the system to create a maintenance mode profile file when you enter the [no] system mode maintenance command.

You can create maintenance-mode or normal-mode profile files by using the config profile maintenance-mode type admin and config profile normal-mode type admin commands respectively.

NXOS Patching

This feature provides the following:

• Allows customer to deploy patch for point fixes.
• Unlike engineering specials, ISSU is maintained. Customer can install patches and then do ISSU to next release.
• Both binaries and libraries can be patched.
• Both module and SUP services can be patched.
• Software patching using process-restart/reload or ISSU

Actual deployment of patches might vary based on platform. For example, on some platform, if process to be patched cannot be restarted, patch will be deployed either by reload or ISSU and on other hand software can be patched simply by restarting the process for process-restart patch.

FEX AA features

Fabric Extender (FEX) is a pass-through/mux device designed to provide top of rack or end of line connectivity for servers/hosts. Currently FEX can be connected to only one Cisco Nexus 7000 series switch. If the switch goes down, FEX loses connectivity to the network. Hence all the singly connected hosts via the FEX also lose connectivity to the network. To solve this problem, FEX can be connected to two Cisco Nexus 7000 series switches in Active-Standby mode or Active-Active mode (vPC). We choose the Active-Active solution because vPC provides seamless switchover and faster convergence in case of switch failure. Moreover, traffic is also sprayed across both switches providing full utilization of bandwidth.

vPC Configuration Synchronization

In a vPC topology, Type-1 configuration mismatch between the peer switches can bring down the vPC leg. Administrator has to manually give the same configuration on each vPC peer switch. The vPC configuration synchronization feature provides a mechanism to keep the Type-1 configuration same on both the switches. With this feature enabled, user needs to modify the Type-1 configuration only on one switch and the vpc-config-sync will synchronize the configuration to the peer switch. The vpc-config-sync will support syncing of all global Type-1 configurations and the Type-1 configuration of vPC port-channel/Physical-Port/FEX Active-Active Ports. The vpc-config-sync will also automatically merge the Type-1 configuration when the switch boots up with start-up configuration.

Dynamic Routing over vPC

Dynamic Routing over vPC feature is supported only on F2E and F3 series modules (for IPv4 Unicast traffic only). This feature enables L3 routing protocols such as OPSF to form adjacency with the two vPC peer chassis. The equal routing cost matrices must be configured on applicable interface on each of the vPC peers, failure to do so can result in blocking the traffic. Asymmetric routing feature has to be implemented to address this issue and to configure Dynamic Routing over vPC. Additionally, when Dynamic Routing over vPC is enabled a warning log message is printed.

VIP HSRP Enhancement

Starting with Cisco NX-OS Release 7.2(0)D1(1), the Virtual IP (VIP) Hot Standby Router Protocol (HSRP) enhancement feature provides support for an HSRP Virtual IP configuration to be in a different subnet than that of the interface subnet. This feature is supported only for IPv4 address and not for IPv6. The following are the enhancements:

• Enhance ARP to source with VIP from Supervisor Engine (SUP) for hosts, when the hosts in VIP subnet are referenced by static route to VLAN configuration.
• Support periodic ARP synchronization to VPC peer if VIP HSRP feature is enabled.
• Allow VIP address as the Layer 3 source address and gateway address for all communications with a Dynamic Host Configuration Protocol (DHCP) server.
• Enhance DHCP relay agent to relay DHCP packets with source as VIP address instead of SVI IP when the feature is enabled.

---

Note HSRP subnet VIP should be configured in the virtual port channel topology.

For more information, see Cisco Nexus 7000 Series Unicast Configuration Guide.

NX-API

NX-API provides programmatic access to the switches by allowing application developers to remotely issue CLI commands over HTTP/HTTPS. It supports requests and responses in JSON-RPC, JSON, and XML formats.

BFD over IP Unnumbered Interfaces

In the leaf-spine architecture to reduce complexity of IP address management, interfaces could be unnumbered (which means configured with no IP addresses) but designated to derive IP address from other numbered interface. BFD is supported over such unnumbered IP interfaces for fast failure detection.

L2 BFD over FabricPath Core Ports

This feature support is added to detect forwarding failures between two directly connected switches in a fabric, which are connected through FabricPath Link. The BFD session exchanges BFD packets with classical Ethernet encapsulation over FabricPath core ports.

L3 BFD Sessions over FabricPath Links

When switches are connected through FabricPath and core port is configured for L3 services over SVI, BFD over FabricPath is required for L3 routing clients for faster convergence. If there are SVIs configured in spine and leaf node with IP addresses and if the neighbor is reachable through FabricPath network, BFD resolves adjacency for the given L3 peer address over FabricPath link and exchanges BFD packets with FabricPath Encapsulation.

VTP v3

VTP3 supports configuration propagation of all 4k VLANs (including private VLANs); an increase from the 1K VLANs in VTPv1/ VTPv2 to 4K in VTP v3.

The introduction of primary VTP server mode eliminates the VTP bombing issue, so a newly inserted VTP switch will not erase other VTP databases in the network.

It supports the propagation of MST configuration, when the switch is configured as MST primary server.

MVPN QoS Enhancement

This feature copies the inner TOS to outer TOS for MVPN.

OTV UDP Encapsulation

OTV UDP encapsulation header support is added on F3 modules. The OTV UDP encapsulation is supported in a F3 only VDC.

LISP Host Route Notification Registration for Host Mobility

Registration of Host Route Notification into LISP Mobility is supported to provide automated interoperability with domains using IGPs, BGP-VPNv4, and BGP-EVPN (VXLAN). Tag-based filtering is supported as part of the Route Notification Registration feature.

FabricPath OAM

FabricPath OAM facilitates operators to monitor, isolate and verify data plane faults on FabricPath networks. FabricPath Ping, Trace route and Multicast Trace route are the 3 main tools. These tools can be invoked on demand. This feature implementation also allows to include flow entropy to validate specific path taken by data in multi path environment.

MAC Security

The MAC Security (MACSec) feature is used for data encryption and decryption. MACSec support is available on F3 Series modules in Cisco NX-OS Release 7.2.0D1(1) with the following caveats:

• F3 Series modules with fiber interfaces—The last eight ports (41 to 48) support MACSec (N7K-F348XP-25 and N77-F348XP-23).

---

Note On the F3 Series, only the 10-Gigabit I/O module offers MACSec capabilities for classic Ethernet. The 40-Gigabit and 100-Gigabit F3 Series modules do not support MACSec.

TrustSec SGT Enhancement

This feature extends the TrustSec functionality to vPC/vPC+ environments. Specifically, this includes SGT tagging, SGT propagation, IP-SGT mapping, Port-SGT mapping, VLAN-SGT mapping, SGACL enforcement, SGName download, AAA policy download, SXP, MACSec and SGT caching. It is required to ensure consistent TrustSec configuration between vPC/vPC+ peers and no configuration compatibility checks (neither type-1 nor type-2) will be enforced.

SGT classification is a feature that is configurable under “cts manual” and “cts dot1x” modes. The “SGT classification via port-profiles” feature entails the changes to support port-profiles for the SGT configuration.

SGT in conjunction with Anycast HSRP or Active/Standby HSRP

CTS over vPC/vPC+ feature ensures dynamically learnt IP-SGT on both the peers are consistent. The vPC peers could also be HSRP routers.

200K IP-SGT mapping support on the M-Series module with large buffer support

IP-SGT scale is enhanced to support 200K entries subject to LC module’s TCAM capacity. M-series module (XL) supporting large TCAM sizes can easily hold 200K IP-SGT bindings.

Environment data CoA

The environment data changes can be updated using ISE push command.

SGACL update method/Per policy CoA

The SGACL policy changes can be updated using ISE push command.

CTS Port-channel compatibility check

CTS interface commands are supported under port-channels also with the necessary compatibility checks.

NetFlow

The following NetFlow features are supported beginning with Cisco NX-OS Release 7.2(0)D1(1):

Fabric Services Accelerator (FSA)

FSA is enabled for NetFlow on F3 series module. FSA increases the packet processing up to 50 thousand packets per second.

Egress NetFlow Support on F3 modules

From Cisco NX-OS Release 7.2(0)D1(1) onwards egress NetFlow is also supported on F3 modules. Egress NetFlow is accomplished by the command ip flow monitor monitor-name output sampler sampler-name. In earlier software version only ingress NetFlow was supported on F3 modules. Egress NetFlow is not supported on F2 and F2e line cards.

Exposure of 1:128 Sampling on F3 cards

F3 interface allows sampler as m:n for 1<=m<=31 and 1<=n<=131071.

NetFlow Support on F2, F2e, F3 Sub-interfaces

NetFlow is now supported for L3 sub-interfaces on F-series modules. Refer to Cisco Nexus 7000 Series NX-OS System Management Configuration Guide for NetFlow configuration details.

SPAN features

Following SPAN features are introduced:

• Enhanced SPAN filtering capability; by supporting combination of multiple filter rules into filter lists and allowing negative rules. This feature is applicable to extended SPAN sessions only and subject to filter resource availability.

Multiple SPAN sessions are allowed to share same destination interface, as long as rate-limit auto is not configured for these sessions.

ITD Enhancements

Following new ITD features are introduced:

• ITD node-level probes
• ITD node-level standby devices
• ITD IPv4 control plane probes to monitor IPv6 data nodes
• ITD exclude feature

RISE RHI and AutoSPAN

Cisco RISE has been enhanced to support Route Health Injection (RHI) with the Citrix NetScaler products and AutoSPAN with the Cisco Prime NAM appliance. RHI support allows VIP advertisement without the need for running routing instances on the Citrix NetScaler. AutoSPAN enables Cisco Prime NAM users to logically move data ports across VDCs within the Nexus 7000 and automatically setup SPAN sessions directly from the Cisco Prime NAM GUI.

PIM BIDIR Support on F2E

Product Independent Multicast (PIM) Bidirectional (BIDR) is supported in a F2E only Virtual Device Context (VDC), F2E /M VDC (with F2E proxying to M1/M2) and F2E/F3 VDC.

WCCP Configurable Heartbeat/Fast Timers

The WCCP—Fast Timers feature enables WCCP to establish redirection using a configurable message interval when a WCCP client is added to a service group or when a WCCP client fails. WCCP routers and WCCP clients exchange keepalive messages at a fixed interval. Prior to the introduction of the WCCP—Fast Timers feature, the WCCP message interval was fixed at 10 seconds. The WCCP—Fast Timers feature enables use of message intervals ranging from 0.5 seconds to 60 seconds and a timeout value scaling factor of 1 to 5. The default is 10 seconds. The timer interval is driven by the WCCP client which is being redirected to. The WCCP clients must support variable message interval timers in order for the WCCP—Fast Timers feature to function correctly.

The WCCP message interval capability introduced by the WCCP—Fast Timers feature defines the transmission interval that WCCP clients and WCCP routers use when sending keepalive messages and defines a scaling factor used when calculating the timeout value. The WCCP router uses the timeout value to determine if a WCCP client is no longer available and to redirect traffic as a result. The WCCP router enforces a single message interval per service group. WCCP clients with incompatible message intervals are prevented from joining a service group. If a default message interval that is smaller than the default 10 seconds is used, CPU usage will increase.

Network Interface (NIF) Monitoring

Starting from Cisco NX-OS Release 7.2(0)D1(1), the SNMP trap clogMessageGenerated will carry the syslog payloads as SNMP trap contents. If a feature does not have a trap implemented but the syslog is logged, then the syslog will be carried by the SNMP trap mentioned above.

MIB Object	Description
cevChassisN77c7702 OBJECT IDENTIFIER ::= {cevChassis 1648}	Cisco NX-OS 7700 2-slot chassis
cevBackplaneN77c7702 OBJECT IDENTIFIER ::= {cevBackplane 70}	Cisco NX-OS 7700 2-slot backplane
cevContainerN77c7702PowerSupplyBay OBJECT IDENTIFIER ::= {cevContainer 336}	Container for Cisco NX-OS 7700 2-slot power supply
cevContainerN77c7702FanBay OBJECT IDENTIFIER ::= {cevContainer 337}	Container for Cisco NX-OS 7700 2-slot fan
cevFanN77c7702Fan OBJECT IDENTIFIER ::= {cevFan 255}	Fan for Cisco NX-OS 7700 2-slot chassis

---

Open Caveats—Cisco NX-OS Release 7.2