QoS na posamezen tunel ne omejuje skupnega uplinka vašega huba

To prepričanje zveni kot aritmetika: pet spokeov, vsak oblikovan na 5 Mbit/s, zato hub prenaša največ 25 Mbit/s. Prva polovica drži, sklep pa ne. Politika na posamezen tunel se uporabi enkrat na tunel, ne enkrat na hub, in skupni uplink, skozi katerega gredo vsi pet tunelov, se v tem izračunu nikoli ne pojavi. Zamašenost na uplinku ostane natanko taka, kot je bila.

Od kod prepričanje

Zmeda je razumljiva, ker informacije o skupini NHRP omogočajo, da ena definicija politike velja za cel niz spokeov. To se bere kot skupni proračun v konfiguracijski datoteki. V resnici to pomeni, da vsak spoke dobi svojo lastno instanco te definicije.

Torej je 5 Mbit/s na spoke zgornja meja na tunel, in mej je toliko, kolikor je tunelov.

Kaj nadzoruje ena instanca politike

Ciscov vodnik za QoS na posamezen tunel v DMVPN na IOS XE opisuje izhodno politiko huba, izbrano z informacijami o skupini NHRP in uporabljeno ločeno na vsakem spokeu. Iz tega stavka izhajata dve omejitvi in obe se ignorirata. Hitrost pripada enemu spokeu in ne skupnemu vedru, funkcija pa upravlja promet od huba proti spokeu, ne obratno.

Načrtujte smer pošiljanja spokea neodvisno. Nič v izhodni politiki huba ne omejuje tega, kar podružnica naloži.

Skupno omejitev postavite na skupno ozko grlo

Skupna količina mora biti oblikovana tam, kjer se resnično poteguje: na fizičnem vmesniku, ki si ga delijo vsi tuneli. Cisco dokumentira class-default shaper na fizičnem vmesniku kot podprto sočasno fizično politiko za to funkcijo, kar je ožja trditev od katere koli hierarhije, ki jo lahko vnesete. Predpostavite, da poljubna druga fizička politika, ki ste si jo izmislili, ni podprta, dokler nekdo ne dokaže nasprotnega.

Nato odločite, kaj se zgodi, ko so vsi spokei hkrati zasedeni. Kateri promet je sprejet, kateri razred ima prednost in katera čakalna vrsta ima tekmovanje. Zgornja meja na spoke ne odgovori na nobeno od teh vprašanj, ker se vsak spoke obravnava posebej.

Uskladite enote oblikovanja in obračun dodatnih stroškov z dejansko predajo. Dodatni stroški inkapsulacije, ki jih pustite zunaj izračuna hitrosti, se pokažejo kot povezava, ki se nasiči pred nastavljeno številko.

Števci lažejo na en določen način

Berite števce na plasti, ki jo oblikujete. Isti Ciscov vodnik opozarja, da so števci politike glavnega vmesnika v tej postavitvi lahko netočni. To je pridržek glede števca, ne dokaz, da se razred ujema ali zavrača. Hranite to ločeno od rezultata aplikacije, ki je edino, kar uporabnik občuti.

Kopiranje starega primera traffic-shape poleg nepovezanega zemljevida politike ne dokazuje, da obe hitrosti nadzorujeta iste pakete.

Preizkusite skupno količino, ne le zgornje meje

Začnite z enim zasedenim spokeom in potrdite, da doseže svojo zgornjo mejo. Nato ponudite promet z vseh hkrati po odobrenem načrtu in opazujte fizični vmesnik ob številkah na posamezen tunel. Če vsak spoke sedi na svoji meji, medtem ko je uplink zamašen in zakasnitev raste, politika na spoke deluje natanko tako, kot je bila zasnovana, in proračun je še vedno napačen.

Popravek na tej točki je odločitev o zmogljivosti ali o sprejemu. Ponovno nastavljanje številk na spoke spremeni le, katera podružnica se pritoži prva.