imq + nftables

А оно ещё нужно?

Конечно.

Зачем?

Например шейпинг до NAT

А почему не сделать его на двух интерфейсах раздельно?

На uplink интерфейсе с NAT уже не видно серых адресов клиентов

Для этого используется IFB (если я правильно понял Вашу задачу). Я здесь уже писал. А imq, по моему опыту, добавляет латентность и вообще дергано управляет полосой.

Есть еще один нюанс, я классифицирую через ipset (skbinfo), а не фильтрами. А ifb работает до iptables

Это я уж не знаю, как Вы классифицируете (и кстати, как заворачиваете) - Вы нас не посвящали. Я просто предложил Вам решение проблемы, на которую Вы указали:

На uplink интерфейсе с NAT уже не видно серых адресов клиентов

Почему бы и не классифицировать фильтрами. Есть довольно удобный bpf.

redirect ingress с внешнего интерфейса на ifb, не?

А ifb работает до iptables

google://ifb delayed shaping

Если вкратце пропускаешь трафик ДО nat, заворачиваешь его еще раз, маркаешь как тебе надо в iptables, шэйпишь, профит.

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

Если у тебя там РАЗНЫЕ классы трафика используются для КАЖДОГО ip - тогда да, придется. Иначе нет, достаточно по одной метке на класс

РАЗНЫЕ классы трафика используются для КАЖДОГО ip

Именно.

Тогда да, только разными метками, по другому никак. Но ты можешь в принципе вообще обойтись без меток - просто указывая IP - так как он на второй итерации шейпинга будет доступен(где шейпить - до/после NAT - это уже решать тебе).

Метки нужны если как-то IP можно сгруппировать для упрощения шейпинга.

Ты про типа «tc filter add dev eth0 parent ffff: protocol all u32 match u32 0 0 action mirred egress redirect dev ifb0»

Этот iproute2/tc без ящика водки не осилить.

imq в этом отношении не требовал таких извращений. Жаль что его не пропихнули в ядро.

Этот iproute2/tc без ящика водки не осилить.

Да, если нужно сделать что-то посложнее шейпинга ТОЛЬКО транзитного трафика на роутере - приходится дичайше страдать и читать килотонны манулов. Sad but true.

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

Я вот дома вообще забил на эти свистопляски с шейпингом, повесил на интерфейс CAKE и всё.

Дома не шейпю (зачем? пров дает свыше 100, никто из домашних не забивает), а на работе все еще шейпю с помощью imq. Без проблем накладывал на свежие ядра. Работает как часы. latency может и добавляет, но видимо мало, потому как я не замечаю. В ручную правила давно не пишу для tc. Давно уже есть скрипт, аналогично htb.init который гененирует мне все что нужно. И шейпинг при это динамический, а не прибитый гвоздями к каждому ip устройства. Так что поэтому приходиться сидеть на iptables. В прочем пока не вижу смысла на новое и переходить. Работает? Работает.

Увы, у меня ADSL 6 мегабит, не шейпить - не вариант

ADSL 6мбит. В 2019 году. Я сочувствую =]