Маркировка DSCP или обещание QoS от провайдера? Ни то ни другое не договор

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

local match → queue and marking → provider classifier
  → provider treatment → destination

Где правильная маркировка может тихо умереть

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

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

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

Явно решите, где маркировке доверяют. Повышение всего, что делит туннель, повышает и массовые передачи вместе с вызовами, а провайдер, принимающий вашу маркировку без проверки, предлагает вам способ навредить себе. Если договор позволяет шлюзу перемаркировать при передаче, зафиксируйте это письменно, потому что именно в этой точке предположения двух команд обычно расходятся.

Что планировщик на самом деле делит

У локальной политики своя семантика, и больше всего недоразумений вызывает слово “remaining”. На платформах, которые описывает руководство по планированию IOS XE, bandwidth remaining percent задаёт избыточный вес, а не шаг в последовательности, где каждый класс берёт долю от того, что оставил предыдущий. Нераспределённые проценты распределяются по подходящим ненастроенным очередям, а не резервируются для последнего класса в файле.

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

Родительский шейпер — другая частая неожиданность. Формирование управляемой очереди до полезной скорости обслуживания часто делается намеренно, потому что оно переносит точку перегрузки на устройство, которым управляете вы, а не на вышестоящую очередь, которой вы не управляете. Удаление шейпера из-за того, что формирование добавляет задержку, может перенести потери, а не устранить их, а учёт накладных расходов или полицейский провайдера могут сделать эффективную скорость ниже, чем предполагает интерфейс.

Счётчики показывают, какая половина отказала

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

Ветви — это разные проблемы с разными владельцами. Локальный класс, который ни с чем не совпадает, — ошибка классификации на вашей стороне. Класс, который совпадает, встаёт в очередь и отбрасывает, пока провайдер сообщает о чистой доставке, указывает на ваш собственный планировщик или шейпер. Класс, который локально выглядит правильно, пока потери появляются за пределами передачи, указывает на отображение оператора и измеренную границу в договоре. Ни одна из трёх не исправляется редактированием остальных, поэтому числа нужно собирать вместе.

RFC 2475 рассматривает классификацию и кондиционирование как работу внутри административных доменов, и именно поэтому маркировка не может резервировать очереди от края до края. Руководство по планированию IOS XE — это справочник по описанному выше поведению избыточного веса, и его сравнения платформ стоит прочитать, прежде чем переносить рассчитанную скорость между моделями.

Запишите договор в одном месте

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

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