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 ?
high
medium
normal
low

Example ACL for PQ:

R3(config)#access-list 174 permit ip 20.1.1.0 0.0.0.255 30.3.3.0 0.0.0.31
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 100.1.1.0 /25 and destined for 200.2.2.0 /28 will be placed into Queue 2.

R3(config)#access-list 124 permit ip 100.1.1.0 0.0.0.127 200.2.2.0 0.0.0.15

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
<cr>

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.

Voice and Video: Voice + QoS (Best Effort, IntServ + DiffServ)

Fact: The human ear will only accept 140 – 150 milliseconds of delay before it notices a problem with voice delivery. That’s how long we have to get the voice traffic from source to destination before the voice quality is compromised.

Voice VLANs

When it comes to the link between the switch and the IP Phone, we’ve got four choices:

  1. Configure the link as an access link
  2. Configure the link as a trunk link and use 802.1p
  3. Configure the link as a trunk link and do not tag voice traffic
  4. Configure the link as a trunk link and specify a Voice VLAN
  • When Voice VLAN is configured on a port, Portfast is automatically enabled — but if you remove the Voice VLAN, Portfast is NOT automatically disabled.
  • Cisco recommends that QoS be enabled on the switch and the switch port connected to the IP phone be set to trust incoming CoS values. The commands to perform these tasks are mls qos and the interface-level command mls qos trust cos, respectively.
  • You can configure voice VLANs on ports running port security or 802.1x authentication. It is recommended that port security be set to allow more than one secure MAC address.
  • CDP must be running on the port leading to the IP phone. CDP should be globally enabled on all switch ports, but take a few seconds to make sure with show cdp neighbor.
  • Voice VLAN is supported only on L2 access ports.

Particularly when implementing video conferencing, make sure your total overall traffic doesn’t exceed 75% of the overall available bandwidth. That includes video, voice, and data! Cisco also recommends that voice and video combined not exceed 33% of a link’s bandwidth. This allows for network control traffic to flow through the network and helps to prevent jitter as well.

Voice And Switch QoS

three main enemies when it comes to successful voice transmission:

  1. jitter
  2. delay
  3. packet loss

QoS

Best-effort delivery is the QoS you have when you have no explicit QoS configuration – the packets are simply forwarded in the order in which they came into the router. Best-effort works fine for UDP, but not for voice traffic.

  1. The Integrated Services Model, or IntServ, is far superior to best-effort. IntServ uses the Resource Reservation Protocol (RSVP) to do its job, and that reservation involves creating a high-priority path in advance of the voice traffic’s arrival. The device that wants to transmit the traffic does not do so until a reserved path exists from source to destination. The creation of this path is sometimes referred to as Guaranteed Rate Service (GRS), or simply Guaranteed Service.
  2. The obvious issue with IntServ is that it’s not a scalable solution – as your network handles more and more voice traffic, you’re going to have more and more reserved bandwidth, which can in turn “choke out” other traffic.
  3. That issue is addressed with the Differentiated Services Model, or DiffServ. Where IntServ reserves an entire path in advance for the entire voice packet flow to use, DiffServ does not reserve bandwidth for the flow; instead, DiffServ makes its QoS decisions on a per-router basis as the flow traverses the network. (If DiffServ sounds like the best choice, that’s because it is.)

The DiffServ Model At Layer Two

As mentioned earlier, DiffServ takes a different view of end-to-end transmission than that taken by IntServ. The DiffServ model allows each network device along the way to make a separate decision on how best to forward the packet toward its intended destination, rather than having all forwarding decisions made in advance. This process is Per-Hop Behavior (PHB).

The core tasks of Diffserv QoS are marking and classification. Marking is the process of tagging data with a value, and classification is taking the appropriate approach to queueing and transmitting that data according to that value.

It’s best practice to mark traffic as close to the source as possible to ensure the traffic receives the proper QoS as it travels across the network. This generally means you’ll be marking traffic at the Access layer of the Cisco switching model, since that’s where our end users can be found.

At Layer 2, tagging occurs only when frames are forwarded from one switch to another. We can’t tag frames that are being forwarded by a single switch from one port to another.

The VLAN ID is tagged on the frame before it goes across the trunk along with another value – a Code of Service (CoS) value – can also be placed on that frame. Where the VLAN ID indicates the VLAN whose hosts should receive the frame, the CoS is used by the switch to make decisions on what QoS, if any, the frame should receive.

ISL and Dot1Q QoS Differences

  • The ISL tag includes a 4-bit User field; the last three bits of that field indicate the CoS value. Three binary bits give us a range of decimal values of 0 – 7.
  • The dot1q tag has a User field as well, but this field is built a little differently. Dot1q’s User field has three 802.1p priority bits that make up the CoS value, and again that gives us a decimal range of 0 – 7.
  • With dot1q, the native vlan is untagged, however the receiving switch can be configured with a CoS to apply to any incoming untagged frames. Naturally, that switch knows that untagged frames are destined for the native VLAN.

The DiffServ Model At Layer Three

One of the IP header fields is Type Of Service (ToS), and that ToS value is the basis for DiffServ’s approach to marking traffic at Layer Three.

The IP ToS byte consists of…

  • an IP Precedence value, generally referred to as IP Prec (3 bits)
  • a Type Of Service value (4 bits)
  • a zero (1 bit)

DiffServ uses this 8-bit field as well, but refers to this as the Differentiated Services (DS) field. The DS byte consists of:

  • a Differentiated Service Code Point value (DSCP,6 bits,RFC 2474)
  • an Explicit Congestion Notification value (ECN, 2 bits, RFC 2481)

The 6-bit DSCP value is itself divided into two parts:

  • a Class Selector value, 3 bits
  • a Drop Precedence value, 3 bits

These two 3-bit values also have a possible range of 0 – 7 overall (000 – 111 in binary).

Here’s a quick description of the Class Selector values and their meanings:

  • Class 7 (111) – Network Control, and the name is the recipe – this value is reserved for network control traffic (STP, routing protocol traffic, etc.)
  • Class 6 (110) – Internetwork Control, same purpose as Network Control.
  • Class 5 (101) – Expedited Forwarding (EF, RFC 2598) – Reserved for voice traffic and other time-critical data. Traffic in this class is practically guaranteed not to be dropped.
  • Classes 1 – 4 (001 – 100) – Assured Forwarding (AF, RFC 2597) –

These classes allow us to define QoS for traffic that is not as time critical as that in Class 5, but that should not be left to best-effort forwarding, which is: Class 0 (000) – Best-effort forwarding. (This is the default)

We’ve got four different classes in Assured Forwarding, and RFC 2597 defines three Drop Precedence values for each of those classes:

  • High – 3
  • Medium – 2
  • Low – 1

The given combination of any class and DP value is expressed as follows:

AF (Class Number)(Drop Precedence)

That is, AF Class 2 with a DP of “high” would be expressed as “AF23”.

Trust Boundaries

The switch has to make a decision on whether to trust an incoming QoS value.

2 possibilites following this:

  1. If the incoming value is trusted, that value is used for QoS.
  2. If the incoming value is not trusted, the receiving switch can assign a preconfigured value.

Frames from your own LAN should be trusted and frames not part of your network should not be trusted. Hence creating a ‘trust boundary’.

Example:

trust

Now to the required commands! Before we perform any QoS on this switch, we have to enable it – QoS is disabled globally by default.

SW2(config)#mls qos

QoS: ensure flow-control on all interfaces are OFF for proper operation. We can trust values on two different levels. First, we can trust the value unconditionally, whether that be CoS, IP Prec, or DSCP. Here, we’ll unconditionally trust the incoming CoS value.

SW2(config-if)#mls qos trust ?
cos Classify by packet COS
device trusted device class
dscp Classify by packet DSCP
ip-precedence Classify by packet IP precedence
<cr>

SW2(config-if)#mls qos trust cos

We can also make this trust conditional, and trust the value only if the device on the other end of this line is a Cisco IP phone. IOS Help shows us that the only option for this command is a Cisco IP phone.

SW2(config-if)#mls qos trust device ? cisco-phone Cisco IP Phone
SW2(config-if)#mls qos trust device cisco-phone

If you configure that command and show mls qos interface indicates the port is not trusted, most likely there is no IP Phone connected to that port.

 SW2#show mls qos interface fast 0/5
FastEthernet0/5
trust state: not trusted
 trust mode: trust cos
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone

Extending the Trust Boundary to the PC

The best practice is to not trust the QoS values sent by the PC. Some applications have been known to set QoS values giving that application’s data a higher priority than other data. The default behavior is to not trust the CoS value from the PC, and to set that value to zero.

To overwrite the CoS value sent by the PC and set it to a value we choose, use the switchport priority extend cos command.

SW2(config-if)#switchport priority extend cos ?
<0-7> Priority for devices on appliance
SW2(config-if)#switchport priority extend cos 2

If we had chosen to trust those same frames and allow their CoS to remain unchanged after transmission from the PC, we would use the switchport priority extend trust command:

SW2(config-if)#switchport priority extend ?
cos Override 802.1p priority of devices on appliance
trust Trust 802.1p priorities of devices on appliance
SW2(config-if)#switchport priority extend trust

*Big thanks to Chris Bryant again for all of the above. Brilliant overview of foundational QoS.