【IT168专稿】局域网中的交换机工作起来，往往不知疲倦，日日夜夜地为上网用户提供“服务”，不过长时间地这样负重前行，交换机很容易支撑不住，出现性能老化现象，从而容易引发各种潜在的网络故障。笔者曾经遇到过一则上网数据严重丢包的故障现象，经过仔细排查之后，发现竟然是交换机自身负荷过重引起的，现在本文就将这则故障的详细排查过程贡献出来，与各位网友参考交流!

　　上网发现严重丢包

　　笔者的朋友是一家单位的网络管理员，他所在的单位大楼共有5层，每个楼层有2个弱电间，楼层交换机就放置在其中。每一个楼层上网用户数量大约为200人，每个用户的计算机都通过100M超五类线缆连接到普通楼层交换机上，普通楼层交换机使用1000M多模光纤线路与大楼局域网中的核心交换机连接。整个大楼局域网租用电信1000M宽带光纤线路，直接访问Internet网络;同时，为了防止来自Internet网络的非法攻击，大楼局域网通过天融信硬件防火墙与Internet网络，确保局域网中的用户上网冲浪安全。

　　平时，大楼中的所有用户都能正常上网，而且访问速度也是不错的。不过最近开始，朋友发现三楼用户不断打来电话，投诉说他们不能正常上网;起初的时候，朋友还以为只是极个别现象，于是每当有上网用户打电话要求帮忙解决网络故障时，朋友都建议他们重新插拔一下网络线缆，或者更换一个IP地址，实在不行的话将计算机系统重新启动一下。然而，同一楼层的上网用户接二连三地上报网络故障，这才让朋友意识到问题并没有自己想像的那样简单;考虑到目前只有三楼的用户电话报告网络故障，而没有其他楼层的用户打电话过来，朋友初步判断很可能是三楼的某个虚拟工作子网出现了问题。

　　根据常规经验，朋友认为某个子网出现大面积不能上网现象时，问题多半出在连接对应虚拟工作子网的楼层交换机上;于是，朋友立即到三楼的弱电间进行现场查看，发现位于三楼的普通楼层交换机共有四个交换机，它们通过1000M光纤线路相互级联在一起，之后再通过其中一个交换机与大楼网络的核心交换机相连，为了找出故障交换机，朋友使用ping命令依次对这四个交换机的IP地址进行测试，结果发现其中一个交换机对ping命令反应比较迟钝，后来朋友又对这个反应迟钝的交换机连续发送了大容量的ping测试数据包，测试表明该交换机数据丢包非常严重，而且有很大的延迟现象。

　　逐一寻找故障原因

　　找到故障交换机后，朋友估计很可能是连接到该交换机上的某个虚拟工作子网出现了问题，那究竟会是什么因素造成交换机数据丢包非常严重，而且有很大的延迟现象呢?起初，朋友下意识地认为可能是故障交换机下面遭遇到了arp病毒攻击，由于现在这种类型的网络病毒非常流行，稍微不小心就可能被该病毒袭击到，而且局域网中感染了arp病毒，对应虚拟工作子网中也同样会出现大面积不能上网的故障现象;为了验证自己的猜测是否正确，朋友立即以Console连接登录进入故障交换机后台系统，并在该系统的全局模式下执行“display logbuff”命令，查看对应交换机系统的日志记录，发现没有因arp病毒造成的网关地址被非法抢用的现象，这就意味着故障交换机下面不存在arp病毒。

　　有没有可能是故障交换机下面存在网络环路呢?在排除了arp病毒因素后，朋友开始怀疑网络环路在暗中作祟了，因为只要局域网中存在网络环路现象，那么该现象可能会造成大量的广播数据包，这些数据包会不停地冲击交换机，造成局域网网络传输堵塞，严重的时候能直接造成交换机死机现象。由于网络环路现象能够造成交换机的某个交换端口输入、输出数据流量明显异常现象，朋友认为只要扫描一下故障交换机的各个交换端口，找出流量状态不正常的故障端口，并将对应的端口关闭掉，相信这样就能恢复交换机的工作状态了。想到做到，朋友立即在故障交换机后台系统执行端口扫描操作，来检查各个交换端口的数据流量大小，可是扫描操作结束后，他却并没有发现数据流量有明显异常的交换端口，这就说明故障交换机的工作状态不可能是端口下面的大容量数据不停冲击造成的。

　　在排除了网络环路以及网络病毒等因素后，朋友发现三楼的部分用户还是不能正常上网，于是他打算重新启动一下故障交换机系统，看看是否是故障交换机自身的问题，造成了数据严重丢包的故障现象;考虑到交换机工作时间长了之后，很容易出现缓存溢出错误或其他一些软故障，这些软故障往往只要重新启动一下系统就能自动消失了。然而让朋友感到比较失望的是，当他切断交换机电源，对该系统进行重新启动后，发现上述故障现象仍然没有消失，很明显数据严重丢包的故障现象也不是由交换机的软故障引起的。

　　后来，朋友担心交换机的端口出现问题，因为他发现各个上网用户的终端设备工作模式都为自使用模式，而交换机的端口却工作在100M全双工模式状态下，会不会是它们之间传输数据时发生了不匹配现象呢?想到这一点，朋友立即在故障交换机系统后台，依次进入各个交换端口的视图模式状态，并在该状态下尝试着将它们的端口工作模式也修改为自适应模式，满以为这样的努力能够解决问题，可是当朋友重新尝试着从自己的笔记本电脑ping故障交换机的IP地址时，发现数据丢包现象仍然比较严重，而且ping命令的响应速度也不是很快，看来问题与交换机的端口工作模式也没有什么关系。

　　交换机“负荷”过重

　　在毫无头绪的情况下，朋友打算将连接到故障交换机上的所有网络线缆依次拔掉，并且拔一个就ping一下交换机的IP地址，看看其数据丢包现象有没有恢复。由于故障交换机上包含了48个端口，当朋友刚开始拔网络线缆的时候，发现连续拔了好几个，故障交换机的数据丢包现象就是不消失;当将故障交换机上连接到第25个端口上的网络线缆拔下来时，朋友发现故障交换机的数据丢包现象突然不见了，难道是连接到第25个端口下面的虚拟工作子网存在问题?为了排除这种故障因素，朋友立即在故障交换机后台系统，执行字符串命令“interface e0/25”，进入对应端口的视图模式状态，在该状态下执行字符串命令“shutdown”，将第25个交换端口的工作状态暂时关闭，那样一来通过该交换端口连接到大楼网络的虚拟工作子网就不会对大楼网络的运行造成冲击了。可是，让朋友没想到的是，当他再次将之前拔下来的网络线缆重新插入到故障交换机上时，发现故障交换机的数据丢包现象又一次出现了，这么说来，这种故障现象与第25个交换端口没有直接关系呀!后来，朋友又做了一次测试，这次他索性先将连接到故障交换机上的所有连接线缆一次性拔了下来，之后将每根网络线缆依次插入到交换机上，并且每插入一根就测试一次故障交换机的连通性，结果发现当将前24个交换端口上的网络线缆插上后，故障交换机的工作状态都正常，但是从第25个交换端口开始，故障交换机的工作状态就不正常了，于是朋友认为很可能是故障交换机负担不起太多的网络端口上网。为了验证自己的猜测是否正确，朋友在插入前24个交换端口上的网络线缆后，进入故障交换机后台系统，并在该系统的全局配置模式下，执行字符串命令“display cpu”，从返回的结果信息中他看到目标交换机系统CPU消耗率为23%;之后，他将第25个交换端口上的网络线缆插上，并且在这种情况下又执行了一遍“display cpu”命令，这次他发现交换机系统CPU消耗率竟然变成了59%，而正常情况下交换机的系统CPU消耗率应该不超过30%才对，现在远远偏离了该数值，说明故障交换机的确“负荷”过重。

　　考虑到故障交换机明明有48个交换端口，现在只有一般交换端口在工作，交换机就明显反应迟钝了，难道交换机自身的性能发生老化了?为了判断故障交换机是否真的出现硬件性能下降现象了，朋友立即将其他一台工作状态正常的交换机拿来进行替换，并将所有网络线缆全部插入到替换后的交换机设备上，经过测试替换后的交换机工作状态一直很正常，这就意味着故障交换机的确出现了硬件性能下降的现象。之后，朋友还是不放心，将故障交换机放置到其他位置进行测试，发现故障交换机的确只能“支撑”24个交换端口同时上网，超过这个负荷，立即就会出现上网数据丢包严重的现象，看来故障交换机真的要“下岗”了。