ZABBIX在韶钢二层网络环路故障处理中的研究与应用

黄福康 曾国辉 邹德胜 黄志君

摘要：众所周知，二层网络环路故障是一种破坏力非常强的故障，特别是发生在二层网络级联交换机过多，广播域过大的场景。环路故障对业务系统的影响不仅严重，而且范围广，并且传统的处理方法费时费力，效率极其低下。本文是在此背景下，阐述的一种基于ZABBIX监控系统，利用对监控机制和广播包传输机制的理解，快速定位环路故障源的技术方案。本文结合二层网络环路的形成特点，通过对ZABBIX监控系统监控功能的研究，提出一套针对性的监控方法。实践表明，该方法能够迅速定位环路故障源头，达到切断广播风暴来源的目的。

关键字：ZABBIX，环路，广播风暴，监控，SNMP，监控系统，自动化

引言：笔者在韶钢从事网络运维10年，目睹传统钢铁企业信息系统从简单到复杂的过程，深感信息系统对于传统网络运维方式的颠覆性的作用。深切理解从人力运维，到使用信息化监控工具运维，在运维效率，成本优化方面的巨大优势。在此借助此文，从这个具体且有代表性的故障案例出发，分享一种利用信息化监控系统提升故障处理效能的具体实践，并分享我对监控系统辅助运维的理解。

正文：

1、广播风暴和传统的环路故障处理

首先简要介绍一下什么是广播风暴和环路故障，以及产生环路故障后传统的处理手段是怎么样的。

广播风暴（broadcast storm）是指广播数据包充斥网络无法处理，占用大量网络带宽及网络设备处理能力，导致网络业务不能正常运行，甚至彻底瘫痪的现象，“广播风暴”产生非常容易，只需要用一条网络线缆将同一台二层交换机的两个物理接口接上，或者将位于同一广播域的两台二层交换机用一条网络线缆接上即可。

达成环路条件的二层交换机及其广播域内的其他交换机会因为无限的转发广播包，让广播域内广播包的数量迅速地达到交换机无法处理的阈值，导致交换机的CPU使用率达到100%并处于半卡死状态，使网络系统进入瘫痪状态，具体的表现就是网络变得极其卡顿或中断。这种故障常见于网络用户自己乱接网线引起的错接网线的场景。

对于环路故障，传统的处理方式是从核心交换机处逐个断开网络线缆，逐个排除每个下联交换机或用户的影响，以核心交换机的CPU使用率是否降低及广播水平是否下降，来定位环路产生的目标交换机。然后从定位到的目标交换机再逐级向下用同样的方法定位，直到找出最末端出现环路的接口，并移除环路的网线，从而移除故障。

这种定位方式及其原始，特别是当二层广播域很大，涉及的下联交换机很多的情况，有时候维护人员要辗转多个物理位置，操作多台下联交换机，这种处理方式就显得效率及其低下，维护人员也及其辛苦。

2、使用ZABBIX监控系统监控广播包数量，定位环路故障。

    什么是ZABBIX监控系统，zabbix（[`zæbiks]）是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。

2.1 监控的条件

首先，我们要安装ZABBIX监控系统服务端（安装方法参考官方文档https://www.zabbix.com/cn/download），并保证ZABBIX的SNMP（Simple Network Management Protocol）简单网络管理协议的监控功能可用。然后要保证二层网络内的所有交换机都是可管理交换机，并且支持且启用了SNMP协议监控。同时ZABBIX监控系统服务端要能和监控的目标交换机网络连通。

2.2 使用ZABBIX监控可管理交换机的接口的接收广播包速率

部署该监控分为以下几个步骤：

2.2.1 建立监控项

在ZABBIX监控系统建立交换机接口入方向广播报文统计监控项，监控项的类别使用SNMP agent类别，监控项的SNMP OID（Object Identifier）对象标识符为：1.3.6.1.2.1.31.1.1.1.9.{接口索引}。

图一

如图一所示，其中{接口索引}为交换机接口的索引号，根据具体交换机接口而异，这个OID 1.3.6.1.2.1.31.1.1.1.9.{接口索引}的含义是接口入方向广播报文的统计，注意他是一个报文的总量统计，接口每接收一个广播包，则统计值加1。

图二

比如图二中IF-MIB::ifHCINBROADCASTPKTS.1这个接口，他的接收总量统计值为112770。

2.2.2 对监控项进行预处理

图三

如图三所示，使用ZABBIX的预处理功能对上述OID监控得到的接口接收广播包总量统计值进行“每秒更改”处理，这个处理的作用是将最近两次取样的总量统计差值除以取样时间间隔，得到采样值的变化速度：包/秒，也就是接口接收广播包速度。

(本次取样值 - 上次取样值)/监控时间间隔 = 接口接收广播包速度

2.2.3 建立触发器

在ZABBIX配置关于这个接收广播包速度监控项相关联的触发器，也就是报警器，让监控指标达到特定阈值时发出报警。

具体配置逻辑为：最近的连续两次接收广播速度取样值的最小值大于3000则触发报警。这个逻辑的意义为：当出现接收广播包速度在最近的两个连续的取样周期里持续超过3000广播包/秒的情况下，则触发报警。

具体的ZABBIX触发器表达式为：

min(/Template SNMP Interfaces BROADCAST in/ifHCInBroadcastPkts[{#SNMPVALUE}],#2)>3000，如图四所示：

图四

2.2.4 关闭上联口监控

关闭交换机上联口的接收广播包监控报警，也就是说只监控交换机下联口的接收广播包。

图五

图五显示了一台部署了广播包监控的交换机的触发器面板，以及被关闭的上联口广播包监控触发器:GigabitEthernet1/0/24，右边红色的“停用的”标识代表其已被关闭。

2.2.5 使用动态拓扑图呈现结果

使用ZABBIX拓扑图辅助接收广播包监控以定位环路故障源。

ZABBIX拓扑图是一个监控功能的重要组成部分，他可以辅助维护人员快速直观的定位故障源

图六

图六显示了一台接入层交换机（右下角变红的交换机）发生接收广播包报警后定位了接收广播包过多故障的接口为Ethernet1/0/2，也就是这种处理环路故障的方法最终在ZABBIX拓扑图展示出的结果。运维人员可以直观的从拓扑图中看到哪条链路上的哪些交换机直接受到了下联的广播风暴冲击，从而定位出故障源。

3、此技术方案的逻辑解释

3.1 为什么要监控广播包

为什么选广播包作为此类故障的监控目标，原因是环路故障出现恶性效果最显著的特征就是广播风暴，广播风暴就是导致交换机瘫痪的第一原因，二层网络内部的广播包水平高低，直接昭示出此故障的特征。

由于交换机对于广播包的处理机制，导致环路故障时，广播包的数量暴增现象是及其显著的，其暴增曲线不是平缓的，而是会在几秒内迅速暴增至二层交换机对广播包的处理极限，通常是上万个广播包每秒的级别，根据交换机的处理能力有差别，所以监控系统能够及其容易的通过广播包发现故障。

3.2 报警触发器的配置逻辑是怎么样的

为什么报警触发器要选择连续两次取样的最小值大于3000，而不使用其最近一次取样的值大于3000，原因第一是广播包是正常业务必须的流量，有时候业务发生变动，广播包会偶尔出现增加超过3000的情况，在实际监控的经验里面，这样的增长大部分时候是暂时的，或者说偶然的，而将业务需要的广播包过多判定为环路是不恰当的。而当环路故障产生时，广播风暴产生，带来的是连续的广播包速度暴涨，这样就恰当匹配了连续两次取样都大于3000包/秒的逻辑。就能精确预报故障，而不是频繁因正常业务的广播包产生误报。

而3000这个数值则是本人在工作场景的监控实践中，根据业务实际情况得出的一个恰当值，大家可根据不同的情况适当调整。

3.3 为什么要关闭上联口广播包监控

原因是交换机上联口接收到的广播往往是其他交换机发送的，如果打开了上联口接收广播包监控，当广播风暴发生时，所有二层广播域内的交换机都会因上联口接收到的巨量广播包而发生报警，就会出现全网所有交换机都在报警的情况，也就无法定位出广播风暴产生的故障源，换句话说就变成了无效监控了。

关闭了上联口广播包监控后，定位效果只在交换机的下联口产生，监控就会由下联口方向不断向下联口交换机遍历查找故障源，从而在拓扑图上清晰的勾勒出具有故障指向信息的脉络。而那些并不在故障产生脉络上的交换机则不会报警，在拓扑图起到清晰定位的作用。

4、从具体的故障处理回到监控系统运维

接下来我们对这个故障处理做一个总结，环路故障监控只是监控系统ZABBIX对于故障处理的一种实现，我们还可以通过ZABBIX系统，对其他各种各样的故障进行监控及处理，而使用监控系统运维工具处理故障，相对于人力处理，其本质区别究竟在哪里？对于这个问题的研究，应该有助于我们充分发挥自动化运维工具的优势，并且有助于我们在未来有目的使用监控系统的各种新功能，帮助我们更好的运维信息系统。

4.1 监控运维系统使信息获取效率极大的提高

比如在环路故障中，传统的获知广播接收水平的方式是手工登录一台台交换机，并且一个一个接口轮流敲命令查看，并且对哪个接口是可能的故障候选接口完全没有任何预警可以作为提示。而监控系统则直接获取，不需要敲命令，并且同时获取，不需要一个一个接口轮流查询，极大提高了故障信息获取的效能，在故障处理中获取了先机。

从本质上来讲，对于监控运维系统来说，单纯的增加监控设备的数量，并不会对它的运维效率造成什么压力，100台和1000台是一样的，它都是直接获取监控指标，换句话说，对于监控系统来说，监控设备数量的多寡并不会对监控系统运行的“熵”造成很大的增量。而对于人力运维来说，维护设备的数量和人力成本是成正比的，设备越多，就需要越多的人，当运维规模大到一定程度，人力运维是无以为继的，所以使用信息化监控系统成为一种必须的选择。

4.2 维护人员可以不断将经验赋能给运维监控系统。

换句话说，维护人员可以教会监控系统如何做事，每当一个新故障出现，维护人员在总结经验的同时，也可以把这些经验在运维监控系统里面具象化为一个个针对性的设置。比如说环路故障是广播风暴引起的，那么我就告诉运维系统去监控广播包水平，由此扩展到各种别的故障。这样每次新故障产生，维护人员都可以根据自己的处理经验对监控系统进行赋能，让监控系统不停的迭代更新，适应更多运维场景。

4.3 信息化监控系统可以将监控指标消息提炼为有用信息。

其实很多时候，监控系统获取到的各种监控指标，比如CPU使用率，接口流量，PING延时等，我们只能把它叫做带有信息的消息，而不能将其等同于故障本身，因为某个单独的监控指标，往往不能代表故障的全貌，故障有时候是多个指标同时发生异常，或者单个指标出现时间上的某种异常造成的，比如说连续的广播包水平高才代表广播风暴，偶尔的高只代表业务需要，又比如说所有二层交换机的CPU利用率都爆满才代表广播风暴，而只有一台二层交换机CPU利用率爆满可能只代表这台交换机本身硬件有故障。

4.4 总结

由此可见，通过信息化监控系统，对监控指标进行时间和空间上的综合计算处理，可以很好的提取出其中和故障相关的特征信息，可以让监控系统不仅仅只是一台噪音接收机，而是能从噪音之中听出弦外之音的智能机器。

综合上述3点，大概可以捋出一种对信息化监控系统处理故障的一般方法流程：

首先是数据采集，应该尽量全面的采集监控对象的运行指标参数，应该尽可能的利用各种手段与层面采集尽量多的指标参数。

然后是对于采集到的监控指标数据，运维人员应该利用自身对于这些数据的理解，去挖掘这些数据与故障处理的联系，去挖掘数据背后对于故障处理的意义，并将其具象化到监控系统的配置中，让监控系统能根据维护人员的经验和理解，从数据现象中抽出故障的本质，并将其赋能到监控系统中。

当监控系统能够抽出故障本质后，应该让监控系统能够用尽量直观的界面或快速的手段，展现或者说告知维护人员，以提高运维效率。

结束语：使用信息化监控系统对于故障处理的实践还有很多各种不同的实现，本文只是借助对于环路故障的处理，展开对信息化运维的思考。在未来，信息化运维监控系统必定成为运维系统最主要的组成部分，并承担越来越重要的角色，希望本文对大家对信息化运维的思路有一些借鉴作用，并打开各种新的思考方向。

参考资料：

1、https://www.h3c.com/cn/d_202202/1545560_30005_0.htm H3C官网文档中心H3C S12500-XS系列交换机 MIB（Management Information Base）参考-R762X-6W1000，5-接口管理章节关于管理信息库MIB：ifHCInBroadcastPkts (1.3.6.1.2.1.31.1.1.1.9)的描述。

2、https://www.zabbix.com/documentation/6.0/zh/manual ZABBIX官网文档中心 ZABBIX 6.0中文使用手册关于配置监控项、预处理功能和触发器表达式的相关描述。