【51CTO.com独家特稿】局域网运行时间一长，出现网络故障的机率就越大，这其中有网络设备运行性能下降的原因，也有网络病毒袭击的原因，但更多的故障却是由用户的管理、维护操作不当引起的；这不，笔者曾经遭遇一则由于网络线缆连接不当，引发局域网广播风暴现象，造成网络访问频繁出错故障，现在就将该故障的排除过程还原出来，与大家一起分享、交流！
网络访问频繁出错
这几天，笔者办公室电话不停响起，上网用户一会儿反映说他们上网的速度象蜗牛一样，一会儿反映说网络连接时通时断，更为严重的是有时整个虚拟工作子网都不能上网；对上报的故障点进行大概分析，笔者发现这些故障点很分散，分布在多个不同的楼层和不同的虚拟工作子网中。对故障工作子网中的交换机进行设备替换测试后，网络访问仍然还是频繁出错；任意选择一台故障客户端系统进行连通性测试，笔者看到对应虚拟工作子网中的网关设备地址能够Ping通，在相同的工作子网中进行共享访问时也能正常，对局域网中的核心交换机IP地址进行连通性测试时，往往会发生延迟时间长、数据丢包严重，甚至无法ping通的现象。通过交换机自带的网络管理工具对相关交换机设备进行检查、测试时，也没有找到明显的报错。
网络访问环境说明
笔者所在单位局域网组网规模较大，整个大楼采用星型拓扑网络结构进行组网，网络中的核心汇聚交换机为H3C S8500路由交换机，该交换机放在信息中心机房，接入交换机统一为3组堆叠的H3C S3050楼层交换机，这些交换机分别位于各个楼层的弱电配电间，每个弱电配电间几乎都安装有48口交换机两到四台，大楼中的各个部门客户端系统利用级连方式或者直接接入方式，并通过各自楼层交换机接入大楼局域网网络。
信息中心机房中的服务器有若干台，能够同时对客户端系统提供FTP服务、Web服务以及文件服务等。为了控制网络运行安全，以及方便管理、维护，整个大楼网络分为20个VLAN，同时依照部门不同分别为不同工作子网定义了IP地址，所有网关都建在H3C S8500路由交换机上；为了保证数据传输、交换速度，客户端设备到楼层交换机统一采用超五类双绞线线缆，楼层交换机到核心交换机统一采用千兆多模光纤线缆。
逐一排查故障因素
由于网络故障点比较分散，局域网中的很多客户端系统同时出现上网时断时续、网络传输延迟现象，为此笔者估计大楼局域网的核心交换机工作状态不正常，于是尝试着重新启动核心交换机系统，待重启成功后，笔者发现故障现象明显有了好转，可是没有多长时间，又出现了相同的故障现象，看来问题非常严重。
任意选择一台客户端系统，打开该系统的运行对话框，在其中执行ping命令，来测试对应虚拟工作子网的网关地址，结果发现数据丢包现象比较严重，达到了85%左右，同时延迟时间大约在500ms，这显然是不正常的；再从核心交换机后台系统ping外网网关地址，发现数据丢报率低于2%，同时延迟时间也不是很大，这说明问题可能出在客户端系统到核心交换机之间。
登录进入核心交换机后台系统，使用“display dia”命令，查看各个光纤交换端口的状态信息，笔者发现一些交换端口的输入、输出数据流量明显不正常，进入异常流量端口视图模式状态，执行字符串命令“display interface g1/2/1”，查看该端口的具体状态信息时，笔者看到该端口此时处于“down”状态，这也难怪连接到该光口下面的虚拟工作子网都不能正常访问网络了，进一步查看该端口其他配置信息时，笔者发现广播数据包的大小也不正常；难道是目标交换端口下面的虚拟工作子网中存在网络病毒？
为了避免网络病毒继续威胁整个大楼网络的稳定运行，笔者在核心交换机后台系统，使用字符串命令“interface g1/2/1”进入指定光口视图模式状态，并在该模式状态下执行字符串命令“shutdown”，关闭该光口的运行状态，那么连接到该光口下的虚拟工作子网中的网络病毒就不会影响核心交换机的工作状态了；原以为上述处理操作，能够解决网络访问频繁出错故障，可是再次重新启动核心交换机后台系统后，笔者发现相同的故障现象仍然存在，这就意味着上述网络故障与网络病毒没有关系。
在排除网络病毒因素后，笔者开始怀疑连接到g1/2/1光纤端口下的楼层交换机到核心交换机之间的线路连通性存在问题，于是使用专门的光功率计来测试光纤线缆的信号收发情况，发现测试结果一切正常，这说明问题与光纤线路连通性没有关系。由于笔者无法远程登录故障楼层交换机，只好赶到该交换机现场，通过Console控制端口登录进入故障交换机后台系统，依次执行“system”、“display cpu”命令，发现该设备后台系统的CPU资源消耗率几乎达到100%，很明显该楼层交换机下面的虚拟工作子网中存在大量广播风暴，于是断开该楼层交换机与核心交换机的网络连接。
继续在核心交换机后台系统进行测试，发现它的CPU消耗率仍然很高，于是笔者怀疑核心交换机下面仍然有异常流量端口，经过仔细查询，终于找到g1/2/9光纤端口流量也不正常，于是再次进入g1/2/9光纤端口视图配置模式，执行“shutdown”命令，将g1/2/9光纤端口的运行状态关闭，此时笔者发现核心交换机的CPU消耗率终于达到了正常的25%左右，与此同时，局域网中的其他故障点立即也能恢复正常的上网状态了。
分析故障产生原因
顺着g1/2/1光纤端口、g1/2/9光纤端口的连接线路，笔者找到了两台数据流量异常的楼层交换机，通过Console控制端口登录进入故障交换机后台系统，同时使用ping命令依次测试每一个以太电口的连通状态，结果发现“e0/12”、“e0/21”这两个以太电口无法被正常ping通。于是使用“display interface e0/12”、“display interface e0/21”命令，分别查看这两个端口的数据流量状态信息时，发现它们的广播包数据流量都比较多。经过更进一步的排查，笔者发现“e0/12”、“e0/21”这两个以太电口下面分别连接了一个集线器，更为巧合的是，这两个集线器全部集中放置在同一个办公室中；
经过了解，笔者发现这家单位的客户端系统平时需要通过不同的集线器，分别连接到两个不同的虚拟工作子网中进行工作，最近这个办公室由于安装窗帘，网络连接线路全部被临时拔了下来，窗帘安装好后，由于工作人员不懂线路连接，随手将备用的网络线缆将两个分别独立的两个集线器也连在了一起，这么一来这两个集线器、两个楼层交换机以及核心交换机之间，无形之中就形成了网络环路，最终造成整个局域网频繁出现网络访问错误。
找到故障原因后，笔者断开了两台集线器之间的网络连接线路，同时在核心交换机后台系统执行“undo shutdown”命令，将g1/2/1光纤端口、g1/2/9光纤端口的运行启用状态恢复正常，这时整个局域网仍然能够正常、稳定工作，至此网络访问频繁出错的故障现象就被彻底地解决了。
故障排查经验总结
平时我们在排查局域网故障现象时，往往先是观察相关网络设备的信号灯状态是否正常，一旦看到不正常的话，最常见的解决办法就是简单地重新启动一下网络设备后台系统，不管是交换机设备还是路由器设备，统统重新启动，并且很多时候都会屡试不爽，可是这次这种办法没有能够顺利地解决问题。经过仔细排查，结果发现问题竟然是由于上网用户随意连接网络线路造成的；
很明显，为了杜绝相同故障现象的再次发生，网络管理员应该加强对局域网的管理力度，禁止上网用户随意下挂交换机或集线器，如果确实由于工作需要必须连接交换机的，应该及时向网络管理部门备案。该故障的排查过程，也给了我们一个很好的启示，在遇到网络故障时，应该首先了解故障发生之前的网络变化情况，同时及时建立完善的网络文件资料。
【51CTO.COM 独家特稿，转载请注明出处及作者！】
