mtr vs traceroute

Traceroute e mtr são ferramentas de linha de comando para diagnosticar problemas de caminho de rede. O mtr faz a mesma coisa, mas continua a sondar, criando estatísticas sobre perda de pacotes, latência e jitter ao longo do tempo. Este post aborda como cada ferramenta funciona, como ler a saída e quando usar cada uma delas.

Como funciona o traceroute

O Traceroute utiliza o campo Time-to-Live (TTL) nos cabeçalhos dos pacotes IP. Envia um pacote com TTL definido para 1. O primeiro router diminui o TTL para zero, deixa cair o pacote e envia uma mensagem ICMP "Time Exceeded". O traceroute regista o IP do router e o tempo de ida e volta, depois envia outro pacote com TTL definido para 2, e assim sucessivamente até o pacote chegar ao destino ou atingir o limite máximo de saltos (30 por predefinição, ajustável com -m).

Por defeito, o traceroute envia três sondas por salto, dando-lhe três leituras de latência. Os protocolos diferem de acordo com o sistema operacional:

• Windows: O comando tracert envia pedidos de eco ICMP.
• Linux/macOS: O comando traceroute envia datagramas UDP (portas 33434-33534). Use -I para ICMP ou -T para TCP se o UDP estiver bloqueado.

Adicionar o sinalizador -n pula as pesquisas de DNS reverso, o que acelera as coisas visivelmente em caminhos com muitos saltos.

Como funciona o mtr

o mtr (My Traceroute) usa a mesma descoberta de caminho baseada em TTL que o traceroute, mas continua a enviar sondas, normalmente uma por segundo. Em vez de três pontos de dados por salto, obtém estatísticas de execução: percentagem de perda de pacotes, latência média, melhores e piores tempos de resposta e desvio padrão (jitter).

o mtr suporta sondas ICMP (padrão), UDP e TCP SYN. O modo TCP é útil quando os firewalls bloqueiam o ICMP ou quando você deseja testar uma porta de aplicativo específica:

mtr --tcp --port 443 example.com

Para obter um relatório não interativo que possa partilhar com uma equipa de suporte, utilize o modo de relatório:

mtr --report --report-cycles 100 example.com

Este modo executa 100 sondas e imprime um resumo. Também é possível definir tamanhos de pacotes personalizados com --psize para testar problemas de MTU ou fragmentação.

o mtr roda nativamente em Linux e macOS. Os utilizadores do Windows podem usar o WinMTR para um equivalente GUI.

Principais diferenças

A diferença prática resume-se a problemas intermitentes. Um único traceroute pode facilmente deixar passar um router que deixa cair 2% dos pacotes ou um salto com 15ms de jitter. O mtr apanha estes problemas porque continua a medir.

Ler o resultado

O erro mais comum ao ler os resultados do traceroute ou do mtr é assumir que um salto intermédio com aspeto problemático significa que existe um problema real. Normalmente não é o caso.

Os asteriscos (*) no traceroute significam que o router não respondeu à sonda. Muitos routers estão configurados para ignorar ou limitar a taxa de ICMP. Se os saltos seguintes responderem normalmente, o caminho está correto.

A perda de pacotes num único salto em mtr segue a mesma lógica. Se o salto 5 mostra 20% de perda mas o destino final mostra 0%, esse router está apenas a despriorizar as respostas da sonda. A perda real de pacotes aparece como um padrão: a perda aparece num salto e persiste em cada salto subsequente até ao destino.

Os saltos de latência entre saltos são normais e esperados. Um salto de 10ms para 80ms geralmente significa que o pacote atravessou um oceano ou uma longa rota terrestre. Preocupe-se com a latência apenas se esta for invulgarmente elevada para a distância (menos de 5ms numa área metropolitana, dezenas de milissegundos em todo o país, 80-150ms transoceânico) ou se a latência do destino final for inaceitável.

Vale a pena prestar atenção aoStDev (jitter) em mtr. Valores acima de 10ms em qualquer salto podem causar problemas para VoIP, chamadas de vídeo e jogos. Se vir um jitter elevado, execute pelo menos 100 ciclos para confirmar que se trata de um padrão sustentado e não de um breve pico.

Quando utilizar cada ferramenta

Utilize o traceroute quando precisar de uma resposta rápida: o destino é alcançável e, se não for, onde é que o caminho pára? É o ponto de partida correto para interrupções e para verificar o encaminhamento básico.

Utilize o mtr quando o problema for intermitente ou relacionado com o desempenho. Os utilizadores que reportam desconexões ocasionais, problemas de qualidade VoIP ou picos de latência necessitam dos dados contínuos do mtr. Execute pelo menos 50-100 ciclos para obter estatísticas fiáveis.

Para um diagnóstico completo, execute o mtr em ambas as direcções: da sua máquina para o servidor e do servidor de volta para o seu IP. O roteamento da Internet é assimétrico, portanto o caminho de retorno pode ter caraterísticas completamente diferentes. Se testar apenas uma direção, poderá não ver onde está o problema.

Se estiver a ter problemas com o seu servidor dedicado ou VPS, as equipas de suporte da FDC Servers aceitam relatórios mtr como prova de diagnóstico padrão para escalonamentos de rede.