QoS kiekvienam tuneliui neriboja bendro jūsų hubo uplink

Šis įsitikinimas skamba kaip aritmetika: penki spoke, kiekvienas apribotas iki 5 Mbit/s, taigi hubas perduoda daugiausia 25 Mbit/s. Pirmoji pusė teisinga, o išvada ne. Politika kiekvienam tuneliui taikoma kartą vienam tuneliui, o ne kartą hubui, ir bendras uplink, kuriuo eina visi penki tuneliai, tame skaičiavime niekada neatsiranda. Uplink perkrova išlieka lygiai tokia, kokia buvo.

Iš kur kyla šis įsitikinimas

Sumišimas suprantamas, nes NHRP grupės informacija leidžia vienai politikos apibrėžčiai galioti visam spoke rinkiniui. Tai skaitoma kaip bendras biudžetas konfigūracijos faile. Iš tikrųjų tai reiškia, kad kiekvienas spoke gauna savą tos apibrėžties egzempliorių.

Taigi 5 Mbit/s vienam spoke yra kiekvieno tunelio lubos, o lubų yra tiek, kiek tunelių.

Ką valdo vienas politikos egzempliorius

Cisco QoS kiekvienam tuneliui DMVPN sistemoje IOS XE vadovas aprašo hubo išėjimo politiką, kuri parenkama pagal NHRP grupės informaciją ir taikoma atskirai kiekvienam spoke. Iš šio sakinio išplaukia du apribojimai, ir abu ignoruojami. Sparta priklauso vienam spoke, o ne bendrai statinei, ir funkcija valdo srautą iš hubo į spoke, o ne atvirkščiai.

Planuokite spoke siuntimo kryptį atskirai. Hubo išėjimo politikoje niekas neriboja to, ką filialas įkelia.

Bendrą limitą nustatykite bendrame susiaurėjime

Visuma turi būti formuojama ten, kur ji iš tikrųjų konkuruoja: fizinėje sąsajoje, kurią dalijasi visi tuneliai. Cisco dokumentuoja class-default formuotoją fizinėje sąsajoje kaip palaikomą vienalaikę fizinę politiką šiai funkcijai, o tai siauresnis teiginys nei bet kokia hierarchija, kurią galite įvesti. Laikykite, kad savavališka antroji fizinė politika, kurią sugalvojote, nepalaikoma, kol kas nors neįrodys priešingai.

Tada nuspręskite, kas nutinka, kai visi spoke vienu metu užimti. Kuris srautas įleidžiamas, kuri klasė gauna prioritetą ir kuri eilė valdo konkurenciją. Lubos vienam spoke neatsako nė į vieną iš šių klausimų, nes kiekvienas spoke nagrinėjamas atskirai.

Suderinkite formavimo vienetus ir pridėtinių išlaidų apskaitą su faktiniu perdavimu. Inkapsuliavimo pridėtinės išlaidos, kurias paliekate už spartos skaičiavimo ribų, pasireiškia kaip jungtis, kuri prisisotina anksčiau už sukonfigūruotą skaičių.

Skaitikliai meluoja vienu konkrečiu būdu

Skaitiklius skaitykite tame sluoksnyje, kurį formuojate. Tas pats Cisco vadovas įspėja, kad pagrindinės sąsajos politikos skaitikliai šioje schemoje gali būti netikslūs. Tai išlyga dėl skaitiklio, o ne įrodymas, kad klasė atitinka ar atmeta. Laikykite tai atskirai nuo programos rezultato, kuris yra vienintelis dalykas, kurį naudotojas patiria.

Seno traffic-shape pavyzdžio perkėlimas šalia nesusijusio politikos žemėlapio neįrodo, kad abi spartos valdo tuos pačius paketus.

Tikrinkite visumą, o ne tik lubas

Pradėkite nuo vieno užimto spoke ir patvirtinkite, kad jis pasiekia savo lubas. Tada pasiūlykite srautą iš visų vienu metu pagal patvirtintą planą ir stebėkite fizinę sąsają šalia kiekvieno tunelio skaičių. Jei kiekvienas spoke stovi prie savo lubų, o uplink užkimštas ir vėlinimas auga, politika vienam spoke veikia būtent taip, kaip suprojektuota, o biudžetas vis dar neteisingas.

Pataisymas tame etape yra talpos arba priėmimo sprendimas. Iš naujo derinti skaičius vienam spoke tik pakeičia, kuris filialas skundžiasi pirmas.