EVPN Multihoming¶

EVPN multihoming (often shortened to EVPN-MH or EVPN multi-homing) lets a customer device — a switch, router, server or access node — attach to two or more PE routers over a single logical link, with the PEs coordinating through BGP instead of a proprietary MC-LAG control channel. It is defined in RFC 7432 (the EVPN base specification) and refined by RFC 8584 (DF election framework). RFC 9252 and RFC 9819 carry the same machinery over SRv6.

This page covers the generic mechanisms first — they are identical whether the core runs MPLS, VXLAN or SRv6 — and then the parts that change with an SRv6 data plane.

graph LR
    CE[CE<br/>LAG with 2 member links] ---|ES 1| PE1[PE1]
    CE ---|ES 1| PE2[PE2]
    PE1 <--> CORE((MPLS / SRv6 core))
    PE2 <--> CORE
    CORE <--> PE3[PE3 remote]
    PE3 --- RCE[Remote CE]

Ethernet Segment and ESI¶

An Ethernet Segment (ES) is the set of links that connect one customer site to several PEs. From the CE's point of view it is usually a single LACP bundle; each PE sees one member link. Every PE attached to the segment configures the same Ethernet Segment Identifier (ESI).

The ESI is 10 octets: a 1-octet type followed by a 9-octet value (RFC 7432 §5). Two values are reserved: all zeros means "single-homed, no ES", and all FF (MAX-ESI) is reserved.

EVPN Routes Used for Multihoming¶

All-Active vs Single-Active¶

A third mode, port-active (RFC 9786, June 2025), elects one PE per interface rather than per VLAN — a drop-in replacement for MC-LAG active/standby. The DF election for port-active can use any of the algorithms below.

Designated Forwarder (DF) Election¶

When the CE floods a broadcast or unknown-unicast frame, every PE on the ES would deliver remote BUM copies back to it. The DF is the one PE per that sends BUM toward the CE; the others drop it.

PEs learn each other through Type 4 routes, wait for the DF election timer (3 seconds by default) so all routes arrive, then run the election.

RFC 8584 also introduced the DF Election extended community on the Type 4 route: a 5-bit algorithm field (0 = modulo, 1 = HRW, ⅔ = highest/lowest preference) and a capability bitmap (D, AC-DF, …). If the PEs on a segment disagree, they all fall back to modulo. Vendor support varies: Cisco IOS-XR and Junos expose modulo and preference-based election in configuration, so check the release notes before designing around HRW.

Modulo example: ES with PE1 (192.0.2.1) and PE2 (192.0.2.2), N = 2
  Ordered list: [PE1, PE2]
  VLAN 100 → 100 mod 2 = 0 → PE1 is DF
  VLAN 101 → 101 mod 2 = 1 → PE2 is DF
  If you only use even VLANs, PE1 is DF for everything — HRW avoids this.

Aliasing and Backup Path¶

A MAC address behind a multihomed CE may only be learned (and advertised in a Type 2 route) by one of the PEs — the one whose LAG member the CE hashed that flow onto. Without help, remote PEs would send all traffic for that MAC to that single PE.

Aliasing fixes this: each PE advertises an Ethernet A-D per EVI route for the ES. A remote PE that sees a Type 2 route with a non-zero ESI looks up every PE that advertised A-D per EVI for that ESI and load-balances across all of them, even the ones that never learned the MAC.

In single-active mode the same routes provide a backup path: the remote PE installs the DF as primary and the other PE as a pre-programmed backup, ready for fast switchover.

Mass Withdrawal¶

If PE1 loses its link to a CE with 10 000 MACs, withdrawing 10 000 Type 2 routes takes time. Instead, PE1 withdraws a single Ethernet A-D per ES route. Every remote PE immediately removes PE1 from the next-hop set of all MACs associated with that ESI — a prefix-independent convergence step — and the individual Type 2 withdrawals follow in the background.

sequenceDiagram
    participant CE
    participant PE1
    participant PE2
    participant PE3 as PE3 (remote)

    Note over CE,PE1: Link CE–PE1 fails
    PE1->>PE3: Withdraw Ethernet A-D per ES (ESI 1)
    PE3->>PE3: Remove PE1 from every MAC/IP with ESI 1
    Note over PE3: All flows now go to PE2 only
    PE1->>PE3: (later) Withdraw individual Type 2 routes

Split-Horizon Filtering¶

In all-active mode, a BUM frame from the CE arrives at PE1, which floods it to every PE in the EVI — including PE2, which is attached to the same ES. If PE2 is the DF, it would send the frame straight back to the CE, creating a loop or duplicate. Split-horizon stops this: the receiving PE must know which ES the frame came from and skip that ES.

How the "came from" information is carried depends on the data plane:

RFC 9746 (March 2025) lets PEs signal which method they use, with a Split-Horizon Type field in the ESI Label extended community: MPLS defaults to ESI-label filtering, VXLAN to local bias, and SRv6 defaults to ESI filtering but supports both. Local bias only works with all-active redundancy.

EVPN Multihoming over SRv6¶

SRv6 has no label stack to push an ESI label onto, so the egress PE's local ES identifier travels as an argument inside the SID itself:

1. Each PE allocates an End.DT2M SID per bridge domain for BUM traffic and advertises its LOC:FUNC part in the Type 3 (IMET) route.
2. For each local ES it allocates an Arg.FE2 value and advertises it in the Type 1 A-D per ES route (SRv6 L2 Service TLV).
3. When PE1 floods BUM that it received from ES 1 to PE2, it combines PE2's End.DT2M LOC:FUNC with PE2's Arg.FE2 for ES 1 into the destination address.
4. PE2 executes End.DT2M: it decapsulates and floods into the bridge domain, excluding the interfaces of the ES identified by the argument.

PE2 Type 3 route:  End.DT2M LOC:FUNC = fc00:0:2:e002::   SID structure 32/16/16, AL 16
PE2 Type 1 route:  Arg.FE2 for ES 1  = 0x00a1             AL 16
PE1 → PE2, BUM received from ES 1:
    argument inserted at offset 32+16+16 = 64 bits
    DA = fc00:0:2:e002:a1::
PE2: End.DT2M with argument 0x00a1 → flood to every AC in the bridge domain except ES 1

Known unicast does not need split-horizon. Remote PEs use End.DT2U (bridge-table lookup) or End.DX2 (cross-connect, for EVPN-VPWS) SIDs from the Type 1 per-EVI and Type 2 routes, and aliasing simply becomes ECMP across the SRv6 SIDs of all PEs on the ES. With uSID these service SIDs are typically uDT2U/uDT2M micro-SIDs on the PE's locator.

The underlay contributes too: TI-LFA protects the core paths between PEs, while mass withdrawal and aliasing protect the attachment circuit — the two mechanisms are complementary.

EVPN L3 Multihoming (Routed CE)¶

When the CE is a router and the service is an L3VPN, the same ES concepts apply to a routed hand-off. draft-ietf-bess-evpn-l3mh-proto specifies EVPN L3 multihoming:

1. CE connects to PE1 and PE2 via an Ethernet Segment (same ESI on both PEs)
2. PEs discover each other via Type 4 routes and elect a DF
3. ARP/ND entries learned by one PE are synced to the other with Type 2 routes, so either PE can route to the CE immediately
4. Prefixes are advertised to remote PEs as Type 5 (or VPNv4/VPNv6) routes with SRv6 End.DT4/End.DT6/End.DT46 service SIDs
5. Remote PEs ECMP across both PEs; on PE or link failure, the Type 1 per-ES withdrawal triggers fast reconvergence

EVPN Multihoming vs MC-LAG¶

Configuration Examples¶

Both PEs on the segment get the same ESI and redundancy mode. The examples use the type 0 ESI 00:11:22:33:44:55:66:77:88:99 with preference-based DF election (PE1 preferred).

!! PE1 (use weight 50 on PE2)
interface Bundle-Ether10
 lacp system mac 0011.2233.4455
!
evpn
 interface Bundle-Ether10
  ethernet-segment
   identifier type 0 11.22.33.44.55.66.77.88.99
   !! all-active is the default; alternatives:
   !! load-balancing-mode single-active | port-active
   service-carving preference-based
    weight 100
  !
 !
 !! SRv6: EVPN services take SIDs from this locator
 segment-routing srv6
  locator MAIN
 !
!

# PE1 (use preference value 50 on PE2)
set interfaces ae0 esi 00:11:22:33:44:55:66:77:88:99
set interfaces ae0 esi all-active
set interfaces ae0 esi df-election-type preference value 100
# identical LACP system ID on every PE of the segment
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp system-id 00:11:22:33:44:55

Common Pitfalls¶

• ESI mismatch: a typo in one PE's ESI silently turns an all-active segment into two single-homed sites — the CE sees duplicate BUM and MAC flaps.
• LACP system ID: for an all-active LAG, every PE must present the same LACP system ID and key to the CE.
• Mixed DF algorithms: PEs that advertise different DF algorithms fall back to modulo; check the DF Election extended community on the Type 4 routes.
• Core isolation: if a PE loses all core connectivity but keeps its CE link up, the CE keeps hashing traffic into a black hole. Most implementations bring the access interface down on core isolation — enable it.
• SRv6 argument length: on SRv6, the End.DT2M argument length must match between Type 1 and Type 3 routes (RFC 9819); mismatches stop BUM from that segment.

Further Reading¶

• BGP Overlay Services — L3VPN and EVPN fundamentals over SRv6
• Network Programming — End.DT2M, End.DT2U and End.DX2 behaviors
• VPN Services — SRv6 VPN use cases
• TI-LFA — Fast reroute for the SRv6 underlay
• RFC 9252 — BGP Overlay Services Based on SRv6
• RFC 9819 — End.DT2M ESI-filtering argument signaling (updates RFC 9252)

References¶

1. RFC 7432 - BGP MPLS-Based Ethernet VPN — EVPN base specification: ESI, route types, DF election, aliasing, mass withdrawal and the ESI label
2. RFC 8584 - Framework for EVPN Designated Forwarder Election Extensibility — HRW and AC-influenced DF election, DF Election extended community
3. RFC 9785 - Preference-Based EVPN Designated Forwarder (DF) Election — Highest/lowest-preference DF algorithms and the non-revertive (Don't Preempt) capability
4. RFC 8365 - A Network Virtualization Overlay Solution Using EVPN — EVPN over VXLAN/NVO, including local-bias split-horizon
5. RFC 9252 - BGP Overlay Services Based on SRv6 — SRv6 Service TLVs for EVPN, including End.DT2M and the ESI-filtering argument
6. RFC 9819 - Argument Signaling for BGP Services in SRv6 — Precise rules for combining the End.DT2M SID and the Arg.FE2 argument
7. RFC 8986 - SRv6 Network Programming — End.DT2M, End.DT2U and End.DX2 behaviors and Arg.FE2
8. RFC 9136 - IP Prefix Advertisement in EVPN — EVPN Type 5 routes
9. draft-ietf-bess-evpn-l3mh-proto — EVPN Layer-3 Multihoming
10. RFC 9786 - EVPN Port-Active Redundancy Mode — Per-interface active/standby multihoming
11. RFC 9746 - BGP EVPN Multihoming Extensions for Split-Horizon Filtering — Signaling ESI-label vs local-bias filtering per encapsulation, including SRv6
12. Cisco IOS-XR EVPN Command Reference (NCS 5500) — ethernet-segment, load-balancing-mode and service-carving syntax
13. Junos esi statement — ESI, redundancy mode and DF election type on Junos
14. Junos: LACP for EVPN active-active multihoming — Matching LACP system IDs across PEs
15. EANTC Multi-Vendor Interoperability Tests — Industry interoperability demonstrations including EVPN multihoming