摘要

  • RFC 9786 把 EVPN DF 选择从 [ES, Ethernet Tag] 收束为整个 ES 端口的一次决定；这不是端口上所有二层与三层服务的健康证书。
  • Port Mode 依赖所有 PE 对算法与 capability bitmap 的一致通告；一台 PE 缺失或不一致就能迫使整个 ES 回退到默认选举，扩大故障面。
  • LACP、ARP/ND/MAC/VRF 同步、Ethernet A-D per-ES 的 P/B、转发表、实包与客户验收分别属于不同证据层。

聚合的是控制，不是事实

RFC 9786 在 RFC 7432 的 All-Active 和 Single-Active 之外引入 Port-Active。关键变化不是又多了一个 DF 算法，而是改变了算法工作的粒度。普通 DF 选择以 ES 与 Ethernet Tag 为单位；Port-Active 删除 Tag，让整个访问端口只留下一个活跃 PE，其余 PE 的对应端口进入 standby。

这样做有现实价值。客户设备可以继续面对一个 LAG，运营方则获得接口级的确定转发，避免多 PE 按流量散列给某些 QoS 行为带来的不确定性。机制不绑定 MPLS、VXLAN 或 SRv6，也可以承载 EVPN、VPWS、VPN 和 IRB。它还让运营方不必为了这种主备模式强制引入 ICCP 与 LDP。

代价也来自同一个粒度。一条端口可能是许多服务的物理容器。选举一次，所有服务一起进入 active 或 standby 意图。若判断错误，影响不再天然局限于一个 VLAN。协议把动作简化成一项，运营证据反而必须展开成多项。

RFC 要求 DF 保持相应接口 up 且 forwarding；非 DF 应跨所有 VLAN 双向阻断。非 DF 可以把接口保持 operational down，也可以在 LACP 场景把它置为 Out of Sync。这里每一个动词都是应当发生的行为，不是 “DF=PE2” 这个标签已经观察到的结果。

P 位只表达共同选择

IANA 的 BGP Extended Communities 注册表把 bit 5 记为 Port Mode Designated Forwarder Election。P=1 要求把选举改到端口 ES 粒度：Modulo 以 ESI 的部分字节计算，HRW 对 ES 计算权重，RFC 9785 的 preference 也改为给端口排序。D/Don't Preempt 仍可让恢复后的端口保持非回切。

这条 capability 的权限很窄。RFC 8584明确说，PE 通告的是希望采用的算法与能力，不是它支持的一切。只有收到的所有 ES Route Type 4 对算法和 bitmap 全部一致，PE 才执行新过程。任何一条通告缺少本地配置的算法或能力、完全没有 extended community，或者同一路由携带多个该 community，接收方都必须解释为默认算法 0、无能力。

RFC 9786 把这一要求称为 unanimity。安全章节也没有粉饰其脆弱性：能修改一台 PE 的人，就可能迫使 ES 上所有 PE 回退到 RFC 7432/RFC 8584 的默认过程，造成不公平负载、服务中断、丢包或重复包。共识是过程入口，不是成功结论。

同理，DF 结果只证明在当前观察到的候选集合上，某个算法选中了某台 PE。它不证明光模块稳定、CE 看到了正确的 LACP actor，不证明 VRF 已装载，也不证明每个客户流都走通。

真正困难发生在 standby 起身之后

Port-Active 的 standby 可能一直是 down。它变成 active 时，链路要先起来，网络状态还要稳定。RFC 9786 因此把预同步列为改善收敛的条件：IRB 和三层服务应考虑 ARP/Neighbor Discovery 缓存，相关 VRF 可能需要同步；二层服务可以同步 MAC 表。

这些状态并不会由选举自动完成。所有 PE 可以对 P=1 完全一致，也可以一致选出 PE2，随后才发现 PE2 的邻居缓存、MAC 表、VRF 或本地 adjacency 落后于控制面。Port Mode 共同意图与服务状态同步必须是两张收据。

LACP 的 warm standby 只缩短一类启动成本。非 DF 不必把 member 完全打到 down，而可以保持 Out of Sync，切换时更快进入工作状态。但 OOS 不是对 ARP、ND、MAC、VRF、FIB 或远端路径的背书。它只描述接入链路协商中的一个有限事实。

P/B 通告也一样。RFC 8214定义 L2-Attr Extended Community；RFC 9786 建议在 Ethernet A-D per-ES 路由只携带 Primary 或 Backup 位，帮助远端快速收敛。per-ES 的父级 P/B 应覆盖 per-EVI 的 P/B。这个信号能证明远端收到的角色声明，却不能证明一枚报文已经穿过新 Primary 并被客户接收。

向后兼容进一步拆开了证据。只实现 RFC 7432 或 RFC 8214 的旧节点会忽略 per-ES L2-Attr，继续默认 path resolution，同时通过 ESI Label 看见 Single-Active，并沿用既有 MAC 与 per-EVI 行为。一个混合版本 ES 在某台设备上看似完整，在另一台设备上可能根本没有使用同一组加速信息。

端口不变化，服务仍然可能失败

Port-Active 有意排除 AC-DF：P=1 时 A 必须为 0，收到 A=1 也要忽略。某个 sub-interface down 所触发的 Ethernet A-D per-EVI withdrawal 不影响端口 DF。这避免服务层的变化扰动端口级主备，但也直接证明 “DF 没变” 不能作为服务健康信号——算法设计上就不消费那类证据。

合理的操作模型需要两条并行视图。端口视图记录 ESI、PE 集合、算法、完整 bitmap、计时器、DF/BDF、LACP 与 per-ES P/B。服务视图逐个记录 VLAN、EVI、VPWS、VRF、MAC/ARP/ND、FIB、计数器、远端可达性和客户探针。前者说明谁掌握聚合控制，后者说明容器里的内容是否一起活了下来。

RFC 9722通过时间同步与激活窗口减少 DF 切换的瞬态风险，但时间对齐仍不测量应用交付。RFC 9784讨论虚拟 Ethernet Segment，把一条 EVC 故障与物理 ENNI 故障划开；那是故障对象与撤回半径的问题。本篇则关注 RFC 9786 已经选择物理端口作为控制单元以后，如何避免让这个选择吞掉服务证据。

RFC Editor 信息页、IETF Datatracker与 errata 查询证明文档状态；截至 2026 年 9 月 11 日的捕获没有匹配勘误。它们不证明实现、采用或生产表现。