networks Опубликовано 14 апреля, 2009 (изменено) · Жалоба Всем привет. В общем, есть такая система работы с безлимитчиками, на базе 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 надо ставить больше. Извините, если покажется ламерством, просто система то уже запущена, но работает как-то странно. Т.е. я не пойму, то ли она делает, что мне надо, то ли нет :) Может, подскажете? Изменено 14 апреля, 2009 пользователем networks Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 15 апреля, 2009 (изменено) · Жалоба когда мы переходили от трафика на безлимит и было 4 Мбита аплинка на 150-250 активных абонентов тоже выбирал как приоритеты выставить. в итоге пришел к очень хорошей реализации на PF ALTQ с дисциплиной hfsc (другие - не давали такого эффекта). Она очень хорошо работала пока аплинк не поднялся толи до 15 толи до 25 Мегабит, потом просто перестала ужимать "плохих" абонентов при всплеске очереди с высшим приоритетом. сразу начал доработку mpd (тогда ещё только что вышел 4.какой-то) для динамического применения правил принятых от radius-сервера. такая схема работала и по сей день может быть включена если вечером аплинк нагружен на 96-99%. просто всем урезаю скорость на 5-10% от тарифа с 19 до 23 часов (пик нагрузки) в биллинге а радиус раздаёт брас-ам на ACCT-UPDATE пы.сы. а на счет очередей в dummynet мне не удалось заставить работать как требуется, но имхо это возможно, думаю, тогда надо было опыт поболее, может и разобрался бы Изменено 15 апреля, 2009 пользователем Giga-Byte Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
networks Опубликовано 17 апреля, 2009 · Жалоба Giga-Byte: спасибо за ответ :) Все знают про ipfw weight, но молчат, посмеиваясь в бороду? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 17 апреля, 2009 · Жалоба Все знают про ipfw weight, но молчат, посмеиваясь в бороду? :) х/з, всё возможно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LuckySB Опубликовано 17 апреля, 2009 · Жалоба 10 мбит... Сдаеться мне, что жить эта конструкция будет плохо... из-за ошибок в dummynet и нехватки проца. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
