Home » QoS » QoS Classification and Marking Tools.

QoS Classification and Marking Tools.

This is the first step in implementing QoS. Classification and Marking is the tool-set which will enable us to identify the traffic which is to be treated differently.
Both Classification and Marking are two different actions that work together to identify and differentiate the traffic, though both of these actions can also be used independently.

Why Classification Tools:
1.Classification tools sort packets into different traffic types, to which different policies can be applied.
2.Classification of packets can occur at each node in the network, though not required.
3.Classification of packets can happen independently, that is without marking.

Why Marking Tools:
1.Marking is done to establish trust boundary.
2.Marking can be done on packets which are already marked (Re-marking), if the existing marking on the packets is not trusted.
3.Trust-Boundary is the network-edge where markings are either accepted or rejected.
4.Marking can be independent of Classification as in marking is not always used solely for the purposes of classification.

What are Classifiers:
Tools used for Classifying traffic are called as Classifiers.
Classifiers normally inspect one or more fields in a packet and identify the type of traffic the packet is carrying. Once the traffic is identified it is then directed to the appropriate policy enforcement engine where it receives treatment as per the predefined actions.
Depending on the policy, treatment the traffic receives may include marking and re-marking,queuing, policing, shaping, or any combination of these actions.

What are Markers:
Tools used for marking and re-marking packets are called as Markers.
Markers normally write a field within a packet, frame or label to preserve the classification decision that was reached at the trust-boundary. Once the packets are marked at the trust-boundary, the remaining nodes within do not have to perform the same in-depth classification and analysis to determine how to treat the traffic type.

How Classification Tools Work:

Classification tools work by examining the following criteria (below) to identify a flow, once identification is complete the traffic can be assigned for a preferential treatment.

Layer-1 Parameters: Physical Media involving interfaces, subinterfaces, PVC or port.
Layer-2 Parameters: Mac-address, 802.1Q/p class of service bits (CoS), VLAN-ID, experimental bits (MPLS EXP), Frame-Relay Discard Eligibility bits (DE).
Layer-3 Parameters: IP Precedence (IPP), DiffServ Code Point (DSCP), Source and Destination IP address
Layer-4 Parameters: TCP or UDP Ports
Layer-7 Parameters: Application signatures and URLs in packet headers.

Policies can be applied to the traffic which has already been identified. Therefore the best-practice design recommends that traffic should be identified and marked as close to the source as possible, typically within the trusted devices. Once the traffic is marked, then the intermediate devices do not have to go through the process of classification and marking, they can just administer the QoS policies based on the already set markings.

End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks (2nd Edition) (Networking Technology)

Cisco Modular QoS Command Line Interface.
This is the main tool for QoS Classification within Cisco IOS. Also called as MQC.

MQC-based Class Maps:

Class maps identify traffic flows using a wide array of filtering criteria which are individually defined by match statements within a class map.
Multiple match statements can be defined within a single class map.
There are two options available when defining multiple match statements within a class map
1. match-all: Works as a Logical AND operand, that is all statements must be true for the class map condition to be met.
2. match-any: Works as a Logical OR operand, that is any of the match statement can be true for the class map condition to be met.

when defining multiple match statements within a single class-map, using the match-all or match-any claus is optional, but when none of these two is used then it defaults to match-all.

Example below shows the class map command.

LAB-Router#config t
LAB-Router(config)#class-map test123

LAB-Router(config-cmap)#match ?

The Sequence of statements within the class-maps are unimportant but the sequence of classes within the policy-maps impacts how the traffic is handled, the policy-maps implement the First-True-Match rule, which means that the classes examine a packet until a match is found, and once a match is found no more class maps are further checked.

Example: Class map / Policy Map and applying it on interface

1. Define Class map for Voice traffic
Class-map match-all VoIP
match ip dscp ef

2. Define Class map for Call-Signaling traffic
Class-map match-all Signaling
match ip dscp cs3

3. Define a Policy Map and include both these Classes and the default class
Policy-map Edge
class VoIP
priority percent 70
class Signaling
bandwidth 5
class default
fair-queue
random-detect

4. Apply on the interface:
interface Serial 1
service-policy output Edge

Note: Class Map and Policy Map names are case sensitive.

NBAR: Network Based Application Recognition.

NBAR can classify packets based on Layer-4 through Layer-7 protocols. NBAR looks beyond the TCP/UDP port numbers of a packet – known as subport classification and examines the packet payload to further classify the packets on payload content.

Not all NBAR classification involves stateful inspection and not all ‘match protocol’ statements will trigger NBAR
Some of the statefully inspected protocols are
FTP
TFTP
HTTP (URL and MIME)
Oracle SQL*NET
Real Audio
StreamWorks
VDOLive
NetShow
r-commands

NBAR Classification Example Configuration:
LABRouter(config)# class-map match-any App1
LABRouter(config-cmap)# match protocol ftp
LABRouter(config-cmap)# match protocol http
LABRouter(config-cmap)# match protocol telnet
LABRouter(config-cmap)# match protocol SSH

LABRouter(config)# class-map match-any web1
LABRouter(config-cmap)# match protocol http url “*.php”
LABRouter(config-cmap)# match protocol http url “*.gif”
LABRouter(config-cmap)# match protocol http url “*.jpg|*.jpeg”

LABRouter(config)# class-map match-any BROADCAST1
LABRouter(config-cmap)# match protocol http mime “*/audio/*”
LABRouter(config-cmap)# match protocol http mime “*/video/*”

NBAR Protocol Discovery:

NBAR Can perform protocol discovery using the sniffing capability of its classification Engine. In cases where is NBAR is not required for defining the QoS Policy, NBAR protocol discovery mode can be used to get information about traffic present on the network and how much bandwidth each traffic type is using.

Command: LABRouter#show ip nbar protocol-discovery stats byte-rate <Interface>

NBAR RTP Payload Classification

RTP Stands for Real-Time Transport Protocol, and defines a standardized packet format for delivering audio and video over a network.

Filtering traffic by codec can be done by inspecting the payload type field within the RTP header

Command: match protocol rtp

where
Audio = matches payload-type values 0 to 23
Video = matches payload type values 24 to 33
Payload-type = Used for more granular matching, as the example below.

As an Example: the following command instructs NBAR to match RTP traffic with the payload types 0, 1, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, or 64:

LABRouter(config)# class-map match-any RTP_Filter
LABRouter(config-cmap)#match protocol rtp payload-type “0, 1, 4 – 0x10, 10001b – 10010b, 64”

Note: match protocol statement can be given in decimal, hexadecimal (the 0x notation), or binary (the 10001b notation) numbers.
Individual numbers separated by commas can be specified, and ranges of numbers can be used, as in the case of 4 – 0x10, which means a decimal value of 4 to a hexadecimal value of 10 (which equates to a decimal value of 16). Therefore, all RTP payload types between 4 and 16 are matched for this part of the statement. Similarly, the binary range 10001b to 10010b equates to 17 to 18 in decimal.

Why Use NBAR.

One of the most asked question when classifying traffic is ‘ What criteria to use to classify the packets, should the traffic be classified on layer-2 address,  Layer-3 IP address, Protocol or Port Numbers’.

Classifying Packets based on layer-2 mac-address can be cumbersome and a lot of work for the network  administrators. But at layer-2 you can always classify traffic based on the CoS Values. Cos are layer-2 Values which an  layer-2 Switch can set.

Classifying packets based on layer-3 Source and Destination addresses is possible but these addresses can change, and the classification may not work if the layer-3 addresses keep changing. But you can classify based on values set in ToS field ( IPP or DSCP).

The Other option is to classify packets based on the TCP and UDP Port Numbers, but some Applications like RTP  change their UDP Port Numbers very frequently as they are dynamic UDP port numbers.

Then we can also look at classifying based on layers 5 through 7 using NBAR., a tool which Cisco provides, it recognizes the application by looking into the packet itself. And therefore using NBAR can make classifying easy, though it may be a little heavy on the routers due to admin overhead involved with NBAR.

Once NBAR classifies and marks the packets on your trust boundary , the remaining uplink routers in the path can use the same markings.  This leads to the question of What and where these markings will be on the packet ?

Can the marking be on Layer-2 on the packets – yes, but the problem with layer-2 marking is that the layer-2 is stripped off at each router(layer-3) hop, so the markings will also vanish. So its better to use layer-3, because layer-3 information is maintained from source to destination.

The rest of the routers in the path look at the layer-3 marking which is the ToS – Type of Service and treat the packet accordingly.

Always As A Rule of Thumb: Classify and Mark the packets as close to the source as possible.

Also, note that Marking is only to save your other routers/devices in the path from classifying the packets again, so to save them from the administrative overhead. You can always classify the packets and instruct how the packets are treated based on classification without putting any marking on the packets.

Another Example of Using NBAR

To view the traffic traversing your link based on NBAR – configure the nbar under the interface you want to see the traffic and then use the show command listed below to view the top talking traffic

Config t
int serial 0/0/0
ip nbar protcol-discovery
End

Once the Above Configuration is complete – type the below Show command to see what NBAR is finding out for you

# Show ip nbar protocol-discovery stats bit-rate top-n 10

The below command will let you see the stats for the traffic which is classified as unknown by nbar.

#Show ip nbar unclassified-port-stats

If  you enabled NBAR and you see that NBAR is not showing some of the Protocols  then you can always download the latest Protocol Description Language Modules (PDLMs) from Cisco’s website  and Install them on your router

Procedure To get the latest NBAR PDLM definations installed on your router:

1. Download the NBAR PDLM File from Cisco’s website  (you will need CCO or Smartnet account)
2. Copy the File to the Router’s Flash
3. Verify:  # Show Flash

Then use the below command to add the NBAR PDLM to the NBAR definations on your Router.

Config t
ip nbar pdlm <Full path to the PDLM File Like Flash://yxz.pdlm>

Example  RTR# ip nbar pdlm flash://rtsp.pdlm

Marking Tools:

The different marking tools available are

1. Class-based Marking
2. Marking using the class-based policing
3. Committed Access Rate (CAR) is a legacy marking technique
4. Policy-based marking is also legacy marking technique
5. For IP telephony systems Voice gateway packet marking is another option.

Most widely used today are class-based marking and marking using class-based policing.

Class-Based Marking:

Uses the Cisco Modular Command Line interface based syntax.

“set” commands within the policy map are used to mark the packets, frames or labels.

Class-Based marking was IP CEF dependent in earlier IOS releases and IP CEF needs to be enabled in global configuration mode to use this feature on the earlier IOS releases.

Class-based marking occurs only after classification of the packet is done. That is “set” occurs only after the “match” criteria.

As an Example Below:

I. Define Class-maps with the ‘match’ statements

LABRouter# config term
LABRouter(config)# Class-map match-all VoIP
LABRouter(config-cmap)# match ip dscp ef
LABRouter(config-cmap)#end

LABRouter# config term
LABRouter(config)# Class-map match-all Signalling
LABRouter(config-cmap)# match ip dscp cs3
LABRouter(config-cmap)#end

II. Defin Policy-maps with the ‘set’ statements

LABRouter# config term
LABRouter(config)# policy-map Edge
LABRouter(config-pmap)# class VoIP
LABRouter(config-pmap-c)# set dscp ?
LABRouter(config-pmap-c)# set precedence ?
LABRouter(config-pmap-c)#exit

LABRouter(config-pmap)#class Signalling
LABRouter(config-pmap-c)#set dscp ?
LABRouter(config-pmap-c)#set precedence ?
LABRouter(config-pmap-c)#end

III. Apply on an Interface

Can be applied either on input policy or on output policy, the behavior varies on how you apply the policy.

LABRouter# config term
LABRouter(config)#interface Serial 1
LABRouter(config-int)#service-policy output Edge

LABRouter# config term
LABRouter(config)#interface Serial 2
LABRouter(config-int)#service-policy input Edge

If applied on the output policy, then the packet marking can be used by the next-hop device to classify the packet. If applied to output tunnel interfaces then the classification and marking can happen after the tunnel encapsulation depending on where the policy is attached. If the policy is attached to GRE and IPSEC tunnels the marking in applied to original inner packet headers, if not then in most cases it is copied to the tunnel header.

If applied on the input interface then the markings can be used by the device on the packets leaving its egress interface.

Marking can be done at both Layer-2 and Layer-3, the respective fields involved per these layers are:

Layer 2 Marking Fields:            802.1Q/p CoS bits, MPLS EXP, Frame-Relay DE bits.

Layer-3 Marking Fields:            IP Precedence or DSCP.

LAYER-2 Marking:

Layer-2 marking are not often involved with end-to-end QoS as they are always lost whenever the layer-3 media changes, for example moving from ethernet to wan media. It is important to note that layer-2 markings must be translated to layer-3 markings to ensure the correct end-to-end QoS consistency for the frames/packets.

Layer-2 is normally stripped out at the Router Hops, So all the Layer-2 information is lost when L2 header is stripped off at each Router.  The most popular way of L2 Marking is – CoS ‘ Class of Service’.

Ethernet Frame: PRI Field has 3 Bits defined for CoS 802.1p User Priority.

Preamble SFD Source       Address Destination    Address Type TAG PT Data FCS
3 Bits used for Layer-2 QoS marking —————> PRI CFI VID

Ethernet Frames can be marked at Layer-2 by setting the 802.1p User Priority Bits (CoS) in the 802.1Q header. In the 802.1Q header only 3 bits are available for marking, therefore only 8 class of Service (0-7) can be marked at Layer-2. These Class of Service (CoS) values are identical to the IP Precedence values and are as follows.

CoS Value Application
7 Reserved
6 Reserved
5 Voice
4 Video-conferencing
3 Call Signalling
2 High Priority Data
1 Medium-Priority Data
0 Best Effort Data

Frame-Relay DE Bit

The Frame Relay DE Bit can only take two values 0 or 1, and indicate the packets that are less important and can be dropped curing periods of congestion.Frames set at DE Bit 1 are discarded before the frames set at DE bit 0.

Traditionally the Cisco IOS was not capable of setting the DE bit and default was DE Bit = 0. The Service provider Frame-Relay switch used to set the DE bit to 1 if the CIR was violated, but starting at IOS 12.2(T) , Cisco IOS can use the class based marking features to support the control bit.

MPLS EXP:

MPLS labels use 3 bits for CoS marking and these bits are called as MPLS EXP bits. The possible values for the CoS are the same as the 802.1Q/p  CoS and IP Precedence. Beginning Cisco IOS 12.1(5)T the MPLS EXP bits can read (Class-map match commands) and write (Policy-map set commands) using the MQC. When the packet enters the PE router, the IP precedence of the packet is automatically copied to the MPLS EXP field in the MPLS header, unless required a re-m,raking due to administrative policy. Upon exiting the MPLS network, the original IP packet comes out with the original IP header, so no action is required unless remarking has to be done due to administrative policy.

LAYER-3 Marking:

Layer-3 marking can be done either via IP Precedence or through the DSCP. They have end-to-end network significance and easily can be translated to the Layer 2 frame markings

IP Precedence:

The first 3 bits of the ToS field in the IPHeader, since these are only 3 bits so there can be only 8 possible values of marking (0-7) similar to the Layer-2 802.1Q/p Cos values. Value 0 is the default and Values 6 and 7 are reserved for the network control traffic. The remaining 5 values are actually used for the non-best-effort traffic, In which the value =5 is recommended for Voice, Value=4 is recommended for both streaming video and video-conferencing, and a Value=3 is recommended for Call signaling, Values=1 and 2 are left for the data applications.
DSCP – Differentiated Services Code Point

DSCP used 6 Bits of the ToS Field to provide QoS marking. Therefore DSCP values range from 0 (000000) through 63 (111111), providing huge options for the QoS marking.

With DSCP, it was structured to be backward compatible with IPP values. So the 6 bits of DSCP were broken down into two parts which would be like [000|000]
(major class)000|000(minor or sub-class). The 3 bits in the major class are backward compatible with IPP and the minor class can be used for more granular control on traffic. With DSCP, many different classes were defined which are
Default Class – DSCP 0
AF1 – meant to be backward compatible with IPP and AF1 matches to IPP1
AF2 – meant to be backward compatible with IPP and AF2 matches to IPP2
AF3 – meant to be backward compatible with IPP and AF3 matches to IPP3
AF4 – meant to be backward compatible with IPP and AF4 matches to IPP4
EF (EF instead of AF5 was defined), and yes this matches to IPP 5.

So in the major CLasses the Higher is better (ex. EF wil be better than AF1,2,3 or 4, Since EF is higher)

Now again in the AF class they were 3 minor classes were defined which were the Drop Preference values and these values range from 1-3, this is because the in the minor class the last bit is never used and is always set to zero, that is 11|0 or 01|0 – the last bit is not used and always 0 so the max value the minor class can have is 3. In the 3 minor classes which are the drop preference the lower is better because lower drop preference is always better than giving a packet a higher drop preference , so within a single AF class, lets say AF1, AF11 is better than AF13 and between two Classes AF23 wil be better than AF11.

DSCP values can be expressed in numeric form or by the keywords known as ‘Per Hop Behaviors’ (PHB). There are 3 defined classed of DSCP PHBs which are

1. Best Effort (BE) or DSCP 0
2. Assured Forwarding (AFxy)
3. Expedited Forwarding (EF).

There are also Class Selector Codepoints (CSx) which are defined to be backward compatible with the IPP. These Class Selectors range for CS1 through CS7 and are identical to the IPP values 1 through 7.

Assured Forwarding (AF)

Assured Forwarding classes  are denoted with AF followed by 2 numerical digits. The 1st digit denotes the AF class and can have a value in the range of 1-4. The Second digit represents the level of drop precedence within each AF class and can range from 1-3, where 1 = Lowest Drop Preference and  3 = Highest Drop Preference.

Per Hop Behaviors Low Drop Medium Drop High Drop
AF Class 1 AF Values AF11 AF12 AF13
Binary Value 10 12 14
DSCP Value 001010 001100 001110
AF Class 2 AF Values AF21 AF22 AF23
Binary Value 18 20 22
DSCP Value 010010 010100 010110
AF Class 3 AF Values AF31 AF32 AF33
Binary Value 26 28 30
DSCP Value 011010 011100 011110
AF Class 4 AF Values AF41 AF42 AF43
Binary Value 34 36 38
DSCP Value 100010 100100 100110

Expedited Forwarding (EF) has a Binary value of 46 which equates to DSCP code points  101110 and Best Effort is 000000.

QoS Marking Tools For Layer-3 Tunnels

Three tools are available for marking the Layer-3 tunnels

1. QoS Preclassify:

This command creates a copy of the inner packet header before the packet is enveloped and upon egress the router checks the Inner packet header against any configured policies applied to the egress interface. Once the policies are applied to the packet the copy of the header is discarded.

2. ToS Reflection:

Is done by default on most platforms for IPSec and GRE tunnels.  As the name suggests its simply copying the ToS byte from inner header to the outer header.

3. Explicit Header Marking.

Mark the tunnel header explicitly as any other packet header is marked.

Examples:

1. Marking Audio Traffic with IP Precedence 5 (critical) using NBAR

Define Class Map to Indentify Traffic
Config t
Class-map Audio
Match protocol  rtp
Exit

Define Policy Map to Mark Traffic
Config t
Policy-map Audio-Map
Match class Audio
Set ip precedence 5
Exit

Apply on Interface
Config t
Int Fa0/0
Service-policy input Audio-Map
Exit

End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks (2nd Edition) (Networking Technology)


 

Incoming search terms for the article:

Leave a Reply