ping 丟包或不通時鏈路測試說明

時間  2019-12-19
標籤 ping 不通 鏈路 測試 說明 简体版
原文   原文鏈接

ping 丟包或不通時鏈路測試說明

更新時間：2017-06-30 11:31html

當客戶端訪問目標服務器出現 ping 丟包或 ping 不通時，能夠經過 tracert 或 mtr 等工具進行鏈路測試來判斷問題來源。本文先介紹了進行鏈路測試的相關工具，而後對測試結果分析及測試步驟進行了說明。linux

鏈路測試工具介紹

根據操做系統類型的不一樣，鏈路測試所使用的工具也有所不一樣。分別簡要介紹以下。centos

Linux 環境下鏈路測試工具介紹

traceroute 命令行工具

traceroute 是幾乎全部 Linux 發行版本預裝的網絡測試工具，用於跟蹤 Internet 協議（IP）數據包傳送到目標地址時通過的路徑。ide

traceroute 先發送具備小的最大存活時間值（Max_TTL）的 UDP 探測數據包，而後偵遵從網關開始的整個鏈路上的 ICMP TIME_EXCEEDED 響應。探測從 TTL=1 開始，TTL 值逐步增長，直至接收到ICMP PORT_UNREACHABLE 消息。ICMP PORT_UNREACHABLE 消息用於標識目標主機已經被定位，或命令已經達到容許跟蹤的最大 TTL 值。工具

traceroute 默認發送 UDP 數據包進行鏈路探測。能夠經過 -I 參數來指定發送 ICMP 數據包用於探測。性能

用法說明：

traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] [ -s SRC_Addr ] [ -t TypeOfService ] [ -f flow ] [ -v ] [ -w WaitTime ] Host [ PacketSize ]

示例輸出：

[root@centos ~]# traceroute -I 223.5.5.5traceroute to 223.5.5.5 (223.5.5.5), 30 hops max, 60 byte packets 1    2 192.168.17.20 (192.168.17.20) 3.965 ms  4.252 ms  4.531 ms 3 111.1.20.41 (111.1.20.41) 6.109 ms  6.574 ms  6.996 ms 4 111.1.34.197 (111.1.34.197) 2.407 ms  2.451 ms  2.533 ms 5 211.138.114.25 (211.138.114.25) 1.321 ms  1.285 ms  1.304 ms 6 211.138.114.70 (211.138.114.70) 2.417 ms 211.138.114.66 (211.138.114.66) 1.857 ms 211.138.114.70 (211.138.114.70) 2.002 ms 7 42.120.244.194 (42.120.244.194) 2.570 ms  2.536 ms 42.120.244.186 (42.120.244.186) 1.585 ms 8 42.120.244.246 (42.120.244.246) 2.706 ms  2.666 ms  2.437 ms 9   10  public1.alidns.com (223.5.5.5) 2.817 ms  2.676 ms  2.401 ms

常見可選參數說明：

  • -d 使用Socket層級的排錯功能。

  • -f 設置第一個檢測數據包的存活數值TTL的大小。

  • -F 設置不要分段標識。

  • -g 設置來源路由網關，最多可設置8個。

  • -i 使用指定的網卡送出數據包。用於主機有多個網卡時。

  • -I 使用ICMP數據包替代 UDP 數據包進行探測。

  • -m 設置檢測數據包的最大存活數值TTL的大小。

  • -n 直接使用IP地址而非主機名稱（禁用 DNS 反查）。

  • -p 設置UDP傳輸協議的通訊端口。

  • -r 忽略普通的Routing Table，直接將數據包送到遠端主機上。

  • -s 設置本地主機送出數據包的IP地址。

  • -t 設置檢測數據包的TOS數值。

  • -v 詳細顯示指令的執行過程。

  • -w 設置等待遠端主機回包時間。

  • -x 開啓或關閉數據包的正確性檢驗。

mtr 命令行工具（建議優先使用）

mtr （My traceroute）也是幾乎全部 Linux 發行版本預裝的網絡測試工具。他把 ping和 traceroute 的功能併入了同一個工具中，因此功能更強大。

mtr 默認發送 ICMP 數據包進行鏈路探測。能夠經過 -u 參數來指定使用 UDP 數據包用於探測。

相對於 traceroute 只會作一次鏈路跟蹤測試，mtr 會對鏈路上的相關節點作持續探測並給出相應的統計信息。因此，mtr能避免節點波動對測試結果的影響，因此其測試結果更正確，建議優先使用。

用法說明：

mtr [-hvrctglspni46] [—help] [—version] [—report] [—report-cycles=COUNT] [—curses] [—gtk] [—raw] [—split] [—no-dns] [—address interface] [—psize=bytes/-s bytes] [—interval=SECONDS] HOSTNAME [PACKETSIZE]

示例輸出：

[root@centos ~]# mtr 223.5.5.5 My traceroute  [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 23:16:27 2016Keys: Help Display mode   Restart statistics   Order of fields   quit                                                  Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ??? 2. 192.168.17.20 0.0% 7 13.1 5.6 2.1 14.7 5.7 3. 111.1.20.41 0.0% 7 3.0 99.2 2.7 632.1 235.4 4. 111.1.34.197 0.0% 7 1.8 2.0 1.2 2.9 0.6 5. 211.138.114.25 0.0% 6 0.9 4.7 0.9 13.9 5.8 6. 211.138.114.70 0.0% 6 1.8 22.8 1.8 50.8 23.6 211.138.128.134 211.138.114.2 211.138.114.66 7. 42.120.244.186 0.0% 6 1.4 1.6 1.3 1.8 0.2 42.120.244.198 8. 42.120.244.246 0.0% 6 2.8 2.9 2.6 3.2 0.2 42.120.244.242 9. ???10. 223.5.5.5 0.0% 6 2.7 2.7 2.5 3.2 0.3

常見可選參數說明：

  • -r 或 —report：以報告模式顯示輸出。

  • -p 或 —split：將每次追蹤的結果分別列出來，而非如 —report統計整個結果。

  • -s 或 —psize：指定ping數據包的大小。

  • -n 或 —no-dns：不對IP地址作域名反解析。

  • -a 或 —address：設置發送數據包的IP地址。用於主機有多個IP時。

  • -4：只使用 IPv4 協議。

  • -6：只使用 IPv6 協議。

另外，也能夠在 mtr 運行過程當中，輸入相應字母來快速切換模式，好比：

  • ？或 h：顯示幫助菜單。

  • d：切換顯示模式。

  • n：切換啓用或禁用 DNS 域名解析。

  • u：切換使用 ICMP或 UDP 數據包進行探測。

返回結果說明：

默認配置下，返回結果中各數據列的說明：

  • 第一列（Host）：節點IP地址和域名。如前面所示，按n鍵能夠切換顯示。

  • 第二列（Loss%）：節點丟包率。

  • 第三列（Snt）：每秒發送數據包數。默認值是10，能夠經過參數 -c 指定。

  • 第四列（Last）：最近一次的探測延遲值。

  • 第5、6、七列（Avg、Best、Wrst）：分別是探測延遲的平均值、最小值和最大值。

  • 第八列（StDev）：標準誤差。越大說明相應節點越不穩定。

Windows 環境下鏈路測試工具介紹

TRACERT 命令行工具

TRACERT (Trace Route) 是 Windows 自帶的網絡診斷命令行實用程序，用於跟蹤 Internet 協議 (IP) 數據包傳送到目標地址時通過的路徑。 

TRACERT 經過向目標地址發送 ICMP 數據包來肯定到目標地址的路由。在這些數據包中，TRACERT 使用了不一樣的 IP「生存期」(TTL) 值。因爲要求沿途的路由器在轉發數據包前至少必須將 TTL 減小 1，所以 TTL 實際上至關於一個躍點計數器 (hop counter)。當某個數據包的 TTL 達到零 (0) 時，相應節點就會向源計算機發送一個 ICMP「超時」的消息。 

TRACERT 第一次發送 TTL 爲 1 的數據包，並在每次後續傳輸時將 TTL 增長 1，直到目標地址響應或達到 TTL 的最大值。中間路由器發送回來的 ICMP「超時」消息中包含了相應節點的信息。

用法說明：

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name

示例輸出：

C:\> tracert -d 223.5.5.5經過最多 30 個躍點跟蹤到 223.5.5.5 的路由 1    請求超時。 2 9 ms     3 ms    12 ms  192.168.17.20 3 4 ms     9 ms     2 ms  111.1.20.41 4 9 ms     2 ms     1 ms  111.1.34.197 5 11 ms       211.140.0.57 6 3 ms     2 ms     2 ms  211.138.114.62 7 2 ms     2 ms     1 ms  42.120.244.190 8 32 ms     4 ms     3 ms  42.120.244.238 9    請求超時。 10 3 ms     2 ms     2 ms  223.5.5.5跟蹤完成。

常見可選參數說明：

  • -d：指定不將地址解析爲主機名（禁用 DNS 反解）。

  • -h：maximum_hops，指定搜索目標地址時的最大躍點數。

  • -j： host-list，指定沿主機列表的鬆散源路由。

  • -w：timeout，由每一個回覆的 timeout 指定的等待毫秒數。

  • -R：跟蹤往返行程路徑(僅適用於 IPv6)。

  • -S：srcaddr，要使用的源地址(僅適用於 IPv6)。

  • -4：強制使用 IPv4。

  • -6：強制使用 IPv6。

  • target_host：目標主機域名或 IP 地址。

WinMTR 工具（建議優先使用）

WinMTR 是 mtr 工具在 Windows 環境下的圖形化實現，但進行了功能簡化，只支持 mtr部分參數的調整設置。WinMTR 默認發送ICMP 數據包進行探測，沒法切換。

WinMTR 能夠從其官方網站下載獲取。

和 mtr 同樣，相比 tracert，WinMTR 能避免節點波動對測試結果的影響，因此測試結果更正確。因此，在 WinMTR 可用的狀況下，建議優先使用 WinMTR 進行鏈路測試。

用法說明：

WinMTR 無需安裝，直接解壓運行便可。操做方法很是簡單，說明以下：

  1. 以下圖所示，運行程序後，在 Host 字段輸入目標服務器域名或 IP（注意前面不要包含空格）。

     

  2. 點擊 Start 開始測試（開始測試後，相應按鈕變成了 Stop）。

  3. 運行一段時間後，點擊 Stop 中止測試。

  4. 其它選項說明：

    • Copy Text to clipboard：將測試結果以文本格式複製到粘貼板。

    • Copy HTML to clipboard：將測試結果以 HTML 格式複製到粘貼板。

    • Export TEXT：將測試結果以文本格式導出到指定文件。

    • Export HTML：將測試結果以 HTML 格式導出到指定文件。

    • Options：可選參數，包括：

    • Interval（sec）：每次探測的間隔（過時）時間。默認爲 1 秒。

    • Ping size(bytes)： ping 探測所使用的數據包大小，默認爲 64 字節。、

    • Max hosts in LRU list： LRU 列表支持的最大主機數，默認值爲 128。

    • Resolve names：經過反查 IP 以域名顯示相關節點。

返回結果說明：

默認配置下，返回結果中各數據列的說明：

  • 第一列（Hostname）：節點 IP 或域名。

  • 第二列（Nr）：節點編號。

  • 第三列（Loss%）：節點丟包率。

  • 第四列（Sent）：已發送的數據包數量。

  • 第五列（Recv）：已成功接收的數據包數量。

  • 第6、7、8、九列（Best 、Avg、Worst、Last）：分別是到相應節點延遲的最小值、平均值、最大值和最後一次值。

  • 第八列（StDev）：標準誤差。越大說明相應節點越不穩定。

鏈路測試結果分析簡要說明

因爲 mtr（WinMTR）有更高的準確性。本文以其測試結果爲例，對鏈路測試結果的分析進行簡要說明。

後續說明，以以下鏈路測試結果示例圖爲基礎進行闡述：

對鏈路測試結果進行分析時，須要關注以下要點：

網絡區域

正常狀況下，從客戶端到目標服務器的整個鏈路，會顯著的包含以下區域：

  • 客戶端本地網絡（本地局域網和本地網絡提供商網絡）：如前文鏈路測試結果示例圖中的區域 A。若是該區域出現異常，若是是客戶端本地網絡相關節點出現異常，則須要對本地網絡進行相應排查分析。不然，若是是本地網絡提供商網絡相關節點出現異常，則須要向當地運營商反饋問題。

  • 運營商骨幹網絡：如前文鏈路測試結果示例圖中的區域 B。若是該區域出現異常，能夠根據異常節點 IP 查詢歸屬運營商，而後直接或經過阿里雲售後技術支持，向相應運營商反饋問題。

  • 目標服務器本地網絡（目標主機歸屬網絡提供商網絡）: 如前文鏈路測試結果示例圖中的區域 C。若是該區域出現異常，則須要向目標主機歸屬網絡提供商反饋問題。

鏈路負載均衡

如前文鏈路測試結果示例圖中的區域 D 所示。若是中間鏈路某些部分啓用了鏈路負載均衡，則 mtr 只會對首尾節點進行編號和探測統計。中間節點只會顯示相應的 IP 或域名信息。

結合Avg（平均值）和 StDev（標準誤差）綜合判斷

因爲鏈路抖動或其它因素的影響，節點的 Best 和 Worst 值可能相差很大。而 Avg（平均值） 統計了自鏈路測試以來全部探測的平均值，因此能更好的反應出相應節點的網絡質量。

而 StDev（標準誤差值）越高，則說明數據包在相應節點的延時值越不相同（越離散）。因此，標準誤差值可用於協助判斷Avg 是否真實反應了相應節點的網絡質量。例如，若是標準誤差很大，說明數據包的延遲是不肯定的。可能某些數據包延遲很小（例如：25ms），而另外一些延遲卻很大（例如：350ms），但最終獲得的平均延遲反而多是正常的。因此，此時 Avg 並不能很好的反應出實際的網絡質量狀況。

綜上，建議的分析標準是：

  • 若是 StDev 很高，則同步觀察相應節點的 Best 和 Wrst，來判斷相應節點是否存在異常。

  • 若是 StDev 不高，則經過 Avg來判斷相應節點是否存在異常。
    注：上述 StDev  「高」或者「不高」，並無具體的時間範圍標準。而須要根據同一節點其它列的延遲值大小來進行相對評估。好比，若是 Avg 爲 30ms，那麼，當 StDev 爲 25ms，則認爲是很高的誤差。而若是 Avg 爲 325ms，則一樣的StDev（25ms），反而認爲是不高的誤差。

Loss%（丟包率）的判斷

任一節點的 Loss%（丟包率）若是不爲零，則說明這一跳網絡可能存在問題。致使相應節點丟包的緣由一般有兩種：

  • 運營商基於安全或性能需求，人爲限制了節點的 ICMP 發送速率，致使丟包。

  • 節點確實存在異常，致使丟包。

能夠結合異常節點及其後續節點的丟包狀況，來斷定丟包緣由：

  • 若是隨後節點均沒有丟包，則一般說明異常節點丟包是因爲運營商策略限制所致。能夠忽略相關丟包。如前文鏈路測試結果示例圖中的第 2 跳所示。

  • 若是隨後節點也出現丟包，則一般說明異常節點確實存在網絡異常，致使丟包。如前文鏈路測試結果示例圖中的第 5 跳所示。

 另外，須要說明的是，前述兩種狀況可能同時發生。即相應節點既存在策略限速，又存在網絡異常。對於這種狀況，若是異常節點及其後續節點連續出現丟包，並且各節點的丟包率不一樣，則一般以最後幾跳的丟包率爲準。如前文鏈路測試結果示例圖所示，在第 五、6、7跳均出現了丟包。因此，最終丟包狀況，以第 7 跳的 40% 做爲參考。

關於延遲

延遲跳變

若是在某一跳以後延遲明顯陡增，則一般判斷該節點存在網絡異常。如前文鏈路測試結果示例圖所示，從第 5 跳以後的後續節點延遲明顯陡增，則推斷是第 5 跳節點出現了網絡異常。

不過，高延遲並不必定徹底意味着相應節點存在異常。如前文鏈路測試結果示例圖所示，第 5 跳以後，雖而後續節點延遲明顯陡增，但測試數據最終仍然正常到達了目的主機。因此，延遲大也有多是在數據回包鏈路中引起的。因此，最好結合反向鏈路測試一併分析。

ICMP 限速致使延遲增長

ICMP 策略限速也可能會致使相應節點的延遲陡增，但後續節點一般會恢復正常。如前文鏈路測試結果示例圖所示，第 3 跳有 100% 的丟包率，同時延遲也明顯陡增。但隨後節點的延遲立刻恢復了正常。因此判斷該節點的延遲陡增及丟包是因爲策略限速所致。

常見鏈路異常場景和測試報告

常見的鏈路異常場景及測試報告實例以下所示：

目標主機網絡配置不當

示例數據：

t@mycentos6 ~]# mtr —no-dns www.google.comMy traceroute  [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016Keys: Help Display mode   Restart statistics   Order of fields   quit                                                  Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ??? 2. ??? 3. 111.1.20.41 0.0% 10 521.3 90.1 2.7 521.3 211.3 4. 111.1.34.209 0.0% 10 2.9 4.7 1.6 10.6 3.9 5. 211.138.126.29 80.0% 10 3.0 3.0 3.0 3.0 0.0 6. 221.183.14.85 0.0% 10 1.7 7.2 1.6 34.9 13.6 7. 221.183.10.5 0.0% 10 5.2 5.2 5.1 5.2 0.0 221.183.11.5 8. 221.183.23.26 0.0% 10 5.3 5.2 5.1 5.3 0.1 9. 173.194.200.105 100.0% 10 0.0 0.0 0.0 0.0 0.0

在該示例中，數據包在目標地址出現了 100% 的丟包。乍一看是數據包沒有到達，其實頗有多是目標服務器相關安全策略（好比防火牆、iptables 等）禁用了 ICMP 所致，致使目的主機沒法發送任何應答。

因此，該場景須要排查目標服務器的安全策略配置。

ICMP 限速

示例數據：

[root@mycentos6 ~]# mtr —no-dns www.google.comMy traceroute  [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016Keys: Help Display mode   Restart statistics   Order of fields   quit                                                  Packets Pings Host Loss% Snt Last Avg Best Wrst StDev1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74. aix.pr1.atl.google.com        0.0% 10 6.7 6.8 6.7 6.9 0.15. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.96. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.27. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.38. gw-in-f147.1e100.net          0.0% 10 39.6 40.5 39.5 46.7 2.2

在該示例中，在第 5 跳出現了明顯的丟包，但後續節點均未見異常。因此推斷是該節點 ICMP 限速所致。

該場景對最終客戶端到目標服務器的數據傳輸不會有影響，因此，分析的時候能夠忽略。

環路

示例數據：

[root@mycentos6 ~]# mtr —no-dns www.google.comMy traceroute  [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016Keys: Help Display mode   Restart statistics   Order of fields   quit                                                  Packets Pings Host Loss% Snt Last Avg Best Wrst StDev1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74. aix.pr1.atl.google.com        0.0% 10 6.7 6.8 6.7 6.9 0.15. 72.14.233.56 0.0% 10 0.0 0.0 0.0 0.0 0.06. 72.14.233.57 0.0% 10 0.0 0.0 0.0 0.0 0.07. 72.14.233.56 0.0% 10 0.0 0.0 0.0 0.0 0.08. 72.14.233.57 0.0% 10 0.0 0.0 0.0 0.0 0.09 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0

在該示例中，數據包在第 5 跳以後出現了循環跳轉，致使最終沒法到達目標服務器。這一般是因爲運營商相關節點路由配置異常所致。

因此，該場景須要聯繫相應節點歸屬運營商處理。

鏈路中斷

示例數據：

t@mycentos6 ~]# mtr —no-dns www.google.comMy traceroute  [v0.75]mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016Keys: Help Display mode   Restart statistics   Order of fields   quit                                                  Packets Pings Host Loss% Snt Last Avg Best Wrst StDev1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74. aix.pr1.atl.google.com        0.0% 10 6.7 6.8 6.7 6.9 0.15. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.06. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.07. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.08. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.09 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0

在該示例中，數據包在第 4 跳以後就沒法收到任何反饋。這一般是因爲相應節點中斷所致。建議結合反向鏈路測試作進一步確認。

該場景須要聯繫相應節點歸屬運營商處理。

鏈路測試步驟

一般狀況下，鏈路測試流程以下鏈路測試流程圖所示：

相關步驟詳細說明以下：

獲取本地網絡對應公網 IP

在客戶端本地網絡訪問 ip.taobao.com 等網站，以下圖，獲取本地網絡對應的公網 IP。

 

正向鏈路測試（ping 和 mtr）

從客戶端向目標服務器作 ping 和 mtr 鏈路測試：

  • 從客戶端向目標服務器域名或 IP 作持續的 ping 測試（建議至少 ping 100 個數據包），記錄測試結果。

  • 根據客戶端操做系統環境的不一樣，使用 WinMTR 或 mtr，設置測試目的地址爲目標服務器域名或IP，而後進行鏈路測試，記錄測試結果。

反向鏈路測試（ping 和 mtr）

進入目標服務器系統內部，作反向 ping 和 mtr 鏈路測試

  • 從目標服務器向前述步驟 1 獲取的客戶端 IP作持續的 ping 測試（建議至少 ping 100 個數據包），記錄測試結果。

  • 根據目標服務器操做系統環境的不一樣，使用 WinMTR 或 mtr，設置測試目的地址爲前述步驟 1 獲取的客戶端 IP，而後進行鏈路測試，記錄測試結果。

測試結果分析

參閱前述說明，對測試結果進行分析。確認異常節點後，訪問 ip.taobao.com 等網站查詢、獲取相應節點歸屬運營商及網絡。

若是是客戶端本地網絡相關節點出現異常，則須要對本地網絡進行相應排查分析。若是是運營商相關節點出現異常，則須要直接或聯繫阿里雲售後技術支持向相應運營商反饋問題。

 

更多資源

      原文連接地址：https://help.aliyun.com/knowledge_detail/40573.html#mtr

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程