Бұл сенім арифметикаға ұқсайды: бес spoke, әрқайсысы 5 Mbit/s-ке қалыпталған, сондықтан хаб ең көбі 25 Mbit/s тасиды. Бірінші жартысы рас, қорытынды емес. Әр туннель саясаты әр туннель үшін бір рет қолданылады, хаб үшін бір рет емес, және барлық бес туннель өтетін ортақ uplink ол есептеуде ешқашан көрінбейді. Uplink-тегі кептеліс дәл бұрынғы қалпында қалады.

Бұл сенім қайдан шығады

Шатасу түсінікті, өйткені NHRP тобының ақпараты бір саясат анықтамасын бүкіл spoke жиынтығына қолдануға мүмкіндік береді. Бұл конфигурация файлындағы ортақ бюджет сияқты оқылады. Шын мәнінде бұл әр spoke сол анықтаманың өз данасын алатынын білдіреді.

Сондықтан әр spoke үшін 5 Mbit/s — әр туннель үшін шек, ал шектер туннельдер санына тең.

Бір саясат данасы нені басқарады

Cisco-ның IOS XE-дегі DMVPN-де әр туннель үшін QoS жөніндегі нұсқаулығы NHRP тобының ақпараты арқылы таңдалатын және әр spoke-ке жеке қолданылатын хабтың шығыс саясатын сипаттайды. Осы сөйлемнен екі шектеу шығады және екеуі де ескерілмейді. Жылдамдық бір spoke-ке тиесілі, ортақ шелекке емес, және функция хабтан spoke-ке қарай трафикті басқарады, керісінше емес.

Spoke-тің жіберу бағытын дербес жоспарлаңыз. Хабтың шығыс саясатында филиалдың жүктейтінін шектейтін ештеңе жоқ.

Жалпы шектеуді ортақ тар жолға қойыңыз

Жиынтық ол шынында бәсекелесетін жерде қалыпталуы керек: барлық туннель бөлісетін физикалық интерфейсте. Cisco физикалық интерфейстегі class-default shaper-ін осы функция үшін қолдау көрсетілетін бір мезгілдегі физикалық саясат ретінде құжаттайды, бұл енгізе алатын кез келген иерархиядан тар мәлімдеме. Ойлап тапқан ерікті екінші физикалық саясатыңызды біреу керісін дәлелдегенше қолдау жоқ деп есептеңіз.

Содан кейін барлық spoke бір уақытта бос емес болғанда не болатынын шешіңіз. Қандай трафик қабылданады, қай класс басымдық алады және қай кезек бәсекеге ие. Әр spoke үшін шек осы сұрақтардың ешқайсысына жауап бермейді, өйткені әр spoke жеке қаралады.

Қалыптау бірліктері мен үстеме шығыс есебін нақты беріліске сәйкестендіріңіз. Жылдамдық есебінен тыс қалдырған инкапсуляция үстемесі конфигурацияланған саннан бұрын қанығатын байланыс ретінде көрінеді.

Санауыштар бір нақты түрде өтірік айтады

Санауыштарды қалыптап жатқан қабатта оқыңыз. Сол Cisco нұсқаулығы негізгі интерфейс саясатының санауыштары бұл орналасуда дәлсіз болуы мүмкін екенін ескертеді. Бұл санауыш туралы ескерту, кластың сәйкес келуі немесе тастауы туралы дәлел емес. Оны қолданба нәтижесінен бөлек ұстаңыз, өйткені пайдаланушы тек соны сезінеді.

Ескі traffic-shape мысалын байланысы жоқ саясат картасының қасына көшіру екі жылдамдықтың бірдей пакеттерді басқаратынын дәлелдемейді.

Жиынтықты сынаңыз, тек шекті емес

Бір бос емес spoke-тен бастап, оның өз шегіне жететінін растаңыз. Содан кейін бекітілген жоспар бойынша барлығынан бір уақытта трафик ұсыныңыз және әр туннель сандарының қасында физикалық интерфейсті бақылаңыз. Егер әр spoke өз шегінде отырса, ал uplink кептеліп, кідіріс өссе, әр spoke саясаты дәл жобаланғандай жұмыс істейді және бюджет әлі де дұрыс емес.

Ол кездегі түзету — сыйымдылық немесе рұқсат шешімі. Әр spoke сандарын қайта реттеу тек қай филиал бірінші шағымданатынын өзгертеді.

Қатысты мақалалар