В качестве предисловия...
Queuing may be performed in software or in hardware. Within Cisco IOS Software there are two main queuing algorithms available, Class-Based Weighted-Fair Queuing (CBWFQ) and Low-Latency Queuing (LLQ).
CBWFQ
Regardless of what queuing policy is applied to an interface within Cisco IOS, there is always an underlying queuing mechanism in place called the Tx-Ring, which is a final (FIFO) output buffer. The Tx-Ring serves the purpose of always having packets ready to be placed onto the wire so that link utilization can be driven to 100%. The Tx-Ring also serves to indicate congestion to the IOS software; specifically, when the Tx-Ring fills to capacity, then the interface is known to be congested and a signal is sent to engage any LLQ/CBWFQ policies that have been configured on the interface.
Class-Based Weighted-Fair Queuing (CBWFQ) is a queuing algorithm that combines the ability to guarantee bandwidth with the ability to dynamically ensure fairness to other flows within a class of traffic. Each queue is serviced in a weighted-round-robin (WRR) fashion based on the bandwidth assigned to each class.
In Figure, a router interface has been configured with a 4-class CBWFQ policy, with an explicit CBWFQ defined for Network Control, Transactional Data, and Bulk Data respectively, as well as the default CBWFQ queue, which has a Fair-Queuing (FQ) pre-sorter assigned to it.
LLQ
Low-Latency Queuing (LLQ) is essentially CBWFQ combined with a strict priority queue. In fact, the original name for the LLQ scheduling algorithm was PQ-CBWFQ. While this name was technically more descriptive, it was obviously clumsy from a marketing perspective and hence the algorithm was renamed LLQ.
In Figure 1-18, a router interface has been configured with a 5-class LLQ/CBWFQ policy, with voice assigned to a 100 kbps LLQ, three explicit CBWFQs are defined for Call-Signaling, Transactional Data, and Bulk Data respectively, as well as a default queue that has a Fair-Queuing pre-sorter assigned to it. However, an underlying mechanism that doesn’t appear within the IOS configuration, but is shown in Figure 1-18, is an implicit policer attached to the LLQ.
The threat posed by any strict priority-scheduling algorithm is that it could completely starve lower priority traffic. To prevent this, the LLQ mechanism has a built-in policer. This policer (like the queuing algorithm itself) engages only when the LLQ-enabled interface is experiencing congestion. Therefore, it is important to provision the priority classes properly. In this example, if more than 100 kbps of voice traffic was offered to the interface, and the interface was congested, the excess voice traffic would be discarded by the implicit policer. However, traffic that is admitted by the policer gains access to the strict priority queue and is handed off to the Tx-Ring ahead of all other CBWFQ traffic.
Not only does the implicit policer for the LLQ protect CBWFQs from bandwidth-starvation, but it also allows for sharing of the LLQ. TDM of the LLQ allows for the configuration and servicing of multiple LLQs, while abstracting the fact that there is only a single LLQ “under-the-hood,” so to speak. For example, if both voice and video applications required realtime service, these could be provisioned to two separate LLQs, which would not only protect voice and video from data, but also protect voice and video from interfering with each other, as illustrated in Figure 1-19.
In Figure 1-19, a router interface has been configured with a 6-class LLQ/CBWFQ policy, with voice assigned to a 100 kbps LLQ, video assigned to a “second” 400 kbps LLQ, three explicit CBWFQs are defined for Call-Signaling, Transactional Data, and Bulk Data respectively, as well as a default queue that has a Fair-Queuing pre-sorter assigned to it.
Within such a dual-LLQ policy, two separate implicit policers have been provisioned, one each for the voice class (to 100 kbps) and another for the video class (to 400 kbps), yet there remains only a single strict-priority queue, which is provisioned to the sum of all LLQ classes, in this case to 500 kbps (100 kbps + 400 kbps). Traffic offered to either LLQ class is serviced on a first-come, first-serve basis until the implicit policer for each specific class has been invoked. For example, if the video class attempts to burst beyond its 400 kbps rate then it is dropped. In this manner, both voice and video are serviced with strict-priority, but do not starve data flows, nor do they interfere with each other.
Для понимания работы алгоритма обслуживания очередей и работы шейпера возьмем за основу 2 конфигурации:
Конфигурация 1 : MQCpolicy-map WAN-QoS
class http
shape average 3072000
set dscp af41
class Mail
shape average 1024000
set dscp af41
class class-default
fair-queue
Конфигурация 2: CBWFQ
policy-map WAN-QoSclass http
priority 3000
set dscp af11
class Mail
bandwidth 2000
set dscp af41
class class-default
fair-queue
Конфигурация 1:
- HTTP трафик будет обработан шейпером до 3 Mbps и промаркирован как AF41. HTTP трафик превышающий CIR в 3 Mbps будет помещен в буфер очереди и будет обрабатываться FIFO алгоритмом по умолчанию, и если буфер окажется переполненным (параметр hold-queue x out) , пакет будет сброшен.
- Почтовый трафик будет обработан шейпером до 1 Mbps и промаркирован как AF41. Почтовый трафик превышающий CIR в 1 Mbps будет помещен в буфер очереди и будет обрабатываться FIFO алгоритмом по умолчанию, и если буфер окажется переполненным (параметр hold-queue x out), пакет будет сброшен.
- Весь оставшийся трафик будет обработан с помощью алгоритма WFQ (директива fair-queue).
Weighted Fair Queuing (WFQ)
Weighted Fair Queuing диаметрально отличается от PQ или CQ алгоритмов. Первая и самая важная отличительная особенность, то что, WFQ не позволяет классифицировать трафик! WFQ классифицирует пакеты основываясь на потоках (flows). Под потоком (flow) понимаются все пакеты которые имеют один и тот же адрес источника и назначения, а также порты источника и назначения, вкупе с одинаковым транспортным протоколом. Следующее большое отличие между WFQ и PQ and CQ - это scheduler, который отдает предпочтение low-volume, higher-precedence flows над large-volume, lower-precedence flows. Именно потому что WFQ является flow based queing tools, а каждый поток использует отдельную очередь, количество этих очередей по сравнению с PQ или CQ значительно выше— до 4096 queues per interface.
Конфигурация 2: CBWFQ
policy-map WAN-QoS
class http
priority 3000
set dscp af11
class Mail
bandwidth 2000
set dscp af41
class class-default
fair-queue
class http
priority 3000
set dscp af11
class Mail
bandwidth 2000
set dscp af41
class class-default
fair-queue
- HTTP трафик вплоть до 3 Mbps будет обработан приоритетно и послан на интерфейс первым во время перегрузки (congestion) на TX-Ring и промаркирован как AF11.
- Почтовый трафик получит не менее 2 Mbps в момент перегрузки (congested) и промаркирован как AF41.
Напомню, что любые софтверные очереди (software queue) активируются только тогда, когда физическая очередь TX-Ring оказывается переполнена.
- Весь оставшийся трафик будет обработан с помощью алгоритма WFQ (директива fair-queue).
CBWFQ/LLQ (Queuing mechanism) on subinterfaces.
Обычно мы не можем сконфигурировать и применить CBWFQ/LLQ (Queuing mechanism) на логический интерфейс, например Tunnel0 или subinterface.
#################################################################################
Cisco IOS logical interfaces do not inherently support a state of congestion and do not support the direct application of a service policy that applies a queueing method. Instead, you first need to apply shaping to the subinterface using either generic traffic shaping (GTS) or class-based shaping. Refer to Policing and Shaping for more information.
The router prints this log message when an Ethernet subinterface is configured with a service policy that applies queueing without shaping:
In other words, you must configure a hierarchical policy with the shape command at the parent level. Use thebandwidth command for CBWFQ, or the priority command for Low Latency Queueing (LLQ) at lower levels. Class-based shaping limits the output rate and (we can assume) leads to a congested state on the logical subinterface. The subinterface than applies "backpressure," and Cisco IOS begins queueing the excess packets that are held by the shaper.router(config)# interface ethernet0/0.1 router(config-subif)# service-policy output test CBWFQ : Not supported on subinterfaces
#################################################################################
Чтобы это стало возможным нам необходимо немного обмануть систему. Для этого нам нужно создать иерархическое правило HQoS в котором мы сначала создадим parent policy на котором сконфигурирован shaper ограничивающий трафик в пределах CIR для нашего логического интерфейса, а затем к нему применяется Queuing policy в качестве child policy.
Например, если у нас есть сабинтерфейс с установленным значением CIR 10Mbps и нам необходимо ограничить сверху HTTP трафик до 3 Mbps, а также обеспечить его приоритетность в периоды перегрузки, а почтовому трафику предоставить не менее 2 Mbps, мы сконфигурируем нашу HQoS политику следующим образом:
policy-map CHILD
class HTTP
priority 3072
set dscp af11
class Mail
bandwidth 2048
set dscp af41
class class-default
fair-queue
policy-map PARENT
class class-default
shape average 10000000
service-policy CHILD
Приведенная выше конфигурация будет делать следующее:
- будет осуществлять шейпинг всего исходящего трафика на этом интерфейсе до значений определенных CIR (shape average 10000000) 10 Mbps.
- Весь трафик выше этого значения в 10 Mbps будет подвергаться буферизации и ставиться в очередь Shaping Queue (по умолчанию FIFO).
- По умолчанию Shaping Queue - FIFO алгоритм.
- Однако мы переопределяем этот алгоритм, применяя CHILD policy, фактически мы меняем FIFO алгоритм на CBFWQ/LLQ и т.д..
Рассмотрим еще один вариант.
Minimum Versus Maximum Bandwidth Controls
Оба метода - и shape и police ограничивают исходящий трафик до значения maximum kbps (CIR).
Важно отметить, что ни один ни другой механизм, не предоставляет гарантий минимальной полосы пропускания в периоды перегрузки на интерфейсе. Для этих целей, необходимо использовать команды bandwidth или priority.
Importantly, neither mechanism provides a minimum bandwidth guarantee during periods of congestion. Use the bandwidth or priority command to provide such guarantees.
A hierarchical policy uses two service policies – a parent policy to apply a QoS mechanism to a traffic aggregate and a child policy to apply a QoS mechanism to a flow or subset of the aggregate. Logical interfaces, such as subinterfaces and tunnel interfaces, require a hierarchical policy with the traffic-limiting feature at the parent level and queuing at lower levels. The traffic-limiting feature reduces the output rate and (предсказуемо) creates congestion, as seen by queuing excess packets.
Внимание: Такая конфигурация не рекомендуется и показана только для иллюстрации различий между POLICER и SHAPER для целей ограничений агрегированного трафика, в нашем случае класс class-default.
В этой ситуации команда police посылает пакеты на выходной интерфейс от классов определенных в политике child базируясь на размере пакета и количестве байт или токенов в корзине Bc (based on the size of the packet and the number of bytes remaining in the conform and exceed token buckets).
Результатом этого будет то, что битрейт выделенный для голосового и IP трафика (given to the Voice over IP (VoIP) and Internet Protocol (IP) classes) не может быть гарантирован, так как алгоритм работы police перечеркивает гарантии трафику сделанные командой priority (overriding the guarantees made by the priority feature).
class-map match-all IP match ip precedence 3 class-map match-all VoIP match ip precedence 5 policy-map child class VoIP priority 128 class IP priority 1000 policy-map parent class class-default police 3300000 103000 103000 conform-action transmit exceed-action drop service-policy child
Тем не менее,если мы будем использовать команду shape, мы получим иерархическую систему очередей (result is a hierarchical queuing system), и все гарантии при этом сохранятся (and all guarantees are made). Другими словами, когда битрейт трафика превысит указанный shape rate, трафик VoIP и IP классов получат свои гарантии по битрейту, а трафик класса class-default (at the child level) будет подвергаться сбросу.
In other words, you must configure a hierarchical policy with the shape command at the parent level. Use the bandwidth command for CBWFQ, or the priority command for Low Latency Queueing (LLQ) at lower levels. Class-based shaping limits the output rate and (we can assume) leads to a congested state on the logical subinterface. The subinterface than applies "backpressure," and Cisco IOS begins queueing the excess packets that are held by the shaper.
В соответствии с вышеприведенной конфигурацией, policing должен быть заменен на shaping.
Например:
policy-map parent class class-default shape average 3300000 103000 0 service-policy child
Inside each queue, the queuing methods use FIFO Queuing. The interesting logic for queuing
occurs after the packets have been enqueued, when the router decides from which queue to take
the next packet. Queue schedulingdescribes the process of the device, in this case a router,
choosing which queue to service next. This process is also called a service algorithm, or a queue
service algorithm. The scheduler may reserve amounts of bandwidth, or a percentage of link
bandwidth, for a particular queue. The scheduler may always service one queue first, which
means the packets in that queue will experience very low delay and jitter.
Комментариев нет:
Отправить комментарий