探究何種原因導緻網絡資料丢包嚴重

許多時候，我們可能都會碰到網絡連接配接時斷時續的故障現象，面對這種網絡故障，不少網絡管理者都會使用Ping指令對網絡連通性進行測試，測試結果表明此時的網絡傳輸線路資料丢包現象非常嚴重，那麼究竟是什麼因素導緻了資料丢包現象比較嚴重呢?是連接配接線路接觸不穩定?是網絡病毒?還是其他的潛在因素?

　　仔細對這類現象進行總結後，我們發現最容易造成資料丢包現象的因素就是網絡環路，畢竟在規模稍微大一點的區域網路環境中，網絡管理者很容易把交換機之間的端口連接配接錯誤，進而引起網絡環路現象，并且這種現象由于有比較強的隐蔽性，我們在排除這類故障的時候要是不留神的話很容易多走彎路!為了幫助各位高效解決資料丢包嚴重這類網絡故障，筆者現在就将自己曾經遭遇到的一則網絡環路故障排除過程貢獻出來，希望大家能從中擷取收益!

　　 故障現象

　　筆者所在機關的區域網路網絡使用的拓撲結構是星型百兆以太網結構，區域網路主機房中使用了一台Cisco品牌的三層路由交換機作為網絡的核心交換機，機關五層大樓中的每個樓層都組建了子網段，每個網段中的所有工作站都使用D-Link品牌的普通交換機作為集線裝置，并且各個樓層中的普通交換機通過雙絞線纜直接接入主機房中的核心交換機，并通過核心交換機直接通路Internet網絡。機關區域網路中同時安裝、配置了多台伺服器，例如有儲存機關重要資料資訊的檔案伺服器，有對外提供Web通路服務的Web伺服器，有提供重要資料下載下傳的FTP伺服器等。

　　平時機關各個子網段中的所有工作站都能正常通路Internet網絡，每個子網段中的工作站之間也能互相通路。可是有一天，某一子網段中的使用者通過手機向筆者反映情況說，他們所在的子網工作站通路Internet網絡時，有時正常有時不正常，并且同一子網段中的工作站之間互相進行Ping測試時，發現資料丢包現象非常嚴重;原以為這種故障僅是極個别現象，可誰曾想到，沒有多長時間，分布在多個網段中的許多使用者接二連三地向筆者反映情況，并且描述的故障現象基本相同。

　　連續的故障求援讓筆者再也坐不住了，筆者立即動身來到其中一個樓層，對該網段中的工作站進行上網測試，在上網過程中筆者發現網頁打開速度有時非常緩慢，幾分鐘也打不開一個頁面，有時速度很快，隻要輸入位址敲下Enter鍵後，網頁内容立即就顯示出來了，并且這種現象反反複複。在确認網絡故障的确存在後，筆者認為這種故障現象涉及多個網段，引起這種故障現象的原因很可能是交換機的連接配接端口出現了問題，于是筆者對交換機的連接配接端口進行了适當調整，并在調整之後及時進行了測試，可是區域網路中的故障現象依然存在。

　　重新傳回到故障工作站現場進行測試，筆者看到使用Ping指令可以Ping通區域網路中的部分工作站和伺服器，不過在Ping主機房中的核心交換機IP位址時，筆者發現存在明顯的資料丢包現象，并且網絡延遲時間也比較長。通過專業的網絡管理工具對主機房中的核心交換機進行參數配置檢查，筆者也沒有發現明顯的錯誤。

　　故障分析

　　雖然核心交換機的參數配置方面沒有找到可疑的地方，但是筆者還是深信問題出在核心交換機身上，畢竟多個子網同時出現相同的故障現象決不是偶然的。在排除了核心交換機參數配置因素後，筆者開始将懷疑重點轉移到該裝置的實體因素上了;首先，筆者仔細觀察了核心交換機控制台中各個信号燈的工作狀态，發現連接配接有雙絞線的所有端口對應的信号燈狀态都很正常。其次，筆者擔心網絡線纜沒有緊密地插入到核心交換機的各個端口中，于是不厭其煩地将所有的網絡線纜逐一拔下來，之後又将其重新插入到對應的交換機端口中，可是筆者的這番辛苦并沒有得到任何回報，區域網路中的資料丢包現象仍然十分嚴重，并且許多工作站還是不能正常通路Internet網絡中的内容。

　　那會不會是核心交換機的緩存遇到錯誤，導緻連接配接到該交換機裝置中的所有子網工作站都不能正常通路網絡内容呢?筆者腦海中總有這樣一種意識，認為交換機運作時間一長之後，其系統緩存十分容易出現溢出或其他軟體錯誤，這類錯誤常常會導緻區域網路網絡産生莫名其妙的故障現象;依照這樣的想法，筆者嘗試着切斷了核心交換機的電源，過了一段時間後，又重新接通該裝置的電源，以便讓其重新啟動，等待核心交換機系統啟動穩定之後，筆者再次嘗試了在故障工作站中進行上網測試，結果發現網絡通路還是時斷時續。

　　在排除了上面幾種因素後，筆者估計這種網絡故障應該不在交換機硬體部分，很可能是區域網路中的網絡病毒造成的。于是，筆者特意從網絡中下載下傳了專業分析工具Sniffer，通過該工具抓包分析網絡中的資訊包，發現有許多資訊包都不約而同來自相同的一個網卡裝置的MAC位址，而資訊包中發送的目的位址在區域網路中根本找不到，于是筆者立即下意識地懷疑可能是“熊貓燒香”之類蠕蟲病毒造成了網絡傳輸通道堵塞。難道目标網卡MAC位址對應的工作站真的被感染上了網絡蠕蟲病毒?

　　想到這一點，筆者立即通過網絡正常傳輸時建立的MAC位址與IP位址對應表，查找到該工作站來自區域網路二樓網段中的一台工作站，初步确認故障原因後，筆者立即将目标網卡MAC位址對應的工作站從特定網段中斷開連接配接，同時在該工作站系統中安裝了最新版本的防毒軟體，并對該工作站系統進行了全面、徹底地病毒清除操作，等到病毒清除任務結束後，筆者還真的看到了一些網絡蠕蟲病毒，原以為這些網絡蠕蟲病毒就是最終的“禍首”，可是當将該工作站重新接入到對應網段中後，區域網路的資料丢包故障現象還是沒有消失。

　　在萬般無奈之際，筆者決定對各個子網進行單獨測試檢查。于是筆者特意找來當初組建區域網路時使用的網絡拓撲結構圖，對照圖紙筆者想依次找出不同網段接入到核心交換機時所使用的端口，在進行這方面查找操作時，筆者偶然看到有一條網絡線纜竟然同時插入到核心交換機中的兩個端口中，很明顯這條網絡線纜使區域網路中形成了環路現象，而環路現象可能就是整個區域網路資料丢包嚴重的“罪槐禍首”。

　　為了驗證筆者的分析是否正确，筆者嘗試着将造成環路的那條線纜拔出後，立即從故障工作站中再次通路了Internet網絡，結果發現故障工作站打開網頁的速度很快;但筆者還是有點不放心，又跑到另外一個故障子網中，随意找了一台工作站進行上網測試，測試結果證明區域網路的所有故障全部已經消失，這表明區域網路的資料丢包故障已經被成功解決了。

　　故障探究

　　通過上面的分析，我們不難發現網絡環路其實就是引起區域網路所有子網不能正常通路的“禍首”，在區域網路環境中一旦有網絡環路現象存在時，那麼工作站對外發送的每一幀資訊都會在網絡通道中反複廣播，進而造成了廣播風暴現象，最終導緻區域網路傳輸通道嚴重被堵塞，那樣一來區域網路網絡就容易出現資料丢包現象。

　　在解決這類網絡故障時，筆者由于沒有及時了解到區域網路網絡中發生了一些變動，導緻在排除故障的過程中，始終沒有想到網絡環路竟是由于我們網絡管理者的疏忽引起的，進而導緻了筆者在解決故障的過程中多走了不少彎路。

　　仔細想來，要是在排除故障之前，筆者能夠事先詢問一下機關的其他網絡管理者，打聽一下最近網絡是否進行了改動的話，說不定就能很快找到故障原因了。是以，日後我們在解決類似網絡故障時，首先應該仔細了解一下故障之前網絡的變動情況，之後再按照正常思路進行排查。

　　當然，為了便于管理網絡，我們在組建區域網路網絡時，也應該及時建立了比較完善的區域網路組建檔案資料，具體内容可以包括IP及MAC對應表、網絡布線圖、網絡變動說明等，有了這些資料幫忙，任何網絡管理者都能在很短時間内解決各種網絡故障了。

本文轉自q狼的誘惑 51CTO部落格，原文連結：http://blog.51cto.com/liangrui/338794，如需轉載請自行聯系原作者