Cisco Policing and Shaping.

Общая идея механизмов известна: установить контрактную скорость, считать пакеты, при превышении скорости полисер дропает лишние пакеты а шейпер копит в буфере.

Немного терминов.

CIR – committed information rate. Контрактная скорость. Не надо забывать, что механизмы не от хорошей жизни. Их назначение в том, что при покупке полосы у провайдера вы должны отправлять пакеты максимум на этой полосе. Иначе они будут справедливо дропаться.

PIR – peak information rate. Переподписка! Провайдер вам продал полосу, но готов пропускать больше трафика (пока суммарно канал не загружен). Вероятность дропа как бы выше, для этого пакеты с рейтом выше CIR но ниже PIR часто помечают худшим маркером.

Tc – time interval (measurement interval) . Фактически это время усреднения, интервал на котором будет отправлено пакетов столько, чтоб не превысить CIR.

Bc – committed burst. Пакеты отправляются на физической скорости интерфейса. Так как за время Tc мы должны получить среднюю скорость CIR, то количество пакетов не может превысить Bc. Никто не мешает отправить все пакеты одномоментно и потом ждать следующего интервала.

Be – extended burst. Если вы несколько Tc не выбирали Bc то средняя скорость ниже CIR и вы вправе отправить на следующем интервале больше пакетов, суммарно Bc+Be. Тем не менее, пакеты Bc гарантируются контрактом, а Be все равно его превышают на данном интервале Tc, по этому к Be пакетам применяется другое действие.

Bc, Be и корзина.

Учет пакетов ведется механизмом корзины токенов. Bc и Be – две отдельных корзины. Для полисера пакеты в рамках Bc проходят с действием Conform, пакеты количеством выше контрактного всплеска но ниже Be проходят по действию Exceed (как правило им что то накручивают, например DE – дроп эладжибилити для фрейм релея или худший приоритет). Наконец пакеты больше Be дропаются. Все вместе называется Singl-rate Three-colour полисинг.

Корзина Be заполняется после того как заполнена Bc, токены как бы протекают, создавая кредит. Расходуются токены из Be не все разом, а учитывая текущий и составной долг который равен составному долгу на шаге N-1 + текущий долг на шаге N. Все это нужно чтобы поддропывать пакеты из расширенного всплеска, намекая TCP что пора сокращать окно передачи.

В момент t=0 у нас в Bc токенов на 2 пакета. В Be - на 4. Раз в секунду нам поступает токен, однако приходит 2 пакета и мы, начиная с t=1 должны один пропускать с правилом Bc а второй с Be. Так в t=1 мы берем один токен из расширенного всплеска. Текущий долг = 1. В t=2 нам опять не хватает токена, мы берем из Be, текущий долг - 2 а составной -3. В момент t=3 мы собираемся взять токен из Be. Однако составной долг вырос бы до 3+3=6 и стал больше Be, что запрещено. Мы дропаем 1 пакет, обнуляем составной долг. Актуальный (текущий долг) остается =2. В момент t=4 мы снова можем взять 1 токен из Be. Когда текущий долг исчерпает весь Be то пакеты больше Bc будут дропаться.

Как выбирать Bc и Be? Опыты показывают, что Be должен быть не меньше 2х Bc, тогда TCP работает достаточно "плавно". Bc не может быть меньше MTU, иначе мы не сможем отправить ни один пакет. Кроме того желательно Bc>=CIR*RTT, где RTT ваша задержка на канале, иначе окно передачи не будет помещаться в один всплеск. И да, для полисера корзина в Байтах а для шейпера в битах, а почему бы и нет)

Tc и с чем его едят.

Глядя на предыдущий параграф, хочется сделать Tc побольше. Не выйдет ли так что корзина будет обновляться редко и трафик будет идти рывками? Фактически Tc является интервалом усреднения, в пределах которого можно потратить размер всплеска и так поддержать контрактную скорость. При этом для полисера корзина пополняется чаще чем один раз в Tc. И идеале токены текут в корзину постоянно на скорости равной CIR. Так как циска - не аналоговый прибор, а цифровой то токены насчитываются дискретно, каждый раз как поступил новый пакет. В корзину кладется (t2-t1)*CIR/8 токенов.

Допустим в момент времени t1=0 у нас в корзине токенов на 1000 пакетов. CIR=1000 пакетов в секунду. Пришло 250 пакетов на интерфейс и осталось в корзине 750. В момент t2=0,25 сек пришло еще 300 пакетов. В корзину начислят (0,25-0)*1000=250 токенов и там останется 700. В t3=0,35 пришло 900 пакетов. Начислят (0,35-0,25)*1000=100 токенов. Итого 800 пакетов уйдет как Conform а 100 как Exceed (если конечно был Be)

Для шейпера Tc имеет то же смысл, однако токены начисляются с периодом Tc. Это не важно, так как пакеты не теряются и не имеют разных правил на выход. Они все равно уйдут или подождут в буфере и уйдут.

Dual-rate

Все меняется, когда мы указываем явно PIR в полисере. Тогда Be отвязывается от Bc и заполняется отдельно. Логично, что Be>Bc. Пакет до уровня Bc списывает токены из обоих корзин. Выше контрактного но ниже пикового всплеска - только из Be. Действия на выход - те же. В результате мы не просто разрешаем расширенные всплески, сохраняя в среднем скорость на уровне CIR а разрешаем слать пакеты на уровне PIR. Гарантированной скоростью по прежнему остается CIR.

Для шейпера пакеты прошедшие что через Bc что через Be выглядят одинаково. Фактически шейпер шпарит на скорости Shaping rate = configured rate (1 + Be/Bc). А в чем прикол? Если в шейпере указать PIR, то CIR рассчитывается как его половина и при получении сигнализации о заторе (BECN) шейпер может перейти на контрактную скорость. Вроде бы)

Очереди и приоритеты.

Полисер и шейпер ограничивают полосу сверху. Но не гарантируют трафик ниже этой полосы. Для этого нужно использовать другие механизмы, например приоритетные очереди и писать составную полиси-мапу. Однако в таких мапах полисер не имеет смысла, так как он не создает очередей и дропает пакеты, не глядя на их параметры. Только шейпер. По умолчанию шейпер создает буфер с очередью WFQ.

Вот пример с Cisco:

class-map match-all IP 
   match ip precedence 3 
class-map match-all VoIP 
   match ip precedence 5 
  
policy-map child 
  class VoIP 
     priority 128 
   class IP 
     priority 1000 
 
 policy-map parent 
   class class-default 
     police 3300000 103000 103000 conform-action transmit exceed-action drop 
     service-policy child

Полисер нужно заменить шейпером:

policy-map parent
    class class-default
     shape average 3300000 103000 0
      service-policy child

Ссылки:

Библиотека радиолюбителя:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_plcshp/configuration/15-mt/qos-plcshp-15-mt-book.html

Сравнение полисера и шейпинга для ограничения трафика. Там же - как смотреть статистику и параметры:
http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html#tokenrefreshrate

Конфигурирование шейпинга с примерами:
http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfcbshp.html#wpxref80464

Хорошая статья Петра Лапухова (в ней ссылки еще на 2 толкования)
http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/?s=Shaping

Поиск по этому блогу

Пора!