Много отброшенных пакетов при tcpdumping на занятом интерфейсе

Мой вызов

Мне нужно сделать tcpdumping много данных - на самом деле из 2 интерфейсов, оставленных в случайном режиме, которые могут видеть много трафика.

Подвести итог

• Журнал всего трафика в случайном режиме с 2 интерфейсов
• Этим интерфейсам не назначен IP-адрес
• pcap файлы должны быть повернуты на ~ 1G
• Когда сохранено 10 ТБ файлов, начните усечение самого старого

Чем я сейчас занимаюсь

Прямо сейчас я использую tcpdump вот так:

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

$FILTERСодержит SRC / Dst фильтры , так что я могу использовать -i any. Причина этого в том, что у меня есть два интерфейса, и я хотел бы запустить дамп в одном потоке, а не в двух.

compress.sh заботится о назначении tar другому ядру процессора, сжимает данные, дает ему разумное имя файла и перемещает его в место архивирования.

Я не могу указать два интерфейса, поэтому я решил использовать фильтры и дамп из anyинтерфейса.

Прямо сейчас я не занимаюсь уборкой, но планирую следить за диском, и когда у меня останется 100G, я начну стирать самые старые файлы - это должно быть хорошо.

И сейчас; моя проблема

Я вижу упавшие пакеты. Это из дампа, который работал несколько часов и собрал примерно 250 гигов файлов 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 - проблема с gulp в том, что он не поддерживает несколько интерфейсов в одном процессе, и он злится, если у интерфейса нет IP-адреса. К сожалению, в моем случае это нарушает условия сделки.

Следующая проблема заключается в том, что, когда трафик проходит через канал, я не могу запустить автоматическое вращение. Получение одного огромного файла размером 10 ТБ не очень эффективно, и у меня нет машины с 10 ТБ + ОЗУ, на которой я могу запустить wireshark, так что этого нет.

Есть ли у вас какие-либо предложения? Может быть, даже лучший способ сделать мой трафик в целом.

tcpdump сохраняет входящие данные в кольцевом буфере. Если буфер переполняется до того, как tcpdump обработает его содержимое, вы потеряете пакеты.

Размер кольцевого буфера по умолчанию, вероятно, составляет 2048 (2 МБ).

Чтобы увеличить размер буфера, добавьте -Bпараметр:

tcpdump -B 4096 ...

Вам также следует попробовать использовать более быстрое дисковое хранилище.

Я закончил тем, что нашел решение, с которым нужно жить. Количество отброшенных пакетов было уменьшено с 0,0047% до 0,00013%, что поначалу кажется незначительным, но когда мы говорим о миллионах пакетов, это довольно много.

Решение состояло из нескольких вещей. Одним из них было изменение размера кольцевого буфера, как это было предложено Майклом Хэмптоном.

Кроме того, я создал ramfs и выполнил дамп для этого, переписал свой скрипт сжатия, чтобы позаботиться о перемещении дампов из ramfs на диск. Это лишь немного уменьшило количество, но достаточно, чтобы быть заметным - даже если все тестирование и тестирование диска показывают, что диск не должен быть узким местом. Я думаю, что время доступа здесь очень важно.

Отключение гиперпоточности также сделало больше, чем вы думали.