摘要

  • RFC 9494 让 GR 之后的陈旧路由按 AFI/SAFI 获得第二段寿命，但对端宣告的 LLST 只是一个可接受或收紧的时间建议，不是转发仍然有效的证明。
  • 合理的 LLGR 运维必须把能力协商、实际接受的时限、社区属性、选路与传播范围，逐层对应到 next hop、FIB、数据包和明确的退出动作。

设想一个用于说明机制的故障。某条 BGP 会话消失，普通 Graceful Restart 的等待期已经结束，但接收方又把一条更具体路由保存六小时。系统把它标成陈旧并降到最低优先级。网络里同时存在一条新鲜但更宽的汇总路由。对落入那个更具体前缀的流量来说，最长前缀匹配仍可能把数据包送向陈旧路径。路由表里还有答案，终点却已经不再回答。

这不一定是软件错误，也不要求报文格式异常。RFC 9494 设计的正是这种延长保留：当控制面恢复缓慢，或 BGP 承载的状态更接近分布式配置时，立即撤回可能造成不必要的抖动和重建成本。但当对象是常规可达性，同一机制也能把黑洞、环路或过期服务绑定保留得更久。

因此，关键问题不是设备界面上是否显示“支持 LLGR”。关键问题是：谁有权让昨天的状态在今天继续产生转发后果，谁限制这段寿命，以及哪一种现场证据可以在计时器到期之前终止它。

LLGR 接在 GR 之后，但不是同一个风险阶段

RFC 4724 定义 BGP Graceful Restart。能力码 64 携带 Restart Time 和按地址族表达的转发状态。会话中断后，接收方可以暂存重启方此前发布的路由。对端重新建立控制状态后，End-of-RIB 标记说明某个 AFI/SAFI 的初始更新已经发送完毕。

触发会话重置的原因也属于证据。RFC 8538 引入 N 位：双方交换这一能力后，许多 NOTIFICATION 和 Hold Time 到期可以进入优雅重启语义。带 Hard Reset 子码的 Cease 则要求完整终止。只记录“邻居掉线”，会丢失究竟允许保留还是要求清空的决定边界。

RFC 9494 新增能力码 71。每个能力条目包括 AFI、SAFI、标志位和 24 位 Long-Lived Stale Time。LLST 以秒计，标准没有规定统一默认值，因为普通 IP 可达性、Route Target 约束、FlowSpec 或发现状态的安全寿命并不相同。

LLGR 不能脱离 GR 独立成立。若收到 LLGR 能力却没有同时收到 GR 能力，接收方必须忽略 LLGR。它复用 GR 的 EoR、状态机和连接重置逻辑。因此，一个“能力 71 已协商”的截图，若没有能力 64、具体地址族和双方参数，仍不足以证明这次保留有效。

两个阶段可以串行运行。第一阶段是普通 GR，路由不会仅因 GR 而自动降低偏好；第二阶段是 LLGR，保留路由必须进入最低偏好。会话尚未恢复时，协议层面的最长保留边界是收到的 Restart Time 与 LLST 之和，再受本地上限或下限约束。

任一阶段都可以为零。本地可以把对端提出的 LLST 缩短。对端提供的是一项时间预算，真正制造本地后果的是接收方的接受和执行。把宣告值直接称为“生效时限”，等于掩盖了运营者自身的决定。

最低偏好不是自动撤回

进入 LLGR 后，helper 为相关 AFI/SAFI 启动计时，并在保留路由上附加 LLGR_STALE。IANA 登记的值是 0xFFFF0006，也就是 65535:6。任何非最低偏好的候选都必须胜过 LLGR stale 路由；若只剩多个最低偏好候选，再使用正常决胜规则。

降级可以让新鲜替代路径胜出，却不能凭空产生替代路径。若陈旧路由仍是某个精确前缀的唯一候选，它仍可能成为 best path。即使存在一条新鲜的更宽前缀，数据面也可能继续选择已经安装的陈旧更具体路由。RFC 9494 明确警告，这会让覆盖范围内的目的地址失去连通性。

逐跳转发的 iBGP 核心还会遇到一致性风险。不同路由器观察的是各自的会话状态。一个节点可能已经把路径降为 stale，另一个节点仍把同一路由视为新鲜。它们可能选择不同出口，并相互转发数据包。RFC 9494 给出了这类环路，并不建议对这种逐跳路由集合启用 LLGR。

隧道化核心能限制某一类逐跳环路，却不能替终端服务作证。RFC 4271 的可解析性要求仍然成立：陈旧路由的 next hop 必须继续可解析。RFC 9494 提到，在合适场景可以用 BFD 补充判断 next hop 是否仍在，但 BFD 只证明一个有限检测边界，不证明应用或整个服务链可用。

所以，LLGR 的作用是推迟撤回，不是给路由重新颁发真实性。它不认证来源，不证明前缀授权，不确认硬件已经编程，也不保证数据包到达能够处理它的服务。

两个社区值表达保留与拒绝

RFC 9494 定义的另一个知名社区是 NO_LLGR，IANA 值为 0xFFFF0007，即 65535:7。携带该值的路由不得进入长期保留。它可以由宣告者附加，也可以由接收方策略根据路由性质增加。

这是拒绝长期保留的通道，不是密码学签名。RFC 1997 把 Communities 定义为路径属性，其数值本身不认证写入者。中间策略可能保留、替换或删除社区。审计必须同时保存每个关键边界的 received 和 advertised 属性，以及真正执行了什么策略。

传播范围同样有限。LLGR stale 路由不应发送给没有宣告 LLGR 能力的邻居。这个规则把过期状态限制在能够理解最低偏好语义的范围内。它也说明，本地保留一条路由与把它继续发布给别人，是两项不同权限。

RFC 9494 为渐进部署保留了窄例外：可以把陈旧路由发给不支持 LLGR 的 iBGP 或联邦内部邻居，但必须附加 NO_EXPORT，并把 LOCAL_PREF 设为零。整个 AS 应一致处理这个零值。这里要保护的不是标签美观，而是选择一致性；不同节点按不同尺度降级，可能形成环路。

会话恢复后，旧债仍在计时

LLGR 的 F 位按地址族说明上次重启时相关状态是否实际保存。它不是“邻居健康”总开关。如果重建后的会话没有列出该 AFI/SAFI、没有设置对应 F 位，或没有再携带所需的 GR 与 LLGR 能力，helper 必须立即删除该地址族的陈旧路由。

反复掉线不能任意刷新保留额度。除非人工干预，正在运行的 LLST 不得在对端完成新会话建立和同步之前更新。同步也是逐 AFI/SAFI 的：收到该地址族 EoR，或 GR 的 Selection_Deferral_Timer 到期，才构成同步边界。

即使会话已经重新 Established，LLST 仍继续走到 EoR。若它在同步期间到期，对端尚未重新宣告的陈旧路由必须删除。因此，绿色会话可以与正在缩小的 stale 集合同时存在。应该核对的不是“邻居是否回来”，而是“每条被保留的路由是否在期限内重新出现”。

EoR 只关闭某个地址族的初始更新阶段，不证明数据面恢复。一条重新宣告的路由仍可能无法解析 next hop、没有进入 FIB、引用了失效标签，或指向已经离线的应用。控制面完成与服务成功是两种证据。

有些 BGP 状态更像配置，而不是下一跳承诺

BGP 还承载 Route Target 约束、FlowSpec、发现信息和 VPN 控制状态。这些对象的重建可能很慢；立即撤回会制造大量抖动，甚至删除仍然有意义的分布式配置。对这类状态，较长保留期可能是理性选择。

标准仍要求按 AFI/SAFI 显式启用，并禁止默认开启。这一要求非常重要：LLGR 不是抽象的“高可用功能”，而是对特定状态寿命作出的例外决定。状态的意义、转发模型和所有依赖的安全期限都必须相容。

依赖有时不是 IP next hop，而是 MPLS 标签。陈旧 VPN 路由可能继续引用一个已经撤销的标签。若出口 PE 在所有入口停止使用旧路由之前，把该标签分配给另一个 VPN，风险会从可用性升级为隔离破坏。RFC 9494 要求标签复用的最短等待大于 LLST 的最大上限。

Cisco、Juniper 和 Nokia 的当前文档也证明不能只写“按 RFC 配置”。Cisco 区分发送与接受的 stale time，并描述 BGP persistence 的阶段；Juniper 分开 receiver、restarter、地址族、策略排除和人工清除；Nokia 展示 SR OS 的支持族和可观察状态。不同产品的默认行为与范围不能互相代替。

一段陈旧寿命需要哪些凭证

第一层是协商。保存双方 OPEN，或具备权威性的邻居输出，列出 GR、LLGR、AFI/SAFI、Restart Time、LLST、N 位与 F 位。把对端宣告值和本地接受上限并列保存。它们有不同作者，也承担不同后果。

第二层是进入阶段。保存重置原因、子码和时间，标出 GR 结束与 LLGR 开始。逐路由记录 LLGR_STALE 的附加、NO_LLGR 的存在或策略添加、选路结果和传播边界。只看到一个社区值，并不能证明它改变了选择或阻止了发布。

第三层是数据面。保存递归解析、实际安装的 FIB 或服务状态，以及陈旧期间的数据包或应用探测。VPN 场景还要保存标签、封装和复用边界。Loc-RIB 的 best path 只是控制面意图，不是交付结果。

第四层是退出。记录 EoR、LLST 到期或人工 clear，并列出所有未刷新路由的删除。服务恢复时证明干净的重新宣告；服务未恢复时证明撤回到达关键节点。缩短计时和执行回滚的人必须在故障之前已经被授权。

来源