Class Based Marking CB Marking

Cisco added CB marking to IOS after all the other classification and marking tools discussed in this book. As of IOS 12.1(5)T and 12.2 mainline, CB marking represents the only classification and marking tool specifically intended for the classification and marking function. NBAR, CAR, PBR, and dial peers have other purposes, whereas CB marking focuses entirely on classification and marking.

You must use a new IOS syntax called the Modular QoS command-line interface (MQC) to configure CB marking. After hearing of the term MQC for the first time, many people think that Cisco has created a totally new CLI, different from IOS configuration mode, to configure CB marking. In reality, MQC defines a new set of configuration commands—commands that are typed in using the same IOS CLI, in configuration mode. So, why bother to name these new commands with the term "MQC?" Well, newer IOS QoS tools, as well as future IOS QoS tools, and to some degree older QoS tools, will all use the same MQC commands for QoS configuration in the future. Instead of more than 30 IOS QoS tools, each with different configuration commands, the commands will slowly converge to use the MQC commands. Therefore, MQC is really more of a standard for new and revised configuration commands for QoS features.

All IOS QoS tools that begin with the phrase "class based" use the MQC commands as of IOS 12.2 mainline. These tools include CB marking, CB Weighted Fair Queuing (CBWFQ), CB policing, and CB shaping. Most QoS tools need to perform classification functions; all MQC supporting tools use the same commands for classification. The person configuring the router only needs to learn one set of commands for classification for all four of these tools, which reduces effort and reduces mistakes.

MQC separates the classification, per-hop behavior (PHB), and enabling functions into three separate commands. The class-map command defines the matching parameters for classifying packets. Because different tools create different PHBs, the PHB actions (marking, queuing, and so on) are configured under a policy-map command. Finally, because these tools operate on packets that either enter or exit an interface, the policy is then enabled on an interface using a service-policy command. Figure 3-9 shows the general flow of commands.

Figure 3-9 MQC Commands and Their Correlation

Classification Configuration

Action/PHB Configuration

Enable on Interface

Class-map myclass1 -

(matching parameters follow ...) Class-map myclass2

(matching parameters follow ...)

Policy-map mypolicy^-class myclass1

(Actions/PHB's FOR THIS CLASS follow: marking, queuing, etc.) class myclass2

(Actions/PHB's FOR THIS CLASS follow: marking, queuing, etc.) Interface S 0/0

service-policy output mypolicy-^-

In this example, the network's QoS policy calls for two classes of packets. (The actual types of packets that are placed into each class are not shown, just to keep the focus on the general flow of how the main commands work together.) To classify packets into two classes, two class-map commands are used. Each class-map would be followed by a match subcommand, which defines the actual parameters compared to packet header contents to match packets for classification. For each class, some QoS action needs to be applied—but configuration for these actions is made under the policy-map command. Under a single policy map, multiple classes will be referenced—two classes in this example, myclass1 and myclass2. Inside the single policy called mypolicy, under each of the two classes myclass1 and myclass2, you can configure separate QoS actions. For instance, you could apply different marking to packets in class myclass1 and myclass2 at this point. Finally, when the service-policy command is applied to an interface, the QoS features are enabled.

MQC provides some good advantages when compared to building each QoS tool with different sets of configuration commands. In many cases, you will use multiple policies in one router, but you need the same classifications. For instance, you might apply slightly different queuing parameters to five different serial links, but because packets have already been marked near the ingress edge of the network, all the classification logic is the same in each case. Therefore, all five policy maps could refer to the same class maps for classification purposes. With multiple tools sharing the same commands, QoS configuration becomes less confusing. Learning how to configure a new MQC QoS tool will be easy as well—for instance, when you know how to configure CB marking, you only need to learn one more command to learn how to configure CBWFQ!

Several specific examples appear over the next several pages. First, Table 3-7 lists the MQC commands used for CB marking. The table shows all the classification options available using the match command, and all the marking options available using the set command. Table 3-8 lists the show commands related to CB marking.

Table 3-7 Command Reference for CB Marking

Command

Mode and Function

class-map class-map-name

Global config; names a class map, where classification options are configured

Match ...

Class-map subcommand; defines specific classification parameters

match access-group {access-group | name access-group-name}

Class-map subcommand; matches an ACL

match source-address mac address-destination

Class-map subcommand; matches a source MAC address

match ip precedence ip-precedence-value [ip-precedence-value ip-precedence-value ip-precedence-value]

Class-map subcommand; Matches an IP precedence value

continues continues

Table 3-7 Command Reference for CB Marking (Continued)

Command

Mode and Function

match mpls experimental number

Class-map subcommand; matches an MPLS Experimental value

match cos cos-value [cos-value cos-value cos-value]

Class-map subcommand; matches a CoS value

match destination-address mac address

Class-map subcommand; matches a destination MAC address

match input-interface interface-name

Class-map subcommand; matches an input interface

match ip dscp ip-dscp-value [ip-dscp-value ip-dscp-value ip-dscp-value ip-dscp-value ip-dscp-value ip-dscp-value ip-dscp-value]

Class-map subcommand; matches an IP DSCP value

match ip rtp starting-port-number port-range

Class-map subcommand; matches the RTP's UDP port-number range

match qos-group qos-group-value

Class-map subcommand; matches a QoS group

match protocol protocol-name

Class-map subcommand; matches NBAR protocol types

match protocol citrix app application-name-string

Class-map subcommand; matches NBAR Citrix applications

match protocol http [url url-string | host hostname-string | mime MIME-type]

Class-map subcommand; matches a host name and URL string

match any

Class-map subcommand; matches all packets

policy-map policy-map-name

Global config; names a policy, which is a set of actions to perform

class class-name

Policy-map subcommand; identifies which packets on which to perform some action by referring to the classification logic in a class map

set

Class subcommand; for the class, marks (sets) particular QoS fields

set ip precedence ip-precedence-value

Class subcommand; set the value for IP precedence

set ip dscp ip-dscp-value

Class subcommand; set the value for IP DSCP

Table 3-7 Command Reference for CB Marking (Continued)

Command

Mode and Function

set cos cos-value

Class subcommand; set the value for CoS

set ip qos-group group-id

Class subcommand; set the value for the QoS group

set atm-clp

Class subcommand; set the value for the ATM CLP bit

set fr-de

Class subcommand; set the value for the Frame Relay DE bit

Table 3-8 Exec Command Reference for CB Marking

Command

Function

show policy-map policy-map-name

Lists configuration information about all MQC-based QoS tools

show policy-map interface-spec [input | output] [class class-name]

Lists statistical information about the behavior of all MQC-based QoS tools

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:

• All VoIP traffic should be marked with DSCP EF.

• All other traffic should be marked with DSCP Default.

Figure 3-10 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 3-1 lists the configuration for this first example.

Figure 3-10 CB Marking Sample Configuration 1

Figure 3-10 CB Marking Sample Configuration 1

Example 3-1 CB Marking: Sample 1 Configuration

R3#conf t

Enter configuration commands, one per line. End with CNTL/Z. R3(config)#ip cef R3(config)#!

R3(config)#class-map voip-rtp R3(config-cmap)#match ip rtp 16384 16383 R3(config-cmap)#policy-map voip-and-be R3(config-pmap)# class voip-rtp R3(config-pmap-c)# set ip DSCP EF R3(config-pmap-c)# class class-default R3(config-pmap-c)# set ip dscp default R3(config-pmap-c)#interface e 0/0 R3(config-if)# service-policy input voip-and-be R3(config-if)#end R3#

R3#show running-config

Example 3-1 CBMarking: Sample 1 Configuration (Continued)

Building configuration... !Portions removed to save space... ip cef !

class-map match-all voip-rtp match ip rtp 16384 16383

policy-map voip-and-be class voip-rtp set ip dscp 46 class class-default set ip dscp 0

interface Fastethernet0/0 description connected to SW2, where Serverl is connected ip address 192.168.3.253 255.255.255.0 service-policy input voip-and-be

First, focus on the command prompts in Example 3-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.

NOTE I tend to call configuration mode you are in after using the policy-map command, and then the class command, the policy-map class mode when teaching QoS classes.

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. The other match command, match any, does exactly that: It matches anything.

Class maps allow multiple match commands in a single class-map command. You may have noticed the match-all parameter on the class-map output from show run; IOS added the match-all parameter, even though it was not typed in. If a class-map command has multiple match commands, with the default setting of match-all, all the match commands must match a packet before the packet is considered to be part of the class. The other alternative is to configure the keyword match-any, which means that if one or more of the match commands in a single class map matches a packet, the packet is part of that class.

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.

Consider two caveats before moving on to more examples. First, examine the output of the show run command in Example 3-1, and look for the set commands. The MQC enables you to type in the text names of the DSCP values, but IOS records the configuration using the decimal version of the DSCP value! Therefore, you may need a handy reference for the actual DSCP values, as is shown in Table 3-4.

The other caveat only occurs if you already know how to configure Frame Relay traffic shaping (FRTS). FRTS uses a command called map-class. Many people who know how to configure map-class first look at any MQC-based tool, see the class-map command, and don't realize that the commands are indeed two totally different commands. So, ignore all you have learned about FRTS until you learn about MQC configurations using the class-map command.

The next example is a CB marking configuration that uses the same network as the one used in Example 3-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 3-11 depicts the network and QoS policies, and Example 3-2 lists the configuration.

Figure 3-11 CB Marking Sample Configuration 2

Figure 3-11 CB Marking Sample Configuration 2

For packets Exiting Ethernet:

Map IP DSCP Default to CoS 0 Map IP DSCP EF to CoS 5

VLAN 2

For packets Exiting Ethernet:

Map IP DSCP Default to CoS 0 Map IP DSCP EF to CoS 5

VLAN 2

Example 3-2 CB Marking: Sample 2 Configuration

Example 3-2 CB Marking: Sample 2 Configuration (Continued)

class cos5

set ip DSCP EF class class-default set ip dscp default

policy-map map-dscp-to-cos class BE

set cos 0 class EF

set cos 5 class class-default set cos 0

interface FastEthernet0/0

interface FastEthernet0/0.1 encapsulation dot1Q 102 service-policy input map-cos-to-dscp service-policy output map-dscp-to-cos

interface FastEthernet0/0.2 encapsulation dot1Q 2 native

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.

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.

Advance SEO Techniques

Advance SEO Techniques

Turbocharge Your Traffic And Profits On Auto-Pilot. Would you like to watch visitors flood into your websites by the 1,000s, without expensive advertising or promotions? The fact is, there ARE people with websites doing exactly that right now. How is that possible, you ask? The answer is Advanced SEO Techniques.

Get My Free Ebook


Post a comment