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

　　故障现象：严重通讯障碍，客户机之间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分左右，在老楼发现故障源也已经消失。由于时间因素，进一步的定位工作没有继续，但是由于已经把问题缩小到老楼局部以及能够定位了故障类型本身，对之后的维护保障工作应当有比较好的帮助。

　　结论

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