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

2026-06-05 Tempo de leitura: Cerca de 9 min Dificuldade: Intermediate

O Que Voce Vai Aprender

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

O Que o traceroute Realmente Faz?

Conclusao: Ele envia pacotes com TTL crescente a partir de 1 e reconstroi 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 e 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 ate alcancar o destino

Ele envia 3 sondas por salto por padrao, entao cada linha mostra tres 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 Esta Quebrado?

Conclusao: Normalmente nao. Um roteador simplesmente escolheu nao responder; se saltos alem dele ainda respondem, o caminho esta funcionando.

* * * significa "sem resposta a nenhuma das 3 sondas." As causas comuns sao:

• O roteador suprime respostas de TTL-exceeded (firewall / politica)
• Ele bloqueia sondas UDP (traceroute no Linux usa UDP por padrao)
• Atingiu um limite de taxa de resposta

Se voce suspeita que UDP esta sendo bloqueado, mude o metodo 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 Opcoes do traceroute Importam?

Conclusao: 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 resolucoes DNS reversas estao tornando o processo lento, adicione -n primeiro.

Como o mtr E Diferente do traceroute?

Conclusao: traceroute e um snapshot unico do caminho; mtr continua fazendo ping em cada salto do caminho e atualiza estatisticas de perda e latencia em tempo real.

Problemas de rede oscilam. Um unico traceroute nao consegue capturar o caso intermitente. O mtr combina traceroute (descoberta de caminho) com ping (medicao 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%: proporcao de sondas sem resposta naquele salto
• Snt: sondas enviadas
• Last / Avg / Best / Wrst: ultimo / medio / minimo / maximo RTT (ms)
• StDev: variacao do RTT (maior = menos estavel)

Como Voce Le a Perda no mtr?

Conclusao: Perda em um salto intermediario que volta a 0% no salto final e perda falsa da limitacao de taxa ICMP. Apenas perda que persiste ate o salto final e real.

Esta e a maior armadilha do mtr e sua licao mais importante. Na saida acima, o salto 3 mostra 10.0% de perda, porem o salto final 4 volta a 0.0%.

Roteadores frequentemente desprioritizam ou limitam as respostas de TTL-exceeded endereacadas a eles mesmos. Entao os 10.0% do salto 3 significam apenas "salto 3 descartou algumas de suas proprias respostas" - o trafego em si passa direto.

Em resumo, observe onde a perda comeca e permanece ate o fim. Descarte perda que desaparece depois.

Como Voce Identifica o Segmento Lento?

Conclusao: Se o Avg salta em um salto e permanece alto pelo resto, esse segmento e a fonte de latencia. Um pico que volta e apenas processamento atrasado de resposta, sem impacto real.

A latencia se le da mesma forma que a perda.

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

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

Significado das opcoes:

• -r / --report: imprimir resultados agregados uma vez em vez da tela interativa
• -w: saida ampla (nao truncar hostnames)
• -z: mostrar o numero AS de cada salto (qual rede de provedor e)
• -b: mostrar tanto hostname quanto IP
• -c N: numero de ciclos a enviar (padrao 10)
• -n: pular resolucao de nomes (mais rapido)

traceroute vs mtr: qual usar

Conclusao: Use traceroute para verificar o caminho uma vez, e mtr para isolar continuamente onde a perda ou latencia ocorre. Anexe a saida de relatorio do mtr ao reportar um problema.