摘要

  • RFC 9521 让会话身份在时间上发生一次切换：远端判别符为零时，以 VNI 和 VAP 内层地址寻找会话；判别符非零后，只能用该判别符解复用。
  • Up 只证明这条受限控制会话完成了连续性交换，不证明探针与每条租户流量同路同待遇，也不证明压缩后的会话覆盖所有 VAP 对或应用已经恢复。

假设两个网络虚拟化边缘各有十个 VAP。理论上，它们可能形成一百条配对会话；为了避免过载，运营者只运行十条，让每个 VAP 至少出现一次。十条全绿，这是一项有效观测。把它描述成“一百种组合全部健康”，则是凭空扩张。

会话在启动后换了一把钥匙

RFC 9521 把异步 BFD 放在 VAP 上。VAP 平时承载以太网，就用内层 Ethernet/IP/UDP/BFD；平时承载 IP，就用内层 IP/UDP/BFD。两端必须映射到同一个 VNI，并采用同一种数据封装。

启动阶段，Your Discriminator 可以为零。以太网负载下，接收端应以 VNI、源/目的 MAC 和源/目的 IP 识别会话；IP 负载下，则以 VNI 和两端 IP 识别。内层 UDP 源端口可以辅助。如果仍找不到会话，报文必须丢弃，并应向管理面报告异常。

一旦判别符非零，规则变了：RFC 9521 要求只用判别符解复用。这个切换决定了审计记录必须保留什么。只留最终判别符，会丢失它最初绑定的 VAP/VNI 上下文；只留地址，则看不见重启后的判别符复用。可靠证据必须把启动元组、切换报文、配置代次和重启边界串在一起。

VNI 确定范围，不授予权力

接收端还要检查 Geneve 报文、VNI 与目的 VAP 映射、协议类型、UDP 目的端口以及 TTL 或 Hop Limit。O 位为一，C 位为零。任何检查失败，报文都不能进入 BFD 状态机。

这些规则能防止报文进入错误会话，却不能证明对端拥有某个租户、获得了代表客户的授权，或有权触发流量切换。Geneve 没有内建安全机制，RFC 9521 因而建议使用 BFD 认证。认证能加强“持有约定密钥的一方发出了报文”这一判断，不能自动授权它关闭事故、改变生产策略或宣布 SLA 达标。

从 N² 压到 N，改变的是观测面

RFC 9521 明确指出，会话数量可能按 N² 增长，并建议设置上限；只要所有 VAP 都受到覆盖，N 条会话也可以采用。这不是缺陷，而是一项可管理的规模取舍。问题在于，覆盖政策必须公开：哪些配对被选中，哪些未被观测，某条探针为何能够代表某组流量。

同一个 VNI 内，探针与数据仍可能走不同 ECMP 成员、LAG 链路、队列、ACL 或服务链。探针 Up 而部分租户流失败并不矛盾；探针因自身队列拥塞而 Down，而应用暂时正常，也不矛盾。

这正是速率要求重要的原因。除非 BFD 真正具有拥塞控制，否则 Geneve BFD 必须运行在流量受控的环境中，并预先配置发送速率，以免拥塞和误判。没有速率配置、队列状态与丢包上下文，Down 是快速症状，不是故障部件的身份证。

七张收据，七个不同问题

完整证据链至少包括：VAP/VNI 映射与配置代次；零判别符阶段的启动元组；切换到本地和远端判别符的记录；探针实际路径与待遇；VAP 清单、配对矩阵与覆盖缺口；状态变化后获得授权且实际执行的动作；以及代表性租户流和应用结果。

规范只负责其中一段，恰恰体现了工程克制。运行代码产生可靠事实的前提，是结论不超过机制。仪表盘可以写“此 BFD 会话 Up”，却不能在缺少后续收据时把主语删除，改成“Geneve 服务健康”。

来源