EVPN VXLAN Single-Gateway Centralized Routing

In a traditional EVPN VXLAN centralized anycast gateway deployment, multiple Layer 3 VXLAN Tunnel Endpoints (VTEPs) serve the role of the centralized anycast gateway. For the hosts to have a consistent ARP binding for any of the individual centralized gateway VTEPs, each VTEP operating as a centralized gateway is configured with a virtual router MAC (VARP MAC). All of the L3 VTEPs operating as centralized gatewaysshare a virtual VTEP IP (VARP VTEP IP). Each centralized gateway VTEP also advertises an EVPN type-3 route for both of theprimary VTEP IP and VARP VTEP IP, so the IPs end up in the overlay floodset.

The traditional configuration works fine, but in the specific case of a network with only a single L3 VTEP centralized gateway or single MLAG pair operating as the L3 VTEP centralized gateway, this leads to unnecessary BUM traffic. When both the physical VTEP IP and the VARP IP end up in the overlay floodset, BUM traffic duplicates to the centralized gateway, which can create overhead workloads with a lot of broadcast or multicast traffic. Because only a single centralized gateway exists, it is not necessary to have a VARP VTEP IP to provide a stable ARP binding for the gateway.

The EVPN VXLAN Single-Gateway Centralized Routing feature enables a single L3 VTEP or single MLAG pair operating as an anycast gateway and does not require a VARP VTEP IP. And eliminates the duplicate BUM traffic caused by the VARP VTEP IP in the overlay floodset. It accomplishes this with two changes:
  • A change to the default ARP behavior when a host sends ARPs for the MAC address associated with a virtual IP address (SVI IP).

    Previously, sending ARPs for a virtual IP returned different MAC address bindings, depending on whether or not a VARP VTEP IP was configured. If a VARP VTEP IP was configured, the ARP request returned the configured VARP MAC. If one was not, the ARP request returns the switch router MAC. This feature changes the behavior to always respond with the configured VARP MAC to an ARP request for a virtual IP. This closes an exception to the rule that virtual IPs are always associated with the VARP MAC.

  • A new EVPN MAC VRF configuration command that generates an EVPN type-2 route for the VARP MAC with a nexthop of the physical VTEP IP.

In a traditional EVPN centralized anycast gateway development, the presence of a configured VARP VTEP IP advertises an EVPN type-2 route for the VARP MAC with a nexthop of the VARP VTEP IP. This allows TOR switches to learn the ARP binding of the centralized anycast gateway as the default gateway. With this feature, you do not have to configure a VARP VTEP IP and requires an alternative method to advertise the appropriate EVPN route. This feature adds a new EVPN MAC VRF configuration command, redistribute router-mac next-hop vtep primary,which when configured on a MAC VRF, advertises an EVPN type-2 route for the VARP MAC with a nexthop of the primary VTEP IP. This allows TOR switches to learn the ARP binding of the centralized anycast gateway.