【51CTO.com獨家特稿】局域網運行時間一長，出現網絡故障的機率就越大，這其中有網絡設備運行性能下降的原因，也有網絡病毒襲擊的原因，但更多的故障卻是由用戶的管理、維護操作不當引起的；這不，筆者曾經遭遇一則由于網絡線纜連接不當，引發局域網廣播風暴現象，造成網絡訪問頻繁出錯故障，現在就將該故障的排除過程還原出來，與大家一起分享、交流！

網絡訪問頻繁出錯   

這幾天，筆者辦公室電話不停響起，上網用戶一會兒反映說他們上網的速度象蝸牛一樣，一會兒反映說網絡連接時通時斷，更為嚴重的是有時整個虛擬工作子網都不能上網；對上報的故障點進行大概分析，筆者發現這些故障點很分散，分布在多個不同的樓層和不同的虛擬工作子網中。對故障工作子網中的交換機進行設備替換測試后，網絡訪問仍然還是頻繁出錯；任意選擇一臺故障客戶端系統進行連通性測試，筆者看到對應虛擬工作子網中的網關設備地址能夠Ping通，在相同的工作子網中進行共享訪問時也能正常，對局域網中的核心交換機IP地址進行連通性測試時，往往會發生延遲時間長、數據丟包嚴重，甚至無法ping通的現象。通過交換機自帶的網絡管理工具對相關交換機設備進行檢查、測試時，也沒有找到明顯的報錯。

網絡訪問環境說明   

筆者所在單位局域網組網規模較大，整個大樓采用星型拓撲網絡結構進行組網，網絡中的核心匯聚交換機為H3C S8500路由交換機，該交換機放在信息中心機房，接入交換機統一為3組堆疊的H3C S3050樓層交換機，這些交換機分別位于各個樓層的弱電配電間，每個弱電配電間幾乎都安裝有48口交換機兩到四臺，大樓中的各個部門客戶端系統利用級連方式或者直接接入方式，并通過各自樓層交換機接入大樓局域網網絡。

信息中心機房中的服務器有若干臺，能夠同時對客戶端系統提供FTP服務、Web服務以及文件服務等。為了控制網絡運行安全，以及方便管理、維護，整個大樓網絡分為20個VLAN，同時依照部門不同分別為不同工作子網定義了IP地址，所有網關都建在H3C S8500路由交換機上；為了保證數據傳輸、交換速度，客戶端設備到樓層交換機統一采用超五類雙絞線線纜，樓層交換機到核心交換機統一采用千兆多模光纖線纜。

逐一排查故障因素   

由于網絡故障點比較分散，局域網中的很多客戶端系統同時出現上網時斷時續、網絡傳輸延遲現象，為此筆者估計大樓局域網的核心交換機工作狀態不正常，于是嘗試著重新啟動核心交換機系統，待重啟成功后，筆者發現故障現象明顯有了好轉，可是沒有多長時間，又出現了相同的故障現象，看來問題非常嚴重。   

任意選擇一臺客戶端系統，打開該系統的運行對話框，在其中執行ping命令，來測試對應虛擬工作子網的網關地址，結果發現數據丟包現象比較嚴重，達到了85%左右，同時延遲時間大約在500ms，這顯然是不正常的；再從核心交換機后臺系統ping外網網關地址，發現數據丟報率低于2%，同時延遲時間也不是很大，這說明問題可能出在客戶端系統到核心交換機之間。   

登錄進入核心交換機后臺系統，使用“display dia”命令，查看各個光纖交換端口的狀態信息，筆者發現一些交換端口的輸入、輸出數據流量明顯不正常，進入異常流量端口視圖模式狀態，執行字符串命令“display interface g1/2/1”，查看該端口的具體狀態信息時，筆者看到該端口此時處于“down”狀態，這也難怪連接到該光口下面的虛擬工作子網都不能正常訪問網絡了，進一步查看該端口其他配置信息時，筆者發現廣播數據包的大小也不正常；難道是目標交換端口下面的虛擬工作子網中存在網絡病毒？

為了避免網絡病毒繼續威脅整個大樓網絡的穩定運行，筆者在核心交換機后臺系統，使用字符串命令“interface g1/2/1”進入指定光口視圖模式狀態，并在該模式狀態下執行字符串命令“shutdown”，關閉該光口的運行狀態，那么連接到該光口下的虛擬工作子網中的網絡病毒就不會影響核心交換機的工作狀態了；原以為上述處理操作，能夠解決網絡訪問頻繁出錯故障，可是再次重新啟動核心交換機后臺系統后，筆者發現相同的故障現象仍然存在，這就意味著上述網絡故障與網絡病毒沒有關系。   

在排除網絡病毒因素后，筆者開始懷疑連接到g1/2/1光纖端口下的樓層交換機到核心交換機之間的線路連通性存在問題，于是使用專門的光功率計來測試光纖線纜的信號收發情況，發現測試結果一切正常，這說明問題與光纖線路連通性沒有關系。由于筆者無法遠程登錄故障樓層交換機，只好趕到該交換機現場，通過Console控制端口登錄進入故障交換機后臺系統，依次執行“system”、“display cpu”命令，發現該設備后臺系統的CPU資源消耗率幾乎達到100%，很明顯該樓層交換機下面的虛擬工作子網中存在大量廣播風暴，于是斷開該樓層交換機與核心交換機的網絡連接。   

繼續在核心交換機后臺系統進行測試，發現它的CPU消耗率仍然很高，于是筆者懷疑核心交換機下面仍然有異常流量端口，經過仔細查詢，終于找到g1/2/9光纖端口流量也不正常，于是再次進入g1/2/9光纖端口視圖配置模式，執行“shutdown”命令，將g1/2/9光纖端口的運行狀態關閉，此時筆者發現核心交換機的CPU消耗率終于達到了正常的25%左右，與此同時，局域網中的其他故障點立即也能恢復正常的上網狀態了。

分析故障產生原因  

順著g1/2/1光纖端口、g1/2/9光纖端口的連接線路，筆者找到了兩臺數據流量異常的樓層交換機，通過Console控制端口登錄進入故障交換機后臺系統，同時使用ping命令依次測試每一個以太電口的連通狀態，結果發現“e0/12”、“e0/21”這兩個以太電口無法被正常ping通。于是使用“display interface e0/12”、“display interface e0/21”命令，分別查看這兩個端口的數據流量狀態信息時，發現它們的廣播包數據流量都比較多。經過更進一步的排查，筆者發現“e0/12”、“e0/21”這兩個以太電口下面分別連接了一個集線器，更為巧合的是，這兩個集線器全部集中放置在同一個辦公室中；

經過了解，筆者發現這家單位的客戶端系統平時需要通過不同的集線器，分別連接到兩個不同的虛擬工作子網中進行工作，最近這個辦公室由于安裝窗簾，網絡連接線路全部被臨時拔了下來，窗簾安裝好后，由于工作人員不懂線路連接，隨手將備用的網絡線纜將兩個分別獨立的兩個集線器也連在了一起，這么一來這兩個集線器、兩個樓層交換機以及核心交換機之間，無形之中就形成了網絡環路，最終造成整個局域網頻繁出現網絡訪問錯誤。   

找到故障原因后，筆者斷開了兩臺集線器之間的網絡連接線路，同時在核心交換機后臺系統執行“undo shutdown”命令，將g1/2/1光纖端口、g1/2/9光纖端口的運行啟用狀態恢復正常，這時整個局域網仍然能夠正常、穩定工作，至此網絡訪問頻繁出錯的故障現象就被徹底地解決了。

故障排查經驗總結   

平時我們在排查局域網故障現象時，往往先是觀察相關網絡設備的信號燈狀態是否正常，一旦看到不正常的話，最常見的解決辦法就是簡單地重新啟動一下網絡設備后臺系統，不管是交換機設備還是路由器設備，統統重新啟動，并且很多時候都會屢試不爽，可是這次這種辦法沒有能夠順利地解決問題。經過仔細排查，結果發現問題竟然是由于上網用戶隨意連接網絡線路造成的；

很明顯，為了杜絕相同故障現象的再次發生，網絡管理員應該加強對局域網的管理力度，禁止上網用戶隨意下掛交換機或集線器，如果確實由于工作需要必須連接交換機的，應該及時向網絡管理部門備案。該故障的排查過程，也給了我們一個很好的啟示，在遇到網絡故障時，應該首先了解故障發生之前的網絡變化情況，同時及時建立完善的網絡文件資料。

【51CTO.COM 獨家特稿，轉載請注明出處及作者！】