Beaucoup de paquets abandonnés lors du tcpdumping sur une interface occupée

Mon défi

J'ai besoin de faire le tcpdumping de beaucoup de données - en fait à partir de 2 interfaces laissées en mode promiscuous qui sont capables de voir beaucoup de trafic.

Résumer

• Consigner tout le trafic en mode promiscuité à partir de 2 interfaces
• Ces interfaces ne reçoivent pas d'adresse IP
• les fichiers pcap doivent être tournés par ~ 1G
• Lorsque 10 To de fichiers sont stockés, commencez à tronquer le plus ancien

Ce que je fais actuellement

En ce moment j'utilise tcpdump comme ceci:

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

Le $FILTERcontient des filtres src / dst afin que je puisse les utiliser -i any. La raison en est que j'ai deux interfaces et que je voudrais exécuter le vidage dans un seul thread plutôt que deux.

compress.sh prend soin d'attribuer tar à un autre cœur de processeur, de compresser les données, de lui donner un nom de fichier raisonnable et de le déplacer vers un emplacement d'archivage.

Je ne peux pas spécifier deux interfaces, j'ai donc choisi d'utiliser des filtres et un vidage depuis l' anyinterface.

Pour le moment, je ne fais pas de ménage, mais je prévois de surveiller le disque et quand il me restera 100 Go, je commencerai à effacer les fichiers les plus anciens - ça devrait aller.

Et maintenant; mon problème

Je vois des paquets perdus. Cela provient d'un vidage qui fonctionne depuis quelques heures et a collecté environ 250 Go de fichiers PCAP:

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

Comment puis-je éviter de perdre autant de paquets?

Ces choses que j'ai déjà essayées ou regardées

Modifié la valeur de /proc/sys/net/core/rmem_maxet /proc/sys/net/core/rmem_defaultqui a effectivement aidé - en fait, il a pris en charge à peu près la moitié des paquets perdus.

J'ai également regardé gulp - le problème avec gulp est qu'il ne prend pas en charge plusieurs interfaces en un seul processus et qu'il se met en colère si l'interface n'a pas d'adresse IP. Malheureusement, c'est une rupture dans mon cas.

Le problème suivant est que lorsque le trafic passe par un tuyau, je ne peux pas lancer la rotation automatique. Obtenir un énorme fichier de 10 To n'est pas très efficace et je n'ai pas de machine avec 10 To + RAM sur laquelle je peux exécuter wirehark, donc c'est fini.

Avez-vous des suggestions? Peut-être même une meilleure façon de faire mon vidage de trafic.

tcpdump stocke les données entrantes dans un tampon en anneau. Si le tampon déborde avant que tcpdump traite son contenu, vous perdez des paquets.

La taille du tampon en anneau par défaut est probablement 2048 (2 Mo).

Pour augmenter la taille du tampon, ajoutez l' -Boption:

tcpdump -B 4096 ...

Vous devriez également essayer d'utiliser un stockage sur disque plus rapide.

J'ai fini par trouver une solution avec laquelle vivre. Les paquets supprimés ont été réduits de .0047% à .00013% - ce qui ne semble pas beaucoup au début, mais lorsque nous parlons de millions de paquets, c'est beaucoup.

La solution consistait en plusieurs choses. L'une consistait à modifier la taille du tampon de l'anneau comme l'avait suggéré Michael Hampton.

De plus, j'ai créé un ramfs et j'ai fait un dumping en direct, j'ai réécrit mon script de compression pour prendre soin de déplacer les vidages de ramfs vers le disque. Cela n'a diminué que très peu, mais suffisamment pour être notable - même si tous les tests et l'analyse comparative du disque montrent que le disque ne devrait pas être le goulot d'étranglement. Je suppose que le temps d'accès est très important ici.

La désactivation de l'hyper threading a également fait plus que vous ne le pensiez.