In this post, we will learn the following things about qos:
- why it is important to have a QoS policy,
- the traffic profile requirements for data, voice and video,
- how to define and implement a QoS policy.
What is QoS, really?
QoS can be defined as a way to ensure a quality of service of a transport system and to control its performance, especially in congestion time. It encompasses the following techniques:
- Congestion Management
- Congestion Avoidance
- Policing and Shaping
- Link Efficiency
QoS helps network engineers reduce or eliminate the famous traffic performance enemies: delay, jitter and packet loss. But in no case can QoS substitute a bandwidth upgrade. For example, with QoS, we can select which packets to be dropped and which to be queued, thus even if packets are to be dropped, they won’t affect the most important traffics we have.
You might have learned in the past that there are data applications and multimedia applications. Here, we will take things in a more general fashion and talk about traffic, instead of applications. That’s because, on the network, we will see things such as voice signaling, database transactions, video streams,…
Each traffic on the network has a set of requirements in terms of bandwidth, delay, jitter and packet loss. The collection of these parameters for each traffic constitutes what is known as traffic profile requirements.
Traffic profile requirements for voice
Voice traffic requires strict values of delay, jitter and packet loss. In fact, here are the thresholds that must not be exceeded:
- Delay: no more than 150ms of one-way delay,
- Jitter: no more than 30ms of one-way jitter,
- Packet loss: less than 1%.
The amount of bandwidth to allocate to voice traffic varies according to the codec being used. For example, with coded G.729, each voice call requires 8kbps, not to mention call signaling.
Traffic profile requirements for video
The same requirements seen with voice traffic apply to video traffic, with one extra thing: provision at least 20% of additional bandwidth, for excess burst. In fact, video traffic is greedy and burst. So we need to take the burst into consideration.
Traffic profile requirements for data
Unlike voice and video, data traffic is less influenced by delay, jitter and packet loss. But requirements vary greatly from data application to another. For example, you can not treat transactional data (such as client-server applications) the same way as you do for bulk data (such as an FTP copy).
Traffic profile requirements for Telepresence
Yes, Telepresence is here. And it encompasses data, voice and video at the same time. It has the same traffic profile requirements as voice and video, except for packet loss: it must be less than 0.05%!
Defining the QoS policy
A QoS policy is a company-wide document that describes the types of traffic, their priorities and their requirements, according to the company business goals. This document must be prepared in conjunction with all departments that use the corporate network.
Steps to elaborate and implement a QoS policy
First, to elaborate the QoS policy, we need to determine the traffic that is traversing the network. Technically, this can be done with common tools such as NBAR, Netflow and packet sniffers such as wireshark. We can call this step Network Audit.
Then, we need to consult department users to know which applications they are using, and which ones are a priority to them. After that, we align the applications with business objectives to come up with a list of applications, sorted by priority. We can call this step Business Audit.
Once we know which traffic circulates on the network and which applications are used across the company, we determine the requirements of each one. This step creates what is called Service Levels.
Now, we group traffic in classes. And for each class, we assign a policy that meets traffic profile requirements.
There are three QoS models known in history: Best Effort, IntServ and DiffServ.
Best Effort model
This is the oldest model the Internet has known and the most used without a doubt. Best Effort model delivers packets in a FIFO fashion. Urgent packets are not given any preferential treatment. All packets are treated equally. And there are no guarantees for packet delivery. This is similar to snail mail.
The queuing mechanism for best effort model is FIFO: First In First Out.
In the IntServ model, the only protocol that you need to know is RSVP. RSVP is the only RFC protocol that provides end-to-end bandwidth guarantees. It is said that it applies hardware QoS to the network.
RSVP provides three service levels: best effort, guaranteed rate and controlled load.
There are two RSVP signaling messages: PATH and RESV.
The concept of RSVP relies on the fact that applications request network resources in terms of bandwidth and delay. To each RSVP application, an RSVP flow is defined and traffic classifiers are created to manage the RSVP flows.
For each RSVP flow, bandwidth guarantees are created based on the messages received from RSVP applications. RSVP relies on CAC (Connection Admission Control, not to be confused with Call Admission Control, although they fulfill the same result) to control RSVP reservations and to ensure that RSVP guarantees are respected at any time.The network constantly monitors RSVP reservations with CAC, and if one of the RSVP interfaces reaches its limits, it makes sure that there are no new RSVP reservations that violate the existing bandwidth guarantees.
RSVP flows are put in a priority queue. All other traffic is managed by WFQ if the chosen service type is Guaranteed rate, and WRED if the chosen service type is Controlled load.
Both RSVP signaling and CAC occur on the control plane. All other traffic is treated on the data plane.
Please note that the bandwidth available for RSVP is not necessarily equal to the total interface bandwidth. It is, by default, equal to 75% of the total interface bandwidth. This can be changed with the command max-reserved-bandwidth
RSVP is less scalable than the Best Effort model.
In the DiffServ model, QoS is applied on the network path at each hop. As opposed to the IntServ model where RSVP creates bandwidth guarantees along the path, DiffServ model creates no “hard” guarantees. That’s why it is sometimes said that it applies “soft” QoS to the network.
DiffServ is an approach that provides an “almost guaranteed” QoS.It does not provide an end-to-end guarantee of QoS like IntServ framework does. However, it is highly scalable. It enforces QoS at each hop of the network path. It allows to establish classes of traffic and to apply preferential treatment to some traffic, consistently across the network path.
BA: Behavioural Aggregate: a collection of packets that have the same DSCP value, and traverse a link in the same direction. BA is associated to a PHB. BA is configured in IOS by the use of class maps.
PHB: Per Hop Behaviour: the QoS treatment that is applied to a BA such as policing, shaping, queueing,… PHB is configured in IOS by the use of policy maps.
IP Precedence spans the most significant 3 bits
DSCP spans the most significant 6 bits. The remaining 2 bits of the ToS byte are reserved for ECN.
The DS field defined by RFC occupies ToS byte in the IPv4 packet format. So its length is one byte.
Class Selector: when the least significant 3 bits of the DSCP field are set to 0, we have a class selector. Class Selector PHB values are in the form of xxx000.
There are four PHBs defined by IETF:
- EF (bandwidth guarantee and low delay, excess bandwidth is policed),
- AF (bandwidth guarantee),
- class selector.
If we want to convert DSCP encodings in binary, they are in the following format:
- aaa is the class, and
- dd is the drop probability.
Notice that the least significant bit is always 0.
The possible values of aaa are: 000, 001, 010, 011, 100 and 101.
- If aaa = 000 then we have PHB default
- if dd=00 then we have class selector
- if aaa= 101, then it is EF PHB. This is the highest user-defined PHB, because aaa= 110 and aaa = 111 correspond to IP Precedence values 6 and 7, which are reserved.
- else, we are left with aaa= 001, 010, 011 and 100 in binary, which all correspond to different classes of AF PHB.
The possible values of dd are 00, 01, 10 and 11 in binary, which correspond to decimal values 0, 1, 2 and 3. The higher the value of dd, the higher the drop probability, which means the packet is more likely to be dropped.
|“dd” Value||Drop Probability|
Traffic that needs EF PHB is a traffic that requires guaranteed bandwidth and low delays. Packets that belong to this traffic should be marked with DSCP EF (1011110 in binary or 46 in decimal). EF PHB traffic is usually voip traffic.
Each PHB is associated with a DSCP value or values. For example, EF PHB is associated with DSCP 46. To determine the corresponding DSCP value of a PHB in the form of EF or AFxy, either convert the PHB to binary then convert the binary value to decimal, or do this formula: DSCP value = x*8 + y*2. For example, the DSCP value of AF32 is equal to 3*8 + 2*2 = 28. How to verify it? well, AF32 is in binary 011 10 0 (remember the aaadd0 format), which in decimal equals to 28.
AF PHB provides bandwidth guarantees and allows excess traffic if there is bandwidth left. AF PHB is segmented in four AF classes: AF1, AF2, AF3 and AF4.
Class Selector PHB has been created for backward compatibility with IP Precedence-based devices.
Class Selector PHB is written as xxx000 in binary. The different values of Class Selector PHB are called Class Selector codepoints.
Here are the values of Class Selector codepoints, both binary and the correspondent DSCP value:
|Class Selector Codepoint||DSCP value|
To convert a Class Selector codepoint to its DSCP value, multiply by 8. For example, the DSCP value of CS2 is 2*8 = 16.
It is to note that each Class Selector codepoint is given an order. The purpose of creating codepoints for Class Selector PHB is to give preferential timely forwarding of packets. So, the higher the order of the Class Selector codepoint, the better the timely forwarding is. The worst timely forwarding a packet can have is, of course, dropping the packet :)
110000 and 111000 Class Selector codepoints have the highest orders. So they should be given the best timely forwarding. These codepoints are reserved for routing traffic.
In the upcoming sections we lean some QoS configuration commands.
QoS configuration and verification
* verify that QoS is enabled:
At this stage, all interfaces are by default untrusted. This means that any frame with a priority value will be remarked as CoS/IP Precedence/DSCP value = 0.
* trust CoS values of incoming frames. Useful for trunks:
* trust CoS values only if an attached Cisco ip phone exists (conditional trust):
At this stage, the trust boundary moves to the IP phone. Any priority value of any attached PC frames is untrused, thus remarked with priority 0. * rewrite CoS of the frames coming from the PC to a specific value, for instance, 0:
We have some trunk interfaces. Let’s trust dot1p priority values there:
* trust CoS values on frames on trunk interfaces:
* verify QoS settings on all interfaces:
Applying A QoS Policy on A Subinterface
When you try to apply a Cisco QoS policy on a subinterface, you may get the following error message:
CBWFQ : Not supported on subinterfaces
In this case, we need to use the concept of hierarchical policy, or parent and child policies. The parent policy is like a container. The child policy is the one that you wanted to apply in the first place. So for example if you want to apply a policy named “WAN_Policy”, this will be your child policy that will go under the parent policy.
In practice, what we need to do is:
- create a parent policy. Let’s name it Shaping,
- call the default class under the parent policy and configure traffic shaping for it. Recall that the default class is named class-default. Traffic shaping needs to be configured with an adequate CIR. CIR depends on the contracted bandwidth. In my case, I want to apply the QoS policy on a GigaEthernet interface connected to the WAN, and with a CIR of 20Mbps.
- this is the tricky part: attach the child policy WAN_Policy to the parent policy Shaping.
Here is what the configuration will look like:
Policy-map Shape class class-default Average Rate Traffic Shaping cir 20000000 (bps) service-policy WAN_Policy Policy-map WAN_Policy
Here goes the class definition of the policy. It depends what you’ve set on your device:
class X1 ... class X2 ... class class-default ...
The last thing is to apply the parent policy to the subinterface:
Interface Gi0/0.1122 service-policy output Shaping
You should replace Gi0/0.1122 with your interface number.
Auto QoS configuration
First, let’s see if QoS is enabled on the switch:
QoS is disabled. We should enable it on global configuration level:
if we want to display QoS settings for an interface, we do a show mls qos interface command:
At this stage we still did not define trust boundaries. That’s why Trust State and Trust Mode say “not trusted”. And we did not specify whether we’ll trust a device or not.
To define trust boundary with auto-qos, we either trust all CoS values coming on the switch interface or we trust CoS values only if an ip phone is connected to the switch port.
With auto qos voip trust, we tell the switch to trust CoS on each packet coming on the switch interface:
If we want to further limit trust boundary, we can tell the switch to trust CoS values only if a Cisco ip phone is detected on the port:
Finally, on a 3550 switch, show auto qos and show auto qos interface give the same output: