traceroute e mtr: Rastreando Caminhos de Rede e Encontrando o Salto Lento

2026-06-05 Tempo de leitura: Cerca de 9 min Dificuldade: Intermediário+

O Que Você Vai Aprender

• Como usar traceroute para mapear o caminho (quais roteadores seus pacotes atravessam)
• Como usar mtr para medir continuamente perda e latência por salto e isolar o segmento problemático
• Como ler * * * e perda em saltos intermediários corretamente em vez de julgá-los erroneamente

O Que o traceroute Realmente Faz?

Conclusão: Ele envia pacotes com TTL crescente a partir de 1 e reconstrói o caminho um salto por vez a partir das mensagens ICMP Time Exceeded que cada roteador retorna.

Todo pacote IP carrega um contador TTL (Time To Live): quantos roteadores mais ele pode cruzar. Cada roteador decrementa o TTL em 1, e um pacote cujo TTL chega a 0 é descartado - o roteador envia uma mensagem ICMP Time Exceeded de volta ao remetente.

O traceroute explora isso.

1. Envie um pacote com TTL=1 -> o primeiro roteador descarta e responde -> salto 1 revelado
2. Envie TTL=2 -> o segundo roteador responde -> salto 2 revelado
3. Continue aumentando o TTL até alcançar o destino

Ele envia 3 sondas por salto por padrão, então cada linha mostra três tempos de ida e volta (RTT).

$ traceroute example.com

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.512 ms  0.498 ms  0.471 ms
 2  10.0.0.1 (10.0.0.1)  4.231 ms  4.118 ms  4.090 ms
 3  * * *
 4  93.184.216.34 (93.184.216.34)  12.043 ms  11.998 ms  12.110 ms

* * * Significa que Algo Está Quebrado?

Conclusão: Normalmente não. Um roteador simplesmente escolheu não responder; se saltos além dele ainda respondem, o caminho está funcionando.

* * * significa "sem resposta a nenhuma das 3 sondas." As causas comuns são:

• O roteador suprime respostas de TTL-exceeded (firewall / política)
• Ele bloqueia sondas UDP (traceroute no Linux usa UDP por padrão)
• Atingiu um limite de taxa de resposta

Se você suspeita que UDP está sendo bloqueado, mude o método de sondagem.

# ICMP Echo (mesmo tipo de pacote que ping)
$ sudo traceroute -I example.com

# TCP SYN para porta 443 (mais proximo do trafego HTTPS real)
$ sudo traceroute -T -p 443 example.com

Quais Opções do traceroute Importam?

Conclusão: Comece com -n (pular DNS para velocidade), -T -p (sondar via TCP) e -m (max hops).

# Numerico, max 20 saltos, uma sonda por salto - varredura rapida
$ traceroute -n -m 20 -q 1 example.com

Se as resoluções DNS reversas estão tornando o processo lento, adicione -n primeiro.

Como o mtr É Diferente do traceroute?

Conclusão: traceroute é um snapshot único do caminho; mtr continua fazendo ping em cada salto do caminho e atualiza estatísticas de perda e latência em tempo real.

Problemas de rede oscilam. Um único traceroute não consegue capturar o caso intermitente. O mtr combina traceroute (descoberta de caminho) com ping (medição continua) e monitora cada salto continuamente.

$ mtr example.com

                             Packets               Pings
 Host                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                 0.0%    20    0.5   0.6   0.4   1.2   0.2
 2. 10.0.0.1                 0.0%    20    4.2   4.3   4.0   6.1   0.5
 3. 203.0.113.1             10.0%    20   18.0  19.4  17.2  41.0   5.1
 4. 93.184.216.34            0.0%    20   12.0  12.1  11.9  12.4   0.1

O significado das colunas:

• Loss%: proporção de sondas sem resposta naquele salto
• Snt: sondas enviadas
• Last / Avg / Best / Wrst: último / médio / mínimo / máximo RTT (ms)
• StDev: variação do RTT (maior = menos estável)

Como Você Lê a Perda no mtr?

Conclusão: Perda em um salto intermediário que volta a 0% no salto final é perda falsa da limitação de taxa ICMP. Apenas perda que persiste até o salto final é real.

Esta é a maior armadilha do mtr e sua lição mais importante. Na saída acima, o salto 3 mostra 10.0% de perda, porém o salto final 4 volta a 0.0%.

Roteadores frequentemente desprioritizam ou limitam as respostas de TTL-exceeded endereacadas a eles mesmos. Então os 10.0% do salto 3 significam apenas "salto 3 descartou algumas de suas próprias respostas" - o tráfego em si passa direto.

Em resumo, observe onde a perda começa e permanece até o fim. Descarte perda que desaparece depois.

Como Você Identifica o Segmento Lento?

Conclusão: Se o Avg salta em um salto e permanece alto pelo resto, esse segmento é a fonte de latência. Um pico que volta é apenas processamento atrasado de resposta, sem impacto real.

A latência se lê da mesma forma que a perda.

• Avg salta em um salto e permanece alto para cada salto posterior -> esse segmento (salto anterior -> este salto) é a fonte real de latência
• Apenas Wrst sobe em um salto enquanto Avg permanece baixo -> aquele roteador simplesmente atrasou sua resposta; não é latência real do caminho

# Modo relatorio: enviar 10 ciclos, depois imprimir resultados finais (para logs / tickets)
$ mtr -rwzbc 10 example.com

Significado das opções:

• -r / --report: imprimir resultados agregados uma vez em vez da tela interativa
• -w: saída ampla (não truncar hostnames)
• -z: mostrar o número AS de cada salto (qual rede de provedor é)
• -b: mostrar tanto hostname quanto IP
• -c N: número de ciclos a enviar (padrão 10)
• -n: pular resolução de nomes (mais rápido)

traceroute vs mtr: qual usar

Conclusão: Use traceroute para verificar o caminho uma vez, e mtr para isolar continuamente onde a perda ou latência ocorre. Anexe a saída de relatório do mtr ao reportar um problema.