Еще чуть-чуть про ipfw weight

[networks]

Всем привет.

 

В общем, есть такая система работы с безлимитчиками, на базе Freebsd + ipfw.

Сначала все кто подключен по безлимитке (VPN-соединения, интерфейс смотрящий на VPN-серверы - vlanX) идут в правила, которые должны распределять общую пропускную способность Интернет-канала, выделяемую для безлимитчиков, по приоритетам. Кто меньше качает - у того больше приоритет (т.е. ему должно доставаться больше скорости). Правила такого вида:

 

ipfw add 09500 queue tablearg ip from any to table(0) out via vlanX

ipfw add 09600 queue tablearg ip from table(1) to any in via vlanX

 

tablearg формируется исходя из рассчитываемого уровня утилизации безлимитного тарифа для каждого из клиентов. Т.е. если клиент утилизирует менее 10% канала, он попадает в weight 90, если от 10% до 20% - то в weight 80 и т.п. Соответственно создаются queue и pipe:

 

ipfw pipe 20000 config bw 10Mbit/s buckets 1000

ipfw queue 20090 config pipe 20000 mask dst-ip 0xffffffff weight 90 buckets 100

ipfw queue 20080 config pipe 20000 mask dst-ip 0xffffffff weight 80 buckets 100

...

...

ipfw queue 20005 config pipe 20000 mask dst-ip 0xffffffff weight 5 buckets 100

 

И так же для src-ip

 

ipfw pipe 20500 config bw 10Mbit/s buckets 1000

ipfw queue 20590 config pipe 20500 mask src-ip 0xffffffff weight 90 buckets 100

ipfw queue 20580 config pipe 20500 mask src-ip 0xffffffff weight 80 buckets 100

...

...

ipfw queue 20505 config pipe 20500 mask src-ip 0xffffffff weight 5 buckets 100

 

И при коннекте по безлимитке IP-адрес клиента добавляется в table(0) и table(1) с соответствующим tablearg. Допустим, если соединяется кто-то, кто утилизирует канал менее чем на 10%:

 

ipfw table 0 add {ip_address} 20090

ipfw table 1 add {ip_address} 20590

 

Далее идут правила, которые нарезают индивидуальные скорости:

 

ipfw add 9700 pipe tablearg ip from any to table(2) out via vlanX

ipfw add 9800 pipe tablearg ip from table(3) to any in via vlanX

 

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

 

 

Собственно, к чему я все это. Вопросов два:

 

1) Правильно ли располагать нарезку общей скорости по приоритетам ДО нарезки индивидуальных скоростей? Или всё-таки нужно сделать иначе?

 

2) Правильно ли я понимаю, что чем больше значение weight, тем больше будет приоритет? Потому что в мане по ipfw сказано ровным счетом наоборот:

Note that weights are not pri-

orities; a flow with a lower weight is still guaranteed to

get its fraction of the bandwidth even if a flow with a

higher weight is permanently backlogged.

 

Т.е. получается, что flow с более низким weight будет гарантированно получать свою часть bandwith, хотя на форумах везде пишут, что для большего приоритета weight надо ставить больше.

 

 

Извините, если покажется ламерством, просто система то уже запущена, но работает как-то странно. Т.е. я не пойму, то ли она делает, что мне надо, то ли нет :) Может, подскажете?

Edited April 14, 2009 by networks

[Giga-Byte]

когда мы переходили от трафика на безлимит и было 4 Мбита аплинка на 150-250 активных абонентов тоже выбирал как приоритеты выставить.

в итоге пришел к очень хорошей реализации на PF ALTQ с дисциплиной hfsc (другие - не давали такого эффекта).

Она очень хорошо работала пока аплинк не поднялся толи до 15 толи до 25 Мегабит,

потом просто перестала ужимать "плохих" абонентов при всплеске очереди с высшим приоритетом.

сразу начал доработку mpd (тогда ещё только что вышел 4.какой-то) для динамического применения правил принятых от radius-сервера.

такая схема работала и по сей день может быть включена если вечером аплинк нагружен на 96-99%.

просто всем урезаю скорость на 5-10% от тарифа с 19 до 23 часов (пик нагрузки) в биллинге а радиус раздаёт брас-ам на ACCT-UPDATE

 

пы.сы. а на счет очередей в dummynet мне не удалось заставить работать как требуется,

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

Edited April 15, 2009 by Giga-Byte

[networks]

Giga-Byte: спасибо за ответ :)

 

Все знают про ipfw weight, но молчат, посмеиваясь в бороду? :)

[Giga-Byte]

Все знают про ipfw weight, но молчат, посмеиваясь в бороду? :)

х/з, всё возможно

 

[LuckySB]

10 мбит...

Сдаеться мне, что жить эта конструкция будет плохо...

из-за ошибок в dummynet и нехватки проца.