JZGKCHINA工控技术分享平台
故事之前先说下生产环境，环境由400+AP，50+交换机和300+终端和27个网络机房构成，而且分布的范围极广。当天正在跟同事做着日常的巡视，聊天打屁好不惬意，还在感叹这设备就是稳定。这时网管报警列表开始刷屏，AP、交换机和无线控制器报警信息轮番出现，当我和我同事还在懵逼的时候，主管的电话已经打到我手机上；焦急的语气叙述着现场的大部分终端已经不能正常工作，生产已经受到影响；要求我俩必须、立即、马上恢复，这时我俩才开始意识到事情不对劲了。PS:现场终端不能断电，必须一直运行。
事件处理过程
现场第一时间用ping测试网络的通断，在20个包的数据下成功了一次，且延时为600ms。
继续实验了其他的几个终端的IP，有些直接就显示成功率0%。陆续尝试用WEB登陆交换机,AP,终端，然而连登录页面都打不开，我俩就更加抓瞎了，穿着短袖在22℃的机房，直接给我俩急出一脑门子汗。
- 紧接着就是开始数据抓包。
Wireshark解包数据如图： 
从图中能够看出有及其多的IP地址冲突和免费ARP报文。（免费ARP图中较少，实际很多）
看到协议分级里ARP协议占据33.2%的份额，一度以为遭到了病毒或者网络攻击（ARP攻击），但内网根本没有网络出口。
这时我俩就更加不知所以，报文里大量出现了不同IP地址的冲突告警，看报文的时候觉得这个设备也有问题，那个设备也有问题，要不是终端不能断电，都想跑过去把它们全部都断了。
- 没办法只有先尝试着断交换机，看断开交换机后报文的情况会不会有好转，然而还是我想多了，并没有好转。
此时传来最新的人员安排，我俩在机房守着，其余的同事分散到各个交换机.
- 这时我想到要是可以进行一个数据的统计，也许就能看出来哪个终端发送的ARP协议最多，这个最多的终端也许就是最大的罪魁祸首。
Wireshark里的统计的确没有Microsoft office做的好。
从wireshark把报文导出为.csv文件进行筛选，得到如图：
可以看出ARP协议中MAC地址最后两位61和ae的设备发送的ARP协议最多，也许这两个就是罪魁祸首。
- 现在摆在我们面前的问题是如何确认这两个设备，我们手上并没有IP与MAC地址的对应表，手上只有IP与设备的对应表，平时要看一个设备的MAC地址，要么就是直接用WEB登录进去看，要么就是ping设备ip，再通过ARP命令来找到设备的MAC地址。
眼看着就陷在这里，就只能在群里问谁知道这两个MAC地址是哪个设备，本来以为没有谁知道，却在群里炸出来一个神人。这位大哥自己做了一个设备名称，IP，MAC地址的对照表，事后问他为啥要做这么一个表，说的纯粹就是看没人关心这个东西，就扒拉了AC控制器里的数据，自己存着了。
- 直接断开这两个设备，等了几分钟后网络就恢复了。
事故复盘
这个故障的原因就是设备大量发送ARP数据导致网络严重堵塞。
事后复盘发现是一个同事在维护一个故障的终端A时没有断开网络，上传终端A的配置文件后，终端A没有正常启动；然后使用网络搜索软件，在列表内选择第一个设备B再次上传了配置文件，然而第二次选择的设备B是一个AP设备，配置文件修改了AP的工作模式，由AP模式变为了Client模式，从而造成了设备B与周围的AP连接通信，形成环路，从而引发了网络风暴。
此次事件影响时间达3.5小时。
该事件暴露出问题：
1. 维护设备时由两人共同完成，操作人员的业务水平有待提高，在发现设备未正常启动后臆测行事，卡控人员没有尽到卡控的责任。
2. 故障处置人员业务水平不熟练。故障处置过程中无网络风暴故障处置经验，无冲突IP快速查找办法。
3. 网络通信系统台账不规范，主管人员未及时更新台账；DCS台账分散，存储位置各级人员不清楚，处置时核对台账较繁琐。
——没事瞎溜达
2021年10月
