Ограничить суммарную скорость пайпов

[asid2006]

Нужно настроить шейпинг на сервере интернет-провайдера.

ос: centos 6.4

аплинк: 25 мбит

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

Так и сделал. В итоге скорость режется как надо, но когда входящий канал забит, кому-то достаётся больше, кому-то меньше, а надо пропорционально тарифным планам. Как я понимаю, нужно для тарифных пайпов задать корневой пайп, говорящий ipfw сколько всего скорости можно распределять.

 

Подскажите, можно ли это реализовать в ipfw и если нет, чем ещё можно реализовать такую схему.

[SokolovS]

ipfw на centos? Да вы товарищ извращенец! Читай документ под названием LARTC (есть на русском), там найдешь все ответы на вопросы.

[Am1G0]

между тем, ipfw(+dummynet) значительно удобнее tc.

[asid2006]

и удобнее, и умеет баллансировать нагрузку (как минимум между очередями). и не важно что ты качаешь - торренты или файлы, всё-равно скорость режется поровну. с tc я такого когда-то сделать не смог

[andryas]

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

 

 

Лучше создать пайпы для каждого тарифа (на вход и исход отдельно). Пользователей добавлять в соответствующи таблицы.

Список правил будет короткий, нагрузка на процессор заметно уменьшится.

[asid2006]

andryas, так и сделал. Проблема в том, что когда аплинк полностью загружен, скорость клиентам отдаётся не пропорционально тарифному плану. Из мыслей как это побороть есть только создать пайп с шириной канала, равному аплинку, а внутри него "подпайпы" для тарифов. Только вот как это сделать в ipfw и возможно ли это вообще - не знаю.

[kayot]

asid2006

Для этого линуксовый HTB предназначен, с tc/htb подобная задача решается элементарно, в lartc готовые примеры есть.

[andryas]

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

 

Можно, смотрите 2-й пример http://noted.org.ua/773 , суть там изложена, можно также настроить приоритеты.

ipfw следует настроить так, чтобы пакет проходил все правила фаервола, не покидая его после первого же пайпа.

ещё примеры http://www.opennet.ru/base/net/ipfw_bandwidth_balance.txt.html

 

Поищите также в гугле другие примеры реализации QOS посредством ipfw.

Edited August 11, 2013 by andryas

[NiTr0]

и удобнее, и умеет баллансировать нагрузку (как минимум между очередями).

htb, иерархия классов, все внутренние классы ограничиваются внешним...

 

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

Прекрасно все ограничивается. Более того, абону можно даже комфортный серфинг сделать, чтобы когда он качает торренты у него ютубы не лагали.

[adsh]

andryas, так и сделал. Проблема в том, что когда аплинк полностью загружен, скорость клиентам отдаётся не пропорционально тарифному плану. Из мыслей как это побороть есть только создать пайп с шириной канала, равному аплинку, а внутри него "подпайпы" для тарифов. Только вот как это сделать в ipfw и возможно ли это вообще - не знаю.

Найстройте для каждого тарифа очереди внутри пайпа. С приоритетом, пропорциональным тарифному плану. И делайте шейпинг на исходящем интерфейсе.

 

Вот Вам рабочий пример:

 

pipe 100 config bw 8Mbit/s

sched 100 config type WF2Q+

 

queue 100 config weight 20 sched 100 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1

queue 200 config weight 80 sched 100 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1

 

 

add queue 100 ip from any to <clients tarif_1 network> out via em0

add queue 200 ip from any to <clients tarif_2 network> out via em0

 

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

 

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

 

<clients tarif_х network> - сеть или номер таблицы с сетями или IP

 

Скорость будет распределяться пропорционально приоритету - 1:4 (20:80). Для каждого IP будет создаваться своя динамическая очередь (mask dst-ip 0xffffffff).

 

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

 

P.S. При таком алгоритме ограничения gred 0.002/10/30/0.1 клиенты будут просто счастливы - не будет пилы.

Edited August 11, 2013 by adsh

[SokolovS]

По сравнению с классами htb, кувыркание с ipfw выглядит очень странно.

[andryas]

По сравнению с классами htb, кувыркание с ipfw выглядит очень странно.

 

Новое и неизвесное для человека всегда выглядит странно.

[SokolovS]

По сравнению с классами htb, кувыркание с ipfw выглядит очень странно.

 

Новое и неизвесное для человека всегда выглядит странно.

Я бы не сказал что ipfw для меня совсем не известен, просто я как-то ограничивался только построением файрвола с его помощью, мне всегда казалось, что это его основное назначение ;) С использованием tc + htb, строится иерархия классов, каждый родительский класс ограничивает своей суммарной полосой все дочерние, причем при превышении суммы полос всех дочерних классов, нарезка будет пропорциональная. Как я полян человеку именно этого и надо, а конкретного удобного решения на ipfw пока не вижу. Уверен оно конечно же есть, но из за основного назначения ipfw оно будет выглядеть странным ИМХО!

[adsh]

Я бы не сказал что ipfw для меня совсем не известен, просто я как-то ограничивался только построением файрвола с его помощью, мне всегда казалось, что это его основное назначение ;)

А я всегда считал, что для целей шейпинга у него существует лишь вспомогательное назначение - заворачивать трафик в шейпер :).

[SokolovS]

Я бы не сказал что ipfw для меня совсем не известен, просто я как-то ограничивался только построением файрвола с его помощью, мне всегда казалось, что это его основное назначение ;)

А я всегда считал, что для целей шейпинга у него существует лишь вспомогательное назначение - заворачивать трафик в шейпер :).

Ну все так не спорю, у iptables и других вменяемых FW, есть возможность заворачивать трафик. Но только ведь с tc можно построить шейпер не используя FW совсем, там есть очень неплохие фильтры.