124 Chapter 5: Introduction to the Modular QoS Command-Line Interface
The simplicity of configuration is made possible through the use of a common configu-
ration structure for all QoS components within the MQC. That is, the basic configuration
steps for configuring all QoS mechanisms is the same, with only small variations in the
configuration that are specific to the actual mechanism. You can configure all the mecha-
nisms through a three-step process:
Step 1 Class map configuration
Step 2 Policy map configuration
Step 3 Service policy application
This chapter describes each step in the configuration process, as well as the configuration
options, and also provides examples of MQC commands.
Step 1: The Class Map
The first step for configuring any QoS mechanism in the MQC is the configuration of a
class-map. Simply stated, the class map defines which traffic you want the router to match.
This is the fundamental step that allows the router to differentiate one traffic type from
another. This is traffic classification, and without classification there can be no QoS.
To differentiate traffic, it is possible to match on one traffic characteristic or multiple
characteristics. If you need to differentiate between traffic from 10.1.1.1 and traffic from
10.1.1.2, for example, the source IP address is the only characteristic that you need to
configure. If you have multiple traffic streams from 10.1.1.1 and need to differentiate
between those, however, as well as differentiate between multiple streams from 10.1.1.2,
you probably need to classify traffic based on multiple criteria, such as TCP or UDP port.
A possible scenario in which this would come into play might be server 10.1.1.1 that serves
production HTTP and FTP to the Accounting department, and server 10.1.1.2 that serves
nonproduction HTTP and FTP to the IT group that develops applications for the
Accounting department. Understanding that production traffic is the top priority, the devel-
opment group needs their traffic to have a minimum bandwidth guarantee to enable that
group to properly test a new HTTP application before delivering it to the Accounting
department for production use. This means that there will be QoS requirements for all
traffic from 10.1.1.1 and some traffic from 10.1.1.2. As such, just matching by IP address
does not suffice. In this case, there is a requirement to match on multiple characteristics.
Configuring the Class Map
When matching on multiple characteristics, two options exist for creating the class map:
match-any and match-all, as demonstrated in Example 5-1.
Example 5-1 Class Map Options
R1(config)# class-map ?
WORD class-map name
match-all Logical-AND all matching statements under this classmap
match-any Logical-OR all matching statements under this classmap
Step 1: The Class Map 125
The match-any option is a logical OR operation, in which only one of the match conditions
must be met for a packet to belong to a specific class. The match-all option is a logical AND
operation, in which all match criteria must be met for a packet to belong to a specific class.
You must choose one of these options before you configure the remaining class map param-
eters.
This section discusses the various configuration parameters for the class map, followed by
a configuration example. The distinction between match-any and match-all is discussed
as part of the configuration example later in this chapter.
In the examples that follow, the match-all parameter is used.
R1(config)#class-map match-all ?
WORD class-map name
Next it is necessary to provide a name for the class map. For this example, the class map is
named HTTP.
R1(config)#class-map match-all HTTP
R1(config-cmap)#
Notice that this router is now in config-cmap, which is class map configuration mode. The
class map has now been created, but it does not have any information about which traffic it
should pay attention to. There are, however, a few options within the class map other than
which traffic to match, as the output in Example 5-2 demonstrates.
It is possible, and highly recommended, to enter a description of the class map, using the
description command. Use this in the same way that you would use the description
command on an interface, and with the understanding that it has no actual impact on traffic.
It is also possible to rename this class map, without losing the configuration of the class
map. For example, if you decide that just calling the class HTTP is ambiguous, and decide
that you want the class to be called ACCOUNTING-HTTP, you can change the name
without destroying the configuration. This command was not always available, and it is a
very convenient addition to the MQC.
R1(config-cmap)#rename ?
WORD new class-map name
The major function of the class map, however, is to match traffic. As such, the match
argument has quite a few options. As with any software package, new features are constantly
Example 5-2 Additional Class Map Options
R1(config-cmap)# ?
QoS class-map configuration commands:
description Class-Map description
exit Exit from QoS class-map configuration mode
match classification criteria
no Negate or set default values of a command
rename Rename this class-map
126 Chapter 5: Introduction to the Modular QoS Command-Line Interface
being added to Cisco IOS Software, so the list is constantly expanded. Example 5-3 shows a
sample of the commands available.
Within some of these match possibilities are additional match options. An example of that
is the match ip option shown in Example 5-4.
You can view a list of the available options by using the interactive help menu.
Class Map Options: A Closer Look
The values on which the class map can be configured to match are explained in the previous
output, but this list provides more detailed explanations of some of these options:
access-group—Allows the configuration of an access-control list (ACL) and the
matching of the criteria defined within that ACL.
any—Allows for the matching of all packets. This option is typically used in a last-
resort class, where the intention is to have all traffic not classified elsewhere put into
a given class. This can also be used effectively with the not keyword, which is
explained later in this list.
class-map—This is the only way to combine the functions of the match-any and
match-all class maps into a single match. Suppose, for instance, that you want traffic
that is from either 10.1.1.1 or 10.1.1.2 and the destination IP address is 10.2.2.1 to
match this class. You could accomplish this by having a match-any class with an
Example 5-3 Options for the match Command
R1(config-cmap)# match ?
access-group Access group
any Any packets
class-map Class map
cos IEEE 802.1Q/ISL class of service/user priority values
destination-address Destination address
fr-de Match on Frame-relay DE bit
input-interface Select an input interface to match
ip IP specific values
mpls Multi Protocol Label Switching specific values
not Negate this match result
protocol Protocol
qos-group Qos-group
source-address Source address
Example 5-4 Class Map match Option
R1(config-cmap)# match ip ?
dscp Match IP DSCP (DiffServ CodePoints)
precedence Match IP precedence
rtp Match RTP port nos
Step 1: The Class Map 127
access-group statement to match the source IP address of 10.1.1.1 (defined by an
ACL) and an access-group statement to match the source IP address of 10.1.1.2
(defined by another ACL). Then, a match-all class would be configured with one
condition being that it matches the first class map and another condition being that it
matches an ACL that defines the destination IP address of 10.2.2.1. Example 5-5
shows the needed configuration.
cos—Allows for the matching of the Layer 2 class of service (CoS) value in either the
802.1Q or Inter-Switch Link (ISL) header.
destination-address—Don’t be fooled, this is not for matching the destination IP
address. This allows matching of the destination MAC address.
fr-de—Allows for matching of packets that have the Frame Relay discard eligible
(DE) bit set.
input-interface—Allows for the matching of packets based on the interface through
which they entered the router. This is useful in an environment in which multiple
remote sites are connected via Frame Relay to a head-end router. In that environment,
provided that point-to-point Frame Relay with subinterfaces is configured, all traffic
from a given remote site can be matched based on the subinterface on which that
traffic arrived.
ip—Allows for matching based on the IP-specific values previously listed (IP
precedence, DiffServ codepoint [DSCP], RTP port numbers).
mpls—Currently, this allows only for the matching of packets based on the
multiprotocol label switching (MPLS) experimental bits. The command has multiple
levels to provide flexibility for future matching of other MPLS-specific values.
not—This is a very useful option, which can be used with the match-any option in a
match-all class map to match all packets except those listed in the not criteria. For
example, you could match all packets (using match-any) and then configure a match
not statement for access group 101, which would match all packets not belonging to
access group 101.
Example 5-5 Combining match-any and match-all Options
Router(config)# class-map match-any SOURCES
Router(config-cmap)# match access-group 103
Router(config-cmap)# match access-group 104
Router(config-cmap)# exit
Router(config)# class-map match-all DESTINATION
Router(config-cmap)# match class-map SOURCES
Router(config-cmap)# match access-group 105
Router(config-cmap)# exit
R1(config)# access-list 103 permit ip host 10.1.1.1 any
R1(config)# access-list 104 permit ip host 10.1.1.2 any
R1(config)# access-list 105 permit ip any host 10.2.2.1
128 Chapter 5: Introduction to the Modular QoS Command-Line Interface
protocol—Allows for the matching of certain predefined protocols. Network-based
application recognition (NBAR) is a new classification engine that can recognize a
large number of applications based on both static and dynamically assigned port
numbers. On routers that support NBAR, the list of protocols is extensive, as shown
in Example 5-6.
Example 5-6 match protocol Possibilities Where NBAR Is Supported
R1(config-cmap)# match protocol ?
aarp AppleTalk ARP
apollo Apollo Domain
appletalk AppleTalk
arp IP ARP
bgp Border Gateway Protocol
bridge Bridging
bstun Block Serial Tunnel
cdp Cisco Discovery Protocol
citrix Citrix Traffic
clns ISO CLNS
clns_es ISO CLNS End System
clns_is ISO CLNS Intermediate System
cmns ISO CMNS
compressedtcp Compressed TCP
cuseeme CU-SeeMe desktop video conference
custom-01 Custom protocol custom-01
custom-02 Custom protocol custom-02
custom-03 Custom protocol custom-03
custom-04 Custom protocol custom-04
custom-05 Custom protocol custom-05
custom-06 Custom protocol custom-06
custom-07 Custom protocol custom-07
custom-08 Custom protocol custom-08
custom-09 Custom protocol custom-09
custom-10 Custom protocol custom-10
decnet DECnet
decnet_node DECnet Node
decnet_router-l1 DECnet Router L1
decnet_router-l2 DECnet Router L2
dhcp Dynamic Host Configuration
dlsw Data Link Switching
dns Domain Name Server lookup
egp Exterior Gateway Protocol
eigrp Enhanced Interior Gateway Routing Protocol
exchange MS-RPC for Exchange
fasttrack FastTrack Traffic - KaZaA, Morpheus, Grokster...
finger Finger
ftp File Transfer Protocol
gnutella Gnutella Traffic - BearShare,LimeWire, Gnutella...
gopher Gopher
gre Generic Routing Encapsulation
http World Wide Web traffic
icmp Internet Control Message
imap Internet Message Access Protocol
ip IP
ipinip IP in IP (encapsulation)
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset