Cisco Nexus 1000V for KVM is a virtual distributed switch that works with the Linux Kernel-based virtual machine (KVM) open source hypervisor.
The Cisco Nexus 1000V for KVM, Release 5.2(1)SK3(1.1) is based on the OpenStack Icehouse release.
The networking function of OpenStack is controlled and managed by the OpenStack Neutron Service. Neutron has been extended in a such a way that Cisco Nexus 1000V can now provide the networking capabilities to the compute nodes and the virtual machines (VMs). As Neutron creates and configures its networks for its environment, this configuration is passed to the Cisco Nexus 1000V switch.
Using OpenStack, you create VM networks and subnets on the Cisco Nexus 1000V for KVM by defining components such as the following:
Network segments, such as VLANs, VLAN trunks, and Virtual Extensible Local Area Networks (VXLANs)
On the Virtual Supervisor Module (VSM), you create port profiles, which define feature policies for different types or classes of VMs and security policies for the VM’s traffic.
When a VM is deployed, a port profile is dynamically created on the Cisco Nexus 1000V for KVM for each unique combination of policy (or feature) port profile and network segment. All other VMs deployed with the same policy to this network reuse this dynamic port profile.
Note You must consistently use OpenStack for all VM network, subnet, and port configurations. If you create VM networks, subnets, and ports directly on the VSM, the configuration is lost when the OpenStack synchronization occurs. For information about OpenStack, see the Cisco Nexus 1000V for KVM Virtual Network Configuration Guide.
Cisco Nexus 1000V for KVM Features
The Cisco Nexus 1000V for KVM Release 5.2(1)SK3(1.1) supports the following features:
Layer 2 Features
Layer 2 switch ports and VLAN trunks
IEEE 802.1Q VLAN encapsulation
Link Aggregation Control Protocol (LACP): IEEE 802.3ad
Advanced PortChannel hashing based on Layer 2, 3, and 4 information
Virtual port channel Host Mode (static, MAC pinning, MAC pinning relative, manual and subgroup CDP)
Internet Group Management Protocol (IGMP) snooping Versions 1, 2, and 3
Jumbo-frame support; up to 9216 bytes
Integrated loop prevention with the Bridge Protocol Data Unit (BPDU) filter without running Spanning Tree Protocol
Cisco Nexus 1000V uses a multi-hypervisor licensing approach, which allows you to migrate a license from one Cisco Nexus 1000V switch platform type to another. For example, you can migrate the license from a Cisco Nexus 1000V for VMware switch to a Cisco Nexus 1000V for KVM. The Cisco Nexus 1000V supports Essential and Advanced license editions. You can swap editions at any time as long as you have the appropriate licenses available for the Advanced edition. Beginning with Cisco Nexus 1000V Release 5.2(1)SV3(1.1), the Advanced license supports license versioning.
Ingress and egress ACLs on Ethernet and virtual Ethernet ports
Standard and extended Layer 2 ACLs:
– MAC address and IPv4
– Source MAC address
– Destination MAC address
– Class of service (CoS)
Standard and extended Layer 3 and 4 ACLs:
– Source IP
– Destination IP
– Protocol (TCP, UDP, Internet Control Message Protocol [ICMP], and IGMP)
– Source port
– Destination port
– TCP flags
– ICMP and IGMP types
– ICMP code
Port-based ACLs (PACLs)
Scalable network isolation
Unicast Flood and Learn mode
Stateful supervisor failover—Synchronized redundant supervisors are always ready for a failover while maintaining a consistent and reliable state.
Nonstop forwarding—Forwarding continues despite loss of communication between the VSM and Virtual Ethernet Module (VEM).
Process survivability—Critical processes run independently for ease of isolation, fault containment, and upgrading. Processes can restart independently in milliseconds without losing state information, affecting data forwarding, or affecting adjacent devices or services.
Branch-office VEM support—This feature extends the datacenter to the branch office with support for hosts in branch offices and VSMs in the central datacenter.
Management through OpenStack Representational State Transfer (REST) APIs, CLI, and Horizon dashboard
Layer 3 connectivity between VSM and VEM, recommended through the VSM management interface
Cisco NX-OS CLI console
In-service software upgrade (ISSU)
Cisco Discovery Protocol Versions 1 and 2
SNMP (read) v1, v2, and v3
Enhanced SNMP MIB support
Authentication, authorization, and accounting (AAA)
Ingress and egress packet counters per interface
Network Time Protocol (NTP) RFC 1305
Domain Name Services (DNS) for management interfaces
Canonical OpenStack High Availability (HA)
You can deploy the Ubuntu OpenStack portion of Cisco Nexus 1000V in High Availability (HA) mode using Juju charms. No additional Cisco Nexus 1000V configuration is required. For information about the requirements for deploying Ubuntu OpenStack in HA mode, see the documentation at the following location: https://wiki.ubuntu.com/ServerTeam/OpenStackHA.
Limitations and Restrictions
Scheduler for Neutron DHCP Port and Linux Router
The Linux router scheduling is random. At any time, one network node might be provisioned with a greater number of Linux routers than other network nodes.
The default DHCP agent scheduler algorithm is also random. At any time, one controller node might be provisioned with a greater number of DHCP ports than other controller nodes.
Each controller node can support up to 990 ports (DHCP and router ports). When this limit is reached, any additional DHCP or router ports are not brought up on the VEM.
OpenStack Horizon Dashboard
If you have more than 200 ports provisioned in the Cisco Nexus 1000V, the OpenStack Horizon dashboard navigation becomes very slow.
If you are using the OpenStack Horizon dashboard, all vNIC interfaces on the same VM must have the same policy profile. If you need to have different policy profiles assigned to vNICs on the same VM, you can do so by using the OpenStack CLI.
When you bring up a VSM, it should have the default port profile named default-pp. This port profile is not automatically created. You need to create this port profile.
The default-pp port profile is used to create DHCP ports. Do not apply any features on this port profile because it impacts the functioning of the DHCP ports. In addition, do not use this port profile to bring up a VM to which you want to apply the port profile features.
If you reboot the VSM before you enter the copy running-config startup-config command on the VSM, you must create the missing policy port-profiles in the VSM with the same UUID. For more information, see the Cisco Nexus 1000V for KVM Troubleshooting Guide.
Deploying vEthernet trunk ports is possible using a trunk policy profile configured on the VSM. With this profile configured on the port, all VLANs configured in the VSM are allowed. You can restrict the set of allowed VLANs by editing the trunk policy profile on the VSM. However, this change is applied to all ports configured with this profile.
Network Segmentation Manager
The VSM CLI does not prevent you from deleting or modifying objects on the VSM, such as a network segment pool, IP pool template, network segment, or dynamic port profile, that were created by the Network Segmentation Manager (NSM). If you do, your VSM configuration could become out-of-sync with the network configuration on OpenStack.
Starting with Release 5.2(1)SK3(1.1), Cisco Nexus 1000V for KVM does not support the VXLAN Gateway feature.
Virtual Ethernet Modules
The slow path is referred to as the path the packet takes when it is punted to the process level for a switching decision before its kernel fast path flow cache is established. The VEM has a slow path maximum throughput. Traffic drops occur with throughput greater than 300 Mbps, and the amount of CPU being utilized spikes to 100 percent for switching processes.
OpenStack does not support live migration to headless VEMs.
If a VLAN reaches the 4000 MAC address limit, any additional traffic from new MAC addresses use the slow path.
Any configuration change to a port profile results in flows getting reprogrammed, which temporarily slows traffic.
VXLAN Native and VXLAN Enhanced
Having multiple VXLAN Tunnel Endpoints (VTEPs) in the same subnet requires an additional configuration file for the Address Resolution Protocol (ARP) to function. You need to add the following sysctl settings in the /etc/sysctl.conf file:
Multicast traffic on a VXLAN might impact performance.
Access Control Lists
If the applied ACL has rule with Layer 4 parameters, fragmented packets uses slow path, else fragmented packets gets switched in the fast path.
If the NetFlow record has Layer 4 match criteria, then the fragmented packets use the slow path. Otherwise, the fragmented packets gets switched in the fast path.
The maximum multicast traffic throughput without packets being dropped is 3 Gbps on a single VEM.
You cannot change the native VLAN from its default to a different type if you created the trunk network profile using OpenStack.
The show logging information has been removed from the show tech-support svs command output because the information it displayed was not related to the Cisco Nexus 1000V for KVM. If you need additional technical support information, you can use the show tech-support svs detail command. Optionally, you can add the exclude interface pipe; for example, show tech-support svs detail | exclude interface.
Table 1 lists the minimum supported software versions required for a Cisco Nexus 1000V for KVM Release 5.2(1)SK3(1.1) deployment.
Note Depending on your specific Cisco Nexus 1000V for KVM release, it is your responsibility to monitor and install all relevant Linux patches on Linux hosts.
Table 1 Minimum Software Versions Supported by Release 5.2(1)SK3(1.1)
Minimum Software Version
Server and NIC Requirements
You can deploy Cisco Nexus 1000V for KVM on the following Cisco UCS servers:
Standalone rack-mount servers that are managed by Cisco Integrated Management Controller (IMC)
Integrated rack-mount servers that are managed by Cisco UCS Manager
Blade servers that are managed by Cisco UCS Manager
Additionally, you can use other servers supported by Canonical. For information, see the following URL:
The following NIC types have been tested and verified:
Emulex OCe11102-FX 2 port 10 GbE CAN
Intel X520 DA2 10Gbps 2 port NIC
Intel I350 1 Gbps
Intel 82599EB 10 Gbps
Broadcom 5709 1 Gbps 4 port NIC
See the Cisco Nexus 1000V for KVM Software Installation Guide for additional information about the requirements for the Cisco UCS servers that you use for the nodes in your Cisco Nexus 1000V for KVM deployment.
Canonical MAAS and Juju Installation
Cisco Nexus 1000V for KVM uses the Ubuntu Metal as a Service (MAAS) and Juju tools to facilitate the installation of OpenStack and Cisco Nexus 1000V for KVM. A description of each is as follows:
Metal as a Service (MAAS)—Tool that sets up and manages the physical infrastructure on which services are deployed.
Juju—Tool that deploys services, such as OpenStack and the Cisco Nexus 1000V for KVM services to your physical or virtual environment. Juju provides the installation logic (Juju charm) and software packages (Debian packages) to deploy the Cisco Nexus 1000V for KVM.
OpenStack—Scalable cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter.
Cisco Nexus 1000V for KVM— Distributed virtual switch (DVS) that works with several different hypervisors. This DVS version is integrated with the Ubuntu Linux Kernel-based virtual machine (KVM) open source hypervisor.
You need to deploy MAAS and Juju before you can deploy OpenStack with the Cisco Nexus 1000V for KVM.
Using the Bug Search Tool
Use the Bug Search tool to search for a specific bug or to search for all bugs in a release.
Step 3 To search for a specific bug, enter the bug ID in the Search For field and press Return.
Step 4 To search for bugs in the current release:
a. In the Search For field, enter Cisco Nexus 1000V for KVM and press Return. (Leave the other fields empty.)
b. When the search results are displayed, use the filter tools to find the types of bugs you are looking for. You can search for bugs by modified date, status, severity, and so forth.
Tip To export the results to a spreadsheet, click the Export Results to Excel link.
The Cisco Management Information Base (MIB) list includes Cisco proprietary MIBs and many other Internet Engineering Task Force (IETF) standard MIBs. These standard MIBs are defined in Requests for Comments (RFCs). To find specific MIB information, you must examine the Cisco proprietary MIB structure and related IETF-standard MIBs supported by the Cisco Nexus 1000V.
For a list of MIBs that the Cisco Nexus 1000V for KVM supports, see the Cisco Nexus 1000V for KVM System Management Configuration Guide.
This section lists the documents used with the Cisco Nexus 1000V for KVM.
Cisco Nexus 1000V for KVM Release Notes
Install and Upgrade
Cisco Nexus 1000V for KVM Software Installation Guide
Cisco Nexus 1000V for KVM Software Installation Video
Cisco Nexus 1000V for KVM Software Installation Workflow
Cisco Nexus 1000V for KVM High Availability and Redundancy Configuration Guide
Cisco Nexus 1000V for KVM Interface Configuration Guide
Cisco Nexus 1000V for KVM Layer2 Configuration Guide
Cisco Nexus 1000V for KVM License Configuration Guide
Cisco Nexus 1000V for KVM Port Profile Configuration Guide
Cisco Nexus 1000V for KVM REST API Configuration Guide
Cisco Nexus 1000V for KVM Security Configuration Guide
Cisco Nexus 1000V for KVM System Management Configuration Guide
Cisco Nexus 1000V for KVM Verified Scalability Guide
Cisco Nexus 1000V for KVM Virtual Nework Configuration Guide
Cisco Nexus 1000V for KVM VXLAN Configuration Guide
Cisco Nexus 1000V for KVM Command Reference
Cisco Nexus 1000V for KVM OpenStack API Reference Guide
Troubleshooting, Password Recovery, System Messages Guides
Cisco Nexus 1000V for KVM System Messages Guide
Cisco Nexus 1000V for KVM Troubleshooting Guide
Obtaining Documentation and Submitting a Service Request
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)