許多時候，我們可能都會碰到網絡連接時斷時續的故障現象，面對這種網絡故障，不少網絡管理員都會使用Ping命令對網絡連通性進行測試，測試結果表明此時的網絡傳輸線路數據丟包現象非常嚴重，那么究竟是什么因素導致了數據丟包現象比較嚴重呢？是連接線路接觸不穩定？是網絡病毒？還是其他的潛在因素？ 恰好我們在賽迪網技術社區中發現了這樣一篇帖子《網絡數據丟包嚴重 線路環路是“禍首”》：

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

故障現象

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

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

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

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

故障分析

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

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

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

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

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

為了驗證筆者的分析是否正確，筆者嘗試著將造成環路的那條線纜拔出后，立即從故障工作站中再次訪問了Internet網絡，結果發現故障工作站打開網頁的速度很快；但筆者還是有點不放心，又跑到另外一個故障子網中，隨意找了一臺工作站進行上網測試，測試結果證明局域網的所有故障全部已經消失，這表明局域網的數據丟包故障已經被成功解決了。

故障探究

通過上面的分析，我們不難發現網絡環路其實就是引起局域網所有子網不能正常訪問的“禍首”，在局域網環境中一旦有網絡環路現象存在時，那么工作站對外發送的每一幀信息都會在網絡通道中反復廣播，從而造成了廣播風暴現象，最終導致局域網傳輸通道嚴重被堵塞，那樣一來局域網網絡就容易出現數據丟包現象。

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

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

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