Configuring Virtual Service Nodes
This section includes the following topics:
Configuring the vService Node
BEFORE YOU BEGIN
Before begining this procedure, you must know or do the following:
- Setup the vService node.
- You have the Virtual Service (vservice) software installed and the basic installation completed.
- You must have the license required for the vservice installed on the switch. Ensure that you have enough licenses to cover the number of Virtual Ethernet Modules (VEMs) you want to protect.
SUMMARY STEPS
1. configure
2. vservice node node_name type { vsg | asa | adc | vwaas }
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 }
|
|
|
Step 1 |
configure Example: n1000v# configure n1000v(config)# |
Places you in global configuration mode. |
Step 2 |
vservice node node_name type { vsg | asa | adc | vwaas } Example: n1000v(config)# vservice node test type vsg n1000v(config-vservice-node)# |
Configures the vservice node name for the Cisco vservice. The name will be used to associate with port profile or vservice path. A node can be deleted only if it is not bound to any virtual machines or not used in any service path. type is needed only for creation of a node. Once a node is created, type is not needed. |
Step 3 |
{ ip address ip_addr | no ip address } Example: n1000v(config-vservice-node)# ip address 10.0.0.1 n1000v(config-vservice-node)# |
Configures the vservice node IP address for the Cisco vservice. Note The IP address must match the data interface (data0) IP address on the Cisco vservice. |
Step 4 |
{ adjacency {{ l2 {vlan vlan_num }| { vxlan bridge-domain bd_name }}| l3} | no adjacency } Example: n1000v(config-vservice-node)# adjacency l2 vlan 88 n1000v(config-vservice-node)# or n1000v(config-vservice-node)# adjacency l2 vxlan bridge-domain vxlan-8888 n1000v(config-vservice-node)# or n1000v(config-vservice-node)# adjacency l3 n1000v(config-vservice-node)# |
Configures the adjacency for the Cisco vservice. If the Cisco vservice is operating in the L2 mode, You must configure the VLAN or VXLAN information. If the Cisco vservice is operating in Layer 3 mode, specify Layer 3 as keyword. |
Step 5 |
{
failmode {
close |
open } |
no
failmode }
Example: n1000v(config-vservice-node)# fail-mode close n1000v(config-vservice-node)# |
The failmode default value is close. Fail mode specifies the behavior when the VEM does not have connectivity to the service node. The default fail mode for ASA 1000V and VSG is close, which means that the packets will be dropped. The default fail mode for vWAAS is open, which means that packets will be forwarded. vPath 1.0 service nodes does not support service chaining. When using a vPath 1.0 service node in a chain, the traffic to that node goes into fail mode. |
Associating a Port Profile to a Virtual Service Node
BEFORE YOU BEGIN
Before beginning this procedure, you must know or do the following:
- You have the Cisco vservice software installed and the basic installation completed.
- You must have the license required for the vservice 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. Cisco Virtual Security Gateway for VMware vSphere Configuration Guide, Release 5.2(1)VSG2(1.2).
- 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.
SUMMARY STEPS
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
|
|
|
Step 1 |
configure Example: n1000v# configure n1000v(config)# |
Places you in global configuration mode. |
Step 2 |
port-profile port-profile-name Example: n1000v(config-port-prof)# port-profile host-profile n1000v(config-port-prof)# |
Enters the port profile configuration mode for the named port profile. If the port profile does not exist, it is created using the following characteristics: port-profile-name —The port profile name can be up to 80 alphanumeric characters and must be unique for each port profile on the Cisco vservice. |
Step 3 |
org org-name Example: n1000v(config-port-prof)# org root/Tenant-A n1000v(config-port-prof)# |
Designates an organization name for the Cisco vservice port profile. |
Step 4 |
vservice node node name profile [ security-profile-name ] Example: n1000v (config-port-prof)# vservice node vsg1 profile profile-1 n1000v (config-port-prof)# |
Associate the port profile with the previously defined vservice node and the security profile name. Note If you do not pick a security profile name, the default name is used. The security profile name must match the security profile created on the Cisco PNSC. |
Step 5 |
copy running-config startup-config Example: n1000v(config-port-prof)# copy running-config startup-config n1000v(config-port-prof)# |
(Optional) Saves configuration changes. |
Step 6 |
exit Example: n1000v(config-port-prof)# exit n1000v(config)# |
Exits the configuration mode and returns you to the global configuration mode. |
Note The Cisco VSG in Layer 2 mode can exist on a VXLAN.
vService Specific Configurations
This topic includes the following topics:
Configuring vmknics for the Layer 3 Mode vservice Encapsulation
You can configure vmknics for a Cisco vservice in the Layer 3 mode encapsulation.
Note Currently only VSG supports L3 mode.
BEFORE YOU BEGIN
Before beginning this procedure, you must know or do the following:
- Identify a VLAN to be used for transporting the Cisco vservice 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 vservice in Layer 3 mode can be configured.
SUMMARY STEPS
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
DETAILED STEPS
|
|
|
Step 1 |
configure Example: switch# configure switch(config)# |
Enters global configuration mode. |
Step 2 |
port-profile profilename Example: switch(config)# port-profile vmknic-pp switch(config-port-prof) |
Enters port profile configuration mode for the named port profile. If the port profile does not already exist, it is created using the following characteristics: The port profile name can be up to 80 characters and must be unique for each port profile on the Cisco Nexus 1000V. Note If a port profile is configured as an Ethernet type, it cannot be used to configure VMware virtual ports. |
Step 3 |
vmware port-group name Example: switch(config-port-prof)# vmware port-group switch(config-port-prof)# |
Designates the port profile as a VMware port group. The port profile is mapped to a VMware port group of the same name unless you specify a name. When you connect the VSM to vCenter Server, the port group is distributed to the virtual switch on the vCenter Server. |
Step 4 |
switchport mode access Example: switch(config-port-prof)# switchport mode access switch(config-port-prof)# |
Designates the interfaces as switch access ports (the default). |
Step 5 |
switchport access vlan id Example: switch(config-port-prof)# switchport access vlan 100 switch(config-port-prof) |
Assigns a VLAN ID to this port profile. |
Step 6 |
capability l3-vn-service Example: switch(config-port-prof)# capability l3-vn-service switch(config-port-prof) |
Assigns the capability l3-vn-service to the port profile to ensure that the interfaces that inherit this port profile are used as sources for the Cisco vservice in Layer 3 mode encapsulated traffic. |
Step 7 |
no shutdown Example: switch(config-port-prof)# no shutdown switch(config-port-prof) |
Administratively enables all ports in the profile. |
Step 8 |
state enabled Example: switch(config-port-prof)# state enabled switch(config-port-prof) |
Sets the operational state of a port profile. |
Step 9 |
show port-profile name profilename Example: switch# show port-profile vmknic-pp |
(Optional) Displays the port profile configuration. |
Step 10 |
copy running-config startup-config Example: switch# copy running-config startup-config |
(Optional) Copies the running configuration to the startup configuration. |
Configuring TCP State-Checks for All Cisco VSGs in the vPath
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. By default, TCP state checks are disabled.
BEFORE YOU BEGIN
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 5.2(1)VSG2(1.2) and Cisco Prime Netwoek Services Controller, Release 3.2.2b Installation and Upgrade Guide
- You must have Nexus1000V Multi-Hypervisor License installed on the switch. Cisco VSG license is integrated with the Nexus1000V Multi-Hypervisor License. The Cisco N1kv VSM is available in two modes: essential and advanced. VSG functionality is available only in the advanced mode. You need to install the Nexus1000V Multi-Hypervisor License and change the VSM mode to advanced mode. When the Nexus1000V Multi-Hypervisor License is installed, the license for Cisco VSG is automatically included.
- 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.
SUMMARY STEPS
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
|
|
|
Step 1 |
configure Example: n1000v# configure n1000v(config)# |
Places you in global configuration mode. |
Step 2 |
vservice global type vsg Example: n1000v(config)# vservice global type vsg n1000v(config-vservice-global)# |
Enters vservice global configuration mode. |
Step 3 |
[no] tcp state-checks Example 1: n1000v(config-vservice-global)# tcp state-checks n1000v(config-vservice-global)# Example 2: n1000v(config-vservice-global)# no tcp state-checks n1000v(config-vservice-global)# |
Enables or disables all the three TCP state checks for Cisco VSGs in the vPath. The default behavior of the TCP checks is as follows:
- invalid-ack—Disabled by default.
- seq-past-window—Disabled by default.
- window-variation—Disabled by default.
The no form of this command reverses the above respective default state. |
Step 4 |
[no] tcp state-checks invalid-ack Example: n1000v(config-vservice-global)# tcp state-checks invalid-ack n1000v(config-vservice-global)# |
Enables the invalid-ack TCP state check on the Cisco VSG. By default, when a data packet triggers an invalid ACK, the packet is dropped by the Cisco VSG. The no form of this command disables the check. |
Step 5 |
[no] tcp state-checks seq-past-window Example: n1000v(config-vservice-global)# tcp state-checks seq-past-window n1000v(config-vservice-global)# |
Enables the seq-past-window TCP state check on the Cisco VSG. By default, when a data packet’s sequence number is greater than the right edge of the TCP receiving window, the packet is dropped by the Cisco VSG. The no form of this command disables the check. |
Step 6 |
[no] tcp state-checks window-variation Example: n1000v(config-vservice-global)# tcp state-checks window-variation n1000v(config-vservice-global)# |
Enables the window-variation TCP state check on the Cisco VSG. The no form of the command disables the check. By default, the Cisco VSG does not allow you to make the window size smaller. |
Step 7 |
exit Example: n1000v(config-vservice-global)# exit n1000v(config)# |
Exits vservice global configuration mode and returns you to the global configuration mode. |
Configuring the vPath to Bypass the Cisco VSG for Service Chain Traffic
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 Prime Network Services Controller (PNSC).
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 YOU BEGIN
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.
SUMMARY STEPS
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
|
|
|
Step 1 |
configure Example: n1000v# configure n1000v(config)# |
Places you in global configuration mode. |
Step 2 |
vservice global type vsg Example: n1000v(config)# vservice global type vsg n1000v(config-vservice-global)# |
Enters vservice global configuration mode. |
Step 3 |
[no] bypass asa-traffic Example 1: n1000v(config-vservice-global)# bypass asa-traffic Example 2: n1000v(config-vservice-global)# no bypass asa-traffic |
Configures the traffic to bypass the Cisco VSG node (example 1). By default, the no form of the command disables the feature, wherein the traffic traverses the VSG node (example 2). |
Step 4 |
exit Example: n1000v(config-vservice-global)# exit n1000v(config)# |
Exits global vservice configuration mode and returns you to global configuration mode. |
Configuring Licenses
Licenses are required for some of the virtual services such as ASA1000V. Cisco Nexus 1000V Series switch does not require any licenses for vWAAS, but vWAAS may have its own licensing requirements. See Licensing, page 1-9 for more information. You do not require license for installing Citrix NetScaler 1000V on Cisco Nexus 1000V Series switch.
Starting with Release Release 4.2(1)VSG2(1.1), Cisco VSG license is integrated with the Cisco Nexus 1000V Multi-Hypervisor License. You need to install the Nexus1000V Multi-Hypervisor License for Cisco VSG for VMware vSphere. The Cisco Nexus 1000V VSM is available in two modes: essential and advanced. VSG functionality is available only in the advanced mode. You need to install the Nexus 1000V Multi-Hypervisor License and change the VSM mode to advanced mode. When the Nexus1000V Multi-Hypervisor License is installed, the license for Cisco VSG is automatically included. To configure Cisco VSG license, use the Nexus 1000V licensing commands.
To configure and transfer ASA licenses between VEMs and transfer license from a VEM to the VSM license pool, use the following procedures:
Transferring Licenses Between VEMs
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 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 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 vservice service configured.
- When licenses are successfully transferred from one VEM to another, the virtual services become available in the virtual machines on the destination VEM.
SUMMARY STEPS
1. vservice license type asa transfer src-module mod_no dst-module mod_no
2. show license usage package_name
DETAILED STEPS
|
|
|
Step 1 |
vservice license type asa transfer src-module mod_no dst-module mod_no Example: n1000v# vservice license type asa transfer src-module 5 dst_module 6 n1000v(config)# |
Transfers the licenses from one VEM to another. mod_no—The VEM module number |
Step 2 |
show license usage package_name Example: n1000v# show license usage |
Verifies the transfer by displaying the licenses in use on each VEM. |
EXAMPLES
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 asa src-module 3 dst_module 5
n1000v(config)#
n1000v# show license usage NEXUS_ASA1000V_SERVICES_PKG
----------------------------------------
Feature Usage Info
----------------------------------------
Version : 1.0
Installed Licenses : 0
Default Eval Licenses : 512
Max Overdraft Licenses : 0
Installed Licenses in Use : 0
Overdraft Licenses in Use : 0
Default Eval Lic in Use : 0
Default Eval days left : 46
Licenses Available : 512
Shortest Expiry : 04 Oct 2014
Description : NEXUS ASA Services package
Transferring Licenses to the License Pool
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 YOU BEGIN
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 vservice service.
SUMMARY STEPS
1. vservice license type asa transfer src-module mod_no license_pool
2. show license usage package_name
DETAILED STEPS
|
|
|
Step 1 |
vservice license type asa transfer src-module mod_no license-pool Example: n1000v(config)# vservice license type vsg transfer src-module 5 license-pool |
Transfers the licenses from a VEM to the license pool. All virtual machines on the VEM can no longer use the Cisco vservice. |
Step 2 |
show license usage package_name Example: n1000v# show license usage |
Verifies the transfer by displaying the licenses in use on each VEM. |
EXAMPLES
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 asa transfer src-module 5 license-pool
n1000v# show license usage NEXUS_ASA1000V_SERVICES_PKG
----------------------------------------
Feature Usage Info
----------------------------------------
Version : 1.0
Installed Licenses : 0
Default Eval Licenses : 512
Max Overdraft Licenses : 0
Installed Licenses in Use : 0
Overdraft Licenses in Use : 0
Default Eval Lic in Use : 0
Default Eval days left : 46
Licenses Available : 512
Shortest Expiry : 04 Oct 2014
Description : NEXUS ASA Services package
Note You can use the following command to transfer a license from a service pool to a VEM machine:
vservice license type asa transfer license-pool dst-module mode_no
Verifying the Cisco vservice Configuration
To display information related to a Cisco vservice, perform one of the following tasks on the switch CLI:
Show Commands
|
|
show license usage Example: vsm# show license usage |
Displays a table with the Cisco vservice license usage information for the Cisco Nexus 1000V Series switch. |
show license usage NEXUS_ASA1000V_SERVICES_PKG Example: vsm# show license usage NEXUS_ASA1000V_SERVICES_PKG |
Displays the usage information for the license package NEXUS_ASA1000V_SERVICES_PKG. |
show vservice {statistics | brief | {detail [{{vlan vlan-num [ip ip-addr]} | module module-num}]}} Example: vsm# show vservice statistics detail vlan 1 |
Displays Virtual Service (vservice) statistics for all VEM modules. |
vPath Bypassing the Cisco VSG for Service Chain Traffic
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.
Examples
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
p - permit t - passthrough
n - not processed upper case - offloaded
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
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
vPath Ping Command for the Layer 2 Mode
To verify various connections and reachable attributes of the Cisco vservice, you can use the vPath ping command.
The vPath ping command for Layer 2 mode has the following syntax:
ping vservice {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.
Examples
This example shows how to see the vservice connections:
VSM-1# ping vservice all src-module all
ping vservice 106.1.1.1 vlan 54 from module 3 5, seq=0 timeout=1-sec
module(usec) : 3(156) 5(160)
ping vservice 110.1.1.1 vlan 54 from module 3 5, seq=0 timeout=1-sec
module(failed) : 3(vservice ARP not resolved) 5(vservice ARP not resolved)
ping vservice 106.1.1.1 vlan 54 from module 3 5, seq=1 timeout=1-sec
module(usec) : 3(230) 5(151)
ping vservice 110.1.1.1 vlan 54 from module 3 5, seq=1 timeout=1-sec
module(failed) : 3(vservice ARP not resolved) 5(vservice ARP not resolved)
ping vservice 106.1.1.1 vlan 54 from module 3 5, seq=2 timeout=1-sec
module(usec) : 3(239) 5(131)
ping vservice 110.1.1.1 vlan 54 from module 3 5, seq=2 timeout=1-sec
module(failed) : 3(vservice ARP not resolved) 5(vservice ARP not resolved)
ping vservice 106.1.1.1 vlan 54 from module 3 5, seq=3 timeout=1-sec
module(usec) : 3(248) 5(153)
ping vservice 110.1.1.1 vlan 54 from module 3 5, seq=3 timeout=1-sec
module(failed) : 3(vservice ARP not resolved) 5(vservice ARP not resolved)
ping vservice 106.1.1.1 vlan 54 from module 3 5, seq=4 timeout=1-sec
module(usec) : 3(259) 5(126)
ping vservice 110.1.1.1 vlan 54 from module 3 5, seq=4 timeout=1-sec
module(failed) : 3(vservice ARP not resolved) 5(vservice ARP not resolved)
This example shows how vservice ping options are displayed:
all All vservices associated to VMs
This example shows how vservice ping options are displayed for all source modules:
VSM-1# ping vservice all src-module ?
vpath-all All modules having VMs associated to vservices
This example shows how to set up a ping for all source modules from a specified IP address:
VSM-1# ping vservice ip 10.1.1.60 src-module all
ping vservice 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(vservice ARP not resolved)
ping vservice 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 vservice 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 vservice 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 vservice 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 vservice ip 10.1.1.60 src-module vpath-all
ping vservice 10.1.1.60 vlan 501 from module 4 5, seq=0 timeout=1-sec
module(usec) : 4(223) 5(247)
ping vservice 10.1.1.60 vlan 501 from module 4 5, seq=1 timeout=1-sec
module(usec) : 4(206) 5(167)
ping vservice 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 vservice ip 10.1.1.60 src-module all timeout 2 count 3
ping vservice 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 vservice 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 vservice 10.1.1.60 vlan 501 from module 4 5 7, seq=2 timeout=2-sec
module(usec) : 4(227) 5(184) 7(216)
vPath Ping Command for the Layer 3 Mode
Note The vPath ping command for the Layer 2 and Layer 3 mode is not supported on Cisco vWAAS.
Examples
This example shows how to see the vservice connections:
vsm# ping vservice ip 10.1.1.40 src-module vpath-all
ping vservice 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 vservice 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 vservice 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 vservice 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 vservice 10.1.1.40 vlan 0 from module 9 11 12, seq=4 timeout=1-sec
module(usec) : 9(387) 11(558) 12(597)
This example shows how vservice ping options are dispalyed for all sources modules:
vsm# ping vservice all src-module all
ping vservice 10.1.1.44 vlan 501 from module 9 10 11 12, seq=0 timeout=1-sec
module(failed) : 10(vservice ARP not resolved) 11(vservice ARP not resolved)
12(vservice ARP not resolved)
ping vservice 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(vservice ARP not resolved)
ping vservice 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 vservice 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 vservice 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 vservice 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 vservice 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 vservice 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 vservice 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 vservice 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)