Table of Contents
This document describes the features, caveats, and limitations for Cisco NX-OS software for use on the Cisco Nexus 7000 Series. Use this document in combination with documents listed in the “Related Documentation” section.
Note Release notes are sometimes updated with new information about restrictions and caveats. See the following website for the most recent version of the Cisco Nexus 7000 Series NX-OS Release Notes, Release 6.x:
Table 1 shows the online change history for this document.
- Added CSCuh18007to the “Open Caveats—Cisco NX-OS Release 6.2” section.
- Added the “ECMP Support in Hardware” limitation.
- Added the “CLI Command for Breakout Capabilities” limitation.
- Added a caveat about FEX queuing to the “Upgrade or Downgrade Caveats” section.
- Added IPv6 Inter-AS Option B lite as a supported MPLS feature.
- Added CSCug37851 to the “Resolved Caveats—Cisco NX-OS Release 6.2(2)” section.
- Added CSCui13170 to the “Open Caveats—Cisco NX-OS Release 6.2” section.
- Updated the supported FEX modules for the N77-F248XP-23E I/O module in Table 3 .
- Added vPC and vPC+ to the “New Software Features” section.
- Updated OTV in the “New Software Features” section.
- Modified the description of the “Behavior of Control Plane Packets on an F2e Series Module” limitation.
- Added the “WCCP Support in a Mixed Mode VDC” limitation.
Added “Upgrade With an M2 Series Module Installed” to the “Upgrade/Downgrade Paths and Caveats” section.
Updated the “Security Features” section of the “Cisco NX-OS Release 6.2(2) Software Features” section.
Updated Table 3 to add support for Cisco Nexus B22 Fabric Extender for HP (N2K-B22HP) on the 48-port 1/10 Gigabit Ethernet SFP+ I/O F2 Series module (N7K-F248XP-25).
Updated the “Limitations” section to add “Behavior of Control Plane Packets on an F2e Series Module”.
Updated Table 9 to add support for Fe and F2e Series modules hardware as ERSPAN destinations.
Added the Cisco Nexus B22HP Fabric Extender for HP (N2K-B22HP) to the “Cisco Nexus Fabric Extenders” section.
Updated the ISSU and ISSD information in the “Upgrade/Downgrade Paths and Caveats” section.
Updated the “Open Caveats—Cisco NX-OS Release 6.2” section to add CSCul91443.
Updated the “Interoperability Between Modules” information.
Updated the Updated the “Limitations” section to add “The no hardware ejector enable Command is Not Recommended for Long-Term Use”
- Updated the “Features Available on F2, F2e, and F3 Series Modules” section to add MACSec support for the F2e Series modules.
- Updated “Interoperability Between Modules” section to add that you cannot interoperate the F3 Series plus the F2 and/or F2e Series plus M2 Series in the same VDC.
- Updated “Non-ISSU Upgrade Steps” section.
The Cisco NX-OS software for the Cisco Nexus 7000 Series fulfills the routing, switching, and storage networking requirements of data centers and provides an Extensible Markup Language (XML) interface and a command-line interface (CLI) similar to Cisco IOS software.
Cisco NX-OS Release 6.2 software requires 8 GB of memory. If you have a Cisco Nexus 7000 Series system with a Supervisor 1 module with 4 GB of memory, you must upgrade to 8 GB of memory using the memory upgrade kit, N7K-SUP1-8GBUPG=, before you install Cisco NX-OS Release 6.2.
Instructions for upgrading to the new memory are available in the “Upgrading Memory for Supervisor Modules” section of the Cisco Nexus 7000 Series Hardware Installation and Reference Guide.
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 Series hardware supported by Cisco NX-OS Release, 6 x, Release 5.x, and Release 4.x software.
Table 3 shows the FEX modules supported by the Cisco Nexus 7000 Series I/O modules.
Table 4 shows the service modules supported by the Cisco Nexus 7000 Series switches.
Table 5 shows the transceiver devices supported by each release.
For a list of minimum recommended Cisco NX-OS software releases for use with Cisco Nexus 7000 Series switches, see the document Minimum Recommended Cisco NX-OS Releases for Cisco Nexus 7000 Series Switches.
8-port 10-Gigabit Ethernet I/O module XL1
32-port 10-Gigabit Ethernet SFP+ I/O module XL 1
48-port 1-Gigabit Ethernet I/O module XL 1
48-port 10/100/1000 Ethernet I/O module XL 1
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.
5.For a complete list of supported optical transceivers of this type, go to the Cisco Transceiver Module Compatibility Information page.
- Supported Upgrade and Downgrade Paths
- ISSU Upgrade Steps
- Non-ISSU Upgrade Steps
- Upgrade or Downgrade Caveats
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.
See Table 6 for the in-service software upgrade (ISSU) path to Cisco NX-OS Release 6.2(x). Releases that are not listed for a particular release train do not support a direct ISSU or ISSD to the current release.
See Table 7 for the in-service software upgrade (ISSU) path to Cisco NX-OS Release 6.2(x) for the Cisco Nexus 7700 Series chassis. Releases that are not listed for a particular release train do not support a direct ISSU or ISSD to the current release.
If you are running a Cisco NX-OS release earlier than Release 5.2, you can perform an ISSU in multiple steps. Table 8 lists the supported multistep ISSU paths.
To perform an ISSU upgrade to Release 6.2(2a) from one of the ISSU supported releases listed in Table 6 , follow these steps:
When manually downgrading from Cisco NX-OS Release 6.2(2) 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.
If your Cisco Nexus 7000 Series device that is running Release 6.2(2) has f2e in its configuration as a part of the limit-resource module-type command, some interfaces might become unallocated after a downgrade from Release 6.2(2a). This issue can occur even if you do not have any F2e Series modules in the chassis.
3. After all I/O modules and supervisor modules come up, enter the copy saved-config running-config command. For example, if your saved configuration is in the file bootflash:saved_config, enter the copy bootflash:saved_config running-config command.
– If you do not have a backup switch configuration from the release to downgrade to, follow these steps to change instances of f2e to f2 in the limit-resource module-type command of the Release 6.2(2a) configuration, before reloading the switch:
2. In the copied file, find all instances of f2e in the limit-resource module-type f2 f2e command and replace it with f2 . Remove any redundant instances of f2 . For example, if you replace f2e in the limit-resource module-type f2 f2e command, make sure that you change it to limit-resource module-type f2. Save the file.
All F2e interfaces might become unallocated immediately after an upgrade from Cisco NX-OS Release 6.1(x) to Release 6.2(2a). Generally, this situation should not occur if you follow recommended upgrade procedures. However, if you find that all F2e interfaces are unallocated after the upgrade, before doing any further configuration, complete the following steps to fix the problem:
2. When all the modules are online and all the VDCs are created and in active status, in the context of the Default VDC or the Admin VDC, enter the copy modified-ascii-config running-config echo command to apply the modified ASCII configuration file.
Starting with Cisco NX-OS Release 6.2(2), shared interfaces must come from the module types that the storage VDC supports, and having F1 and F2 interfaces shared in the same VDC is not supported. In Release 6.2(2), the vdc command will fail if you attempt to share F2 interfaces with a VDC that supports only F1 (or vice versa).
In Cisco NX-OS Release 6.1(x), you are allowed to share F2 interfaces with a storage VDC that supports only F1, and you can share F1 interfaces with a storage VDC that supports only F2. But having F1 and F2 shared interfaces in the same storage VDC is somewhat problematic and can potentially cause issues.
If you have a Cisco NX-OS Release 6.1(x) configuration that has shared F1 and F2 interfaces in the same storage VDC, this configuration will be allowed temporarily in Release 6.2 if you are performing an upgrade through a binary configuration, which is the typical upgrade path, rather than through an ASCII configuration. This temporary situation provides a transition period to update the configuration; however, the functionality of the interfaces is not guaranteed during this time. The configuration might be lost after a switch reboot. In addition, the configuration will fail in Release 6.2, if you remove the interface and attempt to add it back to a shared storage VDC. Because of these constraints, we recommend that you remove the combination of shared interfaces before the upgrade to Release 6.2, or after it.
Before or after an upgrade from Cisco NX-OS Release 6.1(x) to Release 6.2, apply either the limit-resource module-type f1 command or the limit-resource module-type f2 command to the storage VDC, and check that the following storage VDC configurations are removed:
In rare instances, if you perform an ISSU from Cisco NX-OS Release 6.1(2) or an earlier release to Release 6.2(2) or a later release and you have an M2 or F2 Series module installed in your Cisco Nexus 7000 Series system, the upgrade might fail with the following error:
When you upgrade Cisco NX-OS software by changing boot variables and reloading the device, make sure to save the FEX HIF configuration to the startup configuration, as well as another location (such as bootflash or an external server). Once the upgrade to a new release is complete, and the FEX is fully online and associated, reapply the FEX HIF configuration.
The FEX queuing feature is enabled by default if you perform an ISSU to a release that supports this feature from an earlier release that supports this feature. The feature is not enabled if you perform an ISSU to a release that supports this feature from an earlier release that does not support this feature.
For an ISSU to Cisco NX-OS Release 6.2(2a) from Release 6.1(x), you must reload the FEX to enable FEX queuing after the ISSU. Enter the show queuing interface fex-hif-port command to verify if FEX queuing is enabled on a given FEX.
Any upgrade from an image that is earlier than Cisco NX-OS Release 6.2(2) to an image that is Cisco NX-OS Release 6.2(2) or later in an OTV network is disruptive. When you upgrade from any previous release, the OTV overlay needs to be shut down for ISSU to operate.
For more details, see the “Preparing OTV for ISSU to Cisco NX-OS 5.2(1) or Later Releases in a Dual-Homed Site” section in the Cisco Nexus 7000 Series NX-OS OTV Configuration Guide .
If you have LISP configured on a Cisco Nexus 7000 Series device, you must remove the configuration before an ISSU. Enter the no lisp feature command to individually unconfigure the LISP commands. Then enter the no feature lisp command. After the ISSU completes, enter the f eature lisp command to reenable LISP and then reconfigure it.
Cisco NX-OS Release 6.2(2a) supports an increased number of Open Shortest Path First (OSPF) process instances per VDC. See the Cisco Nexus 7000 Series NX-OS Verified Scalability Guide for the latest verified number.
If you have more than four OSPF v2 or more than four OSPF v3 process instances configured and you manually downgrade to an earlier release, you must remove instances 5 and higher. Use the following command to match an OSPF v2 process tag with an OSPF process instance:
During an ISSU from Cisco NX-OS Release 5.2(x) or Release 6.1(x) to Release 6.2(2a), the system prompts you to clear inactive access control list (ACL) configurations. Enter the clear inactive-config acl command to clear any inactive ACL configurations.
ISSU, stateful switchover (SSO), and graceful restart are not supported when aggressive failure detection timers are used for any Layer 3 protocols. Starting in Cisco NX-OS Release 5.2(3a), the First Hop Redundancy Protocol (FHRP) with aggressive timers has been validated for SSO or ISSU using the extended hold timer feature. Other protocols such as OSPF have been validated with aggressive timers without SSO or ISSU support. For additional information on aggressive timer support and extended hold timers for FHRP, see the Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide .
Note The Transport Services Package license is required to enable the Locator/ID Separation Protocol (LISP). If you do not have this license, you can enable the grace period for it. If you cannot enable the grace period, perform an ISSU and reload the affected modules.
Cisco NX-OS Release 6.2(2) includes a new CMP image for the Cisco Nexus 7000 Supervisor 1 module. The CMP is upgraded to Release 6.2(2) on a successful ISSU to Cisco NX-OS to Release 6.2(2). When the ISSU completes, reload the CMP image on the active and standby Supervisor 1 modules.
For additional information about the CMP, see the Cisco Nexus 7000 Series Connectivity Management Processor Configuration Guide.
Cisco NX-OS Release 6.2(2) includes a new EPLD image for the Cisco Nexus 7000 Supervisor 1 and the Supervisor 2 module. For instructions about upgrading to a new EPLD image, see the Cisco Nexus 7000 Series FPGA/EPLD Upgrade Release Notes, Release 6.2.
This section briefly describes the new hardware introduced in Cisco NX-OS Release 6.2. For detailed information about the new hardware, see the Cisco Nexus 7000 Series Hardware Installation and Reference Guide.
See Table 2 for the PIDs associated with the hardware components described in this section.
In addition, Release 6.2(6) introduces new cables that allow you to expand the number of ports on selected modules. These cables allow you to connect to one of the 40-Gigabit Ethernet ports on the following modules and connect the other end to up to four 10-Gigabit Ethernet ports. Two cables are available and offer the following:
- Support for the Cisco Nexus 7000 F3 Series 12-port 40-Gigabit Ethernet (QSFP+) Module to support up to 48 10-Gigabit Ethernet ports per slot for 18-slot, 10-slot, 9-slot, and 4-slot chassis.
- Support for the Cisco Nexus 7000 M2-Series 6-port 40-Gigabit Ethernet I/O Module XL to support up to 24 10-Gigabit Ethernet ports per slot for 18-slot, 10-slot, 9-slot, and 4-slot chassis.
The Cisco Nexus 7706 switch is a 6-slot chassis that delivers 1.32 Gbps per slot. It has two half-width slots for Supervisor 2E modules and four full-width slots for I/O modules. With the F3 Series modules, the switch provides 40-Gigabit Ethernet and 100-Gigabit Ethernet ports. The supervisor modules and I/O modules are interchangeable between the Cisco Nexus 7710 switch and the Cisco Nexus 7706 switch.The switch supports up to six fabric modules and uses three fan tray that provide front-to-back airflow cooling. To power the switch, you can use one or two AC or DC 3-kW power supply units, and you can use up to two more power supplies to provide power-supply or grid power redundancy.
- Cisco Nexus 7700 F3 Series 48-port 1/10-Gigabit Ethernet (SFP+) Module (F3 Series)
- Cisco Nexus 7700 F3 Series 24-port 40-Gigabit Ethernet (SFP+) Module (F3 Series)
- Cisco Nexus 7700 F3 Series 12-port 100-Gigabit Ethernet (SFP+) Module (F3 Series)
These multiprotocol modules support Ethernet, FabricPath, FCoE, OTV, LISP, VXLAN, MPLS, VPLS, and DFA. These modules, except the 12-port 100-Gigabit Ethernet module, support Cisco Nexus 2000 Series Fabric Extenders.
- Cisco Nexus 7710 Switch
- Cisco Nexus 7718 Switch
- Cisco Nexus 7700 Series I/O Module
- Cisco Nexus Fabric Extenders
- Cisco Nexus 7000 Series Network Analysis Module
See Table 2 for the PIDs associated with the hardware components described in this section.
The Cisco Nexus 7710 switch is a 10-slot chassis that delivers 1.32 Gbps per slot. It has two half-width slots for two Supervisor 2E modules and eight full-width slots for I/O modules. The switch supports up to six fabric modules and up to eight 3000 W power supply units. There are three fan trays. Airflow is front to back in the Cisco Nexus 7710 switch.
The Cisco Nexus 7718 switch is a 18-slot chassis that delivers 1.32 Gbps per slot. It has two half-width slots for two Supervisor 2E modules, and 16 full-width slots for I/O modules. The switch supports up to 6 fabric modules and up to 16 3000 W power supply units. There are three fan trays. Airflow is front to back in the Cisco Nexus 7718 switch.
For additional information, see the Cisco Nexus 2000 Series Hardware Installation Guide.
For additional information, see the Cisco Nexus B22 Fabric Extender for HP Getting Started Guide .
The Cisco Nexus 7000 Series Network Analysis Module (Cisco NAM-NX1) is the first service module for the Cisco Nexus 7000 Series platform. With the Cisco NAM-NX1, you can implement network analysis and monitoring in the data center. Cisco NAM-NX1 can be installed into any one of the network module slots on a Cisco Nexus 7000 Series switch.
- For a chassis with only F2e Series modules, the default VDC will be created using an F2e Series module as a supported module, unless you apply your own configuration.
- In Release 6.2(2), F2 Series modules can only be a part of an F2 VDC or an F2-F2E VDC.
- The F2e and F2 Series modules cannot exist with the F1 Series module in a VDC.
- A new VDC type, F2E, supports only F2e Series modules, but can be added to other VDC types to allow F2E to be part of the same VDC with F2 modules, or M1 or M2 Series modules. An F2e Series module and any M Series module can be configured in the same VDC.
- During an upgrade to Cisco NX-OS Release 6.2(2), if you have F2 and F2e Series modules, the VDC type automatically changes to the F2-F2E VDC.
- In an F2-F2E VDC, only the features supported on the F2 Series module are supported.
Review the “Upgrade or Downgrade Caveats” section for information related to VDCs that you should be aware of before upgrading to Cisco NX-OS Release 6.2(2).
Some software features are not available on the F2 or F3 Series modules in Cisco NX-OS Release 6.x. See Table 9 for a list of features that have hardware and software support on the F2, F2e, and F3 Series modules.
This section briefly describes the new features introduced in Cisco NX-OS Release 6.2 software. For detailed information about the features listed, see the documents listed in the “Related Documentation” section. The “New and Changed Information” section in each of these books provides a detailed list of all new features and includes links to the feature description or new command.
- Cisco NX-OS Release 6.2(2) Software Features
- Cisco NX-OS Release 6.2(2a) Software Features
- Cisco NX-OS Release 6.2(6) Software Features
For additional information about these features, see the Cisco Nexus 7000 Series Switches Configuration Guides.
- Any Transport over MPLS (AToM), which accommodates different types of Layer 2 packets, including Ethernet and VLAN, to enable the service provider to transport different types of traffic over the backbone.
- Pseudowire provisioning for AToM, which enables you to configure static pseudowires in cases where you cannot use directed control protocols, such as the Label Distribution Protocol or Resource Reservation Protocol over traffic-engineered tunnels (RSVP-TE).
- Ethernet over Multiprotocol Label Switching (EoMPLS), which is a Virtual Private Wire Service (VPWS) that is used to carry Layer 2 Ethernet frames over an MPLS network. EoMPLS enables service providers to offer emulated Ethernet services over existing MPLS networks.
- EoMPLS Graceful Restart, which adds support for a switch that is configured with the Label Distribution Protocol (LDP) Graceful Restart (GR) to assist its neighboring switches to recover gracefully from an interruption in service.
- Layer 2 and Layer 3 load balancing coexistence, which supports Layer 3 VPN and Layer 2 VPN forwarding that is performed independently on the switch using two different types of adjacencies. The forwarding is not impacted by having a different method of load balancing for the Layer 2 VPN.
- Virtual Private LAN Service, which supports a point-to-multipoint service between multiple customer sites using a mesh of point-to-point pseudowires over the provider core to emulate a LAN between the sites.
- Inter-AS Option B lite is supported.
- A best practice macro for vPCs can be enabled in vPC domain configuration mode with the mode auto command. This feature enables the following vPC best practice features:
- The VLAN translation feature allows you to connect applications that reside in separate Layer 2 domains between data centers.
- Selective unknown Unicast flooding is a per MAC address configuration that allows OTV to flood across the DCI for the specified MAC address. This feature is particularly helpful for applications that go silent and timeout from the ARP tables.
- Dedicated broadcast group allows you to configure a separate multicast address for broadcast traffic. This feature is useful for organizations that need separate QoS policies for broadcast traffic.
- OTV has built-in BFD support that does not require any additional configuration on the OTV side, which helps with any reconvergence that OTV might have to handle.
- The scale of OTV and how fast it converges are improved in this release.
- F1 Series and F2e Series modules can be used as internal interfaces with the OTV VDC.
- The Dynamic Host Configuration Protocol (DHCP) relay now supports IPv6.
- Bidirectional Forwarding Detection (BFD) has been enhanced to include a client for ISISv6, PIMv6, BGPv6, and OSPFv3.
- IPv6 logo phase 2 certification is available in this release.
- The Border Gateway Protocol (BGP) has been enhanced to include flexible distance manipulation and an injection map.
- Virtual Router Redundancy Protocol (VRRP) v3 is supported.
- VRF scale enhancements are in this release.
- Private VLAN (PVLAN) support is provided for vPCs and port channels.
- Layer 2 scale improvements are a part of this release.
- ACL ternary control address memory (TCAM) bank mapping allows TCAM banks to accommodate more feature combinations in a more predictable manner. By using this feature, you can optimize space and maximize the utilization of TCAM banks.
- Added support for the DHCPv6 relay agent. You can configure a device to run a DHCPv6 relay agent, which forwards DHCPv6 packets between clients and servers. This feature is useful when clients and servers are not on the same physical subnet.
- For Control Plane Policing (CoPP)
– Changed the behavior of multicast traffic from being policed at different rates in different classes to being grouped into three classes (multicast-host, multicast-router, and normal) and policed at consistent rates.
- The LISP Instance ID supports virtualization and provides a means of maintaining unique address spaces (or address space segmentation) in the control and data plane.
- The LISP Delegated Database Tree (DDT) defines a large-scale distributed database of LISP Endpoint Identifier (EID) space using a DDT node.
- Support for multicast.
Cisco Fabric Extenders support DSCP to queue mapping, and Layer 3 protocol adjacencies on host interfaces (HIFs). Queueing support is not available in this release for the Cisco Nexus 2248PQ-E Fabric Extender.
“The Remote Integration Service Engine (RISE) architecture logically integrates the Citrix NetScaler appliance and the Cisco Nexus 7000 Series switch so that the Citrix NetScaler service appliance appears as a service module within the Cisco Nexus 7000 Series switch. RISE provides streamlined deployment, simplified configuration, and reduced operational costs for service appliances. RISE enables service integration with the Cisco Nexus 7000 Series switch virtual device context (VDC) architecture.
Cisco NX-OS Release 6.2(2a) includes features that qualify this release for Federal Information Processing Standards (FIPS) 140-2 Level 1 certification for the Cisco Nexus 7000 Series. The release is planned to be submitted for certification in December 2013.
- MAC Security
- VLAN Translation
- OTV Support
- OTV Traffic Depolarization
- Interoperability Between Modules
- FCoE Over Physical Port vPC
- Physical Port vPC
- Ingress NetFlow Sampling and DHCP Relay Together
- F3 Series and F2 Series Modules with Dynamic Fabric Automation
- Automatic Bandwidth Adjustment for MPLS TE Tunnels
- ACL Logged as a Permit or Deny Entry
- Large SGT,DGT Pairs
- ELAM Enhancement
The Multiprotocol VLAN Registration Protocol (MVRP) is a VLAN membership protocol, in which end stations and bridges can issue or withdraw declarations related to the membership of VLANs. The attribute type is the 12-bit VLAN ID. MVRP is a pruning protocol that forbids the propagation of unknown unicast and unknown multicast frames in the regions of the network that do not need to receive those frames.
VLAN translation provides flexibility in managing VLANs and data center-related services by allowing you to merge the two Layer 2 domains without actually changing the original VLAN number. For example, when two data centers are connected using some form of DCI such as OTV and reconfiguration is not worth the collateral damage it can cause.
Cisco NX-OS Release 6.2(6) provides support for Overlay Transport Virtualization (OTV) on the F3 Series modules. This feature is supported only in VDCs without OTV extended switched virtual interfaces (SVIs).
OTV route depolarization is enabled by default with Cisco NX-OS Release 6.2(6). Also, the OTV display shows the secondary addresses used by the overlay and adjacencies. You can disable route depolarization using the command-line interface (CLI).
With Cisco NX-OS Release 6.2(6), you can interoperate the F3 Series modules with other types of modules in the same VDC, in a lowest common denominator mode. The following combinations of modules are allowed:
In both cases, all modules perform full Layer 2 and Layer 3 forwarding based on their native capabilities (there is no proxy routing with F3 modules as on earlier M Series and F Series mixed VDCs). Therefore, only features that are common to all of the modules in the VDC are supported, and available hardware forwarding table sizes are generally equivalent to the smallest forwarding table sizes of any of the modules.
The Cisco NX-OS Release 6.2(6) supports Fibre Channel over Ethernet (FCoE) with the physical port virtual port channel (vPC) for the F2 Series and F2e Series modules. This feature is not supported on the F3 Series modules.
The automatic bandwidth adjustment for TE tunnels feature allows you to configure Multiprotocol Label Switching (MPLS) to automatically monitor and adjust the bandwidth allocation for TE tunnels based on their measured traffic load. The automatic bandwidth behavior changes the configured bandwidth in the running configuration. If automatic bandwidth is configured for a tunnel, TE automatically adjusts the tunnel’s bandwidth. This feature is supported with Cisco NX-OS Release 6.2(6).
- CISCO-IF-EXTENSION-MIB (Enhancements)
- IGMP MIB, IGMP-STD-MIB (RFC 2933)
- Cisco Nexus Platform MIB
- LLDP MIB
- LAN_ENTERPRISE_SERVICES, N77-LAN1K9
- VDC_LICENSES, N77-VDC1K9,
- ENHANCED_LAYER2_PKG, N77-EL21K9
- STORAGE_ENT, N77-SAN1K9
For additional information, see the Cisco NX-OS Licensing Guide.
- The no hardware ejector enable Command is Not Recommended for Long-Term Use
- Saving VLAN Configuration Information
- Rebind Interface Command Is Not Automatically Added to ASCII Configuration
- Fabric Module Removal on the Cisco Nexus 7700 Series
- Fabric Utilization on the Cisco Nexus 7700 Series
- MTU Changes Do Not Take Effect on FEX Queues
- Clearing FEX Queuing Statistics Is Not Supported
- Multicast Traffic is Forwarded to FEX Ports
- F2 Connectivity Restrictions On Connecting Ports to a FEX
- ACL Capture on the Cisco Nexus 7000 Series Network Analysis Module
- Behavior of Control Plane Packets on an F2e Series Module
- Error Appears When Copying a File to the Running Configuration
- CISCO-TRUSTSEC-SXP-MIB Does Not Provide an Instance Number
- Reload with CTS Configuration on the Nondefault VDC Causes a syslog Message
- CTS Configuration Command Not Available
- ECMP Support in Hardware
- EIGRP Aggressive Timers
- CLI Command for Breakout Capabilities
- WCCP Support in a Mixed Mode VDC
- DSCP Queuing with FEX and M1 Series Modules
- DHCP Snooping with vPC+ FEX
- Fabric Module Migration Errors
- Proxy Limitation for the N7K-F132XP-15 Module
- PONG in a vPC Environment
- PONG in a vPC Environment
- SVI Statistics on an F2 Series Module
- LISP Traffic
- Role-Based Access Control
- Standby Supervisor Can Reset with Feature-Set Operation
- Unfair Traffic Distribution for Flood Traffic
- BFD Not Supported on the MTI Interface
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.
In Cisco NX-OS Release 6.2(6), if you have dual Sup2e supervisors and your configuration includes the no hardware ejector enable command, physically removing the active supervisor will cause the modules to reload.
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.
This limitation does not apply to a binary configuration, which is the recommended approach, but only to an ASCII configuration. In addition, this limitation applies to all Cisco NX-OS software releases for the Cisco Nexus 7000 Series.
The rebind interface command that is introduced in Release 6.2(2), is needed to ensure the proper functionality of F2e interfaces in certain circumstances. The command might be required when you change the module type of a VDC. However, because of the disruptive nature of the rebind interface command, it is not automatically added to an ASCII configuration file.
This limitation impacts only F2e interfaces. It applies to an F2e interface only when you replay an ASCII configuration file in the context of the Default VDC or the Admin VDC, and when the F2e interface meets all the following conditions:
- The particular F2e interface is allocated to a VDC before the replay and the F2e interface will stay within the same VDC after the replay.
- The ASCII replay applies the limit-resource module-type command to the VDC that owns the F2e interface, and this VDC module type change requires that you enter the rebind interface command.
- Before the ASCII replay, unallocate the F2e interfaces that meet the preceding conditions. The ASCII reply should run smoothly without further action. In particular, the rebind interface command is not needed. Ensure that the ASCII replay properly allocates those F2e interfaces back to their VDCs and applies other interface configurations.
- An alternate approach is to manually add the rebind interface command wherever needed to the ASCII configuration file for replay. Add the rebind interface command immediately after the limit-resource module-type command. Ensure that the ASCII replay properly applies all interface configurations for all interfaces in the relevant VDCs.
Note If you boot up a switch without any startup configuration, this limitation might apply to an ASCII replay. The reason for this is that without a startup configuration, the Default VDC could still have certain F2e interfaces automatically allocated. Because of this possibility, follow the preceding approaches to work around the limitation.
When traffic ingresses from a module on the Cisco Nexus 7700 Series 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.
The configured MTU for the FEX ports is controlled by the network QoS policy. To change the MTU that is configured on the FEX ports, modify the network QoS policy to also change when the fabric port MTU is changed.
Multicast traffic that is sent to Optimized Multicast Flooding (OMF) Local Targeting Logic (LTL) is forwarded to FEX ports that are not 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.
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.
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.
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.
When Cisco Trusted Security (CTS) enforcement is enabled on VLANs and a VDC reload occurs, CTS tries twice to disable the enforcement on the VLANs. The second time, the following syslog message appears:
Web Cache Control Protocol (WCCP) redirect-in and redirect-out is fully supported in the Cisco NX-OS Release 6.2 in nonmixed module VDCs. WCCP is also supported in mixed module VDC scenarios for most module combinations. For complete support details, see the Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide, Release 6.x for complete information.
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.
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.
– 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.
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.
- Beginning with Cisco NX-OS Release 5.2, 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.
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.
In addition, if you perform a feature-set operation while modules are in the process of coming up, then those modules are power cycled. Modules that are up and in the “ok” state are not power cycled when you perform a feature set operation.
Uneven load balancing of flood traffic occurs when you have a seven-member port channel. This behavior is expected and 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.
- Open Caveats—Cisco NX-OS Release 6.2
- Resolved Caveats—Cisco NX-OS Release 6.2(6a)
- Resolved Caveats—Cisco NX-OS Release 6.2(6)
- Resolved Caveats—Cisco NX-OS Release 6.2(2a)
- Resolved Caveats—Cisco NX-OS Release 6.2(2)
Note Release note information is sometimes updated after the product Release Notes document is published. Use the Cisco Bug Toolkit to see the most up-to-date release note information for any caveat listed in this document.
Workaround : Configure the no otv isis hello padding always command on all overlays. Change the value of the interface MTU on the overlay to less than the default of 1400 and change the value of the lsp-mtu to less than the default of 1392.
Symptom : Creation of a switch virtual interface (SVI) should fail if a virtual fabric interface (VFI) is configured on a VLAN. In addition, a VFI configuration on a VLAN should fail if a corresponding SVI is created.
Conditions : This symptom might be seen when the redirect-list is attached to WCCP groups, when a policy is attached to a port-channel interface, or when a VLAN has a WCCP policy attached to a port-channel interface.
Conditions : This symptom might be seen in a scale setup with approximately1000 VLANs when a switch reload is performed with a saved configuration and the configuration has port channels in access mode (but not in trunk mode). As a result, some of the VLANs might fail to come up on some interfaces.
– The CoS is moved between different queues in such a way that it has the same Independent VLAN Learning (IVL) value for different queues. The output of the show queuing interface ethx/y command shows the IVL value of the ingress queues.
– If the template of the system is changed to one of the template types with multiple queues that have the same IVL, such as 8e-4q4q in a Cisco Nexus 7000 Series switch and 8e-4q8q in a Cisco Nexus 7700 Series switch.
Symptom : A rollback fails when as part of the patch, the current trunk-allowed VLAN list is the default 1000 to 4000 and there is a switchport trunk allowed vlan range command after that in the configuration.
Conditions : This symptom might be seen when Virtual Private LAN Service (VPLS) or EFP Ethernet virtual circuits are configured. The pktmgr process on the active supervisor registers high CPU utilization because it is busy dropping STP BPDUs that are entering the virtual circuit from the customer edge-side device.
Conditions : This symptom might be seen when a second fault happens such as an MPLS path or a Label Distribution Protocol (LDP) adjacency going down in the VC after a Layer 2 VPN process failure or a supervisor switchover. The URIB error notifications are not propagated to the VC after a stateful recovery.
Conditions : This symptom might be seen when LLDP sets a nondefault logging level explicitly with the logging level lldp command and a switchover occurs. The issue occurs in an ASCII configuration when the correct logging level is not displayed in the running configuration after a switchover.
Symptom : Interface configurations on a Cisco Nexus 7000 Series Network Analysis Module (Cisco NAM-NX1) are not available to the user for configuration and a meaningful error is not provided. If you copy the file to the running configuration, the errors appear on the switch console. For example:
013 Might 15 13:09:22 F2-FEX %VNTAG_MGR-2-VNTAG_SEQ_ERROR: Error ("sequence timeout") while communicating with component MTS_SAP_HP_I
Conditions : This symptom might be seen when a vc type vlan command is configured in long form PW, or when a port profile is inherited with that configuration. The issue occurs only in the VPLS service with the EFP member in the BD, when either VPLS PW peer has this configuration.
Symptom : An egress RACL is configured on a switch virtual interface (SVI) and pushed to all line cards, even though there are no members associated with the VLAN (both the default and nondefault VLAN).
Conditions : This symptom might be seen on Cisco Nexus 7000 Series devices. It applies only to BFD sessions that are booted on IPv6 interfaces after an ISSU to Cisco NX-OS Release 6.2(2) from an earlier release.
– Enter the show run bfd command to get the BFD configuration. Enter the no feature bfd command to disable the BFD feature and enter the feature bfd command to reenable it. Save all BFD configurations and reapply the configurations to the running configuration after BFD is reenabled.
Conditions : This symptom might be seen when certain packets that originate from F1 or F2 Series modules have proprietary headers associated with them. When the Ethanalyzer tool is used with a capture filter, some packets that match the criteria are not captured because the filter gets applied incorrectly due to the proprietary headers.
Workaround : Capture the packets without using any capture filters and analyze the captured packets using the “display-filter” option of the Ethanalyzer tool. Otherwise, copy the pcap file to an external workstation and use Wireshark software to analyze the packets.
Conditions : This symptom might be seen when a switchover (or a Layer 2 FM process restart) occurs on one peer, and a switchover (or a Layer 2 FM process restart) occurs immediately within 5 to 6 seconds on the other peer. With a sizeable MAC address table scale (greater than approximately10,000 addresses), the symptom occurs.
Workaround : Enter the clear mac address-table dynamic command. If the switchover occurs on one peer and the local MAC database recovery is complete, the other peer does not have the issue. Enter the show mac address-table count command to confirm that the local MAC database recovery is complete.
Symptom : When an ACL QoS policy is pushed by the policy server and gets programmed correctly, a transient and brief failure for sending the status from the line card immediately following a switchover is logged. The following error appears:ACLQOS-SLOT1-2-ACLQOS_FAILED: ACLQOS failure: Error sending client status for verify session ret_val 0x801c006e
Conditions : This symptom might be seen when Virtual Flow Interfaces (VFIs) with autodiscovery Border Gateway Protocol (BGP) are configured, and some of the provider edges (PEs) are VDCs on the same Cisco Nexus 7000 Series device.
Symptom : Port security works correctly when configured on two interfaces, and all MAC addresses are learned through the interfaces. If the shut command is entered on the interfaces, other interfaces have a security violation error.
Symptom : In a VDC with ERSPAN destination sessions that are operationally up, port error messages might appear after certain events such as a VDC reload, module reload, or sequence timeout. Some of the affected ports might move to an error disabled state. The error message might look like the following:ETHPORT-2-IF_SEQ_ERROR: Error ("sequence timeout") communicating with <none: Internal Error> for opcode <None> (RID_PORT: Ethernet3/1)
To prevent this error, enter the monitor session x type-erspan destination command followed by the shut command prior to a VDC reload or reload of the modules with ERSPAN destination ports. Repeat those commands for all operationally up ERSPAN destination sessions.
Symptom : Cisco Nexus 2000 Virtual Circuits (VCs) take a long time to come up. There are continuous Network Layer Reachability Information (NLRI) label advertisements/withdrawals that cause the route to be provisioned after an extended delay.
Because LLDP works for Layer 2 and Layer 3 ports, InterfaceIndex is used for all of them. The TC LldpPortNumber has a range of only 1 to 4096, and all the interface indexes are beyond this range. As a result, the SNMP queries work in some SNMP Managers or Network Management System (NMS), but do not work in others.
Conditions : This symptom might be seen in Release 6.2(2) when the pseudowire interface is entered for a VLAN that it does not belong to. In this case, the show mac addr tbl vlan x interface pw y command was entered, and pw y belonged to VLAN z.
Symptom: In a scale setup with a high number of logical ports, many processes compete for the CPU immediately after a system switchover. As a result, the Spanning Tree Protocol (STP) has less CPU to be able to rebuild its own database and to send its time-critical BPDUs every 2 seconds. This situation causes a CBL port state change and traffic drop.
Conditions : This symptom might be seen on a root bridge change. Multiple sequences of events are triggered starting from Layer 2 to the Layer 3. The number of these sequences is proportional to the number of VLANs in the system. This situation creates contention for the CPU that does not allow enough CPU for STP to send and receive BPDUs to be able to perform the root bridge for all VLANs.
Conditions : This symptom might be seen because Layer 2 PT requires trunk ports to have a native VLAN that is the same as the trunk VLAN for CDP tunneling. The CE native VLAN is the default for VLAN 1. There is a native VLAN mismatch on the two ends of the port-channel link that causes the Link Aggregation Control Protocol (LACP) to suspend the link.
Symptom : Probe packets sent by the Gold StandbyFabric Loopback test and RewriteEngine test are dropped and the current run of the tests are treated as failed. The HIGH_NULL_POE_DROP_CNT and RO4 TDS timeout interrupt counters also start incrementing for the fabric module.
Workaround : Disable the Gold StandbyFabric Loopback test and Rewrite engine test before power cycling the fabric modules or opening or closing the fabric ejectors. Enable the tests once the spine is replaced or removed permanently.
Symptom : IPv6 Unicast Reverse Path Forwarding (URPF)/Redirects is configured on an interface and the switchport command is configured on the interface. In this case, IPv6 URPF/Redirects get disabled, and the Layer 3 configuration associated with the interface is removed from that interface.
The interface is again moved to a Layer 3 interface when the no switchport command is entered on it and an IPv6 address is configured on the interface. In this case, even though the IPv6 URPF/Redirects configuration is not available on the interface, IPv6 URPF/Redirects continues to be enabled on that particular interface because of stale information.
Conditions : This symptom might be seen when an interface that has IPv6 URPF/Redirects enabled is moved to a switchport, the no switchport command is entered on that interface, and an IPv6 address is configured. There is no issue (URPF/Redirects is disabled) if the interface is moved to a switchport and the interface continues to be in a switchport state. The issue occurs only after the no switchport command is entered and an IPv6 address is configured on the interface.
Workaround : To avoid the issue, clear the IPv6 URPF/Redirects information. Manually configure IPv6 URPF/IPv6 Redirects (in the same mode that you used before moving to switchport mode) and unconfigure IPv6 URPF/Redirects with the no version of the commands.
Conditions : In Cisco NX-OS Release 6.1(3), an issue exists where a port can go into a suspended state when the online diagnostics feature fails to reset the port programming meant for the port loopback tests. This situation can occur in a rare scenario when online diagnostics is running port loopback tests and the same ports are being allocated to a different VDC.
Symptom : When a switch boots up and an ASCII configuration is replayed from a file in a vPC+ scale configuration, the access port-channel interfaces go into an error disabled state. The interfaces in the vPC+ switch go into a loop from “initializing” to “link not connected.”
Symptom : If the fabric module is in the POWER_UP state (during initialization) after a power on or insertion, an online insertion and removal (OIR) results in the module having a fabric synchronization failure and port ASIC PL congestion.
Conditions : This symptom might be seen when you define multiple OTV overlays, and the rolled back configuration requires a redefinition of VLAN mappings for both overlays, or you add or remove VLAN mappings for both overlays.
Symptom : After a peer link is shut in the secondary peer in a vPC+, some MAC addresses in a few VLANs can point to a vPC path that is operationally down. As a result, traffic might be silently dropped.
Conditions : This symptom might be seen when a vPC+ peer link is shut and there is an active traffic flow. Due to a race condition that can occur when the vPC paths in the secondary peer are brought down, the issue might be seen.
Symptom : MPLS LDP is missing local labels, which can result in LDP not installing labeled routes and not advertising labels to peer LSRs. To confirm this issue, enter the show mpls ldp internal event err | inc wbool_set command to check for the presence of LDP event traces:
The first two lines are normal comments that exist in the beginning of all running configurations, and they do not cause any issues. The third line is an inline comment that causes problems after the admin VDC migration. The configuration should be corrected before the admin VDC migration.
Inline comments can be caused by incomplete or invalid configurations. Two cases have been identified that might cause inline comments. One is a Layer 2 VPN feature with an incomplete configuration for pseudowire. The other is the EFP/EVC feature with mismatched configurations. Following are examples of those cases:
Conditions : This symptom might be seen when multiple features like NetFlow, QoS, and various types of ACLs such as VLAN ACLs, router ACLs, and port ACLs are configured on interfaces that belong to a VDC.
Conditions : This symptom might be seen when a FabricPath capable port is coming up and the EthPM process sends a message to the port client in all of the line cards. If the line card goes offline at the same time as the message is sent, this issue occurs. The line card going offline exactly at the same time is rare.
Symptom : After an Authoritative Edge Device (AED) failover in an OTV site, traffic going out of the site to receivers that are silent might experience a delay of about 15 seconds until the new AED issues a TCN flush. After this time, the traffic fully converges and there is no impact on functionality.
Symptom : In a scale setup with a high number of logical ports and with multiple VDCs, the number of processes competing for the CPU immediately after a switchover increases with a factor of the number of VDCs. This situation does not allow the Spanning Tree Protocol (STP) enough of the CPU to send out its time-critical and sensitive bridge protocol data units (BPDUs).
Symptom : For IPv4 and IPv6, when the owner_type is set to CONNECTED in the filter, the onep_routing_rib_get_route_list function does not return the connected (direct) route from a Cisco Nexus 7000 Series device.
Symptom : When you enter the no feature-set fabricpath command and perform a switchover, VLANs disappear from the topology after the switchover. Enter the show system internal m2rib topo command to confirm that the VLANs are not displayed in the topology. FabricPath traffic loss can occur on these VLANs as a result.
Conditions : This symptom might be seen after a switchover or ISSU. Before the switchover, the no feature-set fabricpath command was entered, which caused the VLANs and topologies to be disassociated.
Symptom : In a vPC setup, a peer-link flap will bring down the secondary vPCs. They come back up when the peer link is up. During the time the secondary vPCs are going down, if a switchover occurs and then the peer link comes up (in this corner case scenario), the secondary vPCs come up without active VLANs on them. A few vPCs might come up with active VLANs on them, or many or all vPCs might come up with no active VLANs on them.
Conditions : This symptom might be seen on a Cisco Nexus 7000 Series device with a vPC setup and 4000 VLANs in use in the vPCs. The peer link goes down and before all the secondary vPCs go down, a switchover occurs.
Symptom : After the clear ospf neighbor command is entered, OSPF takes 45 seconds to converge and bidirectional forwarding detection (BFD) takes approximately 2 minutes, 30 seconds to converge for a large number of sessions on physical interfaces. BFD takes approximately 2 minutes 10 seconds to converge after the clear ospf command is entered from a steady state.
Conditions : This symptom might be seen when you perform a non-ISSU upgrade to Cisco NX-OS Release 6.2(2) from an earlier release, and ACL configurations that were active before the upgrade become inactive.clear inactive-config acl <<< This command will clear all the ACL config, and create a file in bootflash.
Note The inactive interface configuration for the ACL manager is saved to /bootflash/aclmgr_inactive_if_config.cfg for the default VDC and for VDCs other than the default VDC to /bootflash/vdc_x/aclmgr_inactive_if_config.cfg (where x is vdc number).
Conditions : This issue might be seen after a switchover of a Supervisor 2 module. The VCs go down and come back up, but one VC disappears. This issue probably will not be seen following a supervisor switchover when the two peers are VDCs on the same device.
Workaround : Enter this command for only those values that apply. If 100 is a bridge domain, enter the show spanning-tree bridge-domain 100 command. If 100 is VLAN, enter the show spanning-tree vlan 100 command.
Symptom : The system has bridge domain (BD 200), but no VLAN 200. However, the show hardware mac address-table vlan 200 command displays the hardware entries, but the show hardware mac address-table 3 bridge-domain 200 command does not display an error:
Symptom : In a multi-VDC setup with a large number of VLANs, immediately after a stateful switchover there are many processes competing for the CPU. As a result, Spanning Tree Protocol (STP) has very little of the CPU to be able to rebuild its own database and send its time-critical BPDUs every 2 seconds and process the incoming BPDUs. This issue causes BPDU to time out and causes STP disputes for a short time.
Symptom : IPv6 Bidirectional Forwarding Detection (BFD) sessions go down when an IPv6 RACL is applied on the switch virtual interface (SVI) where BFD is applied. BFD sessions applied alone work correctly.
Conditions : This symptom might be seen when there is something wrong in the IPv6 merge compression logic. There are some entries in the IPv6 TCAM that are probably causing packets to get redirected to the wrong interface. The sessions go down as OSPF packets get dropped. BFD is still able to receive packets.
Symptom : Layer 2 policies are not applied if you attempt to apply an ASCII configuration file from a release earlier than Cisco NX-OS Release 6.2(2) to Release 6.2(2). The policies that are affected include:
Conditions : This symptom might be seen if you generate an ASCII configuration file in a release earlier than Cisco NX-OS Release 6.2(2) and apply it to Release 6.2(2). Layer 2 policies will not be present in the running configuration.
Symptom : In a large scale vPC setup when a peer link port channel (with many member links) is shut on one peer or one of the peers is reloaded, the other peer experiences an Spanning Tree Protocol (STP) bridge protocol data unit (BPDU) timeout.
Conditions : This issue might be seen when the shut command is entered on the peer link (or it is brought down due to a peer reload) in a large scale vPC setup. In this situation, there were 4000 VLANs in the setup.
Conditions : This symptom might be seen when the ip pim spt-threshold-infinity command is set for a last hop router. If the transit router undergoes an ISSU to Cisco NX-OS Release 6.2(2), it is possible that while unicast routing is still converging, data packets get redirected (due to the RPF check fail), which creates the (S, G) state. The result is traffic that is not forwarded for the (S, G) groups that were created.
Conditions : This symptom might be seen if the vPC peer link is shut when the VFIs are configured (for a longer period than the pseudowire active wait timer which has a default value of 300 seconds), and the no shut command is entered on the peer link.
Conditions : This symptom might be seen when a LISP xTR that has only default routes is not able to perform lookups and forward LISP control plane messages. This situation results in the LISP xTR being unable to register database entries or send map requests.
Workaround : Configure specific routes for the Map Server (MS), the Map Resolver (MR), and the Proxy Egress Tunnel Router (PETR). These routes can be static routes that are added to the router, or learned through a routing protocol
Conditions : This symptom might be seen when over 126 HSRP secondary virtual addresses are used on a single group. Some of the secondary addresses might not be displayed in the output of the show running configuration command.2012 Sep 10 16:06:21 l3sys2-agg1-A3 %PIM-3-SLAB_LIB_SLAB_ERR: Slab error [double free attempted] in pim_routetype2012 Sep 10 16:06:21 l3sys2-agg1-A3 %PIM-3-SLAB_ERR: -Traceback: librsw.so+0x9ee8f librsw.so+0x9f173 0x81822ac 0x81c0d5d 0x812f533 librsw.so+0xb76ee librsw.so+0x9bfef librsw.so+0xa6bdf libpthread.so.0+0x6140 libc.so.6+0xca8ce2012 Sep 10 16:06:21 l3sys2-agg1-A3 %PIM-2-SLAB_LIB_SLAB_ELEM_ERR: Slab element Alloc PC: 0x819cbef, Element index: 1097
Symptom : The port numbers displayed from the show hardware internal statistics pktflow command output for the XBAR ASIC (SAC) are not correct because of different port mappings across the two SAC ASICs.
Symptom : When you are working with vPC+ on the F2 series modules, you might see stale MAC addresses in the MAC address table after you reload the module. The hardware MAC address tables will show that the RD value is 1.
Symptom : When you are working with vPC and the ports on a FEX module go up and down, some MAC addresses will be missing on the primary vPC. The MAC address is deleted from the Peer 1 as a part of the shutdown even though Peer 1 did not receive an age notification from Peer 2.
Conditions : This symptom might be seen when the MAC address is on Peer 2 synchronized to Peer 1. As there is traffic on Peer 2, the MAC address does not age out on Peer 2. However, the MAC address ages out on Peer 1, which sends an age notification to Peer 2. Then, the fabric port channel on Peer 1 goes up and down.
Workaround : The only way that local SPAN can be used with MVRP is to have another port that subscribes for the VLANs on the SPAN destination, so that joins are generated by that other port. In this case, when traffic reaches the SPAN source, the traffic is mirrored and forwarded.
Conditions : This symptom might be seen when the host with and SPT threshold of infinity and the sparse mode host share the common intermediate router, which is in the shared tree path for both the hosts and also in the (S, G, R) prune path from the sparse mode host while it sends joins to the source tree.
Symptom : You might see a ~20K memory leak when you bring the port up and down when you are working with more than 2,000 VLANs configured with a vPC peer and FEX module connected through breakout ports.
Conditions: This symptom might be seen when a FEX trunk is configured. The register is sent upstream for all VLANs because FEX ports do not run MVRP. However, if changes are made to the configuration for ex set trunk allowed vlan to one VLAN only, then the leave is not sent for the others. This applies to all ports that do not run MVRP. Workaround: Clear the mac address table for the problem addresses.
Symptom : STP sets the native VLAN to disable instead of blocking when you enter a shut lan command on the secondary vPC peer on a phy-port leg, immediately followed by entering a shut lan command on the same phy-port vPC leg on the primary switch.
Conditions : This symptom might be seen when you are working on a secondary vPC switch on a phy-port vPC leg. You might seen this if you enter a shut lan command on the secondary vPC peer on a phy-port leg, immediately followed by entering a shut lan command on the same phy-port vPC leg on the primary switch.
Conditions : This symptom might be seen if the TCAM resource is larger than the DRAM resource and the TCAM resource exhaustion is not reached before the DRAM resource exhaustion. You can use the show forwarding internal errors command to display the DRAM exhaustion message.
Symptom : Unable to modify access list. The system gives the error message: service not responding. Unable to modify route map. The system gives the error message: SAP did not respond in expected time frame. Unable to save the configuration. the system gives the error message: config lock in progress.
Symptom : A VDC in which the NAM resides has EIGRP neighbors configured on the interface VLAN. When you are reloading the NAM module, those SVIs will see the EIGRP neighbor go up and down when the NAM comes online.
Conditions : This symptom might be seen on SVI interfaces with EIGRP neighbors configured. Those SVIs with EIGRP configured but no neighbors are not affected. The EIGRP neighbors on the Layer 3 physical interface are not affected.
Conditions : This symptom might be seen when the VLAN mgr creates 3 VLANs—1, 4040, and 4042—on system boot up. There are now from 622 onwards. If the resource manager counts these 3 Boot Up reserved VLAN as resources, then you can create only 1021 VLANs and will receive an error.
Conditions : This symptom might be seen with a scale configuration of approximately 20 host interfaces or more with 75 VLANs per host interface on a 2248PQ FEX type. With this configuration, when batched triggers are executed, STP set port failure are seen.
Conditions : The first or few packets reach the supervisor with the proper SHIM header at the remote side until the (S,G) route is installed in the hardware. All further packets hit this (S,G) and punt to supervisor without the SHIM header, which causes these packets to be dropped by the packet manager. This is a special case where we have (S,G) with punt flag and no OIFs associated with the route. The problem is only seen for tunnel interfaces that need a decap at the tunnel end. A multicast ping over a nontunnel interface does not have this problem.
Conditions : This symptom might be seen when you set the trigger as follows: Change the join interface for Overlay1 to the same join interface for Overlay2. This action allows two different overlays to share the same join interface.
Conditions : This symptom might be seen when the ingress port is a FabricPath VLAN, the egress port is a port channel subinterface, subinterface, or SVI, and the policy type is an egress WCCP policy on the routed packet.
Symptom : All vPC port channels corresponding to TCB_RID mentioned in the following syslog can have traffic loss or duplicates on vPC legs depending on whether the peer's leg is up or down after you see the following message:2013 Oct 16 14:18:50 switch PIXM-3-PIXM_SYSLOG_MESSAGE_TYPE_ERR Process:VDC-2-pixm_vl.Please collect show tech pixm-all, show tech pixmc-all .TCB_RID:0x9e,TXN_Type:67,Status:0x421c0017,Error_Type:0x1c.
Symptom : The switch does not return RFC compliance value for lldpRemIndex. Wherever lldpRemIndex is used as an index into an LLDP MIB table, the switch does not respond back with a valid index ID in the range: (Integer32(1..2147483647)) as per the LLDP MIB RFC and just uses the value of 0 for all lldpRemIndex values.command failed: no such pss key [membership update failed for port-channel999 [service: unknown err: 0x40480003 - no such pss key]]SYSMGR-3-CFGWRITE_SRVFAILED Service "xmlma" failed to store its configuration (error-id 0x41470001).
Symptom : When using the vPC track feature, the vPC is brought down at the moment when the tracking object goes down. After some time (30 sec—configured UP interval) the VPC is restored although the tracking object is down.
Conditions : Because of an inconsistency in ISIS and RIB/FIB o/p in the number of ECMPs, ISIS shows more ECMPs than the forwarding layer can support when configured with a higher than supported value.
Conditions : You might see this symptom when you have a large number of mroutes installed in the MRIB and enter the no feature pim command for example, which disables the PIM protocol completely from the switch. In this case, the PIM protocol may halt without sending the acknowledgments to MRIB process leading to the symptom.
Workaround : If you want to disable PIM protocol from the switch, stagger this process at one interface at a time. Also, when we have a very large number of mroutes, try to shut the interface first, before disabling PIM from it and wait for the routes to age out in the scenario.2013 Dec 13 01:21:58 PTAINTS410 %OSPF-3-RPM_LIB_API_FAILED: bgp_lookup_ext_attr() - failed in rpm_acquire_bgp_shmem_lock()
Conditions : You might see this symptom after you perform an ISSU from Cisco NX-OS Release 6.2(2a) to Release 6.2(6a) with the ASM 32K Scale setup. After an ISSU, the mroutes expire and are added back on R4. The problematic route and the RPF on R4 was PC2. However, PC2 is not seen as OIF on the first hop router (FHR) R5.
Symptom: When you downgrade from Cisco NX-OS Release 6.2(6) to Release 6.2(2a) and have a large-scale configuration, the older version may not be able to handle the same scale which might cause the VDC and/or ports to move to failure state.Unable to perform the action due to incompatibility: Module 1, 2, 3, 4, 7, 15 returned status "Aclqos error: no resource found"
Conditions : You might see this symptom after you apply RACL an/or VACL with statistics and QoS configured on VLANs. The system tries to remove bank-mapping, which is failing, and so it fails to remove egress the QoS configured on the VLAN.
Conditions : You might see this symptom if a WCCP and/or PBR policy is applied on an F3 Series module with the action of forwarding the packet to a different module and/or switch; then, you bring down and bring up the interfaces on the local ports on the F3 Series module.
Conditions : You might see this symptom if a WCCP and/or PBR policy is applied on an F3 Series module with the action of forwarding the packet to a different module and/or switch; then, you bring down and bring up the interfaces on the local ports on the F3 Series module.
Conditions : You might see this symptom when the ARP request lands on the peer on which the MAC address is correctly learned, and the ARP response lands on the peer where the MAC address is not learned properly.
Conditions : This symptom might be seen when the queuing policy is attached to all the interfaces or most of the interfaces. In this case, the dscp2q map is pushed to interfaces one at a time instead of pushing for all interfaces at once.
Symptom : Unable to modify access list. The system gives the error message: service not responding. Unable to modify route map. The system gives the error message: SAP did not respond in expected time frame. Unable to save the configuration. the system gives the error message: config lock in progress.
Symptom : A ping between the Cisco Nexus 6000 Series Dynamic Fabric Automation (DFA) leaf and the Cisco Nexus Series 7000 BGP route-reflector spine nodes does not work. The BGP session will not be established and the Nexus 6000 switch DFA node will be isolated from the network if it does not have a redundant BGP RR session.
Conditions : This symptom might be seen when you reload on either the Nexus 6000 switch or the Nexus 7000 switch, or when an interface over fabric control-segment goes up and down. The Nexus 7000 switch must be running Cisco NX-OS Release 6.2(6) code, when the BGP RR spine feature was first introduced, for you to see this symptom.
Conditions : This symptom might be seen when the BGP has an outgoing route map to a peer, with 1500 prefixes or more from various peers, including the peer with the outgoing route map. When the BGP adjacency to a third peer goes up and down, the outgoing route-map matches the prefixes defined in a Permit Sequence but rather than just matching the prefix-list and performing the action on the sequence, it performs the action only on some of the matching prefixes.
Conditions : This symptom might be seen if a failure is encountered with one of the crossbar ASICs.GOLD can incorrectly report the failed module or might be unable to isolate the exact module. For example, the Cisco Nexus 7000 Series switch active supervisor engine might report RewriteEngineLoopback or PortLoopback (or some other) test failed for all (or several) ports in all (or several) modules present in the switch.
Conditions : This symptom might be seen when the port channel or member is deleted, and the cleanup does not happen properly in ELTM. It can also appear in an ISSU if there are new updates and the port-channel configuration is manually modified.
Symptom : When a VDC ID is greater than 7, the ERSPAN source session configuration on the M2 Series modules might be disregarded by the ASIC driver. This issue will result in the SPAN source on an M2 Series module not being spanned.
Symptom : If you have a hardware failure on a vPC peer link with the Cisco Nexus 7000 Series switch, the switch might receive corrupted frames. If these corrupted frames continue to flow, a VDC or switch reload might occur.
Symptom : During a switchover, the crossbar attempts to gain access to the other crossbars in the system. If this process fails, the syslogs might contain an error message such as: XBAR 4 Fabric 0 on switchover initialization failed xbm_fabric_soft_init_on_swovr 1372. If the software does not cause the crossbar to fail, the modules reloading might fail when they try to come online.
Symptom : The switch is pointing a remote dynamically learned HSRP vMAC address to an incorrect interface and also shows the entry as static in the MAC-address table. After you add a static MAC entry to ensure the switch points the MAC address to the right interface, the switch points the MAC address to the correct interface. If the static MAC address is removed, the entry still shows up in the switch as static.
Conditions : This symptom might be seen in a fully loaded setup with many logical/physical ports and periodically, polled statistics result in large buffers that are transmitted synchronously from the modules to the supervisor. The ports can be down and still be polled.
Conditions : This symptom might be seen when the TCAM utilization is close to 50% with an atomic update or 50% or more without an atomic update prior to upgrading to Cisco NX-OS Release 5.2(9) using an ISSU. Upgrading triggers a TCAM reprogramming. For example, this issue can be the result of a module that is reloading or if you are modifying an ACL that is used in QoS classification and reapplied to VLAN.ETHPORT-5-IF_SEQ_ERROR Error ("sequence timeout") communicating with MTS_SAP_ETH_SPAN for opcode MTS_OPC_ETHPM_PORT_PRE_CFG (RID_PORT: EthernetX/Y); ETHPORT-5-IF_DOWN_ERROR_DISABLED Interface EthernetX/Y is down (Error disabled. Reason:sequence timeout)
Symptom : You might see high CPU usage on the pktmgr process and a consequent drop of ARP packets as well as slow or no responses for ARP requests. This issue starts a timeout on local devices, and traffic is not sent because of incomplete ARP requests.
Conditions : This symptom might be seen when you are using OTV unicast mode and there is a constant rate or constant burst rate of broadcast ARP traffic sent from remote sites to the ADJ server (approximately 1000 ARP requests per second).%MODULE-2-MOD_SOMEPORTS_FAILED: Module x (Serial number: xxxxxxxx) reported failure on ports Ethernet x/y-z (Ethernet) due to error in device DEV_CLP_FWD (device error 0xca802600)
Conditions : This symptom might be seen in the VPC+/FP environment. The problem is triggered after an TCN that causes flash in VPC+ domain is received after entries are flushed. Some entries are not correctly installed toward the local VPC+ channels but are installed on the SWID.SWID.LID of local VPC+ channel.
Symptom : The BFD state displays ADMIN DOWN on BFD-enabled interfaces while other protocols on the same interface are up and working. When in this state, the BFD will not report connectivity as expected. Once deadlocked in this manner, it is possible that a restart message from the module could restart BFD causing link and protocol flaps.2013 Nov 29 16:18:03 NX7KD-S1F5R9 %$ VDC-2 %$ %VMM-2-VMM_SERVICE_ERR: VDC2: Service SAP Qosmgr SAP for slot 4 returned error 0x41170014 (Operation timed out) in if_bind sequence2013 Nov 29 19:30:32 F340.12.06-7000-1 %IM-3-IM_RESP_ERROR: Component MTS_SAP_VMM opcode:MTS_OPC_IM_IF_VDC_BIND in vdc:2 returned error:Operation timed out2013 Nov 29 19:30:32 F340.12.06-7000-1 %VDC_MGR-3-VDC_ERROR: vdc_mgr: Error for port Ethernet4/44. Port is currently in vdc NX7KD-S1F5R9 . GIM returned 41170014 [Operation timed out]. Please run the command "allocate interface Ethernet4/44 force" to try again
Conditions : This symptom might be seen when FRR is configured and the protected link has BFD enabled. A BFD neighbor flap does not trigger an FRR event unless the physical interface itself goes down.
Symptom : With PIM SSM at the switch’s VRF, the RPF neighbor might be listed as 0.0.0.0 although the correct entry for the source is present in the RIB and PIM session with peer is up. You might also see RPF neighbor listed as A.B.C.D although there is no route in RIB to source or RIB's next-hop is D.C.E.F.
Conditions : This symptom might be seen only when PIM SSM groups are defined with /32 mask in the SSM range configuration. After unicast convergence, their RPF neighbor might not get updated to be inline along with new the unicast routing topology.
Symptom : Multicast packets from CE to FP might have the ftag=0 set, which brings about unpredictable forwarding at the next FP switch. Some packets are flooded while some packets are discarded at the next switch.
Symptom : Proxy Layer 3 routing might be affected after configuring FabricPath proxy Layer 2 learning and the dynamic MAC entries are flushed from the MAC table. Unicast traffic sent from the supervisor or from an M Series module towards a FabricPath core port might be dropped because the FabricPath outer destination address is misprogrammed during encapsulation.
Conditions : This symptom might be seen when a QoS configuration is attached to more than 512 VLANs and either the switch is reloaded or the M2 Series module is reloaded. As the module boots up, the QoS configuration is loaded onto the module and the module times out while programming the hardware.
Conditions : This symptom might be seen when one VDC is being suspended, and in another session a configuration change (such as removing VLANs) is occurring in another VDC that shares the same module.
Conditions : This symptom might be seen when the component routes for area aggregation are delivered with same the LSID, but with different costs from different devices. The switch applies the cost from the device with the lower router ID, not the bestpath cost.
Conditions : This symptom might be seen when the broadcast flag is set and reply (offer and ack) packets from server only. The first relay agent floods the packet correctly because the giaddr is its own. The packet is dropped when it is received by the second relay agent.%SYSMGR-SLOT3-4-SYSMGR_CORE_TRUNCATED: Core seems to be truncated on generation. 79448 / 145136 KB. PID: 2122%SYSMGR-SLOT3-2-SERVICE_CRASHED: Service "val_usd" (PID 2122) hasn't caught signal 11 (core will be saved).%MODULE-2-MOD_DIAG_FAIL: Module 3 (Serial number: JAF1717AQCJ) reported failure due to Service on linecard had a hap-reset in device DEV_SYSMGR (device error 0x2da)
C onditions : This symptom might be seen if an export map is configured without an inbound route map. A previously evaluated export map set commands then can be erroneously applied to the prefix currently being evaluated.
Conditions : This symptom might be seen when the Nexus 7000 switches are in a VPC configuration with GLBP as the FHRP and FabricPath is enabled with downstream leaf devices. This situation occurs only if the Nexus 5000 switch has an installed Layer 3 daughter card.
Symptom : For GLC-T SFPs in a switch with N7K-M148GS-11 LC, the interface might remain up when the peer side interface is admin shut from the CLI or the copper cable was removed. This happens when the speed is hardcoded for "speed 1000."
Symptom : A module might go down due to a memory leak, and a core file is generated after the crash. The following error messages are observed every 3 minutes after the module goes down and comes back online:SYSMGR-SLOT3-4-VAR_SYSMGR_FULL System core file storage usage is unexpectedly high at 100%. This might cause corruption of core filesSYSMGR-SLOT3-5-SUBPROC_TERMINATED "System Manager (core-client)" (PID 27674) has finished with error code SYSMGR_EXITCODE_CORE_CLIENT_ERR (11).
Symptom : Static port security MAC address might be programmed as a drop-in MAC address table if the switch receives traffic with a source MAC address from the static port security MAC address, and it is received on other ports.
Symptom : Each switch in a subnet appears as IGMP active querier although only the lowest IP address in the subnet is supposed to perform this role. High CPU might occur. A large number of IGMP Queries might be sent and/or received by the switch in one or more VLANs.
Symptom : When you are working with Cisco NX-OS Release 6.1(4a), the BGP session on the active BGP session will not be torn down until BGP session reset/restart if the password is mismatched on both ends in either of the following scenarios (this will cause an inconsistent state):
Symptom : The service attribute in Cisco NX-OS exec shell accounting requests and command accounting requests are set to TAC_PLUS_AUTHEN_SVC_NONE. (Set it to login instead to match what Cisco IOS sends.)
Symptom : The CoPP logging, which generally logs once when the said violation threshold is violated, is repeated every 5 minutes even if there are no new violations for the class after upgrading to Cisco NX-OS Release 6.2(2) using ISSU.
Symptom : When configuring the port security on a switch port, the SNMP polling and CLI return an incorrect status after the interface is error-disabled due to a security violation (a different MAC than the configuration MAC being learned).
Conditions : This symptom might be seen if an F3 port initially configured as a FabricPath edge port is reconfigured as a core port. The Cisco NX-OS software does not recognize this change and might drop incoming packets from this port to the supervisor.
Conditions : This symptom might be seen during a switchover. Some timers might not be correctly cleaned up during the switchover. As a result, a bad timer can be released, which might cause the FEX to fail.
Symptom : In a mixed-chassis setup on Cisco Nexus 7000 Series devices, with an M Series module and an F2e module in the same virtual device context (VDC), the vPC does not start when using any VLAN greater than 4040, and the switch virtual interface (SVI) remains down.
Conditions : This symptom might be seen when AAA authorization is enabled. The show commands sometimes cause a memory leak, which leads to CLI-4-WARN_OUT_OF_MEMORY errors and causes the VSH process to fail.
Symptom : After an upgrade to Cisco NX-OS Release 6.2(2), DHCP relay sometimes fails on Cisco Nexus 7000 Series devices for DHCP requests when the source User Datagram Protocol (UDP) port is not bootpc (port 68).
Symptom : On a Cisco Nexus7000 Series device, packets might be dropped in a FabricPath topology after a reload or bootup of an F1 Series module that is running Cisco NX-OS Release 6.2(2). This issue is not intermittent, and flows that are interrupted cannot pass any packets.
Symptom : On a Cisco Nexus 7000 Series device running Cisco NX-OS Release 6.2(2), broadcast frames coming from the peer link might not be forwarded to host ports on a Cisco Nexus 2000 Series fabric extender (FEX), which causes incomplete ARP entries when the FEX is not connected.
Conditions : This symptom might be seen on Cisco Nexus 7000 Series devices using module type N7K-F248XP-25 or N7K-F248XP-25E after the module or the chassis reloads. However, after a nondisruptive ISSU, this issue does not occur until the module reloads.
Symptom : A Cisco Nexus 7000 Series device sometimes forwards packets across virtual device contexts (VDCs) when it is configured as an emulated switch in a VDC with F2 modules, and with another VDC using M1 modules. The leaking packet is received over a virtual port channel. On the peer, it is received over the peer link on an F2 module and picked up by the M1 modules in another VDC.
Symptom : If a VLAN mapping of X to A exists, attempts to overwrite the mapping with the otv vlan mapping X to B command are rejected. In addition, attempts to copy a configuration to the running configuration are rejected if mapping conflicts exist.
Conditions : This symptom might be seen when the VLAN mapping X -> A is defined under overlay1, but X is then extended under overlay2. You can enter this configuration from the CLI, but it is a misconfiguration and can lead to incorrect translations.
Symptom : When you perform an ISSU to a Cisco NX-OS Release 6.2(2), a reload of the 32-port 10-Gigabit Ethernet SFP+ I/O module (N7K-M132XP-12) is required to enable the new DSCP based queuing functionality in Release 6.2(2).
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What’s New in Cisco Product Documentation , which also lists all new and revised Cisco technical documentation, at:
Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
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)