QoS per tunnel begränsar inte din hubs totala uplink

Tron låter som aritmetik: fem spokes, var och en formad till 5 Mbit/s, så hubben bär högst 25 Mbit/s. Den första hälften är sann och slutsatsen inte. En policy per tunnel tillämpas en gång per tunnel, inte en gång per hubb, och den delade uplink som alla fem tunnlarna korsar förekommer aldrig i den beräkningen. Överbelastningen på uplinken överlever precis som den var.

Varifrån tron kommer

Förvirringen är begriplig, eftersom NHRP-gruppinformation låter en enda policydefinition gälla för en hel uppsättning spokes. Det läses som en delad budget i en konfigurationsfil. Vad det faktiskt betyder är att varje spoke får sin egen instans av den definitionen.

Så 5 Mbit/s per spoke är ett tak per tunnel, och det finns lika många tak som det finns tunnlar.

Vad en policyinstans styr

Ciscos guide till QoS per tunnel i DMVPN på IOS XE beskriver en hubb-utgångspolicy som väljs via NHRP-gruppinformation och tillämpas separat på varje spoke. Två gränser följer av den meningen, och båda ignoreras. Hastigheten tillhör en enda spoke och inte en delad hink, och funktionen styr trafik från hubben till spoken, inte tvärtom.

Planera spokens sändningsriktning självständigt. Inget i en hubb-utgångspolicy begränsar vad en filial laddar upp.

Sätt den samlade gränsen vid den delade flaskhalsen

Aggregatet måste formas där det faktiskt konkurrerar: på det fysiska gränssnittet som alla tunnlar delar. Cisco dokumenterar en class-default-shaper på det fysiska gränssnittet som den stödda samtidiga fysiska policyn för den här funktionen, vilket är ett snävare påstående än någon hierarki du kan skriva in. Anta att den godtyckliga andra fysiska policy du hittade på inte stöds förrän någon bevisar motsatsen.

Bestäm sedan vad som händer när alla spokes är upptagna samtidigt. Vilken trafik som släpps in, vilken klass som prioriteras och vilken kö som äger konkurrensen. Ett tak per spoke svarar inte på någon av de frågorna, eftersom varje spoke betraktas för sig.

Anpassa formningsenheter och overheadredovisning till den faktiska överlämningen. Encapsulation-overhead som du lämnar utanför hastighetsberäkningen visar sig som en länk som mättas före det konfigurerade talet.

Räknare ljuger på ett särskilt sätt

Läs räknare på det lager du formar. Samma Cisco-guide varnar för att policyräknare för huvudgränssnittet kan vara felaktiga i den här uppställningen. Det är en reservation om räknaren, inte bevis för att en klass matchar eller släpper. Håll det åtskilt från applikationsresultatet, som är det enda användaren upplever.

Att kopiera ett gammalt traffic-shape-exempel bredvid en orelaterad policytabell bevisar inte att de två hastigheterna styr samma paket.

Testa aggregatet, inte bara taket

Börja med en upptagen spoke och bekräfta att den når sitt tak. Erbjud sedan trafik från alla samtidigt enligt en godkänd plan, och följ det fysiska gränssnittet bredvid siffrorna per tunnel. Om varje spoke sitter på sitt tak medan uplinken är full och fördröjningen stiger, fungerar policyn per spoke exakt som designat och budgeten är fortfarande fel.

Rättelsen vid den punkten är ett kapacitets- eller tillträdesbeslut. Att finjustera siffrorna per spoke ändrar bara vilken filial som klagar först.