Tunnel üzrə QoS hub-ın ümumi uplinkini məhdudlaşdırmır

İnanc arifmetika kimi səslənir: hər biri 5 Mbit/s-ə formalaşdırılan beş spoke, deməli hub ən çoxu 25 Mbit/s daşıyır. Birinci yarısı doğrudur, nəticə isə deyil. Tunnel üzrə siyasət hər tunnel üçün bir dəfə tətbiq olunur, hub üçün bir dəfə deyil və beş tunnelin hamısının keçdiyi ortaq uplink o hesablamada heç vaxt görünmür. Uplinkdəki tıxac olduğu kimi qalır.

İnanc haradan gəlir

Qarışıqlıq başa düşüləndir, çünki NHRP qrup məlumatı bir siyasət tərifinin bütöv bir spoke dəstinə tətbiq olunmasına imkan verir. Bu, konfiqurasiya faylında ortaq büdcə kimi oxunur. Əslində isə bu, hər spokun həmin tərifin öz nüsxəsini alması deməkdir.

Beləliklə, hər spoke üçün 5 Mbit/s tunnel üzrə tavan deməkdir və nə qədər tunnel varsa, o qədər tavan var.

Bir siyasət nüsxəsi nəyə nəzarət edir

Cisco-nun IOS XE üçün tunnel üzrə DMVPN QoS təlimatı NHRP qrup məlumatı ilə seçilən və hər spoka ayrıca tətbiq olunan hub çıxış siyasətini təsvir edir. Bu cümlədən iki məhdudiyyət irəli gəlir və hər ikisi gözardı edilir. Sürət ortaq vedrəyə deyil, bir spoka aiddir və funksiya hubdan spoka trafiki idarə edir, tərsini yox.

Spokun göndərmə istiqamətini ayrıca planlayın. Hub çıxış siyasətində heç nə filialın yüklədiyini məhdudlaşdırmır.

Ümumi limiti ortaq darboğaza qoyun

Ümumi həcm əslində rəqabət etdiyi yerdə formalaşdırılmalıdır: bütün tunellərin paylaşdığı fiziki interfeys. Cisco fiziki interfeysdə class-default şəklləndiricisini bu funksiya üçün dəstəklənən eyni vaxtlı fiziki siyasət kimi sənədləşdirir; bu, yaza biləcəyiniz hər iyerarxiyadan daha dar bir ifadədir. Uydurduğunuz ixtiyari ikinci fiziki siyasətin kimsə əksini sübut edənə qədər dəstəklənmədiyini fərz edin.

Sonra bütün spoklar eyni anda məşğul olduqda nə baş verdiyinə qərar verin. Hansı trafik qəbul edilir, hansı sinif prioritet alır və hansı növbə mübahisəyə sahibdir. Spok üzrə tavan bu sualların heç birinə cavab vermir, çünki hər spok tək-tək nəzərdən keçirilir.

Şəklləndirmə vahidlərini və overhead uçotunu real ötürməyə uyğunlaşdırın. Sürət hesablamasından çıxardığınız inkapsulyasiya overhead-i konfiqurasiya olunan rəqəmdən əvvəl doyan link kimi üzə çıxır.

Sayğaclar bir xüsusi şəkildə yalan danışır

Sayğacları formalaşdırdığınız layda oxuyun. Eyni Cisco təlimatı əsas interfeys siyasət sayğaclarının bu quruluşda qeyri-dəqiq ola biləcəyini xəbərdar edir. Bu, sayğacla bağlı bir xəbərdarlıqdır, sinfin uyğunlaşdığı və ya atdığına dair sübut deyil. Onu istifadəçinin yaşadığı yeganə şey olan tətbiq nəticəsindən ayrı saxlayın.

Köhnə traffic-shape nümunəsini əlaqəsiz siyasət xəritəsinin yanına köçürmək iki sürətin eyni paketləri idarə etdiyini sübut etmir.

Ümumi həcmi sınayın, yalnız tavanı deyil

Bir məşğul spokla başlayın və onun tavanına çatdığını təsdiqləyin. Sonra təsdiqlənmiş plan çərçivəsində hamısından eyni anda trafik təklif edin və tunnel üzrə rəqəmlərin yanında fiziki interfeysə baxın. Əgər hər spok öz tavanında oturursa, uplink sıxılıbsa və gecikmə artırsa, spok üzrə siyasət tam dizayn edildiyi kimi işləyir və büdcə hələ də səhvdir.

Bu nöqtədə düzəliş tutum və ya qəbul qərarıdır. Spok üzrə rəqəmləri yenidən tənzimləmək yalnız hansı filialın ilk şikayət edəcəyini dəyişir.