Теоретические основы и архитектура
Лабораторная: сквозная цепочка QoS оператора от доступа до ядра. Строится трёхуровневая схема. 1. Входной PE: policing клиента, классификация в четыре класса (голос EF, критичные данные AF31, видео AF41, best effort CS0) и отображение в TC. 2. Ядро (PE1 и P1 на каждом выходном интерфейсе): Low Latency Queuing с приоритетной очередью для голоса (TC 5), CBWFQ для видео и данных (TC 4 и 3) и WRED для best effort; сверху родительский shaper. 3. Выходной PE: Short-Pipe, очередь к клиенту выбирается по исходному DSCP. Дополнительно голосу выделяется Class-Type CT1 в DS-TE, чтобы объём голоса ограничивался уже при сигнализации. Результат проверяют измерением: счётчики классов, потери и джиттер голосового класса под синтетической перегрузкой (Iperf или TRex) сравниваются с целевыми значениями SLA; нулевые потери и конкретный джиттер нужно подтвердить, а не предполагать.
Что именно строит лабораторная
Цель - не набор команд, а доказуемая сквозная цепочка: клиентский DSCP на CE, TC на ingress PE1, очередь по TC на каждом транзитном интерфейсе (PE1, P1) и Short-Pipe на egress PE2. Затем поверх добавляется DS-TE: голос получает собственный Class-Type CT1 и туннель с зарезервированной полосой, чтобы объём голоса в ядре ограничивался на этапе сигнализации, а не только в очереди. Результат проверяется не конфигурацией, а измерением: счётчиками классов, потерями и джиттером при перегрузке.
| Узел | Классификация | Маркировка | Очередь/ограничение |
|---|---|---|---|
| PE1 ingress (от CE-A) | По клиентскому DSCP | EF -> TC 5, AF41 -> TC 4, AF31 -> TC 3, остальное -> TC 0 | Полисер EF 10 Мбит/с |
| PE1 egress (в ядро) | По TC верхней метки | Не меняется | LLQ 10% + CBWFQ 20/30% + WRED, parent shaper 100 Мбит/с |
| P1 | По TC | Не меняется | Те же классы и shaper на выходе к PE2 |
| PE2 egress (к CE) | По клиентскому DSCP (Short-Pipe) | Не меняется | Приоритет по DSCP EF |
План ёмкости для одного класса голоса
Один вызов G.711 с двумя метками MPLS занимает около 98 кбит/с на Ethernet (расчёт в уроке 1). Приоритетный класс 10 Мбит/с вмещает примерно 100 вызовов; запас 20% (до 120 кбит/с на вызов с накладными расходами канала) уменьшает число вызовов до 83. Размер очереди приоритетного класса делают маленьким: 10 мс при 10 Мбит/с - это 12 500 байт или 8 пакетов по 1500 байт; более глубокая очередь превращает затор в джиттер. Класс данных получает bandwidth percent 30 и WRED; Best Effort - остаток и самую агрессивную кривую WRED. Сумма гарантий (10 + 20 + 30) оставляет 40% для default: нельзя гарантировать больше 100% полосы родителя.
DS-TE: зачем нужен Class-Type
Обычный RSVP-TE ведёт один пул полосы на интерфейс: туннель с голосом на 10 Мбит/с и туннель с bulk на 100 Мбит/с конкурируют в общем пуле, и ничто не гарантирует, что на конкретном линке остаётся место именно для голоса. DS-TE (RFC 3564, протокол в RFC 4124) вводит Class-Type (CT0-CT7): независимый учёт резервирования по классам. Туннель сигнализируется объектом CLASSTYPE; head-end считает путь (CSPF) по полосе именно этого CT, а IGP (OSPF-TE/IS-IS-TE) распространяет доступную полосу по каждому TE-class. TE-class - пара (Class-Type, приоритет вытеснения); их не больше восьми на домен. CT0 - обычный трафик и совместимость с не-DS-TE узлами; голос обычно CT1.
Модели ограничения полосы: MAM и RDM
Bandwidth Constraints (BC) определяют, сколько полосы доступно каждому CT. В MAM (Maximum Allocation Model, RFC 4125) каждый CT ограничен собственным BC независимо: CTi <= BCi, сумма BC не превышает максимально резервируемой полосы. MAM изолирует классы без вытеснения, но неиспользованная полоса CT1 остаётся недоступной CT0. В RDM (Russian Dolls Model, RFC 4127) ограничения вложены: CT1 <= BC1, CT0 + CT1 <= BC0, где BC0 равен максимально резервируемой полосе. Неиспользованная полоса CT1 доступна CT0, но для защиты вложенных классов RDM рассчитан на работу с приоритетами вытеснения. RFC 4128 сравнивает модели. Пример для линка 100 Мбит/с, максимум резервирования 90: MAM - BC0 = 80, BC1 = 10; RDM - BC0 = 90, BC1 = 10 (если CT1 не занят, CT0 может занять 90, если занят 10 - CT0 получит 80).
Связка CT1, EF и LLQ
DS-TE - это учёт в плоскости управления: резервация 10 Мбит/с ничего не ограничивает в плоскости данных. Поэтому три значения должны совпадать: BC1 на интерфейсе (10 Мбит/с), скорость приоритетной очереди (LLQ 10%) и число вызовов, которое разрешает SBC (CAC). Если BC1 больше LLQ, DS-TE допустит больше голоса, чем очередь способна обслужить: при перегрузке полисер очереди будет рубить все вызовы в классе сразу, а не отбивать лишние на этапе установки. Head-end должен ставить TC 5 на трафик, идущий в туннель: на Cisco это политика маркировки на ingress PE1, на Junos - class-of-service 5 в параметрах LSP (EXP для всех пакетов LSP). Загнать в туннель нужно только голос: статический маршрут на подсеть голосовых шлюзов или политика на ingress; иначе весь трафик к PE2 уйдёт в туннель на 10 Мбит/с.
Методика проверки
Нужен генератор трафика: iperf3 или TRex. Голос: UDP ~8 Мбит/с с DSCP 46 (iperf3 -u -b 8M -S 0xb8), видео: UDP 30 Мбит/с с DSCP 34 (-S 0x88), данные: TCP/UDP 50 Мбит/с с DSCP 26 (-S 0x68), bulk: 60 Мбит/с с DSCP 0. Суммарно около 150 Мбит/с на 100 Мбит/с shaper. Порядок: 1) без нагрузки - убедиться по счётчикам политики, что TC выставлен (класс L-VOICE считает пакеты); 2) нагрузка выше shaper - голос должен идти без потерь, остальные классы получить не меньше гарантий; 3) выключить классовую политику на выходе PE1 и повторить: потери голоса появятся, и это доказывает, что именно очередь защищала трафик; 4) отказ линка - туннель CT1 пересигнализируется или не находит путь. Для джиттера измеряют разброс интервалов приёма между пакетами UDP (iperf3 сообщает Jitter) и смотрят на захвате DSCP/TC.
Ожидаемые числа
При нагрузке 8 (voice) + 30 (video) + 50 (data) + 60 (bulk) = 148 Мбит/с на 100 Мбит/с: голос получает свои 8 Мбит/с без потерь, оставшиеся 92 Мбит/с делятся так, что видео получает не меньше 20, данные не меньше 30, bulk не меньше 40 (с поправкой в пределах 2 Мбит/с на неиспользованную полосу голоса); потери концентрируются в bulk. После выключения политики потери распределяются между всеми классами пропорционально нагрузке (около 32% при 148 на 100), включая голос.
Типовые отказы
LLQ задан в процентах от физического порта, а parent shaper уже ограничил скорость: 10% от 1 Гбит/с (100 Мбит/с) вместо 10% от 100 Мбит/с, и голос вытесняет всё остальное. Классы на P1 заданы по match dscp, а пакеты уже с метками: очереди на транзите не срабатывают. BC1 больше LLQ: CAC допускает вызовов больше, чем помещается в очередь. Туннель CT1 упал, а статический маршрут исчез: голос ушёл по IGP-пути без гарантий. WRED включён в приоритетном классе. На Short-Pipe egress PE2 нет политики по DSCP: голос на последнем линке попадает в Best Effort. Резервация DS-TE считается идеальной, хотя фактический голос превышает 10 Мбит/с (рост числа вызовов без изменения CT1).
Схема архитектуры и топология
+-------------+ Multi-Service Queue Scheduling (PE Interface) +-------------+
| PE-1 | ==========================================================> | P-1 |
| Service | [LLQ Strict Priority: Voice 10% (EXP 5)] | Linecard |
| Policy In | [CBWFQ Guaranteed: Video 20% (EXP 4) + Data 30% (EXP 3)] | WRED Active |
| Policy Out | [Default Fair-Queue: Best Effort 40% (EXP 0) with WRED] | Core Queue |
+-------------+ +-------------+Схема прохождения трафика и стек меток
Hardware Linecard Queuing Pipeline:
1. Packet arrives with MPLS TC=5 ---> Directed to Strict Priority LLQ (Serviced first, low latency).
2. Packets with TC=3..4 ---> Serviced via Deficit Weighted Round Robin (DWRR) proportional to allocated bandwidth.
3. Best-Effort (TC=0) ---> Enters default queue governed by Weighted Random Early Detection (WRED).
4. If interface saturates, WRED preemptively drops TCP Best-Effort to prevent global synchronization.