Linux / Comando tracepath: investigar saltos e a MTU do caminho

O comando tracepath investiga os saltos até um destino e a unidade máxima de transmissão do caminho, chamada Path MTU ou PMTU. No iputils para Linux, ele usa sondas UDP (User Datagram Protocol) e pode funcionar sem privilégios de administrador, mas depende das respostas da rede: não revela necessariamente todos os roteadores nem comprova que uma aplicação esteja disponível.

Um salto, ou hop, corresponde a uma etapa de encaminhamento por um roteador. A MTU (Maximum Transmission Unit) indica um limite de tamanho de pacote; a PMTU é o menor desses limites ao longo de determinado caminho. Na definição para IPv4 da RFC 1191 sobre descoberta de Path MTU, ela permite dimensionar datagramas sem fragmentação no percurso. É uma medida de tamanho, não de velocidade de transmissão.

O tracepath combina essas sondas com informações de erro do sistema e mensagens ICMP (Internet Control Message Protocol). Restrições de ICMP, túneis e mudanças de rota podem deixar etapas sem resposta ou alterar o resultado. Ele oferece opções mais simples que o traceroute explicado neste artigo em inglês.

Sintaxe básica

tracepath [opções] destino

Os colchetes representam opções facultativas, sem serem digitados. O destino é um nome ou endereço IP. Consulte man tracepath e tracepath -V na máquina em uso para identificar a implementação e sua versão; o programa descrito aqui pertence ao iputils.

Não é necessário acrescentar sudo aos exemplos deste artigo. Ainda assim, a conta e o ambiente precisam permitir o envio de datagramas UDP ao destino e às portas usadas. Ausência de privilégio de administrador não significa autorização para testar qualquer rede.

Exemplos de uso

Investigar o caminho básico

O comando resolve o nome fornecido, envia sondas e mostra os saltos que responderem e informações de MTU disponíveis:

tracepath example.com

O domínio example.com é um exemplo reservado para documentação pela IANA. Ele não deve ser tratado como um destino de diagnóstico com respostas garantidas. Substitua-o por um destino conhecido que você tenha autorização para testar e confirme o endereço resolvido.

Priorizar endereços numéricos na saída

A opção -n evita a resolução reversa dos endereços apresentados, reduzindo a espera associada à busca de nomes dos saltos:

tracepath -n example.com

Essa opção não elimina a resolução inicial de example.com para um endereço IP. Se o problema ocorre antes do envio por falha de resolução do destino, use o endereço numérico correto do mesmo destino para separar essa etapa do diagnóstico do caminho. A distinção entre resolução do destino e nomes na saída também aparece no código-fonte de tracepath do iputils.

Limitar os saltos investigados

O exemplo limita a investigação ao máximo de 15 saltos. Se o destino estiver além desse limite, a execução pode terminar sem alcançá-lo:

tracepath -m 15 example.com

-m 15 não é um prazo de 15 segundos nem uma promessa de 15 linhas de roteadores identificados. Cada etapa pode ter tentativas sem resposta; mensagens locais e mudanças de PMTU também podem aparecer na saída. Interrompa com Ctrl+C se precisar encerrar a consulta.

Ler saltos, respostas e PMTU

O comando abaixo conserva o endereço didático do exemplo original. Antes de investigar uma rede real, substitua 192.0.2.1 pelo destino autorizado; ele pertence à faixa TEST-NET-1 reservada para documentação pela RFC 5737, e não é um serviço público de testes.

tracepath 192.0.2.1

Trecho esquemático de saída, com nomes e números ilustrativos, sem representar uma execução real nem demonstrar chegada ao destino:

1:  gateway.example  0.5ms
2:  no reply
Resume: pmtu 1500

• 1: identifica o salto da sonda; gateway.example é um nome didático do equipamento que respondeu. Em saídas reais, um ? junto ao número indica que essa identificação precisou ser estimada.
• 0.5ms é um exemplo de tempo de ida e volta da sonda, ou RTT (round-trip time). Não é a latência de apenas um enlace, uma garantia de desempenho ou o tempo de uma aplicação.
• no reply indica ausência de resposta àquela etapa. O roteador pode encaminhar tráfego normalmente e não responder a sondas; a falta de resposta não demonstra, por si só, interrupção de todo o caminho.
• Resume: pmtu 1500 resume a informação de PMTU obtida, em bytes. O número é ilustrativo: não é uma MTU universal, não é todo espaço disponível para dados da aplicação e, sem evidência de chegada, não comprova a PMTU de todo o percurso até o destino.

Em uma execução real, reached indica que a sonda chegou ao destino segundo o mecanismo do tracepath. Como ele usa UDP e respostas de erro, isso pode decorrer de uma resposta de porta inacessível; não significa que um servidor web ou outro serviço esteja atendendo naquela porta. O manual também descreve asymm e back como informações estimadas sobre o retorno: não as trate como uma medição exata da rota inversa.

No ambiente disponível para verificação, Git Bash 5.3.9 no Windows, tracepath não estava instalado e as chamadas retornaram “command not found”, com código 127. As quatro linhas de comando passaram apenas pela verificação de sintaxe do Bash. Nenhuma sonda foi enviada e não houve execução nativa Linux, medição de PMTU ou alteração da configuração de rede.

Opções principais

No IPv4, o tracepath pode percorrer uma faixa de portas UDP para acompanhar as sondas. Mudar a porta inicial pode alterar quais regras de rede afetam o teste; não equivale a testar o funcionamento de um serviço TCP na mesma numeração. Consulte as condições no manual do tracepath do iputils.

Investigar respostas ausentes e suspeitas de MTU

Uma etapa sem resposta, ou asteriscos em outra ferramenta de rastreamento, pode decorrer de filtragem ou limitação das mensagens de diagnóstico. Se saltos posteriores respondem, a ausência isolada de resposta não identifica automaticamente um enlace interrompido. Se a investigação termina, também é necessário distinguir limite de saltos, ausência de respostas, falha de resolução e mensagens explícitas de erro.

1. Confirme o nome ou IP de destino, a família IPv4/IPv6 e o contexto de rede do processo, inclusive VPN (rede privada virtual) ou contêiner. Registre o comando e o resultado para comparar execuções equivalentes.
2. Use -n para separar a apresentação de nomes dos saltos da investigação de rede. Consulte as interfaces e rotas com o comando ip; uma rota configurada, sozinha, não comprova que o destino responde.
3. Leia as alterações de pmtu, as mensagens de erro e a indicação de chegada em conjunto. Verifique interfaces, túneis e regras que tratam mensagens ICMP necessárias ao diagnóstico. Não altere a MTU de produção apenas porque apareceu um número em uma execução.
4. Confira o problema original com o protocolo e cliente reais. Se uma aplicação falha apenas em certas transferências, reúna também seus sintomas e registros; tracepath auxilia a investigação, sem substituir o teste da aplicação.

Balanceamento de carga, alterações de rota e diferenças entre os caminhos de ida e volta podem produzir resultados distintos. O RTT de cada resposta inclui ida e volta e o tratamento da sonda; subtrair tempos de duas linhas não mede de forma confiável o atraso do enlace entre os dois roteadores. A PMTU descoberta também se refere ao caminho observado, não a todos os destinos nem a uma configuração permanente.

Pergunta frequente

Qual é a diferença entre tracepath e traceroute?

Tracepath oferece uma investigação simples com sondas UDP e descoberta de PMTU, normalmente sem exigir privilégios de administrador. O traceroute para Linux oferece mais métodos e ajustes, incluindo sondas UDP, ICMP e TCP, conforme a implementação e as permissões. Ele também dispõe de descoberta de MTU; portanto, essa capacidade não é exclusiva de tracepath. Compare as opções e o método permitido para o problema que você precisa investigar no manual do traceroute para Linux.