在繁忙的介面上進行 tcpdump 時出現大量丟包

在繁忙的介面上進行 tcpdump 時出現大量丟包

我的挑戰

我需要對大量資料進行 tcpdump - 實際上來自處於混雜模式的 2 個接口,這些接口能夠看到大量流量。

把它們加起來

  • 以混雜模式記錄來自 2 個介面的所有流量
  • 這些接口是不是分配一個IP位址
  • pcap 檔案必須每 ~1G 輪換一次
  • 當儲存 10 TB 檔案時,開始截斷最舊的文件

我目前在做什麼

現在我像這樣使用 tcpdump:

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

包含$FILTERsrc/dst 過濾器,以便我可以使用-i any.原因是,我有兩個接口,我想在單個線程而不是兩個線程中運行轉儲。

compress.sh負責將 tar 分配給另一個 CPU 核心、壓縮資料、為其指定合理的檔案名稱並將其移至存檔位置。

我無法指定兩個接口,因此我選擇使用過濾器並從any接口轉儲。

現在,我不做任何管理工作,但我計劃監視磁碟,當我剩下 100G 時,我將開始擦除最舊的文件 - 這應該沒問題。

現在;我的問題

我看到丟包。這是來自已運行幾個小時並收集了大約 250 GB 的 pcap 檔案的轉儲:

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

如何避免丟掉這麼多資料包?

這些事情我已經嘗試過或看過

/proc/sys/net/core/rmem_max改變了和的值/proc/sys/net/core/rmem_default這確實有幫助 - 實際上它處理了大約一半的丟棄資料包。

我也看過吞嚥- gulp 的問題是,它不支援一個進程中的多個接口,如果接口沒有 IP 位址,它就會生氣。不幸的是,這對我來說是一個破壞性的事情。

下一個問題是,當流量流過管道時,我無法進行自動旋轉。取得一個巨大的 10 TB 檔案效率不高,而且我沒有一台具有 10TB 以上 RAM 的機器可以運行wireshark,所以就這樣了。

你有什麼建議嗎?甚至可能是完全處理流量轉儲的更好方法。

答案1

tcpdump 將傳入資料儲存在環形緩衝區中。如果緩衝區在 tcpdump 處理其內容之前溢出,則會遺失資料包。

預設環形緩衝區大小可能是 2048(2MiB)。

若要增加緩衝區大小,請新增-B選項:

tcpdump -B 4096 ...

您還應該嘗試使用更快的磁碟儲存。

答案2

我最終找到了一個可以忍受的解決方案。丟棄的資料包已從 0.0047% 減少到 0.00013% - 乍一看似乎不多,但當我們談論數百萬個資料包時,就相當多了。

解決方案由幾個部分組成。一種是按照 Michael Hampton 的建議更改環形緩衝區大小。

另外,我創建了一個 ramfs 並對其進行了即時轉儲,重寫了我的壓縮腳本以負責將轉儲從 ramfs 移至磁碟。這僅減少了很少的量,但足以引起注意 - 儘管磁碟的所有測試和基準測試都表明磁碟不應該成為瓶頸。我想訪問時間在這裡非常重要。

禁用超線程的作用也比您想像的要多。

相關內容