In part five of this blog series we discussed that classification is considered to be the traffic that is important or grouping the traffic into groups based on the type of traffic. In this part of the series we’ll explore policy maps and how they impact what will be done to the traffic after it has been classified.
Marking is related to classification and allows network devices to classify a packet or frame based on a specific traffic descriptor. Some traffic descriptors include CoS, DSCP, IP precedence, QoS group, and MPLS. Marking can take place at Layer 2 or Layer 3.
Marking a packet or frame with its classification allows network devices to easily distinguish the marked packet or frame as belonging to a specific class.
Link layer media often changes as a packet travels from its source to its destination. Because a CoS field does not exist in a standard Ethernet frame, CoS markings at the link layer are not preserved as packets traverse non-trunked or non-Ethernet networks. Using Marking at the network layer provides a more permanent marker that is preserved from source to destination. Some edge devices only mark frames at the data link layer making it necessary for there to be a way to map QoS marking between the data link layer and the network layer.
A policy map matches the classes from the class map with how much bandwidth and/or priority has been assigned to this traffic. A policy map contains three elements:
- A case sensitive name
- A traffic class specified in the class command
- And the QoS policies
All traffic that is not classified by any of the class maps is considered to be part of the class default. The class default is part of every policy map, even if not configured.
In the following example, the Modular QoS CLI (MQC) Three-Level Hierarchical Policer has been configured for three classes within three separate policy maps. The three classes, called “c1,” “c2,” and “c3,” respectively, have been configured using the match criteria specified as follows:
class-map c1 match any class-map c2 match ip precedence 1 2 3 class-map c3 match ip precedence 2
Next, the classes are configured in three separate policy maps, called p_all (the primary-level policy map), pmatch_123 (the secondary-level policy map), and pmatch_2 (the tertiary-level policy map), as shown below.
policy p_all class c1 police 100000 service-policy pmatch_123 policy pmatch_123 class c2 police 20000 service-policy pmatch_2 policy pmatch_2 class c3 police 8000
The primary goal of this configuration is to limit all traffic to 100 kbps. Within the primary goal, the secondary goal is make sure packets with precedence values of 1, 2, or 3 do not exceed 20 kbps and that packets with precedence value of 2 never exceed 8 kbps.
To verify that the classes have been configured correctly and to confirm the results of the traffic policing configuration in the policy maps, use the show policy-map command. The following sample output of the show policy-map command verifies the configuration of the classes in the policy maps:
Router# show policy map Policy Map p_all Class c1 police cir 100000 bc 3000 conform-action transmit exceed-action drop service-policy pmatch_123 Policy Map pmatch_123 Class c2 police cir 20000 bc 1500 conform-action transmit exceed-action drop service-policy pmatch_2 Policy Map pmatch_2 Class c3 police cir 8000 bc 1500 conform-action transmit exceed-action drop
In this example the first two classes were separately configured using the class-map command. The third class was configured by specifying the match condition after the names in the class.
Class-map match –all Test1 Match protocol http Match access-group 100 Class-map match-amy Test 2 Match protocol http Match access-group 101 Policy-map Test Class Test1 Bandwidth 100 Class Test2 Bandwidth 200 Class Test3 access-group 100 Bandwidth 100 Access-list 100 permit tcp any host 10.1.1.1 Access-list 101 permit tcp any host 10.1.1.2
Service Policy Map
The purpose of the service-policy map is to attach service policies to interfaces. The service policy map is used to create hierarchical service policies in the policy map class configuration mod.
The service-policy command has the following restrictions:
- The set command is not supported on the child policy
- The priority command can be used in either the parent or the child policy, but not both policies simultaneously
- The fair=queue command cannot be defined in the parent policy
In this example all traffic on FA0/0 is set to 2Mbps, and the HTTP traffic is guaranteed 1Mbps to HTTP traffic
(Parent) Class-map AllTraffic Match any Policy-map ShapeAll Class AllTraffic Shape 2000000 Service-policy QueueAll Interface FastEthernet0/0 Service=policy output ShapeAll (Child) Class-Map HTTP Match protocol http Policy-map QueueAll Class HTTP Bandwidth 1000
In the next part of this series on QoS, the third part of MQC setup will be discussed. The Service Policy identifies where this policy will be implemented.
Author: Paul Stryer
- Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
- End-To-End QoS network Design by Tim Szigeti and Christina Hattingh – ISBN # 1-58705-176-1
- DiffServ – The Scalable End-To-End QoS Model
- Integrated Services Architecture
- Definition of the Differentiated Services Field
- An Architecture for Differentiated Services
- Requirements for IP Version 4 Routers
- An Expedited Forwarding PHB (Per-Hop Behavior)