前言

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

可是，在實際工作過程中，交換機的狀態很容易受到外界的干擾，那樣一來局域網中就會出現各種各樣的網絡故障。為了保證網絡運行穩定，我們必須在平時對交換機進行妥善管理、維護，避免交換機發生故障。我以前在對某大樓局域網進行維護時，曾經遇到過物理連接不當，而造成樓層交換機無法ping通的故障現象。這種網絡故障的排查曾讓我頗費一番周折。由于該故障相對典型，而且其排查思路可供借鑒，現在就將它與大家分享。

[[313845]]

故障現場

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

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

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

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

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

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

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

遠程登錄該樓層交換機時，發現遲遲無法登錄成功，使用 ping 命令測試該交換機的 IP 地址時，返回的結果為“Request time out ”;就在我納悶為什么沒有人報故障時，電話鈴聲如期而至，果然來自五樓的用戶開始接二連三地報修網絡故障了。

根據上述故障現象，我估計可能是樓層交換機的工作狀態出現了意外。于是跑到該故障交換機現場，切斷該設備的電源，過一段時間后再次接通電源，進行重新啟動。

等到啟動操作完畢后，我又使用了 ping 命令測試該交換機的 IP 地址。此時返回的結果已經正常，而且遠程登錄操作也能夠很順利地進行。然而，半個小時之后，該故障交換機又出現了相同的故障現象，并且進行 ping 命令測試時，又返回了不正常的測試結果。后來我不放心，又重新經過反復啟動測試，發現故障交換機始終無法正常 ping 通。

深入排查

既然經過反復重啟不能解決問題，我估計引起該故障的原因比較復雜，考慮到這種故障現象在網絡管理過程中經常會碰到。

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

考慮到整個大樓網絡中，只有五樓的某個樓層交換機出現這種現象。我初步判斷可能是該樓層交換機自身問題引起的。

為了能夠確保可以準確定位故障原因，我準備利用一臺工作狀態正常的交換機來替換故障交換機，看看故障現象是否仍然存在。

同時，將那臺被懷疑可能存在問題的交換機連接到一個獨立的網絡工作環境。經過半個小時的測試、觀察，我看到那臺被連接到獨立網絡環境的故障交換機工作狀態是正常的，而且在該網絡環境下可以ping通它的 IP地址。

而那臺新替換的交換機連接到大樓網絡后，卻不能正常 ping通了。依照這些現象，我認為五樓的交換機自身出現問題的可能性幾乎沒有。

在排除了故障交換機自身狀態因素后，我對整個大樓網絡的組網結構和網絡狀態重新進行了回顧。

由于大樓中其他樓層的用戶都能正常上網，唯獨五樓的一部分用戶不能上網。

查閱五樓的組網資料，我看到五樓分布了五家單位，當時網絡管理員在五樓布置了兩臺樓層交換機，將它們通過級聯方式連接在一起。同時在這兩臺交換機中劃分了五個虛擬工作子網，保證了每家單位都能獨立地工作于自己的虛擬工作子網中。

既然核心交換機上的對應端口已經被down掉，那么整個五樓的所有單位都不能上網才對，為什么現在只有一部分用戶上報故障現象呢 ?

等到上班時間一到，我立即電話聯系了其他幾家沒有報修網絡故障的公司。得到的答復說他們剛剛才發現網絡訪問不正常，正準備向大樓網絡管理員求救。如此說來整個五樓的所有單位都是不能正常上網的，那么引起該故障的原因應該在這幾家單位的虛擬工作子網中。

在將故障排查范圍鎖定在位于五樓的五家單位之后，我認為既然重新啟動五樓某個交換機的設備，能夠暫時地將網絡故障恢復。只是在半個小時之后，相同的網絡故障現象才會再次現象。

對照這種特殊的現象，我懷疑可能是網絡廣播風暴，造成了交換機在一定時間內發生了堵塞現象，最終堵死了核心交換機的對應交換端口。

為了便于分析故障，我利用網絡監聽工具對五樓交換機的級聯端口進行了網絡傳輸數據包分析。結果發現無論是輸入數據包流量，還是輸出數據包流量，都非常地大，幾乎超過了正常數值的100倍左右，這說明四樓的網絡中出現了網絡堵塞現象。

[[313846]]

那么究竟是網絡病毒引起的網絡堵塞?還是網絡環路引起的網絡堵塞呢?

我打算觀察一下故障交換機級聯端口的狀態信息變化，特別是輸出廣播包的變化。

如果輸出廣播包每秒鐘都在不停增大的話，那十有八九就能證明五樓網絡中存在網絡環路現象。基于這樣的分析思路，我使用 Console控制線直接連接到故障交換機上，以系統管理員身份登錄進入該系統后臺。同時使用 display 命令查看了該交換機級聯端口的輸出廣播包的變化，并且每隔一秒鐘查看一次，之后比較每次查看的結果。

經過反復測試，我發現故障交換機的輸出廣播包大小果然在不斷地增大著。這說明五樓的五家單位中，肯定存在網絡環路現象。

仔細查看了五樓的兩臺交換機，我發現它們之間的物理連接是正常的。此外，這兩臺交換機的各個交換端口直接與五樓各個房間的墻上上網插口相連。

按理來說，只要各個房間不隨意使用交換機進行級聯， 應該不會出現網絡環路現象的。現在既然證明五樓網絡中存在網絡環路現象，這說明肯定有人在隨意使用交換機進行擴展上網，我們只要找到擴展交換機，并對它的物理連接進行檢查，就能迅速找到具體的故障節點了。

于是我電話聯系了五樓各家單位的網絡管理員，要求他們對各個辦公房間進行檢查，并上報使用下級交換機的房間。沒有多長時間，檢查結果就反饋給了我，竟然有10個左右的房間使用了下級交換機進行擴展上網。這時我知道這10個房間的網絡連接，最有可能出現網絡環路現象，那究竟是哪一個房間呢?

難道我要依次到各個房間的現場，查看他們的網絡連接嗎?經過認真考慮，我找來了組網資料，將這10個房間使用的交換端口號碼一一找了出來。

之后使用網絡線纜直接插入到這些交換端口中，并在這些端口的視圖模式狀態下，依次ping故障交換機的IP地址。結果ping到第六個交換端口時，我發現從該端口無法正常ping通。為了判斷該交換端口是否真的存在問題，我又在該交換端口視圖模式狀態下，使用 display 命令查看了該交換端口的狀態信息。

經過查看分析，我發現該交換端口的輸入、輸出數據包大小明顯不正常。于是，我估計該交換端口肯定是造成故障交換機工作狀態不正常的原因。查閱檔案資料后，我迅速根據那個交換端口號碼，找到了對應的那個上網房間。

到了現場后，我發現該房間中僅有的兩個上網端口，都連接了小集線器，而這兩臺集線器下面都連接有幾臺計算機。更要命的是還有一條網絡線將它們直接連接在了一起，這樣一來這兩個集線器之間就形成了一個網絡環路。 該環路造成的廣播風暴最終堵塞了故障交換機的級聯端口，從而造成了整個樓網絡都不能正常上網。

[[313847]]

故障解決

將該多余的網絡線纜拔除之后，我重新查看了該交換端口的狀態信息。結果發現輸入、輸出數據包大小都恢復了正常。

再次查看核心交換機上對應的交換端口狀態時，發現原因的“down”狀態已經變成了“up”狀態，而且此時我也能正常ping通四樓的故障交換機了。這說明問題果然是由五樓某個房間的用戶非法擴展使用交換機或集線器引起的。

后來，我經過進一步詢問上網用戶了解到，他們的房間在前天晚上進行了打掃除，當時所有的網絡線全部被拔了下來。當清潔工作結束之后，上網用戶由于對連接知識了解不多，就隨意進行了插接，最終造成了網絡環路現象。

總結

通過對這則網絡故障的深入排查，我們不難看出，當遇到網絡故障時，一定要結合故障現象，逐步縮小故障排查范圍，然后借助專業工具來測試上網數據包的大小變化，快速定位故障節點。希望我的這次排錯經歷對你有幫助。