使用 MTR 诊断网络问题 | 每日一贴
验证数据包丢失
在分析WinMTR/MTR输出结果时，您需要查看两件事情：丢包和延迟。首先，我们来讨论丢包。如果您在任何一个节点看到有掉包，这可能表示这个特定的路由节点有问题。然而，有些服务提供商会限制WINMTR/MTR工具发送的ICMP传输。这会对数据包丢失造成错觉，但事实上并未丢包。要确认您看到的数据包丢失是否是由于服务提供商限制造成的，您可以查看随后的一跳路由节点。如果该跳显示丢失0%，那么您可以肯定 是ICMP限制，实际未丢包。 看下面的例子：
在这种情况下，从第一跳到第二跳的丢包可能是由于第二跳路由ICMP限制导致的。因为剩余的8个路由节点都没有丢包。这种情况下，采取掉包最少的节点作为它实际的丢包率。
再考虑一个例子：
在这种情况下，你会看到第三跳和第四跳之间有60%的丢包。您可以假设这是由于路由设备限制导致的丢包。然而，您可以看到最后一跳是显示40%的丢包。但产生不同的丢包结果时，始终采用最后一跳的丢包率。
有些丢包可能产生在路由返回的时候。数据包可以正确无误地到达目的地，但未正常返回。这也会计算在丢包率中，但您从WinMTR/MTR结果报告中很难分辨。因此，在任何时候您都需要同时收集两个方向的WinMTR/MTR结果报告。
读懂网络延迟
除了可以通过 MTR 报告看到丢包率，我们还可以看到本地到目的主机之间的延时。因为不同的物理位置，延迟通常随着跳数的增加而增加。所以，延迟通常取决于节点之间的物理距离和线路质量。
例如，在同样的传输距离下，dial-up连接比cable modem连接有更大的延迟。如下示例中显示 MTR 报告：
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 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
在这份报告中，从第三跳到第四跳的延迟猛增，直接导致了后面的延迟也很大。这可能是因为第四跳的路由器配置不当，或者线路很拥堵的原因。
然而，高延迟并不一定意味着当前路由器有问题。这份报告虽然看到第四跳有点问题，但是数据仍然可以正常达到目的主机并且返回给主机。延迟很大的原因也有可能是在返回过程中引发的。我这份报告我们看不到返回的路径，返回的路径可能是完全不同的线路，所以我们一般要进行双向测试了。
ICMP 速率限制也可能会增加延迟，如下：
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 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
乍一看，第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% 的丢包率所吓到，这并不表明这里有问题。你可以看打在接下来几跳是没有任何丢包的。
运营商的路由器没有正确配置
有时候您的运营商的路由器配置原因，导致 ICMP 包永远不能到达目的地，例如：
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. ??? 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@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. 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@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. 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
通过报告可以看打第4跳的路由器没有正确配置。如果这种状况发生了，您可以连接当地的网络管理员或ISP解决问题。
ICMP 速率限制
ICMP 速率限制可引起数据包的丢失。如果数据包在这一跳有丢失，但是下面几条都正常，我们可以判断是 ICMP 速率限制的原因。如下：
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 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 速率限制是一种常见的手段，这样可以减少网络数据的负载，让更重要的流量先通过。
超时
在很多种情况下会发生超时现象。例如：很多路由器可能会直接丢弃 ICMP 包，这时就会导致超时（???）。
另外，也有可能在数据返回的路上出现了问题。
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. ??? 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 设置引起的原因，这个是没关系的。
