traceroute

Il traceroute è un comando del Sistema Operativo UNIX, presente con qualche variante anche in altri sistemi (tracert sotto DOS o Windows95, trace sulle shell dei gateway). Lo scopo del traceroute è quello di segnalare quali siano le macchine attraversate dai pacchetti per giungere ad una determinata destinazione, nonché di utilizzare tutte le informazioni disponibili per valutare l'affidabilità della connessione. Per far questo, il comando traceroute invia una successione di pacchetti, incrementando di volta in volta il valore del time-to-live (il campo Max_ttl), ed attende le notifiche ICMP del tipo TIME_EXCEEDED, mandate indietro dai gateways lungo il percorso del pacchetto.
I primi pacchetti lanciati avranno un Max_ttl di un solo hop, poi questo valore viene incrementato finché non si raggiunge il numero massimo di hops, oppure finché la stazione destinazione, raggiunta dal pacchetto, non risponde con un DESTINATION_UNREACHABLE di tipo port_unreachable per segnalare che non sa cosa fare del pacchetto ricevuto (riferito ad una porta logica non attivata).
Per ogni valore di Max_ttl il traceroute manda tre pacchetti (ma il loro numero può essere modificato dall'utente), e mostra i seguenti valori:
 

Max_ttl dei pacchetti (espresso in numero di hops) indirizzo del gateway che ha rimandato indietro i pacchetti ICMP TIME_EXCEEDED per ogni pacchetto il tempo intercorso tra la sua spedizione e la sua ricezione (o un asterisco se questo è maggiore di 3 secondi)
 
 

Un esempio di output è il seguente:
 

<utente@pascal ~>traceroute wilma.cs.brown.edu 
traceroute to wilma.cs.brown.edu (128.148.19.15), 30 hops max, 40 byte packets 
 1  gw1.fis.uniroma3.it (193.204.160.1)  3 ms  3 ms  2 ms 
 2  141.108.132.1 (141.108.132.1)  832 ms  967 ms  402 ms 
 3  mp4rm1.roma1.infn.it (141.108.127.6)  267 ms  106 ms  417 ms 
 4  atm-garrten-rm.infn.it (192.135.31.5)  100 ms  939 ms  839 ms 
 5  cnafint-ten34.infn.it (192.135.34.21)  1100 ms *  1056 ms 
 6  mix-serial3-4.Washington.mci.net (204.189.152.161)  618 ms * * 
 7  * core1-fddi-0.Washington.mci.net (204.70.2.1)  1249 ms * 
 8  * * * 
 9  wtn-bbn-nap.Washington.mci.net (206.157.77.218)  766 ms * * 
10  * * chicago1-br1.bbnplanet.net (4.0.1.5)  857 ms 
11  * * * 
12  * boston1-br1.bbnplanet.net (4.0.2.245)  846 ms * 
13  boston1-br2.bbnplanet.net (4.0.2.250)  680 ms * * 
14  * * boston1-mr4.bbnplanet.net (4.0.44.19)  648 ms 
15  providence-cr1.bbnplanet.net (4.0.45.106)  416 ms providence-cr1.bbnplanet.net (4.0.45.102)  1298 ms * 
16  brown.bbnplanet.net (131.192.32.2)  1444 ms  615 ms  802 ms 
17  * * * 
18  * ftp.cs.brown.edu (128.148.19.15)  834 ms  435 ms 
<utente@pascal ~>

Si sta controllando il collegamento tra le macchine pascal.inf.uniroma3.it e wilma.cs.brown.edu (si tratta dello stesso collegamento che nel quadro precedente era stato oggetto di indagine tramite il comando ping).
Il comando traceroute segnala con la prima riga di output che cosa si accinge a fare: cercherà di tracciare il cammino fino a wilma.cs.brown.edu, facendo però un massimo di trenta salti, e mandando pacchetti di 40 bytes.
I numeri da 1 a 17 sono relativi ai gateways intermedi, il cui nome (quando possibile) viene scritto subito a seguire. La riga numero 18 corrisponde invece all'host destinazione (che evidentemente ha più di un nome, ma il cui indirizzo IP 128.148.19.15 coincide con quello richiesto). I tempi in fondo alle righe sono relativi ai tre pacchetti inviati con lo stesso valore di Max_ttl, e sono i millisecondi intercorsi tra la spedizione del pacchetto e la ricezione del relativo messaggio ICMP (dai gateway intermedi o dall'host destinazione). 
Bisogna avere ben chiaro che ogni tempo è generato da un pacchetto diverso. Non è sempre lo stesso pacchetto che attraversa tutti i gateways, e i tempi sulla stessa riga sono relativi a tre pacchetti diversi.
Quando un pacchetto ICMP non torna entro un tempo limite (generalmente 3 secondi, ma è modificabile dall'utente), il comando traceroute sostituisce il tempo mancante con un asterisco. E' ovvio che, quando un pacchetto viene perso, non si ha modo di sapere con precisione quale router avrebbe dovuto inviare il messaggio ICMP TIME_EXCEEDED relativo. Tale informazione infatti viene ricavata dal campo sorgente dei pacchetti IP che vengono ricevuti. Questo è il motivo per cui alcuni asterischi compaiono all'inizio della riga, e non dopo il nome del router: quando si è rilevata la perdita del pacchetto non si disponeva di un riferimento al router. Se tutti e tre i pacchetti relativi ad un dato hop non vengono ricevuti (righe 8, 11, 17) si rimane senza il nome dell'intermediate host relativo.
La riga numero 15 presenta un caso molto particolare: il secondo pacchetto ha un indirizzo del source address (4.0.45.102) diverso dal primo (4.0.45.106). Entrambi comunque corrispondono alla stessa macchina (providence-cr1.bbnplanet.net). Un gateway, infatti, può rispondere a più di un indirizzo IP sulla stessa porta.
Dall'output del comando traceroute, si possono ricavare informazioni diagnostiche molto più dettagliate che dall'output del comando ping: in particolare si può desumere in quale punto esatto della connessione IP tra le macchine pascal.inf.uniroma3.it e wilma.cs.brown.edu si presenti un problema di trasmissione. Infatti si può notare come i tempi aumentino bruscamente tra il 1° ed il 2° hop. E' questo il link al quale va attribuito il ritardo dei pacchetti.  
pagina precedente    prossima pagina