ARP Issues in EVPN Centralized Routing Design

TL&DR: SIP of Networking Was an Understatement 🤦‍♂️

Adding IRB to a EVPN MAC-VRFs (the fancy way of saying stretched VLANs) seems like a no-brainer:

  • Add IP addresses to VLAN interfaces
  • Optionally add a shared anycast gateway
  • Declare “Mission Accomplished” (and try to ignore the inevitable phone call at 2 AM on a Sunday night)

Making that work in a multi-vendor environment is even more fun1, as I sadly discovered when creating the EVPN lab exercises or trying to figure out why some EVPN implementations were failing netlab EVPN integration tests.

Trying to explain those issues from scratch in an already convoluted asymmetric IRB environment would probably just confuse you, so I decided to start with a simpler scenario: central routing on a single spine switch.

Packet forwarding in centralized routing design

Packet forwarding in centralized routing design

Here are our assumptions:

  • L1, L2, and Spine are running EVPN and advertising type-2 (MAC-IP) and type-3 (ingress replication) routes.
  • L1 and L2 are acting as bridges2, and have a single EVPN MAC-VRF.
  • The Spine has two EVPN MAC-VRF instances and an IP address configured in each MAC-VRF instance. We’ll call those IP addresses SIPB and SIPR for obvious reasons. The underlying MAC addresses are SMACB and SMACR.
  • HB1 and HR1 have static routes using the adjacent Spine IP address as the next hop.

Anyone claiming to know a bit about IP routing should be able to recite3 what happens when HB1 tries to send the first packet to HR1:

  1. HB1 does a routing table lookup and finds SIPB as the next hop.
  2. HB1 sends a broadcast ARP request for SIPB
  3. SIPB replies with a unicast ARP reply sent from SMACB
  4. HB1 sends the packet for HR1 to Spine using SMACB as the destination MAC address
  5. Spine does a routing table lookup and realizes the red VLAN is directly connected.
  6. Spine sends a broadcast ARP request for HR1 from SMACR.
  7. HR1 replies with a unicast ARP reply sent to the SMACR.
  8. Spine can now forward the packet received from HB1 to HR1 using the MAC address of HR1.

Sounds trivial, right? What could possibly go wrong? Where do I start, and how much time do you have?

The easy bit first: several EVPN implementations do not advertise their VLAN IP/MAC addresses without some serious arm twisting nerd knobbing. When HB1 sends an Ethernet packet to SMACB, L1 has no idea where SMACB is (because the Spine switch never advertised the MAC-IP route for SMACB/SIPB), so all inter-subnet traffic is flooded (more details).

Not too bad in our scenario with three switches, but a major disaster in a large-scale fabric with dozens of switches in the same VLAN (oops, MAC-VRF instance).

Lesson#1: The spine switch MUST advertise its VLAN MAC/IP address as an EVPN MAC-IP route.

Even worse, some EVPN implementations do not process ARP requests received over VXLAN (because the vendor believes someone else should handle them), making it impossible to make centralized routing work without yet another nerd knob: ARP proxy.

These implementations expect the ingress layer-2 switches to respond to ARP requests on behalf of routers behind them based on the information received in the MAC-IP routes. More nerd knobs to twist on the layer-2 switches (L1/L2)

Lesson#2: Sometimes you have to enable ARP proxy on the layer-2 EVPN switches to cope with routers not listening to ARP-over-VXLAN.

Please note that ARP proxy (responding to ARP requests on behalf of someone else in the same subnet) is not the same as proxy ARP (responding to ARP requests for IP addresses outside of the subnet on which the ARP request was received).

Yeah, sometimes we get the terminology just right 🤦‍♂️

But wait, that’s not all. Some implementations refuse to send ARP requests over VXLAN. In our case, Spine would never send an ARP request for HR1, dropping all packets from HB1 to HR1.

These implementations expect the EVPN layer-2 switches (L1 and L2) to snoop for packets that might reveal MAC-to-IP mappings (ARP, ND, DHCP, sometimes even regular IP traffic) and advertise that information as a type-2 (MAC-IP) EVPN route. The central router would then use that information to build its ARP cache, eliminating the need for ARP requests.

Lesson#3: If your EVPN implementation refuses to send ARP requests over VXLAN, configure ARP snooping (or however it’s called) on layer-2 switches.

Figuring out how to make ARP snooping work with silent hosts is left as an exercise for the reader. If needed, ask your vendor technical contacts about that minor detail and watch them squirm.

Sometimes, an EVPN implementation might use the defaults that make things just work in a single-vendor environment. If you’re unlucky, your vendor believes in the magic powers of type-5 routes and expects everyone to do symmetric IRB (we’ll talk about that some other time). With a bit of luck and arcane knowledge of nerd knobs, you might get some of these implementations to work. If you’re truly unlucky, you’re stuck, and you can’t even use the handheld DMTF tone generator like we could in the wonderful mismatched SIP signaling days.

Try It Out

The lab topology I used in this blog post is in the netlab-examples GitHub repository. If you want to try it out:

  • Set up your lab environment (you can use free GitHub Codespaces)
  • Change directory to EVPN/central-routing
  • Execute netlab up and explore

  1. For people with masochistic tendencies ↩︎

  2. The devices lovingly called layer-2 switches by vendor marketing departments ↩︎

  3. Before the first morning coffee ↩︎

Recent posts in the same categories

1 comments:

  1. Naveen Kumar Devaraj 12 May 2026 09:47

    Hi Ivan,

    Arista EOS supports centralized VxLAN routing, but based on my experience, I haven't seen it commonly deployed in the field. This model has been well supported on EOS since the old days (prior to EVPN) using a static HER-based control plane.

    You can see the supported Arista control planes for VxLAN in this older article: https://arista.my.site.com/AristaCommunity/s/article/summary-of-arista-vxlan-control-plane-options

    Here is the feature set description for EVPN Centralized Anycast Gateway: https://www.arista.com/en/support/toi/eos-4-23-2f/14453-evpn-centralized-anycast-gateway

    This can be somewhat nuanced to absorb. If you have any specific questions on the documentation or configuration, I'm happy to answer them.

    Some thoughts on your topology and findings:

    1. Based on your diagram, I assume the Bridges L1 and L2 are actually VTEPs since you show the VxLAN tunnel (over L3/Routed links towards the Spine) between those Bridges and the Spine. Since there is no SVI on them, let's call them Bridging VTEPs.

    2. Since L1 and L2 are VTEPs and speak BGP/EVPN, they should technically receive the Type-2 MAC+IP routes from the Spine. However, the control plane won't process or install those routes since there is no SVI. Without an SVI, it can't learn ARP, and by virtue of that, it ignores those routes.

    3. The Spine will generate the Type-2 MAC+IP route based on its ARP cache. However, it won't generate the Type-2 MAC-only route, which is exactly what L1 and L2 need to learn the MAC address. The reason is that the Spine never learned the MAC address over a regular Layer-2 port unlike Bridges L1 and L2; it only learned it over the tunnel interface.

    4. Regarding your point: "because the Spine switch never advertised the MAC-IP route for SMACB/SIPB, so all inter-subnet traffic is flooded" -- you might want to clarify whether the Spine didn't send the route, or if the L1/L2 Bridging VTEP simply didn't process/install it.

    5. Extending my point #3, if you want to “bend some rules” and force cross-layer interaction to make an L2 Bridging-only VTEP behave like an IRB VTEP, you can use the following command to make L1 and L2 publish MAC+IP routes over EVPN:

      router l2-vpn
    arp learning bridged

    6. Lastly, if you set up an anycast gateway using "ip virtual-router address", GARPs are sent by default every 30 seconds. This helps in scenarios where you have pure L2 Bridges (not VTEPs) sitting between the hosts and the L2/L1 Bridging-only VTEPs.

    7. On EOS, by design, dataplane MAC learning over the VxLAN tunnel is disabled by default when EVPN is enabled. However, you can enable it for specific use cases with two steps:

    7.1. Enable automatic flood-list construction for VTEPs under the VXLAN interface:

        interface Vxlan 1
          vxlan flood vtep learned data-plane

    7.2. Configure BGP to redistribute MACs learned via the data plane for the relevant MAC VRF:

        router bgp ..
      vlan ..
             redistribute learned remote

    Reference: https://www.arista.com/en/support/toi/eos-4-24-2f/14569-evpn-vxlan-support-for-wireless-aps

    -Naveen

    Replies
    1. Ivan Pepelnjak 13 May 2026 06:39

      Thanks a million. Will go through the "who advertises what" details in another blog post.

Add comment
Home
Sidebar