Well I have been playing around with vxlan more than I care to admit. It’s a painful process. One key component to vxlan is an increased MTU to 1600 in order to support the encapsulation. You verify that you don’t have a MTU issue the following way:
Login to your ESXi host (I like ssh but it’s up to you).
Identify the vmknic with your MTU settings:
esxcfg-vmknic -l
You should see a list of vmknic’s and MTU settings. Then check to make sure your local switch also has the MTU setting => the nic setting
esxcfg-vswitch -l
Check for MTU of switch. If everything looks ok you can use the vmkping to send a packet. Test basic connectivity first:
vmkping IP_Address_of_local_interface
vmkping IP_address_of_remote_interface
This should return with pings unless you are using 5.5 (see below for more 5.5 stuff). If this fails you have basic connectivity issues like firewall,subnet or some other layer 2 problem. Now test for a 1600 byte packet (VMware has a 28 byte overhead that command does not take into account)
5.0 (-d is do not fragment -s is size)
vmkping -d -s 1572 IP_Address_of_local_interface
vmkping -d -s 1572 IP_address_of_remote_interface 5.1 (-I allows you to identify the vmknic to use)
vmkping -I vmknic# -d -s 1572 IP_Address_of_local_interface
vmkping -I vmknic# -d -s 1572 IP_address_of_remote_interface 5.5 (this one is different this actually shoots out a vxlan packet not a MTU 1572 packet - true test of vxlan)
vmkping ++netstack=vxlan vmknic_IP -d -s 1572
or
esxcli network diag ping --netstack=vxlan --host vmknic_IP --df --size=1572
Enjoy your testing and remember the 1572 rule.