Az alagútonkénti QoS nem korlátozza a hub teljes uplinkjét

A hit számítanak tűnik: öt spoke, mindegyik 5 Mbit/s-ra alakítva, tehát a hub legfeljebb 25 Mbit/s-ot visz. Az első fele igaz, a következtetés nem. Az alagútonkénti szabályzat alagútonként egyszer érvényesül, nem hubonként egyszer, és a közös uplink, amelyen mind az öt alagút átmegy, soha nem jelenik meg ebben a számításban. Az uplink torlódása pontosan úgy marad, ahogy volt.

Honnan jön a hit

A zavar érthető, mert az NHRP-csoportinformáció lehetővé teszi, hogy egy szabályzatdefiníció spoke-ok egész csoportjára vonatkozzon. Ez úgy olvasható, mint egy közös büdzsé a konfigurációs fájlban. Valójában azt jelenti, hogy minden spoke megkapja a saját példányát annak a definíciónak.

Tehát az 5 Mbit/s spoke-onként alagútonkénti plafon, és annyi plafon van, ahány alagút.

Mit vezérel egy szabályzatpéldány

A Cisco alagútonkénti QoS-útmutatója a DMVPN-hez IOS XE-n egy hub-kilépési szabályzatot ír le, amelyet az NHRP-csoportinformáció választ ki, és amely minden spoke-ra külön érvényesül. Ebből a mondatból két korlát következik, és mindkettőt figyelmen kívül hagyják. A sebesség egy spoke-hoz tartozik, nem egy közös vödörhöz, és a funkció a hubtól a spoke felé irányuló forgalmat szabályozza, nem fordítva.

Tervezze meg a spoke küldési irányát önállóan. A hub-kilépési szabályzatban semmi nem korlátozza, mit tölt fel egy fióktelep.

A teljes korlátot a közös szűk keresztmetszethez tegye

Az összesített forgalmat ott kell alakítani, ahol valóban versenyez: azon a fizikai interfészen, amelyet minden alagút megoszt. A Cisco class-default shaperként dokumentálja a fizikai interfészen a funkció által támogatott egyidejű fizikai szabályzatot, ami szűkebb állítás minden beírható hierarchiánál. Feltételezze, hogy az ön által kitalált önkényes második fizikai szabályzat nem támogatott, amíg valaki az ellenkezőjét be nem bizonyítja.

Ezután döntse el, mi történik, amikor minden spoke egyszerre foglalt. Melyik forgalom jut be, melyik osztály kap prioritást, és melyik sor birtokolja a versenyt. A spoke-onkénti plafon egyik kérdésre sem válaszol, mert minden spoke-ot külön vizsgálnak.

Igazítsa az alakítási egységeket és a többletelszámolást a tényleges átadáshoz. A sebességszámításból kihagyott csomagolási többlet olyan kapcsolatként jelenik meg, amely a beállított szám előtt telítődik.

A számlálók egy meghatározott módon hazudnak

A számlálókat azon a rétegen olvassa, amelyet alakít. Ugyanez a Cisco-útmutató figyelmeztet, hogy a fő interfész szabályzatszámlálói ebben az elrendezésben pontatlanok lehetnek. Ez a számlálóra vonatkozó fenntartás, nem bizonyíték arra, hogy egy osztály illeszkedik vagy elvet. Tartsa ezt külön az alkalmazás eredményétől, ami az egyetlen dolog, amit a felhasználó tapasztal.

Egy régi traffic-shape példa egy független házirend-térkép mellé másolása nem bizonyítja, hogy a két sebesség ugyanazokat a csomagokat szabályozza.

Az összesített forgalmat tesztelje, ne csak a plafont

Kezdje egy foglalt spoke-pal, és erősítse meg, hogy eléri a plafonját. Ezután kínáljon forgalmat mindegyiktől egyszerre egy jóváhagyott terv szerint, és figyelje a fizikai interfészt az alagútonkénti számok mellett. Ha minden spoke a plafonján ül, miközben az uplink telített és a késleltetés nő, a spoke-onkénti szabályzat pontosan úgy működik, ahogy tervezték, és a büdzsé továbbra is hibás.

A javítás ezen a ponton kapacitás- vagy beengedési döntés. A spoke-onkénti számok újrahangolása csak azt változtatja meg, melyik fióktelep panaszkodik először.