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 само менува која подружница се жали прва.