在我们的环境中，我们通常在任何地方都有 ASR-1000X-2 通过 iBGP/eBGP 对等互连。这些路由器没有冗余 RP，因此在路由器重新启动或崩溃时无法继续转发流量。因此，这是路由器仅具有 NSF 感知（或优雅重启感知）但没有能力的一个明显示例。

我启用此功能的原因是，来自 RFC 4724：

此外，即使说话者没有能力在 BGP 重启期间为任何地址族保留其转发状态，仍然建议说话者向其对等方通告 Graceful Restart Capability（如前所述，这是通过不包括广告功能中的任何内容）。这样做有两个原因。第一个是指示其在其初始路由更新完成后生成 End-of-RIB 标记的意图，因为这样做通常对路由收敛很有用。第二个是表明它对希望执行正常重启的对等点的支持。

所以我希望在“show ip bgp neighbor”命令中看到的关于优雅重启的内容将类似于以下内容：

BGP neighbor is <IP>,  remote AS <AS>, internal link
[...]
  Neighbor capabilities:
[...]
    Graceful Restart Capability: advertised and received
      Remote Restart timer is 120 seconds
      Address families advertised by peer:
        none

基本上，GR 是协商的，但没有指定地址族，有效地仅使用 EOR 标记来改进路由收敛。

相反，这是路由器指定的内容：

BGP neighbor is <IP>,  remote AS <AS>, internal link
[...]
  Neighbor capabilities:
[...]
    Graceful Restart Capability: advertised and received
      Remote Restart timer is 120 seconds
      Address families advertised by peer:
        IPv4 Unicast (was not preserved, VPNv4 Unicast (was not preserved

我的假设是括号中的“未保留”是指邻居最近重新启动，这意味着当邻居重新建立 BGP 连接时，IPv4 和 VPNv4 AFI 的 GR 能力没有设置“转发位”由 GR-RFC 指定：

一旦会话重新建立，如果新接收的平滑重启能力中没有设置特定地址族的“转发状态”位，或者新接收的平滑重启能力中不包含特定地址族，或者在重新建立的会话中根本没有收到 Graceful Restart Capability，那么 Receiving Speaker 必须立即从对等方中删除它为该地址族保留的所有陈旧路由。

显然，由于硬件限制，这种类型的路由器永远不会设置转发状态位。不过，这是我的担忧：当路由器重新启动时会发生什么，并且由于 GR 功能确实指定了 IPv4 和 VPNv4 AFI/SAFI，相邻路由器继续将数据包转发到该路由器？这显然会造成影响，因为交通将成为黑洞。

我将尝试模拟它并查看它的行为，我会报告回来，但是您拥有的任何信息将不胜感激。

编辑：

所以我做了一些测试。我在两个路由器之间进行了数据包捕获。他们都已经有一个 BGP 会话正在进行，所以我只是从一侧 (7.0.0.1) 硬清除了会话。另一端 7.0.0.2 首先发送一个 OPEN 消息，其中包含以下 GR 能力信息：

Capability: Graceful Restart capability
    Type: Graceful Restart capability (64)
    Length: 6
    Restart Timers: 0x0078
        0... .... .... .... = Restart: No
        .... 0000 0111 1000 = Time: 120
    AFI: IPv4 (1)
    SAFI: Unicast (1)
    Flag: 0x00
        0... .... = Preserve forwarding state: No

注意 IPv4 的 AFI/SAFI，根据 RFC，这意味着此路由器支持此 AF 的 GR。

这是来自另一端的 GR 能力信息，我从 (7.0.0.1) 重置 BGP 对等互连：

Capability: Graceful Restart capability
    Type: Graceful Restart capability (64)
    Length: 6
    Restart Timers: 0x8078, Restart
        1... .... .... .... = Restart: Yes
        .... 0000 0111 1000 = Time: 120
    AFI: IPv4 (1)
    SAFI: Unicast (1)
    Flag: 0x00
        0... .... = Preserve forwarding state: No

这里要注意的一个有趣的事情是该路由器设置了重启位，即使它在技术上没有整体重启。我认为这很有用，因为：

当设置（值为 1）时，该位表示 BGP 扬声器已重新启动，并且其对等方在向扬声器通告路由信息之前不得等待来自扬声器的 End-of-RIB 标记。

因此，它允许相邻对等方立即向该路由器发送更新，因为 BGP 重新启动，而无需等待 EOR 数据包。

无论如何，当我真正重新启动其中一台路由器时，通过诱发崩溃，GR 显然不起作用。这 2 个路由器通过环回具有 iBGP 对等互连，因此当环回不可达时，由于“next-hop-self”和下一跳不再可达，因此不会使用该邻居的路由。很明显，我无法访问重新启动的邻居正在通告的路由，即使 RFC 明确指出：

当 Receiving Speaker 检测到与已通告 Graceful Restart Capability 的对等方的 BGP 会话的 TCP 会话终止时，它必须保留从对等方收到的所有地址族的路由，这些路由先前在 Graceful Restart Capability 中收到，并且必须将它们标记为陈旧的路由信息。

所以路由应该被简单地标记为“陈旧”但仍然可用。

所以我认为该软件要么有错误，要么就是不遵循 RFC。只要我们只有这种类型/型号的路由器，我们就应该没问题，尽管不同的平台可能会认真对待这种路由器所宣传的 GR 功能，并且只要该路由器重新启动，就会出现黑洞流量，这显然可能是问题...

Cisco BGP 平滑重启行为

编辑：