Falha na rede Linux: melhores etapas para descobrir a causa?

Um de nossos servidores Linux (CentOS) estava inacessível na noite passada.

O servidor não estava acessível de maneira alguma, exceto no console remoto. Depois de fazer login com o console remoto, também não consegui executar ping em nenhum host externo.

Um simples service network restartresolveu o problema, mas ainda estou me perguntando o que poderia ter causado isso. Meus arquivos de log parecem indicar nenhum erro (exceto os vários daemons que precisam de uma conexão de rede e falharam após a falha na rede).

Existem etapas adicionais que posso executar para descobrir a causa desse problema?

EDIT : isso aconteceu novamente. O servidor ficou completamente sem resposta até eu emitir uma reinicialização do serviço de rede. Qualquer conselho é bem-vindo. Isso pode ser causado por um componente de hardware com defeito?

Conforme solicitado pelo Madhatters, aqui estão alguns trechos do log no momento (a rede travou às 20:13):

/ var / log / messages:

Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=100 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:13:34 graviton junglediskserver: Connection to gateway failed: xGatewayTransport - Connection to gateway failed.

As três primeiras mensagens são respostas simples às regras do iptables que eu configurei através do firewall LFD. A última mensagem indica que o JungleDisk, que eu uso para backups, não pode mais se conectar ao gateway. Além disso, não há mensagens interessantes nesse período.

EDIT 4 dec: conforme solicitação de Mattdm, aqui está a saída de ethtool eth0:

(Lembre-se de que essas são as configurações que atualmente funcionam . Se as coisas derem errado novamente, publicarei isso novamente, se necessário.

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Conforme a solicitação de Joris, aqui está também a saída de route -n:

aron@graviton [~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.xx.58    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.42    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.43    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.41    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.46    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.47    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.44    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.45    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.50    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.51    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.48    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.49    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.54    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.52    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.53    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         xx.xx.xx.62    0.0.0.0         UG    0      0        0 eth0

O xx.62 inferior é o meu gateway.

EDIT 28 de dezembro: o problema ocorreu novamente e tive a chance de comparar algumas das saídas dos testes acima. O que descobri é que arp -anretorna um endereço MAC incompleto para o meu gateway (que não está sob meu controle; o servidor está em um rack compartilhado):

Durante falha:

? (xx.xx.xx.62) at <incomplete> on eth0

Depois service network restart:

? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0

É algo que eu possa corrigir ou está na hora de entrar em contato com o data center?

Verifica

dmesg | lesspara qualquer coisa relacionada ao seu apelido de nic (por exemplo, eht0) less /var/log/messagestambém

Embora raro possa haver um conflito de endereço IP, se isso ocorrer novamente, tente

arping -U <gateway ip> -I <nic alias> No entanto, verifique isso, pois já faz muito tempo que eu não uso arping e isso pode estar incorreto.

Se for bem-sucedido, você deve recuperar a conexão sem recarregar o serviço de rede.

Como você está obtendo seu endereço IP nesta rede (DHCP ou estático)? Se isso acontecer novamente, verifique se ifconfigo estado da interface está em seu estado não funcional. Tem um endereço? Existem erros? Se você executar ethtool, existe um link? (E é negociado na velocidade e no duplex certos?)

Com base nos problemas encontrados, eu suspeitaria de um conflito de endereço IP. Reiniciar a rede enviaria um ARP gratuito que retomaria o IP novamente, o que esclareceria as coisas.

Eu instalaria o arpwatch em outro host no mesmo domínio de broadcast (mesma rede) e verificaria se outras máquinas estão respondendo às solicitações de ARP para o IP do seu servidor. Nesse caso, descubra qual máquina (possivelmente usando as tabelas de endereços MAC de seus comutadores para descobrir a qual porta está conectada) e defina-a para outro endereço estático ou DHCP.

Talvez o conjunto de conexões TCP fique cheio? Algo está abrindo mais e mais conexões, talvez tentar netstat(tente opções diferentes, por exemplo -i para ver interfaces) forneceria informações sobre a conexão aberta.

Se conexões reais (e iptables / rotas / o que quer que seja: você está usando a configuração) estão ok, o problema pode estar, por exemplo, na configuração da interface de rede.

Sua ifconfig -asaída é sã? Essa saída informa se você possui alguns dispositivos de rede que não devem estar presentes, por exemplo, dispositivos virtuais, que estão causando a perda de pacotes.

Essa tabela de roteamento que você colou parece realmente estranha. Funciona quando é assim e muda depois que a conexão para de funcionar? Se sim, algo está causando alterações na tabela de roteamento, talvez algo relacionado ao iptables.

Finalmente, algo específico do CentOS: você tem o NetworkManager em uso? É ativado por padrão no CentOS por algum motivo, mesmo em máquinas virtuais que não possuem X, tornando essa conexão duplicada, roteando alterações e outras coisas possíveis. Eu sugiro desligá-lo, a menos que você saiba que precisa (por exemplo, ter conexões que se ligam e desligam).

Este problema foi resolvido há um bom tempo: o problema estava aparentemente relacionado ao hardware.

Uma nova placa de rede resolveu o problema.

De onde você está testando? Dentro da sub-rede ou fora dela? Quantas rotas você tem? A seleção automática de gateway pode fazer coisas aparentemente imprevisíveis.

Não uso o RedHat ou o CentOS, mas tente olhar para qualquer script que seja chamado quando você fizer uma service network restart. vez. Como a sua rede volta ao normal quando algo nesse script acontece, isso pode ajudar a reduzi-lo.

Hhhmm.

Talvez uma mudança acidental no iptables? Ele pode explicar por que não estava acessível e por que não há nada estranho nos logs (provavelmente você não registra o iptables. Não é?)