1、目錄CloudFabric云數據中心網解決方案設計指南（網絡健康度） TOC o 1-5 h z 1方案簡介11.1方案背景11.2網絡健康度和傳統網管的區別21.3網絡健康度方案簡介22 Telemetry 數據分析4Telemetry 技術簡介4Telemetry 和 SNMP 技術對比42.1.2技術原理42.1.3設備支持情況6Telemetry 異常檢測技術原理72.2.1動態基線異常檢測72.2.2靜態閾值異常檢測72.2.3異常告警抑制73網絡流量分析9TCP流量分析93.1.1技術原理9TCP會話分析9TCP邊緣智能流分析10TCP 全流分析113.1.2適用場景11UDP流量

2、分析123.2.1技術原理123.2.2適用場景133.3報文轉發異常分析133.3.1技術原理133.3.2適用場景143.4 CE款型支持情況154網絡健康度分析164.1五級健康度評估164.2故障智能分析及閉環174.2.1整體方案介紹174.2.2故障發現184.2.3 故障定位定界194.2.4故障恢復隔離22恢復預案22隔離預案224.3設備維度22FIB4表項資源異常224.3.2疑似二層環路234.4網絡維度244.4.1亞健康光模塊檢測244.4.2微突發導致業務丟包254.5協議維度26M-LAG 雙主檢測264.6 Overlay 維度274.6.1網絡接入側IP地址沖

3、突284.7業務維度294.7.1配置異常導致業務中斷294.8網絡健康度報告304.8.1網絡健康度報告簡介304.8.2獲取網絡健康度報告305 Fabricinsight 部署說明33Fabricinsight 部署說明335.1.1管理規模335.1.2部署架構335.2軟件特性清單34 HYPERLINK l bookmark6 o Current Document h A參考圖片361方案簡介1方案簡介1.1方案背景1.2網絡健康度和傳統網管的區別1.3網絡健康度方案簡介1.1方案背景隨著行業數字化轉型的加速進行，大數據、機器學習、分布式、服務化等新技術等新 的業務和應用被部署到數

4、據中心。企業數據中心越來越多的采用云化技術（計算/存儲/ 網絡資源池化、網絡及業務自動化等），以滿足業務數字化轉型對于新業務快速上線、 敏捷迭代、彈性擴/縮容的需求。數據中心資源池化以及SDN技術的應用使得數據中心 內業務上線/變更/下線速度得到了極大的提高，但是也導致數據中心網絡的運行狀態幾 乎每時每刻都在變化，給數據中心網絡的日常運維工作帶來了如下挑戰：主動運維：SDN場景下要求能快速動態地下發業務，如按需創建和刪除邏輯網 絡，網絡或業務配置變更相對會比較頻繁。而頻繁的變更也增加了故障概率，需 要運維系統能主動智能地感知這些故障，并借助大數據分析、經驗數據庫幫助用 戶快速進行故障定界和故障

5、恢復。實時監控：人工智能及大數據分析等關鍵業務在數據中心內得到廣泛應用，要求 運維人員能實時監控網絡運行狀態并針對異常快速響應。例如網絡中由于Incast 流量（多打一）產生瞬態的突發丟包，導致AI訓練集群性能下降。懷疑存在毫秒 級別的微突發流量，但是在分鐘級別的SNMP機制下，網絡運維人員無法觀察至I、更無法針對性的優化該問題。運維規模：云計算場景下運維人員的管理對象從物理設備延伸到虛擬機，網元管 理規模增加了幾十倍；另一方面由于實時性分析的要求，設備指標的采集粒度從 分鐘級提升到毫秒級，數據量增加了近千倍；更重要的是對于故障的主動感知和 排障，除了采集分析網絡設備指標外，還需要結合實際轉發

6、業務流進行分析，數 據規模則進一步擴大。華為Fabriclnsight網絡健康度方案顛覆傳統以設備監控為核心的網絡運維方式，實時 評估設備、網絡、協議、Overby、業務健康狀態，主動感知網絡或業務問題，并針對 數據中心內常見故障提供自動化排障能力，幫助用戶快速進行故障定界和恢復，保障 應用的持續穩定運行。1.2網絡健康度和傳統網管的區別圖1-1網絡健康度和傳統網管對比管Telemetry被動響應 SlKJL網絡全場翩據可視全面網Telemetry秒級數據采集傳統網管基于SNMP協議對網絡設備進行周期性輪詢，由于網管軟件架構及網絡 設備CPU性能約束通常以5分鐘為輪詢周期。Fabricinsi

7、ght網絡健康度方案采用 更高效的Telemetry技術，Fabricinsight按需單次訂閱網絡設備狀態信息及關鍵指 標，設備根據訂閱按照秒級周期主動推送采集數據。以業務為中心，分鐘級識別風險傳統網管監控的核心是網絡設備，獨立的監控單臺設備的KPI指標及工作狀態。 Fabricinsight以業務中心全面評估數據中心網絡健康度，通過設備、網絡、協議、 Overlay、業務五層評估模型和AI智能算法，分鐘級識別網絡運行過程中存在的各 種風險。主動運維，自動化排障傳統數據中心網絡以被動式運維為主，在業務報障后依賴問題復現、網絡抓包、 Ping/Telnet等手段進行事后定位。Fabricins

8、ight網絡健康度方案在系統內集成AI 智能算法及專家經驗實現網絡自動化排障，快速發現并定位問題根因。同時網絡 健康度方案通過對網絡運行歷史數據的智能學習，主動調優網絡以減少因網絡故 障導致業務受損的情況發生。1.3網絡健康度方案簡介華為iMaster NCE-Fabriclnsight網絡健康度評估通過整合網絡中的網絡設備配置數據、 拓撲數據、狀態數據、日志數據、流量數據等，從設備、網絡、協議、Overlay、業務 五個維度對網絡運行狀態進行實時評估，感知網絡中各個層面的工作狀態并識別潛在 的問題和風險；同時iMaster NCE-Fabriclnsight采用專家經驗引擎、AI智能算法、知

9、識 圖譜推理等技術進行大數據挖掘和人工智能分析，對健康度評估發現的網絡風險或故 障進行根因定位并推薦修復/隔離措施。Fabricinsight通過與iMaster NCE-Fabric控制器 的聯動可實現對故障的一鍵隔離或修復，同時還支持對隔離/修復措施進行風險評估， 以輔助用戶進行問題隔離/閉環決策。圖1-2網絡健康度總體方案iMaster NCE-Fabriclnsight故障智能分析專家經驗+AI智能算法+知識圖譜推理異常事件k/Telemetry數據分析扭網絡流量分析聯動閉環iMaster NCE-Fabricgu利用率微突發檢測內存利用率表項利用率迂p應用鉀丟包/時延檢測 屈幕ood

10、識別轉發異廳閱隔離/修復預案業務流數據/ Telemetry數據/日志/告警.網絡設備根據信息采集配置及Fabricinsight Telemetry訂閱信息，定時采集業務流數 據、Telemetry數據、日志、告警等信息，并通過gRPC/Syslog等通道發送給FI。iMaster NCE-FabriclnsightiMaster NCE-Fabriclnsight分析器采集數據中心網絡中的全息數據，數據分析引擎 對不舍設備上報的Telemetry數據、網絡流量數據進行關聯分析，并基于五層評估 模型全面評估網絡健康度狀態、識別網絡運行過程中可能出現的故障及風險并生 成異常事件。同時Fabri

11、cinsight利用專家經驗、AI智能算法、知識圖譜推理等進 行智能關聯分析，實現異常檢測及故障根因定位，同時可以聯動NCE-Fabric進行 閉環修復/隔離。iMaster NCE-FabriciMaster NCE-Fabric控制器通過部件間接口從iMaster NCE-Fabriclnsight接收異常 事件，并生成對應的故障事件。故障事件服務可展示故障的關鍵信息，同時針對 不同的故障iMaster NCE-Fabric會生成定制化的恢復或隔離預案，用戶可選擇想要 的恢復或隔離預案一鍵式下發。用戶確認故障解除后，可以在NCE-Fabric上回退 隔離預案。Telemetry數據分析Te

12、lemetry數據分析Telemetry技術簡介Telemetry異常檢測技術原理Telemetry技術簡介Telemetry 和 SNMP 技術對比編碼效率SNMP使用非結構化數據編碼效率低，Telemetry利用GPB編碼格式（GPB編碼 格式的文件名后綴為.proto）,提供一種靈活、高效、自動序列化結構數據的機 希U，GPB屬于二進制編碼，性能更好、效率更高。采樣精度SNMP支持的數據采集間隔一般為分鐘級，無法滿足業務及網絡監控實時性訴 求。Telemetry由于采用了更高效的編碼及上送機制，可以準實時（秒級）的采集 需要的數據。上送機制Telemetry通過推模式，讓網絡設備周期性自

13、動推送數據給網管側，避免重復查詢 提升監控性能。2.1.2技術原理Fabricinsight利用CE系列交換機設備的Telemetry特性采集設備、接口、隊列等性能 Metrics數據進行分析，主動監控、預測網絡異常。設備的Telemetry特性利用GRPC 協議將數據從設備推送給Fabricinsight的采集器。使用該特性前，需要在設備側導入 Telemetry 的 License GRPC協議介紹GRPC 協議（Google Remote Procedure Call Protocol）是谷歌發布的一個基于 HTTP/2 傳輸層協議承載的高性能、通用的RPC開源軟件框架。通信雙方都基于該

14、框架進行二 次開發，從而使得通信雙方聚焦在業務，無需關注由GRPC軟件框架實現的底層通 信。GRPC協議棧分層如圖2-1所示。圖2-1 GRPC協議分層圖數據模型：APP DATA業務聚焦編碼：GPBGRPCGRPC封裝HTTP2TCP各層的含義解釋如下所示：TCP層：底層通信協議，基于TCP連接。HTTP2層：GRPC承載在HTTP2協議上，利用了 HTTP2的雙向流、流控、頭部 壓縮、單連接上的多路復用請求等特性。GRPC層：遠程過程調用，定義了遠程過程調用的協議交互格式。GPB編碼層：GRPC傳輸的數據，通過GPB格式進行編碼。數據模型層：通信雙方需要了解彼此的數據模型，才能正確交互。用

15、戶可以通過命令行配置設備的Telemetry采樣功能，設備作為GRPC客戶端會主動與 上送目標采集器建立GRPC連接,并且推送數據至采集器。GPB編碼介紹GRPC協議采用GPB (Google Protocol Buffers)編碼格式承載數據。GPB提供了一種 靈活、高效、自動序列化結構數據的機制。GPB與XML、JSON編碼類似，也是一種 編碼方式，但不同的是，它是一種二進制編碼，性能好，效率高。目前，GPB包括v2 和v3兩個版本，設備當前支持的GPB版本是v3。GRPC對接時，需要通過“.proto”文件描述GRPC的定義、GRPC承載的消息。GPB 通過“.proto”文件描述編碼使

16、用的字典，即數據結構描述。Fabricinsight在編譯期根 據“.proto”文件自動生成代碼，并基于自動生成的代碼進行二次開發，對GPB進行 編碼和解碼，從而實現與設備的對接及“.proto”中定義的消息格式的解析。Telemetry訂閱機制介紹CE支持靜態配置或動態訂閱的方式訂閱感興趣數據：靜態訂閱是指設備作為客戶端，采集器作為服務端。由設備主動發起到采集器的 連接，進行數據采集上送。 動態訂閱是指設備作為服務端，采集器作為客戶端發起到設備的連接。支持 Telemetry的設備在完成GRPC服務的相關配置后，由采集器下發動態配置到設 備，完成數據采集。Telemetry數據釆集組網說明

17、用戶在CE系列交換機設備側配置完Telemetry性能Metrics數據訂閱規則,設備側按 照指定的周期采集相應指標數據，上送給Fabricinsight分析處理。組網示意圖如圖2-2 所示。圖2-2 Telemetry性能Metrics數據采集組網示意圖SpineSpine采集器集群對外發布OSPF的VIP路由,設備側Telemetry性能指標數據上報、 ERSPAN報文鏡像上報共用該VIP作為數據上報的目的地址。采集器集群通過 DPDKCollector進程統一接收數據報文，DPDKCollector解析報文頭根據報文類型分發 數據到后端的Agent進行數據的解析處理。2.1.3設備支持情

18、況CE設備支持的Telemetry采集指標參見：CloudEngine 16800, 12800, 12800E, 8800, 7800, 6800, 5800 V200R019C10 Telemetry 性能 指標集2.2 Telemetry異常檢測技術原理2.2.1動態基線異常檢測Fabricinsight使用時序數據特征分解、非周期序列高斯擬合等AI算法對設備CPU/內存 利用率、接口收/發包數等指標生成動態基線。相比傳統網管領域的靜態閾值，動態基 線基于一段時間的歷史數據學習，并配合基于動態基線的異常檢測算法，可以更準 確、并提前發現網絡中的指標劣化問題。當前版本將默認對Fabrici

19、nsight已接入的所 有CE設備建立CPU/內存利用率指標基線，默認對ARP表項、FIB表項、MAC表項 等路由表項指標建基線，也會默認對存在物理鏈路的接口建立收/發包數等指標基線。圖2-3動態基線異常檢測示例A AC Voke-17miAac66053.120叫22020建立動態基線，對比基線指標趨勢，識別異常指標亦a： 70%靈g： 1 刼：1 *se -犧酸-j222靜態閾值異常檢測Fabricinsight除了基于歷史數據生成動態基線外，還支持基于靜態閾值識別設備KPI指 標異常。2.2.3異常告警抑制Fabricinsight支持配置告警抑制規則并按照既定規則進行告警抑制，避免系統

20、產生過多 冗余的基線異常數據。當前系統默認定義連續3個周期超出基線，才會標記為基線異 常。并且一次連續的超出基線的現象，系統會自動進行合并只標記為一次異常，最終 入庫的基線異常數據將標記異常開始時間和結束時間。XX圖2_4異常告警抑制設置當前指標:接收包數關閉開關,不再基T靜態閾值檢SH異常！應用到當前對余Q所有對象當前指標靈Jg1應用到當前對象 C所有對象當前指標C所有指標BM曲3應用到當前對余 C所有對象當前指標C所有指標確走取消網絡流量分析網絡流量分析TCP流量分析UDP流量分析3.3報文轉發異常分析3.4 CE款型支持情況TCP流量分析目前Fabricinsight支持三種TCP流量分

21、析技術，包括TCP會話分析、TCP邊緣智能流 分析和TCP全流分析。3.1.1技術原理一個典型的流量分析系統由流分析數據輸出器TDE (Traffic-analysis Data Exporter) 流分析數據處理器TAP (Traffic-analysis Processor)和流分析數據分析器TDA (Traffic-analysis Data Analyzer, 即 Fabricinsight) 三部分組成：TDE：由使能了流量分析功能的設備承擔，負責配置指定待檢測的業務流，并上 送到TAPoTAP：由設備CPU內置芯片或分析器承擔，對TDE送的業務流進行處理和分 析，并將分析結果輸出至

22、TDAoTDA：表示一個網絡流量分析工具，具有圖形化用戶界面，使用戶可以方便地獲 取、顯示和分析收集到的數據，目前僅支持FabricinsightoTCP會話分析如圖3-1所示，Fabricinsight利用CloudEngine交換機的遠程流鏡像能力在交換機匹配 TCP協議報文，并將這些報文通過ERSPAN協議發送給Fabricinsight采集器進行TCP 會話分析。TCP協議中一條TCP連接的建立需要經過三次握手，連接關閉需要經過四 次揮手。因此CloudEngine交換機將TCP報文中的SYN、FIN、RST報文鏡像到 Fabricinsight采集器上，Fabriclnsight通過

23、對收到的ERSPAN報文進行解析，從而分析 網絡中應用之間TCP的建鏈拆鏈過程，獲取TCP流的轉發路徑、路徑時延、開始/結 束時間、字節數、會話異常。圖3-1 TCP會話分析示意圖Leaf3TCP ClientTCP ServerSpine2n /LeaFI/rLeaf2ERSPANiMasterNCE FabriclnsiahtSYN TCP邊緣智能流分析一個典型的邊緣智能流量分析系統由流分析數據輸出器TDE (Traffic-analysis Data Exporter)流分析數據處理器TAP (Traffic-analysis Processor)和流分析數據分析器 TDA (Traff

24、ic-analysis Data Analyzer,即 Fabricinsight)三部分組成。圖3-2 TCP邊緣智能流分析示意圖如圖3-2所示：在TDE上配置指定待檢測的業務流，并通過下發的ACL規則匹配該指定的業務 流，匹配通過的業務流將會由轉發芯片上送到TAP。TAP對收到的流進行處理，如果是滿足要求的特定流則建立流表進行分析。TAP將分析結果按照指定的目的地址進行封裝，將封裝后的報文發送給轉發芯片 進行路由查找轉發，最終到達TDA進行進一步的分析和展示。Fabricinsight根據沿途設備上報的流表數據進行關聯分析，可視化呈現轉發路徑、 時延、丟包分析。 TCP全流分析TCP全流分

25、析功能示意圖參見下圖：CloudEngine在進行報文轉發時對報文進行分析并創建五元組硬件流表，硬件流表 老化后上送CPU進行分析及預處理。異常流表條目在CPU上直接上送FI進行異常定位及回溯分析，另外CPU會將所 有流表進行壓縮后生成統計流表上送Fabricinsight進行流量統計及趨勢分析。CloudEngine的轉發芯片支持報文轉發異常感知，轉發芯片在感知到報文轉發異常（轉發超時延閾值和轉發丟包）時將異常報文上送CPU建流，CPU根據報文信息 創建轉發異常流表并上送Fabricinsight進行轉發擁塞及丟包分析。圖3-3 TCP全流分析示意圖異常流所有流 壓縮聚合五元組原始流表（硬件

26、）時延超閾值或 轉發丟棄報文ASIUJ 片創建原始流表報文PipeLi ne3.1.2適用場景三種TCP流量分析技術的用場景比對詳細參見下表。技術名稱TCP會話分析TCP邊緣智能TCP全流分析分析能力會話異常建鏈時延轉發路徑丟包統計 RTT時延分析建鏈時延轉發路徑 1:1流量統計表3-1三種TCP流量分析技術適用場景比對技術名稱TCP會話分析TCP邊緣智能TCP全流分析 Flag異常分析適用場景會話監控丟包/時延故障定位流量監控部署建議全局開啟故障定位時開啟全局開啟功能約束僅分析TCP控制報 文，無數據報文分析 能力受小NP性能限制， 僅可用于故障定位場 景僅P5芯片款型支持3.2 UDP流量

27、分析目前Fabricinsight邊緣智能流分析方案支持對UDP流量進行丟包、時延、轉發路徑進 行分析。3.2.1技術原理UDP邊緣智能流量分析與TCP分析功能不同的是，UDP智能流量分析功能是基于 Block粒度對UDP流進行建流分析的。依據Identification字段可以確定UDP報文的序 號，通過對UDP報文序號進行分段，可以將一個UDP流分為多個Block,如圖3-4所 zj 0圖3-4 UDP報文格式Block 255Block 0UDP flowoxrro 0,UDP 65280Oxrrrr.UDP 65535ldentificationJ| UDP報文的其瞬段得到匹配成功的U

28、DP流后，TAP將針對收到的第一個UDP Block中包含的所有UDP 報文進行分析，依據報文中的五元組信息等關鍵值形成一條條的流，從而組成一個流 表。每個Block的流表中主要包含的信息如表3-2所示。表3-2流表各字段說明字段描述報文數量支持統計設備UDP報文數量。報文大小支持統計設備UDP報文的比特數。時間戳支持統計時間戳，對于同一條UDP流，該時間戳隨數據上報量 的增加而增加。流創建時間支持統計UDP智能流量分析流表中流的創建時間。VNI支持識別報文的VXLAN網絡標識VNIoFabricinsight接收到設備上報的UDP流表數據后，根據TTL兩兩計算相鄰設備之間的 流信息（報文數、

29、字節數、速率）和轉發質量（丟包、時延）。3.2.2適用場景UDP流量分析適用場景參見下表。表3-3 UDP流量分析適用場景說明技術名稱UDP邊緣智能分析能力丟包統計端到端時延分析適用場景丟包/時延故障定位部署建議故障定位時開啟功能約束受小NP性能限制，僅可用于UDP故障定位場景3.3報文轉發異常分析3.3.1技術原理CloudEngine數據中心交換機在轉發報文時可以基于報文級別識別芯片轉發異常，并將 爭常報文上送CPU建立轉發異常流表并定期上送Fabricinsight進行分析，如圖3-5所 Zjx O圖3-5報文轉發異常分析流程Master nceCE目前CE交換機支持轉發超時延閾值報文及

30、轉發丟棄報文識別：轉發時延超閾值報文用戶可配置報文在設備內的轉發時延（即進出CloudEngine的時間差）閾值，女口 果報文在CloudEngine內轉發耗時超過用戶配置的時延閾值時會將超閾值報文上 送給CPU進行分析并創建轉發異常軟件流表。轉發丟棄報文當報文在設備內轉發時，因出端口擁塞、ACLDeny策略或轉發查表失敗導致丟包 時，轉發芯片可以感知到報文丟棄事件，并將丟棄的報文拷貝到CPU進行分析并 創建轉發異常軟件流表；轉發丟棄報文上送CPU進行建流，CPU根據上送報文頭 及轉發芯片標記的丟棄原因進行建流。3.3.2適用場景報文轉發異常分析功能適用的場景參見下表。表3-4報文轉發異常分析

31、適用場景說明技術名稱轉發異常分析分析能力轉發丟棄報文原因轉發丟棄報文計數適用場景CE轉發異常監控部署建議全局開啟功能約束僅P5芯片款型支持3.4 CE款型支持情況參見華為iMaster NCE-Fabriclnsight規格清單中“配套的CloudEngine設備規格清單”。網絡健康度分析網絡健康度分析4.1五級健康度評估4.2故障智能分析及閉環4.3設備維度4.4網絡維度4.5協議維度4.6 Overlay 維度4.7業務維度4.8網絡健康度報告4.1五級健康度評估iMaster NCE-Fabriclnsight結合telemetry機制并整合網絡中的配置數據、表項數據、日 志數據、KPI

32、性能數據、業務流數據，實時發現網絡中各個維度的問題和風險；檢測 范圍覆蓋設備工作狀態異常、網絡容量異常、器件亞健康、業務流量交互異常等范 圍，從而幫助運維人員“看網識網”，直觀地呈現全網整體體驗質量。Fabricinsight將 數據中心網絡分申5個維度進行網絡健康度評估：設備，網絡，協議，Overby,業 務，如圖4-1所示。圖4-1網絡健康度評估總覽基于網絡流分析業務毆情況A33發無孔Overlay BD、VNL VRF資亍狀態lOt強屹的刪確平面無孔網絡互連端狀態端口流量、錯包隊列羅光溜狀態協議 M-LAG組狀態 OSPF/BGP Peer連接絡穩議咸知網絡鏈路負載情y況，是否有擁塞丟包

33、硬件狀態：單板/風扇/電源等容量：ARP/FIB/MAC.CPU/內存負載設備物理斛是否有狀 態異常、資源溢出設備：物理設備是構成數據中心網絡的基礎單元，設備層面健康度主要評估物理 硬件狀態、表項容量、CPU和內存負載等單設備健康狀態。網絡：設備和設備之間互聯構成數據中心的物理網絡，網絡層面健康度主要評估 設備間互聯鏈路的端口狀態、端口流量、端口錯報、隊列深度、光鏈路狀態等設 備間互聯鏈路相關的健康狀態。協議：除了物理鏈路進行互連外，網絡設備之間還需要運行各種協議從而將網絡 形成一個整體進行報文轉發及其他協同功能。協議層面健康度主要評估OSPF、 BGP等路由協議工作狀態，還會對跨設備鏈路聚合

34、（M-Lag）協議的工作狀態進 行健康度評估。Overlay：當前數據中心網絡都引入了 SDN技術來實現網絡資源的池化及快速發 放，SDN技術的引入將數據中心網絡分為Underlay和Overlay兩個部分。業務流 量往往承載在Overlay層,Overlay層是否工作正常直接決定了業務的穩定性。 Overlay健康度主要評估VXLAN隧道、BD/VNI/VRF等資源的運行狀態。業務：Fabricinsight基于網絡流量分析能力監控業務流量帶寬、建鏈/拆鏈情況、 異常會話等業務狀態信息，實時感知數據中心網絡承載的上層業務的轉發狀態， 真正從業務層面評估數據中心網絡的健康狀態。4.2故障智能分

35、析及閉環4.2.1整體方案介紹故障智能分析及閉環的整體方案參見下圖。圖4-2故障智能分析整體方案示意圖iMaster NCE-Fabriclnsight故障智能分析（故障定位/定界）根因分析風險預測修復建議iMaster NCE-Fabric故障事件管理（故障修復）故障根因故障影響故障預案預案影響配置預案下發網絡數據采集健康度評估（故障發現）設備 網絡 協議 Overlay 業務iMaster NCE-Fabriclnsight通過Telemetry采集數據中心網絡設備配置、狀態、日志等數 據，之后分為網絡、設備、協議、Overlay、業務五個維度進行健康度評估。健康度評 估識別的異常由故障智

36、能分析模塊進行根因分析，并對識別的故障根因提供修復建 議。Fabricinsight分析出故障根因后通過部件間接口將故障信息同步給iMaster NCE- Fabric, 由iMaster NCE-Fabric可視化呈現故障根因及影響范圍，同時NCE-Fabric會針 對故障推薦故障修復/隔離預案，用戶經過確認可一鍵式下發預案相關的配置完成故障 修復。4.2.2故障發現iMaster NCE-Fabrclnsight通過五級健康度評估發現數據中心網絡中發生的網絡故障及 風險，下面簡單介紹網絡健康度評估故障發現的幾種典型方式：網絡監控對象周期性采用數據發現故障iMaster NCE-Fabric

37、lnsight分析器通過Telemetry訂閱設備上特定對象的周期性采樣 數據，如設備接口收發報文的統計數據，光模塊的指標數據，丟包統計數據等， iMaster NCE-Fabriclnsight分析器通過比對所有監控對象的周期性采樣數據發現異 常，報告故障；例如：光模塊收發功率過低導致的故障。流異常發現故障iMaster NCE-Fabriclnsight分析器通過捕獲TCP報文或分析設備上送的流量分析網 絡流量數據，分析有建鏈異常的TCP會話、設備上報的轉發異常流表等識別流異 常類型的故障；TCP流異常發現故障能力，依賴于設備具有TCP報文鏡像上送或 流表上送能力，如果設備不開啟該功能，或

38、網絡中無TCP流量將無法發現此類問 題。告警日志發現故障有些故障產生后，網絡設備自身會產生告警，并上報網管或其他日志采集系統， 在CloudFabric智能運維解決方案中，有些故障就是通過收到設備告警日志觸發； 如設備資源不足類故障。周期性探測網絡連通性iMaster NCE-Fabriclnsight分析器通過對網絡監控對象的周期性使用ICMP進行連 通性檢測，可以發現因網絡可達性異常導致的故障。女口：設備管理通道中斷故 障。DPV驗證發現的異常Fabricinsight通過定期采集網絡中配置、ARP表、FIB表、網絡拓撲及網絡設備對 象的狀態等提交給DPV引擎，DPV引擎通過仿真驗證算法模

39、擬網絡設備的轉發行 為。周期性的針對Fabricinsight預定義及用戶自定義的規則進行驗證，當DPV驗 證結果和用戶預期不一致時識別為異常。4.2.3故障定位定界CloudFabric網絡健康度方案中，故障的定位定界是在故障發現能力的基礎上，通過 iMaster NCE-Fabriclnsight分析器的大數據分析引擎對收集的網絡數據進行分析，并給 出故障的定位和根因；針對不同的故障，iMaster NCE-Fabriclnsight分析器會采用針對 性的故障定位算法進行處理，以提高故障根因的判斷準確性。如圖4-3所示，iMaster NCE-Fabriclnsight分析器通過設備實時上

40、送的TCP建鏈報文或 流表，對TCP會話狀態進行實時監控。當發現有TCP鏈接異常事件發生時，iMaster NCE-Fabriclnsight通過AI引擎分析檢索出有相同故障特點的TCP流量，“知識推理引 擎”根據異常流量的發生位置，對該設備上故障時刻和此前正常時刻的相關網絡數據 進行分析，然后給出故障根因。圖4-3流量異常類故障定位邏輯由告警日志觸發的故障定位邏輯網絡設備的告警上報的故障，iMaster NCE-Fabriclnsight分析器的判斷邏輯通常有兩 種：第一種是告警可以直接定位問題根因的，例如設備資源超閾值類告警，設備上報 的CPU、內存或表項超過設備設定的閾值告警，這種情況故

41、障根因直接就相關資 源不足。第二種是設備產生的告警問題根因不是告警本身，二是其他故障發生后引發的連 鎖反應，這種問題的根因定位就比較復雜，傳統網絡對于這類問題的排障通常頗 費周折，定位時間一般都比較長，而且對用戶的問題定位經驗或技能要求也比較 咼。iMaster NCE-Fabriclnsight分析器對于這類問題構建了 “知識圖譜”推理引擎：“知識圖 譜”推理引擎通過構建故障在網絡對象間的傳播方式，對故障知識進行建模，確定網 絡對象間的依賴關系，在收到設備產生的告警時，iMaster NCE-Fabriclnsight分析器基 于知識圖譜進行故障溯源，定位出故障的真正原因所在。圖牛4基于“知

42、識圖譜，的推理引擎基于網絡知識圖譜+推理引擎1L知識獲取網絡知識實例圖故障傳播條件I學習L 一二故障傳播條件圏知識圖譜應用舉例：下圖以接口故障導致BGPPeer會話故障為例，展示了知識圖譜的 簡要故障定位原理。圖4-5知識圖譜在“接口故障導致BGPPeer會話故障”中的應用舉例通過知識圖譜，快速進行故障根因溯源L2Link2InterfaceBGPBGP20L2Unk10 OSFPPeerlOSFPOSFP Peer2OSFP3In terface故障場景：設備上報“BGP對等體斷開”告警。當iMaster NCE-Fabriclnsight分析器收到設備上報的“BGP令B居1斷開”告警時，會

43、根 據知識圖譜查找該BGPPeer綁定的BGP進程，并進一步查找承載該BGP進程的 Underlay OSPF路由進程，發現OSPF 1進程所關聯的OSPF鄰居1狀態發生變化，進 一步溯源發現該鄰居所在L3接口的狀態異常，最終根據知識圖譜確認為轉發往該鄰居 的L2出接口鏈路down導致。此時iMaster NCE-Fabriclnsight分析器會報告“BGP鄰居1斷開”的故障根因為 “Linkl ”鏈路down導致。網絡監控對象的周期性采樣數據故障定位邏輯對于某些網絡對象，iMaster NCE-Fabriclnsight采集器會通過Telemetry訂閱多種網絡對 象的采樣數據，并通過大數

44、據分析引擎對采樣數據進行周期分析統計，當發現采樣對 象發生故障時，AI引擎根據采樣數據的分析結果發現異常，并給出故障原因。例如“光鏈路故障” case中，iMaster NCE-Fabriclnsight分析器會對光模塊采樣數據進 行持續分析判斷，包括光模塊的溫度、電壓、電流、光功率等，當發現其中有參數偏 離正常值范圍，iMaster NCE-Fabriclnsight即會報出光鏈路故障Issues,并呈現相關參 數的異常數據值及故障對象的歷史數據走勢。通過網絡連通性探測故障定位邏輯還有一些故障的判斷是通過連通性檢測手段發現的，分析器會通過ping、openflow構 造探測報文等手段檢查目標

45、對象間的連通性，并根據結果判斷是否發生故障。例如“交換機管理通道中斷故障iMaster NCE-Fabriclnsight分析器通過周期性ping 每個納管設備的管理IP來發現設備是否失聯。、4.2.4故障恢復隔離當前iMaster NCE-Fabriclnsight分析器發現并定位故障后，會將故障事件通過部件間 API通告給iMaster NCE-Fabric控制器，iMaster NCE-Fabric控制器根據發生的網絡故 障事件，來判斷是否可通過配置手段對故障進行修復，如果可行則會給出相應的修復 預案，用戶在故障事件管理UI中選擇修復預案后，iMaster NCE-Fabric會對該預案

46、的 修復手段做出說明，呈現該預案將下發到設備上的配置信息，如果修復預案實施后會 對網絡產生影響，iMaster NCE-Fabric控制器還會提供預案影響分析，供用戶決策是否 要最終實施該修復預案。根據對故障修復程度的不同，又可將修復預案劃分為“恢復預案”和“隔離預案”兩 種。恢復預案恢復預案是通過對故障設備下發配置可修復故障，且除修復故障問題外，修復預案不 會在設備上產生新的配置（更改設備已有配置中的錯誤參數除外），設備上已配置的其 他網絡特性或功能不會受恢復預案影響。因此“恢復預案”從配置層面來說對設備的 影響是最小的。卩鬲離預案隔離預案是設備發生的故障，根因是業務側導致，或需要現場排查，

47、或需要更換硬件 后才能徹底解決的，但是通過配置手段可以在故障解決前，將故障源暫時隔離，以降 低或消除其對網絡產生的影響，此類型的預案稱之為“隔離預案”。4.3設備維度設備維度網絡健康度評估主要用于識別單設備異常，如整機故障、風扇/電源故障、設 備表項利用率超閾值等，下面以FIB4表項資源異常及疑似二層環路為例介紹設備維度 健康度分析。4.3.1 FIB4表項資源異常應用場景出現資源不足問題后只能人工登錄設備查看資源占用分布，無法及時感知設備表項資 源不足問題，問題排查效率低；缺乏對表項資源變化的主動識別，判斷是否存在異常 行為。分析對象單板故障識別原理基于Telemetry機制實時檢測單板FI

48、B4表項利用率，如利用率超過設備閾值，則識別 為“交換機FIB4表項超閾值”故障。修復建議將設備升級為表項規格更大的型號，或者將后續上線業務遷移到其他Fabrico通過 iMaster NCE-Fabric 進行修復。圖牛6 FIB4表項資源異常示例4.3.2疑似二層環路應用場景在Fabric網絡中可能存在單設備接口自成環、單設備不通接口之間成環、外部網絡成 環、多設備成環等場景，網絡中一旦出現環路，會導致業務中斷，帶來商業損失。網 絡管理員需要及時發現環路現象，識別環路的設備+端口，快速消除環路影響、進一步 進行根因排查和修復問題。檢測對象設備、接口故障識別原理檢測全網設備MAC地址漂移記錄

49、及基于Telemetry機制實時監測端口收發廣播報文數 變化趨勢，識別環路端口；根據二層域聚合各設備環路端口，識別為“疑似二層環 路”故障。修復建議shutdown環路接口，排障環路口是否存在接線問題。通過 iMaster NCE-Fabric 進行修復。圖4-7疑似二層環路示例V 1谿路問題疑似二層環路致命Suspected Loop Devices=Device=DC2 SVL.對象 Suspected Loop Devices=Devi.CLOSE狀態CLOSE2020-04-03 22:52:082020-04-03 23:03:00A 10GE1/0/610GE1/0/6DC2 SV

50、L185.15是10GE1/0/710GE1/0/7DC2 SVL185.15是共2條514.4網絡維度網絡維度健康度分析主要識別設備互聯鏈路故障、光模塊異常等和設備互聯相關的網 絡故障，下面以亞健康光模塊檢測、微突發檢測為例介紹網絡維度健康度分析。4.4.1亞健康光模塊檢測應用場景光鏈路維護面臨的挑戰主要包括：光模塊長時間運行，光器件性能衰減，導致鏈路不 穩定；光模塊問題現象無規律，難于復現，定位周期長。檢測對象光模塊故障識別原理基于光模塊的運行指標，并結合光模塊硬件工作模式、華為IT現網運行經驗，構建光 模塊亞健康檢測算法。周期性監控以下指標：接收光功率、發送光功率、偏執電流、 電壓、溫度

51、、CRC錯包數，識別出指標有異常后會生成“疑似光鏈路”故障。修復建議步驟1在健康度問題界面，瀏覽當前狀態是OPEN的疑似光鏈路故障問題。 步驟2展開查看問題詳情，如下圖所示，查看疑似故障的光模塊、存在異常的指標以及影響 的鏈路等信息。步驟3根據修復建議中給出的修復方案進行操作。圖牛8亞健康光模塊檢測示例O問題超障對象 Source Device = .OPEN痢制靖 Serverleaf-Mlag.嚴重加站 spinel 40GE1/0/1MFabric openlabjffwFabric openlab問題根因發射率異常a,接口新增接收ts濱包救摘標近11天內出現12次J修復建議*. 0楂查

52、該接口的光模塊類型是否與接口匹配； 卻果確認是匹配的 則更換該接口的光模塊；Serverleaf-Mlagl-1192202.16.18100GE1/0/1spinel1 40GE1/0/1Serverleaf-M lag 1-. up廠商： 尉態:HUAWEIup封律型： 生產日期：qsfp28 2015-07-25華為認證：是光模理：40GBASE_eSR4異常指標|I所勢Sending PowerServerieaf-Mhgl-1 軸的期此譙塊Servedeaf 19Z85.1.2:102I協議:1028- :102UDPII馳占比4231100.00%4.5協議維度協議維度網絡健康度分

53、析主要評估設備間運行的網絡協議工作狀態，例如OSPF、 BGP、M-Lag等，下面以M-lag雙主檢測為例介紹協議維度健康度分析。M-LAG雙主檢測應用場景M-LAG作為一種跨設備鏈路聚合的技術，把鏈路可靠性從單板級提高到了設備級。但 如果心跳中斷，而且peer-link故障時，M-LAG會出現雙主現象，導致兩臺交換機的 表項無法同步，可能會出現流量不通，對業務產生影響。檢測對象M-LAG設備故障識別原理實時檢測M-LAG設備DFS-Group鄰居狀態狀態變化；在出現異常時，主動檢測M- LAG設備成員組DFS-Group主備狀態。如M-LAG組成員設備DFS-Group都為主，則 識別為“交

54、換機M-LAG成雙主狀態”故障。修復建議通過shutdown上下游設備的互聯端口或修改路由轉發優先級，將設備從網絡轉發 平面中隔絕出去，被隔離期間設備將不會接受/轉發業務流量（設備自身的網管流 量除外）；下發預案前請確保隔離故障設備后還存在其他備份平面，否則可能引發 業務故障。通過 iMaster NCE-Fabric 進行修復。圖牛10 M-LAG雙主檢測示例O問題 33mM-LAGfil65R.對象 Member Device 1 =p.悴 CLOSEFabric POD12致命成員S&1 IP47成員爾1悴Backup成員設備2 IP 46成員設備2狀態Master問題根因peer-li

55、nk鏈路狀態異常.遊彩響術影晌范圍M-LAG雙主狀態可能導致兩臺設備間MAC、ARP表項狀態不一致,影晌環側2個IP通信明細.drI12-mlag1 2-147pMf-link(d12mlag1jM46IPitMt0|Eth-Trunk1.20000|Eth-Trunk12001共2條5- 旋：SYN16522.10VRF0route_Finance_000000116522.10正枷IS 徑 1： (01-09 10:3026,141)192202.16.18SeiverLeaf016522.10VbditS005routejinanceOOOOOOlroute_Finance_000000

56、1VMfSOOe19220Z16.18_5enfled=4eat_19220Z16.13ScxMefleaf正囪眸寰似故障:2個基于規則引擎的排障查看貝瞪明細Snapshot one 2018-11-6 16:15:002 ASnapshot on： 2018-11-6 16:25:002 A411 interfece eth-trunk 0411 interface eth-trunk 0412 trunkport 10ge 1/0/3412 trunkport lOge 1/0/3413 trunkport lOge 1/0/4413 trunkport lOge 1/0/4414 mode lacp-static414 mode lacp*static1415 peer-link 14415 peer-lin