You can use the NSX Command Line Interface (CLI) to do some L2 VPN troubleshooting.

Procedure

  1. Use the following central CLI command to see configuration issues:

    show edge <edgeID> configuration l2vpn.

    For example, show edge edge-1 configuration l2vpn.

  2. 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

    Health Status

    Description

    UNK

    Unknown

    INI

    Initializing

    SOCKERR

    Socket error

    L4OK

    Check passed on layer 4, no upper layers testing enabled

    L4TOUT

    Layer 1-4 timeout

    L4CON

    Layer 1-4 connection problem. For example, "Connection refused" (tcp rst) or "No route to host" (icmp)

    L6OK

    Check passed on layer 6

    L6TOUT

    Layer 6 (SSL) timeout

    L6RSP

    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

    L7OK

    Check passed on layer 7

    L7OKC

    Check conditionally passed on layer 7. For example, 404 with disable-on-404

    L7TOUT

    Layer 7 (HTTP/SMTP) timeout

    L7RSP

    Layer 7 invalid response - protocol error

    L7STS

    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:

    1. 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.
    2. Check edge ARP table by show arp command, and verify if the backend server’s ARP entry is changed between the two MAC addresses.
    3. 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.