The Cisco NX-OS software is a data center-class operating system built with modularity, resiliency, and serviceability at its foundation. Based on the industry-proven Cisco MDS 9000 SAN-OS software, Cisco NX-OS helps ensure continuous availability and sets the standard for mission-critical data center environments. The highly modular design of Cisco NX-OS makes zero-effect operations a reality and enables exceptional operational flexibility.
Several new hardware and software features are introduced for the Cisco Nexus 5000 Series switch and the Cisco Nexus 2000 Series Fabric Extender (FEX) to improve the performance, scalability, and management of the product line. Cisco NX-OS Release 5.2 also supports all hardware and software supported in Cisco NX-OS Release 5.1, Cisco NX-OS Release 5.0, and Cisco NX-OS Software Release 4.2.
Cisco Nexus 5000 Series Switches
The Cisco Nexus 5000 Series switches include a family of line-rate, low-latency, lossless 10-Gigabit Ethernet, Cisco Data Center Ethernet, Fibre Channel over Ethernet (FCoE), and native Fibre Channel switches for data center applications. The Cisco Nexus 5000 Series includes the Cisco Nexus 5500 Platform and the Cisco Nexus 5000 Platform.
For information about the Cisco Nexus 5000 Series, see the
Cisco Nexus 5000 Series and Cisco Nexus 5500 Platform Hardware Installation Guide
Cisco Nexus 2000 Series Fabric Extenders
The Cisco Nexus 2000 Series Fabric Extender (FEX) is a highly scalable and flexible server networking solution that works with the Cisco Nexus 5000 Series switches to provide high-density and low-cost connectivity for server aggregation. Scaling across 1-Gigabit Ethernet, 10-Gigabit Ethernet, unified fabric, rack, and blade server environments, the FEX is designed to simplify data center architecture and operations.
The FEX integrates with its parent Cisco Nexus 5000 Series switch, which allows zero-touch provisioning and automatic configuration. The FEX provides a single point of management that supports a large numbers of servers and hosts that can be configured with the same feature set as the parent Cisco Nexus 5000 Series switch, including security and quality of service (QoS) configuration parameters. Spanning Tree Protocol (STP) is not required between the Fabric Extender and its parent switch because the Fabric Extender and its parent switch allow you to enable a large multi-path, loop-free, active-active topology.
Software is not included with the Fabric Extender. Cisco NX-OS software is automatically downloaded and upgraded from its parent switch. For information about configuring the Cisco Nexus 2000 FEX, see the “Configuring the Fabric Extender” chapter in the
Cisco Nexus 5000 Series Layer 2 Switching Configuration Guide
New Software Features in Cisco NX-OS Release 5.2(1)N1(7)
Cisco NX-OS Release 5.2(1)N1(7) does not include new software.
New Software Features in Cisco NX-OS Release 5.2(1)N1(6)
Cisco NX-OS Release 5.2(1)N1(6) is a maintenance release that includes bug fixes and introduces this new feature:
You can now configure static DHCP bindings and port security features simultaneously on the same interface.
New Software Features in Cisco NX-OS Release 5.2(1)N1(5)
Cisco NX-OS Release 5.2(1)N1(5) is a maintenance release that includes bug fixes and introduces this new feature:
CLI for controlling digital optical monitoring (DOM) on a Switchport. By default, DOM polling is disabled. The new CLI commands allow you to turn polling on and off and monitor status.
Table 4 summarizes DOM polling availability for Cisco NX-OS Release 5.2(1)N1(5) and previous 5.2(1)N1(x) releases.
Table 4 DOM Polling Capability by Cisco NX-OS Release
DOM Polling Feature
Cisco NX-OS Release 5.2(1)N1(5)
Cisco NX-OS Release 5.2(1)N1(4)
Cisco NX-OS Release 5.2(1)N1(3) and Earlier
Switchport DOM Polling
Supported, disabled by default
CLI available to enable/disable.
Enabled by default
HIF DOM Polling
New Software Features in Cisco NX-OS Release 5.2(1)N1(4)
Cisco NX-OS Release 5.2(1)N1(4) is a maintenance release that includes bug fixes and introduced this new feature:
Switchport digital optical monitoring (DOM) is available and enabled by default.
New Software Features in Cisco NX-OS Release 5.2(1)N1(3)
Cisco NX-OS Release 5.2(1)N1(3) is a maintenance release that includes bug fixes and the following software feature:
Support for Cisco Nexus B22 Fabric Extender for Dell (N2K-B22DELL-P).
New Software Features in Cisco NX-OS Release 5.2(1)N1(2a)
Cisco NX-OS Release 5.2(1)N1(2a) is a patch release that provides bug fixes. It does not include new software features.
New Software Features in Cisco NX-OS Release 5.2(1)N1(2)
Cisco NX-OS Release 5.2(1)N1(2) is a maintenance release that includes bug fixes and the following software feature:
NIF Storm Control
NIF Storm Control
You can configure traffic storm control on a Fabric Extender (FEX) port. Storm control configured on a FEX port applies to the aggregate traffic coming in on all the ports on that FEX, however, the storm control configuration is not inherited down to the host interface (HIF) ports.
New Software Features in Cisco NX-OS Release 5.2(1)N1(1b)
Cisco NX-OS Release 5.2(1)N1(1b) is a patch release that provides bug fixes. It does not include new software features.
New Software Features in Cisco NX-OS Release 5.2(1)N1(1a)
Cisco NX-OS Release 5.2(1)N1(1a) is a patch release that provides bug fixes. It does not include new software features.
New Software Features in Cisco NX-OS Release 5.2(1)N1(1)
Cisco NX-OS Release 5.2(1)N1(1) includes bug fixes and the following software features and enhancements:
Beginning with Cisco NX-OS Release 5.1(3)N2(1), you can configure the following devices using the XML management interface:
Cisco Nexus 5548UP Switch
Cisco Nexus 5596UP Switch
Cisco Nexus 5548P Switch
The interface uses the XML-based Network Configuration Protocol (NETCONF) that allows you to manage devices and communicate over the interface with an XML management tool or a program. The Cisco NX-OS implementation of NETCONF requires you to use a Secure Shell (SSH) session for communication with the device.
NETCONF is implemented with an XML Schema (XSD) that allows you to enclose device configuration elements within a remote procedure call (RPC) message. From within an RPC message, you select one of the NETCONF operations that matches the type of command that you want the device to execute. You can configure the entire set of CLI commands on the device with NETCONF. To download the Cisco NX-OS XML Schema Definition, go to the following URL and select one of the supported devices: http://www.cisco.com/cisco/software/navigator.html
For more information, see the
Cisco Nexus XML Interface User Guide
IPv6 Support for Additional Features
IPv6 support has been added for the following features:
IPv6 support for Neighbor Discovery (ND) or Address Resolution Protocol (ARP)
IPv6 support for Internet Control Message Protocol (ICMP)
IPv6 support for router ACLs
IPv6 support for Control Plane Policing (CoPP)
IPv6 support for QoS packet classification and marking
IPv6 support for SNMP
STATICv6 routing protocol
BGPv6 routing protocol
EIGRPv6 routing protocol
With the Precision Time Protocol (PTP) feature, IEEE 1588 is supported. PTP is a time synchronization protocol for nodes distributed across a network. Its hardware timestamp feature provides greater accuracy than other time synchronization protocols such as the Network Time Protocol (NTP).
Open Shortest Path First (OSPFv3)
You can configure the following basic and advanced Open Shortest Path First version 3 (OSPFv3) features for IPv6 networks:
Configuration Synchronization Enhancements
Configuration synchronization improvements for deleting and restoring switch profile configuration were added to the
no switch-profile name
Predefined SAN Admin User Role
The new SAN admin (san-admin) user role is a noneditable, predefined user role that provides separation between LAN and SAN administrative tasks. Users that have been assigned the SAN admin user role do not have read or write access for Ethernet features unless it is assigned to them through another user role.
You can use the
hardware profile multicast max-limit
command to set the maximum number of entries in the multicast routing table. The range is from 0 to 8000. In Cisco NX-OS Release 5.2(1)N1(1) only a max-limit of 8000 is supported.
Note A max-limit value above 4096 for this command is valid only on the N55-M160L3-V2 module and N55-D160L3-V2 daughter card.
Dynamic System Reserved VLAN Range
You can change the range of the system-reserved VLANs to any other 80 contiguous VLAN range. Reserving a range frees the range of VLANs that were allocated for internal use by default, and all of those VLANs are available for user configuration except for VLAN 4094. These commands were added:
no system vlan
show system vlan reserved
Increased Host Route Support
For the Generation 2 Layer 3 module, Cisco NX-OS 5.2(1)N1(X) will:
Increase IPv4 host routes to 16,000.
Increase IPv6 host routes to 8,000.
IGMP Snoop Limits
You can use the
hardware multicast snooping group-limit
command to configure the number of groups learned through IGMP Snooping. The range is from 100 to 8000.
Virtual Port Channel Peer Switch
The Virtual Port Channel (vPC) peer switch feature addresses performance concerns around STP convergence. This feature allows a pair of Cisco Nexus 5000 Series devices to appear as a single STP root in the Layer 2 topology. This feature eliminates the need to pin the STP root to the vPC primary switch and improves vPC convergence if the vPC primary switch fails.
To avoid loops, the vPC peer link is excluded from the STP computation. In vPC peer switch mode, STP BPDUs are sent from both vPC peer devices to avoid issues related to STP BPDU timeout on the downstream switches, which can cause traffic disruption.
This feature can be used with the pure peer switch topology in which the devices all belong to the vPC.
Object Tracking Enhancements
The object tracking feature now includes vPC support.
Fabric Path Multiple Topologies
The Cisco Nexus 5000 Series switches support two topologies: the default or base topology (topology 0) and the local VLAN topology (topology 1).
ACL Logging over Management Interface
Access-control list (ACL) logging provides hardware support for ACL logging so that the CPU is not impacted by ACL logging. ACL logging is supported for entries on the mgmt0 interface.
Python Scripting APIs
Python Application Programming Interface (API) support is available on Cisco Nexus 5000 Series switches.
POAP with Python Scripts
Python scripting is fully integrated with Power-On Auto Provisioning (POAP).
New and Changed Hardware Features
This section describes the new hardware features introduced in Cisco NX-OS Release 5.2(1)N1(x). This section includes the following topics:
The following guidelines apply to Cisco NX-OS Release 5.2(1)N1(1) for the Cisco Nexus 5000 Series switches:
If host interface (HIF) port channels or EvPCs are configured in the system and if the system was already upgraded to NX-OS Release 5.1(3)N1(1) or Release 5.1(3)N1(1a) from any release earlier than Release 5.1(3)N1(1), ensure that the system was reloaded at least once before you upgrade to Release 5.1(3)N2(1a) or Release 5.1(3)N2(1). If the switch was not previously reloaded, reload it and upgrade to Release 5.1(3)N2(1a) or Release 5.1(3)N2(1).
When a Layer 3 license is installed, the Cisco Nexus 5500 Platform does not support an ISSU. Hot swapping a Layer 3 module, for example, the Layer 3 GEM (N55-M160L3-V2) or Version 2 Layer 3 daughter card (N55-D160L3-V2), is not supported. You must power down the Cisco Nexus 5000 Series switch before removing or inserting a Layer 3 expansion module.
Supported Upgrade and Downgrade Paths
Table 5 shows the upgrade and downgrade possibilities for Cisco NX-OS Release 5.2(1)N1(7).
8.Upgrading and downgrading are both disruptive between releases 5.1(3)N2(1b) and 5.2(1)N1(2) only.
9.If HIF port channels or Enhanced vPCs (EvPC) are configured in the switch, see CSCtz42084 for additional details.
This section describes the limitations for Cisco NX-OS Release 5.2(1)N1(1).
When performing an ISSU from Cisco NX-OS Release 5.1(3)N1(1) or Cisco NX-OS Release 5.1(3)N2(1) to Cisco NX-OS Release 5.2(1)N1(1), a Forwarding Manager (FWM) core can occur which causes the system to reset. This situation occurs when network interface virtualization (NIV) is enabled. To work around this issue, use the
option in the
command to perform a disruptive upgrade. For details, see CSCty92117.
The SAN admin user role (san-admin) is a new predefined user role in Cisco NX-OS Release 5.2(1)N1(1). If you have an existing user role with the name san-admin in Cisco NX-OS Release 5.1(3)N1(1) or Cisco NX-OS Release 5.1(3)N2(1), the new system defined role is removed when you upgrade. To resolve this issue, downgrade to the previous release, rename the user role, and perform the upgrade. For details, see CSCua21425.
Bridge and STP traps are displayed in the downgrade incompatibility list when you downgrade from Cisco NX-OS Release 5.2(1)N1(1) to Cisco NX-OS Release 5.0(3)N1(1c). To resolve this issue, reset the STP/Bridge trap configuration to the default settings by entering the
no snmp-server enable traps bridge
no snmp-server enable traps stpx
command, and then the
copy running-config startup-config
command. For details, see CSCua75907.
The Server Virtualization Switch (SVS) connection is not deleted during a rollback when NIV is enabled. To resolve this issue, delete the current SVS connection and reapply the original SVS connection. For details, see CSCts17033.
If SPAN traffic is rate-limited by entering the switchport monitor rate-limit 1G command, then a maximum transmission unit (MTU) truncation size cannot be used to truncate SPAN packets. For details, see CSCua05799.
SPAN incompatibility is displayed in the downgrade incompatibility list when you perform a disruptive downgrade from Cisco NX-OS Release 5.2(1)N1(1) to Cisco NX-OS Release 4.2(1)N2(1b). See Supported Upgrade and Downgrade Paths for the recommended downgrade path. To work around this issue, remove and add the SPAN configuration. For details, see CSCtz39192.
Disruptive upgrades from Cisco NX-OS Release 4.2(1)N2(1b) to Cisco NX-OS Release 5.2(1)N1(1) are not supported and result in FC source interfaces from the SPAN sessions being removed. See Supported Upgrade and Downgrade Paths for the recommended upgrade path. For details, see CSCtz65395.
When upgrading from Cisco NX-OS Release 4.2(1)N1(1) and earlier releases to any release, the policy description is lost. This problem does not occur when upgrading from Cisco NX-OS Release 4.2(1)N1(1) and later releases. After an upgrade, we recommend that you reconfigure the policy description. For details, see CSCth14225.
Starting with Cisco NX-OS Release 4.2(1)N2(1), LACP fast timers are supported. If you downgrade to an earlier release that does not support this feature, entering the
command displays the following warning:
"Configuration not supported - Lacp fast rate is enabled",
"Use \"lacp rate normal\" on those interfaces"
Before downgrading to an earlier release, change the LACP rate to normal. If you ignore the warning and force the installation, then it is possible that the leftover LACP rate fast configuration would still be active with previous releases of software but the behavior would be unpredictable and link flap might occur. We recommend that you change the LACP rate setting to normal. For details, see CSCth93787.
When an FC SPAN destination port is changed from SD to F mode and back to SD mode on a NPV switch, the port goes into an error-disabled state. Perform a shut/no-shut after the mode change recovers the port. This issue occurs only in NPV mode. For details, see CSCtf87701.
If you configure a Cisco Nexus 2248TP port to 100 Mbps instead of autonegotiation, then autonegotiation does not occur, which is the expected behavior. Both sides of the link should be configured to both hardwired speed or both autonegotiate.
—Autonegotiates and advertises all speeds (only full duplex).
—Autonegotiates only for a 802.3x pause.
—Does not autonegotiate; pause cannot be advertised. The peer must be set to not autonegotiate and fix at 100 Mbps (similar to the N2248TP)
For details, see CSCte81998.
Given the implementation of a single CPU ISSU, the STP root on the PVST region with switches on an MST region is not supported. The PVST simulation on the boundary ports go into a PVST SIM inconsistent blocked state that breaks the STP active path. To work around this issue, move all STP roots to the MST region. However, the workaround causes a nondisruptive ISSU to fail because non-edge designated forwarding ports are not allowed for an ISSU. For additional information, see CSCtf51577. For information topologies that a nondisruptive upgrade is supported, see to the
Cisco Nexus 5000 Series NX-OS Upgrade and Downgrade Guide
IGMP queries sent in CSCtf94558 are group-specific queries that are sent with the destination IP/MAC address as the group's address.
GS queries are sent for IP address: 220.127.116.11 to 18.104.22.168 [0100.5E01.0E01 to 0100.5E01.0E64]
These are not link-local addresses. By default, they are not flooded by the hardware into the VLAN. They are sent only to the ports that have joined this group.
This is expected behavior during an ISSU.
In another scenario, the IGMP global queries [dest IP 22.214.171.124] get flooded correctly in the VLAN.
Group-specific queries are not forwarded to ports other than the one that joined the group during ISSU. The reason to forward group-specific queries toward hosts is to avoid having them leave the group. However, if a port has not joined the group, then this is not an issue. If there is an interface that has joined the group, then the queries are expected to make it to the host. While the behavior is different when ISSU is not occurring, it is sufficient and works as expected and there is no impact to traffic. For details, see CSCtf94558.
The meaning of an MTU configuration has changed in Cisco NX-OS Release 4.2(1)N1(1) and earlier releases. In releases earlier than Cisco NX-OS Release 4.2(1)N1(1), the configured MTU included the Ethernet payload and Ethernet headers. In Cisco NX-OS Release 4.2(1)N1(1), the configured MTU includes only the Ethernet payload and not the Ethernet headers. When upgrading or downgrading between Cisco NX-OS Release 4.2(1)N1(1) and earlier releases, Cisco NX-OS automatically converts the configuration to address this semantic change by adding or subtracting 38 to the MTU to address the Ethernet header size.
In a vPC configuration, the MTU per class needs to be consistent on both switches in the vPC domain for the vPC peer link to come up. When upgrading/downgrading a working vPC setup between pre-4.2(1)N1(1) and 4.2(1)N1(1) releases, the MTU is adjusted to make sure that the MCT peer-link always comes up.
However if you add a peer-link between two switches in a vPC domain that are identically configured (MTU in particular) with one switch running Cisco NX-OS Release 4.2(1)N1(1) and another switch running an earlier release, then the vPC peer link does not come up because the MTU is inconsistent between the two switches.
This is not an issue when upgrading or downgrading peer switches in a vPC domain; this is only an issue when adding a peer link between two switches running Cisco NX-OS Release 4.2(1)N1(1) and earlier releases that were not previously in the same vPC domain.
To resolve this issue, upgrade or downgrade one switch to match the version on the other switch and reconfigure the MTU to be consistent on both sides. For details, see CSCtg27538.
The channel-group configuration is not applied to the Cisco Nexus 2000 Series downlink interface after downgrading to the Cisco NX-OS Release 4.1(3)N1(1) software. This issue occurs if the
command is present under the context of the port channel. To work around this issue, reconfigure the channel-group command after the system comes up and reapply the configuration from the saved configuration in the bootflash. For details, see CSCtc06276.
When a private VLAN port is configured as a TX (egress) SPAN source, the traffic seen at the SPAN destination port is marked with the VLAN of the ingressed frame. There is no workaround.
In large-scale configurations, some Cisco Nexus 2000 Series Fabric Extenders might take up to 3 minutes to appear online after entering the
command. A configuration can be termed large scale when the maximum permissible Cisco Nexus 2000 Series Fabric Extenders are connected to a Cisco Nexus 5000 Series switch, and all host-facing ports are connected and each host-facing interface has a large configuration (that supports the maximum permissible ACEs per interface).
Egress scheduling is not supported across the drop/no-drop class. Each Fabric Extender host port does not support simultaneous drop and no drop traffic. Each Fabric Extender host port can support drop or no drop traffic.
The Cisco Nexus 2148 Fabric Extender does not support frames with the dot1q vlan 0 tag.
VACLs of more than one type on a single VLAN are unsupported. Cisco NX-OS software supports only a single type of VACL (either MAC, IPv4, or IPv6) applied on a VLAN. When a VACL is applied to a VLAN, it replaces the existing VACL if the new VACL is a different type. For instance, if a MAC VACL is configured on a VLAN and then an IPv6 VACL is configured on the same VLAN, the IPv6 VACL is applied and the MAC VACL is removed.
A MAC ACL is applied only on non-IP packets. Even if there is a
match eth type = ipv4
statement in the MAC ACL, it does not match an IP packet. To avoid this situation, use IP ACLs to apply access control to the IP traffic instead of using a MAC ACL that matches the EtherType to IPv4 or IPv6.
statements in the configuration are not supported.
If you remove an expansion module with Fibre Channel ports, and the cable is still attached, the following FCP_ERRFCP_PORT errors are displayed:
These messages are informational only, and result in no loss of functionality.
If you configure Multiple Spanning Tree (MST) on a Cisco Nexus 5000 Series switch, we do not recommend that you partition the network into a large number of regions.
A downgrade from Cisco NX-OS Release 5.1(3)N1(1) to any 5.0(3)N1(x) image can cause the Cisco Nexus 5000 Series switch to fail. For details, see CSCty92945.
If you upgrade a vPC peer switch from Cisco NX-OS Release 5.0(3)N2(1) to Cisco NX-OS Release 5.1(3)N2(1) or Cisco NX-OS Release 5.2(1)N1(1), and feature-set FabricPath is enabled on the upgraded switch, the vPC Peer-Link enters STP Bridge Assurance Inconsistency which affects all VLANs except VLAN 1 and affects traffic forwarding for vPC ports.
To avoid this issue, upgrade the peer switch that is running Cisco NX-OS Release 5.0(3)N2(1) switch also to Cisco NX-OS Release 5.1(3)N2(1) or higher and then enable feature-set FabricPath on the switch or switches. If you accidentally enable feature-set FabricPath in Cisco NX-OS Release 5.1(3)N2(1) when the peer vPC switch is running Cisco NX-OS Release 5.0(3)N2(1), disable the feature-set FabricPath and the vPC will resume STP forwarding state for all VLANs.
By design, vEth interfaces do not share the underlying behavior of a vPC port. As a result, a VLAN does not get suspended when the peer switch suspends it. For example, when you shut a VLAN on a primary switch, the VLAN continues to be up on the secondary switch when the vEth interface is on a FEX. When the VLAN on the primary switch goes down, the VLAN on the vEth interface on the primary is suspended, but the vEth on the secondary switch is up as it is an active VLAN on the secondary switch.
RBACL policy enforcement is performed on VLANs on which CTS enforcement is not configured. This situation occurs when there is at least one VLAN in the switch where CTS is enforced. On a VLAN where CTS is not enforced, RBACL policy lookup occurs for ingress packets and the packet is denied or permitted according to the policies in the system. To work around this issue, make sure that all VLANs on which SGT tagged packets ingress enforce CTS.
The packet length in the IP GRE header of a packet exiting from the switch is not equal to the MTU value configured in the ERSPAN source session. This is true for SPAN or ERSPAN. This situation can occur whenever the MTU value that is configured in an ERSPAN or SPAN session is smaller than the SPAN packet, such as when the packet is truncated. The IP GRE packet is truncated to a value that differs by -2 to 10 bytes from the expected MTU.
When you configure a Layer 3 interface as an ERSPAN source, and configure the ERSPAN termination on a Catalyst 6000 switch or a Cisco Nexus 7000 Series switch, you cannot terminate the Layer 3 interface ERSPAN source on the Cisco Nexus 7000 Series switch or the Catalyst 6000 switch. To work around this issue, configure VLAN 1 to 512 on the Cisco Nexus 7000 Series switch or the Catalyst 6000 switch.
Unknown Unicast packets in FabricPath ports are counted as Multicast packets in interface counters. This issue occurs when unknown Unicast packets are sent and received with a reserved Multicast address (that floods to a VLAN) in the outer FabricPath header, and the Cisco Nexus 5000 Series switch increments the interface counter based on the outer FabricPath header. As a result, multicast counters are incremented. In the case of a Cisco Nexus 7000 Series switch, Unicast counters are incremented as they are based on an inner Ethernet header. There is no workaround for this issue.
If you configure a speed of 1 G on a base or GEM port and then check for compatibility with a Cisco NX-OS Release 5.0(2) image, no incompatibility is shown. However, because 1 G was not supported in the Cisco NX-OS Release 5.0(2), an incompatibility should be shown. To work around this issue, manually remove the 1 G configuration from the ports before downgrading to Cisco NX-OS Release 5.0(2) or an earlier release.
In an emulated switch setup, inband keepalive does not work. The following steps are recommended for peer keepalive over SVI when a switch is in FabricPath mode:
– Use a dedicated front panel port as a vPC+ keepalive. The port should be in CE mode.
– Use a dedicated VLAN to carry the keepalive interface. The VLAN should be CE VLAN.
– Add the management keyword to the corresponding SVI so that the failure of a Layer 3 module will not bring down the SVI interface.
– Enter the
dual-active exclude interface-vlan
command to prevent the SVI from going down on the secondary when a peer-link goes down.
Fabricpath requires 802.1q tagging of inner Ethernet header of the packet. Native VLAN packets that are sent by a Cisco Nexus 7000 Series switch are not tagged. As a result, a Cisco Nexus 5000 Series switch drops packets due to packet parsing errors. To work around this issue, enable
vlan dot1q tag native
on the Cisco Nexus 7000 Series switch to force 802.1q tagging of native VLAN packets.
SPAN traffic is rate-limited on Cisco Nexus 5500 Series switches platforms to prevent impact to production traffic:
– SPAN is rate-limited to 5 Gbps per ASIC (every 8 ports share one ASIC).
– SPAN is rate-limited to 0.71 Gbps per monitor source port when the RX traffic on the port exceeds 5 Gbps.
For details, see CSCti94902.
Cisco Nexus 5548UP and Cisco Nexus 5598UP switches with a Fibre Channel connection to HP Virtual Connect modules experience link destabilization and packet loss when the speed is set to 8 GB. To work around this issue for the HP VC FlexFabric 10-Gbps 24-port module, upgrade to VC-FF 3.70 or higher firmware. To work around this issue for the HP VC 8-Gbps 24-port Fibre Channel module, upgrade to VC-FC2 1.04 or higher. In the autonegotiation mode, the speed will drop to 4 Gb. The workaround is to manually set the speed to higher than 4 GB. For the HP VC 8-Gbps 20-port Fibre Channel module, leave the speed at 4 GB. For details, see CSCtx52991.
Limitations on the Cisco Nexus 5010 and Cisco Nexus 5020
The limitations on the Cisco Nexus 5010 switch and the Cisco Nexus 5020 switch are as follows:
Traffic going out the Ethernet SPAN destination is always tagged. The SPAN destination can be in the access or trunk mode and frames on the SPAN source port can be tagged or untagged. Frames are always tagged internally as they travel through the system. Information about whether the frame was originally tagged or untagged, as it appeared in the SPAN source, is not preserved in the SPAN destination. The spanned traffic exiting the SPAN destination port always has the VLAN tag on it. The correct VLAN tag is applied on the frame as it goes out the SPAN destination. The only exception is if frames ingress on a SPAN source port on an invalid VLAN. In this case,
is applied on a spanned frame.
Spanned FCoE frames do not preserve original SMAC and DMAC fields. The Ethernet header gets modified as the frame is spanned to the destination. The modified header fields are displayed when monitored on the SPAN destination.
The CoS value in spanned FCoE frames on the Ethernet SPAN destination port does not match with the CoS value in the SPAN FCoE source frame. The CoS value on the captured SPAN FCoE frame should be ignored.
The class-fcoe cannot be removed even if Fibre Channel is not enabled on a switch.
If a port drains traffic at a rate less than 100 Kbps, it is error-disabled in 10 seconds to avoid buffer exhaustion. However, if the drain rate is larger than 100 Kbps, the port might not be consistently error-disabled within 10 seconds which exhaust ingress buffers and discard frames. Use the
command to disable the slow-draining port.
The multicast storm control functionality in the Cisco Nexus 5000 Series does not distinguish between IP, non-IP, registered, or unregistered multicast traffic. All multicast traffic is subject to a single-multicast storm control policer when configured.
IGMP Snooping Limitation
On the Cisco Nexus 5010 switch and the Cisco Nexus 5020 switch with a Cisco Nexus 2000 Series Fabric Extender (FEX) installed, unregistered IP multicast packets on one VLAN are forwarded to other VLANs where IGMP snooping is disabled. We recommend that you do not disable IGMP snooping on the Cisco Nexus 5010 switch and the Cisco Nexus 5020 switch. A static IGMP join can be configured for devices intended to receive IP multicast traffic but not to send IGMP join requests. This limitation applies to the Cisco Nexus 5010 switch and the Cisco Nexus 5020 switch only.
Beginning with NX-OS release 5.2(1)N1(5), IGMP general queries received on FEX interfaces are dropped thereby preventing a FEX interface from becoming an mrouter port.
SPAN Limitations on Fabric Extender Ports
The SPAN limitations on Fabric Extender ports are as follows:
On a Cisco Nexus 5000 Series switch, if the SPAN source is a FEX port, the frames will always be tagged when leaving the SPAN destination.
On a Cisco Nexus 5010 switch or a Nexus 5020 switch, if the SPAN source is an access port on a switch port or FEX port, the spanned frames at the SPAN destination will be tagged.
On a Cisco Nexus 5500 Platform switch, if the SPAN source is on an access port on the switch port, the frames will not be tagged when leaving the SPAN destination.
Ports on a FEX can be configured as a tx-source in one session only.
If two ports on the same FEX are enabled to be tx-source, the ports need to be in the same session. If you configure a FEX port as a tx-source and another port belonging to the same FEX is already configured as a tx-source on a different SPAN session, an error is displayed on the CLI.
In the following example, Interface Ethernet100/1/1 on a FEX 100 is already configured as a tx-source on SPAN session-1:
swor28(config-monitor)# show running-config monitor
monitor session 1
source interface Ethernet100/1/1 tx
destination interface Ethernet1/37
If you add an interface Ethernet100/1/2 as a tx-source to a different SPAN session (session-2) the the following error is displayed:
ERROR: Eth100/1/2: Ports on a fex can be tx source in one session only
When a FEX port is configured as a tx-source, the multicast traffic on all VLANs for which the tx-source port is a member, is spanned. The FEX port sends out only multicast packets that are not filtered by IGMP snooping. For example, if FEX ports 100/1/1-12 are configured on VLAN 11 and the switch port 1/5 sends multicast traffic on VLAN 11 in a multicast group, and hosts connected to FEX ports 100/1/3-12 are interested in receiving that multicast traffic (through IGMP), then that multicast traffic goes out on FEX ports 100/1/3-12, but not on 100/1/1-2.
If you configure SPAN Tx on port 100/1/1, although the multicast traffic does not egress out of port 100/1/1, the SPAN destination does receive that multicast traffic, which is due to a design limitation.
When a FEX port is configured as both SPAN rx-source and tx-source, the broadcast, non-IGMP Layer-2 multicast, and unknown unicast frames originating from that port might be seen twice on the SPAN destination, once on the ingress and once on the egress path. On the egress path, the frames are filtered by the FEX to prevent them from going out on the same port on which they were received. For example, if FEX port 100/1/1 is configured on VLAN 11 and is also configured as SPAN rx-source and tx-source and a broadcast frame is received on that port, the SPAN destination recognizes two copies of the frame, even though the frame is not sent back on port 100/1/1.
A FEX port cannot be configured as a SPAN destination. Only a switch port can be configured and used as a SPAN destination.
Cisco NX-OS Release 5.1(3)N2(1) does not support SPAN on a VM FEX.
Checkpoint and Configuration Rollback Limitation
When FCoE is enabled, the checkpoint and configuration rollback functionality is disabled.
Upgrading and Downgrading Limitations
When upgrading and downgrading between Release 5.1(3)N2(1), Release 5.2(1)N1(1), and Release 5.2(1)N1(1a), you might see the following issues in switch profile mode:
command configuration issues
If you previously used the
switchport access vlan
switchport trunk allowed vlan
command, or the
switchport trunk native vlan
command to configure the switch profile mode, the configurations you created are not visible.
Note This problem is a configuration display issue only, and there is no traffic disruption.
Table 6 lists the situations where you might experience
command configuration issues and the workarounds.
Table 6 Switchport Command Configuration Upgrade and Downgrade Issues
Upgrade from 5.1(3)N2(1) to 5.2(1)N1(1)
Perform the following tasks for all port channels where the configurations you created using the
commands are missing from the switch profile mode.
1. Enter the following commands from the switch profile mode:
When in switch profile mode, the following commands are not visible:
Table 7 lists the situations where you might experience
command issues and the workarounds.
Table 7 Fex Associate Command Upgrade and Downgrade Issues
Upgrade from 5.1(3)N2(1) to 5.2(1)N1(1)
In Release 5.1(3)N2(1), the
command is rarely entered in configuration synchronization mode.
If you plan to enter the
command from the configuration synchronization mode, you must remove the command from the config-sync switch profile mode, and add the command from the configure terminal mode before you upgrade.
command before the upgrade, you must import the command manually.
Downgrade from 5.2(1)N1(1) to 5.1(3)N2(1)
If you plan to enter the
command from the configuration synchronization mode, you must remove the command from the config-sync switch profile mode, and add the command from the configure terminal mode before you downgrade.
command before the downgrade, you must import the command manually.
Upgrade from 5.1(3)N2(1) to 5.2(1)N1(1a)
Same as upgrade from 5.1(3)N2(1) to 5.2(1)N1(1).
Downgrade from 5.2(1)N1(1a) to 5.1(3)N2(1)
Same as downgrade from 5.2(1)N1(1) to 5.1(3)N2(1).
Upgrade from 5.2(1)N1(1) to 5.2(1)N1(1a)
Downgrade from 5.2(1)N1(1a) to 5.2(1)N1(1)
Upgrade from 5.2(1)N1(3) to 5.2(1)N1(4)
Upgrade from 5.2(1)N1(4) to 5.2(1)N1(5)
Layer 3 Limitations
In a vPC topology, two Cisco Nexus 5000 switches configured as vPC peer switches need to be configured symmetrically for Layer 3 configurations such as SVIs, Peer Gateway, routing protocol and policies, and RACLs.
Note vPC consistency check does not include Layer 3 parameters.
When a Layer 3 module goes offline, all non-management SVIs are shut down. An SVI can be configured as a management SVI using the
command and configuring
. This configuration allows traffic to the management SVIs to not go through the Layer 3 module which maintains connectivity in case of a Layer 3 module failure.
Upgrading and Downgrading
When a Layer 3 license is installed, the Cisco Nexus 5500 platform does not support an ISSU. Layer 3 module hot swaps are not supported.
Cisco Nexus 5548P Daughter Card (N55-D160L3)
Before installing a Layer 3 daughter card (N55-D160L3) into a Cisco Nexus 5548P switch, you must upgrade to Cisco NX-OS Release NX-OS Release 5.0(3)N1(1c) or a later release, and then install the card into the chassis.
This section includes the open and resolved caveat record numbers for this release. Links are provided to the Bug Toolkit where you can find details about each caveat.
When a multicast source is connected to only one Cisco Nexus 5000 in a vPC pair, and a multicast bind-vrf is configured, the non-source-connected Nexus 5000 will not create an mroute for the group in question, and will drop all traffic for this group coming across the vPC peer-link due to RPF.
After a change in the spanning-tree (for example, the port moves from forward to blocking), IGMP packets may still be flooded on a blocking interface for some time. This causes IGMP traffic to loop on the network.
With auto-recovery configured on a pair of Cisco Nexus 5000 Series switches in a vPC pair, the traffic coming from the peer link might get dropped if the secondary switch is reloaded with the peer-keepalive link disconnected and then restored after bootup.
ISSU on the Cisco Nexus 5000 Series switch can fail if the logging level on any process is above 5 during the code upgrade. Running ISSU impact pre-install checks still indicates a non-disruptive upgrade.
When trying to write its configuration to the 'ascii-cfg' process after a 'show run' is issued, the vPC process still writes even if it is in a low memory situation and a MALLOCFAIL error occurs. Writing to a null pointer triggers a crash.
Nexus 5000 FabricPath ISIS metric doesn't change when Portchannel member is down. FabricPath ISIS should compute the metric based on ACTIVE members of the portchannel. But on Nexus 5000, FabricPath ISIS should compute the metric based on configured members. The behavior is inherent in the design and is inconsistent with Nexus 7000.
The Cisco Nexus 5000 Series switches in config-sync mode, leak memory in the port-profile manager (ppm) structure when successive adding and removing port-channels were performed, also periodically collecting "show running-config".The switch eventually crashes with messages in the syslog.
DHCP Relay agent sends DHCPACK messages to destination ip address 0.0.0.0. Although current behavior complies to rfc 2131, some OS systems are not setting 'yiaddr', while DHCP relay agent SHOULD set an IP unicast of DHCPACK to the IP address specified in the 'yiaddr' field.
Ipqosmgr crashed when doing a "show tech" on the HSRP active switch when it perform the command 'show policy-map interface brief' when service-policy type qos input marking_VoIP is configured on VLAN interface.
After reboot downstream Po moves to forwarding while VPC is down. After a reload, VPC Port-channel toward downstream switches can go into forwarding state while VPC is still down, potentially causing packet loss.
In a Cisco Nexus 5500 Series switch with layer 3 modules running a NX-OS 5.2 Release, multicast traffic received over vPC bind-vrf VLAN might not get routed to receivers hanging off layer 3 interfaces.
On a Version 2 Layer 3 daughter card (N55-D160L3-V2), when the maximum number of entries in the multicast routing table is greater than 4096, the multicast route programming can exceed the configured hardware limit and impact the allocated space for unicast host routes.
When a new member port from a new ASIC is added to a SAN port channel or the last member from any ASIC of a SAN port channel is flapped, the ingress FC frames are dropped at that member port due to the layer 3 logical interface (LIF) VLAN membership check failure.
What’s New in Cisco Product Documentation
, which lists all new and revised Cisco technical documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The RSS feeds are a free service.
Obtaining Documentation and Submitting a Service Request
What’s New in Cisco Product Documentation
, which lists all new and revised Cisco technical documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The RSS feeds are a free service.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks
. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)