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

Facebook在數(shù)據(jù)中心內(nèi)部一直使用自研交換機構(gòu)建IP CLOS架構(gòu)的數(shù)據(jù)中心。我們可以從Facebook在2019年披露的F16和HGRID看到他們是如何構(gòu)建超大型DC網(wǎng)絡(luò)的物理拓撲架構(gòu)。

在2021年的NSDI會議上面Facebook將內(nèi)部如何使用BGP來構(gòu)建網(wǎng)絡(luò)控制層面的細節(jié)公布出來了，簡單說這就是一份非常好的HLD（High-Level Design）的參考，從中我們也能看到除了網(wǎng)絡(luò)的物理架構(gòu)、協(xié)議邏輯之外還需要大量的整體軟件控制架構(gòu)及其組件的實現(xiàn)。我們先看看Facebook的數(shù)據(jù)中心 BGP的HLD：

設(shè)計的考量

在設(shè)計之初Facebook確定了整體設(shè)計的原則：配置“一致性”和運維“簡單性”。

IP CLOS數(shù)據(jù)中心架構(gòu)選用BGP是一個非常成熟的方案。對比iBGP和eBGP來看，eBGP作為DCN內(nèi)部的路由協(xié)議會有更多的優(yōu)點，例如：相比iBGP更容易做控制，避免了IGP的使用（無論使用哪種IGP都會帶來額外的復(fù)雜和開銷），BGP更加可靠、靈活也符合預(yù)期的一致性和簡單性原則。

如何解決BGP存在的問題

BGP作為互聯(lián)網(wǎng)上唯一的廣域跨域路由協(xié)議已經(jīng)使用了幾十年，在這漫長的使用發(fā)展過程中，積累了很多使用中出現(xiàn)的問題，簡單將BGP直接引入數(shù)據(jù)中心內(nèi)部將面臨很多調(diào)整，有在互聯(lián)網(wǎng)上面應(yīng)用而累積的BGP的自身問題，也有數(shù)據(jù)中心和互聯(lián)網(wǎng)場景不同導(dǎo)致的適配問題，我們需要應(yīng)對這些問題才能確保設(shè)計落地。

匯總業(yè)內(nèi)的一些研究論文以及面臨的問題可以總結(jié)成三個BGP的問題：1）BGP的收斂問題；2）BGP路由穩(wěn)定性；3）錯誤配置帶來的風(fēng)險；

BGP的收斂問題

在互聯(lián)網(wǎng)上面使用BGP來宣告路由網(wǎng)段會傳播到全球網(wǎng)絡(luò)中去，由于通常網(wǎng)絡(luò)具備多個出口，所以BGP路由在這種情況下更多的考量是路由的穩(wěn)定，避免更多的不必要的宣告而造成的持續(xù)不斷的路由震蕩。在這種情況下，BGP協(xié)議通常會有一個MRAI （Min-Route-Advertisement-Interval）計時器，路由器收到路由以后等待計時器（例如：有的廠家定義eBGP為5秒）規(guī)定的時間以后再發(fā)送出去，這樣的好處是：如果在計時器內(nèi)有新的變化可以少一些路由更新發(fā)送出去。

但這個特性顯然不適配數(shù)據(jù)中心內(nèi)的應(yīng)用場景，數(shù)據(jù)中心內(nèi)部使用eBGP來替代IGP需要更快的路由收斂，所以MRAI的設(shè)置在這里選擇為0，對于一個典型的7-Stage數(shù)據(jù)中心的架構(gòu)可以節(jié)省很大路由收斂延遲。無論Facebook的自研BGP軟件，還是商用路由器都可以很簡單的實現(xiàn)這一點。

收斂性和路由傳播的范圍也直接相關(guān)，因此能減少全網(wǎng)傳播的路由有利于收斂、同時增加路由穩(wěn)定性。在Facebook的數(shù)據(jù)中心網(wǎng)絡(luò)中非常精巧的設(shè)計了路由匯聚的原則，這樣可以控制路由的傳播范圍，詳細路由只會在小區(qū)域內(nèi)傳遞，不會影響其他區(qū)域。

BGP路由穩(wěn)定性

Labovitz 等人對互聯(lián)網(wǎng)上BGP運行存在的一些不穩(wěn)定因素做了一些研究：一些有問題的BGP更新報文會成為導(dǎo)致路由不穩(wěn)定的主要因素。我們看看如何在數(shù)據(jù)中心內(nèi)部來應(yīng)對這些可能出現(xiàn)的問題，這樣才能確保數(shù)據(jù)中心內(nèi)部運行BGP的穩(wěn)定性。這些問題如下表所示：



表1：故障BGP的更新報文種類

Facebook在自研的BGP軟件上加入了一些特性來規(guī)避上面的這些問題。自研的BGP Agent軟件具備足夠大的內(nèi)存，可以用來存儲所有BGP路由的狀態(tài)，所以針對問題1和2，可以在存儲的BGP路由狀態(tài)表中先做對比運算，避免不必要的BGP更新報文的重復(fù)發(fā)送；對于問題3（AADiff），F(xiàn)acebook利用設(shè)計來解決：預(yù)先設(shè)置好固定的Local Preferance屬性來規(guī)避；對于問題4需要通過整體系統(tǒng)來解決：使用一套監(jiān)控系統(tǒng)來自動探測故障，發(fā)生故障的時候自動隔離（Drain）繞開故障組件。

錯誤配置帶來的風(fēng)險

人為的配置錯誤造成的故障一直在網(wǎng)絡(luò)中占有很高的比例，研究表明每天全球都有1%數(shù)量的路由是因此問題造成的。研究報告指出有三類BGP錯誤配置會導(dǎo)致這些問題：

1.誤配BGP的屬性

BGP Policy的復(fù)雜性會非常容易引起錯誤配置導(dǎo)致故障，可以通過兩點來加強：a）具備嚴格發(fā)布流程的自動化工具；b）在收發(fā)兩端來同時配置限制條件，確保即使一端錯誤配置也不會發(fā)布到更廣的區(qū)域。

2.BGP與其他協(xié)議互操作

一些設(shè)計不那么完美的實踐中，會存在BGP和IGP的互操作，將部分IGP路由導(dǎo)入BGP或者反之，這非常容易出現(xiàn)影響面很大的故障。在Facebook的數(shù)據(jù)中心網(wǎng)絡(luò)里面沒有IGP協(xié)議，不存在兩種協(xié)議互操作的問題。

3.更新配置導(dǎo)致的問題

設(shè)備重啟之前配置未保存等情況會導(dǎo)致BGP運行的配置不是實際期望的，從而導(dǎo)致故障發(fā)生。應(yīng)對這種問題，F(xiàn)acebook設(shè)計的系統(tǒng)具備集中的配置數(shù)據(jù)庫用來監(jiān)控設(shè)備運行的配置版本，確保在運行、割接等等狀態(tài)始終保持一致性原則。

BGP高階設(shè)計

相比中心控制的SDN實現(xiàn)方式，F(xiàn)acebook選擇的BGP主要基于三點原因：

1）SDN的構(gòu)建、發(fā)開需要更長的周期和實現(xiàn)的復(fù)雜度才能交付整體期望的可擴展性和可靠性；

2）BGP在大規(guī)模網(wǎng)絡(luò)上有被驗證過的良好表現(xiàn)，同時也可以在第三方設(shè)備上進行BGP實現(xiàn)；

3）Facebook的自研交換機FBOSS已經(jīng)運行了這個BGP Agent，使用BGP方案可以無縫在集成之前的整體技術(shù)思路。

摒棄IGP，直接使用eBGP作為DCN內(nèi)部協(xié)議已經(jīng)是一種成熟的解決方案，這里不再贅述。這樣的選擇也更加容易契合配置一致性和運維簡單性的總體設(shè)計原則。

物理拓撲

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

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

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

2）Fabric交換機層（FSW）。

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

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

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



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

路由設(shè)計原則

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

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

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

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

BGPPeering設(shè)計

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

多條互聯(lián)鏈路的情況下，每條鏈路都使用獨立的3層IP互聯(lián)，同時創(chuàng)建eBGP進程。另外，參加圖1和圖2，仔細觀察可以看到每層內(nèi)部并沒有同層的互聯(lián)鏈路，例如RSW不會互聯(lián)另一個RSW，其他兩層同理。在這個物理設(shè)計下，不會需要同層內(nèi)的BGP進程，這也簡化了物理拓撲和路由邏輯。

ECMP（等價多路徑）在這種物理拓撲下將成為最大的特性，通過BGP的路由策略來確保盡可能多的可用路徑能參與ECMP。在交換機的FIB編程中，處理端口的Up/Down只會涉及到ECMP下一跳組數(shù)據(jù)結(jié)構(gòu)內(nèi)的增刪，在這種設(shè)計下，這個操作是非常容易處理的。WCMP（加權(quán)的ECMP）會需要更高的硬件要求，目前Facebook沒有使用。

AS號分配設(shè)計

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

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

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

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



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

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

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

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

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

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

Spine平面

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

路由匯聚設(shè)計

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

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

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

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



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

BGP路由策略

Facebook使用的是BGP的公認屬性來進行路由策略的匹配、控制。利用這些屬性可以方便地控制BGP路由的傳播范圍以及屏蔽一些不期望的路徑。路由策略的設(shè)計中依然兼?zhèn)淞艘恢滦院秃唵涡缘脑瓌t。

路由策略的目標

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

表2：路由策略的目標

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

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

＞可靠性

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

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



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

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

參見圖5b：

如果fsw1和rsw1之間的鏈路發(fā)生故障，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裝載在本地轉(zhuǎn)發(fā)表之外不會再廣播出去，因為這是經(jīng)過備份路徑廣播過來的路由。

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



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

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

在rsw和fsw之間的路由策略中，一端的出方向（export）的策略和另一端的入方向（import）的策略在邏輯上是一致的，比如出方向匹配某個Community的屬性，另一端的入方向也有同樣的匹配條件，這樣可以有效地減少因為錯誤配置帶來的故障。

＞可維護性

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

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

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



表3：路由策略的目標

通過對相關(guān)的設(shè)備的路由策略的變更來實現(xiàn)設(shè)備的隔離以及重新恢復(fù)服務(wù)?；谥暗囊恍┒嗉壐綦x經(jīng)驗，F(xiàn)acebook實現(xiàn)了具有“WARM”狀態(tài)的多級隔離流程，更好地為業(yè)務(wù)流量服務(wù)。在WARM狀態(tài)下，通過更改BGP策略來降低隔離設(shè)備的的路由優(yōu)先級，同時調(diào)整本地、對端的ECMP的組，避免隔離和恢復(fù)業(yè)務(wù)時可能造成的鏈路流量過載。

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

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

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

＞可擴展性

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

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

＞服務(wù)可達性

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

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

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

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

路由策略的配置

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

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

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

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

路由策略變更

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

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

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

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

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

選取有限功能

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

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



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



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



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

多核多線程支持

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

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

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

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



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

路由策略實現(xiàn)

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

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

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

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

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

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



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

服務(wù)可達性

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

在實際操作中這變得不太可行，因為應(yīng)用程序?qū)ψ⑷脒M程不可見，并且還存在故障的依賴問題：

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

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

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

其他工具輔助

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

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

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

測試和灰度部署

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



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

測試

Facebook的測試主要有三個部分組成：單元測試、仿真和灰度測試。

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

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

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

灰度測試包含下面的一些場景：

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

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

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

部署

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

推送機制

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

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

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

推送階段

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

P1 ~ P5 可以理解成擴展測試階段：P1和P2是少量的RSW測試；P3是一個重要節(jié)點，因為是推送到所有類型的交換機上了；P3階段會選擇一個具備有負載分擔(dān)能力的Web服務(wù)數(shù)據(jù)中心，這樣即使發(fā)生問題，對實際業(yè)務(wù)也影響不大。這種多樣化環(huán)境對評估升級是否安全尤為重要。

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



表7：推送階段定義

推送監(jiān)控

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

推送結(jié)果

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

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



圖11：九次推送各階段的時間消耗

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

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



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

站點故障（SEV：Site EVents）

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

2）之前沒有碰到過的場景觸發(fā)了潛在的Bug。

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

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

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

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

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

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

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

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

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

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

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

路由策略的管理

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

進化的測試框架

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

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

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

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

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

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

相關(guān)的工作

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

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

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

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

運維框架

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

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

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

自研的軟件和組件

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

BGP設(shè)計

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

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

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

· BGP路由策略：備份路徑、運維操作、減少運算開銷

自研BGP Agent

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

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

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

·定制改動：同一對地址上運行多個BGP進程，利于VIP Injector廣播路由

·策略引擎：基于LRU的緩存能減少計算開銷、縮短收斂時間

·配合運維：增加BGP的監(jiān)控數(shù)據(jù)項的收集

VIPInjector

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

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

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

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

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

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

測試框架

·開發(fā)仿真：開發(fā)驗證、縮短開發(fā)時間

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

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

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

部署框架

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

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

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

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

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

審核編輯：劉清