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 includes the following sections:
•Using vPath Ping to Determine Connectivity
See the Cisco Virtual Security Gateway for VMware vSphere Troubleshooting Guide, Release 4.2(1)VSG2(1.1) for more information on troubleshooting VSG.
You can use the vpath ping command to determine the connectivity between the Cisco VSG and the VEM.
This example shows how to ping the Cisco VSG connections and if they are reachable:
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 to display VSN ping options:
VSM-1# ping vsn ?
all All VSNs associated to VMs
ip IP Address
vlan VLAN Number
vxlan VXLAN
This example shows how to display VSN ping options 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)
You can run a series of checks to ensure that interactions between the vService and VEM are seamless.
Note In the following examples, VSG is used as an example of vService.
Run the following verifications ():
•Check if the Cisco VSG is alive by using the show vservice brief command from the VSM.
This example shows how to display the Cisco VSG configuration:
vsm# show vservice brief
#License Information Type In-Use
vsg 7
asa 7
#Node Information
ID Name Type IP-Address Mode State Module
1 node_10.1.1.40_l3_fclose vsg 10.1.1.40 l3 Unreach 3,9,
3 node_10.1.1.40_501_fclose vsg 10.1.1.40 vxlan Alive 4,9,11,
5 node_10.1.1.45_502_fclose vsg 10.1.1.45 vxlan Unreach 9,
9 VASA1 asa 192.168.200.221 v-53 Alive 3,9,11,
13 VASA-vxlan-222 asa 192.168.200.222 vxlan Alive 4,9,11,
16 EL1 vsg 7.1.1.1 v-501 Unreach 4,
17 EL2 vsg 7.1.1.1 v-502 Unreach 3,
If a specific Cisco VSG is not alive (wherein `Unreach' or `??' is displayed), use the show vservice detail node_ipaddr node ip command for further analysis.
•Check if the Cisco VSG node definition has "adjacency l2 vxlan" in the output. For example:
vservice node node_10.1.1.40_501_fclose type vsg
ip address 10.1.1.40
adjacency l2 vxlan bridge-domain segment2
fail-mode close
•Check the port profile attached to the VM. It should be pointing to either the vsevice node VSG directly or to a service path that contains the corresponding Cisco VSG.
•Check the port profile attached to the Cisco VSG data interface, which should be on a bridge domain. It must not have any org/vservice configuration. For example:
port-profile type vethernet segment-5001-nofw
vmware port-group
switchport mode access
switchport access bridge-domain segment2
no shutdown
state enabled
When configured, the service-chain functionality enables traffic to flow through the Cisco VSG and the Cisco ASA 1000V clould firewall. The Cisco VSG monitors the data packets and authorizes its flow from the VM to the destination ports. The VM and Cisco ASA 1000V are always in the same broadcast domain, that is, either a VLAN or a Virtual Extensible Local Area Network (VXLAN).
To debug the traffic flow via the service chain, follow these steps:
Step 1 Make sure that the VM's default gateway is set to the ASA 1000V inside interface and is reachable.
Step 2 On the VSM, ensure that the Cisco VSG and ASA 1000V are alive, which ensures that the vPath is able to reach the service nodes.
vsm# show vservice node brief
#Node Information
ID Name Type IP-Address Mode State Module
2 VSG vsg 192.168.10.1 v-140 Alive 3,4
6 ASA asa 3.3.3.1 v-200 Alive 3,4
Step 3 On the VSM, check a connection's status of action (SAct).
vsm# show vservice connection
# Module 1
Proto SrcIP[:Port] SAct DstIP[:Port] DAct Flags Bytes
icmp 192.168.10.15 Pp 192.168.11.15 882
In the SAct value Pp, the uppercase `P' indicates the action that is initiated by the Cisco VSG, while the lowercase `p' indicates the action that is deduced based on the returning traffic from the ASA V1000. If the SAct value is `rr,' it indicates that the traffic is redirecting to either the Cisco VSG or the ASA V1000 but no response is being received.
Step 4 On the VSM, verify that the service node version information (VVer) is `2' so that it works in the service-chain.
vsm# show vservice node detail
#Node Information
#Node ID:2 Name:VSG
Type:asa IPAddr:192.168.10.1 Fail:open Vlan:140
Mod State MAC-Addr VVer
3 Alive 00:50:56:a6:02:a5 2
4 Alive 00:50:56:a6:02:a5 2
#Node ID:6 Name:ASA
Type:asa IPAddr:3.3.3.1 Fail:open Vlan:200
Mod State MAC-Addr VVer
3 Alive 00:50:56:a6:02:6d 2
4 Alive 00:50:56:a6:02:6d 2
The service-chain configuration has the Cisco VSG and ASA 1000V nodes in its service path for a given traffic flow. For debugging purposes, the Cisco VSG can be removed temporarily from the node configuration to isolate a problem. Thus, a user can verify the traffic flow with just the ASA 1000V. Later, the Cisco VSG can be added again to restore the original service-chain configuration using the two said service nodes.
You can use the module vem vem-num execute vemcmd show vsn bindings command on the VSM to ensure that the bindings are correctly configured on the VEM for a service chain. Two entries appear for a single LTL—one of each service node must be displayed.
vsm# module vem 3 execute vemcmd show vsn bindings
VSG Services Enabled | VSG Licenses Available 2
ASA Services Enabled | ASA Licenses Available 2
LTL PATH VSN SWBD IP P-TYPE P-ID
60 6 2 3756 10.10.10.202 1 49
60 6 33 3770 172.31.2.11 2 52 >> two service node bindings for LTL
60 and 62
62 6 2 3756 10.10.10.202 1 49
62 6 33 3770 172.31.2.11 2 52
The Cisco VSG node can be configured with a VXLAN in the Layer 2 mode only. Make sure that the adjacency is correctly defined as Layer 2 and the bridge-domain configuration is valid. The show service node brief command can be used to check a service node's state with respect to the vPath.
This example shows a Cisco VSG node configuration for a VXLAN:
vservice node VSG-vxlan-33071 type vsg
ip address 20.20.20.182
adjacency l2 vxlan bridge-domain 33071
fail-mode close
This example shows how to display the node status in a VXLAN:
vsm# show vservice node brief
#Node Information
ID Name Type IP-Address Mode State Module
35 VSG-vxlan-33071 vsg 20.20.20.182 vxlan Alive 3,4,5