Solução de problemas de “quedas” de rede intermitentes

Question

Fazemos a maioria do nosso trabalho em servidores colocados em um datacenter em SSH. Isso significa que estamos conectados às caixas quase todo o dia, cinco dias por semana. Intermitentemente, vamos ver um atraso entre digitar no teclado, e ter o conteúdo ecoado de volta para nós no shell. Comecei a cavar e estou tendo dificuldades para entender os resultados; Eu também estou procurando os próximos passos para olhar. Anteriormente, eu corri um rastreio wireshark contra tcp.dstport == 22 , que parece ser onde temos a maioria dos problemas. Eu notei um grande-ish (10-20 de vários milhares de pacotes) que eram retransmissões TCP. Presumo que isso esteja relacionado ao problema de atraso que estamos vendo.

1) mtr para o host remoto

                                         Packets               Pings
 Host                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.100.254                    76.6%   454    0.5   0.5   0.3   4.7   0.4
 2. 10.113.128.1                       80.6%   454   17.3 130.8   5.7 6030. 726.7
 3. 74.128.19.209                      79.5%   454    9.7  25.8   6.7 1270. 133.2
 4. 74.128.8.233                       80.6%   454    8.5  31.9   6.6 1369. 150.6
 5. 4.71.250.1                         79.2%   454  1547.  50.5  14.7 1547. 194.1
 6. 4.69.138.158                       80.4%   454   20.1  29.7  15.4 1003. 104.5
 7. 4.69.140.189                       74.2%   454   16.2  28.6  15.0 920.0  85.5
 8. 4.69.138.4                         72.6%   454   17.0  41.2  15.5 821.6  81.7
 9. ???
10. 216.26.190.9                       79.4%   453   45.2 105.8  24.4 3008. 406.7
11. 216.26.162.162                     90.7%   453   28.3  40.2  24.1 556.3  81.7

2) mtr para 192.168.100.254 (acontecendo simultaneamente com acima de mtr)

                                         Packets               Pings
 Host                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.100.254                     0.0%   591    0.8   0.4   0.3   6.9   0.5

Primeira pergunta: por que o top mtr sugere perda de pacotes em 192.168.100.254, quando o inferior não é?

Segunda pergunta: como posso determinar melhor o que pode estar causando isso?

EDITAR :

mtr para o primeiro host fora da nossa rede:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. edge.networldalliance.local      18.1%   393    0.5   0.5   0.4   1.8   0.2
 2. 10.113.128.1                      0.0%   393   10.0  10.1   5.5 744.3  37.4

mtr separado para o segundo host no salto:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. edge.networldalliance.local      87.9%   424    0.8   0.7   0.5   1.2   0.1
 2. 10.113.128.1                      0.0%   424    9.5   9.5   5.2 577.8  27.8
 3. 74-128-19-209.dhcp.insightbb.com  0.0%   423    6.5  10.4   6.2 243.9  12.8

separe (novamente) mtr para o terceiro host no salto:

                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. edge.networldalliance.local      87.2%   440    0.6   0.7   0.4   2.2   0.3
 2. 10.113.128.1                      0.0%   439    6.4  10.9   5.6 991.8  47.2
 3. 74-128-19-209.dhcp.insightbb.com  0.0%   439    8.5  13.3   6.5 744.3  35.6
 4. 74.128.8.233                      0.0%   439    7.9  23.6   6.3 493.8  47.2

Alguma sugestão com base nesses novos dados? Vou ver como substituir o roteador / firewall.

    

Answer 1

Respostas diretas

First question: why does the top mtr suggest packet loss at 192.168.100.254, when the bottom one does not?

mtr envia pings (resposta de eco ICMP) com o incremento do IP TTL até obter uma resposta. 192.168.100.254 responde de forma diferente ao responder a condições de expiração TTL (baixo sucesso) vs resposta de eco ICMP (alto sucesso)

Second question: how can I determine better what might be causing this?

Quando você diz "causando isso", eu suponho que você esteja falando de suas sessões ssh, em vez dos resultados estranhos ... certo? Um par de pensamentos ...

Execute mtr diretamente para cada host no caminho do 11-hop e veja se você pode encontrar algum sintoma interessante a partir de um dos saltos; com base no seu primeiro mtr , isso pode não ser muito mais produtivo, mas vale a pena uma chance. Também fale com o administrador do 192.168.100.254 para ver se vocês podem descobrir por que as respostas do ICMP TTL estão sendo apagadas.

Outros pensamentos

• Existem três causas gerais de problemas de rede: perda de pacotes, atraso de pacotes (enfileiramento) ou reordenamento de pacotes. No entanto, vamos lembrar também que, às vezes, problemas no nível do host contribuem para o seu problema ¹ .

• Vamos supor que, no momento em que o 192.168.100.x vlan não esteja no lugar do seu problema e sua topologia seja assim:

      HOST_A----------------------HOST_B
      192.168.100.x               216.26.162.162
  

Se você ainda não estiver ssh-ing de uma máquina Windows para HOST_A , faça ² . Agora grave sua área de trabalho do Windows ³ . Quando o problema acontece novamente, o vídeo gravado é uma ótima trilha de auditoria para onde seus problemas podem estar (ou seja, na rede, nos hosts ou em uma combinação de ambos). Se você puder de alguma forma ver ntp tempo neste vídeo, melhor ainda ... isso lhe dará uma maneira de voltar atrás na análise por syslog .

NOTAS FINAIS

1. Um deles está trocando para disco, consumindo muita CPU (talvez causado por uma consulta de script / banco de dados) ou ocupado intermitentemente?
2. Com pelo menos quatro janelas, uma para ssh entre HOST_A e HOST_B , outra para uma sessão sniffing em HOST_A , as duas últimas devem estar em execução top ou vmstat 5 on HOST_A and% código%.
3. Use o que você quiser, mas eu uso Camstudio (a cópia beta é minha favorita no momento); é gratuito e de código aberto.

Answer 2

Para sua segunda pergunta: talvez você possa permitir que o ping seja executado por algumas horas em cada um dos saltos detectados. Redirecione a saída para arquivos de log. Então extraia o tempo de ping com grep, awk, etc e plote-o (Excel, OO Calc, etc). Você deve ser capaz de ver em que ponto o atraso começa.

Que tipo de conexão com a Internet você tem? Muitas vezes, a saturação de upload é suspeita quando você está lidando com alta latência. Configure seu roteador (ou novo roteador) para transmitir a 85% -90% da velocidade máxima de conexão e configure um "fair queue" para evitar que os pacotes ssh acabem no final da fila.