Как понимать «нормальный пакет» и «максимальный пакет» в Cisco CAR?

11

Как я понимаю, Cisco IOS CAR (Committed Access Rate) основан на алгоритме сегмента утечки (идея точно такая же, как алгоритм блока маркера ), а количество битов, которые я настраиваю как среднюю скорость, представляет собой количество "воды, постоянно вытекающей из блока". ». Например, здесь средняя скорость ограничения скорости ввода составляет 5 Мбит / с:

interface FastEthernet0/0
 ip address 10.10.10.2 255.255.255.0
 rate-limit input 5000000 937500 1875000 conform-action transmit exceed-action drop

Теперь, если скорость трафика ниже средней, то она всегда соответствует. Правильно ли я понимаю, что «нормальный пакет» определяет, насколько большими могут быть пакеты трафика до применения «превышения»? Таким образом, в приведенном выше примере, если была постоянная скорость трафика 5 Мбит / с (625000 байт в сегменте), то я мог бы отправить за одну секунду 7,5 Мбит / с (добавляет дополнительные 312500 байт в сегмент) трафика, и ни один бит не был отброшен ? И если байты в сегменте находятся между нормальным пакетом и максимальным пакетом, то байты отбрасываются на основе RED-подобного алгоритма, пока все новые пакеты не будут отброшены, если максимальный пакет также заполнен?

cisco cisco-ios Мартин
источник
Любая другая информация или объяснение, которое вы ищете в моем ответе, чтобы заработать вознаграждение, которое вы установили?
Келлер Г
Пожалуйста, не забывайте, что вы должны вручную присудить награду ; Если вы получили ответ, который вас не устраивает, объясните, по крайней мере, что отсутствует в этом ответе.
Майк Пеннингтон

Ответы:

12

Давайте посчитаем, с чем мы имеем дело. 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
!

* Источники *

Келлер Г.
источник
Действительно простой ответ! Но у меня есть один вопрос, касающийся однотарифной (двухцветной) полицейской деятельности. Вы упомянули следующее: есть два «цвета» для трафика, соответствующие и нарушающие. То, что я думаю, должно быть, соответствуя и превосходя (вместо того, чтобы нарушать, что должно принадлежать методу контроля цвета дерева).
Даниэль Блазек
Вы совершенно правы, обновлены, как вы предложили.
Келлер Г.