单跳高丢包率的 mtr 输出

网络工程 路由 ipv4 故障排除 地铁
2021-07-28 15:23:31

我正在调查最终用户对访问我帮助维护的网站的性能不佳的投诉。

我有这两个 mtr 输出给最终用户，第一个来自站点：

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 198.199.92.253                    0.0%   200    7.3   4.2   0.9  89.6   8.0
 2. 69.22.130.37                      0.0%   200    0.4   2.5   0.3  51.4   8.0
 3. 69.22.143.170                    42.5%   200    1.3   2.0   1.1  47.9   4.9
 4. 69.22.143.165                     0.0%   200    2.3   6.4   1.6  56.9   9.7
 5. 206.223.116.86                    0.0%   200    2.5   3.0   1.8  14.1   1.5
 6. 64.125.24.1                       0.0%   200    3.0   6.9   2.2  65.7   9.9
 7. 64.125.26.230                     0.0%   200   56.3  61.4  55.6 119.0  10.0
 8. 64.125.24.33                      0.5%   200   76.4  78.9  76.0 116.1   7.1
 9. 64.125.29.38                      0.0%   200   73.9  77.5  73.4 238.8  13.4
10. 64.125.31.181                     0.5%   200  160.0 159.4 156.2 181.4   4.3
11. 64.125.32.93                      0.0%   200  156.9 157.8 155.9 217.0   6.8
12. 62.253.174.190                    0.0%   200  166.0 166.5 165.6 172.8   1.2
13. 62.253.175.217                    0.0%   200  162.1 163.1 161.7 200.4   4.2
14. 213.105.159.194                   0.0%   200  163.8 165.0 163.4 241.2   8.3
15. 81.97.112.218                     0.0%   200  164.7 166.5 164.5 220.0   7.4
16. ???

第二个来自我的网络：

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 216.16.235.1                      0.0%   115    0.4   0.4   0.3   0.6   0.1
 2. 216.16.232.37                     0.0%   115    0.9   0.9   0.6  18.8   1.7
 3. 216.16.255.141                    0.0%   115    0.8   0.7   0.6   1.1   0.1
 4. 216.16.255.130                    0.0%   114    1.0   1.0   0.8   1.4   0.1
 5. 24.153.3.141                      0.0%   114    1.9   3.6   1.5   6.5   1.2
 6. 64.71.241.97                      0.0%   114    3.4   5.3   3.3   7.4   1.1
 7. ???
 8. 64.124.128.193                   34.5%   114   18.9  19.2  18.7  39.0   2.3
 9. 64.125.21.74                      0.0%   114   19.2  20.4  18.9  49.9   5.0
10. 64.125.29.38                      0.0%   114   19.3  23.1  19.2  48.3   7.6
11. 64.125.27.186                     0.9%   114  105.2 106.1 105.1 137.8   3.2
12. 64.125.32.93                      0.0%   114  106.3 107.1 106.1 163.3   5.8
13. 62.253.174.190                    0.0%   114  181.8 123.5 115.8 206.3  20.9
14. 62.253.175.217                    0.0%   114  113.8 114.8 113.6 144.3   4.2
15. 213.105.159.194                   0.0%   114  115.3 115.9 115.2 163.5   4.6
16. 81.97.112.218                     0.0%   114  113.3 114.4 113.2 140.7   4.5
17. ???

我应该如何解释那些具有 MASSIVE 数据包丢失的跃点？我倾向于认为这些跃点正在进行某种非对称路由，并且其中一条路径拥塞。

这会对最终用户造成任何问题吗？

3个回答

MTR 使用 ICMP，由于它可能会被滥用以产生问题（高 CPU、浪费带宽、DoS 等），因此它在 Internet 上经常受到速率限制。

当您看到这样的输出时，通常这表明 ICMP 的速率限制已到位。通过快速网络搜索，我找到了有关使用 MTR 的文档。虽然它不是官方的，但它看起来不错（至少通过快速扫描）并提供了使用 MTR 可能会发现的一些问题的示例。

由于@YLearn 已经在路由器上写了 ICMP ratelimiting 并且丢包很可能是原因，因为对 ICMP 请求的回复是在 CPU 中完成的，而数据包的转发通常是在 ASIC 中完成的。所以这根本不需要成为问题。

几年前，Richard Steenbergen 编写了一个非常好的解释跟踪路由（和 MTR）输出的指南。他在 NANOG 上做了一个很好的演示。

我先说是的，您提到的路由可能是其中的一部分。这将是从那一跳返回到您的主机的路由，该路由正在采取其他人没有的拥塞路径。

我的家伙在想：如果这是那个特定路由器上数据平面的问题，我希望在这一跳之后看到所有跳的数据包丢失 - 但你没有看到。

当数据包的 TTL 达到 0 时，由路由器上的控制平面生成返回给发送主机的 ICMP 响应。我的猜测是该特定路由器上的控制平面 CPU（在您执行跟踪的时间点）被高度利用，并且它会在 MTR 的超时值之外向您发送一些响应。

其它你可能感兴趣的问题
上一篇当 WAN 上有流量时，什么会导致高延迟？ 下一篇如何验证UDP端口是否打开？