Cisco Nexus 5500 Series Release Notes,
Release Date: January 31, 2013
Part Number: OL-27874-07 A2
Date Last Modified: April 15, 2014
Current Release: NX-OS Release 6.0(2)N2(4)
This document describes the features, caveats, and limitations for the Cisco Nexus 5500 devices and the Cisco Nexus 2000 Series Fabric Extenders. Use this document in combination with documents listed in the “Related Documentation” section.
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 5500 Series device and the Cisco Nexus 2000 Series Fabric Extender (FEX) to improve the performance, scalability, and management of the product line. Cisco NX-OS Release 6.0 also supports all hardware and software supported in Cisco NX-OS Release 5.1, Cisco NX-OS Release 5.0.
Cisco Nexus Devices
The Cisco Nexus devices 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 devices for data center applications.
For information about the Cisco Nexus 5500 Series, see the
Cisco Nexus 5500 Series 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 5500 Series devices 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 device, which allows zero-touch provisioning and automatic configuration. The FEX provides a single point of management that supports a large number of servers and hosts that can be configured with the same feature set as the parent Cisco Nexus 5500 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 5500 Series Layer 2 Switching Configuration Guide
The Cisco NX-OS software supports the Cisco Nexus devices. Starting with Cisco NX-OS Release 6.0(2)N1(2), the Cisco Nexus 5010 and 5020 switches are not supported. You can find detailed information about supported hardware in the
Cisco Nexus 5500 Series Hardware Installation Guide
Table 2 shows the hardware supported by Cisco NX-OS Release 6.0(x) software.
Table 2 Hardware Supported by Cisco NX-OS Release 6.0(x) Software
Bidirectional Forwarding Detection (BFD) is a detection protocol designed to provide fast forwarding-path failure detection times for media types, encapsulations, topologies, and routing protocols. Starting with Release 6.0(2)N2(1), the Cisco Nexus 5500 supports BFD for BGP, EIGRP, OSPF, PIM, HSRP, VRRP, and static routes.
Command Update: show lldp system -detail
command now includes an optional keyword for displaying system details.
You can use the
command to clear the existing configuration of multiple interfaces and return them to default settings. The command can be used for interfaces such as Ethernet, loopback, VLAN network, port-channel, and tunnel interfaces. You can use the
keyword with the command to create a copy of the interface configuration before clearing it so that you can restore it later.
Embedded Event Manager Support
The Embedded Event Manager (EEM) monitors events that occur on your device and takes action to recover from or troubleshoot these events, based on your configuration. You can use EEM to create policies that consist of a set of actions to be taken in response to a specific event. EEM can be controlled through CLI commands or Vsh scripts.
Network Time Protocol Server
A Cisco Nexus 5500 switch can use the Network Time Protocol (NTP) to synchronize the network. Other devices can be configured to use the switch as an NTP time server. In an isolated network, the switch can be configured as an authoritative NTP clock source.
An NTP server usually receives its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server, and then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two devices to within a millisecond of each other.
Policy Based Routing
The Cisco Nexus 5500 now supports policy-based routing (PBR). PBR allows you to configure a defined policy for IPv4 and IPv6 traffic flows, lessening reliance on routes derived from routing protocols.
DHCPv4-relay and DHCPv6-relay
Up to 32 DHCP server addresses can now be configured on an interface. Previously, the maximum number of configurable server addresses was 16.
FEX Host Interface Storm Control
HIF Storm control allows ingress traffic suppression for unknown multicast, broadcast, and unknown unicast traffic on Fabric Extender (FEX) Host Interface (HIF) ports and port channels.
As documented in the release specific Verified Scalability for Cisco Nexus 5500 Series
documents, configuration limits (verified scalability) for several Layer 2 switching functions has increased. Verified and maximum limits have changed for some features, including:
IGMP Snooping groups
Logical interfaces (PVs)
Number of FEX ports
Number of switchports
SNMP Bridge-MIB and LLDP MIB
SNMP Bridge and LLDP MIBs have been published.
You can use the vPC
command to isolate a switch from the vPC complex. The switch can then be debugged, reloaded, or removed physically, without affecting the vPC traffic going through the nonisolated switch.
vPC+ Routing Protocol Peering
Added support for routing unicast and multicast protocol over vPC+.
New Software Features in Cisco NX-OS Release 6.0(2)N1(2)
Cisco NX-OS Release 6.0(2)N1(2) is a maintenance release that includes bug fixes and the following software features and enhancements:
Support added for the IEEE 802.1X, which provides a client-server-based access control and authentication protocol that restricts unauthorized devices from connecting to a LAN through publicly accessible ports. The authentication server authenticates each client connected to a switch port before making available any services offered by the switch or the LAN.
FEX NIF Storm Control
The NIF Storm Control feature allows configuration on a Satellite Fabric port to all the pinned FEX HIF ports regardless of whether it is a logical or a physical HIF. In addition, a new syslog message informs the user when a switch port that has a Storm Control configuration is starting to see a storm of broadcast, multicast, or unicast when it starts dropping packets. You see another syslog message when the storm stops.
You can use an IP-directed broadcast to send a broadcast from a device that is not directly connected to the destination IP subnet. An ACL name can be specified for the broadcast. (This resolves caveat CSCuh1963.)
iSCSI TLV Configuration
As documented in the Cisco Nexus 5500 Series NX-OS SAN Switching Configuration Guide, Release 6.x, NICs and converged network adapters connected to a Cisco Nexus 5500 Series switch can use iSCSI as a storage protocol and can be programmed to accept the configuration values sent by the switch leveraging data center bridging exchange protocol (DCBX). DCBX negotiates configuration and settings between the switch and the adapter through a variety of type-length-values (TLV) and sub-TLVs. This process allows the switch to distribute configuration values to all attached adapters from a centralized location instead of having to manually program CoS markings on each individual server and adapter.
Port Channel Minimum Links
Added support to configure a minimum number of links for the port channel so that when a certain number of port-channel member ports go down, the host-facing interfaces are suspended.
New Software Features in Cisco NX-OS Release 6.0(2)N1(1)
Cisco NX-OS Release 6.0(2)N1(1) includes bug fixes and the following software features and enhancements:
Policing allows you to monitor the data rates for a particular class of traffic. When the data rate exceeds user-configured values, the switch drops packets immediately. Because policing does not buffer the traffic, transmission delays are not affected. When traffic exceeds the data rate, you instruct the system to drop the packets. You can define single-rate and two-color ingress policing.
When forwarding an incoming IP packet in a line card, if the Address Resolution Protocol (ARP) request for the next hop is not resolved, the line card forwards the packets to the supervisor, referred to as glean throttling. The supervisor resolves the MAC address for the next hop and programs the hardware.
The Cisco Nexus 5500 Series device hardware has glean rate limiters to protect the supervisor from the glean traffic. If the maximum number of entries is exceeded, the packets for which the ARP request is not resolved continues to be processed in the software instead of getting dropped in the hardware.
When an ARP request is sent, the software adds a /32 drop adjacency in the hardware to prevent the packets to the same next-hop IP address from being forwarded to the supervisor. When the ARP entry is resolved, the hardware entry is updated with the correct MAC address. If the ARP entry is not resolved before a timeout period, the entry is removed from the hardware.
The ACL logging feature allows the logging of packets that hit the IPv4 ACLs. The log messages are displayed on a flow basis. The flow is identified using a combination of the IP source address, destination address, L4 protocol, and the L4 source/destination ports on an interface. The log message is generated under the following conditions:
INFO message—When a new flow is created
WARNING message—When the packet threshold is reached for a flow
Configurable INFO message—At the end of a periodic interval containing information on the number of packets to hit the flow. The interval default is 5 minutes.
Note When the number of flows exceed a threshold in the given interval, a warning message is logged, and that flow is not added to the logging cache.
POAP enhancements include hostname- and MAC address-based configuration file selection, TCL or Python script logging, and a remote syslog facility.
BGP enhancements include BGP Allow-AS-in, local-AS, prefix-peering, AS-path relax, and remove-private-AS.
VRF Route Leaking
Support for VRF route leaking enables the sharing of routes that were previously visible and available only in segmented networks.
FCoE over 10GBASE-T
FCoE configuration is supported over 10GBASE-T using Cat6a and Cat7 cables up to a distance of 30 m.
New Hardware Features in Cisco NX-OS Release 6.0(2)N2(1b)
Cisco NX-OS Release 6.0(2)N2(1b) supports the following new hardware:
N2K-B22IBM-P—Cisco Nexus B22 Fabric Extender for IBM
New Hardware Features in Cisco NX-OS Release 6.0(2)N2(1)
No new hardware features have been introduced with this release.
New Hardware Features in Cisco NX-OS Release 6.0(2)N1(2)
Cisco NX-OS Release 6.0(2)N1(2) supports the following new hardware:
4-port QSFP+ Nexus N55-M4Q GEM
New power supplies for Cisco Nexus 5596T and Cisco Nexus 5596UP switches:
– Cisco Nexus 1100 W AC front-to-back power supply (PID: NXA-PAC-1100W)
– Cisco Nexus 1100 W AC back-to-front power supply (PID: NXA-PAC-1100W-B)
– Cisco Nexus 1100 W DC front-to-back power supply (PID: N55-PDC-1100W)
New Hardware Features in Cisco NX-OS Release 6.0(2)N1(1)
Cisco NX-OS Release 6.0(2)N1(1) supports the following new hardware:
Cisco Nexus 2248PQ 10-Gigabit FEX
Upgrading or Downgrading to a New Release
This section describes the upgrade and downgrade paths that are supported for Cisco NX-OS Release 6.0(2)N2(2) on the Cisco Nexus device.
The following guidelines apply to Cisco NX-OS Release 6.0(2)N2(2) for Cisco Nexus devices:
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 device 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 6.0(2)N2(3). For more information, see the Cisco Nexus 5500 Series NX-OS Software Upgrade and Downgrade Guide, Release 6.0.
Nondisruptive upgrade (ISSU) via 5.2(1)N1(1) or 5.1(3)N2(1)
Disruptive upgrade (ISSU)
Nondisruptive upgrade (ISSU) via 5.2(1)N1(1) or 5.1(3)N2(1)
30.Upgrading and downgrading are both disruptive between Releases 5.1(3)N2(1b) and 5.2(1)N1(2) only.
31.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 6.0(2)N1(2).
Ingress inter-VLAN-routed Layer3 multicast packets are treated as “unknown multicast” by the storm-control feature. This is due to the Layer 3 forwarding design in the Cisco Nexus 5500 Series switch. For details, see CSCuh34068.
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.
When an FC SPAN destination port is changed from SD to F mode and back to SD mode on an 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 an 802.3x pause.
—Does not autonegotiate; pause cannot be advertised. The peer must be set to not autonegotiate and to 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 goes 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 nonedge designated forwarding ports are not allowed for an ISSU. For additional information, see CSCtf51577. For information about topologies that support a nondisruptive upgrade, see the
Cisco Nexus 5500 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: 22.214.171.124 to 126.96.36.199 [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 188.8.131.52] 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, 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 the traffic. For details, see CSCtf94558.
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 device, 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 appear:
These messages are informational only and result in no loss of functionality.
If you configure Multiple Spanning Tree (MST) on a Cisco Nexus device, we recommend that you avoid partitioning 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 device 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) to Cisco NX-OS Release 5.1(3)N2(1) or later release 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 the 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 because it is an active VLAN on the secondary switch.
Rol-based Access Control List (RBACL) policy enforcement is performed on VLANs on which Cisco Trusted Security (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 5500 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 5500 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 device 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 switch virtual interface (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 a CE VLAN.
– Add the
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 the 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 device drops packets due to packet parsing errors. To work around this issue, enter the
vlan dot1q tag native
command 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 devices 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 devices 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, leave the speed set to 4 GB. For details, see CSCtx52991.
A nondisruptive ISSU is not supported when ingress policing is configured.
The maximum IP MTU that can be set on Layer 3 interfaces on which Layer 3 protocols are running is 9196, because of the internal header used inside the switch. The network-qos policy must be set to 9216.
Limitations on the Cisco Nexus Device
The limitations on the Cisco Nexus device 5500 Series devices are as follows:
The SPAN limitations on Fabric Extender ports are as follows:
On a Cisco Nexus device, if the SPAN source is a FEX port, the frames will always be tagged when leaving the SPAN destination.
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 following error appears:
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), 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.
Note Each affected switchport command configuration must be entered separately. The example uses the switchport trunk allowed vlan command.
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.
Note If you did not add the fex associate 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.
Note If you did not add the fex associate 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)
Layer 3 Limitations
In a vPC topology, two Cisco Nexus devices configured as vPC peer switches need to be configured symmetrically for Layer 3 configurations such as SVIs, the peer gateway, routing protocol and policies, and RACLs.
Note The 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 by entering 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.
If eBGP adjacency is formed through the
command instead of the
command for eBGP peers that are not directly connected, creating a new Layer 3 interface bounces the eBGP session.
In a Cisco Nexus 5000 Series switch, the IGMP Optimized Multicast Flood (OMF) feature is enabled by default, but the output of the show ip igmp snooping vlan command shows the feature as disabled for the VLAN.
Receive error messages that repeat every 10 minutes. If you see the message for any other time interval or just one time, then it is not this bug. These messages do not affect the operation of the switch. It just does not allow the switch to get the power/input/voltage characteristics of the SFP on a port to show in the “show interface x/y transceiver details” output and you will see an error of “unknown error” at the end of the transceiver details output.
In Cisco NX-OS Release 6.0(2)N1(1), the ethanalyzer detail output prints internal Nexus 5000 Series protocol headers. If ethanalyzer output is written as a .pcap file, Wireshark cannot open this .pcap file because it does not understand the headers.
Resolved Caveats in Cisco NX-OS Release 6.0(2)N1(1)
Table 15 lists the caveats that are resolved in Cisco NX-OS Release 6.0(2)N1(1). The caveats might be open in previous Cisco NX-OS releases.
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.
With auto-recovery configured on a pair of Cisco Nexus devices 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.
The Cisco Management Information Base (MIB) list includes Cisco proprietary MIBs and many other Internet Engineering Task Force (IETF) standard MIBs. These standard MIBs are defined in Requests for Comments (RFCs). To find specific MIB information, you must examine the Cisco proprietary MIB structure and related IETF-standard MIBs supported by the Cisco Nexus 5500 Series switch.
The MIB Support List is available at the following FTP site:
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)