記一次網路故障排障

導讀	我以前在對某大樓區域網進行維護時，曾經遇到過物理連線不當，而造成樓層交換機無法ping通的故障現象。這種網路故障的排查曾讓我頗費一番周折。由於該故障相對典型，而且其排查思路可供借鑑，現在就將它與大家分享。

交換機是區域網中一種很重要的網路裝置，它的工作狀態與客戶端系統的上網狀態息息相關。

可是，在實際工作過程中，交換機的狀態很容易受到外界的干擾，那樣一來區域網中就會出現各種各樣的網路故障。為了保證網路執行穩定，我們必須在平時對交換機進行妥善管理、維護，避免交換機發生故障。我以前在對某大樓區域網進行維護時，曾經遇到過物理連線不當，而造成樓層交換機無法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通四樓的故障交換機了。這說明問題果然是由五樓某個房間的使用者非法擴充套件使用交換機或集線器引起的。

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

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

原文來自：