QoS per tunnel avgrensar ikkje den samla uplinken til huben din

Trua høyrest ut som aritmetikk: fem spokes, kvar forma til 5 Mbit/s, så huben ber høgst 25 Mbit/s. Den første halvdelen er sann, og konklusjonen er det ikkje. Ein politikk per tunnel vert brukt éin gong per tunnel, ikkje éin gong per hub, og den delte uplinken som alle fem tunnelane kryssar, viser seg aldri i den utrekninga. Overbelastninga på uplinken overlever nøyaktig som ho var.

Kvar trua kjem frå

Forvirringa er forståeleg, fordi NHRP-gruppeinformasjon lèt éin politikkdefinisjon gjelde for eit heilt sett med spokes. Det vert lese som eit delt budsjett i ei konfigurasjonsfil. Det det faktisk tyder, er at kvar spoke får sin eigen instans av den definisjonen.

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

Kva éin politikkinstans styrer

Cisco sin rettleiar for QoS per tunnel i DMVPN på IOS XE skildrar ein hub-utgangspolitikk som vert vald via NHRP-gruppeinformasjon og brukt separat på kvar spoke. To grenser følgjer av den setninga, og begge vert ignorerte. Ratene høyrer til éin spoke og ikkje ei delt bøtte, og funksjonen styrer trafikk frå huben til spoken, ikkje motsett veg.

Planlegg sendingsretninga til spoken sjølvstendig. Ingenting i ein hub-utgangspolitikk avgrensar det ei filial lastar opp.

Set den samla grensa ved den delte flaskehalsen

Aggregatet må formast der det faktisk konkurrerer: på det fysiske grensesnittet alle tunnelane deler. Cisco dokumenterer ein class-default shaper på det fysiske grensesnittet som den støtta samtidige fysiske politikken for denne funksjonen, noko som er ei snevrare utsegn enn noko hierarki du kan skrive inn. Gå ut frå at den vilkårlege andre fysiske politikken du fann opp, ikkje er støtta før nokon provar det motsette.

Avgjer så kva som skjer når alle spokane er opptekne samtidig. Kva trafikk som slepp inn, kva klasse som får prioritet, og kva kø som eig konkurransen. Eit tak per spoke svarar på ingen av desse spørsmåla, fordi kvar spoke vert vurdert åleine.

Tilpass formingseningar og overhead-rekneskap til den faktiske overleveringa. Encapsulation-overhead som du utelèt frå hastigheitsutrekninga, viser seg som ei lenkje som mettast før det konfigurerte talet.

Teljarar lyg på éin bestemt måte

Les teljarar på laget du formar. Den same Cisco-rettleiaren åtvarar om at politikkteljarar for hovudgrensesnittet kan vere unøyaktige i dette oppsettet. Det er eit atterhald om teljaren, ikkje prov for at ein klasse passar eller droppar. Hald det åtskilt frå applikasjonsresultatet, som er det einaste brukaren opplever.

Å kopiere eit gammalt traffic-shape-døme ved sida av eit urelatert policykart provar ikkje at dei to ratene styrer dei same pakkane.

Test aggregatet, ikkje berre taket

Start med éin opptatt spoke og stadfest at han når taket sitt. Tilby deretter trafikk frå alle samtidig under ein godkjend plan, og følg med på det fysiske grensesnittet ved sida av tala per tunnel. Viss kvar spoke sit på taket sitt medan uplinken er fastlåst og forseinkinga stig, verkar politikken per spoke nøyaktig som designa, og budsjettet er framleis feil.

Rettinga på det punktet er ei kapasitets- eller tilgangsavgjerd. Å finjustere tala per spoke endrar berre kva filial som klagar først.