​我們知道，交換機是局域網中一種很重要的網絡設備，它的工作狀態與客戶端系統的上網狀態息息相關。

可是，在實際工作過程中，交換機的狀態很容易受到外界的干擾，那樣一來局域網中就會出現各種各樣的網絡故障。

為了保證網絡運行穩定，我們必須在平時對交換機進行妥善管理、維護，避免交換機發生故障。

本篇文章，轉載自一位資深老網工的排障經歷貼。他以前在對某大樓局域網進行維護時，曾經遇到過物理連接不當，而造成樓層交換機無法ping通的故障現象。這種網絡故障的排查曾讓他頗費一番周折。

由於該故障相對典型，而且其排查思路可供借鑒，所以特此分享給你。

網絡排障作為網絡工程師必備的技能之一，也是讓不少新手頭疼不已。

1. 故障現場

我當時所負責的寫字大樓包含若干個公司，為了保證每個公司都能獨立上網，並且要求它們的上網狀態不受其他公司的影響，我選用了路由交換機作為大樓網絡的核心交換機。

同時在交換機上對每個單位設置了不同的虛擬工作子網。

由於每家單位分佈在不同的樓層，每個樓層分佈的公司數量也不完全相同，有的樓層有兩、三家單位，有的樓層多達五、六家單位。

不同樓層的單位工作子網全部通過對應樓層的交換機，連接到大樓局域網中，並通過大樓網絡中的硬件防火牆訪問Internet網絡。

為了提高網絡管理效率，網絡管理員平時都會通過遠程連接方式對交換機進行管理、維護。

可是，那天早上一上班，我在掃描診斷局域網核心交換機各個交換端口的工作狀態時，發現其中某個交換端口處於down狀態。

於是我查看了網絡管理檔案，找到連接該端口的是五樓某二層交換機。

遠程登錄該樓層交換機時，發現遲遲無法登錄成功，使用ping 命令測試該交換機的IP 地址時，返回的結果為“Request time out ”;

就在我納悶為什麼沒有人報故障時，電話鈴聲如期而至，果然來自五樓的用戶開始接二連三地報修網絡故障了。

根據上述故障現象，我估計可能是樓層交換機的工作狀態出現了意外。

於是跑到該故障交換機現場，切斷該設備的電源，過一段時間後再次接通電源，進行重新啟動。

等到啟動操作完畢後，我又使用了ping 命令測試該交換機的IP 地址。

此時返回的結果已經正常，而且遠程登錄操作也能夠很順利地進行。

然而，半個小時之後，該故障交換機又出現了相同的故障現象，並且進行ping 命令測試時，又返回了不正常的測試結果。

后来我不放心，又重新经过反复启动测试，发现故障交换机始终无法正常 ping 通。

2. 深入排查

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

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

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

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

同时，将那台被怀疑可能存在问题的交换机连接到一个独立的网络工作环境。

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

而那台新替换的交换机连接到大楼网络后，却不能正常 ping通了。

依照这些现象，我认为五楼的交换机自身出现问题的可能性几乎没有。在排除了故障交换机自身状态因素后，我对整个大楼网络的组网结构和网络状态重新进行了回顾。

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

查阅五楼的组网资料，我看到五楼分布了五家单位，当时网络管理员在五楼布置了两台楼层交换机，将它们通过级联方式连接在一起；

同时在这两台交换机中划分了五个虚拟工作子网，保证了每家单位都能独立地工作于自己的虚拟工作子网中。

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

等到上班时间一到，我立即电话联系了其他几家没有报修网络故障的公司。得到的答复是说：他们刚刚才发现网络访问不正常，正准备向大楼网络管理员求救。

如此说来，整个五楼的所有单位都是不能正常上网的，那么引起该故障的原因应该在这几家单位的虚拟工作子网中。

在将故障排查范围锁定在位于五楼的五家单位之后，我认为既然重新启动五楼某个交换机的设备，能够暂时地将网络故障恢复。

只是在半个小时之后，相同的网络故障现象才会再次现象。

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

为了便于分析故障，我利用网络监听工具对五楼交换机的级联端口进行了网络传输数据包分析。

结果发现无论是输入数据包流量，还是输出数据包流量，都非常地大，几乎超过了正常数值的100倍左右，这说明四楼的网络中出现了网络堵塞现象。

那么究竟是网络病毒引起的网络堵塞？

还是网络环路引起的网络堵塞呢？

我打算观察一下故障交换机级联端口的状态信息变化，特别是输出广播包的变化。如果输出广播包每秒钟都在不停增大的话，那十有八九就能证明五楼网络中存在网络环路现象。

基于这样的分析思路，我使用 Console控制线直接连接到故障交换机上，以系统管理员身份登录进入该系统后台。

同时使用 display 命令查看了该交换机级联端口的输出广播包的变化，并且每隔一秒钟查看一次，之后比较每次查看的结果。

经过反复测试，我发现故障交换机的输出广播包大小果然在不断地增大着。

这说明五楼的五家单位中，肯定存在网络环路现象。

仔细查看了五楼的两台交换机，我发现它们之间的物理连接是正常的。

此外，这两台交换机的各个交换端口直接与五楼各个房间的墙上上网插口相连。

按理来说，只要各个房间不随意使用交换机进行级联， 应该不会出现网络环路现象的。

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

于是我电话联系了五楼各家单位的网络管理员，要求他们对各个办公房间进行检查，并上报使用下级交换机的房间。

没有多长时间，检查结果就反馈给了我，竟然有10个左右的房间使用了下级交换机进行扩展上网。

这时我知道这10个房间的网络连接，最有可能出现网络环路现象，那究竟是哪一个房间呢？

难道我要依次到各个房间的现场，查看他们的网络连接吗？

经过认真考虑，我找来了组网资料，将这10个房间使用的交换端口号码一一找了出来。

之后使用网络线缆直接插入到这些交换端口中，并在这些端口的视图模式状态下，依次ping故障交换机的IP地址。

结果ping到第六个交换端口时，我发现从该端口无法正常ping通。

为了判断该交换端口是否真的存在问题，我又在该交换端口视图模式状态下，使用 display 命令查看了该交换端口的状态信息。

经过查看分析，我发现该交换端口的输入、输出数据包大小明显不正常。于是，我估计该交换端口肯定是造成故障交换机工作状态不正常的原因。

查阅档案资料后，我迅速根据那个交换端口号码，找到了对应的那个上网房间。

到了现场后，我发现该房间中仅有的两个上网端口，都连接了小集线器，而这两台集线器下面都连接有几台计算机。

更要命的是还有一条网络线将它们直接连接在了一起，这样一来这两个集线器之间就形成了一个网络环路。 

该环路造成的广播风暴最终堵塞了故障交换机的级联端口，从而造成了整个楼网络都不能正常上网。

3. 故障解决

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

再次查看核心交换机上对应的交换端口状态时，发现原因的“down”状态已经变成了“up”状态，而且此时我也能正常ping通四楼的故障交换机了。

这说明，问题果然是由五楼某个房间的用户非法扩展使用交换机或集线器引起的。后来，我经过进一步询问上网用户了解到，他们的房间在前天晚上进行了打扫除，当时所有的网络线全部被拔了下来。

当清洁工作结束之后，上网用户由于对连接知识了解不多，就随意进行了插接，最终造成了网络环路现象。​