Implementation – Low Latency Queueing

CBT Nuggets Lab Example



Under interface turn on NBAR (Internet facing Serial interface)

ip nbar protocol-discovery

load-interval 60 (Default 5 min average… lower average to 60 seconds instead)

1. Class Map to match protocol HTTP (NBAR)

2. Class Map to match protocol FTP (NBAR)

3. Single Policy Map to mark traffic. (MARK_TRAFFIC)

4. For HTTP Class Map: set dscp AF21 for HTTP

5. For FTP Class Map: set dcsp AF11 for FTP

6. show policy-map to review

7. service-policy input MARK_TRAFFIC (Marking is typically done on the INBOUND interface from the source.)

8. show policy-map interface eth0 (applied interface)


On R2

1. Class Map to match DSCP AF11 and AF21 for HTTP and FTP

2. Policy Map named ‘LLQ’ class match AF11 (FTP)

Guarantee FTP bandwidth

bandwidth bitrate/percent (10 percent for FTP) (CBWFQ)

bandwidth remaining percent 10 (Look at 75 percent of interface, assign 10 percent of remaining bandwidth) You will never breach the 75 percent best practice)

class class-default fair-queue (Enable WFQ, this is now a CBWFQ setup)


For HTTP – AF21

Not just bandwidth, but priority bandwidth!

priority percent 70

On the outbound/local eth0/0 direction interface on R2:

service-policy output LLQ (Policy Map name)

Only an output feature!

class mark and police only on an inbound interface

75 percent rule applies to Serial/WAN

Eth is 65 percent (Legacy?)

max-reserved-bandwidth – change default reserved bandwidth value! be careful!

Remember that this only applies when there is congestion! Eth interface of 100Mbps, may not actually be congested. Issue is across the cloud/internet…

On the WAN interface of the exit router on R3 we need to apply QoS….

R3 Serial 0/0

policy-map LLQ


priority percent 100

int Serial 0/0

service-policy output LLQ

max-reserved-bandwidth 100 (Lab!!!)

FTP will eventually die due to this configuration!

This is true end to end QoS.

QoS – 642-642 Training: Introduction to Quality Of Service

QoS – 642-642 Training: Introduction to Quality Of Service

1992 – Best Effort

1994 – Integrated Services

1996 – Differentiated Services

1998 – MPLS VPN + QoS

2002 – Auto QoS (Template)

2004 – QoS For Security  (*NBAR = QoS at application level not just ports)

Understanding QoS Requirements

  • Data
  • Voice – Smooth traffic, constant stream, benign. Drop/delay sensitive
  • Video – Bursty and greedy. Drop/delay sensitive. (Not as important as voice)

Citrix application is delay sensitive and similar to voice traffic/treatment on the network.

FTP is an example of data traffic that is not sensitive at all and uses TCP.

Four Evil Villians of Voice and Video

  • Lack of bandwidth – QoS will not help you!!
  • Packet Loss
  • Delay – ITU best practice less than 150ms from point A to B. (ONE WAY only, not round trip time. PSTN quality voice…)
  • Jitter – Variation of delay. 10ms and 50ms = 40ms jitter value (Dejitter buffer in place, which can have capacity issues causing jitter)

Methods of Deploying QoS

  • CLI – Legacy
  • Modular QoS CLI (MQC) – Groupings of QoS methods.
  • AutoQoS – Great, but requires tuning.
  • QoS Policy Manager – Works with Cisco Works – Legacy?

QoS Toolbelt: Classification + Marking

  • Classification involves identifying and grouping different traffic types
  • Marking tags or colors the packet, so it is can be quickly recognized elsewhere in the network.

QoS Toolbelt: Policing and Shaping

  • Policing – Drops or marks packet when limit is reached
  • Shaping – Queues packet when limit is reached. (Kinder than policing!)

QoS Toolbelt: Congestion Avoidance

  • First In First Out – (FIFO) + Taildrop – Doors closing when buffer is full
  • Random Early Detection – (RED) – Random packets dropped to stopped buffer overflow. Not supported by Cisco!
  • Weighted Random Early Detection – (WRED) – Random packet with specific marking can be dropped. If all markings are the same, then WRED acts the same as RED.

QoS Toolbelt: Congestion Management

Queuing Methods.. more to follow.

QoS Toolbelt: Link Efficiency Tools

  • Compression
  • Link Fragmentation + Interleaving (LFI) Chop up huge packets and make them smaller! (Fragmentation) – High level explanation more to follow..

This video was fairly vague as only really an introduction to QoS. More to follow..

CCIE R&S Written Exam Overview: QoS

Quality of Service (QoS)

QoS Overview

• QoS Components

– Classification & Marking

– Queueing & Congestion Management

– Shaping & Policing

Classification & Marking

• Differentiated Services (DiffServ) Model

– Traffic is grouped into classes

• Classification process defined at network edge

• Classification can be encoded inside packet itself

– Known as packet’s marking

– QoS behavior is defined by traffic’s class

• Called Per-Hop Behavior (PHB)

QoS Markings

• Defines classification of the packet

• Different types of markings

– IPv4 & IPv6 ToS Byte

• DSCP (6 bits)

• IP Precedence (3 bits)

– Layer 2 Markings

• Frame-Relay DE bit (1 bit)

• MPLS EXP bits (3 bits)

• 802.1q/ISL CoS bits (3 bits)

DSCP Default & EF PHBs

• Default

– Best Effort (Worst)

– DSCP value 0 (000000)

• Expedited Forwarding (EF) (Best)

– Priority Traffic

– DSCP value 46 (101110)


• Assured Forwarding (AF)

– Bandwidth Guaranteed

– Four classes

• AFxy where x = 1 – 4

• Higher is more preferred

– Three drop precedences

• AFxy where y = 1 – 3

• Higher means higher drop precedence

– DSCP value (xxxyy0)


• Class Selector (CS)

– Backwards compatible with IP Precedence

– Seven classes

• CSx where x = 1 – 7

• Higher is more preferred

Queueing & Congestion Management

• Queueing occurs when packets are delayed by router

• Congestion Management techniques define what happens when queueing occurs

• Techniques include…

– FIFO Queueing

– Fair Queueing & WFQ

– Priority & Low Latency Queueing

– Random Early Detection & WRED

• Technically “congestion avoidance”

– Shaped & Shared Round Robin

Queueing Techniques (Outbound)

• FIFO Queueing

– First packet to enter is first to leave

• Fair Queueing

– Shares resource equally amongst flows

• Weighted Fair Queueing (WFQ)

– Allocates bandwidth per flow proportional to weight

Queueing Techniques (Outbound)

• Class Based Weighted Fair Queueing (CBWFQ)

– WFQ class and weighting are manually defined

– Used to provide bandwidth guarantee to traffic

• Priority Queueing (LLQ)

– Packets marked as priority leave the queue first

– Used to provide low delay to traffic

• Weighted Random Early Detection (WRED)

– Drops packets randomly before queue is full

– Higher a packet’s weighting, less likely it is to be dropped

– TCP Windowing can be modified to slow down conversation

Shaping & Policing

• Used to force congestion to occur

• Traffic Shaping

– Goal is to normalize traffic flow to specified rate

– Delay and Queue exceeding traffic

– Can only apply outbound

• Traffic Policing

– Marks packets that exceed metered rate

• Drop is also a mark action

– Does not queue excess traffic

– Can be applied inbound or outbound


• Modular Quality of Service Command Line Interface

– Syntax implementation of QoS

– Allows multiple QoS methods per interface per direction and for hierarchy

– “Legacy” QoS did not

• Previously called CBWFQ

– Class Based Weighted Fair Queueing

– Now called Hierarchical Queueing Framework (HQF) as of IOS 12.4(20)T

MQC Configuration

• Define traffic classes

– class-map

– Define traffic match criteria

• Define traffic policy

– policy-map

– Define actions

• Apply policy

– service-policy [in/out] on interface

MQC Classification Options

• Match-Any vs. Match-All

• Access-Lists

• DSCP/IP Precedence


• Source Interface

• Source/Destination MAC address

• Can combine multiple matches in one class

MQC QoS Types

• Admission Control

– Policing

• Classification and Marking/Re-Marking

– Shaping

• Congestion Management & Avoidance

– Queueing Disciplines

• Link Optimization

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


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’.



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

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