QoS на кожен тунель не обмежує загальний аплінк вашого хаба

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

Звідки береться це переконання

Плутанина зрозуміла, бо інформація групи NHRP дозволяє одному визначенню політики діяти для цілого набору spoke. Це читається як спільний бюджет у файлі конфігурації. Насправді це означає, що кожен spoke отримує власний примірник цього визначення.

Отже, 5 Mbit/s на spoke — це стеля на тунель, і стель стільки ж, скільки тунелів.

Чим керує один примірник політики

Посібник Cisco з QoS на кожен тунель у DMVPN на IOS XE описує політику виходу з хаба, яка вибирається за інформацією групи NHRP і застосовується окремо до кожного spoke. З цього речення випливають два обмеження, і обидва ігноруються. Швидкість належить одному spoke, а не спільному відру, і функція керує трафіком від хаба до spoke, а не навпаки.

Плануйте напрямок надсилання spoke окремо. Ніщо в політиці виходу з хаба не обмежує те, що філія завантажує.

Розмістіть загальне обмеження в спільному вузькому місці

Сукупність має формуватися там, де вона справді конкурує: на фізичному інтерфейсі, який поділяють усі тунелі. Cisco документує shaper class-default на фізичному інтерфейсі як підтримувану одночасну фізичну політику для цієї функції, і це вужче твердження, ніж будь-яка ієрархія, яку ви можете ввести. Вважайте, що довільна друга фізична політика, яку ви вигадали, не підтримується, доки хтось не доведе зворотне.

Потім вирішіть, що відбувається, коли всі spoke зайняті одночасно. Який трафік допускається, який клас отримує пріоритет і яка черга володіє конкуренцією. Стеля на spoke не відповідає на жодне з цих питань, бо кожен spoke розглядається окремо.

Узгодьте одиниці формування й облік накладних витрат із фактичною передачею. Накладні витрати інкапсуляції, які ви залишаєте поза розрахунком швидкості, виявляються як канал, що насичується раніше за налаштоване число.

Лічильники брешуть одним певним чином

Читайте лічильники на тому рівні, який ви формуєте. Той самий посібник Cisco попереджає, що лічильники політики основного інтерфейсу в такій схемі можуть бути неточними. Це застереження про лічильник, а не доказ того, що клас збігається або відкидає. Тримайте це окремо від результату застосунку, який є єдиним, що відчуває користувач.

Копіювання старого прикладу traffic-shape поруч із не пов'язаною картою політики не доводить, що дві швидкості керують одними й тими самими пакетами.

Перевіряйте сукупність, а не лише стелю

Почніть з одного зайнятого spoke і переконайтеся, що він досягає своєї стелі. Потім запропонуйте трафік від усіх одночасно за затвердженим планом і спостерігайте за фізичним інтерфейсом поряд із цифрами на кожен тунель. Якщо кожен spoke стоїть на своїй стелі, а аплінк забитий і затримка зростає, політика на spoke працює саме так, як задумано, і бюджет досі неправильний.

Виправлення в цій точці — рішення про ємність або допуск. Переналаштування цифр на spoke змінює лише те, яка філія скаржиться першою.