Table of Contents

n1kv_kvm_rn_521sk311

Release Notes for Cisco Nexus 1000V for KVM Release 5.2(1)SK3(1.1)

Last Updated: May 10, 2016

This document describes the features and limitations for Cisco Nexus 1000V for KVM. It also provides information about how to find information about open and closed bugs.

Contents

This document includes the following sections:

- Introduction

- Cisco Nexus 1000V for KVM Features

- OpenStack Features

- Limitations and Restrictions

- Software Compatibility

- Server and NIC Requirements

- Canonical MAAS and Juju Installation

- Using the Bug Search Tool

- MIB Support

Introduction

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:

- Tenants

- Network segments, such as VLANs, VLAN trunks, and Virtual Extensible Local Area Networks (VXLANs)

- IP subnets

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

Multi-Hypervisor Licensing

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.

Security

- 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

– EtherType

– VLAN

– Class of service (CoS)

- Standard and extended Layer 3 and 4 ACLs:

– Source IP

– Destination IP

– DSCP

– Precedence

– 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)

- Named ACLs

- ACL statistics

VXLANs

- Scalable network isolation

- Port statistics

- ACL

- Netflow

- Multicast mode

- Unicast Flood and Learn mode

- Multicast traffics

High Availability

- 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.

System Management

- 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

- SNMP ACL

- Enhanced SNMP MIB support

- SSH v2

- Telnet

- Authentication, authorization, and accounting (AAA)

- TACACS+

- RADIUS

- Syslog

- Ingress and egress packet counters per interface

- Network Time Protocol (NTP) RFC 1305

- Domain Name Services (DNS) for management interfaces

- Distributed NetFlow

OpenStack Features

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.

DHCP Port

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.

VSM

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.

vEthernet Trunks

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.

VXLAN Gateway

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:

net.ipv4.conf.default.rp_filter=2

net.ipv4.conf.all.rp_filter=2

net.ipv4.conf.default.arp_ignore=1

net.ipv4.conf.akll.arp_ignore=1

net.ipv4.conf.all.arp_announce=2

net.ipv4.conf.default.arp_announce=2

- 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.

NetFlow

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.

IGMP

The maximum multicast traffic throughput without packets being dropped is 3 Gbps on a single VEM.

VLANs

You cannot change the native VLAN from its default to a different type if you created the trunk network profile using OpenStack.

Troubleshooting Tools

.

Software Compatibility

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)

Name

Minimum Software Version

OpenStack

Icehouse

Ubuntu

14.04

Kernel

3.13.0-24-generic

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

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.

.

. The Bug Search page opens.

Note If you do not have a Cisco.com username and password, you can register for them at http://tools.cisco.com/RPF/register/register.do.

.

Step 4 To search for bugs in the current release:

. (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.

MIB Support

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.

.

Related Documentation

This section lists the documents used with the Cisco Nexus 1000V for KVM.

General Information

Install and Upgrade

Configuration Guides

Reference Guides

Troubleshooting, Password Recovery, System Messages Guides

Obtaining Documentation and Submitting a Service Request

.

. The RSS feeds are a free service.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Copyright © 2014-2016, Cisco Systems, Inc. All rights reserved.