QoS Design

QoS Design Principles:

One design principle is to always enable QoS policies in hardware rather than software whenever a choice exists as QoS in software places incremental loads on CPU.

Classification and Marking Principles: In order to provide end-to-end Differentiated Services and PHBs, Cisco recommends to classify and mark applications as close to their sources as technically and administratively feasible.

Standards-Based DSCP PHB marking should be used  whenever possible to interoperability between Enterprise and Service Provider, and also benefit future expansion. DSCP marking also benefit end-to end QoS, because Layer 2 markings are lost when media changes (such as a LAN-to-WAN/VPN edge).

Policing and Markdown Principles: Cisco recommends to police traffic flows as close to their sources as possible, and markdown should be done according to standards-based rules whenever supported. Following such markdowns, congestion management policies, such as DSCP-based WRED, should be configured to drop packets.

Single-rate policers can be configured to markdown excess traffic to DSCP CS1 (Scavenger); dual-rate policers can be configured to mark down excess traffic to AFx2, while marking down violating traffic to DSCP CS1. Traffic marked as Scavenger would then be assigned to a “less-than-Best-Effort” queue.

Queuing and Dropping Principles: The only way to provide service guarantees for Critical applications such as VoIP is to enable queuing at any node that has the potential for congestion regardless of how rarely this may occur. This principle applies not only to Campus-to-WAN/VPN edges, where speed mismatches are most pronounced, but also to Campus Access-to-Distribution or Distribution-to-Core links, where oversubscription ratios create the potential for congestion.

It is recommended that you reserve at least 25 percent of link bandwidth for the default Best Effort class. Cisco Technical Marketing testing has shown a significant decrease in data application response times when real-time traffic exceeds one-third of link bandwidth capacity. Extensive testing and customer deployments have shown that a general best queuing practice is to limit the amount of strict priority queuing(LLQ) to 33 percent of link capacity.

Whenever a Scavenger queuing class is enabled, it should be assigned a minimal amount of bandwidth. On a platform that only supports 4 queues with CoS-based admission(such as a Catalyst switch while IOS Router support 11 queues with DSCP-based admission), Scavenger traffic and Bulk Data can not be distinguished as they have same CoS values. In such cases you can assign the Scavenger/Bulk queuing class a bandwidth percentage of 5.

In order to let traffic receives compatible queuing at each node, regardless of platform capabilities, the inter-relationship between these compatible queuing models (4 queues on Catalyst switch and 11 queues on IOS platform) is defined as below,


Whenever supported, you should enable WRED (preferably DSCP-based WRED) on all TCP flows. WRED congestion avoidance prevents TCP global synchronization and increases overall throughput and link efficiency. Enabling WRED on UDP flows is optional.

Campus QoS Design:

Common campus oversubscription values are 20:1 for the access-to-distribution layers and 4:1 for the distribution-to-core layers, as shown below:


Access switches require the following QoS policies:
• Appropriate (endpoint-dependant) trust policies, and/or classification and marking policies
• Policing and markdown policies
• Queuing policies.

Distribution and core switches require the following QoS policies:
• DSCP trust policies
• Queuing policies
• Optional per-user microflow policing policies (only on supported platforms)

Access Edge Trust Models:

Trust Endpoint: Trusted endpoints have the capabilities and intelligence to mark application traffic to the appropriate CoS and/or DSCP values. Trusted endpoints also have the ability to remark traffic that may have been previously marked by an untrusted device. Trusted endpoints are not typically mobile devices, which means that the switch port into which they are plugged does not usually change. Cisco IP Phones, which often change switch ports as users move, are more appropriately classified as conditionally-trusted endpoints.

Examples of trusted endpoints include the following; Analog gateways, IP conferencing stations, Videoconferencing gateways and systems, Video surveillance units, Servers in DC, Wireless access points, Wireless IP Phones. When trusted endpoints are connected to a switch port, all that is typically required is enabling the following interface command: mls qos trust dscp.

Untrusted Endpoints: This section includes two following scenarios:
• Untrusted PC + SoftPhone with Scavenger-Class QoS
• Untrusted Server with Scavenger-Class QoS

Untrusted PC + SoftPhone with Scavenger-Class QoS: A classic example is a PC running Cisco IP Softphone. In such a case, the critical VoIP application needs to be identified using access lists (UDP port range 16384-32768) and marked/remarked at the access edge. A policer is recommended in this case because limits on the amount of traffic being marked can then be imposed to prevent abuse.


Untrusted Server with Scavenger-Class QoS: Servers as well as PCs are subject to attack and infection by worms and viruses, so these should also be policed as to the amounts of traffic they admit onto the network. The values are greater than PC endpoints and so network administrators should profile traffic patterns from servers to establish a baseline of normal and abnormal behavior.

Application baselining has shown that 95 percent of the traffic rates for SAP, Lotus Notes and IMAP are less than 15 Mbps, 35 Mbps and 50 Mbps, respectively. To ensure that no other traffic comes from the server, a final policer to catch any other type traffic is included.


Conditionally-Trusted Endpoints: This section includes the following topics:
• Cisco IP Phones
• Cisco AutoQoS—VoIP
• Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model
• Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model

Cisco IP Phones:As switch ports might be connected to a PC or IP phone, access switch has an intelligent discovery of PC and IP phone using CDP, thus dynamically extend the trust boundary if IP phone is connected.

All of the IP Phones listed above have the ability to mark 802.1Q/p CoS values for both VoIP and call signaling (default values are 5 and 3, respectively). Furthermore, they also have the ability to mark DSCP values for both VoIP and call signaling (current defaults are EF and AF31, respectively; future software releases will change these values to EF and CS3, respectively). All IP phones (excluding 7912) also support 802.1Q/p CoS remarking of tagged packets that may originate
from the PCs connected to them.

AutoQoS—VoIP: AutoQoS VoIP automatically configures the best-practice QoS configurations (based on previous Cisco Enterprise QoS SRNDs) for VoIP on Cisco Catalyst switches and IOS routers by entering one global and/or one interface command depending on the platform.

For example, on Cisco Catalyst switches, AutoQoS performs the following automatically:
• Enforces a conditional-trust boundary with any attached Cisco IP phones
• Enforces a trust boundary on Catalyst switch access ports and uplinks/downlinks
• Modifies CoS-to-DSCP (and IP Precedence-to-DSCP) mappings, as required
• Enables Catalyst strict priority queuing for voice (CoS 5/DSCP EF) and preferential queuing for
Call-Signaling traffic (CoS 3/DSCP CS3)
• Enables best-effort queuing for all other data (CoS 0/DSCP 0) traffic
• Modifies queue admission criteria (such as CoS-to-queue mapping)
• Modifies queue sizes and queue weights, where required

The standard (interface) configuration commands to enable AutoQoS are: auto qosvoip cisco-phone/cisco-softphone/trust.

Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model: In this model, trust of CoS markings is extended to CDP-verified IP Phones. An additional layer of protection can be offered by access edge policers. The most granular policing can be achieved by the use of per-port/per-VLAN policers. For platforms that do not yet support this feature, equivalent logic can be achieved by including subnet information within the access lists being referenced by the class maps.


Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model: For the scenario of desktop videoconferencing applications, two policers should be used; one for IP/VC and another for SoftPhone. Another factor to keep in mind is that certain Catalyst platforms allow only up to 8 policers per FastEthernet port.


WAN Aggregator/Branch Router Handoff Considerations:

Finally, Campus-to-WAN/VPN handoff considerations were examined. It was recommended:
• First, resist the urge to automatically use a GigabitEthernet connection to the WAN Aggregation router, even if the router supports GE.
• Second, if the combined WAN circuit-rate is significantly below 100 Mbps, enable egress shaping on the Catalyst switches (when supported).
• Third, if the combined WAN circuit-rate is significantly below 100 Mbps and the Catalyst switch does not support shaping, enable egress policing (when supported).