Настраиваем QOS на Dionis NX


Опубликовано 16.04.2019 19:00 | Автор: Admin

В данной статье рассматривается:
Рассмотрим на примерах, как настроить QOS на Dionis NX с OC v1.2



Не будем переписывать документацию, а просто на примере рассмотрим, как все это работает. Просьба прочитать «39. Механизмы качества обслуживания (QoS)» в документации, чтоб явственней понимать, что тут происходит. Непосредственно не занимаюсь администрированием данного оборудования, просто пришлось покопаться по случаю.

Для прочтения

Попробуем выделить интересующий нас трафик и ограничить его скорость. Так же попробуем проставлять свои метки TOS/DSCP и настроить реакцию на эти метки наш Dionis.

В нашей тестовой конфигурации будет присутствовать:

  • interface ethernet 0 – LAN интерфейс который смотрит в нашу локальную сеть
  • interface ethernet 1 – WAN внешний интерфейс куда смотрят наши каналы, интернет и т.д.

Внимание! Правила применяются только на исходящий трафик с конкретного интерфейса. Т.е. если взять WAN интерфейс, то мы можем влиять только на то, что исходит из него, но не на то что приходит.
Внимание! На данной прошивке служба QOS не работает должным образом, при ее использовании возможны проблемы в работе сети, выражающиеся большими лагами. Если вы заметили, что без видимых на то причин у вас начались потеря пакетов, огромные пинги, тормоза в том или ином направлении, то необходимо проверить данную службу.

К примеру: у нас имеются IP камеры, на которые подключатся кому не лень и тем самым забиваю наш исходящий канал. Попробуем урезать скорость для данного устройства для всех кто сидит за пределами нашей локальной сети.

Настройки производятся в режиме конфигурирования.


ip class-map cm_Camera
match src 10.0.0.16
match dst 10.0.0.16

ip policy-map out_policy
class cm_Camera rate 512kbit

interface ethernet 1
ip policy-group out_policy

Вот такой несложный конфиг урежет исходящею скорость до 512kbit. А теперь пройдемся по тому что мы сделали.

Командой ip class-map cm_Camera мы определили класс с именем cm_Camera. Классы нам нужны для того чтоб на основе правил класса мы могли пометить наш трафик как принадлежащий данному классу. Т.е. решили вы пойти на дискотеку, нарядились. Перед входом вас встречает охрана и проводит фейсконтроль – а подходите ли под данные им инструкции: так ли вы оделись, не пьяные ли вы или вообще со своими размерами влезете ли в дверь и т.д.

  • MATCH – вот как раз описывает эти правила для нашей охраны.
  • match src 10.0.0.16 – говорит, что пакеты с адресом источника 10.0.0.16 будут помечены как члены класса cm_Camera
  • match dst 10.0.0.16 – аналогично , только здесь проверяется адрес получателя. Т.е. в данном случае наша охрана, посмотрев тебя спереди и сзади ставит тебе на лбу метку – наш клиент с указанием под какой группированный список критериев ты подошел т.е. имя класса. При этом считаем, что каждое match это отдельное правило группирующееся по ИЛИ – минимум что-то одно должно соответствовать.
    • Критериев оценки наш не наш в match довольно много, я не буду их описывать

      ip policy-map out_policy – создаем политику обслуживания с именем out_policy. Политика у нас будет одна, для многих классов т.к. на интерфейс можно повесить только одну политику. Данная политика говорит нашим охранникам как мы будем поступать с клиентами имеющие разные метки. Например, VIP гостей мы будем обслуживать в приоритетном порядке, у тек у кого карманы широкие - вторыми, наглых - третьими, все остальные идут общей очередью. И да, существует еще общая очередь, куда помещаются все, кто не прошел по фейсконтролю и для них не определено особое правило обращения.

      class cm_Camera rate 512kbit – здесь мы описываем конкретное правило поведения для пакетов помеченных состоящими в этом классе. Т.е. говорим, что для класса cm_Camera скорость на отдачу не должна превышать 512kbit, но так же мы гарантируем, что при всей загруженности канала мы постараемся выделить полосу в 512kbit

      interface ethernet 1 – переходим в режим конфигурирования ethernet 1 т.е. наш WAN, говорим, что для данного интерфейса мы будем руководствоваться правилами политики out_policy

      • Если что-то надо удалить, то необходимо перед командой ставить no сама_команда
        Пример: no ip policy-map out_policy - удалит нашу политику out_policy
        Удалять надо в обратной последовательности: интерфейс - политика- класс. Это не касается правил в самих политиках, классах
      • Удаление правил из class-map делается по его номеру no 1. где 1 это индекс правила в class-map
      • Удаление правил из policy-map делается по имени класса no class cm_Camera
      • Изменить правило в class-map мы не можем, только удалить и создать новое
      • В policy-map изменить правило мы можем так class cm_Camera новые параметры старое правило замениться нашим новым набором.

      Код с комментариями:
      !Создаем класс cm_Camera
      ip class-map cm_Camera
      !поле источника в пакете должно соответствовать 10.0.0.16
       match src 10.0.0.16
      !поле получателя в пакете должно соответствовать 10.0.0.16
       match dst 10.0.0.16
      !создаем политику с именем out_policy
      ip policy-map out_policy
      !для класса  cm_Camera скорость отдачи может быть максимум 512kbit , но так же мы гарантируем, что при всей загруженности канала мы постараемся выделить полосу в 512kbit
      class cm_Camera rate 512kbit
      !переходим в режим конфигурирования ethernet 1 т.е. наш WAN
      interface ethernet 1
      !говорим, что для данного интерфейса мы будем руководствоваться правилами политики out_policy
      ip policy-group out_policy
      

      Все теперь охрана при работе, клиенты, что прошли фейсконтроль тоже, остальные не очень. )))

      Давайте теперь выделим icmp пакеты, гарантируем им полосу, а еще и пометим. Icmp – это пакеты которые при любом удачном случае мы, да любое промежуточное оборудование будет обижать. Сейчас мы их сделаем почти самыми любимыми для нас и дадим наградную шапку, чтоб и другие знали кто к ним пришел.

      !создаем новый класс icmp
      ip class-map icmp
      !прописываем правило которое определить, что наш пакет это icmp
       match icmp
      !заходим в нашу ранее созданную политику
      ip policy-map out_policy
      !создаем  правило поведения
      class icmp rate 100kbit ceil 1mbit priority 3 tos 0x80
      !указываем наш реальный внешний канал
      bandwidth 10mbit
      

      Т.к. политика у нас уже привязана к интерфейсу, мы не делаем ее повторной привязки.

      И так командой class icmp rate 100kbit ceil 1mbit priority 3 tos 0x80 – мы сказали следующее:
      • class icmp – для какого класса
      • rate 100kbit – какая гарантированная полоса будет выделена под пакеты отмеченные этим классом
      • ceil 1mbit – тут мы говорим, что при всем нашем уважении, но за пределы 1mbit не вылазь.
      • priority 3 – из 8 приоритетов 0-7 тебе достанется третий, чем меньше число тем ты выше, круче и тебя будут все любить. Если не указать данный параметр, то данный класс получит общий приоритет как у всех смертных т.е. 7.
      • tos 0x80 или dscp cs4 – здесь мы в пакете изменяем TOS значение т.е. когда наш гость покинет наш клуб, ему в качестве презента выдадут вип шапку, с помощью которой он может получить, а может и не получить бонусы по всему дальнейшему пути следования.

      Теперь мы будет отлавливать шапочников, но уже с шапками, выданными кем-то другим.

      Шапки у нас могут быть двух разновидностей TOS или DSCP – не углубляясь далеко, это почти одинаковые шапки, но скажем так, с китайскими и российскими размерами. Расшифровка DSCP и TOS значений

      Ну так вот приходит к нам такой шапочник и что нам с ним делать. Мы можем обслужить его по договорённости с тем, кто выдал шапку, а можем и отобрать шапку и пустить его дальше голым или дать свою шапку, вариантов много.

      К примеру, возьмем голосовой трафик IP телефония т.е. пришел к нам клиент с шапкой TOS 0xB8 или же DSCP ef. Т.к. это особая VIP шапка, то мы пожалую ее обслужим как полагается.

      ip class-map VOIP
      match dscp ef
      ip policy-map out_policy
      class VOIP rate 1mbit ceil 1mbit priority 2
      

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

      ip class-map VOIP
      match udp dport 5060
      match udp sport 5060
      

      Вот тут мы уже не смотрим на шапку, а смотрим ему в зубы т.е. делаем вывод на основе порта получателя и отправителя. Если нам надо указать диапазон портов , то пишем так match udp dport 5060 5070 с 5060 по 5070.

      Еще раз хочу напомнить, эти правила в нашем случае будет действовать на трафик, идущий из LAN в WAN. Если трафик будет идти из WAN в LAN, то шапочник пойдет общей очередью с общим обслуживанием, и мы даже шапку не отберем.

      Не допускайте чтоб один и тот же трафик метился разными классами:
      ip class-map icmp
      match icmp
      ------------------------------
      ip class−map prt0
      match tos 0/0xe0
      ---------------------------------
      ip policy-map out_policy
      class prt0 rate 1kbit ceil 10000mbit priority 7 tos 0x00/0xe0
      class icmp rate 1mbit ceil 1mbit priority 3
      

      В данном случае приходящий пакет icmp имеющий метку tos 0x00 будет отнесен либо к классу prt0, либо классу icmp. На выходе будет отрабатывать произвольная политика

      Кратко о порядке действий:

      • 1. Первым делом мы классифицируем трафик с использованием class-map - даем некую внутреннюю метку
      • 2. Дальше в policy-map мы описываем, как мы будем поступать c меченым трафиком.
      • 3. В завершении мы привязываем policy-map к требуемому интерфейсу.

      Посмотреть статистику отбора пакетов
      
      !отобразит статистику отбора пакетов в соответствии с правилами
      show ip class-map *
      
      !очистит набранную статистику
      show ip class-map * zero
      

Метки
Сети QoS Dionis NX

Комментариев: 0

 293 |


Добавить комментарий:
Google
Yandex
Отправить