网速变慢 源起受损HUB暗中捣乱

　　有一些网络故障是由不起眼的细节因素引起的，这些细节因素平时出现的次数比较少，我们在排除故障的时候很容易忽略它们，这样一来故障排除起来就可能多走弯路，最终会影响故障的排除效率。

　　无论局域网运行规模多大，持续运行的时间长了，各式各样的网络故障就会出现了。面对网络故障，正常情况下我们只要仔细观察具体的故障现象，就能初步找到故障产生的原因，并能对症下药、采取措施解决故障了。不过，也有一些网络故障是由不起眼的细节因素引起的，这些细节因素平时出现的次数比较少，我们在排除故障的时候很容易忽略它们，这样一来故障排除起来就可能多走弯路，最终会影响故障的排除效率。这不，笔者曾经遭遇到的一则网络故障，竟然是由于某个HUB设备发生硬件损坏引起的，鉴于该细节因素出现的机率较小，现在笔者就将该故障的详细排查过程还原出来，与各位朋友共享交流。

　　网速突然变慢

　　笔者管理的某行政大楼局域网网络规模比较大，整个局域网大约由20台二层交换机和一台核心交换机组成，所有二层交换机都是通过1000兆多模光纤与核心交换机保持连接，每一台客户端系统采用100M网络线缆与各个楼层的二层交换机相互连接，核心交换机通过1000兆多模光纤直接连接硬件防火墙，并租用本地电信部门提供的千兆宽带线路实现共享上网目的。为了有效避免广播风暴现象以及抑制网络病毒的疯狂传播，笔者在核心交换机上进行了Vlan划分，确保每一个楼层的客户端系统都处于一个独立的工作子网中。

　　平时，局域网中的所有客户端系统上网都很正常，网络访问速度也是比较快的。可是，最近笔者接二连三地接到故障报修电话，说上网速度越来越慢，特别是在上班高峰期时段，网络几乎就不能使用。刚开始的时候，笔者还以为这仅仅是个别现象，并建议故障报修的用户，动手去查杀一下自己客户端系统中是否有网络病毒;现在好了，电话求援的人数越来越多，这让笔者意识到局域网中看来真的出现了大问题。

　　故障排查过程

　　由于电话求援的用户来自不同的楼层，笔者下意识地认为局域网中可能存在ARP病毒，因为最近Internet网络上经常有ARP病毒疯狂肆虐的消息，并且由ARP病毒造成的网络故障表现出来的现象通常也是大面积上网不正常或者是上网速度缓慢，难道真的是ARP病毒在偷偷作祟?为了检查单位局域网中是否真的有ARP病毒，笔者随意找了一台故障客户端系统，依次单击“开始”/“运行”命令，在弹出的系统运行对话框中执行“cmd”命令，将系统切换到DOS命令行工作状态，在该状态下输入字符串命令“arp -d *”，单击回车键，将本地系统ARP列表中的内容全部删除，之后使用ping命令，重新测试核心交换机的IP地址，可是这一次仍然无法正常ping通核心交换机的地址，按理来说要是局域网意外感染了ARP病毒，删除客户端系统ARP列表中的内容之后，我们应该能够暂时ping通核心交换机的地址才对呀，难道故障客户端系统中不存在ARP病毒?

　　为了弄清楚局域网中究竟是否存在ARP病毒，笔者决定查看一下核心交换机的日志记录，看看有没有由ARP病毒引起的地址冲突内容。考虑到远程登录速度太慢，笔者只好火速赶到核心交换机现场，仔细观察该设备控制面板上的信号灯状态时，并没有看到有什么异常的地方;再用笔记本电脑通过Console控制端口，连接到核心交换机上，同时以系统管理员身份登录进入该交换机的后台管理系统，之后将该系统工作状态切换到全局配置模式状态，并输入“dis logb”字符串命令，单击回车键后发现结果信息中并没有地址冲突记录信息，这就意味着单位局域网网络中并没有ARP病毒。

　　在排除了ARP病毒因素后，笔者开始怀疑局域网网络的核心交换机可能出现了问题。于是，笔者立即在自己的笔记本电脑中，使用ping命令测试一下核心交换机的IP地址，结果发现ping命令测试操作存在明显的丢包、延时现象，尝试上网访问网页内容时，访问速度的确是奇慢无比。不得已，笔者再次用笔记本电脑通过Console控制端口，连接到核心交换机上，同时以系统管理员身份登录进入该交换机的后台管理系统，之后将该系统工作状态切换到全局配置模式状态，在该状态下执行“display cpu”命令时，笔者看到系统CPU资源消耗率竟然达到了惊人的90%，怪不得客户端系统总感觉到上网速度缓慢，原来是核心交换机的系统资源被过度消耗，造成了它无法快速响应客户端系统提出的上网访问请求，那么究竟是什么因素强行占用核心交换机宝贵的CPU资源呢?根据以往经验，对待这种系统资源过度消耗的现象，通常只要简单地重新启动一下交换机后台系统，就能将被占用的系统资源释放出来了，这次会不会呢?为了一看究竟，笔者选择下班时间，断开核心交换机的输入电源，过一段时间后，再接通它的电源，以便重新启动该设备的后台系统，待启动稳定的那一刻，笔者用笔记本电脑测试了网络访问速度，发现访问速度居然恢复正常了;可是，没有持续多长时间，网络访问速度又变得象蜗牛那样爬行了，再测试交换机后台系统的CPU资源消耗率时，发现该资源占用率又达到惊人的95%了。根据这一现象，笔者断定局域网网络中可能存在网络环路。

　　为了定位具体的网络环路位置，笔者在核心交换机后台，使用“display interface”命令，依次查看了各个楼层交换机与核心交换机之间的光纤连接端口状态信息，结果发现GigabitEthernet1/1/14光纤端口的状态明显不正常，来自该交换端口的输出数据流量、输入数据流量，特别大，与正常工作状态时的输出、输入数据流量相差甚远，显然GigabitEthernet1/1/14光纤端口下面的虚拟工作子网中可能存在网络环路现象。查看组网档案资料，笔者发现与核心交换机GigabitEthernet1/1/14光纤端口相连的是来自五楼的某个楼层交换机，将该楼层交换机与核心交换机之间的物理连接断开后，再次在核心交换机后台系统上执行“display cpu”命令，笔者发现这一次系统资源消耗下降到了正常的20%，看来整个局域网上网速度缓慢的现象，就是由于五楼的某个楼层交换机引起的。

　　彻底解决故障

　　既然网络速度变慢的原因是由五楼的某个楼层交换机引起的，那么网络环路现象究竟出现在五楼的哪个位置呢?由于连接到目标交换机下面的计算机数量不是很多，只有20台左右，于是笔者打算采用比较“笨”的办法，那就是将五楼交换机上的所有网络线缆依次拔下来，之后每拔上一根网络线缆后，就观察该楼层交换机CPU资源消耗率的状态变化，看看究竟是哪个交换端口在偷偷“捣乱”。功夫不负有心人，在经过一段时间的观察后，笔者终于将故障范围缩小到e0/8这个普通的以太网电口上。

　　通过贴在e0/8交换端口上的标签信息，笔者发现连接到e0/8这个普通以太网电口上的是位于503房间的一个网络插座，赶到503房间时，笔者发现目标网络插座下面连接的不是普通客户端系统，而是连接的一个HUB设备;原来，这个办公室最近新增加了几个办公人员，为了能让所有的员工都能同时上网，于是他们自行主张，找来了一个旧的HUB设备，该办公室中的所有客户端系统全部连接到HUB设备上，进行共享上网访问。由于这个HUB设备不支持网络管理功能，笔者只好还是逐一拔掉网络连接线缆，观察HUB设备上的信号灯状态变化情况;让人意想不到的是，当笔者将连接到HUB设备上的所有网络线缆全部拔掉的时候，HUB设备上的信号灯居然仍然处于全部点亮状态，这是什么回事呢?很明显，出现这种现象很可能是HUB设备发生了短路问题，这种损坏的设备在无形之中形成了网络环路现象。为了验证自己的猜测，笔者立即找来一只新的HUB设备，替换掉那只旧的HUB设备;果然，在完成设备的替换操作之后，笔者发现所有网络线缆全部插入到HUB设备上后，它的信号灯状态全部恢复到正常状态了。再将5楼楼层交换机连接到核心交换机上后，笔者再次使用“display interface”命令，查看了GigabitEthernet1/1/14光纤端口的状态信息，发现该交换端口的输出数据包、输入数据包立即恢复了正常，此时笔者通过笔记本电脑进行上网测试时，发现网络访问速度也恢复到原来的正常状态了，至此网络速度变慢的故障现象就被彻底解决了。

　　小提示：一般来说，现在局域网使用的核心交换机都支持环回受控测试功能，巧妙地利用该功能，我们可以快速地查看到究竟哪个交换端口下面存在网络环路现象。在实际管理网络的过程中，我们一旦遇到了网络速度突然变慢的故障现象时，可以先将核心交换机中那个流量异常的交换端口配置成Trunk模式，再进入该Trunk端口的视图配置模式，将该端口的环回受控测试功能启用起来，日后要是局域网中果然存在网络环路现象的话，那么该功能会自动关闭存在网络环路的交换端口，那么整个局域网的工作状态就不会受到影响了。当然，即使我们没有启用网络环回受控测试功能，网络环回测试功能同样也能通过“display loopback-detection”命令，快速定位到发生环路故障的具体端口，只是不会将该端口立即关闭，如此一来可能造成整个网络发生堵塞现象。