摘要

  • RFC 3277 的关键问题不是泛泛的“IGP 比 BGP 快”，而是新邻接可能先于重启路由器的新 LSP 传播，使全网把本次启动的边与上次启动留下的节点记录拼在一起。
  • Overload bit 可以暂时撤回中转资格，却不能证明 BGP 路由集合、下一跳解析、FIB 安装或数据包交付已经就绪；清除此位必须依赖属于同一次进程生命的证据链。

RtrB 故障后，RtrA 把前往外部目的地 D.1 的流量切到 RtrC。RtrC 一直在线，已经拥有完整的转发表和从 BGP 学到的外部可达性。片刻后 RtrB 重启，IS-IS 邻接迅速恢复。按 IGP 代价，它又成了更短路径，于是 RtrA 把数据包送回 RtrB。

问题是 RtrB 的 BGP 邻居关系与路由表还没有恢复。它知道怎样与 RtrA、RtrD 建立 IS-IS 邻接，却不知道 D.1 在哪里。控制面的一部分已经成功，另一部分仍为空；数据包在两者之间掉进黑洞。

RFC 3277 于 2002 年 4 月以 Informational RFC 发布。它没有创造新的 IS-IS 字段，而是建议在恢复期间利用已有的 LSP Overload bit：允许路由器继续公布本地连接网络，但让其他路由器暂时不要把它放进中转路径。等 BGP 同步完成，或实现者选择的其他条件满足后，再发布一份清除 overload 的 LSP。

如果故事只到这里，它很容易被缩写成“重启时多等一会”。真正值得保留的是 RFC 对传播顺序的警告。

邻居先替它宣布“回来了”

RtrB 离开网络时，它以前发布的 LSP 仍可能留在其他路由器的链路状态数据库中。RtrB 回来并与 RtrA、RtrD 建立邻接后，两侧邻居会各自生成新 LSP，把这条新邻接告诉全网。此时 RtrB 自己可能仍在同步数据库，尚未发布带有 overload bit 的新 LSP。

于是其他路由器手上出现了一组危险但可计算的材料：RtrA 与 RtrD 的新报文证明新邻接存在，RtrB 的旧报文则描述上一次运行时的节点状态。SPF 并不知道管理者脑中存在“这不是同一轮生命”。只要拓扑图能够连接，它就会把边和节点放在一起。

这里没有一个字段必须是伪造的。邻接确实刚建立；旧 LSP 也确实曾由 RtrB 发出，并且可能尚未自然老化。错误发生在组合层：两条各自真实的记录不属于同一时间与身份边界。

RFC 3277 因此建议，路由器每建立一条邻接，就立刻更新并洪泛自己的 LSP，甚至早于数据库同步开始。目标是让 overload 状态先赶到全网，避免邻居的新邻接把旧 LSP 重新变成可执行的拓扑依据。

这条规则说明发布顺序本身就是控制权。邻接 UP 只能证明当前双方建立了协议关系；旧 LSP 仍有效只能证明一份先前记录尚在。两者都不能单独证明“当前这台路由器已经具有那份旧记录描述的中转能力”。

完整收据至少需要区分启动或重启世代、邻接建立时间、self-originated LSP 的序列与来源世代、新 LSP 的洪泛回执、各节点实际采用的 SPF 输入，以及由此产生的路由选择。仅在日志上看到一个更晚的查询时间，不能把旧对象变成新对象。

本地可达不是中转就绪

最粗暴的做法似乎是发布空 LSP，让网络完全看不见这台路由器。但服务提供商通常以 loopback 地址建立 iBGP 会话。如果连自己的 loopback 和必要邻接都不公布，BGP 恢复本身就失去基础。

Overload bit 提供了更细的状态：节点本身及其本地前缀仍可达，经过它的中转路径暂不成立。它表达的是角色授权，不是总体健康。

这与 RFC 3137 中 OSPF Stub Router Advertisement 的直觉相邻，却不是同一个选题。现有 BTW 稿已经解释 OSPF 通过 MaxLinkMetric 保持自身可达、降低中转偏好以及只有一条路径时的特殊行为。本文不复述高代价与撤回的区别，而只处理 IS-IS 中“新邻接先到、旧自述仍在”的跨世代拼接竞态。

收到带 overload 的 LSP，也不代表所有节点已完成同一轮 SPF，或数据面已经稳定。清除 overload 更只是恢复参与中转计算的资格。它不自动证明 BGP 完整、下一跳已解析、路由已写入硬件、标签动作正确或应用流量已经交付。

数量达标不等于对象齐全

RFC 3277 把具体触发策略留给实现者，并列出两类可能做法：开机后等待 N 秒，或等待 BGP Loc-RIB 中出现 N 条前缀。

时间阈值便于实现，却只证明钟走过了多久。它不知道某个 peer 是否迟到，不知道一个地址族是否没开，不知道路由反射器是否漏了一批路径，也不知道策略是否拒绝了必须存在的基础设施前缀。网络规模扩大或控制面受压后，昨天安全的 90 秒可能变成今天的过早放行。

条目数量比固定时间更贴近 BGP 状态，但仍只是一项基数。故障前有十万条、重启后也有十万条，不代表两边是同一批十万条。默认路由可能消失，某个关键客户前缀可能缺席，另一些无关路由刚好补足计数。Loc-RIB 中存在也不等于下一跳可解析，更不等于 FIB 写入成功。

因此，N 不是坏指标，而是有界指标。若管理者用它清除 overload，就应记录 N 如何得出、哪些必要对象另行核验、允许多大误判、谁承担过早放行的风险，以及观测到矛盾时怎样迅速重新设置 overload。

更强的准备度判断可包含：预期 BGP peer 与地址族、必须存在的默认和基础设施路由、路由集合摘要或版本、下一跳解析、RIB/FIB 对账、接口与标签状态，以及一条受控的跨节点探测。每张网络可选择不同组合，但不能让容易取得的一个数字冒充全部证明。

没有备用路时，保守动作也会伤害可用性

RFC 3277 所述 overload 行为不只是把路径变贵，而是让其他节点不再计算经过该路由器的中转路径。若确有 RtrC 这样的备用路径，这能避免过早回切。若下游只能经过 RtrB，设置 overload 反而可能使网络算不出任何可行路径。

这不是机制失败，而是安全目标冲突。拒绝未经证明的中转状态，有时意味着暂时没有服务；接受唯一但准备度不明的路径，则可能把数据包送入黑洞。决策不能隐藏在通用模板里，必须显式记录当前拓扑、替代路径、业务容忍度与批准者。

即使图上有备用边，也还要核实其容量、故障独立性、策略与当前转发状态。RFC 示例假设 RtrC 长期在线且拥有完整 FIB；真实网络中的“备用”可能在容量上只够保护一部分业务。

兼容性同样不能从认证报文推断。RFC 警告，域内设备若未正确实现 overload 语义，可能形成转发环路。路由认证可以证明谁发出了某个位，却不能证明每个实现都以相同方式解析、计算并安装结果。

RFC 8706 把“上一轮生命”写进协议动作

2008 年的 RFC 5306 标准化了 IS-IS restart signaling；2020 年的 RFC 8706 取代它，并更清楚地区分 restart 与 start。前者假定转发状态跨越控制面重启而保留，后者表示转发状态并未保留。

这种区分不能靠措辞装饰。若没有保留数据面，却把自己宣告为可以维持转发的 planned restart，邻居可能继续把流量交给一台无法兑现拓扑承诺的设备。RFC 8706 明确要求不能这样做。

对于 starting router，上一轮生命留下的 LSP 还可能因为新进程的序列号重新初始化而显得“更新”。这使 2002 年问题的身份维度更加明确：单调序列在一次进程生命内有意义，跨越重启却未必能表示现实先后。

RFC 8706 的 SA bit 提供另一种排序控制。starting router 可以要求邻居暂缓公布与它的邻接。邻居在收到 SA 清除的 IIH 前，不得把该邻接写进自己的 LSP，也不能在自身 SPF 中使用它。旧方案强调让带 overload 的新自述尽快追上；新机制可以先扣住那条会激活旧自述的边。

这并不证明所有生产设备都支持 SA，也不证明混合版本环境自然安全。它提供的是更明确的协议工具与可核查状态，具体实现、配置、定时器和故障行为仍需现场验证。

快速恢复不是一张总收据

BGP Graceful Restart 可以在控制面恢复期间保留某些转发状态；IP Fast Reroute 可以在本地检测故障后快速使用修复路径；ordered FIB convergence 可以控制拓扑变化后的更新顺序。这些机制都可能减少中断。

它们回答的问题不同。BGP 保留标志不能证明 IS-IS LSP 属于当前世代；快速绕行不能证明回归节点的外部路由齐全；有序 FIB 也不能把缺失的路由安装出来。把多种恢复功能同时打开，不会自动生成端到端正确性。

审计应分别保留 Restart TLV、overload 状态、BGP route retention、SPF 结果、RIB、FIB 读回与探测结果。它们可以连接，不能互相替代。

Heng Lu 的窄共同层原则在这里很具体：标准可定义一个最小而确定的中转资格信号，却不应让它吸收本地完整性、硬件执行和服务结果的全部权威。运行状态优先，也不是只看最终一张表；而是追踪这张表由哪一代控制对象、哪些本地决策和哪些可验证动作产生。

真正可辩护的链条是：本次启动身份、转发状态是否保留、邻接建立、新 self-LSP 生成与序列、全网接收、overload 解释、IS-IS 同步、BGP peer 与必要路由集合、下一跳解析、FIB 安装、有限放行、数据包观测、服务结果与回滚。

路由器“回来了”只是一项事实。它是否有权重新承载中转，是另一项需要当前证据回答的问题。

不确定性

本文分析的是标准文本，不是某次具名事故或当前厂商实现调查。RFC 3277 提到该技术曾用于若干大型 IS-IS 网络，但没有给出名称、配置、流量或测量结果，不能据此推断今天的部署率。RFC 8706 支持度、混合实现、触发策略、硬件写表与备用容量都必须在具体环境中验证。本文不声称任何确定的丢包规模或性能收益。

来源