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?
