实战应对三种因素引起的交换故障

运维 网络运维
局域网中的计算机往往都是连接到交换机设备上,可以这样说,交换机工作状态的好坏会对局域网网络的整体运行性能产生直接的影响。这样,如何应对交换故障就成了一个非常重要的问题。

一般来说,新投入使用的交换机设备工作性能往往比较稳定,很少会发生交换故障;可是,随着工作时间的延长,以及网络应用的不断变化,交换机出现故障的机率也在逐渐增大。

为了提高交换故障的解决效率,保证局域网网络能够始终高效运行,本文现在就从实战角度出发,来对常见的三种交换故障进行还原解读,希望大家能够从中得到一些启发!

1.应对缓存溢出故障

某单位局域网共有两台普通交换机,每台交换机都通过百兆双绞线连接到单位的CISCO路由器 href="http://product.it168.com/files/0409search.shtml" target=_blank>路由器设备上,并通过该设备访问Internet网络。平时每台交换机都连接有大约10台计算机,每台计算机都能通过交换机顺利地上网访问;最近不知道怎么回事,单位局域网中有的计算机可以正常上网,有的计算机却不能上网。

起初的时候,网络管理员还以为是计算机自身的因素,可是,在对计算机系统的上网设置以及网络病毒进行检查后,发现都没有问题,使用ping命令测试本地IP地址也是正常的,但是在ping局域网的网关地址时,发现不正常,看来故障计算机到交换机之间的这段线路存在问题。

会不会是物理线路的连通性存在问题呢?

想到这一点,网络管理员立即使用网络测试仪 href="http://product.it168.com/list/b/0447_1.shtml" target=_blank>测试仪,对连接计算机与交换机的双绞线连通性进行测试,结果发现它们的连通状态很正常。

在排除了网络线路以及计算机自身因素后,网络管理员准备检查一下交换机的工作状态是否正常;当他来到交换机设备现场时,他发现其中一台交换机的所有端口信号灯状态都处于点亮但不闪烁状态;按理来说,交换机如果能够正常处理数据信息的话,那么对应交换端口的数据信号灯也应该处于闪烁状态,很明显现在交换端口点亮但不闪烁,这说明了该交换机的工作状态不正常。而反观另外一台交换机设备,网络管理员发现它们的交换端口只要被点亮,基本上都能处于闪烁状态,这说明这台交换机能够正常交换数据。经过进一步检查,网络管理员看到那些不能上网的计算机,基本上都是连接到那台工作状态不正常的交换机上的,看来局域网中部分计算机不能上网的故障现象是由交换机引起的。

那么究竟是什么因素造成故障交换机的端口信号灯显示不正常呢?

一般来说,造成这种端口信号灯状态显示不正常现象的原因主要有两方面,一方面就是交换机系统存在问题,例如受到网络病毒的攻击,或者工作时间长了之后出现了系统缓存溢出错误等,另外一方面就是交换机设备存在硬件问题,例如交换机服役时间比较长之后,它内部的性能元件容易发生老化现象,这些老化的元件也容易造成交换机工作状态不正常。

通常,交换机的设置不发生变化,出现的一些“软”故障往往都能通过重新启动的方法来解决,依照这样的思路,网络管理员立即重新启动了一下故障交换机系统,没有多长时间,网络管理员观察到该故障的交换机端口工作状态已经恢复了正常;再次从故障计算机系统中尝试进行上网访问时,以前不能上网的故障现象立即消失了,这说明故障交换机的确存在类似缓存溢出这样的“软”故障,这样的故障造成了交换机的工作状态无法正常。

如果每重新启动一段时间后,交换机又出现相同的故障现象时,那问题很可能是由局域网中的网络病毒引起的,因为有的网络病毒可能在一定时间内,会对交换机系统的内存或其他系统资源进行不停占用,最终导致交换机系统的资源全部被消耗殆尽,从而会引发局域网中的计算机不能上网的故障现象;为了避免网络病毒对交换机系统的冲击,我们应该在组建网络之前,认真选用质量可靠、性能稳定、缓存较大的设备,同时注意对局域网网络定期执行病毒清除操作。 #p#

2.应对ARP病毒故障

某一天,笔者接到一个故障申请电话,说618房间的计算机突然不能上网,并且系统托盘区域处的网络连接图标上有红色叉号标记出现;起初笔者以为肯定是网络线缆出现了松动,要求该用户自行将网线拔下来重新插一下,确保网络线缆与墙上的上网插口以及网卡接口之间连接牢靠,可是该用户按照笔者要求重新插拔了网络线缆后,还是出现相同的故障现象。

笔者不放心,立即登录到618房间所使用的交换机系统上,查看了对应交换端口的工作状态,发现目标端口处于“up”状态,这说明交换端口的工作状态也是正常的。后来,笔者怀疑618房间的计算机使用的IP地址可能与其他计算机的IP地址发生了冲突,于是建议那位上网用户换一个IP地址试试,果然在重新更换IP地址后,618房间的计算机又能正常上网了。

然后,没有多长时间,618隔壁房间的计算机又打来电话向笔者求援说,他们的计算机也不能正常上网了;笔者经过查阅档案资料,发现出现故障的计算机基本都处于相同的虚拟工作子网中,看来这种故障现象并不简单是由人工修改IP地址造成冲突引起的,很可能是对应虚拟工作子网中出现了ARP病毒。

我们知道,现在ARP病毒非常疯狂,局域网中的计算机很容易感染该病毒,而该病毒往往会欺骗局域网中所有计算机以及网络设备,并强制目标计算机通过特定的病毒主机进行上网访问。很多计算机被感染了ARP病毒后,之所以不能上网或者访问网络的速度会下降,主要是由于在正常状态下目标计算机的网卡IP地址与物理地址是一一对应的,当目标计算机的网卡设备从DHCP服务器 href="http://server.it168.com/" target=_blank>服务器那里申请得到IP地址后,该地址就会被临时与网卡设备的物理地址“捆绑”在一起,并且还会被自动记忆存储 href="http://storage.it168.com/" target=_blank>存储到本地系统的ARP映射表中;当局域网中有计算机被意外感染了ARP病毒后,ARP病毒就会强行把病毒计算机的网卡物理地址映射到局域网的交换机或路由器设备上,并且还会自动向网络中发送大量的ARP广播信息,局域网中的其他计算机收到广播信息后,往往会错误地认为病毒计算机就是局域网的网关地址,这样一来其他计算机就会自动把上网请求转发到病毒计算机上,而病毒计算机实际上并不是真正的网关地址,所以其他计算机自然也就不能正常上网,即使能够上网速度也不会很快了。

为了查清楚究竟是哪台计算机感染了ARP病毒,笔者立即以系统管理员身份登录进入到目标交换机系统,进入该系统的全局配置状态,利用“display dia”命令,查看目标交换机各个交换端口的工作状态,结果发现网卡物理地址为0016-173d-43eb的计算机与对应虚拟工作子网的网关地址存在冲突现象;为了追查出网卡物理地址为0016-173d-43eb的计算机究竟位于哪个房间,笔者立即在交换机的全局配置命令行状态下,执行字符串命令“display mac”,从其后出现的结果界面中,笔者看到网卡物理地址为0016-173d-43eb的计算机使用了43交换端口。

为了防止ARP病毒继续影响局域网的工作状态,笔者在交换机的后台管理界面中,执行字符串命令“interface e0/43”,进入43交换端口的视图配置状态,并且在该状态下继续执行字符串命令“shutdown”,将43交换端口暂时关闭掉,这样一来病毒计算机就不能通过该交换端口向局域网网络发送ARP病毒信息了,此时与病毒计算机同处一个虚拟工作子网的其他计算机立即都能正常上网了。

临时关闭43交换端口的工作状态后,笔者立即又查看了组网时完善起来的档案记录,发现43交换端口被分配给了563房间使用上网了;于是,笔者立即电话联系563房间的上网用户,告诉他的计算机已经感染了ARP病毒,目前已经被强行从网络中断开,并且要求该用户必须使用最新版本的杀毒软件对其使用的计算机进行病毒查杀操作;在查杀完病毒之后,笔者在对应交换端口的视图配置状态下,又执行了“undo shutdown”字符串命令,重新将43交换端口的工作状态激活,之后再次执行“display dia”命令,发现局域网中已经不存在地址冲突现象了,这说明局域网中的ARP病毒故障已经被成功解决了。 #p#

3.应对网络环路故障

某大楼网络共包含12个虚拟工作子网,每一楼层的所有计算机都通过1000M六类双绞线连接到华为系列的可管理交换机设备上,各个楼层中的二层交换机全部通过1000M级别的光纤线路连接到大楼网络的华为S8500核心路由交换机上,核心路由交换机再使用千兆光纤线路连接到单位的天融信硬件防火墙上,最后通过本地的电信线路访问Internet网络,平时大楼内各个楼层的计算机都能正常上网,遇到一些极个不能上网的现象时,网络管理员经过控制交换机系统,都能快速找到故障原因,并能快速恢复网络故障。

然而好景不长,某天上午,网络管理员先是接到来自10楼上网用户的故障保修电话,说是该楼层中的所有计算机瞬间都不能上网了;刚开始的时候,网络管理员估计夏天到了,肯定是楼层交换机工作时间长了,内部无法及时散发出来的热量造成了交换机的工作状态不正常了,对于这样的现象,往往只要让交换机稍微休息一会,再重新启动一下就能解决问题了。刚准备按照这样的思路进行操作,谁曾想到,在短短的几分钟了,其他楼层的上网用户也不停向网络管理员进行电话“求援”,并且申请解决的故障现象几乎都是相同的,显然这样的现象肯定不是由于交换机自身散热不良引起的,毕竟在相同的时间段内不可能有这么多楼层交换机同时出现散热不好的现象,看来问题很可能是大楼网络的核心交换机或硬件防火墙遇到了意外。

网络管理员立即以特权账号登录进入核心交换机后台管理系统,在该系统的命令行状态,使用ping命令测试了硬件防火墙的IP地址,测试结果发现ping命令可以测试成功,不过响应时间明显有点偏长;既然硬件防火墙能够被正常ping通,那就意味着该设备的工作状态是正常的,于是笔者决定还是先来查看一下核心交换机的工作状态是否正常。想到做到,网络管理员在核心交换机的后台管理界面,执行“system”字符串命令,将交换机系统切换到系统全局配置状态,在该状态下输入字符串命令“display cpu”,单击回车键后,笔者发现核心交换机每一块插卡上的CPU消耗率都达到了50%以上,而在正常工作状态下,每块交换插卡的CPU消耗率都应该在20%左右,显然大楼网络内的上网流量出现了异常,正是这些大容量的数据交换信息在不停冲击核心交换机的插卡,才导致了核心交换机的系统CPU资源被大量消耗,最终造成了核心交换机工作状态不正常。

那么究竟是什么因素造成了大楼网络内的上网流量出现了明显异常呢?是恶意使用BT下载?是网络病毒?还是网络环路呢?

笔者立即在核心交换机的后台系统使用“display dia”命令,对核心交换机的各个光纤端口状态进行了扫描诊断,结果发现与硬件防火墙保持连接的那个光纤端口数据流量竟然达到了19000M/s左右,而这样大的数据流量BT下载应用是不可能达到的,而网络病毒也没有这样的能力,很显然这么大的数据流量只有网络环路才能做得到。为了验证自己的猜测,网络管理员立即使用“display interface”字符串命令,来查看核心交换机每一个光纤端口的输入、输出流量,对于那些输入、输出流量同时达到1000M/s以上级别时,继续不停执行“display interface”字符串命令,看看输出广播包数量每秒钟增加的幅度有没有超过500M/s左右大小,如果超过这个大小,那就说明对应交换端口下的虚拟工作子网中存在网络风暴现象。经过对每一个交换端口的输入、输出流量进行详细检查,网络管理员终于找到“g0/1/6”这个光纤端口数据流量不正常,输入流量竟然也达到了5000M/s左右,经过反复执行“display interface g0/1/6”字符串命令,网络管理员最终确认连接到“g0/1/6”这个光纤端口下的虚拟工作子网中存在网络风暴现象。

为了弄清楚究竟是硬件设备损坏还是网络环路引起了网络风暴现象,网络管理员立即来到与“g0/1/6”这个光纤端口保持连接的楼层交换,以系统管理员权限登录进入该楼层交换机的后台管理系统,并使用ping命令测试核心交换机的IP地址时,发现ping命令根本无法测试成功,很显然该楼层交换机工作状态不正常。不得已,网络管理员只好使用“display interface”字符串命令,对该交换机的每一个以太交换端口进行检查,结果看到“e0/35”这个交换端口的输入、输出流量竟然达到了10000M/s级别,立即进入“e0/35”这个交换端口的视图配置状态,执行字符串命令“shutdown”,将“e0/35”交换端口的工作状态临时关闭;之后,网络管理员重新ping了一下核心交换机的IP地址,这一次测试竟然成功了,这说明该楼层交换机的工作状态已经恢复正常。

完成上面的检查工作后,网络管理员随即又联系了刚才报修故障的几位上网用户,请他们配合进行一下上网测试,没有多长时间,所有上网用户的回复都说网络访问已经正常,这说明大楼各个楼层不能上网的故障已经被成功解决了。

后来,网络管理员又查阅了相关的档案资料,发现使用“e0/35”交换端口的上网用户是1613房间,网络管理员立即火速赶到该房间现场,对他们的上网线路进行了检查,结果发现该房间下挂了一台普通的集线器,而恰好该房间当天有人在维修窗户,在维修期间工作人员将所有网络线缆全部拔了下来,在窗户修好之后,工作人员由于不熟悉网络连接操作,就随意地进行了网络连接操作,最终引起了网络环路现象,从而造成了整个大楼网络上网出现了故障。

【编辑推荐】

  1. 善于重启,解决交换机状态出错故障
  2. 网络病毒诱发交换机缓存溢出故障
责任编辑:许凤丽 来源: IT专家网论坛
相关推荐

2009-04-10 09:47:00

2010-09-01 09:18:13

无线网络掉线

2009-03-09 09:18:00

无线连接断线

2010-09-01 09:47:13

无线网络故障

2022-08-24 08:47:47

IT就业招聘

2017-04-01 15:33:09

2014-07-30 09:53:53

2014-05-12 11:12:12

2018-01-04 08:18:34

2022-08-22 15:01:24

网络安全大数据物联网

2013-09-02 15:35:00

2009-12-21 13:37:43

WCF消息交换

2011-10-08 17:22:52

扫描仪常见问题

2013-08-06 09:56:07

交换机端口交换机

2013-10-30 09:26:12

2009-03-27 09:02:48

GoogleAndroid移动OS

2011-01-18 15:35:59

jQueryJavaScriptweb

2010-02-06 10:30:11

多层交换机技术

2015-06-09 15:53:17

布线技术

2010-01-22 15:49:57

多层交换机技术
点赞
收藏

51CTO技术栈公众号