Verifique a saída de 'arp -an' no estado de trabalho e não-funcionamento e procure por endereços MAC / IPs em interfaces erradas.
Se você vir algo errado, talvez tenha colocado em ponte alguns segmentos de rede ou ter um problema de proxy ARP?
Eu tenho um servidor Linux que hospeda nosso software de rastreamento de bugs (CentOS 5.2 Kernel 2.6.18-128.4.1.el5) com o qual tenho alguns problemas de rede estranhos. A máquina é configurada com dois NICS, um para a interface pública e outro para a rede back end do servidor.
O problema é que, depois de fazer uma reinicialização da rede de serviço, posso fazer o ping da interface pública e ela envia de 200 a 500 pacotes ICMP e, de repente, começo a receber um erro de tempo limite de solicitação. Estranho, mas assim que eu me conecto à interface privada, o ping começa a trabalhar novamente na interface pública. Eu claramente tenho um problema de roteamento em algum lugar.
Eu tenho um Juniper Router com a seguinte configuração.
Interface 0/0 - Conecte a sub-rede ao ISP em nossa localização conjunta Interface 0/2 - Para a nossa rede DRAC Interface 0/3 - A rede de servidor back-end (conecta-se diretamente a um switch que alimenta todas as NICs que estão na rede 10.3.20.x. Interface 0/4 - Conecta-se diretamente a outro switch que alimenta nossas interfaces públicas, que interagem como todos os gateways do nosso ip público como endereços IP secundários.
Espero que alguém possa fazer as perguntas certas que podem me levar a checar as coisas e descobrir o que está acontecendo. Alguém já teve problemas semelhantes e que tipo de coisas devo verificar? Problema de roteamento ou algo ainda mais complicado?
[root@fogbugz ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
BOOTPROTO=static
IPADDR=72.249.134.98
NETMASK=255.255.255.248
BROADCAST=72.249.134.103
HWADDR=00:16:3E:AA:BB:EE
ONBOOT=yes
[root@fogbugz ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth1
BOOTPROTO=static
BROADCAST=10.3.20.255
HWADDR=00:17:3E:AA:BB:EE
IPADDR=10.3.20.25
NETMASK=255.255.255.0
NETWORK=10.3.20.0
ONBOOT=yes
[root@fogbugz ~]# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=fogbugz.dfw.hisg-it.net
GATEWAY=72.249.134.97
[root@fogbugz ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
72.249.134.96 0.0.0.0 255.255.255.248 U 0 0 0 eth0
10.3.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
10.0.0.0 10.3.20.1 255.0.0.0 UG 0 0 0 eth1
0.0.0.0 72.249.134.97 0.0.0.0 UG 0 0 0 eth0
Verifique a saída de 'arp -an' no estado de trabalho e não-funcionamento e procure por endereços MAC / IPs em interfaces erradas.
Se você vir algo errado, talvez tenha colocado em ponte alguns segmentos de rede ou ter um problema de proxy ARP?
Por favor, mostre a saída de route -n e arp -an quando a rede não estiver funcionando.
Mostrar o que parece quando tudo está funcionando não é realmente útil. ;)
Duas coisas, uma é que você pode estar tendo problemas com roteamento assimétrico com firewalls, este é um caso comum de conexões que surgem por alguns segundos e depois morrem.
O outro é o RPF do Linux, para desativar isso, configure este sysctl :
net.ipv4.conf.all.rp_filter=0
Qual NIC nesse servidor? Eu experimentei várias vezes esse tipo de problema na NIC Marvell chipset. Normalmente, o problema do driver e o problema do BIOS.
Temos o mesmo problema. Foram no RHEL 5.3, 2.6.18-128.el5 Tivemos um problema com nossa rota para nossa rede privada. Continuou caindo. Encontramos um trabalho por aí. Colocamos isso no nosso crontab e isso resolve o problema. * * * * * / sbin / arp -d IP para armazenamento
link acima trabalhe com você.
Houve um problema com o kernel do linux com o driver do realtek em certas placas onde os tempos limite do watchdog faziam com que as interfaces de rede parassem de funcionar. A única maneira era redefinir a rede e / ou modificar o arquivo ko para o módulo. Verifique / var / log / messages para quaisquer mensagens desse tipo.
Tags networking routing centos juniper