QoS per tunnel begrenst niet de totale uplink van je hub

Het geloof klinkt als rekenkunde: vijf spokes, elk gevormd naar 5 Mbit/s, dus de hub draagt hoogstens 25 Mbit/s. De eerste helft klopt en de conclusie niet. Een beleid per tunnel wordt één keer per tunnel toegepast, niet één keer per hub, en de gedeelde uplink waar alle vijf tunnels doorheen gaan, komt in die berekening nooit voor. De congestie op de uplink blijft precies zoals die was.

Waar het geloof vandaan komt

De verwarring is begrijpelijk, omdat NHRP-groepsinformatie het mogelijk maakt één beleidsdefinitie op een hele set spokes toe te passen. Dat leest als een gedeeld budget in een configuratiebestand. Wat het werkelijk betekent, is dat elke spoke zijn eigen instantie van die definitie krijgt.

Dus 5 Mbit/s per spoke is een plafond per tunnel, en er zijn evenveel plafonds als tunnels.

Wat één beleidsinstantie bestuurt

Cisco's handleiding voor QoS per tunnel in DMVPN op IOS XE beschrijft een hub-uitgangsbeleid dat via NHRP-groepsinformatie wordt gekozen en afzonderlijk op elke spoke wordt toegepast. Uit die zin volgen twee grenzen, en beide worden genegeerd. De snelheid hoort bij één spoke en niet bij een gedeelde emmer, en de functie beheert verkeer van de hub naar de spoke, niet andersom.

Plan de verzendrichting van de spoke onafhankelijk. Niets in een hub-uitgangsbeleid begrenst wat een vestiging uploadt.

Zet de totale limiet bij de gedeelde bottleneck

Het geheel moet gevormd worden waar het echt concurreert: op de fysieke interface die alle tunnels delen. Cisco documenteert een class-default shaper op de fysieke interface als het ondersteunde gelijktijdige fysieke beleid voor deze functie, wat een smaller statement is dan elke hiërarchie die je kunt intypen. Ga ervan uit dat het willekeurige tweede fysieke beleid dat je hebt bedacht niet wordt ondersteund tot iemand het tegendeel bewijst.

Bepaal dan wat er gebeurt als alle spokes tegelijk bezig zijn. Welk verkeer wordt toegelaten, welke klasse krijgt prioriteit en welke wachtrij bezit de strijd. Een plafond per spoke beantwoordt geen van die vragen, omdat elke spoke afzonderlijk wordt bekeken.

Stem vormingseenheden en overheadboekhouding af op de werkelijke overdracht. Encapsulation-overhead die je buiten de snelheidsberekening laat, openbaart zich als een link die verzadigt vóór het geconfigureerde getal.

Tellers liegen op één specifieke manier

Lees tellers op de laag die je vormt. Dezelfde Cisco-handleiding waarschuwt dat beleidstellers van de hoofdinterface in deze opstelling onnauwkeurig kunnen zijn. Dat is een voorbehoud over de teller, geen bewijs dat een klasse overeenkomt of laat vallen. Houd het gescheiden van het applicatieresultaat, dat het enige is wat de gebruiker ervaart.

Een oud traffic-shape-voorbeeld naast een ongerelateerde policy-map kopiëren bewijst niet dat de twee snelheden dezelfde pakketten besturen.

Test het geheel, niet alleen het plafond

Begin met één bezige spoke en bevestig dat die zijn plafond haalt. Bied daarna verkeer van allemaal tegelijk aan volgens een goedgekeurd plan, en kijk naar de fysieke interface naast de cijfers per tunnel. Als elke spoke op zijn plafond zit terwijl de uplink vol zit en de vertraging stijgt, werkt het beleid per spoke precies zoals ontworpen en is het budget nog steeds verkeerd.

De oplossing op dat punt is een capaciteits- of toelatingsbeslissing. De cijfers per spoke bijstellen verandert alleen welke vestiging als eerste klaagt.