首页 | 互联网 | IT动态 | IT培训 | Cisco | Windows | Linux | Java | .Net | Oracle | 软件测试 | C/C++ | 嵌入式开发 | 存储世界 | 服务器
网络设备 | IDC | 安全 | 求职招聘 | 数字网校 | 网页设计 | 平面设计 | 技术专题 | 电子书下载 | 教学视频 | 源码下载 | 搜索 | 博客 | 论坛
欢迎光临中国IT实验室思科频道
Google
您现在的位置: 中国IT实验室 >> Cisco >> 网络管理 >> 故障排除 >> 正文

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

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

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

[1] [2] 下一页

【责编:Kittoy】
中国IT教育
相关产品和培训
文章评论
 友情推荐精华
 专题推荐

 ·节省成本才是“王道” VOIP案例应用…
 ·巧用网络流量 打造健康内网…
 ·无线路由器设置从入门到精通
 ·企业网管如何部署你的网络监控系统?
 ·负载均衡技术方案攻略
 ·中国IT实验室2007年技术热点盘点
 ·利用路由实现VPN的配置方法
 ·让你的局域网网速更上一层楼
 ·小命令大作用---Ping
 ·OSPF路由协议专题
 今日更新
 认证培训
 频道精选
 思科频道导航