QoS на кожным тунелі не абмяжоўвае агульны ўзыходны канал вашага хаба

Перакананне гучыць як арыфметыка: пяць спікаў, кожны абмежаваны 5 Mbit/s, значыць хаб нясе не больш за 25 Mbit/s. Першая палова праўдзівая, а выснова не. Палітыка на кожным тунелі ўжываецца адзін раз на тунель, а не адзін раз на хаб, і агульны ўзыходны канал, праз які праходзяць усе пяць тунеляў, ніколі не з'яўляецца ў гэтым разліку. Перагрузка на ўзыходным канале застаецца такой, якой была.

Адкуль бярэцца перакананне

Блытаніна зразумелая, бо інфармацыя групы NHRP дазваляе аднаму вызначэнню палітыкі прымяняцца да цэлага набору спікаў. Гэта чытаецца як агульны бюджэт у файле канфігурацыі. Насамрэч гэта азначае, што кожны спік атрымлівае свой уласны асобнік гэтага вызначэння.

Такім чынам, 5 Mbit/s на спік — гэта столь на кожным тунелі, і столей столькі ж, колькі тунеляў.

Што кантралюе адзін асобнік палітыкі

Кіраўніцтва Cisco па QoS для DMVPN на асобных тунелях у IOS XE апісвае палітыку выхаду хаба, якая выбіраецца праз інфармацыю групы NHRP і прымяняецца асобна да кожнага спіка. З гэтага сказа вынікаюць два абмежаванні, і абодва ігнаруюцца. Хуткасць належыць аднаму спіку, а не агульнаму вягру, і функцыя кіруе трафікам ад хаба да спіка, а не наадварот.

Плануйце кірунак адпраўкі спіка асобна. Нішто ў палітыцы выхаду хаба не абмяжоўвае тое, што філіял загружае.

Змясціце агульнае абмежаванне ў агульным вузкім месцы

Агульны аб'ём павінен фармавацца там, дзе ён насамрэч канкуруе: на фізічным інтэрфейсе, які падзяляюць усе тунелі. Cisco дакументуе фармавальнік class-default на фізічным інтэрфейсе як падтрыманую сумесную фізічную палітыку для гэтай функцыі, і гэта больш вузкая заява, чым любая іерархія, якую вы можаце ўвесці. Меркавайце, што адвольная другая фізічная палітыка, якую вы прыдумалі, не падтрымліваецца, пакуль хто-небудзь не дакажа адваротнае.

Затым вырашыце, што адбываецца, калі ўсе спікі занятыя адначасова. Які трафік дапускаецца, які клас атрымлівае прыярытэт і якая чарга валодае спаборніцтвам. Столь на спік не адказвае ні на адно з гэтых пытанняў, бо кожны спік разглядаецца асобна.

Узгадніце адзінкі фармавання і ўлік накладанняў з фактычнай перадачай. Накладанні інкапсуляцыі, якія вы пакідаеце па-за разлікам хуткасці, праяўляюцца як канал, што насычаецца раней за наладжаны лік.

Лічыльнікі хлусяць адным пэўным чынам

Чытайце лічыльнікі на тым узроўні, які вы фармуеце. То ж кіраўніцтва Cisco папярэджвае, што лічыльнікі палітыкі асноўнага інтэрфейса могуць быць недакладнымі ў такой схеме. Гэта засцярога адносна лічыльніка, а не доказ таго, што клас супадае або адкідвае. Трымайце гэта асобна ад выніку праграмы, які адзінае, што адчувае карыстальнік.

Капіраванне старога прыкладу traffic-shape побач з незвязанай картай палітыкі не даказвае, што дзве хуткасці кіруюць аднымі і тымі ж пакетамі.

Праверце агульны аб'ём, а не толькі столю

Пачніце з аднаго занятага спіка і пераканайцеся, што ён дасягае сваёй столі. Затым прапануйце трафік ад усіх адначасова ў межах узгоджанага плана і назірайце за фізічным інтэрфейсам побач з лічбамі на кожным тунелі. Калі кожны спік сядзіць на сваёй столі, а ўзыходны канал заціснуты і затрымка расце, палітыка на спік працуе менавіта так, як задумана, і бюджэт па-ранейшаму няправільны.

Выпраўленне ў гэты момант — гэта рашэнне аб ёмістасці ці дапушчальнасці. Пераналадка лічбаў на спік змяняе толькі тое, якая філія скардзіцца першай.