Коммутаторы : Коммутаторы Cisco Nexus серии 7000

Пример конфигурации QoS коммутатора Cisco Nexus серии 7000

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ предоставляет пример конфигурации для функций качества обслуживания (QoS) на коммутаторе Cisco Nexus серии 7000, чтобы упростить, как достигнуты классификация и организация очереди.

Внесенный Энди Госсеттом, Аль Брайантом, и Раесом Гатти, специалистами службы технической поддержки Cisco.

Предварительные условия

Требования

Убедитесь, что вы обеспечили выполнение следующих требований, прежде чем попробовать эту конфигурацию:

  • Имейте базовые знания о конфигурации Коммутаторов Cisco Nexus серии 7000

  • Имейте базовые знания о QoS

Используемые компоненты

Сведения в этом документе основываются на Коммутаторе Cisco Nexus серии 7000.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

 Более подробную информацию о применяемых в документе обозначениях см. в описании условных обозначений, используемых в технической документации Cisco. 

Обзор

Параметры QoS по умолчанию на Коммутаторе Nexus 7000 достаточны для большинства развертываний. Однако необходимо понять ограничения и элементы конфигурации, требуемые создать пользовательскую политику.

Существует два аспекта, что необходимо рассмотреть для QoS на Nexus линейные платы серии M 7000:

  • политика организации очереди

  • Политики QoS

Организация очереди выполнена в аппаратных средствах и настроена с использованием политики организации очереди Командной строки Modular QoS CLI (MQC). Политики QoS, используемые, чтобы отметить или определить политику трафика, используются через политику MQC в точном формате как стандартная политика QoS на других Платформах cisco. Например, список доступа использовал классифицировать трафик на class-map с соответствующим policy-map для установки трафика.

В настоящее время модули серии M выполняют организацию очереди, основанную строго на значении класса обслуживания (CoS). Поэтому необходимо сначала понять, как получено значение CoS. После знания, какое значение CoS вводит/оставляет коммутатор, можно фокусироваться на настройке организации очереди для получения желаемого QoS для других типов трафика.

Поведение класса обслуживания

Для маршрутизировавшего трафика с конкретным адресом значение CoS получено из 3 Most Significant Bits значения точки кода дифференцированных услуг (DSCP). Для соединённого мостом трафика с конкретным адресом значение CoS скопировано со значения CoS, полученного в 802.1q заголовок. Обратите внимание на то, что на соединениях доступа L2 нет никакого заголовка транка. Поэтому, если трафик будет получен на порте доступа и соединит его, то будет выход коммутатор с CoS 0. DSCP-значение не изменено, но пакет может не получить желаемый приоритет. Можно вручную установить значение CoS в policy-map через любую политику QoS, которая вручную устанавливает CoS или DSCP-значение.

Важно понять поведение для групповой адресации также. Направленный многоадресный трафик получает свое значение CoS таким же образом как маршрутизировавший трафик с конкретным адресом. Для соединённого мостом многоадресного трафика поведение зависит от состояния L3. Если нет никакого состояния L3 для группы многоадресной рассылки, CoS получен таким же образом как соединенный трафик с конкретным адресом. Если существует состояние L3 для группы многоадресной рассылки, CoS получен таким же образом как маршрутизировавший трафик с конкретным адресом. Обратите внимание на то, что при включении независимой от протокола многоадресной передачи (PIM) в разреженном режиме на виртуальном интерфейсе коммутатора (SVI) для VLAN, в которой трафик получен, S, G запись создан, когда замечена групповая адресация.

Таким образом, поведение CoS для типа трафика показывают здесь:

Тип трафикаПоведение CoS
маршрутизировавшая индивидуальная рассылкаскопированный с с 3 MSB из ToS
соединенная индивидуальная рассылканеизменный
маршрутизировавшая групповая адресацияскопированный с с 3 MSB из ToS
мост, переданный в многоадресном режиме с L3, сообщает для группыскопированный с с 3 MSB из ToS
мост, переданный в многоадресном режиме без L3, сообщает для группынеизменный

Модифицируйте поведение CoS на соединениях доступа

Рассмотрите пример, где трафик получен на порте доступа (Eth8/1) и соединен на VLAN. По умолчанию значение CoS соединённого мостом трафика с конкретным адресом неизменно. Если трафик поступает в порт доступа, значение CoS по умолчанию 0 назначено. В данном примере приоритетный трафик (DSCP 46) получен на порте доступа и выходе коммутатор с неизменным DSCP-значением и значение CoS 0. Таким образом пакет не получает надлежащий приоритет.

Примечание: Заголовок CoS показывают только для разъяснения. E8/1 является портом доступа, таким образом, значение CoS 0. Поток пакетов слева направо.

Потенциальный обходной путь должен создать политику QoS для ручной установки значения CoS на входном порте.

В примере только пакетам с DSCP 46 обновили их значения CoS. Если бы были множественные DSCP-значения, требуемые гарантировать надлежащее значение CoS, то дополнительные карты классов и действия в policy-map должны были бы быть определены.

Альтернативный вариант должен использовать table-map с действием 'стандартная копия'. Table-map позволяет вам перезагружать DSCP на основе текущего DSCP-значения. Например, если бы трафик был получен с DSCP-значением 40, и необходимо гарантировать, что он был отмечен к DSCP-значению 46, то вы могли использовать карту таблицы с действием 'от 40 до 46'.

Table-map также содержит действие 'стандартной копии', которое устанавливает DSCP-значение в его исходное значение. Это подобно созданию policy-map с классификацией 'ef match dscp' и действия 'ef set dscp'. Логически, DSCP-значение неизменно, но действие 'set dscp' implictly устанавливает значение CoS в с 3 MSB из нового DSCP-значения.

Поэтому, если необходимо гарантировать, что значение CoS всегда обновляется к с 3 MSB из DSCP-значения, используйте table-map с одиночным действием 'стандартной копии'.

 

Выбор выходной очереди и список

Как только значение CoS получено, можно манипулировать глобальными картами классов организации очереди для влияния на cos к сопоставлениям очередности. Эти карты классов являются глобальным и влияют на все модули во всех контекстах виртуального устройства (VDC) для того определенного типа организации очереди. Например, рассмотрите эти карты классов организации очереди по умолчанию для M108 и модулей M132 (1p7q4 т):

class-map type queuing match-any 1p7q4t-out-pq1
 Description: Classifier for egress priority queue of type 1p7q4t
 match cos 5-7

class-map type queuing match-any 1p7q4t-out-q2
 Description: Classifier for egress queue 2 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q3
 Description: Classifier for egress queue 3 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q4
 Description: Classifier for egress queue 4 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q5
 Description: Classifier for egress queue 5 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q6
 Description: Classifier for egress queue 6 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q7
 Description: Classifier for egress queue 7 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q-default
 Description: Classifier for egress default queue of type 1p7q4t
 match cos 0-4

По умолчанию, потому что 0-4 сопоставлен с очередью по умолчанию и потому что 5-7 сопоставлен с очередью с приоритетами. Они идут рука об руку с политикой организации очереди по умолчанию для того же типа организации очереди:

policy-map type queuing default-out-policy 
 class type queuing out-pq1
   priority level 1
   queue-limit percent 16
 class type queuing out-q2
   queue-limit percent 1
 class type queuing out-q3
   queue-limit percent 1
 class type queuing out-q-default
   queue-limit percent 82
   bandwidth remaining percent 25

Очередь с приоритетами является 'приоритетом' с queue-limit 16%. Очередь по умолчанию имеет queue-limit 82% с весом сохраняющего полосы пропускания по умолчанию. Другим очередям, которые не используются, назначают queue-limit 1%. Обратите внимание на то, что q4, q5, и q6 не представлены в политике организации очереди по умолчанию и будут, поэтому, иметь еще меньший queue-limit и вес пропускной способности запрограммированными в аппаратных средствах.

Создайте пользовательскую политику создания очередей

Для создания пользовательской политики создания очередей выполните эти шаги:

  1. Создайте пользовательскую политику создания очередей с желаемым предельным размером очереди и распределением пропускной способности.
  2. Модифицируйте глобальные карты классов организации очереди для создания необходимого CoS к сопоставлению очередности.
  3. Примените новую политику организации очереди к соответствующим интерфейсам.

Рассмотрите пример для модулей M132, которые имеют 1p7q4 т, помещающие архитектуру в очередь, где все 8 значений CoS сопоставлены с отдельной очередью. Выходные данные показывают пользовательскую политику создания очередей наряду с изменениями к глобальным картам классов организации очереди:

policy-map type queuing 10G_POLICY
class type queuing 1p7q4t-out-pq1
priority level 1
queue-limit percent 10
class type queuing 1p7q4t-out-q2
queue-limit percent 10
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q3
queue-limit percent 5
bandwidth remaining percent 5
class type queuing 1p7q4t-out-q4
queue-limit percent 5
bandwidth remaining percent 5
class type queuing 1p7q4t-out-q5
queue-limit percent 10
bandwidth remaining percent 20
class type queuing 1p7q4t-out-q6
queue-limit percent 5
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q7
queue-limit percent 5
bandwidth remaining percent 10
class type queuing 1p7q4t-out-q-default
queue-limit percent 50
bandwidth remaining percent 40
! voice
class-map type queuing match-any 1p7q4t-out-pq1
match cos 5
! scavenger
class-map type queuing match-any 1p7q4t-out-q2
match cos 1
! transactional
class-map type queuing match-any 1p7q4t-out-q3
match cos 2
! call signaling
class-map type queuing match-any 1p7q4t-out-q4
match cos 3
! video
class-map type queuing match-any 1p7q4t-out-q5
match cos 4
! routing
class-map type queuing match-any 1p7q4t-out-q6
match cos 6
! management
class-map type queuing match-any 1p7q4t-out-q7
match cos 7
! best effort
class-map type queuing match-any 1p7q4t-out-q-default
match cos 0

Заключительный шаг должен применить пользовательскую политику создания очередей к каждому интерфейсу на 1p7q4 т:

interface Ethernet8/1
service-policy type queuing output 10G_POLICY

Предупреждения

Политика организации очереди по умолчанию предполагает, что CoS 0-4 сопоставлен с очередью по умолчанию, и CoS 5-7 сопоставлены с очередью с приоритетами. Поэтому ограничения очереди для очередей q3, q4, q5, q6, и q7 являются чрезвычайно маленькими. Можно ввести команду show queuing interface для проверки текущего размера очереди и пропускной способности, настроенной и прикладной в аппаратных средствах.

Рассмотрите пример политики в предыдущем разделе, где каждое значение CoS было сопоставлено с определенной очередью. В конце примера пользовательской политике создания очередей применились к Eth8/1. Кроме того, предположите, что существует другой интерфейс на 1p7q4 т (Eth6/1), который оставили с политикой организации очереди по умолчанию:

N7k# show queuing interface e6/1
<some output omitted>

  Configured queue-limit ratios
     queue-limit ratios:    78[1p7q4t-out-q-default] 1[1p7q4t-out-q2] 1[1p7q4t-out-q3]
*1[1p7q4t-out-q4] *1[1p7q4t-out-q5] *1[1p7q4t-out-q6] *1[1p7q4t-out-q7] 16[1p7q4t-out-pq1]
  * means unused queue with mandatory minimum queue-limit

 Thresholds:
     COS   Queue                      Threshold Type     Min    Max
     ______________________________________________________________
      0    1p7q4t-out-q-default           DT             100    100
      1    1p7q4t-out-q2                  DT             100    100
      2    1p7q4t-out-q3                  DT             100    100
      3    1p7q4t-out-q4                  DT             100    100
      4    1p7q4t-out-q5                  DT             100    100
      5    1p7q4t-out-pq1                 DT             100    100
      6    1p7q4t-out-q6                  DT             100    100
      7    1p7q4t-out-q7                  DT             100    100

От вышеупомянутых выходных данных вы видите, что у очередей q2 и q3 есть queue-limit 1%, в то время как q4, q5, q6, и q7 имеют *1%, который является минимальным обязательным queue-limit (другими словами., значительно меньше чем 1%). Кроме того, вы видите, что значения CoS 1-4 и 6-7 используют эти очень малочисленные очереди. Маленькие размеры очереди быстро приводят к выходному сбросу и могут ухудшить производительность сети.  Если CoS стандартного трафика 0 сопоставлен с одной из этих малочисленных очередей, это далее усилено.

Таким образом, если вы создаете политику настраиваемой организации очереди и изменяете глобальные карты классов организации очереди, важно применить пользовательскую политику создания очередей ко всем интерфейсам через шасси, которые совместно используют тот же тип организации очереди.

Кроме того, некоторые полезные команды отбрасывания перечислены здесь:

  • show policy-map interface ex/y
  • show system внутренняя статистика организации очереди взаимодействует ex/y

Дополнительные сведения



Document ID: 113556