Тюнинг Suricata на IPS при 2Mpps+

она настроена на режим AF_PACKET с копированием пакетов с одного интерфейса на другой и обратно

Интересно, а оно хотя бы mmap использует ?

Интересно, на сколько будет отличаться вариант с ядерным мостом и NFQUEUE в iptables/forward ?

на скоростях до 1.15Mpps на порт ядро и Suricata пакеты не дропают

Где смотрел ?

На сколько равномерно распределяется нагрузка по ядрам ?

PS Где-то на хабре была интересная статейка про тюнинг для прием 1Мpps в userspace.

PPS c cuda/opencl не пробовал запускать ?

Интересно, а оно хотя бы mmap использует ?

Использует, ессесно, пакеты дальше L3 кеша (куда их через DCA кладет карта) не уходят, насколько я понимаю.

Интересно, на сколько будет отличаться вариант с ядерным мостом и NFQUEUE в iptables/forward ?

Хз, мне NFQUEUE не особо интересен т.к. как роутинговый хоп не хочу сурикату в сеть добавлять, но проверю при случае.

Где смотрел ?

В ethtool и самой сурикате. Кол-во принятых и обработанных сурикатой пакетов равно тому количеству что я отправил через tcpreplay в интерфейс с соседнего хоста, ни одного дропа. Дропать начинает на 1.2Mpps по чуть-чуть.

На сколько равномерно распределяется нагрузка по ядрам ?

Смотря какая нагрузка. Если брать прерывания сетевухи, то они идут на 1 выделенное ядро, ибо несимметричный RSS для сурикаты противопоказан т.к. начинается реордеринг пакетов и прочая беда.

А воркеры сурикаты нагружают свои ядра достаточно равномерно.

PPS c cuda/opencl не пробовал запускать ?

Не, там латенси конский, да и профит не очень большой - до 30%, проще еще сервер поставить или ядер побольше. Для пассивного анализа траффика может еще подойдет, а вот для IPS уже вряд-ли.

Хз, мне NFQUEUE не особо интересен т.к. как роутинговый хоп не хочу сурикату в сеть добавлять, но проверю при случае.

Там нет роутинга! Если включить br_netfilter, то в iptables/forward будут попадать пакеты из бриджа.

Смотря какая нагрузка. Если брать прерывания сетевухи, то они идут на 1 выделенное ядро, ибо несимметричный RSS для сурикаты противопоказан т.к. начинается реордеринг пакетов и прочая беда.

реордеринг пакетов неприятен внутри потока. Если поток обрабатывается на одном ядре то и реордеринга не должно быть. Не может ли пригодиться это? Возможно rps+rfs дадут пользу.

И еще на интеле шаманили с «ethtool rx-flow-hash X flow-type X»

Интересно во время тестирования запустить «perf record — sleep 30». Может какую аномалию покажет.

Не пробовал посмотреть сколько pps ловит без потерь просто анализ потока ( без «форвардинга» )?

Там нет роутинга! Если включить br_netfilter, то в iptables/forward будут попадать пакеты из бриджа.

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

реордеринг пакетов неприятен внутри потока. Если поток обрабатывается на одном ядре то и реордеринга не должно быть. Не может ли пригодиться это? Возможно rps+rfs дадут пользу.

Да, внутри потока. А т.к. хеш RSS несимметричен, то прямое направление потока (src->dst) попадет в один воркер сурикаты, а обратное (dst->src) в другой воркер.

По поводу ссылки не совсем понял что конкретно там может помочь :) RPS+RFS хорошая штука, но опять же в том случае если симметрия не парит.

И еще на интеле шаманили с «ethtool rx-flow-hash X flow-type X»

Это не совсем то, с асимметричностью потоков не поможет бороться насколько я понимаю. Читал какие-то статьи про Random Secret Key и его подстройку для того чтобы RSS становился симметричен (https://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf например), но пока руки не дошли. Проблема то у меня где-то в другом месте.

Интересно во время тестирования запустить «perf record — sleep 30». Может какую аномалию покажет.

Гляну, спс.

Не пробовал посмотреть сколько pps ловит без потерь просто анализ потока ( без «форвардинга» )?

Что интересно форвардинг практически не влияет не дропы, т.к. дропать начинает именно принимающая карта когда 1 ядро на котором висит ее очередь не справляется с обработкой.

Причем интересно, что загрузка ядра этого идет по какой-то интересной кривой, вроде экспоненты. Т.е. при 1.15Mpps нагрузка 10-20%, а при 1.5Mpps (это максимум что я выжал из tcpreplay) упирается в 100% и там дропы уже серьезные.

Да, внутри потока. А т.к. хеш RSS несимметричен, то прямое направление потока (src->dst) попадет в один воркер сурикаты, а обратное (dst->src) в другой воркер.

Если это проблема, то суриката неготова :(

А есть ли вообще «success story» с сурикатой на таких скоростях ?

Т.е. при 1.15Mpps нагрузка 10-20%, а при 1.5Mpps (это максимум что я выжал из tcpreplay) упирается в 100% и там дропы уже серьезные.

tcpreplay - достаточно странная утиль :) Когда-то я пытался ей воспроизводить ранее захваченный трафик, но в конце концов мне пришлось написать свой велосипед через tun/tap.

поднять pps можно распределив трафик на несколько tcpreplay

Если это проблема, то суриката неготова :(

Она готова, но эта ситуация вызывает пересортировку пакетов внутри самой сурикаты чтобы реконструировать флоу, что снижает производительность. Поэтому правильнее сделать симметричный RSS чтобы все пакеты потока попадали в один воркер и обрабатывались последовательно.

А есть ли вообще «success story» с сурикатой на таких скоростях ?

Есть вполне, в т.ч. и на больших скоростях. Есть интересный гайд - https://github.com/pevma/SEPTun - откуда я брал много полезных идей. Но там чисто анализ траффика, а не IPS.

tcpreplay - достаточно странная утиль :) Когда-то я пытался ей воспроизводить ранее захваченный трафик, но в конце концов мне пришлось написать свой велосипед через tun/tap.

Да, в общем, не заметил особых проблем. Но я собирал последний из сорцов. Работает на ура.

Да, несколько реплеев можно запустить, но мне пока не надо т.к. дропы и так идут и на этих скоростях. Да и проблема не в дропах, а в том куда пропадают пакеты при форвардинге...

Есть интересный гайд - https://github.com/pevma/SEPTun

Охренеть!

Я не представляю как через af_packet проходит пакет, но интересно, в дисциплинах оно не может дропаться tc -s qdisc show dev eno49 ?

У меня самопальное минималистичное ядро в котором вся эта ересь выпилена, так что вряд ли.

Есть шанс, конечно, что я в конфиге ядра что то намудрил, проверю потом на стоковом...

Самосборное ядро в данном случае просто необходимо, чтобы выкинуть кучу ненужного хлама.

А ты без CONFIG_NET_SCHED собрал ?

Интересно, а эти потери будут проявлятся если в сурикате сделать минимальный конфиг?

А ты без CONFIG_NET_SCHED собрал ?

# zcat /proc/config.gz | grep CONFIG_NET_SCHED # CONFIG_NET_SCHED is not set

Да, я там вообще оставил по минимуму. Если AF_PACKET заработает нормально на форвардинг, то и netfilter выпилю с корнями.

Интересно, а эти потери будут проявлятся если в сурикате сделать минимальный конфиг?

У нее в плане правил он сейчас достаточно минимальный - две штуки добавил для проверки. Хотя количество правил влияет на ее скорость ни разу не линейно, особенно из-за использования Hyperscan либы. Запускал с кучей стоковых правил (тыщ 30), особых изменений не было.

Я вот думаю для начала вместо сурикаты обычный бридж всандалить и посмотреть будут ли тогда потери...

Форвардинг с помощью бриджа есть смысл проверить. А вдруг и он не тянет такой pps :)

Если суриката отдала пакет, но он так и небыл передан сетевой картой, то дропы могут быть при переполнении очереди (должны быть видны в tc -s qdisc если есть CONFIG_NET_SCHED), либо переполнение буфера сокета, но тогда должна быть -ENOBUF, которую суриката должна учитывать. Размер очереди на передающем интерфейсе никак не влияет ?

А воркеры сурикаты привязаны к ядрам ? Может есть смысл xps включить и привязать их к ядрам с сурикатой? Нет ли где общей блокировки на сокете af_packet в которую все упирается? Теоретически это должно быть видно в perf.

netfilter выпилю с корнями

На af_packet оно не должно влиять. Оставь, может пригодиться, а вот conntrack есть смысл выпилить.

В общем дошли руки, еще потестировал.

Роутинг\бриджинг проверил - достаточно большая нагрузка, т.к. пакеты копируются через netlink в юзерспейс при -j NFQUEUE. Есть memory-mapped netlink, но не уверен что Суриката его юзает.

Плюс непонятно с распределением флоу по воркерам - NFQUEUE поддерживает --queue-balance для раскидывания по Сурикатным тредам, и он вроде бы даже flow-aware, но вот обратные пакеты flow из-за RSS наверное не попадут в тот же тред.

Надо дальше копать, в принципе перспективно.

По AF_PACKET.

1) Похоже Суриката сама дропает внутри себя пакеты по каким-то одной ей понятным правилам. Возможно битые чексуммы или порванные флоу.

Ибо: a) Количество дропов для конкретного PCAP всегда идентично с точностью до пакета

b) При смене copy-mode с ips на tap дропы пропадают, т.к. Суриката перестает вмешиваться в поток и всё сразу хорошо.

Каких-либо настроек это контроллирующих в конфиге не нашел, задал вопрос у них в багтрекере - может посоветуют.

2) Выяснился конский Latency при использовании AF_PACKET - пинги идут по 10-50мс в зависимости от погоды на марсе, iperf-ом в результате больше гигабита сложно получить и то после раскачки TCP-окна.

В роутинге такой хрени нет.

Жаль что mmap netlink начали выпиливать из ядра :( Для memory-mapped netlink (для nfqueue) вроде был бранч в какой-то либе. ИМХО пересобрать сурикату с ней не сложно.

хеш в nfqueue - симметричный L3-only если верить include/net/netfilter/nf_queue.h:nfqueue_hash():hash_v4()

NFQUEUE - это очень интересный вариант с точки зрения распределения трафика по очередям, особенно при наличии какого-нибудь предварительного легкого dpi.

Остается посмотреть на netmap/dpdk для полноты картины.

PS Представляю себе сколько времени уходит на эти эксперименты.

хеш в nfqueue - симметричный L3-only если верить include/net/netfilter/nf_queue.h:nfqueue_hash():hash_v4()

Вот это интересно, спасибо. Коммент /* packets in either direction go into same queue */ внушает надежду :)

В таком случае наверное можно будет оставить RSS включенным, всё равно NFQUEUE перекинет в другой тред. Как это скажется на производительности, правда, непонятно. Интересно, есть ли возможность отправлять пакет в ту очередь\тред на котором пакет приходит по RSS. Возможно надо поиграться с Flow Director или чем-то подобным.

Остается посмотреть на netmap/dpdk для полноты картины.

Да, compat_netmap в dpdk выглядит интересным, но это нужно, похоже, править исходники сурикаты. Это я буду делать в последнюю очередь, хотя там вроде бы минимум изменений.

PS Представляю себе сколько времени уходит на эти эксперименты.

Да не то что бы, это такой факультативный проект :) Мы сейчас юзаем F5 файрволлы, платим за их саппорт >100к баксов в год и вот рассматриваем разные альтернативы... плюс уход от вендор лок ин.

на счет файрвола есть интересная мысль.

мост с фильтрацией может работать с conntrack. С одной стороны - это приличная надстройка, а с другой стороны это ядерный фильтр с простым управлением.

сурикате не нужно через себя форвардить, она должна слушать как ids, а в случае необходимости дропать пакеты досточно либо отметить conntrack меткой по которой iptables будет дропать все в обе стороны либо изменить статус conntack как INVALID с последующим дром всего идущего по этому соедиению. Оба действия доступны из утили conntrack, значит это можно сделать и из сурикаты дописав маленький плагин.

и NFQUEUE при этом не нужен!

Небольшой апдейт.

По вопросу потерь пакетов при бриджинге AF_PACKET авторы ответили что это бай дизайн и дропались некорректные пакеты в модуле stream (скорее всего обрывки сессий, начало которых не вошло в тестовый pcap). Но сделали патч, добавляющий опцию которая сей функционал отключает. Так что теперь ни один пакет не дропается.

В гите его пока нет, применять вручную, подробности тут: https://redmine.openinfosecfoundation.org/issues/2099

По поводу латентности пока ничего не изменилось, пинги через мост идут со средней задержкой в 20мс.

Если понять какой параметр в настройках интерфейса влияет на латентность, то можно будет понять в какую сторону копать.

пинги через мост идут со средней задержкой в 20мс

Это при нагрузке?

Это при нагрузке?

Нет, нагрузка нулевая.

В общем, виновник найден - режим работы AF_PACKET - TPACKET_V3. Он, похоже, экспериментальный. Если откатиться на TPACKET_V2, всё становится идеально:

# ping -f -c 100000 -q 192.168.99.2
PING 192.168.99.2 (192.168.99.2) 56(84) bytes of data.

--- 192.168.99.2 ping statistics ---
100000 packets transmitted, 100000 received, 0% packet loss, time 21970ms
rtt min/avg/max/mdev = 0.081/0.211/0.642/0.029 ms, ipg/ewma 0.219/0.210 ms

Т.е. сейчас все стало замечательно: пакеты даже битые не теряются и задержки допустимые.

Да, получается что так. Но производительность существенно упала, не более ~0.77Mpps теперь без дропов, что на 35% меньше чем с V3. Авторы пишут что по-иному не будет т.к. в режиме V3 пакеты группируются в блоки, что снижает нагрузку и вызывает повышение латентности.

Плюс, насколько я понимаю, в режиме бриджа есть проблема с дефрагментацией IP-пакетов. Когда Suricata собирает фрагменты вместе, результирующий пакет может уже по MTU не влезть в передающий интерфейс. Пока я отключил дефрагментацию, в идеале количество фрагментированных IP-пакетов в сети близко к нулю.