Por que o mtr é mais confiável que o traceroute no meu provedor?

Question

Meus resultados traceroute6 são truncados, enquanto os resultados de mtr abrangem todo o caminho. Por que isso aconteceria?

mtr usa ICMP ECHO por padrão , assim como traceroute . Executar o traceroute em sudo não altera o resultado. Nem -M tcp ou -M udp ou -M icmp .

(Note que estou testando deliberadamente a "versão de produção do IP". A "versão experimental" herdada funciona como esperado: -).

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

Os resultados variam ligeiramente entre as execuções: às vezes o salto 3 não é mostrado. Os endereços do hop 3 ou 4 também mudam (independentemente da ferramenta usada); parece que dois caminhos diferentes são usados.

Quando mtr é executado de forma interativa, é possível localizar o salto 3 (embora não seja o salto 4). Esse salto mostra 80-90% de perda. (Como observado na lista NANOG, é necessário ter conhecimento especializado em rede para entender completamente a saída de ferramentas como mtr: -).

    

Answer 1

A página de manual do traceroute diz que !X indica uma das respostas do erro ICMP (além do "TTL excedido" desejado). traceroute desiste quando vê um. Parece que mtr é mais robusto.

É um caso estranho. Não consigo imaginar por que você substituiria uma resposta "TTL ultrapassada" por "proibida administrativamente", quando os pacotes com um TTL grande o suficiente são simplesmente liberados. Obrigado a mtr por tolerar essa estranheza:).

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.