如何使用BGP來(lái)構(gòu)建網(wǎng)絡(luò)控制層面

圖1：數(shù)據(jù)中心物理拓?fù)?

Facebook的數(shù)據(jù)中心采用了統(tǒng)一的模塊化設(shè)計(jì)架構(gòu)，參見(jiàn)上圖：由多個(gè)最小單元：服務(wù)器Pod組成，每個(gè)服務(wù)器Pod分成兩層：

1）最底層的RSW交換機(jī)（Rack Switch架上交換機(jī)）；

2）Fabric交換機(jī)層（FSW）。

所有RSW交換機(jī)上聯(lián)本Pod內(nèi)的所有的FSW交換機(jī)。FSW交換機(jī)再上聯(lián)到4個(gè)平面共16臺(tái)SSW Spine交換機(jī)（F4架構(gòu)）。

Pod內(nèi)FSW交換機(jī)的數(shù)量和Spine的平面數(shù)量是一致的，這也就是說(shuō)F4架構(gòu)（圖2）的FSW是4臺(tái)，F(xiàn)8/F16架構(gòu)下的FSW分別是8/16臺(tái)。

整個(gè)數(shù)據(jù)中心的擴(kuò)容可以通過(guò)增加Spine平面數(shù)量（例如：F4 -> F8，4平面變成8平面）和增加平面內(nèi)Spine交換機(jī)的數(shù)量（例如：每平面4臺(tái)增加變成6臺(tái)）實(shí)現(xiàn)。



圖2：F4整體架構(gòu)

路由設(shè)計(jì)原則

配置一致性和運(yùn)維簡(jiǎn)單性是Facebook最基本的兩個(gè)設(shè)計(jì)原則。在具體詳細(xì)的設(shè)計(jì)中，很多考量都是圍繞這兩個(gè)基本原則進(jìn)行的。

雖然有三種不同的角色：RSW、FSW和SSW，但為了配置一致性和可重復(fù)使用的配置，BGP的路由策略在三種類型上面是盡量相同的，只是實(shí)際動(dòng)態(tài)的IP地址、鏈路地址、服務(wù)網(wǎng)段不同而已。

交換機(jī)的配置包括端口映射、IP地址、BGP、路由策略等配置都是通過(guò)中心控制的網(wǎng)絡(luò)管理控制系統(tǒng)（Robotron）生成的，與底層的交換機(jī)是完全解耦的，所以可以適配不同的物理交換機(jī)類型。

另外值得一提的是這個(gè)中心化的網(wǎng)絡(luò)管理控制系統(tǒng)：Robotron，不僅僅是數(shù)據(jù)中心而是整個(gè)Facebook網(wǎng)絡(luò)的核心管控系統(tǒng)，更關(guān)鍵的是它實(shí)現(xiàn)了通過(guò)抽象化通用模型來(lái)配置、監(jiān)控、自動(dòng)運(yùn)維等意圖化的整體能力，和Google的Orion具有同等的地位。（關(guān)于Robotron將在以后陸續(xù)詳述）

BGPPeering設(shè)計(jì)

三層交換機(jī)每層之間都是用單跳的eBGP來(lái)互聯(lián)，即： ·RSW <---> FSW之間運(yùn)行eBGP ·FSW <---> SSW之間運(yùn)行eBGP

多條互聯(lián)鏈路的情況下，每條鏈路都使用獨(dú)立的3層IP互聯(lián)，同時(shí)創(chuàng)建eBGP進(jìn)程。另外，參加圖1和圖2，仔細(xì)觀察可以看到每層內(nèi)部并沒(méi)有同層的互聯(lián)鏈路，例如RSW不會(huì)互聯(lián)另一個(gè)RSW，其他兩層同理。在這個(gè)物理設(shè)計(jì)下，不會(huì)需要同層內(nèi)的BGP進(jìn)程，這也簡(jiǎn)化了物理拓?fù)浜吐酚蛇壿嫛?/p>

ECMP（等價(jià)多路徑）在這種物理拓?fù)湎聦⒊蔀樽畲蟮奶匦裕ㄟ^(guò)BGP的路由策略來(lái)確保盡可能多的可用路徑能參與ECMP。在交換機(jī)的FIB編程中，處理端口的Up/Down只會(huì)涉及到ECMP下一跳組數(shù)據(jù)結(jié)構(gòu)內(nèi)的增刪，在這種設(shè)計(jì)下，這個(gè)操作是非常容易處理的。WCMP（加權(quán)的ECMP）會(huì)需要更高的硬件要求，目前Facebook沒(méi)有使用。

AS號(hào)分配設(shè)計(jì)

AS號(hào)的規(guī)劃也遵循了一致性和簡(jiǎn)單性原則。Facebook的AS號(hào)規(guī)劃并沒(méi)有使用特殊或者定制的私有特性，而是使用標(biāo)準(zhǔn)的BGP操作屬性，同時(shí)AS號(hào)還可以在不同的數(shù)據(jù)中心之間重復(fù)使用。 BGP聯(lián)邦的最大特點(diǎn)是：聯(lián)邦內(nèi)部可以劃分多個(gè)子AS域，分配子AS號(hào)，但對(duì)外使用外部聯(lián)邦A(yù)S號(hào)。

對(duì)聯(lián)邦外部而言，聯(lián)邦內(nèi)部的子AS號(hào)是不可見(jiàn)的、隱藏了的，所以利用這個(gè)特性，聯(lián)邦內(nèi)部的子AS號(hào)的規(guī)劃分配可以在不同的數(shù)據(jù)中心重復(fù)使用，這就大大簡(jiǎn)化地?cái)?shù)據(jù)中心的設(shè)計(jì)、配置和運(yùn)行維護(hù)。

數(shù)據(jù)中心內(nèi)部的路由選路遵從標(biāo)準(zhǔn)BGP屬性，使用AS-Path作為選路區(qū)分條件來(lái)決定最優(yōu)路由。BGP路由所攜帶的AS-Path屬性在運(yùn)維中也給排錯(cuò)帶來(lái)的便捷：通過(guò)查看路由的AS-Path屬性就可以知道路由的傳遞經(jīng)過(guò)了那些路由器。

AS號(hào)使用了16比特私有AS號(hào)碼（64512 ~ 65535）來(lái)做規(guī)劃。



圖3：BGP聯(lián)邦A(yù)S號(hào)規(guī)劃

參見(jiàn)圖3，BGP的AS號(hào)整體規(guī)劃描述如下：

服務(wù)器Pod內(nèi)規(guī)劃

每個(gè)服務(wù)器Pod對(duì)外使用聯(lián)邦A(yù)S號(hào)，參見(jiàn)圖3中Server Pod 65101。該聯(lián)邦A(yù)S號(hào)在整個(gè)數(shù)據(jù)中心內(nèi)是唯一的，所以其他的服務(wù)器Pod的聯(lián)邦A(yù)S號(hào)規(guī)劃從65102 ~ 651XX（圖3右側(cè)）。一個(gè)服務(wù)器Pod內(nèi)部的RSW和FSW的子AS號(hào)規(guī)劃可以其他的服務(wù)器Pod內(nèi)完全相同，這就帶來(lái)的設(shè)計(jì)、規(guī)劃、配置、運(yùn)維的簡(jiǎn)潔性。

服務(wù)器Pod內(nèi)，子AS號(hào)分配： · RSW分配子AS號(hào)：65401 ~ 654XX （XX = RSW的數(shù)量）； · FSW分配子AS號(hào)：65301 ~ 65304 （F4架構(gòu)）；

子AS號(hào) [ 65401 ~ 654XX，65301 ~ 65304 ] 屬于聯(lián)邦A(yù)S號(hào)65101，F(xiàn)SW將路由廣播給SSW的時(shí)候，這些子AS號(hào)將不再攜帶，AS-Path上只會(huì)呈現(xiàn)一個(gè)65101 AS號(hào)，其他服務(wù)器Pod（AS 65102 ~ 651XX）也同理。

Spine平面

參看圖2，F(xiàn)4具備4個(gè)平面，那么4個(gè)平面的AS號(hào)分別為65001 ~ 65004。SSW作為骨干交換機(jī)連接不同的服務(wù)器Pod以及交換數(shù)據(jù)中心間的流量，通過(guò)多路徑的ECMP的架構(gòu)，同一平面SSW之間并不需要互聯(lián)。這里的設(shè)計(jì)和RSW/FSW不一樣，同一平面內(nèi)的SSW的AS號(hào)是一樣的，這樣的設(shè)計(jì)對(duì)比RSW/FSW來(lái)講，可以實(shí)現(xiàn)期望的防止路由環(huán)路的功能：路由不可能在一個(gè)平面內(nèi)多次經(jīng)過(guò)SSW，簡(jiǎn)單的利用了BGP內(nèi)置的防環(huán)機(jī)制減少了在路由策略上的控制。

路由匯聚設(shè)計(jì)

數(shù)據(jù)中心的IP路由分成兩類：設(shè)備自身的路由和業(yè)務(wù)路由。設(shè)備自身的路由主要用于設(shè)備連接、管理和排錯(cuò)，流量相對(duì)來(lái)說(shuō)非常小。即使故障發(fā)生，設(shè)備的可達(dá)性相比業(yè)務(wù)路由也沒(méi)那么關(guān)鍵，畢竟還有很多冗余路徑和設(shè)備可以提供服務(wù)。業(yè)務(wù)路由承載了大量的實(shí)時(shí)流量，即使是在部分設(shè)備有故障的情況下也需要保障剩下的網(wǎng)絡(luò)能保障其可達(dá)性、最優(yōu)的路徑以及足夠的路徑容量。

數(shù)據(jù)中心內(nèi)有很多IP地址網(wǎng)段，為了減少交換機(jī)硬件FIB表的占用以及其高效收斂計(jì)算，F(xiàn)acebook在網(wǎng)絡(luò)拓?fù)涞母鱾€(gè)層面上進(jìn)行了層次化的路由匯聚。對(duì)于業(yè)務(wù)路由，F(xiàn)acebook在IP地址段規(guī)劃上面就緊密配合了分層路由聚合的實(shí)施。

RSW會(huì)聚合服務(wù)器的業(yè)務(wù)網(wǎng)段路由，F(xiàn)SW會(huì)將RSW傳播上來(lái)的路由進(jìn)行第二級(jí)聚合，這樣廣播到服務(wù)器Pod外部去的將是經(jīng)過(guò)分級(jí)聚合以后的路由，而詳細(xì)路由的傳播范圍維持在Pod內(nèi)部。這種設(shè)計(jì)下，不僅路由條目減少了，并且詳細(xì)路由的抖動(dòng)并不會(huì)波及到Pod外面去。

參見(jiàn)圖4，對(duì)于設(shè)備自身的路由，也是逐級(jí)匯聚，最終FSW匯聚Pod內(nèi)的所有設(shè)備的地址。SSW設(shè)備會(huì)按設(shè)備形成每個(gè)平面的匯聚路由。



圖4：Pod內(nèi)設(shè)備自身路由的匯聚 對(duì)于Facebook數(shù)據(jù)中心的規(guī)模，如果沒(méi)有路由匯聚將會(huì)有超過(guò)10萬(wàn)條路由，然而通過(guò)仔細(xì)的地址分配規(guī)劃以及分層的路由匯聚，F(xiàn)acebook實(shí)現(xiàn)了最終將路由條目控制在小幾千條的規(guī)模，這對(duì)于路由收斂、網(wǎng)絡(luò)穩(wěn)定起到了積極作用。

BGP路由策略

Facebook使用的是BGP的公認(rèn)屬性來(lái)進(jìn)行路由策略的匹配、控制。利用這些屬性可以方便地控制BGP路由的傳播范圍以及屏蔽一些不期望的路徑。路由策略的設(shè)計(jì)中依然兼?zhèn)淞艘恢滦院秃?jiǎn)單性的原則。

路由策略的目標(biāo)

通常BGP路由策略在AS自治域之間用于路由過(guò)濾、控制更改等操作從而控制相應(yīng)的流量。在Facebook的數(shù)據(jù)中心內(nèi)，所有的交換機(jī)處于統(tǒng)一的控制下，所以互聯(lián)網(wǎng)上的商業(yè)對(duì)等關(guān)系不是其關(guān)注的本質(zhì)，更多的關(guān)注點(diǎn)在下表：

表2：路由策略的目標(biāo)

BGP的Community屬性是在Facebook的BGP設(shè)計(jì)實(shí)現(xiàn)中最重要的屬性。對(duì)于不同的路由，附加上不同的Community屬性用于標(biāo)識(shí)路由類型，就類似為路由貼上了不同的標(biāo)簽，為后續(xù)在網(wǎng)絡(luò)中處理帶來(lái)了便捷。在實(shí)現(xiàn)Community的匹配策略的時(shí)候，也遵從了一致性原則，使得BGP的策略也實(shí)現(xiàn)統(tǒng)一性。

下面從Facebook期望的路由策略目標(biāo)來(lái)解釋如何在設(shè)計(jì)中體現(xiàn)：

＞可靠性

目前Facebook設(shè)計(jì)的BGP路由策略能保障其網(wǎng)絡(luò)穩(wěn)定性。由于BGP傳遞過(guò)程中會(huì)將Community屬性附著并廣播，所以就可以進(jìn)行相應(yīng)的控制。

通過(guò)匹配預(yù)先定義并附著的Community屬性就能控制路由傳播的范圍。參見(jiàn)圖5b，RSW廣播路由的時(shí)候會(huì)附帶“rack_prefix”的Community屬性，通過(guò)在FSW上控制，該屬性的路由不會(huì)向SSW廣播，所以帶有“rack_prefix”屬性的路由只會(huì)在Pod內(nèi)部傳播。



圖5：BGP的Community屬性實(shí)現(xiàn)路由控制

使用BGP策略，可以為不同的路由類型預(yù)先創(chuàng)建好備用路徑。業(yè)務(wù)流量會(huì)在鏈路發(fā)生故障的情況下，按照預(yù)先定義的備份路徑發(fā)送。

參見(jiàn)圖5b：

如果fsw1和rsw1之間的鏈路發(fā)生故障，rsw1與fsw2之間的鏈路正常；

rsw1會(huì)將路由標(biāo)記上“rack_prefix”的Community屬性、然后廣播給fsw2；

fsw2除了正常向上（SSW）廣播之外，會(huì)向其備份路徑rsw2廣播路由，該路由會(huì)在fsw2向下廣播的時(shí)候添加上“backup_path” 的Community屬性；

rsw2通過(guò)與fsw1之間的BGP進(jìn)程廣播自己的路由，其中會(huì)有兩種：

一是帶有“rack_prefix” 和“backup_path”屬性的路由；

二是只帶有“rack_prefix”屬性的路由；

fsw2收到這兩種路由，只會(huì)向骨干的SSW廣播只有“rack_prefix”屬性的路由，而帶有“backup_path”屬性的路由除了fsw1裝載在本地轉(zhuǎn)發(fā)表之外不會(huì)再?gòu)V播出去，因?yàn)檫@是經(jīng)過(guò)備份路徑廣播過(guò)來(lái)的路由。

參見(jiàn)圖6，帶有“backup_path”屬性的路由到達(dá)fsw1以后，會(huì)加上“completed_backup_path”屬性，其本質(zhì)就是BGP的知名Community“no-advertise”的屬性，所以fsw1不會(huì)再次廣播給任何BGP鄰居。



圖6：通過(guò)Community屬性控制備份路由傳播范圍

對(duì)于故障情況下的下行的流量，參考圖5a，SSW將目的地為rsw1的流量送至fsw1，雖然fsw1和rsw1之間的鏈路中斷，但其備份路徑（fsw1 -> rsw2 -> fsw2 -> rsw1）還是保障了最終可用性。

在rsw和fsw之間的路由策略中，一端的出方向（export）的策略和另一端的入方向（import）的策略在邏輯上是一致的，比如出方向匹配某個(gè)Community的屬性，另一端的入方向也有同樣的匹配條件，這樣可以有效地減少因?yàn)殄e(cuò)誤配置帶來(lái)的故障。

＞可維護(hù)性

在數(shù)據(jù)中心內(nèi)，每個(gè)小時(shí)都有可能出現(xiàn)事件，某個(gè)組件發(fā)生故障也是預(yù)期內(nèi)的事情。

這些事件可能是：機(jī)架的新增、移除，鏈路震蕩、光模塊故障，網(wǎng)絡(luò)設(shè)備重啟、軟件崩潰，配置更新失敗，交換機(jī)的軟件更新或者其他運(yùn)維操作，想要避免對(duì)業(yè)務(wù)流量的影響，需要對(duì)設(shè)備進(jìn)行隔離（Drain）操作，從而使得業(yè)務(wù)流量不丟包。

Facebook定義了三種不同的運(yùn)維狀態(tài)，而這些狀態(tài)影響了路由的傳播邏輯：



表3：路由策略的目標(biāo)

通過(guò)對(duì)相關(guān)的設(shè)備的路由策略的變更來(lái)實(shí)現(xiàn)設(shè)備的隔離以及重新恢復(fù)服務(wù)。基于之前的一些多級(jí)隔離經(jīng)驗(yàn)，F(xiàn)acebook實(shí)現(xiàn)了具有“WARM”狀態(tài)的多級(jí)隔離流程，更好地為業(yè)務(wù)流量服務(wù)。在WARM狀態(tài)下，通過(guò)更改BGP策略來(lái)降低隔離設(shè)備的的路由優(yōu)先級(jí)，同時(shí)調(diào)整本地、對(duì)端的ECMP的組，避免隔離和恢復(fù)業(yè)務(wù)時(shí)可能造成的鏈路流量過(guò)載。

當(dāng)BGP收斂完成以后，業(yè)務(wù)流量繞開(kāi)隔離節(jié)點(diǎn)以后，再次更改設(shè)備配置進(jìn)入最終狀態(tài)。

在隔離狀態(tài)中，BGP的策略只允許廣播設(shè)備其自身地址，維護(hù)其網(wǎng)絡(luò)可達(dá)性使得設(shè)備還處于可管理、可運(yùn)維的狀態(tài)。在此狀態(tài)下，業(yè)務(wù)流量會(huì)繞開(kāi)該設(shè)備。

隔離/恢復(fù)業(yè)務(wù)是數(shù)據(jù)中心常用的操作。按照數(shù)據(jù)統(tǒng)計(jì)，平均每天要進(jìn)行242次隔離/恢復(fù)操作，每次平均花費(fèi)36秒即可完成。這種多級(jí)隔離狀態(tài)的變化過(guò)程不會(huì)影響業(yè)務(wù)流量。

＞可擴(kuò)展性

BGP設(shè)計(jì)中的路由分層匯聚有效的降低了RIB和FIB的條目，增加了可擴(kuò)展性；同時(shí)通過(guò)Community屬性來(lái)限制路由傳播的范圍也加強(qiáng)了其可擴(kuò)展性。預(yù)定義的備份路徑也有助于增加可擴(kuò)展性，對(duì)于故障的確定性反應(yīng)可以避免小故障引發(fā)變成更大面積的故障。

在路由策略的處理開(kāi)銷上面，F(xiàn)acebook確立了一條原則：第一條策略匹配最多的路由。這樣可以整體減少策略執(zhí)行開(kāi)銷。例如，在隔離狀態(tài)下，需要避免發(fā)送業(yè)務(wù)路由，那么第一條策略就是拒絕發(fā)送所有業(yè)務(wù)路由，而發(fā)送少量的其設(shè)備本身的地址則在策略條目的后面位置。

＞服務(wù)可達(dá)性

數(shù)據(jù)中心的一個(gè)重要的目標(biāo)是提供服務(wù)的可達(dá)性。即使服務(wù)實(shí)例添加、刪除或者遷移的過(guò)程中，也需要保障其可達(dá)性。Facebook使用VIP（Virtual IP Addresses）來(lái)給服務(wù)實(shí)例提供服務(wù)。類似DNS之類的服務(wù)可以通過(guò)單個(gè)VIP宣告其服務(wù)，但實(shí)際上由多個(gè)服務(wù)實(shí)例提供服務(wù)。使用Anycast路由可以將需要到達(dá)實(shí)例的流量發(fā)送到其VIP去。

同樣為了考量一致性和簡(jiǎn)單性的原則，F(xiàn)acebook并非是簡(jiǎn)單的在RSW上直接宣告VIP路由，而是通過(guò)VIP Injector（VIP注入器）和RSW來(lái)創(chuàng)建的BGP進(jìn)程宣告VIP的服務(wù)地址。

這樣做的好處是：RSW配置是固定的，不需要因?yàn)閂IP服務(wù)的增刪而變動(dòng)，增加網(wǎng)絡(luò)穩(wěn)定性；服務(wù)的控制權(quán)交給VIP Injector，各行其事，不混淆各部件的功能。在這種架構(gòu)下，RSW只是對(duì)VIP Injector傳入的路由按照預(yù)定義的屬性進(jìn)行必要的安全檢查、Community屬性添加、為不同的VIP設(shè)置不同的優(yōu)先級(jí)。

VIP服務(wù)實(shí)例的啟用、停用可以由VIP Injector通過(guò)發(fā)送、撤銷BGP路由宣告的方式來(lái)實(shí)現(xiàn)，所有控制權(quán)在VIP Injector端，RSW則維護(hù)網(wǎng)絡(luò)的簡(jiǎn)單、穩(wěn)定。

路由策略的配置

考慮一致性和簡(jiǎn)單性，F(xiàn)acebook的BGP策略不會(huì)對(duì)具體的地址前綴進(jìn)行匹配，而是通過(guò)Community和AS-Path的正則表達(dá)匹配來(lái)實(shí)現(xiàn)。通過(guò)接受、拒絕路由，修改BGP屬性來(lái)控制最優(yōu)路徑選擇。在具體配置上，通過(guò)BGP的 peer group 層級(jí)下的命令可以對(duì)一組BGP鄰居做統(tǒng)一的相同配置。而前面提及的可以復(fù)用的AS號(hào)設(shè)計(jì)使得BGP策略的配置在多個(gè)數(shù)據(jù)中心內(nèi)可以使用相同的策略。

得益于前面的種種設(shè)計(jì)，F(xiàn)acebook數(shù)據(jù)中心各層交換機(jī)之間的路由策略相對(duì)來(lái)說(shuō)非常少：入方向（import）的策略是3 ~ 31條，平均每個(gè)BGP進(jìn)程11條；出方向（export）的策略是1 ~ 23條，平均每個(gè)BGP進(jìn)程12條。大多數(shù)出方向的策略是給路由做標(biāo)記，這些標(biāo)記是預(yù)先定義好的含義明確路由傳播的范圍；而入方向的主要是準(zhǔn)入控制，同時(shí)通過(guò)調(diào)整收到路由的Local-Preference值或者AS-Path長(zhǎng)度來(lái)影響最佳路徑的選擇。

對(duì)于數(shù)量最龐大的RSW交換機(jī)，讓其策略的邏輯盡量簡(jiǎn)單有利于網(wǎng)絡(luò)穩(wěn)定以及更少的配置變更。就此在FSW上會(huì)擔(dān)負(fù)稍多一些的策略，用以卸載RSW的負(fù)擔(dān)。

雖然設(shè)備的配置是由軟件產(chǎn)生、控制的，但兼顧人的可閱讀性，命名上面還是選擇了有含義的定義，方便人工查閱、審核。Facebook的FBNet里面有更詳細(xì)的描述。

路由策略變更

Facebook通過(guò)FBNet維護(hù)了一個(gè)全球路由策略的抽象模板，再使用全局中心化管控系統(tǒng)Robotron來(lái)自動(dòng)生成某個(gè)交換機(jī)的配置。在實(shí)際的運(yùn)行過(guò)程中，路由策略相對(duì)來(lái)說(shuō)比較穩(wěn)定，在3年的運(yùn)行周期中，僅僅做了40次策略模板的修改。

參見(jiàn)下圖對(duì)這40次修改做的統(tǒng)計(jì)數(shù)據(jù)，其中80%的策略修改只針對(duì)策略條目數(shù)量的2%做了修改。當(dāng)然每次策略的變更會(huì)有嚴(yán)格的審核、測(cè)試、驗(yàn)證流程。

圖7：累計(jì)的策略修改統(tǒng)計(jì) ?

自研BGP的軟件實(shí)現(xiàn)

自研BGP Agent其實(shí)是在自研交換機(jī)FBOSS的時(shí)候就已經(jīng)做出了決定，對(duì)比了開(kāi)源的軟件以及其他互聯(lián)網(wǎng)公司的經(jīng)驗(yàn)，F(xiàn)acebook決定自己開(kāi)發(fā)BGP軟件，叫做BGP Agent，運(yùn)行在FBOSS交換機(jī)里面。這是一款使用C++語(yǔ)言開(kāi)發(fā)的軟件，由于有以下種種考慮所以從開(kāi)發(fā)難度、功能和性能上都有很正面的效果。

選取有限功能

與BGP相關(guān)的RFC有幾十個(gè)，涉及到很多特性、功能、擴(kuò)展屬性等等，由于很多功能之間需要相互交互制約，給實(shí)現(xiàn)增加了很多難度。要實(shí)現(xiàn)這完整功能勢(shì)必需要龐大而復(fù)雜的代碼，出現(xiàn)問(wèn)題或者Bug時(shí)開(kāi)發(fā)人員很難調(diào)試找到其根本原因，添加新功能特性或者重構(gòu)也面臨很大的挑戰(zhàn)。

因此Facebook在開(kāi)發(fā)BGP Agent的時(shí)候根據(jù)自己數(shù)據(jù)中心的功能、協(xié)議需求，定制了遵從相關(guān)RFC的最小集合，僅僅使用有限的功能（見(jiàn)表4、5），這樣可以縮短實(shí)現(xiàn)時(shí)間，降低難度。



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



表5：自研BGP Agent的運(yùn)維相關(guān)的功能 在BGP的策略實(shí)現(xiàn)上面也是只選取了部分匹配和操作控制特性（見(jiàn)表6）。



表6：路由策略的匹配域和操控項(xiàng)

多核多線程支持

很多開(kāi)源的BGP實(shí)現(xiàn)方式都是單線程的，例如Quagga和Bird，這不能很好的使用現(xiàn)在的CPU計(jì)算資源。Facebook在自研的BGP Agent整體軟件架構(gòu)上支持了多線程（Peer線程和RIB線程），更好的利用了CPU多核資源。

Peer線程為每個(gè)BGP鄰居維護(hù)其狀態(tài)機(jī)、處理解析、系列化、發(fā)送、接收BGP報(bào)文等。RIB線程維護(hù)本地的路由表，計(jì)算最佳路徑以及ECMP的多路徑，安裝維護(hù)RIB以及硬件上的FIB。為了盡可能的在每個(gè)系統(tǒng)線程上做到最大并行性，F(xiàn)acebook使用了自己的輕量化的應(yīng)用線程框架folly::fibers。

它具備很低的上下文切換成本以及用協(xié)作方式來(lái)執(zhí)行小模塊任務(wù)。Fiber的線程設(shè)計(jì)非常適合BGP鄰居管理這種高I/O特性的處理。為了避免使用進(jìn)程鎖，在相同或者不同的系統(tǒng)進(jìn)程中運(yùn)行的多個(gè)fiber進(jìn)程之間使用消息隊(duì)列來(lái)交換信息。

對(duì)比兩個(gè)開(kāi)源的BGP軟件（Quagga和Bird），F(xiàn)acebook的BGP Agent有相對(duì)不錯(cuò)的性能，參見(jiàn)圖8，三種不同的BGP軟件實(shí)現(xiàn)分別部署在FSW交換機(jī)上，并從24個(gè)SSW接收IPv4和IPv6路由。其中收斂時(shí)間包含了：BGP會(huì)話建立時(shí)間、接收路由、處理接收路由的時(shí)間總和。



圖8：BGP實(shí)現(xiàn)的性能對(duì)比 BGP Agent的收斂性能比Quagga快1.7倍、比Bird快2.3倍。

路由策略實(shí)現(xiàn)

為了提高路由策略的處理性能，F(xiàn)acebook做了一些優(yōu)化措施?；仡櫼幌聰?shù)據(jù)中心的設(shè)計(jì)，對(duì)于某個(gè)具體設(shè)備，設(shè)備上聯(lián)的或者下聯(lián)所有設(shè)備，具備相同的出入方向（Export/Import）的路由策略。對(duì)此具體的觀察結(jié)果如下：

1）從一個(gè)鄰居接收到的多條路由通常共享相同的BGP屬性；

2）當(dāng)交換機(jī)發(fā)送BGP路由向某個(gè)方向（向上uplink或者向下downlink）時(shí)，每個(gè)個(gè)體的BGP鄰居使用了相同的路由策略。

在具體的配置上，使用的“peer group”有助于配置簡(jiǎn)化，但實(shí)際處理過(guò)程中，還是按照每個(gè)BGP的鄰居單獨(dú)計(jì)算處理。對(duì)于第一點(diǎn)觀察，F(xiàn)acebook實(shí)現(xiàn)了“批量化”策略處理，將共享同樣BGP屬性的一組路由前綴作為輸入。路由策略引擎針對(duì)給定的BGP屬性和地址前綴做匹配，然后根據(jù)策略里面定義的“動(dòng)作”輸出更改以后的BGP屬性。

對(duì)于第二點(diǎn)觀察，為了避免不同的BGP鄰居的重復(fù)計(jì)算，F(xiàn)acebook引入了“策略緩存”機(jī)制，這是基于LRU淘汰算法的緩存機(jī)制，緩存包含了< 策略名字，地址前綴，輸入BGP屬性，輸出BGP屬性>。對(duì)于第一次計(jì)算的路由會(huì)將其結(jié)果放入策略緩存中，后面其他BGP鄰居可以匹配的相應(yīng)的條目，然后直接復(fù)制輸出結(jié)果即可，避免了重復(fù)計(jì)算。

在構(gòu)建的測(cè)試環(huán)境中，F(xiàn)SW向24個(gè)SSW交換機(jī)發(fā)送IPv6路由，在開(kāi)啟緩存功能以后，如下圖可以看到性能提升了1.2 ~ 2.4倍：



圖9：策略緩存的性能提升

服務(wù)可達(dá)性

在前面描述過(guò)，服務(wù)可達(dá)性是通過(guò)VIP Injector與RSW交換機(jī)通過(guò)BGP進(jìn)程廣播其服務(wù)路由而實(shí)現(xiàn)的。目前商業(yè)廠家的BGP實(shí)現(xiàn)不能在同一對(duì)地址上建立多個(gè)BGP進(jìn)程，在這個(gè)限制下如果要能夠?qū)崿F(xiàn)服務(wù)的自動(dòng)可達(dá)性，那么就需要在每個(gè)服務(wù)器上單獨(dú)運(yùn)行服務(wù)的注入程序，在服務(wù)器各自和RSW建立的BGP進(jìn)程中廣播其服務(wù)路由。

在實(shí)際操作中這變得不太可行，因?yàn)閼?yīng)用程序?qū)ψ⑷脒M(jìn)程不可見(jiàn)，并且還存在故障的依賴問(wèn)題：

1）應(yīng)用程序必須監(jiān)控注入程序的健康度；

2）注入程序需要撤回路由，當(dāng)它發(fā)現(xiàn)服務(wù)應(yīng)用出現(xiàn)故障時(shí)。

通過(guò)自研的BGP Agent，上面的復(fù)雜性可以得到精簡(jiǎn)。RSW直接和VIP Injector的VIP地址建立多個(gè)BGP進(jìn)程（同一對(duì)地址，多個(gè)BGP進(jìn)程），然后宣告服務(wù)可達(dá)性。這樣就不需要再考慮如何繞開(kāi)商業(yè)廠家的限制、同時(shí)還消除了應(yīng)用程序?qū)ψ⑷肫鞯囊蕾嚒?

其他工具輔助

運(yùn)維團(tuán)隊(duì)傳統(tǒng)使用網(wǎng)管工具類似SNMP、Netconf來(lái)收集網(wǎng)絡(luò)數(shù)據(jù)（例如：鏈路負(fù)載和丟包率等）監(jiān)控網(wǎng)絡(luò)健康狀況。這些工具還可以收集路由表和BGP鄰居的事件。然而，想要在這些工具里面加入新的采集數(shù)據(jù)并非易事，例如BGP收斂時(shí)間。這需要修改并且標(biāo)準(zhǔn)化網(wǎng)管協(xié)議。

Facebook在使用一個(gè)內(nèi)部監(jiān)控系統(tǒng)ODS。通過(guò)使用Thrift網(wǎng)絡(luò)接口（自研交換機(jī)FBOSS的網(wǎng)管接口），運(yùn)維團(tuán)隊(duì)可以監(jiān)控自己定制化的數(shù)據(jù)。然后，在ODS中存儲(chǔ)這些事件數(shù)據(jù)。最后，運(yùn)維團(tuán)隊(duì)可以通過(guò)人工或者自動(dòng)告警工具去查詢、分析他們的系統(tǒng)。

類似其他軟件，F(xiàn)acebook將BGP Agent集成到整個(gè)監(jiān)控框架中了。這使得更精細(xì)的BGP內(nèi)部狀態(tài)的監(jiān)控得以實(shí)現(xiàn)，例如：鄰居建立的數(shù)量、每個(gè)鄰居收發(fā)路由的數(shù)量、前面提及的收斂時(shí)間等等。使用這些數(shù)據(jù)可以檢測(cè)故障，并且實(shí)現(xiàn)自動(dòng)排錯(cuò)機(jī)制。

測(cè)試和灰度部署

參見(jiàn)下圖，兩種情況下需要進(jìn)行測(cè)試和部署：更新交換機(jī)配置和上線新的BGP Agent版本。開(kāi)發(fā)新的BGP功能、優(yōu)化或者修復(fù)安全問(wèn)題、為可靠性和效率進(jìn)行的BGP路由策略修改，都會(huì)觸發(fā)新一輪的測(cè)試和部署。通過(guò)持續(xù)測(cè)試和部署流程，F(xiàn)acebook可以能更快的推出新版本，確保數(shù)據(jù)中心更平滑的運(yùn)行、減少宕機(jī)。



圖10：Facebook整體變更、測(cè)試和部署流水線

測(cè)試

Facebook的測(cè)試主要有三個(gè)部分組成：?jiǎn)卧獪y(cè)試、仿真和灰度測(cè)試。

對(duì)于生產(chǎn)網(wǎng)絡(luò)，仿真是一個(gè)極有用的測(cè)試框架。類似CrystalNet（微軟的仿真測(cè)試平臺(tái)），F(xiàn)acebook開(kāi)發(fā)了BGP仿真框架去測(cè)試BGP Agent軟件、BGP配置和路由策略的實(shí)現(xiàn)，并用于整個(gè)網(wǎng)絡(luò)的BGP建模。仿真還可以用于測(cè)試各種故障情況下BGP的行為，例如：鏈路抖動(dòng)、鏈路中斷或者BGP重啟等情況。BGP Agent的升級(jí)和配置更新也納入了仿真過(guò)程。

在仿真過(guò)程中還可以發(fā)現(xiàn)一些會(huì)對(duì)生產(chǎn)網(wǎng)絡(luò)中服務(wù)造成危害的Bug。仿真測(cè)試可以大大地節(jié)約開(kāi)發(fā)人員的時(shí)間以及對(duì)大量硬件測(cè)試資源的需求。當(dāng)然，由于無(wú)法模擬底層的軟硬件，仿真工具無(wú)法實(shí)現(xiàn)高保真的模擬。在BGP收斂回歸測(cè)試中使用仿真就會(huì)很有挑戰(zhàn)，主要原因是Linux的容器會(huì)比硬件的交換機(jī)慢很多。

在成功的完成仿真測(cè)試以后，下一步將在生產(chǎn)網(wǎng)絡(luò)中進(jìn)行灰度測(cè)試。新的BGP Agent軟件或者新版本的配置會(huì)運(yùn)行在生產(chǎn)網(wǎng)絡(luò)中少量的叫做“Cannaris”交換機(jī)上。灰度測(cè)試可以使得有機(jī)會(huì)進(jìn)一步的捕獲之前沒(méi)有發(fā)現(xiàn)的問(wèn)題，同時(shí)增加上線的信心。通過(guò)挑選在生產(chǎn)網(wǎng)絡(luò)中的交換機(jī)，可以捕獲一些因?yàn)橐?guī)模導(dǎo)致的問(wèn)題，例如：交換機(jī)的收斂變慢。

灰度測(cè)試包含下面的一些場(chǎng)景：

1）從舊的BGP Agent 或者配置遷移到新的BGP Agent軟件或者新的配置，通常發(fā)生在部署階段；

2）從新的BGP Agent 或者配置遷移到舊的BGP Agent軟件或者配置，通常是在生產(chǎn)網(wǎng)絡(luò)遷移過(guò)程中發(fā)生故障，然后回退到舊版本或者配置；

3）BGP進(jìn)程發(fā)生GR（平滑重啟：Gracefual Restart，這是BGP實(shí)現(xiàn)中有利于實(shí)現(xiàn)平滑部署的最重要的一個(gè)功能）。日灰度測(cè)試通常運(yùn)行新版本一整天。生產(chǎn)網(wǎng)絡(luò)的監(jiān)控系統(tǒng)會(huì)對(duì)任何異常行為產(chǎn)生告警?；叶葴y(cè)試會(huì)幫助找到在仿真環(huán)境中沒(méi)有發(fā)現(xiàn)的Bug，比如底層函數(shù)庫(kù)變動(dòng)產(chǎn)生的問(wèn)題。

部署

當(dāng)變更（BGP Agent軟件或者配置）通過(guò)測(cè)試驗(yàn)證，就進(jìn)入了部署階段。在更高效的發(fā)布變更和維系總體可靠性之間需要找到一個(gè)平衡。不可能簡(jiǎn)單的切換整個(gè)數(shù)據(jù)中心的流量來(lái)進(jìn)行控制平臺(tái)的一次性升級(jí)，這對(duì)服務(wù)可用性造成極大的損害。所以，在部署環(huán)節(jié)，盡可能地減少對(duì)網(wǎng)絡(luò)的影響。這也是為了支持在生產(chǎn)網(wǎng)絡(luò)中可以快速、頻繁地進(jìn)行BGP的演進(jìn)。Facebook推出了一個(gè)推送計(jì)劃?rùn)C(jī)制來(lái)實(shí)現(xiàn)逐步部署中及時(shí)發(fā)現(xiàn)問(wèn)題。

推送機(jī)制

推送機(jī)制分成兩種類型：有損式和無(wú)損式，主要區(qū)別是：是否影響交換機(jī)上現(xiàn)有的轉(zhuǎn)發(fā)狀態(tài)。大部分的升級(jí)部署操作都是無(wú)損式的，不會(huì)影響現(xiàn)有的業(yè)務(wù)流量，比如性能優(yōu)化，軟件的集成系統(tǒng)變化等。為了減少在無(wú)損式部署過(guò)程中的路由不穩(wěn)定，GR（Gracefual Restart）是一個(gè)重要功能。

當(dāng)交換機(jī)在升級(jí)過(guò)程中，GR能確保BGP Agent軟件不會(huì)刪除現(xiàn)有轉(zhuǎn)發(fā)表的內(nèi)容。等待交換機(jī)重啟完畢、重新建立BGP鄰居關(guān)系、收斂路由以后，再次重新控制轉(zhuǎn)發(fā)表。在這個(gè)期間，如果沒(méi)有鏈路/設(shè)備發(fā)生故障，業(yè)務(wù)流量完全不會(huì)受到影響。如果沒(méi)有GR，這個(gè)過(guò)程會(huì)有業(yè)務(wù)影響，同時(shí)在節(jié)點(diǎn)重啟完恢復(fù)路由的過(guò)程中會(huì)經(jīng)歷網(wǎng)絡(luò)收斂抖動(dòng)。

有損式部署升級(jí)（例如：現(xiàn)有交換機(jī)路由策略發(fā)生改變）將會(huì)觸發(fā)新的宣告/撤銷更新發(fā)送給交換機(jī)，隨后會(huì)導(dǎo)致BGP進(jìn)行重新收斂。在這個(gè)過(guò)程中，業(yè)務(wù)流量可能會(huì)被丟棄或者走在次優(yōu)路徑上而導(dǎo)致延遲增加。因此，二進(jìn)制或者配置的更改會(huì)是有損式的，在進(jìn)行變更之前需要進(jìn)行隔離（Drain）操作。隔離操作會(huì)降低網(wǎng)絡(luò)整體的吞吐量，所以盡量把相關(guān)的有損式操作聚合集中到一起，可以減少對(duì)網(wǎng)絡(luò)的整體影響。

推送階段

Facebook定義了6個(gè)不同的部署推送階段，參見(jiàn)下表：P1 ~ P6 ，在升級(jí)過(guò)程中依次執(zhí)行。在每一個(gè)階段，推送引擎會(huì)根據(jù)該階段的規(guī)則隨機(jī)選擇一定數(shù)量的交換機(jī)，然后推送引擎將推送并重啟這些交換機(jī)上的BGP。這6個(gè)推送階段是逐步擴(kuò)大部署范圍的過(guò)程，最后一個(gè)階段推送到所有的交換機(jī)上。

P1 ~ P5 可以理解成擴(kuò)展測(cè)試階段：P1和P2是少量的RSW測(cè)試；P3是一個(gè)重要節(jié)點(diǎn)，因?yàn)槭峭扑偷剿蓄愋偷慕粨Q機(jī)上了；P3階段會(huì)選擇一個(gè)具備有負(fù)載分擔(dān)能力的Web服務(wù)數(shù)據(jù)中心，這樣即使發(fā)生問(wèn)題，對(duì)實(shí)際業(yè)務(wù)也影響不大。這種多樣化環(huán)境對(duì)評(píng)估升級(jí)是否安全尤為重要。

P4和P5會(huì)升級(jí)跨數(shù)據(jù)中心的相當(dāng)數(shù)量的交換機(jī)，即使發(fā)送嚴(yán)重故障，整個(gè)網(wǎng)絡(luò)的冗余性任然可以保障業(yè)務(wù)的高性能響應(yīng)。最后一步P6中，完成對(duì)剩下的所有交換機(jī)的升級(jí)。



表7：推送階段定義

推送監(jiān)控

為了在部署期間監(jiān)測(cè)問(wèn)題，F(xiàn)acebook使用一個(gè)可擴(kuò)展的服務(wù)BGPMonitor來(lái)監(jiān)控?cái)?shù)據(jù)中心的所有的BGP設(shè)備。所有的BGP設(shè)備會(huì)將所有收到的廣播/撤銷轉(zhuǎn)給BGPMonitor。BGPMonitor收集以后驗(yàn)證路由是否按照預(yù)期維持不變。例如，在一個(gè)無(wú)損式的升級(jí)中，一旦發(fā)現(xiàn)了有路由的廣播/撤銷（意味著可能造成業(yè)務(wù)影響），就停止推送升級(jí)并且向工程師報(bào)告這種潛在的問(wèn)題，工程師將分析問(wèn)題確定是否可以繼續(xù)升級(jí)推送過(guò)程。數(shù)據(jù)中心的實(shí)際運(yùn)行，F(xiàn)acebook通過(guò)BGPMonitor發(fā)現(xiàn)了一次停電故障。

推送結(jié)果

下圖展示了12個(gè)月的期間內(nèi)進(jìn)行的9次推送中各個(gè)階段的時(shí)間花費(fèi)。下圖同時(shí)也展示了高速迭代在數(shù)據(jù)中心的可行性，在快速的時(shí)間尺度上修復(fù)性能和安全問(wèn)題。也使得其他應(yīng)用程序能夠利用BGP的特性實(shí)現(xiàn)快速革新。P6階段最為費(fèi)時(shí)，因?yàn)樗枰幚頂?shù)量龐大的交換機(jī)。

在P1 ~ P5過(guò)程中，需要處理捕捉到的各種問(wèn)題，因此有些階段需要花費(fèi)更多一些的時(shí)間（超過(guò)一天）。在這12個(gè)月的52%的時(shí)間中，數(shù)據(jù)中心的BGP Agent軟件處于變更中（添加對(duì)BGP架構(gòu)的支持，修復(fù)Bug，優(yōu)化性能，安全補(bǔ)丁等）。



圖11：九次推送各階段的時(shí)間消耗

理想情況下，每個(gè)階段交換機(jī)的升級(jí)應(yīng)該100%成功完成。例如，有一次因?yàn)樾迯?fù)了一個(gè)安全漏洞，進(jìn)行了一次推送，但各種設(shè)備因?yàn)楦鞣N原因而無(wú)法連接。設(shè)備也會(huì)因?yàn)楦鞣N維護(hù)操作而不可達(dá)，造成在推送過(guò)程中無(wú)法訪問(wèn)。不可預(yù)知的硬件和電源問(wèn)題也會(huì)導(dǎo)致推送失敗。

無(wú)法推測(cè)各種不可達(dá)設(shè)備何時(shí)恢復(fù)，當(dāng)然也不期望由于少量的失敗而停止推送步驟，因此對(duì)于每個(gè)階段設(shè)置了99%的閾值，只要失敗的數(shù)量不大于1%那么就可以繼續(xù)進(jìn)行。下面的表格中顯示了12個(gè)月周期中最后三次推送的各個(gè)階段的失敗百分比，最差的一次（第7次）總體成功率也在99.43%。



表8：后三次推送各階段的失敗率

站點(diǎn)故障（SEV：Site EVents）

盡管具備了測(cè)試、部署推送策略，但數(shù)據(jù)中心控制層面的規(guī)模、進(jìn)化演進(jìn)的本質(zhì)、BGP的復(fù)雜性、與其他服務(wù)（例如：推送、隔離等）的交互以及人為錯(cuò)誤都不可避免地會(huì)造成網(wǎng)絡(luò)中斷。Facebook對(duì)2年內(nèi)發(fā)生的重大站點(diǎn)故障（SEV）做了分析、匯總。通常由兩大類原因?qū)е拢?br />
1）最新的配置或者BGP Agent軟件更新；

2）之前沒(méi)有碰到過(guò)的場(chǎng)景觸發(fā)了潛在的Bug。

通過(guò)多種監(jiān)控工具來(lái)捕捉網(wǎng)絡(luò)中的異常時(shí)間，這些工具包括：

1）事件數(shù)據(jù)存儲(chǔ)：ODS，用于記錄BGP的各項(xiàng)數(shù)據(jù)包括宕機(jī)時(shí)間；

2）Netsonar，檢測(cè)不可達(dá)設(shè)備；

3）NetNORAD，檢測(cè)服務(wù)器之間端到端的延遲、丟包率。

分析經(jīng)歷的14次站點(diǎn)故障，與BGP相關(guān)的主要是：路由策略、BGP軟件以及和工具軟件（推送框架、隔離框架）之間的交互。

一組站點(diǎn)故障是由于路由策略部署不完整/不正確造成的。例如，有一次更新配置中，需要在一層交換機(jī)中更改Community屬性，然后再另一層中匹配再操作。這本是應(yīng)該先更改、再匹配，需要有先后順序，但實(shí)際推送過(guò)程中，順序錯(cuò)誤造成數(shù)據(jù)中心內(nèi)的黑洞，損傷了多個(gè)服務(wù)的性能。

另一組站點(diǎn)故障是由BGP Agent軟件錯(cuò)誤造成的。一個(gè)站點(diǎn)故障是由于BGP實(shí)現(xiàn)中限制接收對(duì)端最大路由條目引發(fā)的，由于計(jì)算路由條目算法中的Bug，導(dǎo)致多個(gè)BGP進(jìn)程中斷了，最終導(dǎo)致服務(wù)SLA降格。

不同BGP Agent的版本之間的互操作也導(dǎo)致過(guò)故障。雖然設(shè)計(jì)了BGP GR，但舊版本中GR的計(jì)時(shí)器是30秒，但新版中卻是120秒，重啟30秒以后，舊版本路由器就已經(jīng)清除了轉(zhuǎn)發(fā)表，這個(gè)故障導(dǎo)致流失了大約90秒的流量。再次，BGPMonitor工具探測(cè)到了這個(gè)推送過(guò)程中的故障。

所有這些站點(diǎn)故障都通過(guò)回退到之前的穩(wěn)定的BGP Agent版本或者配置解決了，然后再下一次的更新中發(fā)布修復(fù)版本。問(wèn)題和故障的發(fā)生是必然的，所以一個(gè)優(yōu)秀的測(cè)試部署框架比具體的去解決軟件Bug、版本兼容等問(wèn)題更有效。在開(kāi)發(fā)的后期創(chuàng)建的仿真平臺(tái)，以及不斷新添加針對(duì)之前SEV的測(cè)試用例對(duì)整體流程進(jìn)行了持續(xù)的完善。

未來(lái)的工作內(nèi)容

基于前幾年的數(shù)據(jù)中心運(yùn)營(yíng)中發(fā)現(xiàn)的差距，介紹一下Facebook進(jìn)行的一些工作。

路由策略的管理

BGP支持豐富的策略框架。出入方向的策略是一個(gè)符合設(shè)計(jì)者意識(shí)的帶有多條規(guī)則的決策樹(shù)。雖然在設(shè)計(jì)中路由策略是整體、跨層的，但分布式策略的管理和推理也尤為重要。某些現(xiàn)有的控制層面的驗(yàn)證工具可以通過(guò)設(shè)備配置建模來(lái)驗(yàn)證策略，但無(wú)法支持實(shí)現(xiàn)靈活的復(fù)雜意圖。擴(kuò)展網(wǎng)絡(luò)驗(yàn)證來(lái)支撐大規(guī)模路由策略設(shè)計(jì)是一個(gè)重要的為了方向。擴(kuò)展網(wǎng)絡(luò)合成來(lái)支撐BGP設(shè)計(jì)和策略也是需要追尋的方向。

進(jìn)化的測(cè)試框架

路由策略的校驗(yàn)工具是假設(shè)底層的交換機(jī)的軟件是沒(méi)有錯(cuò)誤的，但有8個(gè)站點(diǎn)故障都是因?yàn)榈讓榆浖e(cuò)誤造成的?，F(xiàn)有的工具沒(méi)法主動(dòng)的檢查到這種問(wèn)題。作為補(bǔ)救方式，在部署之前，F(xiàn)acebook會(huì)用仿真平臺(tái)來(lái)檢測(cè)控制平面的問(wèn)題。在在線網(wǎng)絡(luò)中部署B(yǎng)GP的更新配置和BGP Agent軟件時(shí)，可能會(huì)觸發(fā)一些路由問(wèn)題，例如短暫的轉(zhuǎn)發(fā)環(huán)路和黑洞。

有10個(gè)站點(diǎn)故障是由于部署更新觸發(fā)的。為解決這類問(wèn)題，在仿真平臺(tái)上模擬整個(gè)部署過(guò)程，并且驗(yàn)證各種部署策略的影響。為了更貼近的模擬硬件交換機(jī)以及軟硬件組合的一些場(chǎng)景，還需要探索更多的新技術(shù)。Facebook同時(shí)也擴(kuò)展了測(cè)試框架，包括一些商用的網(wǎng)絡(luò)協(xié)議驗(yàn)證工具以及模糊（Fuzz）測(cè)試。

網(wǎng)絡(luò)協(xié)議驗(yàn)證工具（Keysight的IxanvlTM）可以確保BGP Agent軟件符合RFC的要求，模糊測(cè)試可以增加BGP Agent的健壯性，在面對(duì)無(wú)效、非預(yù)期或者隨機(jī)的BGP消息而具備良好的故障處理能力。

故障下的負(fù)載分擔(dān)

經(jīng)過(guò)幾年的運(yùn)維，F(xiàn)acebook觀察到在設(shè)備處于故障情況下或者在隔離狀態(tài)下，會(huì)發(fā)生負(fù)載分擔(dān)出現(xiàn)不均衡的狀態(tài)。查看圖1，RSW會(huì)將流量發(fā)送到上游的4臺(tái)FSW，對(duì)每臺(tái)FSW會(huì)發(fā)生1/4的流量，每臺(tái)FSW又將自己的1/4的流量（等同于RSW上行的1/16）發(fā)送給4臺(tái)各自的上聯(lián)的SSW。

這個(gè)時(shí)候假設(shè)一臺(tái)SSW出現(xiàn)故障，但基于現(xiàn)在的設(shè)計(jì)和路由處理的方式，RSW對(duì)此毫無(wú)感知，所以有故障的SSW下聯(lián)的那臺(tái)FSW還是收到和其他FSW一樣的流量，但它的上聯(lián)只有3個(gè)SSW，那么這3臺(tái)SSW比其他12臺(tái)SSW收到的流量要多。最理想的情況是RSW能感知到這個(gè)變化，那么向FSW發(fā)送的時(shí)候就是按照：給三個(gè)無(wú)故障的FSW發(fā)送4/15，給有故障的FSW發(fā)送3/15，這樣RSW上行的流量在所有的SSW上面是均衡的。集中式的SDN的控制方式可以容易的實(shí)現(xiàn)，但Facebook基于現(xiàn)有的整體框架，還是考慮使用WCMP通過(guò)BGP路由的方式來(lái)解決。

相關(guān)的工作

在數(shù)據(jù)中心使用BGP的設(shè)計(jì)

在大型的數(shù)據(jù)中心中的路由設(shè)計(jì)，有一些不同的實(shí)現(xiàn)方法，比如使用集中的SDN的方式，另一種是按照RFC7938里面描述的基于BGP的方式。

對(duì)應(yīng)后一種，F(xiàn)acebook的方式還略有不同，比如：Facebook使用了BGP聯(lián)邦屬性，這樣使得16比特的AS號(hào)可以在不同的數(shù)據(jù)中心中重復(fù)使用，簡(jiǎn)化了很多工作；還有，并沒(méi)有使用“Allow AS In”的BGP特性，在某些設(shè)計(jì)中比如同層FSW使用相同的AS號(hào)，那么備份路由勢(shì)必會(huì)有相同的AS號(hào)一前一后的夾帶在AS-Path中，那么就必須使用“Allow AS In”去取消BGP自帶的防環(huán)機(jī)制，相反在詳細(xì)路由傳播范圍的控制中，F(xiàn)acebook還需要防環(huán)功能自動(dòng)的阻止路由的隨意傳播；還有一個(gè)區(qū)別是：使用了路由聚合來(lái)精簡(jiǎn)了路由條目、加快了收斂，控制了詳細(xì)路由的傳播、增加了網(wǎng)絡(luò)穩(wěn)定性。另外一個(gè)重要區(qū)別是：通過(guò)嚴(yán)格的路由策略設(shè)計(jì)，實(shí)現(xiàn)預(yù)先設(shè)計(jì)好的備用路徑，增加了網(wǎng)絡(luò)的可達(dá)性和可靠性；也給主機(jī)提供VIP的主備路徑選擇的能力。

Google的Jupiter中使用SDN的方式來(lái)實(shí)現(xiàn)數(shù)據(jù)中心的路由控制，通過(guò)集中的路由控制器去采集、發(fā)送鏈路狀態(tài)，這需要一個(gè)獨(dú)立的帶外CPN（Control Plane Network）網(wǎng)絡(luò)，在其中運(yùn)行一個(gè)定制的IS-IS協(xié)議去同步拓?fù)錉顟B(tài)。Google選擇SDN的原因與他們使用的定制化的硬件（OpenFlow）以及其網(wǎng)絡(luò)獨(dú)有的特性有關(guān)系。Facebook選擇去中心化的BGP的實(shí)現(xiàn)方式的主因還是：靈活的路由策略控制、大規(guī)模網(wǎng)絡(luò)的支持、自己的操作熟悉性和第三方廠家的支持（自研和第三方設(shè)備可以統(tǒng)一納管）。

運(yùn)維框架

通過(guò)參考CrystalNet（微軟的網(wǎng)絡(luò)仿真驗(yàn)證框架）、Janus（變更規(guī)劃工具）等工具，F(xiàn)acebook的運(yùn)維框架不斷的增強(qiáng)、完善：在運(yùn)維框架中集成監(jiān)控工具、部署框架、運(yùn)維計(jì)劃（有損式變更推送）；同時(shí)針對(duì)其他公司（Google）和研究機(jī)構(gòu)匯總的各種網(wǎng)絡(luò)問(wèn)題，通過(guò)吸收學(xué)習(xí)來(lái)不斷的增加測(cè)試框架中的各種場(chǎng)景，提高最終測(cè)試驗(yàn)證的質(zhì)量。

網(wǎng)絡(luò)邊緣的BGP

Facebook的Edge Fabric和Google的Espresso都是在邊緣依靠BGP來(lái)調(diào)度優(yōu)化和最終用戶交互的廣域網(wǎng)流量，都依靠集中調(diào)度的方式來(lái)在不同的BGP鄰居之間導(dǎo)流，同時(shí)也會(huì)優(yōu)化路徑實(shí)現(xiàn)更低的延遲、更少的丟包和更快的速度。類似數(shù)據(jù)中心內(nèi)的網(wǎng)絡(luò)設(shè)計(jì)的不同，Google還是選擇了集中SDN的控制方式，而Facebook則是用集中輔助控制的方式處理需要優(yōu)化的流量，大量的不需要優(yōu)化的流量還是由分布式的BGP自己控制。

自研的軟件和組件

通過(guò)整體描述下來(lái)，F(xiàn)acebook的BGP實(shí)踐看似簡(jiǎn)單：簡(jiǎn)單說(shuō)就是一個(gè)BGP Agent的實(shí)現(xiàn)以及整體的BGP HLD而已，但實(shí)際仔細(xì)解讀，里面有很多提及的看似不重要的部分卻為網(wǎng)絡(luò)整體的可用、可靠奠定了牢固的基礎(chǔ)。我們?cè)趨R總一下整體需要的組件：

BGP設(shè)計(jì)

· BGP聯(lián)邦：實(shí)現(xiàn)AS號(hào)復(fù)用，同時(shí)精簡(jiǎn)路由控制策略

·路由匯聚：減少RIB和FIB，增加網(wǎng)絡(luò)穩(wěn)定

· Community設(shè)定：設(shè)定路由傳播范圍，顯式確定備份路徑

· BGP路由策略：備份路徑、運(yùn)維操作、減少運(yùn)算開(kāi)銷

自研BGP Agent

· GR先行：Graceful Restart是運(yùn)維部署中最重要的功能

·有限功能集合：縮短開(kāi)發(fā)周期，減少開(kāi)發(fā)難度

·多線程支持：有效利用現(xiàn)在CPU的多核

·定制改動(dòng)：同一對(duì)地址上運(yùn)行多個(gè)BGP進(jìn)程，利于VIP Injector廣播路由

·策略引擎：基于LRU的緩存能減少計(jì)算開(kāi)銷、縮短收斂時(shí)間

·配合運(yùn)維：增加BGP的監(jiān)控?cái)?shù)據(jù)項(xiàng)的收集

VIPInjector

·運(yùn)行在服務(wù)器上的BGP進(jìn)程，用來(lái)向RSW廣播服務(wù)地址

網(wǎng)絡(luò)管理控制平臺(tái)（Robotron）

·意圖化：通過(guò)原子建模完成整個(gè)網(wǎng)絡(luò)的鏡像

·自動(dòng)生成配置：由建模生成具體配置

·設(shè)備配置管理：下發(fā)配置，版本控制

·監(jiān)控：采集運(yùn)行數(shù)據(jù)匹配到模型，來(lái)確定網(wǎng)絡(luò)設(shè)備狀態(tài)

測(cè)試框架

·開(kāi)發(fā)仿真：開(kāi)發(fā)驗(yàn)證、縮短開(kāi)發(fā)時(shí)間

·部署仿真：第一步的變更驗(yàn)證

·灰度測(cè)試：舊->新，新->舊，重啟等

· Cannaris：少量生產(chǎn)環(huán)境驗(yàn)證

部署框架

·自動(dòng)推送框架：自動(dòng)推送，部署，重啟，回退

· BGPMonitor監(jiān)控：監(jiān)控路由狀態(tài)

· ODS：事件存儲(chǔ)服務(wù)

· NetNORAD：時(shí)延丟包檢查子模塊

· Netsonar：設(shè)備可達(dá)性檢查模塊

審核編輯：劉清