Junos MC-LAG to EVPN Multihoming Migration

MC-LAG has kept dual-homed servers alive on Junos for a decade, but it is a vendor-proprietary construct: the peer relationship is held together by ICCP over a dedicated link, and every design decision — split-brain behaviour, ARP handling, the LACP system identifier the server sees — is Juniper-specific. Multi-vendor leaf-spine fabrics, however, need an interoperable multihoming model, which is why most operators eventually migrate MC-LAG links to standard EVPN ESI multihoming. This guide walks through the migration in the order you should actually perform it: audit the ICCP and LACP liveness behaviour first, decide the ESI numbering scheme, generate the ESI LAG configuration, and cut over one server bundle at a time with a rollback path that does not require touching the server.

Why EVPN multihoming replaces MC-LAG

Both features give a server an active/active bundle across two switches. The difference is where the control plane lives. MC-LAG uses ICCP (Inter-Chassis Control Protocol) plus a lacp stanza block with a synchronised system identifier and an icl (inter-chassis link) that carries data. EVPN multihoming uses BGP EVPN Type-4 Ethernet Segment routes, an ESI per bundle, and the underlay you already run for VXLAN.

Step 1 — audit the MC-LAG you are about to leave

Before changing anything, capture the current liveness state. The two failure modes that hurt in production are an ICCP session that is up while the ICL is not passing traffic, and a server bundle whose LACP system identifier silently differs between peers.

show iccp
show interfaces ae0 | match "LACP|System"
show lacp interfaces ae0
show multi-chassis-protection
show configuration interfaces ae0 aggregated-ether-options

Check three things in the output: the ICCP session state must be Up with a non-zero heartbeat count; the LACP system ID for the aggregated Ethernet interface must match on both peers (that is the value the server hashes against); and the multi-chassis-protection stanza should reference the ICL interface, not a routed path. If the system identifiers differ, the server may be pinning all traffic to one member while the switches believe the bundle is healthy.

Step 2 — choose an ESI scheme before you type a command

An ESI is a 10-byte value. The workable convention is to keep the first eight bytes constant per fabric and increment the last two bytes per bundle, so that the ES-Import route target derived from the ESI stays readable and auditable. Type 1 ESI (LACP-derived) is the pragmatic choice on Junos for server-facing bundles: the switch auto-derives the identifier from the LACP system ID, which keeps the string the server sees identical across both leaves.

# fabric convention: 00:11:22:33:44:55:66:77:xx:yy
set interfaces ae0 esi 00:11:22:33:44:55:66:77:00:01
set interfaces ae0 esi all-active
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp system-id 00:11:22:33:44:55:66:77:00:01

Step 3 — generate the ESI LAG configuration

Juniper ships an EZ-LAG commit script that expands a short stanza into the full EVPN multihoming configuration, including the aggregated Ethernet interfaces, the IRB, and LACP force-up on the server link. It is intended precisely for MC-LAG-to-EVPN migrations, and the generated configuration can be diffed against a hand-built one to validate your template.

set protocols evpn ez-lag vslan-encap vlan-aware
set protocols evpn ez-lag esi-lag 1 peer-id 10.0.0.2
set protocols evpn ez-lag esi-lag 1 lacp-active
commit

Two defaults worth knowing: if you do not specify a virtual gateway MAC, the script assigns 00:00:5e:00:01:01; and LACP force-up is applied on the server-facing link so a PXE-booting host sees the bundle come up before it negotiates LACP.

Step 4 — cut over one bundle at a time

Serve the migration in this order, never in parallel:

1. Bring up the EVPN underlay and verify Type-4 routes for the new ESI appear on both peers.
2. Remove the server bundle from MC-LAG (delete the multi-chassis-protection and the lacp synchronisation stanzas) while keeping the member links configured.
3. Apply the ESI configuration to the aggregated Ethernet interface and commit — the interface should stay up because the member links never went down.
4. Verify the server's LACP view is unchanged: the same system ID, the same two active members.
5. Only then delete the ICCP and ICL configuration.

show evpn instance extensive | match "ESI|Designated"
show ethernet-switching evpn arp-table
show bgp summary | match 10.0.0.2
monitor traffic interface ae0 no-resolve detail

Rollback and the pitfalls that bite

Rollback is the same procedure in reverse, and it works because the member interfaces were never shut. What usually breaks a migration is not the ESI syntax but sequence: deleting ICCP before the EVPN ES route is installed leaves the pair in a both-active state with no designated forwarder, which duplicates BUM traffic. The second common mistake is a mismatched ESI on the two peers — check with show evpn instance extensive that both sides report the identical ESI, otherwise the segment never forms and the server silently loses half its bandwidth. Sample the interface counters after the cutover and confirm traffic is leaving both member links, not just one.

Scaling the design: how many ESI LAGs per leaf pair

The number of multihomed bundles a leaf pair can carry is bounded by three things: the EVPN Type-4 route scale in the control plane, the EVPN instance count in the data plane, and the number of MPLS or VXLAN tunnels the hardware can keep programmed. A single VLAN-aware bundle service instance handles many VLANs with one ESI, which is far more scalable than a VLAN-based service instance per VLAN — the difference between two hundred EVPN instances and half a dozen. Check the platform's documented EVPN scale numbers rather than discovering the limit during a migration: show evpn instance summary and the platform datasheet together tell you whether the fabric you are designing fits.

Another dimension is the ESI-to-interface relationship. One ESI per server bundle is the model to keep, because the designated forwarder election is per-ESI: mixing two servers onto a single ESI makes the DF result meaningless for both, and BUM traffic from one server may be dropped on the wrong peer. If you must conserve ESI space, share an ESI across a pair of servers attached to the same leaf pair only when they are genuinely in the same broadcast domain and you accept the shared DF state.

Interoperating outside Juniper

The reason to move to EVPN multihoming is interoperability, so test it rather than assume it. When the peer is another vendor, three fields must match exactly: the ESI value, the ES-Import route target (or the route target community, depending on the implementation), and the LACP system identifier the server sees. Vendors differ on whether an ESI derived from LACP is supported, so the safest cross-vendor design uses an explicit, manually assigned ESI type 0 rather than type 1 — you lose the automatic derivation but you gain determinism, and determinism is worth more than typing saved once.

# verify the peer agrees on everything that matters
show evpn instance  extensive | match "ESI|Route target|Designated"
show bgp group EVPN-MH | match "Type-4"
show lacp interfaces ae0 detail | match "System"

If Type-4 routes are exchanged but the segment never becomes active, compare the ES-Import community on both sides; a mismatch usually comes from an automatically derived value computed differently by the two implementations. Where the peer cannot exchange EVPN routes at all, keep MC-LAG on that pair and run EVPN multihoming only inside the EVPN fabric — a partially migrated topology is a perfectly acceptable end state as long as the boundary is documented.

A verification checklist you can automate

Wrap the migration checks into a script and run it before, during and after the change window. The point is not elegance; it is having a single artefact that answers "is this bundle healthy" without an engineer remembering six commands.

#!/bin/sh
# single-bundle health check: pass the aggregated Ethernet interface
AE=${1:-ae0}
echo "=== ICCP (should be gone after migration, up before) ==="
show iccp | head -5
echo "=== ESI / DF state ==="
show evpn instance extensive | grep -A6 "$AE"
echo "=== LACP view the server sees ==="
show lacp interfaces $AE | grep -E "System|actor|partner"
echo "=== per-member traffic ==="
show interfaces $AE detail | grep -E "Input bytes|Output bytes|member"

Two of those outputs deserve more than a glance. Per-member byte counters should be within a reasonable margin of each other on an active/active bundle; a large imbalance points at a hashing or system-identifier problem rather than at EVPN. And the partner section of the LACP view should show the server's system identifier and port state as distributing — if the server thinks one member is standby, the migration succeeded on the switches and failed on the outcome.

FAQ

Can MC-LAG and EVPN multihoming coexist on the same device? Yes, on different interfaces. Keep the two configurations on separate aggregated Ethernet interfaces and separate VLANs; mixing them on one bundle is what produces ambiguous DF behaviour.

Do I need VXLAN to use EVPN multihoming? No. ESI LAGs work over an MPLS-based EVPN as well, and even on a fabric where the underlay is plain routed IP with EVPN over it. The requirement is an EVPN control plane, not specifically VXLAN.

What happens to a server during the cutover? Nothing, if the member links stay up. The server sees the same LACP system identifier and the same two members; the only change is which set of switches is doing the designated forwarding. That is why the procedure insists on keeping interfaces up and deleting ICCP last.

How do I roll a bundle back during business hours? Re-apply the MC-LAG stanzas and remove the ESI configuration. Because the member links never went down, the bundle stays up throughout, and the server's LACP state does not change. Keep the ICCP and ICL configuration present-but-unused until the whole migration is signed off, not deleted after the first bundle.

Related Reading

Related reading: MC-LAG Explained: ICCP, BFD and LACP System ID Deep Dive, Juniper EVPN ESI-LAG: ESI Types, LACP and Junos CLI, Junos Aggregated Ethernet (AE) and LACP Configuration

原文链接：https://www.juniper.net/documentation/us/en/software/junos/evpn/topics/topic-map/easy-evpn-lag-config-script.html