BGP Graceful Restart 后保留陈旧路由：Stale Path、EoR 与黑洞排查
BGP 邻居重启后很快恢复 Established，但业务仍有短时黑洞；路由表里还能看到带 stale 标记的前缀，或者对端已经恢复却迟迟不删除旧路径。这类现象常与 Graceful Restart（GR）的控制平面恢复和实际转发状态不一致有关。GR 的目标是在 BGP 进程重启时暂时保留路由，不代表数据平面一定可用，也不保证所有地址族会同时恢复。
本文目录（16 节）
先判断是正常保留还是故障
记录会话中断、重新建立、收到 End-of-RIB（EoR）以及 stale 路由删除的准确时间。同步采集本地 RIB、FIB、下一跳解析、接口状态和真实流量测试。如果 stale 路由仍在 FIB 中且下一跳能够转发，短暂保留可能符合设计；如果控制面保留路径而重启设备已经丢失转发表，就会把流量继续送往不可用路径，形成黑洞。
不要只用邻居状态判断恢复。Established 只说明 BGP 会话和 OPEN 协商完成，不证明所有 AFI/SAFI 的路由更新、策略计算和硬件下发已经结束。
GR 的角色与基本时序
RFC 4724 将参与者分为重启方与协助方。会话终止后，协助方可把此前从该邻居学到、属于已协商地址族的路由标记为 stale 并暂时保留。重启方重新建立会话、重发路由，并对每个地址族发送 EoR；协助方收到该地址族的 EoR 后，删除仍未被重新通告的 stale 路由。
如果重启方未在 Restart Time 内恢复，会话协助方应删除保留路由。若重新建立后的能力中没有相应 AFI/SAFI，或 Forwarding State 位表明转发状态没有保留，协助方也应立即清除相关 stale 路由，而不是继续等待。
检查能力协商而非只看配置
分别查看两端实际协商出的 GR capability，包括 Restart State、Restart Time、每个 AFI/SAFI 的 Forwarding State 位，以及是否支持 RFC 8538 定义的 Notification 位。配置文件里启用 GR 不等于邻居已经协商成功；中间升级、邻居组继承或地址族激活差异都可能改变结果。
重点比较故障前后的 OPEN 能力。若 IPv4 unicast 协商了 GR，而 EVPN 或 IPv6 未协商，相同会话重启时各地址族的处理可以不同。不要把一个地址族成功收到 EoR 当成整条会话全部收敛。
Forwarding State 位为何关键
Forwarding State（F）位表示重启方是否为对应 AFI/SAFI 保留了转发状态。协助方据此决定能否安全继续使用旧路由。设备进程热重启时可能保留硬件 FIB，但整机断电、线路板重启、接口 flap 或某些软件升级往往不能满足这个假设。
如果设备错误宣告保留转发状态，或者运维只看到 GR enabled 就假定 FIB 存活，协助方会继续向它转发，黑洞会持续到新路由生效、EoR 到达或计时器到期。因此必须用平台实际状态和报文能力验证，不能仅凭功能名称推断。
EoR 没到或到得太早
EoR 是每个地址族更新完成的边界信号。迟迟收不到 EoR 时，协助方可能继续保留未刷新的 stale 路由；过早发送 EoR，则可能在重启方仍未完成路由恢复时提前删除可用路径。
检查重启方的 RIB 恢复、策略加载、路由反射、标签分配和更新队列是否阻塞。对端查看每个 AFI/SAFI 的 EoR 接收时间与 stale 数量变化。多跳、路由反射器和大量前缀场景要逐跳核对，不能用最外层会话的 EoR 推断内部节点已完成。
Restart Time 与 stale-path 时间
Restart Time 是重启方在能力中告知的恢复窗口。实现还可能提供 stalepath-time 等本地上限，用来约束 stale 路径可保留多久。FRRouting 文档中默认 restart-time 为 120 秒，并提供 stale-path 相关计时配置；实际值应以运行版本和邻居状态为准。
把计时器调得很大不能修复慢恢复，反而会延长黑洞或错误路由的生命周期。值过小则可能在控制面正常恢复前撤销大量路由，引发额外收敛。应根据可测量的 RIB 加载、FIB 下发和更新完成时间设定，并保留故障上限。
LLGR 会让保留时间更长
RFC 9494 的 Long-Lived Graceful Restart（LLGR）允许在普通 GR 窗口之后继续保留路由，并为其施加 LLGR_STALE 社区。总体保留时间由普通重启窗口和 Long-Lived Stale Time 共同决定。标记 NO_LLGR 的路由不应进入长期保留。
看到 stale 路由存在数十分钟甚至更久时，要检查是否协商 LLGR、该地址族的长期计时值、策略是否正确降低 LLGR_STALE 路径优先级，以及路由是否带 NO_LLGR。不要误把 LLGR 的预期行为当成清理进程失效。
NOTIFICATION 与管理重置
传统 GR 主要围绕 TCP 会话中断。RFC 8538 通过 N 位扩展了对 NOTIFICATION 和 Hold Timer Expired 等场景的处理，但双方必须协商该能力。某些管理重置应明确要求硬重置，避免把配置错误、认证错误或策略变更误当成可优雅恢复的进程故障。
采集通知码、子码和发送方向。若一端不支持 N 位，收到 NOTIFICATION 后的保留行为可能与普通链路断开不同。升级前后能力变化也可能解释为什么同一种重置在两个版本上表现不同。
排查 RIB、FIB 与下一跳
对一个受影响前缀建立完整链路：邻居 Adj-RIB-In 中是否 stale，策略后是否仍为 best path，主 RIB 是否选中，FIB 是否安装，递归下一跳是否可达，出接口与邻接项是否有效。随后用受控探测确认真实数据面路径。
若 RIB 有路由而 FIB 无条目，问题在下发或资源层；若 FIB 有条目但下一跳邻接失效，检查链路、ARP/ND、隧道和标签；若只有部分前缀失败，比较地址族、策略、下一跳和路由来源。这样可避免把所有流量问题归因于 BGP 邻居。
BFD 与 GR 的目标冲突
BFD 希望快速发现转发故障，GR 则在控制面中断时保留路径。若 BFD 已确认数据路径不可用，却仍允许 stale BGP 路由继续转发，快速检测的价值会被抵消。核对平台如何联动 BFD、GR helper 与路由撤销，并确认链路故障和进程重启是否采用不同策略。
在冗余路径充足的网络中，宁可快速切换也不一定需要长时间保留 stale 路由；在全表重载昂贵的路由反射器场景，GR 价值更高。策略应按角色和地址族设计，而不是全网复制同一计时器。
连续重启与多厂商差异
重启方在上一轮恢复尚未完成时再次重启，会让 stale 路由生命周期和计时逻辑更复杂。检查实现是否刷新、继承或终止原计时器，并验证第二次会话建立时的 Restart State。反复重启通常应先稳定进程，而不是继续延长 helper 时间。
多厂商环境要以协商报文和运行状态为准。不同平台对会话级与地址族级清理、通知重置、EoR 展示、LLGR 策略和默认计时值可能不同。测试记录应包含软件版本和配置上下文，不能只记录命令输出标签。
建议的故障定位顺序
- 确认影响前缀、地址族、时间窗口和流量方向。
- 对齐两端会话事件、通知原因、GR 能力与计时器。
- 检查重启方是否真的保留对应地址族的转发状态。
- 记录每个 AFI/SAFI 的 EoR 与 stale 路由数量变化。
- 对样本前缀逐层验证 Adj-RIB-In、RIB、FIB、下一跳和数据面。
- 检查 BFD、接口、隧道、标签及路由反射链路。
- 判断普通 GR 还是 LLGR 正在保留路由。
- 在维护窗口用受控重启复现并校准策略。
修复原则
根因是转发状态无法保留时，应纠正能力宣告或禁止该角色使用 helper 保留，而不是隐藏黑洞。根因是路由恢复或 EoR 过慢时，应优化状态恢复、策略计算和更新队列，并根据实测时间调整窗口。根因是 LLGR 策略缺失时，应降低长期 stale 路由优先级，并为不适合长期保留的前缀使用明确策略。
变更应先在单一邻居和单一地址族验证，再扩大范围。测试至少覆盖进程重启、整机重启、接口故障、BFD 失败、管理重置和连续重启，并同时验收控制面与业务流量。
常见问题
邻居已经 Established，为什么路由仍显示 stale？
会话建立不等于该地址族已完成更新。协助方通常要等相应 AFI/SAFI 的新通告与 EoR，才会删除没有被刷新的 stale 路由。检查 EoR、更新队列和地址族能力。
直接关闭 Graceful Restart 能解决黑洞吗？
可能缩短错误路径保留，但会让控制面重启造成完整撤路和重新收敛。应先确认转发状态是否真实保留、是否存在替代路径，再按设备角色和地址族调整。
Restart Time 越长越安全吗？
不是。较长窗口给慢恢复更多时间，也会让不可用的 stale 路径存在更久。计时应依据实测恢复时间、冗余能力和可接受中断上限设定。
为什么只有 IPv6 或 EVPN 出现问题？
GR 能力和 Forwarding State 按 AFI/SAFI 表达，各地址族的恢复、EoR 和 FIB 依赖也不同。逐个地址族检查协商与数据面，不能从 IPv4 成功推断其他地址族成功。
如何确认是 LLGR 在保留路由？
查看双方是否协商 LLGR、Long-Lived Stale Time、路由社区和平台 stale 状态。普通 GR 窗口结束后仍保留且带 LLGR_STALE，是重要线索；同时检查 NO_LLGR 策略。
总结
BGP GR 故障的核心不是“为什么旧路由没有立即删除”，而是旧路由保留期间数据面是否真的可用。用能力协商、F 位、逐地址族 EoR、普通与长期计时器解释控制面，再用 RIB、FIB、下一跳和真实流量验证转发面，才能在减少重启抖动与避免长期黑洞之间取得可靠平衡。