故障地点：上海某某百货局域网
故障现象：严重通讯障碍，客户机之间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是在大量简单重复。换言之，这些大量的广播报文，通常不应当是某台主机主动引起，而是被交换机发复转发造成。
通常交换网络中会打开Spanning Tree协议以保障不发生交换机环路的现象，假如不使用Spanning Tree PRotocol (以下简称STP)，当两台交换机发生同时被两条线缆互联时候，会形成环路，交换机无法自我侦测这一情况，其结果是把广播报反复转发。
假如启用STP，各个交换机会发送优先度很高的BPDU数据封包，进行线路检测，当发现发送的BPDU包被不恰当的转发回来时候，交换机可以相互协商，关闭某一条环路路径。保障任意两个交换机中只有一条耦合链路。
问题确认得到以后，我们试图解决。
采用二分法，临时断开东楼和西楼的光纤链路。断开后发现故障立即消除，所有超时现象不再出现，流量平复正常。 以此可以判定，环路发生在西楼和东楼之间，或在老楼内部。
恢复光纤链路之后，我们前往老楼进一步查访故障源。由于老楼交换机放置地点条件较差，经过整理和分析，到18:45分左右，在老楼发现故障源也已经消失。由于时间因素，进一步的定位工作没有继续，但是由于已经把问题缩小到老楼局部以及能够定位了故障类型本身，对之后的维护保障工作应当有比较好的帮助。
结论
<< 涉及客户信息，被省略 >>
在诊断该故障同时，还发现有一些网络扫描的现象，网内还伴随一些病毒和蠕虫的征兆，因此网络维护任重道远，仍然需要更多的努力和投入。
