Quality of Service

Imagine driving down a three lane highway at a decent (legal) speed. It’s a beautiful day with the sun high in the sky and a nice cool wind coming in through the window. All is going well. In just a few minutes you should be at your destination. Suddenly, all you see in front of you are red lights. You roll to a stop and realize that ahead of you is construction, converting the three lane highway into a single lane snooze-fest. The construction bottleneck has slowed traffic down to a crawl. Hopefully other drivers will let you in as you inch towards the next lane. If only there was a way to just jump to the front of the lane. Well, in this scenario not so much. However, if this was a network full of layer 2 and layer 3 devices, we would have some ways to organize the traffic in a way that the important traffic (cars) keep moving efficiently through the bottlenecks.

Quality of Service (QoS) is technology features that allow for the management of traffic as it flows through the network. The purpose of this writing is to serve as a quick intro with some ideas for configuration. For an administrator of a network, making sure your voice traffic stays consistent, live video streams work and your important data reaches its destinations in a timely fashion is a concern. Engineering how data flows is important. Connecting routers and switches is the foundation in the network, but you also have to spend time thinking about what data will flow through those routers and switches. This might lead to a conversation with the business. What data is important to your business? The business can determine what needs to be prioritized or guaranteed. Usually, voice traffic is important for a company. I don’t think there is anyone out there who enjoys a terrible voice conversation; I’m not talking about the content of the conversation either. Garbled calls and disconnects are ways to have users open tickets with your IT department. The business might need a certain SSH session to be at the top of the list whenever the bandwidth at your site is depleted. When configuring QoS in the environment it is best to have a conversation with the application owners. Unless you are familiar with the application in question, whoever supports the application will need to answer questions you will have about the application. What does it do? What ports does it use? How much bandwidth is required to ensure the application works? These are all questions to answer about the applications you are trying to prioritize or provide any sort of guarantee. Often times, these conversations will come up in environments where you have a wide area network connecting your sites together. Perhaps the traffic will traverse an MPLS on its way to your data center. You would not have QoS for traffic hitting the internet directly. There is not much you can do about how the internet handles your traffic.

QoS Classes
There are several components to setting up QoS in an environment. I wont be diving into great detail, but hope to pierce enough to interest you and get you doing more research. The example I will discuss below would be one we can setup in a Cisco environment with multiple sites that connect to each other using an MPLS. Keep in mind, when dealing with a solution like an MPLS, unless you own and operate that MPLS, you will have a service provider. When setting up QoS, making sure you stay within your service provider’s boundaries; working with them to make changes will be something that comes up. QoS allows you to place different applications into “buckets”. These buckets are QoS Classes. Depending on the types of traffic you are separating out, you would want to utilize the various classes to organize your traffic. The key is to keep it the same across the network. This means you will need to find out what QoS classes your provider uses. Sometimes the names of the classes will vary, but here is where we also rely on the Layer 3 QoS markings. There are a few QoS models you can follow, which would have different amounts of classes within them: 5, 8 or 11.

• Network Control: Here is where your routing traffic lives (OSPF, BGP, etc.;). When bandwidth is low, routing still needs to work.
• Voice: Actual voice traffic, not signaling and call controls.
• Mission Critical: Other important data to the organization.
• Call Signaling: Here you can group traffic used for call setups.
• Network Management: DHCP, DNS and other protocols like them.
• Best Effort: Home to most of your traffic. Anything not sent to a specific class ends up here. The goal is that the traffic above Best Effort is the traffic the organization definitely wants to apply QoS to, anything else is just Best Effort.
• Scavenger: Lower than Best Effort. This is the traffic the organization really does not care for. If there are bandwidth issues, this would be the first traffic to drop. Often companies might put P2P traffic in this class.

There are other classes. You can break the above into more classes if needed. Video is a good example. You might have streaming video which is one-way in nature, but you can also have interactive video between several users.

IP NBAR
How many different applications send/receive traffic on your network? I would guess it is definitely a bit more than one. If you start writing down routing protocols, network management, traffic for home-grown apps, internet bound traffic and everything else on the network, your going to need a lot of paper. There are good applications out there out there that can give you insight to what traffic is crossing your boundaries. However, within a Cisco router, we also have a good tool that will show you the information as well. We can even use it to assist us in our QoS endeavors. Network Based Application Recognition (NBAR) looks at the traffic passing through your network device and classifies it. If you did not know how much Skinny traffic was passing through or if you wanted to classify Skinny into a certain QoS class, NBAR can assist. You can download a Protocol-Pack from Cisco’s site for your specific router. This is then uploaded to the router, installed. Each pack includes more application/traffic classifications.

A “show ip nbar protocol-pack active” command will show you the output of installed NBAR pack:

Once the pack is installed, add the “ip nbar protocol-discovery” command to your interfaces. As data enters and leaves, information is gathered on what that data is. The “show ip nbar protocol-discovery” command will give you this information.

Keep tapping the space bar; there is plenty to scroll through. Some of it might be eye-opening, especially the P2P. Each protocol-pack’s notes will show you how NBAR classifies applications/services. I use NBAR protocols in QoS configurations because it makes it much easier to reference an application. We can do the same with access-lists (and we do), but using NBAR protocols will keep your config clean.

We dived a bit into the foundation of what I look at in QoS, but we still have not reached the meat. The configs below are simple examples of what is needed and things to keep in mind. When I apply QoS, I look at ingress and egress interfaces. I classify traffic as it enters a router and apply policies to it on its way out to the WAN.

Class-Maps
Before you can apply an action to something, you want to figure out what that something is. Here is where class-maps are the focus. Break up your applications, services or just important ports into class-maps. The job of the class-maps we will use is to match the type of traffic entering the router from the LAN. It is possible the traffic entering already has a DSCP value applied. Those values can be applied at the application level. When the traffic enters, it enters with the value, but if it does not, we try to match it other ways.

class-map match-any TELEPHONY
match ip dscp ef
match protocol rtp-audio

Above is a class-map called TELEPHONY. The job of this class-map is to match voice traffic coming in to the router. The “match-any” is an OR statement. That means if the traffic comes in as DSCP EF or if NBAR determined it was rtp-audio, it will match the class-map. You can also choose to use “match-all” which would mean the traffic would match this specific classmap if it came in as DSCP EF and it was rtp-audio.

Some people might say matching on a DSCP value might not be the best thing to do. It is possible someone can change a DSCP somewhere to look like EF, when it should not be EF. That means the traffic entering the router will match this class-map and can end up taking depleting bandwidth you might have set in a policy. This is a risk albeit a small one. Depending on the environment, it can be acceptable to trust the nodes and traffic coming from them. Always keep an eye on reports, show commands and baselines to ensure the traffic coming in is what it is supposed to be.

Here are a few more class-maps for you:

class-map match-any CONTROL_AND_SIGNALING
match access-group name YOUR_CONTROL_AND_SIGNALING_ACL
match protocol attribute sub-category control-and-signaling
match ip dscp cs3

class-map match-any NETWORK_CONTROL
match protocol attribute sub-category routing-protocol

class-map match-any CLASSMAP_EF
match ip dscp ef

class-map match-any CLASSMAP_AF41
match ip dscp af41

class-map match-any CLASSMAP_CS6
match ip dscp cs6

class-map match-any CLASSMAP_CS1
match ip dscp cs1

class-map match-any CLASSMAP_CS3
match ip dscp cs3

class-map match-any CLASSMAP_CS2
match ip dscp cs2

class-map match-any ALL_VIDEO
match protocol attribute traffic-class multimedia-conferencing
match protocol attribute traffic-class real-time-interactive
match ip dscp af41
match ip dscp cs4
match protocol rtp video

class-map match-all BUSINESS_VIDEO
match class-map ALL_VIDEO
match protocol attribute business-relevance business-relevant

The first two are more of the same as the first example. CONTROL_AND_SIGNALING matches on an ACL. This ACL is where I can add ports for voice control and signaling or even specific IP addresses I want to match on. The class-map will match the traffic that is allowed by that ACL. You will also notice NBAR’s protocol attributes being used. NBAR not only includes protocols, but categorizes protocols. Out of the box NBAR will also tag certain traffic as “business-relevant”. You can see this in the 3rd and 4th class-maps. ALL_VIDEO match anything video. However, as a business we probably want to prioritize or concern ourselves with business-relevant videos. Lucky for us NBAR helps. The last class-map above, BUSINESS_VIDEO nests ALL_VIDEO within and also looks to see if the traffic is “business-relevant”. Notice how the class-map is set to “match-all”. That mean the traffic will hit the BUSINESS_VIDEO class if it matches ALL_VIDEO and if it is business-relevant. All the other class-maps are used to match specific DSCP values.

Policy-Maps
Once you organize the traffic into various class-maps, you will add them into policies. Those are the policies that sit on the various interfaces of the router. I create two policies, one I apply my LAN facing interfaces, inbound. The other is applied outbound to the interface that faces the WAN. Here in an example of a small policy applied inbound to the router:

policy-map INBOUND_FROM_LAN
class NETWORK_CONTROL
set ip dscp cs6
class TELEPHONY
set ip dscp ef
class CONTROL_AND_SIGNALING
set ip dscp cs3
class LOW
set ip dscp cs1
class class-default
set ip dscp default

Here we have our policy called INBOUND_FROM_LAN that takes the class-map NETWORK_CONTROL and sets all the traffic that matches that class-map to DSCP CS6. The reason I do this is because the provider on the WAN is expecting I will send CS6 traffic. They apply a certain bandwidth to that the class that includes CS6 on their end. This also keeps the traffic the same until it reaches its destination. As you can see if the other examples, the same occurs. I simply use the inbound policy to set DSCP values as traffic comes in and matches those class-maps. Anything not matching the above statements ends up in the class-default, which is Best Effort.

policy-map OUTBOUND_TO_MPLS
class CLASSMAP_CS6
bandwidth 128
class CLASSMAP_EF
priority 1024
class CLASSMAP_CS3
bandwidth 1024
class CLASSMAP_CS1
bandwidth 1048
class class-default
random-detect

Now as the traffic leaves the router, the above policy-map will greet it on its way out. OUTBOUND_TO_MPLS ensures certain traffic maintains certain bandwidth. Sometimes providers will charge for additional voice or video traffic to traverse their network if its goes over a specific rate. Let’s say you are only contracted to push 5 Mbps or less of video traffic, you want to ensure that your traffic leaving the site does not surpass this. The provider might drop it to Best Effort or completely drop it. Each provider is different so you might want to have a conversation with them. There is so much more we can do with QoS. These are some simple examples to get things up and running. You might need to shape the traffic that leaves your network. QoS helps there. Instead of applying the policy above to an interface, you would nest it within another policy that shapes the traffic leaving the site.

policy-map MPLS_SHAPER
class class-default
shape average 80000000
service-policy OUTBOUND_TO_MPLS

The policy above shapes in bits per second in case you do have some WAN requirements, but it also applies the previous policy-map.
Now that we have our policy-maps, lets apply them to the interfaces:

interface GigabitEthernet0/0
description LAN Facing
ip address 192.168.0.1 255.255.255.0
service-policy input INBOUND_FROM_LAN

interface GigabitEthernet0/2
description WAN Facing
bandwidth 80000
ip address 10.200.1.1 255.255.255.252
service-policy output MPLS_SHAPER

Walk away, get some coffee and verify your configurations. You will be able to see how much traffic is hitting specific policies/classes. Use the “show policy-map interface <the interface>“ command to verify the interface you applied a policy to. Here is a bit:

ROUTER#show policy-map interface gigabitEthernet 0/0/0
GigabitEthernet0/0/0

Service-policy output: MPLS_SHAPER

Class-map: class-default (match-any)
56015610834 packets, 5641967210724 bytes
5 minute offered rate 19987000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 332 packets
(queue depth/total drops/no-buffer drops) 0/3037474/0
(pkts output/bytes output) 56011997410/5641089370871
shape (average) cir 80000000, bc 320000, be 320000
target shape rate 80000000

Service-policy : OUTBOUND_TO_MPLS

queue stats for all priority classes:
Queueing
queue limit 512 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 931719/82227370

Class-map: CLASSMAP_CS6 (match-any)
19189233 packets, 5243928968 bytes
5 minute offered rate 6000 bps, drop rate 0000 bps
Match: ip dscp cs6 (48)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 19189233/5243928968
bandwidth 128 kbps
–More–

This is a good way to find out if traffic is hitting the class-maps you created. You can also see if there are drops and adjustments might be needed.

This seems like a lot, but it is simply scratching the surface. Quality of Service is pretty deep, but as an administrator in the network or perhaps a voice engineer, you will run into it at some point. You can design QoS properly with some thinking and some conversations with the business. Also, do not forget to revisit configurations as bandwidth changes occur and new applications arrive.