摘要

  • 防火墙高可用升级后，Router B 连续 121 秒没有 BGP 前缀；会话状态仍为 Established，流量仍指向防火墙。
  • 演讲者的抓包和实验复现把延迟追到 IPv6 邻居上下文解析错误与 TCP Reset；IPv6 的 End-of-RIB 等待也拖住了 IPv4 路由安装。

Established 看起来让人放心。路由表给出的回答更直接：121 秒内，零个前缀。

这是 Marian Rychtecký 在 NANOG 98 讲述的故障。升级一对防火墙的高可用配置时，BGP 会话重新显示 Established，Router B 却没有收到任何前缀。流量依旧被转向防火墙，而防火墙尚未安装预期路由。结果是数据包被黑洞吞掉，持续近两分钟。

关键数字是 121 秒。End-of-RIB 在接近 120 秒的重连计时器时才到达，但计时器只是线索，并非全部原因。Rychtecký 的排查发现，IPv4 恢复正在等待一条特定的 IPv6 BGP 会话。只要协商过的邻居状态尚未收到 End-of-RIB 标记，Graceful Restart 就没有完成。一个地址族的会话卡住，另一个地址族的路由也被拖住。

抓包显示，新会话收到 TCP Reset。实验室复现中，预期的 IPv6 邻居地址 2001:db8:1::2 被存成 2001:db8:1:。操作系统无法把连接匹配到正确的 VRF 与 BGP 上下文，于是返回 Reset。切换期间，旧 TCP 连接的一段时间仍被视为活跃，新连接撞上了陈旧状态。

这份记录指出的并不只是“Graceful Restart 也会失败”。BGP 会话为绿色，不等于路由表里有路由；控制平面显示恢复，也不等于转发恢复。防火墙升级是触发点，邻居上下文误解析和跨地址族等待构成故障机制，空 RIB 与黑洞流量才是用户实际承受的结果。

演讲者说，在这次故障中，缩短连接计时器加快了重连和 End-of-RIB 交换。这是特定场景下的临时办法，不是通用配置：缩短一种等待，也可能制造另一种故障窗口。可靠的变更验证应覆盖整条链路：TCP 重连、各地址族的 End-of-RIB、路由安装，以及数据包是否真正送达。

演讲材料没有列出设备型号、固件版本或客户流量损失测量；这些记录才能判断这是单一实现缺陷，还是多个部署都存在的模式。

来源