摘要

  • RFC 9764 把承载 BFD PDU 的传输层负载扩充到配置的尺寸，填充内容必须为零；使用 IPv4 时还必须设置 Don't Fragment。会话处于 Up，因而能够持续说明这类 BFD 控制包最近以该尺寸通过。
  • 这份证据只属于实际发送方向与实际经历的转发处理。若要说明双向能力，双方都必须配置；若路径包含 LAG 或 ECMP，一个健康成员也可能让 BFD 保持 Up，同时其他成员仍在丢弃大包。
  • pdu-size 是可能影响多个客户端的共享控制项。提高它可以让已处于 Up 的会话转为 Down；在触发自动动作之前，必须区分真实 MTU 限制、对端不支持、过滤、攻击和成员差异。

传统 BFD 擅长回答一个很窄的问题：两端是否持续收到足以维持会话的控制包。问题在于，这些包通常很小。小包顺利通过，并不代表依赖较大数据报的业务也能通过。路由控制面可以一片绿色，应用却在固定尺寸以上反复超时。

RFC 9764 没有重新发明路径 MTU 发现。它采取更克制的办法：让现有 BFD 异步模式持续发送被扩大的传输层负载，把“至少能承载这个尺寸”加入会话的生存条件。

规范引入 bfd.PaddedPduSize。额外字节必须全部为零，接收端不应把这些字节当成新的内容字段去验证。在 IPv4 中，Don't Fragment 必须置位。这样，一个原本过大的报文不能靠网络分片变成若干小片，悄悄绕过尺寸测试。

机制很短。真正困难的是，组织是否肯让结论也保持同样短。

Up 只说明下限，不说明最大值

BFD 的基础状态机仍来自 RFC 5880。RFC 9764 没有改变 BFD 控制头的意义，而是改变外层传输负载的长度。接收端若不再接受这些大包，状态机看到的就是控制包未到达，并按原有检测规则转变状态。

假设配置值为 1512 字节。Up 可以支持这样一句话：在当前配置与最近观测中，这股 BFD 流量以 1512 字节到达了对端。它不能支持“路径 MTU 恰好是 1512”。路径也许能承载更大报文，只是探测从未询问。若路径容量后来上升，会话也不会为了宣布新增容量而改变。

这与经典机制的目标不同。RFC 1191 把 Path MTU 绑定到具体路径，并让发送端依据受限的“报文过大”反馈降低估计。RFC 8899 则为数据报传输提供分组层探测框架。RFC 9764 的任务不是搜索最大可用尺寸，而是不断复核一个由使用者选择的最低需求。

因此，pdu-size 不应机械复制本地接口 MTU。9000 字节接口只说明本地一段的能力，不说明多跳路径，也不说明应用真的需要 9000。选得过高，会把不必要的压力变成可用性风险；选得过低，会让会话保持绿色，却无法代表最需要这份证据的应用。

“双向”仍需要两个方向的配置

BFD 名称中的“双向”不能替代逐方向证据。RFC 9764 明确指出：若应用需要验证两个方向的指定 Path MTU，双方都要设置 PaddedPduSize。

A 发往 B 的大控制包，说明 B 最近收到过该尺寸；它没有发送一份关于 B 到 A 的证明。现实网络可能存在非对称路由、不同隧道封装、不同队列、不同过滤策略，甚至有意配置不同的 MTU。准确做法不是把一条 Up 状态复制成两条结论，而是分别保留发送端、接收端、尺寸、时间与配置代次。

RFC 5881 描述单跳 BFD。在直接连接场景，接口 MTU 往往已经提供较强的本地保证。RFC 5883 描述多跳 BFD；此时首跳接口能力无法代表后续所有链路，正向路径也不必等于反向路径。大包 BFD 在这里更有用，证据的边界也更容易被忽略。

控制台可以把两个方向汇总为一个方便阅读的状态，但证据库不能因此删除方向。汇总是展示；方向性是事实。

最大请求者决定共享会话的风险

同一对端之间的 BFD 会话可能被多个客户端复用。一个客户端需要 1400 字节，另一个需要 1600 字节。RFC 9764 建议实现选择其中最大的 PaddedPduSize。若选择较小值，会话虽然 Up，较大需求却仍未被满足。

这条合理规则带来一个容易被忽略的控制关系：提出最大尺寸的客户端，实际上改变了所有共享者观察到的会话条件。新客户端加入时，即使老客户端只需要小包，也可能因为更大的探测包无法到达而收到 Down，并启动路由撤回或保护切换。

所以变更记录不能只有最终数值。它至少要写明谁提出需求、哪些客户端共享状态、旧值与新值、双方能力、Down 会触发什么，以及如何回退。否则，一个局部应用需求会通过共享会话放大成全局控制动作。

若对端只能处理普通尺寸的 BFD，启用大包之后也会表现为未收到控制包。真实的窄路径与不兼容的解析器可能产生完全相同的状态。变更本身不仅“发现问题”，也可能创造问题。

同一个 Down 可以对应多种因果链

RFC 9764 利用“传输层负载可以大于内部 BFD PDU”这一空间。旧实现可能拒绝这种外层长度，也可能在验证时错误地把它当成畸形包。中间设备可能按尺寸或协议过滤。路径上的攻击者也可能选择性丢弃 BFD 包，使会话转为 Down。

零填充解决的是另一件事：避免把未初始化的本地内存带上网络。它并不为故障原因背书。

因此要把三层话语分开。第一层是观测：“指定尺寸的 BFD 包没有继续维持会话。”第二层是诊断：“现有证据更支持某种原因。”第三层才是授权：“因此执行某项路由或服务动作。”从第一层直接跳到第三层，等于让状态机代替风险所有者做决定。

双端抓包、接收计数、较小尺寸对照、过滤日志与业务 canary 能缩小范围。它们仍然只是逐步构成证据，不应被一个漂亮的标签压扁。

ECMP 会把故障留在探测流之外

LAG 与 ECMP 把多条物理或逻辑成员包装成一条上层路径。哈希可能让 BFD 控制流稳定落在健康成员上，而客户流量落在 MTU 更小的成员上。于是 BFD Up 与业务失败可以同时为真。

RFC 7130 为 LAG 成员提供 BFD 机制，但 RFC 9764 也明确提醒：多跳 ECMP 没有一套已标准化的通用 BFD 方法可以覆盖每个成员。一些实现会利用内部转发表知识改善覆盖，这属于实现特性，不能从标准编号自动推导。

正确的表述不是“探测无用”，而是“探测描述了自己实际走过的转发处理”。它没有测试所有熵值、所有隧道选择或所有成员。成员 MTU 不一致时，Path MTU 会成为与流相关的属性。

BTW 对 RFC 9978 的既有文章讨论了 BFD 丢包计数：控制包缺失是稳定性信号，却不等于已证明的数据面或客户损失。本文拥有另一条边界：大控制包通过，不等于所有大业务包通过。

YANG 中的一个可写值也需要权责链

ietf-bfd-large 模块扩展 RFC 9314 的 BFD 模型，并遵循 RFC 8342 的 NMDA 架构。它在单跳、多跳、LAG 和 MPLS 会话结构中加入 padding 能力与可写的 pdu-size。

配置库里出现这个叶子节点，只能证明某处记录了意图。还要核对操作状态、软件版本、对端能力、客户端请求、实际报文与生效时间。RFC 特别警告，在已经 Up 的会话上改变数值，可能让会话转为 Down，并影响依赖它的多个客户端。

RFC 7880 给出 S-BFD 基础，RFC 9764 说明本机制也可用于该类场景。可复用并不表示所有模式共享同一证据范围。每一种模式仍需记录自己的端点、方向、封装与转发路径。

周期性降低陈旧程度，却不覆盖未来

RFC 9869 通过 UDP Options 的 REQ/RES 令牌确认特定探测包。其既有 BTW 文章强调：一次确认不能证明未来任意数据报。RFC 9764 的改进在于周期性，尺寸条件随 BFD 不断重测。

但下一个业务包可能使用另一组 ECMP 熵、另一层封装或另一条队列。周期性缩短观测年龄，并没有把样本变成全集。

一个可审计的状态应包含时间和范围：“在本配置代次下，本方向最近以 X 字节大包维持 Up。”这句话允许未来证据推翻它。“网络支持 X 字节”则隐藏了测试主体与未覆盖部分。

来源与证据边界

冻结来源包括主规范 RFC 9764，BFD 基础 RFC 5880、RFC 5881、RFC 5883、RFC 7130 与 RFC 7880，管理模型 RFC 9314 与 RFC 8342，以及尺寸证据上下文 RFC 1191、RFC 8899、RFC 9869 和 RFC 9978。

治理方法来自 Heng Lu 关于最小初始规范、运行代码优先与现实层和符号权力的论述：共享层只负责一个可本地验证的小事实，未来动作仍由承担后果的运营者决定。