• Быстрый переход
  • Рубрики
  • Свежие записи
  • Метки
  • Архивы
  • Реклама 1
  • Реклама 2
  • Рейтинг@Mail.ru

    QoS (Качество обслуживания) на Catalyst 3750. Общие принципы и примеры!


    3750 QOS: Общие принципы:

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

    Classification – для каждого пакета свичу нужно сгенерить QoS Label, который будет сопровождать пакет внутри свича и определять всю его последующую QoS-обработку. Для этого свич «мапирует» CoS или DSCP входящего пакета на QoS Label.
    Policing – определяет попадает ли пакет в профайл или он out profile. Результат отражается в QoS Label и передается Маркеру.
    Marking – оценивает результат полисера и проверяет настройки: что сделать с пакетом, если он out profile. Возможные действия: пропустить без изменений; пропустить, но сделать mark down the QoS label; дропнуть.
    Queueing – поместить пакет в одну из двух ingress очередей свича. Для этого просматривается QoS Label. Сначала по DSCP\CoS пакета выбирается нужная очередь, затем механизм WTD проверяет не превышен ли в этой очереди трешолд для данного DSCP\CoS. Если трешолд превышен, то пакет дропится иначе ставится в очередь.
    Scheduling – механизм SRR (исключительно Shared Round Robin)

    На выходе выполняются следующие шаги:

    Queueing – поместить пакет в одну из четырех egress очередей порта. Для этого просматривается QoS Label. Сначала по DSCP\CoS пакета выбирается нужная очередь, затем механизм WTD проверяет не превышен ли в этой очереди трешолд для данного DSCP\CoS. Если трешолд превышен, то пакет дропится, иначе ставится в очередь
    Scheduling – механизм SRR (Shaped or Shared Round Robin).

    ЗАПОМНИ: Из ingress очередей пакеты попадают в stack ring, т.е. шедулер этих двух очередей управляет передачей пакетов на стековую магистраль. Соответственно BW, которая выделяется каждой очереди – это часть BW стековой магистрали. Из egress очередей портов пакеты попадают в линк, т.е. BW выделяемая каждой очереди – это часть BW порта.

    NOTE: Т.к. суммарная входящая BW всех портов может превысить пропускную способность stack ring'а, то входящие очереди располагаются перед stack ring'ом, т.е. они «сдерживают» траф, уходящий в stack ring. Т.к. несколько входящих портов могут одновременно отправить пакеты в один исходящий порт, то BW этого порта может быть превышена, поэтому egress очереди расположены после stack ring'а, т.е. они сдерживают траф, уходяший в линку.
    Классификация:

    Работает только если QoS глобально включен. Её единственная задача – сгенерить для пакета QoS Label. Данный лейбл позволяет унифицировано обрабатывать весь трафик, ведь пакеты поступают с различными типами QoS характеристик (IP precedence, DSCP, CoS) и нужно привести их к общему виду.

    Итак, в ходе классификации пакету назначается QoS Label, который может быть DSCP based or CoS based. Что это значит ?

    Т.е. если мы доверяем(trust) IP-marking, то в любом случае (IP или non-IP трафик) получаем DSCP based label. Если мы доверяем(trust) CoS-marking, то в любом случае (были или нет CoS биты) получаем CoS based label.

    NOTE: Если мы классифицируем с помощью MQC, то можем установить DSCP или IP Precedence командой set. В этом случае мы тоже получим DSCP based label. Через MQC нельзя использовать команду set cos, на свичах она недоступна. Единственный способ влиять на CoS через MQC – это изменять DSCP таким образом, чтобы затем она мапилась на нужный CoS.

    Policing and Marking:

    После того как пакет получил QoS Label, он передается на полисер, который решает является ли пакет in profile или out profile. Полисер не дропит и не перекрашивает трафик, он просто присваивает ему одну из двух категорий. Результат отражается в QoS Label и пакет переходит на обработку в Marking. Marking просматривает в лейбле результат полисинга и его настройки для работы с out profile трафом. Именно Marking может дропнуть или перекрасить пакет.

    NOTE: Стоит заметить, что marked-down пакет будет размещаться в очереди, согласно своему оригинальному QoS Label'у, а не модифицированному.

    Queueing and Scheduling:

    Перед шедулингом пакет должен попасть в одну из очередей, которая определяется на основе QoS Label'а. Т.к. у нас есть  DSCP based и CoS based лейблы, то существуют соответствующие глобальные карты мапирования DSCP->Queue и CoS->Queue. После того как очередь определена, то вступает в работу механизм WTD. Он должен либо дропнуть пакет либо позволить ему попасть в выбранную очередь. У каждой очереди есть три трешолда (они одни и те же для DSCP и CoS’ов). Если трешолд для данного класса трафа не превышен, то пакет помещается в очередь.

    Немного о трешолдах. У каждой очереди (ingress\egress) три трешолда. Трешолды настраиваются глобально, кроме того они - независимые значения, настраиваются сами по себе, т.е. нет отдельных трешолдов для DSCP и для CoS'ов. DSCP и CoS'ы просто проецируются на номер трешолда независимо от его значения. Из трех трешолдов можно конфигурить threshold1 и threshold2. Threshold3 не конфигурится и составляет 100%.

    Пример 1:

    Допустим мы хотим, чтобы во входящую очередь 2 попадали пакеты с CoS 2, 5, 6 и 7. Причем при заполнении очереди на 40% дропится весь траф с CoS 2; при заполнении на 60% дропится весь траф с CoS 5; и при заполнении на 100% дропится всё остальное: CoS 6-7. Мы хотим смапить CoS'ы на очередь 2 и на трешолды этой очереди, а также установить сами трешолды. Выполняется это двумя командами:

    Отдельно установкой значений трешолдов для очереди
    И отдельно мапинг CoS'ов на очередь и на её трешолд

    mls qos srr-queue input threshold queue-id threshold-percentage1 threshold-percentage2
    mls qos srr-queue input cos-map queue queue-id threshold threshold-id cos1…cos8

    mls qos srr-queue input threshold 2 40 60
    mls qos srr-queue input cos-map queue 2 threshold 1  2
    mls qos srr-queue input cos-map queue 2 threshold 2  5
    mls qos srr-queue input cos-map queue 2 threshold 3  6 7

    SW#sh mls qos maps cos-input-q
    Cos-inputq-threshold map:
    cos:  0   1   2   3   4   5   6   7  
    ------------------------------------
    queue-threshold: 1-1 1-1 2-1 1-1 1-1 2-2 2-3 2-3

    NOTE: Обращаю внимание, что WTD – это не RED. WTDtail drop в чистом виде: пока порог не достигнут – ничего не дропится, как достигнут, то дропится всё то, для чего этот порог определен.

    Пример 2:

    Допустим мы хотим, чтобы во входящую очередь 2 попадали пакеты с DSCP 40-45. Причем при заполнении очереди на 60% дропятся все пакеты DSCP 40-41, при заполнении на 80% дропятся DSCP 42-43 и при запонении на 100% дропится всё остальное.

    Т.к. отдельных трешолдов для DSCP и для CoS нет, то нам придется изменить глобальные трешолды, настроенные в предыдущем примере.

    mls qos srr-queue input threshold 2 60 80
    mls qos srr-queue input dscp-map queue 2 threshold 1  40 41
    mls qos srr-queue input dscp-map queue 2 threshold 2  42 43
    mls qos srr-queue input dscp-map queue 2 threshold 3  44 45

    KTJA_3750_ST3_SW#sh mls qos maps dscp-input-q
    Dscp-inputq-threshold map:
    d1 :d2    0     1     2     3     4     5     6     7     8     9
    ------------------------------------------------------------
    0 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
    1 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
    2 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
    3 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
    4 :    02-01 02-01 02-02 02-02 02-03 02-03 02-01 02-01 01-01 01-01
    5 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01
    6 :    01-01 01-01 01-01 01-01

    KTJA_3750_ST3_SW#sh mls qos input-queue
    Queue     :       1       2
    ----------------------------------------------
    buffers   :      90      10
    bandwidth :       4       4
    priority  :       0      10
    threshold1:     100      60
    threshold2:     100      80

    Два предыдущих примера показали как мапить пакеты на ingress очереди и их трешолды, а также как устанавливать значения трешолдов для входящих очередей. Для работы с egress очередями используются те же принципы и команды, только исходящих очередей четыре и они у каждого порта свои. Работая с egress очередями мы глобально определяем их трешолды и мапинг DSCP\CoS на очередь и трешолд. Т.е. эти настройки одинаковы для всех портов. Однако в контексте порта мы можем выполнить дополнительные настройки шедулера, которые будут уникальны для данного порта.

    Теперь рассмотрим подробнее механизмы управления очередями и шедулером. И входящие и исходящие очереди управляются SRR'ом. Из входящих очередей он отправляет пакеты в stack ring, из исходящих в egress port. Ingress очереди могут работать исключительно в режиме sharing. Egress - в режиме sharing и shaping.

    Shape mode – очередь гарантированно получает свой процент от BW и в тоже время ограничена (rate-limit) этой величиной, т.е. shaped traffic does not use more BW even if the link is idle.
    Share mode - очереди делят между собой всю доступную BW согласно своим weights (like CB queue scheduler). BW гарантирована, но не ограничена. For example, if a queue is empty the other queues can expand into the unused BW and share it among them.

    NOTE: Маппинг на входящие и исходящие очереди и их трешолды выполняется ГЛОБАЛЬНО !!!

    Входящие очереди:

    Свич выделяет под нужды ingress очередей некий буфер памяти. Мы можем административно поделить этот буфер между очередями, указав процентные соотношения для каждой очереди. По умолчанию очередь 1 получает 90%, а очередь 2 – 10%. Административно разделяя буфер мы должны помнить,  что сумма процентов должна составлять 100. Ниже мы пытаемся для каждой очереди выделить по 60% и получаем сообщение об ошибке:

    KTJA_3750_ST3_SW(config)#mls qos srr-queue input buffers 60 60
    The sum should be equal to 100

    После того как очередям передано буферное пространство мы можем настроить BW, выделяемую каждой очереди. Входящих очередей две на весь свич и они могут работать только в режиме share. Напоминаю, что для ingress очереди выделяется % от available bandwidth стековой магистрали и делается это по тому же принципу, что и в механизме CQ (Custom Queue). Ниже очередь 1 получает weight 8, а очередь 2 – weight 4.

    SW(config)#mls qos srr-queue input bandwidth 8 4

    В результате q1_bw = 8/(8+4) от общей BW стека, а q2_bw = 4/(8+4) от общей BW стека. Однако не всё так просто. Для ingress очередей свич поддерживает механизм priority queue и он включен по умолчанию для очереди 2.

    Вот как это работает: одна из очередей назначается на роль priority и ей явно выделяется % от BW стека (допустимые значения от 0 до 40). Шедулер гарантирует, что эта BW будет доступна очереди, даже если стековая магистраль загружена. Назначим очередь 1 на роль priority и выделим ей 10% от BW стека:

    SW(config)mls qos srr-queue input priority-queue 1 bandwidth 10

    В результате выполнения двух последних команд шедулер сначала обработает очередь 1, предоставив обещанные 10%, а затем станет обрабатывать обе очереди: 1 и 2, распределяя между ними оставшиеся 90% согласно weight каждой очереди. Т.е. очередь 1 гарантированно получит 10% и плюс ещё ? от оставшихся 90%. Во как !

    NOTE: По умолчанию настройки входящих очередей  и их трешолдов выглядят так:

    SW#sh mls qos input-queue
    Queue     :       1       2
    ----------------------------------------
    buffers   :      90      10
    bandwidth :       4       4
    priority  :       0      10
    threshold1:     100     100
    threshold2:     100     100

    SW#sh mls qos maps dscp-input-q
    SW#sh mls qos maps cos-input-q

    DSCP 0-39, 48-63    -> Queue 1, Threshold 1
    DSCP 40-47        -> Queue 2, Threshold 1
    CoS 0-4, 6, 7    -> Queue 1, Threshold 1
    CoS 5            -> Queue 2, Threshold 1

    KTJA_3750_ST3_SW#sh mls qos maps dscp-cos
    Dscp-cos map:
    d1 :  d2 0  1  2  3  4  5  6  7  8  9
    ---------------------------------------
    0 :    00 00 00 00 00 00 00 00 01 01
    1 :    01 01 01 01 01 01 02 02 02 02
    2 :    02 02 02 02 03 03 03 03 03 03
    3 :    03 03 04 04 04 04 04 04 04 04
    4 :    05 05 05 05 05 05 05 05 06 06
    5 :    06 06 06 06 06 06 07 07 07 07
    6 :    07 07 07 07

    Т.е. видно, что под high-priority траф выделена очередь 2 и DSCP 40-47 проецируются на CoS 5.

    Исходящие очереди:

    Для начала нужно рассмотреть алгоритмы выделения буферов памяти под egress очереди и назначения различных трешолдов в очередях. Данные операции выполняются через настройку templat'а с последующим его наложением на интерфейс. В качестве templat'ов используются queue-set'ы. Всего их два и по умолчанию на все порты наложен queue-set 1.

    NOTE: queue-set применяется к интерфейсу в целом, а не к отдельной очереди, однако в рамках queue-set'а по отдельности настраивается шаблон для каждой очереди !

    Итак, свич создает два пула памяти для работы egress очередей: reserved pool и common pool. В  reserved пуле для каждого порта резервируется некоторое адресное пространство для буферов его очередей. Мы не знаем размер этого пространства, но мы можем поделить его между четырьмя очередями в процентном соотношении (сумма указанных процентов, или как их называют «weights», должна быть равна 100)

    mls qos queue-set output 2 buffers 40 20 20 20

    После того как пул порта «разрезан» на части и каждая очередь получила свою долю из резерва, мы должны сказать свичу сколько реально выделить (allocate) физической памяти для каждой очереди из её доли. Это тоже делается в процентах. Поясню: с точки зрения очереди вся зарезервированная за ней доля – это её 100% (Вообще эти 100% являются единицей измерения для всех трешолдов). Мы можем «сконвертировать» в физическую память либо всю долю, либо только её часть. В последнем случае неиспользованная часть доли переходит в common pool. Передавая очереди физическую память мы указываем значение 1-100 % (reserved-threshold).

    В процессе работы нагрузка на очередь может возрастать и ей потребуется дополнительная физическая память. Вся дополнительная память для очередей выделяется из common pool'а. Мы можем указать максимальный объем физической памяти, до которого очередь может увеличится. Значение задается в процентах (maximum-threshold). Обращаю внимание, что указывается вообще максимально допустимый для очереди объем памяти, а не дельта к изначально выделенной памяти.

    Допустим для очереди 1 зарезервировано 1000 байт адресного пространства. Если мы установим reserved-threshold в 100 %, то она получит 1000 байт физической памяти. Если мы установим maximum-threshold в 200 %, то очередь сможет расшириться ДО 2000 байт, а НЕ НА 2000 байт. Вообще все трешолды задаются в процентах, где за 100% принимается размер адресного пространства изначально зарезервированного за очередью. Теперь обо всех трешолдах на конкретном примере. Команда для установки трешолдов очереди выглядит так:

    mls qos queue-set output qset-id threshold queue-id
    drop-threshold1
    drop-threshold2
    reserved-threshold
    maximum-threshold

    Два трешолда мы уже рассмотрели, осталось разобраться с drop-трешолдами. Это те же самые drop-трешолды, что и для ingress очередей. Они также указываются в процентах, но их значения могут превышать 100%. Смотри пример ниже.

    mls qos queue-set output 2 threshold 1 110 160 100 200

    В этом примере reserved-threshold 100%, т.е. очередь 1 сразу получает всю физическую память из зарезервированной для неё доли. В процессе работы очередь может вырасти до maximum-threshold 200%. Drop-threshold’ы составляют соответственно 110 и 160 %. Они могут превышать 100% т.к. и сама очередь может увеличиваться за пределы своих изначальных 100%.

    KTJA_3750_ST3_SW#sh mls qos queue-set 2
    Queueset: 2
    Queue     :       1       2       3       4
    ----------------------------------------------
    buffers   :      40      20      20      20
    threshold1:     110     
    threshold2:     160     
    reserved  :     100      
    maximum   :     200     

    А теперь все вместе с наложением templat’а на порт:

    mls qos queue-set output 2 buffers 40 20 20 20
    mls qos queue-set output 2 threshold 1 110 160 100 200

    interface gigabitEthernet 1/0/1
    queue-set 2

    KTJA_3750_ST3_SW#show mls qos interface gigabitEthernet 1/0/1 buffers
    GigabitEthernet1/0/1
    The port is mapped to qset : 2
    The allocations between the queues are : 40 20 20 20

    К сожалению нет возможности одним махом просмотреть все связки port <-> queue-set. Можно просматривать per port, как сделано выше.

    NOTE: По умолчанию буфер порта делится между исходящими очередями в равных долях – по ?. Определяй размеры очередей в соответствии с важностью трафика. Для highest-priority трафа буфер нужен побольше, а лучше вообще буферы не трогать ))) Трешолды по умолчанию настроены так:

    KTJA_3750_ST3_SW#sh mls qos queue-set
    Queueset: 1
    Queue     :       1       2       3       4
    ----------------------------------------------
    buffers   :      25      25      25      25
    threshold1:     100     200     100     100
    threshold2:     100     200     100     100
    reserved  :      50      50      50      50
    maximum   :     400     400     400     400

    Queueset: 2
    Queue     :       1       2       3       4
    ----------------------------------------------
    buffers   :      25      25      25      25
    threshold1:     100     200     100     100
    threshold2:     100     200     100     100
    reserved  :      50      50      50      50
    maximum   :     400     400     400     400

    С буферами и трешолдами разобрались, теперь будем изучать работу SRR-шедулера на исходящих очередях.

    SRR шедулер может работать в следующих режимах: shared, shaped и смешанном shared and shaped.

    Shared mode:

    BW выделяется каждой очереди согласно её весу. Это аналогично механизму CQ. Т.е. когда мы конфигурим

    interface Fa1/0/1
    speed 10
    srr-queue bandwidth share 30 20 25 25
    srr-queue bandwidth shaрe 0  0  0  0

    то получаем weight сумму 30+20+25+25 = 100%, и очереди 1 гарантированно будет предоставлено 30/100 * 10 Mbps = 3Mbps. Как говорилось выше shared режим позволяет загруженным очередям пользоваться свободными ресурсами простаивающих очередей. Гарантированная BW каждой очереди рассчитывается с учетом текущей sending rate порта. По поводу sending rate и clock rate смотри ниже.

    Shaped mode:

    Каждая очередь гарантированно получает абсолютную долю от текущей clock rate порта согласно своему весу. Веса других shape очередей не учитываются. В этом режиме очередь не может использовать ресурсы простаивающих очередей, т.е. она ограничена тем, что ей положено, даже если у порта есть свободные ресурсы для передачи дополнительного трафа.

    interface Fa1/0/1
    speed 10
    srr-queue bandwidth shape 20 0 0 0

    Очередь 1 гарантировано получит (10 Mbps / 20) = 200 kbps, но и будет ограничена этой BW. Если одной и той же очереди назначены оба веса, то share вес не учитывается вообще, т.е. shape всегда имеет старшинство.

    Shape and Share mix:

    interface FastEthernet0/13
    srr-queue bandwidth share 100 100 40 20
    srr-queue bandwidth shape  50  50  0  0

    Здесь для очередей 1 и 2 указаны и shared и shaped веса. Учитываются только shaped, т.к. они приоритетнее. Итак, интерфейс работает на 100Mbps. Очереди 1 и 2 гарантированно получают по 1/50 от текущей физической скорости интерфейса, т.е. по 1/50 * 100Mbps = 2 Mbps. Очереди 3 и 4 делят между собой оставшуюся, remaining, BW (100-2-2=96Mbps) в пропорции 2:1.

    NOTE: Default “shape” and “shareweight settings are as follows: “25 0 0 0” and “25 25 25 25”. Это означает, что очередь 1 обрезается до 4Mbps на интерфейсе 100Mpbs (до 400Kbps на интерфейсе 10Mbps). Очереди 2-4 делят между собой remaining BW в равных долях: каждая получает 25/(25+25+25)=1/3 от 96Mbps. Включая QoS на свиче нужно помнить, что очередь 1 обрезается таким образом, по умолчанию на неё проецируются DSCP 40-47 и CoS 5.

    NOTE: Когда на интерфейсе включается команда priority-queue out, то очередь 1 начинает работать как PQ. При этом все её share или shape настройки игнорируются ! PQ очередь может starve другие очереди.

    NOTE: Можно применить “aggregate” egress rate-limitng на порту через srr-queue bandwidth limit xx . В этом случае interface sending rate снижается до ХХ% текущей физической скорости порта. Допустимые для ХХ значения начинаются от 10% поэтому если, например, требуется снизить скорость отправки порта до 3Mbps, то сначала нужно установить speed 10, а затем srr-queue bandwidth limit 30. Обращаю внимание, clock rate у порта остается прежней и определяется командой speed, просто мы включаем policing на отправку.

    А теперь рассмотрим такой пример:

    interface FastEthernet0/13
    switchport mode access
    speed 10
    srr-queue bandwidth shape 50 0 0 0
    srr-queue bandwidth share 20 20 20 20
    srr-queue bandwidth limit 20

    Текущая clock rate порта 10 Mbps (speed 10), т.е. принимать он может на этой скорости, но policing ограничивает скорость отправки до 2Mbps (srr-queue bandwidth limit 20). Очередь 1 настроена на shape, который рассчитывается исходя из clock rate: 1/50 * 10 Mbps = 200kbps. Очереди 2-4 делят remaining BW (2 Mbps – 200 kbps) в равных долях.

    Пример 3

    На входе используем policer плюс trust dscp. Всё что in profile – проходит без изменений. Всё что в out profile должно быть marked down согласно глобальной таблице policed-dscp. По умолчанию эта таблица мапит «один в один», т.е. изменений никаких не делает.

    mls qos map policed-dscp dscp-list to mark-down-dscp

    mls qos map policed-dscp  50 51 52 53 54 55 56 57 to 0

    KTJA_3750_ST3_SW#sh mls qos maps policed-dscp
    Policed-dscp map:
    d1 :  d2 0  1  2  3  4  5  6  7  8  9
    ---------------------------------------
    0 :    00 01 02 03 04 05 06 07 08 09
    1 :    10 11 12 13 14 15 16 17 18 19
    2 :    20 21 22 23 24 25 26 27 28 29
    3 :    30 31 32 33 34 35 36 37 38 39
    4 :    40 41 42 43 44 45 46 47 48 49
    5 :    00 00 00 00 00 00 00 00 58 59
    6 :    60 61 62 63

    class-map ipclass1
    match access-group 1

    policy-map flow1t
    class ipclass1
    trust dscp
    police 1000000 8000 exceed-action policed-dscp-transmit

    interface gigabitethernet2/0/1
    service-policy input flow1t

    Пример 4

    Применяем aggregate policier на входе. Смысл в том, чтобы создать некий полисир, а потом применить его к нескольким классам внутри одной policy-map. Тогда траф всех этих классов логически «объединяется» в единый поток, который и обрезается полисером. Т.е. обрезание применяется к совокупному трафу классов, а не к трафу каждого класса в отдельности.

    mls qos aggregate-policer agp-256 256000 32000 exceed-action drop
    !
    class-map match-all cm-192.168.0.0
    match access-group name acl-to-192.168.0.0
    class-map match-all cm-10.0.0.0
    match access-group name acl-to-10.0.0.0
    class-map match-all cm-172.16.0.0
    match access-group name acl-to-172.16.0.0
    !

    policy-map pm-qos
    class cm-10.0.0.0
    police aggregate agp-256
    set dscp cs5
    class cm-192.168.0.0
    police aggregate agp-256
    trust dscp
    class cm-172.16.0.0
    police 64000 8000 exceed-action drop
    trust dscp

    Пример 5

    Если два QoS домена имеют разные DSCP окраски, то можно применить DSCP-to-DSCP mutation map чтобы транслировать одни DSCP в другие. Созданная DSCP-to-DSCP mutation map применяется затем на входящем интефейсе.

    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

    interface FastEthernet1/0/1
    mls qos trust dscp
    mls qos dscp-mutation mutation1

    sh mls qos maps dscp-mutation

    Dscp-dscp mutation map:
    mutation1:
    d1 :  d2 0  1  2  3  4  5  6  7  8  9
    ---------------------------------------
    0 :    00 00 00 00 00 00 00 00 10 10
    1 :    10 10 10 10 14 15 16 17 18 19
    2 :    20 20 20 23 24 25 26 27 28 29
    3 :    30 30 30 30 30 35 36 37 38 39
    4 :    40 41 42 43 44 45 46 47 48 49
    5 :    50 51 52 53 54 55 56 57 58 59
    6 :    60 61 62 63

    Пример 6

    Ограничиваем BW в сторону customer'а. Фактически это полисинг.

    interface FastEthernet1/0/2
    speed 10
    srr-queue bandwidth limit 30

    Теперь клиент, подключенный к этому порту, сможет качать на скорости 3 mbps. Однако он продолжит отдавать на скорости 10 mbps. Нужен ещё входящий полисир, чтобы полностью почикать клиента.

    Пример 7

    Тестовый стенд. У свича порт fa1/0/48 в транке. К порту fa1/0/47 подключен комп. Нужно зашейпить трафик, исходящий на комп до 4 Mbps. Три способа – один через CoS, другой через DSCP, третий через полисинг в сторону компа. Как говорилось выше SRR шедулер для исходящих очередей настроен так: srr-queue bandwidth shape 25 0 0 0, т.е нужно поместить исходящий траф в очередь 1.

    Способ 1:

    mls qos
    mls qos srr-queue output cos-map queue 1 threshold 1 1

    interface FastEthernet1/0/48
    switchport trunk encapsulation dot1q
    switchport mode trunk
    load-interval 30
    mls qos cos 1
    mls qos cos override

    Способ 2:

    mls qos
    mls qos srr-queue output dscp-map queue 1 threshold 1 8

    policy-map pm-qos-in
    class class-default
    set dscp 8

    interface FastEthernet1/0/48
    switchport trunk encapsulation dot1q
    switchport mode trunk
    load-interval 30
    service-policy input pm-qos-in

    Способ 3:

    Здесь не учитываем исходящие очереди вообще, а ставим полисир на порт в целом в исходящем направлении. Настройки на Fa1/0/48 роли не играют.

    mls qos

    interface FastEthernet1/0/47
    switchport access vlan 618
    switchport mode access
    speed 10
    srr-queue bandwidth limit 40

    Пример 8.

    Hierarchical Policy-Maps for Classification and Marking.

    Обычно мы выполняем классификацию на физических портах (per-port classification), однако данный метод позволяет использовать policy-map на SVI-интерфейсе, и все настройки QoS'а применяются сразу ко всем портам, переносящим трафик этой VLAN, включая и транки.

    Итак, SW1 и SW2 соединены тремя параллельными транками. R4 также подключен к SW2. Коммутатор SW1 порождает трафик, направленный на R4. SW2 классифицирует его на входе.

    SW1:interface Vlan 201
    ip address 155.1.201.7 255.255.255.0!
    interface Vlan 202
    ip address 155.1.202.7 255.255.255.0
    SW2:mls qos
    !
    access-list 100 permit ip any any
    !
    class-map IP_TRAFFIC
    match access-group 100
    !
    policy-map VLAN201_POLICY
    class IP_TRAFFIC
    set ip precedence 5
    !
    policy-map VLAN202_POLICY
    class IP_TRAFFIC
    set ip precedence 4
    !
    interface Vlan 201
    no ip address
    !
    interface Vlan 202
    no ip address
    !
    interface range Fa 0/13 , Fa 0/14 , Fa 0/15
    mls qos vlan-based
    !
    interface Vlan 201
    service-policy input VLAN201_POLICY
    !
    interface Vlan 202
    service-policy input VLAN202_POLICY

    Во-первых, на SW2 мы создаем «пустые» VLAN-интерфейсы. Они нужны только для того, чтобы «принять» QoS-настройки, поэтому IP-адреса на них не требуются. Во-вторых, policy-map'ы накладываем на эти VLAN-интерфейсы, а не на физические порты. В-третьих, policy-map’ы VLAN-интерфейсов распространятся только на те физические порты, которые mls qos vlan-based - это касается access-портов соответствующих вланов и транков.

    NOTE: Так называемые Hierarchical Policy-Maps можно применять только на SVI интерфейсах, но не на физических портах. Такие policy-map'ы допускают два уровня: VLAN Level (верхний) и Port Level (вложенная policy-map'а). На VLAN уровне мы можем классифицировать, trust'ить и маркеровать. Эти настройки распространяются на трафик всех mls qos vlan-based портов, связанных с трафиком данного влана, включая транки. На Port уровне мы определяем policier и указываем конкретные порты, где этот полисер действует. Допустимо указать до шести портов. Т.е. полисер действует на подмножество портов, охваченных VLAN-уровнем. Работа с полисером в иерархических policy-map'ах рассмотрена в следующем примере.

    Пример 9.

    Hierarchical Policy-Maps for Policing.

    Здесь используется та же топология и на входе SW2 выполняет классификацию, маркинг и  полисинг – для трафика каждого влана в отдельности. В предыдущем примере мы фактически не увидели иерархии в policy-map'е, поэтому повторюсь, что иерархическая policy-map'а имеет два уровня: VLAN Level (верхний) и Port Level (вложенный). На VLAN уровне мы можем только классифицировать и маркировать, но не можем полисить. Полисить можно либо непосредственно на физическом порту либо на Port уровне иерархической policy-map'ы. Далее даны настройки только данной фичи на SW2.

    mls qos
    !
    interface range Fa 0/13 , Fa 0/14 , Fa 0/15
    mls qos vlan-based
    !
    ! [Интерфейсы, на которые будет действовать полисер]
    class-map INPUT_INTERFACES
    match input-interface Fa 0/13 – fa 0/15
    !
    policy-map POLICE_64K
    class INPUT_INTERFACES
    police 64000 32000
    !
    policy-map POLICE_32K
    class INPUT_INTERFACES
    police 32000 16000
    !
    !
    access-list 100 permit ip any any
    !
    class-map IP_TRAFFIC
    match access-group 100
    !
    policy-map VLAN201_POLICY
    class IP_TRAFFIC
    set ip precedence 5
    service-policy POLICE_64K    [Вложенная policy-map для policier]
    !
    policy-map VLAN202_POLICY
    class IP_TRAFFIC
    set ip precedence 4
    service-policy POLICE_32K    [Вложенная policy-map для policier]
    !
    interface Vlan 201
    service-policy input VLAN201_POLICY
    !
    interface Vlan 202
    service-policy input VLAN202_POLICY

    Пример 10.

    Hierarchical Policy-Maps for Policing Markdown

    Продолжаем изучать полисинг. Снова используем ту же топологию, только теперь нам нужно mark down трафик, который out of profile. Как говорилось выше, для таких целей используется глобальная таблица policed-dscp. По умолчанию она мапит «один в один», т.е. изменений никаких не делает. Нам же надо, чтобы DSCP 40 преврашалась в 24, а DSCP 32 в 16.

    Конфига аналогична предыдущей, но с небольшими дополнениями. Они и приведены ниже:

    mls qos map policed-dscp  40 to 24
    mls qos map policed-dscp  32 to 16

    policy-map POLICE_64K
    class IP_TRAFFIC
    police 64000 32000 exceed-action policed-dscp-transmit
    !
    policy-map POLICE_32K
    class IP_TRAFFIC
    police 32000 16000 exceed-action policed-dscp-transmit

    Теперь самое интересное. Проверим как это работает:

    SW1#ping 155.1.201.4 repeat 100 size 1490 timeout 1
    SW1#ping 155.1.202.4 repeat 100 size 1490 timeout 1

    SW2#sh mls qos interface fa0/4 statistics
    dscp: incoming  
    -------------------------------

    0 -  4 :           0            0            0            0            0  
    5 -  9 :           0            0            0            0            0  
    10 - 14 :           0            0            0            0            0  
    15 - 19 :           0           89            0            0            0
    20 - 24 :           0            0            0            0           90
    25 - 29 :           0            0            0            0            0  
    30 - 34 :           0            0           11            0            0
    35 - 39 :           0            0            0            0            0  
    40 - 44 :          10            0            0            0            0
    45 - 49 :           0            0            0            0            0  
    50 - 54 :           0            0            0            0            0  
    55 - 59 :           0            0            0            0            0  
    60 - 64 :           0            0            0            0  

    dscp: outgoing
    ------------------------------

    0 -  4 :           0            0            0            0            0  
    5 -  9 :           0            0            0            0            0  
    10 - 14 :           0            0            0            0            0  
    15 - 19 :           0           89            0            0            0
    20 - 24 :           0            0            0            0           90
    25 - 29 :           0            0            0            0            0  
    30 - 34 :           0            0           11            0            0
    35 - 39 :           0            0            0            0            0  
    40 - 44 :          10            0            0            0            0
    45 - 49 :           0            0            0            0            0  
    50 - 54 :           0            0            0            0            0  
    55 - 59 :           0            0            0            0            0  
    60 - 64 :           0            0            0            0  

    Статистика дана для интерфейса F0/4, но она зеркально отражает процессы, произошедшие на портах Fa0/13 – Fa0/15. Разберемся на примере VLAN201. Итак, в SW1 вошло 100 пакетов: из них 10 оказались in profile и 90 out profile. Последовательность операций на входе:

    policy-map VLAN201_POLICY
    class IP_TRAFFIC
    set ip precedence 5
    service-policy POLICE_64K

    На что ещё обратить внимание:

    3550 QoS. Некоторые фичи.

    В Примере 8 предыдущего раздела мы выполняли классификацию и маркинг на SVI-интерфейсах. Работа сводилась к следующему:

    Явно указать порты, принадлежащие влану (включая транки), входящий трафик которых требует QoS обработки (mls qos vlan-based).
    Для трафика каждой влан создать отдельную policy-map и применить её к логическому SVI-интерфейсу.

    Свич 3550 предлагал другое решение для QoS-обработки входящего трафика различных вланов в транковый порт. Суть этого метода в том, чтобы внутри class-map дополнительно матчить по принадлежности к влану. Допустим предыдущая топология состоит из свичей 3550. Тогда бы Пример 8 выглядел так:

    mls qos
    !
    access-list 100 permit ip any any
    !
    class-map match-any IP_TRAFFIC
    match access-group 100
    !
    class-map match-all VLAN_201_IP
    match vlan 201
    match class-map IP_TRAFFIC
    !
    class-map match-all VLAN_202_IP
    match vlan 202
    match class-map IP_TRAFFIC
    !
    policy-map MARK_TRAFFIC
    class VLAN_201_IP
    set precedence 5
    class VLAN_202_IP
    set precedence 4
    !
    interface range FastEthernet0/13 - 15    [На транке, а не на SVI]
    service-policy input MARK_TRAFFIC

     Источник материала: http://cisco-conf.ru/qos/90-qos-catalyst-3750-.html
    Автор: admin, 20 июля 2013
    Рубрики: Cisco Systems, Новости
    Метки: , , , , , ,

    Написать комментарий

    Последние статьи