Tx ring limit что это

Значения TX-ring-limit

Итак, я углубляюсь в свое исследование CCIE, и я просто прочитал команду интерфейса интерфейса TX-ring. Я использовал QoS немного для избыточных подписей программных буферов, чтобы предотвратить потерю кадров на коммутаторах и еще много чего, можете ли вы использовать «TX-ring-limit» таким же образом, чтобы уменьшить вероятность потери кадров во время пакетного трафика в локальной сети?

Кроме того, я понимаю следующее:
1) Предел TX-ring должен быть установлен как значение 1 или 2 для интерфейса с низкой скоростью, например, T1 serial
2) Более высокие значения могут быть сконфигурированы на высокоскоростных интерфейсах
3) Установка большого значения может привести к дрожанию по ссылке, поскольку очередь программного обеспечения устройства IOS отправит пакеты в очередь оборудования, где они просто FIFO

Кто-нибудь экспериментировал с установкой этого на более высокое значение в интерфейсах локальной сети Ethernet, чтобы позволить аппаратной очереди «держаться за кадры» в течение периода интенсивного трафика, а не бросать их?

1 ответ

TX-Ring — это очередь аппаратного интерфейса и FIFO. QOS не начинает работать в маршрутизаторе до тех пор, пока TX-Ring не будет заполнен. Компромисс — это небольшое TX-Ring, которое заставляет QoS быстрее сокращать (хорошо, когда вы хотите использовать LLQ для VoIP) за счет процессора, большое TX-Ring использует меньше CPU (не нужно обслуживать очередь столько же ), но увеличит дрожание (помните, что очередь — Fifo) для приложений voip. Это важная кнопка настройки VoIP на старых маршрутизаторах cisco по вышеуказанным причинам.

Это не влияет на падение, потому что TX-Ring существует только в маршрутизаторах и когда tx-звонок является полным трафиком, помещается в очередь в памяти маршрутизатора.

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 на одном из интерфейсов

    Защищаемся маршрутизатором: QoS

    QoS — тема большая. Прежде чем рассказывать про тонкости настроек и различные подходы в применении правил обработки трафика, имеет смысл напомнить, что такое вообще QoS.

    Quality of Service (QoS) — технология предоставления различным классам трафика различных приоритетов в обслуживании.

    Во-первых, легко понять, что любая приоритезация имеет смысл только в том случае, когда возникает очередь на обслуживание. Именно там, в очереди, можно «проскользнуть» первым, используя своё право.
    Очередь же образуется там, где узко (обычно такие места называются «бутылочным горлышком», bottle-neck). Типичное «горлышко» — выход в Интернет офиса, где компьютеры, подключенные к сети как минимум на скорости 100 Мбит/сек, все используют канал к провайдеру, который редко превышает 100 МБит/сек, а часто составляет мизерные 1-2-10МБит/сек. На всех.

    Во-вторых, QoS не панацея: если «горлышко» уж слишком узкое, то часто переполняется физический буфер интерфейса, куда помещаются все пакеты, собирающиеся выйти через этот интерфейс. И тогда новопришедшие пакеты будут уничтожены, даже если они сверхнужные. Поэтому, если очередь на интерфейсе в среднем превышает 20% от максимального своего размера (на маршрутизаторах cisco максимальный размер очереди составляет как правило 128-256 пакетов), есть повод крепко задуматься над дизайном своей сети, проложить дополнительные маршруты или расширить полосу до провайдера.

    Разберемся с составными элементами технологии

    (дальше под катом, много)

    Маркировка. В полях заголовков различных сетевых протоколов (Ethernet, IP, ATM, MPLS и др.) присутствуют специальные поля, выделенные для маркирования трафика. Маркировать же трафик нужно для последующей более простой обработки в очередях.

    Ethernet. Поле Class of Service (CoS) — 3 бита. Позволяет разделить трафик на 8 потоков с различной маркировкой

    IP. Есть 2 стандарта: старый и новый. В старом было поле ToS (8 бит), из которого в свою очередь выделялись 3 бита под названием IP Precedence. Это поле копировалось в поле CoS Ethernet заголовка.
    Позднее был определен новый стандарт. Поле ToS было переименовано в DiffServ, и дополнительно выделено 6 бит для поля Differencial Service Code Point (DSCP), в котором можно передавать требуемые для данного типа трафика параметры.

    Маркировать данные лучше всего ближе к источнику этих данных. По этой причине большинство IP-телефонов самостоятельно добавляют в IP-заголовок голосовых пакетов поле DSCP = EF или CS5. Многие приложения также маркируют трафик самостоятельно в надежде, что их пакеты будут обработаны приоритетно. Например, этим «грешат» пиринговые сети.

    Даже если мы не используем никаких технологий приоритезации, это не значит, что не возникает очередей. В узком месте очередь возникнет в любом случае и будет предоставлять стандартный механизм FIFO (First In First Out). Такая очередь, очевидно, позволит не уничтожать пакеты сразу, сохраняя их до отправки в буфере, но никаких преференций, скажем, голосовому трафику не предоставит.

    Если хочется предоставить некоторому выделенному классу абсолютный приоритет (т.е. пакеты из этого класса всегда будут обрабатываться первыми), то такая технология называется Priority queuing. Все пакеты, находящиеся в физическом исходящем буфере интерфейса будут разделены на 2 логических очереди и пакеты из привилегированной очереди будут отсылаться, пока она не опустеет. Только после этого начнут передаваться пакеты из второй очереди. Эта технология простая, довольно грубая, её можно считать устаревшей, т.к. обработка неприоритетного трафика будет постоянно останавливаться. На маршрутизаторах cisco можно создать
    4 очереди с разными приоритетами. В них соблюдается строгая иерархия: пакеты из менее привилегированных очередей не будут обслуживаться до тех пор, пока не опустеют все очереди с более высоким приоритетом.

    Справедливая очередь (Fair Queuing). Технология, которая позволяет каждому классу трафика предоставить одинаковые права. Как правило не используется, т.к. мало даёт с точки зрения улучшения качества сервиса.

    Взвешенная справедливая очередь (Weighted Fair Queuing, WFQ). Технология, которая предоставляет разным классам трафика разные права (можно сказать, что «вес» у разных очередей разный), но одновременно обслуживает все очереди. «На пальцах» это выглядит так: все пакеты делятся на логические очереди, используя в
    качестве критерия поле IP Precedence. Это же поле задаёт и приоритет (чем больше, тем лучше). Дальше, маршрутизатор вычисляет, пакет из какой очереди «быстрее» передать и передаёт именно его.

    

    Считает он это по формуле:

    IPP — значение поля IP Precedence
    t(i) — Время, требуемое на реальную передачу пакета интерфейсом. Можно вычислить, как L/Speed, где L — длина пакета, а Speed — скорость передачи интерфейса

    Такая очередь по умолчанию включена на всех интерфейсах маршрутизаторов cisco, кроме интерфейсов точка-точка (инкапсуляция HDLC или РРР).

    WFQ имеет ряд минусов: такая очередизация использует уже отмаркированные ранее пакеты, и не позволяет самостоятельно определять классы трафика и выделяемую полосу. Мало того, как правило уже никто не маркирует полем IP Precedence, поэтому пакеты идут немаркированные, т.е. все попадают в одну очередь.

    Развитием WFQ стала взвешенная справедливая очередь, основанная на классах (Class-Based Weighted Fair Queuing, CBWFQ). В этой очереди администратор сам задаёт классы трафика, следуя различным критериям, например, используя ACL, как шаблон или анализируя заголовки протоколов (см.NBAR). Далее, для этих классов
    определяется «вес» и пакеты их очередей обслуживаются, соразмерно весу (больше вес — больше пакетов из этой очереди уйдёт в единицу времени)

    Но такая очередь не обеспечивает строгого пропускания наиболее важных пакетов (как правило голосовых или пакетов других интерактивных приложений). Поэтому появился гибрид Priority и Class-Based Weighted Fair Queuing — PQ-CBWFQ, также известный как, Low Latency Queuing (LLQ). В этой технологии можно задать до 4х приоритетных очередей, остальные классы обслуживать по механизму CBWFQ

    LLQ — наиболее удобный, гибкий и часто используемый механизм. Но он требует настройки классов, настройки политики и применения политики на интерфейсе.

    Подробнее о настройках расскажу дальше.

    Таким образом процесс предоставления качества обслуживания можно поделить на 2 этапа:
    Маркировка. Поближе к источникам.
    Обработка пакетов. Помещение их в физическую очередь на интерфейсе, подразделение на логические очереди и предоставление этим логическим очередям различных ресурсов.

    Технология QoS — достаточно ресурсоёмкая и весьма существенно грузит процессор. И тем сильнее грузит, чем глубже в заголовки приходится залезать для классификации пакетов. Для сравнения: маршрутизатору гораздо проще заглянуть в заголовок IP пакета и проанализировать там 3 бита IPP, нежели раскручивать поток практически до уровня приложения, определяя, что за протокол идёт внутри (технология NBAR)

    Для упрощения дальнейшей обработки трафика, а также для создания так называемой «области доверия» (trusted boundary), где мы верим всем заголовкам, относящимся к QoS, мы можем делать следующее:
    1. На коммутаторах и маршрутизаторах уровня доступа (близко к клиентским машинам) ловить пакеты, раскидывать их по классам
    2.В политике качестве действия перекрашивать заголовки по-своему или переносить значения QoS-заголовков более высокого уровня на нижние.

    Например, на маршрутизаторе ловим все пакеты из гостевого WiFi домена (предполагаем, что там могут быть не управляемые нами компьютеры и софт, который может использовать нестандартные QoS-заголовки), меняем любые заголовки IP на дефолтные, сопоставляем заголовкам 3 уровня (DSCP) заголовки канального уровня (CoS),
    чтобы дальше и коммутаторы могли эффективно приоритезировать трафик, используя только метку канального уровня.

    Настройка LLQ

    Настройка очередей заключается в настройке классов, затем для этих классов надо определить параметры полосы пропускания и применить всю созданную конструкцию на интерфейс.

    class-map NAME
    match?

    access-group Access group
    any Any packets
    class-map Class map
    cos IEEE 802.1Q/ISL class of service/user priority values
    destination-address Destination address
    discard-class Discard behavior identifier
    dscp Match DSCP in IP(v4) and IPv6 packets
    flow Flow based QoS parameters
    fr-de Match on Frame-relay DE bit
    fr-dlci Match on fr-dlci
    input-interface Select an input interface to match
    ip IP specific values
    mpls Multi Protocol Label Switching specific values
    not Negate this match result
    packet Layer 3 Packet length
    precedence Match Precedence in IP(v4) and IPv6 packets
    protocol Protocol
    qos-group Qos-group
    source-address Source address
    vlan VLANs to match

    Пакеты в классы можно рассортировывать по различным атрибутам, например, указывая ACL, как шаблон, либо по полю DSCP, либо выделяя конкретный протокол (включается технология NBAR)

    policy-map POLICY
    class NAME1
    ?

    bandwidth Bandwidth
    compression Activate Compression
    drop Drop all packets
    log Log IPv4 and ARP packets
    netflow-sampler NetFlow action
    police Police
    priority Strict Scheduling Priority for this Class
    queue-limit Queue Max Threshold for Tail Drop
    random-detect Enable Random Early Detection as drop policy
    service-policy Configure Flow Next
    set Set QoS values
    shape Traffic Shaping

    Для каждого класса в политике можно либо выделить приритетно кусок полосы:

    policy-map POLICY
    class NAME1
    priority?

    [8-2000000] Kilo Bits per second
    percent % of total bandwidth

    и тогда пакеты этого класса смогут всегда рассчитывать как минимум на этот кусок.

    Либо описать, какой «вес» имеет данный класс в рамках CBWFQ

    policy-map POLICY
    class NAME1
    bandwidth?

    [8-2000000] Kilo Bits per second
    percent % of total Bandwidth
    remaining % of the remaining bandwidth

    В обоих случаях можно указать как аболютное значение, так и процент от всей доступной полосы

    Возникает резонный вопрос: а откуда маршрутизатор знает ВСЮ полосу? Ответ банален: из параметра bandwidth на интерфейсе. Даже если он не сконфигурирован явно, какое то его значение обязательно есть. Его можно посмотреть командой sh int.

    Также обязательно помнить, что по умолчанию вы распоряжаетсь не всей полосой, а лишь 75%. Пакеты, явно не попавшие в другие классы, попадают в class-default. Эту настройку для дефолтного класса можно задать явно

    policy-map POLICY
    class class-default
    bandwidth percent 10
    

    (UPD, спасибо OlegD)

    Изменить максимальную доступную полосу с дефолтных 75% можно командой на интерфейсе

    max-reserved-bandwidth [percent]

    Маршрутизаторы ревностно следят, чтобы админ не выдал случайно больше полосы, чем есть и ругаются на такие попытки.

    Создаётся впечатление, что политика будет выдавать классам не больше, чем написано. Однако, такая ситуация будет лишь в том случае, если все очереди наполнены. Если же какая то пустует, то выделенную ей полосу наполненные очереди поделят пропорционально своему «весу».

    Работать же вся эта конструкция будет так:

    Если идут пакеты из класса с указанием priority, то маршрутизатор сосредотачивается на передаче этих пакетов. Причем, т.к. таких приоритетных очередей может быть несколько, то между ними полоса делится пропорционально указанным процентам.

    Как только все приоритетные пакеты закончились, наступает очередь CBWFQ. За каждый отсчёт времени из каждой очереди «зачёрпывается» доля пакетов, указанная в настройке для данного класса. Если же часть очередей пустует, то их полоса делится пропорционально «весу» класса между загруженными очередями.

    Применение на интерфейсе:

    int s0/0
    service-policy [input|output] POLICY
    

    А что же делать, если надо строго рубить пакеты из класса, выходящие за дозволенную скорость? Ведь указание bandwidth лишь распределяет полосу между классами, когда очереди загружены.

    Для решения этой задачи для класса трафика в политике есть технология

    police [speed] [birst] conform-action [действие] exceed-action [действие]

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

    police 100000 8000 conform-action?

    drop drop packet
    exceed-action action when rate is within conform and
    conform + exceed burst
    set-clp-transmit set atm clp and send it
    set-discard-class-transmit set discard-class and send it
    set-dscp-transmit set dscp and send it
    set-frde-transmit set FR DE and send it
    set-mpls-exp-imposition-transmit set exp at tag imposition and send it
    set-mpls-exp-topmost-transmit set exp on topmost label and send it
    set-prec-transmit rewrite packet precedence and send it
    set-qos-transmit set qos-group and send it
    transmit transmit packet

    Часто возникает также и другая задача. Предположим, что надо ограничить поток, идущий в сторону соседа с медленным каналом.

    

    Дабы точно предсказать, какие пакеты дойдут до соседа, а какие будут уничтожены в силу загруженности канала на «медленной» стороне, надо на «быстрой» стороне создать политику, которая бы заранее обрабатывала очереди и уничтожала избыточные пакеты.

    И тут мы сталкиваемся с одной очень важной вещью: для решения этой задачи надо сэмулировать «медленный» канал. Для этой эмуляции не достаточно только раскидать пакеты по очередям, надо ещё сэмулировать физический буфер «медленного» интерфейса. У каждого интерфейса есть скорость передачи пакетов. Т.е. в единицу времени каждый интерфейс может передать не более, чем N пакетов. Обычно физический буфер интерфейса рассчитывают так, чтобы обеспечить «автономную» работу интерфейсу на несколько единиц вермени. Поэтому физический буфер, скажем, GigabitEthernet будет в десятки раз больше какого-нибудь интерфейса Serial.

    Что же плохого в том, чтобы запомнить много? Давайте рассмотрим подробно, что произойдёт, в случае если буфер на быстрой передающей стороне будет существенно больше буфера принимающей.

    Пусть для простоты есть 1 очередь. На «быстрой» стороне сэмулируем малую скорость передачи. Это значит, что попадая под нашу политику пакеты начнут накапливаться в очереди. Т.к. физический буфер большой, то и логическая очередь получится внушительной. Часть приложений (работающих через ТСР) поздно получат уведомление о том, что часть пакетов не получена и долго будут держать большой размер окна, нагружая сторону-приемник. Это будет происходить в том идеальном случае, когда скорость передачи будет равна или меньше скорости приёма. Но интерфейс принимающей стороны может быть сам загружен и другими пакетами
    и тогда маленькая очередь на принимающей стороне не сможет вместить всех пакетов, передаваемых ей из центра. Начнутся потери, которые повлекут за собой дополнительные передачи, но в передающем буфере ведь ещё останется солидный «хвост» ранее накопленных пакетов, которые будут передаваться «вхолостую», т.к. на принимающей стороне не дождались более раннего пакета, а значит более позние будут просто проигнорированы.

    Поэтому для корректного решения задачи понижения скорости передачи к медленному соседу физический буфер тоже надо ограничить.

    Делается это командой

    shape average [speed]

    Ну а теперь самое интересное: а как быть, если мне помимо эмуляции физического буфера надо внутри него создать логические очереди? Например, выделить приоритетно голос?

    Для это создаётся так называемая вложенная политика, которая применяется внутри основной и делит на логические очереди то, что в неё попадает из родительской.

    Пришло время разобрать какой-нибудь залихватский пример на основе приведенной картинки.

    Пусть мы собираеися создать устойчиво работающие голосовые каналы через интернет между CO и Remote. Для простоты пусть сеть Remote (172.16.1.0/24) имеет только связь с СО (10.0.0.0/8). Скорость интерфейса на Remote — 1 Мбит/сек и выделяется 25% этой скорости на голосовой трафик.

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

    class-map RTP
    match protocol rtp

    policy-map RTP
    class RTP
    priority percent 25

    ip access-list extended CO_REMOTE
    permit ip 10.0.0.0 0.255.255.255 172.16.1.0 0.0.0.255

    class-map CO_REMOTE
    match access-list CO_REMOTE

    На Remote поступим иначе: пусть в силу дохлости железа мы не можем использовать NBAR, тогда нам остаётся только явно описать порты для RTP

    ip access-list extended RTP
    permit udp 172.16.1.0 0.0.0.255 range 16384 32768 10.0.0.0 0.255.255.255 range 16384 32768

    class-map RTP
    match access-list RTP

    policy-map QoS
    class RTP
    priority percent 25

    Далее, на СО надо сэмулировать медленный интерфейс, применить вложенную политику для приоритезации голосовых пакетов

    policy-map QoS
    class CO_REMOTE
    shape average 1000000
    service-policy RTP

    и применить политику на интерфейсе

    int g0/0
    service-policy output QoS
    

    На Remote установим параметр bandwidth (в кбит/сек) в соответствие со скоростью интерфейса. Напомню, что именно от этого параметра будет считаться 25%. И применим политику.

    int s0/0
    bandwidth 1000
    service-policy output QoS
    

    Повествование было бы не полным, если не охватить возможности коммутаторов. Понятно, что чисто L2 коммутаторы не способны так глубоко заглядывать в пакеты и делить их на классы по тем же критериям.

    На более умных L2/3 коммутаторах на маршрутизируемых интерфейсах (т.е. либо на interface vlan, либо если порт выведен со второго уровня командой no switchport) применяется та же конструкция, что работает и на маршрутизаторах, а если порт или весь коммутатор работает в режиме L2 (верно для моделей 2950/60), то там для класса трафика можно использовать только указание police, а priority или bandwidth не доступны.

    С сугубо защитной точки зрения, знание основ QoS позволит оперативно предотвращать бутылочные горла, вызванные работой червей. Как известно, червь сам по себе довольно агрессивен на фазе распространения и создаёт много паразитного трафика, т.е. по сути атаку отказа в обслуживании (Denial of Service, DoS).

    Причем часто червь распространяется по нужным для работы портам (ТСР/135,445,80 и др.) Просто закрыть на маршрутизаторе эти порты было бы опрометчиво, поэтому гуманнее поступать так:

    1. Собираем статистику по сетевому трафику. Либо по NetFlow, либо NBARом, либо по SNMP.

    2. Выявляем профиль нормального трафика, т.е. по статистике, в среднем, протокол HTTP занимает не больше 70%, ICMP — не больше 5% и т.д. Такой профиль можно либо создать вручную, либо применив накопленную NBARом статистику. Мало того, можно даже автоматически создать классы, политику и применить на интерфейсе
    командой autoqos 🙂

    3. Далее, можно ограничить для нетипичного сетевого трафика полосу. Если вдруг и подцепим заразу по нестандартному порту, большой беды для шлюза не будет: на загруженном интерфейсе зараза займет не более выделенной части.

    4. Создав конструкцию (class-map — policy-map — service-policy) можно оперативно реагировать на появление нетипичного всплеска трафика, создавая вручную для него класс и сильно ограничивая полосу для этого класса.

    Похожие публикации:

    1. Как сделать две независимые колонки в ворде
    2. Todouble c что это
    3. Tpl что это
    4. Trim c что это