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

8

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?

linux networking centos

— Aron Rotteveel
quelle

Gibt es eine Chance, die Protokolle aus der Zeit zu sehen, worüber sich die Dämonen beschwert haben usw.?

— MadHatter

Der Beitrag wurde bearbeitet, um einen Teil des Protokolls zu dieser Zeit aufzunehmen, obwohl es nicht viel Interessantes zu sehen gibt.

— Aron Rotteveel

1

Behebt ein Neustart von Service-Iptables das Problem oder wird nur ein Neustart des Service-Netzwerks durchgeführt?

— JakeRobinson

4

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.

— Oneiroi
quelle

Ich habe die Protokolle überprüft, kann aber nichts finden, was auf ein Problem hinweist, abgesehen von den genannten verschiedenen Daemon-Fehlern, die darauf hinweisen, dass das Netzwerk gerade ausgefallen ist.

— Aron Rotteveel

3

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?)

— mattdm
quelle

Die IP-Adresse ist statisch. Ich habe ifconfig ausgeführt und die Schnittstelle hat eine gültige Adresse, keine Fehler. Ich habe nicht laufen eththool.

— Aron Rotteveel

2

Ausführen ethtool. :)

— Mattdm

Okay, gepostet :)

— Aron Rotteveel

Das gibt einen guten Vergleich - es wird interessant sein zu sehen, was sich ändert, wenn es ein Problem gibt.

— Mattdm

2

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.

— Jeff McJunkin
quelle

Wenn dieser Fehler erneut auftritt, würde ich auch ein "arp -an" ausführen. Basierend auf den Angaben für die Gateway-Adresse können Sie Ihren nächsten Schritt zur Fehlerbehebung definieren.

— BMDan

Arp -an ausgeführt. Scheint, als würde mein Gateway ein unvollständiges ARP zurückgeben, aber ich bin mir nicht sicher, was ich als nächstes tun soll.

— Aron Rotteveel

1

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

— Smar
quelle

1

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

Eine neue Netzwerkkarte hat das Problem gelöst.

— Aron Rotteveel
quelle

0

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

— Joris
quelle

Ich teste die Konnektivität, indem ich einfach einige Websites vom Server anpinge und von außen an den Server pinge. Was meinst du mit der Anzahl der Routen? Anzahl der Routen zu was?

— Aron Rotteveel

2

zeige die Ausgabe von route -n? Wie viele Standardrouten gibt es?

— Joris

Danke für die Antwort. Veröffentlichte die Ausgabe in der Frage.

— Aron Rotteveel

0

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.

— LawrenceC
quelle

-1

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.

— Nikolaidis Fotis
quelle

1

A service network restartlöscht keine Iptables.

— Oneiroi

1

Abhängig von Ihrer Konfiguration können iptables rekonstruiert werden. Ich habe nie erwähnt, dass ein Neustart des Netzwerks sie löscht. Wenn iptables aus bestimmten Gründen geändert wurden, konnte ein Neustart des Netzwerks sie reparieren.

— Nikolaidis Fotis