QoS per tunnel begrenser ikke hubens totale uplink

Troen høres ut som aritmetikk: fem spokes, hver formet til 5 Mbit/s, så huben bærer høyst 25 Mbit/s. Den første halvdelen er sann, og konklusjonen er det ikke. En politikk per tunnel brukes én gang per tunnel, ikke én gang per hub, og den delte uplinken som alle fem tunnelene krysser, vises aldri i den beregningen. Overbelastningen på uplinken overlever nøyaktig som den var.

Hvor troen kommer fra

Forvirringen er forståelig, fordi NHRP-gruppeinformasjon lar én policydefinisjon gjelde for et helt sett med spokes. Det leses som et delt budsjett i en konfigurasjonsfil. Det det faktisk betyr, er at hver spoke får sin egen instans av den definisjonen.

Så 5 Mbit/s per spoke er et tak per tunnel, og det er like mange tak som det er tunneler.

Hva én policyinstans styrer

Ciscos veiledning for QoS per tunnel i DMVPN på IOS XE beskriver en hub-utgangspolicy som velges via NHRP-gruppeinformasjon og brukes separat på hver spoke. To grenser følger av den setningen, og begge ignoreres. Ratene tilhører én spoke og ikke en delt bøtte, og funksjonen styrer trafikk fra huben til spoken, ikke motsatt vei.

Planlegg spokens senderetning uavhengig. Ingenting i en hub-utgangspolicy begrenser det en filial laster opp.

Sett den samlede grensen ved den delte flaskehalsen

Aggregatet må formes der det faktisk konkurrerer: på det fysiske grensesnittet alle tunnelene deler. Cisco dokumenterer en class-default shaper på det fysiske grensesnittet som den støttede samtidige fysiske policyen for denne funksjonen, noe som er en snevrere uttalelse enn noe hierarki du kan skrive inn. Anta at den vilkårlige andre fysiske policyen du fant opp, ikke støttes før noen beviser det motsatte.

Avgjør så hva som skjer når alle spokene er opptatt samtidig. Hvilken trafikk som slippes inn, hvilken klasse som prioriteres, og hvilken kø som eier konkurransen. Et tak per spoke svarer på ingen av disse spørsmålene, fordi hver spoke vurderes alene.

Tilpass formingsenheter og overheadregnskap til den faktiske overleveringen. Encapsulation-overhead som du utelater fra hastighetsberegningen, viser seg som en lenke som mettes før det konfigurerte tallet.

Tellere lyver på én bestemt måte

Les tellere på laget du former. Den samme Cisco-veiledningen advarer om at policytellere for hovedgrensesnittet kan være unøyaktige i dette oppsettet. Det er et forbehold om telleren, ikke bevis for at en klasse matcher eller dropper. Hold det atskilt fra applikasjonsresultatet, som er det eneste brukeren opplever.

Å kopiere et gammelt traffic-shape-eksempel ved siden av et urelatert policykart beviser ikke at de to ratene styrer de samme pakkene.

Test aggregatet, ikke bare taket

Start med én opptatt spoke og bekreft at den når taket sitt. Tilby deretter trafikk fra alle samtidig under en godkjent plan, og følg med på det fysiske grensesnittet ved siden av tallene per tunnel. Hvis hver spoke sitter på taket sitt mens uplinken er fastlåst og forsinkelsen stiger, virker politikken per spoke nøyaktig som designet, og budsjettet er fortsatt feil.

Rettelsen på det punktet er en kapasitets- eller adgangsbeslutning. Å finjustere tallene per spoke endrer bare hvilken filial som klager først.