My traceroute6
results are truncated, while the results from mtr
span the whole path. Why would this happen?
mtr uses ICMP ECHO by default, just like traceroute. Running traceroute under sudo
does not change the result. Nor does -M tcp
or -M udp
or -M icmp
.
(Note I am deliberately testing the "production version of IP". The legacy "experimental version" works as expected :-).
mtr
$ 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
traceroute6
$ 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
tracepath6
tracepath is similar to traceroute, only does not require superuser privileges and has no fancy options.
It uses UDP port port or some random port.
tracepath6 is [a] good replacement for traceroute6 and [a] classic example of application of Linux error queues.
$ 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
Results vary slightly between runs: sometimes hop 3 is not shown. The addresses of hop 3 or 4 also happen to change (regardless of the tool used); it looks like two different paths are used.
When mtr
is run interactively, it's eventually able to find hop 3 (though not hop 4). That hop shows 80-90% loss. (As noted on the NANOG list, expert networking knowledge is required to fully understand the output of tools like mtr :-).