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!
la source
Réponses:
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:
Et pour les interfaces IPv4:
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 :
Testé avec Windows 7 Service Pack 1
Windows XP
La
netsh
syntaxe pour Windows XP est légèrement différente: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):
Windows XP ne permet pas de modifier le paramètre MTU de l'intérieur
netsh
. Pour cela vous pouvez:Testé avec Windows XP Service Pack 3
Voir également
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
: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:
Maintenant, un paquet ICMP (ping) a un en-tête de 8 octets (1 octet
type
, 1 octetcode
, 2 octetschecksum
, 4 octets de données supplémentaires):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:
Ensuite, le paquet Ethernet résultant sera plein jusqu'aux branchies. Chaque dernier octet du paquet de 1500 octets sera rempli:
Si vous essayez d'envoyer un octet de plus
le réseau devra fragmenter ce paquet de 1501 octets en plusieurs paquets:
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é:
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:
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.
la source
@ian Je ne suis pas sûr que cela
netsh
montre réellement le MTU actuellement utilisé. Sur ma machine Windows XP Pro SP3, j'ai exécuténetsh interface ip show interface
et il a signalé la valeur MTU pour l'interface pertinente comme1500
. J'ai ensuite ajouté les clés de registre suivantes:Microsoft indique que la définition
EnablePMTUDiscovery
de 0 définira MTU sur 576.La définition de l'
MTU
entrée de registre définit le MTU manuellement. J'ai essayé plusieurs valeurs pour l'MTU
entrée (redémarrage à chaque fois).Dans les deux cas - en ajoutant la première entrée, puis la deuxième - le
netsh
rapport 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
netsh
rapports1500
.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.
la source
Vous pouvez trouver MTU en utilisant ping avec une approche d'essai et d'erreur:
Ping :
Vous obtiendrez des messages «Le paquet doit être fragmenté mais défini par DF» lorsque la longueur est trop grande.
la source
Voir AdapterWatch :
la source
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,
HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
ServiceName
chaîneHKLM\System
; vous assortirez uneNetCfgInstanceId
cléMaxFrameSize
clé (le mien montre 1514)Il existe également un moyen de changer cela avec la
netsh
commande.Vérifiez également la configuration de votre Path MTU Discovery .
la source