摘要

  • BFD 为一条明确的数据协议路径提供快速存活检测；会话含义绑定于端点、封装和协商参数。
  • Up 状态并不证明所有 ECMP 成员、地址族、路由、MTU 或应用业务都经过同一条健康路径。
  • 服务可达结论需要联合回执：BFD 会话与定时器、RIB/FIB、成员覆盖、双向业务尺寸探测和真实应用交易。

绿色会话旁边的黑洞流量

设想一次维护刚结束，路由邻接全部恢复，客户下一跳的监控框显示 BFD Up，于是变更被关闭。几分钟后，大文件传输仍然卡住。小型控制报文被散列到链路组中的健康成员，而部分生产流量落到另一个转发表或 MTU 处理异常的成员。

BFD 没有说谎，错误来自扩大证据的适用范围。绿色状态属于一条具体会话及其报文实际经过的路径。“服务可达”则是更大的命题，还涉及路由选择、全部相关转发成员、两个方向、真实报文尺寸以及应用本身。

RFC 5880 给 BFD 的任务非常精确：低开销、低时延地发现两个转发引擎之间双向路径上的故障，包括接口、数据链路，并尽可能覆盖转发引擎。它独立于介质和路由协议。正因如此，BFD 可以快速服务于多种客户端；也正因如此，运维必须记录是哪一个客户端、哪一条路径在消费这个状态。

BFD 不负责发现会话。应用决定是否需要它，并提供地址和参数。每条通信路径、每种数据协议都应有对应会话。物理链路、虚电路、隧道、MPLS LSP 和多跳路径都能承载 BFD，但结果的含义始终绑定在所用封装和路径上。

Up 究竟记录了什么

异步模式下，两端周期发送 BFD Control 报文；连续缺失达到协商门限后，会话转为 Down。Demand 模式可以停止周期控制报文，因为系统假定另有连通性验证手段，需要时再用 Poll 序列显式核验。Echo 功能则让远端经其转发路径环回探测报文。

这些模式提供的证据并不相同。Echo 可能发现纯控制交换遗漏的某些转发故障；Demand 依赖独立验证。BFD 若运行在控制引擎，可能与路由进程共命运；C 位只说明远端实现是否宣称独立于控制平面。若数据库只保留 Up，解释状态所需的关键上下文就丢失了。

定时器同样是证据的一部分。期望发送间隔、要求接收间隔和检测倍数共同决定异步模式的故障判定时间。10:00 的 Up 只说明当时的状态机尚未按这些参数宣布失败；它既不保证 10:00:01，也不证明客户端协议已经实施预期的路由动作。

RFC 5881 把单跳 IPv4/IPv6 场景的范围写得更清楚：会话绑定远端系统、接口和协议。同一链路上的 IPv4 与 IPv6 需要独立会话；多条会话只有确实穿越不同网络层路径时，才增加路径多样性证据。

该文档把 BFD 定义为网络服务的连接检查与验证 OAM 机制，同时明确普通 BFD 不适合直接充当互联网应用到应用的故障检测器。BFD 报文抵达邻居，并不等于用户的 DNS 查询、下单或文件传输已经完成。

客户端决定信号的后果

RFC 5882 将 BFD 定位为咨询信号。路由协议等客户端接收状态，再使用自己的机制改变邻接、拓扑或转发。BFD 不携带应用专用信息。Down 可以促使客户端更快撤路，但具体动作仍属于客户端。

就连事件历史也可能经过处理。实现可以通过迟滞向客户端隐藏快速的 Up/Down/Up；AdminDown 表达管理意图，本身不代表数据路径故障。因此当前状态、转换历史、通知策略以及客户端实际动作必须分别记录。

ECMP 可能让 BFD 与用户流量走不同成员；小控制报文能通过的地方，业务尺寸报文可能被 MTU 问题丢弃；回程可以独立失败；路由可存在于 RIB 却没有预期 FIB 项；网络成功交付后，应用仍可能拒绝请求。单个绿色格子不能回答这些问题。

来源