记某次一位老工程师的网络故障排障经历

前言

交换机是局域网中一种很重要的网络设备，它的工作状态与客户端系统的上网状态息息相关。

可是，在实际工作过程中，交换机的状态很容易受到外界的干扰，那样一来局域网中就会出现各种各样的网络故障。为了保证网络运行稳定，我们必须在平时对交换机进行妥善管理、维护，避免交换机发生故障。我以前在对某大楼局域网进行维护时，曾经遇到过物理连接不当，而造成楼层交换机无法ping通的故障现象。这种网络故障的排查曾让我颇费一番周折。由于该故障相对典型，而且其排查思路可供借鉴，现在就将它与大家分享。

故障现场

我当时所负责的写字大楼包含若干个公司，为了保证每个公司都能独立上网，并且要求它们的上网状态不受其他公司的影响，我选用了路由交换机作为大楼网络的核心交换机。

同时在交换机上对每个单位设置了不同的虚拟工作子网。

由于每家单位分布在不同的楼层，每个楼层分布的公司数量也不完全相同，有的楼层有两、三家单位，有的楼层多达五、六家单位。

不同楼层的单位工作子网全部通过对应楼层的交换机，连接到大楼局域网中，并通过大楼网络中的硬件防火墙访问Internet网络。

为了提高网络管理效率，网络管理员平时都会通过远程连接方式对交换机进行管理、维护。

可是，那天早上一上班，我在扫描诊断局域网核心交换机各个交换端口的工作状态时，发现其中某个交换端口处于down状态。

于是我查看了网络管理档案，找到连接该端口的是五楼某二层交换机。

远程登录该楼层交换机时，发现迟迟无法登录成功，使用 ping 命令测试该交换机的 IP 地址时，返回的结果为“Request time out ”;就在我纳闷为什么没有人报故障时，电话铃声如期而至，果然来自五楼的用户开始接二连三地报修网络故障了。

根据上述故障现象，我估计可能是楼层交换机的工作状态出现了意外。于是跑到该故障交换机现场，切断该设备的电源，过一段时间后再次接通电源，进行重新启动。

等到启动操作完毕后，我又使用了 ping 命令测试该交换机的 IP 地址。此时返回的结果已经正常，而且远程登录操作也能够很顺利地进行。然而，半个小时之后，该故障交换机又出现了相同的故障现象，并且进行 ping 命令测试时，又返回了不正常的测试结果。后来我不放心，又重新经过反复启动测试，发现故障交换机始终无法正常 ping 通。

深入排查

既然经过反复重启不能解决问题，我估计引起该故障的原因比较复杂，考虑到这种故障现象在网络管理过程中经常会碰到。

于是我按照下面的思路进行了深入排查：

考虑到整个大楼网络中，只有五楼的某个楼层交换机出现这种现象。我初步判断可能是该楼层交换机自身问题引起的。

为了能够确保可以准确定位故障原因，我准备利用一台工作状态正常的交换机来替换故障交换机，看看故障现象是否仍然存在。

同时，将那台被怀疑可能存在问题的交换机连接到一个独立的网络工作环境。经过半个小时的测试、观察，我看到那台被连接到独立网络环境的故障交换机工作状态是正常的，而且在该网络环境下可以ping通它的 IP地址。

而那台新替换的交换机连接到大楼网络后，却不能正常 ping通了。依照这些现象，我认为五楼的交换机自身出现问题的可能性几乎没有。

在排除了故障交换机自身状态因素后，我对整个大楼网络的组网结构和网络状态重新进行了回顾。

由于大楼中其他楼层的用户都能正常上网，唯独五楼的一部分用户不能上网。

查阅五楼的组网资料，我看到五楼分布了五家单位，当时网络管理员在五楼布置了两台楼层交换机，将它们通过级联方式连接在一起。同时在这两台交换机中划分了五个虚拟工作子网，保证了每家单位都能独立地工作于自己的虚拟工作子网中。

既然核心交换机上的对应端口已经被down掉，那么整个五楼的所有单位都不能上网才对，为什么现在只有一部分用户上报故障现象呢 ?

等到上班时间一到，我立即电话联系了其他几家没有报修网络故障的公司。得到的答复说他们刚刚才发现网络访问不正常，正准备向大楼网络管理员求救。如此说来整个五楼的所有单位都是不能正常上网的，那么引起该故障的原因应该在这几家单位的虚拟工作子网中。

在将故障排查范围锁定在位于五楼的五家单位之后，我认为既然重新启动五楼某个交换机的设备，能够暂时地将网络故障恢复。只是在半个小时之后，相同的网络故障现象才会再次现象。

对照这种特殊的现象，我怀疑可能是网络广播风暴，造成了交换机在一定时间内发生了堵塞现象，最终堵死了核心交换机的对应交换端口。

为了便于分析故障，我利用网络监听工具对五楼交换机的级联端口进行了网络传输数据包分析。结果发现无论是输入数据包流量，还是输出数据包流量，都非常地大，几乎超过了正常数值的100倍左右，这说明四楼的网络中出现了网络堵塞现象。

那么究竟是网络病毒引起的网络堵塞?还是网络环路引起的网络堵塞呢?

我打算观察一下故障交换机级联端口的状态信息变化，特别是输出广播包的变化。

如果输出广播包每秒钟都在不停增大的话，那十有八九就能证明五楼网络中存在网络环路现象。基于这样的分析思路，我使用 Console控制线直接连接到故障交换机上，以系统管理员身份登录进入该系统后台。同时使用 display 命令查看了该交换机级联端口的输出广播包的变化，并且每隔一秒钟查看一次，之后比较每次查看的结果。

经过反复测试，我发现故障交换机的输出广播包大小果然在不断地增大着。这说明五楼的五家单位中，肯定存在网络环路现象。

仔细查看了五楼的两台交换机，我发现它们之间的物理连接是正常的。此外，这两台交换机的各个交换端口直接与五楼各个房间的墙上上网插口相连。

按理来说，只要各个房间不随意使用交换机进行级联， 应该不会出现网络环路现象的。现在既然证明五楼网络中存在网络环路现象，这说明肯定有人在随意使用交换机进行扩展上网，我们只要找到扩展交换机，并对它的物理连接进行检查，就能迅速找到具体的故障节点了。

于是我电话联系了五楼各家单位的网络管理员，要求他们对各个办公房间进行检查，并上报使用下级交换机的房间。没有多长时间，检查结果就反馈给了我，竟然有10个左右的房间使用了下级交换机进行扩展上网。这时我知道这10个房间的网络连接，最有可能出现网络环路现象，那究竟是哪一个房间呢?

难道我要依次到各个房间的现场，查看他们的网络连接吗?经过认真考虑，我找来了组网资料，将这10个房间使用的交换端口号码一一找了出来。

之后使用网络线缆直接插入到这些交换端口中，并在这些端口的视图模式状态下，依次ping故障交换机的IP地址。结果ping到第六个交换端口时，我发现从该端口无法正常ping通。为了判断该交换端口是否真的存在问题，我又在该交换端口视图模式状态下，使用 display 命令查看了该交换端口的状态信息。

经过查看分析，我发现该交换端口的输入、输出数据包大小明显不正常。于是，我估计该交换端口肯定是造成故障交换机工作状态不正常的原因。查阅档案资料后，我迅速根据那个交换端口号码，找到了对应的那个上网房间。

到了现场后，我发现该房间中仅有的两个上网端口，都连接了小集线器，而这两台集线器下面都连接有几台计算机。更要命的是还有一条网络线将它们直接连接在了一起，这样一来这两个集线器之间就形成了一个网络环路。 该环路造成的广播风暴最终堵塞了故障交换机的级联端口，从而造成了整个楼网络都不能正常上网。

故障解决

将该多余的网络线缆拔除之后，我重新查看了该交换端口的状态信息。结果发现输入、输出数据包大小都恢复了正常。

再次查看核心交换机上对应的交换端口状态时，发现原因的“down”状态已经变成了“up”状态，而且此时我也能正常ping通四楼的故障交换机了。这说明问题果然是由五楼某个房间的用户非法扩展使用交换机或集线器引起的。

后来，我经过进一步询问上网用户了解到，他们的房间在前天晚上进行了打扫除，当时所有的网络线全部被拔了下来。当清洁工作结束之后，上网用户由于对连接知识了解不多，就随意进行了插接，最终造成了网络环路现象。

总结

通过对这则网络故障的深入排查，我们不难看出，当遇到网络故障时，一定要结合故障现象，逐步缩小故障排查范围，然后借助专业工具来测试上网数据包的大小变化，快速定位故障节点。希望我的这次排错经历对你有帮助。