Juniper EVPN ESI-LAG: ESI Types, LACP and Junos CLI

MC-LAG is a single-vendor control protocol; EVPN ESI-LAG does the same job with standards-based signalling over BGP. This guide covers how an Ethernet Segment Identifier (ESI) identifies a multihomed server bundle on Juniper QFX switches, which ESI types Junos supports, and why the LACP system ID that the server sees matters as much as the ESI itself. Every step ends with a verification command so you can prove the segment is all-active before servers are connected.

What an ESI Actually Identifies

An ESI is a 10-byte value that names one Ethernet segment: the set of links from two or more leaf switches to the same server or blade chassis. The same ESI is configured on every leaf that touches that server, and it is carried in EVPN Type-4 Ethernet Segment routes, which use the ES-Import route target extended community to keep segments isolated from each other. Junos supports three ESI patterns in practice:

• Type 0 - a manually hard-coded ESI. Predictable, audit-friendly and the pattern most runbooks standardise on.
• Type 1 - auto-derived from LACP, convenient for large server farms where scripting the ESI would be overhead.
• Type 5 - an IRB/VGA gateway ESI encoded from the AS number, used for anycast gateway designs.

It is worth being precise about scope, because ESI confusion causes real outages. An ESI does not identify a link, a VLAN, or the pair of uplinks between two switches; it identifies the Ethernet segment as seen by the whole fabric. Both leaves that connect to server-rack-A-01 configure the same ESI on their own aggregate interfaces, and each advertises a Type-4 route carrying that ESI plus the ES-Import route target. Every other PE that imports the route learns "this segment is reachable through these two VTEPs", which is exactly what makes the fabric treat the segment as multihomed rather than as two independent single-homed attachments.

Two consequences follow. First, the same ESI must never be reused for a different server: silently sharing a segment between two hosts makes the designated forwarder election treat them as one segment and can blackhole traffic for one of them. Second, the ES-Import route target must be derived consistently — Junos computes it automatically when the value is left at zero, so only hard-code it if you do so identically on every leaf. A fourth pattern that appears in older Juniper documentation is an ESI derived from the device's own bridge MAC; avoid it on modern QFX because the value changes with hardware, and standardise runbooks on type 0 for server segments.

Structured ESI Assignment

Do not allocate ESIs randomly. Juniper's guidance is to keep the first 8 bytes identical and change only the last two, so every segment in the fabric shares a prefix and stays sortable in documentation:

00:03:03:03:03:03:03:03:03:01   server-rack-A-01
00:03:03:03:03:03:03:03:03:02   server-rack-A-02
00:03:03:03:03:03:03:03:03:03   server-rack-B-01

This also removes a migration trap: ES import route community handling changed in Junos 17.3R3, so a structured scheme keeps older and newer releases consistent in mixed fleets. If you are moving from MC-LAG to ESI-LAG, the full comparison of ICCP failure behaviour is covered in MC-LAG ICCP failure scenarios.

What a scheme promises has to be practised: keep a small spreadsheet or YAML inventory that maps each ESI to a rack, a server, and the pair of leaf interfaces that carry the segment, and generate the CLI from that file rather than typing it. In an Ansible or AVD-driven fabric the ESI and the LACP system ID become fields in the server's record and the leaf templates render them, so a server move is a variable change and a review, not a console session. That inventory is also the only reliable way to answer the one question you will be asked during an incident: which other leaf should be seeing this ESI?

LACP System ID Must Match the ESI

The server only bundles its links if the LACP system ID it receives from both leaves is identical. Best practice is to derive that system ID from the last 6 bytes of the ESI, so one value drives both the control-plane signalling and what the host sees:

set interfaces ae0 esi 00:03:03:03:03:03:03:03:03:01
set interfaces ae0 esi all-active
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp system-id 03:03:03:03:03:01

Unique ESI plus unique system ID per server; identical values across the two leaves for the same server. Mixing this up is the number one cause of a server that shows one link as "collecting, distributing" and the other permanently out of sync.

The reason this is not merely cosmetic: LACP is a link-level protocol and the server has no idea that two switches are involved. It receives LACPDUs on two different physical links, compares the Actor System ID it sees on each, and only bundles links whose system ID matches. If leaf-1 advertises its own backplane-derived system ID and leaf-2 advertises something else, the server keeps one link in collecting, distributing and parks the other as a standby — the aggregate comes up, but at half the bandwidth and with none of the redundancy benefit you deployed the segment for.

Deriving the system ID from the last six bytes of the ESI is the audit-friendly convention because a single lookup tells you both values. Check what the server actually sees with:

show lacp interfaces ae0 | match "Actor|Partner"
show interfaces ae0 | match "LACP|esi"

Keep the system ID unique per server. A fabric-wide identical LACP system ID is a tempting shortcut and a genuine hazard: two servers in the same broadcast domain with identical LACP system IDs and different port keys will interfere with each other's bundles. One ESI, one system ID, one server.

Member Links and VLAN Mapping

The physical ports simply reference the aggregate, and the aggregate carries the VLANs that are also mapped to VNIs - on the same ESI-LAG you cannot mix VXLAN-mapped VLANs with plain bridged VLANs:

set interfaces et-0/0/50 ether-options 802.3ad ae0
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members 100-101
set vlans vlan100 vlan-id 100
set vlans vlan100 vxlan vni 50100

Enterprise-style configuration is recommended over service-provider style on QFX5000 series: it keeps storm control profiles and BPDU blocking available without enabling RSTP on the leaf. The overlay side (VTEP source, route distinguisher, EVPN import policy) follows the same pattern as a standard EVPN-VXLAN fabric, described in Junos EVPN-VXLAN CRB fabric configuration.

Two rules to hold on to when mapping VLANs to an ESI-LAG. First, if a VLAN has a VNI on one leaf it must have a VNI on the other leaf, and it must be the same VNI; the local VLAN ID is only locally significant, but the VNI is what the overlay matches on. Second, if the aggregate carries a mix of overlay VLANs and plain bridged VLANs, split it: create a second aggregate with a different ESI for the layer-2-only VLANs, because a single Ethernet segment cannot be partly in the EVPN and partly outside it. Getting this wrong produces a segment that looks healthy in show evpn instance while traffic for one VLAN disappears into a bridge domain no remote VTEP knows about.

Underlay and Overlay Prerequisites

ESI-LAG rides on a working EVPN-VXLAN fabric; multihoming configuration will not compensate for a broken underlay. Before configuring the segment, confirm all four of these:

• Every VTEP's loopback is reachable as a /32 from every other VTEP, over the IGP or BGP underlay.
• EVPN BGP sessions between leaves show Establ with the EVPN NLRI family negotiated — a session that is up without the family will silently carry nothing.
• The same VNI is mapped to a VLAN on both leaves, and the route distinguisher / route target scheme lets each leaf import the other's Type-4 routes.
• LACP is active on the leaf side; passive on both ends means no LACPDUs are ever sent and the aggregate never comes up.

show bgp summary | match "evpn"
show route table bgp.evpn.0 | match "0:0:0:0:0:0"
show evpn instance extensive | match "Route Distinguisher|Encapsulation"
show route receive-protocol bgp 10.0.0.2 table bgp.evpn.0

Designated Forwarder Election and All-Active Forwarding

On an all-active segment both leaves forward unicast traffic for the server, but broadcast, unknown unicast and multicast (BUM) traffic must be sent by exactly one of them per VLAN — the designated forwarder (DF). Junos runs RFC 7432 mode DF election by default and also supports the newer preference-based election; operationally, what matters is that exactly one leaf is DF for each VLAN, that both leaves agree on the outcome, and that the server never receives a duplicated BUM frame.

show evpn instance extensive | match "ESI|DF|Designated"
show evpn ethernet-segment detail | match "ESI|Interface|Mode|DF"
show evpn ethernet-segment detail | match "Designated forwarder"

If both leaves believe they are DF for the same VLAN, the classic symptom is duplicate ARP replies (intermittent duplicate-address alarms) or a MAC that flaps every few minutes in an upstream access switch. Re-check the ESI value first: a single mistyped byte makes the two leaves believe they are on different segments, and the election then runs twice instead of once.

Failure and Convergence Behaviour

The failure model is the reason to deploy ESI-LAG rather than a plain LAG to one leaf. If the link from server-rack-A-01 to leaf-2 fails, the server keeps the leaf-1 member active, leaf-2 withdraws its Type-4 route, and traffic continues — no DF re-election is needed when a non-DF leaf loses the segment, and re-election completes in milliseconds when the DF leaf itself does. If an entire leaf fails, the surviving leaf becomes DF for its VLANs and remote VTEPs reconverge on the remaining Type-4 route; with BFD on the underlay that is typically a few hundred milliseconds. Compare this with MC-LAG, where an ICCP partition can leave both peers forwarding or a secondary peer blackholing traffic until someone notices. If you are designing the transition, the ICCP failure behaviour on the legacy side is worth reading in detail before you cut over.

Two edge cases deserve attention. A segment-wide failure — both leaves losing their links to the server — withdraws the Type-4 route entirely and remote VTEPs stop advertising reachability, which is correct but means the host is simply gone. And a leaf reload is not a segment failure as long as the other leaf stays up, but it does trigger DF re-election for every VLAN on that segment, so a reload during a maintenance window should be done with the server's traffic profile in mind.

ESI-LAG or MC-LAG: the migration decision

Both designs give a server one logical bundle across two switches; the difference is where the coordination lives. MC-LAG is a vendor control protocol between exactly two peers over a dedicated inter-chassis link, with liveness detection (ICCP/BFD) deciding who keeps forwarding when the peers stop talking. ESI-LAG replaces that control protocol with standards-based signalling: the segment is advertised in EVPN Type-4 routes, and any PE that imports those routes knows the segment is multihomed. That is why ESI-LAG survives a mixed-vendor leaf layer, and why it scales past two leaves.

• Stay on MC-LAG when the servers are single-homed-capable legacy hosts, when the two switches already run an ICCP relationship you trust, or when the fabric around them is not EVPN at all. There is no point running EVPN only to carry a multihoming signal.
• Move to ESI-LAG when the leaves are already EVPN-VXLAN VTEPs, when you want the segment signalled rather than negotiated, when you need more than two leaves on a segment, or when the failure behaviour of an ICCP partition has burned you before.
• Do not run both on the same interfaces. A given aggregate is either an MC-LAG member or an ESI-LAG member; overlapping the two on one AE bundle produces a segment that looks up on both control planes and forwards correctly on neither.

The configuration difference is smaller than the operational difference. The MC-LAG pairing lives in the multi-chassis stanza; the ESI-LAG pairing is two lines on the aggregate:

! MC-LAG: the pairing is a vendor protocol between two peers
set interfaces ae0 aggregated-ether-options lacp system-id 03:03:03:03:03:01

! ESI-LAG: the pairing is advertised in EVPN Type-4 routes
set interfaces ae0 esi 00:03:03:03:03:03:03:03:03:01
set interfaces ae0 esi all-active

What changes is the failure model. MC-LAG peers must agree on liveness before either forwards, so a partition makes both peers conservative; ESI-LAG forwards on both leaves by design and relies on DF election to keep BUM traffic single-copy. That publication model is also why the LACP system ID matters so much: in MC-LAG it is a peer-coordination detail, in ESI-LAG it is the only thing keeping the server from treating your two leaves as two independent partners.

A practical migration sequence: bring the EVPN overlay up first, prove the underlay and the Type-2/Type-3 routes, then convert one server segment at a time by adding the ESI and removing the MC-LAG binding from the same aggregate in a single commit. Verify each converted segment before starting the next one, and keep the rollback configuration at the top of the ticket. If the leaf pair itself is a single logical device rather than two independent switches, the different trade-off is covered in EX Virtual Chassis configuration; the legacy-side failure behaviour that motivates the move is in MC-LAG ICCP failure scenarios and the protocol details in MC-LAG explained: ICCP, BFD and LACP system ID.

Verification

show evpn instance extensive | match "DF|ES"
show lacp interfaces ae0
show interfaces ae0 | match "esi|LACP"
show ethernet-switching table | match 100

On the leaves, the Type-4 route must show both peers as members of the segment and the designated forwarder election must resolve to exactly one leaf per VLAN. On the server, both links should be in the bundle with a single LACP partner ID. If the server stacks links but one leaf never forwards, compare the ESI and system ID on both sides before touching anything else.

Build a pre-connection checklist and run it every time, in this order:

show evpn instance extensive | match "Number of ethernet segments"
show evpn ethernet-segment detail | match "ESI|Interface|Mode"
show lacp interfaces ae0 extensive | match "state|System"
show ethernet-switching table | match 100
show interfaces ae0 | match "Physical link|LACP"

Then verify from the host side: on Linux, cat /proc/net/bonding/bond0; on Windows, Get-NetLbfoTeam. Confirm both members are up, that the same partner system ID appears on both, and that the team mode is LACP active. Connect the server one link at a time, checking the bundle state between each cable, so that a problem is attributable to one link rather than to the segment as a whole.

Common Mistakes and Troubleshooting Checklist

• The same ESI on two different servers — check this first, every time. Symptom: odd DF election and one server losing traffic after a leaf reboot.
• System ID taken from the switch instead of the ESI — one server link stays out of the bundle while the EVPN side looks perfectly healthy.
• LACP passive on both ends — nothing comes up at all, because no LACPDUs are sent and each side waits for the other.
• VLAN-to-VNI mismatch between leaves — the VNI is the same but the local VLAN differs, or a VLAN mapped to a VNI on one leaf is plain bridged on the other; the host can reach itself but not its peers.
• One leaf enterprise-style, the other service-provider-style — the segment exists on both, but member VLANs never align.
• No ES-Import route target — Type-4 routes are exchanged but the segment is not recognised as multihomed, so DF election never runs.
• Aggregate up but server sees two partners — the system IDs differ; fix the LACP system ID before looking at anything else.

原文链接：https://www.juniper.net/documentation/us/en/software/nce/evpn-lag-multihoming-guide/topics/task/evpn-lag-guide-esi-types-lacp.html