编者按： 告警信息是IT 运维工作中所依赖的重要法宝，但在运维工作中也不要忘记故障之间的关联性。笔者单位近期出现断网，初期经分析告警信息发现存在MAC 地址漂移，但并未解决问题，之后才确定是环路问题所致。

笔者单位的办公网最近出现了一次大范围的故障，在解决故障的过程中，由于笔者水平有限，中间走了一些弯路。其中一些经验和教训，希望能给大家一点借鉴。

办公网的拓扑比较简单，主要是上互联网和使用办公软件，上网方式是拨号上网，如图1 所示。

故障第一天，有个别办公室反映拨号自动掉线，重新拨号后恢复正常，判断为个别现象，并未引起重视。第二天一早便有多人反映需要反复拨号或者直接拨号失败，无法上网，出现了大范围的问题。笔者随即按照如下顺序进行了故障排查。

故障排查及解决

1.之前出现过因个别无线路由器接反导致的网络丢包，首先在现场电脑上查看arp-a，未发现异常IP 和MAC 地址。

图1 单位网络拓扑图

2.询问运营商拨号系统是否正常。运营商答复系统正常，未发现明显异常。

3.终端机器Ping 竖 井交换机和网关丢包均在5%左右。

4.登录竖井交换机的Web 管理界面查看交换机CPU 占用率和内存占用率，未发现明显异常。

5.查看交换机告警。由于平时告警界面经常有一些“提示”类的告警信息，对网络运行没有什么影响。鉴于情况比较紧急，笔者直接将告警级别进行了排序，查看是否有重要告警。结果列出了许多“重要”级别告警，显示出现了MAC地址漂移，如图2 所示。

6.由于单位没有处理这种故障的经验，接下来笔者先查看了所有竖井接入交换机，均出现了MAC地址漂移的告警信息，并且每个交换机都出现了多个发生漂移的MAC 地址。笔者随即对相应的MAC 地址终端进行了现场查看和比较，没有发现存在相同MAC地址的终端或其他异常。笔者又将多个发生MAC 地址漂移的终端对应的交换机端口进行了shutdown 处理，问题仍未得到解决。

7.至此，故障处理陷入僵局。笔者经过思考后，重新在Web 界面查看交换机告警，按照时间顺序进行排序。这时才发现，在“提示”级别的告警中，存在环路告警：

图2 告警信息中出现MAC 地址漂移

#Apr 27 2020 14:39:22+08:00 2F-SW LBDT/4/PORTTRAP:OID 1.3.6.1.4.1.2011.5.25.174.3.3 Loop back exists on interface(53)GigabitEthernet0/0/49(none),loopback detec tion status:4,auto loop detection for trap only on VLAN 26.

8.查看所有竖井交换机，均出现环路告警。按照各个交换机的告警信息，除了竖井交换机C，其他均提示为上联口存在Loopback。而交换机C 则指向自己下联的扩展交换机C1，在C1 上Loopback 指向了房间R的端口。笔者立即shutdown 房间R 对应的端口，丢包随即停止了，各拨号上网用户恢复了正常，MAC 地址漂移告警也停止了。后经查看，房间R 因网线较多，自行接线时误将上网的交换机接成了环路。

结语

故障虽然消除了，但是通过这次经历，笔者总结下来一些经验和教训：

查看交换机告警不能只关注“重要”或“紧急”的告警，同样要关注“次要”或“提示”类的告警。

交换机告警是有关联的，严重程度高的告警能够表明相应的故障对业务的影响程度高，但是故障的解决却依赖于对告警根源的追溯。这次MAC 地址漂移的告警之所以重要，是因为MAC 地址一旦发生频繁漂移，势必导致二层网络的通信紊乱，但MAC地址漂移本身是“次生灾害”，是另外一个故障导致的结果了。而另外一个故障已经反映在“提示”告警中了。

除了网管人员加强网络知识的学习以外，为网络增加监测和自动报警的功能也是一个较好的切入点。

下一步单位准备部署能够实时监控网络设备，并能自动报警的服务器，力争做到提前发现，及时处理告警信息。