W systemach Windows 7, Windows Vista i Windows XP, MTU dla różnych interfejsów jest dostępne w samym systemie Windows przy użyciu netsh.
Windows 7, Windows Vista
Aby pokazać aktualne MTU w Windows 7 lub Windows Vista, z wiersza poleceń:
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 Local Area Connection IPv6 ma tak niskie MTU (1280), ponieważ używam usługi tunelowej, aby uzyskać połączenie IPv6 .
Możesz również zmienić swoje MTU (Windows 7, Windows Vista). Z poziomu wyniesionego wiersza poleceń:
>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.
Testowane z Windows 7 Service Pack 1
Windows XP
Składnia netsh dla Windows XP jest nieco inna:
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, aby usługa **Routing and Remote Access była uruchomiona, zanim będzie można zobaczyć szczegóły dotyczące interfejsu (w tym MTU):
C:\Users\Ian>net start remoteaccesss
Windows XP nie udostępnia sposobu na zmianę ustawienia MTU z poziomu netsh. W tym celu można:
Testowane z Windows XP Service Pack 3
Zobacz także
Krótkie omówienie czym jest MTU, skąd się bierze 28 bajtów.
Twoja karta sieciowa (Ethernet) ma maksymalny rozmiar pakietów 1,500 bytes:
+---------+
| 1500 |
| byte |
| payload |
| |
| |
| |
+---------+
Część IP w TCP/IP wymaga 20 bajtowego nagłówka (12 bajtów flag, 4 bajty na źródłowy adres IP, 4 bajty na docelowy adres IP). To pozostawia mniej wolnego 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 danych dodatkowych):
+------------------------+
| 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 |
| |
| |
| |
+------------------------+
To właśnie tam jest “brakujące” 28 bajtów - jest to rozmiar nagłówków wymaganych do wysłania pakietu ping.
Kiedy wysyłasz pakiet ping, możesz określić, jak dużo dodatkowych danych payload chcesz dołączyć. W tym przypadku, jeśli dołączymy wszystkie 1472 bajty:
>ping -l 1472 obsidian
Wtedy wynikowy pakiet ethernet będzie wypełniony po brzegi. Każdy ostatni bajt z 1500 bajtowego pakietu będzie 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ć jeden bajt więcej
>ping -l 1473 obsidian
sieć będzie musiała pofragmentować 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 odbędzie się za kulisami, najlepiej bez wiedzy użytkownika.
Ale możesz być złośliwy i powiedzieć sieci, że pakiet nie może być fragmentowany:
>ping -l 1473 -f obsidian
Flaga -f oznacza nie fragmentuj. Teraz, gdy próbujesz wysłać pakiet, który nie mieści się w sieci, otrzymujesz błąd:
>ping -l 1473 -f obsidian
Packet needs to be fragmented but DF set.
Pakiet wymaga fragmentacji, ale ustawiono flagę Do not Fragment.
Jeśli w którymkolwiek miejscu na linii pakiet wymagał fragmentacji, sieć faktycznie wysyła pakiet ICMP informujący, że doszło do fragmentacji. Twoja maszyna otrzymuje ten pakiet ICMP, dowiaduje się jaki był największy rozmiar i powinna przestać wysyłać zbyt duże pakiety. Niestety większość firewalli blokuje te pakiety ICMP “Path MTU discovery”, więc twoja maszyna nigdy nie zdaje sobie sprawy, że pakiety są fragmentowane (lub co gorsza: porzucane, ponieważ nie mogły być fragmentowane).
To właśnie powoduje, że web-serwer nie działa. Możesz uzyskać początkowe małe (<1280 bajtów) odpowiedzi, ale większe pakiety nie mogą się przedostać. A firewall serwera WWW jest źle skonfigurowany, blokując pakiety ICMP. Więc serwer nie wie, że nie otrzymałeś pakietu.
Fragmentacja pakietów nie jest dozwolona w IPv6, każdy jest wymagany do (prawidłowego) zezwalania na pakiety ICMP mtu discovery.