Comment savoir quel MTU est utilisé dans Windows XP

Pour Windows 7, Windows Vista et Windows XP, le MTU pour les différentes interfaces est disponible à partir de Windows lui-même en utilisant netsh.

Windows 7, Windows Vista

Pour afficher la MTU actuelle sur Windows 7 ou Windows Vista, à partir d'une invite de commande :

C:\Users\Ian>netsh interface ipv6 show subinterfaces

       MTU MediaSenseState Bytes In Bytes Out Interface
---------- --------------- --------- --------- -------------
      1280 1 24321220 6455865 Local Area Connection
4294967295 1 0 1060111 Loopback Pseudo-Interface 1
      1280 5 0 0 isatap.newland.com
      1280 5 0 0 6TO4 Adapter

Et pour les interfaces IPv4 :

C:\Users\Ian>netsh interface ipv4 show subinterfaces

       MTU MediaSenseState Bytes In Bytes Out Interface
---------- --------------- --------- --------- -------------
      1500 1 146289608 29200474 Local Area Connection
4294967295 1 0 54933 Loopback Pseudo-Interface 1

Note: Dans cet exemple, mon interface de connexion au réseau local IPv6 a une MTU si basse (1280) parce que j'utilise un service de tunnel pour obtenir la connectivité IPv6 .

Vous pouvez également changer votre MTU (Windows 7, Windows Vista). À partir d'une invite de commande elevated :

>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.

Testé avec Windows 7 Service Pack 1

Windows XP

La syntaxe de netsh pour Windows XP est légèrement différente :

C:\Users\Ian>netsh interface ip show interface

Index: 1
User-friendly Name: Loopback
Type: Loopback
MTU: 32767
Physical Address:                       

Index: 2
User-friendly Name: Local Area Connection
Type: Etherenet
MTU: 1500
Physical Address: 00-03-FF-D9-28-B7

Note : ** Windows XP exige que le service **Routage et accès à distance soit lancé avant que vous puissiez voir les détails d'une interface (y compris le MTU) :

C:\Users\Ian>net start remoteaccesss

Windows XP ne permet pas de modifier le paramètre MTU à partir de netsh. Pour cela, vous pouvez :

• suivre les instructions de KB283165 - Comment modifier la taille de la MTU PPPoE dans Windows XP
• utiliser Dr. TCP ( Note: Windows 2000/XP uniquement)

Testé avec Windows XP Service Pack 3

Voir aussi

• Configurer la taille maximale de l'unité de transfert (MTU) TCPIP dans Vista
• Régler la MTU dans Windows Vista
• Modifier les paramètres de la MTU Aide !
• KB283165 - Comment modifier la taille de la MTU PPPoE dans Windows XP
• DSLReports - DrTCP

Brève discussion sur la nature de la MTU, d'où proviennent les 28 octets.

Votre carte réseau (Ethernet) a une taille de paquet maximale de 1,500 bytes :

+---------+
| 1500 |
| byte |
| payload |
| |
| |
| |
+---------+

La partie IP de TCP/IP nécessite un en-tête de 20 octets (12 octets de drapeaux, 4 octets pour l'adresse IP source, 4 octets pour l'adresse IP destination). Cela laisse moins d'espace disponible dans le paquet :

+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |- IP header: 20 bytes
| 4 byte to address | /
|------------------------|
| 1480 byte payload |
| |
| |
| |
+------------------------+

Maintenant, un paquet ICMP (ping) a un en-tête de 8 octets (1 octet type, 1 octet code, 2 octets checksum, 4 octets de données supplémentaires) :

+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |
| 4 byte to address | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header | /
|------------------------|
| 1472 byte payload |
| |
| |
| |
+------------------------+

C'est là que se trouvent les 28 octets “manquants” - c'est la taille des en-têtes requis pour envoyer un paquet ping.

Lorsque vous envoyez un paquet ping, vous pouvez spécifier la quantité de données utiles extra que vous souhaitez inclure. Dans ce cas, si vous incluez la totalité des 1472 octets :

>ping -l 1472 obsidian

Alors le paquet ethernet résultant sera plein aux branchies. Chaque dernier octet du paquet de 1500 octets sera rempli :

+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |
| 4 byte to address | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header | /
|------------------------|
|........................|
|........................|
|. 1472 bytes of junk....|
|........................|
|........................|
|........................|
|........................|
+------------------------+

Si vous essayez d'envoyer un autre octet

>ping -l 1473 obsidian

le réseau devra fragmenter ce paquet de 1501 octets en plusieurs paquets :

Packet 1 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address | |
| 4 byte to address | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header | /
|------------------------|
|........................|
|........................|
|..1472 bytes of payload.|
|........................|
|........................|
|........................|
|........................|
+------------------------+

Packet 2 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address | |
| 4 byte to address | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header | /
|------------------------|
|. |
| 1 byte of payload |
| |
| |
| |
| |
| |
+------------------------+

Cette fragmentation se fera en coulisses, idéalement sans que vous le sachiez.

Mais vous pouvez être méchant, et dire au réseau que le paquet ne doit pas être fragmenté :

>ping -l 1473 -f obsidian

Le drapeau -f signifie ne pas fragmenter. Maintenant, lorsque vous essayez d'envoyer un paquet qui ne tient pas sur le réseau, vous obtenez l'erreur :

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

Le paquet doit être fragmenté, mais le drapeau Do not Fragment a été activé.

Si un paquet doit être fragmenté, le réseau envoie en fait un paquet ICMP vous indiquant qu'une fragmentation a eu lieu. Votre machine reçoit ce paquet ICMP, on lui dit quelle était la plus grande taille et elle est censée arrêter d'envoyer des paquets trop gros. Malheureusement, la plupart des pare-feux bloquent ces paquets ICMP “Path MTU discovery”, de sorte que votre machine ne se rend jamais compte que les paquets sont fragmentés (ou pire : abandonnés parce qu'ils n'ont pas pu être fragmentés).

C'est ce qui fait que le serveur web ne fonctionne pas. Vous pouvez obtenir les petites réponses initiales (<1280 octets), mais les gros paquets ne peuvent pas passer. Et les pare-feux du serveur web sont mal configurés, bloquant les paquets ICMP. Ainsi, le serveur web ne réalise pas que vous n'avez jamais reçu le paquet.

La fragmentation des paquets n'est pas autorisée en IPv6, tout le monde est requis pour autoriser (correctement) les paquets de découverte mtu ICMP.

@ian Je ne suis pas sûr que netsh indique réellement le MTU actuellement utilisé. Sur ma machine Windows XP Pro SP3, j'ai exécuté netsh interface ip show interface et la valeur du MTU pour l'interface concernée était 1500. J'ai ensuite ajouté les clés de registre suivantes :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery
    value: 0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{ID}\MTU 
    value: various (e.g. 1200)

Microsoft dit que le fait de mettre EnablePMTUDiscovery à 0 fixera la MTU à 576.

Le fait de définir l'entrée de registre MTU règle le MTU manuellement. J'ai essayé plusieurs valeurs pour l'entrée MTU (en redémarrant à chaque fois).

Dans les deux cas – ajout de la première entrée, puis de la deuxième – netsh a quand même rapporté la MTU comme étant 1500. Les tests avec ping ont confirmé (ou du moins suggéré) que la valeur MTU configurée dans le registre était effectivement utilisée.

Aussi, lorsque j'ai essayé pour la première fois sur ma machine, le service de routage et d'accès à distance était désactivé, donc je n'ai pas pu le démarrer en utilisant vos instructions. Je l'ai activé en allant dans le Panneau de configuration > Outils d'administration > Gestion de l'ordinateur > Services et applications > Services. J'ai changé le “Type de démarrage” de “Désactivé” à “Manuel”. J'ai ensuite démarré le service à partir de cette boîte de dialogue également.

Je ne suis pas non plus sûr que KB283165 soit nécessairement la bonne instruction pour changer le MTU. Ces instructions ne sont-elles pas pertinentes uniquement lorsque vous utilisez le client PPPoE de Windows ? Si vous vous connectez à Internet via un routeur dont le routeur est le client PPPoE (comme dans mon cas), ces instructions ne seraient pas pertinentes, n'est-ce pas ?

Les instructions que j'ai suivies, qui m'ont amené à apporter les modifications susmentionnées au registre, se trouvaient dans KB900926 : Paramètres TCP/IP recommandés pour les liens WAN avec une taille de MTU inférieure à 576 (méthodes 2 & 3).

Modifier par @ian

On dirait que vous avez raison. Configurer pour 1 200, mais netsh rapporte 1500.

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Donc je suppose que la réponse à la question originale est que sous Windows XP vous devez utiliser la fonction d'essai et d'erreur avec le drapeau Ne pas fragmenter pour trouver le plus gros paquet que vous pouvez envoyer. Ensuite, vous avez votre MTU.

Vous pouvez trouver MTU en utilisant ping avec une approche par essais et erreurs :

ping <address> -f -l nnnn

• Ping ** :

-f : Spécifie que les messages de demande d'écho sont envoyés avec l'indicateur “Don’t Fragment” dans l'en-tête IP réglé sur 1. Le message de demande d'écho ne peut pas être fragmenté par les routeurs sur le chemin de la destination. Ce paramètre est utile pour le dépannage des problèmes d'unité de transmission maximale (PMTU) du chemin.

-l Taille : Spécifie la longueur, en octets, du champ de données dans les messages de demande d'écho envoyés. La valeur par défaut est 32. La taille maximale est de 65 527.

Vous obtiendrez des messages “Packet needs to be fragmented but DF set” lorsque la longueur est trop importante.

Microsoft KB314496 : Les tailles MTU par défaut pour différentes topologies de réseau .
Vous ne devez pas essayer de jouer avec la configuration des MTU dans les configurations de réseau normales.

Il y a une référence de code VB ici ](http://www.codeproject.com/KB/IP/NetworkConfigTool.aspx).
Il existe également un outil appelé DrTCP :

Dans le registre,

• Allez à HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
• Ouvrez l'adaptateur qui vous intéresse
• Copiez la chaîne ServiceName
• Cherchez cette chaîne dans HKLM\System ; vous obtiendrez une clé NetCfgInstanceId
• Un peu plus haut se trouvera la clé MaxFrameSize (la mienne indique 1514)

Il y a aussi un moyen de changer cela avec la commande netsh.

Aussi, vérifiez votre Configuration de découverte du chemin MTU .

Voir AdapterWatch :

AdapterWatch affiche des informations utiles sur vos adaptateurs réseau : Adresses IP, Adresse matérielle, Serveurs WINS, Serveurs DNS, Valeur MTU, Nombre d'octets reçus ou envoyés, Vitesse de transfert actuelle, et plus encore. En outre, il affiche des statistiques générales TCP/IP/UDP/ICMP pour votre ordinateur local.