摘要

  • RFC 9784 为每个虚拟以太网段保留独立身份，并要求分别监测 EVC；共享同一物理端口并不意味着所有业务共享同一故障。
  • 单条 EVC 失效应只触发关联 vES 或业务实例的恢复；真正的 ENNI 故障才可以通过分组撤回协调端口下的全部受影响 vES。
  • BGP 撤回只是控制面指令，不能单独证明检测范围正确、各接收端成员表一致、转发已经收敛或客户业务已经恢复。

告警显示一条以太网虚电路中断，物理接口却仍然在线。旁边几百条业务还在正常传输。如果恢复系统仍把物理端口当作唯一故障单位，它就可能清掉无关客户的 MAC 状态，把一个局部缺陷扩大成新的事故。

RFC 9784 的价值正在这里。它讨论 EVPN 与 PBB-EVPN 的虚拟以太网段，但真正处理的是“谁有权触发多大动作”。一条逻辑电路与其他电路共用物理容器，不等于它的告警有权代表整个容器。

反过来也一样。若坏掉的确实是 ENNI，端口下数千个 vES 都失去这条物理路径。逐一发送和处理数千次撤回，可能把收敛时间浪费在重复表达同一物理事件上。因此系统还需要一种受约束的集合信号。局部处置与批量处置都合理，前提是它们对应不同、且已经被证明的故障对象。

物理共享不会消灭逻辑身份

传统 EVPN 的 Ethernet Segment 是连接客户站点与一个或多个 PE 的物理链路集合。RFC 9784 把这个概念延伸到 EVC、EVC 组合、伪线和 LSP。于是，一只物理 ENNI 可以同时承载大量相互独立的虚拟以太网段。

这不是抽象的模型游戏。批发接入网络本来就以昂贵的物理端口承载许多客户、VLAN、广播域和冗余组。规范给出的规模包括数千个单归属 vES、数百个 Single-Active vES，以及可能存在的 All-Active vES。物理相关性很强，但业务身份依然不同。

每个 vES 必须拥有自己的 vESI。DF 选举以 (vESI, Ethernet Tag) 为粒度，Ethernet Tag 在不同模式下对应 VLAN ID 或 I-SID。这个身份把告警、冗余组与业务实例接起来，使控制面能回答：到底哪一组 PE 有资格重新选出转发者？

检测粒度必须支撑动作粒度

RFC 9784 要求各 EVC 的运行健康应被独立监测。一条 EVC 在共享 ENNI 上失效时，必须为它所属的 vES 触发 DF 选举。

关键不是“看到红灯”，而是保存关联链：哪个监测器观察了哪个 EVC；当时该 EVC 属于哪个 vES；vESI 指向哪个冗余组；哪个业务实例和广播域会受影响。接口仍为 up，不能否认其中一条 EVC 已断；EVC 告警也不能反向证明整只端口已死。

规范据此限制恢复的负面影响。单归属或 All-Active vES 中某条 EVC 的故障与恢复，不得影响同一或其他业务实例里的其他 EVC。Single-Active 情形下，影响必须停留在本业务实例；PBB-EVPN 的 C-MAC 清理也只能覆盖相应 I-SID 和该多归属客户网络的地址。

这意味着验证不能只统计“改了多少”。还要证明哪些健康对象没有被改变。共享程度越高，这份否定性证据越重要。

端口级捷径会制造额外故障

PBB-EVPN 最能显示范围错误的代价。一个 B-MAC 可能代表物理端口上的多项业务。若把传统物理段的 MAC Mobility 处置原样套到单条 EVC 故障，远端 PE 可能清理端口上所有 EVC 的 C-MAC。原本健康的业务必须重新学习地址，恢复消息本身成了中断来源。

RFC 9784 借助 RFC 9541 的 B-MAC/I-SID route 把清理动作缩到业务实例。接收方只对被公告 B-MAC 与 I-SID 的组合清理 C-MAC。一条 EVC 若承载多个 VLAN 和 I-SID，就可能需要多条有边界的消息；若数量很大，也可给每个 vES 分配 B-MAC，再撤回该 vES 的 B-MAC。

不存在一个永远正确的最小单位。一条 EVC 未必只有一个广播域，一只端口也绝不等于一项业务。动作范围要从当时真实的映射得出，而不是从设备外形或命名习惯推断。

真正的端口故障需要集合压缩

当 ENNI 本身失效，它下面的全部 EVC 与 vES 都失去关联路径。此时可以把共同物理原因压缩成一条集合事件。RFC 9784 为此定义可选的 route coloring 与 grouping 机制。

PE 可以给各 vES 路由附上代表物理端口的 color，默认使用端口 MAC，并通过 RFC 9135 的 EVPN Router's MAC Extended Community 传递。接收端据此维护“这个 color 包含哪些 vES”的集合。发送端还可以公告特殊的 Grouping Ethernet A-D per ES route；PBB-EVPN 则可用 Grouping B-MAC route。

端口失败时，撤回 grouping route 可以让其他 PE 一次启动整个受影响集合的 DF 选举与故障切换。随后，每个 vES 的独立撤回仍会到达，用于清理 BGP 状态；若 grouping 撤回已经触发选举，后续逐项撤回不应再次触发同一动作。

这个机制压缩的是表达，不是真相。color 只证明发送方曾把若干 vES 与端口关联；grouping route 只证明一个集合被公告；撤回只证明该发送方撤销了集合。它们不观察物理故障，也不保证每个接收方的成员表都新鲜一致。

这正符合“最小初始规范、未来决策本地化”的原则：共享层只携带协调所必需的关系，接收端仍对本地状态、选举与转发结果负责。

两类撤回不能混成一条日志

分组撤回与逐 vES 撤回虽然都叫 withdrawal，却承担不同工作。前者利用预先维护的成员关系快速启动集合动作；后者把具体路由从表中清除。只保留最终 BGP 表为空的快照，就无法回答快速切换是否发生、是否重复发生，或者过期成员关系是否误伤了别的 vES。

恢复同样有层次。路由重新公告，只说明路径再次可选；DF 选举完成，只说明某台 PE 获得本地转发角色；MAC 更新只说明可达状态改变。客户帧是否通过、是否按预期路径通过、邻近健康业务是否未受扰动，需要另行观察。

运营方至少应保留以下证据：检测器与被检测对象、故障与恢复时间、当时的 EVC—vESI—业务实例—端口 color 映射、各接收端 grouping 成员、选择逐项或分组处置的理由、BGP 消息顺序、DF 与 MAC 状态变化、数据面验证，以及同端口健康业务的旁路验证。

一句“EVPN 已收敛”无法代替这些记录。BGP 会话为绿色，不证明正确业务发生切换；DF 结果正确，不证明远端 MAC 已清；一条 VLAN 的探测成功，也不证明多 I-SID EVC 的所有业务结果。

共享基础设施需要更窄的权力

虚拟化让一个物理对象承载更多独立承诺。它没有让范围判断变得不重要，反而使错误的端口级结论更加危险。物理端口越集中，逻辑身份越需要被保存。

运行代码优先的检验很简单：RFC 9784 证明 IETF 发布了机制；配置记录证明设备被要求使用机制；BGP trace 证明控制消息被交换；设备状态证明本地执行了选举或清理；流量与客户记录才证明业务结果。任何一层都不能借用下一层的权威。

这项标准最有价值的成果，不只是加快收敛，而是让速度服从范围。坏的是一条电路时，不应让整只端口陪葬；坏的是整只端口时，可以用一个集合信号协调多条电路，却仍不能把该信号称为恢复证明。先识别对象，再授予动作半径。

来源

  1. RFC 9784：EVPN 与 PBB-EVPN 的虚拟以太网段
  2. RFC 7432：基于 BGP MPLS 的 Ethernet VPN
  3. RFC 7623：Provider Backbone Bridging 与 EVPN
  4. RFC 8214：EVPN 对 VPWS 的支持
  5. RFC 8584：EVPN DF 选举扩展框架
  6. RFC 7023：以太网连接故障管理
  7. RFC 9135：EVPN 中的集成路由与桥接
  8. RFC 9541：PBB-EVPN 的 B-MAC 与 B-MAC/I-SID 路由
  9. Lu Heng：运行代码优先
  10. Lu Heng：最小初始规范、本地化未来决策与自愿采用
  11. Lu Heng：现实层、符号权力与清晰为何显得敌对