在 Linux 上使用 MTR 命令示例结合 Ping 和 Traceroute

MTR 代表 My Traceroute。

它是一个强大的网络诊断工具，结合了Ping和Traceroute命令的强大功能。

它使管理员能够诊断和隔离网络错误并提供有用的网络状态报告。

在本文中，我们将解释如何安装、使用和分析 MTR 命令提供的报告。

MTR 通过逐渐增加 TTL 值来发送 ICMP 数据包以查找源和给定目的地之间的路由。

1.安装

在 debian 或 Ubuntu 系统上使用以下命令：

$ sudo apt-get install mtr

在 centos 和 fedora 系统上执行以下命令：

$ yum install mtr

2. 对域执行 mtr

MTR 在两种模式下工作，图形模式 (X11) 和基于文本的模式 (ncurses)。默认情况下，mtr 命令以 X11 模式运行。

$ mtr google.com

上面的命令将打开一个 GUI 窗口，并显示结果。

3. 使用 –curses 启动文本模式

使用 –curses 选项在终端模式下运行 mtr。

$ mtr --curses google.com

                     Packets               Pings
 Host                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. mblaze.hilink     0.0%    20    3.2   2.7   2.1   3.8   0.5
 2. 10.228.129.9      0.0%    20  187.7  61.8  41.6 187.7  31.3
 3. 10.228.149.14     0.0%    20  112.1  60.2  33.2 112.1  17.8
 4. 116.202.226.145   0.0%    20   57.9  63.2  35.2 147.6  24.4
 5. 116.202.226.21    0.0%    20   35.4  70.4  35.4 211.8  48.6
 6. 72.14.219.94      0.0%    20   58.9  74.6  43.4 231.2  44.2
 7. 72.14.233.204     0.0%    20   46.9  69.8  40.3 222.5  41.9
 8. 72.14.239.20      0.0%    20   94.1 259.2  68.8 3436. 748.2
 9. 209.85.244.111    0.0%    20   86.4  97.5  72.1 232.2  34.3
10. google.com        0.0%    19  387.9 132.5  71.8 387.9  84.9

以上将在交互模式下连续运行。

在交互模式下，结果将反映每个主机的当前往返时间。从上面的示例中，数据包经过“mblaze.hilink”（我的本地路由器），然后经过一系列“跃点”，到达目的地。

跃点是互联网中的路由器或节点，数据包通过这些路由器或节点到达目的地。

4. 使用 –no-dns 省略反向 DNS

MTR 通过使用反向 DNS 查找来查找每个路由器/节点的主机名。如果您想避免进行反向 DNS 查找，请使用 –no-dns 选项。

$ mtr --curses --no-dns google.com

                       Packets               Pings
 Host                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.1       0.0%     2    3.0   2.9   2.9   3.0   0.1
 2. 10.228.129.9      0.0%     2   58.6  49.6  40.7  58.6  12.7
 3. 10.228.149.14     0.0%     2   46.1  46.8  46.1  47.6   1.0
 4. 116.202.226.145   0.0%     2   61.8  61.6  61.3  61.8   0.3
 5. 116.202.226.17    0.0%     2   42.7  39.9  37.0  42.7   4.0
 6. 72.14.215.234     0.0%     2   47.1  43.9  40.7  47.1   4.5
 7. 72.14.232.110     0.0%     2   56.9  60.7  56.9  64.4   5.3
 8. 72.14.239.22      0.0%     2  111.5  95.0  78.5 111.5  23.3
 9. 209.85.244.23     0.0%     2  126.0 102.4  78.8 126.0  33.4
10. 209.85.223.113    0.0%    10   76.4  92.7  75.4 157.3  29.5
11. 74.125.200.102    0.0%     1   78.4  78.4  78.4  78.4   0.0

5.使用-report在报告模式下执行mtr

除了在交互模式下运行 MTR，您可以使用 –report 在报告模式下运行它。在报告模式下，mtr 将运行周期数（默认为 10），然后打印统计信息并退出。此模式可用于生成有关网络质量的统计信息。

$ mtr --no-dns --report google.com

HOST: lakshmanan                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%    10    2.5   3.0   2.4   4.2   0.6
  2.|-- 10.228.129.9               0.0%    10  235.0  74.4  34.0 235.0  67.9
  3.|-- 10.228.149.14              0.0%    10  154.8  65.5  38.7 154.8  34.8
  4.|-- 116.202.226.145            0.0%    10   60.9  66.9  48.2 102.4  15.4
  5.|-- 116.202.226.17             0.0%    10   54.1  65.1  36.0 194.5  46.8
  6.|-- 72.14.215.234              0.0%    10   44.5  78.8  39.2 252.7  64.5
  7.|-- 72.14.232.110              0.0%    10   55.7  66.4  39.1 179.8  41.8
  8.|-- 66.249.94.72               0.0%    10   68.9  90.3  68.9 133.6  18.6
  9.|-- 72.14.233.105              0.0%    10   68.8  76.3  68.8  92.2   7.3
 10.|-- 173.194.38.162             0.0%    10   88.7 107.3  72.2 293.1  65.8

在上面的例子中，mtr 运行了 10 个周期并收集了统计信息。用户可以使用 -c 选项更改周期数。

了解MTR报告

除了提供有关源和目的地之间路径的信息之外，MTR 还提供有关连接持久性的有价值的统计数据。

• Lost% – 显示每一跳的数据包丢失百分比。
• Snt – 显示正在发送的数据包数量。
• Last – 发送的最后一个数据包的延迟。
• Avg – 所有数据包的平均延迟。
• Best - 显示到此主机的数据包的最佳往返时间（最短 RTT）。
• Wrst – 显示到此主机的数据包的最差往返时间（最长 RTT）。
• StDev – 为每个主机提供延迟的标准偏差。

即使“平均”看起来不错，也要看看标准差。如果标准偏差很高，则可能表明“平均”因某些测量误差或波动太大而出现偏差。在这种情况下，请查看 Best and Wrst 延迟以确保平均值良好。

分析MTR报告

1.验证丢包

在提供“速率限制”ICMP 流量的服务中存在一种常见的做法。这可以提供丢包的假象，而实际上没有丢包。要验证丢失是真实的还是由于速率限制，请检查下一跳的“Loss%”。如果它显示 0.0%，那么您可以确定报告的“Loss%”是由于 ICMP 速率限制而不是实际损失。

 10.|-- 209.85.250.237             0.0%    10   85.6  97.5  76.0 172.0  27.2
 11.|-- 209.85.250.203            100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- 74.125.135.138             0.0%    10   77.2 107.3  77.2 219.5  43.5

在上面的输出中，虽然它显示 100.0% Loss 在 hop 10 和 11 之间，但下一个 hop 12 报告了 0.0% 的数据包丢失，这意味着在 hop 11 上报告的 Loss 只是由于 ICMP 速率限制。

如果丢失持续超过 1 跳，则可能存在一些数据包丢失。另请注意，速率限制和数据包丢失可能同时发生。在这种情况下，将序列中的最低损失百分比作为实际损失。

2. 不正确的目标主机网络

 13.|-- 4.69.168.254               0.0%    10  293.3 304.7 276.0 441.0  48.5
 14.|-- 4.69.161.105              10.0%    10  287.5 291.7 261.2 393.6  40.0
 15.|-- 4.69.137.50                0.0%    10  412.2 299.2 266.9 412.2  48.6
 16.|-- 4.69.134.146              10.0%    10  260.5 281.8 260.3 320.1  22.0
 17.|-- 4.69.134.129              10.0%    10  294.7 303.5 268.0 397.8  41.8
 18.|-- 4.69.132.177              10.0%    10  287.8 341.6 262.7 470.4  77.4
 19.|-- 4.71.162.50               10.0%    10  280.8 276.0 257.8 323.2  21.3
 20.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

从上面的例子中，看起来数据包没有到达目的地。但它确实到达了目的地。这可能是由于主机或防火墙规则配置不当而丢弃了 ICMP 数据包。

3. 超时和返回路由问题

有时，路由器会丢弃 ICMP，它会显示为 ??? 在输出上。或者，返回路线也可能存在问题。

9.|-- 209.85.244.25              0.0%    10  260.6 147.0  78.1 260.6  75.3
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- 74.125.200.100             0.0%    10   84.8 112.4  75.6 234.4  63.9

在上面的示例中，第 10 跳的路由器要么没有响应 ICMP，要么数据包的返回路由出现问题。