One of the most interesting capabilities introduced by EVPN is native active-active multihoming. If you’ve spent time designing data center networks over the last decade, you’ve most likely used or at least encountered technologies like vPC, MLAG, MC-LAG, Virtual Chassis, StackWise Virtual, or other similar vendor-specific ways to dual-home servers and access switches.
These technologies solved a real problem. We wanted to connect a device to multiple switches simultaneously while still allowing all available links to forward traffic. Traditional Layer 2 protocols such as STP prevented loops, but they also left redundant links sitting idle which is a big waste of resources.
The challenge is that most MLAG implementations are proprietary. They use special peer links and synchronization mechanisms, and usually that means you’ll be locked into a particular vendor architecture.
EVPN Active-Active Multihoming (EVPN-MH) takes a different approach. Instead of relying on proprietary control planes between switches, EVPN uses BGP EVPN itself to advertise multihoming information throughout the fabric. The result is a standards-based solution that provides redundancy, load balancing, faster convergence, and better scalability for modern VXLAN fabrics.
The Problem EVPN-MH Solves
Look at the image blow of a simple VXLAN leaf-spine fabric.
HostA is connected to both Leaf1 and Leaf2. Without multihoming, we would typically have one active path and one standby path. That wastes bandwidth and introduces additional failover events.
With EVPN-MH, both leaf switches actively forward traffic. The server sees a single logical connection while the fabric sees two independent VTEPs participating in the same Ethernet Segment.
The key concept here is the Ethernet Segment Identifier (ESI), which is a 10-byte value that uniquely identifies a multihomed segment. Both Leaf1 and Leaf2 advertise the same ESI, telling the rest of the fabric that they’re attached to the same downstream device.
How EVPN Multihoming Works
When EVPN-MH is enabled, several EVPN route types begin working together. If you’ve read my recent blog post covering the five EVPN route types, this is where Route Types 1 and 4 become very important.
Route Type 4: Ethernet Segment Route
The first thing the participating leaf switches advertise is a Type 4 Ethernet Segment Route. The purpose of the Type 4 route is to advertise ownership of an ESI and participate in Designated Forwarder (DF) election procedures.
For example, in the image below we can see
- Leaf1 advertises a Type 4 Route with ESI 0000:0000:0000:0001
- Leaf2 advertises a Type 4 Route with ESI 0000:0000:0000:0001
Both leaf switches advertise the same ESI, and now remote VTEPs understand that both leaf switches participate in the same Ethernet Segment. This is important for handling BUM traffic (Broadcast, Unknown Unicast, and Multicast) and avoiding loops within the VXLAN fabric. And in this configuration, only the elected Designated Forwarder handles certain forwarding responsibilities.
In the output of show bgp evpn route-type ethernet-segment, we can see that both leaf switches are advertising the same ESI (0000:0000:0000:0000:0010):
leaf1#show bgp evpn route-type ethernet-segmentBGP routing table information for VRF defaultRouter identifier 10.0.0.11, local AS number 65101Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selectionOrigin codes: i - IGP, e - EGP, ? - incompleteAS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 10.0.0.11:1 ethernet-segment 0000:0000:0000:0000:0010 10.0.0.11 - - - 0 i * > RD: 10.0.0.12:1 ethernet-segment 0000:0000:0000:0000:0010 10.0.0.12 10.0.0.12 - 100 0 65000 65102 i
Route Type 1: Ethernet Auto-Discovery Route
Route Type 1 performs several important functions in EVPN-MH which help it scale far better than traditional MLAG designs. EVPN-MH provides:
- Aliasing
- Mass withdrawal
- Split-horizon support
- Fast convergence
Aliasing
For me, aliasing is one of the features that really made EVPN-MH click.
In EVPN-MH, both Leaf1 and Leaf2 advertise Type 1 Ethernet A-D per-EVI routes for the shared ESI. If Leaf1 advertises the host MAC with a Type 2 route, the remote VTEP sees that the MAC belongs to a multihomed Ethernet Segment. It can then use the Type 1 routes to resolve that ESI to both Leaf1 and Leaf2, allowing traffic to be load-balanced across both leaf switches even though only one leaf originated the MAC route.Imagine a host attached to a dual-homed server.
In the image below, we can see that the Type 1 per-EVI advertisements come from both Leaf1 and Leaf2. This tells remote VTEPs that they each have reachability to that specific Ethernet Segment which HostA is part of.
The remote VTEP might receive the MAC/IP route from one leaf, but because that route is associated with an ESI, it can use the Type 1 Ethernet A-D routes to identify the full set of leaf switches attached to that Ethernet Segment. Therefore, remote VTEPs can load-balance traffic across both leaf switches significantly improving utilization of available bandwidth.
In the output below using show bgp evpn route-type auto-discovery, we can see the routes that tell remote VTEPs that traffic for this specific ESI can be sent through either leaf:
leaf1#show bgp evpn route-type auto-discoveryBGP routing table information for VRF defaultRouter identifier 10.0.0.11, local AS number 65101Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP c - Contributing to ECMP, % - Pending best path selectionOrigin codes: i - IGP, e - EGP, ? - incompleteAS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop Network Next Hop Metric LocPref Weight Path * > RD: 10.0.0.11:10010 auto-discovery 0 0000:0000:0000:0000:0010 - - - 0 i * > RD: 10.0.0.12:10010 auto-discovery 0 0000:0000:0000:0000:0010 10.0.0.12 - 100 0 65000 65102 i * > RD: 10.0.0.11:1 auto-discovery 0000:0000:0000:0000:0010 - - - 0 i * > RD: 10.0.0.12:1 auto-discovery 0000:0000:0000:0000:0010 10.0.0.12 - 100 0 65000 65102 i
Mass Withdrawal and Fast Convergence
Of course utilizing all available bandwidth is extremely important, but now let’s talk failure scenarios. In my opinion, just building the fabric and getting pings to work is one thing, but designing the fabric to handle various failure scenarios is real network architecture.
Suppose Leaf1 loses connectivity to the host. Traditional MAC withdrawal mechanisms may require thousands of MAC entries to age out or be individually withdrawn.
EVPN-MH uses Type 1 per-ES routes to perform mass withdrawal. Instead of withdrawing every MAC individually, Leaf1 simply withdraws the Ethernet Auto-Discovery route associated with the entire Ethernet Segment. Remote VTEPs immediately understand that traffic should no longer be sent toward Leaf1 for that ESI which dramatically improves convergence time.
In large-scale fabrics supporting thousands or tens of thousands of endpoints (even on a single leaf), this becomes a major operational advantage.
Designated Forwarder Election
One challenge with active-active forwarding is preventing duplicate traffic and loops, which is where DF election comes in. Using Type 4 routes, participating leaf switches negotiate which switch becomes the Designated Forwarder for specific VLANs or services.
In our example, Leaf1 might be elected DF, and Leaf2 would be non-DF. For BUM traffic received from the VXLAN fabric and destined toward the Ethernet Segment, only the elected DF forwards the traffic downstream. This prevents duplicate delivery to the multihomed device.
Advantages of EVPN Active-Active Multihoming
To put it in list form (which is great for my SEO 😀), there are several reasons EVPN-MH is widely used in data centers.
- Better Bandwidth Utilization
- All links remain active and forward traffic simultaneously.
- Faster Convergence
- Mass withdrawal mechanisms dramatically reduce failover times during access failures.
- Standards-Based Architecture
- Unlike proprietary MLAG implementations, EVPN-MH is based on open standards and BGP EVPN signaling.
- Better Scale
- The control plane distributes multihoming information efficiently across large fabrics.
- Simplified Operations
- Many organizations are moving toward architectures where EVPN becomes the single control plane for both overlay networking and multihoming.
Disadvantages and Challenges
EVPN-MH isn’t perfect, and one gripe I’ve heard is that it’s very complex. The learning curve is definitely steeper than traditional MLAG. Also, network engineers need to have an understanding of ESI, Route Types 1 and 4, DF election, aliasing, and split-horizon behavior.
Also, although EVPN is standards-based, vendor implementations can differ in operational details and config syntax. That means you may have subtle or even major differences in functionality and/or implementation from vendor-to-vendor.
Next, when something breaks (and according to Murphy it probably will), simply checking a port-channel isn’t really sufficient. Engineers often need to pour over EVPN route tables, Ethernet Segment state, and DF election results.
Does this complexity mean EVPN-MH is therefore inherently bad or not a viable solution? In my opinion, not at all. Yes, I believe it’s best practice to keep things simple when possible, but not at the expense of the functionality we need.
Final Thoughts
EVPN Active-Active Multihoming is one of those technologies that initially feels more complicated than the problem it solves. The first time you start reading about ESI values, Type 1 routes, Type 4 routes, aliasing, split horizon filtering, and DF elections, it can seem like a lot of moving parts just to dual-home a server.
But once you understand the underlying problem, I believe the elegance of the solution becomes evident. EVPN-MH replaces proprietary MLAG control planes with standards-based BGP signaling. It provides active-active forwarding, rapid convergence through mass withdrawal, intelligent load balancing through aliasing, and loop prevention through DF election.
As modern data center fabrics continue to standardize on EVPN and VXLAN, multihoming becomes a natural extension of the control plane rather than a separate technology bolted on afterward.
Thanks,
Phil
{networkphil} 
Leave a comment