Настройка QoS + устранение проблем с перегрузками в очередях

Quality of Service (QoS) - технология предоставления различным классам трафика различных приоритетов в обслуживании. Для классификации трафика используются стандартные поля в заголовках:

• 3-битный Class of Service (CoS) в Ethernet;
• 6-битный Differentiated Services Code Point (DSCP) в IP.

Исходя из значений данных заголовков полученным кадрам назначается внутренний приоритет (Internal Priority), в соответствии с которым на выходе кадры распределяются по внутренним очередям. Для распределения по очередям используются так называемые карты QoS: CoS - IntP, DSCP - IntP, Exp - IntP и далее IntP - Queue.

Если вы хотите подробно разобраться в теме QoS и работе QoS на коммутаторах SNR, приглашаем вас прочитать статью на эту тему.

Алгоритмы управления очередями

Приоритет передачи трафика для внутренних очередей определяется одним из следующих алгоритмов:

• Strict Priority (SP) - строгий приоритет. Пока в более приоритетной очереди есть данные, которые необходимо передать, другие очереди не обрабатываются.
• Weighted Round Robin (WRR) - для каждой очереди определяется вес. Из очередей по порядку берется кратное весу очереди число кадров.
• Weighted Deficit Round Robin (WDRR) - для каждой очереди также устанавливается вес, определяющий количество бит, которые могут быть взяты из очереди. Количество бит пополняется каждый цикл.

Возможно комбинирование алгоритмов WRR/WDRR с SP, для этого достаточно задать нулевой вес для очереди, которую необходимо обрабатывать приоритетно.

Service policy

Позволяет классифицировать трафик на основе различных признаков (ACL, CoS, VLAN ID, IPv4 Precedence, DSCP, IPv6 FL) с возможностью дальнейшей перемаркировки, определения трафика в конкретную очередь, ограничения полосы пропускания и других действий. Рассмотрим создание service-policy подробнее:

Для классификации трафика создается карта классов:

class {class_name}

В режиме настройки класса выбирается критерий, по которому полученные кадры будут классифицированы:

match {...}

Далее создается карта политик:

policy-map {map_name}

Карта политик ассоциируется с необходимым классом и выбирается действие для классифицированного трафика.

Перемаркировка:

set {...}

Ограничение полосы пропускания:

policy {bits_per_second} burst-group {burst-group-id}

Действие сброса либо дальнейшей передачи трафика:

[no] drop
[no] transmit

Применять service-policy можно как к определенному порту в режиме его конфигурирования:

service-policy {input | output} {name}

так и к VLAN в режиме глобального конфигурирования:

service-policy {input | output} {name} vlan {vid}

Multicast policy

Позволяет задать метку CoS для маркировки multicast-трафика на коммутаторе. Можно задать разные значения CoS для разных источников и/или разных групп:

ip multicast policy {source_ip/mask} {group_ip/mask} cos {0-7}

Статистика QoS по очередям

На коммутаторах SNR серий S2995G, S3850G, S2990X, S300X, S300G и S4550 существует возможность просмотра статистики очередей QoS. Рассмотрим подробнее данный функционал:

Сначала необходимо включить возможность снятия статистики QoS в глобальной конфигурации:

mls qos queue statistics enable

Настройка функционала на этом заканчивается. Далее можно смотреть статистику по необходимому интерфейсу, например eth1/0/1:

show mls qos queue statistics interface ethernet 1/0/1

В случае, если QoS настроен по дефолту, все пакеты попадают в нулевую очередь, соответственно в графе dropped будут отображены пакеты, отброшенные по причине превышения пропускной способности канала:

Port:Ethernet1/0/1
-----------------------------------------
Queue Passed(packet) Dropped(packet)
0            2827022         2236755
1                  0               0
2                  0               0
3                  0               0
4                  0               0
5                  0               0
6                  0               0
7                  0               0

Снятие статистики дропов доступно по SNMP, OID: 1.3.6.1.4.1.40418.7.100.11.2.17.1.4.a.b, где:

a - номер порта;
b - номер очереди.

Настройка QoS на коммутаторах SNR

SNR-S2962, SNR-S2965, SNR-S2982G, SNR-S2985G

По умолчанию коммутаторы SNR-S2962(5) и SNR-S2982(5)G доверяют значению СoS, но режим доверия можно изменить. Выставляется данный режим отдельно для каждого порта:

[no] mls qos trust {cos | dscp}

Если режим доверия установлен одновременно и для значения CoS и для значения DSCP - приоритет отдается значению DSCP. ::: Значение CoS для нетегированного входящего трафика можно установить в режиме конфигурирования порта:

mls qos cos {0-7}

подсказка

Чтобы добавить CoS 802.1p к внешнему тегу (s-vid) QinQ нужно отключить доверие существующей метке с помощью 'no mls qos trust cos' и прописать нужный CoS 802.1p с помощью 'mls qos cos', к внутреннему тегу (c-vid) CoS 802.1p можно добавить с помощью policy-map.

Полученные кадры распределяются по 8 внутренним очередям в соответствии с QoS-картой. По умолчанию значения CoS и внутренней приоритизации равны:

Ingress cos-TO-Internal-Priority map:
COS: 0 1 2 3 4 5 6 7
-----------------------------------------
INTP: 0 1 2 3 4 6 6 7
Ingress DSCP-TO-Internal-Priority map:
d1:d2     0 1 2 3 4 5 6 7 8 9
0:        0 0 0 0 0 0 0 0 1 1
1:        1 1 1 1 1 1 2 2 2 2
2:        2 2 2 2 3 3 3 3 3 3
3:        3 3 4 4 4 4 4 4 4 4
4:        5 5 5 5 5 5 5 5 6 6
5:        6 6 6 6 6 6 7 7 7 7
6:        7 7 7 7

Также могут быть установлены индивидуальные соответствия:

mls qos map dscp-intp {cos-dp | cos-intp | dscp-dp | dscp-dscp | dscp-intp}

Для управления очередями по умолчанию используется алгоритм WRR. Изменить алгоритм и веса очередей можно в контексте конфигурирования порта:

mls qos queue algorithm {sp | wdrr | wrr}
mls qos queue {wrr | wdrr} weight {weight0-weight7}

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

• Одновременное изменение значений CoS и DSCP не поддерживается чипом коммутатора. Изменить значение можно только для одной метки.
• При изменении метки с помощью service-policy также необходимо изменять внутренний приоритет классифицированному трафику, в противном случае он будет выбран по первичному значению метки.
• Не рекомендуется одновременно использовать service-policy на VLAN и на портах данной VLAN.

Рассмотрим несколько примеров:

 Пример №1

 Пример №2

 Пример №3

SNR-S2995G, SNR-S3850G

По умолчанию коммутаторы SNR-S2995G и SNR-S3850G не доверяют ни одной из меток. Режим доверия можно изменить отдельно для каждого порта:

[no] mls qos trust {cos | dscp | exp}

примечание

Если режим доверия установлен одновременно и для значения CoS и для значения DSCP - приоритет отдается значению DSCP. Если установлен и EXP, то он имеет наивысший приоритет.

Значение CoS для нетегированного входящего трафика можно установить в режиме конфигурирования порта:

mls qos cos {0-7}

Кроме этого, данные модели позволяют выставить внутренний приоритет для нетегированного трафика в режиме конфигурирования порта:

mls qos internal-priority {0-119}

В случае, если необходимо изменить IntP для определенного порта, но метку CoS/DSCP/ExP оставить без изменений (в обычном варианте значение метки будет выбрано по IntP) на данных моделях создан функционал pass-through:

pass-through-cos
pass-through-dscp-exp

Полученные кадры распределяются по 8 внутренним очередям в соответствии с QoS-картой:

Ingress cos-TO-Internal-Priority map:
COS:  0 1  2  3  4  5  6  7
----------------------------
INTP: 0 8 16 24 32 40 48 56
Ingress DSCP-TO-Internal-Priority map:
d1 : d2      0   1  2  3  4  5  6  7  8  9
0:           0   1  2  3  4  5  6  7  8  9
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:           50 51 52 53 54 55 56 57 58 59
6:           60 61 62 63

Также могут быть установлены индивидуальные соответствия:

mls qos map dscp-intp {cos-cos | cos-dscp | cos-intp | dscp-cos | dscp-dscp | dscp-intp | exp-intp | intp-cos | intp-dp | intp-dscp | intp-exp | intp-intp | intp-queue}

Как мы видим по QoS-картам, данные модели позволяют управлять метками в обоих направлениях, а не только ingress.

Для управления очередями по умолчанию используется алгоритм WDRR. Изменить веса очередей можно в глобальном режиме:

mls qos queue weight {weight0-weight7}

Важно!

• На данных моделях приоритетными очередями (SP) - могут быть только очереди, начиная с последней. Их может быть несколько, но последовательность должна быть непрерывной;
• Не рекомендуется одновременно использовать service-policy на VLAN и на портах данной VLAN;
• При изменении метки с помощью service-policy также необходимо изменять внутренний приоритет классифицированному трафику, в противном случае он будет выбран по первичному значению метки.

Рассмотрим еще один пример (примеры, указанные для серий S2962, S2965, S2982G и S2985G справедливы и для этой серии):

 Пример

Для нетегированного трафика на порте 1/0/28 установить IntP равным 64, при этом значение CoS нужно оставить без изменений.

Switch(config)#interface ethernet 1/0/28
Switch(config-if-ethernet1/0/28)#pass-through-cos
Switch(config-if-ethernet1/0/28)#mls qos internal-priority 64

Решение проблем с перегрузками в очередях (Счётчик "Dropped(packet)" в выводе "show mls qos queue statistics")

В сетях с трафиком высокоскоростного характера (например, в сетях SAN) или при передаче трафика из порта с большей скоростью в порт меньшей скорости (даже если статистическая скорость трафика не превосходит скорость порта с меньшей скоростью) вы можете столкнуться с отбрасыванием трафика в очередях/пакетном буфере. Это чаще всего возникает из-за микровсплесков (или микробёрстов, microburst или просто burst). Чем больше буферная память коммутатора и вернее подобран метод распределения буферной памяти, тем лучше он справляется с возникновением микровсплесков в сети. Вы можете найти таблицу размеров пакетных буферов для коммутаторов SNR по ссылке.

Откуда берётся микровсплеск, если скорость потока не превосходит скорость порта?

Взгляните на два этих графика:

Средняя скорость передачи трафика по обоим графикам – 6 Гб/с.
Но если мы рассмотрим скорость на более мелком участке, то увидим, что скорость за эти промежутки времени разная:

1. В первом примере 6 Гигабит было передано за 0,5 секунды, в оставшиеся 0,5 секунды ничего не передавалось – за 1 секунду было передано 6 Гигабит;
2. Во втором примере 6 Гигабит были равномерно переданы за 1 секунду.
   В обоих случаях средняя скорость 6 Гигабит в секунду;
   Однако если мы посмотрим на первый пример и рассчитаем скорость передачи трафика для первых 0,5 секунды, то это будет 12 Гб/с за первые 0,5 секунды.
   И в этом случае в первые 0.5 секунд коммутатор воспользуется буфером.
   Если буфера не хватит, чтобы передать 12 Гб/с за первые 0,5 секунды, то возникнут дропы, несмотря на то, что средняя скорость за секунду в обоих примерах - 6 Гб/с. В данном примере утрированно показана равномерная нагрузка 6 Гб/с за 0,5 секунды для наглядности. На деле такие всплески длятся миллисекунды, а то и микросекунды (можете увидеть в примере ниже).

Рекомендация по диагностике микровсплесков

Если вы хотите выявить микровсплески по графикам в Wireshark (Инструмент находится здесь: "Статистика" → "Графики Ввода/Вывода"), то будьте внимательны.
По умолчанию графики строятся с интервалом 1 секунда по оси X, то есть по оси Y у вас будет средняя за 1 секунду.
Как мы говорили выше в скрытом тексте, всплески можно наблюдать за очень короткие промежутки времени, поэтому интервал в 1 секунду довольно большой для их обнаружения, и за секунду всё усредняется до нормальных значений.
Чтобы увидеть всплески, вам необходимо указать меньшее значение интервала (смотрите, куда наведён курсор):

Пример: у клиента на порту 10 Gbps были замечены дропы в статистике "show mls qos queue statistics". Был снят дамп с порта, и выведены графики в Wireshark.
С интервалом за 1 секунду средняя скорость была 6 Gbps. Но вот с интервалом 1 мс можно было видеть вот такую картину:

Есть заметные всплески. Можно нажать на эти всплески на графике, и в главном окне Wireshark вы перейдёте к времени всплеска. И уже можете смотреть, какие потоки у вас создают такие всплески.

Решения проблем с всплесками:

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

Административные решения:

• Условия: представьте сеть, где можно классифицировать трафик на два типа:

  1. трафик небольшой скорости (не создаёт заторы в буфере), который не терпит задержки;
  2. высокоскоростные потоки, которые создают заторы в буфере, но могут восстановиться благодаря работе поверх TCP.

  Тогда решение может быть следующим: переопределить политику QoS так, чтобы трафик 1-го типа помещался в приоритетную очередь, а остальной всплескообразный трафик может дропаться (благодаря TCP потерянные сегменты самовосстановятся).

• Повлиять на источники всплескообразного трафика так, чтобы всплески уменьшились (не универсальное решение, не всегда есть такая возможность).

• Если всплеск образуют несколько потоков, то разделить пути передачи таких потоков, чтобы распределить нагрузку между несколькими устройствами (не универсальное решение, частично – архитектурное).

Архитектурные решения:

• Использовать устройства с высокоскоростными портами, превосходящими скорости микровсплесков (дорогое и не универсальное решение).
• Использовать скоростные транспортные системы вроде FiberChannel (не универсальное решение, может быть очень дорогим решением, особенно если нужен полный переход).
• Использовать Ethernet-коммутаторы либо Cut-through, либо Store-and-forward, но обязательно с большим пакетным буфером (ссылка: обратите внимание на SNR-S4650X, SNR-S7550 и SNR-S400X).

Конфигурационные решения:

• Иногда бывает так, что буфера должно хватать для всплесков, но по какой-то причине их не хватает. Это может быть связано с настроенным принципом распределения буферной памяти. В следующей главе представлено несколько решений для коммутаторов SNR по регулированию работы коммутатора с буферной памятью.

Конфигурационные решения для некоторых коммутаторов SNR

Некоторые модели имеют конфигурационные решения для проблем, связанных с переполнением очередей. На момент 12.05.2026 решение имеют модели:
Для SNR-S4350X, команда в режиме глобальной конфигурации:

mls qos burst-mode dynamic

— данная команда позволяет сделать пакетный буфер динамическим: если порту не хватает памяти, отведённой для него, он может взять неиспользуемый объём, незанятый другими портами.

Для SNR-S2995G, команда в режиме глобальной конфигурации:

mls qos burst level <level>

— данная команда увеличивает разрешённый объём буферной памяти, выделяемый портам. Рекомендуется начинать с Level 3 и увеличивать это значение, пока дропы не пропадут.