Troubleshooting the Cisco VSG in the Layer 3 Mode
This section includes the following topics:
Cisco VSG with a VN Service vmknic in Layer 3 Mode
When encapsulated traffic that is destined to a Cisco VSG is connected to a different subnet other than the vmknic subnet, the VEM does not use the VMware host routing table. Instead, the vmknic initiates an Address Resolution Protocol (ARP) for the remote Cisco VSG IP addresses.
You must configure the upstream router to respond by using the proxy ARP feature. If the proxy ARP feature is not configured on the upstream router, the ARP fails and the show vservice node brief indicates that the service node state is down.
To resolve this issue configure the proxy ARP feature on the router as follows:
sg-cat3k-L14-qa(config)# int vlan 3756
sg-cat3k-L14-qa(config-if)# ip proxy-arp
sg-cat3k-L14-qa# sh ip int vlan 3756 | inc Proxy
Local Proxy ARP is disabled
Cisco VSGs with Multiple l3-vn-service vmknics in Layer 3 Mode
The data path traffic and the ARP packets for the Cisco VSGs in Layer 3 mode can use any vmknic that is configured on the VEM host for packet forwarding to the Cisco VSG when you enter the capability l3-vn-service command.
Therefore, all vmknics that are on a VEM host must be able to reach all Cisco VSGs in Layer 3 mode.
If a router is between the vmknics and the Cisco VSGs, all vmknics must have an interface in the router network (VLAN), and all the Cisco VSGs in the Layer 3 mode must have an interface in the router network (VLAN) to ensure that each vmknic has a route to each Cisco VSG.
To resolve this issue ensure that all l3-vn-service vmknics can reach all the Cisco VSGs in the Layer 3 mode that are used by the VEM host.
Note You must enable Proxy ARP on all the interfaces of the router that is alongside the vmknics.
Traffic with Large Payloads Fails: ICMP Too Big Message Does Not Reach the Client with the Cisco VSG in Layer 3 Mode
If a router lies between the vmknic and the Cisco VSG in the Layer 3 mode, and the router receives a packet that it cannot forward due to a large packet size, the router generates an ICMP Too Big message for the vmknic. The vmknic cannot forward the ICMP Too Big message of the router to the client and the vmknic drops the message. The client never receives the ICMP Too Big message and cannot refragment the packet for successful end-to-end traffic and the end-to-end traffic fails. This problem is typically seen if the router interface to the VEM is set at a higher maximun transmission unit (MTU) than the router interface to the Cisco VSG. For example, the router interface to the VEM has an MTU of 1600 and the interface to the Cisco VSG has an MTU of 1500.
This problem can be seen as an increase in the ICMP Too Big Rcvd counter in the show vservice statistics command.
To resolve this issue, configure an oversized MTU (for example, 1600) on both of the router interfaces.
End-to-End Traffic with the Cisco VSG in Layer 3 Mode Fails
When the VEM communicates with the Cisco VSG in the Layer 3 mode, an additional header with 82 bytes is added to the original packet. The VEM does not support fragmentation in the Layer 3 mode and the ports or network elements (which carry a vPath encapsulated packet) must be configured in such a way that the vPath overhead is accommodated.
If end-to-end traffic fails with a Cisco VSG Layer 3 mode, set the uplink MTU to 1582 bytes to accommodate the additional overhead. This solution assumes that the client and server VM MTUs are at the default of 1500 bytes.
End-to-End Traffic with the Cisco VSG in Layer 3 Mode and Jumbo Frames Fails
Traffic with the Layer 3 encapsulation fails even with the uplink MTU set to 9000 bytes.
If jumbo frames are enabled in the network and the end-to-end traffic fails, make sure that the MTU of the client and server VMs are 82 bytes smaller than the uplink. For example, if the uplink MTU is 9000, set the MTU of the client and server VMs to 8918 bytes.
TCP State Checks
By default, TCP state checks are disabled in vPath for the traffic protected by the Cisco VSG. Sometimes, you might see delays in the TCP traffic. To diagnose TCP state checks related issues, you need to enable TCP state checks.
Check the following counters at the VSM in the show vservice statistics output:
vsm# show vservice statistics | grep "TCP chkfail"
TCP chkfail InvalACK 0 TCP chkfail SeqPstWnd 0
TCP chkfail WndVari 0
This example shows how to enable the TCP state checks on a VSM:
VSM(config)# vservice global type vsg
Connection Limit in the Cisco VSG
The Cisco VSG can have up to 256,000 active connections at any given point of time. If for some reason new connections slows down or connections see too many failures, you can check the Cisco VSG for any connection limits that it experiences. If the VEM-to-Cisco VSG connection is not smooth or have some issues that indicates that the Cisco VSG might have missed a few updates from vPath which results in an accumulation of large active connections in its flow table.
This example shows how to check the active connection count on the Cisco VSG:
vsg# show service-path statistics | inc "Active Connections"
Active Flows 48 Active Connections 24
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
ID Name Type IP-Address Mode State Module
2 VSG vsg 192.168.10.1 v-140 Alive 3,4
6 ASA asa 188.8.131.52 v-200 Alive 3,4
Step 3 On the VSM, check a connection’s status of action (SAct).
vsm# show vservice connection
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
Type:asa IPAddr:192.168.10.1 Fail:open Vlan:140
3 Alive 00:50:56:a6:02:a5 2
4 Alive 00:50:56:a6:02:a5 2
Type:asa IPAddr:184.108.40.206 Fail:open Vlan:200
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 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
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
adjacency l2 vxlan bridge-domain 33071
This example shows how to display the node status in a VXLAN:
vsm# show vservice node brief
ID Name Type IP-Address Mode State Module
35 VSG-vxlan-33071 vsg 220.127.116.11 vxlan Alive 3,4,5