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

Как я понимаю, Cisco IOS CAR (Committed Access Rate) основана на пропущенном алгоритме bucket (идея точно такая же, как алгоритм маркера токена ) и количество бит, которые я конфигурирую как среднюю скорость, - это количество «воды, постоянно утечки ведра». Например, средняя скорость ограничения скорости ввода составляет 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-подобного алгоритма до тех пор, пока все новые пакеты не будут сброшены, если максимальный пакет также будет заполнен?

11 голосов | спросил Martin 30 MarpmMon, 30 Mar 2015 16:36:02 +03002015-03-30T16:36:02+03:0004 2015, 16:36:02

1 ответ


11

Давайте вычислим, что мы имеем здесь. 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 Мбит /с. Конец Commit составляет 937 500 байт. Burst Bucket - 1,875,000 байт. И ведра заправляются каждые 187,5 мс.

Как вы уже упоминали, IOS использует механизм ведра, чтобы ограничить количество трафика. Он не сглаживает трафик до X% пропускной способности интерфейса в течение произвольного периода времени! Вместо этого он обеспечивает полный доступ к пропускной способности интерфейса, если у вас есть токены, чтобы заплатить за него.

Кроме того, поскольку это настройка, RED /WRED не воспроизводятся. RED происходит только тогда, когда есть очередь для управления. Буферизация /очередность в полицейском процессе отсутствует, только при формировании.

Сначала рассмотрим Commit Bucket (Bc). Предположим, что на данный момент нет избыточного ведра (Be).

* Только Commit Bucket (двухцветный полимер) *

Это очень строгий полицейский, который позволит вам только отправлять в CIR; нет разрыва выше. Существует только одно ведро, Bc. Для трафика есть два «цвета», соответствует и превышает .

Время = 0 мс - Ведро начинается полностью, в нем есть токены 937,5 тыс. байт. Скажем, вы отправляете 7 500 байтов по интерфейсу. Теперь IOS уменьшает ведро на 7500 байт, а теперь ведро имеет токены 930 000 байт. Отправленный трафик считается «соответствующим» и имеет к нему «соответствующее действие».

Время = 187,5 мс - Теперь мы нажмем Tc и пополним ведро Bc. Добавлены маркеры 937,5 тыс. Байт. Любые дополнительные жетоны разливаются и теряются.

Время = 190 мс - Ведро фиксации содержит 937 500 токенов. Мы получаем 2 000 000 байт трафика. Первые 937 500 байт передаются штрафом, так как у ведра есть метки для него. Оставшийся трафик считается «превышением» и рассматривается в соответствии с «превышением действия». Помните, что в полицейской деятельности нет буферизации (это называется шейпинг) - вы либо передаете, замечаете и передаете, либо теряете.

Время = 375 мс - Мы снова нажимаем Tc, а ведро Bc пополняется 937 500 токенов.

* Commit Bucket с избыточным ведром (трехцветный полис) *

Вы можете дополнительно добавить избыточный ведро (Be). Это позволяет трафику превышать ведро Bc на временной основе. Общий CIR должен оставаться неизменным. Это три «цветных» полицейских: соответствие, превышение и нарушение .

Время = 0 мс - Оба ведра (Bc и Be) начинаются полностью. Bc имеет 937 500 токенов, Be имеет 1,875,000 токенов.

Время = 50 мс - Прибывает 2 000 000 байт трафика. Маршрутизатор сначала уменьшает токены Bc. Это уменьшает ведро 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 и команду полиции с «нарушением действия»).

Время = 187,5 мс - Теперь мы приходим к первому интервалу Tc, чтобы заполнить наши ведра. Ключевым моментом является то, что стоимость токенов Bc пополняется! Ведро Bc заполняется сначала до 937 500. Ведро Be be REMAINS EMPTY.

Время = 375 мс - Было тихо, и мы переходим к следующему интервалу Tc. Значения токенов Bc добавляются в ведро Bc. Так как ведро Bc уже заполнено, избыточные жетоны не теряются - вместо этого они перетекают в ведро Be. Теперь ведро Bc заполнено 937 500 токенами, а ведро Be - частично заполнено 937 500 токенами.

Время = 562,5 мс - Тихо, и мы находимся на следующем Tc. Значения токенов Bc добавляются в ведро Bc, которое уже заполнено. Все это переливается в ведро Be (у которого уже есть 937 500 токенов). Be заполняет все до 1,875,000 токенов.

* Заключительные замечания *

  • В вашей конфигурации не используется ведро Be. Вы ограничение скорости /контроль за использованием только ведро Bc, которое может иметь непреднамеренные побочные эффекты, если полицейский /шейкер, отправляющий вам данные не настроен идентично и не синхронизирован Tc-wise.

  • CAR /limit-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
!

* Источники *

ответил Keller G 1 PMpWed, 01 Apr 2015 19:56:02 +030056Wednesday 2015, 19:56:02

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132