Viele verworfene Pakete beim tcpdumping auf einer ausgelasteten Schnittstelle

Meine Herausforderung

Ich muss eine Menge Daten tcpdumping - tatsächlich von 2 Schnittstellen, die im Promiscuous-Modus verbleiben und viel Verkehr sehen können.

Etwas zusammenfassen

• Protokollieren Sie den gesamten Datenverkehr im Promiscuous-Modus von 2 Schnittstellen
• Diesen Schnittstellen wird keine IP-Adresse zugewiesen
• PCAP-Dateien müssen pro ~ 1G gedreht werden
• Wenn 10 TB Dateien gespeichert sind, schneiden Sie die ältesten ab

Was ich gerade mache

Im Moment benutze ich tcpdump wie folgt:

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

Das $FILTERenthält src / dst Filter, damit ich verwenden kann -i any. Der Grund dafür ist, dass ich zwei Schnittstellen habe und den Speicherauszug in einem einzigen Thread anstatt in zwei ausführen möchte.

compress.sh kümmert sich darum, tar einem anderen CPU-Kern zuzuweisen, die Daten zu komprimieren, ihm einen angemessenen Dateinamen zu geben und ihn an einen Archivspeicherort zu verschieben.

Ich kann nicht zwei Schnittstellen angeben, daher habe ich mich für die Verwendung von Filtern und Dump von der anySchnittstelle entschieden.

Im Moment mache ich keine Hausarbeit, aber ich plane, die Festplatte zu überwachen, und wenn ich noch 100G habe, werde ich anfangen, die ältesten Dateien zu löschen - das sollte in Ordnung sein.

Und nun; mein Problem

Ich sehe verworfene Pakete. Dies ist von einem Dump, der seit einigen Stunden läuft und ungefähr 250 Gigs PCAP-Dateien gesammelt hat:

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

Wie kann ich verhindern, dass so viele Pakete verworfen werden?

Diese Dinge habe ich schon ausprobiert oder angeschaut

Der Wert von wurde geändert /proc/sys/net/core/rmem_maxund /proc/sys/net/core/rmem_defaultwas hat tatsächlich geholfen - tatsächlich hat es nur etwa die Hälfte der verworfenen Pakete erledigt.

Ich habe mir auch gulp angesehen - das Problem mit gulp ist, dass es nicht mehrere Schnittstellen in einem Prozess unterstützt und es wütend wird, wenn die Schnittstelle keine IP-Adresse hat. Leider ist das in meinem Fall ein Deal Breaker.

Das nächste Problem ist, dass ich die automatische Rotation nicht in Gang bringen kann, wenn der Verkehr durch eine Leitung fließt. Das Abrufen einer riesigen 10-TB-Datei ist nicht sehr effizient und ich habe keinen Computer mit 10 TB + RAM, auf dem wir Wireshark ausführen können.

Hast du irgendwelche Vorschläge? Vielleicht sogar eine bessere Möglichkeit, meinen Traffic Dump insgesamt zu erledigen.

tcpdump speichert eingehende Daten in einem Ringpuffer. Wenn der Puffer überläuft, bevor tcpdump seinen Inhalt verarbeitet, verlieren Sie Pakete.

Die Standardgröße des Ringpuffers beträgt wahrscheinlich 2048 (2 MB).

Fügen Sie die -BOption hinzu, um die Puffergröße zu erhöhen :

tcpdump -B 4096 ...

Sie sollten auch versuchen, einen schnelleren Festplattenspeicher zu verwenden.

Am Ende habe ich eine Lösung gefunden, mit der ich leben kann. Die Anzahl der verworfenen Pakete wurde von 0,0047% auf 0,00013% verringert - was auf den ersten Blick nicht viel zu sein scheint, aber wenn wir über Millionen von Paketen sprechen, ist es ziemlich viel.

Die Lösung bestand aus mehreren Dingen. Eine bestand darin, die Ringpuffergröße zu ändern, wie von Michael Hampton vorgeschlagen.

Außerdem habe ich ein Ramfs erstellt und Live-Dumping durchgeführt. Ich habe mein Komprimierungsskript neu geschrieben, um sicherzustellen, dass die Dumps von Ramfs auf die Festplatte verschoben werden. Dies verringerte die Menge nur sehr wenig, aber genug, um bemerkenswert zu sein - obwohl alle Tests und das Benchmarking der Festplatte zeigen, dass die Festplatte nicht der Engpass sein sollte. Ich denke, der Zugang ist hier sehr wichtig.

Das Deaktivieren von Hyper-Threading hat auch mehr bewirkt, als Sie gedacht hatten.