Quality of Service on Cisco IOS
 

The two terms 'Quality' and 'Service' can be defined equivocal: Experienced / Expected

We want our customer to experience great service - we do The Traditional Approach: increase bandwidth - do The Flank Maneuver: upgrade some equipment - and finally accept that the fact: Lowered Expectations.

But what are really our customer's expectations?

In my world, customers expect connectivity and bandwidth around the clock. They expect certain bandwidth and low jitter for voice calls. Some want guaranteed bandwidth for video-conferencing traffic. One customer want 50Mbps uplink bandwidth to be available and freely shared between five different sites, but with a certain level of guaranteed bandwidth available to each of the sites.

Being the messenger - we wash our hands for any dirt, aggressive protocols, spam, attacks - you name it we bring it as long as it has a IP header. The traffic patterns seen can be a challenge. Links are frequently congested, UDP times out and TCP's backoff algorithm goes kanakkas - with the result that end-user experience no service - which is A Bad Thing® .

The solution to these issues on Cisco IOS is to use MQC to build class-maps and policy-maps and finally apply the service-policy on the interface. Frequently known as CBWFQ, this is also often a result of our activities in MQC ;) 

The key element is to make a parent-child policy-map structure and traffic-shape in the parent policy-map, while the required traffic classes / PHBs (Per-Hop Behaviors) are defined in the child policy-map.

Here is an example defining two classes, the VOICE class confirming 128kbps traffic to RFC3246, the VIDEO 512kbps to RFC2597 - and finally the default "Best Effort" class. We use Real-Time NBAR payload classification for simplicity:

class-map match-any VOICE

 match protocol rtp audio

class-map match-any VIDEO

 match protocol rtp video

policy-map CHILD

 class VOICE

  priority 128 3200

 class VIDEO

  bandwidth 512

 class class-default

  fair-queue

policy-map PARENT

 class class-default

  shape average 9600000

  service-policy CHILD

interface Serial0

 service-policy output PARENT

Ctrl+z

Now if the Professor Balthazar Machine is working, you get some pretty nifty statistics to tune your setup by issuing:

show policy-map interface

You can play with the whole MQC/CBWFQ shebang for many hours. I have done that. It boils down to the old principle KISS (Keep It Simple Stupid), if you must enable other mechanisms, I suggest random-detect on the default class within the CHILD structure. It drops packets when link is congested and thereby lowers packet loss in other classes.

This scales. For more detail: Cisco Enterprise QoS Solution Reference

 

Check also Cisco Recommended QoS Baseline (129KB pdf)

Eirik Brendholen

Traffic Engineer

Sign in  |  Recent Site Activity  |  Terms  |  Report Abuse  |  Print page  |  Powered by Google Sites