Шейпинг трафика

Izo_lda · June 8, 2017

использую tc для шейпинга и пытаюсь настроить через хэш таблицы

download поток нормально загоняется для каждого адреса в свою таблицу а upload все равно продолжает идти через таблицу по умолчанию 800::

если upload резать через таблицу по умолчанию 800:: при достижении ~ более 500 отдельных сетевых адресов начинаются затыки в сети

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

пример рабочего кода с ограничением при upload через таблицу по умолчанию 800::

rmmod ifb
modprobe ifb numifbs=1
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 9
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000MBit ceil 1000MBit
tc class add dev eth0 parent 1:1 classid 1:9 htb rate 1000MBit ceil 1000MBit
tc qdisc add dev eth0 parent 1:9 handle 9: sfq perturb 10

ip link set dev ifb0 up
tc qdisc del dev ifb0 root
tc qdisc del dev ifb0 ingress
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0
tc qdisc add dev ifb0 root handle 1: htb default 9
tc class add dev ifb0 parent 1: classid 1:1 htb rate 1000MBit ceil 1000MBit
tc class add dev ifb0 parent 1:1 classid 1:9 htb rate 1000MBit ceil 1000MBit
tc qdisc add dev ifb0 parent 1:9 handle 9: sfq perturb 10

tc filter add dev eth0 parent 1:0 handle 20: protocol ip u32 divisor 256
tc filter add dev eth0 parent 1:0 protocol ip u32 ht 800:: match ip dst 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 20:

tc filter add dev ifb0 parent 1:0 handle 20: protocol ip u32 divisor 256
tc filter add dev ifb0 parent 1:0 protocol ip u32 ht 800:: match ip src 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 20:

tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10Mbit ceil 10Mbit
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 20:15: match ip dst 192.168.0.21/32 flowid 1:10
tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 10Mbit ceil 10Mbit
tc qdisc add dev ifb0 parent 1:10 handle 10: sfq perturb 10
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 800:: match ip src 192.168.0.21/32 flowid 1:10

при upload через отдельную таблицу все равно поток идет через таблицу по умолчанию 800::

...
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 20:15: match ip src 192.168.0.21/32 flowid 1:10

возможно я что то не так формирую в хэш таблицу или оно просто и не должно работать в ifb через хэш таблицы?

taf_321 · June 8, 2017

Хэшам интерфейсы безразличны.

https://www.altlinux.org/%D0%A8%D0%B5%D0%B9%D0%BF%D0%B5%D1%80%D0%94%D0%BB%D1%8F%D0%91%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85%D0%A1%D0%B5%D1%82%D0%B5%D0%B9

и про дружбомагию хэшей можно забыть.

photon · June 8, 2017

Я реализовал это дело без псевдоустройств, с помощью полисинга входящего трафика и шейпинга исходящего: https://sourceforge.net/projects/sc-tool . Если используются только IPv4-адреса, то ipset и iptables из ссылки в предыдущем посте не нужны, все делается правилами tc и поэтому работает быстрее. Да и IPv6 вообще говоря можно точно так же побайтово хэшировать, просто это никому не надо.

Edited June 8, 2017 by photon

bomberman · June 9, 2017

А ещё есть ipt_ratelimit, с CIDR и ipv6. Но правда это полисинг.

Izo_lda · June 9, 2017

Хэшам интерфейсы безразличны.

https://www.altlinux.org/%D0%A8%D0%B5%D0%B9%D0%BF%D0%B5%D1%80%D0%94%D0%BB%D1%8F%D0%91%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85%D0%A1%D0%B5%D1%82%D0%B5%D0%B9

и про дружбомагию хэшей можно забыть.

спасибо, попробую такой вариант

vop · June 9, 2017

Хэшам интерфейсы безразличны.

https://www.altlinux.org/%D0%A8%D0%B5%D0%B9%D0%BF%D0%B5%D1%80%D0%94%D0%BB%D1%8F%D0%91%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85%D0%A1%D0%B5%D1%82%D0%B5%D0%B9

и про дружбомагию хэшей можно забыть.

спасибо, попробую такой вариант

Пока это самый удобный вариант, как по мне.

fet4 · January 16, 2018

В 08.06.2017 в 17:17, taf_321 сказал:

https://www.altlinux.org/ШейперДляБольшихСетей

В данном способе в ipset заносятся ip адреса с одинаковым классом

add shaper4 172.16.1.10/32 skbprio 1:d
add shaper4 172.16.1.12/32 skbprio 1:d
add shaper4 172.16.1.14/32 skbprio 1:d
add shaper4 172.16.1.31/32 skbprio 1:d

Разве эти Ip не будут делить скорость между собой в пределах одного класса?

Насколько я понял это классы тарифов

class add dev bondINT parent 1: classid 1:d est 1sec 8sec hfsc sc umax 1500b dmax 5ms rate 20480kbit ul rate 20480kbit
qdisc add dev bondINT parent 1:d handle d: pfifo limit 200
class add dev bondEXT parent 1: classid 1:d est 1sec 8sec hfsc sc umax 1500b dmax 5ms rate 20480kbit ul rate 20480kbit
qdisc add dev bondEXT parent 1:d handle d: pfifo limit 200

Или я ошибаюсь?

vop · January 16, 2018

Да, будут делить. Я так понимаю, что эти адреса принадлежат одному "клиенту".

fet4 · January 16, 2018

Еще такой вопрос.

Если есть два одинаковых класса 1:d на двух разных интерфейсах.

add shaper4 172.16.1.10/32 skbprio 1:d

Классифицируя на этих интерфейсах

-o bondEXT -j SET --map-set shaper4 src --map-prio
-o bondINT -j SET --map-set shaper4 dst --map-prio

Он попадет в класс 1:d на двух интерфейсах и первом и втором?

Или нужно разделять нумерацию классов для входящего и исходящего трафика?

Edited January 16, 2018 by fet4

taf_321 · January 17, 2018

19 часов назад, fet4 сказал:

Разве эти Ip не будут делить скорость между собой в пределах одного класса?

Да, будут делить, ибо так и задумано (как правильно сказали выше, эти адреса принадлежат одному и тому же клиенту)

19 часов назад, fet4 сказал:

Насколько я понял это классы тарифов

Да, это мы уже конкретно прописываем классы и скорости на конкретных интерфейсах. То, что прописывается два раза на разных интерфейсах это просто для задания скорости на входящий и исходящий трафик.

9 часов назад, fet4 сказал:

Он попадет в класс 1:d на двух интерфейсах и первом и втором?

Или нужно разделять нумерацию классов для входящего и исходящего трафика?

Разделять не обязательно. 1:d на bondINT это не то же самое что 1:d на bondEXT и им даже можно назначать разные скорости.

Просто для справки, в примере интерфейс bondINT смотрит в сторону клиентов, и на этом интерфейсе мы задаем скорости в сторону клиента трафика (мы ведь помним, что нормально шейпить можно только исходящий с интерфейса трафик? Именно по этой причине в правилах iptables указаны опции -o), для задания скорости исходящего от клиентов в мир трафика мы прописываем классы на смотрящем в мир интерфейсе bondEXT.

fet4 · January 17, 2018

Цитата

Разделять не обязательно. 1:d на bondINT это не то же самое что 1:d на bondEXT и им даже можно назначать разные скорости.

Или проще сказать - классов с одинаковыми дескрипторами на разных интерфейсах может быть сколько угодно и трафик попадет в эти классы если он классифицирован?

Цитата

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

Это да помним! По этой причине я использую ifb для редиректа на него входящего в интерфейс трафика, по этой причине я не смогу классифицировать в iptables этот трафик(входящий) с помощью -o т.к. это происходит до iptables? Придется использовать tc filter?

taf_321 · January 17, 2018

1 час назад, fet4 сказал:

Или проще сказать - классов с одинаковыми дескрипторами на разных интерфейсах может быть сколько угодно и трафик попадет в эти классы если он классифицирован?

Коряво, но можно и так сказать.

1 час назад, fet4 сказал:

Это да помним! По этой причине я использую ifb для редиректа на него входящего в интерфейс трафика, по этой причине я не смогу классифицировать в iptables этот трафик(входящий) с помощью -o т.к. это происходит до iptables? Придется использовать tc filter?

Вот, кстати, с -o я чуток соврал. кусок дампа с рабочего браса, параметр -o не обязателен:

-A POSTROUTING -m set ! --match-set localnet4 src -j SET --map-set shaper4 dst --map-prio
-A POSTROUTING -m set ! --match-set localnet4 dst -j SET --map-set shaper4 src --map-prio
-A POSTROUTING -m set --match-set localnet4 src -j SET --map-set local-skb4 dst --map-prio
-A POSTROUTING -m set --match-set localnet4 dst -j SET --map-set local-skb4 src --map-prio

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

vop · January 17, 2018

4 часа назад, fet4 сказал:

Это да помним! По этой причине я использую ifb для редиректа на него входящего в интерфейс трафика, по этой причине я не смогу классифицировать в iptables этот трафик(входящий) с помощью -o т.к. это происходит до iptables? Придется использовать tc filter?

Этого делать не надо (ifb). Трафик нормально классифицируется при входе (с внутреннего интерфейса), а шейпится на выходе. Я классифицирую в цепочках:

-t mangle -A FORWARD -i int ...

-t mangle -A FORWARD -o int ...

fet4 · January 17, 2018

2 часа назад, vop сказал:

Этого делать не надо (ifb). Трафик нормально классифицируется при входе (с внутреннего интерфейса), а шейпится на выходе. Я классифицирую в цепочках:

А если этих внутренних интерфейсов тьма, а нужно построить единое дерево классов? По идее все манипуляции нужно проводит с аплинк интерфейсом у которого исходящий трафик шейпится, а вход заворачивается на ifb или полисится.

vop · January 17, 2018

3 часа назад, fet4 сказал:

А если этих внутренних интерфейсов тьма, а нужно построить единое дерево классов? По идее все манипуляции нужно проводит с аплинк интерфейсом у которого исходящий трафик шейпится, а вход заворачивается на ifb или полисится.

А, ну да, если надо один корень для всех интерфейсов, а это надо, если используется ceil правило, то да, тогда можно и ifb поставить.

taf_321 · January 18, 2018

11 часов назад, fet4 сказал:

А если этих внутренних интерфейсов тьма, а нужно построить единое дерево классов? По идее все манипуляции нужно проводит с аплинк интерфейсом у которого исходящий трафик шейпится, а вход заворачивается на ifb или полисится.

Не обязательно. Если проклассифицировать трафик через iptables, то потом можно просто вешать классы на физические интерфейсы, и трафик будет шейпиться, если он даже проходит внутри ppp-соединения или vlan'а.

Пример с боевого браса:

class add dev bondDOWN parent 1: classid 1:e est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 60000kbit ul rate 60000kbit
qdisc add dev bondDOWN parent 1:e handle e: pfifo limit 100
class add dev bondUP parent 1: classid 1:e est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 60000kbit ul rate 60000kbit
qdisc add dev bondUP parent 1:e handle e: pfifo limit 100

bondUP смотрит в сторону пограничника, bondDOWN смотрит в сторону клиентов, клиенты висят на pppoe. При этом на bondDOWN создано почти пять сотен vlan-интерфейсов, уже на которые производится подключение клиентов по pppoe. Но для всех клиентов классы навешиваются всего на два интерфейса, и мне ортогонально какой у клиента сейчас и потом будет ppp-интерфейс и через какой vlan он подключился.

7 часов назад, vop сказал:

А, ну да, если надо один корень для всех интерфейсов, а это надо, если используется ceil правило, то да, тогда можно и ifb поставить.

Это нужно только в одном случае, если скорость на входящий-исходящий суммируется, а не отдельная на каждое направление.

fet4 · January 18, 2018

Это прям магия какая-то :) Впервые слышу что можно классифицировать трафик на физическом интерфейсе который пришел с другого или в iptables там уже это опускается. Если так и есть то это было супер и упростило бы жизнь мне.

Вы все классифицируете в iptables?

А можно Ваши

tc -s -d -g class show dev bondDOWN

tc -s -d -g class show dev bondUP

tc -s -d -g qdisc show dev bondDOWN

tc -s -d -g qdisc show dev bondUP

iptables-save

ipset list

Для понимания картины в целом.

Заранее спасибо.

Edited January 18, 2018 by fet4

kayot · January 18, 2018

@fet4

А почему нет? Это не будет работать только для pptp, а для влан-интерфейсов и даже pppoe работает, трафик же в сыром виде на родительском интерфейсе бегает.

Я так шейплю на IPOE-БРАСе с кучей qinq вланов.

fet4 · January 18, 2018

А в случае если родительский/физический инт. один, входящий трафик все равно придется заворачивать на ifb для шейпинга?

taf_321 · January 19, 2018

11 часов назад, kayot сказал:

А почему нет? Это не будет работать только для pptp,

Чем интерфейс ppp у pptp туннеля отличается от такого же интерфейса у pppoe? Все дело в том, что при классификации через iptables + ipset заполняется skb->prio у пакета, шедулер заглядывает в это поле у каждого отправляемого через интерфейс пакета. "tc filter" делает то же самое, но своими методами.

10 часов назад, fet4 сказал:

А в случае если родительский/физический инт. один, входящий трафик все равно придется заворачивать на ifb для шейпинга?

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

dendj · March 26, 2018

здравствуйте, помогите с ifb

при заворачивании трафика, iptables не маркирует пакеты

iptables -t mangle -A POSTROUTING -o ifb1 -j SET --map-set shaper4 src --map-prio

ps источник вдохновения https://www.altlinux.org/ШейперДляБольшихСетей

x86 · March 29, 2018

iptables не работает с ifb.

Используйте tc.

ne-vlezay80 · April 20, 2018

В 3/29/2018 в 16:09, x86 сказал:

iptables не работает с ifb.

Используйте tc.

А как через tc анализировать трафик на 7-мом уровне модели OSI?

Ivan_83 · April 21, 2018

23 часа назад, ne-vlezay80 сказал:

А как через tc анализировать трафик на 7-мом уровне модели OSI?

Модель OSI - это фантазия телефонистов, в мире есть tcp/ip.

OSI ложится на это своими уровнями с 1 по 4, дальше всё ломается к чертям как минимум в половине случаев.

x86 · April 24, 2018

В 21.04.2018 в 02:17, ne-vlezay80 сказал:

А как через tc анализировать трафик на 7-мом уровне модели OSI?

Простой ответ - никак.

Сложный - используйте u32, но это все-равно не даст всех возможностей iptables.

Sign In

Шейпинг трафика

Recommended Posts

Izo_lda

taf_321

photon

bomberman

Izo_lda

vop

fet4

vop

fet4

taf_321

fet4

taf_321

vop

fet4

vop

taf_321

fet4

kayot

fet4

taf_321

dendj

x86

ne-vlezay80

Ivan_83

x86

Join the conversation