2 votes

Problèmes de réseau avec un serveur Linux (CentOS 5.3)

J'ai un serveur Linux hébergeant notre logiciel de suivi des bogues (CentOS 5.2 Kernel 2.6.18-128.4.1.el5) avec lequel je rencontre d'étranges problèmes de réseau. La machine est configurée avec deux NICS, l'un pour l'interface publique et l'autre pour le réseau dorsal de notre serveur.

Le problème est qu'après avoir redémarré le réseau de services, je peux envoyer un ping à l'interface publique, qui envoie entre 200 et 500 paquets ICMP, puis, tout à coup, j'obtiens une erreur de temporisation de la demande. C'est étrange mais dès que je me connecte à l'interface privée, le ping recommence à fonctionner vers l'interface publique. Il est clair que j'ai un problème de routage quelque part.

J'ai un routeur Juniper avec la configuration suivante.

Interface 0/0 -- Connecter le sous-réseau au fournisseur d'accès à notre colocation Interface 0/2 -- Pour notre réseau DRAC Interface 0/3 -- Le réseau du serveur (se branche directement sur un commutateur qui alimente toutes les cartes réseau qui sont sur le réseau 10.3.20.x. Interface 0/4 -- Se branche directement sur un autre commutateur qui alimente nos interfaces publiques, cette interface étant toutes les passerelles de nos réseaux IP publics en tant qu'adresses IP secondaires.

J'espère que quelqu'un pourra poser les bonnes questions qui me permettront de vérifier les choses et de comprendre ce qui se passe. Est-ce que quelqu'un a eu des problèmes similaires et quels sont les points à vérifier ? Un problème d'acheminement ou quelque chose de plus compliqué ?

[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

1voto

Bernhard Points 891

Vérifiez la sortie de 'arp -an' en état de fonctionnement et en état de non fonctionnement et recherchez les adresses MAC / IP sur les mauvaises interfaces.

Si vous voyez quelque chose d'anormal, il se peut que vous ayez établi un pont entre certains segments du réseau ou que vous ayez un problème de proxy ARP.

1voto

Joey deVilla Points 4487

Veuillez montrer la sortie de route -n y arp -an lorsque le réseau n'est pas de travail.

Montrer à quoi cela ressemble quand tout fonctionne n'est pas vraiment utile ;)

1voto

Steve Scheffler Points 1166

D'une part, il se peut que vous ayez des problèmes de routage asymétrique avec les pare-feux, ce qui est un cas courant de connexions qui s'établissent pendant quelques secondes puis s'interrompent.

L'autre est le RPF Linux, pour le désactiver, procédez comme suit sysctl :

net.ipv4.conf.all.rp_filter=0

0voto

Quel est le NIC de ce serveur ? J'ai rencontré plusieurs fois ce type de problème avec des cartes d'interface réseau à puce Marvell. Normalement, il s'agit d'un problème de pilote et de BIOS.

0voto

Nous avons le même problème. Nous sommes sur RHEL 5.3, 2.6.18-128.el5. Nous avons eu un problème avec notre route vers notre réseau privé. Elle n'arrêtait pas de tomber. Nous avons trouvé une solution. Nous avons mis ceci dans notre crontab et cela résout le problème. * * * * * /sbin/arp -d IP to storage

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X