Home > Articles > Implementing Quality of Service Over Cisco MPLS VPNs

Implementing Quality of Service Over Cisco MPLS VPNs

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: May 26, 2006.

Chapter Description

This chapter covers the requirements for supporting the converged world of Multiprotocol Label Switching (MPLS) VPNs and how this maps to QoS policy applicable in the enterprise. The aim is to provide a deployable set of policies that the enterprise can use as guidelines. You'll also see how to address these policies to the service provider. Specifically, the QoS needs of Acme, Inc. are addressed in the case study.

From the Book

Selecting MPLS VPN Services

Selecting MPLS VPN Services


The LAN Edge: L2 Configurations

Framing this in the context of a sample configuration, the switch device at the edge of the network has the following policy applied:

Depending on the switch model, it may be necessary to first activate QoS using this command:

switch(config)#mls qos

This command is required on both the Catalyst 3550 and the Catalyst 6500. The Catalyst 2950 has QoS enabled by default.

The trust is configured on the switch port using this command:

switch(config-if)#mls qos trust dscp

Any ISL or 802.1Q/p frames that enter the switch port have their CoS passed (untouched) through the switch. If an untagged frame arrives at the switch port, the switch assigns a default CoS to the frame before forwarding it. By default, untagged frames are assigned a CoS of 0. This can be changed using this interface configuration command:

switch(config-if)#mls qos cos default-cos

where default-cos is a number between 0 and 7.

The syntax to configure QoS trust switch-wide for IP phone endpoints is all that is required in typical installations:

Switch(config-if)#mls qos trust device ciscoipphone

Here's the legacy syntax that was required on a per-VLAN basis:

Switch(config-if)#switchport voice vlan {vlan-id | dot1p | none | untagged}

To instruct the Cisco IP Phone to forward all voice traffic through a specified VLAN, use this command:

Switch(config-if)#switchport voice vlan vlan-id

By default, the Cisco IP Phone forwards the voice traffic with an 802.1Q priority of 5. Valid VLAN IDs are from 1 to 4096.

An alternative to specifying a particular voice VLAN on the switch is to instruct the switch port to use 802.1P priority tagging for voice traffic and to use the default native VLAN (VLAN 0) to carry all traffic. By default, if enabled, the Cisco IP Phone forwards the voice traffic with an 802.1P priority of 5.

Switch(config-if)#switchport voice vlan dot1p

In some cases, it may be desirable—indeed, highly recommended—not to trust edge CoS for nonvoice/video endpoints and not to trust any CoS value that may be present in frames sourced from an edge device. For example, an office PC used for general applications, such as web browsing, e-mail, and file and print services, may not require special QoS treatment. Allowing it to request higher levels of QoS may adversely affect applications such as voice and video, which require guarantees of bandwidth and latency.

For this reason, it is possible to use the override parameter to tell the switch to ignore any existing CoS value that may be in the frame and apply the default value. This effectively disables any trust configuration that may have previously been applied to the port.

The CoS value assigned by the switch can be changed on a port-by-port basis using this interface configuration command:

Switch(config-if)#mls qos cos override

After this command is applied, the switch rewrites the CoS value for all incoming frames to the configured default value, regardless of any existing CoS value.

Other platforms, such as those that employ CatOS, vary. You should always verify such a reference to the correct procedure by reviewing the relevant documentation at http://www.cisco.com. For example, the following is an overview of configuring prioritization, with a 6500 platform running CatOS between Cisco CallManager and IP phones and gateways using TCP ports 2000 to 2002. The sample commands classify all Skinny Protocol traffic from IP phones and gateways (VLAN 110) and Cisco CallManager (4/2) as DSCP AF31, which is backward-compatible with IPP 3.

With older implementations, several steps need to be performed (see Example 5-1):

Step 1

Enable switch-wide QoS.

Step 2

Create an ACL (ACL_IP-PHONES), marking all Skinny Client and Gateway Protocol traffic from the IP phones and from Skinny Protocol gateways with a DSCP value of AF31.

Step 3

Add to the ACL_IP-PHONE access list, trusting all DSCP markings from the IP phone so that the IP Prec = 5 RTP traffic is not rewritten.

Step 4

Create an ACL (ACL_VOIP_CONTROL), marking all Skinny Client and Gateway Protocol traffic from Cisco CallManager with a DSCP value of AF31.

Step 5

Accept incoming Layer 2 CoS classification.

Step 6

Inform the port that all QoS associated with the port will be done on a VLAN basis to simplify configuration.

Step 7

Instruct the IP phone to rewrite CoS from the PC to CoS=0 within the IP phone Ethernet ASIC.

Step 8

Inform Cisco CallManager port (4/2) that all QoS associated with the port will be done on a port basis.

Step 9

Write the ACL to hardware.

Step 10

Map the ACL_IP-PHONE ACL to the auxiliary VLAN.

Step 11

Map the ACL_VOIP_CONTROL ACL to the Cisco CallManager port.

Example 5-1 Setup of a Catalyst Edge Switch (L2 Only)

cat6k-access> (enable) set qos enable
cat6k-access> (enable) set qos acl ip ACL_IP-PHONES dscp 26 tcp any any range 2000
cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos ip any any
cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any range
 2000 2002
cat6k-access> (enable) set port qos 5/1-48 trust trust-cos
cat6k-access> (enable) set port qos 5/1-48 vlan-based
cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted
cat6k-access> (enable) set port qos 4/2 port-based
cat6k-access> (enable) commit qos acl all
cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110
cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2

Classifying Voice on the WAN Edge

A basic configuration of a WAN edge (CE) router is shown in Example 5-2 and defined further in this section. This applies the principles in base configuration terms, as discussed previously.

In this case, you apply a simple LLQ and CBWFQ policy to the router to support voice traffic. Voice traffic needs to be assigned to the LLQ, and voice-control traffic needs a minimum bandwidth guarantee.

Example 5-2 Matching Voice and Voice Control

ip cef
class-map match-all VOICE
 match ip dscp ef
class-map match-all VOICE-CONTROL
 match ip dscp cs3
 match ip dscp af31
policy-map WAN-EDGE
 class VOICE
 priority percent 33
 bandwidth percent 5
 class class-default
interface Serial0/0
 description WAN Link to CCT ID : 1234 :: SP-PE-1
 bandwidth 2048
 ip address
 service-policy output WAN-EDGE

The class map applied to VOICE and VOICE-CONTROL provides an example of matching against DSCP markings, which in this case are for the voice-bearer traffic and the voice signaling and control traffic. In this basic policy, you assume that no marking of traffic needs to happen directly on this box. Rather, it deals only with the outbound classification of the traffic.

In the policy map itself, in effect you assign three elements—those of prioritization for voice and specified as a percentage of the link bandwidth. This is an example of applying LLQ. Voice control specifies the allocation of 5 percent of link bandwidth for voice control, with the final classification being performed as class default, which uses the fair-queuing algorithm on the remaining traffic. In this case, it is assumed to be the default class.

The key to activating this policy is to attach the service-policy output to an interface—in this case, the output interface facing the SP PE. Thus, applying the classification actions as defined in the policy map WAN-EDGE to the output of the WAN serial interface provides this activation.

Classifying Video on the WAN Edge

In Example 5-3, videoconferencing traffic is assigned LLQ, and all nonvideo traffic is assigned to a default queue for WFQ.

Example 5-3 Matching Video

ip cef
class-map match-all VIDEO
 match ip dscp af41
policy-map WAN-EDGE
 priority 460
 class class-default
interface Serial0/0
 description WAN Link to CCT ID : 1234 :: SP-PE-1
 bandwidth 2048
 ip address
 service-policy output WAN-EDGE

On the WAN edge, videoconferencing traffic should be assigned to an LLQ. The video stream minimum bandwidth guarantee should be the size of the stream plus 20 percent.

As before, this policy doesn't take effect until it is bound to an interface with a service-policy statement.

Classifying Data on the WAN Edge

Most enterprises have many applications that can be considered mission-critical (trans-actional). However, if too many applications are classified as mission-critical, they will contend among themselves for bandwidth, with the result of dampening QoS effectiveness. Taken to the extreme, a regular FIFO link (no QoS) is scheduled in the exact same manner as a link where every application is provisioned as mission-critical. Therefore, it is recommended that you classify no more than three applications as mission-critical (transactional).

These applications should be marked with different AF drop-preference values to distinguish them from each other. Such distinctions provide more granular visibility in managing and monitoring application traffic and aid in provisioning for future require-ments. Similar arguments are made for having no more than three applications in a guaranteed bandwidth (bulk data) class of applications and, likewise, marking these applications with different AF drop-preference values.

Default traffic is automatically marked as best-effort (DSCP 0). However, noncritical bandwidth-intensive traffic could (optionally) be marked as different so that adverse policies could be applied to control such traffic. These types of traffic can be described as "less-than-best-effort" or "scavenger" traffic.

It is imperative that DSCP classification be performed on all packets before they arrive at the WAN edges. In this manner, queuing and congestion avoidance can be performed at the WAN edge based strictly on DSCP markings.

The Eight-Class Model introduces a dual-LLQ design: one for voice and another for interactive video. As pointed out earlier in this chapter, the LLQ has an implicit policer that allows for time-division multiplexing of the single priority queue. This implicit policer abstracts the fact that there is essentially a single LLQ within the algorithm and thus allows for the "provisioning" of multiple LLQs.

Interactive video (or IP videoconferencing, also called IP/VC) is recommended to be marked AF41 (which can be marked down to AF42 in the case of dual-rate policing at the campus access edge). It is recommended that you overprovision the LLQ by 20 percent of the IP/VC rate. This takes into account IP/UDP/RTP headers as well as Layer 2 overhead. Additionally, Cisco IOS Software automatically includes a 200-ms burst parameter (defined in bytes) as part of the priority command. On dual-T1 links, this has proven sufficient for protecting a single 384-kbps IP/VC stream. On higher-speed links (such as triple T1s), the default burst parameter has shown to be insufficient for protecting multiple IP/VC streams.

However, multiple-stream IP/VC quality tested well with the burst set to 30,000 bytes (for example, priority 920 30000). Our testing did not arrive at a clean formula for predicting the required size of the burst parameters as IP/VC streams continually were added. However, given the variable packet sizes and rates of these interactive-video streams, this is not surprising. The main point is that the default LLQ burst parameter might require tuning as multiple IP/VC streams are added (which likely will be a trial-and-error process).

Optionally, DSCP-based WRED can be enabled on the Interactive-Video class, but testing has shown negligible performance difference in doing so (because, as has been noted, WRED is more effective on TCP-based flows than UDP-based flows, such as interactive video). In these designs, WRED is not enabled on classes such as Call-Signaling, IP Routing, and Network-Management because WRED would take effect only if such classes were filling their queues nearly to their limits. Such conditions would indicate a provision-ing problem that would be better addressed by increasing the class's minimum bandwidth allocation than by enabling WRED.

Additionally, the Eight-Class Model subdivides the preferential data class to separate control plane traffic (IP routing and network-management applications) from business-critical data traffic. IGP packets (such as RIP, EIGRP, OSPF, and IS-IS) are protected through the PAK_priority mechanism within the router. However, EGP protocols, such as BGP, do not get PAK_priority treatment and might need explicit bandwidth guarantees to ensure that peering sessions do not reset during periods of congestion. Additionally, administrators might want to protect network-management access to devices during periods of congestion.

The other class added to this model is for bulk traffic (the Bulk Data class), which is spun off of the Critical Data class. Because TCP continually increases its window sizes, which is especially noticeable in long sessions (such as large file transfers), constraining bulk data to its own class alleviates other data classes from being dominated by such large file transfers. Bulk data is identified by DSCP AF11 (or AF12 in the case of dual-rate policing at the campus access edges). DSCP-based WRED can be enabled on the Bulk Data class (and also on the Critical Data class). Example 5-4 shows the implementation of the Eight-Class Model for the WAN edge.

Example 5-4 Eight-Class Model

class-map match-all Voice
 match ip dscp ef ! IP Phones mark Voice to EF
class-map match-all Interactive Video
 match ip dscp af41 af42 ! Recommended markings for IP/VC
class-map match-any Call Signaling
 match ip dscp cs3 ! Future Call-Signaling marking
 match ip dscp af31 ! Current Call-Signaling marking
class-map match-any Network Control
 match ip dscp cs6 ! Routers mark Routing traffic to CS6
 match ip dscp cs2 ! Recommended marking for Network Management
class-map match-all Critical Data
 match ip dscp af21 af22 ! Recommended markings for Transactional-Data
class-map match-all Bulk Data
 match ip dscp af11 af12 ! Recommended markings for Bulk-Data
class-map match-all Scavenger
 match ip dscp cs1 ! Scavenger marking
policy-map WAN-EDGE
 class Voice
 priority percent 18 ! Voice gets 552 kbps of LLQ
 class Interactive Video
 priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ
 class Call Signaling
 bandwidth percent 5 ! BW guarantee for Call-Signaling
 class Network Control
 bandwidth percent 5 ! Routing and Network Management get min 5% Bandwidth
 class Critical Data
 bandwidth percent 27 ! Critical Data gets min 27% BW
 random-detect dscp-based ! Enables DSCP-WRED for Critical-Data class
 class Bulk Data
 bandwidth percent 4 ! Bulk Data gets min 4% BW guarantee
 random-detect dscp-based ! Enables DSCP-WRED for Bulk-Data class
 class Scavenger
 bandwidth percent 1 ! Scavenger class is throttled to 1% of bandwidth
 class class-default
 bandwidth percent 25 ! Fair-queuing is sacrificed for Bandwidth guarantee
 random-detect ! Enables WRED on class-default

This design is more efficient than strict policing, because these bandwidth-intensive noncritical applications can use additional bandwidth if it is available while ensuring protection for critical transactional data classes and real-time voice and video applications.

The development of this model is attributed to Tim Szigeti from the Cisco Enterprise Solutions Engineering Group.

For more information on this approach, go to


8. Case Study: QoS in the Acme, Inc. Network | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020