ping 丟包現象的發生非常普遍，但是廣大網友對為何ping 丟包卻不是非常清楚，看了下面的文章，相信您會有收穫！
ping丟包的原因及解決方法 篇1
故障現象：公司有一台型號為清華同方TP200的 WEB服務器，操作系統安裝順利，IIS服務也配置無誤，可是在訪問此台服務器網站卻時斷時續。
分析解決：首先使用Ping命令測試，發現不定時的有數據包丟失的現象，初步認為是物理層的原因。重做網線的RJ45頭後，故障依舊，換根網線也不行。懷疑是網卡接口或者交換機端口的問題。經查看網卡驅動無誤，網卡接口也沒有任何異常。再查看交換機端口，發現與服務器連接的交換機端口工作指示燈在綠與黃之間閃爍，這説明端口工作不正常。使用超級終端登錄交換機，查看此端口的參數，發現此端口是工作在100Mbyte/s全雙工模式，回到服務器前查看本地連接狀態，網卡是工作在10Mbyte/s全雙工模式。交換機的端口與網卡的傳輸速率和雙工模式不一致。將網卡工作模式改為100Mbyte/s全雙工模式後測試，一切正常，故障解決。
ping丟包的原因及解決方法 篇2
從家裏測試寬帶網連接的丟包是一項非常困難的工作。丟包可以發生在從你的計算機到你在互聯網上正在連接的目的地之間的線路上的任何一個地方。引起丟包的原因包括:網絡阻塞、路由器或者交換機超過工作負荷、信號往返時間緩慢以及服務提供商或者託管你訪問的網站的公司使用的通信優先等級。
沒有主動測量實際重複傳輸的TCP流量(對於家庭寬帶網連接來説，這類產品太昂貴了)，很難確定是否真的發生了重複傳輸。你指出的機制ping和跟蹤路由對於幫助家庭用户確定互聯網上哪裏的速度慢是最有用的工具。Ping測量你的計算機和你要連接的IP地址之間的信號往返時間。跟蹤路由是測量路由器在你的計算機和你正在跟蹤的路由的IP地址之間的通道的反應時間。
使用Ping
使用Ping測量丟包的最佳方法是向一個IP地址發送大量的Ping命令，然後檢查沒有應答的那些Ping命令。如果你快速地發出了50次Ping命令，
你可以檢查沒有沒有應答的次數，並把沒有應答的次數作為丟包。沒有應答的次數超過5%可能就值得擔心了。
在一台計算機上，在命令提示符後面輸入如下命令就可以完成這個任務:
Ping -n 50(IP地址或者域名，如)這個命令中的“-n”開關告訴發送ping命令的次數，“50”是發送的次數。
然後，你將得到一個測試總結。這個總結將包括丟失的數量和百分比:
地址Ping的統計結果:
包: 發送 = 6, 接收 = 6, 丟失 = 0 (0%)
大約往返時間以毫秒(ms)顯示:
最小 = 26ms, 最大 = 29ms, 平均 = 27ms
如果你看到平均往返時間較高(超過100ms)，這也會降低你的網絡下載速度。
設法消除某些引起丟包的網絡某些部分的故障的一種方法是在通道的各個部分進行ping測試。我首先開始進行測試的地方是本地的“缺省網關”。這是你所有的數據傳輸到網絡上經過的第一個路由器。如果在這一部分的丟包率很高，那麼問題就在你的服務提供商的網絡上。
在Windows命令提示符後面輸入“ipconfig”命令你就可以發現你的缺省路由器的地址。這個結果顯示如下:
以太網接口本地區域連接:
具體連接的DNS後綴:
IP地址. . . . . . :
子網掩碼 . . . . . :
缺省網關 . . . :
你在這裏要查看的是缺省網關的IP地址。在上述例子中就。
使用跟蹤路由
在Windows命令提示符後面使用跟蹤路由命令就可以實施跟蹤路由。在Windows XPZH中這個命令是:tracert (IP地址或者主機名)
雖然結果不能向你顯示丟包，但是，可以向你顯示在路徑中路由器反應速度減慢的情況。
這個輸出結果將顯示所有的路由器的反應時間。下面是一個例子:
5 ms 2 ms 3 ms []
10 ms 6 ms 7 ms
9 ms 7 ms 7 ms
6 ms 7 ms 7 ms []
7 ms 7 ms 8 ms []
7 ms 7 ms 7 ms []
10 ms 7 ms 8 ms []
10 ms 9 ms 11 ms []
9 ms 10 ms 15 ms []
9 ms 10 ms 10 ms []
29 ms 28 ms 29 ms []
30 ms 29 ms 29 ms []
* * * Request timed out.
* * * Request timed out.
28 ms 28 ms 29 ms []
如果你看到在路徑中跟蹤路由往返時間有超過100ms(十分之一秒)的，這就可能引起網絡上傳輸的時間減慢。
從上述例子中，你可以看到數據在很多不同的網絡(XO, Qwest, ABC)上傳輸。這是互聯網美妙的一部分。不利的方面是一個用户無法解決反應時間減慢的問題。最佳的出發點就是確認你和你的服務提供商之間沒有出現丟包。
ping丟包的原因及解決方法 篇3
兩個idc機房託管的服務器之間通訊不暢，經查，兩個機房間的丟包率在8%左右。這樣的丟包率很容易引起tcp連接失敗，由於網絡在線業務異常重要，不得有片刻的停機時間。刻不容緩，馬上處理。
一、先判斷丟包發生在那裏。從辦公室的計算機分別ping 兩個機房的服務器、然後是網關，通過觀察輸出進行比較，發現問題在望京機房。在用路由跟蹤的方式測試，結論也是一樣。
二、去現場排查。檢查網段類服務器之間，服務器與交換機之間，以及交換機之間的網絡通訊情況，發ping 包，沒有丟包，但從網內ping 外部任何地址，都有丟包現象出現，路由跟蹤有時不成功。這些情況可以表明網段內的通訊是完全正常的。接下來要做的事情就是測試網關的狀態。網關是一個cisco 6509交換機，是網通自己管理，我方的交換機通過一條雙絞線與cisco 6509相連，它是所有服務器的外聯接口。通過技術手段，已經知道上聯交換機的上聯端口是Fa0/41。
1、從網段內的某些服務器ping網關，發現丟包。
2、從外網的某台計算機ping 這個網關，沒有丟包發生。
3、從外網的某些計算機執行到這個網關的路由跟蹤，情況正常。
4、用外網遠程的交換機ping 小包，情況正常。
５、從網段內的交換機ping 小包，發現丟包。
有上面的測試結果可以得出結論：是我方的交換機與網通交換機（我方服務器的網關）間的鏈路有故障。由於我們的網絡服務不能中斷，網通機房的人建議晚間訪問量少的時候重新做一條線或重壓網線兩端的水晶頭。前幾天我方為擴容在機架上施工，因此有可能把線纜碰了。已經是中午了，肚子儘管餓了，但還是有點不甘心，再搗鼓一下看能不能找出點什麼來。於是我搬來梯子，爬上去看接近天花板的交換機的指示燈狀態。居然有一個端口指示燈黃綠交替一閃一閃的，仔細一看，是某個交換機的41號端口，而且網線上標明這條線是整個網段的上聯線，即與網關相連的那條線，和先前測試出來的端口是一致的。可能問題就是在這個交換機上了，趕快連上console線，登錄上這個交換機，用命令 # show int f0/41 查看41號端口的輸出，嘿嘿！居然變成半雙工了，再查看其他一些端口的雙工情況，均是自適應，再去問IDC 機房的人，確認網關哪個連接端口的雙工配置，網關的端口為全雙工。好，馬上進入配置模式，# config t , int f0/41 ,# duplex full 就把交換機的41號端口設置成全雙工了，馬上生效，保存配置；然後再爬梯子看41號端口指示燈的狀態，變成綠色，這基本表明故障已經排除了。現在，開始從內外來測試丟包的情況了，經測試一切恢復正常。
原因分析：端口速率不匹配是引起丟包的最直接的原因。而引起端口速率變成半雙工的原因可能是網絡閃斷引起的，比如網關那端的端口速率變化，而我方交換機的端口是自適應的，因此在協商後就變成半雙工了。
