MTR uno strumento diagnostico di rete

MTR uno strumento diagnostico di rete
Matt's Traceroute (MTR) è uno strumento diagnostico di rete potente e multipiattaforma che combina le funzionalità di ping e traceroute. MTR è un'evoluzione di Traceroute che mostra informazioni approfondite determinando la via del pacchetto verso l'host di destinazione. Il rapporto sul percorso contiene la percentuale di risposta e il tempo di risposta di tutti i luppoli tra l'origine alla macchina di destinazione.

L'articolo descrive in dettaglio il funzionamento di MTR, fornisce alcuni esempi di riga di comando e spiega i dati che genera. Alla fine, dato l'output, eseguiamo l'analisi dei report.

Come funziona MTR?

Strumenti diagnostici di rete, come ping, traceroute e sonda MTR la connessione tra due dispositivi con pacchetti ICMP per la risoluzione dei problemi di connettività della rete. Mentre l'utilità Ping utilizza ICMP ECHO_REQUEST e ECHO_REPLES, al contrario, Traceroute e MTR usano i pacchetti ICMP con TTL time-to-live.

Per l'analisi hop-to-hop, all'inizio, MTR stabilisce indirizzi di switch, gateway e router tra i dispositivi locali e remoti. Quindi, utilizza i pacchetti ICMP con TTL per eseguire il ping di ogni hop in modo tale che il TTL controlli i nodi che il pacchetto raggiungerà prima di morire. Quindi, invia una serie di ICMP echo_request con il TTL impostato su uno, due, tre e così via fino a quando MTR non assembla l'intera rotta.

Il processo di cui sopra emette statistiche che contengono ulteriori informazioni, come lo stato di hop, la connessione di rete, la reattività del nodo, la latenza di rete e il jitter. Più interessante, è simile al comando superiore in quanto continua a rinfrescare con la connettività di rete in tempo reale.

Installazione MTR

Per impostazione predefinita, lo strumento vive in /utente/sbin directory come viene preinstallato con la maggior parte delle distribuzioni. Se non è disponibile, installa MTR Con il gestore dei pacchetti predefiniti della distribuzione.

Per ubuntu:

ubuntu@ubuntu: ~ $ sudo apt -get -y installa mtr

Per Rhel:

ubuntu@ubuntu: ~ $ sudo yum -y installa mtr

Per l'arco:

ubuntu@ubuntu: ~ $ sudo pacman -y installa mtr

Generare e leggere i rapporti MTR live

Come mostrato negli screenshot sopra, oltre a elencare il luppolo di rete, MTR tiene anche traccia della latenza. In altre parole, stima anche il tempo di andata e ritorno dalla macchina locale a ciascun dispositivo sul percorso.

Per un'idea migliore, utilizzare il flag -report per generare un rapporto che costituisce statistiche sulla qualità della rete. Gli utenti possono anche utilizzarlo con l'opzione -c, poiché eseguirà solo il numero di cicli specificati da esso e usciranno dopo aver stampato le statistiche.

ubuntu@ubuntu: ~ $ sudo mtr -r -c 5 google.com

La schermata precedente emette diversi campi/colonne per accedere al traffico di rete. Queste colonne riportano le seguenti statistiche:

  • %Perdita: percentuale di perdita di pacchetti in ogni macchina
  • SNT: Numero di pacchetti inviati
  • Scorso: Il tempo di andata e ritorno per l'ultimo pacchetto Traceroute
  • AVG: Il tempo medio di andata e ritorno per tutte le sonde
  • Migliore: Tempo di andata e ritorno più breve di un pacchetto a un host particolare
  • WRST: Tempo di andata e ritorno più lungo di un pacchetto a un host
  • Stdev: Deviazione standard delle latenze

IL SNT A WRST Le colonne misurano le latenze in millisecondi, ma solo il Avg La colonna conta di più. L'unico aspetto negativo per la generazione di report per la qualità della rete è che utilizza molto traffico di rete che degrada le prestazioni della rete.

Opzioni utili

La sezione seguente contiene alcuni dei più utili esempi di comandi di flag MTR. Spiegheremo i dettagli di output nella sezione Report MTR in seguito.

IPv6: MTR utilizza IPv6 come opzione predefinita, che richiede l'inclusione dell'indirizzo IP o del nome di dominio dell'host di destinazione come argomento. Viene visualizzato un'uscita in tempo reale Premere CTRL+C o Q per uscire:

ubuntu@ubuntu: ~ $ sudo mtr Google.com

O

ubuntu@ubuntu: ~ $ sudo mtr 8.8.8.8

Solo IPv4: Lo switch IPv4 (-4) visualizza solo gli indirizzi IPv4 e include nomi di dominio completamente qualificato:

ubuntu@ubuntu: ~ $ sudo mtr -4 google.com

B: Per visualizzare sia i nomi di dominio che gli indirizzi IPv4, utilizzare il flag -b come segue:

ubuntu@ubuntu: ~ $ sudo mtr -b google.com

C: Come discusso in precedenza, il flag limita il numero di ping inviati a ciascuna macchina. Dopo aver completato il numero di pings, interrompe l'aggiornamento in tempo reale ed esce da MTR subito dopo:

ubuntu@ubuntu: ~ $ sudo mtr -c7 Google.com

T/u: Sostituire i pacchetti Echo ICMP con TCP SYN -T/-tcp o datagrammi UDP -u/-udp:

ubuntu@ubuntu: ~ $ sudo mtr - -tcp Google.com

O

ubuntu@ubuntu: ~ $ sudo mtr --udp google.com

o: Disporre il campo di output secondo il tuo requisito. Ad esempio, il comando dato visualizza l'output nella seguente moda:

ubuntu@ubuntu: ~ $ mtr -o "lsdr nbaw jmxi" 8.8.8.8

M: Specificare il luppolo tra l'host locale e la macchina remota. I seguenti esempi impostano il luppolo su 5, mentre il valore predefinito è 30:

ubuntu@ubuntu: ~ $ mtr -m 5 8.8.8.8

S: Sonda la rete specificando la dimensione del pacchetto ICMP, comprese le intestazioni IP/ICMP in byte:

ubuntu@ubuntu: ~ $ mtr -s pacchetsize -c 5 google.com

Analisi del rapporto

L'analisi del rapporto di output MTR costituisce principalmente o si concentra sulla perdita di pacchetti e sulla latenza della rete. Discutiamo ciascuno di questi in dettaglio:

Perdita di pacchetti

Il rapporto MTR genera una percentuale del campo di perdita di pacchetti ad ogni hop per indicare un problema. Tuttavia, i fornitori di servizi hanno una pratica comune di pacchetti MTR ICMP limitati che danno un'illusione di perdita di pacchetti, il che non è vero. Per identificare se la perdita di pacchetti è effettivamente dovuta a una velocità di limitazione o meno, notare la perdita di pacchetti del hop successivo. Come nello screenshot sopra, per -o Esempio di bandiera, osserviamo una perdita di pacchetti 16.7% al hop 5 e 6. Se non vi è alcuna perdita di pacchetti al dispositivo successivo, risulta a causa della limitazione della velocità.

In un altro scenario, se i rapporti rappresentano diversi importi di perdita ai luppoli iniziali iniziali e i pochi dispositivi successivi mostrano la stessa percentuale di perdita di pacchetti, la perdita nelle macchine iniziali è dovuta a entrambi i fattori: limitazione della tariffa e perdita effettiva. Quindi, quando MTR riporta una perdita di pacchetti diverse a vari luppoli, fidati della perdita al luppolo successivo.

Latenza di rete

La latenza di una rete aumenta con il numero di luppoli tra due endpoint. Tuttavia, la latenza dipende anche dalla qualità della connessione di rete tra le macchine locali e remote. Ad esempio, le connessioni di dial-up mostrano una latenza più elevata rispetto ai modem via cavo.

È anche importante notare che la latenza della rete non implica un percorso inefficiente. Indipendentemente dall'elevata latenza di rete in vari nodi, i pacchetti possono raggiungere la destinazione e tornare alla fonte con perdita zero.

Nell'esempio sopra, osserviamo un salto in latenza dall'8 ° hop in poi, ma nessun pacchetto è stato perso se non all'host di destinazione.

Conclusione

Comprendere le basi di MTR è necessaria per afferrare e capire i problemi di connettività della rete più comuni, come la configurazione impropria di router ISP/router residenziale e rete host di destinazione, timeout e limitazione della velocità ICMP. L'articolo crea un terreno per un utente principiante per comprendere l'uso e il funzionamento di MTR. Mostra anche come generare report MTR ed eseguire analisi per identificare i problemi di perdita di pacchetti correlati per limitare la velocità e analizzare la latenza della rete.