QoS per tonnel beperk nie jou hub se totale opstroom nie

Die oortuiging klink soos rekenkunde: vyf spoke wat elkeen tot 5 Mbit/s gevorm word, dus dra die hub hoogstens 25 Mbit/s. Die eerste helfte is waar en die gevolgtrekking is nie. 'n Beleid per tonnel word een keer per tonnel toegepas, nie een keer per hub nie, en die gedeelde opstroom waardeur al vyf tonnels kruis, verskyn nooit in daardie berekening nie. Oorlading op die opstroom oorleef presies soos dit was.

Waar die oortuiging vandaan kom

Die verwarring is verstaanbaar, want NHRP-groepinligting laat een beleidsdefinisie op 'n hele stel spoke van toepassing word. Dit lees soos 'n gedeelde begroting in 'n konfigurasielêer. Wat dit werklik beteken, is dat elke spoke sy eie instansie van daardie definisie kry.

Dus is 5 Mbit/s per spoke 'n plafon per tonnel, en daar is soveel plafonne as wat daar tonnels is.

Wat een beleidsinstansie beheer

Cisco se QoS-gids per tonnel vir DMVPN in IOS XE beskryf 'n hub-uitgangsbeleid wat deur NHRP-groepinligting gekies en afsonderlik op elke spoke toegepas word. Twee beperkings volg uit daardie sin, en albei word geïgnoreer. Die tempo behoort aan een spoke eerder as aan 'n gedeelde emmer, en die funksie beheer verkeer van die hub na die spoke, nie omgekeerd nie.

Beplan die spoke se stuurrigting afsonderlik. Niks in 'n hub-uitgangsbeleid beperk wat 'n tak opstuur nie.

Plaas die totale beperking by die gedeelde knelpunt

Die totaal moet gevorm word waar die totaal werklik meeding: die fisiese koppelvlak wat al die tonnels deel. Cisco dokumenteer 'n class-default-vormer op die fisiese koppelvlak as die ondersteunde gelyktydige fisiese beleid vir hierdie funksie, wat 'n nouer stelling is as elke hiërargie wat jy kan tik. Aanvaar dat die willekeurige tweede fisiese beleid wat jy uitgedink het, nie ondersteun word nie totdat iemand anders bewys.

Besluit dan wat gebeur wanneer elke spoke gelyktydig besig is. Watter verkeer word toegelaat, watter klas kry prioriteit, en watter tou besit die mededinging. 'n Plafon per spoke beantwoord nie een van daardie vrae nie, want elke spoke word afsonderlik beskou.

Pas vormeenhede en oorhoofberekening by die werklike oorhandiging aan. Oorhoof van inkapseling wat jy uit die tempoberekening laat, wys as 'n skakel wat versadig raak voordat die gekonfigureerde getal bereik word.

Tellers lieg op een spesifieke manier

Lees tellers op die laag wat jy vorm. Dieselfde Cisco-gids waarsku dat hoofkoppelvlak-beleidstellers in hierdie opset onakkuraat kan wees. Dit is 'n voorbehoud oor die teller, nie bewys dat 'n klas pas of laat val nie. Hou dit apart van die toepassingsresultaat, wat die enigste ding is wat die gebruiker ervaar.

Om 'n ou traffic-shape-voorbeeld langs 'n onverwante beleidskaart te kopieer, bewys nie dat die twee tempos dieselfde pakkette beheer nie.

Toets die totaal, nie net die plafon nie

Begin met een besige spoke en bevestig dat dit sy plafon bereik. Bied dan verkeer van almal gelyktydig aan onder 'n goedgekeurde plan, en kyk na die fisiese koppelvlak langs die per-tonnel-getalle. As elke spoke op sy plafon sit terwyl die opstroom vasgepen is en vertraging styg, werk die beleid per spoke presies soos ontwerp en is die begroting steeds verkeerd.

Die oplossing op daardie punt is 'n kapasiteit- of toelatingsbesluit. Om die getalle per spoke weer in te stel, verander net watter tak eerste kla.