Falha de rede semi- regular (Dropped RX Packets)

Question

Redes não são minha especialidade, e eu fiz o meu melhor para tentar isolar esse problema, eu gostaria de algumas dicas sobre como diminuir ainda mais o problema.

Servidor: File Sever executando o Limetech Unraid 5.0.6 (sistema operacional baseado no Slackware com kernel 3.9.11p)

Este servidor tem funcionado de forma confiável por cerca de 2 anos com a única atualização de hardware recente sendo uma atualização de RAM (já usei uma ferramenta de memória para verificar se a RAM está funcionando perfeitamente)

Symtoms iniciais: Outros computadores na rede que acessam os compartilhamentos de rede sofreram desconexão intermitente por 10-20 segundos a cada 3-5 minutos.

Investigações Usando testes de ping repetitivos, consegui determinar que todos os outros dispositivos na rede mantinham suas conexões, era apenas o servidor de arquivos que estava perdendo por breves períodos de tempo.

O ping para o servidor de arquivos ou para ele falharia por até 8 segundos em intervalos semi-aleatórios de apenas 30 segundos de intervalo a mais de 15 minutos de intervalo, com uma média de cerca de 3-5 minutos.

A reinicialização do servidor pareceu fazer com que o problema desaparecesse por algumas horas.

ifconfig mostra números pequenos (3-7) de pacotes RX sendo descartados aproximadamente ao mesmo tempo em que a conexão parece falhar

O syslog não reporta nada incomum na inicialização ou durante a falha.

O ethtool mostra que o Link é mantido 100% do tempo

Não sou engenheiro de rede, mas parece que o problema é específico para esse dispositivo (outros dispositivos conectados à mesma infraestrutura não têm problemas).

É provável que isso seja um problema de hardware com a própria NIC? ou é algo a ver com o sistema operacional ou configuração de rede? Poderia ser causado pelo software do usuário?

Qualquer sugestão sobre como identificar a causa raiz seria muito apreciada.

Saída de log / solução de problemas:

Ping do laptop do Windows para o Unraid Server:

Reply from x.x.x.100: bytes=32 time=3ms TTL=64
Reply from x.x.x.100: bytes=32 time=7ms TTL=64
Reply from x.x.x.100: bytes=32 time=3ms TTL=64
Reply from x.x.x.100: bytes=32 time=3ms TTL=64
Reply from x.x.x.100: bytes=32 time=4ms TTL=64
Reply from x.x.x.100: bytes=32 time=3ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Reply from x.x.x.200: Destination host unreachable.
Request timed out.
Reply from x.x.x.100: bytes=32 time=2ms TTL=64
Reply from x.x.x.100: bytes=32 time=1ms TTL=64
Reply from x.x.x.100: bytes=32 time=4ms TTL=64
Reply from x.x.x.100: bytes=32 time=2ms TTL=64
Reply from x.x.x.100: bytes=32 time=2ms TTL=64

ifconfig -a

eth0      Link encap:Ethernet  HWaddr 94:de:80:03:2e:3c
          inet addr:x.x.x.100  Bcast:x.x.x.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:35866080 errors:0 dropped:2107 overruns:0 frame:0
          TX packets:35139719 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1597778360 (1.4 GiB)  TX bytes:1548836243 (1.4 GiB)
          Interrupt:49

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1583 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1583 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:158298 (154.5 KiB)  TX bytes:158298 (154.5 KiB)

netstat -i

Kernel Interface table
Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500 0  35866360      0   2107 0      35139884      0      0      0 BMRU
lo        65536 0      1583      0      0 0          1583      0      0      0 LRU

dmesg | grep r8168

r8168 Gigabit Ethernet driver 8.037.00-NAPI loaded
r8168 0000:02:00.0: irq 49 for MSI/MSI-X
r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
r8168  Copyright (C) 2013  Realtek NIC software team <[email protected]>

cat / var / log / syslog | grep eth

Jan 10 03:04:03 ServerName logger: /etc/rc.d/rc.inet1:  List of interfaces: 'eth0'
Jan 10 03:04:03 ServerName kernel: eth%%d: 0xf8560000, 94:de:80:03:2e:3c, IRQ 49
Jan 10 03:04:03 ServerName logger: /etc/rc.d/rc.inet1:  Polling for DHCP server on interface eth0:
Jan 10 03:04:03 ServerName logger: /etc/rc.d/rc.inet1:  /sbin/dhcpcd -t 10 -h ServerName -L eth0
Jan 10 03:04:03 ServerName dhcpcd[1203]: eth0: waiting for carrier
Jan 10 03:04:08 ServerName kernel: r8168: eth0: link up
Jan 10 03:04:08 ServerName dhcpcd[1203]: eth0: carrier acquired
Jan 10 03:04:08 ServerName dhcpcd[1203]: eth0: broadcasting for a lease
Jan 10 03:04:11 ServerName dhcpcd[1203]: eth0: offered x.x.x.100 from x.x.x.1
Jan 10 03:04:11 ServerName dhcpcd[1203]: eth0: acknowledged x.x.x.100 from x.x.x.1
Jan 10 03:04:12 ServerName dhcpcd[1203]: eth0: checking for x.x.x.100
Jan 10 03:04:16 ServerName dhcpcd[1203]: eth0: leased x.x.x.100 for 86400 seconds
Jan 10 03:04:31 ServerName logger: #  * SSL.Connection objects, wrapping the methods of Python's portable
Jan 10 03:04:36 ServerName avahi-daemon[7491]: Joining mDNS multicast group on interface eth0.IPv4 with address x.x.x.100.
Jan 10 03:04:36 ServerName avahi-daemon[7491]: New relevant interface eth0.IPv4 for mDNS.
Jan 10 03:04:36 ServerName avahi-daemon[7491]: Registering new address record for x.x.x.100 on eth0.IPv4.
Jan 10 03:05:08 ServerName ntpd[1258]: Listen normally on 2 eth0 x.x.x.100 UDP 123
Jan 10 15:04:17 ServerName dhcpcd[1203]: eth0: renewing lease of x.x.x.100
Jan 10 15:04:17 ServerName dhcpcd[1203]: eth0: acknowledged x.x.x.100 from x.x.x.1
Jan 10 15:04:17 ServerName dhcpcd[1203]: eth0: leased x.x.x.100 for 86400 seconds
Jan 11 03:04:18 ServerName dhcpcd[1203]: eth0: renewing lease of x.x.x.100
Jan 11 03:04:18 ServerName dhcpcd[1203]: eth0: acknowledged x.x.x.100 from x.x.x.1
Jan 11 03:04:18 ServerName dhcpcd[1203]: eth0: leased x.x.x.100 for 86400 seconds
Jan 11 15:04:18 ServerName dhcpcd[1203]: eth0: renewing lease of x.x.x.100
Jan 11 15:04:18 ServerName dhcpcd[1203]: eth0: acknowledged x.x.x.100 from x.x.x.1
Jan 11 15:04:18 ServerName dhcpcd[1203]: eth0: leased x.x.x.100 for 86400 seconds

Sim, esta é a saída selecionada - eu vi o syslog e o dmesg em detalhes e posso fornecer mais, se necessário, no entanto, estou confiante de que não há nada ali de valor. A razão para se segurar? Estou paranóico em fornecer muitas informações sobre a minha rede configurada na Internet pública, e limpar o put é demorado.

    

Answer 1

Problema resolvido - não foi o servidor Unraid, mas inesperadamente, um protetor contra surtos de tensão.

Na minha configuração de rede, eu tenho um protetor contra surtos que isola a rede interna do mundo externo, de modo que, no caso de uma descarga elétrica / sobrecarga de energia, meu equipamento caro está protegido.

É uma longa história sobre o porquê de tudo indicar que era o servidor de arquivos, mas a resposta curta é:

• O servidor de arquivos e o gateway de internet ficavam em um dos lados do protetor, enquanto todo o resto estava no outro
• Apenas o tráfego que passava pelo protetor era afetado (Então, dois dispositivos fazendo ping no outro lado do S.P não pareciam mostrar nenhum problema)
• Perder a conectividade por alguns segundos a cada poucos minutos é quase totalmente indetectável para a maioria dos aplicativos de rede - foi apenas a alta taxa de transferência de dados necessária ao usar o Servidor de arquivos que tornou o problema perceptível.

Quando eu estava isolando o hardware de rede para garantir que era o servidor de arquivos que era o problema, nunca pensei em isolar esse componente em particular (eu mal o considero como hardware de rede).

Eu não tenho ideia do porquê isso estava causando o problema, mas está claro que foi. Eu simplesmente o removi da rede por enquanto, dificilmente é vital para o sistema.