Este problema foi resolvido há um tempo: o problema aparentemente estava relacionado ao hardware.
Uma nova NIC resolveu o problema.
Um dos nossos servidores Linux (CentOS) estava inacessível na noite passada.
O servidor não estava acessível de qualquer forma, exceto para o console remoto. Depois de logar com o console remoto, descobri que não era possível pingar nenhum host externo.
Um simples service network restart resolveu o problema, mas ainda estou me perguntando o que poderia ter causado isso. Meus arquivos de log parecem não indicar nenhum erro (exceto os vários daemons que precisam de uma conexão de rede e falharam após a falha da rede).
Há alguma medida adicional que eu possa tomar para descobrir a causa desse problema?
EDITAR : isso aconteceu de novo. O servidor não respondia completamente até que eu emita um reinício do serviço de rede. Qualquer conselho é bem-vindo. Isso pode ser causado por um componente de hardware defeituoso?
De acordo com o pedido de Madhatters, aqui estão alguns trechos do log no momento (a rede caiu à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 primeiras três 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 nessa época.
EDIT 4 dec: de acordo com o pedido de Mattdm, aqui está a saída de ethtool eth0 :
(Por favor, não que estas são as configurações que atualmente funcionam . Se as coisas derem errado novamente, eu vou postar 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
De acordo com o pedido 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
A parte inferior xx.62 é meu gateway.
EDIT dia 28 de dezembro: o problema ocorreu novamente e eu tive a chance de comparar algumas das saídas dos testes acima. O que eu descobri é que arp -an retorna 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
Após service network restart :
? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0
É algo que posso consertar ou é hora de entrar em contato com o data center?
verifique
dmesg | less para qualquer coisa relacionada ao seu nic alias (por exemplo, eht0)
less /var/log/messages também
Embora seja raro um conflito de endereço IP, se isso ocorrer novamente, tente
arping -U <gateway ip> -I <nic alias> Verifique isso, no entanto, já faz muito tempo desde que usei arping e isso pode estar incorreto.
Se tiver sucesso, 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ática)? Se isso acontecer novamente, certifique-se de executar ifconfig para examinar o estado da interface enquanto estiver no estado não funcional. Tem um endereço? Existem erros? Se você executar ethtool , existe um link? (E é negociado na velocidade certa e duplex?)
Com base nos problemas encontrados, suspeito muito de um conflito de endereço IP. Reiniciar a rede enviaria um ARP gratuito que assumiria o IP novamente, o que esclareceria as coisas.
Eu instalaria arpwatch em outro host no mesmo domínio de transmissão (mesma rede) e veja se alguma outra máquina está respondendo a solicitações ARP para o IP do seu servidor. Em caso afirmativo, descubra qual máquina (possivelmente usando as tabelas de endereços MAC dos seus switches para descobrir a qual porta está conectada) e configure-a para outro endereço estático ou DHCP.
Talvez o pool de conexões TCP fique cheio? Algo está abrindo cada vez mais conexões, talvez tentar netstat (tente diferentes opções, por exemplo, -i para ver interfaces) daria uma visão sobre a conexão aberta.
Se as conexões reais (e iptables / routes / whatever: you_are_using configuration) estiverem corretas, o problema poderia estar, por exemplo, na configuração da interface de rede.
Sua ifconfig -a de saída é sã? Essa saída diria se você tem alguns dispositivos de rede que não deveriam estar presentes, por exemplo, dispositivos virtuais, que estão causando erros nos pacotes.
Esta tabela de roteamento que você colou parece muito estranha. Funciona quando é assim, e muda depois que a conexão para de funcionar? Se sim, algo está fazendo com que a tabela de roteamento mude, talvez algo relacionado ao iptables.
Finalmente, coisa específica do CentOS: você tem o NetworkManager em uso? Ele é habilitado por padrão no CentOS por algum motivo, mesmo em máquinas virtuais que não tenham X, fazendo com que essa conexão duplique, faça alterações de roteamento e outras coisas possíveis. Sugiro desativá-lo, a menos que você saiba que precisa (como conexões que ligam e desligam).
De onde você está testando? Dentro da sub-rede ou fora dela? Quantas rotas você tem? A seleção automática de gateways pode fazer coisas aparentemente imprevisíveis.
Eu não uso RedHat ou CentOS, mas tente olhar para qualquer script chamado quando você faz um service network restart. Como sua rede retorna ao normal quando algo nesse script acontece, isso pode ajudar a reduzi-lo.
Hhhmm.
Talvez uma alteração acidental no iptables? Isso pode explicar porque não foi alcançável e porque não há nada de estranho nos logs (provavelmente você não registra o iptables, não é?)
Tags networking linux centos