Alta porcentagem de pacotes perdidos - TCP, ICMP - mtr - Reclama ao provedor?

Question

Problema

Estou tendo alta perda de pacotes, de acordo com mtr , ao enviar pacotes pela Internet. Devo me queixar ao meu ISP?

História

Estou lendo o OReilly Linux Networking Cookbook e o capítulo Using traceroute, tcptraceroute, and mtr to Pinpoint Network Problems chamou minha atenção. Fazer ping de um host como o Google pela Internet do meu provedor me dá atrasos de registro de 1200 ms ou mais (não apenas desde hoje; desde muito tempo) , então eu pensei em não fazer nada pior analisando o modo dos pacotes com mtr .

Mtr is a network diagnostic tool that combines ping and traceroute into one program.

O trecho e, ao mesmo tempo, o motivo deste tópico de pergunta é:

If any of these consistently get hung up at the same router, or if mtr consistently shows greater than 5 percent packet losses and long transit times on the same router, then it’s safe to say that particular router has a problem. If it’s a router that you con- trol, then for gosh sakes fix it. If it isn’t, use dig or whois to find out who it belongs to, and nicely report the trouble to them.

Problema

Veja a saída mtr --report www.google.com você mesmo: (No total, 12 testes, 1 teste a cada 5 minutos; este é o relatório que representa a 'média' confiável)

HOST: km                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.0.1                   0.0%    10    1.2   3.7   1.2   6.3   1.8
  2. 10.150.144.145               10.0%    10   89.1  77.3  58.7  90.4  11.1
  3. 172.16.251.1                 50.0%    10   52.2  62.1  52.2  70.3   8.8
  4. 172.16.250.54                60.0%    10   74.9  87.5  74.9 100.4  12.1
  5. 172.16.250.251               40.0%    10   68.6  75.4  52.4 113.8  24.2
  6. 200.85.47.2                  10.0%    10  109.6 110.6  80.6 146.2  21.1
  7. 201.217.4.113                 0.0%    10  103.6  87.3  64.4 103.7  12.2
  8. 201.217.0.9                   0.0%    10  229.0 102.6  46.7 229.0  48.1
  9. 201.217.0.3                   0.0%    10   78.8  88.1  53.9 128.8  23.8
 10. So2-3-2-0-grtbueba2.red.tele  0.0%    10  134.1 129.2  71.3 176.6  29.2
 11. Xe4-1-3-0-grtmiabr7.red.tele  0.0%    10  257.3 255.1 221.0 291.6  21.1
 12. Xe2-0-2-0-grtmiana3.red.tele  0.0%    10  290.4 267.0 213.2 319.1  31.0
 13. Xe2-0-2-0-grtmiana3.red.tele  0.0%    10  300.0 250.8 217.3 312.7  34.6
 14. GOOGLE-xe-5-0-0-0-grtmiana3. 10.0%    10  249.8 256.9 206.7 324.0  34.6
 15. 209.85.254.252                0.0%    10  254.3 253.8 217.1 283.1  23.4
 16. 209.85.254.252               10.0%    10  301.2 280.6 252.1 319.7  21.6
 17. 72.14.236.200                10.0%    10  273.4 278.4 238.4 311.0  25.0
 18. 216.239.49.145               20.0%    10  291.0 276.3 240.4 293.5  19.1
 19. 72.14.232.25                 10.0%    10  297.9 286.3 242.4 337.1  30.0
 20. yo-in-f105.1e100.net         70.0%    10  300.7 304.7 280.3 333.0  26.6

Você vê imediatamente que os hosts 3-5 estão com uma perda muito alta de pacotes acima de 5%. Fazer uma consulta ao banco de dados whois mostra que eles são servidores de nome (corrija-me se estiver errado).

Perguntas

1. O que devo dizer ao meu provedor? Como descrever o problema?
2. Que tipo de pesquisa eu posso fazer além de facilitar a solução de problemas? * 1
3. Alguma sugestão?

^{* 1} Esses caras de suporte técnico nem sempre entendem ou eu não consigo expressar meu problema com clareza suficiente (às vezes eles são apenas idiotas sem dúvida)

    

Answer 1

Muitos roteadores são geralmente programados para dar menor prioridade aos pacotes ICMP, de modo que não "desperdiçam" o poder de processamento sobre o tráfego "real". Só porque você vê um salto com altas perdas, não significa que ele está reduzindo o tráfego "real"; pode estar apenas jogando fora o ICMP. Isso não é necessariamente bom porque pode significar que o roteador está muito ocupado, mas não é garantido.

O roteador também pode ser programado para limitar o número de respostas que envia aos pacotes ICMP, em um esforço para mitigar os ataques DoS.

    

Answer 2

Pode ser que o erro esteja dentro da sua rede.

Qual deles é o seu roteador / gateway de internet?

As chances são de que

3. 172.16.251.1    50.0%    10   52.2  62.1  52.2  70.3   8.8
4. 172.16.250.54   60.0%    10   74.9  87.5  74.9 100.4  12.1
5. 172.16.250.251  40.0%    10   68.6  75.4  52.4 113.8  24.2

estão dentro da sua própria rede.

    

Answer 3

Que tipo de conexão e largura de banda inscrita? DSL, linha alugada, frame relay, cable? 768 para baixo / 128 para cima ... etc.

Você pode obter informações mais realistas usando WireShark e capturar / filtrar pacotes entre dois hosts por um período de tempo (30 minutos). Em seguida, use as estatísticas > Gráfico do Fluxo TCP > Gráfico de tempo de viagem de ida e volta. O Round Trip Time (RTT) é o atraso real na camada tcp.

    

Answer 4

Dado que você tem uma perda zero no salto 15, você sabe que pode obter tráfego até lá sem perdas. Todos os números de perda nos saltos 1-15 são "locais", ou seja, os roteadores não responderam ao ICMP, mas encaminharam o tráfego.

A maior perda no último salto, número 20, então o melhor palpite é que o problema é o congestionamento do outro lado. Um relatório de problema para o seu provedor de serviços de Internet não funcionará, mas talvez uma reclamação para qualquer serviço que esteja do outro lado possa ajudar.

Edit: Eu sei que esta é uma pergunta antiga, mas acho que merece esclarecimentos sobre como interpretar números de perda > 0 seguidos de saltos sem perdas.