Home

"I'm brave but I'm chicken shit"

MTU discovery: prova pratica

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:

MTU settings

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


Pubblicato

in

da

Commenti

9 risposte a “MTU discovery: prova pratica”

  1. Avatar Berna

    Complimenti! bellissimo post…buona tecnicità accompagnata da ottimi esempi.

  2. Avatar Fabio
    Fabio

    fa un enorme piacere vedere questi post tecnici di livello,
    complimenti!!
    me lo voglio leggere con calma e capire tutto riga per riga, appena ho un quarto d’ora consecutivo libero (domenica).

  3. Avatar marco
    marco

    Ottimo post Andrea, sei superlativo!
    ma io sono tonto! 1492 sul tuo router e’ un MTU che dipende
    dall’HW (e come tale non andrebbe mai toccato)
    oppure si puo’ giocarci?
    Sul PC ho scovato MTU=1300;
    forse buono x un MTUrouter=1492
    ma non potrei forse impostarli entrambi a 1500 ?
    Grazie.

  4. Avatar jj
    jj

    – Ubuntu gutsy ( kernel 2.6.22-14-generic ) e MTU 1500
    – Linux 2.4.17 ( Linux 2.4.17_mvl21-malta-mips_fp_le ) sul router
    – ADSL con PPPoA ( Tiscali e MTU 1500 )

    Il problema dell’MTU sembra essere prerogativa solo delle ADSL con PPPoE e non delle ADSL PPPoA oppure di alcuni router e non di altri :

    root@*******:~# ping www.google.com -c3 -s1500
    PING google.navigation.opendns.com (208.69.34.231) 1500(1528) bytes of data.
    1508 bytes from google.navigation.opendns.com (208.69.34.231): icmp_seq=1 ttl=54 time=145 ms
    1508 bytes from google.navigation.opendns.com (208.69.34.231): icmp_seq=2 ttl=54 time=144 ms
    1508 bytes from google.navigation.opendns.com (208.69.34.231): icmp_seq=3 ttl=54 time=144 ms

    --- google.navigation.opendns.com ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2001ms
    rtt min/avg/max/mdev = 144.165/144.880/145.984/0.791 ms

    (*) google.navigation.opendns.com -> uso i servizi DNS di openDNS che intercettano i collegamenti verso google rediririgendo dalle proprie pagine.

  5. Avatar Gaby

    Qualche tempo fa’ ho giochicchiato con questa piccola utility per il check del”MTU:

    http://www.elifulkerson.com/projects/mturoute.php

  6. Avatar Un aiuto su VPN

    Ho un problema. Uso un modulo rete Ethernet PLC Siemens CP243-1, un modulo Siemens S7-200 CPU 224XP e un modulo Siemens Scalance S612 per creare una VPN con un pc remoto che funziona da centrale di controllo. Il pc remoto inizia la VPN IPSec che mediante il software Siemens fatto con WinCC flexible Runtime mi fa vedere le variabili del modulo S7-200. Ora la mia domanda è: come fare dal pc remoto ad avere più VPN che puntano contemporaneamente su endpoint diversi, ossia su stazioni PLC Siemens diversi (stazioni formate dai moduli citati all’inizio)?

  7. Avatar jj
    jj

    Aggiornamento : sollecitato dal commento di Gaby , ho rifatto il test impostando i DNS di Tiscali in modo che l’host pingato fosse esattamente google.

    Ebbene per pacchetti superiori a 1500 byte , google non viene pingato come nel test fatto da Andrea. Ma ciò che più ha suscitato la mia curiosità è che per qualunque valore compreso tra 84 e 1500 bytes il pacchetto risulta sempre troncato (appare la dicitura “truncated”)

    Pacchetti invece di lunghezza minore o uguale a 84 bytes complessivi , vengono inoltrati normalmente.

    root@************:~$ ping http://www.google.com -c3 -s56
    PING http://www.l.google.com (209.85.135.99) 56(84) bytes of data.
    64 bytes from mu-in-f99.google.com (209.85.135.99): icmp_seq=1 ttl=242 time=104 ms
    64 bytes from mu-in-f99.google.com (209.85.135.99): icmp_seq=2 ttl=242 time=104 ms
    64 bytes from mu-in-f99.google.com (209.85.135.99): icmp_seq=3 ttl=242 time=105 ms

    http://www.l.google.com ping statistics —
    3 packets transmitted, 3 received, 0% packet loss, time 2000ms
    rtt min/avg/max/mdev = 104.642/105.073/105.858/0.669 ms

    Ora , effettuando una breve ricerca con la chiave MTU=84 , la maggior parte delle risposte indica pagine contenute in Linux Advanced Routing & Traffic Control http://lartc.org/ e pochi riferimenti ad apparecchiature Cisco : è la prova che Tiscali effettua traffic shaping sulla propria rete oppure che Tiscali “processi” le richieste inoltrate verso Google ?

  8. Avatar daniele
    daniele

    ho problema di connessione wireless nel senso che salta spesso la connessione mentre navigo il modem\router è il d-link g624t qlcn può aiutarmi a darmi qlche consigio? grazie ciao a tutti

  9. Avatar Paolo
    Paolo

    ciao,

    stavo leggendo e sperimentando le nozioni del tuo post. Sto utilizzando una macchina virtuale con UBUNTU e la scheda di rete e’ settata con un MTU=1500. Come mai riesco a pingare anche con MTU molto superiori???