Qos что это в роутере cisco

Table Of Contents

Configuring QoS in a Wireless Environment

Understanding QoS for Wireless LANs

QoS for Wireless LANs Versus QoS on Wired LANs

Impact of QoS on a Wireless LAN

Precedence of QoS Settings

Using Wi-Fi Multimedia Mode

Configuring QoS

Layer2 QoS (RBCP and Voice)

TPID-Tag Protocol Identifier

Priority

CFI-Canonical Format Indicator

VID-VLAN Identifier

Layer3 QoS (IP DSCP)

Radio Access Category Definitions

CW-min and CW-max Settings for Point-to-Point and Point-to-Multipoint Bridge Links

QoS Configuration Examples

QoS Example Configuration for VLAN

QoS Example of IP DSCP and IP Precedence

Additional Information

Configuring QoS in a Wireless Environment

This chapter describes how to configure quality of service (QoS) on your Cisco wireless interface. With this feature, you can provide preferential treatment to certain traffic at the expense of other traffic. Without QoS, the device offers best-effort service to each packet, regardless of the packet contents or size. It sends the packets without any assurance of reliability, delay bounds, or throughput.

This chapter consists of these sections:

•Understanding QoS for Wireless LANs

•Configuring QoS

•QoS Configuration Examples

Understanding QoS for Wireless LANs

By default, networks operate on a best-effort delivery basis, which means that all traffic has equal priority and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being dropped.

When you configure QoS on the device, you prioritize network traffic, creating QoS policies and applying the policies to the VLAN configured on your device. Implementing QoS in your wireless LAN makes network performance more predictable and bandwidth utilization more effective. If you do not use VLANs on your network, you can apply your QoS policies to the Ethernet and radio ports.

Note When you enable QoS, the device uses Wi-Fi Multimedia (WMM) mode by default.

QoS for Wireless LANs Versus QoS on Wired LANs

The QoS implementation on wireless LANs differs from QoS implementations on wired networks. With QoS enabled, bridges:

•Do not classify packets; they prioritize packets based on differentiated services code point (DSCP) value, client type (such as a wireless phone), or the priority value in the 802.1q or 802.1p tag.

•They do not match packets using ACL; they use only modular quality of service (MQC) class-map for matching clauses.

•They do not construct internal DSCP values; they only support mapping by assigning IP DSCP, precedence, or protocol values to Layer 2 COS values.

•They carry out Enhanced Distributed Coordination Function (EDCF)-like queuing on the radio egress port only.

•They do only FIFO queuing on the Ethernet egress port.

•They support only 802.1Q/P tagged packets. Bridges do not support InterSwitch Link Protocol (ISL).

•They support only MQC policy-map set cos action.

To contrast the wireless LAN QoS implementation with the QoS implementation on other Cisco network devices, see the Cisco IOS Quality of Service Solutions Configuration Guide at this URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/index.htm

Impact of QoS on a Wireless LAN

Wireless LAN QoS features are a subset of the proposed 802.11e draft. QoS on wireless LANs provides prioritization of traffic from the device over the WLAN based on traffic classification.

Just as in other media, you might not notice the effects of QoS on a lightly loaded wireless LAN. The benefits of QoS become more obvious as the load on the wireless LAN increases, keeping the latency, jitter, and loss for selected traffic types within an acceptable range.

QoS on the wireless LAN focuses on downstream prioritization from the device. These are the effects of QoS on network traffic:

•The radio downstream flow is traffic transmitted out the device radio to another bridge. This traffic is the main focus for QoS on a wireless LAN.

•The radio upstream flow is traffic received on the device radio from another bridge. QoS for wireless LAN does not affect this traffic.

•The Ethernet downstream flow is traffic sent from a switch or a router to the Ethernet port on the device. If QoS is enabled on the switch or router, the switch or router might prioritize and rate-limit traffic to the device.

•The Ethernet upstream flow is traffic sent from the device Ethernet port to a switch or router on the wired LAN. The device does not prioritize traffic that it sends to the wired LAN based on traffic classification.

Precedence of QoS Settings

When you enable QoS, the device queues packets based on the Layer 2 class of service value for each packet. The device applies QoS policies in this order:

1. Packets already classified—When the device receives packets from a QoS-enabled switch or router that has already classified the packets with non-zero 802.1Q/P user_priority values, the device uses that classification and does not apply other QoS policy rules to the packets. An existing classification takes precedence over all other policies on the device.

Note A Cisco device always acts on tagged 802.1P packets that it receives over the radio interface, even if a QoS policy has not been configured.

2. Policies you create on the device—QoS Policies that you create and apply to VLANs or to the device interfaces are second in precedence after previously classified packets.

3. Default classification for all packets on VLAN—If you set a default classification for all packets on a VLAN, that policy is third in the precedence list.

Using Wi-Fi Multimedia Mode

When you enable QoS, the device uses Wi-Fi Multimedia (WMM) mode by default.

The following features of the WMM specification are supported:

•Addition of the WMM information element to associate request frames

•Addition of the WMM parameter element to the beacon, probe response and association response frames

•Addition of the QoS control field to data frames

•Support for setting the field sent in the WMM parameter element (per access class):

–contention window (CW) min

–CW max

–Arbitration Interframe Space (AIFS)

–Admission control required

–Transmit opportunity (TXOP) size

•Separate transmit sequence numbers for each access class and for frames that do not have the QoS control field

•Separate duplicate sequence number checking lists on receive for each access class and for frames that do not have the QoS control field

•No ACK frames for QOS control fields that do not require ACK

•Negotiation of WMM capability with client on reassociation

•Support for burst transmission of multiple frames in a transmit opportunity

•Support for the WMM specified backoff procedure

•Support for the WMM retransmit procedure

•Addition of 802.1d priority for WMM enabled clients

•Support for separate Temporal Key Integrity Protocol (TKIP) replay detection counters on receive for each access class and for frames that do not have the QOS control field

The following features of the WMM specification are supported only on Cisco 3201 WMIC:

•Transmission of a packet with the no ACK required bit set in the QoS control field

•End of service period (EOSP) bit in the QoS control field

•Management action frames

•Traffic Specification (TSPEC) element

•Admission control procedure

•Enforcement of admission control required field

•Triggered power save delivery

Configuring QoS

QoS is enabled by default. This section describes how to configure QoS on your device. Before configuring QoS on your device, you should be aware of this information:

•The most important guideline in QoS deployment is to be familiar with the traffic on your wireless LAN. If you know the applications used by wireless client devices, the applications’ sensitivity to delay, and the amount of traffic associated with the applications, you can configure QoS to improve performance.

•QoS does not create additional bandwidth for your wireless LAN; it helps control the allocation of bandwidth. If you have plenty of bandwidth on your wireless LAN, you might not need to configure QoS.

Layer2 QoS (RBCP and Voice)

Cisco devices can support wireless voice clients that are 802.11e compliant, transmitting and receiving frames with the Layer 2 802.1p priority bits set.

Between the host router and wireless device there is an Router Blade Control Protocol (RBCP) that monitors the health of a device by sending periodic keep alive packets. The device sends layer2 802.1q tagged RBCP packets with the highest priority (priority 7) in the keep alive packets to ensure the keep alive packets make it to the host router, even on a congested network.

The Layer 2 RBCP packet is shown in the following diagram.

The tag field includes the field acronyms and the number of bits for each field.

TPID-Tag Protocol Identifier

The Tag Protocol Identifier is a 16-bit field. It is set to a value of 0x8100 to identify the frame as an IEEE 802.1Q-tagged frame.

Priority

Also known as user priority, this 3-bit field refers to the IEEE 802.1p the frame priority level. The field is set to 0x111 (highest priority) for RBCP.

CFI-Canonical Format Indicator

The Canonical Format Indicator is a 1-bit field. The value is 0 for RBCP when the MAC address is in canonical format.

VID-VLAN Identifier

The VLAN Identifier is a 12-bit field that uniquely identifies the VLAN to which the frame belongs. The field is set to 0x000, which is supported by host routers.

Layer3 QoS (IP DSCP)

When a device is running Lightweight Access Point Protocol (LWAPP), the packets to the host router are encapsulated in a Layer 3 LWAPP header with the IP DSCP field set to one of the values indicated in the table below, depending on the type of traffic.

To provide optimum system QoS for packets going out from the wireless device to the host router and then routed to one of its outgoing interfaces, suitable policy maps must be configured on the host router’s out-going interfaces to prioritize IP DSCP-based packets (devices running LWAPP) or map Class of Service (CoS) to IP DSCP (an autonomous device supporting wireless 802.1e clients). This ensures:

•Host router always sees the wireless device as being online when a service-module wlan-ap 0 status command is issued

•A wireless device running LWAPP does not lose connectivity to the wireless LAN controller (WLC) under congestion scenarios on other router switch-ports

•Voice calls from the wireless device can be provisioned under congestion scenarios on the other router switch-ports

IP DSCP precedence information is contained in the IP header TOS field:

•Best Effort

•Assured Forwarding — Class 1 Low

•Assured Forwarding — Class 1 Medium

•Assured Forwarding — Class 1 High

•Assured Forwarding — Class 2 Low

•Assured Forwarding — Class 2 Medium

•Assured Forwarding — Class 2 High

•Assured Forwarding — Class 3 Low

•Assured Forwarding — Class 3 Medium

•Assured Forwarding — Class 3 High

•Assured Forwarding — Class 4 Low

•Assured Forwarding — Class 4 Medium

•Assured Forwarding — Class 4 High

•Class Selector 1

•Class Selector 2

•Class Selector 3

•Class Selector 4

•Class Selector 5

•Class Selector 6

•Class Selector 7

•Expedited Forwarding

Radio Access Category Definitions

The device uses the radio access category definitions to calculate backoff times for each packet. As a rule, high-priority packets have short backoff times.

The default values for the minimum and maximum contention window and in the slottime are based on settings recommended in IEEE Draft Standard 802.11e. For detailed information on these values, consult that standard.

We recommend that you use the default settings. Changing these values can lead to unexpected blockages of traffic on your wireless LAN, and the blockages might be difficult to diagnose. If you change these values and find that you need to reset them to defaults, use the default settings listed in Table 2.

The values listed in Table 2 are to the power of 2. The device computes contention window values with this equation:

CW = 2 ** X minus 1

where X is the value from Table 2.

CW-min and CW-max Settings for Point-to-Point and Point-to-Multipoint Bridge Links

For best performance on your device links, adjust the CW-min and CW-max contention window settings according to the values listed in Table 3. The default settings, CW-min 3 and CW-max 10, are best for point-to-point links. However, for point-to-multipoint links, you should adjust the settings depending on the number of non-root bridges that associate to the root device.

Note If packet concatenation is enabled, adjust the CW-min and CW-max settings only for traffic class 0. Concatenation is disabled by default.

To adjust the CW-min and CW-max settings, follow these steps, beginning in privileged EXEC mode:

Use the no form of the command to reset the setting to defaults.

QoS Configuration Examples

QoS Example Configuration for VLAN

The following example queues all traffic from VLAN100 to the voice queue:

interface fastEthernet 0.1

 encapsulation dot1Q 1 native

interface fastEthernet 0.100

interface fastEthernet 0.101

 encapsulation dot1Q 1 native

interface dot11Radio 0.100

interface dot11Radio 0.101

class-map match-all alldata

interface dot11Radio 0.100

 service-policy output v100traffic

QoS Example of IP DSCP and IP Precedence

The following example queues traffic data with the IP Precedence value 2 to Queue 0, IP DSCP value 12 to Queue 1, IP Precedence value 5 to Queue 2, and IP DSCP value 46 to queue 3.

class-map match-all dscp12

class-map match-all dscp46

class-map match-all prec2

 match ip precedence immediate

class-map match-all prec5

 match ip precedence critical

 service-policy output L3Map

Additional Information

For more information, see:

Understanding the Lightweight Access Point Protocol (LWAPP) at http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps6306/prod_white_paper0900aecd802c18ee_ns337_Networking_Solutions_White_Paper.html

Quality of Service (QoS) at http://www.cisco.com/en/US/products/ps6558/products_ios_technology_home.html

Материал из Xgu.ru

Перейти к: навигация, поиск

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

[править] Modular QoS CLI

Использование команды match в class map:

• До 4 (CoS и IPP) или 8 (DSCP) значений могут быть указаны в одной команде match cos, match precedence или match dscp. Если любое из указанных значений будет обнаружено в пакете, он совпадет с соответствующей class-map.
• Если в class map используется несколько команд match, то параметр match-any или match-all(используется по умолчанию) команды class-map, определяет используется между этими командами логическое ИЛИ или И.
• Внутри class map можно ссылаться на другую class map, используя команду match class
• Команда match protocol предполагает использование Network Based Application Recognition (NBAR).

[править] Утилиты для классификации и маркировки

[править] 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:

router(config-pmap-c)# set [ip] precedence <ip-precedence-value>

Для этой и следующей команды, если указан параметр ip, то значение поля устанавливается только для пакетов IPv4. Если параметр опущен, то значения IPP и DSCP устанавливаются для пакетов IPv4 и IPv6.

Маркировка трафика определенным значением поля DSCP:

router(config-pmap-c)# set [ip] dscp <ip-dscp-value>

Маркировка трафика определенным значением поля CoS:

router(config-pmap-c)# set cos <cos-value>

Указание идентификатора группы для QoS group:

router(config-pmap-c)# set qos-group <group-id>

Установка в ячейке ATM бита CLP:

router(config-pmap-c)# set atm-clp 

Установка в кадре Frame Relay бита DE:

router(config-pmap-c)# set fr-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 минут:

dyn5(config-if)# load-interval <30-600>

[править] Управление перегрузками и избежание перегрузок

Управление перегрузками (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):

dyn5# sh controllers fa0/0
.......
 tx_limited=0(256)
.......

Изменение размера очереди:

dyn5(config)# int fa0/0
dyn5(config-if)# tx-ring-limit 3

После изменения размер аппаратной очереди:

dyn5# sh controllers fa0/0
.......
 tx_limited=0(3)
.......

[править] Утилиты управления очередями

Старые утилиты:

• 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 а процентах):

dyn5(config)# int fa0/0
dyn5(config-if)# bandwidth 10000
dyn5(config-if)# max-reserved-bandwidth 70

После задания таких параметров, если на интерфейс fa0/0 применяется policy-map, то пропускная способность, которая выделена в ней не должна быть более чем 7000.

Пример policy-map:

dyn5(config)# policy-map test-bw
dyn5(config-pmap)# class class1      
dyn5(config-pmap-c)# bandwidth 4000
dyn5(config-pmap)# class class2      
dyn5(config-pmap-c)# bandwidth 5000

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

dyn5(config-if)# service-policy output test-bw
I/f FastEthernet0/0 class class2 requested bandwidth 5000 (kbps), available only 3000 (kbps)

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:

dyn5(config)# policy-map test-bw
dyn5(config-pmap)# class class1
dyn5(config-pmap-c)# bandwidth percent 20

[править] Размер очереди для CBWFQ

Пример задания размера очереди для класса (диапазон от 1 до 4096 пакетов):

dyn5(config)# policy-map test-bw           
dyn5(config-pmap)# class class1
dyn5(config-pmap-c)# queue-limit 500

[править] Включение WFQ для класса по умолчанию

Для класса по умолчанию можно включить WFQ (и только для него):

dyn5(config)# policy-map test-bw           
dyn5(config-pmap)# class class-default
dyn5(config-pmap-c)# fair-queue

[править] congestive-discard-threshold

fair-queue [congestive-discard-threshold]

[править] LLQ

Синтаксис команды для настройки LLQ:

dyn5(config-pmap-c)# priority <bandwidth-kbps | percent <percentage>> [burst-size]

Команда 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:

dyn5(config)# policy-map test-bw
dyn5(config-pmap)# class llq-class      
dyn5(config-pmap-c)# priority percent 30

Просмотр policy-map:

dyn5# sh policy-map test-bw
  Policy Map test-bw
    Class llq-class
      Strict Priority
      Bandwidth 30 (%)

Просмотр статистики по конкретному классу:

dyn5# sh policy-map interface fa0/0 output class llq-class
 FastEthernet0/0 

  Service-policy output: test-bw

    Class-map: llq-class (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: none 
      Queueing
        Strict Priority
        Output Queue: Conversation 264 
        Bandwidth 30 (%)
        Bandwidth 30000 (kbps) Burst 750000 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

[править] Weighted Round Robin Queuing

Weighted Round Robin (WRR)

sw(config-if)# wrr-queue cos-map queue-id threshold-id cos-1...cos-n

Strict-priority queue:

wrr-queue priority-queue 

sw(config-if)# wrr-queue bandwidth <Q1-weight> <Q2-weight> <Qn-weight>

[1]

[править] Weighted Random Early Detection (WRED)

Tail drop — когда очередь заполнена, IOS начинает отбрасывать новые пакеты.

Weighted Random Early Detection (WRED) — отслеживает длину очереди и отбрасывает некоторый процент пакетов в очереди для улучшения производительности сети.

WRED отбрасывает пакеты до тех пор как очередь заполнится.

Для того чтобы определить достаточно ли полна очередь для того чтобы отбрасывать пакеты WRED измеряет среднюю глубину очереди (average queue depth).
Затем, значение average depth сравнивается с minimum threshold и maximum threshold.
В зависимости от результата сравнения выполняются различные действия.

Mark probability denominator (MPD) — на основании этого значения вычисляется процент пакетов, которые будут отброшены.

WRED дает больший приоритет пакетам с определенными значениями IPP и DSCP.
Для того чтобы сделать это WRED использует разные профили трафика (traffic profile) для пакетов с разными значениями IPP и DSCP.

WRED traffic profile состоит из настроек для трёх переменных:

• minimum threshold,
• maximum threshold,
• MPD.

Профили WRED заданные по умолчанию для DSCP-based WRED:

Exponential weighting constant контролирует насколько быстро меняется средняя глубина очереди. Если значение константы меньше, то средняя глубина очереди меняется быстрее; если константа больше, то — медленнее. По умолчанию используется значение 9.

[править] Настройка WRED

WRED может быть настроен на:

• физическом интерфейсе (с FIFO очередью),
• для класса (класс должен быть не LLQ) внутри CBWFQ policy-map,
• для ATM VC.

Для использования WRED на физическом интерфейсе, IOS отключает остальные механизмы управления очередями и создает одну очередь FIFO.

Команды по настройке WRED аналогичны на интерфейсе и для класса внутри policy-map.

Включение WRED (по умолчанию включается WRED с использованием IPP):

dyn5(config-if)# random-detect 

Включение WRED с использованием DSCP для определения профиля трафика:

dyn5(config-if)# random-detect dscp-based

Изменение настроек по умолчанию WRED для конкретного значения IPP:

dyn5(config-if)# random-detect precedence <precedence> <min-thres> <max-thres> <mpd>

Изменение настроек по умолчанию WRED для конкретного значения DSCP:

dyn5(config-if)# random-detect dscp <dscp-value> <min-thres> <max-thres> <mpd>

Exponential weighting constant:

dyn5(config-if)# random-detect exponential-weighting-constant <1-16>

[править] Просмотр настроек

Просмотр настроек:

dyn5# sh queueing [interface | custom | fair | priority | random-detect]

Пример вывода настроек:

dyn5# sh queueing 
Current fair queue configuration:
Current DLCI priority queue configuration:
Current priority queue configuration:
Current custom queue configuration:
Current random-detect configuration:
  FastEthernet0/0
    Queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0

  class                     Random drop      Tail drop    Minimum Maximum  Mark
                            pkts/bytes       pkts/bytes    thresh  thresh  prob
      0                         0/0              0/0           20      40  1/10
      1                         0/0              0/0           22      40  1/10
      2                         0/0              0/0           24      40  1/10
      3                         0/0              0/0           26      40  1/10
      4                         0/0              0/0           28      40  1/10
      5                         0/0              0/0           31      40  1/10
      6                         0/0              0/0           33      40  1/10
      7                         0/0              0/0           35      40  1/10
   rsvp                         0/0              0/0           37      40  1/10

Current per-SID queue configuration:

[править] 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.

switch# show mls qos maps cos-input-q

switch# show mls qos maps dscp-input-q

Настройка коэффициентов для очередей (по умолчанию 90 процентов в очередь 1 и 10 процентов в очередь 2):

switch(config)# mls qos srr-queue input buffers <percentage1> <percentage2>

Настройка процентов для пропускной способности, которые устанавливают частоту с которой scheduler берет пакеты из двух буферов (по умолчанию оба значения 4):

switch(config)# mls qos srr-queue input bandwidth <weight1> <weight2>

Две указанные команды вместе определяют какое количество данных коммутатор может

Настройка приоритетной очереди:

switch(config)# mls qos srr-queue input priority-queue <queue-id> bandwidth <weight>

Коммутатор будет обслуживать приоритетную очередь до тех пор, пока пропускная способность не достигнет настроенного значения 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 может быть настроен только для исходящих пакетов и может быть применен к физическому интерфейсу или подынтерфейсу.

dyn5(config-pmap-c)# shape [average | peak] <mean-rate> [[burst-size][exceed-burst-size]]

Должен быть указан shaping rate. Bc и Be могут быть опущены, а Tc не может быть задан напрямую.
Соответственно CB shaping высчитывает неуказанные значения.
Значения высчитываются по-разному в зависимости от того чему равен shaping rate.

[править] CB shaping peak rate

Если CB shaping настроен командой shape peak, то:

• значения Bc, Be, Tc высчитываются как и для команды shape average,
• токены Bc и Be (а не только Bc) пополняются каждый временной интервал.

Shaping rate = configured rate (1 + Be/Bc)

[править] Generic Traffic Shaping

[2]

[править] 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).

Настройка FRTS:

dyn5(config)# map-class frame-relay testFR
dyn5(config-map-class)# frame-relay traffic-rate <average> [peak]

Пример явного указания параметров:

dyn5(config)# map-class frame-relay testFR
dyn5(config-map-class)# frame-relay cir 64000
dyn5(config-map-class)# frame-relay bc 640

Настройка динамического реагирования маршрутизатора на основании BECN:

dyn5(config-map-class)# frame-relay adaptive-shaping

[3]

[править] CB policing

CB policing разделяет пакеты на две или три категории, в зависимости от вида policing, а затем применяет к каждой категории соответствующее действие.

Возможные категории:

• conforming
• exceeding
• violating

[править] Single-rate, two-color policing (one bucket)

Policer использует две категории:

• conform
• exceed

CB Policer заполняет bucket не на основании временных интервалов, а на основании пакетов.

Количество токенов высчитывается по формуле:

((current_packet_arrival_time - Previous_packet_arrival_time) * Police_rate) / 8

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

Когда приходит новый пакет, policer должен определить превышает или нет этот пакет установленный контракт.

Policer сравнивает количество байт в пакете (Xp) с количеством токенов в token bucket (Xb).

[править] Single-rate, three-color policing (two buckets)

Policer использует три категории:

• conform
• exceed
• violate

Xbc — количество токенов в Bc bucket,
Xbe — количество токенов в Be bucket.

[править] Two-rate, three-color policing (two buckets)

Two rate:

• Commited information rate (CIR)
• Peak information rate (PIR)

Policer использует три категории:

• conform — пакеты передающиеся до CIR,
• exceed — пакеты передающиеся выше CIR, но до PIR,
• violate — пакеты передающиеся выше PIR.

[править] Настройка CB policing

Пример настройки:

police cir 8000 bc 1000 be 500 conform-action transmit exceed-action transmit violate-action drop 

Если не указаны значения Bc или Be, то используются значения по умолчанию, которые зависят от типа policing.

[править] Multi-action policing

Multi-action policing — маркировка нескольких полей в одном пакете с помощью CB policing.

[править] Commited access rate (CAR)

CAR это single-rate, two-color policing.
CAR оптимизирован для высокоскоростных соединений.
CAR применяется для входных и выходных интерфейсов (включая подинтерфейсы в том числе Frame Relay и ATM)
может так же использоваться для предотвращения DOS атак.

Настройка CAR:

dyn5(config-if)# rate-limit <input | output> [access-group [rate-limit] acl-index] 
bps burst-normal burst-max conform-action action exceed-action action  

Параметры команды:

• 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 – пометить пакет
• burst-max — трафик, который можно передать при пустой очереди

  рекомендовано задавать по формуле:

  burst-max=burst-normal*2

Пример CAR:

interface Tunnel122
 ip address 10.84.239.230 255.255.255.252
 ip mtu 1420
 rate-limit input access-group 199 8000 1600 2000 conform-action transmit exceed-action drop
 ...
end

Просмотр трафика, который попадает под CAR:

sm-sht-c2811#sh int tu 122 rate-limit
Tunnel122 crypto tunnel sm
  Input
    matches: access-group 199
      params:  8000 bps, 1600 limit, 2000 extended limit
      conformed 23741 packets, 1994692 bytes; action: transmit
      exceeded 3210 packets, 184395 bytes; action: drop
      last packet: 1149595396ms ago, current burst: 0 bytes
      last cleared 14w0d ago, conformed 0 bps, exceeded 0 bps

На интерфейс можно описывать любое число правил, ограничивающих трафик на данном интерфейсе
Следующий пример ограничивает ICMP трафик до 500 kb/s, а так же UDP трафик до уровня 2 Мб/s на одном из интерфейсов

!
sm-c3660(config-if)#rate-limit input access-group 100 500000 62500 62500 conform-action transmit exceed-action drop
sm-c3660(config-if)#rate-limit input access-group 101 2010000 250000 250000 conform-action transmit exceed-action drop
!
sm-c3660(config)#access-list 100 permit icmp any any
sm-c3660(config)#access-list 101 permit udp any any

[5]
[6]

[править] rate-limit ACL

dyn1(config)# access-list rate-limit ?
  <0-99>     Precedence ACL index
  <100-199>  MAC address ACL index
  <200-299>  mpls exp ACL index

dyn1(config)# access-list rate-limit 1 mask <0-FF>

Порядок вычисления параметра mask:

1. Определить какие значения IPP нужны.
2. Каждому значению IP precedence соответствует бит в выделенном байте:
   • 00000001 — 0
   • 00001000 — 3
   • 00100001 — 5
3. Сложить получившиеся 8мибитные числа. Например, если необходимо совпадение значений 0, 3 и 5, то итоговое значение будет 00101001.
4. Перевести полученное значение в соответствующее шестнадцатеричное число. Для приведенного примера это будет число 0x29.
5. Настроить соответствующий ACL. Для указанного примера: access-list rate-limit 1 mask 29.

[править] QoS Policy Propagation через BGP (QPPB)

[7]

[править] Дополнительная информация

• Class-Based Shaping Configuration
• Shaping vs. Policing At A Glance
• Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting (англ.)
• QoS для DMVPN
• Understanding How Routing Updates and Layer 2 Control Packets Are Queued on an Interface with a QoS Service Policy (pak_priority) (англ.)

Cisco 3560 QoS:

• Bridging the gap between 3550 and 3560 QoS: Part I (англ.)
• Bridging the gap between 3550 and 3560 QoS: Part II (англ.)
• Traffic Classification in the 3550/3560 Switches (англ.)
• Comparing Traffic Policing Features in the 3550 and 3560 switches (англ.)
• Quick Notes on the 3560 Egress Queuing (англ.)

Cisco Systems, Inc.
Устройства	Cisco 871 • Cisco Router • Cisco Switch • Сisco Сatalyst  • Cisco IPS • Cisco ASA • PIX • Dynamips
Безопасность (коммутаторы и маршрутизаторы)	Cisco Security • Port security • DHCP snooping • Dynamic ARP Protection • IP Source Guard • Аутентификация при доступе к сети • 802.1X в Cisco • Zone-Based Policy Firewall • Cisco NAT • NAT в Cisco  • Cisco SSH
Cisco ASA	Cisco ASA/NAT • Cisco ASA/Troubleshooting • Cisco ASA/IPS • Cisco ASA failover • Cisco ASA/Transparent firewall • Cisco ASA/Site-to-Site_VPN • Cisco ASA/Easy_VPN • Cisco ASA/WebVPN • Объединение OSPF-сетей туннелем между двумя системами ASA (без GRE) • Центр сертификатов на Cisco ASA
VPN	IPsec в Cisco • Cisco IOS Site-to-Site VPN  • DMVPN  • Cisco Easy VPN • Cisco Web VPN • Cisco ipsec preshared
Канальный уровень	CDP  • VLAN в Cisco  • ISL  • VTP  • STP в Cisco  • Cisco Express Forwarding  • Агрегирование каналов  • Зеркалирование трафика  • QinQ  • Frame Relay
Сетевой уровень	Маршрутизация в Cisco  • RIP  • EIGRP  • IS-IS  • OSPF • BGP  • PIM  • Multicast  • GLBP  • VRRP  • HSRP  • DHCP  • IPv6  • IPv6 vs IPv4  • Резервирование Интернет-каналов без использования BGP • Использование BGP для резервирования Интернет-каналов
Разное	Режим ROMMON в Cisco • Опция 82 DHCP • 802.1X и RADIUS • SNMP в Cisco • QoS в Cisco  • EEM  • Troubleshooting  • Автоматизация работы устройств Cisco  • Cisco NTP  • Cisco IP SLA  • Cisco Enhanced Object Tracking

IP-телефония
Основы	PCM  • Дискретизация  • Квантование  • Компандирование (ulaw, alaw)  • Теорема Найквиста  • Кодек  • IP-телефония  • Протоколы IP-телефонии  • Голосовая почта  • IVR  • Конференция  • Gatekeeper  • DID  • Диалплан  • Музыка на удержании  • Эхоподавление  • Перехват звонка  • Парковка вызова  • Запись разговора  • Очереди звонков  • Callback  • Перевод звонка  • Исходящий звонок  • Запись голосовых файлов  • Звонок на группу  • Отправка факсов
Традиционная телефония	PSTN  • DTMF  • SS7 (SCCP)  • FXO  • FXS  • T1  • E1  • PRI  • GSM
Кодеки	G.711  • G.726  • G.729  • GSM  • iLBC  • Speex
Телефонные номера	E.164 • e164.org • ENUM • DUNDi
Протоколы	IAX • H.323 • IAX2 • SIMPLE • SIP • STUN • RSVP • RTP • SCTP • SRTP • MGCP • Skinny (Cisco) • UNIStim (Nortel)
Транспорт и QoS	IP • QoS (Linux, Cisco) • MPLS • LSP • Asterisk QoS
Софтфоны	X-Lite • Zoiper • Twinkle • Ekiga (GnomeMeeting) • KPhone • pjsua • Linphone • Skype
Обработка голоса	Festival • LumenVox
Учёт и биллинг	CDR • Биллинг звонков через Asterisk
Серверы телефонии	Asterisk • GnuGK • OpenH323 • H323plus • sipXecs
Диагностика / Защита	VoIPER  • VoIP-sniffing (прослушивание)
Asterisk	Инсталляция Asterisk  • Инсталляция Asterisk из исходников  • Начальная конфигурация Asterisk  • Digium • AGI • AMI • FOP • zaptel • DAHDI • ztdummy • Adhearsion • AEL • Asterisk Lua  • Русификация • База данных • GSM-шлюз • Управление ОС  • Шифрование звонков  • SIP-транк
Конфигурационные файлы Астериска	extensions.conf • iax.conf • rtp.conf • sip.conf • voicemail.conf • zapata.conf • zaptel.conf

Я всегда считал Quality of Service (QoS) чем-то из разряда “не дадим войсу квакать, не дадим изображению по вкс развалиться”, однако более глубокое изучение вопроса, откровенно говоря, приятно удивило. Количество средств по манипуляции трафиком, а так же различные методы предоставления гарантированного качества канала нужным приложениям сразу дали понять – нахрапом эту крепость не взять.

С чем полезен и с чем помогает справиться QoS?

• Маленькая пропускная способность канала – не всегда у нас на руках оказывается тот канал, который позволит и youtube в HD посмотреть и корпоративным приложениям работать адекватно.
• Потеря критичных пакетов в следствии заторов.
• Задержки (delay) – время, которое требуется пакету чтобы попасть от источника к получателю. Так, к примеру, 400ms RTT для голоса еще туда-сюда, а вот с значениями, которые превышают этот порог вы получите эффект накладывающегося голоса.
• Джиттер (jitter) или изменение задержки с течением времени. Сейчас у вас 100ms, а через минуту 200ms. Поздравляю, у вас теперь 100ms jitter, который превращается в задержку просто потому, что железкам нужно держать пакет в буфере какое-то время для обеспечения плавности того же разговора.

Методы настройки QoS

• Command Line Interface (CLI) – per interface конфигурация.
• Modular QoS CLI (MQC) – аки ZBF позволяет группировать class map в policy map, policy map привязывать к service policy, а вот уже последнее можно и на интерфейс применить. 
• Auto QoS – генерирует некий усредненный конфиг, который, конечно не one size fit all, но в некоторых случаях оказывается вполне работоспособным.
• QoS Policy Manager (QPM) – централизованная поддержка QoS в вашей сети. Встроена в CiscoWorks.

Инструменты QoS

• Классификация и группировка различных типов трафика.
• Маркировка трафика за тем, чтобы другие устройства в сети могли бы распознать его.
• Policing & shaping. Policing позволяет либо отбрасывать пакеты при превышении какого-либо значения, либо изменять маркировку. Shaping – метод размещения пакетов в очередях (i.e. FIFO, WFQ, CBWFQ) при достижении лимита.

Избежание заторов (congestion avoidance)

• First-in First-out – как понятно из названия – кто первый встал, того и тапки. Пакеты помещаются в очередь, пока не будет исчерпана пропускная способность канала. При ее исчерпании заполняется буфер. Ну а если и он закончился, то пакеты попросту отбрасываются – tail drop.
• Random Early Detection (RED) – RED занимается занятной штукой: как только ваш буфер начинает заполняться – “БАМ!” – в нем погибает случайный пакет. И чем быстрее заполняется буфер, тем агрессивнее работает этот механизм. На сколько я знаю Cisco не поддерживает его работу.
• Weighted Random Early Detection (WRED) – занимается тем же, что и RED, но вместо содомии с случайными пакетами этот механизм выбирает жертв на основании маркировки пакетов и обозначенных заранее правил. “БАМ!” – и вместо пакета с voice трафиком погибает кусок картинки с redtube’a. Если пакеты заранее не были маркированы, то WRED превращается в RED.

Управление заторами

Управлять заторами можно помещая пакеты в очереди, позволяя наиболее приоритетному трафику покидать интерфейс в первую очередь, а наименее приоритетный трафик может и включения WRED дождаться, всякое бывает.

Увеличение эффективности

• Сжатие (data compression).
• Фрагментация канала и чередование (link fragmentation & interleaving) – допустим у нас имеется медленный канал (serial, ага) в который готовится просочиться сочный пакет, содержащий не особо важные данные. На момент когда передача будет начата будет в принципе не важно настроен ли QoS – сочный пакет с радостью займет все предоставленные ему 1500 байт и не пустит крошечный голосовой пакет не смотря не на что. LFI говорит примерно следующее – больше у нас не будет больших пакетов, крошечный пакет голоса, упакованный g.711 должен пролезть no matter what.

Modular QoS CLI

Class map – отвечают за классификацию трафика, позволяя отделить трафик и большим приоритетом от трафика с меньшим. i.e. я хочу выделить http трафик в отдельный класс class-map 2.

Policy map – говорит что делать с трафиком, включенным в входящие в него class map. i.e. я хочу маркировать http трафик определенным тэгом в policy-map 1 и я хочу лимитировать полосу пропускания для http трафика в 64kbps в policy-map 2.

Service policy – применяет policy map на интерфейсе для входящего или исходящего трафика. i.e. я хочу чтобы policy-map 1 маркировала исходящий http трафик на fa0/1, а policy map 2 лимитировала входящий на fa0/2. Одна и только одна service policy может существовать для каждого из направлений на каждом интерфейсе.

Настройка class map

Для class map существуют 2 критерия, по которым они будут работать – match-all (логическое И) и match-any (логическое ИЛИ). По умолчанию создается class-map match-all, означающий что все условия, занесенные в такой class map должны совпасить одновременно для того, чтобы class-map сработала.

R2(config)#class-map ICMP
R2(config-cmap)#match protocol icmp
R2(config-cmap)#match packet length min 200 max 400
R2(config-cmap)#do sh class-map
 Class Map match-all ICMP (id 1)
   Match protocol icmp
   Match packet length min 200 max 400

 Class Map match-any class-default (id 0)
   Match any

Под действие этой class map попадет ICMP трафик с размером пакета от 200 до 400 байт.

Самые наблюдательные из вас успели заметить, что помимо созданной class map ICMP существует еще одна – default, под действие которой попадает весь трафик – это class map по умолчанию. Например мы можем описать голосовой трафик и написать для него определенное правило A, а весь остальной трафик, который нам не интересен, отправится автоматом в class-default и для него будет применено правило B.

Помимо протоколов можно допускать или не допускать к фильтрации сети, хосты, а так же гибко их совмещать в одной class-map с помощью ACL. i.e.:

R2(config)#access-list 10 remark mail servers
R2(config)#access-list 10 permit 10.1.1.1
R2(config)#access-list 10 permit 10.1.1.2
R2(config)#class-map match-all MAIL_SRVRS
R2(config-cmap)#match access-group 10
R2(config-cmap)#match protocol smtp

Под действие такой class map попадут ваши почтовые сервера и SMTP трафик. И на 25 и на 587 порт. Умный IOS сам разберется благодаря Network Based Application Recognition (NBAR).

Настройка policy map

Пришло время рассказать бездушной железке что делать с классифицированным таким образом трафиком. Единственная полезная вещь, которую можно сделать с policy map сразу после создания это добавить к нему class map:

R2(config)#policy-map LIMIT_ICMP
R2(config-pmap)#?
QoS policy-map configuration commands:
  class        policy criteria
  description  Policy-Map description
  exit         Exit from QoS policy-map configuration mode
  no           Negate or set default values of a command
  rename       Rename this policy-map

А вот после применения class map как раз и начинается все веселье:

R2(config-pmap)#class ICMP
R2(config-pmap-c)#?
QoS policy-map class configuration commands:
  bandwidth        Bandwidth
  compression      Activate Compression
  drop             Drop all packets
  estimate         estimate resources required for this class
  exit             Exit from QoS class action configuration mode
  netflow-sampler  NetFlow action
  no               Negate or set default values of a command
  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

Обратите внимание на изменившееся приглашение.

Бегло пробежимся по опциям:

• bandwidth – гарантирует трафику минимальную полосу пропускания в случае возникновения затора (CBWFQ). Можно устанавливать значения либо жестко, либо в процентах. Последнее решение обладает большей гибкостью, так как позволяет использовать одну и ту же policy map на интерфейсах с разными значениями bandwidth. 
• compression – включает сжатие TCP или RTP заголовков для данного трафика, снижая network overhead;
• drop – отбрасывает все пакеты, попавшие под действие class map;
• estimate – позволяет предопределять допустимые пределы задержек или потерь пакетов для данного типа трафика;
• netflow-sampler – в том случае если вам не интересен 100% учет сетевого трафика посредством netflow можно настроить sampler, который будет отправлять 1 flow из n, таким образом снижая количество трафика, льющегося на ваши коллекторы.
• policy / shape – гибкие функции по policing’у и shaping’у трафика;
• priority – гарантирует полосу пропускания (LLQ). Тут внимательный читатель спросит LOLWUT?, покосится на bandwidth, потом снова на priority и снова на bandwidth в попытках найти различия. На самом деле они есть и не маленькие – priority позволяет назначать не только минимальную гарантированную полосу пропускания, но и одновременно максимальную. Более подробно о LLQ можно прочитать тут или, возможно, в следующих статьях.
• queue-limit – команда, позволяющая указать или модифицировать количество пакетов, которые маршрутизатор сможет поместить в очередь.
• random-detect – включает механизм WRED.
• service-policy – позволяет указать другую policy map для построения иерархических (вложенных) политик.
• set – устанавливает различные значения в QoS поля.

Хотелось бы еще раз повторить – это краткое описание опций, подробные разговор о которых является темой не для одной статьи.

Применение policy map

Нет ничего проще. В режиме конфигурации интерфейса с помощью команды service-policy укажите направление и название policy map. Не так уж и трудно, не так ли?

Практика

Для того, чтобы разбавить унылую теорию давайте соберем небольшой стенд, запретив на r2 ICMP пакеты больше 700 байт по направлению к r3 из 192.168.1.0/24 сети, для ICMP пакетов размером от 300 до 700 выставим ограничение 8000bps.

R2(config)#access-list 1 permit 192.168.1.0 0.0.0.255
R2(config)#class-map match-all ICMP
R2(config-cmap)# match access-group 1
R2(config-cmap)# match protocol icmp
R2(config-cmap)# match packet length min 300 max 700
R2(config-cmap)#class-map match-all HUGE_ICMP
R2(config-cmap)# match access-group 1
R2(config-cmap)# match protocol icmp
R2(config-cmap)# match packet length min 701
R2(config-cmap)#policy-map ICMP_PMAP
R2(config-pmap)# class ICMP
R2(config-pmap-c)#   police rate 8000 bps
R2(config-pmap-c-police)#     conform-action transmit
R2(config-pmap-c-police)#     exceed-action drop
R2(config-pmap-c-police)# class HUGE_ICMP
R2(config-pmap-c)#   drop
R2(config-pmap-c)#int fa0/1
R2(config-if)# service-policy output ICMP_PMAP
R2(config-if)#^Z

и проверим эмпирическим путем на R1:

R1#ping 1.1.1.2 repeat 20 size 299

Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 12/40/52 ms
R1#ping 1.1.1.2 repeat 20 si
R1#ping 1.1.1.2 repeat 20 size 300

Type escape sequence to abort.
Sending 20, 300-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!.!!!!!.!!!!!.!!
Success rate is 85 percent (17/20), round-trip min/avg/max = 24/41/64 ms
R1#ping 1.1.1.2 repeat 20 size 700

Type escape sequence to abort.
Sending 20, 700-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!.!!.!!.!!.!!.!!.!!
Success rate is 70 percent (14/20), round-trip min/avg/max = 24/46/80 ms
R1#ping 1.1.1.2 repeat 20 size 701

Type escape sequence to abort.
Sending 20, 701-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
....................
Success rate is 0 percent (0/20)

действительно, ICMP пакеты до 299 включительно без проблем пролезают, минуя всю маркировку через class map, ICMP пакеты от 300 до 700 байт начинают испытывать трудности, в результате установленного лимита “не более 8000 бит в секунду”, а ICMP пакеты свыше 701 байта просто и без затей отбрасываются.

На R2 с работой вашей политики можно ознакомиться следующим образом:

 R2#sh policy-map interface fa0/1
 FastEthernet0/1

  Service-policy output: ICMP_PMAP

    Class-map: ICMP (match-all)
      195 packets, 94730 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 1
      Match: protocol icmp
      Match: packet length min 300 max 700
      police:
          rate 8000 bps, burst 1500 bytes
        conformed 31 packets, 15334 bytes; actions:
          transmit
        exceeded 9 packets, 5226 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

    Class-map: HUGE_ICMP (match-all)
      53 packets, 62262 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 1
      Match: protocol icmp
      Match: packet length min 701
      drop

    Class-map: class-default (match-any)
      1538 packets, 170844 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Исходную информацию о трафике для составления QoS политик можно собрать в реальном времени c помощью того же nbar:

R2(config)#int fa0/1
R2(config-if)#ip nbar protocol-discovery
R2(config-if)#^Z
R2#sh ip nbar protocol-discovery top-n 2

 FastEthernet0/1
                            Input                    Output
                            -----                    ------
   Protocol                 Packet Count             Packet Count
                            Byte Count               Byte Count
                            5min Bit Rate (bps)      5min Bit Rate (bps)
                            5min Max Bit Rate (bps)  5min Max Bit Rate (bps)
   ------------------------ ------------------------ ------------------------
   icmp                     8333                     8430
                            1003954                  1093120
                            0                        0
                            22000                    22000
   bgp                      0                        0
                            0                        0
                            0                        0
                            0                        0
   unknown                  0                        0
                            0                        0
                            0                        0
                            0                        0
   Total                    8333                     8430
                            1003954                  1093120
                            0                        0
                            22000                    22000

Но куда кошернее делать это с помощью netflow.

Время на прочтение
4 мин

Количество просмотров 52K

Добрый день, в данной статье хотел бы немного рассказать о методе построения правил QoS в устройствах Cisco. Для начала хочу дать краткое определение понятию QoS.
QoS — это способность сети, обеспечивать улучшенное обслуживание сетевого трафика независимо от выбранных технологий, включая Frame Relay, ATM, Ethernet или IP сеть с маршрутизацией.
Основная функция QoS — это предоставление усовершенствованного и более предсказуемого поведения сетевых служб, при помощи таких механизмов как:

• Выделенная полоса пропускания
• Улучшенная характеристика потерь
• Предотвращение и управление перегрузками
• Деление трафика
• Приоритезация трафика

Теперь перейдем к рассмотрению детальной структуры командной строки управления QoS в устройствах Cisco. Данная модель является центральной в QoS решениях построенных на базе Cisco IOS. В оригинале она звучит как Modular QoS CLI, далее я буду называть ее MQC.
MQC разделяет задачи связанные с QoS на следующие модули:

• Определение потока трафика
• Классификация его на принадлежность к класcу QoS
• Применение политик QoS для данного класса
• Определение интерфейсов на которых политика должна быть приведена в исполнение.

Ниже указанна схема примерного взаимодействия данного алгоритма.

Постараюсь подробнее рассмотреть команды относящиеся к данному режиму конфигурации.
Switch(config)# class-map cisco
Switch(config-cmap)#
Команда class-map используется для того, чтобы описать класс трафика

• Назначение класса трафика — классифицировать или идентифицировать трафик который будет передан конкретному QoS.
• Трафик который соответствует определенным критериям.

Класс трафика состоит из 3 основных элементов:

• Имя (name)
• Набор команд match
• Если существует больше одной команды match, класс должен содержать инструкции по вычислению

данных команд.
Ниже приведу пример, весь трафик который разрешен, через ACL test будет частью класса известного как cisco.
Switch(config)# class-map cisco
Switch(config-cmap)# match access-group name test
Команда match используется для определения различных критериев классификации пакетов.
Если пакет совпадает с указанными критериями:

• Пакет начинает относиться к данному классу
• Пакет пересылается следуя спецификациям QoS указанных в политике трафика.

Пакеты которые не совпали в указанными критериями:

• Классифицируются как класс по умолчанию.
• Распределяются по другим политикам трафика.

Если в данном классе имеется больше чем одно совпадение, используется:
— class-map match-any или
— class-map match-all
Если используется match-any, то трафик будет будет двигаться исходя из правила, «должен соответствовать одному из указанных критериев»
Если используется match-all, то трафик будет двигаться исходя из правила, «должен соответствовать всем указанным критериям»
В качестве примера рассмотрим набор команд:

Switch(config)# class-map match-any cisco
Switch(config-cmap)# match access-group name test
Switch(config-cmap)# match interface fastethernet 0/1

Если трафик совпадает с утверждением «разрешено» в ACL test или трафик создается интерфейсом Fa0/1, он будет признан частью трафика известного как cisco.
Команда policy-map используется для создания политики трафика
— Назначение политики трафика — это конфигурирование функций QoS, которые должны быть связаны с трафиком который был классифицирован как трафик описанный пользователем.
Политика трафика состоит также из трех элементов:

• Имя политики (Policy name)
• Класс трафика (обозначается командой class)
• политики QoS которые будут применены к каждому классу.

Рассмотрим пример:

Switch(config)# policy-map policy1
Switch(config-pmap)# class cisco
Switch(config-pmap-c)# bandwidth 3000
Switch(config-pmap)# class class-default
Switch(config-pmap-c)# bandwidth 2000

Данный policy-map создает политику трафика называющуюся policy1

• Политика применяется ко всему трафику классифицируемому заранее описанным классом трафика «cisco». Указывает, что трафику в данном примере следует выделить полосу пропускания 3000 kbps.
• Весь трафик который не принадлежит данному классу «cisco» формирует часть класса class-default. Ему будет предоставлена полоса пропускания 2000 kbps.

Switch(config)# interface fastethernet 0/1
Switch(config-if)# service-policy output policy1

Команда service policy используется для присоединения политики трафика, указанную командой policy-map, на интерфейс.
— Может быть применен как для входящих так и для исходящих пакетов на указанном интерфейсе, поэтому в данной команде необходимо указывать направление трафика.
Пример:

Switch(config)#interface fastethernet 0/1
Switch(config-if)#service-policy output policy1
Switch(config-if)#exit

Все пакеты покидающие указанные интерфейс должны быть совместимы с критериями указанными в политике трафика названной policy1.
Теперь попробуем объединить все что у нас получилось в единую конфигурацию, с небольшими разъяснениями:

1. Добавляем политику трафика к интерфейсу.
Switch(config)#interface fastethernet 0/1
Switch(config-if)#service-policy output policy1
2. Идентифицируем функцию QoS данной политики, используя классы.
Switch(config)#policy-map policy1
Switch(config-pmap)#class cisco
Switch(config-pmap-c)#bandwidth 3000
Switch(config-pmap)#class class-default
Switch(config-pmap-c)#bandwidth 2000
3. Классификация потока трафика, как принадлежащего к указанному классу QoS.
Switch(config)# class-map match-any cisco
Switch(config-cmap)# match access-group name test
Switch(config-cmap)# match interface fastethernet 0/1

Примерно так и функционирует модель QoS основанная на Cisco IOS, надеюсь я хоть немного смог раскрыть алгоритм данного функционала. Конечно данная статья является только лишь верхушкой айсберга под названием QoS, но надеюсь, что она поможет приобрести небольшую базу в построении политик QoS на устройствах Cisco.

Просто о сложном. Заметки для себя.

В этом разделе описаны различные способы
настройки средств качества обслуживания. В этом разделе рассматриваются
следующие темы:

Вот как коммутатор по умолчанию
обрабатывает кадры после включения QoS:

В коммутаторах Cisco Catalyst
классификация и маркирование уровней качества обслуживания выполняется иначе,
чем в маршрутизаторах. В маршрутизаторах Cisco можно классифицировать пакеты
при помощи:

В коммутаторе Cisco Catalyst  кадры можно классифицировать:

Настройка по входящему значению CoS и DSCP
достигается тремя различными способами:

Иногда возникает недопонимание как
осуществляется классификация и маркировка трафика для коммутаторов Cisco
Catalyst, из-за того, что класс обслуживания CoS или значения DSCP (пакетов
внутри кадров) перемаркируются с использованием таблиц трансформаций.
Использование этих таблиц в маршрутизаторах Cisco недоступно. Функции,
связанные с использованием этих таблиц, доступны только в коммутаторах Cisco
Catalyst. Здесь я объясняю функции, которые предполагают использование этих
таблиц.

Входящий пакет или кадр может уже обладать
меткой качества обслуживания. Могут возникнуть следующие вопросы:

 В
этом разделе приводятся различные сценарии с примерами.

Параметры настройки доверия для порта
таковы:

Пример
1. 

Если порт представляет собой порт доступа
(access port) или порт L3, необходимо настроить команду mls
qos trust dscp .

Нельзя использовать команду mls qos
trust cos, поскольку кадр от порта доступа или порта L3 не содержит тегов dot1q. Биты класса обслуживания CoS присутствуют только в кадрах dot1q или ISL.

Пример 2. 

Если
используемый порт является транковым, можно настроить:

Таблица сопоставлений dscp-cos
используется для вычисления значения класса обслуживания CoS, если порт настроен на доверие DSCP. Таким же
образом, таблица сопоставлений cos-dscp используется для вычисления значения DCSP, если порт настроен на доверие
классу обслуживания CoS.

Пример
3. 

Если порт
является транковым и настроен при помощи команды mls qos trust
cos, то фреймы NATIVE VLAN будут иметь нулевые значения класса
обслуживания (CoS) и DSCP. Поскольку фреймы NATIVE VLAN не обладают тегами, а теги присваиваются только
после попадания кадра в коммутатор, коммутатор задает значение CoS по умолчанию
равным 0, а в таблице сопоставления CoS-DSCP значение DSCP также
устанавливается равным 0.

Можно также
настроить порт коммутатора на изменение нулевого значения класса обслуживания
по умолчанию для нетегированных кадров на любое другое в диапазоне от 0 до 7
при помощи команды mls qos cos <0-7> .

Например,
порт GigabitEthernet1/0/12 настроен для как access port в  VLAN 10 и передачи голосового трафика в
голосовом VLAN 20.

По умолчанию
компьютер не присваивает тегов отправляемым данным. Неотмеченный тегами трафик
от PC , подключенного к телефону Cisco IP Phone, проходит через телефон без
изменений, вне зависимости от состояния доверия порта доступа телефона на
коммутаторе.

Телефон
передает маркированные кадры dot1q с идентификатором голосовой VLAN 20(VID 20).
Поэтому, если порт настроен при помощи команды mls qos trust cos, он
доверяет значениям класса обслуживания кадров, отправляемых с телефона (кадры,
отмеченные тегами VID20), и обнуляет значения класса
обслуживания кадров, передаваемых от ПК (кадры, не отмеченные тегами). Затем
таблица сопоставлений CoS-DSCP обнуляет значение DSCP для пакета внутри кадра,
поскольку в таблице сопоставлений значению CoS «0» соответствует значение
DSCP «0».

 Если пакеты от компьютера обладают каким бы то
ни было значением DSCP, то это значение будет обнулено. При настройке
команды mls qos cos 3 для
этого порта, будет выполнена установка значения класса обслуживания CoS всех кадров от компьютера в значение «3», однако
это не изменит значение класса обслуживания CoS для кадров, передаваемых телефоном.

Если нам необходимо переопределить значения класса
обслуживания CoS для всех кадров ( как тегированных, так и нет) то нам поможет команда mls qos cos 3 override.

Пример 4.

Если
допустить такую ситуацию, что ПК присваивает своему кадру тег идентификатора
VLAN 20, а порт сконфигурирован следующим образом:

В этом
случае, мы имеем следующую ситуацию. Поскольку интерфейс настроен на доверие
значению класса обслуживания, весь трафик PC, получаемый через порт телефона IP Cisco Phone,
проходит через телефон без изменений. Коммутатор также доверяет и пропускает
трафик от ПК, предоставляя этому трафику тот же приоритет, что и трафику
IP-телефона. Такая конфигурация нас явно не устроит. Этого можно избежать при
помощи команды switchport priority
extend cos <cos-value> .

Пример 5. 

Например, если кто-то пытается реализовать
прямое подключение ПК к коммутатору и указать в кадрах dot1q данных ПК теги с
более высоким значением класса обслуживания CoS, чтобы получить более приоритетное обслуживание, то тогда
наша директива switchport priority extend cos 0 не будет работать, поскольку в разрыве уже
нет телефона, злоумышленник подключается напрямую в порт коммутатора.Этого
можно избежать при помощи указания команды mls qos trust device cisco-phone .

Пример 6. 

Например, на интерфейсе GigabitEthernet1/0/12
необходимо настроить доверие меткам класса обслуживания CoS, передаваемых от ПК. ПК подключен к VLAN 10. В этом
случае команда mls qos trust cos, не
сработает, поскольку пакет, передаваемый от ПК, не содержит необходимого
значения класса обслуживания CoS(он попросту
не тегирован). При этом фрейм имеет  только значение DSCP. Коммутатор добавляет
кадр dot1q и устанавливает значение класса обслуживания CoS по умолчанию, равное 0. Затем при помощи таблицы CoS—DSCP
рассчитывается и сбрасывается в 0 значение DSCP.

Решить эту проблему можно двумя способами.

Первый способ — настроить классификацию и маркирование при помощи
MQC. Можно создать список управления доступом (ACL) для сопоставления трафика
ПК в зависимости от источника, IP-адреса назначения и исходных/целевых номеров
портов. После этого можно сопоставить этот список управления доступом в карте
классов. Можно создать карту политик для доверия этому типу трафика. Это
решение описывается в следующем разделе. В этом разделе описывается второй
метод.

Второй метод заключается в том, чтобы включить доверие метке DSCP
вместо метки CoS. После этого метка DSCP-CoS используется для вычисления и
установки значения класса обслуживания, которое соответствует значению DSCP.

После включения mls qos, таблицы карт создаются со
значениями по умолчанию и, затем, применяются.

Distribution1#show mls qos maps cos-dscp

   Cos-dscp map:

        cos:   0  1  2  3  4  5  6  7

     --------------------------------

       dscp:   0  8 16 24 32 40 48 56

Distribution1#show mls qos maps dscp-cos

   Dscp-cos map:

     d1 :  d2 0  1  2  3  4  5  6  7  8  9

     ---------------------------------------

      0 :    00 00 00 00 00 00 00 00 01 01

      1 :    01 01 01 01 01 01 02 02 02 02

      2 :    02 02 02 02 03 03 03 03 03 03

      3 :    03 03 04 04 04 04 04 04 04 04

      4 :    05 05 05 05 05 05 05 05 06 06

      5 :    06 06 06 06 06 06 07 07 07 07

      6 :    07 07 07 07

Если порт настроен на доверие CoS, все входящие значения класса обслуживания становятся
доверенными, а значения DSCP перемаркируются согласно таблице сопоставления
класса обслуживания и DSCP. В соответствии с настройками сопоставления класса
обслуживания и DSCP по умолчанию, значения сопоставляются следующим образом:

Интересный момент, который необходимо помнить.

Например, интерфейс GigabitEthernet1/0/12 настроен на
доверие CoS.

interface GigabitEthernet1/0/12

 description **** Cisco IP Phone  ****

 switchport access vlan 10

 switchport mode access

 switchport voice vlan 20

 mls qos trust cos

 spanning-tree portfast

end

Телефон Cisco IP Phone отмечает полезную нагрузку значениями CoS 5 и DSCP EF при отправке трафика на коммутатор. При входе трафика в порт Gi 1/0/12, коммутатор
доверяет значению CoS. После этого, коммутатор смотрит в
таблицу COS—DSCP, которая
говорит ему о следующих соответствиях:

Distribution1#show mls qos maps cos-dscp

   Cos-dscp map:

        cos:   0  1  2  3  4  5  6  7

     --------------------------------

       dscp:   0  8 16 24 32 40 48 56

Т.е 
сопоставляет значение DSCP CS5 (40) для значения CoS 5 из таблицы сопоставления класса обслуживания и
DSCP. Весь полезный голосовой трафик с классом обслуживания 5 маркируются коммутатором
значением DSCP, равным CS5. Т.е, изначально телефон промаркировал пакет
значением DSCP=EF(46), а на
выходе с коммутатора мы уже имеем CS5.

Использование этого значения нежелательно. Необходимое
значение DSCP для полезной голосовой нагрузки — DSCP EF. По умолчанию, другие
значения класса обслуживания сопоставляются значениям DSCP согласно
спецификациям RFC.

Чтобы этого избежать мы можем подкорректировать
таблицу сопоставления COS—DSCP, чтобы изменить значение DSCP, равное EF, таким
образом, что оно соответствовало CoS 5.

Distribution1(config)#mls qos map cos-dscp 0  8 16 24 32 46 48 56

Теперь взглянем на нашу карту.

ALM-3750X-SRV#sh mls qos maps cos-dscp 

   Cos-dscp map:

        cos:   0  1  2  3  4  5  6  7 

     --------------------------------

       dscp:   0  8 16 24 32 46 48 56

Теперь трафик телефона в голосовом VLAN, будет маркироваться теми же значениями DSCP=EF, которые выставляет телефон.  Если порт настроен на доверие DSCP, все входящие значения DSCP становятся доверенными, а значения COS перемаркируются согласно таблице сопоставления класса обслуживания и DSCP. В соответствии с настройками сопоставления DSCP и класса обслуживания по умолчанию, значения сопоставляются следующим образом:

Distribution1#show mls qos maps dscp-cos
   Dscp-cos map:
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     ---------------------------------------
      0 :    00 00 00 00 00 00 00 00 01 01
      1 :    01 01 01 01 01 01 02 02 02 02
      2 :    02 02 02 02 03 03 03 03 03 03
      3 :    03 03 04 04 04 04 04 04 04 04
      4 :    05 05 05 05 05 05 05 05 06 06
      5 :    06 06 06 06 06 06 07 07 07 07
      6 :    07 07 07 07

В этом случае не требуется изменять эти значения по умолчанию!!!

Примечание: В одной сети все коммутаторы Cisco Catalyst должны обладать идентичными таблицами сопоставлений. Наличие различных таблиц в разных коммутаторах приведет к нежелательным последствиям!!!

В разделе
«Классификация и маркирование» описывается метод классификации и
маркировки при помощи MQC. Вместо настройки для каждого порта можно
использовать MQC. Можно также маркировать входящие пакеты при помощи карты
политик.

Требования
в этом примере таковы:

На
диаграмме ниже показана карта политик, закрепленная на входном интерфейсе
коммутатора. Нельзя применить карту политик к исходящему трафику любого
интерфейса коммутатора Catalyst. В этом разделе не уделено особого внимания той
составляющей функции обеспечения контроля качества, которая основывается на
очередях. Раздел посвящен MQC, который применяется для интерфейса.