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