2009-09-08 11:24:00 +0000 2009-09-08 11:24:00 +0000
21
21

Comment savoir quel MTU est utilisé dans Windows XP

Je souffre d'un problème vraiment bizarre qui consiste à obtenir de manière aléatoire des erreurs “La connexion au serveur a été réinitialisée” lorsque j'essaie d'accéder à des pages web (erreur HTTP 12031 selon l'outil de diagnostic réseau de Windows) - cela se produit indépendamment du fait que la page web à laquelle j'essaie d'accéder se trouve sur l'internet externe ou même si elle provient d'une instance locale d'Apache tournant sur localhost. Elle affecte tous les ordinateurs de notre réseau local (Ethernet, pas sans fil), qui fonctionnent tous sous Windows XP.

Il m'a été suggéré que cela pourrait être lié à la MTU utilisée sur le trafic réseau. Si je fais le test Ping pour trouver le plus gros paquet qui peut passer sans être fragmenté, je peux envoyer un ping au localhost avec un paquet de 1492 octets (+28 octets pour un en-tête ?) et je peux envoyer un ping à notre routeur avec un paquet de 1462 octets (ce qui fait 1490 octets quand on inclut l'en-tête de 28 octets). Si j'essaie d'envoyer un ping à l'extérieur, comme Google, je ne peux rien faire passer au-delà de 1430 (soit 1458 avec l'en-tête).

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

Au début, quand j'essayais 1430 comme valeur, après quelques minutes de bon fonctionnement, les résultats du test Ping diminuaient de 28 octets - tout à coup, je découvrais que je ne pouvais faire passer qu'un paquet de 1402 octets à Google. Si je mettais à jour le réglage du registre MTU à 1402, lorsque je redémarrais et que j'attendais quelques minutes, il serait alors de 1374, puis de 1346, etc. etc. Les autres ordinateurs du réseau n'ont pas été affectés (toujours à 1430) et la suppression du paramètre MTU du registre ramènerait les choses à la normale (et toujours en panne).

La chose que je trouve la plus difficile dans le diagnostic de tout cela est qu'il est très difficile de dire si je joue même avec le bon réglage de la base 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 une idée sur la façon de savoir pourquoi le MTU continue de baisser de 28, cela serait utile aussi (par exemple, y a-t-il un fichier journal de Windows quelque part où il enregistrera quelque chose au moment où la valeur change ?)

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

Réponses (5)

58
58
58
2011-08-02 02:59:21 +0000

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 :

Testé avec Windows XP Service Pack 3

Voir aussi

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.
Source
8
8
8
2011-11-07 19:52:04 +0000

@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.
Source
2
2
2
2009-09-08 11:47:58 +0000

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

ping <address> -f -l nnnn

-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.
Source
1
1
1
2009-09-08 11:28:05 +0000

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 .
Source
1
1
1
2009-09-08 11:41:12 +0000

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.
Source