Jump to content
Калькуляторы

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

использую 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 через хэш таблицы?

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

 

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

В данном способе в 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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Если есть два одинаковых класса 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 by fet4

Share this post


Link to post
Share on other sites
19 часов назад, fet4 сказал:

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

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

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

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
Цитата

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

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

 

Цитата

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

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

Share this post


Link to post
Share on other sites
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 в первых двух правилах созданы чтобы классифицировался только внешний трафик, в других двух правилах это уже классификация локального трафика и пиров.

Share this post


Link to post
Share on other sites
4 часа назад, fet4 сказал:

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

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

 

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

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

 

Share this post


Link to post
Share on other sites
2 часа назад, vop сказал:

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

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

Share this post


Link to post
Share on other sites
3 часа назад, fet4 сказал:

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

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

Share this post


Link to post
Share on other sites
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 поставить.

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

Share this post


Link to post
Share on other sites

Это прям магия какая-то :) Впервые слышу что можно классифицировать трафик на физическом интерфейсе который пришел с другого или в 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 by fet4

Share this post


Link to post
Share on other sites

@fet4 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
11 часов назад, kayot сказал:

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

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

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

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

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

 

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
В 3/29/2018 в 16:09, x86 сказал:

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

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

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

Share this post


Link to post
Share on other sites
23 часа назад, ne-vlezay80 сказал:

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

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

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

Share this post


Link to post
Share on other sites
В 21.04.2018 в 02:17, ne-vlezay80 сказал:

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

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

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now