QoS po tunelu ne ograničava ukupni uplink vašeg huba

Uvjerenje zvuči kao aritmetika: pet spokeova, svaki oblikovan na 5 Mbit/s, pa hub nosi najviše 25 Mbit/s. Prva polovina je tačna, a zaključak nije. Politika po tunelu primjenjuje se jednom po tunelu, a ne jednom po hubu, i zajednički uplink kroz koji prolazi svih pet tunela nikada se ne pojavljuje u tom proračunu. Zagušenje na uplinku ostaje tačno kakvo je bilo.

Odakle dolazi uvjerenje

Zabuna je razumljiva, jer informacije o NHRP grupi omogućavaju da se jedna definicija politike primijeni na cijeli skup spokeova. To se čita kao zajednički budžet u konfiguracijskoj datoteci. Ono što to zapravo znači jeste da svaki spoke dobija svoju vlastitu instancu te definicije.

Dakle, 5 Mbit/s po spokeu je plafon po tunelu, i ima onoliko plafona koliko ima tunela.

Šta kontroliše jedna instanca politike

Cisco vodič za QoS po tunelu u DMVPN-u na IOS XE opisuje politiku izlaza iz huba koja se bira putem informacija o NHRP grupi i primjenjuje zasebno na svaki spoke. Iz te rečenice slijede dva ograničenja i oba se zanemaruju. Brzina pripada jednom spokeu, a ne zajedničkoj kanti, i funkcija upravlja saobraćajem od huba ka spokeu, a ne obrnuto.

Planirajte smjer slanja spokea nezavisno. Ništa u politici izlaza iz huba ne ograničava ono što ogranak šalje.

Postavite ukupno ograničenje na zajedničko grlo

Ukupan obim mora biti oblikovan tamo gdje se zaista takmiči: na fizičkom interfejsu koji svi tuneli dijele. Cisco dokumentuje class-default oblikovalnik na fizičkom interfejsu kao podržanu istovremenu fizičku politiku za ovu funkciju, što je uža tvrdnja od svake hijerarhije koju možete upisati. Pretpostavite da proizvoljna druga fizička politika koju ste izmislili nije podržana dok neko ne dokaže suprotno.

Zatim odlučite šta se dešava kada su svi spokeovi zauzeti istovremeno. Koji saobraćaj se propušta, koja klasa dobija prioritet i koji red čekanja posjeduje nadmetanje. Plafon po spokeu ne odgovara ni na jedno od tih pitanja, jer se svaki spoke razmatra zasebno.

Uskladite jedinice oblikovanja i obračun troškova sa stvarnim predavanjem. Troškovi enkapsulacije koje ostavite izvan proračuna brzine pojavljuju se kao veza koja se zasićuje prije konfigurisanog broja.

Brojači lažu na jedan specifičan način

Čitajte brojače na sloju koji oblikujete. Isti Cisco vodič upozorava da brojači politike glavnog interfejsa mogu biti netačni u ovakvom rasporedu. To je upozorenje o brojaču, a ne dokaz da klasa odgovara ili odbacuje. Držite to odvojeno od rezultata aplikacije, koji je jedino što korisnik osjeća.

Kopiranje starog primjera traffic-shape pored nepovezane mape politike ne dokazuje da dvije brzine kontrolišu iste pakete.

Testirajte ukupan obim, ne samo plafon

Počnite s jednim zauzetim spokeom i potvrdite da dostiže svoj plafon. Zatim ponudite saobraćaj sa svih istovremeno prema odobrenom planu i gledajte fizički interfejs pored brojeva po tunelu. Ako svaki spoke stoji na svom plafonu dok je uplink zaključan i kašnjenje raste, politika po spokeu radi tačno kako je projektovana, a budžet je i dalje pogrešan.

Popravka u tom trenutku je odluka o kapacitetu ili prihvatanju. Ponovno podešavanje brojeva po spokeu mijenja samo to koja se grana prva žali.