can be associated with a single traffic class
using the match any command. The match not
command inverts the specified condition. This command specifies
a match criterion value that prevents packets from being
classified as members of a specified traffic class. All other
values of that particular match criterion belong to the class.
At least one match command should be used within the
class-map configuration mode. The description command is
used for documenting a comment about the class map. There are
many ways to classify traffic when configuring class maps.
Figure shows one possible way to classify traffic using access
control lists (ACLs) to specify the traffic that needs to match
for the QoS policy. Class maps support standard ACLs and
extended ACLs. The match access-group command allows an
ACL to be used as a match criterion for traffic
classification. Example: Traffic Classes Defined
In
the following example, two traffic classes are created and
their match criteria are defined. For the first traffic class
called class1, access control list (ACL) 101 is used as the
match criterion. For the second traffic class called class2,
ACL 102 is used as the match criterion. The router checks the
packets against the contents of these ACLs to determine if they
belong to the class. Router(config)# class-map
class1
Router(config-cmap)# match access-group
101
Router(config-cmap)# exit
Router(config)# class-map class2
Router(config-cmap)# match access-group 102
Router(config-cmap)# exit Example: match not
Command
The match not command is used to
specify a specific QoS policy value that is not used as a match
criterion. When using the match not command, all other
values of that QoS policy become successful match criteria. For
instance, if the match not qos-group 4 command is issued
in class-map configuration mode, the specified class will
accept all QoS group values except 4 as successful match
criteria. In the following traffic class, all protocols except
IP are considered successful match criteria: Router(config)#
class-map noip
Router(config-cmap)# match not
protocol ip
Router(config-cmap)# exit
Content 3.4 Using MQC for Implementing QoS
3.4.5 Step 2: Configuring Policy Maps Figure
describes the concept of a policy map. The policy-map
command creates a traffic policy. The purpose of a traffic
policy is to configure the QoS features that should be
associated with the traffic which are then classified into a
traffic class or classes. You can then assign as much bandwidth
or set whatever priority you need to that class. A traffic
policy contains three elements: a case-sensitive name, a
traffic class (specified with the class command), and
the QoS policies. The policy-map command specifies the
name of a traffic policy (for example, issuing the
policy-map class1 command would create a traffic policy
named class1). After you issue the policy-map command,
you enter policy-map configuration mode. You can then enter the
name of a traffic class. You must be in the policy-map
configuration mode to enter QoS features that apply to the
traffic matching the named class. A packet can match only one
traffic class within a traffic policy. If a packet matches more
than one traffic class in the traffic policy, the first traffic
class defined in the policy is used. On the other hand, the
Cisco MQC does not necessarily require that you associate only
one traffic class to a single traffic policy. When packets
match to more than one match criterion, multiple traffic
classes can be associated with a single traffic policy. The
next topic will explain the concept of nested class maps. You
configure service policies with the policy-map command.
One policy map can have up to 256 classes using the class
command with the name of a preconfigured class map. Figure
shows the policy-map and class command syntax. A
nonexistent class can also be used within the policy-map
configuration mode if the match condition is specified after
the name of the class. The running configuration will reflect
such a configuration by using the match-any strategy and
inserting a full class map configuration. The Configuration
Modes table shows starting and resulting configuration modes
for the class-map, policy-map, and class
commands. Configuration Modes
Staring
Configuration Mode Command Resulting
Configuration Mode Router(config)# class-map
Router(config-cmap)# Router(config)# policy-map
Router(config-pmap)# Router(config-pmap)# class
Router(config-pmap-c)# All traffic not identified in any of the
class maps that are used within the policy map, become part of
the default class “class-default.” This class has no QoS
guarantees by default. The default class, when used on output,
can use one FIFO queue or flow-based WFQ. The default class is
part of every policy map, even if a default class is not
included in the configuration. Example: Traffic Policy
Created
In the following example, a traffic policy
called policy1 is defined to contain policy specifications for
the two classes—class1 and class2. The match criteria for these
classes were defined in the traffic classes. For class1, the
policy includes a bandwidth allocation request and a maximum
packet count limit for the queue reserved for the class. For
class2, the policy specifies only a bandwidth allocation
request. Router(config)# policy-map policy1
Router(config-pmap)# class class1
Router(config-pmap-c)# bandwidth 3000
Router(config-pmap-c)# queue-limit 30
Router(config-pmap)# exit
Router(config-pmap)#
class class2
Router(config-pmap-c)# bandwidth
2000
Router(config-pmap)# exit Example:
Enforcing a Sub-rate
In this example, you need to
enforce a sub-rate (that is, 10 Mbps virtual pipe on a 1 Gbps
link) on a particular link, while offering minimum bandwidth
guarantees to applications such as voice, mission critical
applications, and video within that virtual pipe as follows:
- Voice: 1 Mbps
- Mission critical applications
traffic: 2 Mbps
- Video: 5 Mbps
- Remaining
bandwidth allocated to best-effort traffic within the defined
10 Mbps pipe
Below is the sample configuration.
Router(config)# policy-map CHILD
Router(config-pmap)# class VOICE
Router(config-pmap-c)# priority 1000
Router(config-pmap-c)# class MCA
Router(config-pmap-c)# bandwidth 2000
Router(config-pmap-c)# class VIDEO
Router(config-pmap-c)# bandwidth 5000
Router(config)# policy-map PARENT
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 10000000
Router(config-pmap-c)# service-policy CHILD
Note
If a particular application does not use the
bandwidth, it can be shared among the active applications,
therefore no bandwidth is wasted. Example: Default Traffic
Class Configuration
Unclassified traffic (traffic that
does not meet the match criteria specified in the traffic
classes) is treated as belonging to the default traffic class.
If the user does not configure a default class, packets are
still treated as members of the default class. However, by
default, the default class has no enabled features. Therefore,
packets belonging to a default class with no configured
features have no QoS functionality. These packets are then
placed into a FIFO queue and forwarded at a rate determined by
the available underlying link bandwidth. This FIFO queue is
managed by tail drop. (Tail drop is a means of avoiding
congestion that treats all traffic equally and does not
differentiate between classes of service. Queues fill during
periods of congestion. When the output queue is full and tail
drop is in effect, packets are dropped until the congestion is