QoS na jednotlivých tunelech neomezuje celkový uplink vašeho hubu

Přesvědčení zní jako aritmetika: pět spoků, každý omezený na 5 Mbit/s, takže hub přenáší nejvýš 25 Mbit/s. První polovina je pravdivá, závěr ne. Politika na jednotlivé tunely se uplatňuje jednou na tunel, ne jednou na hub, a sdílený uplink, kterým prochází všech pět tunelů, se v tom výpočtu nikdy neobjeví. Přetížení na uplinku přetrvává přesně tak, jak bylo.

Odkud přesvědčení pochází

Zmatek je pochopitelný, protože informace o skupině NHRP umožňuje jedné definici politiky platit pro celou sadu spoků. To se čte jako sdílený rozpočet v konfiguračním souboru. Ve skutečnosti to znamená, že každý spok dostane svou vlastní instanci této definice.

Takže 5 Mbit/s na spok je strop na tunel a stropů je tolik, kolik je tunelů.

Co řídí jedna instance politiky

Průvodce Cisco QoS na jednotlivých tunelech DMVPN v IOS XE popisuje výstupní politiku hubu vybíranou pomocí informací o skupině NHRP a uplatňovanou zvlášť na každý spok. Z této věty plynou dvě omezení a obě se ignorují. Rychlost patří jednomu spoku, nikoli sdílenému vědru, a funkce řídí provoz z hubu ke spoku, ne naopak.

Plánujte směr odesílání spoku nezávisle. Nic ve výstupní politice hubu neomezuje to, co pobočka nahraje.

Umístěte souhrnný limit na sdílené hrdlo

Souhrn musí být tvarován tam, kde skutečně soutěží: na fyzickém rozhraní, které všechny tunely sdílejí. Cisco dokumentuje class-default shaper na fyzickém rozhraní jako podporovanou souběžnou fyzickou politiku pro tuto funkci, což je užší tvrzení než jakákoli hierarchie, kterou můžete napsat. Předpokládejte, že libovolná druhá fyzická politika, kterou jste vymysleli, není podporovaná, dokud někdo neprokáže opak.

Pak rozhodněte, co se stane, když jsou všechny spoky zaneprázdněné najednou. Který provoz se propustí, která třída má prioritu a která fronta vlastní soupeření. Strop na spok neodpovídá na žádnou z těchto otázek, protože každý spok se posuzuje samostatně.

Sladťte jednotky tvarování a účtování režie se skutečným předáním. Režie zapouzdření, kterou necháte mimo výpočet rychlosti, se projeví jako linka, která se nasytí dřív než nastavené číslo.

Počítadla lžou jedním konkrétním způsobem

Čtěte počítadla na vrstvě, kterou tvarujete. Stejný průvodce Cisco varuje, že počítadla politiky hlavního rozhraní mohou být v tomto uspořádání nepřesná. To je výhrada k počítadlu, nikoli důkaz, že třída odpovídá nebo zahazuje. Držte to odděleně od výsledku aplikace, což je jediné, co uživatel pocítí.

Kopírování starého příkladu traffic-shape vedle nesouvisející mapy politiky neprokazuje, že obě rychlosti řídí stejné pakety.

Testujte souhrn, ne jen strop

Začněte jedním zaneprázdněným spokem a ověřte, že dosáhne svého stropu. Pak nabídněte provoz ze všech najednou podle schváleného plánu a sledujte fyzické rozhraní vedle čísel na jednotlivých tunelech. Pokud každý spok sedí na svém stropu, zatímco uplink je na doraz a zpoždění roste, politika na spok funguje přesně tak, jak byla navržena, a rozpočet je stále špatný.

Oprava v tom okamžiku je rozhodnutí o kapacitě nebo o přijetí. Ladění čísel na spok mění jen to, která pobočka si stěžuje první.