Классификация пакетов на уровне доступа

    Попробую продолжить начатую мной тему методологии и алгоритма функционирования QoS в Cisco. В этой статье будет описано по каким принципам можно разделить и маркировать трафик на 2-3 уровнях модели OSI на пошаговых примерах. Кому интересен данный вопрос прошу под кат.

    В предыдущей статье я описывал Modular QoS CLI и приводил в пример блок-схему функционирования алгоритма QoS Cisco, в конце статьи мы будем возвращаться в данной блок схеме. Для того, чтобы быть эффективным QoS должен быть внедрен на всей сети. Лучше всего классифицировать трафик по принципу «чем скорее, тем лучше», т.е. в нашем случае на уровне доступа. Фреймы и пакеты следует маркировать используя следующие принципы:

    — Уровень 2 (CoS)
    — Уровень 3 (IP Precedence/Differentiated Services Code Point)


    CoS — выставляет приоритеты от 0 до 7. Если граничное устройство (IP телефон или приложение) умеет выставлять биты, то планировщик сети должен решить «доверять» данному устройству или нет.

    image

    Действие свитча по умолчанию:
    Не доверять граничному устройству, на всех фреймах попавших на свич, будут сброшены приоритеты на 0.
    Если граничному устройство разрешается доверять, то свитч необходимо «предупредить» о неприкосновенности данного бита.

    В зависимости от модели свитча, сначала может понадобиться включить QoS — это делается командой mls qos. Дальше на интерфейсе указывается доверительное отношение к CoS, и политика применяемая к пакету, если тот пришел без соответствующего бита. В итоге получаем:

    switch(config)# mls qos
    switch(config-if)# mls qos trust cos
    switch(config-if)# mls qos cos default-cos

    Также если мы хотим чтобы свитч игнорировал присутствующий бит CoS в пакете — необходимо воспользоваться следующим сочетанием команд, в результате будет использован QoS по умолчанию:

    switch(config)# mls qos
    switch(config-if)# mls qos cos override
    switch(config-if)# mls qos cos default-cos


    Не всегда возможно распознать значение CoS пакета, так как не всегда устройства включены напрямую в свитч уровня доступа, часто случается, что клиент бывает воткнут в простейший неуправляемый свитч, которому не известно понятие приоритетов, к сожалению мы не сможем воспользоваться IP ACL, т.к. мы не уверены в постоянстве IP адреса клиента, здесь нам придется использовать MAC ACL, примерно это будет выглядеть вот так.
    Определяем поток трафика, class-map используется для определения потока трафика как класса сервиса, в данном случае класс сервиса мы назвали ipphone:

    switch(config)# class-map match-all ipphone
    switch(config-cmap)# match access-group name officephone
    Создаем критерии условия:
    switch(config)# mac access-list extended officephone
    switch(config-ext-macl)# permit host 000.0a00.0111 any


    Проверить созданное мы сможем при помощи команды: show class-map

    Продолжаем конфигурировать наше правило, следующим шагом мы определяем функции QoS в политике, назначая значение DSCP для существующего класса:

    switch(config)# policy-map inbound-accesslayer
    switch(config-pmap)# class ipphone
    switch(config-pmap-c)# set ip dscp 40


    Проверить результаты мы можем командой: show policy-map

    Ниже я хочу привести сводную таблицу сопоставления значений нашего «волшебного поля» для разного типа определителей.
    image

    image

    На данном этапе остается последнее действие применение политики на интерфейс в нашем случае мы применим эту политику на все порты нашего свитча одновременно:

    switch(config)# interface range fa 0/1-24
    switch(config-if-range)# service-policy input inbound-accesslayer

    И как обычно проверяем наш результат, к примеру на первом порту: show mls qos interface fa 0/1
    Как всегда обобщаем наши действия в конце, если Вы обращали внимание на предыдущую мою статью, то не могли забыть о блок-схеме связей в политиках QoS, можно проследить указанные ниже команды по данной блок-схеме.

    switch(config)# interface range fa 0/1-24
    switch(config-if-range)# service-policy input inbound-accesslayer
    switch(config)# policy-map inbound-accesslayer
    switch(config-pmap)# class ipphone
    switch(config-pmap-c)# set ip dscp 40
    switch(config)# class-map match-all ipphone
    switch(config-cmap)# match access-group name officephone
    switch(config)# mac access-list extended officephone
    switch(config-ext-macl)# permit host 000.0a00.0111 any

    Теперь рассмотрим несколько другой вариант применения такого рода классификаторов для пакетов. Данный вид основывается на определении протокола на третьем уровне, но не без помощи того же ACL.
    Рассмотрим пример предотвращения загрузки канала трафиком FTP, в Вашем случае — это может быть что угодно, хоть диапазон портов. Мы будем маркировать пакеты нулевым значением, что превратит эти пакеты, в пакеты с наименьшим приоритетом, и по технологии IP precedence и по DSCP.

    В данном случае это будет выглядеть примерно так;
    Утверждаем заранее запланированную политику трафика на группу интерфейсов:
    switch(config)#interface range fa 0/1-24
    switch (config-if-range)# service-policy input inbound-accesslayer


    Определяем функции QoS в политике, в данном случае она будет заключаться в добавлении значения 0 в ячейку dscp, ip пакета.
    switch(config)#policy-map inbound-accesslayer
    switch(config-pmap)# class reduceservice
    switch(config-pmap-c)#set ip dscp 0

    Определяем поток трафика:
    switch(config)#class-map reduceservice
    switch(config-cmap)# match acces-group 100


    И последнее условие, необходимое для исполнение всего вышеописанного:
    switch(config)#ip access-list extended 100
    switch(config-ext-nacl)# permit tcp any any eq ftp


    В завершении статьи хочу еще раз напомнить о блок схеме, которая была показана в предыдущей статье, если Вы пишите политики QoS, то держите ее перед глазами, она поможет Вам очень легко с ориентироваться и никогда не запутаться в момент составления правил.
    Спасибо за внимание.

    P.S. По совету IlyaPodkopaev добавляю немного информации о понятиях trust и dscp-mutation
    qos trust — В контексте настройки интерфейса эта команда используется для включения доверенного состояния каждого порта.
    qos dscp-mutation — Применяет карту изменений DSCP для доверенного порта DSCP системы (всегда перезаписывает DSCP для этого порта).
    Чаще всего последняя команда используется если два домена имеют разные значения dscp, но нам необходим какой-то механизм для преобразования одного DSCP в другой. Мы ниже указанными командами задаем так называемые мутации:

    mls qos map dscp-mutation mutation1 1 2 3 4 5 6 7 to 0
    mls qos map dscp-mutation mutation1 8 9 10 11 12 13 to 10
    mls qos map dscp-mutation mutation1 20 21 22 to 20
    mls qos map dscp-mutation mutation1 30 31 32 33 34 to 30


    Следом должны применить данную «мутацию» на интерфейс. Ну и как всегда после проделанной работы проверим командой: show mls qos maps dscp-mutation.

    Комментарии 6

      +2
      спасибо добавлю себе в избранное)
      а вот тут надо исправить опечатки:
      «Данный вид основывается полностью на определения протокола на третьем уровне уровне, также при помощи ACL.»
        0
        Спасибо, исправил.
        +1
        не хотите добавить про трасты и мутации dscp?
          +2
          Сделайте ссылку, на предыдущую вашу статью, тем более вы ее упоминаете.

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

        Самое читаемое