When working with NSX you have the option to create logical switches that are bound by Transport Zones…within those Transport Zones you could have a single vSphere Cluster or a number of Clusters that may or may not span different VLANs or Subnets. For those that have created NSX Logical Switches that span multiple clusters within a Transport Zone at some stage you may need to test connectivity between the VTEPs to ensure VXLAN is working as expected so that the NSX Controllers can do their thing.

There are a couple of different ways to achieve this:

ping with ++netstack=vxlan

This command can be run from the ESXi Shell and the parameters that are required are the correct VMKernel NIC that’s being used for VXLAN traffic encapsulation and the VTEP IP of the Host you want to test in the other Cluster.


If successful you should see outputs from both ends similar to what’s shown above. If you don’t have successful communication between the hosts you will need to start troubleshooting the underlying network as the MTU of the physical transport networks might not be set to 1600 minimum end to end. You can also test data packet sizes to see where the MTU might be set and if Jumbo frames is enabled.

Note: Joseph Griffiths has a good post expanding on the test and a little more detail around VXLAN MTU sizes.

Web Client Logical Switch Monitor Ping Test:

Once logged into the Web Client, click through to Networking & Security -> Logical Switches and then double click on the Logical Switch you want to test. On the Monitor Tab you will see a summary of the Logicial Switch objects in the left window pane while in the main window you have the option to select the Test Parameters and the Start Test button. The Size of the test packet option allows you to perform a standard ping test or one for VXLAN.


Select the Source and Destination Host that span the different Clusters within the Transport Zone you want to test against:


Click on Start Test and if everything is configured as expected you will get a couple of Green Ticks and a confirmation that all packets transmitted where received.


Again, if you get a failed test you will need to investigate where in the underlying network the issue could be…however now you have a couple of options to test the connectivity and more importantly one that allows you to test without having to enable SSH on the ESXi Hosts and test straight from the Web Client.