Динамический шейпер с приоритетом

jam-s

Понимаю, что тема заезженная, но не могу решить такую проблему. Нужно настроить шейпер так, чтобы канал использовался на 100% до тех пор, пока в сети не появляются особые клиенты, после чего соотношение скорости падает - 90% особым клиентам, и 10% - остальным. Читал эту статью https://forum.pfsense.org/index.php?topic=111231.0 практически то, что нужно, только приоритет идет на трафик торрента, а не на пользователя.

werter

Доброе.
Исп. лимитер.

jam-s

То есть это реализуемо? А то в англоязычной ветке, мне перец сказал, что это никак не реализуется, мол гибкие лимиты не установить.

danethz

Приветствую :)

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

jam-s

@danethz:

Приветствую :)

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

Спасибо, попробую так сделать.

danethz

Спасибо, попробую так сделать.

Вот, что мне помогло понять как оно работает:

Небольшой пример, который можно адаптировать 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

jam-s

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

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.

danethz

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, поможет.

Floating.jpg_thumb

pigbrother

2 danethz

Думаю не я один, а все сообщество было бы вам весьма признательно за мануал с картинками.
В pfSense, к сожалению отсутствует механизм переноса\импорта конфигурации из вывода терминала, а все, внесенное вне GUI будет перезаписано после перезагрузки.

jam-s

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

Проблему с неудаляемым шейпером решил - сделал бэкап, удалил вручную <shaper>…</shaper>.

jam-s

Статьи прочитал, конфиги ваши тоже посмотрел, вроде бы понял. Настроил шейпер таким образом

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