Voor Windows 7, Windows Vista en Windows XP is de MTU voor verschillende interfaces beschikbaar vanuit Windows zelf met behulp van netsh.
Windows 7, Windows Vista
Om de huidige MTU op Windows 7 of Windows Vista te tonen, vanaf een opdrachtprompt:
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
En voor IPv4 interfaces:
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
Note: In dit voorbeeld heeft mijn Local Area Connection IPv6 interface zo'n lage MTU (1280) omdat ik een tunneldienst gebruik om IPv6 connectiviteit te krijgen .
Je kunt je MTU ook wijzigen (Windows 7, Windows Vista). Vanaf een verhoogde opdrachtprompt:
>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.
Getest met Windows 7 Service Pack 1
Windows XP
De netsh syntaxis voor Windows XP is iets 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 vereist dat de **Routing and Remote Access service gestart is voordat je details over een interface (inclusief MTU) kunt zien:
C:\Users\Ian>net start remoteaccesss
Windows XP voorziet niet in een manier om de MTU instelling te wijzigen vanuit netsh. Daarvoor kunt u:
Tested with Windows XP Service Pack 3
Zie ook
Korte discussie over wat MTU is, waar de 28 bytes vandaan komen.
Je netwerkkaart (Ethernet) heeft een maximale pakketgrootte van 1,500 bytes:
+---------+
| 1500 |
| byte |
| payload |
| |
| |
| |
+---------+
Het IP gedeelte van TCP/IP heeft een header van 20 bytes nodig (12 bytes voor vlaggen, 4 bytes voor bron IP adres, 4 bytes voor bestemming IP adres). Hierdoor blijft er minder ruimte beschikbaar in het pakket:
+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |- IP header: 20 bytes
| 4 byte to address | /
|------------------------|
| 1480 byte payload |
| |
| |
| |
+------------------------+
Nu heeft een ICMP (ping) pakket een 8 byte header (1 byte type, 1 byte code, 2 byte checksum, 4 byte extra data):
+------------------------+
| 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 |
| |
| |
| |
+------------------------+
Dat is waar de “ontbrekende” 28 bytes zijn - het is de grootte van de headers die nodig zijn om een ping pakket te versturen.
Wanneer je een ping pakket verstuurt, kun je aangeven hoeveel extra payload data je mee wilt sturen. In dit geval, als je alle 1472 bytes meezendt:
>ping -l 1472 obsidian
Dan zal het resulterende ethernet pakket tot de nok toe gevuld zijn. Elke laatste byte van het 1500 byte pakket zal gevuld zijn:
+------------------------+
| 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....|
|........................|
|........................|
|........................|
|........................|
+------------------------+
Als je probeert om nog een byte meer te sturen
>ping -l 1473 obsidian
zal het netwerk dat 1501 byte pakket moeten fragmenteren in meerdere pakketten:
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 |
| |
| |
| |
| |
| |
+------------------------+
Deze fragmentatie gebeurt achter de schermen, idealiter zonder dat jij het weet.
Maar je kunt ook gemeen zijn, en het netwerk vertellen dat het pakket niet gefragmenteerd mag worden:
>ping -l 1473 -f obsidian
De -f vlag betekent niet fragmenteren. Als je nu een pakket probeert te versturen dat niet op het netwerk past, krijg je de foutmelding:
>ping -l 1473 -f obsidian
Packet needs to be fragmented but DF set.
Het pakket moet gefragmenteerd worden, maar de Do not Fragment flag was gezet.
Als ergens langs de lijn een pakket gefragmenteerd moest worden, stuurt het netwerk een ICMP pakket om je te vertellen dat er een fragmentatie is gebeurd. Je machine krijgt dit ICMP pakket, wordt verteld wat de grootste grootte was, en wordt verondersteld te stoppen met het versturen van te grote pakketten. Helaas blokkeren de meeste firewalls deze “Path MTU discovery” ICMP pakketten, zodat je machine nooit doorheeft dat de pakketten gefragmenteerd worden (of erger: gedropt worden omdat ze niet gefragmenteerd konden worden).
Dat is wat er voor zorgt dat de web-server niet werkt. Je kunt de eerste kleine (<1280 byte) antwoorden krijgen, maar grotere pakketten komen er niet doorheen. En de firewalls van de web-server zijn verkeerd geconfigureerd, waardoor ICMP pakketten worden geblokkeerd. Dus de web-server realiseert zich niet dat je het pakket nooit gekregen hebt.
Fragmentatie van pakketten is niet toegestaan in IPv6, iedereen is vereist om (correct) ICMP mtu discovery pakketten toe te staan.