许多时候，我们可能都会碰到网络连接时断时续的故障现象，面对这种网络故障，不少网络管理员都会使用Ping命令对网络连通性进行测试，测试结果表明此时的网络传输线路数据丢包现象非常严重，那么究竟是什么因素导致了数据丢包现象比较严重呢?是连接线路接触不稳定?是网络病毒?还是其他的潜在因素?

　　仔细对这类现象进行总结后，我们发现最容易造成数据丢包现象的因素就是网络环路，毕竟在规模稍微大一点的局域网环境中，网络管理员很容易把交换机之间的端口连接错误，从而引起网络环路现象，并且这种现象由于有比较强的隐蔽性，我们在排除这类故障的时候要是不留神的话很容易多走弯路!为了帮助各位高效解决数据丢包严重这类网络故障，笔者现在就将自己曾经遭遇到的一则网络环路故障排除过程贡献出来，希望大家能从中获取收益!

　　 故障现象

　　笔者所在单位的局域网网络使用的拓扑结构是星型百兆以太网结构，局域网主机房中使用了一台Cisco品牌的三层路由交换机作为网络的核心交换机，单位五层大楼中的每个楼层都组建了子网段，每个网段中的所有工作站都使用D-Link品牌的普通交换机作为集线设备，并且各个楼层中的普通交换机通过双绞线缆直接接入主机房中的核心交换机，并通过核心交换机直接访问Internet网络。单位局域网中同时安装、配置了多台服务器，例如有保存单位重要数据信息的文件服务器，有对外提供Web访问服务的Web服务器，有提供重要资料下载的FTP服务器等。

　　平时单位各个子网段中的所有工作站都能正常访问Internet网络，每个子网段中的工作站之间也能互相访问。可是有一天，某一子网段中的用户通过手机向笔者反映情况说，他们所在的子网工作站访问Internet网络时，有时正常有时不正常，并且同一子网段中的工作站之间相互进行Ping测试时，发现数据丢包现象非常严重;原以为这种故障仅是极个别现象，可谁曾想到，没有多长时间，分布在多个网段中的许多用户接二连三地向笔者反映情况，并且描述的故障现象基本相同。

　　连续的故障求援让笔者再也坐不住了，笔者立即动身来到其中一个楼层，对该网段中的工作站进行上网测试，在上网过程中笔者发现网页打开速度有时非常缓慢，几分钟也打不开一个页面，有时速度很快，只要输入地址敲下回车键后，网页内容立即就显示出来了，并且这种现象反反复复。在确认网络故障的确存在后，笔者认为这种故障现象涉及多个网段，引起这种故障现象的原因很可能是交换机的连接端口出现了问题，于是笔者对交换机的连接端口进行了适当调整，并在调整之后及时进行了测试，可是局域网中的故障现象依然存在。

　　重新返回到故障工作站现场进行测试，笔者看到使用Ping命令可以Ping通局域网中的部分工作站和服务器，不过在Ping主机房中的核心交换机IP地址时，笔者发现存在明显的数据丢包现象，并且网络延迟时间也比较长。通过专业的网络管理工具对主机房中的核心交换机进行参数配置检查，笔者也没有发现明显的错误。

　　故障分析

　　虽然核心交换机的参数配置方面没有找到可疑的地方，但是笔者还是深信问题出在核心交换机身上，毕竟多个子网同时出现相同的故障现象决不是偶然的。在排除了核心交换机参数配置因素后，笔者开始将怀疑重点转移到该设备的物理因素上了;首先，笔者仔细观察了核心交换机控制面板中各个信号灯的工作状态，发现连接有双绞线的所有端口对应的信号灯状态都很正常。其次，笔者担心网络线缆没有紧密地插入到核心交换机的各个端口中，于是不厌其烦地将所有的网络线缆逐一拔下来，之后又将其重新插入到对应的交换机端口中，可是笔者的这番辛苦并没有得到任何回报，局域网中的数据丢包现象仍然十分严重，并且许多工作站还是不能正常访问Internet网络中的内容。

　　那会不会是核心交换机的缓存遇到错误，导致连接到该交换机设备中的所有子网工作站都不能正常访问网络内容呢?笔者脑海中总有这样一种意识，认为交换机运行时间一长之后，其系统缓存十分容易出现溢出或其他软件错误，这类错误常常会导致局域网网络产生莫名其妙的故障现象;依照这样的想法，笔者尝试着切断了核心交换机的电源，过了一段时间后，又重新接通该设备的电源，以便让其重新启动，等待核心交换机系统启动稳定之后，笔者再次尝试了在故障工作站中进行上网测试，结果发现网络访问还是时断时续。

　　在排除了上面几种因素后，笔者估计这种网络故障应该不在交换机硬件部分，很可能是局域网中的网络病毒造成的。于是，笔者特意从网络中下载了专业分析工具Sniffer，通过该工具抓包分析网络中的信息包，发现有许多信息包都不约而同来自相同的一个网卡设备的MAC地址，而信息包中发送的目的地址在局域网中根本找不到，于是笔者立即下意识地怀疑可能是“熊猫烧香”之类蠕虫病毒造成了网络传输通道堵塞。难道目标网卡MAC地址对应的工作站真的被感染上了网络蠕虫病毒?

　　想到这一点，笔者立即通过网络正常传输时创建的MAC地址与IP地址对应表，查找到该工作站来自局域网二楼网段中的一台工作站，初步确认故障原因后，笔者立即将目标网卡MAC地址对应的工作站从特定网段中断开连接，同时在该工作站系统中安装了最新版本的杀毒软件，并对该工作站系统进行了全面、彻底地病毒查杀操作，等到病毒查杀任务结束后，笔者还真的看到了一些网络蠕虫病毒，原以为这些网络蠕虫病毒就是最终的“祸首”，可是当将该工作站重新接入到对应网段中后，局域网的数据丢包故障现象还是没有消失。

　　在万般无奈之际，笔者决定对各个子网进行单独测试检查。于是笔者特意找来当初组建局域网时使用的网络拓扑结构图，对照图纸笔者想依次找出不同网段接入到核心交换机时所使用的端口，在进行这方面查找操作时，笔者偶然看到有一条网络线缆竟然同时插入到核心交换机中的两个端口中，很明显这条网络线缆使局域网中形成了环路现象，而环路现象可能就是整个局域网数据丢包严重的“罪槐祸首”。

　　为了验证笔者的分析是否正确，笔者尝试着将造成环路的那条线缆拔出后，立即从故障工作站中再次访问了Internet网络，结果发现故障工作站打开网页的速度很快;但笔者还是有点不放心，又跑到另外一个故障子网中，随意找了一台工作站进行上网测试，测试结果证明局域网的所有故障全部已经消失，这表明局域网的数据丢包故障已经被成功解决了。

　　故障探究

　　通过上面的分析，我们不难发现网络环路其实就是引起局域网所有子网不能正常访问的“祸首”，在局域网环境中一旦有网络环路现象存在时，那么工作站对外发送的每一帧信息都会在网络通道中反复广播，从而造成了广播风暴现象，最终导致局域网传输通道严重被堵塞，那样一来局域网网络就容易出现数据丢包现象。

　　在解决这类网络故障时，笔者由于没有及时了解到局域网网络中发生了一些变动，导致在排除故障的过程中，始终没有想到网络环路竟是由于我们网络管理员的疏忽引起的，从而导致了笔者在解决故障的过程中多走了不少弯路。

　　仔细想来，要是在排除故障之前，笔者能够事先询问一下单位的其他网络管理员，打听一下最近网络是否进行了改动的话，说不定就能很快找到故障原因了。所以，日后我们在解决类似网络故障时，首先应该仔细了解一下故障之前网络的变动情况，之后再按照常规思路进行排查。

　　当然，为了便于管理网络，我们在组建局域网网络时，也应该及时建立了比较完善的局域网组建档案资料，具体内容可以包括IP及MAC对应表、网络布线图、网络变动说明等，有了这些资料帮忙，任何网络管理员都能在很短时间内解决各种网络故障了。

本文转自q狼的诱惑 51CTO博客，原文链接：http://blog.51cto.com/liangrui/338794，如需转载请自行联系原作者