☰

为什么在我的 ISP 上 mtr 比 Traceroute 更可靠？

tag-icon • tag-icon ipv6 traceroute
为什么在我的 ISP 上 mtr 比 Traceroute 更可靠？

我的traceroute6结果被截断了，而结果mtr跨越了整个路径。为什么会出现这种情况呢？

mtr默认使用ICMP ECHO，就像跟踪路由一样。运行traceroutesudo不会改变结果。-M tcp或-M udp或 也没有-M icmp。

（注意，我故意测试“IP 的生产版本”。遗留的“实验版本”按预期工作:-)。

地铁

$ time mtr -n --report -c 1 google.co.uk
Start: Thu Aug 11 11:29:08 2016
HOST: localhost.localdomain       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- fdaa:bbcc:ddee:0:924d:4af  0.0%     1    5.7   5.7   5.7   5.7   0.0
  2.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  3.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  5.|-- 2a00:2380:3013:9000::8     0.0%     1   23.1  23.1  23.1  23.1   0.0
  6.|-- 2a00:2380:13::23           0.0%     1   23.2  23.2  23.2  23.2   0.0
  7.|-- 2a00:2380:2001:5000::d     0.0%     1   19.2  19.2  19.2  19.2   0.0
  8.|-- 2001:4860:0:1::1049        0.0%     1   13.0  13.0  13.0  13.0   0.0
  9.|-- 2001:4860:0:1::8f          0.0%     1   19.6  19.6  19.6  19.6   0.0
 10.|-- 2a00:1450:4009:809::2003   0.0%     1   24.0  24.0  24.0  24.0   0.0

real    0m6.229s
user    0m0.002s
sys 0m0.011s

跟踪路由6

$ time traceroute -6 -n google.co.uk
traceroute to google.co.uk (2a00:1450:4009:809::2003), 30 hops max, 80 byte packets
 1  fdaa:bbcc:ddee:0:924d:4aff:fe06:1c9  3.351 ms  3.324 ms  5.569 ms
 2  * * *
 3  * * *
 4  2a00:2302::1103:100:37  20.128 ms !X  20.118 ms !X  20.120 ms !X

real    0m0.221s
user    0m0.000s
sys 0m0.006s

跟踪路径6

Tracepath 与traceroute 类似，只是不需要超级用户权限并且没有花哨的选项。

它使用UDP端口或一些随机端口。

Tracepath6 是 Traceroute6 的良好替代品，也是 Linux 错误队列应用的经典示例。

$ time tracepath6 -n google.co.uk
 1?: [LOCALHOST]                        0.035ms pmtu 1488
 1:  fdaa:bbcc:ddee:0:924d:4aff:fe06:1c9                   4.101ms 
 1:  fdaa:bbcc:ddee:0:924d:4aff:fe06:1c9                   3.161ms 
 2:  no reply
 3:  2a00:2302::1103:100:36                               17.379ms asymm  5 
 4:  2a00:2302::1103:100:37                               17.222ms !A
     Resume: pmtu 1488 

real    0m5.068s
user    0m0.001s
sys 0m0.005s

运行之间的结果略有不同：有时未显示第 3 跳。第 3 跳或第 4 跳的地址也发生了变化（无论使用什么工具）；看起来使用了两条不同的路径。

当mtr以交互方式运行时，它最终能够找到跃点 3（尽管不是跃点 4）。该跳跃显示 80-90% 的损失。 （如 NANOG 列表中所述，需要专业的网络知识才能完全理解 mtr 等工具的输出:-)。

答案1

Traceroute 联机帮助页显示!X指示 ICMP 之一错误响应（除了所需的“超出 TTL”）。 traceroute一看到就放弃。看起来mtr更加坚固。

这是一个奇怪的案例。我不明白为什么当具有足够大 TTL 的数据包被简单地允许通过时，为什么要将“TTL 超出”响应替换为“管理禁止”。感谢您mtr容忍这种奇怪的事情:)。

在行程时间之后，可以打印一些附加注释：!H、!N 或 !P（主机、网络或协议无法访问）、!S（源路由失败）、!F（需要分段）、!X（管理性通信）禁止）、!V（主机优先级冲突）、!C（优先级截止有效）或 ! （ICMP 不可达代码）。如果几乎所有的探测都导致某种不可达，traceroute 将放弃并退出。

相关内容