CloudFabric云数据中心网解决方案网络健康度设计指南

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