Transcript
Enterprise QoS Solution Reference Network Design Guide
Version 3.3 November 2005
Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883
ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY 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 THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.
CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or website 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. (0812R) Enterprise QoS Solution Reference Network Design Guide Copyright © 2008, Cisco Systems, Inc. All rights reserved.
CONTENTS
Preface
xiii i-xiii
Revision History
Obtaining Documentation i-xiii Cisco.com i-xiv Documentation CD-ROM i-xiv Ordering Documentation i-xiv Documentation Feedback
i-xiv
Obtaining Technical Assistance i-xv Cisco.com i-xv Technical Assistance Center i-xv Cisco TAC Website i-xvi Cisco TAC Escalation Center i-xvi Obtaining Additional Publications and Information
1
i-xvi
CHAPTER
Quality of Service Design Overview
1-1
QoS Overview 1-1 What is QoS? 1-1 Why is QoS Important for Enterprise Networks? What is the Cisco QoS Toolset? 1-2 Classification and Marking Tools 1-3 Policing and Markdown Tools 1-5 Scheduling Tools 1-5 Link-Specific Tools 1-7 AutoQoS Tools 1-7 Call Admission Control Tools 1-9
1-2
How is QoS Optimally Deployed within the Enterprise? 1-10 1) Strategically Defining QoS Objectives 1-10 2) Analyzing Application Service-Level Requirements 1-12 QoS Requirements of VoIP 1-13 QoS Requirements of Video 1-16 QoS Requirements of Data Applications 1-18 QoS Requirements of the Control Plane 1-21 QoS Requirements of the Scavenger Class 1-22
Enterprise QoS Solution Reference Network Design Guide Version 3.3
iii
Contents
3) Designing the QoS Policies 1-23 Classification and Marking Principles 1-23 Policing and Markdown Principles 1-23 Queuing and Dropping Principles 1-24 4) Rolling out the QoS Policies 1-27 5) Monitoring the Service-Levels 1-27 How Can I Use QoS Tools to Mitigate DoS/Worm Attacks? 1-27 Scavenger-class QoS DoS/Worm Mitigation Strategy 1-31 Summary
1-31
References 1-33 Standards 1-33 Books 1-33 Cisco Documentation
2
1-33
CHAPTER
Campus QoS Design
2-1
QoS Design Overview 2-1 Where is QoS Needed in a Campus? 2-1 DoS/Worm Mitigation Strategies 2-4 Call Signaling Ports 2-5 Access Edge Trust Models 2-6 Trusted Endpoints 2-7 Untrusted Endpoints 2-8 Conditionally-Trusted Endpoints 2-10 AutoQoS—VoIP 2-13 Catalyst 2950—QoS Considerations and Design 2-17 Catalyst 2950—Trusted Endpoint Model 2-17 Configuration 2-17 Catalyst MLS QoS Verification Command 2-18 Catalyst 2950—AutoQoS VoIP Model 2-18 Catalyst 2950—Untrusted PC + SoftPhone with Scavenger-Class QoS Model 2-19 Catalyst 2950—Untrusted Server with Scavenger-Class QoS Model 2-20 Configuration 2-20 Catalyst MLS QoS Verification Commands 2-21 Catalyst 2950—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Configuration 2-23 Catalyst MLS QoS Verification Commands 2-23 Catalyst 2950—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model 2-25 Catalyst 2950—Queuing 2-25
2-23
Enterprise QoS Solution Reference Network Design Guide
iv
Version 3.3
Contents
Configuration 2-25 Catalyst MLS QoS Verification Commands
2-27
Catalyst 3550—QoS Considerations and Design 2-28 Catalyst 3550—Trusted Endpoint Model 2-30 Configuration 2-30 Catalyst MLS QoS Verification Commands 2-30 Catalyst 3550—AutoQoS VoIP Model 2-30 Catalyst 3550—Untrusted PC + SoftPhone with Scavenger-Class QoS Model 2-33 Configuration 2-33 Catalyst MLS QoS Verification Commands 2-33 Catalyst 3550—Untrusted Server with Scavenger-Class QoS Model 2-35 Configuration 2-35 Catalyst MLS QoS Verification Commands 2-36 Catalyst 3500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Configuration 2-36 Catalyst MLS QoS Verification Commands 2-38 Catalyst 3550—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model 2-38 Configuration 2-38 Catalyst MLS QoS Verification Commands 2-41 Catalyst 3550—Queuing and Dropping 2-41 Configuration 2-41 Advanced Tuning Options 2-42 Catalyst MLS QoS Verification Commands 2-44
2-36
Catalyst 2970/3560/3750—QoS Considerations and Design 2-45 Catalyst 2970/3560/3750—Trusted Endpoint Model 2-47 Configuration 2-47 Catalyst MLS QoS Verification Commands 2-47 Catalyst 2970/3560/3750—Auto QoS VoIP Model 2-47 Catalyst 2970/3560/3750—Untrusted PC + SoftPhone with Scavenger-Class QoS Model 2-50 Configuration 2-50 Catalyst MLS QoS Verification Commands 2-51 Catalyst 2970/3560/3750—Untrusted Server with Scavenger-Class QoS Model 2-51 Configuration 2-52 Catalyst MLS QoS Verification Commands 2-53 Catalyst 2970/3560/3750—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model 2-53 Configuration 2-53 Catalyst MLS QoS Verification Commands 2-54
Enterprise QoS Solution Reference Network Design Guide Version 3.3
v
Contents
Catalyst 2970/3560/3750—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model 2-55 Configuration 2-55 Catalyst MLS QoS Verification Commands 2-57 Catalyst 2970/3560/3750—Queuing and Dropping 2-57 Configuration 2-57 Catalyst MLS QoS Verification Commands 2-60 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design 2-62 Catalyst 4500—Trusted Endpoint Model 2-64 Configuration 2-64 Catalyst 4500 QoS Verification Commands 2-64 Catalyst 4500—Auto QoS VoIP Model 2-64 Catalyst 4500—Untrusted PC + SoftPhone with Scavenger-Class QoS Model 2-65 Configuration 2-66 Catalyst 4500 QoS Verification Commands 2-66 Catalyst 4500—Untrusted Server with Scavenger-Class QoS Model 2-67 Configuration 2-67 Catalyst 4500 QoS Verification Commands 2-68 Catalyst 4500 —Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Configuration 2-68 Catalyst 4500 QoS Verification Commands 2-70 Catalyst 4500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model 2-70 Configuration 2-70 Catalyst 4500 QoS Verification Commands 2-72 Catalyst 4500—Queuing 2-72 Configuration 2-72 Catalyst 4500 QoS Verification Commands 2-75 Catalyst 6500 PFC2/PFC3—QoS Considerations and Design 2-77 Catalyst 6500 QoS Configuration and Design Overview 2-77 Catalyst 6500—CatOS Defaults and Recommendations 2-79 Catalyst 6500—Trusted Endpoint Model 2-80 Configuration 2-80 Catalyst 6500 CatOS QoS Verification Commands 2-81 Catalyst 6500 Auto QoS VoIP Model 2-82 Catalyst 6500—Untrusted PC + SoftPhone with Scavenger-Class QoS Model Configuration 2-86 Catalyst 6500—Untrusted Server with Scavenger-Class QoS Model 2-91 Configuration 2-92 Catalyst 6500 CatOS QoS Verification Commands 2-93
Enterprise QoS Solution Reference Network Design Guide
2-68
2-86
vi
Version 3.3
Contents
Catalyst 6500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Configuration 2-94 Catalyst 6500 CatOS QoS Verification Commands 2-95 Catalyst 6500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model 2-95 Configuration 2-96 Catalyst 6500 CatOS QoS Verification Commands 2-98 Catalyst 6500—Queuing and Dropping 2-99 Catalyst 6500 Queuing and Dropping Overview 2-99 Catalyst 6500 Transmit Queuing and Dropping Linecard Options 2-99 Catalyst 6500—2Q2T Queuing and Dropping 2-102 Catalyst 6500—1P2Q1T Queuing and Dropping 2-107 Catalyst 6500—1P2Q2T Queuing and Dropping 2-109 Catalyst 6500—1P3Q1T Queuing and Dropping 2-112 Catalyst 6500—1P3Q8T Queuing and Dropping 2-114 Catalyst 6500—1P7Q8T Queuing and Dropping 2-117 Catalyst 6500—PFC3 Distribution-Layer (IOS) Per-User Microflow Policing 2-121 WAN Aggregator/Branch Router Handoff Considerations Summary
2-124 2-122
2-93
References 2-125 Standards 2-125 Books 2-125 Cisco Catalyst Documentation
3
2-125
CHAPTER
WAN Aggregator QoS Design
3-1 3-1
Where Is QoS Needed over the WAN?
WAN Edge QoS Design Considerations 3-2 Software QoS 3-2 Bandwidth Provisioning for Best-Effort Traffic 3-2 Bandwidth Provisioning for Real-Time Traffic 3-3 Serialization 3-3 IP RTP Header Compression 3-4 Tx-ring Tuning 3-4 PAK_priority 3-5 Link Speeds 3-5 Distributed Platform QoS and Consistent QoS Behavior WAN Edge Classification and Provisioning Models 3-6 Slow/Medium Link-Speed QoS Class Models 3-6 Three-Class (Voice and Data) Model 3-6
3-6
Enterprise QoS Solution Reference Network Design Guide Version 3.3
vii
Contents
Verification Command: show policy 3-8 High Link Speed QoS Class Models 3-10 Eight-Class Model 3-11 QoS Baseline (11-Class) Model 3-13 Distributed-Platform/Consistent QoS Behavior—QoS Baseline Model WAN Edge Link-Specific QoS Design 3-16 Leased Lines 3-16 Slow-Speed (£768 kbps) Leased Lines 3-17 Verification Command: show interface 3-18 Medium-Speed (£ T1/E1) Leased Lines 3-19 High-Speed (Multiple T1/E1 or Greater) Leased Lines 3-20 Verification Command: show policy interface (QoS Baseline Policy) Frame Relay 3-25 Committed Information Rate 3-25 Committed Burst Rate 3-26 Excess Burst Rate 3-26 Minimum Committed Information Rate 3-26 Slow-Speed (£ 768 kbps) Frame Relay Links 3-27 Medium-Speed (£ T1/E1) Frame Relay Links 3-28 High-Speed (Multiple T1/E1 and Greater) Frame Relay Links 3-29 Distributed Platform Frame Relay Links 3-31 ATM 3-32 Slow-Speed (£ 768 kbps) ATM Links: MLPoATM 3-33 Verification Command: show atm pvc 3-34 Slow-Speed (£ 768 kbps) ATM Links: ATM PVC Bundles 3-35 Verification Command: show atm bundle 3-37 Medium-Speed (£ T1/E1) ATM Links 3-37 High-Speed (Multiple T1/E1) ATM Links 3-38 Verification Command: show ima interface atm 3-39 Very-High-Speed (DS3-OC3+) ATM Links 3-39 ATM-to-Frame Relay Service Interworking 3-40 Slow-Speed (£ 768 kbps) ATM-FR SIW Links 3-42 ISDN 3-44 Variable Bandwidth 3-44 MLP Packet Reordering Considerations 3-44 CallManager CAC Limitations 3-45 Voice and Data on Multiple ISDN B Channels 3-45 Summary References
3-46 3-47
3-15
3-21
Enterprise QoS Solution Reference Network Design Guide
viii
Version 3.3
Contents
Standards 3-47 Books 3-47 Cisco Documentation
4
3-47
CHAPTER
Branch Router QoS Design
4-1
Branch WAN Edge QoS Design 4-2 AutoQoS—Enterprise 4-2 Unidirectional Applications 4-5 Branch Router WAN Edge (10-Class) QoS Baseline Model Branch Router LAN Edge QoS Design 4-7 DSCP-to-CoS Remapping 4-8 Branch-to-Campus Classification and Marking 4-9 Source or Destination IP Address Classification 4-10 Verification Command: show ip access-list 4-11 Well-Known TCP/UDP Port Classification 4-11 NBAR Application Classification 4-12 Verification Command: show ip nbar port-map 4-14 NBAR Known-Worm Classification and Policing 4-14 NBAR Versus Code Red 4-15 NBAR Versus NIMDA 4-16 NBAR Versus SQL Slammer 4-17 NBAR Versus RPC DCOM/W32/MS Blaster 4-18 NBAR Versus Sasser 4-19 NBAR Versus Future Worms 4-20 Policing Known Worms 4-20 Summary
4-22
4-6
References 4-22 Standards 4-22 Books 4-23 Cisco IOS Documentation Cisco SAFE‘ Whitepapers
5
4-23 4-23
CHAPTER
MPLS VPN QoS Design
5-1 5-2
Where Is QoS Needed over an MPLS VPN?
Customer Edge QoS Design Considerations 5-4 Layer 2 Access (Link-Specific) QoS Design 5-4 Service Provider Service-Level Agreements 5-5 Enterprise-to-Service Provider Mapping Models 5-6 Voice and Video 5-6
Enterprise QoS Solution Reference Network Design Guide Version 3.3
ix
Contents
Call-Signaling 5-7 Mixing TCP with UDP 5-7 Marking and Re-Marking 5-7 Three-Class Provider-Edge Model: CE Design 5-9 Four-Class Provider-Edge Model: CE Design 5-11 Five-Class Provider-Edge Model: CE Design 5-13 Provider-Edge QoS Considerations 5-15 Service Provider-to-Enterprise Models 5-15 Three-Class Provider-Edge Model: PE Design 5-16 Four-Class Provider-Edge Model: PE Design 5-16 Five-Class Provider-Edge Model: PE Design 5-17 MPLS DiffServ Tunneling Modes 5-18 Uniform Mode 5-18 Short Pipe Mode 5-21 Pipe Mode 5-24 Summary
5-31
References 5-31 Standards 5-31 Books 5-32 Cisco Documentation
6
5-32
CHAPTER
IPSec VPN QoS Design
6-1
Site-to-Site V3PN QoS Considerations 6-2 IPSec VPN Modes of Operation 6-3 IPSec Tunnel Mode (No IP GRE Tunnel) 6-3 IPSec Transport Mode with an Encrypted IP GRE Tunnel 6-4 IPSec Tunnel Mode with an Encrypted IP GRE Tunnel 6-4 Packet Overhead Increases 6-5 cRTP and IPSec Incompatibility 6-8 Prefragmentation 6-9 Bandwidth Provisioning 6-9 Logical Topologies 6-10 Delay Budget Increases 6-11 ToS Byte Preservation 6-12 QoS Pre-Classify 6-13 Pre-Encryption Queuing 6-14 Anti-Replay Implications 6-17 Control Plane Provisioning 6-19 Site-to-Site V3PN QoS Designs
Enterprise QoS Solution Reference Network Design Guide
6-20
x
Version 3.3
Contents
Six-Class Site-to-Site V3PN Model 6-20 Eight-Class Site-to-Site V3PN Model 6-21 QoS Baseline (11-Class) Site-to-Site V3PN Model Headend VPN Edge QoS Options for Site-to-Site V3PNs
6-23 6-25
Teleworker V3PN QoS Considerations 6-26 Teleworker Deployment Models 6-27 Integrated Unit Model 6-27 Dual-Unit Model 6-28 Integrated Unit + Access Model 6-28 Broadband-Access Technologies 6-30 Digital Subscriber Line 6-31 Cable 6-31 Bandwidth Provisioning 6-32 NAT Transparency Feature Overhead 6-32 DSL (AAL5 + PPPoE) Overhead 6-33 Cable Overhead 6-34 Asymmetric Links and Unidirectional QoS 6-34 Broadband Serialization Mitigation Through TCP Maximum Segment Size Tuning Split Tunneling 6-36 Teleworker V3PN QoS Designs 6-38 Integrated Unit/Dual-Unit Models—DSL Design 6-38 Integrated Unit + Access Model—DSL/Cable Designs 6-40 Summary
6-41
6-35
References 6-42 Standards 6-42 Books 6-43 Cisco IOS Documentation
6-43
Enterprise QoS Solution Reference Network Design Guide Version 3.3
xi
Contents
Enterprise QoS Solution Reference Network Design Guide
xii
Version 3.3
Preface
This document provides design considerations and guidelines for implementing Cisco Quality of Service within an enterprise environment. This document is the second major update to the design guidelines and information presented in the Cisco AVVID Network Infrastructure Enterprise Quality of Service Design Solutions Reference Network Design (August, 2002). This document assumes that you are already familiar with Quality of Service terms and concepts. If you want to review any of those terms and concepts, refer to Cisco Quality of Service documentation at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/qos_vcg.htm Alternatively, Quality of Service tools and concepts are presented in depth within the Cisco Press book End-to-End Quality of Service Network Design (ISBN: 1587051761).
Revision History
The following table lists the revision history for this document. Revision Date Comments
November 2005 Revision 3.3 with terminology change from “Business Ready” to “Enterprise.” October 2005 June 2005 The following section has been added:
•
IPSec VPN QoS Design—Chapter 6 AutoQoS—VoIP (Campus)—Chapter 2 AutoQoS—Enterprise (WAN)—Chapter 4 Technical corrections and edits
The following sections are new or have been added
• • •
April 2005
Initial Draft (QoS SRND 3.0)
Obtaining Documentation
Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
xiii
Preface Documentation Feedback
Cisco.com
You can access the most current Cisco documentation on the World Wide Web at this URL: http://www.cisco.com/univercd/home/home.htm You can access the Cisco website at this URL: http://www.cisco.com International Cisco web sites can be accessed from this URL: http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have 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. Registered Cisco.com users can order the Documentation CD-ROM (product number DOC-CONDOCCD=) through the online Subscription Store: http://www.cisco.com/go/subscription
Ordering Documentation
You can find instructions for ordering documentation at this URL: http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm You can order Cisco documentation in these ways:
•
Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace: http://www.cisco.com/en/US/partner/ordering/index.shtml Registered Cisco.com users can order the Documentation CD-ROM (Customer Order Number DOC-CONDOCCD=) 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 Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
•
•
Documentation Feedback
You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page. You can e-mail your comments to
[email protected]. You can submit your comments by mail by using the response card behind the front cover of your document or by writing to the following address:
Enterprise QoS Solution Reference Network Design Guide
xiv
Version 3.3
Preface Obtaining Technical Assistance
Cisco Systems Attn: Customer Document Ordering 170 West Tasman Drive San Jose, CA 95134-9883 We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com, which includes the Cisco Technical Assistance Center (TAC) Website, as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from the Cisco TAC website. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC website, including TAC tools and utilities.
Cisco.com
Cisco.com offers a suite of interactive, networked services that let you access Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world. Cisco.com provides a broad range of features and services to help you with these tasks:
• • • • •
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
To obtain customized information and service, you can self-register on Cisco.com at this URL: http://www.cisco.com
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two levels of support are available: the Cisco TAC website and the Cisco TAC Escalation Center. The avenue of support that you choose depends on the priority of the problem and the conditions stated in service contracts, when applicable. We categorize Cisco TAC inquiries according to urgency:
• • • •
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. 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.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
xv
Preface Obtaining Additional Publications and Information
Cisco TAC Website
You can use the Cisco TAC website 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 website, go to this URL: http://www.cisco.com/tac All customers, partners, and resellers who have a valid Cisco service contract have complete access to the technical support resources on the Cisco TAC website. Some services on the Cisco TAC website require 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 this URL to register: http://tools.cisco.com/RPF/register/register.do If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC website, you can open a case online at this URL: http://www.cisco.com/en/US/support/index.html If you have Internet access, we recommend that you open P3 and P4 cases through the Cisco TAC website so that you can describe the situation in your own words and attach any necessary files.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. 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 automatically opens a case. To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this 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). When you call the center, please have available your service agreement number and your product serial number.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•
The Cisco Product Catalog describes the networking products offered by Cisco Systems as well as ordering and customer support services. Access the Cisco Product Catalog at this URL: http://www.cisco.com/en/US/products/products_catalog_links_launch.html Cisco Press publishes a wide range of networking publications. Cisco suggests these titles for new and experienced users: Internetworking Terms and Acronyms Dictionary, Internetworking Technology Handbook, Internetworking Troubleshooting Guide, and the Internetworking Design Guide. For current Cisco Press titles and other information, go to Cisco Press online at this URL: http://www.ciscopress.com
•
Enterprise QoS Solution Reference Network Design Guide
xvi
Version 3.3
Preface Obtaining Additional Publications and Information
•
Packet magazine is the Cisco monthly periodical that provides industry professionals with the latest information about the field of networking. You can access Packet magazine at this URL: http://www.cisco.com/en/US/about/ac123/ac114/about_cisco_packet_magazine.html iQ Magazine is the Cisco monthly periodical that provides business leaders and decision makers with the latest information about the networking industry. You can access iQ Magazine at this URL: http://business.cisco.com/prod/tree.taf%3fasset_id=44699&public_view=true&kbns=1.html Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in the design, development, and operation of public and private internets and intranets. You can access the Internet Protocol Journal at this URL: http://www.cisco.com/en/US/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html Training-Cisco offers world-class networking training, with current offerings in network training listed at this URL: http://www.cisco.com/en/US/learning/le31/learning_recommended_training_list.html
•
•
•
Enterprise QoS Solution Reference Network Design Guide Version 3.3
xvii
Preface Obtaining Additional Publications and Information
Enterprise QoS Solution Reference Network Design Guide
xviii
Version 3.3
C H A P T E R
1
Quality of Service Design Overview
This document provides an overview of Quality of Service (QoS) tools and design and includes high-level answers to the following questions:
• • • •
Why is Quality of Service Important for Enterprise Networks? What is Cisco’s Quality of Service Toolset? How is QoS Optimally Deployed within an Enterprise? How can QoS Tools be used to Mitigate DoS/Worm Attacks?
QoS has already proven itself as the enabling technology for the convergence of voice, video and data networks. As business needs evolve, so do demands on QoS technologies. The need to protect voice, video and critical data via QoS mechanisms in an enterprise network has escalated over the past few years, primarily due to the increased frequency and sophistication of Denial of Service (DoS) and worm attacks. This document examines current QoS demands and requirements within the enterprise and presents strategic design recommendations to address these needs.
QoS Overview
This section answers the following questions:
• •
What is QoS? Why is QoS Important for Enterprise Networks?
What is QoS?
QoS is the measure of transmission quality and service availability of a network (or internetworks). Service availability is a crucial foundation element of QoS. The network infrastructure must be designed to be highly available before you can successfully implement QoS. The target for High Availability is 99.999 % uptime, with only five minutes of downtime permitted per year. The transmission quality of the network is determined by the following factors:
•
Loss—A relative measure of the number of packets that were not received compared to the total number of packets transmitted. Loss is typically a function of availability. If the network is Highly Available, then loss during periods of non-congestion would be essentially zero. During periods of congestion, however, QoS mechanisms can determine which packets are more suitable to be selectively dropped to alleviate the congestion.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-1
Chapter 1 What is the Cisco QoS Toolset?
Quality of Service Design Overview
•
Delay—The finite amount of time it takes a packet to reach the receiving endpoint after being transmitted from the sending endpoint. In the case of voice, this is the amount of time it takes for a sound to travel from the speaker’s mouth to a listener’s ear. Delay variation (Jitter)—The difference in the end-to-end delay between packets. For example, if one packet requires 100 ms to traverse the network from the source endpoint to the destination endpoint and the following packet requires 125 ms to make the same trip, then the delay variation is 25 ms.
•
Each end station in a Voice over IP (VoIP) or Video over IP conversation uses a jitter buffer to smooth out changes in the arrival times of voice data packets. Although jitter buffers are dynamic and adaptive, they may not be able to compensate for instantaneous changes in arrival times of packets. This can lead to jitter buffer over-runs and under-runs, both of which result in an audible degradation of call quality.
Why is QoS Important for Enterprise Networks?
A communications network forms the backbone of any successful organization. These networks transport a multitude of applications, including realtime voice, high-quality video and delay-sensitive data. Networks must provide predictable, measurable, and sometimes guaranteed services by managing bandwidth, delay, jitter and loss parameters on a network. QoS technologies refer to the set of tools and techniques to manage network resources and are considered the key enabling technology for network convergence. The objective of QoS technologies is to make voice, video and data convergence appear transparent to end users. QoS technologies allow different types of traffic to contend inequitably for network resources. Voice, video, and critical data applications may be granted priority or preferential services from network devices so that the quality of these strategic applications does not degrade to the point of being unusable. Therefore, QoS is a critical, intrinsic element for successful network convergence. QoS tools are not only useful in protecting desirable traffic, but also in providing deferential services to undesirable traffic such as the exponential propagation of worms. You can use QoS to monitor flows and provide first and second order reactions to abnormal flows indicative of such attacks, as will be discussed in additional detail later in this document.
What is the Cisco QoS Toolset?
This section describes the main categories of the Cisco QoS toolset and includes the following topics:
• • • • • •
Classification and Marking tools Policing and Markdown tools Scheduling tools Link-specific tools AutoQoS tools Call Admission Control tools
Cisco provides a complete toolset of QoS features and solutions for addressing the diverse needs of voice, video and multiple classes of data applications. Cisco QoS technology lets complex networks control and predictably service a variety of networked applications and traffic types. You can effectively control bandwidth, delay, jitter, and packet loss with these mechanisms. By ensuring the desired results,
Enterprise QoS Solution Reference Network Design Guide
1-2
Version 3.3
Chapter 1
Quality of Service Design Overview What is the Cisco QoS Toolset?
the QoS features lead to efficient, predictable services for business-critical applications. Using the rich Cisco QoS toolset, as shown in Figure 1-1, businesses can build networks that conform to the Differentiated Services (DiffServ) architecture, as defined in RFC 2475.
Figure 1-1 The Cisco QoS Toolset
Policing and Markdown STOP Admission Control Classification and Marking Scheduling (Queuing and Dropping) Traffic Shaping Link-Specific Mechanisms
Classification and Marking Tools
The first element to a QoS policy is to classify/identify the traffic that is to be treated differently. Following classification, marking tools can set an attribute of a frame or packet to a specific value. Such marking (or remarking) establishes a trust boundary that scheduling tools later depend on. Classification and marking tools set this trust boundary by examining any of the following:
• • • •
Layer 2 parameters—802.1Q Class of Service (CoS) bits, Multiprotocol Label Switching Experimental Values (MPLS EXP) Layer 3 parameters—IP Precedence (IPP), Differentiated Services Code Points (DSCP), IP Explicit Congestion Notification (ECN), source/destination IP address Layer 4 parameters— L4 protocol (TCP/UDP), source/destination ports Layer 7 parameters— application signatures via Network Based Application Recognition (NBAR)
NBAR is a Cisco proprietary technology that identifies application layer protocols by matching them against a Protocol Description Language Module (PDLM), which is essentially an application signature. The NBAR deep-packet classification engine examines the data payload of stateless protocols against PDLMs. There are over 98 PDLMs embedded into Cisco IOS software 12.3 code. Additionally, Cisco IOS software 12.3(4)T introduces the ability to define custom PDLMs which examine user-defined strings within packet payloads. PDLMs can be added to the system without requiring an IOS upgrade because they are modular. 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. You can only apply policies to traffic after it has been positively classified. To avoid the need for repetitive and detailed classification at every node, packets can be marked according to their service levels. An analogy: imagine that each individual in the postal system would have to open up each letter to determine the respective priority required and service it accordingly. Obviously it would be better to
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-3
119473
Chapter 1 What is the Cisco QoS Toolset?
Quality of Service Design Overview
have the first mail-clerk stamp something on the outside of the envelope to indicate the priority level that would be applied during each phase of processing and delivery. Similarly, marking tools can be used to indicate respective priority levels by setting attributes in the frame/packet headers so that detailed classification does not have to be recursively performed at each hop. Within an enterprise, marking is done at either Layer 2 or Layer 3, using the following fields:
•
802.1Q/p Class of Service (CoS)—Ethernet frames can be marked at Layer 2 with their relative importance by setting the 802.1p User Priority bits of the 802.1Q header. Only three bits are available for 802.1p marking. Therefore, only 8 classes of service (0-7) can be marked on Layer 2 Ethernet frames. IP Type of Service (ToS) byte—Layer 2 media often changes as packets traverse from source to destination, so a more ubiquitous classification occurs at Layer 3. The second byte in an IPv4 packet is the ToS byte. The first three bits of the ToS byte are the IPP bits. These first three bits combined with the next three bits are known collectively as the DSCP bits. The IP Precedence bits, like 802.1p CoS bits, allow for only the following 8 values of marking (0–7):
– IPP values 6 and 7 are generally reserved for network control traffic such as routing. – IPP value 5 is recommended for voice. – IPP value 4 is shared by videoconferencing and streaming video. – IPP value 3 is for voice control. – IPP values 1 and 2 can be used for data applications. – IPP value 0 is the default marking value.
•
Many enterprises find IPP marking to be overly restrictive and limiting, favoring instead the 6-Bit/64-value DSCP marking model.
•
DSCPs and Per-Hop Behaviors (PHBs)—DSCP values can be expressed in numeric form or by special standards-based names called Per-Hop Behaviors. There are four broad classes of DSCP PHB markings: Best Effort (BE or DSCP 0), RFC 2474 Class Selectors (CS1–CS7, which are identical/backwards-compatible to IPP values 1–7), RFC 2597 Assured Forwarding PHBs (AFxy), and RFC 3268 Expedited Forwarding (EF). There are four Assured Forwarding classes, each of which begins with the letters “AF” followed by two numbers. The first number corresponds to the DiffServ Class of the AF group and can range from 1 through 4. The second number refers to the level of Drop Preference within each AF class and can range from 1 (lowest Drop Preference) through 3 (highest Drop Preference). DSCP values can be expressed in decimal form or with their PHB keywords. For example, DSCP EF is synonymous with DSCP 46, and DSCP AF31 is synonymous with DSCP 26.
•
IP Explicit Congestion Notification (IP ECN)—IP ECN, as defined in RFC 3168, makes use of the last two bits of the IP ToS byte, which are not used by the 6-bit DSCP markings, as shown in Figure 1-2.
Enterprise QoS Solution Reference Network Design Guide
1-4
Version 3.3
Chapter 1
Quality of Service Design Overview What is the Cisco QoS Toolset?
Figure 1-2
The IP ToS Byte (DSCP and IP ECN)
Version Length
ToS Byte
Len
ID
Offset
TTL
Proto
FCS
IP SA
IP DA
Data
IPv4 Packet 7 6 5 4 3 2 1 0
IP Precedence
Unused IP ECN RFC 3168 IP ECN Bits
119474
DiffServ Code Point (DSCP) RFC 2474 DiffServ Extensions
These last two bits are used to indicate to TCP senders whether or not congestion was experienced during transit. In this way, TCP senders can adjust their TCP windows so that they do not send more traffic than the network can service. Previously, dropping packets was the only way that congestion feedback could be signaled to TCP senders. Using IP ECN, however, congestion notification can be signaled without dropping packets. The first IP ECN bit (7th in the ToS byte) is used to indicate whether the device supports IP ECN and the second bit (last bit in the IP ToS byte) is used to indicate whether congestion was experienced (0=“no congestion”; 1= “congestion was experienced”). IP ECN can be marked through a congestion avoidance mechanism such as weighted early random detection (WRED).
Policing and Markdown Tools
Policing tools (policers) determine whether packets are conforming to administratively-defined traffic rates and take action accordingly. Such action could include marking, remarking or dropping a packet. A basic policer monitors a single rate: traffic equal to or below the defined rate is considered to conform to the rate, while traffic above the defined rate is considered to exceed the rate. On the other hand, the algorithm of a dual-rate policer (such as described in RFC 2698) is analogous to a traffic light. Traffic equal to or below the principal defined rate (green light) is considered to conform to the rate. An allowance for moderate amounts of traffic above this principal rate is permitted (yellow light) and such traffic is considered to exceed the rate. However, a clearly-defined upper-limit of tolerance is set (red light), beyond which traffic is considered to violate the rate. Policers complement classification and marking policies. For example, as previously discussed, RFC 2597 defines the AF classes of PHBs. Traffic conforming to the defined rate of a given AF class is marked to the first Drop Preference level of a given AF class (for example, AF21). Traffic exceeding this rate is marked down to the second Drop Preference level (for example, AF22) and violating traffic is either marked down further to the third Drop Preference level (for example, AF23) or simply dropped.
Scheduling Tools
Scheduling tools determine how a frame/packet exits a device. Whenever packets enter a device faster than they can exit it, such as with speed mismatches, then a point of congestion, or 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.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-5
Chapter 1 What is the Cisco QoS Toolset?
Quality of Service Design Overview
Queueing algorithms are activated only when a device is experiencing congestion and are deactivated when the congestion clears. The main Cisco IOS software queuing tools are Low Latency Queueing (LLQ), which provides strict priority servicing and is intended for realtime applications such as VoIP; and Class-Based Weighted Fair Queuing (CBWFQ), which provides bandwidth guarantees to given classes of traffic and fairness to discrete traffic flows within these traffic classes. Figure 1-3 shows the Layer 3 and Layer 2 queuing subsystems of the Cisco IOS software LLQ/CBWFQ algorithm.
Figure 1-3 LLQ/CBWFQ Operation
Low Latency Queuing VoIP IP/VC Signaling Packets In Critical Bulk Management FQ CBWFQ PQ
Link Fragmentation and Interleave
Interleave
TX Ring
Packets Out
Fragment
Layer 3 Queuing Subsystem
Layer 2 Queuing Subsystem
Queueing buffers act like a funnel for water being poured into a small opening. If water enters the funnel faster than it exits, eventually the funnel overflows from the top. When queueing buffers begin overflowing from the top, 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 because 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 while congestion avoidance mechanisms manage the tail of the queue. Congestion avoidance mechanisms thus indirectly affect scheduling. The principle IOS congestion avoidance mechanism is WRED, which randomly drops packets as queues fill to capacity. However, the randomness of this selection can be skewed by traffic weights. The weight can either be IP Precedence values, as is the case with default WRED which drops lower IPP values more aggressively (for example, IPP 1 would be dropped more aggressively than IPP 6) or the weights can be AF Drop Preference values, as is the case with DSCP-Based WRED which drops higher AF Drop Preference values more aggressively (for example, AF23 is dropped more aggressively than AF22, which in turn is dropped more aggressively than AF21). WRED can also be used to set the IP ECN bits to indicate that congestion was experienced in transit.
Enterprise QoS Solution Reference Network Design Guide
1-6
Version 3.3
119475
Default
Chapter 1
Quality of Service Design Overview What is the Cisco QoS Toolset?
Link-Specific Tools
Link-specific tools include the following:
• •
Shaping tools—A shaper typically delays excess traffic above an administratively-defined rate using a buffer to hold packets and shape the flow when the data rate of the source is higher than expected. Link Fragmentation and Interleaving tools—With slow-speed WAN circuits, large data packets take an excessively long time to be placed onto the wire. This delay, called serialization delay, can easily cause a VoIP packet to exceed its delay and/or jitter threshold. There are two main tools to mitigate serialization delay on slow ( 768 kbps) links: Multilink PPP Link Fragmentation and Interleaving (MLP LFI) and Frame Relay Fragmentation (FRF.12). Compression tools—Compression techniques, such as compressed Real-Time Protocol (cRTP), minimize bandwidth requirements and are highly useful on slow links. At 40 bytes total, the header portion of a VoIP packet is relatively large and can account for nearly two-thirds or the entire VoIP packet (as in the case of G.729 VoIP). To avoid the unnecessary consumption of available bandwidth, you can use cRTP on a link-by-link basis. cRTP compresses IP/UDP/RTP headers from 40 bytes to between two and five bytes (which results in a bandwidth savings of approximately 66% for G.729 VoIP). Transmit ring (Tx-Ring) tuning—The Tx-Ring is a final interface First-In-First-Out (FIFO) queue that holds frames to be immediately transmitted by the physical interface. The Tx-Ring ensures that a frame is always available when the interface is ready to transmit traffic, so that link utilization is driven to 100 % of capacity. The size of the Tx-Ring is dependant on the hardware, software, Layer 2 media, and queueing algorithm configured on the interface. The Tx-Ring may have to be tuned on certain platforms/interfaces to prevent unnecessary delay/jitter introduced by this final FIFO queue.
•
•
AutoQoS Tools
The richness of the Cisco QoS toolset inevitably increases its deployment complexity. To address customer demand for simplification of QoS deployment, Cisco has developed the Automatic QoS (AutoQoS) features. AutoQoS is an intelligent macro that allows an administrator to enter one or two simple AutoQoS commands to enable all the appropriate features for the recommended QoS settings for an application on a specific interface. AutoQoS VoIP, the first release of AutoQoS, provides best-practice QoS designs for VoIP on Cisco Catalyst switches and Cisco IOS routers. By entering one global and/or one interface command, depending on the platform, the AutoQoS VoIP macro expands these commands into the recommended VoIP QoS configurations (complete with all the calculated parameters and settings) for the platform and interface on which the AutoQoS is being applied. For Campus Catalyst switches, AutoQoS automatically performs the following tasks:
• • • • • •
Enforces a trust boundary at Cisco IP Phones. Enforces a trust boundary on Catalyst switch access ports and uplinks/downlinks. Enables Catalyst strict priority queuing for voice and weighted round robin queuing for data traffic. Modifies queue admission criteria (CoS-to-queue mappings). Modifies queue sizes as well as queue weights where required. Modifies CoS-to-DSCP and IP Precedence-to-DSCP mappings.
For Cisco IOS routers, AutoQoS is supported on Frame Relay (FR), Asynchronous Transfer Mode (ATM), High-Level Data Link Control (HDLC), Point-to-Point Protocol (PPP), and FR-to-ATM links.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-7
Chapter 1 What is the Cisco QoS Toolset?
Quality of Service Design Overview
For Cisco IOS routers, AutoQoS automatically performs the following tasks:
•
Classifies and marks VoIP bearer traffic (to DSCP EF) and Call-Signaling traffic (to DSCP CS3).
– Applies scheduling: – Low Latency Queuing (LLQ) for voice – Class-Based Weighted Fair Queuing (CBWFQ) for Call-Signaling – Fair Queuing (FQ) for all other traffic
• • • •
Enables Frame Relay Traffic Shaping (FRTS) with optimal parameters, if required. Enables Link Fragmentation and Interleaving (LFI), either MLP LFI or FRF.12, on slow ( 768 kbps) links, if required. Enables IP RTP header compression (cRTP), if required. Provides Remote Monitoring (RMON) alerts of dropped VoIP packets.
AutoQoS VoIP became available on Cisco IOS router platforms in 12.2(15)T. In its second release, for Cisco IOS routers only, AutoQoS Enterprise detects and provisions for up to ten classes of traffic, including the following: • Voice
• • • • • • • • •
Interactive-Video Streaming-Video Call-Signaling Transactional Data Bulk Data Routing Network Management Best Effort Scavenger
These classes will be explained in more detail later in this document. The AutoQoS Enterprise feature consists of two configuration phases, completed in the following order:
• •
Auto Discovery (data collection)—Uses NBAR-based protocol discovery to detect the applications on the network and performs statistical analysis on the network traffic. AutoQoS template generation and installation—Generates templates from the data collected during the Auto Discovery phase and installs the templates on the interface. These templates are then used as the basis for creating the class maps and policy maps for your network. After the class maps and policy maps are created, they are then installed on the interface.
AutoQoS Enterprise became available on Cisco routers in Cisco IOS 12.3(7)T. Some may naturally then ask: Why should I read the separate QoS design document when I have AutoQoS? While it is true that AutoQoS-VoIP is an excellent tool for customers with the objective of enabling QoS for VoIP (only) on their Campus and WAN infrastructures, and AutoQoS-Enterprise is a fine tool for enabling basic Branch-router WAN-Edge QoS for voice, video and multiple classes of data. For customers that have such basic QoS needs and don’t have the time or desire to learn or do more with QoS, AutoQoS is definitely the way to go.
Enterprise QoS Solution Reference Network Design Guide
1-8
Version 3.3
Chapter 1
Quality of Service Design Overview What is the Cisco QoS Toolset?
However, it is important to remember where AutoQoS came from. AutoQoS tools are the result of Cisco QoS feature development coupled with Cisco QoS Design Guides based on large-scale lab-testing. AutoQoS VoIP is the product of the first QoS Design Guide, one of the most popular/downloaded technical white papers ever produced within Cisco. AutoQoS Enterprise is the result of the strategic QoS Baseline (discussed later in this document) coupled with the second generation QoS Design Guide. These latest QoS design documents represents the third-generation QoS Design Guide, which is essentially a proposed blueprint for the next version of AutoQoS. Figure 1-4 shows the relationship between Cisco QoS features, Design Guides, and AutoQoS.
Figure 1-4 Cisco QoS Feature, Design Guide and AutoQoS Evolution
Advanced Data QoS Features (Advanced Campus Policers)
QoS Design Guide v3 (Voice, Video, Data + DoS/Worm Mitigation)
QoS Baseline Data QoS Features (NBAR, DSCP-WRED) QoS Design Guide v2 (Voice, Video, Data) AutoQoS-Enterprise (WAN Only)
Call Admission Control Tools
After performing the calculations to provision the network with the required bandwidth to support voice, video and data applications, you must ensure that voice or video do not oversubscribe the portion of the bandwidth allocated to them. While most DiffServ QoS features are used to protect voice from data, Call Admission Control (CAC) tools are used to protect voice from voice and video from video. CAC tools fall into the following three main categories:
•
Local—Local CAC mechanisms are a voice gateway router function, typically deployed on the outgoing gateway. The CAC decision is based on nodal information such as the state of the outgoing LAN/WAN link that the voice call traverses if allowed to proceed. Local mechanisms include configuration items to disallow more than a fixed number of calls. If the network designer already knows that no more than five VoIP calls will fit across the outgoing WAN link’s LLQ configuration because of bandwidth limitations, then it would be recommended to configure the local gateway node to not allow more than five simultaneous calls.
•
Measurement-based—Measurement-based CAC techniques look ahead into the packet network to gauge the state of the network to determine whether or not to allow a new call. This usually implies sending probes to the destination IP address, which could be the terminating gateway or endpoint, or another device in between.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
119476
VoIP QoS Features (LLQ, LFI)
QoS Design Guide v1 (VoIP Only)
AutoQoS VoIP (Campus + WAN)
1-9
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
The probes return to the outgoing gateway or endpoint information on the conditions found while traversing the network to the destination. Typically, loss and delay characteristics are the interesting elements of information for voice CAC decisions. The outgoing device then uses this information in combination with configured information to decide if the network conditions exceed a given or configured threshold.
•
Resource-based—There are two types of resource-based mechanisms: those that calculate resources needed and/or available, and those that reserve resources for the call. Resources of interest include link bandwidth, DSPs and DS0 timeslots on the connecting TDM trunks to a voice gateway, CPU power and memory. Several of these resources could be constrained at one or more nodes that the call traverses to its destination.
Cisco CallManager has additional CAC features to handle management of VoIP network deployments. These features are not mutually exclusive to the features listed above. While CallManager Location-Based CAC is deployed in the overall network to manage VoIP bandwidth availability for both Cisco IP Phones and voice gateways, local measurement-based or resource-based features may be deployed at the same time on the voice gateway to push back calls into the private Branch exchange (PBX) or publicly-switched telephone network (PSTN) if IP network conditions do not allow their entry into the VoIP network.
Note
A detailed discussion of CAC configuration is beyond the scope of this document, but CAC configuration is crucial for a successful VoIP deployment. For additional information on CallManager CAC, refer to the IP Telephony Solution Reference Network Design Guide at http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides_list .html.
How is QoS Optimally Deployed within the Enterprise?
A successful QoS deployment is comprised of multiple phases, including:
1. 2. 3. 4. 5.
Strategically defining the business objectives to be achieved via QoS. Analyzing the service-level requirements of the various traffic classes to be provisioned for. Designing and testing QoS policies prior to production-network rollout. Rolling out the tested QoS designs to the production network. Monitoring service levels to ensure that the QoS objectives are being met.
These phases may need to be repeated as business conditions change and evolve. Each of these phases will be addressed in more detail in the following sections.
1) Strategically Defining QoS Objectives
QoS technologies are the enablers for business/organizational objectives. Therefore, the way to begin a QoS deployment is not to activate QoS features simply because they exist, but to start by clearly defining the objectives of the organization. For example, among the first questions that arise during a QoS deployment are: How many traffic classes should be provisioned for? And what should they be? To help answer these fundamental questions, organizational objectives need to be defined, such as:
• •
Is the objective to enable VoIP only or video also required? If so, is video-conferencing required or streaming video? Or both?
Enterprise QoS Solution Reference Network Design Guide
1-10
Version 3.3
Chapter 1
Quality of Service Design Overview How is QoS Optimally Deployed within the Enterprise?
• •
Are there applications that are considered mission-critical, and if so, what are they? Does the organization wish to squelch certain types of traffic, and if so, what are they?
To help address these crucial questions and to simplify QoS, Cisco has adopted a new initiative called the “QoS Baseline.” The QoS Baseline is a strategic document designed to unify QoS within Cisco, from enterprise to service provider and from engineering to marketing. The QoS Baseline was written by Cisco's most qualified QoS experts, who have developed or contributed to the related IETF RFC standards (as well as other technology standards) and are thus eminently qualified to interpret these standards. The QoS Baseline also provides uniform, standards-based recommendations to help ensure that QoS designs and deployments are unified and consistent. The QoS Baseline defines up to 11 classes of traffic that may be viewed as critical to a given enterprise. A summary these classes and their respective standards-based marking recommendations are presented in Table 1-1.
Table 1-1 Cisco QoS Baseline/Technical Marketing (Interim) Classification and Marking Recommendations
Application
Layer 3 Classification
Layer 2 CoS/MPLS EXP
IPP IP Routing Voice Interactive Video Streaming-Video Locally-Defined Mission-Critical Data (see note below) Call-Signaling (see note below) Transactional Data Network Management Bulk Data Scavenger Best Effort 6 5 4 4 3 CS6 EF
PHB 48 46 34 32 25
DSCP 6 5 4 4 3
AF41 CS4 —
3 2 2 1 1 0
AF31/CS3 AF21 CS2 AF11 CS1 0
26/24 18 16 10 8 0
3 2 2 1 1 0
Note
The QoS Baseline recommends marking Call-Signaling to CS3. However, currently most Cisco IP Telephony products mark Call-Signaling to AF31. A marking migration from AF31 to CS3 is under way within Cisco, but in the interim it is recommended that both AF31 and CS3 be reserved for Call-Signaling and that Locally-Defined Mission-Critical Data applications be marked to a temporary placeholder non-standard DSCP, such as 25. Upon completion of the migration, the QoS Baseline marking recommendations of CS3 for Call-Signaling and AF31 for Locally-Defined Mission-Critical Data applications should be used. These marking recommendations are more in line with RFC 2474 and RFC 2597.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-11
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
Enterprises do not need to deploy all 11 classes of the QoS Baseline model. This model is intended to be a forward-looking guide that considers as many classes of traffic with unique QoS requirements as possible. Familiarity with this model can assist in the smooth expansion of QoS policies to support additional applications as future requirements arise. However, at the time of QoS deployment, the enterprise needs to clearly define their organizational objectives, which will correspondingly determine how many traffic classes will be required. This consideration should be tempered with the determination of how many application classes the networking administration team feels comfortable with deploying and supporting. Platform-specific constraints or service-provider constraints may also affect the number of classes of service. At this point you should also consider a migration strategy to allow the number of classes to be smoothly expanded as future needs arise, as shown in Figure 1-5.
Figure 1-5 Example Strategy for Expanding the Number of Classes of Service over Time
4/5 Class Model
8 Class Model Voice
QoS Baseline Model Voice Interactive-Video Streaming Video
Realtime
Video Call Signaling Network Control
Call Signaling
Call Signaling IP Routing Network Management
Critical Data Critical Data
Mission-Critical Data Transactional Data Bulk Data Bulk Data Best Effort Scavenger
119481
Best Effort
Best Effort Scavenger Time
Scavenger
Always seek executive endorsement of the QoS objectives prior to design and deployment. QoS is a system of managed unfairness and as such almost always bears political and organizational repercussions when implemented. To minimize the effects of these non-technical obstacles to deployment, address these political and organizational issues as early as possible, garnishing executive endorsement whenever possible. A strategic standards-based guide like the QoS Baseline coupled with a working knowledge of QoS tools and syntax is a prerequisite for any successful QoS deployment. However, you must also understand the service-level requirements of the various applications requiring preferential or deferential treatment within the network.
2) Analyzing Application Service-Level Requirements
The following sections present an overview of the QoS requirements for voice, video and multiple classes of data, including the following topics:
Enterprise QoS Solution Reference Network Design Guide
1-12
Version 3.3
Chapter 1
Quality of Service Design Overview How is QoS Optimally Deployed within the Enterprise?
• • • • •
QoS Requirements of VoIP QoS Requirements of Video QoS Requirements of Data Applications QoS Requirements of the Control Plane QoS Requirements of the Scavenger Class
QoS Requirements of VoIP
This section includes the following topics:
• •
Voice (Bearer Traffic) Call-Signaling Traffic
VoIP deployments require provisioning explicit priority servicing for VoIP (bearer stream) traffic and a guaranteed bandwidth service for Call-Signaling traffic. These related classes will be examined separately.
Voice (Bearer Traffic)
A summary of the key QoS requirements and recommendations for Voice (bearer traffic) are:
• • • • •
Voice traffic should be marked to DSCP EF per the QoS Baseline and RFC 3246. Loss should be no more than 1 %. One-way Latency (mouth-to-ear) should be no more than 150 ms. Average one-way Jitter should be targeted under 30 ms. 21–320 kbps of guaranteed priority bandwidth is required per call (depending on the sampling rate, VoIP codec and Layer 2 media overhead).
Voice quality is directly affected by all three QoS quality factors: loss, latency and jitter. Loss causes voice clipping and skips. The packetization interval determines the size of samples contained within a single packet. Assuming a 20 ms (default) packetization interval, the loss of two or more consecutive packets results in a noticeable degradation of voice quality. VoIP networks are typically designed for very close to zero percent VoIP packet loss, with the only actual packet loss being due to L2 bit errors or network failures. Excessive latency can cause voice quality degradation. The goal commonly used in designing networks to support VoIP is the target specified by ITU standard G.114, which states that 150 ms of one-way, end-to-end (mouth-to-ear) delay ensures user satisfaction for telephony applications. A design should apportion this budget to the various components of network delay (propagation delay through the backbone, scheduling delay due to congestion, and the access link serialization delay) and service delay (due to VoIP gateway codec and de-jitter buffer). If the end-to-end voice delay becomes too long, the conversation begins to sound like two parties talking over a satellite link or even a CB radio. While the ITU G.114 states that a 150 ms one-way (mouth-to-ear) delay budget is acceptable for high voice quality, lab testing has shown that there is a negligible difference in voice quality Mean Opinion Scores (MOS) using networks built with 200 ms delay budgets. Cisco thus recommends designing to the ITU standard of 150 ms, but if constraints exist where this delay target cannot be met, then the delay boundary can be extended to 200 ms without significant impact on voice quality.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-13
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
Note
Higher delays may also be viewed as acceptable to certain organizations, but the corresponding reduction in VoIP quality must be taken into account when making such design decisions. Jitter buffers (also known as play-out buffers) are used to change asynchronous packet arrivals into a synchronous stream by turning variable network delays into constant delays at the destination end systems. The role of the jitter buffer is to balance the delay and the probability of interrupted playout due to late packets. Late or out-of-order packets are discarded. If the jitter buffer is set either arbitrarily large or arbitrarily small, then it imposes unnecessary constraints on the characteristics of the network. A jitter buffer set too large adds to the end-to-end delay, meaning that less delay budget is available for the network such that the network needs to support a delay target tighter than practically necessary. If a jitter buffer is too small to accommodate the network jitter, then buffer underflows or overflows can occur. An underflow is when the buffer is empty when the codec needs to play out a sample. An overflow is when the jitter buffer is already full and another packet arrives that cannot therefore be enqueued in the jitter buffer. Both jitter buffer underflows and overflows cause packets to be discarded. Adaptive jitter buffers aim to overcome these issues by dynamically tuning the jitter buffer size to the lowest acceptable value. Well-designed adaptive jitter buffer algorithms should not impose any unnecessary constraints on the network design by: Instantly increasing the jitter buffer size to the current measured jitter value following a jitter buffer overflow. Slowly decreasing the jitter buffer size when the measured jitter is less that the current jitter buffer size. Using a Programmable Logic Controller (PLC) to interpolate for the loss of a packet on a jitter buffer underflow. Where such adaptive jitter buffers are used, we can in theory engineer out explicit considerations of jitter by accounting for worst-case per hop delays. Advanced formulas can be used to arrive at network-specific design recommendations for jitter based on maximum and minimum per-hop delays. Alternatively, this 30 ms value can be used as a jitter target as extensive lab testing has shown that when jitter consistently exceeds 30 ms voice quality degrades significantly. Because of its strict service-level requirements, VoIP is well suited to the Expedited Forwarding Per-Hop Behavior, as defined in RFC 3246 (formerly RFC 2598). It should therefore be marked to DSCP EF (46) and assigned strict priority servicing at each node, regardless of whether such servicing is done in hardware (as in Catalyst switches via hardware priority queuing) or in software (as in Cisco IOS routers via LLQ). The bandwidth consumed by VoIP streams (in bps) is calculated by adding the VoIP sample payload (in bytes) to the 40-byte IP/UDP/RTP headers (assuming that cRTP is not in use), multiplying this value by 8 (to convert it to bits) and then multiplying again by the packetization rate (default of 50 packets per second). Table 1-2 details the bandwidth per VoIP flow at a default packet rate of 50 packets per second (pps). This does not include Layer 2 overhead and does not take into account any possible compression schemes, such as cRTP.
Table 1-2 Voice Bandwidth (without Layer 2 Overhead)
Bandwidth Consumption G.711
Sampling Rate 20 ms
Voice Payload in Bytes 160
Packets per Second 50
Bandwidth per Conversation 80 kbps
Enterprise QoS Solution Reference Network Design Guide
1-14
Version 3.3
Chapter 1
Quality of Service Design Overview How is QoS Optimally Deployed within the Enterprise?
Table 1-2
Voice Bandwidth (without Layer 2 Overhead)
G.711 G.729A G.729A
30 ms 20 ms 30 ms
240 20 30
33 50 33
74 kbps 24 kbps 19 kbps
Note
The Service Parameters menu in Cisco CallManager Administration can be used to adjust the packet rate. It is possible to configure the sampling rate above 30 ms, but this usually results in poor voice quality. A more accurate method for provisioning VoIP is to include the Layer 2 overhead, which includes preambles, headers, flags, cyclic redundancy checks (CRCs), and ATM cell-padding. The amount of overhead per VoIP call depends on the Layer 2 technology used:
• • • • •
802.1Q Ethernet adds (up to) 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 4 bytes of Layer 2 overhead; Frame Relay with FRF.12 adds 8 bytes. ATM adds varying amounts of overhead, depending on the cell padding requirements.
Table 1-3 shows a more accurate bandwidth provisioning example for voice because it includes Layer 2 overhead.
Table 1-3 Voice Bandwidth (Including Layer 2 Overhead)
Bandwidth Consumption G.711 at 50 pps G.711 at 33 pps G.729A at 50 pps G.729A at 33 pps
802.1Q Ethernet 93 kbps 83 kbps 37 kbps 27 kbps
PPP 84 kbps 77 kbps 28 kbps 21 kbps
MLP 86 kbps 78 kbps 30 kbps 22 kbps
Frame-Relay w/FRF.12 84 kbps 77 kbps 28 kbps 21 kbps
ATM 106 kbps 84 kbps 43 kbps 28 kbps
Note
A handy tool for quickly and accurately calculating VoIP bandwidth requirements (factoring in the codec, the use of cRTP and L2 overhead) can be found at: http://tools.cisco.com/Support/VBC/jsp/Codec_Calc1.jsp
Call-Signaling Traffic
The following are key QoS requirements and recommendations for Call-Signaling traffic:
• •
Call-Signaling traffic should be marked as DSCP CS3 per the QoS Baseline (during migration, it may also be marked the legacy value of DSCP AF31). 150 bps (plus Layer 2 overhead) per phone of guaranteed bandwidth is required for voice control traffic; more may be required, depending on the call signaling protocol(s) in use.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-15
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
Call-Signaling traffic was originally marked by Cisco IP Telephony equipment to DSCP AF31. However, the Assured Forwarding classes, as defined in RFC 2597, were intended for flows that could be subject to markdown and – subsequently – the aggressive dropping of marked-down values. Marking down and aggressively dropping Call-Signaling could result in noticeable delay-to-dial-tone (DDT) and lengthy call setup times, both of which generally translate to poor user experiences. The QoS Baseline changed the marking recommendation for Call-Signaling traffic to DSCP CS3 because Class Selector code points, as defined in RFC 2474, were not subject to markdown/aggressive dropping. Some Cisco IP Telephony products have already begun transitioning to DSCP CS3 for Call-Signaling marking. In this interim period, both code-points (CS3 and AF31) should be reserved for Call-Signaling marking until the transition is complete.
•
Many Cisco IP phones use Skinny Call-Control Protocol (SCCP) for call signaling. SCCP is a relatively lightweight protocol that requires only a minimal amount of bandwidth protection. However, newer versions of CallManager and SCCP have improved functionality requiring new message sets yielding a higher bandwidth consumption. Cisco signaling bandwidth design recommendations have been adjusted to match. The IPT SRND’s Network Infrastructure chapter contains the relevant details, available at: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guides _list.html. Other call signaling protocols include (but are not limited to) H.323, H.225, Session Initiated Protocol (SIP) and Media Gateway Control Protocol (MGCP). Each call signaling protocol has unique TCP/UDP ports and traffic patterns that should be taken into account when provisioning QoS policies for them.
•
QoS Requirements of Video
This section describes the two main types of video traffic, and includes the following topics:
• •
Interactive Video Streaming Video
Interactive Video
When provisioning for Interactive Video (IP Videoconferencing) traffic, the following guidelines are recommended:
• • • • •
Interactive Video traffic should be marked to DSCP AF41; excess Interactive-Video traffic can be marked down by a policer to AF42 or AF43. Loss should be no more than 1 %. One-way Latency should be no more than 150 ms. Jitter should be no more than 30 ms. Overprovision Interactive Video queues by 20% to accommodate bursts
Because IP Videoconferencing (IP/VC) includes a G.711 audio codec for voice, it has the same loss, delay, and delay variation requirements as voice, but the traffic patterns of videoconferencing are radically different from voice. For example, videoconferencing traffic has varying packet sizes and extremely variable packet rates, as shown in Figure 1-6.
Enterprise QoS Solution Reference Network Design Guide
1-16
Version 3.3
Chapter 1
Quality of Service Design Overview How is QoS Optimally Deployed within the Enterprise?
Figure 1-6
IP Videoconferencing Traffic Rates and Packet Sizes
“I” Frame 1024–1518 Bytes
“I” Frame 1024–1518 Bytes
30pps “P” and “B” Frames 128–256 Bytes 15pps
The videoconferencing rate is the sampling rate of the video stream, not the actual bandwidth the video call requires. In other words, the data payload of videoconferencing packets is filled with 384 kbps worth of video and voice samples. IP, UDP, and RTP headers (40 bytes per packet, uncompressed) need to be included in IP/VC bandwidth provisioning, as does the Layer 2 overhead of the media in use. Because (unlike VoIP) IP/VC packet sizes and rates vary, the header overhead percentage will vary as well, so an absolute value of overhead cannot be accurately calculated for all streams. Testing, however, has shown a conservative rule of thumb for IP/VC bandwidth provisioning is to overprovision the guaranteed/priority bandwidth by 20 percent. For example, a 384 kbps IP/VC stream would be adequately provisioned with an LLQ/CBWFQ of 460 kbps.
Note
The Cisco LLQ algorithm has been implemented to include a default burst parameter equivalent to 200 ms worth of traffic. Testing has shown that this burst parameter does not require additional tuning for a single IP Videoconferencing (IP/VC) stream. For multiple streams, this burst parameter may be increased as required.
Streaming Video
When addressing the QoS needs of Streaming Video traffic, the following guidelines are recommended:
• • • • • •
Streaming Video (whether unicast or multicast) should be marked to DSCP CS4 as designated by the QoS Baseline. Loss should be no more than 5 %. Latency should be no more than 4–5 seconds (depending on video application buffering capabilities). There are no significant jitter requirements. Guaranteed bandwidth (CBWFQ) requirements depend on the encoding format and rate of the video stream. Streaming video is typically unidirectional and, therefore, Branch routers may not require provisioning for Streaming Video traffic on their WAN/VPN edges (in the direction of Branch-to-Campus).
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-17
119477
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
•
Non-organizational Streaming Video applications, such as entertainment videos, may be marked as Scavenger (DSCP CS1) and assigned a minimal bandwidth (CBWFQ) percentage. For more information, see Scavenger-class QoS DoS/Worm Mitigation Strategy.
Streaming Video applications have more lenient QoS requirements because they are delay-insensitive (the video can take several seconds to cue-up) and are largely jitter-insensitive (due to application buffering). However, Streaming Video may contain valuable content, such as e-learning applications or multicast company meetings, and therefore may require service guarantees. The QoS Baseline recommendation for Streaming Video marking is DSCP CS4. An interesting consideration with respect to Streaming Video comes into play when designing WAN/VPN edge policies on Branch routers: because Streaming Video is generally unidirectional, a separate class would likely not be needed for this traffic class in the Branch-to-Campus direction of traffic flow. Non-organizational video content (or video that is strictly entertainment-oriented in nature such as movies, music videos, humorous commercials, and so on) might be considered for a (“less-than-Best-Effort”) Scavenger service. This means that these streams play if bandwidth exists, but they are the first to be dropped during periods of congestion.
QoS Requirements of Data Applications
This section includes the following topics:
• • • •
Best Effort Data Bulk Data Transactional/Interactive Data Locally-Defined Mission-Critical Data
There are hundreds of thousands of data networking applications. Some are TCP, others are UDP; some are delay sensitive, others are not; some are bursty in nature, others are steady; some are lightweight, others require high bandwidth, and so on. Not only do applications vary one from another, but even the same application can vary significantly in one version to another. Given this, how best to provision QoS for data is a daunting question. The Cisco QoS Baseline identifies four main classes of data traffic, according to their general networking characteristics and requirements. These classes are Best Effort, Bulk Data, Transactional/Interactive Data and Locally-Defined Mission-Critical Data.
Best Effort Data
The Best Effort class is the default class for all data traffic. An application will be removed from the default class only if it has been selected for preferential or deferential treatment. When addressing the QoS needs of Best Effort data traffic, Cisco recommends the following guidelines:
• •
Best Effort traffic should be marked to DSCP 0. Adequate bandwidth should be assigned to the Best Effort class as a whole, because the majority of applications will default to this class; reserve at least 25 percent for Best Effort traffic.
In 2003, a Wall Street financial company did an extensive study to identify and categorize the number of different applications on their networks. They found over 3000 discrete applications traversing their infrastructure. Further research has shown that this is not uncommon for larger enterprises.
Enterprise QoS Solution Reference Network Design Guide
1-18
Version 3.3
Chapter 1
Quality of Service Design Overview How is QoS Optimally Deployed within the Enterprise?
Because enterprises have several hundred, if not thousands, of data applications running over their networks (of which, the majority will default to the Best Effort class), you need to provision adequate bandwidth for the default class as a whole, to handle the sheer volume of applications that will be included in it. Otherwise, applications defaulting to this class will be easily drowned out, which typically results in an increased number of calls to the networking help desk from frustrated users. Cisco therefore recommends that you reserve at least 25 percent of link bandwidth for the default Best Effort class.
Bulk Data
The Bulk Data class is intended for applications that are relatively non-interactive and drop-insensitive and that typically span their operations over a long period of time as background occurrences. Such applications include the following:
• • • • • •
FTP E-mail Backup operations Database synchronizing or replicating operations Content distribution Any other type of background operation Bulk Data traffic should be marked to DSCP AF11; excess Bulk Data traffic can be marked down by a policer to AF12; violating bulk data traffic may be marked down further to AF13 (or dropped). Bulk Data traffic should have a moderate bandwidth guarantee, but should be constrained from dominating a link.
When addressing the QoS needs of Bulk Data traffic, Cisco recommends the following guidelines:
• •
The advantage of provisioning moderate bandwidth guarantees to Bulk Data applications rather than applying policers to them is that Bulk applications can dynamically take advantage of unused bandwidth and thus speed up their operations during non-peak periods. This in turn reduces the likelihood of their bleeding into busy periods and absorbing inordinate amounts of bandwidth for their time-insensitive operations.
Transactional/Interactive Data
The Transactional/Interactive Data class, also referred to simply as Transactional Data, is a combination to two similar types of applications: Transactional Data client-server applications and Interactive Messaging applications. The response time requirement separates Transactional Data client-server applications from generic client-server applications. For example, with Transactional Data client-server applications such as SAP, PeopleSoft, and Data Link Switching (DLSw+), the transaction is a foreground operation; the user waits for the operation to complete before proceeding. E-mail is not considered a Transactional Data client-server application, as most e-mail operations occur in the background and users do not usually notice even several hundred millisecond delays in mailspool operations. When addressing the QoS needs of Transactional Data traffic, Cisco recommends the following guidelines:
•
Transactional Data traffic should be marked to DSCP AF21; excess Transactional Data traffic can be marked down by a policer to AF22; violating Transactional Data traffic can be marked down further to AF23 (or dropped).
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-19
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
•
Transactional Data traffic should have an adequate bandwidth guarantee for the interactive, foreground operations they support.
Locally-Defined Mission-Critical Data
The Locally-Defined Mission-Critical Data class is probably the most misunderstood class specified in the QoS Baseline. Under the QoS Baseline model, all traffic classes (with the exclusion of Scavenger and Best Effort) are considered critical to the enterprise. The term “locally-defined” is used to underscore the purpose of this class, which is to provide each enterprise with a premium class of service for a select subset of their Transactional Data applications that have the highest business priority for them. For example, an enterprise may have properly provisioned Oracle, SAP, BEA, and DLSw+ within their Transactional Data class. However, the majority of their revenue may come from SAP, and therefore they may want to give this Transactional Data application an even higher level of preference by assigning it to a dedicated class such as the Locally-Defined Mission-Critical Data class. Because the admission criteria for this class is non-technical (being determined by business relevance and organizational objectives), the decision of which applications should be assigned to this special class can easily become an organizationally- and politically-charged debate. Cisco recommends that you assign as few applications to this class from the Transactional Data class as possible. You should also obtain executive endorsement for application assignments to the Locally-Defined Mission-Critical Data class, because the potential for QoS deployment derailment exists without such an endorsement. For the sake of simplicity, this class will be referred to simply as Mission-Critical Data. When addressing the QoS needs of Mission-Critical Data traffic, Cisco recommends the following guidelines:
•
Mission-Critical Data traffic should be marked to DSCP AF31; excess mission-critical data traffic can then be marked down by a policer to AF32 or AF33. However, DSCP AF31 is currently being used by Cisco IP Telephony equipment as Call-Signaling, so until all Cisco IPT products mark Call-Signaling to DSCP CS3, a temporary placeholder code point (DSCP 25) can be used to identify Mission-Critical Data traffic. Mission-Critical Data traffic should have an adequate bandwidth guarantee for the interactive, foreground operations they support.
•
Table 1-4 shows some applications and the generic networking characteristics that determine for which data application class they are best suited.
Table 1-4 Data Applications by Class
Application Class Interactive
Example Applications Telnet, Citrix, Oracle Thin-Clients AOL Instant Messenger Yahoo Instant Messenger PlaceWare (Conference) Netmeeting Whiteboard
Application/Traffic Properties Highly-interactive applications with tight user feedback requirements.
Packet / Message Sizes Average message size < 100 B Max message size < 1 KB
Enterprise QoS Solution Reference Network Design Guide
1-20
Version 3.3
Chapter 1
Quality of Service Design Overview How is QoS Optimally Deployed within the Enterprise?
Table 1-4
Data Applications by Class
Transactional SAP, PeopleSoft (Vantive) Oracle—financials, Internet procurement, B2B, supply chain management, and application server Oracle 8i Database Ariba Buyer I2, Siebel, E.piphany Broadvision IBM Bus 2 Bus Microsoft SQL BEA Systems DLSw+ Bulk Database syncs Network-based backups Lotus Notes, Microsoft Outlook E-mail download (SMTP, POP3, IMAP, Exchange) Video content distribution, Large ftp file transfers Best-Effort All non-critical traffic HTTP Web browsing + other miscellaneous traffic
Transactional applications typically use a client-server protocol model. User initiated client-based queries followed by server response. Query response may consist of many messages between client and server. Query response may consist of many TCP and FTP sessions running simultaneously (for example, HTTP based applications)
Depends on application—could be anywhere from 1 KB to 50 MB
Long file transfers Always invokes TCP congestion management
Average message size 64 KB or greater
QoS Requirements of the Control Plane
This section includes the following topics:
• •
IP Routing Network Management
Unless the network is up and running, QoS is irrelevant. Therefore, it is critical to provision QoS for control plane traffic, which includes IP Routing traffic and Network Management.
IP Routing
By default, Cisco IOS software (in accordance with RFC 791 and RFC 2474) marks Interior Gateway Protocol (IGP) traffic such as Routing Information Protocol (RIP/RIPv2), Open Shortest Path First (OSPF), and Enhanced Interior Gateway Routing Protocol (EIGRP) to DSCP CS6. However, Cisco IOS software also has an internal mechanism for granting internal priority to important control datagrams as they are processed within the router. This mechanism is called PAK_PRIORITY.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-21
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
As datagrams are processed though the router and down to the interfaces, they are internally encapsulated with a small packet header, referred to as the PAKTYPE structure. Within the fields of this internal header there is a PAK_PRIORITY flag that indicates the relative importance of control packets to the internal processing systems of the router. PAK_PRIORITY designation is a critical internal Cisco IOS software operation and, as such, is not administratively configurable in any way. Note that Exterior Gateway Protocol (EGP) traffic such as Border Gateway Protocol (BGP) traffic is marked by default to DSCP CS6 but does not receive such PAK_PRIORITY preferential treatment and may need to be explicitly protected in order to maintain peering sessions. When addressing the QoS needs of IP Routing traffic, Cisco recommends the following guidelines:
• •
IP Routing traffic should be marked to DSCP CS6; this is default behavior on Cisco IOS platforms. IGPs are usually adequately protected with the Cisco IOS internal PAK_Priority mechanism; Cisco recommends that EGPs such as BGP have an explicit class for IP routing with a minimal bandwidth guarantee. Cisco IOS automatically marks IP Routing traffic to DSCP CS6.
•
Additional information on PAK_PRIORITY can be found at: http://www.cisco.com/warp/public/105/rtgupdates.html
Network Management
When addressing the QoS needs of Network Management traffic, Cisco recommends the following guidelines:
• •
Network Management traffic should be marked to DSCP CS2. Network Management applications should be explicitly protected with a minimal bandwidth guarantee.
Network management traffic is important to perform trend and capacity analysis and troubleshooting. Therefore, you can provision a separate minimal bandwidth queue for Network Management traffic, which could include SNMP, NTP, Syslog, NFS and other management applications.
QoS Requirements of the Scavenger Class
The Scavenger class, based on an Internet-II draft, is intended to provide deferential services, or “less-than-Best-Effort” services, to certain applications. Applications assigned to this class have little or no contribution to the organizational objectives of the enterprise and are typically entertainment-oriented. These include: Peer-to-Peer (P2P) media-sharing applications (such as KaZaa, Morpheus, Grokster, Napster, iMesh, and so on), gaming applications (Doom, Quake, Unreal Tournament, and so on), and any entertainment video applications. Assigning a minimal bandwidth queue to Scavenger traffic forces it to be squelched to virtually nothing during periods of congestion, but allows it to be available if bandwidth is not being used for business purposes, such as might occur during off-peak hours. This allows for a flexible, non-stringent policy control of non-business applications. When provisioning for Scavenger traffic, Cisco recommends the following guidelines:
• •
Scavenger traffic should be marked to DSCP CS1. Scavenger traffic should be assigned the lowest configurable queuing service; for instance, in Cisco IOS this would mean assigning a CBWFQ of 1 % to Scavenger.
The Scavenger class is a critical component to the DoS/worm mitigation strategy presented later in this document.
Enterprise QoS Solution Reference Network Design Guide
1-22
Version 3.3
Chapter 1
Quality of Service Design Overview How is QoS Optimally Deployed within the Enterprise?
3) Designing the QoS Policies
Once a QoS strategy has been defined and the application requirements are understood, end-to-end QoS policies can be designed for each device and interface, as determined by its role in the network infrastructure. A separate QoS design document delves into the specific details of LAN, WAN, and VPN (both MPLS and IPSec VPN) QoS designs. Because the Cisco QoS toolset provides many QoS design and deployment options, a few succinct design principles can help simplify strategic QoS deployments. For example, one such design principle is to always enable QoS policies in hardware— rather than software—whenever a choice exists. Cisco IOS routers perform QoS in software, which places incremental loads on the CPU, depending on the complexity and functionality of the policy. Cisco Catalyst switches, on the other hand, perform QoS in dedicated hardware ASICS and as such do not tax their main CPUs to administer QoS policies. This allows complex policies to be applied at line rates at even Gigabit or Ten-Gigabit speeds. Other simplifying best-practice QoS design principles include:
• • •
Classification and Marking Principles Policing and Markdown Principles Queueing and Dropping Principles
Classification and Marking Principles
When classifying and marking traffic, an unofficial Differentiated Services design principle is to classify and mark applications as close to their sources as technically and administratively feasible. This principle promotes end-to-end Differentiated Services and PHBs. Do not trust markings that can be set by users on their PCs or other similar devices, because users can easily abuse provisioned QoS policies if permitted to mark their own traffic. For example, if DSCP EF received priority services throughout the enterprise, a PC can be easily configured to mark all the traffic of the user to DSCP EF, thus hijacking network priority queues to service non-realtime traffic. Such abuse could easily ruin the service quality of realtime applications like VoIP throughout the enterprise. Following this rule, it is further recommended to use DSCP markings whenever possible, because these are end-to-end, more granular and more extensible than Layer 2 markings. Layer 2 markings are lost when media changes (such as a LAN-to-WAN/VPN edge). There is also less marking granularity at Layer 2. For example, 802.1Q/p CoS supports only 3 bits (values 0–7), as does MPLS EXP. Therefore, only up to 8 classes of traffic can be supported at Layer 2, and inter-class relative priority (such as RFC 2597 Assured Forwarding Drop Preference markdown) is not supported. On the other hand, Layer 3 DSCP markings allow for up to 64 classes of traffic, which is more than enough for most enterprise requirements for the foreseeable future. As the line between enterprises and service providers continues to blur and the need for interoperability and complementary QoS markings is critical, you should follow standards-based DSCP PHB markings to ensure interoperability and future expansion. Because the QoS Baseline marking recommendations are standards-based, enterprises can easily adopt these markings to interface with service provider classes of service. Network mergers—whether the result of acquisitions, mergers or strategic-alliances—are also easier to manage when you use standards-based DSCP markings.
Policing and Markdown Principles
There is little reason to forward unwanted traffic only to police and drop it at a subsequent node, especially when the unwanted traffic is the result of DoS or worm attacks. The overwhelming volume of traffic that such attacks can create can cause network outages by driving network device processors to their maximum levels. Therefore, you should police traffic flows as close to their sources as possible.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-23
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
This principle applies also to legitimate flows. DoS/worm-generated traffic can masquerade under legitimate, well-known TCP/UDP ports and cause extreme amounts of traffic to be poured onto the network infrastructure. Such excesses should be monitored at the source and marked down appropriately. Whenever supported, markdown should be done according to standards-based rules, such as RFC 2597 (“Assured Forwarding PHB Group”). For example, excess traffic marked to AFx1 should be marked down to AFx2 (or AFx3, whenever dual-rate policing—such as defined in RFC 2698—is supported). Following such markdowns, congestion management policies, such as DSCP-based WRED, should be configured to drop AFx3 more aggressively than AFx2, which in turn should be dropped more aggressively than AFx1. However, Cisco Catalyst switches do not currently perform DSCP-Based WRED, and so this standards-based strategy cannot be implemented fully at this time. As an alternative workaround, single-rate policers can be configured to markdown excess traffic to DSCP CS1 (Scavenger); dual-rate policers can be configured to mark down excess traffic to AFx2, while marking down violating traffic to DSCP CS1. Traffic marked as Scavenger would then be assigned to a “less-than-Best-Effort” queue. Such workarounds yield an overall effect similar to the standards-based policing model. However, when DSCP-based WRED is supported on all routing and switching platforms, then you should mark down Assured Forwarding classes by RFC 2597 rules to comply more closely with this standard.
Queuing and Dropping Principles
Critical applications such as VoIP require service guarantees regardless of network conditions. The only way to provide service guarantees is to enable queuing at any node that has the potential for congestion, regardless of how rarely this may occur. This principle applies not only to Campus-to-WAN/VPN edges, where speed mismatches are most pronounced, but also to Campus Access-to-Distribution or Distribution-to-Core links, where oversubscription ratios create the potential for congestion. There is simply no other way to guarantee service levels than by enabling queuing wherever a speed mismatch exists. When provisioning queuing, some best practice rules of thumb also apply. For example, as discussed previously, the Best Effort class is the default class for all data traffic. Only if an application has been selected for preferential/deferential treatment is it removed from the default class. Because many enterprises have several hundred, if not thousands, of data applications running over their networks, you must provision adequate bandwidth for this class as a whole to handle the sheer volume of applications that default to it. Therefore, it is recommended that you reserve at least 25 percent of link bandwidth for the default Best Effort class. Not only does the Best Effort class of traffic require special bandwidth provisioning consideration, so does the highest class of traffic, sometimes referred to as the “Realtime” or “Strict Priority” class (which corresponds to RFC 3246 “An Expedited Forwarding Per-Hop Behavior”). The amount of bandwidth assigned to the Realtime queuing class is variable. However, if you assign too much traffic for strict priority queuing, then the overall effect is a dampening of QoS functionality for non-realtime applications. Remember: the goal of convergence is to enable voice, video, and data to transparently co-exist on a single network. When Realtime applications such as Voice or Interactive-Video dominate a link (especially a WAN/VPN link), then data applications will fluctuate significantly in their response times, destroying the transparency of the converged network. Cisco Technical Marketing testing has shown a significant decrease in data application response times when realtime traffic exceeds one-third of link bandwidth capacity. Extensive testing and customer deployments have shown that a general best queuing practice is to limit the amount of strict priority queuing to 33 percent of link capacity. This strict priority queuing rule is a conservative and safe design ratio for merging realtime applications with data applications.
Enterprise QoS Solution Reference Network Design Guide
1-24
Version 3.3
Chapter 1
Quality of Service Design Overview How is QoS Optimally Deployed within the Enterprise?
Cisco IOS software allows the abstraction (and thus configuration) of multiple strict priority LLQs. In such a multiple LLQ context, this design principle would apply to the sum of all LLQs to be within one-third of link capacity.
Note
This strict priority queuing rule (limit to 33 percent) is simply a best practice design recommendation and is not a mandate. There may be cases where specific business objectives cannot be met while holding to this recommendation. In such cases, enterprises must provision according to their detailed requirements and constraints. However, it is important to recognize the tradeoffs involved with over-provisioning strict priority traffic and its negative performance impact on non-realtime-application response times. Whenever a Scavenger queuing class is enabled, it should be assigned a minimal amount of bandwidth. On some platforms, queuing distinctions between Bulk Data and Scavenger traffic flows cannot be made because queuing assignments are determined by CoS values and these applications share the same CoS value of 1. In such cases you can assign the Scavenger/Bulk queuing class a bandwidth percentage of 5. If you can uniquely assign Scavenger and Bulk Data to different queues, then you should assign the Scavenger queue a bandwidth percentage of 1. The Realtime, Best Effort and Scavenger queuing best practice principles are shown in Figure 1-7.
Figure 1-7 Realtime, Best Effort and Scavenger Queuing Rules
Best Effort > 25% Realtime < 33%
Scavenger/Bulk < 5%
Critical Data
Because platforms support a variety of queuing structures, configure consistent queuing policies according to platform capabilities to ensure consistent PHBs. For example, on a platform that only supports four queues with CoS-based admission (such as a Catalyst switch) a basic queuing policy could be as follows:
• • • •
Realtime (33%) Critical Data Best Effort Data (25%) Scavenger/Bulk (5%)
Enterprise QoS Solution Reference Network Design Guide Version 3.3
119482
1-25
Chapter 1 How is QoS Optimally Deployed within the Enterprise?
Quality of Service Design Overview
The queuing policies can be expanded on a platform that supports a full 11-class QoS Baseline queuing model in such a way as to provide consistent servicing to Realtime, Best Effort and Scavenger traffic. For example, on a platform such as a Cisco IOS router that supports 11 queues with DSCP-based admission, an advanced queuing policy could be as follows:
• • • • • • • • • • •
Voice (18%) Interactive Video (15%) Internetwork-Control Call-Signaling Mission-Critical Data Transactional Data Network Management Streaming Video Best Effort Data (25%) Bulk Data (4%) Scavenger (1%)
The inter-relationship between these compatible queuing models is shown in Figure 1-8.
Figure 1-8 Compatible Four-Class and Eleven-Class Queuing Models following Realtime, Best Effort and Scavenger Queuing Rules
Voice 18% Best Effort 25%
Best Effort > 25% Realtime < 33% Interactive- Video 15%
Scavenger 1% Bulk 4%
Scavenger/ Bulk < 5%
Critical Data Streaming-Video Internetwork-Control
Call-Signaling Network Management Transactional Data Mission-Critical Data
119483
Enterprise QoS Solution Reference Network Design Guide
1-26
Version 3.3
Chapter 1
Quality of Service Design Overview How Can I Use QoS Tools to Mitigate DoS/Worm Attacks?
In this way, traffic receives compatible queuing at each node, regardless of platform capabilities, which is the overall objective of DiffServ PHB definitions. Whenever supported, you should enable WRED (preferably DSCP-based WRED) on all TCP flows. WRED congestion avoidance prevents TCP global synchronization and increases overall throughput and link efficiency. Enabling WRED on UDP flows is optional. These and other architecture-specific QoS design best-practices are discussed in more detail in a separate QoS design document, along with the configuration examples. Furthermore, it is highly-recommended to schedule Proof-of-Concept (PoC) tests to verify that the hardware/software platforms in production support the required QoS features in combination with all the other features they are currently running. Remember, in theory, theory and practice are the same. In other words, there is no substitute for testing.
4) Rolling out the QoS Policies
Once the QoS designs have been finalized and PoC tested, it is vital to ensure that the networking team thoroughly understand the QoS features and syntax before enabling features on production networks. Such knowledge is critical for both rollout and subsequent troubleshooting of QoS-related issues. Furthermore, it is recommended to schedule network downtime in order to rollout QoS features. While QoS is required end-to-end, it does not have to be deployed end-to-end at a single instance. A pilot network-segment can be selected for an initial deployment, and pending observation, the rollout can be expanded in stages to encompass the entire enterprise. A rollback strategy is always recommended, to address unexpected issues arising from the QoS deployment.
5) Monitoring the Service-Levels
Implementing a QoS solution is not a one-time task that is complete upon policy deployment. A successful QoS policy rollout is followed by ongoing monitoring of service levels and periodic adjustments and tuning of QoS policies. Short-term monitoring is useful for verifying that the deployed QoS policies are having the desired end-to-end effect. Long-term monitoring (trending) is needed to determine whether the provisioned bandwidth is still adequate for the changing needs of the enterprise. 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 objectives or economic climates themselves may change, and periodically the overall ranking of priority of applications may need revision. As business conditions change, the enterprise may need to adapt to these changes and may be required to begin the QoS deployment cycle anew, by redefining their objectives, tuning and testing corresponding designs, rolling these new designs out and monitoring them to see if they match the redefined objectives.
How Can I Use QoS Tools to Mitigate DoS/Worm Attacks?
Whenever the business objectives of the enterprise includes mitigating DoS/worm attacks, the Scavenger-class QoS strategy and best practices described in this section apply.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-27
Chapter 1 How Can I Use QoS Tools to Mitigate DoS/Worm Attacks?
Quality of Service Design Overview
Worms have existed in one form or another since the beginning of the Internet, and have steadily increased in complexity and scope of damage, as shown in Figure 1-9.
Figure 1-9 Business Security Threat Evolution
Global Impact Regional Networks Multiple Networks
Next Gen 3rd Gen
Multi-Server, DoS, DDoS, Blended Threat (Worm+ Virus+ Trojan), Turbo Worms, Widespread System Hacking Infrastructure Hacking, Flash Threats, Massive Worm Driven DDoS Negative payload Viruses, Worms and Trojans
2nd Gen
Individual Networks Individual Computer Macro Viruses, Trojans, Email, Single Server DoS, Limited Targeted Hacking
1st Gen
Boot Viruses
1980’s
1990’s
Today
Future
Sophistication of Threats
There has been an exponential increase since 2001 in not only the frequency of DoS/worm attacks, but also in their relative sophistication. For example, more than 994 new Win32 viruses and worms were documented in the first half of 2003, more than double the 445 documented in the first half of 2002. Some of these more recent worms are shown in Figure 1-10.
Figure 1-10
sadmind/IIS
Recent Internet Worms
Code Red NIMDA Apache/ mod_ssl MS-SQL Slammer W32/Blaster W32/MyDoom W32/Sobig W32/Bagel Sasser
May 2001
May 2001
Sept 2001
July 2002
Jan 2003
Aug 2003
Jan 2004
April 29 2004
119479
There are two main classes of DoS attacks:
• •
Spoofing attacks—The attacker pretends to provide a legitimate service, but provides false information to the requester (if any). Slamming/flooding attacks—The attacker exponentially generates and propagates traffic until service resources (servers and/or network infrastructure) are overwhelmed.
Spoofing attacks are best addressed by authentication and encryption technologies. Slamming/flooding attacks, on the other hand, can be effectively mitigated through QoS technologies.
Enterprise QoS Solution Reference Network Design Guide
1-28
119478
Version 3.3
Chapter 1
Quality of Service Design Overview How Can I Use QoS Tools to Mitigate DoS/Worm Attacks?
Worms, on the other hand, exploit security vulnerabilities in their targets and disguisedly carry harmful payloads that usually include a self-propagating mechanism. Network infrastructure usually isn’t the direct target of a worm attack, but can become collateral damage as worms exponentially self-propagate. The rapidly multiplying volume of traffic flows eventually drowns the CPU/hardware resources of routers and switches in their paths, indirectly causing Denial of Service to legitimate traffic flows, as shown in Figure 1-11.
Figure 1-11 Direct and Indirect Collateral Damage from DoS/Worm Attacks
Access
Distribution Core System under attack
Routers overloaded
119480
End systems overload High CPU Applications impacted
Network links overload High packet loss Mission critical Applications impacted
High CPU Instability Loss of management
A reactive approach to mitigating such attacks is to reverse-engineer the worm and set up intrusion detection mechanisms and/or ACLs and/or NBAR policies to limit its propagation. However, the increased sophistication and complexity of worms make them harder and harder to separate from legitimate traffic flows. This exacerbates the finite time lag between when a worm begins to propagate and when the following can take place: Sufficient analysis has been performed to understand how the worm operates and what its network characteristics are. An appropriate patch, plug or ACL is disseminated to network devices that may be in the path of worm; this task may be hampered by the attack itself, as network devices may become unreachable for administration during the attacks. These time lags may not seem long in absolute terms, such as in minutes, but the relative window of opportunity for damage is huge. For example, in 2003, the number of hosts infected with the Slammer worm (a Sapphire worm variant) doubled every 8.5 seconds on average, infecting over 75,000 hosts in just 11 minutes and performing scans of 55 million more hosts within the same time period.
Note
Interestingly, a 2002 CSI/FBI report stated that the majority of network attacks occur from within an organization, typically by disgruntled employees. This underscores the need to protect the Access-Edges of enterprise networks as well as their Internet edges. A proactive approach to mitigating DoS/worm flooding attacks within enterprise networks is to immediately respond to out-of-profile network behavior indicative of a DoS or worm attack using Campus Access-Layer policers. Such policers meter traffic rates received from endpoint devices and markdown excess traffic spikes to the Scavenger class (DSCP CS1) when these exceed specified watermarks (at which point they are no longer considered normal flows).
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-29
Chapter 1 How Can I Use QoS Tools to Mitigate DoS/Worm Attacks?
Quality of Service Design Overview
In this respect, the policers are relatively dumb. They do not match specific network characteristics of specific types of attacks, but simply meter traffic volumes and respond to abnormally high volumes as close to the source as possible. The simplicity of this approach negates the need for the policers to be programmed with knowledge of the specific details of how the attack is being generated or propagated. It is precisely this dumbness of such access layer policers that allow them to maintain relevancy as worms mutate and become more complex. The policers do not care how the traffic was generated or what it looks like, they care only how much traffic is being put onto the wire. Therefore, they continue to police even advanced worms that continually change the tactics of how traffic is being generated. For example, in most enterprises it is quite abnormal (within a 95 % statistical confidence interval) for PCs to generate sustained traffic in excess of 5 % of link capacity. In the case of a FastEthernet switch port, this means that it would be unusual in most organizations for an end-user PC to generate more than 5 Mbps of uplink traffic on a sustained basis.
Note
It is important to recognize that this value ( 5 percent) for normal Access-Edge utilization by endpoints is just an example value. This value would likely vary within the enterprise and from enterprise to enterprise. It is very important to recognize that what is being proposed is not to police all traffic to 5 Mbps and automatically drop the excess. Should that be the case, there would not be much reason to deploy FastEthernet or GigabitEthernet switch ports to endpoint devices, because even 10-BaseT Ethernet switch ports have more uplink capacity than a 5 Mbps policer-enforced limit. Furthermore, such an approach would supremely penalize legitimate traffic that did happen to exceed 5 Mbps on an FE switch port. A less draconian approach would be to couple Access Layer policers with hardware/software (Campus/WAN/VPN) queuing polices, with both sets of policies provisioning a “less-than-Best-Effort” Scavenger class. Access Layer policers would markdown out-of-profile traffic to DSCP CS1 (Scavenger) and then have all congestion management policies (whether in Catalyst hardware or in Cisco IOS software) provision a “less-than Best-Effort” queueing service for any traffic marked to DSCP CS1. Let’s illustrate how this might work for both legitimate traffic exceeding the Access Layer’s policer watermark and also the case of illegitimate excess traffic resulting from a DoS or worm attack. In the former case, assume that the PC generates over 5 Mbps of traffic, perhaps because of a large file transfer or backup. Congestion (under normal operating conditions) is rarely if ever experienced within the Campus because there is generally abundant capacity to carry the traffic. Uplinks to the Distribution and Core layers of the Campus network are typically GigabitEthernet and would require 1000 Mbps of traffic from the Access Layer switch to congest. If the traffic is destined to the far side of a WAN/VPN link (which is rarely over 5 Mbps in speed), dropping occurs even without the Access Layer policer, because of the bottleneck caused by the Campus/WAN speed mismatch. The TCP sliding windows mechanism would eventually find an optimal speed (under 5 Mbps) for the file transfer. Access Layer policers that markdown out-of-profile traffic to Scavenger (CS1) would thus not affect legitimate traffic, aside from the obvious remarking. No reordering or dropping would occur on such flows as a result of these policers that would not have occurred anyway. In the latter case, the effect of Access Layer policers on traffic caused by DoS or worm attacks is quite different. As hosts become infected and traffic volumes multiply, congestion may be experienced even within the Campus. If just 11 end-user PCs on a single switch begin spawning worm flows to their maximum FastEthernet link capacities, the GigabitEthernet uplink from the Access Layer switch to the Distribution Layer switch will congest and queuing/reordering/dropping will engage. At this point, VoIP, critical data applications, and even Best Effort applications would gain priority over worm-generated traffic (as Scavenger traffic would be dropped the most aggressively). Furthermore, network devices would remain accessible for administration of the patches/plugs/ACLs/NBAR-policies required to fully
Enterprise QoS Solution Reference Network Design Guide
1-30
Version 3.3
Chapter 1
Quality of Service Design Overview Summary
neutralize the specific attack. WAN/VPN links would also be protected: VoIP, critical data and even Best Effort flows would receive priority over any WAN/VPN traffic marked down to Scavenger/CS1. This is a huge advantage, because generally WAN/VPN links are the first to be overwhelmed by DoS/worm attacks. Scavenger-class Access Layer policers thus significantly mitigate network traffic generated by DoS or worm attacks. It is important to recognize the distinction between mitigating an attack and preventing it entirely. The strategy described in this document does not guarantee that no DoS or worm attacks will ever happen, but serves only to reduce the risk and impact that such attacks could have on the network infrastructure.
Scavenger-class QoS DoS/Worm Mitigation Strategy
Let’s recap the most important elements of the Scavenger-class QoS DoS/worm mitigation strategy. First, network administrators need to profile applications to determine what constitutes normal as opposed to abnormal flows, within a 95 percent confidence interval. Thresholds demarking normal/abnormal flows will vary from enterprise to enterprise and from application to application. Beware of over-scrutinizing traffic behavior because this could exhaust time and resources and could easily change daily. Remember, legitimate traffic flows that temporarily exceed thresholds are not penalized by the presented Scavenger- class QoS strategy. Only sustained, abnormal streams generated simultaneously by multiple hosts (highly-indicative of DoS/worm attacks) are subject to aggressive dropping only after legitimate traffic has been serviced. To contain such abnormal flows, deploy Campus Access-Edge policers to remark abnormal traffic to Scavenger (DSCP CS1). Additionally, whenever Cisco Catalyst 6500s with Supervisor 720s are deployed in the distribution layer, deploy a second line of policing-defense at the distribution layer via Per-User Microflow Policing. To complement these remarking policies, it is necessary to enforce end-to-end “less-than-Best-Effort” Scavenger-class queuing policies within the Campus, WAN and VPN. It is critically important to recognize, that even when Scavenger class QoS has been deployed end-to-end, this strategy only mitigates DoS/worm attacks, and does not prevent them or remove them entirely. Therefore, it is vital to overlay security, firewall, intrusion detection, identity, Cisco Guard, Cisco Traffic Anomaly Detector and Cisco Security Agent solutions in addition to QoS-enabled infrastructures.
Summary
This document began by reviewing Why Quality of Service is important to Enterprise networks, specifically because as it enables the transparent convergence of voice, video and data onto a single network. Furthermore, this proven technology can be used to mitigate the impact of DoS/worm attacks. To set a context for discussion, the QoS toolset was reviewed, including classification and marking tools, policing tools, scheduling tools, link specific tools and AutoQoS. The next section examined How is QoS is optimally deployed within the enterprise? The answer consisted of a 5 phase approach: 1) Strategically defining the objectives to be achieved via QoS—Successful QoS deployments begin by clearly defining organizational QoS objectives and then selecting an appropriate number of service classes to meet these objectives. This section introduced Cisco’s QoS Baseline as a strategic guide for selecting the number and type of traffic classes to meet organizational objectives; also a migration
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-31
Chapter 1 Summary
Quality of Service Design Overview
strategy was presented to illustrate how enterprises could start with simple QoS models and gradually increase their complexity as future needs arose. Executive endorsement is recommended, especially when choosing the select few applications to be serviced by the Mission-Critical data class. 2) Analyzing the service-level requirements of the various traffic classes to be provisioned for—the service level needs of voice, video, data and the control plane were discussed. Some of these highlights include the following: Voice requires 150 ms one-way, end-to-end (mouth-to-ear) delay, 30 ms of one-way jitter and no more than 1 % packet loss. Voice should receive strict priority servicing, and the amount of priority bandwidth assigned for it should take into account the VoIP codec, the packetization rate, IP/UDP/RTP headers (compressed or not) and Layer 2 overhead. Additionally, provisioning QoS for IP telephony requires that a minimal amount of guaranteed bandwidth be allocated to Call-Signaling traffic. Video comes in two flavors: Interactive Video and Streaming Video. Interactive Video has the same service level requirements as VoIP because a voice call is embedded within the video stream. Streaming Video has much laxer requirements, because of the high amount of buffering that has been built into the applications. Control plane requirements, such as provisioning moderate bandwidth guarantees for IP Routing and Network Management protocols, should not be overlooked. Data comes in a variety of forms, but can generally be classified into four main classes: Best Effort (the default class), Bulk (non-interactive, background flows), Transactional/Interactive (interactive, foreground flows) and Mission-Critical. Mission-Critical Data applications are locally-defined, meaning that each organization must determine the select few Transactional Data applications that contribute the most significantly to their overall business objectives. 3) Designing and testing QoS policies prior to production-network deployment—several best-practice QoS design principles were presented to help simplify and streamline the QoS design phase. These included: always performing QoS policies in hardware – rather than software – whenever a choice exists, classifying and marking (with standards-based DSCP markings) as close to the source as technically and administratively feasible, policing as close to the source as possible, and queuing on every node that has a potential for congestion. Queuing guidelines also included not provisioning more than 33% of a link for realtime traffic and reserving at least 25% of a link for the default Best Effort class. 4) Rolling-out the tested QoS designs to the production-network – Once the QoS designs have been finalized and PoC tested, it is vital ensure that the networking team thoroughly understands the QoS features and syntax before enabling features on production networks. Furthermore, it is recommended to schedule network downtime in order to rollout QoS features. A pilot network-segment can be selected for an initial deployment, and pending observation, the rollout can be expanded in stages to encompass the entire enterprise. A rollback strategy is always recommended, to address unexpected issues arising from the QoS deployment. 5) Monitoring service levels to ensure that the QoS objectives are being met – Implementing a QoS solution is not a one-time task that is complete upon policy deployment. A successful QoS policy rollout is followed by ongoing monitoring of service levels and periodic adjustments and tuning of QoS policies. As business conditions change, the enterprise may need to adapt to these changes and may be required to begin the QoS deployment cycle anew, by redefining their objectives, tuning and testing corresponding designs, rolling these new designs out and monitoring them to see if they match the redefined objectives. The document concluded by addressing the highly-relevant question: How can QoS tools be used to mitigate DoS/Worm Attacks? A “less-than-Best-Effort” traffic class, called Scavenger, was introduced, and a strategy for using this class for DoS/worm mitigation was presented. Specifically, flows can be monitored and policed at the Campus Access-Edge (and also at the Distribution Layer if Catalyst 6500s with Supervisor 720s are
Enterprise QoS Solution Reference Network Design Guide
1-32
Version 3.3
Chapter 1
Quality of Service Design Overview References
used). Out-of-profile flows can be marked down to the Scavenger marking (of DSCP CS1). To complement these policers, queues providing a “less-than-Best-Effort” Scavenger service during periods of congestion can be deployed in the LAN, WAN and VPN. Such a strategy would not penalize legitimate traffic flows that were temporarily out of profile; however sustained abnormal streams, highly-indicative of DoS/worm attacks, would be subject to aggressive dropping only after legitimate traffic was fully serviced. It is critically important to recognize, that even when Scavenger-class QoS has been deployed end-to-end, this strategy only mitigates DoS/worm attacks, and does not prevent them or remove them entirely. Therefore, it is vital to overlay security, firewall, intrusion detection, identity, Cisco Guard, Cisco Traffic Anomaly Detctor and Cisco Security Agent solutions in addition to QoS-enabled infrastructures.
References
Standards
•
RFC 791 “Internet Protocol Protocol Specification” http://www.ietf.org/rfc/rfc791 RFC 2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers http://www.ietf.org/rfc/rfc2474 RFC 2597 "Assured Forwarding PHB Group" http://www.ietf.org/rfc/rfc2597 RFC 2697 "A Single Rate Three Color Marker" http://www.ietf.org/rfc/rfc2697 RFC 2698 "A Two Rate Three Color Marker" http://www.ietf.org/rfc/rfc2698 RFC 3168 "The Addition of Explicit Congestion Notification (ECN) to IP" http://www.ietf.org/rfc/rfc3168 RFC 3246 "An Expedited Forwarding PHB (Per-Hop Behavior)" http://www.ietf.org/rfc/rfc3246
•
•
•
•
•
•
Books
•
Szigeti, Tim and Christina Hattingh. End-to-End QoS Network Design: Quality of Service in LANs, WANs and VPNs. Indianapolis: Cisco Press, 2004.
Cisco Documentation
•
Cisco IOS QoS Configuration Guide – Cisco IOS version 12.3 http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/qos_vcg.htm Cisco IOS Configuration Guide – Configuring Data Link Switching Plus - Cisco IOS version 12.3
•
Enterprise QoS Solution Reference Network Design Guide Version 3.3
1-33
Chapter 1 References
Quality of Service Design Overview
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fibm_c/bcfpart2/bcfdls w.htm
•
Understanding How Routing Updates and Layer 2 Control Packets Are Queued on an Interface with a QoS Service Policy (PAK_PRIORITY) http://www.cisco.com/warp/public/105/rtgupdates.html
Enterprise QoS Solution Reference Network Design Guide
1-34
Version 3.3
C H A P T E R
2
Campus QoS Design
This chapter includes the following topics:
• • • • • • •
QoS Design Overview Catalyst 2950—QoS Considerations and Design Catalyst 3550—QoS Considerations and Design Catalyst 2970/3560/3750—QoS Considerations and Design Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design Catalyst 6500 PFC2/PFC3—QoS Considerations and Design WAN Aggregator/Branch Router Handoff Considerations
QoS Design Overview
This section includes the following topics:
• • • • • •
Where is QoS Needed in a Campus? DoS/Worm Mitigation Call Signaling Ports Access Edge Trust Models Cisco IP Phones WAN Aggregator/Branch Router Connections
Where is QoS Needed in a Campus?
The case for Quality of Service (QoS) in WANs/VPNs is largely self-evident because of its low-bandwidth links compared to the high-bandwidth requirements of most applications. However, the need for QoS is sometimes overlooked or even challenged in high-bandwidth Gigabit/TenGigabit campus LAN environments. Although network administrators sometimes equate QoS only with queuing, the QoS toolset extends considerably beyond just queuing tools. Classification, marking and policing are all important QoS functions that are optimally performed within the campus network, particularly at the access layer ingress edge (access edge). Three important QoS design principles are important when deploying campus QoS policies:
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-1
Chapter 2 QoS Design Overview
Campus QoS Design
•
Classify and mark applications as close to their sources as technically and administratively feasible. This principle promotes end-to-end Differentiated Services/Per-Hop Behaviors. Sometimes endpoints can be trusted to set Class of Service (CoS)/Differentiated Services Code Point (DSCP) markings correctly, but this is not recommended because users can easily abuse provisioned QoS policies if permitted to mark their own traffic. For example, if DSCP Expedited Forwarding (EF) received priority services throughout the enterprise, a user could easily configure the NIC on a PC to mark all traffic to DSCP EF, thus hijacking network priority queues to service their non-real time traffic. Such abuse could easily ruin the service quality of real time applications (like VoIP) throughout the enterprise. For this reason, the clause “as close as… administratively feasible” is included in the design principle.
•
Police unwanted traffic flows as close to their sources as possible. There is little sense in forwarding unwanted traffic only to police and drop it at a subsequent node. This is especially the case when the unwanted traffic is the result of Denial of Service (DoS) or worm attacks. Such attacks can cause network outages by overwhelming network device processors with traffic.
•
Always perform QoS in hardware rather than software when a choice exists. Cisco IOS routers perform QoS in software. This places additional demands on the CPU, depending on the complexity and functionality of the policy. Cisco Catalyst switches, on the other hand, perform QoS in dedicated hardware ASICS and as such do not tax their main CPUs to administer QoS policies. You can therefore apply complex QoS policies at Gigabit/TenGigabitEthernet line speeds in these switches.
For these reasons, you should enable QoS policies such as classification and marking policies to establish and enforce trust boundaries as well as policers to protect against undesired flows at the access edge of the LAN. Most campus links are underutilized. Some studies have shown that 95 percent of campus access layer links are utilized at less than 5 percent of their capacity. This means that you can design campus networks to accommodate oversubscription between access, distribution and core layers. Oversubscription allows for uplinks to be utilized more efficiently and more importantly, reduces the overall cost of building the campus network. Common campus oversubscription values are 20:1 for the access-to-distribution layers and 4:1 for the distribution-to-core layers, as shown in Figure 2-1.
Figure 2-1 Typical Campus Oversubscription Ratios
Core
Si
Si
Typical 4:1 Oversubscription Distribution
Si Si
Typical 20:1 Oversubscription Access
224798
Enterprise QoS Solution Reference Network Design Guide
2-2
Version 3.3
Chapter 2
Campus QoS Design QoS Design Overview
It is quite rare under normal operating conditions for campus networks to suffer congestion. And if congestion does occur, it is usually momentary and not sustained, as at a WAN edge. However, critical applications like VoIP still require service guarantees regardless of network conditions. The only way to provide service guarantees is to enable queuing at any node that has the potential for congestion—regardless of how rarely, in fact, this may occur. The potential for congestion exists in campus uplinks because of oversubscription ratios and speed mismatches in campus downlinks (for example, GigabitEthernet to FastEthernet links). The only way to provision service guarantees in these cases is to enable queuing at these points. Queuing helps to meet network requirements under normal operating conditions, but enabling QoS within the campus is even more critical under abnormal network conditions such as DoS/worm attacks. During such conditions, network traffic may increase exponentially until links are fully utilized. Without QoS, the worm-generated traffic drowns out applications and causes denial of service through unavailability. Enabling QoS policies within the campus, as detailed later in this chapter, maintains network availability by protecting and servicing critical applications such as VoIP and even Best Effort traffic. The intrinsic interdependencies of network QoS, High Availability and security are clearly manifest in such worse-case scenarios. So where is QoS required in campus? Access switches require the following QoS policies:
• • •
Appropriate (endpoint-dependant) trust policies, and/or classification and marking policies Policing and markdown policies Queuing policies. DSCP trust policies Queuing policies Optional per-user microflow policing policies (only on supported platforms)
Distribution and core switches require the following QoS policies:
• • •
These recommendations are summarized in Figure 2-2.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-3
Chapter 2 QoS Design Overview
Campus QoS Design
Figure 2-2
Where is QoS Required within the Campus?
Core
Si
Si
Distribution
Si Si
Access
Interswitch Links: DSCP-Trust and Queuing Policies Optional (C6500-PFC3 Only): Per-User Microflow Policing on Uplinks from Access Layer
DoS/Worm Mitigation Strategies
A proactive approach to mitigating DoS/worm flooding attacks within campus environments is to immediately respond to out-of-profile network behavior indicative of a DoS or worm attack through access layer policers. Such policers meter traffic rates received from endpoint devices and markdown excess traffic when these exceed specified watermarks (at which point they are no longer considered normal flows). These policers are relatively “dumb” because they do not match specific network characteristics of specific types of attacks. Instead, they simply meter traffic volumes and respond to abnormally high volumes as close to the source as possible. The simplicity of this approach negates the need for the policers to be programmed with knowledge of the specific details of how the attack is being generated or propagated. It is precisely this “dumbness” of such access layer policers that allow them to stay effective as worms mutate and become more complex. The policers do not care how the traffic was generated or what it looks like, they only care how much traffic is being put onto the wire. Therefore, they continue to police even advanced worms that continually change the tactics of how traffic is being generated. For example, in most enterprises it is quite abnormal (within a 95 percent statistical confidence interval) for PCs to generate sustained traffic in excess of 5 percent of their link capacity. In the case of a FastEthernet switch port, this means that it is unusual in most organizations for an end-user PC to generate more than 5 Mbps of uplink traffic on a sustained basis.
Note
It is important to recognize that this value for normal access edge utilization by endpoints of 5 percent is just an example value used for simplicity in this chapter. This value would likely vary from industry vertical to vertical, and from enterprise to enterprise.
Enterprise QoS Solution Reference Network Design Guide
2-4
224799
Access Edges: Trust, Classification, Marking, Policing, and Queuing Policies
Version 3.3
Chapter 2
Campus QoS Design QoS Design Overview
Cisco does not recommend policing all traffic to 5 Mbps and automatically dropping the excess. If that was the case, there would be no need to deploy FastEthernet or GigabitEthernet switch ports to endpoint devices because even 10-BaseT Ethernet switch ports have more uplink capacity than a 5 Mbps policer-enforced limit. Such an approach would also penalize legitimate traffic that did exceed 5 Mbps on a FastEthernet switch port. A less severe approach is to couple access layer policers with hardware/software (campus/WAN/VPN) queuing polices, with both sets of policies provisioning for a less-than Best-Effort Scavenger class. With this method, access layer policers mark down out-of-profile traffic to DSCP CS1 (Scavenger) and then all congestion management policies (whether in Catalyst hardware or in IOS software) provision a less-than Best-Effort service for any traffic marked to CS1 during periods of congestion. This method works for both legitimate traffic exceeding the access layer policer’s watermark and also for illegitimate excess traffic as a result of a DoS or worm attack. In the former case, for example, assume that the PC generates over 5 Mbps of traffic, perhaps because of a large file transfer or backup. Congestion under normal operating conditions is rarely if ever experienced because there is generally abundant capacity to carry the traffic within the campus. This is usually true because the uplinks to the distribution and core layers of the campus network are typically GigabitEthernet and require 1000 Mbps of traffic from the access layer switch to congest. If the traffic is destined to the far side of a WAN/VPN link, which is rarely over 5 Mbps in speed, dropping occurs even without the access layer policer, because of the campus/WAN speed mismatch and resulting bottleneck. TCP’s sliding windows mechanism eventually finds an optimal speed (under 5 Mbps) for the file transfer. Thus, access layer policers that mark down out-of-profile traffic to Scavenger (CS1) do not affect legitimate traffic, aside from the obvious remarking. No reordering or dropping occurs on such flows as a result of these policers that would not have occurred in any event. In the case of illegitimate excess traffic, the effect of access layer policers on traffic caused by DoS or worm attacks is quite different. As many hosts become infected and traffic volumes multiply, congestion may be experienced in the campus up-links due to the aggregate traffic volume. For example, if just 11 end-user PCs on a single access-layer switch begin spawning worm flows to their maximum FastEthernet link capacities, the GigabitEthernet up-link to the distribution layer switch will congest, and queuing/reordering will engage. At such a point, VoIP and critical data applications, and even Best Effort applications, gain priority over worm-generated traffic. Scavenger traffic is dropped the most aggressively, while network devices remain accessible for the administration of patches/plugs/ACLs required to fully neutralize the specific attack. WAN links are also protected. VoIP, critical data and even Best Effort flows continue to receive priority over any traffic marked down to Scavenger/CS1. This is a huge advantage, because WAN links are generally the first to be overwhelmed by DoS/worm attacks. Access layer policers thus significantly mitigate network traffic generated by DoS or worm attacks. You should recognize the distinction between mitigating an attack and preventing it entirely. The strategy presented here does not guarantee that no Denial of Service or worm attacks will ever happen, but serves only to reduce the risk and impact that such attacks have on the campus network infrastructure and then, by extension, the WAN/VPN network infrastructure. Furthermore, while this strategy reduces the collateral damage to the network infrastructure caused by DoS/worm attacks, it may not mitigate other specific objectives of such worms, such as reconnaissance and vulnerability exploitation. Hence, a comprehensive approach much be used to address DoS/worm attacks, involving a holistic integration of security technologies with Quality of Service technologies.
Call Signaling Ports
In this design chapter, only Skinny Call Control Protocol (SCCP) ports (TCP Ports 2000–2002) are used to identify call signaling protocols to keep the examples relatively simple.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-5
Chapter 2 QoS Design Overview
Campus QoS Design
However, SCCP is by no means the only call signaling protocol used in IP telephony environments. Cisco recommends including all relevant call signaling ports required for a given IPT environment in the access lists that identify call signaling protocols. Firewalls protecting CallManagers should also allow additional ports to provide the supplementary services that CallManagers provide or require.
Access Edge Trust Models
This section includes the following topics:
• • •
Trusted Endpoints Untrusted Endpoints Conditionally-Trusted Endpoints
The primary function of access edge policies is to establish and enforce trust boundaries. A trust boundary is the point within the network where markings such as CoS or DSCP begin to be accepted. Previously-set markings are overridden as required at the trust boundary. You should enforce trust boundaries as close to the endpoints as technically and administratively possible as shown in Figure 2-3.
Figure 2-3 Establishing Trust Boundaries
Endpoints 1 Access Distribution Core WAN Aggregators
Si
Si
2 3
Si
Si
Trust Boundary 1 Optimal Trust Boundary: Trusted Endpoint 2 Optimal Trust Boundary: Untrusted Endpoint 3 Suboptimal Trust Boundary
224800
Legend for Figure 2-3:
1. 2. 3.
Optimal trust boundary: trusted endpoint Optimal trust boundary: untrusted endpoint Sub-optimal trust boundary
The definition of the trust boundary depends on the capabilities of the endpoints that are being connected to the access edge of the LAN. The following are the three main categories of endpoints as they relate to trust boundaries:
• • •
Trusted endpoints Untrusted endpoints Conditionally-trusted endpoints
Enterprise QoS Solution Reference Network Design Guide
2-6
Version 3.3
Chapter 2
Campus QoS Design QoS Design Overview
Trusted Endpoints
Trusted endpoints have the capabilities and intelligence to mark application traffic to the appropriate CoS and/or DSCP values. Trusted endpoints also have the ability to remark traffic that may have been previously marked by an untrusted device. Trusted endpoints are not typically mobile devices, which means that the switch port into which they are plugged does not usually change.
Note
Cisco IP Phones, which often change switch ports as users move, are more appropriately classified as conditionally-trusted endpoints. Examples of trusted endpoints include the following:
•
Analog gateways—These devices connect analog devices such as fax machines, modems, TDD/TTYs, and analog phones to the VoIP network, such that the analog signals can be packetized and transmitted over the IP network. Examples of analog gateways include the following:
– Analog network modules (NM-1V and NM2-V, which support either high- or low-density
Voice/Fax Interface Cards (VICs)
– Cisco Communication Media Module (CMM) linecard – Catalyst 6500 Analog Interface Module (WS-X6624-FXS). – Cisco VG224 and VG248 IOS-based voice gateways •
IP conferencing stations—These devices are specialized IP Phones with 360 degree microphones and advanced speakerphones designed for meeting room VoIP conferencing. Examples of such devices include the Cisco 7935 and 7936. Videoconferencing gateways and systems—These devices transmit interactive video across the IP network. Examples of such devices capable of setting DSCP markings include the Cisco IP/VC 3511, 3521, 3526 and 3540 videoconferencing gateways and systems. If, on the other hand, video-conferencing devices do not have the ability to set DSCP markings correctly, they should be treated as untrusted devices. Video surveillance units—These third-party devices are used for security and remote monitoring purposes over an IP (as opposed to a closed-circuit) network. These may support DSCP marking, in which case they may be considered trusted endpoints. Servers—Certain servers, within the data center or otherwise, might be capable of correctly marking their traffic on their NICs. In such cases, the network administrator can choose to trust such markings. However, enforcing such a trust boundary requires cooperation between network administrators and system or server administrators, an alliance that is often fragile, at best, and usually involves considerable finger pointing. Additionally, network administrators should bear in mind that the majority of DoS/ worm attacks target servers. Infected servers not only might spew profuse amounts of traffic onto the network, but, in such cases, they might do so with trusted markings. There’s no hard-and-fast rule that will apply to every situation. Some administrators prefer to trust certain servers, like Cisco CallManagers, due to the large number of ports that may be in use to provide services rather than administer complex access lists. In either case, consider the tradeoffs involved when deciding whether or not to trust a server. Wireless access points—Some wireless access points (APs) have the ability to mark or remark 802.1p CoS and/or DSCP values and therefore qualify as trusted endpoints. Examples include Cisco Aironet 350, 1100 and 1200 series APs.
•
•
•
•
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-7
Chapter 2 QoS Design Overview
Campus QoS Design
•
Wireless IP Phones—Mobile wireless IP Phones can mark DSCP values for VoIP and call signaling and pass these on to the wireless AP with which they are associated. Examples include the Cisco 7920G wireless IP Phone.
When trusted endpoints are connected to a switch port, all that is typically required is enabling the following interface command: mls qos trust dscp. Optionally, if the traffic rate of the trusted application is known, the network administrator could apply an access layer policer to protect against out-of-profile rates, in case the trusted endpoint is somehow compromised. For example, consider the case of an IP videoconferencing (IP/VC) station that transmits 384 kbps of video (not including Layer 2–4 overhead) and correctly marks this traffic to DSCP AF41. An access edge ingress policer could be applied to the switch port to which this IP/VC station is connected and be configured to trust up to 500 kbps, allowing for Layer 2–4 overhead and policer granularity of interactive video traffic marked AF41. Excess traffic could be marked to CS1. Such a policy prevents network abuse if another device is inserted, perhaps via a hub, into the path, or if the trusted endpoint itself becomes compromised.
Untrusted Endpoints
This section includes the following topics:
• •
Untrusted PC + SoftPhone with Scavenger-Class QoS Untrusted Server with Scavenger-Class QoS
As previously mentioned, trusting end users and their PCs is generally a bad idea because newer operating systems like Windows XP and Linux make it relatively easy to set CoS or DSCP markings on PC NICs. Such markings may be set deliberately or even inadvertently. In either case, improperly set QoS markings can affect the service levels of multiple users within the enterprise and make troubleshooting a nightmare. Also, marking application traffic on server NICs has disadvantages as discussed in the previous section that may make it preferable to treat these as untrusted devices. While client PCs and data center servers are related and complimentary, they also have unique considerations that affect their classification and marking policies, and so will be examined individually.
Untrusted PC + SoftPhone with Scavenger-Class QoS
Cisco generally recommends not trusting end user PC traffic. However, some PCs may be running applications that critically require QoS treatment. A classic example is a PC running Cisco IP Softphone. In such a case, the critical application needs to be identified using access lists and marked/remarked at the access edge. Remarking can be done with either an MLS QoS set ip dscp command or with a policer. A policer is recommended in this case because limits on the amount of traffic being marked can then be imposed to prevent abuse. Cisco SoftPhones can use regular G.711 codecs, in which case 128 kbps is adequate, or they can be configured use a G.722 (wide codec), in which case 320 kbps is required. The tighter the policer the better, provided that adequate bandwidth has been allocated for application requirements. Additionally, you can explicitly define the UDP ports used by Cisco SoftPhone within the application as opposed to simply picking random ports within the UDP range of 16383–32767. This is recommended because this allows for a more granular access list to match legitimate Cisco SoftPhone traffic, thereby tightening the overall security of the policy.
Enterprise QoS Solution Reference Network Design Guide
2-8
Version 3.3
Chapter 2
Campus QoS Design QoS Design Overview
Note
In this context, “Softphone” can be used to refer to any PC-Based IP Telephony application, including Cisco IP Communicator and similar products. The logic of such an access edge policer marking Cisco Softphone traffic from an untrusted PC endpoint is shown in Figure 2-4.
Figure 2-4
Start
Untrusted Endpoint Policing —PC + SoftPhone + Scavenger Model
UDP 16384 to 32767
Yes No Yes No
Yes
Re-Mark to DSCP EF and Transmit Re-Mark to DSCP CS1 and Transmit
No
TCP 2000–2002
Yes
Re-Mark to DSCP CS3 and Transmit Re-Mark to DSCP CS1 and Transmit
No
Yes No
Re-Mark to DSCP 0 and Transmit Re-Mark to DSCP CS1 and Transmit
224801
The syntax for implementing such a policer may vary slightly from platform to platform, as is detailed in the subsequent platform-specific sections.
Untrusted Server with Scavenger-Class QoS
Servers as well as PCs are subject to attack and infection by worms and viruses, so these should also be policed as to the amounts of traffic they admit onto the network. The values are greater than PC endpoints and so network administrators should profile traffic patterns from servers to establish a baseline of normal and abnormal behavior. For an example, assume a single server is running multiple applications, in this case SAP (TCP ports 3200–3203 and also 3600), Lotus Notes (TCP port 1352), and IMAP (TCP ports 143 and 220). SAP is considered a mission-critical application and until call signaling marking on IP telephony equipment fully migrates from DSCP AF31 to CS3 it should be marked to DSCP 25. Lotus Notes is classed as a Transactional Data application and should be marked to DSCP AF21. IMAP is considered a Bulk application and should be marked to DSCP AF11. Application baselining has shown that 95 percent of the traffic rates for SAP, Lotus Notes and IMAP are less than 15 Mbps, 35 Mbps and 50 Mbps, respectively. To ensure that no other traffic comes from the server, a final policer to catch any other type traffic is included. In the event of legitimate traffic that temporarily exceeds these values, no dropping or re-ordering of packets occurs. However, should this server become infected and begin sending sustained traffic in excess of these normal rates, the excess is subject to aggressive dropping in the event of link congestion. The logic of such a policer is shown in Figure 2-5.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-9
Chapter 2 QoS Design Overview
Campus QoS Design
Figure 2-5
Start Mission-Critical Data ACLs
Untrusted Endpoint Policing—Multi-Application Server + Scavenger Model
Yes Yes Re-Mark to DSCP 25 and Transmit Re-Mark to DSCP CS1 and Transmit Yes Re-Mark to DSCP AF21 and Transmit Re-Mark to DSCP CS1 and Transmit Yes No Yes No Re-Mark to DSCP AF11 and Transmit Re-Mark to DSCP CS1 and Transmit Re-Mark to DSCP 0 and Transmit Re-Mark to DSCP CS1 and Transmit
224802
MCD ACLs
15 Mbps
No
TD ACLs
No Yes
35 Mbps
Transactional Data ACLs
No
Bulk Data ACLs
No Yes
Bulk Data ACLs
No
Remember that when deploying QoS designs for untrusted servers, the applications are usually identified by source ports, and not destination ports (as is the case with client-to-server access lists). Thus the access list becomes:
permit [tcp | udp] any [eq | range] any
as opposed to:
permit [tcp | udp] any any [eq | range]
This is a subtle but critical difference.
Conditionally-Trusted Endpoints
This section includes the following topics:
• • • •
Cisco IP Phones Cisco AutoQoS—VoIP Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model
One of the main business advantages of IP telephony is the simplicity and related cost savings of user adds/moves/changes. To move, a user simply picks up their IP phone, plugs it in at his or her new location and carries on business as usual. If their infrastructure supports inline power, it is literally a matter of unplugging a single RJ-45 cable and plugging it in at the new location. IP phones are trusted devices, while PCs are not. This can be a problem when provisioning trust in a mobile environment. Consider the following example: Port A is configured to trust the endpoint connected to it, which initially is an IP phone. Port B is configured not to trust the endpoint connected to it, which initially is a PC. Because of a move, these endpoints get plugged into the opposite ports. This breaks the VoIP quality of calls made from the IP phone (now plugged into untrusted Port B) and opens the network up for unintentional or deliberate abuse of provisioned QoS by the PC (now plugged into the trusted Port A).
Enterprise QoS Solution Reference Network Design Guide
2-10
Version 3.3
Chapter 2
Campus QoS Design QoS Design Overview
One solution is to place a call to the networking help desk when the move is scheduled, so that the switch ports can be reconfigured to trust/untrust the endpoints as required. However, this approach dampens the mobility business advantage of IP telephony, since manual network administration is then be required to complete the move. Another solution is to have an intelligent exchange of information between the switch and the devices plugged into their ports. If the switch discovers a device that is trustworthy, then it can extend trust to it dynamically; if not, then not. Cisco IP Phones use the latter solution. In the current Cisco implementation, the intelligent exchange of information is performed using Cisco Discovery Protocol (CDP). Figure 2-6 shows a conditional trust boundary extension granted to an IP Phone that has passed a CDP exchange.
Figure 2-6 Conditionally-Trusted Endpoint—Trust Boundary Extension and Operation
“I see you’re an IP phone.” So I will trust your CoS.” IP Phone Phone VLAN = 110 PC VLAN = 10
1
TRUST BOUNDARY 4 “CoS 5 = DSCP 46” “CoS 3 = DSCP 24” “CoS 0 = DSCP 0” “Voice = 5, Signaling = 3” All PC traffic is reset to CoS 0. 3 PC sets CoS to 5 for all traffic.
2
1 Switch and phone exchange CDP; trust boundary is extended to IP phone. 2 Phone sets CoS to 5 for VoIP and to 3 for Call-Signaling traffic. 3 Phone rewrites CoS from PC Port to 0. 4 Switch trusts CoS from phone and maps CoS DSCP for output queuing.
224803
The sequence shown in Figure 2-6 is the following:
1. 2. 3. 4.
Switch and phone exchange CDP; trust boundary is extended to IP Phone. Phone sets CoS to 5 for VoIP and to 3 for call signaling traffic. Phone rewrites CoS from PC to 0. Switch trusts CoS from phone and maps CoS to DSCP for output queuing.
CDP is a lightweight, proprietary protocol engineered to perform neighbor discovery. It was never intended as a security or authentication protocol. Therefore, to improve the security of conditional trust extension, the next generation of Cisco IP Telephony products will incorporate the use of advanced protocols to perform authentication.
Cisco IP Phones
The following overview of some of the main IP Phones helps to explain their impact on access edge QoS design.
•
Cisco 7902G— The 7902G is an entry-level IP phone that addresses the voice¬communication needs of areas where only a minimal amount of features is required, such as lobbies, hallways, and break rooms. These phones probably would not be moved. The 7902G has only a single 10BASE-T Ethernet port on the back of the phone; therefore, there is no hardware support to connect a PC to it.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-11
Chapter 2 QoS Design Overview
Campus QoS Design
•
Cisco 7905G—The 7905G is a basic IP phone that addresses the voice communication needs of a cubicle worker who conducts low to medium telephone traffic. The Cisco 7905G has only a single 10BASE-T Ethernet port on the back of the phone; therefore, there is no hardware support to connect a PC to it. Cisco 7910G and 7910G+SW—The 7910G and 7910G+SW IP phones address the voice-communication needs associated with a reception area, lab, manufacturing floor, or employee with a minimal amount of telephone traffic. The only difference between the Cisco 7910G and the Cisco 7910G+SW is that the former has a single 10BASE-T Ethernet port (therefore, there is no hardware support to connect a PC to it), and the latter has two 10/100BASE-T Ethernet ports, which allow a PC to be connected to the IP phone. Cisco 7912G—The 7912G is a basic IP phone that addresses the voice-communication needs of a cubicle worker who conducts low to medium telephone traffic. The 7912G supports inline power and an integrated 10/100 Ethernet switch for connecting a PC. The switch used in the 7912G has the capability to mark CoS and DSCP of Voice and Call Signaling traffic that originates from the IP phone, but the Cisco 7912G does not have the capability to re-mark CoS values of PC-generated traffic. Cisco 7940G—The 7940G IP phone is suited best for an employee in a basic office cubicle environment—a transaction-type worker, for example—who conducts a medium amount of business by telephone. The 7940G supports inline power and has an integrated 10/100 Ethernet switch for connecting a PC. Cisco 7960G—The 7960G is designed to meet the communication needs of a profes¬sional worker in an enclosed office environment—an employee who experiences a high amount of phone traffic in the course of a business day. The 7960G supports inline power and has an integrated 10/100 Ethernet switch for connecting a PC. Cisco 7970G—The 7970G not only addresses the needs of the executive or major decision maker, but also brings network data and applications to users without PCs. This IP phone includes a backlit, high-resolution color touch-screen display. Cur¬rently, Cisco 7970G is the only Cisco IP phone that supports both Cisco prestandard Power over Ethernet (PoE) and the IEEE 802.3af PoE. The 7970G has an integrated 10/100 Ethernet switch for connecting a PC.
•
•
•
•
•
All of the IP Phones listed above have the ability to mark 802.1Q/p CoS values for both VoIP and call signaling (default values are 5 and 3, respectively). Furthermore, they also have the ability to mark DSCP values for both VoIP and call signaling (current defaults are EF and AF31, respectively; future software releases will change these values to EF and CS3, respectively). IP Phone models 7902G, 7905G and 7910G lack the hardware to connecting a PC behind the Cisco IP Phone. All other IP Phone models listed above (except the 7912G) have the hardware support to connect a PC behind the IP Phone and also support 802.1Q/p CoS remarking of tagged packets that may originate from such PCs. The 10/100 Ethernet switch built into the 7912G does not have the support to re-mark CoS values that might have been set by a PC, as illustrated in Figure 2-7. This re-marking limitation represents a potential security hole for enterprises deploying these IP phones. However, this hole can be plugged, for the most part, with access-edge policers, as will be detailed in this chapter. It is important to note that if 7912G IP phones are deployed to users that move locations, all user switch ports within the enterprise should have access-edge policers set on them to ensure mobility and security if a 7912G user moves the phones to another port.
Enterprise QoS Solution Reference Network Design Guide
2-12
Version 3.3
Chapter 2
Campus QoS Design QoS Design Overview
Figure 2-7
Conditionally-Trusted Endpoint—Cisco 7912G Trust Boundary Extension and Operation
“I see you’re an IP phon e.” So I will t rust your CoS.” 7912G IP Phone Phone VLAN = 110 PC VLAN = 10
1
TRUST BOUNDARY 4 “CoS 5 = DSCP 46” “CoS 3 = DSCP 24” “CoS 5 = DSCP 46” “Voice = 5, Signaling = 3” No PC traffic is remarked. 3 PC sets CoS to 5 for all traffic.
2
1 Switch and phone exchange CDP; trust boundary is extended to IP phone. 3 Cisco 7912G IP phone does not rewrite CoS from PC port to 0. 4 Switch t rusts CoS from phone and maps CoS DSCP for output queuing.
224804
2 Phone sets CoS to 5 for VoIP and to 3 for Call-Signaling traffic.
The sequence as shown in Figure 2-7 is as follows:
1. 2. 3. 4.
Switch and phone exchange CDP; trust boundary is extended to IP Phone Phone sets CoS to 5 for VoIP and to 3 for call signaling traffic. Cisco 7912G IP Phone does not rewrite CoS from PC port to 0 Switch trusts CoS from phone and maps CoS to DSCP for output queuing
AutoQoS—VoIP
When the main business objective of the QoS deployment is to enable QoS for IP Telephony only (i.e., without Scavenger-class QoS), then the network administrator may choose to take advantage of the Cisco AutoQoS VoIP feature. AutoQoS VoIP is essentially an intelligent macro that enables an administrator to enter one or two simple AutoQoS commands to enable all the appropriate features for the recommended QoS settings for an VoIP and IP Telephony for a specific platform and/or a specific interface. AutoQoS VoIP automatically configures the best-practice QoS configurations (based on previous Cisco Enterprise QoS SRNDs) for VoIP on Cisco Catalyst switches and IOS routers. By entering one global and/or one interface command (depending on the platform), the AutoQoS VoIP macro then would expand these commands into the recommended VoIP QoS configurations (complete with all the calculated parameters and settings) for the platform and interface on which the Auto-QoS VoIP macro is applied. For example, on Cisco Catalyst switches, AutoQoS performs the following automatically:
• • • • • •
Enforces a conditional-trust boundary with any attached Cisco IP phones Enforces a trust boundary on Catalyst switch access ports and uplinks/downlinks Modifies CoS-to-DSCP (and IP Precedence-to-DSCP) mappings, as required Enables Catalyst strict priority queuing for voice (CoS 5/DSCP EF) and preferential queuing for Call-Signaling traffic (CoS 3/DSCP CS3) Enables best-effort queuing for all other data (CoS 0/DSCP 0) traffic Modifies queue admission criteria (such as CoS-to-queue mapping)
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-13
Chapter 2 QoS Design Overview
Campus QoS Design
•
Modifies queue sizes and queue weights, where required
The standard (interface) configuration commands to enable AutoQoS are: auto qos voip. Depending on the platform, AutoQoS VoIP can support the following additional keyword commands:
•
cisco-phone—When you enter the auto qos voip cisco-phone interface configuration command on a port at the edge of a network that is connected to a Cisco IP Phone, the switch enables the conditional-trusted boundary feature. The switch uses the Cisco Discovery Protocol (CDP) to detect the presence or absence of a Cisco IP Phone. When a Cisco IP Phone is detected, the ingress classification on the interface is set to trust the CoS marking of the received packet. When a Cisco IP Phone is absent, the ingress classification is set to not trust the CoS (or DSCP) value of any packet. cisco-softphone—When you enter the auto qos voip cisco-softphone interface configuration command on a port at the edge of the network that is connected to a device running the Cisco SoftPhone, the switch uses policing to decide whether a packet is in or out of profile and to specify the action on the packet. If the packet does not have a DSCP value of 24, 26, or 46 or is out of profile, the switch changes the DSCP value to 0. trust —When you enter the auto qos voip trust interface configuration command on a port connected to the interior of the network, the switch trusts the CoS value in ingress packets (the assumption is that traffic has already been classified by other edge devices).
•
•
The AutoQoS commands and optional keywords are shown on a per-platform basis in the platform-specific design sections of this chapter. Additionally, it should be pointed out that AutoQoS VoIP can also be viewed as a template which may be modified and expanded on to support additional classes of applications. In this manner, the AutoQoS VoIP feature can be used to quickly and accurately deploy 80% (or more) of the desired solution, which then can be manually customized further to tailor to the specific customer requirements.
Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model
In this model, trust of CoS markings is extended to CDP-verified IP Phones. An additional layer of protection can be offered by access edge policers. As stated previously, the tighter the policers the better, provided that adequate bandwidth is permitted for legitimate applications. The most granular policing can be achieved by the use of per-port/per-VLAN policers.
Note
Currently, only the Catalyst 3550 family supports per-port/per-VLAN policing as a feature. Other platforms have already committed to supporting this feature in the near future. For platforms that do not yet support this feature, equivalent logic can be achieved by including subnet information within the access lists being referenced by the class maps. Such examples are provided later in this chapter. For example, the peak amounts of legitimate traffic originating from the voice VLAN (VVLAN) on a per-port basis are:
• • •
128 kbps for Voice traffic, marked CoS 5/DSCP EF (320 kbps in the case of G.722 codecs) 32 kbps for call signaling traffic (marked CoS 3/DSCP AF31 or CS3) 32 kbps of Best Effort services traffic (marked CoS 0)
There should not be any other traffic originating from the VVLAN, so the policer can be configured to remark anything else from the VVLAN because such traffic is considered illegitimate and indicative of an attack. These policers can then be combined with a policer to meter traffic from the data VLAN (DVLAN), marking down traffic in excess of 5 percent (5 Mbps for FE ports) to Scavenger/CS1.
Enterprise QoS Solution Reference Network Design Guide
2-14
Version 3.3
Chapter 2
Campus QoS Design QoS Design Overview
The logic of these policers is shown in Figure 2-8.
Figure 2-8 Conditionally-Trusted Endpoint Policing—IP Phone + PC + Scavenger (Basic) Model
VVLAN + DSCP EF No Yes Yes
Start
128 kbps No
Trust and Transmit
Drop VVLAN + DSCP AF31 or CS3 No
Yes
32 kbps No
Yes
Re-Mark to DSCP CS3 and Transmit Re-Mark to DSCP CS1 and Transmit
VVLAN ANY No
Yes
32 kbps No
Yes
Re-Mark to DSCP 0 and Transmit Re-Mark to DSCP CS1 and Transmit
DVLAN ANY
Yes
5 Mbps No
Yes
Re-Mark to DSCP 0 and Transmit Re-Mark to DSCP CS1 and Transmit
Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model
Building on the previous model, you can add additional marking and policing for PC-based video-conferencing and multiple levels of data applications. Desktop videoconferencing applications use the same UDP port range by default as does Cisco SoftPhone. If the UDP ports used by the desktop videoconferencing application can be explicitly defined within the application, as with SoftPhone, then you can use two policers: one for IP/VC and another for SoftPhone. Otherwise, a single policer covering the UDP port range of 16384–32767 is required, which would be provisioned for the worst-case scenario of legitimate traffic. In this case, this is the videoconferencing application’s requirement of 500 kbps (for a 384 kbps desktop IP/VC application), as compared to the SoftPhone requirement of 128 kbps (or 320 kbps for G.722 codecs).
Note
Policer thresholds should be set according to the video application’s requirements. Some interactive-video applications may have higher bandwidth requirements for their codecs; for example Cisco Video Telephony (VT) Advantage includes a proprietary codec that requires 7 Mbps of bandwidth. You can add additional data VLAN policers to meter Mission-Critical Data, Transactional Data and Bulk Data flows. Each of these classes can be policed on ingress to the switch port to an in-profile amount, such as 5 percent each.
Note
Since Mission-Critical and Transactional Data applications are interactive foreground applications requiring user input, it is highly unlikely that both of these types of applications will be simultaneously generating 5 Mbps each from a client PC. However, in the rare case that they are, these flows will be policed further by any per-user microflow policing policies that may be deployed on distribution layer Catalyst 6500 Supervisor 720s (PFC3s), as is detailed later in this chapter.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-15
224805
Chapter 2 QoS Design Overview
Campus QoS Design
Another factor to keep in mind is that certain Catalyst platforms allow only up to 8 policers per FastEthernet port. Therefore, the model presented here is made to conform to this constraint to make it more generic and modular. For this reason, a separate policer has not been defined for call signaling traffic from Softphone. An access list to identify such traffic could be included within the Mission-Critical Data access lists, which is detailed in the configuration examples presented later in this chapter. The logic of these advanced policers is shown in Figure 2-9.
Figure 2-9 Conditionally-Trusted Endpoint Policing—IP Phone + PC + Scavenger (Advanced) Model
VVLAN + DSCP EF No Yes Yes
Start
128 kbps No
Trust and Transmit
Drop
VVLAN + DSCP AF31 or CS3 No
Yes
32 kbps No
Yes
Re-Mark to DSCP CS3 and Transmit Re-Mark to DSCP CS1 and Transmit
VVLAN ANY No
Yes
32 kbps No
Yes
Re-Mark to DSCP 0 and Transmit Re-Mark to DSCP CS1 and Transmit
DVLAN + UDP 1638432767
No
Yes 500 kbps No
Yes
Re-Mark to DSCP AF41 and Transmit Re-Mark to DSCP CS1 and Transmit
Mission-Critical Data ACLs
DVLAN + MCD ACLs
No
Yes 5 Mbps No
Yes
Re-Mark to DSCP 25 and Transmit Re-Mark to DSCP CS1 and Transmit
Transactional Data ACLs
DVLAN + TD ACLs
No
Yes
5 Mbps
Yes
Re-Mark to DSCP AF21 and Transmit Re-Mark to DSCP CS1 and Transmit
No
Bulk Data ACLs
DVLAN + BD ACLs No
Yes
Yes 5 Mbps No
Re-Mark to DSCP AF11 and Transmit Re-Mark to DSCP CS1 and Transmit
DVLAN ANY
Yes
5 Mbps
Yes
Re-Mark to DSCP 0 and Transmit Re-Mark to DSCP CS1 and Transmit 224806
No
Legend for Figure 2-9:
• • •
MCD = Mission Critical Data TD = Transactional Data BD = Bulk Data
Enterprise QoS Solution Reference Network Design Guide
2-16
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2950—QoS Considerations and Design
Catalyst 2950—QoS Considerations and Design
This section includes the following topics:
• • • • • • •
Catalyst 2950—Trusted Endpoint Model Catalyst 2950—AutoQoS VoIP Model Catalyst 2950—Untrusted PC + SoftPhone with Scavenger-Class QoS Model Catalyst 2950—Untrusted Server with Scavenger-Class QoS Model Catalyst 2950—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Catalyst 2950—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model Catalyst 2950—Queuing
The Catalyst 2950 does not support Layer 3 forwarding, and as such is only applicable as a low-end access layer switch. The QoS design options for a Catalyst 2950 are shown in Figure 2-10.
Figure 2-10 Access Layer Catalyst 2950 QoS Design Options
Access-Edges
Trusted-Endpoint Model AutoQoS–VoIP Model Trust-DSCP Untrusted Server + Scavenger Model IP Phone + PC + Scavenger (Basic) Model
132546
Uplinks to Distribution Layer
Global1P3Q1T Queuing
Cisco recommends using the Enhanced Image (EI) versions of IOS software on these platforms because these offer additional QoS features such as MQC/ACL classification options, policing and markdown functions, mapping tables and AutoQoS.
Catalyst 2950—Trusted Endpoint Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Command
Configuration
Configuring a Catalyst 2950 to trust an endpoint is fairly straightforward, as shown below. The trusted endpoint should be assigned either the voice VLAN (VVLAN) or the data VLAN (DVLAN) with the appropriate switchport commands.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-17
Chapter 2 Catalyst 2950—QoS Considerations and Design
Campus QoS Design
Example 2-1
Catalyst 2950—Trusted Endpoint Model Configuration
CAT2950(config)#interface FastEthernet0/1 CAT2950(config-if)#mls qos trust dscp
Catalyst MLS QoS Verification Command
The show mls qos interface verification command reports the configured trust state and the current operating trust mode of a switchport interface. In this example, the command verifies that interface FastEthernet 0/1 correctly trusts the DSCP values of the endpoint to which it is connected.
Example 2-2 Show MLS QoS Interface Verification of a Switchport Connected to a Trusted Endpoint
CAT2950#show mls qos interface FastEthernet0/1 FastEthernet0/1 trust state: trust dscp ! Configured trust state is to trust DSCP trust mode: trust dscp ! Current operating mode is to trust DSCP COS override: dis default COS: 0 pass-through: none trust device: none CAT2950#
Catalyst 2950—AutoQoS VoIP Model
The Catalyst 2950 supports AutoQoS VoIP with the following keyword options:
• • •
auto qos voip cisco-phone auto qos voip cisco-softphone auto qos voip trust
When you enable AutoQoS VoIP on the Catalyst 2950 by using the auto qos voip cisco-phone, the auto qos voip cisco-softphone, or the auto qos voip trust interface configuration command, the switch automatically generates a QoS configuration based on the traffic type and ingress packet label and applies the commands listed in Table 2-1 to the interface.
Table 2-1 Catalyst 2950 Auto-QoS Generated Configuration
Description The switch automatically enables standard QoS and configures the CoS-to-DSCP map (maps CoS values in incoming packets to a DSCP value).
Automatically Generated QoS Command Equivalent
CAT2950(config)# mls qos map cos-dscp 0 8 16 26 32 46 48 56
CAT2950(config-if)# mls qos trust cos If you entered the auto qos voip trust command, the switch automatically sets the ingress classification on the interface to trust the CoS value received in the packet.
Enterprise QoS Solution Reference Network Design Guide
2-18
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2950—QoS Considerations and Design
Table 2-1
Catalyst 2950 Auto-QoS Generated Configuration
CAT2950(config-if)# mls qos trust device cisco-phone
If you entered the auto qos voip cisco-phone command, the switch automatically enables the trusted boundary feature, which uses the CDP to detect the presence or absence of a Cisco IP Phone. If you entered the auto qos voip cisco-softphone command, the switch automatically creates class maps and policy maps.
CAT2950(config)# class-map match-all AutoQoS-VoIP-RTP-Trust CAT2950(config-cmap)# match ip dscp 46 CAT2950(config)# class-map match-all AutoQoS-VoIP-Control-Trust CAT2950(config-cmap)# match ip dscp 24 26 CAT2950(config)# policy-map AutoQoS-Police-SoftPhone CAT2950(config-pmap)# class AutoQoS-VoIP-RTP-Trust CAT2950(config-pmap-c)# set ip dscp 46 CAT2950(config-pmap-c)# police 1000000 4096 exceed-action drop CAT2950(config-pmap)# class AutoQoS-VoIP-Control-Trust CAT2950(config-pmap-c)# set ip dscp 24 CAT2950(config-pmap-c)# police 1000000 4096 exceed-action drop
CAT2950(config-if)# service-policy input After creating the class maps and policy maps, the switch automatically applies the AutoQoS-Police-SoftPhone policy map called AutoQoS-Police-SoftPhone to an ingress interface on which auto-QoS with the Cisco SoftPhone feature is enabled.
The switch automatically assigns egress queue usage on this interface. The switch enables the egress expedite queue and assigns WRR weights to queues 1, 2, and 3. (The lowest value for a WRR queue is 1. When the WRR weight of a queue is set to 0, this queue becomes an expedite queue.) The switch configures the CoS-to-egress-queue map:
• • • •
CAT2950(config)# CAT2950(config)# CAT2950(config)# CAT2950(config)# CAT2950(config)# CAT2950(config)#
wrr-queue bandwidth 10 20 70 1 no wrr-queue cos-map wrr-queue cos-map 1 0 1 wrr-queue cos-map 2 2 4 wrr-queue cos-map 3 3 6 7 wrr-queue cos-map 4 5
CoS values 0 and 1 select queue 1. CoS values 2 and 4 select queue 2. CoS values 3, 6, and 7 select queue 3. CoS value 5 selects queue 4.
Catalyst 2950—Untrusted PC + SoftPhone with Scavenger-Class QoS Model
The Catalyst 2950 does not support the range keyword within an ACL when the ACL is being referenced by a MQC class-map. Therefore, a policy to mark UDP flows in the port range of 16384 through 32767 cannot be configured on the Catalyst 2950.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-19
Chapter 2 Catalyst 2950—QoS Considerations and Design
Campus QoS Design
A possible workaround to this limitation would be to pre-set the port(s) to be used by SoftPhone within the application itself. In such a case, these ports would have to be discretely matched by ACL entries on the Catalyst 2950. Furthermore, each port being used for call signaling would also require a discrete ACL entry. However, even in the case where all these ports are buttoned down and discrete ACLs are configured on the Catalyst 2950 to match them, another limitation of the switch would come into play. Specifically, the Catalyst 2950 can only support policing in 1 Mbps increments on FastEthernet ports. Such lax policing would leave a fairly large hole to allow unauthorized traffic that may be mimicking Voice or call signaling to be admitted onto the network. Due to these limitations, it is not recommended to use a Catalyst 2950 to support an untrusted PC running SoftPhone.
Catalyst 2950—Untrusted Server with Scavenger-Class QoS Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
For the most part, the Catalyst 2950 can support the Untrusted Multi-Application Server + Scavenger Model as illustrated in Figure 2-5. Only the final element of the logical model, namely the policing of all other traffic to 1 Mbps (remarking traffic in excess of this limit to CS1) is not supported on the Catalyst 2950. The main platform-specific caveats that should be kept in mind when deploying this model on the Catalyst 2950 are the following:
•
Non-standard DSCP values are not supported; therefore, Mission-Critical Data traffic cannot be marked to DSCP 25 on Catalyst 2950s (a temporary recommendation during the interim of Cisco’s call signaling marking migration from AF31 to CS3); such application traffic can alternatively be marked to the more general class of Transactional Data (AF21), of which they are a subset. The mls qos cos override interface command must be used to ensure that untrusted CoS values are explicitly set 0 (default). The range keyword cannot be used in the ACLs being referenced by the class-maps; server-ports should be explicitly defined with a separate access list entry (ACE) per TCP/UDP port. User-defined masks must be consistent for all ACLs being referenced by class maps (if filtering is being done against TCP/UDP ports, then all Access Control Entries (ACEs) should be set to filter by TCP/UDP ports, as opposed to some ACEs filtering by ports and others by subnet or host addresses). System-defined masks (such as permit ip any any) cannot be used in conjunction with user-defined masks (such as permit tcp any any eq 3200) within the same policy map; therefore, if some traffic is being matched against TCP/UDP ports, then a final ACL cannot be used to match all other traffic via a permit ip any any statement). The Catalyst 2950 IOS implementation of MQC’s class-default does not (at the time of writing) function compatibly with mainline IOS; class-default should apply a policy to all other traffic not explicitly defined, but testing has shown that this is not the case.
• • •
•
•
Enterprise QoS Solution Reference Network Design Guide
2-20
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2950—QoS Considerations and Design
Example 2-3
Catalyst 2950—Untrusted Multi-Application Server with Scavenger-Class QoS Model Configuration
CAT2950(config)#class-map SAP CAT2950(config-cmap)# match access-group name SAP CAT2950(config-cmap)#class-map LOTUS CAT2950(config-cmap)# match access-group name LOTUS CAT2950(config-cmap)#class-map IMAP CAT2950(config-cmap)# match access-group name IMAP CAT2950(config-cmap)#exit CAT2950(config)# CAT2950(config)#policy-map UNTRUSTED-SERVER CAT2950(config-pmap)# class SAP CAT2950(config-pmap-c)# set ip dscp 18 ! DSCP 25 is not supported CAT2950(config-pmap-c)# police 15000000 8192 exceed-action dscp 8 ! Out-of-profile Mission-Critical is marked down to Scavenger (CS1) CAT2950(config-pmap-c)# class LOTUS CAT2950(config-pmap-c)# set ip dscp 18 ! Transactional is marked AF21 CAT2950(config-pmap-c)# police 35000000 8192 exceed-action dscp 8 ! Out-of-profile Transactional Data is marked down to Scavenger (CS1) CAT2950(config-pmap-c)# class IMAP CAT2950(config-pmap-c)# set ip dscp 10 ! Bulk Data is marked AF11 CAT2950(config-pmap-c)# police 50000000 8192 exceed-action dscp 8 ! Out-of-profile Bulk Data is marked down to Scavenger (CS1) CAT2950(config-pmap-c)#exit CAT2950(config-pmap)#exit CAT2950(config)# CAT2950(config)#interface FastEthernet0/1 CAT2950(config-if)# mls qos cos override ! Untrusted CoS is remarked to 0 CAT2950(config-if)# service-policy input UNTRUSTED-SERVER CAT2950(config-if)#exit CAT2950(config)# CAT2950(config)#ip access list extended SAP CAT2950(config-ext-nacl)# permit tcp any eq 3200 any CAT2950(config-ext-nacl)# permit tcp any eq 3201 any CAT2950(config-ext-nacl)# permit tcp any eq 3202 any CAT2950(config-ext-nacl)# permit tcp any eq 3203 any CAT2950(config-ext-nacl)# permit tcp any eq 3600 any CAT2950(config-ext-nacl)# CAT2950(config-ext-nacl)#ip access list extended LOTUS CAT2950(config-ext-nacl)# permit tcp any eq 1352 any CAT2950(config-ext-nacl)# CAT2950(config-ext-nacl)#ip access list extended IMAP CAT2950(config-ext-nacl)# permit tcp any eq 143 any CAT2950(config-ext-nacl)# permit tcp any eq 220 any CAT2950(config-ext-nacl)#end CAT2950#
Catalyst MLS QoS Verification Commands
This section includes the following Catalyst MLS verification commands:
• • •
show mls qos interface policers show class-map and show policy-map show mls masks qos
show mls qos interface policers
The show mls qos interface policers verification command reports all configured policers attached to the specified interface.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-21
Chapter 2 Catalyst 2950—QoS Considerations and Design
Campus QoS Design
In the following example, the policers defined for Mission-Critical data, Transactional Data and Bulk data which are applied to FastEthernet 0/1 are confirmed.
Example 2-4 Show MLS QoS Interface Policers Verification of a Switchport Connected to an Untrusted Multi-Application Server
CAT2950#show mls qos interface FastEthernet0/1 policers FastEthernet0/1 policymap=UNTRUSTED-SERVER type=Single rate=15000000, burst=8192 ! Mission-Critical Data Policer type=Single rate=35000000, burst=8192 ! Transactional Data Policer type=Single rate=50000000, burst=8192 ! Bulk Data Policer CAT2950#
show class-map and show policy-map
The show class-map and show policy-map verification commands will report the class-map and policy-maps that have been globally configured (regardless of whether or not they’ve been applied to an interface). In the following example, the class-maps for SAP, LOTUS and IMAP are displayed, as is the policy-map UNTRUSTED-SERVER that is referencing these.
Example 2-5 Show Class-Map and Show Policy-Map Verification of a Switch Connected to an Untrusted Multi-Application Server
CAT2950#show class-map Class Map match-all IMAP (id 3) Match access-group name IMAP Class Map match-any class-default (id 0) Match any Class Map match-all SAP (id 1) Match access-group name SAP Class Map match-all LOTUS (id 2) Match access-group name LOTUS CAT2950#show policy-map Policy Map UNTRUSTED-SERVER class SAP set ip dscp 18 police 15000000 8192 exceed-action dscp 8 class LOTUS set ip dscp 18 police 35000000 8192 exceed-action dscp 8 class IMAP set ip dscp 10 police 50000000 8192 exceed-action dscp 8 CAT2950#
show mls masks qos
The show mls masks qos verification command is helpful in keeping track of the number of user-defined or system-defined masks that are being applied by access list entries that are referenced by MQC class-maps.
Enterprise QoS Solution Reference Network Design Guide
2-22
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2950—QoS Considerations and Design
In the example below, the ACEs being referenced by QoS policies are using IP protocol masks, including (TCP/UDP) source ports.
Example 2-6 Show MLS Masks QoS Verification of an Untrusted Multi-Application Server Model
CAT2950#show mls masks qos Mask1 Type : qos Fields : ip-proto, src-port Policymap : UNTRUSTED-SERVER Interfaces : Fa0/1 CAT2950#
Catalyst 2950—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
When configuring an access-switch to trust/conditionally-trust CoS, then the default mapping for CoS 5 should be adjusted to point to DSCP EF (46), instead of DSCP CS5 (40). This modification is shown below.
Example 2-7 Catalyst 2950—CoS-to-DSCP Marking Modification for Voice
! Maps CoS 5 to EF
CAT2950(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56 CAT2950(config)#
Note
Adjusting the default CoS-to-DSCP mapping for call signaling (which formerly was mapped from CoS 3 to DSCP AF31/26) is no longer required. This is because the default mapping of CoS 3 points to DSCP CS3 (24), which is the call signaling marking that all Cisco IP Telephony devices markings will migrate to.
Catalyst MLS QoS Verification Commands
The show mls qos map [cos-dscp | dscp-cos] verification command returns the DSCP-to-CoS and CoS-to-DSCP mappings. These mappings may be either the default mappings or manually configured overrides. In the example below, the default mapping for CoS 5 (DSCP CS5) has been modified to point to DSCP EF instead.
Example 2-8 Show MLS QoS Map Verification for a Catalyst 2950 Switch
CAT2950#show mls qos map Dscp-cos map: dscp: 0 8 10 16 18 24 26 32 34 40 46 48 56 -----------------------------------------------
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-23
Chapter 2 Catalyst 2950—QoS Considerations and Design
Campus QoS Design
cos: 0 1 1 2 2 3 3 4 Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------dscp: 0 8 16 24 32 46 48 56 CAT2950#
4
5
5
6
7
! CoS 5 is now mapped to DSCP EF
The Catalyst 2950’s hardware policers lack the granularity to implement the Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model, as illustrated in Figure 2-8. However, they can implement a simplified version of this model, as shown in Figure 2-11.
Figure 2-11 Catalyst 2950—Conditionally-Trusted Endpoint Policing: IP Phone + PC with Scavenger-Class QoS (Basic) Model
VVLAN ANY Yes Yes
Start
1 Mbps No
Trust and Transmit
Drop
No DVLAN ANY Yes Yes Re-Mark to DSCP 0 and Transmit Re-Mark to DSCP CS1 and Transmit
224808
5 Mbps No
It should be kept in mind that the coarse granularity of the Catalyst 2950’s policers (which are configured in 1 Mbps minimum increments on FastEthernet interfaces) could potentially allow up to 1 Mbps of traffic mimicking legitimate voice traffic per conditionally-trusted switchport. The configuration for configuring a switchport to conditionally trust an IP Phone that has a PC connected to it, with Scavenger-class QoS, is shown below.
Example 2-9 Catalyst 2950—Conditionally Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model
CAT2950(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56 ! Maps CoS 5 to EF CAT2950(config)# CAT2950(config)#class-map VVLAN-ANY CAT2950(config-cmap)# match access-group name VVLAN-ANY CAT2950(config-cmap)#class-map DVLAN-ANY CAT2950(config-cmap)# match access-group name DVLAN-ANY CAT2950(config-cmap)#exit CAT2950(config)# CAT2950(config)#policy-map IPPHONE+PC CAT2950(config-pmap)# class VVLAN-ANY CAT2950(config-pmap-c)# police 1000000 8192 exceed-action drop ! Out-of-profile traffic from the VVLAN is dropped CAT2950(config-pmap-c)# class DVLAN-ANY CAT2950(config-pmap-c)# set ip dscp 0 ! Optional remarking in case the trust boundary is compromised CAT2950(config-pmap-c)# police 5000000 8192 exceed-action dscp 8 ! Out-of-profile data traffic is marked down to Scavenger CAT2950(config-pmap-c)#exit CAT2950(config-pmap)#exit CAT2950(config)# CAT2950(config)# CAT2950(config)#interface FastEthernet0/1 CAT2950(config-if)# switchport access vlan 10 CAT2950(config-if)# switchport voice vlan 110 CAT2950(config-if)# mls qos trust device cisco-phone ! Conditional trust CAT2950(config-if)# mls qos trust cos ! Trust CoS from IP Phone
Enterprise QoS Solution Reference Network Design Guide
2-24
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2950—QoS Considerations and Design
CAT2950(config-if)# service-policy input IPPHONE+PC CAT2950(config-if)#exit CAT2950(config)# CAT2950(config)#ip access list standard VVLAN-ANY CAT2950(config-std-nacl)# permit 10.1.110.0 0.0.0.255 CAT2950(config-std-nacl)# CAT2950(config-std-nacl)#ip access list standard DVLAN-ANY CAT2950(config-std-nacl)# permit 10.1.10.0 0.0.0.255 CAT2950(config-std-nacl)#end CAT2950#
! Policing policy
! VVLAN subnet
! DVLAN subnet
Other Catalyst MLS QoS verification commands include the following:
• • • • • •
show mls qos interface show mls qos interface policers show mls qos map show class-map show policy-map show mls masks qos
Catalyst 2950—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model
The advanced model of the Conditionally-Trusted IP Phone + PC with Scavenger-class QoS, as shown in Figure 2-9 and Figure 2-10, cannot be supported on the Catalyst 2950 because of the previously discussed caveats and limitations of the Catalyst 2950, including the maximum number of policers supported per FE interface, the overly coarse policer granularity, the inability to mix user-defined masks with system-defined masks and other constraints.
Catalyst 2950—Queuing
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
The Catalyst 2950 can be configured to operate in a 4Q1T mode or in a 1P3Q1T mode (with Queue 4 being configured as a strict-priority queue); the 1P3Q1T mode is recommended for converged networks. The strict priority queue is enabled by configuring the fourth queue’s weight parameter, as defined in the wrr-queue bandwidth command, to be 0 (as shown in the example below). The remaining bandwidth is allocated the other queues according to their defined weights. To allocate remaining bandwidths of 5%, 25% and 70% to Queues 1, 2 and 3, weights of 5, 25, 70 can be assigned these queues, respectively. The logic of these bandwidth allocations recommendations will be discussed in more detail momentarily.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-25
Chapter 2 Catalyst 2950—QoS Considerations and Design
Campus QoS Design
Note
Alternatively, as these weights are relative, they can be reduced by dividing each weight by the lowest common denominator (in this case 5) to arrive at queue weights of 1, 5 and 14 for Queues 1, 2 and 3 (respectively). Reduction is strictly optional and makes no difference to the servicing of the queues. Many network administrators tend to prefer defining bandwidth allocation ratios as percentages, and so bandwidth weight ratios aren’t reduced in this design chapter. So far, Campus QoS designs have been presented for the first half of the DoS/worm mitigation strategy discussed at the beginning of this chapter, namely, designs for access layer policers to mark down out-of-profile traffic to the Scavenger class PHB of CS1. The second vital component of this strategy is to map Scavenger class traffic into a “less-than Best-Effort” queuing structure, ensuring that all other traffic will be serviced ahead of it in the event of congestion. The Catalyst 2950, like most Catalyst platforms, supports the mapping of CoS values into queues. The CoS value that corresponds to Scavenger (DSCP CS1) is CoS 1; this CoS value is shared with Bulk data (DSCP AF11). Therefore, a small amount of bandwidth (5%) is allocated to the “less-than Best-Effort” queue: Q1. Q1 will thus service legitimate Bulk traffic but will constrain out-of-profile Scavenger traffic—which may be the result of a DoS/worm attack—to a small amount (<5%), in the event of congestion. The next queue, Q2, is then assigned to service Best Effort traffic. A previously discussed design principle regarding Best Effort bandwidth allocation is to allocate approximately 25% of a link’s bandwidth to service Best Effort traffic. In this manner the sheer volume of traffic that defaults to Best Effort will continue getting adequate bandwidth, both in the event of momentary campus congestion (due to bursts in the amount of legitimate traffic) and even in the case of a DoS/worm attack. Preferential applications, such as Transactional Data, Mission-Critical Data, Call-Signaling, Network/Internetwork Control and Management, as well as both Interactive and Streaming Video will be serviced by Q3. Q3 is allocated 70% of the remaining bandwidth (after the PQ has serviced its voice traffic). The recommended 1P3Q1T queuing model for the Catalyst 2950, along with CoS-to-Queue assignments is illustrated in Figure 2-12.
Enterprise QoS Solution Reference Network Design Guide
2-26
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2950—QoS Considerations and Design
Figure 2-12
Application Network Control
Catalyst 2950 1P3Q1T Queuing Model
DSCP CS6 EF AF41 CS4 DSCP 25 AF31/CS3 AF21 CS2 AF11 CS1 0 CoS CoS 7 CoS 5 CoS 6 CoS 5 CoS 7 CoS 4 CoS 4 CoS 3 CoS 3 CoS 2 CoS 2 CoS 2 CoS 1 CoS 0 CoS 1 0 CoS 1 Queue 2 (25%) CoS 6 Queue 3 (70%) Q4 Priority Queue 1P3Q1T
Internetwork Control Voice Interactive-Video Streaming-Video Mission-Critical Data Call-Signaling Transactional Data Network-Management Bulk Data Scavenger Best-Effort
CoS 4
CoS 3
Queue 1 (5%)
The configuration of the priority queue (Q4) and the bandwidth allocations for the remaining queues (Q1, Q2 & Q3) are shown below.
Example 2-10 Catalyst 2950 Scheduling Configuration—1P3Q1T Example
CAT2950(config)#wrr-queue bandwidth 5 25 70 0 CAT2950(config)# ! Q1-5%, Q2-25%, Q3-70%, Q4=PQ
Catalyst MLS QoS Verification Commands
This section includes the following commands:
• •
show wrr-queue bandwidth show wrr-queue cos-map
show wrr-queue bandwidth
The show wrr-queue bandwidth verification command displays the weights that have been assigned to the queues. If the command returns a value of 0 for the weight of the fourth queue, this indicates that the scheduler is operating in 1P3Q1T mode, with Q4 being the strict-priority queue. In the following example, the scheduler has been configured for 1P3Q1T queuing: Q1 gets 5% of the remaining bandwidth (after the priority queue has been fully-serviced), Q2 gets 25% and Q3 gets 70%.
Example 2-11 Show WRR-Queue Bandwidth Verification for a Catalyst 2950 Switch
CAT2950#show wrr-queue bandwidth WRR Queue : 1 2 3 4 Bandwidth : 5 25 70 0 CAT2950#
! Q1 gets 5%, Q2 gets 25%, Q3 gets 70%, Q4 is PQ
The CoS-to-Queue mapping configuration for the Catalyst 2950 is shown below.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
224809
Queue 1 (5%)
2-27
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
Example 2-12 Catalyst 2950 CoS-to-Queue Mapping Example
CAT2950(config)#wrr-queue CAT2950(config)#wrr-queue CAT2950(config)#wrr-queue CAT2950(config)#wrr-queue CAT2950(config)# cos-map cos-map cos-map cos-map 1 2 3 4 1 0 2 3 4 6 7 5 ! ! ! ! Scavenger/Bulk is assigned to Q1 Best Effort is assigned to Q2 CoS 2,3,4,6,7 are assigned to Q3 VoIP is assigned to Q4 (PQ)
show wrr-queue cos-map
The show wrr-queue cos-map verification command displayst he queue that each CoS value has been assigned to. In the example below, CoS 0 (Best Effort) is assigned to Q2 and CoS 1 (Scavenger) has been assigned to Q1. CoS values 2, 3, 4, 6 and 7 have all been assigned to Q3 and CoS 5 (Voice) has been assigned to the priority-queue, Q4.
Example 2-13 Show WRR-Queue CoS Map Verification for a Catalyst 2950 Switch
CAT2950#show wrr-queue cos-map CoS Value : 0 1 2 3 4 Priority Queue : 2 1 3 3 3 CAT2950#
5 4
6 3
7 3
Catalyst 3550—QoS Considerations and Design
This section includes the following topics:
• • • • • • •
Catalyst 3550—Trusted Endpoint Model Catalyst 3550—AutoQoS VoIP Model Catalyst 3550—Untrusted PC + SoftPhone with Scavenger-Class QoS Model Catalyst 3550—Untrusted Server with Scavenger-Class QoS Model Catalyst 3500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Catalyst 3550—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model Catalyst 3550—Queuing and Dropping
The Catalyst 3550 supports IP routing and so may be found in either the access or distribution layer of the campus. Regarding QoS, the Catalyst 3550 supports a richer feature set than the Catalyst 2950, including an advanced policing feature that is ideal for out-of-profile policing, namely, per-port/per-VLAN policing. The access layer design options and distribution layer design recommendations for a Catalyst 3550 are shown in Figure 2-13 and Figure 2-14, respectively.
Enterprise QoS Solution Reference Network Design Guide
2-28
Version 3.3
Chapter 2
Campus QoS Design Catalyst 3550—QoS Considerations and Design
Figure 2-13
Access Layer Catalyst 3550 QoS Design Options
Access-Edges
Trusted-Endpoint Model AutoQoS–VoIP Model PC + SoftPhone + Scavenger Model Untrusted Server + Scavenger Model IP Phone + PC + Scavenger (Basic) Model IP Phone + PC + Scavenger (Adv) Model 1P3Q1T Queuing 1P3Q1T Queuing 1P3Q1T Queuing Trust-DSCP 1P3Q1T Queuing 1P3Q1T Queuing 1P3Q1T Queuing
132547
Uplinks to Distribution Layer
1P3Q2T Queuing + WRED
Enable QoS Globally
Figure 2-14
Enable QoS Globally
Distribution Layer Catalyst 3550 QoS Design
1P3Q2T Queuing + WRED
224811
Trust-DSCP
Interswitch Links
An important point to remember about the Catalyst 3550 is that QoS is disabled by default and must be enabled globally for configured policies to become effective. While QoS is disabled, all frames/packets are passed through the switch unaltered (which is equivalent to a trust CoS and trust DSCP state on all ports). When QoS is globally enabled however, all DSCP and CoS values are (by default) set to 0 (which is equivalent to an untrusted state on all ports). The example below shows how to verify if QoS has been enabled or not and also how it can be globally enabled.
Example 2-14 Enabling QoS Globally on the Catalyst 3550
CAT3550#show mls qos QoS is disabled CAT3550#configure terminal Enter configuration commands, one per line. CAT3550(config)#mls qos CAT3550(config)#exit CAT3550# CAT3550#show mls qos QoS is enabled CAT3550#
! By default QoS is disabled
End with CNTL/Z. ! Enables QoS globally for the Cat3550
! Verifies that QoS is enabled globally
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-29
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
Note
Enabling QoS in the Catalyst 3550 may (depending on the software version) require the disabling of IEEE 802.3X flow control on all interfaces (if enabled). Flowcontrol can be disabled on an interface by using the interface commands: flowcontrol receive off and flowcontrol send off.
Catalyst 3550—Trusted Endpoint Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
Configuring a Catalyst 3550 switchport to trust an endpoint is identical to the configuration required on a Catalyst 2950, provided that QoS has been globally enabled on the Catalyst 3550. Configuration is shown below.
Example 2-15 Catalyst 3550—Trusted Endpoint
CAT3550(config)#interface FastEthernet0/1 CAT3550(config-if)#mls qos trust dscp
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for the trusted endpoint model include the following:
• •
show mls qos show mls qos interface
Catalyst 3550—AutoQoS VoIP Model
The Catalyst 3550 supports AutoQoS VoIP with the following keyword options:
• • •
auto qos voip cisco-phone auto qos voip cisco-softphone auto qos voip trust
When you enable AutoQoS VoIP on the Catalyst 3550 by using the auto qos voip cisco-phone, the auto qos voip cisco-softphone, or the auto qos voip trust interface configuration command, the switch automatically generates a QoS configuration based on the traffic type and ingress packet label and applies the commands listed in Table 2-2 to the interface.
Enterprise QoS Solution Reference Network Design Guide
2-30
Version 3.3
Chapter 2
Campus QoS Design Catalyst 3550—QoS Considerations and Design
Table 2-2
Catalyst 3550 Auto-QoS Generated Configuration
Description
Automatically Generated Command
The switch automatically enables standard C3550(config)# mls qos C3550(config)# mls qos map cos-dscp 0 8 16 26 32 QoS and configures the CoS-to-DSCP 46 48 56 map (maps CoS values in incoming packets to a DSCP value). If 10/100 Ethernet ports are present, the switch automatically configures the buffer size of the minimum-reserve levels 5, 6, 7, and 8:
• • • •
C3550(config)# C3550(config)# C3550(config)# C3550(config)# mls mls mls mls qos qos qos qos min-reserve min-reserve min-reserve min-reserve 5 6 7 8 170 85 51 34
Level 5 can hold 170 packets. Level 6 can hold 85 packets. Level 7 can hold 51 packets. Level 8 can hold 34 packets.
C3550(config-if)# mls qos trust cos If you entered the auto qos voip trust C3550(config-if)# mls qos trust dscp command, the switch automatically sets the ingress classification to trust the CoS value received in the packet on a nonrouted port or to trust the DSCP value received in the packet on a routed port.
If you entered the auto qos voip cisco-phone command, the switch automatically enables the trusted boundary feature which uses the CDP to detect the presence or absence of a Cisco IP Phone. If you entered the auto qos voip cisco-softphone command, the switch automatically creates class maps and policy maps.
C3550(config-if)# mls qos trust device cisco-phone
C3550(config)# mls qos map policed-dscp 24 26 46 to 0 C3550(config)# class-map match-all AutoQoS-VoIP-RTP-Trust C3550(config-cmap)# match ip dscp 46 C3550(config)# class-map match-all AutoQoS-VoIP-Control-Trust C3550(config-cmap)# match ip dscp 24 26 C3550(config)# policy-map AutoQoS-Police-SoftPhone C3550(config-pmap)# class AutoQoS-VoIP-RTP-Trust C3550(config-pmap-c)# set dscp 46 C3550(config-pmap-c)# police 320000 8000 exceed-action policed-dscp-transmit C3550(config-pmap)# class AutoQoS-VoIP-Control-Trust C3550(config-pmap-c)# set dscp 24 C3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
After creating the class maps and policy C3550(config-if)# service-policy input maps, the switch automatically applies the AutoQoS-Police-SoftPhone policy map called AutoQoS-Police-SoftPhone to an ingress interface on which auto-QoS with the Cisco SoftPhone feature is enabled.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-31
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
Table 2-2
Catalyst 3550 Auto-QoS Generated Configuration
C3550(config-if)# C3550(config-if)# C3550(config-if)# C3550(config-if)# C3550(config-if)# C3550(config-if)# C3550(config-if)# wrr-queue bandwidth 10 20 70 1 no wrr-queue cos-map wrr-queue cos-map 1 0 1 wrr-queue cos-map 2 2 4 wrr-queue cos-map 3 3 6 7 wrr-queue cos-map 4 5 priority-queue out
The switch automatically assigns egress queue usage on this interface. The switch enables the egress expedite queue and assigns WRR weights to queues 1, 2, and 3. (The lowest value for a WRR queue is 1and is the recommended setting for Q4 when it is operating as an expedite queue.) The switch configures the CoS-to-egress-queue map:
• • • •
CoS values 0 and 1 select queue 1. CoS values 2 and 4 select queue 2. CoS values 3, 6, and 7 select queue 3. CoS value 5 selects queue 4 (expedite queue).
Because the expedite queue (queue 4) contains the VoIP data traffic, the queue is serviced until empty. On Gigabit-capable Ethernet ports only, the switch automatically configures the ratio of the sizes of the WRR egress queues:
• • • •
C3550(config-if)# wrr-queue queue-limit 50 25 15 10
Queue 1 is 50 percent. Queue 2 is 25 percent. Queue 3 is 15 percent. Queue 4 is 10 percent.
C3550(config-if)# C3550(config-if)# C3550(config-if)# C3550(config-if)# wrr-queue wrr-queue wrr-queue wrr-queue min-reserve min-reserve min-reserve min-reserve 1 2 3 4 5 6 7 8
On 10/100 Ethernet ports only, the switch automatically configures minimum-reserve levels for the egress queues:
• • • •
Queue 1 selects the minimum-reserve level 5. Queue 2 selects the minimum-reserve level 6. Queue 3 selects the minimum-reserve level 7. Queue 4 selects the minimum-reserve level 8.
Enterprise QoS Solution Reference Network Design Guide
2-32
Version 3.3
Chapter 2
Campus QoS Design Catalyst 3550—QoS Considerations and Design
Catalyst 3550—Untrusted PC + SoftPhone with Scavenger-Class QoS Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
Unlike the Catalyst 2950, the Catalyst 3550 has all the necessary QoS features to support and enforce the Untrusted PC + SoftPhone + Scavenger model, as illustrated in Figure 2-4. The Catalyst 3550 configuration for this access edge model is shown below.
Example 2-16 Catalyst 3550—Untrusted PC + SoftPhone + Scavenger Model Configuration
CAT3550(config)#mls qos map policed-dscp 0 24 46 to 8 ! Excess traffic marked 0 or CS3 or EF will be remarked to CS1 CAT3550(config)# CAT3550(config)#class-map match-all SOFTPHONE-VOICE CAT3550(config-cmap)# match access-group name SOFTPHONE-VOICE CAT3550(config-cmap)#class-map match-all SOFTPHONE-SIGNALING CAT3550(config-cmap)# match access-group name SOFTPHONE-SIGNALING CAT3550(config-cmap)#exit CAT3550(config)# CAT3550(config)#policy-map SOFTPHONE-PC CAT3550(config-pmap)#class SOFTPHONE-VOICE CAT3550(config-pmap-c)# set ip dscp 46 ! Softphone VoIP is marked to DSCP EF CAT3550(config-pmap-c)# police 128000 8000 exceed-action policed-dscp-transmit ! Out-of-profile SoftPhone voice traffic is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class SOFTPHONE-SIGNALING CAT3550(config-pmap-c)# set ip dscp 24 ! Signaling is marked to DSCP CS3 CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Out-of-profile Signaling traffic is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class class-default CAT3550(config-pmap-c)# set ip dscp 0 CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT3550(config-pmap-c)# exit CAT3550(config-pmap)#exit CAT3550(config)# CAT3550(config)#interface FastEthernet0/1 CAT3550(config-if)# service-policy input SOFTPHONE-PC ! Applies policy to int CAT3550(config-if)#exit CAT3550(config)# CAT3550(config)#ip access list extended SOFTPHONE-VOICE CAT3550(config-ext-nacl)# permit udp any any range 16384 32767 ! VoIP ports CAT3550(config-ext-nacl)# CAT3550(config-ext-nacl)#ip access list extended SOFTPHONE-SIGNALING CAT3550(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP ports CAT3550(config-ext-nacl)#end CAT3550#
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for untrusted PC + SoftPhone +Scavenger model include the following:
•
show mls qos
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-33
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
• • • • • • •
show mls qos map show mls qos interface show mls qos interface policers show mls qos statistics show class-map show policy-map show policy interface
show mls qos interface statistics
The show mls qos interface statistics verification command reports dynamic counters for a given policy, including how many packets were classified and policed by the policy. In the example below, untrusted packets from the PC are classified and policed according to the limits shown in Figure 2-4 for the Untrusted PC + SoftPhone + Scavenger access edge endpoint policing model.
Example 2-17 Show MLS QoS Interface Statistics Verification of a Catalyst 3550 Switchport Connected to an Untrusted PC + SoftPhone with Scavenger-Class QoS
CAT3550#show mls qos interface FastEthernet0/1 statistics FastEthernet0/1 Ingress dscp: incoming no_change classified policed dropped (in bytes) Others: 1275410698 31426318 1243984380 1674978822 0 Egress dscp: incoming no_change classified policed dropped (in bytes) Others: 7271494 n/a n/a 0 0 CAT3550#
show policy interface
The show policy interface verification command displays the policy maps (and related classes) that are attached to a given interface. In this example, a summary of the Untrusted PC + SoftPhone + Scavenger policing policy is shown as applied to FastEthernet0/1.
Example 2-18 Show Policy Interface Verification of a of a Catalyst 3550 Switchport Connected to an Untrusted PC + SoftPhone with Scavenger-Class QoS
CAT3550#show policy interface FastEthernet0/1 FastEthernet0/1 service-policy input: SOFTPHONE-PC class-map: SOFTPHONE-VOICE (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: access-group name SOFTPHONE-VOICEqm_police_inform_feature: CLASS_SHOW class-map: SOFTPHONE-SIGNALING (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: access-group name SOFTPHONE-SIGNALINGqm_police_inform_feature: CLASS_SHOW
Enterprise QoS Solution Reference Network Design Guide
2-34
Version 3.3
Chapter 2
Campus QoS Design Catalyst 3550—QoS Considerations and Design
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 bpsqm_police_inform_feature: CLASS_SHOW CAT3550#
Note
Currently, the counters reported via the show policy interface command on the Catalyst 3550 are not being incremented (i.e., all counters are currently frozen at zero), as is the case with the mainline IOS version of this command. A bug has been reported which, when fixed, should result in the counters incrementing dynamically. Catalyst 3550 IOS versions tested and affected with this bug include 12.1(19)EA1 a through c and 12.1(20)EA1.
Catalyst 3550—Untrusted Server with Scavenger-Class QoS Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
The Catalyst 3550 fully supports the Untrusted Multi-Application Server with Scavenger-Class QoS model, as depicted in Figure 2-5. The configuration for this model is shown below.
Example 2-19 Catalyst 3550—Untrusted Multi-Application Server with Scavenger-Class QoS Configuration
CAT3550(config)#mls qos map policed-dscp 0 10 18 25 to 8 ! Excess traffic marked 0 or AF11 or AF21 or DSCP 25 will be remarked to CS1 CAT3550(config)# CAT3550(config)#class-map SAP CAT3550(config-cmap)# match access-group name SAP CAT3550(config-cmap)#class-map LOTUS CAT3550(config-cmap)# match access-group name LOTUS CAT3550(config-cmap)#class-map IMAP CAT3550(config-cmap)# match access-group name IMAP CAT3550(config-cmap)#exit CAT3550(config)# CAT3550(config)#policy-map UNTRUSTED-SERVER CAT3550(config-pmap)#class SAP CAT3550(config-pmap-c)# set ip dscp 25 ! SAP is marked as Mission-Critical CAT3550(config-pmap-c)# police 15000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile SAP is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class LOTUS CAT3550(config-pmap-c)# set ip dscp 18 ! Lotus is marked as Transactional CAT3550(config-pmap-c)# police 35000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile LOTUS is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class IMAP CAT3550(config-pmap-c)# set ip dscp 10 ! IMAP is marked as Bulk Data CAT3550(config-pmap-c)# police 50000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile IMAP is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class class-default
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-35
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
CAT3550(config-pmap-c)# set ip dscp 0 CAT3550(config-pmap-c)# police 1000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile excess data traffic is marked down to Scavenger (CS1) CAT3550(config-pmap-c)# exit CAT3550(config-pmap)#exit CAT3550(config)# CAT3550(config)#interface FastEthernet0/1 CAT3550(config-if)# service-policy input UNTRUSTED-SERVER CAT3550(config-if)#exit CAT3550(config)# CAT3550(config)#ip access list extended SAP CAT3550(config-ext-nacl)# permit tcp any range 3200 3203 any CAT3550(config-ext-nacl)# permit tcp any eq 3600 any CAT3550(config-ext-nacl)# CAT3550(config-ext-nacl)#ip access list extended LOTUS CAT3550(config-ext-nacl)# permit tcp any eq 1352 any CAT3550(config-ext-nacl)# CAT3550(config-ext-nacl)#ip access list extended IMAP CAT3550(config-ext-nacl)# permit tcp any eq 143 any CAT3550(config-ext-nacl)# permit tcp any eq 220 any CAT3550(config-ext-nacl)#end CAT3550#
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for the Multi-Application Server+ Scavenger model include the following:
• • • • • • • •
show mls qos show mls qos map show mls qos interface show mls qos interface policers show mls qos statistics show class-map show policy-map show policy interface
Catalyst 3500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
The Catalyst 3550’s support of Per-Port/Per-VLAN policing makes for a distinct advantage over other platforms when provisioning a (Basic or Advanced) Conditionally-Trusted Endpoint Model. This is because Per-Port/Per-VLAN policies can be provisioned without having to enter subnet-specific information for each switch. This makes such policies more modular and portable.
Enterprise QoS Solution Reference Network Design Guide
2-36
Version 3.3
Chapter 2
Campus QoS Design Catalyst 3550—QoS Considerations and Design
In the following example, the VLAN 10 is the DVLAN and VLAN 110 is the VVLAN.
Note
Since the time of writing, newer versions of Catalyst 3550 switch software do not allow the configuration of a trust-statement in conjunction with a service-policy statement on a switch interface.
Example 2-20 Catalyst 3550—Conditionally-Trusted IP Phone + PC + Scavenger (Basic) Model Configuration
CAT3550(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56 ! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF CAT3550(config)#mls qos map policed-dscp 0 24 to 8 ! Excess DVLAN & VVLAN traffic will be remarked to Scavenger (CS1) CAT3550(config)# CAT3550(config)# CAT3550(config)#class-map match-all VOICE CAT3550(config-cmap)# match ip dscp 46 ! DSCP EF (voice) CAT3550(config-cmap)#class-map match-any CALL SIGNALING ! Need ‘match-any’ here CAT3550(config-cmap)# match ip dscp 26 ! DSCP AF31 (old Call-Signaling) CAT3550(config-cmap)# match ip dscp 24 ! DSCP CS3 (new Call-Signaling) CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all VVLAN-VOICE CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN CAT3550(config-cmap)# match class-map VOICE ! Matches VVLAN DSCP EF CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN CAT3550(config-cmap)# match class-map CALL SIGNALING !Matches VVLAN AF31/CS3 CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all ANY CAT3550(config-cmap)# match access-group name ANY ! Workaround ACL CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all VVLAN-ANY CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN CAT3550(config-cmap)# match class-map ANY ! Matches any other VVLAN traffic CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all DVLAN-ANY CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN CAT3550(config-cmap)# match class-map ANY ! Matches all DVLAN traffic CAT3550(config-cmap)# CAT3550(config-cmap)#policy-map IPPHONE+PC-BASIC CAT3550(config-pmap)#class VVLAN-VOICE CAT3550(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice) CAT3550(config-pmap-c)# police 128000 8000 exceed-action drop ! Only one voice call is permitted per switchport VVLAN CAT3550(config-pmap-c)#class VVLAN-CALL-SIGNALING CAT3550(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling) CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Out-of-profile call signaling is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class VVLAN-ANY CAT3550(config-pmap-c)# set ip dscp 0 CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Unauthorized VVLAN traffic is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class DVLAN-ANY CAT3550(config-pmap-c)# set ip dscp 0 CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT3550(config-pmap-c)# exit CAT3550(config-pmap)#exit CAT3550(config)# CAT3550(config)#interface FastEthernet0/1 CAT3550(config-if)# switchport access vlan 10 ! DVLAN
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-37
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
CAT3550(config-if)# switchport voice vlan 110 CAT3550(config-if)# mls qos trust device cisco-phone CAT3550(config-if)# service-policy input IPPHONE+PC-BASIC CAT3550(config-if)#exit CAT3550(config)# CAT3550(config)# CAT3550(config)#ip access list standard ANY CAT3550(config-std-nacl)# permit any CAT3550(config-std-nacl)#end CAT3550#
! VVLAN ! Conditional Trust ! Attaches policy
! Workaround ACL
Catalyst MLS QoS Verification Commands
The Catalyst MLS QoS verification commands for the Conditionally-Trusted IP Phone + PC + Scavenger (Basic) Model Configuration include the following:
• • • • • • • •
show mls qos show mls qos map show mls qos interface show mls qos interface policers show mls qos statistics show class-map show policy-map show policy interface
Note
While Catalyst 3550 IOS syntax supports the match any criteria within a class-map (which the parser allows to be configured in conjunction with a per-VLAN policy), testing with some versions of Catalyst 3500 IOS have revealed a limitation with this function, since it does not match any other traffic on a per-VLAN basis. Hence an explicit access list named ANY has been used in the example above as a workaround.
Catalyst 3550—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
The Conditionally-Trusted IP Phone + PC + Scavenger Advanced model builds on the Basic model by including policers for PC-based video-conferencing (and/or PC SoftPhone), Mission-Critical Data applications, Transactional Data applications, and Bulk Data applications. This model is graphically depicted in Figure 2-9. The Catalyst 3550 can support 8 policers per 10/100 Ethernet port and so can support this Advanced Model.
Enterprise QoS Solution Reference Network Design Guide
2-38
Version 3.3
Chapter 2
Campus QoS Design Catalyst 3550—QoS Considerations and Design
The Catalyst 3550 configuration for the Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model is shown below. In this example, the same Server-to-Client applications are used as in the Untrusted Multi-Application Server example. However, notice that the Source/Destination ports are reversed for the Client-to-Server direction of traffic flow. Also, due to the limit of the number of policers per FastEthernet port (8), there is no explicit policer for SoftPhone call signaling traffic; to work around this limitation, SoftPhone call signaling traffic is included in the Mission-Critical Data applications access list .
Example 2-21 Catalyst 3550—Conditionally-Trusted IP Phone + PC + Scavenger (Advanced) Model Configuration
CAT3550(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56 ! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF CAT3550(config)#mls qos map policed-dscp 0 10 18 24 25 34 to 8 ! Excess DVLAN traffic marked 0, AF11, AF21, CS3, DSCP 25, ! and AF41 will be remarked to Scavenger (CS1) CAT3550(config)# CAT3550(config)#class-map match-all VOICE CAT3550(config-cmap)# match ip dscp 46 ! DSCP EF (voice) CAT3550(config-cmap)#class-map match-any CALL SIGNALING ! Need ‘match-any’ here CAT3550(config-cmap)# match ip dscp 26 ! DSCP AF31 (old Call-Signaling) CAT3550(config-cmap)# match ip dscp 24 ! DSCP CS3 (new Call-Signaling) CAT3550(config-cmap)#class-map match-all PC-VIDEO CAT3550(config-cmap)# match access-group name PC-VIDEO CAT3550(config-cmap)#class-map match-all MISSION-CRITICAL-DATA CAT3550(config-cmap)# match access-group name MISSION-CRITICAL-DATA CAT3550(config-cmap)#class-map match-all TRANSACTIONAL-DATA CAT3550(config-cmap)# match access-group name TRANSACTIONAL-DATA CAT3550(config-cmap)#class-map match-all BULK-DATA CAT3550(config-cmap)# match access-group name BULK-DATA CAT3550(config-cmap)#class-map match-all ANY CAT3550(config-cmap)# match access-group name ANY ! Workaround ACL CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all VVLAN-VOICE CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN CAT3550(config-cmap)# match class-map VOICE ! Matches VVLAN DSCP EF CAT3550(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN CAT3550(config-cmap)# match class-map CALL SIGNALING ! Matches VVLAN AF31/CS3 CAT3550(config-cmap)#class-map match-all VVLAN-ANY CAT3550(config-cmap)# match vlan 110 ! VLAN 110 is VVLAN CAT3550(config-cmap)# match class-map ANY ! Matches any other VVLAN traffic CAT3550(config-cmap)# CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all DVLAN-PC-VIDEO CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN CAT3550(config-cmap)# match class-map PC-VIDEO ! Matches PC IP/VC or SoftPhone CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all DVLAN-MISSION-CRITICAL-DATA CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN CAT3550(config-cmap)# match class-map MISSION-CRITICAL-DATA CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all DVLAN-TRANSACTIONAL-DATA CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN CAT3550(config-cmap)# match class-map TRANSACTIONAL-DATA CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all DVLAN-BULK-DATA CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN CAT3550(config-cmap)# match class-map BULK-DATA CAT3550(config-cmap)# CAT3550(config-cmap)#class-map match-all DVLAN-ANY CAT3550(config-cmap)# match vlan 10 ! VLAN 10 is DVLAN
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-39
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
CAT3550(config-cmap)# match class-map ANY ! Matches all other DVLAN traffic CAT3550(config-cmap)# CAT3550(config-cmap)# CAT3550(config-cmap)#policy-map IPPHONE+PC-ADVANCED CAT3550(config-pmap)#class VVLAN-VOICE CAT3550(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice) CAT3550(config-pmap-c)# police 128000 8000 exceed-action drop ! Only one voice call is permitted per switchport VVLAN CAT3550(config-pmap-c)#class VVLAN-CALL-SIGNALING CAT3550(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling) CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Out-of-profile call signaling is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class VVLAN-ANY CAT3550(config-pmap-c)# set ip dscp 0 CAT3550(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Unauthorized VVLAN traffic is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class DVLAN-PC-VIDEO CAT3550(config-pmap-c)# set ip dscp 34 ! DSCP AF41 (Interactive-Video) CAT3550(config-pmap-c)# police 500000 8000 exceed-action policed-dscp-transmit ! Only one IP/VC stream will be permitted per switchport CAT3550(config-pmap-c)#class DVLAN-MISSION-CRITICAL-DATA CAT3550(config-pmap-c)# set ip dscp 25 ! Interim Mission-Critical Data CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile Mission-Critical Data is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class DVLAN-TRANSACTIONAL-DATA CAT3550(config-pmap-c)# set ip dscp 18 ! DSCP AF21 (Transactional Data) CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile Transactional Data is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class DVLAN-BULK-DATA CAT3550(config-pmap-c)# set ip dscp 10 ! DSCP AF11 (Bulk Data) CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile Bulk Data is marked down to Scavenger (CS1) CAT3550(config-pmap-c)#class DVLAN-ANY CAT3550(config-pmap-c)# set ip dscp 0 CAT3550(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT3550(config-pmap-c)# exit CAT3550(config-pmap)#exit CAT3550(config)# CAT3550(config)#interface FastEthernet0/1 CAT3550(config-if)# switchport access vlan 10 ! DVLAN CAT3550(config-if)# switchport voice vlan 110 ! VVLAN CAT3550(config-if)# mls qos trust device cisco-phone ! Conditional Trust CAT3550(config-if)# service-policy input IPPHONE+PC-ADVANCED ! Attaches policy CAT3550(config-if)#exit CAT3550(config)# CAT3550(config)#ip access list standard ANY ! Workaround ACL CAT3550(config-std-nacl)# permit any CAT3550(config-std-nacl)# CAT3550(config-std-nacl)#ip access list extended PC-VIDEO ! IP/VC or SoftPhone CAT3550(config-ext-nacl)# permit udp any any range 16384 32767 CAT3550(config-ext-nacl)# CAT3550(config-ext-nacl)#ip access list extended MISSION-CRITICAL-DATA CAT3550(config-ext-nacl)# permit tcp any any range 3200 3203 ! SAP CAT3550(config-ext-nacl)# permit tcp any any eq 3600 ! SAP CAT3550(config-ext-nacl)# permit tcp any any range 2000 2002 ! SoftPhone SCCP CAT3550(config-ext-nacl)# CAT3550(config-ext-nacl)#ip access list extended TRANSACTIONAL-DATA CAT3550(config-ext-nacl)# permit tcp any any eq 1352 ! Lotus CAT3550(config-ext-nacl)# CAT3550(config-ext-nacl)#ip access list extended BULK-DATA CAT3550(config-ext-nacl)# permit tcp any any eq 143 ! IMAP CAT3550(config-ext-nacl)# permit tcp any any eq 220 ! IMAP CAT3550(config-ext-nacl)#end
Enterprise QoS Solution Reference Network Design Guide
2-40
Version 3.3
Chapter 2
Campus QoS Design Catalyst 3550—QoS Considerations and Design
CAT3550#
Catalyst MLS QoS Verification Commands
The Catalyst MLS QoS verification commands for Conditionally-Trusted IP Phone + PC + Scavenger (Advanced) Model include the following:
• • • • • • • •
show mls qos show mls qos map show mls qos interface show mls qos interface policers show mls qos statistics show class-map show policy-map show policy interface
Catalyst 3550—Queuing and Dropping
This section includes the following topics:
• • •
Configuration Advanced Tuning Options Catalyst MLS QoS Verification Commands
Configuration
Like the Catalyst 2950, the Catalyst 3550 supports a 1P3Q1T queuing model for all ports. GigabitEthernet ports have the additional option of being configured as 1P3Q2T, with either tail-drop or WRED thresholds. However, unlike the Catalyst 2950, the Catalyst 3550 queuing parameters are set on a per-interface basis and not globally. Nonetheless, uniform queuing policies can be expeditiously deployed via the interface range configuration command. The strict-priority queue is enabled on a per-interface basis on the Catalyst 3550 with the priority-queue out interface command. Bandwidth is allocated among the remaining queues via the wrr-queue bandwidth command. A twist with the Catalyst 3550 is that Queue 4’s WRR weight is set to 1 (indicating that it does not participate in the WRR scheduler since it is configured as a strict-priority queue), instead of 0 (as is the case on the Catalyst 2950). Recommended remaining bandwidth allocations (after the PQ has been fully serviced) are 5% for the Scavenger queue (Q1), 25% for the Best-Effort queue (Q2), and 70% for the preferential application queue (Q3). Following this, CoS 1 (Scavenger/Bulk) would be assigned to Q1; CoS 0 (Best Effort) would be assigned to Q2; CoS values 2 (Transactional Data and Network Management), 3 (call signaling and Mission-Critical Data), 4 (Interactive and Streaming-Video, 6 (Internetwork Control) and 7 (Network Control/Spanning-Tree) would be assigned to Q3; CoS 5 (voice) would be assigned to the strict-priority Q4. These assignments and allocations are illustrated in Figure 2-15 (the thresholds shown in Q1 and Q3 are discussed shortly).
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-41
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
Figure 2-15
Application Network Control
Catalyst 3550 1P3Q2T Queuing Model
DSCP CS6 EF AF41 CS4 DSCP 25 AF31/CS3 AF21 CS2 AF11 CS1 0 CoS CoS 7 CoS 5 CoS 6 CoS 5 CoS 7 CoS 4 CoS 4 CoS 3 CoS 3 CoS 2 CoS 2 CoS 2 CoS 1 CoS 0 CoS 1 0 CoS 1 Queue 2 (25%) CoS 6 Q3T1 Q4 Priority Queue 1P3Q2T
Internetwork Control Voice Interactive-Video Streaming-Video Mission-Critical Data Call-Signaling Transactional Data Network-Management Bulk Data Scavenger Best-Effort
Q3T2
CoS 4
Queue 3 (70%)
CoS 3
Q1T2 Q1T1
The interface-mode configuration commands to configure this 1P3Q1T queuing model, for either FastEthernet or GigabitEthernet Catalyst 3550 interfaces, are shown below.
Example 2-22 Catalyst 3550 FastEthernet and/or GigabitEthernet Interface Queuing Configuration—1P3Q1T
CAT3550(config)#interface range FastEthernet0/1 - 48 CAT3550(config-if)# wrr-queue bandwidth 5 25 70 1 CAT3550(config-if)# wrr-queue cos-map 1 1 CAT3550(config-if)# wrr-queue cos-map 2 0 CAT3550(config-if)# wrr-queue cos-map 3 2 3 4 6 7 CAT3550(config-if)# wrr-queue cos-map 4 5 CAT3550(config-if)# priority-queue out CAT3550(config-if)#exit CAT3550(config)#
! ! ! ! ! !
Q1-5% Q2-25% Q3-70% Q4=PQ Assigns Scavenger to Q1 Assigns Best Effort to Q2 Assigns CoS 2,3,4,6,7 to Q3 Assigns VoIP to Q4 (PQ) Enables Q4 as PQ
Advanced Tuning Options
The Catalyst 3550 offers some advanced “nerd-knob” queuing options on 10/100 interfaces, such as tuning Minimum Reserve Thresholds. However, testing has shown that such tuning, which rarely factors into play, makes a highly-negligible difference at best. Therefore, tuning Minimum Reserve Thresholds is recommended only for advanced network administrators or via automated tools, such as AutoQoS. Some advanced “nerd-knobs” also exist for GigabitEthernet interfaces. A couple of these advanced tuning options include Queue-Limit tuning and the enabling of WRED thresholds for 1P3Q2T operation. In the event of DoS/worm attacks, the GigabitEthernet uplinks will likely be the first to congest, therefore its worthwhile examining these advanced options. In the example below, the queue-limits for both GigabitEthernet interfaces are tuned to correspond to the WRR weights of the queues (the bandwidth allocations). This is achieved with the wrr-queue queue-limit interface command. However, unlike the WRR weight bandwidth ratio for Q4 (which is set to 1 to indicate that Q4 is a PQ), the queue limit for Q4 needs to be explicitly set to a more representative value, such as 30%.
Enterprise QoS Solution Reference Network Design Guide
2-42
224812
Queue 1 (5%)
Version 3.3
Chapter 2
Campus QoS Design Catalyst 3550—QoS Considerations and Design
Note
The default queue limits are such that each queue is assigned 25% of the available buffer space. It should be noted that when the queue limits are modified, the queue is temporarily shutdown during the hardware reconfiguration and the switch may drop newly-arrived packets destined to the queue. Thus, it may be advisable not to tune the queue limits on Catalyst 3550 switches already in production networks. Additionally, WRED is enabled on each (non-priority) queue. This allows for the preferential treatment of Bulk Data (DSCP AF11) over Scavenger (CS1) within Q1, as well as the preferential treatment of Internetworking/Networking protocols (DSCP CS6 and CS7, respectively) over all other applications assigned to Q3. Even though Q2 has only Best Effort traffic assigned to it, enabling WRED on this queue increases the efficiency of TCP applications within this queue during periods of congestion. A low WRED threshold, such as 40%, can be set for Q1 to aggressively drop Scavenger traffic in order to preferentially service Bulk Data. The WRED thresholds for Q2 and Q3 can be set to higher levels, such as 80%. By default all DSCP values are mapped to the first WRED threshold of the queue to which their CoS values are assigned. Therefore, only DSCP values that are to be mapped to the second WRED thresholds (of their respective queues) need to be manually configured. In this case, Bulk Data (DSCP AF11/10), Internetwork Control (DSCP CS6/48), and Network Control (DSCP CS7/56) all need to be explicitly mapped to the second WRED threshold via the wrr-queue dscp-map interface configuration command.
Note
Network control traffic in the campus primarily refers to Spanning Tree Protocol (STP) traffic, such as Bridge Protocol Data Units (BPDUs). While these Layer 2 Ethernet frames are marked CoS 7, they (obviously) do not have any capability to carry Layer 3 DSCP markings. Thus, it may seem moot to map DSCP CS7 (56) to a higher WRED threshold. However, it should be kept in mind that Catalyst switches generate Internal DSCP values for all frames (regardless of whether they are carrying IP or not). These Internal DSCP values are used for QoS decisions, such as WRED in this case. Therefore, since STP BPDU frames (marked CoS 7) generate an Internal DSCP value of 56, mapping DSCP 56 to the second threshold of Q3 provides preferential treatment for these important Layer 2 frames. The configuration for these tuning options, which are available only on GigabitEthernet interfaces on the Catalyst 3550, is shown below.
Example 2-23 Catalyst 3550 GigabitEthernet Interface Queuing and Dropping Configuration—1P3Q2T
CAT3550(config)#interface range GigabitEthernet 0/1 – 2 CAT3550(config-if-range)# wrr-queue bandwidth 5 25 70 1 ! Q1 gets 5% BW, Q2 gets 25% BW, Q3 gets 70% BW, Q4 is the PQ CAT3550(config-if-range)# wrr-queue queue-limit 5 25 40 30 ! Tunes buffers to 5% for Q1, 25% for Q2, 40% for Q3 and 30% for Q4 CAT3550(config-if-range)# wrr-queue random-detect max-threshold 1 40 100 ! Sets Q1 WRED threshold 1 to 40% and threshold 2 to 100% CAT3550(config-if-range)# wrr-queue random-detect max-threshold 2 80 100 ! Sets Q2 WRED threshold 1 to 80% and threshold 2 to 100% CAT3550(config-if-range)# wrr-queue random-detect max-threshold 3 80 100 ! Sets Q3 WRED threshold 1 to 80% and threshold 2 to 100% CAT3550(config-if)# wrr-queue cos-map 1 1 ! Assigns Scavenger to Q1 CAT3550(config-if)# wrr-queue cos-map 2 0 ! Assigns Best Effort to Q2 CAT3550(config-if)# wrr-queue cos-map 3 2 3 4 6 7 ! Assigns CoS 2,3,4,6,7 to Q3 CAT3550(config-if)# wrr-queue cos-map 4 5 ! Assigns VoIP to Q4 (PQ) CAT3550(config-if-range)# wrr-queue dscp-map 2 10 48 56 ! Maps Bulk Data (10), Routing (48) and Spanning Tree (Internal DSCP 56) ! to WRED threshold 2 of their respective queues – all other DSCP values ! are mapped (by default) to WRED threshold 1 of their respective queues CAT3550(config-if)# priority-queue out ! Enables Q4 as PQ
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-43
Chapter 2 Catalyst 3550—QoS Considerations and Design
Campus QoS Design
CAT3550(config-if-range)#end CAT3550#
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for queuing and dropping include the following:
• •
show mls qos interface buffers show mls qos interface queueing
show mls qos interface buffers
The show mls qos interface buffers verification command displays the queue sizes (as per-queue buffer allocation percentages of the total buffer space). Also the command displays if WRED has been enabled on a queue, and if so, it displays the first and second thresholds (as percentages of the queue’s depth). In the example below, the queue-limits are set to 5%, 25%, 40%, and 30% of the total queuing buffer space for Queues 1 through 4 (respectively). Additionally, WRED is enabled on queues 1 through 3 (but not Q4, as it is the priority queue). The first WRED threshold is set to 5% on Q1 and is set to 80% on queues 2 and 3.
Example 2-24 Show MLS QoS Interface Buffers Verification for a Catalyst 3550 Switch
CAT3550#show mls qos interface GigabitEthernet0/1 buffers GigabitEthernet0/1 Notify Q depth: qid-size 1 – 5 ! Q1 queue-limit is set to 5% of total buffer space 2 – 25 ! Q2 queue-limit is set to 25% of total buffer space 3 – 40 ! Q3 queue-limit is set to 40% of total buffer space 4 – 30 ! Q4 queue-limit is set to 30% of total buffer space qid WRED thresh1 thresh2 1 ena 40 100 ! WRED is enabled on Q1 – first threshold is set to 40% 2 ena 80 100 ! WRED is enabled on Q2 – first threshold is set to 80% 3 ena 80 100 ! WRED is enabled on Q3 – first threshold is set to 80% 4 dis 100 100 ! WRED is disabled on Q4 (as it is the PQ) CAT3550#
show mls qos interface queueing
The show mls qos interface queuing verification command displays the CoS-to-Queuing mappings that have been configured in addition to the bandwidth allocations per queue. On GigabitEthernet interfaces with WRED enabled, the output also includes the DSCP-to-WRED Threshold mappings. This information is displayed in a table form, with the first digit of the decimal DSCP value along the Y-Axis (in rows) and the second digit of the decimal DSCP value along the X-Axis (in columns). In the example below, the output verifies that the egress expedite queue (priority queue: Q4) is enabled. Also, the WRR Bandwidth Weights show that, of the remaining bandwidth, Q1 is allocated 5%, Q2 is allocated 25%, and Q3 is allocated 70%. Additionally, the DSCP-to-WRED table verifies that Bulk Data (AF11/10), Internetwork Control (DSCP CS6/48), and Network Control (DSCP CS7/56) are each mapped to the second WRED thresholds (T2) of their respective queues (as determined by the CoS-to-Queue mappings). Finally, the CoS-to-Queue map shows that CoS 0 (Best Effort) is assigned to Q2, CoS 1 (Scavenger) has been assigned to Q1, CoS values 2, 3, 4, 6 and 7 have all been assigned to Q3, and CoS 5 (Voice) has been assigned to the priority-queue, Q4.
Enterprise QoS Solution Reference Network Design Guide
2-44
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
Example 2-25 Show MLS QoS Interface Verification for a Catalyst 3550 Switch
CAT3550#show mls qos interface GigabitEthernet0/1 queueing GigabitEthernet0/1 Egress expedite queue: ena ! Q4 is enabled as a PQ wrr bandwidth weights: qid-weights 1 – 5 ! Q1 is allocated 5% 2 – 25 ! Q2 is allocated 25% 3 – 70 ! Q3 is allocated 70& 4 - 1 when expedite queue is disabled Dscp-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 : 02 01 01 01 01 01 01 01 01 01 ! DSCP 10 is mapped to WRED T2 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 02 01 ! DSCP 48 is mapped to WRED T2 5 : 01 01 01 01 01 01 02 01 01 01 ! DSCP 56 is mapped to WRED T2 6 : 01 01 01 01 Cos-queue map: cos-qid 0 – 2 ! Best-Effort is assigned to Q2 1 – 1 ! Scavenger and Bulk are assigned to Q1 2 – 3 ! Transactional Data and Network Management are assigned to Q3 3 – 3 ! Mission-Critical Data and call signaling are assigned to Q3 4 – 3 ! Interactive- and Streaming-Video are assigned to Q3 5 – 4 ! Voice is assigned to the priority queue: Q4 6 – 3 ! Internetwork Control (Routing) is assigned to Q3 7 – 3 ! Network Control (Spanning Tree) is assigned to Q3 CAT3550#
Catalyst 2970/3560/3750—QoS Considerations and Design
This section includes the following topics:
• • • • • • •
Catalyst 2970/3560/3750—Trusted Endpoint Model Catalyst 2970/3560/3750—Auto QoS VoIP Model Catalyst 2970/3560/3750—Untrusted PC + SoftPhone with Scavenger-Class QoS Model Catalyst 2970/3560/3750—Untrusted Server with Scavenger-Class QoS Model Catalyst 2970/3560/3750—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Catalyst 2970/3560/3750—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model Catalyst 2970/3560/3750—Queuing and Dropping
The Catalyst 2970 does not support Layer 3 routing and, as such, is restricted to the role of an access-layer switch. The 3560 does support Layer 3 routing as well as inline power— a feature that is rarely, if ever, required at the distribution layer—and so is only considered in an access-layer context. The Catalyst 3750 also supports Layer 3 routing and may be found in either the access layer or the distribution layer. Figure 2-16 shows the QoS design options for access-layer Catalyst 2970s, 3560s, or 3750s, and Figure 2-17 shows the QoS design recommendations for a distribution-layer Catalyst 3750.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-45
Chapter 2 Catalyst 2970/3560/3750—QoS Considerations and Design
Campus QoS Design
Figure 2-16
Access Layer Catalyst 2970/3560/3750 QoS Design Options
Access-Edges
Trusted-Endpoint Model AutoQoS–VoIP Model PC + SoftPhone + Scavenger Model Untrusted Server + Scavenger Model IP Phone + PC + Scavenger (Basic) Model IP Phone + PC + Scavenger (Adv) Model 1P3Q3T Queuing + WTD 1P3Q3T Queuing + WTD 1P3Q3T Queuing + WTD Trust-DSCP 1P3Q3T Queuing + WTD 1P3Q3T Queuing + WTD 1P3Q3T Queuing + WTD
132548 224814
Uplinks to Distribution Layer
1P3Q3T Queuing + WTD
Enable QoS Globally
Figure 2-17
Enable QoS Globally
Distribution Layer Catalyst 3750 QoS Design
1P3Q3T Queuing + WTD
Trust-DSCP
Interswitch Links
Since the QoS features and configuration syntax are identical for the Catalyst 2970, 3560 and 3750, from a QoS design recommendation perspective, they are subsequently addressed as a single switch. As with the Catalyst 3550, QoS is globally disabled by default on the Catalyst 2970/3560/3750. While QoS is disabled, all frames/packets are passed-through the switch unaltered (which is equivalent to a trust CoS and trust DSCP state on all ports). When QoS is globally enabled, however, all DSCP and CoS values are (by default) set to 0 (which is equivalent to an untrusted state on all ports). QoS must be enabled globally for configured policies to become effective. The example below shows how to verify if QoS has been enabled or not and also how it can be globally enabled.
Example 2-26 Enabling QoS Globally on the Catalyst 2970/3560/3750
CAT2970#show mls qos QoS is disabled CAT2970#configure terminal Enter configuration commands, one per line. CAT2970(config)#mls qos CAT2970(config)#end CAT2970# CAT2970#show mls qos QoS is enabled CAT2970#
End with CNTL/Z.
Enterprise QoS Solution Reference Network Design Guide
2-46
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
Catalyst 2970/3560/3750—Trusted Endpoint Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
The Trusted Endpoint model configuration for the Catalyst 2970/3550 is identical to the switches previously discussed (namely, the Catalyst 2950 and 3550) and is shown below.
Example 2-27 Catalyst 2970/3560/3750—Trusted Endpoint Model Configuration
CAT2970(config)#interface GigabitEthernet0/1 CAT2970(config-if)#mls qos trust dscp
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for the Trusted Endpoint model include the following:
• •
show mls qos show mls qos interface
Catalyst 2970/3560/3750—Auto QoS VoIP Model
The Catalyst 2970/3560/3750 supports AutoQoS VoIP with the following keyword options:
• • •
auto qos voip cisco-phone auto qos voip cisco-softphone auto qos voip trust
When you enable AutoQoS VoIP on the Catalyst 2970/3560/3750 by using the auto qos voip cisco-phone, the auto qos voip cisco-softphone, or the auto qos voip trust interface configuration command, the switch automatically generates a QoS configuration based on the traffic type and ingress packet label and applies the commands listed in Table 2-3 to the interface.
Table 2-3
Catalyst 2970/3560/3750 Auto-QoS Generated Configuration
Description
Automatically Generated Command
The switch automatically enables standard C2970(config)# mls qos C2970(config)# mls qos map cos-dscp 0 8 16 26 32 QoS and configures the CoS-to-DSCP 46 48 56 map (maps CoS values in incoming packets to a DSCP value).
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-47
Chapter 2 Catalyst 2970/3560/3750—QoS Considerations and Design
Campus QoS Design
Table 2-3
Catalyst 2970/3560/3750 Auto-QoS Generated Configuration
C2970(config)# no mls qos srr-queue input cos-map C2970(config)# mls qos srr-queue input cos-map queue 1 threshold 3 0 C2970(config)# mls qos srr-queue input cos-map queue 1 threshold 2 1 C2970(config)# mls qos srr-queue input cos-map queue 2 threshold 1 2 C2970(config)# mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7 C2970(config)# mls qos srr-queue input cos-map queue 2 threshold 3 3 5 C2970(config)# no mls qos srr-queue output cos-map C2970(config)# mls qos srr-queue output cos-map queue 1 threshold 3 5 C2970(config)# mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7 C2970(config)# mls qos srr-queue output cos-map queue 3 threshold 3 2 4 C2970(config)# mls qos srr-queue output cos-map queue 4 threshold 2 1 C2970(config)# mls qos srr-queue output cos-map queue 4 threshold 3 0 C2970(config)# no mls qos srr-queue input dscp-map C2970(config)# mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15 C2970(config)# mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7 C2970(config)# mls qos srr-queue input dscp-map queue 1 threshold 3 32 C2970(config)# mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23 C2970(config)# mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48 C2970(config)# mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56 C2970(config)# mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63 C2970(config)# mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31 C2970(config)# mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47
The switch automatically maps CoS values to an ingress queue and to a threshold ID.
The switch automatically maps CoS values to an egress queue and to a threshold ID.
The switch automatically maps DSCP values to an ingress queue and to a threshold ID.
Enterprise QoS Solution Reference Network Design Guide
2-48
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
Table 2-3
Catalyst 2970/3560/3750 Auto-QoS Generated Configuration
C2970(config)# no mls qos srr-queue output dscp-map C2970(config)# mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47 C2970(config)# mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31 C2970(config)# mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55 C2970(config)# mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63 C2970(config)# mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23 C2970(config)# mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39 C2970(config)# mls qos srr-queue output dscp-map queue 4 threshold 1 8 C2970(config)# mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15 C2970(config)# mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7 C2970(config)# priority-queue C2970(config)# priority-queue C2970(config)# 90 10 C2970(config)# 8 16 C2970(config)# 34 66 C2970(config)# 33 no mls qos srr-queue input 1 no mls qos srr-queue input 2 mls qos srr-queue input bandwidth mls qos srr-queue input threshold 1 mls qos srr-queue input threshold 2 mls qos srr-queue input buffers 67
The switch automatically maps DSCP values to an egress queue and to a threshold ID.
The switch automatically sets up the ingress queues, with queue 2 as the priority queue and queue 1 in shared mode. The switch also configures the bandwidth and buffer size for the ingress queues.
The switch automatically configures the egress queue buffer sizes. It configures the bandwidth and the SRR mode (shaped or shared) on the egress queues mapped to the port.
C2970(config)# mls qos queue-set output 1 threshold 1 138 138 92 138 C2970(config)# mls qos queue-set output 1 threshold 2 138 138 92 400 C2970(config)# mls qos queue-set output 1 threshold 3 36 77 100 318 C2970(config)# mls qos queue-set output 1 threshold 4 20 50 67 400 C2970(config)# mls qos queue-set output 2 threshold 1 149 149 100 149 C2970(config)# mls qos queue-set output 2 threshold 2 118 118 100 235 C2970(config)# mls qos queue-set output 2 threshold 3 41 68 100 272 C2970(config)# mls qos queue-set output 2 threshold 4 42 72 100 242 C2970(config)# mls qos queue-set output 1 buffers 10 10 26 54 C2970(config)# mls qos queue-set output 2 buffers 16 6 17 61 C2970(config-if)# srr-queue bandwidth shape 10 0 0 0 C2970(config-if)# srr-queue bandwidth share 10 10 60 20
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-49
Chapter 2 Catalyst 2970/3560/3750—QoS Considerations and Design
Campus QoS Design
Table 2-3
Catalyst 2970/3560/3750 Auto-QoS Generated Configuration
C2970(config-if)# mls qos trust cos If you entered the auto qos voip trust C2970(config-if)# mls qos trust dscp command, the switch automatically sets the ingress classification to trust the CoS value received in the packet on a nonrouted port by using the mls qos trust cos command.
If you entered the auto qos voip cisco-phone command, the switch automatically enables the trusted boundary feature, which uses the CDP to detect the presence or absence of a Cisco IP Phone. If you entered the auto qos voip cisco-softphone command, the switch automatically creates class maps and policy maps.
C2970(config-if)# mls qos trust device cisco-phone
C2970(config)# mls qos map policed-dscp 24 26 46 to 0 C2970(config)# class-map match-all AutoQoS-VoIP-RTP-Trust C2970(config-cmap)# match ip dscp ef C2970(config)# class-map match-all AutoQoS-VoIP-Control-Trust C2970(config-cmap)# match ip dscp cs3 af31 C2970(config)# policy-map AutoQoS-Police-SoftPhone C2970(config-pmap)# class AutoQoS-VoIP-RTP-Trust C2970(config-pmap-c)# set dscp ef C2970(config-pmap-c)# police 320000 8000 exceed-action policed-dscp-transmit C2970(config-pmap)# class AutoQoS-VoIP-Control-Trust C2970(config-pmap-c)# set dscp cs3 C2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
After creating the class maps and policy C2970(config-if)# service-policy input maps, the switch automatically applies the AutoQoS-Police-SoftPhone policy map called AutoQoS-Police-SoftPhone to an ingress interface on which auto-QoS with the Cisco SoftPhone feature is enabled.
Catalyst 2970/3560/3750—Untrusted PC + SoftPhone with Scavenger-Class QoS Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
The Untrusted PC + SoftPhone + Scavenger model configuration for the Catalyst 2970/3560/3750 is identical to the Catalyst 3550 for the same access edge model and is shown below.
Enterprise QoS Solution Reference Network Design Guide
2-50
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
Example 2-28 Catalyst 2970/3560/3750—Untrusted PC + SoftPhone + Scavenger Model Configuration
CAT2970(config)#mls qos map policed-dscp 0 24 46 to 8 ! Excess traffic marked 0 or CS3 or EF will be remarked to CS1 CAT2970(config)# CAT2970(config)#class-map match-all SOFTPHONE-VOICE CAT2970(config-cmap)# match access-group name SOFTPHONE-VOICE CAT2970(config-cmap)#class-map match-all SOFTPHONE-SIGNALING CAT2970(config-cmap)# match access-group name SOFTPHONE-SIGNALING CAT2970(config-cmap)#exit CAT2970(config)# CAT2970(config)#policy-map SOFTPHONE-PC CAT2970(config-pmap)#class SOFTPHONE-VOICE CAT2970(config-pmap-c)# set ip dscp 46 ! Softphone VoIP is marked to DSCP EF CAT2970(config-pmap-c)# police 128000 8000 exceed-action policed-dscp-transmit ! Out-of-profile SoftPhone voice traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class SOFTPHONE-SIGNALING CAT2970(config-pmap-c)# set ip dscp 24 ! Signaling is marked to DSCP CS3 CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Out-of-profile Signaling traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class class-default CAT2970(config-pmap-c)# set ip dscp 0 CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)# exit CAT2970(config-pmap)#exit CAT2970(config)# CAT2970(config)#interface GigabitEthernet0/1 CAT2970(config-if)# service-policy input SOFTPHONE-PC ! Applies policy to int CAT2970(config-if)#exit CAT2970(config)# CAT2970(config)#ip access list extended SOFTPHONE-VOICE CAT2970(config-ext-nacl)# permit udp any any range 16384 32767 ! VoIP ports CAT2970(config-ext-nacl)# CAT2970(config-ext-nacl)#ip access list extended SOFTPHONE-SIGNALING CAT2970(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP ports CAT2970(config-ext-nacl)#end CAT2970#
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for the Untrusted PC + SoftPhone model include the following:
• • • • • • •
show mls qos show mls qos map show mls qos interface show mls qos interface policers show class-map show policy-map show policy interface
Catalyst 2970/3560/3750—Untrusted Server with Scavenger-Class QoS Model
This section includes the following topics:
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-51
Chapter 2 Catalyst 2970/3560/3750—QoS Considerations and Design
Campus QoS Design
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
The Untrusted Multi-Application Server model configuration for the Catalyst 2970/3560/3750 is identical to the Catalyst 3550 and is shown below.
Example 2-29 Catalyst 2970/3560/3750—Untrusted Multi-Application Server with Scavenger-Class QoS Model Configuration
CAT2970(config)#mls qos map policed-dscp 0 10 18 25 to 8 ! Excess traffic marked 0 or AF11 or AF21 or DSCP 25 will be remarked to CS1 CAT2970(config)# CAT2970(config)#class-map SAP CAT2970(config-cmap)# match access-group name SAP CAT2970(config-cmap)#class-map LOTUS CAT2970(config-cmap)# match access-group name LOTUS CAT2970(config-cmap)#class-map IMAP CAT2970(config-cmap)# match access-group name IMAP CAT2970(config-cmap)#exit CAT2970(config)# CAT2970(config)#policy-map UNTRUSTED-SERVER CAT2970(config-pmap)#class SAP CAT2970(config-pmap-c)# set ip dscp 25 ! SAP is marked as Mission-Critical CAT2970(config-pmap-c)# police 15000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile SAP is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class LOTUS CAT2970(config-pmap-c)# set ip dscp 18 ! Lotus is marked as Transactional CAT2970(config-pmap-c)# police 35000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile LOTUS is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class IMAP CAT2970(config-pmap-c)# set ip dscp 10 ! IMAP is marked as Bulk Data CAT2970(config-pmap-c)# police 50000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile IMAP is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class class-default CAT2970(config-pmap-c)# set ip dscp 0 CAT2970(config-pmap-c)# police 1000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile excess data traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)# exit CAT2970(config-pmap)#exit CAT2970(config)# CAT2970(config)#interface GigabitEthernet0/1 CAT2970(config-if)# service-policy input UNTRUSTED-SERVER CAT2970(config-if)#exit CAT2970(config)# CAT2970(config)#ip access list extended SAP CAT2970(config-ext-nacl)# permit tcp any range 3200 3203 any CAT2970(config-ext-nacl)# permit tcp any eq 3600 any CAT2970(config-ext-nacl)# CAT2970(config-ext-nacl)#ip access list extended LOTUS CAT2970(config-ext-nacl)# permit tcp any eq 1352 any CAT2970(config-ext-nacl)# CAT2970(config-ext-nacl)#ip access list extended IMAP CAT2970(config-ext-nacl)# permit tcp any eq 143 any CAT2970(config-ext-nacl)# permit tcp any eq 220 any CAT2970(config-ext-nacl)#end CAT2970#
Enterprise QoS Solution Reference Network Design Guide
2-52
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for the Untrusted Multi-Application Server model include the following:
• • • • • • •
show mls qos show mls qos map show mls qos interface show mls qos interface policers show class-map show policy-map show policy interface
Catalyst 2970/3560/3750—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
At the time of writing, the Catalyst 2970/3560/3750 does not fully support per-port/per-VLAN policing due to hardware restrictions. Therefore, access lists are required to match voice and signaling traffic sourced from the VVLAN. These ACLs require the administrator to specify the VVLAN subnet information. The configuration for a Conditionally-Trusted IP Phone and PC (Basic Model) for a Catalyst 2970/3560/3750 is shown below.
Example 2-30 Catalyst 2970/3560/3750—Conditionally-Trusted IP Phone + PC + Scavenger (Basic) Model Configuration
CAT2970(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56 ! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF CAT2970(config)#mls qos map policed-dscp 0 24 to 8 ! Excess VVLAN & DVLAN traffic will be remarked to Scavenger (CS1) CAT2970(config)# CAT2970(config)# CAT2970(config)#class-map match-all VVLAN-VOICE CAT2970(config-cmap)# match access-group name VVLAN-VOICE CAT2970(config-cmap)# CAT2970(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING CAT2970(config-cmap)# match access-group name VVLAN-CALL-SIGNALING CAT2970(config-cmap)# CAT2970(config-cmap)#class-map match-all VVLAN-ANY CAT2970(config-cmap)# match access-group name VVLAN-ANY CAT2970(config-cmap)# CAT2970(config-cmap)# CAT2970(config-cmap)#policy-map IPPHONE+PC-BASIC CAT2970(config-pmap)#class VVLAN-VOICE CAT2970(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice) CAT2970(config-pmap-c)# police 128000 8000 exceed-action drop
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-53
Chapter 2 Catalyst 2970/3560/3750—QoS Considerations and Design
Campus QoS Design
! Only one voice call is permitted per switchport VVLAN CAT2970(config-pmap-c)#class VVLAN-CALL-SIGNALING CAT2970(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling) CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Out-of-profile call signaling is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class VVLAN-ANY CAT2970(config-pmap-c)# set ip dscp 0 CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Unauthorized VVLAN traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class class-default CAT2970(config-pmap-c)# set ip dscp 0 CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)# exit CAT2970(config-pmap)#exit CAT2970(config)# CAT2970(config)# CAT2970(config)#interface GigabitEthernet0/1 CAT2970(config-if)# switchport access vlan 10 ! DVLAN CAT2970(config-if)# switchport voice vlan 110 ! VVLAN CAT2970(config-if)# service-policy input IPPHONE+PC-BASIC ! Attaches policy CAT2970(config-if)#exit CAT2970(config)# CAT2970(config)# CAT2970(config)#ip access list extended VVLAN-VOICE CAT2970(config-ext-nacl)#permit udp 10.1.110.0 0.0.0.255 any range 16384 32767 ! Voice is matched by VVLAN subnet and VoIP UDP port-range CAT2970(config-ext-nacl)#exit CAT2970(config)# CAT2970(config)#ip access list extended VVLAN-CALL-SIGNALING CAT2970(config-ext-nacl)#permit tcp 10.1.110.0 0.0.0.255 any range 2000 2002 ! Call Signaling is matched by VVLAN subnet and Call-Signaling TCP port-range(s) CAT2970(config-ext-nacl)#exit CAT2970(config)# CAT2970(config)#ip access list extended VVLAN-ANY CAT2970(config-ext-nacl)# permit ip 10.1.110.0 0.0.0.255 any ! Matches all other traffic sourced from the VVLAN subnet CAT2970(config-ext-nacl)#end CAT2970#
Note
At the time of writing, the Catalyst 2970/3560/3750 does not support a trust statement (such as mls qos trust device cisco-phone) in conjunction with a service-policy input statement applied to given port at the same time. While this may be configurable, if the switch is reset, one or the other statement may be removed when the switch reloads. This limitation is to be addressed; consult the latest Catalyst 2970/3560/3750 QoS documentation for updates on this limitation.
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for the Conditionally-Trusted IP Phone and PC with Scavenger-Class QoS (Basic) model include the following:
• • • •
show mls qos show mls qos map show mls qos interface show mls qos interface policers
Enterprise QoS Solution Reference Network Design Guide
2-54
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
• • •
show class-map show policy-map show policy interface
Catalyst 2970/3560/3750—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
Building on the previous model, PC applications such as Interactive Video, Mission-Critical Data, Transactional Data, and Bulk Data are identified by access lists. The configuration for the Conditionally-Trusted IP Phone + PC + Scavenger (Advanced) Model for the Catalyst 2970/3560/3750 is shown below.
Example 2-31 Catalyst 2970/3560/3750—Conditionally-Trusted IP Phone + PC + Scavenger (Advanced) Model Configuration
CAT2970(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56 ! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF CAT2970(config)#mls qos map policed-dscp 0 10 18 24 25 34 to 8 ! Excess DVLAN traffic marked 0, AF11, AF21, CS3, DSCP 25 ! and AF41 will be remarked to Scavenger (CS1) CAT2970(config)# CAT2970(config)# CAT2970(config)#class-map match-all VVLAN-VOICE CAT2970(config-cmap)# match access-group name VVLAN-VOICE CAT2970(config-cmap)# CAT2970(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING CAT2970(config-cmap)# match access-group name VVLAN-CALL-SIGNALING CAT2970(config-cmap)# CAT2970(config-cmap)#class-map match-all VVLAN-ANY CAT2970(config-cmap)# match access-group name VVLAN-ANY CAT2970(config-cmap)# CAT2970(config-cmap)#class-map match-all DVLAN-PC-VIDEO CAT2970(config-cmap)# match access-group name DVLAN-PC-VIDEO CAT2970(config-cmap)# CAT2970(config-cmap)#class-map match-all DVLAN-MISSION-CRITICAL-DATA CAT2970(config-cmap)# match access-group name DVLAN-MISSION-CRITICAL-DATA CAT2970(config-cmap)# CAT2970(config-cmap)#class-map match-all DVLAN-TRANSACTIONAL-DATA CAT2970(config-cmap)# match access-group name DVLAN-TRANSACTIONAL-DATA CAT2970(config-cmap)# CAT2970(config-cmap)#class-map match-all DVLAN-BULK-DATA CAT2970(config-cmap)# match access-group name DVLAN-BULK-DATA CAT2970(config-cmap)#exit CAT2970(config)# CAT2970(config)#policy-map IPPHONE+PC-ADVANCED CAT2970(config-pmap)#class VVLAN-VOICE CAT2970(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice) CAT2970(config-pmap-c)# police 128000 8000 exceed-action drop ! Only one voice call is permitted per switchport VVLAN
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-55
Chapter 2 Catalyst 2970/3560/3750—QoS Considerations and Design
Campus QoS Design
CAT2970(config-pmap-c)#class VVLAN-CALL-SIGNALING CAT2970(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling) CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Out-of-profile call signaling is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class VVLAN-ANY CAT2970(config-pmap-c)# set ip dscp 0 CAT2970(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit ! Unauthorized VVLAN traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class DVLAN-PC-VIDEO CAT2970(config-pmap-c)# set ip dscp 34 ! DSCP AF41 (Interactive-Video) CAT2970(config-pmap-c)# police 496000 8000 exceed-action policed-dscp-transmit ! Only one IP/VC stream will be permitted per switchport CAT2970(config-pmap-c)#class DVLAN-MISSION-CRITICAL-DATA CAT2970(config-pmap-c)# set ip dscp 25 ! Interim Mission-Critical Data CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile Mission-Critical Data is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class DVLAN-TRANSACTIONAL-DATA CAT2970(config-pmap-c)# set ip dscp 18 ! DSCP AF21 (Transactional Data) CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile Transactional Data is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class DVLAN-BULK-DATA CAT2970(config-pmap-c)# set ip dscp 10 ! DSCP AF11 (Bulk Data) CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile Bulk Data is marked down to Scavenger (CS1) CAT2970(config-pmap-c)#class class-default CAT2970(config-pmap-c)# set ip dscp 0 CAT2970(config-pmap-c)# police 5000000 8000 exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT2970(config-pmap-c)# exit CAT2970(config-pmap)#exit CAT2970(config)# CAT2970(config)#interface GigabitEthernet0/1 CAT2970(config-if)# switchport access vlan 10 ! DVLAN CAT2970(config-if)# switchport voice vlan 110 ! VVLAN CAT2970(config-if)# service-policy input IPPHONE+PC-ADVANCED ! Attaches Policy CAT2970(config-if)#exit CAT2970(config)# CAT2970(config)# CAT2970(config)#ip access list extended VVLAN-VOICE CAT2970(config-ext-nacl)#permit udp 10.1.110.0 0.0.0.255 any range 16384 32767 ! Voice is matched by VVLAN subnet and DSCP EF CAT2970(config-ext-nacl)#exit CAT2970(config)# CAT2970(config)#ip access list extended VVLAN-CALL-SIGNALING CAT2970(config-ext-nacl)#permit tcp 10.1.110.0 0.0.0.255 any range 2000 2002 ! Call Signaling is matched by VVLAN subnet Call-Signaling TCP port-range(s) CAT2970(config-ext-nacl)#exit CAT2970(config)# CAT2970(config)#ip access list extended VVLAN-ANY CAT2970(config-ext-nacl)# permit ip 10.1.110.0 0.0.0.255 any ! Matches all other traffic sourced from the VVLAN subnet CAT2970(config-ext-nacl)# CAT2970(config-ext-nacl)#ip access list extended DVLAN-PC-VIDEO CAT2970(config-ext-nacl)# permit udp any any range 16384 32767 ! IP/VC CAT2970(config-ext-nacl)# CAT2970(config-ext-nacl)#ip access list extended DVLAN-MISSION-CRITICAL-DATA CAT2970(config-ext-nacl)# permit tcp any any range 3200 3203 ! SAP CAT2970(config-ext-nacl)# permit tcp any any eq 3600 ! SAP CAT2970(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP CAT2970(config-ext-nacl)# CAT2970(config-ext-nacl)#ip access list extended DVLAN-TRANSACTIONAL-DATA CAT2970(config-ext-nacl)# permit tcp any any eq 1352 ! Lotus
Enterprise QoS Solution Reference Network Design Guide
2-56
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
CAT2970(config-ext-nacl)# CAT2970(config-ext-nacl)#ip access list extended DVLAN-BULK-DATA CAT2970(config-ext-nacl)# permit tcp any any eq 143 CAT2970(config-ext-nacl)# permit tcp any any eq 220 CAT2970(config-ext-nacl)#end CAT2970#
! IMAP ! IMAP
Note
At the time of writing, the Catalyst 2970/3560/3750 does not support a trust statement (such as mls qos trust device cisco-phone) in conjunction with a service-policy input statement applied to given port at the same time. While this may be configurable, if the switch is reset, one or the other statement may be removed when the switch reloads. This limitation is to be addressed; consult the latest Catalyst 2970/3560/3750 QoS documentation for updates on this limitation.
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for the Conditionally-Trusted IP Phone + PC + Scavenger (Advanced) Model include the following:
• • • • • • •
show mls qos show mls qos map show mls qos interface show mls qos interface policers show class-map show policy-map show policy interface
Catalyst 2970/3560/3750—Queuing and Dropping
This section includes the following topics:
• •
Configuration Catalyst MLS QoS Verification Commands
Configuration
For the most part, the Catalyst 2970/3560/3750 is relatively compatible in QoS features and syntax with the Catalyst 3550, except with respect to queuing and dropping. The Catalyst 2970/3560/3750 supports four egress queues, which can be configured on a per-interface basis to operate in either 4Q3T or 1P3Q3T modes. Additionally, the Catalyst 2970/3560/3750 supports two queue-sets, allowing certain interfaces to be configured in one manner and others to be configured in a different manner. For example, some interfaces may be assigned to Queue Set (qset) 1 operating in 4Q3T mode, while others may be assigned to Queue Set 2 operating in 1P3Q3T mode. However, unlike the Catalyst 2950 and 3550, the Catalyst 2970/3560/3750 has Queue 1 (not Queue 4) as the optional priority queue. In a converged campus environment it is recommended to enable the priority queue via the priority-queue out interface command.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-57
Chapter 2 Catalyst 2970/3560/3750—QoS Considerations and Design
Campus QoS Design
Note
The Catalyst 2970/3560/3750 also supports two configurable ingress queues (normal and expedite). Ingress scheduling, however, is rarely—if ever—required, as it only becomes enabled if the combined input rates from any/all switch ports exceed the switch fabric’s capacity. Such cases are extremely difficult to achieve, even in controlled lab environments. In the extreme case where such a scenario develops in a production environment, the default settings of the ingress queues are acceptable to maintain VoIP quality and network availability. The three remaining egress queues on the Catalyst 2970/3560/3750 are scheduled by a Shaped Round-Robin (SRR) algorithm, which can be configured to operate in shaped mode or in shared mode. In shaped mode, assigned bandwidth is limited to the defined amount; in shared mode, any unused bandwidth is shared among other classes (as needed). Shaped or Shared bandwidth weights can be assigned to a queue via the srr-queue bandwidth shape and srr-queue bandwidth share interface commands. Shaped mode weights override shared mode weights and use an inverse ratio (1/weight) to determine the shaping bandwidth for the queue. Furthermore, if shaped weights are set to 0, then the queue is operating in shared mode. For example, the following interface command srr-queue bandwidth shape 3 0 0 0 would shape Q1 to 1/3 of the available bandwidth and set all other queues to operate in sharing mode. To make the queuing structure consistent with examples provided for previously discussed platforms, Queues 2 through 4 should be set to operate in shared mode (which is the default mode of operation on Queues 2 through 4). The ratio of the shared weights determines the relative bandwidth allocations (the absolute values are meaningless). The ratio of the shared weights determines the relative bandwidth allocations (the absolute values are meaningless). Since the PQ of the Catalyst 2970/3560/3750 is Q1 (not Q4 as in the Catalyst 3550), the entire queuing model can be flipped upside down, with Q2 representing the Critical Data queue, Q3 representing the Best Effort queue, and Q4 representing the Scavenger/Bulk queue. Therefore, shared weights of 70, 25, and 5 can be assigned to Queues 2, 3, and 4, respectively. Additionally, the Catalyst 2970/3560/3750 supports three Weighted Tail Drop (WTD) thresholds per queue. Two of these thresholds are configurable (explicit); the third is non-configurable (implicit), as it is set to the queue-full state (100%). These thresholds can be defined with the mls qos queue-set output qset-id threshold global command. The only queues that these thresholds need defining (away from defaults) are Queues 2 and 4. In Queue 2, it is recommended to set the first threshold to 70% and the second to 80%, which leaves the third (implicit) threshold set at 100% (the tail of the queue). In Queue 4, it is recommended to set the first threshold to 40%, leaving the default values for both the second and third thresholds at 100%. Once the queues and thresholds have been defined, traffic can be assigned to queues and thresholds either by CoS values or DSCP values, using the mls qos srr-queue output cos-map queue and mls qos srr-queue output dscp-map queue global commands, respectively. While DSCP-to-Queue/Threshold maps override CoS-to-Queue/Threshold maps, these mappings should be as consistent as possible to ensure predictable behavior and simplify troubleshooting. That being said, CoS 0/DSCP 0 (Best Effort traffic) should be mapped to Queue 3 Threshold 3 (the tail of the queue), as no other traffic is to be assigned to Queue 3. CoS 1 (Scavenger and Bulk) should be mapped to Queue 4 Threshold 3. Scavenger traffic can then be further contained by a DSCP-to-Queue/Threshold mapping assigning DSCP CS1 to Queue 4 Threshold 1 (previously set at 40%); Bulk Data using DSCP values AF11, AF12, or AF13 (decimal values 10, 12, and 14, respectively) can then use the remainder of the queue. Bulk Data can use either Threshold 2 or Threshold 3 as its WTD limit (both of which are set to 100%).
Enterprise QoS Solution Reference Network Design Guide
2-58
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
CoS 2 and DSCP CS2, AF21, AF22, and AF23 (decimal values 16, 18, 20, and 22, respectively) can be assigned to Queue 2 Threshold 1 (previously set at 70%). This limits Network Management and Transactional Data to a subset of the Queue 2. The temporary marking value for Mission-Critical traffic, DSCP 25, should also be assigned to Queue2 Threshold 1. CoS 3, along with DSCP CS3 and AF31 (decimal values 24 and 26, respectively) can be assigned to Queue 2 Threshold 2 (previously set to 80%). This allows for preferential treatment of call signaling traffic within Queue 2. CoS 4 and DSCP CS4, AF41, AF42, and AF43 (decimal values 32, 34, 36, and 38, respectively) can be assigned to Queue 2 Threshold 1. In this manner, video (both Interactive and Streaming) does not drown out call signaling or Network/Internetwork Control traffic within Queue 2. CoS 5 and DSCP EF (decimal value 46) should be assigned to Queue 1 Threshold 3, as Voice is the only traffic to be assigned to the strict-priority queue. CoS 6 and DSCP CS6 (decimal value 48) and CoS 7 and DSCP CS7 (decimal value 56) should be assigned to Queue 2 Threshold 3. In this manner, there is always some room available in Queue 2 to service Network and Internetwork Control traffic. These recommended Catalyst 2970/3560/3750 CoS/DSCP to Queue/Threshold assignments are illustrated in Figure 2-18.
Figure 2-18
Application Network Control Internetwork Control Voice Interactive-Video Streaming-Video Mission-Critical Data Call-Signaling Transactional Data Network-Management Bulk Data Scavenger Best-Effort
Catalyst 2970/3560/3750 1P3Q3T Queuing Model
DSCP CS6 EF AF41 CS4 DSCP 25 AF31/CS3 AF21 CS2 AF11 CS1 0 CoS CoS 7 CoS 1 CoS 6 CoS 5 CoS 0 CoS 4 CoS 4 CoS 3 CoS 6 CoS 3 CoS 3 CoS 2 CoS 2 CoS 1 CoS 2 CoS 1 CoS 5 0 Q1 Priority Queue Q2T2 Queue 2 (70%) CoS 7 Q2T3 Queue 3 (25%) Queue 4 (5%) Q4T2 Q4T1 1P3Q3T
CoS 4
Q2T1
The Catalyst 2970/3560/3750 queuing and dropping configuration recommendations are shown below.
Example 2-32 Catalyst 2970/3560/3750—Queuing and Dropping
CAT2970(config)#mls qos srr-queue output cos-map queue 1 threshold 3 ! Maps CoS 5 to Queue 1 Threshold 3 (Voice gets all of Queue 1) CAT2970(config)#mls qos srr-queue output cos-map queue 2 threshold 1 ! Maps CoS 2 and CoS 4 to Queue 2 Threshold 1 CAT2970(config)#mls qos srr-queue output cos-map queue 2 threshold 2 ! Maps CoS 3 to Queue 2 Threshold 2 CAT2970(config)#mls qos srr-queue output cos-map queue 2 threshold 3 ! Maps CoS 6 and CoS 7 to Queue 2 Threshold 3 CAT2970(config)#mls qos srr-queue output cos-map queue 3 threshold 3 ! Maps CoS 0 to Queue 3 Threshold 3 (Best Efforts gets all of Q3) 5 2 4 3 6 7 0
Enterprise QoS Solution Reference Network Design Guide Version 3.3
224815
2-59
Chapter 2 Catalyst 2970/3560/3750—QoS Considerations and Design
Campus QoS Design
CAT2970(config)#mls qos srr-queue output cos-map queue 4 threshold 3 1 ! Maps CoS1 to Queue 4 Threshold 3 (Scavenger/Bulk gets all of Q4) CAT2970(config)# CAT2970(config)# CAT2970(config)#mls qos srr-queue output dscp-map queue 1 threshold 3 46 ! Maps DSCP EF (Voice) to Queue 1 Threshold 3 CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 16 ! Maps DSCP CS2 (Network Management) to Queue 2 Threshold 1 CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 18 20 22 ! Maps DSCP AF21, AF22, AF23 (Transactional Data) to Queue 2 Threshold 1 CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 25 ! Maps DSCP 25 (Mission-Critical Data) to Queue 2 Threshold 1 CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 32 ! Maps DSCP CS4 (Streaming Video) to Queue 2 Threshold 1 CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 1 34 36 38 ! Maps DSCP AF41, AF42, AF43 (Interactive-Video) to Queue 2 Threshold 1 CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 2 24 26 ! Maps DSCP CS3 and DSCP AF31 (Call-Signaling) to Queue 2 Threshold 2 CAT2970(config)#mls qos srr-queue output dscp-map queue 2 threshold 3 48 56 ! Maps DSCP CS6 and CS7 (Network/Internetwork) to Queue 2 Threshold 3 CAT2970(config)#mls qos srr-queue output dscp-map queue 3 threshold 3 0 ! Maps DSCP 0 (Best Effort) to Queue 3 Threshold 3 CAT2970(config)#mls qos srr-queue output dscp-map queue 4 threshold 1 8 ! Maps DSCP CS1 (Scavenger) to Queue 4 Threshold 1 CAT2970(config)#mls qos srr-queue output dscp-map queue 4 threshold 3 10 12 14 ! Maps DSCP AF11, AF12, AF13 (Bulk Data) to Queue 4 Threshold 3 CAT2970(config)# CAT2970(config)# CAT2970(config)#mls qos queue-set output 1 threshold 2 70 80 100 100 ! Sets Q2 Threshold 1 to 70% and Q2 Threshold 2 to 80% CAT2970(config)#mls qos queue-set output 1 threshold 4 40 100 100 100 ! Sets Q4 Threshold 1 to 40% and Q4 Threshold 2 to 100% CAT2970(config)# CAT2970(config)#interface range GigabitEthernet0/1 - 28 CAT2970(config-if-range)# queue-set 1 ! Assigns interface to Queue-Set 1 (default) CAT2970(config-if-range)# srr-queue bandwidth share 1 70 25 5 ! Q2 gets 70% of remaining BW; Q3 gets 25% and Q4 gets 5% CAT2970(config-if-range)# srr-queue bandwidth shape 3 0 0 0 ! Q1 is limited to 1/3 of the total available BW CAT2970(config-if-range)# priority-queue out ! Q1 is enabled as a PQ CAT2970(config-if-range)#end CAT2970#
Catalyst MLS QoS Verification Commands
Catalyst MLS QoS verification commands for queuing and dropping include the following:
• • • • •
show mls qos interface buffers show mls qos interface queueing show mls qos queue-set show mls qos maps cos-output-q show mls qos maps dscp-output-q
show mls qos queue-set
The show mls qos queue-set verification command returns the configured buffer allocations and defined thresholds for each queue-set.
Enterprise QoS Solution Reference Network Design Guide
2-60
Version 3.3
Chapter 2
Campus QoS Design Catalyst 2970/3560/3750—QoS Considerations and Design
In the example below, each queue has a default buffer allocation of 25%. Additionally, all WTD Thresholds are set to 100% (the tail of the queue), except for Queue 2 Threshold 1 (set to 70%), Queue 2 Threshold 2 (set to 80%), and Queue 4 Threshold 1 (set to 40%).
Example 2-33 Show MLS QoS Queue-Set Verification for a Catalyst 2970/3560/3750 Switch
CAT2970#show mls qos queue-set 1 Queueset: 1 Queue : 1 2 3 4 ---------------------------------------------buffers : 25 25 25 25 threshold1: 100 70 100 40 threshold2: 100 80 100 100 reserved : 50 100 50 100 maximum : 400 100 400 100 CAT2970#
show mls qos maps cos-output-q
The show mls qos maps cos-output-q verification command truncates the show mls qos maps output to only report the CoS-to-Queue/Threshold mappings for egress queues. In the example below, CoS 0 is mapped to Q3T3, CoS 1 is mapped to Q4T3, CoS 2 is mapped to Q2T1, CoS 3 is mapped to Q2T2, CoS 4 is mapped to Q2T1, CoS 5 is mapped to Q1T3 (the PQ), and CoS 6 and CoS 7 are mapped to Q2T3.
Example 2-34 Show MLS QoS Maps CoS-Output-Q Verification for a Catalyst 2970/3560/3750 Switch
CAT2970#show mls qos maps cos-output-q Cos-outputq-threshold map: cos: 0 1 2 3 4 5 6 7 -----------------------------------queue-threshold: 3-3 4-3 2-1 2-2 2-1 1-3 2-3 2-3
CAT2970#
show mls qos maps dscp-output-q
The show mls qos maps dscp-output-q verification command truncates the show mls qos maps output to only report the DSCP-to-Queue/Threshold mappings for egress queues. The output is shown in tabular form, with the first digit of the decimal DSCP value in rows and the second digit in columns. In the example below, only standard DSCP PHBs are being mapped away from the default settings (with the exception of the temporary marking of DSCP 25 for Mission-Critical Data). The other non-standard values may be mapped to reflect the CoS-to-Queue mappings, but for example simplicity this has not been done in this case. Specifically, DSCP 0 is mapped to Q3T3; DSCP CS1 (8) is mapped to Q4T1; DSCP AF11, AF12, and AF13 (10, 12, 14) are mapped to Q4T3; DSCP CS2 (16) is mapped to Q2T1 as are DSCP AF21, AF22, and AF23 (18, 20, 22); DSCP CS3 (24) and AF31 (26) are mapped to Q2T2; DSCP CS4 (32) is mapped to Q2T1 as are DSCP AF41, AF42, and AF43 (34, 36, 38); DSCP EF (46) is mapped to Q1T3 (the PQ); DSCP CS6 (48) and CS7 (56) are mapped to Q2T3. The non-standard DSCP 25 is mapped to Q2T1.
Example 2-35 Show MLS QoS Maps DSCP-Output-Q Verification for a Catalyst 2970/3560/3750 Switch
CAT2970#show mls qos maps dscp-output-q
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-61
Chapter 2 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Campus QoS Design
Dscp-outputq-threshold map: d1 :d2 0 1 2 3 4 5 6 7 8 -----------------------------------------------------------0 : 03-03 02-01 02-01 02-01 02-01 02-01 02-01 02-01 04-01 1 : 04-03 02-01 04-03 02-01 04-03 02-01 02-01 03-01 02-01 2 : 02-01 03-01 02-01 03-01 02-02 02-01 02-02 03-01 03-01 3 : 03-01 03-01 02-01 04-01 02-01 04-01 02-01 04-01 02-01 4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-03 01-01 02-03 5 : 04-01 04-01 04-01 04-01 04-01 04-01 02-03 04-01 04-01 6 : 04-01 04-01 04-01 04-01 CAT2970#
9 02-01 03-01 03-01 04-01 04-01 04-01
Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
This section includes the following topics:
• • • • • • •
Catalyst 4500—Trusted Endpoint Model Catalyst 4500—Auto QoS VoIP Model Catalyst 4500—Untrusted PC + SoftPhone with Scavenger-Class QoS Model Catalyst 4500—Untrusted Server with Scavenger-Class QoS Model Catalyst 4500 —Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Catalyst 4500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model Catalyst 4500—Queuing
The Catalyst 4500 with Supervisors II+, III, IV, and V can be found at either the access layer or the distribution layer of the campus. Furthermore, due to their high performance, they may also be found at the core layer of some campus networks. The QoS design options for access layer Catalyst 4500 design are shown in Figure 2-19; the distribution and/or core layer recommendations are shown in Figure 2-20.
Enterprise QoS Solution Reference Network Design Guide
2-62
Version 3.3
Chapter 2
Campus QoS Design Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Figure 2-19
Access Layer Catalyst 4500 QoS Design Options
Access-Edges
Trusted-Endpoint Model AutoQoS–VoIP Model PC + SoftPhone + Scavenger Model Untrusted Server + Scavenger Model IP Phone + PC + Scavenger (Basic) Model IP Phone + PC + Scavenger (Adv) Model 1P3Q1T Queuing + DBL 1P3Q1T Queuing + DBL 1P3Q1T Queuing + DBL Trust-DSCP 1P3Q1T Queuing + DBL 1P3Q1T Queuing + DBL 1P3Q1T Queuing + DBL
132549 224817
Uplinks to Distribution Layer
1P3Q1T Queuing + DBL
Enable QoS Globally
Figure 2-20
Enable QoS Globally
Distribution and/or Core Layer Catalyst 4500 QoS Design
1P3Q3T Queuing + WTD
Trust-DSCP
Interswitch Links
Note
To narrow the scope of our discussion to the most current and relevant versions of the Catalyst 4500 switch family, only the Catalyst 4500 with Supervisors II+, III, IV and V are examined in this design chapter. For discussions of older versions of Catalyst 4000/4500s, refer to the Cisco Press book, Cisco Catalyst QoS: Quality of Service in Campus Networks, by Mike Flannagan, Richard Froom, and Kevin Turek. Much of the Catalyst MLS QoS syntax is supported on the Catalyst 4500; however, the mls prefix keyword is usually omitted from the configuration commands. For example, as with the Catalyst 3550 and 2970/3560/3750, QoS is globally disabled on the Catalyst 4500 by default. However, the command to enable QoS globally on a Catalyst 4500 is simply qos, not mls qos. The verification commands are issued in the same manner, with the mls keyword omitted. Generally speaking, show mls qos [...] verification commands from other Catalyst platforms are translated to show qos [...] verification commands on the Catalyst 4500 platforms. While QoS is globally disabled on the Catalyst 4500, all frames/packets are passed-through the switch unaltered (which is equivalent to a trust CoS and trust DSCP state on all ports). When QoS is globally enabled, however, then all DSCP and CoS values are (by default) set to 0 (which is equivalent to an untrusted state on all ports). The verification command to check whether QoS has been globally enabled on the Catalyst 4500, along with the configuration command, are shown below.
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-63
Chapter 2 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Campus QoS Design
Example 2-36 Enabling QoS Globally on the Catalyst 4500
CAT4500#show qos QoS is disabled globally IP header DSCP rewrite is enabled CAT4500#conf term Enter configuration commands, one per line. CAT4500(config)#qos CAT4500(config)#end CAT4500# CAT4500#show qos QoS is enabled globally IP header DSCP rewrite is enabled CAT4500#
End with CNTL/Z.
Catalyst 4500—Trusted Endpoint Model
This section includes the following topics:
• •
Configuration Catalyst 4500 QoS Verification Commands
Configuration
To enable a given Catalyst 4500 interface to trust the DSCP markings of an endpoint, the qos trust dscp interface command is used as shown below.
Example 2-37 Catalyst 4500—Trusted Endpoint Model Configuration
CAT4500(config)#interface FastEthernet2/1 CAT4500(config-if)# qos trust dscp CAT4500(config-if)#end CAT4500#
Catalyst 4500 QoS Verification Commands
Catalyst 4500 QoS verification commands for the Catalyst 4500 Untrusted Endpoint model include the following:
• •
show qos show qos interface
Note
Since most Catalyst 4500 verification commands are reasonably similar to the MLS QoS verification commands previously discussed (albeit without the mls keyword), to minimize redundancy MLS QoS verification commands that have already been detailed are not repeated in this section.
Catalyst 4500—Auto QoS VoIP Model
The Catalyst 4500 supports AutoQoS VoIP with the following keyword options:
Enterprise QoS Solution Reference Network Design Guide
2-64
Version 3.3
Chapter 2
Campus QoS Design Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
• •
auto qos voip cisco-phone auto qos voip trust
When you enable AutoQoS VoIP on the Catalyst 4500 by using the auto qos voip cisco-phone or the auto qos voip trust interface configuration commands, the switch automatically generates a QoS configuration based on the traffic type and ingress packet label and applies the commands listed in Table 2-4 to the interface.
Table 2-4
Catalyst 4500 AutoQoS Generated Configuration
Description The switch automatically enables standard QoS and DBL configures the cos-to-DSCP map (maps CoS values in incoming packets to a DSCP value). The switch automatically configures the DSCP-to-Tx-queue mapping. The switch automatically sets the ingress classification on the interface to trust the CoS/DSCP value received in the packet.
Automatically Generated Command
C4500(config)# C4500(config)# C4500(config)# C4500(config)# C4500(config)# 31 to tx-queue C4500(config)# 39 to tx-queue qos qos map cos 3 to 26 qos dbl qos map cos 5 to 46 qos map dscp 24 25 26 27 b28 29 30 4 qos map dscp 32 33 34 35 36 37 38 4
C4500(config-if)# qos trust cos or C4500(config-if)# qos trust dscp
C4500(config)# policy-map autoqos-voip-policy The switch automatically creates a QoS service policy, enables DBL on the policy, C4500(config-pmap)# class class-default C4500(config-pmap-c)# dbl and attaches it to the interface.
If you entered the auto qos voip cisco-phone command, the switch automatically enables the trusted boundary feature, which uses the CDP to detect the presence or absence of a Cisco IP phone. The switch assigns a higher priority for queue 3. Limit for shaping on queue 3 is selected so that it is 33 percent of the link speed. Configure shaping as 33 percent on those ports where sharing is supported. This procedure ensures that the higher-priority queue does not starve other queues.
C4500(config-if)# qos trust device cisco-phone
C4500(config-if)# tx-queue C4500(config-if-tx-queue)# C4500(config-if-tx-queue)# C4500(config-if-tx-queue)#
3 priority high shape percent 33 bandwidth percent 33
Catalyst 4500—Untrusted PC + SoftPhone with Scavenger-Class QoS Model
This section includes the following topics:
• •
Configuration Catalyst 4500 QoS Verification Commands
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-65
Chapter 2 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Campus QoS Design
Configuration
The Untrusted PC + Softphone + Scavenger access edge model for Catalyst 4500s is similar to the examples given on previously discussed platforms. A few distinctions exist, such as the absence of the mls keyword in defining the policed-DSCP map (along with some slight syntax variation for this command) and the (optional) use of the kbps and mbps (denoting kilobits and megabits, respectively) within the policing statements.
Example 2-38 Catalyst 4500—Untrusted PC + SoftPhone + Scavenger Model Configuration
CAT4500-SUP4(config)#qos map dscp policed 0 24 46 to dscp 8 ! Excess traffic marked 0 or CS3 or EF will be remarked to CS1 CAT4500-SUP4(config)# CAT4500-SUP4(config)#class-map match-all SOFTPHONE-SIGNALING CAT4500-SUP4(config-cmap)# match access-group name SOFTPHONE-SIGNALING CAT4500-SUP4(config-cmap)#class-map match-all SOFTPHONE-VOICE CAT4500-SUP4(config-cmap)# match access-group name SOFTPHONE-VOICE CAT4500-SUP4(config-cmap)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#policy-map SOFTPHONE-PC CAT4500-SUP4(config-pmap)# class SOFTPHONE-VOICE CAT4500-SUP4(config-pmap-c)# set ip dscp ef ! Softphone VoIP is marked to DSCP EF CAT4500-SUP4(config-pmap-c)# police 128 kbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile SoftPhone voice traffic is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class SOFTPHONE-SIGNALING CAT4500-SUP4(config-pmap-c)# set ip dscp cs3 ! SoftPhone call signaling is marked to DSCP CS3 CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile Signaling traffic is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class class-default CAT4500-SUP4(config-pmap-c)# set ip dscp default CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#interface FastEthernet2/1 CAT4500-SUP4(config-if)# service-policy input SOFTPHONE-PC ! Applies policy CAT4500-SUP4(config-if)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#ip access list extended SOFTPHONE-VOICE CAT4500-SUP4(config-ext-nacl)# permit udp any any range 16384 32767 ! VoIP CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended SOFTPHONE-SIGNALING CAT4500-SUP4(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP CAT4500-SUP4(config-ext-nacl)#end CAT4500-SUP4#
Catalyst 4500 QoS Verification Commands
Catalyst 4500 QoS verification commands for the Catalyst 4500 Untrusted PC + Softphone + Scavenger model include the following:
• • •
show qos show qos maps show qos interface
Enterprise QoS Solution Reference Network Design Guide
2-66
Version 3.3
Chapter 2
Campus QoS Design Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
• • •
show class-map show policy-map show policy interface
Catalyst 4500—Untrusted Server with Scavenger-Class QoS Model
This section includes the following topics:
• •
Configuration Catalyst 4500 QoS Verification Commands
Configuration
The Catalyst 4500 Untrusted Multi-Application Server with Scavenger-Class QoS model is show below. The main changes for the Catalyst 4500 for this model are the syntax defining the policed-DSCP map and the policer definitions (using the abbreviation mbps for megabits per second).
Example 2-39 Catalyst 4500—Untrusted Multi-Application Server with Scavenger-Class QoS Model Configuration
CAT4500-SUP4(config)#qos map dscp policed 0 10 18 25 to dscp 8 ! Excess traffic marked 0 or AF11 or AF21 or DSCP 25 will be remarked to CS1 CAT4500-SUP4(config)# CAT4500-SUP4(config)#class-map SAP CAT4500-SUP4(config-cmap)# match access-group name SAP CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map LOTUS CAT4500-SUP4(config-cmap)# match access-group name LOTUS CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map IMAP CAT4500-SUP4(config-cmap)# match access-group name IMAP CAT4500-SUP4(config-cmap)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#policy-map UNTRUSTED-SERVER CAT4500-SUP4(config-pmap)#class SAP CAT4500-SUP4(config-pmap-c)# set ip dscp 25 ! SAP is marked as Mission-Critical (DSCP 25) CAT4500-SUP4(config-pmap-c)# police 15 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile SAP is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class LOTUS CAT4500-SUP4(config-pmap-c)# set ip dscp 18 ! Lotus is marked as Transactional Data (DSCP AF21) CAT4500-SUP4(config-pmap-c)# police 35 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile LOTUS is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class IMAP CAT4500-SUP4(config-pmap-c)# set ip dscp 10 ! IMAP is marked as Bulk Data (DSCP AF11) CAT4500-SUP4(config-pmap-c)# police 50 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile IMAP is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class class-default CAT4500-SUP4(config-pmap-c)# set ip dscp 0 CAT4500-SUP4(config-pmap-c)# police 1 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile excess data traffic is marked down to Scavenger (CS1)
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-67
Chapter 2 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Campus QoS Design
CAT4500-SUP4(config-pmap-c)# exit CAT4500-SUP4(config-pmap)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)# CAT4500-SUP4(config)#interface FastEthernet2/1 CAT4500-SUP4(config-if)# service-policy input UNTRUSTED-SERVER CAT4500-SUP4(config-if)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)# CAT4500-SUP4(config)#ip access list extended SAP CAT4500-SUP4(config-ext-nacl)# permit tcp any range 3200 3203 any CAT4500-SUP4(config-ext-nacl)# permit tcp any eq 3600 any CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended LOTUS CAT4500-SUP4(config-ext-nacl)# permit tcp any eq 1352 any CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended IMAP CAT4500-SUP4(config-ext-nacl)# permit tcp any eq 143 any CAT4500-SUP4(config-ext-nacl)# permit tcp any eq 220 any CAT4500-SUP4(config-ext-nacl)#end CAT4500-SUP4#
Catalyst 4500 QoS Verification Commands
Catalyst 4500 QoS verification commands for the Catalyst 4500 Untrusted Server with Scavenger-Class QoS model include the following:
• • • • • •
show qos show qos maps show qos interface show class-map show policy-map show policy interface
Catalyst 4500 —Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model
This section includes the following topics:
• •
Configuration Catalyst 4500 QoS Verification Commands
Configuration
The Catalyst 4500 does not currently support per-port/per-VLAN policing. Therefore, access lists that include the VVLAN subnet are required to achieve granular policing of the VVLAN and DVLAN subnets, as shown below.
Example 2-40 Catalyst 4500—Conditionally-Trusted IP Phone + PC + Scavenger (Basic) Model Configuration
CAT4500-SUP4(config)#qos map cos 5 to dscp 46 ! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF
Enterprise QoS Solution Reference Network Design Guide
2-68
Version 3.3
Chapter 2
Campus QoS Design Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
CAT4500-SUP4(config)#qos map dscp policed 0 24 to dscp 8 ! Excess DVLAN & VVLAN traffic will be marked down to Scavenger (CS1) CAT4500-SUP4(config)# CAT4500-SUP4(config)# CAT4500-SUP4(config)#class-map match-all VVLAN-VOICE CAT4500-SUP4(config-cmap)# match access-group name VVLAN-VOICE CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING CAT4500-SUP4(config-cmap)# match access-group name VVLAN-CALL-SIGNALING CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map match-all VVLAN-ANY CAT4500-SUP4(config-cmap)# match access-group name VVLAN-ANY CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#policy-map IPPHONE+PC-BASIC CAT4500-SUP4(config-pmap)#class VVLAN-VOICE CAT4500-SUP4(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice) CAT4500-SUP4(config-pmap-c)# police 128 kbps 8000 byte exceed-action drop ! Only one voice call is permitted per switchport VVLAN CAT4500-SUP4(config-pmap-c)#class VVLAN-CALL-SIGNALING CAT4500-SUP4(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling) CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile call signaling is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class VVLAN-ANY CAT4500-SUP4(config-pmap-c)# set ip dscp 0 CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action policed-dscp-transmit ! Unauthorized VVLAN traffic is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class class-default CAT4500-SUP4(config-pmap-c)# set ip dscp 0 CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)# exit CAT4500-SUP4(config-pmap)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)# CAT4500-SUP4(config)#interface FastEthernet2/1 CAT4500-SUP4(config-if)# switchport access vlan 10 ! DVLAN CAT4500-SUP4(config-if)# switchport voice vlan 110 ! VVLAN CAT4500-SUP4(config-if)# qos trust device cisco-phone ! Conditional Trust CAT4500-SUP4(config-if)# service-policy input IPPHONE+PC-BASIC CAT4500-SUP4(config-if)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)# CAT4500-SUP4(config)#ip access list extended VVLAN-VOICE CAT4500-SUP4(config-ext-nacl)# permit udp 10.1.110.0 0.0.0.255 any range 16384 32767 ! Voice is matched by VVLAN subnet and UDP port-range CAT4500-SUP4(config-ext-nacl)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#ip access list extended VVLAN-CALL-SIGNALING CAT4500-SUP4(config-ext-nacl)# permit tcp 10.1.110.0 0.0.0.255 any range 2000 2002 ! Call Signaling is matched by VVLAN subnet and TCP port-range CAT4500-SUP4(config-ext-nacl)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#ip access list extended VVLAN-ANY CAT4500-SUP4(config-ext-nacl)# permit ip 10.1.110.0 0.0.0.255 any ! Matches all other traffic sourced from the VVLAN subnet CAT4500-SUP4(config-ext-nacl)#end CAT4500-SUP4#
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-69
Chapter 2 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Campus QoS Design
Catalyst 4500 QoS Verification Commands
Catalyst 4500 QoS verification commands for the Conditionally-Trusted IP Phone + PC + Scavenger (Basic) model include the following:
• • • • • •
show qos show qos maps show qos interface show class-map show policy-map show policy interface
Catalyst 4500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model
This section includes the following topics:
• •
Configuration Catalyst 4500 QoS Verification Commands
Configuration
Building on the previous model, PC applications, such as Interactive-Video, Mission-Critical Data, Transactional-Data, and Bulk-Data, are identified by access lists. The configuration for the Conditionally-Trusted IP Phone + PC + Scavenger (Advanced) Model for the Catalyst 4500 is shown below.
Example 2-41 Catalyst 4500—Conditionally-Trusted IP Phone + PC + Scavenger (Advanced) Model Configuration
CAT4500-SUP4(config)#qos map cos 5 to dscp 46 ! Modifies CoS-to-DSCP mapping to map CoS 5 to DSCP EF CAT4500-SUP4(config)#qos map dscp policed 0 10 18 24 25 34 to dscp 8 ! Excess DVLAN traffic marked 0, AF11, AF21, CS3, DSCP 25 ! and AF41 will be remarked to Scavenger (CS1) CAT4500-SUP4(config)# CAT4500-SUP4(config)# CAT4500-SUP4(config)#class-map match-all VVLAN-VOICE CAT4500-SUP4(config-cmap)# match access-group name VVLAN-VOICE CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map match-all VVLAN-CALL-SIGNALING CAT4500-SUP4(config-cmap)# match access-group name VVLAN-CALL-SIGNALING CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map match-all VVLAN-ANY CAT4500-SUP4(config-cmap)# match access-group name VVLAN-ANY CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map match-all DVLAN-PC-VIDEO CAT4500-SUP4(config-cmap)# match access-group name DVLAN-PC-VIDEO CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map match-all DVLAN-MISSION-CRITICAL-DATA CAT4500-SUP4(config-cmap)# match access-group name DVLAN-MISSION-CRITICAL-DATA CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map match-all DVLAN-TRANSACTIONAL-DATA
Enterprise QoS Solution Reference Network Design Guide
2-70
Version 3.3
Chapter 2
Campus QoS Design Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
CAT4500-SUP4(config-cmap)# match access-group name DVLAN-TRANSACTIONAL-DATA CAT4500-SUP4(config-cmap)# CAT4500-SUP4(config-cmap)#class-map match-all DVLAN-BULK-DATA CAT4500-SUP4(config-cmap)# match access-group name DVLAN-BULK-DATA CAT4500-SUP4(config-cmap)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#policy-map IPPHONE+PC-ADVANCED CAT4500-SUP4(config-pmap)#class VVLAN-VOICE CAT4500-SUP4(config-pmap-c)# set ip dscp 46 ! DSCP EF (Voice) CAT4500-SUP4(config-pmap-c)# police 128 kbps 8000 byte exceed-action drop ! Only one voice call is permitted per switchport VVLAN CAT4500-SUP4(config-pmap-c)#class VVLAN-CALL-SIGNALING CAT4500-SUP4(config-pmap-c)# set ip dscp 24 ! DSCP CS3 (Call-Signaling) CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile call signaling is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class VVLAN-ANY CAT4500-SUP4(config-pmap-c)# set ip dscp 0 CAT4500-SUP4(config-pmap-c)# police 32 kbps 8000 byte exceed-action policed-dscp-transmit ! Unauthorized VVLAN traffic is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class DVLAN-PC-VIDEO CAT4500-SUP4(config-pmap-c)# set ip dscp 34 ! DSCP AF41 (Int-Video) CAT4500-SUP4(config-pmap-c)# police 500 kbps 8000 byte exceed-action policed-dscp-transmit ! Only one IP/VC stream will be permitted per switchport CAT4500-SUP4(config-pmap-c)#class DVLAN-MISSION-CRITICAL-DATA CAT4500-SUP4(config-pmap-c)# set ip dscp 25 ! Interim Mission-Critical CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile Mission-Critical Data is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class DVLAN-TRANSACTIONAL-DATA CAT4500-SUP4(config-pmap-c)# set ip dscp 18 ! DSCP AF21 CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile Transactional Data is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class DVLAN-BULK-DATA CAT4500-SUP4(config-pmap-c)# set ip dscp 10 ! DSCP AF11 CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile Bulk Data is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#class class-default CAT4500-SUP4(config-pmap-c)# set ip dscp 0 CAT4500-SUP4(config-pmap-c)# police 5 mbps 8000 byte exceed-action policed-dscp-transmit ! Out-of-profile data traffic is marked down to Scavenger (CS1) CAT4500-SUP4(config-pmap-c)#exit CAT4500-SUP4(config-pmap)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)# CAT4500-SUP4(config)#interface FastEthernet2/1 CAT4500-SUP4(config-if)# switchport access vlan 10 ! DVLAN CAT4500-SUP4(config-if)# switchport voice vlan 110 ! VVLAN CAT4500-SUP4(config-if)# qos trust device cisco-phone ! Conditional Trust CAT4500-SUP4(config-if)# service-policy input IPPHONE+PC-ADVANCED CAT4500-SUP4(config-if)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#ip access list extended VVLAN-VOICE CAT4500-SUP4(config-ext-nacl)# permit udp 10.1.110.0 0.0.0.255 any range 16384 32767 ! Voice is matched by VVLAN subnet and UDP port-range CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended VVLAN-CALL-SIGNALING CAT4500-SUP4(config-ext-nacl)# permit tcp 10.1.110.0 0.0.0.255 any
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-71
Chapter 2 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Campus QoS Design
range 2000 2002 ! Call Signaling is matched by VVLAN subnet and TCP port-range CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended VVLAN-ANY CAT4500-SUP4(config-ext-nacl)# permit ip 10.1.110.0 0.0.0.255 any CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended DVLAN-PC-VIDEO CAT4500-SUP4(config-ext-nacl)# permit udp any any range 16384 32767 CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended DVLAN-MISSION-CRITICAL-DATA CAT4500-SUP4(config-ext-nacl)# permit tcp any any range 3200 3203 ! SAP CAT4500-SUP4(config-ext-nacl)# permit tcp any any eq 3600 ! SAP CAT4500-SUP4(config-ext-nacl)# permit tcp any any range 2000 2002 ! SCCP CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended DVLAN-TRANSACTIONAL-DATA CAT4500-SUP4(config-ext-nacl)# permit tcp any any eq 1352 ! Lotus CAT4500-SUP4(config-ext-nacl)# CAT4500-SUP4(config-ext-nacl)#ip access list extended DVLAN-BULK-DATA CAT4500-SUP4(config-ext-nacl)# permit tcp any any eq 143 ! IMAP CAT4500-SUP4(config-ext-nacl)# permit tcp any any eq 220 ! IMAP CAT4500-SUP4(config-ext-nacl)#end CAT4500-SUP4#
Catalyst 4500 QoS Verification Commands
Catalyst 4500 QoS verification commands for the Conditionally-Trusted IP Phone + PC + Scavenger (Advanced) model include the following:
• • • • • •
show qos show qos maps show qos interface show class-map show policy-map show policy interface
Catalyst 4500—Queuing
This section includes the following topics:
• •
Configuration Catalyst 4500 QoS Verification Commands
Configuration
The Catalyst 4500 supports four egress queues for scheduling, which may be configured in either 4Q1T or 1P3Q1T modes. The strict-priority queue on the Catalyst 4500 is transmit-queue 3. While tail-drop or WRED thresholds are not supported on the Catalyst 4500, it does support one of the most advanced congestion avoidance mechanisms in the Catalyst family. This congestion avoidance feature is performed by Dynamic Buffer Limiting (DBL). DBL tracks the queue length for each traffic flow in the switch and when the queue length of a flow exceeds its limit, DBL drops packets or sets the (RFC 3168) Explicit Congestion Notification (ECN) bits in the IP packet headers. DBL can be enabled
Enterprise QoS Solution Reference Network Design Guide
2-72
Version 3.3
Chapter 2
Campus QoS Design Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
globally with the qos dbl global command, as well as on a per-class basis within a policy-map with the dbl policy command. A default DBL policy can be applied to all transmit queues, as is shown in the example below. By default, all queues are scheduled in a round robin manner. The third transmit queue can be designated as an optional strict-priority queue. This can be enabled with the tx-queue 3 interface command followed by the priority high interface transmit-queue sub-command. This queue can be defined to be shaped to a peak limit, such as 30%, to allow bandwidth to be available to non-voice applications. This would be valuable in the event that a trust boundary has been compromised and a DoS/worm attack is saturating voice queues. Bandwidth allocations can also be assigned to queues (for certain interfaces) using the tx-queue interface command followed by the bandwidth sub-command. Bandwidth allocations to queues can only be assigned on the following interface types:
• • • • •
Uplink ports on supervisor engines Ports on the WS-X4306-GB linecard The 2 1000BASE-X ports on the WS-X4232-GB-RJ linecard The first 2 ports on the WS-X4418-GB linecard The two 1000BASE-X ports on the WS-X4412-2GB-TX linecard
The Catalyst 4500 does not support CoS-to-Queue mappings, only DSCP-to-Queue mappings. These can be defined with the qos map dscp to tx-queue global command. Given these features and the objective to make queuing consistent across platforms, it is recommended to enable DBL globally on the Catalyst 4500, as well as enable Q3 as the strict-priority queue on all interfaces (such that the switch operates in 1P3Q1T mode). This queue can be shaped to 30% of the link’s capacity. Furthermore, Q1 can then be used as the Scavenger/Bulk queue, Q2 as the Best-Effort queu,e and Q4 as the preferential queue. On interfaces that support bandwidth allocation, 5% could be assigned to Q1, 25% to Q2, and 40% to Q3. Unlike bandwidth-weights that are used on other platforms, these bandwidth allocations are defined in absolute bps or as relative percentages of the link’s bandwidth. In either case, they should not total in excess of the link’s bandwidth-limit (1 Gbps or 100%), including the priority-bandwidth allocation for Q3. By default, the DSCP-to-Queue assignments are as follows:
• • • •
DSCP 0-15 Queue 1 DSCP 16-31 Queue 2 DSCP 32-47 Queue 3 DSCP 48-63 Queue 4 DSCP 0 should be assigned to Q2 DSCP CS1 (Scavenger) and DSCP AF11/AF12/AF13 (Bulk Data) should be assigned to Q1 DSCP CS2 (Network Management) as well as AF21/AF22/AF23 (Transactional Data) should be assigned to Q4 DSCP CS3 and AF31 (Call-Signaling) should be assigned to Q4 DSCP 25 (temporary marking for Mission-Critical Data) should be assigned to Q4 DSCP CS4 (Streaming Video) and AF41/AF42/AF43 (Interactive Video) should be assigned to Q4 DSCP EF (Voice) should be assigned to Q3 (the strict priority queue)
The recommended DSCP-to-Queue assignments for the Catalyst 4500 are as follows:
• • • • • • •
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-73
Chapter 2 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Campus QoS Design
•
DSCP CS6 (Internetwork Control) and CS7 (Network Control/STP) should be assigned to Q4
The queuing recommendations for the Catalyst 4500 (Supervisors II+, III, IV and V) are shown in Figure 2-21.
Figure 2-21
Application Network Control Internetwork Control Voice Interactive-Video Streaming-Video Mission-Critical Data Call-Signaling Transactional Data Network-Management Bulk Data Scavenger Best-Effort
Catalyst 4500-SupII+/III/IV/V 1P3Q1T Queuing Model
DSCP (CS7) CS6/CS7 CS6 CS4/AF41 EF Queue 4 (40%) AF41 DSCP 25 CS4 DSCP 25 AF31/CS3 AF21 CS2 AF11 0 CS1 0 Queue 2 (25%) CS3/AF31 CS2/AF21 1P3Q1T
EF Q3 (30%) Priority Queue
CS1/AF11
Queue 1 (5%)
The configurations for enabling queuing on the Catalyst 4500 per these recommendations are shown below. Two separate examples are given, one for a FastEthernet interface that does not support bandwidth allocations and another for a GigabitEthernet interface that does. Some of the DSCP-to-Queue mappings are not required (as they overlap with the default settings), but are shown nonetheless to complete the logic of the example.
Example 2-42 Catalyst 4500—Queuing and Dropping
CAT4500-SUP4(config)#qos dbl ! Globally enables DBL CAT4500-SUP4(config)#qos dbl exceed-action ecn ! Optional: Enables DBL to mark RFC 3168 ECN bits in the IP ToS Byte CAT4500-SUP4(config)# CAT4500-SUP4(config)#qos map dscp 0 to tx-queue 2 ! Maps DSCP 0 (Best Effort) to Q2 CAT4500-SUP4(config)#qos map dscp 8 10 12 14 to tx-queue 1 ! Maps DSCP CS1 (Scavenger) and AF11/AF12/AF13 (Bulk) to Q1 CAT4500-SUP4(config)#qos map dscp 16 18 20 22 to tx-queue 4 ! Maps DSCP CS2 (Net-Mgmt) and AF21/AF22/AF23 (Transactional) to Q4 CAT4500-SUP4(config)#qos map dscp 24 25 26 to tx-queue 4 ! Maps DSCP CS3 and AF31 (Call-Signaling) and DSCP 25 (MC Data) to Q4 CAT4500-SUP4(config)#qos map dscp 32 34 36 38 to tx-queue 4 ! Maps DSCP CS4 (Str-Video) and AF41/AF42/AF43 (Int-Video) to Q4 CAT4500-SUP4(config)#qos map dscp 46 to tx-queue 3 ! Maps DSCP EF (VoIP) to Q3 (PQ) CAT4500-SUP4(config)#qos map dscp 48 56 to tx-queue 4 ! Maps DSCP CS6 (Internetwork) and CS7 (Network) Control to Q4 CAT4500-SUP4(config)# CAT4500-SUP4(config)#policy-map DBL CAT4500-SUP4(config-pmap)#class class-default CAT4500-SUP4(config-pmap-c)# dbl ! Enables DBL on all traffic flows CAT4500-SUP4(config-pmap-c)# exit
Enterprise QoS Solution Reference Network Design Guide
2-74
224818
Queue 1 (5%)
Version 3.3
Chapter 2
Campus QoS Design Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
CAT4500-SUP4(config-pmap)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#interface range FastEthernet2/1 - 48 CAT4500-SUP4(config-if-range)# service-policy output DBL CAT4500-SUP4(config-if-range)# tx-queue 3 CAT4500-SUP4(config-if-tx-queue)# priority high CAT4500-SUP4(config-if-tx-queue)# shape percent 30 CAT4500-SUP4(config-if-tx-queue)# exit CAT4500-SUP4(config-if-range)#exit CAT4500-SUP4(config)# CAT4500-SUP4(config)#interface range GigabitEthernet1/1 - 2 CAT4500-SUP4(config-if-range)# service-policy output DBL CAT4500-SUP4(config-if-range)# tx-queue 1 CAT4500-SUP4(config-if-tx-queue)# bandwidth percent 5 CAT4500-SUP4(config-if-tx-queue)# tx-queue 2 CAT4500-SUP4(config-if-tx-queue)# bandwidth percent 25 CAT4500-SUP4(config-if-tx-queue)# tx-queue 3 CAT4500-SUP4(config-if-tx-queue)# priority high CAT4500-SUP4(config-if-tx-queue)# bandwidth percent 30 CAT4500-SUP4(config-if-tx-queue)# shape percent 30 CAT4500-SUP4(config-if-tx-queue)# tx-queue 4 CAT4500-SUP4(config-if-tx-queue)# bandwidth percent 40 CAT4500-SUP4(config-if-tx-queue)#end CAT4500-SUP4#
! Applies DBL policy ! Enables Q3 as PQ ! Shapes PQ to 30%
! Applies DBL policy ! Q1 gets 5% ! Q2 gets 25% ! Enables Q3 as PQ ! PQ gets 30% ! Shapes PQ to 30% ! Q4 gets 40%
Catalyst 4500 QoS Verification Commands
Catalyst 4500 QoS verification commands for queuing include the following:
• • •
show qos dbl show qos maps dscp tx-queue show qos interface
show qos dbl
The Catalyst 4500 show qos dbl verification command returns whether or not DBL has been enabled, as well as some of the operating parameters that have been defined for its operation. These parameters include allowing DBL to set RFC 3168 ECN bits in IP headers, as shown in the example below.
Example 2-43 Show QoS DBL Verification for a Catalyst 4500 Switch
CAT4500-SUP4#show qos dbl QOS is enabled globally DBL is enabled globally DBL flow includes vlan DBL flow includes layer4-ports DBL uses ecn to indicate congestion DBL exceed-action probability: 15% DBL max credits: 15 DBL aggressive credit limit: 10 DBL aggressive buffer limit: 2 packets CAT4500-SUP4#
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-75
Chapter 2 Catalyst 4500 Supervisor II+/III/IV/V—QoS Considerations and Design
Campus QoS Design
show qos maps dscp tx-queue
The Catalyst 4500 show qos maps dscp tx-queue verification command truncates the show qos maps output to only report the DSCP-to-Queue mappings for egress queues. The output is shown in tabular form, with the first digit of the decimal DSCP value in rows and the second digit in columns. In the example below, only DSCP 0 is mapped to Q2; DSCP CS1 (8) and AF11/AF12/AF13 (10/12/14) are mapped to Q1; DSCP CS2 (16) and AF22/AF22/AF23 (18/20/22) are mapped to Q4; DSCP CS3 (24) and AF31 (26) are mapped to Q4, as is the non-standard DSCP 25. DSCP CS4 (32) and AF41/AF42/AF43 (34/36/38) are mapped to Q4, as are DSCP CS6 (48) and CS7 (56). DSCP EF (46) is mapped to Q3.
Example 2-44 Show QoS Maps DSCP Tx-Queue Verification for a Catalyst 4500 Switch
CAT4500-SUP4#show qos maps dscp tx-queue DSCP-TxQueue Mapping Table (dscp = d1d2) d1 : d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------0 : 02 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 04 02 04 02 2 : 3 4 5 6 : : : : 04 02 04 02 04 04 04 02 02 02 02 03 04 04 02 03 04 04 04 03 04 04 03 04 03 04 03 04 03 03 03 03 03 03 04 04 04 04 04 04 04 04 04 04
! ! ! ! ! ! ! !
DSCP DSCP DSCP DSCP DSCP DSCP DSCP DSCP
0 => Q2; DSCP CS1 => Q1 AF11/AF12/AF13 => Q1 CS2 and AF21 => Q4 AF22/AF23 => Q4 CS3, 25 and AF31 => Q4 CS4 and AF41/AF42/AF43 => Q4 EF => Q3; DSCP CS6 => Q4 CS7 => Q4
CAT4500-SUP4#
show qos interface
The Catalyst 4500 show qos interface verification command displays the global state of QoS (enabled or not), the trust state of an interface, as well as any queuing/shaping parameters that have been defined for the interface. In the first example below, the show qos interface command is being applied on an access-edge FastEthernet interface that has been configured to conditionally-trust Cisco IP Phones. Furthermore, the output reports that Q3 has been enabled as the priority-queue on this interface and is shaped to 30 Mbps (30%). Bandwidth cannot be assigned for non-priority queues on this interface, as is indicated by the “N/A” entries under the bandwidth column. In the second example below, the show qos interface command is being applied to a GigabitEthernet uplink interface which as been configured to trust-DSCP. As before, Q3 has been enabled as the priority-queue and has been shaped to 30%, which now translates to 300 Mbps. Bandwidth is assignable on this interface and therefore Q1 is allocated 50 Mbps (5%), Q2 is allocated 250 Mbps (25%), Q3 is allocated 300 Mbps (30%), and Q4 is allocated 400 Mbps (40%).
Example 2-45 Show QoS Interface Verification for a Catalyst 4500 Switch
CAT4500-SUP4#show qos interface FastEthernet2/1 QoS is enabled globally Port QoS is enabled Administrative Port Trust State: 'cos' Operational Port Trust State: 'cos' Trust device: cisco-phone Default DSCP: 0 Default CoS: 0 Appliance trust: none Tx-Queue Bandwidth ShapeRate Priority QueueSize
Enterprise QoS Solution Reference Network Design Guide
2-76
Version 3.3
Chapter 2
Campus QoS Design Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
1 2 3 4
(bps) N/A N/A N/A N/A
(bps) disabled disabled 30000000 disabled
N/A N/A high N/A
(packets) 240 240 240 240
CAT4500-SUP4#
CAT4500-SUP4#show qos interface GigabitEthernet1/1 QoS is enabled globally Port QoS is enabled Administrative Port Trust State: 'dscp' Operational Port Trust State: 'dscp' Trust device: none Default DSCP: 0 Default CoS: 0 Appliance trust: none Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 50000000 disabled N/A 1920 2 250000000 disabled N/A 1920 3 300000000 300000000 high 1920 4 700000000 disabled N/A 1920 CAT4500-SUP4#
Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
This section includes the following topics:
• • • • • • • • • •
Catalyst 6500 QoS Configuration and Design Overview Catalyst 6500—CatOS Defaults and Recommendations Catalyst 6500—Trusted Endpoint Model Catalyst 6500 Auto QoS VoIP Model Catalyst 6500—Untrusted PC + SoftPhone with Scavenger-Class QoS Model Catalyst 6500—Untrusted Server with Scavenger-Class QoS Model Catalyst 6500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Basic) Model Catalyst 6500—Conditionally-Trusted IP Phone + PC with Scavenger-Class QoS (Advanced) Model Catalyst 6500—Queuing and Dropping Catalyst 6500—PFC3 Distribution-Layer (IOS) Per-User Microflow Policing
Catalyst 6500 QoS Configuration and Design Overview
The Catalyst 6500 is the undisputed flagship of the Cisco family of LAN switches, as it is the most powerful and flexible switching platform. As such, it can be found in all three layers of a campus network (Access, Distribution, and Core). When configured as an access layer switch, the recommended software for the Supervisor is CatOS; when configured as a distribution or core layer switch, the recommended software is Cisco IOS. Furthermore, at the time of writing, Catalyst 6500 IOS does not yet support AutoQoS nor the conditional-trust feature, therefore only CatOS examples of these models are given. However, both
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-77
Chapter 2 Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
Campus QoS Design
AutoQoS VoIP and conditional trust have been committed for future releases of Catalyst 6500 IOS. The QoS design recommendations for a Catalyst 6500 switch at the access layer are summarized in Figure 2-22; the corresponding recommendations for Catalyst 6500s deployed in the distribution or core layers is shown in Figure 2-23.
Figure 2-22 Access Layer (CatOS) Catalyst 6500 QoS Design Options
Access-Edges
Trusted-Endpoint Model AutoQoS–VoIP Model PC + SoftPhone + Scavenger Model Trust-DSCP Untrusted Server + Scavenger Model IP Phone + PC + Scavenger (Basic) Model IP Phone + PC + Scavenger (Adv) Model
132550
Uplinks to Distribution Layer
Globally-Defined Linecard-Dependant Queuing + Dropping
Enable QoS Globally
Figure 2-23
Distribution and/or Core Layer (IOS) Catalyst 6500 QoS Design
Uplinks from Access Layer Only
Distribution Layer: Enable QoS Globally Optional (PFC3 Only): Per-User Microflow Policing Interface-Group Line Card-Dependent Queuing + Dropping
Trust-DSCP
Interswitch Links Core Layer: Enable QoS Globally Interface-Group Line Card-Dependent Queuing + Dropping
224820
Trust-DSCP
Interswitch Links
Note
To narrow the scope of our discussion to the most current and relevant versions of the Catalyst 6500 switch-family, only the Catalyst 6500 with Supervisor 2 (PFC2) and Supervisor 720 (PFC3) be examined in this design chapter. For discussions of older versions of Catalyst 6000/6500s (such as Supervisor 1, 1a with/without a PFC), refer to the Cisco Press book, Cisco Catalyst QoS: Quality of Service in Campus Networks, by Mike Flannagan, Richard Froom and Kevin Turek.
Enterprise QoS Solution Reference Network Design Guide
2-78
Version 3.3
Chapter 2
Campus QoS Design Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
QoS is globally disabled by default on Catalyst 6500s running either CatOS or IOS. When QoS is globally disabled, then all frames/packets that are passed-through the switch remain unaltered (which is equivalent to a trust CoS and trust DSCP state on all ports). When QoS is globally enabled, however, then all DSCP and CoS values are (by default) set to 0 (which is equivalent to an untrusted state on all ports). The commands to enable and verify QoS globally on both CatOS and IOS Catalyst 6500s are shown below.
Example 2-46 Enabling QoS Globally on a Catalyst 6500—CatOS
CAT6500-PFC2-CATOS> (enable) set qos enable QoS is enabled. CAT6500-PFC2-CATOS> (enable)
CAT6500-PFC2-CATOS> (enable) show qos status QoS is enabled on this switch. CAT6500-PFC2-CATOS> (enable)
Example 2-47 Enabling QoS Globally on a Catalyst 6500—IOS
CAT6500-PFC2-IOS(config)#mls qos CAT6500-PFC2-IOS(config)#end CAT6500-PFC2-IOS#
CAT6500-PFC2-IOS#show mls qos QoS is enabled globally Microflow policing is enabled globally Vlan or Portchannel(Multi-Earl) policies supported: Yes ----- Module [2] ----QoS global counters: Total packets: 65 IP shortcut packets: 0 Packets dropped by policing: 0 IP packets with TOS changed by policing: 0 IP packets with COS changed by policing: 0 Non-IP packets with COS changed by policing: 0 CAT6500-PFC2-IOS#
Catalyst 6500—CatOS Defaults and Recommendations
CatOS specifies a number of default QoS settings per-port, which do not appear in the normal configuration output. However it is beneficial to be aware of what these defaults are and what they do, so as not to override them by mistake. For example, CatOS allows the QoS policy-source to be defined by the local configuration or by the Common Open Policy Source (COPS) protocol, referring to a COPS Policy-Decision Point (PDP) Server. COPS is a QoS administration protocol that is both dynamic and scalable, but unfortunately it never gained mainstream acceptance. It is recommended to leave the switch’s default policy-source as local (except of course in the extremely rare occurrence that COPS is actually deployed on the network).
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-79
Chapter 2 Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
Campus QoS Design
Additionally, QoS policies may be applied to VLANs or to ports. There was never any significant advantage of using one base over the other; however, AutoQoS tools favor port-based QoS, as it is marginally simpler to configure. Port-based QoS is the default per-port setting and all examples in this chapter are configured using port-based QoS. All ports (once QoS has been globally enabled) are set to an untrusted state by default. Also, by default, the trust-extension state is set to untrusted and the extended-CoS is correspondingly set to 0. All packets received through an untrusted port (whether the untrusted port is the actual switch port or the extended switch port in the back of a Cisco IP Phone) are marked to a CoS value of 3, by default. This default marking should be set instead to 0 on all ports connected to untrusted endpoints by using the command set port qos mod/port cos 0. Furthermore, on all ports that are connected to conditionally-trusted endpoints (like Cisco IP Phones) it is recommended to use the command set port qos mod/port cos 0 in conjunction with the command set port qos mod/port cos-ext 0. It is recommended to leave all these port QoS settings at their defaults, with the exception of trust and cos/cos-ext—depending on the access edge model to be applied to the port, as is discussed in additional detail below. Another Catalyst-OS default behavior to keep in mind is that ACLs and aggregate policers cannot be applied to more than one port in the same manner as these can when configured in IOS. For example, if an aggregate policer called POLICE-VOIP was defined to rate-limit flows to 128 kbps and if this policer were applied to two separate ports in CatOS, then it would rate limit flows from both ports to combined total of 128 kbps, instead of (the preferred behavior of) limiting flows to 128 kbps on a per-port basis (as is the case when configured in IOS). To work around this default behavior, ACLs and aggregate policers have to be uniquely defined on a per-port basis. To facilitate the administration of this additional configuration complexity, it is recommended that all CatOS ACLs and aggregate policers be defined with names that include the module and port they are to be applied to. For example, the previously defined aggregate policer POLICE-VOIP would become POLICE-VOIP-3-1 when applied to port 3/1 and POLICE-VOIP-3-2 when applied to port 3/2. This is the nomenclature adopted in the examples to follow in this chapter.
Note
Administrators should keep in mind the maximum number of aggregate policers that can be configured via CatOS on a given Catalyst 6500 switch (currently 1023) when designing their access-edge policies. Depending on the chassis/linecard combination, this maximum number of aggregate policers may present scaling limitations to the advanced models presented in this design chapter.
Catalyst 6500—Trusted Endpoint Model
This section includes the following topics:
• •
Configuration Catalyst 6500 CatOS QoS Verification Commands
Configuration
For most Catalyst 6500 switch ports, setting the trust state to trust DSCP is a relatively straightforward command (in either CatOS or in IOS). In this first example, DSCP trust is configured on a port in CatOS; in the second, DSCP trust is configured on a port/interface in IOS.
Enterprise QoS Solution Reference Network Design Guide
2-80
Version 3.3
Chapter 2
Campus QoS Design Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
Example 2-48 Catalyst 6500 CatOS—Trusted Endpoint Model
CAT6500-PFC2-CATOS> (enable) set port qos 3/1 trust trust-dscp Port 3/1 qos set to trust-dscp. CAT6500-PFC2-CATOS> (enable)
Catalyst 6500 CatOS QoS Verification Commands
Catalyst 6500 CatOS QoS verification commands include the following:
• •
show port qos show qos status
show port qos
The Catalyst 6500 CatOS show port qos verification command returns the configured and runtime QoS states of a port. These may differ, as certain commands need to be committed (programmed into hardware) before they become effective. In the example below, the switch has QoS globally enabled and the source of QoS policy decisions is the local configuration, as opposed to a Common-Open Policy Source Policy-Decision Point (COPS PDP). Furthermore, the output shows that the port is configured for port-based QoS (by default) and has been set to trust DSCP from connected endpoints. No trust-extension has been configured, as this is not a conditionally-trusted endpoint model. The output includes the linecard’s queuing capabilities: 1P3Q1T (Transmit) and 1P1Q0T (Receive), as well as any ACLs that may be mapped to the port (however, no ACLs have been mapped to this port in this particular example).
Example 2-49 Show Port QoS Verification for a Catalyst 6500—CatOS Switch
CAT6500-PFC2-CATOS> (enable) show port qos 3/1 QoS 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 ----- -------------- -------------- ------------- ------------3/1 port-based port-based COPS local Port Trust Type Trust Type Def CoS Def CoS config runtime config runtime ----- ------------ ------------ ------------ ------------- ------- ------3/1 1p3q1t 1p1q0t trust-dscp trust-dscp 0 0 Port Ext-Trust Ext-Cos Trust-Device ----- --------- ------- -----------3/1 untrusted 0 none (*)Runtime trust type set to untrusted. Config: Port ACL name Type ----- -------------------------------- ---No ACL is mapped to port 3/1. Runtime: Port ACL name Type ----- -------------------------------- ---TxPort Type RxPort Type
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-81
Chapter 2 Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
Campus QoS Design
No ACL is mapped to port 3/1. CAT6500-PFC2-CATOS> (enable)
On non-GigabitEthernet linecards that use 2Q2T Transmit Queuing and 1Q4T Receive queuing (such as the WS-X6248-RJ-xx and WS-X6348-RJ-xx linecards), a hardware limitation prevents the proper functioning of port-based trust (which affects trust-cos, trust-ipprec, and trust-dscp). The show port qos command can be used to determine if the linecard is a 2Q2T-Tx/1Q4T-Rx linecard. These cards also listed in Table 2-5. On such linecards, a workaround ACL can be used to achieve trust-functionality for trust-cos, trust-ipprec, and trust-dscp. The workaround ACL for trust-DSCP functionality on such linecards is shown below.
Example 2-50 Trust-DSCP Workaround ACL for Catalyst 6500 2Q2T-TX/1Q4T-Rx Non-Gigabit Linecards
CAT6500-PFC2-CATOS> (enable) set qos acl ip TRUST-DSCP trust-dscp any TRUST-DSCP editbuffer modified. Use 'commit' command to apply changes. CAT6500-PFC2-CATOS> (enable) commit qos acl TRUST-DSCP QoS ACL 'TRUST-DSCP' successfully committed. CAT6500-PFC2-CATOS> (enable) CAT6500-PFC2-CATOS> (enable) set qos acl map TRUST-DSCP 4/1
Note
To apply the QoS ACL you have defined (above), the ACL must be committed to hardware. The process of committing copies the ACL from a temporary editing buffer to the PFC hardware. Once resident in the PFC memory, the policy defined in the QoS ACL can be applied to all traffic that matches the Access Control Entries (ACEs). For ease of configuration, most administrators issue a commit all command, however you can commit a specific ACL (by name) to be sent from the editing buffer to PFC memory, as shown above. In this second example, DSCP trust is configured on a port/interface in IOS.
Example 2-51 Catalyst 6500 IOS—Trusted Endpoint Example
CAT6500-PFC2-IOS(config)#interface FastEthernet3/1 CAT6500-PFC2-IOS(config-if)#mls qos trust dscp
Other Catalyst 6500 CatOS QoS verification commands include the following:
• •
show mls qos show mls qos interface
Note
The ACL Trust workaround to the 2Q2T non-GigabitEthernet linecards (such as the such as the WS-X6248-RJ-xx and WS-X6348-RJ-xx) limitation of not supporting trust only applies in the access Layer of the campus (where CatOS is the recommended software for the Catalyst 6500). In the distribution and core layers, where IOS is the preferred software, all interfaces are recommended to be GigabitEthernet or higher.
Catalyst 6500 Auto QoS VoIP Model
At the time of writing, AutoQoS VoIP is only supported on the Catalyst 6500 in CatOS.
Enterprise QoS Solution Reference Network Design Guide
2-82
Version 3.3
Chapter 2
Campus QoS Design Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
The AutoQoS VoIP macro for the Catalyst 6500 CatOS is divided into these two separate components:
•
Global AutoQoS command (set qos auto)—Deals with all switch-wide related QoS settings that are not specific to any given interface, including CoS-to-queue maps, CoS-to-DSCP maps, and WRED settings for specific port types and global mappings. Port-specific automatic QoS command (set port qos mod/port autoqos)—Configures all inbound QoS parameters for a particular port to support IP Telephony devices.
•
The port-specific AutoQoS VoIP command for the Catalyst 6500 in CatOS supports the the following keyword options:
• • •
autoqos voip ciscoipphone autoqos voip ciscosoftphone autoqos trust [cos | dscp]
The effects of enabling the Global AutoQoS command set qos auto on the Catalyst 6500 in CatOS are as follows.
Example 2-52 Catalyst 6500 Global AutoQoS Generated Configuration
set qos autoqos --------------set qos enable set set set set set set set set set set set set set qos qos qos qos qos qos qos qos qos qos qos qos qos policy-source local ipprec-dscp-map 0 10 18 26 34 46 48 56 cos-dscp-map 0 10 18 26 34 46 48 56 dscp-cos-map 0-7:0 8-15:1 16-23:2 24-31:3 32-39:4 40-47:5 48-55:6 56-63:7 acl default-action ip dscp 0 map 2q2t tx queue 2 2 cos 5,6,7 map 2q2t tx queue 2 1 cos 1,2,3,4 map 2q2t tx queue 1 1 cos 0 drop-threshold 2q2t tx queue 1 100 100 drop-threshold 2q2t tx queue 2 80 100 drop-threshold 1q4t rx queue 1 50 60 80 100 txq-ratio 2q2t 80 20 wrr 2q2t 100 255
set set set set set set set set set set set set set set set set set set set set set
qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos
map 1p3q1t tx 1 1 cos 0 map 1p3q1t tx 2 1 cos 1,2 map 1p3q1t tx 3 1 cos 3,4 map 1p3q1t tx 3 0 cos 6,7 map 1p3q1t tx 4 cos 5 wrr 1p3q1t 20 100 200 wred 1p3q1t queue 1 70:100 wred 1p3q1t queue 2 70:100 wred 1p3q1t queue 3 70:90 map 1p1q0t rx 1 cos 0,1,2,3,4 map 1p1q0t rx 2 cos 5,6,7 rxq-ratio 1p1q0t 80 20 map 1p2q2t tx 1 2 cos 0 map 1p2q2t tx 2 1 cos 1,2,3,4 map 1p2q2t tx 2 2 cos 6,7 map 1p2q2t tx 3 cos 5 txq-ratio 1p2q2t 75 15 15 wrr 1p2q2t 50 255 wred 1p2q2t queue 1 1 40:70 wred 1p2q2t queue 1 2 70:100 wred 1p2q2t queue 2 1 40:70
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-83
Chapter 2 Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
Campus QoS Design
set set set set set set set set set set set set set set set set set set set set set set
qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos qos
wred 1p2q2t queue 2 2 map 1p1q4t rx 1 1 cos map 1p1q4t rx 1 3 cos map 1p1q4t rx 1 4 cos map 1p1q4t rx 2 cos 5 drop-threshold 1p1q4t
70:100 0 1,2,3,4 6,7 rx queue 1 50 60 80 100
map 1p2q1t tx 1 1 cos 0 map 1p2q1t tx 2 1 cos 1,2,3,4 map 1p2q1t tx 2 cos 6,7 map 1p2q1t tx 3 cos 5 txq-ratio 1p2q1t 75 15 15 wrr 1p2q1t 50 255 wred 1p2q1t queue 1 70:100 wred 1p2q1t queue 2 70:100 map 1p1q8t rx 1 1 cos 0 map 1p1q8t rx 1 5 cos 1,2 map 1p1q8t rx 1 8 cos 3,4 map 1p1q8t rx 2 cos 5,6,7 wred 1p1q8t queue 1 1 40:70 wred 1p1q8t queue 1 5 60:90 wred 1p1q8t queue 1 8 70:100 rxq-ratio 1p1q8t 80 20
set qos policed-dscp-map 0:0 set qos policed-dscp-map 1:1 set qos policed-dscp-map 2:2
set qos policed-dscp-map 61:61 set qos policed-dscp-map 62:62 set qos policed-dscp-map 63:63
set qos policed-dscp-map excess-rate 0:0 set qos policed-dscp-map excess-rate 1:1 set qos policed-dscp-map excess-rate 2:2
set qos policed-dscp-map excess-rate 61:61 set qos policed-dscp-map excess-rate 62:62 set qos policed-dscp-map excess-rate 63:63
The effects of enabling the port-specific set port qos mod/port autoqos voip ciscoipphone command on the Catalyst 6500 in CatOS are as follows.
Example 2-53 Catalyst 6500 Port-Specific AutoQoS VoIP CiscoIPPhone Generated Configuration
set port qos mod/port --------------set port qos mod/port set port qos mod/port set port qos mod/port set port qos mod/port set port qos mod/port set port qos mod/port autoqos voip ciscoipphone policy-source local port-based cos 0 cos-ext 0 trust-ext untrusted trust-device ciscoipphone
If the port is on a 2Q2T-Tx/1Q4T-Rx (non-GigabitEthernet) linecard, the configuration is as follows:
set qos acl ip ACL_IP-PHONES trust-cos any
Enterprise QoS Solution Reference Network Design Guide
2-84
Version 3.3
Chapter 2
Campus QoS Design Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
commit qos acl ACL_IP-PHONES set qos acl map ACL_IP-PHONES mode/port set port qos mod/port trust trust-cos
If the port type is another port type, the configuration is as follows:
set port qos mod/port trust trust-cos
The effects of enabling the port-specific set port qos mod/port autoqos voip ciscosoftphone command on the Catalyst 6500 in CatOS are as follows.
Example 2-54 Catalyst 6500 Port-Specific AutoQoS VoIP CiscoSoftPhone Generated Configuration
set port qos mod/port autoqos voip ciscosoftphone --------------set port qos mod/port policy-source local set port qos mod/port port-based set port qos mod/port cos 0 set port qos mod/port cos-ext 0 set port qos mod/port trust-ext untrusted set port qos mod/port trust-device none set port qos mod/port trust untrusted set qos policer aggregate POLICE_SOFTPHONE-DSCP46-mod-port rate 320 burst 20 policed-dscp set qos policer aggregate POLICE_SOFTPHONE-DSCP26-mod-port rate 32 burst 8 policed-dscp set qos acl ip ACL_IP-SOFTPHONE-mod-port trust-dscp aggregate POLICE_SOFTPHONE-DSCP46-mod-port any dscp-field 46 set qos acl ip ACL_IP-SOFTPHONE-mod-port trust-dscp aggregate POLICE_SOFTPHONE-DSCP26-mod-port any dscp-field 26 commit qos acl ACL_IP-SOFTPHONE-mod-port set qos acl map ACL_IP-SOFTPHONE-mod-port mod/port
The effects of enabling the port-specific set port qos mod/port autoqos voip trust cos command on the Catalyst 6500 in CatOS are as follows.
Example 2-55 Catalyst 6500 Port-Specific AutoQoS VoIP Trust CoS Generated Configuration
set port qos mod/port --------------set port qos mod/port set port qos mod/port set port qos mod/port set port qos mod/port set port qos mod/port set port qos mod/port autoqos trust cos policy-source local port-based cos 0 cos-ext 0 trust-ext untrusted trust-device none
If the port is on a 2Q2T-Tx/1Q4T-Rx (non-GigabitEthernet) linecard, the configuration is as follows:
set qos acl ip ACL_IP-TRUSTCOS trust-cos any commit qos acl ACL_IP-TRUSTCOS set qos acl map ACL_IP-TRUSTCOS mode/port set port qos mod/port trust trust-cos
If the port type is another port type, the configuration is as follows:
set port qos mod/port trust trust-cos
The AutoQoS VoIP command with the Trust-DSCP option is virtually identical to the Trust-CoS option (albeit the final configuration commands are set port qos mod/port trust trust-dscp instead of trust-cos).
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-85
Chapter 2 Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
Campus QoS Design
Catalyst 6500—Untrusted PC + SoftPhone with Scavenger-Class QoS Model
This section includes the following topics:
• •
Configuration Catalyst 6500 CatOS QoS Verification Commands
Configuration
The radical difference in syntax between CatOS and IOS becomes increasingly apparent as more complex access edge models are presented. In the Untrusted PC + SoftPhone + Scavenger Model, shown below, per-application aggregate policers are defined—one each for SoftPhone VoIP traffic, SoftPhone call signaling traffic, and PC Data traffic. Then an ACL (titled “SOFTPHONE-PC-mod-port”) with multiple ACEs is defined, with each ACE referencing its associated aggregate policer. Once complete, the ACL is committed to PFC memory and then mapped to the desired switch port(s). Switch responses to the commands have been omitted to simplify the example.
Example 2-56 Catalyst 6500 CatOS—Untrusted PC + SoftPhone + Scavenger Model Configuration
CAT6500-PFC2-CATOS> (enable) set qos policed-dscp-map 0,24,46:8 ! Excess traffic marked DSCP 0 or CS3 or EF will be remarked to CS1 CAT6500-PFC2-CATOS> (enable) CAT6500-PFC2-CATOS> (enable) set qos policer aggregate SOFTPHONE-VOICE-3-1 rate 128 burst 8000 policed-dscp ! Defines the policer for SoftPhone VoIP traffic CAT6500-PFC2-CATOS> (enable) set qos policer aggregate SOFTPHONE-SIGNALING-3-1 rate 32 burst 8000 policed-dscp ! Defines the policer for SoftPhone call signaling traffic CAT6500-PFC2-CATOS> (enable) set qos policer aggregate PC-DATA-3-1 rate 5000 burst 8000 policed-dscp ! Defines the policer for PC Data traffic CAT6500-PFC2-CATOS> (enable) CAT6500-PFC2-CATOS> (enable) set qos acl ip SOFTPHONE-PC-3-1 dscp 46 aggregate SOFTPHONE-VOICE-3-1 udp any any range 16384 32767 ! Binds ACL to policer and marks in-profile SoftPhone VoIP to DSCP EF CAT6500-PFC2-CATOS> (enable) set qos acl ip SOFTPHONE-PC-3-1 dscp 24 aggregate SOFTPHONE-SIGNALING-3-1 tcp any any range 2000 2002 ! Binds ACL to policer marks in-profile call signaling to DSCP CS3 CAT6500-PFC2-CATOS> (enable) set qos acl ip SOFTPHONE-PC-3-1 dscp 0 aggregate PC-DATA-3-1 any ! Binds ACL to policer and marks in-profile PC Data traffic to DSCP 0 CAT6500-PFC2-CATOS> (enable) CAT6500-PFC2-CATOS> (enable) commit qos acl SOFTPHONE-PC-3-1 ! Commits ACL to PFC hardware CAT6500-PFC2-CATOS> (enable) CAT6500-PFC2-CATOS> (enable) set port qos 3/1 cos 0 ! Sets CoS to 0 for all untrusted packets CAT6500-PFC2-CATOS> (enable) set port qos 3/1 trust untrusted ! Sets the port trust state to untrusted CAT6500-PFC2-CATOS> (enable) set qos acl map SOFTPHONE-PC-3-1 3/1 ! Attaches ACL to switch port CAT6500-PFC2-CATOS> (enable)
Catalyst 6500 CatOS QoS verification commands for the Untrusted PC + Softphone + Scavenger model include the following:
•
show qos status
Enterprise QoS Solution Reference Network Design Guide
2-86
Version 3.3
Chapter 2
Campus QoS Design Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
• • • • •
show qos maps show port qos show qos acl show qos policer show qos statistics
show qos maps
The Catalyst 6500 CatOS show qos maps verification command is fairly similar to the show mls qos maps MLS QoS verification command. It returns the configured CoS-DSCP, IPPrec-DSCP, DSCP-CoS, and Normal-Rate and Excess-Rate Policed-DSCP Maps. The command can return configured maps (which may or may not be committed to the PFC) or runtime maps. In the (truncated) runtime example below, all maps are at their default states, with the exception of the Normal-Rate Policed-DSCP map, which has DSCP 0, CS3 (24), and EF (46) mapped for out-of-profile markdown to DSCP CS1 (8).
Example 2-57 Show QoS Maps Verification for Catalyst 6500 Switch—CatOS
CAT6500-PFC2-CATOS> (enable) show qos maps runtime CoS - DSCP map: CoS DSCP -----0 0 1 8 2 16 3 24 4 32 5 40 6 48 7 56 IP-Precedence - DSCP map: IP-Prec DSCP ---------0 0 1 8 2 16 3 24 4 32 5 40 6 48 7 56 DSCP - CoS map: DSCP -------------------------------0-7 8-15 16-23 24-31 32-39 40-47 48-55 56-63
CoS --0 1 2 3 4 5 6 7
DSCP - Policed DSCP map normal-rate: DSCP Policed DSCP -------------------------------- ------------
Enterprise QoS Solution Reference Network Design Guide Version 3.3
2-87
Chapter 2 Catalyst 6500 PFC2/PFC3—QoS Considerations and Design
Campus QoS Design
1 2 3 4 5 6 7 0,8,24,46 9 10