Leggere un traceroute: perché la perdita all'hop 5 quasi mai significa qualcosa

Un sito sembra lento, qualcuno lancia un traceroute ed eccolo: 40 per cento di perdita all'hop 5. Sembra la risposta. Quasi mai lo è, e agire di conseguenza manda le persone a inseguire un router che funziona benissimo.

Il traceroute è uno strumento davvero utile costruito su un trucco, ed è quel trucco a rendere il suo output così facile da leggere male.

Cosa fa davvero un traceroute

Manda pacchetti con un TTL volutamente piccolo. Il primo router lo porta a zero, rinuncia e rimanda indietro un messaggio ICMP Time Exceeded. È da quella risposta che scoprite che il router esiste. Con TTL 2 arriva il secondo, e così via finché i pacchetti raggiungono la destinazione.

Quindi ogni riga tranne l'ultima non misura il vostro traffico. Misura quanto in fretta un router ha deciso di generare un messaggio di errore riguardo al vostro traffico. Sono cose diverse, e i router le trattano in modo diverso.

Perché gli hop centrali mentono

Generare risposte ICMP non è il mestiere di un router. L'inoltro avviene in hardware; rispondere a un TTL scaduto tocca al piano di controllo, una CPU molto più piccola con compiti più importanti. La maggior parte dei router limita la frequenza di quelle risposte e alcuni le scartano del tutto.

Il risultato è un hop che mostra il 40 per cento di perdita mentre lascia passare il 100 per cento del traffico. Ne discendono due regole, che risolvono sul posto la maggior parte di questi ticket:

Una perdita che non prosegue fino in fondo non è una perdita. Se l'hop 5 segna quaranta per cento e gli hop dal 6 al 12 segnano zero, non si è perso nulla. L'hop 5 semplicemente non aveva voglia di rispondere.
Conta solo l'ultima riga. La perdita alla destinazione, se persiste, è reale. È quel numero a meritare un'escalation.

Un hop con latenza alta si comporta allo stesso modo. Un router che risponde lentamente al proprio ICMP non inoltra necessariamente lentamente.

La metà che non vedete

Un traceroute mostra il percorso di andata. Del ritorno non dice nulla, e i due sono spesso diversi: i vostri pacchetti possono uscire da un operatore di transito e le risposte tornare da un altro. Su internet è normale e non è un guasto.

Conta perché il problema che state cercando può stare interamente sul percorso di ritorno, che il vostro traceroute non vede affatto. Per questo una traccia in un solo senso finisce spesso con il supporto che chiede altro invece di riparare: manca metà delle prove.

Per lo stesso motivo la soluzione a volte vive in una rete che non è né vostra né nostra. Quando si gestisce un proprio AS e le proprie sessioni BGP, la via di ritorno del traffico si può correggere a monte, non soltanto spiegare.

Usate mtr

mtr è traceroute e ping insieme. Continua a inviare, così vedete la perdita come percentuale nel tempo invece di tirare a indovinare su tre sonde:

mtr -rwzbc 200 dcxv.com

-r modalità report, stampa una volta ed esce
-w output largo, perché i nomi lunghi non vengano troncati
-z mostra il numero di AS di ogni hop, cioè di chi è quella rete
-b mostra nome e IP insieme
-c 200 invia 200 sonde, perché 10 non dicono nulla su una perdita intermittente

Su Windows, WinMTR fa lo stesso lavoro. Lasciatelo girare un paio di minuti prima di leggerci dentro qualcosa.

Cosa mandare al supporto

La cosa più utile da allegare è mtr nelle due direzioni: uno dalla vostra macchina al server e uno dal server al vostro indirizzo, presi nello stesso momento. Quella coppia trasforma un'ipotesi unilaterale in qualcosa di attribuibile a una rete precisa.

Aggiungete l'IP di destinazione, il vostro indirizzo pubblico, l'ora con il fuso orario e se il problema è costante o va e viene. Se va e viene, dite quando. Una perdita intermittente con ritmo giornaliero di solito è congestione da qualche parte, e conoscere l'ora restringe in fretta il campo.

Cosa non aiuta: uno screenshot di un singolo traceroute con un cerchio rosso attorno a un hop centrale. È l'allegato più frequente e il meno utilizzabile.

In sintesi

Leggete l'ultima riga, non quelle centrali. Una perdita che non arriva fino alla destinazione è un router che rifiuta di rispondere, non una rete che butta via il vostro traffico. Quando qualcosa non va davvero, mtr nelle due direzioni trasforma una lamentela in un rapporto su cui si può lavorare.

Server cloud e dedicati in Cechia e Portogallo, sulla nostra rete AS204057: dcxv.com/data-center#cloud