classes designed to accommodate various enterprise
applications. The table lists the class name, the type of
traffic defined for the class, and the DSCP value for the type
of traffic, if applicable. Figure summarizes this table and
provides a corresponding CoS priority number. Class
Name Traffic Type DSCP Value IP routing
Network control traffic, such as routing protocols CS6
Interactive voice Interactive voice-bearer traffic EF
Interactive video Interactive video data traffic AF41 Streaming
video Streaming media traffic CS4 Telephony signaling Telephony
signaling and control traffic CS3 Transactional-interactive
Database applications that are transactional in nature AF21
Network management Network management traffic CS2 Bulk data
Bulk data transfers, web traffic, general data service AF11
Scavenger Casual entertainment, rogue traffic;
less-than-best-effort treatment for traffic in this category
CS1 Best effort Default class; all noncritical traffic, HTTP,
all miscellaneous traffic 0 These classes are used with the MQC
to define class maps after the classification criteria are
determined. These classes are also chosen to meet scheduling
requirements in compliance with DiffServ recommendations.
Note
The actual number of classes created
corresponds to the number of applications discovered during the
Auto Discovery phase.
Content 5.2
Mitigating Common Cisco AutoQoS Issues 5.2.4
Common Issues with Cisco AutoQoS Although Cisco AutoQoS
automates QoS deployment, it targets only the most common
enterprise network scenarios. The QoS classes and templates
that Cisco AutoQoS generates will not suit every network
requirement. The following three most common issues may arise
when you are using Cisco AutoQoS to generate enterprise
policies: - Cisco AutoQoS generates too many classes
and overengineers the classification: Cisco AutoQoS
generates up to 10 DiffServ classes, depending on the number
and types of applications and protocols that it detected during
the Auto Discovery phase. The vast majority of enterprise
networks today deploy only three to a maximum of six classes
in order to maintain configuration manageability. There is no
adjustment in Cisco AutoQoS to decrease the number of classes
it is allowed to generate. The only solution is to manually
consolidate similar classes to produce the required final
number of classes.
- Cisco AutoQoS generates QoS
templates based on conditions at the time of Auto
Discovery: Auto Discovery should be run for several days to
maximize the probability that Cisco AutoQoS will generate
policies based on conditions close to daily network reality.
All of the configurations that Cisco AutoQoS generates are
related solely to what was preconfigured (for example, the
bandwidth configured at the interface) and what was detected at
the time of Auto Discovery. If network conditions change after
Cisco AutoQoS has autogenerated the QoS templates, the Auto
Discovery phase and the QoS template deployment phase must be
repeated to adapt the configuration to the new traffic
conditions.
- Cisco AutoQoS, even after repeated and
extensive Auto Discovery, does not generate the expected QoS
templates: Cisco AutoQoS built-in intelligence is based on
Cisco best practices and the experience gained in the broad
enterprise customer base. However, there may be some special
exceptions; in particular, deployment requirements may go
beyond current capabilities or circumstances that are simply
undetectable because they require human-like intelligence. For
instance, classification may need to be based on a mix of
complex, specific parameters. In these special situations,
Cisco AutoQoS can be used to generate the initial class maps
and policy maps, which are then manually tuned to meet the
specific requirements. The autogenerated configuration is fully
compliant with Cisco MQC, and practically any MQC mechanism can
be used to supplement the classification or to extend a
policy.
Figure summarizes these issues and
solutions.
Content 5.2 Mitigating
Common Cisco AutoQoS Issues 5.2.5 Interpreting
Cisco AutoQoS Configurations To inspect the resulting QoS
templates after you apply Cisco AutoQoS, use the show auto
qos command. This command provides the ultimate information
about all QoS mechanisms and their parameters that Cisco
AutoQoS enabled based on the Auto Discovery results or simply
generated to improve QoS. The command is specifically used to
examine the following as shown in Figure : - How many
classes did Cisco AutoQoS identify? This value is visible as a
number of class maps.
- What traffic classification
options did Cisco AutoQoS select? This parameter is visible as
a match command option within the respective class
map.
- What traffic marking options did Cisco AutoQoS
select? You can see these options in the policy maps as a
set command option.
- What queuing mechanisms did
Cisco AutoQoS designate and what queuing parameters were
projected? You can see this information in the policy maps as
either bandwidth command or priority command
options with their individual parameter.
- Were any
other QoS mechanisms appointed to serve the class? The content
of policy maps can list some other mechanisms that Cisco
AutoQoS designated to handle the class traffic for best
application performance (for example, link efficiency
mechanisms or traffic shaping).
- Cisco AutoQoS can also
suggest some traffic parameters such as committed bursts and
CIR in Frame Relay networks, seen in the Frame Relay map
class.
- How did Cisco AutoQoS apply the autogenerated
policy to the existing router configuration? Cisco AutoQoS can
apply the autogenerated policy to a serial interface,
subinterface, data-link connection identifier (DLCI), or PVC.
This information is also provided in the show auto qos
command output.
How to Interpret the show auto
qos Command Output
Figure shows the command output of
the show auto qos command. The detailed output of the
show auto qos command varies depending on network and
traffic conditions where Cisco AutoQoS was enabled, but it
always has some common elements: - The command output
displays the autogenerated policy, applied in the form of the
MQC policy map. In this section, the selected queuing
mechanisms will be evident (LLQ or CBWFQ), but this section
can also show class-based marking, class-based shaping,
congestion avoidance (WRED), and link efficiency mechanisms
(cRTP or LFI). Each QoS mechanism appears in the generated
output in the same form that it would have if it were
configured manually with the MQC.
- The other important
section in the show auto qos command output is the
classification, shown in the form of an MQC class map. The
class map can use the NBAR classification option or the DSCP or
IP precedence option when Cisco AutoQoS was enabled in the
trusted mode. In either case, the match command is used
within individual class maps with the appropriate
parameters.
- In some special situations, such as those
shown in the output for a Frame Relay PVC , Cisco AutoQoS can
construct two policy maps, one nested in the other. The purpose
is to use class-based shaping to fit the traffic within
specific PVC traffic parameters while managing congestion using
proper queuing techniques.
Individual policy maps
and class maps are cross-referenced using names generated by
Cisco AutoQoS. RMON
Customers are often deluged with
mountains of data, but very little relevant information that
helps them to identify the root of a problem or any important
trends (such as traffic patterns and exceptions). Obtaining the
right information can be quite expensive, and it often arrives
too late to be useful. A classic example is finding out
"who" (that is, which user or IP address) is causing
congestion or creating abnormal loads on a link. Without
automation, it can take many months to establish an efficient