Come si diagnostica la perdita di pacchetti?

Mi rendo conto che questo è molto soggettivo e dipende da una serie di variabili, ma mi chiedo quali passi attraversano la maggior parte delle persone quando hanno bisogno di diagnosticare la perdita di pacchetti su un determinato sistema?

Sono un ingegnere di rete, quindi lo descriverò dal mio punto di vista.

Per me, la diagnosi della perdita di pacchetti di solito inizia con "non funziona molto bene". Da lì, di solito cerco di trovare il kit il più vicino possibile a entrambe le estremità della comunicazione (in genere, una stazione di lavoro in un ufficio e un server da qualche parte) e ping il più vicino possibile all'altra estremità (idealmente "end-point remoto", ma a volte ci sono firewall attraverso i quali non riesco a inviare ping, quindi dovrò accontentarmi di un'interfaccia LAN su un router) e vedere se riesco a vedere qualche perdita.

Se riesco a vedere la perdita, di solito è un caso di "larghezza di banda insufficiente" o "collegamento con problemi" da qualche parte nel mezzo, quindi trova il percorso attraverso la rete e inizia dalla metà, che di solito ti dà una fine o l'altra.

Se non riesco a vedere la perdita, i due passaggi successivi tendono ad essere "invia più ping" o "invia ping più grandi". Se ciò non consente di dare un'indicazione di quale sia il problema, è tempo di iniziare a esaminare le politiche QoS e le statistiche dell'interfaccia attraverso l'intero percorso tra gli end-point.

Se ciò non trova nulla, è il momento di iniziare a mettere in discussione i tuoi presupposti, stai davvero soffrendo di perdita di pacchetti. L'unico modo sicuro per scoprire che è fare acquisizioni simultanee su entrambe le estremità, usando WireShark (o equivalente) sugli host o collegando macchine sniffer (probabilmente usando WireShark o simili) tramite i tocchi di rete. Poi arriva il divertimento di confrontare le due acquisizioni di pacchetti ...

A volte, ciò che viene attribuito come "perdita di pacchetti" è semplicemente qualcosa sul lato server che è notevolmente più lento (come, diciamo, spostare il database da "sulla stessa LAN" a "20 ms di distanza" e usare query che richiedono un sacco di avanti e indietro tra front-end e database).

Dal punto di vista di un sistema Linux, cercherò innanzitutto la perdita di pacchetti sull'interfaccia di rete con ethtool -S ethX.

Il più delle volte, aumentando il buffer dell'anello ethtool -G ethX rx VALUErisolve questo problema.

A volte gli interrupt non si bilanciano perché al sistema manca il servizio di irqbalance, quindi cerca in chkconfig(EL) o update-rc(Debuntu) per vedere se questo servizio è in esecuzione. Puoi dire se gli interrupt non sono in bilanciamento perché /proc/interruptsmostreranno solo Core 0 che serve tutti i canali IRQ.

In caso contrario, potrebbe essere necessario aumentare net.core.netdev_max_backlogse il sistema sta passando più di qualche gigabit di traffico, e forse net.core.netdev_budget.

Se ciò non funziona, è possibile modificare i valori di coalescenza di interruzione con ethtool -C.

Se non ci sono drop di pacchetti sull'interfaccia di rete, cerca netstat -se vedi se ci sono drop nei buffer dei socket, questi saranno segnalati con statistiche come " pruned from receive queue" e " dropped from out-of-order queue".

Puoi provare ad aumentare i buffer socket predefiniti e max per il protocollo appropriato (ad esempio: net.ipv4.tcp_rmemper TCP).

Se l'applicazione imposta la propria dimensione del buffer socket, l'applicazione potrebbe richiedere modifiche alla configurazione. Se la tua applicazione ha dimensioni del buffer socket codificate, contatta il fornitore dell'applicazione.

Personalmente non mi piace l'offload del protocollo su NIC (checksum, offload di segmentazione, offload di ricezione di grandi dimensioni) in quanto sembra causare più problemi di quanto valga la pena. Giocare con queste impostazioni ethtool -Kpuò valere la pena di provare.

Guarda le opzioni del modulo per la tua scheda di rete ( modinfo <drivername>) in quanto potrebbe essere necessario modificare alcune funzionalità. Per fare un esempio che ho riscontrato, l'utilizzo del Flow Director di Intel su un sistema che gestisce un grande flusso TCP probabilmente danneggerà l'efficienza di tale flusso, quindi disattivare FDir.

Oltre a ciò, stai mettendo a punto questo sistema specifico per il suo carico di lavoro specifico, che immagino esuli dalla portata della tua domanda.

Inizierò utilizzando lo strumento di acquisizione dei pacchetti come: WireShark (su Windows) e TCPCDump (sul terminale Linux).

Controllerò anche la configurazione del firewall (firewall host e firewall di rete).

Isolare, quindi eliminare.

Trova il sottoinsieme più piccolo di percorsi con il problema. Fallo testando diverse combinazioni e / o distillando i rapporti degli utenti. Non dimenticare di considerare il tempo nell'equitazione. Forse è solo perdita di pacchetti su tutto il traffico verso una rete specifica, o forse solo i client wireless soffrono. Prendi in considerazione diversi tipi di traffico (limite di velocità sui ping). Trova il modo più affidabile e facilmente ripetibile per testarlo.

Quindi eliminare le potenziali cause. Ridurre il traffico sui collegamenti (temporaneamente), rimuovere le fonti di interferenza dallo spettro, disconnettere alcuni client. Alla fine troverai la fonte del problema.

A volte puoi prendere scorciatoie guardando i dump dei pacchetti o fare ipotesi (è sempre bittorrent). Inoltre, di 'al tuo professore che serverfault è fantastico.

I ping potrebbero non mostrare la perdita di pacchetti a meno che non invii ping di grandi dimensioni! Ho avuto una perdita di pacchetti sulla mia rete che era invisibile fino a quando non ho aumentato la dimensione del mio pacchetto di ping.

Per windows:

ping -n 30 -l <largevalue> <target>

Per largevalueho usato 40960 (pacchetto 40k)

Per targetho usato i primi pochi indirizzi IP datracert google.com

(che era il mio router e modem via cavo). Uno dei dispositivi più in basso nella catena ha avuto una terribile perdita di pacchetti (> 60%) per pacchetti di grandi dimensioni, ma 0% per piccoli. L'ho risolto riavviandolo, ma potrebbe anche essere un cavo o qualcosa di interno che deve essere sostituito.