|
某单位市公司核心网络交换设备持续负载过高的故障定位与排除一、网络环境与故障描述 某集团公司某市分公司生产网络出现了主干网络交换设备负载过高的情况，由于集团业务涉及民生，又恰逢重大节日，为了保障网络通讯正常，该公司要求在保持正常通讯的情况下排除故障。
1.1 网络环境 该市分公司规划分为两级网络，一级网络为核心主干网络，二级网络为各行政区分支机构网络。由于历史原因主干网未建立汇聚交换层，仅开发区设置有一台汇聚交换机但未启用三层功能，所有二级网络网关均指向核心。核心交换机为思科6500系列万兆设备，二层交换机百余台，均采用思科或H3C常见三层交换机作为二层交换使用（三层功能未启用），其中直连核心的二层交换机约50台。
下图为该单位网络拓扑的示意图。图中县/镇级交换机数量多，不一一画出，各接入交换机都连接有多种网络设备。
[size=1em]1.2 [size=1em]故障描述
本次故障主要出现在部分接入交换机和核心交换设备上，直观特点是CPU利用率持续过高，部分设备CPU利用率达到90%以上。
故障持续了三个月，初期是个别思科接入交换机CPU利用率升高到70%以上，经过排查未能找到根本问题，一段时间后核心交换CPU利用率突然升高到70%以上，出现了骨牌效应，开发区所有思科接入交换机CPU利用率都出现了过高的情况，最高的能达到100%，持续了1周时间，待我们到达现场时，除以上情况外，核心交换机CPU利用率升高到了90%左右，而更加奇怪的是热备核心交换机CPU利用率也竟也达到了70%，网管系统持续告警。
该单位管理人员十分紧张，由于该单位网络为生产型网络且与民生息息相关，绝不能出现网络中断的情况，对于故障点的定位，则需要极高的准确性，否则就会给生产和民生造成极大影响。因此，该单位现场工程师对该问题的处置慎之又慎，只有在100%确定故障来源的情况下，才能对故障设备进行调整处理。
二、故障类型研判
在该单位在核心交换处旁路部署一台科来网络回溯分析设备，对所有启用端口数据流进行观测，通过观察发现核心交换机每秒处理数据包总数在10 万个以下，单从数量来说不足以使万兆交换设备出现CPU 占用率超过90% 的情况，而且CPU 占用率不稳定。如下图，
因此造成CPU利用率高的问题可能是由于部署某些特殊应用或者网络设备之间存在高频率的通讯，且该类通讯对设备的CPU占用率较高，例如生成树STP的TC报文、BPDU报文攻击、生成树震荡产生的ARP风暴等等。
三、故障排查 通过以上初步判断，梳理相关流量是解决问题的第一步，对各类流量的对比分析是解决问题的关键。下图为该单位故障期间，利用科来网络回溯分析设备得到某段时间内的网络流量概况。
从图中可以看到广播包数量占比偏高，非IP流量中的广播流量达到了 93.5%（参考值为5%），核心设备收到的二层广播包过多，因此怀疑网络中存在ARP广播风暴。所以需要单独针对广播流量回溯分析，是发现故障点的关键要素之一。
通常交换设备的CPU占用率高与某些应用的异常密切相关，梳理数据流构成，找到异常应用是发现故障点的另一个关键要素。与现场工程师沟通了解到，故障期间各网络设备的内存占用率都不高，因此考虑按照每个应用的发包频率梳理数据流构成比按照每秒字节数梳理效率更高，更加有利于定位故障。因此按照发包频率对各应用排序如下：
常被蠕虫入侵实用的CIFS协议发包频率较多，但平均包长在1KB左右，挖据分析后发现为正常的文件共享通讯。较为反常的是SNMP协议的数据包数量平均每秒达到2230个，网络中启用SNMP管理的网络设备、应用服务器大概有100多台，平均每台设备每秒收发20个snmp报文，比OA、视频会议、数据库协议都高。通常网络管理软件利用SNMP协议查询网络设备的实时硬件状态，对设备CPU的占用率是比较高的，如果同一台设备同一时间收到多的SNMP数据包，会占用大量的CPU二级缓存，造成利用率持续较高的情况。
初步认为是ARP广播和SNMP查询频率过高造成的CPU利用率持续过高的情况，同现场工程师沟通后，利用思科进程展示命令查询核心交换机CPU占用情况如下：
第8项 ARP input CPU占用率在20%左右，第340项SNMP引擎CPU占用率56%左右，都是相当高的，CPU占用率不稳定也与SNMP协议通讯间歇性有关。所以，经过以上证实了之前关于故障类型的判断。与现场工程师沟通了解到，使用SNMP通讯协议的网管网络应用非常多，大概有20多个；二层交换设备有近百台，大部分都是直连核心的约有50多台，因此认为ARP风暴可能是“重灾区”，后来经过定位分析也证实了这个猜测。
四、故障定位 4.1异常SNMP通讯定位 由于使用SNMP协议通讯的应用很多，因此针对SNMP协议流量进行专项分析，排除其他数据包的干扰，节省分析的时间和步骤。
下图是SNMP通讯协议回溯分析视图
从上图可以清晰看出，故障当天10点到下午13点，SNMP通讯的数据包呈现波浪式的通讯，峰值数据包数量2Kpps，使用SNMP通讯协议的IP地址见下图右侧，IP地址按照发包频率由高到低排列：
上图可以清晰的看出SNMP数据流主要是以地址15.251为主，其他流量几乎可以忽略。对该地址进行数据挖掘，如下图，该地址与255网段所有存活IP进行通讯，跟现场工程师沟通后得知该网段全部为网络设备管理地址。其通讯频率之高，令人瞠目结舌。3小时内与各网络设备平均通讯频率最低20pps，最高的达到了83pps。通讯频率最高的地址为255.2，经确认该地址属于备用核心，这就清晰的解释了备用核心机未使用，而CPU利用率也高达70%的原因。
针对地址15.251做回溯分析，如下图，发现该地址仅存在SNMP通讯，且通讯波形与全局下的SNMP通讯几乎一致，可见第一个故障点已经找到。
从上图看到15.251和225段的所有IP地址查询和回复数据包比例基本为1:1，而将该数据包解码，如下图
其查询包采用snmpv2，报文仅max-repetitions一项参数呈现递增规律，其余各项完全相同，该参数用于指定返回项目个数，跟工程师核实后确认该地址属于一台准入设备，其通讯频率阈值设置存在问题，不间断的向所有网络设备查询状态。
4.2 广播风暴
对网络中的广播包进行单独分析，需要借助科来网络回溯分析设备针对某一个MAC地址的回溯分析，一般广播目的Mac地址为FFFF:FFFF:FFFF:FFFF，所以在控制台对这个Mac地址进行分析得到下图
由上图可以看出，网络中存在大量的广播风暴，广播包总数最大峰值15Kpps。在我们分析期间，某个MAC地址最大的ARP解析请求能够达到400pps，下载其中某个Mac地址分析数据包得到下图
可以清楚地看到全部为ARP协议的request数据包，查询源为二层设备的管理地址255.38，而目标是其他网络设备的管理地址，ARP风暴仅存在于Vlan255中，而该Vlan仅属于网络设备，通过Mac地址和IP地址追溯发现，ARP广播风暴设备以H3C设备为主。与现场工程师沟通后确认网络设备均已启用STP生成树协议，造成arp广播包环路的可能性不大。
常见的ARP广播风暴一般是由于病毒引起的，一类是扫描引发的广播风暴，常呈现较为规律的探测，例如查询某一个段的所有IP，或对网络中不存在的地址进行查询，对这类查询按照目的IP地址排序后地址序列呈现递增规律，有些病毒会乱序扫描，但最终为了达到发现的目的，每个网段每个地址在一定时间范围内一定都会扫描到，因此按照目的IP排序就可以清晰的看到隐藏的秘密；另一类是特定的攻击行为，只针对某几个特定的地址进行高频率的ARP攻击。
从上图可以看出，查询的IP地址均在网路中使用，且没有连续的查询，应不属于第一类扫描。与现场运维工程师沟通后了解到，该单位内网与外界物理隔离，且使用的是静态IP，接入设备和终端做了ARP双向绑定，单位内部而爆发跨区县的大面积的针对网络设备的攻击行为概率非常小，如果存在就属于很严重的治安事件，为了排除这种可能，要求现场工程师，关闭了核心、直连交换设备的ARP代理功能，观察广播风暴情况，发现没有任何变化，应该不是攻击行为引起的。因此判断风暴来自于二层设备本身，而非客户端病毒。
由于二层设备启用了Vlan功能，该二层设备应该有ARP映射列表，该扫描是否与动态映射列表更新有关系呢，我们找到Mac地址对应的网络交换机，查看了该交换机上的arp映射，惊奇的发现Vlan255的映射地址与该设备发往核心的ARP请求完全吻合，而且该映射列表全部为动态映射，与现场运维工程师沟通后得知，所有直连核心的接入设备全部为动态映射。
初步考虑是由于偶发的生成树震荡，引起的ARP动态映射列表清空，而思科与H3C设备应对机制不同或配置存在差异，多设备同时刷新ARP映射时，引发了骨牌效应，使得H3C交换机不停地刷新动态的ARP映射关系，产生了大量的ARP查询报文，造成了接受这些ARP查询的思科设备CPU利用率升高。
上图中只显示了部分直连核心的交换设备的ARP请求大，可能是由于核心交换机的保护机制，ARP数据包到达一定数量后，部分被随机丢弃。在后期的处理中，也证实了这个猜测。
五、
解决方案
5.1 SNMP准入设备处置
经过分析，定位出的问题网管设备：“15.251”，为近期新配置的一台准入设备，时间点与核心设备CPU占用率升高的时间点基本吻合，该设备的配置修改需要与厂商协同处理，目前为保证网络设备的正常运转、保障生产网络稳定，对该设备采取离线处置。该设备离线后，核心和各网络设备的CPU利用率下降了30-40%左右，核心交换机CPU占用率达到60%左右，核心设备显示SNMP引擎进程，CPU占用率下降到9%左右。截至发稿时，该厂商已经解决了这一配置问题。
5.2 ARP广播风暴的处置
ARP广播的问题主要是动态映射列表刷新的问题，采用静态映射就可以解决这一问题。在处理过程中发现ARP风暴基本为H3C设备，对TOP20的设备进行绑定后，其ARP发送量迅速回归到1pps以下，而之前发包速率在20PPS左右的地址，ARP查询数据包迅速增大到300pps以上，说明这一问题是一个普遍问题，只显示部分地址ARP查询包频率高的原因可能是核心设备启用了ARP防DOS攻击机制，在端口处有随机丢包的情况。绑定所有发包频率大的直连交换机后，核心CPU利用率下降到了50%以下，二层交换设备CPU利用率全部在60%以下，恢复到故障前的正常水平。该问题得到了顺利解决。
六、
总结
近几年，许多地方网络通讯发展迅猛，网络发展现状已经远远超过了最初的网路设计规模，而网络设备更是快速迭代，便出现了多品牌同类型设备的混搭使用，这个过程中，不同厂商的路由交换解决方案的细微差异，配置不当就可能造成网络故障。
网路应用越来越多，网络管理工具也更加多元化专业化，工具本身的配置复杂程度已经超过了一般管理员所掌握的范围，精准定位网络中的突发故障，更需要通过回溯对比分析研判故障类型，在这个过程中，原理与现象相互印证是对故障点精确定位的不二法则。 | 
发表于 2016-3-29 17:21:18