Molti pacchetti rilasciati quando tcpdumping su interfaccia occupata

La mia sfida

Devo fare il dumping di molti dati - in realtà da 2 interfacce lasciate in modalità promiscua in grado di vedere molto traffico.

Riassumendo

• Registra tutto il traffico in modalità promiscua da 2 interfacce
• A tali interfacce non è assegnato un indirizzo IP
• I file pcap devono essere ruotati di ~ 1G
• Quando vengono memorizzati 10 TB di file, iniziare a troncare il più vecchio

Quello che faccio attualmente

In questo momento uso tcpdump in questo modo:

ifconfig ethX promisc
ifconfig ethX promisc
tcpdump -n -C 1000 -z /data/compress.sh -i any -w /data/livedump/capture.pcap $FILTER

Il $FILTERcontiene filtri src / DST modo che io possa usare -i any. Il motivo è che ho due interfacce e vorrei eseguire il dump in un singolo thread anziché in due.

compress.sh si occupa di assegnare tar a un altro core della CPU, comprimere i dati, dargli un nome file ragionevole e spostarlo in una posizione di archivio.

Non riesco a specificare due interfacce, quindi ho scelto di usare filtri e dump anydall'interfaccia.

In questo momento, non faccio alcun servizio di pulizia, ma ho intenzione di monitorare il disco e quando mi restano 100 G inizierò a cancellare i file più vecchi - questo dovrebbe andare bene.

E adesso; il mio problema

Vedo i pacchetti rilasciati. Questo proviene da una discarica che è in esecuzione da alcune ore e ha raccolto circa 250 concerti di file pcap:

430083369 packets captured
430115470 packets received by filter
32057 packets dropped by kernel  <-- This is my concern

Come posso evitare che così tanti pacchetti vengano eliminati?

Queste cose che ho già provato o guardato

Modificato il valore /proc/sys/net/core/rmem_maxe /proc/sys/net/core/rmem_defaultche in effetti ha aiutato - in realtà si è preso cura di circa la metà dei pacchetti rilasciati.

Ho anche esaminato gulp : il problema con gulp è che non supporta più interfacce in un processo e si arrabbia se l'interfaccia non ha un indirizzo IP. Sfortunatamente, nel mio caso questo è un problema.

Il prossimo problema è che quando il traffico scorre attraverso una pipe, non riesco a far funzionare la rotazione automatica. Ottenere un enorme file da 10 TB non è molto efficiente e non ho una macchina con 10 TB + RAM su cui posso eseguire WireShark, quindi è fuori.

Hai qualche suggerimento? Forse anche un modo migliore di fare del tutto il mio dump del traffico.

tcpdump archivia i dati in arrivo in un buffer ad anello. Se il buffer trabocca prima che tcpdump elabori il suo contenuto, si perdono i pacchetti.

La dimensione predefinita del buffer dell'anello è probabilmente 2048 (2 MiB).

Per aumentare la dimensione del buffer, aggiungere l' -Bopzione:

tcpdump -B 4096 ...

Dovresti anche provare a utilizzare una memoria su disco più veloce.

Ho finito per trovare una soluzione con cui convivere. I pacchetti rilasciati sono stati ridotti da 0,0000% a 0,00013%, cosa che all'inizio non sembra molto, ma quando parliamo di milioni di pacchetti, è parecchio.

La soluzione consisteva in diverse cose. Uno era quello di cambiare la dimensione del buffer dell'anello come suggerito da Michael Hampton.

Inoltre, ho creato un ramfs e ho scaricato dal vivo su quello, riscritto il mio script compress per occuparmi di spostare i dump da ramfs su disco. Questo ha solo ridotto la quantità molto poco, ma abbastanza per essere notevole - anche se tutti i test e il benchmarking del disco mostrano, che il disco non dovrebbe essere il collo di bottiglia. Immagino che il tempo di accesso sia molto importante qui.

La disabilitazione dell'hyper threading ha fatto anche più di quanto pensassi.