mtr 命令详解

显示行号 | 选择喜欢的代码风格

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

mtr 命令（my traceroute）是一个命令行网络诊断工具，它提供 ping 和 traceroute 命令的功能。这是一个简单的跨平台工具，可打印有关网络数据包所经过的整个路由的信息，从主机系统到指定的目标系统。 mtr 命令比 traceroute 命令更具优势，因为它还会显示两个系统之间所有网络跃点的响应百分比和响应时间。

mtr 命令安装：

-bash/zsh: mtr: command not found
 
#Debian
apt-get install mtr

#Ubuntu
apt-get install mtr

#Alpine
apk add mtr

#Arch Linux
pacman -S mtr

#Kali Linux
apt-get install mtr

#CentOS
yum install mtr

#Fedora
dnf install mtr

#OS X
brew install mtr

#Raspbian
apt-get install mtr

#Docker
docker run cmd.cat/mtr mtr

#Windows
安装 WinMTR 
  或者
使用 BestTrace - https://www.ipip.net/product/client.html

#OpenSUSE
zypper install mtr

mtr 命令补充说明：

MTR 是一款强大的网络诊断工具，网络管理员使用 MTR 可以诊断和隔离网络问题，并且为上游 ISP 提供有用的网络状态报告。MTR 是传统 traceroute 命令的进化版，并且可以提供强大的数据样本，因为他集合了 traceroute 和 ping 这两个命令的精华。本文带您深入了解 MTR ，从数据如何生成，到如果正确理解报告样本并得出相应的结论。

网络诊断工具例如 ping traceroute mtr 都使用的 ICMP 包来测试 Internet 两点之间的网络连接状况。当用户使用 ping 命令 ping 网络上的主机后，ICMP 包将会发送到目的主机，然后在目的主机返回响应。这样，就可以得知本机到目的主机 ICMP 包传输所使用的往返时间。

Windows 下可以使用 WinMTR 工具

相对于其他命令仅仅收集传输路径或响应时间，MTR 工具会收集更多的信息，比如连接状态，连接可用性，以及传输路径中主机的响应性。由于这些额外的信息，我们建议您尽可能完整的展现 Internet 两个主机之间的网络连接信息。接下来我们讲述如何安装 MTR 软件，以及如何看懂这款软件的输出结果。

mtr 相关名词解释：

ICMP (Internet Control Message Protocol)

IP 协议族的一员，主要用于网络设备间发送错误指示信息, 一般不用于传输数据，常见部署在用户端网络程序中，诸如 traceroute 或 ping 等程序

TTL (Time To Live)

此处的 Time 表示的是次数，而不是时间，表达的是一个包在结束之前还能经过的跳数

Hop

跳数: 网络中两个端路径上的节点，路由器的数目

ISP (Internet Service Provider)

互联网服务提供商

mtr 命令语法：

mtr [-hvrctglspniu46] [--help] [--version] [--report] [--report-wide] [--report-cycles COUNT] [--curses] [--split] [--raw] [--no-dns] [--gtk] [--address IP.ADD.RE.SS] [--interval SECONDS] [--psize BYTES | -s BYTES] HOSTNAME [PACKETSIZE]

mtr 命令选项：

-F, --filename FILE        从文件中读取主机名
-4                         仅使用IPv4
-6                         仅使用IPv6
-u, --udp                  使用UDP代替ICMP回显
-T, --tcp                  使用TCP代替ICMP echo
-a, --address ADDRESS      将输出套接字绑定到ADDRESS
-f, --first-ttl NUMBER     设置启动什么TTL
-m, --max-ttl NUMBER       最大跳数
-U, --max-unknown NUMBER   最大未知主机
-P, --port PORT            TCP，SCTP或UDP的目标端口号
-L, --localport LOCALPORT  UDP的源端口号
-s, --psize PACKETSIZE     设置用于探测的数据包大小
-B, --bitpattern NUMBER    设置要在有效载荷中使用的位模式
-i, --interval SECONDS     ICMP回显请求间隔
-G, --gracetime SECONDS    等待响应的秒数
-Q, --tos NUMBER           IP标头中的服务字段类型
-e, --mpls                 显示来自ICMP扩展的信息
-Z, --timeout SECONDS      秒保持探针插座打开
-r, --report               使用报告模式输出
-w, --report-wide          输出范围广泛的报告
-c, --report-cycles COUNT  设置发送的ping数
-j, --json                 输出json
-x, --xml                  输出xml
-C, --csv                  输出逗号分隔值
-l, --raw                  输出原始格式
-p, --split                分割输出
-t, --curses               使用curses终端界面
   --displaymode MODE      选择初始显示模式
-n, --no-dns               不解析主机名
-b, --show-ips             显示IP号和主机名
-o, --order FIELDS         选择输出字段
-y, --ipinfo NUMBER        在输出中选择IP信息
-z, --aslookup             显示AS号
-h, --help                 显示此帮助并退出
-v, --version              输出版本信息并退出

mtr 命令参数：

目标 IP 或者目标域名

mtr 命令实例

简单使用，查看本地到 hexun.com 的路由连接情况：

mtr hexun.com

                                My traceroute  [v0.85]
dsp-2 (0.0.0.0)                                               Tue Jun  9 12:10:48 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                              Packets               Pings
 Host                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ???
 2. 11.219.78.45                             0.0%    23   10.2  20.3   1.9  51.9  17.4
 3. 11.219.79.154                            8.7%    23    3.8  37.0   2.4  92.6  22.2
 4. 11.211.191.146                           0.0%    23    1.2   7.6   0.8  34.2  10.5
 5. 116.251.104.185                          0.0%    23    1.2   1.2   0.9   1.6   0.0
 6. 123.56.34.5                              0.0%    23    1.7   2.5   1.6   7.5   1.3
 7. 106.38.196.253                          54.5%    23    3.1   3.2   3.0   3.2   0.0
 8. 36.110.246.137                           0.0%    23    3.5   3.5   3.4   3.9   0.0
 9. ???
10. 111.175.213.42                           0.0%    23   20.1  22.8  18.6  26.5   2.3
11. 119.97.254.214                          13.0%    23   20.4  20.9  20.2  26.2   1.2
12. 119.97.254.14                            0.0%    23   23.5  23.6  23.5  24.1   0.0
13. 119.97.154.126                           0.0%    23   20.2  20.3  20.1  21.5   0.2
14. ???
15. 119.97.159.10                            0.0%    22   23.1  23.1  23.1  23.2   0.0

-------------------------------
输出参数解释：
-------------------------------
第一列是IP地址
丢包率：Loss
已发送的包数：Snt
最后一个包的延时：Last
平均延时：Avg
最低延时：Best
最差延时：Wrst
方差（稳定性）：StDev

report - 使用 mtr -r hexun.com 来打印报告，如果不使用 -r 或 --report 参数 mtr 会不断动态运行。使用 report 选项， mtr 会向 hexun.com 主机发送 10 个 ICMP 包，然后直接输出结果。通常情况下 mtr 需要几秒钟时间来输出报告。mtr 报告由一系列跳数组成，每一跳意味着数据包通过节点或者路由器来达到目的主机。

清除报告中的输出，使用语法： $ mtr –rw -c [n] “domainname/IP” >”report-name”

mtr -rw -c 10 hexun.com >mtr-report-hexun

使用 -s 来指定 ping 数据包的大小：

mtr -r -s 50 hexun.com

100 bytes 数据包会用来发送测试，如果设置为负数，则每一次发送的数据包的大小都会是一个随机数。

指定发送数量 - 默认使用 -r 参数来生成报告，只会发送 10 个数据包，如果想要自定义数据包数量，可以使用 -c 参数

mtr -c 100 hexun.com

不进行主机解释 - 使用 -n 选项来让 mtr 只输出 IP，而不对主机 host name 进行解释

mtr -n github.com

显示数字IP地址 - 使用 -g 选项它将在 traceroute 报告中显示数字 IP 地址而不是主机名。如果需要同时保留 hostname 和 IP，则使用 -b 选项。

重新排列输出字段 - 语法： $ mtr -o “[Output Format]” “domainname/IP”。

$ mtr -o "LSDR NBAW JMXI" hexun.com

使用 TCP SYN 数据包或 UDP 数据报

$ mtr --tcp hexun.com
$ mtr --udp hexun.com

指定本地系统和远程计算机之间的最大跳数

$ mtr -m 35 216.58.223.78

打印 CSV / XML 输出

mtr --csv commandnotfound.cn
mtr --xml commandnotfound.cn

mtr 命令之：如何读懂并分析 MTR 报告

当我们研究 MTR 报告时候，最好找出每一跳的任何问题。除了可以查看两个服务器之间的路径之外，MTR 在它的七列数据中提供了很多有价值的数据统计报告。 Loss% 列展示了数据包在每一跳的丢失率。 Snt 列记录的多少个数据包被送出。使用 –report 参数默认会送出 10 个数据包。如果使用 –report-cycles=[number-of-packets] 选项，MTR 就会按照 [number-of-packets] 指定的数量发出 ICMP 数据包。

Last, Avg, Best 和 Wrst 列都标识数据包往返的时间，使用的是毫秒（ms）单位表示。 Last 表示最后一个数据包所用的时间， Avg 表示平均时间， Best 和 Wrst 表示最小和最大时间。在大多数情况下，平均时间（Avg）列需要我们特别注意。

最后一列 StDev 提供了数据包在每个主机的标准偏差。如果标准偏差越高，说明数据包在这个节点的延时越不相同。标准偏差会让您了解到平均延时是否是真的延时时间的中心点，或者测量数据受到某些问题的干扰。

例如，如果标准偏差很大，说明数据包的延迟是不确定的。一些数据包延迟很小（例如：25ms），另一些数据包延迟很大（例如：350ms）。当 10 个数据包全部发出后，得到的平均延迟可能是正常的，但是平均延迟是不能很好的反应实际情况的。如果标准偏差很高，使用最好和最坏的延迟来确定平均延迟是一个较好的方案。

在大多数情况下，您可以把 MTR 的输出分成三大块。根据配置，第二或第三跳一般都是您的本地 ISP，倒数第二或第三跳一般为您目的主机的 ISP。中间的节点是数据包经过的路由器。

mtr 报告核心的两个参数:

loss 丢包率
latency 延迟

mtr 确定丢包率

当分析 MTR 的输出时，您需要注意两点： loss 和 latency。首先，让我们讨论一下 loss。如果您在任何一跳上看到 loss 的百分比，这就说明这一跳上可能有问题了。当然，很多服务提供商人为限制 ICMP 发送的速率，这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输还是确定有丢包的现象？我们需要查看下一跳。如果下一跳没有丢包现象，说明上一条是人为限制的。如下示例：

root@commandnotfound.cn:~$ mtr --report www.google.com

HOST: example                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                50.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

在 mtr 此例中，第二跳发生了丢包现象，但是接下来几条都没任何丢包现象，说明第二跳的丢包是人为限制的。如果在接下来的几条中都有丢包，那就可能是第二跳有问题了。请记住：ICMP 包的速率限制和丢失可能会同时发生。如果发生包的丢失情况，我们要用最低百分比来衡量时间情况。为什么这么说呢？请看如下示例：

root@commandnotfound.cn:~$ mtr --report www.google.com

HOST: localhost                  Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1
5. 72.14.233.56                  50.0%   10    7.2   8.3   7.1  16.4   2.9
6. 209.85.254.247                40.0%   10   39.1  39.4  39.1  39.7   0.2
7. 64.233.174.46                 40.0%   10   39.6  40.4  39.4  46.9   2.3
8. gw-in-f147.1e100.net          40.0%   10   39.6  40.5  39.5  46.7   2.2

在 mtr 这个例子中，您可以看打第 3 跳和第 4 跳都有 60% 的丢包率，从接下来的几跳都有丢包现象，所以不像是人为限制 ICMP 速率的原因。但是最后几跳都是 40% 的丢包率，我们可以猜测到 60% 的丢包率除了网络糟糕的原因之前还有人为限制 ICMP。所以，当我们看到不同的丢包率时，通常要以最后几跳为准。

还有很多时候问题是在数据包返回途中发生的。数据包可以成功的到达目的主机，但是返回过程中遇到 “困难” 了。所以，当问题发生后，我们通常需要收集反方向的 MTR 报告。

此外，互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率，当出现短暂的 10% 丢包率时候，不必担心，应用层的程序会弥补这点损失。

读懂 mtr 网络延迟

除了可以通过 MTR 报告看到丢包率，我们还可以看到本地到目的主机之间的延时。因为不同的物理位置，延迟通常随着跳数的增加而增加。所以，延迟通常取决于节点之间的物理距离和线路质量。

例如，在同样的传输距离下，dial-up 连接比 cable modem 连接有更大的延迟。如下示例中显示 MTR 报告：

root@commandnotfound.cn:~$ mtr --report www.google.com

HOST: localhost                 Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7   0.2
5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7   0.2
6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7   0.4
7. 64.233.174.46                 0.0%    10  391.8 360.4 342.1 396.7   2.1
8. gw-in-f147.1e100.net          0.0%    10  392.0 360.4 342.1 396.7   1.2

在 mtr 这份报告中，从第三跳到第四跳的延迟猛增，直接导致了后面的延迟也很大。这可能是因为第四跳的路由器配置不当，或者线路很拥堵的原因。

然而，高延迟并不一定意味着当前路由器有问题。这份报告虽然看到第四跳有点问题，但是数据仍然可以正常达到目的主机并且返回给主机。延迟很大的原因也有可能是在返回过程中引发的。我这份报告我们看不到返回的路径，返回的路径可能是完全不同的线路，所以我们一般要进行双向测试了。

ICMP 速率限制也可能会增加延迟，如下：

root@commandnotfound.cn:~$ mtr --report www.google.com

HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

乍一看 mtr 结果，第 4 跳和第 5 跳直接的延迟很大。但是第 5 跳之后，延迟又恢复正常了。最后的延迟差不多为 40ms。像这种情况，是不影响实际情况的。因为可能仅仅是第 5 跳设备限制了 ICMP 传输速率的原因。

所以我们一般要用最后一跳的实际延迟为准！

常见的 MTR 报告类型

很多网络问题十分麻烦，并且需要上级网络提供商来帮助。然而，这里有很多常见的 MTR 报告所描述的网络问题。如果您正在经历一些网络问题，并且想诊断出原因，可以参考如下示例：

目的主机网络配置不当

在下面这个例子中，数据包在目的地出现了 100% 的丢包。乍一看是数据包没有到达，其实未必，很有可能是路由器或主机配置不当。

root@meiriyitie.com:~$ mtr --report www.google.com

HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net         100.0    10    0.0   0.0   0.0   0.0   0.0

MTR 报告数据包没有到达目的主机是因为目的主机没有发送任何应答。这可能是目的主机防火墙的原因，例如： iptables 配置丢掉 ICMP 包所致。

家庭或办公室路由器的原因

有时候家庭路由器的原因导致 MTR 报告看起来有点误导。

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

HOST: deleuze                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                   0.0%    10    2.2   2.2   2.0   2.7   0.2
  2. ???                          100.0    10    8.6  11.0   8.4  17.8   3.0
  3. 68.86.210.126                 0.0%    10    9.1  12.1   8.5  24.3   5.2
  4. 68.86.208.22                  0.0%    10   12.2  15.1  11.7  23.4   4.4
  5. 68.85.192.86                  0.0%    10   17.2  14.8  13.2  17.2   1.3
  6. 68.86.90.25                   0.0%    10   14.2  16.4  14.2  20.3   1.9
  7. 68.86.86.194                  0.0%    10   17.6  16.8  15.5  18.1   0.9
  8. 75.149.230.194                0.0%    10   15.0  20.1  15.0  33.8   5.6
  9. 72.14.238.232                 0.0%    10   15.6  18.7  14.1  32.8   5.9
 10. 209.85.241.148                0.0%    10   16.3  16.9  14.7  21.2   2.2
 11. 66.249.91.104                 0.0%    10   22.2  18.6  14.2  36.0   6.5

不要为 100% 的丢包率所吓到，这并不表明这里有问题。你可以看 mtr 打在接下来几跳是没有任何丢包的。

运营商的路由器没有正确配置

有时候您的运营商的路由器配置原因，导致 ICMP 包永远不能到达目的地，例如：

root@commandnotfound.cn:~$ mtr --report www.google.com

HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  6. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  7. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  8. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  9. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 10. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

当没有额外的路由信息时，将会显示问号（???），下面 mtr 例子也一样：

root@commandnotfound.cn:~$ mtr --report www.google.com

HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
   1. 63.247.74.43                 0.0%    10    0.3   0.6   0.3   1.2   0.3
   2. 63.247.64.157                0.0%    10    0.4   1.0   0.4   6.1   1.8
   3. 209.51.130.213               0.0%    10    0.8   2.7   0.8  19.0   5.7
   4. aix.pr1.atl.google.com       0.0%    10    6.7   6.8   6.7   6.9   0.1
   5. 172.16.29.45                 0.0%    10    0.0   0.0   0.0   0.0   0.0
   6. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0 
   7. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
   8. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
   9. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
  10. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0

有时候，一个错误配置的路由器，将会在一个环路中不断发送数据包，如下：

root@commandnotfound.cn:~$ mtr --report www.google.com

HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  6. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  7. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  8. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  9. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 10. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 11. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 12. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 13. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 14. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

通过 mtr 报告可以看打第 4 跳的路由器没有正确配置。如果这种状况发生了，您可以连接当地的网络管理员或 ISP 解决问题。

ICMP 速率限制

ICMP 速率限制可引起数据包的丢失。如果数据包在这一跳有丢失，但是下面 mtr 几条都正常，我们可以判断是 ICMP 速率限制的原因。如下：

root@commandnotfound.cn:~$ mtr --report www.google.com

 HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
   1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
   2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
   3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
   4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
   5. 72.14.233.56                 60.0%    10   27.2  25.3  23.1  26.4   2.9
   6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
   7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
   8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

这种状况是没关系的。ICMP 速率限制是一种常见的手段，这样可以减少网络数据的负载，让更重要的流量先通过。

mtr 超时

在很多种情况下会发生超时现象。例如：很多路由器可能会直接丢弃 ICMP 包，这时就会导致超时 （???） 。另外，也有可能在数据返回的路上出现了问题。

root@commandnotfound.cn:~$ mtr --report www.google.com

HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. ???                           0.0%    10    7.2   8.3   7.1  16.4   2.9
  6. ???                           0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

超时不一定是数据包被丢失。如上例，数据包还是安全的到达目的地并且返回。中间节点的超时可能是路由器配置丢弃 ICMP 包，或者 QoS 设置引起的原因，这个是没关系的。

MTR 命令使用小结：

#	描述
1	mtr 的功能是检查在目的地址有丢包的情况下，查出具体在哪一跳丢包，然后反馈给机房，机房再反馈给运营商；
2	看 mtr 的截图，先看最后的目的地址是否有丢包，若最后一跳没有丢包，说明线路 ok，若最后一跳有丢包，往下看；
3	再看在路由情况，第一次丢包发生在哪一跳，对应的查这一跳的丢包情况即可；
4	如果有条件建议双向测试抓取 mtr 返回结果，对比路由是否对等；
5	整理邮件发送机房联系本地网络服务商 ISP 或者云主机服务商请求技术支持。