Comment résoudre les problèmes de perte de paquets NAT Hyper-V aux heures de pointe

Si vos machines virtuelles fonctionnent parfaitement le matin, mais commencent à saccader, à perdre des paquets ou à voir leur débit chuter drastiquement en période de forte activité, c’est un vrai casse-tête à résoudre. Généralement, le problème ne vient pas d’Hyper-V lui-même, mais de sa configuration sous-jacente, notamment la carte réseau et sa gestion du trafic. Pour corriger ce genre de situation, il suffit de quelques ajustements, principalement la désactivation de certaines fonctions de déchargement gênantes ou la mise à jour des pilotes. Si vous procédez correctement, c’est comme appuyer sur un interrupteur : tout rentre dans l’ordre. Voici donc un récapitulatif des solutions qui ont fonctionné par le passé et des pistes à explorer.

Comment résoudre les problèmes de réseau NIC et Hyper-V lors des pics de charge

Pourquoi cela se produit-il ?

En période de forte activité, les cartes réseau tentent d’optimiser leurs performances. Elles déchargent certaines tâches de calcul de sommes de contrôle, de fractionnement de paquets et de mise en file d’attente afin d’économiser des cycles CPU. Plutôt ingénieux, non ? Mais en réalité, surtout avec des pilotes anciens ou génériques (et oui, Windows Update propose souvent une version lente et boguée), ces processus de déchargement peuvent parfois se chevaucher au niveau du commutateur virtuel. Les sommes de contrôle sont alors altérées, les données arrivent corrompues et votre réseau de machines virtuelles devient soudainement très instable. Le principal responsable est VMQ, la technologie de file d’attente des machines virtuelles qui répartit la charge entre les cœurs. Si le pilote ou le matériel est défaillant, cela peut entraîner une corruption des paquets uniquement en cas de forte charge, lorsque tous les processus de déchargement sont saturés.

La solution consiste donc à désactiver ou à mettre à jour ces processus de déchargement. C’est ce qui a fonctionné pour moi, du moins dans la plupart des cas.

Solution 1 – Mettez à jour le pilote de votre carte réseau auprès du fournisseur.

C’est une évidence, mais on l’oublie souvent. Les pilotes obsolètes sont généralement à l’origine de tous ces bugs de déchargement amplifiés. Ne vous fiez pas uniquement à Windows Update ; consultez directement le site web du fabricant de votre matériel. Il propose souvent un pilote plus récent et optimisé qui corrige les problèmes connus.

Ouvrez le Gestionnaire de périphériques et trouvez votre carte réseau ; repérez le modèle exact afin de télécharger le pilote approprié.
Rendez-vous sur le site web du fabricant — Intel, Broadcom, Realtek, quel que soit celui qui a fabriqué votre carte réseau.
Téléchargez le pilote le plus récent correspondant à votre modèle et à votre version de Windows. Il se trouve parfois dans la section « Derniers téléchargements de support ».
Exécutez le programme d’installation, puis redémarrez. Oui, il se peut qu’un redémarrage soit demandé, mais croyez-moi, les pilotes Windows génériques sont souvent obsolètes ou ne comportent pas le correctif essentiel.

Sur certaines configurations, j’ai constaté que Windows Update installe un pilote plus ancien qui aggrave le problème. L’utilisation du pilote le plus récent du fabricant résout généralement le problème, ou du moins améliore la situation.

Solution 2 – Désactiver VMQ sur la carte réseau physique

Si la mise à jour du pilote n’a pas résolu le problème, la prochaine étape consiste à désactiver VMQ. Pour une configuration à hôte unique, l’impact est faible, mais cela peut réduire considérablement la corruption des paquets lors des pics de charge.

Ouvrez PowerShell en tant qu’administrateur ( Windows + Xpuis choisissez Terminal (Admin) ).
Vérifiez l’état de VMQ avec :Get-NetAdapterVmq
Identifiez votre carte réseau physique, généralement étiquetée « Ethernet » ou similaire.
Désactivez VMQ pour cette carte réseau avec :Disable-NetAdapterVmq -Name "Ethernet"

Vous pouvez également effectuer la même opération via l’interface graphique : ouvrez le Gestionnaire de périphériques, localisez votre carte réseau, accédez à l’ onglet Avancé et désactivez les files d’attente de machines virtuelles. Le résultat est identique. Attention : le comportement peut varier selon les cartes réseau ou les pilotes, et un redémarrage peut parfois être nécessaire pour que les modifications soient prises en compte.

Cette étape s’est avérée utile dans de nombreux cas, notamment avec les anciennes cartes réseau Intel ou Broadcom. Il s’agit simplement de désactiver le déchargement instable, ce qui peut s’avérer salvateur.

Correctif 3 – Désactiver les fonctions de déchargement TCP

Si VMQ n’est pas en cause, le problème vient peut-être des moteurs de déchargement TCP. Ces fonctionnalités, comme le déchargement des envois volumineux et le déchargement des sommes de contrôle, sont conçues pour accélérer le traitement, mais en cas de forte charge, elles peuvent générer des paquets corrompus.

Dans le Gestionnaire de périphériques, développez Cartes réseau. Trouvez votre carte réseau, cliquez avec le bouton droit > Propriétés.
Passez à l’ onglet Avancé.
Modifiez les paramètres suivants et désactivez-les :

Déchargement d’envoi volumineux V2 (IPv4)
Déchargement d’envoi volumineux V2 (IPv6)
Déchargement de la somme de contrôle TCP
Déchargement de la somme de contrôle UDP

Ce réglage sacrifie légèrement l’efficacité du processeur au profit d’une gestion des paquets bien plus fiable en cas de forte charge. Pour la plupart des configurations, le gain est largement justifié et vous constaterez probablement une stabilité de votre débit pendant les heures de pointe. Vous désactivez certains mécanismes de déchargement utilisés par la carte réseau pour contourner les limitations, mais ces mécanismes ont souvent pour effet inverse de corrompre les trames.

Correctif 4 – Désactiver RSC (Receive Segment Coalescing) sur le commutateur virtuel

RSC est censé améliorer les performances du processeur en regroupant les paquets, mais il provoque depuis un certain temps des problèmes de débit et d’intégrité des paquets sur Hyper-V. C’est assez étrange, mais le désactiver pourrait résoudre le problème de corruption des paquets lors des pics de charge.

Ouvrez PowerShell en tant qu’administrateur.
Vérifiez le paramètre actuel avec :Get-VMSwitch | Select Name, SoftwareRscEnabled
Si cette fonction est activée, désactivez-la :

Set-VMSwitch -Name "YourSwitchName" -EnableSoftwareRsc $false

Ensuite, effectuez des tests de charge : si la corruption de paquets cesse à des charges élevées, c’était bien le problème. Remarque : remplacez YourSwitchName par le nom réel de votre commutateur, que vous pouvez afficher avec la commande `ls` Get-VMSwitch. Dans de nombreuses configurations, désactiver RSC assure la stabilité du réseau.

Correctif 5 – Correspondance bout à bout des trames MTU et Jumbo

Ce problème est sournois : si la MTU ou les trames Jumbo ne correspondent pas entre vos appareils, des fragments de paquets apparaissent et sont souvent confondus avec une perte ou une corruption de paquets. En période de forte affluence, cette incompatibilité est la première cause de ralentissements ou de comportements anormaux.

Dans le Gestionnaire de périphériques, accédez à l’onglet Avancé de votre carte réseau et recherchez Jumbo Packet.
Si les trames jumbo sont activées sur l’hôte mais pas sur votre commutateur ou routeur, les trames seront tronquées ou perdues. La meilleure solution ? Configurer la même MTU partout : activez les trames jumbo partout (si votre réseau le prend en charge) ou désactivez-les complètement et restez à 1 500 octets.

Pour vérifier ou modifier la MTU en ligne de commande :

netsh interface ipv4 show subinterfaces

netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent

Même chose pour IPv6 si nécessaire. L’uniformisation des paramètres de tous les appareils évite la fragmentation et le chaos qui s’aggravent en cas de forte charge, notamment lors des pics de trafic.

Comment maintenir la stabilité ?

Téléchargez toujours les pilotes réseau directement auprès du fournisseur, et non via Windows Update. Les pilotes obsolètes sont souvent la cause insidieuse de ces bugs.
Désactivez VMQ dès le départ si les cartes réseau sont anciennes ou si les pilotes sont instables. Mieux vaut prévenir que guérir.
Harmonisez les paramètres MTU et de trame jumbo sur tous les commutateurs, routeurs et machines virtuelles pour éviter que cela ne soit ignoré.
Effectuez des tests de charge sur votre réseau avant le déploiement afin de détecter ces problèmes au plus tôt — un commutateur peut fonctionner correctement au repos, mais se transformer en catastrophe lorsqu’il est sollicité.

Les gens demandent aussi

Pourquoi Hyper-V perd-il des paquets en cas de forte charge ?

Le plus souvent, ce sont les fonctions d’accélération matérielle de la carte réseau qui sont en cause. VMQ, l’accélération des envois volumineux ou l’accélération du calcul des sommes de contrôle, qui permettent d’accélérer le trafic en cas de faible charge, ont tendance à dysfonctionner ou à se corrompre lorsque le trafic atteint des niveaux critiques. La désactivation de ces fonctions permet généralement de résoudre le problème de la transmission des paquets.

Dois-je désactiver VMQ sur Hyper-V ?

Si vous n’utilisez qu’un seul hôte ou rencontrez des problèmes, oui, surtout avec des cartes réseau ou des pilotes anciens. Bien que VMQ soit utile pour les serveurs multi-cartes réseau en répartissant la charge, il peut engendrer plus de problèmes qu’il n’en résout sur une configuration simple. Désactiver VMQ permet souvent de résoudre les pertes de paquets aléatoires ou la corruption de données en cas de forte charge, sans baisse de performance perceptible.

La désactivation du déchargement TCP ralentit-elle les choses ?

En quelque sorte, oui. Cela reporte une partie de la charge du processeur sur celui-ci, mais sur les processeurs modernes, l’impact est minime. Généralement, la stabilité et la sécurité du trafic compensent largement ce léger sacrifice de performance. La plupart des configurations ne remarqueront même pas la différence, mais les paquets corrompus ? C’est une autre histoire.

J’espère que ces astuces vous éviteront de passer des heures à traquer des problèmes de réseau fantômes aux heures de pointe. Parfois, une simple mise à jour de pilote ou une modification rapide suffit à résoudre le problème plus vite qu’on ne le pense. Bonne chance !