Comment savoir quel MTU est utilisé dans Windows XP

Je souffre d'un problème vraiment étrange où j'obtiens au hasard des erreurs «La connexion au serveur a été réinitialisée» lorsque j'essaie d'accéder aux pages Web (erreur HTTP 12031 selon l'outil de diagnostic réseau Windows) - cela se produit indépendamment du fait que la page Web J'essaie d'accéder sur Internet externe ou même s'il s'agit d'une instance Apache locale exécutée sur localhost. Il affecte tous les ordinateurs de notre réseau local (Ethernet, pas sans fil), qui exécutent tous Windows XP.

Il m'a été suggéré que cela pourrait être lié au MTU utilisé sur le trafic réseau. Si je fais le test Ping pour découvrir le plus gros paquet qui peut passer par non fragmenté, je peux pinguer l'hôte local avec un paquet de 1492 octets (+28 octets pour un en-tête?) Et je peux pinguer notre routeur avec un paquet de 1462 octets (qui est de 1490 octets lorsque vous incluez l'en-tête de 28 octets). Si j'essaie de cingler quelque chose à l'extérieur comme Google, je ne peux rien obtenir de plus grand que 1430 (soit 1458 avec l'en-tête).

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

Initialement, lorsque j'essayais 1430 comme valeur, après quelques minutes de fonctionnement correct, les résultats du test Ping diminuaient de 28 octets - du coup, je trouvais que je ne pouvais obtenir qu'un paquet de 1402 octets via Google. Si je mettais à jour le paramètre de registre MTU à 1402, lorsque je redémarrais et attendais quelques minutes, ce serait alors 1374, puis 1346, etc. etc. Les autres ordinateurs du réseau n'étaient pas affectés (toujours à 1430) et supprimaient le paramètre MTU. du registre ramènerait les choses à la normale (et toujours cassées).

La chose que je trouve la plus difficile à diagnostiquer, c'est qu'il est très difficile de dire si je joue même avec le paramètre de registre correct. Donc, c'est plus simple, ma question serait: comment puis-je savoir quel paramètre MTU Windows essaie d'utiliser?

De plus, si quelqu'un a des idées pour savoir pourquoi le MTU continue de chuter de 28, cela serait également utile (par exemple, y a-t-il un fichier journal Windows quelque part où il enregistrera quelque chose au point où la valeur change?)

Enfin, si quelqu'un peut me dire définitivement comment dire quel paramètre MTU je devrais essayer d'utiliser, ce serait génial!

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

Windows 7, Windows Vista

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

Remarque: Dans cet exemple , ma connexion au réseau local IPv6 interface a un faible MTU (1280) parce que je suis sur un tunnel de service pour obtenir une connectivité IPv6 .

Vous pouvez également modifier votre MTU (Windows 7, Windows Vista). À 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 netshsyntaxe 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 de routage et d'accès distant soit démarré avant de pouvoir voir les détails d'une interface (y compris MTU):

C:\Users\Ian>net start remoteaccesss

Windows XP ne permet pas de modifier le paramètre MTU de l'intérieur netsh. Pour cela vous pouvez:

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

Testé avec Windows XP Service Pack 3

Voir également

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

Brève discussion sur ce qu'est MTU, d'où viennent 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, 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 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 nécessaires pour envoyer un paquet ping.

Lorsque vous envoyez un paquet ping, vous pouvez spécifier la quantité de données utiles supplémentaires 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 de plus

>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 n'est pas autorisé à être fragmenté:

>ping -l 1473 -f obsidian

L' indicateur -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 l' indicateur Ne pas fragmenter a été défini.

Si, le long de la ligne, un paquet devait être fragmenté, le réseau envoie en fait un paquet ICMP vous indiquant qu'une fragmentation s'est produite. Votre ordinateur reçoit ce paquet ICMP, est informé de la taille maximale et est censé 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 machine ne se rend jamais compte 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 réponses initiales petites (<1280 octets), mais les paquets plus gros ne peuvent pas passer. Et les pare-feu du serveur Web sont mal configurés, bloquant les paquets ICMP. Ainsi, le serveur Web ne se rend pas compte que vous n'avez jamais reçu le paquet.

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

@ian Je ne suis pas sûr que cela netshmontre réellement le MTU actuellement utilisé. Sur ma machine Windows XP Pro SP3, j'ai exécuté netsh interface ip show interfaceet il a signalé la valeur MTU pour l'interface pertinente comme 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 la définition EnablePMTUDiscoveryde 0 définira MTU sur 576.

La définition de l' MTUentrée de registre définit le MTU manuellement. J'ai essayé plusieurs valeurs pour l' MTUentrée (redémarrage à chaque fois).

Dans les deux cas - en ajoutant la première entrée, puis la deuxième - le netshrapport MTU était toujours de 1500. Les tests avec ping ont confirmé (ou du moins suggéré) que la valeur MTU configurée dans le registre était en fait utilisée.

De plus, lorsque j'ai essayé ceci pour la première fois sur ma machine, le service Routage et accès distant a été désactivé, je n'ai donc pas pu le démarrer à l'aide de vos instructions. Je l'ai activé en allant dans 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é en Manuel. J'ai également démarré le service à partir de cette boîte de dialogue.

Je ne suis pas sûr non plus que KB283165 soit nécessairement les bonnes instructions pour changer le MTU. Ces instructions ne sont-elles pas pertinentes uniquement lors de l'exécution du client Windows PPPoE? Si vous vous connectez à Internet via un routeur où le routeur est le client PPPoE (comme dans mon cas), ces instructions ne seraient pas pertinentes, non?

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

Modifier par @ian

On dirait que tu as raison. Configurer pour 1 200, mais netshrapports 1500.

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Donc, je suppose que la réponse à la question d'origine est que sur Windows XP, vous devez utiliser l'essai et l'erreur avec l' indicateur 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 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 sur le chemin vers la destination. Ce paramètre est utile pour dépanner les problèmes de PMTU (Maximum Transmission Unit).

-l Taille: spécifie la longueur, en octets, du champ 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 «Le paquet doit être fragmenté mais défini par DF» lorsque la longueur est trop grande.

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, etc. De plus, il affiche des statistiques générales TCP / IP / UDP / ICMP pour votre ordinateur local.

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

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

Dans le registre,

• Aller à HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
• Ouvrez l'adaptateur qui vous intéresse
• Copiez la ServiceNamechaîne
• Recherchez cette chaîne dans HKLM\System; vous assortirez une NetCfgInstanceIdclé
• Un peu au dessus ce sera la MaxFrameSizeclé (le mien montre 1514)

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

Vérifiez également la configuration de votre Path MTU Discovery .