Meine Herausforderung
Ich muss ein TCP-Dumping großer Datenmengen durchführen – und zwar von zwei Schnittstellen im Promiscuous-Modus, die viel Datenverkehr verarbeiten können.
Etwas zusammenfassen
- Protokollieren Sie den gesamten Datenverkehr im Promiscuous-Modus von 2 Schnittstellen
- Diese Schnittstellen sindnichteine IP-Adresse zugewiesen
- pcap-Dateien müssen pro ~1G rotiert werden
- Wenn 10 TB an Dateien gespeichert sind, beginnen Sie mit dem Abschneiden der ältesten
Was ich derzeit mache
Im Moment verwende 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, die ich verwenden kann -i any. Der Grund dafür ist, dass ich zwei Schnittstellen habe und den Dump lieber in einem einzigen Thread als in zwei ausführen möchte.
compress.shkümmert sich um die Zuweisung von Tar zu einem anderen CPU-Kern, komprimiert die Daten, gibt ihnen einen sinnvollen Dateinamen und verschiebt sie an einen Archivort.
Ich kann nicht zwei Schnittstellen angeben, deshalb habe ich mich dafür entschieden, Filter zu verwenden und von anyder Schnittstelle zu dumpen.
Im Moment mache ich keine Aufräumarbeiten, aber ich habe vor, die Festplatte zu überwachen und wenn ich noch 100 GB übrig habe, werde ich anfangen, die ältesten Dateien zu löschen – das sollte kein Problem sein.
Und jetzt; mein Problem
Ich sehe verlorene Pakete. Dies stammt aus einem Dump, der seit einigen Stunden läuft und ungefähr 250 GB an 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 verloren gehen?
Diese Dinge habe ich bereits ausprobiert bzw. mir angeschaut
Habe den Wert von /proc/sys/net/core/rmem_maxund geändert /proc/sys/net/core/rmem_default, was tatsächlich geholfen hat – tatsächlich hat es nur etwa die Hälfte der verlorenen Pakete behoben.
Ich habe mir auch angesehenSchluck- das Problem mit Gulp ist, dass es mehrere Schnittstellen in einem Prozess nicht unterstützt und wütend wird, wenn die Schnittstelle keine IP-Adresse hat. Leider ist das in meinem Fall ein Dealbreaker.
Das nächste Problem ist, dass ich die automatische Rotation nicht starten kann, wenn der Datenverkehr durch eine Leitung fließt. Eine riesige 10-TB-Datei zu erstellen ist nicht sehr effizient und ich habe keine Maschine mit 10 TB+ RAM, auf der ich Wireshark ausführen kann, also scheidet das aus.
Haben Sie Vorschläge? Vielleicht sogar eine insgesamt bessere Möglichkeit, meinen Traffic-Dump durchzuführen.
Antwort1
tcpdump speichert eingehende Daten in einem Ringpuffer. Wenn der Puffer überläuft, bevor tcpdump seinen Inhalt verarbeitet, gehen Pakete verloren.
Die Standardgröße des Ringpuffers beträgt wahrscheinlich 2048(2 MiB).
Um die Puffergröße zu erhöhen, fügen Sie die -BOption hinzu:
tcpdump -B 4096 ...
Sie sollten auch versuchen, schnelleren Festplattenspeicher zu verwenden.
Antwort2
Ich habe schließlich eine Lösung gefunden, mit der ich leben kann. Die Anzahl verlorener Pakete wurde von 0,0047 % auf 0,00013 % reduziert – was zunächst nicht viel erscheint, aber wenn wir von Millionen von Paketen sprechen, ist es ziemlich viel.
Die Lösung bestand aus mehreren Dingen. Eines davon bestand darin, die Ringpuffergröße zu ändern, wie von Michael Hampton vorgeschlagen.
Außerdem habe ich ein RAMFS erstellt und Live-Dumps dorthin gesendet und mein Komprimierungsskript umgeschrieben, damit die Dumps vom RAMFS auf die Festplatte verschoben werden. Dadurch wurde die Menge nur geringfügig verringert, aber genug, um bemerkenswert zu sein – obwohl alle Tests und Benchmarks der Festplatte zeigen, dass die Festplatte nicht der Engpass sein sollte. Ich denke, die Zugriffszeit ist hier sehr wichtig.
Auch das Deaktivieren von Hyper-Threading hat mehr bewirkt, als Sie gedacht hätten.