mtr vs traceroute

Traceroute e mtr sono entrambi strumenti a riga di comando per diagnosticare i problemi del percorso di rete. Traceroute fornisce un'istantanea del percorso dei pacchetti. mtr fa la stessa cosa ma continua a sondare, accumulando statistiche sulla perdita di pacchetti, sulla latenza e sul jitter nel tempo. Questo post spiega come funziona ogni strumento, come leggere l'output e quando usarlo.

Come funziona traceroute

Traceroute utilizza il campo Time-to-Live (TTL) nelle intestazioni dei pacchetti IP. Invia un pacchetto con TTL impostato a 1. Il primo router decrementa il TTL a zero, lascia cadere il pacchetto e invia un messaggio ICMP "Time Exceeded". Traceroute registra l'IP del router e il tempo di andata e ritorno, quindi invia un altro pacchetto con TTL impostato a 2 e così via finché il pacchetto non raggiunge la destinazione o il limite massimo di hop (30 per impostazione predefinita, regolabile con -m).

Per impostazione predefinita, traceroute invia tre sonde per hop, fornendo tre letture della latenza. I protocolli differiscono a seconda del sistema operativo:

• Windows: Il comando tracert invia richieste di eco ICMP.
• Linux/macOS: il comando traceroute invia datagrammi UDP (porte 33434-33534). Usare -I per ICMP o -T per TCP se UDP è bloccato.

Aggiungendo il flag -n si saltano le ricerche DNS inverse, il che accelera notevolmente i percorsi con molti hop.

Come funziona mtr

mtr (My Traceroute) utilizza lo stesso rilevamento del percorso basato su TTL di traceroute, ma continua a inviare sonde, in genere una al secondo. Invece di tre punti di dati per hop, si ottengono statistiche correnti: percentuale di perdita di pacchetti, latenza media, tempi di risposta migliori e peggiori e deviazione standard (jitter).

mtr supporta le sonde ICMP (predefinite), UDP e TCP SYN. La modalità TCP è utile quando i firewall bloccano ICMP o quando si desidera testare una porta di applicazione specifica:

mtr --tcp --port 443 example.com

Per un report non interattivo da condividere con un team di supporto, utilizzare la modalità report:

mtr --report --report-cycles 100 example.com

Esegue 100 sonde e stampa un riepilogo. È anche possibile impostare dimensioni personalizzate dei pacchetti con --psize per verificare la presenza di problemi di MTU o di frammentazione.

mtr funziona in modo nativo su Linux e macOS. Gli utenti di Windows possono usare WinMTR per un'interfaccia grafica equivalente.

Differenze chiave

La differenza pratica si riduce ai problemi intermittenti. Un singolo traceroute può facilmente non notare un router che lascia cadere il 2% dei pacchetti o un hop con 15 ms di jitter. mtr li individua perché continua a misurare.

Leggere l'output

L'errore più comune quando si legge l'output di traceroute o mtr è supporre che un hop intermedio dall'aspetto problematico significhi che c'è un problema reale. Di solito non è così.

Gli asterischi (*) in traceroute significano che il router non ha risposto al probe. Molti router sono configurati per ignorare o limitare la velocità di ICMP. Se gli hop successivi rispondono normalmente, il percorso è corretto.

La perdita di pacchetti in un singolo hop in mtr segue la stessa logica. Se l'hop 5 mostra una perdita del 20% ma la destinazione finale mostra lo 0%, quel router sta solo deprioritizzando le risposte della sonda. La vera perdita di pacchetti si manifesta come uno schema: la perdita appare in un hop e persiste in ogni hop successivo fino alla destinazione.

Isalti di latenza tra gli hop sono normali e previsti. Un salto da 10 a 80 ms di solito significa che il pacchetto ha attraversato un oceano o un lungo percorso terrestre. Ci si preoccupa della latenza solo se è insolitamente alta per la distanza (meno di 5 ms all'interno di un'area metropolitana, decine di millisecondi all'estero, 80-150 ms transoceanici) o se la latenza della destinazione finale è inaccettabile.

Vale la pena di prestare attenzione aStDev (jitter) in mtr. Valori superiori a 10 ms in qualsiasi hop possono causare problemi per VoIP, chiamate video e giochi. Se si nota un jitter elevato, eseguire almeno 100 cicli per verificare che si tratti di un andamento sostenuto e non di un breve picco.

Quando usare ogni strumento

Utilizzate il traceroute quando avete bisogno di una risposta rapida: la destinazione è raggiungibile e, in caso contrario, dove si interrompe il percorso? È il punto di partenza giusto per le interruzioni e per verificare il routing di base.

Usate mtr quando il problema è intermittente o legato alle prestazioni. Gli utenti che segnalano disconnessioni occasionali, problemi di qualità VoIP o picchi di latenza hanno bisogno dei dati continui di mtr. Eseguire almeno 50-100 cicli per ottenere statistiche affidabili.

Per una diagnosi completa, eseguire mtr in entrambe le direzioni: dal computer al server e dal server al proprio IP. Il routing su Internet è asimmetrico, quindi il percorso di ritorno può avere caratteristiche completamente diverse. Se si esegue il test solo in una direzione, è possibile che non si riesca a individuare il problema.

Se avete problemi con il vostro server dedicato o VPS, i team di assistenza di FDC Servers accettano i rapporti mtr come prova diagnostica standard per le escalation di rete.