Traffic Classification and Marking
Classification and marking allow QoS-enabled networks to identify traffic types near the source and assign specific markings to those traffic types. This section addresses the need for and various approaches used to perform classification and marking.
Classification and Marking Basics
One of the first QoS mechanisms that you apply to your traffic is classification, which recognizes the types of traffic that are flowing across the network. For example, you might recognize Telnet, FTP, and HTTP traffic and categorize those applications together in a specific class of traffic.
Although classification is great, you probably do not want to configure classification on every router. Therefore, after the traffic is classified, you can “mark” it. At that point, other routers and switches in the network can reference those markings and make decisions (for example, forwarding or dropping decisions) based on those markings.
Some of these markings are Layer 2 (that is, the Data Link Layer) markings, whereas other markings are at Layer 3 (that is, the Network Layer). First, consider the Layer 2 markings.
On an Ethernet trunk, you can mark frames with a class of service (CoS) value. A CoS value can range from 0 through 7, although Cisco recommends that you never use 6 or 7. The bits that create the CoS marking depend on the type of trunk that is being used, as follows:
IEEE 802.1Q trunk—Uses 3 bits in a Tag Control byte to mark a CoS value. (Note: This method is referred to as IEEE 802.1p.)
ISL trunk—Uses 3 bits in the ISL header to mark a CoS value.
)
Figure
8Layer 2 markings also can extend to the WAN. Consider a Frame Relay network. Within a Frame Relay header is a bit called the Discard Eligible (DE) bit, which identifies frames that the service provider can drop during periods of congestion. You can leverage that DE bit to identify less important traffic that you send to the Frame Relay service provider. Similarly, you can mark the Cell Loss Priority (CLP) bit in an ATM cell to identify less important ATM traffic.
Service providers often use Multiprotocol Label Switching (MPLS) to forward traffic. Three bits in the MPLS label can be used to identify priority for traffic that is flowing through the service provider’s cloud.
As mentioned earlier, Layer 3 markings are made possible by using bits within an IPv4 header’s ToS byte. These markings are IP Precedence (which uses the 3 leftmost bits in the ToS byte) and DSCP (which uses the 6 leftmost bits in the ToS byte).
A major design issue to keep in mind is that a CoS marking from a trunk does not survive a route processor hop. So, if you are only using CoS markings to identify the priority of your traffic, those CoS markings should be “remarked” to a Layer 3 marking before the traffic passes through a route processor.
)
Figure
9Although Cisco recommends marking traffic as close to the source as possible, you typically do not want users setting their own priority markings. Therefore, you can use Catalyst switches to create a trust boundary, which is a point in the network that does not trust incoming markings. An exception to having a wiring closet switch acting as a trust boundary would be a Cisco IP Phone that is connected to the switch. Because the Cisco IP Phone performs priority marking, you can extend the trust boundary to the phone.
Modular Classification with MQC
Recall the previous discussion about the Cisco three-step MQC process for configuring QoS mechanisms. You can leverage this MQC approach to do classification and marking. First, consider classification using MQC. In class-map configuration mode, you can use the match command to categorize traffic based on any of the following criteria:
Access control lists (ACLs)
Existing markings (for example, CoS, IP Precedence, or DSCP)
QoS group (a locally significant grouping of packets)
Protocol (using NBAR)
Traffic matching another class-map
Incoming interface
MAC address (source or destination)
Range of UDP port numbers
In the following example, you are matching traffic based on a variety of the preceding criteria:
Router(config)#class-map match-any INT Router(config-cmap)#match input-interface ethernet 0/0 Router(config-cmap)#match input-interface ethernet 0/1 Router(config-cmap)#exit Router(config)#class-map ACL Router(config-cmap)#match access-group 101 Router(config-cmap)#exit Router(config)#class-map COS Router(config-cmap)#match cos 0 1 2 3 Router(config-cmap)#exit Router(config)#access-list 101 permit tcp any any eq 23
In this example, the INT class-map matches traffic that came into the router on any of the specified interfaces. The ACL class-map matches traffic that is matched by access-list 101. Finally, the COS class-map categorizes traffic with a CoS marking of 0, 1, 2, or 3.
Modular Marking with MQC
After you have classified your traffic using class-maps, you can use a policy-map to mark the traffic. Following is a listing of supported markings and the corresponding syntax:
IP Precedence (set ip precedence value)
DSCP (set ip dscp value)
QoS group(set ip precedence value)
MPLS experimental bits (set mpls experimental value)
CoS value (set cos value)
Frame Relay DE bit (set fr-de)
ATM CLP bit (set atm-clp)
In the following example, you use MQC to remark CoS values that are entering a router to DSCP values:
)
Figure
10Router(config)#class-map HI-PRI Router(config-cmap)#match cos 5 6 7 Router(config-cmap)#exit Router(config)#class-map MED-PRI Router(config-cmap)#match cos 2 3 4 Router(config-cmap)#exit Router(config)#class-map LOW-PRI Router(config-cmap)#match cos 0 1 Router(config-cmap)#exit Router(config)#policy-map REMARK Router(config-pmap)#class HI-PRI Router(config-pmap-c)#set ip dscp af31 Router(config-pmap-c)#exit Router(config-pmap)#class MED-PRI Router(config-pmap-c)#set ip dscp af21 Router(config-pmap-c)#exit Router(config-pmap)#class-map LOW-PRI Router(config-pmap-c)#set ip dscp af11 Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#interface fastethernet 0/1 Router(config-if)#service-policy input REMARK
In this example, traffic marked with CoS values of 5, 6, or 7 is classified in the HI-PRI class-map, whereas traffic with CoS values of 2, 3, or 4 goes into the MED-PRI class-map. Finally, CoS values of 0 and 1 are placed in the LOW-PRI class-map. The REMARK policy-map assigns a DSCP value of AF31 to the HI-PRI traffic, a DSCP value of AF21 to the MED-PRI traffic, and a DSCP value of AF11 to the LOW-PRI traffic. The third step of MQC applies a policy-map to an interface. In this case, you are applying the REMARK policy-map to the FastEthernet 0/1 interface in the inbound direction. It is critical that you apply the policy-map in the inbound direction. By doing so, you are remarking the CoS values before the route processor strips them.
As you learned earlier, to see what policies are applied to your class-maps, use the show policy-map command. Or, to see interface-specific statistics for a policy-map, the show policy-map interface interface-identifier command is appropriate.
Classifying with NBAR
The most powerful and flexible approach to classifying traffic is the Network Based Application Recognition (NBAR) feature. NBAR can look beyond Layer 3 and Layer 4 information, all the way up to Layer 7. Protocols that change port number (that is, stateful protocols) can be tracked, and even URL strings can be matched with NBAR.
Although the IOS comes with multiple NBAR application signatures, a continuing need exists for additional signature recognition. For example, even though your router might be able to recognize KaZaa traffic, it might not be able to recognize e-Donkey traffic. Fortunately, you can install Packet Description Language Modules (PDLMs) into the router’s flash, and these PDLMs extend the IOS’s ability to recognize traffic. PDLMs are available for download from http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm.
Note that this site requires a Cisco.com login. Also, note that the context-sensitive help in the IOS might define the PDLM as Protocol Description Language Module instead of Packet Description Language Module.
)
Figure
11In addition to NBAR’s usefulness in classifying, it can function as a protocol discovery tool. For example, NBAR protocol discovery could be enabled on an interface to determine the applications that are consuming the most bandwidth on that interface (that is, the “top talkers”).
The following command configures NBAR protocol discovery:
Router(config-if)#ip nbar protocol-discovery
After NBAR has collected traffic statistics for an interface, use the following command to view the statistics:
Router#show ip nbar protocol-discovery
To use NBAR to classify traffic, as part of a class-map, use the keyword protocol in the match command, as follows:
Router(config-cmap)#match protocol protocol
You can reference the previously mentioned PDLM file with the following command:
Router(config)#ip nbar pdlm pdlm-file
In the following example, NBAR classifies KaZaa Version 2 traffic and HTTP traffic:
)
Figure
12Router(config)#class-map MUSIC Router(config-cmap)#match protocol kazaa2 Router(config-cmap)#exit Router(config)#class-map WEB Router(config-cmap)#match protocol http Router(config-cmap)#exit Router(config)#policy-map NBARTEST Router(config-pmap)#class MUSIC Router(config-pmap-c)#police 32000 Router(config-pmap-c)#exit Router(config-pmap)#class-map WEB Router(config-pmap-c)#bandwidth 128 Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#interface ethernet 0/1 Router(config-if)#service-policy output NBARTEST
In this example, KaZaa version 2 traffic is classified by the MUSIC class-map, whereas http traffic is classified by the WEB class-map. Then, the NBARTEST policy-map limits the MUSIC class to 32 kbps while allocating 128 kbps of bandwidth for the WEB class. Finally, the policy-map is applied outbound to the ethernet 0/1 interface.
Consider the priority that you should assign to web traffic. If you have an e-commerce site, as an example, web traffic might need varying levels of priority, depending on the content of the web traffic. The good news is that NBAR can recognize the content of web traffic using commands such as the following:
Router(config-cmap)#match protocol http url url-string
(Matches a string that is contained in the URL)
As an example, you could match traffic that contains the word cisco in the URL with the following command:
match protocol http url “*cisco*”
The asterisks are acting as wildcards, matching any characters before or after the word cisco.
QoS over Tunnel Connections
Virtual private networks (VPNs) are gaining tremendous popularity because of their ability to provide secure connectivity through a public network, such as an ISP. VPNs are made possible thanks to tunneling.
The challenge with QoS in a tunnel environment is that the tunnels encapsulate traffic, which hides the original information in a packet’s header. After packets enter a tunnel, they have a tunnel header. Therefore, all packets have the same level of priority, because the classification of encapsulated packets is based on the tunnel header. The Cisco pre-classify feature overcomes this issue by applying QoS features to packets before they enter the tunnel. Pre-classification, however, is only necessary when you are classifying based on a criterion other than a packet’s ToS byte. The IOS automatically copies bits from a packet’s ToS byte into the ToS byte of the tunnel header.
)
Figure
13 ***
To enable the pre-classification feature, in tunnel-interface-configuration mode (or in crypto-map configuration mode for an IPSec tunnel), enter the following command:
qos pre-classify
QoS over BGP Networks
In a service provider environment, you might not want to use access-lists or other classification mechanisms through the service provider’s network. An alternate option is to use QoS Policy Propagation Through BGP (QPPB).
QPPB lets you encode QoS information by assigning BGP attributes such as an autonomous system number, community string, or an IP prefix.
For example, instead of setting the IP Precedence marking to a 4 inside every packet, you could send the traffic with a certain community string. When the far-end autonomous system receives the traffic with that community string, it can mark those packets with an IP Precedence of 4.
In the following example for router R1, the community attribute determines how the IP Precedence value is set. Specifically, traffic with a community string of 20:1 has its IP Precedence set to a 2, and traffic with a community string of 20:2 has its IP Precedence set to a 3. The bgp-policy source command applies this policy to interface Serial 0/1.
)
Figure
14 ***
router bgp 100 table-map precedence-map neighbor 1.1.1.2 remote-as 200 neighbor 1.1.1.2 send-community ! route-map precedence-map permit 10 match community 1 set ip precedence 2 ! route-map precedence-map permit 20 match community 2 set ip precedence 3 ! ip community-list 1 permit 20:1 ip community-list 2 permit 20:2 ! interface serial 0/1 ip address 1.1.1.1 255.255.255.0 bgp-policy source ip-prec-map
Catalyst-Based Classification and Marking
You can perform classification and marking functions, not just on router platforms, but also on many Catalyst series switches. Even though QoS is considered primarily a WAN technology, proper QoS configuration in a enterprise network’s infrastructure is also critical. For example, a switch might have interfaces that run at different speeds (for example, 10 Mbps and 1 Gbps). Such a scenario could lead to a switch queue overflowing. Also, traffic can enter a switch marked with a Layer 2 CoS value. These Layer 2 values do not pass through a route processor. Therefore, a Catalyst switch is an excellent place to perform CoS-to-DSCP remarking. So, when the traffic reaches the route processor, it has a Layer 3 marking, which can pass successfully through the route processor.
Applying QoS features at the edge of the network (for example, in a wiring closet) offers the following benefits:
Provides immediate traffic classification
Reduces congestion within the remainder of the network
Eases the processor burden on the distribution and core routers
These Quick Reference Sheets primarily focus on the Catalyst 2950 Series of switches. You can configure the Catalyst 2950 ports to trust CoS or DSCP markings. However, by default, these ports are “untrusted,” meaning that they disregard priority markings on incoming traffic. When a port is untrusted, traffic is assigned the configurable CoS value of the port.
The Catalyst 2950 can place frames in one of four queues. Later in these Quick Reference Sheets, you use these queues for Weighted Round Robin (WRR) queuing. For now, however, you should be familiar with how the switch places frames with various CoS markings into its four queues, as described in the following table.
|
Default Queue Assignment |
|
|
CoS Value |
Queue |
|
0 and 1 |
1 |
|
2 and 3 |
2 |
|
4 and 5 |
3 |
|
6 and 7 |
4 |
For internal QoS processing, all traffic (even non-IP traffic) is assigned an internal DSCP number. The default CoS-to-DSCP mappings are shown in the following table.
|
CoS-to-DSCP Mappings |
|
|
CoS Value |
DSCP Value |
|
0 |
0 |
|
1 |
8 |
|
2 |
16 |
|
3 |
24 |
|
4 |
32 |
|
5 |
40 |
|
6 |
48 |
|
7 |
56 |
Because the Catalyst 2950 uses CoS values to make queuing decisions, before the queuing process, the internal DSCP value is extrapolated to a CoS value. Although mappings are configurable, the default values are shown in the following table.
|
DSCP-to-CoS Mappings |
|
|
DSCP Values |
CoS Value |
|
0 |
0 |
|
8 and 10 |
1 |
|
16 and 18 |
2 |
|
24 and 26 |
3 |
|
32 and 34 |
4 |
|
40 and 46 |
5 |
|
48 |
6 |
|
56 |
7 |
With your understanding of the default switch behavior, you can explore how to manipulate the trust settings and the CoS-to-DSCP mappings. The following command tells a port what to trust:
Switch(config-if)#mls qos trust [cos [pass-through dscp] | device cisco-phone | dscp]
The pass-through dscp option does not modify the DSCP values (that is, remark them based on CoS values).
You can use the following command to assign a default CoS value for a port:
Switch(config-if)#mls qos cos {default-cos | override}
The override option applies the default CoS value to a frame, even though a frame might already have a CoS marking.
The following commands allow you to manipulate the default CoS-to-DSCP and DSCP-to-CoS mappings:
Switch(config)#mls qos map cos-dscp dscpvalue1 dscpvalue2 ... dscpvalue8
(Configures CoS-to-DSCP mapping)
For example:
Switch(config)#mls qos map cos-dscp 0 16 24 32 34 40 48 56
In this example, the eight DSCP values that are entered correspond to CoS values 0 through 7.
Switch(config)#mls qos map dscp-cos dscp-list to cos
(Configures DSCP-to-CoS mapping)
For example:
Switch(config)#mls qos map dscp-cos 16 28 24 26 to 1
)
Figure
15 ***
You can associate up to 13 DSCP values with a single CoS value.
The three-step MQC process can also be used on a Catalyst 2950 to perform classification and marking, without as many “match” options as are available on a router platform. Typically, you create a standard or extended IP access-list (or a Layer 2 MAC ACL for non-IP traffic). That access-list can then serve as the match criterion in a class-map. Note, however, that the extended IP access-lists that are available on the Catalyst 2950 do not have all the options that are available on a router. Specifically, you cannot use the access-list to match a range of port numbers.
In the following example, an extended IP access-list matches traffic that is destined for IP address 192.168.0.101. A policy-map then marks traffic that is destined for that host with a DSCP value of 34. Finally, the policy is applied to interface Gigabit Ethernet 0/3 in the inbound direction. The example is as follows:
Switch(config)#access-list 100 permit ip any host 192.168.0.101 Switch(config)#class-map CATCLASS Switch(config-cmap)#match access-group 100 Switch(config-cmap)#exit Switch(config)#policy-map CATPOLICY Switch(config-pmap)#class CATCLASS Switch(config-pmap-c)#set ip dscp 34 Switch(config-pmap-c)#interface gig 0/3 Switch(config-if)#service-policy input CATPOLICY
A switch’s QoS interface configuration can be verified with the following command:
Switch#show mls qos interface interface-identifier
Use the following command to see how CoS and DSCP values are mapped to one another:
Switch#show mls qos maps [cos-dscp | dscp-cos]