double qos

эксперименты с veth и lo как то не получились

Ну попробуйте ещё с br0.

эт тож самое что и veth

http://www.linuximq.net/

про IMQ я знаю
а стандартным способом ?

про imq не совсем так - шейпить можно только в 2-х местах: prerouting & postrouting. "-j IMQ" не отправляет пакет в очередь, он только отмечает в какую очередь ( устройство) этот пакет отправить.

После этого можно шейпить еще раз в очереди на устройстве (и еще раз если интерфейс типа vlan).

Но, после imq/postrouting нет возможности переклассифицировать траффик.

Дважды можно шейпить (с переклассификацией) через ifb + output, но в ifb классификация трафика может оказаться невозможной (только средства tc filter).

Тут кто-то писал про шейпер через NFQUEUE, вот там можно неограниченное число раз шейпить.

Дважды можно шейпить (с переклассификацией) через ifb + output, но в ifb классификация трафика может оказаться невозможной (только средства tc filter).

да - но после ifb сразу уходит на сетевую - как тут и причем OUTPUT ?

Тут кто-то писал про шейпер через NFQUEUE, вот там можно неограниченное число раз шейпить.

хех - то есть написать юзерспейс приложение которое будет принимать все пакеты - это да - все проблемы решит
но тормаза же будут

да - но после ifb сразу уходит на сетевую - как тут и причем OUTPUT ?

почему ? в ifb загоняем через

tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
  match u32 0 0 flowid 1:1 \
  action mirred egress redirect dev ifb0

и оно шейпится в ifb0, а после этого классифицируем трафик (-j CLASSIFY) и шейпим уже через исходящий интерфейс.

Но это только для транзитного трафика, а с локальным так не прокатит.

проблема в том что это так тока для входящего трафика с внешней сетевой - там да ingress и далее второй раз для уже исходящего трафика на внутренней сетевой

вся проблема в том - что двойной qos могу делать только на исходящем от сервера трафике на локальную сеть

как бы там умудриться сделать мелкую петлю :) ...

мост теоретически имеет 2 очереди - сам мост и физический интерфейс. А если есть br_netfilter, то с повторной классификацией проблем нет.

Тут кто-то писал про шейпер через NFQUEUE

Ага. Вот он, этот шейпер: https://github.com/vmxdev/damper

Мне там кстати в ишшуях какой-то индус спрашивал про шейпинг на 10G. Я сначала мысленно отмахнулся, а потом задумался. Теоретически можно же хватать пакеты каким-нибудь механизмом вроде PACKET_MMAP (до того как пакет попадет в ядро) и пробовать шейпить. Но пока так и не понял, получится ли трафик дропнуть, потом реинъектировать в тот же интерфейс. Или как это вообще лучше сделать?

Может быть попробую покрутить еще netmap, он вроде бы умеет делать такие трюки. А может быть и нет. Надо пробовать, правда щас времени на это вообще нет

а в чем сложность шейпера на 10G
шейпер как шейпер - вопрос в кол-ве проверок

Ну у меня такого оборудования нет, в интернетах пишут что на 10G все не так просто. Ядро может захлебнуться, народ придумывает всякие DPDK, XDP, PACKET_MMAP, netmap и прочее.

В DPDK есть какой-то QoS, вроде netmap тоже что-то такое умеет. Сильно не погружался, немного погуглил и почитал. Может пока искаженная картина в мозгу, надо разбираться

чего там захлебываться
но советуют вместо htb юзать hfsc как не имеющего(?) локов на все ядра
ну и общее хеширование и так далее

Если есть возможность повесить на eth0, то вешаешь на него и на vlan.

Если нету, то QinQ например (подразумевается что трафик приезжает к роутеру одим SVLAN'ом с пачкой клиентов, заменим его для стенда Linux'ом):

linux01:

ip link set eth0 mtu 1504
ip link add q1000 link eth0 type vlan id 1000
ip link add vlan200 link q1000 type vlan id 200
ip link set q1000 up
ip link set vlan200 up
ip a add 10.0.0.1/24 brd 10.0.0.255 dev vlan200

linux02:

ip link set eth0 mtu 1504
ip link add q1000 link eth0 type vlan id 1000
ip link add vlan200 link q1000 type vlan id 200
ip link set q1000 up
ip link set vlan200 up
ip a add 10.0.0.2/24 brd 10.0.0.255 dev vlan200

linux01:

Q1000="q1000"
Q1000_RATE="1000Mbit"
VLAN200="vlan200"
VLAN200_RATE="99Mbit"

tc qdisc del dev $Q1000 root
tc qdisc del dev $VLAN200 root

tc qdisc add dev $Q1000 root handle 1:0 htb r2q 1000 default 11
tc class add dev $Q1000 parent 1:0 classid 1:1 htb rate 1Gbit burst 15k
tc class add dev $Q1000 parent 1:1 classid 1:11 htb rate $Q1000_RATE burst 15k prio 1

tc qdisc add dev $VLAN200 root handle 1:0 htb r2q 100 default 11
tc class add dev $VLAN200 parent 1:0 classid 1:1 htb rate 100Mbit burst 15k
tc class add dev $VLAN200 parent 1:1 classid 1:11 htb rate $VLAN200_RATE burst 15k prio 1

Как вы и хотели - 2 раза, причем в прямом смысле этого слова. Скорость задаваемая на клиентском вилане будет ~ в 2 раза меньше, то есть из заданных 99Mbit, реально получается где-то 55Mbit, то есть деление ~ «на два».

Вполне возможно и на vrf сделать, я не тестил. Посмотрите мой пост на наге может поиграетесь

Удачи.

с netns все с одной стороны упрощается, но появляется лишний роутинг.

в варианте с vlan/bridge не переклассифицировать траффик :(

tc redirect, который уже посоветовали

И еще. Трафик через сервер, именно «проходящий» - значит у него есть интерфейс входа и интерфейс выхода. На каждом из которых может быть по очереди. Через skbedit можно промаркировать только тот трафик прошедший через первый шейпер, который нужно зашейпить позднее(заматчив как обычный промаркированный через iptables).