Linux-Netzwerkabsturz: Beste Schritte, um die Ursache herauszufinden?

Einer unserer Linux (CentOS) -Server war letzte Nacht nicht erreichbar.

Der Server war bis auf die Remote-Konsole in keiner Weise erreichbar. Nachdem ich mich mit der Remote-Konsole angemeldet hatte, stellte sich heraus, dass ich auch keine externen Hosts anpingen konnte.

Eine einfache service network restartLösung des Problems, aber ich frage mich immer noch, was dies verursacht haben könnte. Meine Protokolldateien scheinen überhaupt keinen Fehler anzuzeigen (mit Ausnahme der verschiedenen Dämonen, die eine Netzwerkverbindung benötigen und nach dem Netzwerkfehler fehlgeschlagen sind).

Gibt es zusätzliche Schritte, die ich unternehmen kann, um die Ursache dieses Problems herauszufinden?

EDIT : das ist gerade wieder passiert. Der Server reagierte nicht mehr, bis ich einen Neustart des Netzwerkdienstes durchführte. Jeder Rat ist willkommen. Könnte dies an einer fehlerhaften Hardwarekomponente liegen?

Laut Madhatters Anfrage sind hier einige Auszüge aus dem Protokoll zu der Zeit (das Netzwerk stürzte um 20:13 Uhr ab):

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

Die ersten drei Nachrichten sind einfache Antworten auf iptables-Regeln, die ich über die LFD-Firewall eingerichtet habe. Die letzte Meldung zeigt an, dass JungleDisk, die ich für Backups verwende, keine Verbindung mehr zum Gateway herstellen kann. Abgesehen davon gibt es derzeit keine interessanten Nachrichten.

EDIT 4 dec: gemäß Mattdms Anfrage ist hier die Ausgabe von ethtool eth0:

(Bitte beachten Sie, dass dies die Einstellungen sind, die derzeit funktionieren . Wenn erneut Probleme auftreten, werde ich diese bei Bedarf erneut veröffentlichen.

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

Auf Wunsch von Joris ist hier auch die Ausgabe von 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

Das untere xx.62 ist mein Gateway.

EDIT 28. Dezember: Das Problem trat erneut auf und ich hatte die Möglichkeit, einige der Ergebnisse der oben genannten Tests zu vergleichen. Ich habe festgestellt, dass arp -aneine unvollständige MAC-Adresse für mein Gateway zurückgegeben wird (die nicht unter meiner Kontrolle steht; der Server befindet sich in einem gemeinsam genutzten Rack):

Bei Ausfall:

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

Nachher service network restart:

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

Kann ich das beheben oder muss ich mich an das Rechenzentrum wenden?

prüfen

dmesg | lessfür alles, was auch mit deinem net alias (dh eht0) zu less /var/log/messagestun hat

Obwohl dies selten vorkommt, kann es sich um einen IP-Adresskonflikt handeln. Sollte dies erneut auftreten, versuchen Sie es erneut

arping -U <gateway ip> -I <nic alias> Überprüfen Sie dies jedoch, da ich Arping schon lange nicht mehr verwendet habe und dies möglicherweise falsch ist.

Bei Erfolg sollten Sie die Verbindung wiederherstellen, ohne den Netzwerkdienst neu zu laden.

Wie erhalten Sie Ihre IP-Adresse in diesem Netzwerk (DHCP oder statisch)? Wenn es erneut passiert, stellen Sie sicher, dass Sie ausgeführt werden ifconfig, um den Status der Schnittstelle zu überprüfen, während sie sich in ihrem nicht funktionsfähigen Zustand befindet. Hat es eine Adresse? Gibt es Fehler? Wenn Sie laufen ethtool, gibt es einen Link? (Und wird es mit der richtigen Geschwindigkeit und Duplex ausgehandelt?)

Aufgrund der aufgetretenen Probleme wäre ich einem IP-Adresskonflikt sehr misstrauisch. Ein Neustart des Netzwerks würde einen kostenlosen ARP senden, der diese IP wieder übernehmen würde, was die Dinge klären würde.

Ich würde arpwatch auf einem anderen Host in derselben Broadcast-Domäne (demselben Netzwerk) installieren und prüfen, ob andere Computer auf ARP-Anforderungen für die IP Ihres Servers antworten. Wenn ja, finden Sie heraus, auf welchem ​​Computer (möglicherweise mithilfe von MAC-Adresstabellen von Ihren Switches, an welchen Port er angeschlossen ist) und stellen Sie ihn auf eine andere statische Adresse oder DHCP ein.

Vielleicht wird der TCP-Verbindungspool voll? Etwas öffnet immer mehr Verbindungen. Vielleicht würde ein Versuch netstat(versuchen Sie verschiedene Optionen, zum Beispiel -i, um Schnittstellen zu sehen) einen Einblick in die offene Verbindung geben.

Wenn die tatsächlichen Verbindungen (und iptables / routen / was auch immer: you_are_using configuration) in Ordnung sind, kann das Problem beispielsweise bei der Konfiguration der Netzwerkschnittstelle liegen.

Ist Ihre ifconfig -aAusgabe gesund? Diese Ausgabe zeigt an, ob einige Netzwerkgeräte vorhanden sind, die nicht vorhanden sein sollten, z. B. virtuelle Geräte, die dazu führen, dass Pakete durcheinander geraten.

Diese Routing-Tabelle, die Sie eingefügt haben, sieht wirklich seltsam aus. Funktioniert es, wenn es so ist, und ändert es sich, nachdem die Verbindung nicht mehr funktioniert? Wenn ja, ändert sich aufgrund einer Routing-Tabelle möglicherweise etwas mit iptables.

Schließlich CentOS-spezifische Sache: Haben Sie NetworkManager im Einsatz? Es ist in CentOS aus irgendeinem Grund standardmäßig aktiviert, auch in virtuellen Maschinen ohne X, wodurch diese Verbindung verdoppelt, Änderungen weitergeleitet und andere Dinge möglich werden. Ich schlage vor, es auszuschalten, es sei denn, Sie wissen, dass Sie es benötigen (z. B. Verbindungen, die ein- und ausgeschaltet werden).

Dieses Problem wurde vor einiger Zeit gelöst: Das Problem war anscheinend hardwarebezogen.

Eine neue Netzwerkkarte hat das Problem gelöst.

Von wo testest du? Innerhalb oder außerhalb des Subnetzes? Wie viele Routen haben Sie? Die automatische Gateway-Auswahl kann scheinbar unvorhersehbare Dinge bewirken.

Ich verwende weder RedHat noch CentOS, aber versuchen Sie, sich das Skript anzusehen, das beim Ausführen eines Skripts aufgerufen wird. service network restart. Da Ihr Netzwerk wieder normal wird, wenn etwas in diesem Skript passiert, kann es hilfreich sein, es einzugrenzen.

Hhhmm.

Vielleicht eine versehentliche Änderung an iptables? Es kann sowohl erklären, warum es nicht erreichbar war, als auch warum die Protokolle nichts Seltsames enthalten (wahrscheinlich protokollieren Sie keine iptables.