3

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 :-).

Improve this question
3

The traceroute manpage says !X indicates one of the ICMP error responses (other than the desired "TTL exceeded"). traceroute gives up when it sees one. It looks like mtr is more robust.

It's a weird case. I can't think why you'd replace a "TTL exceeded" response with "administratively prohibited", when packets with a large enough TTL are simply let through. Thanks to mtr for tolerating this weirdness :).

After the trip time, some additional annotation can be printed: !H, !N, or !P (host, network or protocol unreachable), !S (source route failed), !F (fragmentation needed), !X (communication administratively prohibited), !V (host precedence violation), !C (precedence cutoff in effect), or ! (ICMP unreachable code ). If almost all the probes result in some kind of unreachable, traceroute will give up and exit.

Improve this answer
  • 1
    !X is a common response when the packets have been blocked by a firewall. – Michael Hampton Aug 13 '16 at 4:55
  • Yah. The reason it's weird is the firewall's only quibble is expired TTL. Otherwise, I'm being allowed to send these packets. If they have a higher TTL they're not blocked by the firewall. Packets with expired TTL generate the !X, which identifies the firewall address just as well as the expected "TTL exceeded". I can imagine a firewall config that does this but not why you would ever implement it! I wonder if it is caused by the endpoint of a tunnel (which transits over an ipv4 net). – sourcejedi Aug 13 '16 at 6:42
  • I was referring not to your firewall, but a firewall elsewhere on the Internet. The firewalls on Red Hat based systems default to returning administratively prohibited for denied traffic. – Michael Hampton Aug 13 '16 at 6:43
  • I know it's not my firewall, I'm not sure where I was unclear about this :). I mean my ISP is allowing me to send these UDP packets to google.com. My ISP is not blocking me from sending the UDP packets to google.com, but that's how traceroute6 (understandably) interprets the response, and why it decides there's no point continuing the trace beyond the weird firewall. What my ISP is apparently doing is prohibiting me from sending UDP packets to google.com if the TTL expires at a specific hop. I mean what's the threat, does hop 4 have a buggy IP stack that's allergic to the number zero? – sourcejedi Aug 13 '16 at 8:38
  • Never said I was surprised that a firewall uses "communication administratively prohibited" to indicate blocked traffic. Those words all make sense (& I know the behaviour is extant and common). – sourcejedi Aug 13 '16 at 8:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.