It’s the best of times. It’s the worst of times. Well...not quite! However, it certainly is the age of technology offering immediate ROI, sky high cost savings, and even magic that can help add to an organization’s bottom line. It’s also the time when new technology is wreaking havoc on data delivery when implemented without considering the additional traffic load it adds to the network. To think of it, global IP traffic is expected to increase 8-fold before the end of 2015. All of this is making it trickier to deliver data to the cloud, a remote site, or even just out of the edge router.

 

When network engineers need to police and drop unwanted traffic, prioritize business traffic, and ensure data delivery, the answer is QoS or Quality of Service. QoS can provide preferential treatment to desired traffic within your LAN, at the network edge, and even over the WAN if the ISP respects your QoS markings. ISPs have always used QoS to support their own (preferred) services or to offer better chances of delivery at a premium. While ‘end-to-end QoS’ in its real sense (from a system in your LAN, over the WAN, peered links and multiple Autonomous Systems to an end-point sitting thousands of miles away) is challenging, it’s wise to use QoS to ensure that your data at least reaches the PE device without packet loss, jitter, and errors.

 

Alright, now comes the fun part, implementing Cisco QoS! Some network engineers and SMBs are wary of implementing QoS for the fear of breaking something that already works. But fear not, here is some help for beginners to get started with Cisco QoS, its design & implementation strategies.

 

QoS Design and Implementation:

QoS design consists of 3 strategies:

  • Best Effort: Default design with no differentiation or priority for any traffic. All traffic works under the best effort.
  • IntServ: A signaling protocol such as RSVP is used to signal to routers along a path about an application or service that needs QoS. This reserves bandwidth for the application and cannot be re-allocated even when the specific application is not in use.
  • DiffServ: The most widely used option. Allows a user to group traffic packets into classes and provide a desired level of service.

 

The choices for QoS implementation range from traditional CLI and MQC to AutoQoS. For a beginner, the easiest would be to start with a DiffServ design strategy and use Cisco’s MQC (Modular QoS CLI) for implementation. MQC based QoS configuration involves:

  • Class-Maps: Used to match and classify your traffic into groups, say web, peer-to-peer, business-critical, or however you think it should be classified. Traffic is classified into class-maps using match statements.
  • Policy-Maps: Describes the action to be taken on the traffic classified using class-maps. Actions can be to limit the bandwidth used by a class, queue the traffic, drop it, set a QoS value, and so forth.
  • Service-Policy: The last stage is to attach the policy-map to an interface on whose traffic you wish to perform the QoS actions defined earlier. The actions can be set to act on either Ingress or Egress traffic.

MQC QoS structure.png

Now, I would like to show you a sample configuration to put unwanted traffic and a business app in two different classes and  set their priorities using IP precedence.

 

Creating class-maps to group traffic based on user requirements:

Rtr(config)#class-map match-any unwanted

Rtr(config-cmap)#match protocol ftp

Rtr(config-cmap)#match protocol gnutella

Rtr(config-cmap)#match protocol kazaa2

 

Rtr(config)#class-map videoconf

Rtr(config-cmap)#match protocol rtp

 

Associating the class-map to a policy and defining the action to be taken:

Rtr(config)#policy-map business

Rtr(config-pmap)#class unwanted

Rtr(config-pmap-c)#set precedence 0

Rtr(config-pmap)#class videoconf

Rtr(config-pmap-c)#set precedence 5

 

Assigning the policy to an interface:

Rtr(config)#interface Se0/0

Rtr(config-if)service-policy output business

 

QoS Validation:

The next thoughts after implementation should be on how to make sure the QoS policies you created are working - Are they dropping the traffic they are supposed to or are the QoS policies affecting the performance of your business applications?

 

This is where Cisco’s Class-Based QoS MIB, better known as CBQoS steps in. SNMP capable monitoring tools can collect information from the CBQoS MIB to report on the pre and post-policy statistics for every QoS policy on a device. CBQoS reports help determine the volume of traffic dropped or queued and confirms that the classifying and marking of traffic is working as expected.

 

Well, that completes the basics of QoS using MQC and implementation ideas for your network. While we talked about QoS configuration using classification and marking in this blog, there are more options such as congestion management, congestion avoidance, and shaping which we have not explored because they can be complex when starting out. If you have got the hang of QoS configuration using MQC, be sure to explore all options for classifying and marking traffic from here before your first QoS implementation.

 

Good luck creating a better network!