Loading...

Tech Talk Live Blog

Quality of Service – Part 2 – Differentiated Services

Frank Olshansky


This is the second of several posts that will address Quality of Service. To read the first post in this series, click on Part 1.​

In the last blog post discussing Quality of Service (QoS), I stated that there are three main parts of the Differentiated Services (DiffServ) model, which are classification and marking, policing, and scheduling. In this post, I will discuss how to configure each of these components.

On a Cisco router or Layer 3 switch, configuring QoS is done using the following method:

  1. Enable QoS.
  2. Classify your traffic into class map.
  3. Define what to do with that traffic through a policy map.
  4. Attach the policy map to an interface.

QoS is enabled by using the mls qos command in global configuration mode

Switch1(config)#mls qos

Class maps are used to classify the network traffic that will be processed by the policy maps. There are a number of ways to classify traffic into class maps, however, the most common methods are using Access Control Lists (ACLs) or the Differentiated Services Code Point (DSCP) bits in a packet.

The below configuration matches any traffic with the access list named VIDEO (which would be any traffic with a source IP address of 10.100.50.X) and places it into a class-map that is named VIDEO.

ip access-list extended VIDEO

permit ip 10.100.50.0 0.0.0.255

class-map match-any VIDEO

match access-group name VIDEO

This configuration matches any traffic that has a value of 46 set in the DSCP field and places it into a class-map that is named VOICE. The reason that this might be used is that some devices, such as some VoIP phones, mark their packets with the DSCP field already set.

class-map match-any VOICE

match ip dscp EF

It is also important to note that any traffic that does not match any class maps is placed into a class map that is named “class-default.”

The next step in configuring QoS is to define what to do with the traffic that you classified in the class maps. A policy map is an ordered list that is processed from top to bottom, and the action taken is based on the first match, so it is important to order the policy map correctly. Policy maps are used to perform the classification and marking, policing, and scheduling of packets.

It is recommended that traffic be classified and marked as close to the source as possible. Best practice is to have a policy map that performs the classification and marking on the first layer 3 device through which the traffic will be routed.

Below is a sample policy map named QOS that uses the VOICE and VIDEO class maps that I defined above. This policy map is taking any traffic which matches the VOICE class map and setting the value of the DSCP field to 46. The policy map is also taking any traffic that matches the VIDEO class map and setting the DSCP field to a value of 34. Any traffic that does not match any of the class map defined on the switch goes into the class-default class-map, and this sets the value of the DSCP field to 0.

policy-map QOS

 class VOICE

  set dscp ef

 class VIDEO

  set dscp AF41

class class-default

 set dscp 0

In the above example, the policy map is taking any traffic that already has a DSCP field value of 46 (it matches the VOICE class-map) and re-marking it with the same DSCP value. This is considered best practice because it ensures that the DSCP value for that traffic will not be set to 0.

There are two methods to limit the amount of traffic originating from an interface: policing and shaping. When an interface is policed outbound, traffic exceeding the configured threshold is dropped. Shaping, on the other hand, buffers excess traffic to transmit during non-burst periods. This is done by using the shape or the police commands when defining what to do with the traffic in the policy map, as shown in the two examples below.

In this example, all traffic is shaped to 40 Mbps.

policy-map QOS-SHAPE-40

 class class-default

  shape average 40000000   (CAREFUL: shape units are bps!)

While in this example, all traffic is policed to 40 Mbps

policy-map POLICE-MARKDOWN

  class QOS-DSCP-VOICE

   police cir 1000000

Policy maps are also used to schedule traffic. In the example below, traffic that matches the VOICE class map is placed into a priority queue which is 20% of the bandwidth of the link. Any traffic that matches the VIDEO class map has access to 60% of the remaining bandwidth after subtracting out the priority queue, so this traffic actually only has 48% of the bandwidth of the link. All other traffic has access to 40% of the remaining bandwidth after subtracting out the priority queue, which is 32% of the link.

policy-map WAN

  class VOICE

    priority percent 20

  class VIDEO

    bandwidth remaining percent 60

  class class-default

    bandwidth remaining percent 40

Policy maps can also call other policy maps as shown in the full configuration example below. This is normally done on WAN links, where all the traffic is policed or shaped first, and then the traffic is put through the scheduling policy map.

The final step to implement QoS is to apply the policy map to an interface. Policy maps can be applied to either physical ports or SVIs. As shown in the below example, this is completed by using the service-policy command. Policy maps can be defined in either the inbound or outbound direction.

interface GigabitEthernet0/2

  service-policy output WAN

There are many more optional features that can be configured and changed from the defaults, however, the above configuration is all that is required to implement QoS.

Tech Talk Live Blog Comment Guidelines:

One of our main goals at Tech Talk Live is to build a community. It is our hope that this blog can be a forum for discussion around our content. We see commenting as an integral part of this community. It allows everyone to participate, contribute, connect, and share relevant personal experience that adds value to the conversation. Respect counts. We believe you can disagree without being disagreeable. Please refrain from personal attacks, name calling, libel/defamation, hate speech, discriminatory or obscene/profane language, etc. Comments should keep to the topic at hand, and not be promotional or commercial in nature. Please do not link to personal blog posts, websites, or social media accounts that are irrelevant to the conversation. This is considered self-promotion. We welcome links that help further the conversation and reserve the right to delete those we deem unnecessary. The appearance of external links on this site does not constitute official endorsement on behalf of Tech Talk Live or Lancaster-Lebanon Intermediate Unit 13. You are solely responsible for the content that you post – please use your best judgment. We reserve the right to remove posts that do not follow these guidelines.

Leave a Reply

Your email address will not be published. Required fields are marked *

CONTACT

Tech Talk Live is the only conference of its kind in the region specifically designed for IT pros in education.


techtalklive@iu13.org
1020 New Holland Avenue, Lancaster, PA 17601

(717) 606-1770