Queuing: Custom and Priority Queuing (CQ+PQ) + Queueing Strategies

Priority Queuing (PQ)

The “next level” of queuing is Priority Queuing (PQ), where four predefined queues exist: High, Medium, Normal, and Low. Traffic is placed into one of these four queues through the use of access lists and priority lists. The High queue is also called the strict priority queue, making PQ and LLQ the queueing solutions to use when a priority queue is needed.

These four queues are predefined, as are their limits:

  • High-Priority Queue: 20 Packets
  • Medium-Priority Queue: 40 Packets
  • Normal-Priority Queue: 60 Packets
  • Low-Priority Queue: 80 Packets

Important Concept for PQ:

PQ is not round-robin; when there are packets in the High queue, they’re going to be sent before any packets in the lower queues. (If too many traffic types are configured to go into the High and Medium queues, packets in the Normal and Low queues may never be sent)

R3(config)#priority-list 1 protocol ip ?

Example ACL for PQ:

R3(config)#access-list 174 permit ip
R3(config)#priority-list 1 protocol ip high list 174

To place packets coming in on the Ethernet0 interface into the Normal queue, use the interface option with the priority-list command.

R3(config)#priority-list 1 interface ethernet0 normal

The default queue sizes can be changed with the queue-limit command.

Priority queuing is applied to the interface with the priority-group command.

R3(config)#int serial0
R3(config-if)#priority-group 1

show queueing verifies that PQ is now in effect on this interface.

R3#show queueing inter serial0
Interface Serial0 queueing strategy: priority
Output queue utilization (queue/count)
high/0 medium/0 normal/0 low/0
R3#show queueing priority
Current DLCI priority queue configuration:
Current priority queue configuration:
List Queue Args
1 high protocol ip
1 high protocol ip list 174
1 medium protocol ip tcp port domain
1 normal interface Ethernet0
1 normal limit 120

Custom Queueing (CQ)

Custom Queueing (CQ) takes PQ one step further – CQ actually allows you to define how many bytes will be forwarded from every queue when it’s that queue’s turn to transmit. CQ doesn’t have the same queues that PQ has, though. CQ has 17 queues, with queues 1 – 16 being configurable.

Queue Zero carries network control traffic and cannot be configured to carry additional traffic. By default, the packet limit for each configurable queue is 20 packets and each will send 1500 bytes when it’s that queue’s turn to transmit.

Traffic that uses Queue Zero includes

  • Hello packets for EIGRP, OSPF, IGRP, ISIS
  • Syslog messages
  • STP keepalives

CQ uses a round-robin system to send traffic. When it’s a queue’s turn to send, that queue will transmit until it’s empty or until the configured byte limit is reached. By configuring a byte-limit, CQ allows you to allocate the desired bandwidth for any and all traffic types.

Configuring CQ is basically a three-step process:

  • Define the size of the queues
  • Define what packets should go in each queue
  • Define the custom queue list by applying the list to the appropriate interface

Defining The Custom Queue Size

R3(config)#queue-list 1 queue 1 limit ?
<0-32767> number of queue entries
R3(config)#queue-list 1 queue 1 limit 100

Defining The Packets To Be Placed In Each Custom Queue

In the following example, traffic sourced from network /25 and destined for /28 will be placed into Queue 2.

R3(config)#access-list 124 permit ip

R3(config)#queue-list 1 protocol ip ?
<0-16> queue number

R3(config)#queue-list 1 protocol ip 2 ?
fragments Prioritize fragmented IP packets
gt Classify packets greater than a specified size
list To specify an access list
lt Classify packets less than a specified size
tcp Prioritize TCP packets 'to' or 'from' the specified port
udp Prioritize UDP packets 'to' or 'from' the specified port

R3(config)#queue-list 1 protocol ip 2 list 124

To queue traffic according to the incoming interface, use the interface option with the queue-list command. All traffic arriving on ethernet0 will be placed into Queue 4.

R3(config)#queue-list 1 interface ethernet0 4

To change the amount of bytes a queue will transmit when the round-robin format allows it to, use the byte-count option. Here, we’ll double the default for Queue 3.

R3(config)#queue-list 1 queue 3 byte-count 3000

A default queue can also be created as a “catch-all” for traffic that isn’t matched by earlier arguments. Since this example has used queues 1 – 4, Queue 5 will be used as the default queue.

R3(config)#queue-list 1 default 5

Defining The Custom Queue List By Applying It To The Appropriate Interface

To apply the custom queue to an interface, use the custom-queue-list command. To verify the configuration, run show queueing custom and show queueing interface serial0.

Queueing Summary

Weighted Fair Queueing (Flow-Based)

  • No predefined limit on the number of queues
  • Assigns weights to traffic flows
  • Low-bandwidth, interactive transmissions are given priority over high bandwidth transmissions
  • The default queueing strategy for physical interfaces running at or less than E1 speed, AND that aren’t running LAPB, SDLC, Tunnels, Loopbacks, Dialer Profiles, Bridges, Virtual Interfaces, or X.25.

Priority Queueing

  • Four predefined queues
  • High priority queue traffic is always sent first, sometimes at the expense of lower queues whose traffic may receive inadequate attention
  • Not the default under any circumstances, must be manually configured
  • A maximum of 64 classes can be defined

Custom Queueing

  • 17 overall predefined queues; Queue Zero is used for network control traffic and cannot be configured to carry other traffic, leaving 16 configurable queues
  • Uses a round-robin transmission approach
  • A maximum of 64 classes can be defined
  • Not the default under any circumstances, must be manually configured

What Queueing option to use?

This decision often comes down to whether you’ve got voice traffic on your network. If you do, Priority Queueing is probably your best choice. PQ offers a queue (the High queue) that will always offer the highest priority to traffic – but you must be careful and not choke out traffic in the lower queues at the expense of priority traffic.

If there’s no delay-sensitive traffic such as voice or video, Custom Queueing works well, since CQ allows you to configure the size of each queue as well as allocating the maximum amount of bandwidth each queue is allowed to use.

In comparison to PW and CQ, Weighted Fair Queueing requires no access-list configuration to determine priority traffic, because there isn’t any priority traffic. Both low-volume, interactive traffic as well as higher volume traffic such as file transfers gets a fair amount of bandwidth.

Queuing: FIFO, WFQ, CBWFQ, LLQ + Global Synchronisation

I have already covered some of the QoS basics from CCNA Voice, however the Chris Bryant Study Guide dives deeper into the actual configuration of each queuing method. It is no wonder so many people just use AutoQoS instead of manually creating these queues. 🙂

First In First Out (FIFO)

FIFO is just what it sounds like – there is no priority traffic, no traffic classes, no queueing decision for the router to make. This is the default for all Cisco router interfaces, with the exception of Serial interfaces running at less than E1 (2.048 MBPS) speed. FIFO is fine for many networks, and if you have no problem with network congestion, FIFO may be all you need. If you’ve got traffic that’s especially time-sensitive such as voice and video, FIFO is not your best choice.

(Flow Based) Weighted Fair Queuing (WFQ)

WFQ prevents one particular stream of network traffic, or flow, from using most or all of the available bandwidth while forcing other streams of traffic to sit and wait. These flows are defined by WFQ and require no access list configuration. Flow-based WFQ is the default queueing scheme for Serial interfaces running at E1 speed or below.

Flow-Based WFQ takes these packet flows and classifies them into conversations. WFQ gives priority to the interactive, low-bandwidth conversations, and then splits the remaining bandwidth fairly between the non-interactive, high-bandwidth conversations.

The key with WFQ is that one file transfer flow will not have priority over the other.

We don’t even have to configure it on the following Serial interface, since WFQ is enabled by default on all serial interfaces running at or below E1 speed. Here are the steps:

R1(config)#int serial0
R1(config-if)#fair-queue ?
<1-4096> Congestive Discard Threshold

The Congestive Discard Threshold dictates the number of packets that can be held in a single queue. The default is 64. Let’s change it to 200.

R1(config)#int serial0
R1(config-if)#fair-queue ?
<1-4096> Congestive Discard Threshold
R1(config-if)#fair-queue 200

To verify your queuing configuration, run show queue followed by theinterface type and number.

R1#show queue serial0
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/200/0 (size/max total/threshold/drops)
Conversations 0/0/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec

The Dynamic Conversation Queues are used for normal, best-effort conversations. We’ll change that to 200 as well.

R1(config-if)#fair-queue 200 200
Number of dynamic queues must be a power of 2 (16, 32, 64, 128, 256, 512, 1024)

The final WFQ option is the number of Reservable Conversation Queues. The default here is zero. These queues are used for specialized queueing and Quality of Service features like the Resource Reservation Protocol (RSVP). We’ll set this to 100.

R1(config-if)#fair-queue 200 256 100

show queue verifies that all three of these values have been successfully set, as does show queuing fair.

R1#show queue serial 0
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/200/0 (size/max total/threshold/drops)
Conversations 0/0/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec

If any of the following features are running on the interface, WFQ will not be the default:

  1. Tunnels, Bridges, Virtual Interfaces
  2. Dialer interfaces, LAPB, X.25

(Class-Based) Weighted Fair Queuing

There’s an advanced form of WFQ, Class-Based Weighted Fair Queuing (CBWFQ) that allows manual configuration of queuing – and CBWFQ does involve access list configuration.

Real world example to configure CBWFQ:

1. We’ll first define two classes, one that will be applied to TCP traffic sourced from /24, and another applied to FTP traffic from /24. The first step is to write two separate ACLs, with one matching the first source and another matching the second. Don’t write one ACL matching both.

R1(config)#access-list 100 permit tcp any
R1(config)#access-list 110 permit tcp any eq ftp

2. Now two class maps will be written, each calling one of the above ACLs

R1(config)#class-map 17210100
R1(config-cmap)#match access-group 100
R1(config)#class-map 17220200
R1(config-cmap)#match access-group 110

(The actual values applied to the traffic are contained in our next step, the policy map)

3. Create the policy-map:

R1(config)#policy-map CBWFQ
R1(config-pmap)#class 17210100
QoS policy-map class configuration commands:
bandwidth Bandwidth
exit Exit from QoS class action configuration mode
no Negate or set default values of a command
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 QoS Service Policy
shape Traffic Shaping
police Police

For traffic matching class 17210100, we’ll assign bandwidth of 400 and a queue limit of 50 packets; for traffic matching class 17220200, we’ll assign bandwidth of 200 and a queue limit of 25 packets. The bandwidth assigned to a class is the value CBWFQ uses to assign weight.

R1(config)#policy-map CBWFQ
R1(config-pmap)#class 17210100
R1(config-pmap-c)#bandwidth 400
R1(config-pmap-c)#queue-limit 50
R1(config-pmap-c)#class 17220200
R1(config-pmap-c)#bandwidth 200
R1(config-pmap-c)#queue-limit 25
If no queue limit is configured, the default of 64 is used.

4. Finally, we need to apply this policy map to the interface. As with ACLs, a Cisco router interface can have one policy map affecting incoming traffic and another affecting outgoing traffic. We’ll apply this to traffic leaving Serial0.

R1(config)#int s0
R1(config-if)#service ?
history Keep history of QoS metrics
input Assign policy-map to the input of an interface
output Assign policy-map to the output of an interface
R1(config-if)#service output CBWFQ

*Must remove fair-queue configuration first.

5. To view the contents of a policy map, run show policy-map

R1#show policy-map CBWFQ
Policy Map CBWFQ
Class 17210100
Bandwidth 400 (kbps) Max Threshold 50 (packets)
Class 17220200
Bandwidth 200 (kbps) Max Threshold 25 (packets)

CBWFQ configuration does have its limits. By default, you can’t assign over 75% of an interface’s bandwidth via CBWFQ, because 25% is reserved for network control and routing traffic.

If you really need to change this reserved percentage – and you should have a very good reason before doing so. Use the max-reserved-bandwidthcommand on the interface. The following configuration changes the reservable bandwidth to 85%.

R1(config-if)#max-reserved-bandwidth ?
<1-100> Max. reservable bandwidth as % of interface bandwidth
R1(config-if)#max-reserved-bandwidth 85

The “reservable bandwidth” referenced in this command isn’t just the bandwidth assigned in CBWFQ. It also includes bandwidth allocated for the following:

  • Low Latency Queuing (LLQ)
  • IP Real Time Protocol (RTP) Priority
  • Frame Relay IP RTP Priority
  • Frame Relay PVC Interface Priority Queuing
  • Resource Reservation Protocol (RSVP)

CBWFQ And Packet Drop

If the queue is full, what happens? No matter how efficient your queuing strategy, sooner or later, the router is going to drop some packets. The default method of packet drop with CBWFQ is tail drop, and that’s just what it sounds like – packets being dropped from the tail end of the queue. Tail drop offers no mechanism to look at a packet and decide that a packet already in the queue should be dropped to make room for it.

TCP Global Synchronization/Random Early Detection and Weighted Random Early Detection

  • Packets dropped due to tail drop result in the TCP senders reducing their transmission rate.
  • As the transmission slows, the congestion is reduced.
  • All TCP senders will gradually increase their transmission speed as a result of the reduced congestion – which results in congestion occurring all over again.

To avoid the TCP Global Synchronization problems, Random Early Detection (RED) or Weighted Random Early Detection (WRED) can be used in place of Tail Drop.

  • RED will proactively drop packets before the queue gets full, but the decision of which packets will be dropped is still random.
  • WRED uses either a packet’s IP Precedence or Differentiated Services Code Point (DSCP) to decide which packets should be dropped.
  • WRED gives the best service it can to packets in a priority queue. If the priority queue becomes full, WRED will drop packets from other queues before dropping any from the priority queue.

WRED Configuration Example

R1(config)#policy-map CBWFQ_WRED
R1(config-pmap)#class 17210100
R1(config-pmap-c)#bandwidth 400
R1(config-pmap-c)#random-detect ?
dscp parameters for each dscp value
dscp-based Enable dscp-based WRED as drop policy
exponential-weighting-constant weight for mean queue depth calculation
prec-based Enable precedence-based WRED as drop policy
precedence parameters for each precedence value

*Both RED and WRED are useful only when the traffic in question is TCP based.

Low Latency Queuing

CBWFQ is definitely a step in the right direction, but what we’re looking for is a guarantee (or something close to it) that data adversely affected by delays is given the highest priority possible.

Low Latency Queuing (LLQ) is an “add-on” to CBWFQ that creates such a strict priority queue for such traffic, primarily voice traffic, allowing us to avoid the jitter that comes with voice traffic that is not given the needed priority queuing. (Cisco recommends that you use an LLQ priority queue only to transport Voice Over IP traffic.)

Since we’re mentioning “priority” so often here, it shouldn’t surprise you to learn that the command to enable LLQ is priority.

Before we configure LLQ, there are a couple of commands and services we’ve mentioned that don’t play well with LLQ:

  • WRED and LLQ can’t work together. Why? Because WRED is effective only with TCP-based traffic, and the voice traffic that will use LLQ’s priority queue is UDP-based. The random-detect and priority commands can’t be used in the same class.
  • By its very nature, LLQ doesn’t have strict queue limits, so the queue-limit and priority commands are mutually exclusive.
  • Finally, the bandwidth and priority commands are also mutually exclusive.

In the following example, we’ll create an LLQ policy that will place any UDP traffic sourced from /24 and destined for /24 into the priority queue – IF the UDP port falls in the 17000-18000 or 20000- 21000 range. The priority queue will be set to a maximum bandwidth of 45 kbps. The class class-default defines what happens to traffic that doesn’t match any other classes, and we’ll use that class to apply fair queuing to unmatched traffic.

R2#show access-list
Extended IP access list 155
permit udp range 17000 18000
permit udp range 20000 21000
R2(config)#class-map VOICE_TRAFFIC_PRIORITY
R2(config-cmap)#match access-group 155
R2(config)#policy-map VOICE
R2(config-pmap)#class VOICE_TRAFFIC_PRIORITY
R2(config-pmap-c)#priority 45
R2(config-pmap-c)#class class-default
R2(config-pmap-c)#interface serial0
R2(config-if)#service-policy output VOICE