摘要

  • RFC 9612 为 MPLS LSP echo 请求增加 BFD Reverse Path TLV，使入口端可以要求对端沿指定反向 FEC 发送 BFD Control 报文。它明确了请求，不会自动明确故障方向。
  • 返回码 193 与仍然存活的 BFD 会话可以同时为真：指定反向路径没有找到，但出口端的本地策略允许改走其他 IP 路径。拒绝、实际路径和服务结果必须分别留证。
  • 完整证据链应连接正向 LSP、反向 FEC、TLV 响应、真实回程、BFD 结果、Reply Path 核验、重定向、操作员通知和应用交付。

值班台先收到一条 BFD Down。屏幕上挂着正向 LSP 的名字，于是故障单也自动写成“正向路径中断”。这个名称看起来合理，却比测量结果多说了一层。BFD 报文要完成去程与回程；没有回来，只能证明这次闭环没有在期限内完成，不能单凭沉默指出是哪一段失效。

反向 FEC 可能在维护中被改写，出口端可能无法找到入口端指定的回程，回程本身可能故障，或者出口端可能按照本地策略切到普通 IP 路由。正向 LSP 当然也可能真的坏了。问题不在于缺少候选原因，而在于快速告警没有足够信息排除其中任何一个。

RFC 9612 是 Experimental 文档。它扩展 MPLS LSP echo 请求，增加 BFD Reverse Path TLV，让入口端向出口端说明 BFD Control 报文应当使用哪个反向 LSP 或 FEC。于是，“我想监控哪条回程”第一次成为双方都能解析、应答、替换和撤销的协议事实。

这个扩展最有价值的地方，不是替操作员做完归因，而是把共同事实缩到足够清楚。双方共享最小请求与错误码；出口端仍保留本地回退政策；运行中的转发表、报文和服务结果负责证明最后发生了什么。这正是最小初始规范与本地未来决策的边界。

往返可用不等于方向已知

RFC 5880 定义 BFD 的快速故障检测机制。RFC 5884 把它用于 MPLS LSP 时，报文可以沿被测 LSP 前进，再按 IP 路由返回。这足以观察端点间是否还能形成控制闭环，却不足以证明正向 LSP 单独健康。

RFC 9612 的 Reverse Path TLV 类型值为 16384，可以包含零个或多个允许的、非组播 Target FEC Stack 子 TLV。组播 FEC 不适合这里的返回路径语义，收到后应返回代码 192。默认最多 128 个子 TLV，目的是限制膨胀请求造成的查询和资源消耗，而不是鼓励一次填满 128 项。

指定反向路径后，实验条件确实更清楚：入口端知道自己请求了什么，出口端也必须明确回答。但 BFD Down 仍然是闭环结果。指定路径可能在建立后改变，FEC 解析可能漂移，出口端的真实转发也可能与控制面想象不一致。快速检测提供时间，不提供完整因果关系。

把告警直接命名为“正向 LSP 故障”，会让假设变成历史记录。排障人员随后只看正向设备，自动化也可能绕开并未损坏的资源。正确状态应当是“BFD 闭环中断，方向待核验”。保留不确定性并非拖延，而是拒绝伪造不存在的证据。

193 和绿色状态可以同时成立

如果出口端找不到请求中指定的反向路径，它必须返回代码 193。这个代码只证明一件事：所请求的反向路径没有找到。它不等于“所有 BFD 服务都不可用”，也不等于“应用已经中断”。

本地配置可以允许出口端改用另一条路径，例如普通 IP 回程。在这种情况下，193 是真的，BFD Up 也是真的。前者说明共同意图未实现，后者说明另一种控制闭环仍可工作。把 193 因为绿色图标而抹掉，是把回退可用误写成合规；把绿色状态因为 193 而忽略，则是把精准拒绝误写成全面宕机。

至少要保存四个独立状态：指定反向路径是否找到、本地回退是否启用、BFD 会话是否存活、用户服务是否交付。它们可以形成多种组合。一条 IP 回退可能维持控制会话，却破坏原本要求的物理分离；控制会话也可能中断，而应用已经切到其他服务路径。

空的 Reverse Path TLV 也有明确含义：撤销先前选择的反向路径，把发送方式交还本地策略，通常回到 RFC 5884 的 IP 回程。若此前已经设置反向路径，后来 LSP ping 仍带 BFD Discriminator TLV、却不带 Reverse Path TLV，出口端也应恢复按照本地策略周期发送。缺少 TLV 不是空白，而是一项需要记录的状态变化。

快检测会先于慢解释到达

FEC 不是永远静止的标签。控制面重收敛、维护或策略变化都可能让同一个描述解析到不同回程。RFC 9612 因而要求会话建立之后仍能改变反向路径，不能只在启动时理解一次。

发生故障后，入口端必须使用 LSP ping 的 Reply Path TLV 核验反向 FEC 是否仍然有效。如果 FEC 已变，就必须用另一个 FEC 重定向 BFD 会话，并通知操作员。核验、重定向和通知是三个连续收据，任何一个都不能被“自动恢复成功”吞掉。

这里有两只不同速度的钟。BFD Control 报文频率很高，目标就是尽早检测。控制面和数据面的 Reply Path 核验频率明显更低。反向 FEC 变化时，告警先来、解释后到，是时序模型的自然结果，不是监控系统偶然失灵。

计划维护可以提前换路，减少部分告警。但它无法预知所有变化，也不能保证慢核验每次都抢在快检测之前。成熟系统应把这段间隔显式显示为“故障已检测、原因待确认”，并测量从告警到核验、重定向和通知分别用了多久。

请求不等于远程控制权

入口端可以在协议中指定它希望使用的反向 FEC，却不能因此接管出口端的本地策略。出口端决定是否允许 IP 回退、接受多少子 TLV、为查询分配多少资源。这种本地决定权让协议保持轻量，也让不同网络可以采用共同机制而不被迫拥有同一套运营政策。

本地决定必须可见。若出口端静默回退，入口端会误以为自己仍在监控指定的双向结构。自由选择回退是合理权限；把回退伪装成请求已满足，则破坏了协议产生的证据价值。

安全限制也说明了同一原则。无上限的 FEC 列表可能成为资源放大手段，因此规范设置 128 项的默认边界，实施者还可以更严格。组播 FEC 通过 192 得到精准拒绝。明确拒绝让双方知道边界在哪里，而不是依靠模糊失败猜测。

Experimental 也只应在它所属的层解释：这是文档类别和实验成熟度，不是产品实现清单，不是现网部署证明，更不是 Standards Track 身份。设备是否支持、路径是否真的按要求走、运维是否保留了回退记录，都要靠运行证据回答。

为故障建立完整保管链

故障之前就应记录正向 LSP、请求的反向 FEC、实际发送的 TLV、出口端的接受或错误码，以及 BFD 报文真实走过的路径。只有这样，告警到来时才有基线可比。

故障之后，证据链加入 Reply Path 结果、当前 FEC 解析、新的候选 FEC、重定向时间和操作员通知。最后必须检查应用边界的交付、丢包和时延。BFD 证明的是控制交换，不是最终业务订单、会话或内容已经送达。

产品测试不能只跑成功场景。先指定有效回程并抓包；再在会话存活时改变 FEC；请求不存在的路径，分别观察允许和禁止回退时的 193；提交组播 FEC 得到 192；发送空 TLV；随后保留判别符但省略反向 TLV；最后超过配置上限，确认资源消耗被有限拒绝。

每一步都要比较管理 API、控制面、转发表和报文捕获。软件可能报告选择成功，硬件却仍走旧路；设备也可能已经回退，管理模型却没有字段。只有多个现实层相互吻合，才能说路径身份得到证明。

最有用的事故结论不是简单红绿，而是：“请求的反向 FEC 消失；出口端返回 193；BFD 通过 IP 回退继续；应用交付未中断；Reply Path 找到替代 FEC；会话完成重定向，操作员已收到通知。”每句话都能被独立验证，也能被未来审计。

来源