Comment savoir quel MTU est utilisé dans Windows XP

Question

Je souffre d'un problème vraiment étrange où j'obtiens au hasard des erreurs "La connexion au serveur a été réinitialisée" lors d'une tentative d'accès à des pages Web (erreur HTTP 12031 selon l'outil de diagnostic réseau de Windows) - que la page Web soit ou non J'essaie d'accéder à Internet externe ou même à partir d'une instance Apache locale s'exécutant sur localhost. Il affecte tous les ordinateurs de notre réseau local (Ethernet, non sans fil), qui exécutent tous Windows XP.

On m'a suggéré que cela pourrait être lié au MTU utilisé sur le trafic réseau. Si je fais le test de ping pour trouver le plus gros paquet pouvant passer sans fragmentation, je peux envoyer une requête de ping à l'hôte local avec un paquet de 1492 octets (+28 octets pour un en-tête?) et je peux envoyer une requête ping à notre routeur avec un paquet de 1462 octets (soit 1490 octets lorsque vous incluez l’en-tête de 28 octets). Si j'essaie d'envoyer un ping à l'extérieur, comme Google, je ne peux rien obtenir de plus grand que 1430 (ce qui correspond à 1458 avec l'en-tête).

J'ai essayé de suivre diverses instructions pour mettre à jour le registre Windows XP avec ce paramètre de MTU, en mettant à jour HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU. J'ai essayé sans limite de valeurs alternatives: la valeur correcte la plus évidente semble être 1490, mais j'ai aussi essayé 1462, 1458, 1430, etc., etc. Lorsque je redémarre l'ordinateur pour que les modifications prennent effet, semble fonctionner pendant quelques minutes (difficile à dire avec certitude, car il est toujours aléatoire plutôt que cohérent), mais cela ne dure jamais longtemps.

Initialement, lorsque j'essayais d'utiliser une valeur 1430, après quelques minutes de bon fonctionnement, les résultats du test Ping diminuaient de 28 octets. Soudain, je me rendais compte que je ne pouvais obtenir qu'un package de 1402 octets via Google. Si j'ai mis à jour le paramètre de registre MTU sur 1402, lorsque j'ai redémarré et que j'ai attendu quelques minutes, il s'agirait alors de 1374, puis 1346, etc. Les autres ordinateurs du réseau ne sont pas affectés (toujours à 14 h 30) et suppriment le paramètre MTU. à partir du registre restaurerait les choses à la normale (et toujours cassé).

Ce que je trouve le plus difficile à diagnostiquer, c’est qu’il est très difficile de savoir si je joue même avec le bon paramètre de registre. Donc, au plus simple, ma question serait: Comment puis-je savoir quel paramètre de MTU Windows essaie d’utiliser?

De plus, si quelqu'un a des idées sur la raison pour laquelle le MTU continue de baisser de 28, cela serait également utile (par exemple, y a-t-il un fichier journal Windows à un endroit où il enregistrera quelque chose au moment où la valeur changera?)

Enfin, si quelqu'un peut me dire définitivement comment définir le paramètre MTU que je devrais essayer d'utiliser, ce serait formidable!

Ian Boyd · Accepted Answer

Pour Windows 7, Windows Vista et Windows XP, le MTU de diverses interfaces est disponible à partir de Windows lui-même à l'aide de netsh.

Windows 7, Windows Vista

Pour afficher le courant MTU sous 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

Remarque: Dans cet exemple, ma connexion au réseau local . L'interface IPv6 a un MTU aussi bas (1280) parce que j'utilise un service de tunnel pour obtenir la connectivité IPv6 .

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

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

Testé avec Windows 7 Service Pack 1

Windows XP

La syntaxe 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

Remarque: Windows XP nécessite que le service Routage et accès distant soit démarré avant de pouvoir afficher les détails relatifs à une interface (y compris 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:

suivez les instructions de KB283165 - Comment modifier la taille du MTU PPPoE dans Windows XP
utilise Dr. TCP ( Remarque: Windows 2000/XP uniquement)

Testé avec Windows XP Service Pack 3

Voir également

Brève discussion sur ce qu'est le 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 d'indicateurs, 4 octets pour l'adresse IP source et 4 octets pour l'adresse IP de 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 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 nécessaires pour envoyer un paquet ping.

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

>ping -l 1472 obsidian

Ensuite, le paquet Ethernet résultant sera plein jusqu'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 octet supplémentaire

>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 produira dans les coulisses, idéalement à votre insu.

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

>ping -l 1473 -f obsidian

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

>ping -l 1473 -f obsidian Packet needs to be fragmented but DF set.

Le paquet doit être fragmenté, mais l'indicateur Ne pas fragmenter a été défini.

Si un paquet doit être fragmenté à un endroit quelconque de la ligne, le réseau envoie un paquet ICMP vous indiquant qu'une fragmentation s'est produite. Votre machine reçoit ce paquet ICMP, est informée de la taille la plus grande et est supposée arrêter d'envoyer des paquets trop volumineux. Malheureusement, la plupart des pare-feu bloquent ces paquets ICMP "Path MTU discovery", de sorte que votre ordinateur ne réalise jamais que les paquets sont fragmentés (ou pire: abandonnés car ils ne pouvaient pas être fragmentés).

C'est ce qui empêche le serveur Web de fonctionner. Vous pouvez obtenir les petites réponses initiales (<1280 octets), mais les paquets plus volumineux ne peuvent pas passer. Et les pare-feu du serveur Web sont mal configurés, bloquant les paquets ICMP. Donc, 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 dans IPv6, tout le monde est requis pour autoriser (correctement) les paquets de découverte ICMP mtu.

JMM · Answer

@ian Je ne suis pas sûr que netsh indique réellement le MTU actuellement utilisé. Sur mon ordinateur Windows XP Pro SP3, j'ai exécuté netsh interface ip show interface et la valeur MTU indiquée pour l'interface correspondante é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 indique que le fait de définir EnablePMTUDiscovery sur 0 définira MTU sur 576.

La définition de l'entrée de registre MTU définit manuellement la MTU. J'ai essayé plusieurs valeurs pour l'entrée MTU (en redémarrant à chaque fois).

Dans les deux cas - en ajoutant la première entrée, puis la seconde - netsh, le MTU était toujours égal à 1500. Les tests avec ping ont confirmé (ou au moins suggéré) que la valeur de MTU configurée dans le registre était effectivement utilisée.

De plus, lorsque j'ai essayé ceci pour la première fois sur ma machine, le service Routage et accès à distance était désactivé et je ne pouvais donc pas le démarrer en suivant vos instructions. Je l'ai activé en accédant à Panneau de configuration> Outils d'administration> Gestion de l'ordinateur> Services et applications> Services. J'ai changé le "Type de démarrage" de Disabled en Manuel. J'ai ensuite lancé le service à partir de ce dialogue également.

Je ne suis pas sûr non plus que KB283165 soit nécessairement les instructions correctes pour changer le MTU. Ces instructions ne sont-elles pas uniquement pertinentes lors de l'exécution du client Windows PPPoE? 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 et qui m'ont amené à apporter les modifications ci-dessus au registre étaient les suivantes: KB900926: paramètres TCP/IP recommandés pour WAN liens avec une taille de MTU inférieure que 576 (méthodes 2 et 3).

Edité par @ian

On dirait que tu as raison. Configurez pour 1 200, mais netsh rapporte 1500.

enter image description here

>ping -l 1173 -f obsidian Packet needs to be fragmented but DF set.

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

T. Kaltnekar · Answer

Vous pouvez trouver MTU à l'aide de ping avec une approche d'essai et d'erreur:

ping <address> -f -l nnnn

Ping :

-f: Spécifie que les messages de demande d'écho sont envoyés avec l'indicateur Ne pas fragmenter dans l'en-tête IP défini sur 1. Le message de demande d'écho ne peut pas être fragmenté par les routeurs dans le chemin d'accès à la destination. Ce paramètre est utile pour résoudre les problèmes de PMTU (Maximum Transmission Unit) 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 taille par défaut est 32. La taille maximale est 65 527.

Vous obtiendrez le message "Le paquet doit être fragmenté mais DF set" lorsque la longueur est trop grande.

nik · Answer

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

Il existe une référence de code VB ici .
Il existe également un outil appelé DrTCP :

alt text

Dans le registre,

Aller au HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
Ouvrez l'adaptateur qui vous intéresse
Copier la chaîne ServiceName
Recherchez cette chaîne dans HKLM\System; vous ferez correspondre une clé NetCfgInstanceId
Un peu plus haut, ce sera la clé MaxFrameSize (le mien montre 1514)

Il existe également un moyen de changer cela avec la commande netsh.

Vérifiez également votre configuration Path MTU Discovery .

harrymc · Answer

Voir AdapterWatch :

AdapterWatch affiche des informations utiles sur vos cartes 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, etc. En outre, il affiche les statistiques générales TCP/IP/UDP/ICMP de votre ordinateur local.