eth0 NIC Link is Down répéter le message dans le journal du noyau

J'ai remarqué depuis quelques jours que le même type de message se répète et je peux affirmer que rien n'a été intentionnellement changé (installé / désinstallé) pendant cette période.

voici un exemple de message /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

à partir du fichier journal complet - lorsque tous les messages de journal de ce type sont pris en compte - je peux conclure:

eth0 échoue toutes les quelques heures
eth0 échoue dans le premier cas pendant deux et en deuxième pendant 19 secondes

C'est le serveur de production dont je parle ici.

Comment résoudre ce problème, car le serveur de messagerie est en production et les pannes de réseau de 19 secondes que je ne peux pas tolérer?

— Miloš Đakonović
source

Qu'avez-vous vérifié jusqu'à présent? Le câble est-il correctement fixé et en bon état? L'interrupteur à l'autre extrémité observe-t-il également que le lien descend? Il convient de noter que le lien détecté est différent à différents moments (le contrôle de flux diffère dans votre journal). Peut-être que la négociation automatique échoue? Le problème disparaît-il si vous forcez 1000 Mbps FD Rx / Tx?

— Håkan Lindqvist

@ HåkanLindqvist Je n'ai pas la possibilité de vérifier le câble, car le serveur n'est pas physiquement près de moi. Est-ce quelque chose que je devrais demander aux techniciens de la batterie de serveurs de vérifier? Comment puis-je forcer 1000 Mbps FD Rx / Tx? Et, au sujet du contrôle de flux étant différent à différents moments, est-ce le problème?

— Miloš Đakonović

Le lien "type" qui change avec le temps me suggère que quelque chose ne va pas, mais trouver la cause réelle est bien sûr une question à part entière. Demander au personnel technique peut être une bonne idée.

— Håkan Lindqvist

Vous pouvez utiliser ethtool ou mii-tool pour vérifier l'état de négociation automatique, etc. à l'extrémité du serveur. Vous devez vous assurer que le commutateur auquel votre serveur est configuré correspond. Cela ressemble à un problème matériel - il peut s'agir d'un adaptateur de serveur, d'un câble ou d'un commutateur. Je suggère de regarder l'état du commutateur pour voir ce qu'il pense qu'il se passe.

— Paul Haldane

Réponses:

vérifier les erreurs sur le fil, regardez le champ "erreurs" dans la sortie de ifconfig. Si différent de zéro, il y a des problèmes avec le matériel (câble, carte NIC ou concentrateur / commutateur). Un câble Ethernet non fiable donnera également des erreurs dans ce domaine.
remplacez le câble Ethernet, quelle que soit l'étape 1. C'est rapide, bon marché et facile, et cela devrait être fait chaque fois que votre lien monte et descend à intervalles aléatoires.
utilisez ethtoolet assurez-vous que les paramètres réseau (duplex, etc.) correspondent à ceux du commutateur. Si vous n'êtes pas l'administrateur du commutateur, demandez à l'administrateur du réseau de vous fournir les paramètres.
si le commutateur a le contrôle de flux activé, assurez-vous qu'il est activé sur votre boîtier Linux. Sinon, désactivez-le.

En remarque, vous devez évaluer si vous avez besoin d'un contrôle de flux. Selon HP, il n'est nécessaire que pour les applications hautes performances: voir l' article HP sur l'utilisation du contrôle de flux

— Michael Martinez
source

C'était des erreurs de fil. Le matériel technique de la batterie de serveurs a fait le travail après avoir signalé des erreurs.

— Miloš Đakonović

'ifconfig' montrait des erreurs?

— Michael Martinez

Voici ma solution. Ce problème se produit sur du matériel spécifique (sur une seule machine, 1 port sur 2 sur la carte réseau), toujours avec le pilote e1000e, depuis le noyau 3.9 ou plus. Ce fichier est pour centos7, entre /etc/init.d/et doit être activé avec chkconfig --add <name>. Le nom de l'interface est codé en dur ... assurez-vous de le définir.

#!/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
source