网络瘫痪事件的诊断与恢复

故障地点：

故障现象：严重通讯障碍，客户机之间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是在大量简单重复。换言之，这些大量的广播报文，通常不应当是某台主机主动引起，而是被交换机发复转发造成。