Cisco vPath and vServices Reference Guide for VMware vSphere
Troubleshooting vPath and vServices
Downloads: This chapterpdf (PDF - 222.0KB) The complete bookPDF (PDF - 1.62MB) | Feedback

Troubleshooting vPath and vServices

Table Of Contents

Troubleshooting vPath and vServices

Using vPath Ping to Determine Connectivity

Troubleshooting the vService and VEM Interactions When the Cisco VSG is on a VXLAN in a Service-Chain

Debugging the Traffic Flow Via a Service Chain

Troubleshooting the Service Chain by Excluding the Cisco VSG Node

VEM/vpath Configured Correctly on a VEthernet Interface for a ServiceChain

Cisco VSG on a VXLAN is not working


Troubleshooting vPath and vServices


This chapter includes the following sections:

Using vPath Ping to Determine Connectivity

Troubleshooting the vService and VEM Interactions When the Cisco VSG is on a VXLAN in a Service-Chain

See the Cisco Virtual Security Gateway for VMware vSphere Troubleshooting Guide, Release 4.2(1)VSG2(1.1) for more information on troubleshooting VSG.

Using vPath Ping to Determine Connectivity

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)

Troubleshooting the vService and VEM Interactions When the Cisco VSG is on a VXLAN in a Service-Chain

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

Debugging the Traffic Flow Via a Service Chain

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
 
   

Troubleshooting the Service Chain by Excluding the Cisco VSG Node

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.

VEM/vpath Configured Correctly on a VEthernet Interface for a ServiceChain

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 LTLone 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

Cisco VSG on a VXLAN is not working

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