Windows Server 2016 : désactiver les Jumbo Frames sur VMs Hyper‑V et VMware (MTU 1500, « Jumbo Packet »)

Des lenteurs réseau sur vos VMs Windows Server 2016 ? Si l’on vous recommande de « désactiver les jumbo frames », cela signifie revenir à une MTU standard de 1500 octets sur tous les maillons : VM, vNIC de l’hôte, carte physique et équipements en face. Voici la méthode fiable, étape par étape.

Sommaire

Vue d’ensemble de la question

Dans certaines cartes réseau Windows, la propriété « Jumbo Packet » ne propose pas « Disabled », uniquement des tailles (par ex. 4088, 9014…). Cette absence prête à confusion : comment “désactiver” ? Sur Windows, désactiver les jumbo frames revient à rétablir une MTU de 1500 octets côté système et, si le pilote l’expose, à sélectionner la plus petite valeur dans « Jumbo Packet ». L’essentiel est d’assurer une homogénéité de bout en bout : tous les segments doivent parler MTU 1500 pour éviter la fragmentation et les retransmissions.

Idée clé : fixez MTU 1500 partout (VM, vNIC de l’hôte, NIC physique, vSwitch/port‑group côté hyperviseur, switch/routeur en face). Si « Jumbo Packet » n’a pas « Disabled », prenez la plus petite valeur affichée et vérifiez la MTU effective avec PowerShell.

Réponse et solution

Sur Hyper‑V

Le commutateur virtuel Hyper‑V ne possède pas de réglage MTU propre ; la MTU se gère sur les interfaces : vNIC des VMs, vNIC de l’hôte (interface vEthernet (...)) et NIC(s) physique(s) raccordées au vSwitch. Si vous utilisez un Team (LBFO) ou Switch Embedded Teaming (SET), appliquez la MTU sur chaque NIC physique membre et sur la vNIC d’hôte.

Dans la machine virtuelle Windows Server 2016

Exécutez en PowerShell (administrateur) :

# Afficher la MTU courante (IPv4 et IPv6)
Get-NetIPInterface | Format-Table ifIndex, InterfaceAlias, AddressFamily, NlMtuBytes

# Revenir à MTU standard 1500 sur l'interface "Ethernet"

Set-NetIPInterface -InterfaceAlias "Ethernet" -NlMtuBytes 1500

# Inspecter les propriétés avancées exposées par le pilote

Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object DisplayName -match 'Jumbo|MTU'

Alternative (équivalente) en netsh si vous préférez une commande explicite par pile :

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

Si le pilote propose « Jumbo Packet » sans option « Disabled », choisissez la plus petite taille de la liste (par ex. 1500/1514 selon le constructeur). Cela garantit l’alignement avec la MTU système.

Sur l’hôte Hyper‑V

Appliquez 1500 à la NIC physique connectée au vSwitch externe, à la vNIC d’hôte (vEthernet (NomDuSwitch)) et à chaque membre d’un Team/SET le cas échéant.

# NIC physique attachée au vSwitch externe
Set-NetIPInterface -InterfaceAlias "Ethernet" -NlMtuBytes 1500

# vNIC d'hôte créée par le vSwitch externe

Set-NetIPInterface -InterfaceAlias "vEthernet (NomDuSwitch)" -NlMtuBytes 1500

# Facultatif : si le pilote expose "Jumbo Packet", choisir la plus petite valeur

Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object DisplayName -match 'Jumbo|MTU'

Si vous utilisez un Team classique (LBFO) ou SET :

# Exemple : forcer MTU 1500 sur tous les membres d'un Team/SET
Get-NetAdapter -Physical | Where-Object {$_.Status -eq 'Up'} |
  ForEach-Object {
    try {
      Set-NetIPInterface -InterfaceAlias $_.Name -NlMtuBytes 1500 -ErrorAction Stop
    } catch {
      Write-Host "Échec sur $($_.Name) : $($_.Exception.Message)"
    }
  }

Rappel important : il n’existe pas de Set-VMSwitch pour « Jumbo Packet ». Tout se passe au niveau des adaptateurs.

Redémarrage de l’interface

Certains pilotes nécessitent un cycle OFF/ON de l’interface pour appliquer la MTU :

Disable-NetAdapter -Name "Ethernet" -Confirm:$false
Enable-NetAdapter  -Name "Ethernet"

Vous pouvez aussi redémarrer proprement la VM si la fenêtre de maintenance le permet.

Sur VMware ESXi et autres hyperviseurs

Sur ESXi, la MTU se configure à plusieurs niveaux : vSwitch, port‑group et VMkernel NIC (vmkX). Pour “désactiver” les jumbo frames, ramenez ces valeurs à 1500 ; dans l’OS invité Windows, fixez également 1500.

# Sur l'hôte ESXi en SSH (exemples)
# vSwitch standard
esxcli network vswitch standard set --mtu 1500 --vswitch-name vSwitch0

# Port-group standard

esxcli network vswitch standard portgroup set --portgroup-name "PG-VM" --vlan-id 0

# La MTU du port-group hérite du vSwitch sur standard ; vérifiez l'homogénéité.

# VMkernel NIC (ex. vmk0)

esxcli network ip interface set --mtu 1500 --interfacename vmk0

Dans la VM Windows invitée, utilisez les mêmes commandes PowerShell/netsh que ci‑dessus pour revenir à MTU 1500. Pensez aussi à l’équipement physique en face (switch, routeur) : toute valeur différente (par exemple 9000 côté switch) romprait l’homogénéité.

Vérification technique

Contrôlez d’abord ce que pense Windows :

Get-NetIPInterface | Format-Table ifIndex, InterfaceAlias, AddressFamily, NlMtuBytes

Testez ensuite la MTU de bout en bout avec ICMP :

IPv4 : 1472 octets de charge utile correspondent à 1500 octets sur le fil (1472 + 28 d’en‑têtes IP+ICMP). Utilisez le drapeau « Don’t Fragment ».

ping &lt;IP-cible&gt; -f -l 1472

IPv6 : la charge utile pour 1500 est 1452 octets (1500 − 40 IPv6 − 8 ICMPv6). Le paramètre -f n’est pas requis en IPv6.

ping -6 &lt;IP-cible&gt; -l 1452

Le test doit réussir sans fragmentation/erreur Packet too big. S’il échoue, un maillon impose une MTU inférieure ; réduisez temporairement la charge utile jusqu’à trouver la limite, puis corrigez l’élément fautif.

Tableau de synthèse

Composant	Où régler	Valeur pour désactiver Jumbo	Commande ou action
VM Windows Server 2016	Interface réseau de la VM	MTU 1500	`Set-NetIPInterface -NlMtuBytes 1500` ou `netsh ... mtu=1500`
vNIC d’hôte Hyper‑V	Interface `vEthernet (...)`	MTU 1500	`Set-NetIPInterface -InterfaceAlias "vEthernet (...)" -NlMtuBytes 1500`
NIC physique hôte	Interface physique et propriété pilote	MTU 1500 et « Jumbo Packet » à la plus petite valeur	PowerShell et/ou Gestionnaire de périphériques
Hyper‑V vSwitch	N/A	N/A	Pas de réglage MTU au niveau du vSwitch
ESXi vSwitch	vSwitch/port‑group	MTU 1500	`esxcli network vswitch standard set --mtu 1500 ...`
ESXi VMkernel	vmkX	MTU 1500	`esxcli network ip interface set --mtu 1500 --interfacename vmk0`
Switch/Routeur	Ports connectés	MTU 1500	Configurer chaque port concerné

Scripts prêts à l’emploi

Application sur toutes les interfaces actives

# Forcer MTU 1500 sur toutes les interfaces "Up" (IPv4 et IPv6)
$ifaces = Get-NetIPInterface | Where-Object {$_.ConnectionState -eq 'Connected'}
foreach ($iface in $ifaces) {
  try {
    Set-NetIPInterface -InterfaceIndex $iface.ifIndex -NlMtuBytes 1500 -ErrorAction Stop
  } catch {
    Write-Host "Échec sur $($iface.InterfaceAlias) [$($iface.AddressFamily)] : $($_.Exception.Message)"
  }
}

# Désactiver/Réactiver chaque adaptateur pour s'assurer de la prise en compte

Get-NetAdapter | Where-Object {\$*.Status -eq 'Up'} | ForEach-Object {
Disable-NetAdapter -Name \$*.Name -Confirm:\$false
Enable-NetAdapter  -Name $\_.Name
}

Audit des valeurs “Jumbo Packet” côté pilote

# Liste des propriétés avancées liées à la MTU/Jumbo
Get-NetAdapter | ForEach-Object {
  Get-NetAdapterAdvancedProperty -Name $_.Name |
    Where-Object {$_.DisplayName -match 'Jumbo|MTU'} |
    Select-Object @{n='Adapter';e={$_.Name}}, DisplayName, DisplayValue
} | Format-Table -AutoSize

Recherche de la plus grande MTU sans fragmentation en IPv4

# Détecte la charge utile maximale ICMP (IPv4) sans fragmentation (binaire)
param([string]$Target = "8.8.8.8")

\$low = 0
\$high = 1472
while (\$low -lt \$high) {
\$mid = \[int]\((\$low + \$high + 1) / 2)
\$ping = ping \$Target -f -l \$mid -n 1 | Out-String
if (\$ping -match "TTL=") { \$low = \$mid } else { \$high = \$mid - 1 }
}
\$mtu = \$low + 28
"Charge utile max: \$low octets ; MTU effective estimée: \$mtu"

Comprendre la relation entre MTU et “Jumbo Packet”

La valeur « Jumbo Packet » dépend du pilote :

Certains pilotes n’affichent aucune option « Disabled » et ne proposent que des tailles (par ex. 4088, 9014…). La plus petite valeur désactive de facto les jumbo frames.
D’autres montrent 1514 au lieu de 1500 (différence liée à l’en‑tête Ethernet). Choisissez 1514 dans ce cas.
Quelques‑uns exposent explicitement « Disabled » : sélectionnez‑la et assurez‑vous que la MTU Windows reste à 1500.

Style de pilote	Valeur à sélectionner	Remarques
Liste numérique (4088, 9014…)	Plus petite valeur disponible	Confirmez avec `Get-NetIPInterface` que la MTU est bien 1500
Liste avec 1514	1514	Correspond à 1500 utiles + en‑tête Ethernet
Option « Disabled »	Disabled + MTU Windows à 1500	Le plus simple si proposé

Pièges fréquents

Mélanger les MTU : un segment en 9000 entre deux segments en 1500 crée de la fragmentation ou des rejets. Harmonisez à 1500 partout si vous « désactivez les jumbo ».
Confondre MTU et offloads : LSO/LSOv2, RSC, RSS, vRSS, VMQ et SR‑IOV améliorent les performances mais ne changent pas la MTU. Les désactiver n’équivaut pas à désactiver les jumbo frames.
Oublier les overlays : VPN/IPsec, GRE, VXLAN ajoutent des en‑têtes. Une MTU logicielle à 1500 peut être trop élevée pour le chemin effectif. Ajustez ou laissez la PMTUD faire son travail et testez avec ping.
Team/SET non aligné : tous les membres du Team doivent partager la même MTU et la même valeur « Jumbo Packet ».
SR‑IOV : si activé, la VM s’appuie quasi directement sur la NIC physique. Assurez‑vous que la MTU/Jumbo de la NIC physique est cohérente.
Changements non pris en compte : après modification, redémarrez l’interface ou la VM ; certains pilotes n’appliquent la MTU qu’après un reset du lien.

Dépannage des lenteurs réseau après la remise en MTU standard

Si les lenteurs persistent malgré le retour à 1500, explorez ces pistes :

Débit et latence : utilisez un outil de mesure (par ex. iperf3) entre la VM et une sonde de référence pour isoler un goulot d’étranglement.
Offloads : vérifiez LSO/RSC. Dans certains cas pathologiques, désactiver temporairement LSO peut stabiliser des flux TCP mal gérés par un firmware ancien.
QoS ou shaping : une politique QoS peut limiter les débits. Contrôlez les stratégies locales et côté réseau.
Drivers et firmwares : mettez à jour les pilotes NIC (hôte et invité) et le firmware du switch. Les anomalies MTU/Jumbo sont souvent corrigées par des mises à jour.
Chemin end‑to‑end : le test ping -f -l 1472 doit passer dans les deux sens. S’il ne passe que dans un sens, suspectez un filtrage ICMP ou un segment asynchrone différent.

Questions et réponses rapides

La case « Jumbo Packet » n’a pas « Disabled », est‑ce grave ?
Non. Sélectionnez la plus petite valeur et fixez MTU=1500 avec PowerShell/netsh : vous êtes en configuration standard.

Dois‑je changer quelque chose sur le vSwitch Hyper‑V ?
Non, il n’expose pas de MTU configurable. Agissez sur les vNICs et les NICs physiques.

Et si mon fournisseur réseau impose une MTU inférieure à 1500 ?
Il faut aligner vers le bas partout (ex. 1492 avec PPPoE). Déterminez la MTU maximale tolérée par le chemin puis uniformisez.

Changer la MTU nécessite un redémarrage du serveur ?
Généralement non ; un OFF/ON de l’interface suffit. Certains pilotes exigent toutefois un redémarrage.

Exemples concrets complets

Remise à plat d’une VM Windows

Ouvrez PowerShell en administrateur.
Set-NetIPInterface -InterfaceAlias "Ethernet" -NlMtuBytes 1500.
Dans le Gestionnaire de périphériques > Carte réseau > Avancé, mettez « Jumbo Packet » sur la plus petite valeur proposée (1500/1514).
Désactivez/réactivez l’interface (ou redémarrez la VM).
Vérifiez avec Get-NetIPInterface et ping -f -l 1472 <cible>.

Remise à plat d’un hôte Hyper‑V

Set-NetIPInterface -InterfaceAlias "vEthernet (Production)" -NlMtuBytes 1500.
Set-NetIPInterface -InterfaceAlias "Ethernet 1" -NlMtuBytes 1500 (la NIC physique).
Si Team/SET : appliquez 1500 à chaque membre.
Assurez‑vous que le switch physique en face est lui aussi en 1500.

Remise à plat côté ESXi

esxcli network vswitch standard set --mtu 1500 --vswitch-name vSwitch0.
Vérifiez le port‑group hébergeant la VM.
esxcli network ip interface set --mtu 1500 --interfacename vmk0.
Dans l’OS invité, revenez à 1500 comme expliqué.
Testez avec ICMP non fragmentable et validez les flux applicatifs.

Bonnes pratiques pour rester stable

Documentez la MTU cible et la chaîne des composants concernés.
Industrialisez les changements par script (PowerShell/Ansible/SCCM) pour éviter les oublis.
Surveillez les compteurs NIC (erreurs, paquets fragmentés, retransmissions TCP) après modification.
Validez avec un test applicatif représentatif (SMB, SQL, HTTP/HTTPS) en plus du ping.

Résumé exécutable

Pour “désactiver les jumbo frames” sur des VMs Windows Server 2016 :

Fixez MTU 1500 dans la VM (Set-NetIPInterface/netsh),
fixez MTU 1500 sur la vNIC d’hôte et la NIC physique Hyper‑V (ou vSwitch/port‑group/VMkernel en ESXi),
si la propriété Jumbo Packet existe, choisissez la plus petite valeur,
redémarrez l’interface et vérifiez par Get-NetIPInterface et ping -f -l 1472.

La clef est l’homogénéité de bout en bout : une chaîne 100 % en 1500 élimine les effets secondaires liés aux jumbo frames (pertes, réémissions, latences erratiques).

Annexe de vérification rapide

# VM et hôte : MTU = 1500
Get-NetIPInterface | Select-Object InterfaceAlias, AddressFamily, NlMtuBytes

# Test IPv4 non fragmentable

ping \ -f -l 1472

# Test IPv6

ping -6 \ -l 1452

En appliquant ces étapes, vous revenez à une base saine et prédictible, conforme aux attentes de la majorité des réseaux d’entreprise et des infrastructures cloud, tout en conservant la possibilité de réactiver des jumbo frames plus tard si votre environnement est intégralement compatible.

Windows Server 2016 : désactiver les Jumbo Frames sur VMs Hyper‑V et VMware (MTU 1500, « Jumbo Packet »)