摘要

  • RFC 9494 可让 BGP 路由在普通 Graceful Restart 时限结束后继续保留，但只适用于双方协商的 AFI/SAFI 和有限的 Long-Lived Stale Time；路由必须带上 LLGR_STALE，并成为最不优先的选择。
  • Enke Chen 同时参与撰写 RFC 4724 与 RFC 9494。后者没有证明旧路径仍然有效，而是通过 NO_LLGR、接收方本地时限、End-of-RIB 同步和明确的转发风险，让借来的连续性可以被拒绝、检查和终止。

两只时钟从会话故障开始走

路由器发现 BGP 会话中断时，面对的并不是一个单一事实。第一只时钟属于控制平面：邻居不再发送消息，新的可达性信息也无法到达。第二只时钟属于转发平面：上一刻写入硬件的下一跳、隧道或标签状态，可能仍能把数据包送到目的地。这两只时钟并不必然在同一秒归零。

立即撤回全部路由，是把控制通道故障当成转发故障；无限保留，则是把过去的状态当成永远有效。普通 Graceful Restart 给这种不确定性留出一个较短的恢复窗口。Long-Lived Graceful Restart 处理的是更难的问题：如果窗口结束，但旧状态仍可能有用，网络应如何继续使用，同时不把它伪装成新事实？

这并非只关乎传统互联网路由。在隧道化网络中，控制进程重启时，独立的转发状态可能继续工作。BGP 还承载 VPN 发现、信令或接近配置的数据，其生命周期未必等同于一条逐跳转发路径。过早删除可能扩大中断；延迟删除则可能延长黑洞、环路或隔离失效。

普通优雅重启的短窗口

RFC 4724 于 2007 年发布，作者为 Srihari Sangli、Enke Chen、Ramachandra Fernando、John Scudder 与 Yakov Rekhter。它定义了 BGP Graceful Restart capability 和 End-of-RIB 标记。重启方可以在控制进程恢复期间保留转发状态；接收方可以把来自该邻居的路由标为 stale，暂不立即删除。

这份标准没有把宽限期设计成无限承诺。Restart Time 字段只有 12 位，编码上限为 4,095 秒；建议默认值不超过 BGP OPEN 中的 HOLDTIME。会话在期限内没有重新建立，接收方必须删除保留路由。如果通过 BFD 或链路信息等证据判断对方转发已经失效，也可以提前删除。

普通 GR 期间，stale 路由不会因为陈旧而降低选路优先级。这样能减少一次短暂重启触发的大规模 churn，但代价是网络仍可能偏好一个暂时没有控制来源的路径。RFC 8538 后来扩展了可进入优雅流程的会话故障情形，并增加 Hard Reset 信号；它没有改变“宽限必须有边界”这一基本纪律。

第二阶段不是延长原时钟

RFC 9494 于 2023 年 11 月发布，署名作者是 James Uttaro、Enke Chen、Bruno Decraene 与 John G. Scudder。它建立的 LLGR 不是简单把 RFC 4724 的 4,095 秒放大，而是引入第二种状态。Enke Chen 在两份 RFC 中的署名，证明的是他在 IETF 集体成果中的连续贡献，不是个人发明或对实现的独占解释权。

LLGR capability code 为 71，内容由一个或多个 <AFI, SAFI, Flags, LLST> 组成。不同地址族可以有不同的 Long-Lived Stale Time。标准刻意不给出推荐默认值，因为 VPN、隧道、普通单播和控制型数据承受的风险不同。接收方可以对对端宣告的 LLST 设置本地上限、下限，或直接缩短它。

LLGR 也不能脱离普通 GR 单独宣告。如果邻居没有同时提供 Graceful Restart capability，接收方必须忽略 LLGR。两者都启用时，普通 GR 先运行，期间路由不降权；它结束后才进入 LLGR。运营者若不需要第一阶段，可把 Restart Time 设为零，使陈旧状态立即显形。

这一区分很重要。短暂恢复期保留“旧状态很快会被新状态替换”的假设；长时间保留则必须承认，证据已经变弱。一个更长的计时器，不能仅靠持续安静来获得与新路由相同的地位。

LLGR_STALE 是降级声明

进入 LLGR 阶段时，helper 针对每个已协商的 AFI/SAFI 启动 LLST 计时器，并给保留路由附加 well-known community LLGR_STALE，数值为 0xFFFF0006。选路时，它必须低于所有没有被标为 least preferred 的路由。只有候选全部同为最低优先级时，普通 tie-break 才继续发挥作用。

因此，LLGR 的价值不是“路由不消失”，而是“旧路由只作为最后选择”。新鲜替代路径出现，应立即胜过它；没有替代路径时，它仍可能成为 best path 并承载流量。网络得到的是一个可撤销的机会，而不是路径健康证明。

降级信息还必须随路由传播。除 RFC 9494 为内部 BGP 或联盟成员给出的有限例外外，speaker 不应把 LLGR_STALE 路由发给未宣告 LLGR 能力的邻居；继续传播时也不得删除该 community。否则，上游已知的怀疑，会在下游被洗成普通可达性。

与“保留”相对应，标准还定义 NO_LLGR，数值为 0xFFFF0007。带有该 community 的路由不得进入长期保留流程，必须按普通 BGP 规则删除。发送方可以标记不适合长期存活的信息，接收方也可用本地策略施加同样的拒绝。共同能力不等于强制接受。

会话回来，不等于证据刷新

重新建立 TCP/BGP 会话只是恢复了沟通渠道。对某个 AFI/SAFI 而言，路由是否重新同步，要看 End-of-RIB 或 selection-deferral 边界。LLST 计时器不会因为“邻居又上线了”就自动获得新寿命。如果计时在同步完成前到期，尚未被新通告刷新的陈旧路由必须删除。

连续重启也不能轻易重置证据年龄。此前已被标记 stale 的状态，不应因为又一次会话波动而反复领取完整期限。返回的邻居若不再提供所需的 GR/LLGR 能力、遗漏地址族，或没有给出要求的转发状态信号，helper 也必须清理相关路由。

RFC 9494 的示例把状态转换写得很清楚：普通 Restart Time 为 1 秒，LLST 为 3,600 秒。第一秒结束后，路由获得 LLGR_STALE 并降权；若没有替代路径，边界路由器仍可使用它，并向具备 LLGR 能力的外部 peer 重新通告。3,600 秒到期，路由被删除并撤回。若 180 秒后完成同步，刷新的路由移除 stale 标记。外部 peer 没有宣告能力，则在 LLGR 开始时就收到 withdrawal。

降权挡不住最长前缀

风险首先来自两个不同的选择层。BGP 在同一前缀的路径之间比较偏好，而 IP 转发先选择最长匹配前缀。一条陈旧的 more-specific 即使已被降到最低 BGP 优先级，仍可能压过一条新鲜但范围更宽的 less-specific。于是控制平面看见“已经降权”，数据包却继续进入失效的更具体路径。

第二类风险来自路由器之间的认知不一致。RFC 9494 描述了一种内部拓扑：一台路由器在原出口变成 least preferred 后转向另一出口，邻居却仍偏好原出口，两者可能互相转发同一批数据包。普通 GR 也可能短暂暴露类似问题；LLGR 将错误寿命从分钟延长到小时甚至更久。

因此，RFC 给出的核心规则非常严厉：如果一组路由在 AS 内用于逐跳转发，不建议启用 LLGR。MPLS 等隧道化转发，或与普通下一跳关系较远的 BGP 信息，风险可能较低，但仍需逐个地址族验证。Forwarding State/F bit 不能被当作礼貌声明，必须对应实际保留的状态。

VPN 还存在标签复用风险。旧 VPN 路由携带的标签被撤回后，可能分配给新的上下文；若陈旧路由仍在网络中传播，流量可能带着旧含义进入新对象。标准建议：启用某 VPN 地址族的 LLGR 前，标签复用的最短等待必须大于 LLST 的最大上限。时间边界在这里直接成为隔离边界。

共同规则只定义“陈旧如何被看见”

Lu Heng 的最小初始规范、本地未来决策与自愿采用提供了一个后来的分析框架。共同层只需精确定义能力协商、地址族范围、降级标记、拒绝标记、最低优先级和确定性到期。是否启用、接受多长时间、哪些转发模式合适、何时提前撤回，应由承担风险的运营者决定。

这种分工同时拒绝两种越界。RFC 不能替每个网络命令“必须保留”；本地策略也不能删除 LLGR_STALE，把陈旧状态重新包装成新鲜事实。共享语义负责让状态可识别，实际网络负责选择是否承受它。

运行代码优先进一步要求，配置已开启、会话已恢复都不是充分证据。运营者应看到实际协商的 AFI/SAFI、对端时限与本地裁剪后的时限、进入和退出 LLGR 的路由数量、选路变化、向不具备能力的 peer 的撤回、End-of-RIB 进度、丢包与环路信号，以及最终清理。这是 Sofia Ren 运用 Lu Heng 后来提出的原则，不是把这些观点追溯为 Chen 或 RFC 作者的原意。

RFC 9494 最诚实之处，是没有给被保留的路由换一个更体面的名字。它仍然是 stale。标准允许网络借用过去的转发状态，却要求旧证据公开降级、接受拒绝、服从计时并最终退出。连续性只有在不冒充真相时，才值得被保留。

来源