QoS за всеки тунел не ограничава общия ъплинк на вашия хъб

Вярването звучи като аритметика: пет спока, всеки оформен до 5 Mbit/s, значи хъбът носи най-много 25 Mbit/s. Първата половина е вярна, а заключението не е. Политиката за всеки тунел се прилага веднъж на тунел, не веднъж на хъб, и споделеният ъплинк, през който минават всичките пет тунела, никога не се появява в това изчисление. Задръстването на ъплинка остава точно каквото беше.

Откъде идва вярването

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

Така 5 Mbit/s на спок е таван за всеки тунел и има толкова тавани, колкото са тунелите.

Какво контролира един екземпляр на политика

Ръководството на Cisco за QoS за всеки тунел в DMVPN при IOS XE описва политика за изход от хъба, избрана чрез информация за група NHRP и прилагана отделно към всеки спок. От това изречение следват две ограничения и двете се пренебрегват. Скоростта принадлежи на един спок, а не на споделена кофа, и функцията управлява трафика от хъба към спока, а не обратното.

Планирайте посоката на изпращане от спока независимо. Нищо в политиката за изход от хъба не ограничава това, което клонът качва.

Поставете общото ограничение при споделеното тясно място

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

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

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

Броячите лъжат по един специфичен начин

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

Копирането на стар пример за traffic-shape до несвързана карта на политика не доказва, че двете скорости управляват едни и същи пакети.

Тествайте общия обем, не само тавана

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

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