Давайте посчитаем, с чем мы имеем дело. CAR - это, по сути, старая версия IOS-политик, поэтому все эти понятия применимы к обоим.
Committed Information Rate (CIR) = 5,000,000 (5Mbps)
Burst Commit Bucket (Bc) = 937,500
Burst Excess Bucket (Be) = 1,875,000
Time Interval (Tc) = Bc / CIR = 0.1875 s = 187.5 ms
Скорость, которой мы хотим ограничить потоки, составляет 5 Мбит / с. Объем сообщения составляет 937 500 байт. Burst Bucket составляет 1 875 000 байт. И ведра пополняются каждые 187,5 мс.
Как вы упомянули, IOS использует механизм корзины, чтобы ограничить объем передаваемого трафика. Он не сглаживает трафик до X% пропускной способности интерфейса за произвольный период времени! Вместо этого он обеспечивает полный доступ к пропускной способности интерфейса, если у вас есть токены, чтобы заплатить за него.
Кроме того, поскольку это политика, КРАСНЫЙ / КРАСНЫЙ не участвуют в игре. КРАСНЫЙ происходит только тогда, когда есть очередь для управления. В применении политик нет буферизации / очередей, только в формировании.
Давайте сначала разберемся с коммитом коммита (Bc). Предположим, что на данный момент нет Excess Bucket (Be).
* Commit Bucket Only (двухцветный ограничитель) *
Это очень строгий ограничитель, который позволяет вам отправлять сообщения только в пределах CIR; не взрывается выше. Есть только одно ведро, Bc. Есть два «цвета» для трафика, соответствующие и превышающие .
Время = 0 мс. - Начало корзины заполнено токенами на сумму 937 500 байт. Допустим, вы отправили 7500 байт через интерфейс. Теперь IOS уменьшает контейнер на 7500 байт, и в нем теперь есть токены на 930 000 байтов. Отправленный трафик считается «соответствующим» и к нему применяется «действие-соответствие».
Время = 187,5 мс. - Теперь мы нажимаем на Tc и пополняем ведро Bc. Добавлены токены на сумму 937 500 байт. Любые лишние жетоны разливаются и теряются.
Время = 190 мс. - В ячейке коммита содержится 937 500 токенов. Мы получаем 2 000 000 байтов трафика. Первые 937 500 байт передаются в порядке, так как в ведре есть токены для этого. Оставшийся трафик считается «превышением» и обрабатывается в соответствии с «превышением действия». Помните, что нет никакой буферизации в применении политик (это называется формированием) - вы либо передаете, замечаете и передаете, либо отбрасываете.
Время = 375 мс. - Мы снова нажимаем на Tc, и бак Bc пополняется 937 500 токенами.
* Совершенное ведро с избыточным ведром (трехцветный ограничитель) *
При желании вы можете добавить Excess Bucket (Be). Это позволяет трафику временно превышать Bc bucket. Общий CIR должен оставаться прежним. Это трехцветный ограничитель: соответствующий, превышающий и нарушающий .
Время = 0 мс - оба сегмента (Bc и Be) начинают заполняться. Bc имеет 937 500 токенов, Be - 1 875 000 токенов.
Время = 50 мс - поступает 2 000 000 байт трафика. Маршрутизатор сначала уменьшает токены Bc Bucket. Это уменьшает ведро Bc до нуля. 937 500 байт трафика, покрываемых Bc, считаются «соответствующими» и к ним применяется «действие-согласование».
Это оставляет 1 062 500 байтов трафика, у которого еще нет токенов. Теперь маршрутизатор погружается в корзину Be и вычитает 1 062 500 токенов, чтобы покрыть остальную часть трафика. Эти байты считаются «превышающими» и к ним будет применено «превышение действия». В вашем примере трафик будет отброшен, но вы можете заметить или просто передать его.
Если вы ведете счет дома, Bc теперь имеет ноль жетонов, Be - 812 500 жетонов.
Время = 75 мс. Теперь маршрутизатор получает еще 1 200 000 байтов трафика. Ведро Bc пустое, поэтому никакой помощи нет. Может помочь корзина Be, поэтому она покрывает первые 812 500 байт трафика своими токенами и теперь пуста. Этот трафик считается «превышением», и к нему будет применено «превышение действия».
Теперь ведра пусты, но осталось еще 387 500 байт для обработки. Этот трафик считается «нарушающим» и всегда сбрасывается с помощью CAR (с ним можно делать другие вещи, используя MQC и команду полиции с помощью «violate-action»).
Время = 187,5 мс - Теперь мы приходим к первому интервалу Tc, время для заполнения наших сегментов. Ключевым моментом является то, что толькотокены на сумму Bc пополняются! Ведро Bc сначала заполняется до 937 500. Ведро Be ОСТАЕТСЯ ПУСТОЙ.
Время = 375 мс. Было тихо, и мы переходим к следующему интервалу Tc. Жетоны Bc добавляются в Bc Bucket. Поскольку бак Bc уже заполнен, лишние токены не теряются - вместо этого они «перетекают» в корзину Be. Теперь ведро Bc заполнено 937 500 токенами, а ведро Be частично заполнено 937 500 токенами.
Время = 562,5 мс - по- прежнему тихо, и мы находимся на следующем Tc. Токены Bc добавляются в корзину Bc, которая уже заполнена. Все это перетекает в ведро Be (в котором уже есть 937 500 токенов). Бе заполняет до 1875000 жетонов.
* Заключительные замечания *
Ваша конфигурация не использует ведро Be. Вы ограничиваете / ограничивает скорость, используя только контейнер Bc, который может иметь непреднамеренные побочные эффекты, если ограничитель / формирователь, отправляющий вам данные, не настроен идентично и не синхронизирован Tc-wise.
CAR / rate-limit очень старый и устарел. Рассмотрите возможность перехода на MQC и современное QoS для реализации этого, так как это даст вам больше информации и возможностей.
Я полностью игнорирую задержку сериализации (время, необходимое для передачи данных по линии) выше, и я совершенно уверен, что математика не работает в реальном сценарии. Но концепции надежны независимо от того, какие цифры используются.
* Пример MQC *
policy-map PM-FA0/0-IN
class class-default
police cir 5000000 bc 937500 be 1875000
!
interface Fa0/0
service-policy input PM-FA0/0-IN
!
* Источники *