Динамический шейпер с приоритетом
-
Понимаю, что тема заезженная, но не могу решить такую проблему. Нужно настроить шейпер так, чтобы канал использовался на 100% до тех пор, пока в сети не появляются особые клиенты, после чего соотношение скорости падает - 90% особым клиентам, и 10% - остальным. Читал эту статью https://forum.pfsense.org/index.php?topic=111231.0 практически то, что нужно, только приоритет идет на трафик торрента, а не на пользователя.
-
Доброе.
Исп. лимитер. -
То есть это реализуемо? А то в англоязычной ветке, мне перец сказал, что это никак не реализуется, мол гибкие лимиты не установить.
-
Приветствую :)
Нужно настроить шейпер так, чтобы канал использовался на 100% до тех пор, пока в сети не появляются особые клиенты, после чего соотношение скорости падает - 90% особым клиентам, и 10% - остальным.
Можно реализовать с помощью HFSC-очередей, но только максимум будет только в 80%.
Если известен IP VIP-клиента, то можно:- Создать очередь qVIP, которая будет иметь 79% realtime bandwidth.
- Создать правило Floating, которое будет Match'ить пакеты от одного или нескольких IP VIP-клиентов.
- У остальных очередей realtime bandwidth вообще не указываем, а ставим только Upper Limit.
Таким образом пакеты, маркированные qVIP будут гарантировано иметь 79% канала.
P. S. Есть мнение, что HFSC работают криво и с артифактами. Мой опыт в этом пока мал, но у меня заработало.
Проверял на http и https с 3-х машин. -
Приветствую :)
Нужно настроить шейпер так, чтобы канал использовался на 100% до тех пор, пока в сети не появляются особые клиенты, после чего соотношение скорости падает - 90% особым клиентам, и 10% - остальным.
Можно реализовать с помощью HFSC-очередей, но только максимум будет только в 80%.
Если известен IP VIP-клиента, то можно:- Создать очередь qVIP, которая будет иметь 79% realtime bandwidth.
- Создать правило Floating, которое будет Match'ить пакеты от одного или нескольких IP VIP-клиентов.
- У остальных очередей realtime bandwidth вообще не указываем, а ставим только Upper Limit.
Таким образом пакеты, маркированные qVIP будут гарантировано иметь 79% канала.
P. S. Есть мнение, что HFSC работают криво и с артифактами. Мой опыт в этом пока мал, но у меня заработало.
Проверял на http и https с 3-х машин.Спасибо, попробую так сделать.
-
Спасибо, попробую так сделать.
Вот, что мне помогло понять как оно работает:
- Небольшой пример, который можно адаптировать https://knasys.ru/8-pfsense-%D0%BE%D0%B3%D1%80%D0%B0%D0%BD%D0%B8%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%BA%D0%BE%D1%80%D0%BE%D1%81%D1%82%D0%B8-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D0%B5/
- Тут основные принципы: https://calomel.org/pf_hfsc.html
-
Попробовал настроить так, пока на практике нет возможности проверить, хочется узнать ваше мнение - верная или нет настройка.
queue root_em0 on em0 bandwidth 50Mb priority 0 {qInternet}
queue qInternet on em0 bandwidth 50Mb hfsc( red ecn upperlimit 50Mb ) {qACK, qDefault, qP2P}
queue qACK on em0 bandwidth 10Mb hfsc( red ecn )
queue qDefault on em0 bandwidth 5Mb hfsc( red ecn default )
queue qP2P on em0 bandwidth 2.50Mb hfsc( red ecn upperlimit 2.50Mb )
queue root_em1 on em1 bandwidth 100Mb priority 0 {qLink, qInternet}
queue qLink on em1 bandwidth 20Mb qlimit 500 hfsc( red ecn default )
queue qInternet on em1 bandwidth 50Mb hfsc( red ecn upperlimit 50Mb ) {qACK, qP2P}
queue qACK on em1 bandwidth 10Mb hfsc( red ecn )
queue qP2P on em1 bandwidth 2.50Mb hfsc( red ecn upperlimit 2.50Mb )Не знаю как правильно сюда скопировать конфиг. В общем настроил следующим образом - распихал випы и невипы по пулам, создал в файрволле плавающие правила для каждой группы с соответствующей очередью (qACK для випов, qP2P для обычных. qP2P взял для примера). Для правила qACK параметр real time и 80% от канала, приоритет 7. Для qP2P - параметр upper в 100%, приоритет 5.
-
qACK для випов
Вот именно qACK стоит использовать по назначению, чтобы не путаться, а именно:
ACK-пакеты в TCP-сессии, это подтверждение получателя о полученном пакете, поэтому стоит этой очереди выдать realtime в 20-40% вне зависимости от статуса пользователя.
HFSC-очереди вообще не используют параметр Priority, на него можно не обращать внимания.
Относительно qP2P: тут вопрос как ловить этот трафик, визарды ловят его по диапазону портов, но сейчас торрент-клиенты хитрые, некоторые используют нестандартные порты, вплоть до 443.
Я пока не знаю как грамотно шейпить трафик P2P, поэтому просто отдаю ему оставшийся после шейпинга канал.
Вот очереди, которые я использую в работе с 2 WAN:altq on em3 hfsc bandwidth 19Mb queue { qInternet } queue qInternet on em3 bandwidth 19Mb hfsc ( ecn , linkshare 19Mb , upperlimit 19Mb ) { qACK, qDefault } queue qACK on em3 bandwidth 20% hfsc ( ecn , linkshare 20% ) queue qDefault on em3 bandwidth 10% hfsc ( ecn , default ) altq on em1 hfsc bandwidth 19Mb queue { qInternet } queue qInternet on em1 bandwidth 19Mb hfsc ( ecn , linkshare 19Mb , upperlimit 19Mb ) { qACK, qDefault } queue qACK on em1 bandwidth 20% hfsc ( ecn , linkshare 20% ) queue qDefault on em1 bandwidth 10% hfsc ( ecn , default ) altq on em2 hfsc bandwidth 38Mb queue { qLink, qACK, qMAIL, q1C, qRUK, qLSN, qHTTP-S } queue qLink on em2 bandwidth 2Mb qlimit 500 hfsc ( default , upperlimit 37Mb ) queue qACK on em2 bandwidth 8Mb hfsc ( realtime 8Mb , upperlimit 12Mb ) queue qMAIL on em2 bandwidth 4Mb hfsc ( realtime 4Mb , upperlimit 30Mb ) queue q1C on em2 bandwidth 8Mb hfsc ( realtime 8Mb , upperlimit 12Mb ) queue qRUK on em2 bandwidth 4Kb hfsc ( realtime 2Mb , upperlimit 30Mb ) queue qLSN on em2 bandwidth 4Mb hfsc ( realtime (4Mb, 2000, 2Mb) , upperlimit 30Mb ) queue qHTTP-S on em2 bandwidth 8Mb hfsc ( realtime (4Mb, 2000, 3Mb) , upperlimit 5Mb )
Здесь qRUK и qLSN как раз VIP-пользователи, а em2 - Локальный интерфейс.
Так же есть один нюанс:
если в правилах Firewall->Rules, пакет проходит по всем правилам сверху вниз до первого совпадения, затем выходит из таблицы, то в правилах Floating пакет пройдет по всем правилам, даже если каждое ему подходит (за исключением, если в каком-либо правиле ты поставишь галочку Quick). Таким образом получается разница:- Firewall Rules - частные правила вверху, общие внизу.
- Floating - наоборот. Частные внизу, общие вверху.
Пример моих правил Floating во вложении.
Всё же очень рекомендую ознакомиться с документом: https://calomel.org/pf_hfsc.html, поможет.
-
2 danethz
Думаю не я один, а все сообщество было бы вам весьма признательно за мануал с картинками.
В pfSense, к сожалению отсутствует механизм переноса\импорта конфигурации из вывода терминала, а все, внесенное вне GUI будет перезаписано после перезагрузки. -
Захотел сейчас настроить по примеру, но в прошлый раз видать так нахеревертил, что даже шейпер теперь не удаляется, и очереди тоже, даже не выключаются. Через конфиг бестолку. Приплыли :-\
Проблему с неудаляемым шейпером решил - сделал бэкап, удалил вручную <shaper>…</shaper>.
-
Статьи прочитал, конфиги ваши тоже посмотрел, вроде бы понял. Настроил шейпер таким образом
queue root_em1 on em1 bandwidth 1Gb priority 0 {qLink, qInternet} queue qLink on em1 bandwidth 200Mb qlimit 500 hfsc( red ecn default ) queue qInternet on em1 bandwidth 50Mb hfsc( red ecn upperlimit 50Mb ) {qACK, qVIP} queue qACK on em1 bandwidth 8Mb hfsc( red ecn realtime 8Mb upperlimit 12Mb ) queue qVIP on em1 bandwidth 40Mb hfsc( red ecn realtime 35Mb upperlimit 37Mb )
И правила
match on em0 inet from any to <vip> label "USER_RULE" queue(qVIP, qACK) match on em1 inet from any to <vip> label "USER_RULE" queue(qVIP, qACK)</vip></vip>
Получается вип клиенты при работе будут иметь гарантированно 35 MB/sec, и максимум в 37 MB/sec. Как я понял, для остальных пользователей ни очередь, ни отдельный алиас с правилом в файрволле не нужны.