WAN QoS (Quality of Service) is a critical yet largely misunderstood topic, given today’s cost-conscious IT-budget-cutting environment.

Unlike LAN bandwidth which tends to be very cheap, WAN bandwidth – especially if that bandwidth is over a private line circuit (i.e. non-internet) is quite expensive. You can buy a cheap switch for $50 or $100 and have gigabits worth of throughput at your disposal. But a 10Mbps private line circuit in a developing country can cost you many thousands of dollars each month.

So how and why is WAN QoS so important? WAN QoS ensures you are getting the maximum amount of value out of your WAN bandwidth. After all, if you’re going to pay a thousand dollars for a 10Mbps circuit between Johannesburg and London, you definitely want to ensure that the traffic most critical to you can always be sent over that circuit. You don’t want to be in a situation where someone streaming a high definition soccer game video feed prevents you from being able to print shipping labels or make phone calls to clients.

CCNA Training – Resources (Intense)

Without a mechanism like WAN QoS, this can be exactly the kind of problem you would encounter. WAN QoS gives the network administrator the ability to prioritize one packet over another packet when the link is congested. So in the case above, the router would drop the streaming video packets and send the other more important traffic.

One thing to remember about WAN QoS is that it is a tradeoff. When a link is congested, WAN QoS can send your important traffic, but it means you have to drop or delay something else to do so. Many people will put in WAN QoS, giving priority to one application, and then wonder why a different application begins to experience performance problems. Before implementing WAN QoS policies, you should know as much as possible about the types of traffic that go over your circuits, and how each and every kind of traffic should be treated should the link become congested.

You can think of WAN QoS as a giant chain. It is truly only as strong as its weakest link. If there is anywhere in the path where the QoS policies are not configured correctly, it doesn’t matter if every other place is configured perfectly; you will likely see none of the benefits of QoS. In addition, when you think of the path of WAN QoS, you should remember that it is bidirectional. It matters how traffic is queued towards your destination as well as how traffic from the destination is queued back towards you. In fact, in most cases, it is the traffic coming back towards you that is most important because almost all sites receive more traffic than they send.

Since QoS has to be done end to end with some level of configuration on every device in the path, true QoS over the internet is virtually never possible. You can do everything on the two endpoints that you control, but since you can neither choose the path nor configure the devices in that path, you have no control over what happens between those two endpoints.

QoS is going to provide the greatest level of benefit when you control every device in the path between the endpoints that are communicating with one another, or at least have a working relationship with whoever does control those endpoints. An example of this might be the MPLS backbone of the WAN carrier that connects all of your sites together.

There are three main components to QoS over the WAN: classification, marking, and queuing. Classification involves matching something about the traffic passing through the router. You can use an IP address, a port number, a specific protocol, or even application-level data if you use a tool such as NBAR in a policy-map (more on those later). Classification is how you differentiate between the types of traffic flowing over the link.

Marking is just taking the packets you have classified as requiring a certain level of QoS and setting some field in the packet so that the packet can be quickly, easily and appropriately queued. Typically, you will set the DSCP value (the first 6 bits of the type of service byte in the IP header) or the IP Precedence (first 3 bits of ToS byte). Any downstream device trusting the marking that is set can then queue based on that value, rather than have to go through the lengthy and resource-intensive process of classifying it again.

Queuing is where the real magic of WAN QoS comes in. Based on the marking you set earlier, a router will treat that packet a certain way as it queues it outbound from its interface. With the exception of some high-end switching platforms, queuing is always applied as traffic exits an interface, not as it enters. If you find yourself trying to apply queuing inbound, you should go to the other side of the link and apply it there outbound.

The level of loss, jitter, and delay a packet experiences as it’s queued outbound is in theory determined by how the router is configured to treat that packet. Remember that with QoS, you are ensuring one type of traffic is treated a certain way even if other types of less important traffic have to be dropped or delayed in order to accomplish this.

The way you want to treat a type of traffic in your QoS policy is also referred to as a PHB (or per hop behavior). As you might infer from the “per hop” in PHB, this behavior can be the same or different at each hop along the way. To avoid going into way too much detail, you can loosely say there are 3 PHBs you can choose from: default, assured forwarding, and expedited forwarding.

Each of these PHBs has different characteristics regarding loss, jitter, and latency. Loss describes what you send that doesn’t arrive at the destination. Latency describes how long what you sent takes to get to the destination. Jitter describes the variation in how long it takes to get to your destination from frame to frame. For example, if the first packet takes 20 milliseconds to get from the source to the destination and the second packet takes 27 milliseconds, you have a jitter of 7 milliseconds.

The default PHB means you have no guarantees. It’s going to deliver as much traffic as it can as fast as it can, but if something more important comes along, you don’t have a guarantee of anything. Before you begin to use QoS, it’s critical you understand more than just what you want to prioritize, since by prioritizing one thing, you are inherently assigning the default best-effort PHB to everything else.

The assured forwarding PHB guarantees low loss, but doesn’t provide any guarantees regarding latency of jitter. This is commonly used for applications where a small amount of delay or jitter is not going to cause a huge problem. For example, let’s say you are downloading a CAD drawing from a server to a workstation. You want all the data to get there, but if there is some delay, it’s not a big deal. You will likely see the download slow down a little bit, but it will pick back up and still be able to complete.

The expedited forwarding PHB guarantees low loss, low jitter, and low latency. This PHB is designed for applications and other types of traffic that can’t tolerate loss, delay, or variations in delay. Common examples include VOIP (voice over IP) and videoconferencing. If this type of traffic isn’t delivered in a timely manner, it’s almost better that it’s not delivered at all. When you are talking to someone via voice over IP, they need to hear your voice in a smooth even manner. They don’t want to hear you cut in and out when the packets carrying your voice are delayed across the network.

In order to provide the expedited forwarding PHB, a Cisco router is going to suspend servicing all other types of traffic as soon as it sees a frame with a marking it associates with the EF PHB. Only when the EF queue is empty will it begin to send traffic from the other queues again. While this is great for the EF packets, as you might imagine, this has the potential to severely affect traffic with anything other than the EF PHB.

To avoid continual servicing of the EF queue preventing any other types of traffic from being sent, Cisco built in a policing mechanism into how it provides the EF PHB. For example, if you want to allocate 100Kbps of an interface’s bandwidth to provide forwarding for EF traffic, the Cisco router will drop anything more than 100Kbps. It is very important to note however that this EF policer only activates if other non-EF traffic needs to be sent. You can send more EF traffic than what you have allocated, provided no other non EF traffic wants the bandwidth. For this reason, you want to make sure that if you are using the EF PHB, you are allocating a sufficient amount of bandwidth for what you’ve classified into it.

Though QoS can seem confusing, fortunately the configuration of basic WAN QoS is not tremendously difficult. There are 3 main components to configuring WAN QoS on a Cisco router. Cisco uses a format called MQC (Modular QoS CLI) to achieve this configuration. MQC involves defining a class-map, policy-map, and then applying the policy-map via a service-policy. In the class-map, you define what goes into a specific queue. Then, in the policy-map, you match the classes you defined earlier and assign a specific PHB for a given amount of traffic for that class. Finally, you apply the policy-map you created on an interface with the service-policy command.

An example of WAN QoS configuration is below.

First, we define ACLs and match them in class-maps. In this case, we’re matching VOIP traffic in our EF class and Oracle traffic in our AF Class. Note: you can use things other than ACLs to match the traffic, such as NBAR (network based application recognition).

Ip access-list extended EF_ACL
Permit tcp any any range 5060 5090
Permit tcp any range 5060 5090 any
Permit udp any any range 16384 32767
Permit udp any range 16384 32767 any
Ip access-list extended AF_ACL
Permit tcp any anyeq 8001
Permit tcp any eq 8001 any

Class-map match-any COS1
Match access-group name EF_ACL
Class-map match-any COS2
Match access-group name AF_ACL

Next, we define the policy-map, reference the class-maps defined earlier, and assign them a given level of service, up to a specified amount of bandwidth. In this case, we are assigning 500Kbps of an EF PHB to COS1, and 2000Kbps of an AF PHB to COS2.

Policy-map WAN_QOS
Class COS1
Priority 500
Class COS2
Bandwidth 2000

Finally, we apply the policy-map with the service-policy command. Note again that we are applying this in the outbound direction, since we can say as a general rule that queuing is only done outbound. If you do attempt to apply a policy-map with a queuing action in the inbound direction, you will see an error from the router saying that queuing cannot be done inbound.

Interface Gi0/2
Service-policy output WAN_QOS

The last very important thing to remember with the MQC is that when you apply a policy to an interface, that policy doesn’t know that your CIR (committed information rate, or amount of bandwidth you purchased from the carrier) is different than the AR (access rate, or the speed of the interface on which the circuit from the carrier is delivered).

Think of it this way – you plug the Gigabit Ethernet port of your wireless router into your modem, but that doesn’t mean you have 1Gbps worth of speed from the carrier. You may just have a 15Mbps download speed delivered on a 1Gbps interface. In order to make QoS operate in the context of the CIR rather than the AR, you must use a feature known as shaping.

Shaping with MQC still requires everything you did above, but also requires one additional step. In this extra step, you define a parent policy whose default class is shaped to the circuit amount, and then you must apply the more specific policy underneath the shaper. Finally you apply the parent shaper to the interface. Without doing this, traffic can exceed the true speed of the pipe you’ve purchased. And if you do that, your WAN carrier blissfully drops whatever it needs to whenever, without differentiating between what is more or less important to your organization.

Policy-map WAN_QOS_PARENT
Class class-default
Shape average 15000000
Service-policy WAN_QOS

Int gi0/2
No Service-policy output WAN_QOS
Service-policy output WAN_QOS_PARENT

As applications become increasingly hungry for bandwidth, ensuring that the most important kinds of traffic get the special treatment they need over the WAN when there is contention is going to become more and more important. Hopefully this explanation has been helpful in explaining how you do that, namely, through WAN QoS.