Перейти к содержимому
Калькуляторы

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

В 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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Если есть два одинаковых класса 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 на двух интерфейсах и первом и втором?

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

Изменено пользователем fet4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата

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

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

 

Цитата

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 поставить.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Изменено пользователем fet4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@fet4 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.