QoS this way, use the console or Telnet to access
the CLI. Using the CLI approach is simple but only allows basic
features to be configured. To implement QoS this way, you must
first build a QoS policy (traffic policy) and then apply the
policy to the interface. Figure summarizes these points. Figure
lists these guidelines for building a QoS policy (traffic
policy): - Identify the traffic patterns in your network
by using a packet analyzer. This activity gives you the ability
to identify the traffic types, for example, IP, TCP, User
Datagram Protocol (UDP), DECnet, AppleTalk, and Internetwork
Packet Exchange (IPX).
- After you have performed the
traffic identification, start classifying the traffic. For
example, separate the voice traffic class from the
business-critical traffic class.
- For each traffic
class, specify the priority for the class. For example, voice
is assigned a higher priority than business-critical
traffic.
- After applying the priorities to the traffic
classes, select a proper QoS mechanism, such as queuing,
compression, or a combination of both. This choice determines
which traffic leaves the device first and how traffic leaves
the device.
Example: Legacy CLI QoS
Figure shows a possible implementation scenario for legacy CLI
followed by a sample configuration. In this scenario, a
low-speed WAN link connects the office site to the central
site. Both sites are equipped with PCs and servers that run
interactive applications, such as terminal services. Because
the available bandwidth is limited, you must devise an
appropriate strategy for efficient bandwidth use. In a network
with remote sites that use interactive traffic for daily
business, bandwidth availability is an issue. The available
bandwidth resources need to be used efficiently. Because only
simple services are run, basic queuing techniques, such as PQ
or CQ, and header compression mechanisms, such as TCP header
compression, are needed to use the bandwidth much more
efficiently. Note
PQ and CQ are traditional Cisco
priority mechanisms that have been mostly replaced by more
advanced mechanisms, such as weighted fair queuing (WFQ),
CBWFQ, and LLQ. Depending on the kind of traffic in the
network, you must choose suitable queuing and compression
mechanisms. In the example in Figure , CQ and TCP header
compression are a strategy for interactive traffic quality
assurance. The output in Figure illustrates complex
configuration tasks that can be involved with using the CLI as
follows: - Each QoS feature needs a separate line. CQ
needs two lines: one line that sets up the queue list, in this
example for Telnet traffic, and a second line that binds the
queue list to an interface and activates the list.
- PPP
multilink configuration needs four lines and another line for
TCP header compression.
Content 3.4
Using MQC for Implementing QoS 3.4.3 Modular
QoS CLI The Cisco MQC allows users to create traffic
policies and then attach these policies to interfaces. A QoS
policy contains one or more traffic classes and one or more QoS
features. A traffic class classifies traffic, and the QoS
features in the QoS policy determine how to treat the
classified traffic. The Cisco MQC offers significant advantages
over the legacy CLI method for implementing QoS. By using MQC,
a network administrator can significantly reduce the time and
effort it takes to configure QoS in a complex network. Rather
than configuring “raw” CLI commands interface by interface, the
administrator develops a uniform set of traffic classes and QoS
policies that are applied on interfaces. The use of the Cisco
MQC allows the separation of traffic classification from the
definition of QoS policy. This capability enables easier
initial QoS implementation and maintenance as new traffic
classes emerge and QoS policies for the network evolve. Figure
summarizes these points. Figure summarizes the three steps to
follow when configuring QoS using Cisco MQC configuration. Each
step answers a question concerning the classes assigned to
different traffic flows: - Build a class map:
What traffic do we care about? The first step in QoS deployment
is to identify the interesting traffic, that is, classify the
packets. This step defines a grouping of network traffic—a
class-map in MQC terminology—with various classification tools:
Access Control Lists (ACLs), IP addresses, IP precedence, IP
Differentiated Services Code Point (DSCP), IEEE 802.1p,
Multiprotcol Label Switching Experimental bit (MPLS EXP), and
Cisco Network Based Application Recognition (NBAR). In this
step, you configure traffic classification by using the
class-map command.
- Policy map: What will
happen to the classified traffic? Decide what to do with a
group once you identify its traffic. This step is the actual
construction of a QoS policy—a policy-map in MQC terminology—by
choosing the group of traffic (class-map) on which to perform
QoS functions. Examples of QoS functions are queuing, dropping,
policing, shaping, and marking. In this step, you configure
each traffic policy by associating the traffic class with one
or more QoS features using the policy-map command.
- Service policy: Where will the policy apply? Apply
the appropriate policy map to the desired interfaces,
sub-interfaces, or Asynchronous Transfer Mode (ATM) or Frame
Relay Permanent Virtual Circuits (PVCs). In this step, you
attach the traffic policy to inbound or outbound traffic on
interfaces, subinterfaces, or virtual circuits by using the
service-policy command.
Figure is a simple
example of using the three-step process. The classification
step is modular and independent of what happens to the packet
after it is classified. For example, a defined policy map
contains various class maps and the configuration within a
policy map can be changed independently from the configuration
of a defined class map (and vice versa). Further, use of the
no policy-map command can disable an entire QoS policy.
Content 3.4 Using MQC for Implementing
QoS 3.4.4 Modular QoS CLI Step 1: Configuring
Class Maps Step 1 requires you to tell the router what
traffic gets QoS and to what degree. An ACL is the traditional
way to define any traffic for a router. A class-map defines the
traffic into groups with classification templates that are used
in policy maps where QoS mechanisms are bound to classes. You
can configure up to 256 class maps on a router. For example,
you might assign video applications to a class map called
Video, and e-mail application traffic to a class map called
Mail. You could also create a class map called VoIP
traffic and and include all of the VoIP protocols. Figure
summarizes these points. Use the class-map global
configuration command to create a class map. Identify class
maps with case-sensitive names. All subsequent references to
the class map must use the same name. Each class map contains
one or more conditions that define which packets belong to the
class. Figure shows the command syntax for the
class-map command. There are two ways of processing
conditions when there is more than one condition in a class
map: - Match all: Must meet all conditions to
bind a packet to the class.
- Match any: Meet at
least one condition to bind the packet to the class.
The default match strategy of class maps is match
all. The match commands specify various criteria for
classifying packets. Packets are checked to determine whether
they match the criteria that are specified in the match
commands. If a packet matches the specified criteria, that
packet is considered a member of the class and is forwarded
according to the QoS specifications set in the traffic policy.
Packets that fail to meet any of the matching criteria are
classified as members of the default traffic class. The Cisco
MQC does not necessarily require that users associate a single
traffic class to one traffic policy. Multiple types of traffic