eth0 NIC-Link ist inaktiv und wiederholt die Meldung im Kernel-Protokoll

Ich habe vor ein paar Tagen bemerkt, dass die gleiche Art von Nachrichten auftritt und ich kann definitiv sagen, dass in diesem Zeitraum nichts absichtlich geändert (installiert / deinstalliert) wurde.

Hier ist ein Beispiel für die Meldung /var/log/kern.log :

Mar 30 06:32:45 aurora kernel: [566322.867110] e1000e: eth0 NIC Link is Down

Mar 30 06:32:47 aurora kernel: [566325.313634] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

Mar 30 06:32:59 aurora kernel: [566337.632930] e1000e: eth0 NIC Link is Down

Mar 30 06:33:18 aurora kernel: [566356.543664] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Mar 30 11:05:47 aurora kernel: [582689.779752] e1000e: eth0 NIC Link is Down

Mar 30 11:05:50 aurora kernel: [582692.174337] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

Aus der vollständigen Protokolldatei - wenn alle Protokollmeldungen dieser Art gezählt werden - kann ich schließen:

eth0 schlägt alle paar Stunden fehl
eth0 versagt im ersten Fall für zwei und im zweiten für 19 Sekunden

Ich spreche hier von einem Produktionsserver.

Wie kann ich dieses Problem lösen, da der Mailserver in Betrieb ist und Netzwerkfehler von 19 Sekunden Dauer auftreten, die ich nicht tolerieren kann?

— Miloš Đakonović
quelle

Was haben Sie bisher überprüft? Ist das Kabel richtig angeschlossen und in unversehrtem Zustand? Beobachtet der Schalter am anderen Ende auch, dass die Verbindung unterbrochen wird? Erwähnenswert ist, dass die erkannte Verbindung zu verschiedenen Zeiten unterschiedlich ist (die Flusssteuerung in Ihrem Protokoll unterscheidet sich). Vielleicht schlägt die Autonegotiation fehl? Behebt sich das Problem, wenn Sie 1000 Mbit / s FD Rx / Tx erzwingen?

— Håkan Lindqvist

@ HåkanLindqvist Ich habe keine Möglichkeit, das Kabel zu überprüfen, da der Server nicht in meiner Nähe ist. Sollte ich Serverfarmtechniker bitten, das zu überprüfen? Wie erzwinge ich 1000Mbps FD Rx / Tx? Und ist das Problem, dass die Flusskontrolle zu verschiedenen Zeiten unterschiedlich ist?

— Miloš Đakonović

Der Link "Typ", der sich im Laufe der Zeit ändert, legt für mich nahe, dass etwas nicht ganz stimmt, aber die eigentliche Ursache zu finden, ist natürlich eine ganz andere Frage. Es kann eine gute Idee sein, das technische Personal zu fragen.

— Håkan Lindqvist

Sie können ethtool oder mii-tool verwenden, um den Status der automatischen Aushandlung usw. auf der Serverseite zu überprüfen. Sie müssen sicherstellen, dass der Switch, auf den sich Ihr Server bezieht, übereinstimmt. Dies klingt nach einem Hardwareproblem - es kann sich um einen Serveradapter, ein Kabel oder einen Switch handeln. Ich schlage vor, den Status des Schalters zu überprüfen, um festzustellen, was seiner Meinung nach geschieht.

— Paul Haldane

Antworten:

Suchen Sie nach Fehlern in der Leitung und sehen Sie sich das Feld "Fehler" in der Ausgabe von an ifconfig. Wenn der Wert nicht Null ist, liegt ein Problem mit der Hardware vor (Kabel, NIC-Karte oder Hub / Switch). Ein unzuverlässiges Ethernet-Kabel führt auch in diesem Bereich zu Fehlern.
Tauschen Sie das Ethernet-Kabel unabhängig von Schritt 1 aus. Dies ist schnell, kostengünstig und einfach und sollte immer dann durchgeführt werden, wenn die Verbindung in zufälligen Abständen auf und ab geht.
Verwenden Sie ethtoolund stellen Sie sicher, dass die Netzwerkeinstellungen (Duplex usw.) mit denen auf dem Switch übereinstimmen. Wenn Sie nicht der Administrator des Switches sind, bitten Sie den Netzwerkadministrator, Ihnen die Einstellungen mitzuteilen.
Wenn auf dem Switch die Flusskontrolle aktiviert ist, stellen Sie sicher, dass sie auf Ihrer Linux-Box aktiviert ist. Andernfalls deaktivieren Sie es.

Nebenbei sollten Sie prüfen, ob Sie eine Flusskontrolle benötigen. Laut HP ist dies nur für Hochleistungsanwendungen erforderlich: Weitere Informationen finden Sie im HP Artikel zum Zeitpunkt der Verwendung der Flusskontrolle

— Michael Martinez
quelle

Es waren Drahtfehler. Das technische Personal der Serverfarm hat den Job erledigt, nachdem ich Fehler gemeldet habe.

— Miloš Đakonović

'ifconfig' zeigte Fehler an?

— Michael Martinez

Hier ist meine Lösung. Dieses Problem tritt auf einer bestimmten Hardware auf (auf einem Computer nur 1 von 2 Ports auf der Netzwerkkarte), immer mit dem e1000e-Treiber, seit Kernel 3.9 oder so. Diese Datei ist für Centos7, geht rein /etc/init.d/und muss mit aktiviert werden chkconfig --add <name>. Der Name der Schnittstelle ist fest codiert. Achten Sie darauf, ihn festzulegen.

#!/bin/sh

### BEGIN INIT INFO
# Provides:          pm-e1000e-fix
# Required-Start:    $network
# Required-Stop:     $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 6
# Short-Description: workaround for e1000e issue
# Description:       e1000e fix
### END INIT INFO

################################################################################
# Give Usage Information                                                       #
################################################################################
usage() {
    echo "Usage: $0 start|restart" >&2
    exit 1
}

################################################################################
# E X E C U T I O N    B E G I N S   H E R E                                   #
################################################################################
command="$1"
shift

interface="eth0"

case "$command" in
    start)
        ethtool -K "$interface" gso off gro off tso off
        ;;
    restart)
        ethtool -K "$interface" gso off gro off tso off
        ;;
    *)
        usage
        ;;
esac

— Peter
quelle