如何使用BGP来构建网络控制层面

Facebook在数据中心内部一直使用自研交换机构建IP CLOS架构的数据中心。我们可以从Facebook在2019年披露的F16和HGRID看到他们是如何构建超大型DC网络的物理拓扑架构。

在2021年的NSDI会议上面Facebook将内部如何使用BGP来构建网络控制层面的细节公布出来了，简单说这就是一份非常好的HLD（High-Level Design）的参考，从中我们也能看到除了网络的物理架构、协议逻辑之外还需要大量的整体软件控制架构及其组件的实现。我们先看看Facebook的数据中心 BGP的HLD：  

设计的考量

在设计之初Facebook确定了整体设计的原则：配置“一致性”和运维“简单性”。

IP CLOS数据中心架构选用BGP是一个非常成熟的方案。对比iBGP和eBGP来看，eBGP作为DCN内部的路由协议会有更多的优点，例如：相比iBGP更容易做控制，避免了IGP的使用（无论使用哪种IGP都会带来额外的复杂和开销），BGP更加可靠、灵活也符合预期的一致性和简单性原则。  

如何解决BGP存在的问题

  BGP作为互联网上唯一的广域跨域路由协议已经使用了几十年，在这漫长的使用发展过程中，积累了很多使用中出现的问题，简单将BGP直接引入数据中心内部将面临很多调整，有在互联网上面应用而累积的BGP的自身问题，也有数据中心和互联网场景不同导致的适配问题，我们需要应对这些问题才能确保设计落地。

汇总业内的一些研究论文以及面临的问题可以总结成三个BGP的问题：1）BGP的收敛问题；2）BGP路由稳定性；3）错误配置带来的风险；

BGP的收敛问题  

在互联网上面使用BGP来宣告路由网段会传播到全球网络中去，由于通常网络具备多个出口，所以BGP路由在这种情况下更多的考量是路由的稳定，避免更多的不必要的宣告而造成的持续不断的路由震荡。在这种情况下，BGP协议通常会有一个MRAI （Min-Route-Advertisement-Interval）计时器，路由器收到路由以后等待计时器（例如：有的厂家定义eBGP为5秒）规定的时间以后再发送出去，这样的好处是：如果在计时器内有新的变化可以少一些路由更新发送出去。

但这个特性显然不适配数据中心内的应用场景，数据中心内部使用eBGP来替代IGP需要更快的路由收敛，所以MRAI的设置在这里选择为0，对于一个典型的7-Stage数据中心的架构可以节省很大路由收敛延迟。无论Facebook的自研BGP软件，还是商用路由器都可以很简单的实现这一点。

收敛性和路由传播的范围也直接相关，因此能减少全网传播的路由有利于收敛、同时增加路由稳定性。在Facebook的数据中心网络中非常精巧的设计了路由汇聚的原则，这样可以控制路由的传播范围，详细路由只会在小区域内传递，不会影响其他区域。  

BGP路由稳定性  

Labovitz 等人对互联网上BGP运行存在的一些不稳定因素做了一些研究：一些有问题的BGP更新报文会成为导致路由不稳定的主要因素。我们看看如何在数据中心内部来应对这些可能出现的问题，这样才能确保数据中心内部运行BGP的稳定性。这些问题如下表所示：



表1：故障BGP的更新报文种类  

Facebook在自研的BGP软件上加入了一些特性来规避上面的这些问题。自研的BGP Agent软件具备足够大的内存，可以用来存储所有BGP路由的状态，所以针对问题1和2，可以在存储的BGP路由状态表中先做对比运算，避免不必要的BGP更新报文的重复发送；对于问题3（AADiff），Facebook利用设计来解决：预先设置好固定的Local Preferance属性来规避；对于问题4需要通过整体系统来解决：使用一套监控系统来自动探测故障，发生故障的时候自动隔离（Drain）绕开故障组件。  

错误配置带来的风险  

人为的配置错误造成的故障一直在网络中占有很高的比例，研究表明每天全球都有1%数量的路由是因此问题造成的。研究报告指出有三类BGP错误配置会导致这些问题：

1. 误配BGP的属性

BGP Policy的复杂性会非常容易引起错误配置导致故障，可以通过两点来加强：a）具备严格发布流程的自动化工具；b）在收发两端来同时配置限制条件，确保即使一端错误配置也不会发布到更广的区域。

2. BGP与其他协议互操作

一些设计不那么完美的实践中，会存在BGP和IGP的互操作，将部分IGP路由导入BGP或者反之，这非常容易出现影响面很大的故障。在Facebook的数据中心网络里面没有IGP协议，不存在两种协议互操作的问题。

3. 更新配置导致的问题

设备重启之前配置未保存等情况会导致BGP运行的配置不是实际期望的，从而导致故障发生。应对这种问题，Facebook设计的系统具备集中的配置数据库用来监控设备运行的配置版本，确保在运行、割接等等状态始终保持一致性原则。

BGP高阶设计

相比中心控制的SDN实现方式，Facebook选择的BGP主要基于三点原因：

1）SDN的构建、发开需要更长的周期和实现的复杂度才能交付整体期望的可扩展性和可靠性；

2）BGP在大规模网络上有被验证过的良好表现，同时也可以在第三方设备上进行BGP实现；

3）Facebook的自研交换机FBOSS已经运行了这个BGP Agent，使用BGP方案可以无缝在集成之前的整体技术思路。

摒弃IGP，直接使用eBGP作为DCN内部协议已经是一种成熟的解决方案，这里不再赘述。这样的选择也更加容易契合配置一致性和运维简单性的总体设计原则。  

物理拓扑

 

图1：数据中心物理拓扑  

Facebook的数据中心采用了统一的模块化设计架构，参见上图：由多个最小单元：服务器Pod组成，每个服务器Pod分成两层：

1）最底层的RSW交换机（Rack Switch架上交换机）；

2）Fabric交换机层（FSW）。

所有RSW交换机上联本Pod内的所有的FSW交换机。FSW交换机再上联到4个平面共16台SSW Spine交换机（F4架构）。

Pod内FSW交换机的数量和Spine的平面数量是一致的，这也就是说F4架构（图2）的FSW是4台，F8/F16架构下的FSW分别是8/16台。

整个数据中心的扩容可以通过增加Spine平面数量（例如：F4 -> F8，4平面变成8平面）和增加平面内Spine交换机的数量（例如：每平面4台增加变成6台）实现。



图2：F4整体架构  

路由设计原则

配置一致性和运维简单性是Facebook最基本的两个设计原则。在具体详细的设计中，很多考量都是围绕这两个基本原则进行的。

虽然有三种不同的角色：RSW、FSW和SSW，但为了配置一致性和可重复使用的配置，BGP的路由策略在三种类型上面是尽量相同的，只是实际动态的IP地址、链路地址、服务网段不同而已。

交换机的配置包括端口映射、IP地址、BGP、路由策略等配置都是通过中心控制的网络管理控制系统（Robotron）生成的，与底层的交换机是完全解耦的，所以可以适配不同的物理交换机类型。

另外值得一提的是这个中心化的网络管理控制系统：Robotron，不仅仅是数据中心而是整个Facebook网络的核心管控系统，更关键的是它实现了通过抽象化通用模型来配置、监控、自动运维等意图化的整体能力，和Google的Orion具有同等的地位。（关于Robotron将在以后陆续详述）  

BGP Peering设计

三层交换机每层之间都是用单跳的eBGP来互联，即： · RSW <---> FSW 之间运行eBGP · FSW <---> SSW之间运行eBGP

多条互联链路的情况下，每条链路都使用独立的3层IP互联，同时创建eBGP进程。另外，参加图1和图2，仔细观察可以看到每层内部并没有同层的互联链路，例如RSW不会互联另一个RSW，其他两层同理。在这个物理设计下，不会需要同层内的BGP进程，这也简化了物理拓扑和路由逻辑。

ECMP（等价多路径）在这种物理拓扑下将成为最大的特性，通过BGP的路由策略来确保尽可能多的可用路径能参与ECMP。在交换机的FIB编程中，处理端口的Up/Down只会涉及到ECMP下一跳组数据结构内的增删，在这种设计下，这个操作是非常容易处理的。WCMP（加权的ECMP）会需要更高的硬件要求，目前Facebook没有使用。  

AS号分配设计

AS号的规划也遵循了一致性和简单性原则。Facebook的AS号规划并没有使用特殊或者定制的私有特性，而是使用标准的BGP操作属性，同时AS号还可以在不同的数据中心之间重复使用。   BGP联邦的最大特点是：联邦内部可以划分多个子AS域，分配子AS号，但对外使用外部联邦AS号。

对联邦外部而言，联邦内部的子AS号是不可见的、隐藏了的，所以利用这个特性，联邦内部的子AS号的规划分配可以在不同的数据中心重复使用，这就大大简化地数据中心的设计、配置和运行维护。

数据中心内部的路由选路遵从标准BGP属性，使用AS-Path作为选路区分条件来决定最优路由。BGP路由所携带的AS-Path属性在运维中也给排错带来的便捷：通过查看路由的AS-Path属性就可以知道路由的传递经过了那些路由器。

AS号使用了16比特私有AS号码（64512 ~ 65535）来做规划。



图3：BGP联邦AS号规划  

参见图3，BGP的AS号整体规划描述如下：  

服务器Pod内规划  

每个服务器Pod对外使用联邦AS号，参见图3中Server Pod 65101。该联邦AS号在整个数据中心内是唯一的，所以其他的服务器Pod的联邦AS号规划从65102 ~ 651XX（图3右侧）。一个服务器Pod内部的RSW和FSW的子AS号规划可以其他的服务器Pod内完全相同，这就带来的设计、规划、配置、运维的简洁性。

服务器Pod内，子AS号分配： · RSW分配子AS号：65401 ~ 654XX （XX = RSW的数量）； · FSW分配子AS号：65301 ~ 65304 （F4架构）；

子AS号 [ 65401 ~ 654XX，65301 ~ 65304 ] 属于联邦AS号65101，FSW将路由广播给SSW的时候，这些子AS号将不再携带，AS-Path上只会呈现一个65101 AS号，其他服务器Pod（AS 65102 ~ 651XX）也同理。  

Spine平面  

参看图2，F4具备4个平面，那么4个平面的AS号分别为65001 ~ 65004。SSW作为骨干交换机连接不同的服务器Pod以及交换数据中心间的流量，通过多路径的ECMP的架构，同一平面SSW之间并不需要互联。这里的设计和RSW/FSW不一样，同一平面内的SSW的AS号是一样的，这样的设计对比RSW/FSW来讲，可以实现期望的防止路由环路的功能：路由不可能在一个平面内多次经过SSW，简单的利用了BGP内置的防环机制减少了在路由策略上的控制。  

路由汇聚设计  

数据中心的IP路由分成两类：设备自身的路由和业务路由。设备自身的路由主要用于设备连接、管理和排错，流量相对来说非常小。即使故障发生，设备的可达性相比业务路由也没那么关键，毕竟还有很多冗余路径和设备可以提供服务。业务路由承载了大量的实时流量，即使是在部分设备有故障的情况下也需要保障剩下的网络能保障其可达性、最优的路径以及足够的路径容量。

数据中心内有很多IP地址网段，为了减少交换机硬件FIB表的占用以及其高效收敛计算，Facebook在网络拓扑的各个层面上进行了层次化的路由汇聚。对于业务路由，Facebook在IP地址段规划上面就紧密配合了分层路由聚合的实施。

RSW会聚合服务器的业务网段路由，FSW会将RSW传播上来的路由进行第二级聚合，这样广播到服务器Pod外部去的将是经过分级聚合以后的路由，而详细路由的传播范围维持在Pod内部。这种设计下，不仅路由条目减少了，并且详细路由的抖动并不会波及到Pod外面去。

参见图4，对于设备自身的路由，也是逐级汇聚，最终FSW汇聚Pod内的所有设备的地址。SSW设备会按设备形成每个平面的汇聚路由。  



图4：Pod内设备自身路由的汇聚   对于Facebook数据中心的规模，如果没有路由汇聚将会有超过10万条路由，然而通过仔细的地址分配规划以及分层的路由汇聚，Facebook实现了最终将路由条目控制在小几千条的规模，这对于路由收敛、网络稳定起到了积极作用。  

BGP路由策略

Facebook使用的是BGP的公认属性来进行路由策略的匹配、控制。利用这些属性可以方便地控制BGP路由的传播范围以及屏蔽一些不期望的路径。路由策略的设计中依然兼备了一致性和简单性的原则。  

路由策略的目标  

通常BGP路由策略在AS自治域之间用于路由过滤、控制更改等操作从而控制相应的流量。在Facebook的数据中心内，所有的交换机处于统一的控制下，所以互联网上的商业对等关系不是其关注的本质，更多的关注点在下表：

表2：路由策略的目标  

BGP的Community属性是在Facebook的BGP设计实现中最重要的属性。对于不同的路由，附加上不同的Community属性用于标识路由类型，就类似为路由贴上了不同的标签，为后续在网络中处理带来了便捷。在实现Community的匹配策略的时候，也遵从了一致性原则，使得BGP的策略也实现统一性。

下面从Facebook期望的路由策略目标来解释如何在设计中体现：  

＞可靠性  

目前Facebook设计的BGP路由策略能保障其网络稳定性。由于BGP传递过程中会将Community属性附着并广播，所以就可以进行相应的控制。

通过匹配预先定义并附着的Community属性就能控制路由传播的范围。参见图5b，RSW广播路由的时候会附带“rack_prefix”的Community属性，通过在FSW上控制，该属性的路由不会向SSW广播，所以带有“rack_prefix”属性的路由只会在Pod内部传播。

 

图5：BGP的Community属性实现路由控制  

使用BGP策略，可以为不同的路由类型预先创建好备用路径。业务流量会在链路发生故障的情况下，按照预先定义的备份路径发送。

参见图5b：

如果fsw1和rsw1之间的链路发生故障，rsw1与fsw2之间的链路正常；

rsw1会将路由标记上“rack_prefix”的Community属性、然后广播给fsw2；

fsw2除了正常向上（SSW）广播之外，会向其备份路径rsw2广播路由，该路由会在fsw2向下广播的时候添加上“backup_path” 的Community属性；

rsw2通过与fsw1之间的BGP进程广播自己的路由，其中会有两种：

一是带有“rack_prefix” 和“backup_path”属性的路由；

二是只带有“rack_prefix”属性的路由；

fsw2收到这两种路由，只会向骨干的SSW广播只有“rack_prefix”属性的路由，而带有“backup_path”属性的路由除了fsw1装载在本地转发表之外不会再广播出去，因为这是经过备份路径广播过来的路由。

参见图6，带有“backup_path”属性的路由到达fsw1以后，会加上“completed_backup_path”属性，其本质就是BGP的知名Community“no-advertise”的属性，所以fsw1不会再次广播给任何BGP邻居。

 

图6：通过Community属性控制备份路由传播范围  

对于故障情况下的下行的流量，参考图5a，SSW将目的地为rsw1的流量送至fsw1，虽然fsw1和rsw1之间的链路中断，但其备份路径（fsw1 -> rsw2  -> fsw2  -> rsw1）还是保障了最终可用性。

在rsw和fsw之间的路由策略中，一端的出方向（export）的策略和另一端的入方向（import）的策略在逻辑上是一致的，比如出方向匹配某个Community的属性，另一端的入方向也有同样的匹配条件，这样可以有效地减少因为错误配置带来的故障。  

＞可维护性  

在数据中心内，每个小时都有可能出现事件，某个组件发生故障也是预期内的事情。

这些事件可能是：机架的新增、移除，链路震荡、光模块故障，网络设备重启、软件崩溃，配置更新失败，交换机的软件更新或者其他运维操作，想要避免对业务流量的影响，需要对设备进行隔离（Drain）操作，从而使得业务流量不丢包。

Facebook定义了三种不同的运维状态，而这些状态影响了路由的传播逻辑：  



表3：路由策略的目标

通过对相关的设备的路由策略的变更来实现设备的隔离以及重新恢复服务。基于之前的一些多级隔离经验，Facebook实现了具有“WARM”状态的多级隔离流程，更好地为业务流量服务。在WARM状态下，通过更改BGP策略来降低隔离设备的的路由优先级，同时调整本地、对端的ECMP的组，避免隔离和恢复业务时可能造成的链路流量过载。

当BGP收敛完成以后，业务流量绕开隔离节点以后，再次更改设备配置进入最终状态。

在隔离状态中，BGP的策略只允许广播设备其自身地址，维护其网络可达性使得设备还处于可管理、可运维的状态。在此状态下，业务流量会绕开该设备。

隔离/恢复业务是数据中心常用的操作。按照数据统计，平均每天要进行242次隔离/恢复操作，每次平均花费36秒即可完成。这种多级隔离状态的变化过程不会影响业务流量。  

＞可扩展性  

BGP设计中的路由分层汇聚有效的降低了RIB和FIB的条目，增加了可扩展性；同时通过Community属性来限制路由传播的范围也加强了其可扩展性。预定义的备份路径也有助于增加可扩展性，对于故障的确定性反应可以避免小故障引发变成更大面积的故障。

在路由策略的处理开销上面，Facebook确立了一条原则：第一条策略匹配最多的路由。这样可以整体减少策略执行开销。例如，在隔离状态下，需要避免发送业务路由，那么第一条策略就是拒绝发送所有业务路由，而发送少量的其设备本身的地址则在策略条目的后面位置。  

＞服务可达性  

数据中心的一个重要的目标是提供服务的可达性。即使服务实例添加、删除或者迁移的过程中，也需要保障其可达性。Facebook使用VIP（Virtual IP Addresses）来给服务实例提供服务。类似DNS之类的服务可以通过单个VIP宣告其服务，但实际上由多个服务实例提供服务。使用Anycast路由可以将需要到达实例的流量发送到其VIP去。

同样为了考量一致性和简单性的原则，Facebook并非是简单的在RSW上直接宣告VIP路由，而是通过VIP Injector（VIP注入器）和RSW来创建的BGP进程宣告VIP的服务地址。

这样做的好处是：RSW配置是固定的，不需要因为VIP服务的增删而变动，增加网络稳定性；服务的控制权交给VIP Injector，各行其事，不混淆各部件的功能。在这种架构下，RSW只是对VIP Injector传入的路由按照预定义的属性进行必要的安全检查、Community属性添加、为不同的VIP设置不同的优先级。

VIP服务实例的启用、停用可以由VIP Injector通过发送、撤销BGP路由宣告的方式来实现，所有控制权在VIP Injector端，RSW则维护网络的简单、稳定。  

路由策略的配置  

考虑一致性和简单性，Facebook的BGP策略不会对具体的地址前缀进行匹配，而是通过Community和AS-Path的正则表达匹配来实现。通过接受、拒绝路由，修改BGP属性来控制最优路径选择。在具体配置上，通过BGP的 peer group 层级下的命令可以对一组BGP邻居做统一的相同配置。而前面提及的可以复用的AS号设计使得BGP策略的配置在多个数据中心内可以使用相同的策略。

得益于前面的种种设计，Facebook数据中心各层交换机之间的路由策略相对来说非常少：入方向（import）的策略是3 ~ 31条，平均每个BGP进程11条；出方向（export）的策略是1 ~ 23条，平均每个BGP进程12条。大多数出方向的策略是给路由做标记，这些标记是预先定义好的含义明确路由传播的范围；而入方向的主要是准入控制，同时通过调整收到路由的Local-Preference值或者AS-Path长度来影响最佳路径的选择。

对于数量最庞大的RSW交换机，让其策略的逻辑尽量简单有利于网络稳定以及更少的配置变更。就此在FSW上会担负稍多一些的策略，用以卸载RSW的负担。

虽然设备的配置是由软件产生、控制的，但兼顾人的可阅读性，命名上面还是选择了有含义的定义，方便人工查阅、审核。Facebook的FBNet里面有更详细的描述。  

路由策略变更  

Facebook通过FBNet维护了一个全球路由策略的抽象模板，再使用全局中心化管控系统Robotron来自动生成某个交换机的配置。在实际的运行过程中，路由策略相对来说比较稳定，在3年的运行周期中，仅仅做了40次策略模板的修改。

参见下图对这40次修改做的统计数据，其中80%的策略修改只针对策略条目数量的2%做了修改。当然每次策略的变更会有严格的审核、测试、验证流程。

图7：累计的策略修改统计  

自研BGP的软件实现

自研BGP Agent其实是在自研交换机FBOSS的时候就已经做出了决定，对比了开源的软件以及其他互联网公司的经验，Facebook决定自己开发BGP软件，叫做BGP Agent，运行在FBOSS交换机里面。这是一款使用C++语言开发的软件，由于有以下种种考虑所以从开发难度、功能和性能上都有很正面的效果。  

选取有限功能  

与BGP相关的RFC有几十个，涉及到很多特性、功能、扩展属性等等，由于很多功能之间需要相互交互制约，给实现增加了很多难度。要实现这完整功能势必需要庞大而复杂的代码，出现问题或者Bug时开发人员很难调试找到其根本原因，添加新功能特性或者重构也面临很大的挑战。

因此Facebook在开发BGP Agent的时候根据自己数据中心的功能、协议需求，定制了遵从相关RFC的最小集合，仅仅使用有限的功能（见表4、5），这样可以缩短实现时间，降低难度。  



表4：自研BGP Agent的核心功能

 

表5：自研BGP Agent的运维相关的功能   在BGP的策略实现上面也是只选取了部分匹配和操作控制特性（见表6）。



表6：路由策略的匹配域和操控项  

多核多线程支持  

很多开源的BGP实现方式都是单线程的，例如Quagga和Bird，这不能很好的使用现在的CPU计算资源。Facebook在自研的BGP Agent整体软件架构上支持了多线程（Peer线程和RIB线程），更好的利用了CPU多核资源。

Peer线程为每个BGP邻居维护其状态机、处理解析、系列化、发送、接收BGP报文等。RIB线程维护本地的路由表，计算最佳路径以及ECMP的多路径，安装维护RIB以及硬件上的FIB。为了尽可能的在每个系统线程上做到最大并行性，Facebook使用了自己的轻量化的应用线程框架folly::fibers。

它具备很低的上下文切换成本以及用协作方式来执行小模块任务。Fiber的线程设计非常适合BGP邻居管理这种高I/O特性的处理。为了避免使用进程锁，在相同或者不同的系统进程中运行的多个fiber进程之间使用消息队列来交换信息。

对比两个开源的BGP软件（Quagga和Bird），Facebook的BGP Agent有相对不错的性能，参见图8，三种不同的BGP软件实现分别部署在FSW交换机上，并从24个SSW接收IPv4和IPv6路由。其中收敛时间包含了：BGP会话建立时间、接收路由、处理接收路由的时间总和。



图8：BGP实现的性能对比   BGP Agent的收敛性能比Quagga快1.7倍、比Bird快2.3倍。  

路由策略实现  

为了提高路由策略的处理性能，Facebook做了一些优化措施。回顾一下数据中心的设计，对于某个具体设备，设备上联的或者下联所有设备，具备相同的出入方向（Export/Import）的路由策略。对此具体的观察结果如下：

1）从一个邻居接收到的多条路由通常共享相同的BGP属性；

2）当交换机发送BGP路由向某个方向（向上uplink或者向下downlink）时，每个个体的BGP邻居使用了相同的路由策略。

在具体的配置上，使用的“peer group”有助于配置简化，但实际处理过程中，还是按照每个BGP的邻居单独计算处理。对于第一点观察，Facebook实现了“批量化”策略处理，将共享同样BGP属性的一组路由前缀作为输入。路由策略引擎针对给定的BGP属性和地址前缀做匹配，然后根据策略里面定义的“动作”输出更改以后的BGP属性。

对于第二点观察，为了避免不同的BGP邻居的重复计算，Facebook引入了“策略缓存”机制，这是基于LRU淘汰算法的缓存机制，缓存包含了< 策略名字，地址前缀，输入BGP属性，输出BGP属性>。对于第一次计算的路由会将其结果放入策略缓存中，后面其他BGP邻居可以匹配的相应的条目，然后直接复制输出结果即可，避免了重复计算。

在构建的测试环境中，FSW向24个SSW交换机发送IPv6路由，在开启缓存功能以后，如下图可以看到性能提升了1.2 ~ 2.4倍：



图9：策略缓存的性能提升  

服务可达性  

在前面描述过，服务可达性是通过VIP Injector与RSW交换机通过BGP进程广播其服务路由而实现的。目前商业厂家的BGP实现不能在同一对地址上建立多个BGP进程，在这个限制下如果要能够实现服务的自动可达性，那么就需要在每个服务器上单独运行服务的注入程序，在服务器各自和RSW建立的BGP进程中广播其服务路由。

在实际操作中这变得不太可行，因为应用程序对注入进程不可见，并且还存在故障的依赖问题：

1）应用程序必须监控注入程序的健康度；

2）注入程序需要撤回路由，当它发现服务应用出现故障时。

通过自研的BGP Agent，上面的复杂性可以得到精简。RSW直接和VIP Injector的VIP地址建立多个BGP进程（同一对地址，多个BGP进程），然后宣告服务可达性。这样就不需要再考虑如何绕开商业厂家的限制、同时还消除了应用程序对注入器的依赖。  

其他工具辅助  

运维团队传统使用网管工具类似SNMP、Netconf来收集网络数据（例如：链路负载和丢包率等）监控网络健康状况。这些工具还可以收集路由表和BGP邻居的事件。然而，想要在这些工具里面加入新的采集数据并非易事，例如BGP收敛时间。这需要修改并且标准化网管协议。

Facebook在使用一个内部监控系统ODS。通过使用Thrift网络接口（自研交换机FBOSS的网管接口），运维团队可以监控自己定制化的数据。然后，在ODS中存储这些事件数据。最后，运维团队可以通过人工或者自动告警工具去查询、分析他们的系统。

类似其他软件，Facebook将BGP Agent集成到整个监控框架中了。这使得更精细的BGP内部状态的监控得以实现，例如：邻居建立的数量、每个邻居收发路由的数量、前面提及的收敛时间等等。使用这些数据可以检测故障，并且实现自动排错机制。  

测试和灰度部署

参见下图，两种情况下需要进行测试和部署：更新交换机配置和上线新的BGP Agent版本。开发新的BGP功能、优化或者修复安全问题、为可靠性和效率进行的BGP路由策略修改，都会触发新一轮的测试和部署。通过持续测试和部署流程，Facebook可以能更快的推出新版本，确保数据中心更平滑的运行、减少宕机。  



图10：Facebook整体变更、测试和部署流水线  

测试

Facebook的测试主要有三个部分组成：单元测试、仿真和灰度测试。

对于生产网络，仿真是一个极有用的测试框架。类似CrystalNet（微软的仿真测试平台），Facebook开发了BGP仿真框架去测试BGP Agent软件、BGP配置和路由策略的实现，并用于整个网络的BGP建模。仿真还可以用于测试各种故障情况下BGP的行为，例如：链路抖动、链路中断或者BGP重启等情况。BGP Agent的升级和配置更新也纳入了仿真过程。

在仿真过程中还可以发现一些会对生产网络中服务造成危害的Bug。仿真测试可以大大地节约开发人员的时间以及对大量硬件测试资源的需求。当然，由于无法模拟底层的软硬件，仿真工具无法实现高保真的模拟。在BGP收敛回归测试中使用仿真就会很有挑战，主要原因是Linux的容器会比硬件的交换机慢很多。

在成功的完成仿真测试以后，下一步将在生产网络中进行灰度测试。新的BGP Agent软件或者新版本的配置会运行在生产网络中少量的叫做“Cannaris”交换机上。灰度测试可以使得有机会进一步的捕获之前没有发现的问题，同时增加上线的信心。通过挑选在生产网络中的交换机，可以捕获一些因为规模导致的问题，例如：交换机的收敛变慢。

灰度测试包含下面的一些场景：

1）从旧的BGP Agent 或者配置迁移到新的BGP Agent软件或者新的配置，通常发生在部署阶段；

2）从新的BGP Agent 或者配置迁移到旧的BGP Agent软件或者配置，通常是在生产网络迁移过程中发生故障，然后回退到旧版本或者配置；

3）BGP进程发生GR（平滑重启：Gracefual Restart，这是BGP实现中有利于实现平滑部署的最重要的一个功能）。日灰度测试通常运行新版本一整天。生产网络的监控系统会对任何异常行为产生告警。灰度测试会帮助找到在仿真环境中没有发现的Bug，比如底层函数库变动产生的问题。  

部署

当变更（BGP Agent软件或者配置）通过测试验证，就进入了部署阶段。在更高效的发布变更和维系总体可靠性之间需要找到一个平衡。不可能简单的切换整个数据中心的流量来进行控制平台的一次性升级，这对服务可用性造成极大的损害。所以，在部署环节，尽可能地减少对网络的影响。这也是为了支持在生产网络中可以快速、频繁地进行BGP的演进。Facebook推出了一个推送计划机制来实现逐步部署中及时发现问题。  

推送机制  

推送机制分成两种类型：有损式和无损式，主要区别是：是否影响交换机上现有的转发状态。大部分的升级部署操作都是无损式的，不会影响现有的业务流量，比如性能优化，软件的集成系统变化等。为了减少在无损式部署过程中的路由不稳定，GR（Gracefual Restart）是一个重要功能。

当交换机在升级过程中，GR能确保BGP Agent软件不会删除现有转发表的内容。等待交换机重启完毕、重新建立BGP邻居关系、收敛路由以后，再次重新控制转发表。在这个期间，如果没有链路/设备发生故障，业务流量完全不会受到影响。如果没有GR，这个过程会有业务影响，同时在节点重启完恢复路由的过程中会经历网络收敛抖动。

有损式部署升级（例如：现有交换机路由策略发生改变）将会触发新的宣告/撤销更新发送给交换机，随后会导致BGP进行重新收敛。在这个过程中，业务流量可能会被丢弃或者走在次优路径上而导致延迟增加。因此，二进制或者配置的更改会是有损式的，在进行变更之前需要进行隔离（Drain）操作。隔离操作会降低网络整体的吞吐量，所以尽量把相关的有损式操作聚合集中到一起，可以减少对网络的整体影响。  

推送阶段  

Facebook定义了6个不同的部署推送阶段，参见下表：P1 ~ P6 ，在升级过程中依次执行。在每一个阶段，推送引擎会根据该阶段的规则随机选择一定数量的交换机，然后推送引擎将推送并重启这些交换机上的BGP。这6个推送阶段是逐步扩大部署范围的过程，最后一个阶段推送到所有的交换机上。

P1 ~ P5 可以理解成扩展测试阶段：P1和P2是少量的RSW测试；P3是一个重要节点，因为是推送到所有类型的交换机上了；P3阶段会选择一个具备有负载分担能力的Web服务数据中心，这样即使发生问题，对实际业务也影响不大。这种多样化环境对评估升级是否安全尤为重要。

P4和P5会升级跨数据中心的相当数量的交换机，即使发送严重故障，整个网络的冗余性任然可以保障业务的高性能响应。最后一步P6中，完成对剩下的所有交换机的升级。  



表7：推送阶段定义  

推送监控  

为了在部署期间监测问题，Facebook使用一个可扩展的服务BGPMonitor来监控数据中心的所有的BGP设备。所有的BGP设备会将所有收到的广播/撤销转给BGPMonitor。BGPMonitor收集以后验证路由是否按照预期维持不变。例如，在一个无损式的升级中，一旦发现了有路由的广播/撤销（意味着可能造成业务影响），就停止推送升级并且向工程师报告这种潜在的问题，工程师将分析问题确定是否可以继续升级推送过程。数据中心的实际运行，Facebook通过BGPMonitor发现了一次停电故障。  

推送结果  

下图展示了12个月的期间内进行的9次推送中各个阶段的时间花费。下图同时也展示了高速迭代在数据中心的可行性，在快速的时间尺度上修复性能和安全问题。也使得其他应用程序能够利用BGP的特性实现快速革新。P6阶段最为费时，因为它需要处理数量庞大的交换机。

在P1 ~ P5过程中，需要处理捕捉到的各种问题，因此有些阶段需要花费更多一些的时间（超过一天）。在这12个月的52%的时间中，数据中心的BGP Agent软件处于变更中（添加对BGP架构的支持，修复Bug，优化性能，安全补丁等）。



图11：九次推送各阶段的时间消耗  

理想情况下，每个阶段交换机的升级应该100%成功完成。例如，有一次因为修复了一个安全漏洞，进行了一次推送，但各种设备因为各种原因而无法连接。设备也会因为各种维护操作而不可达，造成在推送过程中无法访问。不可预知的硬件和电源问题也会导致推送失败。

无法推测各种不可达设备何时恢复，当然也不期望由于少量的失败而停止推送步骤，因此对于每个阶段设置了99%的阈值，只要失败的数量不大于1%那么就可以继续进行。下面的表格中显示了12个月周期中最后三次推送的各个阶段的失败百分比，最差的一次（第7次）总体成功率也在99.43%。



表8：后三次推送各阶段的失败率  

站点故障（SEV：Site EVents）

尽管具备了测试、部署推送策略，但数据中心控制层面的规模、进化演进的本质、BGP的复杂性、与其他服务（例如：推送、隔离等）的交互以及人为错误都不可避免地会造成网络中断。Facebook对2年内发生的重大站点故障（SEV）做了分析、汇总。通常由两大类原因导致：

1）最新的配置或者BGP Agent软件更新；

2）之前没有碰到过的场景触发了潜在的Bug。

通过多种监控工具来捕捉网络中的异常时间，这些工具包括：

1）事件数据存储：ODS，用于记录BGP的各项数据包括宕机时间；

2）Netsonar，检测不可达设备；

3）NetNORAD，检测服务器之间端到端的延迟、丢包率。  

分析经历的14次站点故障，与BGP相关的主要是：路由策略、BGP软件以及和工具软件（推送框架、隔离框架）之间的交互。

一组站点故障是由于路由策略部署不完整/不正确造成的。例如，有一次更新配置中，需要在一层交换机中更改Community属性，然后再另一层中匹配再操作。这本是应该先更改、再匹配，需要有先后顺序，但实际推送过程中，顺序错误造成数据中心内的黑洞，损伤了多个服务的性能。

另一组站点故障是由BGP Agent软件错误造成的。一个站点故障是由于BGP实现中限制接收对端最大路由条目引发的，由于计算路由条目算法中的Bug，导致多个BGP进程中断了，最终导致服务SLA降格。

不同BGP Agent的版本之间的互操作也导致过故障。虽然设计了BGP GR，但旧版本中GR的计时器是30秒，但新版中却是120秒，重启30秒以后，旧版本路由器就已经清除了转发表，这个故障导致流失了大约90秒的流量。再次，BGPMonitor工具探测到了这个推送过程中的故障。

所有这些站点故障都通过回退到之前的稳定的BGP Agent版本或者配置解决了，然后再下一次的更新中发布修复版本。问题和故障的发生是必然的，所以一个优秀的测试部署框架比具体的去解决软件Bug、版本兼容等问题更有效。在开发的后期创建的仿真平台，以及不断新添加针对之前SEV的测试用例对整体流程进行了持续的完善。  

未来的工作内容

基于前几年的数据中心运营中发现的差距，介绍一下Facebook进行的一些工作。  

路由策略的管理

BGP支持丰富的策略框架。出入方向的策略是一个符合设计者意识的带有多条规则的决策树。虽然在设计中路由策略是整体、跨层的，但分布式策略的管理和推理也尤为重要。某些现有的控制层面的验证工具可以通过设备配置建模来验证策略，但无法支持实现灵活的复杂意图。扩展网络验证来支撑大规模路由策略设计是一个重要的为了方向。扩展网络合成来支撑BGP设计和策略也是需要追寻的方向。  

进化的测试框架

路由策略的校验工具是假设底层的交换机的软件是没有错误的，但有8个站点故障都是因为底层软件错误造成的。现有的工具没法主动的检查到这种问题。作为补救方式，在部署之前，Facebook会用仿真平台来检测控制平面的问题。在在线网络中部署BGP的更新配置和BGP Agent软件时，可能会触发一些路由问题，例如短暂的转发环路和黑洞。

有10个站点故障是由于部署更新触发的。为解决这类问题，在仿真平台上模拟整个部署过程，并且验证各种部署策略的影响。为了更贴近的模拟硬件交换机以及软硬件组合的一些场景，还需要探索更多的新技术。Facebook同时也扩展了测试框架，包括一些商用的网络协议验证工具以及模糊（Fuzz）测试。

网络协议验证工具（Keysight的IxanvlTM）可以确保BGP Agent软件符合RFC的要求，模糊测试可以增加BGP Agent的健壮性，在面对无效、非预期或者随机的BGP消息而具备良好的故障处理能力。  

故障下的负载分担

经过几年的运维，Facebook观察到在设备处于故障情况下或者在隔离状态下，会发生负载分担出现不均衡的状态。查看图1，RSW会将流量发送到上游的4台FSW，对每台FSW会发生1/4的流量，每台FSW又将自己的1/4的流量（等同于RSW上行的1/16）发送给4台各自的上联的SSW。

这个时候假设一台SSW出现故障，但基于现在的设计和路由处理的方式，RSW对此毫无感知，所以有故障的SSW下联的那台FSW还是收到和其他FSW一样的流量，但它的上联只有3个SSW，那么这3台SSW比其他12台SSW收到的流量要多。最理想的情况是RSW能感知到这个变化，那么向FSW发送的时候就是按照：给三个无故障的FSW发送4/15，给有故障的FSW发送3/15，这样RSW上行的流量在所有的SSW上面是均衡的。集中式的SDN的控制方式可以容易的实现，但Facebook基于现有的整体框架，还是考虑使用WCMP通过BGP路由的方式来解决。

相关的工作

在数据中心使用BGP的设计

在大型的数据中心中的路由设计，有一些不同的实现方法，比如使用集中的SDN的方式，另一种是按照RFC7938里面描述的基于BGP的方式。

对应后一种，Facebook的方式还略有不同，比如：Facebook使用了BGP联邦属性，这样使得16比特的AS号可以在不同的数据中心中重复使用，简化了很多工作；还有，并没有使用“Allow AS In”的BGP特性，在某些设计中比如同层FSW使用相同的AS号，那么备份路由势必会有相同的AS号一前一后的夹带在AS-Path中，那么就必须使用“Allow AS In”去取消BGP自带的防环机制，相反在详细路由传播范围的控制中，Facebook还需要防环功能自动的阻止路由的随意传播；还有一个区别是：使用了路由聚合来精简了路由条目、加快了收敛，控制了详细路由的传播、增加了网络稳定性。另外一个重要区别是：通过严格的路由策略设计，实现预先设计好的备用路径，增加了网络的可达性和可靠性；也给主机提供VIP的主备路径选择的能力。

Google的Jupiter中使用SDN的方式来实现数据中心的路由控制，通过集中的路由控制器去采集、发送链路状态，这需要一个独立的带外CPN（Control Plane Network）网络，在其中运行一个定制的IS-IS协议去同步拓扑状态。Google选择SDN的原因与他们使用的定制化的硬件（OpenFlow）以及其网络独有的特性有关系。Facebook选择去中心化的BGP的实现方式的主因还是：灵活的路由策略控制、大规模网络的支持、自己的操作熟悉性和第三方厂家的支持（自研和第三方设备可以统一纳管）。

运维框架  

通过参考CrystalNet（微软的网络仿真验证框架）、Janus（变更规划工具）等工具，Facebook的运维框架不断的增强、完善：在运维框架中集成监控工具、部署框架、运维计划（有损式变更推送）；同时针对其他公司（Google）和研究机构汇总的各种网络问题，通过吸收学习来不断的增加测试框架中的各种场景，提高最终测试验证的质量。    

网络边缘的BGP

Facebook的Edge Fabric和Google的Espresso都是在边缘依靠BGP来调度优化和最终用户交互的广域网流量，都依靠集中调度的方式来在不同的BGP邻居之间导流，同时也会优化路径实现更低的延迟、更少的丢包和更快的速度。类似数据中心内的网络设计的不同，Google还是选择了集中SDN的控制方式，而Facebook则是用集中辅助控制的方式处理需要优化的流量，大量的不需要优化的流量还是由分布式的BGP自己控制。  

自研的软件和组件

通过整体描述下来，Facebook的BGP实践看似简单：简单说就是一个BGP Agent的实现以及整体的BGP HLD而已，但实际仔细解读，里面有很多提及的看似不重要的部分却为网络整体的可用、可靠奠定了牢固的基础。我们在汇总一下整体需要的组件：  

BGP设计  

· BGP联邦：实现AS号复用，同时精简路由控制策略

· 路由汇聚：减少RIB和FIB，增加网络稳定

· Community设定：设定路由传播范围，显式确定备份路径

· BGP路由策略：备份路径、运维操作、减少运算开销  

自研BGP Agent  

· GR先行：Graceful Restart是运维部署中最重要的功能

· 有限功能集合：缩短开发周期，减少开发难度

· 多线程支持：有效利用现在CPU的多核

· 定制改动：同一对地址上运行多个BGP进程，利于VIP Injector广播路由

· 策略引擎：基于LRU的缓存能减少计算开销、缩短收敛时间

· 配合运维：增加BGP的监控数据项的收集  

VIP Injector  

· 运行在服务器上的BGP进程，用来向RSW广播服务地址  

网络管理控制平台（Robotron）

 · 意图化：通过原子建模完成整个网络的镜像

· 自动生成配置：由建模生成具体配置

· 设备配置管理：下发配置，版本控制

· 监控：采集运行数据匹配到模型，来确定网络设备状态  

测试框架  

· 开发仿真：开发验证、缩短开发时间

· 部署仿真：第一步的变更验证

· 灰度测试：旧->新，新->旧，重启等

· Cannaris：少量生产环境验证  

部署框架  

· 自动推送框架：自动推送，部署，重启，回退

· BGPMonitor监控：监控路由状态

· ODS：事件存储服务

· NetNORAD：时延丢包检查子模块

· Netsonar：设备可达性检查模块            

审核编辑：刘清