Récemment, mon serveur maison et hôte de VM a commencé à perdre sa connectivité réseau de façon aléatoire. De l’extérieur, on aurait dit qu’il fonctionnait toujours, mais impossible d’y accéder à distance, quelle que soit la méthode. L’adaptateur ethernet semblait actif d’après le switch, donc le problème devait se trouver quelque part côté logiciel.
Ce ne serait pas la première fois qu’un pilote est à l’origine d’une connexion réseau qui plante. Par le passé, je me suis déjà fait avoir par des pilotes WiFi buggés sur des machines Linux et Windows.
Après avoir fouillé un peu dans les logs système, je suis tombé sur ceci :
vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state
Ensuite, il réinitialisait l’adaptateur réseau, puis recommençait un peu plus tard, jusqu’à ce que la machine passe complètement hors ligne.
En cherchant des réponses en ligne, je suis tombé sur ce fil ServerFault.
Cause
D’après différentes sources et listes de rapports de bugs, la meilleure façon de reproduire le problème semble être de mettre l’appareil dans une situation de forte bande passante, c’est-à-dire de faire transiter de grandes quantités de données qui saturent l’interface.
Dans mon cas, ça arrivait généralement quand je diffusais des médias depuis le serveur Plex local vers un appareil. À cause de la façon dont le réseau est configuré, la VM Windows qui fait tourner Plex doit récupérer le fichier média depuis un partage réseau NFS sur un autre appareil, le transcoder dans la VM, puis l’envoyer à l’appareil de lecture.
Ça représente beaucoup de trafic réseau, généralement ~40-100 mbit/s, selon l’appareil qui lit le fichier et la qualité du fichier source.
Le même problème s’est manifesté en streamant des jeux via Steam Link vers notre Apple TV. La connexion est filaire, mais il n’est pas rare que le réseau tombe. Je pense que c’est lié au même problème, mais je garde un œil dessus pour voir si ça se reproduit après le correctif.
Correctif possible
Il semblerait qu’un correctif possible consiste à désactiver GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) et GRO (Generic Receive Offload) sur l’interface réseau* :
ethtool -K eth0 gso off gro off tso off
J’ai appliqué ça à ma configuration et j’attends de voir si ça résout vraiment le problème sur le long terme.
Notes de bas de page
* Ces options servent à déléguer la segmentation des paquets au contrôleur d’interface réseau afin de réduire l’utilisation du CPU de la machine. Plus de détails dans cet article de Wikipédia.