Dopo la teoria, facciamo una prova pratica sull’MTU, visto che l’unico strumento che serve è il comando ping.
Per comodità mia utilizzo il terminale di un server Ubuntu, ma si può utilizzare tranquillamente il prompt dei comandi di Windows, sebbene con sintassi diversa.
Anzitutto controlliamo il valore dell’MTU della scheda di rete(*):
root@ginger:~$ ifconfig eth0 | grep MTU
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Ok, è 1500 per default. (Per Windows possiamo utilizzare l’utility gratuita DrTCP.)
Controlliamo che un host esterno risponda al ping:
root@ginger:~# ping www.google.com -c3
PING www.l.google.com (216.239.59.147) 56(84) bytes of data.
64 bytes from gv-in-f147.google.com (216.239.59.147): icmp_seq=1 ttl=243 time=48.5 ms
64 bytes from gv-in-f147.google.com (216.239.59.147): icmp_seq=2 ttl=243 time=47.1 ms
64 bytes from gv-in-f147.google.com (216.239.59.147): icmp_seq=3 ttl=243 time=50.2 ms
--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004msrtt min/avg/max/mdev = 47.140/48.647/50.295/1.304 ms
Il ping funziona tramite ICMP, che vi ricordo essere un “…protocollo di servizio che si preoccupa di trasmettere informazioni riguardanti malfunzionamenti, informazioni di controllo o messaggi tra i vari componenti di una rete di calcolatori.”
Come si può vedere, per impostazione predefinita il comando ping manda un pacchetto di 56 byte, a cui vanno aggiunti 20 byte di intestazione IP e 8 byte relativi al messaggio ICMP_REQUEST; infatti il manuale del comando ping (man ping) riporta: “ICMP PACKET DETAILS – An IP header without options is 20 bytes. An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth of ICMP header followed by an arbitrary amount of data. When a packetsize is given, this indicated the size of this extra piece of data (the default is 56). Thus the amount of data received inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes more than the requested data space (the ICMP header).”
Quindi ping ci informa che sta mandando fuori un pacchetto di 56+28=84 byte.
Adesso proviamo a pingare con pacchetti appena sopra l’MTU della scheda, cioè 1501 byte. Facciamo due calcoli: 1501 meno 28 (tra intestazione IP e messaggio ICMP) = 1473 byte:
root@ginger:~# ping www.google.com -c3 -s1473
PING www.l.google.com (216.239.59.99) 1473(1501) bytes of data.
--- www.l.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2006ms
Adesso si comincia a vedere qualcosa di interessante: il pacchetto è troppo grosso e quindi evidentemente non esce dalla scheda di rete, che avendo MTU a 1500 non riesce a “sparare” pacchetti da 1501 byte.
Proviamo all’esatto valore di MTU, quindi 1500-28=1472:
root@ginger:~# ping www.google.com -c3 -s1472
PING www.l.google.com (216.239.59.99) 1472(1500) bytes of data.
From 192.168.254.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)
--- www.l.google.com ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2006ms
Sempre meglio: adesso il pacchetto è uscito, ma l’host 192.168.254.1, che è il mio router, mi comunica che la sua interfaccia è impostata con un MTU di 1492 byte e non può frammentare i pacchetti (DF set), quindi il pacchetto viene droppato ed il ping non funziona. Proviamo a impostare il flag DF sull’interfaccia locale e vediamo che succede:
root@ginger:~# ping www.google.com -c3 -s1472 -M do
PING www.l.google.com (216.239.59.147) 1472(1500) bytes of data.
From ginger (192.168.254.2) icmp_seq=1 Frag needed and DF set (mtu = 1492)
From ginger (192.168.254.2) icmp_seq=1 Frag needed and DF set (mtu = 1492)
From ginger (192.168.254.2) icmp_seq=1 Frag needed and DF set (mtu = 1492)
--- www.l.google.com ping statistics ---
0 packets transmitted, 0 received, +3 errors
Come ci si aspettava, adesso è l’host locale (ginger – 192.168.254.2) che risponde lamentandosi che per far uscire il pacchetto avrebbe bisogno di frammentarlo, ma il flag DF è settato quindi non se ne fa nulla. Ma adesso sappiamo che l’MTU è settato a 1492 byte, quindi 1492-28=1464
root@ginger:~# ping www.google.com -c3 -s1464
PING www.l.google.com (216.239.59.104) 1464(1492) bytes of data.
64 bytes from 216.239.59.104: icmp_seq=1 ttl=243 (truncated)
64 bytes from 216.239.59.104: icmp_seq=2 ttl=243 (truncated)
64 bytes from 216.239.59.104: icmp_seq=3 ttl=243 (truncated)
--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
Fatto, il pacchetto passa, e passa anche con il flag DF settato localmente:
root@ginger:~# ping www.google.com -c3 -s1464 -M do
PING www.l.google.com (216.239.59.104) 1464(1492) bytes of data.
64 bytes from 216.239.59.104: icmp_seq=1 ttl=243 (truncated)
64 bytes from 216.239.59.104: icmp_seq=2 ttl=243 (truncated)
64 bytes from 216.239.59.104: icmp_seq=3 ttl=243 (truncated)
--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 68.888/69.473/70.187/0.618 ms
Come controprova, aumentiamo di 1 byte:
root@ginger:~# ping www.google.com -c3 -s1465
PING www.l.google.com (216.239.59.99) 1465(1493) bytes of data.
From 192.168.254.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)
--- www.l.google.com ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2006ms
Come volevasi dimostrare. Abbiamo scoperto che l’MTU path della connessione è 1492. Ed infatti sul mio router:
Con Windows è meno immediato, poichè non restituisce tutti i messaggi ICMP, quindi il valore dell’MTU path va trovato per tentativi.
In realtà questi esercizi non sono che una diagnostica grossolana, specie in ambienti complessi con molti salti e architetture complicate, ma uniti ad un po’ di pazienza, uno sniffer e un po’ di fortuna permettono di risolvere problemi apparentemente complicatissimi. Inoltre non sottovalutate il fatto che potete fare parecchio “cinema” con queste manovre. 
(*)vale anche per l’interfaccia verso un modem ADSL
Tags:
DF,
don't fragment,
MTU,
MTU discovery,
network,
ping,
reti,
TCP/IP
Feed