QoS 2 Classification and Marking

Classifying and Marking Traffic
Conceptually, DiffServ QoS involves three steps:
• Traffic must be identified and then classified into groups.
• Traffic must be marked on trust boundaries.
• Policies must be created to describe the per-hop behavior for
classified traffic.
DiffServ QoS relies on the classification of traffic, to provide differentiated
levels of service on a per-hop basis. Traffic can be classified based on a wide
variety of criteria called traffic descriptors, which include:
• Type of application
• Source or destination IP address
• Incoming interface
• Class of Service (CoS) value in an Ethernet header

• Type of Service (ToS) value in an IP header (IP Precedence or DSCP)
• MPLS EXP value in a MPLS header

Access-lists can be used to identify traffic for classification, based on

address or port. However, a more robust solution is Cisco’s Network-Based
Application Recognition (NBAR), which will dynamically recognize
standard or custom applications, and can classify based on payload.
Once classification has occurred, traffic should be marked, to indicate the
required level of QoS service for that traffic. Marking can occur within
either the Layer-2 header or the Layer-3 header.

The point on the network where traffic is classified and marked is known as
the trust boundary. QoS marks originating from outside this boundary
should be considered untrusted, and removed or changed. As a general rule,
traffic should be marked as close to the source as possible. In VoIP
environments, this is often accomplished on the VoIP phone itself. Traffic
classification should not occur in the network core.

Configuring DiffServ QoS on IOS devices requires three steps: 

• Classify traffic using a class-map.

• Define a QoS policy using a policy-map.

• Apply the policy to an interface, using the service-policy command.

Layer-2 Marking

Layer-2 marking can be accomplished for a variety of frame types: 

• Ethernet – using the 802.1p Class of Service (CoS) field. 

• Frame Relay – using the Discard Eligible (DE) bit. 

• ATM - using the Cell Loss Priority (CLP) bit. 

• MPLS - using the EXP field. 

Marking Ethernet frames is accomplished using the 3-bit 802.1p Class of 

Service (CoS) field. The CoS field is part of the 4-byte 802.1Q field in an 

Ethernet header, and thus is only available when 802.1Q VLAN frame 

tagging is employed. The CoS field provides 8 priority values: 

Frame Relay and ATM frames provide a less robust marking mechanism, 

compared to the Ethernet CoS field. Both Frame Relay and ATM frames 

reserve a 1-bit field, to prioritize which traffic should be dropped during 

periods of congestion. 

Frame Relay identifies this bit as the Discard Eligible (DE) field, while 

ATM refers to this bit as the Cell Loss Priority (CLP) field. A value of 0 

indicates a lower likelihood to get dropped, while a value of 1 indicates a 

higher likelihood to get dropped. 

MPLS employs a 3-bit EXP (Experimental) field within the 4-byte MPLS 

header. The EXP field provides similar QoS functionality to the Ethernet 

CoS field. 

Layer-3 Marking

Layer-3 marking is accomplished using the 8-bit Type of Service (ToS)

field, part of the IP header. A mark in this field will remain unchanged as it 

travels from hop-to-hop, unless a Layer-3 device is explicitly configured to 

overwrite this field. 

There are two marking methods that use the ToS field: 

• IP Precedence - uses the first three bits of the ToS field. 

• Differentiated Service Code Point (DSCP) – uses the first six bits of 

the ToS field. When using DSCP, the ToS field is often referred to as 

the Differentiated Services (DS) field. 

These values determine the per-hop behavior (PHB) received by each 

classification of traffic. 

IP Precedence

IP Precedence utilizes the first three bits (for a total of eight values) of the 

ToS field to identify the priority of a packet. Packets with a higher IP 

Precedence value should be provided with a better level of service. IP 

Precedence values are comparable to Ethernet CoS values:

By default, all traffic has an IP Precedence of 000 (Routine), and is 

forwarded on a best-effort basis. 

Normal network traffic should not (and in most cases, cannot) be set to 110 

(Inter-Network Control) or 111 (Network Control), as it could interfere with 

critical network operations, such as STP calculations or routing updates.

Differentiated Service Code Point (DSCP)

DSCP utilizes the first six bits of the ToS header to identify the priority of a 

packet. The first three bits identify the Class Selector of the packet, and is 

backwards compatible with IP Precedence. The following three bits identify 

the Drop Precedence of the packet.

DSCP identifies six Class Selectors for traffic (numbered 0 - 5). Class 0 is 

default, and indicates best-effort forwarding. Packets with a higher Class 

value should be provided with a better level of service. Class 5 is the highest 

DSCP value, and should be reserved for the most sensitive traffic. 

Within each Class Selector, traffic is also assigned a Drop Precedence. 

Packets with a higher Drop Precedence are more likely to be dropped 

during congestion than packets with a lower Drop Precedence. Remember 

that this is applied only within the same Class Selector. 

The Class Name provides a simple way of identifying the DSCP value. AF

is short for Assured Forwarding, and is the type of service applied to 

Classes 1 – 4. If a packet is marked AF23, then the Class Selector is 2 (the 2

in 23) and its Drop Precedence is High (the 3 in 23). 

Packets marked as Class 0 (Default) or Class 5 (Expedited Forwarding or 

EF) do not have a Drop Precedence

Modular QoS CLI (MQC)

The Modular QoS CLI (MQC) is an improved command-line 

implementation of QoS that replaced legacy CLI commands on IOS devices. 

MQC is considered modular because it separates classification from policy 

configurations. 

There are three steps to configuring QoS using MQC:

• Classify traffic using a class-map.

• Define a QoS policy using a policy-map.

• Apply the policy to an interface, using the service-policy command.

Classifying and Marking Traffic using MQC

We have lab section for MQC policy.

Network-Based Application Recognition (NBAR)

Cisco’s Network-Based Application Recognition (NBAR) provides an 

alternative to using static access-lists to identify protocol traffic for 

classification. NBAR introduces three key features:

• Dynamic protocol discovery 

• Statistics collection 

• Automatic traffic classification 

NBAR provides classification abilities beyond that of access-lists, including: 

• Ability to classify services that use dynamic port numbers. This is 

accomplished using the stateful inspection of traffic flows. 

• Ability to classify services based on sub-protocol information. For 

example, NBAR can classify HTTP traffic based on payload, such as 

the host, URL, or MIME type. 

NBAR employs a Protocol Discovery process to determine the application 

traffic types traversing the network. The Protocol Discovery process will 

then maintain statistics on these traffic types. 

NBAR recognizes applications using NBAR Packet Description Language 

Modules (PDLMs), which are stored in flash on IOS devices. Updated

PDLMs are provided by Cisco so that IOS devices can recognize newer 

application types.

NBAR has specific requirements and limitations: 

• NBAR requires that Cisco Express Forwarding (CEF) be enabled. 

• NBAR does not support Fast EtherChannel interfaces.

• NBAR supports only 24 concurrent host, URL, or MIME types. 

• NBAR can only analyze the first 400 bytes of a packet. Note: This 

restriction is only for IOS versions previous to 12.3(7), which 

removed this restriction. 

• NBAR cannot read sub-protocol information in secure (encrypted) 

traffic types, such as HTTPS. 

• NBAR does not support fragmented packets. 

Configuring NBAR

To enable NBAR Protocol Discovery on an interface: 

Router(config)# ip cef 

Router(config)# interface fa0/0 

Router(config-if)# ip nbar protocol-discovery 

To view statistics for NBAR-discovered protocol traffic: 

Router# show ip nbar protocol-discovery

FastEthernet0/0 

Input Output 

----- ------ 

output cut ---

you find on the lab section.