00 Combined Cisco QoS AAGs

Strategic QoS Design At-A-Glance
The Quality of Service Challenge Step 2: Define an End-to-End QoS Design Strategy RFC 4594 also provides some application classification
Today there is a virtual explosion of rich media Once applications have been defined as business-relevant rules to help network architects to assign applications to
applications on the IP network This explosion of content (or otherwise), then the network architect must decide how the optimal traffic classes; these are summarized in the
and media types, both managed and un-managed, to mark and treat these applications over the IP following sections:
requires network architects to take a new look at their infrastructure.
Quality of Service (QoS) designs. Business relevant application can be grouped into one of
To this end, Cisco advocates following relevant industry four main categories:
Step 1: Articulate Business Intent and standards and guidelines, as this extends the effectiveness • control plane protocols
Application Relevance of your QoS policies beyond your direct administrative • voice applications
The first step may seem obvious and superfluous, but in control. That being said, it may be helpful to overview a • video applications
actuality it is crucial: clearly define the business relevant RFC for QoS marking and provisioning: RFC 4594, • data applications
objectives that your QoS policies are to enable. These “Configuration Guidelines for DiffServ Service Classes.”
may include any/all of the following: Beginning with the control plane protocols, these may be
• Guaranteeing voice quality meets enterprise standards These guidelines are to be viewed as industry best-practice sub-divided further, as shown in Figure 3.
• Ensuring a high Quality of Experience (QoE) for video recommendations. As such, enterprises and service
providers are encouraged to adopt these marking and Figure 3 Control Plane Traffic Classes
• Increasing user productivity by increasing network
response times for interactive applications provisioning recommendations with the aim of improving
• Managing applications that are “bandwidth hogs” QoS consistency, compatibility, and interoperability.
• Identifying and de-prioritizing consumer applications However, it should be noted that these guidelines are not
• Improving network availability standards; as such, modifications can be made to these
• Hardening the network infrastructure recommendations as specific needs or constraints require.
• Network Control—This traffic class is intended for
With these goals in mind, network architects can clearly Thus, to meet specific business requirements, Cisco has
network control plane traffic, which is required for reliable
identify which applications are relevant to their business. made a minor modification to its adoption of RFC 4594:
operation of the enterprise network. Traffic in this class
Conversely, this exercise will also make it apparent specifically the swapping of Call-Signaling and Broadcast
should be marked CS6 and provisioned with a
which applications are not relevant towards achieving Video markings (to CS3 and CS5, respectively). A summary
(moderate, but dedicated) guaranteed bandwidth queue.
business objectives. Such applications may include of Cisco’s implementation of RFC 4594 is presented in
WRED should not be enabled on this class, as network
consumer-oriented and/or entertainment-oriented Figure 2.
control traffic should not be dropped. Example traffic
applications. includes EIGRP, OSPF, BGP, HSRP, IKE, etc.
Figure 2 Cisco (RFC 4594-Based) QoS Recommendations
Finally, there may be applications/protocols that can fall • Signaling—This traffic class is intended for signaling
into either category of business relevance. For example, Application Class
Per-Hop
Queuing and Dropping traffic that supports IP voice and video telephony. Traffic
HTTP/HTTPS may carry business-relevant traffic or Behavior
in this class should be marked CS3 and provisioned with
consumer-oriented traffic, and as such cannot be clearly Voice EF Priority Queue (PQ)
a (moderate, but dedicated) guaranteed bandwidth
classified in either category. Note: in such cases, deep Broadcast Video CS5 (Optional) PQ
queue. WRED should not be enabled on this class, as
packet inspection technologies may be able to Real-Time Interactive CS4 (Optional) PQ
signaling traffic should not be dropped. Example traffic
discretely identify the applications being transported, Multimedia Conferencing AF4 BW Queue + DSCP WRED
includes SCCP, SIP, H. 323, etc.
allowing these to be properly classified in line with Multimedia Streaming AF3 BW Queue + DSCP WRED
business objectives. Network Control CS6 BW Queue • Operations/Administration/Management (OAM)—
Call-Signaling CS3 BW Queue This traffic class is intended for network operations,
Figure 1 Determining Application Business Relevance
Ops/Admin/Mgmt (OAM) CS2 BW Queue administration, and management traffic. This class is
Transactional Data AF2 BW Queue + DSCP WRED critical to the ongoing maintenance and support of the
Bulk Data AF1 BW Queue + DSCP WRED network. Traffic in this class should be marked CS2 and
Best Effort DF Default Queue + RED provisioned with a (moderate, but dedicated) guaranteed
Scavenger CS1 Min BW Queue bandwidth queue. WRED should not be enabled on this
class, as OAM traffic should not be dropped. Example
traffic includes SSH, SNMP, Syslog, etc.
Cisco Strategic QoS Design At-A-Glance
Provisioning for voice is relatively straightforward: • Real-Time Interactive—This traffic class is intended for • Transactional Data—This traffic class is intended for
inelastic interactive video applications. Whenever interactive, “foreground” data applications Traffic in this
• Voice—This traffic class is intended for voice/audio possible, signaling and data sub-components of this class class should be marked AF Class 2 (AF21) and should be
traffic (VoIP signaling traffic is assigned to the “Call- should be separated out and assigned to their respective provisioned with a dedicated bandwidth queue with DSCP-
Signaling” class). Traffic assigned to this class should be traffic classes. Traffic in this class should be marked CS4 WRED enabled. This traffic class may be subject to policing
marked EF. This class is provisioned with an Expedited and may be provisioned with an EF PHB; as such, and re-marking. Example applications include data
Forwarding (EF) Per-Hop Behavior (PHB). The EF PHB- admission to this class should be controlled. An example components of multimedia collaboration applications,
defined in RFC 3246-is a strict-priority queuing service application is Cisco TelePresence. Enterprise Resource Planning (ERP) applications,
and, as such, admission to this class should be Customer Relationship Management (CRM) applications,
controlled. Example traffic includes G.711 and G.729a, • Multimedia Conferencing—This traffic class is database applications, etc.
as well as the audio components of multimedia intended for elastic interactive multimedia collaboration
conferencing applications, like Cisco Jabber, WebEx and applications. Whenever possible, signaling and data sub- • Bulk Data—This traffic class is intended for non-
Spark. components of this class should be separated out and interactive “background” data applications Traffic in this
assigned to their respective traffic classes. Traffic in this class should be marked AF Class 1 (AF11) and should be
Video—on the other hand—may have unique QoS class should be marked Assured Forwarding (AF) Class 4 provisioned with a dedicated bandwidth queue with DSCP-
requirements depending on the type, as illustrated in (AF41) and should be provisioned with a guaranteed WRED enabled. This traffic class may be subject to policing
Figure 4. bandwidth queue with DSCP-based Weighted-Random and re-marking. Example applications include: E-mail,
Early Detect (DSCP-WRED) enabled. Traffic in this class backup operations, FTP/SFTP transfers, video and content
Figure 4 Video Traffic Classes may be subject to policing and re-marking. Example distribution, etc.
applications include Cisco Jabber, WebEx and Spark.
With all business-relevant applications assigned to their
• Multimedia Streaming—This traffic class is intended for respective traffic classes, then only two types of traffic
elastic streaming video applications, such as Video-on- classes are left to be provisioned:
Demand (VoD). Traffic in this class should be marked AF
Class 3 (AF31) and should be provisioned with a • Best Effort (the Default Class)—This traffic class is the
guaranteed bandwidth queue with DSCP-based WRED default class. The vast majority of applications will continue
Two key questions need to be answered to determine enabled. Example applications include Cisco Digital to default to this Best-Effort service class; as such, this
the optimal traffic classification for a video application : Media System Video-on-Demand (VoD) streams, E- default class should be adequately provisioned. Traffic in
• is the video unidirectional or bidirectional? Learning videos, etc. this class is marked Default Forwarding (DF or DSCP 0)
• is the video elastic or inelastic? and should be provisioned with a dedicated queue. WRED
Figure 5 Data Traffic Classes is recommended to be enabled on this class.:
“Elastic” flows are able to adapt to network congestion
and/or drops (by reducing frame rates, bit rates, • Scavenger—This traffic class is intended for all
compression rates, etc.); “inelastic” flows either do not applications that have been previously identified as
have such capabilities or—in order to meet specific business-irrelevant. These may include video applications
business configured not to utilize these. that are consumer and/or entertainment-oriented. The
When it comes to data applications, there is really only approach of a “less-than Best-Effort” service class for non-
With these two questions answered, video applications business applications (as opposed to shutting these down
may be assigned to their respective traffic classes, one key question to answer (as illustrated in Figure 5):
• Is the data application “foreground” or “background”? entirely) has proven to be a popular, political compromise.
including: These applications are permitted on business networks
• Broadcast Video—This traffic class is intended for “Foreground” refers to applications from which users when bandwidth is available; however, as soon as the
broadcast TV, live events, video surveillance flows, and expect a response—via the network—in order to continue network experiences congestion, this class is the most
similar “inelastic” streaming video flows Traffic in this with their tasks; excessive latency to such applications aggressively dropped. Traffic in this class should be
class should be marked Class Selector 5 (CS5) and may will directly impact user productivity. marked CS1 and should be provisioned with a minimal
be provisioned with an EF PHB; as such, admission to bandwidth queue that is the first to starve should network
this class should be controlled. Example traffic includes congestion occur. Example traffic includes Netflix,
Conversely, “background” applications—while business
live Cisco Enterprise TV (ETV) streams, and Cisco IP YouTube, Xbox Live/360 Movies, iTunes, BitTorrent, etc
relevant—do not directly impact user productivity and
Video Surveillance. typically consist of machine-to-machine flows.
For more details, see:
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html
And the Cisco Press Book: End-to-End QoS Network Design (Second Edition)-Chapter 10
Copyright © 2015 Cisco Systems, Inc. All rights reserved. Cisco, the Cisco logo, Cisco Systems, and the Cisco Systems logo are registered trademarks or trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
Tactical QoS Design At-A-Glance
Translating QoS Strategy into Tactical Designs QoS Design Recommendations: 2) Classification and Marking Best Practices
To meet the demands of today's media-rich networks, 1) Hardware vs. Software Best Practices When classifying and marking traffic, a recommended
administrators are recommended to articulate a QoS design best practice is to classify and mark applications
Some Cisco routers (such as Cisco ISRs) perform
strategy that reflects their business intent. This strategy as close to their sources as technically and
details which applications are/are-not business
QoS in software, which places incremental loads on administratively feasible. This principle promotes end-to-
relevant, as well as how these applications are to be the CPU. The actual incremental load will depend end Differentiated Services and Per-Hop Behaviors.
marked and treated over the IP network. Furthermore, on the numerous factors, including: the complexity
this QoS strategy is end-to-end and is not constrained and functionality of the policy, the volume and In general, it is not recommended to trust markings that
by any technical or administrative limitation. composition of the traffic, the speed of the interface, can be set by users on their PCs or other similar devices
the speed of the CPU, the memory of the router, because users can easily abuse provisioned QoS
While defining such an unconstrained QoS strategy is etc. policies if permitted to mark their own traffic. For
an important part of the deployment process, when it example, if an EF PHB has been provisioned over the
comes to practical deployment, various technical network, a PC user can easily configure all their traffic to
On the other hand, other devices (such as Cisco
constraints have to be taken into account, including: be marked to EF, thus hijacking network priority queues
Catalyst switches) perform QoS in dedicated to service their non-realtime traffic. Such abuse could
• hardware constraints hardware Application Specific Integrated Circuits easily ruin the service quality of realtime applications
• software constraints (ASICs). As such, these switches can perform even throughout the enterprise. On the other hand, if
• media capability constraints
the most complex QoS policy on maximum traffic enterprise controls are in place to centrally administer
• bandwidth constraints
• service provider constraints loads at line rates on GE/10GE/40GE/100GE PC QoS markings, then it may be an acceptable design
interfaces—all without any marginal CPU tax. option to trust them.
Thus the goal of tactical QoS design is to adapt the
QoS strategy to the maximum of a platform's Thus, whenever a choice exists, Cisco Following this rule, it is further recommended to use
DSCP markings whenever possible, because these
capabilities, subject to all relevant constraints. recommends implementing QoS policies in devices
Layer 3 IP-header markings are end-to-end, more
that perform QoS operations in hardware—rather granular, and more extensible than Layer 2 markings.
Additional recommendations to keep in mind during than software—as this will result in more efficient For example, IEEE 802.1p, IEEE 802.11e and MPLS
the tactical design phase are to: utilization of network infrastructure resources. EXP only support three bits (values 0-7) for marking.
• Only enable QoS features if these directly Therefore, only up to eight classes of traffic can be
contribute to expressing the QoS strategy on the For example, suppose an administrator has the supported with these marking schemes and inter-class
given platform option of deploying classification and marking relative priority (such as RFC 2597 Assured Forwarding
• Leverage QoS design best-practices to generate policies in a branch network in either a Catalyst Drop Preference markdown) is not supported. On the
platform specific configurations that reflect the switch (in hardware) or at the LAN-edge interface of other hand, Layer 3 DSCP markings allow for up to 64
QoS strategy with maximum fidelity distinct classes of traffic.
an ISR router (in software). Since a choice exists as
to where the policy should be deployed, it would be As the line between enterprises and service providers
more efficient to classify and mark within the continues to blur and the need for interoperability and
Catalyst switch. complementary QoS markings is critical, you should
follow standards-based DSCP PHB markings to ensure
However, there may be cases where such a choice interoperability and future expansion.
doesn’t exist. Continuing the example: there may
be a business need to perform deep-packet
inspection on branch-originated traffic (which isn’t
currently supported on Catalyst switches), and as
such the administrator would then have to apply the
required classification and marking policies on the
ISR router.
Cisco Tactical QoS Design At-A-Glance
3) Policing and Remarking Best Practices The Real-Time Queue corresponds to the RFC 3246 EF The Best Effort Queue is the default treatment for all
There is little reason to forward unwanted traffic only to PHB. The amount of bandwidth assigned to the real-time traffic that has not been explicitly assigned to another
police and drop it at a downstream node, Therefore, it is queue is usually variable. However, if the majority of queue. Only if an application has been selected for
recommended to police traffic flows as close to their bandwidth is provisioned with strict-priority queuing preferential/deferential treatment is it removed from the
sources as possible. (which is effectively a first-in, first-out [FIFO] queue), the default class. Because most enterprises have several
overall effect is a dampening of QoS functionality. thousand applications running over their networks,
Whenever supported, markdown should be done Remember the goal of convergence is to enable voice, adequate bandwidth must be provisioned for this class as
according to standards-based rules, such as RFC 2597, video, and data applications to transparently coexist on a a whole to handle the sheer number and volume of
The Assured Forwarding PHB . For example, excess single network. When real-time applications dominate a applications that default to it. Therefore, Cisco
traffic marked to AFx1 should be marked down to AFx2 link, non-real-time applications fluctuate significantly in recommends provisioning at least 25% of link
(or AFx3 whenever dual-rate policing—such as defined their response times, destroying the transparency of the bandwidth for the default Best Effort class.
in RFC 2698—is supported). Following such converged network.
markdowns, congestion management policies, such as In addition, WRED is recommended to be enabled on the
DSCP-based Weighted Random Early Detection Cisco has done extensive testing and has found that a default class to improve throughput and reduce TCP
(WRED), should be configured to drop AFx3 more significant decrease in non-real-time application synchronization. Because all traffic destined to this class
aggressively than AFx2, which in turn should be response times occurs when real-time traffic exceeds is to be marked to the same DSCP value (of 0), there is
dropped more aggressively than AFx1. one-third of link bandwidth capacity. In fact, both testing no “weight” component to the WRED dropping decision,
and customer deployments have shown that a general and therefore the congestion algorithm is effectively
4) Queuing and Dropping Best Practices best queuing practice is to limit the amount of strict- random early detect (RED).
priority queuing to 33% of link bandwidth capacity.
Business-critical applications require service guarantees This strict priority queuing recommendation is a Whenever the Scavenger Queue is enabled, it should be
regardless of network conditions. The only way to conservative and safe design ratio for merging real-time assigned a minimal amount of bandwidth, such as 1%
provide service guarantees is to enable queuing at any applications with data applications. (or whatever the minimal bandwidth allocation that the
and every node that has the potential for congestion.
platform supports).
Finally, WRED—or any similar congestion avoidance
In addition, because each application class has unique mechanism—should never be enabled on the strict- WRED is not required on the Scavenger class queue
service level requirements, each should optimally be priority queue. Traffic assigned to this queue is often because traffic assigned to this queue has no implied
assigned a dedicated queue. In such a manner, specific highly drop sensitive; therefore, early dropping should “good-faith” service guarantee or expectation. Therefore,
bandwidth allocations and dropping policies can be never be induced on these flows. there is little to gain by adding this feature and it may
assigned to each discrete application class to meet its
even be wasteful of router CPU resources.
distinctive QoS requirements. Otherwise, if multiple At least one queue should be provisioned as an
application classes are assigned into a common Assured Forwarding Queue. Per RFC 2597, up to four Figure 1 Queuing Best Practices
queuing bucket, the administrator no longer can control queues can be provisioned with this service:
if bandwidth resources are being shared among these • AF Class 1-AF11, AF12, AF13
application classes according to their individual • AF Class 2-AF21, AF22, AF23
requirements. • AF Class 3-AF31, AF32, AF33
• AF Class 4-AF41, AF42, AF43
At a minimum, however, the following standards-based
queuing behaviors should be supported: These queues should have bandwidth guarantees that
• Real-time queue(s)-to support an RFC 3246 correspond with the application class requirements of
Expedite Forwarding service the traffic assigned to it.
• Guaranteed-bandwidth queue(s)-to support RFC
2597 Assured Forwarding services In addition, DSCP-based WRED should be enabled on
• Default queue-to support an RFC 2474 Default these queues, such that traffic marked AFx3 is
Forwarding service (statistically) dropped sooner and more often than AFx2,
• Bandwidth-constrained queue-to support an RFC which in turn is (statistically) dropped more aggressively
3662 “Scavenger” service than AFx1.
For more details, see:
Cisco offers design recommendations for each of these
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html
types of queues. These queuing best practices are And the Cisco Press Book: End-to-End QoS Network Design (Second Edition)-Chapter 11
illustrated in Figure 1.
Cisco NBAR2 QoS Attributes At-A-Glance
Role in Network For example, the voice-and-video category includes Traffic-Class Attribute
not only cisco-phone and telepresence-media voice The traffic-class attribute aligns NBAR2 applications according
Cisco Network Based Application Recognition (NBAR)
and video flows, but also skype and facetime. But to RFC 4594-based traffic-classes. For example, per RFC 4594
technology (now in its second generation) boasts an
these consumer-oriented voice-and-video applications "Low Latency Data" applications (commonly referred to as
application library of over 1300 applications, many with
may be considered to be business-irrelevant, and so "Bulk Data" applications) includes email, file-transfer and other
media sub-component signatures also available, for an
would need to be excluded from a business QoS policy. "background" (i.e. non-user-interactive) applications. As such,
approximate total of 1400 distinct applications/sub-
applications. rather than having to configure a class map along the lines of:
Additionally, NBAR2 categories predate the industry-
standard reference for configuring DiffServ QoS, namely class-map match-any BULK-DATA
While this richness provides network administrators
RFC 4594. As such, these categories do not align with match protocol attribute category email
great flexibility and power in their policy-definitions, it is
the traffic-class names used in this RFC. match protocol attribute category file-sharing
cumbersome to specify each application/sub-application
by name within a QoS policy. match protocol attribute sub-category backup-
Therefore, to simplify and expedite QoS configuration, systems... etc.
NBAR2 has been enhanced in IOS XE 3.16 to support
To assist in policy-definition and in browsing the
application library, applications are grouped into two new attributes:
categories and sub-categories. For example, NBAR • Business-Relevance An administrator can configure all relevant applications
application categories include: • Traffic-Class matching a specific RFC 4594 traffic-class with a single
• browsing command (examples of which are shown on the reverse).
• business-and-productivity-tools Business-Relevance Attribute
• email The business-relevance attribute allows an administrator The ten RFC 4594 traffic classes for business-relevant
• file-sharing to classify a given application to one of three levels of applications are shown in Table 2.
• gaming business relevancy, as shown in Table 1.
• industrial-protocols Table 2 Traffic-Class NBAR2 Attribute
• instant-messaging Table 1 Business-Relevance NBAR2 Attribute
• internet-privacy
• layer3-over-ip
• location-based-services
• net-admin
• newsgroup
• social-networking
• streaming All applications within the NBAR2 library has been pre-
• voice-and-video populated with the most common business-relevance
attribute. For example, youtube by default is set as
Thus, for example if an administrator wanted to classify business-irrelevant, as most customers typically
all email applications, they could use the match classify this application as such. However, this may not
protocol attribute category email command within a be the case across the board; for example, some Thus, with these new attributes, all 1400 NBAR2 applications
class-map. businesses may be using YouTube for training can be configured into a 12-class RFC 4594-based QoS model
purposes. In such cases, an administrator can change with a straighforward and user-intuitive syntax, as is shown on
However, there may be cases where all applications this business-relevancy setting to align with their the reverse.
within a given category may not be considered business- objectives.
relevant, as shown in Figure 1.
A business-irrelevant application is intended for a
Figure 1 Determining Application Business Relevance RFC 3662 “Scavenger” treatment. An application with a
business-relevancy setting of default is intended for a
RFC 2474 Default Forwarding treatment. In turn,
business-relevant applications are intended to be
serviced within their respective RFC 4594 traffic-class.
Cisco NBAR QoS Attributes At-A-Glance
Step 1 : Configure NBAR2 (Business-Relevance and Traffic-Class) Class-Maps Step 2: Configure Marking Policy-Map
class-map match-all VOICE policy-map MARKING
match protocol attribute traffic-class voip-telephony class VOICE
match protocol attribute business-relevance business-relevant set dscp ef
class-map match-all BROADCAST-VIDEO class BROADCAST-VIDEO
match protocol attribute traffic-class broadcast-video set dscp cs5
match protocol attribute business-relevance business-relevant class INTERACTIVE-VIDEO
class-map match-all INTERACTIVE-VIDEO set dscp cs4
match protocol attribute traffic-class real-time-interactive class MULTIMEDIA-CONFERENCING
match protocol attribute business-relevance business-relevant set dscp af41
class-map match-all MULTIMEDIA-CONFERENCING
class MULTIMEDIA-STREAMING
match protocol attribute traffic-class multimedia-conferencing
set dscp af31
match protocol attribute business-relevance business-relevant
class SIGNALING
class-map match-all MULTIMEDIA-STREAMING
set dscp cs3
match protocol attribute traffic-class multimedia-streaming
class NETWORK-CONTROL
class-map match-all SIGNALING set dscp cs6
match protocol attribute traffic-class signaling class NETWORK-MANAGEMENT
match protocol attribute business-relevance business-relevant set dscp cs2
class-map match-all NETWORK-CONTROL class TRANSACTIONAL-DATA
match protocol attribute traffic-class network-control set dscp af21
match protocol attribute business-relevance business-relevant class BULK-DATA
class-map match-all NETWORK-MANAGEMENT set dscp af11
match protocol attribute traffic-class ops-admin-mgmt class SCAVENGER
match protocol attribute business-relevance business-relevant set dscp cs1
class-map match-all TRANSACTIONAL-DATA class class-default
match protocol attribute traffic-class transactional-data set dscp default
class-map match-all BULK-DATA
match protocol attribute traffic-class bulk-data Step 3: Attach the Policy-Map to the Interface(s)
match protocol attribute business-relevance business-relevant service-policy input MARKING
class-map match-all SCAVENGER
match protocol attribute business-relevance business-irrelevant
Note: Highlighted commands are interface specific; otherwise these are global.
Cisco Domain Name System-Authoritative Source (DNS-AS) At-A-Glance
The Role of DNS-AS Identifying Internal Applications Figure 1 DNS-AS Identification of Internal Applications-
Steps 1 to 3
An increasing number of applications are being As internal DNS servers are centrally administered by the
encrypted, which limits the effectiveness of deep-packet enterprise IT department, these may be modified to include
inspection technologies. Additionally, many applications custom DNS TXT records that reflect application metadata, such
are multiplexing their media streams, making these as:
increasingly difficult to distinguish and treat differently. • application name
• application ID
Providing application metadata can address both of • RFC 4594 traffic classification
these challenges and enhance the utility of network QoS,
• Business relevance, etc.
security, performance routing and other policies.
With this application metadata in place in the local DNS server

The challenge thus becomes how to distribute such database, then - for example - a network access switch with no
application metadata. For instance, if applications deep-packet inspection capabilities can leverage DNS-AS to
running on devices were to communicate such metadata correctly classify and apply QoS (and other types of policies) to
to the network, this would require a phenomenal amount any internal application.
of cross-platform software development and
maintenance.
The DNS-AS operational steps to identify internal applications
are:
However, DNS is not only a trusted source of information
(as it is centrally administered, either by an enterprise or 1) A client requests a DNS Lookup, as shown in Figure 1.
2) The access switch examines the DNS request Figure 2 DNS-AS Identification of Internal Applications-
by a service provider), but is also flexible and extensible.
Steps 4 to 6
As such, it may be used as an "authoritative source" of 3) The internal DNS Server returns a DNS response (A-Record).
application metadata.
4) The access switch makes its own DNS query and requests
application metadata information, as shown in Figure 2.
Thus, DNS-AS can provide the following value to
5) The internal DNS Server returns a TXT Record with
enterprise networks:
application metadata information.
• accurately classify encrypted applications
6) The access switch maintains a Binding Table of
• identify thousands of applications
(e.g. by leveraging OpenAppID)
• provide layer 7 visibility to network devices that have
no deep-packet inspection capabilities At this point, the access switch can apply QoS policies or security
• reduce configuration complexity on network devices or routing or other types policies to the flow.
for classification
• require no software updates to endpoint devices,
applications or operating systems
Consider two main DNS-AS use-cases:

• identifying internal applications
• identifying external applications
Cisco DNS-AS QoS
Identifying External Applications Figure 3 DNS-AS Identification of External Applications- Figure 4 DNS-AS Identification of External Applications-
Steps 1 to 5 Steps 6 and 7
A few additional steps are required when identifying external
applications that have no application metadata in their DNS
records. In this model, the internet edge router plays a key role as a
DNS-AS Proxy.
The DNS-AS operational steps to identify external applications are:

1) A client requests a DNS Lookup, as shown in Figure 3.
2) The access switch examines the DNS request.
3) The external DNS Server returns a DNS response (A-Record).
4) The access switch makes its own DNS query and requests
application metadata information (via a TXT record).
5) The external DNS Server has no TXT Record with application
metadata.
6) The internet edge router notices the request for a TXT Record
without response and:
A) On the first flow:
The internet edge router uses NBAR2 to perform deep-
packet inspection to identify the flow and makes an entry
in its local Binding Table.
B) On subsequent flows:
The internet edge router responds (as a DNS-Proxy)
to the request for application metadata (by inserting a
TXT Record into the DNS response from the external
DNS server). Figure 4 DNS-AS Identification of External Applications-
Step 6a
7) The access switch maintains a Binding Table of

Cisco APIC-EM QoS At-A-Glance
The Roles of APIC-EM QoS Capturing Business Intent and Articulating QoS Strategy Three key design principles are followed when
Without a centralized controller, application policies (such as translating the strategic (business-intent) QoS policy
QoS is one of the most widely-deployed technologies in
QoS) have to be independently configured on individual into tactical (device-specific) configurations:
the enterprise and needs to be deployed in a holistic,
network devices and it would be up to the administrator to • The first is that the primary goal of the tactical QoS
integrated, end-to-end manner to ensure maximum
ensure compatibility and cohesiveness across the network. policy is to express the strategic QoS policy with
effectiveness. As such, it is a prime candidate technology
to showcase the value-add of Software Defined However, a controller-based approach allows for maximum fidelity, subject to any platform-specific
Networking (SDN), which allows for: administrators to centrally define QoS policies, by expressing technical constraints
the business-relevance of applications. With this information, • The second is that QoS features will not be enabled
• Integrating applications with the network infrastructure
the controller can then articulate a end-to-end strategy that is simply because these exist, but rather only features
• Capturing business intent of QoS policies so as to
to be deployed across all network devices in a consistent that directly contribute to the strategic policy will
articulate an end-to-end QoS strategy
manner. be enabled
• Abstracting platform-specific implementation details,
while maintaining cross-platform consistency • The third is that all features that are enabled are
• Dynamic QoS policies based on application Abstracting Platform-Specific Implementation Details done in accordance with CVD best-practices.
requirements and events
With a central QoS strategy defined, the controller can then
apply Cisco Validated Design (CVD) best-practices to
Integrating Applications with the Network
translate the policy to device-specific configurations, which it
A key objective of SDN is to allow for communication
then pushes down to all network devices via (Southbound)
between applications and the network. This is done by
APIs, as shown in Figure 2.
supporting (Northbound) Application Programming
Interfaces (APIs) between software applications and the In this manner, device-specific details are completely
network controller, such as Cisco's Application Policy abstracted from the network operator, who can thus focus on
Infrastructure Controller-Enterprise Module (APIC-EM). business objectives and results.
In this manner, the network can adapt policies to
application's requirements, as well as provide feedback Figure 2 APIC-EM Adaption of Business Intent QoS Policies to Platform-Specific Capabilities and Constraints
so that applications can also make intelligent decisions
based on dynamic network conditions.
Figure 1 Cisco APIC-EM Architecture

Cisco APIC-EM QoS At-A-Glance
Dynamic Application-Based QoS Policies Figure 3 APIC-EM Dynamic QoS Policies - Steps 1 (Operator Expresses Business Intent) and 2 (Tactical QoS Policies Deployed)
A unique advantage that a controller-based architecture
brings to the network is the ability to deploy dynamic QoS
policies in a scalable and virtually instantaneous manner.
For example, APIC-EM can integrate via APIs to
collaborative multimedia applications, including Cisco
Jabber and Microsoft Lync (now Skype for Business). By
means of this integration, QoS policies can be dynamically
applied throughout the network to prioritize voice and video
flows.
Such dynamic QoS policies allow for these applications to

have their flows protected with QoS, regardless of whether:
• the endpoint devices are wired or wireless
• the endpoint devices are IT-managed or BYOD
• the media flows are encrypted or not
There are 5 main steps to these dynamic QoS policies:

Step 1: A network operator enters business-intent into
APIC-EM, which then articulates a strategic
end-to-end QoS policy, as shown in Figure 3.
Step 2: APIC-EM translates the strategic policy into

device-specific tactical policies, including Figure 4 APIC-EM Dynamic QoS Policies - Steps 3 (APIC-EM is Informed of a Proceeding Call) and 4 (Dynamic ACEs are Pushed)
classification, marking and queuing policies.
Note: classification policies for voice and

video - which are are access-list (ACL) based -
do not (initially) include any access-list entries
(ACEs) to discretely identify the IP flows to
which these should apply.
Note: Queuing policies (not shown in Figure 3,

but expressed in Figure 1) are all DSCP-based.
Step 3: APIC-EM is informed (by either Cisco Unified
Call Manager or the Microsoft Lync server) of a
proceeding call. This includes the 5-tuple
information (IP Source / Destination Addresses
and UDP Source / Destination Ports) of the
voice and video flows, as shown in Figure 4.
Step 4: APIC-EM dynamically pushes out ACEs to the

edge switches hosting the endpoints.
Step 5: APIC-EM is informed of a terminated call.
Step 6: APIC-EM removes the ACEs corresponding to

the terminated call. (Steps 5 & 6 are not shown).
Intelligent WAN QoS Design At-A-Glance
Deploying Cisco IWAN QoS Figure 2 8-class Egress Queuing Model
Quality of Service (QoS) has already proven itself as the Policers typically drop traffic, but traffic shapers delay
enabling technology for the convergence of voice, excess traffic, smoothing bursts and preventing
video, and data networks. As business needs evolve, so unnecessary drops.
do demands on QoS technologies. The need to protect
Shapers are very common with Ethernet WAN, as well as
voice, video, and critical data with QoS mechanisms is
Non-Broadcast Multiple-Access (NBMA) network
extremely important on the WAN because access
topologies such as Frame-Relay and ATM.
speeds are much lower than the LAN networks that feed
them.
Figure 4 Traffic Shaping
When configuring WAN-edge QoS, you are defining
how traffic egresses your network. It is critical that the
classification, marking, and bandwidth allocations align
to the service provider, offering to ensure consistent The 12-class view should always be preserved across the
QoS treatment end to end. Enterprise even though we treat it differently at the egress
Figure 1 shows a typical 8-class queuing model for a of the router and send it to different channels in the service
Cisco Intelligent WAN (IWAN) deployment. Voice traffic provider network.
is put into a strict priority queue and the rest of of the The Per-Tunnel QoS for DMVPN feature allows the
traffic is put into class-based weighted fair queues. The The twelve classes remain intact on the inner header and configuration of a QoS policy on a DMVPN hub on a per-
bandwidth remaining percentages must equal 100%. the outer tunnel header is remarked as the traffic leaves the tunnel basis. The QoS policy on a tunnel instance allows
tunnel interface. The remarked outer header is discarded you to shape the tunnel traffic to individual spokes
The values used below are a good starting point, but after arriving at the tunnel interface on the receiving router, (parent policy) and to differentiate between traffic classes
the final numbers should be based on an analysis of thus leaving the inner header marking unchanged. within the tunnel for appropriate treatment (child policy).
your traffic patterns over a period of time.
The following table shows how to combine the twelve Traffic is regulated from the central site (hub) routers to
Figure 1 8-class QoS Model classes into a typical 4-class SP model. the remote-site routers on a per-tunnel (spoke) basis.
The hub site is unable to send more traffic than a single
Figure 3 4-class SP Model remote-site can handle, and this ensures that high
bandwidth hub sites do not overrun lower bandwidth
remote-sites.
Figure 5 DMVPN Per-Tunnel QoS
When the access rate of an interface is different from the

The following table shows how to combine the twelve service rate, traffic shapers are used to limit the transmit
RFC 4594 traffic classes into an 8-class model for rate. A shaper will guarantee that traffic will not exceed the
egress queuing. Combining the 12-class into a smaller contracted rate. A nested queuing policy will force
number of queues is recommended for IWAN when queuing to engage at the contracted sub-line rate to
bandwidth service rates are less than 100 Mbps. prioritize packets prior to shaping.
Intelligent WAN QoS Design At-A-Glance
Implementing 8-class Egress Queuing and 4-class SP Mapping Implementing DMVPN Per Tunnel QoS
1. On all routers, create the 8-class QoS queuing model using class-maps with
match dscp to combine the twelve classes.
2. On the hub border routers, create the 4-class SP mapping using set dscp tunnel.
3. On the remote site routers, create the 4-class SP mapping using set dscp.
Class-map for 8-class QoS Model
class-map match-any VOICE

match dscp ef
class-map match-any INTERACTIVE-VIDEO
match dscp cs4 af41 af42 af43
class-map match-any STREAMING-VIDEO
class-map match-any NET-CTRL
match dscp cs6
class-map match-any CALL-SIGNALING
match dscp cs3
class-map match-any CRITICAL-DATA
match dscp cs2 af11 af12 af13 af21 af22 af23
class-map match-any SCAVENGER
match dscp cs1
1. On the hub border router, create the child and parent shaper policies for each
Hub Border Router: Remote Site Router:
Policy-map for 4-class service provider offering
remote site bandwidth type using the policy-map for the service provider.
Policy-map for 4-class service provider offering
2. List the available policies as nhrp map groups on the hub tunnel interfaces.
policy-map WAN policy-map WAN 3. Create a "shape only" grandparent policy and apply it on the hub outbound
class INTERACTIVE-VIDEO class INTERACTIVE-VIDEO physical interface.
bandwidth remaining percent 30 bandwidth remaining percent 30
random-detect dscp-based
4. On the remote site router, signal from the spoke to the hub using the nhrp group
set dscp tunnel af31 set dscp af31 command specifying the correct bandwidth policy.
class STREAMING-VIDEO class STREAMING-VIDEO This creates a per-tunnel shaper for each remote site on the hub border router.
random-detect dscp-based random-detect dscp-based You can find more details about configuring QoS for IWAN in the IWAN
set dscp tunnel af31 set dscp af31
class NET-CTRL
Deployment Guide. The full routers configurations used in the CVD Lab
class NET-CTRL
bandwidth remaining percent 5 bandwidth remaining percent 5 can be found in the IWAN Configurations Files Guide.
set dscp tunnel cs6 set dscp cs6
class CALL-SIGNALING
Cisco Validated Design (CVD)
bandwidth remaining percent 4 bandwidth remaining percent 4 Branch, WAN and Internet Edge: http://www.cisco.com/go/cvd/wan
class CRITICAL-DATA class CRITICAL-DATA
random-detect dscp-based random-detect dscp-based
class SCAVENGER class SCAVENGER
set dscp tunnel default set dscp default
class VOICE class VOICE
priority level 1 priority level 1
police cir percent 10 police cir percent 10
set dscp tunnel ef set dscp ef
class class-default class class-default
random-detect random-detect
set dscp tunnel default set dscp tunnel default
Campus QoS Design At-A-Glance
The Case for QoS in Campus Networks Trust States Figure 2 Port-Based QoS
The primary role of QoS in campus networks is not to A switch port that is set to trust will accept and preserve
VLAN Interfaces
control latency or jitter (as it is in the WAN/VPN), but to either Layer 2 or Layer 3 packet markings. There are four VLAN 10 VLAN 20
manage packet loss. In GE/10GE campus networks, it static trust states with which a switch port may be
takes only a few milliseconds of congestion to cause configured:
instantaneous buffer overruns resulting in packet drops. • Untrusted—The default state with QoS enabled Physical Ports
Rich media applications—particularly HD video • Trust CoS—Accepts Layer 2 802.1P CoS markings
227050
Policy map is applied to
applications—are extremely sensitive to packet drops, • Trust IP Precedence—Accepts Layer 3 IP the physical switch port
to the point where even 1 packet dropped in 10,000 is Precedence markings; largely deprecated
Per-VLAN QoS
discernible by the end-user. • Trust DSCP—Accepts Layer 3 DSCP markings; this is
Classification, marking, policing, queuing, and congestion the most granular and flexible static state and thus the When a QoS policy is applied on a per-VLAN basis, it is
avoidance are therefore critical QoS functions that are most utilized static trust state in campus networks attached to a logical VLAN interface and is active on all
optimally performed within the campus network, traffic received on all ports that are currently assigned to
the VLAN. Figure 3 illustrates VLAN-based QoS.
Conditional Trust
Four QoS design principles that apply to campus QoS Figure 3 VLAN-Based QoS
Trust may also be extended dynamically, provided a
deployments include: successful condition has been met. In Cisco campus Policy map is applied to
networks this condition is a successful Cisco Discovery the logical VLAN interface
• Always perform QoS in hardware rather than software Protocol (CDP) negotiation between the access switch
when a choice exists. and the endpoints. Endpoints that can be extended VLAN Interfaces
• Classify and mark applications as close to their conditional trust by Cisco Catalyst switches include
VLAN 10 VLAN 20
sources as technically and administratively feasible. Cisco IP phones, Cisco TelePresence Systems, Cisco
227051
• Police unwanted traffic flows as close to their sources IP Surveillance Cameras, and Cisco Digital Media
Physical Ports
as possible. Players. Conditional trust operation is shown in Figure 1.
Per-Port/Per-VLAN QoS
• Enable queuing policies at every node where the Figure 1 Conditional Trust Operation
potential for congestion exists, When a QoS policy is applied on a Per-Port/Per-VLAN
Initial Trust basis, it is attached to specific VLAN on a trunked port and
Campus QoS Design Considerations Boundary
1
Cisco media endpoints successfully is active on all traffic received from that specific VLAN
meet CDP-based condition
There are several considerations that impact QoS from that specific trunked port (only). Figure 4 illustrates
designs within the campus: Per-Port/Per-VLAN-based QoS.
• Global Default QoS Setting Figure 4 Per-Port-Per-VLAN-Based QoS
• Trust States and Conditional Trust IP
• Per-Port QoS., Per-VLAN QoS, Per-Port/Per-VLAN VLAN Interfaces
DVLAN 10
QoS
VVLAN 110
• Ingress QoS Models
2
• Egress QoS Models
290909
Cisco access switch dynamically

• EtherChannel QoS extends trust boundary
Trunked Physical Ports
• QoS Roles in a campus Per-Port QoS
DVLAN policy map is applied VVLAN policy map is applied
• AutoQoS When a QoS policy is applied on a per-port basis, it is
227052
to the Data VLAN (only) to the Voice VLAN (only)
on a given trunked switch port on a given trunked switch port
Global Default QoS Setting attached to a specific physical switch port and is active on
On some platforms QoS is globally disabled by default all traffic received on that specific port (only). QoS policies Ingress QoS Models
(such as the Cisco Catalyst 2960/3650/3750). A are applied on a per-port basis by default. Figure 2 There are many options for an administrator to choose
fundamental first step is to globally enable QoS on these illustrates port-based QoS. from for ingress QoS models, as shown in Figure 5.
platforms.
Campus QoS Design At-A-Glance
Figure 5 Ingress QoS Models • Voice, broadcast video, and realtime interactive may queuing policies) are always applied to the physical
be mapped to the realtime queue (per RFC 4594) port-member interfaces.
• Network/internetwork control, signaling, network
No Trust
Trust CoS
QoS Roles in a Campus
Trust DSCP
management, multimedia conferencing, multimedia Access edge switch ports have the most variation in QoS
streaming, and transactional data can be mapped to
Trust Device/Conditional Trust policy roles and these will vary depending on the type of
the guaranteed bandwidth queue. Congestion
Marking Policies endpoint to which these are connecting.
(Optional) Policing Policies
avoidance mechanisms, such as WRED, can be
(if required and supported)

For all switch-to-switch links the only QoS policies that are
Ingress Queuing Policies

VoIP Classifier Mark EF
VVLAN
VoIP Policer (<128 kbps)
Yes
No enabled on this class; furthermore, if configurable
Drop
required are DSCP-trust (on ingress) and queuing (on
drop thresholds are supported on the platform, these
Yes
Signaling Classifier Mark CS3 Signaling Policer (<32 kbps) No Drop
egress). QoS roles in a campus network are shown in
Yes may be enabled to provide intra-queue QoS to these
Multimedia Conferencing Mark AF41 MM-Conf Policer (<5 Mbps) No
Drop Figure 7.
Classifier
Signaling Classifier Mark CS3

DVLAN
Signaling Policer (<32 kbps)
Yes
No
application classes, in the respective order they are
Yes
Drop
listed (such that control plane protocols receive the Figure 7 Campus Port QoS Roles
Transactional Data Classifier Mark AF21 Trans-Data Policer (<10 Mbps) No Remark to CS1
Bulk Data Classifier Mark AF11 Bulk Data Policer(<10 Mbps)

Yes
No Remark to CS1
highest level of QoS within a given queue) Untrusted Endpoints
Scavenger Classifier Mark CS1 Scavenger Policer (<10 Mbps)
Yes
No
Drop
• Bulk data and scavenger traffic can be mapped to the
Best Effort (Class-Default) Mark DF Best Effort Policer (<10 Mbps)
Yes
No Remark to CS1 bandwidth-constrained queue and congestion
227056
avoidance mechanisms can be enabled on this class. Access Distribution Core
The three most utilized ingress QoS models for campus If configurable drop thresholds are supported on the
networks are: platform, enabling them provides intra-queue QoS to Trusted
Endpoints
• Trust DSCP Model drop scavenger traffic ahead of bulk data
• Conditional Trust Model • Best effort traffic can be mapped to the default
• Service Policy Models queue; congestion avoidance mechanisms can be
Combinations of these may be used at the same time enabled on this class
Egress QoS Models An egress queuing example based on these design IP
Cisco Catalyst switches perform queuing in hardware and considerations is shown in Figure 6. WAN/VPN
Block
Conditionally-
as such are limited to a fixed number of queues. The Figure 6 An Egress Queuing Example Model Trusted
Endpoints
nomenclature used to describe these queuing structures
is 1PxQyT, where: Application DSCP 1P3Q8T Untrusted Endpoint Port QoS: Switch-to-Switch/Router Port QoS:
• No Trust • Trust DSCP
• 1P represents a strict priority queue Network Control (CS7) EF • [Optional Ingress Marking and/or Policing] • 1P3QyT or 1P7QyT Queuing
Priority Queue
• xQ represents x-number of non-priority queues Internetwork Control CS6
CS5
(<33%)
• 1P3QyT Queuing
Distribution Switch Downlinks:
CS4
• yT represents y-number of drop-thresholds per VoIP EF
Trusted Endpoint Port QoS:
• Trust-DSCP
+ Microflow Policing/UBRL
(if supported)
non-priority queue Broadcast Video CS5
CS7 Q3T7 • [Optional Ingress Marking and/or Policing]
• 1P3QyT Queuing
No fewer than four hardware queues would be required to CS6 Q3T6
Multimedia Conferencing AF4 Conditionally-Trusted Endpoint Port QoS:
support QoS policies in the campus; the following CS3 Q3T5
• Conditional-Trust with Trust-DSCP
227059
queues would be considered a minimum: Realtime Interactive CS4 CS2 Queue 3 Q3T4 • [Optional Ingress Marking and/or Policing]
• 1P3QyT Queuing
• Realtime queue (RFC 3246 EF PHB) Multimedia Streaming AF3 AF4 Q3T3
• Guaranteed bandwidth queue (RFC 2597 AF PHB) Signaling CS3

AF3 Q3T2 AutoQoS
• Default queue (RFC 2474 DF PHB) Transactional Data AF2
AF2 Q3T1
On some Catalyst switching platforms Cisco has already
• Bandwidth constrained queue (RFC 3662 PDB or Queue 2 updated and expanded the functionality of its AutoQoS
Network Management CS2
“scavenger”service) DF ( 25%) feature to automatically provision QoS best practice
Bulk Data AF1
Additionally, the following bandwidth allocations are designs for voice, IP-based video applications (such as IP
recommended for these queues: Best Effort
Scavenger DF
CS1 AF1 Q1T2 Video Surveillance, Cisco TelePresence, conferencing
227058
• Realtime queue should not exceed 33% BW Best Effort DF CS1 Queue 1 (5%) Q1T1 applications, and streaming video applications), as well as
• Default queue should be at least 25% BW for multiple types of data applications.
EtherChannel QoS
• Bulk/scavenger queue should not exceed 5% BW On these switch platforms, an administrator can
Given these minimum queuing requirements and On some platforms ingress QoS policies (such as DSCP automatically provision these best practice designs via a
bandwidth recommendations, the following application trust) are applied on the logical Port-Channel interface; single interface-level command that corresponds to the
classes can be mapped to the respective queues: however, on all platforms egress QoS policies (such as endpoint to which the switch port is connecting.
For more details, see Campus QoS Design 4.0:

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html
And the Cisco Press book: End-to-End QoS Network Design (Second Edition)-Chapter 13
Cisco Catalyst 2960-X QoS Design At-A-Glance
Role in Campus Network Trust DSCP Model Step 3: Configure Egress Queuing
The Cisco Catalyst 2960-X series switches are well This model is configured with the mls qos trust dscp The egress queuing model for the Cisco Catalyst
suited to the role of access switches in campus interface-configuration command. 2960-X is shown in Figure 2..
networks. As such, these switches may connect directly The Trust DSCP model configures the interface to Figure 2 Catalyst 2960-X Egress Queuing Model
to a variety of endpoints, as well as to distribution-layer statically accept and preserve the Layer 3 DSCP markings
switches, as shown in Figure 1. of all incoming packets. This model is suitable for
Figure 1 Cisco Catalyst 2960-X Switches in a Campus interfaces connecting to endpoints that can mark DSCP Application DSCP 1P3Q3T
Network values and are administratively controlled (such as WLAN Network Control (CS7) AF1 Queue 4 Q4T2
(5%)
controllers) as well as for any uplinks to distribution layer Internetwork Control CS6
CS1 Q4T1
switches. Switch ports that can be set to trust DSCP are VoIP EF Default Queue
DF Queue 3 (35%)
shown as yellow circles in Figure 1. Broadcast Video CS5
CS7 Q2T3
Conditional Trust Model Multimedia Conferencing AF4
CS6
This model is configured with the mls qos trust device Realtime Interactive CS4
CS3 Q2T2
IP interface-configuration command. Multimedia Streaming AF3 Queue 2
AF4 (30%) Q2T1
The Conditional Trust model configures the interface to Signaling CS3
AF3
dynamically accept markings from endpoints that have
290910
Transactional Data AF2

AF2
met a specific condition (currently based on a successful Network Management CS2
CS2
Cisco Discovery Protocol identification). This model is Bulk Data AF1
QoS Design Steps suitable for switch ports connecting to Cisco IP phones EF
Best Effort
Scavenger DF
CS1 Q1
CS5
There are four main steps to configure QoS on (with the cisco-phone option), Cisco TelePresence Priority Queue
227062
Best Effort DF CS4
Cisco Catalyst 2960-X series switches: Systems (with the cts option), Cisco IP Video Surveillance
1. Enable QoS cameras (with the ip-camera option), and Cisco Digital
Media Players (with the media-player option). This model EtherChannel QoS
2. Configure Ingress QoS Model(s):
is also suitable for PCs and untrusted devices, since the
– Trust DSCP Model ports connecting to such devices will remain in their QoS policies on the Cisco Catalyst 2960-X are
default untrusted state. Switch ports that can be set to configured on the physical port-member interfaces only
– Conditional Trust Model
conditional trust are shown as green circles in Figure 1. (and not on the logical Port-Channel interface).
– Service Policy Models
3. Configure Egress Queuing Service Policy Models
There may be cases where administrators require more
detailed or granular policies on their ingress edges and as
Step 1: Globally Enable QoS such they may construct MQC-based policies to
QoS is globally enabled on the Cisco Catalyst 2960-X implement classification, marking, and/or policing
with the mls qos command. policies. These policies are constructed with:
Step 2: Configure Ingress QoS Model(s) • class-maps which identify the flows using packet
markings or by access-lists or other criteria
The three most utilized ingress QoS models for campus
networks are: • policy-maps which specify policy actions to be taken
on a class-by-class basis
• Trust DSCP Model
• service-policy statements which apply a specific
• Conditional Trust Model policy-map to an interface(s) and specify direction
• Service Policy Models
Combinations of these ingress QoS models may be used
at the same time.
Campus Cisco Catalyst 3560-X/3750-X QoS Design At-A-Glance
Cisco Validated Design

The Cisco Validated Design for Cisco Catalyst 2960-X series switches in the role of an access switch in a campus network is presented below.
Step 1: Enable QoS: Step 3 : Configure Egress Queuing

mls qos mls qos queue-set output 1 buffers 15 30 35 20
mls qos queue-set output 1 threshold 1 100 100 100 100
Egress Queue and
Step 2: Configure Ingress QoS Model : mls qos queue-set output 1 threshold 2 80 90 100 400 Threshold Tuning
mls qos queue-set output 1 threshold 3 100 100 100 400
Trust DSCP Model : mls qos queue-set output 1 threshold 4 60 100 100 400
mls qos trust dscp mls qos srr-queue output cos-map queue 1 threshold 3 4 5
mls qos srr-queue output cos-map queue 2 threshold 1 2 Egress
Conditional Trust Model :
mls qos srr-queue output cos-map queue 2 threshold 2 3 CoS-to-Queue
mls qos trust device cisco-phone or Mapping
mls qos srr-queue output cos-map queue 2 threshold 3 6 7
mls qos trust device cts or mls qos srr-queue output cos-map queue 3 threshold 3 0
mls qos trust device ip-camera or mls qos srr-queue output cos-map queue 4 threshold 3 1
mls qos trust device media-player mls qos srr-queue output dscp-map queue 1 threshold 3 32 40 46
mls qos srr-queue output dscp-map queue 2 threshold 1 16 18 20 22
Service Policy Models :
mls qos srr-queue output dscp-map queue 2 threshold 1 26 28 30 34 36 38 Egress
[class-maps omitted for brevity]
mls qos srr-queue output dscp-map queue 2 threshold 2 24 DSCP-to-Queue
mls qos srr-queue output dscp-map queue 2 threshold 3 48 56 Mapping
policy-map MARKING-POLICY
class VOIP mls qos srr-queue output dscp-map queue 3 threshold 3 0
set dscp ef mls qos srr-queue output dscp-map queue 4 threshold 1 8
class MULTIMEDIA-CONFERENCING mls qos srr-queue output dscp-map queue 4 threshold 2 10 12 14
set dscp af41
queue-set 1
class SIGNALING Egress Queuing
srr-queue bandwidth share 1 30 35 5
set dscp cs3 Interface-Specific Commands
priority-queue out
290911
class TRANSACTIONAL-DATA
set dscp af21
class BULK-DATA
set dscp af11
class SCAVENGER
set dscp cs1
class DEFAULT
set dscp default
service-policy input MARKING-POLICY
Note : The Service-Policy Model can be expanded to

include policing.

Cisco Catalyst 3560-X/3750-X QoS Design At-A-Glance
Role in Campus Network Trust DSCP Model Step 3: Configure Ingress Queuing
The Cisco Catalyst 3560-X & 3750-X series switches This model is configured with the mls qos trust dscp The ingress queuing model for the Cisco Catalyst
are well suited to the role of access switches in campus interface-configuration command. 3560-X/3750X is shown in Figure 2.
networks. As such, these switches may connect directly The Trust DSCP model configures the interface to Figure 2 Catalyst 3560-X/3750-X Ingress Queuing
to a variety of endpoints, as well as to distribution-layer statically accept and preserve the Layer 3 DSCP markings Model
switches, as shown in Figure 1. of all incoming packets. This model is suitable for
Figure 1 Cisco Catalyst 3560-X/3750-X Switches in a interfaces connecting to endpoints that can mark DSCP Application DSCP 1P1Q3T
Campus Network values and are administratively controlled (such as WLAN Network Control (CS7) EF
Q2
controllers) as well as for any uplinks to distribution layer Internetwork Control CS6
CS5
Priority Queue
CS4
switches. Switch ports that can be set to trust DSCP are VoIP EF
shown as yellow circles in Figure 1. CS7 Q1T3
Broadcast Video CS5
CS6
Conditional Trust Model Multimedia Conferencing AF4 CS3 Q1T2
This model is configured with the mls qos trust device Realtime Interactive CS4 AF4 Q1T1
IP interface-configuration command. Multimedia Streaming AF3 AF3
The Conditional Trust model configures the interface to Signaling CS3

Queue 1
dynamically accept markings from endpoints that have
290910
Transactional Data AF2 AF2 Non-Priority

met a specific condition (currently based on a successful Default Queue
Network Management CS2 CS2
Cisco Discovery Protocol identification). This model is
QoS Design Steps suitable for switch ports connecting to Cisco IP phones Bulk Data AF1 AF1
There are four main steps to configure QoS on Cisco (with the cisco-phone option), Cisco TelePresence Best Effort
Scavenger DF
CS1 CS1
227061
Catalyst 3560-X and 3750-X series switches: Systems (with the cts option), Cisco IP Video Surveillance Best Effort DF DF
1. Enable QoS cameras (with the ip-camera option), and Cisco Digital
Media Players (with the media-player option). This model Step 4: Configure Egress Queuing
2. Configure Ingress QoS Model(s):
is also suitable for PCs and untrusted devices, since the The egress queuing model for the Cisco Catalyst
– Trust DSCP Model ports connecting to such devices will remain in their 3560-X/3750X is shown in Figure 3..
– Conditional Trust Model default untrusted state. Switch ports that can be set to
conditional trust are shown as green circles in Figure 1. Figure 3 Catalyst 3560-X/3750-X Egress Queuing
– Service Policy Models Model
3. Configure Ingress Queuing Service Policy Models
Application DSCP 1P3Q3T
4. Configure Egress Queuing There may be cases where administrators require more
Network Control (CS7) AF1 Queue 4 Q4T2
detailed or granular policies on their ingress edges and as CS1 (5%)
Step 1: Globally Enable QoS such they may construct MQC-based policies to Internetwork Control CS6
Q4T1
Default Queue
QoS is globally enabled on the Cisco Catalyst 3560-X and implement classification, marking, and/or policing VoIP EF DF Queue 3 (35%)
3750-X with the mls qos command. policies. These policies are constructed with: Broadcast Video CS5
CS7 Q2T3
Step 2: Configure Ingress QoS Model(s) • class-maps which identify the flows using packet Multimedia Conferencing AF4
CS6
markings or by access-lists or other criteria Realtime Interactive CS4
The three most utilized ingress QoS models for campus CS3 Q2T2
networks are: • policy-maps which specify policy actions to be taken Multimedia Streaming AF3 Queue 2
(30%)
AF4 Q2T1
on a class-by-class basis Signaling CS3
• Trust DSCP Model AF3
• service-policy statements which apply a specific Transactional Data AF2
• Conditional Trust Model policy-map to an interface(s) and specify direction Network Management CS2
AF2
CS2
• Service Policy Models Bulk Data AF1
EF
Combinations of these ingress QoS models may be used Best Effort
Scavenger DF
CS1
CS5
Q1
Priority Queue
227062
at the same time. Best Effort DF CS4
Campus Cisco Catalyst 3560-X/3750-X QoS Design At-A-Glance
EtherChannel QoS Cisco Validated Design

QoS policies on the Cisco Catalyst 3560-X/3750-X are The Cisco Validated Design for Cisco Catalyst 3650-X and
configured on the physical port-member interfaces only 3750-X series switches in the role of an access switch in a
(and not on the logical Port-Channel interface). campus network is presented below.
Step 1: Enable QoS: Step 3 :Configure Ingress Queuing

mls qos mls qos srr-queue input priority-queue 2 bandwidth 30
mls qos srr-queue input bandwidth 70 30 Ingress Queue and
mls qos srr-queue input buffers 90 10 Threshold Tuning
Step 2: Configure Ingress QoS Model :
mls qos srr-queue input threshold 1 80 90
Trust DSCP Model : mls qos srr-queue input cos-map queue 1 threshold 1 0 1 2
Ingress
mls qos trust dscp mls qos srr-queue input cos-map queue 1 threshold 2 3
CoS-to-Queue
mls qos srr-queue input cos-map queue 1 threshold 3 6 7 Mapping
Conditional Trust Model : mls qos srr-queue input cos-map queue 2 threshold 1 4 5
mls qos trust device cisco-phone or mls qos srr-queue input dscp-map queue 1 threshold 1 0 8 10 12 14
mls qos trust device cts or mls qos srr-queue input dscp-map queue 1 threshold 1 16 18 20 22
mls qos srr-queue input dscp-map queue 1 threshold 1 26 28 30 34 36 38 Ingress
mls qos trust device ip-camera or DSCP-to-Queue
mls qos trust device media-player mls qos srr-queue input dscp-map queue 1 threshold 2 24 Mapping
mls qos srr-queue input dscp-map queue 1 threshold 3 48 56
Service Policy Models : mls qos srr-queue input dscp-map queue 2 threshold 3 32 40 46
[class-maps omitted for brevity]
Step 4 : Configure Egress Queuing
policy-map MARKING-POLICY mls qos queue-set output 1 buffers 15 30 35 20
class VOIP mls qos queue-set output 1 threshold 1 100 100 100 100
set dscp ef Egress Queue and
mls qos queue-set output 1 threshold 2 80 90 100 400 Threshold Tuning
class MULTIMEDIA-CONFERENCING mls qos queue-set output 1 threshold 3 100 100 100 400
set dscp af41 mls qos queue-set output 1 threshold 4 60 100 100 400
class SIGNALING mls qos srr-queue output cos-map queue 1 threshold 3 4 5
set dscp cs3 mls qos srr-queue output cos-map queue 2 threshold 1 2
class TRANSACTIONAL-DATA Egress
mls qos srr-queue output cos-map queue 2 threshold 2 3 CoS-to-Queue
set dscp af21 mls qos srr-queue output cos-map queue 2 threshold 3 6 7 Mapping
class BULK-DATA mls qos srr-queue output cos-map queue 3 threshold 3 0
set dscp af11 mls qos srr-queue output cos-map queue 4 threshold 3 1
class SCAVENGER mls qos srr-queue output dscp-map queue 1 threshold 3 32 40 46
set dscp cs1 mls qos srr-queue output dscp-map queue 2 threshold 1 16 18 20 22
class DEFAULT mls qos srr-queue output dscp-map queue 2 threshold 1 26 28 30 34 36 38
set dscp default Egress
mls qos srr-queue output dscp-map queue 2 threshold 2 24 DSCP-to-Queue
mls qos srr-queue output dscp-map queue 2 threshold 3 48 56 Mapping
mls qos srr-queue output dscp-map queue 3 threshold 3 0
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 10 12 14
Note : The Service-Policy Model can be expanded to
include policing.
queue-set 1
srr-queue bandwidth share 1 30 35 5 Egress Queuing
Interface-Specific Commands
priority-queue out
290911
Cisco Catalyst 3650/3850 QoS Design At-A-Glance
Role in Campus Network Figure 2 Catalyst 3650/3850 2P6Q3T (Wired Port)

The Catalyst 3650/3850 series switches are engineered Conditional Trust Model Egress Queuing Model
to serve as a converged access switch in wired and The Conditional Trust model configures the interface
wireless campus networks. As such, these switches to dynamically accept markings from endpoints that
may connect directly to a variety of endpoints and have met a specific condition, such as a successful Network Control (CS7) EF PQ Level 1 (10%)
distribution-layer switches, as shown in Figure 1. CDP negotiation (switch ports set to conditional trust Internetwork Control CS6 CS5
PQ Level 2 (20%)
Figure 1 Cisco Catalyst 3650/3850 Switch in a are shown as green circles in Figure 1). VoIP EF
CS4
Campus Network This model is suitable for switch ports connecting to: Broadcast Video CS5
CS7 & CS6 Q6
CS3 & CS2 (BWR 10%)
• Cisco IP phones—trust device cisco-phone Multimedia Conferencing AF4

Q5
AF4 (BWR 10% + WTD)
Realtime Interactive CS4
• Cisco TelePresence Systems—trust device cts
Multimedia Streaming AF3 Q4
• Cisco IP Video Surveillance cameras—trust AF3 (BWR 10%
+ DSCP-based WTD)
IP
device ip-camera Signaling CS3
Q3
(BWR 10%
Cisco Digital Media Players—trust device media-
Transactional Data AF2 AF2
295084
• + DSCP-based WTD)
player Network Management CS2

AF1 Q2
QoS Design Steps This model is also suitable for PCs and untrusted Bulk Data AF1
CS1
(BWR 5%
+ DSCP-based WTD)
devices, since the ports connecting to such devices Best Effort
Scavenger DF
CS1
There are two main steps to configure QoS on Cisco will remain in their default untrusted state (shown as Best Effort DF DF Q1 (BWR 25%)
Catalyst 3650/3850 series switches: black circles in Figure 1).
1. Configure Ingress QoS Model(s): Step 2b: Configure Egress Queuing for Wireless
Service Policy Models Ports
– Trust DSCP Model
There may be cases where administrators require The Catalyst 3650/3850 switch supports two levels of
– Conditional Trust Model (wired ports only)
more detailed or granular policies on their ingress priority queueing on wireless ports, as well as one
– Service Policy Models edges and as such they may construct MQC-based non-priority queue for unicast traffic and one non-
2. Configure Egress Queuing policies to implement classification, marking, and/or priority queue for multicast traffic. The switch also
– Wired Queuing Models: 1P7Q3T or 2P6Q3T policing policies. These policies are constructed with: supports a bandwidth control algorithm, Approximate
– Wireless Queuing Model: 2P2Q+AFD • class-maps which identify the flows using packet Fair Drop (AFD), to provide fairness between radios,
markings or by access-lists or other criteria. As SSIDs, and even individual clients
Step 1: Configure Ingress QoS Model(s) of IOS XE 16.3 NBAR2 classification on wired Figure 3 Catalyst 3650/3850 2P2Q+AFD (Wireless
The three most utilized ingress QoS models for campus ports is also supported.
Port) Egress Queuing Model
networks are: • policy-maps which specify policy actions to be
• Trust DSCP Model taken on a class-by-class basis
Application DSCP 2P2Q + AFD
• Conditional Trust • service-policy statements which apply a specific Voice EF

Model policy-map to an interface(s) and specify Multicast Queue
direction Interactive Video CS4

• Service Policy Models AF3
On the Catalyst 3650/3850, service policies may be
Combinations of these ingress QoS models may be AF2 Unicast Queue
applied to wired or wireless ports (shown as red
Streaming Video AF3
used at the same time. DF (63%)
circles in Figure 1) or to individual wireless clients Signaling CS3

CS1
Trust DSCP Model (shown as purple circles in Figure 1). Network Control CS6
Wired ports on the Catalyst 3650/3850 default to a Step 2a: Configure Egress Queuing for Wired Ports CS4
Priority Queue 2
(20%)
Transactional Data AF2
trusted state (shown as orange circles in Figure 1). CS3
Wired ports can be configured with a 1P7Q3T or
Prior to IOS XE 3.3 SE wireless ports defaulted to an
2P6Q3T egress queuing model. The only difference
Best Effort DF
CS6 Priority Queue 1
untrusted state. However, wireless ports could also be
295086
(10%)
between the models is the number of priority queues Scavenger CS1 EF
configured to be trusted by the global configuration
configured via the priority level 1 or priority level 2
command: no qos wireless-default-untrust.
policy-map action commands.
Campus Cisco Catalyst 3650/3850 QoS Design At-A-Glance
IOS XE 16.3 AVC / NBAR2 Policy Example

An example design for a Catalyst 3650/3850 series policy-map NBAR-MARKING class MULTIMEDIA-STREAMING-QUEUE
switch in the role of a converged access switch in a class VOICE bandwidth remaining percent 10
campus network are presented below. set dscp ef queue-buffers ratio 10
class BROADCAST-VIDEO queue-limit dscp af33 percent 80
set dscp cs5 queue-limit dscp af32 percent 90
Step 1: Configure Ingress QoS Model : class REAL-TIME-INTERACTIVE queue-limit dscp af31 percent 100
set dscp cs4 class TRANSACTIONAL-DATA-QUEUE
Trust DSCP Model:
class CALL-SIGNALING bandwidth remaining percent 10
Wired Ports : <default>
Wireless Ports: <default since IOS XE 3.3 SE> set dscp cs3 queue-buffers ratio 10
class TRANSACTIONAL-DATA queue-limit dscp af23 percent 80
Conditional Trust Model: set dscp af21 queue-limit dscp af22 percent 90
trust device cisco-phone or class BULK-DATA queue-limit dscp af21 percent 100
trust device cts or set dscp af11 class SCAVENGER-BULK-DATA-QUEUE
trust device ip-camera or class SCAVENGER bandwidth remaining percent 5
trust device media-player set dscp cs1 queue-buffers ratio 10
class class-default queue-limit dscp values af13 cs1 percent 80
Service Policy Models (Wired ): set dscp default queue-limit dscp values af12 percent 90
queue-limit dscp values af11 percent 100
class-map match-any VOICE Wired Port Application: class class-default
match protocol cisco-phone interface GigabitEthernet 1/0/1 bandwidth remaining percent 25
match protocol cisco-jabber-audio service-policy input NBAR-MARKING queue-buffers ratio 25
match protocol ms-lync-audio
match protocol citrix-audio
Wireless SSID Application:
Wired Port Application:
wlan WLAN-1
class-map match-any BROADCAST-VIDEO service-policy input MARKER
interface GigabitEthernet 1/0/1
match protocol cisco-ip-camera service-policy output 2P6Q3T
class-map match-any REAL-TIME-INTERACTIVE Per-Wireless-Client Application:
match protocol telepresence-media wlan WLAN-1 Step 2b: Configure 2P2Q+AFD Egress Queuing on
class-map match-any CALL-SIGNALING service-policy client input MARKER
Wireless Ports :
match protocol skinny
match protocol telepresence-control Step 2a: Configure 1P7Q3T or 2P6Q3T Egress Queuing
policy-map port_child_policy
class-map match-any TRANSACTIONAL-DATA on Wired Ports (2P6Q3T Example is shown) :
class non-client-nrt-class
match protocol citrix bandwidth remaining ratio 7
match protocol sap policy-map 2P6Q3T
class RT1
priority level 1
class-map match-any BULK-DATA class VOICE-PQ1
police rate percent 10
match protocol attribute category email priority level 1
conform-action transmit
match protocol attribute category file- police rate percent 10
exceed-action drop
sharing class VIDEO-PQ2
class RT2
match protocol attribute sub-category priority level 2
priority level 2
backup-systems police rate percent 20
police rate percent 20
class-map match-any SCAVENGER class CONTROL-MGMT-QUEUE
conform-action transmit
match protocol attribute category gaming bandwidth remaining percent 10
exceed-action drop
match protocol attribute application-group queue-buffers ratio 10
class class-default
skype-group class MULTIMEDIA-CONFERENCING-QUEUE
bandwidth remaining ratio 63
bandwidth remaining percent 10
queue-buffers ratio 10
queue-limit dscp af43 percent 80
Note: This policy is applied automatically to all
queue-limit dscp af42 percent 90 wireless ports and thus no explicit service-
queue-limit dscp af41 percent 100 policy attachment statement is needed.
Note: Yellow highlighted commands are interface specific; otherwise these are global.
Cisco Catalyst 4500 (Supervisor 6-E / 7-E / 8-E) QoS Design At-A-Glance
Role in Campus Network Trust DSCP Model Step 2: Configure Egress Queuing
The Cisco Catalyst 4500 series switches with Supervisor By default all interfaces trust DSCP; as such, no explicit The egress queuing model for the Catalyst 4500 with
6-E/7-E/8-E are well-suited to the role of access- or configuration is required to enable this model. Supervisor 6-E/7-E/8-E is shown in Figure 2.
distribution-layer switches in campus networks. As such,
In the default trust DSCP state, the interface statically Figure 2 Cisco Catalyst 4500 Supervisor 6-E / 7-E / 8-E
these switches may connect directly to a variety of
accepts and preserves the Layer 3 DSCP markings of all Egress Queuing Model
endpoints, as well as to distribution-layer and/or core-
incoming packets. This model is suitable for interfaces
layer switches, as shown in Figure 1.
connecting to endpoints that can mark DSCP values and Application DSCP 1P7Q1T (+DBL)
Figure 1 Cisco Catalyst 4500 Series Switch with are administratively controlled (such as WLAN Network Control (CS7) EF
Supervisor 6-E/7-E/8-E in a Campus controllers) as well as for any uplinks to distribution layer Internetwork Control CS6 CS5
PQ (30%)
Network switches. Switch ports that should trust DSCP are VoIP EF CS4
shown as yellow circles in Figure 1. Broadcast Video CS5 CS7 & CS6
Q7 (10%)
CS3 & CS2
Multimedia Conferencing AF4
Conditional Trust Model AF4
Realtime Interactive CS4 Q6 (10%)
The Conditional Trust model configures the interface to Multimedia Streaming AF3
dynamically accept markings from endpoints that have AF3 Q5 (10%)
Signaling CS3
met a specific condition, such as a successful CDP
negotiation (switch ports set to conditional trust are Transactional Data AF2 AF2 Q4 (10%)
IP shown as green circles in Figure 1). Network Management CS2
AF1 Q3 (4%)
Bulk Data AF1
This model is suitable for switch ports connecting to: CS1 Q2 (1%)
Best Effort
Scavenger DF
CS1
• Cisco IP phones—trust device cisco-phone
227066
Best Effort DF DF Q1 (25%)
290912
• Cisco TelePresence Systems—trust device cts

EtherChannel QoS
• Cisco IP Video Surveillance cameras—trust device ip-
QoS Design Steps camera Ingress QoS policies (such as classification & marking
policies) on the Cisco Catalyst 4500 Supervisor 6-E/7-
There are only two main steps to configure QoS on a Cisco • Cisco Digital Media Players—trust device media- E/8-E are configured on the logical Port-Channel
Catalyst 4500 series switch with Supervisor 6-E/7-E/8-E: player interface (but typically these are simply to enable DSCP
1. Configure Ingress QoS Model(s): trust—which requires no explicit configuration), Egress
This model is also suitable for PCs and untrusted QoS policies (such as the service-policy-statement to
– Trust DSCP Model devices, since the ports connecting to such devices will enable egress queuing) are configured on the physical
– Conditional Trust Model remain in their default untrusted state. port-member interfaces.
– Service Policy Models
Service Policy Models Cisco Validated Design (CVD)
2. Configure Egress Queuing
There may be cases where administrators require more The Cisco Validated Design for Cisco Catalyst 4500
Step 1: Configure Ingress QoS Model(s) detailed or granular policies on their ingress edges and with Supervisor 6-E/7-E/8-E in the role of an access
as such they may construct MQC policies to implement switch in a campus network is presented below.
The three most utilized ingress QoS models for campus
classification, marking, and/or policing policies. These
networks are:
policies are constructed with:
• Trust DSCP Model • class-maps which identify the flows using packet
• Conditional Trust Model markings or by access-lists or other criteria
• Service Policy Models • policy-maps which specify policy actions to be taken on
Combinations of these ingress QoS models may be used a class-by-class basis
at the same time.
• service-policy statements which apply a specific policy-
map to an interface(s) and specify direction
Campus Cisco Catalyst 4500 Supervisor 6-E/7-E QoS Design At-A-Glance
Step 1: Configure Ingress QoS Model : Step 2 : Egress Queuing Configuration

class-map match-any PRIORITY-QUEUE
Assigns VoIP (EF)
Trust DSCP Model : match dscp ef Broadcast Video (CS5) and
<no configuration/default state> match dscp cs5 Realtime Interactive (CS4) to the PRIORITY-QUEUE
match dscp cs4
Conditional Trust Model : class-map match-any CONTROL-MGMT-QUEUE
class-map match-all VOICE match dscp cs7 Assigns Network Control (CS7), Internetwork Control (CS6),
match cos 5 match dscp cs6 Signaling (CS3) and Management (CS2) to the
class-map match-all SIGNALING match dscp cs3 CONTROL-MGMT-QUEUE
match cos 3 match dscp cs2
class-map match-all MULTIMEDIA-CONFERENCING-QUEUE Assigns AF4 to the
match dscp af41 af42 af43 MULTIMEDIA-CONFERENCING-QUEUE
policy-map CISCO-IPPHONE class-map match-all MULTIMEDIA-STREAMING-QUEUE Assigns AF3 to the
class VOICE match dscp af31 af32 af33 MULTIMEDIA-STREAMING-QUEUE
set dscp ef class-map match-all TRANSACTIONAL-DATA-QUEUE Assigns AF2 to the
class SIGNALING match dscp af21 af22 af23 TRANSACTIONAL-DATA-QUEUE
set dscp cs3 class-map match-all BULK-DATA-QUEUE Assigns AF1 to the
class class-default match dscp af11 af12 af13 BULK-DATA-QUEUE
set dscp default class-map match-all SCAVENGER-QUEUE Assigns CS1 to the
match dscp cs1 SCAVENGER-QUEUE
qos trust device cisco-phone
service-policy input CISCO-IPPHONE
policy-map EGRESS-QUEUING PRIORITY-QUEUE gets strict priority servicing
class PRIORITY-QUEUE (All other queues get percentages of bandwidth remaining
priority after the PQ has been fully serviced)
class CONTROL-MGMT-QUEUE
Service Policy Models : CONTROL-MGMT-QUEUE gets 10% of remaining bandwidth
[class-maps omitted for brevity] class MULTIMEDIA-CONFERENCING-QUEUE MM-CONF-QUEUE gets 10% of remaining bandwidth
policy-map MARKING-POLICY bandwidth remaining percent 10
class VOIP class MULTIMEDIA-STREAMING-QUEUE
MM-STREAMING-QUEUE gets 10% of remaining bandwidth
set dscp ef bandwidth remaining percent 10
class MULTIMEDIA-CONFERENCING class TRANSACTIONAL-DATA-QUEUE
TRANS-DATA-QUEUE gets 10% of remaining bandwidth
set dscp af41 bandwidth remaining percent 10
and Dynamic Buffer Limiting
class SIGNALING dbl
class BULK-DATA-QUEUE
set dscp cs3
bandwidth remaining percent 4 BULK-DATA-QUEUE gets 4% of remaining bandwidth
class TRANSACTIONAL-DATA and Dynamic Buffer Limiting
dbl
set dscp af21 class SCAVENGER-QUEUE
class BULK-DATA SCAVENGER-QUEUE is limited to 1% of remaining bandwidth
set dscp af11 class class-default
Default (Best-Effort) queue 25% of remaining bandwidth
class SCAVENGER bandwidth remaining percent 25 and Dynamic Buffer Limiting
set dscp cs1 dbl
class class-default
set dscp default
service-policy output EGRESS-QUEUING Applies EGRESS-QUEUEING policy to interface
290913
And the Cisco Press Book: End-to-End QoS Network Design (Second Edition)-Chapter 15
Cisco Catalyst 6500 (Supervisor 2T) QoS Design At-A-Glance
Role in Campus Network Figure 2 Catalyst 6500 Sup2T (2P6Q4T) Ingress and Egress Queuing Model
The Cisco Catalyst 6500 series switches with
Supervisor 2Ts are well-suited to the role of
distribution- or core-layer switches in campus
networks. As such, these switches typically connect
directly to other switches or routers, as shown in
Figure 1.
Figure 1 Cisco Catalyst 6500 Supervisor 2T Switches in
a Campus Network
EtherChannel QoS
Trust DSCP
Ingress classification& marking QoS policies on the Cisco Catalyst
293375
+ Ingress Queuing
+ Egress Queuing 6500 are configured on the logical Port-Channel interface (typically
these are simply to enable DSCP trust, which is enabled by default on
the Sup2T) . Ingress and egress queuing QoS policies are configured
QoS Design Steps
on the physical port-member interfaces.
There are two main steps to configure QoS on
Cisco Catalyst 6500 series switches with Cisco Validated Design (CVD)
Supervisor 2T:
The Cisco Validated Design for Cisco Catalyst 6500 series switches
1. Configure Ingress Queuing with Supervisor 2T in the role of a distribution- or core-layer switch in
a campus network is presented below.
Steps 1 & 2: Configure Ingress & Egress Queuing:

The 2P6Q4T queuing model for both ingress and
egress queuing for the Cisco Catalyst 6500 with
Supervisor 2T is shown in Figure 2.
Campus Cisco Catalyst 6500 Supervisor 2T QoS Design At-A-Glance
Step 1: Configure (Common) Class-Maps to be used for both Ingress & Step 2 Configure 2P6Q4T Ingress & Egress Queuing Policy-Map
Egress Queuing Policies and apply to Interface(s)
class-map type lan-queuing VOICE-PQ1
policy-map type lan-queuing 2P6Q4T
match dscp ef
class-map type lan-queuing VIDEO-PQ2
class VOICE-PQ1
match dscp cs4 cs5
class-map type lan-queuing CONTROL-MGMT-QUEUE priority level 1
match dscp cs2 cs3 cs6 cs7 class VIDEO-PQ2
class-map type lan-queuing MULTIMEDIA-CONFERENCING-QUEUE priority level 2
match dscp af41 af42 af43 class CONTROL-MGMT-QUEUE
class-map type lan-queuing MULTIMEDIA-STREAMING-QUEUE bandwidth remaining percent 5
match dscp af31 af32 af33 class MULTIMEDIA-CONFERENCING-QUEUE
class-map type lan-queuing TRANSACTIONAL-DATA-QUEUE bandwidth remaining percent 20
match dscp af21 af22 af23 random-detect dscp af41 percent 80 100
class-map type lan-queuing SCAVENGER-BULK-DATA-QUEUE random-detect dscp af42 percent 70 100
random-detect dscp af43 percent 60 100
class MULTIMEDIA-STREAMING-QUEUE
class TRANSACTIONAL-DATA-QUEUE
class BULK-DATA-QUEUE
random-detect dscp cs1 percent 50 100
class class-default
random-detect dscp default percent 80 100
service-policy type lan-queuing input 2P6Q4T
service-policy type lan-queuing output 2P6Q4T

Note: Highlighted commands are interface specific; otherwise these are global

Cisco Catalyst 6500 (Supervisor 720 / Supervisor 32) QoS Design At-A-Glance
Role in Campus Network Step 3: Configure Ingress Queuing Step 4: Configure Egress Queuing
The Cisco Catalyst 6500 series switches are well-suited to Three considerations need to be taken into account when The egress queuing model for the Cisco Catalyst
the role of distribution- or core-layer switches in campus determining if ingress queuing configuration is required 6500 (with 6708 or 6716 linecards) is shown in Figure
networks. As such, these switches typically connect on the Cisco Catalyst 6500 linecard: 3.
directly to other switches or routers, as shown in Figure 1.
• Is the linecard oversubscribed? Figure 3 Catalyst 6500 (6716) Egress Queuing Model
To simplify design, this document assumes the use of
• Is the linecard operating in the distribution or core
WS-X6716-10GE linecards.
layers of the campus network? Application DSCP 1P7Q4T
Network Control (CS7) EF

• Does the linecard support DSCP-to-Queue CS5 PQ (30%)
Figure 1 Cisco Catalyst 6500 Switches in a Campus Internetwork Control CS6 CS4
mapping?
Network VoIP EF CS7 Q7T4
Ingress queuing is only recommended when the answer CS6 Q7 (10%) Q7T3
Broadcast Video CS5 CS3 Q7T2
to all three questions is Yes. CS2 Q7T1
The ingress queuing model for the Cisco Catalyst 6500
Realtime Interactive CS4 AF4 Q6 (10%)
(with 6716 linecards) is shown in Figure 2.
Multimedia Streaming AF3
AF3 Q5 (10%)
Figure 2 Catalyst 6500 (6716) Ingress Queuing Model
Signaling CS3
Application DSCP 1P7Q2T Transactional Data AF2 AF2 Q4 (10%)
Network Control (CS7) Network Management CS2

EF Q8 (PQ) AF1 Q3 (4%)
Internetwork Control CS6 CS5 Bulk Data AF1
CS7 Q7T2 DF Q1 (25%)
290914
VoIP EF Best Effort

Scavenger DF
CS1
CS6 Q7 (10%)
227070
Broadcast Video CS5 CS3 Q7T1 Best Effort DF CS1 Q2 (1%)
CS2
QoS Design Steps Realtime Interactive CS4
CS4
AF4 Q6 (10%) EtherChannel QoS
There are four main steps to configure QoS on Cisco Multimedia Streaming AF3 Ingress QoS policies on the Cisco Catalyst 6500 are
AF3 Q5 (10%)
Catalyst 6500 series switches: Signaling CS3 configured on the logical Port-Channel interface (typically
1. Enable QoS Transactional Data AF2 AF2 Q4 (10%) these are simply to enable DSCP trust) , while egress QoS
2. Configure DSCP-Trust Network Management CS2 policies are configured on the physical port-member
AF1 Q3 (4%) interfaces.
3. Configure Ingress Queuing Bulk Data AF1
Best Effort
Scavenger DF
CS1 DF Q2 (25%)
4. Configure Egress Queuing Cisco Validated Design (CVD)
228292
Best Effort DF CS1 Q1 (1%)
The Cisco Validated Design for Cisco Catalyst 6500
Step 1: Globally Enable QoS
series switches with WS-X6716-10GE linecards in the role
QoS is globally enabled on the Cisco Catalyst 6500 with of a distribution- or core-layer switch in a campus
the mls qos command. network is presented on the reverse.
Step 2: Configure DSCP-Trust

DSCP trust is configured with the mls qos trust dscp
interface-configuration command.
Switch ports that can be set to trust DSCP are shown as
yellow circles in Figure 1.
Campus Cisco Catalyst 6500 QoS Design At-A-Glance
Step 1: Enable QoS Step 4: Configure Egress Queuing (continued)

mls qos
wrr-queue random-detect 1
Step 2: Configure DSCP-Trust wrr-queue random-detect 3 Enables WRED
mls qos trust dscp wrr-queue random-detect 4 on Egress Queues 1-7
Step 3: Configure Ingress Queuing wrr-queue random-detect 6 Tunes WRED on
Enables DSCP-based wrr-queue random-detect 7
mls qos queue-mode mode-dscp Queue/Threshold Mapping Egress Queues 1-7
wrr-queue random-detect max-threshold 1 100 100 100 100

rcv-queue bandwidth 1 25 4 10 10 10 10 Ingress Queue
wrr-queue random-detect min-threshold 1 80 100 100 100
rcv-queue queue-limit 10 25 10 10 10 10 10 Tuning
rcv-queue threshold 1 100 100 wrr-queue random-detect max-threshold 3 80 90 100 100
rcv-queue threshold 2 100 100 wrr-queue random-detect min-threshold 3 70 80 90 100
rcv-queue threshold 3 80 100 Ingress wrr-queue random-detect min-threshold 4 70 80 90 100
rcv-queue threshold 4 80 100 Threshold wrr-queue random-detect max-threshold 4 80 90 100 100
rcv-queue threshold 5 80 100 Tuning wrr-queue random-detect min-threshold 5 70 80 90 100
rcv-queue dscp-map 1 2 8 wrr-queue random-detect max-threshold 7 70 80 90 100
rcv-queue dscp-map 2 2 0
rcv-queue dscp-map 3 1 12 14 wrr-queue dscp-map 1 1 8
rcv-queue dscp-map 3 2 10 wrr-queue dscp-map 2 1 0
rcv-queue dscp-map 4 2 18 Ingress wrr-queue dscp-map 3 2 12
rcv-queue dscp-map 5 1 28 30 DSCP-to-Queue/Threshold wrr-queue dscp-map 3 3 10
Mapping wrr-queue dscp-map 4 1 22
wrr-queue dscp-map 4 3 18
rcv-queue dscp-map 6 2 32 34
wrr-queue dscp-map 5 1 30 Egress
rcv-queue dscp-map 7 1 16 24
wrr-queue dscp-map 5 2 28 DSCP-to-Queue/Threshold
rcv-queue dscp-map 7 2 48 56 wrr-queue dscp-map 5 3 26 Mapping
Step 4: Configure Egress Queuing wrr-queue dscp-map 6 3 34
wrr-queue queue-limit 10 25 10 10 10 10 10 Egress Queue
Tuning
wrr-queue bandwidth 1 25 4 10 10 10 10 wrr-queue dscp-map 7 2 24
priority-queue queue-limit 15 wrr-queue dscp-map 7 3 48
priority-queue dscp-map 1 32 40 46
290915
Note: Highlighted commands are global; otherwise these are interface specific.

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html.
Cisco Catalyst 6500 (Supervisor 720-10GE) QoS Design At-A-Glance
Role in Campus Network Step 3: Configure Ingress Queuing Step 4: Configure Egress Queuing
The Cisco Catalyst 6500 Series switches with Three considerations need to be taken into account The egress queuing model for the Cisco Catalyst
Sup720s are well-suited to the role of distribution- or when determining if ingress queuing configuration is 6500 (with 6708 or 6716 linecards) is shown in
core-layer switches in campus networks. As such, required on the Cisco Catalyst 6500 linecard: Figure 3.
these switches typically connect directly to other
• Is the linecard oversubscribed? Figure 3 Catalyst 6500 (6716) Egress Queuing Model
switches or routers, as shown in Figure 1.
• Is the linecard operating in the distribution or
To simplify design, this document assumes the use of
core layers of the campus network? Application DSCP 1P7Q4T
WS-X6716-10GE linecards. EF
• Does the linecard support DSCP-to-Queue
Network Control (CS7)
CS5 PQ
CS4
Figure 1 Cisco Catalyst 6500 Switches in a Campus mapping? Internetwork Control CS6
CS7
Network VoIP EF
Ingress queuing is only recommended when the CS6 Q7 (10% BWR)
Broadcast Video CS5 CS3
answer to all three questions is Yes. CS2
The ingress queuing model for the Cisco Catalyst AF4
Q6 (20%) BWR +
DSCP-WRED
6500 (with 6716 linecards) in oversubscription mode
is shown in Figure 2. Multimedia Streaming AF3

AF3
Q5 (15% BWR) +
DSCP-WRED
Signaling CS3
Figure 2 Catalyst 6500 (6716) Ingress Queuing Model Q4 (15% BWR) +
DSCP-WRED
Application DSCP 1P7Q2T Network Management CS2
Q3 (9% BWR) +
AF1
Network Control (CS7) CS4
Bulk Data AF1 DSCP-WRED
EF Q8 (PQ)
Internetwork Control CS6 CS5
Best Effort
Scavenger DF
CS1 DF Q1 (30% BWR)
290914
227070
VoIP EF CS7
CS6 Q7 (10% BWR) Best Effort DF CS1 Q2 (1% BWR)
Broadcast Video CS5 CS3
CS2
QoS Design Steps Multimedia Conferencing AF4
Q6 (20% BWR) +
EtherChannel QoS
DSCP Tail-Drop
Ingress classification & marking QoS policies on the
There are four main steps to configure QoS on
AF4
Cisco Catalyst 6500 series switches: Multimedia Streaming AF3

AF3
Q5 (15% BWR) + Cisco Catalyst 6500 are configured on the logical
DSCP Tail-Drop
1. Enable QoS
Signaling CS3 Port-Channel interface (typically these are simply to
Q4 (15% BWR) +
DSCP Tail-Drop
enable DSCP trust). Ingress and egress queuing QoS
2. Configure DSCP-Trust policies are configured on the physical port-member
Network Management CS2
Q3 (9% BWR) +
3. Configure Ingress Queuing Bulk Data AF1
AF1
DSCP Tail-Drop interfaces.
4. Configure Egress Queuing Best Effort
Scavenger DF
CS1 DF Q1 (30% BWR)
228292
Best Effort DF CS1 Q2 (1% BWR)
Step 1: Globally Enable QoS The Cisco Validated Design for Cisco Catalyst 6500
QoS is globally enabled on the Cisco Catalyst 6500 series switches with WS-X6716-10GE linecards in the
with the mls qos command. role of a distribution- or core-layer switch in a
campus network is presented on the reverse.
Step 2: Configure DSCP-Trust
DSCP trust is configured with the mls qos trust dscp
interface-configuration command.
Switch ports that can be set to trust DSCP are
shown as yellow circles in Figure 1.
Campus Cisco Catalyst 6500 QoS Design At-A-Glance
Step 1: Enable QoS Step 4: Configure Egress Queuing (continued)

mls qos
no wrr-queue random-detect 2
Step 2: Configure DSCP-Trust wrr-queue random-detect 3 Enables WRED
mls qos trust dscp wrr-queue random-detect 4 on Egress Queues 1 and 3-6
Step 3: Configure Ingress Queuing wrr-queue random-detect 6 Tunes WRED on
mls qos queue-mode mode-dscp
Enables DSCP-based no wrr-queue random-detect 7 Egress Queues
Queue/Threshold Mapping
rcv-queue bandwidth 30 1 9 15 15 20 10
Ingress Queue
rcv-queue queue-limit 25 10 10 15 15 15 10 wrr-queue random-detect min-threshold 1 80 100 100 100
100 100 100 100
Tuning
wrr-queue random-detect max-threshold 3
rcv-queue threshold 3 80 100 Ingress wrr-queue random-detect max-threshold 4 60 70 80 100
rcv-queue threshold 4 80 100 Threshold wrr-queue random-detect min-threshold 5 100 100 100 100
rcv-queue threshold 5 80 100 Tuning wrr-queue random-detect max-threshold 5 60 70 80 100

Ingress wrr-queue dscp-map 4 1 22
DSCP-to-Queue/Threshold wrr-queue dscp-map 4 2 20
Mapping
rcv-queue dscp-map 5 2 26 Egress
wrr-queue dscp-map 5 1 30 DSCP-to-Queue/Threshold
rcv-queue dscp-map 6 1 36 38 wrr-queue dscp-map 5 2 28 Mapping
rcv-queue dscp-map 7 1 16 24 48 56 wrr-queue dscp-map 6 1 38
priority-queue dscp-map 1 32 40 46 wrr-queue dscp-map 6 3 34
priority-queue queue-limit 15 wrr-queue dscp-map 7 1 16 24 48 56
priority-queue dscp-map 1 32 40 46
Step 4: Configure Egress Queuing
wrr-queue queue-limit 25 10 10 10 10 10 10 Egress Queue
wrr-queue bandwidth 30 1 9 15 15 20 10 Tuning
priority-queue queue-limit 15
290915
Note: Highlighted commands are global; otherwise these are interface specific.

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html.
Cisco Nexus 7700 (F3 Module) Campus QoS Design At-A-Glance
Role in Campus Network Figure 2 Nexus 7700 F3 (4Q1T) Ingress Queuing Model
The Cisco Nexus series switches with F3 modules are
suited to the role of a core-layer switch in campus
networks. As such, these switches typically connect
directly to other switches or routers, as shown in Figure 1.
Figure 1 Cisco Nexus 7700 (F3 Module) Switches in a
Campus Network
Step 2: Configure Egress Queuing

QoS Design Steps
The (CoS-Based) 1P7Q1T egress queuing model for the Cisco Nexus 7700 with F3 module is shown in Figure 3.
There are two main steps to configure QoS on
Cisco Nexus 7700 series switches with F3 modules: Figure 3 Nexus 7700 F3 (CoS-Based 1P7Q1T) Egress Queuing Model
1. Configure Ingress Queuing

Step 1: Configure Ingress Queuing

The 4Q1T ingress queuing model for the Cisco Nexus
7700 with F3 modules is shown in Figure 2.

The Cisco Validated Design for Cisco Nexus 7700 series
switches with F3 modules in the role of a core-layer
switch in a campus network is presented on the reverse.
Cisco Nexus 7700 (F3 Module) Campus QoS Design At-A-Glance
Step 1: Configure 4Q1T Ingress Queuing Policies Step 2 Configure (CoS-Based) 1P7Q1T Egress Queuing Policies
class-map type queuing match-any 8e-4q8q-in-q1
match cos 5
match cos 5-7
no match dscp 40-63
no match dscp 40-63
match dscp 32, 40, 46, 48, 56
match dscp 32, 40, 46, 48, 56
class-map type queuing match-any 8e-4q8q-in-q3 class-map type queuing match-any 8e-4q8q-in-q3
match cos 2-4, 6-7 match cos 2-4
match dscp 16, 18, 20, 22 match dscp 16, 18, 20, 22
match dscp 24, 26, 28, 30 match dscp 24, 26, 28, 30
match dscp 34, 36, 38 match dscp 34, 36, 38
class-map type queuing match-any 8e-4q8q-in-q4 match cos 1
match cos 1 match dscp 8, 10, 12, 14
match dscp 8, 10, 12, 14 class-map type queuing match-any 8e-4q8q-in-q-default
class-map type queuing match-any 8e-4q8q-in-q-default match cos 0
match cos 0
policy-map type queuing CAMPUS-F3-4Q1T-INGRESS policy-map type queuing 1P7Q1T-OUT

class type queuing 8e-4q8q-in-q1
bandwidth percent 30 class type queuing 8e-4q8q-out-q1
queue-limit percent 10 priority level 1
class type queuing 8e-4q8q-in-q-default shape average percent 30
queue-limit percent 30 bandwidth remaining percent 55
class type queuing 8e-4q8q-in-q3 class type queuing 8e-4q8q-out-q3
bandwidth percent 40 bandwidth remaining percent 10
queue-limit percent 30 class type queuing 8e-4q8q-out-q4
class type queuing 8e-4q8q-in-q4 bandwidth remaining percent 1
queue-limit percent 30 bandwidth remaining percent 1
class type queuing 8e-4q8q-out-q6
service-policy type queuing input CAMPUS-F3-4Q1T-INGRESS class type queuing 8e-4q8q-out-q7
293378
class type queuing 8e-4q8q-out-q-default
service-policy type queuing output 1P7Q1T-OUT
For more details on Cisco Nexus 7000 QoS design,

see the Cisco Press book: End-to-End QoS Network Design (Second Edition)-Chapter 25
WLAN QoS Design At-A-Glance
The Case for QoS in the Wireless LAN IEEE 802.11e EDCF Arbitration Interframe Spaces (AIFS)
Wireless access points are the second most-likely places The original 802.11 standard described a Distributed Each wireless station was wait a fixed (and a variable)
in the enterprise network to experience congestion (after Coordination Function (DCF) to avoid collisions over the amount of time once the medium is clear prior to
LAN-to-WAN links). This is because wireless media: WLAN. However, this function had no support for QoS. In attempting to transmit. The fixed amount of time is called
• generally presents a downshift in speed/throughput 2006, the 802.11e task group provided several the AIFS. EDCF skewed these fixed delays on a per-
• is a half-duplex media enhancements to this function to support QoS, hence the access category basis, such that higher-priority ACs are
• is a shared media term: Enhanced Distributed Coordination Function assigned shorter wait times as compared to the lower-
(EDCF). These enhancements include: priority ACs. This approach thus gives the high-priority
Furthermore, the nature of wireless media presents traffic better probability of being transmitted first. AIFS by
additional challenges from a QoS provisioning User Priorities (UP) access category are shown in Figure 3.
perspective, including: 802.11e introduced a 3 bit marking value in layer 2
wireless frames referred to as User Priority (UP); UP Figure 3 IEEE 802.11e AIFS by Access Category
• No support for strict priority queuing
• No support for guaranteed bandwidth allocations values range from 0-7. UP fields are showin in Figure 1.
• Non-deterministic media access
Figure 1 IEEE 802.11e User Priority Field
• A maximum of four levels of service
As such, the case for QoS on the WLAN is to minimize

packet drops due to congestion, as well as to minimize
jitter due to non-deterministic access to the half-duplex,
shared media.
WLAN QoS Design Best Practices Contention Windows

Four QoS design principles that apply to WLAN If two or more wireless devices begin transmitting after
deployments include: waiting only a fixed amount of time after the air is clear
• Classify and mark applications as close to their sources (the AIFS), then the probability of collisions would be
as technically and administratively possible high. However, in addition to waiting a fixed amount of
Access Categories (AC)
• Police unwanted traffic flows as close to their sources time, each station must also wait a variable amount of
Pairs of UP values are assigned to 4 access categories,
as possible time, called a random backoff. The range for these
which statistically equate to 4 distinct levels of service
• Enable queuing policies at every node where the random backoffs is between 0 and the current size of the
over the WLAN. Access categories and their UP pairings
potential for congestion exists the Contention Window (CW). The CW can increase
are shown in Figure 2.
over time, but begins at an initial minimum value
WLAN QoS Design Considerations Figure 2 IEEE 802.11e Access Categories (CWmin). The values for CWmin are skewed by access
There are several considerations unique to WLANs that categories, as are the maximum values for Contention
must be factored into QoS designs: Windows (the CWmax values), as shown in Figure 4.
• The IEEE 802.11e Enhanced Distributed Coordination
Function (EDCF), including: Figure 4 IEEE 802.11e Contention Windows by AC
 User Priorities
 Access Categories
 Arbitration Inter-Frame Spaces (AIFS)
 Contention Windows (CW)
 EDCF Operation
 Transmission Opportunity (TXOP)
 Transmission Specification (TSpec)
• UP-to-DSCP and DSCP-to-UP Mapping
WLAN QoS Design At-A-Glance
EDCF Operation Figure 5 IEEE 802.11e AIFS and CWmin by Access Category
When the AIFS and random backoff timers are
combined, then the skewing of the probability of
transmission of each access categories becomes even
more apparent, as shown in Figure 5 (right).
Each wireless station (including the access point, which Transmission Opportunity (TXOP) Conversely, in the reverse direction, the CoS or UP
is competing on equal terms with endpoint devices for EDCF provides contention-free period access to the values are simply multiplied by 8 (in order to shift these
airtime) waits until all timers have elapsed before wireless medium, called the Transmission Opportunity three binary bits to the left) to generate a DSCP value.
attempting transmission. Statistically, any endpoint (TOXP). The TXOP is a set period of time when a Continuing the example, UP 5 (binary 101) would be
transmitting voice traffic will have a better chance at wireless station may send as many frames as possible mapped (i.e., multiplied by 8) to DSCP 40 (binary
being the next to use the media; however, this is not without having to contend with other stations. With 101000), also referred to as Class Selector 5 (CS5).
guaranteed, because of the random value of the CW TXOP, each station has a set time limit when it can
timers. transmit; once this limt expires, it must give up access to As can be seen in the above pair of examples, because
the medium. information is being truncated from 6-bits to 3-bits,
If in the event that two (or more) stations still begin marking details can get lost in translation. In this
transmitting at the same time, then all stations will Transmission Specification (TSpec) example, the original voice packet was sent with DSCP
effectively double their CW sizes and try again. This One last major enhancement introduced by 802.11e is a EF, but was received as DSCP CS5 (based solely on
process repeats (as needed) until the CWmax value for mechanism for Call Admission Control (CAC) called default Layer 2-to-Layer 3 mapping). This needs to be
an AC is reached. At this point, Contention Windows Transmission Specification (TSpec). TSpec allows real- taken into account when mapping from wired-to-wireless
remain fixed at the CWmax size until a defined time applications, such as voice or video calls in- and vice-versa.
transmission attempt limit is reached (e.g. on Cisco APs progress, to be prioritized over requests for new calls. To
this limit is 64 transmission attempts). This operation is use this feature of EDCF, TSpec must be configured on Also, it bears explicit mention that (Layer 2) IEEE and
shown in Figure 6. the AP and optionally on the client stations. (Layer 3) IETF marking recommendations do not always
align. For example, DSCP EF/46 is recommended by the
Figure 6 Contention Window Operation DSCP-to-UP and UP-to-DSCP Mapping IETF for use for voice, which would map by default to UP
Upstream and downstream DSCP<>UP mapping is 5; but the IEEE designates UP 6 for voice. Similarly, the
shown in Figure 7. By default, 6-bit DSCP values are IETF recommends DSCP CS4 or AF4 for real-time or
mapped to 3-bit 802.11e UP values by taking the three interactive video conferencing, both of which would map
Most-Significant Bits (MSB) of the DSCP and copying by default to UP 4; but the IEEE designates UP 5 for
these as UP values. For example, DSCP EF/46 (binary video. Such discrepancies must also be taken into
101110) is mapped to CoS or UP 5 (binary 101), by account and reconciled in WLAN QoS designs
default.
Figure 7
Downstream
(DSCP-to-UP)
Mapping &
Upstream
(UP-to-DSCP)
Mapping
For more details, see the AVC/QoS Design chapter of the BYOD CVD at:
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/BYOD_Design_Guide/BYOD_AVC.html
And/or the Cisco Press book: End-to-End QoS Network Design (Second Edition)-Chapter 18
AireOS Wireless LAN Controller AVC/QoS Design At-A-Glance
Role in Wireless Campus Network Figure 1 Design Recommendations for the Platinum QoS Profile for an Employee WLAN
Cisco AireOS wireless LAN controllers centrally

manage QoS policies on wireless LAN access points,
as well as perform advanced QoS operations, such
as Application Visibility and Control (AVC)
classification, marking and policing.
QoS Design Steps
There are three main steps required to configure

AVC/QoS on AireOS WLCs:
1. Select and tune the desired QoS Profile

2. Configure an AVC Profile
3. Apply the QoS and AVC Profiles on the
WLAN and enable Application Visibility
Step 1: Selecting and Tuning the QoS Profile

QoS Profiles are applied to both upstream and
downstream flows on WLC egress. The WLAN QoS
Profile defines (as shown in Figure 1):
• Per-User Bandwidth Contracts—(Optional)
per-user limits for average and peak data and realtime
traffic rates.
• Per-SSID Bandwidth Contracts—(Optional) per-
SSID limits for average and peak data and realtime
traffic rates.
• WLAN Maximum Priority—The highest DSCP
marking value that may be used on the WLAN; this
value can override AVC policies as well DSCP-values
received from the wired network. As such, in
multiservice WLANs, it is generally recommended to
ensure that the Maximum Priority value be set to
voice.
• Unicast and Multicast Default Priority—The default
DSCP marking value to be used on the WLAN for all
traffic not explicitly classified by an overriding AVC
Profile. Typically these values are set as best effort;
however there may be cases where this default value
may be set to background (i.e., bronze), such as if
applied to a guest WLAN.
• Wired QoS Protocol—Can be set to 802.1p and the
maximum CoS value can be defined per WLAN
Cisco AireOS WLC AVC/QoS Design At-A-Glance
Figure 2 Example AVC Profile for an Employee WLAN

Step 2: Configure an AVC Profile
AVC Profiles are applied to both upstream and
downstream flows on WLC ingress. While this may
simplify the QoS policy configuration on the WLC, it
has design implications in upstream/downstream
mapping.
Additionally, each WLAN can have only one AVC

profile attached to it to control applications, however
an AVC Profile can be attached to multiple WLANs.
Also, an AVC Profile can contain a maximum of 32
application rules and a maximum of 16 AVC profiles
can be created on a WLC. Also, only 3 AVC
applications may be policed in a given profile.
As has been previously discussed, it also is important

to note that each WLAN can have both a QoS Profile
and an AVC Profile attached to it. The AVC Profile is
applied when the packet enters the WLC and the QoS
policy is applied when packet exits the WLC. QoS
Profiles may define a Maximum Priority (DSCP value)
for packet marking, which will override any AVC Profile
marking policy. Thus care should be taken that QoS
and AVC Profiles are correctly configured to
complement-and not contradict-one another.
An example AVC Profile is shown in Figure 2.
Step 3: Apply the QoS and AVC Profiles on the

WLAN and enable Application Visibility With the
QoS and AVC Profiles defined, all that remains is to
enable these on a given WLAN, as shown in Figure 3.
Additionally, by checking the box for AVC, Application
Visibility is enabled on the WLAN.
Figure 3 Example AVC Profile for an Employee WLAN
WLAN QoS Mapping for AireOS Wireless LAN Controllers At-A-Glance
The Case for QoS Mapping in the Wireless LAN Figure 1: Default Downstream DSCP-to-UP Mapping
As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is
crucial that Quality of Service be aligned between wired-and-wireless networks; however,
this is not always the case by default. This is due to the fact that two independent standards
bodies provide QoS guidance on wired and wireless networks: specifically, the IETF offers
design recommendations for wired IP networks, while a separate and autonomous
standards-body, the IEEE, administers the standards for wireless 802.11 networks. As
such, custom QoS mappings are required between IETF Differentiated Services Code Point
(DSCP) and IEEE 802.11 User Priority (UP) markings to reconcile the design
recommendations offered by these two standards bodies, and, as such, to optimize
wired-and-wireless interconnect QoS.
Three are three general options for wired/wireless QoS mapping:

• (Downstream) DSCP-to-UP Mapping
• (Upstream) UP-to-DSCP Mapping Figure 2: Default Upstream UP-to-DSCP Mapping
• (Upstream) DSCP-Trust
Note: In AireOS, these options are combined with QoS Profiles, which can limit the
maximum marking values in use to/from a given WLAN.
DSCP-to-UP Mapping
Downstream DSCP-to-UP mapping is shown in Figure 1.
By default, 6-bit DSCP values are mapped to 3-bit 802.11e UP values by taking the three
Most-Significant Bits (MSB) of the DSCP and copying these as UP values. For example,
the IETF recommended marking for voice (DSCP EF/46-binary 101110) is mapped by
default to UP 5 (binary 101); which, incidentally is an IEEE recommended marking for
video (IEEE marks voice as UP 6).
Note: To partially compensate for IETF/IEEE marking misalignments, AireOS implements

some non-default mappings, as specified in the QoS Translation Table at:
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/configuration-guide/b_cg81/
b_cg81_chapter_01010111.html Figure 3: Upstream DSCP Trust
Upstream DSCP-to-UP Mapping
Upstream UP-to-DSCP mapping is shown in Figure 2.
Conversely, in the reverse direction, UP values are simply multiplied by 8 (in order to shift
these three binary bits to the left) to generate a DSCP value. Continuing the example, the
IEEE recommended marking for voice (UP 6-binary 110) would be mapped by default (i.e.,
multiplied by 8) to DSCP CS6/48 (binary 110000); which, incidentally is an IETF recom-
mended marking for network control traffic (rather than EF/46, the IETF marking for voice).
Upstream DSCP Trust

Upstream DSCP trust is shown in Figure 3.
To prevent information from being lost in translation (which can happen when converting 6-
bit markings to/from 3-bit markings), as well to prevent IEEE UP markings to generate
misaligned IETF DSCP markings, Cisco wireless access points can also be configured to
Trust DSCP. In this example, a voice packet marked EF can likewise have its CAPWAP
outer DSCP set to match.
WLAN QoS Mapping for AireOS Wireless LAN Controllers At-A-Glance
Cisco DSCP<>UP QoS Mapping Recommendations

AireOS Recommended QoS Mapping Configuration
As previously mentioned, (Layer 2) IEEE and (Layer 3) Note: This requires AireOS 8.1MR+
IETF marking recommendations do not always align.
For example, DSCP EF/46 is recommended by the
IETF for use for voice, which would map by default to Step 1: Disable the 802.11 Networks and the Current QoS Map
UP 5; but the IEEE designates UP 6 for voice. These (Cisco Controller) > config 802.11a disable network
discrepancies must be taken into account and (Cisco Controller) > config 802.11b disable network
reconciled in WLAN QoS designs, as shown in Figure (Cisco Controller) > config qos qosmap disable
4 which presents Cisco's Recommended DSCP-to-UP
Mappings. Step 2: Configure the UP-to-DSCP Maps
Even though DSCP will be trusted in the upstream direction (rather then implementing UP-to-DSCP Maps), specifying
Figure 4: Cisco Recommended DSCP-to-UP the UP-to-DSCP maps is a syntactical requirement. Additionally, the first line also has the additional benefit of mapping
Mapping the whole DSCP range (0-63) to UP 0.
(Cisco Controller) > config qos qosmap up-to-dscp-map 0 0 0 7
Step 3: Configure DSCP-to-UP Mapping Exceptions

Only the exceptions noted in Figure 4 will be explicitly mapped to various UP values; all remaining (unused) DSCPs will
continue to be mapped to UP 0.
Note: The details behind Cisco's recommendations (Cisco Controller) > config qos qosmap dscp-to-up-exception 46 6
for IETF/IEEE QoS Mapping are documented in the (Cisco Controller) > config qos qosmap dscp-to-up-exception 40 5
Internet Draft: https://tools.ietf.org/html/draft-ietf- (Cisco Controller) > config qos qosmap dscp-to-up-exception 38 4
tsvwg-ieee-802-11-03 (Cisco Controller) > config qos qosmap dscp-to-up-exception 36 4
(Cisco Controller) > config qos qosmap dscp-to-up-exception 34 4
In the upstream, Cisco recommends DSCP-trust, for (Cisco Controller) > config qos qosmap dscp-to-up-exception 32 5
the following reasons: (Cisco Controller) > config qos qosmap dscp-to-up-exception 30 4
• This is a standards-based approach (per RFC (Cisco Controller) > config qos qosmap dscp-to-up-exception 28 4
2474 and 2475) (Cisco Controller) > config qos qosmap dscp-to-up-exception 26 4
• Most wireless device operating systems generate (Cisco Controller) > config qos qosmap dscp-to-up-exception 24 4
UP values by using the 3 MSB of the encapsulated (Cisco Controller) > config qos qosmap dscp-to-up-exception 22 3
6-bit DSCP; then, at the access point, these 3-bit (Cisco Controller) > config qos qosmap dscp-to-up-exception 20 3
mappings are converted back into DSCP values; in (Cisco Controller) > config qos qosmap dscp-to-up-exception 18 3
such cases, information is lost in the transitions from (Cisco Controller) > config qos qosmap dscp-to-up-exception 16 0
6-bit marking to 3-bit marking and then back to 6-bit (Cisco Controller) > config qos qosmap dscp-to-up-exception 14 2
marking; trusting the encapsulated DSCP prevents (Cisco Controller) > config qos qosmap dscp-to-up-exception 12 2
this loss of information (Cisco Controller) > config qos qosmap dscp-to-up-exception 10 2
• A practical implementation benefit is also realized, (Cisco Controller) > config qos qosmap dscp-to-up-exception 8 1
as enabling applications to mark DSCP is much
more prevalent and accessible to programmers of Step 4: Enable DSCP-Trust, the New Qos Maps and the 802.11 Networks
wireless applications vis-a-vis trying to explicitly set (Cisco Controller) > config qos qosmap trust-dscp-upstream enable
UP values, which requires special hooks into the (Cisco Controller) > config qos qosmap enable
wireless device operating system (Cisco Controller) > config 802.11a enable network
(Cisco Controller) > config 802.11b enable network
IOS XE Wireless LAN Controller AVC/QoS Design At-A-Glance
Role in Wireless Campus Network Step 2: (Optional) Create a Flow Exporter Step 2: Configure a Policy-Map
An optional second step is to configure a flow exporter. The policy map will specify the action to be performed on a given
Cisco IOS XE wireless LAN controllers may be
The flow exporter defines the destination and transport class of traffic. These actions may include:
deployed in a centralized controller model or in a
parameters of the management station that the flow • Marking via the set command
converged access model. In either deployment model,
details are to be exported to via Flexible NetFlow • Policing via the police command
IOS XE controllers centrally manage QoS policies
(FNF). Application flow information is gathered by the • Dropping via the drop command
which - in turn - are enforced on wireless LAN access
NBAR2 engine on the access point and sent to the Note: Only upstream dropping is supported
points, including:
management station using NetFlow version 9 format.
• Application Visibility and Control (AVC) Step 3: Attach the Policy-Map to the WLAN
• classification The policy map is attached to the desired WLAN(s) via a service-
Step 3: Create a Flow Monitor
• marking policy statement, which also specifies direction of application.
The next step is to configure a flow monitor. A flow
• policing
monitor associates a flow record with an optional flow
• dropping Configuring DSCP-to-UP Table Maps
exporter and can be applied to a WLAN.
• DSCP-to-UP and UP-to-DSCP mapping
There may be times when the default mappings between L2 User
Step 4: Apply the Flow Monitor to the WLAN Priority and L3 DSCP may be sub-optimal for QoS. This can
Enabling Application Visibility
Once the flow monitor has been defined, then it can be sometimes be the case because of marking recommendation
There are four steps to enabling application visibility on applied to a given WLAN(s) and the direction of discrepancies between the IEEE and IETF standards bodies.
IOS XE wireless LAN controllers: application can be specified.
1. Create a Flow Record The Cisco-recommended DSCP-to-UP mappings to reconcile
2. (Optional) Create a Flow Exporter Configuring AVC/QoS Policies IETF and IEEE markings are shown in Figure 1.
3. Create a Flow Monitor
Application Visibility - by itself- only reports traffic
4. Apply the Flow Monitor to the WLAN Figure 1 Cisco Recommended DSCP-to-UP Mappings
statistics; however, the same deep packet inspection
engine can be coupled with QoS policies to control
Step 1: Create a Flow Record
these applications, via marking, policing or even
The first step in enabling application visibility for IOS
outright dropping.
XE wireless controllers is to configure a flow record. A
flow record specifies the details of a given flow that is
The steps to configure AVC/QoS policies on IOS XE
to be tracked by matching one or more of the following
wireless LAN controllers are:
parameters:
1. Configure AVC-based class-maps
• IPv4 Source Address
2. Configure a policy map to mark, police or
• IPv4 Destination Address
drop applications
• Transport Protocol Source-Port
3. Apply the policy-map to the WLAN
• Transport Protocol Destination Port
• Flow Direction Step 1: Configure AVC-based Class-Maps
• Application Name The key command to enabling AVC within a standard
• WLAN SSID Modular QoS Command-Line-Interface (MQC) class-
map is match protocol. This command can be
Once the match details are specified so as to identify a configured to match on:
discrete flow, then the flow record also specifies the In the upstream direction, Cisco recommends trusting DSCP.
• Individual applications:
type of statistics and information that is to collected by
match protocol application_name Note: The details behind Cisco's recommendations
the flow record, including:
• Categories of applications: for IETF/IEEE QoS Mapping are documented in the
• Bytes
match protocol attribute category category_name Internet Draft:
• Packets
• Sub-categories of applications: https://tools.ietf.org/html/draft-szigeti-tsvwg-ieee-802-11e-00
• Access Point (BSSID) MAC address
match protocol attribute sub-category sub_cat_name
• Client MAC address
• Groups of applications:
match protocol attribute application-group app_group_name
Cisco IOS XE WLC AVC/QoS Design At-A-Glance
Enabling Application Visibility Configuring AVC/QoS Policies Configuring Downstream

DSCP-to-UP Table Map
Step 1: Create a Flow Record Step 1: Configure AVC-based Class-Maps (Upstream DSCP-Trust is enabled
class-map match-any VOICE by default)
flow record AVC-FLOW-RECORD
match protocol cisco-phone
description BASIC-AVC-FLOW-RECORD
class-map match-any BROADCAST-VIDEO Step 1: Configure Cisco-Recommended
match ipv4 protocol
match protocol cisco-ip-camera Downstream DSCP-to-UP Table Map
match ipv4 source address
class-map match-any REAL-TIME-INTERACTIVE
match ipv4 destination address table-map DSCP-to-UP
match protocol telepresence-media
match transport source-port map from 46 to 6
class-map match-any CALL-SIGNALING
match transport destination-port map from 40 to 5
match protocol skinny
match flow direction map from 38 to 4
match protocol telepresence-control
match application name map from 36 to 4
class-map match-any TRANSACTIONAL-DATA
match wireless ssid map from 34 to 4
match protocol citrix
collect counter bytes long map from 32 to 5
match protocol sap
collect counter packets long map from 30 to 4
class-map match-any BULK-DATA
collect wireless ap mac address map from 28 to 4
match protocol attribute category email
collect wireless client mac address map from 26 to 4
match protocol attribute category file-sharing
map from 24 to 4
match protocol attribute sub-category backup-systems
map from 22 to 3
class-map match-any SCAVENGER
Step 2: Create a Flow Exporter map from 20 to 3
match protocol attribute category gaming
flow exporter AVC-FLOW-EXPORTER map from 18 to 3
match protocol attribute application-group skype-group
destination 10.10.10.10 map from 16 to 0
transport udp 2055 map from 14 to 2
destination 10.20.20.20 Step 2: Configure a Policy-Map map from 12 to 2
transport udp 9991 policy-map AVC-MARKING map from 10 to 2
class VOICE map from 8 to 1
Note: Lancope collects Netflow on port 2055 and set dscp ef default 0
Cisco Prime Infrastructure collects Netflow on port 9991 class BROADCAST-VIDEO
set dscp cs5 Step 2: Reference this Table-Map within a
class REAL-TIME-INTERACTIVE Policy-Map
Step 3: Create a Flow Monitor
set dscp cs4 policy-map DSCP-TO-UP-POLICY
flow monitor AVC-FLOW-MONITOR class class-default
record AVC-FLOW-RECORD set wlan user-priority
set dscp cs3
exporter AVC-FLOW-EXPORTER dscp table DSCP-to-UP
set dscp af21
class BULK-DATA Step 3: Attach the Policy-Map to WLAN
Step 4: Apply the Flow Monitor to the WLAN
set dscp af11 wlan EMPLOYEE-WLAN
wlan EMPLOYEE-WLAN class SCAVENGER service-policy output
ip flow monitor AVC-FLOW-MONITOR input set dscp cs1 DSCP-TO-UP-POLICY
ip flow monitor AVC-FLOW-MONITOR output class class-default
set dscp default
Note: Highlighted commands are interface specific;
otherwise these are global. Step 3: Attach the Policy-Map to the WLAN
wlan EMPLOYEE-WLAN
service-policy client input AVC-MARKING
And the Cisco Press book: End-to-End QoS Network Design (Second Edition)-Chapters 20 & 21
Cisco Catalyst 9000 Series QoS Design At-A-Glance
Roles in Campus Network Step 1: Configure Ingress QoS Model(s) • policy-maps which specify policy actions to be
The three most utilized ingress QoS models for taken on a class-by-class basis
The Catalyst 9300 & 9400 Series switches are
engineered to serve as access-layer switches in campus networks are: • service-policy statements which apply a specific
campus networks. As such, these switches may • Trust DSCP Model policy-map to an interface(s) and specify
connect directly to a variety of endpoints and • Conditional Trust Model direction
aggregation-layer switches, as shown in Figure 1. • Service Policy Models On the Catalyst 9300 Series, service policies may be
Figure 1 Cisco Catalyst 9300 & 9400 Series Combinations of these ingress QoS models may be applied to switch ports (shown as red circles in
Switches in a Campus Network used at the same time. Figure 1).
Trust DSCP Model Step 2: Configure Egress Queuing for Switch Ports
Switch ports on the Catalyst 9000 Series default to a Switch ports can be configured with an 8Q3T,
trusted state (shown as orange circles in Figures 1 1P7Q3T, or 2P6Q3T egress queuing model. The only
IP and 2). difference between the models is the number of
priority queues configured via the prioritylevel 1 or
Conditional Trust Model
295084
priority level 2 policy-map action commands.

The Conditional Trust model configures the interface
Figure 3 Cisco Catalyst 9000 Series 2P6Q3T
The Catalyst 9500 Series switches are engineered to to dynamically accept markings from endpoints that
Egress Queuing Model
serve as core or aggregation-layer switches in campus have met a specific condition, such as a successful
networks. As such, these switches may connect CDP negotiation (switch ports set to conditional trust
directly to other core, aggregation-layer, or access- are shown as green circles in Figure 1).
Network Control (CS7) EF PQ Level 1 (10%)
layer switches, as shown in Figure 2. This model is suitable for switch ports connecting to:
Internetwork Control CS6 CS5
Figure 2 Cisco Catalyst 9500 Series Switches • Cisco IP phones - trust device cisco-phone CS4
PQ Level 2 (20%)
VoIP EF
in a Campus Network • Cisco TelePresence Systems - trust device cts Broadcast Video CS5
CS7 & CS6
(BWR 10%) Q6
• Cisco IP Video Surveillance cameras - trust CS3 & CS2
device ip-camera AF4
(BWR 15%) Q5
• Cisco Digital Media Players - trust device Realtime Interactive CS4 (DSCP-Based WTD or WRED)
media-player Multimedia Streaming AF3

AF3
(BWR 15%) Q4
DSCP-based WTD or WRED)

Signaling CS3
This model is also suitable for PCs and untrusted Q3
293375
(BWR 15%
devices, since the ports connecting to such devices Transactional Data AF2 AF2 DSCP-based WTD or WRED)
Trust DSCP
will remain in their default untrusted state (shown as Network Management CS2
AF1 (BWR 10%) Q2
+ Egress Queuing black circles in Figure 1). Bulk Data AF1

DSCP-based WTD or WRED)
CS1
Scavenger
Service Policy Models CS1
QoS Design Steps There may be cases where administrators require

Best Effort DF DF (BWR 35%) Q1
DSCP-based WRED)
There are two main steps to configure QoS on Cisco more detailed or granular policies on their ingress
Catalyst 9000 Series switches: edges and as such they may construct MQC-based Both WRED and WTD are supported on Catalyst 9000
policies to implement classification, marking, and/or Series switches. WRED can be applied on up to four
1. Configure Ingress QoS Model(s): queues only. Additional queues can implement WTD
policing policies. These policies are constructed
– Trust DSCP Model if desired.
with:
– Conditional Trust Model IOS XE 16.8.1 AVC / NBAR2 Policy Example
• class-maps which identify the flows using packet
– Service Policy Models markings, access-lists, NBAR2 classification, or An example design for a Catalyst 9000 Series in the
2. Configure Egress Queuing other criteria role of an access-layer switch in a campus network,
– Queuing Models: 8Q3T, 1P7Q3T or 2P6Q3T using match protocol attribute commands and
DSCP-based WRED is presented below.
Campus Cisco Catalyst 9000 Series QoS Design At-A-Glance
Step 1: Configure Ingress QoS Model : class REAL-TIME-INTERACTIVE class-map match-any TRANSACTIONAL-DATA-QUEUE
set dscp cs4 match dscp af21
Trust DSCP Model: match dscp af22
class MULTIMEDIA-CONFERENCING
Switch Ports : <default> match dscp af23
set dscp af41
class-map match-any SCAVENGER-BULK-DATA-QUEUE
class MULTIMEDIA-STREAMING match dscp af11
Conditional Trust Model: set dscp af31 match dscp af12
trust device cisco-phone or Note: Yellow highlighted class SIGNALING match dscp af13
trust device cts or commands are interface set dscp cs3 match dscp cs1
trust device ip-camera or specific; otherwise these class NETWORK-CONTROL
policy-map 2P6Q3T-WRED
trust device media-player are global. set dscp cs6
class NETWORK-MANAGEMENT class VOICE-PQ1
set dscp cs2 priority level 1
Service Policy Models: police rate percent 10
class VIDEO-PQ2
class-map match-all VOICE set dscp af21
priority level 2
match protocol attribute traffic-class voip-telephony class BULK-DATA
match protocol attribute business-relevance business-relevant set dscp af11 police rate percent 20
class-map match-all BROADCAST-VIDEO class SCAVENGER class CONTROL-MGMT-QUEUE
match protocol attribute traffic-class broadcast-video set dscp cs1 bandwidth remaining percent 10
match protocol attribute business-relevance business-relevant class class-default queue-buffers ratio 10
class-map match-all REAL-TIME-INTERACTIVE set dscp default class MULTIMEDIA-CONFERENCING-QUEUE
match protocol attribute traffic-class real-time-interactive bandwidth remaining percent 15
Switch Port Application:
match protocol attribute business-relevance business-relevant interface GigabitEthernet 1/0/1
class-map match-all MULTIMEDIA-CONFERENCING service-policy input NBAR-MARKING
match protocol attribute traffic-class multimedia-conferencing queue-limit dscp af42 percent 90
match protocol attribute business-relevance business-relevant class MULTIMEDIA-STREAMING-QUEUE
class-map match-all MULTIMEDIA-STREAMING Step 2: Configure 8Q3T, 1P7Q3T or 2P6Q3T Egress bandwidth remaining percent 15
match protocol attribute traffic-class multimedia-streaming Queuing on Switch Ports (2P6Q3T Example with WRED queue-buffers ratio 10
is shown) :
match protocol attribute business-relevance business-relevant queue-limit dscp af33 percent 80
class-map match-all SIGNALING class-map match-any VOICE-PQ1
match protocol attribute traffic-class signaling match dscp ef
class TRANSACTIONAL-DATA-QUEUE
match protocol attribute business-relevance business-relevant class-map match-any VIDEO-PQ2
class-map match-all NETWORK-CONTROL match dscp cs4
match protocol attribute traffic-class network-control match dscp cs5 random-detect dscp-based
match protocol attribute business-relevance business-relevant class-map match-any CONTROL-MGMT-QUEUE random-detect dscp 18 percent 80 100
class-map match-all NETWORK-MANAGEMENT match dscp cs7 random-detect dscp 20 percent 70 100
match protocol attribute traffic-class ops-admin-mgmt match dscp cs6 random-detect dscp 22 percent 60 100
match protocol attribute business-relevance business-relevant match dscp cs3 class SCAVENGER-BULK-DATA-QUEUE
class-map match-all TRANSACTIONAL-DATA match dscp cs2 bandwidth remaining percent 10
match protocol attribute traffic-class transactional-data class-map match-any MULTIMEDIA- queue-buffers ratio 10
match protocol attribute business-relevance business-relevant CONFERENCING-QUEUE random-detect dscp-based
class-map match-all BULK-DATA match dscp af41 random-detect dscp 8 percent 60 100
match protocol attribute traffic-class bulk-data match dscp af42 random-detect dscp 10 percent 80 100
match protocol attribute business-relevance business-relevant match dscp af43 random-detect dscp 12 percent 70 100
class-map match-all SCAVENGER class-map match-any MULTIMEDIA-STREAMING- random-detect dscp 14 percent 60 100
match protocol attribute business-relevance business-irrelevant QUEUE class class-default
match dscp af31 bandwidth remaining percent 35
policy-map NBAR-MARKING match dscp af32 queue-buffers ratio 25
class VOICE match dscp af33 random-detect dscp-based
set dscp ef [Continued...] random-detect dscp 0 percent 80 100
class BROADCAST-VIDEO
set dscp cs5 Switch Port Application:
[Continued...] interface GigabitEthernet 1/0/1
service-policy output 2P6Q3T-WRED
At a glance
Cisco public
Cisco DNA Application Experience

Intent-Based Networking for Applications in the Enterprise
Requirements of intent-based networks

The primary functions of intent-based networks are:
• Translation and validation of intent: Business-level intent is expressed by
an operator and is translated into validated platform-specific configurations.
• Automation: Network device configurations are deployed at scale by
a controller.
• Analytics: The network operational state is continually monitored
via telemetry.
• Assurance: The system validates that the expressed intent is being delivered
via quantitative metrics OR recognizes that the intent is not being met and
then guides or automates remediation actions.
The Cisco® Digital Network Architecture (Cisco DNA™), illustrated in Figure 1,
meets all of these requirements for intent-based application networking in
the enterprise.
© 2018 Cisco and/or its affiliates. All rights reserved.

At a glance
Cisco public
Figure 1. Cisco Digital Network Architecture Figure 2. Creating an intent-based Cisco DNA Application Policy
DNA Software Capabilities
Cloud Service Management
3
Automation Analytics
1
Virtualization
2
DNA Physical and Virtual Infrastructure
Security
Cisco DNA Application Policy

Network operators can deploy application policies across their routed,
Cisco DNA delivers intent-based networking for applications via the
switched, and wireless enterprise infrastructure with just three easy steps:
following three main components:
• Cisco DNA Application Policy (item 1 in Figure 1) is an application within 1. Name their policy.
Cisco DNA Center™ that solicits business intent, translates and validates 2. Select a site scope (to which their policy will apply).
this intent, and automates the deployment of Cisco Validated Design
3. Assign business relevance to their applications.
configurations to network devices.
Note: Operators can also perform optional steps, such as tuning bandwidth
• Cisco Programmable Infrastructure (item 2 in Figure 1): Programmable
allocations and/or service provider profiles, as well as previewing and testing
hardware enables powerful infrastructure software solutions to recognize
the policy prior to deployment.
and prioritize application traffic, as well as report on application
treatment across the enterprise routing, switching, and wireless network; Operators can assign applications to one of three levels of business
this capability includes advanced application recognition for hundreds of relevance, as shown in Figure 2.
encrypted applications, without compromising privacy or confidentiality.
• Business relevant: These applications are known to contribute to the
• Cisco DNA Application Assurance (item 3 in Figure 1) is an application business objectives of the organization.
within DNA Center that ingests telemetry data from the network and
• Default: These applications may or may not contribute to business
adjacent data sources and performs contextual correlation and analytics
objectives, or there is no business reason to justify explicit policy treatment.
to determine the network state in the context of the expressed intent.
This application provides assurance either by confirming that the intent is • Business irrelevant: These applications are known to have no
being met (and supplying quantitative metrics to support such a validation) contribution to business-objectives.
or by identifying that the intent is not being met and then initiating guided
remediation workflows.
© 2018 Cisco and/or its affiliates. All rights reserved.

At a glance
Cisco public
Cisco DNA Programmable Infrastructure Figure 4. Cisco DNA Application Assurance—Application Health Summary
The next set of requirements for enforcing application policy across the
infrastructure is:
• Identifying the applications on the network, even though the majority of
these are encrypted
• Grouping these applications into traffic classes
• Expressing the operator-selected business relevance of the applications
• Marking the traffic from end to end across the network
• Applying consistent congestion management and congestion avoidance to
the traffic from end to end across the network
DNA Center abstracts heterogeneous platform-specific tools and features
needed to implement these requirements across the network and deploys a
consistent, cohesive, and comprehensive policy to express the intent from Cisco DNA Application Assurance
end to end, as shown in Figure 3.
Cisco DNA Application Assurance closes the intent-based application
A key technology used by Cisco DNA infrastructure is Next-Generation experience loop illustrated in Figure 1.
Network-Based Application Recognition (NBAR2). NBAR2 recognizes over
1400 applications, including more than 150 encrypted applications (without Cisco DNA Application Assurance ingests telemetry data from the network,
compromising confidentiality or privacy). NBAR2 is now supported not only on as well as from relevant non-network sources (such as application servers,
routing and wireless platforms, but also on switching platforms, such as the peer-analytics systems, client devices, etc.) and performs contextual
Cisco Catalyst® 9300 Series, because of its advanced Cisco Unified Access® correlation and analysis of all such data to determine the operational state of
Data Plane (UADP) 2.0 Application-Specific Integrated Circuit (ASIC). applications on the enterprise network.
Figure 3. Cisco DNA infrastructure enabling and enforcing Cisco DNA Application Policy To do this, Cisco DNA Application Assurance monitors multiple application
Key Performance Indicators (KPIs) and—by applying standards-based
guidance—interprets these for the network operator. In such a manner,
DNAC Southbound APIs translate business intent to
platform specific configurations raw network data (such as latency, jitter, and packet-loss values) can be
transformed into more meaningful information, such as the overall health
score of an application, as shown in Figure 4.
Wireless AP
ASR/ISRs Wireless AP
Additionally, Cisco DNA Application Assurance flags issues with
Trust Boundary
PEP
4Q (WMM)
Catalyst 4500 Nexus 7700
AVC PEP Trust Boundary
PEP underperforming applications and presents actionable insights and guided
1P7Q1T F3: 1P7Q1T 4Q (WMM)
WLC
remediation to the network operator.
Catalyst 9300 Catalyst 6500 Catalyst 3650
Trust Boundary AVC PEP Trust Boundary
1P3Q4T
AVC PEP 1P7Q4T PEP
2P6Q3T 2P6Q4T 1P3Q3T
...
© 2018 Cisco and/or its affiliates. All rights reserved. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/go/trademarks.
Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) C45-740915-00 07/18

00 Combined Cisco QoS AAGs

Uploaded by

Copyright:

Available Formats

00 Combined Cisco QoS AAGs

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

00 Combined Cisco QoS AAGs

Uploaded by

Copyright:

Available Formats

Strategic QoS Design At-A-Glance

With this application metadata in place in the local DNS server

Consider two main DNS-AS use-cases:

The DNS-AS operational steps to identify external applications are:

7) The access switch maintains a Binding Table of

Figure 1 Cisco APIC-EM Architecture

Such dynamic QoS policies allow for these applications to

There are 5 main steps to these dynamic QoS policies:

Step 2: APIC-EM translates the strategic policy into

Note: classification policies for voice and

Note: Queuing policies (not shown in Figure 3,

Step 4: APIC-EM dynamically pushes out ACEs to the

Step 5: APIC-EM is informed of a terminated call.

Step 6: APIC-EM removes the ACEs corresponding to

Deploying Cisco IWAN QoS Figure 2 8-class Egress Queuing Model

Figure 5 DMVPN Per-Tunnel QoS

When the access rate of an interface is different from the

Class-map for 8-class QoS Model

class-map match-any VOICE

Cisco access switch dynamically

(if required and supported)

Ingress Queuing Policies

Signaling Classifier Mark CS3

Bulk Data Classifier Mark AF11 Bulk Data Policer(<10 Mbps)

• Guaranteed bandwidth queue (RFC 2597 AF PHB) Signaling CS3

For more details, see Campus QoS Design 4.0:

Transactional Data AF2

Cisco Validated Design

Step 1: Enable QoS: Step 3 : Configure Egress Queuing

service-policy input MARKING-POLICY

Note : The Service-Policy Model can be expanded to

For more details, see Campus QoS Design 4.0:

The Conditional Trust model configures the interface to Signaling CS3

Transactional Data AF2 AF2 Non-Priority

EtherChannel QoS Cisco Validated Design

Step 1: Enable QoS: Step 3 :Configure Ingress Queuing

Role in Campus Network Figure 2 Catalyst 3650/3850 2P6Q3T (Wired Port)

• Cisco IP phones—trust device cisco-phone Multimedia Conferencing AF4

player Network Management CS2

• Conditional Trust • service-policy statements which apply a specific Voice EF

direction Interactive Video CS4

circles in Figure 1) or to individual wireless clients Signaling CS3

IOS XE 16.3 AVC / NBAR2 Policy Example

• Cisco IP phones—trust device cisco-phone

• Cisco TelePresence Systems—trust device cts

Step 1: Configure Ingress QoS Model : Step 2 : Egress Queuing Configuration

Steps 1 & 2: Configure Ingress & Egress Queuing:

service-policy type lan-queuing input 2P6Q4T

service-policy type lan-queuing output 2P6Q4T

For more details, see Campus QoS Design 4.0:

Network Control (CS7) EF

Application DSCP 1P7Q2T Transactional Data AF2 AF2 Q4 (10%)

Network Control (CS7) Network Management CS2

VoIP EF Best Effort

Step 2: Configure DSCP-Trust

Step 1: Enable QoS Step 4: Configure Egress Queuing (continued)

wrr-queue random-detect max-threshold 1 100 100 100 100

For more details, see Campus QoS Design 4.0:

is shown in Figure 2. Multimedia Streaming AF3

Cisco Catalyst 6500 series switches: Multimedia Streaming AF3