Encontre perda de pacotes com MTR e leia corretamente

Instale

apt install -y mtr-tiny     # Debian
dnf install -y mtr          # AlmaLinux

Execute corretamente

mtr -rwbc 200 <destination>

• -r modo de relatório, para que saia com algo que você possa colar
• -w saída larga, para que nomes de host longos sobrevivam
• -b mostrar o nome e o endereço de cada salto
• -c 200 duzentos ciclos, cerca de três minutos e meio, e a diferença entre evidência e anedota

Dez pacotes não provam nada. Se uma execução de dez ciclos mostrar perda, execute duzentos antes de concluir qualquer coisa.

Leia o último salto primeiro

Roteadores despriorizam pacotes endereçados a si mesmos. Um roteador de trânsito carregando centenas de gigabits responderá às suas sondas de TTL expirado quando tiver um ciclo livre e as descartará quando não tiver, o que pinta perda no meio do seu relatório enquanto cada pacote que você realmente se importa chega intacto.

Duas regras cobrem a maioria dos relatórios:

1. Perda no salto sete que está ausente no salto oito e além é limitação de taxa. Ignore-a.
2. Perda que começa no salto sete e continua até o destino é real, e o salto onde começa é onde procurar.

A latência se comporta da mesma forma. Um salto que adiciona oitenta milissegundos e então entrega o tráfego ao próximo salto no valor anterior está respondendo lentamente, não encaminhando lentamente.

ICMP não é o seu tráfego

Se o serviço roda em TCP, teste em TCP:

mtr -rwbc 200 --tcp --port 443 <destination>

Redes que limitam ICMP fortemente muitas vezes passam TCP intocado. O caso inverso vale a pena descobrir antes de culpar a rede de alguém: um firewall que responde ping feliz e descarta a porta que seus usuários realmente alcançam.

Ambos os sentidos, toda vez

O roteamento é assimétrico mais frequentemente do que não. O caminho de você para nós não é o caminho de nós para você, e um relatório de uma extremidade descreve exatamente um deles. Execute MTR da instância em direção ao cliente e do cliente em direção à instância, então anexe ambos. Nossa metade do caminho também pode ser sondada sem shell em lugar nenhum, a partir do looking glass.

Corrobore nos contadores TCP

MTR descreve o caminho. As estatísticas de socket descrevem a consequência:

ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Uma taxa de retransmissão acima de um por cento ou mais, em uma conexão que deveria estar limpa, apoia o relatório. Zero retransmissões junto com um MTR cheio de perda significa que você está olhando para limitação de taxa e nada mais.

O que nos enviar

• Ambos os relatórios MTR, duzentos ciclos, como texto em vez de captura de tela
• Destino, transporte e porta
• Carimbos de data/hora com fuso horário, e se a perda é constante ou em rajadas
• O ID da instância

Aproximadamente metade desses resolve para um salto intermediário com limite de taxa, e dizemos isso na primeira resposta. O resto geralmente podemos contornar em uma hora: perda dentro da nossa própria rede é problema nosso, e perda em um caminho de trânsito é questão de mover seu tráfego para um diferente.