Յուրաքանչյուր թունելի QoS-ը չի սահմանափակում ձեր hub-ի ընդհանուր uplink-ը

Այս համոզմունքը թվաբանության է նման. հինգ spoke, յուրաքանչյուրը ձևավորված 5 Mbit/s-ի, ուստի hub-ը կրում է առավելագույնը 25 Mbit/s։ Առաջին կեսը ճիշտ է, եզրակացությունը՝ ոչ։ Յուրաքանչյուր թունելի քաղաքականությունը կիրառվում է մեկ անգամ յուրաքանչյուր թունելի համար, ոչ թե մեկ անգամ hub-ի համար, և ընդհանուր uplink-ը, որով անցնում են բոլոր հինգ թունելները, երբեք չի հայտնվում այդ հաշվարկում։ Uplink-ի գերբեռնվածությունը մնում է ճիշտ այնպիսին, ինչպիսին եղել է։

Որտեղից է գալիս համոզմունքը

Շփոթմունքը հասկանալի է, որովհետև NHRP խմբի տեղեկությունը թույլ է տալիս մեկ քաղաքականության սահմանում կիրառել spoke-ների ամբողջ հավաքածուի վրա։ Դա կարդացվում է որպես ընդհանուր բյուջե կոնֆիգուրացիայի ֆայլում։ Իրականում դա նշանակում է, որ յուրաքանչյուր spoke ստանում է այդ սահմանման իր պատճենը։

Այսպիսով, 5 Mbit/s մեկ spoke-ի համար թունելային առաստաղ է, և առաստաղներ այնքան կան, որքան թունելներ։

Ինչ է կառավարում քաղաքականության մեկ պատճենը

Cisco-ի QoS-ի ուղեցույցը թունելային DMVPN-ի համար IOS XE-ում նկարագրում է hub-ի ելքային քաղաքականություն, որն ընտրվում է NHRP խմբի տեղեկությամբ և առանձին կիրառվում յուրաքանչյուր spoke-ի վրա։ Այդ նախադասությունից բխում են երկու սահմանափակում, և երկուսն էլ անտեսվում են։ Արագությունը պատկանում է մեկ spoke-ի, ոչ թե ընդհանուր դույլի, և ֆունկցիան կառավարում է երթևեկությունը hub-ից spoke, ոչ թե հակառակը։

Պլանավորեք spoke-ի ուղարկման ուղղությունը ինքնուրույն։ Hub-ի ելքային քաղաքականության մեջ ոչինչ չի սահմանափակում, թե մասնաճյուղը ինչ է վերբեռնում։

Ընդհանուր սահմանը դրեք ընդհանուր խցանման վայրում

Ագրեգատը պետք է ձևավորվի այնտեղ, որտեղ այն իրականում մրցում է՝ ֆիզիկական ինտերֆեյսում, որը բոլոր թունելները կիսում են։ Cisco-ն ֆիզիկական ինտերֆեյսի class-default shaper-ը փաստագրում է որպես այս ֆունկցիայի աջակցվող զուգահեռ ֆիզիկական քաղաքականություն, ինչը ավելի նեղ պնդում է, քան ցանկացած հիերարխիա, որը կարող եք մուտքագրել։ Ենթադրեք, որ ձեր հորինած կամայական երկրորդ ֆիզիկական քաղաքականությունը չի աջակցվում, քանի դեռ ինչ-որ մեկը չի ապացուցել հակառակը։

Այնուհետև որոշեք, թե ինչ է լինում, երբ բոլոր spoke-ները միաժամանակ զբաղված են։ Որ երթևեկությունն է ընդունվում, որը դասն է առաջնահերթություն ստանում, և որը հերթն է տիրում մրցակցությանը։ Spoke-ի առաստաղը այս հարցերից ոչ մեկին չի պատասխանում, որովհետև յուրաքանչյուր spoke դիտարկվում է առանձին։

Համապատասխանեցրեք ձևավորման միավորները և վերածախսի հաշվառումը իրական հանձնմանը։ Ինկապսուլյացիայի վերածախսը, որը թողնում եք արագության հաշվարկից դուրս, երևում է որպես կապուղի, որը հագենում է կարգավորված թվից առաջ։

Հաշվիչները ստում են մեկ կոնկրետ ձևով

Կարդացեք հաշվիչները այն շերտում, որը ձևավորում եք։ Նույն Cisco ուղեցույցը զգուշացնում է, որ հիմնական ինտերֆեյսի քաղաքականության հաշվիչները այս դասավորության մեջ կարող են անճշտել։ Դա վերաբերում է հաշվիչին, ոչ թե ապացույց է, որ դասը համընկնում է կամ դեն է նետում։ Առանձին պահեք այն հավելվածի արդյունքից, որը միակ բանն է, որ օգտվողը զգում է։

Հին traffic-shape օրինակը անկապ քաղաքականության քարտեզի կողքին պատճենելը չի ապացուցում, որ երկու արագությունները կառավարում են նույն փաթեթները։

Փորձարկեք ագրեգատը, ոչ միայն առաստաղը

Սկսեք մեկ զբաղված spoke-ով և հաստատեք, որ այն հասնում է իր առաստաղին։ Այնուհետև հաստատված պլանի ներքո առաջարկեք երթևեկություն բոլորից միաժամանակ, և դիտեք ֆիզիկական ինտերֆեյսը թունելային թվերի կողքին։ Եթե յուրաքանչյուր spoke նստած է իր առաստաղին, մինչ uplink-ը լցված է և ուշացումը բարձրանում է, spoke-ի քաղաքականությունը աշխատում է ճիշտ այնպես, ինչպես նախագծվել է, և բյուջեն դեռ սխալ է։

Այդ պահին ուղղումը հզորության կամ ընդունելության որոշում է։ Spoke-ի թվերը վերակարգավորելը փոխում է միայն այն, թե որ մասնաճյուղն է առաջինը բողոքում։