接下來我會給大家分享一下我們的應用場景，以及在實施部署的時候我們遇到的困難和挑戰，在實踐的過程中走過的一些坑。

所以針對這個問題我們最終選擇了比較折中的方案，首先我們采用VRF來做業務類型區分，directadmin漢化 虛擬主機，其次，SR隧道我們依然保存，但是僅僅是做SR標簽轉換，不再重新生成隧道，我們靜態配置點到點的隧道。通過控制器向VRF注入BGP的路由，還是采用改變下一跳的方式，將數據引入到相應的SR隧道中，從而實現基于業務類型的流量調度。

在未來我們計劃將路由器的VRF功能和引流的功能遷移到NFV網關上。在百度，所有的南北向流量都會經過自研的NFV網關，那么我們就可以在NFV網關設備上基于流進行SR頭部封裝，實現基于服務的出口調度。中間的網絡設備只做SR標簽轉發，不再做復雜的引流工作。

Route feed模塊采集設備路由變化信息；Flow Analysis分析流量大小，這里不緊緊是分析端口級流量，需要詳細分析每個路由前綴的流量；Limits Computer主要采集物理網絡的硬件參數，比如網絡帶寬空閑量、網絡跳數、時延等。分析平臺會把三種數據做綜合分析，去除干擾數據，將有效數據傳輸給決策層。決策層根據現網的情況，和來自controller的輸入，做出調度方案，同時將調度方案發送給路徑計算模塊。路徑計算模塊根據決策層傳遞的調度方案，計算出流量路徑，并通過bgp injector注入到設備。

我們有這么多的出口，有成本昂貴的transit出口，有成本相對便宜的對等peer。怎么才能讓質量敏感類服務走時延最低、丟包最少的出口，讓成本敏感類服務，走成本最低的出口？要解決這個問題，我們可能要做一個比較復雜的系統。我們發現看起來要解決一個簡單的問題，可能要付出很大的代價，至少在這個系統里需要做三個基礎模塊。一個是AAA，就是權限管理模塊，需要做一些權限認證；另外要一個是DB數據庫，用于存儲網絡拓撲、配置數據；最后一個是log日志分析組件。

除此之外，還有一個非常致命的缺陷，就是策略變更時效性低。

首先是我們的需求，百度網絡大概分成三個圈，最里面的一圈是數據中心，大量的服務器部署在這些數據中心里。中間綠色點和黃色點的一圈是外網骨干網，這張網將各個數據中心的外網出口連接起來，同時和運營商互聯，這是百度服務器和互聯網用戶通信的出口。最外面一圈是訪問百度的互聯網用戶。

最終我們采用這種方式在海外網絡做了部署，這種方式顯著的優勢就是對網絡設備的要求降低了，不需要動態修改設備配置，對設備廠商的南向接口依賴降低。但是它依然還是存在著一個很嚴重的缺陷，就是傳統MPLS-TE面臨的問題，需要建立點到點的隧道，每個設備的每個VRF都要跟其它所有設備建立隧道，如果有n個設備，每個設備有2個VRF，就需要建立2（n-1）個隧道。大量的隧道維護額外增加了運維人員的工作。

左邊向上的箭頭是采集設備信息，向上傳給上面的分析模塊，根據分析結果我們做一些策略往下推。

這個方法看起來非常完美了，那么實際實施中有什么問題嗎？首先，擺在我們面前的第一個問題是如何動態操作多廠商設備？我們遵循了google的open config標準，基于YANG模型對網絡設備進行配置。然而，各個設備廠商對YANG模型支持力度參差不齊，大量時間花費在溝通上，開發進展緩慢。此外，各廠商對SR-TE引流方式技術也不完全相同，比如cisco采用SR-POLICY、華為采用QPPB，這導致網絡配置邏輯上存在一定差異，從而給配置模塊引入較大難度。

今天我重點要給大家講的是網絡設備上流量調度的實施方案，回到最原始的需求，選擇出口的問題。在沒有SR技術之前，控制器和所有網絡設備建立一個IBGP會話，通過這個控制器下發BGP路由。將期望調度的目標前綴的下一跳修改成你想調度到的出口的網絡設備，從而將流量調度到該出口。然而，這個方法并不能解決我們的問題，因為基于前綴的調度，將質量敏感類業務和成本敏感類業務都調度到了這個出口，但這個出口可能質量很好、成本很高，我們滿足了質量敏感類業務的需求，卻不能滿足成本敏感類業務的需求；相反有些出口成本比較低、質量比較差，能滿足成本敏感類業務需求，不能滿足質量敏感類業務的需求。可見傳統的基于BGP路由調度的方法，不能同時滿足兩類業務的需求。

我們2016年就接觸了相關的SR技術，憑著一腔工程師對新技術的熱情開始學習，2017年的時候我們靜下心來開始思考，用SR技術能給我們帶來什么，能幫助我們解決哪些問題。2017年下半年和一些設備廠商開始聯合研發，2018年上半年我們做了測試，并在海外做了小批量的部署。

這是我的分享，謝謝。

數據中心的業務，我們分為兩類。一類是對質量特別敏感的，比如搜索、自動駕駛類服務；另一類是對成本比較敏感的，比如網盤、視頻類服務。

以下為百度網絡架構師劉小軍的演講實錄：

這個時候正好出現了SR相關技術，2017年的時候我們對SR寄予了特別大的希望來解決這個問題。SR怎么解決呢？對成本類、質量類服務通過dscp標簽的方式分別做一個標記，先進行分類；在出口選擇的時候，我們為每一個出口設定了一個Community值，以此標記出口。當想調度某個前綴的流量到某個特定的出口時，將該前綴打上該出口的bgp community值即可。這樣我們就可以同時match dscp和community，將流量注入到SR隧道中，通過SR隧道將特定業務類型的數據傳輸到適合該業務的出口。