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將在以后陸續詳述）

BGPPeering設計

三層交換機每層之間都是用單跳的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的監控數據項的收集

VIPInjector

·運行在服務器上的BGP進程，用來向RSW廣播服務地址

網絡管理控制平臺（Robotron）

·意圖化：通過原子建模完成整個網絡的鏡像

·自動生成配置：由建模生成具體配置

·設備配置管理：下發配置，版本控制

·監控：采集運行數據匹配到模型，來確定網絡設備狀態

測試框架

·開發仿真：開發驗證、縮短開發時間

·部署仿真：第一步的變更驗證

·灰度測試：舊->新，新->舊，重啟等

· Cannaris：少量生產環境驗證

部署框架

·自動推送框架：自動推送，部署，重啟，回退

· BGPMonitor監控：監控路由狀態

· ODS：事件存儲服務

· NetNORAD：時延丟包檢查子模塊

· Netsonar：設備可達性檢查模塊

審核編輯：劉清