Chapter 1. Overview

Information About the Installation

Juju Charms

Configuration Files

Types of Nodes

Supported Nodes

Network Connectivity Between OpenStack Services

Supported Topologies

Physical Deployment

Virtual Machine Deployment

OpenStack High Availability Deployment

Chapter 2. System Requirements

Networking Requirements

Minimum Node Requirements

Supported Operating Systems

Supported Hypervisors

Supported MAAS Deployment

Chapter 3. Preparing for Installation

Downloading the Cisco Nexus 1000V Software

Preparing the Configuration and Mapping Files

OpenStack Charm Parameters

Cisco Nexus 1000V for KVM VSM Charm Parameters

Cisco Nexus 1000V for KVM VEM Charm Parameters

Cisco Nexus 1000V for KVM VXLAN Gateway Charm Parameters

Chapter 4. Installing Cisco Nexus 1000V for KVM

Steps to Install the Cisco Nexus 1000V for KVM

Installing and Configuring MAAS

Installing and Configuring Juju

Installing and Configuring the OpenStack Services

Verifying the Cisco Nexus Plug-in for OpenStack Neutron Version

Installing and Configuring the Cisco Nexus 1000V for KVM

Installing and Configuring the VXLAN Gateway Using Juju Charms

Chapter 5. Installing VSM on the Cisco Nexus Cloud Services Platform

Information About Installing a VSM on the Cisco Nexus Cloud Services Platform

Installing a VSM on the Cisco Nexus Cloud Services Platform

Chapter 6. Installing and Configuring the VXLAN Gateway

Information About the VXLAN Gateway Deployment

Guidelines and Limitations for Cisco Nexus 1000V VXLAN Gateway

Steps to Install and Configure VXLAN Gateway

Configuring Port Profiles on the VSM

Configuring a Port Profile for the Uplink on the VXLAN Gateway

Configuring a Port Profile for the VTEP on the VXLAN Gateway

Installing the VXLAN Gateway as a VM Using Juju Charms

Configuring the VXLAN Gateway Data and Management Interfaces Using OpenStack dashboard

Guidelines and Limitations for the OpenStack Dashboard

Steps to Configure the VXLAN Gateway Interfaces Using the OpenStack Dashboard

Creating a Trunk Network Profile Using OpenStack Dashboard

Creating a VLAN Network Profile Using OpenStack Dashboard

Creating a Network Using the OpenStack Dashboard

Creating a Subnet for a Network Using the OpenStack Dashboard

Booting a VXLAN Gateway VM

Configuring the VXLAN Gateway Data and Management Interfaces Using the OpenStack CLI

Steps to Configure the VXLAN Gateway Interfaces Using the OpenStack CLI

Creating the VXLAN Gateway Data Interface

Creating a VXLAN Gateway Management Interface

Booting a VXLAN Gateway VM

Example of VXLAN Gateway Interface Configuration

VXLAN Gateway and High Availability

Configuring the VXLAN Gateway HA Mode as Standalone

Configuring the VXLAN Gateway as an HA Pair

Managing the VXLAN-to-VLAN Mappings on the VXLAN Gateway

Verifying the VXLAN Gateway Configuration

Appendix A. Sample Global Configuration File

Sample Global Configuration File

Appendix B. Setup Script

Setup Script

Preface

Audience

Document Conventions

Related Documentation for Cisco Nexus 1000V for KVM Software

Related Documentation for Cisco Nexus Cloud Services Platform

Documentation Feedback

Obtaining Documentation and Submitting a Service Request

Copyright Page

Chapter 1. Overview

This chapter contains the following sections:

- Information About the Installation

- Juju Charms

- Configuration Files

- Types of Nodes

- Supported Nodes

- Network Connectivity Between OpenStack Services

- Supported Topologies

Information About the 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.

The following figure shows the installation process:

Installation Process Overview

If you want to deploy OpenStack with the Cisco Nexus 1000V for KVM on a smaller scale for testing purposes, see Setup Script.

Juju Charms

The charm logic to install the Cisco Nexus 1000V-specific OpenStack Networking plugins and the Cisco Nexus 1000V for KVM services are packaged together in a charm Debian package called jujucharm-n1k_5.2.1_sk3.1.1YYYYMMDDhhmm-1_amd64 . This package contains the following OpenStack and Cisco Nexus 1000V for KVM charms:

- nova-cloud-controller

- quantum-gateway

- openstack-dashboard

- nova-compute

- vsm

- vem

- vxlan-gateway

The Metal-as-a-Service (MAAS) node downloads the OpenStack and Cisco Nexus 1000V for KVM charms to the cluster nodes to facilitate the installation of their respective services.

You must download each of the following required charms separately from the Charm store:

- ceph

- ceph-radosgw

- cinder

- glance

- keystone

- mysql

- rabbitmq-server

- swift-proxy

- swift-storage

Juju deploys each service using its respective charm and two configuration files: its own YAML Ain't Markup Language (YAML) configuration file (called config.yaml that comes with the charm and serves as its parameter data modeling and default value settings) and a global configuration file (a file that you create for defining any deployment-specific parameters).

Note

Treat the config.yaml file as a read-only file. If you want to add any deployment-specific parameter changes, use the global configuration file.

For more information about the global configuration file, see Preparing for Installation.

The Virtual Supervisor Module (VSM) charm helps to deploy the VSM as a virtual machine on an Ubuntu KVM server node in a MAAS environment. This charm does not install the VSM on a Cisco Nexus Cloud Service Platform. On a Cloud Service Platform, VSM is installed through the standard method without the Juju charm. For more information, see Installing VSM on the Cisco Nexus Cloud Services Platform.

The Virtual Ethernet Module (VEM) charm is a subordinate charm under two primary charms: nova-compute and quantum-gateway. You deploy the VEM first; however, the real instantiation of the VEM happens when you add relationships with the corresponding primary charms.

The VEM can be configured by using the config.yaml file and the global configuration file that you provide. In addition, you can define specific information for a host by using a variable named mapping which takes in the content of a server node mapping file in YAML format and named, for example, mapping.yaml. This file is delineated by the host ID (for example, maas-node-3) where you specify each server node variable value that is different from the other server nodes. The most common usage of this mapping file is for configuring the VXLAN Tunnel Endpoints (VTEPs) to implement the Virtual Extensible Local Area Network (VXLAN) feature. VTEPs are host-specific and require that you define host-specific values.

Configuration Files

Each charm's parameters are defined in a configuration file in YAML format.

Note

YAML (rhymes with “camel”) is a human-friendly, cross language, Unicode based data serialization language designed around the common native data structures of agile programming languages. It is broadly useful for programming needs ranging from configuration files to Internet messaging to object persistence to data auditing.

The config.yaml file defines the whole set of configurable parameters for each charm. It defines each parameter's type, default value, and corresponding description. You do not modify this file. For an example of this file, see Sample Global Configuration File.

To define values for parameters that are specific to your deployment, you need to create a global configuration file. You separate the charms into sections and provide the corresponding parameters and values in each section. For more information, see Preparing the Configuration and Mapping Files.

For the Cisco Nexus 1000V-related OpenStack charms listed below, you need to modify the global configuration file with this provision: openstack-origin:  ppa:cisco-n1kv/icehouse-updates.

- nova-cloud-controller

- nova-compute

- openstack-dashboard

- quantum-gateway

Note

To deploy the VEMs with their specific parameters, you need to create a host-mapping file, which is deployed with the other configuration files when you deploy the VEM service. For more information see, Cisco Nexus 1000V for KVM VEM Charm Parameters.

Types of Nodes

A node in MAAS architecture can be a physical server or a virtual machine. MAAS does not differentiate between these two.

The Cisco Nexus 1000V for KVM deployment has the following five node types:

- Infrastructure nodes (MAAS server node and Juju bootstrap node)

- OpenStack service nodes

- Network nodes (also known as Quantum-gateway nodes)

- Nova compute nodes

- Virtual Supervisor Module (VSM) nodes

MAAS Server Node

The MAAS server node is the cluster controller where the cluster provisioning and service management are performed. It provides the following functions:

- DHCP and Preboot Execution Environment (PXE) boot services

- DNS and DNS forwarding service

- Cluster controller service for enlisting and delisting the cluster nodes

- Debian package proxy

- Juju client when the Juju command is issued

Juju Bootstrap Node

The Juju bootstrap node is the server node where the following functions are provided:

- Serves the Juju request from clients (for example, from the MAAS server)

- Service scheduling

- Service staging

- Establishing and maintaining relationships between services

OpenStack Service Nodes

If you decide to deploy any of the following OpenStack services, they can be deployed using their corresponding charms:

Services

Charms

Cloud controller

Loads Cisco Nexus 1000V VXLAN Gateway image to Glance

nova-cloud-controller

vxlan-gateway (subordinate charm to nova-cloud-controller)

Identity service

keystone

Unified, distributed storage service

ceph

Amazon Simple Storage Service (S3), Swift-compatible HTTP gateway for online object storage on top of a Ceph cluster (RADOS Gateway)

ceph-radosgw

Volume service

cinder

Image service

glance

Django-based web user-interface for administering the OpenStack nodes

openstack-dashboard

Proxy for object storage service

swift-proxy

Object storage service

swift-storage

SQL database service

mysql

Advanced Message Queuing Protocol (AMQP) messaging service

rabbitmq

Percona XtraDB Cluster, which provides an active/active MySQL-compatible alternative that is implemented using the Galera synchronous replication extensions

percona-cluster

Network Nodes

The network nodes host the OpenStack networking services for your Cisco Nexus 1000V for KVM deployment, including all of the OpenStack service nodes. The network nodes provide the following services through these service charms:

Services

Charms

Neutron DHCP and Layer 3 agents

quantum-gateway

vem (subordinate charm to quantum-gateway)

Nova Compute Nodes

The Nova compute nodes host your virtual machines (VMs), including any VXLAN Gateway VMs that you have deployed as VMs. The Nova compute nodes provide the following service through these service charms:

Service

Charms

Nova compute service

nova-compute

vem (subordinate charm to nova-compute)

VSM Nodes

The VSM can be hosted on a dedicated server node or on a Cisco Nexus 1110 as a Virtual Service Blade (VSB). The VSM node provides the following service through this service charm:

Service

Charm

Distributed virtual switch management and control of multiple Virtual Ethernet Modules (VEMs).

vsm

Supported Nodes

The Cisco Nexus 1000V for KVM supports the following nodes in a Metal-as-a-Service (MAAS) OpenStack cluster:

- One MAAS server node

- One Juju bootstrap node

- One or more OpenStack service nodes

- One or more Nova-compute nodes

- Zero, one, or more network nodes

- One or two Virtual Supervisor Module (VSM) nodes if you deploy the VSM as a virtual machine (VM). Zero VSM nodes when you deploy the VSM as a Virtual Service Blade (VSB) in a Cisco Cloud Services Platform.

Network Connectivity Between OpenStack Services

A MAAS deployment requires the following four functional networks:

- Management network—Provides internal communication between the OpenStack components. All IP addresses on this network need to be reachable only within the data center.

- Data network—Provides communication between VMs in the cloud. The IP addressing requirements of this network depend on the OpenStack network plugin that your deployment uses.

- Public network—Provides a node with public internet access. If required, IP addresses on this network need to be reachable from the internet.

- Intelligent Platform Management Interface (IPMI) network—Manages the power sequence for all of the nodes in the cluster.

System administrators retain the option to collapse network boundaries based on the physical setup of their datacenter. For example, you can fold the management network into the data network.

Supported Topologies

Cisco Nexus 1000V for KVM supports both physical and virtual machine topologies.

- Physical Deployment

- Virtual Machine Deployment

- OpenStack High Availability Deployment

Physical Deployment

In this deployment model, the services are deployed on bare metal servers rather then as virtual machines. See the figure below. The primary benefit of this deployment model is the performance improvement of the OpenStack services as well as the network nodes. When a Layer 3 agent with high performance is required, this deployment model is recommended.

The VSM can be deployed in active/standby high availability (HA) mode using the Juju charms, or it can be manually brought up on a Cisco Nexus 1010 or 1110 Virtual Service Appliance. In all deployment models, we recommend that you deploy the Virutal Supervisor Module (VSM) in HA mode.

You can also deploy OpenStack in HA mode. For more information, see OpenStack High Availability Deployment.

Topology of Physical Deployment

Virtual Machine Deployment

The simplest deployment model is one where all of the OpenStack, Metal-as-a-Service (MAAS), and Juju services are deployed on a single physical server as virtual machines (VMs). See the figure below. The network node (used for offering the DHCP/Layer 3 Agent service) is also deployed on this server as a VM. Multiple network node instances can be created for scaling the agent ports. However, the capacity of the Layer 3 agents is limited in this solution because all the Layer 3 agents are running on the same physical server.

In this solution, a Virtual Supervisor Module (VSM) can be deployed as a VM or on a Cloud Services Platform (CSP). Similarly, the network node can be deployed as a VM or on a physical server. However, we recommend that you deploy the network node on a physical server, as shown in the figure.

The VSM can be deployed in Active/Standby HA mode using the Juju charms, or it can be manually brought up on a Cisco Nexus 1010 or 1110 Virtual Service Appliance. In all deployment models, we recommend that you deploy the VSM in high availability (HA) mode.

You can also deploy OpenStack in HA mode. For more information, see OpenStack High Availability Deployment.

Topology of Virtual Machine Deployment

OpenStack High Availability Deployment

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: Click Here .

The reason that the Cisco Nexus 1000V requires no additional configuration is that the Cisco Nexus Plug-in for OpenStack Neutron resides in the Nova-cloud-controller (NCC), which provides the API endpoints for the Nova and Neutron services. As APIs are stateless, the NCC nodes can be scaled horizontally by load-balancing the requests across all of the available nodes. Therefore, only one active NCC node processes the requests, and, when necessary, the node sends the requests to the Virtual Supervisor Module (VSM).

Chapter 2. System Requirements

This chapter contains the following sections:

- Supported Operating Systems

- Supported Hypervisors

- Supported MAAS Deployment

Networking Requirements

The following table describes the networking requirements that the nodes in your Cisco Nexus 1000V for KVM deployment must meet.

Networking Requirements for Nodes

Node

Network Requirements

MAAS

- Intelligent Platform Management Interface (IPMI)

- Management interface

- Public interface

Juju

- IPMI

- Management interface

Nova Cloud Controller

- IPMI

- Management interface

RabbitMQ+MySQL

- IPMI

- Management interface

VSM

- IPMI

- Management interface

Compute

- IPMI

- Management interface

- Data interface

Network

- IPMI

- Management interface

- Data interface

- Public interface

Ceph (Optional for non-HA deployment; Required for HA deployment)

- IPMI

- Management interface

- HA interface

Minimum Node Requirements

The following tables list the minimum node requirements for deploying the Cisco Nexus 1000V for KVM.

Minimum Node Requirements for a Physical Server Deployment

Node

Memory (GB)

Hard Drive (GB)

CPU or vCPU

Node Type

Ceph Storage

8

400

2

Server

MAAS

4

75

2

Server

Juju

2

10

2

Server

Rabbit-MQ/MySQL

2

50

2

Server

OpenStack Controller

2

300

2

Server

Nova Compute

24

300

2

Server

VSM

4

3

2

VM

Quantum Gateway

24

10

2

Server

VXLAN Gateway

2

10

2

VM

VSM Hypervisor

16

50

2

Server

VXLAN Gateway Hypervisor

24

300

2

Server

Minimum Node Requirements for a Virtual Server Deployment

Node

Memory (GB)

Hard Drive (GB)

CPU or vCPU

Node Type

MAAS

4

75

2

VM

Juju

2

10

2

VM

MySQL

2

50

2

VM

Rabbit-MQ

2

10

2

VM

Nova Cloud Controller

2

10

2

VM

Cinder

1

75

1

VM

Keystone

1

8

1

VM

Glance

1

25

1

VM

OpenStack Dashboard

1

20

2

VM

VSM

4

3

2

VM

Nova Compute

24

300

2

Server

Quantum Gateway

24

10

2

Server

VXLAN Gateway

2

10

2

VM

VSM Hypervisor

16

50

2

Server

VXLAN Gateway Hypervisor

24

300

2

Server

Supported Operating Systems

The Cisco Nexus 1000V for KVM with OpenStack Icehouse release supports the operating system levels in the following table.

Name

Supported Versions

Ubuntu

14.04

Kernel

3.13.0-24-generic

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.

Supported Hypervisors

Cisco Nexus 1000V for KVM supports the Kernel-based Virtual Machine (KVM) for the supported Ubuntu operating system as the hypervisor in the OpenStack cluster. KVM is a virtualization package for Linux on an x86 hardware platform. KVM uses x86 hardware virtualization extensions (for example, Intel VT-x) to implement a hypervisor that hosts VMs as userspace processes.

Supported MAAS Deployment

For MAAS deployment, the following characteristics are supported:

- One cluster controller per MAAS deployment.

- A maximum of two VSMs (active/standby) per Cisco Nexus 1000V for KVM cloud service deployment.

- One or more services on a dedicated server or in a virtual machine on a single server.

- Each VSM must be on different server and must be the only VM on that server.

Chapter 3. Preparing for Installation

This chapter contains the following sections:

- Downloading the Cisco Nexus 1000V Software

- Preparing the Configuration and Mapping Files

- OpenStack Charm Parameters

- Cisco Nexus 1000V for KVM VSM Charm Parameters

- Cisco Nexus 1000V for KVM VEM Charm Parameters

- Cisco Nexus 1000V for KVM VXLAN Gateway Charm Parameters

Downloading the Cisco Nexus 1000V Software

The Cisco Nexus 1000V for KVM software packages are available from two locations and, as such, its image versions are named based on the location. The following table lists the package name and versions based on their location.

Package Name

CCO Image Version

Cisco PPA

VSM

5.2.1.SK3.1.1

5.2.1.sk3.1.0.187-1

VEM

14.04.5.2.1.sk3.1.0.s0.187-1

14.04.5.2.1.sk3.1.0.s0.187-1

VXLAN-GATEWAY

5.2.1.SK3.1.1

5.2.1.sk3.1.0.187-1

The location that you choose to download the software from affects the way that you set up and execute the installation.

- Downloading from the Cisco PPA—You can set up your installation so that when you deploy the Cisco Nexus 1000V for KVM, the charms retrieve the packages from the Cisco PPA. For charms to install the VSM, VEM, and VXLAN gateway packages from the PPA you must provide the correct Cisco PPA link as the n1kv-source in the global configuration file.

- Downloading from Cisco.com—You can manually download the software from Cisco.com to an HTTP server so that when you deploy the Cisco Nexus 1000V for KVM, Juju retrieves the software from the HTTP server. To perform this type of installation, you must define the location of the HTTP server for the VSM, VEM, and VXLAN Gateway charms in the global configuration file.

For example, you can use the MAAS server as the HTTP server because it already provides the HTTP service and its IP address is well known within the cluster.

For information, see the following:

- Cisco Nexus 1000V for KVM VSM Charm Parameters

- Cisco Nexus 1000V for KVM VEM Charm Parameters

- Cisco Nexus 1000V for KVM VXLAN Gateway Charm Parameters

Preparing the Configuration and Mapping Files

Before you can deploy the Cisco Nexus 1000V for KVM, you need to configure several charms with specific configuration information. You do this by defining specific charm parameters in a global configuration file that you create.

Note

You must maintain consistency between the global configuration file parameter names and the charm's config.yaml file parameter names. Do not introduce new parameter names in the global configuration file.

If your deployment requires it, you can deploy VEMs with unique configuration parameters instead of using the configuration parameters that are defined for all VEMs in the config.yaml file. To do this, you need to create a mapping file.

OpenStack Charm Parameters

You must modify the global configuration file for the following Cisco Nexus 1000V for KVM-related OpenStack charms:

- nova-cloud-controller

- nova-compute

- openstack-dashboard

- quantum-gateway

The following sections provide information about the OpenStack charm parameters that you need to define in the global configuration file.

nova-cloud-controller Charm Parameters

Parameter

Description

openstack-origin: debian-pkg-location

Location of the Cisco Nexus 1000V for KVM Debian package:

openstack-origin:  ppa:cisco-n1kv/icehouse-updates

n1kv-vsm-username: vsm-username

Login for accessing the Cisco Nexus 1000V for KVM (VSM).

n1kv-vsm-password: vsm-password

Secure password for accessing the Cisco Nexus 1000V for KVM (VSM).

n1kv-vsm-ip: vsm-ip-address

IP address of the VSM.

This example shows the nova-cloud controller portion of the global configuration file:

nova-cloud-controller:
openstack-origin:  ppa:cisco-n1kv/icehouse-updates
n1kv-vsm-username: nexus
n1kv-vsm-password: nexus123
n1kv-vsm-ip: 192.168.10.1

.
.
.

nova-compute Charm Parameters

Parameter

Description

openstack-origin: debian-pkg-location

Location of the Cisco Nexus 1000V for KVM Debian package:

openstack-origin:  ppa:cisco-n1kv/icehouse-updates

This example shows the nova-compute portion of the global configuration file:

nova-comute:
openstack-origin:  ppa:cisco-n1kv/icehouse-updates
.
.
.

quantum-gateway Charm Parameters

Parameter

Description

openstack-origin: debian-pkg-location

Location of the Cisco Nexus 1000V for KVM Debian package:

openstack-origin:  ppa:cisco-n1kv/icehouse-updates

enable-l3-agent: {true | false}

Parameter for enabling or disabling the Layer 3 agent. Following are the valid values:

- true—Brings up the Linux router as part of the quantum-gateway.

- false—Does not bring up the Linux router.

This example shows the quantum-gateway portion of the global configuration file:

quantum-gateway:
openstack-origin:  ppa:cisco-n1kv/icehouse-updates
plugin: n1kv
ext-port: eth1
.
.
.

openstack-dashboard Charm Parameters

Parameter

Description

openstack-origin: debian-pkg-location

Location of the Cisco Nexus 1000V for KVM Debian package:

openstack-origin:  ppa:cisco-n1kv/icehouse-updates

profile:name

Default profile for the dashboard to use, for example, cisco.

This example shows the openstack-dashboard portion of the global configuration file:

openstack-dashboard:
openstack-origin:  ppa:cisco-n1kv/icehouse-updates
profile: cisco
.
.
.

Cisco Nexus 1000V for KVM VSM Charm Parameters

This table lists the Cisco Nexus 1000V for KVM VSM charm parameters that you need to define in the global configuration file.

Parameter

Description

n1kv-source: debian-pkg-location

Location of the Cisco Nexus 1000V for KVM VSM software. The location that you define depends on whether you choose to have Juju download the VSM software (charm) automatically from the Cisco Personal Package Archive (PPA) or you choose to manually download the software from Cisco.com to a local HTTP server. For more information, see Downloading the Cisco Nexus 1000V Software.

Define the debian-pkg-location variable in one of the following two ways:

- Cisco PPA—n1kv-source:  ppa:cisco-n1kv/n1kv-updates

- Local HTTP server—http://server-address/vsm-image-name.iso

n1kv-vsm-domain-id: domain-id

Domain number that the VSM will control.

n1kv-vsm-password: vsm-password

Secure password for accessing the Cisco Nexus 1000V for KVM (VSM).

n1kv-vsm-name: vsm-name

Name of the VSM.

n1kv-vsm-role: {primary | secondary}

High availability role. Valid values are primary or secondary.

n1kv-vsm-ip: management-IP-address

IP address of the management interface.

n1kv-vsm-mgmt-netmask: management-ip-subnet-mask

IP address subnet mask of the management interface.

n1kv-vsm-gateway: management-subnet-default -gateway

IP address of the management subnet default gateway.

n1kv-vsm-ctrl-mac:

MAC address of the VSM's control TAP interface. This parameter is optional for the primary VSM, but required for the secondary VSM.

n1kv-vsm-mgmt-mac

MAC address of the VSM's management TAP interface. This parameter is optional for the primary VSM, but required for the secondary VSM.

n1kv-vsm-pkt-mac:

MAC address of the VSM's packet TAP interface. This parameter is optional for the primary VSM.

n1kv-vsm-console-pts:

(Optional) Console port of the VSM VM.

n1kv-vsm-vm-vcpu:

(Optional) Number of vCPUs in the VSM VM. The default and recommended value is two vCPUs.

n1kv-vsm-disk-size:

(Optional) Disk size (GB) of the VSM VM.

n1kv-phy-intf-bridge:

(Optional) Host interface to which the VSM bridge is attached. The bridge connects the VSM with the upstream network. The default value is Ethernet 0 (eth0).

This example shows the primary and secondary VSMs with the n1kv-source defined as the Cisco PPA:

vsm-primary:
n1kv-source: deb xxxxx | xxxx (variable)
n1kv-vsm-domain-id: 500
n1kv-vsm-password: nexus123
n1kv-vsm-mgmt-ip: 192.168.10.1
n1kv-phy-intf-bridge: eth2
n1kv-vsm-mgmt-gateway: 192.168.10.2
n1kv-vsm-mgmt-netmask: 255.255.255.0
n1kv-vsm-role: primary
n1kv-vsm-name: vsm-p
vsm-secondary:
n1kv-source: deb xxxxx | xxxx (variable)
n1kv-vsm-domain-id: 500
n1kv-vsm-password: nexus123
n1kv-phy-intf-bridge: eth2
n1kv-vsm-role: secondary
n1kv-vsm-name: vsm-s

This example shows the primary and secondary VSM with the n1kv-source defined as an HTTP server:

vsm-primary:
n1kv-source: http://192.168.10.3/images/vsm-image-name.iso
n1kv-vsm-domain-id: 101
n1kv-vsm-password: nexus123
n1kv-vsm-name: vsm-primary
n1kv-vsm-role: primary
n1kv-vsm-ip: 192.168.10.4
n1kv-vsm-mgmt-netmask: 255.255.255.0
n1kv-mgmt-gateway: 192.168.10.5
.
.
.
vsm-secondary:
n1kv-source: http://192.168.10.6/images/vsm-image-name.iso
n1kv-vsm-domain-id: 101
n1kv-vsm-password: nexus123
n1kv-vsm-name: vsm-secondary
n1kv-vsm-role: secondary

.
.
.

Cisco Nexus 1000V for KVM VEM Charm Parameters

This table lists the Cisco Nexus 1000V for KVM VEM charm parameters. You define the parameters that will be the same among all of the VEMs in your network. For any parameters that you want to customize, you create a mapping file in YAML syntax in the MAAS node’s file system. In the mapping file, you configure a section for each node by using the host name ID, and you include any of the VEM configuration parameters listed in this table.

A typical usage for a custom mapping file is to configure certain nodes (for example, nova-compute or quantum-gateway nodes) with specific management or uplink interface settings. Another typical usage is to create VTEPs for VXLAN or VXLAN Gateway configurations on VEMs. If VTEPs are not configured using DHCP mode, the VTEPs need to be configured with static IP addresses using a custom mapping file.

Parameter

Description

n1kv-source: debian-pkg-location

Location of the Cisco Nexus 1000V for KVM VEM software.

The location that you define depends on whether you choose to have Juju download the VEM software (charm) automatically from the Cisco Personal Package Archive (PPA) or you choose to manually download the software from Cisco.com to a local HTTP server.

The VEM software is comprised of two Debian packages: a VEM DKMS package and a VEM data-path package. Juju downloads both automatically if you specify the Cisco PPA as the source. However, if you choose to manually download the software from Cisco.com, you must download both Debian packages.

For more information, see Downloading the Cisco Nexus 1000V Software.
Define the debian-pkg-location variable in one of the following two ways:

- Cisco PPA—n1kv-source:  ppa:cisco-n1kv/n1kv-updates

- Local HTTP server—http://server-address/VEM-DKMS.deb, http://server-address/VEM-DP.deb

vtep_config: virt port-name profile profile-name [mode static | dhcp [address ip-address]]

Virtual Tunnel Endpoint (VTEP) port configuration. Only static IP and MAC addresses are supported.

Note:
The port-name cannot exceed 11 alphanumeric characters. If it does, the VTEP does not come up.

n1kv-node_type: {compute | network}

Type of node that the VEM is intended to be installed on. The default value is compute.

n1kv-vtep_in_same_subnet: {yes | no}

Setting that indicates whether multiple VTEPs are located in the same subnet. The default value is no.

This example shows the VEM with the n1kv-source defined as the Cisco PPA:

vem:
n1kv-source:  ppa:cisco-n1kv/n1kv-updates
vtep_config:
node-type: network
vtep_in_same_subnet: yes
vtep_config:'virt vtep1-nw2 profile vxlan-vtep mode static address 192.168.10.2 netmask 255.255.0.0 mac 0e:1f:56:cf:82:53'
.
.
.

This example shows the VEM with the n1kv-source defined as an HTTP server:

vem:
n1kv-source: http://192.168.10.1/images/VEM-DKMS.deb, http://server-address/VEM-DP.deb
vtep_config:
node-type: network
vtep_in_same_subnet: yes
vtep_config:'virt vtep1-nw2 profile vxlan-vtep mode static address 192.168.10.2 netmask 255.255.0.0 mac 0e:1f:56:cf:82:53'
.
.
.

This example shows a mapping file with configuration parameters for two nodes. Each section is separated by the host name ID. Within each section, node-specific parameters are defined because they are different from the ones in the config.yaml file.

maas-node-6:
host_mgmt_intf: eth1
uplink_profile: phys eth2 profile sys-uplink
maas-node-11:
host-mgmt-intf: eth0
uplink_profile: phys eth3 profile sys-uplink
node_type: network
vtep_config:'virt vtep1-nw2 profile vxlan-vtep mode static address 6.0.8.253 netmask 255.255.0.0 mac 0e:1f:56:cf:82:53'

Cisco Nexus 1000V for KVM VXLAN Gateway Charm Parameters

For VXLAN Gateway, you need to define the source of the vxlan-gateway charm.

Note

The VXLAN Gateway feature has other configuration requirements, including the creation of VTEPs on the VEMs. You can use a common configuration for all VEMs if you use DHCP to assign IP addresses to all of the VTEPs, or you can use a mapping.yaml file. For more information about creating VTEPs using a mapping.yaml file, see Cisco Nexus 1000V for KVM VEM Charm Parameters.

The following table lists the Cisco Nexus 1000V for KVM VXLAN Gateway charm parameter that you need to define in the global configuration file.

Parameter

Description

n1kv-source: debian-pkg-location

Location of the VXLAN Gateway software. The location that you define depends on whether you choose to have Juju download the VXLAN Gateway software (charm) automatically from the Cisco Personal Package Archive (PPA) or you choose to manually download the software from Cisco.com to a local HTTP server. For more information, see Downloading the Cisco Nexus 1000V Software.

Define the debian-pkg-location variable in one of the following two ways:

- Cisco PPA—n1kv-source:  ppa:cisco-n1kv/n1kv-updates

- Local HTTP server—http://server-address/VXGW-image.qcow

This example shows the VXLAN Gateway with the n1kv-source defined as the Cisco PPA:

vxlan-gateway:
n1kv-source:  ppa:cisco-n1kv/n1kv-updates
.
.
.

This example shows the VXLAN Gateway with the n1kv-source defined as an HTTP server:

vxlan-gateway:
n1kv-source: https://192.168.10.1/images/VXGW-image.qcow
.
.
.

Chapter 4. Installing Cisco Nexus 1000V for KVM

This chapter contains the following sections:

- Steps to Install the Cisco Nexus 1000V for KVM

- Installing and Configuring MAAS

- Installing and Configuring Juju

- Installing and Configuring the OpenStack Services

- Verifying the Cisco Nexus Plug-in for OpenStack Neutron Version

- Installing and Configuring the Cisco Nexus 1000V for KVM

- Installing and Configuring the VXLAN Gateway Using Juju Charms

Steps to Install the Cisco Nexus 1000V for KVM

You can use the following high-level procedure to guide you through the installation process.

Before You Begin

- Decide on a deployment model. See Supported Topologies.

- Make sure that your network, servers, operating system, hypervisor, and MAAS deployment meet the minimum requirements. See System Requirements.

- Gather the required network information for the Juju configuration file (config.yaml file). See Canonical documentation at this URL: Click Here .

- Gather the required network information for the global configuration file. See Preparing the Configuration and Mapping Files.

- Gather any unique network information for the VEMs. See Mapping File Parameters.

Procedure

Command or Action

Purpose

Step 1

Install and configure MAAS.

See Installing and Configuring MAAS.

Step 2

Install and configure Juju.

See Installing and Configuring Juju.

Step 3

Install and configure the OpenStack services.

See Installing and Configuring the OpenStack Services.

Step 4

Verify that the correct version of the Cisco Nexus Plug-in for OpenStack Neutron was installed.

See Verifying the Cisco Nexus Plug-in for OpenStack Neutron Version

Step 5

Install and configure the Cisco Nexus 1000V for KVM.

See Installing and Configuring the Cisco Nexus 1000V for KVM.

Step 6

Install and configure the VXLAN Gateway.

(Optional)
See Installing and Configuring the VXLAN Gateway Using Juju Charms.

Installing and Configuring MAAS

You need to install and configure MAAS. For detailed information about this procedure, see the Canonical documentation at this URL: Click Here .

Procedure

Step 1

Install the following MAAS packages.

- maas

- maas-region-controller

- maas-cluster-controller

- maas-dhcp/maas-dns

Step 2

Set up the initial MAAS configuration:

1. Designate the MAAS server API URL.

2. Create a MAAS admin account.

3. Import the boot images (only necessary during the first time setup).

4. Configure DHCP.

5. Configure the immediate upstream switch to be in STP PortFast mode for fast convergence on ports in the forwarding state.

Installing and Configuring Juju

You need to install and configure Juju. For detailed information about this procedure, see the Canonical documentation at this URL Click Here .

The following procedure is required to deploy the Cisco Nexus 1000V for KVM.

Procedure

Step 1

Install a stable Juju-core.

Step 2

Synchronize the Juju cloud tool.

Step 3

Configure Juju.

1. Generate the Juju configuration file.

2. Customize the Juju configuration file in MAAS mode.

3. Create a MAAS bootstrap node.

Installing and Configuring the OpenStack Services

You install and configure the OpenStack services using the jujucharm-n1k Debian package that you get either from the Cisco PPA or the Juju Charm store.

For more details about this procedure, see the Canonical documentation at Click Here .

Before You Begin
Make sure that the virtual machines, physical servers, and/or local containers are set up based on your deployment model.

Make sure that you have defined the correct HTTP proxy as the http_proxy and https_proxy environment variables. The HTTP proxy is used if a firewall blocks web access.

Procedure

Step 1

Enter the following command: sudo -E add-apt-repository -y ppa:cisco-n1kv/icehouse-updates

Step 2

Enter the following command: sudo apt-get update

Step 3

Enter the following command:
Note:   All the charms are contained in the tar file brought in by the jujucharm-n1k.
sudo apt-get install jujucharm-n1k

Step 4

Enter the following command: tar zxf /opt/cisco/n1kv/charms/jujucharm-n1k-precise_5.2.1.sk3.1.1.YYYYMMDDhhmm.tar.gz

Step 5

Enter the following command: cd ./jujucharm-n1k/charms

Step 6

Deploy the OpenStack services.
Note:
The OpenStack charms in the jujucharm-n1k Debian package contain Cisco Nexus 1000V for KVM-specific changes and need to be installed locally. For information about installing these services, see Installing and Configuring the Cisco Nexus 1000V for KVM.

All other required OpenStack charms can be either downloaded locally from their respective bzr branches and deployed from the local repository or can be deployed directly from the Juju Charm store using the juju deploy --config config-file charm-name command.

juju deploy --config config-file --repository=. local:trusty/charm-name

Verifying the Cisco Nexus Plug-in for OpenStack Neutron Version

If you downloaded the Cisco Nexus 1000V for KVM software from the Cisco PPA, an issue exists where you might download an incompatible version of Cisco Nexus Plug-in for OpenStack Neutron.

Every 12 hours, the Cisco Nexus 1000V for KVM software version is checked, and if it is not the latest version, the latest version is reposted to the Cisco PPA. The reason that the version is checked is that the Debian packages for the Cisco Nexus 1000V include the version of OpenStack from the Ubuntu PPA, and whenever a new version of OpenStack is posted to the Ubuntu PPA, this version is used in the Cisco Nexus 1000V for KVM software Debian packages. This upstream version of OpenStack may contain an incompatible version of the Cisco Nexus Plug-in for OpenStack Neutron.

For the latest Cisco Nexus 1000V for KVM features to work properly, you must ensure that the latest version of the Cisco Nexus Plug-in for OpenStack Neutron is installed.

There are two ways that you can ensure that you have the latest version:

- Log into the nodes and check the Cisco Nexus Plug-in for OpenStack Neutron apt policy. Verify that the source of the installed version points to the Cisco PPA. This example shows that the correct version is installed. The Installed field shows 1:2014.1.1-0ubuntu2+springfieldv1407151351 as the image that is installed, and the Version table shows the source of that image is the Cisco PPA.

~$ sudo apt-cache policy neutron-server
neutron-server:
Installed: 1:2014.1.1-0ubuntu2+springfieldv1407151351
Candidate: 1:2014.1.1-0ubuntu2+springfieldv1407151351
Version table:
*** 1:2014.1.1-0ubuntu2+springfieldv1407151351 0
900 https://private-ppa.launchpad.net/springfield-team/icehouse-staging/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status
1:2014.1.1-0ubuntu2 0
500 http://archive.ubuntu.com//ubuntu/ trusty-updates/main amd64 Packages
1:2014.1-0ubuntu1.3 0
500 http://archive.ubuntu.com//ubuntu/ trusty-security/main amd64 Packages

- Add the following command to the late_commands in /etc/maas/preseed/generic and use default installer for MAAS deployment:

echo -en 'Package: *\nPin: release o=LP-PPA-cisco-n1kv-icehouse-updates\nPin-Priority: 900' > /target/etc/apt/preferences.d/n1kv-pin-900 && \

Installing and Configuring the Cisco Nexus 1000V for KVM

Perform this procedure to install and configure the Cisco Nexus 1000V for KVM on a physical server or as a VM. To deploy the Cisco Nexus 1000V for KVM on a Cisco Cloud Services Platform, see Installing VSM on the Cisco Nexus Cloud Services Platform.

Before You Begin
Make sure that you have defined the necessary parameters in the global configuration file and mapping file for your deployment.

Procedure

Step 1

Deploy the primary VSM. juju deploy –u --config config-file --repository=. local:trusty/vsm vsm-primary

Step 2

Deploy the secondary VSM. juju deploy –u --config config-file --repository=. local:trusty/vsm vsm-secondary

Step 3

Deploy VEMs.

1. juju deploy –u --config config-file --repository=. local:trusty/vem

2. juju add-relation nova-compute vem

3. juju add-relation vem vsm-primary

4. juju add-relation quantum-gateway vem

5. Optional: juju set vem mapping=$(cat mapping.yaml)

Installing and Configuring the VXLAN Gateway Using Juju Charms

The VXLAN Gateway is an optional addition to the Cisco Nexus 1000V for KVM deployment. If you want to deploy the VXLAN Gateway with the Cisco Nexus 1000V for KVM, you can use the VXLAN Gateway charm. For a complete, step-by-step procedure to install and configure the VXLAN Gateway, see Steps to Install and Configure VXLAN Gateway.

Before You Begin
Ensure that the deployment meets the minimum requirements. See Information About the VXLAN Gateway Deployment and Guidelines and Limitations for Cisco Nexus 1000V VXLAN Gateway.

If you are not using DHCP to configure IP addresses on the VTEPS, you must have configured static IP addresses on the VTEPs. To do this, you must have configured the vtep_config parameter in a custom mapping file for the VEM charm. For information, see Cisco Nexus 1000V for KVM VEM Charm Parameters.

You have created two port profiles on the switch (VSM): one for the uplinks on the gateway and one for the VTEP interface. For information, see Configuring a Port Profile for the Uplink on the VXLAN Gateway and Configuring a Port Profile for the VTEP on the VXLAN Gateway.

The source of the VXLAN Gateway image is configured in your VXLAN Gateway charm mapping.file. For information, see Cisco Nexus 1000V for KVM VXLAN Gateway Charm Parameters.

Ensure that the Nova cloud controller is started before deploying the VXLAN Gateway charm. To start the Nova cloud controller, use the juju status nova-cloud-controller command.

Procedure

Step 1

Deploy the VXLAN Gateway.

1. juju deploy –u --config config-file --repository=. local:trusty/vxlan-gateway

2. juju add-relation nova-cloud-controller vxlan-gateway

Step 2

Configure the VXLAN Gateway. You need to configure the data and management interfaces, high availability, and the VXLAN-to-VLAN mappings. For information, see Installing and Configuring the VXLAN Gateway.

Chapter 5. Installing VSM on the Cisco Nexus Cloud Services Platform

This chapter contains the following sections:

- Information About Installing a VSM on the Cisco Nexus Cloud Services Platform

- Installing a VSM on the Cisco Nexus Cloud Services Platform

Information About Installing a VSM on the Cisco Nexus Cloud Services Platform

If you choose to install a Virtual Supervisor Module (VSM) on the Cisco Nexus Cloud Services Platform, you must install all primary and secondary VSMs on the Cisco Nexus Cloud Services Platform. You cannot install any other VSMs as a VM.

Installing a VSM on the Cisco Nexus Cloud Services Platform

Before You Begin
Copy the VSM ISO or OVA file to the bootflash:repository/ of the Cisco Nexus Cloud Services Platform.

Procedure

Step 1

Create a virtual service blade.

switch(config)# show virtual-service-blade summary

---------------------------------------------------------------------------------
Name        HA-Role       HA-Status     Status               Location
---------------------------------------------------------------------------------
switch(config)# virtual-service-blade vsm-1
switch(config-vsb-config)# virtual-service-blade-type new nexus-1000v-dk9.5.2.1.SK3.1.2.iso
switch(config-vsb-config)# show virtual-service-blade summary

--------------------------------------------------------------------------------------
Name        HA-Role       HA-Status     Status                   Location
--------------------------------------------------------------------------------------
vsm-1       PRIMARY       NONE          VSB NOT PRESENT          PRIMARY
vsm-1       SECONDARY     NONE          VSB NOT PRESENT          SECONDARY

switch(config-vsb-config)#

Step 2

Configure the control, packet, and management interface VLANs for static and flexible topologies.

switch(config-vsb-config)# interface management vlan 100
switch(config-vsb-config)# interface control vlan 101
switch(config-vsb-config)# interface packet vlan 101

Step 3

Configure two vCPUs and the size of the RAM to 4 GB for the VSM.

switch(config-vsb-config)# ramsize 4096
switch(config-vsb-config)# numcpu 2

If desired, you can verify these settings with the following command:

switch(config-vsb-config)# show virtual-service-blade name vsm-1

Step 4

Configure the Cisco Nexus 1000V for KVM on the Cisco Nexus Cloud Services Platform.

switch(config-vsb-config)# enable
Enter vsb image: [nexus-1000v.4.2.1.SV2.2.1.iso]
Enter domain id[1-1023]: 127
Management IP version [V4/V6]: [V4]
Enter Management IP address: 192.0.2.79
Enter Management subnet mask: 255.255.255.0
IPv4 address of the default gateway: 192.0.2.1
Enter HostName: n1000v
Enter the password for ‘admin’: password
Note: VSB installation is in progress, please use show virtual-service-blade commands to check the installation status.
switch(config-vsb-config)#

Step 5

Display the primary and secondary VSM status.

switch(config-vsb-config)# show virtual-service-blade summary

--------------------------------------------------------------------------------------
Name        HA-Role       HA-Status     Status                   Location
--------------------------------------------------------------------------------------
vsm-1       PRIMARY       NONE          VSB POWER ON IN PROGRESS PRIMARY
vsm-1       SECONDARY     ACTIVE        VSB POWERED ON           SECONDARY

Step 6

Log in to the VSM.

switch(config)# virtual-service-blade vsm-1
switch(config-vsb-config)# login virtual-service-blade vsm-1
Telnet escape character is ‘^\’.
Trying 192.0.2.18...
Connected to 192.0.2.18.
Escape character is ‘^\’.

Nexus 1000v Switch
n1000v login: admin
Password:
Cisco Nexus operating System (NX-OS) Software
TAC support: http://www/cisco.com/tac
Copyright (c) 2002-2012, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
switch#

Step 7

Enable the following features in the VSM to ensure that OpenStack can configure the networks appropriately:

- http-server

- network-segmentation-manager

- segmentation

Chapter 6. Installing and Configuring the VXLAN Gateway

This chapter contains the following sections:

- Information About the VXLAN Gateway Deployment

- Guidelines and Limitations for Cisco Nexus 1000V VXLAN Gateway

- Steps to Install and Configure VXLAN Gateway

- Configuring Port Profiles on the VSM

- Managing the VXLAN-to-VLAN Mappings on the VXLAN Gateway

- Verifying the VXLAN Gateway Configuration

Information About the VXLAN Gateway Deployment

The Virtual Extensible Local Area Network (VXLAN) Gateway has the following deployment requirements:

- To configure the VXLAN Gateway, you must install the Advanced Edition license on the Cisco Nexus 1000V switch.

- You can only deploy the VXLAN Gateway as a VM. In this release of the Cisco Nexus 1000V for KVM, the VXLAN Gateway cannot be deployed on a Cisco Nexus Cloud Services Platform (Cisco Nexus 1010 or Cisco Nexus 1110 platforms).

- vCPU and memory requirements:

- Two vCPUs for each Virtual Machine (VM)

- 4-GB RAM

- 10-GB virutal disk space

- Network requirements:

- Management interface

- Gateway uplink interface

- VTEP interface

This figure shows the VXLAN Gateway deployment.

VXLAN Gateway Deployment on the Cloud Services Platform (CSP)

Guidelines and Limitations for Cisco Nexus 1000V VXLAN Gateway

VXLAN Gateways have the following configuration guidelines and limitations:

- You must configure the VSM to use the Layer 3 control. We strongly recommend that VSM Layer 3 control is through mgmt 0. For more information about Layer 3 control, see the Cisco Nexus 1000V System Management Configuration Guide.

- A single VSM can manage a maximum of eight VXLAN Gateway high availability (HA) clusters.

- You must configure the HA mode of the VXLAN Gateway as standalone or primary/secondary so that when you bring up the VXLAN Gateway, the HA state is either active or standby and the VXLAN-to-VLAN mappings are either active or pending. If you do not configure an HA role for the VXLAN Gateway, when you bring up the VXLAN Gateway, the HA state is unknown, and VXLAN-to-VLAN traffic is not processed.

- The VXLAN Gateway virtual machine (VM) uses two vCPUs; one vCPU for management traffic and one vCPU for the data interface.

Steps to Install and Configure VXLAN Gateway

There are several key steps to install and configure a VXLAN Gateway.

Procedure

Command or Action

Purpose

Step 1

Create two port profiles on the switch (VSM): one for the uplinks on the gateway and one for the VTEP interface.

See Configuring a Port Profile for the Uplink on the VXLAN Gateway and Configuring a Port Profile for the VTEP on the VXLAN Gateway.

Step 2

Deploy the VXLAN Gateway.

To deploy the VXLAN Gateway as a VM, see Installing the VXLAN Gateway as a VM Using Juju Charms.

Step 3

Create the VXLAN Gateway data and management interfaces.

Choose one of the following methods:

- Configuring the VXLAN Gateway Data and Management Interfaces Using OpenStack dashboard

- Configuring the VXLAN Gateway Data and Management Interfaces Using the OpenStack CLI

Step 4

Configure high availability on the VSMs. You must configure the HA mode of the VXLAN Gateway as standalone or primary/secondary so that when you bring up the VXLAN Gateway, the HA state is either active or standby and the VXLAN-to-VLAN mappings are either active or pending. If you do not configure an HA role for the VXLAN Gateway, when you bring up the VXLAN Gateway, the HA state is unknown, and VXLAN-to-VLAN traffic is not processed.

See Configuring the VXLAN Gateway HA Mode as Standalone.

Step 5

Set up the VXLAN-to-VLAN mappings on the VXLAN Gateway.

See Managing the VXLAN-to-VLAN Mappings on the VXLAN Gateway.

Step 6

Verify the VXLAN Gateway installation and configuration.

(Optional)
See Verifying the VXLAN Gateway Configuration.

Configuring Port Profiles on the VSM

You must create port profiles on the VSM before you can install and configure the VXLAN Gateway.

- Configuring a Port Profile for the Uplink on the VXLAN Gateway

- Configuring a Port Profile for the VTEP on the VXLAN Gateway

Configuring a Port Profile for the Uplink on the VXLAN Gateway

Before installing the VXLAN Gateway, you must create two port profiles on the switch (VSM), one for the uplinks on the gateway and one for the VXLAN Tunnel Endpoint (VTEP) interface.

Before You Begin

- Ensure that the VSM is configured in the Advanced mode by entering the svs switch edition advanced configuration command to enable Advanced mode.

- Ensure that the VXLAN feature is enabled on the VSM by entering the feature segmentation configuration command to enable VXLANs on the VSM.

- Ensure that the VXLAN Gateway is enabled on the VSM by entering the feature vxlan-gateway configuration command.

- Ensure that the interfaces of the upstream switch are configured with a matching port channel and VLAN trunk configuration.

Procedure

Command or Action

Purpose

Step 1

vsm# configure terminal

Enters global configuration mode.

Step 2

vsm# encapsulation profile segment name

Creates an encapsulation profile to contain the VLAN-to-VXLAN mappings.

Step 3

vsm(config-vxlan-encap-prof)# dot1q VLAN-ID bridge-domain bd-name

Maps a VLAN to a VXLAN. The VXLAN is specified through the bridge-domain name.

Note:
The bridge-domain name and VLAN-ID you provide are not created during the port-profile configuration. The bridge-domain name and the VLAN ID that you provide should be in an active state or the mapping is held in an inactive state until you create the bridge-domain name and VLAN ID.

Note:
Repeat this step to specify additional mappings.

Step 4

vsm(config)# port profile type ethernet name

Creates a port profile of type ethernet for the VXLAN Gateway uplink.

Note:
You must provide a port-profile name when prompted while executing the setup script to configure the VXLAN Gateway.

Step 5

vsm(config-port-prof)# switchport mode trunk

Designates that the interfaces are to be used as trunking ports. A trunk port transmits untagged packets for the native VLAN and transmits encapsulated, tagged packets for all other VLANs.

Step 6

vsm(config-port-prof)# switchport trunk allowed vlan vlan list

Specifies the list of VLANs allowed on the gateways uplink. This list should consist of all the mapped VLANs and the VLAN for the VTEP virtual interface.

Step 7

vsm(config-port-prof)# mtu mtu size in bytes

Designates the MTU size. For VXLAN traffic to be functional, you must set the MTU size as 1550. If you do not set the MTU size, the default of 1500 is used. The size must be an even number between 1500 and 9000. The MTU configured on an interface takes precedence over the MTU configured on a port profile.

Step 8

vsm(config-port-prof)# service instance 1-4096

(Optional)
Defines a place holder for mappings. The range is from 1 to 4096.

Note:
You do not need to execute the service instance and the encapsulation command at this stage to bring up the gateway. These commands are optional and you can add the mappings later once the port profiles are configured.

Step 9

vsm(config-port-prof-svc)#encapsulation profile name

Specifies the encapsulation profile for the port profile.

Step 10

vsm(config-port-prof-srv)# exit

(Optional)
Exits from the service instance mode.

Step 11

vsm(config-port-prof)# no shutdown

Administratively enables all ports in the profile.

Step 12

vsm(config-port-prof)# state enabled

Enables the port profile and applies its configuration to the assigned ports.

Step 13

vsm(config-port-prof)# publish port-profile

Publishes the port profile.

This example shows how to configure and display the gateway mappings:

vsm# configuration terminal
vsm(config)# port-profile type ethernet gw-uplink
vsm(config)# switchport mode trunk
vsm(config)# switchport trunk allowed vlan 1545
vsm(config)# mtu 1550
vsm(config-port-prof)# service instance 1
vsm(config-port-prof)# encapsulation profile gw_mappings
vsm(config-port-prof-srv)# encapsulation profile segment gw-segment
vsm(config-port-prof-srv)# encapsulation dot1q 753 bridge-domain bd-753
vsm(config-port-prof-srv)# exit
vsm(config-port-prof)# channel-group auto
vsm(config-port-prof)# no shutdown
vsm(config-port-prof)# state enabled
vsm(config-port-prof)# publish port-profile

Configuring a Port Profile for the VTEP on the VXLAN Gateway

You can create a port profile that can be applied to the VTEP virtual interface on the VXLAN Gateway.

Procedure

Command or Action

Purpose

Step 1

vsm# configure terminal

Enters global configuration mode.

Step 2

vsm(config) # port-profile type vethernet port-profile name

Configures a port profile for the VTEP on the VXLAN gateway.

Note:
You must provide a port profile name when prompted while executing the setup script to configure the VXLAN Gateway.

Step 3

vsm(config-port-prof) # switchport mode access

Designates that the interfaces are to be used as a trunking ports. A trunk port transmits untagged packets for the native VLAN and transmits encapsulated, tagged packets for all other VLANs.

Step 4

vsm(config-port-prof) # switchport access vlan vlan-id-access

Assigns an access VLAN ID to this port profile. The VLAN ID provided must be added to the allowed VLAN set of the uplink port profile. This VLAN should not be mapped to any VXLAN.

Note:
If you do not specify a VLAN ID, VLAN 1 is used automatically.

Step 5

vsm(config-port-prof ) # capability vxlan

Configures the capability VXLAN feature on the specified virtual ethernet port and enables encapsulation and decapsulation of VXLAN packets.

Step 6

vsm(config-port-prof) # transport ip address ip-address netmask network mask [gateway ip-address]

Configures the IP address, netmask, and gateway for the VTEP.
Note:
If you have VTEPs that are in different subnets, you must specify the gateway IP address. If a gateway is not provided, the VXLAN Gateway uses ARP to reach the remote VTEP.

Step 7

vsm(config-port-prof)# no shutdown

Administratively enables all ports in the profile.

Step 8

vsm(config-port-prof)# state enabled

Enables the port profile and applies its configuration to the assigned ports.

Step 9

vsm(config-port-prof)# publish port-profile

Publishes the port profile.

This example displays how to configure a VTEP on the VXLAN gateway:

vsm# configure terminal
vsm(config)# port-profile type vethernet gw-vtep
vsm(config-port-prof)# switchport mode access
vsm(config-port-prof)# switchport access vlan 760
vsm(config-port-prof)# capability vxlan
vsm(config-port-prof)# transport ip address 192.0.2.1 255.255.255.0 gateway 192.0.2.254
vsm(config-port-prof)# no shutdown
vsm(config-port-prof)# state enabled
vsm(config-port-prof)# publish port-profile

Installing the VXLAN Gateway as a VM Using Juju Charms

Before You Begin

- Ensure that the server on which you create the VXLAN Gateway VM meets the minimum requirements. See Networking Requirements and Networking Requirements.

- The source of the VXLAN Gateway image is configured in your VXLAN Gateway charm mapping.file. For information, see Cisco Nexus 1000V for KVM VXLAN Gateway Charm Parameters.

- You have created two port profiles on the switch (VSM): one for the uplinks on the gateway and one for the VTEP interface. For details, see Configuring a Port Profile for the Uplink on the VXLAN Gateway and Configuring a Port Profile for the VTEP on the VXLAN Gateway.

- If you are not using DHCP to configure IP addresses on the VTEPS, you must have configured static IP addresses on the VTEPs. To do this, you must have configured the vtep_config parameter in a custom mapping file for the VEM charm. For information, see Cisco Nexus 1000V for KVM VEM Charm Parameters.

Ensure that the Nova cloud controller is started before deploying the VXLAN Gateway charm. To start the Nova cloud controller, use the juju status nova-cloud-controller command.

Procedure

Step 1

Configure the source of the VXLAN Gateway image in your VXLAN Gateway charm mapping file.
For more information, see Cisco Nexus 1000V for KVM VXLAN Gateway Charm Parameters.

Step 2

Download the VXLAN Gateway software image VXGW-image.qcow.

Step 3

Deploy the VXLAN Gateway. juju deploy [config=config-file] [--to=destination] --repository=/opt/cisco/n1kv/charms/jujucharm-n1k/charms local:precise/vxlan-gateway

Step 4

Make sure the VXLAN Gateway image is present by entering the following OpenStack command: glance image-list

Configuring the VXLAN Gateway Data and Management Interfaces Using OpenStack dashboard

- Guidelines and Limitations for the OpenStack Dashboard

- Steps to Configure the VXLAN Gateway Interfaces Using the OpenStack Dashboard

- Creating a Trunk Network Profile Using OpenStack Dashboard

- Creating a VLAN Network Profile Using OpenStack Dashboard

- Creating a Network Using the OpenStack Dashboard

- Creating a Subnet for a Network Using the OpenStack Dashboard

- Booting a VXLAN Gateway VM

Guidelines and Limitations for the OpenStack Dashboard

The OpenStack dashboard has the following guidelines and limitations when you use it to create virtual networks for Cisco Nexus 1000V for KVM:

- Network profile creation by an administrator is not supported in Cisco Nexus 1000V for KVM Release 5.2(1)SK3(2.2) software and highter. Network profiles are automatically created for each network type.

- To create a network profile and associate it with a tenant, you must log in to the OpenStack dashboard as a user with admin privileges. Any user can use a network profile that is associated with a tenant.

- You cannot create policy profiles or assign them to a tenant in OpenStack dashboard. You must first create them as part of the port profiles in the VSM. The OpenStack dashboard retrieves them from the VSM and displays them on the Router dashboard.

- When there are multiple VSMs, the port profile must be configured on all the VSMs.

Steps to Configure the VXLAN Gateway Interfaces Using the OpenStack Dashboard

Before You Begin
Create one or more port profiles in the VSM. These port profiles are displayed as policy profiles in OpenStack dashboard. For more information, see Configuring a Port Profile for the Uplink on the VXLAN Gateway and Configuring a Port Profile for the VTEP on the VXLAN Gateway.

Procedure

Step 1

Create a network profile of type trunk.
See Creating a Trunk Network Profile Using OpenStack Dashboard.

Step 2

Create a network profile of type VLAN.
See Creating a VLAN Network Profile Using OpenStack Dashboard.

Step 3

Create one or more networks for the network profiles.
See Creating a Network Using the OpenStack Dashboard.

Step 4

Create a subnet for each network.
See Creating a Subnet for a Network Using the OpenStack Dashboard.

You do not need to create a port for the network. OpenStack dashboard creates a port for the network when you launch the instance.

Step 5

Create and launch the VM instance.
See Booting a VXLAN Gateway VM.

Creating a Trunk Network Profile Using OpenStack Dashboard

Before You Begin

- Create one or more policy profiles as part of the port profiles in the VSM.

- Create one or more tenants in OpenStack dashboard.

Procedure

Step 1

In the Navigation pane, click the Router dashboard.

Step 2

In the Cisco Nexus 1000v panel, click Create Network Profile.

Step 3

In the Create Network Profile dialog box, do the following:

1. In the Name field, enter a unique name for the network profile.
The name can have a maximum length of 255 characters and can contain uppercase or lowercase characters, numerals, and special characters such as an "at" sign (@), ampersand (&), and exclamation point (!).

2. From the Segment Type drop-down list, choose Trunk.

3. From the Sub Type drop-down list, choose VLAN.

4. From the Project multi-select list, choose one or more tenants that you want to associate with this network profile.

5. Click Create Network Profile.

OpenStack dashboard creates the network profile and then updates the OpenStack Neutron database and the VSM.

What to Do Next

Create one or more networks.

Creating a VLAN Network Profile Using OpenStack Dashboard

Before You Begin

- Create one or more policy profiles as part of the port profiles in the VSM.

- Create one or more tenants in OpenStack dashboard.

Procedure

Step 1

In the Navigation pane, click the Router dashboard.

Step 2

In the Cisco Nexus 1000v panel, click Create Network Profile.

Step 3

In the Create Network Profile dialog box, do the following:

1. In the Name field, enter a unique name for the network profile.
The name can have a maximum length of 255 characters and can contain uppercase or lowercase characters, numerals, and special characters such as an "at" sign (@), ampersand (&), and exclamation point (!).

2. From the Segment Type drop-down list, choose VLAN.
Separate the first and last segments in the range with a hyphen (-). For example, enter a range of 80-86. For a segment type of VLAN, the range can be from 1 to 3967 or from 4048 to 4093.

3. In the Segment Range field, enter the segment range for the network profile.
For example, enter a range of 80-86. For a segment type of VLAN, the range can be from 1 to 3967 or from 4048 to 4093.

4. In the Physical Network field, enter the name of the associated physical network.

5. From the Project multi-select list, choose one or more tenants that you want to associate with this network profile.

6. Click Create Network Profile.

OpenStack dashboard creates the network profile and then updates the OpenStack Neutron database and the VSM.

What to Do Next

Create one or more networks.

Creating a Network Using the OpenStack Dashboard

You must perform this procedure twice: once to create a network with the trunk network profile and again to create a network with the VLAN network profile.

Procedure

Step 1

In the Navigation pane, click Admin > Networks.

Step 2

In the Networks panel, click Create Network.

Step 3

In the Create Network dialog box, do the following:

1. In the Name field, enter a unique name for the network.
The name can have a maximum length of 255 characters and can contain uppercase or lowercase characters, numerals, and special characters such as an "at" sign (@), ampersand (&), and exclamation point (!).

2. From the Project drop-down list, choose a tenant that you want to associate with this network.
This tenant should be the same tenant that you use for the network profile.

3. Check the Admin State check box.
You can accept the defaults for the Shared check box and the External Network check box. By default, these check boxes are unchecked.

4. Click Create Network.

Step 4

For the VXLAN Gateway, perform this procedure again to create another network and choose the VLAN network profile that you already created.

What to Do Next

Create a subnet for the network.

Creating a Subnet for a Network Using the OpenStack Dashboard

You must perform this procedure twice: once to create a subnet in the trunk network that you already created and again to create a subnet in the VLAN network that you already created.

Note

Do not enable DHCP on these subnets.

Procedure

Step 1

In the Navigation pane, click Admin > Networks.

Step 2

In the Networks panel, click the network to which you want to add a subnet.
For the VXLAN Gateway, choose the trunk network that you already created.

Step 3

In the Create Subnet dialog box, click the Subnet tab an do the following:

1. In the Name field, enter a unique name for the subnet.
The name can have a maximum length of 255 characters and can contain uppercase or lowercase characters, numerals, and special characters such as an "at" sign (@), ampersand (&), and exclamation point (!).

2. In the Network Address field, enter the address for the subnet.
The subnet address must be in classless interdomain routing (CIDR) format. For example, 192.168.0.0/16.

3. From the IP Version drop-down list, choose IPv4.

4. Optional: In the Gateway IP field, enter a gateway IP address for the subnet.

Step 4

Optionally, click the Subnet Detail tab and do the following:

1. (Optional) Click the Enable DHCP checkbox.

2. Enter one or more allocation pools in the Allocation Pools text box.

3. Enter one or more name servers in the DNS Name Servers text box.

4. Enter one or more host routes in the Host Routes text box.

Step 5

Click Create to create the subnet.

Step 6

For the VXLAN Gateway, perform this procedure again to create another network and choose the VLAN network that you already created.

Booting a VXLAN Gateway VM

You must manually create the port IDs and launch the VM instance using OpenStack commands.

Procedure

Step 1

neutron port-create trunk-network-name --n1kv:profile_id VSM-policy-profile-id

Creates the trunk port ID for the VXLAN Gateway data interface.

Step 2

neutron port-create vxgw-mgmt-network-name --n1kv:profile_id VSM-policy-profile-id

Creates the management port ID for the VXLAN Gateway management interface.

Step 3

nova boot --image image_id --flavor 3 nic port-id= trunk_port-id nic port-id= access_port-id vxlan_gateway_name

Launches the VXLAN Gateway VM.

Note:   In this command, you must specify the first NIC as a trunk port and the second NIC as an access port.

Note:   You must specify flavor 3, because flavor 3 provides the two vCPUs that the VM requires.

Step 4

nova list

Lists the active servers.

Configuring the VXLAN Gateway Data and Management Interfaces Using the OpenStack CLI

- Steps to Configure the VXLAN Gateway Interfaces Using the OpenStack CLI

- Creating the VXLAN Gateway Data Interface

- Creating a VXLAN Gateway Management Interface

- Booting a VXLAN Gateway VM

- Example of VXLAN Gateway Interface Configuration

Steps to Configure the VXLAN Gateway Interfaces Using the OpenStack CLI

Before You Begin
Create one or more port profiles in the VSM. For more information, see Configuring a Port Profile for the Uplink on the VXLAN Gateway and Configuring a Port Profile for the VTEP on the VXLAN Gateway.

Procedure

Command or Action

Purpose

Step 1

If you have not already done so, log in to the OpenStack CLI as a user with admin privileges.

—

Step 2

Create the VXLAN Gateway data interface.

For details, see Creating the VXLAN Gateway Data Interface.

Step 3

Create theVXLAN Gateway management interface.

For details, see Creating a VXLAN Gateway Management Interface.

Step 4

Boot the VXLAN Gateway VM.

For details, see Booting a VXLAN Gateway VM.

Creating the VXLAN Gateway Data Interface

Procedure

Command or Action

Purpose

Step 1

neutron net-create network_name

Creates a network using the network profile.

Step 2

neutron subnet-create network_name cidr_blocks --name subnet_name --disable-dhcp

Creates a subnet for the network profile.

Note:   Although you configure the VXLAN Gateway data interface manually, the create-subnet command still requires that you specify an IP address block. However, this value is not used and is ignored.

Step 3

neutron cisco-policy-profile-list

Lists the policy profiles available in neutron.

Step 4

neutron port-create network_name n1kv:profile cisco_policy_profile_id

Creates a trunk port. For network_name, specify the name of the network that you created in Step 3. For cisco_policy_profile_id, specify the profile with the mode trunk from the list of available profiles obtained in Step 3.

Note:   To create a second instance of the VXLAN Gateway virtual machine (for example, for an HA pair), perform this step again.

Creating a VXLAN Gateway Management Interface

Procedure

Command or Action

Purpose

Step 1

neutron net-create network_name

Creates an access network.

Step 2

neutron subnet-create network_name cidr_blocks --name subnet_name

Creates a subnet for the access network segment profile.

Step 3

neutron cisco-policy-profile-list

Lists the policy profiles available in Neutron.

Step 4

neutron port-create network_name n1kv:profile cisco_policy_profile_id

Creates an access port. Use a Cisco policy profile ID from the list of available profiles listed in Step 5.

Booting a VXLAN Gateway VM

You must manually launch a VM instance using the OpenStack CLI.

Procedure

Command or Action

Purpose

Step 1

Launch the VXLAN Gateway VM.

nova boot --image image_id --flavor 3 --nic port-id= trunk_port-id --nic port-id= access_port-id vxlan_gateway_name
Note:   In this command, you must specify the first NIC as a trunk port and the second NIC as an access port. Also, you must specify flavor 3 (m1.medium), because flavor 3 provides the two vCPUs that the VM requires.

Step 2

List the active servers.

nova list

Example of VXLAN Gateway Interface Configuration

This example shows how to configure a VXLAN Gateway VM with a trunk network profile named aug-net and a VLAN network profile named test-2.

root@server:~# neutron cisco-credential-create 172.23.181.101 n1kv --tenant-id 1234-1234-1234-1234 --user_name admin --password mypwd
root@server:~# neutron cisco-network-profile-create aug-net-prof trunk sub_type vlan
root@server:~# neutron net-create aug-net --n1kv:profile_id 999e6dc-7a55-4c4a-839e-9aa22957ba99
root@server:~# neutron subnet-create aug-net 110.10.10.0/24 --name augsubnet --disable-dhcp
root@server:~# neutron cisco-policy-profile-list
+--------------------------------------+---------------+
| id                                   | name          |
+--------------------------------------+---------------+
| 0dc6bb6d-2929-466f-abed-6e4c0f25c3be | test-prof     |
| 4c4455e5-95d6-4185-80a1-a028e27fc8bd | trk-policy    |
| 63964f53-178c-440a-8f09-301ce021498d | acc-policy    |
| 652fbfd7-0c40-41d0-bc34-5a0fda4b2ca7 | dhcp_pp       |
| 964fb14c-59cc-48d4-a4d4-abc52965fb7c | q-n1kv-policy |
+--------------------------------------+---------------+
root@server:~# neutron port-create aug-net --n1kv:profile_id 4c4455e5-95d6-4185-80a1-a028e27fc8bd
root@server:~# neutron cisco-network-profile-create test2 vlan --segment_range 400-499 --physical_network q-n1k
root@server:~# neutron net-create q-n1k --n1kv:profile_id 2e464910-f452-4865-9793-6bd70a4c0cf6
root@server:~# neutron subnet-create q-n1k 110.10.10.0/24 --name q-110.10.10.0/24
root@server:~# neutron cisco-policy-profile-list
+--------------------------------------+---------------------------+
| id                                   | name                      |
+--------------------------------------+---------------------------+
| 5cdd9b93-c109-4455-a740-746a9d59c340 | NSM_template_vlan         |
| 691b2497-b435-495a-b140-e3ebe0835e75 | test-2                    |
| 7fc8d34b-cadd-4ca0-a85c-e18aecedd308 | NSM_template_segmentation |
| 83cc0410-7781-42b5-abb1-3b00921bfcc5 | test-1                    |
+--------------------------------------+---------------------------+
root@server:~# neutron port-create q-n1k --n1kv:profile_id 99cc0410-7781-42b5-abb1-3b00921bfcc5
root@server:~# nova boot --image vxlan-gateway --flavor 3 --nic port-id=d341926c-21ca-48cd-ae18-c51f899f6d3f
root@server:~#

VXLAN Gateway and High Availability

The operation of high availability (HA) involves the following terminology:

- Cluster—A cluster is a pair of gateway modules that operate together as a single HA module. Each cluster is distinguished by a unique cluster ID. A gateway module that is deployed in a standalone mode of operation is assigned a dummy cluster ID of 0.

- HA role—The gateway modules that make up an HA cluster are assigned separate roles. One is designated as primary and the other as secondary. This role decides which of the two modules goes to active state first and which stays in a standby state. These states persist until the active module fails. In the event of any failure in the active gateway module, the standby gateway module detects the failure and moves to the active state. This way, one of the two modules is always providing active service.

- HA state— At any given time, only one gateway module from a given cluster is actively performing the gateway function. The other module stays in the standby state pending the failure of the active module. A gateway module can be in the active or standby state. In addition, there is a transient initial state called the Init state. In this state, a gateway is either waiting to be assigned a role or negotiating its state with its peer.

After a gateway module is installed and brought up, the VSM assigns a role to the gateway module and can result in one of the following transitions:

- Unconfigured-Init to Standalone-Active

- Unconfigured-Init to Primary-Active

- Unconfigured-Init to Secondary-Standby

- Standalone-Active to Primary-Active

- Standalone-Active to Secondary-Active

For all other combinations, we recommend that you first fall back to the Unconfigured-Init mode by using the no service VXLAN Gateway module command and then proceed to the desired role or states.

Note

Roles must be preassigned to module numbers in the VSM. When a VXLAN gateway is attached to the VSM on that module, it inherits the role and state that are assigned by the VSM.

You must configure the HA mode of the VXLAN Gateway as standalone or primary/secondary so that when you bring up the VXLAN Gateway, the HA state is either active or standby and the VXLAN-to-VLAN mappings are either active or pending. If you do not configure an HA role for the VXLAN Gateway, when you bring up the VXLAN Gateway, the HA state is unknown, and VXLAN-to-VLAN traffic is not processed.

Configuring the VXLAN Gateway HA Mode as Standalone

You can create a service module in a standalone mode. Perform these steps on the VSM.

Before You Begin
Roles must be preassigned to module numbers in the VSM. When a VXLAN gateway is attached to the VSM on that module, it inherits the role and state that are assigned by the VSM.

Procedure

Command or Action

Purpose

Step 1

vsm(config)# service mod role standalone

Configures the service module as standalone active.

Step 2

vsm(config)# show module service

Displays the service module number, cluster ID, role, HA mode, and status.

This example shows how to display the cluster ID mapping and the details about active, standby, and standalone service modules:

vsm(config)# show module service
Mod  Cluster-id  Role            HA Mode       Status
---  ----------  -----------     ----------    -------
36        0      Standalone      Standalone    Active

Configuring the VXLAN Gateway as an HA Pair

You can create a service module as a HA pair. Perform these steps on the VSM.

Before You Begin
You must create a second instance of the VXLAN Gateway VM.

Procedure

Command or Action

Purpose

Step 1

vsm(config)# service modNo1 role primary ha-cluster clusterNo

Configures the service module in HA and adds a primary service module to a cluster.

Step 2

vsm(config)# service modNo2 role secondary ha-cluster clusterNo

Configures another service module as secondary in the same cluster.

Step 3

vsm(config)# show module service-module

Displays the service module number, cluster ID, role, HA mode, and status.

This example shows how to display the cluster ID mapping and the details about active, standby, and standalone service modules:

vsm(config)# show module service
Mod  Cluster-id  Role        HA Mode    Status
--- ---------- ----------- ---------- -------
9    1        Primary          HA       Active
10   1        Secondary        HA       Standby

To switch over between the active and standby VXLAN gateway, enter the following command on the VSM:

vsm# service ha-cluster <1-8> switchover

Managing the VXLAN-to-VLAN Mappings on the VXLAN Gateway

The VLAN-to-VXLAN mappings that are configured on a gateway module can be managed by editing the port profile applied on the gateway uplink modules. To add or remove a mapping, perform these steps on the VSM.

Procedure

Command or Action

Purpose

Step 1

vsm# configure terminal

Enters global configuration mode.

Step 2

vsm(config)# encapsulation profile segment name

Creates an encapsulation profile to contain the VLAN-to-VXLAN mappings.

Step 3

vsm(config-vxlan-encap-prof)# dot1q VLAN-ID bridge-domain bd-name

Maps a VLAN to a VXLAN. The VXLAN is specified through the bridge-domain name.

Note:
The bridge-domain name and VLAN ID that you provide are not created during the port-profile configuration. The bridge-domain name and the VLAN ID that you provide should be in an active state or the mapping is held in an inactive state until you create the bridge-domain name and VLAN ID.

Note:
Repeat this step to specify additional mappings.

Note:   To remove a mapping, use the no form of this command.

Step 4

vsm(config-vxlan-encap-prof)# exit

Exits the current configuration mode.

Step 5

vsm(config)# port-profile port-profile-name

Specifies the name of the port-profile applied to the VXLAN Gateway uplink interface.

Step 6

vsm(config-port-prof)# service instance 1 to 4096

Defines a place holder for mappings. The range is from 1 to 4096.

Note:
Port profiles that contain the service instance keyword cannot be used for a non-VXLAN gateway module.

Step 7

vsm(config-port-prof-srv)# encapsulation profile name

Assigns the specified encapsulation profile to the port profile.

Step 8

vsm(config-port-prof-srv)# copy running-config startup-config

Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to configure VXLAN-to-VLAN mappings on the VXLAN gateway:

vsm# configure terminal
vsm(config)# encapsulation profile segment mgmt_mappings
vsm(config-vxlan-encap-prof)# dot1q 1555 bridge-domain vxlan6000
vsm(config-vxlan-encap-prof)# dot1q 1557 bridge-domain vxlan6002
vsm(config-vxlan-encap-prof)# dot1q 1558 bridge-domain vxlan6003
vsm(config-vxlan-encap-prof)# dot1q 1559 bridge-domain vxlan6004
vsm(config-vxlan-encap-prof)# exit
vsm(config)# port-profile Uplink-All-VXGW
vsm(config-port-prof)# service instance 2
vsm(config-port-prof)# encapsulation profile mgmt_mappings
vsm(config-prot-prof-srv)# copy running-config startup-config

vsm(config)# show run port-profile Uplink-All-VXGW
port-profile type ethernet Uplink-All-VXGW
switchport mode trunk
switchport trunk allowed vlan 1545-1575,1577-1605
mtu 1550
service instance 2
encapsulation dot1q 1555 bridge-domain vxlan6000
encapsulation dot1q 1557 bridge-domain vxlan6002
encapsulation dot1q 1558 bridge-domain vxlan6003
encapsulation dot1q 1559 bridge-domain vxlan6004
no shutdown
state enabled

vsm(config)# show port-profile usage
port-profile Uplink-All-VXGW
port-channel1
port-channel5
Ethernet7/1
Ethernet7/3

vsm(config)# show run interface ethernet 7/1 expand-port-profile
interface Ethernet7/1
switchport mode trunk
switchport trunk allowed vlan 1545-1575,1577-1605
mtu 1550
channel-group auto mode active
service instance 2
no shutdown
encapsulation dot1q 1557 bridge-domain vxlan6002
encapsulation dot1q 1555 bridge-domain vxlan6000
encapsulation dot1q 1558 bridge-domain vxlan6003
no shutdown

Verifying the VXLAN Gateway Configuration

To display the VXLAN gateway (GW) installation and configuration information, perform one of the following tasks on the VSM:

Command

Purpose

show running-config port-profile gw-uplink

Displays the configuration of the port profile assigned to the VXLAN gateway uplinks.

show running-config port-profile gw-vtep

Displays the configuration of the port profile assigned to the VXLAN VTEP.

show module

Displays the VXLAN gateway service modules.

show module service

Verifies the role of the VXLAN gateway module and displays the cluster ID mapping and the details about active, standby, and standalone service modules.

show vxlan gateway interface

Displays if the VTEPs are configured properly.

show interface vethernet 6

Displays if both the VTEP Virtual Ethernet interfaces are in up state.

show port-channel summary

Displays if the port channels are up for gateway service modules.

show bridge-domain mappings

Displays VXLAN gateway mappings.

show switch edition

Displays if the VSM is in Advanced mode.

show feature

Displays if the VXLAN gateway is enabled on the VSM.

show virtual-service-blade summary
Note:
You must enter this command from the Cloud Services Platform.

Displays the status of the VXLAN gateway VSB as it transitions from the VSB DEPLOY IN PROGRESS to VSB POWERED ON.

show virtual-service-blade

Note:
You must enter this command from the Cloud Services Platform.

Displays the VXLAN Gateway configuration.

show encapsulation profile

Displays the VLAN-to-VXLAN mappings for all encapsulation profiles or for the specified encapsulation profile.

This example shows how to display the status of the VXLAN gateway VSB:

CSP# show virtual-service-blade summary

-------------------------------------------------------------------------------
Name                HA-Role     HA-Status   Status                   Location
-------------------------------------------------------------------------------
VXLAN-GW            PRIMARY     ACTIVE      VSB POWERED ON           PRIMARY
VXLAN-GW            SECONDARY   ACTIVE      VSB POWERED ON           SECONDARY

This example shows how to display the VXLAN gateway configuration:

CSP# show virtual-service-blade
virtual-service-blade VXLAN-GW
Description:
Slot id:        1
Host Name:      VXLAN-GW-DOCS
Management IP:  192.168.1.104
VSB Type Name :  vx-gw-1.5
Configured vCPU:           3
Operational vCPU:           3
Configured Ramsize:        2048
Operational Ramsize:        2048
Disksize:       3
Heartbeat:      154764

Legends:   P -  Passthrough
--------------------------------------------------------------------------
Interface           Type         MAC     VLAN    State   Uplink-Int
Pri  Sec Oper  Adm
--------------------------------------------------------------------------
VsbEthernet1/1  gw-uplink1 0002.3d71.a303        up   up Gi3(P) Gi3(P)
VsbEthernet1/2  management 0002.3d71.a302  751   up   up Gi1    Gi1
VsbEthernet1/3  gw-uplink2 0002.3d71.a304        up   up Gi4(P) Gi4(P)
internal          NA        NA       NA    up   up
HA Role: Primary
HA Status: ACTIVE
Status:       VSB POWERED ON
Location:     PRIMARY
SW version:
HA Role: Secondary
HA Status: ACTIVE
Status:       VSB POWERED ON
Location:     SECONDARY
SW version:
VSB Info:
Domain ID : 405

This example shows how to display the port-profile configuration assigned to the VXLAN Gateway uplinks:

vsm# show running-config port-profile gw-uplink

port-profile type ethernet gw-uplink
switchport mode trunk
switchport trunk allowed vlan 1,81,751-760
mtu 1550
channel-group auto mode active
no shutdown
state enabled

This example shows how to display the port-profile configuration assigned to the VXLAN VTEP:

vsm# show running-config port-profile gw-vtep

port-profile type vethernet gw-vtep
switchport mode access
switchport access vlan 760
capability vxlan
transport ip address 182.168.1.253 255.255.255.0 gateway 182.168.1.1
no shutdown
state enabled

This example shows how to display the VXLAN Gateway service modules as soon as they are online:

vsm# show module
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          ha-standby
2    0      Virtual Supervisor Module         Nexus1000V          active *
11   332    Virtual Ethernet Module           NA                  ok
18   332    Virtual Ethernet Module           NA                  ok
20   13     Virtual Service Module            VXLAN Gateway       ok
21   13     Virtual Service Module            VXLAN Gateway       ok
22   13     Virtual Service Module            VXLAN Gateway       ok

Mod  Sw                  Hw
---  ------------------  ------------------------------------------------
1    5.2(1)SK1(2.1)      0.0
2    5.2(1)SK1(2.1)      0.0
11   5.2(1)SK1(2.1)      Linux 3.2.0-23-generic
18   5.2(1)SK1(2.1)      Linux 3.8.0-29-generic
20   5.2(1)SK1(2.1)      Linux 2.6.27.10
21   5.2(1)SK1(2.1)      Linux 2.6.27.10
22   5.2(1)SK1(2.1)      Linux 2.6.27.10

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    192.0.2.166      NA                                    NA
2    192.0.2.166      NA                                    NA
11   192.0.2.147      47DE0F4A-8072-0E4D-A218-84A2C058FF3C  vxlan-gw-ubuntu
18   192.0.2.54       EE04B285-6BA6-5642-AC8E-EDB12D07811B  vxlan-gw-ubuntu2
20   192.0.2.90       7a4f6171-3235-4fd2-9797-80149df55171  ab-vxgw-1110
21   192.0.2.53       48ad3898-401f-4377-8de1-dcfa22df78ec  VxLanGW
22   192.0.2.55       5a996a7e-fa85-4630-89e5-18a3a3b413b8  VxLanGW
* this terminal session

This example shows how to display the cluster ID mapping and the details about active, standby, and standalone service modules:

vsm# show module service
Mod  Cluster-id  Role        HA Mode    Status
--- ---------- ----------- ---------- -------
9    1        Primary          HA       Active
10   1        Secondary        HA       Standby

This example shows how to display the module for virtual Ethernet interface binding:

vsm(config-if)# show vxlan gateway interface
-----------------------------------------------------------------
Port     IPAddress     Netmask     Gateway Mod Status Role
-----------------------------------------------------------------
Veth6     192.0.2.253  255.255.255.0    192.168.1.1 9     up Active
Veth22     192.0.2.253  255.255.255.0    192.168.1.1 10  up Standby

This example shows how to display whether both the VTEP virtual Ethernet interfaces are in up state:

vsm# show interface vethernet 6
Vethernet6 is up
Port description is VXLANGW VTEP, Network Adapter 1
Hardware: Virtual, address: 0002.3d71.a303 (bia 0002.3d71.a303)
Owner is VM "VXLANGW VTEP", adapter is Network Adapter 1
Active on module 9
Port-Profile is gw-vtep
Port mode is access
5 minute input rate 8 bits/second, 0 packets/second
5 minute output rate 0 bits/second, 0 packets/second
Rx
6 Input Packets 6 Unicast Packets
0 Multicast Packets 588 Broadcast Packets
468 Bytes
Tx
34321 Output Packets 34321 Unicast Packets
33609 Multicast Packets 24 Broadcast Packets 33633 Flood Packets
2193700 Bytes
0 Input Packet Drops 0 Output Packet Drops

vsm# show interface vethernet 22
Vethernet22 is up
Port description is VXLANGW VTEP, Network Adapter 1
Hardware: Virtual, address: 0002.3d71.a383 (bia 0002.3d71.a383)
Owner is VM "VXLANGW VTEP", adapter is Network Adapter 1
Active on module 10
Port-Profile is gw-vtep
Port mode is access
5 minute input rate 8 bits/second, 0 packets/second
5 minute output rate 0 bits/second, 0 packets/second
Rx
6 Input Packets 6 Unicast Packets
0 Multicast Packets 25 Broadcast Packets
468 Bytes
Tx
33742 Output Packets 33742 Unicast Packets
33609 Multicast Packets 133 Broadcast Packets 33742 Flood Packets
2158956 Bytes
0 Input Packet Drops 0 Output Packet Drops

This example shows how to display whether the port channels are up for VXLAN Gateway service modules:

vsm# show port-channel summary
Flags:  D - Down        P - Up in port-channel (members)
I - Individual  H - Hot-standby (LACP only)
s - Suspended   r - Module-removed
S - Switched    R - Routed
U - Up (port-channel)
--------------------------------------------------------------------------------
Group Port-       Type     Protocol  Member Ports
Channel
--------------------------------------------------------------------------------
1     Po1(SU)     Eth      NONE      Eth3/3(P)    Eth3/4(P)    Eth3/5(P)
Eth3/6(P)
2     Po2(SU)     Eth      NONE      Eth4/3(P)    Eth4/4(P)    Eth4/5(P)
Eth4/6(P)
3     Po3(SU)     Eth      NONE      Eth5/3(P)    Eth5/4(P)    Eth5/5(P)
Eth5/6(P)
4     Po4(SU)     Eth      NONE      Eth6/3(P)    Eth6/4(P)    Eth6/5(P)
Eth6/6(P)
5     Po5(SU)     Eth      NONE      Eth7/3(P)    Eth7/4(P)    Eth7/5(P)
Eth7/6(P)
6     Po6(SU)     Eth      NONE      Eth8/4(P)
7     Po7(SU)     Eth      LACP      Eth9/1(P)    Eth9/3(P)
8     Po8(SU)     Eth      LACP      Eth10/1(P)   Eth10/3(P)

This example shows how to display VXLAN Gateway mappings:

vsm# show bridge-domain mappings
-------------------------------------------------------------------------------
Interface       Module  Serv Inst  Vlan  BD-Name
-------------------------------------------------------------------------------
port-channel7   9       753        753   bd-753
port-channel8   10      753        753   bd-753

This example shows how to display the IP address for module binding:

vsm(config-if)# show module service mgmt-int
--------------------------------------------------------------------------------
Mod Interface-Name IP-address Speed MTU
--------------------------------------------------------------------------------
4 Mgmt0 10.10.10.2             0     0
5 Mgmt0 10.10.10.3             0     0
Remember the management IP address user installs gateway with
(in this example 10.10.10.2, which occupies module slot 4)

This example shows how to display whether the VSM is in Advanced mode:

vsm# show switch edition
Switch Edition: Advanced

Advanced Features
Feature Name    Feature State
-----------------------------
vxlan-gateway   enabled

Licenses Available: 1020
Licenses In Use: 4
License Expiry Date: 13 Jun 2013

This example shows how to display whether the VXLAN Gateway is enabled on the VSM:

vsm# show feature
Feature Name          Instance  State
--------------------  --------  --------
cts                   1         enabled
dhcp-snooping         1         enabled
http-server           1         enabled
lacp                  1         enabled
netflow               1         disabled
network-segmentation  1         enabled
port-profile-roles    1         disabled
private-vlan          1         disabled
segmentation          1         enabled
sshServer             1         enabled
tacacs                1         disabled
telnetServer          1         disabled
vtracker              1         enabled
vxlan-gateway         1         enabled

Perform one of the following tasks on the VXLAN Gateway. If your VSM is on Layer 3 through management and your gateway is also on the same management subnet, use the attach module service module number command to acces the gateway CLI. If your VSM is on Layer 3 through control, you can access the gateway CLI from any machine on that control subnet. This example shows the VSM which is on Layer 3 control.

Command

Purpose

show redundancy config

Displays the high availability status.

This example shows how to display the HA status:

gw# show redundancy config

HA Manager Node Information:

Cluster Node Count: 2

Local Node:
state          : Active
HA mode        : High Availability
uuid           : 56fa6753-4dc5-4a7d-ad07-cc817114f838
cluster_id     : 1
node_priority  : 2
node_type      : VXLAN Gateway
ipaddr [mgmt]  : 192.168.1.104

Peer Node 1:
state          : Standby
uuid           : 4cbd05df-b3e5-468a-9497-89aa3fae8153
node_type      : VXLAN Gateway
ipaddr [mgmt]  : 192.168.1.105

This example shows how to display the VLAN-to-VXLAN mappings for all encapsulation profiles:

gw# show encapsulation profile

-------------------------------------------------------------------------------
Vlan Bridge-domain
-------------------------------------------------------------------------------
2100 segment5050
2055 segment5031
2056 segment5032
2057 segment5033
2058 segment5034

Appendix A. Sample Global Configuration File

This appendix contains the following section:

- Sample Global Configuration File

Sample Global Configuration File

quantum-gateway:
plugin: n1kv
ext-port: eth1
openstack-origin:  ppa:cisco-n1kv/icehouse-updates
nova-cloud-controller:
network-manager: Neutron
openstack-origin:  ppa:cisco-n1kv/icehouse-updates
quantum-plugin: n1kv
n1kv-vsm-username: admin
n1kv-vsm-password: Abc123
n1kv-vsm-ip: 192.0.2.164
config-flags: instance_name_template='%(user_id)s-%(display_name)s’
Glance:
openstack-origin: distro
Keystone:
admin-password: openstack
openstack-origin: distro
nova-compute:
enable-live-migration: True
migration-auth-type: none
openstack-origin:  ppa:cisco-n1kv/icehouse-updates
virt-type: kvm
config-flags: auto_assign_floating_ip=True,compute_driver=libvirt.LibvirtDriver,instance_name_template='%(user_id)s-%(display_name)s’
openstack-dashboard:
openstack-origin:  ppa:cisco-n1kv/icehouse-updates
profile: cisco
Vem:
n1kv-source:  ppa:cisco-n1kv/n1kv-updates
n1kv-vsm-ip: 192.0.2.164
n1kv-vsm-domain-id: 500
uplink_profile: phys eth1 profile sys-uplink
host_mgmt_intf: br0
vxlan-gateway:
n1kv-source:  ppa:cisco-n1kv/n1kv-updates
vsm-p:
n1kv-source:  ppa:cisco-n1kv/n1kv-updates
n1kv-vsm-domain-id: 500
n1kv-vsm-password: Abc123
n1kv-vsm-mgmt-ip: 192.0.2.164
n1kv-phy-intf-bridge: eth2
n1kv-vsm-mgmt-gateway: 192.0.2.161
n1kv-vsm-mgmt-netmask: 255.255.255.224
n1kv-vsm-role: primary
n1kv-vsm-name: vsm-p
vsm-s:
n1kv-source:  ppa:cisco-n1kv/n1kv-updates
n1kv-vsm-domain-id: 500
n1kv-vsm-password: Abc123
n1kv-phy-intf-bridge: eth2
n1kv-vsm-role: secondary
n1kv-vsm-name: vsm-s

Appendix B. Setup Script

This appendix contains the following section:

- Setup Script

Setup Script

You can use the following setup script to deploy a small Cisco Nexus 1000V for KVM with OpenStack environment for testing purposes.

#Deploy Openstack Services
juju deploy mysql
juju deploy rabbitmq-server
juju deploy --config ./openstack.yaml keystone
juju deploy  --config ./openstack.yaml --repository=. local:trusty/nova-cloud-controller
juju deploy  --config ./openstack.yaml  glance
juju deploy  --config ./openstack.yaml --repository=. local:trusty/openstack-dashboard
juju deploy --config ./openstack.yaml --repository=. local:trusty/nova-compute -n 2
juju deploy --config ./openstack.yaml --repository=. local:trusty/quantum-gateway
# Deploy VEM
juju deploy  --config ./openstack.yaml --repository=. local:trusty/vem
#Deploy VXGW
juju deploy  --config ./openstack.yaml --repository=. local:trusty/vxlan-gateway
#Deploy VSM HA
juju deploy  --config ./openstack.yaml --repository=. local:trusty/vsm vsm-p
juju deploy  --config ./openstack.yaml --repository=. local:trusty/vsm vsm-s

#ADDING RELATIONS
juju add-relation keystone mysql
juju add-relation nova-cloud-controller mysql
juju add-relation nova-cloud-controller rabbitmq-server
juju add-relation nova-cloud-controller glance
juju add-relation nova-cloud-controller keystone
juju add-relation nova-compute mysql
juju add-relation nova-compute:amqp rabbitmq-server:amqp
juju add-relation nova-compute glance
juju add-relation nova-compute nova-cloud-controller
juju add-relation glance mysql
juju add-relation glance keystone
juju add-relation openstack-dashboard keystone
juju add-relation quantum-gateway mysqljuju add-relation quantum-gateway nova-cloud-controller
juju add-relation quantum-gateway rabbitmq-server
# VEM is a subordinate charm so we need to add relation to deplOy the VEM on compute and network nodes
juju add-relation nova-compute vem
juju add-relation quantum-gateway vem
juju add-relation nova-cloud-controller vxlan-gateway

Preface

The Preface contains the following sections:

- Audience

- Document Conventions

- Related Documentation for Cisco Nexus 1000V for KVM Software

- Related Documentation for Cisco Nexus Cloud Services Platform

- Documentation Feedback

- Obtaining Documentation and Submitting a Service Request

Audience

This publication is for network administrators who configure and maintain Cisco Nexus devices.

This guide is for network and server administrators with the following experience and knowledge:

- An understanding of virtualization

- An understanding of the corresponding hypervisor management software for your switch, such as VMware vSwitch, Microsoft System Center Virtual Machine Manager (SCVMM), or OpenStack.

Document Conventions

Command descriptions use the following conventions:

Convention

Description

bold

Bold text indicates the commands and keywords that you enter literally as shown.

Italic

Italic text indicates arguments for which the user supplies the values.

[x]

Square brackets enclose an optional element (keyword or argument).

[x | y]

Square brackets enclosing keywords or arguments separated by a vertical bar indicate an optional choice.

{x | y}

Braces enclosing keywords or arguments separated by a vertical bar indicate a required choice.

[x {y | z}]

Nested set of square brackets or braces indicate optional or required choices within optional or required elements. Braces and a vertical bar within square brackets indicate a required choice within an optional element.

variable

Indicates a variable for which you supply values, in context where italics cannot be used.

string

A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks.

Examples use the following conventions:

Convention

Description

screen font

Terminal sessions and information the switch displays are in screen font.

boldface screen font

Information you must enter is in boldface screen font.

italic screen font

Arguments for which you supply values are in italic screen font.

< >

Nonprinting characters, such as passwords, are in angle brackets.

[ ]

Default responses to system prompts are in square brackets.

!, #

An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line.

This document uses the following conventions:

Note

Means reader take note. Notes contain helpful suggestions or references to material not covered in the manual.

Caution

Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.

Related Documentation for Cisco Nexus 1000V for KVM Software

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

General Information

Cisco Nexus 1000V for KVM Release Notes

Install and Upgrade

Cisco Nexus 1000V for KVM Software Installation Guide

Configuration Guides

Cisco Nexus 1000V for KVM High-Availability Configuration Guide

Cisco Nexus 1000V for KVM Interface Configuration Guide

Cisco Nexus 1000V for KVM Layer 2 Configuration Guide

Cisco Nexus 1000V for KVM License Configuration Guide

Cisco Nexus 1000V for KVM Virtual Network 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 VXLAN Configuration Guide

Reference Guides

Cisco Nexus 1000V for KVM Command Reference

Cisco Nexus 1000V for KVM OpenStack REST API Reference

Troubleshooting and Alerts

Cisco Nexus 1000V for KVM Troubleshooting Guide

Related Documentation for Cisco Nexus Cloud Services Platform

This section lists the documents used with the Cisco Nexus Cloud Services Platform and available on Cisco.com at the following URL:

Click Here

General Information

Cisco Nexus Cloud Services Platform Release Notes

Install and Upgrade

Cisco Nexus Cloud Services Platform Hardware Installation Guide

Cisco Nexus Cloud Services Platform Software Installation and Upgrade Guide

Regulatory Compliance and Safety Information for the Cisco Nexus Cloud Services Platform

Configuration Guide

Cisco Nexus Cloud Services Platform Software Configuration Guide

Reference Guides

Cisco Nexus Cloud Services Platform Command Reference

Cisco Nexus Cloud Services Platform Compatibility Information

Troubleshooting and Alerts

Cisco Nexus Cloud Services Platform Troubleshooting Guide

Documentation Feedback

To provide technical feedback on this document, or to report an error or omission, please send your comments to: ciscodfa-docfeedback@cisco.com.

We appreciate your feedback.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What's New in Cisco Product Documentation, at: Click Here .

Subscribe to What's New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation as an RSS feed and delivers content directly to your desktop using a reader application. The RSS feeds are a free service.

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

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.

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: Click Here . 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)