1、目錄CloudFabric云數據中心網解決方案 設計指南（運營維護） TOC o 1-5 h z 1數據中心網絡運維概述1 HYPERLINK l bookmark0 o Current Document h 1.1數據中心網絡智能運維背景與挑戰1 HYPERLINK l bookmark6 o Current Document h 1.2數據中心SDN網絡運維需求與目標3 HYPERLINK l bookmark8 o Current Document h SDN數據中心Underlay網絡可靠性4 HYPERLINK l bookmark10 o Current Document h 1.

2、2.2服務器批量上線效率5 HYPERLINK l bookmark12 o Current Document h 1.2.3業務變更網絡布放效果預測5 HYPERLINK l bookmark14 o Current Document h 1.2.4既有業務網絡可達性校驗5 HYPERLINK l bookmark16 o Current Document h 1.2.5故障快速發現定位及恢復5 HYPERLINK l bookmark18 o Current Document h 1.3數據中心網絡運維設計原則6DAY-0規格化設計-SDN數據中心Underlay網絡設計7 HYPERLI

3、NK l bookmark24 o Current Document h 2.1整體拓撲設計7 HYPERLINK l bookmark30 o Current Document h 2.2路由協議設計10 HYPERLINK l bookmark38 o Current Document h 2.3擴展性設計14 HYPERLINK l bookmark44 o Current Document h 2.4可靠性設計15 HYPERLINK l bookmark46 o Current Document h 2.4.1可靠性設計一般原則15Border Leaf 節點可靠性16Spine 節

4、點可靠性16Leaf節點可靠性18NGFW 節點可靠性24vSwitch 節點可靠性（受限商用）28 HYPERLINK l bookmark74 o Current Document h DAY-0網絡初始化-ZTP開局31 HYPERLINK l bookmark76 o Current Document h DAY-0意圖驗證-Underlay網絡校驗32 HYPERLINK l bookmark88 o Current Document h DAY-1業務方案&變更-SDN網絡業務發放前校驗方案36 HYPERLINK l bookmark92 o Current Document h

5、 5.1網絡業務編排（設計態）37 HYPERLINK l bookmark94 o Current Document h 5.2網絡資源仿真校驗38 HYPERLINK l bookmark96 o Current Document h 5.3網絡連通性校驗385.4設備配置變更內容預覽39DAY-2.例行維護40 HYPERLINK l bookmark98 o Current Document h 6.1單路徑探測40 HYPERLINK l bookmark136 o Current Document h 6.2多路徑探測51 HYPERLINK l bookmark170 o Cur

6、rent Document h DAY-2 CloudFabric 智能運維59 HYPERLINK l bookmark172 o Current Document h CloudFabric 智能運維方案總體架構59 HYPERLINK l bookmark174 o Current Document h iMaster NCE-Fabric 控制器架構60 HYPERLINK l bookmark220 o Current Document h iMaster NCE-Fabriclnsight 架構63 HYPERLINK l bookmark178 o Current Documen

7、t h SDN數據中心網絡故障智能運維方案及功能介紹65 HYPERLINK l bookmark180 o Current Document h 7.2.1網絡故障智能運維能力全景65 HYPERLINK l bookmark182 o Current Document h 7.2.2網關故障智能運維處理流程介紹74 HYPERLINK l bookmark192 o Current Document h 7.2.3網絡故障智能運維之網絡監控能力80 HYPERLINK l bookmark194 o Current Document h 7.2.4網絡故障智能運維之故障發現82 HYPER

8、LINK l bookmark196 o Current Document h 7.2.5網絡故障智能運維之問題定位定界83 HYPERLINK l bookmark202 o Current Document h 7.2.6網絡故障智能運維之故障恢復/隔離86 HYPERLINK l bookmark208 o Current Document h 7.2.7數據中心典型故障智能運維case示例87 HYPERLINK l bookmark210 o Current Document h Casel：交換機FIB表項跳變導致會話異常87 HYPERLINK l bookmark212 o C

9、urrent Document h Case2：光模塊故障導致鏈路頻繁閃斷88 HYPERLINK l bookmark214 o Current Document h Case3： ARP 攻擊89 HYPERLINK l bookmark216 o Current Document h 使用 Fabriclnsight進行網絡例行巡檢89 HYPERLINK l bookmark218 o Current Document h 7.4數據中心iMaster NCE-Fabriclnsight智能運維網絡部署90iMaster NCE-Fabriclnsight 和控制器的資源要求90 HY

10、PERLINK l bookmark222 o Current Document h 7.6方案約束（本節對外發布時不展示）91 HYPERLINK l bookmark224 o Current Document h 7.6.1設備的能力約束92DAY-2配置回滾93&全網回滾93 HYPERLINK l bookmark232 o Current Document h 8.2租戶回滾95 HYPERLINK l bookmark238 o Current Document h DAY-N網絡擴容-SDN數據中心服務器自動化批量上線98 HYPERLINK l bookmark252 o C

11、urrent Document h DAY-N網絡擴容-交換機擴容102 HYPERLINK l bookmark254 o Current Document h DAY-N設備更換-替換交換機105 HYPERLINK l bookmark256 o Current Document h 11.1替換設備（非ZTP設備）105 HYPERLINK l bookmark288 o Current Document h 11.2替換設備（ZTP設備）116 HYPERLINK l bookmark310 o Current Document h DAY-N設備更換-替換端口124 HYPERLI

12、NK l bookmark318 o Current Document h A參考圖片1271數據中心網絡運維概述1數據中心網絡運維概述數據中心作為信息與信息系統的物理載體，主要用于與IT相關的主機、網絡、存儲等 設備和資源的存放、運營及管理，只有運維好一個數據中心，才能發揮數據中心的作 用，使之能更好的為業務部門提供強大的支撐能力。本文檔主要針對數據中心的網絡運維進行了闡述，其出發點在于使用戶能對SDN時代 的數據中心網絡實現精確管控維護，使SDN網絡的管理水平和服務質量得到持續提 升，此外對傳統數據中心網絡的建設有具有參考價值。1.1數據中心網絡智能運維背景與挑戰1.2數據中心SDN網絡運

13、維需求與目標1.3數據中心網絡運維設計原則1.1數據中心網絡智能運維背景與挑戰本節主要介紹數據中心業務連續性及容災標準。近來年，無論是金融、電信、互聯網等行業的大型企業，還是全國各個科技園區、各 級政府都在如火如荼地進行數據中心建立，數據中心的穩定運行關系著國家信息安全 和社會穩定，為了防范災難和風險，保障業務連續性，國內外監管部門頒布了一系列 業務連續性及容災的標準。國內外數據中心規范對業務連續性要求ANSI/TIA-942-B 2017數據中心電信基礎設施標準主要是根據數據中心基礎設施 的“可用性(Availability ) ”、穩定性(Stability )” 和安全性(Securit

14、y )”分 為四個等級：Tier I, Tier II, Tier III, Tier IV。該標準所說的數據中心可以是政府或企 業自有產權的自有數據中心，也可以是運營商用于租賃服務的公用數據中心。該標準 描述了各類數據中心或計算機房中，對通信基礎設施的起碼的、最低的要求。ANSI/TIA -942-B 標 準定義可信要求可用性指標/每年允許宕機時 間TierlBasic基本系統沒有冗余的基本的數據中心可用性99.671%、年平均故 障時間28.8小時Tier IIRedundant Component 冗余系統組件級冗余基礎設施可用性99.741%、年平均故 障時間22.7小時Tier II

15、IConcurrentlyMaintainable并行維護可并行維護級機房基礎設施，電 源等主用1+備用1,多上行可用性99.982%、年平均故 障時間1.6小時Tier IVFault Tolerant 容錯 系統容錯級機房基礎設施，所有設施 支持容錯（上行鏈路、存儲、制 冷、電源等1+1主用）可用性99.995%、年平均故 障時間0.4小時ANSI/TIA-942-B突出對數據中心可用性/故障中斷時間提出了要求：其中，Tier III可 用性99.982%、年平均故障時間1.6小時;Tier IV可用性99.995%、年平均故障時間 0.4小時。國內標準數據中心設計規范（GB50174）在

16、滿足中國數據中心行業發展的前提 下，吸取國外數據中心設計的優點，結合中國數據中心行業的具體情況，增加補充具 有數據中心行業特點的相關條文規定。主要圍繞數據中心的可靠性、可用性、安全、 節能環保等方面提出進一步明確要求。數據中心設計規范根據數據中心的使用性 質、數據丟失或網絡中斷在經濟或社會上造成的損失或影響程度確定所屬級別，將數 據中心劃分為分為A （容錯型）、B （冗余型）、C （基本型）三個級別。GB50174級別可信要求可用 性行業遵從與 TIA-942-B 級 別對應關系A級容錯 系統應在一次意外事故后或單系統設備維 護或檢修時仍能保證電子信息系統正 常運行當兩個或兩個以上地處不同區域

17、、同 城或者異地同時數據中心建設，要求 互為備份，主要適用于云計算數據中 心、互聯網數據中心等最高 等級金融行業、軍 事部門、交 通、電信、國 家信息中心Tier IVTier IIIB級冗余 系統基礎設施在冗余能力范圍內，不應因設 備故障而導致電子信息系統運行中斷居中科研院所、高 校、政府辦公 樓Tier IIC級基本 系統在基礎設施正常運行情況下，應保證電 子信息系統運行最低-Tierl行業數據中心規范對業務連續性要求 金融行業金融數據中心一般都有本地的數據冗余保護或容災建設，最主流的災備技術是兩 地三中心建設，確保業務可靠可用性高，遵從數據中心設計規范A級標準。中國銀監會發布商業銀行業務

18、連續性監管指引【2011】（104號），標志著國家 和行業監管部門對業務連續性的重視程度已經提升到了一個新的高度。表1-1商業銀行業務連續性監管指引對運營中斷事件等級定義事故等級定級定級標準監管處置I級事故特別重大運營中斷 事件單機構單省中斷6小時單機構多省中斷3小時多機構多省中斷3小時上報國務院II級事故重大運營中斷事件單機構單省中斷3小時單機構多省中斷半小時多機構多省中斷半小時上報銀監會III級事 故較大運營中斷事件單機構單省中斷半小時上報銀監會電信行業運營商遵從數據中心設計規范A級標準，業務可用性99.995% （年平均故障 時間0.4小時），處于國際標準Tier4范圍。互聯網行業YD/

19、T 2441-2013互聯網數據中心技術及分級分類標準規定了互聯網數據中心 IDC在可靠性、綠色節能和安全性等三個方面的分級分類的技術要求，明確定義 T IDC可靠性方面的等級為R1R3,其中R1為最低等級，R3為最高等級：R3 業務可用性299.95%, R2業務可用性299.9%, R1業務可用性299.5%。OTT可用性要求：OTT業務可用性基本要求99.95%（年平均故障時間4.38小 時），可靠性為R3級別，介于國際標準Tier II和Tierlll之間。BAT可用性要求：百度業務可用性要求99.99% （年平均故障時間0.88小時）， 阿里99.99% （年平均故障時間0.88小時

20、），可靠性為R3級別，介于國際標準 Tier3和Tier4之間；騰訊99.9% （年平均故障時間8.76小時），可靠性為R2級 別，介于國際標準Tier2和Tier3之間。1.2數據中心SDN網絡運維需求與目標在數據中心云化背景下，為了提示數據中心業務上線效率，數據中心網絡業務發放也 趨于采用SDN解決方案，隨之而來的對網絡運維效率也要求向智能化、自動化方向轉 變，以適應數據中心業務高效、復雜多變的業務需求。在此背景及目標的驅動下，華為CloudFabric為數據中心SDN網絡提供了智能化的運 維解決方案。華為CloudFabric運維解決方案的愿景：建設自動化、可視化、智能化的數據中心，并

21、最終實現無人值守。圖1-1 CloudFabric運維解決方案的愿景AS-IS：傳統運維TO-BE:趙值守網絡健康監控系統(U ndertay&Overtay)網絡KPI信息主動上報 業務質*分析Q Q統一南向采集接口修復隔離策略基于AI的故障走位引擎基于AI的故障修復引擎根據國內外數據中心設計標準業務可用性要求，結合客戶對業務SLA等級越來越高的 要求，華為CloudFabric運維解決方案制定了 SDN場景下的運維目標：1分鐘故障發 現，3分鐘故障定位，5分鐘故障恢復。版本如下：V100R019C10：支持75+故障場景，實現1分鐘自動發現、3分鐘故障定位、5分 鐘故障修復。V100R02

22、0C00：管控析融合統一 3個入口：業務發放入口、統一監控入口、故障 處理入口。業務發放入口：包括Underlay/Overlay業務自動化部署、意圖驗證引擎實現配 置變更無人值守。統一監控入口：包括物理網絡、邏輯網絡、應用網絡資源分布情況、健康度 狀態。故障處理入口：以故障快速恢復為主線，對故障處理生命周期全過程實現連 貫性處理。1.2.1 SDN數據中心Underlay網絡可靠性隨著數據中心業務云化的開展，用戶對數據中心網絡的可靠性等有了更高的要求，業 務云化也帶來了資源池化的需求，相應的要求網絡能夠滿足在更大范圍上的資源池化 部署，同時，在互聯網+的大形勢下用戶要求能夠實現業務的快速部署

23、，從傳統的周、 月部署周期，提升到天、小時級的部署周期，甚至讓業務實現分鐘級上線，但這些高 效提升的前提是要求數據中心Underlay網絡能夠適應SDN業務的發放特點，提供穩定 可靠的網絡保障性，因此在進行SDN網絡設計時，針對Underlay網絡的可靠性需要從 網絡的接入側、網絡側、轉發設備、VAS設備、網絡出口等多個層面來綜合考慮、全 面設計，打造端到端的數據中心可靠網絡。1.2.2服務器批量上線效率在數據中心的日常維護中，服務器擴容是一個經常性且關鍵的工作，通常情況下管理 員需要事先規劃好服務器網卡與交換機的連接關系，包括管理網、存儲網、業務網等 多個網絡平面。傳統的運維模式下通過人工按

24、規劃設計對交換機進行配置，完成服務 器的接入上線。但在云化數據中心場景下，對業務的上線效率要求越來越高，采用人 工配置完成大批量服務器上線的速度越來越跟不上業務節奏的要求。尤其是在SDN組 網場景下，也需要考慮采用自動化、智能化的方案實現服務器的批量快速上線。1.2.3業務變更網絡布放效果預測在SDN組網場景下，業務的邏輯網絡是由管理員在0層編排完成的，但下發到網絡設 備上的具體配置是由SDN控制器自動轉換后下發的，相對于傳統的網絡配置方法，采 用SDN后管理員對于SDN控制器下發的何種具體配置將無從知曉。但在某些場景 下，女口：管理員正在經歷傳統手工配置向SDN自動發放過度，或者某些重要業務

25、管理 員希望能在業務網絡布放前校驗SDN下發的配置是否正確，這就要求SDN方案能具 備業務網絡布放前提供預先校驗的能力，包括配置校驗、資源校驗、業務可達性校驗 等多個方面效果預測。1.2.4既有業務網絡可達性校驗Underlay網絡初始化部署完成后，為了能驗證網絡設備上線后的連通性及路由轉發實 現是否符合預期，用戶一般會用ping, trace等常規測試方法進行驗證，但這種驗證手 段效率較低，且驗證效果并不全面，所以就需要一種更高效的方案來替代傳統方式， SDN組網場景下用戶也希望能采用一種自動化方式來達到此種目的。1.2.5故障快速發現定位及恢復在數據中心網絡的日常維護中，非常重要的一項工作

26、就是網絡中故障的快速發現定位 并能及時排除，按照傳統維護經驗，網絡中的故障發現主要通過兩種途徑：網管系統收集的告警、日志及設備上報的統計數據等通過網管系統告警進行故障發現有幾個顯而易見的問題：1是時效性比較差，網管收集設備數據本身有一定的時延，管理員在網管系統上發 現告警等故障數據又會有一定的周期，甚至有些故障初期顯現的苗頭數據不一定 會得到管理員的關注和處理；2是復雜故障的發現需要依靠管理員的經驗，通過對多種網管數據、指標的綜合分 析才能最終斷定。3是由于設備算法或底層芯片故障導致的流轉發類異常的，管理員目前并有效的發 現和定位手段，往往需要廠商技術支持人員現場排查才能準確判斷；業務報障有很

27、多網絡中產生的故障，通過網管系統收集的日志或統計數據是無法及時發現 的，比如設備上的配置錯誤、轉發表項異常抑或是業務遭受了攻擊導致的異常等 等，在傳統數據中心網絡運維模式下，這些網絡問題往往業務上報故障時間會早 于網絡管理員主動發現問題的時間。而且這類問題的排除定位通常也會費時費 力。在SDN組網場景下，為了能跟上業務發放、變更的高效節奏，網絡故障也需要具備快 速發現、定位以及恢復的能力。這就需要網管運維系統除了收集傳統的日志告警類信 息外，還需要收集更多的指標類、資源類、表項類甚至是會話交互數據，同時還要具 備海量數據的分析處理能力，并能從中找出故障間的關聯線索實現快速準確的故障定 位，對于

28、其中可以通過配置實現故障恢復或隔離的，還要具備恢復預案的自動生成能 力，必要時這些預案可實現一鍵式下發從而實現對故障的快速恢復或隔離。1.3數據中心網絡運維設計原則華為CloudFabric V1R19C10提供了數據中心SDN網絡DAYO-DAYn全生命周期的設計 指導原則及方案實現指南，本篇文章針對數據中心網絡在生命周期每個階段的重點運 維設計工作將進行展開介紹。DAY-0規格化設計-SDN數據中心Underlay網絡設計在華為CloudFabric解決方案中,Underlay網絡從Fabric骨干組網結構、Server Leaf接 入、Border Leaf接入、網絡出口以及Underl

29、ay網絡路由等多個方面進行了全新的考量 和設計，力求滿足數據中心云化場景要求，提升SDN Overlay場景下的網絡可靠性， 靈活性及可彈性擴縮等方面的能力。2.1整體拓撲設計2.2路由協議設計2.3擴展性設計2.4可靠性設計2.1整體拓撲設計物理網絡架構概覽根據華為CloudFabric解決方案對數據中心組網的先進設計理念，一個典型的數據中心 內部的物理組網架構，應遵循Spine-Leaf架構。華為推薦的物理組網如下圖所示。圖2-1推薦的物理組網方式其中對上圖CloudFabric解決方案的物理組網中各類角色的定義參見下表。表2-1物理組網中各類角色的功能說明物理組網角色含義和功能說明Fab

30、ric一個SDN控制器管理的網絡故障域，可以包含一個或多個Spine- Leaf網絡結構。Spine骨干節點，VXLAN Fabric網絡核心節點，提供高速IP轉發功能， 通過高速接口連接各個功能Leaf節點。Leaf葉子節點，VXLANFabric網絡功能接入節點，提供各種網絡設備 接入VXLAN網絡功能。Service LeafLeaf功能節點,提供Firewall和LoadBalance等L4L7增值服務接 入VXLAN Fabric網絡的功能。Server LeafLeaf功能節點，提供虛擬化服務器、非虛擬化服務器等計算資源接 入VXLAN Fabric網絡的功能。Border Lea

31、fLeaf功能節點，提供數據中心外部流量接入數據中心VXLAN Fabric網絡的功能，用于連接外部路由器或者傳輸設備。DCI Leaf (FabricLeaf功能節點，提供跨Fabric三段式轉發時，VXLAN Mapping的 網絡功能，具體使用情況見MultiFabric設計指南。物理組網角色含義和功能說明Gateway)華為CloudFabric解決方案，要求一個典型的數據中心組網中Fabric網絡結構具有以下 幾個特點：包含了一個或多個Spine-Leaf結構；具有高帶寬、大容量能力；接入節點間無差異性；采用扁平結構，由于當前數據中心內部東西流量較大，因此采用扁平化設計可使 流量路徑

32、盡可能短，轉發效率高；靈活組網、彈性擴縮：當服務器數量增加時，可相應增加Leaf數量；當Spine轉 發帶寬不足時，可相應增加Spine節點個數，擴容靈活。對于Spine-Leaf架構的組網，推薦以下組網形態：推薦采用由CE大容量物理交換機組網；推薦米用L3網絡、部署IGP路由協議：Leaf和Spine之間米用三層互聯；推薦采用ECMP實現等價多路徑負載均衡和鏈路備份：從Leaf通過多條等價路徑 轉發數據流量到Spine,在保證可靠性的同時也能提升網絡的帶寬。Fabric提供的服務原則上要求網絡接入節點間可提供無差異互訪能力。物理網絡設計基本原則一個數據中心網絡內部推薦采用由CE系列交換機組成

33、的Spine-Leaf結構，并根據網絡 規模來靈活配置Spine和Leaf的節點數量。圖2-2 Fabric中ECMP示意圖 L3 interfaceSpine設計在Spine-Leaf網絡架構中，Spine的數量由Leaf到Spine的收斂比（Leaf的下行總 帶寬和Leaf的上行總帶寬的比值，不同的行業及不同的客戶有各自的要求）來決 定。Spine節點與Leaf節點之間使用以太網口互聯，并且配置成三層路由接口模式， 從而構建全IP Fabric網絡。Leaf設計Leaf可使用多種靈活組網方式，如M-LAG （推薦）和堆疊。每一個Leaf節點與所有Spine節點相連，構建全連接拓撲形態。Le

34、af節點的TOR設備數量較多，建議通過ZTP的方式來部署TOR設備，降 低部署復雜度。匚口說明ZTP - Zero Touch Provisioning是指新出廠或空配置設備上電啟動時采用的一種自動加載版本文 件，包括系統軟件、配置文件、補丁文件的功能。轉發設計Underlay路由建議選擇OSPF動態路由協議，Spine-Leaf間可以形成IPECMP 等價路徑。Leaf設備到Spine設備的流量形成ECMP負載分擔，無阻塞轉發，故障快速 收斂。ECMP鏈路須選擇基于L4 Port的負載分擔算法，由于VXLAN使用的是UDP 封裝，因此VXLAN報文的目的端口號是4789不變，而VXLAN報文

35、頭部的 源端口號可變，基于此來進行負載分擔。2.2路由協議設計Underlay層面的路由協議，建議選用OSPF （推薦）或EBGP。Underlay路由選用OSPF當TOR規模小于100臺時，推薦Underlay路由選用OSPF,此時路由規劃如下：單Fabric內部，Spine和Leaf節點的物理交換機上全部部署OSPF,并都在AreaO 中，使用三層路由口地址建立OSPF鄰居，打通Underlay路由，network類型建議 為P2P,如圖2-3所示。多Fabric之間互聯設備部署在OSPF AreaO,打通Underlay路由，如圖2-4所示。 單Fabric內部OSPF路由規劃推薦圖2-

36、3單Fabric部署OSPF路由規劃推薦圖2-3單Fabric部署OSPF路由規劃推薦P2PP2PP2PP2PP2POSPF1 Area 0C)疊）c)Sc)Spine2Leafl Leaf2Leaf3 Leaf4Leaf5Leaf6圖2-4多Fabric部署OSPF路由規劃推薦當Underlay的路由選用OSPF時的優缺點對比參見下表。表2-2 Umierby路由為OSPF時的優缺點對比說明項目說明優點OSPF路由協議部署簡單OSPF路由收斂速度快Underlay中的OSPF路由協議報文與Overlay中的BGP協議報文不同隊 列，VRF和路由表項都相互隔離，從而實現underlay和ove

37、rlay路由協議 故障上互相隔離項目說明缺點 OSPF路由域規模受限故障域較大Underlay路由選用EBGP當TOR規模大于200臺時，推薦Underlay路由選用EBGP,該場景路由規劃如下：單Fabric內部，Spine節點劃分一個AS,每個Leaf節點分別劃分一個AS, Leaf 節點和所有Spine節點之間部署EBGP鄰居（IPv4地址族），如圖2-5所示。多Fabric之間通過互聯設備部署EBGP鄰居，打通Underlay路由，如圖2-6所zj O圖2-5單Fabric內部EBGP路由規劃推薦AS 63500Spine2AS 65501(&)Leafl Leaf2Leaf3 Lea

38、f4Leaf5 Leaf6圖2-6多Fabric之間EBGP路由規劃推薦圖2-6多Fabric之間EBGP路由規劃推薦POD2SpineSpineLEAF倉）（） AS 65501、AS 65522 ；1 AS 655021_5_521Super SpinePOD1LEAFAS 61500當Underlay的路由選用EBGP時的優缺點對比參見下表。表2-3 UiKterlay路由為EBGP時的優缺點對比說明項目說明優點每個分區路由域獨立，故障域可控路由控制靈活，可靈活擴展規模適合大規模組網缺點配置復雜Underlay路由協議選擇對比不同的Underlay路由協議之間的對比參見下表。表2-4不同

39、的Underlay路由協議之間的對比說明項 目優點缺點適用場景OSPFOSPF路由協議部署簡單OSPF路由收斂快速Underlay中的OSPF路由協議報文與 Overlay中的BGP協議報文不同隊 OSPF路由域規模受限故障域較大中小型網絡單Area,大型網絡 三層架構多Area；建議鄰居數200項 目優點缺點適用場景列，VRF和路由表項都相互隔離， 實現故障的隔離建議多POD規劃，避免單 POD鄰居數100,避免路由域 過大影響網絡性能EBGP每個分區路由域獨立，故障域可控路由控制靈活，可靈活擴展規模適合大規模組網配置復雜中大型網絡建議鄰居數500建議多POD規劃，避免單POD鄰居數100,

40、避免路由域 過大影響網絡性能2.3擴展性設計數據中心內Fabric網絡的擴展模型主要有兩種類型：小POD模式和大POD模式。小POD模式擴展在原先Fabric基礎上進行擴展，小POD模式是指擴展成的新Fabric實際上是將原 Fabric復制成多份后組成，它們之間使用高速的傳統網絡互連起來，如下圖所示。圖2-7小POD模式擴展示意圖Fabric 1小POD模式擴展的特點是：按需擴容，模塊化擴展適用于大規模數據中心POD接入規模超過2000臺服務器時推薦此方式典型場景：金融行業數據中心大POD模式擴展當原網絡中業務需要擴容時，增加Fabric網絡中Leaf的數量來達到擴容目的。在增加 Serve

41、r Leaf的同時也可以增加Border Leaf,如下圖所示。圖2-8大POD模式擴展示意圖Fabric 1Fabric 1大POD模式擴展的特點是：按需擴容，擴展Leaf節點適用于中小規模數據中心POD接入規模不超過2000臺服務器推薦典型場景：企業數據中心2.4可靠性設計2.4.1可靠性設計一般原則以三層架構組網為例，通過設備冗余備份來提升網絡的可靠性。服務器鏈路故障：服務器雙歸接入，網卡負載分擔/主備，當服務器一條鏈路故障 時，業務倒換到冗余/備份鏈路。Server Leaf/Border Leaf 設備故障：Server Leaf/Border Leaf 配置 M-LAG 工作組，

42、當一臺 Server Leaf/Border Leaf 故障時,業務倒換到另外一臺 Server Leaf/Border Leaf上繼續轉發。Leaf上行鏈路故障：Leaf和Spine間通過多條鏈路實現ECMP,當一條上行鏈路 故障后，業務哈希到其他鏈路繼續轉發。Spine設備故障：一臺Spine故障后，流量從另外一臺Spine設備轉發。FW故障：FW配置主備鏡像，配置和會話表實時同步，當主FW故障后，流量切 換到備份FW設備。Peer-link故障：當M-LAG組中互聯的Peer-link故障時,通過雙主檢測，觸發狀 態為備的設備上除管理網口、Peer-link接口以外的接口處于Error-

43、Down狀態，避 免網絡出現雙主，提高可靠性。PE與Border Leaf之間鏈路故障：當某一臺Border Leaf設備與外部網絡連接故障 時，通過路由收斂后，自動啟用到外部網絡的備份路徑繼續轉發，SDN控制平面 不感知故障。當使用框式設備組網時，框式設備的上下行鏈路以及堆疊、Peer-link鏈路建議跨 板連接，實現單板級可靠性。Border Leaf節點可靠性兩個Border Leaf組成雙活網關（部分部署組播的場景需要開啟M-Lag特性）。這兩臺 Border Leaf需配置唯一的虛擬VTEP IP和Server Leaf建立VxLAN隧道。Border Leaf和PE之間交叉或口字型

44、組網。Border Leaf和PE通過E-trunk對接。FW可旁掛或直掛組網，一般是旁掛。兩臺FW主備備份。單臺FW通過trunk接口雙 歸到兩個 Border Leaf。Border Leaf 通過 E-trunk 口和 FW 連接。Border Leaf與外部PE 口字型組網可靠性正常情況下，兩臺Border Leaf設備分別將指向外部網絡的靜態或動態私網路 由引入三層逃生鏈路并發布，以便Border Leaf建立到外部網絡的備份路徑。當某一臺Border Leaf設備與外部網絡連接故障時，通過路由收斂后，自動啟 用到外部網絡的備份路徑繼續轉發，SDN控制平面不感知故障，支持鏈路失 效告

45、警。網絡側內部鏈路故障時，路由收斂依賴于IGP動態路由的能力，SDN控制平 面不感知故障，支持鏈路失效告警。當某一臺Border Leaf設備故障時，網絡通過路由收斂完成轉發路徑切換， SDN控制平面不感知故障，支持設備失效告警。Border Leaf與外部PE交叉型組網可靠性正常情況下，兩臺Border leaf使用4個L3接口與PE對接，物理組網交叉連 線，分別建立私網eBGP會話或者靜態路由傳遞路由信息。兩臺Border leaf在交叉組網下可以不需要部署L3逃生路徑。只有當Border Leaf與PE間的物理鏈路都故障時才會走到逃生路徑。當某一臺Border Leaf設備與外部網絡連接

46、故障時，通過路由收斂后，自動啟 用到外部網絡的備份路徑繼續轉發，SDN控制平面不感知故障，支持鏈路失 效告警。網絡側內部鏈路故障時，路由收斂依賴于IGP動態路由的能力，SDN控制平 面不感知故障，支持鏈路失效告警。當某一臺Border Leaf設備故障時，網絡通過路由收斂完成轉發路徑切換， SDN控制平面不感知故障，支持設備失效告警。243 Spine節點可靠性數據中心網絡Spine-Leaf架構下，單純的Spine設備角色本身彼此無需物理連線連接， 各設備獨立運行在Underlay路由網絡。Spine上連Border Leaf設備，下連ServerLeaf 設備，均使用三層路由口互聯。某臺S

47、pine設備的鏈路或者整機故障時，上下層設備通過動態路由協議，例如OSPF或者EBGP,收斂Underlay路由，將流量引導到正常的 Spine鏈路或者設備承載。由于Spine間可靠性耦合較小，因此Spine設備自身的可靠性是主要的考慮因素，在 CloudFabric基線中，建議使用框式設念作為Spine節點：CE12800系列、CE12800S系列或者12800E系列（海外不體現）框式交換機CE16800系列框式交換機CE16800系列框式交換機CE16800系列框式設備采用多種冗余技術提高設備的可靠性，如圖2-9所示，包括主 控單元的冗余備份，監控單元冗余備份，交換單元的冗余備份，電源模塊

48、的冗余備 份，風扇冗余備份等。并且當上述冗余的模塊發生故障時，可以通過熱插拔方式替 換，保證整機持續處于高可靠狀態。另外，接口板也可以通過配置多塊單板，多鏈路跨板接入方式保證鏈路側可靠性，接 口板同樣支持熱插拔替換。圖2-9 CE16800系列框式交換機可靠性示意圖電源N+M熱備份監控1+1熱備份系統級 熱備份PEM輸入N+N備份交換網N+M熱備份 風扇框/風扇熱備份主控1十1熱備份CE12800系列框式交換機CE12800系列框式設備采用多種冗余技術提高設備的可靠性，如圖2-10所示，包括主 控單元的冗余備份，監控單元冗余備份，交換單元的冗余備份，電源模塊的冗余備 份，風扇冗余備份等。并且當

49、上述冗余的模塊發生故障時，可以通過熱插拔方式替 換，保證整機持續處于高可靠狀態。另外，接口板也可以通過配置多塊單板，多鏈路跨板接入方式保證鏈路側可靠性，接 口板同樣支持熱插拔替換。圖2-11服務器接入VXLAN的兩種方案圖2-10 CE12800系列框式交換機可靠性示意圖監控W熱備份一*主控1十1熱備份-電源N十M熱備份熱備份交換網N+M熱備份風扇框內雙風扇 W熱備份-1+1風扇框級熱備份系統內熱備份電源era e31主用備用1雌雌Sx 網板外設.3s im ri阿i両i網板n雙CAN監控總線雙GE管理總線多LINK高速數據總線CE12800系列的可靠性還包括設備本身對故障的檢測、分析和預警處

50、理能力。這些技 術包括設備CPU防攻擊能力、完善故障監控和全面的告警功能。CE12800系列交換機 采用控制平面和管理平面分離的同時，還增加監控平面。這三個平面完全獨立，保證 整個系統的可靠性以及業務連續性。匚口說明監控單元是一個完全獨立的帶外管理單元，遵循數據中心DCMI1.0管理規范和IPMI2.0管理規 范。監控單元可以實現遠程單板的上電、固件升級、資產管理、故障診斷和溫度、電壓、功率的 監控等功能，從而實現設備的遠程管理和遠程維護。2.4.4 Leaf節點可靠性服務器接入方式簡介服務器接入Server Leaf的方式推薦為M-LAG,如圖2-11所示。（推薦）服務器Eth-Tnmk接入

51、Leaf M-LAG I作組，如下圖中“1”所示。服務器主備接入Leaf單機，如下圖中“2”所示。上述幾種部署方式的比較參見下表。表2-5兩種服務器接入方式的對比部署方式特點管理復 雜度可靠性接入成本（推薦）服務 器 Eth-Trunk 接入LeafM- LAG工作組兩臺Leaf設備通過peer-link互聯并建立DFS Group,對外表現為一臺邏輯設備，但又各自有獨 立的控制面，服務器以負載分擔方式接入兩臺 Leaf設備升級維護簡單，運行可靠性高。下行口 配置M-LAG特性雙歸接入服務器，服務器雙網卡 運行在主備/負載分擔模式。因設備有獨立控制 面，故部署配置相對復雜。高高中服務器主備接

52、入Leaf單機Leaf獨立部署，服務器雙網卡綁定以主備模式接 入兩臺Leaf設備，同一時間只有一個網卡收發報 文，帶寬利用率低。主備網卡切換時接收流量的 VTEP IP變化，依賴于發生切換的服務器發送免 費ARP報文重新引流。中高中綜上所述，推薦M-LAG來組建Leaf工作組。當兩臺設備之間配置了 DFS Group和Peerl-link后，兩臺設備通過Peer-link鏈路進行 DFS Group配對，并協商設備的主、備狀態和M-LAG成員口的主備。正常工作后，兩 臺設備之間會通過Peer-link鏈路發送M-LAG同步報文實時同步對端的信息，M-LAG 同步報文中包括MAC表項、ARP表項

53、以及STP、VRRP協議報文信息等，并發送M- LAG成員端口的狀態，這樣任意一臺設備故障都不會影響流量的轉發，保證正常的業 務不會中斷。M-LAG上行鏈路故障時的可靠性保證如下圖所示，M-LAG I作組的雙主檢測鏈路通過連接到Spine的業務網絡互通。配置 Monitor-Link,將一臺設備的所有上行鏈路加入Uplink,對應服務器的下行鏈路加入 Downlinko當這臺設備的所有上行鏈路故障時，聯動下行鏈路down,觸發服務器側流 量只通過另一條上行鏈路轉發。此時場景變為單歸接入。M-LAG下行鏈路故障時的可靠性保證如下圖所示，當下行M-LAG成員口故障時，DFS Group主備狀態不會

54、變化，但如果故 障M-LAG成員口狀態為主，則備M-LAG成員口狀態由備升主，流量切換到該鏈路上 進行轉發。發生故障的M-LAG成員口所在的鏈路狀態變為Down,雙歸場景變為單歸 場景。故障M-LAG成員口的MAC地址指向peer-link接口。在故障M-LAG成員口恢 復后，M-LAG成員口狀態不再回切，由備升主的M-LAG成員口狀態仍為主，原主M- LAG成員口在故障恢復后狀態為備。可以執行display dfs-group dfs-group-id node node-idm-lag命令來查看成員接口當前狀態。圖2-13下行鏈路故障時可靠性示意圖圖2-14 M-LAG主設備故障時可靠性示

55、意圖圖2-14 M-LAG主設備故障時可靠性示意圖NetworkNetworkDAD linkBackupDAD linkPeer-linkPeer-link:kup下行鏈路故障對于組播源在網絡側，組播成員在接入側的組播流量，當M-LAG主設備的M-LAG成 員口故障時，通過M-LAG同步報文通知對端設備進行組播表項刷新，M-LAG主備設 備不再按照組播地址奇偶進行負載分擔，而是所有組播流量都由端口狀態Up的M- LAG備設備進行轉發，反之亦然。M-LAG主設備故障時的可靠性保證如下圖所示，當M-LAG主設備故障，則M-LAG備設備將升級為主，其設備側Eth- Trunk鏈路狀態仍為Up,流量

56、轉發狀態不變，繼續轉發流量。M-LAG主設備側Eth- Trunk鏈路狀態變為Down,雙歸場景變為單歸場景。如果是M-LAG備設備發生故障，M-LAG的主備狀態不會發生變化，M-LAG備設備 側Eth-Trunk鏈路狀態變為Down。M-LAG主設備側Eth-Trunk鏈路狀態仍為Up,流 量轉發狀態不變，繼續轉發流量，雙歸場景變為單歸場景。M-LAG主設備 故障DAD link BackupNetworlDAD linkasterPeer4inkifi*BAckupM-LAG的Peer-Link鏈路故障時的可靠性保證如下圖所示，當M-LAG應用于普通以太網絡、VXLAN網絡或IP網絡的雙歸

57、接入 時，peer-link故障但雙主檢測心跳狀態正常會觸發備設備上除管理網口、peer-link接口 和堆疊口以外的接口處于Error-Down狀態。一旦peer-link故障恢復，處于ERROR DOWN狀態的M-LAG接口默認將在2分鐘后自動恢復為Up狀態，處于ERROR DOWN狀態的其它接口將立即自動恢復為Up狀態。圖2-15 M-LAG的Peer-Link鏈路故障時可靠性示意圖圖2-15 M-LAG的Peer-Link鏈路故障時可靠性示意圖Peer-UnkJJf 障BickupPeer-link /ckupDAD linkMasti fX y Peer-link1x故障鏈路Erro

58、r-Down 接口但在實際組網應用中，當某些上行端口運行路由協議或者是雙主檢測心跳口時是不希 望被Error-Down的。此時，可以根據實際情況選擇配置下列功能。在peer-link故障但 雙主檢測正常時，配置下列功能，設備接口 Error-Down情況參見下表。表2-6設備在peer-link故障但雙主檢測正常時接口 Error-Down情況設備配置情況M-LAG接入普通以太網絡、VXLAN網絡或IP網絡設備缺省情況除管理網口、peer-link接口和堆疊口以外的接口處于 ERROR DOWN 狀態。設備僅配置suspend功能僅M-LAG成員口以及配置該功能的接口處于ERROR DOWN狀

59、態。設備僅配置reserved功能除配置該功能的接口、管理網口、peer-link接口和堆疊 口以外的接口處于ERROR DOWN狀態。設備同時配置suspend功 能和reserved功能僅M-LAG成員口以及配置suspend功能的接口處于 ERROR DOWN 狀態。部署注意事項 關于VTEP IP的規劃計算節點通常雙歸接入到M-LAG工作組中的兩臺不同的TOR設備，且這兩臺 TOR需配置相同的、全網唯一的VTEPIP地址和相同的NVE1的MAC地址。使 用M-LAG技術可以在兩臺物理TOR上配置相同的VTEPIP,但兩臺設備依然彼 此獨立，可獨立升級部署，進一步提高接入可靠性。 關于P

60、eer-Link鏈路帶寬的選擇如下圖所示：網絡正常時，流量不經過Peer-link鏈路橫穿，無論上行流量經過哪個DFS成 員設備，下行流量Hash到其他成員時，其他成員具備本地優先轉發能力。當DFS1的全部上行鏈路中斷時，服務器發出的流量要通過Peer-link鏈路橫 穿到其他DFS成員設備進行轉發，如下圖中綠色虛線所示。因此Peer-link鏈 路帶寬應不小于DFS單設備上行帶寬。當DFS1的全部下行鏈路中斷時，網絡側下行的流量要通過Peer-link鏈路橫 穿到其他DFS成員設備進行轉發，如下圖中紅色虛線所示。因此Peer-link鏈 路帶寬應不小于DFS單設備上行帶寬。圖2-16成員設備