The policy maps and class maps that AutoQoS generates do not always suit the needs of a network completely. In that case, you can modify the policy maps and class maps to meet the specific network requirements. Therefore, it is important to know how to fine-tune the configuration that Cisco AutoQoS generates. Some Cisco IOS show commands are specifically helpful for determining which parts of the configuration need modification.
Automation with Cisco AutoQoS
Cisco AutoQoS is capable of performing the following tasks and might generate appropriate configurations to accomplish them:
■ Defining the trust boundaries (or extended trust boundaries) and re-marking incoming traffic on trusted and untrusted links
■ Defining traffic classes based on the applications and protocols discovered in the network
■ Creating queuing mechanisms with proper configurations such as bandwidth guarantee for each traffic type, based on the DiffServ model
■ Enabling interface-specific transport features, such as LFI, Multilink PPP (MLP), cRTP, TCP Header compression, traffic shaping, and Frame Relay traffic shaping (FRTS), when necessary based on link bandwidth and encapsulation
■ Defining alarms and event logging settings for monitoring purposes
■ Defining CoS-to-DSCP mappings (or other required mappings), DSCP-to-egress queue mappings, and the proper queue sizes and WRR weights on Cisco Catalyst LAN switches
Based on Cisco best-practices recommendations and the discovered application and protocol types, AutoQoS can enable six QoS mechanisms using DiffServ technology. Table 7-4 shows the six DiffServ functions and the corresponding Cisco IOS features that AutoQoS can enable for that function.
Table 7-4 DiffServ Functions and Cisco IOS Features That AutoQoS Enables
|
DiffServ Function |
Cisco IOS QoS Feature That AutoQoS Uses |
|
Classification |
Using NBAR (on untrusted links) Using IP precedence, DSCP, or CoS (trusted) |
|
Marking |
Class-based marking |
|
Congestion management |
LLQ (Strict PQ + CBWFQ) using percentage BW WRR (on Catalyst LAN switches) |
|
Shaping |
CBTS1 FRTS2 |
|
Congestion avoidance |
WRED3 |
|
Link efficiency |
LFI MLP cRTP |
1 CBTS = class-based traffic shaping
2 FRTS = Frame Relay traffic shaping
3 WRED = weighted random early detection
Using MQC, AutoQoS defines up to 10 traffic classes based on packet marking on trusted links or using NBAR on untrusted links. Classified packets are marked at trust boundary spots (as close to the traffic source as possible), preferably in the wiring closet switches and IP phones. Table 7-5 shows the ten classes of traffic that AutoQoS can define along with the DSCP and CoS values that AutoQoS assigns to them. The number of traffic classes defined depends on the results of the discovery phase.
Table 7-5 Traffic Classes That AutoQoS Defines
|
Class Name |
Traffic Type |
DSCP Value |
CoS Value |
|
IP Routing |
Network control traffic such as routing protocols |
CS6 |
6 |
|
Interactive Voice |
Interactive voice bearer traffic |
EF |
5 |
|
Interactive Video |
Interactive video data traffic |
AF41 |
4 |
Table 7-5 Traffic Classes That AutoQoS Defines
|
Class Name |
Traffic Type |
DSCP Value |
CoS Value |
|
Streaming Video |
Streaming media traffic |
CS4 |
4 |
|
Telephony Signaling |
Telephony signaling and control traffic |
CS3 |
3 |
|
Transactional and Interactive |
Database applications that are transactional in nature |
AF21 |
2 |
|
Network Management |
Network management traffic |
CS2 |
2 |
|
Bulk Data |
Bulk data transfers, web traffic, general data service |
AF11 |
1 |
|
Scavenger |
Entertainment, rogue traffic, and less than best-effort traffic |
CS1 |
1 |
|
Best Effort |
All noncritical and miscellaneous traffic |
BE |
0 |
To ensure predictable network behavior and good voice (and video) quality while providing the appropriate amount of bandwidth to Enterprise applications, especially during congestion, AutoQoS enables the most modern queuing mechanisms—LLQ and WRR—where they are needed. Voice traffic is treated as DiffServ EF with highest priority and placed in a strict priority queue with a guaranteed but policed bandwidth. Signaling and enterprise data traffic are treated as DiffServ AF classes, and CBWFQ is utilized for those classes, giving each class a separate queue with minimum bandwidth guarantees. Unclassified traffic is treated as DiffServ BE and is assigned to the default class. The bandwidth allocations are done using a percentage of the link bandwidth for better scalability and manageability reasons. On LAN switches, WRR is utilized with a priority queue for real-time traffic. Also, AutoQoS uses modifiable CoS-to-DSCP and DSCP-to-CoS mappings within Cisco LAN switches.
AutoQoS enables FRTS where it is needed. FRTS is especially important for two reasons:
■ The interface clock rate (physical speed) is usually higher than the committed information rate (CIR). As stated before, correct bandwidth configuration on serial interfaces and sub-interfaces is necessary before activation of AutoQos on those interfaces.
■ Enterprise sites are usually connected in a hub-and-spoke topology, and traffic flows from one or many sites to another site can cause congestion and data loss at the destination site.
WRED is the congestion avoidance technique that AutoQoS deploys to avoid tail drop and congestion at network bottleneck areas. Global synchronization and dropping of high-priority packets are the mitigation targets of congestion avoidance using WRED. AutoQoS deploys link-efficiency mechanisms to address insufficient bandwidth and long delays on slow links. The link-efficiency mechanisms that AutoQoS deploys include LFI, MLP, Frame Relay fragmentation, and cRTP.
Common AutoQoS Problems
AutoQoS was developed to automate QoS configuration for common enterprise network scenarios. Therefore, the configuration that AutoQoS yields does not necessarily suit and satisfy the requirements of every network. Following are the three most common Cisco AutoQoS issues that might arise:
■ Too many traffic classes are generated; classification is overengineered.
■ The configuration that AutoQoS generates does not adapt automatically to changing network traffic conditions.
■ The configuration that AutoQoS generates fits common network scenarios but does not fit some circumstances, even after extensive autodiscovery.
Based on the traffic and protocol types discovered during the autodiscovery phase, AutoQoS can generate up to ten traffic classes. Most enterprises, to keep the configurations simple and manageable, deploy only three to six traffic classes. Currently, AutoQoS does not have a knob to let you configure the maximum number of classes to be generated. However, it is recommended that if the number of generated traffic classes is too many for your needs, you should modify the AutoQoS-generated configuration and reduce the number of traffic classes. You can consolidate two or more similar traffic classes into a common class.
AutoQoS generates QoS templates and policies based on the device configuration at the time AutoQoS was enabled and based on the network applications and protocols detected at the time autodiscovery was run. Therefore, it is recommended that configurations such as interface bandwidth be done carefully, and before the AutoQoS discovery is allowed to run for as long as possible (preferably several days). If the device configuration changes, or if network traffic conditions change, AutoQoS-generated configuration will not adapt to the changes. However, if you disable AutoQoS, rerun the AutoQoS discovery, and enable AutoQoS again, the AutoQoS will generate its templates and policies based on the new network conditions.
If AutoQoS-generated configuration does not suit your network needs and circumstances, you might have to give the autodiscovery phase more time for a more thorough discovery and classification. However, letting the autodiscovery run for a long time does not always solve this problem. This is because the AutoQoS was developed for most common Enterprise networks and based on Cisco best-practice recommendations, but it does not necessarily meet the special requirements of all networks. To solve this problem, you can modify the configuration that AutoQoS generates. The AutoQoS-generated configuration is MQC compliant, and you can use MQC to enhance the configuration to meet your specific needs.
Interpreting and Modifying AutoQoS Configurations
The show auto qos command displays all the QoS mechanisms (and the corresponding configurations) that Cisco AutoQoS has enabled on a router, with or without autodiscovery. Therefore, you can inspect all the QoS templates that were generated as a result of applying Cisco AutoQoS. You can gather several particular facts from the output of the show auto qos command, the most important of which are these:
■ The number of traffic classes.
■ The classification options used.
■ The traffic markings performed.
■ The queuing mechanisms generated and the options used.
■ Other QoS mechanisms, such as traffic shaping, applied per traffic class.
■ Other traffic parameters, such as CIR, suggested for a Frame Relay connection.
■ The interface, subinterface, or virtual circuit where the policies are applied.
The number of traffic classes that AutoQoS identifies is recognized based on the number of class maps that have been generated. The match and set statements within each class map reveal the classification options used and the class-based markings performed. From within the policy maps, you can observe the queue types generated and the corresponding parameters; the priority and bandwidth commands reveal the queue type and the amount of bandwidth guarantee for each queue. From within the policy maps, you can also observe other QoS mechanisms, such as class-based shaping, congestion avoidance (WRED), or link efficiency mechanisms (LFI or cRTP) applied to each traffic class. You can discover traffic parameters such as the CIR or committed burst applied to a Frame Relay map class—in other words, suggested by AutoQoS—by inspecting the show auto qos command output. The output of this command also shows the actual interface, subinterface, or virtual circuit where the policies that AutoQoS generates are applied. Finally, the Remote Monitoring (RMON) traps that are logged for voice packet drops are displayed in the output of the show auto qos command.
Using Cisco IOS command-line interface (CLI), you can modify the class maps, policy maps, and traffic parameters that AutoQoS generates. You might have to do this for two major reasons:
■ The AutoQoS-generated commands do not completely satisfy the specific requirements of the Enterprise network.
■ The network condition, policies, traffic volume and patterns, and so on might change over time, rendering the AutoQoS-generated configuration dissatisfying.
If the network engineers (or administrators) have the ability and the expertise to modify and adapt the AutoQoS-generated configuration, they will not need to redeploy the whole AutoQoS procedure again. You can modify and tune the AutoQoS-generated class maps and policy maps by doing the following:
■ Using Cisco QoS Policy Manager (QPM).
■ Directly entering the commands one at the time at the router CLI using MQC.
■ Copying the existing configuration, a class map for example, into a text editor and modifying the configuration using the text editor, offline. Next, using CLI, remove the old undesirable configuration and then add the new configuration by copying and pasting the text from the text editor. This is probably the easiest way to modify and tune the AutoQoS-generated class maps and policy maps.
For classification purposes, in addition to using NBAR and ACLs, MQC offers more classification options that you can use for tuning. Some of those classification options and their corresponding match statements are as follows:
■ Based on the specific ingress interface where the traffic comes from:
■ Based on the Layer 2 CoS value of the traffic:
■ Based on the Layer 3 IP precedence value:
■ Based on the Layer 3 IP DSCP value:
■ Based on the RTP port value range:
The modifying and tuning of the configuration that AutoQoS generates will probably take a few rounds of modification and testing before it fully satisfies your requirements. Figure 7-1 shows a flowchart about using AutoQoS, verifying its auto-generated commands, and modifying the auto-generated commands if necessary.
Figure 7-1 Verifying and Modifying AutoQoS-Generated Configurations
The procedure for modifying an existing, active classification or policy that AutoQoS generates can be summarized into a three-step process:
Step 1 Review the existing QoS policy, identify the new requirements, and outline the configuration modifications necessary.
Step 2 Modify the AutoQoS-generated configuration according to the new requirements.
Step 3 Review the new (modified) configuration.
Please note that if you modify the AutoQoS-generated configuration, the AutoQoS generated commands will not be removed properly when you enter the no auto qos command. The no auto qos command only removes the original (unmodified) commands that AutoQoS generated.
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.
Cisco AutoQoS is an automation tool for deploying QoS policies. Following are the key benefits of Cisco AutoQoS:
■ Uses Cisco IOS built-in intelligence to automate generation of QoS configurations for most common business scenarios
■ Protects business-critical data applications in the Enterprise to maximize their availability
■ Simplifies QoS deployment
■ Reduces configuration errors
■ Makes QoS deployment cheaper, faster, and simpler
■ Follows the DiffServ model
■ Allows customers to have complete control over their QoS configuration
■ Enables customers to modify and tune the configurations that Cisco AutoQoS automatically generates to meet their specific needs or changes in the network conditions
The two phases of Cisco AutoQoS evolution are as follows:
1. AutoQoS VoIP
This was the first phase of AutoQoS.
One command provisions the basic required QoS commands.
It is supported across a broad range of router and switch platforms.
2. AutoQoS for Enterprise
This is the second phase of AutoQoS.
It extends the AutoQoS capabilities for data, voice, and video.
It is, however, supported only on routers.
It is deployed in a two-step process. In the first step, called autodiscovery, it discovers the traffic types and loads using NBAR protocol discovery. In the second step, it generates and implements QoS policies.
Cisco AutoQoS addresses five key elements of QoS deployment:
■ Application classification
■ Policy generation
■ Configuration
■ Monitoring and reporting
■ Consistency
AutoQoS for Enterprise uses NBAR protocol discovery. NBAR protocol discovery analyzes traffic in real-time, identifies approximately 100 Layer 4 through 7 applications and protocols using stateful and deep packet inspection, and provides bidirectional, per-interface, and per-protocol statistics. NBAR protocol discovery is able to identify and classify all of the following application types:
■ Applications that target a session to a well-known (UDP/TCP) destination port number, referred to as static port applications
■ Applications that start a control session using a well-known port number but negotiate another port number for the session, referred to as dynamic port applications
■ Some non-IP applications
■ HTTP applications based on URL, MIME type, or host name
You can enable Cisco AutoQoS Enterprise on certain types of interfaces and permanent virtual circuits (PVCs) only. These are the interface and PVC types that you can enable AutoQoS Enterprise for on a Cisco router:
■ Serial interfaces with PPP or HDLC encapsulation.
■ Frame Relay point-to-point subinterfaces. (Multipoint is not supported.)
■ ATM point-to-point subinterfaces (PVCs) on both slow (<=768 kbps) and fast serial (>768 kbps) interfaces.
■ Frame Relay-to-ATM interworking links.
Following are the router prerequisites for configuring Cisco AutoQoS:
■ The router cannot have a QoS policy attached to the interface.
■ You must enable CEF on the router interface (or PVC).
■ You must specify the correct bandwidth on the interface or subinterface.
■ You must configure a low-speed interface (<= 768 Kbps) and an IP address. You deploy AutoQoS for Enterprise on Cisco routers in two steps (or two phases):
Step 1 Traffic is profiled using autodiscovery.
You do this by entering the auto qos discovery command in the interface configuration mode.
Step 2 MQC-based QoS policies are generated and deployed.
You do this by entering the auto qos command in interface configuration mode.
On Cisco LAN switches, AutoQoS VoIP is enabled on each interface using the auto qos voip [trust I cisco-phone] command. The trust keyword is used for trusted connections such as an uplink to a trusted switch or router so that the ingress VoIP packet marking is trusted. You use the cisco-phone keyword for Cisco IP phone connections and to enable the trusted boundary feature. You use CDP to detect the presence or absence of a Cisco IP phone.
The commands for verifying Cisco AutoQoS on routers are as follows:
■ show auto discovery qos
Allows you to examine autodiscovery results
■ show auto qos
Allows you to examine Cisco AutoQoS templates and initial configuration
■ show policy-map interface
Allows you to explore interface statistics for autogenerated policy The commands for verifying Cisco AutoQoS on Cisco LAN switches are as follows:
■ show auto qos
Allows you to examine Cisco AutoQoS templates and initial configuration
■ show policy-map interface
Allows you to explore interface statistics for autogenerated policy
■ show mls qos maps
Allows you to examine CoS-to-DSCP maps
The three most common Cisco AutoQoS issues that might arise, and their corresponding solutions, are as follows:
■ Too many traffic classes are generated; classification is overengineered.
Solution: Manually consolidate similar classes to produce the number of classes needed.
■ The configuration that AutoQoS generates does not automatically adapt to changing network traffic conditions.
Solution: Run Cisco AutoQoS discovery on a periodic basis, followed by re-enabling of Cisco AutoQoS.
■ The configuration that AutoQoS generates fits common network scenarios but does not fit some circumstances, even after extensive autodiscovery
Solution: Manually fine-tune the AutoQoS-generated configuration.
You examine the AutoQoS-generated configuration using the show auto qos command, which provides the following information:
■ Number of traffic classes identified (class maps)
■ Traffic classification options selected (within class maps)
■ Traffic marking options selected (within policy maps)
■ Queuing mechanisms deployed and their corresponding parameters (within policy maps)
■ Other QoS mechanisms deployed (within policy maps)
■ Where the autogenerated policies are applied: on the interface, subinterface, or PVC You might have to modify the configuration that AutoQoS generates for two reasons:
■ The AutoQoS-generated commands do not completely satisfy the specific requirements of the Enterprise network.
■ The network condition, policies, traffic volume and patterns, and so on might change over time, rendering the AutoQoS-generated configuration dissatisfying.
You can modify and tune the AutoQoS-generated class maps and policy maps by doing the following:
■ Using Cisco QoS Policy Manager (QPM).
■ Directly entering the commands one at a time at the router command-line interface using MQC.
■ Copying the existing configuration, a class map for example, into a text editor and modifying the configuration using the text editor offline. Next, using CLI, remove the old undesirable configuration and then add the new configuration by copying and pasting the text from the text editor. This is probably the easiest way.
For classification purposes, in addition to using NBAR and ACLs, you can use the following classification options that MQC offers for tuning:
■ Based on the specific ingress interface where the traffic comes from:
■ Based on the Layer 2 CoS value of the traffic:
■ Based on the Layer 3 IP precedence value:
■ Based on the Layer 3 IP DSCP value:
■ Based on the RTP port value range:
