Cisco QoS 2 - Classification and Marking, Modular QoS CLI

Note: Configuration commands and options vary by IOS version (considering newer versions here) and by device (router, switch, category).

Trust Boundary - the boundary of trust, it separates the part of the network where we still trust the transmitted markings (classes) and where we don't, typically the edge switch, we don't trust what the client sends us, but we classify the traffic ourselves, there may be an exception like an IP phone.

Detailed traffic analysis (of the packet) should be performed at the network edge, as much as possible, where we establish the Trust Boundary. Based on the analysis, we categorize the traffic into classes. Other active elements then use this classification for traffic routing. DiffServ operates in a manner referred to as Per-hop behavior, processing at each active element. To achieve a comprehensive QoS solution, all active elements on the path must have the same Per-hop behavior.

Classification

We can distinguish packets based on a number of parameters, some of which are:

• ACL (access control list) using access group - this includes definition based on a number of parameters, primarily IP address or MAC address
• input interface - through which the packet came
• IP parameter - DSCP or Precedence
• protocol - some basic protocols or a range when using NBAR (which is only on better routers or the largest switches)
• all - all traffic
• class-map - according to a nested class map
• trusted Cos, DSCP or IP precedence - accepting the received values

Marking

After classifying the packet into a class, we need to assign this information to it. This is done using marking and there are several options, depending on the protocol/technology used. Here I only mention the more common TCP/IP and Ethernet (and omit other options like ATM, Frame Relay, MPLS).

Class of Service (CoS) field in OSI Layer 2

CoS is a priority bit according to IEEE 802.1p within the IEEE 802.1q Ethernet frame (extended frame header by 4 bytes), size 3 bits, taking values ​​0 to 7.

802.1q frame

Structure of 802.1q tag

Type of Service (ToS) field in OSI Layer 3

The ToS field is inside the IP header and is 8 bits long, inside it is the value of the Differentiated Services Code Point (DSCP) 6 bits and thus values ​​0 to 63, inside it is the IP Precedence (IPP) of 3 bits (values ​​0 to 7). Originally, IP Precedence was used, for DiffServ it was extended to DSCP, which is backward compatible with IP Precedence.

IP header

ToS field

CoS, IP Precedence, DSCP Values

Per-Hop Behaviors - PHB

PHB is a term used in DiffServ that defines the policies and priorities applied to a packet as it passes through a router (hop). The standard PHBs are:

• Expedited Forwarding - EF - fast (prioritized) transmission, ideal for small bandwidth but low latency
• Assured Forwarding - AF - assured transmission, has reserved bandwidth, often divided into gold, silver, and bronze
• Class Selector - CS - compatible with IP Precedence
• Best Effort - BE - default, worst

PHB is defined in several RFCs, but in reality it is just a recommendation. Everything depends on how we configure it on the active elements. The mentioned classes do not automatically exist, so if we mark the traffic to a recommended value, nothing will happen yet, we need to set the behavior of the given class.

The following table shows the recommended values ​​of IP Precedence (IPP) and the corresponding PHB classes along with the DSCP value. The size of DSCP is 6 bits, the first 3 bits correspond to IP Precedence. The higher the IP Precedence number, the higher the priority. For PHB AF, this number is added to the name (and also forms CS). The next two bits determine the drop probability, the higher the number, the more likely it is to be dropped (AFx1 - low drop preference, AFx2 med drop preference, AFx3 high drop preference), and they are also added to the PHB EF name. The last bit is 0.

Configuration in Cisco IOS - MQC

Nowadays, the Modular Quality of Service Command Line Interface (Modular QoS CLI or just MQC) is used for configuring QoS under Cisco IOS (regardless of whether on a router or switch, although the detailed options differ). We always work with classes (in which we classify traffic), so it is called Class-based QoS.

Using MQC, more activities are performed than just classification and marking, and the same commands are used for everything, so I will also indicate other options that will be described in more detail next time. The following mechanisms can be used in MQC:

• Marking - marking packets, applicable to input/output, set command
• Shaping - limiting traffic with delay (distribution), applicable to output, shape command
• Policing - limiting traffic by dropping packets, applicable to input/output, police command
• Weighted fair queuing (CBWFQ) - queues for bandwidth reservation (guarantee), applicable to output, bandwidth command
• Low-latency queuing (CBLLQ) - queues for bandwidth reservation (guarantee) and ensuring low latency, applicable to output, priority command
• Weighted random early detection (WRED) - queues for bandwidth reservation (guarantee) with intelligent packet dropping, random-detect command

The configuration in MQC consists of three steps:

• Traffic class definition - I determine what traffic I want to work with, I create a class-map
• Policy definition - I determine what I want to do with the selected traffic, I create a policy-map and include one or more class-maps in it
• Policy application - I apply the policy to an interface, that's when it starts working, using service-policy

Traffic class definition

We create a named class into which (or using which) we will select traffic. Inside the class, we select traffic using the match command, which can be used once or multiple times. In the class definition, we can specify whether multiple match commands should use logical AND or logical OR, using the match-all or match-any parameter.

ROUTER(config)#class-map test-class            // definition of class-map named test-class, match-all is used by default
ROUTER(config)#class-map match-all test-class  // same as above
ROUTER(config)#class-map match-any test-class  // at least one match must apply

We can select traffic based on a number of parameters (see above), depending on the device type and what it supports.

ROUTER(config-cmap)#match any                    // select everything, doesn't work for all applications
ROUTER(config-cmap)#match access-group 10        // what ACL number 10 evaluates
ROUTER(config-cmap)#match ip precedence critical // what has IP Precedence = 5 set
ROUTER(config-cmap)#match vlan 100 - 105         // VLAN 100 to 105
ROUTER(config-cmap)#match destination-address mac 00-16-EA-E4-D0-96 // destination MAC address
ROUTER(config-cmap)#match input-interface fa1    // what came through interface fa1
ROUTER(config-cmap)#match protocol ip            // by protocol

An interesting option is to use the match not command, which selects based on all other values of the given criterion except the specified values.

ROUTER(config-cmap)#match not protocol ip  // all protocols except IP

We can also nest class-maps for more complex selections

ROUTER(config)#class-map match-any test-class 
ROUTER(config-cmap)#match class-map test-class-1 
ROUTER(config-cmap)#match class-map test-class-2

Classification using ACL

ACL (Access Control List) is often used to find interesting traffic. We can use standard IP ACL, extended IP ACL or L2 MAC ACL. More about creating ACLs in the article Cisco IOS 8 - ACL - Access Control List.

It's important to know how ACLs are evaluated when assigned to a class-map. The following rules are used:

• if a match with a permit action is found, the assigned QoS action is used
• if a match with a deny action is found, the ACL is skipped and the next one is continued
• if no permit rule is found, QoS is not processed and Best-Effort is used
• if multiple ACLs are defined, the search stops after the first permit match

Policy definition

In the first step, we selected which traffic we're interested in, and now we need to determine what we'll do with it. There are many options, and in this step, we actually apply all the QoS possibilities. We can mark traffic, perform marking, (set IP precedence, DSCP, etc.) or work directly with traffic, limit or reserve bandwidth for traffic, handle queues, etc.

We create a named policy called test-policy.

ROUTER(config)#policy-map test-policy 

Next, we determine which class-map our settings will apply to. We can include multiple class-maps in one policy-map and set different behaviors for them. This is necessary because we can only apply one policy-map per interface and direction.

ROUTER(config-pmap)#class test-class  

Within the class-map, we already determine the given policy, it can be multiple settings.

ROUTER(config-pmap-c)#set cos 3         // mark traffic as COS 3
ROUTER(config-pmap-c)#set precedence 3  // mark traffic as IPP 3
ROUTER(config-pmap-c)#set dscp 24       // mark traffic as DSCP 24
ROUTER(config-pmap-c)#police 128000 8000 exceed-action drop // traffic limitation
ROUTER(config-pmap-c)#police aggregate test-policer // traffic limitation using pre-created policy
ROUTER(config-pmap-c)#shape average 512000 // traffic shaping
ROUTER(config-pmap-c)#priority 16000    // prioritization and bandwidth allocation in kbps
ROUTER(config-pmap-c)#bandwidth 1024    // bandwidth allocation in kbps
ROUTER(config-pmap-c)#log               // logging

All other traffic that we didn't include in any class is automatically assigned to the default class, to which QoS is not applied - Best-effort is used. This class is called class-default and we can change its behavior.

ROUTER(config)#policy-map test-policy 
ROUTER(config-pmap)#class class-default    
ROUTER(config-pmap-c)#queue-limit 10    // queue size of 10 packets

Policy application

Creating a policy-map doesn't mean it will start working. First, it needs to be mapped to an interface within which it will be executed. And also determine whether it applies to incoming or outgoing packets (similar to ACL).

ROUTER(config)#interface gigabitEthernet1/0/1       // select interface
ROUTER(config-if)#service-policy input test-policy  // apply policy map named test-policy to incoming packets

We can also create hierarchical policies by applying one policy inside another policy under a class.

ROUTER(config)#policy-map test-policy 
ROUTER(config-pmap)#class test-class  
ROUTER(config-pmap-c)#police 512000 
ROUTER(config-pmap-c)#service-policy test-inner-policy  // apply policy within a policy

Show commands - verification

To verify our settings, we can use the following show commands:

ROUTER#show running-config    // we'll find the entered commands in the running configuration
ROUTER#show class-map         // displays all defined class-maps
ROUTER#show class-map class1  // displays class-map class1
ROUTER#show policy-map        // displays all defined policy-maps (doesn't show individual commands)
ROUTER#show policy-map policy1 class class1 // displays configuration of specified class in given policy-map
ROUTER#show policy-map interface s0/0  // displays statistics on how the policy is applied to the interface