技术支持 > 技术文章 > 层层深入探究“网络丢包”
 
网络瘫痪事件的诊断与恢复

故障地点:上海某某百货局域网
  故障现象:严重通讯障碍,客户机之间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分左右,在老楼发现故障源也已经消失。由于时间因素,进一步的定位工作没有继续,但是由于已经把问题缩小到老楼局部以及能够定位了故障类型本身,对之后的维护保障工作应当有比较好的帮助。
  结论
  在诊断该故障同时,还发现有一些网络扫描的现象,网内还伴随一些病毒和蠕虫的征兆,因此网络维护任重道远,仍然需要更多的努力和投入。
 

 
苏ICP备09091153号 Copyright ® 2009 Design By Topsi.net.cn 隐私保护 | 联系我们 | 技术支持 | 众衡论坛