The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure the virtual service nodes and virtual network services for vPath.
This chapter includes the following sections:
•Configuring Virtual Service Nodes
•vService Specific Configurations
•Configuring the vPath to Bypass the Cisco VSG for Service Chain Traffic
•Verifying the Cisco VSN Configuration
vPath and vServices has the following configuration guidelines and limitations:
•If the jumbo frames are enabled in the network, make sure that the MTU of the client and server VMs are reduced by the vPath encapsulation size.
• If the Cisco VSN is deployed on a Vitual Extensible Local Area Network, an additional header with 50 bytes is added in front of the vPath encapsulation. Adjust the MTU by this amount.
•When the VEM communicates with the Cisco VSN in the Layer 2 mode, an additional header with 62 bytes is added to the original packet. The VEM fragments the packet if it exceeds the uplink maximum transmission unit (MTU). For better performance, increase the MTU of all links between the VEM and the Cisco VSN by 62 bytes to account for packet encapsulation, which occurs for communication between vPath and the Cisco VSN.
•When the VEM communicates with the Cisco VSN in the Layer 3 mode, an additional header with 82 bytes is added to the original packet. The VEM does not support fragmentation in Layer 3 mode and the ports/network- elements that carry the vPath encapsulated packets must be configured so that the vPath overhead is accommodated.
This section includes the following topics:
•Configuring the vService Node
•Associating a Port Profile to a Virtual Service Node
Before begining this procedure, you must know or do the following:
•Setup the vService node.
•You have the Virtual Service Node (VSN) software installed and the basic installation completed.
•You must have the license required for the VSN installed on the switch. Ensure that you have enough licenses to cover the number of Virtual Ethernet Modules (VEMs) you want to protect.
1. configure
2. vservice node node_name type {vsg | asa | ace}
3. {ip address ip_addr | no ip address}
4. {adjacency {l2 {vlan vlan_num}| {vxlan bridge-domain bd_name}}| l3} | no adjacency}
5. {{failmode {close | open} | no failmode}
DETAILED STEPS
Before beginning this procedure, you must know or do the following:
•You have the Cisco VSN software installed and the basic installation completed.
•You must have the license required for the VSN installed on the switch. Ensure that you have enough licenses to cover the number of Virtual Ethernet Modules (VEMs) you want to protect.
•You have completed creating the Cisco VSG port profiles for the service and high-availability (HA) interface. See the Cisco Virtual Security Gateway for VMware vSphere Configuration Guide, Release 4.2(1)VSG2(1.1).
•You have defined the vservice node that will be added to the service path.
•You are logged in to the switch CLI in EXEC mode.
1. configure
2. port-profile port-profile-name
3. org org-name
4. vservice node node name profile [security-profile-name]
5. (Optional) copy running-config startup-config
6. exit
DETAILED STEPS
Note The Cisco VSG in Layer 2 mode can exist on a VXLAN.
This section contains the following topics:
•Configuring the vService Path
•Associating a Port Profile with a vService Path
Before beginning this procedure, you must know or do the following:
•You have the Cisco VSN software installed and the basic installation completed.
•You must have the license required for the VSN installed on the switch. Ensure that you have enough licenses to cover the number of Virtual Ethernet Modules (VEMs) you want to protect.
•There are multiple combinations in which the service nodes in a vservice path can be deployed. Based on the combination/topology used, provision the uplink MTU correspondingly for the traffic to go across in a service chain. The uplink MTU chosen for a given combination is usually the highest of the overhead provisions that you make for each service node in that particular combination.
•You have completed creating the Cisco VSG port profiles for the service and high-availability (HA) interface. See the Cisco Virtual Security Gateway for VMware vSphere Configuration Guide, Release 4.2(1)VSG2(1.1).
•You have defined the vservice node that will be added to the service path.
•You are logged in to the switch CLI in EXEC mode.
1. configure
2. vservice path svc_path_name
3. node node_name profile profile_name order order_num
4. exit
ETAILED STEPS
Before beginning this procedure, you must know or do the following:
•You have the Cisco VSN software installed and the basic installation completed.
•You must have the license required for the VSN installed on the switch. Ensure that you have enough licenses to cover the number of Virtual Ethernet Modules (VEMs) you want to protect.
•Complete the vservice node. For details, see the Configuring the vService Node section or the Configuring vService Path section.
•You have completed creating the Cisco VSG port profiles for the service and high-availability (HA) interface. See the Cisco Virtual Security Gateway for VMware vSphere Configuration Guide, Release 4.2(1)VSG2(1.1).
•You have defined the vservice node that will be added to the service path.
•You are logged in to the switch CLI in EXEC mode.
1. configure
2. port-profile port-profile-name
3. org org-name
4. vservice path path_name
5. (Optional) copy running-config startup-config
6. exit
DETAILED STEPS
This topic includes the following topics:
•Configuring vmknics for the Layer 3 Mode VSN Encapsulation
•Configuring TCP State-Checks for All Cisco VSGs in the vPath
•Configuring the vPath to Bypass the Cisco VSG for Service Chain Traffic
You can configure vmknics for a Cisco VSN in the Layer 3 mode encapsulation.
Note Currently only VSG supports L3 mode.
Before beginning this procedure, you must know or do the following:
•Identify a VLAN to be used for transporting the Cisco VSN in the Layer 3 mode-encapsulated traffic. Ensure that the VLAN is configured on the uplink port profile for all VEMs on which the Cisco VSN in Layer 3 mode can be configured.
1. configure
2. port-profile profilename
3. vmware port-group name
4. switchport mode access
5. switchport access vlan id
6. capability l3-vn-service
7. no shutdown
8. state enabled
9. (Optional) show port-profile name profilename
10. (Optional) copy running-config startup-config
The TCP (Transmission Control Protocol) state checks performs three checks on TCP traffic that is routed through the Cisco VSG:
•invalid-ack—When the ACK (acknowledge) number of a received TCP packet is greater than the sequence number of the TCP packet to be sent next, it is an invalid ACK.
•seq-past-window—The sequence number of a received TCP packet is greater than the right edge of the TCP receiving window.
•window-variation—The window size mechanism allows TCP to advertise a large window and to subsequently advertise a much smaller window without accepting a lot of data. From the TCP specification, it is recommended not to make the window size smaller.
When one of the above checks is turned on, the data packets are dropped by the Cisco VSG if they meet the specified condition. However, you may need to disable a specific check when you do not want the information generated by that TCP state check to hide other information in which you are specifically interested.
Note This feature is supported for Cisco Nexus 1000V, Release 4.2(1)SV2(1.1) onwards.
Before beginning this procedure, you must know or do the following:
•You have the Cisco VSG software installed and the basic installation completed. For details, see the Cisco Virtual Security Gateway, Release 4.2(1)VSG2(1.1) and Cisco Virtual Network Management Center, Release 2.0 Installation and Upgrade Guide
•You must have the NEXUS_VSG_SERVICES_PKG license installed on the switch. Ensure that you have enough licenses to cover the number of VEMs that you want to protect.
•You have completed creating the Cisco VSG port profiles for the service and HA interface.
•You are logged in to the switch CLI in EXEC mode.
1. configure
2. vservice global type vsg
3. [no] tcp state-checks
4. (Optional) [no] tcp state-checks invalid-ack
5. (Optional) [no] tcp state-checks seq-past-window
6. (Optional) [no] tcp state-checks window-variation
7. exit
DETAILED STEPS
In a service chain, the traffic between the inside and outside networks traverses the Cisco ASA and VSG service nodes. However, sometimes the data packets may not require the Cisco VSG approval. In such a scenario, you can configure the vPath to bypass all Cisco VSG nodes, so that the policy lookup is performed only in the Cisco ASA nodes. This traffic optimization improves network performance, while simplifying the policy configuration on the Cisco Virtual Network Management Center (VNMC).
Note that this feature works only in a service chaining environment, wherein all traffic between inside and outside networks skip the Cisco VSG. However, non-service chaining and inside to inside traffic continues to be validated by the Cisco VSG.
Note This feature is supported for Cisco Nexus 1000V, Release 4.2(1)SV2(1.1) onwards.
Before beginning this procedure, you must know or do the following:
•You have successfully configured a service chain on the Cisco Nexus 1000V switch.
•You must bypass the Cisco VSG node in a service chain to improve network peformance.
•You are logged in to the switch CLI in EXEC mode.
1. configure
2. vservice global type vsg
3. [no] bypass asa-traffic
4. exit
Note Because this is a global configuration command, all Cisco VSG-bound traffic bypasses that node in a service chain. Currently, you cannot configure to bypass specific Cisco VSG nodes.
DETAILED STEPS
Licenses are requied for some of the virtual services such as VSG and ASA1000V. Cisco Nexus 1000V Series switch does not require any licenses for vWAAS, but vWAAS may have its own licensing requirements. See Licensing for more information.
You can use the following procedures in this section to transfer licenses between VEMs and transfer license from a VEM to the VSM license pool:
•Transferring Licenses Between VEMs
•Transferring Licenses to the License Pool
Use the following procedure to transfer licenses from one VEM to another. For example, you might transfer licenses between VEMs after moving a VM from one host to another.
Before beginning this procedure, you must know or do the following:
•You are logged in to the CLI in EXEC mode.
•You know the VEM that you want to transfer licenses from and the number of licenses it has.
•You know the VEM that you are transferring licenses to and the number of licenses required.
•You know the number of CPUs installed on the destination VEM.
•Licenses cannot be transferred to a VEM unless there are enough licenses in the pool to cover all of its CPUs.
•Licenses cannot be transferred to a VEM that does not have a VSN service configured.
•When licenses are successfully transferred from one VEM to another, the virtual machines on the source VEM can no longer use Cisco VSG services and the virtual machines on the destination VEM can now use Cisco VSG services.
1. vservice license type vsg transfer src-module mod_no dst-module mod_no
2. show license usage package_name
This example shows how to transfer a license from VEM 3 to VEM 5 and verify the transfer in the license usage:
n1000v# vservice license type vsg src-module 3 dst_module 5
n1000v(config)#
n1000v# show license usage NEXUS_VSG_SERVICES_PKG
--------------------------------------
Feature Usage Info
--------------------------------------
Installed Licenses : 10
Eval Licenses : 0
Max Overdraft Licenses : 16
Installed Licenses in Use : 4
Overdraft Licenses in Use : 0
Eval Licenses in Use : 0
Licenses Available : 22
--------------------------------------
Application
--------------------------------------
VEM 4 - Socket 1
VEM 4 - Socket 2
VEM 5 - Socket 1
VEM 5 - Socket 2
--------------------------------------
Use the following procedure to transfer licenses from a VEM to the VSM license pool. For example, you might remove a license from a VEM and transfer it to the VSM license pool.
Before beginning this procedure, you must know or do the following:
•You are logged in to the CLI in EXEC mode.
•When you transfer its licenses to the VSM license pool, all VMs on the VEM can no longer use the Cisco VSN service.
1. vservice license type vsg transfer src-module mod_no license_pool
2. show license usage package_name
This example shows how to display the licenses in use on each VEM. Notice that the licenses on VEM 3 are no longer in use.
vservice license type vsg transfer src-module 5 license-pool
n1000v# show license usage NEXUS_VSG_SERVICES_PKG
--------------------------------------
Feature Usage Info
--------------------------------------
Installed Licenses : 10
Eval Licenses : 0
Max Overdraft Licenses : 16
Installed Licenses in Use : 2
Overdraft Licenses in Use : 0
Eval Licenses in Use : 0
Licenses Available : 24
--------------------------------------
Application
--------------------------------------
VEM 4 - Socket 1
VEM 4 - Socket 2
--------------------------------------
Note You can use the following command to transfer a license from a service pool to a VEM machine:
vservice license type vsg transfer license-pool dst-module mode_no
To display information related to a Cisco VSN, perform one of the following tasks on the switch CLI:
•vPath Bypassing the Cisco VSG for Service Chain Traffic
•vPath Ping Command for the Layer 2 Mode
•vPath Ping Command for the Layer 3 Mode
In a service chain, when "bypass asa-traffic" is enabled, traffic between the inside and outside networks bypasses the Cisco VSG, whilst processing only via the Cisco ASA. To verify if the traffic is indeed bypassing the Cisco VSG nodes, use the show vservice connection command.
In the following example, the "n" against the Cisco VSG node output shows that it has "not processed" the service chain traffic between the outside and inside networks. The "n" flag is highlighted in yellow in the output. This example shows how to see the vservice connection:
VSM# show vservice connection
Actions(Act):
d - drop s - reset
p - permit t - passthrough
r - redirect e - error
n - not processed upper case - offloaded
Flags:
A - seen ack for syn/fin from src a - seen ack for syn/fin from dst
E - tcp conn established (SasA done)
F - seen fin from src f - seen fin from dst
R - seen rst from src r - seen rst from dst
S - seen syn from src s - seen syn from dst
T - tcp conn torn down (FafA done) x - IP-fragment connection
#Port-Profile:VSPATH-1-vlan-87 Path:VSPATH-1
#Module 3
Proto SrcIP[:Port] SAct DstIP[:Port] DAct Flags Bytes
icmp 192.168.193.11 np 192.168.192.1 2940
tcp 192.168.193.11:52897 np 192.168.192.1:80 T 1290
To verify various connections and reachable attributes of the Cisco VSN, you can use the vPath ping command.
The vPath ping command for Layer 2 mode has the following syntax:
ping vsn {all | {ip ip-addr [vlan vlan-num | vxlan bridge-domain bd_name]]}} src-module {all | vpath-all | module-num} [timeout secs] [count {count | unlimited}]
Note The vPath ping command for the Layer 2 and Layer 3 mode is not supported on Cisco vWAAS.
This example shows how to see the VSN connections:
VSM-1# ping vsn all src-module all
ping vsn 106.1.1.1 vlan 54 from module 3 5, seq=0 timeout=1-sec
module(usec) : 3(156) 5(160)
ping vsn 110.1.1.1 vlan 54 from module 3 5, seq=0 timeout=1-sec
module(failed) : 3(VSN ARP not resolved) 5(VSN ARP not resolved)
ping vsn 106.1.1.1 vlan 54 from module 3 5, seq=1 timeout=1-sec
module(usec) : 3(230) 5(151)
ping vsn 110.1.1.1 vlan 54 from module 3 5, seq=1 timeout=1-sec
module(failed) : 3(VSN ARP not resolved) 5(VSN ARP not resolved)
ping vsn 106.1.1.1 vlan 54 from module 3 5, seq=2 timeout=1-sec
module(usec) : 3(239) 5(131)
ping vsn 110.1.1.1 vlan 54 from module 3 5, seq=2 timeout=1-sec
module(failed) : 3(VSN ARP not resolved) 5(VSN ARP not resolved)
ping vsn 106.1.1.1 vlan 54 from module 3 5, seq=3 timeout=1-sec
module(usec) : 3(248) 5(153)
ping vsn 110.1.1.1 vlan 54 from module 3 5, seq=3 timeout=1-sec
module(failed) : 3(VSN ARP not resolved) 5(VSN ARP not resolved)
ping vsn 106.1.1.1 vlan 54 from module 3 5, seq=4 timeout=1-sec
module(usec) : 3(259) 5(126)
ping vsn 110.1.1.1 vlan 54 from module 3 5, seq=4 timeout=1-sec
module(failed) : 3(VSN ARP not resolved) 5(VSN ARP not resolved)
This example shows how VSN ping options are displayed:
VSM-1# ping vsn ?
all All VSNs associated to VMs
ip IP Address
vlan VLAN Number
vxlan VXLAN
This example shows how VSN ping options are displayed for all source modules:
VSM-1# ping vsn all src-module ?
<3-66> Module number
all All modules in VSM
vpath-all All modules having VMs associated to VSNs
This example shows how to set up a ping for all source modules from a specified IP address:
VSM-1# ping vsn ip 10.1.1.60 src-module all
ping vsn 10.1.1.60 vlan 501 from module 4 5 7, seq=0 timeout=1-sec
module(usec) : 4(301) 5(236)
module(failed) : 7(VSN ARP not resolved)
ping vsn 10.1.1.60 vlan 501 from module 4 5 7, seq=1 timeout=1-sec
module(usec) : 4(241) 5(138) 7(270)
ping vsn 10.1.1.60 vlan 501 from module 4 5 7, seq=2 timeout=1-sec
module(usec) : 4(230) 5(155) 7(256)
ping vsn 10.1.1.60 vlan 501 from module 4 5 7, seq=3 timeout=1-sec
module(usec) : 4(250) 5(154) 7(284)
ping vsn 10.1.1.60 vlan 501 from module 4 5 7, seq=4 timeout=1-sec
module(usec) : 4(231) 5(170) 7(193)
This example shows to set up a ping for all vPath source modules for a specified IP address:
VSM-1# ping vsn ip 10.1.1.60 src-module vpath-all
ping vsn 10.1.1.60 vlan 501 from module 4 5, seq=0 timeout=1-sec
module(usec) : 4(223) 5(247)
ping vsn 10.1.1.60 vlan 501 from module 4 5, seq=1 timeout=1-sec
module(usec) : 4(206) 5(167)
ping vsn 10.1.1.60 vlan 501 from module 4 5, seq=2 timeout=1-sec
module(usec) : 4(241) 5(169)
This example shows how to set up a ping for all source modules of a specified IP address with a time-out and a count:
VSM-1# ping vsn ip 10.1.1.60 src-module all timeout 2 count 3
ping vsn 10.1.1.60 vlan 501 from module 4 5 7, seq=0 timeout=2-sec
module(usec) : 4(444) 5(238) 7(394)
ping vsn 10.1.1.60 vlan 501 from module 4 5 7, seq=1 timeout=2-sec
module(usec) : 4(259) 5(154) 7(225)
ping vsn 10.1.1.60 vlan 501 from module 4 5 7, seq=2 timeout=2-sec
module(usec) : 4(227) 5(184) 7(216)
Note The vPath ping command for the Layer 2 and Layer 3 mode is not supported on Cisco vWAAS.
This example shows how to see the vsn connections:
vsm# ping vsn ip 10.1.1.40 src-module vpath-all
ping vsn 10.1.1.40 vlan 0 from module 9 11 12, seq=0 timeout=1-sec
module(usec) : 9(698) 11(701) 12(826)
ping vsn 10.1.1.40 vlan 0 from module 9 11 12, seq=1 timeout=1-sec
module(usec) : 9(461) 11(573) 12(714)
ping vsn 10.1.1.40 vlan 0 from module 9 11 12, seq=2 timeout=1-sec
module(usec) : 9(447) 11(569) 12(598)
ping vsn 10.1.1.40 vlan 0 from module 9 11 12, seq=3 timeout=1-sec
module(usec) : 9(334) 11(702) 12(559)
ping vsn 10.1.1.40 vlan 0 from module 9 11 12, seq=4 timeout=1-sec
module(usec) : 9(387) 11(558) 12(597)
vsm#
This example shows how VSN ping options are dispalyed for all sources modules:
vsm# ping vsn all src-module all
ping vsn 10.1.1.44 vlan 501 from module 9 10 11 12, seq=0 timeout=1-sec
module(usec) : 9(508)
module(failed) : 10(VSN ARP not resolved) 11(VSN ARP not resolved)
12(VSN ARP not resolved)
ping vsn 10.1.1.40 vlan 0 from module 9 10 11 12, seq=0 timeout=1-sec
module(usec) : 9(974) 11(987) 12(1007)
module(failed) : 10(VSN ARP not resolved)
ping vsn 10.1.1.44 vlan 501 from module 9 10 11 12, seq=1 timeout=1-sec
module(usec) : 9(277) 10(436) 11(270) 12(399
)
ping vsn 10.1.1.40 vlan 0 from module 9 10 11 12, seq=1 timeout=1-sec
module(usec) : 9(376) 10(606) 11(468) 12(622)
ping vsn 10.1.1.44 vlan 501 from module 9 10 11 12, seq=2 timeout=1-sec
module(usec) : 9(272) 10(389) 11(318) 12(357)
ping vsn 10.1.1.40 vlan 0 from module 9 10 11 12, seq=2 timeout=1-sec
module(usec) : 9(428) 10(632) 11(586) 12(594)
ping vsn 10.1.1.44 vlan 501 from module 9 10 11 12, seq=3 timeout=1-sec
module(usec) : 9(284) 10(426) 11(331) 12(387)
ping vsn 10.1.1.40 vlan 0 from module 9 10 11 12, seq=3 timeout=1-sec
module(usec) : 9(414) 10(663) 11(644) 12(698)
ping vsn 10.1.1.44 vlan 501 from module 9 10 11 12, seq=4 timeout=1-sec
module(usec) : 9(278) 10(479) 11(334) 12(469)
ping vsn 10.1.1.40 vlan 0 from module 9 10 11 12, seq=4 timeout=1-sec
module(usec) : 9(397) 10(613) 11(560) 12(593)
vsm#