Traceroute: come interpretare i risultati passo per passo

Il traceroute è uno degli strumenti di diagnostica di rete più utili a disposizione di chiunque. Non serve essere un tecnico per usarlo, ma serve capire cosa sta dicendo. L'output è spesso ignorato o frainteso, il che porta a conclusioni sbagliate su dove si trova effettivamente un problema. Questa guida spiega come leggerlo correttamente.

Come funziona traceroute

Traceroute sfrutta il campo TTL (Time To Live) degli header IP. Ogni pacchetto IP nasce con un valore TTL (tipicamente 64 o 128). Ogni router che lo instrada decrementa il TTL di 1. Quando il TTL raggiunge zero, il router scarta il pacchetto e risponde con un messaggio ICMP "Time Exceeded" al mittente.

Traceroute invia una serie di pacchetti con TTL crescente: prima 1, poi 2, poi 3, e così via. Il primo pacchetto viene scartato dal primo hop (il tuo router o gateway), il secondo dal secondo hop, e così via fino alla destinazione. Raccogliendo le risposte, traceroute ricostruisce il percorso completo.

Su Linux e macOS il comando usa pacchetti UDP per default; su Windows usa ICMP. La variante traceroute -I (ICMP) è spesso più efficace perché molti firewall bloccano UDP ma lasciano passare ICMP echo.

Leggere l'output

Un output tipico su Linux:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max
 1  192.168.1.1    0.8 ms   0.7 ms   0.9 ms
 2  10.0.0.1       3.2 ms   3.1 ms   3.4 ms
 3  185.24.x.x     5.1 ms   5.3 ms   5.0 ms
 4  89.97.x.x      6.8 ms   6.9 ms   7.1 ms
 5  72.14.x.x     12.4 ms  12.3 ms  12.5 ms
 6  * * *
 7  8.8.8.8        12.9 ms  12.8 ms  13.1 ms

Ogni riga rappresenta un hop — un router intermedio. Le tre colonne di millisecondi sono i RTT (Round-Trip Time) di tre sonde separate inviate verso quello stesso hop.

• Hop 1: il tuo gateway — solitamente il router di casa, latenza < 2 ms in condizioni normali
• Hop 2: il primo apparato dell'operatore (DSLAM, OLT, aggregation switch)
• Hop 3 in poi: backbone dell'ISP, poi eventualmente peering verso la destinazione

Asterischi: cosa significano davvero

Le righe con * indicano che quel router non ha risposto alle sonde di traceroute. Ci sono due motivi principali:

1. Il router filtra i pacchetti ICMP TTL-Exceeded — molti router di backbone non rispondono per scelta di configurazione (riduzione del carico CPU, sicurezza). Il router esiste e instrada traffico normalmente, ma non risponde alle sonde.
2. Il router non raggiungibile — caso molto meno frequente, ma reale se la rete è interrotta in quel punto.

Il modo per distinguerli: se dopo gli asterischi la traccia riprende con hop successivi che rispondono, il problema è solo il silenzio di quel router specifico — il traffico ci passa ugualmente. Se invece gli asterischi continuano fino al termine della traccia, lì c'è un blocco reale.

Latenze: dove guardare

Un errore comune è allarmarsi per un singolo hop con latenza alta. La latenza che conta è quella dell'ultimo hop — la destinazione finale. La latenza dei singoli hop intermedi non è sempre significativa perché:

• I router danno priorità bassa ai pacchetti ICMP di risposta rispetto al traffico normale
• Un hop può sembrare lento ma instradare il traffico reale senza problemi
• La latenza si accumula ma non deve necessariamente aumentare in modo uniforme

Pattern di problema reale:

 3  185.24.x.x      5.1 ms
 4  89.97.x.x      85.4 ms   ← spike improvviso
 5  72.14.x.x      86.2 ms
 6  8.8.8.8        87.0 ms

Qui la latenza sale bruscamente all'hop 4 e rimane alta fino alla destinazione. Questo indica un problema reale in quel segmento — congestione, un link degradato, o routing subottimale.

Pattern non preoccupante:

 3  185.24.x.x     5.1 ms
 4  89.97.x.x     45.2 ms   ← hop lento
 5  72.14.x.x      6.3 ms   ← torna basso
 6  8.8.8.8        6.8 ms

L'hop 4 sembra lento, ma la destinazione è raggiunta in 6.8 ms. Il router all'hop 4 stava semplicemente dando bassa priorità alle proprie risposte ICMP.

Packet loss: diagnosi

Se vedi * in mezzo a una traccia che poi riprende, non è packet loss — è silenzio voluto. Il vero packet loss si identifica così:

• Usi mtr (un traceroute continuo con statistiche): mtr -n 8.8.8.8
• Guardi la colonna Loss% per ogni hop
• Se la perdita appare a un hop intermedio ma NON agli hop successivi, è il router intermedio che scarta le sonde (ma non il traffico reale)
• Se la perdita appare all'ultimo hop (destinazione), hai packet loss reale verso quella destinazione

Traceroute e reti MPLS

Nelle reti degli operatori è comune incontrare tratti MPLS (Multiprotocol Label Switching). Su questi tratti il campo TTL può essere preservato o nascosto a seconda della configurazione. Potresti vedere hop con IP privati (10.x.x.x, 172.16.x.x) oppure salti numerici inspiegabili — hop 3 che risponde, poi silenzio fino all'hop 7.

Questo è normale e non indica un problema. Il traffico transita attraverso nodi MPLS che non rispondono a traceroute ma instradano correttamente.

Strumenti pratici

Su Linux e macOS:

# Traceroute base
traceroute -n 8.8.8.8

# Con ICMP invece di UDP (più compatibile con firewall)
traceroute -I -n 8.8.8.8

# MTR: statistiche continue, molto più informativo
mtr -n --report --report-cycles 100 8.8.8.8

Su Windows:

tracert 8.8.8.8

Per analisi più dettagliate, mtr con l'opzione --report genera un report sintetico dopo N cicli — utile per diagnosticare problemi intermittenti che una singola traccia non mostrerebbe.

Caso d'uso pratico: connessione lenta

Scenario: internet lenta, vuoi capire dove si trova il collo di bottiglia.

1. Esegui mtr -n --report-cycles 50 8.8.8.8
2. Guarda l'RTT medio dell'hop 1 (gateway): dovrebbe essere < 5 ms. Se è > 20 ms, il problema è nel tratto locale (router sovraccarico, Wi-Fi congestionato, ONT)
3. Guarda l'hop 2 (primo router ISP): se sale significativamente qui, il problema è nel tratto tra te e il DSLAM/OLT
4. Se la latenza alta appare solo agli hop di backbone (5+), è probabile congestione su un link intermedio dell'operatore
5. Se la destinazione finale ha latenza alta ma tutti gli hop prima sono OK, il problema è sul server di destinazione

Traceroute non risolve i problemi, ma li localizza. Avere questo dato quando si contatta il supporto tecnico dell'operatore è la differenza tra una risposta utile e un generico "eseguiamo un check sulla linea".