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



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



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



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



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

    Нужно настроить шейпер так, чтобы канал использовался на 100% до тех пор, пока в сети не появляются особые клиенты, после чего соотношение скорости падает - 90% особым клиентам, и 10% - остальным.

    Можно реализовать с помощью HFSC-очередей, но только максимум будет только в 80%.
    Если известен IP VIP-клиента, то можно:

    1. Создать очередь qVIP, которая будет иметь 79% realtime bandwidth.
    2. Создать правило Floating, которое будет Match'ить пакеты от одного или нескольких IP VIP-клиентов.
    3. У остальных очередей realtime bandwidth вообще не указываем, а ставим только Upper Limit.
      Таким образом пакеты, маркированные qVIP будут гарантировано иметь  79% канала.

    P. S. Есть мнение, что HFSC работают криво и с артифактами. Мой опыт в этом пока мал, но у меня заработало.
    Проверял на http и https с 3-х машин.



  • @danethz:

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

    Нужно настроить шейпер так, чтобы канал использовался на 100% до тех пор, пока в сети не появляются особые клиенты, после чего соотношение скорости падает - 90% особым клиентам, и 10% - остальным.

    Можно реализовать с помощью HFSC-очередей, но только максимум будет только в 80%.
    Если известен IP VIP-клиента, то можно:

    1. Создать очередь qVIP, которая будет иметь 79% realtime bandwidth.
    2. Создать правило Floating, которое будет Match'ить пакеты от одного или нескольких IP VIP-клиентов.
    3. У остальных очередей realtime bandwidth вообще не указываем, а ставим только Upper Limit.
      Таким образом пакеты, маркированные qVIP будут гарантировано иметь  79% канала.

    P. S. Есть мнение, что HFSC работают криво и с артифактами. Мой опыт в этом пока мал, но у меня заработало.
    Проверял на http и https с 3-х машин.

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



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

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

    1. Небольшой пример, который можно адаптировать 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/
    2. Тут основные принципы: 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). Таким образом получается разница:

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