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.

  • Pingback: Technology Short Take #26 | Strategic HRStrategic HR

  • Pingback: Technology Short Take #26 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers

  • Antoine

    Hum, interesting, but weird for a few reasons:

    1- Security : if the source mac of the router sending traffic from the other VTEP is learn to figure out the ‘next hop’ MAC, how to protect against spoofing?

    2-There is a wrong assumption here that unicast and multicast will follow the same path.

    3 – What about FHR redundancy ?

    • http://www.borgcube.com/blogs Kamau Wanguhu

      Antoine;
      1) There is no guard against spoofing built into the protocol. It becomes up to the implementer to mitigate against spoofing by using a dedicated L3 for the VTEPs. I would say approach this the same way we approach management connections.
      2) This would be the case if the L3 that the VTEP is on has multiple router exit points. In that case then yes the Unicast and Multicast packets could use different paths. If you are thinking about different paths beyond the first hop router then at that point it is not relevant as we are only concerned with final delivery and not the path taken.
      3) If by “FHR redundancy” you are referring to First Hop Redundancy Protocols like VRRP and HSRP, I do not see how they relate. The next hop MAC address should remain the same after a failover and VTEP is only concerned with the first hop MAC.

      These were awesome questions, and I appreciate you taking the time to read and ask them.