1. Introduction
本文针对SONiC NOS中的 routing-stack可重启性问题,并提出了解决此问题的解决方案。
在本文档的上下文中,我们使用 graceful-restart 和warm-reboot 术语来交替引用正在讨论的 routing-stack 可重启项。
2. Problem Statement(问题陈述)
具有完全解耦的控制和转发平面的网络元件潜在地能够防止在routing-restarting事件期间的流量中断。在这些场景中,期望的行为是最小化路由进程在重新启动时可能对网络其余部分造成的负面影响(例如docker bgp restart)。
任何graceful-restart 实现都有两个主要目标:
- No forwarding-plane update:瞬态不应暴露于转发组件。
- No control-plane update:不应将瞬态通告给相邻对等方的邻居(二级邻居)。
第一个目标是在其控制平面受到影响的设备的边界内完成的(重启节点),而第二个目标主要是在相邻的节点上完成的(接收端或gr-helper端)。
3. 范围
尽管本文档试图为SONiC的 routing-stack作为一个整体的warm-restartability 问题提供一个解决方案,但实际上,存在各种限制,这些限制缩小了本练习的范围,如下所示:
- 今天,SONiC只支持BGP routing-protocol,所以这里介绍的解决方案将仅限于此协议。
- Graceful-restart (GR)功能需要与邻居节点进行交互,因此这些节点应支持与正在使用的路由协议相关联的“gr-helper”功能。在我们的具体案例中,我们假设这些对等点完全支持BGP的gr helper功能,用于IPv4和IPv6 AFIs。
- FRR和Quagga都不完全支持 rfc4724中提到的“重启”功能。生成了转发位(F-bit),但是bgpd和zebra都不保证在GR的重启间隔期间能够保持路由状态。此时,我们不会试图通过扩展任何routing-stacks来解决此问题。目前,本工作的范围将包含在SONiC 层中。有关更多详细信息,请参阅next-steps部分。
4. BGP Graceful-Restart Overview
如 rfc4724所述,BGP实现依赖于 Graceful-Restart 能力,以允许BGP speakers 在BGP重启事件期间表达其保持转发状态的能力。Rfc4724利用以下主要元素来实现这一目标:
- 重新启动标志:在该字段中,最高有效位(R-bit)表示BGP speaker 已重新启动。
- 重新启动时间:重新启动的BGP对等机重新建立会话所需的估计时间(以秒为单位)。
- 地址族标志:此字段的最高有效位(F-bit)用于指示在上一次BGP重新启动期间是否确实保留了使用给定AFI和SAFI播发的路由的转发状态。
每当一个支持GR的speaker 检测到与正在重启的BGP对等机相关联的TCP会话终止时,这个speaker 就会遍历先前从受影响的对等机接收到的所有前缀,并将这些条目标记为过时。之后,必须启动一个计时器,让重新启动的对等机有机会重新建立会话。等待的时间量应与受影响的speaker 先前公布的“重新启动时间”相匹配。
如果重新启动的对等机在分配的窗口内重新建立会话,则接收speaker 应该清除过时的标志。在这种情况下不需要bgp更新,因为没有对路由状态进行任何修改。只有满足以下所有条件时,才可以执行此操作:
- graceful-restart功能由重启对等方发送。
- 重启端发送的graceful-restart能力包括与路由状态相关联的AFI/SAFI,路由状态由两个对等方交换。
- 相关AFI/SAFI的 F-bit 由重启对等机正确设置。
另一方面,如果远程对等方无法在重启计时器间隔内重新建立其会话,或者如果上述任何要求未完全满足,则接收speaker 应消除先前标记为过时的所有前缀,并继续向它的其他对等方发送bgp更新以撤回这些路由。
另一个重要的突出方面是,如果TCP pipeline 被认为已断开,接收speaker 将仅执行上述逻辑(即充当“gr-helper”)。换句话说,如果TCP会话因BGP通知消息而优雅终止,则将遵循常规的BGP/TCP会话终止过程。这意味着重新启动对等机先前发布的状态将立即从接收对等机中消除。
5. High-level Design
简而言之,本文档中的设计依赖于两个主要构建块:
1)支持GR的BGP实现,完全支持gr-helper功能和(至少