case "$ACTION" in
    add)
    # these interfaces generate hotplug events *after* they are brought up
    case $INTERFACE in
        ppp*|ippp*|isdn*|plip*|lo|irda*|ipsec*

вот

если используется qinq с именем интерфейса eth0. ens192 и тд

то вписать туда eth* или ens*

Благодарю!)

Вообще, это какая то сомнительная фича

Дык plug and pray ) дабы в конфиге работал allow-hotplug

В 9ке вроде тоже работал

Да это давно, я уже не помню с какой верси ...

Но в 10ке проц улетает в полку

Все же наверное баг

Может даже уже пофиксили в новых версиях

Я не тестил

А ядро какой версии?

Смотреть надоть. Скорее что-то поменялось в вызовах...

У меня два сервера на дефолтных  ядрах

👌

У меня на 5.1 самосбор живут

как ты относишься к iscsi?

Да вроде пока нормально. Разве что таргет на винде делать больше не буду )

Не спрашивайте, зачем, но озаботился ограничением скорости dhcp discover пакетов. Всегда считал, что на начальных этапах работы этого протокола используется raw сокеты, который для iptables недостижимы, ввиду более поздних хуков. Какое же было мое удивление, когда я поймал discover именно в iptables и в цепочке input. heх-последовательность в дампе для dhcp message type: discover составляет 35 01 01. Это легко увидеть в wireshark.
Дальше через модуль string ловим, а через limit - насилуем.
Как-то так:
--new-chain DHCP_LIMITER
--flush DHCP_LIMITER
-A INPUT -i bond1.+ -p udp -d 255.255.255.255 --destination-port 67 -m string --algo kmp --hex-string "|35 01 01|" -j DHCP_LIMITER
-A DHCP_LIMITER -m limit --limit 100/sec --limit-burst 3 -j RETURN
-A DHCP_LIMITER -j DROP
Зажал limit - количество starting сессий в accel уменьшилось. Разжал - вернулось в норму.