On Generating EVPN MAC/IP Routes

Key Takeaways

• Arista EOS creates both MAC‑only and MAC+IP EVPN routes
• This doubles the number of entries in the EVPN BGP table
• RFC 7432 explicitly permits independent MAC‑only and MAC/IP routes
• Separate routes preserve MAC data when ARP entries expire
• Designers must account for larger BGP tables in scaling

Pulse Analysis

Enterprise Ethernet VPN (EVPN) has become the de‑facto standard for multi‑tenant data‑center fabrics, offering a unified control plane for both Layer 2 and Layer 3 services. Central to EVPN is the MAC/IP route, which binds a host's MAC address to its IP address and is distributed via BGP. In addition, a MAC‑only route can be advertised when a device learns a MAC address without an associated IP, such as in pure bridging scenarios. This dual‑type routing provides flexibility but also introduces complexity in route management.

Arista's EOS implementation follows the RFC 7432 specification by generating two distinct route types: a MAC‑only route triggered by MAC table updates and a MAC+IP route triggered by ARP or ND updates. The separation mirrors traditional networking practice where MAC and ARP tables are maintained independently. By keeping these routes separate, the system ensures that a MAC address remains reachable even if the corresponding ARP entry times out, preventing unintended traffic loss. The design is intentional, not a bug, and aligns with the standard's guidance that MAC‑only routes may coexist with MAC/IP routes.

For operators, the practical impact is a potential doubling of EVPN BGP entries, which can strain router memory and processing resources in large fabrics. Network planners should factor this growth into capacity models, monitor BGP table size, and consider route‑dampening or selective advertisement techniques. Understanding the rationale behind MAC‑only versus MAC+IP routes enables more accurate troubleshooting and optimization, ensuring that EVPN deployments remain both resilient and scalable.