摘要

  • Graceful Restart 允许对端暂时保留路由，前提是相关地址族的转发状态仍可用。
  • stale 路由、恢复的会话或 End-of-RIB 都不能证明下一跳、FIB、标签、线卡和报文交付正常。
  • 连续性结论需要一份有期限的联合记录：协商能力、标志位、计时器、保留路由、转发读回和实测流量。

控制面平静，报文却进了黑洞

设想一次控制面重启。helper 保留路由、标记 stale，避免大规模撤回。会话在 Restart Time 内恢复，End-of-RIB 也已到达，路由表看起来很“优雅”。但探测仍失败，因为重启设备没有保留这些路由所依赖的转发项。

这不是 Graceful Restart 理念失效，而是保证范围被扩大了。保留的路由告诉 helper 暂时可以相信什么，却看不到重启节点的线卡、邻接、标签或真实报文路径。

能力声明有条件，也按地址族区分

RFC 4724 定义能力、Restart Time 和每个 AFI/SAFI 的标志。speaker 可以声明某地址族保留转发，也可以不带相关 tuple，仅表明支持 End-of-RIB 或帮助重启对端。因此，“支持 GR”不是统一的转发承诺。

重启方应在可能时保留转发状态并标记 stale；Forwarding State 应反映真实保留。接收方暂留合格路由，若会话超过 Restart Time 就删除；重连后某地址族没有转发状态指示，也须立即删除。计时器只限制相信多久，End-of-RIB 只表示初始更新结束，并不测量报文。

RFC 8538 仅在协商 N bit 时把 GR 扩展到特定 NOTIFICATION 重置，并要求可配置 stale timer。重置原因和协商结果都应进入证据。

控制面重启不是转发资源维护

RFC 6198 明确：GR 适用于控制面重启但转发保持的场景。如果维护会中断链路、线卡或转发资源，应使用 graceful shutdown。对即将停止转发的资源继续保留可达性，反而可能延长丢包。

来源