仔細對這類現象進行總結後，我們發現最容易造成資料丟包現象的因素就是網路環路，畢 竟在規模稍微大一點的區域網環境中，網路管理員很容易把交換機之間的埠連線錯誤，從而引起網路環路現象，並且這種現象由於有比較強的隱蔽性，我們在排除 這類故障的時候要是不留神的話很容易多走彎路！為了幫助各位高效解決資料丟包嚴重這類網路故障，筆者現在就將自己曾經遭遇到的一則網路環路故障排除過程貢 獻出來，希望大家能從中獲取收益！
故障現象
平時單位各個子網段中的所有工作站都能正常訪問internet網路，每個子網段中 的工作站之間也能互相訪問。可是有一天，某一子網段中的使用者通過手機向筆者反映情況說，他們所在的子網工作站訪問internet網路時，有時正常有時不 正常，並且同一子網段中的工作站之間相互進行ping測試時，發現資料丟包現象非常嚴重；原以為這種故障僅是極個別現象，可誰曾想到，沒有多長時間，分布 在多個網段中的許多使用者接二連三地向筆者反映情況，並且描述的故障現象基本相同。
連續的故障求援讓筆者再也坐不住了，筆者立即動身來到其中乙個樓層，對該網段中的工 作站進行上網測試，在上網過程中筆者發現網頁開啟速度有時非常緩慢，幾分鐘也打不開乙個頁面，有時速度很快，只要輸入位址敲下回車鍵後，網頁內容立即就顯 示出來了，並且這種現象反反覆覆。在確認網路故障的確存在後，筆者認為這種故障現象涉及多個網段，引起這種故障現象的原因很可能是交換機的連線埠出現了 問題，於是筆者對交換機的連線埠進行了適當調整，並在調整之後及時進行了測試，可是區域網中的故障現象依然存在。
重新返回到故障工作站現場進行測試，筆者看到使用ping命令可以ping通區域網 中的部分工作站和伺服器，不過在ping主機房中的核心交換機ip位址時，筆者發現存在明顯的資料丟包現象，並且網路延遲時間也比較長。通過專業的網路管 理工具對主機房中的核心交換機進行引數配置檢查，筆者也沒有發現明顯的錯誤。
故障分析
雖然核心交換機的引數配置方面沒有找到可疑的地方，但是筆者還是深信問題出在核心交 換機身上，畢竟多個子網同時出現相同的故障現象決不是偶然的。在排除了核心交換機引數配置因素後，筆者開始將懷疑重點轉移到該裝置的物理因素上了；首先， 筆者仔細觀察了核心交換機控制面板中各個訊號燈的工作狀態，發現連線有雙絞線的所有埠對應的訊號燈狀態都很正常。其次，筆者擔心網路線纜沒有緊密地插入 到核心交換機的各個埠中，於是不厭其煩地將所有的網路線纜逐一拔下來，之後又將其重新插入到對應的交換機埠中，可是筆者的這番辛苦並沒有得到任何回 報，區域網中的資料丟包現象仍然十分嚴重，並且許多任務作站還是不能正常訪問internet網路中的內容。
那會不會是核心交換機的快取遇到錯誤，導致連線到該交換機裝置中的所有子網工作站都 不能正常訪問網路內容呢？筆者腦海中總有這樣一種意識，認為交換機執行時間一長之後，其系統快取十分容易出現溢位或其他軟體錯誤，這類錯誤常常會導致局域 網網路產生莫名其妙的故障現象；依照這樣的想法，筆者嘗試著切斷了核心交換機的電源，過了一段時間後，又重新接通該裝置的電源，以便讓其重新啟動，等待核 心交換機系統啟動穩定之後，筆者再次嘗試了在故障工作站中進行上網測試，結果發現網路訪問還是時斷時續。
想到這一點，筆者立即通過網路正常傳輸時建立的mac位址與ip位址對應表，查詢到 該工作站來自區域網二樓網段中的一台工作站，初步確認故障原因後，筆者立即將目標網絡卡mac位址對應的工作站從特定網段中斷開連線，同時在該工作站系統中 安裝了最新版本的防毒軟體，並對該工作站系統進行了全面、徹底地病毒查殺操作，等到病毒查殺任務結束後，筆者還真的看到了一些網路蠕蟲病毒，原以為這些網 絡蠕蟲病毒就是最終的「禍首」，可是當將該工作站重新接入到對應網段中後，區域網的資料丟包故障現象還是沒有消失。
在萬般無奈之際，筆者決定對各個子網進行單獨測試檢查。於是筆者特意找來當初組建局 域網時使用的網路拓撲結構圖，對照圖紙筆者想依次找出不同網段接入到核心交換機時所使用的埠，在進行這方面查詢操作時，筆者偶然看到有一條網路線纜竟然 同時插入到核心交換機中的兩個埠中，很明顯這條網路線纜使區域網中形成了環路現象，而環路現象可能就是整個區域網資料丟包嚴重的「罪槐禍首」。
為了驗證筆者的分析是否正確，筆者嘗試著將造成環路的那條線纜拔出後，立即從故障工 作站中再次訪問了internet網路，結果發現故障工作站開啟網頁的速度很快；但筆者還是有點不放心，又跑到另外乙個故障子網中，隨意找了一台工作站進 行上網測試，測試結果證明區域網的所有故障全部已經消失，這表明區域網的資料丟包故障已經被成功解決了。
故障**
通過上面的分析，我們不難發現網路環路其實就是引起區域網所有子網不能正常訪問的「 禍首」，在區域網環境中一旦有網路環路現象存在時，那麼工作站對外傳送的每一幀資訊都會在網路通道中反覆廣播，從而造成了廣播風暴現象，最終導致區域網傳 輸通道嚴重被堵塞，那樣一來區域網網路就容易出現資料丟包現象。
在解決這類網路故障時，筆者由於沒有及時了解到區域網網路中發生了一些變動，導致在排除故障的過程中，始終沒有想到網路環路竟是由於我們網路管理員的疏忽引起的，從而導致了筆者在解決故障的過程中多走了不少彎路。
仔細想來，要是在排除故障之前，筆者能夠事先詢問一下單位的其他網路管理員，打聽一下最近網路是否進行了改動的話，說不定就能很快找到故障原因了。所以，日後我們在解決類似網路故障時，首先應該仔細了解一下故障之前網路的變動情況，之後再按照常規思路進行排查。
當然，為了便於管理網路，我們在組建區域網網路時，也應該及時建立了比較完善的區域網組建檔案資料，具體內容可以包括ip及mac對應表、網路佈線圖、網路變動說明等，有了這些資料幫忙，任何網路管理員都能在很短時間內解決各種網路故障了。
Linux UDP嚴重丟包問題的解決
測試系統在linux上的效能發現丟包率極為嚴重，發210000條資料，丟包達110000之巨，丟包率超過50 同等情形下windows上測試，僅丟幾條資料。形勢嚴峻，必須解決。考慮可能是因為協議棧buffer太低所致，於是先看看預設情況 sysctl a grep net.core 發現net.co...
Linux UDP嚴重丟包問題的解決
測試系統在linux上的效能發現丟包率極為嚴重，發210000條資料，丟包達110000之巨，丟包率超過50 同等情形下windows上測試，僅丟幾條資料。形勢嚴峻，必須解決。考慮可能是因為協議棧buffer太低所致，於是先看看預設情況 sysctl a grep net.core 發現net.co...
網路丟包監控指令碼
前段搞了乙個根據丟包權重判斷是否傳送報警通知的乙個指令碼，相互學習學習 cat checkuser.sh bin bash export path usr local sbin usr local bin sbin bin usr sbin usr bin root bin log time dat...