Chapter 1. New and Changed Information

New and Changed Information

Chapter 2. Overview

Information About the Cisco Nexus Cloud Services Platform

Cisco Nexus Cloud Services Platform High Availability

Comparison with a Virtual Machine

Cisco Integrated Management Controller

Virtual Service Blades

Uplinks

Traffic Classification

Network Uplink Configuration

Chapter 3. Setting Up Remote Management

Information About Remote Management

Configuring Remote Management

Feature History for Remote Management

Chapter 4. Configuring the Network Uplinks

Information About Network Uplink Configurations

Default Network Uplink Configuration

Network Uplink Configuration Examples

Support for Cisco UCS VIC 1225 10-Gbps Dual-Port NICs

Guidelines and Limitations for Enabling the Cisco UCS 10-Gbps Card

Enabling a Cisco UCS 10-Gbps Card

Configuring Port Channels

Deleting Port Channels

Assigning Uplinks to a VSB Interface

Manually Assigning Uplinks to a VSB Interface

Assigning a Native VLAN to a Port Channel

Shutting Down Ports or Port Channel Interfaces

Verifying the Uplink Configuration

Passthrough Interfaces

Feature History for Uplinks

Chapter 5. Configuring Virtual Services Blades

Information About Virtual Service Blades

Cisco Nexus 1000V VSM Virtual Service Blades

Cisco Network Analysis Module Virtual Service Blades

Cisco Virtual Security Gateway Module Virtual Service Blades

Cisco Data Center Network Manager Virtual Service Blades

Cisco Nexus VXLAN Gateway Virtual Service Blades

Citrix NetScaler 1000V Virtual Service Blades

Cisco Nexus 1000V for KVM Virtual Service Blades

Virtual Service Blade Management VLAN

Virtual Service Blade High Availability

Role Collision Detection

Guidelines and Limitations for Virtual Service Blades

Crypto and SSL Offloading in Virtual Service Blades

Guidelines and Limitations for Using the Cavium NITROX Security Processor Card

Configuring SSL and Crypto Offloading Capability in Virtual Service Blades

Creating a Virtual Service Blade

Deleting a Virtual Service Blade

Modifying a Virtual Service Blade

Modifying a Virtual Service Blade on the Cisco Nexus Cloud Services Platform

Modifying the Cisco Nexus 1000V VSM Configuration

Defining Form Factors for a Cisco Virtual Security Gateway VSB

Automatic Execution of the copy running-config startup-config Command

Configuring a Passthrough VSB Interface

Setting Up a Passthrough VSB Interface

Configuration Examples for Virtual Service Blades

Verifying the Virtual Service Blade Configuration

MIBs

Feature History for Virtual Service Blades

Chapter 6. Migrating Virtual Supervisor Modules

Information About Migrating a Virtual Supervisor Module

Guidelines and Limitations for Migrating a Virtual Supervisor Module

Migrating a Virtual Service Module to the Cisco Nexus Cloud Services Platform

Verifying the Migration

Migrating a Virtual Supervisor Module from the Cisco Nexus Cloud Services Platform to the Hypervisor Server

Feature History for Virtual Supervisor Module Migration

Chapter 7. Exporting and Importing a Virtual Service Blade

Information About Exporting and Importing a Virtual Service Blade

Guidelines and Limitations for Exporting and Importing a Virtual Service Blade

Exporting a Virtual Service Blade

Exporting a Virtual Service Blade Backup File

Copying the Exported Virtual Service Blade to an External Storage Location

Importing a Virtual Service Blade

Verifying the Export and Import of a Virtual Service Blade

Feature History for Export and Import

Chapter 8. Migrating a Virtual Service Blade to the Cisco Nexus 1110 Series

Information About Migrating Virtual Service Blades

Guidelines and Limitations for Migrating a Virtual Service Blade

Migrating a Virtual Service Blade to the Cisco Nexus 1110 Series

Migrating an HA Virtual Service Blade to the Cisco Nexus 1110 Series

Migrating a Non-HA VSB to the Cisco Nexus 1110 Series

Migrating an OVA to the Cisco Nexus Cloud Services Platform

Verifying the Migration

Feature History for Migration

Copyright Page

Chapter 1. New and Changed Information

This chapter contains the following sections:

- New and Changed Information

New and Changed Information

This section lists the new and changed information in this document by release:

Feature

Description

Release

Enable the Cisco UCS 1225 (10 Gbps) card on the Cisco Nexus 1110-X

The Cisco Nexus 1110-X has its dual 10 Gbps ports enabled as uplinks in shared mode.

5.2(1)SP1(7.1)

Support for the Cisco Nexus 1000V for KVM

The Cisco Nexus Cloud Services Platform supports the Cisco Nexus 1000V for KVM. The Cisco Nexus 1000V for KVM can be deployed as a VSB on the Cisco Nexus Cloud Services Platform.

5.2(1)SP1(7.1)

No support for static topologies

The Cisco Nexus Cloud Services Platform supports only a flexible network topology. All previously configured static topologies are automatically converted to a flexible configuration during an upgrade.

5.2(1)SP1(7.1)

Automatic execution of the copy running-config startup-config command for saving VSB configuration settings

The copy running-config startup-config command is automatically executed at 5-minute intervals to save all virtual service blade (VSB) configuration settings.

5.2(1)SP1(7.1)

Interface name mode passthrough

Command to configure a VSB to assign a virtual interface to an uplink.

4.2(1)SP1(6.1)

Form factor for VSG VSB

Set up the VSG VSBs in different form factors.

4.2(1)SP1(6.1)

show virtual-service-blade name command

This command was introduced.

4.2(1)SP1(5.1)

Flexible network uplink

Configure a flexible network uplink type.

4.2(1)SP1(4)

Native VLAN

Assign a native VLAN to a port channel.

4.2(1)SP1(4)

Shut down port channel interfaces

Shut down ports or port channel interfaces.

4.2(1)SP1(4)

OVA support for VSB

Create a VSB using an OVA file.

4.2(1)SP1(4)

Migrate OVA

Export an OVA from ESX and import it into the Cisco Nexus 1010 product family as a VSB.

4.2(1)SP1(4)

Migrate a VSB

Migrate a VSB from the Cisco Nexus 1010 to the Cisco Nexus 1010-X.

4.2(1)SP1(3)

Back up and restore a VSB

Create a backup copy of a VSB, store it remotely, and reimport it to restore a VSB.

4.2(1)SP1(3)

Chapter 2. Overview

This chapter contains the following sections:

- Information About the Cisco Nexus Cloud Services Platform

- Cisco Nexus Cloud Services Platform High Availability

- Comparison with a Virtual Machine

- Cisco Integrated Management Controller

- Virtual Service Blades

- Uplinks

- Network Uplink Configuration

Information About the Cisco Nexus Cloud Services Platform

The Cisco Nexus Cloud Services Platform product family includes the Cisco Nexus 1010, Cisco Nexus 1010-X, Cisco Nexus 1110-S, and Cisco Nexus 1110-X. The Cisco Nexus Cloud Services Platform provides dedicated hardware for Cisco Nexus 1000V Virtual Supervisor Modules (VSMs) and can host VSMs that were hosted on virtual machines, which allows you to install and manage a Cisco Nexus 1000V VSM like a standard Cisco switch.

The services managed by the Cisco Nexus Cloud Services Platform are called virtual service blades (VSBs). The Cisco Nexus Cloud Services Platform supports the following VSBs:

- Cisco Nexus 1000V VSM for VMware vSphere, Microsoft Hyper-V, and KVM

- Cisco Network Analysis Module (NAM)

- Cisco Nexus 1000V VXLAN gateway

- Citrix NetScaler 1000V

For more information about VSBs, see Virtual Service Blades.

For more information about the number of VSBs supported and hosted on the Cisco Nexus Cloud Services Platform, see the Cisco Nexus Cloud Services Platform Compatibility Information.

The following figure shows how the Cisco Nexus Cloud Services Platform hosts a Cisco Nexus 1000V VSM and its Virtual Ethernet Modules (VEMs) in your network.

Cisco Nexus Cloud Services Platform Architecture

Cisco Nexus Cloud Services Platform High Availability

The Cisco Nexus Cloud Services Platform supports high availability. Two Cisco Nexus Cloud Services Platforms can form an HA pair to provide high availability. If control connectivity is lost for a Cisco Nexus Cloud Services Platform, but management connectivity is preserved, the active Cisco Nexus Cloud Services Platform reloads the standby once. The standby comes up in a wait state until control connectivity is restored. In an HA pair, the active and standby Cisco Nexus Cloud Services Platforms use control connectivity to synchronize data.

The Cisco Nexus Cloud Services Platform supports the following forms of high availability:

- Active-Standby in Management Deployment—The active Cisco Nexus Cloud Services Platform is reachable over the network and a majority of the commands are supported only on the active Cisco Nexus Cloud Services Platform. The standby Cisco Nexus Cloud Services Platform is not reachable over the IP network, but is accessible through the active Cisco Nexus Cloud Services Platform or directly through a serial connection.

- Active-Active in VSB Deployment—When you deploy a VSB on the Cisco Nexus Cloud Services Platform, you can deploy the VSB on either the active or the standby Cisco Nexus Cloud Services Platform. The VSBs can be active on both the active and standby Cisco Nexus Cloud Services Platform. This configuration balances the distribution of traffic and reduces the potential fault domain.

The following figure shows the HA components and the communication links between them.

Cisco Nexus Cloud Services Platform HA Components and Communication Links

Comparison with a Virtual Machine

The following table compares running a VSM on a Cisco Nexus Cloud Services Platform with running a VSM on a virtual machine.

VM and Cisco Nexus Cloud Services Platform Comparison

Feature

Virtual Machine

Cisco Nexus 1010

Cisco Nexus 1010-X

Cisco Nexus 1110-S

Cisco Nexus 1110-X

Host management capacity

64

384

64 hosts per VSM x 4 VSMs

640

64 hosts per VSM x 4 VSMs

384

64 hosts per VSM x 4 VSMs

640

64 hosts per VSM x 4 VSMs

VSM with Cisco NX-OS high availability

Yes

Yes

Yes

Yes

Yes

VEM running on hypervisor host machine

Yes

Yes

Yes

Yes

Yes

Cisco Nexus 1000V running on hypervisor host machine, features scalability

Yes

Yes

Yes

Yes

Yes

Software-only switch

Yes

No

No

No

No

Dedicated services appliance, such as the Cisco NAM

No

Yes

Yes

Yes

Yes

Installation similar to a standard Cisco switch

No

Yes

Yes

Yes

Yes

Network team manages the switch hardware

No

Yes

Yes

Yes

Yes

Note

The Cisco Nexus 1000V supports a hypervisor host machine that runs on VMware vSphere or Microsoft Hyper-V hypervisors.

The following figure compares running a VSM on a Cisco Nexus Cloud Services Platform with running a VSM on a virtual machine.

VM and Cisco Nexus Cloud Services Platform Comparison

Cisco Integrated Management Controller

The Cisco Integrated Management Controller (CIMC) is a software interface included with the Cisco Nexus Cloud Services Platform. CIMC allows you to configure Serial over LAN (SoL) access and set up remote management if the device becomes unreachable. For more information about remote management, see the Cisco Nexus Cloud Services Platform Software Installation and Upgrade Guide.

When you are installing the Cisco Nexus Cloud Services Platform, you have the option to configure the CIMC interface. For details, see the Cisco Nexus Cloud Services Platform Hardware Installation Guide.

Virtual Service Blades

The services hosted, created, and managed by the Cisco Nexus Cloud Services Platform family are called virtual service blades (VSBs).

Note

In this document, a Cisco Nexus 1000V Virtual Supervisor Module (VSM) refers to a service hosted on VMware vSphere, KVM, or Microsoft Hyper-V.

The Cisco Nexus 1010 can host up to six virtual service blades (VSBs) and the Cisco Nexus 1010-X can host up to ten VSBs. The Cisco Nexus 1110-S can host up to ten VSBs and the Cisco Nexus 1110-X can host up to 14 VSBs.

VSBs are created using ISO or OVA image files found in the Cisco Nexus Cloud Services Platform bootflash:repository. The ISO defines the following for a VSB:

- Required number of interfaces

- Required hard disk emulation

- Disk and RAM defaults

- Type of VSB

For more information about VSBs, see Information About Virtual Service Blades.

For information about supported VSBs, software compatibility, and the weighing matrix to determine the maximum capacity on the Cisco Nexus Cloud Services Platform, see the Cisco Nexus Cloud Services Platform Compatibility Information.

Uplinks

This section describes the uplinks that you connected during your installation of the hardware. For more information about these connections and the prerequisites for the switches that are upstream from your Cisco Nexus Cloud Services Platform, see the Cisco Nexus Cloud Services Platform Hardware Installation Guide.

- Traffic Classification

Traffic Classification

The following table describes the classes of network traffic carried on the Cisco Nexus Cloud Services Platform uplinks.

Traffic Class

Data Packets Exchanged

Management

For Cisco Nexus Cloud Services Platform and VSB management such as the following:

- Telnet

- Secure Shell (SSH)

- HTTP

Note:
If your VSB uses the management class of traffic, it inherits the management VLAN from the Cisco Nexus Cloud Services Platform.

Control

- Between the Cisco Nexus 1000V VSMs (VSBs) and VEMs.

- Between redundant Cisco Nexus Cloud Services Platform active and standby supervisors.

- Between redundant Cisco Nexus 1000V active and standby VSMs.

Data

- VSB traffic that is not classified as either management or control.

- High volume, application-specific traffic between virtual interfaces.

- Traffic that is not considered management for other VSBs should be isolated to a separate interface and classified as data. If the same interface is used for both management and data, as is the case with NAM, the traffic is classified as data.

Note:
Cisco Nexus 1000V VSM VSB traffic is not classified as data traffic.

Network Uplink Configuration

Starting in Release 5.2(1)SP1(7.1), the Cisco Nexus Cloud Services Platform supports a flexible network topology by default. A flexible network uplink offers complete flexibility to connect the Cisco Nexus 1110-S or Cisco Nexus 1110-X to the network, and allows flexible deployment of the virtual service blades (VSB) on the Cisco Nexus Cloud Services Platform. A flexible configuration enables appropriate traffic segregation policies such as VSB traffic segregation. In the default flexible network uplink configuration, each physical port acts as an individual uplink. You can change the default configuration by adding ports to a port channel or by assigning uplinks to a VSB interface.

For more information on the flexible network uplink configuration, see Default Network Uplink Configuration.

The following figures show the flexible network uplink configured by default with or without vPC and Virtual Switching System (VSS).

Flexible Network Uplink Without vPC or VSS (Default)

Flexible Network Uplink with vPC or VSS (Default)

Chapter 3. Setting Up Remote Management

This chapter contains the following sections:

- Information About Remote Management

- Configuring Remote Management

- Feature History for Remote Management

Information About Remote Management

You can add remote management to your redundant Cisco Nexus Cloud Services Platform startup configuration so that if one pair becomes unreachable, the other can automatically attempt to recover it.

If redundant Cisco Nexus Cloud Services Platforms cannot communicate with each other over the management and control interfaces, they can both become active simultaneously. This process is known as a split-brain conflict. A Cisco Nexus Cloud Services Platform cannot be rebooted from its peer switch using high availability.

If one Cisco Nexus Cloud Services Platform becomes unreachable, its peer becomes active if it is the standby. If you have configured remote management, the new active Cisco Nexus Cloud Services Platform can attempt to power cycle its unreachable peer switch through the mgmt0 port of its Cisco Integrated Management Controller (CIMC) interface if CIMC is reachable on the peer. The active Cisco Nexus Cloud Services Platform starts the reboot code immediately when the standby is lost. The standby Cisco Nexus Cloud Services Platform waits 60 seconds before starting the reboot code.

For more information about losing communication between redundant Cisco Nexus Cloud Services Platforms, see the Cisco Nexus 1000V High Availability and Redundancy Configuration Guide.

For more information about CIMC, see Cisco Integrated Management Controller.

Configuring Remote Management

You can set up remote management in the startup configuration to recover an unreachable Cisco Nexus Cloud Services Platform peer switch through the mgmt0 port of its CIMC software.

Use the following procedure to set up remote management for the primary and secondary Cisco Nexus Cloud Services Platform.

Before You Begin

- You have previously configured the CIMC when installing the Cisco Nexus Cloud Services Platform. For more information, see the Cisco Nexus Cloud Services Platform Hardware Installation Guide.

- Know the following information for the Cisco Nexus Cloud Services Platform:

- CIMC management port IP address

- CIMC administrator login and password

- Log in to the active Cisco Nexus Cloud Services Platform in EXEC mode.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # nexus1010-system remote-mgmt primary ip ipaddr username username password password

Sets up remote management in the running configuration of the primary Cisco Nexus Cloud Services Platform. The arguments are as follows:

- ipaddress—IP address of the CIMC management port

- username—admin username for the CIMC management software

- password—admin password for the CIMC management software

Step 3

switch (config) # nexus1010-system remote-mgmt secondary ip ipaddr username username password password

Sets up remote management in the running configuration of the secondary Cisco Nexus Cloud Services Platform. The arguments are as follows:

- ipaddress—IP address of the CIMC management port

- username—admin username for the CIMC management software

- password—admin password for the CIMC management software

Step 4

switch (config) # show running-config

(Optional)
Displays the running configuration, including the remote management configuration for verification.

Step 5

switch (config) # copy running-config startup-config

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

This example shows how to configure remote management and display the running configuration:

switch# configure terminal
switch(config)# nexus-system remote-mgmt
primary ip 172.23.181.132 username
admin password password
Note: User must ensure the login and password matches CIMC login credentials.
switch(config)# nexus-system remote-mgmt secondary ip 172.23.180.184 username admin password password
Note: User must ensure the login and password matches CIMC login credentials.
switch(config)# show run

!Command: show running-config
!Time: Wed May 21 10:03:22 2014

version 5.2(1)SP1(7.1)
hostname switch

feature telnet
no feature http-server

username admin password 5 $1$5Ugkc3a7$VhMJcRReBuu0/3/oHftbU.  role network-admin
username admin keypair rsa

banner motd #Cisco VSA
#

ip domain-lookup
ip host switch 172.23.180.107
errdisable recovery cause failed-port-state
snmp-server user admin network-admin auth md5 0xb64ad6879970f0e57600c443287a79f0
priv 0xb64ad6879970f0e57600c443287a79f0 localizedkey
rmon event 1 log trap public description FATAL(1) owner PMON@FATAL
rmon event 2 log trap public description CRITICAL(2) owner PMON@CRITICAL
rmon event 3 log trap public description ERROR(3) owner PMON@ERROR
rmon event 4 log trap public description WARNING(4) owner PMON@WARNING
rmon event 5 log trap public description INFORMATION(5) owner PMON@INFO

vrf context management
ip route 0.0.0.0/0 172.23.180.1
vlan 1,180,366

port-channel load-balance ethernet source-mac
port-profile default max-ports 32
port-profile default port-binding static
port-profile type vethernet N1K_Cloud_Default_Trunk
switchport mode trunk
no shutdown
guid fd7b724c-03f0-4fc0-90a4-02b482918b3a
max-ports 64
description Port Profile created for Nexus 1000V internal usage. Do not use.
state enabled

system storage-loss log time 30
system inter-sup-heartbeat time 15
interface Ethernet1
channel-group 1 mode active
interface Ethernet2
interface Ethernet3
channel-group 1 mode active
interface Ethernet4
interface Ethernet5
interface Ethernet6
interface PortChannel1
svs-domain
control uplink Ethernet2
management uplink Ethernet2
virtual-service-blade VSM
virtual-service-blade-type name VSM-1.3
interface control vlan 366
interface control uplink Ethernet4
interface management vlan 180
interface management uplink Ethernet2
interface packet vlan 366
interface packet uplink PortChannel1
ramsize 3072
crypto-offload 10000
disksize 3
numcpu 1
cookie 1315634022
no shutdown primary
no shutdown secondary
interface VsbEthernet1/1
interface VsbEthernet1/2
interface VsbEthernet1/3
virtual-service-blade vxgw
virtual-service-blade-type name vx-gw-1.5
interface gw-uplink1 uplink Ethernet5
interface gw-uplink1 mode passthrough
interface management vlan 180
interface management uplink Ethernet2
interface gw-uplink2 vlan 366
interface gw-uplink2 uplink Ethernet2
ramsize 2048
disksize 3
numcpu 3
cookie 628175011
no shutdown primary
interface VsbEthernet2/1
interface VsbEthernet2/2
interface VsbEthernet2/3

interface mgmt0
ip address 172.23.180.107/24

interface control0
line console
line vty
boot kickstart bootflash:/nexus-1010-kickstart.5.2.1.SP1.7.1.bin
boot system bootflash:/nexus-1010.5.2.1.SP1.7.1.bin
boot kickstart bootflash:/nexus-1010-kickstart.5.2.1.SP1.7.1.bin
boot system bootflash:/nexus-1010.5.2.1.SP1.7.1.bin
svs-domain
domain id 638
control vlan 366
management vlan 180
svs mode L2
switch-guid 19147832-15eb-47ca-a797-f1bd3b34f8ea

switch#

Feature History for Remote Management

This section provides the remote management release history.

Feature Name

Releases

Feature Information

Remote Management

4.0(4)SP1(1)

This feature was introduced.

Chapter 4. Configuring the Network Uplinks

This chapter contains the following sections:

- Information About Network Uplink Configurations

- Support for Cisco UCS VIC 1225 10-Gbps Dual-Port NICs

- Configuring Port Channels

- Deleting Port Channels

- Assigning Uplinks to a VSB Interface

- Manually Assigning Uplinks to a VSB Interface

- Assigning a Native VLAN to a Port Channel

- Shutting Down Ports or Port Channel Interfaces

- Verifying the Uplink Configuration

- Passthrough Interfaces

- Feature History for Uplinks

Information About Network Uplink Configurations

Starting in Release 5.2(1)SP1(7.1), the Cisco Nexus Cloud Services Platform supports only a flexible network uplink configuration to connect to the network. When you perform a new installation of the Cisco Nexus Cloud Services Platform, you cannot choose the network uplink topology. If you are upgrading to Release 5.2(1)SP1(7.1) from an earlier release of the Cisco Nexus Cloud Services Platform, your existing topology will automatically convert to a flexible network uplink topology.

- Default Network Uplink Configuration

- Network Uplink Configuration Examples

Default Network Uplink Configuration

You can use the default network uplink configuration to connect the Cisco Nexus Cloud Services Platform to the network and enable traffic segregation policies such as virtual service blade (VSB) traffic segregation.

The network uplink configuration consists of the following features:

- Complete flexibility in terms of port configuration and usage.

- Flexible building of ports into a port channel.

- Flexible assignment of a port or port channel to a VSB interface.

- Easy uplink configuration.

- Ability to achieve maximum uplink.

- Every physical port individually forms an uplink.

- Each uplink can be configured independently.

- No default redundancy for uplinks.

- Ability to bundle physical ports into a port channel.

- VSB traffic is segregated by default.

- You can manually configure a VSB interface to share a port.

Network Uplink Configuration Examples

You can make changes to the default network uplink configuration to suit your needs. However, you must ensure that you do the following when you configure the network uplinks:

- Assign the control and management uplinks to an interface. These interfaces can be single or port channel interfaces.

- Assign a native VLAN to the port channel interfaces.

You can use physical ports as individual uplinks or you can bundle these uplinks into a port channel. The network uplink configuration is flexible because you can bundle ports into a port channel.

See the following figures for more information about how to assign the uplinks to an interface and how to assign a native VLAN.
Assigning Uplinks to a Flexible Network Configuration

Adding Port Channels to a Flexible Network Configuration

Support for Cisco UCS VIC 1225 10-Gbps Dual-Port NICs

The Cisco Nexus 1110-X has two Peripheral Component Interconnect (PCI) slots that are shipped with the Cisco UCS VIC 1225 10-Gbps Dual-Port NIC (10-Gbps card) and the Intel 1-Gbps quad-port NIC.

Starting with Release 5.2(1)SP1(7.1), you can switch the Cisco UCS 10-Gbps card and Cavium’s NITROX Crypto Compression card in the same PCI slot. You can replace the Cisco UCS 10-Gbps card or the Intel 1-Gbps quad-port NIC with a Cavium NITROX Crypto Compression card for offloading the security processing on the Cisco Nexus Cloud Services Platform. For information about inserting and switching the Cisco UCS 10-Gbps Dual Port NIC or the Intel 1-Gbps quad-port cards with the Cavium NITROX Crypto Compression card, see the Cisco Nexus Cloud Services Platform Hardware Installation Guide.

Caution

The Cisco Nexus Cloud Services Platform does not boot up if either of the PCI slots fails to detect the appropriate inserted card. For information about the correct slots to insert the cards on the Cisco Nexus Cloud Services Platform, see the Cisco Nexus Cloud Services Platform Hardware Installation Guide.

Enabling the Cisco UCS 10-Gbps Dual-Port NIC on the Cisco Nexus 1110-X depends on the installation type you choose.

- If you are upgrading to Release 5.2(1)SP1(7.1) from an earlier release of the Cisco Nexus Cloud Services Platform, the Cisco UCS 10-Gbps Dual-Port NIC is listed as part of the installed hardware. You can then assign uplinks to it or form a port channel with another Cisco UCS 10-Gbps port.

Note

The Cisco UCS 10-Gbps interface card is enabled only for the Cisco Nexus 1110-X model. If the Cisco UCS 10-Gbps card is enabled, it is detected as Ethernet 7 and Ethernet 8 on the Cisco Nexus 1110-X.

- If you are performing a new installation of the Cisco Nexus 1110-X, the Cisco Nexus Cloud Services Platform software detects the Cisco UCS 10-Gbps NIC, prompts you to choose a control or management VLAN to be added to the interface, and provides a choice to configure the interface as a port channel. For more information about the installation procedure, see the Cisco Nexus Cloud Services Platform Software Installation and Upgrade Guide.

Caution

A Cisco UCS 10-Gbps interface can form a port channel only with another Cisco UCS 10-Gbps interface.

- Starting in Release 5.2(1)SP1(7.1), interface names on the Cisco Nexus Cloud Services Platform are changed from Gigabit Ethernet to Ethernet. The Cisco UCS 10-Gbps interfaces are listed under Ethernet 7 and Ethernet 8.

- Guidelines and Limitations for Enabling the Cisco UCS 10-Gbps Card

- Enabling a Cisco UCS 10-Gbps Card

Guidelines and Limitations for Enabling the Cisco UCS 10-Gbps Card

The following are the guidelines and limitations for using the Cisco UCS 10-Gbps card on the Cisco Nexus Cloud Services Platform:

- The Cisco Nexus Cloud Services Platform allows only a symmetric configuration of the Cisco UCS 10-Gbps card in high availability (HA) mode.

- You can configure the Cisco UCS 10-Gbps card on the Cisco Nexus Cloud Services Platform when a:

- Cisco Nexus 1110-X in standalone mode detects a Cisco UCS 10-Gbps interface installed on it.

- Cisco Nexus 1110-X in HA mode and its pair both detect the Cisco UCS 10-Gbps interface installed on them.

Note

If the Cisco UCS 10-Gbps card is not detected while enabling a VSB on the Cisco Nexus Cloud Services Platform, the appliance goes into shutdown mode.

Enabling a Cisco UCS 10-Gbps Card

You can enable the Cisco UCS 10-Gbps interface in the appropriate PCI slot by upgrading to Cisco Nexus Cloud Services Platform, Release 5.2(1)SP1(7.1), or by performing a new installation as follows:

- Insert the Cisco UCS 10-Gbps card in the appropriate PCI slot on the Cisco Nexus Cloud Services Platform. For details, see the Cisco Nexus Cloud Services Platform Hardware Installation Guide.

- Upgrade to Release 5.2(1)SP1(7.1); the software detects the presence of the interface automatically.

Configuring Port Channels

You can configure the port channels in the Cisco Nexus Cloud Services Platform in a flexible network uplink configuration.

Before You Begin

- Log in to the CLI in EXEC mode.

- You must group the ports together in either HA or LACP mode.

- You must ensure that the ports are not used by any other port channel or by any VSB interface. To delete a port, see Deleting Port Channels.

- Know that an Ethernet interface with a conflicting native VLAN cannot be part of an existing port channel.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# [no] interface name id

Enters the configuration mode for the port channel or creates a port channel ID if the port channel does not exist. The valid range for the ID is from 1 to 6.

Step 3

switch(config)# interface Ethernet name

Enters the interface configuration mode for the named interface. The interface names can be Gigabit Ethernet only.

Step 4

switch (config-if) # channel-group id mode {ha | active}

Assigns an Ethernet interface to a port channel and sets the desired mode. The mode can be either HA or Active.

Step 5

switch (config-if) # exit

Exits interface configuration mode and returns to global configuration mode.

Step 6

switch (config) # exit

Exits global configuration mode and returns to EXEC mode.

Step 7

switch # show network port-channel summary

(Optional)
Displays a summary of the port channels in the network.

This example shows how to configure port channels and display summary information:

switch# configure terminal
switch(config)# interface portChannel 1
switch(config-if)# channel-group 1 mode active
switch(config-if)# exit
switch(config)# exit
switch# show network port-channel summary
Flags: D - Down P - Up in port-channel (members)
U - Up (port-channel)
-------------------------------------------------------------------------
Group Port-Channel Type Protocol Member-Ports
-------------------------------------------------------------------------
1 PortChannel1(U) eth LACP Eth3(P)

switch# configure terminal
switch(config)# interface portChannel 2
switch(config-if)# interface ethernet 4
switch(config-if)# channel-group 2 mode ha
switch(config-if)# exit
switch(config)# exit
switch# show network port-channel summary
Flags: D - Down P - Up in port-channel (members)
U - Up (port-channel)
-------------------------------------------------------------------------
Group Port-Channel Type Protocol Member-Ports
-------------------------------------------------------------------------
1 PortChannel1(U) eth LACP Eth3(P)
2 PortChannel2(U) eth HA Eth4(P)
switch(config-if)#

Deleting Port Channels

You can delete port channels. You must first delete ports from the port channel and then delete the port channel.

Before You Begin

- Log in to the CLI in EXEC mode.

- Shut down the virtual service blades using the port or the port channel that contains the port.

Procedure

Command or Action

Purpose

Step 1

switch # configure terminal

Enters global configuration mode.

Step 2

switch (config) # interface Ethernet name

Enters configuration mode for the named interface. The interface name can be Gigabit Ethernet only.

Step 3

switch (config-if) # no channel-group

Deletes the port channel.

This example shows how to delete port channels:

switch# configure terminal
switch(config)# interface Ethernet4
switch(config-if)# no channel-group

Assigning Uplinks to a VSB Interface

You can assign uplinks to a VSB interface.

Before You Begin

- Log in to the CLI in EXEC mode.

- Know that:

- By default, uplinks are assigned to the first available free port or port channel.

- If both free ports and port channels are available, free ports get preference over port channels.

- If no free ports are available, you must assign the uplink manually. For information about how to manually assign uplinks to a VSB interface, see Manually Assigning Uplinks to a VSB Interface.

- A VSB can have different uplinks for every port or port channel.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # virtual-service-blade name

Enters VSB configuration mode for the named VSB.

Step 3

switch (config-vsb-config) # [no] interface name uplink name

Assigns a VSB Ethernet interface to an uplink.

Step 4

switch (config-vsb-config) # exit

Exits VSB configuration mode and returns to global configuration mode.

Step 5

switch (config) # exit

Exits global configuration mode and returns to EXEC mode.

Step 6

switch # show network summary

(Optional)
Displays summary network information about VSB Ethernet interfaces assigned to an uplink.

This example shows how to assign uplinks to a VSB interface and display summary network information:

switch# configure terminal
switch(config)# virtual-service-blade vsm-5
switch(config-vsb-config)# interface control uplink PortChannel2
switch(config-vsb-config)# exit
switch(config)# exit
switch # show network summary

-----------------------------------------------------------------------------
Port     State     Uplink-Interface  Speed  RefCnt    MTU   Nat-Vlan
Oper     Admin        Oper  Admin                           Oper  Admin
------------------------------------------------------------------------------
Gi1    up     up                     1000       0   9000
Gi2    up     up                     1000       0   9000
Gi3    up     up                     1000       3   9000
Gi4  down     up                     1000       0   9000
Gi5  down     up                     1000       0   9000
Gi6  down     up                     1000       0   9000
Po1    up     up                     1000      13   9000
VsbEth6/1    up     up      Gi3    Gi3     1000           9000
VsbEth6/2    up     up      Gi3    Gi3     1000           9000
VsbEth6/3    up     up      Gi3    Gi3     1000           9000
control0    up     up      Po1    Po1     1000           9000
mgmt0    up     up      Po1    Po1     1000           9000

Manually Assigning Uplinks to a VSB Interface

You can manually assign uplinks to a VSB interface.

Before You Begin

Log in to the CLI in EXEC mode.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # virtual-service-blade name

Enters VSB configuration mode for the named VSB.

Step 3

switch (config-vsb-config) # interface control uplink name

Assigns a physical interface to the control uplink.

Step 4

switch (config-vsb-config) # interface management uplink name

Assigns a physical interface to the management uplink.

Step 5

switch (config-vsb-config) # interface packet uplink name

Assigns a physical interface to the packet uplink.

Step 6

switch (config-vsb-config) # exit

Exits VSB configuration mode and returns to global configuration mode.

Step 7

switch (config) # exit

Exits global configuration mode and returns to EXEC mode.

Step 8

switch # show network summary

(Optional)
Displays summary network information about VSB Ethernet interfaces assigned to an uplink.

This example shows how to manually assign uplinks to a VSB interface and display summary network information:

switch# configure terminal
switch(config)# virtual-service-blade vsm-5
switch(config-vsb-config)#  interface control uplink ethernet 4
switch(config-vsb-config)#  interface management uplink ethernet 4
switch(config-vsb-config)#  interface packet uplink ethernet 4
switch(config-vsb-config)# exit
switch(config)# exit
switch # show network summary

-----------------------------------------------------------------------------
Port     State     Uplink-Interface  Speed  RefCnt    MTU   Nat-Vlan
Oper     Admin        Oper  Admin                           Oper  Admin
------------------------------------------------------------------------------
Gi1    up     up                     1000       0   9000
Gi2    up     up                     1000       0   9000
Gi3    up     up                     1000       3   9000
Gi4  down     up                     1000       0   9000
Gi5  down     up                     1000       0   9000
Gi6  down     up                     1000       0   9000
Po1    up     up                     1000      13   9000
VsbEth6/1    up     up      Gi3    Gi3     1000           9000
VsbEth6/2    up     up      Gi3    Gi3     1000           9000
VsbEth6/3    up     up      Gi3    Gi3     1000           9000
control0    up     up      Po1    Po1     1000           9000
mgmt0    up     up      Po1    Po1     1000           9000

Assigning a Native VLAN to a Port Channel

You can configure a native VLAN that corresponds to an Ethernet interface. This procedure applies to flexible network uplink types. Native VLAN changes can take effect immediately, except for cases that involve the Cisco Nexus Cloud Services Platform VLANs and interfaces.

Before You Begin

- Log in to the CLI in EXEC mode.

- Know that:

- You cannot assign a native VLAN to an Ethernet interface that is a part of a port channel.

- You can add an Ethernet interface to a port channel only if the Ethernet interface and the port channel have the same native VLAN configuration.

- After you configure the native VLANs in the Cisco Nexus Cloud Services Platform, you must also configure all the upstream switches with the same native VLAN.

- When you modify the control or management native VLAN uplink configuration, you must first save the configuration and then shut down the Cisco Nexus Cloud Services Platform. You can change the native VLAN configuration on the uplink switch and then restart the Cisco Nexus Cloud Services Platform.

- When you delete an Ethernet interface from a port channel, it retains the native VLAN configuration.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # interface name

Enters configuration mode for the named interface. The interface names can be Ethernet or Portchannel.

Step 3

switch (config-if) # native vlan id

Modifies the native VLAN ID.

Step 4

switch (config-if) # exit

Exits interface configuration mode and returns to global configuration mode.

Step 5

switch (config) # exit

Exits global configuration mode and returns to EXEC mode.

Step 6

switch# show network summary

(Optional)
Displays the network summary.

This example shows how to assign a native VLAN to a port channel:

switch# configure terminal
switch(config)# interface portChannel 2
switch(config-if)# native vlan 2050
switch(config-if)# exit
switch(config)# exit
switch # show network summary

Legends: P - Passthrough
------------------------------------------------------------------------------
Port      State    Uplink-Interface    Speed   RefCnt   MTU    Nat-Vlan
Oper Admin Oper Admin Oper Admin
------------------------------------------------------------------------------
Eth1     up up                          1000     2       9000
Eth2     up up                          1000     6       9000
Eth3       up up                          1000     0       9000
Eth4     up up                               1000     0       9000
Eth5    down up                         1000     0       9000
Eth6     up up                          1000     0       9000
Po1     down up                         1000     0       9000
Po2     down up                         1000     0       9000
VsbEth2/1 up up            Eth2 Eth2    1000             9000
VsbEth2/2 up up            Eth2 Eth2    1000             9000
VsbEth2/3 up up            Eth2 Eth2    1000             9000
control0 up up             Eth1 Eth1    1000             9000
mgmt0    up up             Eth1 Eth1    1000             9000

Shutting Down Ports or Port Channel Interfaces

Before You Begin

Log in to the CLI in EXEC mode.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # interface name

Enters interface configuration mode for the specified interface.

Step 3

switch (config-if) # [no] shutdown [primary | secondary]

Shuts down the port or port channel interface. If a redundant pair of Cisco Nexus Cloud Services Platform is configured, you must specify whether to shut down the primary or secondary.

Step 4

switch (config-if) # show network summary

(Optional)
Displays the network summary.

Step 5

switch (config-if) # show network port-channel summary

(Optional)
Displays the network port channel summary.

The following example shows how to shut down ports or port channel interfaces:

switch# configure terminal
switch(config)# interface portChannel 3
switch(config-if)# shutdown primary
switch(config-if)# 2014 Oct 20 17:11:43 switch %SWITCH-AGENT_NOTIFICATION: Agent Notification: Interface PortChannel3 is DOWN.

switch(config-if)# show network summary

Legends:    P - Passthrough
------------------------------------------------------------------------------
Port     State     Uplink-Interface  Speed  RefCnt    MTU   Nat-Vlan
Oper  Admin   Oper    Admin                          Oper  Admin
------------------------------------------------------------------------------
Eth1    up     up                     1000       0   9000
Eth2    up     up                     1000       0   9000
Eth3    up     up                     1000       0   9000  2050   2050
Eth4    up     up                     1000       0   9000  2050   2050
Eth5    up     up                     1000       0   9000
Eth6    up     up                     1000       0   9000
Eth7    up     up                    10000       0   9000
Eth8    up     up                    10000       0   9000
Po1    up     up                     1000      11   9000
Po2    up     up                     1000       3   9000  2050   2050
Po3  down   down                     1000       3   9000
VsbEth1/1    up     up   Po3    Po3        1000           9000
VsbEth1/2    up     up   Po3    Po3        1000           9000
VsbEth1/3    up     up   Po3    Po3        1000           9000
VsbEth2/1    up     up   Po1    Po1        1000           9000
VsbEth2/2    up     up   Po2    Po2        1000           9000
VsbEth2/3    up     up   Po1    Po1        1000           9000
VsbEth3/1    up     up   Po1    Po1        1000           9000
VsbEth3/2    up     up   Po1    Po1        1000           9000
VsbEth3/3    up     up   Po1    Po1        1000           9000
VsbEth4/1    up     up   Po1    Po1        1000           9000
VsbEth4/2    up     up   Po2    Po2        1000           9000
VsbEth4/3    up     up   Po1    Po1        1000           9000
VsbEth5/1    up     up   Po1    Po1        1000           9000
VsbEth5/2    up     up   Po1    Po1        1000           9000
VsbEth5/3    up     up   Po1    Po1        1000           9000
control0    up     up   Po2    Po2        1000           9000
mgmt0    up     up   Po1    Po1        1000           9000
switch(config-if)# show network  port-channel summary
Flags:  D - Down  P - Up in port-channel (members)
U - Up (port-channel)
-------------------------------------------------------------------------
Group     Port-Channel  Type  Protocol        Member-Ports
-------------------------------------------------------------------------
1  PortChannel1(U)   eth       HA     Eth1(P) Eth2(P)
2  PortChannel2(U)   eth       HA     Eth3(P) Eth4(P)
3  PortChannel3(D)   eth       HA     Eth5(P) Eth6(P)

switch(config-if)# no shutdown primary
switch(config-if)# 2014 Oct 20 17:13:59 switch %SWITCH-AGENT_NOTIFICATION: Agent Notification: Interface PortChannel3 is UP.

switch(config-if)# show network  summary

Legends:    P - Passthrough
------------------------------------------------------------------------------
Port     State     Uplink-Interface  Speed  RefCnt    MTU   Nat-Vlan
Oper  Admin   Oper    Admin                          Oper  Admin
------------------------------------------------------------------------------
Eth1    up     up                     1000       0   9000
Eth2    up     up                     1000       0   9000
Eth3    up     up                     1000       0   9000  2050   2050
Eth4    up     up                     1000       0   9000  2050   2050
Eth5    up     up                     1000       0   9000
Eth6    up     up                     1000       0   9000
Eth7    up     up                    10000       0   9000
Eth8    up     up                    10000       0   9000
Po1    up     up                     1000      11   9000
Po2    up     up                     1000       3   9000  2050   2050
Po3    up     up                     1000       3   9000
VsbEth1/1    up     up   Po3    Po3        1000           9000
VsbEth1/2    up     up   Po3    Po3        1000           9000
VsbEth1/3    up     up   Po3    Po3        1000           9000
VsbEth2/1    up     up   Po1    Po1        1000           9000
VsbEth2/2    up     up   Po2    Po2        1000           9000
VsbEth2/3    up     up   Po1    Po1        1000           9000
VsbEth3/1    up     up   Po1    Po1        1000           9000
VsbEth3/2    up     up   Po1    Po1        1000           9000
VsbEth3/3    up     up   Po1    Po1        1000           9000
VsbEth4/1    up     up   Po1    Po1        1000           9000
VsbEth4/2    up     up   Po2    Po2        1000           9000
VsbEth4/3    up     up   Po1    Po1        1000           9000
VsbEth5/1    up     up   Po1    Po1        1000           9000
VsbEth5/2    up     up   Po1    Po1        1000           9000
VsbEth5/3    up     up   Po1    Po1        1000           9000
control0    up     up   Po2    Po2        1000           9000
mgmt0    up     up   Po1    Po1        1000           9000

switch(config-if)# show network  port-channel summary
Flags:  D - Down  P - Up in port-channel (members)
U - Up (port-channel)
-------------------------------------------------------------------------
Group     Port-Channel  Type  Protocol        Member-Ports
-------------------------------------------------------------------------
1  PortChannel1(U)   eth       HA     Eth1(P) Eth2(P)
2  PortChannel2(U)   eth       HA     Eth3(P) Eth4(P)
3  PortChannel3(U)   eth       HA     Eth5(P) Eth6(P)

switch(config-if)# shutdown secondary
switch(config-if)# attach module 2
Attaching to module 2 ...
To exit type 'exit', to abort type '$.'
Last login: Mon Oct 20 17:08:14 UTC 2014 from 127.1.1.2 on pts/0
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2014, 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(standby)# show network summary

Legends:    P - Passthrough
------------------------------------------------------------------------------
Port     State     Uplink-Interface  Speed  RefCnt    MTU   Nat-Vlan
Oper  Admin   Oper    Admin                          Oper  Admin
------------------------------------------------------------------------------
Eth1    up     up                     1000       0   9000
Eth2    up     up                     1000       0   9000
Eth3    up     up                     1000       0   9000  2050   2050
Eth4    up     up                     1000       0   9000  2050   2050
Eth5    up     up                     1000       0   9000
Eth6    up     up                     1000       0   9000
Eth7    up     up                    10000       0   9000
Eth8    up     up                    10000       0   9000
Po1    up     up                     1000      11   9000
Po2    up     up                     1000       3   9000  2050   2050
Po3  down   down                     1000       3   9000
VsbEth1/1    up     up   Po3    Po3        1000           9000
VsbEth1/2    up     up   Po3    Po3        1000           9000
VsbEth1/3    up     up   Po3    Po3        1000           9000
VsbEth2/1    up     up   Po1    Po1        1000           9000
VsbEth2/2    up     up   Po2    Po2        1000           9000
VsbEth2/3    up     up   Po1    Po1        1000           9000
VsbEth3/1    up     up   Po1    Po1        1000           9000
VsbEth3/2    up     up   Po1    Po1        1000           9000
VsbEth3/3    up     up   Po1    Po1        1000           9000
VsbEth4/1    up     up   Po1    Po1        1000           9000
VsbEth4/2    up     up   Po2    Po2        1000           9000
VsbEth4/3    up     up   Po1    Po1        1000           9000
VsbEth5/1    up     up   Po1    Po1        1000           9000
VsbEth5/2    up     up   Po1    Po1        1000           9000
VsbEth5/3    up     up   Po1    Po1        1000           9000
control0    up     up   Po2    Po2        1000           9000
mgmt0    up     up   Po1    Po1        1000           9000

switch(standby)# show network port-channel summary
Flags:  D - Down  P - Up in port-channel (members)
U - Up (port-channel)
-------------------------------------------------------------------------
Group     Port-Channel  Type  Protocol        Member-Ports
-------------------------------------------------------------------------
1  PortChannel1(U)   eth       HA     Eth1(P) Eth2(P)
2  PortChannel2(U)   eth       HA     Eth3(P) Eth4(P)
3  PortChannel3(D)   eth       HA     Eth5(P) Eth6(P)

switch(standby)# exit
switch(config-if)# no shutdown secondary

switch(config-if)# attach module 2
Attaching to module 2 ...
To exit type 'exit', to abort type '$.'
Last login: Mon Oct 20 17:08:14 UTC 2014 from 127.1.1.2 on pts/0
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2014, 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(standby)# show network port-channel summary
Flags:  D - Down  P - Up in port-channel (members)
U - Up (port-channel)
-------------------------------------------------------------------------
Group     Port-Channel  Type  Protocol        Member-Ports
-------------------------------------------------------------------------
1  PortChannel1(U)   eth       HA     Eth1(P) Eth2(P)
2  PortChannel2(U)   eth       HA     Eth3(P) Eth4(P)
3  PortChannel3(U)   eth       HA     Eth5(P) Eth6(P)

Verifying the Uplink Configuration

To verify the uplink configuration, use the following commands:

Command

Purpose

show network

Displays information about the network.

show network cdp neighbors

Displays uplink connectivity for the active or standby Cisco Nexus Cloud Services Platform.

show network counters

Displays statistical information about the network.

show network summary

Displays summary information about the network.

show network port-channel summary

Displays summary information about port channels in the network.

show network uplink

Displays information about network uplinks.

Example: show network

This example shows how to display information about the network:

switch# show network

Example: show network cdp neighbors

This example shows how to display information about the network CDP neighbors:

switch# show network cdp neighbors
Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge
S - Switch, H - Host, I - IGMP, r - Repeater,
V - VoIP-PEthernet1 is up
Hardware: Ethernet, address: 68ef.bdf6.1d46 (bia 68ef.bdf6.1d46)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
61192399 packets input, 12117620046 bytes
173137 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
1474009 packets output, 2009606616 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet2 is up
Hardware: Ethernet, address: 68ef.bdf6.1d47 (bia 68ef.bdf6.1d47)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
38590566 packets input, 7510824311 bytes
206041 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
1862 packets output, 194816 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet3 is up
Hardware: Ethernet, address: 0010.1857.5800 (bia 0010.1857.5800)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
38590549 packets input, 7819154927 bytes
206046 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
826 packets output, 150332 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet4 is up
Hardware: Ethernet, address: 0010.1857.5802 (bia 0010.1857.5802)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
43399753 packets input, 5813744893 bytes
101075 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
826 packets output, 150332 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet5 is down (not connected)
Hardware: Ethernet, address: 0010.1857.5804 (bia 0010.1857.5804)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
0 packets input, 0 bytes
0 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
0 packets output, 0 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet6 is up
Hardware: Ethernet, address: 0010.1857.5806 (bia 0010.1857.5806)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
43399753 packets input, 5813744893 bytes
101075 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
826 packets output, 150332 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

VsbEthernet1/1 is up
Hardware: Ethernet, address: 0002.3d71.0b02 (bia 0002.3d71.0b02)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
1037 packets input, 47878 bytes
0 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
3471317 packets output, 285476658 bytes
0 underrun, 0 output errors, 0 collisions
1 fifo, 0 carrier errors

VsbEthernet2/1 is up
Hardware: Ethernet, address: 0002.3d71.0b04 (bia 0002.3d71.0b04)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
9892 packets input, 965387 bytes
0 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
7 packets output, 540 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

VsbEthernet2/2 is up
Hardware: Ethernet, address: 0002.3d71.0b03 (bia 0002.3d71.0b03)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
9846 packets input, 947803 bytes
0 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
17333725 packets output, 6611457932 bytes
0 underrun, 0 output errors, 0 collisions
4 fifo, 0 carrier errors

VsbEthernet2/3 is up
Hardware: Ethernet, address: 0002.3d71.0b05 (bia 0002.3d71.0b05)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
11 packets input, 900 bytes
0 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
9887 packets output, 964937 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errorshone, D - Remotely-Managed-Device,
s - Supports-STP-Dispute

Device-ID             Local Intrfce    Hldtme Capability  Platform      Port ID

sfish-cat3k-K5-stack2 GigabitEthernet1  173    S I       cisco WS-C375 GigabitEthernet1/0/45
sfish-cat3k-K5-stack1 GigabitEthernet2  133    S I       cisco WS-C375 GigabitEthernet1/0/45
sfish-cat3k-K5-stack2 GigabitEthernet3  173    S I       cisco WS-C375 GigabitEthernet1/0/46
sfish-cat3k-K5-stack1 GigabitEthernet4  133    S I       cisco WS-C375 GigabitEthernet1/0/46

Example: show network counters

This example shows how to display information about the network statistics:

switch# show network counters
-----------------------------------------------------------------------
Port       InOctets    InUcastPkts    InMcastPkts
-----------------------------------------------------------------------
Ethernet1    12138620790       61319787         173442
Ethernet2     7522937938       38666311         206370
Ethernet3     7832218009       38670779         206381
Ethernet4     5825527684       43498917         101282
Ethernet5              0              0              0
Ethernet6     5825527684       43498917         101282
VsbEthernet1/1          47970           1039              0
VsbEthernet2/1         966798           9907              0
VsbEthernet2/2         949211           9861              0
VsbEthernet2/3            900             11              0
-----------------------------------------------------------------------
Port      OutOctets   OutUcastPkts   OutMcastPkts
-----------------------------------------------------------------------
Ethernet1     2009685197        1474325         173442
Ethernet2         195086           1865         206370
Ethernet3         150514            827         206381
Ethernet4         150514            827         101282
Ethernet5              0              0              0
Ethernet6         150514            827         101282
VsbEthernet1/1      285917126        3478128              0
VsbEthernet2/1            540              7              0
VsbEthernet2/2     6621327414       17361515              0
VsbEthernet2/3         966348           9902              0

Example: show network summary

This example shows how to display the network summary:

switch# show network summary

Legends:    P - Passthrough
------------------------------------------------------------------------------
Port     State     Uplink-Interface  Speed  RefCnt    MTU   Nat-Vlan
Oper  Admin   Oper    Admin                          Oper  Admin
------------------------------------------------------------------------------
Eth1    up     up                     1000       5   9000
Eth2    up     up                     1000       1   9000
Eth3    up     up                     1000       0   9000
Eth4    up     up                     1000       0   9000
Eth5  down     up                     1000       0   9000
Eth6    up     up                     1000       0   9000
VsbEth1/1    up     up  Eth2   Eth2        1000           9000
VsbEth2/1    up     up  Eth1   Eth1        1000           9000
VsbEth2/2    up     up  Eth1   Eth1        1000           9000
VsbEth2/3    up     up  Eth1   Eth1        1000           9000
control0    up     up  Eth1   Eth1        1000           9000
mgmt0    up     up  Eth1   Eth1        1000           9000
switch#

Example: show network port-channel summary

This example shows how to display the network port channel summary:

switch# show network port-channel summary
Flags:  D - Down  P - Up in port-channel (members)
U - Up (port-channel)
-------------------------------------------------------------------------
Group     Port-Channel  Type  Protocol        Member-Ports
-------------------------------------------------------------------------

Example: show network uplinks

This example shows how to display information about the network uplinks:

switch# show network uplinks
Ethernet1 is up
Hardware: Ethernet, address: 68ef.bdf6.1d46 (bia 68ef.bdf6.1d46)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
61433728 packets input, 12158205983 bytes
173769 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 21 fifo
1474730 packets output, 2009784594 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet2 is up
Hardware: Ethernet, address: 68ef.bdf6.1d47 (bia 68ef.bdf6.1d47)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
38749322 packets input, 7534956327 bytes
206801 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
1869 packets output, 195534 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet3 is up
Hardware: Ethernet, address: 0010.1857.5800 (bia 0010.1857.5800)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
38749269 packets input, 7844543273 bytes
206806 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
829 packets output, 150878 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet4 is up
Hardware: Ethernet, address: 0010.1857.5802 (bia 0010.1857.5802)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
43587903 packets input, 5837193453 bytes
101455 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
829 packets output, 150878 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet5 is down (not connected)
Hardware: Ethernet, address: 0010.1857.5804 (bia 0010.1857.5804)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
0 packets input, 0 bytes
0 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
0 packets output, 0 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Ethernet6 is up
Hardware: Ethernet, address: 0010.1857.5806 (bia 0010.1857.5806)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
full-duplex, 1000 Mb/s
Auto-Negotiation is turned on
43587905 packets input, 5837193653 bytes
101455 multicast frames, 0 compressed
0 input errors, 0 frame, 0 overrun, 0 fifo
829 packets output, 150878 bytes
0 underrun, 0 output errors, 0 collisions
0 fifo, 0 carrier errors

Passthrough Interfaces

You can configure a Cisco Nexus Virtual Extensible Local Area Network (VXLAN) gateway virtual service blade (VSB) or a Citrix NetScaler 1000V to function as a passthrough interface. The passthrough feature enables a VSB to assign a virtual interface to a dedicated uplink. This uplink can be an Ethernet port on the Cisco Nexus Cloud Services Platform or a port channel. For more information, see Setting Up a Passthrough VSB Interface.

Note

1. You must upgrade to Cisco Nexus Cloud Services Platform, Release 5.2(1)SP1(7.1) or perform a new installation before you configure the VSB in the passthrough mode.

2. Passthrough is not supported on the Cisco UCS VIC 1225 10-Gbps interface.

- To create a port channel, see Configuring Port Channels.

- To assign uplinks to a VSB interface, see Assigning Uplinks to a VSB Interface.

- To set up a VSB interface in passthrough mode, see Setting Up a Passthrough VSB Interface.

Feature History for Uplinks

This section provides the uplinks feature release history.

Feature Name

Releases

Feature Information

Recommendations for freeing ports for setting up new VSBs as passthrough interfaces

4.2(1)SP1(6.1)

These recommendations were introduced.

Flexible Network Uplink

4.0(4)SP1(4)

This feature was introduced.

Uplink

4.0(4)SP1(4)

This feature was introduced.

Chapter 5. Configuring Virtual Services Blades

This chapter contains the following sections:

- Information About Virtual Service Blades

- Cisco Nexus 1000V VSM Virtual Service Blades

- Cisco Network Analysis Module Virtual Service Blades

- Cisco Virtual Security Gateway Module Virtual Service Blades

- Cisco Data Center Network Manager Virtual Service Blades

- Cisco Nexus VXLAN Gateway Virtual Service Blades

- Citrix NetScaler 1000V Virtual Service Blades

- Cisco Nexus 1000V for KVM Virtual Service Blades

- Virtual Service Blade Management VLAN

- Virtual Service Blade High Availability

- Role Collision Detection

- Guidelines and Limitations for Virtual Service Blades

- Crypto and SSL Offloading in Virtual Service Blades

- Configuration Examples for Virtual Service Blades

- Verifying the Virtual Service Blade Configuration

- MIBs

- Feature History for Virtual Service Blades

Information About Virtual Service Blades

The Cisco Nexus Cloud Services Platform manages services called virtual service blades (VSBs). The VSBs are created using ISO or OVA files found in the Cisco Nexus Cloud Services Platform bootflash:repository. The ISO or OVA defines the following for a VSB:

- Required number of interfaces

- Required hard disk emulation

- Disk and RAM defaults

Note

The Cisco Nexus Cloud Services Platform supports the Cisco Nexus 1000V Virtual Supervisor Modules (VSMs) for VMware vSphere, the Microsoft Hyper-V, and KVM hypervisors.

Cisco Nexus Cloud Services Platform supports the following VSB types:

- Cisco Nexus 1000V

- Cisco Network Analysis Module Virtual Service Blade

- Cisco Virtual Security Gateway Module Virtual Service Blade

- Cisco Nexus VXLAN Gateway Virtual Service Blades

- Citrix NetScaler 1000V Virtual Service Blades

- Cisco Nexus 1000V for KVM Virtual Service Blades

For information about the supported VSBs and their weighting matrix, see the Cisco Nexus Cloud Services Platform Compatibility Information.

Cisco Nexus 1000V VSM Virtual Service Blades

The Cisco Nexus Cloud Services Platform supports the Cisco Nexus 1000V Virtual Supervisor Module (VSM) for VMware vSphere, KVM, and Microsoft Hyper-V hypervisors.

The Cisco Nexus 1110-S can host up to six VSMs and the Cisco Nexus 1110-X can host up to ten VSMs. Each VSM controls a group of virtual Ethernet modules (VEMs). From a network management perspective, a VSM and its VEMs make up a virtual switch. The Cisco Nexus Cloud Services Platform and the multiple virtual switches that it hosts are viewed as a cluster of switches.

You can create redundant VSMs on the Cisco Nexus Cloud Services Platform with the Cisco Nexus 1000V ISO or OVA image that is located in the bootflash:repository. The image is copied to a new VSB when you create it. After you create the first VSM, you can point to that software image to create additional VSMs. You can upgrade your VSMs to a new release of Cisco Nexus 1000V software as needed.

To create a VSM virtual service blade, see Creating a Virtual Service Blade.

Cisco Network Analysis Module Virtual Service Blades

You can create a Network Analysis Module (NAM) on the Cisco Nexus Cloud Services Platform with the NAM ISO image in the Cisco Nexus 1010 bootflash:repository. This image is copied to a new NAM VSB when you create it. To create a VSB for NAM, see Creating a Virtual Service Blade.

For more information about NAM, see the Cisco Network Analysis Module Software Documentation Guide.

Cisco Virtual Security Gateway Module Virtual Service Blades

You can create up to three Cisco Virtual Security Gateway (VSG) modules on the Cisco Nexus Cloud Services Platform with the Cisco VSG ISO image. You can copy the Cisco VSG ISO image from Cisco.com and then copy it to the new Cisco VSG VSB when you create it.

The Cisco Nexus Cloud Services Platform does not support:

- OVA deployment and migration on the Cisco VSG VSB.

- VSG deployment in standalone mode. We recommend that you deploy VSG as an HA pair on the Cisco Nexus Cloud Services Platform.

Cisco Data Center Network Manager Virtual Service Blades

Cisco Data Center Network Manager (DCNM) is an advanced management software that provides comprehensive lifecycle management of the LAN and SAN data center.

You can create one Cisco DCNM on the Cisco Nexus Cloud Services Platform with the Cisco DCNM ISO image in the Cisco Nexus Cloud Services Platform bootflash:repository. The image is copied to a new Cisco DCNM VSB when you create it.

Note

The Cisco DCNM VSB is supported only on the Cisco Nexus 1010 and the Cisco Nexus 1010-X.

For more information about installing Cisco DCNM on the Cisco Nexus Cloud Services Platform, see the Cisco DCNM Installation and Licensing Guide.

Cisco Nexus VXLAN Gateway Virtual Service Blades

The VXLAN gateway is a Layer 2 gateway that extends the virtual extensible LAN (VXLAN) Layer 2 domain to physical servers and services deployed on a VLAN. A VXLAN gateway is created when a Layer 2 adjacency is required between virtual machines on a VXLAN and physical servers and services on a VLAN.

A VXLAN gateway is managed as a Virtual Ethernet Module (VEM) from the Cisco Nexus 1000V Virtual Supervisor Module (VSM) and defines the mapping between a VXLAN and VLAN on a VSM. The VXLAN gateway acts as a bridge between the VXLAN and the VLAN to direct traffic to and from the VXLAN to a traditional VLAN.

You can copy the VXLAN gateway ISO image from Cisco.com and then copy it to the new VXLAN gateway VSB when you create it.

Note

The Cisco Nexus Cloud Services Platform does not support OVA deployment and migration on a VXLAN gateway VSB.

For more information about installing and configuring a VXLAN gateway as a VSB, see the Cisco Nexus 1000V VXLAN Configuration Guide.

Citrix NetScaler 1000V Virtual Service Blades

Citrix NetScaler 1000V is a virtual appliance that provides load-balancing and traffic management capabilities. The Citrix NetScaler 1000V enables application-aware Layer 7 content switching and fundamental Layer 4 load-balancing, that feature health checks, session persistence mechanisms, and load-balancing algorithms to ensure traffic is always sent to the most appropriate server. The global server load-balancing feature on the Citrix NetScaler 1000V enhances disaster recovery by redirecting users to alternate data centers if an outage or interruption occurs.

You can deploy the Citrix NetScaler 1000V on the Cisco Nexus Cloud Services Platform as a Virtual Service Blade (VSB). The Citrix NetScaler 1000V hosted on a Cisco Nexus Cloud Services Platform gives you the flexibility to use two vCPU or six vCPU deployments for high performance. The Cisco Nexus Cloud Services Platform HA also enables Citrix NetScaler 1000V high availability.

For more information, see the Citrix NetScaler 1000V documentation at Click Here .

Cisco Nexus 1000V for KVM Virtual Service Blades

The Cisco Nexus 1000V for KVM is a virtual distributed switch that works with the Linux Kernel-based virtual machine (KVM) open source hypervisor. The Linux KVM hypervisor is ideally suited for OpenStack environments. Using the Cisco Nexus 1000V for KVM Virtual Supervisor Module (VSM), you can create policy profiles (called port profiles on the VSM), which define port classification information, such as security settings (access control lists [ACLs], and so on). When a virtual machine (VM) is deployed, a port profile is dynamically created on the Cisco Nexus 1000V for KVM for each unique combination of policy port profile and network segment. All other VMs deployed with the same policy to this network reuse this dynamic port profile.

You can use the Cisco Nexus 1000V for KVM as a VSB on the Cisco Nexus Cloud Services Platform. For more information about the Cisco Nexus 1000V for KVM, see the Cisco Nexus 1000V for KVM Virtual Network Configuration Guide. For information about the supported version of the Cisco Nexus 1000V for KVM, see the Cisco Nexus Cloud Services Platform Compatibility Information.

Virtual Service Blade Management VLAN

Starting in Release 5.2(1)SP1(7.1), the management VLAN of a virtual service blade (VSB) and the Cisco Nexus Cloud Services Platform host can be different from each other.

Virtual Service Blade High Availability

High availability (HA) is configured for the redundant VSB pairs that you create on the Cisco Nexus Cloud Services Platform. At a given time, not all VSBs are active on the active Cisco Nexus Cloud Services Platform. If there is connectivity between the active and standby Cisco Nexus Cloud Services Platforms, access through a serial connection is maintained to any VSB. When a Cisco Nexus Cloud Services Platform fails, the other Cisco Nexus Cloud Services Platform becomes active and all VSBs in the standby state on that Cisco Nexus Cloud Services Platform become active on their own.

The VSB HA has the following features:

- Deployment—You must deploy an HA-capable VSB on a Cisco Nexus Cloud Services Platform HA pair.

- HA role and inheritance—A VSB’s HA role is inherited from the host Cisco Nexus Cloud Services Platform’s HA role. A primary VSB always resides on a primary Cisco Nexus Cloud Services Platform and a secondary VSB always resides on a secondary Cisco Nexus Cloud Services Platform.

- Independence—A VSB’s HA role is independent of the state of the Cisco Nexus Cloud Services Platform. Although the initial role of VSB is inherited from the Cisco Nexus Cloud Services Platform HA role, the eventual status is independent of the Cisco Nexus Cloud Services Platform HA role. For example, an active primary VSB can reside on a standby primary Cisco Nexus Cloud Services Platform or a standby primary Cisco Nexus Cloud Services Platform can reside on an active primary VSB.

- Control VLAN and domain ID—HA information for the Cisco Nexus Cloud Services Platform and a VSB are formed based on the control VLAN and domain ID combination.

Note

The Cisco Nexus Cloud Services Platform does not support control VLAN and domain ID combinations in the following cases:

- Across a VSM and Cisco Nexus Cloud Services Platform.

- Across VSMs of different releases.

- Across VSMs of the same hypervisors (VMware, KVM, or Hyper-V).

If a VSM or VSB is configured with such a combination, it might result in system instability or traffic loss.

- Back up and save—You must save modifications to the configuration of a VSB and the Cisco Nexus Cloud Services Platform, and back up their settings independently. It is important to do so because the configuration settings of a Cisco Nexus Cloud Services Platform are different from the settings of a VSB and the copy configuration or save configuration commands do not produce uniform results on both platforms.

Note

Although there is an auto config feature that automatically saves the configuration every 5 minutes, we recommend that you run the copy running-config startup-config command each time you make a critical change to the configuration.

- Removing a VSB from the Cisco Nexus Cloud Services Platform—You can remove a VSB from both Cisco Nexus Cloud Services Platforms or from only one. If one redundant pair becomes unusable, you can remove it from only the Cisco Nexus Cloud Services Platform where it resides. This process enables you to preserve the remaining VSB in the HA pair.

For more information about HA, see Cisco Nexus Cloud Services Platform High Availability.

For more information about VSM HA, see the Cisco Nexus 1000V High Availability and Redundancy Configuration Guide.

Role Collision Detection

When you configure a Cisco Nexus 1000V Virtual Switch Module (VSM) with the same role as an existing VSM with the same control VLAN and domain ID, the new VSM and the existing VSM exchange heartbeats to discover each other. Both VSMs detect a role collision when they exchange heartbeats. When a collision occurs, identifying the primary and secondary VSMs becomes disruptive and inconsistent on a Cisco Nexus Cloud Services Platform.

Note

In this document, Cisco Nexus 1000V VSM refers to the service on VMware, KVM, and Hyper-V hypervisors and their different versions.

A role collision is detected on the control and the management interfaces if the Cisco Nexus 1000V VSMs and the Cisco Nexus Cloud Services Platforms are configured in the following combinations:

1. When a Cisco Nexus 1000V VSM is configured with the same role and the control VLAN and domain ID as that of an existing VSM in the same platform (VMware with VMware, KVM with KVM, or Hyper-V with Hyper-V VSMs) or with another Cisco Nexus 1000V VSM from a different release.

2. When a VSM shares the control VLAN and the domain ID with a Cisco Nexus Cloud Services Platform.

3. When a Cisco Nexus Cloud Services Platform shares the control VLAN and domain ID with another Cisco Nexus Cloud Services Platform.

Caution

The Cisco Nexus Cloud Services Platform does not support the architecture to detect and display a role collision in the HA-paired Cisco Nexus 1000V VSMs or between two Cisco Nexus Cloud Services Platforms.

In any of these combinations, the Cisco Nexus Cloud Services Platform cannot identify the primary and secondary VSM, which might result in flapping, rebooting, and some traffic loss. This problem can occur on a primary or a secondary Cisco Nexus 1000V VSM, depending on whether the newly configured or the installed VSM has the primary or the secondary role assigned to it.

At the first occurrence of a role collision on a Cisco Nexus Cloud Services Platform, the HA pairing begins to fluctuate when the secondary VSM tries to identify the primary and causes system instability. When the Cisco Nexus 1000V VSM stops communicating in the domain, the collision is no longer updated. After an hour has elapsed since the last collision, the collision MAC entries are removed.

For combinations 1 and 2, you can enter the show system redundancy status command on the primary or secondary VSM console to display the traffic collision details. You can change the domain ID on the Cisco Nexus 1000V VSM or the Cisco Nexus Cloud Services Platform to ensure proper operation of the Cisco Nexus Cloud Services Platform.

Note

The colliding VSMs might also report a collision detection from the original VSM. Because the colliding VSMs can use the same IP address for their management interfaces, the remote SSH or Telnet connections might fail. Therefore, we recommend that you use the consoles during a role collision detection.

However, when a Cisco Nexus Cloud Services Platform shares the control VLAN and domain ID with another Cisco Nexus Cloud Services Platform, you cannot use the show system redundancy status command to display the role collision details. We recommend that you keep the domain IDs unique on both the Cisco Nexus Cloud Services Platforms to maintain high availability and to avoid the potential system instability and data loss due to the role collision.

For more information about high availability on the Cisco Nexus Cloud Services Platform, see Cisco Nexus Cloud Services Platform High Availability.

Guidelines and Limitations for Virtual Service Blades

Unlike the control and packet VLANs that are set when a VSB is created, a Virtual Supervisor Module (VSM) inherits its management VLAN from the Cisco Nexus Cloud Services Platform.

Crypto and SSL Offloading in Virtual Service Blades

VSBs on the Cisco Nexus Cloud Services Platform can offload their security processing capacity to a dedicated external processor to improve performance. Depending on their deployment models, different VSBs might require more or less processing capacity than the others on the Cisco Nexus Cloud Services Platform.

To meet the security processing requirements of the VSBs, the Cisco Nexus 1110-X supports the Cavium NITROX CNN3550-C20-NHB-2.0-G security processor card as a field replacement unit (FRU) to enable Secure Sockets Layer (SSL) and crypto acceleration. The Cavium NITROX security processor card provides a total of 30 Gbps of SSL offload capacity that is shared by all VSBs on the Cisco Nexus Cloud Services Platform. The Cisco Nexus Cloud Services Platform slices the security processor card and allocates the corresponding capacities to the VSBs based on their bandwidth requirements. However, you must configure the VSBs to use the allocated slice of the security processor card.

- Guidelines and Limitations for Using the Cavium NITROX Security Processor Card

- Configuring SSL and Crypto Offloading Capability in Virtual Service Blades

Guidelines and Limitations for Using the Cavium NITROX Security Processor Card

Cavium NITROX security processor cards have the following guidelines and limitations:

1. Cavium's NITROX security processor card is supported only as a field replacement unit (FRU) on the Cisco Nexus 1110-X.

2. Multiple VSBs on a single Cisco Nexus Cloud Services Platform can offload their security processing to a single security processor.

3. The Cavium NITROX security processor card is supported only on a new deployment; you cannot upgrade your existing Cisco Nexus 1110-X pair to a crypto-enabled Cisco Nexus 1110-X pair. However, you can convert the existing Cisco Nexus 1110-X to a crypto-enabled appliance by replacing the Intel quad-port NIC card with a Cavium NITROX card, or by replacing the Cisco UCS 10-Gbps card with a Cavium NITROX card and reinstalling the Cisco Nexus Cloud Services Platform software.

For information about installing the Cavium NITROX card on your Cisco Nexus Cloud Services Platform, see the Cisco Nexus Cloud Services Platform Hardware Installation Guide. For information about installing the Cisco Nexus Cloud Services Platform software, see the Cisco Nexus Cloud Services Platform Software Installation and Upgrade Guide.

4. If the security processor card that is used by a VSB gets disabled, the VSB moves to the shutdown state in the following cases:

- When the presence of a Cavium NITROX card is not detected after a system reboot.

- When a Cisco Nexus Cloud Services Platform is paired with a new HA appliance, and the HA Cisco Nexus Cloud Services Platform does not have a Cavium NITROX card, the VSB moves to the shutdown state on the newly paired HA appliance.

Configuring SSL and Crypto Offloading Capability in Virtual Service Blades

You can configure Secure Sockets Layer (SSL) and crypto offloading capability in a VSB.

Before You Begin

- Log in to the CLI in EXEC mode.

- Ensure that the latest CIMC version is installed before configuring the crypto card. For more information about the latest CIMC version, see the Cisco Nexus Cloud Services Platform Software Installation and Upgrade Guide.

- Know the name of the VSB that you created. If you want to create a new VSB, see Creating a Virtual Service Blade.

- Ensure that there is enough crypto bandwidth to meet the requirement of the VSB.

- In a standalone Cisco Nexus Cloud Services Platform configuration, ensure that the Cavium NITROX card is present locally.

- In an HA configuration, ensure that the Cavium NITROX card is present on both Cisco Nexus Cloud Services Platforms.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # virtual-service-blade name

Creates the named VSB and enters configuration mode for that VSB.

name—Enter an alphanumeric string of up to 80 characters.

Step 3

switch (config-vsb-config) # virtual-service-blade-type [name name |new [iso-filename |ova-filename]

Specifies the type and name of the software image file to add to this VSB.

- name—Enter the name of the existing VSB.

- iso-filename | ova-filename—Enter the name of the new ISO or OVA image file in the bootflash:repository.

Step 4

switch (config-vsb-config) # interface name uplink name

Assigns the uplink port channel ID to this interface. The port channel ID range is from 1 to 6.

This command also assigns an uplink to a VSB interface to be configured as passthrough. This uplink can be Gigabit Ethernet or Portchannel.

Step 5

switch (config-vsb-config) # interface name mode passthrough

Sets up the named interface in passthrough mode on the VSB.

Step 6

switch (config-vsb-config) # crypto-offload bandwidth

Configures the bandwidth requirement of the traffic that needs to be offloaded to the Cavium NITROX card. The bandwidth range is from 100 to 30,000 Mbps.

Step 7

switch (config-vsb-config) # enable

Initiates the configuration of the VSB and then enables it.

Step 8

Enter the configuration details as prompted.

Information that you entered is echoed back to the console.

Step 9

Review the configuration details, and then enter Y at the prompt.

The configuration details that you entered are applied to the VSB.

Step 10

switch (config-vsb-config) # exit

Exits virtual service configuration mode and returns to global configuration mode.

Step 11

switch (config) # exit

Exits global configuration mode and returns to EXEC mode.

Step 12

switch #show virtual-service-blade name name

(Optional)
Displays information about the newly created VSB.

This example shows how to configure SSL and crypto offloading capability in a VSB:

switch# configure terminal
switch (config)# virtual-service-blade NS1000V
switch(config-vsb-config)# virtual-service-blade-type new NetScaler1000V-NEXUS-10.5-52.11_nc.ova
Note: It can take awhile to finish OVA extract operation. Please be patient..
Note: please be patient..
Note: please be patient..

switch(config-vsb-config)# interface ns_intf_1 uplink ethernet 2
switch(config-vsb-config)# interface ns_intf_1 mode passthrough
switch(config-vsb-config)# crypto-offload 10000
switch(config-vsb-config)# enable

Enter vsb image: [NetScaler1000V-NEXUS-10.5-52.11_nc.ova]
NS HA [true/false]: [true] 2
Out of range. NS HA [true/false]: [true]
Management IP version [V4|V6]: [V4]
Enter Primary IPv4 address: 80.80.80.91
Enter Primary subnet mask: 255.255.255.0
Primary IPv4 address of the default gateway: 80.80.80.1
Enter Secondary IPv4 address: [0.0.0.0] 80.80.80.92
Enter Secondary subnet mask: [0.0.0.0] 255.255.255.0
Enter secondary IPv4 address of the default gateway: [0.0.0.0] 80.80.80.1
Enter Primary HostName: NS1000V-1
Enter Secondary HostName: NS1000V-2
Enter the password for  'nsroot': Sfish123

----Details entered----
NS HA [true/false]: : true
Management IP version [V4|V6]: : V4
Enter Primary IPv4 address: : 80.80.80.91
Enter Primary subnet mask: : 255.255.255.0
Primary IPv4 address of the default gateway: : 80.80.80.1
Enter Secondary IPv4 address: : 80.80.80.92
Enter Secondary subnet mask: : 255.255.255.0
Enter secondary IPv4 address of the default gateway: : 80.80.80.1
Enter Primary HostName: : NS1000V-1
Enter Secondary HostName: : NS1000V-2
Enter the password for  'nsroot': : Sfish123
Do you want to continue installation with entered details (Y/N)? [Y]
Note: VSB installation is in progress, please use show virtual-service-blade commands to check the installation status.
Note: VSB installation may take upto 5 minutes.

switch(config-vsb-config)# exit
switch(config)# exit
switch# show virtual-service-blade name VSM
virtual-service-blade NS1000V
Description:
Slot id:        4
Host Name:      NS1000V-2
Management IP:  80.80.80.92
VSB Type Name :  NetScaler1000V-1055211.1
Configured vCPU:           2
Operational vCPU:           2
Configured Ramsize:        2048
Operational Ramsize:        2048
Disksize:       20
Configured CryptoOffload Bandwidth:       10000
Operational CryptoOffload Bandwidth:       10000
Configured CryptoOffload VF:       3
Operational CryptoOffload VF:       3
Heartbeat:      78

Legends:   P -  Passthrough
--------------------------------------------------------------------------
Interface           Type         MAC     VLAN    State  Uplink-Int
Pri  Sec Oper  Adm
--------------------------------------------------------------------------
VsbEthernet4/1   ns_intf_0 0002.3d70.2393 2050        up Eth1   Eth1
internal          NA        NA       NA         up
VsbEthernet4/3   ns_intf_1 0002.3d70.2394 3123        up Eth2(P)Eth2(P)
VsbEthernet4/4   ns_intf_2 0002.3d70.2395 3123      down Eth7   Eth7
VsbEthernet4/5   ns_intf_3 0002.3d70.2396 3123      down Eth7   Eth7
VsbEthernet4/6   ns_intf_4 0002.3d70.2397 3123      down Eth7   Eth7
VsbEthernet4/7   ns_intf_5 0002.3d70.2398 3123      down Eth7   Eth7
VsbEthernet4/8   ns_intf_6 0002.3d70.2399 3123      down Eth7   Eth7
VsbEthernet4/9   ns_intf_7 0002.3d70.239a 3123      down Eth7   Eth7
virtual-service-blade:
HA Status: ACTIVE
Status:       VSB POWERED ON
Location:     SECONDARY
SW version:   NetScaler NS10.5: Build 52.11.nc, Date: Sep 30 2014, 00:55:10
VSB Info:
Netscaler VPX

switch#

Creating a Virtual Service Blade

You can create a VSB, such as a virtual supervisor module (VSM), by installing and configuring the software.

Note

For information about upgrading the Cisco Nexus 1000V software on an existing VSB, see the Cisco Nexus 1000V Installation and Upgrade Guide.

Before You Begin

- Log in to the CLI in EXEC mode.

- Know the name of the VSB that you want to create.

- You can create a new VSB using an ISO file from any of the following sources:

- From a previously created VSB.

- Shipped with the Cisco Nexus Cloud Services Platform in the bootflash:repository.

- Downloaded from Cisco.com and copied to the bootflash:repository.

- If you are using an ISO file from the bootflash:repository or a downloaded ISO file, make sure that you know the filename.

- If you are using an ISO file from an existing VSB, make sure that you know the name of the VSB type. This procedure includes information about identifying this name.

- Know the following properties for the VSB:

- Domain ID

- Management IP address

- Management subnet mask length

- Default gateway IPv4 address

- Hostname

- Administrator password

- Control and packet VLAN IDs

Note

- When you are connected through a serial port on the Cisco Nexus Cloud Services Platform, and you want to create a VSB, do the following:

- Manually enter the configuration commands one at a time. If you copy and paste the commands in bulk into the CLI, the terminal might hang and leave the process incomplete.

- Avoid using show commands that generate large outputs. Using these commands causes the serial port to lock and hangs the terminal.

- If a terminal becomes unresponsive, open a new console and manually enter the commands one after the other to set up a new VSB.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # virtual-service-blade name

Enters the VSB configuration mode and creates the named VSB.

name—Enter an alphanumeric string of up to 79 case-sensitive characters.

Step 3

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

Displays a summary of all VSB configurations by VSB type, such as VSM or Network Analysis Module (NAM). Use this type name in the next step.

Step 4

switch (config-vsb-config) # virtual-service-blade-type [name name |new iso-filename |ova filename]

Specifies the type and name of the software image file to add to this VSB. The keywords are as follows:

- name—Enter the name of the existing VSB type as displayed in the output to Step 3.

- [iso-filename | ova-filename]—Enter the name of the new ISO or OVA software image file in the bootflash:repository.

Step 5

switch (config-vsb-config) # description

(Optional)
Enter an alphanumeric string of up to 79 case-sensitive characters.

Step 6

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

Displays the VSB that you just created, including the interface names that you configure in the next step.

Step 7

switch (config-vsb-config) # interface name vlan vlan-id

Applies the interface name and VLAN ID to this VSB. Use the interface names from the Step 6 command output. If you attempt to apply an interface name that is not present, the following error is displayed:

ERROR: Interface name not found in the associated virtual-service-blade type.

Caution:   To prevent a loss of connectivity, you must configure the same control and packet VLANs on the hosted VSMs.

Step 8

Repeat Step 7 to apply additional interfaces.

—

Step 9

switch (config-vsb-config) # enable [primary | secondary]

Initiates the configuration of the VSB and then enables it. If you are enabling a non-redundant VSB, you can specify its HA role as follows:

- primary—Designates the VSB in a primary role.

- secondary—Designates the VSB in a secondary role.

The Cisco Nexus Cloud Services Platform prompts you for the following:

- Domain ID—This must be a different domain ID than the one you used for the Cisco Nexus Cloud Services Platform.

- VSB image name

- Software virtual switch (SVS) control mode

- Management IP version

- Management IP address

- Management subnet mask length

- Default gateway IPv4 address

- Hostname

- Administrator password

Step 10

Confirm the configuration and then enter Y.

The configuration is applied to the VSB.

Step 11

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

(Optional)
Displays the new VSB for verification. While the switch is configuring the VSB, the switch output for this command progresses from in progress to powered on.

This example shows how to create a VSB:

switch configure terminal
switch(config)# virtual-service-blade VSM
switch(config-vsb-config)# show virtual-service-blade-type summary

-------------------------------------------------------------------------------
Virtual-Service-Blade-Type    Virtual-Service-Blade
-------------------------------------------------------------------------------
VSM_SK1-3.1                          KVM-VSM
VSM_SV3-1.1                        ESX-VSM
VSG-1.2                              HyperV-VSG
ESX-VSG
switch(config-vsb-config)# virtual-service-blade-type new n1000v-dk9.5.2.1.SV3.1.1.1010.ova
Note: It can take awhile to finish OVA extract operation. Please be patient..
Note: please be patient..
Note: please be patient..

switch(config-vsb-config)#
switch(config-vsb-config)# description vsm-for-esx
switch(config-vsb-config)# show virtual-service-blade name VSM

virtual-service-blade VSM
Description:  vsm-for-esx
Slot id:        5
Host Name:
Management IP:
VSB Type Name :  VSM_SV3-1.1
Configured vCPU:           2
Operational vCPU:           2
Configured Ramsize:        4096
Operational Ramsize:        4096
Disksize:       3
Configured CryptoOffload Bandwidth:       0
Operational CryptoOffload Bandwidth:       0
Configured CryptoOffload VF:       0
Operational CryptoOffload VF:       0
Heartbeat:      0

Legends:   P -  Passthrough
--------------------------------------------------------------------------
Interface           Type         MAC     VLAN    State   Uplink-Int
Pri  Sec  Oper  Adm
--------------------------------------------------------------------------
VsbEthernet5/1     control                       up   up
VsbEthernet5/2  management                1496   up   up
VsbEthernet5/3      packet                       up   up
internal          NA        NA       NA    up   up
HA Role: Primary
HA Status: NONE
Status:       VSB NOT PRESENT
Location:     PRIMARY
SW version:
HA Role: Secondary
HA Status: NONE
Status:       VSB NOT PRESENT
Location:     SECONDARY
SW version:
VSB Info:

cppa-mgr(config-vsb-config)# interface control vlan 2013
cppa-mgr(config-vsb-config)# interface packet vlan 2014
cppa-mgr(config-vsb-config)# enable
Enter vsb image: [n1000v-dk9.5.2.1.SV3.1.1.1010.ova]
Enter domain id[1-1023]: 111
Enter SVS Control mode (L2 / L3): [L3]
Management IP version [V4/V6]: [V4]
Enter Management IP address: 80.80.80.70
Enter Management subnet mask: 255.255.255.0
IPv4 address of the default gateway: 80.80.80.1
Enter HostName: VSM
Enter the password for 'admin': Sfish123

----Details entered----
Enter domain id[1-1023]: : 111
Enter SVS Control mode (L2 / L3): : L3
Management IP version [V4/V6]: : V4
Enter Management IP address: : 80.80.80.70
Enter Management subnet mask: : 255.255.255.0
IPv4 address of the default gateway: : 80.80.80.1
Enter HostName: : VSM
Enter the password for 'admin': : Sfish123
Do you want to continue installation with entered details (Y/N)? [Y]
Note: VSB installation is in progress, please use show virtual-service-blade commands to check the installation status.
Note: VSB installation may take upto 10 minutes.

cppa-mgr(config-vsb-config)#
cppa-mgr(config-vsb-config)# show virtual-service-blade name VSM
virtual-service-blade VSM
Description:  vsm-for-esx
Slot id:        5
Host Name:      VSM
Management IP:  80.80.80.70
VSB Type Name :  VSM_SV3-1.1
Configured vCPU:           2
Operational vCPU:           2
Configured Ramsize:        4096
Operational Ramsize:        4096
Disksize:       3
Configured CryptoOffload Bandwidth:       0
Operational CryptoOffload Bandwidth:       0
Configured CryptoOffload VF:       0
Operational CryptoOffload VF:       0
Heartbeat:      356

Legends:   P -  Passthrough
--------------------------------------------------------------------------
Interface           Type         MAC     VLAN    State   Uplink-Int
Pri  Sec  Oper  Adm
--------------------------------------------------------------------------
VsbEthernet5/1     control 0002.3d77.e38f 2013   up   up Po1    Po1
VsbEthernet5/2  management 0002.3d77.e38e 1496   up   up Po1    Po1
VsbEthernet5/3      packet 0002.3d77.e390 2014   up   up Po1    Po1
internal          NA        NA       NA    up   up
HA Role: Primary
HA Status: STANDBY
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 : 111

Deleting a Virtual Service Blade

You can delete a VSB, such as a virtual supervisor module (VSM) or Network Analysis Module (NAM).

Before You Begin

- Log in to the CLI in EXEC mode.

- Know the name of the VSB that you are deleting.

- Shut down the VSB before you delete it. This procedure includes instructions for shutting down the VSB.

- Know that you can remove a VSB from both redundant Cisco Nexus Cloud Services Platforms or from only one platform. If one redundant pair becomes unusable, you can remove it from only the Cisco Nexus Cloud Services Platform where it resides. This process enables you to preserve the remaining VSB in the pair. This action might may become necessary if a new instance of the service must be provisioned.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # virtual-service-blade name

Enters configuration mode for the named VSB.

Step 3

switch (config-vsb-config) # shutdown

Shuts down the VSB.

Step 4

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

(Optional)
Displays a summary of services to verify the shutdown.

Step 5

Do one of the following:

- no virtual-service-blade name

- no enable [primary | secondary]

Deletes the specified VSB. The keywords are as follows:

- no virtual-service-blade name—Removes the specified VSB from the Cisco Nexus Cloud Services Platform.

- no enable [primary | secondary]—Removes the specified VSB from the system but retains the infrastructure configuration (interface VLANs, RAM size, disk size overrides) in the Cisco Nexus Cloud Services Platform. Use this command to delete only the primary or secondary VSB in a pair.

Step 6

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

(Optional)
Displays a summary of services for verification of the removal.

This example shows how to delete a VSB:

switch# configure terminal
switch(config)# virtual-service-blade vsm-5
switch(config-vsb-config)# shutdown
switch(config-vsb-config)# show virtual-service-blade summary
---------------------------------------------------------------------------------------------------
Name                HA-Role         HA-Status   Status               Location
---------------------------------------------------------------------------------------------------
vsm-1               PRIMARY     ACTIVE      VSB POWERED ON           PRIMARY
vsm-1               SECONDARY   STANDBY     VSB POWERED ON           SECONDARY

switch(config-vsb-config)# no virtual-service-blade vsm-5
switch(config-vsb-config)# no enable
switch(config)# copy running-config startup-config

Modifying a Virtual Service Blade

You can modify the control VLAN, packet VLAN, disk size, number of CPUs, or RAM size of a VSB and then make the corresponding changes to the VSM.

- Modifying a Virtual Service Blade on the Cisco Nexus Cloud Services Platform

- Modifying the Cisco Nexus 1000V VSM Configuration

- Defining Form Factors for a Cisco Virtual Security Gateway VSB

Modifying a Virtual Service Blade on the Cisco Nexus Cloud Services Platform

Before You Begin

- Log in to the CLI in EXEC mode.

- Know the name of the VSB that you are modifying.

- Shut down the VSB before modifying the RAM size or the control VLAN. This procedure includes instructions for shutting down the VSB.

Caution

The virtual supervisor module (VSM) must be in the shutdown state before you modify the control VLAN to preserve HA when the service comes back up. The control VLAN passes control messages to the standby VSM.

- Change the configuration first in the VSB configuration and then in the Cisco Nexus 1000V VSM configuration. This procedure changes the VSB configuration. To change the Cisco Nexus 1000V configuration, see Modifying the Cisco Nexus 1000V VSM Configuration.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters the global configuration mode.

Step 2

switch (config) # virtual-service-blade name

Enters the configuration mode for the named VSB.

Step 3

switch (config-vsb-config) # shutdown

Shuts down the VSB.

Step 4

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

(Optional)
Displays a summary of services for verification of the shutdown.

Step 5

Do one of the following:

- ramsize name

- interface control vlan vlanid

- interface packet vlan vlanid

- numcpu number

- disk size number

- crypto offload bandwidth

Modifies the VSB. You can modify any of the following VSB parameters:

- Memory allocated for RAM (1024-4096 MB)

- Control VLAN ID

- Packet VLAN ID

- Number of CPUs

- Disk size

- Crypto offload bandwidth

Step 6

switch (config-vsb-config) # no shutdown

Returns the VSB status to powered on.

Step 7

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

(Optional)
Displays the VSB information for verification of the changes.

This example shows how to modify a VSB on the Cisco Nexus Cloud Services Platform:

switch# configure terminal
switch(config)# virtual-service-blade vsm-1
switch(config-vsb-config)# shutdown
switch(config-vsb-config)# show virtual-service-blade summary
----------------------------------------------------------------------------------------
Name         HA-Role           HA-Status   Status       Location
----------------------------------------------------------------------------------------
vsm-1       PRIMARY ACTIVE     VSB POWERED ON           PRIMARY
vsm-1       SECONDARY STANDBY  VSB POWERED ON           SECONDARY

Do one of the following to modify the VSB parameters:

switch(config-vsb-config)# ramsize 1024
switch(config-vsb-config)# interface control vlan 1116
switch(config-vsb-config)# interface packet vlan 1116
switch(config-vsb-config)# no shutdown
switch(config-vsb-config)# show virtual-service-blade name vsm-1
virtual-service-blade vsm-1
Description:
Slot id:        1
Host Name:      switch
Management IP:  172.23.181.37
VSB Type Name :  VSM-1.1
vCPU:           1
Ramsize:        2048
Disksize:       3
Heartbeat:      35275
--------------------------------------------------------------------------------------
Interface  Type       VLAN      State                       Uplink-Interface
Primary    Secondary        Oper  Admin
--------------------------------------------------------------------------------------
VsbEthernet1/1     control 423       up         up               Po1    Po1
VsbEthernet1/2  management 231       up         up               Po1    Po1
VsbEthernet1/3      packet 423       up         up               Po1    Po1
internal NA        NA         up         up
HA Role: Primary
HA Status: ACTIVE
Status:       VSB POWERED ON
Location:     PRIMARY
SW version:   4.2(1)SV1(4a)
HA Role: Secondary
HA Status: STANDBY
Status:       VSB POWERED ON
Location:     SECONDARY
SW version:   4.2(1)SV1(4a)
VSB Info:
Domain ID : 441

Modifying the Cisco Nexus 1000V VSM Configuration

Before You Begin

- Log in to the CLI in EXEC mode.

- Know the name of the virtual supervisor module (VSM) that you are modifying.

- Change the configuration of the Cisco Nexus Cloud Services Platform VSB first, and then change the Cisco Nexus 1000V VSM configuration. This procedure changes the Cisco Nexus 1000V VSM configuration. To change the Cisco Nexus Cloud Services Platform VSB configuration, see Modifying a Virtual Service Blade on the Cisco Nexus Cloud Services Platform.

Procedure

Command or Action

Purpose

Step 1

switch # login virtual-service-blade name

Enters global configuration mode.

Step 2

Enter your username.

Authenticates your user ID.

Step 3

Enter your password.

Authenticates your password.

Step 4

switch # show svs domain

Displays the domain configuration for the VSM.

Step 5

switch # configure terminal

Enters the CLI global configuration mode.

Step 6

switch(config) # svs-domain

Enters SVS domain configuration mode.

Step 7

switch (config-svs-domain) # control vlan vlanid

Modifies the VLAN ID of the VSM domain control VLAN.

Step 8

switch (config-svs-domain) # packet vlan vlanid

Modifies the VLAN ID of the VSM domain packet VLAN.

Step 9

switch # show svs-domain

(Optional)
Displays the domain configuration for verification of the changes.

Step 10

Press the Ctrl key and the \ backslash key.

Exits the SVS domain configuration mode and returns you to a Telnet prompt.

Step 11

Telnet close

Closes the Telnet session and returns you to EXEC mode on the Cisco Nexus Cloud Services Platform.

This example shows how to modify a VSM on the Cisco Nexus 1000V:

switch-1# login virtual-service-blade 1
Telnet escape character is '^\'.
Trying 192.168.0.18...
Connected to 192.168.0.18.
Escape character is '^\'.

User Access Verification
switch-vsm1 login:
password:
switch # show svs domain
SVS domain config:
Domain id:    100
Control vlan: 1114
Packet vlan:  1115
L2/L3 Control mode: L2
L3 control interface:  NA
Status: Config push to VC successful.
switch(config)# svs domain
switch(config-svs-domain)# control vlan 1116
switch(config-svs-domain)# packet vlan 1117
switch(config-svs-domain)# Ctrl \
Telnet> close

Defining Form Factors for a Cisco Virtual Security Gateway VSB

Before You Begin

- Log in to the CLI in EXEC mode.

- Know the name of the VSB that you created. If you want to create a new VSB, see Creating a Virtual Service Blade.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # virtual-service-blade name

Enters the configuration mode for the named VSB.

name—Enter an alphanumeric string of up to 80 characters.

Step 3

switch# shutdown

(Optional)
Shuts down the running Virtual Security Gateway (VSG) that requires modification.

Step 4

switch (config-vsb-config) # description

(Optional)
Enter a description for the VSB as an alphanumeric string of up to 80 characters.

Step 5

switch (config-vsb-config) # numcpu

Configures the VSB as a medium or large model based on the number of virtual CPUs attached to the VSB.

number—Enter the numeric value of 1 or 2.

Step 6

switch (config-vsb-config) # name

Enter the name of the VSB.

Step 7

(Optional) switch (config-vsb-config) # no shutdown name

(Optional)
Returns the VSB status to powered on. Use ths command if you shut down a running VSG in Step 3.

Step 8

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

(Optional)
Displays the VSB information for verification of the changes.

This example shows how to define form factors for a Cisco VSG VSB:

switch# configure terminal
switch(config)# virtual-service-blade vy252
switch(config-vsb-config)# shutdown vy252
switch(config-vsb-config)# description VSG_vy_252
switch(config-vsb-config)# numcpu 2
switch(config-vsb-config)# name vy252
switch(config-vsb-config)# no shutdown vy252
switch(config-vsb-config)# show virtual-service-blade name vy252
virtual-service-blade vy252
Description:  VSG_CY_252
Slot id:        2
Host Name:      vsg-c252
Management IP:
VSB Type Name :  VSG-1.2
vCPU:           2
Ramsize:        2048
Disksize:       3
Heartbeat:      1933
--------------------------------------------------------------------------
Interface            Type   VLAN       State            Uplink-Interface
Primary  Secondary   Oper   Admin
--------------------------------------------------------------------------
VsbEthernet2/1        data    21       up         up    eth3    eth3
VsbEthernet2/2  management    21       up         up    eth3    eth3
VsbEthernet2/3          ha    21       up         up    eth3    eth3
internal          NA    NA             up         up
HA Role: Primary
HA Status: NONE
Status:       VSB POWERED OFF
Location:     PRIMARY
SW version:   4.2(1)VSG2(1.0.252)
HA Role: Secondary
HA Status: NONE
Status:       VSB POWERED OFF
Location:     SECONDARY
SW version:   4.2(1)VSG2(1.0.252)
VSB Info:
Domain ID : 441

Automatic Execution of the copy running-config startup-config Command

Beginning in Release 5.2(1)SP1(7.1) of the Cisco Nexus Cloud Services Platform, the copy running-config startup-config command persistently saves your VSB and network configuration settings, and copies them to the startup configuration every 5 minutes. This feature prevents the loss of VSB configurations during a reload or a power failure.

- Even though the copy running-config startup-config command is triggered at 5-minute intervals, we recommended that you execute the command manually to save your critical configuration settings immediately.

- The auto-save of the configuration settings is triggered only if a VSB-related configuration is affected. Therefore, if you have critical configuration settings not involving a VSB, you must manually save your settings.

The following table lists the commands that are impacted by this change in the configuration procedure.

Impacted Commands

Description

VSB Configuration Commands

virtual-service-blade name

Creates a virtual service blade.

virtual-service-blade-type name template name

Attaches a VSB template file to the VSB.

virtual-service-blade-type new [iso-filename | ova-filename]

Attaches an ISO or OVA file to a VSB.

switch-vsb-config # ramsize

Configures the RAM size for a VSB.

switch-vsb-config # disksize

Configures the disk size for a VSB.

switch-vsb-config # numcpu

Configures the number of CPU cores for a VSB.

switch-vsb-config # interface int-name mode mode

Configures the VSB interface mode.

switch-vsb-config # interface int-name vlan vlan-id

Configures the VLAN for a VSB interface.

switch-vsb-config # interface int-name uplink uplink-id

Configures an uplink port for a VSB interface.

switch-vsb-config # shutdown [primary | secondary | both]

Shuts down a VSB.

switch-vsb-config # enable [primary | secondary | both ]

Enables a VSB.

switch # [no] virtual-service-blade name

Deletes a VSB.

Network Configuration Commands

config-if # channel-group

Configures an interface as a part of the port channel group.

config-if # no shutdown

Changes the operational state of the interface.

config-if # native vlan vlan-id

Configures a native VLAN on an interface.

SVS Configuration Commands

config-svs-domain # control vlan vlan-id

Configures the control VLAN on the uplink.

config-svs-domain # control management vlan-id

Configures the management VLAN on the uplink.

Configuring a Passthrough VSB Interface

After you create a Cisco Nexus VXLAN gateway VSB, you can configure it to function as a passthrough interface. The passthrough VSB interface enables the VSB to assign a virtual interface to a dedicated uplink. This uplink can be an Ethernet port on the Cisco Nexus Cloud Services Platform or a port channel.

A passthrough VSB interface has the following features and limitations:

- The passthrough VSB interface is available for the Cisco Nexus VXLAN gateway and the Citrix NetScaler 1000V VSBs.

- A VSB can have multiple passthrough interfaces and also have a combination of passthrough and shared interfaces.

- A passthrough uplink has a one-to-one mapping with the corresponding VSB interface and cannot be shared by multiple interfaces of the same or different VSBs.

- A VSB passthrough interface is not supported on Cisco UCS VIC 1225 10-Gbps interfaces.

A passthrough VSB interface has the following benefits:

- Ensures higher network throughput than a shared uplink interface.

- Allows the VSB to be in trunkall mode to receive tagged packets.

- Setting Up a Passthrough VSB Interface

Setting Up a Passthrough VSB Interface

You can configure a VSB interface in passthrough mode.

Before You Begin

- Log in to the CLI in EXEC mode.

- Know the name of the VSB that you created. If you want to create a new VSB, see Creating a Virtual Service Blade.

- Know that VLAN IDs are not required to be assigned to an interface before you configure it in passthrough mode. Previously assigned VLANs are ignored while setting up an interface in passthrough mode.

- Know the following properties for the VSB:

- Management IP version

- Primary IPv4 address

- Primary subnet mask length

- Primary default gateway IPv4 address

- Secondary IPv4 address

- Secondary subnet mask length

- Secondary default gateway IPv4 address

- Primary hostname

- Secondary hostname

- Administrator password

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch (config) # virtual-service-blade name

Enters the VSB configuration mode and creates the named VSB.

name—Enter an alphanumeric string of up to 80 characters.

Step 3

switch (config-vsb-config) # virtual-service-blade-type [name name |new [iso filename | ova filename]

Specifies the type and name of the software image file to add to this VSB.

- name—Enter the name of the existing VSB type.

- [iso-filename | ova-filename]—Enter the name of the new ISO or OVA software image file in the bootflash:repository.

Step 4

switch (config-vsb-config) # interface name uplink name

Applies the uplink port channel ID to this interface. The range is from 1 to 6.

This command also assigns an uplink to a VSB interface to be configured as passthrough. This uplink can be Gigabit Ethernet or Portchannel.

Step 5

switch (config-vsb-config) # interface name mode passthrough

Sets up the interface in passthrough mode on the VSB.

Step 6

switch (config-vsb-config) # enable

Initiates the configuration of the VSB and then enables it. If you are enabling a non-redundant VSB, you can specify its HA role as follows:

- primary—Designates the VSB in a primary role.

- secondary—Designates the VSB in a secondary role.

The Cisco Nexus Cloud Services Platform prompts you for the following:

- Management IP version

- Primary IPv4 address

- Primary subnet mask length

- Primary default gateway IPv4 address

- Secondary IPv4 address

- Secondary subnet mask length

- Secondary default gateway IPv4 address

- Primary hostname

- Secondary hostname

- Administrator password

Step 7

Confirm the configuration and then enter Y.

Applies the configuration to the VSB.

Step 8

switch (config) # show network summary

(Optional)
Displays a summary of all VSBs, including the ones configured in passthrough mode. The passthrough legend (P) is added to the uplink interfaces for the interfaces that are configured in passthrough mode.

Step 9

switch (config) # show virtual service blade name name

(Optional)
Displays details about the named VSB that you just created.

This example shows how to configure a passthrough VSB interface:

switch# configure terminal
switch(config)# virtual-service-blade NS1000V
switch(config-vsb-config)# virtual-service-blade-type new vpx.ova
Note: It can take awhile to finish OVA extract operation. Please be patient..
Note: please be patient..
Note: please be patient..

switch(config-vsb-config)#
switch(config-vsb-config)# interface ns_intf_1 uplink Ethernet 4
switch(config-vsb-config)# interface ns_intf_1 mode passthrough
switch(config-vsb-config)# enable
Enter vsb image: [vpx.ova]
NS HA [true/false]: [true]
Management IP version [V4|V6]: [V4]
Enter Primary IPv4 address: 80.80.80.80
Enter Primary subnet mask: 255.255.255.0
Primary IPv4 address of the default gateway: 80.80.80.1
Enter Secondary IPv4 address: [0.0.0.0] 80.80.80.81
Enter Secondary subnet mask: [0.0.0.0] 255.255.255.0
Enter secondary IPv4 address of the default gateway: [0.0.0.0] 80.80.80.1
Enter Primary HostName: vpx-1
Enter Secondary HostName: vpx-2
Enter the password for  'nsroot': Sfish123

----Details entered----
NS HA [true/false]: : true
Management IP version [V4|V6]: : V4
Enter Primary IPv4 address: : 80.80.80.80
Enter Primary subnet mask: : 255.255.255.0
Primary IPv4 address of the default gateway: : 80.80.80.1
Enter Secondary IPv4 address: : 80.80.80.81
Enter Secondary subnet mask: : 255.255.255.0
Enter secondary IPv4 address of the default gateway: : 80.80.80.1
Enter Primary HostName: : vpx-1
Enter Secondary HostName: : vpx-2
Enter the password for  'nsroot': : Sfish123
Do you want to continue installation with entered details (Y/N)? [Y]
Note: VSB installation is in progress, please use show virtual-service-blade commands to check the installation status.
Note: VSB installation may take upto 5 minutes.

switch(config)# show network summary

Legends:    P - Passthrough
------------------------------------------------------------------------------
Port     State     Uplink-Interface  Speed  RefCnt    MTU   Nat-Vlan
Oper  Admin  Oper    Admin                          Oper  Admin
------------------------------------------------------------------------------
Eth1    up     up                     1000       0   9000
Eth2    up     up                     1000       0   9000
Eth3    up     up                     1000       8   9000
Eth4    up     up                     1000       1   9000
Eth5    up     up                     1000       3   9000
Eth6    up     up                     1000       0   9000
Po1    up     up                     1000       9   9000
VsbEth1/1    up     up  Eth3   Eth3        1000           9000
VsbEth1/3    up     up  Eth3   Eth3        1000           9000
VsbEth1/4    up     up  Eth3   Eth3        1000           9000
VsbEth1/5    up     up  Eth3   Eth3        1000           9000
VsbEth1/6    up     up  Eth3   Eth3        1000           9000
VsbEth1/7    up     up  Eth3   Eth3        1000           9000
VsbEth1/8    up     up  Eth3   Eth3        1000           9000
VsbEth1/9    up     up  Eth3   Eth3        1000           9000
VsbEth2/1    up     up   Po1    Po1        1000           9000
VsbEth2/3    up     up  Eth4(P)Eth4(P)     1000           9000
VsbEth2/4  down   down   Po1    Po1        1000           9000
VsbEth2/5  down   down   Po1    Po1        1000           9000
VsbEth2/6  down   down   Po1    Po1        1000           9000
VsbEth2/7  down   down   Po1    Po1        1000           9000
VsbEth2/8  down   down   Po1    Po1        1000           9000
VsbEth2/9  down   down   Po1    Po1        1000           9000
control0    up     up   Po1    Po1        1000           9000
mgmt0    up     up   Po1    Po1        1000           9000

switch(config)# show virtual-service-blade name NS1000V
virtual-service-blade NS1000V
Description:
Slot id:        2
Host Name:      vpx-2
Management IP:  80.80.80.81
VSB Type Name :  NetScaler1000V-1055211.1
Configured vCPU:           2
Operational vCPU:           2
Configured Ramsize:        2048
Operational Ramsize:        2048
Disksize:       20
Configured CryptoOffload Bandwidth:       0
Operational CryptoOffload Bandwidth:       0
Configured CryptoOffload VF:       0
Operational CryptoOffload VF:       0
Heartbeat:      966

Legends:   P -  Passthrough
--------------------------------------------------------------------------
Interface           Type         MAC     VLAN    State   Uplink-Int
Pri  Sec Oper  Adm
--------------------------------------------------------------------------
VsbEthernet2/1   ns_intf_0 0002.3d71.4d8a 2050   up   up Po1    Po1
internal          NA        NA       NA    up   up
VsbEthernet2/3   ns_intf_1 0002.3d71.4d8b        up   upEth4(P)Eth4(P)
VsbEthernet2/4   ns_intf_2 0002.3d71.4d8c 3423 down down Po1    Po1
VsbEthernet2/5   ns_intf_3 0002.3d71.4d8d 3423 down down Po1    Po1
VsbEthernet2/6   ns_intf_4 0002.3d71.4d8e 3423 down down Po1    Po1
VsbEthernet2/7   ns_intf_5 0002.3d71.4d8f 3423 down down Po1    Po1
VsbEthernet2/8   ns_intf_6 0002.3d71.4d90 3423 down down Po1    Po1
VsbEthernet2/9   ns_intf_7 0002.3d71.4d91 3423 down down Po1    Po1
HA Role: Primary
HA Status: STANDBY
Status:       VSB POWERED ON
Location:     PRIMARY
SW version:   NetScaler NS10.5: Build 52.11.nc, Date: Sep 30 2014, 00:55:10
HA Role: Secondary
HA Status: ACTIVE
Status:       VSB POWERED ON
Location:     SECONDARY
SW version:   NetScaler NS10.5: Build 52.11.nc, Date: Sep 30 2014, 00:55:10
VSB Info:
Netscaler VPX

Configuration Examples for Virtual Service Blades

This example shows how to display the running configuration of a VXLAN gateway VSB in passthrough mode:

switch # show virtual-service-blade vxgw
Description:
Slot id:        2
Host Name:
Management IP:
VSB Type Name :  vx-gw-1.5
Configured vCPU:           3
Operational vCPU:           3
Configured Ramsize:        2048
Operational Ramsize:        2048
Disksize:       3
Configured CryptoOffload Bandwidth:       0
Operational CryptoOffload Bandwidth:       0
Configured CryptoOffload VF:       0
Operational CryptoOffload VF:       0
Heartbeat:      0

Legends:   P -  Passthrough
--------------------------------------------------------------------------
Interface           Type         MAC     VLAN    State   Uplink-Int
Pri  Sec Oper  Adm
--------------------------------------------------------------------------
VsbEthernet2/1  gw-uplink1                       up   upEth5(P)Eth5(P)
VsbEthernet2/2  management                 180   up   upEth2   Eth2
VsbEthernet2/3  gw-uplink2                 366   up   upEth2   Eth2
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: STANDBY
Status:       VSB POWERED ON
Location:     SECONDARY
SW version:
VSB Info:

switch#

Verifying the Virtual Service Blade Configuration

Command

Purpose

show virtual-service-blade [name name]

Displays the configuration for a specific VSB.

show virtual-service-blade-type summary

Displays a summary of all VSB configurations by type, such as VSM or NAM.

show virtual-service-blade summary

Displays a summary of all VSB configurations.

This command is only recognized by the primary Cisco Nexus Cloud Services Platform.

show virtual-service-blade [name name ] statistics

Displays statistics for a specific VSB such as CPU utilization, memory, last reboot time, or total number of reboots.

show network summary

Displays a summary of all interfaces, including the ones configured in passthrough mode.

This example shows how to display the VSB type summary:

switch# show virtual-service-blade-type summary
-------------------------------------------------------------------------------
Virtual-Service-Blade-Type    Virtual-Service-Blade
-------------------------------------------------------------------------------
VSM_SV1_3                     vsm-1
vsm-2
NAM-MV                        nam-1
switch#

This example shows how to display the VSB names for a Cisco Nexus 1000V VSM and a Cisco Nexus VXLAN gateway VSB:

switch# show virtual-service-blade vxgw
virtual-service-blade vxgw
Description:
Slot id:        2
Host Name:
Management IP:
VSB Type Name :  vx-gw-1.5
Configured vCPU:           3
Operational vCPU:           3
Configured Ramsize:        2048
Operational Ramsize:        2048
Disksize:       3
Configured CryptoOffload Bandwidth:       0
Operational CryptoOffload Bandwidth:       0
Configured CryptoOffload VF:       0
Operational CryptoOffload VF:       0
Heartbeat:      0

Legends:   P -  Passthrough
--------------------------------------------------------------------------
Interface           Type         MAC     VLAN    State   Uplink-Int
Pri  Sec Oper   Adm
--------------------------------------------------------------------------
VsbEthernet2/1  gw-uplink1                       up   up Eth5(P)Eth5(P)
VsbEthernet2/2  management                 180   up   up Eth2   Eth2
VsbEthernet2/3  gw-uplink2                 366   up   up Eth2   Eth2
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: STANDBY
Status:       VSB POWERED ON
Location:     SECONDARY
SW version:
VSB Info:

switch#

This example shows how to display the VSB summary:

switch# show virtual-service-blade summary

-------------------------------------------------------------------------------
Name                HA-Role     HA-Status   Status                   Location
-------------------------------------------------------------------------------
dcnm                PRIMARY     ACTIVE      VSB POWERED ON           PRIMARY
dcnm                SECONDARY   NONE        VSB NOT PRESENT          SECONDARY
vsm                 PRIMARY     ACTIVE      VSB POWERED ON           PRIMARY

This example shows how to display the VSB statistics:

switch# show virtual-service-blade statistics

virtual-service-blade: dcnm
Virtual Memory: 8558m
Physical Memory: 3.4g
CPU Usage Percentage: 1.00
Up Since: Thu May 15 22:46:51 2014
Number of Restarts: 1
Last heartbeat received at: Fri May 16 15:57:58 2014

virtual-service-blade: vsm
Virtual Memory: 4442m
Physical Memory: 1.7g
CPU Usage Percentage: 3.00
Up Since: Thu May 15 22:46:51 2014
Number of Restarts: 1
Last heartbeat received at: Fri May 16 15:57:58 2014

This example shows how to display the network summary:

switch# show network summary

Legends:    P - Passthrough
------------------------------------------------------------------------------
Port     State     Uplink-Interface  Speed  RefCnt    MTU   Nat-Vlan
Oper  Admin   Oper    Admin                          Oper  Admin
------------------------------------------------------------------------------
Eth1    up     up                     1000       5   9000
Eth2    up     up                     1000       1   9000
Eth3    up     up                     1000       0   9000
Eth4    up     up                     1000       0   9000
Eth5  down     up                     1000       0   9000
Eth6    up     up                     1000       0   9000
VsbEth1/1    up     up  Eth2   Eth2        1000           9000
VsbEth2/1    up     up  Eth1   Eth1        1000           9000
VsbEth2/2    up     up  Eth1   Eth1        1000           9000
VsbEth2/3    up     up  Eth1   Eth1        1000           9000
control0    up     up  Eth1   Eth1        1000           9000
mgmt0    up     up  Eth1   Eth1        1000           9000
switch#

MIBs

To locate and download MIBs, go to the following URL:

Click Here

Feature History for Virtual Service Blades

This section provides the release history for VSBs.

Feature Name

Releases

Feature Information

Static network uplink

5.2(1)SP1(7.1)

This feature was removed.

Support for KVM VSB

5.2(1)SP1(7.1)

This feature was introduced.

Enabling the 10-Gbps interface

5.2(1)SP1(7.1)

This feature was introduced.

Enabling the Cavium NITROX crypto card

5.2(1)SP1(7.1)

This feature was introduced.

Automatic execution of the copy running-config startup-config command

5.2(1)SP1(7.1)

This feature was introduced.

Passthrough interface

4.2(1)SP1(6.1)

This feature was introduced.

Creating VSBs for the VXLAN gateway

4.2(1)SP1(6.1)

This feature was introduced.

Setting up different form factors for the Cisco VSG VSBs

4.2(1)SP1(6.1)

This feature was introduced.

show virtual-service-blade name name statistics command

4.2(1)SP1(5.1)

This feature was introduced.

Creating and exporting a VSB backup file

4.2(1)SP1(3)

This feature was introduced.

Importing a VSB backup file

4.2(1)SP1(3)

This feature was introduced.

Escape sequence

4.2(1)SP1(2)

This feature was introduced.

VSB

4.0(4)SP1(1)

This feature was introduced.

Chapter 6. Migrating Virtual Supervisor Modules

This chapter contains the following sections:

- Information About Migrating a Virtual Supervisor Module

- Guidelines and Limitations for Migrating a Virtual Supervisor Module

- Migrating a Virtual Service Module to the Cisco Nexus Cloud Services Platform

- Verifying the Migration

- Migrating a Virtual Supervisor Module from the Cisco Nexus Cloud Services Platform to the Hypervisor Server

- Feature History for Virtual Supervisor Module Migration

Information About Migrating a Virtual Supervisor Module

After you have installed the Cisco Nexus Cloud Services Platform, you can move or migrate your Virtual Supervisor Modules (VSMs) from virtual machines (VMs) to the Cisco Nexus Cloud Services Platform.

The hypervisor server represents one of the following hypervisors:

- VMware vSphere

- Microsoft Hyper-V

- KVM

The following figure assumes that the standby state VSM VM on the hypervisor server is also assigned the secondary HA role. If your standby state VSM VM is assigned the primary role, you must reverse the roles in the flowchart.

Migrating a VSM to the Cisco Nexus Cloud Services Platform

Guidelines and Limitations for Migrating a Virtual Supervisor Module

- You must use the same management VLAN for both the Virtual Supervisor Module (VSM) that you are migrating and the Cisco Nexus Cloud Services Platform.

- You must use the same RAM size and disk size for the virtual service that you used for the VSM VM.

Migrating a Virtual Service Module to the Cisco Nexus Cloud Services Platform

You can move or migrate VSMs to the Cisco Nexus Cloud Services Platform without a service interruption.

This procedure describes the migration of a VSM from ESXi to the Cisco Nexus Cloud Services Platform using the ESX vSphere Client.

Before You Begin

- You have installed a primary and secondary Cisco Nexus Cloud Services Platform in HA mode.

- Log in to the CLI of the Cisco Nexus Cloud Services Platform in EXEC mode.

- Know the name of the VSM that you want to move or migrate from the hypervisor server.

- The Cisco Nexus 1000V software must already be installed and upgraded to Release 5.2(1)SP1(7.1) on the hypervisor server.

- For information about installing the software, see the Cisco Nexus 1000V Installation and Upgrade Guide.

- For information about upgrading, see the Cisco Nexus 1000V Installation and Upgrade Guide.

- When you are creating the secondary virtual service, use the same information that you used for the primary VSM for the following:

- ISO filename

- Management IP address

- Domain ID

- Hostname

- Default gateway

- Control and packet VLAN IDs

Caution

If you use a value that results in a mismatch with the hypervisor, the synchronization between the hypervisor and the Cisco Nexus Cloud Services Platform overwrites your configuration on the Cisco Nexus Cloud Services Platform.

- When you are creating the secondary virtual service, use the same information that you used for the VSM VM for the following:

- RAM size

- Disk size

- Designate the secondary VSM as active. If the primary VSM is active, change it to make the secondary VSM active.

Procedure

Step 1

From the ESX vSphere Client, right-click the standby VSM and from the drop-down list, choose power off.
The standby VSM is powered off.

Step 2

From the ESX vSphere Client, right-click the standby VSM and from the drop-down list, choose delete from disk.
The standby VSM is removed from the hypervisor server. Only the primary VSM is active on the hypervisor server with modules attached.

Step 3

From the CLI of the active Cisco Nexus Cloud Services Platform, create a primary virtual service for the VSM that you want to migrate.
Use the same information that you used to create the secondary VSM.

Example:

switch# configure terminal
switch(config)# virtual-service-blade VB-1
switch(config-vsb-config)# virtual-service-blade-type new new dcos_vsm.iso
switch(config-vsb-config)# ramsize 2048
switch(config-vsb-config)# disksize 4
switch(config-vsb-config)# interface control vlan 1322
switch(config-vsb-config)# interface packet vlan 1323
switch(config-vsb-config)# enable primary
Enter domain id[1-4095]: 1322
Management IP version [V4/V6]: [V4]
Enter Management IP address: 10.78.109.67
Enter Management subnet mask: 255.255.255.224
IPv4 address of the default gateway: 10.78.109.65
Enter HostName: switch
Enter the password for 'admin': xz35vb1zx
switch(config-vsb-config)#

Step 4

Verify that the configuration is complete.

Example:

switch# show virtual-service-blade summary

-------------------------------------------------------------------------------
Name                HA-Role     HA-Status   Status                   Location
-------------------------------------------------------------------------------
VSM1                PRIMARY     ACTIVE      VSB POWERED ON           PRIMARY
VSM1                SECONDARY   NONE        VSB NOT PRESENT          SECONDARY
vsm                 PRIMARY     ACTIVE      VSB POWERED ON           PRIMARY

Step 5

From the CLI of the secondary VSM on the hypervisor server, verify the redundancy status of the VSMs.
If the output indicates the following, you can proceed with a system switchover:

- The presence of an active VSM

- The presence of a standby VSM in the HA standby redundancy state

Example:

switch# show system redundancy status
Redundancy role
---------------
administrative: primary
operational: primary
Redundancy mode
---------------
administrative: HA
operational: HA
This supervisor (sup-1)
-----------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby
Other supervisor (sup-2)
------------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby

Step 6

From the CLI of the secondary VSM on the hypervisor server, initiate a manual switchover to the standby virtual service on the Cisco Nexus Cloud Services Platform.
Before continuing with the next step, wait until the switchover completes and the standby supervisor becomes active. The following occurs when the switchover is complete:

- The VSM on the hypervisor server reboots.

- The virtual service configuration on the Cisco Nexus Cloud Services Platform is overwritten to match what is on the VSM on the hypervisor server. The primary virtual service on the Cisco Nexus Cloud Services Platform is now the active VSM.

Example:

switch# system switchover
----------------------------
2009 Mar 31 04:21:56 n1000v %$ VDC-1 %$ %SYSMGR-2-HASWITCHOVER_PRE_START:
This supervisor is becoming active (pre-start phase).
2009 Mar 31 04:21:56 n1000v %$ VDC-1 %$ %SYSMGR-2-HASWITCHOVER_START:
This supervisor is becoming active.
2009 Mar 31 04:21:57 n1000v %$ VDC-1 %$ %SYSMGR-2-SWITCHOVER_OVER: Switchover completed.
2009 Mar 31 04:22:03 n1000v %$ VDC-1 %$ %PLATFORM-2-MOD_REMOVE: Module 1 removed (Serial number )
switch#

Step 7

From the ESX vCenter Client, right-click the standby VSM and from the drop-down list, choose power off.
The standby VSM is powered off.

Step 8

From the ESX vCenter Client, right-click the standby VSM and from the drop-down list, choose delete from disk.
The standby VSM is removed from the hypervisor server.

Step 9

From the CLI of the active Cisco Nexus Cloud Services Platform, use the following commands to create a new secondary virtual service. Use the same information that you used to create the primary virtual service.
After you enter the commands that are shown in the output, the Cisco Nexus Cloud Services Platform prompts you for additional information. After you create the secondary virtual service on the active Cisco Nexus Cloud Services Platform, an HA pair is formed between the primary virtual service and the secondary virtual service on the Cisco Nexus Cloud Services Platform.

Example:

switch# configure terminal
switch(config)# virtual-service-blade VB-1
switch(config-vsb-config)# enable secondary
Enter vsb image: [dcos_vsm.iso]
Enter domain id[1-4095]: 1322
Management IP version [V4/V6]: [V4]
Enter Management IP address: 10.78.109.67
Enter Management subnet mask length: 27
IPv4 address of the default gateway: 10.78.109.65
Enter HostName: switch
Enter the password for 'admin': xz35vb1zx

Step 10

Verify that the configuration is complete.

Example:

switch# show virtual-service-blade summary

-------------------------------------------------------------------------------
Name                HA-Role     HA-Status   Status                   Location
-------------------------------------------------------------------------------
VSM1                PRIMARY     ACTIVE      VSB POWERED ON           PRIMARY
VSM1                SECONDARY   NONE        VSB NOT PRESENT          SECONDARY
vsm                 PRIMARY     ACTIVE      VSB POWERED ON           PRIMARY

Verifying the Migration

Use the commands in the following table to verify the migration.

Command

Purpose

show virtual-service-blade summary

Displays a summary of the VSB status.

show system redundancy status

Displays the redundancy state (active or standby) and the redundancy role (primary or secondary) for the Cisco Nexus Cloud Services Platform.

Example: show virtual service blade summary

This example shows how to display the virtual service blade summary:

switch# show virtual-service-blade summary

-------------------------------------------------------------------------------
Name HA-Role HA-Status Status Location
-------------------------------------------------------------------------------
NEW PRIMARY NONE VSB NOT PRESENT PRIMARY
NEW SECONDARY NONE VSB NOT PRESENT SECONDARY
CY_MTU PRIMARY ACTIVE VSB POWERED ON PRIMARY
CY_MTU SECONDARY STANDBY VSB POWERED ON SECONDARY
switch#

Example: show system redundancy status

This example shows how to display the system redundancy status:

switch# show system redundancy status
Redundancy role
---------------
administrative: primary
operational: primary
Redundancy mode
---------------
administrative: HA
operational: HA
This supervisor (sup-1)
-----------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby
Other supervisor (sup-2)
------------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby

Migrating a Virtual Supervisor Module from the Cisco Nexus Cloud Services Platform to the Hypervisor Server

You can move or migrate a Cisco Nexus 1000V VSM from the Cisco Nexus Cloud Services Platform to a hypervisor server.

Note

This procedure describes the migration of a VSM from the Cisco Nexus Cloud Services Platform to ESXi using the ESX vSphere Client.

Before You Begin

- Install a primary and secondary Cisco Nexus Cloud Services Platform in HA mode.

- Designate the primary VSM as active and the secondary VSM as standby.

- Log in to the CLI of the Cisco Nexus Cloud Services Platform in EXEC mode.

- Know the name of the VSM that you want to move or migrate to the hypervisor server.

Procedure

Step 1

From the CLI of the secondary VSM on the Cisco Nexus Cloud Services Platform, enter the following commands to shut down the secondary standby VSM on the Cisco Nexus Cloud Services Platform:

configure terminal
virtual service blade name
shutdown secondary

Step 2

Create the secondary VSM on a hypervisor server. The release number of the VSM that is installed on the hypervisor server should be the same as that of the VSM already installed on the Cisco Nexus Cloud Services Platform.
See the Cisco Nexus 1000V Installation and Upgrade Guide for more information about installing the software on the hypervisor server.

Step 3

When you are creating the secondary VSM on a hypervisor server, use the same information that you used for creating the primary VSM on the Cisco Nexus Cloud Services Platform for the following:

- ISO filename

- Management IP address

- Management VLAN ID

- Domain ID

- Hostname

- Default gateway

- Control and packet VLAN IDs

Step 4

When you are creating the secondary VSM, use the same information that you used for the VSM on the Cisco Nexus Cloud Services Platform for the following:

- RAM size

- Disk size

Step 5

From the ESX vSphere Client, right-click the secondary VSM and choose power on from the drop-down list. Ensure that there is HA communication between the primary VSM on the Cisco Nexus Cloud Services Platform and the secondary VSM on the hypervisor server.

Step 6

Designate the secondary VSM on the hypervisor server as active.

Step 7

From the CLI of the primary Cisco Nexus Cloud Services Platform, enter the following commands to shut down the primary VSM on the Cisco Nexus Cloud Services Platform:

configure terminal
virtual service blade name
shutdown primary

Step 8

Create the primary VSM on the hypervisor server using the same parameters that you used in this procedure for creating the secondary VSM.

Step 9

From the ESX vSphere Client, right-click the primary VSM and choose power on from the drop-down list.

Step 10

From the CLI of the Cisco Nexus Cloud Services Platform, enter the following commands to remove the VSM:

configure terminal
no virtual service blade name

The VSM is migrated from the Cisco Nexus Cloud Services Platform to the hypervisor server.

Feature History for Virtual Supervisor Module Migration

This section provides the migration feature release history.

Feature Name

Releases

Feature Information

VSM Migration

4.0(4)SP1(1)

This feature was introduced.

Chapter 7. Exporting and Importing a Virtual Service Blade

This chapter contains the following sections:

- Information About Exporting and Importing a Virtual Service Blade

- Guidelines and Limitations for Exporting and Importing a Virtual Service Blade

- Exporting a Virtual Service Blade

- Importing a Virtual Service Blade

- Verifying the Export and Import of a Virtual Service Blade

- Feature History for Export and Import

Information About Exporting and Importing a Virtual Service Blade

You can export or import a virtual service blade (VSB) on the Cisco Nexus Cloud Services Platform by creating a copy of the VSB backup file. You can store this backup file remotely to use as a recovery mechanism, or when you need to move a VSB between two Cisco Nexus Cloud Services Platforms.

Guidelines and Limitations for Exporting and Importing a Virtual Service Blade

VSB import and export guidelines are as follows:

- You can create multiple export files with this process. Do not change the file suffix for numbering purposes. If you change the prefix for one file, you must change it for all files.

- You must shut down the VSB before creating the file to export.

- The bootflash export-import directory must be empty before you can create an export file or copy the file from external storage.

Exporting a Virtual Service Blade

You can create a backup copy of a VSB, store it remotely, and then reimport it to either recover a virtual supervisor module (VSM), or move a VSB between Cisco Nexus Cloud Services Platforms.

- Exporting a Virtual Service Blade Backup File

- Copying the Exported Virtual Service Blade to an External Storage Location

Exporting a Virtual Service Blade Backup File

Before You Begin

- Log in to the CLI of the Cisco Nexus Cloud Services Platform in EXEC mode.

- Know the name of the VSB for which you are creating a file to export.

- Enter the copy running-config startup-config command to save the running configuration before you begin this procedure.

- Verify that the bootflash: export-import directory is empty. If there are files in this directory, you must delete them before starting this procedure.

- Shut down the VSB that you want to back up before creating the file to export. This procedure includes a step for shutting down the VSB, and then a step for restarting the VSB after creating the file.

Procedure

Command or Action

Purpose

Step 1

switch # dir bootflash:export-import

Displays the contents of the export-import directory for verification that the directory is empty. If there is anything in this directory, you must use the next step to delete it before proceeding.

Step 2

switch (config-vsb-config) # delete bootflash:export-import foldername

(Optional)
Deletes the VSB compressed tar file and the folder that was created for export.

Step 3

switch # configure terminal

Enters global configuration mode.

Step 4

switch (config) # virtual-service-blade name

Enters the configuration mode for the named VSB.

Step 5

switch (config-vsb-config) # shutdown [primary | secondary]

Shuts down the VSB that you are exporting from. If you have a redundant pair of Cisco Nexus Cloud Services Platforms, you must specify whether to shut down the primary or secondary.

Step 6

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

(Optional) Displays the summary VSB configuration for verification.

Step 7

switch (config-vsb-config) # export [primary | secondary]

Creates a directory named for the slot ID of the exported VSB that contains a compressed tar image of the VSB.

If you are exporting from a redundant pair of Cisco Nexus Cloud Services Platforms, you must specify whether you are exporting from the primary or secondary.

Note:   The export command does not move the configuration file off of the Cisco Nexus Cloud Services Platform. It creates a backup copy that you must then copy to the remote storage location.

Step 8

switch (config-vsb-config) # dir bootflash:export-import

Displays the contents of the bootflash: export-import directory, including the directory name of the folder that contains the compressed tar image of the VSB for verification. You need this folder name in Step 11.

Step 9

switch (config-vsb-config) # no shutdown [primary | secondary]

Powers on the VSB that was powered off when creating the file for export. If you have a redundant pair of Cisco Nexus Cloud Services Platforms, you must specify primary or secondary.

Step 10

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

(Optional)
Displays the VSB configuration for verification.

Step 11

switch (config-vsb-config) # dir bootflash:export-import /directory-name

Displays the contents of the Cisco Nexus Cloud Services Platform export folder, including the filename of the VSB compressed tar image.

Note:

- You identified this folder name in Step 8.

- You can create multiple export files. Do not change the file suffix for numbering purposes. If you change the prefix for one file, you must change it for all files.

This example shows how to create a VSB backup file:

switch# dir bootflash:export-import

Usage for bootflash://sup-local
496164864 bytes used
3495215104 bytes free
3991379968 bytes total

switch-1(config-vsb-config)# delete bootflash:/export-import/1/*.*
switch-1(config-vsb-config)# delete bootflash:/export-import/1
switch-1(config-vsb-config)#
switch-1# configure terminal
switch-1(config)# virtual-service-blade vsm-1
switch-1(config-vsb-config)# shutdown secondary
switch-1(config-vsb-config)# show virtual-service-blade summary

-------------------------------------------------------------------------------
Name               Role        State                   Nexus1010-Module
-------------------------------------------------------------------------------
VSM1               PRIMARY     VSB POWERED ON          Nexus1010-PRIMARY
VSM1               SECONDARY   VSB POWERED OFF         Nexus1010-SECONDARY

Example of a successful completion of a VSB

switch-1(config-vsb-config)# export secondary
Note: export started..
Note: please be patient..
Note: please be patient..
Note: please be patient..
Note: export completed...switch-1(config-vsb-config)#

Example of an error condition while exporting a VSB

switch-1(config-vsb-config)# export primary
ERROR: Please clean export-import directory first, then proceed.

Example of an error condition while exporting a secondary VSB

switch-1(config-vsb-config)# export secondary
ERROR: Cannot export active virtual-service-blade, please shut and retry.

switch-1(config-vsb-config)# dir bootflash:export-import
4096      Sep 08 19:12:52 2011 1/

Usage for bootflash://sup-local
310870016 bytes used
3680509952 bytes free
3991379968 bytes total

switch-1(config-vsb-config)# no shutdown secondary
switch-1(config-vsb-config)# show virtual-service-blade summary

-------------------------------------------------------------------------------
Name                Role        State                   Nexus1010-Module
-------------------------------------------------------------------------------
VSM1                PRIMARY     VSB POWERED ON          Nexus1010-PRIMARY
VSM1                SECONDARY   VSB POWERED ON          Nexus1010-SECONDARY

switch-1(config-vsb-config)# dir bootflash:export-import/1
279955021     Sep 08 19:13:21 2011  Vdisk1.img.tar.00

Usage for bootflash://sup-local
310870016 bytes used
3680509952 bytes free
3991379968 bytes total

Copying the Exported Virtual Service Blade to an External Storage Location

You can copy the exported VSB to a remote storage location and then delete the folder created for this purpose from the Cisco Nexus Cloud Services Platform.

Before You Begin

- You have created a file to export and you know the name of this file and the name of the folder that it resides in.

Note

You can create multiple files. If you do, use the first filename in this procedure. Do not change the file suffix for numbering purposes. If you change the prefix for one file, you must change it for all files.

- Log in to the CLI of the Cisco Nexus Cloud Services Platform in EXEC mode.

- Know the name of the path to a remote storage location.

- After copying the export backup file, delete the contents, including the files and folders, of the export-import directory. Do not delete the export-import folder.

Procedure

Command or Action

Purpose

Step 1

switch # copy bootflash:export-import /folder-name/filename ftp:

Copies the VSB image from the Cisco Nexus Cloud Services Platform export-import folder to a remote storage location.

Step 2

switch # delete bootflash:export-import /folder-name

Deletes the VSB compressed tar file and the folder that was created for export.

Step 3

switch # dir

Displays the contents of the export-import directory for verification.

This example shows how to copy a VSB file to an external location:

switch# copy bootflash:export-import/1/Vdisk1.img.tar.00 ftp:
Enter vrf (If no input, current vrf 'default' is considered):
Enter hostname for the ftp server: 10.78.109.51
Enter username: administrator
Password:
***** Transfer of file Completed Successfully *****
switch# delete bootflash:/export-import/1/Vdisk1.img.tar.00
switch# delete bootflash:/export-import/1
switch# dir
switch#

Importing a Virtual Service Blade

You can import a previously saved backup copy of a VSB from a remote storage location to the Cisco Nexus Cloud Services Platform.

Before You Begin

- Log in to the CLI of the active Cisco Nexus Cloud Services Platform in EXEC mode.

- Create and save a copy of the VSB configuration in a remote storage location.

Note

You can create multiple VSB configuration files. If you do, use only the first filename with the import command. Do not change the file suffix for numbering purposes. If you change the prefix for one file, you must change it for all files.

- Know the name of the VSB and the path to the remote storage location.

- Verify that the bootflash:export-import folder is empty. If there are files in this directory, you must delete them before importing a VSB configuration file.

- If an imported HA VSB role does not match the role of the Cisco Nexus Cloud Services Platform on which it is imported, change the HA VSB role internally to match the Cisco Nexus Cloud Services Platform.

Procedure

Command or Action

Purpose

Step 1

switch # dir bootflash:export-import

Displays the contents of the bootflash:export-import folder for verification that the directory is empty. If there is anything in this directory, you must use the next step to delete it before proceeding.

Step 2

switch (config-vsb-config) # delete bootflash:export-import foldername

(Optional)
Deletes the VSB compressed tar file and the directory created for export.

Step 3

switch # copy ftp: filename bootflash:export-import

Copies the exported image file from a remote storage location into the Cisco Nexus Cloud Services Platform export-import directory in the bootflash:export-import folder.

filename—The name of the export file. Multiple files might have been created. If so, copy these files into the bootflash:export-import folder and use only the first filename with the import command. Do not change the file suffix for numbering purposes. If you change the prefix for one file, you must change it for all files.

Step 4

switch # configure terminal

Enters global configuration mode.

Step 5

switch (config) # virtual-service-blade name

Enters configuration mode for the named VSB.

Step 6

switch (config-vsb-config) # import primary filename

Powers off the primary VSB, imports the specified VSB configuration file, and then removes the configuration file from the bootflash:import-export folder.

filename—The name of the export file that you copied from the remote server to the bootflash:repository.

Step 7

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

(Optional)
Displays a summary of all VSB configurations by type name. Verify that the primary VSB is powered off.

Step 8

Complete the following tasks:

- See Configuring Port Channels.

- See Assigning Uplinks to a VSB Interface.

Step 9

switch # no shutdown primary filename

Powers on the primary VSB and imports the primary VSB configuration.

filename—The name of the imported primary VSB.

Step 10

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

(Optional)
Displays the VSB information for verification. From the command output, make a note of the control and management VSB Ethernet interfaces.

Step 11

switch (config-vsb-config) # copy running-config startup-config

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

This example shows how to import a VSB backup file:

switch# dir bootflash export-import
switch# dir export-import

Usage for bootflash://sup-local
496164864 bytes used
3495215104 bytes free
3991379968 bytes total
switch#
switch-1(config-vsb-config)# delete Vdisk1.img.tar.00
switch-1(config-vsb-config)#
switch# copy ftp:Vdisk1.img.tar.00 bootflash:export-import
Enter vrf (If no input, current vrf 'default' is considered):
Enter hostname for the ftp server: 10.78.109.51
Enter username: administrator
Password:
***** Transfer of file Completed Successfully *****
switch-1# configure terminal
switch-1(config)# virtual-service-blade VSM1
switch-1(config-vsb-config)# import primary Vdisk1.img.tar.00
Note: import started..
Note: please be patient..
Note: Import cli returns check VSB status for completion

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

-------------------------------------------------------------------------------
Name                Role        State                    Nexus1010-Module
-------------------------------------------------------------------------------

VSM1                PRIMARY     VSB POWERED OFF          Nexus1010-PRIMARY
VSM1                SECONDARY   VSB POWERED ON           Nexus1010-SECONDARY

switch-1(config)# virtual-service-blade VSM1
switch-1(config)# no shutdown primary
switch-1(config-vsb-config)# show virtual-service-blade name VSM1
virtual-service-blade VSM1
Description:
Slot id:        1
Host Name:
Management IP:
VSB Type Name :  VSM-1.1
vCPU:           1
Ramsize:        2048
Disksize:       3
Heartbeat:      0
HA Admin role: Primary
HA Oper role: NONE
Status:       VSB POWERED OFF
Location:     PRIMARY
SW version:
VsbEthernet1/1/1:  control     vlan:   1306    state:     up
VsbEthernet1/1/2:  management  vlan:   1304    state:     up
VsbEthernet1/1/3:  packet      vlan:   1307    state:     up
Interface:         internal    vlan:     NA    state:     up
HA Admin role: Secondary
HA Oper role: NONE
Status:       VSB POWERED ON
Location:     SECONDARY
SW version:
VSB Info:

switch-1(config-vsb-config)# copy running-config startup-config

Verifying the Export and Import of a Virtual Service Blade

To verify the export and import, use the following commands:

Command

Purpose

dir bootflash:export-import /folder-name

Displays the contents of the export-import directory.

show virtual-service-blade summary

Displays the redundancy state (active or standby) and the redundancy role (primary or secondary) for each VSB.

show virtual-service-blade [name name]

Displays the configuration for a specific VSB.

This example shows an export-import directory:

switch-1(config-vsb-config)# dir bootflash:export-import/1
279955021     Sep 08 19:13:21 2011  Vdisk1.img.tar.00

Usage for bootflash://sup-local
310870016 bytes used
3680509952 bytes free
3991379968 bytes total

This example shows how to display summary information for a VSB:

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

-------------------------------------------------------------------------------
Name                Role        State                    Nexus1010-Module
-------------------------------------------------------------------------------

VSM1                PRIMARY     VSB POWERED OFF          Nexus1010-PRIMARY
VSM1                SECONDARY   VSB POWERED ON           Nexus1010-SECONDARY

This example shows how to display information for a named VSB:

switch# show virtual-service-blade name VSM1
virtual-service-blade VSM1
Description:
Slot id:        1
Host Name:
Management IP:
VSB Type Name :  VSM-1.1
vCPU:           1
Ramsize:        2048
Disksize:       3
Heartbeat:      0
HA Admin role: Primary
HA Oper role: NONE
Status:       VSB POWERED OFF
Location:     PRIMARY
SW version:
VsbEthernet1/1/1:  control     vlan:   1306    state:     down
VsbEthernet1/1/2:  management  vlan:   1304    state:     down
VsbEthernet1/1/3:  packet      vlan:   1307    state:     up
Interface:         internal    vlan:     NA    state:     up
HA Admin role: Secondary
HA Oper role: NONE
Status:       VSB POWERED ON
Location:     SECONDARY
SW version:
VSB Info:
switch-1(config)#

Feature History for Export and Import

This section provides the feature release history.

Feature Name

Releases

Feature Information

VSB export and import

4.2(1)SP1(3)

This feature was introduced.

Chapter 8. Migrating a Virtual Service Blade to the Cisco Nexus 1110 Series

This chapter contains the following sections:

- Information About Migrating Virtual Service Blades

- Guidelines and Limitations for Migrating a Virtual Service Blade

- Migrating a Virtual Service Blade to the Cisco Nexus 1110 Series

- Migrating an HA Virtual Service Blade to the Cisco Nexus 1110 Series

- Migrating a Non-HA VSB to the Cisco Nexus 1110 Series

- Migrating an OVA to the Cisco Nexus Cloud Services Platform

- Verifying the Migration

- Feature History for Migration

Information About Migrating Virtual Service Blades

After you have installed the Cisco Nexus Cloud Services Platform, you can move or migrate your virtual service blades (VSBs) from the Cisco Nexus 1010 series to the Cisco Nexus 1110 series. For more information, see Information About Virtual Service Blades.

Guidelines and Limitations for Migrating a Virtual Service Blade

The Cisco Nexus Cloud Services Platform has the following guidelines and limitations for migrating a VSB from the Cisco Nexus 1010 series to the Cisco Nexus 1110 series:

- You cannot form an HA pair with a Cisco Nexus 1110-S and a Cisco Nexus 1110-X. An HA pair can only be formed with the same hardware.

- You must use the same management VLAN for both the Cisco Nexus 1010 series and the Cisco Nexus 1110 series.

- You must use the same RAM size and disk size for the new VSB on the Cisco Nexus Cloud Services Platform that you used for migrating the VSB on the Cisco Nexus 1110 series.

Migrating a Virtual Service Blade to the Cisco Nexus 1110 Series

Procedure

Step 1

Verify that the Cisco Nexus 1010 series has the VSBs configured that need to be migrated to the Cisco Nexus 1110 series.

Step 2

Set up the Cisco Nexus 1110 series in a redundant HA pair.
See the Cisco Nexus Cloud Services Platform Software Installation and Upgrade Guide.

Step 3

Migrate the HA VSBs such as the VSM and Cisco VSG to the Cisco Nexus 1110.
See Migrating an HA Virtual Service Blade to the Cisco Nexus 1110 Series.

Step 4

Migrate the non-HA VSBs such as the Cisco NAM to the Cisco Nexus 1110.
See Migrating a Non-HA VSB to the Cisco Nexus 1110 Series.

Migrating an HA Virtual Service Blade to the Cisco Nexus 1110 Series

Before You Begin

- You have installed a primary and secondary Cisco Nexus 1110 in HA mode.

- Log in to the CLI of the Cisco Nexus 1110 in EXEC mode.

- Know the name of the VSB that you want to move or migrate from the Cisco Nexus 1010.

- When you are creating the secondary virtual service, use the same information that you used for the primary VSB for the following:

- ISO filename

- Management IP address

- Domain ID

- Hostname

- Default gateway

- Control and packet VLAN IDs

Note

If you use a value that results in a mismatch with the Cisco Nexus 1110, the synchronization between the Cisco Nexus 1110 and the Cisco Nexus 1010 overwrites your configuration on the Cisco Nexus 1010.

- When you are creating the secondary virtual service, use the same information that you used for the VSB for the following:

- RAM size

- Disk size

- Designate the secondary VSM as active. If the primary VSM is active, change it to make the secondary VSM active.

Procedure

Step 1

From the CLI of the primary VSB on the Cisco Nexus 1010, initiate a manual switchover, and then shut down the primary VSB by entering the configure terminal virtual-service-blade name login virtual-service-blade name primary command.
After logging into the VSB, enter the system switchover command to initiate a manual switchover. When the switchover completes and the CLI returns to the Cisco Nexus 1010, enter the shut primary command to shut the primary VSB.

Step 2

From the CLI of the active Cisco Nexus 1110, create a primary virtual service for the VSB that you want to migrate.
Use the same information that you used to create the VSB on the Cisco Nexus 1010.

Step 3

Verify that the configuration is complete.
After you create the virtual service on the primary Cisco Nexus 1110, an HA pair forms between the secondary VSB on the Cisco Nexus 1010 and the primary virtual service on the Cisco Nexus 1110.

Step 4

From the CLI of the primary VSB on the Cisco Nexus 1110, verify the redundancy status of the VSBs.
If the output indicates the following, you can proceed with a system switchover:

- The presence of an active VSB

- The presence of a standby VSB in the HA standby redundancy state

Step 5

From the CLI of the secondary VSB on the Cisco Nexus 1010, initiate a manual switchover to the standby virtual service on the Cisco Nexus 1110. After logging into the VSB, enter the system switchover command to initiate a manual switchover.
When the switchover completes and the CLI returns to the Cisco Nexus 1010, use the shut secondary command to shut the secondary VSB. Before continuing with the next step, wait until the switchover completes and the standby supervisor becomes active. The following occurs when the switchover is complete:

- The VSB on the Cisco Nexus 1010 reboots.

- The virtual service configuration on the Cisco Nexus 1110 is overwritten to match what is on the VSB on the Cisco Nexus 1010.

- The primary virtual service on the Cisco Nexus Cloud Services Platform is now the active VSB.

Step 6

From the CLI of the active Cisco Nexus 1110, create a new secondary virtual service. Use the same information that you used to create the primary virtual service.
After you enter the commands, the Cisco Nexus 1110 prompts you for additional information. After you create the secondary virtual service on the active Cisco Nexus 1110, an HA pair is formed between the primary virtual service and the secondary virtual service on the Cisco Nexus 1110.

Step 7

Verify that the configuration is complete. The VSB is migrated from the Cisco Nexus 1010 series to the Cisco Nexus 1110 series.

This example shows how to create a primary virtual service for the VSB that you want to migrate:

switch# configure terminal
switch(config)# virtual-service-blade VB-1
switch(config-vsb-config)# virtual-service-blade-type new dcos_vsm.iso
switch(config-vsb-config)# interface control vlan 1322
switch(config-vsb-config)# interface packet vlan 1323
switch(config-vsb-config)# enable primary
Enter domain id[1-4095]: 1322
Management IP version [V4/V6]: [V4]
Enter Management IP address: 10.78.109.67
Enter Management subnet mask: 255.255.255.224
IPv4 address of the default gateway: 10.78.109.65
Enter HostName: switch
Enter the password for 'admin': xz35vb1zx
switch(config-vsb-config)#

This example shows how to verify the configuration:

switch(config-vsb-config)# show virtual-service-blade summary
-------------------------------------------------------------------------------
Name                Role        State                        Nexus1010-Module
-------------------------------------------------------------------------------
VB-1                PRIMARY          VSB DEPLOY IN PROGRESS                Nexus1010-PRIMARY
VB-1                SECONDARY   VSB NOT PRESENT                                        Nexus1010-SECONDARY

This example shows how to check the redundancy status of the VSBs:

switch#show system redundancy status
Redundancy role
---------------
administrative: primary
operational: primary
Redundancy mode
---------------
administrative: HA
operational: HA
This supervisor (sup-1)
-----------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby
Other supervisor (sup-2)
------------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby

This example shows how to initiate a manual switchover to the standby virtual service:

switch# system switchover
----------------------------
2009 Mar 31 04:21:56 n1000v %$ VDC-1 %$ %SYSMGR-2-HASWITCHOVER_PRE_START:
This supervisor is becoming active (pre-start phase).
2009 Mar 31 04:21:56 n1000v %$ VDC-1 %$ %SYSMGR-2-HASWITCHOVER_START:
This supervisor is becoming active.
2009 Mar 31 04:21:57 n1000v %$ VDC-1 %$ %SYSMGR-2-SWITCHOVER_OVER: Switchover completed.
2009 Mar 31 04:22:03 n1000v %$ VDC-1 %$ %PLATFORM-2-MOD_REMOVE: Module 1 removed (Serial number )
switch#

This example shows how to create a secondary virtual service:

switch# configure terminal
switch(config)# virtual-service-blade VB-1
switch(config-vsb-config)# enable secondary
Enter vsb image: [dcos_vsm.iso]
Enter domain id[1-4095]: 1322
Management IP version [V4/V6]: [V4]
Enter Management IP address: 10.78.109.67
Enter Management subnet mask length: 27
IPv4 address of the default gateway: 10.78.109.65
Enter HostName: switch
Enter the password for 'admin': xz35vb1zx

This examples shows the VSB summary after you create a secondary virtual service.

Example:
switch(config-vsb-config)# show virtual-service-blade summary
-------------------------------------------------------------------------------
Name                Role        State                                                            Nexus1010-Module
-------------------------------------------------------------------------------
VB-1                PRIMARY     VSB POWERED ON                                    Nexus1010-PRIMARY
VB-1                SECONDARY   VSB DEPLOY IN PROGRESS  Nexus1010-SECONDARY

Migrating a Non-HA VSB to the Cisco Nexus 1110 Series

Procedure

Step 1

From the CLI of the Cisco Nexus Cloud Services Platform, power off the non-HA VSB on the Cisco Nexus Cloud Services Platform.

Step 2

Export the non-HA VSB to the Cisco Nexus Cloud Services Platform. See Exporting a Virtual Service Blade Backup File.

Step 3

Copy a VSB configuration file to external storage location. See Copying the Exported Virtual Service Blade to an External Storage Location.

Step 4

Import the non-HA VSB to the Cisco Nexus 1110. See Importing a Virtual Service Blade.

Step 5

From the CLI of the Cisco Nexus 1110, power on the imported non-HA VSB on the Cisco Nexus 1110.

This example shows how to migrate a non-HA VSB to the Cisco Nexus 1110:

switch# configure terminal
switch(config)# virtual-service-blade NAM
switch(config-vsb-config)# shut
switch(config-vsb-config)# export
Note: export started..
Note: please be patient..
...
Note: export completed...
switch(config-vsb-config)# copy bootflash:export-import/1/ ftp:
Enter the source filename:  Vdisk1.img.tar.00
Enter vrf (If no input, current vrf 'default' is considered):
Enter hostname for the ftp server: 10.78.109.51
Enter username: administrator
Password:
***** Transfer of file Completed Successfully *****

On Cisco Nexus 1110 Series CLI:
switch# configure terminal
switch(config)# copy ftp: bootflash:export-import
Enter source filename: Vdisk1.img.tar.00
Enter vrf (If no input, current vrf 'default' is considered):
Enter hostname for the ftp server: 10.78.109.51
Enter username: administrator
Password:
***** Transfer of file Completed Successfully *****

switch#configure terminal
switch(config)# virtual-service-blade NAM
switch(config-vsb-config)# import primary Vdisk1.img.tar.00
Note: import started..
Note: please be patient..
...
Note: Import cli returns check VSB status for completion
switch(config-vsb-config)# no shutdown

Migrating an OVA to the Cisco Nexus Cloud Services Platform

You can export an OVA from ESX and import it into the Cisco Nexus Cloud Services Platform as a VSB. You must run the migration tool script on the OVA and then take the generated tar file and use it for importing into the Cisco Nexus Cloud Services Platform.

Before You Begin

- You must have the following binaries installed:

- /bin/cp

- /bin/mkdir

- bin/rm

- bin/mv

- bin/tar

- vmware-vdiskmanager

- You must save the configuration on the VSB before exporting it to ESX.

Procedure

Step 1

Export the VSB to ESX and then copy the exported OVA into the esx_migration_tool/ directory.

Step 2

Run the migration tool script on the OVA.
If the migration tool supports the version number of the VSB, enter the following command: ./migration.sh <ova-filename> <vsb_type> <cookie> <ha-role> <vmware-vdiskmanager_location> [-v vsb_version]

- ova-filename—The name of the exported OVA file from ESX.

- vsb_type—Cisco VSG type such as VSM, VSG, or NAM.

- cookie—A positive integer unique for every slot. The cookie value for the primary and secondary Cisco Nexus Cloud Services Platform must be the same.

- ha-role—Either primary or secondary, and should be imported with the same HA role in the Cisco Nexus Cloud Services Platform.

- vmware-vdiskmanager_location—The path in which the vmware-vdiskmanager binary can be found.

- -v vsb_version—The version number of the VSB.

- vbtype_xml_file_path—The complete file path where the xml template file of the VSB is placed.

If the migration tool does not support the version number of the VSB, enter the following command: ./migration.sh <ova-filename> <vsb_type> <cookie> <ha-role> <vmware-vdiskmanager_location> [-f vbtype_xml_file_path]

Step 3

After the script executes, locate the split tar files in the esx_migration_tool/ directory.

Step 4

Use the tar file to import the VSB to the Cisco Nexus Cloud Services Platform. See Importing a Virtual Service Blade.

Step 5

Configure the interface VLAN values and power on the VSB.

This example shows how to run the migration script if the migration tool supports the VSB version number:

./migration.sh VSM.ova VSM 123456 primary /usr/bin/ -v 5.2(1)SP1(7.1)

This example shows how to run the migration script if the migration tool does not support the VSB version number:

./migration.sh VSM.ova VSM 678910 secondary /usr/bin/ -f /tmp/ovf_vbtype.xml

Verifying the Migration

To verify the migration, use the following commands

Command

Purpose

show virtual-service-blade summary

Displays the redundancy state (active or standby) and the redundancy role (primary or secondary) for each virtual service.

show system redundancy status

Displays the redundancy state (active or standby) and the redundancy role (primary or secondary) for the Cisco Nexus Cloud Services Platform.

This example shows a summary of the VSB information:

switch(config-vsb-config)# show virtual-service-blade summary
-------------------------------------------------------------------------------
Name                Role        State                    Nexus1010-Module
-------------------------------------------------------------------------------
VB-1                PRIMARY     VSB NOT PRESENT          Nexus1010-PRIMARY
VB-1                SECONDARY   VSB DEPLOY IN PROGRESS   Nexus1010-SECONDARY

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

-------------------------------------------------------------------------------
Name                Role        State                    Nexus1010-Module
-------------------------------------------------------------------------------
VB-1                PRIMARY     VSB NOT PRESENT          Nexus1010-PRIMARY
VB-1                SECONDARY   VSB POWERED ON           Nexus1010-SECONDARY

This example shows the system redundancy status:

switch# show system redundancy status
Redundancy role
---------------
administrative: primary
operational: primary
Redundancy mode
---------------
administrative: HA
operational: HA
This supervisor (sup-1)
-----------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby
Other supervisor (sup-2)
------------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby

Feature History for Migration

This section provides the migration feature release history.

Feature Name

Releases

Feature Information

VSB Migration

4.0(4)SP1(3)

This feature was introduced.

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)