You can use the NSX Command Line Interface (CLI) to do some L2 VPN troubleshooting.
L2 VPN is not working as expected.
- Use the following central CLI command to see configuration issues:
show edge <edgeID> configuration l2vpn.
For example, show edge edge-1 configuration l2vpn.
- Use the following commands on both the client and server edge:
show configuration l2vpn - Check the four following key values to verify the server.
show service l2vpn bridge - The number of interfaces depends on the number of L2 VPN clients. In below output, a single L2 VPN client (na1) is configured. Port1 refers to vNic_2. The MAC address of 02:50:56:56:44:52 has been learned on the vNic_2 interface, and is not local to the edge ( L2 VPN server). Row 3 in the following example refers to na1 interface.
show service l2vpn trunk table
show service l2vpn conversion table - In the following example, an Ethernet frame which arrives on tunnel #1 will have its VLAN ID #1 converted to VXLAN with a VLAN # of 5001 before the packet is passed to the VDS.
show process monitor - Identify if the process l2vpn (server) and naclientd (client) is running.
show service network-connections - Identify if the l2vpn (server) and naclientd (client) process is listening on port 443.
show service monitor [service] - Details of monitor backed by monitor service daemon; whether the daemon is running, and the details of monitor instance scheduled.
show service loadbalancer pool/virtual - If health monitor is provided by built-in health check, the output displays last state change time and failure reason when health check fails. If health monitor is provided by monitor service, beside the above two outputs, last check time is also displayed.
show service load balancer monitor - The last column of the output of this command is the health status of the pool member. Following status are displayed:
Table 1. Health status with description
Check passed on layer 4, no upper layers testing enabled
Layer 1-4 timeout
Layer 1-4 connection problem. For example, "Connection refused" (tcp rst) or "No route to host" (icmp)
Check passed on layer 6
Layer 6 (SSL) timeout
Layer 6 invalid response - protocol error. May caused as the:
Backend server only supports “SSLv3” or “TLSv1.0”, or
Certificate of the backend server is invalid, or
The cipher negotiation failed, and so on
Check passed on layer 7
Check conditionally passed on layer 7. For example, 404 with disable-on-404
Layer 7 (HTTP/SMTP) timeout
Layer 7 invalid response - protocol error
Layer 7 response error. For example, HTTP 5xx
When the error code is L4TOUT/L4CON, it is usually connectivity issues on the underlying networking. Duplicate IP often happens as root cause with such reason in customer’s environments. When this error happens, troubleshoot as follows:
- Check the High Availability (HA) status of edges, when HA is enabled by using the show service highavailability command on both the edges. Check if the HA link is DOWN and all the edges are Active, so there are no duplicate edge IP on the network.
- Check edge ARP table by show arp command, and verify if the backend server’s ARP entry is changed between the two MAC addresses.
- Check backend server ARP table or use the arp-ping command and check whether any other machine has the same IP similar to the edge IP.