摘要

  • BGP Graceful Restart 允许具备相应能力的邻居在会话重启期间暂时保留路由，但被保留的控制面状态不能单独证明重启路由器仍能转发相关流量。
  • 运营保障应是一份按地址族建立的重启收据，把能力位、保留计时器、实际报文连续性、End-of-RIB 以及陈旧路由的最终处置绑定在一起。

设想一个明确的假想维护窗口。路由器重启 BGP 进程，邻居继续保留从它学到的前缀，路由面板呈现有序恢复，而不是立即撤回。可是某个地址族的流量已经停止。邻居仍选择陈旧路由，直到计时器或后续协议事件将其删除。原本用于遮蔽短暂控制面中断的机制，让数据面故障持续到了保留决策结束。

这并不说明 Graceful Restart 本身存在缺陷，而是说明运营者把两个不同条件合并成了一个。协议协调控制面恢复；安全使用还要求邻居依据陈旧信息转发时，底层转发状态依然有效。

能力通告究竟说明什么

RFC 4724 定义了 Graceful Restart 能力。Restart State 位表示通告方已经重启；针对每个 AFI/SAFI，Forwarding State 位表示该地址族的转发状态是否得到保留。因此，这不是一项覆盖整台设备、所有地址族的笼统承诺。

如果某地址族的转发状态没有保留，RFC 4724 要求接收方删除相应陈旧路由。若通告了状态保留，协助方可以在会话恢复和路由刷新期间暂时保留这些路由。这一区别就是安全边界。

Restart Time 估计重启方重新建立会话所需的时间。协助方还使用本地配置的陈旧路径保留上限。这两个数字都不测量报文是否持续送达，只是限制控制面愿意依赖状态保留声明多久。

End-of-RIB 关闭的是另一个问题

会话恢复后，End-of-RIB 标记说明某地址族的初始路由更新已经结束。得到刷新者成为当前路由，未刷新者可以被移除。它完成的是路由协调，并不能重建标记抵达之前的报文交付事实。

会话恢复、收到 End-of-RIB、流量恢复是三项观察。把它们压成一个“重启成功”状态，就无法判断机制究竟保护了服务，还是仅仅让路由留在表中。

更长保留期意味着更高证明负担

RFC 9494 引入 Long-Lived Graceful Restart，定义了更长的保留期和 LLGR_STALE community，并建议降低这些路由的优先级，以便替代路径胜出。若转发确实能长期保持，这很有价值；若保持已经结束或从未存在，它也会让错误假设持续更久。

问题不在于长计时器必然错误，而在于计时器、选路优先级与替代路径是否有实际平台和拓扑证据支持。一个地址族、线卡或实验环境的证据不能自动覆盖另一个。

NOTIFICATION 不是转发证明

RFC 8538 允许在部分 BGP NOTIFICATION 事件后应用 Graceful Restart 程序。该消息可以说明会话为何结束，以及邻居接下来采用什么程序，却不能证明事件期间报文持续穿过重启设备。没有撤回路由，可能只是协助方按要求执行了保留程序，并非交付结果。

按地址族建立重启收据

每次批准使用时，记录双方邻居、AFI/SAFI、通告能力、Restart State 与 Forwarding State 位、Restart Time、本地陈旧路径上限、LLGR 策略和替代路径。再记录会话丢失、首个成功报文、会话返回、End-of-RIB、陈旧路由最终撤回或刷新的时间。

报文观察必须代表真正重要的路径和服务。环回地址可达，不代表客户前缀或另一张转发表可达；IPv4 成功不能证明 IPv6，某块线卡、FIB、VRF 或服务用户群也不能证明另一个。收据必须对应协助方所保留状态的地址族、平台、表和流量。

来源