QoS katram tunelim neierobežo jūsu hub kopējo uplink

Šis uzskats izklausās kā aritmētika: pieci spoke, katrs ierobežots līdz 5 Mbit/s, tātad hub pārvada ne vairāk kā 25 Mbit/s. Pirmā puse ir patiesa, bet secinājums nav. Politika katram tunelim tiek piemērota reizi katram tunelim, nevis reizi hub, un kopīgais uplink, pa kuru iet visi pieci tuneļi, šajā aprēķinā nekad neparādās. Uplink pārslodze saglabājas tieši tāda, kāda tā bija.

No kurienes nāk šis uzskats

Apjukums ir saprotams, jo NHRP grupas informācija ļauj vienai politikas definīcijai attiekties uz visu spoke kopu. Tas lasās kā kopīgs budžets konfigurācijas failā. Patiesībā tas nozīmē, ka katrs spoke iegūst savu šīs definīcijas eksemplāru.

Tātad 5 Mbit/s vienam spoke ir griesti katram tunelim, un griestu ir tik, cik ir tuneļu.

Ko kontrolē viens politikas eksemplārs

Cisco QoS katram tunelim DMVPN vidē IOS XE rokasgrāmata apraksta hub izejas politiku, kas tiek izvēlēta pēc NHRP grupas informācijas un piemērota atsevišķi katram spoke. No šī teikuma izriet divi ierobežojumi, un abi tiek ignorēti. Ātrums pieder vienam spoke, nevis kopīgai spainim, un funkcija pārvalda trafiku no hub uz spoke, nevis otrādi.

Plānojiet spoke sūtīšanas virzienu neatkarīgi. Hub izejas politikā nekas neierobežo to, ko filiāle augšupielādē.

Novietojiet kopējo ierobežojumu kopīgajā sašaurinājumā

Kopums ir jāveido tur, kur tas patiešām konkurē: fiziskajā saskarnē, ko dala visi tuneļi. Cisco dokumentē class-default veidotāju fiziskajā saskarnē kā atbalstīto vienlaicīgo fizisko politiku šai funkcijai, kas ir šaurāks apgalvojums nekā jebkura hierarhija, ko varat ievadīt. Pieņemiet, ka patvaļīgā otrā fiziskā politika, ko izgudrojāt, netiek atbalstīta, līdz kāds pierāda pretējo.

Pēc tam izlemiet, kas notiek, kad visi spoke vienlaikus ir aizņemti. Kurš trafiks tiek ielaists, kurai klasei ir prioritāte un kura rinda pārvalda konkurenci. Griesti vienam spoke neatbild ne uz vienu no šiem jautājumiem, jo katrs spoke tiek aplūkots atsevišķi.

Saskaņojiet formēšanas vienības un pieskaitāmo izmaksu uzskaiti ar faktisko nodošanu. Iekapsulēšanas pieskaitāmās izmaksas, ko atstājat ārpus ātruma aprēķina, izpaužas kā saite, kas piesātinās pirms konfigurētā skaitļa.

Skaitītāji melo vienā konkrētā veidā

Lasiet skaitītājus tajā slānī, kuru formējat. Tā pati Cisco rokasgrāmata brīdina, ka galvenās saskarnes politikas skaitītāji šajā izkārtojumā var būt neprecīzi. Tas ir iebildums par skaitītāju, nevis pierādījums, ka klase atbilst vai atmet. Turiet to atsevišķi no lietojumprogrammas rezultāta, kas ir vienīgais, ko lietotājs izjūt.

Vecas traffic-shape parauga kopēšana blakus nesaistītai politikas kartei nepierāda, ka abi ātrumi kontrolē vienas un tās pašas paketes.

Pārbaudiet kopumu, ne tikai griestus

Sāciet ar vienu aizņemtu spoke un apstipriniet, ka tas sasniedz savus griestus. Pēc tam piedāvājiet trafiku no visiem vienlaikus saskaņā ar apstiprinātu plānu un vērojiet fizisko saskarni līdzās skaitļiem katram tunelim. Ja katrs spoke stāv pie saviem griestiem, kamēr uplink ir noslogots un aizkave pieaug, politika vienam spoke darbojas tieši tā, kā projektēta, un budžets joprojām ir nepareizs.

Labojums šajā posmā ir jaudas vai pieņemšanas lēmums. Skaitļu pārregulēšana vienam spoke maina tikai to, kura filiāle sūdzas pirmā.