What is EVPN Multihoming
EVPN Multihoming solves the same basic problem as MC-LAG — connecting a host to two or more switches for redundancy and load balancing — but does it natively within a BGP EVPN control plane, rather than as a separate mechanism layered on top of one. When a host is dual-homed (or multi-homed) to multiple leaf switches running EVPN-VXLAN, EVPN Multihoming coordinates those leaves so they present a single, consistent aggregation point to the host, providing all-active redundancy: every link stays actively forwarding traffic, with automatic load balancing and failover if one leaf or link goes down.
Where MC-LAG typically requires a dedicated pair of peer switches connected by a peer-link, EVPN Multihoming works directly through the EVPN control plane already carrying VXLAN routing information — meaning a host's redundant links don't need to land on the same two devices every time, and the coordination between leaves rides on infrastructure that's already there for VXLAN.
How EVPN Multihoming Works
The foundation of EVPN Multihoming is the ESI (Ethernet Segment Identifier) — a 10-byte value configured on a downlink interface. When two (or more) leaf switches configure the same ESI on their respective downlink ports connecting to the same host, those ports are recognized as peers of the same Ethernet Segment, and EVPN Multihoming treats them as a coordinated redundancy group.
Because multiple leaves can all be attached to the same Ethernet Segment, something has to decide which leaf actually forwards flooded traffic — broadcast, unknown-unicast, and multicast (BUM) traffic — arriving from the VXLAN overlay down to that segment. That's the job of the DF (Designated Forwarder): exactly one leaf per Ethernet Segment is elected DF, and only the DF is allowed to forward BUM traffic down to the local ESI; every other leaf on that segment is a Non-DF and stays silent for that traffic. DF election compares a configurable DF preference value across leaves on the same ES — the leaf with the highest preference wins, with ties broken by the lowest VTEP IP address — and the result is propagated using a dedicated Type-4 route. This is what solves what would otherwise be a serious problem: without a single elected forwarder, every leaf attached to the segment would flood the same BUM traffic down to the host redundantly.
A second mechanism, split-horizon, prevents a different failure mode: BUM traffic loops. Split-horizon enforces that only BUM traffic originating from a remote site is forwarded back down to a local Ethernet Segment — a leaf never re-floods traffic back out onto the same segment it just received equivalent traffic from — preventing both loops and duplicate delivery of the same traffic to a multihomed host.
Why EVPN Multihoming is Beneficial
True all-active redundancy, not active/standby: Every multihomed link stays forwarding traffic simultaneously, rather than sitting idle as a backup path the way some redundancy schemes do.
Scales past a fixed device pair: Because coordination happens through the shared ESI concept rather than a dedicated peer relationship between exactly two switches, a host's redundant links aren't locked into always landing on the same pair of leaves.
Solves BUM replication cleanly: DF election guarantees exactly one leaf forwards flooded traffic to a given segment, avoiding the duplicate-delivery problem that would occur if every attached leaf flooded independently.
Loop-free by design: Split-horizon logic prevents BUM traffic from looping back out the segment it arrived from, without requiring a separate spanning-tree-style mechanism to catch it.
Built on infrastructure the network already has: Because EVPN Multihoming rides on the same BGP EVPN control plane used for VXLAN routing, it doesn't require standing up a parallel redundancy protocol alongside it.