QoS в Cisco
[править] Утилиты для классификации и маркировки
[править] Class-Based Marking (CB Marking)
Особенности логики и настройки CB Marking:
- Для CB Marking нужно включать CEF, иначе соответствующую service-policy нельзя будет применить на интерфейсе.
- CB Marking включается для пакетов входящих или выходящих из интерфейса.
- Могут быть настроены несколько команд set для маркировки трафика в нескольких полях.
- Пакеты, которые не совпали с явно настроенными class, совпадают со специальным class, который называется class-default.
- Если для class не задана команда set, то трафик, который совпадает с ним, не маркируется.
[править] Настройка CB Marking
Маркировка трафика, который совпадает с параметрами class-map определенным значением поля IP Precedence:
Для этой и следующей команды, если указан параметр ip, то значение поля устанавливается только для пакетов IPv4. Если параметр опущен, то значения IPP и DSCP устанавливаются для пакетов IPv4 и IPv6.
Маркировка трафика определенным значением поля DSCP:
Маркировка трафика определенным значением поля CoS:
Указание идентификатора группы для QoS group:
Установка в ячейке ATM бита CLP:
Установка в кадре Frame Relay бита DE:
[править] QoS Pre-Classification
Устройство, на котором выполняется маркировка трафика, может терминировать VPN-туннель. В этом случае в туннельные заголовки (IPsec или GRE) копируется значение поля ToS. Но такие функции как NBAR не могут работать с трафиком, который инкапсулирован в туннельный заголовок.
В IOS существует функция, которая помогает решить этот вопрос — QoS Pre-Classification.
QoS pre-classification «помнит» исходный, не зашифрованный трафик, до тех пор пока не будут выполнены действия QoS в исходящем направлении.
Эта функция может быть включена командой qos pre-classify в таких режимах:
- interface tunnel (для GRE и IPIP)
- interface virtual-template (для L2F и L2TP)
- crypto map (для IPsec)
[править] Просмотр информации
Для того чтобы регулировать частоту с которой проверяется статистика на интерфейсах (packet rate, bit rate) используется команда load-interval. Интервал указывается в секундах, по умолчанию 5 минут:
[править] Управление перегрузками и избежание перегрузок
Управление перегрузками (congestion management) или queuing — каким образом маршрутизатор или коммутатор управляет пакетами или кадрами, пока они ожидают своей очереди для выхода из устройства.
Для маршрутизаторов характерно output queuing, а для коммутаторов input и output queuing.
Избежание перегрузок (congestion avoidance) — логика, которую использует устройство, когда решает отбрасывать ли пакет и когда его отбрасывать, если система очередей становится более загруженной.
[править] Программные и аппаратные очереди
- Программная очередь (software queue) — очереди, которые реализованы в программном обеспечении и которыми можно управлять с помощью различных утилит.
- Аппаратная очередь (hardware queue) — после того как пакет покидает программную очередь, он попадает в небольшую аппаратную FIFO очередь. В Cisco эта очередь ещё называется transmit queue (TX queue) или transmit ring (TX ring).
Свойства аппаратных очередей:
- после окончания отправки интерфейсом одного пакета, следующий пакет из аппаратной очереди может быть отправлен через интерфейс без вмешательства со стороны программного обеспечения,
- всегда используют логику FIFO,
- не могут быть изменены утилитами IOS,
- IOS автоматически уменьшает размер аппаратной очереди по сравнению с её размером по умолчанию, если настроена какая-то утилита управления очередями,
- Если длина аппаратной очереди меньше, то повышается вероятность, что передача данных будет контролироваться в программной очереди.
Посмотреть текущий размер аппаратной очереди (для этого маршрутизатора по умолчанию размер очереди 256):
Изменение размера очереди:
После изменения размер аппаратной очереди:
[править] Утилиты управления очередями
- Priority queuing (PQ)
- Custom queuing (CQ)
- Class-based weighted fair queuing (CBWFQ)
- Low-latency queuing (LLQ)
Классы определенные в policy-map соответствуют очередям. Поэтому термины очередь (queue) и класс (class) взаимозаменяемы в контексте обсуждения LLQ и CBWFQ.
LLQ и CBWFQ поддерживают 64 очереди. Кроме того, существует одна специальная очередь по умолчанию class-default queue. В эту очередь попадают пакеты, которые НЕ совпали с критериями явно настроенных классов.
[править] CBWFQ
Принципы работы CBWFQ:
- Классификация — выполняется на основании любых критериев, которые доступны в MQC с помощью команды match,
- Политика отбрасывания пакетов — tail drop или WRED, настраивается для каждой очереди,
- Количество очередей — 64,
- Максимальная длина очереди — зависит от модели маршрутизатора,
- Обслуживание в пределах одной очереди — FIFO в 63 очередях, FIFO или WFQ в class-default queue,
- Обслуживание между очередями — на основании выделенной пропускной способности для каждой очереди.
[править] Проверка количества выделенной пропускной способности
Когда policy-map применяется к интерфейсу (команда service-policy output), IOS выполняет проверку не выделяет ли эта policy map слишком много пропускной способности для конкретного интерфейса. Если policy map не проходит проверку, то она не применяется к интерфейсу.
Проверка выполняется на основании двух команд указанных в режиме настройки интерфейса:
- bandwidth
- max-reserved-bandwidth
IOS позволяет policy map выделять пропускную способность величиной (сумма всех значений bandwidth) не более чем произведение значений bandwidth и max-reserved-bandwidth (по умолчанию 75 процентов).
Пример задания величин на интерфейсе (bandwidth задается в килобитах, а max-reserved-bandwidth а процентах):
После задания таких параметров, если на интерфейс fa0/0 применяется policy-map, то пропускная способность, которая выделена в ней не должна быть более чем 7000.
Применение policy-map на интерфейсе:
Policy-map не была применена так как максимальное значение пропускной способности которое может быть для неё выделено 7000. Первый класс забрал 4000, а оставшихся 3000 не хватает для второго класса. Поэтому и появляется ошибка, что доступно только 3000, а класс запросил 5000.
Существует другой вариант выделения пропускной способности для policy-map. При выделении пропускной способности для класса используются команды:
- bandwidth percent — процент пропускной способности выделенной для класса, процент считается от всей пропускной способности интерфейса. Сумма пропускной способности выделенной для классов в policy-map не должна превышать max-reserved-bandwidth настроенной на соответствующем интерфейсе.
- bandwidth remaining percent — процент пропускной способности выделенной для класса, процент считается от значения произведения bandwidth и max-reserved-bandwidth интерфейса. Сумма пропускной способности выделенной для классов в policy-map соответственно может быть 100 процентов.
В одной policy-map может использоваться только один из трёх вариантов выделения пропускной способности для класса (bandwidth, bandwidth percent или bandwidth remaining percent).
[править] Размер очереди для CBWFQ
Пример задания размера очереди для класса (диапазон от 1 до 4096 пакетов):
[править] Включение WFQ для класса по умолчанию
Для класса по умолчанию можно включить WFQ (и только для него):
[править] congestive-discard-threshold
[править] LLQ
Синтаксис команды для настройки LLQ:
Команда priority для класса:
- включает LLQ,
- резервирует пропускную способность,
- включает функцию policing,
- (опционально) указывает размер burst для policer (по умолчанию 20 процентов).
Пропускная способность может быть задана конкретным значением или процентами от пропускной способности интерфейса. В одной и той же policy-map могут использоваться различные способы указания пропускной способности priority или priority percent.
Суммарная пропускная способность выделенная в policy-map командами priority и bandwidth не должна превышать значение произведения bandwidth и max-reserved-bandwidth.
Фактически LLQ будет использоваться только когда аппаратная очередь заполнена.
Параметр bandwidth указывает максимальное значение пропускной способности, которое выделяется пакетам, которые принадлежат классу в котором указана команда priority. Этот параметр с одной стороны гарантирует указанную пропускную способность классу, с другой — сдерживает поток пакетов приоритетного класса.
Когда устройство не перегружено, то приоритетному классу разрешено превышать указанную пропускную способность. Если устройство перегружено, то трафик приоритетного класса, который превышает указанную пропускную способность, будет отброшен.
Пример policy-map в которой для class1 настроено LLQ:
Просмотр статистики по конкретному классу:
[править] Weighted Round Robin Queuing
Weighted Round Robin (WRR)
[править] Weighted Random Early Detection (WRED)
Tail drop — когда очередь заполнена, IOS начинает отбрасывать новые пакеты.
Weighted Random Early Detection (WRED) — отслеживает длину очереди и отбрасывает некоторый процент пакетов в очереди для улучшения производительности сети.
WRED отбрасывает пакеты до тех пор как очередь заполнится.
Для того чтобы определить достаточно ли полна очередь для того чтобы отбрасывать пакеты WRED измеряет среднюю глубину очереди (average queue depth). Затем, значение average depth сравнивается с minimum threshold и maximum threshold. В зависимости от результата сравнения выполняются различные действия.
| Значение average depth относительно threshold | Действие | Название действия в WRED |
|---|---|---|
| average < min threshold | Пакеты не отбрасываются | No drop |
| min threshold < average < max threshold | Процент пакетов отбрасывается. Процент пакетов, которые отбрасываются возрастает от 0 до максимального процента по мере приближения значения average к max threshold | Random drop |
| average > max threshold | Все новые пакеты отбрасываются | Full drop |
Mark probability denominator (MPD) — на основании этого значения вычисляется процент пакетов, которые будут отброшены.
WRED дает больший приоритет пакетам с определенными значениями IPP и DSCP. Для того чтобы сделать это WRED использует разные профили трафика (traffic profile) для пакетов с разными значениями IPP и DSCP.
WRED traffic profile состоит из настроек для трёх переменных:
- minimum threshold,
- maximum threshold,
- MPD.
Профили WRED заданные по умолчанию для DSCP-based WRED:
| DSCP | Min threshold | Max threshold | MPD | 1/MPD |
|---|---|---|---|---|
| AFx1 | 33 | 40 | 10 | 10% |
| AFx2 | 28 | 40 | 10 | 10% |
| AFx3 | 24 | 40 | 10 | 10% |
| EF | 37 | 40 | 10 | 10% |
Exponential weighting constant контролирует насколько быстро меняется средняя глубина очереди. Если значение константы меньше, то средняя глубина очереди меняется быстрее; если константа больше, то — медленнее. По умолчанию используется значение 9.
[править] Настройка WRED
WRED может быть настроен на:
- физическом интерфейсе (с FIFO очередью),
- для класса (класс должен быть не LLQ) внутри CBWFQ policy-map,
- для ATM VC.
Для использования WRED на физическом интерфейсе, IOS отключает остальные механизмы управления очередями и создает одну очередь FIFO.
Команды по настройке WRED аналогичны на интерфейсе и для класса внутри policy-map.
Включение WRED (по умолчанию включается WRED с использованием IPP):
Включение WRED с использованием DSCP для определения профиля трафика:
Изменение настроек по умолчанию WRED для конкретного значения IPP:
Изменение настроек по умолчанию WRED для конкретного значения DSCP:
Exponential weighting constant:
[править] Просмотр настроек
Пример вывода настроек:
[править] Modified Deficit Round-Robin (MDRR)
Утилита MDRR реализована только для маршрутизаторов Cisco 12000, так как они не поддерживают CBWFQ и LLQ.
MDRR позволяет классифицировать трафик на семь round-robin очередей (0-6), с одной дополнительной приоритетной очередью.
Если в приоритетной очереди нет пакетов, то WDRR обслуживает очереди по принципу round-robin. Если в приоритетной очереди есть пакеты, то WDRR может обрабатывать пакеты одним из вариантов:
- Strict priority mode — приоритетная очередь обслуживается сразу, как только там появляются пакеты;
- Alternate mode — приоритетная очередь обслуживается после каждой не приоритетной очереди.
MDRR поддерживает два типа scheduling.
- Quantum value (QV) — количество байтов. WDRR удаляет пакеты из очереди до тех пор пока QV для этой очереди будет удалено.
- Deficit — количество байт которые были обработаны сверх нормы (более чем QV). При следующем прохождении цикла с очереди в которой было взято больше байт, будет взято на эту же величину меньше.
[править] Управление перегрузками и избежание перегрузок на коммутаторах
Коммутаторы 3550 и 3560 выполняют входящее и исходящее управление очередями. У 3550 одна входящая очередь работающая по принципу FIFO. У 3560 две входящих очереди, одна из которых может быть настроена как приоритетная очередь.
В 3560 packet scheduler использует метод shared round-robin (SRR) для того чтобы контролировать отправку пакетов. На входящих очередях SRR разделяет пропускную способность между очередями, в соответствии с настроенными весами. Вес выполняет роль относительной, а не абсолютной величины.
Пол умолчанию, трафик промаркированный значением COS 5 попадает во вторую очередь, остальной в первую. Можно настроить назначение трафика в очередь по значению DSCP.
Настройка коэффициентов для очередей (по умолчанию 90 процентов в очередь 1 и 10 процентов в очередь 2):
Настройка процентов для пропускной способности, которые устанавливают частоту с которой scheduler берет пакеты из двух буферов (по умолчанию оба значения 4):
Две указанные команды вместе определяют какое количество данных коммутатор может
Настройка приоритетной очереди:
Коммутатор будет обслуживать приоритетную очередь до тех пор, пока пропускная способность не достигнет настроенного значения weight. После этого остальная пропускная способность разделяется между очередями.
[править] Shaping и Policing
[править] Терминология
- Tc — временной интервал, измеряемый в секундах, в течение которого может быть отправлен commited burst (Bc). Для многих shaping утилит Tc=Bc/CIR.
- Bc — commited burst rate, измеряется в битах. Количество трафика которое будет отправлено в течение Tc интервала.
- CIR — commited information rate, в битах в секунду, определяет rate VC в соответствии с контрактом.
- Shaped rate — rate, в битах за секунду, до которого конкретная настройка делает shape трафику. Может быть установлен или нет в значение равное CIR.
- Be — excess burst size, в битах. Количество битов, которое может быть отправлено сверх указанного Bc после периода неактивности.
[править] Shaping в сетях Frame-Relay
Minimum information rate (MIR) или mincir.
Уменьшает rate шейпер в том случае, если обнаруживает перегрузку с помощью одного из двух методов:
- получает кадр с установленным битом BECN (Backward Explicit Congestion Notification),
- получает проприетарное сообщение о перегрузке (congestion message) Cisco ForeSight.
При получении BECN или ForeSight сообщения, шейпер снижает rate на 25 процентов от максимального rate. Фактически уменьшается Bc и Be на 25 процентов, а Tc остается неизменным. Если опять приходит сообщение BECN или ForeSight, то происходит уменьшение ещё на 25 процентов. Так происходит то тех пор пока не будет достигнут mincir.
После получения 16 сообщений без BECN или ForeSight, rate снова возрастает.
[править] Class-based shaping
CB shaping может быть настроен только для исходящих пакетов и может быть применен к физическому интерфейсу или подынтерфейсу.
Должен быть указан shaping rate. Bc и Be могут быть опущены, а Tc не может быть задан напрямую. Соответственно CB shaping высчитывает неуказанные значения. Значения высчитываются по-разному в зависимости от того чему равен shaping rate.
| Переменная | Rate <= 320 kbps | Rate > 320 kbps |
|---|---|---|
| Bc | 8000 bits | Bc = shaping rate * Tc |
| Be | Be = Bc = 8000 | Be = Bc |
| Tc | Tc = Bc / shaping rate | 25ms |
[править] CB shaping peak rate
Если CB shaping настроен командой shape peak, то:
- значения Bc, Be, Tc высчитываются как и для команды shape average,
- токены Bc и Be (а не только Bc) пополняются каждый временной интервал.
[править] Generic Traffic Shaping
[править] Frame-Relay traffic shaping
Frame-Relay traffic shaping (FRTS):
- FRTS может использоваться только на frame-relay интерфейсах, а CB shaping может использоваться для любого протокола канального уровня.
- Как и CB shaping, FRTS позволяет использовать утилиты для управления очередями вместо одной очереди FIFO.
- В отличие от CB shaping, FRTS не позволяет включать дополнительные утилиты управления очередями на физическом интерфейсе одновременно с FRTS.
- FRTS всегда шейпит трафик в каждой VC отдельно.
- FRTS не может классифицировать трафик для того чтобы шейпить часть трафика конкретной VC.
- В отличие от CB shaping, FRTS может динамически получать значение CIR, Bc и Be, настроенные на FR-коммутаторе, используя Enhanced Local Management Interface (ELMI).
Пример явного указания параметров:
Настройка динамического реагирования маршрутизатора на основании BECN:
[править] CB policing
CB policing разделяет пакеты на две или три категории, в зависимости от вида policing, а затем применяет к каждой категории соответствующее действие.
- conforming
- exceeding
- violating
[править] Single-rate, two-color policing (one bucket)
Policer использует две категории:
- conform
- exceed
CB Policer заполняет bucket не на основании временных интервалов, а на основании пакетов.
Количество токенов высчитывается по формуле:
Так как токен представляет право на передачу одного байта, то результат разделен на 8, чтобы перевести его из битов в байты.
Когда приходит новый пакет, policer должен определить превышает или нет этот пакет установленный контракт.
Policer сравнивает количество байт в пакете (Xp) с количеством токенов в token bucket (Xb).
| Категория | Требования | Токены, которые забраны из bucket |
|---|---|---|
| Conform | Если Xp <= Xb | Xp токенов |
| Exceed | Если Xp > Xb | не забираются |
[править] Single-rate, three-color policing (two buckets)
Policer использует три категории:
- conform
- exceed
- violate
Xbc — количество токенов в Bc bucket, Xbe — количество токенов в Be bucket.
| Категория | Требования | Токены, которые забраны из bucket |
|---|---|---|
| Conform | Если Xp <= Xbc | Xp токенов из Bc bucket |
| Exceed | Если Xp > Xbc и Xp <= Xbe | Xp токенов из Be bucket |
| Violate | Если Xp > Xbc и Xp > Xbe | не забираются |
[править] Two-rate, three-color policing (two buckets)
- Commited information rate (CIR)
- Peak information rate (PIR)
Policer использует три категории:
- conform — пакеты передающиеся до CIR,
- exceed — пакеты передающиеся выше CIR, но до PIR,
- violate — пакеты передающиеся выше PIR.
[править] Настройка CB policing
Если не указаны значения Bc или Be, то используются значения по умолчанию, которые зависят от типа policing.
| Тип policing | Как определить тип по команде police | Значения по умолчанию |
|---|---|---|
| Single rate, two color | не настроено violate-action | Bc = CIR/32, Be = 0 |
| Single rate, three color | настроено violate-action | Bc = CIR/32, Be = Bc |
| Dual rate, three color | настроено PIR | Bc = CIR/32, Be = PIR/32 |
[править] Multi-action policing
Multi-action policing — маркировка нескольких полей в одном пакете с помощью CB policing.
[править] Commited access rate (CAR)
CAR это single-rate, two-color policing.
CAR оптимизирован для высокоскоростных соединений.
CAR применяется для входных и выходных интерфейсов (включая подинтерфейсы в том числе Frame Relay и ATM)
может так же использоваться для предотвращения DOS атак.
- access-group — аксесс лист классификации
- bps — скорость бит/с (commited access rate)
- burst-normal — размер всплеска рекомендовано считать по формуле ([4]):
- burst-normal = bps * (1 byte)/(8 bits) * 1.5 seconds
- burst-max — максимальный размер всплеска
- burst-max=burst-normal*2
- conform-action action — действие при соответствии ограничения
- exceed-action action — действие при превышении ограничения
- Возможные варианты действий:
- drop – уничтожить
- transmit — передать
- set-dscp-transmit – пометить пакет
Просмотр трафика, который попадает под CAR:
На интерфейс можно описывать любое число правил, ограничивающих трафик на данном интерфейсе
Следующий пример ограничивает ICMP трафик до 500 kb/s, а так же UDP трафик до уровня 2 Мб/s на одном из интерфейсов6.1 — Hold Queue and Tx-Ring
The Tx-Ring, also known as the Tx-Queue (transmit Queue) and as the hardware queue, is a small FIFO queue on each interface. It is the final queue before the packet is sent out the interface. The Tx-Ring’s purpose is to drive the link utilization to 100% when packets are waiting to exit an interface. The hardware queue can be accessed directly by the interface’s ASIC, so there is no need to wait on the general processor if it is busy.
The configured queues that exist are nothing more than a series of pointers to the memory buffers that hold the actual physical packets waiting to exit the interface. These are just software queues. All queuing tools that exist in IOS operate on software queues. The hardware queue, however, is an actual physical FIFO queue located on the interface. Its length can be adjusted manually, and IOS will automatically shorten the hardware queue when a software queueing method is configured.
Even if software queues exist, IOS checks the hardware queue for the outbound interface for available space. If it has availability, packets are sent directly to the hardware queue instead of being sent to the hold queues. The Hold Queues are available for both input and output. So, if the interface becomes congested, the TX-Ring fills up and packets are placed on its output hold queue instead, triggering congestion management.
Not suprisingly, the terminology is confusing when it comes to Hold Queues. To set the length (number of packets) of the input or output hold queues, use the following interface commands:
However, if you then want to view them under the show interfaces command, you will see them called input and output queues.
To set the Tx-ring size, use the following:
Then to ensure it was set correctly, you must use the show controllers command.
TX-ring-limit Values
So, I am getting deep into my CCIE study and I just read about the TX-ring-limit interface command. I have used QoS a bit to oversubscribe software buffers to prevent frame loss on switches and whatnot, can you use the «TX-ring-limit» in a similar manner to decrease the likelihood of frame loss during bursty traffic on a LAN?
Additionally I understand the following:
1) TX-ring-limit should be set to either a value of 1 or 2 for a low speed interface such as a T1 serial
2) Higher values can be configured on higher speed interfaces
3) Setting a high value can introduce jitter on a link because the software queue of a IOS device will send the packets to the hardware queue where they are simply FIFOHas anyone experimented with setting this to a higher value on ethernet LAN interfaces to allow the hardware queue to «hold on to frames» during a bursty traffic period, rather than drop them?
Understanding and Tuning the tx-ring-limit Value
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Contents
Introduction
This document discusses the function of a hardware transmit ring and the purpose of the tx-ring-limit command on ATM router interface hardware that supports per-virtual circuit (VC) queueing.
Cisco router interfaces configured with service policies store packets for an ATM VC in one of two sets of queues depending on the congestion level of the VC:
Queue Location Queueing Methods Service Policies Apply Command to Tune Hardware queue or transmit ring Port adapter or network module FIFO only No tx-ring-limit Layer-3 queue Layer-3 processor system or interface buffers N/A Yes Varies with queueing method: — vc-hold-queue — queue-limit Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Understanding Particles
Before discussing the transmit ring, we first need to understand what a particle is. A particle forms the basic building block of packet buffering on many platforms, including the Cisco 7200 router series and the versatile interface processor (VIP) on the Cisco 7500 router series.
Depending on the packet length, Cisco IOS® software uses one or more particles to store a packet. Let’s look at an example. When receiving a 1200-byte packet, IOS retrieves the next free particle and copies the packet data into the particle. When the first particle is filled, IOS moves to the next free particle, links it to the first particle, and continues copying the data into this second particle. Upon completion, the 1200 bytes of the packet are stored in three discontiguous pieces of memory that IOS logically makes a part of a single packet buffers.
IOS particle size varies from platform to platform. All particles within a given pool are the same size. This uniformity simplifies the particle management algorithms and helps contribute to efficient memory use.
Understanding Buffer Rings
Along with public and private interface pools, Cisco IOS creates special buffer control structures called rings. Cisco IOS and interface controllers use these rings to control which buffers are used to receive and transmit packets to the media. The rings themselves consist of media-controller-specific elements that point to individual packet buffers elsewhere in I/O memory.
Each interface has a pair of rings — a receive ring for receiving packets and a transmit ring for transmitting packets. The size of the rings can vary with the interface controller. In general, the size of the transmit ring is based on bandwidth of the interface or VC and is a power of two (Cisco Bug ID CSCdk17210).
Interface Rings Line Rate(Mb/s) < 2 10 20 30 40 . txcount 2 4 8 16 32 64 Note: On the 7200 series platform, the transmit ring packet buffers come from the receive ring of the originating interface for a switched packet or from a public pool if the packet was originated by IOS. They are deallocated from the transmit ring and returned to their original pool after the payload data is transmitted.
PA-A3 Architecture Overview
To ensure high forwarding performance, the PA-A3 port adapter uses separate receive and transmit segmentation and reassembly (SAR) chips. Each SAR is supported by its own subsystem of onboard memory to store packets as well as key data structures like the VC table. This memory specifically includes 4 MB of SDRAM, which is chunked into particles.
The following table illustrates the number and size of particles on the receive and transmit paths on the PA-A3.
Ring Particle Size Number of Particles Receive Ring 288 bytes n/a Transmit Ring 576* bytes 6000 (144 particles are reserved) * The transmit ring’s particle size also is described as being 580 bytes. This value includes the 4-byte ATM core header that travels with the packet inside the router.
The sizes in the above table were selected because they are divisible by 48 (the size of a cell’s payload field) and by the cache line size (32 bytes) for maximum performance. They are designed to prevent the SAR from introducing inter-buffer delay when a packet requires multiple buffers. The transmit particle size of 576 bytes also was selected to cover about 90 percent of Internet packets.
Transmit Ring Allocation Scheme on the PA-A3
The PA-A3 driver assigns a default transmit-ring value to each VC. This value varies with the ATM service category assigned to the VC. The following table lists the default values.
VC Service Category PA-A3-OC3, T3, E3 Default Transmit Ring Value PA-A3-IMA Default Transmit Ring Value PA-A3-OC12 Default Transmit Ring Value Time of Enforcement VBR-nrt Based on formula**: (48 x SCR) / (Particle_size x 5) Minimum value is 40, and overrides any calculated value less than 40 with a very low SCR. Note: SCR is the cell rate with ATM overhead included. Based on formula: (48 x SCR) / (Particle_size x 5) Minimum value is 40, and overrides any calculated value less than 40 with a very low SCR. Note: SCR is the cell rate with ATM overhead included. Based on the following formula: Average rate (SCR) * 2 * TOTAL_CREDITS / VISIBLE_BANDWIDTH TOTAL_CREDITS = 8192 VISIBLE_BANDWIDTH = 599040 Note: If this formula calculates a value which is less than the default of 128, then the VC’s transmit ring limit is set to 128. Always ABR 128 128 N/A Always* UBR 40 128 128 Only when total credit utilization exceeds 75 percent or the tx_threshold value, as shown in show controller atm. * Originally, the PA-A3-OC12 did not implement always-active limiting of VBR-nrt PVCs to the current transmit ring value. Bug ID CSCdx11084 resolves this issue. .
** SCR should be expressed in cells/sec.
Displaying the Current Transmit Ring Values
Originally, the value of the transmit ring was only visible via a hidden command. The show atm vc command now displays the current value.
You also can use the debug atm events command to view the VC setup messages between the PA-A3 driver and the host CPU. The following sets of output were captured on a PA-A3 in a 7200 series router. The transmit ring value is displayed as the tx_limit value, which implements the particle buffer quota allocated for a specific VC in the transmit direction.
PVC 1/100 is configured as VBR-nrt. Based on an SCR of 3500 kbps, the PA-A3 assigns a tx_limit of 137. To see how this calculation is made, we need to convert an SCR of 3500 kbps to cells/sec. Notice that (3,500,000 bits /sec) * (1 byte / 8 bits) * (1 cell / 53 byes ) = (3, 500, 000 cells) / (8 * 53 sec) = 8254 cells / sec. Once we have the SCR value in cells / sec, we can apply the formula above to ger tx_limit = 137.
PVC 1/101 is configured as ABR. The PA-A3 assigns the default ABR tx_limit value of 128. (See the table above.)
PVC 1/102 is configured as UBR. The PA-A3 assigns the default UBR tx_limit value of 40. (See the table above.)
The purpose of the tx_limit is to implement a per-VC transmit credit or memory allocation scheme that prevents any consistently oversubscribed VC from grabbing all the packet buffer resources and hindering other VCs from transmitting normal traffic within their traffic contracts.
The PA-A3 implements a memory credit check under two conditions:
Individual quota on each VBR-nrt and ABR VC — Compares each VC’s tx_count and tx_limit values. It discards subsequent packets when the tx_count is greater than the tx_limit on any one VC. It is important to note that a burst of packets can exceed the transmit ring of a VBR-nrt VC at an instant in time and lead to output drops.
Overall quota — Considers the tx_threshold value. The PA-A3 allows for larger bursts on UBR VCs by enforcing traffic policing on such VCs only when the total packet buffer usage on the PA-A3 reaches this preset threshold.
Note: If a packet requires multiple particles and the transmit ring is full, the PA-A3 allows a VC to exceed its quota if particles are available. This scheme is designed to accommodate a small burst of packets without output drops.
The show controller atm command displays several counters relevant to transmit credits.
The following table describes the values used by the PA-A3 to enforce the overall transmit credit scheme:
Note: The PA-A3 microcode also tracks the tx_count of each VC. When a particle is sent to the PA-A3 microcode from the PA-A3 driver, the tx_count increments by one.
When Should the Transmit Ring Be Tuned?
The transmit ring serves as a staging area for packets in line to be transmitted. The router needs to enqueue a sufficient number of packets on the transmit ring and ensure that the interface driver has packets with which to fill available cell timeslots.
Originally, the PA-A3 driver did not adjust the transmit ring size when a service policy with low latency queueing (LLQ) was applied. With current images, the PA-A3 tunes down the value from the above defaults (Cisco Bug ID CSCds63407) to minimize queueing-related delay.
The primary reason to tune the transmit ring is to reduce latency caused by queueing. When tuning the transmit ring, consider the following:
On any network interface, queueing forces a choice between latency and the amount of burst that the interface can sustain. Larger queue sizes sustain longer bursts while increasing delay. Tune the size of a queue when you feel the VC’s traffic is experiencing unnecessary delay.
Consider the packet size. Configure a tx-ring-limit value that accommodates four packets. For example, if your packets are 1500 bytes, set a tx-ring-limit value of 16 = (4 packets) * (4 particles).
Ensure the transmit credit is large enough to support one MTU-sized packet and/or the number of cells equal to the maximum burst size (MBS) for a VBR-nrt PVC.
Configure a low value with low-bandwidth VCs, such as a 128 kbps SCR. For example, on a low-speed VC with an SCR of 160 kbps, a tx-ring-limit of ten is relatively high and can lead to significant latency (for example, hundreds of milliseconds) in the driver-level queue. Tune the tx-ring-limit down to its minimum value in this configuration.
Configure higher values for high-speed VCs. Selecting a value of less than four may inhibit the VC from transmitting at its configured rate if the PA-A3 implements back pressure too aggressively and the transmit ring does not have a ready supply of packets waiting to be transmitted. Ensure that a low value does not affect VC throughput. (See Cisco Bug ID CSCdk17210.)
In other words, the size of the transmit ring needs to be small enough to avoid introducing latency due to queueing, and it needs to be large enough to avoid drops and a resulting impact to TCP-based flows.
An interface first removes the packets from the layer-3 queueing system and then queues them on the transmit ring. Service policies apply only to packets in the layer-3 queues and are transparent to the transmit ring.
Queueing on the transmit ring introduces a serialization delay that is directly proportional to the depth of the ring. An excessive serialization delay can impact latency budgets for delay-sensitive applications such as voice. Thus, Cisco recommends reducing the size of the transmit ring for VCs carrying voice. Select a value based on the amount of amount of serialization delay, expressed in seconds, introduced by the transmit ring. Use the following formula:
Note: IP packets on the Internet are typically one of three sizes: 64 bytes (for example, control messages), 1500 bytes (for example, file transfers), or 256 bytes (all other traffic). These values produce a typical overall Internet packet size of 250 bytes.
Note: The following table summarizes the advantages and disadvantages of larger or smaller transmit ring sizes:
Size of Transmit Ring Advantage Disadvantage High Value Recommended for data VCs to accommodate bursts. Not recommended for voice VCs. Can introduce increased latency and jitter. Low Value Recommended for voice VCs to reduce delay due to queueing and jitter. Not recommended for relatively high-speed VCs. Can introduce reduced throughput if tuned to such a low value that no packets are ready to be sent once the wire is free. Use the tx-ring-limit command in VC configuration mode to tune the size of the transmit ring.
Use the show atm vc command to display the currently configured value.
In addition, use the show atm pvc vpi/vci command to view both the current transmit and receive ring limits. The following output was captured on a 7200 Series router running Cisco IOS Software Release 12.2(10).
Impact of Very Small tx-ring-limit Values
On the transmit path, the host CPU transfers the payload from the host buffers to the local particle buffers on the PA-A3. The firmware running on the PA-A3 caches several buffer descriptors and frees them in a group. During the caching period, the PA-A3 does not accept new packets even though the contents of the local memory have been transmitted on the physical wire. The purpose of this scheme is to optimize overall performance. Thus, when configuring a non-default tx-ring-limit value, consider the buffer descriptor return delay.
In addition, if you configure a tx-ring-limit value of one with given a particle size of 576 bytes, a 1500-byte packet is removed from the queue as follows:
The PA-A3 driver queues the first particle in the transmit ring, and remembers that this packet is stored in two other memory particles.
During the next time that the transmit ring is empty, the second particle of the packet is put in the transmit ring.
During the next time that the transmit ring is empty again, the third particle is put in the transmit ring.
Even though the transmit ring consists of only one 576 byte particle, MTU/port-speed is still the worst-case latency through the transmit ring.
Known Issues
When the tx-ring-limit command is applied to a VC through a vc-class statement, the PA-A3 does not apply the configured value. Confirm this result by displaying the current value in the show atm vc detail command. Tuning the transmit ring using a vc-class was implemented in Cisco IOS Software Release 12.1 (Cisco Bug ID CSCdm93064). CSCdv59010 resolves a problem with the tx-ring-limit in certain versions of Cisco IOS Software Release 12.2. When you apply the tx-ring-limit command through the vc-class statement to an ATM PVC, the transmit ring size is not modified. Confirm this result using the show atm vc detail command, after applying the command through the vc-class and class-vc command pairs.
When added to a PVC on a PA-A3 in a Cisco 7200 series router running Cisco IOS Software Release 12.2(1), the tx-ring-limit command is duplicated, as shown below (Cisco Bug ID CSCdu19350).
The condition is harmless and does not affect the operation of the router.
Cisco bug ID CSCdv71623 resolves a problem with output drops on a multilink PPP bundle interface when the traffic rate is well below the line rate. This problem was seen in CSCdv89201 on an ATM interface with a tx-ring-limit value greater than five. The problem becomes particularly apparent when fragmentation is disabled or when the link weights (fragment size limits) are large — common on higher speed links like T1s or E1s — and the data traffic consists of a mix of small and large packets. Enabling fragmentation and using a small fragment size (set by the interface configuration command ppp multilink fragment delay) improves operation significantly. However, you should verify that your router has sufficient processing capacity to support these high levels of fragmentation without overloading the system CPU, before using this as a workaround.
Cisco bug ID CSCdw29890 resolves a problem with the tx-ring-limit command being accepted by the CLI for ATM PVC bundles, but not taking effect. However, you do not normally need to change the tx-ring-limit on ATM PVC bundles. The reason is that, reducing the ring size effectively moves all the transmit buffering to a QoS-controlled queue, so an arriving priority packet is transmitted immediately to minimize delay on low-speed interfaces. With ATM PVC bundles, cells from packets of all the member VCs are always sent simultaneously (and interleaved), so the delay is minimized automatically.
Tuning the tx-ring-limit on 3600 and 2600 Routers
Current Cisco IOS software images support tuning the transmit ring on the ATM network modules for Cisco 2600 and 3600 series routers (Cisco Bug ID CSCdt73385). The current value appears in the show atm vc output.
- Возможные варианты действий: