cisco avvid network infrastructure enterprise … avvid network...contents vi cisco avvid network...

Cisco AVVID Network Infrastructure Enterprise Quality of Service DesignSolutions Reference Network Design

August, 2002

Corporate HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706 USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 526-4100

Customer Order Number: 956467

http://www.cisco.com

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

CCIP, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That’s Possible, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site 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. (0203R)

Cisco AVVID Network Infrastructure Enterprise Quality of Service DesignCopyright © 2002, Cisco Systems, Inc.All rights reserved.

Cisco AVVID Netwo956467

C O N T E N T S

About this Document xi

Intended Audience xi

Document Organization xi

Document Conventions xii

Obtaining Documentation xiii

World Wide Web xiii

Documentation CD-ROM xiii

Ordering Documentation xiii

Documentation Feedback xiii

Obtaining Technical Assistance xiv

Cisco.com xiv

Technical Assistance Center xiv

Cisco TAC Web Site xv

Cisco TAC Escalation Center xv

C H A P T E R 1 Overview 1-1

Why is Quality of Service Required for AVVID? 1-1

Understanding QoS 1-1

Loss 1-2

Delay 1-3

Delay Variation 1-3

Quality of Service Requirements for Voice 1-3

Voice Traffic 1-4

Voice Control Traffic 1-5

Quality of Service Requirements for Video 1-6

Streaming Video 1-6

Video conferencing 1-7

Quality of Service Requirements for Data 1-7

Relative Priority vs. Over-Engineering Bandwidth Provisioning 1-8

Determining the Classes of Data Traffic 1-9

Provisioning for Important Data Traffic 1-9

Reactive vs. Proactive Policies 1-10

Non-Technical QoS Considerations of Data 1-10

Service-Provider QoS Requirements 1-11

iiirk Infrastructure Enterprise Quality of Service Design

Contents

What is the Quality of Service Toolset? 1-12

Classification Tools 1-12

Class of Service 1-13

Type of Service and Differentiated Services Code Points 1-13

Per-Hop Behaviors 1-14

Network-Based Application Recognition 1-14

Classification Equivalents 1-14

Classification Recommendations 1-15

Voice Bearer Traffic 1-16

Voice Control Traffic 1-16

Video Conferencing 1-16

Streaming Video 1-16

Mission-Critical Data 1-17

Less-Than-Best-Effort Data 1-17

Best-Effort Data 1-17

Scheduling Tools 1-17

Class-Based Weighted-Fair Queueing 1-18

Low-Latency Queueing 1-19

Weighted-Random Early Detect 1-20

Scheduling Recommendations 1-22

Queue Scheduling 1-22

Number of Queues 1-22

Provisioning Tools 1-22

Policing and Shaping Tools 1-23

Link-Efficiency Mechanisms 1-23

Call Admission Control 1-26

Management Tools 1-26

C H A P T E R 2 QoS Considerations When Connecting End-Points to an AVVID Network 2-1

Overview 2-1

The Trusted Edge 2-2

IP Telephony 2-2

IP Phones 2-2

CallManager 2-2

VoIP Gateways 2-3

H.323 2-3

MGCP 2-3

Classification for Non-marking Applications 2-3

ivCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents

Video 2-3

Video Conferencing 2-4

Streaming Video 2-4

Mission-Critical Applications 2-4

DLSW+ 2-4

Less-than-Best-Effort 2-5

Summary 2-5

C H A P T E R 3 QoS in an AVVID-Enabled Campus Network 3-1

Overview 3-1

Delay Variation 3-2

Transmit Buffer Congestion 3-2

QoS Toolset 3-4

Classification 3-4

Scheduling 3-5

Server Farm Switch Selection 3-6

Voice Bearer Traffic 3-7

Voice over IP Call Control 3-10

Skinny Protocol 3-10

H.323 Protocol 3-11

MGCP 3-11

Verifying the ACLs 3-12

Mission-Critical Data 3-12

Selecting an Access-Layer Switch 3-14

Catalyst 6500 as an Access-Layer Switch 3-15

Enabling QoS 3-17

Configuring IP Phone Port Queuing 3-17

Configuring the Uplink to the Distribution Switch 3-18

Verifying the Configuration 3-19


Catalyst 4000 with Supervisor III 3-22

Catalyst 4000 with Supervisor II 3-29

Catalyst 3524-PWR XL as an Access-Layer Switch 3-31

Configuring IP Phone Port Queuing 3-32

Configuring the Uplink Interface to the Distribution Switch 3-33


Enabling QoS 3-34

Modifying the CoS-to-DSCP Mappings 3-34

Enabling Priority Queuing 3-35

vCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents

Configuring ACLs 3-35

Configuring Access-Layer Phone Support 3-36




Modifying the CoS-to-DSCP Mappings 3-39


Configuring Access-Layer Phone Support 3-40



Selecting a Distribution-Layer Switch 3-42

Catalyst 6500 (with Catalyst OS) as a Distribution-Layer Switch 3-42

Configuring the Distribution Layer VoIP Control Traffic Transmit Queue 3-43

Configuring the Distribution Layer with a Layer 3 Switch 3-43



Catalyst 6500 (with Native IOS) as a Distribution-Layer Switch 3-47

Enabling QoS 3-47

Configuring the Distribution Layer VoIP Control Traffic Transmit Queue 3-48




Catalyst 4000 with Supervisor III as a Distribution-Layer Switch 3-51

Enabling QoS 3-52

Modifying the CoS-to-DSCP Mapping 3-52

Configuring Priority Queuing 3-53


Configuring Service Policy 3-54

Configuring CoS or DSCP Trust 3-54


Catalyst 3550 as a Distribution-Layer Switch 3-58

Enabling QoS 3-58

Modifying the CoS-to-DSCP Mapping 3-59

Enabling Priority Queuing 3-59


Configuring CoS or DSCP Trust 3-60


Summary 3-63

viCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents

C H A P T E R 4 QoS in an AVVID-Enabled Wide-Area Network 4-1

Overview 4-1

QoS Toolset 4-2

Classification 4-2

Provisioning 4-2

Policers and Shapers 4-2

Link-Fragmentation and Interleaving 4-3

TX Ring 4-3

Modular QoS Command-Line Interface 4-4

QoS Recommendations for WAN Aggregation Routers 4-4

Classifying and Provisioning for Voice on the WAN Edge 4-4

Classifying and Provisioning for Video on the WAN Edge 4-6

Classifying and Provisioning for Data on the WAN Edge 4-6

Link-Specific WAN QoS Recommendations 4-9

High-Speed Point-to-Point Links 4-9

Slow-Speed Point-to-Point Links 4-10

High-Speed Frame Relay Links 4-11

Distributed-Platform High-Speed Frame Relay Links 4-14

Slow-Speed Frame Relay Links 4-15

Distributed-Platform Slow-Speed Frame Relay Links 4-17

High-Speed ATM Links 4-18

Slow-Speed ATM Links 4-19

ATM-to-Frame Relay Recommendations 4-21

ISDN Recommendations 4-24

Summary Configurations 4-26

QoS Recommendations for Remote Branch Routers 4-28

WAN Edges 4-28

Remote LAN Edge for Voice 4-28

Remote LAN Edge for Video 4-29

Remote LAN Edge for Data 4-30

Output Policies 4-30

Input Policies 4-30

Summary Configuration 4-32

Verifying QoS 4-34

show policy 4-34

show policy interface 4-36

Example 1 4-36

Example 2 4-40

show interface 4-42

viiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents

show queue 4-43

show frame-relay pvc 4-43

show atm bundle 4-47

show policy interface atm 4-47

show atm vc 4-47

show atm pvc 4-48

C H A P T E R 5 QoS in a SOHO Virtual Private Network for IP Telephony 5-1

Overview 5-1

QoS Toolset 5-2

Classification 5-2

Classification of Voice Bearer traffic 5-2

Classification of Voice Signaling Traffic 5-3

Scheduling 5-3

Provisioning 5-3

TX Ring Sizing 5-3

Link Fragmentation and Interleave 5-3

Fragment Sizing for MLPPP over ATM 5-3

Traffic Shaping 5-4

Bandwidth Calculation 5-5

Solutions 5-6

Application of QoS to DSL in a SOHO Environment 5-6

One and Two Box DSL Solution 5-7

Third-Party Modem Solution 5-9

Application of QoS to Cable in a SOHO Environment 5-10

One and Two Box Cable Solution 5-11

Third-Party Modem Solution 5-13

Application of QoS over Other Technologies 5-14

Last Mile Wireless, IDSL, etc. 5-14

Voice over ISDN 5-15

Summary 5-16

C H A P T E R 6 QoS with MPLS in an AVVID-Enabled Network 6-1

Overview 6-1

MPLS VPN Architecture 6-2

MPLS Modes of Operation 6-2

MPLS Labels 6-3

MPLS Label Stack 6-3

Placement of Labels by Mode 6-4

viiiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents

MPLS VPN QoS 6-5

Considerations for MPLS VPN QoS 6-5

Convergence 6-5

After a Link Failure 6-5

After a Link Recovery 6-6

Redundancy 6-6

Using IP Multicast over MPLS VPNs 6-7

Implementing MPLS VPN QoS 6-8

CE Routers 6-8

PE Routers 6-10

P Routers 6-13

A P P E N D I X A Reference Information A-1

DSCP Equivalents A-1

Catalyst 6500 Linecards and Queuing Mechanisms A-2

Mission-Critical Applications Well-Known Ports A-3

DLSW+ Considerations A-4

When to Enable cRTP A-5

Web Sites with Additional Information A-6

Cisco Public Documentation A-6

Cisco Limited-Access Information A-7

Cisco Internal Documentation A-7

RFCs from the IETF A-8

Other External Sites A-8

ixCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Contents

xCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

About this Document

This document is designed to present an overview of the use of Quality of Service (QoS) in a variety of Cisco AVVID environments.

Intended AudienceThis document is intended for customers and Enterprise Systems Engineers (SEs) who has recently become involved with the QoS aspects of a Cisco AVVID network and who may be unfamiliar with the deployment choices available to an Enterprise customer.

It provides in-depth design and configuration recommendations for the implementation of QoS to successfully meet the loss, delay, and delay variation (jitter) requirements of voice over IP, video over IP, and mission-critical data in a variety of environments.

Document OrganizationThis document contains the following chapters:

Chapter or Appendix Description

Chapter 1, “Overview” Provides an overview of QoS, the need for QoS in an AVVID network, and the QoS toolset.

Chapter 2, “QoS Considerations When Connecting End-Points to an AVVID Network”

Provides information about implementing QoS at the network edge.

Chapter 3, “QoS in an AVVID-Enabled Campus Network”

Discusses the need for QoS in a campus environment and provides guidelines and examples for implementation.

Chapter 4, “QoS in an AVVID-Enabled Wide-Area Network”

Discusses the need for QoS in a wide-area network (WAN) and provides guidelines and examples for implementation.

Chapter 5, “QoS in a SOHO Virtual Private Network for IP Telephony”

Discusses the need for QoS in a small office, home office (SOHO) environment and provides guidelines and examples for implementation.

xiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

About this DocumentDocument Conventions

Note The chapters of this document contain references to other documents. These references are included as tips in the text. The URL for each referenced document is located in Appendix A “Reference Information.” In some cases, an internal document is referenced. For copies of internal documents, please see your Cisco Systems representative.

Document ConventionsThis guide uses the following conventions to convey instructions and information:

Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the manual.

Timesaver Means the described action saves time. You can save time by performing the action described in the paragraph.

Tips Means the following information will help you solve a problem. The tips information might not be troubleshooting or even an action, but could be useful information, similar to a Timesaver.

Chapter 6, “QoS with MPLS in an AVVID-Enabled Network”

Discusses the nuances of implementing QoS with MPLS in an AVVID network.

Appendix A, “Reference Information”

Provides reference information, such as equivalence tables and URLs for referenced documents.

Chapter or Appendix Description

Table 1 Document Conventions

Convention Description

boldface font Commands and keywords.

italic font Variables for which you supply values.

[ ] Keywords or arguments that appear within square brackets are optional.

{x | y | z} A choice of required keywords appears in braces separated by vertical bars. You must select one.

screen font Examples of information displayed on the screen.

boldface screen font

Examples of information you must enter.

< > Nonprinting characters, for example passwords, appear in angle brackets.

[ ] Default responses to system prompts appear in square brackets.

xiiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

About this DocumentObtaining Documentation

Caution Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.

Obtaining DocumentationThe following sections explain how to obtain documentation from Cisco Systems.

World Wide WebYou can access the most current Cisco documentation on the World Wide Web at the following URL:


Translated documentation is available at the following URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation CD-ROMCisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.

Ordering DocumentationCisco documentation is available in the following ways:

• Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/cgi-bin/order/order_root.pl

• Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:

http://www.cisco.com/go/subscription

• Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation FeedbackIf you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click the Fax or Email option under the “Leave Feedback” at the bottom of the Cisco Documentation home page.

You can e-mail your comments to [email protected].

xiiiCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467


http://www.cisco.com/public/countries_languages.shtml

http://www.cisco.com/cgi-bin/order/order_root.pl

http://www.cisco.com/go/subscription

About this DocumentObtaining Technical Assistance

To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:

Cisco SystemsAttn: Document Resource Connection170 West Tasman DriveSan Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical AssistanceCisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.

Cisco.comCisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.

Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to

• Streamline business processes and improve productivity

• Resolve technical issues with online support

• Download and test software packages

• Order Cisco learning materials and merchandise

• Register for online skill assessment, training, and certification programs

You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:


Technical Assistance CenterThe Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.

Inquiries to Cisco TAC are categorized according to the urgency of the issue:

• Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.

• Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

xivCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467



• Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.

• Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.

Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.

Cisco TAC Web Site

The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:

http://www.cisco.com/tac

All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:

http://www.cisco.com/register/

If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:

http://www.cisco.com/tac/caseopen

If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.

xvCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

http://www.cisco.com/tac

http://www.cisco.com/register/

http://www.cisco.com/tac/caseopen

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml


xviCisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Cisco AVVID Network Infrastructure956467

C H A P T E R 1
Overview
This chapter provides an overview of Quality of Service (QoS) and its uses. This chapter provides high-level answers to the following questions:

• Why is Quality of Service Required for AVVID?

• What is the Quality of Service Toolset?

Note This chapter contains references to other documents. These references are included as tips in the text. The URL for each referenced document is located in Appendix A, “Reference Information.” In some cases, an internal document is referenced. For copies of internal documents, please see your Cisco Systems representative.

Why is Quality of Service Required for AVVID?The key enabling technology for network convergence in the Architecture for Voice, Video, and Integrated Data (AVVID) is QoS. This is because voice, video, and mission-critical data have stringent service requirements from the network infrastructure. These requirements supersede the requirements of generic data traffic. If voice, interactive-video, and mission-critical data are not given priority service from network devices, then the quality of these important applications would quickly degrade to the point of being unusable.

Understanding QoSQoS is defined as the measure of performance for a transmission system that reflects its transmission quality and service availability. Service availability is a crucial foundation element of QoS. Before any QoS can be implemented successfully, the network infrastructure must be designed to be highly available. The transmission quality is determined by the following factors:

• Loss

• Delay

• Delay Variation

There are many points in AVVID networks where QoS mechanisms are required to manage loss, delay, and delay variation. Figure 1-1 illustrates areas where QoS mechanisms are required to control the impact of loss, delay, and delay variation on voice performance.

1-1 Enterprise Quality of Service Design

Chapter 1 OverviewWhy is Quality of Service Required for AVVID?

Figure 1-1 Areas Where QoS is Needed

Loss

Loss (or packet loss) is a comparative measure of packets faithfully transmitted and received to the total number that were transmitted. Loss is expressed as the percentage of packets that were dropped.

8109

9

M

WAN

Central campus Remote branch

Si

SiIP

IP

QoS - Campus Access QoS - Campus Dist. QoS - WAN QoS - Branch

Establish Trust Boundary

Layer 2 (802.1p) to Layer 3(DSCP) classification

Layer 3 (DSCP) to Layer 2(802.1p) classification

Layer 2 or Layer 3classification whererequired-service policies

CoS/DSCP to queue entrycriteria

Multiple queues and queuescheduling (priority or high)

Establish Trust Boundary-Trust DSCP or CoS fromAccess Layer






Map L3 DSCP to L2 CoSvia sevice policy out and802.1q trunk






Low-latency queuing

Data traffic queue provisioning

Link Fragmentation and interleave

Traffic shaping

Admission control

1-2Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467


Delay

Delay (or latency) is the amount of time it takes a packet to reach the receiving endpoint after being transmitted from the sending endpoint. This time period is termed the “end-to-end delay” and can be broken into two areas: fixed network delay and variable network delay. Fixed network delay includes encoding/decoding time (for voice and video), as well as the finite amount of time required for the electrical/optical pulses to traverse the media en route to their destination. Variable network delay generally refers to network conditions, such as congestion, that may affect the overall time required for transit.

In data networks carrying voice, there are three types of delay:

• Packetization delay, which is the amount of time that it takes to sample and encode the analog voice signals and turn them in to packets.

• Serialization delay, which is the amount of time that it takes to place the bits of the data packets onto the physical media.

• Propagation delay, which is the amount of time it takes to transmit the bits of a packet across the physical wire.

Delay Variation

Delay variation (or jitter) is the difference in the end-to-end delay between packets. For example, if one packet required 100 ms to traverse the network from the source-endpoint to the destination-endpoint and the following packet required 125 ms to make the same trip, then the delay variation is calculated as 25 ms.

Each end station in a VoIP or Video over IP conversation has a jitter buffer. Jitter buffers are used to smooth out changes in arrival times of data packets containing voice. A jitter buffer is dynamic and can adjust for up to a 30 ms average change in arrival times of packets. If you have instantaneous changes in arrival times of packets that are outside of the capabilities of a jitter buffer’s ability to compensate you will have jitter buffer over-runs and under-runs.

• A jitter buffer under-run occurs when arrival times of packets increases to the point where the jitter buffer has been exhausted and contains no packets to be processed by the DSPs when it is time to play out the next piece of voice or video.

• A jitter buffer over-run occurs when packets containing voice or video arrive faster than the jitter buffer can dynamically resize itself to accommodate. When this happens packets are dropped and when it is time to play out the voice or video samples contained in the dropped packets quality is degraded.

Quality of Service Requirements for VoiceWhen addressing the QoS needs of voice traffic, keep the following in mind:

• Loss should be no more than 1%.

• One-way latency should be no more than 150-200 ms.

• Average jitter should be no more than 30 ms.

• 21-106 kbps of guaranteed priority bandwidth is required per call (depending on the sampling rate, codec and Layer 2 overhead).

• 150 bps (+ Layer 2 overhead) per phone of guaranteed bandwidth is required for Voice Control traffic.


956467


Voice quality is directly affected by all three QoS quality factors: loss, delay, and delay variation.

Loss causes voice clipping and skips. The industry standard codec algorithms used in Cisco Digital Signal Processor (DSP) can correct for up to 30 ms of lost voice. Cisco VoIP technology uses 20 ms samples of voice payload per VoIP packet. Therefore, for the codec correction algorithms to be effective, only a single Real Time Transport (RTP) packet can be lost during any given time. If two successive voice packets are lost, the 30ms correctable window is exceeded and voice quality begins to degrade.

Delay can cause voice quality degradation if it is above 200 ms. If the end-to-end voice delay becomes too long (for example, 250 ms), the conversation begins to sound like two parties talking on over a satellite link or even a CB radio. The ITU standard for VoIP (G.114) states that a 150 ms one-way delay budget is acceptable for high voice quality. The Cisco Technical Marketing Team has shown that there is a negligible difference in voice quality scores using networks built with 200 ms delay budgets.

With respect to delay variation, there are adaptive jitter buffers within Cisco IP Telephony devices. However, these can usually only compensate for 20 to 50 ms of jitter.

Implementing QoS is a means to use bandwidth efficiently, but not a blanket substitute for bandwidth itself. When an enterprise is faced with ever increasing congestion, a certain point is reached where QoS alone will not solve bandwidth requirements. At such a point, nothing short of additional bandwidth will suffice. The following sections provide guidelines that can help you determine when this point is reached.

Voice Traffic

The bandwidth consumed by VoIP streams is calculated by adding the packet payload and all headers (in bits), then multiplying by the packet rate per second (default of 50 packets per second). Table 1-1 details the bandwidth per VoIP flow at a default packet rate of 50 packets per second (pps) and at 33 pps. This does not include Layer 2 overhead and does not take into account any possible compression schemes, such as compressed Real-time Transport Protocol (cRTP). The Service Parameters menu in Cisco CallManager Administration can be used to adjust the packet rate.

Note Although it is possible to configure the sampling rate above 30 ms, this usually results in very poor voice quality.

Table 1-1 Voice Bandwidth (without Layer 2 overhead)

Bandwidth Consumption Sampling Rate Voice Payload in Bytes

Packets per Second

Bandwidth per Conversation

G.711 20 ms 160 50 80 kbps

G.711 30 ms 240 33 74 kbps

G.729A 20 ms 20 50 24 kbps

G.729A 30 ms 30 33 19 kbps


956467


A more accurate method for provisioning VoIP is to include the Layer 2 overhead, which includes: preambles, headers, flags, CRCs, and ATM cell-padding. The amount of overhead depends on the technology used:

• 802.1Q Ethernet adds 32 bytes of Layer 2 overhead.

• Point-to-point protocol (PPP) adds 12 bytes of Layer 2 overhead.

• Multilink PPP (MLP) adds 13 bytes of Layer 2 overhead.

• Frame Relay adds 8 bytes of Layer 2 overhead.

• ATM adds varying amounts of overhead. depending on the cell-padding requirements.

When Layer 2 overhead is included in the bandwidth calculations, the VoIP call requirements translate to the figures shown in Table 1-2.

Table 1-2 Voice Bandwidth (with Layer 2 overhead)

Bandwidth requirements for voice traffic range from 21 kbps to 106 kbps, depending on the CODEC, the sampling rate, and the Layer 2 media used.

Figure 1-2 shows the bandwidth requirements of a G.711 voice call (64 kbps) over Frame-Relay media.

Figure 1-2 G.711 Pulse-Code Modulation (PCM) Voice-Call Over Frame-Relay

Voice Control Traffic

In centralized call processing designs, the IP phones use a TCP control connection to communicate with the Cisco CallManager. If there is not enough bandwidth provisioned for these lightweight control connections, the user might be adversely affected. For example, let’s look at the Delay to Dial-Tone (DTT) time periods. When an IP phone goes off-hook, it “asks” the CallManager what to do. The CallManager instructs the IP phone to play a Dial-Tone. If control traffic is dropped or delayed within the network, the user will not get the Dial-Tone played out. This same logic applies to all signaling traffic for gateways and phones.

For Cisco IP phones, the control traffic required is approximately 150 bps per phone (not including layer 2 overhead).

Bandwidth Consumption

802.1Q Ethernet PPP MLP Frame-Relay ATM

G.711 at 50 pps 93 kbps 84 kbps 86 kbps 84 kbps 106 kbps

G.711 at 33 pps 83 kbps 77 kbps 78 kbps 77 kbps 84 kbps

G.729A at 50 pps 37 kbps 28 kbps 30 kbps 28 kbps 43 kbps

G.729A at 33 pps 27 kbps 21 kbps 22 kbps 21 kbps 28 kbps

Single PCM VoIP Call

84Kbps64Kbps

7463

5


956467


Tip Detailed calculations of call control traffic can be found in the “Network Infrastructure Requirements” chapter of the IP Telephony Solution Reference Network Design Guide.

Quality of Service Requirements for VideoWhen addressing the QoS needs of streaming video traffic, keep the following in mind:


• Latency should be no more than 4-5 seconds (depending on video application's buffering capabilities).

• There are no significant jitter requirements.

• Bandwidth requirements depends on the encoding and rate of video stream.

• Non-entertainment streaming video should be provisioned into the “Silver” data-traffic class. (The silver data class is discussed in “Provisioning for Important Data Traffic” section on page 1-9.)

For video content distribution, keep the following in mind:

• Streaming video content is delay and delay variation insensitive.

• Streaming video requires large file transfers (traffic patterns similar to FTP sessions).

• Try to restrict to distribution to less-busy times of day.

• Provision as “less-than-best-effort” data. (The less-than-best-effort data class is discussed in “Provisioning for Important Data Traffic” section on page 1-9.)

When addressing the QoS needs of video conferencing traffic, keep the following in mind:


• One-way latency should be no more than 150-200 ms.

• Average jitter should be no more than 30 ms.

• The minimum bandwidth guarantee is the size of the video conferencing session + 20% (meaning that a 384 kbps video conferencing session requires 460 kbps guaranteed priority bandwidth).

There are two main types of video applications: streaming video (such as IP/TV, which may be either on-demand or multicast) and interactive video (such as video conferencing).

Streaming Video

Streaming video applications have more lenient QoS requirements, as they are delay insensitive (the video can take several seconds to 'cue-up'), and are largely delay variation insensitive (due to application buffering). Streaming video may contain valuable content, as in the case of an E-learning application, and therefore may require service guarantees via QoS. Streaming video would be appropriately provisioned in the “Silver” class of data traffic.

When you are provisioning for streaming video, you should also take into account the video content distribution requirements. Video file distribution is very similar to FTP traffic in nature and can have a major impact on network performance (due to the file size). Distribution traffic should be managed to avoid impacting the network. For example, video content transfers could be limited to off-peak hours or treated as “less-than-best-effort” traffic.


956467


Video conferencing

Video conferencing has the same loss, delay, and delay variation requirements as voice, but the traffic patterns of video conferencing are radically different from voice. For example, video conferencing traffic has varying packet sizes and extremely variable packet rates (as shown in Figure 1-3.)

Figure 1-3 Video conferencing Bandwidth Requirements for a 384 kbps Session

Because of its bursty nature, video conferencing has two unique requirements in provisioning for strict-priority bandwidth:

• The LLQ must be provisioned to the stream-rate plus 20%.

• The LLQ burst parameter must be provisioned to 30000 bytes per 384 kbps stream.

Quality of Service Requirements for DataWhen addressing the QoS needs of data application traffic, keep the following in mind:

• Profile applications to get a basic understanding of their network requirements and traffic patterns.

• Don't over-engineer the provisioning. Instead, use the proven relative priority model (as explained in the following section).

• Use no more than four traffic classes, such as:

– Gold (Mission-Critical)—Enterprise Resource Planning (ERP), transactional, in-house software

– Silver (Guaranteed-Bandwidth)—Streaming video, messaging, intranet

– Bronze (Best-Effort and Default class)—Internet browsing, E-Mail

– Less-than-Best-Effort (Optional; higher-drop preferences)—FTP, backups, Peer-to-Peer (P2P) applications (Napster, KaZaa)

• Do not assign more than 3 applications to each class of protected data traffic.

• Use proactive provisioning polices before reactive policing policies.

• Obtain executive endorsement of relative ranking of application priority (from a QoS perspective) prior to committing to the actual policy implementation, to avoid potential derailing of the project.

"P" and "B" FramesDifferential/Predicted Frames

128-256 Bytes

"I" Frame(Full-Sample Video)

1024-1518 Bytes

"I" Frame(Full-Sample Video)

1024-1518 Bytes

35Kbps

15pps

30pps

600Kbps

7463

8


956467


Relative Priority vs. Over-Engineering Bandwidth Provisioning

Because bandwidth requirements vary greatly from application to application (and even between versions of the same applications) it is not possible to provide a blanket rule for provisioning data bandwidth. Traffic analysis and lab-testing are required to ascertain bandwidth requirements for data applications.

Figure 1-4 shows a comparison of traffic patterns between two popular mission-critical ERP applications, Oracle and SAP.

Figure 1-4 Oracle versus SAP R/3 Packet Distribution

In addition to the wide variation of traffic patterns and requirements between different data applications, traffic patterns often vary greatly between two versions of the same application. Figure 1-5 illustrates a situation where the same transaction in one version of SAP requires 35 times more bytes than an earlier version.

Figure 1-5 SAP Version Traffic Comparison for Identical Transactions

The following is an example of basic bandwidth provisioning for data.

An enterprise has as SAP R/3 as its mission-critical application. The task most typically performed by users in the remote offices is the Create Sales Order transaction (VA01). This transaction entails 14 KB of data, which translates to 112 kbps of required bandwidth to ensure a response time of less than 1 second. If SAP is provisioned as a mission-critical application receiving 25% of the link's capacity, then a link size of approximately 512 kbps is required to provide this service-level.

Oracle SAP

7463

9

0-64 Bytes 1024-1518 Bytes

512-1023 Bytes

253-511 Bytes

65-127 Bytes

128-252 Bytes

253-511 Bytes

512-1023 Bytes

1024-1518 Bytes

128-252 Bytes

65-127 Bytes

0-64 Bytes

7464

0

SAP GUI,Release

3.0F

500,000

400,000

300,000

200,000

100,000

0SAP GUI,Release

4.6C,with Cache

Bytes per Sales Order Entry (VA01)Transaction

SAP GUI,Release

4.6C,no Cache

SAP GUI(HTML),Release

4.6C


956467


However, if the enterprise chooses to run a newer version of SAP (4.6c) in an uncompressed HTML format, the VA01 transaction would then require 490 KB per transaction. If link and bandwidth-provisioning remained unchanged, then the new end-user response time would be approximately 32 seconds per transaction. If there is no other traffic traversing the 512 kbps link, the transaction would require approximately 8 seconds. Clearly this is a case where QoS alone is insufficient to accommodate required service-levels given the nature of the data traffic.

Continuing the example, let’s assume that the average employee in this enterprise receives 10 MB of e-mail per day (including all attachments). While E-Mail is a highly asynchronous application and is recommended to be classified as best-effort traffic, it nonetheless requires bandwidth. The daily average mail spool divided over an 8 hour workday equates to average of 2.8 kbps of e-mail traffic per employee. If the remote branch has 50 employees, this requirement becomes 140 kbps as a daily average. But, e-mail traffic generally displays a cyclical burst according to time of day (with highest traffic levels between 8-10:30 am). If the assumption is made that e-mail traffic during these periods is double the daily average, then more than 280 kbps of bandwidth could be consumed by e-mail during these hours.

These are the type of calculations that should be taken into account not only when provisioning QoS policies, but also in determining when to increase link bandwidth.

Absolute application provisioning requires a myriad of assumptions that are unlikely to all hold true on a daily basis. Application updates, fluctuation in the numbers of users, varying business environments, as well as the time of day, month, and year, all affect bandwidth requirements of data applications. Therefore, rather than attempting to determine exact kilobits of bandwidth requirements for data applications, a simpler and proven approach is to assign relative priorities to data applications.

Determining the Classes of Data Traffic

It is counterproductive to use too many discrete classes for data traffic. This is because the more classes that are defined, the less the distinction between service-levels. To illustrate, the available bandwidth could be likened to a pie. If the pie is sliced into 64 gradually smaller pieces and then served to respectively important guests (with the largest slice being served to the most important guest), it would be quite difficult to ascertain who's getting the better slivers. Likewise, having too many classes will reduce the overall effectiveness of QoS. Therefore, it is recommended that you define only four classes of data traffic at the most.

Additionally, if too many applications are assigned to the highest classes, then the overall effectiveness of QoS provisioning is dampened. Taken to an extreme, if all applications are assigned 'gold' service levels, then the end result is the same as when no QoS is provisioned at all (first-in-first-out scheduling). For this reason, applications provisioned with QoS should be limited to only a select few (maximum 3 applications per class).

Provisioning for Important Data Traffic

The relative-priority model suits data applications, as these can easily be categorized into three broad classes of traffic: important, best-effort and less-than-best-effort. Important traffic can additionally be sub-divided into multiple categories, as required.

Usually mission-critical traffic is assigned to the highest class of data applications, gold. Mission-critical applications are those that directly contribute to the core operations of an enterprise. These applications are highly-interactive and are therefore sensitive to loss and delay. Examples of mission-critical applications include ERP applications, such as SAP, Oracle, and PeopleSoft, as well as proprietary applications that were designed in-house.


956467


Some applications are better suited to a silver class of data traffic. Such applications are generally viewed as secondary in importance to business operations or are highly asynchronous in nature. These applications include Netmeeting and messaging applications, calendaring, groupware, and intranet browsing.

Best-effort is the default category for data applications. These applications play an indirect role in normal enterprise operations. While some of these applications might be interactive, no bandwidth guarantees are required. Perhaps the best examples of these types of application are E-mail and generic Internet browsing.

Less-than-best-effort is a category for applications that are bandwidth intensive and that may not have anything to do with the enterprises' business. These applications are typically highly delay and drop insensitive, and often the executions of such applications span over hours. Therefore, these applications can be given a higher-drop preference to prevent them from robbing bandwidth away from best-effort applications. Examples of less-than-best-effort of traffic include large file transfers, backup operations, and peer-to-peer entertainment-media swapping applications (like Napster, KaZaa, Gnutella).

Reactive vs. Proactive Policies

Sometimes administrators chase after the less-than-best-effort traffic and implement limiting policies on these in hopes of indirectly improving available bandwidth to other applications. With this reactive approach, bandwidth is monopolized by unimportant applications until users of important applications complain enough to warrant investigation into the cause by the IT or networking departments. After time, the investigations reveal the culprit application, which is subsequently policed. Performance of the important applications will likely improve, but only until another lesser-important, bandwidth-intensive application emerges. In this approach, the bandwidth-limiting policies will become increasingly complex to administer and will require more CPU overhead to enforce as their complexity grows.

A proactive approach is to properly provision (minimum) bandwidth guarantees for important data applications (in their respective orders) and provision a best-effort default class. After these protective policies are in place, optional policing policies can be overlaid for less-than-best-effort traffic. However, the implementation of policing policies creates a static limit that may not always be desirable. For example, data backups, which usually occur overnight, often make use of the additional bandwidth that is available during non-peak hours. With policing policies, the unused bandwidth would not be available, which could cause the backup process to carry over into morning work hours. Therefore, increasing the drop preference of less-than-best- effort traffic (instead of using strict policing policies) is a more efficient use of available bandwidth.

Non-Technical QoS Considerations of Data

QoS is essentially segregating applications and giving preference to certain applications over others. With voice and video, the need for QoS is relatively objective and obvious. However, this is not the case with data applications.

Arriving at the design principles of relatively few classes of data traffic and also of assigning only a select few applications to these classes opens up a variety of subjective non-technical issues. This is because the enterprise is left to subjectively rank their applications in relative priority. This process is usually very politically and organizationally charged and quite often takes more time to complete than the actual technical portion of a QoS implementation.

Tip It is important to have agreement (preferably with executive endorsement) on the relative ranking of data applications within the enterprise, otherwise QoS rollout projects could get derailed when disagreements arise over which applications are the more important.


956467


Service-Provider QoS RequirementsEnd-to-end QoS is like a chain, which is only as strong as the weakest link. Therefore, it's essential for enterprises to use service providers that can provide the service-level agreements required for AVVID applications. For example, the end-to-end requirements of voice and video conferencing are:

• No more than 1% loss

• No more than 150 ms of one-way latency from mouth-to-ear (per ITU G.114 standard)

• No more than 30 ms jitter

Thus, the service provider's component (a subset of the trip) must be considerably tighter, as shown below and in Figure 1-6.

• No more than 0.5% loss

• No more than 60 ms of one-way latency from edge-to-edge

• No more than 20 ms jitter

Figure 1-6 Service-Provider Service-Level Agreements Required for AVVID

To achieve such values, enterprises and service-providers must cooperate and be consistent in classifying, provisioning and integrating their respective QoS solutions.

Maximum One-WayService-ProviderService-Levels

Latency <= 60 msJitter <= 20 msLoss <= 0.5%

Maximum One-Way Service-LevelsLatency < 150 ms / Jitter < 30 ms / Loss < 1%

Service Provider

Enterprisebranchoffice

Enterpriseheadquarters

7464

7

IP IP


956467

Chapter 1 OverviewWhat is the Quality of Service Toolset?

What is the Quality of Service Toolset? As applications that are sensitive to packet loss, delay, and delay variation (jitter) are implemented in Enterprise network environments, the ability to manage these sensitivities has become necessary. The packet loss, delay, and delay variation requirements that VoIP, video, and mission-critical data applications make of the network can be satisfied through the implementation of the QoS classification, scheduling, provisioning, and management tools.

This section provides an overview of the following topics:

• Classification Tools

• Classification Recommendations

• Scheduling Tools

• Scheduling Recommendations

• Provisioning Tools

• Management Tools

Classification ToolsThe first element to a QoS policy is to identify the traffic that is to be treated differently. Classification tools mark a packet or flow with a specific priority. This marking establishes a trust boundary that must be enforced. Classification set this boundary by examining any of the following:

• Layer 2 Parameters (802.1Q Class of Service [CoS] bits, MAC address, Multiprotocol Label Switching [MPLS] experimental values)

• Layer 3 Parameters (IP Precedence, Differentiated-Services Code Points [DSCP], Source/Destination IP address)

• Layer 4 Parameters (TCP or UDP ports)

• Layer 7 Parameters (application signatures)

Only after traffic can be positively identified can policies be applied. Best-practice design recommendations are to identify and mark (with DSCP values) traffic as close to the source of the traffic as possible. The network edge where markings are accepted (or rejected) is referred to as the “trust-boundary.” If markings and trusts are set correctly, then intermediate hops do not have to perform detailed traffic identification, but can administer QoS policies based on these previously set DSCP markings. This approach simplifies policy administration and reduces CPU overhead.

Classification should take place at the network edge, typically in the wiring closet or within the IP phones or voice endpoints themselves.

There are several mechanisms that can be used for marking traffic, including:

• Class of Service

• Type of Service and Differentiated Services Code Points

• Per-Hop Behaviors

• Network-Based Application Recognition

Tip For more information, see Classification in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.


956467


Class of Service

Packets can be marked as important by using Layer 2 Ethernet CoS settings in the User Priority bits of the 802.1p portion of the 802.1Q header (as shown in Figure 1-7).

Figure 1-7 Layer 2 Ethernet (802.1Q) CoS Settings

Type of Service and Differentiated Services Code Points

As Layer 2 media often changes as a packet travels from source to destination, a more ubiquitous classification would occur at Layer 3. The second byte in an IPv4 packet is the Type of Service (ToS) byte. The first three bits (by themselves) of the ToS byte are referred to as the IP Precedence bits. These same three bits, in conjunction with the next three bits, are known collectively as the DSCP bits. These bits are illustrated in Figure 1-8.

Figure 1-8 Layer 3 ToS and DSCP Settings

PREAM. SFD DA

PRI CFI VLAN ID

SA Type PT DATA FCSTAG

4 Bytes

Three bits used for CoS(User priority) 81

034

VersionLength

ToS1 Byte

LEN

7 6 5 4 3 2 1 0

ID Offset Proto FCS IP-SA IP-DA DataTTL

Unused bits;Flow control for

DS CP

IP precedence

DS CPStandard IPV4: Three MSB called IP precedence

(DiffServ may use six D.S. bits plus two for flow control) 8103

5

Layer 3 IPV4


956467


Per-Hop Behaviors

The Internet Engineering Task Force (IETF) has defined certain Per-Hop Behaviors (PHBs) in RFC 2597 and RFC 2598 to identify consistent service levels to be provided by each node in the network infrastructure to packets with DSCP markings.

Tip For more information on RFC 2597, see Assured Forwarding PHB Group. And for more information on RFC 2598, see An Expedited Forwarding PHB.

There are three broad classes of PHBs: Best Effort (BE or DSCP 0), Assured Forwarding (AFxy), and Expedited Forwarding (EF or DSCP 46).

Assured Forwarding has 4 sub-classes within it (corresponding to IP Precedence values) and also 3 levels of drop-preference within each class. For example, AF31 would refer to Assured Forwarding Class 3 drop-preference 1.

DSCP values can be expressed in decimal form or with their PHB keywords; for example DSCP EF is synonymous with DSCP 46, also DSCP AF31 is synonymous with DSCP 26. In this document the DSCP values will be referred to by their PHB keywords.

Network-Based Application Recognition

Although the majority of data applications can be identified by using Layer 3 or Layer 4 criteria (such as discrete IP addresses or well-known TCP/UDP ports), there are applications that cannot be identified such criteria alone. This may be due to legacy limitations, but more likely due to deliberate design. For example, peer-to-peer media-sharing applications deliberately negotiate dynamic ports with the objective of penetrating firewalls. When Layer 3 or 4 parameters are insufficient to positively identify an application, then Network-Based Application Recognition (NBAR) may be a viable alternative solution. It should be noted that NBAR is a more CPU intensive classification mechanism than matching traffic by DSCP or access-lists.

NBAR identifies application layer protocols by matching them against a Protocol Description Language Module (PDLM), which is essentially an application signature. NBAR’s deep-packet classification engine examines the data payload of stateless protocols against PDLMs. There are over 70 PDLMs embedded into IOS 12.2 code. Furthermore, since PDLMs are modular, they can be added to system without upgrading requiring an IOS upgrade.

NBAR is dependent on Cisco Express Forwarding (CEF) and performs deep-packet classification only on the first packet of a flow. The remainder of the packets belonging to the flow is then CEF switched.

Tip For more information, see Network-Based Application Recognition and the NBAR Performance white paper (internal).

Classification Equivalents

Table 1-3 shows the recommended DSCP traffic classifications (in PHB and decimal) and how they relate to IP Precedence and MPLS experimental values.


956467


Table 1-3 AVVID Classification Recommendations by PHB, DSCP and MPLS EV

Note Although many documents on QoS refer to DSCP classifications by their PHB label, you must use their decimal equivalent to make configuration changes in the Catalyst switches. For additional information about the decimal equivalents of PHBs, see Appendix A, “Reference Information.”

Note On routers enabled with MPLS, the IP Precedence values will (by default) be mapped to corresponding MPLS Experimental Values. If the classification recommendations shown in Table 1-3 are used, then no additional classification or reclassification is needed when interfacing with MPLS backbones.

Classification RecommendationsThis section provides classification recommendations for

• Voice Bearer Traffic

• Voice Control Traffic

• Video Conferencing

• Streaming Video

• Mission-Critical Data

Traffic DSCP PHB DSCP Decimal IP Precedence MPLS EV

Voice EF 46 5 5

Video AF41 34 4 4

Voice-Control AF31 26 3 3

Gold-Data

Application 1 AF21 18 2 2



Silver-Data




Bronze Data (best effort) BE 0 0 0

Less-than-best-effort data

Application 1 - 2 0 0




956467


Voice Bearer Traffic

Recommendation: DSCP EF, IP Precedence 5, COS 5

The IETF draft recommends a DSCP PHB label of EF for VoIP traffic. To remain backwardly compatible with IP Precedence, use an IP Precedence value of 5 and a CoS marking of 5.

These markings can be used as selection criteria for entry into the priority queue, where it exists, or the queue with the highest service weight and lowest drop probability in a WRR/WRED scheduling scheme.

Voice Control Traffic

Recommendation: DSCP AF31, IP Precedence 3, CoS 3

Typically the voice gateway or voice application server will mark it's RTP and control traffic with the appropriate DSCP and CoS markings. However, some end devices may not have the capability to correctly classify their own traffic. It is also possible, for reasons of control and security, that you would not want to trust the CoS and ToS markings assigned by the device (and would prefer to rewrite them upon ingress to the network).

Signaling traffic should be assigned a DSCP PHB label of AF31. This assignment is backwardly compatible with an IP Precedence value of 3.

Video Conferencing


In enterprise networks, video conferencing over IP (IPVC) has similar loss, delay, and delay variation requirements to that of VoIP traffic. It is necessary to classify IPVC traffic so that network devices can recognize it and provide the appropriate treatment during periods of congestion. In enterprise networks, video conferencing packets should be marked with a DSCP PHB label of AF41. This assignment is backwardly compatible with an IP Precedence value of 4. A Layer 2 802.1p CoS value of 4 should be used for IPVC traffic in 802.1Q environments.

Streaming Video


Streaming video applications, like IPTV Video on Demand (VoD) programs, are relatively high bandwidth applications with a high tolerance for loss, delay, and delay variation. As such, significant QoS tools are not required to meet the needs of these applications. However, in most enterprise environments, these types of applications are considered more important than regular background applications (such as e-mail and web browsing) and should be given preferential treatment. A Layer 2 classification of CoS 1 in 802.1Q/p environments should be used for these applications. Because streaming video is not drop or delay sensitive, you can use the high drop preference DSCP PHB. The DSCP label AF13 should be used. This assignment is backwardly compatible with an IP Precedence value of 1.


956467


Mission-Critical Data

Recommendation: Gold class or mission-critical—DSCP AF21-23, IP Precedence 2, CoS 2; Silver class—DSCP AF11-AF13, IP Precedence 1, CoS 1

Although the variety of factors that determine the importance of application traffic make it difficult to apply a formula to the provisioning of data, guidelines can be set for the classification of mission-critical traffic. Delay-sensitive applications that are critical to the operation of an enterprise, should be placed in the “gold-data” category and assigned a DSCP PHB ranging from AF21 to AF23 to protect them from drops. Less delay-sensitive applications that are important, but not critical, to the operation of an enterprise, should be placed in the “silver-data” category and assigned a higher drop preference of AF11 to AF13.

If gold-data traffic is assigned AF21-AF23 and silver-data is assigned AF11-AF13, then these traffic flows will automatically be backwardly compatible with the IP Precedence model. Gold-data will be recognized as IP Precedence 2 and silver-data will be recognized as IP Precedence 1.

Less-Than-Best-Effort Data

Recommendation: DSCP 2-6, IP Precedence 0, CoS 0

As mentioned before, non-critical, bandwidth-intensive data traffic should be assigned to the class known as “less-than-best-effort.” This traffic is delay-insensitive and should be given the least preference of any of the classes and, as such, should be dropped sooner than any other traffic. Therefore, less-than-best-effort traffic should be assigned a DSCP of 2-6 (decimal). This assignment is backwardly compatible with an IP Precedence value of 0.

Best-Effort Data

Recommendation: DSCP BE, IP Precedence 0, CoS 0

All other traffic should be placed in the “best-effort” category. This includes all non-interactive traffic, regardless of importance.Best-effort traffic should be assigned a DSCP of BE. This assignment is backwardly compatible with an IP Precedence value of 0.

Scheduling ToolsScheduling tools refer to the set of tools that determine how a frame/packet exits a node. Whenever packets enter a device faster than they can exit it (as with speed mismatches) then a point of congestion, or a bottleneck, can occur. Devices have buffers that allow for scheduling higher-priority packets to exit sooner than lower priority ones, which is commonly called queueing. Queueing algorithms are activated only when a devices is experiencing congestion and are deactivated when the congestion clears.

Figure 1-9 shows a generic example of queueing.


956467


Figure 1-9 Generic Queueing Example

Queueing buffers are finite in capacity and act very much like a funnel for water being poured into a small opening. However, if water is continually entering the funnel much faster than it exits, then eventually the funnel will being overflowing from the top. When queueing buffers begin overflowing, packets may be dropped either as they arrive (tail-drop) or selectively before all buffers are filled. Selective dropping of packets when the queues are filling is referred to as congestion avoidance. Congestion avoidance mechanisms work best with TCP-based applications, as selective dropping of packets causes the TCP windowing mechanisms to 'throttle-back' and adjust the rate of flows to manageable rates.

Congestion avoidance mechanisms are complementary to queueing algorithms; queueing algorithms manage the front of a queue, congestion avoidance mechanisms manage the tail of the queue. Therefore, congestion avoidance mechanisms indirectly affect scheduling.

Scheduling tools include:

• Class-Based Weighted-Fair Queueing

• Low-Latency Queueing

• Weighted-Random Early Detect

Tip For more information, see Congestion Management in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

Class-Based Weighted-Fair Queueing

Class-Based Weighted-Fair Queueing (CBWFQ) is a hybrid queueing algorithm, combining the ability to guarantee bandwidth (from Custom Queueing) with the ability to dynamically ensure fairness to other flows (from Weighted-Fair Queueing). CBWFQ allows for the creation of up to 64 classes of traffic, each with its own reserved queue. Each queue is serviced in a Weighted-Round-Robin (WRR) fashion.

CBWFQ is a highly efficient algorithm for data applications, but is not able to provide strict-priority servicing to real-time applications, such as voice or video.

To avoid bandwidth starvation of background applications (such as routing protocols, network services, and Layer 2 overhead and keepalives), it is recommended that you not provision total bandwidth guarantees to exceed 75% of the link's capacity (see Figure 1-11).

Note Distributed CBWFQ (dCBWFQ) is the distributed counterpart of CBWFQ.

7464

2

Router

Prioritization can be strict,bandwidth guarantee by traffic class,

or automatically weighted

Voice

Video

Data

11

2223 12 1

3333


956467


Low-Latency Queueing

Like CBWFQ, Low-Latency Queueing (LLQ) is also a hybrid queueing algorithm. LLQ is a combination of Priority Queueing, Custom Queueing, and Weighted-Fair Queueing. In fact, LLQ was originally named PQ-CBWFQ, but this name was dropped in favor of LLQ for fairly-obvious marketing reasons.

LLQ adds a strict-priority queue to the CBWFQ scheduler. LLQ is designed exclusively for voice and interactive-video applications. The strict-priority queue is completely emptied before the CBWFQ queues are serviced.

The Layer 3 queueing subsystem for LLQ/CBWFQ is shown on the left side of Figure 1-10.

Figure 1-10 CBWFQ/LLQ Queueing Subsystem Logic

In this illustration, VoIP bearer traffic is placed in the LLQ, commonly known as the priority queue (PQ). When traffic is present in the LLQ, it is serviced with preferential treatment exhaustively (first until none is present). The priority queue is policed so that traffic in the priority queue cannot starve out the other classes of traffic. It is important to provision the LLQ properly. This policing action could negatively affect voice quality if the policing value is set lower than the total amount of voice traffic to be serviced by the LLQ, in which case the excess will be dropped.

This illustration also shows VoIP control traffic being placed in a class-based weighted fair queue of its own so that a small bandwidth guarantee can be made. This insures that call control traffic is transmitted even during periods of congestion on the link. This means that the time to dial tone and call setup/transfer are performed quickly enough to assure a positive user experience.

It is important to keep in mind that the LLQ is in effect a first-in first-out (FIFO) queue. The amount of bandwidth reservable for the LLQ is variable, yet if the LLQ is over-provisioned, the overall effect will be a dampening of QoS functionality. This is because the scheduling algorithm that decides how packets exit the device will be predominantly FIFO (which is essentially “no QoS”). Over-provisioning the LLQ defeats the purpose of enabling QoS at all. For this reason, it is recommended that you not provision more than 33% of the link's capacity as a LLQ (see Figure 1-11).

More than one LLQ can be provisioned. One LLQ could be provisioned for voice and another for video conferencing. Each queue would be serviced exhaustively before the next one would begin to be serviced (this scheduling is similar to legacy Priority Queueing). If more than one LLQ is provisioned, the 33% limit for all LLQs still applies.

7491

7

Low latency queuing Link fragmentationand interleave

Police

PQ Voice

VoIPControl

Fragment

Default

CBWFQ

WFQ

Packets inPackets out

PQ

Interleave TXRing


956467


Note The 33% limit for all LLQs is a design recommendation. There may be cases where specific business needs cannot be met while holding to this recommendation. In such cases, the enterprise must provision queueing according to their specific requirements and constraints.

Figure 1-11 illustrates the recommendations that LLQ is no more than 33% of the link and all bandwidth guarantees are no more than 75% of the link capacity.

Figure 1-11 LLQ and CBWFQ

The functionality of LLQ has been extended in IOS 12.2 to allow the specification of a burst size for the LLQ. This burst parameter is highly useful in provisioning QoS for video conferencing.

Note Distributed LLQ (dLLQ) is the distributed counterpart of LLQ.

Weighted-Random Early Detect

As mentioned before, congestion avoidance mechanisms, like Weighted-Random Early Detect (WRED), are complementary to and dependent on queueing algorithms.

The default router behavior allows output buffers to fill during periods of congestion and then drops everything thereafter (tail-drop). Due to the nature of the sliding-windows mechanism of TCP, a potentially large number of packets from numerous connections are discarded because of lack of buffer capacity during tail-drop. This behavior can result in waves of congestion followed by periods during which the transmission link is not fully used. Figure 1-12 illustrates such congestion waves created by tail-drop.

VideoVoice Control Data Routing

LLQ 33%

LLQ/CBWFQ Bandwidth Provisioning Principles

LLQ (Voice) + LLQ (Video) 33% Link CapacityLLQ (Voice) + LLQ (Video) + CBWFQ (All Data) 75% Link

Sum of all BW guarantees 75% of link

Link capacity

8103

6


956467


Figure 1-12 Congestion Waves Attributable to Tail-Drop

WRED obviates this situation proactively by providing congestion avoidance. That is, instead of waiting for buffers to fill before dropping packets, the router monitors the buffer depth and performs early discards on selected packets sent over selected connections.

WRED is primarily designed to work with TCP applications. When WRED is used and the TCP source detects the dropped packet, the source slows its transmission. WRED can selectively discard lower priority traffic when the interface begins to get congested.

WRED can also be configured to use the DSCP value when it calculates the drop probability of a packet. The DiffServ Compliant WRED feature extends the functionality of WRED to enable support for PHBs. Thus, packets marked with Assured Forwarding PHBs will be assigned preferential drop probabilities based on these markings by the WRED algorithm. Figure 1-13 illustrates a simplified (3 PHB) example of DSCP-based WRED.

Figure 1-13 DSCP-Based WRED for AF11, AF12, and AF13

Note Distributed WRED (dWRED) is the distributed counterpart of WRED.

8103

7

100

Three traffic flowsstart at different times

Another traffic flowstarts at this point

Time

Queueutilization

8103

8

1

0Begin

droppingAF13

Begindropping

AF12

Begindropping

AF11

Dropall

AF13

Dropall

AF12

Dropall

AF11

Max queue length(tail drop everything)

Dropprobability


956467


Tip For more information, see Congestion Avoidance in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

Scheduling RecommendationsThis section provides some recommendations for queue scheduling and the number of queues to use.

Queue Scheduling

Once you have marked your traffic appropriately and have allowed the traffic admission into the appropriate queue, you need to control how the queues are serviced. The scheduler process can use a variety of methods to service each of the transmit queues (voice, video, mission critical data, and general access data). The easiest method is a round-robin algorithm, which services queue 1 through queue N in a sequential manner. While not robust, this is an extremely simple and efficient method that can be used for branch office and wiring closet switches. Distribution layer switches use a WRR algorithm in which higher priority traffic is given a scheduling “weight.”

Today's QoS-enabled switches have the ability to use hybrid scheduling algorithms that allow an exhaustive priority queue to be serviced until it is empty and WRR is used for the additional queues on a given interface.

Where supported, it is best to use a priority queue for voice and video bearer traffic. If a priority queue is not supported, use WRR and WRED to service the queue that contains the voice and video traffic. Set the WRR to service that queue most frequently and set the WRED thresholds such that the queue does not participate in WRED congestion avoidance.

Number of Queues

There has been much discussion about how many queues are actually needed on transmit interfaces in the campus. Should you add a queue to the wiring closet switches for each CoS value? Should you add eight queues to the distribution layer switches? Should you add a queue for each of the 64 DSCP values? This section presents some guidelines that address these questions.

First, it is important to remember that each port has a finite amount of buffer memory. A single queue has access to all the memory addresses in the buffer. As soon as a second queue is added, the finite buffer amount is split into two portions, one for each queue. At this point, all packets entering the switch must contend for a much smaller portion of buffer memory. During periods of high traffic, the buffer fills and packets are dropped at the ingress interface. Because the majority of network traffic today is TCP-based, a dropped packet results in a resend, which further increases network congestion. Therefore, queuing should be used cautiously and only when particular priority traffic is sensitive to packet delays and drops.

Provisioning ToolsThe category of provisioning tools includes:

• Policing and Shaping Tools

• Link-Efficiency Mechanisms


956467


Policing and Shaping Tools

Policers and shapers are the oldest forms of QoS mechanisms. These tools have the same objectives, namely to identify and respond to traffic violations.

Policers and shapers usually identify traffic violations in an identical manner; however, their main difference is the manner in which they respond to violations:

• A policer typically drops traffic.

• A shaper typically delays excess traffic using a buffer, or queueing mechanism, to hold packets and shape the flow when the data rate of the source is higher than expected.

Shaping tools meter the transmit rate of frames from a source router to a destination router. This metering is typically done at a value that is lower than the line or circuit rate of the transmitting interface, as shown inFigure 1-14. The metering is done at this rate to account for the circuit speed mismatches that are common in current non-broadcast multiple-access (NBMA) networks, such as Frame-Relay and ATM.

Figure 1-14 Shaping Traffic at Less than Line Rate for NBMA Networks

Tip For more information, see Policing and Shaping in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

Link-Efficiency Mechanisms

Newer mechanisms have been developed to address link-specific requirements, such as minimizing serialization delay and traffic compression.

Tip For more information, see Link Efficiency Mechanisms in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

Link Fragmentation and Interleave

To offset link-specific delays, larger data packets can be fragmented and interleaved with higher priority voice or video packets. This helps reduce the variation in delay caused by periodic congestion on slow-link edges. Figure 1-15 illustrates the process of link fragmentation and interleaving (LFI).

Traffic shaping limits the transmit rateto a value (R) lower than line rate

Without Traffic Shaping

With Traffic Shaping

Line Rate

R

7464

3


956467


Note In the context of Link-Efficiency Mechanisms, slow-speed links are defined as WAN links with clock speeds of 768 kbps or less.

Figure 1-15 Fragmentation and Interleaving to Reduce Serialization Delay

LFI belongs to the Layer 2 queueing subsystem and operates on packets that have already exited the Layer 3 queueing subsystem (LLQ/CBWFQ). As illustrated in Figure 1-10, only packets that are not assigned to the LLQ are fragmented.

Table 1-4 shows the serialization delays of various packet sizes on increasingly faster links.

Table 1-4 Serialization Delays at Various Clocking Speeds

A maximum of 10 ms serialization delay is the recommended target to use for setting fragmentation size, as this allows adequate time for end-to-end delay required by voice (150-200 ms).

7464

4

Serialization Delay =Frame Size

Before

Link Speed

After using LFI Tools

Data Data Voice Data

60 Byte Voice 1500 Byte Data Frame

214 ms Serialization Delayfor 1500 Byte Frame at 56 kbps

Link SpeedDelay at 64 Bytes

Delay at 128 Bytes

Delay at 256 Bytes

Delay at 512 Bytes

Delay at 1024 Bytes

Delay at 1500 Bytes

56kbps 9 ms 18 ms 36 ms 72 ms 144 ms 214 ms





768kbps 640 µs 1.28 ms 2.56 ms 5.12 ms 10.4 ms 15 ms


956467


Compressed Real-Time Protocol

RTP is the Internet Standard (RFC 1889) protocol for the transport of real-time voice and/or video. At 40 bytes total, the header portion of an RTP packet is considerably large and can account for nearly two-thirds or the entire packet. For example, G.729 VoIP payloads are only 20 bytes when sampled at 20 ms.

Tip For more information on RFC 1889, see RTP: A Transport Protocol for Real-Time Applications.

To avoid the unnecessary consumption of available bandwidth, cRTP can be used on a link-by-link basis. cRTP compresses IP/UDP/RTP headers from 40 bytes to between 2 and 5 bytes. Such compression is illustrated in Figure 1-16.

Figure 1-16 IP/UDP/RTP Header Compression

Note Distributed RTP Header Compression (dCRTP) is the distributed counterpart of cRTP.

Compression techniques minimize bandwidth requirements and are highly useful on slow-links. Due to the additional CPU loads these compression techniques require, they need to be used with caution, especially in scenarios with many remote sites attaching to a central WAN Aggregation router. For more information on when to use cRTP, see Appendix A, “Reference Information.”

Tip For more information on cRTP, see Configuring Compressed Real-Time Protocol.

TX Ring

The transmit (TX) ring is a FIFO queue located just prior to the physical interface. Its purpose is to hold packets prior to the physical interface to insure that a packet will be available when the interface is ready to transmit traffic. It is the unprioritized, final buffer used to hold frames prior to transmission in order to drive link utilization to 100%.

The placement of the TX ring in the Layer 2 queueing subsystem is shown in Figure 1-10.

UDP HDR RTP HeaderIP Header

20 Bytes 8 Bytes 12 Bytes

2-5 Bytes 8104

0


956467


Call Admission Control

After performing the calculations to provision the network with the required bandwidth to support voice, video and data applications, it's important to ensure that voice or video do not oversubscribe the portion of the bandwidth allocated to them. While most QoS mechanisms are used to protect voice from data, Call Admission Control (CAC) is used to protect voice from voice (and video from video).

CAC is illustrated in Figure 1-17, which shows an environment where the network has been provisioned to support only two voice calls. However, if a third voice call is attempted, the quality of all calls will degrade.

Figure 1-17 Call Admission Control—Protects Provisioned Bandwidth for Voice from Voice

Tip A detailed discussion of CAC is not in the scope of this document, but it is and important consideration in successful AVVID rollouts. The details of CAC are covered in the “Call Admission Control” chapter of the IP Telephony Solution Reference Network Design Guide.

Management ToolsImplementing a QoS solution is not a one-time task that is complete upon policy deployment. A successful QoS deployment is followed by ongoing monitoring of service levels and periodic adjustments and tuning of QoS policies, as shown in Figure 1-18.

IP IP IP

IP WAN

8103

2

V

M

IP WAN link provisioned for 2 VoIP calls

CAC limits number of VoIP calls on each WAN link

No physical limitation on IP links.If third call accepted, voice qualityof all calls degrades.

CallManager

IP WANlink

Router/Gateway


956467


Figure 1-18 Quality of Service Management Cycle

Short-term monitoring is useful for verifying that the deployed QoS policies are having the desired end-to-end effect. Long-term monitoring, or trending, is needed to determine whether the provisioned bandwidth is still adequate for changing needs. For example, upgrading to a newer version of an application may cause the provisioned bandwidth to be exceeded (as would the addition of new users). Furthermore, business objective themselves may change, and periodically the overall ranking of priority of applications may need revision.

Monitoring and adapting QoS policies to such business changes is efficiently done through QoS Management solutions.

7464

8

Monitor

Cla

ssify

Adjust Service Levels


956467



956467


C H A P T E R 2
QoS Considerations When Connecting End-Points to an AVVID Network
This chapter provides information about implementing QoS at the edge of an AVVID network. It includes the following:

• Overview

• The Trusted Edge

• IP Telephony

• Video

• Mission-Critical Applications

• Summary


OverviewClassification (or marking) of traffic at the edge of the network (where CPU resources are plentiful and scalability of classification services is not an issue) is a requirement that needs to be addressed in today's enterprise networking environments.

This chapter focuses on the design requirements at the edge of the network needed to classify traffic so that devices throughout the network can recognize loss, delay, and delay variation sensitive applications and give them the appropriate treatment end-to-end.

Throughout this chapter VoIP traffic will be used to illustrate how QoS can limit loss, delay, and delay variation because it is easy to illustrate how network performance can adversely affect voice quality. Delay-sensitive applications, like video-conferencing over IP, and mission critical applications, like ERP applications or mainframe SNA applications, have similar requirements of the network and are adversely affected by packet loss, delay, and delay variation.


Chapter 2 QoS Considerations When Connecting End-Points to an AVVID NetworkThe Trusted Edge

The Trusted EdgeWhen classifying traffic types in an enterprise networking environment, a trust boundary must be established. A trust boundary is the point at which classification of traffic is either applied by the device allowing traffic into the network or the device allowing traffic into the network trusts classification that has been applied by the end station.

Today's enterprise switch platforms have the ability to trust CoS in an 802.1Q/p environment or DSCP or IP Precedence in an environment where more granularity is required or where 802.1Q/p is not available. It is desirable to have traffic classified by the signaling device itself and use trust as the traffic enters the network, as is the case with Cisco IP phones and voice gateways. However, there are places in the network where due to the need for administrative control or the lack of end station capabilities classification or marking at the edge is required.

Chapter 3, “QoS in an AVVID-Enabled Campus Network” contains detailed configuration examples for the various platforms that have classification/marking capabilities.

IP TelephonyAn IP telephony solution is built with many components that can generate both VoIP bearer and control traffic. This section provides information about the following components:

• IP Phones

• CallManager

• VoIP Gateways

IP PhonesCisco IP phones (79xx) classify their voice and control traffic at Layer2 (802.1Q/p) and at Layer3 (DSCP). The recommended configuration is to trust the L2 (CoS) classification applied by the phone on the access port servicing the phone. This is accomplished through the application of the trust cos port configuration option. Additionally, the IP phone must be configured to set the trust state of the “PC” port on the IP phone. This is accomplished with the trust-ext interface/port level command. In most cases, the IP phone's PC port should be set to an untrusted state where no classification of traffic by the PC is allowed. Detailed examples are available in Chapter 3, “QoS in an AVVID-Enabled Campus Network.”

CallManagerThe CallManager application can generate VoIP bearer and VoIP control traffic in several formats. A CallManager can act as a conference bridge, in which case it generates VoIP Bearer traffic classified with a DSCP value of EF. CallManager acting as a Music on Hold server also generates voice bearer traffic marked with a DSCP value of EF. Additionally, a CallManager acting as a call setup agent in an IP telephony network generates VoIP call control traffic (H.323, skinny station, and MGCP) all marked with a DSCP value of AF31.

Because CallManager correctly classifies the VoIP bearer and control traffic that it generates, the only requirement of the network is that the trusted edge be configured to accept this classification. This is accomplished through the use of the trust dscp or trust ip-precedence interface/port level configuration command. Detailed examples by platform can be found in Chapter 3, “QoS in an AVVID-Enabled Campus Network.”


956467

Chapter 2 QoS Considerations When Connecting End-Points to an AVVID NetworkVideo

VoIP GatewaysCisco offers two types of VoIP gateways: H.323 and MGCP.

H.323

IOS-based H.323 gateways can be configured to correctly mark their VoIP bearer traffic with a DSCP value of EF and their VoIP control traffic with a DSCP value of AF31.

Tip Detailed examples for IOS configurations can be found in the IP Telephony QoS Design Guide.

Because H.323 gateways correctly mark their traffic, the network requirement at the trusted edge is to allow the classified traffic to be admitted to the network. This is accomplished through the use of the trust dscp or trust ip precedence port/interface level configuration command.

MGCP

MGCP gateways can be configured to correctly mark their VoIP bearer traffic with a DSCP value of EF and their VoIP control traffic with a DSCP value of AF31.

Tip Detailed examples for IOS configurations can be found in the IP Telephony QoS Design Guide.

Because MGCP gateways correctly mark their traffic, the network requirement at the trusted edge is to allow the classified traffic to be admitted to the network. This is accomplished through the use of the trust dscp or trust ip precedence port/interface level configuration command.

Classification for Non-marking ApplicationsSome Cisco applications and older versions of IOS-based gateways may not correctly classify their VoIP bearer and control traffic. When this is the case, the requirement at the trusted edge of the network is to apply the correct classification. Because these devices generate both VoIP control and bearer traffic, you cannot use the simple port-level configuration commands to set the CoS or DSCP. In this case, a Layer 3 aware switch that supports Modular Quality of Service CLI (MQC)-based classification should be used. When you use MQC, the VoIP bearer and control traffic is identified via extended Access Control Lists (ACLs) and subsequently marked with the correct DSCP value (EF for VoIP bearer and AF31 for VoIP control). Configuration examples using MQC are included in Chapter 3, “QoS in an AVVID-Enabled Campus Network” and Chapter 4, “QoS in an AVVID-Enabled Wide-Area Network.”

VideoThere are two types of IP Video traffic: IP video conferencing, which is an interactive, two-way video, and streaming video, which is one way, view only. Each has different and specific requirements of the network. One varies greatly in its bandwidth and packet size requirements and is very delay and delay variation sensitive, while the other acts very much like a large file transfer (tolerant of delay, delay


956467

Chapter 2 QoS Considerations When Connecting End-Points to an AVVID NetworkMission-Critical Applications

variability, and packet loss, within reason). Because the network requirements for these types of traffic are different, you should classify them differently at the edge of the network so that different policies can be applied throughout the network.

Video ConferencingIP video conferencing (IPVC) traffic should be classified at the edge of the network with a CoS value of 4, or where the edge device has the ability to do so with a DSCP value of AF41. This can be accomplished with port-level configuration commands to set the CoS or DSCP, or through the application of MQC configuration and input service policies. Detailed configuration examples are included in Chapter 3, “QoS in an AVVID-Enabled Campus Network.”

Streaming VideoStreaming video, like IPTV, should be classified with a CoS value of 1, or where the edge device has the ability to do so with a DSCP value of AF13. This can be accomplished with port-level configuration commands to set the CoS or DSCP, or through the application of MQC configuration and input service policies. Detailed configuration examples are included in Chapter 3, “QoS in an AVVID-Enabled Campus Network.”

Mission-Critical ApplicationsAs discussed in Chapter 1, “Overview,” classification of data applications should be limited to a select few applications so preferential treatment can be provided with clearly discernible results. This section provides two examples of application classification: one for DLSW+ traffic, another for bandwidth-intensive applications that require less-than-best-effort treatment.

DLSW+DLSW+ traffic is typically deployed in IBM mainframe environments where loss, and delay are critical application requirements. When DLSW+ is enabled on a Cisco IOS router, the DLSW+ traffic is marked, by default, with an IP Precedence value of 5. This default classification could have a negative effect on VoIP traffic if the classified traffic is allowed to enter the PQ when the PQ has not been provisioned to support it. One solution is to modify the DLSW+ configuration to change the default classification to IP Precedence 2. Note that DLSW+ is not DSCP aware, so a DLSW+ peer classification of DSCP AF21 cannot be accomplished by the IOS router itself. The modification is accomplished through the use of the priority keyword when defining the peer and the tos map commands, as illustrated in the configuration below:

dlsw remote-peer 0 tcp 171.70.234.121 prioritydlsw tos map high 2 medium 2 normal 2 low 2

After the traffic is properly classified, the access switch to which the DLSW+ peer is attached must allow the classification into the network. This is accomplished with the trust dscp or trust ip precedence interface/port level command.


956467

Chapter 2 QoS Considerations When Connecting End-Points to an AVVID NetworkSummary

Less-than-Best-EffortLess-than-best-effort (<BE) traffic can be defined as traffic that can be bandwidth intensive but should be given less preference than other traffic by the network when periods of congestion are encountered. These applications are often batch updates or large file transfers that can be easily identified by the IP addresses of the devices in the conversation or by well-known TCP or UDP port numbers.

Classification of this type of traffic is most effectively achieved at the edge of the network though the utilization of MQC configuration where ACLs can be used to identify the traffic by IP address or TCP/UDP port numbers.

Peer-to-peer file sharing applications, such as Napster, KaZaa, and Gnutella, also fall in to the category of less-than-best-effort traffic. These types of applications can have considerable impact on network utilization and they are relatively difficult to identify by IP address and/or TCP/UDP port numbers. Chapter 4, “QoS in an AVVID-Enabled Wide-Area Network” contains detailed examples of the application of NBAR to identify and classify these types of less-than-best-effort applications with MQC configuration.

Less-than-best-effort traffic should be marked with a DSCP decimal value of 2, 4, or 6 so that MQC can be used to limit the amount of bandwidth that less-than-best-effort traffic can consume and affect the drop preference of this type of traffic during periods of congestion.

SummaryIn order for the network to be able to recognize and provide preferential treatment for applications that are loss, delay, and delay variation sensitive, classification and marking at Layer 2 (802.1Q/P CoS) or Layer 3 (IP TOS DSCP or IP Precedence) must be established. To insure that only the intended traffic is classified and treated preferentially, a trusted edge must be established. The trusted edge is where classified traffic from trusted sources is allowed to enter the network and where classification of traffic from untrusted sources is applied. The ability to allow classification to enter the network from a trusted source is enabled via the use of the interface/port level commands trust cos, trust dscp, or trust ip precedence. Additionally, when an IP phone is present, the trust state of the phones PC port must be established. This is accomplished via the trust-ext interface/port-level command.

Classification of traffic from untrusted devices or from devices that are unable to correctly mark their traffic with a Layer 2 CoS or Layer 3 ToS (DSCP or IP Precedence) value can be accomplished in one of two ways.

• If all the traffic entering the network from a given device should receive the same classification, the set cos or set dscp port- level commands can be used.

• If the traffic entering the network from a specific device requires multiple classifications types (as with a VoIP gateway where VoIP bearer and control traffic must be classified with different DSCP values), MQC configuration is required. Using MQC, interesting traffic is identified through ACLs and MAP CLASS statements and specific treatment/classification is applied via a service-policy.

In short there are many ways to accomplish classification of traffic at the edge of the network the selection of which is dependent on the requirements that the application has of the network.


956467

Chapter 2 QoS Considerations When Connecting End-Points to an AVVID NetworkSummary


956467


C H A P T E R 3
QoS in an AVVID-Enabled Campus Network
This chapter provides information about implementing QoS in an AVVID-enabled campus network. It includes the following:

• Overview

• QoS Toolset

• Server Farm Switch Selection

• Selecting an Access-Layer Switch

• Selecting a Distribution-Layer Switch

• Summary


OverviewUntil recently, the conventional wisdom has been that QoS was not an issue in an enterprise campus network where bandwidth is plentiful. As applications like IP telephony and video-conferencing, and mission-critical data applications have been implemented in the campus, it has become evident that buffer management, not just bandwidth, is an issue that must be addressed. QoS functions, such as classification, scheduling, and provisioning, are required to manage bandwidth and buffers to minimize loss, delay, and delay variation.

Throughout this chapter VoIP traffic will be used to illustrate how QoS can limit loss, delay, and delay variation because it is easy to illustrate how network performance can adversely affect voice quality. Delay-sensitive applications, like video-conferencing over IP, and mission critical applications, like ERP applications or mainframe SNA applications, have similar requirements of the network and are adversely affected by packet loss, delay, and delay variation.

This chapter focuses strictly on the campus components of the Cisco AVVID Network Infrastructure (as shown in Figure 3-1), specifically the:

• Access routers

• Distribution routers

For general information about using QoS for voice and video, see Chapter 1, “Overview.”


Chapter 3 QoS in an AVVID-Enabled Campus NetworkOverview

Figure 3-1 Campus Infrastructure

Delay Variation

In campus local area networks (LANs), serialization delay is not a significant concern. The amount of time required for LAN interfaces to serialize the bits of packets onto the physical media is negligible; it is not significant enough to affect delay-sensitive applications. Additionally in LANs, propagation delay is of little concern because LANs by their very nature are not geographically dispersed.

The type of delay that is present in LANs is variation in delay, or jitter (as explained in the following sections). This can adversely affect voice and video quality by introducing packet loss through jitter buffer over-runs and under-runs.

Transmit Buffer Congestion

An additional contributor to packet loss in campus networks is TX buffer congestion. Transmit buffer congestion can happen if a rate change occurs or if many interfaces are aggregated into a single uplink, resulting in an oversubscription of the uplink’s capacity to buffer packets.

The bits of a traffic flow that runs through a high-speed campus network serialize into and out of switches at different rates depending on the link speed of the physical interfaces they are traversing. When traffic serializes into a campus switch at gigabit speeds and is switched to a one hundred megabit interface, the switch must have buffering capabilities in order to hold, or queue, the bits while it waits to transmit them. When a transmit buffer fills, ingress interfaces are not able to place new traffic into the transmit buffer of the target interface. When the switch cannot place a packet into the transmit queue because of TX buffer congestion/exhaustion, packet drops will occur (as shown in Figure 3-2).

Si

Si

Si

Si

IP

IP

IP

IP

IP

IP

IP

IPIP phonesAccess

Distribution Core WANaggregator

Branchrouter

Access IP phones

7638

9

WAN


956467

Chapter 3 QoS in an AVVID-Enabled Campus NetworkOverview

Figure 3-2 Transmit Congestion

There are many points in a campus network where QoS mechanisms are required to manage loss, delay, and delay variation. Figure 3-3 illustrates areas where TX buffer congestion can become an issue.

Figure 3-3 QoS in the Campus Network.

Using multiple queues on the transmit interfaces minimizes the potential for dropped or delayed traffic caused by TX buffer congestion. By separating voice, video, and mission-critical data (which are all sensitive to loss, delay, and delay variation) into their own queues, you can prevent flows from being dropped at the ingress interface even when TX buffer congestion is experienced. You can also minimize delayed transmission due to non-QoS sensitive traffic congestion by servicing the QoS sensitive queues in a priority fashion. (Scheduling algorithms are discussed in the “Scheduling Tools” section on page 1-17.)

Ethernet switch

100 Mbps1Gbps

Additional flows, includingvoice, can not get access to TX

queue when it becomes fulland packets are dropped.

Bits serialize OUT at 100Mbps.TX queue buffers to compensate

for rate change.

Bits serialize INat 1Gbps

RX TX

Ethernet switch

Data

Missioncritical data

Video

Voice

To core

RX

RX

RX

RX

TX

Put voice and videointo "delay and drop"

sensitive queue

Queue assignment basedon CoS/ToS classification

7469

3


956467

Chapter 3 QoS in an AVVID-Enabled Campus NetworkQoS Toolset

Figure 3-4 illustrates the placement of separate TX buffers. As the transmit queues begin to fill, traffic is dropped from the non-mission-critical buffer first. This protects voice, video, and mission-critical data from packet loss.

Figure 3-4 Using Separate TX Buffers

QoS ToolsetThe challenges of loss, delay, and delay variation can be addressed through the application of various QoS tools.

This section provides information about the use of QoS tools in a campus environment. For general information about the QoS Toolset, see the “What is the Quality of Service Toolset?” section on page 1-12.

ClassificationWithin a campus AVVID network, you should classify voice and video bearer traffic, signaling traffic, and mission-critical data traffic.

For general recommendations for classification, see “Classification Recommendations” section on page 1-15.

Core

Distribution

Access

7469

4

Si

Si Si

IP

TX TX

TX TX

TX TX

TX TX

TX

Areas where QoSmaybe a concern


956467

Chapter 3 QoS in an AVVID-Enabled Campus NetworkQoS Toolset

SchedulingIn access-layer switches, the number of queues is not as important as how those queues and their various drop thresholds are configured and serviced. As few as two queues might be adequate for wiring closet access switches, where buffer management is less critical than at other layers. How these queues are serviced (RR, WRR, Priority Queuing, or a combination of Priority Queuing and WRR or WRED) is less critical than the number of buffers because the scheduler process is extremely fast when compared to the aggregate amount of traffic.

Distribution-layer switches require much more complex buffer management due to the flow aggregation occurring at that layer. Not only are priority queues needed, but thresholds within the standard queues should also be specified. It is important to note that Cisco has chosen to use multiple thresholds within queues instead of continually increasing the number of interface queues. As discussed earlier, each time a queue is configured and allocated, all of the memory buffers associated with that queue can be used only by frames meeting the queue entrance criteria.

For example, assume that a Catalyst 4000 10/100 Ethernet port has two queues configured, one for VoIP (VoIP bearer and control traffic) and the default queue, which is used for Hypertext Transfer Protocol (HTTP), email, FTP, logins, Windows NT Shares, and Network File System (NFS). The 128 KB voice queue is split into a 7:1 transmit and receive ratio. The transmit buffer memory is then further separated into high and low priority partitions in a 4:1 ratio. If the default traffic (the web, email, and file shares) begins to congest the default queue, which is only 24 KB, then packets are dropped at the ingress interfaces. This happens regardless of whether or not the VoIP control traffic is using any of its queue buffers. The dropped packets of the TCP-oriented applications cause each of these applications to send the data again, aggravating the congested condition of the network. If this same scenario were configured with a single queue, but with multiple thresholds used for congestion avoidance, then the default traffic would share the entire buffer space with the VoIP control traffic. Only during periods of congestion, when the entire buffer memory approaches saturation, would the lower priority traffic (HTTP and email) be dropped.

This discussion does not imply that multiple queues are to be avoided in Cisco AVVID networks. As discussed earlier, the VoIP bearer streams must use a separate queue to eliminate the adverse affects that packet drops and delays have on voice quality. However, every single CoS or DSCP value should not get its own queue because the small size of the resulting default queue will cause many TCP resends and will actually increase network congestion.

In addition, the VoIP and video bearer channel is a bad candidate for queue congestion avoidance algorithms such as WRED. Queue thresholding uses the WRED algorithm to manage queue congestion when a preset threshold value is specified. Random Early Detection (RED) works by monitoring buffer congestion and discarding TCP packets before they are admitted to the queue if the congestion begins to increase. The result of the drop is that the sending endpoint detects the dropped traffic and slows the TCP sending rate by adjusting the window size. A WRED drop threshold is the percentage of buffer utilization at which traffic with a specified CoS value is dropped, leaving the buffer available for traffic with higher-priority CoS values. The key is the word “Random” in the algorithm name. Even with weighting configured, WRED can still discard packets in any flow; it is just statistically more likely to drop them from the lower CoS thresholds.


956467

Chapter 3 QoS in an AVVID-Enabled Campus NetworkServer Farm Switch Selection

Server Farm Switch SelectionFigure 3-5 shows a typical server farm design, with a Catalyst 6500 (Layer 3 aware using the Policy Feature Card [PFC]) at the access layer. A Catalyst 6500 with the PFC is able to classify traffic using ACLs and Services Policies to apply CoS, IP Precedence, or DSCP markings to traffic on ingress to the network. Both can be used to ensure admission of traffic into the appropriate queue. The Catalyst 4006 with Supervisor III, and the Catalyst 3550 are also excellent server farm switches with advanced QoS features. The tradeoffs between a Catalyst 6500, a Catalyst 4000 Supervisor III, and a Catalyst 3500 are primarily switching capacity and modularity.

Tip For a comparison of the features of each of the Catalyst switches, see the Cisco Products Quick Reference Guide: February 2002.

The example configurations for policy-based classification in this section leverage each of these types of switches for a portion of the configuration.

Figure 3-5 Server Farm Switch Selection

Tip For more information about designing server farms, see the Designing Small Scale Server Farms white paper (internal).

Si

Si Si

V

V

Core

Distribution

Access

Catalyst 6500

Layer 3 awareserver farm

switch

Videoconference

CallManager(TFTP)

H.323Gateway

MGCPGateway

7469

6


956467


Voice Bearer TrafficVoice traffic can be identified in many ways. The easiest way to identify voice traffic is to have the end device (the IP phone or gateway) mark its traffic appropriately. Cisco IP phones tag their bearer traffic at Layer 2 with a CoS of 5 and set the Layer 3 DSCP marking to EF. Voice application servers, such as Personal Assistant, IP IVR, and Unity - Unified Messaging, are not as far along as the hardware devices and may not mark their bearer and control traffic with the appropriate Layer 3 tagging. And, because current voice application servers do not support 802.1Q configurations for the network interface, they are not capable of Layer 2 CoS classification. To classify voice application traffic at the edge of the network for voice application servers, you must use a switch that has Layer 3 awareness and a service policy that uses Layer 3 and Layer 4 (TCP or UDP ports) as its admission criteria.

The following configuration example uses a Catalyst 3500. In this example, the switch recognizes and classifies voice bearer and signaling traffic on ingress into the network.

Step 1 Enable switch-wide QoS.

3550G-Access#config tEnter configuration commands, one per line. End with CNTL/Z.3550G-Access(config)#mls qos

To verify, enter the following command (shown with its associated output):

3550G-Access#show mls qosQoS is enabled

Step 2 Modify the default CoS-to-ToS mapping table. You must setup a translation between CoS and DSCP because there at only 8 CoS labels and 64 possible DSCP labels. The default mapping table looks like the following:

3550G-Access#show mls qos maps

Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------- dscp: 0 8 16 24 32 40 48 56

Change the defaults so that:

• CoS 3 maps to AF31 (26)

• CoS 4 maps to AF41 (34)

• CoS 5 to EF (46)

3550G-Access#config tEnter configuration commands, one per line. End with CNTL/Z.3550G-Access(config)#mls qos map cos-dscp 0 8 16 26 34 46 48 56

To verify, enter the following command (shown with its associated output):

3550G-Access#show mls qos maps Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------- dscp: 0 8 16 26 34 46 48 56


956467


Step 3 Turn on priority queuing and move CoS 5 traffic to queue 4, which is the priority queue in the Catalyst 3500 family. The default queuing looks like the following:

3550G-Access#show mls qos interface queueingGigabitEthernet0/1Ingress expedite queue: disEgress expedite queue: diswrr bandwidth weights:qid-weights 1 - 25 2 - 25 3 - 25 4 - 25 when expedite queue is disabledDscp-threshold map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 01 01 01 01 2 : 01 01 01 01 01 01 01 01 01 01 3 : 01 01 01 01 01 01 01 01 01 01 4 : 01 01 01 01 01 01 01 01 01 01 5 : 01 01 01 01 01 01 01 01 01 01 6 : 01 01 01 01 Cos-queue map:cos-qid 0 - 1 1 - 1 2 - 2 3 - 2 4 - 3 5 - 3 6 - 4 7 - 4

Change the defaults:

3550G-Access#config tEnter configuration commands, one per line. End with CNTL/Z.3550G-Access(config)#interface range g 0/1 - 123550G-Access(config-if-range)#priority-queue out3550G-Access(config-if-range)#wrr-queue cos-map 4 5

To verify, issue the following command (shown with its associated output):

3550G-Access#show mls qos interface queueing GigabitEthernet0/1Ingress expedite queue: disEgress expedite queue: enawrr bandwidth weights:qid-weights 1 - 25 2 - 25 3 - 25 4 - 25 when expedite queue is disabledDscp-threshold map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 01 01 01 01 2 : 01 01 01 01 01 01 01 01 01 01 3 : 01 01 01 01 01 01 01 01 01 01 4 : 01 01 01 01 01 01 01 01 01 01 5 : 01 01 01 01 01 01 01 01 01 01 6 : 01 01 01 01


956467


Cos-queue map:cos-qid 0 - 1 1 - 1 2 - 2 3 - 2 4 - 3 5 - 4 6 - 4 7 - 4

Step 4 Create an ACL that identifies voice bearer and control traffic.

3550G-Access (config)#ip access-list extended VOICE3550G-Access (config-ext-nacl)#remark Match the UDP ports that VoIP uses for Bearer Traffic3550G-Access (config-ext-nacl)#permit udp any any range 16384 327673550G-Access (config)#ip access-list extended VOICE-CONTROL3550G-Access (config-ext-nacl)#remark Match VoIP Control Traffic3550G-Access (config-ext-nacl)#remark SCCP3550G-Access (config-ext-nacl)#permit tcp any any range 2000 20023550G-Access (config-ext-nacl)#remark H323 Fast Start3550G-Access (config-ext-nacl)#permit tcp any any eq 17203550G-Access (config-ext-nacl)#remark H323 Slow Start3550G-Access (config-ext-nacl)#permit tcp any any range 11000 119993550G-Access (config-ext-nacl)#remark H323 MGCP3550G-Access (config-ext-nacl)#permit udp any any eq 2427

Step 5 Create classes that use the ACLs as admission criteria (as shown below).

3550G-Access (config)#class-map match-all VOICE3550G-Access (config-cmap)#description VOIP Bearer Traffic3550G-Access (config-cmap)#match access-group name VOICE3550G-Access (config)#class-map match-all VOICE-CONTROL3550G-Access (config-cmap)#description VOIP Control Traffic (SCCP, H225, H254, MGCP)3550G-Access (config-cmap)#match access-group name VOICE-CONTROL

Step 6 Create a service policy that uses the classes as admission and sets the DSCP PHB labels.

3550G-Access (config)#policy-map ACCESS-C3550-LAN-EDGE-IN3550G-Access (config-pmap)#description Set DSCP PerHopBehavior Label for VOIP Control and Bearer Traffic3550G-Access (config-pmap)#class VOICE-CONTROL3550G-Access (config-pmap-c)#set ip dscp 263550G-Access (config-pmap)#class VOICE3550G-Access (config-pmap-c)#set ip dscp 46

Step 7 Apply the policy to an interface so that traffic entering the network through this port is classified with the appropriate DSCP PHB Label EF and AF31 for VoIP bearer and control respectively.

3550G-Access#ctEnter configuration commands, one per line. End with CNTL/Z.3550G-Access(config)#int g 0/2550G-Access(config-if)#service-policy input ACCESS-C3550-LAN-EDGE-IN


3550G-Access#show pol int g 0/2

service-policy input: ACCESS-C3550-LAN-EDGE-IN

class-map: VOICE-CONTROL (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: access-group name VOICE-CONTROL


956467


class-map: VOICE (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: access-group name VOICE

class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: any 0 packets, 0 bytes 5 minute rate 0 bps

Voice over IP Call ControlThe current release of Cisco CallManager includes the ability to configure the CoS and ToS values for all VoIP control and management traffic from CallManager, the IP phones, H.323, Skinny Protocol, and MGCP gateways. With this user-configurable classification, network element access lists are no longer required to mark VoIP control traffic. However, some network managers may choose to enforce policy at the edge of their network and not trust the markings that end devices provide. The following configuration example uses a Catalyst 6500 with Multilayer Switch Feature Card 2 (MSFC2) and Policy Feature Card (PFC2) and Catalyst Operating System (Catalyst OS). In this example, the switch recognizes and classifies VoIP control traffic upon ingress to the network.

Skinny Protocol

Cisco CallManager communicates with IP phones and gateways using TCP ports 2000-2002. The example below marks all Skinny Protocol traffic from IP phones and gateways (VLAN 110) and Cisco CallManager (4/2) with a DSCP of AF31, which is backwardly compatible with IP Precedence 3.


cat6k-access> (enable) set qos enable

Step 2 Create an ACL (ACL_IP-PHONES) to mark all Skinny Client and Gateway Protocol traffic from the IP phones and from Skinny Protocol gateways with a DSCP value of AF31 (decimal of 26).

cat6k-access> (enable) set qos acl ip ACL_IP-PHONES dscp 26 tcp any any range 2000 2002

Step 3 Add an entry to the ACL_IP-PHONE access list to trust all DSCP markings from the IP phone so that the RTP traffic with ToS of is not rewritten.

cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos ip any any

Step 4 Create an ACL (ACL_VOIP_CONTROL) to mark all Skinny Client and Gateway Protocol traffic from Cisco CallManager with a DSCP value of AF31.

cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any range 2000 2002

Step 5 Accept incoming Layer 2 CoS classification.

cat6k-access> (enable) set port qos 5/1-48 trust trust-cos

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

cat6k-access> (enable) set port qos 5/1-48 vlan-based


956467


Step 7 Instruct the IP phone to rewrite CoS from the PC to CoS of 0 within the IP phone Ethernet ASIC.

cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted

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

cat6k-access> (enable) set port qos 4/2 port-based

Step 9 Write the ACL to hardware.

cat6k-access> (enable) commit qos acl all

Step 10 Map the ACL_IP-PHONE ACL to the auxiliary VLAN.

cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110

Step 11 Map the ACL_VOIP_CONTROL ACL to the Cisco CallManager port.

cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2

H.323 Protocol

Cisco CallManager communicates with H.323 gateways using TCP ports 1720 (H.225) and 11xxx (H.245). The example below marks H.323 control traffic from Cisco CallManager (4/2) and from H.323 gateways (4/3) with a DSCP of AF31.

Step 1 Add entries to the ACL_VOIP_CONTROL access list to mark all traffic from H.323 gateways with a DSCP value of AF31.

cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any eq 1720cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any range 11000 11999



Step 3 Inform the Cisco H.323 gateway port (4/3) that all QoS associated with the port will be done on a port basis



cat6k-access> (enable) commit qos acl ACL_VOIP_CONTROL

Step 5 Map the ACL_VOIP_CONTROL ACL to the Cisco CallManager port and the H.323 gateway port.

cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/3

MGCP

Cisco CallManager communicates with MGCP gateways using User Datagram Protocol (UDP) port 2427. The example below classifies MGCP control traffic from Cisco CallManager (4/2) and from the MGCP gateway (4/4) as DSCP AF31, which is backward compatible with IP Precedence 3.


956467


Step 1 Add an entry to the ACL_VOIP_CONTROL access list to marking all traffic from MGCP gateways with a DSCP value of AF31.

cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 udp any any eq 2427



Step 3 Inform the Cisco MGCP gateway port (4/4) that all QoS associated with the port will be done on a port basis



cat6k-access> (enable) commit qos acl ACL_VOIP_CONTROL

Step 5 Map the ACL_VOIP_CONTROL ACL to the Cisco CallManager port and the MGCP gateway port.

cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/4

Verifying the ACLs

Use the following show command and its associated output for verifying that the ACLs are associated with the correct VLANs and ports.

cat6k-access> (enable) sh qos acl map run all

ACL name Type Vlans-------------------------------- ---- -------------------------------ACL_IP-PHONES IP 110,111,112 ACL name Type Ports-------------------------------- ---- -------------------------------ACL_IP-PHONES IP

ACL name Type Vlans-------------------------------- ---- -------------------------------ACL_VOIP_CONTROL IP ACL name Type Ports-------------------------------- ---- -------------------------------ACL_VOIP_CONTROL IP 4/2,4/3,4/4

Mission-Critical DataAs discussed earlier, the classification of any type of traffic as mission-critical could be a controversial move. Take care when classifying mission-critical data.

The following configuration example uses a Catalyst 4006 with Supervisor III. In this example, the switch marks IP traffic to and from a specific TCP/IP address with a DSCP of AF21.


4006-SUPIII-Access(config)#qos


956467



4006-SUPIII-Access#show qosQoS is enabled globally

Step 2 The default CoS-to-DSCP maps must be modified to allow us to trust CoS and maintain DSCP EF and AF31 for VoIP bearer and control traffic respectively.

4006-SUPIII-Access#show qos map cosCoS-DSCP Mapping Table CoS: 0 1 2 3 4 5 6 7 -------------------------------- DSCP: 0 8 16 24 32 40 48 56

Change the default CoS-to-DSCP mapping so that CoS 5 equates to EF, CoS 3 equates to AF31, and CoS 4 equates to AF41.

4006-SUPIII-Access(config)#qos map cos 3 to dscp 264006-SUPIII-Access(config)#qos map cos 4 to dscp 344006-SUPIII-Access(config)#qos map cos 5 to dscp 46



4006-SUPIII-Access#show qos map dscp tx-queue DSCP-TxQueue Mapping Table (dscp = d1d2)d1 : d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 02 02 02 02 2 : 02 02 02 02 02 02 02 02 02 02 3 : 02 02 03 03 03 03 03 03 03 03 4 : 03 03 03 03 03 03 03 03 04 04 5 : 04 04 04 04 04 04 04 04 04 04 6 : 04 04 04 04

Step 3 Turn on priority queuing. The default admission to the priority queue is sufficient for our requirements.

4006-SUPIII-Access(config-if-tx-queue)#tx-queue 34006-SUPIII-Access(config-if-tx-queue)#priority high


4006-SUPIII-Access#show qos inter fa 3/4QoS is enabled globallyPort QoS is enabledPort Trust State: 'untrusted'Default DSCP: 0 Default CoS: 0Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 N/A disabled N/A 240 2 N/A disabled N/A 240 3 N/A disabled high 240 4 N/A disabled N/A 240


956467

Chapter 3 QoS in an AVVID-Enabled Campus NetworkSelecting an Access-Layer Switch

Step 4 Create an ACL to identify the traffic to be marked.

4006-SUPIII-Access(config)#ip access-list extended GOLD-DATA4006-SUPIII-Access(config-ext-nacl)#remark Match IP Address of the application server4006-SUPIII-Access(config-ext-nacl)#permit ip any host 192.168.100.14006-SUPIII-Access(config-ext-nacl)#permit ip host 192.168.100.1 any

Step 5 Create classes that use the ACL as admission criteria.

4006-SUPIII-Access(config)#class-map match-all GOLD-DATA4006-SUPIII-Access(config-cmap)#description Mission Critical Traffic4006-SUPIII-Access(config-cmap)#match access-group name GOLD-DATA

Step 6 Create a service policy that uses the classes for admission criteria and sets the appropriate DSCP label.

4006-SUPIII-Access(config)#policy-map ACCESS-C4006-LAN-EDGE-IN4006-SUPIII-Access(config-pmap)#description Set DSCP PerHopBehavior Label for Mission Critical Traffic4006-SUPIII-Access(config-pmap)#class GOLD-DATA4006-SUPIII-Access(config-pmap-c)#set ip dscp 18

Step 7 Apply the service policy to an interface.

4006-SUPIII-Access#ctEnter configuration commands, one per line. End with CNTL/Z.4006-SUPIII-Access(config)#int fa 3/44006-SUPIII-Access(config-if)#service-policy input ACCESS-C4006-LAN-EDGE-IN


4006-SUPIII-Access#show pol int fa 3/4


class-map: GOLD-DATA (match-all) 0 packets match: access-group name GOLD-DATA set: ip dscp 18

class-map: class-default (match-any) 0 packets match: any 0 packets

Selecting an Access-Layer SwitchThe Cisco portfolio of Catalyst switches offers a rich selection of access-layer devices. There are many criteria involved when selecting a device for this layer of your network. When AVVID solutions are involved, there is a base set of features required to support IP telephony, which is a major component of the AVVID solution.

• The switch must support multiple VLANs on the access port to which the IP phone is attached. This is currently supported via the voice VLAN command for IOS-based switches and the auxiliary VLAN command for Catalyst OS-based switches.

• The switch must be able to manipulate the IP phones trust boundary and marking capabilities. This functionality is supported via the switchport priority command in IOS-based switches and the trust-ext command in Catalyst OS-based switches.


956467


• The switch must be able trust the CoS or DSCP marking that the IP phones provide. This is currently supported via the mls QoS trust CoS and mls QoS trust DSCP commands for IOS-based switches and the trust-CoS and trust-DSCP commands for Catalyst OS-based switches.

As mentioned before (in the “Server Farm Switch Selection” section on page 3-6), there are times when the devices attached to an AVVID network do not classify their traffic with the appropriate Layer 2 and Layer 3 markings. When considering your choices for access-layer devices, consider the switch’s ability to classify and mark traffic at the edge of the network via ACLs and service policies. This will allow QoS to be offered as a service throughout the network and administered at the edge of the network where CPU resources are plentiful, rather than at the distribution and core aggregation points where enforcement of QoS classification and marking could adversely affect network performance.

Catalyst 6500 as an Access-Layer SwitchOne of the most popular campus configurations for Cisco AVVID solutions is to use Catalyst 6500 switches in both the wiring closet and the distribution and core layers. There are several compelling reasons for this:

• The Catalyst 6500 supports dual supervisor engines providing the highest availability of access solutions.

• The Catalyst 6500 can provide in-line power to the IP phones. The current 10/100 boards for the Catalyst 6500 support integrated inline power and are standard.

• The Catalyst 6500 offers the highest growth potential.

• The Catalyst 6500 supports advanced Layer 2/3 campus QoS tools.

Figure 3-6 shows a general model for the Catalyst 6500 as an access device (as illustrated in the QoS configurations discussed in this chapter).


956467


Figure 3-6 General Model for Catalyst 6500 QoS Configurations

With the addition of the PFC, the Catalyst 6500 is capable of handling Layer 2, 3, and 4 QoS tasks. The PFC can be used to enable advanced QoS tools, such as packet classification and marking, scheduling, and congestion avoidance, based on either Layer 2 or Layer 3 and 4 header information. You can configure multiple receive and transmit queues with thresholds that can be used according to the QoS policy rules configured in the switch.

There are also many versions of Catalyst 6500 line cards with varying QoS capabilities. (See Appendix A, “Reference Information” for a list of linecards and queuing mechanisms available for the Catalyst 6500.) The newest cards include enhanced QoS features that provide priority queuing capabilities for both ingress and egress interfaces. With the exception of the priority queue, which is always serviced as soon as frames are present, the queues are serviced in the WRR method. Each queue is given a user-configurable weight. By default, the “high” queue is given 98% of the scheduler time and the “low” queue is given 2%. This ratio is conducive to ensuring that packets with a low delay-tolerance are not delayed in a queue. This is also the reason behind giving the “low” queue a much higher percentage of the overall interface buffer.

Note Because the Catalyst OS is designed for switches that operate in the “closet” and Native IOS is designed for switches that operate at the distribution layer of the network, a Catalyst 6500 that is functioning as an access-switch should be equipped with Catalyst OS.

To see how a port is configured, issue the show port capabilities mod/port Catalyst OS command. The default QoS capabilities of the port can be changed using the set qos map and set qos wred-threshold commands. When modifying the queue thresholds, it is important to remember that the higher priority queue has a higher numerical value.

Si

Si Si

IP

VVID=110

VLAN=10

Core

Distribution

Access

Catalyst6500

Catalyst 6500 w/ PFC

7469

7


956467


After you have connected the IP phone to the access-layer switch, it is time to configure the QoS parameters on the switch. This includes setting up multiple queues on all ports, configuring access to the queues, setting thresholds for congestions avoidance, and connecting the switch to the distribution or core layer.

For the Catalyst 6500, QoS requires the following changes to the configuration of the access switch:

1. Enable switch-wide QoS.

2. Configure the IP phone port queuing.

3. Configure the uplink interface to the distribution switch, including enabling trust for Ethernet frames coming into the trunk port, manipulating the CoS-to-queue mapping entrance criteria, and mapping the CoS and IP Precedence values to the appropriate DSCP value.

Enabling QoS

To enable QoS on the access-layer Catalyst 6500, do the following:


cat6k-access> (enable) set qos enable

Configuring IP Phone Port Queuing

If you use a single cable to connect an IP phone, the access port is configured to trust the IP phone and not the attached PC. The port is also configured to use multiple transmit queues, one being a priority queue for voice traffic.

Figure 3-7 Connecting an IP phone to a Catalyst 6500

To configure IP phone port queuing, do the following:

Step 1 Inform the port that all QoS associated with the port will be done on a VLAN basis.

cat6k-access> (enable) set port qos 5/1-48 vlan-based

Step 2 Instruct the IP phone to rewrite CoS from the PC to CoS of 0 within the IP phone Ethernet ASIC.

cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted

Step 3 Accept incoming Layer 2 CoS classification. (Current 10/100 version “1” linecards must still have trust-cos enabled even though the parser returns an error.)

cat6k-access> (enable) set port qos 5/1-48 trust trust-cos

Step 4 Create an access list that accepts incoming Layer 3 ToS classification (necessary only on 10/100 ports).

cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos any

IP

7469

8Catalyst 6500w/ PFC

IP Phone = IPSubnet 110

Auxilary VLAN = 110 PC VLAN = 10

Desktop PC:IP Subnet 10


956467



cat6k-access> (enable) commit qos acl ACL_IP-PHONES

Step 6 Map the access list to the Auxiliary VLAN.

cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110

Once QoS has been enabled on the Catalyst 6500 access-layer switch, you can use the following command to place all traffic with a CoS of 3 (VoIP control) into the second transmit queue (with a low drop threshold), to ensure successful call control during periods of heavy congestion. All traffic with a CoS of 5 (VoIP RTP Bearer) is placed into the second queue by default.

cat6k-access> (enable) set qos map 2q2t tx 2 1 cos 3

Configuring the Uplink to the Distribution Switch

Once you have configured the access port queuing, you must also configure the uplink interfaces to the distribution, or core, switch. This involves enabling trust for Ethernet frames coming into the trunk port (1/1 in this example), manipulating the CoS-to-queue mapping entrance criteria, and mapping the CoS and IP Precedence values to the appropriate DSCP value.

Configuring Transmit Queues

All VoIP (CoS of 5) traffic will be placed into the egress interface priority queue on 1p2q2t interfaces and queue 2 on 2q2t interfaces as soon as you enable QoS. However, you must perform the additional step of configuring the Catalyst 6500 CoS queue admission rules to ensure that traffic with a CoS of 3 (VoIP control) is placed into the second queue.

Step 1 Place CoS of 3 in queue 2 for 1p2q2t.

cat6k-access> (enable) set qos map 1p2q2t tx 2 1 cos 3

Step 2 Place CoS of 3 in queue 2 for 2q2t.

cat6k-access> (enable) set qos map 2q2t tx 2 1 cos 3

Modifying CoS-to DSCP and IP Precedence-to-DSCP Mappings

Cisco follows the IETF recommendations for setting the DSCP classification values for both the VoIP control plane traffic and VoIP bearer or media plane traffic. The recommended settings are DSCP of AF31 for VoIP control plane and DSCP of EF for VoIP bearer plane. To map the Layer 2 CoS and Layer 3 IP Precedence settings correctly to these DSCP values, you must modify the default CoS/IP Precedence-to-DSCP mappings.

Step 1 Modify the CoS-to-DSCP mappings.

cat6k-access> (enable) set qos cos-dscp-map 0 8 16 26 34 46 48 56

Step 2 Modify the IP Precedence-to-DSCP mappings.

cat6k-access> (enable) set qos ipprec-dscp-map 0 8 16 26 34 46 48 56


956467


Verifying the Configuration

One of the fundamental processes of implementing QoS is verifying that the configurations are correct and are performing as expected. On the Catalyst 6500 access-layer switch, you can verify the configuration and performance during periods of high congestion by examining the output of the following commands:

Example 3-1 Displaying QoS Settings for a Port

cat6k-access> (enable) show port qos 5/1QoS is enabled for the switchQoS policy source for the switch set to local.

Port Interface Type Interface Type Policy Source Policy Source config runtime config runtime----- -------------- -------------- ------------- ------------- 5/1 vlan-based vlan-based COPS local

Port TxPort Type RxPort Type Trust Type Trust Type Def CoS Def CoS config runtime config runtime----- ------------ ------------ ------------ ------------- ------- ------- 5/1 2q2t 1q4t trust-cos trust-cos* 0 0

Port Ext-Trust Ext-Cos----- --------- ------- 5/1 untrusted 0

(*)Runtime trust type set to untrusted.

Config:Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 5/1.ACL is mapped to VLAN Runtime:Port ACL name Type----- -------------------------------- ----No ACL is mapped to port 5/1.

Command Description See

show port qos mod/port Displays the QoS settings for the specified port.

Example 3-1

show qos info runtime mod/port Displays QoS runtime information for the specified port.

Example 3-2

show mac mod/port Displays Media Access Control TX ringMAC) information for the specified port.

Example 3-3

show qos statistics l3 Displays summary QoS statistics for all ports. Example 3-4

show qos stat mod/port Displays detailed QoS statistics for the specified port.

Example 3-5

show qos map run cos-dscp-map Displays the CoS-to-DSCP mappings. Example 3-6

show qos map run ipprec-dscp-map

Displays the IP Precedence-to-DSCP mappings.

Example 3-7


956467


Example 3-2 Displaying QoS Runtime Information

cat6k-access>(enable) show qos info run 5/1Run time setting of QoS:QoS is enabledPolicy Source of port 5/1: LocalCurrent 10/100 "1" linecards support 2q2t/1q4t onlyTx port type of port 5/1 : 2q2t Rx port type of port 5/1 : 1q4tInterface type: vlan-basedACL is mapped to VLANACL attached: The qos trust type is set to trust-cos.Warning: Runtime trust type set to untrusted.Default CoS = 0 Queue and Threshold Mapping for 2q2t (tx):Queue Threshold CoS ----- --------- ---------------1 1 0 1 1 2 2 2 1 3 4 5 2 2 6 7 Queue and Threshold Mapping for 1q4t (rx):Queue Threshold CoS ----- --------- ---------------1 1 0 1 1 2 2 1 3 3 4 5 1 4 6 7

Example 3-3 Displaying MAC Information

cat6k-access> (enable) show mac 5/1

Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast-------- -------------------- -------------------- -------------------- 5/1 267223 37 4

Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast-------- -------------------- -------------------- -------------------- 5/1 28748894 5206 72

Port Rcv-Octet Xmit-Octet-------- -------------------- -------------------- 5/1 17178128 1840430081

"Out-Discards" are packets drooped due to congestion in the tx interface buffersMAC Dely-Exced MTU-Exced In-Discard Out-Discard-------- ---------- ---------- ---------- ----------- 5/1 0 0 0 262140

Example 3-4 Displaying QoS Summary Statistics

cat6k-access> (enable) show qos stat l3VoIP Control packets that have been re-written with CoS=3/DSCP=26 (AF31)Packets dropped due to policing: 0IP packets with ToS changed: 1885IP packets with CoS changed: 781Non-IP packets with CoS changed: 0


956467


Example 3-5 Displaying QoS Detailed Statistics

cat6k-access> (enable) show qos stat 5/1All packets dropped are in the 1st drop threshold of queue #1Tx port type of port 5/1 : 2q2tQ # Threshold #:Packets dropped--- -----------------------------------------------1 1:393210 pkts, 2:0 pkts2 1:0 pkts, 2:0 pktsRx port type of port 5/1 : 1q4tQ # Threshold #:Packets dropped--- -----------------------------------------------1 1:0 pkts, 2:0 pkts, 3:0 pkts, 4:0 pkts

Example 3-6 Displaying CoS-to-DSCP Mappings

cat6k-access> (enable) show qos map run cos-dscp-map CoS - DSCP map:CoS DSCP--- ---- 0 0 1 8 2 16 3 26 26 = AF31 Voice Control 4 34 34 = AF41 IP Video Conferencing 5 46 46 = EF Voice Bearer 6 48 7 56

Example 3-7 Displaying IP Precedence-to-DSCP Mappings

cat6k-access> (enable) show qos map run ipprec-dscp-map IP-Precedence - DSCP map:IP-Prec DSCP------- ---- 0 0 1 8 2 16 3 26 26 = AF31 Voice Control 4 34 34 = AF41 IP Video Conferencing 5 46 46 = EF Voice Bearer 6 48 7 56

Catalyst 4000 as an Access-Layer Switch Another popular campus configuration for Cisco AVVID networks uses the Catalyst 2948G, the Catalyst 2980G, and the Catalyst 4000 family of switches in the wiring closets.

There are several compelling reasons for this, including:

• The Catalyst 4006 can provide in-line power to the IP phones.

• The Catalyst 4000 offers a very low price per port.

• These switches provide extremely scalable, high-speed switching.

Starting with Catalyst OS Release 5.2, the Catalyst 4000 switches support dual-transmit queues on every interface. Admission to the queues is based on Layer 2 CoS markings and is configurable in 802.1p user priority pairs.


956467


Note From a configuration perspective, the Catalyst 2948G, the Catalyst 2980G, and the Catalyst 4000 family of switches are the same. Therefore, the configuration of only one, the Catalyst 4000, is shown in this section.

Catalyst 4000 with Supervisor III

The Catalyst 4000 Supervisor III introduces many enhanced QoS features to the Catalyst 4000, including four queues per port with a configurable priority queue.

Figure 3-8 shows a general model for the Catalyst 4000 with Supervisor III as an access device (as illustrated in the QoS configurations discussed in this chapter).

Figure 3-8 General Model for Catalyst 4000 with Supervisor III QoS Configurations

This section presents suggested configurations for port scheduling and queuing on the Catalyst 4000 with Supervisor III. In general:

• The recommended configuration for the receive interface is FIFO—one standard FIFO queue.

• The recommended configuration for the transmit interface is 1P3Q1T—one priority queue (when configured) and three queues with a single threshold. Scheduling is done on a WRR basis. Admission to the queues is based on IP DSCP value and is user configurable.

Si

Si Si

IP

VVID=111

VLAN=11

Core

Distribution

Access

Catalyst6500

Catalyst 4000

7469

9


956467


For the Catalyst 4000 with Supervisor III, QoS requires the following changes to the configuration of the access switch:

1. Enable QoS globally.

2. Modify the default CoS-to-DSCP mapping so that CoS 3 = AF31, CoS 4 = AF41, and CoS 5 = EF.

3. Enable priority queuing (per port). The default admission criteria for the priority queue matches our requirements.

4. Configure an ACL to identify traffic to be marked, associate it with a service policy, and apply the service policy to the interface.

5. Configure a port to support an IP phone.

6. Configure uplink scheduling and trust (CoS or DSCP).

Enabling QoS

To enable QoS on the access-layer Catalyst 4000 with Supervisor III, do the following:


4006-SUPIII-Access(config)#qos

Modifying the CoS-to-DSCP Mappings

There are 8 CoS labels and 64 possible DSCP labels. To trust the CoS markings, the default CoS-to-DSCP mapping table must be modified to equate CoS 3 (VoIP control traffic) to AF31, CoS 5 (VoIP bearer traffic) to EF, and CoS 4 (video conferencing) to AF41.

Step 1 The default CoS-to-DSCP mappings are as follows:


Change the default mapping table so that CoS 3 = AF31, CoS 4 = AF41, and CoS 5 = EF. Remember to use the decimal equivalents.

4006-SUPIII-Access(config)#qos map cos 3 to dscp 264006-SUPIII-Access(config)#qos map cos 4 to dscp 344006-SUPIII-Access(config)#qos map cos 5 to dscp 46

Enabling Priority Queuing

To enable priority queuing, do the following:

Note In the Catalyst 4000 with Supervisor III, only queue number 3 can be enabled for priority queuing.


956467


Step 1 Specify the transmit queue.

4006-SUPIII-Access(config-if-tx-queue)#tx-queue 3

Step 2 Set the priority to high.

4006-SUPIII-Access(config-if-tx-queue)#priority high

Configuring ACLs

There are times when classification of traffic by the access-layer switch is required. The Catalyst 4000 with Supervisor III has a powerful set of features that allow traffic to be classified as it enters the network.

To classify VoIP bearer and control traffic as it enters the network, do the following:

Step 1 Create an ACL to match the traffic to be prioritized.

4006-SUPIII-Access(config)#ip access-list extended GOLD-DATA4006-SUPIII-Access(config-ext-nacl)#remark Match IP Address of the application server4006-SUPIII-Access(config-ext-nacl)#permit ip any host 192.168.100.14006-SUPIII-Access(config-ext-nacl)#permit ip host 192.168.100.1 any4006-SUPIII-Access(config)#ip access-list extended VOICE4006-SUPIII-Access(config-ext-nacl)#remark Match the UDP ports that VoIP Uses for Bearer Traffic4006-SUPIII-Access(config-ext-nacl)#permit udp any any range 16384 327674006-SUPIII-Access(config)#ip access-list extended VOICE-CONTROL4006-SUPIII-Access(config-ext-nacl)#remark Match VoIP Control Traffic4006-SUPIII-Access(config-ext-nacl)#remark SCCP4006-SUPIII-Access(config-ext-nacl)#permit tcp any any range 2000 20024006-SUPIII-Access(config-ext-nacl)#remark H323 Fast Start4006-SUPIII-Access(config-ext-nacl)#permit tcp any any eq 17204006-SUPIII-Access(config-ext-nacl)#remark H323 Slow Start4006-SUPIII-Access(config-ext-nacl)#permit tcp any any range 11000 119994006-SUPIII-Access(config-ext-nacl)#remark H323 MGCP4006-SUPIII-Access(config-ext-nacl)#permit udp any any eq 2427

Step 2 Create classes based on the ACL.

4006-SUPIII-Access(config)#class-map match-all GOLD-DATA4006-SUPIII-Access(config-cmap)#description Mission Critical Traffic4006-SUPIII-Access(config-cmap)#match access-group name GOLD-DATA4006-SUPIII-Access(config)#class-map match-all VOICE4006-SUPIII-Access(config-cmap)#description VoIP Bearer Traffic4006-SUPIII-Access(config-cmap)#match access-group name VOICE4006-SUPIII-Access(config)#class-map match-all VOICE-CONTROL4006-SUPIII-Access(config-cmap)#description VoIP Control Traffic (SCCP, H225, H254, MGCP)4006-SUPIII-Access(config-cmap)#match access-group name VOICE-CONTROL

Step 3 Create a policy to set the DSCP PHB label for the classes.

4006-SUPIII-Access(config)#policy-map ACCESS-C4006-LAN-EDGE-IN4006-SUPIII-Access(config-pmap)#description Set DSCP PerHopBehavior Label for VOIP Control and Bearer Traffic4006-SUPIII-Access(config-pmap)#class VOICE-CONTROL4006-SUPIII-Access(config-pmap-c)#set ip dscp 264006-SUPIII-Access(config-pmap)#class VOICE4006-SUPIII-Access(config-pmap-c)#set ip dscp 464006-SUPIII-Access(config-pmap)#class GOLD-DATA4006-SUPIII-Access(config-pmap-c)#set ip dscp 18


956467


Step 4 Apply the policy to a physical interface.

4006-SUPIII-Access(config)#int fa 4/14006-SUPIII-Access(config-if)#service-policy input ACCESS-C4006-LAN-EDGE-IN

Configuring Access-Layer Phone Support

When the Catalyst 4000 with Supervisor III is connected to an IP phone, do the following:

Step 1 Configure the switch to trust CoS from the IP Phone.

4006-SUPIII-Access(config)#int fa 4/54006-SUPIII-Access(config-if)#qos trust cos

Step 2 Enable the voice and data VLANs.

4006-SUPIII-Access(config-if)#switchport voice vlan 1114006-SUPIII-Access(config-if)#switchport access vlan 11

Step 3 Set the IP Phones trust boundary.

4006-SUPIII-Access(config-if)#switchport priority extend cos 0

Step 4 While in interface configuration mode, enable priority queueing on the port.

Note In the Catalyst 4000 with Supervisor III, only queue number 3 can be enabled for priority queuing.

4006-SUPI(config-if-tx-queue)#tx-queue 34006-SUPI(config-if-tx-queue)#priority high


The ports attached to the distribution layer require a slightly different configuration. These ports must be configured to trust DSCP or CoS depending on the capabilities of the distribution-layer switch attached. In the following configuration, port 3/1 is attached to a Layer 3-aware distribution device and can trust DSCP arriving from it. Port 3/2 illustrates an example where CoS-only classification is used.

Note The system-wide CoS-to-DSCP mapping and DSCP-to-queue admission criteria configurations must have been completed and the priority queue must be enabled for these ports in order for the access-layer uplink ports to perform QoS as expected.

Step 1 Configure DSCP trust.

4006-SUPIII-Access(config)#int g 3/14006-SUPIII-Access(config-if)#qos trust dscp

Step 2 Enable the priority queue on this interface.



956467


Step 3 Configure CoS trust.

4006-SUPIII-Access(config-if)#int g 3/2 4006-SUPIII-Access(config-if)#qos trust cos

Step 4 Enable the priority queue on this interface.



On the Catalyst 4000 access-layer switch, you can verify the configuration and performance during periods of high congestion by examining the output of the following commands:

Example 3-8 Displaying QoS CoS Mapping Information


Example 3-9 Displaying QoS DSCP Mapping Information

4006-SUPIII-Access#show qos map dscp tx-queue DSCP-TxQueue Mapping Table (dscp = d1d2)d1 : d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 02 02 02 02 2 : 02 02 02 02 02 02 02 02 02 02 3 : 02 02 03 03 03 03 03 03 03 03 4 : 03 03 03 03 03 03 03 03 04 04 5 : 04 04 04 04 04 04 04 04 04 04 6 : 04 04 04 04


show qos map cos Displays the QoS CoS mapping information. Example 3-8

show qos map dscp Displays the QoS DSCP mapping information. Example 3-9

show qos interface interface Displays QoS queuing information. Example 3-10

show policy-map interface Displays statistics and configurations of input and output policies attached to an interface.

Example 3-11

show interface counters Displays statistics regarding traffic seen on the physical interface.

Example 3-12


956467


Example 3-10 Displaying QoS Queuing Information

4006-SUPIII-Access#show qos interface fa 4/1QoS is enabled globallyPort QoS is enabledPort Trust State: 'untrusted'Default DSCP: 0 Default CoS: 0Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 N/A disabled N/A 240 2 N/A disabled N/A 240 3 N/A disabled high 240 4 N/A disabled N/A 240

4006-SUPIII-Access#show qos int g 3/1QoS is enabled globallyPort QoS is enabledPort Trust State: 'dscp'Default DSCP: 0 Default CoS: 0Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 250000000 disabled N/A 1920 2 250000000 disabled N/A 1920 3 250000000 disabled high 1920 4 250000000 disabled N/A 1920

4006-SUPIII-Access#show qos int g 3/2QoS is enabled globallyPort QoS is enabledPort Trust State: 'cos'Default DSCP: 0 Default CoS: 0Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 250000000 disabled N/A 1920 2 250000000 disabled N/A 1920 3 250000000 disabled high 1920 4 250000000 disabled N/A 1920

Example 3-11 Displaying Policy Information

4006-SUPIII-Access#show policy-map interface fa 4/1



class-map: VOICE-CONTROL (match-all) 0 packets match: access-group name VOICE-CONTROL set: ip dscp 26

class-map: VOICE (match-all) 0 packets match: access-group name VOICE set: ip dscp 46


956467



Example 3-12 Displaying Traffic Statistics

4006-SUPIII-Access#show int g3/2 count all

Port InBytes InUcastPkts InMcastPkts InBcastPktsGi3/2 0 0 0 0

Port OutBytes OutUcastPkts OutMcastPkts OutBcastPktsGi3/2 0 0 0 0

Port InPkts 64 OutPkts 64 InPkts 65-127 OutPkts 65-127Gi3/2 0 0 0 0

Port InPkts 128-255 OutPkts 128-255 InPkts 256-511 OutPkts 256-511Gi3/2 0 0 0 0

Port InPkts 512-1023 OutPkts 512-1023Gi3/2 0 0


Port InPkts 1024-1522 OutPkts 1024-1522 InPkts 1523-1548 OutPkts 1523-1548Gi3/2 N/A N/A N/A N/A

Port InPkts 1549-9216 OutPkts 1549-9216 Port InPkts 1549-9216 OutPkts 1549-9216Gi3/2 0 0

Port Tx-Bytes-Queue-1 Tx-Bytes-Queue-2 Tx-Bytes-Queue-3 Tx-Bytes-Queue-4Gi3/2 0 0 0 0

Port Tx-Drops-Queue-1 Tx-Drops-Queue-2 Tx-Drops-Queue-3 Tx-Drops-Queue-4Gi3/2 0 0 0 0

Port Rx-No-Pkt-Buff RxPauseFrames TxPauseFrames PauseFramesDropGi3/2 0 0 0 0

Port UnsupOpcodePauseGi3/2 0

Port CrcAlign-Err TxCrc-Err Collisions Symbol-ErrGi3/2 0 0 0 0

Port Undersize Oversize Fragments JabbersGi3/2 0 0 0 0

Port Single-Col Multi-Col Late-Col Excess-ColGi3/2 0 0 0 0

Port Deferred-Col False-Car Carri-Sen Sequence-ErrGi3/2 0 0 0 0

Port RxIslTagFrames TxIslTagFrames RxDot1qTagFrames TxDot1qTagFramesGi3/2 0 0 0 0


956467


Port RxMacFifoOverrun RxMacFifoUnderrun RxCdmFifoOverrun TxCsmFifoUnderrunGi3/2 0 0 0 0

Port NoPBA/CdmFifoOverunGi3/2 0

Catalyst 4000 with Supervisor II

Figure 3-9 shows a general model for the Catalyst 4000 with Supervisor II as an access device (as illustrated in the QoS configurations discussed in this chapter).

Figure 3-9 General Model for Catalyst 4000 with Supervisor II QoS Configurations

This section presents suggested configurations for port scheduling and queuing on the Catalyst 4000 with Supervisor II. In general:

• The recommended configuration for the receive interface is 1Q-FIFO—one standard FIFO queue.

• The recommended configuration for the transmit interface is 2Q1T—two standard queues with a single threshold. Scheduling is on a round-robin basis. Admission to the queues is based on 802.1p CoS value and is user configurable in pairs. If you enable QoS but do not modify the CoS-to-transmit queue mappings, switch performance could be affected because all traffic is assigned to queue 1. Once QoS is enabled on the Catalyst 4000, you must change the CoS mappings to use the newly created queue.

• The default queue admission criteria for the Catalyst 4000 is: CoS 0 through 7 goes to queue 1, all other (broadcast, multicast, and unknown) traffic goes to queue 2.

Si

Si Si

IP

VVID=111

VLAN=11

Core

Distribution

Access

Catalyst6500

Catalyst 400074

700


956467


For the Catalyst 4000 with Supervisor II, QoS requires the following changes to the configuration of the access switch:


2. Verify the queue admission configuration.


4. Configure the uplink to the distribution switch.

Enabling QoS

By default, only one queue is enabled on the Catalyst 4000 line of switches. To enable the second queue, use the set qos map command. VoIP Control (CoS of 3) frames should be placed into the second queue. These maps must be configured in pairs of CoS values because the Catalyst 4000 examines only the first two CoS bits. To enable QoS and establish the second queue, do the following.

Step 1 Enable QoS.

cat4k> (enable) set qos enable

Step 2 Map the CoS categories to the queues.

cat4k> (enable) set qos map 2q1t 1 1 cos 0-1cat4k> (enable) set qos map 2q1t 2 1 cos 2-3cat4k> (enable) set qos map 2q1t 2 1 cos 4-5cat4k> (enable) set qos map 2q1t 2 1 cos 6-7

Verifying Queue Admission Configuration

To verify the queue admission configuration on the Catalyst 4000, use the following command (shown with its associated output):

cat4k> (enable) show qos info runtimeRun time setting of QoS:QoS is enabledAll ports have 2 transmit queues with 1 drop thresholds (2q1t).Default CoS = 0 Queue and Threshold Mapping:Queue Threshold CoS----- --------- ---------------1 1 0 1 2 1 2 3 4 5 6 7


In the Catalyst OS Release 5.5.1, the Catalyst 4000 line does not offer any advanced IP phone queuing features. Because of this, the Catalyst 4000 depends on the default CoS marking and enforcement on the IP phone.

Configuring the Uplink Interface to the Distribution Switch

Queuing is automatically enabled when QoS is been enabled and classification and queue admission have been configured. Therefore, no special queuing or scheduling commands need to be configured on the Catalyst 4000 side of the link (from the access-layer Catalyst 4000 to the distribution-layer Catalyst 6500).


956467


If you are using the Catalyst 4000 with the Layer 3 engine (the WS-X4232), which enables IP, IPX, and Multicast routing for the switch, you can perform additional uplink configuration. The Layer 3 engine allows the Catalyst 4000 to support four standard transmit queues with a single threshold on the two-gigabit uplinks. The four queues are scheduled using a user-configurable WRR algorithm. Admission to the queues is based on 802.1p CoS value and is user-configurable in pairs.

To enable QoS and change CoS mappings to use the newly created queues, do the following:

Step 1 Enable QoS

cat4k> (enable) set qos enable

Step 2 Map the CoS categories to each of the queues.

cat4k> (enable) set qos map 4q1t 1 1 cos 6-7cat4k> (enable) set qos map 4q1t 2 1 cos 4-5cat4k> (enable) set qos map 4q1t 3 1 cos 2-3cat4k> (enable) set qos map 4q1t 4 1 cos 0-1

Note that the Layer 3 queue numbering is the reverse of the Layer 2 numbering.

Catalyst 3524-PWR XL as an Access-Layer SwitchFigure 3-10 shows a general model for the Catalyst 3524-PWR XL as an access device (as illustrated in the QoS configurations discussed in this chapter).

Figure 3-10 General Model for Catalyst 3524-PWR XL QoS Configurations

Si

Si

IP

VVID=112

VLAN=12

Core

Distribution

Access

Catalyst6500

Catalyst 3524-PWR

7470

1

Si


956467


This section presents suggested configurations for port scheduling and queuing on the Catalyst 3524-PWR XL. In general:


• The recommended configuration for the 10/100 transmit interface is 2Q1T—two standard queues with a single threshold. Scheduling is done on a priority-scheduling basis. Admission to the queues is based on 802.1p CoS or port priority CoS value and is not user configurable. The queue admission criteria for the Catalyst 3500 are as follows: queue1: CoS 0 through 3, queue 2: CoS 4 through 7.

• The recommended configuration for the gigabit Ethernet transmit interface is 8Q-FIFO—eight standard queues with a single drop threshold. Currently, only two queues are used. Scheduling is done on a priority-scheduling basis. Admission to the queues is based on 802.1p or port priority CoS values and is not user configurable. The gigabit Ethernet queue admission criteria are as follows: queue 1: CoS 0 through 3, queue 2: CoS 4 through 7, queues 3-8: not used.

For the Catalyst 3524-PWR XL, QoS requires the following changes to the configuration of the access switch:


2. Configure the uplink to the distribution switch.


If you use a single cable to install an IP phone, the access port is configured to trust the IP phone and not the attached PC. The port is also configured to use multiple transmit queues on all interfaces.

To configure IP phone port queuing, do the following:

Step 1 Enter interface configuration mode:

c35k(config)#interface FastEthernet0/1

Step 2 Set the encapsulation format on the trunk port to 802.1Q. With this format, the switch supports simultaneous tagged and untagged traffic on a port.

c35k(config-if)#switchport trunk encapsulation dot1q

Step 3 Set the native VLAN for sending and receiving untagged traffic when the interface is in 802.1Q trunking mode. Valid IDs are from 1 to 4094. Do not enter leading zeros.

c35k(config-if)#switchport trunk native vlan 12

Step 4 Configure the port as a trunk port.

c35k(config-if)#switchport mode trunk

Step 5 Configure the VLAN to be used for voice.

c35k(config-if)#switchport voice vlan 112

Step 6 Set the IP phone port to override the priority received from PC or the attached device.

c35k(config-if)#switchport priority extend cos 0

Step 7 Enable the Port Fast feature on an interface in all its associated VLANs.

c35k(config-if)#spanning-tree portfast


956467


Configuring the Uplink Interface to the Distribution Switch

The recommended design for wiring closet configurations of Catalyst 3500 XL family of Catalyst switches is a star topology. A Catalyst 3500 family GigaStack configuration cannot provide guaranteed voice QoS because it is essentially a shared media access model. The basic concern is the behavior of the GigStack GBIC when you use both ports of the GBIC. GigaStack is a half-duplex connection. Because it is half duplex, you cannot guarantee voice quality if you use both ports of the GigaStack GBIC. So where you use stacked switches, you need to use only one port in the GigaStack GBIC. This will mean that you use more GigaStack GBICS. However, this design will avoid any half- duplex, non-deterministic behavior. Additionally, when you create stacks of switches you need to keep in mind how your traffic will flow and how many devices will be participating in a Layer 2 convergence event. In general, if you have to stack, design small stacks so that you will be able to tune spanning tree for fast convergence.

Catalyst 3550 as an Access-Layer SwitchThe Catalyst 3550 family of switches supports enhanced QoS features that can be used in the access layer. Of particular interest are the Catalyst 3550's ability to classify and mark traffic on ingress to the network using ACLs and policies. The Catalyst 3550's ability to identify traffic flows at Layer 3 and Layer 4 using ACLs makes it very powerful as an access-layer device.

The Catalyst 3550 is a powerful, QoS-capable switch for the access layer. However, it does not support the full set of features required for an IP telephony deployment. The Catalyst 3550 IOS software provides full support for IP telephony. However, there is no hardware option that provides inline power. This can be designed around through the use of the AC power brick or an inline power patch panel. The inline power feature is scheduled for addition to the Catalyst 3550 family sometime in CY2002.



Si

Si

VLAN=12

Core

Distribution

Access

Catalyst6500

Catalyst 3550

7470

2

Si


956467


This section presents suggested configurations for port scheduling and queuing on the Catalyst 3550. In general:


• The recommended configuration for the transmit interface is 1P3Q1T—one priority queue and three queues, each with a single drop threshold. Scheduling is done on a WRR basis where each queue is given a relative weight while the priority queue is serviced exhaustively. The default is WRR only. If priority scheduling is required, it must be explicitly enabled. Admission to the queues is based on 802.1p CoS or port priority CoS. The default queue admission criteria for the Catalyst 3550 are as follows: queue 1: CoS 0 and 1; queue 2: CoS 2 and 3; queue 3: CoS 4 and 5; queue 4: CoS 6 and 7.

For the Catalyst 3550, QoS requires the following changes to the access switch configuration:


2. Modify the default CoS-to-DSCP mapping table.

3. Turn on priority queuing.

4. Move CoS 5 traffic to the priority queue.

5. Enable QoS features when classification is required.

6. Enable QoS features when connecting and IP phone.

7. Enable QoS features for the uplink to distribution.

Enabling QoS

To enable QoS on the access-layer Catalyst 3550, do the following:


3550G-Access(config)#mls qos


There are 8 CoS labels and 64 possible DSCP labels. To trust the CoS markings, the default CoS-to-DSCP mapping table must be modified to equate CoS 3 (VoIP control traffic) to AF31, CoS 5 (VoIP bearer traffic) to EF, and CoS 4 to AF41.

Step 1 The default CoS-to-DSCP mapping is as follows:

3550G-Access#show mls qos maps


Change the default mapping table so that CoS 3 = AF31, CoS 4 = AF41, and CoS 5 = EF. Remember to use the decimal equivalents.

3550G-Access(config)#mls qos map cos-dscp 0 8 16 26 34 46 48 56


956467




Step 1 Specify the interface range.

3550G-Access(config)#interface range g 0/1 - 12

Step 2 Specify the priority queue.

3550G-Access(config-if-range)#priority-queue out

Step 3 Move the CoS 5 traffic to queue 4, which is the priority queue for the Catalyst 3500 family.

3550G-Access(config-if-range)#wrr-queue cos-map 4 5

Configuring ACLs

There are times when classification of traffic by the access-layer switch is required. The Catalyst 3550 has a powerful set of features that allow us to classify traffic as it enters the network. The following configuration illustrates how to classify VoIP bearer and control traffic with the Catalyst 3550 as it enters the network.

Step 1 Create the ACLs to identify the traffic.

3550G-Access(config)#ip access-list extended VOICE3550G-Access(config-ext-nacl)#remark Match the UDP ports that VoIP Uses for Bearer Traffic3550G-Access(config-ext-nacl)#permit udp any any range 16384 327673550G-Access(config)#ip access-list extended VOICE-CONTROL3550G-Access(config-ext-nacl)#remark Match VoIP Control Traffic3550G-Access(config-ext-nacl)#remark SCCP3550G-Access(config-ext-nacl)#permit tcp any any range 2000 20023550G-Access(config-ext-nacl)#remark H323 Fast Start3550G-Access(config-ext-nacl)#permit tcp any any eq 17203550G-Access(config-ext-nacl)#remark H323 Slow Start - Verify could be in 3000 range for CM or 11000 to 65535 with newer IOS's3550G-Access(config-ext-nacl)#permit tcp any any range 11000 119993550G-Access(config-ext-nacl)#remark H323 MGCP3550G-Access(config-ext-nacl)#permit udp any any eq 2427

Step 2 Create classes that use the ACLs as admission criteria.

3550G-Access(config)#class-map match-all VOICE3550G-Access(config-cmap)#description VOIP Bearer Traffic3550G-Access(config-cmap)#match access-group name VOICE3550G-Access(config)#class-map match-all VOICE-CONTROL3550G-Access(config-cmap)#description VOIP Control Traffic (SCCP, H225, H254, MGCP)3550G-Access(config-cmap)#match access-group name VOICE-CONTROL

Step 3 Create a policy to set the DSCP PHB label/value for the classes.

3550G-Access(config)#policy-map ACCESS-C3550-LAN-EDGE-IN3550G-Access(config-pmap)#description Set DSCP PerHopBehavior Label for VOIP Control and Bearer Traffic3550G-Access(config-pmap)#class VOICE-CONTROL3550G-Access(config-pmap-c)#set ip dscp 263550G-Access(config-pmap)#class VOICE3550G-Access(config-pmap-c)#set ip dscp 46


956467


Step 4 Apply the policy to an interface so that traffic entering the network through this port is classified with the appropriate DSCP PHB Label EF and AF31 for VoIP bearer and control respectively.

3550G-Access(config)#int g 0/23550G-Access(config-if)#service-policy input ACCESS-C3550-LAN-EDGE-IN


When the Catalyst 3550 is connected to an IP phone, you must do the following:

Step 1 Configure the switch to trust CoS from the IP phone.

3550G-Access(config)#interface g 0/113550G-Access(config-if)#mls qos trust cos


3550G-Access(config-if)#switchport voice vlan 1113550G-Access(config-if)#switchport access vlan 11

Step 3 Set the IP phone’s trust boundary.

3550G-Access(config-if)#switchport priority extend cos 0

Step 4 Enable priority queuing on the port.

3550G-Access(config-if)#priority-queue out

Step 5 Modify the CoS to queue admission criteria.

3550G-Access(config-if)#wrr-queue cos-map 4 5


The ports attached to the distribution layer require a slightly different configuration. These ports must be configured to trust DSCP or CoS depending on the capabilities of the distribution-layer switch attached. In the following configuration, port 0/11 is attached to a Layer 3-aware distribution device and can trust DSCP arriving from it. Port 0/12 illustrates and example where CoS-only classification is used.

Note The system-wide CoS-to-DSCP mapping and DSCP-to-queue admission criteria configurations must have been completed and the priority queue must be enabled for these ports in order for the access-layer uplink ports to perform QoS as expected.



Step 2 Enable the priority queue on this interface and move CoS 5 traffic into queue 4, which is the priority queue on the Catalyst 3500 family.

3550G-Access(config-if)#priority-queue out3550G-Access(config-if)#wrr-queue cos-map 4 5


956467



3550G-Access(config)#interface g 0/123550G-Access(config-if)#mls qos trust dscp

Step 4 Enable the priority queue on this interface and move Cos 5 traffic into queue 4, which is the priority queue on the Catalyst 3500 family.

3550G-Access(config-if)#priority-queue out3550G-Access(config-if)#wrr-queue cos-map 4 5




3550G-Access#show mls qos maps Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------- dscp: 0 8 16 26 34 46 48 56

Example 3-14 Displaying QoS Queuing Strategy

3550G-Access#show mls qos interface queueing GigabitEthernet0/1Ingress expedite queue: disEgress expedite queue: enawrr bandwidth weights:qid-weights 1 - 25 2 - 25 3 - 25 4 - 25 when expedite queue is disabledDscp-threshold map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 01 01 01 01 2 : 01 01 01 01 01 01 01 01 01 01 3 : 01 01 01 01 01 01 01 01 01 01 4 : 01 01 01 01 01 01 01 01 01 01 5 : 01 01 01 01 01 01 01 01 01 01 6 : 01 01 01 01



show mls qos interface queueing Displays the QoS queuing strategy. Example 3-14


Example 3-15


956467


Cos-queue map:cos-qid 0 - 1 1 - 1 2 - 2 3 - 2 4 - 3 5 - 4 6 - 4 7 - 4


3550G-Access#show policy-map interface g 0/2





Catalyst 2950 as an Access-Layer SwitchThe 2950 family of Catalyst switches support enhanced QoS features that can be used in the access layer. Of particular interest is the ability to classify and mark traffic on ingress to the network via ACLs and policies. While not as advanced as the Catalyst 4000 Supervisor III or Catalyst 3550 in its flexibility to identify traffic flows at Layer 3 and Layer 4 via ACLs, the Catalyst 2950 family of switches are Layer 3 aware, making them very powerful. It should be noted that ACLs used to identify traffic in the Catalyst 2950 are limited to a single TCP or UDP port per Access Control Entry (ACE). Use of the range, greater than, or less than, keywords is not supported when defining an ACL on the Catalyst 2950. This can make identification of applications that use a wide range of ports difficult. This means that long ACLs are required, which may exceed the Catalyst 2950's ACL memory capacity.

The Catalyst 2950 is a very powerful QoS-capable switch for the access layer. However, it does not support the full set of features required for an IP telephony deployment. The Catalyst 2950 IOS software provides full support for IP telephony. There is not, however, a Catalyst 2950 hardware option that provides inline power. This can be designed around through the use of the AC power brick or an inline power patch panel.



956467



This section presents suggested configurations for port scheduling and queuing on the Catalyst 2950. In general:


• The recommended configuration for the transmit interface is 4Q1T—four standard queues with a single threshold. Scheduling is done on a priority-scheduling basis or a WRR scheduling algorithm. The default is priority scheduling. Admission to the queues is based on 802.1p CoS or port priority CoS. The default queue admission criteria for the Catalyst 2950 are as follows: queue 1: CoS 0 and 1, queue 2: CoS 2 and 3, queue 3: CoS 4 and 5, queue 4: CoS 6 and 7.

For the Catalyst 2950, QoS requires the following changes to the access switch configuration:

1. Modify the default CoS-to-DSCP mapping table.

2. Configure an ACL that identifies mission critical traffic, associate it with a service policy, and apply the policy to an interface.

3. Enable QoS features to support an IP Phone.

4. Enable QoS features required to support uplink to distribution layer.

Note QoS is on by default in the Catalyst 2950. Priority queuing is the default. No change is required for the CoS-to-queue assignment.



Si

Si

VLAN=12

Core

Distribution

Access

Catalyst6500

Catalyst 2950

7470

3

Si


956467



2950-Access#sh mls qos maps

Dscp-cos map: dscp: 0 8 10 16 18 24 26 32 34 40 46 48 56 ----------------------------------------------- cos: 0 1 1 2 2 3 3 4 4 5 5 6 7


Change the default mapping table so that CoS 2 = AF21, CoS 3 = AF31, CoS 5 = EF. Remember to use the decimal equivalents.

2950-Access(config)#mls qos map cos-dspc 0 8 16 26 34 46 48 56

Configuring ACLs

To use ACLs to determine admission criteria, do the following:

Step 1 Define an access list to select the traffic that will be classified later.

2950-Access(config)#ip access-list extended GOLD-DATA2950-Access(config-ext-nacl)#remark Match IP Address of the application server2950-Access(config-ext-nacl)#permit ip any host 192.168.100.1

Step 2 Define a class that to use in the policy.

2950-Access(config)#class-map match-all GOLD-DATA2950-Access(config-cmap)#description Mission Critical Traffic2950-Access(config-cmap)#match access-group name GOLD-DATA

Step 3 Define the policy that uses the ACL and class and sets the DSCP PHB label.

2950-Access(config)#policy-map ACCESS-C2950-LAN-EDGE-IN2950-Access(config-pmap)#description Set DSCP PerHopBehavior Label for Mission Critical Traffic2950-Access(config-pmap)#class GOLD-DATA2950-Access(config-pmap-c)#set ip dscp 18

Step 4 Apply the policy to an interface. In this example, all traffic that matches the ACL will be classified with a DSCP PHB of AF21.

2950-Access(config)#int fa0/12950-Access(config-if)#service-policy input ACCESS-C2950-LAN-EDGE-IN


When the Cisco 2950 is connected to an IP phone, you must do the following:


956467


Step 1 Configure the switch to trust CoS from the IP phone.



2950G-Access(config-if)#switchport voice vlan 1112950G-Access(config-if)#switchport access vlan 11

Step 3 Set the IP phone’s trust boundary.

2950G-Access(config-if)#switchport priority extend cos 0


The ports attached to the distribution layer require a different configuration. These ports must be configured to trust DSCP or CoS depending on the capabilities of the distribution-layer switch attached. In the following configuration, port 0/11 illustrates an example where CoS-only classification is used. Port 0/12 is attached to a Layer 3-aware distribution device and can trust the DSCP arriving from it.




2950G-Access(config)#interface g 0/122950G-Access(config-if)#mls qos trust dscp


On the Catalyst 2950 access-layer switch, you can verify the configuration by examining the output of the following commands:


2950-Access#show mls qos maps

Dscp-cos map: dscp: 0 8 10 16 18 24 26 32 34 40 46 48 56 ----------------------------------------------- cos: 0 1 1 2 2 3 3 4 4 5 5 6 7



show mls qos maps Displays the QoS CoS mapping information. Example 3-16

show wrr-queue band Displays the queuing mechanism and the QoS queue assignments.

Example 3-17


956467

Chapter 3 QoS in an AVVID-Enabled Campus NetworkSelecting a Distribution-Layer Switch

Example 3-17 Displaying the Queuing Mechanism and Queue Assignments

2950-Access#show wrr-queue bandwrr-queue bandwidth is disabled

2950-Access#show wrr-que cosCoS Value : 0 1 2 3 4 5 6 7

Priority Queue : 1 1 2 2 3 3 4 4

Selecting a Distribution-Layer SwitchThere are many choices for distribution-layer Catalyst switches. The most common switch in this layer of a hierarchical network design is the Catalyst 6500. The Catalyst 6500 series has advanced QoS features via the PFC that makes it an ideal choice for this location in the network. The Catalyst 4000 with Supervisor III is also well suited for this task. The primary difference between a Catalyst 6500 series and the Catalyst 4000 when used in this part of a network design is scalability. The Catalyst 6500 can scale to 256 Gbps with 10 Gbps interfaces while the Catalyst 4000 with Supervisor III can only scale to 32 Gbps interfaces. Additionally, for very small networks (where density, scalability, and investment protection are not a primary concern), the Catalyst 3550 family of switches offers a robust QoS feature set that makes it a good fit for the distribution layer.

After you configure the access switch and attached it to the distribution layer, you must set up QoS on the distribution switches. This section illustrates how to do that on the various switches mentioned earlier in this chapter.

Catalyst 6500 (with Catalyst OS) as a Distribution-Layer SwitchFigure 3-13 shows a general model for the Catalyst 6500 (with Catalyst OS) as a distribution device (as illustrated in the QoS configurations discussed in this chapter).


956467


Figure 3-13 General Model for Catalyst 6500 (with Catalyst OS) as a Distribution Switch in QoS

Configurations

For the Catalyst 6500 running Catalyst OS, QoS requires the following changes to the configuration of the distribution switch:

1. Configure VoIP control traffic transmit queuing.

2. Configure the distribution layer with a Layer 3 access switch.


Configuring the Distribution Layer VoIP Control Traffic Transmit Queue

When QoS is enabled, all VoIP (CoS of 5) traffic is placed into the egress interface priority queue on 1p2q2t interfaces and into queue 2 on 2q2t interfaces (for all versions “1” of the 10/100 line cards). To configure the Catalyst 6500 CoS queue admission rules to ensure that VoIP control traffic (CoS of 3) is placed into the second queue, do the following:

Step 1 Change the mapping for the 1p2q2t interfaces.

cat6k-distrib> (enable) set qos map 1p2q2t tx 2 1 cos 3

Step 2 Change the mapping for the 2q2t interfaces.

cat6k-distrib> (enable) set qos map 2q2t tx 2 1 cos 3

Configuring the Distribution Layer with a Layer 3 Switch

Once you have enabled QoS on the distribution layer switch and have modified the default queue admission, do the following to complete the integration with a Layer 3 access switch:

Si Si

IP

VVID=112

6500 w/ PFC 4000 3500

VLAN=12

IP

VVID=111

VLAN=11

IP

VVID=110

VLAN=10

Distribution

Access

Hybrid6500

Native IOS6500

7200 WANrouter

7470

4

2/12/2 1/2 3/2

9/13/1 1/1


956467


Step 1 Enable trust for DSCP values from adjacent Layer 3 access switches. Use port-based QoS on the trunking port and use trust-dscp instead of trust-cos (because trust-cos overwrites the Layer 3 DSCP value with the mapped CoS, which is unnecessary because classification is done at the access layer).

cat6k-distrib> (enable) set port qos 1/1 port-basedcat6k-distrib> (enable) set port qos 1/1 trust trust-dscp

Step 2 Configure CoS/IP Precedence-to-DSCP mappings. Cisco follows the IETF recommendations for setting the DSCP classification values for both the VoIP control plane traffic and VoIP bearer or media plane traffic. The recommended settings are DSCP of AF31 for VoIP control plane and DSCP of EF for VoIP bearer plane. To map the Layer 3 IP Precedence settings correctly to these DSCP values, you must modify the default CoS/IP Precedence-to-DSCP mappings as follows:

cat6k-distrib> (enable) set qos ipprec-dscp-map 0 8 16 26 34 46 48 56


Once you have enabled QoS on the distribution-layer switch and have modified the default queue admission, do the following to complete the integration with a Layer 2 access switch:

Step 1 Enable trust for CoS values from adjacent Layer 2 access switches. Use port-based QoS on the trunking port and use trust-cos instead of trust-dscp. This configuration is used when the access-layer switch is a Layer 2-only device performing CoS classification.

cat6k-distrib> (enable) set port qos 1/2,3/2 trust trust-cos

Step 2 Configure CoS-to-DSCP mappings. Cisco follows the IETF recommendations for setting the DSCP classification values for both the VoIP control plane traffic and VoIP bearer or media plane traffic. The recommended settings are DSCP of AF31 for VoIP control plane and DSCP of EF for VoIP bearer plane. Modify the default CoS-to-DSCP mappings as follows:

cat6k-distrib> (enable) set qos cos-dscp-map 0 8 16 26 34 46 48 56

Configuring QoS Policies and Layer 3 Access Lists for VoIP Control Traffic

In addition, you must configure Layer 3 access lists for VoIP control traffic.

Note This example uses the ACL_IP-PHONES ACL defined earlier.

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

cat6k-distrib> (enable) set port qos 1/2,3/2 vlan-based

Step 2 Map the ACL_IP-PHONE ACL to the auxiliary VLAN.

cat6k-distrib> (enable) set qos acl map ACL_IP-PHONES 111


956467


To verify the settings, issue the following commands:

cat6k-distrib> (enable) show qos acl map run ACL_IP-PHONESACL name Type Vlans-------------------------------- ---- ---------------------------------ACL_IP-PHONES IP 110,111,112 ACL name Type Ports-------------------------------- ---- ---------------------------------ACL_IP-PHONES IP

cat6k-distrib> (enable) show qos acl info run ACL_IP-PHONES

set qos acl IP ACL_IP-PHONES----------------------------------------------1. dscp 26 tcp any any range 2000 20022. dscp 26 tcp any any eq 17203. dscp 26 tcp any any range 11000 119994. dscp 26 udp any any eq 24275. trust-cos any

Step 3 Enable trust for DSCP values from adjacent Layer 3 access switches. Use port-based QoS on the trunking port. Current 10/100 version 1 linecards must have trust-ipprec enabled even though the parser returns an error.

cat6k-distrib> (enable) set port qos 9/1 port-basedcat6k-distrib> (enable) set port qos 9/1 trust trust-ipprec

Step 4 Create an access list that accepts incoming Layer 3 IP Precedence classification.

cat6k-distrib> (enable) set qos acl ip ACL_TRUST-WAN trust-ipprec any


cat6k-distrib> (enable) commit qos acl ACL_TRUST-WAN

Step 6 Map the ACL_TRUST-WAN ACL to the port.

cat6k-distrib> (enable) set qos acl map ACL_TRUST-WAN 9/1


On the Catalyst 6500 distribution-layer switch (with Catalyst OS), you can verify the configuration by examining the output of the following commands:


show qos map run ipprec-dscp-map

Displays the QoS IP Precedence mapping information.

Example 3-18

show qos map run cos-dscp-map Displays the QoS CoS mapping information. Example 3-19

show port qos Displays the Qos settings for a specified port. Example 3-20


956467


Example 3-18 Displaying the QoS IP Precedence-to-DSCP Mappings

cat6k-distrib> (enable) show qos map run ipprec-dscp-map IP-Precedence - DSCP map:IP-Prec DSCP------- ---- 0 0 1 8 2 16 3 26 26 = AF31 VoIP Control 4 34 34 = AF41 IP Video Conferencing 5 46 46 = EF VoIP Bearer 6 48 7 56

Example 3-19 Displaying the QoS CoS-to-DSCP Mappings

cat6k-distrib> (enable) show qos map run cos-dscp-map CoS - DSCP map:CoS DSCP--- ---- 0 0 1 8 2 16 3 26 4 34 5 46

6 487 56

Example 3-20 Displaying the QoS Port Settings

cat6k-distrib> (enable) show port qos 9/1QoS is enabled for the switch.QoS policy source for the switch set to local.

Port Interface Type Interface Type Policy Source Policy Source config runtime config runtime----- -------------- -------------- ------------- ------------- 9/1 port-based port-based COPS local

Port TxPort Type RxPort Type Trust Type Trust Type Def CoS Def CoS config runtime config runtime-------------------------------------------------------------------- 9/1 2q2t 1q4t trust-ipprec trust-ipprec 0 0

Port Ext-Trust Ext-Cos----- --------- ------- 9/1 untrusted 0

(*)Runtime trust type set to untrusted.

Config:Port ACL name Type----- -------------------------------- ---- 9/1 ACL_TRUST-WAN IP Runtime:Port ACL name Type----- -------------------------------- ---- 9/1 ACL_TRUST-WAN IP


956467


Catalyst 6500 (with Native IOS) as a Distribution-Layer SwitchFigure 3-14 shows a general model for the Catalyst 6500 (with Native IOS) as a distribution device (as illustrated in the QoS configurations discussed in this chapter).

Figure 3-14 General Model for Catalyst 6500 (with Native IOS) as a Distribution Switch in QoS

Configurations

For the Catalyst 6500 running Native IOS, QoS requires the following changes to the configuration of the distribution switch:

1. Configure QoS.

1. Configure VoIP control traffic transmit queuing.



4. Configure QoS policies and Layer 3 access lists for VoIP control traffic classification.

Enabling QoS

To enable QoS on the Catalyst 6500 with Native Cisco IOS, do the following:

Step 1 Enable QoS.

Cat6k-distrib (config)#mls qos

Si Si

IP

VVID=112

6500 w/ PFC 4000 3500

VLAN=12

IP

VVID=111

VLAN=11

IP

VVID=110

VLAN=10

Distribution

Access

Hybrid6500

Native IOS6500

7200 WANrouter

7470

5

2/12/2 1/2 3/2

9/13/1 1/1


956467


Configuring the Distribution Layer VoIP Control Traffic Transmit Queue

When QoS is enabled, all VoIP (CoS of 5) traffic is placed into the egress interface priority queue on 1p2q2t interfaces and into queue 2 on 2q2t interfaces (for all versions “1” of the 10/100 line cards). To configure the Catalyst 6500 CoS queue admission rules to ensure that VoIP control traffic (CoS of 3) is placed into the second queue, do the following:

Step 1 Specify the range of ports for which you want to define queue admission rules.

Cat6k-distrib (config)#interface range gigabitEthernet 1/1 - 2

Step 2 Map the CoS values to drop thresholds for each queue.

Cat6k-distrib (config-if)#wrr-queue cos-map 2 1 3 4

Tip When using IOS version 12.1(8a)EX and above on a Catalyst 6500, you cannot modify the CoS-to-queue mapping for the priority queue on the Gigabit Ethernet ports in the supervisor module.

For more information, please see the field notice titled Limited QoS Functionality on the Gigabit Ethernet Ports on the Catalyst 6000 Supervisor.


Once you have enabled QoS on the Native Cisco IOS distribution layer switch and have modified the default queue admission, do the following to complete the integration with a Layer 3 access switch:

Step 1 Enable trust for DSCP values from adjacent Layer 3 access switches. Use port-based QoS on the trunking port (port-based QoS is enabled by default when MLS QoS is configured) and use mls qos trust dscp.

Cat6k-distrib (config)#interface GigabitEthernet2/1Cat6k-distrib (config-if)#no ip addressCat6k-distrib (config-if)#wrr-queue cos-map 2 1 3 4 Cat6k-distrib (config-if)#mls qos trust dscpCat6k-distrib (config-if)#switchportCat6k-distrib (config-if)#switchport trunk encapsulation dot1qCat6k-distrib (config-if)#switchport mode trunk

Step 2 Configure CoS/IP Precedence-to-DSCP mappings. Cisco follows the IETF recommendations for setting the DSCP classification values for both the VoIP control plane traffic and VoIP bearer or media plane traffic. The recommended settings are DSCP of AF31 for VoIP control plane and DSCP of EF for VoIP bearer plane.

Additionally, the recommended value for video conferencing (CoS 4) is DSCP AF41 (decimal 34). The default CoS-to-DSCP mapping equates CoS 4 with DSCP decimal 32. Therefore, to support video conferencing, the mapping must be modified to map CoS 4 to DSCP decimal 34 (AF41).

To map the Layer 3 IP Precedence settings correctly to these DSCP values, modify the default CoS/IP Precedence-to-DSCP mappings as follows:

Cat6k-distrib (config-if)#mls qos map ip-prec-dscp 0 8 16 26 34 46 48 56


956467



Once you have enabled QoS on the distribution-layer switch and have modified the default queue admission, do the following to complete the integration with a Layer 2 access switch:

Step 1 Enable trust for CoS values from adjacent Layer 2 access switches. Use port-based QoS on the trunking port and use mls qos trust cos. This configuration is used when the access-layer switch is only a Layer 2 device performing CoS classification.

Cat6k-distrib (config)#interface GigabitEthernet2/2Cat6k-distrib (config-if)#no ip addressCat6k-distrib (config-if)#wrr-queue cos-map 2 1 3 4 Cat6k-distrib (config-if)#mls qos vlan-basedCat6k-distrib (config-if)#mls qos trust cosCat6k-distrib (config-if)#switchportCat6k-distrib (config-if)#switchport trunk encapsulation dot1qCat6k-distrib (config-if)#switchport mode trunk

Cat6k-distrib (config)#interface GigabitEthernet3/1Cat6k-distrib (config-if)#no ip addressCat6k-distrib (config-if)#wrr-queue cos-map 2 1 3 4 Cat6k-distrib (config-if)#mls qos vlan-basedCat6k-distrib (config-if)#mls qos trust cosCat6k-distrib (config-if)#switchportCat6k-distrib (config-if)#switchport trunk encapsulation dot1qCat6k-distrib (config-if)#switchport mode trunk

Step 2 Configure CoS-to-DSCP mappings. Cisco follows the IETF recommendations for setting the DSCP classification values for both the VoIP control plane traffic and VoIP bearer or media plane traffic. The recommended settings are DSCP of AF31 for VoIP control plane and DSCP of EF for VoIP bearer plane. To map the Layer 2 settings correctly to these DSCP values, you must modify the default CoS-to-DSCP mappings as follows:

Cat6k-distrib (config-if)#mls qos map cos-dscp 0 8 16 26 34 46 48 56

Configuring QoS Policies and Layer 3 Access Lists for VoIP Control Traffic

In addition, you must configure QoS policies and Layer 3 access lists for VoIP control traffic.

The QoS configuration for the Catalyst 6500 with Native Cisco IOS is similar to the QoS configuration for Cisco WAN routers, except how policing is used for marking traffic flows and how service policies are applied to VLAN interfaces.

With Native Cisco IOS:

• The physical gigabit Ethernet uplink ports are configured to use VLAN-based QoS with the MLS QoS VLAN-based Native Cisco IOS interface commands.

• The service-policy is applied to all VLAN traffic inbound on the uplink.

In the example below, three classes are defined: one for the VoIP media stream, one for the control traffic, and one for all other traffic. Traffic is filtered for these classes based on the Layer 3 or 4 source and destination IP addresses and ports. Each of these classes is referenced in the Voice-QoS policy map. In the policy-map statements, a policing function is used to classify all traffic that meets the entrance criteria matched with the class-map access lists.

The Catalyst 6500 Native Cisco IOS software does not support the set ip dscp commands. Although it can be enabled, it should not be used because only software switched packets will be classified. Instead, the policing algorithm should be used to classify traffic.


956467


In this scenario, the policing code tags the traffic flows with DSCP values of AF31 for VoIP control traffic, EF for VoIP bearer traffic, and 0 for all other packets.

Step 1 Create classes that use ACLs as admission criteria.

Cat6k-distrib (config)#class-map match-all VOICE-CONTROLCat6k-distrib (config-cmap)#match access-group 100Cat6k-distrib (config)#class-map match-all VOICECat6k-distrib (config-cmap)#match access-group 101Cat6k-distrib (config)#class-map match-all BEST-EFFORT-DATACat6k-distrib (config-cmap)#match access-group 102

Step 2 Create policies to tag the traffic flows with the appropriate DSCP values.

Note The policer value (4000000000) below should be sized appropriately in your network.

Cat6k-distrib (config)#policy-map DISTRIBUTION-C6000-UPLINK-INCat6k-distrib (config-pmap)#class VOICE-CONTROLCat6k-distrib (config-pmap-c)#police 4000000000 125000000 125000000 conform-action set-dscp-transmit 26 exceed-action transmitCat6k-distrib (config-pmap)#class VOICECat6k-distrib (config-pmap-c)#police 4000000000 125000000 125000000 conform-action set-dscp-transmit 46 exceed-action transmitCat6k-distrib (config-pmap)#class BEST-EFFORT-DATACat6k-distrib (config-pmap-c)#police 4000000000 125000000 125000000 conform-action set-dscp-transmit 0 exceed-action transmit

Step 3 Create an access list for VoIP control traffic.

Cat6k-distrib (config)#access-list 100 permit tcp any any range 2000 2002Cat6k-distrib (config)#access-list 100 permit tcp any any eq 1720Cat6k-distrib (config)#access-list 100 permit tcp any any range 11000 11999Cat6k-distrib (config)#access-list 100 permit udp any any eq 2427

Step 4 Create an access list for VoIP bearer traffic.

Cat6k-distrib (config)#access-list 101 permit udp any any range 16384 32767

Step 5 Create an access list for best effort traffic.

Cat6k-distrib (config)#access-list 102 permit ip any any

Step 6 Enable trust for DSCP values from adjacent Layer 3 access switches. Use VLAN-based QoS on the trunking port.

Cat6k-distrib (config)#interface GigabitEthernet2/2Cat6k-distrib (config-if)#no ip addressCat6k-distrib (config-if)#wrr-queue cos-map 2 1 3 4 Cat6k-distrib (config-if)#mls qos vlan-basedCat6k-distrib (config-if)#switchportCat6k-distrib (config-if)#switchport trunk encapsulation dot1qCat6k-distrib (config-if)#switchport mode trunk

Cat6k-distrib (config)#interface GigabitEthernet3/1Cat6k-distrib (config-if)#no ip addressCat6k-distrib (config-if)#wrr-queue cos-map 2 1 3 4 Cat6k-distrib (config-if)#mls qos vlan-basedCat6k-distrib (config-if)#switchportCat6k-distrib (config-if)#switchport trunk encapsulation dot1qCat6k-distrib (config-if)#switchport mode trunk


956467


Step 7 Configure the voice VLANs on the access switches.

Cat6k-distrib (config)#interface Vlan111Cat6k-distrib (config-if)#ip address 10.1.111.77 255.255.255.0Cat6k-distrib (config-if)#ip helper-address 10.1.10.10Cat6k-distrib (config-if)#no ip redirectsCat6k-distrib (config-if)#service-policy input DISTRIBUTION-C6000-UPLINK-INCat6k-distrib (config-if)#standby 111 ip 10.1.111.1

Cat6k-distrib (config)#interface Vlan112Cat6k-distrib (config-if)#description voice vlan on 3500Cat6k-distrib (config-if)#ip address 10.1.112.77 255.255.255.0Cat6k-distrib (config-if)#ip helper-address 10.1.10.10Cat6k-distrib (config-if)#no ip redirectsCat6k-distrib (config-if)#service-policy input DISTRIBUTION-C6000-UPLINK-INCat6k-distrib (config-if)#standby 112 ip 10.1.112.1


To verify the QoS configuration, issue the following command.

Cat6k-distrib#show mls qosQoS is enabled globallyMicroflow policing is enabled globally

QoS is vlan-based on the following interfaces:Vl111 V112 Gi2/2 Gi3/1 Gi3/2 Gi3/3 Gi3/4 Gi3/5 Gi3/6 Gi3/7 Gi3/8 Gi4/1 Gi4/2 Gi4/3 Gi4/4 Gi4/5 Gi4/6 Gi4/7 Gi4/8 Fa9/1 Fa9/2 Fa9/3 Fa9/4 Fa9/5 Fa9/6 Fa9/7 Fa9/8 Fa9/9 Fa9/10 Fa9/11 Fa9/12 Fa9/13 Fa9/14 Fa9/15 Fa9/16 Fa9/17 Fa9/18 Fa9/19 Fa9/20 Fa9/21 Fa9/22 Fa9/23 Fa9/24 Fa9/25 Fa9/26 Fa9/27 Fa9/28 Fa9/29 Fa9/30 Fa9/31 Fa9/32 Fa9/33 Fa9/34 Fa9/35 Fa9/36 Fa9/37 Fa9/38 Fa9/39 Fa9/40 Fa9/41 Fa9/42 Fa9/43 Fa9/44 Fa9/45 Fa9/46 Fa9/47 Fa9/48

QoS global counters:Total packets: 16750372458300Packets dropped by policing: 55930847232IP packets with TOS changed by policing: 16750372458300IP packets with COS changed by policing: 55945330688Non-IP packets with COS changed by policing: 16750372458300

Catalyst 4000 with Supervisor III as a Distribution-Layer SwitchFigure 3-15 shows a general model for the Catalyst 4000 with Supervisor III as a distribution device (as illustrated in the QoS configurations discussed in this chapter).


956467


Figure 3-15 General Model for Catalyst 4000 with Supervisor III as a Distribution Switch in QoS

Configurations

For a Catalyst 4000 with Supervisor III, QoS requires the following changes to the configuration of the distribution switch:

1. Enable QoS.

2. Change the default CoS-to-DSCP mapping table so that CoS and DSCP PHB label behavior can be maintained throughout the network.

3. Configure service policies to classify traffic for that does not contain a CoS-to-ToS marking that you can trust.

4. Enable CoS or DSCP trust on the ports where trust is appropriate. Use ToS for Layer 3 aware access and CoS for Layer 2 only access.

Enabling QoS

To enable QoS on the Catalyst 4000, do the following:

Step 1 Enable QoS.

4006-SUPIII-Dist(config)#qos

Modifying the CoS-to-DSCP Mapping

The default CoS-to-DSCP maps must be modified to allow us to trust CoS and maintain DSCP PHB EF and AF31 for VoIP bearer and control traffic respectively.

Si Si

IP

VVID=112

6500 w/ PFC 4000 3500

VLAN=12

IP

VVID=111

VLAN=11

IP

VVID=110

VLAN=10

Distribution

Access

4k Sup III4k Sup III7200 WAN

router

7470

6

3/13/2 3/2 3/3

4/13/3 3/1


956467



4006-SUPIII-Dist#show qos map cosCoS-DSCP Mapping Table CoS: 0 1 2 3 4 5 6 7 -------------------------------- DSCP: 0 8 16 24 32 40 48 56

Change the default CoS-to-DSCP mapping so that CoS 5 = EF and CoS 3 = AF31 and CoS 4 = AF41.

4006-SUPIII-Dist(config)#qos map cos 3 to dscp 264006-SUPIII-Dist(config)#qos map cos 4 to dscp 344006-SUPIII-Dist(config)#qos map cos 5 to dscp 46

Configuring Priority Queuing

Turn on priority queuing on a per port basis. Default admission to the priority queue matches our requirements.

Step 1 Specify the transmit queue.

4006-SUPIII(config-if-tx-queue)#tx-queue 3

Step 2 Set the priority for the queue to high.

4006-SUPIII(config-if-tx-queue)#priority high

Configuring ACLs

Create an ACL to identify the traffic to be marked and create classes that use the ACLs as admission criteria.

Step 1 Create an ACL to match the traffic you want to prioritize.

4006-SUPIII-Dist(config)#ip access-list extended GOLD-DATA4006-SUPIII-Dist(config-ext-nacl)#remark Match IP Address of the application server4006-SUPIII-Dist(config-ext-nacl)#permit ip any host 192.168.100.14006-SUPIII-Dist(config-ext-nacl)#permit ip host 192.168.100.1 any4006-SUPIII-Dist(config)#ip access-list extended VOICE4006-SUPIII-Dist(config-ext-nacl)#remark Match the UDP ports that VoIP Uses for Bearer Traffic4006-SUPIII-Dist(config-ext-nacl)#permit udp any any range 16384 327674006-SUPIII-Dist(config)#ip access-list extended VOICE-CONTROL4006-SUPIII-Dist(config-ext-nacl)#remark Match VoIP Control Traffic4006-SUPIII-Dist(config-ext-nacl)#remark SCCP4006-SUPIII-Dist(config-ext-nacl)#permit tcp any any range 2000 20024006-SUPIII-Dist(config-ext-nacl)#remark H323 Fast Start4006-SUPIII-Dist(config-ext-nacl)#permit tcp any any eq 17204006-SUPIII-Dist(config-ext-nacl)#remark H323 Slow Start4006-SUPIII-Dist(config-ext-nacl)#permit tcp any any range 11000 119994006-SUPIII-Dist(config-ext-nacl)#remark H323 MGCP4006-SUPIII-Dist(config-ext-nacl)#permit udp any any eq 2427


956467


Step 2 Create classes based on the ACL.

4006-SUPIII-Dist(config)#class-map match-all GOLD-DATA4006-SUPIII-Dist(config-cmap)#description Mission Critical Traffic4006-SUPIII-Dist(config-cmap)#match access-group name GOLD-DATA4006-SUPIII-Dist(config)#class-map match-all VOICE4006-SUPIII-Dist(config-cmap)#description VoIP Bearer Traffic4006-SUPIII-Dist(config-cmap)#match access-group name VOICE4006-SUPIII-Dist(config)#class-map match-all VOICE-CONTROL4006-SUPIII-Dist(config-cmap)#description VoIP Control Traffic (SCCP, H225, H254, MGCP)4006-SUPIII-Dist(config-cmap)#match access-group name VOICE-CONTROL

Configuring Service Policy

Create a service policy that uses the classes for admission criteria and sets the appropriate DSCP PHB label.


4006-SUPIII-Dist(config)#policy-map DISTRIBUTION-C4006-UPLINK-IN4006-SUPIII-Dist(config-pmap)#description Set DSCP PerHopBehavior Label for VOIP Control and Bearer Traffic4006-SUPIII-Dist(config-pmap)#class VOICE-CONTROL4006-SUPIII-Dist(config-pmap-c)#set ip dscp 264006-SUPIII-Dist(config-pmap)#class VOICE4006-SUPIII-Dist(config-pmap-c)#set ip dscp 464006-SUPIII-Dist(config-pmap)#class GOLD-DATA4006-SUPIII-Dist(config-pmap-c)#set ip dscp 18

Step 2 Apply the policy to the physical interface.

4006-SUPIII-Dist(config)#int fa 4/14006-SUPIII-Dist(config-if)#service-policy input DISTRIBUTION-C4006-UPLINK-IN

Configuring CoS or DSCP Trust

Additionally, you need to enable the Catalyst 4000 Supervisor III to trust DSCP or CoS depending on the capabilities of the access-layer switch attached. In this example, port 3/1 is attached to a Layer 3-aware access device and can trust DSCP arriving from it. Ports 3/2 and 3/3 are attached to Layer 2 only access devices, so the switch needs to trust CoS.

Step 1 Configure trust for DSCP.

4006-SUPIII-Dist(config)#int g 3/14006-SUPIII-Dist(config-if)#qos trust dscp

Step 2 Configure trust for CoS.

4006-SUPIII-Dist(config-if)#int g 3/2 4006-SUPIII-Dist(config-if)#qos trust cos 4006-SUPIII-Dist(config-if)#int g 3/3 4006-SUPIII-Dist(config-if)#qos trust cos


956467



On the Catalyst 4006 distribution-layer switch, you can verify the configuration by examining the output of the following commands:

Example 3-21 Displaying the QoS CoS-to-DSCP Mappings

4006-SUPIII-Dist#show qos map cosCoS-DSCP Mapping Table CoS: 0 1 2 3 4 5 6 7 -------------------------------- DSCP: 0 8 16 26 34 46 48 56

4006-SUPIII-Dist#show qos map dscp tx-queue DSCP-TxQueue Mapping Table (dscp = d1d2)d1 : d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 02 02 02 02 2 : 02 02 02 02 02 02 02 02 02 02 3 : 02 02 03 03 03 03 03 03 03 03 4 : 03 03 03 03 03 03 03 03 04 04 5 : 04 04 04 04 04 04 04 04 04 04 6 : 04 04 04 04


4006-SUPIII-Dist#show policy-map interface fa 4/1

service-policy input: DISTRIBUTION-C4006-UPLINK-IN


class-map: VOICE-CONTROL (match-all) 0 packets match: access-group name VOICE-CONTROL set: ip dscp 26

class-map: VOICE (match-all) 0 packets match: access-group name VOICE set: ip dscp 46



show policy-map interface Displays policy mapping information. Example 3-22

show port qos Displays the Qos settings for a specified port. Example 3-23

show interface counters Displays statistics regarding traffic seen on the physical interface.

Example 3-24


956467



Example 3-23 Displaying QoS Queuing Information

4006-SUPIII-Dist#show qos int g 3/1QoS is enabled globallyPort QoS is enabledPort Trust State: 'dscp'Default DSCP: 0 Default CoS: 0Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 250000000 disabled N/A 1920 2 250000000 disabled N/A 1920 3 250000000 disabled high 1920 4 250000000 disabled N/A 1920

4006-SUPIII-Dist#show qos int g 3/2QoS is enabled globallyPort QoS is enabledPort Trust State: 'cos'Default DSCP: 0 Default CoS: 0Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 250000000 disabled N/A 1920 2 250000000 disabled N/A 1920 3 250000000 disabled high 1920 4 250000000 disabled N/A 1920

4006-SUPIII-Dist#show qos int g 3/3QoS is enabled globallyPort QoS is enabledPort Trust State: 'cos'Default DSCP: 0 Default CoS: 0Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 250000000 disabled N/A 1920 2 250000000 disabled N/A 1920 3 250000000 disabled high 1920 4 250000000 disabled N/A 1920

Example 3-24 Displaying Traffic Statistics

4006-SUPIII-Dist#show int g3/2 count all

Port InBytes InUcastPkts InMcastPkts InBcastPktsGi3/2 0 0 0 0

Port OutBytes OutUcastPkts OutMcastPkts OutBcastPktsGi3/2 0 0 0 0

Port InPkts 64 OutPkts 64 InPkts 65-127 OutPkts 65-127Gi3/2 0 0 0 0



956467


Port InPkts 512-1023 OutPkts 512-1023Gi3/2 0 0


Port InPkts 1024-1522 OutPkts 1024-1522 InPkts 1523-1548 OutPkts 1523-1548Gi3/2 N/A N/A N/A N/A

Port InPkts 1549-9216 OutPkts 1549-9216 Port InPkts 1549-9216 OutPkts 1549-9216Gi3/2 0 0

Port Tx-Bytes-Queue-1 Tx-Bytes-Queue-2 Tx-Bytes-Queue-3 Tx-Bytes-Queue-4Gi3/2 0 0 0 0

Port Tx-Drops-Queue-1 Tx-Drops-Queue-2 Tx-Drops-Queue-3 Tx-Drops-Queue-4Gi3/2 0 0 0 0

Port Rx-No-Pkt-Buff RxPauseFrames TxPauseFrames PauseFramesDropGi3/2 0 0 0 0

Port UnsupOpcodePauseGi3/2 0

Port CrcAlign-Err TxCrc-Err Collisions Symbol-ErrGi3/2 0 0 0 0

Port Undersize Oversize Fragments JabbersGi3/2 0 0 0 0

Port Single-Col Multi-Col Late-Col Excess-ColGi3/2 0 0 0 0

Port Deferred-Col False-Car Carri-Sen Sequence-ErrGi3/2 0 0 0 0

Port RxIslTagFrames TxIslTagFrames RxDot1qTagFrames TxDot1qTagFramesGi3/2 0 0 0 0

Port RxMacFifoOverrun RxMacFifoUnderrun RxCdmFifoOverrun TxCsmFifoUnderrunGi3/2 0 0 0 0

Port NoPBA/CdmFifoOverunGi3/2 0


956467


Catalyst 3550 as a Distribution-Layer SwitchFigure 3-16 shows a general model for the Catalyst 3550 as a distribution device (as illustrated in the QoS configurations discussed in this chapter).

Figure 3-16 General Model for Catalyst 3550 as a Distribution Switch in QoS Configurations

For the Catalyst 3550, QoS requires the following changes to the configuration of the distribution switch:

1. Enable QoS.

2. Change the default CoS-to-DSCP mapping table so that CoS and DSCP PHB label behavior can be maintained throughout the network.

3. Enable priority queuing (per port). Default admission to priority queue matches our requirements.

4. Configure ACLs, associate them with service policies, and apply the policy to an interface.

5. Configure CoS or DSCP trust for access Layer 2 and Layer 3 aware switches.

Enabling QoS

To enable QoS on the Catalyst 3550, do the following:

Step 1 Enable QoS.

3550G-Dist(config)#mls qos

Si Si

IP

VVID=112

6500 w/ PFC 4000 3500

VLAN=12

IP

VVID=111

VLAN=11

IP

VVID=110

VLAN=10

Distribution

Access

355035507200 WAN

router

7470

7

0/10/2 0/2 0/3

0/10/3 0/1


956467


Modifying the CoS-to-DSCP Mapping



3550G-Dist#show mls qos maps


Change the default CoS-to-DSCP mapping so that CoS 5 = EF and CoS 3 = AF31 and CoS 4 = AF41.

3550G-Dist(config)#mls qos map cos-dscp 0 8 16 26 34 46 48 56



Step 1 Specify the interface range.

3550G-Dist(config)#interface range g 0/1 - 12

Step 2 Specify the priority queue.

3550G-Dist(config-if-range)#priority-queue out

Step 3 Move the CoS 5 traffic to queue 4, which is the priority queue for the Catalyst 3500 family.

3550G-Dist(config-if-range)#wrr-queue cos-map 4 5

Configuring ACLs

There are times when classification of traffic by the access-layer switch is required. The Catalyst 3550 has a powerful set of features that allow us to classify traffic as it enters the network. The following configuration illustrates how to classify VoIP bearer and control traffic with the Catalyst 3550 as it enters the network.

Step 1 Create ACLs to identify the traffic.

3550G-Dist(config)#ip access-list extended GOLD-DATA3550G-Dist(config-ext-nacl)#remark Match IP Address of the application server3550G-Dist(config-ext-nacl)#permit ip any host 192.168.100.13550G-Dist(config-ext-nacl)#permit ip host 192.168.100.1 any3550G-Dist(config)#ip access-list extended VOICE3550G-Dist(config-ext-nacl)#remark Match the UDP ports that VoIP Uses for Bearer Traffic3550G-Dist(config-ext-nacl)#permit udp any any range 16384 327673550G-Dist(config)#ip access-list extended VOICE-CONTROL3550G-Dist(config-ext-nacl)#remark Match VoIP Control Traffic3550G-Dist(config-ext-nacl)#remark SCCP


956467


3550G-Dist(config-ext-nacl)#permit tcp any any range 2000 20023550G-Dist(config-ext-nacl)#remark H323 Fast Start3550G-Dist(config-ext-nacl)#permit tcp any any eq 17203550G-Dist(config-ext-nacl)#remark H323 Slow Start3550G-Dist(config-ext-nacl)#permit tcp any any range 11000 119993550G-Dist(config-ext-nacl)#remark H323 MGCP3550G-Dist(config-ext-nacl)#permit udp any any eq 2427

Step 2 Create classes that use the ACLs as admission criteria.

3550G-Dist(config)#class-map match-all VOICE3550G-Dist(config-cmap)#description VoIP Bearer Traffic3550G-Dist(config-cmap)#match access-group name VOICE3550G-Dist(config)#class-map match-all GOLD-DATA3550G-Dist(config-cmap)#description Mission Critical Traffic3550G-Dist(config-cmap)#match access-group name GOLD-DATA3550G-Dist(config)#class-map match-all VOICE-CONTROL3550G-Dist(config-cmap)#description VoIP Control Traffic (SCCP, H225, H254, MGCP)3550G-Dist(config-cmap)#match access-group name VOICE-CONTROL


3550G-Dist(config)#policy-map DISTRIBUTION-C3550-UPLINK-IN3550G-Dist(config-pmap)#description Set DSCP PerHopBehavior Label for VOIP Control and Bearer Traffic3550G-Dist(config-pmap)#class VOICE-CONTROL3550G-Dist(config-pmap-c)#set ip dscp 263550G-Dist(config-pmap)#class VOICE3550G-Dist(config-pmap-c)#set ip dscp 463550G-Dist(config-pmap)#class GOLD-DATA3550G-Dist(config-pmap-c)#set ip dscp 18

Step 4 Apply the policy to an interface so that traffic entering the network through this port is classified with the appropriate DSCP PHB Label EF and AF31 for VoIP Bearer, and Control respectively.

3550G-Dist(config)#int g 0/123550G-Distconfig-if)#service-policy input DISTRIBUTION-C3550-UPLINK-IN

Configuring CoS or DSCP Trust

Additionally, you need to enable the Catalyst 3550 to trust DSCP or CoS depending on the capabilities of the access-layer switch attached. In this example, port 0/1 is attached to a Layer 3-aware access device and can trust DSCP arriving from it. Ports 0/2 and 0/3 are attached to Layer 2-only access devices, so the switch needs to trust CoS.

Step 1 Configure trust for DSCP.

3550G-Dist(config)#int g0/1 3550G-Dist(config-if)#mls qos trust DSCP

Step 2 Configure trust for CoS.

3550G-Dist(config-if)#int g0/2 3550G-Dist(config-if)#mls qos trust cos 3550G-Dist(config-if)#int g0/3 3550G-Dist(config-if)#mls qos trust cos


956467




Example 3-25 Displaying the QoS CoS- Mapping Information

3550G-Dist#show mls qos maps Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------- dscp: 0 8 16 26 34 46 48 56

Example 3-26 Displaying QoS Queuing Strategy

3550G-Dist#show mls qos interface queueing GigabitEthernet0/1Ingress expedite queue: disEgress expedite queue: enawrr bandwidth weights:qid-weights 1 - 25 2 - 25 3 - 25 4 - 25 when expedite queue is disabledDscp-threshold map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 01 01 01 01 2 : 01 01 01 01 01 01 01 01 01 01 3 : 01 01 01 01 01 01 01 01 01 01 4 : 01 01 01 01 01 01 01 01 01 01 5 : 01 01 01 01 01 01 01 01 01 01 6 : 01 01 01 01 Cos-queue map:cos-qid 0 - 1 1 - 1 2 - 2 3 - 2 4 - 3 5 - 4 6 - 4 7 - 4


show mls qos maps Displays the QoS CoS mapping information. Example 3-25

show mls qos interface queueing Displays the QoS queuing strategy. Example 3-26


Example 3-27

show mls qos interface interface Displays QoS information for the specified interface.

Example 3-28


956467



3550G-Dist#show policy-map interface

GigabitEthernet0/12

service-policy input: DISTRIBUTION-C3550-UPLINK-IN



class-map: GOLD-DATA (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: access-group name GOLD-DATA


Example 3-28 Displaying QoS Information for the Interface

3550G-Dist#show mls qos int g0/1GigabitEthernet0/1trust state: trust dscpCOS override: disdefault COS: 0DSCP Mutation Map: Default DSCP Mutation Map

3550G-Dist#show mls qos int g0/2GigabitEthernet0/2trust state: trust cosCOS override: disdefault COS: 0DSCP Mutation Map: Default DSCP Mutation Map

3550G-Dist#show mls qos int g0/3GigabitEthernet0/3trust state: trust cosCOS override: disdefault COS: 0DSCP Mutation Map: Default DSCP Mutation Map


956467

Chapter 3 QoS in an AVVID-Enabled Campus NetworkSummary

SummaryThe following general guidelines and recommendations apply when configuring a Cisco AVVID network in a campus environment:

• Multiple queues are required on all interfaces to guarantee that loss, delay, and delay variation will not affect voice, video, mission-critical data.

• Use service policies to set the ToS and CoS classification marking for those devices that cannot set the classification and for those devices that you cannot trust.

• Never allow PC applications to send traffic at a CoS or ToS value of 3-7. Use the ability of the access-layer switches to manipulate the IP phone’s classification and marking ability and set the appropriate trust for access-layer ports that directly support PCs.

• Remember that QoS in the campus is not a bandwidth management issue as much as it is a buffer management issue. TX queue congestion can cause packet loss, which can adversely affect performance of applications that are sensitive to loss, delay, and delay variation.


956467

Chapter 3 QoS in an AVVID-Enabled Campus NetworkSummary


956467


C H A P T E R 4
QoS in an AVVID-Enabled Wide-Area Network
This chapter provides information about implementing QoS in an AVVID-enabled wide-area network (WAN). It includes the following:

• Overview

• QoS Recommendations for WAN Aggregation Routers

• QoS Recommendations for Remote Branch Routers

• Verifying QoS


OverviewA fundamental principle of economics states that the more scarce a resource, the more efficiently it should be managed. In an enterprise network infrastructure, bandwidth is the prime resource and it is scarcest over the WAN. Therefore, the case for efficient bandwidth optimization via QoS technologies is strongest over the WAN, especially for enterprises that are converging their voice, video, and data networks.

This chapter provides design guidance for enabling QoS over the WAN. It is important to note that the recommendations put forward in this chapter are not autonomous. They are critically dependent on the recommendations discussed in Chapter 3, “QoS in an AVVID-Enabled Campus Network.”

This chapter focuses strictly on the WAN components of the Cisco AVVID Network Infrastructure (as shown in Figure 4-1), specifically the:

• WAN aggregation routers

• Remote-branch routers

• WAN media

For general information about using QoS for voice and video, see Chapter 1, “Overview.”


Chapter 4 QoS in an AVVID-Enabled Wide-Area NetworkQoS Toolset

Figure 4-1 WAN Infrastructure

QoS ToolsetThe challenges of packet loss, delay, and delay variation can be addressed through the application of various QoS tools.

This section provides information about the use of QoS tools in WAN environments. For general information about the QoS Toolset, see the “What is the Quality of Service Toolset?” section on page 1-12.

ClassificationIn a WAN environment, classification is generally DSCP-based. NBAR can also be used for classification within the WAN. For information on these two tools, see the “Classification Tools” section on page 1-12.

ProvisioningWith respect to provisioning tools in a WAN environment, special consideration should be given to the following:

• Policers and Shapers

• Link-Fragmentation and Interleaving

• TX Ring

Policers and Shapers

The principle drawback in strict traffic policing is that TCP will retransmit dropped packets and will throttle flows up and down, until the all the data is sent (or the connection times-out). Such TCP ramping behavior results in inefficient use of bandwidth (both over-utilizing and under-utilizing the WAN links). Because shaping usually delays packets rather than dropping them, it smooths flows and allows for more efficient use of WAN bandwidth. Therefore, shaping is more suitable in the WAN than policing. This is especially in the case with NBMA WAN media where physical access speed can vary between two endpoints, such as Frame Relay and ATM (as shown in Figure 4-2).

Si

Si

Si

Si

IP

IP

IP

IP

IP

IP

IP

IPIP phonesAccess

Distribution Core WANaggregator

WAN

Branchrouter

Access IP phones

8103

1


956467

Chapter 4 QoS in an AVVID-Enabled Wide-Area NetworkQoS Toolset

Figure 4-2 Varying Access Speeds in NBMA Networks Cause Delay and Drops

Link-Fragmentation and Interleaving

For slow-speed (768 kbps or below) WAN connections it is necessary to provide a mechanism for LFI. A data frame can only be sent to the physical wire at the serialization rate of the interface. This serialization rate is the size of the frame divided by the clocking speed of the interface. For example, a 1500 byte frame takes 214 ms to serialize on a 56 kbps circuit. If a delay-sensitive voice packet is behind a large data packet in the egress interface queue, the end-to-end delay budget of 150-200 msec could be exceeded. Additionally, even relatively small frames can adversely affect overall voice quality by simply increasing the delay variation to a value greater than the size of the adaptive jitter buffer at the receiver.

In WANs, two tools are available for LFI: MLP LFI (for point-to-point links), and FRF.12 (for Frame Relay links).

Tip For more information on FRF.12, see Configuring FRF.12 Fragmentation on Switched PVCs.

TX Ring

On all PPP and MLP interfaces, the TX ring buffer size is automatically configured. These default buffer values can not be changed. On Frame Relay links, the TX ring is for the main interface, which all sub-interfaces use. The default value is 64 packets. This may need to be changed if the sub-interface is very small or there are many sub-interfaces. Otherwise, TX rings need to be adjusted on low-bandwidth ATM PVCs, where they should be set to a value of 3. Table 4-1 shows the default TX ring values for WAN Interfaces.

Table 4-1 Default Tx Ring Values

Frame Relay,ATM

CentralSite

T1

T1

RemoteSites

Result:Buffering that will cause delay and,eventually, dropped packets

128 kbps

256 kbps

512 kbps

768 kbps

8103

9

Media Default TX-Ring Buffer Sizing (packets)

PPP 6

MLP 2

ATM 8192 (Must be changed for low speed VCs.)

Frame Relay 64 (per main T1 interface)


956467

Chapter 4 QoS in an AVVID-Enabled Wide-Area NetworkQoS Recommendations for WAN Aggregation Routers

Modular QoS Command-Line Interface The Modular QoS CLI (MQC) was developed with the objective of making QoS configuration more consistent across platforms. MQC is a syntax structure for QoS policies, consisting of three parts:

• class-map statement— classifies traffic

• policy-map statement— defines the treatment for the various classes of traffic

• service-policy statement—binds the policy to an interface and specifies direction

MQC offers simplicity and consistency in policy definition as its main advantages. MQC also supports the ability to define policies within policies (hierarchical policies). Hierarchical policies are essential for deploying AVVID policies on distributed Frame Relay WAN aggregators. Also, MQC has associated with it an SNMPv2 MIB (CISCO-CLASS-BASED-QOS-MIB), which provides detailed, granular visibility for QoS monitoring and management.

Tip For more information, see Modular Quality of Service Command Line Interface in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2.

For hierarchical policies, see the Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example.

And for the MIB, see the Cisco Class-Based QoS Configuration and Statistics MIB.

QoS Recommendations for WAN Aggregation RoutersThis section contains information about using QoS in WAN aggregation routers. It covers the following:

• Classifying and Provisioning for Voice on the WAN Edge

• Classifying and Provisioning for Video on the WAN Edge

• Classifying and Provisioning for Data on the WAN Edge

• Link-Specific WAN QoS Recommendations

• Summary Configurations

Classifying and Provisioning for Voice on the WAN EdgeOn the WAN edges (both at the WAN aggregator and the remote-branch), voice traffic needs to be assigned to an LLQ and voice control traffic needs a minimum bandwidth guarantee (CBWFQ).

The bandwidth required for LLQ traffic can be expressed quantitatively (in absolute kbps) or it can be expressed relatively (as of IOS 12.2.2T) using the percent keyword. This keyword can enable increased modularity of configuration and simplification of management. Expressing the bandwidth reservation in absolute kbps or as a percentage is at the administrator's discretion.

Note If the percent keyword is used for one LLQ provisioning, then it must be used for all other LLQ provisioning (as in the case of voice and video). Likewise, if an LLQ is provisioned in terms of absolute kbps, then any additional LLQs must also be provisioned in absolute kbps.


956467


Tip For more information on the percent keyword, see Low Latency Queueing with Priority Percentage Support.

In the following configuration for voice only over a T1 link:

• Voice is assigned to an LLQ.

• Voice control traffic is guaranteed.

• All non-voice traffic is assigned to a default queue to receive weighted-fair queueing.

class-map match-all VOICE match ip dscp ef!class-map match-all VOICE-CONTROL match ip dscp af31!!policy-map WAN-EDGE class VOICE priority percent 33 class VOICE-CONTROL bandwidth percent 2 class class-default fair-queue

Or:

class-map match-all VOICE match ip dscp ef!class-map match-all VOICE-CONTROL match ip dscp af31!!policy-map WAN-EDGE class VOICE priority 506 class VOICE-CONTROL bandwidth percent 2 or bandwidth 30 class class-default fair-queue

DSCP keywords and decimal values are completely synonymous (DSCP EF is the exactly the same as DSCP 46). Both refer to a value of 101110 in the first 6 bits of the ToS byte.

Note At the time of writing, IOS 12.2(8)T converts DSCP keywords to their decimal equivalents in the running configuration.

Note Remember that this policy does not take effect until it is bound to an interface with a service-policy statement. Service-policy statements are discussed in the “Link-Specific WAN QoS Recommendations” section.

For more information about LLQ and CBWFQ, see “Scheduling Tools” section on page 1-17.


956467


Classifying and Provisioning for Video on the WAN EdgeOn the WAN edges (both at the WAN-aggregator and the remote-branch), video conferencing traffic should to be assigned to an LLQ. The video stream minimum bandwidth guarantee should be the size of the stream plus an additional 20%. Also, the LLQ burst parameter should be set to 30000 bytes per 384 kbps stream.

Tip Additional details on bandwidth provisioning for video conferencing are explained in the IP Videoconferencing Solution Reference Network Design Guide.

In the following configuration for video only over a T1 link:

• Video conferencing traffic is assigned to an LLQ.

• All non-video traffic is assigned to a default queue for weighted-fair queueing.

class-map match-all VIDEO match ip dscp af41!!policy-map WAN-EDGE class VIDEO priority 460 30000 class class-default fair-queue


Classifying and Provisioning for Data on the WAN EdgeMost enterprises have many applications that can be considered mission-critical (Gold). However, if too many applications are classified as mission-critical, they will contend amongst themselves for bandwidth and the result will be a dampening QoS effectiveness. A regular FIFO link (with 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 a maximum of three applications as mission-critical (Gold).

Mission-critical applications should be marked with different AF drop-preference values to distinguish them from each other. These distinctions will provide more granular visibility in managing and monitoring application traffic and aid in provisioning for future requirements.

Similar arguments can be made for having no more than three applications in a guaranteed-bandwidth (Silver) class of applications. You should also mark these applications with different AF drop-preference values.

Default traffic is automatically marked as best effort (DSCP 0). However, non-critical bandwidth-intensive traffic could be marked differently, 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.

For information on the recommended DSCP traffic classifications for data, see Table 1-3 on page 1-15.


956467


It is imperative that DSCP classification be performed on all packets prior to their arriving at the WAN edges. This allows queueing and congestion-avoidance to be performed at the WAN edge based strictly on DSCP markings, which reduces WAN aggregator CPU overhead.

Note The default class-map match setting is match-all. Therefore, when you attempt to classify mutually-exclusive traffic flows (such as differing DSCP values), it is important to explicitly use the match-any qualifier when defining the class-map.

Example 4-1 shows how four classes of traffic (gold, silver, bronze, and less-than-best-effort) can be classified into three queues.

Example 4-1 Four Classes in Three Queues

ip cef For distributed platforms, use ip cef distributed.!…!class-map match-any GOLD-DATA match ip dscp af21 match ip dscp af22 match ip dscp af23!class-map match-any SILVER-DATA match ip dscp af11 match ip dscp af12 match ip dscp af13!policy-map WAN-EDGE class GOLD-DATA bandwidth percent 25 random-detect dscp-based class SILVER-DATA bandwidth percent 15 random-detect dscp-basedclass class-default fair-queue random-detect dscp-based random-detect dscp 0 96 128 10 The queue depth and thresholds are increased for the default

random-detect dscp 2 70 128 10 queue. This allows more traffic and increases the portability (to random-detect dscp 4 58 128 10 Frame Relay Traffic-Shaping [FRTS] interfaces and VIP platforms)random-detect dscp 6 44 128 10 of the configuration.

The best effort traffic and the less-than-best-effort traffic (DSCP 2, 4, 6) share the default queue, but the random-detect thresholds have been adjusted such that less-than-best-effort traffic is dropped significantly sooner than regular best-effort traffic.

Example 4-2 shows how four classes of traffic (gold, silver, bronze, and less-than-best-effort) can be classified into four queues.


956467


Example 4-2 Four-Classes in Four Queues

ip cef!…!class-map match-any GOLD-DATA match ip dscp af21 match ip dscp af22 match ip dscp af23!class-map match-any SILVER-DATA match ip dscp af11 match ip dscp af12 match ip dscp af13!class-map match-any <BE-DATA match ip dscp 2 match ip dscp 4 match ip dscp 6!policy-map WAN-EDGE class GOLD-DATA bandwidth percent 20 random-detect dscp-based class SILVER-DATA bandwidth percent 15 random-detect dscp-based class <BE-DATA bandwidth percent 5 random-detect dscp-based random-detect dscp 2 32 40 10 random-detect dscp 4 28 40 10 random-detect dscp 6 24 40 10 class class-default fair-queue

For distributed platforms, use ip cef distributed and use:

class <BE-DATAbandwidth percent 5random-detect dscp-basedrandom-detect dscp 2 70 128 10random-detect dscp 4 58 128 10random-detect dscp 6 44 128 10

Although it may appear contradictory that less-than-best-effort traffic is assigned a minimum bandwidth guarantee, the logic is based on the fact that CBWFQ will drop packets from a given class when the link is congested and the particular queue for the traffic class is full. Therefore, during times of congestion, all applications designated less-than-best-effort will receive a maximum of 5% of the pipe and then be dropped. Also, the random-detect thresholds have been adjusted to drop less-than-best-effort traffic in order of importance (6 before 4 before 2, which corresponds to the AFxy drop-preference model).

This design is more efficient than strict policing, as these bandwidth-intensive, non-critical applications have the ability to make use of additional bandwidth if it is available.



956467


For more information about classification and provisioning tools, see “Classification Tools” section on page 1-12 and “Provisioning Tools” section on page 1-22.

Link-Specific WAN QoS RecommendationsThis section contains configuration recommendations for WAN QoS on a variety of high-speed (over 768 kbps) and slow-speed (768 kbps and less) links. It includes the recommendations for the following:

• High-Speed Point-to-Point Links

• Slow-Speed Point-to-Point Links

• High-Speed Frame Relay Links

• Distributed-Platform High-Speed Frame Relay Links

• Slow-Speed Frame Relay Links

• Distributed-Platform Slow-Speed Frame Relay Links

• High-Speed ATM Links

• Slow-Speed ATM Links

• ATM-to-Frame Relay Recommendations

• ISDN Recommendations

High-Speed Point-to-Point Links

High-speed point-to-point links can be configured as MLP links, PPP links, or HDLC links. An advantage of MLP is that future expansion is easier to manage as there are fewer configuration changes required if an additional link to a remote site is added.

Note cRTP can be used on high-speed point-to-point links, but do so with caution. CPU performance should first be evaluated when enabling cRTP on high-speed links.

For more information on cRTP, see “Provisioning Tools” section on page 1-22 and “When to Enable cRTP” section on page A-5.

Example 4-3 illustrates how MQC policies can be applied to a high-speed MLP link.

Example 4-3 High-Speed MLP Link

interface Multilink40 description MLP Link to BRANCH#40 bandwidth 1536 ip address 10.200.40.1 255.255.255.252 service-policy output WAN-EDGE This command applies the MQC policy to the interface. ppp multilink multilink-group 40!…!


956467


interface Serial0/0 description MLP GROUP 40 Member bandwidth 1536 no ip address encapsulation ppp ppp multilink multilink-group 40

The following commands can be used to verify that a voice, video and data QoS policies have been applied correctly to a MLP interface.

• show policy

• show policy interface

• show interface

• show queue

For more information, see the “Verifying QoS” section on page 4-34.

Example 4-4 illustrates how MQC policies can be applied to a high-speed PPP link.

Example 4-4 High-Speed PPP Link

interface Serial0/1 description PPP Link to BRANCH#40 bandwidth 1536 ip address 10.200.40.1 255.255.255.252 encapsulation ppp service-policy output WAN-EDGE This command applies the MQC policy to the interface.

Example 4-5 illustrates how MQC policies can be applied to a high-speed HDLC link.

Example 4-5 High-Speed HDLC Link

interface Serial0/1 description HDLC Link to BRANCH#40 ip address 10.200.40.1 255.255.255.252 service-policy output WAN-EDGE This command applies the MQC policy to the interface.

Slow-Speed Point-to-Point Links

For slow-speed point-to-point WAN links, link-fragmentation and interleaving is required to minimize serialization delay. MLP must be used on PPP links below 768 kbps, as MLP LFI is the only mechanism for reducing serialization delay on point-to-point links.

Enabling LFI on MLP links requires two additional commands, as shown in Example 4-6.

Note Optionally, cRTP can be implemented on slow point-to-point links. cRTP is best utilized on slow-speed links after the CPU performance impact has been evaluated.


Provided the bandwidth savings and overall network design justify implementing cRTP, the following commands can be used.


956467


Example 4-6 Slow-Speed MLP Links

interface Multilink40 description MLP Link to BRANCH#40 bandwidth 768 ip address 10.200.40.1 255.255.255.252 ip tcp header-compression iphc-format This command is automatically added when cRTP is enabled. service-policy output WAN-EDGE This command applies the MQC policy to the interface. ppp multilink ppp multilink fragment-delay 10 This command sets the maximum delay to 10 milliseconds. ppp multilink interleave This command enables LFI for MLP. multilink-group 40 ip rtp header-compression iphc-format This command enables cRTP.!!interface Serial0/0 description MEMBER MLP GROUP 40 bandwidth 768 no ip address encapsulation ppp no fair-queue ppp multilink multilink-group 40

High-Speed Frame Relay Links

Frame Relay networks are the most popular WANs in use today because of the low costs associated with them. Frame Relay is an NBMA technology that uses oversubscription to achieve costs savings. To manage oversubscription, a traffic shaping mechanism must be used. FRTS is the shaping mechanism for Frame Relay WAN media. FRTS requires the following parameters to be defined:

• Committed Information Rate

• Committed Burst Rate

• Excess Burst Rate

• Minimum CIR

Tip For more information, see Configuring Frame Relay Traffic Shaping.

Committed Information Rate

Recommendation: CIR set to PVC speed.

In most Frame Relay networks, a central site uses a T1 link, or something faster, to terminate WAN connections from many remote offices. The central site sends data out at 1.536 Mbps, while a remote site may have only a 56 kbps circuit. In addition, there is typically a many-to-one ratio of remote offices to central hubs. It is possible for all the remote sites to send traffic at a rate that can overwhelm the T1 at the hub. Both of these scenarios can cause frame buffering in the provider network that introduces loss, delay, and delay variation.

The only solution is to use traffic shaping at both the central and remote routers and to define a consistent Committed Information Rate (CIR) at both ends of the Frame Relay DLCI. For high-speed (greater than 768 kbps) Frame Relay links, the CIR should be set to the Permanent Virtual Circuit (PVC) speed.


956467


Committed Burst Rate

Recommendation: Bc set to CIR/100.

With Frame Relay networks, you also need to consider the amount of data a node can transmit at any given time. A 56 kbps PVC can transmit a maximum of 56 kbps of traffic in 1 second. How this second is divided is called the interval (Tc). The amount of traffic a node can transmit during this interval is called the Committed Burst (Bc) rate.

By default, Cisco IOS sets the Bc to CIR/8. The formula for calculating the Tc is:

Tc = Bc / CIR

For example, with a CIR of 56 kbps:

Tc = 7000 / 56000 or 125 ms

This example is illustrated in Figure 4-3.

Figure 4-3 FRTS Delay with Default Bc (CIR/8)

In this example, after a router sends its allocated 7000 bits, it must wait 120.5 ms before sending the next batch of traffic.While this is a good default value for data, it is a very bad choice for voice. By setting the Bc value to a much lower number, you can decrease the interval, which means the router will send traffic more frequently.

The optimal configured value for Bc is CIR/100, which results in a 10 ms interval (Tc=Bc/CIR).

Excess Burst Rate

Recommendation: Be set to 0.

If the router does not have enough traffic to send all of its Bc (1000 bits, for example), it can “credit” its account and send more traffic during a later interval. The maximum amount that can be credited to the router's traffic account is called the excess burst (Be) rate. The problem with the Be in Cisco AVVID networks is that this can create a potential for buffering delays within a Frame Relay network (because the receiving side can “pull” the traffic from a circuit only at the rate of Bc, not Bc + Be). Therefore, to remove this potential for buffering delays, it is recommended that you set Be to 0.

Tc = = 125msIMPORTANT!By default,Bc is setto CIR/8

Bc

0

CIR

8103

3

700056000

7 14 21 28 35 42 49 56

0 ms 125 250 375 500 625 750 875 1000

When 7000 bits (Bc) of transmitted credits are exhausted then no more packets can be sent inthat interval. The transmitting router must wait until the next interval to send another burst of

7000 bits. For a T1 line rate, this cycle will translate to 4.5 ms of transmission, followed by 120.5 msof silence. This cycle is repeated eight times in one second, by default. VoIP latency/jitterrequirements cannot tolerate the interpacket delay introduced by the FRTS default Bc.


956467


Minimum CIR

Recommendation: mincir set to CIR.

The minimum CIR is the transmit value a Frame Relay router will “rate down” to when Backward Explicit Congestion Notifications (BECNs) are received. By default, Cisco IOS sets the minimum CIR to CIR/2. However, to maintain consistent service-levels, it is recommended that you disable adaptive shaping and set the minimum CIR equal to the CIR (which means there is no “rating down”).

High-Speed FRTS Parameter Summary

In summary:

• CIR is set to the PVC speed

• Bc is set to CIR/100

• Be is set to 0

• Minimum CIR is equal to the CIR

No LFI mechanism is required on WAN links above 768 kbps.

Note cRTP can be used on high-speed Frame Relay links, but do so with caution on WAN aggregators that serve a large number of remote sites. CPU performance should first be evaluated when enabling cRTP on high-speed links.


Example 4-7 High-Speed Frame Relay Link

interface Serial0/1 description Parent FR Link no ip address encapsulation frame-relay frame-relay traffic-shaping This command enables FRTS on the main interface. !interface Serial0/1.50 point-to-point description FR Link to BRANCH#50 bandwidth 1536 ip address 10.200.50.1 255.255.255.252 frame-relay interface-dlci 150 class FRTS-1536kbps This command applies the FRTS map-class to the DLCI.

!…!map-class frame-relay FRTS-1536kbps frame-relay cir 1536000 frame-relay bc 15360 frame-relay be 0 frame-relay mincir 1536000 no frame-relay adaptive-shaping service-policy output WAN-EDGE This command applies the MQC policy to the FRTS map-class.


956467


Distributed-Platform High-Speed Frame Relay Links

Most policies, when ported to distributed platforms (such as the Cisco 7500 VIP), require little more than ensuring that CEF is running in distributed mode. However, because FRTS is not supported in a distributed environment, another shaping tool is required. Distributed Traffic Shaping (dTS) can be used in conjunction with hierarchical MQC policies to achieve a similar effect on traffic flows over distributed Frame Relay WAN links.

However, the Cisco 7500 VIP requires the interval (Tc) to be defined in an increment of 4 ms. Because the target interval for all platforms is 10 ms, which is not evenly divisible by 4 ms, the recommendation for Cisco 7500 VIP is to use an interval of 8 ms. The interval can be set to 8 ms by defining the burst using the following formula:

Bc = CIR/125

For example, for a T1 (1.536 Mbps), the Bc for an 8 ms interval is 12288 bits.

As before, the Be is set to 0. Additionally, it is recommended that you increase the queue-limit from the default of 126 packets to reduce the potential for tail-drops from the shaping queue. To provision the shaping queue to allow for shaping for up to a 10 second period, use the following formula:

Queue-limit = (CIR * 10) / (MTU * 8)

For example, the queue-limit for a T1 circuit (with an MTU of 1500) would be calculated as:

Queue-limit = (1536000*10)/(1500*8) or 1280 packets

Tip For more information, see Configuring Distributed Traffic Shaping.

Example 4-8 illustrates using dTS and hierarchical MQC policies for a distributed-platform Frame Relay WAN aggregator.

Example 4-8 Distributed-Platform High-Speed Frame Relay Link

ip cef distributed!…!policy-map dTS-1536kbps class class-default shape average 1536000 12288 0 This command is the dTS shaper (CIR at T1 rate, Bc=CIR/125). queue-limit 1280 This command increases the queue limit. service-policy WAN-EDGE This command applies the LLQ/CBWFQ policies within the dTS! policy.interface Serial1/0/1 bandwidth 1536 no ip address encapsulation frame-relay no fair-queue!interface Serial1/0/1.50 point-to-point description FR Link to BRANCH#50 bandwidth 1536 ip address 10.200.50.1 255.255.255.252 frame-relay interface-dlci 150 class dTS-TO-FRTS-1536kbps This command binds the Frame Relay map-class to the DLCI. !…


956467


!map-class frame-relay dTS-TO-FRTS-1536kbps no frame-relay adaptive-shaping service-policy output dTS-1536kbps This command applies the dTS policy to the FR map-class.

The symbolic name of “DTS-1536kbps” represents distributed traffic shaping (DTS) and the link speed.

The following commands can be used to verify that a voice, video and data QoS policies have been applied correctly to a Frame Relay link.

• show policy interface


Slow-Speed Frame Relay Links

Similar to high-speed Frame Relay links, slow-speed Frame Relay links require the following parameters to be defined:

• Fragment Sizes

• Committed Information Rate and Burst

Fragment Sizes

As with all slow links, slow Frame Relay links require a mechanism for fragmentation and interleaving. In the Frame Relay environment, the tool for accomplishing this is FRF.12. Unlike MLP LFI, which takes the maximum serialization delay as a parameter, FRF.12 requires the actual fragment sizes to be defined. This requires some additional calculations, as the maximum fragment sizes vary by link speed. These fragment sizes can be calculated by dividing the recommended 10 ms of delay by 1 byte of traffic at the provisioned line-clocking speed:

Fragment Size = (Maximum Allowed Jitter * Link Speed in kbps) / 8

For example, the calculation for the maximum fragment size for a 56 kbps circuit is:

Fragment Size = (10 ms * 56) / 8 or 70 Bytes

Fragment sizes that correspond to the recommended minimum serialization delay of 10 ms per link are shown in second column of Table 4-2.

Committed Information Rate and Burst

With FRTS, it is important to note that Frame Relay header flags and the CRC (which are added by the interface driver) are not taken into account in the shaping algorithm. When the flags and CRC are included in the CIR calculation, the value is determined by the following formula:

CIR = (Link-Speed * Maximum-Frame-Size) / (Maximum-Frame-Size + 4)

For high-speed links, this value works out to around 99%. For example, a on a T1 link:

CIR = 1536000 * 1500 / (1500 + 4)CIR = 1536000 * 0.99734CIR = 1531914

which is 99.7% of the link speed.

While this calculated value could be used, the difference is so negligible that for simplicity's sake the CIR could just as well be set to the link-speed (as recommended in the “High-Speed Frame Relay Links” section on page 4-11).


956467


Because a flag and CRC need to be added for every fragment, enabling fragmentation directly affects the CIR value. Therefore, the recommended CIR values as calculated by the formula above (and rounded down to the nearest byte-boundary) are shown in the third column of Table 4-2 and the Bc values (CIR/100, rounded) are shown in the fourth column. As before, Be is set to 0 and the minimum CIR is set to the CIR.

Table 4-2 Recommended Fragment Sizes, CIRs and Bursts for Slow-Speed FR Links

Note cRTP can also be implemented on slow Frame Relay links. cRTP is best utilized on slow-speed links after the CPU performance impact has been evaluated.


Example 4-9 illustrates a MQC policy applied to a slow-speed (512 kbps) Frame Relay link.

Example 4-9 Slow-Speed Frame Relay Link

interface Serial0/1 description Parent FR Link no ip address encapsulation frame-relay frame-relay traffic-shaping This command enables FRTS on the main interface. !interface Serial0/1.50 point-to-point description FR Link to BRANCH#50 bandwidth 512 ip address 10.200.50.1 255.255.255.252 frame-relay interface-dlci 150 class FRTS-512kbps This command applies the FRTS map-class to the DLCI. frame-relay ip rtp header-compression This command enables cRTP. !…!map-class frame-relay FRTS-512kbps frame-relay cir 508816 frame-relay bc 5090 frame-relay be 0 frame-relay mincir 508816 no frame-relay adaptive-shaping service-policy output WAN-EDGE This command applies the MQC policy to the FRTS map-class. frame-relay fragment 640 This command enables FRF.12.

PVC SpeedMaximum Fragment Size (for 10 ms delay)

Recommended CIR Values Recommended Bc Values

56 kbps 70 Bytes 52968 bps 530 bits per Tc







956467


The following commands can be used to verify that a voice, video and data QoS policies have been applied correctly to a Frame Relay link.

• show policy

• show frame-relay pvc


Distributed-Platform Slow-Speed Frame Relay Links

Slow-speed Frame Relay policies on a distributed platform require the following:

• CEF must be enabled in distributed mode

• dTS policy (with nested queueing policies)

• Bc set to CIR/125

• Be set to 0

• Queue-limit can be increased to (CIR*10) / (MTU*8)

• FRF.12 must be enabled

• CIR values need to reflect fragmentation headers and CRCs

• CIR must be a multiple of 8000

Note cRTP can be enabled.


One constraint of class-based shaping (which includes dTS) is that the CIR must be a multiple of 8000. Therefore, the calculated FRTS CIR values from Table 4-2 must be rounded down to the nearest multiple of 8000 for dTS.

Because the Cisco 7500 requires that an interval (Tc) be defined in 4 ms increments, the FRTS optimal recommendation of Bc=CIR/100 (which sets the interval to equal 10 ms) cannot be used. The nearest (rounded-down) 4 ms interval is 8 ms. To set an 8 ms interval, the Bc value must be defined as CIR/125. Be is held at 0.

Table 4-3 shows the recommended fragmentation, CIR, Bc and queue-limit values for distributed-platform, slow-speed Frame Relay links.

Table 4-3 Distributed-Platform Fragmentation and (dTS) Shaping Values

PVC Speed Fragment Sizes CIR Bc dTS Queue-Limits

56 kbps 70 Bytes 48000 bps 384 bits per Tc Default (126 packets)



256 kbps 320 Bytes 248000 bps 1984 bits per Tc 213 packets




956467


Example 4-10 illustrates a MQC policy applied to a slow-speed (512 kbps) Frame Relay link connecting to a distributed-platform.

Example 4-10 Distributed-Platform Slow-Speed Frame Relay Link

ip cef distributed!…!policy-map dTS-512kbps class class-default shape average 504000 4032 0 This command sets the dTS shaper. queue-limit 427 This command increases the queue limit. service-policy WAN-EDGE This command applies the LLQ/CBWFQ policies within the dTS! policy. …!interface Serial1/0/1 bandwidth 1536 no ip address encapsulation frame-relay no fair-queue!interface Serial1/0/1.50 point-to-point description FR Link to BRANCH#50 bandwidth 512 ip address 10.200.50.1 255.255.255.252 frame-relay interface-dlci 150 class dTS-TO-FRTS-512kbps This command binds the FR map-class to the DLCI. frame-relay ip rtp header-compression This command enables cRTP. !…!map-class frame-relay dTS-TO-FRTS-512kbps no frame-relay adaptive-shaping service-policy output dTS-512kbps This command applies the dTS policy to the FR map-class. frame-relay fragment 640 This command enables FR.12.

High-Speed ATM Links

Class-based policies are only recommended on ATM hardware that supports per-VC traffic-shaping (for example, ATM Enhanced Port Adaptors [PA-A3] for the Cisco 7200/7500 routers and OC3 Network Modules for Cisco 3600 routers). Example 4-11 illustrates how MQC policies can be applied directly to ATM PVCs.

Example 4-11 High-Speed ATM Links

ip cef In distributed platforms, use ip cef distributed. !…!interface ATM4/0 description Parent ATM Link bandwidth 3000 no ip address no atm ilmi-keepalive!


956467


interface ATM4/0.60 point-to-point description ATM Link to BRANCH#60 bandwidth 3000 ip address 10.200.60.1 255.255.255.252 pvc BRANCH#60 0/60 vbr-nrt 3000 3000 This command sets the high ATM AAL5 traffic contract. tx-ring-limit 3 This command reduces delay caused by the TX ring buffer. service-policy output WAN-EDGE This command applies the MQC policy to the ATM PVC.

Tip For more information, see Configuring ATM.

Slow-Speed ATM Links

Prior to IOS 12.1(5)T, there was no mechanism for fragmenting-and-interleaving over low-speed ATM links. At that time, a new standard of applying MLP LFI over ATM provided the required minimization of serialization delay for slow ATM links. Additionally, MLP over ATM requires the MLP bundle to classify the outgoing packets before they are sent to the ATM VC.

Note There are two virtual-access interfaces created for each virtual-template. One is the Layer 2 PPP-only virtual-access. The other is the “bundle” virtual-access interface. It is the bundle interface that takes on all of the properties of Layer 3 (the IP address, cRTP if configured, etc.). CBWFQ can be applied only to the bundle interface.

MLP uses the bundle virtual-access interface to reassemble packets received over individual links and to fragment packets sent out over individual links. The bundle interface inherits its configuration from the virtual-template specific to MLP.

Example 4-12 illustrates how virtual-templates and MLP LFI can be applied in such a scenario.

Example 4-12 Slow-Speed ATM Link Using Virtual-Templates

ip cef In distributed platforms, use ip cef distributed. !…!interface ATM4/0 bandwidth 768 no ip address no atm ilmi-keepalive!interface ATM4/0.60 point-to-point pvc BRANCH#60 0/60 vbr-nrt 768 768 This command sets the high ATM AAL5 traffic contract. tx-ring-limit 3 This command reduces the delay caused by the TX ring buffer. protocol ppp Virtual-Template60 This command binds the virtual template to the PVC. !interface Virtual-Template60 bandwidth 768 ip address 10.200.60.1 255.255.255.252 service-policy output WAN-EDGE This command sets the MQC policies for voice and data. ppp multilink ppp multilink fragment-delay 10 This command sets the maximum delay to 10 ms. ppp multilink interleave This command enables MLP LFI.


956467


Note cRTP is only supported on ATM PVCs (via PPPoATM) as of IOS 12.2(2)T. For more information, see IP Header Compression Enhancement—PPPoATM and PPPoFR Support.

When using virtual-templates for low-speed ATM links, keep the following in mind:

• The dynamic nature of virtual-template interfaces may make network management unwieldy.

• MLP over ATM can only be supported on hardware that supports per-VC traffic shaping.

An alternative option is to use VC-bundling, in which you have 2 (or more) PVCs with different traffic contracts. For example, one PVC (for voice) would have vbr-nrt, while another (for data) would be ubr.

Example 4-13 Slow-Speed ATM Link Using VC-Bundling

ip cef!…!vc-class atm VOICE-VC-256

vbr-nrt 256 256 tx-ring-limit 3 precedence 5 no bump traffic protect vc!vc-class atm DATA-VC-512 ubr 512 tx-ring-limit 3 precedence other!…!interface ATM3/0 no ip address no atm ilmi-keepalive!interface ATM3/0.60 point-to-point ip address 10.200.60.1 255.255.255.252 bundle BRANCH#60 pvc-bundle BRANCH60-DATA 0/60 class-vc DATA-VC-512 service-policy output WAN-EDGE-DATA Only data policies are required. pvc-bundle BRANCH60-VOICE 0/600 class-vc VOICE-VC-256

One drawback to the multiple PVC design is that data can never get access to the voice (or video) VCs, even if there is available bandwidth in them. This forces sub-optimal consumption of WAN bandwidth.

The following commands can be used to verify that a voice, video and data policies have been applied correctly to an ATM PVC-bundle.

• show policy

• show atm bundle

• show policy interface atm

• show atm vc

• show atm pvc



956467


ATM-to-Frame Relay Recommendations

Many enterprises are deploying AVVID over networks that use Frame Relay at the remote sites and ATM at the central location. The conversion is accomplished through ATM to Frame Relay Service Interworking (FRF.8) in the carrier network.

FRF.12 cannot be used because currently no service provider supports FRF.12 termination in the Frame Relay cloud. In fact, there are no Cisco WAN switching devices that support FRF.12. Tunneling FRF.12 through the service provider's network will do no good because there is no FRF.12 standard on the ATM side. This is a problem because fragmentation is a requirement if any of the remote Frame Relay sites use a circuit speed of 768 kbps or below. However, MLP over ATM and Frame Relay provides an end-to-end, Layer 2, fragmentation and interleaving method for low-speed ATM to Frame Relay FRF.8 Service Interworking links.

FRF.8 Service Interworking is a Frame Relay Forum standard for connecting Frame Relay networks with ATM network. Service Interworking provides a standards-based solution for service providers, enterprises, and end users. In Service Interworking translation mode, Frame Relay PVCs are mapped to ATM PVCs without the necessity for symmetric topologies; the paths can terminate on the ATM side. FRF.8 supports two modes of operation of the IWF for upper-layer user protocol encapsulation:

• Translation mode—maps between ATM and Frame Relay encapsulation. It also supports interworking of routed or bridged protocols.

• Transparent mode—does not map encapsulations but sends them unaltered. This mode is used when translation is impractical because encapsulation methods do not conform to the supported standards for Service Interworking.

MLP for LFI on ATM and Frame Relay Service Interworking networks is supported for transparent mode VCs and translational mode VCs that support PPP translation (FRF 8.1).

To make MLPoFR and MLPoATM interworking possible, the Interworking Switch must be configured in transparent mode and the end routers must be able to recognize both MLPoFR and MLPoATM headers. This is enabled with the frame-relay interface-dlci dlci ppp and protocol ppp commands for Frame Relay and ATM respectively.

When a frame is sent from the Frame Relay side of an ATM to Frame Relay Service Interworking connection, the following should happen to make interworking possible:

1. A packet is encapsulated in MLPoFR header by the sending router

2. The Carrier Switch, in transparent mode, strips off the 2-byte Frame Relay DLCI field and sends the rest of the packet to its ATM interface

3. The receiving router examines the header of the received packet. If the first two bytes of the received packet are 0x03cf, it treats it as a legal MLPoATM packet and sends it to MLP layer for further processing.

When an ATM cell is sent from ATM side of an ATM to Frame Relay Service Interworking connection, the following should happen to make interworking possible:

1. A packet is encapsulated in MLPoATM header by the sending router

2. The Carrier Switch, in transparent mode, prepends 2-byte Frame Relay DLCI field to the received packet and sends the packet to its Frame Relay interface

3. The receiving router examines the header of the received packet. If the first 4 bytes after the 2-byte DLCI field of the received packet is 0xfefe03cf, it treats it as a legal MLPoFR packet and sends it to MLP layer for further processing.

Tip For more information, see Configuring Frame Relay-ATM Interworking.


956467


A new ATM to Frame Relay Service Interworking standard, FRF.8.1, supports MLP over ATM and Frame Relay Service Interworking, but it can be years before all switches are updated to the new standard.

Optimizing Fragment Sizes

When enabling MLP over ATM the fragment size should be optimized such that it fits into an integral number of cells. Otherwise, the bandwidth required could potentially double due to cell padding. For example, if a fragment size of 49 bytes is configured, then this fragment would require 2 cells to transmit (as ATM cells have 48 byte payloads). This would generate 57 bytes of overhead (2 cell headers plus 47 bytes of cell padding), which is more than double the fragment itself.

Tip Currently, IOS does not automatically optimize the fragment sizes (which are indirectly defined by the MLP fragment-delay parameter). Arriving at such optimal sizes requires a fair bit of math, which is well documented in the Multilink PPP over Frame Relay and ATM white paper (internal).

Table 4-4 provides a summary of the optimal fragment-delay parameters for MLP over ATM.

Table 4-4 MLP over ATM Optimal Fragment-Delay Values

Sample ATM-to-Frame Relay Configuration

An ATM-to-Frame Relay configuration is shown below, in two parts:

• Example 4-14 shows the Central Site WAN Aggregator ATM configuration.The Central Site WAN Aggregator ATM configuration is identical to the configuration required for end-to-end low-speed ATM connections implementing MLP LFI.

• Example 4-15 shows the Remote-Branch Frame Relay Configuration.

Example 4-14 Central Site WAN Aggregator ATM Configuration

ip cef For distributed platforms, use ip cef distributed. !…!interface ATM4/0 no ip address no atm ilmi-keepalive!

PVC Speed Optimal Fragment SizeATM Cells (Rounded Up)

ppp multilink fragment-delay value

56 kbps 84 bytes 2 12 ms

64 kbps 80 Bytes 2 10 ms






956467


interface ATM4/0.60 point-to-point pvc BRANCH#60 0/60 vbr-nrt 256 256 This command sets the high ATM AAL5 traffic contract. tx-ring-limit 3 This command reduces the delay caused by the TX ring buffer. protocol ppp Virtual-Template60 This command binds the virtual template to the PVC. !interface Virtual-Template60 bandwidth 256 ip address 10.200.60.1 255.255.255.252 service-policy output WAN-EDGE This command sets the MQC policy for voice and data. ppp multilink ppp multilink fragment-delay 10 This command sets the maximum delay. ppp multilink interleave This command enables MLP LFI.

Example 4-15 Remote-Branch Router Frame Relay Configuration

ip cef!…!interface Serial6/0 description Parent FR Link for BRANCH#60 no ip address encapsulation frame-relay frame-relay traffic-shaping!interface Serial6/0.60 point-to-point description FR Sub-Interface for BRANCH#60 bandwidth 256 frame-relay interface-dlci 60 ppp Virtual-Template60 class FRTS-256kbps!interface Virtual-Template60 bandwidth 256 ip address 10.200.60.2 255.255.255.252 service-policy output WAN-EDGE This command sets the MQC policies for voice and data. ppp multilink ppp multilink fragment-delay 10 This command sets the maximum delay. ppp multilink interleave This command enables MLP LFI.!…!map-class frame-relay FRTS-256kbps frame-relay cir 252832 frame-relay bc 2530 frame-relay be 0 frame-relay mincir 252832 no frame-relay adaptive-shaping

Considerations for MLPoATM and MLPoFR

When using MLP over ATM and MLP over Frame Relay, keep the following in mind:

• MLPoATM can only be supported on platforms that support per-VC traffic shaping (such as ATM Enhanced Port Adaptors for the 7200/7500 and OC3 Network Modules for the 3600).

• MLPoATM requires the MLP bundle to classify the outgoing packets before they are sent to the ATM VC. It also requires that the per-VC queuing strategy for the ATM VC to be FIFO.

• MLP over Frame Relay relies on the FRTS engine to control the flow of packets from MLP bundle to FR VC.

• cRTP is only supported over ATM links as of IOS 12.2(2)T


956467


ISDN Recommendations

When designing VoIP over ISDN networks, remember the following:

• Link bandwidth varies as B channels are added or dropped.

• RTP packets may arrive out of order when transmitted across multiple B channels.

• CAC limitations with Call Manager locations-based CAC.

Variable Bandwidth

ISDN allows B channels to be added or dropped in response to the demand for bandwidth. The fact that the bandwidth of a link varies over time presents a special challenge to the CBWFQ/LLQ queuing mechanisms of IOS. Prior to IOS 12.2(2)T, a policy-map implementing LLQ could only be assigned a fixed amount of bandwidth. On an ISDN interface, IOS assumes that only 64 kbps is available, even though the interface has the potential to provide 128 kbps, 1.544 Mbps, or 2.408 Mbps of bandwidth. By default, the maximum bandwidth assigned must be less than or equal to 75% of the available bandwidth. Hence, prior to IOS 12.2(2)T, only 75% of 64 kbps, or 48 kbps, could be allocated to an LLQ on any ISDN interface. If more was allocated, then an error message was generated when the policy-map was applied to the ISDN interface. This severely restricted the number of VoIP calls that could be carried.

The solution to this problem was introduced in IOS 12.2(2)T with the introduction of the percent keyword to the priority statement. This keyword allows for the reservation of a variable bandwidth percentage to be assigned to the LLQ.

MLP Packet Reordering Considerations

MLP LFI is used for fragmentation and interleaving voice and data over ISDN links. LFI fragments large data packets into smaller fragments and transmits them in parallel across all the B channels in the bundle. At the same time, voice packets are interleaved in between the fragments, thereby reducing their delay. The interleaved packets are not subject to MLP encapsulation. They are encapsulated as regular PPP packets. Hence, they have no MLP sequence numbers and cannot be reordered should they arrive out of sequence. The need to reorder the packet is quite likely. The depth of the various link queues in the bundle may differ, causing RTP packets to overtake each other as a result of the difference in queuing delay. The various B channels may also take different paths through the ISDN network and end up with different transmission delays.

This reordering of packets is not generally a problem for RTP packets. The buffers on the receiving VoIP devices will reorder the packets based on the RTP sequence numbers. However, reordering does become a problem if cRTP is used. The cRTP algorithm assumes that RTP packets are compressed and decompressed in the same order. If they get out of sequence, then decompression will not occur correctly. Therefore, today it is not safe to use cRTP if there is more then one B channel in the MLP bundle. The same restriction applies if you are using MLP over ATM or Frame Relay, in which case cRTP is not possible if there is more then one VC in the bundle.

A solution to the reordering problem is offered by Multiclass Multilink PPP (MCMP). With MCMP, the interleaved packets are given a small header with a sequence number, which allows them to be reordered by the far end of the bundle before cRTP decompression takes place. At the time of this writing, MCMP is not yet supported in IOS.

CallManager CAC Limitations

IP telephony in branch networks are typically based on the centralized call-processing model and use locations-based CAC to limit the number of calls across the WAN. Locations-based CAC does not currently have any mechanism for tracking topology changes in the network. So if the primary link to a


956467


branch goes down and ISDN backup engages, the Call Manager remains ignorant of the occurrence. For this reason, it is critical that the ISDN backup link can handle the same number of VoIP calls as the main link. Otherwise, CAC could ultimately oversubscribe the backup link.

The actual bandwidth of the primary link and the backup link do not need to be identical. They just need to be able to carry the same number of VoIP calls. For example, the backup link may use cRTP while the primary link does not, in which case less bandwidth is required on the backup link to carry the same number of calls as the primary link.

Because of these limitations, it is recommended that the 33% LLQ ceiling be relaxed in this dial-backup scenario. The LLQ could be provisioned as high as 73% (leaving 2% for Voice Control traffic over the ISDN link).

Voice and Data on Multiple ISDN B Channels

This design takes advantage of the fact that LLQ bandwidth can be expressed as a percentage instead of an absolute number. This allows a service policy to be applied to a bundle with multiple B channels. As a result, RTP packets can be carried across multiple B channels. The drawback is that cRTP will not work properly in such a configuration, due to the potential reordering of RTP packets.

IOS provides two mechanisms for controlling how channels are added in response to demand.

• The first mechanism is commonly referred to as Dial on Demand Routing (DDR). With DDR, a load-threshold must be specified (as fraction of available bandwidth). When traffic load exceeds this number, an additional channel is added to the bundle. The threshold is calculated as a running average. Therefore, there is certain delay in bringing up additional B channels when the load increases. This delay does not present a problem with data, but with voice it is unacceptable. This delay can be reduced to around 30 seconds by adding the load-interval command to the physical ISDN interface, but even 30 seconds is too long.

• The second is a more robust solution, which is to simply bring all B channels up immediately and keep them up as long as the ISDN service is required. This is achieved by using the ppp multilink links minimum command.

With two B channels available, the service policy can now reserve 93 kbps (73% of 128 kbps) for voice and voice control traffic. The total number of calls that can be transmitted will depend on the CODEC and sampling rates used.

Example 4-16 illustrates the configuration for enabling voice and data over multiple ISDN B channels.

Example 4-16 Voice and Data over Multiple B Channels

class-map match-all VOICE match ip dscp ef!class-map match-all VOICE-CONTROL match ip dscp af31!policy-map WAN-EDGE-ISDN class VOICE priority percent 73 This command relaxes the LLQ ceiling for this DDR scenario. (73% of 128 class VOICE-CONTROL kbps is 93 kbps. That leaves 2%, which is 2.5 kbps; enough for 15 phones.) bandwidth percent 2 class class-default fair-queue!interface BRI0/0 encapsulation ppp dialer pool-member 1!


956467


interface Dialer1 encapsulation ppp dialer pool 1 dialer remote-name routerB-dialer1 dialer-group 1 dialer string 12345678 service-policy output WAN-EDGE-ISDN This command binds the MQC policy to the ISDN interface. ppp multilink ppp multilink fragment-delay 10 This command limits the maximum delay. ppp multilink interleave This command enables MLP LFI. ppp multilink links minimum 2 This command brings up both B channels immediately.

Tip For additional details refer to the VoIP over ISDN white paper (internal).

Summary ConfigurationsThis section provides configuration examples for implementing QoS on WAN aggregation routers.

Example 4-17 Classifying and Provisioning for Voice, Video and Data

class-map match-all VOICE match ip dscp efclass-map match-all VIDEO match ip dscp af41class-map match-all VOICE-CONTROL match ip dscp af31class-map match-any GOLD-DATA match ip dscp af21 match ip dscp af22 match ip dscp af23class-map match-any SILVER-DATA match ip dscp af11 match ip dscp af12 match ip dscp af13!policy-map WAN-EDGE class VOICE priority percent 17 class VIDEO priority percent 16 30000 class VOICE-CONTROL bandwidth percent 2 class GOLD-DATA bandwidth percent 25 random-detect dscp-based class SILVER-DATA bandwidth percent 15 random-detect dscp-basedclass class-default fair-queue random-detect dscp-based random-detect dscp-based random-detect dscp 0 96 128 10 random-detect dscp 2 70 128 10 random-detect dscp 4 58 128 10 random-detect dscp 6 44 128 10


956467


The following design principles apply when determining bandwidth provisioning requirements for combining voice, video and data over a single WAN link:

• Video requires 460 kbps of LLQ for each 384 kbps stream.

• VoIP also requires LLQ bandwidth (depending on number of phones, CODECs etc.).

• Total LLQ provisioning is recommended to be less than or equal to 33% of the link-capacity.

Although the ratios of voice and video may vary from one enterprise to another, if they are roughly the same then a minimum bandwidth recommendation for combined voice, video and data would be 3 Mbps. To meet this design recommendation in a point-to-point topology, two T1 links have been combined into a MLP bundle and the MQC policy is applied to the multilink Interface.

Example 4-18 Combined Voice, Video and Data over Point-to-Point Links

interface Multilink 40 bandwidth 3072 ip address 10.200.40.1 255.255.255.252 service-policy output WAN-EDGE ppp multilink multilink-group 40!…!interface Serial1/0 description Link T1-A to BRANCH#40 bandwidth 1536 no ip address encapsulation ppp ppp multilink multilink-group 40!interface Serial1/1 description Link T1-B to BRANCH#40 bandwidth 1536 no ip address encapsulation ppp ppp multilink multilink-group 40

Example 4-19 Combined Voice, Video and Data over Frame-Relay Links

interface Serial0/1 description Parent FR Link no ip address encapsulation frame-relay!interface Serial0/1.50 point-to-point description FR Link to BRANCH#50 bandwidth 3000 ip address 10.200.50.1 255.255.255.252 frame-relay interface-dlci 211 class REMOTE-BRANCH-3000kbps This command applies the FRTS map-class to the DLCI. !…map-class frame-relay REMOTE-BRANCH-3000kbps frame-relay cir 3000000 frame-relay bc 30000 frame-relay be 0 frame-relay mincir 3000000 no frame-relay adaptive-shaping service-policy output WAN-EDGE This command applies the MQC policy to the FRTS map-class.


956467

Chapter 4 QoS in an AVVID-Enabled Wide-Area NetworkQoS Recommendations for Remote Branch Routers

Example 4-20 Combined Voice, Video and Data over ATM Links

interface ATM4/0 bandwidth 3000 no ip address no atm ilmi-keepalive!interface ATM4/0.60 point-to-point bandwidth 3000 ip address 10.210.60.1 255.255.255.252 pvc BRANCH#60 0/60 vbr-nrt 3000 3000 This command sets the high ATM AAL5 traffic contract. tx-ring-limit 3 This command reduces the delay caused by the TX ring buffer. service-policy output WAN-EDGE This command applies the MQC policy to the ATM PVC.

QoS Recommendations for Remote Branch Routers This section contains information about using QoS in WAN remote branch routers. It covers the following:

• WAN Edges

• Remote LAN Edge for Voice

• Remote LAN Edge for Video

• Remote LAN Edge for Data

• Summary Configuration

WAN EdgesThe WAN edges on the remote branch routers have the identical configurations as their WAN aggregation link counterparts.

Remote LAN Edge for VoiceThe remote branch LAN edges are responsible for restoring the DSCP-to-CoS mappings that were lost when the Layer 2 media changed. This mapping is accomplished using Class-Based Marking, which is CEF dependent.

In the following voice-only example, voice and voice-control traffic are mapped from their DSCP values (EF and AF31 respectively) to their corresponding 802.1Q CoS values (5 and 3 respectively). The policy is applied to both the voice VLAN and the data VLAN Fast-Ethernet sub-interfaces.

Note Class-maps that have been defined for the WAN edge policies do not need to be redefined


956467


ip cef!…!policy-map REMOTE-LAN-EDGE class VOICE set cos 5 class VOICE-CONTROL set cos 3!interface FastEthernet0/0 description CAT3500 REMOTE-BRANCH ACCESS-SWITCH no ip address load-interval 30 speed auto duplex auto!interface FastEthernet0/0.50 description NATIVE SUBNET 10.1.50.0 DATA encapsulation dot1Q 50 ip address 10.1.50.1 255.255.255.0 service-policy output REMOTE-LAN-EDGE This command applies the MQC policy to the sub-interface.interface FastEthernet0/0.150 This policy is required on the data VLAN to remap voicedescription NATIVE SUBNET 10.1.150.0 VOICEand voice control traffic heading to softphone clients. encapsulation dot1Q 150ip address 10.1.150.1 255.255.255.0

service-policy output REMOTE-LAN-EDGE This command applies the MQC policy to the sub-interface.

For more information about DSCP and COS, see “Classification Tools” section on page 1-12.

Remote LAN Edge for VideoIn the following video-only example, video traffic is mapped from the DSCP value AF41 to the 802.1Q CoS value (4). The policy is applied to only the data/video VLAN FE sub-interface.

Note Class-maps that have been defined for the WAN-Edge policies do not need to be redefined

ip cef!policy-map REMOTE-LAN-EDGE class VIDEO set cos 4!…!interface FastEthernet0/0 description CAT3500 REMOTE-BRANCH ACCESS-SWITCH no ip address load-interval 30 speed auto duplex auto!interface FastEthernet0/0.50 description NATIVE SUBNET 10.1.50.0 DATA + VIDEO encapsulation dot1Q 50 ip address 10.1.50.1 255.255.255.0 service-policy output REMOTE-LAN-EDGE This command applies the MQC policy to the sub-interface.



956467


Remote LAN Edge for DataFor data, service policies are typically applied at the output, but there are exceptions when they can be applied at the input.

Output Policies

In the following data-only example, data traffic flows are mapped from their DSCP values to their corresponding 802.1Q CoS values. The policy is applied to only the Data VLAN Fast-Ethernet sub-interface.

Note Class-maps that have been defined for the WAN-Edge policies do not need to be redefined

ip cef!policy-map REMOTE-LAN-EDGE-OUT class GOLD-DATA set cos 2 class SILVER-DATA set cos 1 class class-default set cos 0!interface FastEthernet0/0 description CAT3500 REMOTE-BRANCH ACCESS-SWITCH no ip address load-interval 30 speed auto duplex auto!interface FastEthernet0/0.50 description NATIVE SUBNET 10.1.50.0 DATA encapsulation dot1Q 50 ip address 10.1.50.1 255.255.255.0 service-policy output REMOTE-LAN-EDGE-OUT This command applies the MQC policy to the

sub-interface.


Input Policies

In keeping with the Differentiated Services model design principle, all traffic should be marked as close to their sources as possible. This means marking data traffic on campus access switches and at remote branch access switches. However, circumstances may exist where such classification cannot be made on the remote branch access switch, such as:

• The remote branch access switch does not have Layer 3/Layer 4 awareness.

• Classification needs to be done at the application layer (via NBAR).

In such cases, DSCP classification must be performed at the ingress interface of the remote branch router.

Example 4-21 provides an illustration of this. SAP (identified by TCP port 3200), SQLNET and Citrix are the most important applications. These are followed in order of importance by e-mail protocols, TELNET, and R-commands (rsh, rlogin, rexec). Finally, FTP, backups, and peer-to-peer applications are designated for less-than-best-effort service.


956467


Example 4-21 DSCP Classification at the Ingress Interface

ip cef!class-map match-all SAP match access-group 100class-map match-all SQLNET match protocol sqlnetclass-map match-all CITRIX match protocol citrixclass-map match-any EMAIL match protocol pop3 match protocol imap match protocol smtpclass-map match-all TELNET match protocol telnetclass-map match-all RCMD match protocol rcmdclass-map match-all FTP match protocol ftpclass-map match-all BACKUPS match access-group 101class-map match-any P2P match protocol napster match protocol fasttrack!policy-map REMOTE-LAN-EDGE-IN class SAP set ip dscp af21 class SQLNET set ip dscp af22 class CITRIX set ip dscp af23 class EMAIL set ip dscp af11 class TELNET set ip dscp af12 class RCMD set ip dscp af13 class FTP set ip dscp 2 class BACKUPS set ip dscp 4 class P2P set ip dscp 6!interface FastEthernet0/0 description CAT3500 REMOTE-BRANCH ACCESS-SWITCH no ip address no ip mroute-cache load-interval 30 speed auto duplex auto!interface FastEthernet0/0.50 description NATIVE SUBNET 10.1.50.0 DATA encapsulation dot1Q 50 ip address 10.1.50.1 255.255.255.0 service-policy input REMOTE-LAN-EDGE-IN This command applies the input MQC policy to theservice-policy output REMOTE-LAN-EDGE-OUT sub-interface.

!…access-list 100 permit tcp any any eq 3200access-list 101 permit tcp any host 10.1.100.100


956467


For more information about DSCP and NBAR, see “Classification Tools” section on page 1-12.

Summary ConfigurationThe following is an example of a remote branch router configured for QoS for voice, video, and mission-critical data.

ip cef!class-map match-all VOICE match ip dscp efclass-map match-all VIDEO match ip dscp af41class-map match-all VOICE-CONTROL match ip dscp af31class-map match-any GOLD-DATA match ip dscp af21 match ip dscp af22 match ip dscp af23class-map match-any SILVER-DATA match ip dscp af11 match ip dscp af12 match ip dscp af13!class-map match-all SAP match access-group 100class-map match-all SQLNET match protocol sqlnetclass-map match-all CITRIX match protocol citrixclass-map match-any EMAIL match protocol pop3 match protocol imap match protocol smtpclass-map match-all TELNET match protocol telnetclass-map match-all RCMD match protocol rcmdclass-map match-all FTP match protocol ftpclass-map match-all BACKUPS match access-group 101class-map match-any P2P match protocol napster match protocol fasttrack!policy-map WAN-EDGE class VOICE priority percent 17 class VIDEO priority percent 16 30000 class VOICE-CONTROL bandwidth percent 2 class GOLD-DATA bandwidth percent 25 random-detect dscp-based class SILVER-DATA bandwidth percent 15 random-detect dscp-based


956467


class class-default fair-queue random-detect dscp-based random-detect dscp-based random-detect dscp 0 96 128 10 random-detect dscp 2 70 128 10 random-detect dscp 4 58 128 10 random-detect dscp 6 44 128 10!policy-map REMOTE-LAN-EDGE-OUT class VOICE set cos 5 class VOICE-CONTROL set cos 3 class VIDEO set cos 4 class GOLD-DATA set cos 2 class SILVER-DATA set cos 1 class class-default set cos 0!policy-map REMOTE-LAN-EDGE-IN class SAP set ip dscp af21 class SQLNET set ip dscp af22 class CITRIX set ip dscp af23 class EMAIL set ip dscp af11 class TELNET set ip dscp af12 class RCMD set ip dscp af13 class FTP set ip dscp 2 class BACKUPS set ip dscp 4 class P2P set ip dscp 6!!interface FastEthernet0/0 description CAT3500 REMOTE-BRANCH ACCESS-SWITCH no ip address load-interval 30 speed auto duplex auto!interface FastEthernet0/0.50 description NATIVE SUBNET 10.1.50.0 DATA encapsulation dot1Q 50 ip address 10.1.50.1 255.255.255.0 service-policy output REMOTE-LAN-EDGEservice-policy input REMOTE-LAN-EDGE-IN

!!interface FastEthernet0/0.150 description NATIVE SUBNET 10.1.150.0 VOICE encapsulation dot1Q 150 ip address 10.1.150.1 255.255.255.0 service-policy output REMOTE-LAN-EDGE


956467

Chapter 4 QoS in an AVVID-Enabled Wide-Area NetworkVerifying QoS

!…!interface Multilink1 bandwidth 3072 ip address 10.200.40.2 255.255.255.252 service-policy output WAN-EDGE ppp multilink multilink-group 1!interface Serial1/0 description Link T1-A to BRANCH#40 bandwidth 1536 no ip address encapsulation ppp ppp multilink multilink-group 1!interface Serial1/1 description T1-B to BRANCH#40 bandwidth 1536 no ip address encapsulation ppp ppp multilink multilink-group 1!…!access-list 100 permit tcp any any eq 3200access-list 101 permit tcp any host 10.1.100.100

Verifying QoSThis section contains examples of the output generated by various show command used to verify the QoS configuration in a WAN.

show policyThis example is the output of a voice, video and data policy on a non-distributed platform. In this example, you will note that:

• Voice and video traffic are assigned LLQ.

• Voice-control traffic is assigned CBWFQ.

• Gold data and silver data are assigned CBWFQ.

• Best-effort traffic is assigned WFQ.

WAN-AGG-7200#show policy Policy Map WAN-EDGE Class VOICE Weighted Fair Queueing Strict Priority Bandwidth 17 (%) Class VIDEO Weighted Fair Queueing Strict Priority Bandwidth 16 (%) Burst 30000 (Bytes)


956467


Class VOICE-CONTROL Weighted Fair Queueing Bandwidth 2 (%) Max Threshold 64 (packets) Class GOLD-DATA Weighted Fair Queueing Bandwidth 25 (%) exponential weight 9 dscp min-threshold max-threshold mark-probablity ----------------------------------------------------------

af11 - - 1/10 af12 - - 1/10 af13 - - 1/10 af21 - - 1/10 af22 - - 1/10 af23 - - 1/10 af31 - - 1/10 af32 - - 1/10 af33 - - 1/10 af41 - - 1/10 af42 - - 1/10 af43 - - 1/10 cs1 - - 1/10 cs2 - - 1/10 cs3 - - 1/10 cs4 - - 1/10 cs5 - - 1/10 cs6 - - 1/10 cs7 - - 1/10 ef - - 1/10 rsvp - - 1/10 default - - 1/10

Class SILVER-DATA Weighted Fair Queueing Bandwidth 15 (%) exponential weight 9 dscp min-threshold max-threshold mark-probablity ----------------------------------------------------------

af11 - - 1/10 af12 - - 1/10 af13 - - 1/10 af21 - - 1/10 af22 - - 1/10 af23 - - 1/10 af31 - - 1/10 af32 - - 1/10 af33 - - 1/10 af41 - - 1/10 af42 - - 1/10 af43 - - 1/10 cs1 - - 1/10 cs2 - - 1/10 cs3 - - 1/10 cs4 - - 1/10 cs5 - - 1/10 cs6 - - 1/10 cs7 - - 1/10 ef - - 1/10 rsvp - - 1/10 default - - 1/10


956467


Class class-default Weighted Fair Queueing Flow based Fair Queueing Bandwidth 0 (kbps) exponential weight 9 dscp min-threshold max-threshold mark-probablity ----------------------------------------------------------

af11 - - 1/10 af12 - - 1/10 af13 - - 1/10 af21 - - 1/10 af22 - - 1/10 af23 - - 1/10 af31 - - 1/10 af32 - - 1/10 af33 - - 1/10 af41 - - 1/10 af42 - - 1/10 af43 - - 1/10 cs1 - - 1/10 cs2 - - 1/10 cs3 - - 1/10 cs4 - - 1/10 cs5 - - 1/10 cs6 - - 1/10 cs7 - - 1/10 ef - - 1/10 2 70 128 1/10 4 58 128 1/10 6 44 128 1/10 rsvp - - 1/10 default 96 128 1/10

show policy interfaceThis section provides two examples of the show policy interface command.

Example 1

This example is the output of a voice, video and data policy applied to a multilink interface consisting of a dual-T1 connection on a non-distributed platform. In this example, you will note that:

• There are no drops for voice traffic.

• There are no drops for video traffic.

• There are no drops for voice-control traffic.

• Gold data has deep queues and random drops (based on DSCP-markings), but no tail-drops.

• Silver data has deep queues and random drops (based on DSCP-markings), as well as tail-drops.

• Best effort traffic has deep queues and random drops (based on DSCP-markings), as well as tail-drops.


956467


WAN-AGG-7200#show policy interface multilink 1 Multilink1

Service-policy output: WAN-EDGE

Class-map: VOICE (match-all) 235728 packets, 45259776 bytes 30 second offered rate 512000 bps, drop rate 0 bps Match: ip dscp 46 Weighted Fair Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 17 (%) Bandwidth 522 (kbps) Burst 13050 (Bytes) (pkts matched/bytes matched) 235729/45259968 (total drops/bytes drops) 0/0

Class-map: VIDEO (match-all) 64405 packets, 42852720 bytes 30 second offered rate 485000 bps, drop rate 0 bps Match: ip dscp 34 Weighted Fair Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 16 (%) Bandwidth 491 (kbps) Burst 30000 (Bytes) (pkts matched/bytes matched) 64538/42941550 (total drops/bytes drops) 0/0

Class-map: VOICE-CONTROL (match-all) 44199 packets, 5834268 bytes 30 second offered rate 65000 bps, drop rate 0 bps Match: ip dscp 26 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 2 (%) Bandwidth 61 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 44290/5846280 (depth/total drops/no-buffer drops) 1/0/0

Class-map: GOLD-DATA (match-any) 93422 packets, 118192896 bytes 30 second offered rate 1336000 bps, drop rate 32000 bps Match: ip dscp 18 24386 packets, 36676544 bytes 30 second rate 415000 bps Match: ip dscp 20 33676 packets, 41488832 bytes 30 second rate 469000 bps Match: ip dscp 22 35360 packets, 40027520 bytes 30 second rate 451000 bps Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 25 (%) Bandwidth 768 (kbps) (pkts matched/bytes matched) 93816/118691420 (depth/total drops/no-buffer drops) 29/2327/0 exponential weight: 9 mean queue depth: 28


956467


dscp Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh probaf11 0/0 0/0 0/0 32 40 1/10af12 0/0 0/0 0/0 28 40 1/10af13 0/0 0/0 0/0 24 40 1/10af21 24489/36831456 98/14700 0/0 32 40 1/10af22 33061/40732666 458/932340 0/0 28 40 1/10af23 33990/38479822 571/1775230 0/0 24 40 1/10af31 0/0 0/0 0/0 32 40 1/10af32 0/0 0/0 0/0 28 40 1/10af33 0/0 0/0 0/0 24 40 1/10af41 0/0 0/0 0/0 32 40 1/10af42 0/0 0/0 0/0 28 40 1/10af43 0/0 0/0 0/0 24 40 1/10cs1 0/0 0/0 0/0 22 40 1/10cs2 0/0 0/0 0/0 24 40 1/10cs3 0/0 0/0 0/0 26 40 1/10cs4 0/0 0/0 0/0 28 40 1/10cs5 0/0 0/0 0/0 30 40 1/10cs6 0/0 0/0 0/0 32 40 1/10cs7 0/0 0/0 0/0 34 40 1/10ef 0/0 0/0 0/0 36 40 1/10rsvp 0/0 0/0 0/0 36 40 1/10default 0/0 0/0 0/0 20 40 1/10

Note The DSCP table reflects that the drop-preference bit is a factor in deciding which application to drop first in the event of queue congestion. For example, AF23 is (statistically) dropped more often than AF22, which is dropped more often than AF21.

Class-map: SILVER-DATA (match-any) 153034 packets, 118626388 bytes 30 second offered rate 1342000 bps, drop rate 561000 bps Match: ip dscp 10 41599 packets, 38770268 bytes 30 second rate 439000 bps Match: ip dscp 12 47146 packets, 39225472 bytes 30 second rate 443000 bps Match: ip dscp 14 64289 packets, 40630648 bytes 30 second rate 459000 bps Weighted Fair Queueing Output Queue: Conversation 267 Bandwidth 15 (%) Bandwidth 460 (kbps) (pkts matched/bytes matched) 154625/119859800 (depth/total drops/no-buffer drops) 40/65111/0 exponential weight: 9 mean queue depth: 40

dscp Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh probaf11 24874/23216884 3059/2844870 14099/13112070 32 40 1/10af12 27987/23324484 3328/2762240 16322/13547260 28 40 1/10af13 36654/23221934 4514/2843820 23789/14987070 24 40 1/10af21 0/0 0/0 0/0 32 40 1/10af22 0/0 0/0 0/0 28 40 1/10af23 0/0 0/0 0/0 24 40 1/10af31 0/0 0/0 0/0 32 40 1/10af32 0/0 0/0 0/0 28 40 1/10af33 0/0 0/0 0/0 24 40 1/10


956467


af41 0/0 0/0 0/0 32 40 1/10af42 0/0 0/0 0/0 28 40 1/10af43 0/0 0/0 0/0 24 40 1/10cs1 0/0 0/0 0/0 22 40 1/10cs2 0/0 0/0 0/0 24 40 1/10cs3 0/0 0/0 0/0 26 40 1/10cs4 0/0 0/0 0/0 28 40 1/10cs5 0/0 0/0 0/0 30 40 1/10cs6 0/0 0/0 0/0 32 40 1/10cs7 0/0 0/0 0/0 34 40 1/10ef 0/0 0/0 0/0 36 40 1/10rsvp 0/0 0/0 0/0 36 40 1/10default 0/0 0/0 0/0 20 40 1/10

Note The DSCP table reflects that the drop-preference bit is a factor in deciding which application to drop first in the event of queue congestion. For example, AF13 is (statistically) dropped more often than AF12, which is dropped more often than AF11.

Class-map: class-default (match-any) 324880 packets, 220268626 bytes 30 second offered rate 2492000 bps, drop rate 2468000 bps Match: any Weighted Fair Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 245/320377/0 exponential weight: 9

dscp Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh probaf11 0/0 0/0 0/0 32 40 1/10af12 0/0 0/0 0/0 28 40 1/10af13 0/0 0/0 0/0 24 40 1/10af21 0/0 0/0 0/0 32 40 1/10af22 0/0 0/0 0/0 28 40 1/10af23 0/0 0/0 0/0 24 40 1/10af31 0/0 0/0 0/0 32 40 1/10af32 0/0 0/0 0/0 28 40 1/10af33 0/0 0/0 0/0 24 40 1/10af41 0/0 0/0 0/0 32 40 1/10af42 0/0 0/0 0/0 28 40 1/10af43 0/0 0/0 0/0 24 40 1/10cs1 0/0 0/0 0/0 22 40 1/10cs2 0/0 0/0 0/0 24 40 1/10cs3 0/0 0/0 0/0 26 40 1/10cs4 0/0 0/0 0/0 28 40 1/10cs5 0/0 0/0 0/0 30 40 1/10cs6 156/9672 0/0 0/0 32 40 1/10cs7 0/0 0/0 0/0 34 40 1/10ef 0/0 0/0 0/0 36 40 1/102 131/298894 11/16522 35884/53897768 70 128 1/104 149/303902 16/24032 39887/59910274 58 128 1/106 152/318420 19/27721 44894/67430788 44 128 1/10rsvp 0/0 0/0 0/0 36 40 1/10default 9192/1106286 985/63770 199706/41151028 96 128 1/10


956467


Note The DSCP table reflects that the drop-preference bit is a factor in deciding which application to drop first in the even of queue congestion. For example, DSCP 6 is (statistically) dropped more often than DSCP 4, which is dropped more often than DSCP 2.

It may be surprising to see DSCP values other than 0, 2, 4 and 6 in the default queue, but this is perfectly normal if the traffic is marked at CS6 or CS7 (IP Precedence 6 and 7). These IP Precedence values are used by routing protocols.

Example 2

This second example is the output of a voice, video and data policy applied to a high-speed Frame Relay PVC on a distributed platform (notice the hierarchical policy. In this example, you will note that:


• There are no drops for video traffic.


• Within the gold data, drops are increasing according to the drop-preference bit.

• Within the silver data, drops are increasing according to the drop-preference bit.

• Within the best-effort traffic, drops are increasing according to the drop-preference bit.

WAN-AGG-7500#show policy interface serial 1/0/1.50 Serial1/0/1.50: DLCI 150 -

Service-policy output: dTS-3072kbps

queue stats for all priority classes: queue size 0, queue limit 337 packets output 252815, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0

Class-map: class-default (match-any) 780988 packets, 474070302 bytes 30 second offered rate 5758000 bps, drop rate 2997000 bps Match: any queue size 372, queue limit 2560 packets output 463967, packet drops 314658 tail/random drops 314658, no buffer drops 0, other drops 0 Shape: cir 3072000, Bc 24576, Be 0 lower bound cir 0, adapt to fecn 0 output bytes 231123890, shape rate 2975000 bps Queue-limit 1024 Service-policy : WAN-EDGE

Class-map: VOICE (match-all) 204471 packets, 39258432 bytes 30 second offered rate 474000 bps, drop rate 0 bps Match: ip dscp 46 Priority: 17% (522 kbps), burst bytes 13050, b/w exceed drops: 0

Class-map: VIDEO (match-all) 49118 packets, 32162946 bytes 30 second offered rate 388000 bps, drop rate 0 bps Match: ip dscp 34 Priority: 16% (491 kbps), burst bytes 30000, b/w exceed drops: 0


956467


Class-map: VOICE-CONTROL (match-all) 30720 packets, 4055040 bytes 30 second offered rate 46000 bps, drop rate 0 bps Match: ip dscp 26drops queue size 8, queue limit 20 packets output 30626, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 Bandwidth: 2%, kbps 61

Class-map: GOLD-DATA (match-any) 80937 packets, 102443744 bytes 30 second offered rate 1247000 bps, drop rate 530000 bps Match: ip dscp 18 21255 packets, 31967520 bytes 30 second rate 386000 bps Match: ip dscp 20 29162 packets, 35927584 bytes 30 second rate 435000 bps Match: ip dscp 22 30520 packets, 34548640 bytes 30 second rate 420000 bps queue size 135, queue limit 255 packets output 47252, packet drops 33438 tail/random drops 33438, no buffer drops 0, other drops 0 Bandwidth: 25%, kbps 768 Random-detect: Exp-weight-constant: 9 (1/512) Mean queue depth: 127 Class Random Tail Minimum Maximum Mark Output drop drop threshold threshold probability packets (af21) 18 1211 7502 110 127 1/10 12472 (af22) 20 1672 10375 94 127 1/10 17014 (af23) 22 1757 10894 78 127 1/10 17766

Class-map: SILVER-DATA (match-any) 133058 packets, 103122556 bytes 30 second offered rate 1251000 bps, drop rate 830000 bps Match: ip dscp 10 36259 packets, 33793388 bytes 30 second rate 406000 bps Match: ip dscp 12 40761 packets, 33913152 bytes 30 second rate 412000 bps Match: ip dscp 14 56038 packets, 35416016 bytes 30 second rate 426000 bps queue size 91, queue limit 153 packets output 46493, packet drops 86159 tail/random drops 86159, no buffer drops 0, other drops 0 Bandwidth: 15%, kbps 460 Random-detect: Exp-weight-constant: 9 (1/512) Mean queue depth: 77 Class Random Tail Minimum Maximum Mark Output drop drop threshold threshold probability packets (af11) 10 1269 22191 66 76 1/10 12866 (af12) 12 1437 25415 57 76 1/10 14375 (af13) 14 1990 34781 47 76 1/10 19904


956467


Class-map: class-default (match-any) 282684 packets, 193027584 bytes 30 second offered rate 2327000 bps, drop rate 1634000 bps Match: any queue size 131, queue limit 256 packets output 88031, packet drops 197850 tail/random drops 197850, no buffer drops 0, other drops 0 Fair-queue: per-flow queue limit 64 Random-detect: Exp-weight-constant: 9 (1/512) Mean queue depth: 129 Class Random Tail Minimum Maximum Mark Output drop drop threshold threshold probability packets 0 5894 116200 96 128 1/10 58942 2 992 20265 22 128 1/10 9913 4 1108 22389 18 128 1/10 11081 6 1237 25357 14 128 1/10 12369 48 0 0 112 128 1/10 156

Again, class 48 (IP Precedence 6) is routing traffic that has been assigned to the default queue.

show interfaceThis example is the output of voice and data policies over a 512 kbps multilink interface with LFI enabled on a non-distributed platform. In this example, you will note that:

• The txload indicates a fully-congested link.

• There is a total of 144066 drops and 10910 interleaves.

WAN-AGG-7200#show interface multilink 1Multilink1 is up, line protocol is up Hardware is multilink group interface Internet address is 10.100.40.1/30 MTU 1500 bytes, BW 512 Kbit, DLY 100000 usec, reliability 255/255, txload 255/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 2 seconds on reset LCP Open, multilink Open Open: IPCP, CDPCP Last input 00:00:01, output never, output hang never Last clearing of "show interface" counters 00:03:07 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 144066 Queueing strategy: weighted fair Output queue: 309/1000/64/144066/10910 (size/max total/threshold/drops/interleaves) Conversations 7/8/256 (active/max active/max total) Reserved Conversations 3/3 (allocated/max allocated) Available Bandwidth 2 kilobits/sec 30 second input rate 0 bits/sec, 0 packets/sec 30 second output rate 512000 bits/sec, 79 packets/sec 46 packets input, 3761 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 14361 packets output, 11733605 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions


956467


show queueThis example is the output of voice and data policies over a 512 kbps multilink interface with LFI enabled on a non-distributed platform. In this example, you will note that:

• There are no drops or interleaves for the LLQ for voice.

• For mission-critical, Gold traffic, data is randomly dropped, tail dropped, and interleaved as needed.

WAN-AGG-7200#show queue multilink 1 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 278264 Queueing strategy: weighted fair Output queue: 302/1000/64/278264/21900 (size/max total/threshold/drops/interleaves) Conversations 7/8/256 (active/max active/max total) Reserved Conversations 3/3 (allocated/max allocated) Available Bandwidth 2 kilobits/sec...

The following shows the queue for Voice (DSCP 46):

• The first six bits of ToS Byte are set to 101110.

• The last two bits set to 00.

• The total ToS Byte Value is 10111000, or 184 in decimal.

(depth/weight/total drops/no-buffer drops/interleaves) 1/0/0/0/0 Conversation 264, linktype: ip, length: 90 source: 10.1.1.10, destination: 10.1.40.100, id: 0x806A, ttl: 127, TOS: 184 prot: 17, source port 1098, destination port 14046...

The following shows the queue for mission-critical/Gold application 1 data (DSCP 18):

• The first six bits of ToS Byte are set to 010010.

• The last two bits set to 00.

• The total ToS Byte Value is 01001000 or 72 in decimal.

(depth/weight/total drops/no-buffer drops/random/tail/interleaves) 41/62/3142/400/734/2008/9055 Conversation 266, linktype: ip, length: 1502 source: 10.1.1.10, destination: 10.1.40.100, id: 0x7437, ttl: 127, TOS: 72 prot: 17, source port 1071, destination port 14021

show frame-relay pvcThis example is the output of voice and data policies over a 512 kbps Frame Relay PVC with FRF.12 enabled on a non-distributed platform. In this example, you will note that:



• Within the gold data, drops are increasing according to the drop-preference bit.

• Within the silver data, drops are increasing according to the drop-preference bit.

• Within the best-effort traffic, drops are increasing according to the drop-preference bit.

• The default queue depth is 128 (compared to non-distributed point-to-point links, where the queue depth is 40).


956467


WAN-AGG-7200#show frame-relay pvc interface serial 1/2.50 150

PVC Statistics for interface Serial1/2.50 (Frame Relay DTE)

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/2.50

input pkts 254 output pkts 691829 in bytes 21409 out bytes 512977916 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 215 out bcast bytes 17780 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 529000 bits/sec, 744 packets/sec pvc create time 00:32:35, last time pvc status changed 00:32:35 service policy WAN-EDGE Serial1/2.50: DLCI 150 -

Service-policy output: WAN-EDGE

Class-map: VOICE (match-all) 27330 packets, 2514360 bytes 30 second offered rate 122000 bps, drop rate 0 bps Match: ip dscp 46 Weighted Fair Queueing Strict Priority Output Queue: Conversation 40 Bandwidth 33 (%) Bandwidth 167 (kbps) Burst 4175 (Bytes) (pkts matched/bytes matched) 27380/2518960 (total drops/bytes drops) 0/0

Class-map: VOICE-CONTROL (match-all) 9018 packets, 649296 bytes 30 second offered rate 8790 bps, drop rate 0 bps Match: ip dscp 26 Weighted Fair Queueing Output Queue: Conversation 41 Bandwidth 2 (%) Bandwidth 10 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 9035/650520 (depth/total drops/no-buffer drops) 1/0/0

Class-map: GOLD-DATA (match-any) 81990 packets, 123312960 bytes 30 second offered rate 207600 bps, drop rate 80600 bps Match: ip dscp 18 27329 packets, 41102816 bytes 30 second rate 359000 bps Match: ip dscp 20 27331 packets, 41105824 bytes 30 second rate 359000 bps Match: ip dscp 22 27330 packets, 41104320 bytes 30 second rate 359000 bps Weighted Fair Queueing Output Queue: Conversation 42 Bandwidth 25 (%) Bandwidth 127 (kbps) (pkts matched/bytes matched) 82364/123875456 (depth/total drops/no-buffer drops) 128/39864/8161 exponential weight: 9 mean queue depth: 129


956467


dscp Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh probaf11 0/0 0/0 0/0 106 128 1/10af12 0/0 0/0 0/0 92 128 1/10af13 0/0 0/0 0/0 78 128 1/10af21 7464/11225856 459/690336 10567/15892768 106 128 1/10af22 8060/12122240 475/714400 9989/15023456 92 128 1/10af23 8277/12448608 517/777568 9758/14676032 78 128 1/10af31 0/0 0/0 0/0 106 128 1/10af32 0/0 0/0 0/0 92 128 1/10af33 0/0 0/0 0/0 78 128 1/10af41 0/0 0/0 0/0 106 128 1/10af42 0/0 0/0 0/0 92 128 1/10af43 0/0 0/0 0/0 78 128 1/10cs1 0/0 0/0 0/0 71 128 1/10cs2 0/0 0/0 0/0 78 128 1/10cs3 0/0 0/0 0/0 85 128 1/10cs4 0/0 0/0 0/0 92 128 1/10cs5 0/0 0/0 0/0 99 128 1/10cs6 0/0 0/0 0/0 106 128 1/10cs7 0/0 0/0 0/0 113 128 1/10ef 0/0 0/0 0/0 120 128 1/10rsvp 0/0 0/0 0/0 120 128 1/10default 0/0 0/0 0/0 64 128 1/10 Class-map: SILVER-DATA (match-any) 81995 packets, 123320480 bytes 30 second offered rate 107600 bps, drop rate 31600 bps Match: ip dscp 10 27331 packets, 41105824 bytes 30 second rate 359000 bps Match: ip dscp 12 27332 packets, 41107328 bytes 30 second rate 359000 bps Match: ip dscp 14 27332 packets, 41107328 bytes 30 second rate 359000 bps Weighted Fair Queueing Output Queue: Conversation 43 Bandwidth 15 (%) Bandwidth 76 (kbps) (pkts matched/bytes matched) 82812/124549248 (depth/total drops/no-buffer drops) 129/46384/8860 exponential weight: 9 mean queue depth: 129

dscp Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh probaf11 6688/10058752 246/320384 11606/17455424 106 128 1/10af12 5217/7846368 300/451200 13124/19738496 92 128 1/10af13 6493/9765472 340/511360 11808/17759232 78 128 1/10af21 0/0 0/0 0/0 106 128 1/10af22 0/0 0/0 0/0 92 128 1/10af23 0/0 0/0 0/0 78 128 1/10af31 0/0 0/0 0/0 106 128 1/10af32 0/0 0/0 0/0 92 128 1/10af33 0/0 0/0 0/0 78 128 1/10af41 0/0 0/0 0/0 106 128 1/10af42 0/0 0/0 0/0 92 128 1/10af43 0/0 0/0 0/0 78 128 1/10cs1 0/0 0/0 0/0 71 128 1/10cs2 0/0 0/0 0/0 78 128 1/10cs3 0/0 0/0 0/0 85 128 1/10cs4 0/0 0/0 0/0 92 128 1/10


956467


cs5 0/0 0/0 0/0 99 128 1/10cs6 0/0 0/0 0/0 106 128 1/10cs7 0/0 0/0 0/0 113 128 1/10ef 0/0 0/0 0/0 120 128 1/10rsvp 0/0 0/0 0/0 120 128 1/10default 0/0 0/0 0/0 64 128 1/10 Class-map: class-default (match-any) 492201 packets, 263703748 bytes 30 second offered rate 2297000 bps, drop rate 2218000 bps Match: any Weighted Fair Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 32 (total queued/total drops/no-buffer drops) 129/337323/58000 exponential weight: 9

dscp Transmitted Random drop Tail drop Minimum Maximum Mark pkts/bytes pkts/bytes pkts/bytes thresh thresh probaf11 0/0 0/0 0/0 106 128 1/10af12 0/0 0/0 0/0 92 128 1/10af13 0/0 0/0 0/0 78 128 1/10af21 0/0 0/0 0/0 106 128 1/10af22 0/0 0/0 0/0 92 128 1/10af23 0/0 0/0 0/0 78 128 1/10af31 0/0 0/0 0/0 106 128 1/10af32 0/0 0/0 0/0 92 128 1/10af33 0/0 0/0 0/0 78 128 1/10af41 0/0 0/0 0/0 106 128 1/10af42 0/0 0/0 0/0 92 128 1/10af43 0/0 0/0 0/0 78 128 1/10cs1 0/0 0/0 0/0 71 128 1/10cs2 0/0 0/0 0/0 78 128 1/10cs3 0/0 0/0 0/0 85 128 1/10cs4 0/0 0/0 0/0 92 128 1/10cs5 0/0 0/0 0/0 99 128 1/10cs6 172/12616 0/0 0/0 106 128 1/10cs7 0/0 0/0 0/0 113 128 1/10ef 0/0 0/0 0/0 120 128 1/102 3092/4650368 204/309008 15751/23689504 70 128 1/104 2958/4448832 312/450324 15890/23898560 58 128 1/106 3164/4758656 445/603008 15683/23587232 44 128 1/10rsvp 0/0 0/0 0/0 120 128 1/10default 49263/16075336 7/3268 233441/80715440 96 128 1/10

Output queue size 387/max total 600/drops 627903 fragment type end-to-end fragment size 640 cir 508816 bc 5090 be 0 limit 636 interval 10 mincir 508816 byte increment 636 BECN response no IF_CONG no frags 149162 bytes 59819202 frags delayed 121321 bytes delayed 57257850

shaping active traffic shaping drops 628612


956467


show atm bundleThis example is the output of an ATM bundle configuration. In this example, you will note that:

• IP Precedence 5 (voice) is assigned to the 256 kbps Voice PVC (0/600).

• All other precedence values are assigned to the 512 kbps Data PVC (0/60).

WAN-AGG-7200#show atm bundle

BRANCH#60 on ATM3/0.60: UP

Config Current Bumping PG/ Peak Avg/Min BurstVC Name VPI/ VCI Prec/Exp Prec/Exp PrecExp/ PV Kbps kbps Cells Sts AcceptBRANCH60-DAT 0/60 7-6, 4-0 7-6, 4-0 - / Yes - 512 UPBRANCH60-VOI 0/600 5 5 - / No PV 256 256 94 UP

show policy interface atmThis example is the output of an ATM interface policy configuration. In this example, you will note that:

• The service policy is only applied to the data VC.

WAN-AGG-7200#show policy int atm 3/0.60 ATM3/0.60: VC 0/60 -

Service-policy output: WAN-EDGE-DATA

Class-map: VOICE-CONTROL (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp 26 Weighted Fair Queueing Output Queue: Conversation 73 Bandwidth 2 (%) Bandwidth 0 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0

Class-map: GOLD-DATA (match-any)…

show atm vcThis example is the output of an ATM VC configuration. In this example, you will note that:

• Voice gets VBR.

• Data gets UBR.

WAN-AGG-7200#show atm vc VCD / Peak Avg/Min BurstInterface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts3/0.60 BRANCH60-DAT 0 60 PVC SNAP UBR 512 UP3/0.60 BRANCH60-VOI 0 600 PVC SNAP VBR 256 256 94 UP


956467


show atm pvcThis example is the output of an ATM PVC configuration. In this example, you will note that:

• The TX ring limit is set to 3.

WAN-AGG-7200#show atm pvc 0/600ATM3/0.60: VCD: 2, VPI: 0, VCI: 600, Connection Name: BRANCH60-VOICEVBR-NRT, PeakRate: 256, Average Rate: 256, Burst Cells: 94AAL5-LLC/SNAP, etype:0x0, Flags: 0x20, VCmode: 0x0OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)OAM up retry count: 3, OAM down retry count: 5OAM Loopback status: OAM DisabledOAM VC state: Not ManagedILMI VC state: Not ManagedVC TxRingLimit: 3 particlesVC Rx Limit: 18 particlesInARP frequency: 15 minutes(s)Transmit priority 4InPkts: 0, OutPkts: 110674, InBytes: 0, OutBytes: 88317056InPRoc: 0, OutPRoc: 0InFast: 0, OutFast: 110674, InAS: 0, OutAS: 0InPktDrops: 0, OutPktDrops: 10628/0/10628 (holdq/outputq/total)CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0, LengthViolation: 0, CPIErrors: 0Out CLP=1 Pkts: 0OAM cells received: 0F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0OAM cells sent: 0F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutRDI: 0F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0OAM cell drops: 0Status: UP


956467


C H A P T E R 5
QoS in a SOHO Virtual Private Network for IP Telephony
This chapter provides information about implementing QoS in an AVVID-enabled Small Office Home Office (SOHO) Virtual Private Network (VPN) for IP telephony. It includes the following:

• Overview

• QoS Toolset

• Solutions

• Summary


OverviewAs IP telephony becomes accepted in the enterprise, the ability to extend its functionality to SOHO environments is becoming more desirable. This chapter provides in-depth design and configuration guidance for implementation of QoS in a SOHO environment. It focuses on the CPE, or enterprise, implementation of QoS features and functionality. This document does not cover end-to-end QoS design and implementation as it does not include SP design and configuration guidance.

There are many points in SOHO networks where QoS mechanisms are required to manage loss, delay, and delay variation. Figure 5-1 illustrates areas where QoS mechanisms are required to control the impact of loss, delay, and delay variation on voice performance.


Chapter 5 QoS in a SOHO Virtual Private Network for IP TelephonyQoS Toolset

Figure 5-1 Areas of a SOHO Network Where QoS is Needed

QoS ToolsetThe challenges of packet loss, delay, and delay variation can be address through the application of various QoS tools.

This section provides information about the use of QoS tools in a SOHO environment. For general information about the QoS Toolset, see the “What is the Quality of Service Toolset?” section on page 1-12.

ClassificationWithin a SOHO AVVID network, you should classify voice bearer and signaling traffic.

For general recommendations for classification, see “Classification Recommendations” section on page 1-15.

Classification of Voice Bearer traffic

In a SOHO AVVID network, you must classify packets that contain voice traffic so that they can be placed into the appropriate queues. The recommended DSCP PHB label of Expedite Forward (EF) for should be used for VoIP traffic. To remain backwardly compatible with IP Precedence, use an IP Precedence value of 5 and a CoS marking of 5.

These markings can be used as selection criteria for entry into the priority queue, where it exists, or the queue with the highest service weight and lowest drop probability in a WRR/WRED scheduling scheme.

IP

IP

IP

Areas where QoSmay be a concern

Two-box

Third-party modem

Single-box

3rd-partymodem

Cisco806/1710

Cisco806/1710

PIX 501

Backbone To headend

7491

6


956467


Classification of Voice Signaling Traffic

In a SOHO AVVID network, signaling traffic should be assigned a DSCP PHB label of AF31, an IP Precedence value of 3, and a CoS marking of 3.

SchedulingThe IOS feature of LLQ/CBWFQ is used in a SOHO environment to schedule the voice bearer and voice control traffic preferentially over all other types of traffic if there is congestion on the link.

For general recommendations for classification, see “Scheduling Recommendations” section on page 1-22.

ProvisioningIn a SOHO/VPN environment there are many aspects to consider when provisioning the CPE device, such as TX ring sizing, link fragmentation and interleave, traffic shaping, and bandwidth calculation.

TX Ring Sizing

On ATM interfaces, which are the transport medium for many DSL environments, the default depth of the TX ring is very large. However, a large TX ring and LLQ/CBWFQ do not work well together.

When congestion occurs and LLQ/CBWFQ is engaged (to give voice packets preferential treatment), the TX ring must be emptied before the first expedited voice packet can get serialized by the physical interface and be transmitted. If the TX ring is very large, it can take some time to empty before the voice packets are serviced. This results in very short periods of poor voice quality followed by long period of excellent voice quality. The solution is to reduce the TX ring size.

Link Fragmentation and Interleave

In DSL environments that use ATM as the transport medium, MLP with fragmentation and interleave is used as a Layer 2 LFI mechanism. Depending on the underlying (Layer 2) transport, other LFI mechanisms may be required.

Today's cable deployments use link speeds in excess of 768 Kbps. At link speeds greater than 768 Kbps, the variation in delay introduced by random-sized packets is not of significant concern and LFI is not required.

Fragment Sizing for MLPPP over ATM

When ATM is the underlying transport technology in a DSL network, there are 53 byte cells for transport with 48 bytes of usable payload. Therefore, the fragment size selected must be divisible by 48 with a remainder of zero so that partial cells are not transmitted. MLPPP with fragmentation and interleave uses a maximum delay parameter and calculates the fragment size based on the bandwidth of the interface. Some manipulation of the interface bandwidth statement and max delay statement is required to arrive at a fragment size that cleanly maps into ATM cells.


956467


Tip Currently, IOS does not automatically optimize the fragment sizes (which are indirectly defined by the MLP fragment-delay parameter). Arriving at such optimal sizes requires a fair bit of math, which is well documented in the Multilink PPP over Frame Relay and ATM white paper (internal).

Table 5-1 provides a list of often used PVC speeds and the corresponding fragment delay and interface bandwidths required to achieve the desired fragment size and delay.

Table 5-1 Common ATM Virtual Circuit Speeds and Maximum Delay and Bandwidths

Traffic Shaping

Traffic shaping is required in SOHO environments to insure that the SP guaranteed rate is not exceeded. Traffic in excess of the guarantee could result in drops or queuing that would defeat the QoS measures (LLQ/CBWFQ, and LFI) that have been applied at the edge of the network. To avoid congestion in the virtual path through the SP network, traffic in the direction of the SP should be rate-limited to the negotiated SP guaranteed rate.

PVC Speed(in Kbps)

Fragmentation Size(in cells)

PPP Multilink Fragment Delay(in msec)

Bandwidth(in Kbps)

Real Delay(in msec)

56 2 12 57 13.7

64 2 10 68 12.0

128 4 11 132 12.0

192 6 11 202 12.0

256 7 10 260 10.5

320 9 10 337 10.8

384 11 10 414 11.0

448 12 10 452 10.3

512 14 10 529 10.5

576 16 10 606 10.7

640 17 10 644 10.2

704 19 10 721 10.4

768 21 10 798 10.5


956467


Figure 5-2 Traffic Shaping

• In DSL over ATM (PPPoA) environments, ATM traffic shaping per Virtual Circuit (VC) is inherently available. No additional steps beyond defining the VC type and speed are required.

• In DSL over Ethernet (PPPoE) environments, traffic shaping on the egress Ethernet interface of the first QoS capable device is required.

• In Cable environments, the Data over Cable Service Interface Specification (DOCSIS) specification version 1.1 allows us to operate within the guaranteed rates to which the SP has agreed and is policing.

Bandwidth Calculation

QoS is not a substitute for sufficient bandwidth. It is important to understand the exact bandwidth requirements of the priority traffic so that links can be provisioned accordingly. For VoIP traffic in a SOHO environment, you must consider the CODEC sample size, and the IP, UDP, RTP, and IPsec overhead when provisioning the link (as shown in Table 5-1).

Because of the overhead associated with the encapsulating protocols involved in an IPsec solution, the bandwidth requirements are considerably more than one might think. For example, a G.711, or 64 Kbps, call requires 128 Kbps of bandwidth over an ATM (PPPoA) connection.

Figure 5-3 VoIP Bandwidth Utilization Including IPsec

IP

Cisco806/1710

3rd-partyDSL modem

To headend

DSLBackbone

10/100 m Ethernet Shaped 128k Uplink

7491

9

7492

0

Voicepayload

CODEC

G.711 at 50 pps 112 kbps 114.40 kbps 127.20 kbps

G.729A at 50 pps 54.4 kbps 56.8 kbps 63.6 kbps

PlusIP UDP RTP

and IPsec

PlusPPP

Plus ATM cells53b cells 48b

payload equals

RTPHeader

UDPHeader

VoIP Packet

VoIP with IPsec MLPPP over ATM

IPHeader

IPsec & GREHeaders

Linkheader

X Bytes 12 Bytes 8 Bytes 20 Bytes 76/80 Bytes(variable)

X Bytes


956467

Chapter 5 QoS in a SOHO Virtual Private Network for IP TelephonySolutions

SolutionsNow that you understand the problems that you need to solve (classification, scheduling, and provisioning) and the tools that you can use to resolve those problems (LLQ/CBWFQ for classification and scheduling, MLPPP with fragmentations and interleave for LFI), as well as an understanding of the bandwidth requirements of VoIP in an IPsec environment, let's see how you apply these tools in the following environments:

• DSL

• Cable

• Other

Application of QoS to DSL in a SOHO EnvironmentIn SOHO VPN environments that use DSL as the transport, there are three alternatives for deployment (as illustrated in Figure 5-4). They are a one-box solution, a two-box solution, and a solution that uses a third-party modem.

Figure 5-4 Typical DSL Deployments

There are two commonly used methods of delivering DSL to the SOHO, DSL over ATM (PPPoA) and DSL over Ethernet (PPPoE). PPPoA implementations are the only DSL environments where you have the complete set of features required to address all of the QoS requirements of the solution. In a PPPoE environment (as of the writing of this paper), the full set of features required to address QoS from the CPE, or last mile, perspective does not exist.

IP

IP

IP

Two-box

Third-party modem

Single-box

3rd-partyDSL modemCisco

806/1710

Cisco 827

PIX 501

DSLBackbone To head

end

7492

1


956467


One and Two Box DSL Solution

The one-box and two-box solutions require the same set of features from a QoS perspective. The only difference is that in a one box solution, VPN and QoS are in the same box and a two box solution, the VPN functionality is moved out of the DSL termination device. In both of these solutions (where QoS is being provided by the DSL termination devices), all three aspects of QoS must be provided: classification, scheduling (including LFI and traffic shaping), and provisioning.

Figure 5-5 One- and Two-Box DSL Deployments

For the one- and two-box DSL solutions (illustrated in Figure 5-5):

• The IP phone handles classification of the VoIP bearer and control traffic. The IP phone marks its traffic at Layer 2 with a CoS of 5 for bearer traffic and 3 for control traffic. It marks its traffic at Layer 3 with a DHCP PHB label of EF for bearer traffic and AF31 for control traffic.

• A Cisco 827, or equivalent router, handles scheduling.

• LLQ/CBWFQ is used to give the VoIP bearer and control traffic the guarantees for loss, delay, and delay variation that they require.

Example 5-1 shows the IOS configuration used to address the QoS requirements for VoIP in a SOHO environment.

Example 5-1 DSL PPPoA QoS Configuration

class-map match-all VOICE match ip dscp EFclass-map match-all VOICE-CONTROL match ip dscp AF31!policy-map TELEWORK class VOICE priority 64 class VOICE-CONTROL bandwidth 8 class class-default fair-queue

IP

IP

IP

Two-box

Third-party modem

Single-box


806/1710

Cisco 827

PIX 501

DSLBackbone To head

end

7492

2


956467


!interface ATM0 no ip address pvc 1/100 vbr-rt 128 128 tx-ring-limit 3 encapsulation aal5mux ppp dialer dialer pool-member 1interface Dialer0 bandwidth 132 ip address negotiated ip nat outside encapsulation ppp no ip mroute-cache load-interval 30 dialer pool 1 dialer-group 1 service-policy output TELEWORK no cdp enable ppp authentication chap callin ppp chap hostname 827a ppp chap password 7 104D000A0618 ppp multilink ppp multilink fragment-delay 11 ppp multilink interleave

In this example:

• The class-map, policy-map, and service-policy commands are used for scheduling.

• The TX ring must be tuned so that voice traffic (given preferential treatment by the LLQ/CBWFQ configuration) does not wait behind a large amount of other traffic before it is serialized onto the physical interface. The tx ring limit 3 command is used to tune the TX ring to a reasonable depth.

• The majority of DSL deployments deliver an upstream link that is less than 768k. To solve this problem, use MLPPP with fragmentation and interleave. The ppp multilink commands are used to enable MLPPP. You must set the fragment size so that it easily maps into the 48 bytes available for data in an ATM cell. This is accomplished by manipulating the interface bandwidth statement and the MLPPP fragment delay statement to arrive at a fragment size that fits into ATM cells without causing half full cells. The interface bandwidth and ppp multilink fragment-delay commands are used to achieve the desired fragment size in this example.

Tip Table 5-1 lists the bandwidth and fragment delay combinations required for many common ATM VC speeds. A detailed analysis of this requirement and how to arrive at the specified bandwidth and delay values can be found in the Multilink PPP Over Frame Relay & ATM white paper (internal).

• Traffic shaping is handled by the PVC definition. The vbr-rt 128 128 command is used to define the ATM virtual circuit and to shape the traffic to the specified rate.

• This example is provisioned to support a single G.729 call (64 Kbps of bandwidth including the encapsulating technologies overhead). The priority 64 command in the service policy definition section is used to provision the LLQ (PQ) for this purpose.


956467


Third-Party Modem Solution

Figure 5-6 illustrates where QoS is required when a third-party DSL modem is used as the DSL termination device. In this environment QoS cannot be guaranteed.

Figure 5-6 DSL with Third-party Modem

For the third-party modem solution (illustrated in Figure 5-6):


• A Cisco 806 or 1710, or equivalent router, handles scheduling.

• LLQ/CBWFQ is used to recognize and preferentially schedule VoIP bearer and control traffic in the direction of the DSL modem.

• Class-based policing (shaping) is used to rate limit the traffic transmitted towards the DSL modem to the rate that you are guaranteed from the SP on the DSL link.

There are many factors that are out of our control when you do not directly terminate the DSL connection. Example 5-2 illustrates the best that can be done in this environment. The biggest issue left to be resolved in this configuration is the lack of LFI. Packets can be fragmented in the direction of the DSL modem. However, IOS today does not have the ability to interleave on this segment of the network so you can not insure that a VoIP packet will not wait for a maximum MTU packet to serialize out the physical link on the DSL modem. This would introduce a large delay and delay variation into the VoIP traffic and compromise the voice quality (due to packet loss as a result of jitter buffer under and over runs).

IP

IP

IP

Two-box

Third-party modem

Single-box


806/1710

Cisco 827

PIX 501

DSLBackbone To head

end

7492

3


956467


Example 5-2 DSL QoS Configuration with a Third-party Modem

class-map match-any CBS-256kbps match any class-map match-all VOICE match ip dscp EF class-map match-all VOICE-CONTROL match ip dscp AF31 !policy-map WAN-EDGE class VOICE priority percent 33 class VOICE-CONTROL bandwidth percent 2class class-default fair-queue random-detect dscp-basedpolicy-map CBS-256kbps class CBS-256kbps bandwidth 256 shape peak 256000 service-policy WAN-EDGE!interface Ethernet1 ip address dhcp service-policy out CBS-256kbps

In this example:

• The concept of hierarchical service policies and classed-based policing is introduced. The class-map match-any and policy-map commands are used to provide class-based policing. The symbolic name of “CBS-256kbps” represents class-based shaping (CBS) and the link speed.

Note This configuration addresses most of the QoS requirements of a solution where you are not in direct control of the DSL termination. However, LFI is not addressed, so large data packets could introduce variability in delay and affect voice quality.

Application of QoS to Cable in a SOHO EnvironmentIn SOHO VPN environments that use Cable as the transport, there are three alternatives for deployment (as illustrated in Figure 5-7). They are a one-box solution, a two-box solution, and a solution that uses a third-party modem.


956467


Figure 5-7 Typical Cable Deployment

One and Two Box Cable Solution

The one-box and two-box solutions require the same set of features from a QoS perspective. The only difference is that in a one box solution, VPN and QoS are in the same box and a two box solution, the VPN functionality is moved out of the cable termination device.

Figure 5-8 One- and Two-Box Cable Deployments

IP

IP

IP

Two-box

Third-party modem

Single-box

Cisco806/1710

Cisco 9x5

PIX 501

Cablebackbone To head

end

7492

4

IP

IP

IP

Two-box

Third-party modem

Single-box

Cisco806/1710

Cisco 9x5

PIX 501


end74

925


956467


For the one- and two-box cable solutions (illustrated in Figure 5-8):


• QoS is provided via DOCSIS version 1.1. DOCSIS 1.1 provides Layer 2 QoS services that enable a cable solution to provide bandwidth guarantees for VoIP traffic.

It is important to note that QoS in cable environments is not accomplished through the Modular QoS CLI configuration. Instead, a DOCSIS policy is downloaded to the cable router when it boots. Then the router enforces the policy as it transmits traffic. Figure 5-9 illustrates this download process.

Figure 5-9 DOCSIS 1.1 Configuration Downloaded to a Cable Router

Example 5-3 highlights specific options in the cable modem DOCSIS 1.1 configuration that are required to provide the bandwidth and scheduling guarantees for VoIP traffic.

Example 5-3 Cable DOCSIS 1.1 Extracts for QoS

18 (Maximum Number of CPE) = 1022 (Upstream Packet Classification Block) T01 (IP ToS Range & Mask) = 160.160.224 Match IP Prec 5 T02 (IP Protocol) = 256 T02 (Source MAC Addr) = 0-8-21-3a-29-7e Match MAC 23 (Downstream Packet Classification Block) T01 (IP ToS Range & Mask) = 160.160.224 Match IP Prec 5 T05 (Destination Address) = 10.91.20.4 Match IP address T06 (Destination Mask) = 255.255.255.25524 (Upstream Service Flow Block) S19 (Unsolicited Grant Size) = 300 Bandwidth S20 (Nominal Grant Interval) = 20000 Timeslot

In this example:

• Options 22 and 23 specify traffic source and destination.

• Option 24 specifies the bandwidth guarantee being granted to the VoIP traffic.

IP

IP

IP

Two-box

Third-party modem

Single-box

Cisco806/1710

Cisco 9x5

uBR7246

PIX 501Cable

backbone To headend

7492

6


956467


Third-Party Modem Solution

In environments where the cable termination device is not QoS capable, the same restrictions and limitations exist as in a cable environment where a third-party cable modem is used.

Figure 5-10 Cable QoS with a Third-party Modem

For the third-party modem solution (illustrated in Figure 5-10):


• A Cisco 806 or 1710, or equivalent router, provides preferential scheduling for the VoIP bearer and control traffic that has been classified or tagged by the IP phone.

• LLQ/CBWFQ is used to give the preferential treatment.

• The router also shapes its traffic to the guaranteed bandwidth that the service provider is delivering.

There are many factors that are out of our control when you do not directly terminate the cable connection. Example 5-4 illustrates the best that can be done in this environment.

Example 5-4 Cable QoS Configuration with a Third-party Modem

class-map match-any CBS-256kbps match any class-map match-all VOICE match ip dscp EF class-map match-all VOICE-CONTROL match ip dscp AF31 !policy-map WAN-EDGE class VOICE priority percent 33 class VOICE-CONTROL bandwidth percent 2class class-default fair-queue random-detect dscp-based

IP

IP

IP

Two-box

Third-party modem

Single-box

Cisco806/1710

Cisco 9x5

PIX 501


end

7492

7


956467


policy-map CBS-256kbps class CBS-256kbps bandwidth 256 shape peak 256000 service-policy WAN-EDGE!interface Ethernet1 ip address dhcp service-policy out CBS-256kbps

This configuration cannot provide LFI, which means that if the link speeds available in the cable plant are less than or equal to 768 Kbps, the delay through the SP network could introduce packet loss due to jitter buffer over and under runs. In most cable environments, LFI is not needed. However, there is no method in this environment of informing the QoS-enabled router of changes in the load present on the cable segment. For QoS to be effective in this case you must shape to a worst-case rate to protect VoIP bearer and control traffic from congestion in the cable segment. The QoS provided in this environment may not be sufficient to guarantee voice quality as the QoS- enabled router does not have vision into the state of the cable network.

Application of QoS over Other TechnologiesThere are SOHO solutions other than DSL and Cable that are viable solutions for a QoS-enabled SOHO environment that supports IP telephony. Figure 5-11 illustrates alternate environments for SOHO link delivery.

Figure 5-11 Typical Other Deployments

Last Mile Wireless, IDSL, etc.

In environments where the device terminating the SP link is another technology, such as last mile wireless or DSL with ISDN as the Layer 2 transport (IDSL), you can provide scheduling services via LLQ/CBWFQ for the traffic that has been tagged with the appropriate DSCP PHB labels by the IP phone. You can also shape the traffic to the speeds guaranteed to by the SP. You cannot, however, provide LFI for these types of connections. This means that on links where either the link serialization rate or virtual circuit speeds are equal to or less than 768 Kbps, you cannot provide sufficient QoS services to guarantee voice quality.

Example 5-5 illustrates the best that can be done in this environment.

Example 5-5 Configuration for Last Mile Wireless, ISDL, and Others

class-map match-any CBS-256kbps match any class-map match-all VOICE match ip dscp EF class-map match-all VOICE-CONTROL match ip dscp AF31 !

Cisco 80xPIX 501

Others To headend

ISDN,wireless, etc. 74

928


956467


policy-map WAN-EDGE class VOICE priority percent 33 class VOICE-CONTROL bandwidth percent 2class class-default fair-queue random-detect dscp-basedpolicy-map CBS-256kbps class CBS-256kbps bandwidth 256 shape peak 256000 service-policy WAN-EDGE!interface Ethernet1 ip address dhcp service-policy out CBS-256kbps

In this example:

• The class-map VOICE, class-map VOICE-CONTROL, and service-policy WAN-EDGE commands are responsible for providing LLQ/CBWFQ for preferential treatment of the VoIP bearer and control traffic.

• The policy-map CBS-256kbps and service-policy out CBS-256kbps commands are responsible for shaping the traffic towards the SP link, protecting the VoIP traffic from unexpected loss and queuing delays due to exceeding the SP guaranteed bandwidth.

Voice over ISDN

VoIP over ISDN is an acceptable solution for a SOHO solution. Figure 5-12 illustrates how a SOHO connected via ISDN would look from a device perspective.

Figure 5-12 VoIP over ISDN

This is not a solution where IPsec is encrypted through the Internet. It is a private network extension using IDSN. Prior to IOS 12.2(7a), this was not a viable solution because the LLQ/CBWFQ Modular QoS CLI service policies were not available for ISDN connections. With IOS 12.2(7a) and beyond, you now have access to the full suite of tools required to guarantee voice quality over an ISDN connection.

Example 5-6 illustrates the IOS configuration required to provide QoS in this environment.

Example 5-6 VoISDN QoS Configuration Example

class-map match-all VOICE match ip dscp EFclass-map match-all VOICE-CONTROL match ip dscp AF31 !

IP

Cisco 80x To headend

ISDN,wireless, etc. 74

929


956467

Chapter 5 QoS in a SOHO Virtual Private Network for IP TelephonySummary

policy-map VOICE-AND-DATA class VOICE priority percent 33 class VOICE-CONTROL bandwidth percent 10!interface BRI0/0 encapsulation ppp dialer pool-member 1 ppp authentication chapinterface Dialer1 encapsulation ppp dialer pool 1 dialer remote-name routerB-dialer1 dialer-group 1 dialer string 12345678 service-policy output VOICE-AND-DATA ppp authentication chap ppp chap hostname routerA-dialer1 ppp chap password cisco ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave ppp multilink links minimum 2

In this example:

• The class-map, policy-map, and service-policy commands enable LLQ/CBWFQ to provide preferential treatment for the VoIP bearer and control traffic.

• The ppp multilink commands enable MLPPP/LFI to use link fragmentation and interleave to protect VoIP traffic from variable delay due to serialization of random packet sizes.

Tip A detailed study of VoIP over ISDN can be found in the VoIP over ISDN white paper (internal).

SummaryThere are three major categories of SOHO environments: DSL, Cable, and others. These environments have varying levels of QoS support.

• DSL over ATM environments support the full suite of QoS features. In a DSL over ATM (PPPoA) environment, LLQ/CBWFQ is used to give VoIP traffic preferential treatment and MLPPP with fragmentation and interleave is employed to break data traffic into small fragments and protect VoIP traffic from delay due to serialization of large packets on the physical interface. DSL over ATM also inherently supports traffic shaping, as the rates that the ATM virtual circuit can support must be defined when the virtual circuit is configured. This insures that the DSL terminating device will not transmit traffic at a rate in excess of the SP guaranteed rate.

• Cable solutions that are DOCSIS 1.1 enabled can also provide the QoS services required to support VoIP applications. The QoS mechanisms required are inherent to DOCSIS 1.1.

• Other solutions (such as DSL over Ethernet (PPPoE), DSL over ISDN (IDSL), or implementations where a third-party device terminates the SP link) support an incomplete set of QoS services and are not ideal candidates for environments where guaranteed VoIP performance is required. However, many QoS problems can be overcome in these environments and VoIP for internal enterprise communications can be supported.


956467


C H A P T E R 6
QoS with MPLS in an AVVID-Enabled Network
This chapter discusses the ability of MPLS VPNs to support QoS functionality for AVVID, whether the MPLS backbone is an SP-owned or customer-owned network. It includes the following:

• Overview

• Considerations for MPLS VPN QoS

• Implementing MPLS VPN QoS

OverviewTraditionally, VPNs for site-to-site connectivity have been provided as either Layer 2 networks (such as a Frame Relay PVC), as IPSec tunnels across Layer a 3 network (such as the Internet), or as a combination of the two. MPLS was designed to provide for a more robust Layer 3 VPN offering, allowing for overlapping address space, additional hierarchy of routing, and traffic engineering.

MPLS is a new forwarding mechanism in which packets are forwarded based on labels. Labels can correspond to IP destination networks (equal to traditional IP forwarding) or to other parameters, such as QoS or source address.

Unlike in Layer 3 networks, with MPLS only edge routers must perform a routing lookup. Although all the devices within the network participate in the routing architecture (control plane), the core routers switch packets based on simple label lookups and swap labels, instead of the traditional IP address lookup in a forwarding database. A core router can be an MPLS-capable traditional Layer 3 router or a Layer 2 device, such as an ATM switch that is enabled to participate in the MPLS control plane. With MPLS, ATM switches forward cells based on a knowledge of the dynamic Layer 3 architecture of the network, rather than on static ATM PVC configurations.


Chapter 6 QoS with MPLS in an AVVID-Enabled NetworkOverview

MPLS VPN ArchitectureMPLS VPNs leverage the MPLS architecture to provide VPNs across an SP Layer 3 network. MPLS VPNs are composed of three basic entities:

• Customer edge (CE) router—The last-hop router on the customer network. This router provides connectivity to the SP MPLS network by connecting to the provider edge router. The CE router is not aware of any MPLS functionality and is not required to use any special IOS feature set.

• Provider edge (PE) router—The only device in the network that is configured specifically for MPLS VPNs. The ingress interface on the PE router is configured to define the specific VPN to which the customer is connected. The PE router is responsible for assigning a label to each VPN and redistributing the routes between the customer and BGP within the provider backbone.

• Provider core—May include MPLS-enabled devices (P routers) or non-MPLS-enabled Layer 2 devices, such as ATM switches that are not enabled to support MPLS. The P routers are simply provider backbone devices configured to support MPLS. There is no definition of VPNs on these devices. They serve merely to support an additional layer of hierarchy to the MPLS network.

Figure 6-1 shows a basic implementation of these devices in a network with an MPLS core.

Figure 6-1 MPLS Architecture

MPLS Modes of OperationMPLS technology is intended to be used anywhere regardless of Layer 1 media and Layer 2 protocol. There are two label allocation and switching methods:

• Frame mode, which can be used over any Layer 2 transport, including ATM. Frame-mode MPLS uses a 32-bit label field that is inserted between the Layer 2 and Layer 3 headers.

• Cell mode, which is used only in environments where ATM is the transport. Cell-mode MPLS over ATM uses the ATM header as the label. Any other labels (such as the VPN label applied by BGP to a packet before the packet is sent to the egress interface) assigned to the packet prior to the segmentation and reassembly (SAR) are included in the first cell payload and are available for packet forwarding once the cells have been reassembled.

When using MPLS VPNs, BGP allocates an additional unique 32-bit label for each VPN. If the egress interface is a cell interface, this label is applied in the VPI/VCI field. If the egress interface is a frame interface, an additional 32-bit label is assigned and a label-stack is created.

CE CECustomer VPN2Customer VPN1

Customer Edge

PEP P

P

PE

Internet PE

InternetProvider EdgeVPN Edge LSR

Service Provider

MP-BGP

7835

6


956467


MPLS LabelsThe MPLS label (as shown in Figure 6-2) is 32 bits long and is made up of the following:

• The 20-bit label field

• The 3-bit experimental (EXP) field

• The 1-bit bottom-of-stack bit (labeled S), which indicates if the label is the last label in the label stack

• The 8-bit time to live (TTL) field, which is used to prevent indefinite looping of packets

Figure 6-2 MPLS Label Format

Note The EXP field is 3 bits. Therefore, the full DSCP label cannot be carried. By default, the field is set to the IP Precedence value of the original IP packet, but this can be changed by applying a policy at the MPLS node.

MPLS Label Stack

In a typical MPLS network there is only one label assigned to a packet. There are instances, however, when multiple labels are necessary, such as

• MPLS VPNs—Two labels are used. The first label points to the egress routers and the second label identifies the VPN.

• MPLS TE—Two or more labels are used. The first label points to the endpoint of the traffic engineering tunnel and the second label points to the destination.

• MPLS VPNs combined with MPLS TE—Three or more labels are used.

Figure 6-3 illustrates the format of a stacked label.

Figure 6-3 MPLS Label Stacking

Within the protocol field of a Layer 2 frame, the protocol identifier specifies that the payload starts with a label and is followed by an IP header. Within the label, the bottom-of-stack bit indicates whether the next header is another label or a Layer 3 header.

When there are multiple labels within a label stack, the receiving label-switch router uses the first label only.

7835

2

Label

0 19 20 22 23 24 31

EXP S TTL

FrameHeader

PID=MPLS-IP S=0 S=0 S=1

PayloadLabel 1 Label 2 Label 3 IP Header78

355


956467


Placement of Labels by Mode

As mentioned before, the placement of the label depends on the MPLS mode used. Figure 6-4 and Figure 6-5 highlight the application of labels in frame and cell modes for MPLS.

Figure 6-4 Frame-Mode MPLS

Figure 6-5 Cell-Mode MPLS

Labels are inserted between the Layer 2 (frame) header and the Layer 3 (packet) header.

FrameHeader

IP Header

Layer 2 Layer 3

Routinglookup and labelassignment

Payload

FrameHeader

IP Header

Layer 2 Layer 3

Payload

7835

3Label

Layer 2½

FrameHeader

IP Header

Layer 2 Layer 3

VPI/VCI fields areused for labelswitching

Payload

ATMHeader

ATM AdaptationLayer 5 (AAL5) Header

Layer 2

Cell 1 Payload

FrameHeaderLayer 2 Layer 3

PayloadLabel

Layer 2½

Label

Layer 2½

IP Header

Layer 3

IP Header

ATMHeaderCell 2 Payload

7835

4


956467

Chapter 6 QoS with MPLS in an AVVID-Enabled NetworkConsiderations for MPLS VPN QoS

MPLS VPN QoS MPLS provides for differentiated service QoS functionality, including:

• LLQ/CBWFQ, which uses a class-map to classify traffic, and then applies a policy map to those classifications to allocate bandwidth for each class of service. The policy map is then applied to the MPLS interface.

• Committed access rate (CAR), which can mark packets upon their arrival and perform recursive actions on packets, including changing the marking or dropping packets that are out-of conformance.

• Class-based policing, which is similar to CAR, but does not support recursive actions.

• Class-based marking, which sets the MPSL EXP bits instead of accepting the default mapping of IP Precedence into the EXP bits.

These functions are configured using the modular QoS CLI within Cisco IOS.

For frame-mode MPLS, QoS relies on the use of the MPLS label EXP field. For cell-mode MPLS, which cannot leverage the EXP field, QoS is achieved by using up to four labels for four individual classes of service.

Considerations for MPLS VPN QoSWhen considering MPLS VPN QoS, you must consider the following factors:

• Convergence

• Redundancy

• Using IP Multicast over MPLS VPNs

ConvergenceA very important factor to consider in the design of an AVVID network is the convergence of the network in a time of failure. Specifically, you must consider what happens at the time of failure and what happens when the link or device is restored. The behavior of the network is quite different in these two scenarios.

After a Link Failure

In the event of a link failure:

• MPLS convergence in frame-mode MPLS does not affect the overall convergence time.

• MPLS convergence occurs immediately after the routing protocol convergence and is based on labels already stored in the label information base.


956467


After a Link Recovery

After a link recovers:

• Routing protocol convergence optimizes the forwarding path after a link recovery.

• The label information base might not contain the label from the new next hop by the time the IP convergence is complete.

• End-to-end MPLS connectivity might be intermittently broken after link recovery until IP reconvergence is complete.

• It is possible to use MPLS traffic engineering for make-before-break recovery to reduce or eliminate broken connectivity after link recovery.

RedundancyTo provide stability for the WAN, you can use redundant links from the MPLS VPN backbone to the customer site (redundant PE-CE links). To allow for full redundancy, the PE and CE routers can also be redundant. When this is done, it becomes important to decide how the traffic is routed in steady-state conditions. The options are:

• Using primary-backup links—The links are allocated as primary-backup. Under normal conditions, no traffic will flow over the backup link. The IGP routes traffic that is outbound from the site to the MPLS backbone to the primary link using the metrics available. Both CE routers must be receiving routing updates (either a default route or full routes for the VPN).

When the primary CE router fails, all traffic is routed to the backup CE router and traffic flows outbound from the backup CE router over the backup link. Return traffic can be routed to the primary link based on the BGP metrics at the PE routers.

By setting communities and local pref, you can force traffic to the primary PE-CE link in normal state. Upon failure of the primary CE router or primary CE-PE link, all traffic will flow over the backup link.

Both links must be configured identically for support of voice and video in the LLQ design (unless this traffic is forced off-net in the event of a primary route failure). It is good practice to stop all signalling across the backup as well, to prevent any call setup.

• Using load sharing—The links are provided as load sharing. There are several issues with this option. Admission control and QoS for voice and video become more difficult.

There is no way to effectively ensure that the traffic is fully load-balanced. Therefore, determining how to create the priority queues on the PE-CE links becomes very difficult. Both CE-PE links must be configured to support the full load of traffic allowed by the connection admission control mechanisms of the network.

Both OSPF and EIGRP allow for load sharing by default. However, the MPLS core uses BGP, which places only a single entry for a route into the routing table, preventing load sharing. To influence the load-sharing mechanism from the MPLS VPN backbone to the CE devices, the PE routers have to be configured to prefer some routes over one path and the rest over the other path. While this may provide a good balance at first, as data flow patterns change over time, this will result in an unbalanced load between the two links.

Note For this configuration, there exists a high probability that traffic flows will be asymmetrical.


956467


To expand this to larger sites, the same routing configurations can be expanded to provide for multiple primary and backup links. However, it is easiest to deploy this configuration when voice is kept on a single link and video is kept on a single link (which may be the same link as voice). This way, the network can be configured with substantially less effort and complexity. This makes it easier to create ACLs to influence IP routing, both outbound from and inbound to the site, and to control the flow of call setup when primary links are down.

Additionally, the SP can implement MPLS traffic engineering, which can be tailored to reduce the time required for convergence in the event of a link failure within the MPLS backbone. Note that in this case, there will be a minimum of three labels in the stack: one assigned by BGP for identifying the VPN, one by the label distribution protocol (LDP), and one for traffic engineering.

To provide additional resiliency, the customer can use ISDN backup. A router can be deployed either just for that customer, in which case it would function as another CE device, or for a pool of customers.

Note In the past, support has not been available for CEF on dialer interfaces, which would eliminate the ability to deploy MPLS on this node as a PE device. With IOS 12.2T, support was included for VRF-aware dialer interfaces. Enabling an SP can use a single access server or router for multiple customers.

Using IP Multicast over MPLS VPNsInitially, MPLS VPNs did not natively support IP multicast traffic. To provide for IP multicast traffic (music-on-hold, broadcast video, etc.), GRE tunnels were provisioned allowing the IP multicast packets to ride inside of IP unicast tunnels. Because the GRE tunnels were point-point, there was an inherent scalability concern as the number of CE routers grew. In addition, the CE routers, which were the tunnel endpoints, were required to perform a substantial amount of packet replication.

Then, multicast VPNs (MVPNs) were outlined in the IETF draft, Multicast in MPLS/BGP VPNs (draft-rosen-vpn-mcast-03.txt). This draft defines three possible methods of providing for IP multicast in a MPLS VPN environment:

• Multicast domains—The PE router creates a multicast tunnel interface (MTI) and multicast virtual routing and forwarding (VRF). The MTI encapsulates the customer multicast traffic within it's own multicast packet for traversing the core.

• VPN-IP PIM—The provider MPLS network runs PIM natively and the customer multicast VRFs are leaked into the global routing table.

• Multicast domain using PIM NBMA functionality—This creates a tunnel interface on the PE routers and unicast encapsulates the multicast packets. This is very resource intense on the PE router as it must replicate all multicast packets for each remote PE.

Cisco's implementation is based upon the multicast domain solution.

The provider must have a multicast-enabled core to use the Cisco MVPN solution. However, the customer’s IP Multicast network does not interact with the provider's multicast control plane. This means that although the PE must interact with the CE router, the provider's multicast stability has no dependency upon the CE's multicast stability.

Also, the MVPN solution does not require BGP to be deployed in the service provider core. However, the PE routers must have MBGP for the next hop information. Note that only PIM-Sparse mode is supported. Only PE routers that have connected CE routers which have requested to join this PIM group will join the provider's multicast tree. The PE routers must be PIM adjacencies and have a BGP relationship.


956467

Chapter 6 QoS with MPLS in an AVVID-Enabled NetworkImplementing MPLS VPN QoS

A Data Multicast Data Tree (MDT) is a dynamically generated group, created when a customer's stream of multicast traffic exceeds a configured threshold on the PE. The purpose of the MDT is to allow only those remote PEs who are interested in that stream to receive it. Currently, only one MVRF is permitted. Effectively, there can be only a single Closed User Group such that you can not provide for MVRF-MVRF connectivity within the MPLS network, as can be done for unicast VRFs through the use of route targets.

When MDTs are created, the remote PEs are notified of the Data MDT via a UDP packet on port 3232. This UDP packet is sent on the default MDT to all remote PEs. The UDP packet encapsulates a 224.0.0.13, all PIM routers message. The receiving PE router runs an RFP check and verifies that the originating PE is correct for the connected CE router. Each customer must use a different group number for the MDT within the provider network.

Note Cisco’s implementation of MVPN is currently scheduled to FCS in IOS version 12.2(12)T, which is subject to change. Contact the your Cisco representative to verify the availability of MVPNs.

One other option for providing IP multicast capabilities, is to use a satellite network for the transmission of the IP multicast data. Within IOS, there are tools to provide for this functionality without causing reverse path-forwarding failures. This is not unique to the MPLS environment and can be used to supplement any data network.

Implementing MPLS VPN QoSIn an MPLS VPN, QoS is applied at all levels of the MPLS architecture: CE routers, PE routers, and P routers.

CE RoutersAs mentioned earlier, the CE routers are not aware of the presence of the MPLS VPN network. As a result, the QoS capabilities of each CE device are unaltered, that is, the use of all QoS mechanisms available for that platform is retained. WAN edge routers within the AVVID architecture are required to be able to provide the appropriate queuing mechanisms, such as LLQ. The router may also provide packet (re)classification, link fragmentation and interleaving, and congestion avoidance.

Following the AVVID architecture, the PE-CE link typically uses LLQ, with voice bearer traffic and H.323 video conferencing traffic assigned to the priority queue, each policed individually with a separate threshold. Voice bearer traffic is given a IP Precedence of 5 (DSCP label of EF). H.323 video conferencing traffic is given an IP Precedence of 4 (DSCP label of AF41). All voice signalling traffic, as well as data traffic, uses CBWFQ.

The CE router is responsible for all classification and marking to ensure that traffic is treated appropriately throughout the MPLS network, conforming to the agreement with the carrier. In addition, the CE router is required to perform traffic shaping to ensure that no packets are marked discard eligible by the carrier and to match the rate agreed to by the SP.

For sites with a single CE-to-PE link, with or without a backup link, the CE router can use a single default route from the MPLS network, rather than full routing tables. For more complex topologies, CE routers typically require that the MPLS network send full routes to the customer routing protocol (EIGRP, OSPF, etc.).


956467


Because the PE routers use BGP, all of the routing options normally associated with BGP are available to influence path selection into a site with multiple links (local preference, communities, etc.). For traffic outbound from the CE to the PE routers, link selection can be based on the metrics of the internal IGP, which routes traffic to the appropriate PE router for transmission to the MPLS network. When using ATM as the transport mechanism from the CE to the PE, the IOS version implemented on the CE router must support both generic traffic shaping and LLQ on a single ATM virtual circuit.

Example 6-1 shows the configuration of a CE router. In this example, voice bearer traffic is set to an IP Precedence of 5, voice signaling to 3, and video to 4. Voice bearer traffic and video are sent to the priority queue, and voice signalling is sent to a CBWFQ. The commands to implement QoS are highlighted in bold.

Example 6-1 MPLS QoS CE Configuration

class-map match-all VOICE match ip dscp efclass-map match-all VIDEO match ip dscp af41class-map match-all VOICE-CONTROL match ip dscp af31class-map match-any GOLD-DATA match ip dscp af21 match ip dscp af22 match ip dscp af23class-map match-any SILVER-DATA match ip dscp af11 match ip dscp af12 match ip dscp af13!!policy-map WAN-EDGE class VOICE priority percent 17 class VIDEO priority percent 16 30000 class VOICE-CONTROL bandwidth percent 2 class GOLD-DATA bandwidth percent 25 random-detect dscp-based class SILVER-DATA bandwidth percent 15 random-detect dscp-based class class-default fair-queue random-detect dscp-based random-detect dscp 0 96 128 10 random-detect dscp 2 70 128 10 random-detect dscp 4 58 128 10 random-detect dscp 6 44 128 10 !interface Loopback0 ip address 192.169.1.2 255.255.255.255!interface Ethernet0/0 ip address 10.3.1.1 255.255.255.0 ip helper-address 10.3.3.0 full-duplex no cdp enable!


956467


interface Serial0/0 bandwidth 4000 ip address 10.13.1.2 255.255.255.0 no cdp enable service-policy output CE-EDGE !router eigrp 65network 10.0.0.0redistribute bgp 60passive-interface serial 0/0!router bgp 60 no synchronization bgp log-neighbor-changes network 192.168.1.0 network 10.0.0.0 neighbor 192.169.1.1 remote-as 60 neighbor 192.169.1.1 update-source Loopback0

PE Routers The PE router is required to provide QoS for both native IP packets (on the PE-to-CE link) as well as labeled MPLS packets (on the PE-to-P links). For the PE-CE link, IP Precedence and LLQ is used. The PE router also provides traffic shaping, but not packet reclassification (which is performed prior to entrance into the carrier MPLS network). IOS 12.2T (or later) is required to provide for multiple classes of service on each VRF interface and to be able to use a non-MPLS ATM network.

For the PE-to-P links, the MPLS mode must be considered.

• As mentioned earlier, in frame-mode MPLS the label includes a 3-bit EXP field, which includes the IP Precedence setting of the incoming packet mapped to that label field. So for frame mode, all of the modular QoS CLI functions are available to police and queue traffic based on the EXP bits.

• For cell-based MPLS, the label for the outbound cells does not include any inherent QoS classification field. It is simply the assigned VPI/VCI label, which include the 3 bits that indicate one of four labeled virtual circuits.

If the plan is to use a single labeled virtual circuit per destination for the PE-to-P links, there must be a mapping from the class-of-service (gold, silver, bronze) to a per-virtual circuit queuing mechanism on the egress interface. If there are no P routers and the MPLS backbone is simply a mesh of PVCs, then there must either be a per-virtual circuit queuing mechanism or the ability to map different classes of service to virtual circuits with different shaping characteristics (PCR, etc.) or service guarantees (CBR, VBR-nrt, VBR-rt, etc.).

In a cell-based MPLS network, normal operation uses a single virtual circuit per destination and allows CBWFQ to be applied to that virtual circuit. Routers can alternatively use up to 4 virtual circuits for each destination, using a classification based on the low-order 2 bits of the EXP filed at the ingress to the cell MPLS network. This limit of 4 virtual circuits requires additional planning of the classes supported within the EXP bits as there are now only 4 classes (reduced from the 8 available via the 3 EXP bits).

Table 6-1 shows the default mapping of EXP values to labeled virtual circuits in cell-mode MPLS. This mapping can be altered through the modular QoS CLI.


956467


Table 6-1 Mapping of EXP Values to Virtual Circuits

Within an ATM network that is not MPLS enabled, each ATM permanent virtual circuit looks like a point-to-point connection to the MPLS nodes. Given that, each node must apply a per-virtual circuit mechanism, such as CBWFQ, in order to enforce QoS. One option that can be used, but which inherently does not scale, is to rate-limit the egress interfaces of the CE routers. This ensures that the MPLS backbone network, which is ATM, cannot be over-subscribed. This is difficult enough to ensure in a steady-state condition, but under failure within the ATM network, a mechanism must be used to ensure that no PVCs are re-routed to a link that would cause over-subscription.

Example 6-2 shows the configuration of a PE router.

In this example, the PE router uses a policer to check the inbound traffic from the customer CE router and sets the MPLS EXP bits based on whether the traffic is in conformance with the service contract, as agreed to by the customer and SP. The commands to implement QoS are highlighted in bold.

Example 6-2 PE Router Configuration

version 12.0ip cef distributedno ip fingerno ip domain-lookup!class-map match-all VOICE-MPLS

match mpls experimental 5class-map match-all DATA-MPLS

match mpls experimental 1 2

class-map match-all VOICE-DSCPmatch ip dscp ef

class-map match-all DATA-DSCPmatch ip dscp af31 af21 af22 af23 af11 af12 af13

!!policy-map PE-EDGE-IN

class VOICE-DSCPpolice 1280000 32000 32000 conform-action set-mpls-exp-transmit 5 exceed-action drop

class DATA_DSCPpolice 22000000 550000 550000 conform-action set-mpls-exp-transmit 2exceed-action set-mpls-exp-transmit 1

class class-defaultset mpls experimental 0

!!

MPLS EXP Value VC

0 Available

1 Standard

2 Premium

3 Control

4 Available

5 Standard

6 Premium

7 Control


956467


policy-map PE-EDGE-OUTclass VOICE-MPLSpriority percent 33

class DATA-MPLSbandwidth percent 42random-detect dscp-based

class class-defaultrandom-detect dscp-based

!mpls traffic-eng auto-bw timers!ip vrf testvrf rd 100:20 route-target import 100:30!!interface Loopback0 ip address 172.16.255.1 255.255.255.255 no ip directed-broadcast!interface POS0/0/0 ip address 172.16.0.1 255.255.255.252 no ip directed-broadcast ip router isis encapsulation ppp ip route-cache distributed service-policy output PE-EDGE-OUT tag-switching ip! interface Serial1/0/0 ip address 192.168.1.1 255.255.255.252 ip vrf forwarding testvrf no ip directed-broadcast ip route-cache distributed service-policy input PE-EDGE-IN!router isis 60 net 49.0011.0000.0000.0005.00 is-type level-2-only metric-style wide max-lsp-lifetime 65500 lsp-refresh-interval 64000 log-adjacency-changes!router bgp 10 no synchronization bgp log-neighbor-changes network 192.168.1.0 neighbor 172.16.255.2 remote-as 10 neighbor 172.16.255.2 update-source Loopback0!address-family ipv4 vrf testvrf redistribute connected neighbor 192.169.1.2 remote-as 60 neighbor 192.169.1.2 activate neighbor 192.169.1.2 send-community both neighbor 192.169.1.2 as-override neighbor 192.169.1.2 route-map RESTRICT-SOO in neighbor 192.169.1.2 description --------------- CE ROUTER no auto-summary no synchronization exit-address-family !


956467


address-family vpnv4 neighbor 172.16.255.2 activate neighbor 172.16.255.2 send-community both no auto-summary exit-address-family!route-map RESTRICT-SOO permit 120 match ip address acl-any set local-preference 120 set extcommunity soo 10:400!ip classless

P RoutersThe MPLS P-to-PE links were discussed in the PE Routers section. For P-to-P links, again a differentiation must be made for frame versus cell modes of operation.

• For frame mode, all of the modular QoS CLI functions are available to police and queue traffic based on the EXP bits.

• For cell mode, the label virtual circuits have been created at the edge and all label virtual circuits are mapped through the MPLS backbone prior to the actual flow of data.

Example 6-3 shows the configuration of a P router. The commands to implement QoS are highlighted in bold.

Example 6-3 P Router Configuration

ip subnet-zerono ip domain-lookupmpls traffic-eng auto-bw timers!!interface Loopback0 ip address 172.16.255.2 255.255.255.255 no ip directed-broadcast!interface POS0/0 ip address 172.16.0.2 255.255.255.252 no ip directed-broadcast encapsulation ppp tag-switching ip crc 16 clock source internal!interface POS0/1 ip address 172.16.192.1 255.255.255.252 ip router isis no ip directed-broadcast encapsulation ppp tag-switching ip crc 16 tx-cos P-EDGE-OUT!


956467


router isis 60 net 49.0011.0000.0000.0006.00 is-type level-2-only metric-style wide max-lsp-lifetime 65500 lsp-refresh-interval 64000 log-adjacency-changes!ip classlessip route 0.0.0.0 0.0.0.0 10.0.152.1ip pim rp-address 150.100.99.1!!cos-queue-group P-EDGE-OUT precedence 0 random-detect-label 0 precedence 1 queue 1 precedence 1 random-detect-label 1 precedence 2 queue 1 precedence 2 random-detect-label 2 precedence 5 queue low-latency random-detect-label 0 300 500 1 random-detect-label 1 100 300 1 random-detect-label 2 300 500 1 queue 0 50 queue 1 50 queue low-latency strict-priority


956467


A P P E N D I X A
Reference Information
DSCP EquivalentsTable A-1 correlates DSCP PHB labels to their binary and decimal representation. It also shows the IP Precedence decimal and binary equivalents.

Table A-1 DSCP and IP Precedence Decimal and Binary Equivalents

DSCP PHB DSCP Binary DSCP DecimalIP Precedence Decimal

IP Precedence Binary

- 000010 2 0 000

- 000100 4 0 000

- 000110 6 0 000

BE 000000 0 0 000

AF11 001010 10 1 001

AF12 001100 12 1 001

AF13 001110 14 1 001

AF21 010010 18 2 010

AF22 010100 20 2 010

AF23 010110 22 2 010

AF31 011010 26 3 011

AF32 011100 28 3 011

AF33 011110 30 3 011

AF41 100010 34 4 100

AF42 100100 36 4 100

AF43 100110 38 4 100

EF 101110 46 5 101

A-1 Enterprise Quality of Service Design

Appendix A Reference InformationCatalyst 6500 Linecards and Queuing Mechanisms

Catalyst 6500 Linecards and Queuing MechanismsTable A-2 shows the linecards and queuing mechanisms available for the Catalyst 6500.

Table A-2 Available Linecards and Queuing Mechanisms for the Catalyst 6500.

Product NumberBackplane Connection Forwarding

Number of Transmit Queues/Port

Number of Receive Queues/Port

WS-X6348-RJ-45 Bus Centralized 2q2t 1q4t

WS-X6348-RJ-21 Bus Centralized 2q2t 1q4t

WS-X6324-100FX-SM Bus Centralized 2q2t 1q4t

WS-X6324-100FX-MM Bus Centralized 2q2t 1q4t

WS-X6248A-TEL Bus Centralized 2q2t 1q4t

WS-X6548-RJ-45 Switch fabric and bus Centralized 1p3q1t 1p1q0t

WS-X6548-RJ-21 Switch fabric and bus Centralized 1p3q1t 1p1q0t

WS-X6524-100FX-MM Switch fabric and bus Centralized 1p3q1t 1p1q0t

WS-X6408-GBIC Bus Centralized 2q2t 1q4t

WS-X6408A-GBIC Bus Centralized 1p2q2t (3) 1p1q4t (2)

WS-X6316-GE-TX Bus Centralized 1p2q2t (3) 1p1q4t (2)

WS-X6416-GBIC Bus Centralized 1p2q2t (3) 1p1q4t (2)

WS-X6501-10GEX4 Switch fabric and bus Centralized. Support for distributed forwarding with optional DFC

1p2q2t (3) 1p1q4t (2)

WS-X6516-GBIC Switch fabric and bus Centralized. Support for distributed forwarding with optional DFC

1p2q2t (3) 1p1q4t (2)

A-2Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Appendix A Reference InformationMission-Critical Applications Well-Known Ports

Mission-Critical Applications Well-Known PortsTable A-3 summarizes some of the more popular important data applications within enterprises. The list is by no means exhaustive.

Tip A comprehensive list can be found at IANA:

http://www.iana.org/assignments/port-numbers

Table A-3 Mission-Critical Applications Well-Known TCP Ports

Application TCP Ports Description NBAR Keyword

CCMail 3264 Lotus Mail

Citrix 2512, 2513 Citrix Admin

Citrix 2598 Citrix Client

CU-SeeMe 7648, 7649 Desktop video conferencing cuseeme

HTTP 80 Hypertext Transfer Protocol http

HTTPS 443 Secured HTTP secure-http

IMAP 143, 220 Internet Message Access Protocol imap

IRC 194 Internet Relay Chat irc

Kerberos 88, 749 Kerberos Network Authentication Service kerberos

LDAP 389 Lightweight Directory Access Protocol ldap

Lotus Notes 1352 Lotus Notes

MS-PPTP 1723 Microsoft Point-to-Point Tunneling Protocol for VPNs pptp

MS-SQLServer 1433 Microsoft SQL Server Desktop Videoconferencing sqlserver

NetBIOS 137, 139 NetBIOS over IP (MS Windows) netbios

NNTP 119 Network News Transfer Protocol nntp

Novadigm 3460 - 3465 Novadigm Enterprise Desktop Manager (EDM) novadigm

Oracle 9000 Oracle/PeopleSoft Application

Oracle 1524 Oracle/PeopleSoft Database

Oracle 2481 - 2484 Oracle version 8

PCAnywhere 5631, 65301 Symantec PCAnywhere pcanywhere

POP3 110 Post Office Protocol pop3

Printer 515 Printer printer

PeopleSoft 1433 PeopleSoft SQL Server

PeopleSoft 8000 - 8004 PeopleSoft FDM

PeopleSoft 7000 - 7004 PeopleSoft HRMS

PeopleSoft 9000 - 9004 PeopleSoft Jolt Application Server

PeopleSoft 9100 9104 PeopleSoft JRAD Application Server

SAP 3200-3399 SAP


956467

Appendix A Reference InformationDLSW+ Considerations

DLSW+ ConsiderationsA potential issue arises with recommended LLQ/CBWFQ admission criteria for AVVID when DLSW+ traffic is present in the network. DLSw+ traffic is marked with an IP Precedence of 5 (DSCP 40) by default when DLSw+ is enabled on a router. This may interfere with, and adversely affect, bandwidth provisioning policies. The solution is to modify DLSw+ traffic marking.

First ensure that the DLSw+ priority statement is not being used to classify DLSw+ traffic with multiple IP Precedence values utilizing multiple TCP/IP ports for communication. If this is not the case, the following commands can be added to the configuration of DLSw+ peer routers to change the default DLSw+ IP Precedence to 2.

dlsw local-peer peer-id 192.168.10.1

dlsw remote-peer 0 tcp 192.168.100.1

dlsw tos map high 2 medium 2 normal 2 low 2

Because DLSw+ does not currently support the full DSCP range, a separate match statement for ToS 2 (DSCP 16) would be required in the class-map for mission-critical data on the WAN edges. An example is shown:

class-map match-any GOLD-DATA match ip dscp 16 Assigns newly-modified DLSw+ traffic to Gold class. match ip dscp af21 match ip dscp af22

Tip For additional information, refer to the Cisco alert titled DLSw+ Marks Its Traffic with IP Precedence of 5 (internal).

SFTP 990 Secure FTP secure-ftp

SHTTP 443 Secure HTTP secure-http

SIMAP 585, 993 Secure IMAP secure-imap

SIRC 994 Secure IRC secure-irc

SLDAP 636 Secure LDAP secure-ldap

SMTP 25 Simple Mail Transfer Protocol smtp

SNMP 161, 162 Simple Network Management Protocol snmp

SNNTP 563 Secure NNTP secure-nntp

SOCKS 1080 Firewall security protocol socks

SPOP3 995 Secure POP3 secure-pop3

SSH 22 Secured Shell ssh

STELNET 992 Secure Telnet secure-telnet

Sun 111 Sun RPC

Telnet 23 Telnet Protocol telnet

X Window System 6000-6003 X11, X Window System xwindows

Application TCP Ports Description NBAR Keyword


956467

Appendix A Reference InformationWhen to Enable cRTP

When to Enable cRTP ESE Lab testing of QoS features has revealed performance ceilings resulting from enabling recommended WAN QoS features. cRTP is the most CPU intensive QoS feature and should be used with caution on WAN aggregation routers that are serving a large number of remote sites. Specifically:

• The 7200VXR with NPE-400 can successfully compress and decompress 360 simultaneous RTP streams, with FRTS and LLQ engaged.

• The 7500 with VIP4-80 can compress and decompress between 240 and 300 simultaneous RTP streams, with FRTS and LLQ engaged.

Note These results are based on only transmitting voice and voice control traffic.

Tip For full details refer to the WAN Platform Performance Guide and the cRTP Scalability on Cisco WAN Aggregation Platform case-study (internal).

Likewise, there are performance impacts on remote-branch routers when cRTP is enabled, as shown in Figure A-1.

Figure A-1 cRTP Performance Impact on Remote Branch Routers

Tip For full details refer to the QoS Branch Performance Guide (internal).

8103

8

128K 256K

17512651364037254224

768K 2048K 4500K

Linkspeed

CU

PU

%

0

10

20

30

40

50

60

70

80

90


956467

Appendix A Reference InformationWeb Sites with Additional Information

Web Sites with Additional InformationThis section lists all of the web sites that are referenced throughout this document. Additional information related to AVVID QoS can be found at the sites listed below.

Cisco Public Documentation• Cisco IP Telephony Solution Reference Network Design Guide

http://www.cisco.com/warp/public/779/largeent/netpro/avvid/iptel_register.html

• IP Videoconferencing Solution Reference Network Design Guide

http://www.cisco.com/warp/public/779/largeent/netpro/avvid/ipvc_register.html

• Low Latency Queueing with Priority Percentage Support

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ftllqpct.htm

• Configuring Frame Relay Traffic Shaping

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_c/wcffrely.htm#xtocid27

• Configuring Distributed Traffic Shaping

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt4/qcfdts.htm

• Configuring ATM

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_c/wcfatm.htm

• IP Header Compression Enhancement—PPPoATM and PPPoFR Support

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122relnt/xprn122t/122tnewf.htm#xtocid274

• Configuring Frame Relay-ATM Interworking

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_c/wcffratm.htm

• Classification in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt1/index.htm

• Network-Based Application Recognition

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt1/qcfclass.htm#xtocid24

• Congestion Management in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2


• Congestion Avoidance in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2



956467


• Policing and Shaping in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2


• Link Efficiency Mechanisms in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2


• Configuring FRF.12 Fragmentation on Switched PVCs

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwan_c/wcffrely.htm#xtocid54

• Configuring Compressed Real-Time Protocol

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt6/qcfcrtp.htm

• Modular Quality of Service Command Line Interface in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2


• Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt8/qcfmcli2.htm#xtocid16

• IP Telephony QoS Design Guide

http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/

• Cisco Class-Based QoS Configuration and Statistics MIB

ftp://ftp.cisco.com/pub/mibs/v2/CISCO-CLASS-BASED-QOS-MIB.my

• Cisco Products Quick Reference Guide: February 2002

http://www.cisco.com/warp/public/752/qrg/cpqrg2.htm

Cisco Limited-Access Information• Field Notice: Limited QoS Functionality on the Gigabit Ethernet Ports on the Catalyst 6000

Supervisor

http://www-tac.cisco.com/Support_Library/field_alerts/fn19310.html

Cisco Internal Documentation To request a copy of any of the following documents, contact your Cisco Systems representative.

• Designing Small Scale Server Farms

http://wwwin/ent/ese/cani/data-center/design-guidance.shtml

• NBAR Performance White Paper

http://wwwin.cisco.com/cmc/cc/pd/iosw/ioft/ioqo/prodlit/nbrp_wi.htm


956467


• Multilink PPP Over Frame Relay & ATM White Paper

http://wwwin-eng.cisco.com/CA/GSOLE/Solutions/IP_Telephony/MLPoverFRandATMwhitepaper.doc

• VoIP Over ISDN White Paper

http://wwwin-eng.cisco.com/CA/GSOLE/Solutions/IP_Telephony/VoIPoverISDNWhitepaper.doc

• Cisco Alert: DLSw+ Marks Its Traffic with IP Precedence of 5

http://wwwin-eng.cisco.com/Eng/ESE/CANI/Design/HotTopic-DLSW-IPPREC5.doc

• WAN Platform Performance Guide and the cRTP Scalability on Cisco WAN Aggregation Platform case-study

http://wwwin.cisco.com/ent/ese/cani/wan/design-guidance.shtml

• QoS Branch Performance Guide

http://wwwin-eng.cisco.com/Eng/ESE/CANI/Implementation/Branch_Performance.doc

RFCs from the IETF• Assured Forwarding PHB Group (RFC)

http://www.ietf.org/rfc/rfc2597.txt

• An Expedited Forwarding PHB(RFC)


• RTP: A Transport Protocol for Real-Time Applications


Other External Sites• Port Numbers

http://www.iana.org/assignments/port-numbers


956467

Cisco AVVID Network Infrastr956467

I N D E X

A

access control list (ACL)

configuring

Catalyst 2950 3-40

Catalyst 3550 3-35, 3-59

Catalyst 4000 with Sup III 3-24, 3-53

for marking traffic 2-3

access-layer switch

Catalyst 2950 3-38

Catalyst 3524-PWR XL 3-31

Catalyst 3550 3-33

Catalyst 4000 with Sup II 3-29

Catalyst 4000 with Sup III 3-22

Catalyst 6500 3-15

criteria 3-14

ATM

fragment sizes 4-22

high-speed links 4-18

MLPoATM 4-23

slow-speed links 4-19

to Frame Relay recommendations 4-21

VC-bundling 4-20

B

bandwidth

in a campus network 3-1

in a SOHO network 5-5

ISDN 4-24

voice 1-4, 1-5

best-effort 1-10

burst rate

committed 4-12

excess 4-12

C

cable

one and two box solution 5-11

solution 5-10

third-party modem solution 5-13

call admission control (CAC)

limitations in ISDN 4-24

overview 1-26

CallManager, Cisco 2-2, 3-10, 3-11, 4-24

Catalyst 2950

as an access-layer switch 3-38

configuring ACLs 3-40

configuring IP phone support 3-40

configuring the uplink 3-41

modifying CoS-to-DSCP mappings 3-39

verifying configuration 3-41

Catalyst 3500 example 3-7

Catalyst 3524-PWR XL




Catalyst 3550

as a distribution switch 3-58


configuring ACLs 3-35, 3-59

configuring CoS or DSCP trust 3-60



IN-1ucture Enterprise Quality of Service

Index

enabling priority queuing 3-35, 3-59

enabling QoS 3-34, 3-59


verifying configuration 3-37, 3-61

Catalyst 4000

as a distribution switch 3-51


Sup II



enabling QoS 3-30

Sup III

configuring ACLs 3-24, 3-53

configuring CoS or DSCP trust 3-54


configuring service policy 3-54


enabling priority queuing 3-23, 3-53

enabling QoS 3-23, 3-52

modifying CoS-to-DSCP mappings 3-23, 3-52

verifying configuration 3-26, 3-55

Catalyst 4006 example 3-12

Catalyst 6500

as a distribution switch 3-42, 3-47


configuring IP phone port queuing 3-17


enabling QoS 3-17

example 3-10

linecards and queuing mechanisms A-2



with Cat OS

configuring the distribution layer 3-43

configuring the VoIP transmit queue 3-43


with Native IOS

configuring the distribution layer 3-48

configuring the VoIP transmit queue 3-48

IN-2Cisco AVVID Network Infrastructure Enterprise Quality of Service

enabling QoS 3-47


cell mode 6-2

class-based weighted-fair queueing (CBWFQ) 1-18

classes of data traffic 1-9

classification

data by a server farm switch 3-12

data recommendations for the LAN edge 4-30

data recommendations for the WAN 4-6

equivalents 1-14


in a WAN environment 4-2

non-marking applications 2-3

recommendations 1-15

tools 1-12

video recommendations for the LAN edge 4-29

video recommendations for the WAN 4-6

voice by a server farm switch 3-7

voice control by a server farm switch 3-10

voice recommendations for the LAN edge 4-28

voice recommendations for the WAN 4-4

class of service (CoS) 1-13

committed burst rate 4-12

committed information rate 4-11

committed information rate, minimum 4-13

compressed real-time protocol (cRTP) 1-25, 4-9, 4-10, 4-13, 4-16, 4-17, 4-20, 4-23, A-5

convergence, with MPLS 6-5

CoS trust, configuring

Catalyst 3550 3-60


customer edge (CE) router 6-2, 6-8

D

data

classes 1-9

classifiation by a server farm switch 3-12

classification recommendation 1-17

956467

Index

classifying on the LAN edge 4-30

classifying on the WAN edge 4-6

on multiple ISDN B channels 4-25

provisioning on the WAN edge 4-6

QoS requirements 1-7

delay

See also latency

overview 1-3

packetizatoin 1-3

propogation 1-3

serialization 1-3

delay variation

See also jitter

in LANs 3-2

overview 1-3

dial on demand routing (DDR) 4-25

differentiated service code points (DSCP) 1-13

differentiated service code points (DSCP) equivalents A-1

distributed-platform high-speed Frame Relay link 4-14

distributed-platform slow-speed Frame Relay link 4-17

distribution layer, configuring

Catalyst 6500 with Cat OS 3-43

Catalyst 6500 with Native IOS 3-48

distribution switch

Catalyst 3550 3-58




configuring uplink

Catalyst 2950 3-41


Catalyst 3550 3-36



Catalyst 6500 3-18

criteria 3-42

DLSW+ 2-4, A-4

DOCSIS 5-12

Cisco956467

DSCP trust, configuring

Catalyst 3550 3-60


DSL

one and two box solution 5-7

solution 5-6

third-party modem solution 5-9

E

excess burst rate 4-12

F

first-in first--out (FIFO) 1-19

fragment size

on ATM-to-Frame Relay link 4-22

on distributed slow-speed Frame Relay link 4-17

on slow-speed Frame Relay links 4-15

frame mode 6-2

Frame Relay 4-11

committed burst rate 4-12, 4-15

committed information rate 4-11, 4-15

distributed-platform high-speed links 4-14

distributed-platform slow-speed links 4-17

excess burst rate 4-12

fragment size on distributed slow-speed links 4-17

fragment size on slow-speed links 4-15

minimum committed information rate 4-13

MLP over Frame Relay 4-23


to ATM recommendations 4-21

FRF.12 4-3, 4-21

FRF.8 4-21

FRTS 4-11, 4-13

IN-3 AVVID Network Infrastructure Enterprise Quality of Service

Index

G

G.711 bandwidth requirements 1-5

H

H.323 gateways

Cisco 2-3

configuring communication 3-11

header compression 1-25

high-speed

Frame Relay

high-speed links 4-11

high-speed links

ATM 4-18

Frame Relay, distributed-platform 4-14

point-to-point 4-9

I

IDSL 5-14

IP phones, Cisco 2-2

IP phone support, configuring

Catalyst 2950 3-40


Catalyst 3550 3-36



Catalyst 6500 3-17

ISDN 5-15

bandwidth 4-24

data on multiple B channels 4-25

MLP LFI 4-24

voice on multiple B channels 4-25


J

jitter

See also delay variation

data requirements 1-7

overview 1-3

video requirements 1-6

voice requirements 1-3

L

label stack 6-3

latency

See also delay

data 1-7

overview 1-3

video 1-6


less-than-best-effort 1-10, 2-5

link-efficiency tools 1-23

link fragmentation and interleave (LFI)

FRF.12 4-3



MLP 4-3, 4-10, 4-19, 4-21

MLP in ISDN 4-24

overview 1-23

loss

data requirements 1-7

overview 1-2

video requirements 1-6


low-latency queueing (LLQ) 1-19

M

management tools 1-26

956467

Index

mappings

CoS-to-DSCP

modifying on a Catalyst 2950 3-39


modifying on a Catalyst 4000 with Sup III 3-23, 3-52


media gateway control protocol (MGCP) gateways

Cisco 2-3

configuring communication 3-11

mission critical application well-known ports A-3

MLP

in high-speed links 4-9

in slow-speed links 4-10

LFI 4-19, 4-21

LFI in ISDN 4-24

over ATM 4-23

over Frame Relay 4-23

MLPPP over ATM, fragment sizing 5-3

modular QoS CLI (MQC) 2-3, 4-4, 4-18

MPLS

convergence 6-5

labels 6-3

modes of operation 6-2

overview 6-1

redundancy 6-6

VPN

architecture 6-2

QoS 6-3

QoS considerations 6-5

QoS implementation 6-8

N

network-based application recognition (NBAM) 4-2

network-based application recognition (NBAR) 1-14

Cisco956467

P

packetization delay 1-3

per-hop behaviors (PHB) 1-14

point-to-point

high-speed link 4-9


policing


tools 1-23

PPP 4-10

priority queuing

enabling on a Catalyst 3550 3-35, 3-59

enabling on a Catalyst 4000 with Sup III 3-23, 3-53

propogation delay 1-3

provider core (P routers) 6-2, 6-13

provider edge (PE) router 6-2, 6-10

provisioning

data recommendations for the WAN 4-6



tools 1-22

video recommendations for the WAN 4-6

voice recommendations for the WAN 4-4

Q

QoS

enabling

Catalyst 3550 3-34, 3-59


Catalyst 4000 with Sup III 3-23, 3-52

Catalyst 6500 3-17


in the SOHO network 5-1

overview 1-1

requirements

data 1-7

service provider 1-11

IN-5 AVVID Network Infrastructure Enterprise Quality of Service

Index

video 1-6

voice 1-3

toolset 1-12

with MPLS VPN 6-3

queue

number of 1-22

scheduling 1-22

R

redundancy, with MPLS 6-6

reference information A-6

S

scheduling

in a campus network 3-5


queues 1-22

recommendations 1-22

tools 1-17

serialization delay 1-3

service policy, configuring


service provider QoS requirements 1-11

shaping



tools 1-23

show atm bundle 4-47

show atm pvc 4-48

show atm vc 4-47

show frame-relay pvc 4-43

show interface 4-42

show interface counters 3-26, 3-55

show mac 3-19

show mls qos interface 3-61

show mls qos interface queueing 3-37, 3-61


show mls qos maps 3-41, 3-61

show policy 4-34

show policy interface 4-36

show policy interface atm 4-47

show policy-map interface 3-26, 3-37, 3-55, 3-61

show port qos 3-19, 3-45, 3-55

show qos info runtime 3-19

show qos interface 3-26

show qos map cos 3-26, 3-37, 3-55

show qos map dscp 3-26

show qos map run cos-dscp-map 3-45

show qos map run ipprec-dscp-map 3-19, 3-45

show qos stat 3-19

show qos statistics l3 3-19

show queue 4-43

show wos map run cos-dscp-map 3-19

show wrr-queue band 3-41

signaling


skinny protocol 3-10

slow-speed links

ATM 4-19

Frame Relay 4-15

Frame Relay, distributed-platform 4-17

point-to-point 4-10

small office-home office (SOHO)

classification 5-2

overview 5-1

provisioning 5-3

scheduling 5-3

streaming video


requirements 1-6

T

transmit (TX)

buffer congestion 3-2

queue, configuring

956467

Index



ring 1-25, 4-3, 5-3

trust boundary 2-2

V

video




conferencing


requirements 1-7



streaming


requirements 1-6

virtual circuit (VC) bundling 4-20

voice

bandwidth 1-4, 1-5

classification by a server farm switch 3-7




control traffic classification by a server farm switch 3-10

gateways, Cisco 2-3

on multiple ISDN B channels 4-25

over ISDN 5-15



W

weighted-random early detect (WRED) 1-20

well-known ports of mission critical applications A-3

Cisco956467
IN-7
AVVID Network Infrastructure Enterprise Quality of Service

Index


956467

cisco avvid network infrastructure enterprise … avvid network...contents vi cisco avvid network...

Documents