同一站点内相同 iESI，站点之间唯一：Junos 拼接

两对网关服务两个数据中心，而总得有人来决定设计需要多少个 interconnect ESI 值。答案是每个网关组一个，而不是每个 fabric 一个，也不是每个网关一个。做错了会产生一个看似已配置却选出错误 forwarder 的 fabric，或者把本应保持独立的两个站点合并。这条规则及其例外值得写在网关清单旁边。

两种范围，两条规则

在站点内部，冗余的 interconnect 网关表现为一个 multihomed 端点，因此它们共用一个 interconnect ESI。它们的 peer 必须看到一个逻辑成员，而不是两个独立成员。这正是共享值的全部意义。

在站点之间，每个网关组各用自己的值。共享同一个标识符的两个数据中心在控制平面上会变成一个 multihomed 组，这通常不是跨 WAN 拼接设计所想要的。同一组内的两个站点还会继承彼此的故障模式。

站点内部：组用一个身份

在相同的业务上下文中，为这对网关在两个 peer 上配置相同的值，并把它记录到网络的标识符清单中，而不是聊天记录里。两个成员之间的不一致正是那种会产生只有一个成员且没有明显告警的故障模式。在相信会话正常之前，先比较两个成员。

支持的模型是 all-active。同一份参考文档排除了该拼接身份的 single-active 运行、自动派生的 LACP 标识符以及 source-bmac 选项，因此假定了其中任一项的设计在选标识符之前就需要重新审视。这项约束是设计输入，不是脚注。

跨站点：不同的值，或者有意的合并

每个站点使用唯一值可以让两个网关组保持独立。如果确实打算把一个 multihomed 组扩展到多个站点，那是另一种架构，会带来自己的时延、故障和转发后果，应当作为架构来决定，而不是当作标识符的选择。请在维护窗口之前以书面形式确定该决定。

把预期的区分写进方案，以免后来复制可用站点模板的工程师把这个标识符一并带过去。

peer 语句是身份的一部分

组内每个网关按 loopback 地址列出本地 peer，而该关系位于全局 EVPN 层级，而不是某个单独的 MAC-VRF 内部。把它放到错误的层级是产生能提交但永远形不成组的配置的常见做法。把参考层级读一遍，然后照它执行。

语句名称也变了。Juniper 在 24.2R1 中重命名了 interconnect peer-gateways 语句，并在 24.4R1 中恢复了数据中心 interconnect 专用的形式。因此，取自中间版本的片段可能使用部署版本不接受的名称，反之亦然。把片段来源版本记在片段旁边。

共享 iESI 不能做什么

它不会替你定义 route target、VNI 或本地 EVPN 实例。这些仍是必须在两侧一致的单独配置，而且标识符匹配而 route target 不匹配时，会产生一个能够形成却不承载任何流量的组。在同一次检查中比较这些设置的两侧。

它也不能证明 peer 可达性或 designated forwarder 选举。先在正常情况下测试单播以及所需的广播和组播行为，然后移除一个网关再测一次，让存活的成员独自承载该组。

正是第二次运行才能证明这个组是真实存在的。

把观察到的成员关系和业务上下文与测试结果一起保存。这样，日后修改标识符就可以按 multihoming 变更来评审——它本来就是——而不是对字符串的表面修改。结果是唯一能证明标识符确实按图运作的证据。