Oct 152012
 

I have received a number of emails on the need for Proxy ARP on the router interface used by a VTEP.  In a VMkernel based implementation of VXLAN the simple answer is that there is no requirement for Proxy ARP for a VTEP to send and receive VXLAN traffic.  The reason for this is that all VTEP learning is over multicast for the 5.1 release. If you do not have multicast configured, there will be no learning, and VTEPs will not be able to discover other VTEPs in non local L2 networks.

The VTEPs rely on the same TCP/IP stack as the vmkernel, but they do not require a gateway to be configured as they build the VTEP IP to Destination MAC tables (think ARP table) from the responses to multicast solicitations.  If a VTEP is on a different L2 segment from the vmkernel, the VTEP will need to have a PIM enabled router on it’s L2 segment that will route multicast but the VTEP does not need to know anything about this router. Unicast responses from remote VTEPs will get back with the routers MAC addresses which the VTEPs will use for future unicast responses. What a VTEP needs the vmkernel for, is for it’s TCP/IP stack to handle IGMP processing.

So to summarize, as a VTEP will not send out an ARP request when trying to reach a remote VTEP, there is no need for Proxy ARP to be enabled.  The one time I can think of that you would ever need Proxy ARP would be for the times when you would using overlapping subnet masks for an IP range  for your VTEP interfaces.  An example of this would be VTEP1 on 192.168.176.10/21 and VTEP2 on 192.168.178.100/24, not very likely but that would be one case where you would need ProxyARP enabled for the router handing the 192.168.176.10/21 network.