Linux-роутер, шейпинг и QoS

Но у меня роутер, и вопрос звучит так: почему вместо плясок с перенаправлением ingress'а WAN-интерфейса нельзя повесить шейпинг на egress LAN-интерфейса?

Можно и нужно, вообще-то везде про это и написано. Перенаправление на промежуточный интерфейс при использовании nat используют для исходящего трафика, т.к. на egress wan уже нет локального ip клиента.
PS Вообще перенаправление на промежуточный интерфейс не единственное решение, можно например использовать connmark

Я фигово представляю, что у тебя есть и что ты хочешь получить.

И что ты подразумеваешь под «не мешать»? Тебе нужно задать лимит канала для гостевой сети?

Другими словами, нужно ли делать что-то сверх банального «на корень HTB, на листья fq_codel, трафик с этих IP в один класс, с этих IP в другой», если я ещё не знаю точно, чего я хочу?

С помощью HTB ты можешь, например, заставить трафик из wlan'а «уступать» полосу остальному трафику в случае необходимости (т.е., приоритизировать нужный трафик). Но только в том случае, если все это выходит через один интерфейс.

В OpenWRT когда-то был IMQ, который позволял делать «общий» шейпинг для группы интерфейсов. Сейчас там есть IFB, но, насколько я понял, он такое не может. Поэтому, как вариант, можно поставить жесткое ограничение на скорость гостевой сети.

из wlan'а

в wlan, конечно же

Есть ethernet-интерфейс (свитч), который разделён на несколько VLAN-ов, часть которых объединена в мост с WLAN-интерфейсом. На что из этого нужно вешать qdisc-и?

На те самые непосредственные интерфейсы, с которых будет осуществляться обмен IP-пакетами. То есть, например, в случае бриджа - на br0, а не на входящие в его состав интерфейсы.

Случай когда надо лимитировать отдачу только на определенный физический интерфейс в составе моста - опускаем, для простоты.

Но у меня роутер, и вопрос звучит так: почему вместо плясок с перенаправлением ingress'а WAN-интерфейса нельзя повесить шейпинг на egress LAN-интерфейса?

Если сам роутер полосу пропускания занимать не будет(например торрент-клиентом) - да, можно. Это минимум геморроя.

У меня так не получилось организационно(у меня сервер и шэйпит и торренты качает/раздает), поэтому у меня ад в виде дважды заходящего на ifb-устройство трафика с хитрой маркировкой через iptables.

Так что если тебе не надо на роутер всякую хрень, занимающую канал ставить - тебе будет гораздо легче.

Вообще, в какую сторону следует конфигурить tc, если особых проблем с задержками не наблюдается, а нужно исключительно заставить гостевую WLAN-сеть не мешать основной?

В качестве листьев(leaf qdisc) очень fq_codel советуют, но я его еще даже не пробовал, увы, у меня sfq с flow classifier-ом. Работает худо-бедно, но «интерактивность» трафика при большой загрузке канала страдает(браузить при этом можно без особых проблем).

Другими словами, нужно ли делать что-то сверх банального «на корень HTB, на листья fq_codel, трафик с этих IP в один класс, с этих IP в другой»

Примерно так. У меня правда как я уже сказал вместо fq_codel - sfq. А вместо HTB - HFSC.

насколько я понял, он такое не может

Может. Другое дело что IMQ как бы позволял шейпить входящий трафик без геморроя. С IFB для этого придется поплясать.

Можно и нужно, вообще-то везде про это и написано.

Ну вот там на арчвики написано про «example of ingress traffic shaping with SNAT». Насколько понимаю, речь про ingress WAN-интерфейса.

Перенаправление на промежуточный интерфейс при использовании nat используют для исходящего трафика, т.к. на egress wan уже нет локального ip клиента.

Гм, об этом не подумал.

Вообще перенаправление на промежуточный интерфейс не единственное решение, можно например использовать connmark

Так. Это же решения разных проблем. Промежуточный интерфейс используется, когда нужно шейпить входящий трафик, а пляски вокруг connmark — когда применяется тот или иной NAT?

Я фигово представляю, что у тебя есть и что ты хочешь получить.

Есть: br-lan(eth0.3,wlan0) — LAN, eth0.1 — WAN. Будет ещё wlan1 — гостевой LAN.

И что ты подразумеваешь под «не мешать»? Тебе нужно задать лимит канала для гостевой сети?

«Не мешать» значит, что любой идиот на гостевой LAN (будь то устройство с миллионом исходящих соединений, или же торрент-клиент с NAT traversal, или ещё что-нибудь) не должен никак влиять на устройства в основной сети.

Собственно, один из вопросов в этом и состоит — что, помимо ограничения ширины канала, нужно ещё учесть?

На те самые непосредственные интерфейсы, с которых будет осуществляться обмен IP-пакетами. То есть, например, в случае бриджа - на br0, а не на входящие в его состав интерфейсы.

Гм. Тогда почему у меня по дефолту на физических интерфейсах fq_codel, а на бридже — noqueue? Это баг в инитскриптах OpenWRT?

У меня так не получилось организационно(у меня сервер и шэйпит и торренты качает/раздает), поэтому у меня ад в виде дважды заходящего на ifb-устройство трафика с хитрой маркировкой через iptables.

Да, по ходу, мне это не нужно, но для общего развития — можно на это посмотреть?

На те самые непосредственные интерфейсы, с которых будет осуществляться обмен IP-пакетами. То есть, например, в случае бриджа - на br0, а не на входящие в его состав интерфейсы.

Алсо, в текущей конфигурации на eth0 корнем стоит fq_codel, а на wlan0 — mq. Кто такой mq и как в таком случае настраивать бридж?

а на бридже — noqueue?

Это ж вроде всегда так, не? Там у тебя и ifconfig должен txqueuelen нулевую показать.

Кто такой mq

multiqueue. у тебя что за роутер? не 11ac, случаем?
mq - это поддержка сетевухой нескольких аппаратных очередей.

Сделай лимит трафика на гостевую сеть через sqm-scripts:
https://volatilesystems.org/rate-limited-guest-wlan-on-openwrt.html

Можно, конечно, геморроиться с уводом приоритета всего гостевого трафика в BULK. Но это, ИМХО, профита не даст.

Тогда почему у меня по дефолту на физических интерфейсах fq_codel, а на бридже — noqueue? Это баг в инитскриптах OpenWRT?

Нет, это фича скриптов openwrt. Как я уже говорил - если не надо шейпить отдельные интерфейсы - лучше делать так. В OpenWRT видать считают что так нужно. Имеют полное право.

но для общего развития — можно на это посмотреть?

Примерно так:

iptables -t mangle -vn -L
Chain PREROUTING (policy ACCEPT 14M packets, 6620M bytes)
 pkts bytes target     prot opt in     out     source               destination         
  12M 6333M FROM_INET  all  --  ppp999 *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 1389K packets, 1242M bytes)
 pkts bytes target     prot opt in     out     source               destination         
16075  843K TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x06/0x02 TCPMSS clamp to PMTU
 881K 1212M FROM_INET  all  --  ppp999 *       0.0.0.0/0            0.0.0.0/0           
 506K   29M TO_INET    all  --  *      ppp999  0.0.0.0/0            0.0.0.0/0           

Chain POSTROUTING (policy ACCEPT 15M packets, 11G bytes)
 pkts bytes target     prot opt in     out     source               destination         
  13M 8056M TO_INET    all  --  *      ppp999  0.0.0.0/0            0.0.0.0/0           

Chain FROM_INET (2 references)
 pkts bytes target     prot opt in     out     source               destination         
20055 2200K MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            MARK set 0xb
 4835  670K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 MARK set 0xb
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:22 MARK set 0xb

Chain TO_INET (2 references)
 pkts bytes target     prot opt in     out     source               destination         
 8394  918K MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            MARK set 0x15
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 MARK set 0x15
 6420  780K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:22 MARK set 0x15

Приведены только основные записи, чтобы было примерно понятно о чём речь. Заметь, что маркировка делается дважды.

Идем дальше. В /etc/conf.d/net(гента же) есть следующий кусок:

postup() {
        if [ "${IFACE}" = ppp999 ]; then
                tc qdisc del dev ${IFACE} root &>/dev/null
                tc qdisc add dev ${IFACE} root handle 1: prio
                tc filter add dev ${IFACE} parent 1: prio 10 protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb1

                tc qdisc del dev ${IFACE} ingress &>/dev/null
                tc qdisc add dev ${IFACE} ingress handle ffff:
                tc filter add dev ${IFACE} parent ffff: prio 10 protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

        fi
        if [ "${IFACE}" = tunv6 ]; then
                tc qdisc del dev ${IFACE} root &>/dev/null
                tc qdisc add dev ${IFACE} root handle 1: prio
                tc filter add dev ${IFACE} parent 1: prio 20 protocol ipv6 u32 match u32 0 0 action mirred egress redirect dev ifb1
                # TODO: ingress qdisc may not work for some reason, remove it if problems occur

                tc qdisc del dev ${IFACE} ingress &>/dev/null
                tc qdisc add dev ${IFACE} ingress handle ffff:
                tc filter add dev ${IFACE} parent ffff: prio 20 protocol ipv6 u32 match u32 0 0 action mirred egress redirect dev ifb0
        fi
        if [ "${IFACE}" = br0 -o "${IFACE}" = vlan2 ]; then
                tc qdisc del dev ${IFACE} root &>/dev/null
                tc qdisc add dev ${IFACE} root handle 1: prio
                tc filter add dev ${IFACE} parent 1:0 prio 10 protocol ip handle 100 fw action mirred egress redirect dev ifb0
                tc filter add dev ${IFACE} parent 1:0 prio 20 protocol ipv6 handle 100 fw action mirred egress redirect dev ifb0
        fi
}

ifb0 отвечает за шейпинг входящего трафика, ifb1 - исходящего. Но так как я уже упомянул, что шейпить надо в том числе трафик, входящий на сам роутер, а от IMQ пришлось отказаться - имеем вот такой вот геморрой.

Дальше - веселее :-). Сам шейпер:

# Variables that control script parameters
MAIN_IFACE="ifb0"
OUT_IFACE="ifb1"

BAND="7Mbit"
HIGH_LIMIT="6Mbit"

# Simple shaper for outgoing traffic (device ${OUT_IFACE})
tc qdisc del dev ${OUT_IFACE} root &>/dev/null
tc qdisc add dev ${OUT_IFACE} root handle 1: prio

# add some qdisc to high priority traffic
tc qdisc add dev ${OUT_IFACE} parent 1:1 handle 10: sfq

# Properly marked traffic is high-priority
tc filter add dev ${OUT_IFACE} parent 1:0 prio 1 protocol ip \
handle 21 fw \
flowid 1:1

# Properly marked IPv6 traffic is high-priority
tc filter add dev ${OUT_IFACE} parent 1:0 prio 2 protocol ipv6 \
handle 21 fw \
flowid 1:1

# Other traffic is lowest-priority
tc filter add dev ${OUT_IFACE} parent 1:0 prio 100 protocol ip u32 match u32 0 0 flowid 1:3

# Other traffic(IPv6) is lowest-priority
tc filter add dev ${OUT_IFACE} parent 1:0 prio 200 protocol ipv6 u32 match u32 0 0 flowid 1:3

# Shaper for incoming traffic
tc qdisc del dev ${MAIN_IFACE} root handle 1: hfsc &>/dev/null
tc qdisc add dev ${MAIN_IFACE} root handle 1: hfsc

# Internet traffic (full MAXIMUM speed)
tc class add dev ${MAIN_IFACE} parent 1:0 classid 1:1 hfsc sc rate ${BAND} ul rate ${BAND}
# Dummy subclass for delayed shaping
tc class add dev ${MAIN_IFACE} parent 1:0 classid 1:100 hfsc sc rate 1Gbit ul rate 1Gbit
# Subclasses of Internet traffic
tc class add dev ${MAIN_IFACE} parent 1:1 classid 1:10 hfsc rt umax 1500 dmax 2ms rate 1Mbit ls rate ${HIGH_LIMIT}
tc class add dev ${MAIN_IFACE} parent 1:1 classid 1:11 hfsc ls rate 1Mbit

# SFQ Disciplines traffic with filter based on destination IP (fair use)
# for high-priority traffic
tc qdisc add dev ${MAIN_IFACE} parent 1:10 handle 10: sfq
tc filter add dev ${MAIN_IFACE} parent 10: protocol ip handle 1 flow hash keys nfct-dst divisor 256 baseclass 1:10
# for low-priority traffic
tc qdisc add dev ${MAIN_IFACE} parent 1:11 handle 11: sfq
tc filter add dev ${MAIN_IFACE} parent 11: protocol ip handle 1 flow hash keys nfct-dst divisor 256 baseclass 1:11
# end of SFQ Disciplines

# qdisc for dummy subclass
tc qdisc add dev ${MAIN_IFACE} parent 1:100 handle 100: pfifo limit 1000

# Properly marked traffic is high-priority
tc filter add dev ${MAIN_IFACE} parent 1:0 prio 2 protocol ip \
handle 11 fw \
flowid 1:10

# Properly marked IPv6 traffic is high-priority
tc filter add dev ${MAIN_IFACE} parent 1:0 prio 3 protocol ipv6 \
handle 11 fw \
flowid 1:10

# Not input traffic and not classified valid as FORWARD traffic - it should be low priority
tc filter add dev ${MAIN_IFACE} parent 1:0 prio 90 protocol ip \
handle 100 fw \
flowid 1:11

# Not input IPv6 traffic and not classified valid as FORWARD traffic - it should be low priority
tc filter add dev ${MAIN_IFACE} parent 1:0 prio 100 protocol ipv6 \
handle 200 fw \
flowid 1:11

# Not input traffic, shape it AGAIN later
tc filter add dev ${MAIN_IFACE} parent 1:0 prio 2000 protocol ip u32 \
match u32 0 0 \
flowid 1:100 \
action xt -j MARK --set-mark 100 &>/dev/null

# Not input IPv6 traffic, shape it AGAIN later
tc filter add dev ${MAIN_IFACE} parent 1:0 prio 1000 protocol ipv6 u32 \
match u32 0 0 \
flowid 1:100 \
action xt -j MARK --set-mark 200 &>/dev/null

Когда я это дописывал, я уже сам не верил, что эта сотона заработает

Кусок из ip6tables не привожу - там всё примерно аналогично.

Схема сети следующая:

2 VLAN-а(для проводной сети и wi-fi). vlan1(проводной) включен в мост(br0) - для виртуальных машин и контейнеров. Интернет поступает посредством PPPoE-соединения - ppp999. Поверх него - IPv6-туннель до Hurricane Electric. IPv6 в локалке поднят как на проводном VLAN-е, так и на беспроводном. Шейпить надо, как понимаешь и IPv4 и IPv6.

Там у тебя и ifconfig должен txqueuelen нулевую показать.

Ага.

Это ж вроде всегда так, не?

Ну вот потому в тегах к топику и написано «нуб», что я понятия не имею, как оно должно быть. Пинкбайт вон выше по треду говорит, что qdisc'и нужно именно к мосту прикручивать.

multiqueue. у тебя что за роутер? не 11ac, случаем?

WDR-4300. 11abgn, вроде как.

mq - это поддержка сетевухой нескольких аппаратных очередей.

Круто. Тогда вопрос остаётся в силе — как прицепить шейпинг так, чтобы задействовать эти самые несколько очередей?

как прицепить шейпинг так, чтобы задействовать эти самые несколько очередей?

Задействовать те классы, которые поддерживают шейпирование в несколько очередей. IMQ поддерживает multiqueue, например. Читать надо по каждому отдельному классу. Но это шейпинг на ядрах процессора.

Плюс именно аппаратные очереди на самих сетевухах задействуются как правило только простейшими бесклассовыми дисциплинами. Но я могу ошибаться.

Дальше - веселее :-). Сам шейпер:

Ты б ещё wondershaper выложил)
У OpenWRT сейчас вся эта фигня считается устаревшей и рекомендуют пользоваться sqm-scripts, которые настраиваются примитивным образом в /etc/config/qos без простыни кода.

Увы, мне простые скрипты а-ля htbinit не подходят :-)

А такой ещё вопрос. Если какие-то qdisc'и прицеплены и на бридж, и на сетевуху, то что происходит? Пакет проходит через оба, или через один (какой?), или это неправильная конфигурация и ничего попросту не заработает?

По идее пакет пройдет через оба qdisc. В каком порядке - хз, но если рассудить логически - сначала через qdisc составного устройства(моста), а потом уже через qdisc физического.

Так. Это же решения разных проблем. Промежуточный интерфейс используется, когда нужно шейпить входящий трафик

Да, для случая когда несколько локальных интерфейсов и надо сбалансировать весь поток (забыл этот случай, подумал про домашний роутер). Если локальный интерфейс один или есть возможность полосы жестко разделить между локальными интерфейсами промежуточный интерфейс для входящего трафика не нужен.

а пляски вокруг connmark — когда применяется тот или иной NAT?

Как вариант, но не единственный.

Да, для случая когда несколько локальных интерфейсов и надо сбалансировать весь поток (забыл этот случай, подумал про домашний роутер). Если локальный интерфейс один или есть возможность полосы жестко разделить между локальными интерфейсами промежуточный интерфейс для входящего трафика не нужен.

Ага. Картинка начинает складываться. Т. е. например, в моём текущем юзкейсе (WAN, LAN, guest-LAN), если хочется ограничивать guest-LAN в пропускной способности, но при этом отдавать ему всю полосу в случае полного простоя основной LAN, без ifb на ingress WAN'а не обойтись?

Как вариант, но не единственный.

А как ещё? Мы сейчас ведь говорим о ситуации, когда в вышеописанном юзкейсе в очереди ifb-интерфейса все пакеты будут с dst ip == wan ip, и если я захочу классифицировать их в зависимости от подсети назначения (LAN vs. guest-LAN), мне придётся как-то извращаться, так?

Ага. Картинка начинает складываться. Т. е. например, в моём текущем юзкейсе (WAN, LAN, guest-LAN), если хочется ограничивать guest-LAN в пропускной способности, но при этом отдавать ему всю полосу в случае полного простоя основной LAN, без ifb на ingress WAN'а не обойтись?

Все верно. На всякий случай уточню, для входящего трафика.

А как ещё? Мы сейчас ведь говорим о ситуации, когда в вышеописанном юзкейсе в очереди ifb-интерфейса все пакеты будут с dst ip == wan ip, и если я захочу классифицировать их в зависимости от подсети назначения (LAN vs. guest-LAN), мне придётся как-то извращаться, так?

Не понял, мы сейчас о каком направлении говорим? Я имел ввиду исходящий трафик.