用事实讲解网络瘫痪事件的诊断与恢复


故障地点：上海某某百货局域网

故障现象：严重通讯障碍，客户机之间ping包掉包严重，甚至POS机也不能正常通讯，用户很难完成付款操作。

详细描述：整个网络间断性出现网络通讯中断，造成经常性的客户机应用延迟和上网缓慢。在主机房中进行ping包测试时发现，主机房客户机对主交换机的管理地址的ping包也会发生间隙性掉包。主机房客户机对各个楼面交换机通讯的通讯中断情况更加严重。

初步经验性问题判断为：

1）ARP表更新问题；

2）广播故障；

3）路由表更新故障；

4）病毒攻击及其他安全状况。

需要获取的进一步信息是：

1） ARP表信息；

2） 交换机负载；

3） 通讯数据捕获。

进行了简单的ARP测试，发现更新ARP正常； 由于交换机反应缓慢，操作超时，无法准确获得当前负载数据。

选择主交换上一网络端口接入测试用笔记本，启动协议分析工具。

接入端口没有做镜像，接入后发现每秒钟接收到数据报文数量平均8000个，最高达到每秒14000个。按此推算，每台交换机背板每秒可能交换336000多个封包，这可能是造成交换机处理器被严重占用，造成间歇性丢包的直接原因。

由于交换机端口没有做镜像，可以认为当前的接收到的数据主要为广播通讯。利用协议分析工具捕获解码后，可以得到以下结果。

主要的协议通讯都是广播通讯。包括ARP 广播、SMB广播和Name SVC广播。

几乎所有的封包大小都小于255字节。所以尽管封包数量很大，但是总体字节数不多，吞吐量较小，在一些只记录流量的软件系统中，不能准确发现这个问题的危害。

从解码角度察看，可以看到一段时间内，主要为某一台主机的疯狂通讯。往往一台主机的通讯在瞬间占据当时总体通讯的50%以上。

到此，问题原因曾经被导向到个别流量特别大的主机，怀疑其由于病毒/蠕虫的侵害而造成大流量的产生。但是在进一步分析的过程中，我们注意到了这些在通讯中有一个特点，例如在NetBIOS 的Name SVC广播为UDP协议，UDP为IP之上封装的通讯，在IP包头包含了IP Identification信息缩写IPID），一般每台主机在主动发送一个数据包时，会对IPID这个值进行递增。例如第一个包IPID为 10000，第二个发送包就可能是10001，第三是10002，依次类推，不同的主动发送的报文的IPID应当是不同的。但是在解码中可以发现在一段时间内，IPID是在大量简单重复。换言之，这些大量的广播报文，通常不应当是某台主机主动引起，而是被交换机发复转发造成。

在此情况下，为了正式这一现象，我们作了一次试验，让某台主机以每三秒一次的频率发送请求到一个不存在的地址为了引起ARP广播），但是每三秒一次的广播，在网络中捕获的结果是在一秒钟内形成了7991次反复转发，造成了大量的网络流量。经过这些过程，我们确认这一问题是由于交换机环路造成。

通常交换网络中会打开Spanning Tree协议以保障不发生交换机环路的现象，如果不使用Spanning Tree Protocol 以下简称STP），当两台交换机发生同时被两条线缆互联时候，会形成环路，交换机无法自我侦测这一情况，其结果是把广播报反复转发。

如果启用STP，各个交换机会发送优先度很高的BPDU数据封包，进行线路检测，当发现发送的BPDU包被不恰当的转发回来时候，交换机可以相互协商，关闭某一条环路路径。保障任意两个交换机中只有一条耦合链路。问题确认得到以后，我们试图解决。

采用二分法，临时断开东楼和西楼的光纤链路。断开后发现故障立即消除，所有超时现象不再出现，流量平复正常。 以此可以判断，环路发生在西楼和东楼之间，或在老楼内部。

恢复光纤链路之后，我们前往老楼进一步查访故障源。由于老楼交换机放置地点条件较差，经过整理和分析，到18：45分左右，在老楼发现故障源也已经消失。由于时间因素，进一步的定位工作没有继续，但是由于已经把问题缩小到老楼局部以及能够定位了故障类型本身，对之后的维护保障工作应当有比较好的帮助。

结论

在诊断该故障同时，还发现有一些网络扫描的现象，网内还伴随一些病毒和蠕虫的征兆，因此网络维护任重道远，仍然需要更多的努力和投入。

  1. 网络故障诊断和排除
  2. 如何利用TCP标记分析网络故障？
  3. 排除网络故障的一个总体模型

相关内容