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

05-24

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

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

鏈路測試工具介紹

根據操作系統類型的不同，鏈路測試所使用的工具也有所不同。分別簡要介紹如下。

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

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

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

traceroute 命令行工具

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

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 ~]# traceroute -I 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）：最近一次的探測延遲值。
第五、六、七列（Avg、Best、Wrst）：分別是探測延遲的平均值、最小值和最大值。
第八列（StDev）：標準偏差。越大說明相應節點越不穩定。

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

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

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 無需安裝，直接解壓運行即可。操作方法非常簡單，說明如下：

如下圖所示，運行程序後，在 Host 欄位輸入目標伺服器域名或 IP（注意前面不要包含空格）。
點擊 Start 開始測試（開始測試後，相應按鈕變成了 Stop）。
運行一段時間後，點擊 Stop 停止測試。
其它選項說明：
- 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）：已成功接收的數據包數量。
第六、七、八、九列（Best 、Avg、Worst、Last）：分別是到相應節點延遲的最小值、平均值、最大值和最後一次值。
第八列（StDev）：標準偏差。越大說明相應節點越不穩定。

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

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

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

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

網路區域
鏈路負載均衡
結合Avg（平均值）和 StDev（標準偏差）綜合判斷
Loss%（丟包率）的判斷
關於延遲

網路區域

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

客戶端本地網路（本地區域網和本地網路提供商網路）：如前文鏈路測試結果示例圖中的區域 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 跳所示。

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

關於延遲

延遲跳變

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

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

ICMP 限速導致延遲增加

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

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

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

目標主機網路配置不當
ICMP 限速
環路
鏈路中斷

目標主機網路配置不當

示例數據：

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
正向鏈路測試（ping 和 mtr）
反向鏈路測試（ping 和 mtr）
測試結果分析

獲取本地網路對應公網 IP

在客戶端本地網路訪問 http://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地址庫ip.taobao.com 等網站查詢、獲取相應節點歸屬運營商及網路。

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