Jak stwierdzić, jaka jednostka MTU jest używana w systemie Windows XP

Mam naprawdę dziwny problem polegający na tym, że podczas próby dostępu do stron internetowych losowo dostaję błędy „Połączenie z serwerem zostało zresetowane” (błąd HTTP 12031 według narzędzia diagnostycznego sieci systemu Windows) - dzieje się tak niezależnie od tego, czy strona internetowa Próbuję uzyskać dostęp do zewnętrznego Internetu lub nawet jeśli pochodzi z lokalnej instancji Apache działającej na localhost. Wpływa na wszystkie komputery w naszej sieci lokalnej (Ethernet, a nie bezprzewodowo), wszystkie z systemem Windows XP.

Zasugerowano mi, że może to być związane z MTU używanym w ruchu sieciowym. Jeśli wykonam test ping, aby znaleźć największy pakiet, który może przechodzić przez niefragmentowane, mogę pingować hosta lokalnego za pomocą pakietu 1492 bajtów (+28 bajtów dla nagłówka?) I mogę pingować nasz router za pomocą pakietu 1462 bajtów (czyli 1490 bajtów po dodaniu 28-bajtowego nagłówka). Jeśli spróbuję pingować coś na zewnątrz, takiego jak Google, nie mogę uzyskać niczego większego niż 1430 (czyli 1458 z nagłówkiem).

Próbowałem postępować zgodnie z różnymi zestawami instrukcji, aby zaktualizować rejestr systemu Windows XP za pomocą tego ustawienia MTU, aktualizując HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU. Nie próbowałem końca alternatywnych wartości: najbardziej oczywistą poprawną wartością wydaje się być 1490, ale próbowałem również 1462, 1458, 1430 itd. Itp. Kiedy uruchamiam ponownie komputer, aby zmiana zaczęła obowiązywać, to wydaje się działać przez kilka minut (trudno powiedzieć na pewno, ponieważ zawsze jest raczej losowy niż spójny), ale nigdy nie trwa długo.

Początkowo, gdy próbowałem 1430 jako wartości, po kilku minutach poprawnego działania wyniki testu ping zmniejszyłyby się o 28 bajtów - nagle okazało się, że mogę przesłać do Google tylko pakiet 1402 bajtów. Gdybym zaktualizował ustawienie rejestru MTU do 1402, po ponownym uruchomieniu i odczekaniu kilku minut będzie to 1374, następnie 1346 itd. Itd. Inne komputery w sieci pozostały niezmienione (nadal w 1430) i usunięcie ustawienia MTU z rejestru przywróciłoby rzeczy do normy (i nadal jest uszkodzone).

Najtrudniejsze w diagnozowaniu tego wszystkiego jest to, że bardzo trudno jest stwierdzić, czy w ogóle bawię się odpowiednim ustawieniem rejestru. Najprościej więc moje pytanie brzmi: w jaki sposób mogę ustalić, jakie ustawienie MTU próbuje użyć Windows?

Również, jeśli ktoś ma jakieś pomysły, jak powiedzieć, dlaczego MTU spada o 28, byłoby to również przydatne (np. Czy istnieje plik dziennika systemu Windows, w którym zapisuje coś w miejscu, w którym zmienia się wartość?)

Wreszcie, jeśli ktoś może mi ostatecznie powiedzieć, jak powiedzieć, jakiego ustawienia MTU powinienem użyć, byłoby świetnie!

W systemie Windows 7, Windows Vista i Windows XP MTU dla różnych interfejsów jest dostępne w systemie Windows przy użyciu netsh.

Windows 7, Windows Vista

Aby wyświetlić bieżącą jednostkę MTU w systemie Windows 7 lub Windows Vista, z wiersza polecenia:

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

A dla interfejsów 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

Uwaga: W tym przykładzie mój interfejs połączenia lokalnego IPv6 ma tak niską MTU (1280), ponieważ używam usługi tunelowej, aby uzyskać łączność IPv6 .

Możesz także zmienić MTU (Windows 7, Windows Vista). Z wiersza polecenia z podwyższonym poziomem uprawnień:

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

Testowane z dodatkiem Service Pack 1 dla systemu Windows 7

Windows XP

netshSkładnia dla systemu Windows XP jest nieco inny:

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

Uwaga: Windows XP wymaga uruchomienia usługi Routing i dostęp zdalny, zanim będzie można wyświetlić szczegółowe informacje o interfejsie (w tym MTU):

C:\Users\Ian>net start remoteaccesss

Windows XP nie zapewnia sposobu zmiany ustawienia MTU od wewnątrz netsh. W tym celu możesz:

• postępuj zgodnie z instrukcjami w KB283165 - Jak zmienić rozmiar MTU PPPoE w Windows XP
• użyj Dr. TCP ( Uwaga: tylko Windows 2000 / XP)

Testowane z Windows XP Service Pack 3

Zobacz też

• Skonfiguruj rozmiar maksymalnej jednostki transferu TCPIP (MTU) w systemie Vista
• Ustawianie MTU w systemie Windows Vista
• Zmień ustawienia MTU Pomoc!
• KB283165 - Jak zmienić rozmiar MTU PPPoE w systemie Windows XP
• DSLReports - DrTCP

Krótka dyskusja na temat tego, czym jest MTU, skąd pochodzi 28 bajtów.

Twoja karta sieciowa (Ethernet) ma maksymalny rozmiar pakietu 1,500 bytes:

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

Część IP protokołu TCP / IP wymaga 20-bajtowego nagłówka (12 bajtów flag, 4 bajty dla źródłowego adresu IP, 4 bajty dla docelowego adresu IP). To pozostawia mniej miejsca w pakiecie:

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

Teraz pakiet ICMP (ping) ma 8-bajtowy nagłówek (1 bajt type, 1 bajt code, 2 bajty checksum, 4 bajty dodatkowe dane):

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

Właśnie tam znajduje się „brakujący” 28 bajtów - to rozmiar nagłówków wymaganych do wysłania pakietu ping.

Wysyłając pakiet ping, możesz określić, ile dodatkowych danych ładunku chcesz uwzględnić. W takim przypadku, jeśli podasz wszystkie 1472 bajty:

>ping -l 1472 obsidian

Następnie powstały pakiet ethernetowy będzie pełny do skrzeli. Każdy ostatni bajt pakietu 1500 bajtów zostanie wypełniony:

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

Jeśli spróbujesz wysłać jeszcze jeden bajt

>ping -l 1473 obsidian

sieć będzie musiała podzielić ten 1501 bajtowy pakiet na wiele pakietów:

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

Ta fragmentacja nastąpi za kulisami, najlepiej bez Twojej wiedzy.

Ale możesz być wredny i powiedzieć sieci, że pakiet nie może zostać podzielony:

>ping -l 1473 -f obsidian

W -f środki flag nie fragmentacji . Teraz, gdy próbujesz wysłać pakiet, który nie pasuje do sieci, pojawia się błąd:

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

Pakiet musi zostać pofragmentowany, ale ustawiono flagę Nie fragmentuj .

Jeśli w dowolnym miejscu linii konieczne jest fragmentowanie pakietu, sieć faktycznie wysyła pakiet ICMP z informacją, że nastąpiła fragmentacja. Twoja maszyna otrzyma ten pakiet ICMP, zostanie poinformowany, jaki był największy rozmiar i ma przestać wysyłać zbyt duże pakiety. Niestety większość zapór blokuje te pakiety ICMP „Path MTU Discovery”, więc twoja maszyna nigdy nie zdaje sobie sprawy z tego, że pakiety są pofragmentowane (lub gorzej: są odrzucane, ponieważ nie można ich pofragmentować).

To powoduje, że serwer WWW nie działa. Możesz uzyskać początkowe małe odpowiedzi (<1280 bajtów), ale większe pakiety nie mogą się przedostać. A zapory ogniowe serwera WWW są źle skonfigurowane, blokując pakiety ICMP. Tak więc serwer sieciowy nie zdaje sobie sprawy, że nigdy nie dostałeś pakietu.

Fragmentacja pakietów nie jest dozwolona w IPv6, każdy musi (poprawnie) zezwolić na pakiety wykrywania ICMP mtu.

@ian Nie jestem pewien, czy netshfaktycznie pokazuje aktualnie używany MTU. Na moim komputerze z systemem Windows XP Pro SP3 wykonałem netsh interface ip show interfacei zgłosił wartość MTU dla odpowiedniego interfejsu jako 1500. Następnie dodałem następujące klucze rejestru:

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 twierdzi, że ustawienie EnablePMTUDiscoveryna 0 spowoduje ustawienie MTU na 576.

Ustawienie MTUwpisu rejestru ustawia MTU ręcznie. Próbowałem kilka wartości dla MTUwpisu (za każdym razem restart).

W obu przypadkach - dodanie pierwszego wpisu, a następnie drugiego wpisu - netshnadal zgłaszało MTU jako 1500. Testowanie za pomocą polecenia ping potwierdziło (lub przynajmniej zasugerowało), że faktycznie użyto wartości MTU skonfigurowanej w rejestrze.

Ponadto, kiedy po raz pierwszy wypróbowałem to na moim komputerze, usługa Routing i dostęp zdalny została wyłączona, więc nie byłem w stanie uruchomić jej przy użyciu twoich instrukcji. Włączyłem go, przechodząc do Panelu sterowania> Narzędzia administracyjne> Zarządzanie komputerem> Usługi i aplikacje> Usługi. Zmieniłem „Typ uruchamiania” z Wyłączony na Ręczny. Następnie uruchomiłem usługę również z tego okna dialogowego.

Nie jestem również pewien, czy KB283165 jest koniecznie poprawną instrukcją zmiany MTU. Czy te instrukcje nie są istotne tylko podczas uruchamiania klienta Windows PPPoE? Jeśli łączysz się z Internetem przez router, na którym router jest klientem PPPoE (jak w moim przypadku), te instrukcje nie byłyby istotne, prawda?

Instrukcje, które zastosowałem, które doprowadziły mnie do wprowadzenia powyższych zmian w rejestrze, były w KB900926: Zalecane ustawienia TCP / IP dla łączy WAN o rozmiarze MTU mniejszym niż 576 (metody 2 i 3).

Edytuj przez @ian

Wygląda na to, że masz rację. Skonfiguruj dla 1200, ale netshraportów 1500.

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Myślę, że odpowiedź na pierwotne pytanie brzmi: w systemie Windows XP musisz użyć metody prób i błędów z flagą Nie fragmentuj, aby znaleźć największy pakiet, jaki możesz wysłać. Masz swój MTU.

Możesz znaleźć MTU za pomocą polecenia ping z podejściem prób i błędów:

ping <address> -f -l nnnn

Ping :

-f: określa, że ​​komunikaty żądania echa są wysyłane z flagą Nie fragmentuj w nagłówku IP ustawioną na 1. Komunikat żądania echa nie może zostać podzielony przez routery na ścieżce do miejsca docelowego. Ten parametr jest przydatny przy rozwiązywaniu problemów związanych ze ścieżką rozwiązywania problemów z maksymalną jednostką transmisji (PMTU).

-l Rozmiar: Określa długość pola danych w wysłanych komunikatach żądania echa (w bajtach). Domyślna wartość to 32. Maksymalny rozmiar to 65 527.

Otrzymasz komunikat „Pakiet musi zostać podzielony na fragmenty, ale zestaw DF”, gdy długość jest zbyt duża.

Zobacz AdapterWatch :

AdapterWatch wyświetla przydatne informacje o twoich kartach sieciowych: adresy IP, adres sprzętowy, serwery WINS, serwery DNS, wartość MTU, liczbę odebranych lub wysłanych bajtów, aktualną prędkość transferu i więcej. Ponadto wyświetla ogólne statystyki TCP / IP / UDP / ICMP dla komputera lokalnego.

Microsoft KB314496: Domyślne rozmiary MTU dla różnych topologii sieci .
Nie powinieneś próbować grać z konfiguracją MTU w normalnych konfiguracjach sieciowych.

Jest tutaj odniesienie do kodu VB .
Istnieje również narzędzie o nazwie DrTCP :

W rejestrze

• Iść do HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
• Otwórz adapter, który Cię interesuje
• Skopiuj ServiceNameciąg
• Wyszukaj ten ciąg w HKLM\System; dopasujesz NetCfgInstanceIdklucz
• Nieco wyżej będzie MaxFrameSizeklucz (moja pokazuje 1514)

Istnieje również sposób, aby to zmienić za pomocą netshpolecenia.

Sprawdź także konfigurację Path MTU Discovery .