Same iESI inside a site, unique across sites: Junos stitching

Two gateway pairs serve two data centres, and somebody has to decide how many interconnect ESI values the design needs. The answer is one per gateway group, not one per fabric and not one per gateway. Getting that wrong produces a fabric that looks configured and elects the wrong forwarder, or merges two sites that were meant to stay distinct. The rule and its exceptions are worth writing down beside the gateway list.

Two scopes, two rules

Inside a site, the redundant interconnect gateways act as one multihomed endpoint, so they share a single interconnect ESI. Their peers must see one logical member rather than two independent ones. That is the whole point of the shared value.

Between sites, each gateway group gets its own value. Two data centres that share an identifier become one multihomed group in the control plane, which is not what a stitching design across a WAN usually intends. Two sites in one group also inherit each other's failure modes.

Within a site: one identity for the group

Give the pair the same value on both peers, in the same service context, and record it in the network's identifier inventory rather than in a chat thread. A mismatch between the two members is the failure mode that produces a group of one and no obvious alarm. Compare both members before believing a working session.

The supported model is all-active. The same reference excludes single-active operation, auto-derived LACP identifiers and source-bmac options for this stitching identity, so a design that assumed one of those needs revisiting before the identifier is even chosen. That constraint is a design input, not a footnote.

Across sites: different values, or a deliberate merge

A unique value per site keeps the two gateway groups separate. If the intention is genuinely to extend one multihomed group across sites, that is a different architecture with its own latency, failure and forwarding consequences, and it should be decided as an architecture rather than as an identifier choice. Ask for that decision in writing before the maintenance window.

Write the intended distinction into the plan, so a later engineer copying a working site template does not import its identifier along with it.

The peer statement is part of the identity

Each gateway in the group lists its local peers by loopback address, and that relationship lives at the global EVPN level rather than inside an individual MAC-VRF. Putting it in the wrong hierarchy is a common way to produce a configuration that commits but never forms the group. Read the reference hierarchy once, then keep to it.

The statement name also moved. Juniper renamed the interconnect peer-gateways statement in 24.2R1 and restored the interconnect-specific form for data-centre interconnect in 24.4R1. A snippet taken from the intermediate release can therefore use a name the deployed version does not accept, or vice versa. Record the release the snippet came from next to the snippet itself.

What sharing an iESI does not do

It does not define route targets, VNIs or the local EVPN instance for you. Those remain separate configuration that has to agree on both sides, and an identifier that matches while a route target does not produces a group that forms and carries nothing. Compare both sides of those settings in the same pass.

Nor does it prove peer reachability or designated-forwarder election. Test unicast and the required broadcast and multicast behaviour in the normal case, then repeat with one gateway removed so the surviving member carries the group alone.

That second run is the one that proves the group is real.

Keep the observed membership and service context with the test results. A later identifier change can then be reviewed as a multihoming change, which is what it is, rather than as a cosmetic edit to a string. The results are the only evidence that the identifier does what the drawing says.