Маркування DSCP чи обіцянка QoS від провайдера? Ні те ні інше не договір

Щось маркується, черга налаштовується, а потім хтось питає, яку якість дизайн насправді гарантує. Чесна відповідь: ви описали дві половини договору, які зустрічаються на межі. Поки ви не можете назвати клас, який приймає провайдер, і обробку, яку він застосовує, локальна конфігурація є наміром, а не обіцянкою. Обидві половини важливі, і жодна не виводиться з іншої.

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

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

Почніть із того, що для кожного робочого навантаження запишете локальну умову збігу, будь-яке маркування всередині тунелю, значення, яке приймає провайдер, і клас обслуговування, який це значення вибирає. Чотири стовпці, і збої зазвичай живуть між другим і третім.

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

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

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

Що планувальник насправді ділить

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

Ця різниця важлива, бо послідовна розумова модель дає прогнози, які ніколи не збігаються з лічильниками. Інженери переставляють класи, щоб змінити результат, не бачать різниці й роблять висновок, що платформа зламана, хоча конфігурація ніколи не означала того, що вони припускали.

Батьківський шейпер — інша часта несподіванка. Формування керованої черги до корисної швидкості обслуговування часто робиться навмисно, бо воно переносить точку перевантаження на пристрій, яким керуєте ви, а не на вищу чергу, якою ви не керуєте. Видалення шейпера через те, що формування додає затримку, може перенести втрати, а не усунути їх, а облік накладних витрат або поліцейський провайдера можуть зробити ефективну швидкість нижчою, ніж припускає інтерфейс.

Лічильники показують, яка половина відмовила

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

Гілки — це різні проблеми з різними власниками. Локальний клас, який ні з чим не збігається, — помилка класифікації на вашому боці. Клас, який збігається, стає в чергу й відкидає, поки провайдер повідомляє про чисту доставку, вказує на ваш власний планувальник або шейпер. Клас, який локально виглядає правильно, поки втрати з'являються за межами передачі, вказує на відображення оператора та виміряну межу в договорі. Жодна з трьох не виправляється редагуванням інших, тому числа треба збирати разом.

RFC 2475 розглядає класифікацію та кондиціонування як роботу всередині адміністративних доменів, і саме тому маркування не може резервувати черги від краю до краю. Посібник із планування IOS XE — це довідка щодо описаної вище поведінки надлишкової ваги, і його порівняння платформ варто прочитати, перш ніж переносити розраховану швидкість між моделями.

Запишіть договір в одному місці

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

Зміна локального відсотка не може виправити гарантію іншої черги, і жодна схема маркування не виживає за відображення, якого провайдер не дотримується. Порівняйте половини, назвіть межу і лише тоді цитуйте число.