The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to create and configure virtual service blades and includes the following sections:
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:
Note The Cisco Nexus Cloud Services Platform supports the Cisco Nexus 1000V Virtual Supervisor Modules (VSMs) for VMware vSphere and Microsoft Hyper-V hypervisors.
The Cisco Nexus Cloud Services Platform supports the following types of VSB::
For information about the supported VSBs and their weighting matrix, see the Cisco Nexus Cloud Services Platform Compatibility Information Guide.
The Cisco Nexus Cloud Services Platform product family supports the Cisco Nexus 1000V VSMs for VMware vSphere 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 controlling a group of virtual Ethernet modules (VEMs). From a network management perspective, a VSM and its VEMs makeup 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.
This section includes the following topics:
To create a VSM virtual service blade, see Creating a Virtual Service Blade.
The Cisco Nexus Cloud Services Platform and its hosted VSBs share the same management VLAN in a static topology because the management VLAN is inherited. However, this constraint does not exist in the flexible topology where the management VLAN of a VSB can be different from that of the Cisco Nexus Cloud Services Platform host.
High availability 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. As long as 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 high availability has the following features:
Note The Cisco Nexus Cloud Services Platform does not support the control VLAN and domain ID combinations in the following cases:
(a) Across a VSM and Cisco Nexus Cloud Services Platform
(b) Across VSMs of different releases
(c) Across VSMs of the same hypervisors (VMware or Hyper-V)
If a VSM/VSB is configured with such a combination, it might result in system instability and/or traffic loss.
For more information about high availability on the Cisco Nexus Cloud Services Platform, see the Cisco Nexus Cloud Services Platform High Availability section.
For more information about VSM high availability, see the Cisco Nexus 1000V High Availability and Redundancy Configuration Guide, Release 4.2(1)SV2(2.1) .
When you configure a Cisco Nexus 1000V 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 A Cisco Nexus 1000V VSM in this guide refers to the service on both VMware 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 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.
In any of these combinations, identifying the primary and secondary VSM becomes inconsistent and might result in flapping and 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 instance 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. Also, when the Cisco Nexus 1000V VSM stops communicating in the domain, the collision time is not updated anymore. After an hour elapses 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 subsequently 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/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 the Cisco Nexus Cloud Services Platform High Availability section.
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 .
You can create up to three Cisco Virtual Security Gateway (VSG) modules on the Cisco Nexus Cloud Services Platform with the VSG ISO image. You can copy the VSG ISO image from the following link and then copy it to the new VSG VSB when you create it.
The Cisco Nexus Cloud Services Platform product family does not support OVA deployment and migration on the Cisco VSG VSB.
VXLAN is a Layer 2 gateway that extends the Virtual Extensible LAN (VXLAN) Layer 2 domain to physical servers and services deployed on a VLAN. The 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.
The Cisco Nexus VXLAN Gateway is managed as a VEM from the Cisco Nexus 1000V 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 www.cisco.com and then copy it to the new VXLAN Gateway VSB when you create it.
The Cisco Nexus Cloud Services Platform product family does not support OVA deployment and migration on VXLAN GW VSB.
For more information about installing and configuring the Cisco Nexus VXLAN Gateway as a VSB, see the Cisco Nexus 1000V VXLAN Configuration Guide, Release 4.2(1)SV2(2.1).
Citrix NetScaler 1000V is a virtual appliance that provides comprehensive load balancing and traffic management capabilities. The Citrix NetScaler 1000V enables application aware L7 content switching, along with fundamental L4 load balancing functionality, featuring comprehensive health checks, session persistence mechanisms and load balancing algorithms to ensure traffic is always sent to the most appropriate server. Global Server Load Balancing feature on Citrix NetScaler 1000V also enhances disaster recovery by transparently redirecting users to alternate data centers in the event of an outage or interruption.
You can deploy the Citrix NetScaler 1000V on the Cisco Nexus Cloud Services Platform as a Virtual Service Blade. The Citrix NetScaler 1000V hosted on a Cisco Nexus Cloud Services Platform provides ease of deployment, giving you the flexibility to meet your performance use case with 2vCPU or 6vCPU deployments for high performance. Cisco Nexus Cloud Services Platform HA also enables NetScaler 1000V high availability.
For more information about installing and configuring the Citrix NetScaler 1000V as a VSB, see the Citrix NetScaler 1000V documentation.
Virtual Service Blades have the following configuration guidelines and limitations:
This section includes the following topics:
You can create a VSB such as a VSM, by installing and configuring the software.
Note For information about upgrading Cisco Nexus 1000V software on an existing VSB, see the Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1)SV2(2.1).
Before beginning this procedure, you must know or do the following:
– From a previously created VSB.
– Ships with the Cisco Nexus Cloud Services Platform in bootflash repository:
– Downloaded from www.cisco.com and copied to the bootflash repository.
– Management subnet mask length
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 after the other. 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.
3. show virtual- service-blade-type summary
4. virtual-service-blade-type [ name name | new iso file name | new ova file name ]
6. show virtual-service-blade name name
8. enable [primary | secondary]
|
|
|
---|---|---|
Creates the named virtual service blade and places you into configuration mode for that service. |
||
Displays a summary of all virtual service blade configurations by type name, such as VSM or NAM. You use this type name in the next step. |
||
switch(config-vsb-config)# show virtual-service-blade-type summary |
||
virtual-service-blade-type [ name name | new iso file name | new ova file name ] switch(config-vsb-config)# virtual-service-blade-type new nexus-1000v.4.2.1.SV1.5.1.iso virtual-service-blade-type new nexus-1000v.4.2.1.SV1.5.1.1010.ova |
Specifies the type and name of the software image file to add to this virtual service blade. The keywords are as follows:
|
|
(Optional) Adds a description to the virtual service blade. The description is an an alphanumeric string of up to 80 characters |
||
Displays the VSB that you have just created including the interface names that you configure in the next step. |
||
switch(config-vsb-config)# show virtual-service-blade name vsm-1 -------------------------------------------------------------------------- Interface Type VLAN State Uplink-Interface -------------------------------------------------------------------------- |
||
switch(config-vsb-config)# interface control vlan 1044 |
Applies the interface and VLAN ID to this VSB. Use the interface names from the Step 6 command output. If you attempt to apply an interface that is not present, the following error is displayed: |
|
Repeat Step 7 to apply additional interfaces. |
||
switch(config-vsb-config)# enable Enter Management IP address: 10.78.108.40 Enter Management subnet mask length 28 IPv4 address of the default gateway: 10.78.108.117 |
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: The Cisco Nexus Cloud Services Platform prompts you for the following: |
|
(Optional) Displays the new virtual service blade for verification. While the switch is configuring the virtual service blade, the switch output for this command progresses from in progress to powered on. |
||
switch(config-vsb-config)# show virtual-service-blade name vsm-1 ----------------------------------------------------------------------------------------- Interface Type VLAN State Uplink-Interface ----------------------------------------------------------------------------------------- VsbEthernet1/1 control 423 up up Po1 Po1 VsbEthernet1/2 management 231 up up Po1 Po1 |
||
copy running-config startup-config 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. |
Before beginning this procedure, you must know or do the following:
4. show virtual-service-blade summary
– no virtual-service-blade name
You can modify the control VLAN, packet VLAN, or the RAM size of a VSB and then make the corresponding changes to the VSM.
You can modify the control VLAN, packet VLAN, or the RAM size of a VSB.
Before beginning this procedure, you must know or do the following:
– If you are modifying the ram size or the control VLAN, then continue with the next step.
5. show virtual-service-blade summary
– interface control vlan vlanid
– interface control vlan vlanid
|
|
|
---|---|---|
|
||
Displays a summary of services for verification of the shutdown. |
||
Example: show virtual-service-blade summary ----------------------------------------------------------------------------------------- Name HA-Role HA-Status Status Location ----------------------------------------------------------------------------------------- vsm-1 PRIMARY ACTIVE VSB POWERED ON PRIMARY |
||
switch(config-vsb-config)# ramsize 1024 switch(config-vsb-config)# interface control vlan 1116 |
Modifies the VSB. You can modify any of the following virtual service blade parameters: |
|
Displays the VSB information for verification of the changes. |
||
switch(config-vsb-config)# show virtual-service-blade name vsm-1 ----------------------------------------------------------------------------------------- Interface Type VLAN State Uplink-Interface ----------------------------------------------------------------------------------------- VsbEthernet1/1 control 423 up up Po1 Po1 VsbEthernet1/2 management 231 up up Po1 Po1 |
||
Saves the running configuration persistently through reboots and restarts by copying it to the startup configuration. |
||
You have completed this procedure. You must now update the VSM configuration using the instructions in the Modifying a VSM on the Cisco Nexus 1000V section. |
You can modify the control VLAN ID, packet VLAN ID, or RAM size in the VSM configuration on the Cisco Nexus 1000V.
Before beginning this procedure, you must know or do the following:
1. login virtual-service-blade vb6
The Cisco Nexus Cloud Services Platform supports the Virtual Security Gateway as a VSB in different formats. While instantiating the Cisco VSG, you can define the form factor for the VSB by specifying the number of assigned virtual CPUs. Your network performance depends on the form factor that you choose to define for the Cisco VSG virtual service blade.
Table 4-1 lists the metrics of the Cisco VSG deployed as a VSB in different form factors:
Table 4-1 Metrics for defining form factors for a Cisco VSG VSB:
|
|
|
|
---|---|---|---|
For more information about the Cisco VSG, see the Cisco Virtual Security Gateway for Nexus 1000V Series Switch Configuration Guide . To create a VSB for Cisco VSG see Creating a Virtual Service Blade.
Before beginning this procedure, you must know or do the following:
3. (optional) shutdown (for modifying a running VSG)
6. show virtual-service-blade name
7. no shutdown ( optional - only if the VSG was shutdown per step 3)
A passthrough VSB interface has the following features and limitations:
A Passthrough interface has the following benefits:
Before beginning this procedure, you must know or do the following:
3. virtual-service-blade-type [ name name | new iso file name | new ova file name
This example shows how to display the running configuration of a Cisco Nexus VXLAN Gateway VSB in passthrough mode:
To verify the virtual service blade configuration, use the following commands:
|
|
---|---|
Displays a summary of all VSB configurations. Note This command is only recognized by the primary Cisco Nexus Cloud Services Platform. See Example 4-5 on page 4-28 . |
|
Displays a summary of all VSB configurations by type, such as VSM or NAM. See Example 4-1 on page 4-26 . |
|
Displays statistics for a specific VSB such as CPU utilization, memory, last reboot time, total number of reboots. See Example 4-6 on page 4-28 . |
|
Displays the uplink configuration for verification. See Example 4-2 on page 4-26 . |
|
Displays a summary of all interfaces including the ones configured in passthrough mode. See Example 4-7 on page 4-28 . |
Example 4-1 Virtual Service Blade Type
switch# show virtual-service-blade-type summary
Example 4-2 Network Uplink Type
switch# show network uplink type
Example 4-3 Virtual Service Blade Name
Example 4-4 Virtual Service Blade Name
Example 4-5 Virtual Service Blade Summary
switch# show virtual-service-blade summary
Example 4-6 Virtual Service Blade Statistics
For additional information related to implementing the VSB features, see the following sections:
|
|
---|---|
To locate and download MIBs, go to the following URL: http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml |
This section provides the virtual service blade release history.
|
|
|
---|---|---|
Commands and procedure added for exporting and importing a VSB configuration file. |
||
Procedure added for recovering a VSM using a saved configuration file. |
||