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

так же вчера столкнулся с неработающим l4-redirect в ipset список. Причём на всех ядрах выше кроме 3.14.14. С ошибкой:
# accel-pppd -c /etc/accel-ppp.conf
[2020-07-27 18:16:48.116] accel-ppp version 1.12.0
[2020-07-27 18:16:48.117] open ns (null)
[2020-07-27 18:16:48.132] libnetlink: RTNETLINK answers: Unknown error 4097

Ок. Спасибо. Сейчас всё перепроверю ещё раз, отпишусь.

ipset вообще работает? В ядре была поддержка установлена?

разумеется. В ядре всё собрано модулями. пакет ipset стоит. Было опробовано с заранее созданными списками разного типа хеширования.

на 3,14,14 всё отлично.

для списка hash:ip

Спасибо, Dimka88. Загрузился в  linux-5.4.48-gentoo, переставил из ebuild 9999 предварительно грохнув вручную модули, которые всё таки остались, после удаления accel- средствами emerge.
Всё завелось. Интерфейсы ipoe создаются. l4 в список добавляются.
Видать споткнулся на том, что модули действительно были из старой версии. Почему то посчитал, что при удалении, оно их затирает. А нет. Будет наукой мне. Ещё раз спасибо.
Ещё один вопрос уточнить хотел.
Если я верно понимаю шейпинг строится на интерфейсе ipoe. Т.е. для каждой сессии для каждого ip своя скорость. Если мне нужно на учётку выдать несколько ip и разделить между ними скорость. Я стандартными средствами этого сделать не могу. Только через  скрипты up|down и внешний шейпер?

Пожалуйста. По второму вопросу, если вы через framed route будете делать, то полоса будет общая для этого роута

Коллеги... посоны.....  замечена  одна странность при  срабатывании  vlan_mon
вводные данные:
- в сети работает 3 сервера   (  есть как впу  так  шареды )
- установлен    vlan-timeout=86400  

и когда на них равномерное количество абонентов ранее проблем не наблюдалось
в один день день произошла расбалансировка  абонов по серверам,  и вот на том что меньше абонов наблюдается в логах

error: vlan_mon: netlink error: No buffer space available
после этого  либо частинчно либо полностью  абоны с этого сервера  переподключаются....

При наблюдении за ними...
на одном  50%   на нем такого в логах нет
на втором  сейчас  30%  сейчас в логах такого тоже нет, но  до того как он набрал абонов  так же было
на третем  оставшиеся 20%   и в логах подобное осталось

что бы vlan_mon не срабатывал   попробовал установить vlan-timeout=0

Пока что предположение следующее,   когда  на  сервере к примеру 80%  абон базы, то все ок
Если   на сервере к примеру оставшиеся 20%  или что то около того ... тогда  когда  срабатывает vlan_mon ему становится плохо от  удаления  "пустых" интерфейсов которые   так же  посоздавались когда летели бродкасты.

Кто что думает?

Отлично. Спасибо.

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

Никого же не волнует что влан будет удален +-5 минут например

да,  причем при срабатывании, процы взлетают

А удаление интерфейсов это всегда боль для ядра

если на влане будет висеть адрес который по оспф будет анонсится в ядро - будет боль

А че это они там будет висеть если влан подлежит удалению как некьтвен

Там точно параметров не будет

так vlan_mon удаляет только те которые неактивны

Ребят, а в ситуации с weight, если сессия на одном из accel присутствует, а клиент выполняет повторно Discover, нет вероятности что она подниметься на том где нет сессии ? Там где есть сессия вижу что сразу Offer кидает. Там где нет, полный цикл.