Ар бир тоннелдин QoS хабдын жалпы uplink'ин чектебейт

Бул ишеним арифметикага окшош: беш 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 сандарын кайра жөндөө кайсы филиал биринчи даттанарын гана өзгөртөт.