Попробую продолжить начатую мной тему методологии и алгоритма функционирования QoS в Cisco. В этой статье будет описано по каким принципам можно разделить и маркировать трафик на 2-3 уровнях модели OSI на пошаговых примерах. Кому интересен данный вопрос прошу под кат.
В предыдущей статье я описывал Modular QoS CLI и приводил в пример блок-схему функционирования алгоритма QoS Cisco, в конце статьи мы будем возвращаться в данной блок схеме. Для того, чтобы быть эффективным QoS должен быть внедрен на всей сети. Лучше всего классифицировать трафик по принципу «чем скорее, тем лучше», т.е. в нашем случае на уровне доступа. Фреймы и пакеты следует маркировать используя следующие принципы:
— Уровень 2 (CoS)
— Уровень 3 (IP Precedence/Differentiated Services Code Point)
CoS — выставляет приоритеты от 0 до 7. Если граничное устройство (IP телефон или приложение) умеет выставлять биты, то планировщик сети должен решить «доверять» данному устройству или нет.
Действие свитча по умолчанию:
Не доверять граничному устройству, на всех фреймах попавших на свич, будут сброшены приоритеты на 0.
Если граничному устройство разрешается доверять, то свитч необходимо «предупредить» о неприкосновенности данного бита.
В зависимости от модели свитча, сначала может понадобиться включить QoS — это делается командой mls qos. Дальше на интерфейсе указывается доверительное отношение к CoS, и политика применяемая к пакету, если тот пришел без соответствующего бита. В итоге получаем:
Также если мы хотим чтобы свитч игнорировал присутствующий бит CoS в пакете — необходимо воспользоваться следующим сочетанием команд, в результате будет использован QoS по умолчанию:
Не всегда возможно распознать значение CoS пакета, так как не всегда устройства включены напрямую в свитч уровня доступа, часто случается, что клиент бывает воткнут в простейший неуправляемый свитч, которому не известно понятие приоритетов, к сожалению мы не сможем воспользоваться IP ACL, т.к. мы не уверены в постоянстве IP адреса клиента, здесь нам придется использовать MAC ACL, примерно это будет выглядеть вот так.
Определяем поток трафика, class-map используется для определения потока трафика как класса сервиса, в данном случае класс сервиса мы назвали ipphone:
Проверить созданное мы сможем при помощи команды: show class-map
Продолжаем конфигурировать наше правило, следующим шагом мы определяем функции QoS в политике, назначая значение DSCP для существующего класса:
Проверить результаты мы можем командой: show policy-map
Ниже я хочу привести сводную таблицу сопоставления значений нашего «волшебного поля» для разного типа определителей.
На данном этапе остается последнее действие применение политики на интерфейс в нашем случае мы применим эту политику на все порты нашего свитча одновременно:
И как обычно проверяем наш результат, к примеру на первом порту: show mls qos interface fa 0/1
Как всегда обобщаем наши действия в конце, если Вы обращали внимание на предыдущую мою статью, то не могли забыть о блок-схеме связей в политиках QoS, можно проследить указанные ниже команды по данной блок-схеме.
Теперь рассмотрим несколько другой вариант применения такого рода классификаторов для пакетов. Данный вид основывается на определении протокола на третьем уровне, но не без помощи того же ACL.
Рассмотрим пример предотвращения загрузки канала трафиком FTP, в Вашем случае — это может быть что угодно, хоть диапазон портов. Мы будем маркировать пакеты нулевым значением, что превратит эти пакеты, в пакеты с наименьшим приоритетом, и по технологии IP precedence и по DSCP.
В данном случае это будет выглядеть примерно так;
Утверждаем заранее запланированную политику трафика на группу интерфейсов:
Определяем функции QoS в политике, в данном случае она будет заключаться в добавлении значения 0 в ячейку dscp, ip пакета.
Определяем поток трафика:
И последнее условие, необходимое для исполнение всего вышеописанного:
В завершении статьи хочу еще раз напомнить о блок схеме, которая была показана в предыдущей статье, если Вы пишите политики QoS, то держите ее перед глазами, она поможет Вам очень легко с ориентироваться и никогда не запутаться в момент составления правил.
Спасибо за внимание.
P.S. По совету IlyaPodkopaev добавляю немного информации о понятиях trust и dscp-mutation
qos trust — В контексте настройки интерфейса эта команда используется для включения доверенного состояния каждого порта.
qos dscp-mutation — Применяет карту изменений DSCP для доверенного порта DSCP системы (всегда перезаписывает DSCP для этого порта).
Чаще всего последняя команда используется если два домена имеют разные значения dscp, но нам необходим какой-то механизм для преобразования одного DSCP в другой. Мы ниже указанными командами задаем так называемые мутации:
Следом должны применить данную «мутацию» на интерфейс. Ну и как всегда после проделанной работы проверим командой: show mls qos maps dscp-mutation.
В предыдущей статье я описывал Modular QoS CLI и приводил в пример блок-схему функционирования алгоритма QoS Cisco, в конце статьи мы будем возвращаться в данной блок схеме. Для того, чтобы быть эффективным QoS должен быть внедрен на всей сети. Лучше всего классифицировать трафик по принципу «чем скорее, тем лучше», т.е. в нашем случае на уровне доступа. Фреймы и пакеты следует маркировать используя следующие принципы:
— Уровень 2 (CoS)
— Уровень 3 (IP Precedence/Differentiated Services Code Point)
CoS — выставляет приоритеты от 0 до 7. Если граничное устройство (IP телефон или приложение) умеет выставлять биты, то планировщик сети должен решить «доверять» данному устройству или нет.
Действие свитча по умолчанию:
Не доверять граничному устройству, на всех фреймах попавших на свич, будут сброшены приоритеты на 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
Ниже я хочу привести сводную таблицу сопоставления значений нашего «волшебного поля» для разного типа определителей.
На данном этапе остается последнее действие применение политики на интерфейс в нашем случае мы применим эту политику на все порты нашего свитча одновременно:
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.
