The purpose of the “Do I Know This Already?” quiz is to help you decide whether you really need to read the entire chapter. If you already intend to read the entire chapter, you do not necessarily need to answer these questions now.

The 10-question quiz, derived from the major sections in “Foundation Topics” portion of the chapter, helps you determine how to spend your limited study time.

Table 4-1 outlines the major topics discussed in this chapter and the “Do I Know This Already?” quiz questions that correspond to those topics.

Table 4-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

You can find the answers to the “Do I Know This Already?” quiz in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Q&A Sections.” The suggested choices for your next step are as follows:

Most QoS tools classify traffic, which allows for each class of traffic to receive a different level of treatment from other traffic classes. These different types or classes of traffic are typically called service classes in QoS terminology. Classification allows the devices to decide which packets are part of each service class, which then allows the devices to perform other QoS functions differently based on the service class.

Classification and marking tools not only classify packets into service classes, but they also mark the packets in the same service class with the same value in a field in the header. By marking the packets, other QoS tools that examine the packet later can examine the marked bits to more easily classify packets.

Classification

Almost every QoS tool uses classification to some degree. To put one packet into a different queue than another packet, the IOS must somehow differentiate between the two packets. To perform header compression on Real Time Protocol (RTP) packets, but not on other packets, the IOS must determine which packets have RTP headers. To shape data traffic going into a Frame Relay network, so that the voice traffic gets enough bandwidth, the IOS must differentiate between Voice over IP (VoIP) and data packets. If an IOS QoS feature needs to treat two packets differently, it must use classification.

Because most QoS tools need to differentiate between packets, most QoS tools have classification features. In fact, many of you will already know something about several of the QoS tools described in this book, and you will realize that you already know how to perform classification using some of those tools. For instance, many QoS tools enable you to classify using access-control lists (ACLs). If ACL 101 permits a packet, a queuing tool might put the packet into one queue; if ACL 102 permits a packet, it is placed in a second queue; and so on. In one way of thinking, queuing could instead be called classification and queuing, because the queuing feature must somehow decide which packets end up in each queue. Similarly, traffic shaping could be called classification and traffic shaping, policing could be called classification and policing, and so on. Because most QoS tools classify traffic, however, the names of most QoS tools never evolved to mention the classification function of the tool.

Most classification and marking tools, like the other types of QoS tools, generally operate on packets that are entering or exiting an interface. The logic works something like an ACL, but the action is marking, as opposed to allowing or denying (dropping) a packet. More generally, classification and marking logic for ingress packets can be described as follows:

   For packets entering an interface, if they match criteria 1, mark a field with a value.

   If the packet was not matched, compare it to criteria 2, and then mark a potentially different field with a potentially different value.

   Keep looking for a match of the packet, until it is matched

   If the packet is not matched, no specific action is taken with the packet, and it is forwarded just like it would have been if no QoS had been configured.

Note    This book uses the following terms describe the data structures used when sending data:

   Frame—Bits that include the data link layer header and trailer (for example, Ethernet frame and Frame Relay frame)

   Cell—Specifically, an Asynchronous Transfer Mode (ATM) cell

   Packet—Bits that include the network layer header, but does not include the data link header (for instance, an IP packet)

   Segment—Bits that include the TCP or UDP header, but not the data link or network layer header

Class-Based Marking

This chapter focuses on Class-Based Marking (CB-Marking). CB Marking can classify packets into service classes by directly examining frame, cell, packet, and segment headers. CB Marking can also refer to access control lists (ACLs) to match packets, with packets permitted by an ACL being considered to match the logic used by CB Marking. For reference, Table 4-2 lists many of the most popular things that can be matched with an IP ACL; Table 4-3 lists the fields directly matchable by CB Marking in router IOS (as of Cisco IOS Software Release 12.2(15)T5):

Table 4-2 Popular IP Extended ACL Matchable Fields

* Although IP Precedence and DSCP can be matched with an ACL, with CB Marking, the fields can be matched directly without use of an ACL.

Table 4-3 Fields Directly Matchable by CB Marking

CB Marking can be configured to look at many of the fields in Tables 4-2 and 4-3 to directly classify packets. However, CB Marking can also use NBAR to classify packets. NBAR provides a router with the capability to classify packets, particularly hard-to-identify packets. Independently, NBAR can be configured to keep counters of traffic types and traffic volume for each type.

NBAR classifies packets that are normally difficult to classify. For instance, some applications use dynamic port numbers, so a statically configured match command, looking for a particular UDP or TCP port number, simply could not classify the traffic. NBAR can look past the UDP and TCP header, and refer to the host name, URL, or MIME type in HTTP requests. (This deeper examination of the packet contents is sometimes called deep packet inspection.) NBAR can also look past the TCP and UDP headers to recognize application-specific information. For instance, NBAR allows recognition of different Citrix application types, and allows searching for a portion of a URL string.

You can easily recognize when CB Marking is using NBAR for classification. When the match protocol command is used, CB Marking is looking to match a protocol discovered by NBAR.

Whether or not NBAR is used with CB Marking, it can be used to gather and report statistics about packets entering and exiting an interface. To see an exhaustive list of protocols, use the show ip nbar protocol-discovery command on a router that has NBAR enabled on one or more interfaces. Because CB Marking can take advantage of NBAR’s powerful packet matching capabilities, you should be aware of some of the more popular and more useful types of packets that NBAR can match. Table 4-4 lists those values.

Table 4-4 Popular Fields Matchable by CB Marking by Using NBAR

Marking involves setting some bits inside a data link or network layer header, with the goal of letting other devices’ QoS tools classify based on the marked values. You can mark a wide variety of fields, and each has a particular purpose. Some fields are more widely used, and some are less widely used. Some marking options make sense for all devices on the LAN, whereas others only when using specific hardware platforms. Marking at the WAN is possible, too.

The following sections list the header fields that you can use for marking, along with explanations of when it is most useful to use that particular field. Recommendations follow these sections as to when to use classification and marking.

IP Header QoS Fields: Precedence and DSCP

The two most popular marking fields for QoS are the IP Precedence and IP DSCP fields that were introduced in Chapter 2, “QoS Tools and Architectures.” QoS tools frequently use these two fields in part because the IP packet header exists from endpoint to endpoint in a network, as shown in Figure 4-1.

Figure 4-1 Headers Used During Typical Packet Flow

As seen in Figure 4-1, the IP packet en route to host PC2 stays intact throughout the network, whereas the data-link headers only exist while a frame is crossing between a host and a router, or between routers.

Figure 4-2 outlines the two marking fields and their positions inside an IP header.

Figure 4-2 IP Precedence and IP DSCP Fields

You can mark the Precedence and DSCP fields with any valid binary value of either 3 or 6 bits, respectively. Chapter 2 contains detailed discussion of the recommended values used in these two fields. Briefly, Precedence field values should grow in importance, and in QoS behavior, as the number gets higher. DSCP differs in that several per-hop behavior (PHB) RFCs define suggested DSCP values for which the larger number does not always get a better QoS treatment.

Table 4-5 lists the IP precedence and DSCP values, and their names, for review. Note that not all DSCP values are listed; only the DSCP values suggested by the DiffServ RFCs are listed in the table. Router QoS tools that are capable of setting DSCP can set any of the actual 64 values. (As you will read in Chapter 9, the 2950 cannot set all 64 DSCP values.)

Table 4-5 IP Precedence and DSCP—Popular Values and Names

The two IP header QoS marking fields do not provide all the QoS marking fields needed today. One day, all other Layer 3 protocols besides IP may no longer be used. One day, all LAN switches will be capable of looking at IP headers, including IP DSCP and Precedence, and perform QoS based on those fields. Likewise, one day, all WAN services, including Frame Relay and ATM switches, will be able to perform QoS based on these same fields. However, today’s reality is that even as more and more devices become capable of marking and reacting to IP precedence and DSCP, it will be a long time before all networking devices are both capable and configured to use these fields for QoS purposes. So, other QoS marking fields are needed.

Many LAN switches today can mark and react to a Layer 2 3-bit field called the Class of Service (CoS) located inside an Ethernet header. The CoS field only exists inside Ethernet frames when 802.1Q or Inter-Switch Link (ISL) trunking is used. (The IEEE 802.1P standard actually defines the usage of the CoS bits inside the 802.1Q header.) You can use the field to set 8 different binary values, which can be used by the classification features of other QoS tools, just like IP precedence and DSCP. Figure 4-3 shows the general location of the CoS field inside ISL and 802.1P headers.

Figure 4-3 LAN CoS Fields

The term CoS really refers to two different fields—a field inside either the 802.1Q trunking header, or a field inside the ISL header. The IEEE 802.1Q standard uses the 3 most-significant bits of the 2-byte Tag Control field, called the user-priority bits. The Cisco proprietary ISL specification uses the 3 least-significant bits from the 1-byte User field, which is found inside the ISL header’s user field byte. In general conversation, and in the QoS courses from Cisco, the term CoS applies to either of these two fields.

When can CoS be marked, and when can it be useful for classification to a QoS tool? First of all, trunking with 802.1Q or ISL must be enabled before the CoS field even exists! Second, as soon as the packet experiences Layer 3 forwarding, either with a router or some Layer 3 switch, the old LAN header gets discarded—which means you lose the CoS field. After a CoS field has been created and populated with the desired markings, routers and switches have several QoS tools that can react to these markings. Consider, for instance, a typical trunking environment, as shown in Figure 4-4, where all LAN switches are only performing Layer 2 switching.

Figure 4-4 CoS—Trunking Locations in a Typical Network, Layer 2 Switches Only

To mark the CoS bits, trunking must be used—and in Figure 4-4, trunking could be used on every Ethernet segment. Switches typically use trunking on the Ethernet segments to other switches, routers, and to IP Phones. Typically, switches do not need to use trunking on segments connected to PCs or servers. Because some networking cards have the capability to support 802.1Q or ISL trunking, however, servers and PCs can set the CoS bits.

Both routers and switches use QoS tools that can react to the marked CoS bits. Cisco routers can indeed mark CoS bits for frames exiting an Ethernet interface that supports trunking. For instance, R3 could mark CoS 5 on a frame it forwards out its FA 0/0 interface. Other Cisco router QoS tools can react to the marked CoS bits on incoming frames as well. For instance, R3 could mark packets entering its FA0/0 interface with a particular DSCP value based on the incoming CoS value. Later in this chapter, you will see a sample configuration for class-based marking that performs both of these functions.

Cisco switches vary widely regarding their capabilities to set CoS bits and react to previously marked CoS bits. Switches can support marking of CoS, and more often today support marking of IP precedence and DSCP as well. LAN switches that do support QoS features generally perform output queuing, and sometimes input queuing, choosing queues based on CoS values. Congestion avoidance using Weighted Random Early Detection (WRED) is another typical switch QoS feature. In addition, some switches support policing tools, also based on CoS. Chapter 9, “LAN QoS,” covers LAN QoS in additional depth.

You can use single-bit fields in Frame Relay and ATM networks to mark a frame or cell for Layer 2 QoS. Unlike IP precedence, IP DSCP, and 802.1P/ISL CoS, however, these two fields are not intended for general, flexible use. Each of these single-bit fields, when set, imply that the frame or cell is a better candidate to be dropped, as compared with frames or cells that do not have the bit set. In other words, you can mark the bit, but the only expected action by another QoS tool is for the tool to drop the frame or cell.

Frame Relay defines the discard eligibility (DE) bit, and ATM defines the cell loss priority (CLP) bit. The general idea is that when a device, typically a WAN switch, experiences congestion, it needs to discard some frames or cells. If a frame or cell has the DE or CLP bit set, respectively, the switch may choose to discard those frames or cells, and not discard other frames or cells. If the DE or CLP bit is set, there is no requirement that the Frame Relay and ATM switches react to it—just like there is no guarantee that an IP packet with DSCP EF will get special treatment by another router. It’s up to the owner of the Frame Relay or ATM switch to decide whether it will consider the DE and CLP bits, and how to react differently.

You can use two other QoS marking fields in specialized cases. The MPLS Experimental bits comprise a 3-bit field that you can use to map IP precedence into an MPLS label. Also, instead of simply mapping IP precedence to the MPLS Experimental field, you can perform CB Marking at the edge of the MPLS network, classifying on any of the fields mentioned in Tables 4-2, 4-3, and 4-4, and marking the appropriate MPLS experimental bits. This allows MPLS routers to perform QoS features indirectly based on the original IP Precedence field inside the IP packets encapsulated by MPLS, without the need to spend resources to open the IP packet header and examine the IP Precedence field.

Finally, the QoS Group field, an internal marking that exists only within the router, may be set as a packet passes through the fabric of a Cisco gigabit switch router (GSR) or edge services router (ESR). QoS processing can be performed more quickly inside the switching fabric by using the QoS group. Therefore, you may want to configure GSRs and ESRs to mark the QoS group on ingress so that QoS processing occurs more rapidly.

Not all these marked fields receive the same amount of attention on the QoS exams. Refer to the Introduction of this book, and the website suggested there, for the latest information about where to focus your attention. Table 4-6 summarizes the marking fields.

Table 4-6 Names of Marking Fields

Classification and marking tools provide many options, but sometimes sorting out the best way to use the tools can be difficult. Classification and marking tools can classify based on a large number of frame and packet header fields. They can also mark a number of fields, the most notable being the IP Precedence and DSCP fields. You can use the classification and marking tools on all routers in the network, on many LAN switches, and even on IP Phones and host computers. This brief section discusses some of the classification and marking design choices.

The first step in making good classification and marking design choices is to choose where to mark. The general rule for choosing where to mark is as follows:

Figure 4-5 diagrams a typical enterprise IP network, which will be used to look more closely at the options for where to mark packets.

Figure 4-5 Typical Enterprise Network

Consider packets that flow left to right in Figure 4-5. The marking efforts for data sent by the PC and phone on the left, up to R1, can be summarized as follows:

So marking can be done in many places near the ingress edge of the network—but whom do you trust? Classification and marking should not be performed before the frame/packet reaches a trusted device. This location in the network is called the trust boundary. For instance, Jessie formerly marked her packets with DSCP default, but because the user of the PC can change that value, Jessie changed to use DSCP EF to get better service. In most cases, the end-user PCs are beyond the trust boundary. IP Phones can reset CoS, Hannah’s traffic, and rely on the IP phone’s markings with CoS 5, precedence 5, and DSCP EF—with the added benefit that the phone user cannot reset those values. The IP Phone trust settings are controlled by the connected Cisco Catalyst switch, enabling the system administrator to trust markings received from the IP Phone while rewriting the CoS value received from the attached PC.

The final consideration when deciding where to mark involves the function of the various devices, and personal preferences. For instance, IP Phones provide three classes based on CoS—one for voice bearer traffic, one for voice signaling traffic, and one for all packets from the PC. However, a network may need multiple classes for data traffic, so further classification may be required by a switch or router. Some switches provide robust Layer 3 QoS classification and marking functions—in these cases, classification and marking may be performed on the switch; otherwise classification and marking must be performed on the router. (note: the classification and marking features on Cisco LAN switches are covered in chapter 9.) Figure 4-6 shows three typical paths for frames between the end-user device and the first router. The first instance shows a typical installation near the end users—a switch that performs only Layer 2 QoS, and PCs connected to it. Only Layer 2 QoS just means that the switch can react to, or possibly set, CoS, but it cannot react to or mark IP precedence or DSCP. In this case, classification and marking is typically performed as packets enter R1’s Ethernet interface. In addition, because SW1 can support CoS, but not precedence or DSCP, R1 may want to map incoming CoS values to the Precedence or DSCP fields.

Figure 4-6 Three Classification and Marking Placement Strategies

The second part of Figure 4-6 shows a network with a Layer 3 QoS-capable switch. Depending on the type of switch, this switch may not be able to perform Layer 3 switching, but it does have the capability to react to or mark IP precedence or DSCP. In this case, you should classify and mark on the switch. Classification and marking on the Layer 3 switch allows classification and marking closer to the trust boundary of the network, and offers the added benefits of queuing, congestion avoidance, and policing based on the marked values. If only a few sites in the network have Layer 3 QoS-capable switches, you may prefer to perform classification and marking on the router, so all sites’ configurations are similar. However, classifying and marking in the router places additional overhead on the router’s CPU.

Finally, the third example shows a PC cabled through an IP Phone to a Layer 3 QoS-capable switch. The IP Phone can easily take care of classification and marking into two categories—voice and nonvoice. The switch and router can take advantage of those marked values. If more classes are needed for this network’s QoS policy, SW3, or R3, can perform classification and marking. Of course, if the QoS policy for this network only requires the three classes—one for voice bearer traffic, one for voice signaling traffic, one for nonvoice—and all PCs are connected through the switch in the IP Phone, no classification and marking is needed on SW3 or R3!

Figure 4-7 summarizes some of the design options for where to classify and mark, showing the remote site from Figure 4-5.

Figure 4-7 Classification and Marking Options Applied to a Typical Enterprise Network

The choices of where to perform classification and marking can be summarized as follows:

Typically, when the packet makes it to the first WAN router, the initial marking has occurred. However, there may be other instances where marking should take place. Consider Figure 4-8, which shows several additional options for where marking can occur.

Figure 4-8 Classification and Marking Options—Typical Enterprise WAN

Most QoS tools can classify based on IP precedence and DSCP. However, the Frame Relay or ATM switches can also react to the DE and CLP bits, respectively. Therefore, you might want to set DE or CLP for the least-important traffic. If the LAN switches connected to R3 react to CoS settings, but not precedence or DSCP, which is typical of switches that only support Layer 2 QoS, you might want to mark the CoS bits on R3 before sending frames onto the Ethernet.

Finally, when you do mark CoS, IP precedence, and IP DSCP, what values should you use? Well, the “bigger is better” attitude is suggested for CoS and precedence. The DiffServ RFCs make recommendations for which markings to use for certain types of traffic, and most current Cisco products (as of publication date) use those recommendations. For instance, the DiffServ RFC’s suggest marking voice signaling traffic as AF31, and Cisco IP Phones indeed do that. Table 4-7 lists these recommended values.

Table 4-7 DiffServ RFC Recommended Values for Marking

The second major section of this chapter covers several Classification and Marking tools. First, Class-Based Marking will be covered in detail, followed by NBAR, which can be used by CB Marking to classify packets. Next, the text moves on to an explain some of the issues faced by CB Marking when tunnels are in use, and how IOS can be configured to still classify the packets correctly.

Class-Based Marking (CB Marking) Configuration

As with the other QoS tools whose names begin with the phrase Class Based, you use MQC commands to configure it. The logic used by CB Marking, now that you know the concepts, it is actually pretty straightforward:

1. Classify packets into service classes using the match command inside an MQC class map.

2. Mark the packets in each service class using the set command inside an MQC policy map.

3. Enable the CB Marking logic, as defined in a policy map, using the MQC service-policy command under an interface.

In Chapter 3, you read about the syntax of the MQC commands, and how policy maps use class maps to classify packets. Armed with that knowledge, you now only need to be reminded of all the fields with which you can match packets for classification using the MQC match command, and what fields you can mark with the MQC set command. Table 4-9 lists the options for the match command, which are applicable to all MQC QoS features. Table 4-10 lists the options on the set command, and Table 4-11 lists the show commands related to CB Marking. (Because the options for the match command are the same for all of the other MQC-based QoS tools inside a router, the rest of the chapters will refer back to Table 4-9 instead of repeating this same information in each chapter.)

Table 4-9 Match Configuration Command Reference for CB Marking

Table 4-10 set Configuration Command Reference for CB Marking

Table 4-11 EXEC Command Reference for CB Marking

You should read over the commands presented in the preceding tables to get familiar with the many options. However, you should not have to memorize all the options at this point. If you continue reading the chapters, and practice a little on real lab gear, you should be prepared for answering QoS exam questions.

QoS configuration should follow the process of planning the QoS policies for the network. After those policies have been defined, and the location of where to perform the marking functions has been determined, however, the CB Marking configuration that follows becomes an exercise in deciding how to match or classify the packets, and how to configure the commands correctly. In the first MQC configuration example, for example, the policy has been defined as follows:

Figure 4-9 is used for many example configurations in this book. In the first example, marking is performed for packets entering R3’s FA0/0 interface. In reality, it also makes sense to mark packets near R1 for packet flows from left to right in the figure. To keep the configurations less cluttered, however, only one direction, right to left, is shown. Example 4-1 lists the configuration for this first example.

Figure 4-9 CB Marking Sample Configuration 1

First, focus on the command prompts in Example 4-1. Note that the class-map command moves the CLI into class map configuration mode, with the prompt R3(config-cmap). The policy-map command moves the CLI into policy map configuration mode, and the class command that follows (not class-map, but just class) moves the CLI into an additional subconfiguration mode that has no specific name.

Next, examine the match commands. The solution could have referred to IP ACL 101 with the match ip access-group 101 command, with ACL 101 matching UDP ports between 16,384 and 32,767, inclusive, to match all VoIP traffic. However, the match ip rtp command matches only the even-numbered ports in this same UDP port range. (VoIP payload only uses the even port numbers.) Therefore, the match ip rtp command is more efficient for matching VoIP, easier to configure, and only matches the VoIP payload.

Continuing down the configuration, examine the policy-map set commands. The first command sets a DSCP of EF for all traffic that matches class-map voip-rtp. The other set command, which follows the class class-default command, sets DSCP of Default for traffic that matches the class-default class-map. In other words, the policy map sets DSCP EF for packets that match one class, and DSCP Default, using the keyword default, for the other class. IOS includes a class that matches all remaining traffic, called class-default, in every policy map. Although the command class class-default was not specified in the configuration, note that the class class-default command is automatically added to the end of a policy map to match all unspecified traffic. class-default was used in the policy map to match all remaining traffic and then mark that traffic as BE.

Finally, the service-policy command enables CB Marking for ingress packets with the service-policy input voip-and-be interface subcommand. When enabled, IOS applies the policy map classes in the order they appear in the policy-map command. In this example, for instance, the VoIP RTP class is used to examine the packet first; if a match appears, the packet is marked with DSCP EF. After the packet has been matched and marked, it exits the policy map. If no match occurs, only then is the next class, class-default, used to examine the packet.

The next example is a CB Marking configuration that uses the same network as the one used in Example 4-1. R3 is performing the CB Marking function again, but this time R3 expects that SW2 has already set CoS bits to either 0 or 5. The engineers in the meeting to discuss QoS policies for this network decided that SW2 would mark CoS with either 0 or 5, and then R3 would map CoS 0 to DSCP Default, and CoS 5 to DSCP EF. For packets moving left to right, R3 should map DSCP Default back to CoS 0, and DSCP EF back to CoS 5. Figure 4-10 depicts the network and QoS policies, and Example 4-2 lists the configuration.

Figure 4-10 CB Marking Sample Configuration 2

As you learned earlier in this chapter, to mark and classify CoS values, a VLAN trunking header must exist on the packet. On R3 in this example, subinterface Fast Ethernet 0/0.1 and subinterface Fast Ethernet 0/0.2 have been created and assigned to the voice VLAN 102 and the data VLAN 2, respectively, using 802.1Q trunking. This configuration creates an 802.1Q header for traffic in the voice VLAN 102, without creating a VLAN header for the data VLAN 2 traffic because VLAN2 will be the native VLAN on this trunk.

The QoS policy required two policy maps in this example. Policy map map-cos-to-dscp matched CoS values for frames entering R3’s FA 0/0.1 interface, and marked DSCP values, for packets flowing right to left in the figure. Therefore, the policy map was enabled on input of R3’s FA 0/0.1 interface. Policy map map-dscp-to-cos matched DSCP values on packets exiting R3’s FA 0/0.1 interface, and marked CoS, for packets flowing left to right in the figure. Therefore, the policy map was enabled on output of R3’s FA 0/0.1 interface. Neither policy map could be applied on the WAN interface, because only interfaces configured for 802.1Q accept service-policy commands that reference policy maps that either classify or mark based on CoS.

Note that you cannot enable a policy map that refers to CoS on interface FA0/0.2 in this example. That subinterface is in the native VLAN, meaning that no 802.1Q header is used. In a real network, you would probably want to enable a policy map on the subinterface in order to mark traffic, but it must classify based on something beside CoS.

Network-Based Application Recognition (NBAR)

CB Marking, and other MQC-based tools, can use NBAR to help classify traffic. By using the match protocol class map subcommand, MQC can match protocols recognized by NBAR. This section describes how to configure CB Marking using NBAR for classification.

The connection between NBAR and CB Marking, or any other MQC tool, is through the match protocol class map subcommand. An MQC tool can include the match protocol command under a class-map command, and as a result, IOS uses NBAR to actually match the packets.

A sample configuration and statistical display may help you make sense of NBAR. Tables 4-12 and 4-13 list the NBAR configuration and exec commands, respectively. Following the tables, Figure 4-11 diagrams the familiar network, where R3 performs CB Marking based on NBAR classification of the URL string. Finally, Example 4-3 lists a sample NBAR and CB Marking configuration, where CB Marking matches a portion of an HTTP URL. The example includes a listing of NBAR statistics gathered on the interface.

Table 4-12 Configuration Command Reference for NBA

Table 4-13 EXEC Command Reference for NBAR

CB Marking provides only one show command that provides statistical information: show policy-map interface. The statistics do provide some good insight to the packet volumes being marked by CB Marking. The next sample configuration includes a new configuration and several variations of the show policy-map command.

The same network is used for the next example as was used in the other CB Marking examples, but with different marking criteria. In this case, traffic is generated so that the show command output is more meaningful. The following traffic is generated:

Figure 4-12 depicts the same familiar network, and lists the criteria in with the figure for easy reference.

Figure 4-12 Three Classification and Marking Placement Strategies

The new criteria for Example 4-4 is as follows:

Example 4-4 shows the configuration, including the appropriate show commands.

Review the configuration before taking a closer look at the show commands. The only part of the configuration that was not covered in the first three examples on CB Marking is the matching of the Microsoft NetMeeting traffic. NetMeeting uses RTP for the video flows, and by default uses G.723 for audio and H.323 for video. To match both the audio and video for NetMeeting, a class map that matches either of the two RTP payload subtypes for G.723 and H.323 is needed. So, the NetMeet class map uses match-any logic, and matches on RTP payload types 4 (G.723) and 34 (H.323).

Also note that the NetMeet class map uses a combination of capital letters and lowercase letters, as does the class command that refers to it. Class map names are case sensitive—you may want to choose to use only uppercase or lowercase letters for names to avoid confusion.

The show policy-map laundry-list command just lists a summary of the configuration. You can gather the same information with a show running-config command, but it is summarized nicely with show policy-map. The show policy-map command lists the same configuration information, but it lists the information for all the configured policy maps in this router.

The show policy-map command using the interface option provides statistical information about the number of packets and bytes that have matched each class inside the policy maps. Because CB Marking is configured, it also notes the number of packets that have been marked. You can select all interfaces, just one interface, either input or output, and even select a single class inside a single policy map for display.

Finally, the load-interval interface subcommand can also be useful when looking at any QoS tool’s statistics. The load-interval command defines the time interval over which IOS measures packet and bit rates on an interface. With a lower load interval, the statistics change more quickly; with a larger load interval, the statistics change more slowly. In a lab when you are just learning to use QoS tools, set the load interval to the minimum of 30 seconds, so you can see the results of new traffic, or changes to the configuration, quickly. (The default setting is 5 minutes.)

The examples in this chapter highlight just some of the features of CB Marking, while the list of classification and marking options in Tables 4-9 and 4-10 provides a lot of details. This final section on CB Marking highlights some of the more important small features of CB Marking that so far have only been mentioned as part of the generic commands in Tables 4-9 and 4-10.

The class-map command actually has two optional keywords after the name of the class map, namely match-any and match-all. If you need to refer to multiple match criteria inside a class map, you can use multiple match subcommands. These two keywords can then be used to specify whether all matches must be true (match-all) or if just one needs to be true (match-any). match-all is the default.

The match subcommand under class-map can be used to match up to four IP Precedence values in one command. For instance, match ip precedence 0 1 2 matches packets with any of the three values. Similarly, up to eight DSCP values can be matched with the match ip dscp command, and up to four CoS values can be matched in one match cos command.

Another small but interesting feature is the match not command. Inside a class-map, you can use match not to match all packets that do not match the remaining criteria in the command. For instance, to match packets that are not permitted by ACL 153, you could use the match not access-group 153 command. You could of course just change the ACL to do the opposite of what it was matching originally, but in some cases, it might be more convenient to use match not. For instance, if you might want two classes—one for packets that match ACL 153, and one for those that do not.

All the CB Marking examples in this chapter show a single field being set by a policy map. However, you can actually mark multiple fields in the same policy map for the same packet. For instance, you might want to classify voice payload traffic, and mark it with DSCP EF. However, if the policy map will be enabled for outgoing traffic on a FastEthernet interface that trunks, you might also want to set the CoS field as well. To mark both, you would use two set commands under a single class command. For instance, inside class voice, you might see the commands set ip dscp ef and set cos 5.

If you have a spare router, it’s a good idea to spend some time experimenting and getting familiar with the many options available with CB Marking, particularly with the match and set commands.

Virtual private networks (VPNs) provide a way for Enterprise networks to create a network in which packet contents are kept private, but the packets actually flow over the public Internet. To create a private VPN over a public Internet, VPN hardware or software encapsulates the private IP packets into another IP packet, typically encrypting the original IP packet in order to maintain privacy.

This short section points out a few of the challenges associated with QoS classification in the presence of VPNs.

Classification and Marking Before Entering the VPN Tunnel

In the earlier sections of this chapter, you read about the many things that Class-Based Marking can examine in order to classify a packet. However, once a packet has been encapsulated and probably encrypted as part of a VPN, those header fields are no longer available for examination. Figure 4-13 depicts a typical site-to-site VPN environment, using IPSEC tunnels:

Figure 4-13 Typical Site-to-Site IPSEC VPN

Figure 4-13 shows a router at each Enterprise site performing the encapsulation and encryption of the packets. The routers inside the ISP network see an IP header, but it’s not the original IP header. Also, the original IP and TCP header in this example are part of the encrypted payload, making the packet unavailable to routers inside the ISP network. The application headers that NBAR can examine are also encrypted when the packet passes through the ISP. In short, the only thing that the ISP routers can examine are the VPN-created IP headers.

Thankfully, with a good classification and marking strategy, QoS can be extended into the ISP network, even with VPNs in use. When a Cisco router performs the VPN functions, for instance, IPSEC tunnel mode, the router copies the ToS byte from the original IP packet into the newly-created IP header. With proper classification and marking before the packet enters the VPN tunnel, the ISP will at least be able to look at the ToS byte, which includes the DSCP and ECN fields, in order to perform QoS functions. Figure 4-14 depicts the general idea.

Figure 4-14 Cisco IOS VPN Copies Original ToS Byte

Without any overt action or configuration (beyond configuring VPN features as always) IOS copies the ToS byte to the new IP header. That’s true whether using IPSec transport mode, tunnel mode, GRE tunnels, or any of the other Cisco IOS VPN features. So if an enterprise marks a packet with a DSCP value before sending it over a VPN connection, the ISP routers at least have the opportunity to examine the DSCP value to perform QoS functions.

Note    IPSec uses either tunnel mode, where the original IP header is encrypted, and transport mode, where the original IP header is not encrypted. With tunnel mode, the original IP ToS byte is copied into the encapsulating IP header; with transport, the original ToS byte is not encrypted, and can be examined by QoS mechanisms. Regardless, the original ToS byte information is referencable by the QoS tools.

Classification and Marking on the Router Creating the VPN Tunnel

VPN tunnel encapsulation and encryption can be done by routers, firewalls, software on a PC, or specialized VPN hardware, like the Cisco 3000 series VPN concentrators. This section of the book looks at a specific implementation issue when performing VPN functions in a Cisco router.

Figure 4-14 depicted the original IP packet being encapsulated, encrypted, and copying the original ToS byte into the new IP header. A router performs these steps after the packet is received, but before the packet is forwarded to the outgoing interface. Once the new VPN packet has been created, the packet is then forwarded to the correct outgoing interface, based on the routing table, and transmitted. As a result, the following general statements can be made:

   Packets entering a router interface, not yet in a VPN tunnel, can be processed with ingress QoS features on that interface just like always.

   Packets exiting a router interface, after encapsulation and encryption by that router into a VPN tunnel, cannot be processed with egress QoS features on that interface just like always. The Egress QoS features can only examine the post-encapsulation IP header.

In many cases, these points do not matter a lot. You already know that the DSCP is copied into the new VPN IP header, and effective marking of DSCP before the packet is encapsulated might be all you need to do. However, in some cases, you might want to perform QoS features at egress on some interface, and you might simply want to be able to look at fields inside the original IP packet.

Cisco IOS includes a feature called QoS Pre-classification, just for this specific case. On routers that are VPN endpoints, you can configure the router such that it can refer to the original packet headers for QoS decisions, even seemingly after the original packet has been encapsulated and encrypted.

The QoS Pre-classification feature does allow the router that encapsulates and encrypts the original packet into the tunnel to look at the original headers for QoS functions. This feature does not, however, allow the ensuing routers to be able to look at the original headers—they are indeed encrypted. Internally, in the router performing the encapsulation and encryption, IOS keeps the original unencrypted packet in memory until the QoS actions have been taken.

Figure 4-15 summarizes the behavior of a router in terms of when it can and can’t look at the original headers for QoS features, based on the presence or absence of QoS Pre-classification:

Figure 4-15 Locations Where the Original Classifications Fields are and are not Available

Keep in mind that this feature applies only to the router performing the encapsulation and not other routers. Also, the ToS byte is copied from the original IP header to the encapsulating VPN header automatically as a totally separate and unrelated feature.

Configuring QoS Pre-classification

Configuring QoS Pre-classification is relatively simple. First, the command to enable it is qos pre-classify. The only hard part is knowing where to use the command. With IOS, depending on the type of VPN tunnel being created, you might use one of three general styles of configuration. Table 4-14 lists the modes in which you might type the commands, according to the type of VPN configured:

Table 4-14 Rules for Where to Configure the qos pre-classify command

Although the configuration is simple, a few example commands can help. Figure 4-16 shows a sample network, with two remote sites connecting through an ISP. R4 and R1 have been configured such that IPSEC is used when someone at R4’s branch Telnets to R1’s Loopback IP address (10.1.1.1). Figure 4-16 depicts the network, and Example 4-5 that follows shows the configuration on R4, as well as some show commands.

Figure 4-16 Site-to-Site VPN for Telnet Traffic: QoS Pre-classify

This book attempts to cover the breadth and depth of QoS as covered on the QoS exam (642-642). However, you may want to read more about topics in this chapter, or other classification and marking topics.

For more on the topics in this chapter:

For more on other Classification and Marking topics:

For design related guidance:

As mentioned in the Introduction, you have two choices for review questions. The questions that follow next give you a more difficult challenge than the exam itself by using an open-ended question format. By reviewing now with this more difficult question format, you can exercise your memory better, and prove your conceptual and factual knowledge of this chapter. You can find the answers to these questions in Appendix A.

The second option for practice questions is to use the CD-ROM included with this book. It includes a testing engine and more than 200 multiple-choice questions. You should use this CD-ROM nearer to the end of your preparation, for practice with the actual exam format. You can even customize the CD-ROM exam to include, or not include, the topics that are only on the CCIP QoS.