巧妙排查 揪出堵塞网络通信的祸首

运维 网络运维
上网速度缓慢、数据严重丢包故障现象十分常见,造成该故障的原因也是十分繁多,这种类型的网络故障排查解决起来自然也比较麻烦;为了帮助大家多积累这方面的排查经验,本文现在就从实战角度出发,来向大家贡献一则由网络线缆连接不当引发的网络通道堵塞故障的排查过程,希望这些内容能让大家得到启发!

上网速度缓慢、数据严重丢包故障现象十分常见,造成该故障的原因也是十分繁多,这种类型的网络故障排查解决起来自然也比较麻烦;为了帮助大家多积累这方面的排查经验,本文现在就从实战角度出发,来向大家贡献一则由网络线缆连接不当引发的网络通道堵塞故障的排查过程,希望这些内容能让大家得到启发!

故障现象
  
笔者所在单位的局域网是由一个中心机房的工作子网和各个楼层的工作子网组成,中心机房的工作子网中有包括Web服务器在内的各个应用系统服务器以及核心路由交换机,各个楼层的工作子网全部通过千兆光纤线路与中心机房的核心交换机保持连接,局域网中的所有终端电脑全部通过超5类双绞线实现与各个楼层交换机的百兆网络互联。为了抑制广播风暴现象以及网络病毒的疯狂传播,网络管理员采用VLAN技术将整个局域网划分成了不同的虚拟工作子网,所有虚拟工作子网全部通过中心机房的核心路由交换机实现不同虚拟工作子网之间的路由。

平时,整个局域网中的所有终端电脑都能正常上网,并且上网速度也非常理想。可是,最近这几天,网络管理员不断接到来自五楼不同用户的电话报修故障,声称它们的终端电脑上网访问速度突然变慢,从网上下载信息时一点也没有以往一气呵成的感觉了,现在的下载速度就象蜗牛一样爬行,经常要访问的站点也打不开了,电子邮件也不能正常收发了。接到故障求援之后,网络管理员立即从自己的终端电脑出发,使用ping命令测试五楼楼层接入交换机的IP地址,结果发现这项测试操作延迟现象十分严重,而且数据丢包率达到了惊人的16%左右,这在一个规模不大的局域网网络中来说是不应该的。既然故障现象发生了,网络管理员立即采取措施,进行了以下排查操作。

故障排查

考虑到最近一段时间,整个局域网网络曾经发生过网络病毒疯狂肆虐的现象,为此网络管理员首先将故障排查对象锁定在网络病毒身上;因为一旦局域网中真的存在许多网络病毒,并且这些病毒同时爆发的话,那么对应网络中的有限出口带宽资源可能会被大量占用,那么终端电脑上网速度自然会受到明显影响。为了判断网络病毒是否是上述故障现象的祸首,网络管理员立即赶到五楼楼层交换机现场,将自己随身携带的笔记本电脑通过Console控制线缆连接到该楼层交换机上,然后在笔记本电脑中运行Sniff程序进行数据抓包分析;结果网络管理员发现,这个楼层的虚拟工作子网内当前上线的终端电脑数量只有二三十台,而对应工作子网内的数据包流量也不是很大;在这种情形下,网络管理员尝试通过该楼层的交换机进行上网访问时,发现网页内容仍然无法访问,电子邮件收发也无法进行,看来造成这种故障现象的因素不是网络病毒。

在排除网络病毒因素后,网络管理员又对这个楼层的交换机设备进行了仔细观察,发现连接到该交换机的终端电脑数量比较多,而且对应交换机的型号属于低端产品,它的自身运行性能也是一般。正常情况下,这种低端的楼层交换机持续运行的时间比较长的话,很有可能出现系统缓存溢出错误等,或者交换机内部的性能元件发生老化现象,这些现象都会影响交换机的运行稳定性。对于这样的“软”故障现象,往往都能通过重新启动的方法来解决,依照这样的思路,网络管理员立即重新启动了一下五楼楼层交换机系统,没有多长时间,该交换机就启动稳定了。原以为这次努力能够解决问题,可是当网络管理员再次从自己的笔记本电脑中访问目标站点页面中的内容时,发现网络访问速度仍然非常缓慢,显然网络通道仍然处于堵塞状态。

既然故障现象与网络病毒以及楼层交换机自身运行状态没有关系,那么究竟是什么因素造成了这种故障现象呢?经过仔细思索,网络管理员突然联想到了网络环路因素,因为局域网中一旦存在网络环路现象的话,同样能够产生广播风暴现象,从而可能会堵塞网络传输通道,那么局域网中究竟存在不存在网络环路现象呢?正常情况下,如果五楼工作子网中存在网络环路现象的话,那么对应楼层的交换机上的所有信号灯状态都应该处于不停闪烁状态。基于这样的分析,网络管理员立即对楼层交换机控制面板上的信号灯状态进行了观察,结果发现这些交换端口信号灯果然存在闪烁过于频繁的嫌疑;于是,网络管理员立即断开楼层交换机与对应楼层的光纤收发器之间的连接线路,通过普通的网络线缆将自己的笔记本电脑连接到对应楼层的光纤收发器网络端口上,满以为这次可能能够解决问题,可是网络管理员再次在笔记本电脑中访问目标站点页面时,网页内容竟然还是无法打开,之前出现的故障现象仍然存在,很明显这样的故障现象与楼层交换机没有任何关系!

在确认上面的故障现象与楼层交换机没有任何关系之后,网络管理员又将故障排查的范围缩小到光纤连接跳线、光收发器、中心机房的核心交换机上了,因为只有这些位置的设备或线缆没有检查了。由于除了五楼之外的其他楼层交换机同样也是连接到中心机房的核心交换机上的,仔细观察其他楼层用户的上网状态时,发现它们都是正常的,所以从这一点来看,网络管理员估计中心机房的核心交换机自身工作状态是正常的。那有没有可能是连接五楼楼层交换机的核心交换机端口存在问题,导致五楼用户不能正常通过核心交换机访问网络呢?联想到这一点,网络管理员立即以系统管理员权限登录进入核心交换机后台,进入连接五楼的交换端口视图配置界面,使用“display interface”命令查看该交换端口的状态信息时,没有发现有什么异常现象,同时该交换端口的工作状态也处于“up”状态。后来,网络管理员担心连接五楼交换机的光纤收发器以及光纤跳线接头存在问题,于是又不厌其烦地采用手工方法对光纤连接跳线线头进行了卫生清洁工作,同时又替换了光纤收发器设备,可即使这样努力,故障排查工作还是一点没有进展。

故障解决

在万般无奈之下,网络管理员只好赶到中心机房,来到核心交换机现场,仔细观察核心交换机的物理连接时,终于弄清楚了故障产生的根源。我们知道,普通的光纤收发器设备通常只有一对光口以及一个普通的以太网端口,其中光口是专门用来连接光纤跳线的,以太网端口可以连接终端电脑进行网络访问测试;可是,中心机房使用的光纤收发器设备却与众不同,它同时拥有两个普通的以太网端口,它的作用与一只包含两个交换端口的微型交换机相当。正常情况下,我们只会同时用到一个以太网端口和连接光纤跳线的光口,另外一个以太网端口平时不怎么用到;可是网络管理员在这里却看到,连接核心路由交换机的光纤收发器,同时使用了两个普通的以太网端口,分别沿着这两个以太网端口的连接线缆进行查询时,网络管理员发现它们竟然同时连接到核心交换机设备上了,只是它们连接到核心交换机不同的Vlan接口上罢了。由于各个楼层的Vlan全部设置在核心路由交换机上,各个楼层Vlan相互之间的访问路由也配置在该设备上,当连接五楼的光纤收发器上的两个普通以太网端口同时连接到核心路由交换机上时,对应光纤收发器与核心路由交换机之间无形之中就形成了网络环路现象,结果造成对应光纤收发器的连接端口被大量的数据包堵塞,从而影响了五楼用户的上网访问速度。

找到了故障产生的“罪槐祸首”后,网络管理员立即从连接五楼的光纤收发器上拔下了多余的网络连接线缆,再次使用笔记本电脑从五楼网段进行目标网站的访问时,发现网络访问速度已经恢复到正常状态,同时发现收发电子邮件等操作也恢复了正常,这说明五楼的网络故障现象已经彻底消失了。

原因探究

上面的故障现象虽然已经被成功解决了,但是让网络管理员感到疑惑不解的是,为什么光纤收发器上的两个普通以太网接口会同时连接有网络线缆?网络管理员经过仔细观察看到。在中心机房的接线柜内同时安装了来自其他楼层的十几个光纤收发器设备,其中某个光纤收发器设备由于发生了硬件质量问题被暂时从接线柜内移走了,不过对应设备的电源连接线缆以及网络连接线缆仍然还放置在接线柜内;网络管理员询问中心机房的其他工作人员时得知,前几天另外一个工作人员在对大楼网络设备正常巡检时,看来保留下来的网络线缆时,以为是该网络线缆由于接触不牢靠从设备上滑落下来了,于是下意识地将它连接到来自五楼的光纤收发器设备上了,这样一则奇怪的网络故障现象就在不经意间发生了。

从这则故障的产生过程来看,笔者认为平时遭遇到的许多网络故障现象,都是由于网络管理员自己在工作过程中粗心大意引起的。所以,为了保证局域网网络能够始终稳定地运行,我们除了在安装、组建的时候,要严格遵守网络布线标准外,还需要在平时加强对网络工作环境的维护,千万不能图一时的操作便利而轻易留下故障隐患。  

责任编辑:许凤丽 来源: IT专家网
相关推荐

2009-02-27 09:44:00

2020-11-12 08:52:16

Python

2009-08-24 17:20:13

C#网络通信TCP连接

2019-04-29 10:26:49

TCP网络协议网络通信

2010-06-14 19:13:28

网络通信协议

2010-06-09 11:57:42

网络通信协议

2014-09-16 17:00:02

UDP

2021-08-13 11:27:25

网络通信数据

2020-07-06 07:52:10

Kubernetes网络通信

2010-07-01 15:45:22

网络通信协议

2017-01-15 17:44:56

node网络通信Socket

2024-02-20 19:53:57

网络通信协议

2022-12-05 09:25:17

Kubernetes网络模型网络通信

2010-09-12 23:07:53

2010-06-09 11:31:55

网络通信协议

2016-08-25 11:17:16

CaaS华为

2022-05-13 10:59:14

容器网络通信

2009-10-16 08:48:08

2010-04-22 16:10:48

Aix操作系统网络通信

2021-08-30 13:08:56

Kafka网络通信
点赞
收藏

51CTO技术栈公众号