有人能解释BGP路由器优雅的重启流程吗？
请有人解释一下BGP路由器优雅的重启流程，BGP路由器在重启前和会话后如何进行消息交换。
回答 1
Network Engineering用户
发布于 2019-11-24 13:05:03
考虑下面的拓扑R1---R2---R3。
线R1--R2和R2--R3代表物理连接和EBGP会话。
我们将看到从R1到R3的BGP更新，因此从R3到R1的数据平面流量。
在本例中，R2将重新启动。
R1 ----> R2
OPEN
Graceful restart capability => "I support graceful restart"
Restart flags
R = 0 => "I have not restarted"
Restart Time = 30 => "If I restart in the future, I expect to be done in 30 seconds"
AFI SAFI = IPv4 Unicast => "I support GR for IPv4-Unicast"
AFI SAFI Flags
F = 0 => "This is only relevant after a restart, so 0 for now"
R2 ----> R1
OPEN (similar to above)
R2 ----> R3
OPEN (similar to above)
R3 ----> R2
OPEN (similar to above)路由器R1起源于一些前缀1.1.0.0/16和2.2.0.0/16
R1 ----> R2
UPDATE
AFI-SAFI = IPv4-Unicast
Prefix = 1.1.0.0/16, 2.2.0.0/16
Attributes
Next Hop = R1
AS Path = 100
etc.路由器R2在R2 FIB中安装条目，通过路由器R1将流量转发给1.1.0.0/16和2.2.0.0/16。
路由器R2将从R1收到的BGP更新传播到R3：
R2 ----> R3
UPDATE
AFI-SAFI = IPv4-Unicast
Prefix = 1.1.0.0/16, 2.2.0.0/16
Attributes
Next Hop = R2
AS Path = 200 100
etc.路由器R3在R3 FIB中安装条目，通过路由器R2将流量转发给1.1.0.0/16和2.2.0.0/16。
*路由器R2上的控制飞机因某种原因而坠毁(坠毁，升级)*
路由器R2上的转发平面：
- 继续使用FIB中当前安装的路由转发数据包:向
1.1.0.0/16和2.2.0.0/16的流量继续转发到路由器R1。 - 将FIB中的路线标记为陈旧(规范说肋骨中的路线被标记为陈旧，但这很难实现，因为控制飞机刚刚被吹走)。
路由器R3注意到R2的BGP会话会下降(例如，BFD超时或because超时或链接向下)。
通常，路由器R3会将从R2 (即1.1.0.0/16和2.2.0.0/16)接收到的BGP路由从其肋骨和FIB中移除。
然而，由于路由器R2宣称它支持优雅的重新启动，路由器R3将
- 保持路线从R2在它的肋骨
- 将肋骨上的所有路线标记为“发霉”
- 保持R2在其FIB中的路由
- 继续转发FIB中这些路线的流量
*拓扑变化*
当路由器R2关闭时，网络的拓扑结构发生了一些变化。
让我们假设一些导致路由器R1停止广告前缀1.1.0.0/16的更改
路由器R1将将路由1.1.0.0/16从其肋骨和FIB中撤回，并将BGP撤回发送给其所有邻居。
但是，R1无法向R2发送撤回消息，因为R1-R2 BGP会话此时已关闭。
稍后我们将从这个“不同步”问题中恢复过来。
*路由器R2上的控制平面恢复*
我们假设控制平面的恢复所用的时间少于30秒(路由器R2在开始发送的打开消息中重新启动时间字段的值)。如果花费更长的时间，路由器R3就会“放弃”并冲掉从它的肋骨和FIB中从R2那里学到的路线。
BGP会议恢复如下：
R1 ----> R2
OPEN
Graceful restart capability => "I support graceful restart"
Restart flags
R = 0 => "I have not restarted"
Restart Time = 30 => "If I restart in the future, I expect to be done in 30 seconds"
AFI SAFI = IPv4 Unicast => "I support GR for IPv4-Unicast"
AFI SAFI Flags
F = 0 => "This is only relevant after a restart, so 0 for now"
R2 ----> R1
OPEN
Graceful restart capability => "I support graceful restart"
Restart flags
R = 1 => "*** I DID RESTART ***"
Restart Time = 30 => "If I restart in the future, I expect to be done in 30 seconds"
AFI SAFI = IPv4 Unicast => "I support GR for IPv4-Unicast"
AFI SAFI Flags
F = 1 => "*** I DID PRESERVE FORWARDING STATE IN THE FIB ***"
R3 ----> R2
Similar to R1->R2 OPEN
R2 ----> R3
Similar to R2->R1 OPEN*重新同步化*
路由器R2知道它重新启动，所以它不会发送任何更新，直到它收到来自它的邻居(R1和R3)的所有更新，选择最好的路由，并更新它的肋骨和FIB。
路由器R1知道它的邻居R2重新启动，所以它将重新发送所有路由到R2，然后是一个肋骨结束标记，然后清除从它的肋骨/FIB从R2收到的所有陈旧路由(在本例中没有)。
类似地，路由器R3知道它的邻居R2重新启动，所以它将重新发送所有路由到R2 (在本例中没有任何路由)，然后是一个肋骨末端标记，然后清除从它的肋骨/FIB接收到的从R2收到的陈旧路由。
那么，让我们详细介绍一下：
路由器R1起源于前缀2.2.0.0/16 (但由于上面提到的拓扑更改，不再是1.1.0.0/16 )：
R1 ----> R2
UPDATE
AFI-SAFI = IPv4-Unicast
Prefix = 2.2.0.0/16
Attributes
Next Hop = R1
AS Path = 100
etc.路由器R2在其肋骨和FIB中安装2.2.0.0/16。
路由器R2在其FIB中已经有一个2.2.0.0/16的条目，标记为“过期”。这个陈腐的标记现在被去掉了，它又是新鲜的了。
路由器R2不接收来自R1的1.1.0.0/16更新。因此，R2的肋骨中没有1.1.0.0/16的条目。但是R2在其FIB中仍然有一个1.1.0.0/16的条目，这个条目现在和现在都标记为过期。
路由器R1已经将所有路由发送到R2，因此它向R2发送了一个肋骨末端标记：
R1 ----> R2
UPDATE
AFI-SAFI = IPv4-Unicast
End-of-RIB marker到目前为止，路由器R2已经从R1收到了一个肋骨末端标记，但还没有从R3那里得到.因此，它还没有采取任何行动(它需要从所有邻居收到一个肋骨末端标记)。
现在，让我们看看路由器R3。
在本例中，路由器R3没有任何前缀可发送给R2，因此它立即发送一个肋骨末端标记：
R3 ----> R2
UPDATE
AFI-SAFI = IPv4-Unicast
End-of-RIB marker此时，路由器R2已经从它的所有邻居(R1和R3)接收到了肋骨末端标记，因此它将采取以下操作：
- R2将对其肋骨中的每个目标前缀运行最佳的路由选择过程(在本例中仅为2.2.0.0/16)
- R2将为肋骨中的每个前缀安装所选的最佳路径到FIB (仅2.2.0.0/16)
- R2将从FIB清除任何剩余的陈旧路线(在本例中为1.1.0.0/16)
- R2将开始发送更新，向邻居宣传(传播)其肋骨中的路由：
路由器R2将从R1收到的BGP更新传播到R3：
R2 ----> R3
UPDATE
AFI-SAFI = IPv4-Unicast
Prefix = 2.2.0.0/16
Attributes
Next Hop = R2
AS Path = 200 100
etc.此时，路由器R2已经将所有路由发送到R3，因此它向R3发送了一个肋骨末端标记：
R2 ----> R3
UPDATE
AFI-SAFI = IPv4-Unicast
End-of-RIB marker请注意，路由器R2没有发送到R1的路由(具体来说，它没有将2.2.0.0/16的路由发送回R1，因为使用了AS-path循环)。因此，R2立即向R1发送一个肋骨末端标记：
R2 ----> R1
UPDATE
AFI-SAFI = IPv4-Unicast
End-of-RIB marker当路由器R3从R2接收到肋骨末端标记时，它会从R1 (在本例中为1.1.0.0/16)从is肋骨和FIB刷新所有陈旧的路由。
当路由器R1从R2接收到肋骨末端标记时，它也会这样做，但是这个例子没有什么需要刷新的，因为R2没有为到R1的任何路由做广告。
https://networkengineering.stackexchange.com/questions/60710
复制相似问题
腾讯云开发者
