Trova la perdita di pacchetti con MTR e leggilo correttamente

Installalo

apt install -y mtr-tiny     # Debian
dnf install -y mtr          # AlmaLinux

Eseguito correttamente

mtr -rwbc 200 <destination>

• -r modalità report, così esce con qualcosa da incollare
• -w output largo, così i nomi host lunghi sopravvivono
• -b mostra il nome e l'indirizzo per ogni hop
• -c 200 duecento cicli, circa tre minuti e mezzo, e la differenza tra prove e aneddoti

Dieci pacchetti non provano nulla. Se un run di dieci cicli mostra perdita, esegui duecento cicli prima di trarre conclusioni.

Leggi prima l'ultimo hop

I router de-prioritizzano i pacchetti indirizzati a loro stessi. Un router di transito che trasporta centinaia di gigabit risponde alle tue sonde TTL scadute quando ha un ciclo libero e le lascia cadere quando non lo ha, il che dipinge la perdita nel mezzo del tuo report mentre ogni pacchetto che ti interessa arriva intatto.

Due regole coprono la maggior parte dei report:

1. La perdita all'hop sette che è assente all'hop otto e oltre è un rate limit. Ignorala.
2. La perdita che inizia all'hop sette e continua fino alla destinazione è reale, e l'hop dove inizia è dove guardare.

La latenza si comporta allo stesso modo. Un hop che aggiunge ottanta millisecondi e poi passa il traffico all'hop successivo a cifra precedente sta rispondendo lentamente, non inoltrando lentamente.

ICMP non è il tuo traffico

Se il servizio gira su TCP, testa su TCP:

mtr -rwbc 200 --tcp --port 443 <destination>

Le reti che limitano ICMP duramente spesso lasciano passare TCP intatto. Il caso inverso vale la pena scoprirlo prima di incolpare la rete di qualcuno: un firewall che risponde al ping felicemente e lascia cadere la porta a cui i tuoi utenti arrivano davvero.

Entrambe le direzioni, ogni volta

Il routing è asimmetrico più spesso di quanto non lo sia. Il percorso da te a noi non è il percorso da noi a te, e un report da un'estremità descrive esattamente uno dei due. Esegui MTR dall'istanza verso il client e dal client verso l'istanza, poi allega entrambi. La nostra metà del percorso può anche essere sondata senza shell da nessuna parte, dal looking glass.

Corrobora nei contatori TCP

MTR descrive il percorso. Le statistiche dei socket descrivono la conseguenza:

ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Un tasso di ritrasmissione superiore a circa l'uno percento, su una connessione che dovrebbe essere pulita, supporta il report. Zero ritrasmissioni insieme a un MTR pieno di perdita significa che stai guardando un rate limit e nient'altro.

Cosa inviarci

• Entrambi i report MTR, duecento cicli, come testo piuttosto che come screenshot
• Destinazione, trasporto e porta
• Timestamp con fuso orario, e se la perdita è costante o a raffiche
• L'ID dell'istanza

Circa la metà di questi si risolve in un hop centrale limitato, e lo diciamo nella prima risposta. Il resto di solito possiamo instradarlo entro un'ora: la perdita nella nostra rete è un nostro problema, e la perdita in un percorso di transito è questione di spostare il tuo traffico su uno diverso.