Per Windows 7, Windows Vista e Windows XP, l'MTU per varie interfacce è disponibile da Windows stesso usando netsh
.
Windows 7, Windows Vista
Per mostrare l'attuale MTU su Windows 7 o Windows Vista, da un prompt dei comandi:
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
E per le interfacce 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
Nota: In questo esempio la mia interfaccia IPv6 Local Area Connection ha un MTU così basso (1280) perché sto usando un servizio tunnel per ottenere connettività IPv6 .
Puoi anche cambiare il tuo MTU (Windows 7, Windows Vista). Da un prompt di comando elevato:
>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.
Testato con Windows 7 Service Pack 1
Windows XP
La sintassi netsh
per Windows XP è leggermente diversa:
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
Nota: ** Windows XP richiede che il servizio **Routing and Remote Access sia avviato prima di poter vedere i dettagli di un'interfaccia (incluso l'MTU):
C:\Users\Ian>net start remoteaccesss
Windows XP non fornisce un modo per cambiare l'impostazione dell'MTU da netsh
. Per questo è possibile:
Testato con Windows XP Service Pack 3
Vedi anche
Breve discussione su cosa sia l'MTU, da dove vengono i 28 byte.
La tua scheda di rete (Ethernet) ha una dimensione massima dei pacchetti di 1,500 bytes
:
+---------+
| 1500 |
| byte |
| payload |
| |
| |
| |
+---------+
La parte IP di TCP/IP richiede un'intestazione di 20 byte (12 byte di flags, 4 byte per l'indirizzo IP sorgente, 4 byte per l'indirizzo IP destinazione). Questo lascia meno spazio disponibile nel pacchetto:
+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |- IP header: 20 bytes
| 4 byte to address | /
|------------------------|
| 1480 byte payload |
| |
| |
| |
+------------------------+
Ora un pacchetto ICMP (ping) ha un'intestazione di 8 byte (1 byte type
, 1 byte code
, 2 byte checksum
, 4 byte di dati aggiuntivi):
+------------------------+
| 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 |
| |
| |
| |
+------------------------+
Ecco dove sono i 28 byte “mancanti” - è la dimensione dell'intestazione richiesta per inviare un pacchetto ping.
Quando invii un pacchetto ping, puoi specificare quanti dati extra di carico utile vuoi includere. In questo caso, se si includono tutti i 1472 byte:
>ping -l 1472 obsidian
Allora il pacchetto ethernet risultante sarà pieno fino alle branchie. Ogni ultimo byte del pacchetto da 1500 byte sarà riempito:
+------------------------+
| 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....|
|........................|
|........................|
|........................|
|........................|
+------------------------+
Se provate a inviare un altro byte
>ping -l 1473 obsidian
la rete dovrà frammentare quel pacchetto da 1501 byte in più pacchetti:
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 |
| |
| |
| |
| |
| |
+------------------------+
Questa frammentazione avverrà dietro le quinte, idealmente senza che tu lo sappia.
Ma puoi essere cattivo, e dire alla rete che il pacchetto non può essere frammentato:
>ping -l 1473 -f obsidian
Il flag -f significa non frammentare. Ora quando si cerca di inviare un pacchetto che non entra nella rete si ottiene l'errore:
>ping -l 1473 -f obsidian
Packet needs to be fragmented but DF set.
Il pacchetto deve essere frammentato, ma il flag Do not Fragment è stato impostato.
Se in qualsiasi punto della linea un pacchetto deve essere frammentato, la rete invia effettivamente un pacchetto ICMP che ti dice che è avvenuta una frammentazione. La vostra macchina riceve questo pacchetto ICMP, le viene detto quale era la dimensione più grande, e si suppone che smetta di inviare pacchetti troppo grandi. Sfortunatamente la maggior parte dei firewall blocca questi pacchetti ICMP “Path MTU discovery”, così la tua macchina non si rende mai conto che i pacchetti sono stati frammentati (o peggio: abbandonati perché non potevano essere frammentati).
Questo è ciò che fa sì che il web-server non funzioni. È possibile ottenere le risposte iniziali piccole (<1280 byte), ma i pacchetti più grandi non possono passare. E i firewall del web-server sono mal configurati, bloccando i pacchetti ICMP. Così il web-server non si rende conto che non ha mai ricevuto il pacchetto.
La frammentazione dei pacchetti non è consentita in IPv6, tutti sono richiesti per consentire (correttamente) i pacchetti ICMP mtu discovery.