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 Business-Application. It specifies that traffic matching access-list 101 is classified as Business-Application.
Example 2-1 Class Maps
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 Enterprise-Policy. 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.
Example 2-2 Policy Map
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.
Example 2-3 Service-Policy
The following commands allow you to display and verify QoS classes and policies you have configured using the MQC:
show class-map—This command displays all the configured class maps. show policy-map—This command displays all the configured policy maps.
show policy-map interface interface—This command displays the policy map that is applied to a particular interface using the service-policy command. This command also displays QoS interface statistics.
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:
■ Classification—AutoQoS 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 generation—It 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.
■ Configuration—It 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 reporting—It generates system logging messages, SNMP traps, and summary reports.
■ Consistency—The 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 round-robin (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 router’s hardware, software, and the available features. For example, you can see the router’s 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 router’s LAN and WAN interfaces, firewall policies, VPN, routing, and IPS configurations. You can also see the router’s 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
■ Security Audit
■ Intrusion Prevention
■ Quality of Service
■ Additional Tasks
The tasks available on the left side of the Monitor page are:
■ Interface Status
■ Firewall Status
■ VPN Status
■ Traffic Status
■ NAC Status
■ 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.
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-effort—The 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.
■ IntServ—IntServ 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.
■ DiffServ—DiffServ 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 network’s
■ Cisco IOS CLI—Configuring QoS using Cisco IOS CLI is the most complex and time-consuming method. It requires that you learn different syntax for each QoS mechanism.
■ MQC—MQC 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 AutoQoS—Because 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 Wizard—Cisco 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 fine-tune their results, how time consuming they are, and how modular they are.
Table 2-3 Comparing QoS Implementation Methods
Ease of use
Easier than legacy CLI
Ability to fine-tune
Time consuming to implement
Most time consuming (longest)
Moderate time consumed (average)
Least time consuming
Very little time
Very modular (excellent)
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.