QOS

You are currently browsing articles tagged QOS.

Before I started my QOS studies I had always had a trouble distinguishing between policing and shaping.  I generally knew what they were, but I didn’t know when to use them or how they worked.  Lets give a brief definition of both and I’ll follow up with a configuration example of both in the next two posts.

Policing
Policing to me, was the easier of the two.  The Cisco Press book used the analogy of a policeman enforcing the law.  With Policing, you can ‘police’ the traffic to a certain rate.  Basically you are setting a hard limit and saying if you go above this, the policer will take action.  There are generally two things a policer can do with the traffic once it goes over the defined limit.  The policer can drop the traffic or ‘mark down’ or retag the traffic with a lower priority.  Policing can be done on egress or ingress traffic.

Shaping
Shaping was the topic I always had a issue with.  Shaping allows you to ‘shape’ the traffic to a particular speed.  If too much traffic is arriving at an interface the traffic can be shaped to an allowed rate with excess traffic being queued.  Shaping can only be used on egress traffic which makes sense.

Summary
Policing is pretty straight forward.  If interface X goes over limit Y drop the traffic or mark it down.  Shaping on the other hand, can be a lot more complicated especially when you start talking about the details.

Tags:

I used MQC in an earlier blog post about NBAR but I didn’t spend much time talking about it.  In this post, we’ll discuss MQC in greater detail.

Cisco MQC is a three tiered system of applying QOS policy.  It looks something like this…

Class Map – Defines particular types of traffic
Policy Map – Defines what to do with traffic defined my a Class Map
Service Policy – Defines the Policy Map on a particular interface in a particular direction

So as you can see, the three configuration items build on each other.  The easiest way to explain it is to see a configuration example.  So let’s walk through the RTP example I used in the previous post about NBAR.

Class Maps
Classifying traffic is done through the use of class maps.  Class maps can match traffic based on several different features.  Let’s take a look at our options for classifying traffic.

access-group             Access group
any                            Any packets
class-map                  Class map
cos                             IEEE 802.1Q/ISL class of service
destination-address  Destination address
discard-class              Discard behavior identifier
dscp                           Match DSCP in IP(v4) and IPv6 packets
flow                            Flow based QoS parameters
fr-de                           Match on Frame-relay DE bit
fr-dlci                          Match on fr-dlci
input-interface           Select an input interface to match
ip                               IP specific values
mpls                           Multi Protocol Label Switching specific values
not                             Negate this match result
packet                        Layer 3 Packet length
precedence                Match Precedence in IP(v4) and IPv6 packets
protocol                      Protocol
qos-group                  Qos-group
source-address          Source address
vlan                            VLANs to match

So as you can see, there are a multitude of ways to classify the traffic.  Since we used NBAR last time, let’s try classifying using the access-group command.

Cisco1841(config)#class-map CM-VOIPTRAFFIC
Cisco1841(config-cmap)#
match access-group name ACL-VOIPTRAFFIC
Cisco1841#show class-map VOIPTRAFFIC
Class Map match-all CM-VOIPTRAFFIC (id 1)
   Match access-group name ACL-VOIPTRAFFIC
Cisco1841(config)#
ip access-list standard ACL-VOIPTRAFFIC
Cisco1841(config-std-nacl)#deny host 10.20.20.1
Cisco1841(config-std-nacl)#deny host 10.20.20.2
Cisco1841(config-std-nacl)#permit 10.20.20.0 0.0.0.255
Cisco1841(config-std-nacl)#end
Cisco1841#show ip access-list ACL-VOIPTRAFFIC
Standard IP access list ACL-VOIPTRAFFIC
    20 deny   10.20.20.2
    10 deny   10.20.20.1
    30 permit 0.0.0.0, wildcard bits 255.255.255.0

In the above example we configured the class-map to match traffic from the ACL ACL-VOIPTRAFFIC.  Remember, the default behavior for a class is to ‘match all’ unless defined explicitly to ‘match any’.  Since we only have one match command it doesn’t matter in this instance.

Policy Maps
Policy maps allow you to define a policy for traffic classified with class maps.  The options for what to do with the traffic are many…

bandwidth                 Bandwidth
compression              Activate Compression
drop                          Drop all packets
exit                            Exit from class action configuration mode
fair-queue                 Enable Flow-based Fair Queuing in this Class
log                             Log IPv4 and ARP packets
netflow-sampler        NetFlow action
no                             Negate or set default values of a command
police                        Police
priority                      Strict Scheduling Priority for this Class
queue-limit               Queue Max Threshold for Tail Drop
random-detect          Enable Random Early Detection as drop policy
service-policy            Configure QoS Service Policy
set                            Set QoS values
shape                       Traffic Shaping

So in the spirit of making sure we match our traffic, let’s use the ‘drop’ option.

Cisco1841(config)#policy-map PM-VOIPTRAFFIC
Cisco1841(config-pmap)#class CM-VOIPTRAFFIC
Cisco1841(config-pmap-c)#drop
Cisco1841(config-pmap-c)#end
Cisco1841#show policy-map PM-VOIPTRAFFIC
  Policy Map PM-VOIPTRAFFIC
    Class CM-VOIPTRAFFIC
      drop

Service Policies
So at this point, we’ve classified our traffic by using an ACL, matched that traffic to a policy, told that policy to drop the traffic.  The last piece is to use a service policy to bind that policy to an interface.  The only real considerations here are the interface and the direction of the traffic flow.  Keep in mind the following rules when designing the QOS policies that you can only define one service per policy per interface, per direction.  That is, a single interface can have an in and out policy.  So let’s put this on our interface and see what happens.

Cisco1841(config)# interface Vlan1
Cisco1841(config-if)#service-policy input PM-VOIPTRAFFIC

The instant I pressed ‘ENTER’ on the last command my active VOIP calls dropped and my VOIP phone went into the registering state.  A look at my policy map shows active matches…

Cisco1841#show policy-map interface vlan 1
Vlan1
  Service-policy input: PM-VOIPTRAFFIC
   Class-map: CM-VOIPTRAFFIC (match-all)
      2908 packets, 609450 bytes
      5 minute offered rate 8000 bps, drop rate 8000 bps
      Match: access-group name ACL-VOIPTRAFFIC
      drop

My ACL used in the class-map also shows hits…

Cisco1841#show ip access-list ACL-VOIPTRAFFIC
Standard IP access list ACL-VOIPTRAFFIC
    10 deny   192.168.127.1
    20 permit 192.168.127.0, wildcard bits 0.0.0.255 (2996 matches)

Conclusion
The more you play around with MQC the easier it becomes.  In my mind, it’s a ingenious system with a easy to follow flow.

Tags:

I’ve been working on memorizing this since I started QOS studies.  While its certainly not the first one out of the web, I typed it up and posted it to help me remember. 

image

Tags:

« Older entries