junjunk2

Я предпочитаю использовать RHEL-based дистрибутивы

@JohnMcLaren Добавил исправление. Забавно, что Debian портировали последние изменения в довольно старое ядро.

@init_@TTPartizan Ошибки почищены, модуль должен без проблем собираться и работать на ядрах вплоть до 6.1.х Следующие улучшения добавлены: 1. Для матчера в правилах iptables добавлена опция -m isg --active-no-services . Можно использовать в начале цепочки PREROUTING чтобы разрешить трафик без изменений, который не надо по навешанным сервисам отправлять на портал. Например, если вы использовали правило для перенаправления пользователей с отрицательным балансом через присвоенный им сервис REDIRECT: -A PREROUTING -i iif -p tcp -m tcp --dport 80 -m isg --service-name REDIRECT -j DNAT --to-destination 127.0.0.1 то весь трафик всех абонентов проходил правило сравнения на наличие сервисов. Неоптимально, особенно если есть несколько разных сервисов. Теперь можно сделать -A PREROUTING -i iif -p tcp -m tcp --dport 80 -m isg --active-no-services -j ACCEPT -A PREROUTING -i iif -p tcp -m tcp --dport 80 -m isg --service-name REDIRECT -j DNAT --to-destination 127.0.0.1 и основной трафик будет проходить только одно правило, а не проверяться по всем в цепочке. 2. Выведен отдельный каунтер для подсчета сессий, у которых нет аккаунтинга. Обычно это сессии, которые получили Access-Reject и им навесили стандартные сервисы, которые в конфиге. Вывод виден в show_counter 3. Все суммарные каунтеры (которые видны по show_counter) теперь per-cpu - статистика собирается без блокировки сессий 4. spinlock сессии теперь распилен на 2, чтобы шейпер мог считать входящий и исходящий трафик без блокировки. До этого обработка пакета блокировала обработку трафика всей сессии, вне зависимости от направления 5. Шейпер теперь работает с микросекундной точностью, что приводит к меньшим колебаниям скорости у клиентов, но может показывать чуть завышенные значения. Параметры шейпера теперь хранятся в RCU указателе, что позволяет не блокировать сессию на время обновления тарифа. 6. Структуры данных оптимизированы таким образом, чтобы не было split-lock ситауции - ускоряет работу на процессорах с маленьким кэшом. Ну или вообще, если количество сессий огромное. Тестируйте, а я буду поглядывать сюда за коментами

Пофикшено в PR#204

@admf исправил код, теперь должно нормально собираться

По какому идентификатору чистили сессию? Я проверял функционал чистки сессии - у нас было всё ок. Ну и было бы неплохо версию ядра указать, на которой воспроизводится

Подскажите, почему при использовании VRF на свитче S3850G перестает работать DHCP Server и DHCP Relay. конфигурация упрощенно следующая: клиенты в vrf MGMT, DHCP сервер в vrf SERVER. connected маршруты редистрибьютятся между этими vrf с помощью BGP. если статически назначить адреса у клиентов, то IP связность между ними и сервером появляется. Если на vlan интерфейсе в vrf MGMT добавить ip helper-address с указанием адреса DHCP сервера, то на DHCP сервере нет запросов. при этом без VRF всё работает. sh ip dhcp packet stat показывает, что DHCPDISCOVER форвардятся: Message Receive Detail Message From Vlan400 DHCPDISCOVER 405 DHCPREQUEST 0 DHCPDECLINE 0 DHCPRELEASE 0 DHCPINFORM 0 DHCPOFFER 0 DHCPACK 0 DHCPNAK 0 ERROR 0 Message Forward Total DHCPDISCOVER 405 DHCPREQUEST 0 DHCPDECLINE 0 DHCPRELEASE 0 DHCPINFORM 0 DHCPOFFER 0 DHCPACK 0 DHCPNAK 0 ERROR 0

Переписал модуль, избавился от глобального spin_lock - теперь должно масштабироваться намного лучше. Если кто-то может потестировать - был бы признателен. Из известных проблем - при большом количестве одновременно начинающихся сессий ISGd.pl не успевает вычитывать всё из nelink сокета и из-за этого могут сыпаться ошибки ipt_ISG: Lost packet during sending data to listener (err=-11) а так же может не вычитываться весь список сессий. над этим работаю - хочу переписать демона с перла на что-то более быстрое PS. Если кто-то будет обновлять репо - делайте git pull --rebase потому что я иногда у себя делаю rebase. Баги и фиче-реквесты можно пулять в проект в гитхабе

Репозиторий Поддерживаются версии ядра до 5.2 включительно (скорее всего и все более новые, просто не проверял) Восстановил либу для матчера - ее не было в репозитории предыдущего поста Планирую провести серьезную оптимизацию кода - если кому-то будет интересно.

Из сервисов - NAT, ipt_NETFLOW nat events, немного правил в ipset. От Xeon E3-1270v3 отказались в пользу Xeon E5-1650 v2. Сеть на машинах - Intel X520 - 2 порта в LACP, драйвер bonding На Е3 пиковые значения - 12Гбит/с 1.5Mpps, при этом все ядра в 100% нагрузки и начинаются дропы на интерфейсах. На Е5 получилось утилизировать оба порта практически в полку, по графикам 19.5 Гбит/с, 2.2Mpps загрузка 96-98% на всех ядрах, редкие незначительные дропы, но есть увеличение Latency, связанное с упиранием портов в полку по трафику. Ядро Linux 4.1.23, немного подтюнено, драйвер 4.3.15, DCA работает, Flow Director отключен, LRO выпилен на этапе сборки, UDP хэшинг по портам включен, Flow control выключен Эффективность двухпроцессороной системы под сомнением, т.к. контроллер PCI-Ex сейчас находится на процессоре, соответственно при использовании одной карты получается кросс-NUMA передача трафика и не самая эффективня обработка. Если действительно не будет хватать процессора, то лучше рассмотреть вариант с большим количеством ядер в одном package.

Логируем через ipt_NETFLOW. В принципе по нагрузке вообще не видно, если использовать только nat events

Не поднимается LACP с другой стороны тогда, что в принципе логично. Нагрузочное тестирование показало, что трафика в пике получилось протянуть 12,2 Гбит на драйвере teaming против 12.0 Гбит на драйвере bonding, что в принципе можно считать погрешностью измерений. В итоге вернулись назад на bonding из-за того, что не получилось равномерно распределять трафик, всегда был какой-нить перекос по портам

Есть. но что в таком случае делать со стороны свитча?

И в дополнение - не очень хорошо ведет себя этот драйвер в плане нагрузки по сравнению с bonding. Xeon E3 3.5Ггц 9.5 Гбит/с -- teaming: 81% CPU, bonding 73% CPU при прочих равных условиях. Видимо, буду выводить из работы, пока не прооптимизируют балансера. Ну или чуть позже сам посмотрю алгоритм выбора интерфейса и сравню его с bonding. Хотя, как я понял из описания, алгоритм работы драйвера (LACP + HASH ALGO) загружаются в разделяемую память модуля team при создании интерфейса в качестве BPF подпрограммы... поэтому заоптимизировать это дело будет сложно.

Собрал teaming, запустил в работу... Сильно-сильно расстроил момент один - поднять LACP получилось совсем не сразу. Пришлось играться с приоритетами, иначе со стороны свитча порт был suspended. И сейчас так и не смог добиться нормальной балансировки исходящего трафика - на 2х портах перекос 40:60 ... если убрать из алгоритма MAC адреса, то вообще идет только по одному каналу. l3 или l4 - не имеет значения