Теория: QoS — управление качеством обслуживания

Зачем расставлять приоритеты трафику, DSCP-маркировка, очереди и разница policing/shaping. Прочитайте материал, а затем пройдите тест — следующий пункт курса откроется после верных ответов.

Зачем нужен QoS

По умолчанию сеть работает по принципу best effort — все пакеты равны, никто не получает приоритета, и при перегрузке канала пакеты просто отбрасываются в порядке очереди (или вовсе случайно, если буфер переполнен). Для обычной передачи файлов это не страшно — TCP заметит потерянный сегмент и перепошлёт его, пользователь в худшем случае увидит файл, который скачался на секунду дольше. Но для голоса и видео в реальном времени задержка или потеря пакета невосполнима: переотправка физически не успеет встроиться в живой разговор, и собеседник либо услышит провал в речи, либо звук станет нечётким и «роботизированным». QoS (Quality of Service) — набор механизмов, которые позволяют сознательно решать, чей трафик важнее в момент, когда канал не может пропустить всё и сразу.

Параметры качества канала — и конкретные ориентиры для голоса

• Latency (задержка) — сколько времени пакет идёт от отправителя к получателю. Для голоса приемлемый ориентир — до 150 мс в одну сторону (рекомендация ITU G.114); выше этого порога собеседники начинают ощущать неестественную паузу перед ответом, как в плохом международном звонке прошлых десятилетий.
• Jitter (джиттер) — насколько задержка колеблется от пакета к пакету; для голоса джиттер даже хуже, чем сама стабильная задержка, потому что сбивает естественный ритм речи — типичный ориентир держать джиттер ниже 30 мс.
• Packet loss (потери пакетов) — какая доля пакетов не доходит; для голоса некомфортно уже при потерях выше 1%, хотя кодеки умеют маскировать отдельные потерянные пакеты, заполняя пробел приближённым звуком.
• Bandwidth (пропускная способность) — сколько данных в секунду канал может пропустить.
Голосу критичны низкая задержка, низкий джиттер и минимальные потери, но почти не нужна большая полоса (один голосовой звонок по кодеку G.711 — это всего около 64 Кбит/с плюс служебные накладные расходы). Массовой передаче файлов — ровно наоборот: важна полоса, а вот задержка почти не имеет значения, лишних 200 мс никто не заметит на загрузке файла, который скачивается минуту.

Модели QoS: Best Effort, IntServ, DiffServ

Best Effort — никакого QoS, все пакеты равны (описано выше). IntServ (Integrated Services) — каждый поток данных явно резервирует ресурсы канала через протокол RSVP перед началом передачи, буквально спрашивая разрешения у каждого узла на пути: «зарезервируй для меня вот столько полосы на ближайшие 10 минут». Это даёт по-настоящему жёсткие гарантии, но не масштабируется: на магистральном роутере, через который проходят миллионы независимых потоков одновременно, отслеживать состояние резервации для каждого потока попросту нереально по объёму памяти и вычислений. DiffServ (Differentiated Services) — практический подход, используемый сегодня почти повсеместно: пакеты не резервируют ресурсы заранее и ничего ни у кого не спрашивают, а просто помечаются классом прямо в заголовке, и каждый узел сети самостоятельно решает, как обработать этот класс согласно своей локальной политике — никакой координации между узлами не требуется, что и позволяет масштабироваться до размеров всего интернета.

Классификация и маркировка (DSCP)

В DiffServ-модели приоритет кодируется в поле DSCP (Differentiated Services Code Point) заголовка IP — это 6 бит, теоретически до 64 значений. Распространённые классы: EF (Expedited Forwarding, числовое значение 46) — для голоса, минимальная задержка и потери, обычно только один этот класс на всю сеть, чтобы не размывать его смысл; AF (Assured Forwarding) — целое семейство классов (AF11–AF43) с разным приоритетом для обычных приложений вроде видео или важных бизнес-данных; CS (Class Selector) — для обратной совместимости со старым полем ToS/IP Precedence из ранних версий IPv4, где было всего 8 уровней приоритета вместо 64.

Кроме DSCP на уровне IP (L3) есть и 802.1p CoS (Class of Service) на уровне Ethernet (L2) — 3 бита приоритета внутри тега 802.1Q (тема одного из предыдущих уроков про VLAN), всего 8 уровней. CoS и DSCP — разные поля в разных заголовках, и при переходе кадра с L2 на L3 (или наоборот) информацию иногда приходится сознательно сопоставлять одну с другой, иначе приоритет, заданный на одном уровне, может просто потеряться на границе.

DSCP — шесть бит в заголовке IP, по которым каждый роутер решает, кого пропускать вперёд

заголовок IP

Версия · IHL1 Б

DiffServ1 Б

Длина2 Б

TTL1 Б

Протокол1 Б

IP отправителя4 Б

IP получателя4 Б

Данные…

Значение DSCP — всего лишь число. Само по себе оно ничего не ускоряет: пакет поедет быстрее только там, где на интерфейсе настроены очереди, которые это число читают. Метка без политики на устройствах — просто байт в заголовке.

Доверие маркировке и trust boundary

Маркировку DSCP/CoS принято ставить на границе управляемой сети — там, где трафик впервые попадает под контроль администратора, и эта точка называется trust boundary. До этой точки маркировке, пришедшей извне (например, от пользовательского ПК), доверять нельзя: если разрешить любому устройству самостоятельно ставить себе DSCP EF («у меня самый важный трафик»), пользователи быстро научатся помечать так вообще всё, и смысл всей приоритизации обнулится. Поэтому типичная практика — на границе сети сбрасывать или принудительно перемаркировывать DSCP входящего трафика согласно политике, и только потом, уже внутри управляемой инфраструктуры, доверять собственной маркировке.

Механизмы обработки очередей

• FIFO — простая очередь «первым пришёл — первым ушёл», без приоритизации вообще: при перегрузке канала пакеты просто выстраиваются и ждут своего хода в порядке прибытия, независимо от важности.
• Priority Queueing (PQ) — строгий приоритет: пока есть хоть один пакет в приоритетной очереди, низкоприоритетные пакеты не обслуживаются вообще — риск полного «голодания» (starvation) низкоприоритетного трафика, если высокоприоритетного слишком много (что в принципе не должно случаться с голосом, но легко может произойти, если в приоритетный класс по ошибке попало что-то ещё, кроме голоса).
• WFQ / CBWFQ (Weighted/Class-Based Fair Queueing) — справедливое распределение полосы между классами по заданным весам, без полного вытеснения одного класса другим — каждый класс гарантированно получит свою долю канала даже при перегрузке.
• LLQ (Low Latency Queueing) — практичная комбинация: строгий приоритет (PQ) для самого чувствительного к задержке трафика (голос), а всё остальное распределяется через CBWFQ — самый распространённый практический выбор для сетей с голосом и видео, потому что голосу действительно нужен строгий приоритет, а вот остальным классам — просто справедливая доля, а не вытеснение друг друга.

Управление перегрузкой: tail drop и WRED

Когда буфер очереди заполняется полностью, самый простой способ справиться с перегрузкой — tail drop: новые пакеты, не помещающиеся в буфер, просто отбрасываются в конце очереди. Проблема в том, что при этом может одновременно «обрезаться» сразу множество TCP-сессий, и все они одновременно среагируют на потерю снижением скорости (TCP congestion control), а затем одновременно попробуют восстановиться — получается синхронная пульсация трафика, известная как global synchronization, снижающая общую эффективность использования канала.

WRED (Weighted Random Early Detection) решает эту проблему иначе — начинает случайно отбрасывать отдельные пакеты заранее, ещё до того, как буфер заполнится полностью, и чем ближе буфер к переполнению, тем выше вероятность отбрасывания. Это работает как мягкое предупреждение части TCP-сессий по одной, не давая им синхронизироваться, в отличие от резкого одновременного «обрезания» всех сразу при классическом tail drop.

Очередь на перегруженном интерфейсе: кто ждёт, кто обгоняет, кого выкидывают

очередь на выходном интерфейсе

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

Policing и Shaping

Оба механизма ограничивают скорость трафика до заданного лимита, но по-разному реагируют на превышение. Policing — превышающие лимит пакеты сразу отбрасываются или перемаркируются более низким приоритетом, без какой-либо буферизации: просто и быстро в реализации, но резко по последствиям для трафика-нарушителя. Shaping — превышающие лимит пакеты буферизуются и отправляются немного позже, сглаживая резкие всплески трафика вместо немедленного отбрасывания (пока буфер не переполнится окончательно) — мягче по отношению к трафику, но требует памяти на буфер и добавляет небольшую дополнительную задержку, которая для голоса может оказаться нежелательной, а для обычной передачи данных совершенно неважна.

Как проверять / частые ошибки

show policy-map interface — посмотреть, как применяется QoS-политика на конкретном интерфейсе, и статистику по каждому классу отдельно (сколько пакетов прошло, сколько отброшено в каждой очереди). Главная и самая частая ошибка — забыть, что QoS работает только если настроен консистентно на всём пути пакета end-to-end: если голос промаркирован и приоритезирован на одном роутере, а на следующем хопе маркировка игнорируется (или вообще сбрасывается на границе с сетью другого оператора, который не обязан доверять чужой маркировке) — все усилия первого узла оказываются абсолютно бесполезны, потому что узкое место может оказаться именно там, где QoS не настроен.

Команды настройки — шпаргалка

# описать класс трафика
class-map match-all VOICE     # match-all — должны совпасть ВСЕ условия ниже
                              #   (есть match-any — достаточно любого).
                              #   VOICE — придуманное вами имя
 match dscp ef                # само условие: метка DSCP равна EF, так
                              #   помечают голос

# что с этим классом делать
policy-map QOS-POLICY         # контейнер правил, имя придумываете сами
 class VOICE                  # ссылка на описанный выше класс
  priority percent 10         # строгий приоритет и не больше 10% полосы.
                              #   Это и есть LLQ; процент ограничивает сверху,
                              #   чтобы голос не задавил всё остальное
 class class-default          # встроенное имя: всё, что не попало в явные классы
  fair-queue                  # поделить остаток полосы между потоками поровну
                              #   (CBWFQ)

# применить на порт — без этого политика ни на что не влияет
interface GigabitEthernet0/1
 service-policy output QOS-POLICY
                              # output — направление: исходящий трафик.
                              #   Очереди имеют смысл на выходе, где затор

# граница доверия на коммутаторе
interface GigabitEthernet0/2
 mls qos trust dscp           # trust dscp — принимать входящую метку как есть.
                              #   Без команды коммутатор обнулит чужую маркировку.
                              #   Вместо dscp бывает cos — метка канального уровня

# проверка
show policy-map interface     # сколько пакетов попало в каждый класс
                              #   и сколько отброшено

Контрольные вопросы

Дальше — лабораторная работа «QoS: раздели полосу под голос»

Для неё нужен аккаунт: стенд поднимается персонально под вас — свои роутеры, свои конфиги, никто в них не мешает. Регистрация — почта и пароль.

Создать аккаунт → У меня есть аккаунт

Теория прочитана. Дальше — руками.

Личный стенд из настоящих роутеров разворачивается за секунды. Платформа проверяет не ответы на тесты, а состояние вашей сети: поднялись ли соседства, сошлись ли маршруты, ходит ли ping. Рядом — AI-наставник, который видит ваши конфиги и ведёт к решению, не выдавая готовое.

Начать бесплатно → бета открыта, доступ бесплатный