Class in Session: Cisco

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
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.

Policy Maps
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:

1. A case sensitive name
2. A traffic class specified in the class command
3. 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.

Example 1
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

Example 2
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:

1. The set command is not supported on the child policy
2. The priority command can be used in either the parent or the child policy, but not both policies simultaneously
3. The fair=queue command cannot be defined in the parent policy

Example 3

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

References

• 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)