Congestion Management
Queuing Overview
A queue is used to store traffic until it can be processed or serialized. Both
switch and router interfaces have ingress (inbound) queues and egress
(outbound) queues.
An ingress queue stores packets until the switch or router CPU can forward
the data to the appropriate interface. An egress queue stores packets until the
switch or router can serialize the data onto the physical wire.
Switch ports and router interfaces contain both hardware and software
queues.
Queue Congestion
Switch (and router) queues are susceptible to congestion. Congestion occurs
when the rate of ingress traffic is greater than can be successfully processed
and serialized on an egress interface. Common causes for congestion
include:
• The speed of an ingress interface is higher than the egress interface.• The combined traffic of multiple ingress interfaces exceeds the
capacity of a single egress interface.
• The switch/router CPU is insufficient to handle the size of the
forwarding table.
By default, if an interface’s queue buffer fills to capacity, new packets will
be dropped. This condition is referred to as tail drop, and operates on a
firstcome, first-served basis. If a standard queue fills to capacity, any new
packets are indiscriminately dropped, regardless of the packet’s
classification or marking.QoS provides switches and routers with a mechanism to queue and service
higher priority traffic before lower priority traffic.
QoS also provides a mechanism to drop lower priority traffic before higher
priority traffic, during periods of congestion. This is known as Weighted
Random Early Detection (WRED)
Types of Queues
Recall that interfaces have both ingress (inbound) queues and egress
(outbound) queues. Each interface has one or more hardware queues (also
known as transmit (TxQ) queues). Traffic is placed into egress hardware
queues to be serialized onto the wire.
There are two types of hardware queues. By default, traffic is placed in a
standard queue, where all traffic is regarded equally. However, interfaces
can also support strict priority queues, dedicated for higher-priority traffic.
DiffServ QoS can dictate that traffic with a higher DSCP or IP Precedence
value be placed in strict priority queues, to be serviced first. Traffic in a
strict priority queue is never dropped due to congestion.
Forms of Queuing
The default form of queuing on nearly all interfaces is First-In First-Out
(FIFO). This form of queuing requires no configuration, and simply
processes and forwards packets in the order that they arrive. If the queue
becomes saturated, new packets will be dropped (tail drop).
This form of queuing may be insufficient for real-time applications,
especially during times of congestion. FIFO will never discriminate or give
preference to higher-priority packets. Thus, applications such as VoIP can be
starved out during periods of congestion.
Hardware queues always process packets using the FIFO method of
queuing. In order to provide a preferred level of service for high-priority
traffic, some form of software queuing must be used. Software queuing
techniques can include:
• First-In First-Out (FIFO) (default)• Priority Queuing (PQ)
• Custom Queuing (CQ)
• Weighted Fair Queuing (WFQ)
• Class-Based Weighted Fair Queuing (CBWFQ)
• Low-Latency Queuing (LLQ)
In summary:(taken from packetlife)
Software queuing usually employs multiple queues, and each is assigned a
specific priority. Traffic can then be assigned to these queues, using access lists
or based on classification. Traffic from a higher-priority queue is serviced before
the traffic from a lower-priority queue.
Please note: traffic within a single software queue (sometimes referred to as
sub-queuing) is always processed using FIFO.
Note also: if the hardware queue is not congested, software queues are
ignored. Remember, software-based queuing is only used when the
hardware queue is congested. Software queues serve as an intermediary,
deciding which traffic types should be placed in the hardware queue first and
how often, during periods of congestion.
Priority Queuing (PQ)
Priority Queuing (PQ) employs four separate queues:
• High
• Medium
• Normal (default)
• Low
Traffic must be assigned to these queues, usually using access-lists. Packets
from the High queue are always processed before packets from the Medium
queue. Likewise, packets from the Medium queue are always processed
before packets in the Normal queue, etc. Remember that traffic within a
queue is processed using FIFO.
As long as there are packets in the High queue, no packets from any other
queues are processed. Once the High queue is empty, then packets in the
Medium queue are processed… but only if no new packets arrive in the High
queue. This is referred to as a strict form of queuing.
The obvious advantage of PQ is that higher-priority traffic is always
processed first. The nasty disadvantage to PQ is that the lower-priority
queues can often receive no service at all. A constant stream of High priority
traffic can starve out the lower-priority queues.
Custom Queuing (CQ)
A less strict form of queuing is Custom Queuing (CQ), which employs a
weighed round-robin queuing methodology.
Each queue is processed in order, but each queue can have a different weight
or size (measured either in bytes, or the number of packets). Each queue
processes its entire contents during its turn. CQ supports a maximum of 16
queues.
Weighted Fair Queuing (WFQ) dynamically creates queues based on
traffic flows. Traffic flows are identified with a hash value generated from
the following header fields:
• Source and Destination IP address
• Source and Destination TCP (or UDP) port
• IP Protocol number
• Type of Service value (IP Precedence or DSCP)
Traffics of the same flow are placed in the same flow queue. By default, a
maximum of 256 queues can exist, though this can be increased to 4096.
If the priority (based on the ToS field) of all packets are the same, bandwidth
is divided equally among all queues. This results in low-traffic flows
incurring a minimal amount of delay, while high-traffic flows may
experience latency.
Packets with a higher priority are scheduled before lower-priority packets
arriving at the same time. This is accomplished by assigning a sequence
number to each arriving packet, which is calculated from the last sequence
number multiplied by an inverse weight (based on the ToS field). In other
words a higher ToS value results in a lower sequence number, and the
higher-priority packet will be serviced first.
WFQ is actually the default on slow serial links (2.048 Mbps or slower).
To explicitly enable WFQ on an interface:
Router(config)# interface s0/0
Router(config-if)# fair-queue
The following are optional WFQ parameters:
Router(config)# interface s0/0
Router(config-if)# fair-queue 128 1024
The 128 value increases the maximum size of a queue, measured in packets
(64 is the default). The 1024 value increases the maximum number of
queues from its default of 256.
The following queuing methods are based on WFQ:
• Class-Based Weighted Fair Queuing (CBWFQ)
• Low Latency Queuing (LLQ)
Class-Based WFQ (CBWFQ)
WFQ suffers from several key disadvantages:
• Traffic cannot be queued based on user-defined classes.
• WFQ cannot provide specific bandwidth guarantees to a traffic flow.
• WFQ is only supported on slower links (2.048 Mbps or less).
These limitations were corrected with Class-Based WFQ (CBWFQ).
CBWFQ provides up to 64 user-defined queues. Traffic within each queue is
processed using FIFO. Each queue is provided with a configurable minimum
bandwidth guarantee, which can be represented one of three ways:
• As a fixed amount (using the bandwidth command).
• As a percentage of the total interface bandwidth (using the bandwidth
percent command).
• As a percentage of the remaining unallocated bandwidth (using the
bandwidth remaining percent command).
Note: the above three commands must be used exclusively from each other –
it is no possible to use the fixed bandwidth command on one class, and
bandwidth percent command on another class within the same policy.
CBWFQ queues are only held to their minimum bandwidth guarantee during
periods of congestion, and can thus exceed this minimum when the
bandwidth is available.
By default, only 75% of an interface’s total bandwidth can be reserved. This
can be changed using the following command:
Router(config)# interface s0/0
Router(config-if)# max-reserved-bandwidth 90
The key disadvantage with CBWFQ is that no mechanism exists to provide a
strict-priority queue for real-time traffic, such as VoIP, to alleviate latency.
Low Latency Queuing (LLQ) addresses this disadvantage, and will be
discussed in detail shortly.
Low Latency Queuing (LLQ)
Low-Latency Queuing (LLQ) is an improved version of CBWFQ that
includes one or more strict-priority queues, to alleviate latency issues for
real-time applications. Strict-priority queues are always serviced before
standard class-based queues.
The key difference between LLQ and PQ (which also has a strict priority
queue), is that the LLQ strict-priority queue will not starve all other queues.
The LLQ strict-priority queue is policed, either by bandwidth or a
percentage of the bandwidth.
As with CBWFQ, configuration of LLQ is accomplished using MQC:
Lab Work:
No comments:
Post a Comment