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

So erkennen Sie, welche MTU in Windows XP verwendet wird

Ich leide unter einem wirklich seltsamen Problem, bei dem ich zufällig “Die Verbindung zum Server wurde zurückgesetzt”-Fehler erhalte, wenn ich versuche, auf Webseiten zuzugreifen (HTTP-Fehler 12031 laut dem Windows-Netzwerkdiagnosetool) - dies geschieht unabhängig davon, ob die Webseite, auf die ich zuzugreifen versuche, im externen Internet ist oder sogar, wenn sie von einer lokalen Apache-Instanz auf localhost läuft. Es betrifft alle Computer in unserem lokalen Netzwerk (Ethernet, nicht drahtlos), die alle unter Windows XP laufen.

Es wurde mir vorgeschlagen, dass es mit der MTU des Netzwerkverkehrs zu tun haben könnte. Wenn ich den Ping-Test durchführe, um das größte Paket herauszufinden, das unfragmentiert durchgehen kann, kann ich den localhost mit einem Paket von 1492 Bytes (+28 Bytes für einen Header?) anpingen und ich kann unseren Router mit einem Paket von 1462 Bytes anpingen (das sind 1490 Bytes, wenn man den 28-Byte-Header einbezieht). Wenn ich versuche, etwas von außen anzupingen, wie z. B. Google, kann ich nichts durchkommen, was größer ist als 1430 (was mit dem Header 1458 ist).

Ich habe versucht, verschiedene Anweisungen zu befolgen, um die Windows XP-Registrierung mit dieser MTU-Einstellung zu aktualisieren. Ich habe unendlich viele alternative Werte ausprobiert: der offensichtlichste korrekte Wert scheint 1490 zu sein, aber ich habe auch 1462, 1458, 1430 usw. usw. ausprobiert. Wenn ich den Computer neu starte, um die Änderung wirksam werden zu lassen, scheint es für ein paar Minuten zu funktionieren (schwer zu sagen, da es immer zufällig und nicht konsistent ist), aber es hält nie lange an.

Als ich anfangs 1430 als Wert ausprobierte, verringerten sich die Ergebnisse des Ping-Tests nach ein paar Minuten, in denen alles gut funktionierte, um 28 Bytes - plötzlich konnte ich nur noch ein Paket von 1402 Bytes zu Google durchstellen. Wenn ich die MTU-Registrierungseinstellung auf 1402 aktualisierte, wenn ich neu startete und ein paar Minuten wartete, war sie dann 1374, dann 1346, usw. usw. Andere Computer im Netzwerk blieben unbeeinflusst (immer noch auf 1430), und wenn ich die MTU-Einstellung aus der Registry entfernte, war alles wieder normal (und immer noch kaputt).

Das Schwierigste an der Diagnose ist, dass es sehr schwer ist, festzustellen, ob ich überhaupt mit der richtigen Registry-Einstellung spiele. Am einfachsten wäre also meine Frage: Wie kann ich feststellen, welche MTU-Einstellung Windows zu verwenden versucht?

Wenn jemand eine Idee hat, wie man feststellen kann, warum die MTU immer wieder um 28 abfällt, wäre das auch nützlich (z.B. gibt es irgendwo eine Windows-Protokolldatei, in der etwas an dem Punkt protokolliert wird, an dem sich der Wert ändert?)

Schließlich, wenn mir jemand definitiv sagen kann, wie ich feststellen kann, welche MTU-Einstellung ich verwenden sollte, wäre das großartig!

Antworten (5)

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

Für Windows 7, Windows Vista und Windows XP ist die MTU für verschiedene Schnittstellen von Windows selbst mit netsh verfügbar.

Windows 7, Windows Vista

Um die aktuelle MTU unter Windows 7 oder Windows Vista anzuzeigen, über eine Eingabeaufforderung:

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

Und für IPv4-Schnittstellen:

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

Hinweis: In diesem Beispiel hat meine Local Area Connection IPv6-Schnittstelle eine so niedrige MTU (1280), weil ich einen Tunneldienst verwende, um IPv6-Konnektivität zu erhalten .

Sie können Ihre MTU auch ändern (Windows 7, Windows Vista). Von einer erhöhten Eingabeaufforderung aus:

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

Tested with Windows 7 Service Pack 1

Windows XP

Die netsh Syntax für Windows XP ist etwas anders:

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 erfordert, dass der Dienst *Routing und Remote Access gestartet ist, bevor Sie Details über eine Schnittstelle (einschließlich MTU) sehen können:

C:\Users\Ian>net start remoteaccesss

Windows XP bietet keine Möglichkeit, die MTU-Einstellung von netsh aus zu ändern. Dafür können Sie:

Tested with Windows XP Service Pack 3

Siehe auch


Kurze Diskussion darüber, was MTU ist, woher die 28 Bytes kommen.

Ihre Netzwerkkarte (Ethernet) hat eine maximale Paketgröße von 1,500 bytes:

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

Der IP-Teil von TCP/IP benötigt einen 20-Byte-Header (12 Byte Flags, 4 Byte für die Quell-IP-Adresse, 4 Byte für die Ziel-IP-Adresse). Dadurch steht weniger Platz im Paket zur Verfügung:

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

Nun hat ein ICMP-(Ping-)Paket einen 8-Byte-Header (1 Byte type, 1 Byte code, 2 Byte checksum, 4 Byte zusätzliche Daten):

+------------------------+
| 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 |
| |
| |
| |
+------------------------+

Das ist es, wo die “fehlenden” 28 Bytes sind - es ist die Größe des Headers, die benötigt wird, um ein Ping-Paket zu senden.

Wenn Sie ein Ping-Paket senden, können Sie angeben, wie viele zusätzliche Nutzdaten Sie einschließen möchten. In diesem Fall, wenn Sie alle 1472 Bytes einschließen:

>ping -l 1472 obsidian

Dann wird das resultierende Ethernet-Paket voll bis zu den Kiemen sein. Jedes letzte Byte des 1500 Byte großen Pakets wird gefüllt sein:

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

Wenn Sie versuchen, ein weiteres Byte

>ping -l 1473 obsidian

zu senden, muss das Netzwerk dieses 1501-Byte-Paket in mehrere Pakete fragmentieren:

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 |
| |
| |
| |
| |
| |
+------------------------+

Diese Fragmentierung geschieht im Hintergrund, im Idealfall ohne Ihr Wissen.

Aber Sie können gemein sein und dem Netzwerk sagen, dass das Paket nicht fragmentiert werden darf:

>ping -l 1473 -f obsidian

Das -f Flag bedeutet nicht fragmentieren. Wenn Sie nun versuchen, ein Paket zu senden, das nicht in das Netzwerk passt, erhalten Sie die Fehlermeldung:

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

Das Paket muss fragmentiert werden, aber das Do not Fragment Flag wurde gesetzt.

Wenn irgendwo auf der Leitung ein Paket fragmentiert werden musste, sendet das Netzwerk tatsächlich ein ICMP-Paket, das Ihnen mitteilt, dass eine Fragmentierung stattgefunden hat. Ihr Rechner erhält dieses ICMP-Paket, erfährt, was die größte Größe war, und soll aufhören, zu große Pakete zu senden. Leider blockieren die meisten Firewalls diese “Path MTU discovery”-ICMP-Pakete, so dass Ihr Rechner nie merkt, dass die Pakete fragmentiert werden (oder schlimmer: verworfen werden, weil sie nicht fragmentiert werden konnten).

Das ist die Ursache dafür, dass der Webserver nicht funktioniert. Sie können die anfänglichen kleinen (<1280 Byte) Antworten bekommen, aber größere Pakete kommen nicht durch. Und die Firewalls des Web-Servers sind falsch konfiguriert und blockieren ICMP-Pakete. Also merkt der Web-Server nicht, dass das Paket nie angekommen ist.

Fragmentierung von Paketen ist in IPv6 nicht erlaubt, jeder ist verpflichtet, ICMP mtu discovery Pakete (korrekt) zu erlauben.

8
8
8
2011-11-07 19:52:04 +0000

@ian Ich bin mir nicht so sicher, dass netsh tatsächlich die aktuell verwendete MTU anzeigt. Auf meinem Windows XP Pro SP3-Rechner habe ich netsh interface ip show interface ausgeführt und es hat den MTU-Wert für die entsprechende Schnittstelle als 1500 gemeldet. Ich habe dann die folgenden Registrierungsschlüssel hinzugefügt:

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 sagt dass das Setzen von EnablePMTUDiscovery auf 0 die MTU auf 576 setzt.

Das Setzen des Registrierungseintrags MTU stellt die MTU manuell ein. Ich habe mehrere Werte für den Eintrag MTU ausprobiert (und jedes Mal neu gebootet).

In beiden Fällen - dem ersten und dem zweiten Eintrag - meldete netsh immer noch die MTU von 1500. Tests mit Ping bestätigten (oder legten zumindest nahe), dass der in der Registry konfigurierte MTU-Wert tatsächlich verwendet wurde.

Als ich dies zum ersten Mal auf meinem Rechner ausprobierte, war der Routing- und Fernzugriffsdienst deaktiviert, so dass ich ihn nicht mit Ihren Anweisungen starten konnte. Ich aktivierte ihn, indem ich zu Systemsteuerung > Verwaltung > Computerverwaltung > Dienste und Anwendungen > Dienste ging. Ich änderte “Starttyp” von Deaktiviert auf Manuell. Dann habe ich den Dienst auch über diesen Dialog gestartet.

Ich bin mir auch nicht sicher, ob KB283165 unbedingt die richtige Anleitung zum Ändern der MTU ist. Sind diese Anweisungen nicht nur relevant, wenn der Windows-PPPoE-Client läuft? Wenn die Verbindung zum Internet über einen Router erfolgt, bei dem der Router der PPPoE-Client ist (wie in meinem Fall), wären diese Anweisungen nicht relevant, richtig?

Die Anweisungen, die ich befolgt habe und die mich dazu brachten, die oben genannten Änderungen in der Registrierung vorzunehmen, waren in KB900926: Empfohlene TCP/IP-Einstellungen für WAN-Verbindungen mit einer MTU-Größe von weniger als 576 (Methoden 2 & 3).


Bearbeiten von @ian

Sieht aus, als hätten Sie recht. Konfigurieren Sie für 1.200, aber netsh meldet 1500.

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Die Antwort auf die ursprüngliche Frage lautet also, dass man unter Windows XP mit dem Flag Nicht fragmentieren durch Ausprobieren herausfinden muss, wie groß das größte Paket ist, das man senden kann. Dann haben Sie Ihre MTU.

2
2
2
2009-09-08 11:47:58 +0000

Sie können die MTU mit ping durch Ausprobieren ermitteln:

ping <address> -f -l nnnn

-f : Gibt an, dass Echo-Request-Nachrichten mit dem auf 1 gesetzten Don’t-Fragment-Flag im IP-Header gesendet werden. Die Echo-Request-Nachricht kann von Routern im Pfad zum Ziel nicht fragmentiert werden. Dieser Parameter ist nützlich für die Fehlersuche bei Problemen mit der Path Maximum Transmission Unit (PMTU).

-l Größe : Legt die Länge des Datenfelds in den gesendeten Echo-Request-Nachrichten in Bytes fest. Der Standardwert ist 32. Die maximale Größe beträgt 65.527.

Sie erhalten “Packet needs to be fragmented but DF set”-Meldungen, wenn die Länge zu groß ist.

1
1
1
2009-09-08 11:28:05 +0000

Microsoft KB314496: Die Standard-MTU-Größen für verschiedene Netzwerktopologien .
Sie sollten nicht versuchen, mit der MTU-Konfiguration in normalen Netzwerk-Setups zu spielen.

Es gibt eine VB-Code-Referenz hier .
Es gibt auch ein Tool namens DrTCP :


In der Registry,

  • Gehen Sie zu HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
  • Öffnen Sie den Adapter, der Sie interessiert
  • Kopieren Sie die ServiceName Zeichenkette
  • Suchen Sie diese Zeichenkette in HKLM\System; Sie werden einen NetCfgInstanceId Schlüssel finden
  • Ein wenig darüber wird der MaxFrameSize Schlüssel sein (meiner zeigt 1514)

Es gibt auch eine Möglichkeit, dies mit dem netsh Befehl zu ändern.

Überprüfen Sie auch Ihre Path MTU Discovery Konfiguration .

1
1
1
2009-09-08 11:41:12 +0000

Siehe AdapterWatch :

AdapterWatch zeigt nützliche Informationen über Ihre Netzwerkadapter an: IP-Adressen, Hardware-Adresse, WINS-Server, DNS-Server, MTU-Wert, Anzahl der empfangenen oder gesendeten Bytes, die aktuelle Übertragungsgeschwindigkeit und mehr. Darüber hinaus zeigt es allgemeine TCP/IP/UDP/ICMP-Statistiken für Ihren lokalen Computer an.