Accident de mise en réseau Linux: meilleures étapes pour en découvrir la cause?

Un de nos serveurs Linux (CentOS) était inaccessible la nuit dernière.

Le serveur n'était accessible d'aucune façon, à l'exception de la console distante. Après avoir ouvert une session avec la console distante, il s'est avéré que je ne pouvais pas non plus cingler aucun hôte extérieur.

Un simple a service network restartrésolu le problème, mais je me demande toujours ce qui aurait pu causer cela. Mes fichiers journaux ne semblent indiquer aucune erreur (à l'exception des différents démons qui ont besoin d'une connexion réseau et qui ont échoué après la défaillance du réseau).

Existe-t-il des mesures supplémentaires que je peux prendre pour trouver la cause de ce problème?

EDIT : cela vient de se produire à nouveau. Le serveur ne répondait pas complètement jusqu'à ce que j'émette un redémarrage du service réseau. Tout conseil est le bienvenu. Cela pourrait-il être causé par un composant matériel défectueux?

Selon la demande de Madhatters, voici quelques extraits du journal de l'époque (le réseau s'est écrasé à 20h13):

/ 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.

Les trois premiers messages sont de simples réponses aux règles iptables que j'ai définies via le pare-feu LFD. Le dernier message indique que JungleDisk, que j'utilise pour les sauvegardes, ne peut plus se connecter à la passerelle. En dehors de cela, il n'y a pas de messages intéressants à cette époque.

EDIT 4 déc: selon la demande de Mattdm, voici la sortie de ethtool eth0:

(Veuillez noter que ce sont les paramètres qui fonctionnent actuellement . Si les choses tournent mal à nouveau, je serai sûr de poster à nouveau si nécessaire.

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

Selon la demande de Joris, voici également le résultat 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

Le bas xx.62 est ma passerelle.

EDIT 28 décembre: le problème s'est reproduit et j'ai eu la chance de comparer certaines des sorties des tests ci-dessus. Ce que j'ai découvert, c'est que arp -anrenvoie une adresse MAC incomplète pour ma passerelle (qui n'est pas sous mon contrôle; le serveur est dans un rack partagé):

En cas d'échec:

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

Après service network restart:

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

Est-ce quelque chose que je peux résoudre ou est-il temps pour moi de contacter le centre de données?

vérifier

dmesg | lesspour tout ce qui concerne votre alias nic (c. -à- eht0) less /var/log/messagesaswell

Bien que rare, il pourrait s'agir d'un conflit d'adresse IP, si cela devait se reproduire, essayez

arping -U <gateway ip> -I <nic alias> Vérifiez cela cependant car cela fait longtemps que je n'ai pas utilisé d'arping et cela peut être incorrect.

En cas de succès, vous devez rétablir la connexion sans recharger le service réseau.

Comment obtenez-vous votre adresse IP sur ce réseau (DHCP ou statique)? Si cela se reproduit, assurez-vous d'exécuter ifconfigpour regarder l'état de l'interface lorsqu'elle est dans son état non fonctionnel. At-il une adresse? Y a-t-il des erreurs? Si vous courez ethtool, y a-t-il un lien? (Et est-il négocié à la bonne vitesse et en duplex?)

Sur la base des problèmes rencontrés, je serais très méfiant d'un conflit d'adresse IP. Le redémarrage du réseau enverrait un ARP gratuit qui reprendrait cette IP, ce qui clarifierait les choses.

J'installe arpwatch sur un autre hôte dans le même domaine de diffusion (même réseau) et voir si d'autres machines répondent aux requêtes ARP pour l'adresse IP de votre serveur. Si tel est le cas, recherchez la machine (en utilisant éventuellement les tables d'adresses MAC de vos commutateurs pour savoir à quel port il est connecté) et définissez-la sur une autre adresse statique ou DHCP.

Peut-être que le pool de connexions TCP est plein? Quelque chose ouvre de plus en plus de connexions, peut-être essayer netstat(essayer différentes options, par exemple -i pour voir les interfaces) donnerait un aperçu de la connexion ouverte.

Si les connexions réelles (et iptables / routes / que ce soit: configuration you_are_using) sont correctes, le problème pourrait être par exemple dans la configuration de l'interface réseau.

Votre ifconfig -asortie est-elle saine d'esprit? Cette sortie indiquerait si vous avez des périphériques réseau qui ne devraient pas être présents, par exemple des périphériques virtuels, ce qui provoque un détraquage des paquets.

Cette table de routage que vous avez collée est vraiment étrange. Est-ce que ça marche quand c'est comme ça, et ça change après que la connexion cesse de fonctionner? Si oui, quelque chose fait changer la table de routage, peut-être quelque chose lié à iptables.

Enfin, chose spécifique à CentOS: utilisez-vous NetworkManager? Il est activé par défaut dans CentOS pour une raison quelconque, même dans les machines virtuelles qui n'ont pas X, ce qui permet de doubler cette connexion, de modifier le routage et d'autres choses. Je suggère de l'éteindre sauf si vous savez que vous en avez besoin (par exemple, avoir des connexions qui s'allument et s'éteignent).

Ce problème a été résolu il y a longtemps: le problème était apparemment lié au matériel.

Une nouvelle carte réseau a résolu le problème.

D'où testez-vous? Dans le sous-réseau ou à l'extérieur de celui-ci? Combien d'itinéraires avez-vous? La sélection automatique de la passerelle peut faire des choses apparemment imprévisibles.

Je n'utilise pas RedHat ou CentOS, mais essayez de regarder quel que soit le script appelé lorsque vous faites un. service network restart. Puisque votre réseau revient à la normale lorsque quelque chose dans ce script se produit, cela peut aider à le réduire.

Hhhmm.

Peut-être un changement accidentel vers iptables? Il peut expliquer à la fois pourquoi il n'est pas accessible et pourquoi il n'y a rien d'étrange dans les journaux (vous ne connectez probablement pas iptables. N'est-ce pas?)