Home > Articles > Certification > Cisco Certification

  • Print
  • + Share This
This chapter is from the book

Classification and Marking Tools

Three classification and marking tools provide the multifield classifier function of DiffServ—namely, class-Based marking (CB marking), committed access rate (CAR), and policy-based routing (PBR). All three tools enable you to configure matching parameters for a wide variety of fields in a packet header.

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 09Figure 3-9 MQC Commands and Their Correlation

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

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

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 10Figure 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
Building configuration...

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 Server1 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 11Figure 3-11 CB Marking Sample Configuration 2


Example 3-2 CB Marking: Sample 2 Configuration

class-map cos0
 match cos 0
!
class-map cos5
 match cos 5
!
class-map BE
 match ip dscp default
!
class-map EF
 match ip dscp EF
!
policy-map map-cos-to-dscp
 class cos0
 set ip DSCP default
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.

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 NBAR, and includes examples of CB marking with NBAR.

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, just could not classify the traffic. NBAR can look past the UDP and TCP header, looking at the host name, URL, or MIME type in HTTP requests. NBAR can also look past the TCP and UDP headers to recognize application-specific information. For instance, NBAR allow recognition of different Citrix application types, and allows for searching for a portion of a URL string.

NBAR uses the classification information for two purposes. NBAR, without the help of other IOS features, can classify these difficult-to-classify protocols for the purpose of gathering statistics about the protocols. In fact, NBAR by itself provides classification and statistics, but no marking. NBAR also provides classification help for other QoS tools. Specifically, all MQC tools can refer to NBAR classifications for matching traffic.

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. To do so, NBAR must be enabled on the same interface on which the class map is indirectly enabled through the service-policy interface subcommand.

A sample configuration and statistical display may help you make sense of NBAR. Tables 3-9 and 3-10 list the NBAR configuration and exec commands, respectively. Following the tables, Figure 3-12 diagrams the familiar network, where R3 performs CB marking based on NBAR classification of the URL string. Finally, Example 3-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.

Figure 12Figure 3-12 CB Marking Sample Configuration 3


Table 3-9 Configuration Command Reference for NBAR

Command

Mode and Function

ip nbar protocol-discovery

Interface mode; enables NBAR for traffic entering the interface.

ip nbar port-map protocol-name [tcp | udp] port-number

Global; tells NBAR to search for a protocol using a different port number than the well-known port. Also defines ports to be used by custom packet description language modules (PDLMs).

ip nbar pdlm pdlm-name

Global; extends the list of protocols recognized by NBAR by adding additional PDLMs.


NOTE

You can download additional PDLMs from Cisco.com:

http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm

Table 3-10 Exec Command Reference for NBAR

Command

Function

show ip nbar protocol-discovery [interface interface-spec] [stats {byte-count | bit-rate | packet-count}][{protocol protocol-name | top-n number}]

Lists information about statistics for the discovered protocols. Statistics can be listed by interface, by protocol, or for just the top n protocols by volume.

show ip nbar port-map [protocol-name]

Lists the current ports in use by the discovered protocols.


Example 3-3 uses the following criteria for marking packets:

  • Any HTTP traffic whose URL contains the string "important" anywhere in the URL is marked with AF21.

  • Any HTTP traffic whose URL contains the string "not-so" anywhere in the URL is marked with DSCP default.

  • All other traffic is marked with AF11.

Example 3-3 shows the configuration.

Example 3-3 Sample 3: CB Marking Based on URLs, Using NBAR for Classification

ip cef
!
class-map http-impo
 match protocol http url "*important*"

!
class-map http-not
 <Anchor1>match protocol http url "*not-so*"

!
class-map all-else
 match any
!
policy-map http
 class http-impo
 set ip dscp AF21
!
 class http-not
 set ip dscp default
!
 class class-default
 set ip DSCP AF11
!
interface fastethernet 0/0
 ip nbar protocol-discovery
 service-policy input http
!
!

R3# show ip nbar protocol-discovery top-n 5

FastEthernet0/0
                           Input                    Output
  Protocol                 Packet Count             Packet Count
                           Byte Count               Byte Count
                           5 minute bit rate (bps)  5 minute bit rate (bps)
  ------------------------ ------------------------ ------------------------
  eigrp                    76                       0
                           5624                     0
                           0                        0
  bgp                      0                        0
                           0                        0
                           0                        0
  citrix                   0                        0
                           0                        0
                           0                        0
  cuseeme                  0                        0
                           0                        0
                           0                        0
  custom-01                0                        0
                           0                        0
                           0                        0
  unknown                  5610                     0
                           5665471                  0
                           135000                   0
  Total                    5851                     0
                           5845277                  0
                           135000                   0

R3#show ip nbar protocol-discovery interface fastethernet 0/0 stats packet-count top-n 5

FastEthernet0/0
                           Input                    Output
  Protocol                 Packet Count             Packet Count
  ------------------------ ------------------------ ------------------------
  http                     721                      428
  eigrp                    635                      0
  netbios                  199                      0
  icmp                     1                        1
  bgp                      0                        0
  unknown                  46058                    63
  Total                    47614                    492           

Notice that the class map configuration does not specifically use the term NBAR. Two class maps, http-impo and http-not, use the match command, with the protocol keyword, which implies that the actual classification uses NBAR. NBAR has been enabled on FA0/0 with the ip nbar protocol discovery command—had NBAR not been enabled, the service-policy command would have been rejected. Also note that CEF forwarding must be enabled, using the ip cef global command, before NBAR will work.

NBAR can match URLs exactly, or with some wildcards. You can use the asterisk (*) to match any characters of any length. In this case, as long as the phrases "important" or "not-so" appear in the URL, the packets are matched by one of the two class maps, respectively. Interestingly, when downloading an object with HTTP, the URL does not flow in every packet. When classifying based on URL, NBAR matches all packets beginning with the matched URL, and then until another HTTP request for another URL flows inside the same TCP connection.

The show ip nbar protocol-discovery command lists statistics for NBAR-classified packets. However, just using that command in live networks does not help much, because it lists three lines of output per type of protocol that can be discovered by NBAR—not just the protocols NBAR actually discovered. Therefore, the optional parameters on the command are more useful. For instance, both commands shown in the preceding example use the top-n parameter to limit the output based on the highest-volume protocols. The show command can also limit the statistics for a single interface, or it can limit the statistics to just packet count, or byte count, or bit rate.

Unlike most other IOS features, you can upgrade NBAR without changing to a later IOS version. Cisco uses a feature called packet descriptor language modules (PDLMs) to define new protocols that NBAR should match. When Cisco decides to add one or more new protocols to the list of protocols that NBAR should recognize, it creates and compiles a PDLM. You can then download the PDLM from Cisco, copy it into Flash memory, and add the ip nbar pdlm pdlm-name command to the configuration, where pdlm-name is the name of the PDLM file in Flash memory. NBAR can then classify based on the protocol information from the new PDLM.

CB Marking show Commands

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:

  • Two G.711 VoIP calls between R4 and R1 using Foreign Exchange Station (FXS) cards on these two routers. Voice Activation Detection (VAD) is disabled.

  • One FTP connection from the client PC to the server, with an FTP get of a 40-MB file called big.zip.

  • One Microsoft NetMeeting video/audio conference between the client and server.

  • One web page download from the server to the client. The web page has a few small objects. The web page includes two panes, each with a different JPG file: one called important.jpg; the other called not-so.jpg. The JPGs are exact copies of each other, and each JPG is 687 KB. In later examples, the differing performance of the download of these examples is used to demonstrate the behavior of other QoS tools.

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

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

Figure 13Figure 3-13 Three Classification and Marking Placement Strategies

  • VoIP payload is marked with DSCP EF.

  • NetMeeting voice and video from Server 1 to Client 1 is marked with DSCP AF41.

  • Any HTTP traffic whose URL contains the string "important" anywhere in the URL is marked with AF21.

  • Any HTTP traffic whose URL contains the string "not-so" anywhere in the URL is marked with AF23.

  • All other traffic is marked with DSCP Default.

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

Example 3-4 CB Marking Sample 4, with show Command output

ip cef
!
interface fastethernet 0/0
 ip nbar protocol-discovery
!
access-list 101 permit udp host 192.168.3.101 gt 16383 192.168.1.0 0.0.0.255 gt 16383
!
class-map voip-rtp
 match ip rtp 16384 16383
!
class-map http-impo
 match protocol http url "*important*"
!
class-map http-not
 match protocol http url "*not-so*"
!
class-map NetMeet
 match access-group 101
!
policy-map laundry-list
! 
 class voip-rtp
 set ip dscp EF
!
 class NetMeet
 set ip dscp AF41
! 
class http-impo
 set ip dscp AF21
!
 class http-not
 set ip dscp AF23
!
 class class-default
 set ip DSCP default
!
 interface Fastethernet 0/0
 service-policy input laundry-list
end

R3#show policy-map
 Policy Map laundry-list
  Class voip-rtp
   set ip dscp 46
  Class NetMeet
   set ip dscp 34
  Class http-impo
   set ip dscp 18
  Class http-not
   set ip dscp 22
  Class class-default
   set ip dscp 0

R3#show policy-map laundry-list
 Policy Map laundry-list
  Class voip-rtp
   set ip dscp 46
  Class NetMeet
   set ip dscp 34
  Class http-impo
   set ip dscp 18
  Class http-not
   set ip dscp 22
  Class class-default
   set ip dscp 0
R3#show policy-map interface fastethernet 0/0 input
 Fastethernet0/0

Service-policy input: <Anchor2>laundry-list

  Class-map: voip-rtp (match-all)
   35268 packets, 2609832 bytes
   5 minute offered rate <Anchor3>59000 bps, drop rate 0 bps

   Match: ip rtp 16384 16383
   QoS Set
    ip dscp 46
     <Anchor4>Packets marked 35268

  Class-map: NetMeet (match-all)
   817 packets, 328768 bytes
   5 minute offered rate 19000 bps, drop rate 0 bps

   Match: access-group 101
   QoS Set
    ip dscp 34
     Packets marked 817

  Class-map: http-impo (match-all)
   2843 packets, 3462611 bytes
   5 minute offered rate >56000 bps, drop rate 0 bps

   Match: protocol http url "*important*"
   QoS Set
    ip dscp 18
     Packets marked 2855


  Class-map: http-not (match-all)
   2828 packets, 3445409 bytes
   5 minute offered rate <Anchor9>56000 bps, drop rate 0 bps

   Match: protocol http url "*not-so*"
   QoS Set
    ip dscp 22
      Packets marked 2842


  Class-map: class-default (match-all)
   33216 packets, 43649458 bytes
   5 minute offered rate <Anchor11>747000 bps, drop rate 0 bps

   Match: any
   QoS Set
    ip dscp 0
     Packets marked 33301

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 audio and video flows. ACL 101 matches all UDP port numbers over 16,384, for traffic from Server 1 going to the client. This may catch other traffic besides NetMeeting, but it definitely catches all the NetMeeting traffic. 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 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.)

CB Marking Summary

Class-based marking provides the most functional general classification and marking tool in IOS, as of IOS 12.2 mainline. Class-based marking provides the largest number of fields for classifying packets, and the largest number of fields that can be marked. It uses MQC for configuration, separating the classification details from the QoS action.

Refer to Table 3-17, in the "Foundation Summary" section of this chapter, for a complete list of classification and marking fields used by CB marking.

Committed Access Rate (CAR)

CAR provides policing functions and marking. Chapter 5, "Traffic Policing and Shaping," covers the policing details of CAR and CB policing. However, a quick review of policing before getting into CAR's marking features will help you appreciate why CAR includes marking.

Policing, in its most basic form, discards traffic that exceeds a particular traffic contract. The contract has two components: a rate, stated either in bits per second or bytes per second; and a burst size, stated in either bits or bytes. The traffic conforms to the contract if it sends at the rate, or below, and it does not send a burst of traffic greater than the burst size. If the traffic exceeds the traffic rate over time, or exceeds the single burst size limit, the policing function drops the traffic in excess of the rate and the burst size. Therefore, the simplest form of policing has two rigid actions: either to forward packets or to drop them.

CAR's marking function allows for additional policing action besides just forwarding or dropping a packet. Consider a typical case where policing is used, as in Figure 3-14. ISP1 needs to police traffic to protect customers who conform to their contracts from congestion created by customers who do not conform. If the network is not congested, however, it might be nice to go ahead and forward the nonconforming customer traffic. Doing so doesn't really cost the ISP anything, so long as the network is not congested. If the network is congested, however, ISP1 wants to discard the traffic that exceeds the contract before discarding traffic that is within its respective contract.

Figure 14Figure 3-14 Policing: Excess Traffic Marked with Higher Discard Value

For instance, the conforming traffic can be marked with DSCP AF41, and the nonconforming traffic with DSCP Default. The congestion-avoidance QoS tools in ISP1 can be configured to aggressively discard all DSCP Default traffic at the first signs of congestion. So, when ISP1 experiences congestion, policing indirectly causes the excess traffic to be discarded; in periods of no congestion, ISP1 provides service beyond what the customer has paid for.

You can also use CAR to just mark the traffic. CAR classifies traffic based on a large number of fields in the packet header, including anything that can be matched with an IP ACL. Once matched, CAR can be configured to do one action for conforming traffic, and another for excess traffic. If the two actions (conform and exceed actions) are the same action, in effect, CAR has not policed, but rather has just marked packets in the same way.

CAR configuration includes the classification, marking, and enabling features all in a single configuration command: the rate-limit interface subcommand. (CB marking, you may recall, separates classification, marking, and enabling on an interface into three separate commands.) Tables 3-11, 3-12, and 3-13 list the pertinent CAR configuration and exec commands, respectively.

Table 3-11 Configuration Command Reference for CAR

Command

Mode and Function

rate-limit {input | output} [access-group [rate-limit] acl-index] bps burst-normal burst-max conform-action conform-action exceed-action exceed-action

Interface mode; configures classification, marking, policing, and enabling CAR on the interface

access-list rate-limit acl-index {precedence | mac-address | exp mask mask}

Global mode; creates a CAR ACL, which can match IP precedence, MAC addresses, and MPLS Experimental bits


Table 3-12 Possible Actions with CAR rate-limit Command

rate-limit Conform and Exceed Options

Function

Continue

Evaluates the next rate-limit command

Drop

Drops the packet

set-dscp-continue

Sets the differentiated services code point (DSCP) (0–63) and evaluates the next rate-limit command

set-dscp-transmit

Sets the DSCP and transmits the packet

set-mpls-exp-continue

Sets the MPLS Experimental bits (0–7) and evaluates the next rate-limit command

set-mpls-exp-transmit

Sets the MPLS Experimental bits (0–7) and sends the packet

set-prec-continue

Sets the IP precedence (0–7) and evaluates the next rate-limit command

set-prec-transmit

Sets the IP precedence (0–7) and sends the packet

set-qos-continue

Sets the QoS group ID (1–99) and evaluates the next rate-limit command

set-qos-transmit

Sets the QoS group ID (1–99) and sends the packet

Transmit

Sends the packet


Table 3-13 Exec Command Reference for CAR

Command

Function

show interfaces [interface-type interface-number] rate-limit

Displays CAR statistics on the interface specified, or on all interfaces if the interface is not specified

show access-lists rate-limit [acl-index]

Lists information about the configuration of rate-limit ACLs


The first CAR marking example, shown in Example 3-5, uses the following criteria for marking packets. In this example, R3 is marking packets that flow right to left in Figure 3-15. (This example's criteria matches that in Example 3-1 for CB marking.)

Figure 15Figure 3-15 CAR Marking Sample 1: VoIP Marked with DSCP EF, Everything Else Marked BE

  • All VoIP payload traffic is marked with DSCP EF.

  • All other traffic is marked with DSCP Default.

Example 3-5 CAR Marking, VoIP as DSCP EF, Everything Else as BE

no ip cef
!
access-list 102 permit udp any range 16384 32768 any range 16384 32768
!
interface fastethernet 0/0
 rate-limit input access-group 102 10000 20000 30000 conform-action 
  set-dscp-transmit 46 exceed-action set-dscp-transmit 46
 rate-limit input 10000 20000 30000 conform-action set-dscp-transmit 0 
  exceed-action set-dscp-transmit 0
end

The configuration does not take nearly as many different commands as the CB marking example, because most of the interesting parameters are contained in the rate-limit commands. Cisco Express Forwarding (CEF) is disabled, just to make the point that although you can use CEF with CAR, it is not required. ACL 102 defines some classification parameters that CAR will use to match VoIP packets, looking at UDP ports between 16,384 and 32,767. The ACL logic matches all VoIP payload, but it will also match VoIP Real Time Control Protocol (RTCP) traffic, which uses the odd-numbered UDP ports in the same port range. Finally, two rate-limit commands under FA0/0 enable CAR, define policing limits, classification details, and marking details.

The first of the two rate-limit commands matches a subset of all traffic using classification, whereas the second rate-limit command just matches all traffic. CAR uses the information configured in these two commands sequentially; in other words, if a packet matches the first CAR statement's classification details, the statement is matched, and its actions are followed. If not, CAR compares the next statement, and so on. In this example, the first CAR rate-limit command matches VoIP packets by referring to ACL 102, and the second statement, because it does not refer to an ACL, matches all packets.

NOTE

CAR can actually match multiple statements on the same interface. Some CAR actions include the keyword continue, which means that even after the statement is matched, CAR should keep searching the statements for further matches. This allows CAR to nest statements, to perform features such as "police all traffic at 500 kbps, but police subsets at 250 kbps, 200 kbps, and 150 kbps."

Now examine the first rate-limit command, rate-limit input access-group 102 10000 20000 30000 conform-action set-dscp-transmit 46 exceed-action set-dscp-transmit 46, in detail. The input keyword means that CAR examines traffic entering the interface. The access-group 102 command means that packets permitted by ACL 102 are considered to match this rate-limit command. The next three values represent the committed rate, the burst size, and the excess size, which make up the traffic contract. The conform-action keyword identifies that the next parameter defines the action applied to conforming traffic, and the exceed-action keyword identifies that the next parameter defines the action applied to traffic that exceeds the traffic contract. In this example, both the conform and exceed actions are identical: set-dscp-transmit 46, which marks the DSCP value to decimal 46, or DSCP EF. (The rate-limit command does not allow the use of DSCP names.)

In this example, the actual traffic contract does not matter, because the actions for conforming traffic and excess traffic are the same. The true goal of this example is just to use CAR to mark packets VoIP—not to actually police the traffic. Chapter 5 includes CAR examples with different conform and exceed actions. The three values represent the committed rate (bps), the committed burst size (bytes), and the committed burst plus the excess burst (bytes). The excess burst parameter essentially provides a larger burst during the first measurement interval after a period of inactivity. (Chapter 5 covers the details of these settings.)

The second rate-limit command, rate-limit input 10000 20000 30000 conform-action set-dscp-transmit 0 exceed-action set-dscp-transmit 0, matches all remaining traffic. The only way that CAR can classify packets is to refer to an IP ACL, or a CAR rate-limit ACL, from the rate-limit command. The second rate-limit command does not refer to an ACL with the access-group keyword, so by implication, the statement matches all packets. Both actions set the DSCP value to zero. Essentially, this example uses CAR to mark traffic with either DSCP 46 or 0 (decimal), without discarding any packets due to policing.

The second sample CAR configuration, Example 3-6, includes classification options similar to CB marking Example 3-4. Because CAR cannot take advantage of NBAR, CAR cannot look at the URL for HTTP requests, as the CB marking example did. The slightly modified criteria for CAR marking in Example 3-6 is as follows:

  • VoIP payload is marked with DSCP EF.

  • NetMeeting voice and video from Server1 to Client1 is marked with DSCP AF41.

  • Any HTTP traffic is marked with AF22.

  • All other traffic is marked with DSCP Default.

Figure 3-16 shows the network in which the configuration is applied, and Example 3-6 shows the configuration.

Figure 16Figure 3-16 CAR Marking Sample 2 Network

Example 3-6 CAR Marking Sample 2: VoIP, NetMeeting Audio/Video, HTTP URLs, and Everything Else

no ip cef
!
access-list 110 permit udp any range 16384 32768 any range 16384 32768
!
access-list 111 permit udp host 192.168.1.100 gt 16383 192.168.3.0 0.0.0.255 gt 16383
!
access-list 112 permit tcp any eq www any
access-list 112 permit tcp any any eq www
!
!
interface fastethernet 0/0
rate-limit input access-group 111 8000 20000 30000 conform-action 
 set-dscp-transmit 34 exceed-action set-dscp-transmit 34
rate-limit input access-group 110 8000 20000 30000 conform-action 
 set-dscp-transmit 46 exceed-action set-dscp-transmit 46
rate-limit input access-group 112 8000 20000 30000 conform-action 
 set-dscp-transmit 20 exceed-action set-dscp-transmit 20
rate-limit input 8000 20000 30000 conform-action set-dscp-transmit 0 
 exceed-action set-dscp-transmit 0

end
R3#show interface fastethernet 0/0 rate-limit
Fastethernet0/0 connected to SW2, where Server1 is connected
 Input
  matches: access-group 111
   params: 8000 bps, 20000 limit, 30000 extended limit
   conformed 1346 packets, 341169 bytes; action: set-dscp-transmit 34
   exceeded 2683 packets, 582251 bytes; action: set-dscp-transmit 34
   last packet: 56ms ago, current burst: 29952 bytes
   last cleared 00:07:11 ago, <Anchor13>conformed 6000 bps, exceeded 10000 bps

  matches: access-group 110
   params: 8000 bps, 20000 limit, 30000 extended limit
   conformed 6118 packets, 452856 bytes; action: set-dscp-transmit 46
   exceeded 34223 packets, 2552218 bytes; action: set-dscp-transmit 46
   last packet: 12ms ago, current burst: 29989 bytes
   last cleared 00:07:11 ago, <Anchor14>conformed 8000 bps, exceeded 47000 bps

  matches: access-group 112
   params: 8000 bps, 20000 limit, 30000 extended limit
   conformed 677 packets, 169168 bytes; action: set-dscp-transmit 20
   exceeded 3631 packets, 5084258 bytes; action: set-dscp-transmit 20
   last packet: 8ms ago, current burst: 29638 bytes
   last cleared 00:07:12 ago, <Anchor15>conformed 3000 bps, exceeded 94000 bps

  matches: all traffic
   params: 8000 bps, 20000 limit, 30000 extended limit
   conformed 671 packets, 279572 bytes; action: set-dscp-transmit 0

The show interface Fastethernet 0/0 rate-limit command lists the pertinent statistical information about CAR's performance. The output has one stanza correlating to each rate-limit command on the interface, as highlighted in the example. Under each stanza, the number of packets and bytes that conformed, and the number of packets and bytes that exceeded the traffic contract, are listed. Because this CAR configuration was intended only for marking traffic, the number of packets and bytes in each category does not matter; Chapter 5 takes a closer look at the two values. For comparison purposes, however, consider the bps rates of the combined conformed and exceeded values. For instance, the second rate-limit command referenced ACL 110, which matched the two VoIP calls between R1 and R4. These two values total 55 kbps, which is the amount of traffic expected from a pair of G.729a calls over an Ethernet network.

CAR Marking Summary

CAR is another tool that examines packet header information to classify and mark packets. CAR provides fewer options for classification and marking than does CB marking, but CAR is considered to be DiffServ compliant because it can classify DSCP using an ACL and mark the DSCP field directly. CAR, along with CB marking and PBR, makes classification decisions based on the contents of packet headers and marks QoS fields based on those classifications. Dial peers provide very different classification options, so fewer direct comparisons can be drawn.

Refer to Table 3-17 for a complete list of classification and marking fields used by CAR.

Policy-Based Routing (PBR)

PBR enables you to route a packet based on other information, in addition to the destination IP address. In most cases, engineers are happy with the choices of routes made by the routing protocol, with routing occurring based on the destination IP address in each packet. For some specialized cases, however, an engineer may want some packets to take a different path. One path through the network may be more secure, for instance, so some packets could be directed through a longer, but more secure, path. Some packets that can tolerate high latency may be routed through a path that uses satellite links, saving bandwidth on the lower-latency terrestrial circuits for delay-sensitive traffic. Regardless of the reasons, PBR can classify packets and choose a different route. Figure 3-17 shows a simple example, where FTP traffic is directed over the longer path in the network.

Figure 17Figure 3-17 PBR: FTP Traffic Routed over Longer Path

PBR supports packet marking and policy routing. As you learned in previous sections, CAR supports marking because CAR's main feature, policing, benefits from having the marking feature available as well. Similarly, PBR includes a marking feature, because in some cases, PBR is used to pick a different route for QoS reasons—for instance, to affect the latency of a packet. So, PBR's core function can benefit from marking a packet, so that the appropriate QoS action can be taken as the packet traverses the network. Just as with CAR, you can use PBR's marking feature without actually using its core feature. In other words, you can use PBR just for classification and marking, without choosing a different route. The examples in this chapter focus only on PBR as a marking tool.

Unlike CB marking and CAR, PBR only processes packets entering an interface; you cannot enable it for packets exiting an interface. The reason PBR only processes incoming packets relates to its core function: policy routing. PBR needs to process packets before a routing decision has been made. Therefore, PBR processes packets entering an interface, preempting the normal routing logic based on destination IP address.

Finally, one other difference between PBR and the other classification and marking tools covered so far (CB marking and CAR) is that PBR can classify based on routing information, instead of totally relying on information in the frame or packet header. PBR can look up the entry in the routing table that matches a packet's destination address, for instance, and then classify based on information about that route. For example, the metric associated with that route, the source of the routing information, or the next-hop interface associated with the route can be checked. In most cases, this routing information does not help you with differentiating between different types of traffic. An FTP server, an IP Phone, a video server, and some web servers may all be in the same subnet, for instance, but the routing information about that subnet could not help PBR distinguish between those different types of traffic. Therefore, typically the most useful classification feature of PBR, when used for marking, is just to refer to an IP ACL.

PBR configuration uses yet another totally different set of configuration commands as compared to CB marking and CAR. PBR does separate the classification, marking, and enabling features into different commands. Tables 3-14 and 3-15 list the pertinent PBR configuration and exec commands, respectively. Following the tables, two example PBR configurations are shown. The two examples use the same criteria as the two CAR samples.

Table 3-14 Configuration Command Reference for PBR3

Command

Mode and Function

ip local policy route-map map-tag

Global; specifies that packets generated by this router should be candidates for policy routing

ip policy route-map map-tag

Interface subcommand; refers to a route map, which in turn classifies packets and specifies actions; actions include specifying a different route, and setting IP precedence

route-map map-tag [permit | deny] [sequence-number]

Global command; creates a route map entry

match ip address {access-list-number | access-list-name} [... access-list-number | ... access-list-name]

Route-map subcommand; used to match IP packets based on parameters that can be matched with an IP ACL

match length minimum-length maximum-length

Route-map subcommand; used to match IP packets based on their length

set ip precedence number | name

Route-map subcommand; sets IP precedence value using the decimal number of name

set ip next-hop ip-address [...ip-address]

Route-map subcommand; defines the IP address(es) of the next-hop router(s) to be used for forwarding packets that match this route map entry

ip route-cache policy

Global command; enables fast switching of PBR-routed packets


Table 3-15 Exec Command Reference for PBR Marking

Command

Function

show ip policy

Lists configured PBR details, and statistics for numbers of packets matched by each clause.

show route-map

Lists statistical information about packets matched with a route map. PBR uses route maps to classify and mark traffic.


Example 3-7 shows the first PBR marking example, which uses the same criteria as Example 3-1 for CB marking and Example 3-5 for CAR. In this example, R3 is marking packets that flow right to left in Figure 3-18.

Figure 18Figure 3-18 PBR Marking Sample 1: VoIP Marked with IP Precedence 5, Everything Else Marked IP Precedence 0

  • All VoIP payload traffic is marked with IP precedence 5.

  • All other traffic is marked with IP precedence 0.

Example 3-7 PBR Marking, VoIP as DSCP EF, Everything Else as BE

ip route-cache policy
!
ip access-list extended VoIP-ACL
 permit udp any range 16384 32767 any range 16384 32767
!
int fastethernet 0/0
 ip policy route-map voip-routemap
!
route-map voip-routemap permit 10
 match ip address VoIP-ACL
 set ip precedence 5
!
route-map voip-routemap permit 20
set ip precedence 0

PBR uses route-map commands, along with match and set route-map subcommands, to classify and mark the packets. This configuration uses a route map named voip-routemap, which includes two clauses. The first clause, clause 10, uses a match command that refers to VoIP-ACL, which is a named IP ACL. VoIP-ACL matches UDP port numbers between 16,384 and 32,767, which matches all VoIP traffic. If the ACL permits a packet, the route map's first clause acts on the set command, which specifies that IP precedence should be set to 5.

The second route map clause, clause 20, matches the rest of the traffic. The route map could have referred to another IP ACL to match all packets; however, by not specifying a match statement in clause 20, all packets will match this clause by default. By not having to refer to another IP ACL to match all packets, less processing overhead is required. The set command then specifies to set precedence to zero.

The ip policy route-map voip-routemap command enables PBR on interface FA0/0 for incoming packets. Notice that the direction, input or output, is not specified, because PBR can only process incoming packets.

The last PBR-specific command is ip route-cache policy. IOS process-switches PBR traffic by default; to use fast switching on PBR traffic, use the ip route-cache policy command.

The second PBR configuration (Example 3-8) includes classification options identical to CAR example 2 (see Example 3-6). A major difference between PBR and CAR is that PBR cannot set the DSCP field, so it sets the IP Precedence field instead. The slightly modified criteria, as compared with CAR example 2, for PBR example 2 is as follows:

  • VoIP payload is marked with precedence 5.

  • NetMeeting voice and video from Server1 to Client1 is marked with precedence 4.

  • Any HTTP traffic is marked with precedence 2.

  • All other traffic is marked with precedence 0.

Figure 3-19 shows the network in which the configuration is applied, and Example 3-8 shows the configuration.

Figure 19Figure 3-19 PBR Marking Sample 2 Network

Example 3-8 PBR Marking Sample 2: VoIP, NetMeeting Audio/Video, HTTP URLs, and Everything Else

ip route-cache policy
!
ip access-list extended VoIP-ACL
 permit udp any range 16384 32768 any range 16384 32768
!
ip access-list extended NetMeet-ACL
 permit udp host 192.168.1.100 range 16384 32768 192.168.3.0 0.0.0.255 range 16384 32768
!
!
ip access-list extended http-acl
 permit tcp any eq www any
 permit tcp any any eq www
!
interface fastethernet 0/0
 ip policy route-map voip-routemap
!
route-map voip-routemap permit 10
 match ip-address NetMeet-ACL
 set ip precedence 4
!
route-map voip-routemap permit 20
 match ip-address VoIP-ACL
 set ip precedence 5
!
route-map voip-routemap permit 30
 match ip-address http-acl
 set ip precedence 2
!
route-map voip-routemap permit 40
set ip precedence 0
!
end
R3#sh ip policy
Interface   Route map
Fastethernet0/0  voip-routemap
R3#show route-map
route-map voip-routemap, permit, sequence 10
 Match clauses:

  ip address (access-lists): NetMeet-ACL

 Set clauses:
  ip precedence flash-override

 Policy routing matches: 3 packets, 222 bytes
route-map voip-routemap, permit, sequence 20
 Match clauses:

  ip address (access-lists): VoIP-ACL
 Set clauses:
  ip precedence critical

 Policy routing matches: 14501 packets, 1080266 bytes
route-map voip-routemap, permit, sequence 30
 Match clauses:


  ip address (access-lists): http-acl
 Set clauses:
  ip precedence immediate
 Policy routing matches: 834 packets, 1007171 bytes
route-map voip-routemap, permit, sequence 40
 Match clauses:
 Set clauses:
  ip precedence routine
 Policy routing matches: 8132 packets, 11263313 bytes

The output of the show ip policy command lists only sparse information. The show route-map command enables you to view statistical information about what PBR has performed. This command lists statistics for any activities performed by a route map, including when one is used for PBR. Notice that the four sets of classification criteria seen in the configuration are listed in the highlighted portions of the show route-map output, as are packet and byte counters.

PBR Marking Summary

PBR provides another classification and marking tool that examines packet header information to classify and mark packets. PBR is unique compared to the other tools in that it can classify based on information about the route that would be used for forwarding a packet. However, PBR has fewer options for matching header fields for classification as compared with the other tools.

PBR can mark IP precedence, QoS group, as well as the ToS bits. Refer to Table 3-17, in the summary for this chapter, for a complete list of classification and marking fields used by PBR.

PBR provides a strong option for classification and marking in two cases. For applications when marking based on routing information is useful, PBR can look at details about the route used for each packet, and make marking choices. The other application for PBR marking is when policy routing is already needed, and marking needs to be done at the same time. For more general cases of classification and marking, CB marking or CAR is recommended.

VoIP Dial Peer

IOS voice gateways provide many services to connect the packetized, VoIP network to nonpacketized, traditional voice services, including analog and digital trunks. IOS gateways perform many tasks, but one of the most important tasks is to convert from packetized voice to nonpacketized voice, and vice versa. In other words, voice traffic entering a router on an analog or digital trunk is not carried inside an IP packet, but the IOS gateway converts the incoming voice to a digital signal (analog trunks only) and adds the appropriate IP, UDP, and RTP headers around the digital voice (both analog and digital trunks). Conversely, when a VoIP packet arrives, and the voice needs to be sent out a trunk, the IOS gateway removes the packet headers, converts the voice to analog (analog trunks only), and sends the traffic out the trunk.

Although this book does not attempt to explain voice configuration and concepts to much depth, some appreciation for IOS gateway configuration is required for some of the functions covered in this book. In particular, Chapter 8, "Call Admission Control and QoS Signaling," which covers Voice call admission control (CAC), requires a little deeper examination of voice. To understand classification and marking using dial peers, however, only a cursory knowledge of voice configuration is required. Consider Figure 3-20, for instance, which shows two analog IOS voice gateways, R1 and R4, along with Examples 3-9 and 3-10, which show the pertinent configuration on R1 and R4.

Figure 20Figure 3-20 Network with Two Analog Voice Gateways


Example 3-9 R1 Voice Gateway Configuration

hostname R1
!
int fastethernet 0/0
ip address 192.168.1.251 255.255.255.0
!
dial-peer voice 3001 voip
 destination-pattern 3001
 session target ipv4:192.168.3.254
!
dial-peer voice 3002 voip
 destination-pattern 3002
 session target ipv4:192.168.3.254
!
dial-peer voice 1001 pots
 destination-pattern 1001
 port 3/0
!
dial-peer voice 1002 pots
 destination-pattern 1002
 port 3/1

Example 3-10 R4 Voice Gateway Configuration

hostname R4
!
int fastethernet 0/0
ip address 192.168.3.254 255.255.255.0
!
dial-peer voice 1001 voip
 destination-pattern 1001
 session target ipv4:192.168.1.251
!
dial-peer voice 1002 voip
 destination-pattern 1002
 session target ipv4:192.168.1.251
!
dial-peer voice 3001 pots
 destination-pattern 3001
 port 3/0
!
dial-peer voice 3002 pots
 destination-pattern 3002
 port 3/1

The highlighted portions of the examples focus on the configuration for the physical voice ports on R1, and the VoIP configuration on R4. Both R1 and R4 use dial-peer commands to define their local analog voice trunks and to define peers to which VoIP calls can be made. In Example 3-9, for instance, the highlighted portion of the configuration shows R1's configuration of the two local analog lines. The two highlighted dial-peer statements use the keyword pots, which stands for plain-old telephone service. The pots keyword implies that the ports associated with this dial peer are traditional analog or digital telephony ports. The physical analog ports are correlated to each dial peer with the port command; in each of these configurations, a two-port FXS card sits inside slot 3 of a 1760-V router. Finally, on R1, the phone number, or dial pattern, associated with each of the analog ports is configured. With just the highlighted configuration in R1, voice calls could be placed between the two extensions (x1001 and x1002).

To place calls to extensions 1001 and 1002 from R4, the dial-peer commands highlighted in Example 3-10 are required. These two dial-peer commands use a voip keyword, which means this dial peer configures information about an entity to which VoIP calls can be placed. The phone number, or dial pattern, is defined with the destination-pattern command again—notice that extensions 1001 and 1002 are again configured. Finally, because these two dial peers configure details about a VoIP call, a local physical port is not referenced. Instead, the session-target ipv4:192.168.1.251 command implies that when these phone numbers are called, to establish a VoIP call, using the IP version 4 IP address shown.

Similarly, R4 defines the local phone numbers and ports for the locally connected phones, and R1 defines VoIP dial peers referring to R4's phones, so that calls can be initiated from R1.

Dial-peer classification and marking, when you know how to configure the basic dial-peer parameters, is easy. POTS dial peers refer to analog or digital trunks, over which no IP packet is in use—so there is nothing to mark. On VoIP dial peers, the dial peer refers to the IP address of another gateway to which a call is placed. So, by placing the ip precedence 5 dial-peer subcommand under each voip dial-peer, the packets generated for calls matching each dial peer will be marked with IP precedence 5. Example 3-11 lists the R4 configuration, with these changes made; the equivalent changes would be made to R1 as well.

Example 3-11 R4 Voice Gateway Configuration

hostname R4
!
interface fastethernet 0/0
ip address 192.168.3.254 255.255.255.0
!
dial-peer voice 1001 voip
 destination-pattern 1001
 session target ipv4:192.168.1.251
 ip precedence 5
 no vad
!
dial-peer voice 1002 voip
 destination-pattern 1002
 session target ipv4:192.168.1.251
 ip precedence 5
 no vad
!
dial-peer voice 3001 pots
 destination-pattern 3001
 port 3/0
!
dial-peer voice 3002 pots
 destination-pattern 3002
 port 3/1

In the example, the highlighted text shows the ip precedence 5 commands under each voip dial-peer. Packets created for VoIP calls for the configured dial patterns of 1001 and 1002 will be marked with IP precedence 5. The identical commands would be added to R1's configuration on the VoIP dial peers to achieve the same effect.

Beginning in IOS Releases 12.2(2)XB and 12.2(2)T the ip precedence command has been replaced with the ip qos dscp command. This allows the dial peer to set the IP precedence or the DSCP value for VoIP payload and signaling traffic. Also keep in mind that the current DQOS exam, at the time this book was published, was based on IOS 12.1(5)T—so this command would not be on the current exam. Check the URLs listed in the Introduction for any possible changes.

The command uses the following syntax:

ip qos dscp [number | set-af | set-cs | default | ef][media | signaling]

Table 3-16 outlines the meaning of the parameters of the command.

Table 3-16 IP QoS DSCP Command Options

IP QoS DSCP Options

Function

number

DSCP value. Valid entries are from 0 to 63.

set-af

Sets DSCP to assured forwarding bit pattern. Acceptable values are as follows:

AF11, AF12, AF13, AF21, AF22, AF23, AF31, AF32, AF33, AF41, AF42, AF43

set-cs

Sets DSCP to class selector code point. Acceptable values are as follows:

CS1, CS2, CS3, CS4, CS5, CS6, CS7

default

Sets DSCP to default bit pattern 000000.

ef

Sets DSCP to expedited forwarding bit pattern 101110.

media

Applies the specified DSCP value to the media payload packets.

signaling

Applies the specified DSCP value to the signaling packets.


The ip qos dscp command enables you to have much more granular control of how a VoIP packet is marked than the ip precedence command, while providing a method to preserve backward compatibility. Examples 3-12 and 3-13 show how R1 and R4 can be configured to use the ip qos dscp command to mark voice payload traffic with a DSCP value of EF and voice signaling traffic with a DSCP value of AF31. Figure 3-21 shows the now-familiar network, with the new criteria listed.

Figure 21Figure 3-21 Mark Voice Payload Traffic


Example 3-12 R1 IP QoS DSCP Dial-Peer Configuration

hostname R1
!
int fastethernet 0/0
ip address 192.168.1.251 255.255.255.0
!
dial-peer voice 3001 voip
 destination-pattern 3001
 ip qos dscp ef media
 ip qos dscp af31 signaling
 session target ipv4:192.168.3.254
!
dial-peer voice 3002 voip
 destination-pattern 3002
 ip qos dscp ef media
 ip qos dscp af31 signaling
 session target ipv4:192.168.3.254
!
dial-peer voice 1001 pots
 destination-pattern 1001
 port 3/0
!
dial-peer voice 1002 pots
 destination-pattern 1002
 port 3/1

Example 3-13 R4 IP QoS DSCP Dial-Peer Configuration

hostname R4
!
int fastethernet 0/0
ip address 192.168.3.254 255.255.255.0
!
dial-peer voice 1001 voip
 destination-pattern 1001
 ip qos dscp ef media
 ip qos dscp af31 signaling
 session target ipv4:192.168.1.251
!
dial-peer voice 1002 voip
 destination-pattern 1002
 ip qos dscp ef media
 ip qos dscp af31 signaling
 session target ipv4:192.168.1.251
!
dial-peer voice 3001 pots
 destination-pattern 3001
 port 3/0
!
dial-peer voice 3002 pots
 destination-pattern 3002
 port 3/1

In this example, the highlighted text shows the ip qos dscp commands used to mark voice signaling with DSCP AF31 and voice payload with DSCP EF. For networks that cannot yet support DSCP markings, you can use the set-cs option to mark the voice traffic with IP precedence, providing backward-compatible support.

VoIP Dial-Peer Summary

For voice traffic passing through an IOS gateway, marking the traffic using dial peers provides an easy-to-configure, low-overhead way to mark the packets. Prior to IOS Releases 12.2(2)XB and 12.2(2)T the ip precedence command was used to mark all VoIP traffic with an IP precedence value. After these IOS releases, you can use the ip qos dscp command to separate and individually mark the voice signaling and voice payload traffic. These markings can be DCSP values, or IP precedence values if backward compatibility is needed. Refer to Tables 3-14 and 3-15 for ip qos dscp command options.

Summary of Classification and Marking QoS Features

Classification and marking tools can be easily compared based on three general categories. First, some classification and marking tools are specialized, and some are more general. CB marking, CAR, and PBR all perform the same basic function of matching packets based on fields inside the packet header, and marking based on those fields, so these three tools are the more generalized classification and marking tools. Dial peers perform specialized classification and marking functions. This tool is different from the other three because it does not classify packets based on a variety of fields in a packet header, instead classifying all traffic to the particular dial peer.

The other two points for comparison of classification and marking tools concern what each tool can match for classification, and what each can mark for the marking feature. Tables 3-17 and 3-18 summarize the fields that you can use for classification and marking in the tools, respectively.

Table 3-17 Classification Fields Used by Classification and Marking Tools

Classification Field4

CB Marking

CAR

PBR

Dial Peers

Extended IP ACLs

X

X

X

 

DSCP

X

 

 

 

Precedence

X

X

 

 

QoS Group

X

 

 

 

CoS

X

 

 

 

NBAR

X

 

 

 

VoIP Payload (even-numbered RTP UDP ports)

X

 

 

 

MPLS Experimental bits

X

X

 

 

Input Interface

X

 

 

 

Source MAC address

X

X

 

 

Destination MAC address

X

 

 

 

BGP ASN

 

 

X

 

BGP Community

 

 

X

 

Outgoing Interface

 

 

X

 

Next-hop IP Address

 

 

X

 

Routing Protocol Metric

 

 

X

 

Source of Routing Information

 

 

X

 

Packet Length

 

 

X

 

VoIP Dial Peers

 

 

 

X


Table 3-18 Marking Fields Used by Classification and Marking Tools

Marking Field

CB Marking

CAR

PBR

Dial Peers

DSCP

X

X

 

X

Precedence

X

X

X

X

QoS Group

X

X

X

 

CoS

X

 

 

 

MPLS Experimental bits

X

X

 

 

Frame Relay DE

X

 

 

 

ATM CLP

X

 

 

 

IP ToS bits

 

 

X

 


The choice of when to use each tool can be confusing. Dial peers have specific applications, so the number of instances where they are useful directs you when to consider each tool. Dial peers are used only in IOS voice gateways, which is a convenient place to set IP precedence or DSCP.

The three general classification and marking tools create a more difficult choice, because each can be enabled on almost any interface. CB marking may be ruled out based on the IOS revision being used, because CB marking did not appear in a T-train IOS until 12.1(5)T, and in mainline IOS until 12.2.

NOTE

Refer to http://www.cisco.com/go/fn to use the Cisco feature navigator to find IOS revision levels required for different features.

When at a level of code that support CB marking, the general recommendation is to use CB marking, unless one of the next two statements is true. If you need to use PBR to perform policy routing, and you also need to mark, go ahead and use PBR for marking. Similarly, if you need to perform policing and marking at the same point in the network, use CAR for both.

Foundation Summary

The "Foundation Summary" is a collection of tables and figures that provide a convenient review of many key concepts in this chapter. For those of you already comfortable with the topics in this chapter, this summary could help you recall a few details. For those of you who just read this chapter, this review should help solidify some key facts. For any of you doing your final prep before the exam, these tables and figures are a convenient way to review the day before the exam.

Table 3-19 shows the list of items that can be matched with an extended IP ACL. Table 3-20 lists the fields that can be matched by classification and marking tools without use of an ACL. Note that some header fields can be matched by an ACL or directly through some other style of configuration—in those cases, it is typically better to match the field directly, rather than with an ACL.

Table 3-19 IP Extended ACL Matchable Fields—IOS 12.2

Field

Comments

Source IP address

A range of source IP addresses can be matched by using a wildcard mask.

Destination IP address

A range of source IP addresses can be matched by using a wildcard mask.

IP Precedence

Format of command uses names for precedence. The following table lists the decimal value for each name.

Name
IP precedence value
routine
0
priority
1
immediate
2
flash
3
flash-override
4
Critic
5
internet
6
network
7

IP DSCP

Format of the command allows use of differentiated services code point (DSCP) names, as well as decimal values.

IP ToS

Can check to see whether a single Type of Service (ToS) field bit is toggled on; keywords are normal (binary 0000), max-reliability (binary 1000), max-throughput (binary 0100), min-delay (binary 0010), and min-monetary-cost (binary 0001).

TCP ports

Can check source and destination ports; can also check a range of port numbers, whether a port number is larger or smaller than a single value.

TCP Established

Although not typically useful for QoS classification, ACLs can match all TCP segments after the initial segment used for connection establishment.

UDP

Checks the source and destination ports; can also check a range of port numbers, whether a port number is larger or smaller than a single value.

ICMP

Checks a larger variety of ICMP messages and code types (for example, echo request and echo reply).

IGMP

Checks for Internet Group Management Protocol (IGMP) message types.


Table 3-20 Fields Directly Matchable by Classification and Marking tools

Field

Tool

Comments

Source MAC address

CAR, CB marking

Committed access rate (CAR) uses special "access-rate" ACLs; class-based (CB) marking uses the match command.

IP Precedence

CAR, CB marking

CAR uses special "access-rate" ACLs specific to CAR; CB marking uses the match command; both can match a subset of values.

MPLS Experimental

CAR, CB marking

CAR uses special "access-rate" ACLs specific to CAR; CB marking uses the match command; both can match a subset of values.

CoS

CB marking

Checks incoming ISL/802.1P CoS bits. Can match multiple values.

Destination MAC address

CB marking

Checks for destination MAC address. Can match multiple values.

Input Interface

CB marking

Checks for input interface. Can match multiple values.

IP DSCP

CB marking

Can check for multiple values using multiple match commands.

RTP's UDP port-number range

CB marking

RTP uses even-numbered UDP ports from 16,384 to 32,767. This option allows matching a subset of these values, even-numbered ports only, because RTP only uses even-numbered ports.

QoS Group

CB marking

The QoS Group field is used to tag packets internal to a single router.

NBAR protocol types

CB marking

Refer to the "Network Based Application Recognition (NBAR)" section in this chapter for more details.

NBAR Citrix applications

CB marking

NBAR can recognize different types of Citrix applications; CB marking can use NBAR to classify based on these application types.

Host name and URL string

CB marking

NBAR can also match URL strings, including the host name, using regular expressions. CB marking can use NBAR to match these strings for classification.

Outgoing Interface

Policy-based routing (PBR)

Checks the routing table and finds all valid routes for the packet; matches based on the outgoing interface.

Next-Hop

PBR

Similar to the outgoing interface, but it checks the next-hop routers' IP addresses.

Metric

PBR

Checks the routing table entry for this packet, and compares the metric value to match the packet.

Route type

PBR

Checks the routing table, looking at the source of the routing table entry that matches the packet.

Dial Peer

Dial peers

Based on the dial peer and used to connect a VoIP call.


Figure 3-22 outlines the two IP marking fields and their positions inside an IP header: The suggested values for these fields, and their names, are listed in Table 3-21.

Figure 22Figure 3-22 IP Precedence and IP DSCP Fields

Table 3-21 IP Precedence and DSCP—Popular Values and Names5

Field and Value (Decimal)

Binary Value

Name

Defined by This RFC

Precedence 0

000

routine

791

Precedence 1

001

priority

791

Precedence 2

010

immediate

791

Precedence 3

011

flash

791

Precedence 4

100

flash override

791

Precedence 5

101

critic

791

Precedence 6

110

internetwork control

791

Precedence 7

111

network control

791

DSCP 0

000000

best effort or default

2475

DSCP 8

001000

CS1

2475

DSCP 16

010000

CS2

2475

DSCP 24

011000

CS3

2475

DSCP 32

100000

CS4

2475

DSCP 40

101000

CS5

2475

DSCP 48

110000

CS6

2475

DSCP 56

111000

CS7

2475

DSCP 10

001010

AF11

2597

DSCP 12

001100

AF12

2597

DSCP 14

001110

AF13

2597

DSCP 18

010010

AF21

2597

DSCP 20

010100

AF22

2597

DSCP 22

010110

AF23

2597

DSCP 26

011010

AF31

2597

DSCP 28

011100

AF32

2597

DSCP 30

011110

AF33

2597

DSCP 34

100010

AF41

2597

DSCP 36

100100

AF42

2597

DSCP 38

100110

AF43

2597

DSCP 46

101110

EF

2598


Figure 3-23 shows the general location of the CoS field inside ISL and 802.1P headers.

Figure 23Figure 3-23 LAN Class Of Service Fields

Table 3-22 summarizes the marking fields.

Table 3-22 Names of Marking Fields

Field

Location

Length

Comments

IP Precedence

IP header

3 bits

Contained in the first 3 bits of the ToS byte.

IP DSCP

IP header

6 bits

Contained in the first 6 bits of the DS field, which replaces the ToS byte.

DS

IP header

1 byte

Replaces ToS byte per RFC 2475.

ToS

IP header

1 byte

Replaced by DS field per RFC 2475.

ToS

IP header

4 bits

A field inside the ToS byte; superseded by RFC 2475.

CoS

ISL and 802.1Q/P

3 bits

Cisco convention uses "CoS" to describe either trunking headers' QoS field.

Priority bits

802.1Q/P

3 bits

The name used by IEEE 802.1P for the CoS bits.

Discard Eligible (DE)

Frame Relay header

1 bit

Frame Relay switches may discard DE-marked frames, avoiding discarding frames without DE marked, under congestion.

Cell Loss Priority (CLP)

ATM cell header

1 bit

ATM equivalent of the DE bit

MPLS Experimental values(s)

MPLS header

3 bits

Used to pass QoS marking information across an MPLS network.

QoS Group

Headers internal to IOS

N/A

Uses values between 1–99 inclusive. Used for marking only internal to a single router, specifically only on the GSR/ESR product lines.


Table 3-23 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-24 lists the show commands related to CB marking.

Table 3-23 Command Reference for Class-Based 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}

ACL

match source-address mac address-destination

Source MAC address

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

IP precedence

match mpls experimental number

MPLS Experimental

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

CoS

match destination-address mac address

Destination MAC address

match input-interface interface-name

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]

IP DSCP

match ip rtp starting-port-number port-range

RTP's UDP port-number range

match qos-group qos-group-value

QoS group

match protocol protocol-name

NBAR protocol types

match protocol citrix [app application-name-string]

NBAR Citrix applications

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

Host name and URL string

match any

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

For the class, marks (sets) particular QoS fields

set ip precedence ip-precedence-value

IP precedence

set ip dscp ip-dscp-value

IP DSCP

set cos cos-value

CoS

set ip qos-group group-id

QoS group

set atm-clp

ATM CLP bit

Set fr-de

Frame Relay DE bit


Table 3-24 Exec Command Reference for Class-Based 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


Figure 3-24 shows the general flow of MQC commands.

Figure 24Figure 3-24 MQC Commands and Their Correlation

Tables 3-25 and 3-26 list the NBAR configuration and exec commands, respectively.

Table 3-25 Configuration Command Reference for NBAR

Command

Mode and Function

ip nbar protocol-discovery

Interface mode; enables NBAR for traffic entering the interface.

ip nbar port-map protocol-name [tcp | udp] port-number

Global; tells NBAR to search for a protocol using a different port number than the well-known port. Also defines ports to be used by custom packet description language modules (PDLM).

ip nbar pdlm pdlm-name

Global; extends the list of protocols recognized by NBAR by adding additional PDLMs.


You can use CAR for policing, but instead of discarding packets, CAR can instead mark nonconforming packets with a value that increases the packets' chances of being discarded when congestion occurs, as seen in Figure 3-25.

Figure 25Figure 3-25 Policing: Excess Traffic Marked with Lower Value

Table 3-26 Exec Command Reference for NBAR

Command

Function

show ip nbar protocol-discovery [interface interface-spec] [stats {byte-count | bit-rate | packet-count}][{protocol protocol-name | top-n number}]

Lists information about statistics for the discovered protocols. Statistics can be listed by interface, by protocol, or for just the top n protocols by volume.

show ip nbar port-map [protocol-name]

Lists the current ports in use by the discovered protocols.


Tables 3-27, 3-28, and 3-29 list the pertinent CAR configuration and exec commands, respectively.

Table 3-27 Configuration Command Reference for CAR

Command

Mode and Function

rate-limit {input | output} [access-group [rate-limit] acl-index] bps burst-normal burst-max conform-action conform-action exceed-action exceed-action

Interface mode; configures classification, marking, policing, and enabling CAR on the interface

access-list rate-limit acl-index {precedence | mac-address | exp mask mask}

Global mode; creates a CAR ACL, which can match IP precedence, MAC addresses, and MPLS Experimental bits


Table 3-28 Possible Actions with CAR rate-limit Command

rate-limit Conform and Exceed Options

Function

Continue

Evaluates the next rate-limit command

Drop

Drops the packet

set-dscp-continue

Sets the differentiated services code point (DSCP) (0–63) and evaluates the next rate-limit command

set-dscp-transmit

Sets the DSCP and transmits the packet

set-mpls-exp-continue

Sets the MPLS Experimental bits (0–7) and evaluates the next rate-limit command

set-mpls-exp-transmit

Sets the MPLS Experimental bits (0–7) and sends the packet

set-prec-continue

Sets the IP precedence (0–7) and evaluates the next rate-limit command

set-prec-transmit

Sets the IP precedence (0–7) and sends the packet

set-qos-continue

Sets the QoS group ID (1–99) and evaluates the next rate-limit command

set-qos-transmit

Sets the QoS group ID (1–99) and sends the packet

Transmit

Sends the packet


Table 3-29 Exec Command Reference for CAR

Command

Function

show interfaces [interface-type interface-number] rate-limit

Displays CAR statistics on the interface specified, or on all interfaces if the interface is not specified

show access-lists rate-limit [acl-index]

Lists information about the configuration of rate-limit ACLs


Policy-based routing (PBR) enables you to route a packet based on some other information besides the destination IP address. Figure 3-26 shows a simple example, where FTP traffic is directed over the longer path in the network.

Figure 26Figure 3-26 PBR: FTP Traffic Routed over Longer Path

Tables 3-30 and 3-31 list the pertinent PBR configuration and exec commands, respectively.

Table 3-30 Configuration Command Reference for PBR6

Command

Mode and Function

ip local policy route-map map-tag

Global; specifies that packets generated by this router should be candidates for policy routing

ip policy route-map map-tag

Interface subcommand; refers to a route map, which in turn classifies packets and specifies actions; actions include specifying a different route, and setting IP precedence

route-map map-tag [permit | deny] [sequence-number]

Global command; creates a route map entry

match ip address {access-list-number | access-list-name} [... access-list-number | ... access-list-name]

Route-map subcommand; used to match IP packets based on parameters that can be matched with an IP ACL

match length minimum-length maximum-length

Route-map subcommand; used to match IP packets based on their length

set ip precedence number | name

Route-map subcommand; sets IP precedence value using the decimal number of name

set ip next-hop ip-address [...ip-address]

Route-map subcommand; defines the IP address(es) of the next-hop router(s) to be used for forwarding packets that match this route map entry

ip route-cache policy

Global command; enables fast switching of PBR-routed packets


Table 3-31 Exec Command Reference for PBR Marking

Command

Function

show ip policy

Lists configured PBR details, and statistics for numbers of packets matched by each clause.

show route-map

Lists statistical information about packets matched with a route map. PBR uses route maps to classify and mark traffic.


  • + Share This
  • 🔖 Save To Your Account