Ler um traceroute: por que perda no salto 5 quase nunca significa nada

Um site parece lento, alguém roda um traceroute e lá está: 40 por cento de perda no salto 5. Parece a resposta. Quase nunca é, e agir com base nisso manda as pessoas atrás de um roteador que está funcionando perfeitamente.

O traceroute é uma ferramenta realmente útil construída sobre um truque, e é esse truque que torna a saída tão fácil de ler errado.

O que o traceroute faz de verdade

Ele envia pacotes com um TTL propositalmente pequeno. O primeiro roteador o reduz a zero, desiste e devolve uma mensagem ICMP Time Exceeded. É por essa resposta que você descobre que o roteador existe. Com TTL 2 vem o segundo, e assim por diante até os pacotes chegarem ao destino.

Ou seja, todas as linhas menos a última não medem o seu tráfego. Elas medem a rapidez com que um roteador resolveu gerar uma mensagem de erro sobre o seu tráfego. São coisas diferentes, e os roteadores as tratam de forma diferente.

Por que os saltos do meio mentem

Gerar respostas ICMP não é o trabalho de um roteador. Encaminhar pacotes é feito em hardware; responder a um TTL esgotado cabe ao plano de controle, uma CPU bem menor com tarefas mais importantes. A maioria dos roteadores limita a taxa dessas respostas e alguns simplesmente as descartam.

O resultado é um salto mostrando 40 por cento de perda enquanto passa 100 por cento do tráfego. Daí saem duas regras que resolvem na hora a maioria desses chamados:

Perda que não continua até o fim não é perda. Se o salto 5 mostra quarenta por cento e os saltos de 6 a 12 mostram zero, nada se perdeu. O salto 5 apenas não quis responder.
Só a última linha conta. Perda no destino, sustentada, é real. Esse é o número que merece escalada.

Um salto com latência alta se comporta do mesmo jeito. Um roteador que responde devagar ao próprio ICMP não encaminha necessariamente devagar.

A metade que você não vê

O traceroute mostra o caminho de ida. Sobre o de volta não diz nada, e os dois costumam ser diferentes: seus pacotes podem sair por um provedor de trânsito e as respostas voltarem por outro. Na internet isso é normal e não é defeito.

Importa porque o problema que você procura pode estar inteiro no caminho de volta, que o seu traceroute não enxerga. Por isso um traço em um só sentido costuma terminar com o suporte pedindo mais dados em vez de consertar algo: falta metade das provas.

Pelo mesmo motivo, a correção às vezes mora em uma rede que não é sua nem nossa. Quando se opera um AS próprio e sessões BGP, o caminho de volta do tráfego pode ser ajustado com os upstreams, não apenas explicado.

Use o mtr

mtr é traceroute e ping juntos. Ele continua enviando, então você vê a perda como percentual ao longo do tempo em vez de adivinhar com três sondas:

mtr -rwzbc 200 dcxv.com

-r modo relatório, imprime uma vez e sai
-w saída larga, para nomes longos não serem cortados
-z mostra o número de AS de cada salto, ou seja, de quem é aquela rede
-b mostra nome e IP ao mesmo tempo
-c 200 envia 200 sondas, porque 10 não dizem nada sobre perda intermitente

No Windows, o WinMTR faz o mesmo serviço. Deixe rodar uns dois minutos antes de tirar conclusões.

O que enviar ao suporte

A coisa mais útil que você pode anexar é mtr nos dois sentidos: um da sua máquina até o servidor e outro do servidor até o seu endereço, colhidos ao mesmo tempo. Esse par transforma um palpite unilateral em algo atribuível a uma rede específica.

Inclua o IP de destino, o seu próprio endereço público, a hora com o fuso e se é constante ou vai e volta. Se vai e volta, diga quando. Perda intermitente com padrão diário costuma ser congestionamento em algum ponto, e saber a hora estreita rápido a busca.

O que não ajuda: uma captura de um único traceroute com um círculo vermelho em volta de um salto do meio. É o anexo mais comum e o menos acionável.

Conclusão

Leia a última linha, não as do meio. Perda que não persiste até o destino é um roteador se recusando a responder, não uma rede jogando fora o seu tráfego. Quando há mesmo algo errado, mtr nos dois sentidos é o que transforma uma reclamação em um relatório com o qual dá para trabalhar.

Servidores cloud e dedicados na Chéquia e em Portugal, na nossa própria rede AS204057: dcxv.com/data-center#cloud