QoS по сваком тунелу не ограничава укупан uplink вашег hub-а

Ово уверење звучи као аритметика: пет spoke-ова, сваки обликован на 5 Mbit/s, па hub носи највише 25 Mbit/s. Прва половина је тачна, а закључак није. Политика по сваком тунелу примењује се једном по тунелу, а не једном по hub-у, и заједнички uplink кроз који пролазе свих пет тунела никада се не појављује у том прорачуну. Загушење на uplink-у остаје тачно какво је било.

Одакле долази ово уверење

Забуна је разумљива, јер информације о NHRP групи омогућавају да једна дефиниција политике важи за цео скуп spoke-ова. То се чита као заједнички буџет у конфигурационој датотеци. Оно што то заправо значи јесте да сваки spoke добија своју сопствену инстанцу те дефиниције.

Дакле, 5 Mbit/s по spoke-у је плафон по тунелу, и плафона има онолико колико има тунела.

Шта контролише једна инстанца политике

Cisco водич за QoS по сваком тунелу у DMVPN-у на IOS XE описује политику излаза из hub-а која се бира преко информација о NHRP групи и примењује засебно на сваки spoke. Из те реченице следе два ограничења и оба се игноришу. Брзина припада једном spoke-у, а не заједничкој канти, и функција управља саобраћајем од hub-а ка spoke-у, а не обрнуто.

Планирајте смер слања spoke-а независно. Ништа у политици излаза из hub-а не ограничава оно што огранак отпрема.

Поставите укупно ограничење на заједничко грло

Укупан саобраћај мора бити обликован тамо где се заиста такмичи: на физичком интерфејсу који сви тунели деле. Cisco документује class-default обликовач на физичком интерфејсу као подржану истовремену физичку политику за ову функцију, што је ужа тврдња од сваке хијерархије коју можете унети. Претпоставите да произвољна друга физичка политика коју сте измислили није подржана док неко не докаже супротно.

Затим одлучите шта се дешава када су сви spoke-ови заузети истовремено. Који саобраћај се прихвата, која класа добија приоритет и који ред чекања поседује надметање. Плафон по spoke-у не одговара ни на једно од тих питања, јер се сваки spoke разматра засебно.

Ускладите јединице обликовања и обрачун додатних трошкова са стварним предавањем. Додатни трошкови инкапсулације које оставите изван прорачуна брзине појављују се као веза која се засити пре конфигурисаног броја.

Бројачи лажу на један одређени начин

Читајте бројаче на слоју који обликујете. Исти Cisco водич упозорава да бројачи политике главног интерфејса могу бити нетачни у овом распореду. То је ограда око бројача, а не доказ да класа одговара или одбацује. Држите то одвојено од резултата апликације, који је једино што корисник доживљава.

Копирање старог примера traffic-shape поред неповезане мапе политике не доказује да две брзине контролишу исте пакете.

Тестирајте укупан саобраћај, не само плафон

Почните са једним заузетим spoke-ом и потврдите да достиже свој плафон. Затим понудите саобраћај са свих истовремено према одобреном плану и посматрајте физички интерфејс поред бројева по тунелу. Ако сваки spoke стоји на свом плафону док је uplink закрчен и кашњење расте, политика по spoke-у ради тачно како је пројектована и буџет је и даље погрешан.

Поправка у том тренутку је одлука о капацитету или о прихватању. Поновно подешавање бројева по spoke-у мења само то која се огранак прва жали.