Archives for category: QOS

It’s worth making some notes on this subject to clear up a few misconceptions I found online.

Firstly I setup a lab to confirm what i’m about to say, the reason we use this command is to allow QoS to correctly classify or view the packets based on the original header, if the packet is encapsulated  it’s  treated the same as any other encapsulated packet. The original header and its QoS value is now unknown to the forwarding device.

So by enabling this command we can apply the classification before the encapsulation or tunneling happens.

Apply the command “qos pre-classify” to a tunnel interface, a crypto-map or a virtual tunnel interface.

Classification based on layer3 and layer4 information is the exact reason we would consider using this feature, classification based on TOS or DSCP values do not need to use this feature, that’s because of TOS byte preservation inherently built into IPSEC.

Once you’ve added the pre-classify command, apply a service-policy to the physical interface outbound, then all IP packets will be classified pre-encapsulation on any tunnels egressing that physical interface. In other words you will see hits on the policy-map individual classes.

A really great resource I found online is this QoS values calculator check it out………….


The last item on our list is the service-policy, this is the part where we apply our policy-map to an interface and specify the direction for the policy.

To help you visualise how the command is used and which direction see the picture below.


QOS is being applied to traffic coming from inside our network going outbound to the WAN.

Your interface will look something like this.

interface FastEthernet0/0
 description WAN_interface
 bandwidth 20000
 ip address
 ip nbar protocol-discovery
 service-policy output QOS_Egress

To confirm the QOS is working you would use the command “show policy-map interface fastethernet 0/0” this will give you a whole bunch of information, see below for an example of how this might look.

Service-policy output: QOS_Egress

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 331150787/112001702019

Class-map: voice_traffic (match-all)
266055005 packets, 57655712122 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Priority: 7% (1400 kbps), burst bytes 35000, b/w exceed drops: 0
QoS Set
dscp ef
Packets marked 266055059

Class-map: voip_signal (match-any)
78149834 packets, 7487646866 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:  dscp cs3 (24) af31 (26)
78149834 packets, 7487646866 bytes
5 minute rate 0 bps
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 78149832/7487645664
bandwidth 3% (600 kbps)
QoS Set
dscp af31
Packets marked 78149834

Class-map: class-default (match-any)
9073254895 packets, 3302249852254 bytes
5 minute offered rate 998000 bps, drop rate 0 bps
Match: any
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/16751970/0
(pkts output/bytes output) 569664615/3424829483864
QoS Set
dscp default
Packets marked 9071570170
shape (average) cir 16000000, bc 160000, be 160000
target shape rate 16000000

As you can see it gives lots of information on how your QOS is performing, the default-class shows some drops that means its had to drop some packets when the link was congested and in fact means your QOS policy is doing its job if the drops were excessive you would increase the values or decrease whichever suits your network.

If you just want to view an indivdual class then you would use the command “show policy-map interface fastethernet 0/0 output class web_traffic” for example.

When using the “service-policy input QOS_Egress” you will receive an error stating that you cannot apply this to the interface, this is becuase CBWFQ is a mechanism for traffic queuing in the outbound direction, never for the inbound direction.

I hope my 3 part blog has gone some way to helping you understand QOS.


My last blog covered class-map’s, which were used to identify traffic to our device, the next part of QOS covers what the device does with the traffic after its been identified. This is called a policy-map.

So you create your policy with the following command

R1#conf t
R1#(config)policy-map QOS_Egress

Next you need to reference each class-map then tell the device what to do with that traffic. Here’s an example

class voice_traffic
priority percent 7
set ip dscp ef
class voip_signal
bandwidth percent 3
set ip dscp af31
class SQL_App
bandwidth 20000
set ip dscp 26
class telnet_traffic
bandwidth percent 3
set ip dscp af21
class citrix_traffic
bandwidth percent 10
set ip dscp af41
class my_desktop
bandwidth percent 40
set ip dscp 18
class web_traffic
police rate percent 15
set ip dscp 10
class class-default
set ip dscp default
shape average percent 80

I’ve used some different actions on my policy map, “priority” and “bandwidth” are worth some discussion.

The idea with priority is just as it sounds, that’s your most important traffic class hence why it’s used for voice, so in my policy-map I’ve reserved 7% bandwidth, on a 20mbps circuit that would mean when the link is saturated, any voice traffic upto 1400kbps would be given priority over all other traffic. The difference that priority has over bandwidth is built-in policer, provides low latency, manages delay and jitter.

For your environment you may need more or less than 7% depending on what codecs you use between your IP phones.

Bandwidth defines the minimum bandwidth guarantee to that class, this can be specified in percentage of the interface bandwidth or in kbps. With CBWFQ the excess bandwidth is divided up amongst the remaining classes if it’s not already being used by the default-class.

Traffic shaping can be applied to the default-class as a way of ensuring your link is never fully utilized by unimportant traffic, what it does in this case is only ever allows maximum outbound traffic for the default-class to reach 80% of the interface rate.

Police means the maximum rate that is always applied to that class, the difference between police and shape is that police will drop packets and shape will buffer them, policing the traffic is alot more complicated than what I’ve explained, this is just simple terms.

DSCP values are set on my policy-map for  inbound traffic to my WAN, so in advance I would speak with my WAN provider and break up all the different DSCP values into classes like gold, silver, bronze then once the WAN provider receives a layer 3 packet with a DSCP value assigned it can decide how to process the packet when the link is congested.

There are lots of variations you can use with policy-maps, you can use nested policy-maps aswell, but this is just a brief overview of what you can achieve with QOS.

Remember you need to have end to end QOS, that means determining trust boundaries. For example from IP phone to IP Phone would be end to end QOS, if you don’t mark the packets coming from your IP Phone then the router will classify them as default traffic, by default your IP phone will send voice traffic marked as EF, You need to connect it to a switchport that at the very least has the command “trust cos


Quality Of Service is one of my favourite subjects the more I learn about it, the more I realise what i don’t know!

So the idea with QOS is you can classify different types of traffic using a class-map, then you can create a policy-map and specify what to do with that traffic, Next you apply the service-policy to an interface either inbound or outbound.

QOS really comes into its own in a  VoIP system, when your WAN link bandwidth is saturated you need to make sure that your VoIP traffic skips to the front of the queue giving the user the clear and uninterrupted call they expect. Remember that QOS only works when its deployed end to end.

My assumption here is you know what DSCP values are.

So lets look at a class-map this is the first part of our configuration, what a class-map does is identify traffic to your router, traffic can be identified at layer 3, layer 4 or layer 7.

This class-map matches DSCP EF (expedited forwarding) which is what voice traffic is marked, this is the most important and should be given top priority. I’ve included is voice_signal traffic which is marked as cs3 or af31, next matches applications, this is used in conjunction with NBAR, below we’ve matched some well known ones SQL, Telnet & Citrix. I’ve thrown in a class-map that can match ip address’s specified in access-list 10 and an extended access-list for matching tcp traffic.

Your router will parse each line sequentially, this is the same with your policy-map.

class-map match-all voice_traffic
 match ip dscp ef
class-map match-any voip_signal
 match ip dscp cs3 af31
class-map match-any SQL_App
match protocol sqlserver
class-map match-all telnet_traffic
  match protocol telnet
class-map match-all citrix_traffic
  match protocol citrix
class-map match-any my_desktop
 match ip access-group 10
class-map match any web_traffic
 match ip access-group 101
access-list 10 permit  
access-list 101 permit tcp any any eq www

Now you have your class-map your router can now identify traffic that passes through it.

So part 1 of this blog has covered identifying traffic to your router next we will cover policy-maps which decide what the router does with the traffic, so the class-map identifies the traffic and the policy-map defines the action for that traffic.

See you soon for my next part!