Complex QoS matching policies.

This article assumes you know the basics about Cisco Quality of Service. If not, have patience, I will be covering it in due course and all articles will have their own labels.


In this post I want to cover some more complicated policies in the labelling side of QoS. In most of the policies we utilise in our office we run the same rough architecture as the device are CPE/Network edge devices.

We use the inbound traffic stream on the LAN port for identifying and labelling traffic and the WAN outbound stream for queuing and shaping the traffic.

The shaping I will cover next time out but for this instance we will cover the labelling. There are some important things you can use that you might not immediately think of when setting up policies. Although in this instance we had the customer pre-label, we could have also gone with :

policy-map match-all LABEL-AF31
match access-group LAN priority
match not protocol sip
match not ip rtp audio

policy-map match-any LABEL-EF
match protocol sip
match ip rtp audio

with the relevant labelling policy map,which would allow all the normal traffic to go out as one class and the VOIP as another.



Most common policies label by the following :

Protocol
Access List
DSCP tag
Source VLAN
etc.......


There are some circumstances where you can pile a lot of general criteria together via the "match any" type of class map to ensure your traffic hits if you are not sure what ports etc you are using

i.e.

class-map match-all VOICE
match protocol h323
match ip rtp audio
match access-group VOICE

combined with
ip access-list extended VOICE
10 match (phone source range) any
20 match any (VOIP SERVER IP)

this would allow any one of the above criteria to cause the class-map to flag traffic for action based on its policy map on any of the above criteria.

Note it will match the first in the list it flags on. It is possible to put the same criteria in more than one class map or similar criteria so remember the router will work top-down and match the first criteria it finds so with any overlap etc you could end up with traffic in the wrong class if you are not careful.


The real power comes in with a combination of "match-all" and negate statements.

In an example from real life, recently I was working with a customer who has an Ethernet service with multiple networks behind it for different offices in the building.

The issue is they want to ensure as they pay for the circuit, that their portion of the bandwidth is not only guaranteed but prioritised. However they also want any one network to have the ability to utilise/burst up to the bandwidth available on the circuit which rules out or makes very complicated using Burst/Police/Shape statements.

We got around this by utilising QoS to give each source network a label and a shape statement to give the main source a priority but through the features of QoS it would allow bursting above if required.

The issue then occured that one of the companies wanted to run a VOIP network with proper QoS to ensure the phonecalls.

We have a couple of options. We can't run multiple policies on the line as you can only run one QoS policy per line/router.

Rather than create complex parent/child policies, we actioned the below. By asking the customer to pre-label all their traffic with the EF/DSCP46 tag, we then applied the below policy.


class-map match-all LABEL-AF31
match access-group LANPRIORITY
match not ip dscp EF

class-map SHAPE-EF
match ip dscp ef

class-map SHAPE-AF31
match ip dscp af31

policy-map LABEL
class LABEL-AF31
set ip dscp af31

Policy-map SHAPE
class SHAPE-EF
priority 1024
class SHAPE-AF31
bandwidth 2048
random-detect dscp-based.


What this effectively does is forces the labelling function to take into account additional criteria when creating a match. Because the Match-all flag is live you have to match all the listed criteria to get the result, unlike the Match-Any flag which allows any of the sub criteria to score.

Initially we were marking all traffic based on source IP to ensure all traffic from the priority LAN was guaranteed but with the introduction of the voice LAN within it, even if the phones were labelling the traffic they would be overwritten due to the source identity.

By adding the negate statement, we ensured only traffic from the source LAN that was NOT already marked EF to be labelled AF31 and all the remaining EF traffic would pass untouched, to be queued independently in its own priority queue.

This is one of many examples of tailoring a policy to meet your needs. I'll post further pertinent examples as I get them.