摘要

  • RFC 5880 把 BFD 定义为一种与具体协议无关的双向转发路径故障检测机制，检测时延可以很低。
  • 这个信号不是路由选择策略：应用负责建立和使用会话，而更激进的定时器会带来报文、处理能力和误判成本。

信号很窄，后果很广

BFD 观察两个转发引擎之间的双向路径。RFC 5880 说明，这条路径可以包括接口、数据链路，并在可能时覆盖转发引擎本身。它有意与承载介质、被转发的数据协议，以及消费状态的路由协议相互独立。

范围狭窄正是它的价值所在。路由协议不必总是等自己的 Hello 或失效定时器超时，才得知实际转发路径已经断开；服务也能使用同一底层状态。但 BFD 不决定移动哪个前缀、选择哪个下一跳，也不决定是否拆除邻接。它报告状态，策略权仍属于客户端。

RFC 5882 把边界说得很清楚：对应用而言，BFD 的用途是核验一对系统之间、特定数据协议经特定路径的连通性。它不用于直接证明控制协议本身是否健康。Down 状态可以成为路由动作的理由，却不能证明所有控制进程都已失败，也不能证明某条备选路径一定安全。

建立会话是一项授权决定

BFD 没有发现机制。应用必须提供远端地址和建立会话所需的其他参数。因此覆盖范围来自配置，而不是自动推断：一条从未绑定会话的路径，不会因为设备其他位置运行了 BFD 就受到保护。

RFC 5882 还要求，多个客户端如果监测同一数据协议的同一路径，应共享一个 BFD 会话。这个状态因而成为共同依赖。必须有人决定哪些应用可以使用它、会话代表哪个地址族和路径，以及状态变化如何传入不同控制系统。

单跳规则让这些边界更加具体。RFC 5881 要求：如果同一路径同时监测 IPv4 和 IPv6，两者必须使用不同会话；收到的单跳 Control 报文还必须具有 255 的 TTL 或 Hop Limit，以把接收范围限制在直连对等方。认证可以保护 Control 报文，但部署和密钥管理仍是运营责任。

兼容性规则同样重要。若认为邻居不支持 BFD，RFC 5882 指出，不应仅因 BFD 不可用就阻止控制协议邻接。BFD 是附加的故障信号，不是让基本连通性依赖一个对方不支持功能的授权。

检测时间要用容量购买

在 Asynchronous 模式下，两端周期性发送 Control 报文；如果检测窗口内没有收到协商数量的报文，会话就进入 Down。Demand 模式在会话 Up 后可以停止周期发送，但前提是另有机制独立核验连通性。可选的 Echo 功能则让远端转发面把测试报文环回，以检验转发路径。

更短的间隔不会带来免费的确定性。RFC 5881 要求妥善配置发送速率，避免压垮链路、输入队列或报文处理器。若监测本身造成过载，延迟到达的 BFD 报文可能被当作故障证据，而这个故障又部分由监测负荷制造。快速定时器可以缩短真实黑洞，也可能把瞬时拥塞放大为撤路或服务抖动。

RFC 7419 定义了一组通用间隔，减少实现之间的互操作风险。但它解决的是间隔协商，不是容量决策。两台设备都支持某个数值，不代表它适合所有会话规模、队列设计、故障域和恢复策略。

Up 不等于稳定

只要检测窗口内收到足够的 Control 报文，基础 BFD 状态机就会保持 Up；窗口内的零星丢包未必改变状态。以 Experimental 身份发布的 RFC 9978，通过逐包递增的序号和 YANG 模型，增加了统计缺失 BFD Control 报文的方法，试图在会话尚未 Down 前显露劣化。

这项扩展有明确限制：它测量的是 BFD 报文丢失，不是用户数据丢失或时延。ECMP 和链路聚合可能造成乱序；若实现不作处理，简单比较序号就会把乱序误判为丢失。该证据可以引导进一步的 OAM 检查，但不能单独定位根因。

证据与限制

RFC 5880、5881 和 5882 分别界定基础机制、单跳约束和应用关系；RFC 7419 统一常用间隔；RFC 9978 增加实验性稳定性测量。

这些来源没有给出适用于所有平台的安全定时器、当前部署普及率或厂商性能保证。BFD 状态也不能直接识别根因，更不会选择应当保留的路由。

来源