mtr 如何工作/使用 mtr 解读痛点

Question

我最近一直在尝试解决mtr网络拥塞的痛点。以下是示例mtr请求

示例 1

$ mtr --report -c 10 my.example.com 

HOST: ansh0l-Lenovo               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1                0.0%    10    1.3   5.2   1.3  22.4   8.0
  2.|-- 10.10.20.1                 0.0%    10    3.9   2.5   1.6   4.6   1.2
  3.|-- NSG-Static-*.*.*.*        10.0%    10    7.7   6.7   5.1  10.1   1.5
  4.|-- AES-Static-*.*.*.*        10.0%    10   46.3  48.5  46.2  53.8   2.6
  5.|-- s38895.sgw.equinix.com     0.0%    10   50.3  47.9  46.1  50.3   1.5
  6.|-- 203.83.223.2               0.0%    10   49.0  48.7  47.0  51.1   1.2
  7.|-- 203.83.223.23              0.0%    10   47.8  48.1  46.9  50.0   1.0
  8.|-- ec2-175-*-*-*.ap-sou       0.0%    10   47.7  49.0  47.6  55.8   2.5
  9.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

示例 2

$ mtr --report -c 100 my.example.com 
HOST: ansh0l-Lenovo               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1                2.0%   100    5.5   3.2   1.2  94.6   9.8
  2.|-- 10.10.20.1                 3.0%   100    4.3   3.9   1.5 160.5  16.3
  3.|-- NSG-Static-*.*.*.*         3.0%   100    9.9   8.1   4.3  99.0   9.8
  4.|-- AES-Static-*.*.*.*         3.0%   100   48.6  48.9  45.9 137.0   9.4
  5.|-- s38895.sgw.equinix.com     5.0%   100   46.7  49.6  45.5 155.6  11.5
  6.|-- 203.83.223.2               2.0%   100   52.4  53.0  46.5 213.3  20.8
  7.|-- 203.83.223.23              4.0%   100   49.1  50.0  46.2 145.6  11.5
  8.|-- ec2-175-*-*-*.ap-sou       5.0%   100   49.3  50.8  46.4 169.6  12.8
  9.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

问题：

1. 主机 n 处的丢包数是否 = 专门为主机 n 发送的数据包的丢包总数？假设发送到 HOST 7 的数据包将具有相同的先前跃点，这有多安全？

2. 在示例 1 中，在 HOST 3 和 4 处，丢包率相同 (10%)。假设所有数据包丢失都因此发生在节点 3 上是否安全？

3. 在示例 1 中，当 HOST 4 的丢包率为 10% 时，下一跳不应该也受到性能影响吗？如果我在其中一个中间节点有 10% 的丢包，那么它后面的节点也应该有一些丢包，对吗？

4. 在示例 2 中，一些节点具有更高的StDev。这些应该被解释为不可靠点吗？

Answer 1

1) 主机 n 的丢包数是否 = 专门为主机 n 发送的数据包的丢包总数？

是的，它们是专门针对该主机的。MTR 依赖于发送一个固定 TTL 的数据包，并期望收到一个“超时”ICMP 响应，它最初发送的 ICMP 回显将来自 TTL 超过的路由器。

假设发送到 HOST 7 的数据包将具有相同的先前跃点，这有多安全？

它非常安全，我不能代表所有网络，但它在跳间路由上非常不寻常，期望流量被路由到多条路径——它可能发生，但它更多的是例外而不是常态。

2) 在 Example1 中，在 HOST 3 和 4 处，丢包率相同（10%）。假设所有数据包丢失都因此发生在节点 3 上是否安全？

不，可能不是。如果节点 3 确实丢弃了转发的数据包，人们会期望看到此后所有其他跃点的导数丢失（因此在跃点 5、6、7、8 和 9 上丢失约 10%）。

3) 在示例 1 中。当 HOST 4 出现 10% 的数据包丢失时，下一跳不应该也受到性能影响吗？如果我在其中一个中间节点有 10% 的丢包，那么它后面的节点也应该有一些丢包，对吗？

是的，如果您收到的是真正的丢包。不幸的是，事情比这复杂得多。

4) 在 Example2 中，一些节点具有更高的 StDev。这些应该被解释为不可靠的点吗？

mtr 真的只能给你一个大概的数字。许多路由器将丢弃 ICMP 数据包作为服务质量机制的一部分（icmp 对其而言不如 tcp/udp 流量重要）。其他人可能会延迟交通，或两者兼而有之。

您真正可以说的是，发送该路由器应该响应的 ICMP 流量可能会导致性能不可靠，但您不能说其他类型的流量（如 TCP）也是如此。

总而言之，如果由于路由器中间跳导致到特定目的地的数据包真正丢失，您将看到 <= loss % 一直沿着未来的跃点。

如果您的目标跃点响应为 0% 丢失，则您没有丢弃数据包。

一些路由器故意丢弃它们负责响应的 ICMP 流量，因此您可能会得到仅限于该跃点的“额外丢失”。如果该跃点既执行某种形式的流量整形又真正丢失流量，那么事情就会变得非常混乱，因为您无法判断自己真正有多少损失。相反，您可以做的最好的事情是从未来的跳跃中获取最低的损失百分比，并说明它可能大约是您看到的损失百分比。