Come leggere la perdita di pacchetti prima di dare la colpa al cavo

Una perdita del due per cento lungo una lunga serie di ping sembra una cifra su cui si può agire, e raramente lo è. Non dice dove sono sparite le risposte, se sono sparite insieme né come ha vissuto quell’intervallo una determinata applicazione. Una perdita distribuita uniformemente su un minuto e una perdita raggruppata dentro un solo scambio producono esiti molto diversi per la stessa percentuale.

Confrontate tre misure invece di fidarvi di una: cosa ha visto la sonda, cosa hanno fatto i contatori dell’interfaccia e cosa ha aspettato davvero l’applicazione.

Cosa misura davvero una percentuale di ping

Una sonda d’eco prova una direzione di un protocollo con una dimensione di pacchetto, al ritmo che avete scelto. Un tunnel che trasporta un caricamento grande fa qualcosa di completamente diverso, e un collegamento che scarta sonde piccole non è necessariamente il collegamento che danneggia il trasferimento. La percentuale schiaccia anche l’informazione temporale che conta di più, perché dieci risposte perse in una raffica non sono la stessa cosa di dieci risposte perse a un’ora di distanza. Non può nemmeno dirvi quale lato del tunnel ha scartato qualcosa.

Tenete il risultato della sonda come indizio sul percorso. Poi cercate il momento e il confine che l’hanno prodotto.

Confrontate le differenze dei contatori, non i totali di vita

Prendete letture con marca temporale prima e dopo la finestra in cui è comparso il sintomo, a entrambe le estremità e su qualsiasi porta di commutatore che controllate. Registrate il volume di traffico insieme a errori, scarti e cambiamenti di stato del collegamento, perché un totale diverso da zero accumulato in mesi descrive la storia, non questo incidente. Un contatore che si è mosso di tre durante la pausa è un’osservazione diversa da un contatore che segna tremila e non è mai cambiato.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

I pacchetti scartati per errori di ricezione e i pacchetti scartati per altri motivi vivono in contatori separati, e questa distinzione cambia il seguito. I contatori di errore puntano al livello fisico o al livello del driver, mentre la pressione delle code e gli scarti di policy puntano a qualcosa più in alto. Conservate anche la direzione e il nome dell’interfaccia, perché un aumento di errori di ricezione su un collegamento salente e un contatore di pacchetti del tunnel non sono intercambiabili.

Se un driver espone contatori fisici dettagliati, leggeteli attraverso la documentazione di quell’adattatore. Attribuire un solo significato a ogni campo chiamato “drop” presso due produttori è il modo in cui una normale stranezza contabile diventa una diagnosi hardware.

Come un segmento perso diventa una lunga attesa

Un’applicazione può attendere molto più di un solo andata e ritorno dopo aver perso un segmento. TCP stima il tempo di andata e ritorno, calcola da quella stima un timer di ritrasmissione e arretra quando anche una ritrasmissione fallisce, così un singolo segmento perso nel momento sbagliato può bloccare una richiesta per un intervallo percepibile. Quel meccanismo è specificato in RFC 6298, e spiega perché un tasso di perdita che sembra banale può comunque farsi sentire.

Non ogni pausa è però un timeout di ritrasmissione. La stessa attesa può venire dalla risoluzione dei nomi, da un server lento o da un’applicazione che ritenta la propria richiesta dopo un errore. Separate questi casi allineando l’operazione fallita con le osservazioni di trasporto e con gli eventi di sessione del tunnel stesso. Un’interruzione sul percorso dati senza riconnessione è un evento diverso da una nuova stretta di mano e da uno scambio di credenziali.

Dove la cattura è consentita, tenetela stretta. Ciò che vi serve è se i pacchetti o gli acknowledgement attesi si fermano a un confine preciso, non il fatto che esista una ritrasmissione da qualche parte in una traccia trafficata.

Cambiate un confine senza spostare gli altri

Se le prove indicano un collegamento locale, sostituite un cavo o una porta approvati come confronto controllato e lasciate stare tutto il resto. Mantenete comparabili l’estremità, l’applicazione e il carico di lavoro, e cambiate esattamente un confine per tentativo. Confrontare un portatile cablato con uno senza fili mentre cambiate anche uscite e protocolli non vi dice nulla che possiate attribuire.

Contatori locali puliti non certificano il resto del percorso. Delimitano la parte che vedete, e il resoconto onesto dice quali confini sono stati osservati e quali no. Alla fine volete un’affermazione che un’osservazione è cambiata quando è avvenuto un intervento, non un aneddoto su un cavo difettoso elevato a regola universale.