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 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.
Cisco Nexus 1000V VSM Virtual Service Blade
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.
VSB Management VLAN
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.
VSB High Availability
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:
- 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. 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 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.
- Back-up and save—You must save modifications to the configuration of a VSB and the Cisco Nexus Cloud Services Platform, and backup their respective 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 or save configuration commands do not produce uniform results on both the platforms.
- Removing 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 of the redundant pair of VSB's becomes unusable, you can remove it from only the Cisco Nexus Cloud Services Platform where it resides, which mitigates the recovery by preserving the remaining VSB in the HA pair.
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) .
Role Collision Detection on the Cisco Nexus Cloud Services Platform
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.
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, 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.
Cisco Network Analysis Module Virtual Service Blade
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 Blade
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.
Cisco Nexus VXLAN Gateway Virtual Service Blade
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 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 VXLAN Gateway as a VSB, see the Cisco Nexus 1000V VXLAN Configuration Guide, Release 4.2(1)SV2(2.1).
Configuring Virtual Service Blades
This section includes the following topics:
Creating a Virtual Service Blade
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 YOU BEGIN
Before beginning this procedure, you must know or do the following:
- 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.
– Ships with the Cisco Nexus Cloud Services Platform in bootflash repository:
– Downloaded from www. cisco.com and copied to the bootflash repository.
- If you are using an ISO file from the bootflash repository or downloaded, make sure that you know the filename.
- If you are using an ISO file from an existing virtual service blade, 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 IP4 address
– Switchname
– Administrator password
– Control and packet VLAN IDs
- This procedure shows you how to identify and assign control and packet VLANs for the virtual service blade. Do not assign a management VLAN because the management VLAN is inherited from the Cisco Nexus Cloud Services Platform.
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.
- If a terminal becomes unresponsive, open a new console and manually enter the commands one after the other to set up a new VSB.
SUMMARY STEPS
1. configure terminal
2. virtual-service-blade name
3. show vsb-type summary
4. virtual-service-blade-type [ name name | new iso file name | new ova file name ]
5. description description
6. show virtual-service-blade name name
7. interface name vlan vlanid
8. enable [primary | secondary]
9. show virtual-service-blade name name
10. copy running-config startup-config
DETAILED STEPS
|
|
|
Step 1 |
configure terminal Example: switch# configure terminal switch(config)# |
Enters the global configuration mode. |
Step 2 |
virtual-service-blade name Example: switch(config)# virtual-service-blade vsm-1 switch(config-vsb-config)# |
Creates the named virtual service blade and places you into configuration mode for that service. name : an alphanumeric string of up to 80 characters |
Step 3 |
show virtual-service-blade-type summary |
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. |
|
Example: switch(config-vsb-config)# show virtual-service-blade-type summary
-------------------------------------------------------------------------------
Virtual-Service-Blade-Type Virtual-Service-Blade
-------------------------------------------------------------------------------
switch(config-vsb-config)# |
Step 4 |
virtual-service-blade-type [ name name | new iso file name | new ova file name ] Example: switch(config-vsb-config)# virtual-service-blade-type new nexus-1000v.4.2.1.SV1.5.1.iso switch(config-vsb-config)# Example: switch(config-vsb-config)# virtual-service-blade-type new nexus-1000v.4.2.1.SV1.5.1.1010.ova switch(config-vsb-config)#
|
Specifies the type and name of the software image file to add to this virtual service blade. The keywords are as follows:
- name —The name of the existing virtual service blade type. Enter the name of an existing type found in the Step 5 command output.
- new — The name of the new ISO or OVA software image file in bootflash: repository folder.
|
Step 5 |
description description Example: switch(config-vsb-config)# description vsm hamilton storage switch(config-vsb-config)# |
(Optional) Adds a description to the virtual service blade. The description is an an alphanumeric string of up to 80 characters |
Step 6 |
show virtual-service-blade name name |
Displays the VSB that you have just created including the interface names that you configure in the next step. |
|
Example: switch(config-vsb-config)# show virtual-service-blade name vsm-1 virtual-service-blade vsm-1 Description: Slot id: 6 Host Name: Management IP: VSB Type Name : vsm-1.iso vCPU: 0 Ramsize: 0 Disksize: 0 Heartbeat: 0 -------------------------------------------------------------------------- Interface Type VLAN State Uplink-Interface Primary Secondary Oper Admin -------------------------------------------------------------------------- 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: |
Step 7 |
interface name vlan vlanid Example: switch(config-vsb-config)# interface control vlan 1044 switch(config-vsb-config)# Example: switch(config-vsb-config)# interface packet vlan 1045 switch(config-vsb-config)# |
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: “ERROR: Interface name not found in the associated virtual-service-blade type.”
Caution Do not assign a management VLAN. Unlike control and packet VLANs, the management VLAN is inherited from the Cisco Nexus Cloud Services Platform.
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 |
enable [primary | secondary] Example: switch(config-vsb-config)# enable Enter domain id[1-4095]: 1054 Enter Management IP address: 10.78.108.40 Enter Management subnet mask length 28 IPv4 address of the default gateway: 10.78.108.117 Enter Switchname: VSM-1 Enter the password for 'admin': pwd123 switch(config-vsb-config)# |
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 ID must be a different domain ID than the one you used for the Cisco Nexus Cloud Services Platform.
- Management IP address
- Management subnet mask length
- Default gateway IPV4 address
- Switch name
- Administrator password
|
Step 10 |
show virtual-service-blade name |
(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. |
|
Example: 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 switch(config-vsb-config)# switch# switch(config-vsb-config)# |
Step 11 |
copy running-config startup-config Example: 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. |
Deleting a Virtual Service Blade
You can delete a VSB, such as a VSM or NAM.
BEFORE YOU BEGIN
Before beginning this procedure, you must know or do the following:
- You are logged in to the CLI in EXEC mode.
- You know the name of the virtual service blade you are deleting.
- Shut down the VSB before it can be deleted. This procedure includes instructions for shutting down the virtual service blade.
- You can remove a VSB from both redundant Cisco Nexus Cloud Services Platforms or from only one. If one of a redundant pair of VSBs becomes unusable, you can remove it from only the Cisco Nexus Cloud Services Platform where it resides which mitigates the recovery by preserving the remaining virtual service blade in the pair. This action might may become necessary if a new instance of the service must be provisioned.
SUMMARY STEPS
1. configure terminal
2. virtual-service-blade name
3. shutdown
4. show virtual-service-blade summary
5. One of the following:
– no virtual-service-blade name
– no enable
6. show virtual-service-blade summary
7. copy running-config startup-config
DETAILED STEPS
|
|
|
Step 1 |
configure terminal Example: switch# config t switch(config)# |
Places you in the CLI Global Configuration mode. |
Step 2 |
virtual-service-blade name Example: switch(config)# virtual-service-blade vsm-5 switch(config-vsb-config)# |
Places you into the configuration mode for the named virtual service blade. |
Step 3 |
shutdown Example: switch(config-vsb-config)# shutdown switch(config-vsb-config)# |
Shuts down the VSB. |
Step 4 |
show virtual-service-blade summary |
(Optional) Displays a summary of services for verification of the shutdown. |
|
Example: 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)# |
Step 5 |
Do one of the following:
- no virtual-service-blade name
- no enable [ primary | secondary ]
Example: switch(config-vsb-config)# no virtual-service-blade vsm-5 switch(config-vsb-config)# Example: switch(config-vsb-config)# no enable switch(config-vsb-config)# |
Deletes the specified virtual service blade. The keywords are as follows:
- no virtual-service-blade —Removes the virtual service blade in its entirety from the Cisco Nexus Cloud Services Platform.
- no enable —Removes the specified virtual service blade 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 one virtual service blade in a pair (primary or secondary).
|
Step 6 |
show virtual-service-blade summary |
Displays a summary of services for verification of the removal. |
Step 7 |
copy running-config startup-config Example: switch(config)# copy running-config startup-config |
Saves the running configuration persistently through reboots and restarts by copying it to the startup configuration. |
Modifying a Virtual Service Blade
You can modify the control VLAN, packet VLAN, or the RAM size of a VSB and then make the corresponding changes to the VSM.
This section includes the following topics:
Modifying a Virtual Service Blade on the Cisco Nexus Cloud Services Platform
You can modify the control VLAN, packet VLAN, or the RAM size of a VSB.
BEFORE YOU BEGIN
Before beginning this procedure, you must know or do the following:
- Log in to the CLI in EXEC mode.
- Know the name of the virtual service blade you are modifying.
- Shut down the VSB before modifying the RAM size. This procedure includes instructions for shutting down the VSB.
- Shut down the VSB before modifying the control VLAN. This procedure includes instructions for shutting down the VSB.
Caution The VSM must be in the shut down state before you modify the control VLAN to preserve high availability when the service comes back. The control VLAN passes control messages to the standby VSM.
Caution Do not modify the management VLAN. If you change the management VLAN, the change is applied to both the Cisco Nexus Cloud Services Platform and all of the Cisco Nexus 1000V VSMs. The Cisco Nexus Cloud Services Platform and its hosted Cisco Nexus 1000V VSMs share the same management VLAN. Unlike the control and packet VLANs that are set when a VSB is created, the management VLAN is inherited.
SUMMARY STEPS
1. configure terminal
2. virtual-service-blade name
3. Do one of the following:
– If you are modifying the ram size or the control VLAN, then continue with the next step.
– Otherwise, go to Step 6.
4. shutdown
5. show virtual-service-blade summary
6. One of the following:
– ramsize size
– interface control vlan vlanid
– interface control vlan vlanid
7. no shutdown
8. show virtual-service-blade name name
9. copy running-config startup-config
DETAILED STEPS
|
|
|
Step 1 |
configure terminal Example: switch# config t switch(config)# |
Places you in the CLI Global Configuration mode. |
Step 2 |
virtual-service-blade name Example: switch(config)# virtual-service-blade vsm-5 switch(config-vsb-config)# |
Places you into the configuration mode for the named VSB. |
Step 3 |
Do one of the following:
- If you are modifying the RAM size or the control VLAN, continue with the next step.
- Otherwise, go to Step 6.
|
Step 4 |
shutdown Example: switch(config-vsb-config)# shutdown switch(config-vsb-config)# |
Shuts down the VSB. |
Step 5 |
show virtual-service-blade summary |
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 vsm-1 SECONDARY STANDBY VSB POWERED ON SECONDARY switch(config-vsb-config)# |
Step 6 |
Do one of the following:
- ramsize size
- interface control vlan vlanid
- interface packet vlan vlanid
Example: switch(config-vsb-config)# ramsize 1024 switch(config-vsb-config)# Example: switch(config-vsb-config)# interface control vlan 1116 switch(config-vsb-config)# Example: switch(config-vsb-config)# interface packet vlan 1117 switch(config-vsb-config)# |
Modifies the VSB. You can modify any of the following virtual service blade parameters:
- Memory allocated for RAM (1024-4096 MB).
- Control VLAN ID
- Packet VLAN ID
|
Step 7 |
no shutdown Example: switch(config-vsb-config)# no shutdown switch(config-vsb-config)# |
Returns the VSB status to powered on. |
Step 8 |
show virtual-service-blade name name |
Displays the VSB information for verification of the changes. |
|
Example: 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 switch(config-vsb-config)# |
Step 9 |
copy running-config startup-config Example: switch(config)# copy running-config startup-config |
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 “Modifying a VSM on the Cisco Nexus 1000V” section. |
Modifying a VSM on the Cisco Nexus 1000V
You can modify the control VLAN ID, packet VLAN ID, or RAM size in the VSM configuration on the Cisco Nexus 1000V.
BEFORE YOU BEGIN
Before beginning this procedure, you must know or do the following:
- Log in to the CLI in EXEC mode.
- Know the name of the VSM you are modifying.
- You change the configuration first in the Cisco Nexus Cloud Services Platform VSB and then in the Cisco Nexus 1000V VSM configuration. This procedure changes the Cisco Nexus 1000V VSM configuration. To change the Cisco Nexus Cloud Services Platform virtual service blade configuration, see the “Modifying a Virtual Service Blade on the Cisco Nexus Cloud Services Platform” section.
Caution Do not modify the management VLAN. If you change the management VLAN, the change is applied to both the Cisco Nexus Cloud Services Platform and all of the Cisco Nexus 1000V VSMs. The Cisco Nexus 1010 and its hosted Cisco Nexus 1000V VSMs share the same management VLAN. Unlike the control and packet VLANs which are set when a virtual service blade is created, the management VLAN is inherited.
SUMMARY STEPS
1. login virtual-service-blade vb6
2. login
3. password
4. show svs domain
5. config t
6. svs-domain
7. control vlan vlanid
8. packet vlan vlanid
9. show svs domain
10. copy running-config startup-config
11. Ctrl \
12. close
DETAILED STEPS
|
|
|
Step 1 |
login virtual-service-blade vb6 |
Logs you into the Cisco Nexus 1000V CLI for the VSM that you are modifying. |
Step 2 |
Enter your username |
Authenticates your user ID. |
Step 3 |
Enter your password |
Authenticates your password. |
|
Example: 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: |
Step 4 |
show svs domain n1000v# show svs domain
L3 control interface: NA Status: Config push to VC successful.
n1000v# |
Displays the domain configuration for the VSM. |
Step 5 |
config t Example: n1000v# config t n1000v(config)# |
Places you in the CLI Global Configuration mode. |
Step 6 |
svs-domain Example: n1000v(config)# svs domain n1000v(config-svs-domain)# |
Places you into SVS Domain Configuration mode. |
Step 7 |
control vlan vlanid Example: n1000v(config-svs-domain)# control vlan 1116 n1000v(config-svs-domain)# |
Modifies the VLAN ID of the VSM domain control VLAN. |
Step 8 |
packet vlan vlanid Example: n1000v(config-svs-domain)# packet vlan 1117 n1000v(config-svs-domain)# |
Modifies the VLAN ID of the VSM domain packet VLAN. |
Step 9 |
show svs domain Example: n1000v(config-svs-domain)# show svs domain
L2/L3 Aipc interface: mgmt0
Status: Config push to VC successful.
n1000v(config-svs-domain)# |
(Optional) Displays the domain configuration for verification of the changes. |
Step 10 |
copy running-config startup-config Example: n1000v(config-svs-domain)# copy running-config startup-config n1000v(config-svs-domain)# |
Saves the running configuration persistently through reboots and restarts by copying it to the startup configuration. |
Step 11 |
Press the Ctrl key and \ key Example: n1000v(config-svs-domain)# Ctrl \ Telnet> |
Exits from the SVS domain configuration mode and returns you to a Telnet prompt. |
Step 12 |
close Example: Telnet> close switch# |
Closes the Telnet session and returns you to EXEC mode on the Cisco Nexus Cloud Services Platform. |
You have completed this procedure. |
Defining Form Factors for a Cisco Virtual Security Gateway VSB
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:
Cisco Nexus Cloud Services Platform
|
|
|
|
Cisco Nexus 1010 |
Memory |
2 GB |
2GB |
Number of virtual CPUs |
1 |
2 |
Cisco Nexus 1110 |
Memory |
2 GB |
2 GB |
Number of virtual CPUs |
1 |
2 |
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 the Creating a Virtual Service Blade.
BEFORE YOU BEGIN
Before beginning this procedure, you must know or do the following:
- Log in to the CLI in EXEC mode.
- Know the name of the virtual service blade you have created. If you want to create a new VSB, see Creating a Virtual Service Blade.
SUMMARY STEPS
1. configure terminal
2. virtual-service-blade name
3. (optional) shutdown (for modifying a running VSG)
4. description (optional)
5. numcpu number
6. show virtual-service-blade name
7. no shutdown ( optional - only if the VSG was shutdown per step 3)
8. end
DETAILED STEPS
|
|
|
Step 1 |
config terminal Example: switch# configure terminal switch(config)# |
Places you in the CLI Global Configuration mode. |
Step 2 |
config virtual-service-blade name Example: switch(config)# virtual-service-blade vy252 switch(config-vsb-config)# |
Places you into the configuration mode for the named virtual service blade. |
Step 3 |
shutdown Example: shutdown vy252 |
(Optional) Shuts down a running VSG requiring modification. |
Step 4 |
description description Example: switch(config-vsb-config)# description VSG_vy_252 switch(config-vsb-config)# |
(Optional) Adds a description to the virtual service blade. The description argument is an alphanumeric string of up to 80 characters. |
Step 5 |
numcpu number Example: switch(config-vsb-config)#numcpu 2 switch(config-vsb-config)# |
Configures the VSB as a medium or large model based on the number of virtual CPUs attached to the VSB. number numeric value 1 or 2 |
Step 6 |
show virtual-service-blade name Example: switch(config-vsb-config)#name vy252 |
Displays the VSB information for verification of the changes. |
Step 7 |
(Optional- Use if you have shutdown a running VSG per step 3)no shutdown Example: switch(config-vsb-config)# no shutdown switch(config-vsb-config)# |
Returns the VSB status to powered on. |
|
Example: 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 Gi3 Gi3 VsbEthernet2/2 management 21 up up Gi3 Gi3 VsbEthernet2/3 ha 21 up up Gi3 Gi3 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 |
Step 8 |
copy running-config startup-config Example: switch(config)# copy running-config startup-config |
Saves the running configuration persistently through reboots and restarts by copying it to the startup configuration. |
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 feature enables the VSB to assign a virtual interface to a dedicated uplink. This uplink can be a Gigabit Ethernet port on the Cisco Nexus Cloud Services Platform or a port channel.
A passthrough VSB interface has the following features and limitations:
- Cisco Nexus Cloud Services Platform supports passthrough only on a flexible topology.
- The Passthrough feature is currently available for the VXLAN Gateway 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 Passthrough 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 Interface
You can configure a VSB interface in the passthrough mode:
BEFORE YOU BEGIN
Before beginning this procedure, you must know or do the following:
- Log in to the CLI in EXEC mode.
- Know the name of the VSB you have created. If you want to create a new VSB, see Creating a Virtual Service Blade.
- No VLAN IDs are required to be assigned to an interface before you configure it in the passthrough mode. Previously assigned VLANs are ignored while setting up an interface in the passthrough mode.
SUMMARY STEPS
1. configure terminal
2. virtual-service-blade name
3. virtual-service-blade-type [ name name | new iso file name | new ova file name
4. interface name uplink name
5. interface name mode passthrough
6. enable
7. show network summary
8. copy running-config startup-config
DETAILED STEPS
|
|
|
Step 1 |
configure terminal Example: switch# configure terminal switch(config)# |
Places you in the CLI Global Configuration mode. |
Step 2 |
virtual-service-blade name Example: switch(config)# virtual-service-blade vxgw switch(config-vsb-config)# |
Creates the named VSB and places you into the configuration mode for that service. The name argument is an alphanumeric string of up to 80 characters. |
Step 3 |
virtual-service-blade-type [ name name | new iso file name | new ova file name ] Example: switch(config-vsb-config)# virtual-service-blade-type new vxgw.4.2.1.SV2.1.1 iso Note: please be patient.. switch(config-vsb-config) |
Specifies the type and name of the software image file to add to this virtual service blade. •name—The name of the existing virtual service blade type. •new—The name of the new ISO or OVA software image file in bootflash repository folder. |
Step 4 |
interface name uplink name Example: 1 switch(config-vsb-config)# [no] interface vxgw_intf_1 uplink1 uplink GigabitEthernet2 switch(config-vsb-config)# Example:2 switch(config-vsb-config)# interface vxgw_intf_2 uplink2 uplink GigabitEthernet3 switch(config-vsb-config) |
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 GigabitEhternet or Portchannel. |
Step 5 |
interface name mode passthrough Example: switch(config-vsb-config)# interface vxgw_intf_1 uplink1 mode passthrough vxgw_intf_2 uplink2 mode passthrough switch(config-vsb-config)# |
Sets up the interface in passthrough mode on the VSB. |
Step 6 |
enable Example: switch(config-vsb-config)#enable Enter vsb image: [vxgw.4.2.1.SV2.1.1 iso] Enter domain id[1-4095]: 4 Management IP version [V4/V6]:[V4] Enter primary IP address: 10.105.234.50 Enter primary subnet mask: 255.255.255.224 IPv4 address of the default gateway: 10.105.234.33 Enter Hostname: vxgw Enter the password for 'admin': pwd123 VSM L3 Ctrl IPv4 address: 10.105.234.53 VSM Primary MAC Address: 00:02:3d:78:c4:0c Enter VSM uplink port-profile name: UPLINK-VXGW Enter Encapsulation port-profile name: vxlangw-tvlan1495 Note: VSB installation is in progress, please use show virtual-service-blade commands to check the installation status. switch(config-vsb-config)# |
Initiates the configuration of the VSB and then enables it. |
Step 7 |
show network summary |
Displays a summary of all VSBs including the ones configured in the passthrough mode. The passthrough legend (P) is added to the uplink interfaces for the interfaces that are configured in passthrough mode. |
|
Example: switch# show network summary Legends: P - Passthrough ---------------------------------------------------------------------------------------- Port State Uplink-Interface Speed RefCnt MTU Nat-Vlan Oper Admin Oper Admin Oper Admin ----------------------------------------------------------------------------------------- Gi1 up up 1000 3 9000 Gi2 up up 1000 1 9000 Gi3 up up 1000 1 9000 Gi4 up up 1000 9000 Gi5 up up 1000 9000 Gi6 up up 1000 9000 VsbEth1/1 up up Gi2(P) Gi2(P) 1000 9000 VsbEth1/2 up up Gi1 Gi1 1000 9000 VsbEth1/3 up up Gi3(P) Gi3(P) 1000 9000 control0 up up Gi1 Gi1 1000 9000 mgmt0 up up Gi1 Gi1 1000 9000 switch(config-vsb-config)# -------------------------------------------------------------------------------------- |
Step 8 |
copy running-config startup-config Example: 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. |
Verifying the Virtual Service Blade Configuration
To verify the virtual service blade configuration, use the following commands:
|
|
show virtual-service-blade [name name ] |
Displays the configuration for a specific VSB. See Example 4-3 on page 4-26 and Example 4-4 on page 4-27 . |
show virtual-service-blade summary |
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 . |
show virtual-service-blade-type summary |
Displays a summary of all VSB configurations by type, such as VSM or NAM. See Example 4-1 on page 4-26 . |
show virtual-service-blade [name name] statistics |
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 . |
show network-uplink type |
Displays the uplink configuration for verification. See Example 4-2 on page 4-26 . |
show network summary |
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
-------------------------------------------------------------------------------
Virtual-Service-Blade-Type Virtual-Service-Blade
-------------------------------------------------------------------------------
Example 4-2 Network Uplink Type
switch# show network uplink type
Administrative topology id: 2
Operational topology id: 1
Example 4-3 Virtual Service Blade Name
switch#virtual-service-blade vsm-1
Management IP: 172.23.181.37
----------------------------------------------------------------------------------------------
Interface Type VLAN State Uplink-Interface
Primary Secondary Oper Admin
------------------------------------------------------------------------------------------------
VsbEthernet1/1 control 423 up up Po1 Po1
VsbEthernet1/2 management 2 31 up up Po1 Po1
VsbEthernet1/3 packet 423 up up Po1 Po1
SW version: 4.2(1)SV1(4a)
SW version: 4.2(1)SV1(4a)
Example 4-4 Virtual Service Blade Name
switch# show virtual-service-blade vxgw
Management IP: 172.23.180.42
VSB Type Name : vx-gw-1.2
Operational Ramsize: 2048
--------------------------------------------------------------------------
Interface Type MAC VLAN State Uplink-Int
--------------------------------------------------------------------------
VsbEthernet3/1 gw-uplink1 0002.3d7b.e909 up up Gi2(P) Gi2(P)
VsbEthernet3/2 management 0002.3d7b.e908 180 up up Gi1 Gi1
VsbEthernet3/3 gw-uplink2 0002.3d7b.e90a up up Gi3(P) Gi3(P)
Example 4-5 Virtual Service Blade Summary
switch# 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
Example 4-6 Virtual Service Blade Statistics
switch# show virtual-service-blade name VSM statistics
virtual-service-blade: VSM
CPU Usage Percentage: 4.0
Up Since: Mon Sep 10 16:05:21 2012
Last heartbeat received at: Thu Sep 13 09:11:17 2012
Example 4-7 Network Summary
switch# show network summary
switch(config-vsb-config)# show network summary
------------------------------------------------------------------------------
Port State Uplink-Interface Speed RefCnt MTU Nat-Vlan
Oper Admin Oper Admin Oper Admin
------------------------------------------------------------------------------
VsbEth1/1 up up Po1 Po1 1000 9000
VsbEth1/3 up up Gi3(P) Gi3(P) 1000 9000
VsbEth1/4 up up Gi5(P) Gi5(P) 1000 9000
VsbEth1/5 up up Po1 Po1 1000 9000
VsbEth1/6 up up Po1 Po1 1000 9000
VsbEth1/7 up up Po1 Po1 1000 9000
control0 up up Po1 Po1 1000 9000
mgmt0 up up Po1 Po1 1000 9000