Доброго времени суток.
Поставили nDPI в тестовую эксплуатацию. 2 тестовые машины. Прокачиваемый трафик в ЧНН - до 17 GBit / 2.5 Мpps (Вх+исх) на сервер. Третьи сутки - полёт нормальный, в iptables 1 дополнительное правило с -m ndpi --bittorrent с маркировкой, дополнительная нагрузка на CPU в ЧНН 35-40%. Судя по nDPI - торрентов из входящего трафика почти ровно четверть(исходящий не мониторили). Однако есть несколько вопросов и одна проблема:

- Вопросы в следующем - на нашем трафике очевидно преимущество большого bt_hash_size - при малых значениях большая часть нагрузки ndpi - функция hash_ip4p_find, по умолчанию ограничение - 32к исходя из чего оно выбрано? Путем нехитрых манипуляций я его увеличил, однако при размере >64k заполняются только первые 64к элементов. Подскажите в какую сторону копать (какой функцией заполняется хэш) и имеет ли оно смысл?
Сегодня настрою мониторинг количества записей в хэш-таблице и min/max количество в 1 элементе хэша. Если интересно - после выходных выложу результат.

- Проблема в том что после около 2х суток работы не могу выгрузить модуль - после удаления всех правил с -m ndpi и чистки conntrack модуль всё ещё используется:

shaper-3 nDPI # lsmod | grep ndpi
xt_ndpi               464532  2 
nf_conntrack           71572  14 nf_nat_ftp,nf_nat_sip,xt_ndpi,nf_conntrack_proto_gre,ipt_NETFLOW2,nf_conntrack_rtcache,nf_nat,nf_nat_ipv4,nf_nat_pptp,nf_conntrack_netlink,nf_conntrack_ftp,nf_conntrack_sip,nf_conntrack_ipv4,nf_conntrack_pptp

P.P.S. Параметры загрузки на 2 серверах:
options xt_ndpi bt_hash_size=64 bt_hash_timeout=900 - модифицированный и
options xt_ndpi bt_hash_size=16 bt_hash_timeout=900 - оригинальный
Правило iptables:
iptables -t mangle -A FORWARD ! -s 10.0.0.0/8 -d 10.0.0.0/8 -m ndpi --bittorrent -j IPCLASSIFY --addr dst
(IPCLASSIFY - аналог IPMARK из xtables_addons делает то-же что -j CLASSIFY, так-же как IPMARK :))

на счет ограничения в 32k списков - это разумное ограничение для домашнего испольщования. Для большого трафика можно увеличить.

заполняются только первые 64к элементов

Странно. IMHO должны заполняться все, а вот в procfs может быть неправильно отображается.

На счет утечки в счетчиков - была такая бага, но давно и определить когда это происходит так и не удалось.

ipv6 не используется ?

Можно попытаться понять что именно утекло по параметрам в /sys/module/xt_ndpi/parameters/*

flow_created - flow_deleted должно быть 0 после сброса всех правил и conntrack

А какое ядро используется ? С патчем ?

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

Странно. IMHO должны заполняться все, а вот в procfs может быть неправильно отображается.

Ок, проверю, спасибо.

ipv6 не используется ?

Нет

Можно попытаться понять что именно утекло по параметрам в /sys/module/xt_ndpi/parameters/*
flow_created - flow_deleted должно быть 0 после сброса всех правил и conntrack

Принял, еще раз спасибо.

А какое ядро используется ? С патчем ?

3.18.22 - без IMQ

Сорри за оффтоп, а вы я так понимаю средних размеров провайдер

Так оно и есть.

просто очень интересно было бы с вами пообщаться .

Я всегда рад обмену опытом:)

Можете мне на мыло написать или как то чиркануть?

IMQ - это отдельная тема от ndpi

на 3.18 я последние версии не тестировал вообще.

ndpi есть в двух вариантах: без патчей (используется nf_labels) и с патчем. Вариант с патчем более предпочтителен, но требует пересборки ядра и всех модулей, что не всегда возможно.

ndpi есть в двух вариантах: без патчей (используется nf_labels) и с патчем.

Понял, у нас без патчей - с nf_labels.

Вариант с патчем более предпочтителен

А в чём преимущество, кроме доступности connlabel?

требует пересборки ядра и всех модулей

Технически - не проблема(если патч наложется).

А в чём преимущество, кроме доступности connlabel?

Там используется грязный хак для освобождения памяти при удалении conntrack

Может какую-нибудь группу/тему запилим для обмена опыта/общения, тоже провайдер. Есть много непонятных вопросов в управлении трафика и не только?

vel, где-то читал вы Ndpi используете для приоритезации, не поделитесь вашим скриптом шейпера или дайте совет какие дисциплины лучше использовать для этих целей. Заранее спасибо.

Vel, 1.8 будет?

Не совсем понятно а нужен ли 1.8. Там уже 2.0

Мне сейчас нужен ipt_NETFLOW работающий в netns.

Не совсем понятно а нужен ли 1.8. Там уже 2.0

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

Мне сейчас нужен ipt_NETFLOW работающий в netns.

На это есть issue #75 вроде.

про ipt_NETFLOW

У меня есть небольшой опыт по добавлению поддержки netns в ipset.

Там не нужно issue, там нужно выкинуть поддержку того, что не умеет netns ( <= 3.4 ) и переписать весь код. IMHO это должна быть отдельная ветка, т.к. слишком много изменений.

Там 2 беды - весь код использует кучу статических переменных, которые нужно разнести по netns и вторая беда в том, что в ipt_NETFLOW есть куча фич, которые я не использую и не могу понять нафига они нужны ( типа SAMPLER ). Т.е. проверить их работоспособность мне будет тяжело.

Можно попытаться понять что именно утекло по параметрам в /sys/module/xt_ndpi/parameters/*
flow_created - flow_deleted должно быть 0 после сброса всех правил и conntrack

После выходных проверил почти 5 суток: flow_created - 1706718431 flow_deleted - 1701013485 Итого разница 5704946
В пике - 5.5 миллионов записей в хэш таблице

Странно. IMHO должны заполняться все, а вот в procfs может быть неправильно отображается.

Нашел причину, тип переменной key в функции hash_ip4p_add - u_int16_t (сама функция возвращает u_int32_t - в ней всё ок), из-за этого заполняются только первые 64к.
Может чего-то ещё не хватает, но пока не нашел.

PR на гитхабе присылай, чтобы vel'у на это время не тратить ;)

Исправил.

PR на гитхабе присылай, чтобы vel'у на это время не тратить ;)

Исправил.

Не успел - хотел сначала под нагрузкой погонять.:)

$ cat ipt_NETFLOW.{c,h} | wc -l -
6517 -
$ git diff --shortstat HEAD^
 2 files changed, 800 insertions(+), 713 deletions(-)

В минимальной конфигурации уже не падает после загруки модуля, модуль уже выгружается без последствий, flow-данные посылаются в нужный netns. Отдельные sysctl для каждого netns.

Но я еще не проводил нагрузочное тестирование, не проверял кучу опций и сборку менее чем на 4.11 8-[

--enable-nat мне вообще не нравится вообще. Нафига этот гемор с колбеками ? Данные можно извлечь из conntrack.

--enable-sampl и --enable-sampl-hash вообще не могу понять как тестировать.

--enable-aggr - интересная вещь, нужно тестировать

--enable-promisc - нужно тестировать.

--promisc-mpls - нечем тестировать.:(

--enable-snmp-rules - интересная вещь, нужно тестировать

Dota 2

День добрый Вышел патч на Dota 2 и всё опять ушло в битторент :( что-то сменили в протоколе обмена у себя. беда печаль.

выслал Вам дампы на почту - поправьте плиз и поправьте модули определения.

ndpi-netfilter в >1.8

начиная с 1.8 выпилили ndpi-netfilter так я не очень понимаю как тогда шейпить трафик?

Гляну на этой неделе.

-       if(bt_hash_size && bt_hash_size > 32) bt_hash_size = 32;
+       if(bt_hash_size && bt_hash_size > 512) bt_hash_size = 512;

не нужно ли еще добавить это?

Dota 2

День добрый Нашлось время? Поправьте пожалуйста.

На гитхабе тикет создайте а то нет ни старого pcap ни нового.

пока даже не смотрел.

Еще заметил, что если установить хэш больше 128к, то вылетает:

[    2.147633] ------------[ cut here ]------------
[    2.147637] WARNING: CPU: 1 PID: 1180 at mm/page_alloc.c:3532 __alloc_pages_slowpath+0x24c/0xa60
[    2.147638] Modules linked in: ip6_tables ip_tables xt_ndpi(O+) nf_conntrack_netlink nfnetlink ipt_NETFLOW(O) xt_ratelimit(O) nf_conntrack_rtcache nf_conntrack x_tables pptp gre pppox ppp_generic slhc ipoe(O) imq ifb dummy evdev igb(O) 9pnet_virtio intel_rapl_perf atkbd 9pnet e1000e(O)
[    2.147649] CPU: 1 PID: 1180 Comm: modprobe Tainted: G           O    4.9.39+++ #64
[    2.147651]  0000000000000000 ffffffff811cb564 0000000000000000 0000000000000000
[    2.147652]  ffffffff81036f74 00000000024000c0 00000000024040c0 0000000000000000
[    2.147654]  000000000000000b ffff88007a943bb0 ffff88007ab25348 ffffffff810ba78c
[    2.147656] Call Trace:
[    2.147658]  [<ffffffff811cb564>] ? dump_stack+0x5c/0x78
[    2.147660]  [<ffffffff81036f74>] ? __warn+0xb4/0xd0
[    2.147661]  [<ffffffff810ba78c>] ? __alloc_pages_slowpath+0x24c/0xa60
[    2.147663]  [<ffffffff810eed05>] ? __kmalloc+0x15/0xd0
[    2.147664]  [<ffffffff810b9c13>] ? get_page_from_freelist+0x3f3/0x890
[    2.147672]  [<ffffffffa0260e98>] ? node_init+0x38/0x40 [xt_ndpi]
[    2.147678]  [<ffffffffa026140a>] ? ac_automata_add+0x8a/0xd0 [xt_ndpi]
[    2.147679]  [<ffffffff810bb092>] ? __alloc_pages_nodemask+0xf2/0x130
[    2.147681]  [<ffffffff810cfa48>] ? kmalloc_order+0x18/0x50
[    2.147687]  [<ffffffffa0272722>] ? hash_ip4p_init+0x22/0x80 [xt_ndpi]
[    2.147693]  [<ffffffffa0274e33>] ? ndpi_bittorrent_init+0x13/0x50 [xt_ndpi]
[    2.147698]  [<ffffffffa025e42c>] ? ndpi_net_init+0x10c/0x430 [xt_ndpi]
[    2.147700]  [<ffffffff8129b074>] ? ops_init+0x34/0x100
[    2.147702]  [<ffffffff8129b332>] ? register_pernet_operations+0xe2/0x1a0
[    2.147705]  [<ffffffffa021ad89>] ? nf_ct_extend_register+0x59/0x60 [nf_conntrack]
[    2.147706]  [<ffffffffa02ce000>] ? 0xffffffffa02ce000
[    2.147707]  [<ffffffff8129b40f>] ? register_pernet_subsys+0x1f/0x40
[    2.147712]  [<ffffffffa02ce0e8>] ? ndpi_mt_init+0xe8/0x2e4 [xt_ndpi]
[    2.147713]  [<ffffffff810003e2>] ? do_one_initcall+0x32/0x140
[    2.147715]  [<ffffffff810b281f>] ? do_init_module+0x51/0x1c2
[    2.147717]  [<ffffffff81095977>] ? load_module+0x1e67/0x23a0
[    2.147718]  [<ffffffff810930f0>] ? ref_module+0x110/0x110
[    2.147720]  [<ffffffff810fa48b>] ? kernel_read_file+0xfb/0x180
[    2.147721]  [<ffffffff81096062>] ? SYSC_finit_module+0xa2/0xb0
[    2.147722]  [<ffffffff8100128c>] ? do_syscall_64+0x5c/0x220
[    2.147724]  [<ffffffff8134952b>] ? entry_SYSCALL64_slow_path+0x25/0x25
[    2.147725] ---[ end trace 44b1cb019bdebc3c ]---
[    2.147761] xt_ndpi v1.2 ndpi 1.7.0-netfilter-255-dc2faae with IPv6
                bt hash size 256k gc timeout 1800 sec
                sizeof hash_ip4p_node  44
                sizeof id_struct 256
                sizeof flow_struct 912
                 sizeof packet_struct 416
                 sizeof flow_tcp_struct 38
                 sizeof flow_udp_struct 18
                 sizeof int_one_line_struct 4
                sizeof ndpi_ip_addr_t 16
                sizeof ndpi_protocol 4
                sizeof nf_ct_ext_ndpi 40
                sizeof spinlock_t 4
                NF_EXT_ID 10

а там такой код в функции __alloc_pages_slowpath:

        /*
         * In the slowpath, we sanity check order to avoid ever trying to
         * reclaim >= MAX_ORDER areas which will never succeed. Callers may
         * be using allocators in order of preference for an area that is
         * too large.
         */
        if (order >= MAX_ORDER) {
                WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
                return NULL;
        }

Есть ограничения на размер kmalloc :)

Посмотрел.

в csgo_new2 интересного неоказалось, а в csgo_new есть пара характерных признаков. Попробуй обновленный вариант.

Это я понял :)

Где и как его убрать?

Не нужно трогать ядро. Выделение огромного куска памяти - не лучший способ.

Для огромных списков нужно переделывать хеш.

Dota 2

Там еще отсылал dota2 файлы вот они вообще в торрент высыпались.

ЗЫ только ndpi модуль пересобрать? с ядром что нужно делать?

Если не 4.12 - то ядро не нужно трогать.

А про dota2 - я его вчера не заметил. Посмотрю сегодня.

Dota 2

На гитхабе последний комит по ядру неделю назад.

Dota 2

Подожду уже изменения и по доте. Да и пятница :) на боевом серваке что делать нельзя.

Добавил изменения в csgo/dota2

Тем есть достаточно специфичные сигнатуры ( которые пересекались с BT ).

git

Спасибо. но на гите Latest commit f3c77b1 8 days ago или я не туда смотрю?

:( я ошибся репозиторием, когда пушил

f87fffb - последний

На прошлой неделе трохи преболел. Вчера обновил - протестировал - вроде всё гуд. Спасибо.

Выложи pcap на ядиск с дотой актуальный.

а вам зачем? проблему решили. Доту удалил. Жалоб вроде нет.

Ну что за вопрос? Это секретная информация?)

Все, не надо. Племяш приехал, с него записал.

Удалось скомпилить и запустить на тестирование ndpi-netfilter c 2.0-stable

Думаю, что через пару недель будет полноценная версия.

Появилась ветка netfilter2 на базе 2.0-stable

Кто может протестировать?

Оно в тестовом режиме проработало 6 дней. Не упало и память не утекла, но в продакшен ее пока стремно пихать.

Запустил на 1й из машин. Пока всё ок.

Первое что заметил - в новой версии perf top показывает что функция debug_printf в топе (из xt_ndpi) - почти наравне с ndpi_mt, в старой версии в топе была только ndpi_mt, debug_printf было даже не видно. Так и надо или это можно отключить?

Это результат сборки с NDPI_ENABLE_DEBUG_MESSAGES.

В 2.0 что-то сильно переделали в отладке/трассировке.

Но это не главная беда.

Я столкнулся с следующей проблемой - на разных архитектурах и при разной оптимизации.

Пока эта проблема не решена нет смысла делать что-то дальше.