DSCP маркиране или обещание за QoS от доставчика? Нито едното не е договор

Нещо се маркира, конфигурира се опашка и после някой пита какво качество всъщност гарантира дизайнът. Честният отговор е, че сте описали две половини на договор, които се срещат на граница. Докато не можете да назовете класа, който доставчикът приема, и обработката, която прилага, локалната конфигурация е намерение, а не обещание. Двете половини са важни и нито една не може да бъде изведена от другата.

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

Къде правилното маркиране може тихо да умре

Започнете, като за всяко натоварване запишете локалното условие за съвпадение, всяко маркиране, което се случва в тунел, стойността, която доставчикът приема, и класа на услугата, който тази стойност избира. Четири колони, а отказите обикновено живеят между втората и третата.

Поведението на маркиране от вътрешна към външна заглавка е класическият проблем. Пакетът в криптиран или тунелен път носи вътрешна заглавка, която вашият класификатор вижда, и външна заглавка, която оборудването на доставчика вижда, а копирането на едната в другата е решение за конфигурация, а не автоматично свойство. Маркирайте само вътрешната заглавка и доставчикът класифицира външната, обикновено като подразбираща се, поради което правилно маркиран поток може да пристигне в грешен клас без нито един погрешно конфигуриран ред от ваша страна.

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

Решете изрично къде се доверяваме на маркирането. Повишаването на всичко, което споделя тунел, повишава и масовите трансфери заедно с разговорите, а доставчик, който приема вашето маркиране без валидация, ви предлага начин да си навредите. Ако договорът позволява на шлюза да премаркира при предаването, запишете го писмено, защото точно в тази точка допусканията на два екипа обикновено се разминават.

Какво всъщност разделя планировчикът

Локалната политика има своя семантика и най-много недоразумения предизвиква думата “remaining”. На платформите, описани в ръководството за планиране на IOS XE, bandwidth remaining percent задава излишно тегло, а не стъпка в последователност, в която всеки клас взема дял от това, което предишният клас е оставил. Неразпределените проценти се разпръскват между подходящи неконфигурирани опашки, вместо да се запазват за последния клас във файла.

Това разграничение е важно, защото последователният мисловен модел дава прогнози, които никога не съвпадат с броячите. Инженерите пренареждат класовете, за да променят резултат, не виждат разлика и заключават, че платформата е счупена, а конфигурацията никога не е означавала това, което са предполагали.

Родителският шейпър е другата честа изненада. Ограничаването на контролирана опашка до използваемата скорост на услугата често е умишлено, защото премества точката на задръстване на устройство, което вие администрирате, вместо нагоре по веригата опашка, която не администрирате. Премахването на шейпъра, защото шейпингът добавя закъснение, може да премести загубата, а не да я премахне, а отчитането на разходите или полицейският механизъм на доставчика могат да направят ефективната скорост по-ниска от тази, която интерфейсът подсказва.

Броячите показват коя половина е отказала

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

Разклоненията са различни проблеми с различни собственици. Локален клас, който не съвпада с нищо, е грешка в класификацията от ваша страна. Клас, който съвпада, се подрежда и изпуска, докато доставчикът съобщава за чисто доставяне, сочи към вашия собствен планировчик или шейпър. Клас, който изглежда правилен локално, докато загубата се появява отвъд предаването, сочи към съпоставянето на оператора и измерената граница в договора. Нито един от трите не се оправя чрез редактиране на другите, поради което числата трябва да се събират заедно.

RFC 2475 рамкира класификацията и кондиционирането като работа в административни домейни и точно затова маркирането не може да резервира опашки от край до край. Ръководството за планиране на IOS XE е справката за поведението на излишното тегло, описано по-горе, а сравненията му между платформи си струва да се прочетат, преди изчислена скорост да се мести между модели.

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

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

Промяната на локален процент не може да поправи гаранцията на друга опашка и никоя схема за маркиране не оцелява при съпоставяне, което доставчикът не спазва. Сравнете половините, назовете границата и само тогава цитирайте число.