Estou enfrentando o seguinte problema ao executar tracerouteentre dois nós na mesma sub-rede. Isso é feito como um teste para saber se a conexão de rede entre esses dois nós é confiável ou não. Fomos informados para usar essa abordagem pela Equipe de Suporte de um fornecedor de DB conhecido.
Ao executar o comando:
traceroute -s 10.1.3.205 -r 10.1.3.210 há pacotes aleatoriamente não recebidos e nenhum RTT é relatado:
traceroute to 10.1.3.210 (10.1.3.210), 30 hops max, 60 byte packets
1 10.1.3.210 (10.1.3.210) 0.152 ms 0.064 ms *
Por outro lado, executar o traceroute com a opção ICMP: traceroute -I -s 10.1.3.205 -r 10.1.3.210é confiável e não há pacotes perdidos.
O mesmo problema foi descoberto em vários sistemas Linux em nosso ambiente com diferentes níveis de patch, diferentes versões do traceroute e não importa se o sistema é uma VM ou físico.
Para simplificar e facilitar a leitura do tcpdump, tentei com o seguinte comando:
for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done
A saída é a seguinte:
for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.203 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.071 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.075 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 *
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.142 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
1 10.1.3.210 0.054 ms
Cada 7º pacote não obtém resposta e isso é reproduzível. Agora, a equipe de suporte finaliza como se tivéssemos um problema em nossa configuração de rede com essa perda de pacote.
Executando o mesmo loop com um atraso de 1 segundo, todos os 10 pacotes são enviados e recebidos:
for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; sleep 1; done
Estou com algumas dúvidas se essa maneira de testar a confiabilidade da rede está correta ou não, já que normalmente o traceroute é usado para monitorar o caminho da rede em conexões roteadas.
Tentei um teste de conexão de rede por várias horas com nipinga SAP, onde nenhuma conexão perdida foi descoberta.
Então, há algo óbvio que eu tenha esquecido e usar tracerouteesse método é uma maneira viável de testar a confiabilidade da rede?
Como Steffen disse ,
tracerouteé a ferramenta errada para o trabalho, porque sua detecção e relatório de erros simplesmente não são suficientes para o trabalho. Então, diga "oi" para a equipe do fornecedor de DB da nossa parte, e diga a eles que outros administradores disseram que, embora o traceroute seja uma boa ferramenta para detectar se existem rotas da origem para o destino, ele não é útil para diagnosticar problemas de confiabilidade de UDP em uma única sub-rede.Isso é duas vezes mais verdadeiro, pois a carga de rede causada por
tracerouteé realmente mínima. Se você quiser descobrir se sua rede descarta pacotes UDP sob alta carga de banco de dados, ela nem está tentando carregar a rede.Diagnosticar pacotes perdidos é provavelmente algo que você desejará fazer com as pessoas que administram sua rede, mas para um primeiro teste de carga, você pode usar
iperf, como este na máquina cliente:e assim por diante na máquina servidora:
Se 10 Mb/s funcionar, você pode então aumentar a
RATE_BITS_PER_SECvariável, até que seu servidor comece a imprimir números que indiquem que você perdeu pacotes. Isso tem que acontecer em algum momento, ou seja, quando você excede a velocidade do fio, a questão é o quão perto você chega disso.O traceroute baseado em UDP espera mensagens ICMP TTL excedido para descobrir se um pacote com um TTL específico foi descartado por um roteador. Geralmente, há um limite de taxa para envio de ICMP TTL excedido e, às vezes, eles simplesmente não são enviados ou ICMP bloqueado/taxa limitada por sistemas intermediários.
Portanto, o traceroute não é uma ferramenta útil para testar a confiabilidade de uma rede em relação à perda de pacotes. A ferramenta nunca foi planejada para isso. Usado com conhecimento apropriado, o traceroute pode ser usado para encontrar coisas estranhas na rede que também podem afetar a confiabilidade, mas não é uma ferramenta de teste de confiabilidade de propósito geral.