Perda de pacotes muito alta no burst

Question

Às vezes temos mais de 90% de perda de pacotes em nosso servidor, mas isso nem sempre é acrescentado. Agora funciona perfeitamente, mas há apenas meia hora atrás, tinha exatamente esse problema.

Nosso provedor de serviços está nos dizendo para entrar em um sistema de recuperação para testar se isso é realmente um problema de hardware e não um software do nosso lado. No entanto, não vejo nada que possa causar perda de pacotes do nosso lado, especialmente se não for consistente.

Existe alguma coisa que possamos verificar antes de fazer outro teste no sistema de recuperação?

Temos um servidor dedicado em Hetzner.de. Está ligado a 100MB de ethernet. Nós não tentamos mudar nada do lado do hardware, porque nosso provedor de servidores quer que nós verifiquemos nosso software antes de continuar a verificar o hardware.

Aqui estão os relatórios mtr que eu fiz. Durante o relatório, tivemos 3 de perda de pacotes e o restante do tempo que o servidor ficou acessível:

Cliente para servidor

HOST: mbp                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.1.1                   0.0%  1000    0.4   0.2   0.2   3.4   0.2
  2.|-- 10.0.1.1                   0.3%  1000   27.5  29.7   5.9 237.3  34.6
  3.|-- 10.170.172.121             0.4%  1000   17.2  41.9   7.2 334.1  44.2
  4.|-- 216.113.123.158            1.4%  1000   44.4  58.6  10.6 299.6  49.2
  5.|-- 216.113.123.194            1.1%  1000   36.6  72.9  19.4 330.7  48.1
  6.|-- paix-nyc.init7.net         0.7%  1000   57.1  75.8  18.4 313.8  49.1
  7.|-- r1lon1.core.init7.net      1.4%  1000  199.8 150.9  87.1 373.7  56.4
  8.|-- r1fra1.core.init7.net      0.6%  1000  244.2 150.1  98.6 438.6  53.6
  9.|-- gw-hetzner.init7.net       1.4%  1000  175.3 140.6 100.5 397.2  49.7
 10.|-- hos-bb2.juniper2.rz16.het 39.0%  1000  120.0 136.7 103.5 362.6  44.3
 11.|-- hos-tr4.ex3k13.rz16.hetzn  0.8%  1000  145.4 132.2 106.8 393.3  36.9
 12.|-- static.98.43.9.5.clients. 39.8%  1000  116.0 131.5 106.1 371.8  34.4

Servidor para cliente

HOST: thetransitapp               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. static.97.43.9.5.clients.you 29.0%  1000    7.2   7.4   0.9  24.9   1.9
  2. hos-tr1.juniper1.rz16.hetzne 38.7%  1000    6.1   9.6   0.2  78.8   7.6
  3. hos-bb2.juniper4.ffm.hetzner 36.2%  1000   11.8  11.4   5.8  29.0   1.5
  4. r1fra1.core.init7.net        38.1%  1000   12.4  13.9   5.5  22.9   3.9
  5. r1lon1.core.init7.net        36.3%  1000   23.5  26.5  17.6  37.6   4.4
  6. r1nyc1.core.init7.net        35.5%  1000   92.3  93.8  86.1 103.0   3.7
  7. paix-ny.ia-unyc-bb05.vtl.net 35.5%  1000   95.5  96.4  87.6 134.7   5.3
  8. 216.113.123.169              36.3%  1000  101.5 102.0  94.4 124.9   3.6
  9. 216.113.124.42               34.7%  1000  113.1 107.7  96.7 117.6   3.6
 10. 216.113.123.157              37.5%   999  106.5 107.4 101.5 115.0   1.5
 11. ???                          100.0   999    0.0   0.0   0.0   0.0   0.0
 12. modemcable004.103-176-173.mc 36.7%   999  111.2 147.9 107.2 342.0  48.3

Aqui está a configuração da ethernet

Settings for eth0:
    Supported ports: [ TP MII ]
    Supported link modes:   10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Half 1000baseT/Full 
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Half 1000baseT/Full 
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                         100baseT/Half 100baseT/Full 
                                         1000baseT/Full 
    Link partner advertised pause frame use: No
    Link partner advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: pumbg
    Wake-on: g
    Current message level: 0x00000033 (51)
    Link detected: yes

ifconfig de eth0:

eth0      Link encap:Ethernet  HWaddr c8:60:00:bd:2f:9d  
          inet addr:5.9.43.98  Bcast:5.9.43.127  Mask:255.255.255.224
          inet6 addr: fe80::ca60:ff:febd:2f9d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3521 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2117 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2882770 (2.7 MiB)  TX bytes:910907 (889.5 KiB)
          Interrupt:30 Base address:0x8000 

    

Answer 1

Na minha opinião, é uma falha hetzner. Eu tenho discutido com eles por um longo tempo sobre casos semelhantes.

Tivemos esses problemas e reportamos para a empresa de hospedagem. A resposta foi sempre a mesma - "Por favor, anexe mtr em ambas as direções" - eles responderiam assim mesmo durante a falha. Então nós escrevemos um daemon que irá iniciar o mtr toda vez que tivermos alguma perda de pacotes entre servidores:

if [ -z $1 ] ; then
                echo "Give target host"
else
                host=$1
                while true ; do
                                loss='ping -c 10 $host | grep packet | awk {'print $6'} | sed s/%//g'
                                if [ $loss -ge 1 ]; then
                                                echo 'date' >> /root/scripts/loss_measure_mtr.log
                                                mtr -s 1500 -r -c 1000 -i 0.1 $host >> /root/scripts/loss_measure_mtr.log
                                fi

                done


fi

Depois, com essas informações, eles responderam:

At this time there was an incoming attack in the subnet. In this case it is
possible that packet-loss occurs at servers in the same subnet.

Best Regards

Michael Straetz

Hetzner Online AG
Support
90431 Nürnberg / Germany
Tel: [phone]
Fax: [phone]
http://www.hetzner.de

O que exatamente está acontecendo? Eu não sei, mas parece quase o mesmo:

Sun Aug 12 01:13:20 CEST 2012
HOST: app                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.                      94.1%  1000    0.2   0.2   0.1   0.4   0.1
  2. static.1.24.24.46.clients.you  0.0%  1000    3.0   1.9   0.7  19.4   1.5
  3. hos-tr4.juniper2.rz13.hetzne  9.4%  1000    0.6   1.9   0.4 133.2   8.0
  4. hos-bb2.juniper1.rz1.hetzner  5.4%  1000   38.6   7.1   3.0 112.9  11.5
  5. hos-tr1.ex3k3.rz1.hetzner.de 10.9%  1000    4.4   5.1   3.6  23.6   1.8**
  6. static.88-128-24-108.clients 15.5%  1000    3.6   3.5   3.4   4.6   0.1
HOST: app                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.                  94.5%  1000    0.2   0.2   0.1   0.6   0.1
  2. static.1.24.24.46.clients.you  0.0%  1000    1.2   1.9   0.7  19.3   1.6
  3. hos-tr4.juniper2.rz13.hetzne  9.3%  1000    0.6   1.8   0.4 136.8   7.9
  4. hos-bb2.juniper1.rz1.hetzner  2.7%  1000    3.3   7.0   3.0 113.1  11.5
  5. hos-tr1.ex3k3.rz1.hetzner.de  8.5%  1000    7.0   5.1   3.6  26.8   2.0
  6. static.88-128-24-108.clients 12.8%  1000    3.6   3.5   3.3   4.5   0.1

I have tens of mtr's like this.

Na minha opinião, são os problemas de infraestrutura deles. Observe que a perda está ocorrendo nos nós: hos-tr1.ex3k3.rz1.hetzner.de , hos-tr4.juniper2.rz13.hetzner.de e assim por diante.

Se eles não corrigirem, provavelmente migrarei para linode ou amazon.

    

Answer 2

Esta não é uma resposta, mas é muito longa para um comentário, por isso eu a ponho como resposta.

Eu não concordo completamente com as avaliações feitas no respondente existente e alguns dos comentários para esta questão.

O problema com o uso de qualquer ferramenta que usa ICMP via ping e traceroute (como mtr se estou entendendo como funciona) é que a dita ferramenta está testando como cada salto no caminho responde ao tráfego ICMP, significando que o teste é enviado para cada salto e, em seguida, mede essa resposta de saltos. Este não é um teste verdadeiro da qualidade do caminho através de cada salto no caminho, ou seja, não está testando a transmissão do tráfego "real" através do caminho. Cada salto pode optar por dar baixa prioridade ao seu teste com base em ICMP ou pode descartá-lo completamente, daí a variação nos resultados de um salto para o próximo. Se você tivesse um problema real no hop 10 (em sua primeira captura de tela), então esse problema continuaria (e seria cumulativo) em cada salto sucessivo. Como você pode ver na sua tentativa de sceen, o hop 10 está mostrando 39% de perda de pacotes, mas o hop 11 está mostrando quase nenhuma perda de pacotes. Se o hop 10 estivesse realmente eliminando o tráfego "real", o problema também se manifestaria no hop 11. De fato, o hop 11 provavelmente mostraria mais perda de pacotes (cumulativo da perda no hop 10, a perda na ligação entre o hop 10 e 11, e a perda no hop 11).

O que você deve fazer é testar com uma ferramenta que envia tráfego real de uma ponta à outra, como iperf.