QoS pr. tunnel begrænser ikke din hubs samlede uplink

Troen lyder som aritmetik: fem spokes, hver formet til 5 Mbit/s, så huben bærer højst 25 Mbit/s. Den første halvdel er sand, og konklusionen er ikke. En politik pr. tunnel anvendes én gang pr. tunnel, ikke én gang pr. hub, og den fælles uplink, som alle fem tunneler krydser, optræder aldrig i den beregning. Overbelastningen på uplinken overlever præcis som den var.

Hvor troen kommer fra

Forvirringen er forståelig, fordi NHRP-gruppeoplysninger lader én politikdefinition gælde for et helt sæt spokes. Det læses som et fælles budget i en konfigurationsfil. Hvad det faktisk betyder, er at hver spoke får sin egen instans af den definition.

Så 5 Mbit/s pr. spoke er et loft pr. tunnel, og der er lige så mange lofter som der er tunneler.

Hvad én politikinstans styrer

Ciscos guide til QoS pr. tunnel i DMVPN på IOS XE beskriver en hub-udgangspolitik, der vælges via NHRP-gruppeoplysninger og anvendes separat på hver spoke. To grænser følger af den sætning, og begge ignoreres. Hastigheden tilhører én spoke og ikke en fælles spand, og funktionen styrer trafik fra huben til spoken, ikke omvendt.

Planlæg spokens sendretning uafhængigt. Intet i en hub-udgangspolitik begrænser, hvad en filial uploader.

Læg den samlede grænse ved den fælles flaskehals

Det samlede trafik skal formes der, hvor det faktisk konkurrerer: på det fysiske interface, som alle tunneler deler. Cisco dokumenterer en class-default-shaper på det fysiske interface som den understøttede samtidige fysiske politik for denne funktion, hvilket er en snævrere udtalelse end enhver hierarki, du kan skrive. Antag, at den vilkårlige anden fysiske politik, du fandt på, ikke understøttes, indtil nogen beviser det modsatte.

Beslut derefter, hvad der sker, når alle spokes er travle på én gang. Hvilken trafik lukkes ind, hvilken klasse prioriteres, og hvilken kø der ejer konkurrencen. Et loft pr. spoke besvarer ingen af de spørgsmål, fordi hver spoke betragtes alene.

Tilpas formningsenheder og overheadregnskab til den faktiske overdragelse. Encapsulation-overhead, som du udelader af hastighedsberegningen, viser sig som et link, der mættes før det konfigurerede tal.

Tællere lyver på én bestemt måde

Læs tællere på det lag, du former. Den samme Cisco-guide advarer om, at politikttællere på hovedinterfacet kan være unøjagtige i dette arrangement. Det er et forbehold om tælleren, ikke bevis for at en klasse matcher eller dropper. Hold det adskilt fra applikationsresultatet, som er det eneste, brugeren oplever.

At kopiere et gammelt traffic-shape-eksempel ved siden af et urelateret politikmap beviser ikke, at de to hastigheder styrer de samme pakker.

Test det samlede trafik, ikke kun loftet

Start med én travl spoke og bekræft, at den når sit loft. Tilbyd derefter trafik fra dem alle på én gang under en godkendt plan, og hold øje med det fysiske interface ved siden af tallene pr. tunnel. Hvis hver spoke står på sit loft, mens uplinken er fastlåst og forsinkelsen stiger, virker politikken pr. spoke præcis som designet, og budgettet er stadig forkert.

Rettelsen på det tidspunkt er en kapacitets- eller adgangsbeslutning. At finjustere tallene pr. spoke ændrer kun, hvilken filial der klager først.