My Traceroute, o MTR, combina i comandi traceroute e ping per misurare lo stato di integrità di un percorso di rete.
Dopo aver letto questo articolo sarai in grado di:
Argomenti correlati
Abbonati a theNET, il riepilogo mensile di Cloudflare sulle tematiche più discusse in Internet.
Copia link dell'articolo
Traceroute è uno strumento utilizzato per diagnosticare i problemi in un percorso di rete. Traceroute viene utilizzato per comprendere il percorso che i pacchetti IP stanno prendendo da un computer (indirizzo IP di origine) a un altro (indirizzo IP di destinazione). Il comando traceroute (su Linux o macOS) o tracert (su Windows) consente di conoscere:
*Il tempo di andata e ritorno (RTT) è la quantità di tempo necessaria ai dati per arrivare e tornare da un determinato punto su una rete.
Ecco un esempio di traceroute verso 1.1.1.1. Le righe con asterischi (* * *) rappresentano gli hop da cui i pacchetti non sono stati restituiti; questo può accadere quando i router sono configurati per ignorare i pacchetti traceroute. I tempi in millisecondi su ogni riga sono i tempi di andata e ritorno dall'origine a quell'hop per ciascun pacchetto (traceroute invia tre pacchetti alla volta per verificare i risultati).
| Esempio di traceroute |
|---|
| traceroute verso 1.1.1.1 (1.1.1.1), max 64 hop, pacchetti da 52 byte |
| 1 myrouter (192.168.47.1) 2,755 ms 1,452 ms 1,325 ms |
| 2 * * * |
| 3 69.168.32.65 (69.168.32.65) 18.159 ms 18.658 ms 15.091 ms |
| 4 * * * |
| 5 206.126.237.30 (206.126.237.30) 30,453 ms 50,242 ms 24,342 ms |
| 6 one.one.one.one (1.1.1.1) 29,000 ms 26,784 ms 26,017 ms |
Un percorso di rete si riferisce alla sequenza di reti attraverso cui passa un pacchetto per raggiungere la sua destinazione.
Internet è un'enorme raccolta di reti che si connettono tra loro tramite routing. La maggior parte degli endpoint Internet, ad esempio un browser Web che prova ad accedere a un sito Web e il server che ospita quel sito Web, non fa parte della stessa rete. Ciò significa che se il browser Web invia una richiesta ai server del sito Web, la richiesta dovrà probabilmente passare tra diverse reti intermedie lungo il percorso.
Uno strumento traceroute invia i pacchetti a un IP di destinazione e con un time-to-live (TTL) impostato su 1, in modo che il primo router raggiunto dai pacchetti invii un errore ("Tempo superato"). Quando viene restituito l'errore, lo strumento traceroute registra l'identità del primo router e il tempo di andata e ritorno, incrementa il TTL e invia nuovi pacchetti, ripetendo questo processo fino a quando 1) l'ultimo pacchetto raggiunge l' IP di destinazione o 2) due set di pacchetti vengono eliminati.
In questo modo, lo strumento consente di comprendere il percorso seguito dai pacchetti e il tempo di andata e ritorno per ogni hop, in modo da poter risolvere i problemi di latenza e perdita di pacchetti.
Traceroute si basa sul protocollo ICMP (Internet Control Message Protocol). ICMP è un protocollo a livello di rete utilizzato per i test di errore. Non ha alcun protocollo di trasporto associato ed è in esecuzione direttamente sul protocollo Internet (IP). Quando viene superato il TTL di un pacchetto inviato dallo strumento traceroute, il router invia un pacchetto ICMP di tipo 11 (errore Tempo superato).
I pacchetti in uscita (inviati dal router iniziale) possono utilizzare ICMP (impostazione predefinita sui sistemi operativi MacOS e Linux) o UDP (impostazione predefinita su Windows). Scegliere un protocollo diverso per i pacchetti traceroute in uscita è un modo per ottenere risultati più completi se i router lungo il percorso di rete sono configurati per filtrare i pacchetti di un determinato protocollo.
My Traceroute (MTR) è uno strumento che combina traceroute e ping, un altro metodo comune per testare la connettività e la velocità della rete. Oltre agli hop lungo il percorso di rete, l'MTR mostra informazioni in costante aggiornamento sulla latenza e la perdita dei pacchetti lungo il percorso verso la destinazione. Questo aiuta a risolvere i problemi di rete consentendoti di vedere cosa sta succedendo lungo il percorso in tempo reale.
MTR funziona scoprendo il percorso di rete in modo simile a traceroute e quindi inviando regolarmente pacchetti per continuare a raccogliere informazioni per fornire una visione aggiornata sullo stato e la velocità della rete.
Come traceroute, MTR può utilizzare ICMP o UDP per i pacchetti in uscita, ma si affida a ICMP per i pacchetti di ritorno (tipo 11: Tempo superato).
Di seguito sono riportati tre esempi di come leggere e trarre conclusioni dall'output di MTR.
| Pulire l'MTR | |||||||
|---|---|---|---|---|---|---|---|
| Start: 2020-04-08T13:28:52+0100 | |||||||
| HOST: myrouter | Loss% | Snt | Ultimo | Avg | Migliore | Wrst | StDev |
| 1.|-- 10.10.1.1 | 0% | 10 | 0.3 | 0.4 | 0.3 | 0.4 | 0.0 |
| 2.|-- 141.0.147.177.bcube.co.uk | 0% | 10 | 2.7 | 2.7 | 2.5 | 3.1 | 0.2 |
| 3.|-- 172.16.28.38 | 0% | 10 | 2.8 | 6.4 | 2.8 | 22.2 | 6.1 |
| 4.|-- 172.17.13.76 | 0% | 10 | 1.1 | 2.8 | 1.1 | 14.6 | 4.2 |
| 5.|-- 172.17.13.49 | 0% | 10 | 1.4 | 4.0 | 1.3 | 25.0 | 7.4 |
| 6.|-- 172.17.13.24 | 0% | 10 | 2.5 | 2.7 | 2.0 | 5.1 | 1.1 |
| 7.|-- one.one.one.one | 0% | 10 | 1.3 | 1.2 | 1.2 | 1.3 | 0.0 |
Questo esempio segue il percorso di rete tra il router iniziale e 1.1.1.1 di Cloudflare Server DNS. L'output di MTR non indica alcun problema: sono necessari 7 hop per raggiungere 1.1.1.1 e nessuno di essi indica alcuna perdita di pacchetti.
| Perdita di pacchetti lungo il percorso | |||||||
|---|---|---|---|---|---|---|---|
| Start: 2020-04-08T12:48:28+0000 | |||||||
| HOST: myrouter | Loss% | Snt | Ultimo | Avg | Migliore | Wrst | StDev |
| 1.|-- 2400:cb00:207:1000::1 | 0% | 10 | 1.1 | 6.0 | 0.6 | 15.7 | 5.9 |
| 2.|-- 2404:d400:4000:27::1 | 0% | 10 | 0.4 | 0.6 | 0.2 | 2.9 | 0.8 |
| 3.|-- 2404:d400:0:8:: | 0% | 10 | 125.7 | 125.7 | 125.7 | 126.2 | 0.2 |
| 4.|-- 2001:978:2:42::e:1 | 50,0% | 10 | 129.2 | 129.6 | 129.2 | 130.5 | 0.6 |
| 5.|-- be2846.ccr42.fra03.atlas.cogentco.com | 80% | 10 | 151.9 | 139.5 | 127.1 | 151.9 | 17.6 |
| 6.|-- be2814.ccr42.ams03.atlas.cogentco.com | 80% | 10 | 136.2 | 137.0 | 136.2 | 137.8 | 1.1 |
| 7.|-- be2183.ccr22.lpl01.atlas.cogentco.com | 50,0% | 10 | 146.3 | 146.2 | 145.9 | 146.3 | 0.1 |
| 8.|-- be3043.ccr22.ymq01.atlas.cogentco.com | 30% | 10 | 215.3 | 215.2 | 215.0 | 215.4 | 0.2 |
| 9.|-- be3260.ccr32.yyz02.atlas.cogentco.com | 90,0% | 10 | 227.8 | 227.8 | 227.8 | 227.8 | 0.0 |
| 10.|-- be2994.ccr22.cle04.atlas.cogentco.com | 30% | 10 | 234.9 | 234.9 | 234.5 | 235.1 | 0.2 |
| 11.|-- be2718.ccr42.ord01.atlas.cogentco.com | 70,0% | 10 | 233.7 | 233.8 | 233.7 | 233.9 | 0.1 |
| 12.|-- be2832.ccr22.mci01.atlas.cogentco.com | 50,0% | 10 | 244.8 | 245.1 | 244.8 | 245.5 | 0.3 |
| 13.|-- be3036.ccr22.den01.atlas.cogentco.com | 30% | 10 | 259.6 | 259.6 | 259.3 | 259.8 | 0.2 |
| 14.|-- be3038.ccr32.slc01.atlas.cogentco.com | 90,0% | 10 | 267.2 | 267.2 | 267.2 | 267.2 | 0.0 |
| 15.|-- be3110.ccr22.sfo01.atlas.cogentco.com | 10,0% | 10 | 291.0 | 291.1 | 291.0 | 291.4 | 0.1 |
| 16.|-- be3670.ccr41.sjc03.atlas.cogentco.com | 30% | 10 | 292.6 | 292.7 | 292.6 | 292.8 | 0.1 |
| 17.|-- 2001:550:2:1f::29:2 | 0% | 10 | 312.3 | 291.5 | 287.0 | 312.3 | 8.6 |
| 8.6 | 0% | 10 | 298.7 | 299.5 | 298.7 | 306.1 | 2.3 |
| 19.|-- ??? | 100.0 | 10 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| 20.|-- ??? | 100.0 | 9 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| 21.|-- 2400:cb00:36:1008::a29e:40e2 | 0% | 9 | 302.9 | 302.9 | 302.8 | 303.2 | 0.1 |
Questo esempio mostra il percorso di rete tra il router iniziale e 2400:cb00:36:1008::a29e:40e2, che è un indirizzo IPv6. L'output mostra una significativa perdita di pacchetti su tutti gli hop Cogent. Tuttavia, non si verifica alcuna perdita pacchetto nell'ultimo hop (21). Ciò indica che il percorso di rete in realtà non è problematico. Quello che sta succedendo è qualcosa che viene spesso definito "Control Plane Policing".
Come detto in precedenza, l'MTR funziona inviando (come impostazione predefinita) pacchetti ICMP Echo, con un TTL (Time-To-Live) incrementale per pacchetto. Quando il TTL scade, un router invierà un ICMP di tipo 11 (Tempo superato), indicando quanti hop ci sono dal punto A al punto B.
Molti operatori di rete (incluso Cloudflare) stabiliscono limiti arbitrari sulla quantità di pacchetti ICMP che possono raggiungere il piano di controllo di un router. Il piano di controllo è il cervello del router. Un pacchetto che supera il TTL di un router deve essere elaborato dal piano di controllo. Per evitare che il piano di controllo venga sopraffatto da troppi di questi pacchetti, viene impostato un limite di velocità (o policer), motivo per cui vediamo tutta questa perdita sugli hop intermedi, ma non sull'hop finale: i limiti di velocità del piano di controllo per i router sugli hop intermedi sono stati superati, quindi i pacchetti di tipo 11 non sono stati rispediti per i pacchetti traceroute oltre tali limiti, ma sono riusciti ad arrivare a destinazione in modo sicuro.
| Perdita di pacchetti sul percorso di ritorno | |||||||
|---|---|---|---|---|---|---|---|
| Start: 2020-04-08T13:32:30+0000 | |||||||
| HOST: myrouter | Loss% | Snt | Ultimo | Avg | Migliore | Wrst | StDev |
| 1.|-- 162.158.216.129 | 0% | 10 | 0.7 | 6.9 | 0.7 | 62.6 | 19.6 |
| 2.|-- 118.69.221.209 | 0% | 10 | 0.2 | 0.3 | 0.2 | 1.3 | 0.3 |
| 3.|-- 118.69.252.172 | 0% | 10 | 0.7 | 1.0 | 0.6 | 2.9 | 0.7 |
| 4.|-- 118.69.132.169 | 0% | 10 | 11.4 | 11.3 | 11.2 | 11.5 | 0.1 |
| 5.|-- 118.69.247.64 | 0% | 10 | 34.2 | 34.4 | 33.9 | 37.2 | 1.0 |
| 6.|-- 13335.sgw.equinix.com | 50,0% | 10 | 27.5 | 27.9 | 27.1 | 29.1 | 0.8 |
| 7.|-- 162.158.161.251 | 30% | 10 | 26.8 | 26.8 | 26.8 | 26.8 | 0.0 |
Questo esempio mostra il percorso di rete tra il router iniziale e 162.158.161.251. L'output mostra la perdita pacchetto negli ultimi 2 hop.
L'MTR offre numerose opzioni. Puoi trovare ulteriori informazioni nella pagina della guida di MTR: mtr --help
Alcune delle opzioni utilizzate di frequente sono: