Introduzione
MTR (originariamente, TraceRoute di Matt, ora solo My TraceRoute) è uno strumento pratico e leggero nell'arsenale di un amministratore UNIX/Linux che può aiutare a identificare e diagnosticare problemi di rete comuni come latenza, perdita di pacchetti ed errori di routing. È un potente strumento 2 in 1 che combina e visualizza i risultati di un traceroute e un ping con un comando. Esaminiamo le basi dell'utilizzo di MTR e come interpretare i dati che fornisce.
Prerequisiti
- Avrai bisogno di un server Linux e, se non disponi già di un server, puoi visitare la nostra pagina Hosting VPS e avviare un nuovo server in meno di 30 secondi
Installazione di MTR
I pacchetti MTR sono disponibili per la maggior parte dei più diffusi sistemi operativi Linux (o basati su UNIX) di oggi.
Installa MTR su Ubuntu/Debian:
sudo apt-get install mtr-tiny
Il mtr-tiny package è la versione solo da riga di comando di mtr pacchetto. Il mtr il pacchetto include il supporto per l'interfaccia grafica X-11.
Installa MTR su CentOS/Fedora:
yum install mtr
Installa MTR su Arch Linux:
pacman -S mtr
Installa MTR su FreeBSD:
pkg install mtr
.
Come funziona MTR
Per comprendere l'output generato da MTR, potresti trovare utile sapere come funziona. Se conosci già come il traceroute il comando funziona, quindi questa spiegazione suonerà familiare.
MTR genera un pacchetto ICMP Echo Request destinato all'IP/hostname di destinazione del tuo mtr comando. Il primo pacchetto avrà un valore TTL (time-to-live) di 1. Quando quel pacchetto arriva al router che è il suo gateway nel suo percorso verso la sua eventuale destinazione, il router ricevente diminuirà il TTL di 1, portandolo a 0 Quando un TTL raggiunge 0, il router elimina il pacchetto e invia al mittente originale un pacchetto ICMP Time Exceeded. Questo pacchetto di ritorno contiene l'indirizzo IP del mittente e MTR visualizza questo IP (o nome host, se può risolverlo) come primo hop. Quindi invia un pacchetto ICMP Echo Request separato con un TTL di 2 e quando riceve il pacchetto ICMP Time Exceeded dalla scadenza del TTL, elenca questo dispositivo come secondo hop e così via finché la destinazione non restituisce un pacchetto ICMP Echo Reply .
.
Lettura dei rapporti MTR
Oltre a elencare ogni hop di rete tra l'originator e la destinazione, MTR tiene anche traccia delle statistiche relative al tempo di andata e ritorno per i pacchetti dall'host di origine a ogni hop lungo il percorso. Questo tempo di andata e ritorno è spesso chiamato latenza .
Per avere un'idea migliore di ciò che ci dice MTR, diamo un'occhiata a un esempio che traccia il percorso verso il DNS pubblico di Google.
sudo mtr -r 8.8.8.8
[sample results below]
HOST: endor Loss% Snt Last Avg Best Wrst StDev
1. 69.28.84.2 0.0% 10 0.4 0.4 0.3 0.6 0.1
2. 38.104.37.141 0.0% 10 1.2 1.4 1.0 3.2 0.7
3. te0-3-1-1.rcr21.dfw02.atlas. 0.0% 10 0.8 0.9 0.8 1.0 0.1
4. be2285.ccr21.dfw01.atlas.cog 0.0% 10 1.1 1.1 0.9 1.4 0.1
5. be2432.ccr21.mci01.atlas.cog 0.0% 10 10.8 11.1 10.8 11.5 0.2
6. be2156.ccr41.ord01.atlas.cog 0.0% 10 22.9 23.1 22.9 23.3 0.1
7. be2765.ccr41.ord03.atlas.cog 0.0% 10 22.8 22.9 22.8 23.1 0.1
8. 38.88.204.78 0.0% 10 22.9 23.0 22.8 23.9 0.4
9. 209.85.143.186 0.0% 10 22.7 23.7 22.7 31.7 2.8
10. 72.14.238.89 0.0% 10 23.0 23.9 22.9 32.0 2.9
11. 216.239.47.103 0.0% 10 50.4 61.9 50.4 92.0 11.9
12. 216.239.46.191 0.0% 10 32.7 32.7 32.7 32.8 0.1
13. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. google-public-dns-a.google.c 0.0% 10 32.7 32.7 32.7 32.8 0.0
I rapporti MTR, per impostazione predefinita, mostrano le seguenti colonne:
– % di perdita =La percentuale di pacchetti per i quali non è stata ricevuta una risposta ICMP.
– Snt =Il numero di pacchetti inviati a ciascun hop.
– Ultimo =Il tempo di andata e ritorno dell'ultima sonda traceroute, in millisecondi.
– Media =Il tempo medio di andata e ritorno di tutte le sonde traceroute, in millisecondi.
– Migliore =Il tempo di andata e ritorno più breve di tutte le sonde traceroute, in millisecondi.
– Prima =Il tempo di andata e ritorno più lungo di tutte le sonde traceroute, in millisecondi.
– StDev =La sonda di deviazione standard risulta per ogni hop.
.
Ricevere un rapporto in tempo reale da MTR
Se esegui MTR solo con un IP di destinazione (o un nome host), riceverai un rapporto in tempo reale che continuerà fino al termine della sessione o all'esecuzione del comando break (Ctrl+C ).
sudo mtr 8.8.8.8
Alcuni sistemi operativi richiedono sudo prima di eseguire mtr comando; altri no.
.
Se desideri mettere in pausa MTR, premi p . MTR conserverà tutti i conteggi raccolti durante la pausa, consentendoti di fare uno screenshot o di copiare i dati negli appunti. Riattiva MTR con la barra spaziatrice.
.
Generazione di un rapporto MTR a conteggio fisso
Puoi anche generare un rapporto MTR dopo un numero specifico di sonde di traccia con il -r opzione (il modulo lungo è --report ). Il numero predefinito di conteggi è 10, ma se desideri eseguire MTR per un numero di conteggi diverso, utilizza il -c (--report-cycles ) anche l'opzione. Ad esempio, se desideri generare un rapporto con più di 200 conteggi:
sudo mtr -rc 200 8.8.8.8 [long form] sudo mtr --report --report-cycles 200 8.8.8.8
Qualsiasi MTR eseguito con -r l'opzione non produrrà alcun output (a differenza del rapporto in tempo reale sopra) finché non completa il numero completo di conteggi. MTR invia una serie di sonde di traccia una volta al secondo per impostazione predefinita, quindi un rapporto dovrebbe essere completato in poco più di un numero di secondi pari al numero del tuo conteggio (200 secondi nell'esempio sopra).
.
Altre opzioni utili
Ci sono molte altre opzioni che potresti trovare utili durante l'utilizzo di MTR. Quelli che non richiedono argomenti (come -r ) possono essere concatenati nella stessa stringa di opzioni (ad esempio, -rn ). Un'opzione che richiede un argomento può essere inclusa in una di queste catene solo se è l'ultima opzione ed è seguita dal suo argomento (ad esempio, -rnc 200 ).
-n:(forma lunga--no-dns) Disabilita le ricerche dei nomi host DNS. Ilnchiave può essere utilizzata anche durante un rapporto in tempo reale per alternare tra la disabilitazione e l'abilitazione delle ricerche DNS.-u:Invia datagrammi UDP invece di pacchetti di richiesta eco ICMP. Iluchiave può anche alternare tra UDP e ICMP durante un rapporto in tempo reale.-w:(forma lunga--report-wide) Sostituisce-rma produce un rapporto che non tronca i nomi host più lunghi.-i*:(forma lunga--interval) Specificare l'intervallo, in secondi, tra le sonde di prova. L'intervallo predefinito è 1 secondo.-4:Limita il test a IPv4.-6:Limita il test a IPv6.
.
Analisi dei dati MTR per la latenza
L'output dei dati MTR può aiutarti a identificare i problemi che tu o uno dei vettori Internet potreste riscontrare con il routing. Può anche aiutare a impostare una linea di base per la latenza prevista tra gli endpoint.
Ribadiamo qui che i tempi generati da MTR sono i tempi di andata e ritorno per un pacchetto ICMP per raggiungere l'hop in cui scade il suo TTL, per il dispositivo che elabora tale scadenza per generare un pacchetto ICMP Time Exceeded e per quel pacchetto per tornare a il dispositivo di origine. Per molti router, l'esecuzione della risposta ICMP per i pacchetti persi è una priorità bassa e su alcuni dispositivi è completamente disabilitata.
Per uno di questi motivi, probabilmente vedrai casi in cui un hop intermedio mostra il picco occasionale nella colonna del tempo "Ultimo" o "Peggiore". Finché il salto di latenza non si propaga anche a ogni hop successivo, ciò che si vede è il ritardo dal meccanismo di risposta su quell'unico dispositivo, al contrario della vera latenza del throughput. Prendi, ad esempio, il seguente output MTR:
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. vl223-ar-01.nyc-ny.atlantic.net 0.0% 66 0.5 6.1 0.5 140.2 25.5 2. te0-0-1-1.rcr11.ewr04.atlas.cogentco.com 0.0% 66 1.0 1.0 0.8 2.8 0.2 3. te0-3-0-4.rcr21.ewr02.atlas.cogentco.com 0.0% 66 1.1 1.1 0.9 2.5 0.2 4. be2601.rcr24.jfk01.atlas.cogentco.com 0.0% 66 1.6 1.7 1.5 2.0 0.0 5. be2632.ccr42.jfk02.atlas.cogentco.com 0.0% 66 1.7 1.8 1.6 3.0 0.1 6. be2807.ccr42.dca01.atlas.cogentco.com 0.0% 66 8.3 8.1 7.7 12.1 0.6 7. be2113.ccr42.atl01.atlas.cogentco.com 9.1% 66 27.5 21.7 18.6 34.7 3.9 8. be2123.ccr22.mia01.atlas.cogentco.com 0.0% 66 33.0 33.4 33.0 41.5 1.1 9. be2055.ccr21.mia03.atlas.cogentco.com 0.0% 66 33.3 33.6 33.1 36.3 0.4 10. 38.104.95.170 0.0% 65 40.8 40.9 40.7 42.0 0.1 11. 209.208.7.42 0.0% 65 41.6 43.3 40.9 187.9 18.2 12. [target host] 0.0% 65 41.1 41.1 40.9 41.3 0.0
Vedi come il primo e l'undicesimo salto hanno ciascuno un tempo peggiore molto più alto della loro media? Molti considerano un indicatore come questo e presumono che rappresenti la prova della latenza del throughput. Ma noti come il secondo e il dodicesimo salto non mostrino anche un momento altrettanto peggiore? Se la colonna del tempo peggiore per ogni hop successivo mostrava un tempo uguale o maggiore, allora potremmo prendere quel risultato di un incidente che indica potenziali problemi di latenza. Nota, al contrario, la colonna del tempo medio, in particolare tra i hop 6 e 7. La media salta da 8,3 millisecondi a 21,7 millisecondi e ogni hop successivo ha un numero più alto. Questa colonna mostra un esempio di vera latenza, in questo caso tra router a Washington, DC e Atlanta, GA (questo risultato è abbastanza normale per gli standard del 2015).
Potresti anche vedere salti intermedi sporadicamente o addirittura far cadere del tutto i pacchetti. Ancora una volta, fintanto che questi drop sono isolati su un dispositivo e non coerenti in tutti gli hop successivi, è molto probabile che i messaggi di risposta ICMP Time Exceeded vengano depriorizzati per il traffico di transito più importante (puoi vedere un esempio di questo drop nel luppolo 7 sopra). In alcuni casi, gli amministratori di rete configurano i router in modo che non rispondano affatto con le risposte ICMP Time Exceeded. Potresti vedere che questi salti vengono visualizzati come un calo del 100% del traffico mentre quelli successivi sono ancora reattivi (nel primo esempio in questo articolo, puoi vedere un esempio di questo comportamento nell'hop 13 che mostra una perdita del 100% e non mostra l'IP dei suoi host o nome host).
.
E poi?
Questo articolo è solo un'introduzione a come utilizzare lo strumento MTR per esaminare la connettività di rete a vari endpoint su Internet. Sebbene ci sia molto altro da imparare, le informazioni presentate qui dovrebbero darti un buon inizio per poter diagnosticare i problemi di rete che potresti riscontrare. Grazie per la lettura e ricontrolla con noi per ulteriori aggiornamenti, tutorial e articoli sull'hosting VPS più avanzati come Che cos'è:Nozioni di base sulla rete:switch, router e firewall.
Scopri di più sui nostri servizi di hosting VPS e sui server privati virtuali.
.
.