0% found this document useful (0 votes)
134 views

QoS Implementation Methods

This document discusses and compares four methods for implementing Quality of Service (QoS): legacy command-line interface (CLI), modular QoS command-line interface (MQC), Cisco AutoQoS, and SDM QoS Wizard. Legacy CLI was error-prone and time-consuming. MQC improved on legacy CLI by making the configuration modular and reusable. AutoQoS simplifies QoS configuration by automatically generating the necessary commands. The SDM QoS Wizard is a graphical tool that performs the same automatic command generation as AutoQoS.
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
134 views

QoS Implementation Methods

This document discusses and compares four methods for implementing Quality of Service (QoS): legacy command-line interface (CLI), modular QoS command-line interface (MQC), Cisco AutoQoS, and SDM QoS Wizard. Legacy CLI was error-prone and time-consuming. MQC improved on legacy CLI by making the configuration modular and reusable. AutoQoS simplifies QoS configuration by automatically generating the necessary commands. The SDM QoS Wizard is a graphical tool that performs the same automatic command generation as AutoQoS.
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 16

QoS Implementation Methods (IP Quality of Service)

This section explores the four main QoS implementation


methods, namely CLI, MQC, Cisco AutoQoS, and SDM QoS Wizard. A
high-level explanation of each QoS implementation method and the
advantages and disadvantages of each are provided in turn.
Legacy Command-Line Interface (CLI)
Legacy CLI was the method used up to about six years ago to
implement QoS on network devices. Legacy CLI requires configuration
of few to many lines of code that for the most part would have to be
applied directly at the interface level. Configuration of many
interfaces required a lot of typing or cutting and pasting. Maintaining
consistency, minimizing errors, and keeping the configuration neat
and understandable were difficult to do using legacy CLI.
Legacy CLI configuration required the user to log into the router
via console using a terminal (or a terminal emulator) or via a virtual
terminal line using a Telnet application. Because it was a nonmodular
method, legacy CLI did not allow users to completely separate traffic
classification from policy definition and how the policy is applied.
Legacy CLI was also more error prone and time consuming. Today,
people still use CLI, but mostly to fine-tune the code generated by
AutoQoS, which will be discussed later.
You began legacy CLI configuration by identifying, classifying,
and prioritizing the traffic. Next, you had to select one of the available
and appropriate QoS tools such as link compression or an available
queuing mechanism such as custom or priority queuing. Finally, you
had to enter from a few to several lines of code applying the selected
QoS mechanisms for one or many interfaces.
Modular QoS Command-Line Interface (MQC)
Cisco introduced MQC to address the shortcomings of the legacy
CLI and to allow utilization of the newer QoS tools and features
available in the modern Cisco IOS. With the MQC, traffic classification
and policy definition are done separately. Traffic policies are defined
after traffic classes. Different policies might reference the same traffic
classes, thereby taking advantage of the modular and reusable code.
When one or more policies are defined, you can apply them to many
interfaces, promoting code consistency and reuse.
MQC is modular, more efficient, and less time consuming than
legacy CLI. Most importantly, MQC separates traffic classification from
policy definition, and it is uniform across major Cisco IOS platforms.
With MQC, defined policies are applied to interfaces rather than a
series of raw CLI commands being applied to interfaces.

Implementing QoS with MQC involves three major steps:


Step 1 Define traffic classes using the class-map command. This step
divides the identified network traffic into a number of named classes.
Step 2 Define QoS policies for the defined traffic classes using the
policy-map command. This step involves QoS features being linked to
traffic classes. It defines the treatment of the defined classes of
traffic.
Step 3 Apply the defined policies in the inbound or outbound
direction to each intended interface, subinterface, or circuit, using the
service-policy command. This step defines where the defined policies
are applied.
Each class map, which has a case-sensitive name, is composed of
one or more match statements. One or all of the match statements
must be matched, depending on whether class map contains the
match-any or the match-all command. When neither match-any nor
match-all is specified on the class-map statement, match-all applies
by default.
Example 2-1 shows two class maps. The first class map is called
VOIP. This class map specifies that traffic matching access list 100 is
classified as VOIP. The second class map is called BusinessApplication. It specifies that traffic matching access-list 101 is
classified as Business-Application.

In Example 2-1, note that both of the class maps have only one
match statement, and neither match-all nor match-any is specified,
which defaults to match-all. When only one match statement exists,
match-all and match-any yield the same result. However, when more
than one match statement exists, using match-any or match-all
makes a big difference. match-any means only one of the match
statements needs to be met, and match-all means all the match
statements must be met to bind the packet to the class.
NOTE The opposite of the match condition is the match not condition.

You create traffic policies by associating required QoS features to


traffic classes defined by class maps; you use the policy-map
command to do that. A policy map has a case-sensitive name and can
associate QoS policies for up to 256 traffic classes (each defined by a
class map). Example 2-2 exhibits a policy map called EnterprisePolicy. This policy map specifies that traffic classified as
VOIP is assigned to a priority queue that has a bandwidth
guarantee of 256 Kbps. Enterprise-Policy also states that the traffic
classified as Business-Application is assigned to a WFQ with a
bandwidth guarantee of 256 Kbps. According to this policy map, all
other traffic, classified as class-default, will be assigned to a queue
that gets the rest of the available bandwidth, and a WFQ policy will be
applied to it.

If you configure a policy map that includes a class statement


followed by the name of a nonexistent class map, as long as the
statement includes a condition, a class map is created and inserted
into the configuration with that name automatically. If, within a policy
map, you do not refer to the class-default (and do not configure it),
any traffic that the defined classes do not match will still be treated
as class-default. The class-default gets no QoS guarantees and can
use a FIFO or a WFQ.
A policy map is applied on an interface (or subinterface, virtual
template, or circuit) in the outbound or inbound direction using the
service-policy command (and the direction specified using the input
or output keywords). You can apply a defined and configured policy
map to more than one interface. Reusing class maps and policy maps
is highly encouraged because it promotes standardization and
reduces the chance of errors. Example 2-3 shows that the policy map
Enterprise-Policy is applied to the serial 1/0 interface of a router on
the outbound direction.

The following commands allow you to display and verify QoS


classes and policies you have configured using the MQC:
show class-mapThis command displays all the configured class
maps. show policy-mapThis command displays all the configured
policy maps.
show policy-map interface interfaceThis command displays the
policy map that is applied to a particular interface using the servicepolicy command. This command also displays QoS interface statistics.

AutoQoS
AutoQoS is a value-added feature of Cisco IOS. After it is enabled
on a device, AutoQoS automatically generates QoS configuration
commands for the device. The initial release of AutoQoS (Auto QoS
VoIP) focused on generating commands that made the device ready
for VoIP and IP Telephony. Later, the AutoQoS Discovery feature was
introduced. The next generation of AutoQoS that takes advantage of
AutoQoS discovery is called AutoQoS for the Enterprise. AutoQoS
Discovery, as its name implies, analyzes live network traffic for as
long as you let it run and generates traffic classes based on the traffic
it has processed. Next, you enable the AutoQoS feature. AutoQoS
uses the traffic classes (class maps) formed by AutoQoS Discovery to
generate network QoS policy (policy map), and it applies the policy.
Based on the interface type, AutoQoS might also add features such as
fragmentation and interleaving, multilink, and traffic shaping to the
interface configuration.
The main advantage of AutoQoS is that it simplifies the task of
QoS configuration. Network administrators who lack in-depth
knowledge of QoS commands and features can use AutoQoS to
implement those features consistently and accurately. AutoQoS
participates in all the main aspects of QoS deployment:
ClassificationAutoQoS for the Enterprise, through AutoQoS
Discovery, automatically discovers applications and protocols (using
Network Based Application Recognition, or NBAR). It uses Cisco
Discovery Protocol (CDP) to check whether an IP phone is attached to
a switch port.
Policy generationIt provides appropriate treatment of traffic by
the QoS policies that it auto-generates. AutoQoS checks interface
encapsulations, and accordingly, it considers usage of features such
as fragmentation, compression, and traffic shaping. Access lists, class
maps, and policy maps, which normally have to be entered manually,
are automatically generated by AutoQoS.

ConfigurationIt is enabled by entering only one command, auto


qos, at the interface. In a matter of seconds, proper commands to
classify, mark, prioritize, preempt packets, and so on are added to the
configuration appropriately.
Monitoring and reportingIt generates system logging
messages, SNMP traps, and summary reports.
ConsistencyThe commands generated on different routers,
using AutoQoS, are consistent and interoperable.
AutoQoS was introduced in Cisco IOS Software Release 12.2(15)T
and provides a quick and consistent way to enter the bulk of QoS
commands. Network administrators can then modify those commands
and policies or optimize them using CLI. Cisco SDM QoS Wizard is a
newer GUI tool that generates QoS commands and policies; that tool
will be discussed in the next section.
AutoQoS performs a series of functions on WAN devices and
interfaces. It creates a traffic class for voice payload (RTP), and it
builds another class for voice signaling (Skinny, H.323, SIP, and
MGCP). Service policies for voice bearer and voice signaling are
created and deployed using LLQ with bandwidth guarantees. Voice
traffic is assigned to the priority queue. On Frame Relay connections,
AutoQoS turns on Frame Relay traffic shaping (FRTS) and link
fragmentation and interleaving (LFI); on other types of links, such as
PPP links, AutoQoS might turn on multilink PPP (MLP) and compressed
RTP (cRTP). AutoQoS also provides SNMP and syslog alerts for VoIP
packet drops.
In LAN environments, AutoQoS trust boundaries are set and
enforced on the different types of switch ports, such as access ports
and uplinks. Expedited queuing (strict priority) and weighted roundrobin (WRR) are also enforced where required. Traffic is assigned to
the proper queue based on its marking or application recognition
based on NBAR.
Using AutoQoS has some prerequisites. Before you enable
AutoQoS on an interface, you must ensure that the following
tasks have been completed:
Cisco Express Forwarding (CEF) is enabled. CEF is the
prerequisite for NBAR.
NBAR is enabled. AutoQoS for the Enterprise (not Auto QoS VoIP)
uses NBAR for traffic discovery and classification.
The correct bandwidth on the interface is configured. AutoQoS
configures LLQ, cRTP, and LFI based on the interface type and the
interface bandwidth. On certain interfaces, such as Ethernet, the
bandwidth is auto-sensed; however, on other interfaces, such as

synchronous serial interface, if the bandwidth is not specified, the IOS


assumes a bandwidth of 1544 Kbps.
After these tasks have been completed, AutoQoS can be
configured (enabled) on the desired interface. Example 2-4 shows a
serial interface that has been configured with bandwidth, IP address,
CEF, and AutoQoS.
Example 2-4 Configuring AutoQoS on an Interface

Note that in Example 2-4, the command auto qos voip is applied to
interface serial 1/0. This command represents the first generation of
AutoQoS. The focus of auto qos voip was to automate generation of
QoS commands to get the device ready for VoIP traffic. In the second
generation AutoQoS for the Enterprise, you must first enter the auto
discovery qos so that the router discovers and analyzes network
traffic entering the interface using NBAR. Next, you enter the auto qos
command. When you enter the auto qos command on an interface,
the router builds class maps (based on the results of discovery) and
then creates and applies a policy map on the interface.
Router and Security Device Manager (SDM) QoS Wizard
Cisco SDM is a web-based device-management tool for Cisco routers.
With SDM, router deployment and troubleshooting of network and
VPN connectivity issues becomes simpler. Proactive management
through performance monitoring is also accomplished using SDM.
Cisco SDM supports a range of Cisco IOS Software releases and
is available on many Cisco router models (from Cisco 830 Series to
Cisco 7301); on several router models, SDM is preinstalled. Cisco SDM
offers smart wizards that provide step-by-step assistance for
configuration of LAN and WAN interfaces, Network Address Translation
(NAT), firewall policy, IPS, IPsec VPN, and QoS. Inexperienced users
find the SDM GUI easier to use than the CLI and enjoy the
comprehensive online help and tutorials for SDM.
The QoS Wizard of SDM provides you with an easy-to-use user
interface to define traffic classes and configure QoS policies for your
network. The SDM predefines three different application categories:
real-time, business-critical, and best-effort. SDM supports and uses
NBAR to validate the bandwidth consumed by different application
categories. Additional features offered by the SDM QoS Wizard include

QoS policing and traffic monitoring. The SDM QoS Wizard enables you
to do three things:
Implement QoS
Monitor QoS
Troubleshoot QoS on your network
Figure 2-3 displays the main page of Cisco SDM. This page is
comprised of two sections:
About Your Router
Configuration Overview
Figure 2-3 Main Page of Cisco SDM

In the About Your Router section of the SDM main page you can
find information about your routers hardware, software, and the
available features. For example, you can see the routers total and
available memory, flash capacity, IOS version, SDM version, and
whether features such as IP, firewall, VPN, IPS, and NAC are available.
Further information can be seen through the More options in the
hardware and software sections. The Configuration Overview section
of the SDM main page provides information about your routers LAN
and WAN interfaces, firewall policies, VPN, routing, and IPS

configurations. You can also see the routers running configuration


through the View Running Config option. You can navigate to the main
page by pressing the Home button on the main tool bar of the Cisco
SDM. The other two important buttons on the Cisco SDM main tool bar
are the Configure and Monitor buttons. The tasks available on the left
side of the Configure page are:

Interfaces and Connections


Firewall and ACL
VPN
Security Audit
Routing
NAT
Intrusion Prevention
Quality of Service
NAC
Additional Tasks

The tasks available on the left side of the Monitor page are:
Overview
Interface Status
Firewall Status
VPN Status
Traffic Status
NAC Status
Logging
IPS Status
If you select the Traffic Status task, you will have the option to view
graphs about QoS or application/protocol traffic.
The remainder of this section takes you through the steps necessary
to create a QoS policy, apply it to an interface, and monitor the QoS
status using the Cisco SDM (GUI) Wizard. For each step one or more
figures are provided so that you are well prepared for the exam
questions that might be asked about creating QoS policy using the
SDM Wizard.
To begin to create a QoS policy you must complete the
following steps:
Step 1 Click the Configure button on the main toolbar of SDM.
Step 2 Click the Quality of Service button on the tasks toolbar on the
left side of the SDM window (in Configuration mode; see Figure 2-4).
Step 3 Click the Create QoS Policy tab in the middle section of the
SDM window (see Figure 2-4).

Step 4 Click the Launch QoS Wizard button on the bottom right side
of the SDM window (see Figure 2-4).
Figure 2-4 Four Steps to Start Creating a QoS Policy with SDM

Now the SDM QoS Wizard page pops up on your computer screen
(see Figure 2-5) and it informs you that SDM by default creates QoS
policy to handle two main types of traffic, namely Real-Time and
Business-Critical. To proceed press the Next button.
Figure 2-5 SDM QoS Wizard Initial Page

The QoS Wizard asks you to select an interface on which you


want the QoS policy to be applied. Figure 2-6 shows you this screen.
After making your selection press the Next button on that screen to
proceed.
Figure 2-6 Interface Selection Page of SDM QoS Wizard
The SDM QoS Wizard asks you to enter the bandwidth percent for
Real Time and Business-Critical traffic (see Figure 2-7). SDM will then
automatically compute the bandwidth percent for the Best-Effort
traffic and the actual bandwidth (kbps) for all three traffic classes.
Figure 2-7 QoS Policy Generation Page of SDM QoS Wizard

After you press Next the new page shows a summary of the
configuration applied to the interface you have previously selected for
the policy (see Figure 2-8). On this page you can scroll down and up to
see the policy generated (and to be applied) in its entirety. Once you
press the Finish button.
After you press the Finish button on the SDM QoS summary of the
configuration screen, a Commands Delivery Status window appears
(see Figure 2-9). This screen first informs you that commands are
being prepared, then it tells you that the commands are being
submitted, and finally it tells you that the commands have been
delivered to the router. At this time, you can press the OK button and
the job is complete.
Figure 2-8 QoS Policy: Summary of the Configuration

Figure 2-9 QoS Policy: Commands Delivery Status

Upon completion of your QoS configuration tasks, SDM allows


you to monitor the QoS status. You must first click the Monitor button

of the SDM main tool bar. Next, from the list of available tasks you
must select Traffic Status (see Figure 2-10). Note that in the ONT
courseware, this option is shown as QoS Status, probably due to SDM
version differences. In the middle of the Traffic Status screen, you will
then notice a folder called Top N Traffic Flows with QoS and
Application/Protocol Traffic as two options displayed below it. If you
click QoS (effectively requesting to see the QoS status), you can then
choose any of the interfaces displayed in the Traffic Status screen and
see informative QoS-related graphs about the chosen interface.
Figure 2-10 SDM Monitor Traffic/QoS Status

When you select the QoS option of the Traffic Status, notice that on
the top right corner of the screen you can select the View Interval
(Now, Every 1 Minute, Every 5 Minutes, Every 1 Hour). Furthermore,
there is a small area with the "Select QoS Parameters for Monitoring"
title that allows you to select the Direction (input or output) of the
traffic, and the Statistics (bandwidth, byte, and packets dropped) for
which you want to see graphs.
Foundation Summary
The "Foundation Summary" is a collection of information that
provides a convenient review of many key concepts in this topic. If
you are already comfortable with the topics in this topic, this
summary can help you recall a few details. If you just read this topic,
this review should help solidify some key facts. If you are doing your

final preparation before the exam, the information in this section is a


convenient way to review the day before the exam.
In a converged enterprise network, four major issues affect the
performance and perceived quality of applications:

Available bandwidth
End-to-end delay
Variation of delay (jitter)
Packet loss

Lack of sufficient bandwidth, high end-to-end delay, high variation in


delay, and excessive packet loss lower the quality of applications.
QoS is the ability of the network to provide better or "special"
service to a set of users or applications or both to the detriment of
other users or applications or both. You can use several QoS features,
tools, and technologies to accomplish the QoS goals. Classification,
marking, congestion avoidance, congestion management,
compression, shaping, and policing are examples of QoS tools
available in Cisco IOS. The three steps of implementing QoS in an
enterprise network are as follows:
Step 1 Identify the network traffic and its requirements Step
2 Define traffic classes Step 3 Define a QoS policy for each
traffic class The main QoS models of today are as follows:
Best-effortThe best-effort model requires no QoS configuration
and mechanisms; therefore, it is easy and scalable, but it provides no
Differentiated Service to different application types.
IntServIntServ provides guaranteed service (Hard QoS). It uses
signaling to reserve and guarantee resources for each traffic flow
below it. RSVP is the common signaling protocol for resource
reservation signaling on IP networks. Per-flow signaling and
monitoring escalate the overhead of the IntServ model and make it
nonscalable.
DiffServDiffServ is the most modern of the three models. It
requires traffic classification and marking and providing differentiated
service to each traffic class based on its marking. DiffServ is scalable,
but its drawback is that it requires implementation of complex QoS
features on network devices throughout the network.
Network administrators have four methods at their disposal to
implement QoS on their networks
Cisco devices:
Cisco IOS CLIConfiguring QoS using Cisco IOS CLI is the most
complex and time-consuming method. It requires that you learn
different syntax for each QoS mechanism.

MQCMQC is a modular command-line interface that is common


across different Cisco platforms, and it separates the task of defining
different traffic classes from the task of defining QoS policies.
Cisco AutoQoSBecause AutoQoS automatically generates QoS
commands on your router or switch, it is the simplest and fastest
method among the four QoS implementation methods. However,
should you need to fine-tune the AutoQoS configuration results, you
must use MQC (or CLI) to do so. Fine-tuning of the commands that
AutoQoS generates is seldom necessary.
Cisco Router and Security Device Manager (SDM) QoS
WizardCisco SDM offers several wizards for implementing services,
such as IPsec, VPN, and proactive management through performance
monitoring, in addition to the QoS Wizard. Cisco SDM QoS Wizard
allows you to remotely configure and monitor your Cisco routers
without using the CLI. The SDM GUI makes it simple for you to
implement QoS services, features, and policies.
Table 2-3 compares Cisco IOS CLI, MQC, AutoQoS, and SDM with
respect to how easy they are to use, whether they allow you to finetune their results, how time consuming they are, and how modular
they are.

MQC is the recommended and the most powerful method for


implementing QoS. It is modular, it promotes re-use of written code,
and it facilitates consistency of QoS configurations among your Cisco

devices. MQC also reduces the chances for errors and conflicts, while
allowing you to take advantage of the latest features and mechanisms
offered by your version of Cisco IOS.

You might also like