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 меняет только то, какой филиал жалуется первым.