Не будем переписывать документацию, а просто на примере рассмотрим, как все это работает. Просьба прочитать «39. Механизмы качества обслуживания (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_Cameramatch 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_policyclass-map делается по его номеру no 1. где 1 это индекс правила в class-mappolicy-map делается по имени класса no class cm_Cameraclass-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. На выходе будет отрабатывать произвольная политика
Кратко о порядке действий:
!отобразит статистику отбора пакетов в соответствии с правилами
show ip class-map *
!очистит набранную статистику
show ip class-map * zero
Статья очень полезная, но помогите ограничить на входящий трафик тоже
Применяйте правила на интерфейсе, что смотрит в локальную сеть ...