摘要

  • RFC 5286 的普通 LFA 是按目的、按候选邻居、按预期故障计算出来的结果；全局开关为真，完全可能与某些目的没有合格备选同时成立。
  • 可审计的保护记录必须带上拓扑时代、距离操作数、前缀来源、保护类型、候选拒绝原因和转发表安装状态。只保存一个绿色状态，会把设计责任推迟到故障时才暴露。

交接单上缺失的一行

架构团队交付一张表：一百台路由器，LFA 启用率百分之百。运维团队真正需要的却是另一张表：每个关键目的经哪个主下一跳转发，保护哪个资源，哪些邻居参加过计算，谁通过了哪项测试，谁被拒绝，以及备选是否进入转发表。

两张表回答不同问题。前者说明功能可用，后者说明保护是否存在。把前者当作后者，就在组织交接时丢掉了最重要的一层事实。

RFC 5286 对计算路由器 S、候选邻居 N 和目的 D 给出基本无环条件：

Distance_opt(N,D) < Distance_opt(N,S) + Distance_opt(S,D)

这是严格小于。假设左侧为 20，右侧由 7 加 13 也等于 20，候选不合格。S 无法据此排除 N 的最短路经由 S 返回。把小于号看成小于等于，并不是显示方式不同，而是把没有完成的证明当成已经完成。

若一次度量调整让左侧变成 19，候选才在新的拓扑时代通过。邻居的名字没有变，结论却变了。这说明 LFA 不是接口的永久属性，而是带输入、时间和范围的派生事实。

每个目的都要有自己的答案

RFC 5286 的目标是在分布式路由收敛完成前，利用预计算的下一跳减少丢包。主下一跳失效后，本地路由器可以临时切到备选；新 SPF 安装后，再离开修复状态。计算备选并不会修改正常的主 SPF 结果。

但备选是按目的计算的。同一个邻居可能对前缀 A 合格，对前缀 B 不合格。多归属前缀还会引入多个来源和前缀成本。RFC 8518 更新了 RFC 5286 的相关处理，明确细化多归属和 OSPF 外部前缀的候选规则。只看路由器之间的距离，可能遗漏决定某个前缀结果的来源和路由类型。

因此，“覆盖率”必须先定义分母。是链路、节点、前缀、主下一跳、目的类别，还是流量？如果剩余的百分之二恰好承载最关键业务，百分之九十八并不代表风险很小。数字还要说明保护类型和故障模型，否则链路保护会被误读成节点保护，局部 SRLG 避让会被误读成所有相关风险都已绕开。

RFC 6571 讨论拓扑对普通 LFA 可用性的影响。RFC 7490 之所以引入远端 LFA，正是因为某些拓扑——尤其环形结构——常常找不到合格的物理邻居。这不是普通 LFA 失败的丑闻，而是图结构给出的正常答案。

无环、下游和节点保护是三种结论

通过基本不等式，只能证明候选在所建模的链路故障情形下不会把流量直接送回 S。RFC 5286 还定义更严格的下游条件：

Distance_opt(N,D) < Distance_opt(S,D)

候选必须比 S 更接近目的。这样可以在某些超出预期的故障中降低临时环路风险，但也会删除更多候选。安全边界变强，覆盖可能变低；有时正确动作是丢弃，而不是使用一个无法证明安全的备选。

节点保护又多一层要求：候选路径必须避开主邻居 E。如果 N 有等价路径，其中一条经过 E、另一条不经过，S 无法控制 N 最终选择哪条。RFC 5286 不允许把“存在一条好的等价路径”直接提升为节点保护证明。

广播或 NBMA 网络还要处理 IGP 伪节点。同一个广播段可能同时承载去往主邻居和候选邻居的路径；避开主节点不一定避开故障链路。局部 SRLG 进一步把共享端口、线卡或其他相关故障纳入候选排除。若导出记录只写 N = LFA，这些区别全部消失。

保护结果还必须携带故障假设。为单链路失败计算的备选，并不自动覆盖主节点消失、多个资源同时失败或未建模的相关故障。现实范围一旦大于计算范围，微环或丢包仍可能出现。

从计算到转发，中间还有四次交接

更完整的状态链是：

已配置 -> 计算合格 -> 策略选中 -> 已安装 -> 已激活 -> 已转发 -> 已收敛

“计算合格”要能回放拓扑版本和不等式。“策略选中”要说明为什么在多个候选中选择这个邻居。“已安装”需要转发表或硬件回读。“已激活”需要把故障检测事件和状态转换关联起来。“已转发”要有计数器或路径观测。“已收敛”则说明临时修复何时退出。

BFD 可以提供故障检测证据，却不能替代候选资格、安装或转发证据。相反，即使计算结果正确，也可能因硬件资源、编程失败或策略冲突而未进入 FIB。每一步的所有者和修复动作都不同。

一条可复核记录至少应包含：计算路由器、区域或层级、LSDB 版本或摘要、计算时间、目的前缀、路由类型、全部相关来源、主下一跳、保护资源、候选邻居、三个基本距离、每项附加测试、保护类型、拒绝原因、选择策略和安装代次。

还要记录计算粒度。RFC 7916 区分按前缀与更粗的计算方式，并把模拟、激活粒度、策略和覆盖监测放进运维框架。按下一跳汇总比较省事，却可能遮住一个来源特殊的前缀。按前缀计算更透明，但必须能导出并比较结果。

不应宣称的内容

这些标准没有证明任何具名运营商使用了 LFA，也没有证明某个产品实现正确、某个网络覆盖率达到多少或收敛用了多久。不等式失败不等于缺陷；它可能正是当前图上的正确结果。不等式通过也不等于候选已选择、已安装或已激活。

远端 LFA、TI-LFA、Segment Routing 和 RSVP-TE FRR 都有自己的前提。没有配置和状态证据时，不能把它们当作默默补位的后备方案。面对普通 LFA 的空结果，诚实的表述是“在此拓扑、策略和故障模型下没有合格备选”。

本文也不重复既有 RFC 9855 文章关于“本地修复不等于业务恢复”的论点。这里追问的是更早的一步：这个普通邻居是否曾得到为该目的承担修复的数学授权？