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:
Testowane z Windows XP Service Pack 3
Zobacz też
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.
