PDF(189.5 KB) View with Adobe Reader on a variety of devices
ePub(81.2 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(94.5 KB) View on Kindle device or Kindle app on multiple devices
Updated:March 8, 2015
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Release notes are sometimes updated with new information about restrictions and caveats. See the following website for the most recent version of the Cisco NX-OS Release 11.0(3i) Release Notes for Cisco Nexus 9000 Series ACI-Mode Switches:
Cisco NX-OS Software for the Cisco Nexus 9000 Series is a data center, purpose-built, operating system designed with performance, resiliency, scalability, manageability, and programmability at its foundation. It provides a robust and comprehensive feature set that meets the requirements of virtualization and automation in data centers
Cisco NX-OS Release 11.0 works only on Cisco Nexus 9000 Series switches in ACI Mode.
See Table 2 for a list of modules that are supported on Cisco Nexus 9000 Series switches in ACI Mode.
Table 2 lists the hardware that the Cisco Nexus 9000 Series ACI Mode switches support.
Table 2 Supported Hardware
Cisco Nexus 9504 chassis with four slots
Cisco Nexus 9508 chassis with 8 slots
Cisco Nexus 9500 3000W AC power supply, port side intake
The Cisco Nexus 9000 Series ACI Mode Release 11.0(3i) contains no new hardware.
New Software Features
The Cisco Nexus 9000 Series ACI Mode Release 11.0(3i) contains no new software.
For installation instructions, see the Cisco ACI Fabric Hardware Installation Guide.
Follow this procedure when upgrading from a 1.0(2x) release to a 1.0(3x) release:
1. Upgrade the APIC controller software image.
2. After all APICs in the cluster are successfully upgraded, upgrade all the switches in the fabric.
Note The switches may need to be rebooted after upgrading (See CSCut32029).
Follow this procedure when downgrading from 1.0(3x) release to a 1.0(2x) release:
1. Downgrade the APIC controller software image.
2. After all APICs in the cluster are successfully downgraded, downgrade all the switches in the fabric.
Note Switch models N9K-C9372PX, N9K-C9332PQ, and N9K-C9372TX are not supported for downgrading in the APIC 1.0(2x) or the Cisco Nexus 9000 11.0(2x) releases. If your fabric has those models, do not downgrade.
– UDP DestPort 161: SNMP. These cannot be blocked through contracts. Creating an SNMP ClientGroup with a list of Client-IP Addresses restricts SNMP access to only those configured Client-IP Addresses. If no Client-IP address is configured, SNMP packets are allowed from anywhere.
If the TOR 1RU system is configured with the RED fan (the reverse airflow), the air will flow from back to front. The temperature sensor in the back will be defined as an Inlet temperature sensor, and the temperature sensor in the front will be defined as an outlet temperature sensor.
If the TOR 1RU system is configured with the BLUE fan (normal airflow), the air will flow from front to back. The temperature sensor in the front will be defined as an Inlet temperature sensor, and the temperature sensor in the back will be defined as outlet temperature sensor.
From the airflow perspective, the Inlet sensor reading should always be less than the outlet sensor reading. However, in the TOR 1RU family, the front panel temperature sensor has some inaccurate readings due to the front panel utilization & configuration, which causes the Inlet temperature sensor reading to be very close, equal, or even greater than the outlet temperature reading.
When a traceroute is performed from a VM attached to a regular bridge domain and to a VM behind a border leaf, and both of these VMs are behind two different ToRs, the traceroute does not show the ToR with the border leaf.
This section lists caveats that are resolved in Cisco NX-OS Release 11.0(3i). Click a Bug ID shown in Table 5 to access the Bug Search Tool and see additional information about the bug.
After configuring AVS: The status of a vPC/Po used between an iLeaf and a vleaf (AVS) shown as down appears to be an expected behavior. However, this behavior is reported to the APIC as an anomaly. This causes a vPC down fault. This fault needs to be suppressed.
When an IP moves from one MAC behind one ToR to another MAC behind another ToR, even though the VM sends a GARP packet, in ARP unicast mode, this GARP packet is not flooded. As a result, any other host with the original MAC to IP binding sending an L2 packet will send to the original ToR where the IP was in the beginning (based on MAC lookup), and the packet will be sent out on the old port (location). Without flooding the GARP packet in the network, all hosts will not update the MAC-to-IP binding.
When modifying the L2Unknown Unicast parameter on a Bridge Domain (BD), interfaces on externally connected devices may bounce. Additionally, the endpoint cache for the BD is flushed and all endpoints will have to be re-learned.
If an endpoint has multiple IPs, the endpoint will not be aged until all IPs go silent. If one of the IPs is reassigned to another server/host, fabric detects it as an IP move and forwarding will work as expected.
ARP does not reach hosts in the same endpoint group.
The Cisco Nexus 9508 ACI-mode switch supports warm (stateless) standby where the state is not synched between the active and the standby supervisor modules. For an online insertion and removal (OIR) or reload of the active supervisor module, the standby supervisor module becomes active, but all modules in the switch are reset because the switchover is stateless. In the output of the show system redundancy status command, warm standby indicates stateless mode.
When a recommissioned APIC controller rejoins the cluster, GUI and CLI commands can time out while the cluster expands to include the recommissioned APIC controller.
If connectivity to the APIC cluster is lost while a switch is being decommissioned, the decommissioned switch may not complete a clean reboot. In this case, the fabric administrator should manually complete a clean reboot of the decommissioned switch.
Before expanding the APIC cluster with a recommissioned controller, remove any decommissioned switches from the fabric by powering down and disconnecting them. Doing so will ensure that the recommissioned APIC controller will not attempt to discover and recommission the switch.
IGMP Snooping Known Behaviors:
Multicast router functionality is not supported when IGMP queries are received with VxLAN encapsulation.
IGMP Querier election across multiple Endpoint Groups (EPGs) or Layer 2 outsides (External Bridged Network) in a given Bridge Domain (BD) is not supported. Only one EPG or Layer 2 outside for a given BD should be extended to multiple multicast routers if any.
The rate of the number of IGMP reports sent to a leaf switch should be limited to 1000 reports per second.
Unknown IP multicast packets are flooded on ingress leaf switches and border leaf switches, unless “unknown multicast flooding” is set to “Optimized Flood” in a BD. This knob can be set to “Optimized Flood” only for a maximum of 50 BDs per leaf.
If “Optimized Flood” is enabled for more than the supported number of BDs on a leaf, follow these configuration steps to recover:
– Set “unknown multicast flooding” to “Flood” for all BDs mapped to a leaf.
– Set “unknown multicast flooding” to “Optimized Flood” on needed BDs.
This section lists the product documentation for the Cisco ACI.
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)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.