Un nœud AHV perd des paquets en réception toute la journée, et trois suspects se présentent d’eux-mêmes : la charge, la carte réseau, le lien 25G. Avant de toucher à un réglage, on peut les écarter un par un en comparant le nœud à ses voisins, puis à un témoin, avec le bon compteur.
Le contexte
Un cluster AHV de production d’une quinzaine de nœuds, deux uplinks 25 GbE par hôte en bond OVS balance-tcp avec LACP, cartes Broadcom (pilote bnxt_en). La supervision remonte un compteur de drops Rx par hyperviseur : un nœud en cumule plusieurs centaines de milliers par jour, en continu. Ses voisins en comptent quelques dizaines de milliers au plus sur quinze jours.
Écarter la charge : normaliser
Un volume brut ne prouve rien, puisqu’un nœud plus chargé perd plus. Divisez les drops par le trafic reçu sur la même période. Sur sept jours, tous les nœuds recevaient entre 30 et 44 To. Le nœud fautif perdait 106 472 paquets par To reçu, les autres entre 172 et 938 : au moins 113 fois plus à charge équivalente.
La même série a fourni deux autres indices. Le profil horaire est plat et les drops en émission sont à zéro. Une nuit où tous les nœuds montent correspondait à un remplacement de modules optiques : c’est un artefact de l’intervention, pas un symptôme.
Écarter le lien et la carte
Le remplacement des modules 25G n’a rien changé au rythme. Sur l’hôte, en root :
ovs-appctl bond/show
ovs-appctl lacp/show
ip -s -s link show eth0Le LACP était négocié, les deux membres actifs, les hashes répartis. Les CRC étaient quasi nuls, frame, fifo et overrun à zéro. Ni câble, ni module, ni port de switch.
Pour la carte, il faut un témoin : un nœud du même cluster, même carte, même pilote, même firmware, à zéro drop sur quinze jours. La carte et le pilote ne suffisent donc pas à expliquer.
Le piège du compteur
ethtool -S expose des statistiques propres au pilote. Sur bnxt_en, deux familles se ressemblent :
ethtool -S eth0 | grep -E 'rx_stat_discard|rx_discards|rx_total_discard_pkts'rx_stat_discard: selon Broadcom, paquets rejetés au port faute de tampons côté réseau. Il montait sur les deux nœuds, et son cumul était 3,4 fois plus élevé sur le témoin. Une analyse arrêtée là conclut à l’envers.[N]: rx_discards: paquets rejetés sur la file N faute de place dans l’anneau côté hôte. Le témoin était à 0 sur les 8 files de chacun de ses deux uplinks, le nœud fautif à 270 millions. Leur somme,rx_total_discard_pkts, était égale à la colonnemisseddeip -s -s link, et son rythme était du même ordre que le compteur de supervision.
Côté compteurs standard, la colonne missed correspond à rx_missed_errors, que la doc du noyau réserve aux pertes par épuisement des tampons, distinctes de rx_dropped.
Comparer les réglages, et les uptimes
ethtool -i eth0
ethtool -g eth0
ethtool -l eth0
ethtool -c eth0
ethtool -k eth0
uptime -sTout était identique : anneau RX à 511 pour un maximum de 2047, 8 files combined sur 16 possibles, adaptive-rx off, rx-usecs et rx-frames à 6, GRO actif, LRO inactif.
Ramené au jour, le nœud fautif recevait sur son premier uplink 22 % de paquets en plus, plus petits (992 octets en moyenne contre 1 190), avec un p99 de débit environ 1,4 fois plus haut. Les pertes touchaient les 8 files de chaque uplink, entre 0,0046 % et 0,0155 % de leur trafic, et se déplaçaient d’une file à l’autre entre deux relevés : pas de file saturée par un flux unique.
Où on en est
L’hypothèse retenue est un débordement diffus de l’anneau RX. Elle n’est pas prouvée : 22 % de paquets en plus expliquent mal 0 contre 270 millions. Le correctif évident, agrandir l’anneau avec ethtool -G, n’est pas appliqué. Sur le forum de la communauté Nutanix, un employé recommandait en 2020, pour AHV, de répartir la charge sur les uplinks plutôt que d’agrandir le tampon ; ici le bond répartit déjà. Le changement reste à valider avec le support, persistance au redémarrage comprise.
Ce qu’il faut retenir
- Ramenez les drops au trafic reçu avant d’accuser la charge.
- Un nœud témoin identique à zéro drop vaut mieux que toute hypothèse sur la carte.
- Sur
bnxt_en, suivezrx_discardspar file, pasrx_stat_discard. - Comparez des taux par jour, jamais des cumuls ethtool entre nœuds aux uptimes différents.
In English
An AHV node keeps dropping packets on receive. Normalize by traffic, compare with a reference node, and read the right ethtool counter: the method to rule out load, link and NIC. On bnxt_en, the discriminating counter was per-queue rx_discards rather than rx_stat_discard, and cumulative ethtool counters must be compared per day since node uptimes differ.
Sources & vérification
Testé sur : hôtes AHV de production, uplinks 25 GbE, pilote bnxt_en, 2026
- Linux kernel, Interface statistics docs.kernel.org
- man ethtool(8) man7.org
- Broadcom TechDocs, Ethtool Counters techdocs.broadcom.com
- man ovs-vswitchd(8), bond/show et lacp/show openvswitch.org
- Nutanix Community, NIC Receive (RX) Missed Errors (2020) next.nutanix.com
- Expérience directe de l’auteur, en production (versions ci-dessus)