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

Chapter 2. System Requirements

Minimum Networking Requirements

Minimum Server Requirements

Supported Operating Systems

Supported Hypervisors

Supported MAAS Deployment

Chapter 3. Preparing for Installation

Information About the Global Configuration File

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

Mapping File 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 Cloud Archive OpenStack Services

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

Creating and Deploying a VXLAN Gateway

Configuring the VXLAN Gateway Using the Setup Script

Modifying the Initial Setup Script Parameters

Installing the VXLAN Gateway as a VM

Configuring the VXLAN Gateway Data and Management Interfaces Using OpenStack Horizon Dashboard

Guidelines and Limitations for OpenStack Horizon Dashboard

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

Creating a Trunk Network Profile Using OpenStack Horizon Dashboard

Creating a VLAN Network Profile Using OpenStack Horizon Dashboard

Creating a Network Using OpenStack Horizon Dashboard

Creating a Subnet for a Network Using OpenStack Horizon 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

Verifying the VXLAN Gateway Configuration

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

Appendix A. Sample Global Configuration File

Sample Global Configuration File

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, Juju, and OpenStack before you can deploy the Cisco Nexus 1000V for KVM.

The following figure shows the installation process:

Installation Process Overview

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-precise_5.2.1.sk1.2.2.date.deb. The MAAS node downloads these charms to the cluster nodes to facilitate the installation of their respective services.

- OpenStack charms

- nova-cloud-controller

- quantum-gateway

- openstack-dashboard

- Cisco Nexus 1000V for KVM charms

- vsm

- vem

- vxlan-gateway

Juju deploys each service using its respective charm and two configuration files: its own config.yaml file (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

The config.yaml file is a read-only file and cannot be changed.

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

The VSM charm helps to deploy the Virtual Supervisor Module (VSM) as a virtual machine on an Ubuntu KVM server node in a Canonical OpenStack network. 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.

When you deploy the Virtual Ethernet Module (VEM), you must add a relationship between the VEM and the Nova-compute node so that whenever a nova-compute node is deployed, the VEM service is also deployed automatically. When this relationship is built, the VEM charm installs a VEM on every Nova-compute node.

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

The following figure shows the relationships between theCisco Nexus 1000V for KVM-related charms and their respective config.yaml files, the global configuration file, and in the case of VEM, the mapping.file.

Cisco Nexus 1000V for KVM-Related Charms and Their Respective Configuration Files

Illustration to be provided.

Configuration Files

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

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 Mapping File 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 node)

- OpenStack service nodes

- Network 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 Node

The Juju 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

OpenStack has several service nodes, including the following nodes that perform key functions in the Cisco Nexus 1000V for KVM deployment:

- Nova—Cloud controller

- Keystone—Identity service

- Cinder—Infrastructure for managing OpenStack block storage volumes

- Glance—Services for discovering, registering, and retrieving virtual machine images

- Dashboard—Web-based user interface to OpenStack services including Nova, Swift, Keystone, and so on

- Ceph—Unified, distributed storage system

- RabbitMQ—Internal communication facilitator among the OpenStack nodes that uses Advanced Message Queue Protocol (AMQP)

- MySQL—Cloud database

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:

- Neutron DHCP server through the Neutron DHCP agent

- Virtual routing through the Neutron Layer 3 agent

Nova Compute Nodes

The Nova compute nodes host your virtual machines (VMs), including any VXLAN Gateway VMs that you have deployed as VMs.

VSM Nodes

The VSM controls multiple Virtual Ethernet Modules (VEMs) as one logical modular switch.

The VSM can be hosted on a dedicated server node or a Cisco Nexus 1110 as a Virtual Service Blade (VSB).

Supported Nodes

The Cisco Nexus 1000V for KVM supports the following nodes in a MAAS OpenStack cluster:

- One MAAS server node

- One Juju node

- One or more OpenStack service nodes

- One or more Nova-compute nodes

- Zero, one, or more network nodes

- One or two VSM nodes

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

Physical Deployment

In this deployment model, the services are deployed on a baremetal server rather then as virtual machines. (See the following figure.)The primary benefit of this deployment model is the performance 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.

Note

In all deployment models, we recommend that you deploy the VSM in high availability (HA) mode.

Topology of Physical Deployment

Virtual Machine Deployment

The simplest deployment model is one where all of the OpenStack, MAAS, and Juju services are deployed on a single physical server as virtual machines (see the following figure). The network node (used for offering the DHCP/Layer 3 Agent service) is also deployed on this server as a virtual machine. 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 VSM can be deployed as a virtual machine or on a Cloud Services Platform.

Note

In all deployment models, we recommend that you deploy the VSM in high availability (HA) mode.

Topology of Virtual Machine Deployment

Chapter 2. System Requirements

This chapter contains the following sections:

- Supported Operating Systems

- Supported Hypervisors

- Supported MAAS Deployment

Minimum Networking Requirements

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

Minimum Networking Requirements for Nodes

Component

Networking Requirements

Control node

- Intelligent Platform Management Interface (IPMI)

- Management interface

- Access to the Internet

- API network interface

VSM node

- Management interface

- Access to the datacenter management network and the external network through a proxy server or Network Address Translation (NAT)

Network node

- IPMI.

- Management interface.

- Access to the network through a proxy server or NAT.

- VEM uplink and one or two interfaces connected to the Cisco Nexus 1000V for KVM data network.

- External interface for Layer 3 agent. This interface can be same as the VEM uplink.

Compute nodes

- Management interface.

- IPMI.

- Access to the network through a proxy server or NAT.

- VEM uplink and two interfaces connected to the Cisco Nexus 1000V for KVM data network.

Minimum Server Requirements

The following table lists the minimum requirements for the Cisco Unified Computing System (UCS) servers that you use for the nodes in your Cisco Nexus 1000V for KVM deployment.

You cannot have a mix of blade servers and rack servers. All servers need to be the same hardware configuration.

Server/Node

Minimum Recommended Hardware

Control node

CPU: 2 (v)CPUs minimum

Memory: 2 GB

Disk space: 20 GB [1]

1 NIC[2]

Compute node

CPU: 2 64-bit (Intel VT or AMD-V)

Memory: 24 GB

Disk space: 300 GB single-boot drive or RAID 1/RAID 5

Volume storage: two disks with 2 TB (SATA) for volumes attached to the compute nodes

Network node

Processor: 64-bit x86

Memory: 12 GB

Disk space: 500 GB to 1 TB (SATA or SAS), depending upon configuration

VSM node

Processor: 64-bit x86

Memory: 12 GB

Disk space: 1 TB (SATA or SAS)

VSM as a VM on a KVM node

Memory: 4 GB

CPU: 2 vCPU, 2 GHz

VXLAN Gateway as a VM on compute node

Memory: 4 GB

CPU: 2 vCPU, 2 GHz

[1] MAAS requires at least 150 GB of disk space.

[2] Nova Networking (Neutron) requires at least 2 NICs.

Supported Operating Systems

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

Name

Supported Versions

Ubuntu

12.04.4

Kernel

3.11

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.

- One OpenStack controller per Cisco Nexus 1000V for KVM cloud service 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.

Chapter 3. Preparing for Installation

This chapter contains the following sections:

- Information About the Global Configuration File

- Mapping File Parameters

Information About the Global Configuration File

Several charms require specific configuration information for the Cisco Nexus 1000V for KVM deployment. You define this information in a global configuration file that you create. The following sections provide lists of those configuration parameters.

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.

- 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

OpenStack Charm Parameters

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: archive list

Archive(s) of the Cisco Nexus 1000V for KVM Debian package.

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: deb http://ppa.launchpad.net/cisco-n1kv/havana-stable/ubuntu precise main
n1kv-vsm-username: nexus
n1kv-vsm-password: nexus123
n1kv-vsm-ip: 192.168.10.1
.
.
.

quantum-gateway Charm Parameters

Parameter

Description

openstack-origin: debian-pkg-location

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

l3-agent: {enable | disable}

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

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

- disable—Does not bring up the Linux router.

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

quantum-gateway:
openstack-origin: deb http://ppa.launchpad.net/cisco-n1kv/havana-stable/ubuntu precise main
n1kv-agent: enable
.
.
.

openstack-dashboard Charm Parameters

Parameter

Description

openstack-origin: debian-pkg-location

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

profile-support: cisco

Controls the features supported in the dashboard. For Cisco Nexus 1000V for KVM, the valid value is cisco.

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

openstack-dashboard:
openstack-origin: deb http://ppa.launchpad.net/cisco-n1kv/havana-stable/ubuntu precise main
profile-support: 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 Debian package.

n1kv-version: debian-pkg-version

Cisco Nexus 1000V for KVM Debian package version. If this value is not specified, the latest version among all of the archives is used.

n1kv-vsm-domain-id: domain-id

Domain ID of the VSM.

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.

This example shows the primary VSM portion of the global configuration file:

n1kv-source:  deb http://ppa.launchpad.net/cisco-n1kv/n1kv-stable/ubuntu precise main, deb http://ppa.launchpad.net/cisco-n1kv/n1kv-stable-1/ubuntu precise main, deb http://ppa.launchpad.net/cisco-n1kv/ n1kv-stable-2/ubuntu precise main, deb http://ppa.launchpad.net/cisco-n1kv/ n1kv-stable-3/ubuntu  precise main, deb http://ppa.launchpad.net/cisco-n1kv/ n1kv-stable-4/ubuntu  precise main, deb http://ppa.launchpad.net/cisco-n1kv/ n1kv-stable-5/ubuntu  precise main
n1kv-version: 5.2.1.sk1.2.1.36-1_amd64
n1kv-vsm-domain-id: 101
n1kv-vsm-password: nexus123
n1kv-vsm-name: vsm-primary
n1kv-vsm-role: primary
n1kv-vsm-ip: 192.168.10.2
n1kv-vsm-mgmt-netmask: 255.255.255.0
n1kv-mgmt-gateway: 192.168.10.3
.
.
.

This example shows the secondary VSM portion of the global configuration file:

vsm-secondary:
n1kv-source:  deb http://ppa.launchpad.net/cisco-n1kv/n1kv-stable/ubuntu precise main, deb http://ppa.launchpad.net/cisco-n1kv/n1kv-stable-1/ubuntu precise main, deb http://ppa.launchpad.net/cisco-n1kv/n1kv-stable-2/ubuntu  precise main, deb http://ppa.launchpad.net/cisco-n1kv/n1kv-stable-3/ubuntu  preicse main, deb http://ppa.launchpad.net/cisco-n1kv/n1kv-stable-4/ubuntu  preicse main, deb http://ppa.launchpad.net/cisco-n1kv/n1kv-stable-5/ubuntu  preicse main
n1kv-version: 5.2.1.sk1.2.1.36-1_amd64
n1kv-vsm-domain-id: 101
n1kv-vsm-password: nexus123
n1kv-vsm-name: vsm-secondary
n1kv-vsm-role: secondary
n1kv-vsm-ip: 0.0.0.0
n1kv-vsm-mgmt-netmask: 0.0.0.0
n1kv-mgmt-gateway: 0.0.0.0
.
.
.

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 use the mapping file. For more information, see Mapping File Parameters.

Parameter

Description

n1kv-source: debian-pkg-location

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

n1kv-version: debian-pkg-version

Cisco Nexus 1000V for KVM Debian package version. If this value is not specified, the latest version among all of the archives is used.

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

Virtual Tunnel Endpoint (VTEP) port configuration.

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 portion of the global configuration file:

vem:
n1kv-source: deb http://ppa.launchpad.net/springfield-team/n1kv-stable/ubuntu precise main, deb http://ppa.launchpad.net/springfield-team/n1kv-stable1/ubuntu precise main, deb http://ppa.launchpad.net/springfield-team/n1kv-stable2/ubuntu precise main, deb http://ppa.launchpad.net/springfield-team/n1kv-stable3/ubuntu
n1kv-version:12.04.5.2.1.sk1.2.1.s0.36-1gdb_amd64
vtep_config:
node-type: network
vtep_in_same_subnet: yes
vtp_config:"virt vmknic-int5 profile profint mode static address 192.168.2.91 netmask 255.255.255.0 mac 00:22:22:33:44:51, virt vmknic-int6 profile profint mode static address 192.168.2.92 netmask 255.255.255.0 mac 00:22:22:33:44:52"

.
.
.

Cisco Nexus 1000V for KVM VXLAN Gateway Charm Parameters

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

Parameter

Description

n1kv-source: debian-pkg-location

Archive(s) of the Cisco Nexus 1000V for KVM Debian package.

n1kv-version: debian-pkg-version

Cisco Nexus 1000V for KVM Debian package version. If this value is not specified, the latest version among all of the archives is used.

This example shows the VEM portion of the global configuration file:

vxlan-gateway:
n1kv-source:deb ppa.launchpad.net/cisco-n1kv/n1kv-stable/ubuntu precise main, deb ppa.launchpad.net/cisco-n1kv/n1kv-stable-1/ubuntu precise main, deb ppa.launchpad.net/cisco-n1kv/n1kv-stable-2/ubuntu precise main, deb ppa.launchpad.net/cisco-n1kv/n1kv-stable-3/ubuntu precise main, deb ppa.launchpad.net/cisco-n1kv/n1kv-stable-4/ubuntu precise main, deb ppa.launchpad.net/cisco-n1kv/n1kv-stable-5/ubuntu precise main
n1kv-version:

.
.
.

Mapping File Parameters

You can deploy VEMs with unique configuration parameters instead of using the configuration parameters that are defined in the config.yaml file for all VEMs. To do this, you need to 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 node ID and include any of the VEM configuration parameters listed in the Cisco Nexus 1000V for KVM VEM Charm Parameters section.

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

maas-node-6:
n1kv-host-mgamt-intf: eth1
n1kv-uplink-profile: phys eth2 profile sys-uplink
maas-node-11:
n1kv-host-mgmt-intf: eth0
n1kv-uplink-profile: phys eth0 profile sys-uplink
n1kv-node-type: network
n1kv-vtep-config: virt mvknic-int1 profile profint mode dhcp mac 00:21:32:43:54:76

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 Cloud Archive OpenStack Services

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

- 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 Cloud Archive OpenStack services.

See Installing and Configuring the Cloud Archive OpenStack Services.

Step 4

Install and configure the Cisco Nexus 1000V for KVM.

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

Step 5

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. For detailed information, see Click Here .

- 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 Cloud Archive OpenStack Services

You install and configure the Cloud Archive OpenStack services using an Ubuntu Debian package that you get directly from the Canonical Charm Store(s).

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

Procedure

Step 1

Set up the virtual machines, physical servers, and/or local containers based on your deployment model.

Step 2

Deploy the OpenStack services.
Note:
Certain OpenStack and Cisco Nexus 1000V for KVM services are packaged together in another charm Debian package that you download and install locally. For information about installing these services, see Installing and Configuring the Cisco Nexus 1000V for KVM.

juju deploy [--config config-file] [--to=destination] [-n instances] [--constraints constraint-clauses] cs:precise:service

Installing and Configuring the Cisco Nexus 1000V for KVM

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

Install the charm package on your local machine. apt-get install jujucharm-n1k

Step 2

Create a global configuration file and divide it into sections. Create one section for each charm with the values for your deployment. For information about the contents of the global configuration file, see Preparing for Installation.

Step 3

Deploy the nova-cloud-controller service. juju deploy [--config config-file] [--to=destination]--repository=/opt/cisco/n1kv/charms/jujucharm-n1k/charms local:precise/nova-cloud-controller

Step 4

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

Step 5

Deploy the openstack-daskboard service. juju deploy [--config config-file] [--to=destination]--repository=/opt/cisco/n1kv/charms/jujucharm-n1k/charms local:precise/openstack-dashboard

Step 6

Deploy the primary VSM. juju deploy [--config config-file] [--to=destination]--repository=/opt/cisco/n1kv/charms/jujucharm-n1k/charms local:precise/vsm vsm-primary

Step 7

Deploy the secondary VSM. juju deploy [--config config-file] [--to=destination]--repository=/opt/cisco/n1kv/charms/jujucharm-n1k/charms local:precise/vsm vsm-secondary

Step 8

Deploy the VEM.

1. juju deploy [--config config-file] [--to=destination]--repository=/opt/cisco/n1kv/charms/jujucharm-n1k/charms local:precise/vem

2. juju add-relation nova-compute vem

3. juju add-relation vsm:dvs vem:dvs

4. juju add-relation quantum-gateway vem

5. Optional: juju set vem mapping=`cat host-mapping-file `

Installing and Configuring the VXLAN Gateway Using Juju Charms

If you want to deploy the VXLAN Gateway with the Cisco Nexus 1000V for KVM, you can install the VXLAN Gateway using the vxlan-gateway charm. (Alternatively, you can install the VXLAN Gateway using an ISO file. For more information, see Installing and Configuring the VXLAN Gateway.

Note

The VXLAN Gateway is an optional addition to the Cisco Nexus 1000V for KVM deployment.

Before You Begin
Make sure 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 vxlan-gateway

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

Step 2

Configure the VXLAN Gateway data and management interfaces. For details, see Creating the VXLAN Gateway Data Interface and Creating a VXLAN Gateway Management Interface.

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.

Note

Install the primary and secondary VSM on the Cisco Nexus Cloud Services Platform before you create the build server.

Installing a VSM on the Cisco Nexus Cloud Services Platform

Note

Virtual Ethernet Modules (VEMs) do not register to the VSM before a vmkernel interface (vmk) is migrated to a Layer 3 control-capable port profile. You must migrate a vmk to the Layer 3 port profile after you migrate host vmnics to Ethernet port profiles.

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.4.2.1.SV2.2.1.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

- Verifying the VXLAN Gateway Configuration

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

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 deploy the VXLAN Gateway as a VM or on the Cisco Nexus Cloud Services platform Release 4.2(1)SP1(6.1) or later releases.

- You must connect the Cloud Services Platform appliance to a switch that supports the Link Aggregation Control Protocol (LACP) based or statically configured port channels and VLAN-based trunk interfaces.

- vCPU and memory requirements:

- Three vCPUs for each Virtual Service Blade (VSB)

- Two vCPUs for each Virtual Machine (VM)

- 2-GB RAM

- 3-GB virutal disk space

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 Installation and Upgrade Guide and Cisco Nexus 1000V System Management Configuration Guide.

- You must configure the uplink for the gateway module as a LACP or a static port channel. The VXLAN Gateway does not function if gateways are configured in the MAC-pinning mode.

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

- You must configure the underlying Cloud Services Platform with an uplink type that is flexible (type 5). VXLAN Gateways use two physical interfaces. You must set the interfaces in the passthrough mode. In addition, you must set at least one physical or a port channel interface must be set up to carry management traffic.

- Ensure that you do not configure a private VLAN on the VLANs that are used for VXLAN-VLAN mappings.

- The VXLAN Gateway virtual services blade (VSB) has two uplink data interfaces configured in a port channel group. The VXLAN Gateway VM has only one uplink data interface; therefore, it does not require a port channel.

- The VXLAN Gateway virtual services blade (VSB) uses three vCPUs: one vCPU for management traffic and the other two vCPUs for the data interfaces. The VXALN Gateway virtual machine (VM) uses two vCPUs; one vCPU for management traffic and one vCPU for the data interface.

The following figure shows the maximum allowed VXLAN Gateway deployment that is managed by a single VSM. It displays four Cloud Services Platform devices where each Cloud Services Platform device hosts two VXLAN Gateway modules. Four HA clusters of gateway modules are setup with each cluster that consists of an active/standby pair of modules.

VXLAN Gateway HA Pairs

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.

For details, see Configuring a Port Profile for the Uplink on the VXLAN Gateway topic and the Configuring a Port Profile for the VTEP on the VXLAN Gateway.

Step 2

Install VXLAN Gateway either on a Cisco Nexus Cloud Services Platform (CSP) or a VM.

For details, see Installing the VXLAN Gateway as a VM topic or the Creating and Deploying a VXLAN Gateway.

Step 3

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.

For details, see the Configuring the VXLAN Gateway HA Mode as Standalone topic.

Step 4

Verify the VXLAN Gateway installation and configuration.

(Optional)
For details, see Verifying the VXLAN Gateway Configuration.

Step 5

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

For details, see Managing the VXLAN-to-VLAN Mappings on the VXLAN Gateway.

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 the LACP is configured by entering the feature lacp configuration command on the VSM.

- Offload the LACP operation by entering the lacp offload configuration command on the VSM.

- 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)# channel-group auto

Creates a channel group for all interfaces that belong to the port profile.

Step 12

vsm(config-port-prof)# channel-group auto mode active

Configures the port channel mode as LACP.

Step 13

vsm(config-port-prof)# no shutdown

Administratively enables all ports in the profile.

Step 14

vsm(config-port-prof)# state enabled

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

Step 15

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

Creating and Deploying a VXLAN Gateway

You can create and deploy a VXLAN Gateway as a VSB on all Cisco Nexus Cloud Services Platforms.

Before You Begin
You must be logged in to the Cisco Nexus Cloud Services Platform on which you want to install the VXLAN Gateway.

Procedure

Command or Action

Purpose

Step 1

CSP# copy scp:// server where the VXGW image is located source path iso image of vxlan gw bootflash:repository >

Copies the VXLAN gateway image to the bootflash/repository on the CCPA Manager.

Step 2

CSP# configure terminal

Enters global configuration mode.

Step 3

CSP(config) # virtual-service-blade name of the VXLAN GW VSB

Creates a VXLAN Gateway VSB.

Step 4

CSP(config-vsb-config) # virtual-service-blade-type new iso image of the vxlan gw

Deploys the downloaded VXLAN Gateway. The image is always populated from the bootflash or repository and there is no need to specify the path.

Step 5

CSP(config-vsb-config) # interface gw-uplink1 uplink Physical-Interface Cloud Services Platform

Assigns a physical interface on the Cloud Services Platform to the gateway uplink. GigabitEthernet3 through GigabitEthernet6 are available in the flexible mode physical interfaces. You must configure the port channels using LACP on the upstream switches.

Step 6

CSP(config-vsb-config) # interface gw-uplink1 mode passthrough

Configures the gateway uplink as passthrough. The corresponding Gigabit Ethernet interface cannot be shared with other VSBs on the Cloud Services Platform.

Step 7

CSP(config-vsb-config) # interface gw-uplink2 uplink Physical-Interface Cloud Services Platform

Assigns a physical interface on the Cloud Services Platform to the gateway uplink. GigabitEthernet3 through GigabitEthernet6 are available in the flexible mode physical interfaces. You must configure the port channels using LACP on the upstream switches.

Step 8

CSP(config-vsb-config) # interface gw-uplink2 mode passthrough

Configures the gateway uplink as passthrough. The corresponding Gigabit Ethernet interface cannot be shared with other VSBs on the Cloud Services Platform.

Step 9

CSP(config-vsb-config) # interface management vlan vlan id

Allows the specified VLAN ID on the management uplink. The VLAN range is from 1 to 4096.

Step 10

CSP(config-vsb-config) # interface management uplink interface

Specifies the interface as either a physical interface of the Cloud Services Platform or a port channel interface previously created on the Cloud Services Platform.

Step 11

Use one of the following commands to deploy a gateway:

- CSP(config-vsb-config)# enable

- CSP(config-vsb-config)# enable primary

- CSP(config-vsb-config)# enable secondary

Use the enable command to install two VSBs, one on the primary Cloud Services Platform and another on the secondary cloud services platform.

Use the enable primary command to deploy the gateway in standalone mode on the primary Cloud Services Platform.

Use the enable secondary command to deploy the gateway in standalone mode on the secondary Cloud Services Platform.

Initiates a setup script to configure the VXLAN gateway, IP address, subnet mask, gateway, hostname, and password for the VXLAN gateway VSB. You are also required to specify the details of the VSMs domain ID, IP address, primary and secondary MAC addresses on the control interface. For more information, see Setup Script to Configure the VXLAN Gateway.

This example shows how to bring up a gateway as a VSB on a VSA pair:

CSP# configure terminal
CSP(config)# virtual-service-blade VXLAN-GW
CSP(config-vsb-config)# virtual-service-blade-type new vxgw.4.2.1.SV2.2.0.264.iso
CSP(config-vsb-config)# interface gw-uplink1 uplink GigabitEthernet3
CSP(config-vsb-config)# interface gw-uplink2 uplink GigabitEthernet4
CSP(config-vsb-config)# interface gw-uplink1  mode passthrough
CSP(config-vsb-config)# interface gw-uplink2  mode passthrough
CSP(config-vsb-config)# interface management uplink GigabitEthernet1
CSP(config-vsb-config)# interface management vlan 751
CSP(config-vsb-config)# enable

Configuring the VXLAN Gateway Using the Setup Script

After you enter enable while installing a VXLAN Gateway as a VSB, the setup script to configure the VXLAN gateway is executed. The setup script configures the following parameters on the VXLAN gateway:

- IP address, network mask, and default gateway for both the primary and secondary VXLAN Gateway Management interface

- VSM details—Domain ID, IP address, primary MAC address, and secondary MAC address of the VSM control interface

- Port profiles used for the VXLAN Gateway uplink and VTEP

Procedure

Step 1

On the command prompt, enter the VSB image and press Enter.

Enter VSB image:x.x.x.x.x.x.x.iso: [vxgw.5.2.1.SK1.2.1.iso]

Step 2

Enter the VSM domain ID. The range is from 1 to 1023.

Enter domain [1-1023]:405

Note:
You can get the domain ID by entering the show svs domain command on the VSM.

Step 3

Enter the management IP version.

Management IP version [V4]:v4

Step 4

Configure the management IP address to interface mgmt 0 on the VXLAN Gateway that is deployed on the primary Cloud Services Platform.

Enter management IP address of service module on primary: 192.168.1.104

Note:
If you are deploying the gateway in the standalone mode on the secondary Cloud Services Platform, enter the IP address, network mask, and the default gateway address for the primary as 0.0.0.0.

Step 5

Enter the management subnet mask.

Enter management subnet mask of service module on primary: 255.255.255.0

Step 6

Enter the management default gateway.

Enter default gateway IP address of service module on primary: 192.168.1.1

Step 7

Configure the management IP address to interface mgmt 0 on the VXLAN gateway deployed on the secondary Cloud Services Platform.

Enter management IP address of service module on secondary: 192.168.1.105

Note:
If you are deploying the gateway in the standalone mode on the primary Cloud Services Platform, enter the IP address, network mask, and the default gateway address for the secondary as 0.0.0.0.

Note:
In a HA deployment, we recommend that the IP address that you provide is in the same subnet as the one provided in Step 5.

Step 8

Enter the management subnet mask.

Enter management subnet mask of service module on secondary: 255.255.255.0

Step 9

Enter the management interface default gateway.

Enter default gateway IP address of service module on secondary: 192.168.1.1

Step 10

Enter the VXLAN Gateway hostname.

Enter HostName: VXLAN-GW-DOCS

Step 11

Enter the login credentials.

Enter the password for admin:Sfish123

Step 12

Enter the IP address of the VSM.

VSM L3 Ctrl IPv4 address:192.168.1.210

Step 13

Enter the uplink trunk port profile configured on the VSM.

Enter VSM uplink port-profile name: gw-uplink

Note:
Enter the dedicated uplink trunk port profile for the VXLAN Gateway pair created on the VSM.

Step 14

Enter the VTEP profile name.

Enter VTEP port-profile name: gw-vtep

Note:
Enter the same VTEP port profile name created on the VSM.

This example shows how to bring up the VXLAN Gateway:

CSP(config-vsb-config)# enable
Enter vsb image: [vxgw.4.2.1.SV2.2.0.264.iso]
Enter the VSM domain id[1-4095]: 405
Enter Management IP version [V4]: [V4]
Enter Management IP address of service module on primary: 192.168.1.104
Enter Management subnet mask of service module on primary: 255.255.255.0
Enter default gateway IP address of service module on primary: 192.168.1.1
Enter management IP address of service module on secondary: 192.168.1.105
Enter management subnet mask of service module on secondary: 255.255.255.0
Enter default gateway IP address of service module on secondary: 192.168.1.1
Enter HostName: VXLAN-GW-DOCS
Enter the password for 'admin': Sfish123
VSM L3 Ctrl IPv4 address : 192.168.1.210
Enter VSM uplink port-profile name: gw-uplink
Enter VTEP port-profile name: gw-vtep
Note: VSB installation is in progress, please use show virtual-service-blade commands to check the installation status.
CSP(config-vsb-config)#

Modifying the Initial Setup Script Parameters

After executing the setup script for the first time, if you need to modify any of the setup parameters, use the following commands on the VSM:

Note

If an HA pair is installed, ensure that you apply the same changes individually on both gateway modules.

Note

Ensure the port profile that you update is first saved on the VSM.

Procedure

Command or Action

Purpose

Step 1

vsm(config)# service module update port-profile type ethernet name VXLAN Gateway Uplink port-profile name

Modifies the VXLAN Gateway uplink port profile from the VSM.

Step 2

vsm(config)# service module update port-profile type vethernet name VXLAN Gateway VTEP port-profile name

Modifies the VXLAN Gateway VTEP port profile from the VSM.

Installing the VXLAN Gateway as a VM

Do not perform this step if you plan to install your VXLAN Gateway pairs on the Cisco Nexus Cloud Services Platform.

Before You Begin

- Ensure that the server on which you create the VXLAN Gateway VM meets the networking requirements, as described in Minimum Networking Requirements.

- Create the required port profiles in the VSM, as described in Configuring Port Profiles on the VSM.

Procedure

Step 1

Download the VXLAN Gateway software image vxgw.5.2.1.SK1.2.1.disk1.qcow2 to the build server.

Step 2

Configure the $gwimage variable in the site.pp file on the build server.

Step 3

Deploy the VXLAN Gateway using the puppet apply -v /etc/puppet/manifests/site.pp command followed immediately by the puppet agent -t -v command.
As part of the OpenStack installation, this VXLAN Gateway image is pushed from the build server to Glance on the OpenStack controller.

Step 4

Make sure the VXLAN Gateway image is present in one of the following ways:

- In the OpenStack Horizon Dashboard, choose Admin > Images.

- In the OpenStack CLI, enter glance image-list.

Step 5

Create the VXLAN Gateway data and management interfaces in one of the following ways:

- Configuring the VXLAN Gateway Data and Management Interfaces Using OpenStack Horizon Dashboard

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

Configuring the VXLAN Gateway Data and Management Interfaces Using OpenStack Horizon Dashboard

- Guidelines and Limitations for OpenStack Horizon Dashboard

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

- Creating a Trunk Network Profile Using OpenStack Horizon Dashboard

- Creating a VLAN Network Profile Using OpenStack Horizon Dashboard

- Creating a Network Using OpenStack Horizon Dashboard

- Creating a Subnet for a Network Using OpenStack Horizon Dashboard

- Booting a VXLAN Gateway VM

Guidelines and Limitations for OpenStack Horizon Dashboard

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

- To create a network profile, you must log in to OpenStack Horizon Dashboard as a user with admin privileges. Any user can use a network profile that is already created.

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

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

Before You Begin
Create one or more port profiles in the VSM. These port profiles are displayed as policy profiles in OpenStack Horizon 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

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

Step 2

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

Step 3

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

Step 4

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

Step 5

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

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

Step 6

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

Creating a Trunk Network Profile Using OpenStack Horizon 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 Horizon 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. In the Segment Range field, leave this blank. Do not enter any information in this field.

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

6. From the Project drop-down list, choose the tenant that you want to associate with this network profile.

7. Click Create Network Profile.

OpenStack Horizon 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 Horizon 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 Horizon 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. From the Sub Type drop-down list, choose None.

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

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

6. From the Project drop-down list, choose the tenant that you want to associate with this network profile.

7. Click Create Network Profile.

OpenStack Horizon 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 OpenStack Horizon 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 the tenant where you want to create the network.
This tenant should be the same tenant that you use for the network profile.

3. From the Network Profile drop-down list, choose the network profile you want to associate with the network.
For the VXLAN Gateway, choose the trunk network profile that you already created.

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

5. 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 OpenStack Horizon 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, 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 the type of IP address that you want to use for the subnet:

- IPv4

- IPv6

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

5. Click Create Subnet.

Step 4

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

What to Do Next

Create a VM instance. OpenStack Horizon Dashboard creates a port for the network when you launch the instance.

Booting a VXLAN Gateway VM

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

Procedure

Step 1

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 2

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

quantum cisco-network-profile-create network_name trunk sub_type vlan

Creates a network profile with a segment type of trunk and a subtype of vlan.

Step 2

quantum cisco-network-profile-list

Displays the Cisco network profile IDs.

Step 3

quantum net-create network_name --n1kv:profile_id network_profile_id

Creates a network using the network profile.

Step 4

quantum subnet-create network_profile_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 5

quantum cisco-policy-profile-list

Lists the policy profiles available in Quantum.

Step 6

quantum port-create network_name n1kv:profile_id 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 one of the Cisco policy profile IDs from the list of available profiles obtained in Step 5.

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

quantum cisco-network-profile-create network_profile_name --sub_type vlan segment_range segment_range physical_network network_name

Creates a VLAN access network profile.

Step 2

quantum cisco-network-profile-list

Displays the Cisco network profile IDs.

Step 3

quantum net-create network_name --n1kv:profile_id network_profile_id

Creates an access network.

Step 4

quantum subnet-create network_name cidr_blocks --name subnet_name

Creates a subnet for the access network segment profile.

Step 5

quantum cisco-policy-profile-list

Lists the policy profiles available in Quantum.

Step 6

quantum port-create network_name n1kv:profile_id 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:~# quantum cisco-credential-create 172.23.181.101 n1kv --tenant-id 1234-1234-1234-1234 --user_name admin --password mypwd
root@server:~# quantum cisco-network-profile-create aug-net-prof trunk sub_type vlan
root@server:~# quantum net-create aug-net --n1kv:profile_id 999e6dc-7a55-4c4a-839e-9aa22957ba99
root@server:~# quantum subnet-create aug-net 110.10.10.0/24 --name augsubnet --disable-dhcp
root@server:~# quantum 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:~# quantum port-create aug-net --n1kv:profile_id 4c4455e5-95d6-4185-80a1-a028e27fc8bd
root@server:~# quantum cisco-network-profile-create test2 --vlan segment_range 400-499 --physical_network q-n1k
root@server:~# quantum net-create q-n1k --n1kv:profile_id 2e464910-f452-4865-9793-6bd70a4c0cf6
root@server:~# quantum subnet-create q-n1k 110.10.10.0/24 --name q-110.10.10.0/24
root@server:~# quantum 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:~# quantum 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

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

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

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: cloud:precise-havana
nova-cloud-controller:
network-manager: Neutron
openstack-origin: cloud:precise-havana
quantum-plugin: n1kv
n1kv-vsm-username: < Introduce the VSM username here >
n1kv-vsm-password: < Introduce the VSM password here >
n1kv-vsm-ip: < Introduce the VSM IP here >
ceph:
fsid: a51ce9ea-35cd-4639-9b5e-668625d3c1d8
monitor-secret: AQCk5+dR6NRDMRAAKUd3B8SdAD7jLJ5nbzxXXA==
osd-devices: /dev/vdb
source: cloud:precise-updates/havana
cinder:
block-device: /dev/vdb
openstack-origin: cloud:precise-havana/updates
overwrite: 'true'
glance:
openstack-origin: cloud:precise-havana/updates
keystone:
admin-password: openstack
debug: 'true'
log-level: DEBUG
openstack-origin: cloud:precise-havana/updates
nova-compute:
config-flags: auto_assign_floating_ip=True,compute_driver=libvirt.LibvirtDriver
enable-live-migration: 'True'
migration-auth-type: none
openstack-origin: cloud:precise-havana/updates
virt-type: kvm
openstack-dashboard:
openstack-origin: cloud:precise-havana/updates
profile-support: "cisco"
swift-proxy:
auth-type: keystone
country: US
locale: San Francisco
openstack-origin: cloud:precise-havana/updates
state: CA
zone-assignment: auto
swift-storage:
block-device: /dev/vdb
openstack-origin: cloud:precise-havana/updates
overwrite: 'true'
vsm-primary:
n1kv-source: < Private PPA source >
n1kv-vsm-domain-id:<domain-id>
n1kv-vsm-name:"vsm-p"
n1kv-vsm-role:"primary"
n1kv-vsm-ip:<VSM IP>
n1kv-vsm-mgmt-netmask:<VSM Netwmask>
n1kv-mgmt-gateway:<Default Gateway>
vsm-secondary:
n1kv-source: < Private PPA source >
n1kv-vsm-domain-id:<domain-id>
n1kv-vsm-name:"vsm-s"
n1kv-vsm-role:"secondary"
vem:
n1kv-source: < Private PPA source >
n1kv-vsm-ip: < Introduce the VSM ip here >
n1kv-vsm-domain-id: < Introduce the VSM domain id here>
uplink-profile: "phys <interface> profile <port-profile>"

Preface

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

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 OpenStack Configuration Guide and Command Reference

Cisco Nexus 1000V for KVM Port Profile 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 Configuration Guide and 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 one of the following:

- nexus-1k-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 deliver 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)