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 contains 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, the Microsoft Hyper-V, and KVM hypervisors. |
Cisco Nexus Cloud Services Platform supports the following VSB types:
For information about the supported VSBs and their weighting matrix, see the Cisco Nexus Cloud Services Platform Compatibility Information.
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.
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 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 (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.
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 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 http://www.cisco.com/c/en/us/support/switches/citrix-netscaler-1000v/tsd-products-support-series-home.html.
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.
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.
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.
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.
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:
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.
When a VSM shares the control VLAN and the domain ID with a Cisco Nexus Cloud Services Platform.
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.
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.
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.
Cavium NITROX security processor cards have the following guidelines and limitations:
Cavium's NITROX security processor card is supported only as a field replacement unit (FRU) on the Cisco Nexus 1110-X.
Multiple VSBs on a single Cisco Nexus Cloud Services Platform can offload their security processing to a single security processor.
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.
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.
You can configure Secure Sockets Layer (SSL) and crypto offloading capability in a VSB.
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.
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#
Configuring Virtual Service Blades
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. |
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:
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:
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
You can delete a VSB, such as a virtual supervisor module (VSM) or Network Analysis Module (NAM).
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.
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: |
Deletes the specified VSB. The keywords are as follows:
|
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
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.
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.
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: |
Modifies the VSB. You can modify any of the following VSB parameters: |
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
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.
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. |
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
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.
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. |
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
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. |
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:
You can configure a VSB interface in passthrough mode.
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:
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. |
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: The Cisco Nexus Cloud Services Platform prompts you for the following: |
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. |
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
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#
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. |
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#
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#
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
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
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#
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 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. |