DCN場景下的BGP協議優化特性總結

【BGP協議】本文將通過某互聯網公司工程師小李在建設DCN時候的親身填坑經歷來了解BGP協議在數據中心場景的優化特性。

發布時間：2019-11-21
點擊量：
點贊：

分享至

我想評論

前言

隨著超大型互聯網數據中心的規模優勢愈加明顯，特別是在IPv4、IPv6雙棧模式下，對于我們網絡工程師而言，所面臨的建設和維護壓力也是越來越大。在上一篇文章《大型數據中心BGP路由協議規劃》中，我們討論了BGP路由協議在數據中心的規模部署，可以大大提升網絡的路由性能，簡化網絡規劃，但是數據中心網絡畢竟與傳統廣域網不同，對于BGP的部署和運維要求也會存在差異，通過優化BGP協議可以進一步提升網絡路由性能及簡化運維。本文將通過某互聯網公司工程師小李在建設DCN時候的親身填坑經歷來了解BGP協議在數據中心場景的優化特性。

-------------我是華麗麗的分割線------------

我是小李。

我上大學念的是法律專業，為了省點網費，跟校園網部署的銳捷認證計費系統進行了多年的斗智斗勇，也因此愛上了網絡這個行當，并且考取了銳捷網絡的RCIE（銳捷認證網絡專家）認證，畢業后順利地進入了一家互聯網企業工作，每天就是處理各種網絡的建設、規劃、配置、變更，也可謂是經驗豐富的老司機。

下面，就是我的故事，請仔細聽噢！

網絡建設篇

早晨，小李吹著口哨聽著歌，一進辦公室就接到了老板一個大活，要建設一個可以容納5萬臺以上服務器的數據中心，業務服務器需要運行IPv4和IPv6雙棧模式，先給出詳細的網絡設計方案和規劃。對于網絡規劃，除了物理組網外，比較復雜的就是路由、地址等規劃，但是作為銳捷《大型數據中心BGP路由協議規劃》文章的優秀讀者，小李對于路由協議的選擇和規劃沒有任何疑慮，但考慮到雙棧模式下會有大量的接口地址以及管理地址，頓感煩躁！

擺在面前的情況是：

服務器雙棧運行，意味著網絡也要開啟雙棧模式；

大量設備互聯地址及管理地址規劃，包括IPv4和IPV6；

BGP的IPv4鄰居和IPv6鄰居配置。

按照傳統配置方法當然能實現，這個沒有任何問題，但小李作為一個有著創新意識的互聯網一線大廠工程師，并未急于按照經驗進行規劃，有沒有更簡單的方案呢？經過一番廠家的交流，小李采用銳捷網絡提供的規劃方案：

1.基于Linklocal地址建立會話---簡化IPv6地址的分配
Link-localaddress是IPv6協議棧引入的新地址類型，接口開啟IPv6協議后，可以自動生成Link-localaddress（FE80::/10），并且地址為本地鏈路有效。設備支持基于Link-local地址建立多個BGP鄰居，從而可以免去規劃分配獨立的IPv6地址。
2.單BGP會話雙棧路由---減少BGP鄰居數量
僅通過IPv4地址或者僅通過IPv6地址建立一個BGP鄰居會話，同時實現IPv4、IPv6雙棧路由傳遞的功能，從而達到節省設備鄰居表項。

小李發現這兩個功能在這種場景下的結合簡直不要太好用，通過IPv6的Link-local address，通過指定鄰居接口即可建立BGP鄰居，并基于每個鄰居激活IPv4、IPv6雙棧路由模式，從而實現單IPv6會話，傳遞IPv4、IPv6雙棧路由。

小李的規劃提交給了領導后，馬上獲得審批通過，并立即開始建設執行，就在服務器批量上線的時候，小李又接到了一個新的需求，數據中心單獨規劃一個POD，這個POD服務器要運行Docker，宿主機要與TOR交換機之間需要通過BGP進行路由交換，宿主機的網段已經規劃完成，但具體地址要等業務上線的時候才能拿到，做好心理準備吧！

小李大吃一驚，什么心理準備啊，還不是業務每上線一臺宿主機我都要配合他們做一次 BGP鄰居對接配置嗎？按照業務上線的習慣每次都要等到后半夜才能上線，難不成，每天就為了配置一個BGP鄰居，一分鐘不到的事情，還要跟他們一起加個班么？

加班雖好，但是工作內容價值不高。所以小李開始琢磨，既然網段已經規劃好，如果BGP的鄰居能基于網段建立，那不就不需要每天跟業務線的人一起加班了么？

通過翻閱設備手冊，小李還真的發現了這個功能：

基于網段被動建立會話
網絡設備配置基于網段的BGP鄰居，配置此模式后，不會主動發起BGP鄰居建立請求，而是被動接收到對端鄰居發起建立請求后，根據鄰居地址生成對應的真實鄰居，并建立會話。

時間指向晚上八點鐘，配置完成，大功告成。作為一個互聯網一線大廠的優秀工程師，小李吹著口哨聽著歌打卡下班了，還有時間健個身，心里美滋滋。

網絡擴容篇

某日，小李得到領導安排的一項新的任務，近期公司要上線一批AI業務，規模雖然不大，但是原有網絡的收斂比較高，恐怕不能滿足高性能計算的需求，要求小李針對一個POD進行擴容，降低收斂比，但又不能影響原來在線的業務，擴容后的網絡架構，如圖一所示：

▲ 圖一：POD擴容架構

小李接到任務后，心里自喜，采用Spine-Leaf的一個很大的好處就是橫向擴容方便，于是就按照規劃割接第一臺POD-Spine設備上線，這時候業務反饋有少量的丟包。?。侩m然是少量丟包，但也引發了小李深深的思考，到底是怎么回事呢？

檢查配置OK、路由學習正常，為什么有丟包呢？經過仔細分析，小李發現原來問題的根源在于路由表項的安裝差異上，新的POD-Spine上線后，向POD-Leaf以及Spine通告了自己的路由，并學習網絡的路由，就在此時，對于POD-Leaf來說，ECMP由兩條，立刻變成了三條，并且發送數據流量，與此同時新上線的POD-Spine設備雖然完成了網絡路由的學習，但安裝這些路由表項需要一定的時間，從而有一個時間差，導致服務器的流量出現了少量的丟包，那如何解決這個問題呢？小李此時想如果設備能夠先將路由學習并安裝完成以后，再向鄰居通告自己完整的路由，那這個時間差不就不存在了嗎？想到這里，小李通過翻閱設備手冊發現：

BGP路由延遲通告
將學習到的路由先安裝到硬件路由表項后，再向鄰居通告這些路由

有了這個功能后應該就能解決這個問題了吧！小李立刻進行了第二臺POD-Spine設備的上線，并開啟了此功能，同時還請業務組同事實時監控服務器的丟包情況，發現第二臺設備上線后沒有造成任何的丟包。搞定，勝利，歐耶~

故障處理篇

天有不測風云，人有旦夕禍福，小概率事件也是會發生的。

如圖二所示：

▲ 圖二：網絡維護區域

這天工程師小王找小李哭訴，由于Spine節點設備出現故障、宕機，導致小王被業務部門投訴，表示出現了10多秒的丟包。咱們網絡有10K多的路由，收斂也需要時間啊，丟點包怎么了，業務又沒斷。咦？你負責的區域應該同樣會受到這臺設備故障牽連，你怎么還能那么瀟灑呢，業務部門沒有投訴你嗎？

這時小李低聲說，告訴你一個秘籍吧，保你輕松應對“黑天鵝事件”，這個秘籍叫做：

BGP的PIC（prefix independent
convergence）快切
BGP的PIC快切實現了路由前綴無關的收斂，收斂速度與路由規模無關，因此能實現大規模路由的快速切換。

PIC快切功能基于AS號來實現，在EBGP之間啟用，開啟PIC快切功能后，BGP發布路由時會攜帶PIC擴展團體屬性，接收該BGP路由的交換機會根據發布者的AS號和router-id分配一個唯一的索引ID，通過優選計算后會攜帶該索引下發到轉發面。當發布者上行鏈路全部中斷，無法收到此AS的路由信息時，通過查找對應的索引ID，通告轉發面將關聯該ID的路由一次性完成切換，從而實現業務的快速收斂，無需等待逐條刪除路由來收斂（普通路由收斂需要逐條刪除失效路由信息，因此收斂時間與路由規模強相關）。

簡單來說呢，就是來自故障節點設備（Spine）發布的路由，POD-Spine設備通過BGP的私有屬性進行了歸類分組，并且攜帶私有屬性將路由通告下游（POD-Leaf），一旦Spine節點故障，POD-Spine自身會快速切換，并通過私有屬性通告POD-Leaf全部路由失效并進行切換。這樣，我的這個POD內部就能夠實現快速的收斂了。這種實現方式做到了與前綴無關的路由收斂，并且非常適用于大規模的路由切換，實測數據顯示：

12K路由收斂實測：

未開啟PIC快切：13S

開啟PIC快切：1S以內(0.7S)（此切換時間不隨路由規模變化而變化，在大規模路由情況下尤為適用）

那既然是私有屬性，只能自己識別，別的設備不支持會影響路由學習嗎？小王疑惑地問。不會的，對于不支持這個屬性的設備，會自動過濾掉這個信息，不會影響其他設備路由的正常學習。好吧，今天又漲知識了，帶著滿臉佩服表情的小王回到了自己的工位，并將所學知識點立即應用到自己的網絡，降低“黑天鵝事件”發生后產生的損失。

核心遷移篇

有人問這次互聯網寒冬到底有多冷，小李表示，到底有多冷我不知道，但要做的事情一點沒有少。這不，又接到了一個新機房建設任務。接到任務的小李，立即進行了網絡的規劃以及硬件核對，發現還缺少兩臺POD-Spine設備？難不成這個設備也要從那個機房遷移過來嗎？小李得到的回復是肯定的，那個老機房的業務沒有按照預期計劃部署，流量沒有那么高了，將收斂比提高一下，并下線兩臺POD-Spine設備吧，但一定不能影響業務哦~

▲ 圖三：某某機房網絡架構

設備下線，要先將待下線設備流量遷移走，保證不影響業務，這時小李通過與設備廠家溝通，獲取了幾種BGP流量遷移的方式：

Neighbor shutdown
通過向鄰居發送notification報文來告知鄰居已經人為shutdown鄰居關系，常用于框式設備單線卡隔離變更。

Graceful shutdown
向鄰居設備發送UPDATE報文，用于通告優先級低的路由（local-preference 值為0或MED值為4294967295），并且會攜帶知名的gshut community，從而使鄰居設備進行路由更新，使其流量預先切換到備份鏈路或其他等價鏈路上。

BGP advertise-map
通過向鄰居發送UPDATE報文攜帶的withdraw routes字段，告知鄰居路由失效，鄰居收到UPDATE報文之后會更新本地路由表，從而將相關的路由都刪除。從使其的流量切換到備份鏈路或其他等價鏈路上。

通過原理的對比分析，小李總結出這幾種流量遷移方式的差異點，如表1所示

▲ 表一：BGP流量遷移方式總結

經過對比分析，小李發現Neighbor shutdown方式太暴力，還會丟包;Graceful shutdown雖然不丟包，但需要等待路由收斂，時間比較長，而第三種BGP Advertise-Map直接通告路由失效的方式，既快捷又不丟包，而且特殊場景還可以通過ACL加以控制，就用它了。

總結

技術路漫漫，只有通過不斷地學習、積累和實踐才能進取前行。在DCN場景下的BGP優化主要的側重點在于在雙棧模式下簡化BGP協議的部署、提高BGP協議的收斂性能以及平穩的流量遷移。網工小李把他工作中的經歷毫無保留地分享給了其他的網工，希望他們有所收獲。而他也在技術路上不斷的成長，終于穿上了他心愛的格子衫，并且。。。。。。

他頭上的發量，始終是個謎。

相關推薦：

相關標簽：