Un valore di perdita su un hop di MTR non basta a indicare un collegamento guasto. Il router potrebbe limitare le risposte ICMP che riceve continuando a inoltrare il traffico. Per distinguere questo caso dagli errori fisici, dalle code sature o da un limite di velocità, occorre verificare se la perdita raggiunge la destinazione e confrontarla con i contatori dell'host.
Il percorso di questo tutorial è concreto: misurare con diverse dimensioni dei pacchetti, leggere il pattern di MTR, rilevare i contatori prima e dopo il test e, se necessario, aumentare gradualmente la velocità di un flusso UDP. Useremo indirizzi riservati alla documentazione: 198.51.100.10 come destinazione remota e eth0 come interfaccia locale. Sostituiscili con i valori del tuo ambiente.
flowchart TD
A["Medir con ping y MTR"] --> B["Comprobar el destino"]
B --> C["Revisar contadores locales"]
C --> D["Clasificar errores o colas"]
D --> E["Probar una tasa UDP"]
E --> F["Aislar el tramo y registrar"]Preparare una misurazione ripetibile
In Linux, installa MTR con il gestore di pacchetti della tua distribuzione. Alibaba Cloud documenta apt per Ubuntu e Debian e yum per CentOS e Alibaba Cloud Linux. L'esempio usa Debian o Ubuntu; i test seguenti richiedono anche iproute2, che fornisce il comando ip, e ethtool per consultare le statistiche del dispositivo.
# Debian o Ubuntu: installa MTR ed ethtool
sudo apt install mtr ethtoolPrima di eseguire i test, annota l'ora, l'interfaccia e la destinazione. Un campione breve può confondere una fluttuazione momentanea con una tendenza; il test seguente invia 200 sonde a intervalli di 0,2 secondi. Ripeti con pacchetti grandi e confronta le famiglie IPv4 e IPv6 se il problema si verifica anche con IPv6.
# Misura la perdita e la latenza con pacchetti piccoli e grandi
ping -c 200 -i 0.2 198.51.100.10
ping -c 200 -i 0.2 -s 1400 198.51.100.10
# Salva un report MTR con 200 sonde
mtr -rwzc 200 198.51.100.10Se falliscono solo i pacchetti grandi, verifica MTU o frammentazione prima di attribuire il problema alla congestione. Se la perdita si verifica in determinate fasce orarie, il pattern è compatibile con la congestione; se è costante, cerca anche un guasto persistente. Sono indizi, non una localizzazione definitiva.
Leggere MTR senza incolpare il primo hop che fallisce
MTR combina sonde continue con il tracciamento degli hop. La regola utile è osservare cosa succede dopo l'hop che mostra una perdita: se la destinazione non perde pacchetti, quel valore intermedio può riflettere una limitazione delle risposte ICMP, non una perdita del traffico inoltrato. Se lo stesso pattern continua fino alla destinazione, ci sono più motivi per indagare sul percorso dei dati.
Un hop che non risponde — talvolta rappresentato come ??? — non dimostra da solo che ci sia una perdita. Potrebbero non esserci informazioni di routing per quel nodo oppure il router potrebbe non rispondere alle sonde. Quando MTR mostra perdite su più hop, confronta le percentuali fino alla fine e non fermarti al primo valore diverso da zero. Per esempio, Alibaba Cloud descrive un campione in cui un hop indica il 41,2% e quello successivo lo 0%: questa discontinuità indica una limitazione delle risposte, non una perdita che si propaga lungo il percorso.
Se puoi, ripeti il test anche con TCP, oltre che con ICMP. La documentazione di Edge Diagnostics di Akamai avverte che le sonde ICMP possono essere soggette a limitazioni imposte dai provider o dai firewall; segnala inoltre che TCP può essere meno affidabile in alcuni dei suoi test. Se un tipo di sonda fallisce, confrontalo con l'altro invece di considerare un singolo risultato come verdetto.
Rilevare i contatori prima e dopo
Una route con sintomi non scagiona l'host stesso. Salva una lettura dell'interfaccia e delle statistiche del kernel, esegui il test e rileggile. Ciò che conta è l'incremento durante l'intervallo, non solo il valore accumulato dall'avvio del sistema.
# Controlla le statistiche dettagliate dell'interfaccia e del kernel
ip -s -s link show dev eth0
ethtool -S eth0 | grep -Ei 'err|drop|miss|fifo|crc'
nstat -az | grep -Ei 'drop|retrans|overflow'Linux espone le statistiche standard dell'interfaccia tramite ip; ripetendo -s vengono mostrati anche i campi dettagliati. ethtool -S fornisce le statistiche del dispositivo e del driver. I nomi specifici variano a seconda del dispositivo, quindi cerca le famiglie di contatori e confrontane i valori, senza presumere che tutti i driver pubblichino lo stesso insieme.
Un aumento di CRC, errori di frame o di allineamento indirizza l'indagine verso il livello fisico: cavo, connettore, ottica o negoziazione duplex. I contatori RX di pacchetti persi o FIFO possono indicare che la NIC o il driver non riescono a tenere il passo. Gli scarti TX o della qdisc indicano la coda di uscita. Al contrario, contatori puliti sull'host spostano i sospetti sul percorso tra gli endpoint, anche se da soli non identificano il tratto esatto.
Distinguere errori fisici, congestione e limiti di velocità
Consulta la disciplina di coda e la sua attività nello stesso periodo. Se gli scarti aumentano con il carico su un'interfaccia di uscita, controllane anche l'utilizzo: è un segnale diverso dagli errori CRC, che si riflettono nei contatori degli errori di collegamento.
# Consulta le statistiche della coda di uscita di eth0
tc -s qdisc show dev eth0Un pattern di coda che scarta pacchetti mentre il traffico aumenta è compatibile con la congestione o con raffiche che superano lo spazio disponibile nel buffer. Gli errori fisici, invece, aumentano nei contatori dell'interfaccia e possono verificarsi indipendentemente dal carico. Prima di sostituire l'hardware, registra i valori e ripeti il test: la variazione tra le due letture è la prova più utile.
Un policer o un limitatore di velocità tende a mostrare un andamento diverso: il throughput si stabilizza vicino a un tetto e compaiono perdite anche se il collegamento non sembra saturo. Per cercare questa soglia, invia UDP a una velocità fissa e aumentala con test successivi. L'esempio seguente richiede un server iperf3 raggiungibile sulla destinazione; inizia a 50 Mbit/s e dura 30 secondi.
# Invia UDP a 50 Mbit/s per 30 secondi
iperf3 -c 198.51.100.10 -u -b 50M -t 30Ripeti con velocità maggiori, modificando il valore di -b a ogni esecuzione. Una perdita che inizia bruscamente intorno a una determinata velocità è compatibile con un limite o un collo di bottiglia a quella velocità. Da sola non permette di distinguere i due casi: confronta il risultato con l'utilizzo e i contatori della coda e chiedi al provider di controllare il collegamento specifico se i dati indicano un problema esterno all'host.
Isolare il tratto e raccogliere prove
Se l'host è pulito e la perdita raggiunge la destinazione, confronta i punti intermedi che controlli. Puoi anche acquisire il traffico su entrambi gli endpoint e confrontare i pacchetti e i timestamp; un test nella direzione inversa è utile quando la latenza o la perdita in andata non spiegano ciò che osserva l'applicazione. MTR mostra il percorso dall'origine del test: non trasforma automaticamente l'hop con la perdita maggiore nel responsabile.
Quando segnali il caso a un operatore, fornisci la fascia oraria, gli indirizzi, la dimensione dei pacchetti, la velocità del test, il risultato di MTR e i contatori prima e dopo. Registra anche da quale endpoint è stato eseguito il test. Queste informazioni consentono di ripeterlo dopo una modifica e circoscrivono la discussione a un tratto e a un sintomo specifici.
La sequenza pratica è misurare, controllare la destinazione, verificare l'host e classificare il pattern prima di modificare la configurazione. Se un hop intermedio perde sonde ma la destinazione no, non considerare il percorso perso; se durante il test aumenta una coda o un contatore fisico, hai già un indizio locale che può essere verificato.
Fonti: DEV Community, Linux Kernel Documentation, Alibaba Cloud Documentation, Edge Diagnostics
