A policy-map is how you specify what actions should apply to each class of traffic you create.
Let’s re-examine the simple example above:
policy-map simple-example
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
The policy-map name is simple-example – this is the name we use when we subsequently attach the policy to one or more interfaces. The policy itself is quite readable
– we have defined two classes of traffic: voice and video. Voice traffic should receive priority (low latency) scheduling
but throughput of that class is limited to 10% of the interface bandwidth. For video traffic, we have a dedicated queue and
a guarantee of 30% of what remains after voice is serviced.
The above policy-map has a 3rd implicit class; class-default is the last class in a policy, whether explicitly configured
or not. It is a catch-all into which falls any traffic that does not match one of the user-defined classes. In egress policies
class-default will have its own queue and an implicit bandwidth remaining ratio of 1. If bandwidth values are specified in
percentage, class-default will receive any unassigned percent (see asterisks). Knowing this the above policy-map would actually
look as follows:
class-map class-default
match any
!
policy-map simple-example
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
class class-default
bandwidth remaining percent 70 ****
Note
|
You never need to create a class-map for class-default. We visualize it here to provide a better understanding of how the
policy works. If a packet does not match the voice class or the video class it will always match class-default.
|
Examples of actions in the policy above include the priority , police , and bandwidth commands. Actions function as control knobs to differentiate how one class of traffic will be treated vs. another.
One very important differentiation when looking at actions is queuing vs. non-queuing. What if we now add one more class to
the simple-example policy-map:
class-map youtube
match protocol youtube
!
policy-map simple-example
class voice
priority
police cir percent 10
class youtube
police cir percent 5
class video
bandwidth remaining percent 30
We have added a third user-defined class named youtube that is rate-limiting YouTube traffic such that it can never exceed 5% of link capacity. As this class has no queuing action
configured, no queue is created (see below the list of actions that create a queue). Packets that match this class (those
with protocol youtube) will traverse the policer and then be enqueued in the class-default queue.
Did you notice that we placed the youtube class before the video class in our policy definition? We want to ensure that youtube traffic is always part of this class rather than our video class.
By defining this class earlier in the policy-map we will check for a match to this class before we check the video class criteria.
The specific actions that will create a queue are priority, bandwidth, bandwidth remaining and shape. Other actions like fair-queue, queue-limit and random-detect
may only be used in a class already containing one of the actions that creates a queue. The actions police and set will not create a queue, although you can use the police command for queue admission control.
One key reason to differentiate between queuing actions and non-queuing actions is that a policy-map that will be applied
to ingress traffic may not contain any queuing actions on the ASR 1000 Series Router. Let's summarize which actions are queuing
and which are not:
Queuing and Non-Queuing Actions
|
|
Action
|
Queuing Actions
|
|
|
|
Scheduling
|
|
|
|
priority
|
|
|
bandwidth
|
|
|
bandwidth remaining
|
|
|
shape
|
|
|
fair-queue
|
|
Queue Management / Congestion Avoidance
|
|
|
|
queue-limit
|
|
|
random-detect
|
Non-Queuing Actions
|
|
|
|
Rate-Limiting / Admission Control
|
|
|
|
police
|
|
Marking
|
|
|
|
set
|
Hierarchical policy-maps
can be created by embedding a policy-map within a class of another policy-map:
policy-map child
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
!
policy-map parent-vlan
class class-default
shape average 100m
service-policy child
A common use is to create a shape on parent / queue on child policy that can be attached to a logical interface such as a VLAN or a tunnel.
From a classification perspective, a packet must adhere to the classification criteria of the child as well as the parent
class to be considered a member of a particular child class. In this example the parent class is class-default and by definition
any traffic will match this class.
When defining hierarchical polices we can re-use policy-maps for convenience.
In the following example, we use the policy-map named child in both parent-vlan100 and parent-vlan200. When instantiated
(attached to an interface) the voice class in parent-vlan100 will be limited to 10 Mbps (10% of 100m parent shaper) while the voice class in parent-vlan200
will be limited to 5 Mbps (10% of 50m parent shaper):
policy-map child
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
!
policy-map parent-vlan100
class class-default
shape average 100m
service-policy child
!
policy-map parent-vlan200
class class-default
shape average 50m
service-policy child
!
int gigabitethernet1/0/0.100
service-policy out parent-vlan100
int gigabitethernet1/0/0.200
service-policy out parent-vlan200
This example shows that although the definition may be shared the instances of the policy on different interfaces are truly
unique.
You can also create hierarchical policies with policy-maps used in user-defined classes.
The following example illustrates a 3-level hierarchical policy, the max currently supported on the ASR 1000 Series Router.
For a packet to match a class at the application level it must now match 3 requirements: the voice or video classifier at
the child, the vlan classifier in the vlan-sharing policy-map, and the class-default (anything) in the physical level policy-map:
class-map vlan100
match vlan 100
class-map vlan200
match vlan 200
!
policy-map child
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
!
policy-map vlan-sharing
class vlan100
shape average 100m
service-policy child
class vlan200
shape average 50m
service-policy child
!
policy-map physical-policy
class class-default
shape average 500m
service-policy vlan-sharing
!
interface gigabitethernet1/0/0
service-policy out physical-policy
When you create a policy-map, IOS will perform some error checking on the policy. For example, if I create a policy with an
unconstrained priority queue and then guarantee bandwidth to another queue, IOS will recognize the disconnect; if the unconstrained
priority queue can comsume the entire interface bandwidth then clearly you cannot guarantee any of that bandwidth to another
queue:
policy-map create-error-example
class unconstrained-priority
priority
class bandwidth-guarantee
bandwidth percent 50
If IOS detects an error in the policy during creation, it will reject the configuration and display an error at that time.