Cisco IOS Quality of Service Solutions Configuration Guide

Release 12.2

Corporate 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 526-4100

Customer Order Number: DOC-7811745= Text Part Number: 78-11745-01

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. AccessPath, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, PIX, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All Thats Possible, and Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries. All other brands, names, or trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0102R) Cisco IOS Quality of Service Solutions Configuration Guide Copyright 2001, Cisco Systems, Inc. All rights reserved.

C O N T E N T S

About Cisco IOS Software Documentation Documentation Objectives Audience

xxvii xxvii xxvii xxvii

xxvii

Documentation Organization Documentation Modules Master Indexes Document Conventions Obtaining Documentation World Wide Web
xxx

Supporting Documents and Resources

xxxi xxxii

xxx

xxxii xxxii xxxiii

Documentation CD-ROM Ordering Documentation Documentation Feedback Cisco.com

xxxiii

xxxiii xxxiii

Obtaining Technical Assistance Technical Assistance Center

xxxiv xxxiv

Contacting TAC by Using the Cisco TAC Website Contacting TAC by Telephone Using Cisco IOS Software Getting Help
xxxvi xxxvii xxxix xxxv xxxv xxxiv

Understanding Command Modes

Example: How to Find Command Options Using the no and default Forms of Commands Saving Configuration Changes Identifying Supported Platforms Using Feature Navigator
xli xli xl

Filtering Output from the show and more Commands

xli

xl

Using Software Release Notes Quality of Service Overview What Is Quality of Service? About QoS Architecture
QC-1 QC-1

QC-1
Cisco IOS Quality of Service Solutions Configuration Guide

iii

Contents

Who Could Benefit from Using Cisco IOS QoS? Why Deploy Cisco IOS QoS? End-to-End QoS Models Best-Effort Service Integrated Service Cisco QoS Features Classification
QC-4 QC-4 QC-4 QC-3 QC-3

QC-2

Differentiated Service
QC-5 QC-5

IP Precedence

QC-6 QC-6 QC-7 QC-7

Policy-Based Routing BGP Policy Propagation

Committed Access Rate (Packet Classification) Class-Based Packet Marking

QC-8 QC-8 QC-8

QoS for Virtual Private Networks Congestion Management FIFO Queueing PQ CQ

QC-9 QC-10 QC-9 QC-8

Network-Based Application Recognition What Is Congestion in Networks?

QC-9

Frame Relay PVC PQ

QC-10

WFQ and Distributed WFQ IP RTP Priority LLQ

QC-11 QC-11 QC-11 QC-11 QC-10

QC-10 QC-10

CBWFQ and Distributed CBWFQ Frame Relay IP RTP Priority Distributed LLQ Congestion Avoidance WRED DWRED
QC-12 QC-12 QC-12 QC-13

QC-11

LLQ for Frame Relay

Flow-Based WRED Policing and Shaping CAR Rate Limiting

DiffServ Compliant WRED

QC-13 QC-13

Cisco IOS Quality of Service Solutions Configuration Guide

iv

Contents

Traffic Policing Shaping Signalling

QC-14 QC-14

QC-14

Link Efficiency Mechanisms

QC-15 QC-15

Link Fragmentation and Interleaving Compressed Real-Time Protocol QoS Solutions

QC-16 QC-16 QC-17

QC-16 QC-16

Distributed Compressed Real-Time Protocol IP to ATM CoS

QoS Features for Voice

Differentiated Services Implementations Modular QoS Command-Line Interface Security Device Manager Classification Classification Overview About IP Precedence
QC-21 QC-22 QC-17 QC-17

QC-17

How the IP Precedence Bits Are Used to Classify Packets Setting or Changing the IP Precedence Value Policy-Based Routing How It Works
QC-24 QC-24 QC-25 QC-25 QC-23

QC-22

When Should You Use Policy-Based Routing? QoS Policy Propagation via Border Gateway Protocol Restrictions
QC-25 QC-26 QC-26 QC-27

Committed Access Rate

Class-Based Packet Marking CoS Value Marking ATM CLP Bit Setting Additional Statistics Benefits
QC-28

IP Precedence and IP DSCP Marking

QC-27 QC-27

QoS Group Value Marking

QC-27

Support for ATM Virtual Circuits

QC-28

QC-28

Packet Marking Through IP Precedence, QoS Group, CoS Value, and IP DSCP Value Setting QC-28

Cisco IOS Quality of Service Solutions Configuration Guide

Contents

Improved Bandwidth Management on ATM Networks Restrictions Prerequisites Restrictions

QC-29 QC-29 QC-29

QC-28

QoS for Virtual Private Networks

QC-30

Network-Based Application Recognition

QC-30 QC-33 QC-33

Classification of HTTP by URL, HOST, or MIME Protocol Discovery

QC-34 QC-35

Classification of Citrix ICA Traffic by Application Name Packet Description Language Module Memory Management Supported Protocols Restrictions
QC-40 QC-43 QC-43 QC-35 QC-36

Configuring Policy-Based Routing Enabling PBR

QC-43

Policy-Based Routing Configuration Task List Enabling Fast-Switched PBR Enabling Local PBR
QC-45 QC-45 QC-44

Enabling CEF-Switched PBR Equal Access Example

Policy-Based Routing Configuration Examples

QC-46 QC-46

QC-46

Differing Next Hops Example

Configuring QoS Policy Propagation via Border Gateway Protocol Policy Propagation via BGP Configuration Task Overview Policy Propagation via BGP Configuration Task List
QC-48 QC-48 QC-47

QC-47

Configuring Policy Propagation Based on Community Lists Configuring Policy Propagation Based on an Access List Monitoring Policy Propagation via BGP
QC-50 QC-51

Configuring Policy Propagation Based on the Autonomous System Path Attribute

QC-50

QC-49

Policy Propagation via BGP Configuration Examples Configuring Committed Access Rate
QC-55

Committed Access Rate Configuration Task List Configuring CAR and DCAR for All IP Traffic Configuring CAR and DCAR Policies
QC-57

QC-55 QC-56

Cisco IOS Quality of Service Solutions Configuration Guide

vi

Contents

IP Precedence or MAC Address IP Access List

QC-58

QC-58

Configuring a Class-Based DCAR Policy Monitoring CAR and DCAR Subrate IP Services Example
QC-59

QC-58

CAR and DCAR Configuration Examples

QC-60

QC-59

Input and Output Rate Limiting on an Interface Example Rate Limiting in an IXP Example
QC-60 QC-61 QC-63 QC-63

QC-60

Rate Limiting by Access List Example Configuring Class-Based Packet Marking Configuring an IP Precedence Value Configuring an IP DSCP Value Configuring a QoS Group Value
QC-64 QC-65

Class-Based Packet Marking Configuration Task List

QC-64

Configuring a Class of Service Value

QC-65 QC-66 QC-66 QC-67

Changing an ATM Cell Loss Priority Bit Setting Class-Based Packet Marking Configuration Examples Configuring an IP Precedence Value Example Configuring an IP DSCP Value Example Configuring a QoS Group Value Example Changing the ATM CLP Value Example Configuring QoS for Virtual Private Networks QoS for VPNs Configuration Task List Configuring QoS for VPNs Verifying QoS for VPNs
QC-69 QC-70 QC-69 QC-67 QC-68

Verifying the Class-Based Packet Marking Feature

QC-67

Configuring a Classifying CoS Values Example

QC-68

QC-68

QC-69

Verifying QoS for VPNs with the show interfaces Command Verifying QoS for VPNs with the show crypto map Command Monitoring and Maintaining QoS for VPNs QoS for VPNs Configuration Examples
QC-71 QC-71

QC-70 QC-71

Configuring QoS for VPNs for GRE and IPIP Tunnel Protocols Example Configuring QoS for VPNs for L2F and L2TP Tunnel Protocols Example Configuring QoS for VPNs for IPSec Tunnel Protocols Example
QC-72

QC-72 QC-72

Cisco IOS Quality of Service Solutions Configuration Guide

vii

Contents

Configuring Network-Based Application Recognition NBAR Configuration Task List Configuring a Traffic Class Configuring a Traffic Policy
QC-73 QC-74 QC-75 QC-75

QC-73

Attaching a Traffic Policy to an Interface Verifying Traffic Policy Configuration Monitoring and Maintaining NBAR NBAR Configuration Example
QC-76 QC-76

QC-75

Configuring a Traffic Class with NBAR Example Congestion Management Congestion Management Overview Why Use Congestion Management? FIFO Queueing
QC-83 QC-83 QC-84 QC-79 QC-80 QC-81

QC-76

Deciding Which Queueing Policy to Use Weighted Fair Queueing Restrictions

Flow-Based Weighted Fair Queueing

QC-86 QC-86

WFQ and IP Precedence WFQ and RSVP

QC-87

WFQ and Frame Relay Drop Policy Restrictions

QC-88 QC-88

QC-87 QC-87

Distributed Weighted Fair Queueing

Class-Based Weighted Fair Queueing CBWFQ Bandwidth Allocation Why Use CBWFQ? CBWFQ and RSVP Restrictions
QC-91 QC-91 QC-91

QC-89 QC-90

Distributed Class-Based Weighted Fair Queueing RSVP Interaction with DCBWFQ Benefits
QC-92 QC-93 QC-93 QC-92

QC-91

Restrictions Prerequisites IP RTP Priority

QC-93

Cisco IOS Quality of Service Solutions Configuration Guide

viii

Contents

IP RTP Priority Bandwidth Allocation Restrictions

QC-95 QC-96

QC-94

Frame Relay IP RTP Priority Restrictions Prerequisites

QC-97 QC-97

Frame Relay PVC Interface Priority Queueing

QC-96

Low Latency Queueing

QC-97 QC-98 QC-100 QC-100

LLQ Bandwidth Allocation

LLQ and Committed Burst Size Why Use LLQ? Restrictions

QC-100 QC-101

LLQ and per-VC Hold Queue Support for ATM Adapters

Distributed Low Latency Queueing Benefits

QC-102 QC-103 QC-104

QC-101 QC-102

Guaranteeing Bandwidth with the priority Command Restrictions Prerequisites Restrictions Prerequisites How It Works Custom Queueing How It Works

Low Latency Queueing for Frame Relay

QC-105 QC-105 QC-105

QC-104

QC-106 QC-106 QC-107

Determining Byte Count Values for Queues How the Byte Count Is Used Determining the Byte Count Window Size Why Use CQ? Restrictions Priority Queueing How It Works
QC-109 QC-109 QC-110 QC-110 QC-110 QC-108 QC-108

How Packets Are Classified for Priority Queueing Why Use Priority Queueing? Restrictions
QC-111 QC-112 QC-111

QC-111

Bandwidth Management

Cisco IOS Quality of Service Solutions Configuration Guide

ix

Contents

Configuring Weighted Fair Queueing Configuring WFQ

QC-114

QC-113 QC-113

Flow-Based Weighted Fair Queueing Configuration Task List Monitoring Fair Queueing
QC-115

Distributed Weighted Fair Queueing Configuration Task List Configuring Flow-Based DWFQ
QC-116 QC-116 QC-117

QC-115

Configuring QoS-Group-Based DWFQ Monitoring DWFQ Defining Class Maps

QC-117

Configuring Type of Service-Based DWFQ

Class-Based Weighted Fair Queueing Configuration Task List

QC-118 QC-118 QC-119

QC-117

Configuring Class Policy in the Policy Map Configuring Class Policy Using Tail Drop

Configuring Class Policy Using WRED Packet Drop Configuring the Class-Default Class Policy
QC-120

QC-120

Attaching the Service Policy and Enabling CBWFQ

QC-122 QC-123 QC-123

Modifying the Bandwidth for an Existing Policy Map Class Modifying the Queue Limit for an Existing Policy Map Class Configuring the Bandwidth Limiting Factor Deleting Classes
QC-124 QC-124 QC-123

Deleting Policy Maps

Verifying Configuration of Policy Maps and Their Classes Modifying the Bandwidth for an Existing Traffic Class Modifying the Queue Limit for an Existing Traffic Class Monitoring and Maintaining DCBWFQ IP RTP Priority Configuration Task List Configuring IP RTP Priority Verifying IP RTP Priority
QC-127 QC-127 QC-126 QC-127

QC-124 QC-125

Distributed Class-Based Weighted Fair Queueing Configuration Task List

QC-125 QC-126

Configuring the Bandwidth Limiting Factor

QC-128

Monitoring and Maintaining IP RTP Priority Configuring Frame Relay IP RTP Priority Verifying Frame Relay IP RTP Priority

QC-128 QC-128

Frame Relay IP RTP Priority Configuration Task List

QC-128 QC-129

Monitoring and Maintaining Frame Relay IP RTP Priority

QC-129

Cisco IOS Quality of Service Solutions Configuration Guide

Contents

Frame Relay PVC Interface Priority Configuration Task List Configuring PVC Priority in a Map Class Assigning a Map Class to a PVC Verifying Frame Relay PIPQ
QC-130 QC-130

QC-129

Enabling Frame Relay PIPQ and Setting Queue Limits

QC-131

QC-130

Monitoring and Maintaining Frame Relay PIPQ Low Latency Queueing Configuration Task List Configuring LLQ Verifying LLQ
QC-132

QC-131

QC-131

Configuring the Bandwidth Limiting Factor

QC-132 QC-133 QC-133

QC-132

Monitoring and Maintaining LLQ Distributed LLQ Configuration Task List

Configuring a Priority Queue for an Amount of Available Bandwidth Configuring a Priority Queue for a Percentage of Available Bandwidth Configuring a Transmission Ring Limit Verifying Distributed LLQ
QC-135 QC-135 QC-135 QC-136 QC-134

QC-133 QC-134

Verifying a Transmission Ring Limit

Monitoring and Maintaining Distributed LLQ Defining Class Maps

QC-136

Low Latency Queueing for Frame Relay Configuration Task List Configuring Class Policy in the Policy Map
QC-136

Configuring Class Policy for a LLQ Priority Queue Configuring the Class-Default Class Policy

QC-137 QC-137

Configuring Class Policy Using a Specified Bandwidth and WRED Packet Drop
QC-138 QC-139

Attaching the Service Policy and Enabling LLQ for Frame Relay Verifying Configuration of Policy Maps and Their Classes Monitoring and Maintaining LLQ for Frame Relay Configuring Burst Size in LLQ Configuration Task List Configuring the LLQ Bandwidth Configuring the LLQ Burst Size Verifying the LLQ Burst Size
QC-140 QC-140 QC-140 QC-139 QC-139

QC-139

Per-VC Hold Queue Support for ATM Adapters Configuration Task List Configuring the per-VC Hold Queue on an ATM Adapter Flow-Based WFQ Configuration Examples
QC-141 QC-141

QC-140

Verifying the Configuration of the per-VC Hold Queue on an ATM Adapter

QC-141

Cisco IOS Quality of Service Solutions Configuration Guide

xi

Contents

DWFQ Configuration Examples Flow-Based DWFQ Example ToS-Based DWFQ Example CBWFQ Configuration Examples Policy Creation Example

QC-141 QC-142 QC-142

QoS-Group-Based DWFQ Example

QC-143

QC-143 QC-144

Class Map Configuration Example

QC-144

Policy Attachment to Interfaces Example CBWFQ Using WRED Packet Drop Example

QC-144 QC-145 QC-145 QC-145

Display Service Policy Map Content Examples All Classes for All Service Policy Maps Specified Class for a Service Policy Map Distributed CBWFQ Configuration Examples Traffic Class Configuration Example Traffic Policy Creation Example IP RTP Priority Configuration Examples CBWFQ Configuration Example
QC-148

All Classes for a Specified Service Policy Map

QC-146

QC-146 QC-146

All Classes for All Service Policy Maps on a Specified Interface

QC-147 QC-147

Traffic Policy Attachment to an Interface Example

QC-148 QC-149 QC-149 QC-150

QC-148

Virtual Template Configuration Example Multilink Bundle Configuration Example Debug Example
QC-151

Frame Relay IP RTP Priority Configuration Examples Frame Relay PVC Interface PQ Configuration Examples LLQ Configuration Examples
QC-153 QC-153 QC-153 QC-154

QC-151 QC-151

Strict Priority Service to Matching RTP Packets Example

QC-152

ATM PVC Configuration Example

Virtual Template Configuration Example Multilink Bundle Configuration Example Distributed LLQ Configuration Examples

QC-155 QC-155 QC-156

Enabling PQ for an Amount of Available Bandwidth on an ATM Subinterface Example Enabling PQ for a Percentage of Available Bandwidth on an ATM Subinterface Example Limiting the Transmission Ring Limit on an ATM Interface Example
QC-156 QC-156

Limiting the Transmission Ring Limit on an ATM PVC Subinterface Example

Cisco IOS Quality of Service Solutions Configuration Guide

xii

Contents

LLQ for Frame Relay Configuration Examples Burst Size in LLQ Configuration Examples

QC-157

QC-158 QC-158

Per-VC Hold Queue Support for ATM Adapters Examples Configuring Custom Queueing
QC-159 QC-159

Custom Queueing Configuration Task List Defining the Custom Queue List

QC-160 QC-160

Specifying the Maximum Size of the Custom Queues Assigning Packets to Custom Queues Monitoring Custom Queue Lists Custom Queueing Configuration Examples Custom Queue List Defined Example
QC-161 QC-161 QC-162 QC-162

Maximum Specified Size of the Custom Queues Examples Packets Assigned to Custom Queues Examples Protocol Type Interface Type Default Queue
QC-162 QC-163 QC-163 QC-165 QC-165 QC-162

QC-162

Configuring Priority Queueing Defining the Priority List

Priority Queueing Configuration Task List

QC-165

Assigning Packets to Priority Queues Assigning the Priority List to an Interface Monitoring Priority Queueing Lists Priority Queueing Configuration Examples
QC-167

QC-166 QC-166

Specifying the Maximum Size of the Priority Queues

QC-167

QC-167 QC-167

Priority Queueing Based on Protocol Type Example Priority Queueing Based on Interface Example Priority List Assigned to an Interface Example Priority Queueing Using Multiple Rules Example Congestion Avoidance Congestion Avoidance Overview Tail Drop
QC-171 QC-172 QC-171

QC-168 QC-168

Maximum Specified Size of the Priority Queue Example

QC-168 QC-168

Weighted Random Early Detection

Cisco IOS Quality of Service Solutions Configuration Guide

xiii

Contents

About Random Early Detection How It Works

QC-172

QC-172

Packet Drop Probability

QC-173 QC-173 QC-174

How TCP Handles Traffic Loss About WRED

QC-175 QC-175

How the Router Interacts with TCP Why Use WRED? How It Works Restrictions How It Works Average Queue Size
QC-177

QC-175 QC-176

Distributed Weighted Random Early Detection

QC-177 QC-178 QC-178

QC-177

Average Queue Size Why Use DWRED? Restrictions Prerequisites Flow-Based WRED How It Works How It Works Usage Scenarios
QC-180 QC-180

Packet-Drop Probability

QC-179

QC-181 QC-181

Why Use Flow-Based WRED?

QC-181 QC-182

DiffServ Compliant WRED

QC-182

QC-183 QC-183 QC-185 QC-186

Usage Points to Note

Configuring Weighted Random Early Detection Enabling WRED Monitoring WRED

QC-186 QC-187

Weighted Random Early Detection Configuration Task List Changing WRED Parameters
QC-187 QC-188 QC-188

DWRED Configuration Task List

Configuring DWRED in a Traffic Policy Monitoring and Maintaining DWRED Flow-Based WRED Configuration Task List Configuring Flow-Based WRED
Cisco IOS Quality of Service Solutions Configuration Guide

Configuring DWRED to Use IP Precedence Values in a Traffic Policy

QC-189 QC-190

QC-189

QC-190

xiv

Contents

DiffServ Compliant WRED Configuration Task List WRED at the Interface Level WRED at the per-VC Level WRED at the Class Level WRED Configuration Examples
QC-191 QC-191 QC-191

QC-190 QC-190

Configuring WRED to Use the Differentiated Services Code Point Value

Verifying the DSCP Value Configuration

QC-192 QC-192

QC-192

WRED Configuration Example

Parameter-Setting DWRED Example Parameter-Setting WRED Example DWRED Configuration Examples Modular QoS CLI Example
QC-195

QC-194 QC-195

DWRED on an Interface Example

QC-195

QC-195

Configuring DWRED in Traffic Policy Example Flow-Based WRED Configuration Example

QC-196

QC-196

DiffServ Compliant WRED Configuration Examples DSCP Value Configuration Verification Example Policing and Shaping Policing and Shaping Overview What Is a Token Bucket? Policing with CAR How It Works Rate Limits
QC-204 QC-205 QC-205 QC-203

QC-198 QC-198

WRED Configured to Use the DSCP Value Example

QC-199

QC-204

Matching Criteria

QC-206 QC-208

Conform and Exceed Actions Multiple Rate Policies Restrictions Traffic Policing Benefits
QC-209 QC-209 QC-210 QC-208

Bandwidth Management Through Rate Limiting Restrictions Prerequisites

QC-210 QC-210

QC-210 QC-210

Packet Marking Through IP Precedence, QoS Group, and DSCP Value Setting

Cisco IOS Quality of Service Solutions Configuration Guide

xv

Contents

Traffic Shaping

QC-211 QC-211 QC-211 QC-212

About Traffic Shaping

Why Use Traffic Shaping? Discard Eligible Bit

QC-212

Traffic Shaping and Rate of Transfer

Differences Between Shaping Mechanisms Traffic Shaping and Queueing Generic Traffic Shaping Class-Based Shaping How It Works Restrictions Restrictions Prerequisites Derived Rates Restrictions
QC-214 QC-215 QC-215 QC-216 QC-216 QC-214

QC-213

Distributed Traffic Shaping

QC-217 QC-217

Frame Relay Traffic Shaping

QC-218 QC-218

QC-217

Configuring Traffic Policing

QC-219 QC-219

Traffic Policing Configuration Task List Configuring Traffic Policing

QC-219

Verifying the Traffic Policing Configuration Monitoring and Maintaining Traffic Policing Traffic Policing Configuration Examples Verifying the Configuration Example Configuring Generic Traffic Shaping Configuring GTS
QC-224 QC-224 QC-221

QC-220 QC-221

Traffic Policy that Includes Traffic Policing Example

QC-222

QC-221

QC-223 QC-223

Generic Traffic Shaping Configuration Task List Configuring GTS for an Access List Monitoring the GTS Configuration

Configuring Adaptive GTS for Frame Relay Networks

QC-225 QC-225

QC-224

Generic Traffic Shaping Configuration Examples GTS Enabled on the Interface Example Constrained Access Rate Example
QC-226

QC-225

Different Controlled Rates Through an IP Internet Example

Cisco IOS Quality of Service Solutions Configuration Guide

QC-226

xvi

Contents

Frame Relay Adaptability to Congestion Example Different Accommodated Access Speeds Example Configuring Class-Based Shaping
QC-229 QC-229

QC-226 QC-227

Class-Based Shaping Configuration Task List Configuring Class-Based Shaping

QC-229

Configuring CBWFQ Inside Generic Traffic Shaping Class-Based Shaping Configuration Examples Class-Based Shaping Example CBWFQ Inside GTS Examples
QC-231 QC-231 QC-231

QC-230 QC-230

Verifying the Configuration of Policy Maps and Their Classes

CBWFQ in Conjunction with GTS Example

QC-232 QC-234 QC-237

Configuration Verification Example Configuring Distributed Traffic Shaping Creating a Traffic Class
QC-237

Distributed Traffic Shaping Configuration Task List Configuring a Traffic Policy that Uses DTS Modifying DTS for an Existing Traffic Class Monitoring and Maintaining DTS DTS on Main Interface Example
QC-239

QC-237

QC-238 QC-238 QC-238

Attaching the Traffic Policy and Enabling DTS

Distributed Traffic Shaping Configuration Examples

QC-239

QC-239

Class-Based DTS on Main Interface Example

QC-239 QC-240 QC-240

DTS on Frame Relay Point-to-Point Subinterface Example

Class-Based DTS on Frame Relay Point-to-Point Subinterface Example Signalling Signalling Overview IP Precedence
QC-243

QC-243 QC-244

Resource Reservation Protocol How It Works Restrictions Prerequisites

QC-245

RSVP Support for Low Latency Queueing

QC-247 QC-247 QC-247

QC-245

RSVP Support for Frame Relay

Cisco IOS Quality of Service Solutions Configuration Guide

xvii

Contents

RSVP Bandwidth Allocation and Modular QoS Command Line Interface (CLI) Benefits
QC-248 QC-249 QC-249 QC-249

QC-248

Restrictions Prerequisites How It Works COPS for RSVP

RSVP-ATM QoS Interworking

QC-250

An Example Scenario
QC-252 QC-253

QC-251

How It Works

A Detailed Look at COPS for RSVP Functioning Subnetwork Bandwidth Manager Configuring RSVP
QC-261 QC-262 QC-262 QC-263 QC-263 QC-264 QC-258

QC-254

RSVP Reservation Types Distinct Reservation Shared Reservation

Planning for RSVP Configuration

RSVP Implementation Considerations ATM Internetwork Considerations Enabling RSVP

QC-265

Frame Relay Internetwork Considerations

QC-265

QC-264

Resource Reservation Protocol Configuration Task List Entering Senders in the RSVP Database Entering Receivers in the RSVP Database Specifying Multicast Destinations Enabling RSVP to Attach to NetFlow Monitoring RSVP
QC-268 QC-267 QC-266 QC-266

QC-265

Controlling Which RSVP Neighbor Can Offer a Reservation

QC-267 QC-268

QC-267

Setting the IP Precedence and ToS Values

RSVP Configuration for a Multicast Session Example Configuring RSVP Support for LLQ Configuring Flow Classification Enabling RSVP and WFQ Configuring a Burst Factor Configuring a Path
QC-276 QC-276 QC-276 QC-275 QC-275

QC-269

RSVP Support for LLQ Configuration Task List

QC-276

Cisco IOS Quality of Service Solutions Configuration Guide

xviii

Contents

Configuring a Reservation

QC-277 QC-277 QC-278

Verifying RSVP Support for LLQ Configuration RSVP Support for LLQ Configuration Examples Configuring RSVP Support for Frame Relay

Monitoring and Maintaining RSVP Support for LLQ

QC-278 QC-281

RSVP Support for Frame Relay Configuration Task List Enabling Frame Relay Encapsulation on an Interface Configuring a Virtual Circuit
QC-282

QC-281 QC-282

Enabling Frame Relay Traffic Shaping on an Interface Enabling Enhanced Local Management Interface Enabling RSVP on an Interface
QC-283

QC-282

QC-282

Specifying a Traffic Shaping Map Class for an Interface Specifying the CIR Enabling WFQ Enabling FRF.12 Configuring a Path
QC-283 QC-284

QC-283 QC-283

Defining a Map Class with WFQ and Traffic Shaping Parameters Specifying the Minimum CIR
QC-284 QC-284 QC-284 QC-285 QC-285

Configuring a Reservation

Verifying RSVP Support for Frame Relay Multipoint Configuration

QC-285 QC-286

Point-to-Point Configuration

Monitoring and Maintaining RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Examples Multipoint Configuration Example
QC-287 QC-290 QC-293 QC-293 QC-294 QC-287

QC-287

Point-to-Point Configuration Example Configuring RSVP-ATM QoS Interworking

RSVP-ATM QoS Interworking Configuration Task List Enabling RSVP and Limiting Reservable Bandwidth Enabling Creation of SVCs for Reserved Flows Configuring per-VC DWRED
QC-296

QC-294 QC-296

Limiting the Peak Rate Applied to the PCR for SVCs Monitoring RSVP-ATM Configuration for an Interface RSVP-ATM QoS Interworking Configuration Examples

QC-297

QC-297

Cisco IOS Quality of Service Solutions Configuration Guide

xix

Contents

Configuring COPS for RSVP

QC-303 QC-303 QC-304 QC-304

COPS for RSVP Configuration Task List

Specifying COPS Servers and Enabling COPS for RSVP Restricting RSVP Policy to Specific Access Control Lists Rejecting Unmatched RSVP Messages
QC-304 QC-304

Confining Policy to PATH and RESV Messages

Retaining RSVP Information After Losing Connection with the COPS Server Reporting the Results of Outsourcing and Configuration Decisions Verifying the Configuration
QC-305 QC-305 QC-306 QC-306 QC-306 QC-305

QC-305

COPS for RSVP Configuration Examples COPS Server Specified Example RSVP Behavior Customized Example

Verification of the COPS for RSVP Configuration Example Configuring Subnetwork Bandwidth Manager
QC-307

Subnetwork Bandwidth Manager Configuration Task List Configuring the NonResvSendLimit Object Verifying Configuration of SBM State
QC-308

QC-307 QC-308

Configuring an Interface as a Designated SBM Candidate

QC-309

Subnetwork Bandwidth Manager Candidate Configuration Example Link Efficiency Mechanisms Link Efficiency Mechanisms Overview How It Works Restrictions Prerequisites
QC-314 QC-313 QC-313

QC-310

Link Fragmentation and Interleaving for MLP

Link Fragmentation and Interleaving for Frame Relay and ATM VCs
QC-316 QC-316 QC-316 QC-316

QC-315

Frame Relay Fragmentation How It Works

QC-317

Compressed Real-Time Protocol Why Use CRTP Header?

QC-318 QC-318 QC-318

Express RTP Header Compression Benefits

QC-319

Distributed Compressed Real-Time Protocol

Additional Functionality Capabilities for the RSP

Cisco IOS Quality of Service Solutions Configuration Guide

QC-319

xx

Contents

Enhanced 7500 Series Router Scalability for Enterprise and Service Provider Networks Additional Support for VoIP Streams Improved Latency Restrictions Prerequisites
QC-320 QC-320 QC-321 QC-319 QC-319 QC-319

QC-319

Accelerates Speed of Packet Transmission

Configuring Link Fragmentation and Interleaving for Multilink PPP About MLP Interleaving and Queueing for Real-Time Traffic Restrictions
QC-322 QC-322 QC-321

Interleaving for Multilink PPP Configuration Task List Configuring MLP Interleaving
QC-322 QC-323 QC-323

Displaying Interleaving Statistics Monitoring PPP and MLP Interfaces MLP and LFI Configuration Examples

QC-324 QC-327

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Task List
QC-327 QC-327

Configuring LFI Using Multilink Point-to-Point Protocol over Frame Relay Configuring LFI Using MLP in a Virtual Template Interface
QC-328

Associating the Virtual Template Interface with a Frame Relay Permanent Virtual Circuit QC-328 Configuring LFI Using MLP over ATM
QC-329 QC-329 QC-330

Configuring LFI Using MLP on a Virtual Template Interface Associating the Virtual Template Interface with an ATM PVC Configuring LFI Using MLP on a Dialer Interface Associating the Dialer Interface with an ATM PVC Verifying LFI for Frame Relay and ATM
QC-332 QC-330 QC-331

Monitoring and Maintaining LFI for Frame Relay and ATM LFI for Frame Relay and ATM VCs Configuration Examples

QC-332

QC-333 QC-333

LFI over Frame Relay Using a Virtual Template Interface Configuration Example LFI over ATM Using a Virtual Template Interface Configuration Example LFI over ATM Using a Dialer Interface Configuration Example Configuring Compressed Real-Time Protocol Prerequisites
QC-337 QC-338 QC-337 QC-337 QC-335 QC-334

Compressed Real-Time Protocol Configuration Task List Enabling CRTP on a Serial Interface

Cisco IOS Quality of Service Solutions Configuration Guide

xxi

Contents

Enabling CRTP with Frame Relay Encapsulation Displaying System and Network Statistics

QC-338 QC-339

Changing the Number of Header Compression Connections

QC-339 QC-339

Compressed Real-Time Protocol Configuration Examples Configuring Distributed Compressed Real-Time Protocol Distributed CRTP Configuration Task List Distributed CRTP Configuration Examples
QC-341

QC-341

Changing the Number of Header Compression Connections

QC-342

QC-342

Distributed Compressed RTP Header Compression Example Express TCP Header Compression Example Quality of Service Solutions IP to ATM Class of Service Overview About IP to ATM CoS
QC-347 QC-348 QC-348 QC-347 QC-343

QC-342

Single ATM VC Support

VC Bundle Support and Bundle Management Per-VC LLQ, WFQ and CBWFQ Support Why Use IP to ATM CoS? Benefits
QC-351 QC-352 QC-352 QC-353 QC-351

QC-350

IP to ATM CoS Features Congestion Avoidance Restrictions

QC-354

Bumping and ATM VC Bundles

Configuring IP to ATM Class of Service Defining the WRED Parameter Group

QC-355 QC-355

IP to ATM CoS on a Single ATM VC Configuration Task List

QC-356 QC-356

Configuring the WRED Parameter Group Displaying the WRED Parameters Displaying the Queueing Statistics Creating a VC Bundle
QC-357 QC-356

QC-356 QC-357

IP to ATM CoS on an ATM Bundle Configuration Task List Applying Bundle-Level Parameters
QC-357 QC-358

Configuring Bundle-Level Parameters

Configuring VC Class Parameters to Apply to a Bundle

QC-358

Cisco IOS Quality of Service Solutions Configuration Guide

xxii

Contents

Attaching a Class to a Bundle Committing a VC to a Bundle

QC-359

QC-359 QC-359 QC-360 QC-360

Applying Parameters to Individual VCs

Configuring a VC Bundle Member Directly

Configuring VC Class Parameters to Apply to a VC Bundle Member Applying a VC Class to a Discrete VC Bundle Member Configuring a VC Not to Accept Bumped Traffic Per-VC WFQ and CBWFQ Configuration Task List
QC-361 QC-362 QC-361

Monitoring and Maintaining VC Bundles and Their VC Members

QC-362 QC-362 QC-363

Configuring Class-Based Weighted Fair Queueing Configuring a VC to Use Flow-Based WFQ Monitoring per-VC WFQ and CBWFQ IP to ATM CoS Configuration Examples
QC-363

Attaching a Service Policy and Enabling CBWFQ for a VC

QC-365

Enabling Logging of Error Messages to the Console

QC-365

QC-365

Single ATM VC with WRED Group and IP Precedence Example VC Bundle Configuration Using a VC Class Example Bundle-Class Class Control-Class Class Premium-Class Class Priority-Class Class Basic-Class Class new-york Bundle los-angeles Bundle
QC-366 QC-367 QC-367 QC-367 QC-367 QC-368 QC-368 QC-369 QC-369 QC-366

QC-366

san-francisco Bundle

Per-VC WFQ and CBWFQ on a Standalone VC Example

Per-VC WFQ and CBWFQ on Bundle-Member VCs Example QoS Features for Voice
QC-371 QC-371

QC-370

Cisco IOS QoS for Voice Features For More Information

QC-373

Implementing DiffServ for End-to-End Quality of Service Overview About Differentiated Services DS Field Definition Per-Hop Behaviors Default PHB
QC-376 QC-377 QC-375 QC-376

QC-375

Cisco IOS Quality of Service Solutions Configuration Guide

xxiii

Contents

Class-Selector PHB

QC-377 QC-377 QC-378

Assured Forwarding PHB Expedited Forwarding PHB Benefits Feature Sets

QC-378

Differentiated Services Components

QC-379

QC-379

Constructing Services Using DiffServ Sample DiffServ Implementation Sample Configurations Troubleshooting Logs Class-Based Management What to Do Next
QC-394 QC-388 QC-394

QC-380 QC-380

QC-382

Modular Quality of Service Command-Line Interface Modular Quality of Service Command-Line Interface Overview About the Modular QoS CLI Supported MIB
QC-399 QC-401 QC-397 QC-397

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Task List Creating a Traffic Class Creating a Traffic Policy Verifying the Configuration
QC-401 QC-403 QC-405 QC-401

Attaching a Traffic Policy to an Interface

QC-406

Modular QoS CLI Configuration Examples Traffic Classes Defined Example Traffic Policy Created Example match not Command Example

QC-406

QC-407 QC-407 QC-407

Traffic Policy Attached to an Interface Example

QC-408

Default Traffic Class Configuration Example

QC-408 QC-408 QC-409

class-map match-any and class-map match-all Commands Example Traffic Class as a Match Criterion (Nested Class Maps) Example Nested Traffic Class for Maintenance Example
QC-409

Nested Traffic Class to Combine match-any and match-all Characteristics in One Traffic Class Example QC-410 Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example
Cisco IOS Quality of Service Solutions Configuration Guide

QC-410

xxiv

Contents

Security Device Manager Security Device Manager Overview About the Security Device Manager Index
QC-415 QC-415

Cisco IOS Quality of Service Solutions Configuration Guide

xxv

Contents

Cisco IOS Quality of Service Solutions Configuration Guide

xxvi

About Cisco IOS Software Documentation

This chapter discusses the objectives, audience, organization, and conventions of Cisco IOS software documentation . It also provides sources for obtaining documentation from Cisco Systems.

Documentation Objectives
Cisco IOS software documentation describes the tasks and commands necessary to configure and maintain Cisco networking devices.

Audience
The Cisco IOS software documentation set is intended primarily for users who configure and maintain Cisco networking devices (such as routers and switches) but who may not be familiar with the tasks, the relationship between tasks, or the Cisco IOS software commands necessary to perform particular tasks. The Cisco IOS software documentation set is also intended for those users experienced with Cisco IOS software who need to know about new features, new configuration options, and new software characteristics in the current Cisco IOS software release.

Documentation Organization
The Cisco IOS software documentation set consists of documentation modules and master indexes. In addition to the main documentation set, there are supporting documents and resources.

Documentation Modules
The Cisco IOS documentation modules consist of configuration guides and corresponding command reference publications. Chapters in a configuration guide describe protocols, configuration tasks, and Cisco IOS software functionality and contain comprehensive configuration examples. Chapters in a command reference publication provide complete Cisco IOS command syntax information. Use each configuration guide in conjunction with its corresponding command reference publication.

Cisco IOS Quality of Service Solutions Configuration Guide

xxvii

About Cisco IOS Software Documentation Documentation Organization

Figure 1 shows the Cisco IOS software documentation modules.

Note

The abbreviations (for example, FC and FR) next to the book icons are page designators, which are defined in a key in the index of each document to help you with navigation. The bullets under each module list the major technology areas discussed in the corresponding books.

Figure 1

Cisco IOS Software Documentation Modules

IPC IP1R
Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services

FC

Cisco IOS Configuration Fundamentals Configuration Guide

Cisco IOS IP Configuration Guide

P2C

Cisco IOS AppleTalk and Novell IPX Configuration Guide

P3C

IP3R
Cisco IOS AppleTalk and Novell IPX Command Reference

Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Command Reference

FR

Cisco IOS Configuration Fundamentals Command Reference

IP2R

Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols

Cisco IOS IP Command Reference, Volume 3 of 3: Multicast

P2R

P3R

Module FC/FR: Cisco IOS User Interfaces File Management System Management

Module IPC/IP1R/IP2R/IP3R: IP Addressing and Services IP Routing Protocols IP Multicast

Module P2C/P2R: AppleTalk Novell IPX

Module P3C/P3R: Apollo Domain Banyan VINES DECnet ISO CLNS XNS

WC

Cisco IOS Wide-Area Networking Configuration Guide

IC

Cisco IOS Interface Configuration Guide

MWC

Cisco IOS Mobile Wireless Configuration Guide

SC

Cisco IOS Security Configuration Guide

WR

Cisco IOS Wide-Area Networking Command Reference

IR

Cisco IOS Interface Command Reference

MWR

Cisco IOS Mobile Wireless Command Reference

SR

Cisco IOS Security Command Reference

Module WC/WR: ATM Broadband Access Frame Relay SMDS X.25 and LAPB

Module IC/IR: LAN Interfaces Serial Interfaces Logical Interfaces

Module MWC/MWR: General Packet Radio Service

Module SC/SR: AAA Security Services Security Server Protocols Traffic Filtering and Firewalls IP Security and Encryption Passwords and Privileges Neighbor Router Authentication IP Security Options Supported AV Pairs

Cisco IOS Quality of Service Solutions Configuration Guide

xxviii

47953

About Cisco IOS Software Documentation Documentation Organization

DC

Cisco IOS Dial Technologies Configuration Guide

TC

Cisco IOS Terminal Services Configuration Guide

BC

Cisco IOS Bridging and IBM Networking Configuration Guide

B1R
Cisco IOS Dial Technologies Command Reference Cisco IOS Terminal Services Command Reference Cisco IOS Bridging and IBM Networking Command Reference, Volume 1 of 2

B2R
Cisco IOS Bridging and IBM Networking Command Reference, Volume 2 of 2

DR

TR

Module DC/DR: Preparing for Dial Access Modem and Dial Shelf Configuration and Management ISDN Configuration Signalling Configuration Dial-on-Demand Routing Configuration Dial-Backup Configuration Dial-Related Addressing Services Virtual Templates, Profiles, and Networks PPP Configuration Callback and Bandwidth Allocation Configuration Dial Access Specialized Features Dial Access Scenarios

Module TC/TR: ARA LAT NASI Telnet TN3270 XRemote X.28 PAD Protocol Translation

Module BC/B1R: Transparent Bridging SRB Token Ring Inter-Switch Link Token Ring Route Switch Module RSRB DLSw+ Serial Tunnel and Block Serial Tunnel LLC2 and SDLC IBM Network Media Translation SNA Frame Relay Access NCIA Client/Server Airline Product Set

Module BC/B2R: DSPU and SNA Service Point SNA Switching Services Cisco Transaction Connection Cisco Mainframe Channel Connection CLAW and TCP/IP Offload CSNA, CMPC, and CMPC+ TN3270 Server

VC

Cisco IOS Voice, Video, and Fax Configuration Guide

QC

Cisco IOS Quality of Service Solutions Configuration Guide

XC

Cisco IOS Switching Services Configuration Guide

VR

Cisco IOS Voice, Video, and Fax Command Reference

QR

Cisco IOS Quality of Service Solutions Command Reference

XR

Cisco IOS Switching Services Command Reference

Module VC/VR: Voice over IP Call Control Signalling Voice over Frame Relay Voice over ATM Telephony Applications Trunk Management Fax, Video, and Modem Support

Module QC/QR: Packet Classification Congestion Management Congestion Avoidance Policing and Shaping Signalling Link Efficiency Mechanisms

Module XC/XR: Cisco IOS Switching Paths NetFlow Switching Multiprotocol Label Switching Multilayer Switching Multicast Distributed Switching Virtual LANs LAN Emulation

Cisco IOS Quality of Service Solutions Configuration Guide

47954

xxix

About Cisco IOS Software Documentation Documentation Organization

Master Indexes
Two master indexes provide indexing information for the Cisco IOS software documentation set: an index for the configuration guides and an index for the command references. Individual books also contain a book-specific index. The master indexes provide a quick way for you to find a command when you know the command name but not which module contains the command. When you use the online master indexes, you can click the page number for an index entry and go to that page in the online document.

Supporting Documents and Resources

The following documents and resources support the Cisco IOS software documentation set:

Cisco IOS Command Summary (two volumes)This publication explains the function and syntax of the Cisco IOS software commands. For more information about defaults and usage guidelines, refer to the Cisco IOS command reference publications. Cisco IOS System Error Messages This publication lists and describes Cisco IOS system error messages. Not all system error messages indicate problems with your system. Some are purely informational, and others may help diagnose problems with communications lines, internal hardware, or the system software. Cisco IOS Debug Command ReferenceThis publication contains an alphabetical listing of the debug commands and their descriptions. Documentation for each command includes a brief description of its use, command syntax, usage guidelines, and sample output. Dictionary of Internetworking Terms and AcronymsThis Cisco publication compiles and defines the terms and acronyms used in the internetworking industry. New feature documentationThe Cisco IOS software documentation set documents the mainline release of Cisco IOS software (for example, Cisco IOS Release 12.2). New software features are introduced in early deployment releases (for example, the Cisco IOS T release train for 12.2, 12.2(x)T). Documentation for these new features can be found in standalone documents called feature modules. Feature module documentation describes new Cisco IOS software and hardware networking functionality and is available on Cisco.com and the Documentation CD-ROM. Release notesThis documentation describes system requirements, provides information about new and changed features, and includes other useful information about specific software releases. See the section Using Software Release Notes in the chapter Using Cisco IOS Software for more information. Caveats documentationThis documentation provides information about Cisco IOS software defects in specific software releases. RFCsRFCs are standards documents maintained by the Internet Engineering Task Force (IETF). Cisco IOS software documentation references supported RFCs when applicable. The full text of referenced RFCs may be obtained on the World Wide Web at http://www.rfc-editor.org/. MIBsMIBs are used for network monitoring. For lists of supported MIBs by platform and release, and to download MIB files, see the Cisco MIB website on Cisco.com at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

Cisco IOS Quality of Service Solutions Configuration Guide

xxx

About Cisco IOS Software Documentation Document Conventions

Document Conventions
Within Cisco IOS software documentation, the term router is generally used to refer to a variety of Cisco products (for example, routers, access servers, and switches). Routers, access servers, and other networking devices that support Cisco IOS software are shown interchangeably within examples. These products are used only for illustrative purposes; that is, an example that shows one product does not necessarily indicate that other products are not supported. The Cisco IOS documentation set uses the following conventions: Convention ^ or Ctrl Description The ^ and Ctrl symbols represent the Control key. For example, the key combination ^D or Ctrl-D means hold down the Control key while you press the D key. Keys are indicated in capital letters but are not case sensitive. A string is a nonquoted set of characters shown in italics. For example, when setting an SNMP community string to public, do not use quotation marks around the string or the string will include the quotation marks. Command syntax descriptions use the following conventions: Convention boldface italics [x] | [x | y] {x | y} Description Boldface text indicates commands and keywords that you enter literally as shown. Italic text indicates arguments for which you supply values. Square brackets enclose an optional element (keyword or argument). A vertical line indicates a choice within an optional or required set of keywords or arguments. Square brackets enclosing keywords or arguments separated by a vertical line indicate an optional choice. Braces enclosing keywords or arguments separated by a vertical line indicate a required choice. Nested sets of square brackets or braces indicate optional or required choices within optional or required elements. For example: Convention [x {y | z}] Description Braces and a vertical line within square brackets indicate a required choice within an optional element. Examples use the following conventions: Convention
screen boldface screen

string

Description Examples of information displayed on the screen are set in Courier font. Examples of text that you must enter are set in Courier bold font. Angle brackets enclose text that is not printed to the screen, such as passwords.

<

>

Cisco IOS Quality of Service Solutions Configuration Guide

xxxi

About Cisco IOS Software Documentation Obtaining Documentation

Convention ! [ ]

Description An exclamation point at the beginning of a line indicates a comment line. (Exclamation points are also displayed by the Cisco IOS software for certain processes.) Square brackets enclose default responses to system prompts. The following conventions are used to attract the attention of the reader:

Caution

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

Note

Means reader take note. Notes contain helpful suggestions or references to materials not contained in this manual.

Timesaver

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

Obtaining Documentation
The following sections provide sources for obtaining documentation from Cisco Systems.

World Wide Web

The most current Cisco documentation is available on the World Wide Web at the following website: http://www.cisco.com Translated documentation is available at the following website: http://www.cisco.com/public/countries_languages.html

Documentation CD-ROM
Cisco documentation and additional literature are available in a CD-ROM package, which ships 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.

Cisco IOS Quality of Service Solutions Configuration Guide

xxxii

About Cisco IOS Software Documentation Documentation Feedback

Ordering Documentation
Cisco documentation can be ordered in the following ways:

Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace: http://www.cisco.com/cgi-bin/order/order_root.pl

Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store: http://www.cisco.com/go/subscription

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

Documentation Feedback
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. You can e-mail your comments to [email protected]. To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address: Cisco Systems, Inc. Document Resource Connection 170 West Tasman Drive San Jose, CA 95134-9883 We appreciate your comments.

Obtaining Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.

Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco. Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.

Cisco IOS Quality of Service Solutions Configuration Guide

xxxiii

About Cisco IOS Software Documentation Obtaining Technical Assistance

Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco. To access Cisco.com, go to the following website: http://www.cisco.com

Technical Assistance Center

The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.

Contacting TAC by Using the Cisco TAC Website

If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website: http://www.cisco.com/tac P3 and P4 level problems are defined as follows:

P3Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue. P4You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.

In each of the above cases, use the Cisco TAC website to quickly find answers to your questions. To register for Cisco.com, go to the following website: http://www.cisco.com/register/ If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website: http://www.cisco.com/tac/caseopen

Contacting TAC by Telephone

If you have a priority level 1 (P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website: http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml P1 and P2 level problems are defined as follows:

P1Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available. P2Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.

Cisco IOS Quality of Service Solutions Configuration Guide

xxxiv

Using Cisco IOS Software

This chapter provides helpful tips for understanding and configuring Cisco IOS software using the command-line interface (CLI). It contains the following sections:

Understanding Command Modes Getting Help Using the no and default Forms of Commands Saving Configuration Changes Filtering Output from the show and more Commands Identifying Supported Platforms

For an overview of Cisco IOS software configuration, refer to the Cisco IOS Configuration Fundamentals Configuration Guide. For information on the conventions used in the Cisco IOS software documentation set, see the chapter About Cisco IOS Software Documentation located at the beginning of this book.

Understanding Command Modes

You use the CLI to access Cisco IOS software. Because the CLI is divided into many different modes, the commands available to you at any given time depend on the mode you are currently in. Entering a question mark ( ?) at the CLI prompt allows you to obtain a list of commands available for each command mode. When you log in to the CLI, you are in user EXEC mode. User EXEC mode contains only a limited subset of commands. To have access to all commands, you must enter privileged EXEC mode, normally by using a password. From privileged EXEC mode you can issue any EXEC commanduser or privileged modeor you can enter global configuration mode. Most EXEC commands are one-time commands. For example, show commands show important status information, and clear commands clear counters or interfaces. The EXEC commands are not saved when the software reboots. Configuration modes allow you to make changes to the running configuration. If you later save the running configuration to the startup configuration, these changed commands are stored when the software is rebooted. To enter specific configuration modes, you must start at global configuration mode. From global configuration mode, you can enter interface configuration mode and a variety of other modes, such as protocol-specific modes. ROM monitor mode is a separate mode used when the Cisco IOS software cannot load properly. If a valid software image is not found when the software boots or if the configuration file is corrupted at startup, the software might enter ROM monitor mode.

Cisco IOS Quality of Service Solutions Configuration Guide

xxxv

Using Cisco IOS Software Getting Help

Table 1 describes how to access and exit various common command modes of the Cisco IOS software. It also shows examples of the prompts displayed for each mode.
Table 1 Accessing and Exiting Command Modes

Command Mode User EXEC Privileged EXEC Global configuration

Access Method Log in. From user EXEC mode, use the enable EXEC command. From privileged EXEC mode, use the configure terminal privileged EXEC command. From global configuration mode, specify an interface using an interface command. From privileged EXEC mode, use the reload EXEC command. Press the Break key during the first 60 seconds while the system is booting.

Prompt
Router> Router#

Exit Method Use the logout command. To return to user EXEC mode, use the disable command. To return to privileged EXEC mode from global configuration mode, use the exit or end command, or press Ctrl-Z. To return to global configuration mode, use the exit command. To return to privileged EXEC mode, use the end command, or press Ctrl-Z.

Router(config)#

Interface configuration

Router(config-if)#

ROM monitor

>

To exit ROM monitor mode, use the continue command.

For more information on command modes, refer to the Using the Command-Line Interface chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.

Getting Help
Entering a question mark ( ?) at the CLI prompt displays a list of commands available for each command mode. You can also get a list of keywords and arguments associated with any command by using the context-sensitive help feature. To get help specific to a command mode, a command, a keyword, or an argument, use one of the following commands: Command
help

Purpose Provides a brief description of the help system in any command mode. Provides a list of commands that begin with a particular character string. (No space between command and question mark.) Completes a partial command name. Lists all commands available for a particular command mode. Lists the keywords or arguments that you must enter next on the command line. (Space between command and question mark.)

abbreviated-command-entry?

abbreviated-command-entry<Tab>
?

command ?

Cisco IOS Quality of Service Solutions Configuration Guide

xxxvi

Using Cisco IOS Software Getting Help

Example: How to Find Command Options

This section provides an example of how to display syntax for a command. The syntax can consist of optional or required keywords and arguments. To display keywords and arguments for a command, enter a question mark ( ?) at the configuration prompt or after entering part of a command followed by a space. The Cisco IOS software displays a list and brief description of available keywords and arguments. For example, if you were in global configuration mode and wanted to see all the keywords or arguments for the arap command, you would type arap ?. The <cr> symbol in command help output stands for carriage return. On older keyboards, the carriage return key is the Return key. On most modern keyboards, the carriage return key is the Enter key. The <cr> symbol at the end of command help output indicates that you have the option to press Enter to complete the command and that the arguments and keywords in the list preceding the <cr> symbol are optional. The <cr> symbol by itself indicates that no more arguments or keywords are available and that you must press Enter to complete the command. Table 2 shows examples of how you can use the question mark (?) to assist you in entering commands. The table steps you through configuring an IP address on a serial interface on a Cisco 7206 router that is running Cisco IOS Release 12.0(3).
Table 2 How to Find Command Options

Command
Router> enable Password: <password> Router#

Comment Enter the enable command and password to access privileged EXEC commands. You are in privileged EXEC mode when the prompt changes to Router#. Enter the configure terminal privileged EXEC command to enter global configuration mode. You are in global configuration mode when the prompt changes to Router(config)#. Enter interface configuration mode by specifying the serial interface that you want to configure using the interface serial global configuration command. Enter ? to display what you must enter next on the command line. In this example, you must enter the serial interface slot number and port number, separated by a forward slash. You are in interface configuration mode when the prompt changes to
Router(config-if)#.

Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#

Router(config)# interface serial ? <0-6> Serial interface number Router(config)# interface serial 4 ? / Router(config)# interface serial 4/ ? <0-3> Serial interface number Router(config)# interface serial 4/0 Router(config-if)#

Cisco IOS Quality of Service Solutions Configuration Guide

xxxvii

Using Cisco IOS Software Getting Help

Table 2

How to Find Command Options (continued)

Command
Router(config-if)# ? Interface configuration commands: . . . ip Interface Internet Protocol config commands keepalive Enable keepalive lan-name LAN Name command llc2 LLC2 Interface Subcommands load-interval Specify interval for load calculation for an interface locaddr-priority Assign a priority group logging Configure logging for interface loopback Configure internal loopback on an interface mac-address Manually set interface MAC address mls mls router sub/interface commands mpoa MPOA interface configuration commands mtu Set the interface Maximum Transmission Unit (MTU) netbios Use a defined NETBIOS access list or enable name-caching no Negate a command or set its defaults nrzi-encoding Enable use of NRZI encoding ntp Configure NTP . . . Router(config-if)# Router(config-if)# ip ? Interface IP configuration subcommands: access-group Specify access control for packets accounting Enable IP accounting on this interface address Set the IP address of an interface authentication authentication subcommands bandwidth-percent Set EIGRP bandwidth limit broadcast-address Set the broadcast address of an interface cgmp Enable/disable CGMP directed-broadcast Enable forwarding of directed broadcasts dvmrp DVMRP interface commands hello-interval Configures IP-EIGRP hello interval helper-address Specify a destination address for UDP broadcasts hold-time Configures IP-EIGRP hold time . . . Router(config-if)# ip

Comment Enter ? to display a list of all the interface configuration commands available for the serial interface. This example shows only some of the available interface configuration commands.

Enter the command that you want to configure for the interface. This example uses the ip command. Enter ? to display what you must enter next on the command line. This example shows only some of the available interface IP configuration commands.

Cisco IOS Quality of Service Solutions Configuration Guide

xxxviii

Using Cisco IOS Software Using the no and default Forms of Commands

Table 2

How to Find Command Options (continued)

Command
Router(config-if)# ip address ? A.B.C.D IP address negotiated IP Address negotiated over PPP Router(config-if)# ip address

Comment Enter the command that you want to configure for the interface. This example uses the ip address command. Enter ? to display what you must enter next on the command line. In this example, you must enter an IP address or the negotiated keyword. A carriage return (<cr>) is not displayed; therefore, you must enter additional keywords or arguments to complete the command.

Router(config-if)# ip address 172.16.0.1 ? A.B.C.D IP subnet mask Router(config-if)# ip address 172.16.0.1

Enter the keyword or argument you want to use. This example uses the 172.16.0.1 IP address. Enter ? to display what you must enter next on the command line. In this example, you must enter an IP subnet mask. A <cr> is not displayed; therefore, you must enter additional keywords or arguments to complete the command.

Router(config-if)# ip address 172.16.0.1 255.255.255.0 ? secondary Make this IP address a secondary address <cr> Router(config-if)# ip address 172.16.0.1 255.255.255.0

Enter the IP subnet mask. This example uses the 255.255.255.0 IP subnet mask. Enter ? to display what you must enter next on the command line. In this example, you can enter the secondary keyword, or you can press Enter. A <cr> is displayed; you can press Enter to complete the command, or you can enter another keyword.

Router(config-if)# ip address 172.16.0.1 255.255.255.0 Router(config-if)#

In this example, Enter is pressed to complete the command.

Using the no and default Forms of Commands

Almost every configuration command has a no form. In general, use the no form to disable a function. Use the command without the no keyword to reenable a disabled function or to enable a function that is disabled by default. For example, IP routing is enabled by default. To disable IP routing, use the no ip routing command; to reenable IP routing, use the ip routing command. The Cisco IOS software command reference publications provide the complete syntax for the configuration commands and describe what the no form of a command does.

Cisco IOS Quality of Service Solutions Configuration Guide

xxxix

Using Cisco IOS Software Saving Configuration Changes

Configuration commands also can have a default form, which returns the command settings to the default values. Most commands are disabled by default, so in such cases using the default form has the same result as using the no form of the command. However, some commands are enabled by default and have variables set to certain default values. In these cases, the default form of the command enables the command and sets the variables to their default values. The Cisco IOS software command reference publications describe the effect of the default form of a command if the command functions differently than the no form.

Saving Configuration Changes

Use the copy system:running-config nvram:startup-config command to save your configuration changes to the startup configuration so that the changes will not be lost if the software reloads or a power outage occurs. For example:
Router# copy system:running-config nvram:startup-config Building configuration...

It might take a minute or two to save the configuration. After the configuration has been saved, the following output appears:
[OK] Router#

On most platforms, this task saves the configuration to NVRAM. On the Class A Flash file system platforms, this task saves the configuration to the location specified by the CONFIG_FILE environment variable. The CONFIG_FILE variable defaults to NVRAM.

Filtering Output from the show and more Commands

In Cisco IOS Release 12.0(1)T and later releases, you can search and filter the output of show and more commands. This functionality is useful if you need to sort through large amounts of output or if you want to exclude output that you need not see. To use this functionality, enter a show or more command followed by the pipe character (|); one of the keywords begin, include, or exclude; and a regular expression on which you want to search or filter (the expression is case-sensitive): command | {begin | include | exclude} regular-expression The output matches certain lines of information in the configuration file. The following example illustrates how to use output modifiers with the show interface command when you want the output to include only lines in which the expression protocol appears:
Router# show interface | include protocol FastEthernet0/0 is up, line protocol is up Serial4/0 is up, line protocol is up Serial4/1 is up, line protocol is up Serial4/2 is administratively down, line protocol is down Serial4/3 is administratively down, line protocol is down

For more information on the search and filter functionality, refer to the Using the Command-Line Interface chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.

Cisco IOS Quality of Service Solutions Configuration Guide

xl

Using Cisco IOS Software Identifying Supported Platforms

Identifying Supported Platforms

Cisco IOS software is packaged in feature sets consisting of software images that support specific platforms. The feature sets available for a specific platform depend on which Cisco IOS software images are included in a release. To identify the set of software images available in a specific release or to find out if a feature is available in a given Cisco IOS software image, see the following sections:

Using Feature Navigator Using Software Release Notes

Using Feature Navigator

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a particular set of features and which features are supported in a particular Cisco IOS image. Feature Navigator is available 24 hours a day, 7 days a week. To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, e-mail the Contact Database Administration group at [email protected]. If you do not have an account on Cisco.com, go to http://www.cisco.com/register and follow the directions to establish an account. To use Feature Navigator, you must have a JavaScript-enabled web browser such as Netscape 3.0 or later, or Internet Explorer 4.0 or later. Internet Explorer 4.0 always has JavaScript enabled. To enable JavaScript for Netscape 3.x or Netscape 4.x, follow the instructions provided with the web browser. For JavaScript support and enabling instructions for other browsers, check with the browser vendor. Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. You can access Feature Navigator at the following URL: http://www.cisco.com/go/fn

Using Software Release Notes

Cisco IOS software releases include release notes that provide the following information:

Platform support information Memory recommendations Microcode support information Feature set tables Feature descriptions Open and resolved severity 1 and 2 caveats for all platforms

Release notes are intended to be release-specific for the most current release, and the information provided in these documents may not be cumulative in providing information about features that first appeared in previous releases.

Cisco IOS Quality of Service Solutions Configuration Guide

xli

Using Cisco IOS Software Identifying Supported Platforms

Cisco IOS Quality of Service Solutions Configuration Guide

xlii

Quality of Service Overview

This chapter explains quality of service (QoS) and the service models that embody it. It also suggests benefits you can gain from implementing Cisco IOS QoS in your network. Then it focuses on the Cisco IOS QoS features and the technologies that implement them. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

What Is Quality of Service?

QoS refers to the ability of a network to provide improved service to selected network traffic over various underlying technologies including Frame Relay, ATM, Ethernet and 802.1 networks, SONET, and IP-routed networks. In particular, QoS features provide improved and more predictable network service by providing the following services:

Supporting dedicated bandwidth Improving loss characteristics Avoiding and managing network congestion Shaping network traffic Setting traffic priorities across the network

About QoS Architecture

You configure QoS features throughout a network to provide for end-to-end QoS delivery. The following three components are necessary to deliver QoS across a heterogeneous network:

QoS within a single network element, which includes queueing, scheduling, and traffic shaping features. QoS signalling techniques for coordinating QoS for end-to-end delivery between network elements. QoS policing and management functions to control and administer end-to-end traffic across a network.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-1

Quality of Service Overview Who Could Benefit from Using Cisco IOS QoS?

Not all QoS techniques are appropriate for all network routers. Because edge routers and backbone routers in a network do not necessarily perform the same operations, the QoS tasks they perform might differ as well. To configure an IP network for real-time voice traffic, for example, you would need to consider the functions of both edge and backbone routers in the network, then select the appropriate QoS feature or features. In general, edge routers perform the following QoS functions:

Packet classification Admission control Configuration management

In general, backbone routers perform the following QoS functions:

Congestion management Congestion avoidance

Who Could Benefit from Using Cisco IOS QoS?

All networks can take advantage of aspects of QoS for optimum efficiency, whether the network is for a small corporation, an enterprise, or an Internet service provider (ISP). Different categories of networking userssuch as major enterprises, network service providers, and small and medium-sized business networking usershave their own QoS requirements; in many areas, however, these requirements overlap. The Cisco IOS QoS features described in the section Cisco QoS Features later in this chapter address these diverse and common needs. Enterprise networks, for example, must provide end-to-end QoS solutions across the various platforms comprising the network; providing solutions for heterogeneous platforms often requires that you take a different QoS configuration approach for each technology. As enterprise networks carry more complex, mission-critical applications and experience increased traffic from Web multimedia applications, QoS serves to prioritize this traffic to ensure that each application gets the service it requires. ISPs require assured scalability and performance. For example, ISPs that long have offered best-effort IP connectivity now also transfer voice, video, and other real-time critical application data. QoS answers the scalability and performance needs of these ISPs to distinguish different kinds of traffic, thereby enabling them to offer service differentiation to their customers. In the small and medium-sized business segment, managers are experiencing firsthand the rapid growth of business on the Internet. These business networks must also handle increasingly complex business applications. QoS lets the network handle the difficult task of utilizing an expensive WAN connection in the most efficient way for business applications.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-2

Quality of Service Overview Why Deploy Cisco IOS QoS?

Why Deploy Cisco IOS QoS?

The Cisco IOS QoS features enable networks to control and predictably service a variety of networked applications and traffic types. Implementing Cisco IOS QoS in your network promotes the following features:

Control over resources. You have control over which resources (bandwidth, equipment, wide-area facilities, and so on) are being used. For example, you can limit bandwidth consumed over a backbone link by File Transfer Protocol (FTP) transfers or give priority to an important database access. Tailored services. If you are an ISP, the control and visibility provided by QoS enables you to offer carefully tailored grades of service differentiation to your customers. Coexistence of mission-critical applications. Cisco QoS features make certain of the following conditions:
That your WAN is used efficiently by mission-critical applications that are most important to

your business.
That bandwidth and minimum delays required by time-sensitive multimedia and voice

applications are available.

That other applications using the link get their fair service without interfering with

mission-critical traffic. Moreover, in implementing QoS features in your network, you put in place the foundation for a future fully integrated network.

End-to-End QoS Models

A service model, also called a level of service, describes a set of end-to-end QoS capabilities. End-to-end QoS is the ability of the network to deliver service required by specific network traffic from one end of the network to another. Cisco IOS QoS software supports three types of service models: best effort, integrated, and differentiated services.

Note

QoS service models differ from one another in how they enable applications to send data and in the ways in which the network attempts to deliver that data. For instance, a different service model applies to real-time applications, such as audio and video conferencing and IP telephony, than a model that applies to file transfer and e-mail applications. Consider the following factors when deciding which type of service to deploy in the network:

The application or problem you are trying to solve. Each of the three types of servicebest effort, integrated, and differentiatedis appropriate for certain applications. The kind of ability you want to allocate to your resources. Cost-benefit analysis. For example, the cost of implementing and deploying differentiated service is certain to be more expensive than the cost for a best-effort service.

The following sections describe the service models supported by features in Cisco IOS software:

Best-Effort Service Integrated Service Differentiated Service

Cisco IOS Quality of Service Solutions Configuration Guide

QC-3

Quality of Service Overview End-to-End QoS Models

Best-Effort Service
Best effort is a single service model in which an application sends data whenever it must, in any quantity, and without requesting permission or first informing the network. For best-effort service, the network delivers data if it can, without any assurance of reliability, delay bounds, or throughput. The Cisco IOS QoS feature that implements best-effort service is FIFO queueing. Best-effort service is suitable for a wide range of networked applications such as general file transfers or e-mail.

Integrated Service
Integrated service is a multiple service model that can accommodate multiple QoS requirements. In this model the application requests a specific kind of service from the network before it sends data. The request is made by explicit signalling; the application informs the network of its traffic profile and requests a particular kind of service that can encompass its bandwidth and delay requirements. The application is expected to send data only after it gets a confirmation from the network. It is also expected to send data that lies within its described traffic profile. The network performs admission control, based on information from the application and available network resources. It also commits to meeting the QoS requirements of the application as long as the traffic remains within the profile specifications. The network fulfills its commitment by maintaining per-flow state and then performing packet classification, policing, and intelligent queueing based on that state. Cisco IOS QoS includes the following features that provide controlled load service, which is a kind of integrated service:

The Resource Reservation Protocol (RSVP), which can be used by applications to signal their QoS requirements to the router. Intelligent queueing mechanisms, which can be used with RSVP to provide the following kinds of services:
Guaranteed Rate Service, which allows applications to reserve bandwidth to meet their

requirements. For example, a Voice over IP (VoIP) application can reserve the required amount of bandwidth end-to-end using this kind of service. Cisco IOS QoS uses weighted fair queueing (WFQ) with RSVP to provide this kind of service.
Controlled Load Service, which allows applications to have low delay and high throughput even

during times of congestion. For example, adaptive real-time applications such as playback of a recorded conference can use this kind of service. Cisco IOS QoS uses RSVP with Weighted Random Early Detection (WRED) to provide this kind of service.

Differentiated Service
Differentiated service is a multiple service model that can satisfy differing QoS requirements. However, unlike in the integrated service model, an application using differentiated service does not explicitly signal the router before sending data. For differentiated service, the network tries to deliver a particular kind of service based on the QoS specified by each packet. This specification can occur in different ways, for example, using the IP Precedence bit settings in IP packets or source and destination addresses. The network uses the QoS specification to classify, mark, shape, and police traffic, and to perform intelligent queueing.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-4

Quality of Service Overview Cisco QoS Features

The differentiated service model is used for several mission-critical applications and for providing end-to-end QoS. Typically, this service model is appropriate for aggregate flows because it performs a relatively coarse level of traffic classification. Cisco IOS QoS includes the following features that support the differentiated service model:

Committed access rate (CAR), which performs packet classification through IP Precedence and QoS group settings. CAR performs metering and policing of traffic, providing bandwidth management. Intelligent queueing schemes such as WRED and WFQ and their equivalent features on the Versatile Interface Processor (VIP), which are distributed WRED (DWRED) and distributed WFQ. These features can be used with CAR to deliver differentiated services.

For more information on how to implement Differentiated Services using the components of Cisco IOS software, see the chapter Implementing DiffServ for End-to-End Quality of Service Overview in this book.

Cisco QoS Features

The Cisco IOS QoS software provides the major features described in the following sections. Some of which have been previously mentioned, and all of them are briefly introduced in this chapter.

Classification Congestion Management Congestion Avoidance Policing and Shaping Signalling Link Efficiency Mechanisms QoS Solutions Modular QoS Command-Line Interface Security Device Manager

The features listed are described more fully in the overview chapters of this book, which is organized into parts, one for each of the major features listed. Each book part contains an overview chapter and one or more configuration chapters.

Classification
Packet classification features provide the capability to partition network traffic into multiple priority levels or classes of service. For example, by using the three precedence bits in the Type of service (ToS) field of the IP packet headertwo of the values are reserved for other purposesyou can categorize packets into a limited set of up to six traffic classes. After you classify packets, you can utilize other QoS features to assign the appropriate traffic handling policies including congestion management, bandwidth allocation, and delay bounds for each traffic class. Packets can also be classified by external sources, that is, by a customer or by a downstream network provider. You can either allow the network to accept the classification or override it and reclassify the packet according to a policy that you specify.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-5

Quality of Service Overview Cisco QoS Features

Packets can be classified based on policies specified by the network operator. Policies can be set that include classification based on physical port, source or destination IP or MAC address, application port, IP protocol type, and other criteria that you can specify by using access lists or extended access lists. You can use Cisco IOS QoS policy-based routing (PBR) and the classification features of Cisco IOS QoS CAR to classify packets. You can use Border Gateway Protocol (BGP) policy propagation to propagate destination-based packet classification policy throughout a large network via BGP routing updates. This section gives a brief description of these features. In addition, you can use the QoS for Virtual Private Networks (VPNs) feature to classify packets before tunneling and encryption occur. The process of classifying features before tunneling and encryption is called preclassification. The Class-Based Packet Marking feature provides users with a user-friendly command-line interface (CLI) for efficient packet marking by which users can differentiate packets based on the designated markings. For more complete conceptual information on packet classification, see the chapter Classification Overview in this book. For information on how to configure the various protocols that implement classification, see the following chapters:

Configuring Policy-Based Routing Configuring QoS Policy Propagation via Border Gateway Protocol Configuring Committed Access Rate Configuring Class-Based Packet Marking Configuring QoS for Virtual Private Networks Configuring Network-Based Application Recognition

For complete command syntax information, refer to the Cisco IOS Quality of Service Solutions Command Reference.

IP Precedence
The IP Precedence feature allows you to specify the class of service of a packet using the three precedence bits in the ToS field of the IP version 4 (IPv4) header. Other features configured throughout the network can then use these bits to determine how to treat the packet in regard to the type of service to grant it. For example, although IP Precedence is not a queueing method, other queueing methods such as WFQ can use the IP Precedence setting of the packet to prioritize traffic.

Policy-Based Routing
Cisco IOS QoS PBR allows you to perform the following tasks:

Classify traffic based on extended access list criteria. Set IP Precedence bits. Route specific traffic to engineered paths, which may be required to allow a specific QoS service through the network.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-6

Quality of Service Overview Cisco QoS Features

Classification of traffic through PBR allows you to identify traffic for different classes of service at the perimeter of the network and then implement QoS defined for each class of service in the core of the network using priority queueing, custom queueing, or WFQ techniques. This process obviates the need to classify traffic explicitly at each WAN interface in the core-backbone network. Some possible applications for policy routing are to provide equal access, protocol-sensitive routing, source-sensitive routing, routing based on interactive versus batch traffic, or routing based on dedicated links.

BGP Policy Propagation

BGP provides a powerful, scalable means of utilizing attributes, such as community values, to propagate destination-based packet classification policy throughout a large network via BGP routing updates. Packet classification policy can be scalably propagated via BGP without writing and deploying complex access lists at each of a large number of routers. BGP ensures that return traffic to customers is handled as premium traffic by the network.

Committed Access Rate (Packet Classification)

CAR is the main feature supporting packet classification. CAR uses the ToS bits in the IP header to classify packets. You can use the CAR classification commands to classify and reclassify a packet. Here are some example packet classification policies:

All packets received on a particular T1 line are classified as high priority (port-based classification). All HTTP traffic is classified as medium priority (application classification). Video traffic from a specified IP address is classified as medium priority. Packets bound for particular destinations are classified as high priority traffic (for example, international traffic or traffic bound for a premium customer). Some packets are classified for subrate IP services. The network operator delivers a physical T1/E1 or T3/E3 line to the customer, but offers a less expensive subrate service, for example, 1 Mbps on an E1 line or 10 Mbps on a T3 line. The customer pays for the subrate bandwidth and may be upgraded to additional access bandwidth over time based on demand. CAR limits the traffic rate available to the customer and delivered to the network to the agreed-upon rate limit (with the ability to temporarily burst over the limit). The network operator may upgrade the service without any physical network arrangement. Traffic is classified for exchange point traffic control. An ISP offers transit services to downstream ISPs via exchange point connectivity provided by a Layer 2 switch. The upstream provider utilizes MAC-address rate limits provided by CAR to enforce bandwidth usage limitations on the downstream ISPs.

Note

CAR also implements rate-limiting services, which are described later in this chapter.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-7

Quality of Service Overview Cisco QoS Features

Class-Based Packet Marking

The Class-Based Packet Marking feature provides users with a means for efficient packet marking by which users can differentiate packets based on the designated markings. The Class-Based Packet Marking feature allows users to perform the following tasks:

Mark packets by setting the IP Precedence bits or the IP differentiated services code point (DSCP) in the IP ToS byte. Mark packets by setting the Layer 2 class of service (CoS) value. Associate a local QoS group value with a packet. Set the cell loss priority (CLP) bit setting in the ATM header of a packet from 0 to 1.

QoS for Virtual Private Networks

When packets are encapsulated by tunnel or encryption headers, QoS features are unable to examine the original packet headers and correctly classify the packets. Packets traveling across the same tunnel have the same tunnel headers, so the packets are treated identically if the physical interface is congested. With the growing popularity of VPNs, the need to classify traffic within a traffic tunnel is gaining importance. QoS features have historically been unable to classify traffic within a tunnel. With the introduction of the QoS for VPNs feature, packets can now be classified before tunneling and encryption occur. The process of classifying features before tunneling and encryption is called preclassification. The QoS for VPNs feature is designed for tunnel interfaces. When the feature is enabled, the QoS features on the output interface classify packets before encryption, allowing traffic flows to be adjusted in congested environments. The result is more effective packet tunneling.

Network-Based Application Recognition

The Network-Based Application Recognition (NBAR) feature provides intelligent network classification to network infrastructures. NBAR is a classification engine that recognizes a wide variety of applications, including web-based and other difficult-to-classify protocols that utilize dynamic TCP/User Datagram Ports (UDP) port assignments. When an application is recognized and classified by NBAR, a network can invoke services for that specific application.

Congestion Management
Congestion management features operate to control congestion once it occurs. One way that network elements handle an overflow of arriving traffic is to use a queueing algorithm to sort the traffic, then determine some method of prioritizing it onto an output link. Each queueing algorithm was designed to solve a specific network traffic problem and has a particular effect on network performance. The Cisco IOS software congestion management, or queueing, features include the following:

FIFO Priority queueing (PQ) Frame Relay permanent virtual circuit (PVC) interface priority queueing (FR PIPQ) Custom queueing (CQ) Flow-based, class-based, and distributed WFQ Distributed class-based WFQ

Cisco IOS Quality of Service Solutions Configuration Guide

QC-8

Quality of Service Overview Cisco QoS Features

IP RTP Priority and Frame Relay IP RTP Priority Low latency queueing (LLQ), Distributed LLQ, and LLQ for Frame Relay

For more complete conceptual information on packet classification, see the chapter Congestion Management Overview in this book. For information on how to configure the various protocols that implement congestion management, see the following chapters:

Configuring Weighted Fair Queueing Configuring Custom Queueing Configuring Priority Queueing

For complete command syntax information, refer to the Cisco IOS Quality of Service Solutions Command Reference.

What Is Congestion in Networks?

To give you a more definite sense of congestion in networks, this section briefly describes some of its characteristics, drawing on the explanation presented by V. Paxson and S. Floyd in a paper titled Wide Area Traffic: The Failure of Poisson Modeling. What does congestion look like? Consideration of the behavior of congested systems is not simple and cannot be dealt with in a simplistic manner, because traffic rates do not simply rise to a level, stay there a while, then subside. Periods of traffic congestion can be quite long, with losses that are heavily concentrated. In contrast to Poisson traffic models, linear increases in buffer size do not result in large decreases in packet drop rates; a slight increase in the number of active connections can result in a large increase in the packet loss rate. This understanding of the behavior of congested networks suggests that because the level of busy period traffic is not predictable, it would be difficult to efficiently size networks to reduce congestion adequately. Observers of network congestion report that in reality, traffic spikes, which causes actual losses that ride on longer-term ripples, which in turn ride on still longer-term swells.

FIFO Queueing
FIFO provides basic store and forward capability. FIFO is the default queueing algorithm in some instances, thus requiring no configuration. See WFQ and Distributed WFQ later in this section for a complete explanation of default configuration.

PQ
Designed to give strict priority to important traffic, PQ ensures that important traffic gets the fastest handling at each point where PQ is used. PQ can flexibly prioritize according to network protocol (such as IP, IPX, or AppleTalk), incoming interface, packet size, source/destination address, and so on.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-9

Quality of Service Overview Cisco QoS Features

Frame Relay PVC PQ

The FR PIPQ provides an interface-level PQ scheme in which prioritization is based on destination PVC rather than packet contents. For example, FR PIPQ allows you to configure PVC transporting voices traffic to have absolute priority over a PVC transporting signalling traffic, and a PVC transporting signalling traffic to have absolute priority over a PVC transporting data. FR PIPQ provides four levels of priority: high, medium, normal, and low. The Frame Relay packet is examined at the interface for the data-link connection identifier (DLCI) value. The packet is then sent to the correct priority queue based on the priority level configured for that DLCI.

CQ
CQ reserves a percentage of the available bandwidth of an interface for each selected traffic type. If a particular type of traffic is not using the bandwidth reserved for it, then other traffic types may use the remaining reserved bandwidth.

WFQ and Distributed WFQ

WFQ applies priority (or weights) to identified traffic to classify traffic into conversations and determine how much bandwidth each conversation is allowed relative to other conversations. WFQ classifies traffic into different flows based on such characteristics as source and destination address, protocol, and port and socket of the session. To provide large-scale support for applications and traffic classes requiring bandwidth allocations and delay bounds over the network infrastructure, Cisco IOS QoS includes a version of WFQ that runs only in distributed mode on VIPs. This version is called VIP-distributed WFQ (DWFQ). It provides increased flexibility in terms of traffic classification, weight assessment, and discard policy, and delivers Internet-scale performance on the Cisco 7500 series platforms. For serial interfaces at E1 (2.048 Mbps) and below, WFQ is used by default. When no other queueing strategies are configured, all other interfaces use FIFO by default.

CBWFQ and Distributed CBWFQ

The class-based WFQ (CBWFQ) and distributed class-based WFQ (DCBWFQ) features extend the standard WFQ functionality to provide support for user-defined traffic classes. They allow you to specify the exact amount of bandwidth to be allocated for a specific class of traffic. Taking into account available bandwidth on the interface, you can configure up to 64 classes and control distribution among them. DCWFQ is intended for use on the VIP-based Cisco 7000 series routers with the Route Switch Processors (RSPs), and the Cisco 7500 series routers.

IP RTP Priority
The IP RTP Priority feature provides a strict priority queueing scheme that allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued. This feature can be used on serial interfaces and Frame Relay PVCs in conjunction with either WFQ or CBWFQ on the same outgoing interface. In either case, traffic matching the range of UDP ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-10

Quality of Service Overview Cisco QoS Features

Frame Relay IP RTP Priority

The Frame Relay IP RTP Priority feature provides a strict priority queueing scheme on a Frame Relay PVC for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the frame-relay ip rtp priority command. The result of using this feature is that voice is serviced as strict priority in preference to other nonvoice traffic.

LLQ
LLQ provides strict priority queueing on ATM VCs and serial interfaces. This feature allows you to configure the priority status for a class within CBWFQ, and is not limited to UDP port numbers, as is IP RTP Priority. LLQ and IP RTP Priority can be configured at the same time, but IP RTP Priority takes precedence. Additionally, the functionality of LLQ has been extended to allow you to specify the Committed Burst (Bc) size in LLQ and to change (or vary) the number of packets contained in the hold queue per-VC (on ATM adapters that support per-VC queueing). For more information, see the chapter Congestion Management Overview in this book.

Distributed LLQ
The Distributed LLQ feature provides the ability to specify low latency behavior for a traffic class on a VIP-based Cisco 7500 series router. LLQ allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued The Distributed LLQ feature also introduces the ability to limit the depth of a device transmission ring.

LLQ for Frame Relay

LLQ for Frame Relay is provides strict PQ for voice traffic and WFQs for other classes of traffic. Before the release of this feature, LLQ was available at the interface and ATM VC levels. It is now available at the Frame Relay VC level when Frame Relay Traffic Shaping is configured. Strict PQ improves QoS by allowing delay-sensitive traffic such as voice to be pulled from the queue and sent before other classes of traffic. LLQ for Frame Relay allows you to define classes of traffic according to protocol, interface, or access lists. You can then assign characteristics to those classes, including priority, bandwidth, queue limit, and WRED.

Congestion Avoidance
Congestion avoidance techniques monitor network traffic loads in an effort to anticipate and avoid congestion at common network and internetwork bottlenecks before it becomes a problem. These techniques are designed to provide preferential treatment for premium (priority) class traffic under congestion situations while concurrently maximizing network throughput and capacity utilization and minimizing packet loss and delay. WRED and DWRED are the Cisco IOS QoS congestion avoidance features.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-11

Quality of Service Overview Cisco QoS Features

Router behavior allows output buffers to fill during periods of congestion, using the tail drop feature to resolve the problem when WRED is not configured. During tail drop, a potentially large number of packets from numerous connections are discarded because of lack of buffer capacity. This behavior can result in waves of congestion followed by periods during which the transmission link is not fully used. WRED obviates this situation proactively by providing congestion avoidance. That is, instead of waiting for buffers to fill before dropping packets, the router monitors the buffer depth and performs early discards on selected packets sent over selected connections. WRED is the Cisco implementation of the RED class of congestion avoidance algorithms. When RED is used and the source detects the dropped packet, the source slows its transmission. RED is primarily designed to work with TCP in IP internetwork environments. WRED can also be configured to use the DSCP value when it calculates the drop probability of a packet, enabling WRED to be compliant with the DiffServ standard being developed by the Internet Engineering Task Force (IETF). For more complete conceptual information, see the chapter Congestion Avoidance Overview in this book. For information on how to configure WRED, DWRED, flow-based WRED, and DiffServ Compliant WRED, see the chapter Configuring Weighted Random Early Detection in this book. For complete command syntax information, refer to the Cisco IOS Quality of Service Solutions Command Reference.

WRED
WRED, the Cisco implementation of RED, combines the capabilities of the RED algorithm with IP Precedence to provide preferential traffic handling for higher priority packets. It can selectively discard lower priority traffic when the interface begins to get congested and provide differentiated performance characteristics for different classes of service. WRED is also RSVP-aware. WRED is available on the Cisco 7200 series RSP.

DWRED
DWRED is the Cisco high-speed version of WRED. The DWRED algorithm was designed with ISP providers in mind; it allows an ISP to define minimum and maximum queue depth thresholds and drop capabilities for each class of service. DWRED, which is available on the Cisco 7500 series routers or the Cisco 7000 series router with RSPs is analogous in function to WRED, which is available on the Cisco 7200 series RSP.

Flow-Based WRED
The Flow-based WRED feature forces WRED to afford greater fairness to all flows on an interface in regard to how packets are dropped. To provide fairness to all flows, flow-based WRED has the following features:

It ensures that flows that respond to WRED packet drops by backing off packet transmission are protected from flows that do not respond to WRED packet drops. It prohibits a single flow from monopolizing the buffer resources at an interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-12

Quality of Service Overview Cisco QoS Features

DiffServ Compliant WRED

The DiffServ Compliant WRED feature extends the functionality of WRED to enable support for Differentiated Services (DiffServ) and Assured Forwarding (AF) Per Hop Behavior (PHB). This feature enables customers to implement AF PHB by coloring packets according to DSCP values and then assigning preferential drop probabilities to those packets. The DiffServ and the AF PHB standards are supported by this feature.

Policing and Shaping

Cisco IOS QoS includes traffic policing capabilities implemented through the rate-limiting aspects of CAR, and the Traffic Policing feature. For traffic shaping, Cisco IOS QoS includes Generic Traffic Shaping (GTS), Class-Based Shaping, Distributed Traffic Shaping (DTS), and FRTS protocols. For more complete conceptual information, see the chapter Policing and Shaping Overview in this book. For information on how to configure the Traffic Policing feature, see the chapter Configuring Traffic Policing in this book. For information on how to configure GTS, Class-Based Shaping, and DTS, see the following chapters in this book:

Configuring Generic Traffic Shaping Configuring Class-Based Shaping Configuring Distributed Traffic Shaping

Note

For information on how to configure Frame Relay and Frame Relay Traffic Shaping, refer to the Cisco IOS Wide-Area Networking Configuration Guide.

Note

For complete command syntax information on the commands related to Traffic Policing, GTS, Class-Based Shaping, and DTS, refer to the Cisco IOS Quality of Service Solutions Command Reference.

CAR Rate Limiting

The rate-limiting feature of CAR provides the network operator with the means to define Layer 3 aggregate or granular access, or egress bandwidth rate limits, and to specify traffic handling policies when the traffic either conforms to or exceeds the specified rate limits. Aggregate access or egress matches all packets on an interface or subinterface. Granular access or egress matches a particular type of traffic based on precedence. You can designate CAR rate-limiting policies based on physical port, packet classification, IP address, MAC address, application flow, and other criteria specifiable by access lists or extended access lists. CAR rate limits may be implemented either on input or output interfaces or subinterfaces including Frame Relay and ATM subinterfaces. An example of the use of the rate-limiting capability of CAR is application-based rates limiting HTTP World Wide Web traffic to 50 percent of link bandwidth, which ensures capacity for non-Web traffic including mission-critical applications.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-13

Quality of Service Overview Cisco QoS Features

Traffic Policing
The Traffic Policing feature performs the following functions:

Limits the input or output transmission rate of a class of traffic based on user-defined criteria Marks packets by setting the IP Precedence value, the QoS group, or the DSCP value

Shaping
Cisco IOS QoS software the following traffic shaping features that manage traffic and congestion on the network:

GTS, which provides a mechanism to control the flow of outbound traffic on a particular interface. It reduces outbound traffic flow to avoid congestion by constraining specified traffic to a particular bit rate. Traffic adhering to a particular profile can be shaped to meet downstream requirements, eliminating bottlenecks in topologies with data rate mismatches. Class-Based Shaping, which provides the means for configuring GTS on a class, rather than only on an access control list (ACL). Using the Class-Based Shaping feature, you can perform the following tasks:
Configure GTS on a traffic class Specify average rate or peak rate traffic shaping Configure CBWFQ inside GTS

Class-Based Shaping can be enabled on any interface that supports GTS.

DTS, which provides the means for managing the bandwidth of an interface to avoid congestion, to meet remote site requirements, and to conform to a service rate that is provided on that interface. DTS uses queues to buffer traffic surges that can congest a network. FRTS, which provides parameters such as the following that are useful for managing network traffic congestion:
Committed information rate (CIR) Forward and backward explicit congestion notification (FECN/BECN) The discard eligible (DE) bit

For some time Cisco has provided support for FECN for DECnet and OSI, BECN for SNA traffic using direct Logical Link Control, type 2 (LLC2) encapsulation via RFC 1490, and DE bit support. The FRTS feature builds upon this Frame Relay support by providing additional capabilities that improve the scalability and performance of a Frame Relay network by increasing the density of VCs and improving response time. FRTS applies only to Frame Relay permanent PVCs and switched virtual circuits (SVCs).

Signalling
Cisco IOS QoS signalling provides a way for an end station or network node to signal its neighbors to request special handling of certain traffic. QoS signalling is useful for coordinating the traffic handling techniques provided by other QoS features. It plays a key role in configuring successful overall end-to-end QoS service across your network.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-14

Quality of Service Overview Cisco QoS Features

Cisco IOS QoS signalling takes advantage of IP. Either in-band (IP Precedence, 802.1p) or out-of-band (RSVP) signalling is used to indicate that a particular QoS service is desired for a particular traffic classification. Together, IP Precedence and RSVP provide a robust combination for end-to-end QoS signalling: IP Precedence signals for differentiated QoS and RSVP for guaranteed QoS. To achieve the end-to-end benefits of IP Precedence and RSVP signalling, Cisco IOS QoS software offers ATM User Network Interface (UNI) signalling and the Frame Relay Local Management Interface (LMI) to provide signalling into their respective backbone technologies. To achieve centralized monitoring and control of RSVP signalling, Cisco IOS software offers Common Open Policy Service (COPS) with RSVP. To enable admission control over IEEE 802-styled networks, Cisco IOS QoS software offers Subnetwork Bandwidth Manager (SBM). To provide support for Controlled Load Service using RSVP over an ATM core network, Cisco IOS QoS software offers the RSVP-ATM QoS Interworking feature. Cisco also provides RSVP support for Low Latency Queueing (LLQ) and Frame Relay. For more complete conceptual information, see the chapter Signalling Overview in this book. For information on how to configure the various protocols that implement signalling, see the following chapters:

Configuring RSVP Configuring RSVP Support for LLQ Configuring RSVP Support for Frame Relay Configuring COPS for RSVP Configuring Subnetwork Bandwidth Manager Configuring RSVP-ATM QoS Interworking

For complete command syntax information, refer to the Cisco IOS Quality of Service Solutions Command Reference.

Link Efficiency Mechanisms

Cisco IOS QoS software offers three link efficiency mechanisms that work in conjunction with queueing and traffic shaping to improve efficiency and predictability of the application services levels: Link Fragmentation and Interleaving (LFI), Compressed Real-Time Protocol (CRTP), and Distributed Compressed Real-Time Protocol (dCRTP). For more complete conceptual information, see the chapter Link Efficiency Mechanisms Overview in this book. For complete command syntax information, refer to the Cisco IOS Quality of Service Solutions Command Reference.

Link Fragmentation and Interleaving

Interactive traffic, such as Telnet and VoIP, is susceptible to increased latency and jitter when the network processes large packets, such as LAN-to-LAN FTP Telnet transfers traversing a WAN link. This susceptibility increases as the traffic is queued on slower links. Cisco IOS QoS LFI reduces delay and jitter on slower speed links by breaking up large datagrams and interleaving low-delay traffic packets with the resulting smaller packets.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-15

Quality of Service Overview Cisco QoS Features

For information on how to configure LFI, see the chapter Configuring Link Fragmentation and Interleaving for Multilink PPP, or the chapter Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits in this book.

Compressed Real-Time Protocol

RTP is a host-to-host protocol used for carrying newer multimedia application traffic, including packetized audio and video, over an IP network. RTP provides end-to-end network transport functions intended for applications sending real-time requirements, such as audio, video, or simulation data multicast or unicast network services. To avoid the unnecessary consumption of available bandwidth, the RTP header compression feature, referred to as CRTP, is used on a link-by-link basis. For information on how to configure CRTP, see the chapter Configuring Compressed Real-Time Protocol in this book.

Distributed Compressed Real-Time Protocol

The dCRTP feature compresses the combined 40-byte IP/UDP/RTP packet headers to 2 to 4 bytes on packets traveling on a Cisco 7500 series router with a VIP in distributed fast-switching and distributed Cisco Express Forwarding (dCEF) environments. This compression reduces the packet size, improves the speed of packet transmission, and reduces packet latency. For information on how to configure the dCRTP feature, see the chapter Configuring Distributed Compressed Real-Time Protocol in this book.

QoS Solutions
IP to ATM CoS
IP to ATM CoS is a feature suite that maps QoS characteristics between IP and ATM, making it possible to support differential services in network service provider environments. Network managers can use existing features such as CAR or PBR to classify and mark different IP traffic by modifying the IP Precedence field in the IPv4 packet header. Subsequently, WRED or DWRED can be configured on a per-VC basis so that the IP traffic is subject to different drop probabilities (and therefore priorities) as IP traffic coming into a router competes for bandwidth on a particular VC. IP to ATM CoS provides support for ATM VC bundle management, allowing you to configure multiple VCs that have different QoS characteristics between any pair of ATM-connected routers. IP to ATM CoS also provides for per-VC WFQ and CBWFQ, which allows you to apply CBWFQ functionalitynormally applicable at the interface or subinterface levels onlyto an individual VC configured for IP to ATM CoS. You can use this feature to apply either CBWFQ or flow-based WFQ on a per-VC basis. For more complete conceptual information, see the chapter IP to ATM Class of Service Overview in this book. For information on how to configure IP to ATM CoS, see the chapter Configuring IP to ATM Class of Service in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-16

Quality of Service Overview Cisco QoS Features

QoS Features for Voice

Many of the QoS features already mentioned in this chapter are useful for voice applications. For a high-level overview of Cisco IOS QoS features for voice, see the chapter QoS Features for Voice in this book.

Differentiated Services Implementations

Many of the QoS features mentioned in this book can be used to implement Differentiated Services on your network. For a high-level overview of how to use the Cisco IOS components to implement Differentiated Services, see the chapter Implementing DiffServ for End-to-End Quality of Service Overview in this book.

Modular QoS Command-Line Interface

The Modular CLI is a CLI structure that allows users to create traffic policies and attach these policies to interfaces. For conceptual information about the Modular QoS CLI, see the chapter Modular Quality of Service Command-Line Interface Overview in this book. The Modular QoS CLI contains the following three steps:

Define a traffic class with the class-map command. Create a traffic policy by associating the traffic class with one or more QoS features (using the policy-map command). Attach the traffic policy to the interface with the service-policy command.

For information on how to configure the Modular QoS CLI, see Configuring the Modular Quality of Service Command-Line Interface in this book.

Security Device Manager

The Cisco Router and Security Device Manager (SDM) provides an intuitive, graphical user interface for configuring and monitoring advanced IP-based QoS functionality within Cisco routers. For a high-level overview of SDM, see the chapter Security Device Manager Overview in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-17

Quality of Service Overview Cisco QoS Features

Cisco IOS Quality of Service Solutions Configuration Guide

QC-18

Classification

Classification Overview
Classification entails using a traffic descriptor to categorize a packet within a specific group to define that packet and make it accessible for QoS handling on the network. Using packet classification, you can partition network traffic into multiple priority levels or classes of service. When traffic descriptors are used to classify traffic, the source agrees to adhere to the contracted terms and the network promises a quality of service. Traffic policers, such as the Traffic Policing feature and the rate-limiting feature of committed access rate (CAR), and traffic shapers, such as Generic Traffic Shaping (GTS), Distributed Traffic Shaping (DTS) and Frame Relay Traffic Shaping (FRTS), use traffic descriptor of a packetthat is, its classificationto ensure adherence to the contract. Packet classification is pivotal to policy techniques that select packets traversing a network element or a particular interface for different types of QoS service. For example, you can use classification to mark certain packets for IP Precedence and you can identify others as belonging to a Resource Reservation Protocol (RSVP) flow. Methods of classification were once limited to use of the contents of the packet header. Current methods of marking a packet with its classification allow you to set information in the Layer 2, 3, or 4 headers, or even by setting information within the payload of a packet. Criteria for classification of a group might be as broad as traffic destined for subnetwork X or as narrow as a single flow. This chapter explains IP Precedence, then it gives a brief description of the kinds of traffic classification provided by the Cisco IOS QoS features. It discusses features described in the following sections:

Policy-Based Routing QoS Policy Propagation via Border Gateway Protocol Committed Access Rate Class-Based Packet Marking QoS for Virtual Private Networks Network-Based Application Recognition

Cisco IOS Quality of Service Solutions Configuration Guide

QC-21

Classification Overview About IP Precedence

About IP Precedence
Use of IP Precedence allows you to specify the class of service (CoS) for a packet. You use the three precedence bits in the type of service (ToS) field of the IP version 4 (IPv4) header for this purpose. Figure 2 shows the ToS field.
Figure 2 IPv4 Packet Type of Service Field

IPv4 packet Data

ToS field 3-bit precedence

16757

Using the ToS bits, you can define up to six classes of service. Other features configured throughout the network can then use these bits to determine how to treat the packet in regard to the ToS to grant it. These other QoS features can assign appropriate traffic-handling policies including congestion management strategy and bandwidth allocation. For example, although IP Precedence is not a queueing method, queueing methods such as weighted fair queueing (WFQ) and Weighted Random Early Detection (WRED) can use the IP Precedence setting of the packet to prioritize traffic. By setting precedence levels on incoming traffic and using them in combination with the Cisco IOS QoS queueing features, you can create differentiated service. You can use features such as policy-based routing (PBR) and CAR to set precedence based on extended access list classification. These features afford considerable flexibility for precedence assignment. For example, you can assign precedence based on application or user, or by destination and source subnetwork. So that each subsequent network element can provide service based on the determined policy, IP Precedence is usually deployed as close to the edge of the network or the administrative domain as possible. You can think of IP Precedence as an edge function that allows core, or backbone, QoS features such as WRED to forward traffic based on CoS. IP Precedence can also be set in the host or network client, but this setting can be overridden by policy within the network. The following QoS features can use the IP Precedence field to determine how traffic is treated:

Distributed WRED (DWRED) WFQ CAR

How the IP Precedence Bits Are Used to Classify Packets

You use the three IP Precedence bits in the ToS field of the IP header to specify CoS assignment for each packet. You can partition traffic into up to six classesthe remaining two are reserved for internal network useand then use policy maps and extended access lists to define network policies in terms of congestion handling and bandwidth allocation for each class. For historical reasons, each precedence corresponds to a name. These names, which continue to evolve, are defined in the RFC 791 document. Table 3 lists the numbers and their corresponding names, from least to most important.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-22

Classification Overview About IP Precedence

Table 3

IP Precedence Values

Number 0 1 2 3 4 5 6 7

Name routine priority immediate flash flash-override critical internet network

However, the IP Precedence feature allows you considerable flexibility for precedence assignment. That is, you can define your own classification mechanism. For example, you might want to assign precedence based on application or access router.

Note

IP Precedence bit settings 6 and 7 are reserved for network control information such as routing updates.

Setting or Changing the IP Precedence Value

By default, the Cisco IOS software leaves the IP Precedence value untouched, preserving the precedence value set in the header, allowing all internal network devices to provide service based on the IP Precedence setting. This policy follows the standard approach stipulating that network traffic should be sorted into various types of service at the basic perimeter of the network and that those types of service should be implemented in the core of the network. Routers in the core of the network can then use the precedence bits, for example, to determine the order of transmission, the likelihood of packet drop, and so on. Because traffic coming into your network can have precedence set by outside devices, we recommend you reset the precedence for all traffic entering your network. By controlling IP Precedence settings, you prohibit users that have already set the IP precedence from acquiring better service for their traffic simply by setting a high precedence for all of their packets. You can use any of the features described in the following sections to set the IP precedence in packets:

Policy-Based Routing QoS Policy Propagation via Border Gateway Protocol Committed Access Rate

As mentioned previously, after a packet has been classified, you can use other QoS features such as CAR and WRED to specify and enforce business policies to fit your business model.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-23

Classification Overview Policy-Based Routing

Policy-Based Routing
PBR gives you a flexible means of routing packets by allowing you to configure a defined policy for traffic flows, lessening reliance on routes derived from routing protocols. To this end, PBR gives you more control over routing by extending and complementing the existing mechanisms provided by routing protocols. PBR allows you to set the IP precedence. It also allows you to specify a path for certain traffic, such as priority traffic over a high-cost link. You can set up PBR as a way to route packets based on configured policies. For example, you can implement routing policies to allow or deny paths based on the identity of a particular end system, an application protocol, or the size of packets. PBR allows you to perform the following tasks:

Classify traffic based on extended access list criteria. Access lists, then, establish the match criteria. Set IP Precedence bits, giving the network the ability to enable differentiated classes of service. Route packets to specific traffic-engineered paths; you might need to route them to allow a specific QoS through the network.

Policies can be based on IP address, port numbers, protocols, or size of packets. For a simple policy, you can use any one of these descriptors; for a complicated policy, you can use all of them. For example, classification of traffic through PBR allows you to identify traffic for different classes of service at the edge of the network and then implement QoS defined for each CoS in the core of the network using priority queueing (PQ), custom queueing (CQ), or WFQ techniques. This process obviates the need to classify traffic explicitly at each WAN interface in the core-backbone network. For information on how to configure policy-based routing, see the chapter Configuring Policy-Based Routing in this book.

How It Works
All packets received on an interface with PBR enabled are passed through enhanced packet filters known as route maps. The route maps used by PBR dictate the policy, determining to where the packets are forwarded. Route maps are composed of statements. The route map statements can be marked as permit or deny, and they are interpreted in the following ways:

If the packets do not match any route map statements, then all the set clauses are applied. If a statement is marked as deny, the packets meeting the match criteria are sent back through the normal forwarding channels and destination-based routing is performed. If the statement is marked as permit and the packets do not match any route map statements, the packets are sent back through the normal forwarding channels and destination-based routing is performed.

You specify PBR on the interface that receives the packet, not on the interface from which the packet is sent.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-24

Classification Overview QoS Policy Propagation via Border Gateway Protocol

When Should You Use Policy-Based Routing?

You might enable PBR if you want certain packets to be routed some way other than the obvious shortest path. For example, PBR can be used to provide the following functionality:

equal access protocol-sensitive routing source-sensitive routing routing based on interactive versus batch traffic routing based on dedicated links

Some applications or traffic can benefit from QoS-specific routing; for example, you could transfer stock records to a corporate office on a higher-bandwidth, higher-cost link for a short time while sending routine application data such as e-mail over a lower-bandwidth, lower-cost link.

QoS Policy Propagation via Border Gateway Protocol

The Border Gateway Protocol (BGP) is an interdomain routing protocol that exchanges reachability information with other BGP systems. It is defined by RFC 1163. The Policy Propagation via BGP feature allows you to classify packets based on the following:

Access lists. BGP community lists. A community is a group of destinations that share some common attribute. You use community lists to create groups of communities to use in a match clause of a route map. As with access lists, a series of community lists can be created. BGP autonomous system paths. An autonomous system path is a collection of networks under a common administration sharing a common routing strategy. BGP carries the autonomous system path in its routing updates. You can filter routing updates by specifying an access list on both incoming and outbound updates based on the BGP autonomous system path. IP Precedence. See the section About IP Precedence earlier in this chapter. Source and destination address lookup. You can specify whether the IP Precedence level is obtained from the source (input) address or destination (output) address entry in the route table.

After a packet has been classified using BGP, you can use other QoS features such as CAR and WRED to specify and enforce business policies to fit your business model. BGP Policy Propagation leverages BGP to distribute QoS policy to remote routers in your network. It allows ingress routers to prioritize incoming traffic.

Restrictions
For the Policy Propagation via BGP feature to work, you must enable BGP and Cisco Express Forwarding (CEF)/distributed CEF (dCEF) on the router. Subinterfaces on an ATM interface that has the bgp-policy command enabled must use CEF mode because dCEF is not supported. (Note that dCEF uses the Versatile Interface Processor (VIP) rather than the Route Switch Processor (RSP) to perform forwarding functions.) For information on how to configure Policy Propagation via BGP, see the chapter Configuring QoS Policy Propagation via Border Gateway Protocol in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-25

Classification Overview Committed Access Rate

Committed Access Rate

CAR is a multifaceted feature that implements both classification services and policing through rate limiting. This section describes its classification capability. For information on its rate limiting features, see the chapter Policing and Shaping Overview in this book. You can use the classification services of CAR to set the IP precedence for packets entering the network. This capability of CAR allows you to partition your network into multiple priority levels or classes of service. Networking devices within your network can then use the adjusted IP precedence to determine how to treat the traffic. For example, VIP-distributed WRED uses the IP precedence to determine the probability of whether a packet will be dropped. As discussed in the section About IP Precedence, you can use the three precedence bits in the ToS field of the IP header to define up to six classes of service. You can classify packets using policies based on physical port, source or destination IP or MAC address, application port, IP protocol type, or other criteria specifiable by access lists or extended access lists. You can classify packets by categories external to the network, for example, by a customer. After a packet has been classified, a network can either accept or override and reclassify the packet according to a specified policy. CAR includes commands you can use to classify and reclassify packets. CAR is supported on the majority of Cisco routers. Additionally, distributed CAR is supported on Cisco 7000 series routers with an RSP7000 interface processor or Cisco 7500 series routers with a VIP-based VIP2-40 or greater interface processor. A VIP2-50 interface processor is strongly recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 interface processor is required for OC-3 rates. For information on how to configure CAR, see the chapter Configuring Committed Access Rate in this book.

Class-Based Packet Marking

The Class-Based Packet Marking feature provides users with a means for efficient packet marking by which users can differentiate packets based on the designated markings. The Class-Based Packet Marking feature allows users to perform the following tasks:

Mark packets by setting the IP Precedence bits or the IP differentiated services code point (DSCP) in the IP ToS byte. Mark packets by setting the Layer 2 CoS value. Associate a local QoS group value with a packet. Set the Cell Loss Priority (CLP) bit setting in the ATM header of a packet from 0 to 1.

The Class-Based Packet Marking feature supports the following RFCs:

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 2475, An Architecture for Differentiated Services Framework RFC 2597, Assured Forwarding PHB RFC 2598, An Expedited Forwarding PHB

For information on how to configure Class-Based Packet Marking, see the chapter Configuring Class-Based Packet Marking in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-26

Classification Overview Class-Based Packet Marking

IP Precedence and IP DSCP Marking

Associating a packet with an IP Precedence or IP DSCP marking allows users to classify traffic based on IP Precedence and IP DSCP value, depending on which value is marked. These markings can be used to identify traffic within the network, and other interfaces can match traffic based on the IP Precedence or DSCP markings. IP Precedence and DSCP markings are used to decide how packets should be treated in Weighted Random Early Detection (WRED). The IP DSCP value is the first 6 bits in the ToS byte, while the IP Precedence value is the first 3 bits in the ToS value. The IP Precedence value is actually part of the IP DSCP value. Therefore, both values cannot be set simultaneously. If both values are set simultaneously, the packet is marked with the IP DSCP value. If you need to mark packets in your network and all of your devices support IP DSCP marking, use the IP DSCP marking to mark your packets, since the IP DSCP markings provide more packet marking options. If marking by IP DSCP is undesirable, however, or if you are unsure if the devices in your network support IP DSCP values, use the IP precedence value to mark your packets. The IP precedence value is likely supported by all devices in the network. A user can set up to 8 different IP precedence markings and 64 different IP DSCP markings.

CoS Value Marking

Associating a packet with a local CoS value allows users to associate a Layer 2 CoS value with a packet. The value can then be used to classify packets based on user-defined requirements. Layer 2 to Layer 3 mapping can also be configured by matching on the CoS value, because switches already have the capability to match and set CoS values. If a packet that needs to be marked to differentiate user-defined QoS services is leaving a router and entering a switch, the router should set the CoS value of the packet, because the switch can process the Layer 2 CoS header marking. A user can set up to 8 different CoS markings.

QoS Group Value Marking

Associating a packet with a local QoS group allows users to associate a group ID with a packet. The group ID can be used to classify packets into QoS groups based on prefix, autonomous system, or community string. This QoS group marking can only be used to classify traffic within a router, and cannot be used to mark packets leaving the router. A user can set up to 100 different QoS group markings.

ATM CLP Bit Setting

Changing the CLP bit setting in the ATM header of a cell provides a method of controlling the discarding of cells in congested ATM environments. A CLP bit contains two settings: 0 or 1. Cells with a CLP bit setting of 1 are discarded before cells with a CLP bit setting of 0 when congestion occurs.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-27

Classification Overview Class-Based Packet Marking

Support for ATM Virtual Circuits

With the Class-Based Packet Marking feature, packet marking is supported on ATM virtual circuits (VCs). Users can configure the marking action in the same policy map where they configure the queueing actions, on a per-VC basis. Previously, packet marking was supported on the main interface or subinterface configuration level.

Additional Statistics
With the Class-Based Packet Marking feature, output from the show policy-map interface command is enhanced to provide additional statistics such as the incoming traffic rate, the dropped packet rate, the number of matched packets, and the number of matched bytes for traffic classes that are attached to the specified interface. The Class-Based Packet Marking feature is configured with the Modular QoS CLI. For additional information on the Modular QoS CLI, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Benefits
Packet Marking Through IP Precedence, QoS Group, CoS Value, and IP DSCP Value Setting
Packet marking allows you to partition your network into multiple priority levels or classes of service, as follows:

Use QoS packet marking to set the IP Precedence or IP DSCP values for packets entering the network. Networking devices within your network can then use the newly marked IP Precedence values to determine how the traffic should be treated. For example, class-based WRED uses IP Precedence values to determine the probability that a packet will be dropped. In addition, voice packets can be marked with a particular color (precedence/DSCP). Low latency queueing (LLQ) can then be configured to put all packets of that mark into the priority queue. Use QoS packet marking to assign packets to a QoS group. The router uses the QoS group to determine how to prioritize packets for transmission. Use CoS packet marking to assign packets to set the priority value of 802.1p/Inter-Switch Link (ISL) packets. The router uses the CoS value to determine how to prioritize packets for transmission and can use this marking to perform Layer 2 to Layer 3 mapping.

Improved Bandwidth Management on ATM Networks

The ability to set the ATM CLP bit allows users to extend their IP QoS policies into an ATM network. As congestion occurs in the ATM network, cells with the CLP bit set are more likely to be dropped, resulting in improved network performance for higher priority traffic and applications.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-28

Classification Overview QoS for Virtual Private Networks

Restrictions
The following restrictions apply to the Class-Based Packet Marking feature:

It can mark only packets traveling on CEF switching paths. In order to use the Class-Based Packet Marking feature, you must configure CEF on both the interface receiving the packet and the interface sending the packet. It can be configured on an interface, a subinterface, or an ATM permanent virtual circuit (PVC), but is not supported on the following interface types:
Fast EtherChannel Tunnel PRI ATM switched virtual circuit (SVC) Frame Relay data-link connection identifier (DLCI) Any interface that does not support CEF

Before modifying the encapsulation type from IEEE 802.1 Q to ISL, or vice versa, on a subinterface, detach the policy map from the subinterface. After changing the encapsulation type, reattach the policy map. To use the set atm-clp command available with the Class-Based Packet Marking feature, you must have one of the following adapters: the Enhanced ATM Port Adapter (PA-A3), the ATM Inverse Multiplexer over ATM Port Adapter with 8 T1 Ports (PA-A3-8T1IMA), or the ATM Inverse Multiplexer over ATM Port Adapter with 8 E1 Ports (PA-A3-8E1IMA). Therefore, the set atm-clp command is not supported on any platform that does not support these adapters. For more information, refer to the documentation for your specific router. A policy map containing the set atm-clp command can be attached as an output policy only. The set atm-clp command does not support packets that originate from the router.

Prerequisites
CEF must be configured on the interface before the Class-Based Packet Marking feature can be used. For additional information on CEF, refer to the Cisco IOS Switching Services Configuration Guide.

QoS for Virtual Private Networks

The QoS for Virtual Private Networks (VPNs) feature is designed for tunnel interfaces. When the feature is enabled, the QoS features on the output interface classify packets before encryption, allowing traffic flows to be adjusted in congested environments. The result is more effective packet tunneling. The QoS for VPNs feature provides a solution for making Cisco IOS QoS services operate in conjunction with tunneling and encryption on an interface. Cisco IOS software can classify packets and apply the appropriate QoS service before the data is encrypted and tunneled. The QoS for VPN feature allows users to look inside the packet so that packet classification can be done based on original port numbers and based on source and destination IP addresses. This allows the service provider to treat mission-critical or multiservice traffic with higher priority across its network. To use this feature, the system must be able to configure QoS features.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-29

Classification Overview Network-Based Application Recognition

Restrictions
Interfaces running cascading QoS features, such as Generic Traffic Shaping (GTS) or CQ, are required to have QoS for VPNs enabled or disabled on all cascading features. If the QoS for VPNs feature is enabled on one cascading feature, the QoS for VPNs feature must be enabled on all cascading features. Similarly, if the QoS for VPNs feature is disabled on one cascading feature, the QoS for VPNs feature must be disabled on all cascading features. For information on how to configure the QoS for VPNs feature, see the chapter Configuring QoS for Virtual Private Networks in this book.

Network-Based Application Recognition

The Network-Based Application Recognition (NBAR) feature adds intelligent network classification to network infrastructures. NBAR is a classification engine that recognizes a wide variety of applications, including web-based and other difficult-to-classify protocols that utilize dynamic TCP/User Datagram Ports (UDP) port assignments. When an application is recognized and classified by NBAR, a network can invoke services for that specific application. NBAR ensures that network bandwidth is used efficiently by working with QoS features to provide the following features:

Guaranteed bandwidth Bandwidth limits Traffic shaping Packet coloring

NBAR introduces the following new classification features:

Classification of applications that dynamically assign TCP/UDP port numbers Classification of HTTP traffic by URL, HOST, or Multipurpose Internet Mail Extension (MIME) type Classification of Citrix Independent Computing Architecture (ICA) traffic by application name Classification of application traffic using subport information

NBAR can also classify static port protocols. Although access control lists (ACLs) can also be used for this purpose, NBAR is easier to configure and can provide classification statistics that are not available when ACLs are used. NBAR provides a special Protocol Discovery feature that determines which application protocols are traversing a network at any given time. The Protocol Discovery feature captures key statistics associated with each protocol in a network. These statistics can be used to define traffic classes and QoS policies for each traffic class.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-30

Classification Overview Network-Based Application Recognition

NBAR addresses IP QoS classification requirements by classifying application-level protocols so that QoS policies can be applied to the classified traffic. NBAR addresses the ongoing need to extend the classification engine for the many existing and emerging application protocols by providing an extensible Packet Description Language (PDL). NBAR can determine which protocols and applications are currently running on a network so that an appropriate QoS policy can be created based upon the current traffic mix and application requirements. NBAR can now perform subport classification of HTTP traffic by host name in addition to classification by MIME-type or URL. This ability enables users to classify HTTP traffic by web server names. With URL matching, only the portion of the URL following the host name can be specified for a match. To perform a match on the host name portion of the URL, use the new HOST matching criterion. For example, a HOST match on http://www.cisco.com/latest/whatsnew.html will classify all traffic from the web server www.cisco.com, whereas a URL match can be performed on the /latest/whatsnew.html portion of the URL. NBAR supports the following RFCs:

RFC 742, NAME/FINGER Protocol RFC 759, Internet Message Protocol RFC 792, Internet Control Message Protocol RFC 793, Transmission Control Protocol RFC 821, Simple Mail Transfer Protocol RFC 827, Exterior Gateway Protocol RFC 854, Telnet Protocol Specification RFC 888, STUB Exterior Gateway Protocol RFC 904 , Exterior Gateway Protocol formal specification. RFC 951, Bootstrap Protocol RFC 959, File Transfer Protocol RFC 977, Network News Transfer Protocol RFC 1001, Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods RFC 1002, Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications RFC 1057, RPC: Remote Procedure Call RFC 1094, NFS: Network File System Protocol Specification RFC 1112, Host Extensions for IP multicasting RFC 1157, Simple Network Management Protocol RFC 1282, BSD Rlogin RFC 1288, The Finger User Information Protocol RFC 1305, Network Time Protocol RFC 1350, The TFTP Protocol (Revision 2) RFC 1436, The Internet Gopher Protocol RFC 1459, Internet Relay Chat Protocol RFC 1510, The Kerberos Network Authentication Service

Cisco IOS Quality of Service Solutions Configuration Guide

QC-31

Classification Overview Network-Based Application Recognition

RFC 1542, Clarifications and Extensions for the Bootstrap Protocol RFC 1579, Firewall-Friendly FTP RFC 1583, OSPF Version 2 RFC 1657, Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol RFC 1701, Generic Routing Encapsulation RFC 1730, Internet Message Access Protocol - Version 4 RFC 1771, A Border Gateway Protocol 4 (BGP-4) RFC 1777, Lightweight Directory Access Protocol RFC 1831, RPC: Remote Procedure Call Protocol Specification Version 2 RFC 1928, SOCKS Protocol Version 5 RFC 1939, Post Office Protocol - Version 3 RFC 1945, Hypertext Transfer Protocol -- HTTP/1.0 RFC 1964, The Kerberos Version 5 GSS-API Mechanism RFC 2060, Internet Message Access Protocol - Version 4rev1 RFC 2068, Hypertext Transfer Protocol -- HTTP/1.1 RFC 2131, Dynamic Host Configuration Protocol RFC 2205, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification RFC 2236, Internet Group Management Protocol, Version 2 RFC 2251, Lightweight Directory Access Protocol (v3) RFC 2252, Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions RFC 2253, Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names RFC 2326, Real Time Streaming Protocol (RTSP) RFC 2401, Security Architecture for the Internet Protocol RFC 2406, IP Encapsulating Security Payload RFC 2453, RIP Version 2 RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1

NBAR supports the following RFCs:

0009, File Transfer Protocol (FTP) 0013, Domain Names - Concepts and Facilities 0033, The TFTP Protocol (Revision 2) 0034, Routing Information Protocol 0053, Post Office Protocol - Version 3 0056, RIP Version 2

For information on how to configure NBAR, see the chapter Configuring Network-Based Application Recognition in this book. You must enable CEF before you configure NBAR. For more information on CEF, refer to the Cisco IOS Switching Services Configuration Guide.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-32

Classification Overview Network-Based Application Recognition

Classification of HTTP by URL, HOST, or MIME

NBAR can classify application traffic by looking beyond the TCP/UDP port numbers of a packet. This ability is called subport classification. NBAR looks into the TCP/UDP payload itself and classifies packets on content within the payload such as transaction identifier, message type, or other similar data. Classification of HTTP by URL, HOST, or MIME type is an example of subport classification. NBAR classifies HTTP traffic by text within the URL or HOST fields of a GET request using regular expression matching. NBAR uses the UNIX filename specification as the basis for the URL or HOST specification format. The NBAR engine then converts the specified match string into a regular expression. NBAR recognizes HTTP GET packets containing the URL and classifies all packets that are sent to the source of the HTTP GET request. Figure 3 illustrates a network topology with NBAR in which Router Y is the NBAR-enabled router.
Figure 3 Network Topology with NBAR

Router X HTTP clients

HTTP get response (classified)

Router Y

HTTP server

When specifying a URL for classification, include only the portion of the URL following the www.hostname.domain in the match statement. For example, for the URL www.cisco.com/latest/whatsnew.html, include only /latest/whatsnew.html. HOST specification is identical to URL specification. NBAR performs a regular expression match on the HOST field contents inside an HTTP GET packet and classifies all packets from that host. For example, for the URL www.cisco.com/latest/whatsnew.html, include only www.cisco.com. For MIME type matching, the MIME type can contain any user-specified text string. A list of the Internet Assigned Numbers Authority (IANA)-supported MIME types can be found at the IANA web site. In MIME type matching, NBAR classifies the packet containing the MIME type and all subsequent packets, which are sent to the source of the HTTP GET request. NBAR supports URL and HOST classification in the presence of persistent HTTP. NBAR does not classify packets that are part of a pipelined request. With pipelined requests, multiple requests are pipelined to the server before previous requests are serviced.

Classification of Citrix ICA Traffic by Application Name

NBAR can classify ICA traffic and perform subport classification of Citrix traffic based on Citrix published applications. NBAR can monitor Citrix ICA client requests for a published application destined to a Citrix ICA Master browser. After the client makes a request to the published application, the Citrix ICA Master browser directs the client to the server with the most available memory. The Citrix ICA client then connects to this Citrix ICA server for the application. NBAR statefully tracks Citrix ICA client/server messages and classifies requests for given Citrix application names and traffic. A Citrix application is named when published on a Citrix ICA server. NBAR performs a regular expression match using a user-specified application name string on the

Cisco IOS Quality of Service Solutions Configuration Guide

29056

HTTP get request

QC-33

Classification Overview Network-Based Application Recognition

contents of the Citrix ICA control packets carrying the published application name. Therefore, users need to specify a regular expression that will result in a match for the published application name if they wish to match a specified application. Refer to the match protocol citrix command in the Cisco IOS Quality of Service Solution Command Reference for additional information. Citrix ICA clients can be configured in various modes. NBAR cannot distinguish among Citrix applications in all modes of operation. Therefore, network administrators might need to collaborate with Citrix administrators to ensure that NBAR properly classifies Citrix traffic. A Citrix administrator can configure Citrix to publish Citrix applications individually or as the entire desktop. In the Published Desktop mode of operation, all applications within the published desktop of a client use the same TCP session. Therefore, differentiation among applications is impossible, and NBAR can only be used to classify Citrix applications as aggregates (by looking at port 1494). The Published Application mode for Citrix ICA clients is recommended when you use NBAR. In Published Application mode, a Citrix administrator can configure a Citrix client in either seamless or nonseamless (windows) modes of operation. In nonseamless mode, each Citrix application uses a separate TCP connection, and NBAR can be used to provide interapplication differentiation based on the name of the published application. Seamless mode clients can operate in one of two submodes: session sharing or nonsession sharing:

In seamless session sharing mode, all clients share the same TCP connection, and NBAR cannot differentiate among applications. Seamless sharing mode is enabled by default on some software releases. In seamless nonsession sharing mode, each application for each particular client uses a separate TCP connection. NBAR can provide interapplication differentiation in seamless nonsession sharing mode.

To turn off session sharing, perform the following steps:

Step 1 Step 2

At the command prompt of the Citrix server, open the registry editor by entering the regedit command. Create the following registry entry (which overrides session sharing):
[HKLM]\SYSTEM\CurrentControlSet\Control\Citrix\WFSHELL\TWI Value name: "SeamlessFlags", type DWORD, possible values :0 or 1

Setting this registry value to 1 overrides session sharing. Note that this flag is SERVER GLOBAL.

Note

NBAR operates properly in ICA secure mode. Pipelined Citrix ICA client requests are not supported.

Protocol Discovery
So that QoS policies can be developed and applied, NBAR includes a Protocol Discovery feature that provides an easy way to discover application protocols that are transiting an interface. The Protocol Discovery feature discovers any protocol traffic supported by NBAR. Protocol Discovery can be applied to interfaces and can be used to monitor both input and output traffic. Protocol Discovery maintains the following per-protocol statistics for enabled interfaces: total number of input and output packets and bytes, and input and output bit rates.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-34

Classification Overview Network-Based Application Recognition

Packet Description Language Module

An external Packet Description Language Module (PDLM) can be loaded at run time to extend the NBAR list of recognized protocols. PDLMs can also be used to enhance an existing protocol recognition capability. PDLMs allow NBAR to recognize new protocols without requiring a new Cisco IOS image or a router reload. New PDLMs will be released only by Cisco and can be loaded from Flash memory. Please contact your local Cisco representative to request additions or changes to the set of protocols classified by NBAR.

Memory Management
NBAR uses approximately 150 bytes of DRAM for each flow that requires stateful inspection. Table 4 lists the stateful protocols supported by NBAR that require stateful inspection. When NBAR is configured, it allocates 1 MB of DRAM to support up to 5000 concurrent flows. NBAR checks to determine if it needs more memory to handle additional concurrent stateful flows. If such a need is detected, NBAR expands its memory usage in increments of 200 Kb to 400 Kb.
Table 4 TCP and UDP Stateful Protocols

Cisco IOS Release1 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

Protocol FTP

Type TCP

Description File Transfer Protocol

Syntax ftp

Exchange

TCP

MS-RPC for Exchange

exchange

HTTP 12.0(5)XE2 12.1(1)E 12.1(5)T (HTTP Host classification is not available on the 12.0 XE train) 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T Netshow

TCP

HTTP with URL, MIME, or HOST classification

http

TCP/ UDP TCP/ UDP TCP

Microsoft Netshow

netshow

RealAudio

RealAudio Streaming Protocol

realaudio

r-commands

rsh, rlogin, rexec

rcmd

StreamWorks

UDP

Xing Technology Stream Works audio and video

streamwork

Cisco IOS Quality of Service Solutions Configuration Guide

QC-35

Classification Overview Network-Based Application Recognition

Table 4

TCP and UDP Stateful Protocols (continued)

Cisco IOS Release1 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

Protocol SQL*NET

Type TCP/ UDP TCP/ UDP UDP

Description SQL*NET for Oracle

Syntax sqlnet

SunRPC

Sun Remote Procedure Call

sunrpc

TFTP

Trivial File Transfer Protocol

tftp

VDOLive

TCP/ UDP

VDOLive Streaming Video

vdolive

1. Indicates the Cisco IOS maintenance release that first supported the protocol.

Supported Protocols
NBAR can classify the following three types of protocols:

TCP and UDP protocols that dynamically assign port numbers and therefore require stateful inspection Non-UDP and non-TCP IP protocols TCP and UDP protocols that use statically assigned port numbers

Table 5 lists all of the non-UDP and non-TCP protocols than NBAR can classify. Table 6 lists the TCP and UDP static port protocols.
Table 5 Non-UDP and Non-TCP Protocols

Cisco IOS Release1 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

Protocol EGP

Type IP

Well-Known Port Number 8

Description Exterior Gateway Protocol

Syntax egp

GRE

IP

47

Generic Routing Encapsulation Internet Control Message Protocol IP in IP

gre

ICMP

IP

icmp

IPINIP

IP

ipinip

Cisco IOS Quality of Service Solutions Configuration Guide

QC-36

Classification Overview Network-Based Application Recognition

Table 5

Non-UDP and Non-TCP Protocols (continued)

Cisco IOS Release1 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

Protocol IPSec

Type IP

Well-Known Port Number 50, 51

Description IP Encapsulating Security Payload/Authentication Header Enhanced Interior Gateway Routing Protocol

Syntax ipsec

EIGRP

IP

88

eigrp

1. Indicates the Cisco IOS maintenance release that first supported the protocol.

Table 6

TCP and UDP Static Port Protocols

Cisco IOS Release1 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

Protocol BGP

Type TCP/UDP

Well-Known Port Number 179

Description Border Gateway Protocol Desktop video conferencing Desktop video conferencing

Syntax bgp

CU-SeeMe

TCP/UDP

7648, 7649

cuseeme

CU-SeeMe

UDP

24032

cuseeme

DHCP/ BOOTP DNS

UDP

67, 68

Dynamic Host dhcp Configuration Protocol/ Bootstrap Protocol Domain Name System dns

TCP/UDP

53

Finger

TCP

79

Finger user information finger protocol Internet Gopher Protocol Hypertext Transfer Protocol Secured HTTP gopher

Gopher

TCP/UDP

70

HTTP

TCP

80

http

HTTPS

TCP

443

secure-http

IMAP

TCP/UDP

143, 220

Internet Message Access Protocol

imap

Cisco IOS Quality of Service Solutions Configuration Guide

QC-37

Classification Overview Network-Based Application Recognition

Table 6

TCP and UDP Static Port Protocols (continued)

Cisco IOS Release1 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

Protocol IRC

Type TCP/UDP

Well-Known Port Number 194

Description Internet Relay Chat

Syntax irc

Kerberos

TCP/UDP

88, 749

Kerberos Network Authentication Service L2F/L2TP tunnel

kerberos

L2TP

UDP

1701

l2tp

LDAP

TCP/UDP

389

Lightweight Directory Access Protocol Microsoft Point-to-Point Tunneling Protocol for Virtual Private Networks (VPNs) Microsoft SQL Server Desktop Videoconferencing NetBIOS over IP (MS Windows) NetBIOS over IP (MS Windows) Network File System

ldap

MS-PPTP

TCP

1723

pptp

12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.1(2)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

MSSQLServer NetBIOS

TCP

1433

sqlserver

TCP

137, 139

netbios

NetBIOS

UDP

137, 138

netbios

NFS

TCP/UDP

2049

nfs

NNTP

TCP/UDP

119

Network News Transfer nntp Protocol Lotus Notes notes

Notes

TCP/UDP

1352

Novadigm

TCP/UDP

3460 to 3465 Novadigm Enterprise Desktop Manager (EDM) 123

novadigm

NTP

TCP/UDP

Network Time Protocol ntp

PCAnywhere

TCP

5631, 65301

Symantec PCAnywhere pcanywhere

Cisco IOS Quality of Service Solutions Configuration Guide

QC-38

Classification Overview Network-Based Application Recognition

Table 6

TCP and UDP Static Port Protocols (continued)

Cisco IOS Release1 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.1(2)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

Protocol PCAnywhere

Type UDP

Well-Known Port Number 22, 5632

Description

Syntax

Symantec PCAnywhere pcanywhere

POP3

TCP/UDP

110

Post Office Protocol

pop3

Printer RIP

TCP/UDP UDP

515 520

Printer Routing Information Protocol Resource Reservation Protocol Secure FTP

printer rip

RSVP

UDP

1698,1699

rsvp

SFTP

TCP

990

secure-ftp

SHTTP

TCP

443

Secure HTTP

secure-http

SIMAP

TCP/UDP

585, 993

Secure IMAP

secure-imap

SIRC

TCP/UDP

994

Secure IRC

secure-irc

SLDAP

TCP/UDP

636

Secure LDAP

secure-ldap

SNNTP

TCP/UDP

563

Secure NNTP

secure-nntp

SMTP

TCP

25

Simple Mail Transfer Protocol Simple Network Management Protocol Firewall security protocol

smtp

SNMP

TCP/UDP

161, 162

snmp

SOCKS

TCP

1080

socks

Cisco IOS Quality of Service Solutions Configuration Guide

QC-39

Classification Overview Network-Based Application Recognition

Table 6

TCP and UDP Static Port Protocols (continued)

Cisco IOS Release1 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T 12.0(5)XE2 12.1(1)E 12.1(5)T

Protocol SPOP3

Type TCP/UDP

Well-Known Port Number 995

Description Secure POP3

Syntax secure-pop3

SSH

TCP

22

Secured Shell

ssh

STELNET

TCP

992

Secure Telnet

secure-telnet

Syslog

UDP

514

System Logging Utility syslog

Telnet

TCP

23

Telnet Protocol

telnet

X Window System

TCP

6000-6003

X11, X Window System xwindows

1. Indicates the Cisco IOS maintenance release that first supported the protocol.

Restrictions
The NBAR feature does not support the following:

More than 24 concurrent URLs, HOSTs, or MIME type matches Matching beyond the first 400 bytes in a URL Non-IP traffic Multicast and other non-CEF switching modes Fragmented packets Pipelined persistent HTTP requests URL/HOST/MIME/ classification with secure HTTP Asymmetric flows with stateful protocols Packets originating from or destined to the router running NBAR

NBAR is not configurable on the following logical interfaces:

Fast EtherChannel Interfaces where tunneling or encryption is used VLANs

Note

NBAR is configurable on VLANs as of Cisco IOS Release 12.1(13)E, but supported in the software switching path only.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-40

Classification Overview Network-Based Application Recognition

Dialer interfaces Multilink PPP

Note

NBAR cannot be used to classify output traffic on a WAN link where tunneling or encryption is used. Therefore, NBAR should be configured on other interfaces on the router (such as a LAN link) to perform input classification before the traffic is switched to the WAN link for output.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-41

Classification Overview Network-Based Application Recognition

Cisco IOS Quality of Service Solutions Configuration Guide

QC-42

Configuring Policy-Based Routing

This chapter describes the tasks for configuring policy-based routing (PBR) on a router. For complete conceptual information about this feature, see the section Policy-Based Routing in the chapter Classification Overview in this book. For a complete description of the PBR commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Policy-Based Routing Configuration Task List

To configure PBR, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Enabling PBR (Required) Enabling Fast-Switched PBR (Optional) Enabling Local PBR (Optional) Enabling CEF-Switched PBR (Optional)

See the end of this chapter for the section Policy-Based Routing Configuration Examples.

Enabling PBR
To enable PBR, you must create a route map that specifies the match criteria and the resulting action if all of the match clauses are met. Then, you must enable PBR for that route map on a particular interface. All packets arriving on the specified interface matching the match clauses will be subject to PBR.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-43

Configuring Policy-Based Routing Policy-Based Routing Configuration Task List

To enable PBR on an interface, use the following commands beginning in global configuration mode: Command
Step 1
Router(config)# route-map map-tag [permit | deny] [sequence-number]

Purpose Defines a route map to control where packets are output. This command puts the router into route-map configuration mode. Specifies the match criteria. You can specify one or both of the following:

Step 2

Router(config-route-map)# match length min max Router(config-route-map)# match ip address {access-list-number | name} [...access-list-number | name]

Matches the Level 3 length of the packet. Matches the source and destination IP address that is permitted by one or more standard or extended access lists.

If you do not specify a match command, the route map applies to all packets.
Step 3
Router(config-route-map)# set ip precedence [number | name] Router(config-route-map)# set ip next-hop ip-address [... ip-address] Router(config-route-map)# set interface interface-type interface-number [... type number] Router(config-route-map)# set ip default next-hop ip-address [... ip-address] Router(config-route-map)# set default interface interface-type interface-number [... type ...number]

Specifies the action or actions to take on the packets that match the criteria. You can specify any or all of the following:

Sets precedence value in the IP header. You can specify either the precedence number or name. Sets next hop to which to route the packet (the next hop must be adjacent). Sets output interface for the packet. Sets next hop to which to route the packet, if there is no explicit route for this destination. Sets output interface for the packet, if there is no explicit route for this destination.

Step 4 Step 5

Router(config-route-map)# interface interface-type interface-number Router(config-if)# ip policy route-map map-tag

Specifies the interface. This command puts the router into interface configuration mode. Identifies the route map to use for PBR. One interface can only have one route map tag, but you can have multiple route map entries with different sequence numbers. These entries are evaluated in sequence number order until the first match. If there is no match, packets will be routed as usual.

The set commands can be used in conjunction with each other. They are evaluated in the order shown Step 3 in the previous task table. A usable next hop implies an interface. Once the local router finds a next hop and a usable interface, it routes the packet.

Enabling Fast-Switched PBR

IP PBR can now be fast-switched. Prior to Cisco IOS Release 12.0, PBR could only be process-switched, which meant that on most platforms the switching rate was approximately 1000 to 10,000 packets per second. This speed was not fast enough for many applications. Users that need PBR to occur at faster speeds can now implement PBR without slowing down the router.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-44

Configuring Policy-Based Routing Policy-Based Routing Configuration Task List

Fast-switched PBR supports all of the match commands and most of the set commands, with the following restrictions:

The set ip default next-hop and set default interface commands are not supported. The set interface command is supported only over point-to-point links, unless a route cache entry exists using the same interface specified in the set interface command in the route map. Also, at the process level, the routing table is consulted to determine if the interface is on a reasonable path to the destination. During fast switching, the software does not make this check. Instead, if the packet matches, the software blindly forwards the packet to the specified interface.

PBR must be configured before you configure fast-switched PBR. Fast switching of PBR is disabled by default. To enable fast-switched PBR, use the following command in interface configuration mode: Command
Router(config-if)# ip route-cache policy

Purpose Enables fast switching of PBR.

To display the cache entries in the policy route cache, use the show ip cache policy command. To display which route map is associated with which interface, use the show ip policy command.

Enabling Local PBR

Packets that are generated by the router are not normally policy-routed. To enable local PBR for such packets, indicate which route map the router should use by using the following command in global configuration mode: Command
Router(config)# ip local policy route-map map-tag

Purpose Identifies the route map to use for local PBR.

All packets originating on the router will then be subject to local PBR. Use the show ip local policy command to display the route map used for local PBR, if one exists.

Enabling CEF-Switched PBR

Beginning in Cisco IOS Release 12.0, PBR is supported in the Cisco Express Forwarding (CEF) switching path. CEF-switched PBR has better performance than fast-switched PBR and, therefore, is the optimal way to perform PBR on a router. No special configuration is required to enable CEF-switched PBR. It is on by default as soon as you enable CEF and PBR on the router.

Note

The ip route-cache policy command is strictly for fast-switched PBR and, therefore, not required for CEF-switched PBR.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-45

Configuring Policy-Based Routing Policy-Based Routing Configuration Examples

Policy-Based Routing Configuration Examples

The following sections provide PBR configuration examples:

Equal Access Example Differing Next Hops Example

For information on how to configure policy-based routing, see the section Policy-Based Routing Configuration Task List in this chapter.

Equal Access Example

The following example provides two sources with equal access to two different service providers. Packets arriving on asynchronous interface 1 from the source 1.1.1.1 are sent to the router at 6.6.6.6 if the router has no explicit route for the destination of the packet. Packets arriving from the source 2.2.2.2 are sent to the router at 7.7.7.7 if the router has no explicit route for the destination of the packet. All other packets for which the router has no explicit route to the destination are discarded.
access-list 1 permit ip 1.1.1.1 access-list 2 permit ip 2.2.2.2 ! interface async 1 ip policy route-map equal-access ! route-map equal-access permit 10 match ip address 1 set ip default next-hop 6.6.6.6 route-map equal-access permit 20 match ip address 2 set ip default next-hop 7.7.7.7 route-map equal-access permit 30 set default interface null0

Differing Next Hops Example

The following example illustrates how to route traffic from different sources to different places (next hops), and how to set the Precedence bit in the IP header. Packets arriving from source 1.1.1.1 are sent to the next hop at 3.3.3.3 with the Precedence bit set to priority; packets arriving from source 2.2.2.2 are sent to the next hop at 3.3.3.5 with the Precedence bit set to critical.
access-list 1 permit ip 1.1.1.1 access-list 2 permit ip 2.2.2.2 ! interface ethernet 1 ip policy route-map Texas ! route-map Texas permit 10 match ip address 1 set ip precedence priority set ip next-hop 3.3.3.3 ! route-map Texas permit 20 match ip address 2 set ip precedence critical set ip next-hop 3.3.3.5

Cisco IOS Quality of Service Solutions Configuration Guide

QC-46

Configuring QoS Policy Propagation via Border Gateway Protocol

This chapter describes the tasks for configuring Policy Propagation via Border Gateway Protocol (BGP) on a router. For complete conceptual information about this feature, see the section QoS Policy Propagation via Border Gateway Protocol in the chapter Classification Overview in this book. For a complete description of the Policy Propagation via BGP commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index, or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter of this book.

Policy Propagation via BGP Configuration Task Overview

The Policy Propagation via BGP feature allows you to classify packets by IP precedence based on BGP community lists, BGP autonomous system paths, and access lists. After a packet has been classified, you can use other QoS features such as committed access rate (CAR) and Weighted Random Early Detection (WRED) to specify and enforce policies to fit your business model. To configure Policy Propagation via BGP, perform the following basic tasks:

Configure BGP and Cisco Express Forwarding (CEF) or distributed CEF (dCEF). To configure BGP, refer to the Cisco IOS IP Configuration Guide. To configure CEF and dCEF, refer to the Cisco IOS Switching Services Configuration Guide. Define the policy. Apply the policy through BGP. Configure the BGP community list, BGP autonomous system path, or access list and enable the policy on an interface. For information about this task, see the next section in this chapter. Enable CAR or WRED to use the policy. To enable CAR, see the chapter Configuring Committed Access Rate in this book. To configure WRED, see the chapter Configuring Weighted Random Early Detection in this book.

This chapter describes how to configure Policy Propagation based on BGP community list, BGP autonomous system path, or access list. It assumes you have already configured BGP and CEF or dCEF.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-47

Configuring QoS Policy Propagation via Border Gateway Protocol Policy Propagation via BGP Configuration Task List

Policy Propagation via BGP Configuration Task List

To configure Policy Propagation via BGP, perform the tasks described in the following sections. The tasks in the first three sections are required; the task in the remaining section is optional.

Configuring Policy Propagation Based on Community Lists (Required) Configuring Policy Propagation Based on the Autonomous System Path Attribute (Required) Configuring Policy Propagation Based on an Access List (Required) Monitoring Policy Propagation via BGP (Optional)

Note

For the Policy Propagation via BGP feature to work, you must enable BGP and CEF/dCEF on the router. Subinterfaces on an ATM interface that have the bgp-policy command enabled must use CEF mode because dCEF is not supported. dCEF uses the Versatile Interface Processor (VIP) rather than the Route Switch Processor (RSP) to perform forwarding functions. See the end of this chapter for the section Policy Propagation via BGP Configuration Examples.

Configuring Policy Propagation Based on Community Lists

This section describes how to configure Policy Propagation via BGP using community lists. The tasks listed in this section are required unless noted as optional. This section assumes you have already configured CEF/dCEF and BGP on your router. To configure the router to propagate the IP precedence based on the community lists, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# route-map route-map-name [permit | deny [sequence-number]] Router(config-route-map)# match community-list community-list-number [exact] Router(config-route-map)# set ip precedence [number | name]

Purpose Defines a route map to control redistribution and enters route-map configuration mode. Matches a BGP community list. Sets the IP Precedence field when the community list matches. You can specify either a precedence number or name. Enters router configuration mode. Modifies the metric and tag values when the IP routing table is updated with BGP learned routes. Creates a community list for BGP and controls access to it. Specifies the interfaces (or subinterface) and enters interface configuration mode. Classifies packets using IP Precedence. (Optional) Configures a new community format so that the community number is displayed in the short form.

Step 4 Step 5 Step 6

Router(config-router)# router bgp autonomous-system Router(config-router)# table-map route-map-name

Router(config-router)# ip community-list community-list-number {permit | deny} community-number Router(config-router)# interface interface-type interface-number Router(config-if)# bgp-policy ip-prec-map Router(config-if)# ip bgp-community new-format

Step 7 Step 8 Step 9

Cisco IOS Quality of Service Solutions Configuration Guide

QC-48

Configuring QoS Policy Propagation via Border Gateway Protocol Policy Propagation via BGP Configuration Task List

Configuring Policy Propagation Based on the Autonomous System Path Attribute

This section describes how to configure Policy Propagation via BGP based on the autonomous system path. This section assumes you have already configured CEF/dCEF and BGP on your router. To configure the router to propagate the IP precedence based on the autonomous system path attribute, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# route-map route-map-name [permit | deny [sequence-number]] Router(config-route-map)# match as-path path-list-number Router(config-route-map)# set ip precedence [number | name]

Purpose Defines a route map to control redistribution and enters route-map configuration mode. Matches a BGP autonomous system path access list. Sets the IP Precedence field when the autonomous system path matches. Specifies either a precedence number or name. Enters router configuration mode. Modifies the metric and tag values when the IP routing table is updated with BGP learned routes. Defines an autonomous system path access list.

Step 4 Step 5 Step 6

Router(config-route-map)# router bgp autonomous-system Router(config-router)# table-map route-map-name

Router(config-router)# ip as-path access-list access-list-number {permit | deny} as-regular-expression Router(config-router)# interface interface-type interface-number Router(config-if)# bgp-policy ip-prec-map

Step 7 Step 8

Specifies the interfaces (or subinterface) and enters interface configuration mode. Classifies packets using IP Precedence.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-49

Configuring QoS Policy Propagation via Border Gateway Protocol Policy Propagation via BGP Configuration Task List

Configuring Policy Propagation Based on an Access List

This section describes how to configure Policy Propagation via BGP based on an access list. This section assumes you have already configured CEF/dCEF and BGP on your router. To configure the router to propagate the IP Precedence based on an access list, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3 Step 4 Step 5
Router(config)# route-map route-map-name [permit | deny [sequence-number]] Router(config-route-map)# match ip address access-list-number Router(config-route-map)# set ip precedence [number | name]

Purpose Defines a route map to control redistribution and enters route-map configuration mode. Matches an access list. Sets the IP Precedence field when the autonomous system path matches. Enters router configuration mode. Modifies the metric and tag values when the IP routing table is updated with BGP learned routes. Defines an access list. Specifies the interfaces (or subinterface) and enters interface configuration mode. Classifies packets using IP Precedence.

Router(config-route-map)# router bgp autonomous-system Router(config-router)# table-map route-map-name

Step 6 Step 7 Step 8

Router(config-router)# access-list access-list-number {permit | deny} source Router(config-router)# interface interface-type interface-number Router(config-if)# bgp-policy ip-prec-map

Monitoring Policy Propagation via BGP

To monitor the Policy Propagation via BGP configuration, use the following commands in EXEC mode, as needed. The commands listed in this section are optional. Command
Router# show ip bgp

Purpose Displays entries in the BGP routing table, to verify that the correct community is set on the prefixes. Displays routes permitted by the BGP community list, to verify that the correct prefixes are selected. Displays entries in the Forwarding Information Base (FIB) table based on the IP address, to verify that CEF has the correct precedence value for the prefix. Displays information about the interface. Displays the current status of the routing table, to verify that the correct precedence values are set on the prefixes.

Router# show ip bgp community-list community-list-number

Router# show ip cef network

Router# show ip interface Router# show ip route prefix

Cisco IOS Quality of Service Solutions Configuration Guide

QC-50

Configuring QoS Policy Propagation via Border Gateway Protocol Policy Propagation via BGP Configuration Examples

Policy Propagation via BGP Configuration Examples

The following example shows how to create route maps to match access lists, BGP community lists, and BGP autonomous system paths, and apply IP precedence to routes learned from neighbors. For information on how to configure Policy Propagation via BGP, see the section Policy Propagation via BGP Configuration Task Overview in this chapter. In Figure 4, Router A learns routes from autonomous system 10 and autonomous system 60. QoS policy is applied to all packets that match the defined route maps. Any packets from Router A to autonomous system 10 or autonomous system 60 are sent the appropriate QoS policy, as the numbered steps indicate.
Figure 4 Router Learning Routes and Applying QoS Policy
2. Route arrives 3. QoS policy applied Cisco 10000 series Autonomous system 30 4. Packet sent with QoS policy Router B 1. Route announced Autonomous system 60
10737

Autonomous system 10

Router A Configuration
router bgp 30 table-map precedence-map neighbor 20.20.20.1 remote-as 10 neighbor 20.20.20.1 send-community neighbor 20.20.20.1 route-map precedence-map ! ip bgp-community new-format ! ! Match community 1 and set the IP Precedence route-map precedence-map permit 10 match community 1 set ip precedence priority ! ! Match community 2 and set the IP Precedence route-map precedence-map permit 20 match community 2 set ip precedence immediate ! ! Match community 3 and set the IP Precedence route-map precedence-map permit 30 match community 3 set ip precedence flash ! ! Match community 4 and set the IP Precedence route-map precedence-map permit 40 match community 4 set ip precedence flash-override ! ! Match community 5 and set the IP Precedence route-map precedence-map permit 50 match community 5 set ip precedence critical !

out

to priority

to immediate

to flash

to flash-override

to critical

Cisco IOS Quality of Service Solutions Configuration Guide

QC-51

Configuring QoS Policy Propagation via Border Gateway Protocol Policy Propagation via BGP Configuration Examples

! Match community 6 and set the IP Precedence to internet route-map precedence-map permit 60 match community 6 set ip precedence internet ! ! Match community 7 and set the IP Precedence to network route-map precedence-map permit 70 match community 7 set ip precedence network ! ! Match ip address access list 69 or match AS path 1 ! and set the IP Precedence to critical route-map precedence-map permit 75 match ip address 69 match as-path 1 set ip precedence critical ! ! For everything else, set the IP Precedence to routine route-map precedence-map permit 80 set ip precedence routine ! ! Define the community lists ip community-list 1 permit 60:1 ip community-list 2 permit 60:2 ip community-list 3 permit 60:3 ip community-list 4 permit 60:4 ip community-list 5 permit 60:5 ip community-list 6 permit 60:6 ip community-list 7 permit 60:7 ! ! Define the AS path ip as-path access-list 1 permit ^10_60 ! ! Define the access list access-list 69 permit 69.0.0.0

Router B Configuration
router bgp 10 neighbor 30.30.30.1 remote-as 30 neighbor 30.30.30.1 send-community neighbor 30.30.30.1 route-map send_community out ! ip bgp-community new-format ! ! Match prefix 10 and set community to 60:1 route-map send_community permit 10 match ip address 10 set community 60:1 ! ! Match prefix 20 and set community to 60:2 route-map send_community permit 20 match ip address 20 set community 60:2 ! ! Match prefix 30 and set community to 60:3 route-map send_community permit 30 match ip address 30 set community 60:3 ! ! Match prefix 40 and set community to 60:4 route-map send_community permit 40 match ip address 40 set community 60:4

Cisco IOS Quality of Service Solutions Configuration Guide

QC-52

Configuring QoS Policy Propagation via Border Gateway Protocol Policy Propagation via BGP Configuration Examples

! ! Match prefix 50 and set community to 60:5 route-map send_community permit 50 match ip address 50 set community 60:5 ! ! Match prefix 60 and set community to 60:6 route-map send_community permit 60 match ip address 60 set community 60:6 ! ! Match prefix 70 and set community to 60:7 route-map send_community permit 70 match ip address 70 set community 60:7 ! ! For all others, set community to 60:8 route-map send_community permit 80 set community 60:8 ! ! Define the access lists access-list 10 permit 61.0.0.0 access-list 20 permit 62.0.0.0 access-list 30 permit 63.0.0.0 access-list 40 permit 64.0.0.0 access-list 50 permit 65.0.0.0 access-list 60 permit 66.0.0.0 access-list 70 permit 67.0.0.0

Cisco IOS Quality of Service Solutions Configuration Guide

QC-53

Configuring QoS Policy Propagation via Border Gateway Protocol Policy Propagation via BGP Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-54

Configuring Committed Access Rate

This chapter describes the tasks for configuring committed access rate (CAR) and distributed CAR (DCAR). For complete conceptual information about these features, see the section Committed Access Rate in the Classification Overview chapter and the section Policing with CAR in the Policing and Shaping Overview chapter in this book. For a complete description of the CAR commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Note

CAR and DCAR can only be used with IP traffic. Non-IP traffic is not rate limited. CAR and DCAR can be configured on an interface or subinterface. However, CAR and DCAR are not supported on the Fast EtherChannel, tunnel, or PRI interfaces, nor on any interface that does not support Cisco Express Forwarding (CEF). CEF must be enabled on the interface before you configure CAR or DCAR.

Committed Access Rate Configuration Task List

The CAR and DCAR services limit the input or output transmission rate on an interface or subinterface based on a flexible set of criteria. CAR is often configured on interfaces at the edge of a network to limit traffic into or out of the network. CAR can rate limit traffic based on certain matching criteria, such as incoming interface, IP precedence, or IP access list. You configure the actions that CAR will take when traffic conforms to or exceeds the rate limit. You can set CAR rate policies that are associated with one of the following:

All IP traffic IP precedence

Cisco IOS Quality of Service Solutions Configuration Guide

QC-55

Configuring Committed Access Rate Committed Access Rate Configuration Task List

MAC address IP access list, both standard and extended. Matching to IP access lists is more processor-intensive than matching based on other criteria.

Each interface can have multiple CAR policies, corresponding to different types of traffic. For example, low priority traffic may be limited to a lower rate than high-priority traffic. With multiple rate policies, the router examines each policy in the order entered until the packet matches. If a match is not found, the default action is to send. The rate policies can be independent; each rate policy deals with a different type of traffic. Alternatively, rate policies can be cascading; a packet can be compared to multiple different rate policies in succession. You can configure up to 100 rate policies on a subinterface.

Note

Because of the linear search for the matching rate-limit statement, the CPU load increases with the number of rate policies. To configure CAR, perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.

Configuring CAR and DCAR for All IP Traffic (Required) Configuring CAR and DCAR Policies (Required) Configuring a Class-Based DCAR Policy (Optional) Monitoring CAR and DCAR (Optional)

See the end of this chapter for the section CAR and DCAR Configuration Examples.

Configuring CAR and DCAR for All IP Traffic

To configure CAR (or DCAR on Cisco 7000 series routers with RSP7000 or Cisco 7500 series routers with a VIP2-40 or greater interface processor) for all IP traffic, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# interface interface-type interface-number Router(config-if)# rate-limit {input | output} bps burst-normal burst-max conform-action action exceed-action action

Purpose Specifies the interface or subinterface. This command puts the router in interface configuration mode. Specifies a basic CAR policy for all IP traffic. See Table 7 for a description of conform and exceed action keywords.

Basic CAR and DCAR functionality requires that the following criteria be defined:

Packet direction, incoming or outgoing. An average rate, determined by a long-term average of the transmission rate. Traffic that falls under this rate will always conform. A normal burst size, which determines how large traffic bursts can be before some traffic is considered to exceed the rate limit. An excess burst size (Be). Traffic that falls between the normal burst size and the Excess Burst size exceeds the rate limit with a probability that increases as the burst size increases. CAR propagates bursts. It does no smoothing or shaping of traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-56

Configuring Committed Access Rate Committed Access Rate Configuration Task List

Conform and exceed actions are described in Table 7.

Table 7 Rate-Limit Command Action Keywords

Keyword continue drop set-prec-continue new-prec set-prec-transmit new-prec transmit

Description Evaluates the next rate-limit command. Drops the packet. Sets the IP Precedence and evaluates the next rate-limit command. Sets the IP Precedence and sends the packet. Sends the packet.

See the sections Configuring CAR and DCAR Policies and Configuring a Class-Based DCAR Policy to understand how to configure other CAR and DCAR policy options. See the sections Subrate IP Services Example and Input and Output Rate Limiting on an Interface Example for examples of how to configure CAR for all IP traffic.

Configuring CAR and DCAR Policies

To configure CAR (or DCAR on Cisco 7000 series routers with the RSP7000 or Cisco 7500 series routers with a VIP2-40 or greater interface processor), use the following commands beginning in interface configuration mode. The tasks listed in this section are required unless noted as optional. Command
Step 1 Step 2
Router(config-if)# interface interface-type interface-number Router(config-if)# rate-limit {input | output} [access-group [rate-limit] acl-index] bps burst-normal burst-max conform-action action exceed-action action Router(config-if)# access-list rate-limit acl-index {precedence | mac-address | mask prec-mask} Router(config-if)# access-list acl-index {deny | permit} source [source-wildcard]

Purpose Specifies the interface or subinterface. This command puts the router in interface configuration mode. Specifies the rate policy for each particular class of traffic. See Table 7 for a description of the rate-limit command action keywords. Repeat this command for each different class of traffic. (Optional) Specifies a rate-limited access list. Repeat this command if you wish to specify a new access list. (Optional) Specifies a standard or extended access list. Repeat this command to further configure the access list or specify a new access list.

Step 3 Step 4

or
Router(config-if)# access-list acl-index {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence][tos tos] [log]

Cisco IOS Quality of Service Solutions Configuration Guide

QC-57

Configuring Committed Access Rate Committed Access Rate Configuration Task List

The following sections describe requirements for specific policies.

IP Precedence or MAC Address

Use the access-list rate-limit command to classify packets using either IP Precedence or MAC addresses. You can then apply CAR policies using the rate-limit command to individual rate-limited access lists. Packets with different IP precedences or MAC addresses are treated differently by the CAR service. See the section Rate Limiting in an IXP Example for an example of how to configure a CAR policy using MAC addresses.

IP Access List
Use the access-list command to define CAR policy based on an access list. The acl-index argument is an access list number. Use a number from 1 to 99 to classify packets by precedence or precedence mask. Use a number from 100 to 199 to classify by MAC address.

Note

If an access list is not present, the rate-limit command will act as if no access list is defined and all traffic will be rate limited accordingly. See the section Rate Limiting by Access List Example for an example of how to configure a CAR policy using IP access lists.

Configuring a Class-Based DCAR Policy

When you configure DCAR on Cisco 7000 series routers with RSP7000 or Cisco 7500 series routers with a VIP2-40 or greater interface processor, you can classify packets by group, to allow you to partition your network into multiple priority levels or classes of service. This classification is achieved by setting IP precedences based on different criteria for use by other QoS features such as Weighted Random Early Detection (WRED) or weighted fair queueing (WFQ). To configure a class-based DCAR policy, use the following commands beginning in interface configuration mode. The tasks listed in this section are required unless noted as optional. Command
Step 1
Router(config-if)# interface interface-type interface-number

Purpose Specifies the interface or subinterface. This command puts the router in interface configuration mode. Specifies the rate policy for each particular class of traffic. See Table 7 for a description of the rate-limit command action keywords. Repeat this command for each different class of traffic.

Step 2

Router(config-if)# rate-limit {input | output} [access-group [rate-limit] acl-index] bps burst-normal burst-max conform-action action exceed-action action

Cisco IOS Quality of Service Solutions Configuration Guide

QC-58

Configuring Committed Access Rate CAR and DCAR Configuration Examples

Command
Step 3 Step 4
Router(config-if)# random-detect precedence precedence min-threshold max-threshold mark-prob-denominator Router(config-if)# access-list acl-index {deny | permit} source [source-wildcard]

Purpose Configures WRED and specifies parameters for packets with specific IP Precedence. (Optional) Specifies a standard or extended access list. Repeat this command to further configure the access list or specify a new access list.

or
Router(config-if)# access-list acl-index {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [log]

Monitoring CAR and DCAR

To monitor CAR and DCAR services in your network, use the following commands in EXEC mode, as needed: Command
Router# show access-lists

Purpose Displays the contents of current IP and rate-limited access lists. Displays information about rate-limited access lists. Displays information about an interface configured for CAR.

Router# show access-lists rate-limit [access-list-number] Router# show interfaces [interface-type interface-number] rate-limit

CAR and DCAR Configuration Examples

The following sections provide CAR and DCAR configuration examples:

Subrate IP Services Example Input and Output Rate Limiting on an Interface Example Rate Limiting in an IXP Example Rate Limiting by Access List Example

For information on how to configure CAR and DCAR, see the section Committed Access Rate Configuration Task List in this chapter.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-59

Configuring Committed Access Rate CAR and DCAR Configuration Examples

Subrate IP Services Example

The following example illustrates how to configure a basic CAR policy that allows all IP traffic. In the example, the network operator delivers a physical T3 link to the customer, but offers a less expensive 15 Mbps subrate service. The customer pays only for the subrate bandwidth, which can be upgraded with additional access bandwidth based on demand. The CAR policy limits the traffic rate available to the customer and delivered to the network to the agreed upon rate limit, plus the ability to temporarily burst over the limit.
interface hssi 0/0/0 rate-limit output 15000000 2812500 5625000 conform-action transmit exceed-action drop ip address 10.1.0.9 255.255.255.0

Input and Output Rate Limiting on an Interface Example

In this example, a customer is connected to an Internet service provider (ISP) by a T3 link. The ISP wants to rate limit transmissions from the customer to 15 Mbps of the 45 Mbps. In addition, the customer is allowed to send bursts of 2,812,500 bytes. All packets exceeding this limit are dropped. The following commands are configured on the High-Speed Serial Interface (HSSI) of the ISP connected to the customer:
interface Hssi0/0/0 description 45Mbps to R1 rate-limit input 15000000 2812500 2812500 conform-action transmit exceed-action drop ip address 200.200.14.250 255.255.255.252 rate-limit output 15000000 2812500 2812500 conform-action transmit exceed-action drop

The following sample output shows how to verify the configuration and monitor CAR statistics using the show interfaces rate-limit command:
Router# show interfaces hssi 0/0/0 rate-limit Hssi0/0/0 45Mbps to R1 Input matches: all traffic params: 15000000 bps, 2812500 limit, 2812500 extended limit conformed 8 packets, 428 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop last packet: 8680ms ago, current burst: 0 bytes last cleared 00:03:59 ago, conformed 0 bps, exceeded 0 bps Output matches: all traffic params: 15000000 bps, 2812500 limit, 2812500 extended limit conformed 0 packets, 0 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop last packet: 8680ms ago, current burst: 0 bytes last cleared 00:03:59 ago, conformed 0 bps, exceeded 0 bps

Rate Limiting in an IXP Example

The following example uses rate limiting to control traffic in an Internet Exchange Point (IXP). Because an IXP comprises many neighbors around an FDDI ring, MAC address rate-limited access lists are used to control traffic from a particular ISP. Traffic from one ISP (at MAC address 00e0.34b0.7777) is compared to a rate limit of 80 Mbps of the 100 Mbps available on the FDDI connection. Traffic that conforms to this rate is sent. Nonconforming traffic is dropped.
interface Fddi2/1/0

Cisco IOS Quality of Service Solutions Configuration Guide

QC-60

Configuring Committed Access Rate CAR and DCAR Configuration Examples

rate-limit input access-group rate-limit 100 80000000 64000 80000 conform-action transmit exceed-action drop ip address 200.200.6.1 255.255.255.0 ! access-list rate-limit 100 00e0.34b0.7777

The following sample output shows how to verify the configuration and monitor the CAR statistics using the show interfaces rate-limit command:
Router# show interfaces fddi2/1/0 rate-limit Fddi2/1/0 Input matches: access-group rate-limit 100 params: 800000000 bps, 64000 limit, 80000 extended limit conformed 0 packets, 0 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop last packet: 4737508ms ago, current burst: 0 bytes last cleared 01:05:47 ago, conformed 0 bps, exceeded 0 bps

Rate Limiting by Access List Example

The following example shows how CAR can be used to limit the rate by application to ensure capacity for other traffic including mission-critical applications:

All World Wide Web traffic is sent. However, the IP precedence for Web traffic that conforms to the first rate policy is set to 5. For nonconforming Web traffic, the IP precedence is set to 0 (best effort). File Transfer Protocol (FTP) traffic is sent with an IP precedence of 5 if it conforms to the second rate policy. If the FTP traffic exceeds the rate policy, it is dropped. Any remaining traffic is limited to 8 Mbps, with a normal burst size of 16,000 bytes and an Excess Burst size of 24,000 bytes. Traffic that conforms is sent with an IP precedence of 5. Traffic that does not conform is dropped.

Figure 5 illustrates the configuration. Notice that two access lists are created to classify the Web and FTP traffic so that they can be handled separately by CAR.
Figure 5 Rate Limiting by Access List

Router LEFT 10.1.0.9 S0 E0 144.254.32.1 HSSI

Router RIGHT 10.1.0.10 S0 E0 10.2.2.1 10.2.2.2

17191

144.254.32.101

255.255.255.0

255.255.255.0

Router LEFT Configuration

interface Hssi0/0/0 description 45Mbps to R2 rate-limit output access-group 101 20000000 24000 32000 conform-action set-prectransmit 5 exceed-action set-prec-transmit 0 rate-limit output access-group 102 10000000 24000 32000 conform-action set-prec-transmit 5 exceed-action drop rate-limit output 8000000 16000 24000 conform-action set-prec-transmit 5

Cisco IOS Quality of Service Solutions Configuration Guide

QC-61

Configuring Committed Access Rate CAR and DCAR Configuration Examples

exceed-action drop ip address 10.1.0.9 255.255.255.0 ! access-list 101 permit tcp any any eq www access-list 102 permit tcp any any eq ftp

The following sample output shows how to verify the configuration and monitor CAR statistics using the show interfaces rate-limit command:
Router# show interfaces hssi 0/0/0 rate-limit Hssi0/0/0 45Mbps to R2 Input matches: access-group 101 params: 20000000 bps, 24000 limit, 32000 extended limit conformed 3 packets, 189 bytes; action: set-prec-transmit 5 exceeded 0 packets, 0 bytes; action: set-prec-transmit 0 last packet: 309100ms ago, current burst: 0 bytes last cleared 00:08:00 ago, conformed 0 bps, exceeded 0 bps matches: access-group 102 params: 10000000 bps, 24000 limit, 32000 extended limit conformed 0 packets, 0 bytes; action: set-prec-transmit 5 exceeded 0 packets, 0 bytes; action: drop last packet: 19522612ms ago, current burst: 0 bytes last cleared 00:07:18 ago, conformed 0 bps, exceeded 0 bps matches: all traffic params: 8000000 bps, 16000 limit, 24000 extended limit conformed 5 packets, 315 bytes; action: set-prec-transmit 5 exceeded 0 packets, 0 bytes; action: drop last packet: 9632ms ago, current burst: 0 bytes last cleared 00:05:43 ago, conformed 0 bps, exceeded 0 bps

Cisco IOS Quality of Service Solutions Configuration Guide

QC-62

Configuring Class-Based Packet Marking

This chapter describes the tasks for configuring the Class-Based Packet Marking feature. For complete conceptual information, see the section Class-Based Packet Marking in the Classification Overview chapter in this book. For a complete description of the Class-Based Packet Marking commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Class-Based Packet Marking Configuration Task List

To configure the Class-Based Packet Marking feature, perform the tasks described in the following sections. Although all of the tasks in the sections are optional, you must either configure an IP Precedence value or an IP differentiated services code point (DSCP) value (the tasks in the first or second section).

Configuring an IP Precedence Value (Optional) Configuring an IP DSCP Value (Optional) Configuring a QoS Group Value (Optional) Configuring a Class of Service Value (Optional) Changing an ATM Cell Loss Priority Bit Setting (Optional) Verifying the Class-Based Packet Marking Feature (Optional)

This task list includes the instructions for configuring either an IP Precedence value or an IP DSCP value. However, other match criteria can be used used as well. For information about other match criteria, see the section Creating a Traffic Class in the chapter Configuring the Modular Quality of Service Command-Line Interface in this book. See the end of this chapter for the section Class-Based Packet Marking Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-63

Configuring Class-Based Packet Marking Class-Based Packet Marking Configuration Task List

Configuring an IP Precedence Value

To mark a packet by setting the IP Precedence bits in the ToS byte, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-name

Purpose Specifies the name of the service policy to configure. Specifies the name of a predefined class, which was defined with the class-map command, included in the service policy. Specifies the IP precedence of packets within a traffic class. The ip-precedence-value is in the range from 0 to 7.

Router(config-pmap)# class class-name

Step 3

Router(config-pmap-c)# set ip precedence ip-precedence-value

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Configuring an IP DSCP Value

To mark a packet by setting the IP DSCP value, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-name

Purpose Specifies the name of the service policy to configure. Specifies the name of a predefined class, which was defined with the class-map command, included in the service policy. Specifies the IP DSCP value of packets within a traffic class. The number is in the range from 0 to 63. Reserved keywords such as EF (expedited forwarding) and AF11 (assured forwarding class AF11) can be specified instead of numeric values. The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Router(config-pmap)# class class-name

Step 3

Router(config-pmap-c)# set ip dscp ip-dscp-value

Cisco IOS Quality of Service Solutions Configuration Guide

QC-64

Configuring Class-Based Packet Marking Class-Based Packet Marking Configuration Task List

Configuring a QoS Group Value

To associate a local QoS group value with a packet, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-name

Purpose Specifies the name of the service policy to configure. Specifies the name of a predefined class, which was defined with the class-map command, included in the service policy. Specifies a QoS group value to associate with the packet. The number is in the range from 0 to 99.

Router(config-pmap)# class class-name

Step 3

Router(config-pmap-c)# set qos-group qos-group-value

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Configuring a Class of Service Value

To mark a packet with a specific class of service (CoS) value, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-name

Purpose Specifies the name of the service policy to configure. Specifies the name of a predefined class, which was defined with the class-map command, included in the service policy. Specifies a CoS value or values to associate with the packet. The number is in the range from 0 to 7.

Router(config-pmap)# class class-name

Step 3

Router(config-pmap-c)# set cos cos-value

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Note

A service policy that contains the set cos command can only be attached as an output service policy. The set cos command cannot be applied to packets entering an interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-65

Configuring Class-Based Packet Marking Class-Based Packet Marking Configuration Task List

Changing an ATM Cell Loss Priority Bit Setting

To set the Cell Loss Priority (CLP) bit to 1 on all packets matching a specified class, use the following commands beginning in global configuration mode:
Command Step 1 Step 2 Step 3
Router(config)# policy-map policy-name Router(config-pmap)# class class-name

Purpose

Specifies the name of the policy map to configure. Specifies the name of a predefined class included in the service policy. Changes the ATM CLP bit setting for all packets matching the specified class from 0 to 1.

Router(config-pmap-c)# set atm-clp

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Verifying the Class-Based Packet Marking Feature

To verify the Class-Based Packet Marking feature, display the configuration of a policy map, and retrieve information regarding QoS packet marking features that are configured in policy-map configuration mode, use the following commands in EXEC mode, as needed: Command
Router# show policy-map Router# show policy-map policy-map-name Router# show policy-map interface

Purpose Displays all configured policy maps. Displays the user-specified policy map. Displays statistics and configurations of all input and output policies attached to an interface. Displays configuration and statistics of the input and output policies attached to a particular interface. Displays configuration and statistics of the input policy attached to an interface. Displays configuration and statistics of the output policy attached to an interface. Displays the configuration and statistics for the class name configured in the policy.

Router# show policy-map interface interface-spec

Router# show policy-map interface interface-spec [input]

Router# show policy-map interface interface-spec [output]

Router# show policy-map interface-spec [input | output] [class class-name]

Cisco IOS Quality of Service Solutions Configuration Guide

QC-66

Configuring Class-Based Packet Marking Class-Based Packet Marking Configuration Examples

Class-Based Packet Marking Configuration Examples

The following sections provide Class-Based Packet Marking configuration examples:

Configuring an IP Precedence Value Example Configuring an IP DSCP Value Example Configuring a QoS Group Value Example Configuring a Classifying CoS Values Example Changing the ATM CLP Value Example

For information on how to configure Class-Based Packet Marking, see the section Class-Based Packet Marking Configuration Task List in this chapter.

Configuring an IP Precedence Value Example

In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined classification policy through the use of the class command. This example assumes that a classification policy called class1 was previously configured. In the following example, the IP Precedence bit in the Type of Service (ToS) byte is set to 1:
Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# set ip precedence 1

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Configuring an IP DSCP Value Example

In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined classification policy through the use of the class command. This example assumes that a classification policy called class1 was previously configured. In the following example, the IP DSCP value in the ToS byte is set to 5:
Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# set ip dscp 5 Router(config-pmap-c)# class class2 Router(config-pmap-c)# set ip dscp ef

After you configure the settings shown for voice packets at the edge, all intermediate routers are configured to provide low latency treatment to the voice packets, as follows:
Router(config)# class-map voice Router(config-cmap)# match ip dscp ef Router(config)# policy qos-policy Router(config-pmap)# class voice Router(config-pmap-c)# priority 24

Cisco IOS Quality of Service Solutions Configuration Guide

QC-67

Configuring Class-Based Packet Marking Class-Based Packet Marking Configuration Examples

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Configuring a QoS Group Value Example

In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined classification policy through the use of the class command. This example assumes that a classification policy called class1 was previously configured. In the following example, the QoS group value is set to 4:
Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# set qos-group 4

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Configuring a Classifying CoS Values Example

In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined classification policy through the use of the class command. This example assumes that a classification policy called class1 was previously configured. In the following example, the CoS value is set to 5:
Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# set cos 5

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Changing the ATM CLP Value Example

In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined classification policy through the use of the class command. This example assumes that a classification policy called class1 was previously configured. In this example, all packets with IP Precedence values of 0 or 1 are sent with the CLP bit set to 1:
Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# set atm-clp

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-68

Configuring QoS for Virtual Private Networks

This chapter describes the tasks for configuring the QoS for Virtual Private Networks (VPNs) feature. For complete conceptual information, see the section QoS for Virtual Private Networks in the Classification Overview chapter in this book. For a complete description of the QoS for VPNs commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

QoS for VPNs Configuration Task List

To configure the QoS for VPNs feature, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Configuring QoS for VPNs (Required) Verifying QoS for VPNs (Optional) Monitoring and Maintaining QoS for VPNs (Optional)

See the end of this chapter for the section QoS for VPNs Configuration Examples.

Configuring QoS for VPNs

The QoS for VPNs feature, which is enabled by the qos pre-classify command, is restricted to tunnel and virtual template interfaces, and crypto map configuration submodes. For generic routing encapsulation (GRE) and IP in IP (IPIP) tunnel protocols, the qos pre-classify command is applied on the tunnel interface, making QoS for VPNs a configuration option on a per-tunnel basis. For Layer 2 Forwarding (L2F) and Layer 2 Tunneling Protocol (L2TP) protocols, the qos pre-classify command is applied on the virtual template interface. L2TP clients belonging to identical virtual private dial-up network (VPDN) groups inherit the preclassification setting. The qos pre-classify command can be configured on a per-VPDN tunnel basis.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-69

Configuring QoS for Virtual Private Networks QoS for VPNs Configuration Task List

For IPSec tunnels, the qos pre-classify command is applied on the crypto map, allowing configuration on a per-tunnel basis. QoS features on the physical interface carrying the crypto map are able to classify packets before encryption. To configure the QoS for VPNs feature on a tunnel or virtual interface basis, use the following commands beginning in global interface mode: Command
Step 1 Step 2
Router(config)# interface [tunnel-name | virtual-template-name] Router(config-if)# qos pre-classify

Purpose Enters interface configuration mode and specifies the tunnel or virtual interface to configure. Enables the QoS for VPNs feature.

To configure the QoS for VPNs feature on the crypto map configuration basis, use the following commands beginning in global configuration mode: Command
Step 1
Router(config)# crypto map [map-name]

Purpose Enters crypto map configuration mode and specifies the previously defined crypto map to configure. Enables the QoS for VPNs feature.

Step 2

Router(config-if)# qos pre-classify

Verifying QoS for VPNs

Use the show interfaces or show crypto-map commands to verify that the QoS for VPNs feature has been successfully enabled on your router.

Note

The show queue command output displays packet information, including whether the packet is preclassified. In a congested environment, using the show queue command might assist in evaluating the environment and reconfiguring your router.

Verifying QoS for VPNs with the show interfaces Command

To verify that the QoS for VPNs feature has been successfully enabled on an interface, use the show interfaces command. The following line in the output (which is italicized for emphasis in the example) verifies that the QoS for VPNs feature is successfully enabled.
Queuing Strategy: fifo (QOS pre-classification) Router# show interfaces Tunnel0 is up, line protocol is up Hardware is Tunnel Interface is unnumbered. Using address of Ethernet 3/2 (13.0.0.2) MTU 1476 bytes, BW 9 Kbit, DLY 500000usec, reliability 255/255. txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (10 sec) Tunnel source 13.0.0.2 (Ethernet 3/2), destination 13.0.0.1 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Checksumming of packets disabled, fast tunneling enabled

Cisco IOS Quality of Service Solutions Configuration Guide

QC-70

Configuring QoS for Virtual Private Networks QoS for VPNs Configuration Examples

Last input never, output 00:07:29, output hang never Last clearing of show interface counters 1d05h Queuing Strategy: fifo (QOS pre-classification)

Verifying QoS for VPNs with the show crypto map Command
To verify that the QoS for VPNs feature has been successfully enabled on a crypto map, use the show crypto map command. The following line in the output (which is italicized for emphasis in the example) verifies that the QoS for VPNs feature is successfully enabled.
QoS pre-classification Router# show crypto map Crypto Map testtag 10 ipsec-isakmp Peer = 13.0.0.1 Extended IP access list 102 access-list 102 permit gre host 13.0.0.2 host 13.0.0.1 Current peer:13.0.0.1 Security association lifetime: 4608000 kilobytes/86400 seconds PFS (Y/N): N Transform sets={ proposal1,} QoS pre-classification

Monitoring and Maintaining QoS for VPNs

To monitor and maintain the QoS for VPNs feature, use the following commands in user EXEC mode, as needed: Command
Router# show interfaces [tunnel-name | virtual-template-name]

Purpose Displays information regarding the tunnel or the virtual template, including the queueing strategy. Displays information regarding the crypto map. If the QoS for VPNs feature is enabled, a QoS preclassification line will appear in the command output.

Router# show crypto map [map-name]

QoS for VPNs Configuration Examples

The following section provides QoS for VPNs configuration examples:

Configuring QoS for VPNs for GRE and IPIP Tunnel Protocols Example Configuring QoS for VPNs for L2F and L2TP Tunnel Protocols Example Configuring QoS for VPNs for IPSec Tunnel Protocols Example

For information on how to configure QoS for VPNs, see the section QoS for VPNs Configuration Task List in this chapter.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-71

Configuring QoS for Virtual Private Networks QoS for VPNs Configuration Examples

Configuring QoS for VPNs for GRE and IPIP Tunnel Protocols Example
In the following example, tunnel0 is the tunnel name. The qos pre-classify command enables the QoS for VPNs feature on tunnel0.
Router(config)# interface tunnel0 Router(config-if)# qos pre-classify

Configuring QoS for VPNs for L2F and L2TP Tunnel Protocols Example
In the following example, virtual-template1 is the virtual-template name. The qos pre-classify command enables the QoS for VPNs feature on virtual-template1.
Router(config)# interface virtual-template1 Router(config-if)# qos pre-classify

Configuring QoS for VPNs for IPSec Tunnel Protocols Example

In the following example, secured-partner-X is the crypto map name. The qos pre-classify command enables the QoS for VPNs feature on secured-partner-X.
Router(config)# crypto map secured-partner-X Router(config-crypto-map)# qos pre-classify

Cisco IOS Quality of Service Solutions Configuration Guide

QC-72

Configuring Network-Based Application Recognition

This chapter describes the tasks for configuring the Network-Based Application Recognition (NBAR) feature. For complete conceptual information, see the section Network-Based Application Recognition in the Classification Overview chapter in this book. For a complete description of the NBAR commands mentioned in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

NBAR Configuration Task List

Your interface to NBAR is through the Modular QoS Command-Line Interface (Modular QoS CLI) feature. The Modular QoS CLI provides a model for QoS configuration under Cisco IOS software. The Modular QoS CLI provides a clean separation between the specification of a classification policy and the specification of other policies that act based on the results of the applied classification. Configuring a QoS policy typically requires the configuration of traffic classes, the configuration of policies that will be applied to those traffic classes, and the attaching of policies to interfaces using the following commands:

class-map policy-map service-policy

Use the class-map command to define one or more traffic classes by specifying the criteria by which traffic is classified. Use the policy-map command to define one or more QoS policies (such as shaping, policing, and so on) to apply to traffic defined by a class map. Use the service-policy command to attach a traffic to an interface on the router. For additional information on the Modular QoS CLI, see the Modular Quality of Service Command-Line Interface Overview chapter in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-73

Configuring Network-Based Application Recognition NBAR Configuration Task List

To configure NBAR, perform the tasks described in the following sections. The tasks in the first three sections are required; the tasks in the remaining two sections are optional.

Configuring a Traffic Class (Required) Configuring a Traffic Policy (Required) Attaching a Traffic Policy to an Interface (Required) Verifying Traffic Policy Configuration (Optional) Monitoring and Maintaining NBAR (Optional)

Note

You must enable Cisco Express Forwarding (CEF) on the router prior to configuring the NBAR feature. For information on how to enable CEF, refer to the Cisco IOS Switching Services Configuration Guide. See the end of this chapter for the section NBAR Configuration Example.

Configuring a Traffic Class

To configure a traffic class and the match criteria that will be used to identify traffic as belonging to that class, use the class-map global configuration command. For more information about match criteria, see the sectionCreating a Traffic Class in the chapter Configuring the Modular Quality of Service Command-Line Interface in this book. To define the match criteria, use the following commands beginning in global configuration mode. In the following procedure, all traffic matching a specified protocol will be classified as belonging to the traffic class. The traffic class will classify traffic while the traffic policy configuration will determine how to treat the traffic. For instance, if you wanted all FTP traffic to be marked with the QoS group value of 1, you would use the match protocol ftp command in class-map configuration mode, and use the set qos-group 1 command in policy-map class configuration mode (assuming the traffic policy uses the specified class). Therefore, the classification purpose (classifying FTP traffic) would be handled in the traffic class, while the QoS feature (marking the QoS group value to 1) would be handled in the traffic policy. Command
Step 1
Router(config)# class-map [match-all | match-any] class-name

Purpose Specifies the user-defined name of the class map. The match-all option specifies that all match criteria in the class map must be matched. The match-any option specifies that one or more match criteria must match. Specifies a protocol supported by NBAR as a matching criterion.

Step 2

Router(config-cmap)# match protocol protocol-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-74

Configuring Network-Based Application Recognition NBAR Configuration Task List

Configuring a Traffic Policy

To specify the QoS policies to apply to traffic classes defined by a traffic class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-name Router(config-pmap)# class class-name Router(config-pmap-c)#

Purpose Specifies the traffic policy name entered by the user. Specifies the name of a previously defined traffic class. Enters policy-map class configuration mode, a prerequisite for entering QoS policies.

Attaching a Traffic Policy to an Interface

To attach a traffic policy to an interface and to specify the direction in which the traffic policy should be applied (on either packets coming into the interface or packets leaving the interface), use the following commands in interface configuration mode, as needed:
.

Command
Router(config-if)# service-policy output policy-map-name

Purpose Specifies the name of the traffic policy to be attached where it can be applied to all packetes leaving the interface. Specifies the name of the traffic policy to be attached where it can be appliced to all packets entering the interface.

Router(config-if)# service-policy input policy-map-name

To detach a policy map from an interface, use the no service-policy [input | output] policy-map-name command.

Verifying Traffic Policy Configuration

To display the configuration of a traffic policy and its associated traffic classes, use the following commands in privileged EXEC mode, as needed: Command
Router# show class-map Router# show class-map class-name

Purpose Displays all traffic class information. Displays the traffic class information of the userspecified traffic class. Displays all configured policy maps. Displays the user-specified policy map. Displays statistics and configurations of all input and output policies attached to an interface. Displays configuration and statistics of the input and output policies attached to a particular interface.

Router# show policy-map Router# show policy-map policy-map-name Router# show policy-map interface

Router# show policy-map interface-spec

Cisco IOS Quality of Service Solutions Configuration Guide

QC-75

Configuring Network-Based Application Recognition NBAR Configuration Example

Command
Router# show policy-map interface-spec [input]

Purpose Displays configuration and statistics of the input policy attached to an interface. Displays configuration statistics of the output policy attached to an interface. Displays the configuration and statistics for the class name configured in the policy.

Router# show policy-map interface-spec [output]

Router# show policy-map interface-spec [input | output] class class-name

Monitoring and Maintaining NBAR

NBAR can determine which protocols and applications are currently running on a network. NBAR includes the Protocol Discovery feature that provides an easy way of discovering application protocols operating on an interface so that appropriate QoS policies can be developed and applied. With Protocol Discovery, you can discover any protocol traffic supported by NBAR and obtain statistics associated with that protocol. To monitor and maintain the NBAR feature, use the following commands in privileged EXEC mode, as needed: Command
Router# show ip nbar port-map [protocol-name]

Purpose Displays the TCP/User Datagram Protocol (UDP) port number(s) used by NBAR to classify a given protocol. Displays the statistics for all interfaces on which Protocol Discovery is enabled.

Router# show ip nbar protocol-discovery

NBAR Configuration Example

The following Configuring a Traffic Class with NBAR Example section provides an NBAR configuration example. For information on how to configure NBAR, see the section NBAR Configuration Task List in this chapter.

Configuring a Traffic Class with NBAR Example

In the following example, the class-map class1 command uses the NBAR classification of SQL*Net as its matching criterion:
Router(config)# class-map class1 Router(config-cmap)# match protocol sqlnet

Cisco IOS Quality of Service Solutions Configuration Guide

QC-76

Congestion Management

Congestion Management Overview

Congestion management features allow you to control congestion by determining the order in which packets are sent out an interface based on priorities assigned to those packets. Congestion management entails the creation of queues, assignment of packets to those queues based on the classification of the packet, and scheduling of the packets in a queue for transmission. The congestion management QoS feature offers four types of queueing protocols, each of which allows you to specify creation of a different number of queues, affording greater or lesser degrees of differentiation of traffic, and to specify the order in which that traffic is sent. During periods with light traffic, that is, when no congestion exists, packets are sent out the interface as soon as they arrive. During periods of transmit congestion at the outgoing interface, packets arrive faster than the interface can send them. If you use congestion management features, packets accumulating at an interface are queued until the interface is free to send them; they are then scheduled for transmission according to their assigned priority and the queueing mechanism configured for the interface. The router determines the order of packet transmission by controlling which packets are placed in which queue and how queues are serviced with respect to each other. This chapter discusses these four types of queueing, which constitute the congestion management QoS features:

FIFO (first-in, first-out). FIFO entails no concept of priority or classes of traffic. With FIFO, transmission of packets out the interface occurs in the order the packets arrive. Weighted fair queueing (WFQ). WFQ offers dynamic, fair queueing that divides bandwidth across queues of traffic based on weights. (WFQ ensures that all traffic is treated fairly, given its weight.) To understand how WFQ works, consider the queue for a series of File Transfer Protocol (FTP) packets as a queue for the collective and the queue for discrete interactive traffic packets as a queue for the individual. Given the weight of the queues, WFQ ensures that for all FTP packets sent as a collective an equal number of individual interactive traffic packets are sent.) Given this handling, WFQ ensures satisfactory response time to critical applications, such as interactive, transaction-based applications, that are intolerant of performance degradation. For serial interfaces at E1 (2.048 Mbps) and below, flow-based WFQ is used by default. When no other queueing strategies are configured, all other interfaces use FIFO by default. There are four types of WFQ:
Flow-based WFQ (WFQ) Distributed WFQ (DWFQ) Class-based WFQ (CBWFQ) Distributed class-based WFQ (DCBWFQ)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-79

Congestion Management Overview Why Use Congestion Management?

Custom queueing (CQ). With CQ, bandwidth is allocated proportionally for each different class of traffic. CQ allows you to specify the number of bytes or packets to be drawn from the queue, which is especially useful on slow interfaces. Priority queueing (PQ). With PQ, packets belonging to one priority class of traffic are sent before all lower priority traffic to ensure timely delivery of those packets.

Note

You can assign only one queueing mechanism type to an interface.

Note

A variety of queueing mechanisms can be configured using multilink, for example, Multichassis Multilink PPP (MMP). However, if only PPP is used on a tunneled interfacefor example, virtual private dialup network (VPND), PPP over Ethernet (PPPoE), or PPP over Frame Relay (PPPoFR)no queueing can be configured on the virtual interface.

Why Use Congestion Management?

Heterogeneous networks include many different protocols used by applications, giving rise to the need to prioritize traffic in order to satisfy time-critical applications while still addressing the needs of less time-dependent applications, such as file transfer. Different types of traffic sharing a data path through the network can interact with one another in ways that affect their application performance. If your network is designed to support different traffic types that share a single data path between routers, you should consider using congestion management techniques to ensure fairness of treatment across the various traffic types. Here are some broad factors to consider in determining whether to configure congestion management QoS:

Traffic prioritization is especially important for delay-sensitive, interactive transaction-based applicationsfor instance, desktop video conferencingthat require higher priority than do file transfer applications. However, use of WFQ ensures that all traffic is treated fairly, given its weight, and in a dynamic manner. For example, WFQ addresses the requirements of the interactive application without penalizing the FTP application. Prioritization is most effective on WAN links where the combination of bursty traffic and relatively lower data rates can cause temporary congestion. Depending on the average packet size, prioritization is most effective when applied to links at T1/E1 bandwidth speeds or lower. If users of applications running across your network notice poor response time, you should consider using congestion management features. Congestion management features are dynamic, tailoring themselves to the existing network conditions. However, consider that if a WAN link is constantly congested, traffic prioritization may not resolve the problem. Adding bandwidth might be the appropriate solution. If there is no congestion on the WAN link, there is no reason to implement traffic prioritization.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-80

Congestion Management Overview Deciding Which Queueing Policy to Use

The following list summarizes aspects you should consider in determining whether you should establish and implement a queueing policy for your network:

Determine if the WAN is congestedthat is, whether users of certain applications perceive a performance degradation. Determine your goals and objectives based on the mix of traffic you need to manage and your network topology and design. In identifying what you want to achieve, consider whether your goal is among the following:
To establish fair distribution of bandwidth allocation across all of the types of traffic you

identify.
To grant strict priority to traffic from special kinds of applications you servicefor example,

interactive multimedia applicationspossibly at the expense of less-critical traffic you also support.
To customize bandwidth allocation so that network resources are shared among all of the

applications you service, each having the specific bandwidth requirements you have identified.
To effectively configure queueing. You must analyze the types of traffic using the interface and

determine how to distinguish them. See the chapter Classification Overview in this book for a description of how packets are classified. After you assess your needs, review the available congestion management queueing mechanisms described in this chapter and determine which approach best addresses your requirements and goals.

Configure the interface for the kind of queueing strategy you have chosen, and observe the results.

Traffic patterns change over time, so you should repeat the analysis process described in the second bullet periodically, and adapt the queueing configuration accordingly. See the following section, Deciding Which Queueing Policy to Use, for elaboration of the differences among the various queueing mechanisms.

Deciding Which Queueing Policy to Use

This section looks briefly at some of the differences between the types of queueing and includes a table that compares the main queueing strategies. FIFO queueing performs no prioritization of data packets on user data traffic. It entails no concept of priority or classes of traffic. When FIFO is used, ill-behaved sources can consume available bandwidth, bursty sources can cause delays in time-sensitive or important traffic, and important traffic may be dropped because less important traffic fills the queue. Consider these differences in deciding whether to use CQ or PQ:

CQ guarantees some level of service to all traffic because you can allocate bandwidth to all classes of traffic. You can define the size of the queue by determining its configured packet-count capacity, thereby controlling bandwidth access. PQ guarantees strict priority in that it ensures that one type of traffic will be sent, possibly at the expense of all others. For PQ, a low priority queue can be detrimentally affected, and, in the worst case, never allowed to send its packets if a limited amount of bandwidth is available or if the transmission rate of critical traffic is high.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-81

Congestion Management Overview Deciding Which Queueing Policy to Use

In deciding whether to use WFQ or one of the other two queueing types, consider these differences among WFQ and PQ and CQ:

WFQ does not require configuration of access lists to determine the preferred traffic on a serial interface. Rather, the fair queue algorithm dynamically sorts traffic into messages that are part of a conversation. Low-volume, interactive traffic gets fair allocation of bandwidth with WFQ, as does high-volume traffic such as file transfers. Strict priority queueing can be accomplished with WFQ by using the IP RTP Priority, Frame Relay IP RTP Priority, low latency queueing (LLQ), distributed low latency queueing, low latency queueing for Frame Relay, or Frame Relay PVC Interface Priority Queueing features. Strict PQ allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued.

Table 8 compares the salient features of flow-based WFQ, CBWFQ and DCBWFQ, CQ, and PQ.
Table 8 Queueing Comparison

Flow-Based WFQ Number of Queues Kind of Service

CBWFQ/DCBWFQ

CQ 16 user queues

PQ 4 queues

Configurable number of One queue per class, up queues (256 user queues, to 64 classes by default)

Ensures fairness among all traffic flows based on weights Strict priority queueing is available through use of the IP RTP Priority or Frame Relay IP RTP Priority features

Provides class bandwidth guarantee for user-defined traffic classes Provides flow-based WFQ support for nonuser-defined traffic classes Strict priority queueing is available through use of the IP RTP Priority, Frame Relay IP RTP Priority, LLQ, Distributed LLQ, and LLQ for Frame Relay features

Round-robin service

High priority queues are serviced first Absolute prioritization; ensures critical traffic of highest priority through use of the Frame Relay PVC Interface Priority Queueing feature

Configuration No configuration required

Requires configuration

Requires configuration

Requires configuration

Cisco IOS Quality of Service Solutions Configuration Guide

QC-82

Congestion Management Overview FIFO Queueing

FIFO Queueing
In its simplest form, FIFO queueingalso known as first-come, first-served (FCFS) queueinginvolves buffering and forwarding of packets in the order of arrival. FIFO embodies no concept of priority or classes of traffic and consequently makes no decision about packet priority. There is only one queue, and all packets are treated equally. Packets are sent out an interface in the order in which they arrive. When FIFO is used, ill-behaved sources can consume all the bandwidth, bursty sources can cause delays in time-sensitive or important traffic, and important traffic can be dropped because less important traffic fills the queue. When no other queueing strategies are configured, all interfaces except serial interfaces at E1 (2.048 Mbps) and below use FIFO by default. (Serial interfaces at E1 and below use WFQ by default.) FIFO, which is the fastest method of queueing, is effective for large links that have little delay and minimal congestion. If your link has very little congestion, FIFO queueing may be the only queueing you need to use.

Weighted Fair Queueing

This section discusses the four types of WFQ described in the following sections:

Flow-Based Weighted Fair Queueing Distributed Weighted Fair Queueing Class-Based Weighted Fair Queueing Distributed Class-Based Weighted Fair Queueing

This section also discusses the six related features described in the following sections:

IP RTP Priority Frame Relay IP RTP Priority Frame Relay PVC Interface Priority Queueing Low Latency Queueing Distributed Low Latency Queueing Low Latency Queueing for Frame Relay

Table 9 summarizes the differences among WFQ, DWFQ, CBWFQ, and DCBWFQ.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-83

Congestion Management Overview Weighted Fair Queueing

Table 9

WFQ, DWFQ, CBWFQ, and DCBWFQ Comparison

WFQ Flow-based WFQ:

DWFQ Flow-based DWFQ:

CBWFQ Class-based WFQ:

DCBWFQ Class-based distributed WFQ:

Weighted, when packets are classified; for example, Resource Reservation Protocol (RSVP) Fair queued (FQ), when packets are not classified (for example, best-effort traffic)

FQ, not weighted

Weighted Bandwidth allocation can be specified for a specific class of traffic

Class-based DWFQ:

Weighted Bandwidth allocation can be specified for a specific class of traffic

Weighted QoS-group-based Type of Service (ToS)-based

Runs on standard Cisco IOS platforms

Runs on Versatile Interface Processor (VIP) (faster performance)

Runs on standard Cisco IOS Runs on VIP platforms (faster performance)

For DWFQ and DCBWFQ, all queueing is transacted by the VIP. On the VIP, all packets are sent directly out the interface. A Route Switch Processor (RSP) resides on the same platform as the VIP. The RSP handles all tasks associated with system maintenance and routing. The VIP and the RSP each handle some scheduling. The dual-processor support accounts for the faster speed of DWFQ and DCBWFQ over WFQ running on standard Cisco IOS platforms. For information on how to configure WFQ, DWFQ, CBWFQ, and DCBWFQ, see the chapter Configuring Weighted Fair Queueing in this book. For information on how to configure per-VC WFQ and CBWFQ, see the chapter Configuring IP to ATM Class of Service in this book.

Flow-Based Weighted Fair Queueing

WFQ is a dynamic scheduling method that provides fair bandwidth allocation to all network traffic. WFQ applies priority, or weights, to identified traffic to classify traffic into conversations and determine how much bandwidth each conversation is allowed relative to other conversations. WFQ is a flow-based algorithm that simultaneously schedules interactive traffic to the front of a queue to reduce response time and fairly shares the remaining bandwidth among high-bandwidth flows. In other words, WFQ allows you to give low-volume traffic, such as Telnet sessions, priority over high-volume traffic, such as FTP sessions. WFQ gives concurrent file transfers balanced use of link capacity; that is, when multiple file transfers occur, the transfers are given comparable bandwidth. Figure 6 shows how WFQ works.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-84

Congestion Management Overview Weighted Fair Queueing

Figure 6

Weighted Fair Queueing

Incoming packets
Classify

Transmit queue

Outgoing packets

Weighted fair scheduling

Configurable number of queues

Flow-based Queueing classification: buffer resources Source and destination address Protocol Session identifier (port/socket)

Weight determined by: Required QoS (IP Precedence, RSVP) Flow throughput inversely proportional Frame Relay FECN, BECN, DE (for Frame Relay traffic)

WFQ overcomes a serious limitation of FIFO queueing. When FIFO is in effect, traffic is sent in the order received without regard for bandwidth consumption or the associated delays. As a result, file transfers and other high-volume network applications often generate series of packets of associated data. These related packets are known as packet trains. Packet trains are groups of packets that tend to move together through the network. These packet trains can consume all available bandwidth, depriving other traffic of bandwidth. WFQ provides traffic priority management that dynamically sorts traffic into messages that make up a conversation. WFQ breaks up the train of packets within a conversation to ensure that bandwidth is shared fairly between individual conversations and that low-volume traffic is transferred in a timely fashion. WFQ classifies traffic into different flows based on packet header addressing, including such characteristics as source and destination network or MAC address, protocol, source and destination port and socket numbers of the session, Frame Relay data-link connection identifier (DLCI) value, and ToS value. There are two categories of flows: high-bandwidth sessions and low-bandwidth sessions. Low-bandwidth traffic has effective priority over high-bandwidth traffic, and high-bandwidth traffic shares the transmission service proportionally according to assigned weights. Low-bandwidth traffic streams, which comprise the majority of traffic, receive preferential service, allowing their entire offered loads to be sent in a timely fashion. High-volume traffic streams share the remaining capacity proportionally among themselves. WFQ places packets of the various conversations in the fair queues before transmission. The order of removal from the fair queues is determined by the virtual time of the delivery of the last bit of each arriving packet.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-85

16756

Congestion Management Overview Weighted Fair Queueing

New messages for high-bandwidth flows are discarded after the congestive-messages threshold has been met. However, low-bandwidth flows, which include control-message conversations, continue to enqueue data. As a result, the fair queue may occasionally contain more messages than are specified by the threshold number. WFQ can manage duplex data streams, such as those between pairs of applications, and simplex data streams such as voice or video. The WFQ algorithm also addresses the problem of round-trip delay variability. If multiple high-volume conversations are active, their transfer rates and interarrival periods are made much more predictable. WFQ greatly enhances algorithms such as Systems Network Architecture (SNA) Logical Link Control (LLC) and TCP congestion control and slow start features. Flow-based WFQ is used as the default queueing mode on most serial interfaces configured to run at E1 speeds (2.048 Mbps) or below. WFQ provides the solution for situations in which it is desirable to provide consistent response time to heavy and light network users alike without adding excessive bandwidth. WFQ automatically adapts to changing network traffic conditions.

Restrictions
WFQ is not supported with tunneling and encryption because these features modify the packet content information required by WFQ for classification. Although WFQ automatically adapts to changing network traffic conditions, it does not offer the degree of precision control over bandwidth allocation that CQ and CBWFQ offer.

WFQ and IP Precedence

WFQ is IP precedence-aware. It can detect higher priority packets marked with precedence by the IP Forwarder and can schedule them faster, providing superior response time for this traffic. Thus, as the precedence increases, WFQ allocates more bandwidth to the conversation during periods of congestion. WFQ assigns a weight to each flow, which determines the transmit order for queued packets. In this scheme, lower weights are served first. For standard Cisco IOS WFQ, the IP precedence serves as a divisor to this weighting factor. Like CQ, WFQ sends a certain number of bytes from each queue. With WFQ, each queue corresponds to a different flow. For each cycle through all flows, WFQ effectively sends a number of bytes equal to the precedence of the flow plus one. This number is only used as a ratio to determine how many bytes per packets to send. However, for the purposes of understanding WFQ, using this number as the byte count is sufficient. For instance, traffic with an IP Precedence value of 7 gets a lower weight than traffic with an IP Precedence value of 3, thus, the priority in transmit order. The weights are inversely proportional to the IP Precedence value. To determine the bandwidth allocation for each queue, divide the byte count for the flow by the total byte count for all flows. For example, if you have one flow at each precedence level, each flow will get precedence + 1 parts of the link: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 = 36 Thus, precedence 0 traffic will get 1/36 of the bandwidth, precedence 1 traffic will get 2/36, and precedence 7 traffic will get 8/36. However, if you have 18 precedence 1 flows and one of each of the rest, the total is now: 1 + 2(18) + 3 + 4 + 5 + 6 + 7 + 8 = 70

Cisco IOS Quality of Service Solutions Configuration Guide

QC-86

Congestion Management Overview Weighted Fair Queueing

Precedence 0 traffic will get 1/70, each of the precedence 1 flows will get 2/70, and so on. As flows are added or ended, the actual allocated bandwidth will continuously change.

WFQ and RSVP

RSVP uses WFQ to allocate buffer space and schedule packets, and to guarantee bandwidth for reserved flows. WFQ works with RSVP to help provide differentiated and guaranteed QoS services. RSVP is the Internet Engineering Task Force (IETF) Internet Standard (RFC 2205) protocol for allowing an application to dynamically reserve network bandwidth. RSVP enables applications to request a specific QoS for a data flow. The Cisco implementation allows RSVP to be initiated within the network using configured proxy RSVP. RSVP is the only standard signalling protocol designed to guarantee network bandwidth from end to end for IP networks. Hosts and routers use RSVP to deliver QoS requests to the routers along the paths of the data stream and to maintain router and host state to provide the requested service, usually bandwidth and latency. RSVP uses a mean data rate, the largest amount of data the router will keep in queue, and minimum QoS to determine bandwidth reservation. WFQ or Weighted Random Early Detection (WRED) acts as the preparer for RSVP, setting up the packet classification and scheduling required for the reserved flows. Using WFQ, RSVP can deliver an Integrated Services Guaranteed Service.

WFQ and Frame Relay

WFQ weights are affected by Frame Relay discard eligible (DE), forward explicit congestion notification (FECN), and backward explicit congestion notification (BECN) bits when traffic is switched by the Frame Relay switching module. Once congestion is flagged, the weights used by the algorithm are altered so that the conversation encountering the congestion sends less frequently.

Distributed Weighted Fair Queueing

DWFQ is a special high-speed version of WFQ that runs on the VIP. It is supported on the following routers with a VIP2-40 or greater interface processor:

Cisco 7000 series with RSP7000 Cisco 7500 series

A VIP2-50 interface processor is recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 card is required for OC-3 rates. To use DWFQ, distributed Cisco Express Forwarding (dCEF) switching must be enabled on the interface. For more information on CEF, refer to the Cisco IOS Switching Services Configuration Guide and the Cisco IOS Switching Services Command Reference.

Note

The VIP-distributed WFQ implementation differs from WFQ that runs on all other platforms.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-87

Congestion Management Overview Weighted Fair Queueing

There are two forms of distributed WFQ:

Flow-based. In this form, packets are classified by flow. Packets with the same source IP address, destination IP address, source TCP or User Datagram Protocol (UDP) port, destination TCP or UDP port, protocol, and ToS field belong to the same flow. (All non-IP packets are treated as flow 0.) Each flow corresponds to a separate output queue. When a packet is assigned to a flow, it is placed in the queue for that flow. During periods of congestion, DWFQ allocates an equal share of the bandwidth to each active queue. Flow-based DWFQ is also called fair queueing because all flows are equally weighted and allocated equal bandwidth. In the current implementation of DWFQ, weights are not assigned to flows. With DWFQ, well-behaved hosts are protected from ill-behaved hosts.

Class-based. In this form, packets are assigned to different queues based on their QoS group or the IP precedence in the ToS field. QoS groups allow you to customize your QoS policy. A QoS group is an internal classification of packets used by the router to determine how packets are treated by certain QoS features, such as DWFQ and committed access rate (CAR). Use a CAR policy or the QoS Policy Propagation via Border Gateway Protocol (BGP) feature to assign packets to QoS groups. If you want to classify packets based only on the two low-order IP Precedence bits, use ToS-based DWFQ. Specify a weight for each class. In periods of congestion, each group is allocated a percentage of the output bandwidth equal to the weight of the class. For example, if a class is assigned a weight of 50, packets from this class will be allocated at least 50 percent of the outgoing bandwidth during periods of congestion. When the interface is not congested, queues can use any available bandwidth.

The Drop Policy section describes the drop policy used by both forms.

Drop Policy
DWFQ keeps track of the number of packets in each queue and the total number of packets in all queues. When the total number of packets is below the aggregate limit, queues can buffer more packets than the individual queue limit. When the total number of packets reaches the aggregate limit, the interface starts enforcing the individual queue limits. Any new packets that arrive for a queue that has exceeded its individual queue limit are dropped. Packets that are already in the queue will not be dropped, even if the queue is over the individual limit. In some cases, the total number of packets in all queues put together may exceed the aggregate limit.

Restrictions
Use DWFQ with IP traffic. All non-IP traffic is treated as a single flow and, therefore, placed in the same queue. DWFQ has the following restrictions:

Can be configured on interfaces, but not subinterfaces. Is not supported with the ATM encapsulations AAL5-MUX and AAL5-NLPID. Is not supported on Fast EtherChannel, tunnel interfaces, or other logical (virtual) interfaces such as Multilink PPP (MLP). Cannot be configured on the same interface as RSP-based PQ, CQ, or WFQ.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-88

Congestion Management Overview Weighted Fair Queueing

Class-Based Weighted Fair Queueing

CBWFQ extends the standard WFQ functionality to provide support for user-defined traffic classes. For CBWFQ, you define traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class. A FIFO queue is reserved for each class, and traffic belonging to a class is directed to the queue for that class. Once a class has been defined according to its match criteria, you can assign it characteristics. To characterize a class, you assign it bandwidth, weight, and maximum packet limit. The bandwidth assigned to a class is the guaranteed bandwidth delivered to the class during congestion. To characterize a class, you also specify the queue limit for that class, which is the maximum number of packets allowed to accumulate in the queue for the class. Packets belonging to a class are subject to the bandwidth and queue limits that characterize the class. After a queue has reached its configured queue limit, enqueueing of additional packets to the class causes tail drop or packet drop to take effect, depending on how class policy is configured. Tail drop is used for CBWFQ classes unless you explicitly configure policy for a class to use WRED to drop packets as a means of avoiding congestion. Note that if you use WRED packet drop instead of tail drop for one or more classes comprising a policy map, you must ensure that WRED is not configured for the interface to which you attach that service policy. If a default class is configured with the bandwidth policy-map class configuration command, all unclassified traffic is put into a single FIFO queue and given treatment according to the configured bandwidth. If a default class is configured with the fair-queue command, all unclassified traffic is flow classified and given best-effort treatment. If no default class is configured, then by default the traffic that does not match any of the configured classes is flow classified and given best-effort treatment. Once a packet is classified, all of the standard mechanisms that can be used to differentiate service among the classes apply. Flow classification is standard WFQ treatment. That is, packets with the same source IP address, destination IP address, source TCP or UDP port, or destination TCP or UDP port are classified as belonging to the same flow. WFQ allocates an equal share of bandwidth to each flow. Flow-based WFQ is also called fair queueing because all flows are equally weighted. For CBWFQ, the weight specified for the class becomes the weight of each packet that meets the match criteria of the class. Packets that arrive at the output interface are classified according to the match criteria filters you define, then each one is assigned the appropriate weight. The weight for a packet belonging to a specific class is derived from the bandwidth you assigned to the class when you configured it; in this sense the weight for a class is user-configurable. After the weight for a packet is assigned, the packet is enqueued in the appropriate class queue. CBWFQ uses the weights assigned to the queued packets to ensure that the class queue is serviced fairly.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-89

Congestion Management Overview Weighted Fair Queueing

Configuring a class policythus, configuring CBWFQentails these three processes:

Defining traffic classes to specify the classification policy (class maps). This process determines how many types of packets are to be differentiated from one another.

Associating policiesthat is, class characteristicswith each traffic class (policy maps). This process entails configuration of policies to be applied to packets belonging to one of the classes previously defined through a class map. For this process, you configure a policy map that specifies the policy for each traffic class.

Attaching policies to interfaces (service policies). This process requires that you associate an existing policy map, or service policy, with an interface to apply the particular set of policies for the map to that interface.

CBWFQ Bandwidth Allocation

The sum of all bandwidth allocation on an interface cannot exceed 75 percent of the total available interface bandwidth. The remaining 25 percent is used for other overhead, including Layer 2 overhead, routing traffic, and best-effort traffic. Bandwidth for the CBWFQ class-default class, for instance, is taken from the remaining 25 percent. However, under aggressive circumstances in which you want to configure more than 75 percent of the interface bandwidth to classes, you can override the 75 percent maximum sum allocated to all classes or flows using the max-reserved-bandwidth command. If you want to override the default 75 percent, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic, and Layer 2 overhead. When ATM is used you must account for the fact that ATM cell tax overhead is not included. For example, consider the case where a class needs guaranteed bandwidth on an ATM permanent virtual circuit (PVC). Suppose the average packet size for the class is 256 bytes and the class needs 100 kbps (which translates to 49 packets per second) of guaranteed bandwidth. Each 256-byte packet would be split into six cells to be sent on a VC, giving a total of 6 * 53 = 318 bytes. In this case, the ATM cell tax overhead would be 62 bytes or 49 * 62 * 8 = 24.34 kbps. When configuring CBWFQ in this example, ensure that the sum of all the configured class bandwidths is less than the VC bandwidth by at least 24.34 kbps to ensure desired payload guarantee for the configured classes (in this example, there is only one class). If you have several classes, the sum of all the class overheads should be estimated and added to the sum of all the configured class bandwidths. This total should be less than the VC bandwidth to ensure the required payload guarantees.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-90

Congestion Management Overview Weighted Fair Queueing

Why Use CBWFQ?

Here are some general factors you should consider in determining whether you need to configure CBWFQ:

Bandwidth allocation. CBWFQ allows you to specify the exact amount of bandwidth to be allocated for a specific class of traffic. Taking into account available bandwidth on the interface, you can configure up to 64 classes and control distribution among them, which is not the case with flow-based WFQ. Flow-based WFQ applies weights to traffic to classify it into conversations and determine how much bandwidth each conversation is allowed relative to other conversations. For flow-based WFQ, these weights, and traffic classification, are dependent on and limited to the seven IP Precedence levels. Coarser granularity and scalability. CBWFQ allows you to define what constitutes a class based on criteria that exceed the confines of flow. CBWFQ allows you to use ACLs and protocols or input interface names to define how traffic will be classified, thereby providing coarser granularity. You need not maintain traffic classification on a flow basis. Moreover, you can configure up to 64 discrete classes in a service policy.

CBWFQ and RSVP

RSVP can be used in conjunction with CBWFQ. When both RSVP and CBWFQ are configured for an interface, RSVP and CBWFQ act independently, exhibiting the same behavior that they would if each were running alone. RSVP continues to work as it does when CBWFQ is not present, even in regard to bandwidth availability assessment and allocation.

Restrictions
Configuring CBWFQ on a physical interface is only possible if the interface is in the default queueing mode. Serial interfaces at E1 (2.048 Mbps) and below use WFQ by defaultother interfaces use FIFO by default. Enabling CBWFQ on a physical interface overrides the default interface queueing method. Enabling CBWFQ on an ATM PVC does not override the default queueing method. If you configure a class in a policy map to use WRED for packet drop instead of tail drop, you must ensure that WRED is not configured on the interface to which you intend to attach that service policy. Traffic shaping and policing are not currently supported with CBWFQ. CBWFQ is supported on variable bit rate (VBR) and available bit rate (ABR) ATM connections. It is not supported on unspecified bit rate (UBR) connections. CBWFQ is not supported on Ethernet subinterfaces.

Distributed Class-Based Weighted Fair Queueing

As explained earlier, WFQ offers dynamic, fair queueing that divides bandwidth across queues of traffic based on weights. WFQ ensures that all traffic is treated fairly, given its weight. For more information about WFQ, see the section Weighted Fair Queueing in this chapter. The DCBWFQ feature extends the standard WFQ functionality to provide support for user-defined traffic classes on the VIP. These user-defined traffic classes are configured in the Modular Quality of Service Command-Line Interface (Modular QoS CLI) feature. For information on how to configure QoS with the Modular QoS CLI, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-91

Congestion Management Overview Weighted Fair Queueing

The maximum number of packets allowed to accumulate in a traffic class queue is called the queue limit and is specified with the queue-limit command when you create a service policy with the policy-map command. Packets belonging to a traffic class are subject to the guaranteed bandwidth allocation and the queue limits that characterize the traffic class. After a queue has reached its configured queue limit, enqueuing of additional packets to the traffic class causes tail drop or WRED drop to take effect, depending on how the service policy is configured. (Tail drop is a means of avoiding congestion that treats all traffic equally and does not differentiate between classes of service. Queues fill during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full). Tail drop is used for DCBWFQ traffic classes unless you explicitly configure a service policy to use WRED to drop packets as a means of avoiding congestion. Note that if you use WRED packet drop instead of tail drop for one or more traffic classes making up a service policy, you must ensure that WRED is not configured for the interface to which you attach that service policy. For information on how to configure DCBWFQ, see the chapter Configuring Weighted Fair Queueing in this book.

RSVP Interaction with DCBWFQ

When RSVP and DCBWFQ are configured, RSVP and DCBWFQ act independently of one another. RSVP and DCBWFQ allocate bandwidth among their traffic classes and flows according to unallocated bandwidth available at the underlying point of congestion. When an RSVP flow is created, the VIP queueing system reserves the unit of bandwidth allocation in an RSVP queue, similar to the way a traffic class queue is allotted to a DCBWFQ traffic class. DCBWFQ traffic classes are unaffected by the RSVP flows.

Benefits
Bandwidth Allocation
DCBWFQ allows you to specify the amount of guaranteed bandwidth to be allocated for a traffic class. Taking into account available bandwidth on the interface, you can configure up to 64 traffic classes and control bandwidth allocation among them. If excess bandwidth is available, the excess bandwidth is divided among the traffic classes in proportion to their configured bandwidths. Flow-based WFQ allocates bandwidth equally among all flows.

Coarser Granularity and Scalability

DCBWFQ allows you to define what constitutes a traffic class based on criteria that exceed the confines of flow. DCBWFQ allows you to use ACLs and protocols or input interface names to define how traffic is classified, thereby providing coarser granularity. You need not maintain traffic classification on a flow basis. Moreover, you can configure up to 64 discrete traffic classes in a service policy.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-92

Congestion Management Overview Weighted Fair Queueing

Restrictions
Using the bandwidth Command on VIP Default Traffic Class
On a VIP, all traffic that does not match a user-defined traffic class is classified as part of the default traffic class. The implicit bandwidth allocated to the default traffic class on a VIP is equal to the link bandwidth minus all of the user-defined bandwidth given to the user-defined traffic classes (with the bandwidth command). At least 1 percent of the link bandwidth is always reserved for the default traffic class. Because the bandwidth of the default traffic class for a VIP is implicit (the default traffic class receives all remaining bandwidth not given to the user-defined traffic classes), the bandwidth command cannot be used with the default traffic class when you configure a VIP.

Using the match protocol Command on a VIP

Do not use the match protocol command to create a traffic class with a non-IP protocol as a match criterion. The VIP does not support matching of non-IP protocols.

Prerequisites
WFQ
Attaching a service policy to an interface disables WFQ on that interface if WFQ is configured for the interface. For this reason, you should ensure that WFQ is not enabled on such an interface. For information on WFQ, see the chapter Configuring Weighted Fair Queueing in this book.

ACLs
You can specify a numbered access list as the match criterion for any traffic class that you create. For this reason, you should know how to configure access lists.

Modular QoS CLI

You can configure DCBWFQ using the Modular QoS CLI. For information on configuring QoS features with the Modular QoS CLI, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

IP RTP Priority
The IP RTP Priority feature provides a strict priority queueing scheme for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the ip rtp priority command. The result is that voice is serviced as strict priority in preference to other nonvoice traffic.

Note

Although this section focuses mainly on voice traffic, IP RTP Priority is useful for any RTP traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-93

Congestion Management Overview Weighted Fair Queueing

The IP RTP Priority feature extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of UDP/RTP ports whose traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and before packets in other queues are dequeued. We recommend that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations. The IP RTP Priority feature does not require that you know the port of a voice call. Rather, the feature gives you the ability to identify a range of ports whose traffic is put into the priority queue. Moreover, you can specify the entire voice port range16384 to 32767to ensure that all voice traffic is given strict priority service. IP RTP Priority is especially useful on links whose speed is less than 1.544 Mbps. This feature can be used in conjunction with either WFQ or CBWFQ on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first. Note the following conditions of the ip rtp priority command:

When used in conjunction with WFQ, the ip rtp priority command provides strict priority to voice, and WFQ scheduling is applied to the remaining queues. When used in conjunction with CBWFQ, the ip rtp priority command provides strict priority to voice. CBWFQ can be used to set up classes for other types of traffic (such as SNA) that needs dedicated bandwidth and needs to be treated better than best effort and not as strict priority; the nonvoice traffic is serviced fairly based on the weights assigned to the enqueued packets. CBWFQ can also support flow-based WFQ within the default CBWFQ class if so configured.

Because voice packets are small in size and the interface also can have large packets going out, the Link Fragmentation and Interleaving (LFI) feature should also be configured on lower speed interfaces. When you enable LFI, the large data packets are broken up so that the small voice packets can be interleaved between the data fragments that make up a large data packet. LFI prevents a voice packet from needing to wait until a large packet is sent. Instead, the voice packet can be sent in a shorter amount of time. For information on how to configure IP RTP Priority, see the chapter Configuring Weighted Fair Queueing in this book.

IP RTP Priority Bandwidth Allocation

If you want to understand its behavior and properly use the IP RTP Priority feature, it is important to consider its admission control and policing characteristics. When you use the ip rtp priority command to configure the priority queue for voice, you specify a strict bandwidth limitation. This amount of bandwidth is guaranteed to voice traffic enqueued in the priority queue. (This is the case whether you use the IP RTP Priority feature with CBWFQ or WFQ.)

Note

IP RTP Priority does not have per-call admission control. The admission control is on an aggregate basis. For example, if configured for 96 kbps, IP RTP Priority guarantees that 96 kbps is available for reservation. It does not ensure that only four calls of 24 kbps are admitted. A fifth call of 24 kbps could be admitted, but because the five calls will only get 96 kbps, the call quality will be deteriorated. (Each call would get 96/5 = 19.2 kbps.) In this example, it is the responsibility of the user to ensure that only four calls are placed at one time.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-94

Congestion Management Overview Weighted Fair Queueing

IP RTP Priority closely polices use of bandwidth for the priority queue, ensuring that the allocated amount is not exceeded in the event of congestion. In fact, IP RTP Priority polices the flow every second. IP RTP Priority prohibits transmission of additional packets once the allocated bandwidth is consumed. If it discovers that the configured amount of bandwidth is exceeded, IP RTP Priority drops packets, an event that is poorly tolerated by voice traffic. (Enable debugging to watch for this condition.) Close policing allows for fair treatment of other data packets enqueued in other CBWFQ or WFQ queues. To avoid packet drop, be certain to allocate to the priority queue the most optimum amount of bandwidth, taking into consideration the type of codec used and interface characteristics. IP RTP Priority will not allow traffic beyond the allocated amount. It is always safest to allocate to the priority queue slightly more than the known required amount of bandwidth. For example, suppose you allocated 24 kbps bandwidth, the standard amount required for voice transmission, to the priority queue. This allocation seems safe because transmission of voice packets occurs at a constant bit rate. However, because the network and the router or switch can use some of the bandwidth and introduce jitter and delay, allocating slightly more than the required amount of bandwidth (such as 25 kbps) ensures constancy and availability. The IP RTP Priority admission control policy takes RTP header compression into account. Therefore, while configuring the bandwidth parameter of the ip rtp priority command you only need to configure for the bandwidth of the compressed call. For example, if a G.729 voice call requires 24 kbps uncompressed bandwidth (not including Layer 2 payload) but only 12 kbps compressed bandwidth, you only need to configure a bandwidth of 12 kbps. You need to allocate enough bandwidth for all calls if there will be more than one call. The sum of all bandwidth allocation for voice and data flows on the interface cannot exceed 75 percent of the total available bandwidth. Bandwidth allocation for voice packets takes into account the payload plus the IP, RTP, and UDP headers, but again, not the Layer 2 header. Allowing 25 percent bandwidth for other overhead is conservative and safe. On a PPP link, for instance, overhead for Layer 2 headers assumes 4 kbps. The amount of configurable bandwidth for IP RTP Priority can be changed using the max-reserved-bandwidth command on the interface. If you know how much bandwidth is required for additional overhead on a link, under aggressive circumstances in which you want to give voice traffic as much bandwidth as possible, you can override the 75 percent maximum allocation for the bandwidth sum allocated to all classes or flows by using the max-reserved-bandwidth command. If you want to override the fixed amount of bandwidth, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic, and Layer 2 overhead. As another alternative, if the importance of voice traffic far exceeds that of data, you can allocate most of the 75 percent bandwidth used for flows and classes to the voice priority queue. Unused bandwidth at any given point will be made available to the other flows or classes.

Restrictions
Because the ip rtp priority command gives absolute priority over other traffic, it should be used with care. In the event of congestion, if the traffic exceeds the configured bandwidth, then all the excess traffic is dropped. The ip rtp reserve and ip rtp priority commands cannot be configured on the same interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-95

Congestion Management Overview Weighted Fair Queueing

Frame Relay IP RTP Priority

The Frame Relay IP RTP Priority feature provides a strict priority queueing scheme on a Frame Relay PVC for delay-sensitive data such as voice. Voice traffic can be identified by its RTP port numbers and classified into a priority queue configured by the frame-relay ip rtp priority command. The result of using this feature is that voice is serviced as strict priority in preference to other nonvoice traffic. This feature extends the functionality offered by the ip rtp priority command by supporting Frame Relay PVCs. This feature allows you to specify a range of UDP ports whose voice traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent before packets in other queues are dequeued. This process is performed on a per-PVC basis, rather than at the interface level. For information on how to configure Frame Relay IP RTP Priority, see the chapter Configuring Weighted Fair Queueing in this book.

Frame Relay PVC Interface Priority Queueing

The Frame Relay PVC Interface Priority Queueing (PIPQ) feature provides an interface-level priority queueing scheme in which prioritization is based on destination PVC rather than packet contents. For example, Frame Relay (FR) PIPQ allows you to configure a PVC transporting voice traffic to have absolute priority over a PVC transporting signalling traffic, and a PVC transporting signalling traffic to have absolute priority over a PVC transporting data. For information on how to configure Frame Relay PIPQ, see the chapter Configuring Weighted Fair Queueingin this book. For information about Frame Relay, refer to the Cisco IOS Wide-Area Networking Configuration Guide. Frame Relay PIPQ provides four levels of priority: high, medium, normal, and low. The Frame Relay packet is examined at the interface for the data-link connection identifier (DLCI) value. The packet is then sent to the correct priority queue based on the priority level configured for that DLCI.

Note

When using Frame Relay PIPQ, configure the network so that different types of traffic are transported on separate PVCs. Frame Relay PIPQ is not meant to be used when an individual PVC carries different traffic types that have different QoS requirements. You assign priority to a PVC within a Frame Relay map class. All PVCs using or inheriting that map class will be classed according to the configured priority. If a PVC does not have a map class associated with it, or if the map class associated with it does not have priority explicitly configured, then the packets on that PVC will be queued on the default normal priority queue. If you do not enable Frame Relay PIPQ on the interface using the frame-relay interface-queue priority command in interface configuration mode, configuring PVC priority within a map class will not be effective. At this time you have the option to also set the size (in maximum number of packets) of the four priority queues. Frame Relay PIPQ works with or without Frame Relay Traffic Shaping (FRTS) and FRF.12. The interface-level priority queueing takes the place of the FIFO queueing or dual FIFO queueing normally used by FRTS and FRF.12. PVC priority assigned within FR PIPQ takes precedence over FRF.12 priority, which means that all packets destined for the same PVC will be queued on the same interface queue whether they were fragmented or not.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-96

Congestion Management Overview Weighted Fair Queueing

Note

Although high priority PVCs most likely will transport only small packets of voice traffic, you may want to configure FRF.12 on these PVCs anyway to guard against any unexpectedly large packets.

Restrictions
The following restrictions apply to Frame Relay PIPQ:

It is not supported on loopback or tunnel interfaces, or interfaces that explicitly disallow priority queueing. It is not supported with hardware compression. It cannot be enabled on an interface that is already configured with queueing other than FIFO queueing. FR PIPQ can be enabled if WFQ is configured, as long as WFQ is the default interface queueing method.

Prerequisites
The following prerequisites apply to Frame Relay PIPQ:

PVCs should be configured to carry a single type of traffic. The network should be configured with adequate call admission control to prevent starvation of any of the priority queues.

Low Latency Queueing

The LLQ feature brings strict PQ to CBWFQ. Strict PQ allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued. Without LLQ, CBWFQ provides WFQ based on defined classes with no strict priority queue available for real-time traffic. CBWFQ allows you to define traffic classes and then assign characteristics to that class. For example, you can designate the minimum bandwidth delivered to the class during congestion. For CBWFQ, the weight for a packet belonging to a specific class is derived from the bandwidth you assigned to the class when you configured it. Therefore, the bandwidth assigned to the packets of a class determines the order in which packets are sent. All packets are serviced fairly based on weight; no class of packets may be granted strict priority. This scheme poses problems for voice traffic that is largely intolerant of delay, especially variation in delay. For voice traffic, variations in delay introduce irregularities of transmission manifesting as jitter in the heard conversation. LLQ provides strict priority queueing for CBWFQ, reducing jitter in voice conversations. Configured by the priority command, LLQ enables use of a single, strict priority queue within CBWFQ at the class level, allowing you to direct traffic belonging to a class to the CBWFQ strict priority queue. To enqueue class traffic to the strict priority queue, you specify the named class within a policy map and then configure the priority command for the class. (Classes to which the priority command is applied are considered priority classes.) Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, strict priority queue.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-97

Congestion Management Overview Weighted Fair Queueing

One of the ways in which the strict PQ used within CBWFQ differs from its use outside CBWFQ is in the parameters it takes. Outside CBWFQ, you can use the ip rtp priority command to specify the range of UDP ports whose voice traffic flows are to be given priority service. Using the priority command, you are no longer limited to a UDP port number to stipulate priority flows because you can configure the priority status for a class within CBWFQ. Instead, all of the valid match criteria used to specify traffic for a class now apply to priority traffic. These methods of specifying traffic for a class include matching on access lists, protocols, and input interfaces. Moreover, within an access list you can specify that traffic matches are allowed based on the IP differentiated services code point (DSCP) value that is set using the first six bits of the ToS byte in the IP header. Although it is possible to enqueue various types of real-time traffic to the strict priority queue, we strongly recommend that you direct only voice traffic to it because voice traffic is well-behaved, whereas other types of real-time traffic are not. Moreover, voice traffic requires that delay be nonvariable in order to avoid jitter. Real-time traffic such as video could introduce variation in delay, thereby thwarting the steadiness of delay required for successful voice traffic transmission. For information on how to configure LLQ, see the chapter Configuring Weighted Fair Queueing in this book.

LLQ Bandwidth Allocation

When you specify the priority command for a class, it takes a bandwidth argument that gives maximum bandwidth in kbps. You use this parameter to specify the maximum amount of bandwidth allocated for packets belonging to the class configured with the priority command. The bandwidth parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class. In the event of congestion, policing is used to drop packets when the bandwidth is exceeded. Voice traffic enqueued to the priority queue is UDP-based and therefore not adaptive to the early packet drop characteristic of WRED. Because WRED is ineffective, you cannot use the WRED random-detect command with the priority command. In addition, because policing is used to drop packets and a queue limit is not imposed, the queue-limit command cannot be used with the priority command. When congestion occurs, traffic destined for the priority queue is metered to ensure that the bandwidth allocation configured for the class to which the traffic belongs is not exceeded. Priority traffic metering has the following qualities:

It is much like the rate-limiting feature of CAR, except that priority traffic metering is only performed under congestion conditions. When the device is not congested, the priority class traffic is allowed to exceed its allocated bandwidth. When the device is congested, the priority class traffic above the allocated bandwidth is discarded. It is performed on a per-packet basis, and tokens are replenished as packets are sent. If not enough tokens are available to send the packet, it is dropped. It restrains priority traffic to its allocated bandwidth to ensure that nonpriority traffic, such as routing packets and other data, is not starved.

With metering, the classes are policed and rate-limited individually. That is, although a single policy map might contain four priority classes, all of which are enqueued in a single priority queue, they are each treated as separate flows with separate bandwidth allocations and constraints. It is important to note that because bandwidth for the priority class is specified as a parameter to the priority command, you cannot also configure the bandwidth policy-map class configuration command for a priority class. To do so is a configuration violation that would only introduce confusion in relation to the amount of bandwidth to allocate.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-98

Congestion Management Overview Weighted Fair Queueing

The bandwidth allocated for a priority queue always includes the Layer 2 encapsulation header. However, it does not include other headers, such as ATM cell tax overheads. When you calculate the amount of bandwidth to allocate for a given priority class, you must account for the fact that Layer 2 headers are included. When ATM is used, you must account for the fact that ATM cell tax overhead is not included. You must also allow bandwidth for the possibility of jitter introduced by routers in the voice path. Consider this case that uses ATM. Suppose a voice stream of 60 bytes emitting 50 packets per second is encoded using G.729. Prior to converting the voice stream to cells, the meter for the priority queue used for the voice stream assesses the length of the packet after the Layer 2 Logical Link Control (LLC) headers have been added. Given the 8-byte Layer 2 LLC header, the meter will take into account a 68-byte packet. Because ATM cells are a standard 53 bytes long, before the 68-byte packet is emitted on the line, it is divided into two 53-byte ATM cells. Thus, the bandwidth consumed by this flow is 106 bytes per packet. For this case, then, you must configure the bandwidth to be at least 27.2 kbps (68 * 50 * 8 = 27.2 kbps). However, recall that you must also allow for the ATM cell tax overhead, which is not accounted for by the configured bandwidth. In other words, the sum of the bandwidths for all classes must be less than the interface bandwidth by at least 15.2 kbps ([106 68] * 50 * 8 = 15.2 kbps). You should also remember to allow bandwidth for router-introduced jitter.

Note

The sum of all bandwidth allocation on an interface cannot exceed 75 percent of the total available interface bandwidth. However, under aggressive circumstances in which you want to configure more than 75 percent of the interface bandwidth to classes, you can override the 75 percent maximum sum allocated to all classes or flows using the max-reserved-bandwidth command. The max-reserved-bandwidth command is intended for use on main interfaces only; it has no effect on virtual circuits (VCs) or ATM permanent virtual circuits (PVCs).

LLQ with IP RTP Priority

LLQ and IP RTP Priority can be configured at the same time, but IP RTP Priority takes precedence. To demonstrate how they work together, consider the following configuration:
policy-map llqpolicy class voice priority 50 ip rtp priority 16384 20000 40 service-policy output llqpolicy

In this example, packets that match the 16384 to 20000 port range will be given priority with 40 kbps bandwidth; packets that match the voice class will be given priority with 50 kbps bandwidth. In the event of congestion, packets that match the 16384 to 20000 port range will receive no more than 40 kbps of bandwidth, and packets that match the voice class will receive no more than 50 kbps of bandwidth. If packets match both criteria (ports 16384 to 20000 and class voice), IP RTP Priority takes precedence. In this example, the packets will be considered to match the 16384 to 20000 port range and will be accounted for in the 40 kbps bandwidth.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-99

Congestion Management Overview Weighted Fair Queueing

LLQ and Committed Burst Size

The functionality of LLQ has been extended to allow you to specify the Committed Burst (Bc) size in LLQ. This functionality is provided with the Configuring Burst Size in Low Latency Queueing feature. With this new functionality, the network can now accommodate temporary bursts of traffic and handle network traffic more efficiently.

Note

The default Bc size used by LLQ is intended to handle voice-like non-bursty traffic. If you want to configure LLQ to handle the traffic of non-voice applications, you may need to increase the burst size accordingly, based on the application in use on your network.

LLQ and per-VC Hold Queue Support for ATM Adapters

By default, the queueing mechanism in use determines the size of the hold queue, and, therefore, the number of packets contained in the queue. The Configurable per-VC Hold Queue Support for ATM Adapters feature allows you to expand the default hold queue size and change (or vary) the number of packets the queue can contain. With this new feature, the hold queue can contain a maximum of 1024 packets. This feature allows you to specify the number of packets contained in the hold queue, per VC, on ATM adapters that support per-VC queueing.

Note

This feature is supported only on the Cisco 7200 series routers, and on Cisco 2600 and 3600 series adapters that support per-VC queueing. For related information about per-VC and ATM configurations, see the chapters IP to ATM Class of Service Overview and Configuring IP to ATM Class of Service later in this book.

Why Use LLQ?

Here are some general factors you should consider in determining whether you need to configure LLQ:

LLQ provides strict priority service on ATM VCs and serial interfaces. (The IP RTP Priority feature allows priority queueing only on interfaces.) LLQ is not limited to UDP port numbers. Because you can configure the priority status for a class within CBWFQ, you are no longer limited to UDP port numbers to stipulate priority flows. Instead, all of the valid match criteria used to specify traffic for a class now apply to priority traffic. By configuring the maximum amount of bandwidth allocated for packets belonging to a class, you can avoid starving nonpriority traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-100

Congestion Management Overview Weighted Fair Queueing

Restrictions
The following restrictions apply to LLQ:

If you use access lists to configure matching port numbers, this feature provides priority matching for all port numbers, both odd and even. Because voice typically exists on even port numbers, and control packets are generated on odd port numbers, control packets are also given priority when using this feature. On very slow links, giving priority to both voice and control packets may produce degraded voice quality. Therefore, if you are only assigning priority based on port numbers, you should use the ip rtp priority command instead of the priority command. (The ip rtp priority command provides priority only for even port numbers.) The random-detect command, queue-limit command, and bandwidth policy-map class configuration command cannot be used while the priority command is configured. The priority command can be configured in multiple classes, but it should only be used for voice-like, constant bit rate (CBR) traffic.

Distributed Low Latency Queueing

The Distributed LLQ feature provides the ability to specify low latency behavior for a traffic class on a VIP-based Cisco 7500 series router. LLQ allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued. The Distributed LLQ feature also introduces the ability to limit the depth of a device transmission ring. Before the introduction of Distributed LLQ, the maximum transmission ring depth was not a user-configurable parameter. Therefore, particles could accumulate on a transmission ring without limitation, which could result in unavoidable high latencies. The Distributed LLQ feature allows users to limit the number of particles that may exist on a transmission ring, effectively lowering the latency incurred by packets sitting on that transmission ring. The priority command is used to allow delay-sensitive data to be dequeued and sent first. LLQ enables use of a single priority queue within which individual classes of traffic can be placed. To enqueue class traffic to the priority queue, you configure the priority command for the class after you specify the named class within a policy map. The amount of bandwidth available for the priority queue can be specified either as a set amount of bandwidth in kbps or as a percentage of all available bandwidth (beginning in Cisco IOS Release 12.1(5)T). Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, priority queue. The tx-ring-limit command allows the user to specify the number of allowable particles on a transmission ring, effectively lowering the latency for that transmission ring. One packet can contain multiple particles, and a typical particle is 512 bytes in size (the size depends on the interface types. For some interface types, a typical particle size is 256 bytes.) These particles can no longer accumulate on a transmission ring and cause unavoidable high latencies. Distributed LLQ is supported on the Cisco 7500 RSP series router with a VIP. This feature also supports the Class-Based Quality of Service MIB. For information on how to configure Distributed LLQ, see the chapter Configuring Weighted Fair Queueing in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-101

Congestion Management Overview Weighted Fair Queueing

Guaranteeing Bandwidth with the priority Command

One method of using the priority command for a traffic class is to specify a bandwidth argument that gives the maximum bandwidth in kpbs. The other method of using the priority command for a traffic class, which was introduced in Cisco IOS Release 12.1(5)T, is to specify a percentage of available bandwidth to be reserved for the priority queue. The bandwidth value or percentage guarantees the configured bandwidth to the priority class under worst-case congestion scenarios. If excess bandwidth is available, the priority class will be allowed to utilize the bandwidth. If no excess bandwidth is available, the priority traffic will be constrained to the configured rate via packet drops. Each individual class that is configured to a bandwidth value will have its traffic constrained to its individual rate. When a class is constrained to its individual rate, the traffic is permitted a certain amount of burstiness because of the token bucket mechanism policing the stream. This amount of burstiness is controlled by the optional burst parameter in the priority command (this burstiness cannot be specified when specifying a priority queue based on a percentage of available bandwidth). The burst parameter specifies, in bytes, the amount of traffic allowed to pass through the token bucket as a one-time burst in excess of the token bucket drop parameters. The default burst value is 200 milliseconds of traffic at the configured token bucket drop parameters. It is important to note that because bandwidth for the priority class is specified as a parameter to the priority command, you cannot also configure the bandwidth command for a priority class. To do so is a configuration violation that introduces confusion in relation to the amount of bandwidth to allocate. The bandwidth allocated for a priority queue always includes the Layer 2 encapsulation header. However, it does not include other headers, such as ATM cell tax overheads. When you calculate the amount of bandwidth to allocate for a given priority class, you must account for the fact that the Layer 2 headers are included. When ATM is used, you must account for the fact that ATM cell tax overhead is not included. You must also allow bandwidth for the possibility of jitter introduced by routers in the voice path. Consider this case that uses ATM: Suppose a voice stream of 60 bytes emitting 50 packets per second is encoded using G.729. Prior to converting the voice stream to cells, the meter for the priority queue used for the voice stream assesses the length of the packet after the Layer logical link control (LLC) headers have been added. Given the 8-byte Layer 2 LLC header, the meter will take into account a 68-byte packet. Because ATM cells are a standard 53 bytes long, before the 68-kbps packet is emitted on the line, it is divided into two 53-byte ATM cells. Thus, the bandwidth consumed by this flow is 106 bytes per packet. For this case, then, you must configure the bandwidth to be at least 27.2 kbps (68 * 50 * 8 = 27.2 kbps). However, recall that you must also allow for the ATM cell tax overhead, which is not accounted for by the configured bandwidth. In other words, the sum of the bandwidths for all classes must be less than the interface bandwidth by at least 15.2 kbps ([106 68] * 50 * 8 = 15.2 kbps). You should also remember to allow bandwidth for router-introduced jitter.

Benefits
Provides Priority Service on ATM VCs and Serial Interface
The PQ scheme allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued. This feature provides PQ on ATM VCs.

Admission Control
By configuring the maximum amount of bandwidth allocated for packets belonging to a class, you can avoid starving nonpriority traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-102

Congestion Management Overview Weighted Fair Queueing

Limiting Particles on a Transmission Ring

The Distributed LLQ feature also introduces particle limiting for transmission rings. Before the introduction of Distributed LLQ, the transmission ring depth was not user-configurable. Therefore, a user could experience unavoidable high latencies on a transmission ring. The Distributed LLQ feature allows users to limit the number of particles on a transmission ring to a predefined limit, effectively lowering the latency on transmission rings.

Restrictions
The following restrictions apply to the Distributed LLQ feature:

If you use access lists to configure matching port numbers, this feature provides priority matching for all port numbers. Because voice typically exists on even port numbers, and control packets are generated on odd port numbers, control packets are also given priority when using this feature. On very slow links, giving priority to both voice and control packets may produce degraded voice quality. The priority command can be used in conjunction with the set command. The priority command cannot be used in conjunction with any other command, including the random-detect, queue-limit, and bandwidth commands. The priority command can be configured in multiple traffic classes. If the traffic is not CBR traffic, you must configure a large enough bandwidth-kbps parameter to absorb the data bursts. Because 1 percent of the available bandwidth is reserved for the default traffic class, the sum of the percentage for the bandwidth percent and priority percent command reservations cannot exceed 99 percent. Priority queues can be reserved by either size or percentage values, but not both, in the same policy map. Therefore, if the priority command is used without the percent option in a policy map, the bandwidth command, if used, must also be used without the percent option, and vice versa. Similarly, if the priority percent command is used in a policy map, the bandwidth percent command must be used to specify bandwidth allocation for the class, and vice versa. The priority and priority percent commands also cannot be used in the same policy map. The bandwidth and priority commands cannot be used in the same class map. These commands can be used together in the same policy map, however. The following commands cannot be used in the same class or policy map with the priority command:
priority percent bandwidth percent

The following commands cannot be used in the same class or policy map with the priority percentage command:
priority (without the percent option) bandwidth (without the percent option)

The tx-ring-limit command can only affect a VBR VC on a PA-A3 port adapter. The tx-ring-limit command does not affect UBR VCs.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-103

Congestion Management Overview Weighted Fair Queueing

Prerequisites
To use this feature, you should be familiar with the following features:

ACLs ATM PVCs Bandwidth management CBWFQ LFI Virtual templates and virtual access interfaces

Low Latency Queueing for Frame Relay

LLQ for Frame Relay provides a strict priority queue for voice traffic and weighted fair queues for other classes of traffic. With this feature, LLQ is available at the Frame Relay VC level when FRTS is configured. LLQ, also called PQ/CBWFQ, is a superset of and more flexible than previous Frame Relay QoS offerings, in particular RTP prioritization and PQ/WFQ. With RTP prioritization and PQ/WFQ, traffic that matches a specified UDP/RTP port range is considered high priority and allocated to the priority queue (PQ). With LLQ for Frame Relay, you set up classes of traffic according to protocol, interface, or access lists, and then define policy maps to establish how the classes are handled in the priority queue and weighted fair queues. Queues are set up on a per-PVC basis: each PVC has a PQ and an assigned number of fair queues. The fair queues are assigned weights proportional to the bandwidth requirements of each class; a class requiring twice the bandwidth of another will have half the weight. Oversubscription of the bandwidth is not permitted. The CLI will reject a change of configuration that would cause the total bandwidth to be exceeded. This functionality differs from that of WFQ, in which flows are assigned a weight based on IP precedence. WFQ allows higher precedence traffic to obtain proportionately more of the bandwidth, but the more flows there are, the less bandwidth is available to each flow. The PQ is policed to ensure that the fair queues are not starved of bandwidth. When you configure the PQ, you specify in kbps the maximum amount of bandwidth available to that queue. Packets that exceed that maximum are dropped. There is no policing of the fair queues. LLQ for Frame Relay is configured using a combination of class-map, policy-map , and Frame Relay map class commands. The class-map command defines traffic classes according to protocol, interface, or access list. The policy-map command defines how each class is treated in the queueing system according to bandwidth, priority, queue limit, or WRED. The service-policy output map class command attaches a policy map to a Frame Relay VC. Policies not directly related to LLQfor example, traffic shaping, setting IP precedence, and policingare not supported by the class-map and policy-map commands for Frame Relay VCs. You must use other configuration mechanisms, such as map class commands, to configure these policies. For information on how to configure LLQ for Frame Relay, see the chapter Configuring Weighted Fair Queueing in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-104

Congestion Management Overview Weighted Fair Queueing

Restrictions
Only the following class map and policy map commands are supported:

The match class-map configuration command The priority, bandwidth, queue-limit, random-detect, and fair-queue policy-map configuration commands

Prerequisites
The following tasks must be completed before LLQ for Frame Relay can be enabled:

FRTS must be enabled on the interface. An output service policy must be configured in the map class associated with the interface, subinterface, or DLCI. Any queue other than a FIFO queue that is configured in the map class must be removed. LLQ for Frame Relay cannot be configured if there is already a non-FIFO queue configured, except for the default queue that is created when fragmentation is enabled.

How It Works
LLQ for Frame Relay is used in conjunction with the features described in the following sections:

RTP Prioritization Voice over Frame Relay Frame Relay Fragmentation IP Cisco Express Forwarding Switching

RTP Prioritization
RTP prioritization provides a strict PQ scheme for voice traffic. Voice traffic is identified by its RTP port numbers and classified into a priority queue configured by the frame-relay ip rtp priority map-class configuration command. You classify traffic as voice by specifying an RTP port number range. If traffic matches the specified range, it is classified as voice and queued in the LLQ PQ, and the interface priority queue. If traffic does not fall within the specified RTP port range, it is classified by the service policy of the LLQ scheme. The ip rtp priority command is available in both interface configuration mode and map-class configuration mode. Only the frame relay ip rtp priority map-class configuration command is supported in this feature.

Voice over Frame Relay

Voice over Frame Relay (VoFR) uses the LLQ priority queue (PQ) rather than its own PQ mechanism. The frame-relay voice bandwidth map-class configuration command configures the total bandwidth available for VoFR traffic. The visible bandwidth made available to the other queues will be the minimum committed information rate (CIR) minus the voice bandwidth. The frame-relay voice bandwidth map-class configuration command also configures a call admission control function, which ensures that sufficient VoFR bandwidth remains before allowing a call. There is no policing of the voice traffic once the call has been established.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-105

Congestion Management Overview Custom Queueing

For VoFR with no data, all voice and call control packets are queued in the LLQ priority queueing (PQ). For VoFR with data, a VoFR PVC may carry both voice and data packets in different subchannels. VoFR data packets are fragmented and interleaved with voice packets to ensure good latency bounds for voice packets and scalability for voice and data traffic. Note that when VoFR is enabled, there is no need to configure a priority class map for voice. The only VoFR commands to be used with LLQ for Frame Relay are the frame-relay voice bandwidth map-class configuration command and the vofr data Frame Relay DLCI configuration command.

Note

It is possiblethough not recommendedto configure other traffic for the PQ at the same time as VoFR. Doing so could cause delays because interleaving non-VoFR packets in the PQ would not be possible, causing the PQ (and any VoFR packets on it) to be held up during fragmentation until the entire fragmented packet has been sent.

Frame Relay Fragmentation

The purpose of Frame Relay fragmentation (FRF.12) is to support voice and data packets on lower-speed links without causing excessive delay to the voice packets. Large data packets are fragmented and interleaved with the voice packets. When FRF.12 is configured with LLQ, small packets classified for the PQ pass through unfragmented onto both the LLQ PQ and the high priority interface queue. Large packets destined for PQ are shaped and fragmented when dequeued. Use the frame-relay fragment and service-policy map-class configuration commands to enable LLQ with FRF.12.

IP Cisco Express Forwarding Switching

IP CEF switching is not affected by LLQ functionality.

Custom Queueing
CQ allows you to specify a certain number of bytes to forward from a queue each time the queue is serviced, thereby allowing you to share the network resources among applications with specific minimum bandwidth or latency requirements. You can also specify a maximum number of packets in each queue. For information on how to configure CQ, see the chapter Configuring Custom Queueing in this book.

How It Works
CQ handles traffic by specifying the number of packets or bytes to be serviced for each class of traffic. It services the queues by cycling through them in round-robin fashion, sending the portion of allocated bandwidth for each queue before moving to the next queue. If one queue is empty, the router will send packets from the next queue that has packets ready to send. When CQ is enabled on an interface, the system maintains 17 output queues for that interface. You can specify queues 1 through 16. Associated with each output queue is a configurable byte count, which specifies how many bytes of data the system should deliver from the current queue before it moves on to the next queue.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-106

Congestion Management Overview Custom Queueing

Queue number 0 is a system queue; it is emptied before any of the queues numbered 1 through 16 are processed. The system queues high priority packets, such as keepalive packets and signalling packets, to this queue. Other traffic cannot be configured to use this queue. For queue numbers 1 through 16, the system cycles through the queues sequentially (in a round-robin fashion), dequeueing the configured byte count from each queue in each cycle, delivering packets in the current queue before moving on to the next one. When a particular queue is being processed, packets are sent until the number of bytes sent exceeds the queue byte count or the queue is empty. Bandwidth used by a particular queue can be indirectly specified only in terms of byte count and queue length. Figure 7 shows how CQ behaves.
Figure 7 Custom Queueing

5% 30% Incoming packets

Classify

Percent of length bandwidth

Transmit queue 60%

Outgoing packets

Up to 16 Length defined by queue limit

Weighted round-robin scheduling

Classification by: Queueing Protocol (IP, IPX, buffer resources AppleTalk, SNA, DECnet, bridge, and so on) Source interface (E0, S0, S1, and so on)

Interface hardware Ethernet Frame Relay ATM Serial link (and others)

CQ ensures that no application or specified group of applications achieves more than a predetermined proportion of overall capacity when the line is under stress. Like PQ, CQ is statically configured and does not automatically adapt to changing network conditions. On most platforms, all protocols are classified in the fast-switching path.

Determining Byte Count Values for Queues

In order to allocate bandwidth to different queues, you must specify the byte count for each queue.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-107

16754

Congestion Management Overview Custom Queueing

How the Byte Count Is Used

The router sends packets from a particular queue until the byte count is exceeded. Once the byte count value is exceeded, the packet that is currently being sent will be completely sent. Therefore, if you set the byte count to 100 bytes and the packet size of your protocol is 1024 bytes, then every time this queue is serviced, 1024 bytes will be sent, not 100 bytes. For example, suppose one protocol has 500-byte packets, another has 300-byte packets, and a third has 100-byte packets. If you want to split the bandwidth evenly across all three protocols, you might choose to specify byte counts of 200, 200, and 200 for each queue. However, this configuration does not result in a 33/33/33 ratio. When the router services the first queue, it sends a single 500-byte packet; when it services the second queue, it sends a 300-byte packet; and when it services the third queue, it sends two 100-byte packets. The effective ratio is 50/30/20. Thus, setting the byte count too low can result in an unintended bandwidth allocation. However, very large byte counts will produce a jerky distribution. That is, if you assign 10 KB, 10 KB, and 10 KB to three queues in the example given, each protocol is serviced promptly when its queue is the one being serviced, but it may be a long time before the queue is serviced again. A better solution is to specify 500-byte, 600-byte, and 500-byte counts for the queue. This configuration results in a ratio of 31/38/31, which may be acceptable. In order to service queues in a timely manner and ensure that the configured bandwidth allocation is as close as possible to the required bandwidth allocation, you must determine the byte count based on the packet size of each protocol, otherwise your percentages may not match what you configure.

Note

CQ was modified in Cisco IOS Release 12.1. When the queue is depleted early, or the last packet from the queue does not exactly match the configured byte count, the amount of deficit is remembered and accounted for the next time the queue is serviced. Beginning with Cisco IOS Release 12.1, you need not be as accurate in specifying byte counts as you did when using earlier Cisco IOS releases that did not take deficit into account.

Note

Some protocols, such as Internetwork Packet Exchange (IPX), will negotiate the frame size at session startup time.

Determining the Byte Count

To determine the correct byte counts, perform the following steps:
Step 1

For each queue, divide the percentage of bandwidth you want to allocate to the queue by the packet size, in bytes. For example, assume the packet size for protocol A is 1086 bytes, protocol B is 291 bytes, and protocol C is 831 bytes. We want to allocate 20 percent for A, 60 percent for B, and 20 percent for C. The ratios would be: 20/1086, 60/291, 20/831 or 0.01842, 0.20619, 0.02407

Step 2

Normalize the numbers by dividing by the lowest number: 1, 11.2, 1.3 The result is the ratio of the number of packets that must be sent so that the percentage of bandwidth that each protocol uses is approximately 20, 60, and 20 percent.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-108

Congestion Management Overview Custom Queueing

Step 3

A fraction in any of the ratio values means that an additional packet will be sent. Round up the numbers to the next whole number to obtain the actual packet count. In this example, the actual ratio will be 1 packet, 12 packets, and 2 packets.

Step 4

Convert the packet number ratio into byte counts by multiplying each packet count by the corresponding packet size. In this example, the number of packets sent is one 1086-byte packet, twelve 291-byte packets, and two 831-byte packets, or 1086, 3492, and 1662 bytes, respectively, from each queue. These are the byte counts you would specify in your CQ configuration.

Step 5

To determine the bandwidth distribution this ratio represents, first determine the total number of bytes sent after all three queues are serviced: (1 * 1086) + (12 * 291) + (2 * 831) = 1086 + 3492 + 1662 = 6240

Step 6

Then determine the percentage of the total number of bytes sent from each queue: 1086/6240, 3492/6240, 1662/6240 = 17.4, 56, and 26.6 percent This result is close to the desired ratio of 20/60/20.

Step 7

If the actual bandwidth is not close enough to the desired bandwidth, multiply the original ratio of 1:11.2:1.3 by the best value, trying to get as close to three integer values as possible. Note that the multiplier you use need not be an integer. For example, if we multiply the ratio by two, we get 2:22.4:2.6. We would now send two 1086-byte packets, twenty-three 291-byte packets, and three 831-byte packets, or 2172/6693/2493, for a total of 11,358 bytes. The resulting ratio is 19/59/22 percent, which is much closer to the desired ratio that we achieved.

The bandwidth that a custom queue will receive is given by the following formula:
(queue byte count / total byte count of all queues) * bandwidth capacity of the interface

where bandwidth capacity is equal to the interface bandwidth minus the bandwidth for priority queues.

Window Size
Window size also affects the bandwidth distribution. If the window size of a particular protocol is set to one, then that protocol will not place another packet into the queue until it receives an acknowledgment. The CQ algorithm moves to the next queue if the byte count is exceeded or no packets are in that queue. Therefore, with a window size of one, only one frame will be sent each time. If your frame count is set to 2 kilobytes, and your frame size is 256 bytes, then only 256 bytes will be sent each time this queue is serviced.

Why Use CQ?

You can use the Cisco IOS QoS CQ feature to provide specific traffic guaranteed bandwidth at a potential congestion point, assuring the traffic a fixed portion of available bandwidth and leaving the remaining bandwidth to other traffic. For example, you could reserve half of the bandwidth for SNA data, allowing the remaining half to be used by other protocols. If a particular type of traffic is not using the bandwidth reserved for it, then unused bandwidth can be dynamically allocated to other traffic types.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-109

Congestion Management Overview Priority Queueing

Restrictions
CQ is statically configured and does not adapt to changing network conditions. With CQ enabled, the system takes longer to switch packets than FIFO because the packets are classified by the processor card.

Priority Queueing
PQ allows you to define how traffic is prioritized in the network. You configure four traffic priorities. You can define a series of filters based on packet characteristics to cause the router to place traffic into these four queues; the queue with the highest priority is serviced first until it is empty, then the lower queues are serviced in sequence. For information on how to configure PQ, see the chapter Configuring Priority Queueing in this book.

How It Works
During transmission, PQ gives priority queues absolute preferential treatment over low priority queues; important traffic, given the highest priority, always takes precedence over less important traffic. Packets are classified based on user-specified criteria and placed into one of the four output queueshigh, medium, normal, and lowbased on the assigned priority. Packets that are not classified by priority fall into the normal queue. Figure 8 illustrates this process.
Figure 8 Priority Queueing

High

Incoming packets
Classify

Medium Normal Low

Transmit queue

Outgoing packets

Length defined by queue limit

Classification by: Queueing Protocol (IP, IPX, buffer resources AppleTalk, SNA, DECnet, bridge, and so on ) Source interface (E0, S0, S1, and so on)

Interface hardware Ethernet Frame Relay ATM Serial link (and others)

When a packet is to be sent out an interface, the priority queues on that interface are scanned for packets in descending order of priority. The high priority queue is scanned first, then the medium priority queue, and so on. The packet at the head of the highest queue is chosen for transmission. This procedure is repeated every time a packet is to be sent. The maximum length of a queue is defined by the length limit. When a queue is longer than the queue limit, all additional packets are dropped.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-110

16755

Congestion Management Overview Priority Queueing

Note

The priority output queueing mechanism can be used to manage traffic from all networking protocols. Additional fine-tuning is available for IP and for setting boundaries on the packet size.

How Packets Are Classified for Priority Queueing

A priority list is a set of rules that describe how packets should be assigned to priority queues. A priority list might also describe a default priority or the queue size limits of the various priority queues. Packets can be classified by the following criteria:

Protocol or subprotocol type Incoming interface Packet size Fragments Access list

Keepalives sourced by the network server are always assigned to the high priority queue; all other management traffic (such as Interior Gateway Routing Protocol (IGRP) updates) must be configured. Packets that are not classified by the priority list mechanism are assigned to the normal queue.

Why Use Priority Queueing?

PQ provides absolute preferential treatment to high priority traffic, ensuring that mission-critical traffic traversing various WAN links gets priority treatment. In addition, PQ provides a faster response time than do other methods of queueing. Although you can enable priority output queueing for any interface, it is best used for low-bandwidth, congested serial interfaces.

Restrictions
When choosing to use PQ, consider that because lower priority traffic is often denied bandwidth in favor of higher priority traffic, use of PQ could, in the worst case, result in lower priority traffic never being sent. To avoid inflicting these conditions on lower priority traffic, you can use traffic shaping or CAR to rate-limit the higher priority traffic. PQ introduces extra overhead that is acceptable for slow interfaces, but may not be acceptable for higher speed interfaces such as Ethernet. With PQ enabled, the system takes longer to switch packets because the packets are classified by the processor card. PQ uses a static configuration and does not adapt to changing network conditions. PQ is not supported on any tunnels.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-111

Congestion Management Overview Bandwidth Management

Bandwidth Management
RSVP, CBWFQ, LLQ, IP RTP Priority, Frame Relay IP RTP Priority, and Frame Relay PIPQ can all reserve and consume bandwidth, up to a maximum of the reserved bandwidth on an interface. To allocate bandwidth, you can use one of the following commands:

For RSVP, use the ip rsvp bandwidth command. For CBWFQ, use the bandwidth policy-map class configuration command. For more information on CBWFQ bandwidth allocation, see the section Class-Based Weighted Fair Queueingin this chapter. For LLQ, you can allocate bandwidth using the priority command. For more information on LLQ bandwidth allocation, see the sectionFrame Relay PVC Interface Priority Queueing in this chapter. For IP RTP Priority, use the ip rtp priority command. For more information on IP RTP Priority bandwidth allocation, see the section IP RTP Priority in this chapter. For Frame Relay IP RTP Priority, use the frame-relay ip rtp priority command. For more information on Frame Relay IP RTP Priority, see the section Frame Relay IP RTP Priority in this chapter. For Frame Relay PVC Interface Priority Queueing, use the frame-relay interface-queue priority command. For more information on Frame Relay PIPQ, see the section Frame Relay PVC Interface Priority Queueing in this chapter.

When you configure these commands, be aware of bandwidth limitations and configure bandwidth according to requirements in your network. Remember, the sum of all bandwidths cannot exceed the maximum reserved bandwidth. The default maximum bandwidth is 75 percent of the total available bandwidth on the interface. The remaining 25 percent of bandwidth is used for overhead, including Layer 2 overhead, routing traffic, and best-effort traffic. If you find that it is necessary to change the maximum reserved bandwidth, you can change the maximum bandwidth by using the max-reserved-bandwidth command. The max-reserved-bandwidth command can be used only on interfaces; it cannot be used on VCs. On ATM VCs, ATM cell tax overhead is not included in the 75 percent maximum reserved bandwidth.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-112

Configuring Weighted Fair Queueing

This chapter describes the tasks for configuring flow-based weighted fair queueing (WFQ), distributed WFQ (DWFQ), and class-based WFQ (CBWFQ), and distributed class-based WFQ (DCBWFQ) and the related features described in the following section, which provide strict priority queueing (PQ) within WFQ or CBWFQ:

IP RTP Priority Queueing Frame Relay IP RTP Priority Queueing Frame Relay PVC Interface Priority Queueing Low Latency Queueing Distributed Low Latency Queueing Low Latency Queueing (LLQ) for Frame Relay Burst Size in Low Latency Queueing Per-VC Hold Queue Support for ATM Adapters

For complete conceptual information, see the section Weighted Fair Queueing in the chapter Congestion Management Overview in this book. For a complete description of the QoS commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Flow-Based Weighted Fair Queueing Configuration Task List

WFQ provides traffic priority management that automatically sorts among individual traffic streams without requiring that you first define access lists. WFQ can also manage duplex data streams such as those between pairs of applications, and simplex data streams such as voice or video. There are two categories of WFQ sessions: high bandwidth and low bandwidth. Low-bandwidth traffic has effective priority over high-bandwidth traffic, and high-bandwidth traffic shares the transmission service proportionally according to assigned weights.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-113

Configuring Weighted Fair Queueing Flow-Based Weighted Fair Queueing Configuration Task List

When WFQ is enabled for an interface, new messages for high-bandwidth traffic streams are discarded after the configured or default congestive messages threshold has been met. However, low-bandwidth conversations, which include control message conversations, continue to enqueue data. As a result, the fair queue may occasionally contain more messages than its configured threshold number specifies. With standard WFQ, packets are classified by flow. Packets with the same source IP address, destination IP address, source TCP or User Datagram Protocol (UDP) port, or destination TCP or UDP port belong to the same flow. WFQ allocates an equal share of the bandwidth to each flow. Flow-based WFQ is also called fair queueing because all flows are equally weighted. The Cisco IOS software provides two forms of flow-based WFQ:

Standard WFQ, which is enabled by default on all serial interfaces that run at 2 Mbps or below, and can run on all Cisco serial interfaces. Distributed WFQ, which runs only on Cisco 7000 series routers with a Route Switch Processor (RSP)-based RSP7000 interface processor or Cisco 7500 series routers with a Versatile Interface Processor (VIP)-based VIP2-40 or greater interface processor. (A VIP2-50 interface processor is strongly recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 interface processor is required for OC-3 rates.) For configuration information on DWFQ, see the section Distributed Weighted Fair Queueing Configuration Task List later in this chapter.

To configure flow-based WFQ, perform the tasks described in the following sections. The task in the first section is required; the task in the remaining section is optional.

Configuring WFQ (Required) Monitoring Fair Queueing (Optional)

Flow-based WFQ is supported on unavailable bit rate (UBR), variable bit rate (VBR), and available bit rate (ABR) ATM connections. See the end of this chapter for the section Flow-Based WFQ Configuration Examples.

Configuring WFQ
To configure flow-based WFQ on an interface, use the following command in interface configuration mode: Command
Router(config-if)# fair-queue [congestive-discard-threshold [dynamic-queues [reservable-queues]]]

Purpose Configures an interface to use WFQ.

Flow-based WFQ uses a traffic data stream discrimination registry service to determine to which traffic stream a message belongs. Refer to the table accompanying the description of the fair-queue (WFQ) command in the Cisco IOS Quality of Service Solutions Command Reference for the attributes of a message that are used to classify traffic into data streams. Defaults are provided for the congestion threshold after which messages for high-bandwidth conversations are dropped, and for the number of dynamic and reservable queues; however, you can fine-tune your network operation by changing these defaults. Refer to the tables accompanying the description of the fair-queue (WFQ) command in the Cisco IOS Quality of Service Solutions Command Reference for the default number of dynamic queues that WFQ and CBWFQ use when they are enabled on an interface or ATM VC. These values do not apply for DWFQ.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-114

Configuring Weighted Fair Queueing Distributed Weighted Fair Queueing Configuration Task List

Note

WFQ is the default queueing mode on interfaces that run at E1 speeds (2.048 Mbps) or below. It is enabled by default for physical interfaces that do not use Link Access Procedure, Balanced (LAPB), X.25, or Synchronous Data Link Control (SDLC) encapsulations. WFQ is not an option for these protocols. WFQ is also enabled by default on interfaces configured for Multilink PPP (MLP). However, if custom queueing (CQ) or priority queueing (PQ0 is enabled for a qualifying link, it overrides fair queueing, effectively disabling it. Additionally, WFQ is automatically disabled if you enable autonomous or silicon switching.

Monitoring Fair Queueing

To monitor flow-based fair queueing services in your network, use the following commands in EXEC mode, as needed: Command
Router# show interfaces [interface] Router# show queue interface-type interface-number

Purpose Displays statistical information specific to an interface. Displays the contents of packets inside a queue for a particular interface or virtual circuit (VC). Displays status of the fair queueing configuration.

Router# show queueing fair

Distributed Weighted Fair Queueing Configuration Task List

To configure DWFQ, perform one of the mutually exclusive tasks described in the following sections:

Configuring Flow-Based DWFQ Configuring QoS-Group-Based DWFQ Configuring Type of Service-Based DWFQ Monitoring DWFQ (Optional)

If you enable flow-based DWFQ and then enable class-based DWFQ (either QoS-group based or ToS-based), class-based DWFQ will replace flow-based DWFQ. If you enable class-based DWFQ and then want to switch to flow-based DWFQ, you must disable class-based DWFQ using the no fair-queue class-based command before enabling flow-based DWFQ. If you enable one type of class-based DWFQ and then enable the other type, the second type will replace the first. DWFQ runs only on Cisco 7000 series routers with an RSP-based RSP7000 interface processor or Cisco 7500 series routers with a VIP-based VIP2-40 or greater interface processor. (A VIP2-50 interface processor is strongly recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 interface processor is required for OC-3 rates.) DWFQ can be configured on interfaces but not subinterfaces. It is not supported on Fast EtherChannel, tunnel, or other logical or virtual interfaces such as MLP. See the end of this chapter for the section DWFQ Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-115

Configuring Weighted Fair Queueing Distributed Weighted Fair Queueing Configuration Task List

Configuring Flow-Based DWFQ

To configure flow-based DWFQ, use the following commands in interface configuration mode: Command
Step 1 Step 2
Router(config-if)# fair-queue Router(config-if)# fair-queue aggregate-limit aggregate-packet

Purpose Enables flow-based DWFQ. (Optional) Sets the total number of buffered packets before some packets may be dropped. Below this limit, packets will not be dropped. (Optional) Sets the maximum queue size for individual per-flow queues during periods of congestion.

Step 3

Router(config-if)# fair-queue individual-limit individual-packet

For flow-based DWFQ, packets are classified by flow. Packets with the same source IP address, destination IP address, source TCP or UDP port, destination TCP or UDP port, and protocol belong to the same flow. In general, you should not change the aggregate or individual limit value from the default. Use the fair-queue aggregate-limit and fair-queue individual-limit commands only if you have determined that you would benefit from using different values, based on your particular situation.

Configuring QoS-Group-Based DWFQ

To configure QoS-group-based DWFQ, use the following commands in interface configuration mode: Command
Step 1 Step 2 Step 3
Router(config-if)# fair-queue qos-group Router(config-if)# fair-queue qos-group number weight weight Router(config-if)# fair-queue aggregate-limit aggregate-packet

Purpose Enables QoS-group-based DWFQ. For each QoS group, specifies the percentage of the bandwidth to be allocated to each class. (Optional) Sets the total number of buffered packets before some packets may be dropped. Below this limit, packets will not be dropped. (Optional) Sets the maximum queue size for every per-flow queue during periods of congestion. (Optional) Sets the maximum queue size for a specific QoS group queue during periods of congestion.

Step 4 Step 5

Router(config-if)# fair-queue individual-limit individual-packet Router(config-if)# fair-queue qos-group number limit class-packet

In general, you should not change the aggregate, individual, or class limit value from the default. Use the fair-queue aggregate-limit, fair-queue individual-limit, and fair-queue limit commands only if you have determined that you would benefit from using different values, based on your particular situation.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-116

Configuring Weighted Fair Queueing Class-Based Weighted Fair Queueing Configuration Task List

Configuring Type of Service-Based DWFQ

To configure type of service (ToS)-based DWFQ, use the following commands in interface configuration mode: Command
Step 1 Step 2 Step 3
Router(config-if)# fair-queue tos Router(config-if)# fair-queue tos number weight weight Router(config-if)# fair-queue aggregate-limit aggregate-packet

Purpose Enables ToS-based DWFQ (Optional) For each ToS class, specifies the percentage of the bandwidth to be allocated to each class. (Optional) Sets the total number of buffered packets before some packets may be dropped. Below this limit, packets will not be dropped. (Optional) Sets the maximum queue size for every per-flow queue during periods of congestion. (Optional) Sets the maximum queue size for a specific ToS queue during periods of congestion.

Step 4 Step 5

Router(config-if)# fair-queue individual-limit individual-packet Router(config-if)# fair-queue tos number limit class-packet

In general, you should not change the aggregate, individual, or class limit value from the default. Use the fair-queue aggregate-limit, fair-queue individual-limit, and fair-queue limit commands only if you have determined that you would benefit from using different values, based on your particular situation.

Monitoring DWFQ
To monitor DWFQ, use the following commands in EXEC mode, as needed: Command
Router# show interfaces [interface] Router# show queueing fair-queue

Purpose Displays the statistical information specific to an interface. Displays status of the fair queueing configuration.

Class-Based Weighted Fair Queueing Configuration Task List

To configure CBWFQ, perform the tasks described in the following sections. The tasks in the first three sections are required; the tasks in the remaining sections are optional.

Defining Class Maps (Required) Configuring Class Policy in the Policy Map (Required) Attaching the Service Policy and Enabling CBWFQ (Required) Modifying the Bandwidth for an Existing Policy Map Class (Optional) Modifying the Queue Limit for an Existing Policy Map Class (Optional) Configuring the Bandwidth Limiting Factor (Optional) Deleting Classes (Optional)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-117

Configuring Weighted Fair Queueing Class-Based Weighted Fair Queueing Configuration Task List

Deleting Policy Maps (Optional) Verifying Configuration of Policy Maps and Their Classes (Optional)

CBWFQ is supported on VBR and ABR ATM connections. It is not supported on UBR connections. See the end of this chapter for the section CBWFQ Configuration Examples. For information on how to configure per-VC WFQ and CBWFQ, see the chapter Configuring IP to ATM Class of Service in this book.

Defining Class Maps

To create a class map containing match criteria against which a packet is checked to determine if it belongs to a classand to effectively create the class whose policy can be specified in one or more policy mapsuse the first command in global configuration mode to specify the class map name, then use one of the following commands in class-map configuration mode, as needed: Command
Step 1 Step 2
Router(config)# class-map class-map-name Router(config-cmap)# match access-group {access-group | name access-group-name}

Purpose Specifies the name of the class map to be created. Specifies the name of the access control list (ACL) against whose contents packets are checked to determine if they belong to the class. CBWFQ supports numbered and named ACLs. Specifies the name of the input interface used as a match criterion against which packets are checked to determine if they belong to the class.

or
Router(config-cmap)# match input-interface interface-name

or
Router(config-cmap)# match protocol protocol

Specifies the name of the protocol used as a match criterion against which packets are checked to determine if they belong to the class.

or
Router(config-cmap)# match mpls experimental number

Specifies the value of the EXP field to be used as a match criterion against which packets are checked to determine if they belong to the class.

Other match criteria can be used when defining class maps. For additional match criteria, see the section Creating a Traffic Class in the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

Configuring Class Policy in the Policy Map

To configure a policy map and create class policies that make up the service policy, use the policy-map command to specify the policy map name, then use one or more of the following commands to configure policy for a standard class or the default class:

class bandwidth (policy-map class)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-118

Configuring Weighted Fair Queueing Class-Based Weighted Fair Queueing Configuration Task List

fair-queue (for class-default class only) queue-limit or random-detect

For each class that you define, you can use one or more of the listed commands to configure class policy. For example, you might specify bandwidth for one class and both bandwidth and queue limit for another class. The default class of the policy map (commonly known as the class-default class) is the class to which traffic is directed if that traffic does not satisfy the match criteria of other classes whose policy is defined in the policy map. You can configure class policies for as many classes as are defined on the router, up to the maximum of 64. However, the total amount of bandwidth allocated for all classes included in a policy map must not exceed 75 percent of the available bandwidth on the interface. The other 25 percent is used for control and routing traffic. (To override the 75 percent limitation, use the max-reserved bandwidth command.) If not all of the bandwidth is allocated, the remaining bandwidth is proportionally allocated among the classes, based on their configured bandwidth. To configure class policies in a policy map, perform the optional tasks described in the following sections. If you do not perform the steps in these sections, the default actions are used.

Configuring Class Policy Using Tail Drop (Optional) Configuring Class Policy Using WRED Packet Drop (Optional) Configuring the Class-Default Class Policy (Optional)

Configuring Class Policy Using Tail Drop

To configure a policy map and create class policies that make up the service policy, use the first command in global configuration mode to specify the policy map name, then use the following commands in policy-map class configuration mode, as needed, to configure policy for a standard class. To configure policy for the default class, see the section Configuring the Class-Default Class Policy in this chapter. Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the name of a class to be created and included in the service policy. Specifies the amount of bandwidth, in kbps, or percentage of available bandwidth, to be assigned to the class. The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead. Specifies the maximum number of packets that can be queued for the class.

Router(config-pmap)# class class-name

Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

Step 4

Router(config-pmap-c)# queue-limit number-of-packets

To configure policy for more than one class in the same policy map, repeat Step 2 through Step 4. Note that because this set of commands uses the queue-limit command, the policy map uses tail drop, not Weighted Random Early Detection (WRED) packet drop.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-119

Configuring Weighted Fair Queueing Class-Based Weighted Fair Queueing Configuration Task List

Configuring Class Policy Using WRED Packet Drop

To configure a policy map and create class policies comprising the service policy, use the first command in global configuration mode, as needed, to specify the policy map name, then use the following commands in policy-map class configuration mode, as needed, to configure policy for a standard class. To configure policy for the default class, see the section Configuring the Class-Default Class Policy in this chapter. Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the name of a class to be created and included in the service policy. Specifies the amount of bandwidth, in kbps, or percentage of available bandwidth to be assigned to the class. The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead. Enables WRED. The class policy will drop packets using WRED instead of tail drop. Configures the exponential weight factor used in calculating the average queue length.

Router(config-pmap)# class class-name

Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

Step 4 Step 5

Router(config-pmap-c)# random-detect

Router(config-pmap-c)# random-detect exponential-weighting-constant exponent

or
Router(config-pmap-c)# random-detect precedence precedence min-threshold max-threshold mark-prob-denominator

Configures WRED parameters for packets with a specific IP precedence. Repeat this command for each precedence.

To configure policy for more than one class in the same policy map, repeat Step 2 through Step 5. Note that this set of commands uses WRED packet drop, not tail drop.

Note

If you configure a class in a policy map to use WRED for packet drop instead of tail drop, you must ensure that WRED is not configured on the interface to which you intend to attach that service policy.

Configuring the Class-Default Class Policy

The class-default class is used to classify traffic that does not fall into one of the defined classes. Once a packet is classified, all of the standard mechanisms that can be used to differentiate service among the classes apply. The class-default class was predefined when you created the policy map, but you must configure it. If no default class is configured, then by default the traffic that does not match any of the configured classes is flow classified and given best-effort treatment. By default, the class-default class is defined as flow-based WFQ. However, configuring the default class with the bandwidth policy-map class configuration command disqualifies the default class as flow-based WFQ.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-120

Configuring Weighted Fair Queueing Class-Based Weighted Fair Queueing Configuration Task List

To configure a policy map and configure the class-default class to use tail drop, use the first command in global configuration mode to specify the policy map name, then to configure policy for the default class use the following commands in policy-map class configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the default class so that you can configure or modify its policy. Specifies the amount of bandwidth, in kbps, or percentage of available bandwidth to be assigned to the class. The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead. Specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class. The number of dynamic queues is derived from the bandwidth of the interface. Refer to the tables accompanying the description of the fair-queue (WFQ) command in the Cisco IOS Quality of Service Solutions Command Reference for the default number of dynamic queues that WFQ and CBWFQ use when they are enabled on an interface or ATM VC. Specifies the maximum number of packets that the queue for the default class can accumulate.

Router(config-pmap)# class class-default default-class-name Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

or
Router(config-pmap-c)# fair-queue [number-of-dynamic-queues]

Step 4

Router(config-pmap-c)# queue-limit number-of-packets

To configure a policy map and configure the class-default class to use WRED packet drop, use the first command in global configuration mode to specify the policy map name, then to configure policy for the default class use the following commands in policy-map class configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the default class so that you can configure or modify its policy.

Router(config-pmap)# class class-default default-class-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-121

Configuring Weighted Fair Queueing Class-Based Weighted Fair Queueing Configuration Task List

Command
Step 3
Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

Purpose Specifies the amount of bandwidth, in kbps, or percentage of available bandwidth to be assigned to the class. The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead. Specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class The number of dynamic queues is derived from the bandwidth of the interface. Refer to the tables accompanying the description of the fair-queue (WFQ) command in the Cisco IOS Quality of Service Solutions Command Reference for the default number of dynamic queues that WFQ and CBWFQ use when they are enabled on an interface or ATM VC. Enables WRED. The class policy will drop packets using WRED instead of tail drop. Configures the exponential weight factor used in calculating the average queue length.

or
Router(config-pmap-c)# fair-queue [number-of-dynamic-queues]

Step 4 Step 5

Router(config-pmap-c)# random-detect

Router(config-pmap-c)# random-detect exponential-weighting-constant exponent

or
Router(config-pmap-c)# random-detect precedence precedence min-threshold max-threshold mark-prob-denominator

Configures WRED parameters for packets with a specific IP precedence. Repeat this command for each precedence.

Attaching the Service Policy and Enabling CBWFQ

To attach a service policy to the output interface and enable CBWFQ on the interface, use the following command in interface configuration mode. When CBWFQ is enabled, all classes configured as part of the service policy map are installed in the fair queueing system. Command
Router(config-if)# service-policy output policy-map

Purpose Enables CBWFQ and attaches the specified service policy map to the output interface.

Configuring CBWFQ on a physical interface is only possible if the interface is in the default queueing mode. Serial interfaces at E1 (2.048 Mbps) and below use WFQ by defaultother interfaces use FIFO by default. Enabling CBWFQ on a physical interface overrides the default interface queueing method. Enabling CBWFQ on an ATM permanent virtual circuit (PVC) does not override the default queueing method.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-122

Configuring Weighted Fair Queueing Class-Based Weighted Fair Queueing Configuration Task List

Modifying the Bandwidth for an Existing Policy Map Class

To change the amount of bandwidth allocated for an existing class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map containing the class to be modified. Specifies the name of a class whose bandwidth you want to modify. Specifies the new amount of bandwidth, in kbps, or percentage of available bandwidth to be used to reconfigure the class. The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead.

Router(config-pmap)# class class-name

Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

Modifying the Queue Limit for an Existing Policy Map Class

To change the maximum number of packets that can accrue in a queue reserved for an existing class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map containing the class to be modified. Specifies the name of a class whose queue limit you want to modify. Specifies the new maximum number of packets that can be queued for the class to be reconfigured. The default and maximum number of packets is 64.

Router(config-pmap)# class class-name

Router(config-pmap-c)# queue-limit number-of-packets

Configuring the Bandwidth Limiting Factor

To change the maximum reserved bandwidth allocated for Resource Reservation Protocol (RSVP), CBWFQ, LLQ, IP RTP Priority, Frame Relay IP RTP Priority, and Frame Relay PVC Interface Priority Queueing (PIPQ), use the following command in interface configuration mode: Command
Router(config-if)# max-reserved-bandwidth percent

Purpose Changes the maximum configurable bandwidth for RSVP, CBWFQ, LLQ, IP RTP Priority, Frame Relay IP RTP Priority, and Frame Relay PVC Interface Priority Queueing. The default is 75 percent.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-123

Configuring Weighted Fair Queueing Class-Based Weighted Fair Queueing Configuration Task List

Deleting Classes
To delete one or more class maps from a service policy map, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map containing the classes to be deleted. Specifies the name of the classes to be deleted. Deletes the default class.

Router(config-pmap)# no class class-name Router(config-pmap-c)# no class class-default

Deleting Policy Maps

To delete a policy map, use the following command in global configuration mode: Command
Router(config)# no policy-map policy-map

Purpose Specifies the name of the policy map to be deleted.

Verifying Configuration of Policy Maps and Their Classes

To display the contents of a specific policy map, a specific class from a specific policy map, or all policy maps configured on an interface, use the following commands in EXEC mode, as needed: Command
Router# show policy-map policy-map

Purpose Displays the configuration of all classes that make up the specified policy map. Displays the configuration of the specified class of the specified policy map. Displays the configuration of all classes configured for all policy maps on the specified interface. Displays queueing configuration and statistics for a particular interface.

Router# show policy-map policy-map class class-name

Router# show policy-map interface interface-name

Router# show queue interface-type interface-number

The counters displayed after issuing the show policy-map interface command are updated only if congestion is present on the interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-124

Configuring Weighted Fair Queueing Distributed Class-Based Weighted Fair Queueing Configuration Task List

Distributed Class-Based Weighted Fair Queueing Configuration Task List

To configure DCBWFQ, perform the tasks described in the following sections. Although all the tasks are listed as optional, you must complete the task in either the first or second section.

Modifying the Bandwidth for an Existing Traffic Class (Optional) Modifying the Queue Limit for an Existing Traffic Class (Optional) Monitoring and Maintaining DCBWFQ (Optional)

DCBWFQ is configured using user-defined traffic classes and service policies. Traffic classes and service policies are configured using the Modular Quality of Service Command-Line Interface (CLI) feature. For information on how to configure QoS with the Modular QoS CLI, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book. See the end of this chapter for the section Verifying Configuration of Policy Maps and Their Classes.

Modifying the Bandwidth for an Existing Traffic Class

To change the amount of bandwidth allocated for an existing traffic class in congested environments, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the traffic policy to be created or modified. Specifies the name of a traffic class whose bandwidth you want to modify. Specifies the amount of allocated bandwidth, in kbps, to be reserved for the traffic class in congested network environments.

Router(config-pmap)# class class-name

Router(config-pmap-c)# bandwidth bandwidth-kbps

After configuring the traffic policy with the policy-map command, you must still attach the traffic policy to an interface before it is successfully enabled. For information on attaching a traffic policy to an interface, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-125

Configuring Weighted Fair Queueing Distributed Class-Based Weighted Fair Queueing Configuration Task List

Modifying the Queue Limit for an Existing Traffic Class

To change the maximum number of packets that can accrue in a queue reserved for an existing traffic class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the traffic policy to be created or modified. Specifies the name of a traffic class whose queue limit you want to modify. Specifies the new maximum number of packets that can be queued for the traffic class to be reconfigured. The default and maximum number of packets is 64.

Router(config-pmap)# class class-name

Router(config-pmap-c)# queue-limit number-of-packets

After configuring the service policy with the policy-map command, you must still attach the traffic policy to an interface before it is successfully enabled. For information on attaching a traffic policy to an interface, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

Monitoring and Maintaining DCBWFQ

To display the configuration of a traffic policy and its associated traffic classes, use the following commands in EXEC mode, as needed: Command
Router# show policy-map Router# show policy-map policy-map-name Router# show policy-map interface

Purpose Displays all configured traffic policies. Displays the user-specified traffic policy. Displays statistics and configurations of all input and output policies attached to an interface. Displays configuration and statistics of the input and output policies attached to a particular interface. Displays configuration and statistics of the input policy attached to an interface. Displays configuration statistics of the output policy attached to an interface. Displays the configuration and statistics for the class name configured in the policy.

Router# show policy-map interface interface-spec

Router# show policy-map interface interface-spec input

Router# show policy-map interface interface-spec output

Router# show policy-map [interface [interface-spec [input | output] [class class-name]]]]

Cisco IOS Quality of Service Solutions Configuration Guide

QC-126

Configuring Weighted Fair Queueing IP RTP Priority Configuration Task List

IP RTP Priority Configuration Task List

To configure IP RTP Priority, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Configuring IP RTP Priority (Required) Configuring the Bandwidth Limiting Factor (Optional) Verifying IP RTP Priority (Optional) Monitoring and Maintaining IP RTP Priority (Optional)

See the end of this chapter for the section IP RTP Priority Configuration Examples. Frame Relay Traffic Shaping (FRTS) and Frame Relay Fragmentation (FRF.12) must be configured before the Frame Relay IP RTP Priority feature is used. For information about configuring FRTS and FRF.12, refer to the Cisco IOS Wide-Area Networking Configuration Guide.

Configuring IP RTP Priority

To reserve a strict priority queue for a set of RTP packet flows belonging to a range of UDP destination ports, use the following command in interface configuration mode: Command
Router(config-if)# ip rtp priority starting-rtp-port-number port-number-range bandwidth

Purpose Reserves a strict priority queue for a set of RTP packet flows belonging to a range of UDP destination ports.

Caution

Because the ip rtp priority command gives absolute priority over other traffic, it should be used with care. In the event of congestion, if the traffic exceeds the configured bandwidth, then all the excess traffic is dropped. The ip rtp reserve and ip rtp priority commands cannot be configured on the same interface. The frame-relay ip rtp priority command provides strict PQ for Frame Relay PVCs. For more information about this command, refer to the Cisco IOS Quality of Service Solutions Command Reference.

Configuring the Bandwidth Limiting Factor

To change the maximum reserved bandwidth allocated for CBWFQ, LLQ, and the IP RTP Priority feature, use the following command in interface configuration mode: Command
Router(config-if)# max-reserved-bandwidth percent

Purpose Changes the maximum configurable bandwidth for CBWFQ, LLQ, and IP RTP Priority. The default is 75 percent.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-127

Configuring Weighted Fair Queueing Frame Relay IP RTP Priority Configuration Task List

Verifying IP RTP Priority

To display the contents of the priority queue (such as queue depth and the first packet queued), use the following command in EXEC mode: Command
Router# show queue interface-type interface-number

Purpose Displays queueing configuration and statistics for a particular interface.

Monitoring and Maintaining IP RTP Priority

To tune your RTP bandwidth or decrease RTP traffic if the priority queue is experiencing drops, use the following commands in EXEC mode, as needed: Command
Router# debug priority

Purpose Displays priority queueing output if packets are dropped from the priority queue. Displays queueing configuration and statistics for a particular interface.

Router# show queue interface-type interface-number

Frame Relay IP RTP Priority Configuration Task List

To configure Frame Relay IP RTP Priority, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Configuring Frame Relay IP RTP Priority (Required) Verifying Frame Relay IP RTP Priority (Optional) Monitoring and Maintaining Frame Relay IP RTP Priority (Optional)

See the end of this chapter for the section Frame Relay IP RTP Priority Configuration Examples.

Configuring Frame Relay IP RTP Priority

To reserve a strict priority queue on a Frame Relay PVC for a set of RTP packet flows belonging to a range of UDP destination ports, use the following command in map-class configuration mode: Command
Router(config-map-class)# frame-relay ip rtp priority starting-rtp-port-number port-number-range bandwidth

Purpose Reserves a strict priority queue for a set of RTP packet flows belonging to a range of UDP destination ports.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-128

Configuring Weighted Fair Queueing Frame Relay PVC Interface Priority Configuration Task List

Caution

Because the frame-relay ip rtp priority command gives absolute priority over other traffic, it should be used with care. In the event of congestion, if the traffic exceeds the configured bandwidth, then all the excess traffic is dropped.

Verifying Frame Relay IP RTP Priority

To verify the Frame Relay IP RTP Priority feature, use the following commands in EXEC mode, as needed: Command
Router# show frame relay pvc Router# show queue interface-type interface-number

Purpose Displays statistics about PVCs for Frame Relay interfaces. Displays fair queueing configuration and statistics for a particular interface. Displays information about the elements queued at a particular time at the VC data-link connection identifier (DLCI) level.

Router# show traffic-shape queue

Monitoring and Maintaining Frame Relay IP RTP Priority

To tune your RTP bandwidth or decrease RTP traffic if the priority queue is experiencing drops, use the following command in EXEC mode: Command
Router# debug priority

Purpose Displays priority queueing output if packets are dropped from the priority queue.

Frame Relay PVC Interface Priority Configuration Task List

To configure the Frame Relay PVC Interface Priority feature, perform the tasks described in the following sections. The tasks in the first three sections are required; the tasks in the remaining sections are optional.

Configuring PVC Priority in a Map Class (Required) Enabling Frame Relay PIPQ and Setting Queue Limits (Required) Assigning a Map Class to a PVC (Required) Verifying Frame Relay PIPQ (Optional) Monitoring and Maintaining Frame Relay PIPQ (Optional)

See the end of this chapter for the section Frame Relay PVC Interface PQ Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-129

Configuring Weighted Fair Queueing Frame Relay PVC Interface Priority Configuration Task List

Configuring PVC Priority in a Map Class

To configure PVC priority within a map class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# map-class frame-relay map-class-name Router(config-map-class)# frame-relay interfacequeue priority {high | medium | normal | low}

Purpose Specifies a Frame Relay map class. Assigns a PVC priority level to a Frame Relay map class.

Enabling Frame Relay PIPQ and Setting Queue Limits

To enable Frame Relay (FR) PIPQ and set the priority queue sizes, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# interface type number [name-tag]

Purpose Configures an interface type and enters interface configuration mode. Enables Frame Relay encapsulation. Enables Frame Relay PIPQ and sets the priority queue limits.

Router(config-if)# encapsulation frame-relay [cisco | ietf] Router(config-if)# frame-relay interface-queue priority [high-limit medium-limit normal-limit low-limit]

Assigning a Map Class to a PVC

To assign a map class to a specific PVC, use the following commands beginning in interface configuration mode: Command
Step 1 Step 2
Router(config-if)# frame-relay interface-dlci dlci Router(config-fr-dlci)# class map-class-name

Purpose Specifies a single PVC on a Frame Relay interface. Associates a map class with a specified PVC.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-130

Configuring Weighted Fair Queueing Low Latency Queueing Configuration Task List

Verifying Frame Relay PIPQ

To verify the configuration of Frame Relay (FR) PIPQ, use the following commands in privileged EXEC mode, as needed: Command
Router# show frame-relay pvc [interface interface][dlci]

Purpose Displays statistics about PVCs for Frame Relay interfaces. Displays the statistical information specific to a serial interface. Lists all or selected configured queueing strategies.

Router# show interfaces [type number][first][last]

Router# show queueing [custom | fair | priority | random-detect [interface atm_subinterface [vc [[vpi/] vci]]]]

Monitoring and Maintaining Frame Relay PIPQ

To monitor and maintain Frame Relay (FR) PIPQ, use the following commands in privileged EXEC mode, as needed: Command
Router# debug priority

Purpose Displays priority queueing output if packets are dropped from the priority queue. Displays statistics about PVCs for Frame Relay interfaces. Displays the statistical information specific to a serial interface. Displays the contents of packets inside a queue for a particular interface or VC. Lists all or selected configured queueing strategies.

Router# show frame-relay pvc [interface interface][dlci] Router# show interfaces [type number][first][last] Router# show queue interface-name interface-number [vc [vpi/] vci][queue-number] Router# show queueing [custom | fair | priority | random-detect [interface atm_subinterface [vc [[vpi/] vci]]]]

Low Latency Queueing Configuration Task List

To configure LLQ, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Configuring LLQ (Required) Configuring the Bandwidth Limiting Factor (Optional) Verifying LLQ (Optional) Monitoring and Maintaining LLQ (Optional)

See the end of this chapter for the section LLQ Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-131

Configuring Weighted Fair Queueing Low Latency Queueing Configuration Task List

Configuring LLQ
To give priority to a class within a policy map, use the following command in policy-map class configuration mode: Command
Router(config-pmap-c)# priority bandwidth

Purpose Reserves a strict priority queue for this class of traffic.

Configuring the Bandwidth Limiting Factor

To change the maximum reserved bandwidth allocated for CBWFQ, LLQ, and IP RTP Priority, use the following command in interface configuration mode: Command
Router(config-if)# max-reserved-bandwidth percent

Purpose Changes the maximum configurable bandwidth for CBWFQ, LLQ, and IP RTP Priority. The default is 75 percent.

Verifying LLQ
To display the contents of the priority queue, such as queue depth and the first packet queued, use the following command in EXEC mode: Command
Router# show queue interface-type interface-number

Purpose Displays queueing configuration and statistics for a particular interface.

The priority queue is the queue whose conversation ID is equal to the number of dynamic queues plus 8. The packets in the priority queue have a weight of 0.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-132

Configuring Weighted Fair Queueing Distributed LLQ Configuration Task List

Monitoring and Maintaining LLQ

To tune your RTP bandwidth or decrease RTP traffic if the priority queue is experiencing drops, use the following commands in EXEC mode, as needed: Command
Router# debug priority

Purpose Displays priority queueing output if packets are dropped from the priority queue. Displays queueing configuration and statistics for a particular interface. Displays the configuration of all classes configured for all traffic policies on the specified interface. Displays if packets and bytes were discarded or dropped for the priority class in the traffic policy attached to the interface.

Router# show queue interface-type interface-number

Router# show policy-map interface interface-name

Distributed LLQ Configuration Task List

To configure Distributed LLQ, perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.

Configuring a Priority Queue for an Amount of Available Bandwidth (Required) Configuring a Priority Queue for a Percentage of Available Bandwidth (Required) Configuring a Transmission Ring Limit (Optional) Verifying Distributed LLQ (Optional) Verifying a Transmission Ring Limit (Optional) Monitoring and Maintaining Distributed LLQ (Optional)

See the end of this chapter for the section Distributed LLQ Configuration Examples.

Configuring a Priority Queue for an Amount of Available Bandwidth

To give priority to a traffic class based on the amount of available bandwidth within a traffic policy, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-name

Purpose Specifies the name of the policy map to configure. Enters policy-map configuration mode. Specifies the name of a predefined class included in the service policy. Enters policy-map class configuration mode. Reserves a priority queue with a specified amount of available bandwidth for CBWFQ traffic.

Router(config-pmap)# class class-name

Step 3

Router(config-pmap-c)# priority kpbs [bytes]

Cisco IOS Quality of Service Solutions Configuration Guide

QC-133

Configuring Weighted Fair Queueing Distributed LLQ Configuration Task List

The traffic policy configured in this section is not yet attached to an interface. For information on attaching a traffic policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Configuring a Priority Queue for a Percentage of Available Bandwidth

To give priority to a class based on a percentage of available bandwidth, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-name

Purpose Specifies the name of the traffic policy to configure. Enters policy-map configuration mode. Specifies the name of a predefined class included in the service policy. Enters policy-map class configuration mode. Reserves a priority queue with a specified percentage of available bandwidth for CBWFQ traffic.

Router(config-pmap)# class class-name

Step 3

Router(config-pmap-c)# priority percent percent

The traffic policy configured in this section is not yet attached to an interface. For information on attaching a traffic policy to an interface, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Configuring a Transmission Ring Limit

To limit the number of allowable particles on a transmission ring on an ATM PVC, use the following commands beginning in global interface configuration mode: Command
Step 1 Step 2
Router(config)# interface atm interface-name Router(config-if)# atm pvc vcd-number vpi-number vci-number Encapsulation-type tx-ring-limit ring-limit

Purpose Specifies the name of the ATM interface to configure. Specifies the ATM PVC to configure, the encapsulation type, and the transmission ring limit value.

To limit the number of allowable particles on a transmission ring on an ATM subinterface, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# interface atm subinterface name Router(config-subif)# pvc pvc-name Router(config-if-atm-vc)# tx-ring-limit ring-limit

Purpose Specifies the name of the subinterface to configure. Specifies the name of the PVC to configure. Specifies the transmission ring limit value.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-134

Configuring Weighted Fair Queueing Distributed LLQ Configuration Task List

Verifying Distributed LLQ

To view the contents of the priority queue, such as queue depth and the first packet queued, use the following commands in EXEC mode, as needed: Command
Router# show interfaces [interface-type interface-number] fair-queue Router# show policy-map policy-map-name

Purpose Displays information and statistics about WFQ for a VIP-based interface. Displays the contents of a policy map, including the priority setting in a specific policy map.

The priority queue is the queue in which the conversation ID is equal to the number of dynamic queues plus 8. The packets in the priority queue have a weight of 0.

Verifying a Transmission Ring Limit

To display the contents of the interface or the PVC, use the following command in EXEC mode: Command
Router# show atm vc vc-name

Purpose Displays the contents of a VC. The show atm vc command output will indicate the transmission ring limit value if the tx-ring-limit command is successfully enabled.

Monitoring and Maintaining Distributed LLQ

To tune your Real-Time Transport Protocol (RTP) bandwidth or to decrease RTP traffic if the priority queue is experiencing drops, use the following commands in EXEC mode, as needed: Command
Router# show interfaces [interface-type interface-number] fair-queue Router# show policy-map policy-map-name

Purpose Displays information and statistics about WFQ for a VIP-based interface. Displays the contents of a traffic policy, including the priority setting in a specific policy map. Displays the configuration of all classes configured for all service policies on the specified interface. Displays if packets and bytes were discarded or dropped for the priority class in the service policy attached to the interface. Displays the contents of a VC. The show atm vc command output will indicate the transmission ring limit value if the tx-ring-limit command is successfully enabled.

Router# show policy interface interface-name

Router# show atm vc vc-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-135

Configuring Weighted Fair Queueing Low Latency Queueing for Frame Relay Configuration Task List

Low Latency Queueing for Frame Relay Configuration Task List

To configure LLQ for Frame Relay, perform the tasks described in the following sections. The tasks in the first three sections are required; the tasks in the remaining section are optional.

Defining Class Maps (Required) Configuring Class Policy in the Policy Map (Required) Attaching the Service Policy and Enabling LLQ for Frame Relay (Required) Verifying Configuration of Policy Maps and Their Classes (Optional) Monitoring and Maintaining LLQ for Frame Relay (Optional)

See the end of this chapter for the section LLQ for Frame Relay Configuration Examples.

Defining Class Maps

To create a class map containing match criteria against which a packet is checked to determine if it belongs to a class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# class-map class-map-name Router(config-cmap)# match access-group {access-group | name access-group-name}

Purpose Specifies the name of the class map to be created. Specifies the name of the ACL against whose contents packets are checked to determine if they belong to the class.

or
Router(config-cmap)# match input-interface interface-name

Specifies the name of the input interface used as a match criterion against which packets are checked to determine if they belong to the class.

or

Router(config-cmap)# match protocol protocol

Specifies the name of the protocol used as a match criterion against which packets are checked to determine if they belong to the class.

Configuring Class Policy in the Policy Map

To configure a policy map and create class policies that make up the service policy, begin with the policy-map command to specify the policy map name. Then use one or more of the following commands to configure the policy for a standard class or the default class:

priority bandwidth queue-limit or random-detect fair-queue (for class-default class only)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-136

Configuring Weighted Fair Queueing Low Latency Queueing for Frame Relay Configuration Task List

For each class that you define, you can use one or more of the commands listed to configure the class policy. For example, you might specify bandwidth for one class and both bandwidth and queue limit for another class. The default class of the policy map (commonly known as the class-default class) is the class to which traffic is directed if that traffic does not satisfy the match criteria of the other classes defined in the policy map. You can configure class policies for as many classes as are defined on the router, up to the maximum of 64. However, the total amount of bandwidth allocated for all classes in a policy map must not exceed the minimum committed information rate (CIR) configured for the VC minus any bandwidth reserved by the frame-relay voice bandwidth and frame-relay ip rtp priority commands. If the minimum CIR is not configured, the bandwidth defaults to one half of the CIR. If all of the bandwidth is not allocated, the remaining bandwidth is allocated proportionally among the classes on the basis of their configured bandwidth. To configure class policies in a policy map, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Configuring Class Policy for a LLQ Priority Queue (Required) Configuring Class Policy Using a Specified Bandwidth and WRED Packet Drop (Optional) Configuring the Class-Default Class Policy (Optional)

Configuring Class Policy for a LLQ Priority Queue

To configure a policy map and give priority to a class within the policy map, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the name of a class to be created and included in the service policy. Creates a strict priority class and specifies the amount of bandwidth, in kbps, to be assigned to the class.

Router(config-pmap)# class class-name

Router(config-pmap-c)# priority bandwidth-kbps

Configuring Class Policy Using a Specified Bandwidth and WRED Packet Drop
To configure a policy map and create class policies that make up the service policy, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the name of a class to be created and included in the service policy.

Router(config-pmap)# class class-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-137

Configuring Weighted Fair Queueing Low Latency Queueing for Frame Relay Configuration Task List

Command
Step 3
Router(config-pmap-c)# bandwidth bandwidth-kbps

Purpose Specifies the amount of bandwidth to be assigned to the class, in kbps, or as a percentage of the available bandwidth. Bandwidth must be specified in kbps or as a percentage consistently across classes. (Bandwidth of the priority queue must be specified in kbps.) Enables WRED.

Step 4

Router(config-pmap-c)# random-detect

To configure policy for more than one class in the same policy map, repeat Steps 2 through 4.

Configuring the Class-Default Class Policy

The class-default class is used to classify traffic that does not fall into one of the defined classes. Even though the class-default class is predefined when you create the policy map, you still have to configure it. If a default class is not configured, then traffic that does not match any of the configured classes is given best-effort treatment, which means that the network will deliver the traffic if it can, without any assurance of reliability, delay prevention, or throughput. To configure a policy map and the class-default class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the default class so that you can configure or modify its policy. Specifies the amount of bandwidth, in kbps, to be assigned to the class.

Router(config-pmap)# class class-default default-class-name

Router(config-pmap-c)# bandwidth bandwidth-kbps

or
Router(config-pmap-c)# fair-queue [number-of-dynamic-queues]

Specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class. The number of dynamic queues is derived from the bandwidth of the interface. Specifies the maximum number of packets that the queue for the default class can accumulate.

Step 4

Router(config-pmap-c)# queue-limit number-of-packets

Cisco IOS Quality of Service Solutions Configuration Guide

QC-138

Configuring Weighted Fair Queueing Configuring Burst Size in LLQ Configuration Task List

Attaching the Service Policy and Enabling LLQ for Frame Relay
To attach a service policy to the output interface and enable LLQ for Frame Relay, use the following command in map-class configuration mode. When LLQ is enabled, all classes configured as part of the service policy map are installed in the fair queueing system. Command
Router(config-map-class)# service-policy output policy-map

Purpose Attaches the specified service policy map to the output interface and enables LLQ for Frame Relay.

Verifying Configuration of Policy Maps and Their Classes

To display the contents of a specific policy map or all policy maps configured on an interface, use the following commands in EXEC mod, as needed: Command
Router# show frame-relay pvc dlci

Purpose Displays statistics about the PVC and the configuration of classes for the policy map on the specified DLCI. When FRTS is configured, displays the configuration of classes for all Frame Relay VC-level policy maps. When FRTS is not configured, displays the configuration of classes for the interface-level policy.

Router# show policy-map interface interface-name

Router# show policy-map interface interface-name dlci dlci

When FRTS is configured, displays the configuration of classes for the policy map on the specified DLCI.

Monitoring and Maintaining LLQ for Frame Relay

For a list of commands that can be used to monitor LLQ for Frame Relay, see the previous section Verifying Configuration of Policy Maps and Their Classes.

Configuring Burst Size in LLQ Configuration Task List

To configure the burst size in LLQ, perform the tasks described in the following sections. The tasks in the first two sections are required; the task in the remaining section is optional.

Configuring the LLQ Bandwidth (Required) Configuring the LLQ Burst Size (Required) Verifying the LLQ Burst Size (Optional)

See the end of this chapter for Burst Size in LLQ Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-139

Configuring Weighted Fair Queueing Per-VC Hold Queue Support for ATM Adapters Configuration Task List

Configuring the LLQ Bandwidth

To configure the LLQ bandwidth, use the following command in global configuration mode: Command
Router(config)# priority bandwidth

Purpose Specifies the maximum amount of bandwidth, in kpbs, for the priority traffic.

Configuring the LLQ Burst Size

To configure the LLQ burst size, use the following command in global configuration mode: Command
Router(config)# priority bandwidth burst

Purpose Specifies the burst size in bytes. The range is from 32 to 2 million.

Verifying the LLQ Burst Size

To verify the LLQ burst size, use the following commands in EXEC mode, as needed: Command
Router# show policy-map

Purpose Displays the configuration of all classes comprising the specified service policy map or all classes for all existing policy maps. Displays the configuration of classes configured for service polices on the specified interface or PVC.

Router# show policy-map interface

Per-VC Hold Queue Support for ATM Adapters Configuration Task List
To configure the per-VC hold queue support for ATM adapters, perform the tasks described in the following sections. The task in the first section is required; the task in the remaining section is optional.

Configuring the per-VC Hold Queue on an ATM Adapter (Required) Verifying the Configuration of the per-VC Hold Queue on an ATM Adapter (Optional)

See the end of this chapter for Per-VC Hold Queue Support for ATM Adapters Examples. For related information about per-VC and ATM configurations, see the chapters IP to ATM Class of Service Overview and Configuring IP to ATM Class of Service later in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-140

Configuring Weighted Fair Queueing Flow-Based WFQ Configuration Examples

Configuring the per-VC Hold Queue on an ATM Adapter

To configure the per-VC hold queue on an ATM adapter, use the following command in global configuration mode: Command
Router(config)# vc-hold-queue number-of-packets

Purpose Specifies the number of packets contained in the per-VC hold queue. This can be a number from 5 to 1024.

Verifying the Configuration of the per-VC Hold Queue on an ATM Adapter

To verify the configuration of the per-VC hold queue on an ATM adapter, use the following command in EXEC mode: Command
Router# show queueing interface

Purpose Displays the queueing statistics of an interface or VC.

Flow-Based WFQ Configuration Examples

The following example requests a fair queue with a congestive discard threshold of 64 messages, 512 dynamic queues, and 18 RSVP queues:
Router(config)# interface Serial 3/0 Router(config-if)# ip unnumbered Ethernet 0/0 Router(config-if)# fair-queue 64 512 18

For information on how to configure WFQ, see the section Flow-Based Weighted Fair Queueing Configuration Task List in this chapter.

DWFQ Configuration Examples

The following sections provide DWFQ configuration examples:

Flow-Based DWFQ Example QoS-Group-Based DWFQ Example ToS-Based DWFQ Example

For information on how to configure DWFQ, see the section Distributed Weighted Fair Queueing Configuration Task List in this chapter.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-141

Configuring Weighted Fair Queueing DWFQ Configuration Examples

Flow-Based DWFQ Example

The following example enables DWFQ on the HSSI interface 0/0/0:
Router(config)# interface Hssi0/0/0 Router(config-if)# description 45Mbps to R2 Router(config-if)# ip address 200.200.14.250 255.255.255.252 Router(config-if)# fair-queue

The following is sample output from the show interfaces fair-queue command for this configuration:
Router# show interfaces hssi 0/0/0 fair-queue Hssi0/0/0 queue size 0 packets output 35, drops 0 WFQ: global queue limit 401, local queue limit 200

QoS-Group-Based DWFQ Example

The following example configures QoS-group-based DWFQ. Committed access rate (CAR) policies are used to assign packets with an IP Precedence value of 2 to QoS group 2, and packets with an IP Precedence value of 6 are assigned to QoS group 6.
Router(config)# interface Hssi0/0/0 Router(config-if)# ip address 188.1.3.70 255.255.255.0 Router(config-if)# rate-limit output access-group rate-limit 6 155000000 2000000 8000000 conform-action set-qos-transmit 6 exceed-action drop Router(config-if)# rate-limit output access-group rate-limit 2 155000000 2000000 8000000 conform-action set-qos-transmit 2 exceed-action drop Router(config-if)# fair-queue qos-group Router(config-if)# fair-queue qos-group 2 weight 10 Router(config-if)# fair-queue qos-group 2 limit 27 Router(config-if)# fair-queue qos-group 6 weight 30 Router(config-if)# fair-queue qos-group 6 limit 27 ! Router(config)# access-list rate-limit 2 2 Router(config)# access-list rate-limit 6 6

The following sample output shows how to view WFQ statistics using the show interfaces fair-queue command:
Router# show interfaces fair-queue Hssi0/0/0 queue size 0 packets output 806232, drops 1 WFQ: aggregate queue limit 54, individual queue limit 27 max available buffers 54 Class 0: weight 60 limit 27 qsize 0 packets output 654 drops 0 Class 2: weight 10 limit 27 qsize 0 packets output 402789 drops 0 Class 6: weight 30 limit 27 qsize 0 packets output 402789 drops 1

Cisco IOS Quality of Service Solutions Configuration Guide

QC-142

Configuring Weighted Fair Queueing CBWFQ Configuration Examples

ToS-Based DWFQ Example

The following example configures type of service (ToS)-based DWFQ using the default parameters:
Router# configure terminal Router(config)# interface Hssi0/0/0 Router(config-if)# fair-queue tos Router(config-if)# end

The following is output of the show running-config command for the HSSI interface 0/0/0. Notice that the router automatically adds the default weights and limits for the ToS classes to the configuration.
interface Hssi0/0/0 ip address 188.1.3.70 255.255.255.0 fair-queue tos fair-queue tos 1 weight 20 fair-queue tos 1 limit 27 fair-queue tos 2 weight 30 fair-queue tos 2 limit 27 fair-queue tos 3 weight 40 fair-queue tos 3 limit 27

The following sample output shows how to view DWFQ statistics using the show interfaces fair-queue command:
Router# show interfaces fair-queue Hssi0/0/0 queue size 0 packets output 1417079, drops 2 WFQ: aggregate queue limit 54, individual queue limit 27 max available buffers 54 Class Class Class Class 0: 1: 2: 3: weight weight weight weight 10 20 30 40 limit limit limit limit 27 27 27 27 qsize qsize qsize qsize 0 0 0 0 packets packets packets packets output output output output 1150 drops 0 0 drops 0 775482 drops 1 0 drops 0

CBWFQ Configuration Examples

The following sections provide CBWFQ configuration examples:

Class Map Configuration Example Policy Creation Example Policy Attachment to Interfaces Example CBWFQ Using WRED Packet Drop Example Display Service Policy Map Content Examples

For information on how to configure CBWFQ, see the section Class-Based Weighted Fair Queueing Configuration Task List in this chapter.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-143

Configuring Weighted Fair Queueing CBWFQ Configuration Examples

Class Map Configuration Example

In the following example, ACLs 101 and 102 are created. Next, two class maps are created and their match criteria are defined. For the first map class, called class1, the numbered ACL 101 is used as the match criterion. For the second map class, called class2, the numbered ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the class.
Router(config)# access-list 101 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000 Router(config# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000 Router(config)# class-map class1 Router(config-cmap)# match access-group 101 Router(config-cmap)# exit Router(config-cmap)# class-map class2 Router(config-cmap)# match access-group 102 Router(config-cmap)# exit

Policy Creation Example

In the following example, a policy map called policy1 is defined to contain policy specification for the two classes, class1 and class2. The match criteria for these classes were defined in the previous Class Map Configuration Example section. For class1, the policy specifies the bandwidth allocation request and the maximum number of packets that the queue for this class can accumulate. For class2, the policy specifies only the bandwidth allocation request, so the default queue limit of 64 packets is assumed.
Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap-c)# exit Router(config-pmap)# class class2 Router(config-pmap-c)# bandwidth 2000 Router(config-pmap-c)# exit

Policy Attachment to Interfaces Example

The following example shows how to attach an existing policy map. After you define a policy map, you can attach it to one or more interfaces to specify the service policy for those interfaces. Although you can assign the same policy map to multiple interfaces, each interface can have only one policy map attached at the input and one policy map attached at the output. The policy map in this example was defined in the previous section, Policy Creation Example.
Router(config)# interface e1/1 Router(config-if)# service output policy1 Router(config-if)# exit Router(config)# interface fa1/0/0 Router(config-if)# service output policy1 Router(config-if)# exit

Cisco IOS Quality of Service Solutions Configuration Guide

QC-144

Configuring Weighted Fair Queueing CBWFQ Configuration Examples

CBWFQ Using WRED Packet Drop Example

In the following example, the class map called class1 is created and defined to use the input FastEthernet interface 0/1 as a match criterion to determine if packets belong to the class. Next, the policy map policy1 is defined to contain policy specification for class1, which is configured for WRED packet drop.
Router(config)# class-map class1 Router(config-cmap)# match input-interface FastEthernet0/1 ! Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 1000 Router(config-pmap-c)# random-detect ! Router(config)# interface serial0/0 Router(config-if)# service-policy output policy1 !

Display Service Policy Map Content Examples

The following examples show how to display the contents of service policy maps. Four methods can be used to display the contents.

Display all classes that make up a specified service policy map Display all classes configured for all service policy maps Display a specified class of a service policy map Display all classes configured for all service policy maps on a specified interface

All Classes for a Specified Service Policy Map

The following example displays the contents of the service policy map called pol1:
Router# show policy-map po1 Policy Map po1 Weighted Fair Queueing Class class1 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class3 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class6 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class7 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class8 Bandwidth 937 (kbps) Max thresh 64 (packets)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-145

Configuring Weighted Fair Queueing CBWFQ Configuration Examples

All Classes for All Service Policy Maps

The following example displays the contents of all policy maps on the router:
Router# show policy-map Policy Map poH1 Weighted Fair Queueing Class class1 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class3 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class6 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class7 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class8 Bandwidth 937 (kbps) Max thresh 64 (packets) Policy Map policy2 Weighted Fair Queueing Class class1 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class3 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class6 Bandwidth 300 (kbps) Max thresh 64 (packets)

Specified Class for a Service Policy Map

The following example displays configurations for the class called class7 that belongs to the policy map called po1:
Router# show policy-map po1 class class7 Class class7 Bandwidth 937 (kbps) Max Thresh 64 (packets)

All Classes for All Service Policy Maps on a Specified Interface

The following example displays configurations for classes on the output Ethernet interface 2/0. The numbers shown in parentheses are for use with the Management Information Base (MIB).
Router# show policy-map interface e2/0 Ethernet2/0 Service-policy output:p1 (1057)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-146

Configuring Weighted Fair Queueing Distributed CBWFQ Configuration Examples

Class-map:c1 (match-all) (1059/2) 19 packets, 1140 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match:ip precedence 0 (1063) Weighted Fair Queueing Output Queue:Conversation 265 Bandwidth 10 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map:c2 (match-all) (1067/3) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match:ip precedence 1 (1071) Weighted Fair Queueing Output Queue:Conversation 266 Bandwidth 10 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map:class-default (match-any) (1075/0) 8 packets, 2620 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match:any (1079)

Distributed CBWFQ Configuration Examples

The following sections provide DCBWFQ configuration examples:

Traffic Class Configuration Example Traffic Policy Creation Example Traffic Policy Attachment to an Interface Example

For information on how to configure DCBWFQ, see the section Distributed Class-Based Weighted Fair Queueing Configuration Task List in this chapter.

Traffic Class Configuration Example

In the following example, two traffic classes are created and their match criteria are defined. For the first traffic class, called class1, the numbered ACL 101 is used as the match criterion. For the second traffic class, called class2, the numbered ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the traffic class.
Router(config)# class-map class1 Router(config-cmap)# match access-group 101 Router(config-cmap)# exit Router(config)# class-map class2 Router(config-cmap)# match access-group 102 Router(config-cmap)# exit

For additional information on traffic classes, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-147

Configuring Weighted Fair Queueing IP RTP Priority Configuration Examples

Traffic Policy Creation Example

In the following example, a traffic policy called policy1 is defined to associate QoS features with the two traffic classes, class1 and class2. The match criteria for these traffic classes were defined in the previous Class Map Configuration Example section. For class1, the QoS policies include bandwidth allocation request and maximum packet count limit for the queue reserved for the traffic class. For class2, the policy specifies only a bandwidth allocation request, so the default queue limit of 64 packets is assumed.
Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap)# exit Router(config-pmap)# class class2 Router(config-pmap-c)# bandwidth 2000 Router(config-pmap)# exit

For additional information on traffic policy configurations, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

Traffic Policy Attachment to an Interface Example

The following example shows how to attach an existing traffic policy to an interface. After you define a traffic policy, you can attach it to one or more interfaces to specify a traffic policy for those interfaces. Although you can assign the same traffic policy to multiple interfaces, each interface can have only one traffic policy attached at the input and one policy map attached at the output at one time.
Router(config)# interface fe1/0/0 Router(config-if)# service output policy1 Router(config-if)# exit

For additional information on attaching traffic policy configurations to interfaces, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

IP RTP Priority Configuration Examples

The following sections provide IP RTP Priority configuration examples:

CBWFQ Configuration Example Virtual Template Configuration Example Multilink Bundle Configuration Example Debug Example

For information on how to configure IP RTP Priority, see the section IP RTP Priority Configuration Task List in this chapter.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-148

Configuring Weighted Fair Queueing IP RTP Priority Configuration Examples

CBWFQ Configuration Example

The following example first defines a CBWFQ configuration and then reserves a strict priority queue:
! The following commands define a class map: Router(config)# class-map class1 Router(config-cmap)# match access-group 101 Router(config-cmap)# exit ! The following commands create and attach a policy map: Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap-c)# random-detect Router(config-pmap-c)# random-detect precedence 0 32 256 100 Router(config-pmap-c)# exit Router(config)# interface Serial1 Router(config-if)# service-policy output policy1 ! The following command reserves a strict priority queue: Router(config-if)# ip rtp priority 16384 16383 40

The queue-limit and random-detect commands are optional commands for CBWFQ configurations. The queue-limit command is used for configuring tail drop limits for a class queue. The random-detect command is used for configuring RED drop limits for a class queue, similar to the random-detect command available on an interface.

Virtual Template Configuration Example

The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.
Router(config)# multilink virtual-template 1 Router(config)# interface virtual-template 1 Router(config-if)# ip address 172.16.1.1 255.255.255.0 Router(config-if)# no ip directed-broadcast Router(config-if)# ip rtp priority 16384 16383 25 Router(config-if)# service-policy output policy1 Router(config-if)# ppp multilink Router(config-if)# ppp multilink fragment-delay 20 Router(config-if)# ppp multilink interleave Router(config-if)# max-reserved-bandwidth 80 Router(config-if)# end Router(config)# interface Serial0/1 Router(config-if)# bandwidth 64 Router(config-if)# ip address 1.1.1.2 255.255.255.0 Router(config-if)# no ip directed-broadcast Router(config-if)# encapsulation ppp Router(config-if)# ppp multilink Router(config-if)# end

Note

To make the virtual access interface function properly, the bandwidth policy-map class configuration command should not be configured on the virtual template. It needs to be configured on the actual interface, as shown in the example.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-149

Configuring Weighted Fair Queueing IP RTP Priority Configuration Examples

Multilink Bundle Configuration Example

The following example configures a strict priority queue in a multilink bundle configuration with WFQ. The advantage to using multilink bundles is that you can specify different ip rtp priority parameters on different interfaces. The following commands create multilink bundle 1, which is configured for a maximum ip rtp priority bandwidth of 200 kbps. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for WFQ and IP RTP Priority.
Router(config)# interface multilink 1 Router(config-if)# ip address 172.17.254.161 255.255.255.248 Router(config-if)# no ip directed-broadcast Router(config-if)# ip rtp priority 16384 16383 200 Router(config-if)# no ip mroute-cache Router(config-if)# fair-queue 64 256 0 Router(config-if)# ppp multilink Router(config-if)# ppp multilink fragment-delay 20 Router(config-if)# ppp multilink interleave Router(config-if)# max-reserved-bandwidth 80

The following commands create multilink bundle 2, which is configured for a maximum ip rtp priority bandwidth of 100 kbps:
Router(config)# interface multilink 2 Router(config-if)# ip address 172.17.254.162 255.255.255.248 Router(config-if)# no ip directed-broadcast Router(config-if)# ip rtp priority 16384 16383 100 Router(config-if)# no ip mroute-cache Router(config-if)# fair-queue 64 256 0 Router(config-if)# ppp multilink Router(config-if)# ppp multilink fragment-delay 20 Router(config-if)# ppp multilink interleave

In the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1:
Router(config)# interface serial 2/0 Router(config-if)# bandwidth 256 Router(config-if)# no ip address Router(config-if)# no ip directed-broadcast Router(config-if)# encapsulation ppp Router(config-if)# no ip mroute-cache Router(config-if)# no fair-queue Router(config-if)# clockrate 256000 Router(config-if)# ppp multilink Router(config-if)# multilink-group 1

Next, serial interface 2/1 is configured to be part of multilink bundle 2.

Router(config)# interface serial 2/1 Router(config-if)# bandwidth 128 Router(config-if)# no ip address Router(config-if)# no ip directed-broadcast Router(config-if)# encapsulation ppp Router(config-if)# no ip mroute-cache Router(config-if)# no fair-queue Router(config-if)# clockrate 128000 Router(config-if)# ppp multilink Router(config-if)# multilink-group 2

Cisco IOS Quality of Service Solutions Configuration Guide

QC-150

Configuring Weighted Fair Queueing Frame Relay IP RTP Priority Configuration Examples

Debug Example
The following example shows sample output from the debug priority command. In this example, 64 indicates the actual priority queue depth at the time the packet was dropped.
Router# debug priority *Feb *Feb *Feb *Feb *Feb *Feb *Feb 28 28 28 28 28 28 28 16:46:05.659:WFQ:dropping 16:46:05.671:WFQ:dropping 16:46:05.679:WFQ:dropping 16:46:05.691:WFQ:dropping 16:46:05.699:WFQ:dropping 16:46:05.711:WFQ:dropping 16:46:05.719:WFQ:dropping a a a a a a a packet packet packet packet packet packet packet from from from from from from from the the the the the the the priority priority priority priority priority priority priority queue queue queue queue queue queue queue 64 64 64 64 64 64 64

Frame Relay IP RTP Priority Configuration Examples

This Strict Priority Service to Matching RTP Packets Example section provides a configuration example. For information on how to configure Frame Relay IP RTP Priority queueing, see the section Frame Relay IP RTP Priority Configuration Task List in this chapter.

Strict Priority Service to Matching RTP Packets Example

The following example first configures the Frame Relay map class called voip and then applies the map class to PVC 100 to provide strict priority service to matching RTP packets. In this example, RTP packets on PVC 100 with UDP ports in the range 16384 to 32764 will be matched and given strict priority service.
map-class frame-relay voip frame-relay cir 256000 frame-relay bc 2560 frame-relay be 600 frame-relay mincir 256000 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 250 frame-relay ip rtp priority 16384 16380 210 interface Serial5/0 ip address 10.10.10.10 255.0.0.0 no ip directed-broadcast encapsulation frame-relay no ip mroute-cache load-interval 30 clockrate 1007616 frame-relay traffic-shaping frame-relay interface-dlci 100 class voip frame-relay ip rtp header-compression frame-relay intf-type dce

Cisco IOS Quality of Service Solutions Configuration Guide

QC-151

Configuring Weighted Fair Queueing Frame Relay PVC Interface PQ Configuration Examples

Frame Relay PVC Interface PQ Configuration Examples

This section provides configuration examples for Frame Relay PIPQ. For information on how to configure Frame Relay PIPQ, see the section Frame Relay PVC Interface Priority Configuration Task List in this chapter. This example shows the configuration of four PVCs on serial interface 0. DLCI 100 is assigned high priority, DLCI 200 is assigned medium priority, DLCI 300 is assigned normal priority, and DLCI 400 is assigned low priority. The following commands configure Frame Relay map classes with PVC priority levels:
Router(config)# map-class Router(config-map-class)# Router(config-map-class)# Router(config)# map-class Router(config-map-class)# Router(config-map-class)# Router(config)# map-class Router(config-map-class)# Router(config-map-class)# Router(config)# map-class Router(config-map-class)# Router(config-map-class)# frame-relay frame-relay exit frame-relay frame-relay exit frame-relay frame-relay exit frame-relay frame-relay exit HI interface-queue priority high MED interface-queue priority medium NORM interface-queue priority normal LOW interface-queue priority low

The following commands enable Frame Relay encapsulation and Frame Relay PIPQ on serial interface 0. The sizes of the priority queues are set at a maximum of 20 packets for the high priority queue, 40 for the medium priority queue, 60 for the normal priority queue, and 80 for the low priority queue.
Router(config)# interface Serial0 Router(config-if)# encapsulation frame-relay Router(config-if)# frame-relay interface-queue priority 20 40 60 80

The following commands assign priority to four PVCs by associating the DLCIs with the configured map classes:
Router(config-if)# frame-relay interface-dlci Router(config-fr-dlci)# class HI Router(config-fr-dlci)# exit Router(config-if)# frame-relay interface-dlci Router(config-fr-dlci)# class MED Router(config-fr-dlci)# exit Router(config-if)# frame-relay interface-dlci Router(config-fr-dlci)# class NORM Router(config-fr-dlci)# exit Router(config-if)# frame-relay interface-dlci Router(config-fr-dlci)# class LOW Router(config-fr-dlci)# exit 100

200

300

400

Cisco IOS Quality of Service Solutions Configuration Guide

QC-152

Configuring Weighted Fair Queueing LLQ Configuration Examples

LLQ Configuration Examples

The following sections provide LLQ configuration examples:

ATM PVC Configuration Example Virtual Template Configuration Example Multilink Bundle Configuration Example

For information on how to configure LLQ, see the section Low Latency Queueing Configuration Task List in this chapter.

ATM PVC Configuration Example

In the following example, a strict priority queue with a guaranteed allowed bandwidth of 50 kbps is reserved for traffic that is sent from the source address 10.10.10.10 to the destination address 10.10.10.20, in the range of ports 16384 through 20000 and 53000 through 56000. First, the following commands configure access list 102 to match the desired voice traffic:
Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000 Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000

Next, the class map voice is defined, and the policy map called policy1 is created; a strict priority queue for the class voice is reserved, a bandwidth of 20 kbps is configured for the class bar, and the default class is configured for WFQ. The service-policy command then attaches the policy map to the PVC interface 0/102 on the subinterface atm1/0.2.
Router(config)# class-map voice Router(config-cmap)# match access-group 102 Router(config)# policy-map policy1 Router(config-pmap)# class voice Router(config-pmap-c)# priority 50 Router(config-pmap)# class bar Router(config-pmap-c)# bandwidth 20 Router(config-pmap)# class class-default Router(config-pmap-c)# fair-queue Router(config)# interface atm1/0.2 Router(config-subif)# pvc 0/102 Router(config-subif-vc)# service-policy output policy1

Virtual Template Configuration Example

The following example configures a strict priority queue in a virtual template configuration with CBWFQ. Traffic on virtual template 1 that is matched by access list 102 will be directed to the strict priority queue. First, the class map voice is defined, and the policy map called policy1 is created. A strict priority queue (with a guaranteed allowed bandwidth of 50 kbps) is reserved for the class called voice.
Router(config)# class-map voice Router(config-cmap)# match access-group 102 Router(config)# policy-map policy1

Cisco IOS Quality of Service Solutions Configuration Guide

QC-153

Configuring Weighted Fair Queueing LLQ Configuration Examples

Router(config-pmap)# class voice Router(config-pmap-c)# priority 50

Next, the service-policy command attaches the policy map called policy1 to virtual template 1.
Router(config)# multilink virtual-template 1 Router(config)# interface virtual-template 1 Router(config-if)# ip address 172.16.1.1 255.255.255.0 Router(config-if)# no ip directed-broadcast Router(config-if)# service-policy output policy1 Router(config-if)# ppp multilink Router(config-if)# ppp multilink fragment-delay 20 Router(config-if)# ppp multilink interleave Router(config-if)# end Router(config)# interface serial 2/0 Router(config-if)# bandwidth 256 Router(config-if)# no ip address Router(config-if)# no ip directed-broadcast Router(config-if)# encapsulation ppp Router(config-if)# no fair-queue Router(config-if)# clockrate 256000 Router(config-if)# ppp multilink

Multilink Bundle Configuration Example

The following example configures a strict priority queue in a multilink bundle configuration with CBWFQ. Traffic on serial interface 2/0 that is matched by access list 102 will be directed to the strict priority queue. The advantage to using multilink bundles is that you can specify different priority parameters on different interfaces. To specify different priority parameters, you would configure two multilink bundles with different parameters. First, the class map voice is defined, and the policy map called policy1 is created. A strict priority queue (with a guaranteed allowed bandwidth of 50 kbps) is reserved for the class called voice.
Router(config)# class-map voice Router(config-cmap)# match access-group 102 Router(config)# policy-map policy1 Router(config-pmap)# class voice Router(config-pmap-c)# priority 50

The following commands create multilink bundle 1. The policy map called policy1 is attached to the bundle by the service-policy command.
Router(config)# interface multilink 1 Router(config-if)# ip address 172.17.254.161 255.255.255.248 Router(config-if)# no ip directed-broadcast Router(config-if)# no ip mroute-cache Router(config-if)# service-policy output policy1 Router(config-if)# ppp multilink Router(config-if)# ppp multilink fragment-delay 20 Router(config-if)# ppp multilink interleave

In the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1, which effectively directs traffic on serial interface 2/0 that is matched by access list 102 to the strict priority queue:
Router(config)# interface serial 2/0 Router(config-if)# bandwidth 256 Router(config-if)# no ip address Router(config-if)# no ip directed-broadcast

Cisco IOS Quality of Service Solutions Configuration Guide

QC-154

Configuring Weighted Fair Queueing Distributed LLQ Configuration Examples

Router(config-if)# Router(config-if)# Router(config-if)# Router(config-if)# Router(config-if)#

encapsulation ppp no fair-queue clockrate 256000 ppp multilink multilink-group 1

Distributed LLQ Configuration Examples

The following sections provide distributed LLQ configuration examples:

Enabling PQ for an Amount of Available Bandwidth on an ATM Subinterface Example Enabling PQ for a Percentage of Available Bandwidth on an ATM Subinterface Example Limiting the Transmission Ring Limit on an ATM Interface Example Limiting the Transmission Ring Limit on an ATM PVC Subinterface Example

For information on how to configure distributed LLQ, see the section Distributed LLQ Configuration Task List in this chapter.

Enabling PQ for an Amount of Available Bandwidth on an ATM Subinterface Example

The priority command can be enabled on an ATM subinterface, and that subinterface must have only one enabled ATM PVC. This configuration provides a sufficient amount of ATM PVC support. In the following example, a priority queue with a guaranteed allowed bandwidth of 50 kbps is reserved for traffic that is sent from the source address 10.10.10.10 to the destination address 10.10.10.20, in the range of ports 16384 through 20000 and 53000 through 56000. First, the following commands configure access list 102 to match the desired voice traffic:
Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000 Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000

Next, the traffic class called voice is defined, and the policy map called policy1 is created; a priority queue for the class voice is reserved with a guaranteed allowed bandwidth of 50 kpbs and an allowable burst size of 60 bytes, a bandwidth of 20 kbps is configured for the class called bar, and the default class is configured for flow-based fair queuing. The service-policy command then attaches the policy map to the PVC interface 0/102 on the subinterface atm1/0.
Router(config)# class-map voice Router(config-cmap)# match access-group 102 Router(config)# policy-map policy1 Router(config-pmap)# class voice Router(config-pmap-c)# priority 50 60 Router(config-pmap)# class bar Router(config-pmap-c)# bandwidth 20 Router(config-pmap)# class class-default Router(config-pmap-c)# fair-queue Router(config)# interface atm1/0 Router(config-subif)# pvc 0/102 Router(config-subif)# service-policy output policy1

Cisco IOS Quality of Service Solutions Configuration Guide

QC-155

Configuring Weighted Fair Queueing Distributed LLQ Configuration Examples

Enabling PQ for a Percentage of Available Bandwidth on an ATM Subinterface Example

The priority percent command can be enabled on an ATM subinterface, and that subinterface must have only one enabled ATM PVC. This configuration provides a sufficient amount of ATM PVC support. In the following example, a priority queue with a guaranteed allowed bandwidth percentage of 15 percent is reserved for traffic that is sent from the source address 10.10.10.10 to the destination address 10.10.10.20, in the range of ports 16384 through 20000 and 53000 through 56000. First, the following commands configure access list 102 to match the desired voice traffic:
Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000 Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000

Next, the traffic class called voice is defined, and the policy map called policy1 is created; a priority queue for the class voice is reserved with a guaranteed allowed bandwidth percentage of 15 percent, a bandwidth percentage of 20 percent is configured for the class called bar, and the default class is configured for flow-based fair queueing. The service-policy command then attaches the policy map to the ATM subinterface 1/0.2.
Router(config)# class-map voice Router(config-cmap)# match access-group 102 Router(config)# policy-map policy1 Router(config-pmap)# class voice Router(config-pmap-c)# priority percent 15 Router(config-pmap)# class bar Router(config-pmap-c)# bandwidth percent 20 Router(config-pmap)# class class-default Router(config-pmap-c)# fair-queue Router(config)# interface atm1/0.2 Router(config-subif)# service-policy output policy1

Limiting the Transmission Ring Limit on an ATM Interface Example

In the following example, the number of particles on the transmission ring of an ATM interface is limited to seven particles:
Router(config)# interface atm 1/0/0 Router(config-if)# atm pvc 32 0 32 tx-ring-limit 7

Limiting the Transmission Ring Limit on an ATM PVC Subinterface Example

In the following example, the number of particles on the transmission ring of an ATM PVC subinterface is limited to ten particles:
Router(config)# interface ATM1/0/0.1 point-to-point Router(config-subif)# pvc 2/200 Router(config-if-atm-vc)# tx-ring-limit 10

The tx-ring-limit command can be applied to several ATM PVC subinterfaces on a single interface. Every individual PVC can configure a transmission ring limit.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-156

Configuring Weighted Fair Queueing LLQ for Frame Relay Configuration Examples

LLQ for Frame Relay Configuration Examples

The following section provides a LLQ for Frame Relay configuration examples. For information on how to configure LLQ for Frame Relay, see the section Low Latency Queueing for Frame Relay Configuration Task List in this chapter. The following example shows how to configure a PVC shaped to a 64K CIR with fragmentation. The shaping queue is configured with a class for voice, two data classes for IP precedence traffic, and a default class for best-effort traffic. WRED is used as the drop policy on one of the data classes. The following commands define class maps and the match criteria for the class maps:
! class-map voice match access-group 101 ! class-map immediate-data match access-group 102 ! class-map priority-data match access-group 103 ! access-list 101 permit udp any any range 16384 32767 access-list 102 permit ip any any precedence immediate access-list 103 permit ip any any precedence priority

The following commands create and define a policy map called mypolicy:
! policy-map mypolicy class voice priority 16 class immediate-data bandwidth 32 random-detect class priority-data bandwidth 16 class class-default fair-queue 64 queue-limit 20

The following commands enable Frame Relay fragmentation and attach the policy map to DLCI 100:
! interface Serial1/0.1 point-to-point frame-relay interface-dlci 100 class fragment ! map-class frame-relay fragment frame-relay cir 64000 frame-relay mincir 64000 frame-relay bc 640 frame-relay fragment 50 service-policy output mypolicy

Cisco IOS Quality of Service Solutions Configuration Guide

QC-157

Configuring Weighted Fair Queueing Burst Size in LLQ Configuration Examples

Burst Size in LLQ Configuration Examples

For information on how to configure the burst size in LLQ, see the section Configuring Burst Size in LLQ Configuration Task List in this chapter. The following example configures the burst parameter to 1250 bytes for the class called Voice, which has an assigned bandwidth of 1000 kbps:
policy policy1 class Voice priority 1000 1250

Per-VC Hold Queue Support for ATM Adapters Examples

For information on how to configure per-VC hold queue support for ATM Adapters, see the section Per-VC Hold Queue Support for ATM Adapters Configuration Task List in this chapter. The following example sets the per-VC hold queue to 55:
interface atm2/0.1 pvc 1/101 vc-hold-queue 55

Cisco IOS Quality of Service Solutions Configuration Guide

QC-158

Configuring Custom Queueing

This chapter describes the tasks for configuring QoS custom queueing (CQ) on a router. For complete conceptual information, see the section Low Latency Queueing for Frame Relay in the chapter Congestion Management Overview in this book. For a complete description of the CQ commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Note

CQ is not supported on any tunnels.

Custom Queueing Configuration Task List

You must follow certain required, basic steps to enable CQ for your network. In addition, you can choose to assign packets to custom queues based on protocol type, interface where the packets enter the router, or other criteria you specify. To configure CQ, perform the tasks described in the following sections. The tasks in first and third sections are required; the tasks in the remaining sections are optional.

Defining the Custom Queue List (Required) Specifying the Maximum Size of the Custom Queues (Optional) Assigning Packets to Custom Queues (Required) Monitoring Custom Queue Lists (Optional)

See the end of this chapter for the section Custom Queueing Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-159

Configuring Custom Queueing Custom Queueing Configuration Task List

Defining the Custom Queue List

To assign a custom queue list to an interface, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# interface interface-type interface-number

Purpose Specifies the interface, and then enters interface configuration mode. Assigns a custom queue list to the interface. The list argument is any number from 1 to 16. There is no default assignment.

Router(config-if)# custom-queue-list list

Note

Use the custom-queue-list command in place of the priority-list command. Only one queue list can be assigned per interface. CQ allows a fairness not provided with priority queueing (PQ). With CQ, you can control the available bandwidth on an interface when it is unable to accommodate the aggregate traffic enqueued. Associated with each output queue is a configurable byte count, which specifies how many bytes of data should be delivered from the current queue by the system before the system moves on to the next queue. When a particular queue is being processed, packets are sent until the number of bytes sent exceeds the queue byte count defined by the queue-list queue byte-count command (see the following section Specifying the Maximum Size of the Custom Queues), or until the queue is empty.

Specifying the Maximum Size of the Custom Queues

You can specify the maximum number of packets allowed in each of the custom queues. The default is 20 entries. You can also specify the approximate number of bytes to be forwarded from each queue during its turn in the cycle. The number is used as an average number, because whole packets must be forwarded. To specify the approximate number of bytes to be forwarded from each queue during its turn in the cycle, use the following commands in global configuration mode, as needed: Command
Router(config)# queue-list list-number queue queue-number limit limit-number

Purpose Specifies the maximum number of packets allowed in each of the custom queues. The limit-number argument specifies the number of packets that can be queued at any one time. The range is from 0 to 32767. Designates the average number of bytes forwarded per queue. The byte-count-number argument specifies the average number of bytes the system allows to be delivered from a given queue during a particular cycle.

Router(config)# queue-list list-number queue queue-number byte-count byte-count-number

Cisco IOS Quality of Service Solutions Configuration Guide

QC-160

Configuring Custom Queueing Custom Queueing Configuration Task List

Assigning Packets to Custom Queues

You can assign packets to custom queues based on the protocol type or interface where the packets enter the router. Additionally, you can set the default queue for packets that do not match other assignment rules. You can also specify multiple rules. To define the CQ lists, use the following commands in global configuration mode, as needed: Command
Router(config)# queue-list list-number protocol protocol-name queue-number queue-keyword keyword-value Router(config)# queue-list list-number interface interface-type interface-number queue-number Router(config)# queue-list list-number default queue-number

Purpose Establishes queueing priorities based on the protocol type.

Establishes CQ based on packets entering from a given interface. Assigns a queue number for those packets that do not match any other rule in the custom queue list.

All protocols supported by Cisco are allowed. The queue-keyword variable provides additional options, including byte count, TCP service and port number assignments, and AppleTalk, IP, IPX, VINES, or XNS access list assignments. Refer to the queue-list protocol command syntax description in the Cisco IOS Quality of Service Solutions Command Reference. When you use multiple rules, remember that the system reads the queue-list commands in order of appearance. When classifying a packet, the system searches the list of rules specified by queue-list commands for a matching protocol or interface type. When a match is found, the packet is assigned to the appropriate queue. The list is searched in the order it is specified, and the first matching rule terminates the search.

Monitoring Custom Queue Lists

To display information about the input and output queues when CQ is enabled on an interface, use the following commands in EXEC mode, as needed: Command
Router# show queue interface-type interface-number

Purpose Displays the contents of packets inside a queue for a particular interface or virtual circuit (VC). Displays the status of the CQ lists. Displays the current status of the custom output queues when CQ is enabled.

Router# show queueing custom Router# show interfaces interface-type interface-number

Cisco IOS Quality of Service Solutions Configuration Guide

QC-161

Configuring Custom Queueing Custom Queueing Configuration Examples

Custom Queueing Configuration Examples

The following sections provide custom queueing examples:

Custom Queue List Defined Example Maximum Specified Size of the Custom Queues Examples Packets Assigned to Custom Queues Examples

For information on how to configure CQ, see the section Custom Queueing Configuration Task List in this chapter.

Custom Queue List Defined Example

The following example illustrates how to assign custom queue list number 3 to serial interface 0:
interface serial 0 custom-queue-list 3

Maximum Specified Size of the Custom Queues Examples

The following example specifies the maximum number of packets allowed in each custom queue. The queue length of queue 10 is increased from the default 20 packets to 40 packets.
queue-list 3 queue 10 limit 40

The queue length limit is the maximum number of packets that can be enqueued at any time, with the range being from 0 to 32767 queue entries. The following example decreases queue list 9 from the default byte count of 1500 to 1400 for queue number 10:
queue-list 9 queue 10 byte-count 1400

The byte count establishes the lowest number of bytes the system allows to be delivered from a given queue during a particular cycle.

Packets Assigned to Custom Queues Examples

The following examples assign packets to custom queues by either protocol type or interface type, and the default assignment for unmatched packets.

Protocol Type
The following example assigns traffic that matches IP access list 10 to queue number 1:
queue-list 1 protocol ip 1 list 10

The following example assigns Telnet packets to queue number 2:

queue-list 4 protocol ip 2 tcp 23

Cisco IOS Quality of Service Solutions Configuration Guide

QC-162

Configuring Custom Queueing Custom Queueing Configuration Examples

The following example assigns User Datagram Protocol (UDP) Domain Name Service (DNS) packets to queue number 3:
queue-list 4 protocol ip 3 udp 53

Interface Type
In this example, queue list 4 establishes queueing priorities for packets entering on serial interface 0. The queue number assigned is 10.
queue-list 4 interface serial 0 10

You can define multiple rules; the system reads the priority settings in order of appearance. The system searches the list in the order it is specified, and the first matching rule terminates the search. When a match is found, the packet is assigned to the appropriate queue.

Default Queue
You can specify a default queue for packets that do not match other assignment rules. In this example, the default queue for list 10 is set to queue number 2:
queue-list 10 default 2

Cisco IOS Quality of Service Solutions Configuration Guide

QC-163

Configuring Custom Queueing Custom Queueing Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-164

Configuring Priority Queueing

This chapter describes the tasks for configuring priority queueing (PQ) on a router. For complete conceptual information, see the section Priority Queueing in the chapter Congestion Management Overview in this book. For a complete description of the PQ commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Priority Queueing Configuration Task List

To configure PQ, perform the tasks described in the following sections. The tasks in the first two sections are required; the task in remaining section is optional.

Defining the Priority List (Required) Assigning the Priority List to an Interface (Required) Monitoring Priority Queueing Lists (Optional)

See the end of this chapter for the section Priority Queueing Configuration Examples.

Defining the Priority List

A priority list contains the definitions for a set of priority queues. The priority list specifies which queue a packet will be placed in and, optionally, the maximum length of the different queues. In order to perform queueing using a priority list, you must assign the list to an interface. The same priority list can be applied to multiple interfaces. Alternatively, you can create many different priority policies to apply to different interfaces. To define a priority list, perform the tasks described in the following sections. The task in the first section is required; the task in the remaining section is optional.

Assigning Packets to Priority Queues (Required) Specifying the Maximum Size of the Priority Queues (Optional)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-165

Configuring Priority Queueing Priority Queueing Configuration Task List

Assigning Packets to Priority Queues

Assign packets to priority queues based on the following qualities:

Protocol type Interface where the packets enter the router

You can specify multiple assignment rules. The priority-list commands are read in order of appearance until a matching protocol or interface type is found. When a match is found, the packet is assigned to the appropriate queue and the search ends. Packets that do not match other assignment rules are assigned to the default queue. To specify which queue to place a packet in, use the following commands in global configuration mode: Command
Step 1
Router(config)# priority-list list-number protocol protocol-name {high | medium | normal | low} queue-keyword keyword-value Router(config)# priority-list list-number interface interface-type interface-number {high | medium | normal | low} Router(config)# priority-list list-number default {high | medium | normal | low}

Purpose Establishes queueing priorities based on the protocol type. Establishes queueing priorities for packets entering from a given interface. Assigns a priority queue for those packets that do not match any other rule in the priority list.

Step 2

Step 3

All protocols supported by Cisco are allowed. The queue-keyword argument provides additional options including byte count, TCP service and port number assignments, and AppleTalk, IP, IPX, VINES, or XNS access list assignments. Refer to the queue-list protocol command syntax description in the Cisco IOS Quality of Service Solutions Command Reference.

Specifying the Maximum Size of the Priority Queues

To specify the maximum number of packets allowed in each of the priority queues, use the following command in global configuration mode: Command
Router(config)# priority-list list-number queue-limit [high-limit [medium-limit [normal-limit [low-limit]]]

Purpose Specifies the maximum number of packets allowed in each of the priority queues.

Use the priority-list queue-limit command for each priority list. The default queue limit arguments are listed in Table 10.
Table 10 Default Priority Queue Packet Limits

Priority Queue Argument high-limit medium-limit normal-limit low-limit

Packet Limits 20 40 60 80

Cisco IOS Quality of Service Solutions Configuration Guide

QC-166

Configuring Priority Queueing Priority Queueing Configuration Examples

Assigning the Priority List to an Interface

You can assign a priority list number to an interface. Only one list can be assigned per interface. To assign a priority group to an interface, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# interface interface-type interface-number Router(config-if)# priority-group list-number

Purpose Specifies the interface, and then enters interface configuration mode. Assigns a priority list number to the interface.

Monitoring Priority Queueing Lists

To display information about the input and output queues, use the following commands in EXEC mode, as needed: Command
Router# show queue interface-type interface-number

Purpose Displays the contents of packets inside a queue for a particular interface or VC. Displays the status of the priority queueing lists.

Router# show queueing priority

Priority Queueing Configuration Examples

The following sections provide PQ configuration examples:

Priority Queueing Based on Protocol Type Example Priority Queueing Based on Interface Example Maximum Specified Size of the Priority Queue Example Priority List Assigned to an Interface Example Priority Queueing Using Multiple Rules Example

For information on how to configure PQ, see the section Priority Queueing Configuration Task List in this chapter.

Priority Queueing Based on Protocol Type Example

The following example establishes queueing based on protocol type. The example assigns 1 as the arbitrary priority list number, specifies IP as the protocol type, and assigns a high priority level to traffic that matches IP access list 10.
access-list 10 permit 239.1.1.0 0.0.0.255 priority-list 1 protocol ip high list 10

Cisco IOS Quality of Service Solutions Configuration Guide

QC-167

Configuring Priority Queueing Priority Queueing Configuration Examples

Priority Queueing Based on Interface Example

The following example establishes queueing based on interface. The example sets any packet type entering on Ethernet interface 0 to a medium priority.
priority-list 3 interface ethernet 0 medium

Maximum Specified Size of the Priority Queue Example

The following example changes the maximum number of packets in the high priority queue to 10. The medium-limit, normal, and low-limit queue sizes remain at their default 40-, 60-, and 80-packet limits.
priority-list 4 queue-limit 10 40 60 80

Priority List Assigned to an Interface Example

The following example assigns priority group list 4 to serial interface 0:
interface serial 0 priority-group 4

Priority Queueing Using Multiple Rules Example

When classifying a packet, the system searches the list of rules specified by priority-list commands for a matching protocol type. The following example specifies four rules:

DECnet packets with a byte count less than 200 are assigned a medium priority queue level. IP packets originating or destined to TCP port 23 are assigned a medium priority queue level. IP packets originating or destined to User Datagram Protocol (UDP) port 53 are assigned a medium priority queue level. All IP packets are assigned a high priority queue level.

Remember that when using multiple rules for a single protocol, the system reads the priority settings in the order of appearance.
priority-list priority-list priority-list priority-list 4 4 4 4 protocol protocol protocol protocol decnet medium lt 200 ip medium tcp 23 ip medium udp 53 ip high

Cisco IOS Quality of Service Solutions Configuration Guide

QC-168

Congestion Avoidance

Congestion Avoidance Overview

Congestion avoidance techniques monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottlenecks. Congestion avoidance is achieved through packet dropping. Among the more commonly used congestion avoidance mechanisms is Random Early Detection (RED), which is optimum for high-speed transit networks. Cisco IOS QoS includes an implementation of RED that, when configured, controls when the router drops packets. If you do not configure Weighted Random Early Detection (WRED), the router uses the cruder default packet drop mechanism called tail drop. For an explanation of network congestion, see the chapter Quality of Service Overview. This chapter gives a brief description of the kinds of congestion avoidance mechanisms provided by the Cisco IOS QoS features. It discusses the following features:

Tail drop. This is the default congestion avoidance behavior when WRED is not configured. WRED. WRED and distributed WRED (DWRED)both of which are the Cisco implementations of REDcombine the capabilities of the RED algorithm with the IP Precedence feature. Within the section on WRED, the following related features are discussed:
Flow-based WRED. Flow-based WRED extends WRED to provide greater fairness to all flows

on an interface in regard to how packets are dropped.

DiffServ Compliant WRED. DiffServ Compliant WRED extends WRED to support

Differentiated Services (DiffServ) and Assured Forwarding (AF) Per Hop Behavior (PHB). This feature enables customers to implement AF PHB by coloring packets according to differentiated services code point (DSCP) values and then assigning preferential drop probabilities to those packets. For information on how to configure WRED, DWRED, flow-based WRED, and DiffServ Compliant WRED, see the chapter Configuring Weighted Random Early Detection in this book.

Tail Drop
Tail drop treats all traffic equally and does not differentiate between classes of service. Queues fill during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-171

Congestion Avoidance Overview Weighted Random Early Detection

Weighted Random Early Detection

This section gives a brief introduction to RED concepts and addresses WRED, the Cisco implementation of RED for standard Cisco IOS platforms. WRED avoids the globalization problems that occur when tail drop is used as the congestion avoidance mechanism on the router. Global synchronization occurs as waves of congestion crest only to be followed by troughs during which the transmission link is not fully utilized. Global synchronization of TCP hosts, for example, can occur because packets are dropped all at once. Global synchronization manifests when multiple TCP hosts reduce their transmission rates in response to packet dropping, then increase their transmission rates once again when the congestion is reduced.

About Random Early Detection

The RED mechanism was proposed by Sally Floyd and Van Jacobson in the early 1990s to address network congestion in a responsive rather than reactive manner. Underlying the RED mechanism is the premise that most traffic runs on data transport implementations that are sensitive to loss and will temporarily slow down when some of their traffic is dropped. TCP, which responds appropriatelyeven robustlyto traffic drop by slowing down its traffic transmission, effectively allows the traffic-drop behavior of RED to work as a congestion-avoidance signalling mechanism. TCP constitutes the most heavily used network transport. Given the ubiquitous presence of TCP, RED offers a widespread, effective congestion-avoidance mechanism. In considering the usefulness of RED when robust transports such as TCP are pervasive, it is important to consider also the seriously negative implications of employing RED when a significant percentage of the traffic is not robust in response to packet loss. Neither Novell NetWare nor AppleTalk is appropriately robust in response to packet loss, therefore you should not use RED for them.

How It Works
RED aims to control the average queue size by indicating to the end hosts when they should temporarily slow down transmission of packets. RED takes advantage of the congestion control mechanism of TCP. By randomly dropping packets prior to periods of high congestion, RED tells the packet source to decrease its transmission rate. Assuming the packet source is using TCP, it will decrease its transmission rate until all the packets reach their destination, indicating that the congestion is cleared. You can use RED as a way to cause TCP to slow down transmission of packets. TCP not only pauses, but it also restarts quickly and adapts its transmission rate to the rate that the network can support. RED distributes losses in time and maintains normally low queue depth while absorbing spikes. When enabled on an interface, RED begins dropping packets when congestion occurs at a rate you select during configuration. For an explanation of how the Cisco WRED implementation determines parameters to use in the WRED queue size calculations and how to determine optimum values to use for the weight factor, see the section Average Queue Size later in this chapter.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-172

Congestion Avoidance Overview Weighted Random Early Detection

Packet Drop Probability

The packet drop probability is based on the minimum threshold, maximum threshold, and mark probability denominator. When the average queue depth is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases until the average queue size reaches the maximum threshold. The mark probability denominator is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold. When the average queue size is above the maximum threshold, all packets are dropped. Figure 9 summarizes the packet drop probability.
Figure 9 RED Packet Drop Probability

Two service levels are shown: up to six can be defined Standard service profile

Packet discard probability

Adjustable Premium service profile

Min 1

Max 1

Min 2

Max 2

The minimum threshold value should be set high enough to maximize the link utilization. If the minimum threshold is too low, packets may be dropped unnecessarily, and the transmission link will not be fully used. The difference between the maximum threshold and the minimum threshold should be large enough to avoid global synchronization of TCP hosts (global synchronization of TCP hosts can occur as multiple TCP hosts reduce their transmission rates). If the difference between the maximum and minimum thresholds is too small, many packets may be dropped at once, resulting in global synchronization.

How TCP Handles Traffic Loss

Note

The sections How TCP Handles Traffic Loss and How the Router Interacts with TCP contain detailed information that you need not read in order to use WRED or to have a general sense of the capabilities of RED. If you want to understand why problems of global synchronization occur in response to congestion when tail drop is used by default and how RED addresses them, read these sections.

Cisco IOS Quality of Service Solutions Configuration Guide

16763

Average queue size

QC-173

Congestion Avoidance Overview Weighted Random Early Detection

When the recipient of TCP trafficcalled the receiverreceives a data segment, it checks the four octet (32-bit) sequence number of that segment against the number the receiver expected, which would indicate that the data segment was received in order. If the numbers match, the receiver delivers all of the data that it holds to the target application, then it updates the sequence number to reflect the next number in order, and finally it either immediately sends an acknowledgment (ACK) packet to the sender or it schedules an ACK to be sent to the sender after a short delay. The ACK notifies the sender that the receiver received all data segments up to but not including the one marked with the new sequence number. Receivers usually try to send an ACK in response to alternating data segments they receive; they send the ACK because for many applications, if the receiver waits out a small delay, it can efficiently include its reply acknowledgment on a normal response to the sender. However, when the receiver receives a data segment out of order, it immediately responds with an ACK to direct the sender to resend the lost data segment. When the sender receives an ACK, it makes this determination: It determines if any data is outstanding. If no data is outstanding, the sender determines that the ACK is a keepalive, meant to keep the line active, and it does nothing. If data is outstanding, the sender determines whether the ACK indicates that the receiver has received some or none of the data. If the ACK indicates receipt of some data sent, the sender determines if new credit has been granted to allow it to send more data. When the ACK indicates receipt of none of the data sent and there is outstanding data, the sender interprets the ACK to be a repeatedly sent ACK. This condition indicates that some data was received out of order, forcing the receiver to remit the first ACK, and that a second data segment was received out of order, forcing the receiver to remit the second ACK. In most cases, the receiver would receive two segments out of order because one of the data segments had been dropped. When a TCP sender detects a dropped data segment, it resends the segment. Then it adjusts its transmission rate to half of what is was before the drop was detected. This is the TCP back-off or slow-down behavior. Although this behavior is appropriately responsive to congestion, problems can arise when multiple TCP sessions are carried on concurrently with the same router and all TCP senders slow down transmission of packets at the same time.

How the Router Interacts with TCP

Note

The sections How TCP Handles Traffic Loss and How the Router Interacts with TCP contain detailed information that you need not read in order to use WRED or to have a general sense of the capabilities of RED. If you want to understand why problems of global synchronization occur in response to congestion when tail drop is used by default and how RED addresses them, read these sections. To see how the router interacts with TCP, we will look at an example. In this example, on average, the router receives traffic from one particular TCP stream every other, every 10th, and every 100th or 200th message in the interface in MAE-EAST or FIX-WEST. A router can handle multiple concurrent TCP sessions. Because network flows are additive, there is a high probability that when traffic exceeds the Transmit Queue Limit (TQL) at all, it will vastly exceed the limit. However, there is also a high probability that the excessive traffic depth is temporary and that traffic will not stay excessively deep except at points where traffic flows merge or at edge routers. If the router drops all traffic that exceeds the TQL, as is done when tail drop is used by default, many TCP sessions will simultaneously go into slow start. Consequently, traffic temporarily slows down to the extreme and then all flows slow-start again; this activity creates a condition of global synchronization.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-174

Congestion Avoidance Overview Weighted Random Early Detection

However, if the router drops no traffic, as is the case when queueing features such as fair queueing or custom queueing (CQ) are used, then the data is likely to be stored in main memory, drastically degrading router performance. By directing one TCP session at a time to slow down, RED solves the problems described, allowing for full utilization of the bandwidth rather than utilization manifesting as crests and troughs of traffic.

About WRED
WRED combines the capabilities of the RED algorithm with the IP Precedence feature to provide for preferential traffic handling of higher priority packets. WRED can selectively discard lower priority traffic when the interface begins to get congested and provide differentiated performance characteristics for different classes of service. You can configure WRED to ignore IP precedence when making drop decisions so that nonweighted RED behavior is achieved. For interfaces configured to use the Resource Reservation Protocol (RSVP) feature, WRED chooses packets from other flows to drop rather than the RSVP flows. Also, IP Precedence governs which packets are droppedtraffic that is at a lower precedence has a higher drop rate and therefore is more likely to be throttled back. WRED differs from other congestion avoidance techniques such as queueing strategies because it attempts to anticipate and avoid congestion rather than control congestion once it occurs.

Why Use WRED?

WRED makes early detection of congestion possible and provides for multiple classes of traffic. It also protects against global synchronization. For these reasons, WRED is useful on any output interface where you expect congestion to occur. However, WRED is usually used in the core routers of a network, rather than at the edge of the network. Edge routers assign IP precedences to packets as they enter the network. WRED uses these precedences to determine how to treat different types of traffic. WRED provides separate thresholds and weights for different IP precedences, allowing you to provide different qualities of service in regard to packet dropping for different traffic types. Standard traffic may be dropped more frequently than premium traffic during periods of congestion. WRED is also RSVP-aware, and it can provide the controlled-load QoS service of integrated service.

How It Works
By randomly dropping packets prior to periods of high congestion, WRED tells the packet source to decrease its transmission rate. If the packet source is using TCP, it will decrease its transmission rate until all the packets reach their destination, which indicates that the congestion is cleared. WRED generally drops packets selectively based on IP precedence. Packets with a higher IP precedence are less likely to be dropped than packets with a lower precedence. Thus, the higher the priority of a packet, the higher the probability that the packet will be delivered. WRED reduces the chances of tail drop by selectively dropping packets when the output interface begins to show signs of congestion. By dropping some packets early rather than waiting until the queue is full, WRED avoids dropping large numbers of packets at once and minimizes the chances of global synchronization. Thus, WRED allows the transmission line to be used fully at all times.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-175

Congestion Avoidance Overview Weighted Random Early Detection

In addition, WRED statistically drops more packets from large users than small. Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate little traffic. WRED avoids the globalization problems that occur when tail drop is used as the congestion avoidance mechanism. Global synchronization manifests when multiple TCP hosts reduce their transmission rates in response to packet dropping, then increase their transmission rates once again when the congestion is reduced. WRED is only useful when the bulk of the traffic is TCP/IP traffic. With TCP, dropped packets indicate congestion, so the packet source will reduce its transmission rate. With other protocols, packet sources may not respond or may resend dropped packets at the same rate. Thus, dropping packets does not decrease congestion. WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic, in general, is more likely to be dropped than IP traffic. Figure 10 illustrates how WRED works.
Figure 10 Weighted Random Early Detection

Incoming packets
Classify

Discard test

Transmit queue

Outgoing packets

FIFO scheduling

Discard test based on: Buffer queue depth IP Precedence RSVP session

Queueing buffer resources

16759
-n

Average Queue Size

The router automatically determines parameters to use in the WRED calculations. The average queue size is based on the previous average and the current size of the queue. The formula is:
average = (old_average * (1-2
-n

)) + (current_queue_size * 2

where n is the exponential weight factor, a user-configurable value. For high values of n, the previous average becomes more important. A large factor smooths out the peaks and lows in queue length. The average queue size is unlikely to change very quickly, avoiding drastic swings in size. The WRED process will be slow to start dropping packets, but it may continue dropping packets for a time after the actual queue size has fallen below the minimum threshold. The slow-moving average will accommodate temporary bursts in traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-176

Congestion Avoidance Overview Weighted Random Early Detection

Note

If the value of n gets too high, WRED will not react to congestion. Packets will be sent or dropped as if WRED were not in effect. For low values of n , the average queue size closely tracks the current queue size. The resulting average may fluctuate with changes in the traffic levels. In this case, the WRED process responds quickly to long queues. Once the queue falls below the minimum threshold, the process will stop dropping packets. If the value of n gets too low, WRED will overreact to temporary traffic bursts and drop traffic unnecessarily.

Restrictions
You cannot configure WRED on the same interface as Route Switch Processor (RSP)-based CQ, priority queueing (PQ), or weighted fair queueing (WFQ).

Distributed Weighted Random Early Detection

Distributed WRED (DWRED) is an implementation of WRED for the Versatile Interface Processor (VIP). DWRED provides the complete set of functions for the VIP that WRED provides on standard Cisco IOS platforms. The DWRED feature is only supported on Cisco 7000 series routers with an RSP-based RSP7000 interface processor and Cisco 7500 series routers with a VIP-based VIP2-40 or greater interface processor. A VIP2-50 interface processor is strongly recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 interface processor is required for OC-3 rates. DWRED is configured the same way as WRED. If you enable WRED on a suitable VIP interface, such as a VIP2-40 or greater with at least 2 MB of SRAM, DWRED will be enabled instead. In order to use DWRED, distributed Cisco Express Forwarding (dCEF) switching must be enabled on the interface. For information about dCEF, refer to the Cisco IOS Switching Services Configuration Guide and the Cisco IOS Switching Services Command Reference. You can configure both DWRED and distributed weighted fair queueing (DWFQ) on the same interface, but you cannot configure distributed WRED on an interface for which RSP-based CQ, PQ, or WFQ is configured. You can enable DWRED using the Modular Quality of Service Command-Line Interface (Modular QoS CLI) feature. For complete conceptual and configuration information on the Modular QoS CLI feature, see the chapter Modular Quality of Service Command-Line Interface Overview of this book.

How It Works
When a packet arrives and DWRED is enabled, the following events occur:

The average queue size is calculated. See the Average Queue Size section for details. If the average is less than the minimum queue threshold, the arriving packet is queued. If the average is between the minimum queue threshold and the maximum queue threshold, the packet is either dropped or queued, depending on the packet drop probability. See the Packet-Drop Probability section for details. If the average queue size is greater than the maximum queue threshold, the packet is automatically dropped.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-177

Congestion Avoidance Overview Weighted Random Early Detection

Average Queue Size

The average queue size is based on the previous average and the current size of the queue. The formula is:
average = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

where n is the exponential weight factor, a user-configurable value. For high values of n, the previous average queue size becomes more important. A large factor smooths out the peaks and lows in queue length. The average queue size is unlikely to change very quickly, avoiding drastic swings in size. The WRED process will be slow to start dropping packets, but it may continue dropping packets for a time after the actual queue size has fallen below the minimum threshold. The slow-moving average will accommodate temporary bursts in traffic.

Note

If the value of n gets too high, WRED will not react to congestion. Packets will be sent or dropped as if WRED were not in effect. For low values of n , the average queue size closely tracks the current queue size. The resulting average may fluctuate with changes in the traffic levels. In this case, the WRED process responds quickly to long queues. Once the queue falls below the minimum threshold, the process stops dropping packets. If the value of n gets too low, WRED will overreact to temporary traffic bursts and drop traffic unnecessarily.

Packet-Drop Probability
The probability that a packet will be dropped is based on the minimum threshold, maximum threshold, and mark probability denominator. When the average queue size is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold. The mark probability denominator is the fraction of packets dropped when the average queue size is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold. When the average queue size is above the maximum threshold, all packets are dropped. Figure 11 summarizes the packet drop probability.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-178

Congestion Avoidance Overview Weighted Random Early Detection

Figure 11

Packet Drop Probability

1

Packet discard probability

Mark probability

0 Minimum threshold Maximum threshold

10778

Average queue size

The minimum threshold value should be set high enough to maximize the link utilization. If the minimum threshold is too low, packets may be dropped unnecessarily, and the transmission link will not be fully used. The difference between the maximum threshold and the minimum threshold should be large enough to avoid global synchronization of TCP hosts (global synchronization of TCP hosts can occur as multiple TCP hosts reduce their transmission rates). If the difference between the maximum and minimum thresholds is too small, many packets may be dropped at once, resulting in global synchronization.

Why Use DWRED?

DWRED provides faster performance than does RSP-based WRED. You should run DWRED on the VIP if you want to achieve very high speed on the Cisco 7500 series platformfor example, you can achieve speed at the OC-3 rates by running WRED on a VIP2-50 interface processor. Additionally, the same reasons you would use WRED on standard Cisco IOS platforms apply to using DWRED. (See the section Why Use WRED? earlier in this chapter.) For instance, when WRED or DWRED is not configured, tail drop is enacted during periods of congestion. Enabling DWRED obviates the global synchronization problems that result when tail drop is used to avoid congestion. The DWRED feature provides the benefit of consistent traffic flows. When RED is not configured, output buffers fill during periods of congestion. When the buffers are full, tail drop occurs; all additional packets are dropped. Because the packets are dropped all at once, global synchronization of TCP hosts can occur as multiple TCP hosts reduce their transmission rates. The congestion clears, and the TCP hosts increase their transmission rates, resulting in waves of congestion followed by periods when the transmission link is not fully used. RED reduces the chances of tail drop by selectively dropping packets when the output interface begins to show signs of congestion. By dropping some packets early rather than waiting until the buffer is full, RED avoids dropping large numbers of packets at once and minimizes the chances of global synchronization. Thus, RED allows the transmission line to be used fully at all times. In addition, RED statistically drops more packets from large users than small. Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate little traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-179

Congestion Avoidance Overview Weighted Random Early Detection

DWRED provides separate thresholds and weights for different IP precedences, allowing you to provide different qualities of service for different traffic. Standard traffic may be dropped more frequently than premium traffic during periods of congestion.

Restrictions
The following restrictions apply to the DWRED feature:

Interface-based DWRED cannot be configured on a subinterface. (A subinterface is one of a number of virtual interfaces on a single physical interface.) DWRED is not supported on Fast EtherChannel and tunnel interfaces. RSVP is not supported on DWRED. DWRED is useful only when the bulk of the traffic is TCP/IP traffic. With TCP, dropped packets indicate congestion, so the packet source reduces its transmission rate. With other protocols, packet sources may not respond or may resend dropped packets at the same rate. Thus, dropping packets does not necessarily decrease congestion. DWRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic is usually more likely to be dropped than IP traffic. DWRED cannot be configured on the same interface as RSP-based CQ, PQ, or WFQ. However, both DWRED and DWFQ can be configured on the same interface.

Note

Do not use the match protocol command to create a traffic class with a non-IP protocol as a match criterion. The VIP does not support matching of non-IP protocols.

Prerequisites
This section provides the prerequisites that must be met before you configure the DWRED feature.

Weighted Fair Queueing

Attaching a service policy to an interface disables WFQ on that interface if WFQ is configured for the interface. For this reason, you should ensure that WFQ is not enabled on such an interface before configuring DWRED. For information on WFQ, see the chapter Configuring Weighted Fair Queueing in this book.

WRED
Attaching a service policy configured to use WRED to an interface disables WRED on that interface. If any of the traffic classes that you configure in a policy map use WRED for packet drop instead of tail drop, you must ensure that WRED is not configured on the interface to which you intend to attach that service policy.

Access Control Lists

You can specify a numbered access list as the match criterion for any traffic class that you create. For this reason, before configuring DWRED you should know how to configure access lists.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-180

Congestion Avoidance Overview Weighted Random Early Detection

Cisco Express Forwarding

In order to use DWRED, dCEF switching must be enabled on the interface. For information on dCEF, refer to the Cisco IOS Switching Services Configuration Guide.

Flow-Based WRED
Flow-based WRED is a feature that forces WRED to afford greater fairness to all flows on an interface in regard to how packets are dropped.

Why Use Flow-Based WRED?

Before you consider the advantages that use of flow-based WRED offers, it helps to think about how WRED (without flow-based WRED configured) affects different kinds of packet flows. Even before flow-based WRED classifies packet flows, flows can be thought of as belonging to one of the following categories:

Nonadaptive flows, which are flows that do not respond to congestion. Robust flows, which on average have a uniform data rate and slow down in response to congestion. Fragile flows, which, though congestion-aware, have fewer packets buffered at a gateway than do robust flows.

WRED tends toward bias against fragile flows because all flows, even those with relatively fewer packets in the output queue, are susceptible to packet drop during periods of congestion. Though fragile flows have fewer buffered packets, they are dropped at the same rate as packets of other flows. To provide fairness to all flows, flow-based WRED has the following features:

It ensures that flows that respond to WRED packet drops (by backing off packet transmission) are protected from flows that do not respond to WRED packet drops. It prohibits a single flow from monopolizing the buffer resources at an interface.

How It Works
Flow-based WRED relies on the following two main approaches to remedy the problem of unfair packet drop:

It classifies incoming traffic into flows based on parameters such as destination and source addresses and ports. It maintains state about active flows, which are flows that have packets in the output queues.

Flow-based WRED uses this classification and state information to ensure that each flow does not consume more than its permitted share of the output buffer resources. Flow-based WRED determines which flows monopolize resources and it more heavily penalizes these flows. To ensure fairness among flows, flow-based WRED maintains a count of the number of active flows that exist through an output interface. Given the number of active flows and the output queue size, flow-based WRED determines the number of buffers available per flow. To allow for some burstiness, flow-based WRED scales the number of buffers available per flow by a configured factor and allows each active flow to have a certain number of packets in the output queue. This scaling factor is common to all flows. The outcome of the scaled number of buffers becomes the per-flow limit. When a flow exceeds the per-flow limit, the probability that a packet from that flow will be dropped increases.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-181

Congestion Avoidance Overview Weighted Random Early Detection

DiffServ Compliant WRED

DiffServ Compliant WRED extends the functionality of WRED to enable support for DiffServ and AF Per Hop Behavior PHB. This feature enables customers to implement AF PHB by coloring packets according to DSCP values and then assigning preferential drop probabilities to those packets.

Note

This feature can be used with IP packets only. It is not intended for use with Multiprotocol Label Switching (MPLS)-encapsulated packets. The Class-Based Quality of Service MIB supports this feature. This MIB is actually the following two MIBs:

CISCO-CLASS-BASED-QOS-MIB CISCO-CLASS-BASED-QOS-CAPABILITY-MIB

The DiffServ Compliant WRED feature supports the following RFCs:

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 2475, An Architecture for Differentiated Services Framework RFC 2597, Assured Forwarding PHB RFC 2598, An Expedited Forwarding PHB

How It Works
The DiffServ Compliant WRED feature enables WRED to use the DSCP value when it calculates the drop probability for a packet. The DSCP value is the first six bits of the IP type of service (ToS) byte. This feature adds two new commands, random-detect dscp and dscp . It also adds two new arguments, dscp-based and prec-based, to two existing WRED-related commandsthe random-detect (interface) command and the random-detect-group command. The dscp-based argument enables WRED to use the DSCP value of a packet when it calculates the drop probability for the packet. The prec-based argument enables WRED to use the IP Precedence value of a packet when it calculates the drop probability for the packet. These arguments are optional (you need not use any of them to use the commands) but they are also mutually exclusive. That is, if you use the dscp-based argument, you cannot use the prec-based argument with the same command. After enabling WRED to use the DSCP value, you can then use the new random-detect dscp command to change the minimum and maximum packet thresholds for that DSCP value. Three scenarios for using these arguments are provided.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-182

Congestion Avoidance Overview Weighted Random Early Detection

Usage Scenarios
The new dscp-based and prec-based arguments can be used whether you are using WRED at the interface level, at the per-virtual circuit (VC) level, or at the class level (as part of class-based WFQ (CBWFQ) with policy maps).

WRED at the Interface Level

At the interface level, if you want to have WRED use the DSCP value when it calculates the drop probability, you can use the dscp-based argument with the random-detect (interface) command to specify the DSCP value. Then use the random-detect dscp command to specify the minimum and maximum thresholds for the DSCP value.

WRED at the per-VC Level

At the per-VC level, if you want to have WRED use the DSCP value when it calculates the drop probability, you can use the dscp-based argument with the random-detect-group command. Then use the dscp command to specify the minimum and maximum thresholds for the DSCP value or the mark-probability denominator. This configuration can then be applied to each VC in the network.

WRED at the Class Level

If you are using WRED at the class level (with CBWFQ), the dscp-based and prec-based arguments can be used within the policy map. First, specify the policy map, the class, and the bandwidth. Then, if you want WRED to use the DSCP value when it calculates the drop probability, use the dscp-based argument with the random-detect (interface) command to specify the DSCP value. Then use the random-detect dscp command to modify the default minimum and maximum thresholds for the DSCP value. This configuration can then be applied wherever policy maps are attached (for example, at the interface level, the per-VC level, or the shaper level).

Usage Points to Note

Remember the following points when using the new commands and the new arguments included with this feature:

If you use the dscp-based argument, WRED will use the DSCP value to calculate the drop probability. If you use the prec-based argument, WRED will use the IP Precedence value to calculate the drop probability. The dscp-based and prec-based arguments are mutually exclusive. If you do not specify either argument, WRED will use the IP Precedence value to calculate the drop probability (the default method). The random-detect dscp command must be used in conjunction with the random-detect (interface) command. The random-detect dscp command can only be used if you use the dscp-based argument with the random-detect (interface) command.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-183

Congestion Avoidance Overview Weighted Random Early Detection

The dscp command must be used in conjunction with the random-detect-group command. The dscp command can only be used if you use the dscp-based argument with the random-detect-group command.

For more information about using these commands, refer to the Cisco IOS Quality of Service Command Reference.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-184

Configuring Weighted Random Early Detection

This chapter describes the tasks for configuring Weighted Random Early Detection (WRED), distributed WRED (DWRED), flow-based WRED, and DiffServ Compliant WRED on a router. For complete conceptual information, see the section Weighted Random Early Detection in the chapter Congestion Avoidance Overview in this book. For a complete description of the WRED and DWRED commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. The RSVP-ATM QoS Interworking and IP to ATM Class of Service features also use WRED. For information on how to configure these features with WRED, see the chapters Configuring RSVP-ATM QoS Interworking and Configuring IP to ATM Class of Service in this book. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Note

WRED is useful with adaptive traffic such as TCP/IP. With TCP, dropped packets indicate congestion, so the packet source will reduce its transmission rate. With other protocols, packet sources may not respond or may resend dropped packets at the same rate. Thus, dropping packets does not decrease congestion. WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic is more likely to be dropped than IP traffic. You cannot configure WRED on the same interface as Route Switch Processor (RSP)-based custom queueing (CQ), priority queueing (PQ), or weighted fair queueing (WFQ). However, you can configure both DWRED and DWFQ on the same interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-185

Configuring Weighted Random Early Detection Weighted Random Early Detection Configuration Task List

Weighted Random Early Detection Configuration Task List

Random Early Detection (RED) is a congestion avoidance mechanism that takes advantage of the congestion control mechanism of TCP. By randomly dropping packets prior to periods of high congestion, RED tells the packet source to decrease its transmission rate. WRED drops packets selectively based on IP precedence. Edge routers assign IP precedences to packets as they enter the network. (WRED is useful on any output interface where you expect to have congestion. However, WRED is usually used in the core routers of a network, rather than at the edge.) WRED uses these precedences to determine how it treats different types of traffic. When a packet arrives, the following events occur:
1. 2. 3.

The average queue size is calculated. If the average is less than the minimum queue threshold, the arriving packet is queued. If the average is between the minimum queue threshold for that type of traffic and the maximum threshold for the interface, the packet is either dropped or queued, depending on the packet drop probability for that type of traffic. If the average queue size is greater than the maximum threshold, the packet is dropped.

4.

See the section About WRED in the chapter Congestion Avoidance Overviewin this book for more details on the queue calculations and how WRED works. To configure WRED on an interface, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Enabling WRED (Required) Changing WRED Parameters (Optional) Monitoring WRED (Optional)

See the end of this chapter for the section WRED Configuration Examples.

Enabling WRED
To enable WRED, use the following command in interface configuration mode: Command
Router(config-if)# random-detect

Purpose Enables WRED. If you configure this command on a Versatile Interface Processor (VIP) interface, DWRED is enabled.

You need not specify any other commands or parameters in order to configure WRED on the interface. WRED will use the default parameter values.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-186

Configuring Weighted Random Early Detection Weighted Random Early Detection Configuration Task List

Changing WRED Parameters

To change WRED parameters, use the following commands in interface configuration mode, as needed: Command
Router(config-if)# random-detect exponential-weighting-constant exponent Router(config-if)# random-detect precedence precedence min-threshold max-threshold mark-prob-denominator

Purpose Configures the weight factor used in calculating the average queue length. Configures parameters for packets with a specific IP Precedence. The minimum threshold for IP Precedence 0 corresponds to half the maximum threshold for the interface. Repeat this command for each precedence. To configure RED, rather than WRED, use the same parameters for each precedence.

When you enable WRED with the random-detect interface configuration command, the parameters are set to their default values. The weight factor is 9. For all precedences, the mark probability denominator is 10, and maximum threshold is based on the output buffering capacity and the transmission speed for the interface. The default minimum threshold depends on the precedence. The minimum threshold for IP Precedence 0 corresponds to half of the maximum threshold. The values for the remaining precedences fall between half the maximum threshold and the maximum threshold at evenly spaced intervals.

Note

The default WRED parameter values are based on the best available data. We recommend that you do not change the parameters from their default values unless you have determined that your applications will benefit from the changed values.

Monitoring WRED
To monitor WRED services in your network, use the following commands in EXEC mode, as needed: Command
Router# show queue interface-type interface-number

Purpose Displays the header information of the packets inside a queue. This command does not support DWRED. Displays the WRED statistics of a specific virtual circuit (VC) on an interface. Displays the queueing configuration for WRED. Displays WRED configuration on an interface.

Router# show queueing interface interface-number [vc [[vpi/] vci]] Router# show queueing random-detect Router# show interfaces [type slot | port-adapter | port]

Cisco IOS Quality of Service Solutions Configuration Guide

QC-187

Configuring Weighted Random Early Detection DWRED Configuration Task List

DWRED Configuration Task List

To configure DWRED, perform the tasks described in the following sections. The tasks in the first two sections are required; the task in the remaining section is optional.

Configuring DWRED in a Traffic Policy (Required) Configuring DWRED to Use IP Precedence Values in a Traffic Policy (Required) Monitoring and Maintaining DWRED (Optional)

See the end of this chapter for the section DWRED Configuration Examples.

Configuring DWRED in a Traffic Policy

To configure DWRED in a traffic policy, use the policy-map command in global configuration mode to specify the traffic policy name. Then to configure the traffic policy, use the following commands in policy-map configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-map

Purpose Specifies the name of the traffic policy to be created or modified. Specifies the name of a traffic class to be created and included in the traffic policy

Router(config-pmap)# class class-name

Steps 3, 4, and 5 are optional. If you do not want to configure the exponential weight factor, specify the amount of bandwidth, or specify the number of queues to be reserved, you can skip these three steps and continue with step 6.
Step 3 Step 4 Step 5 Step 6
Router(config-pmap-c)# random-detect exponential-weighting-constant exponent Router(config-pmap-c)# bandwidth bandwidth-kbps

Configures the exponential weight factor used in calculating the average queue length. Specifies the amount of bandwidth, in kbps, to be assigned to the traffic class. Specifies the number of queues to be reserved for the traffic class. Specifies the maximum number of packets that can be queued for the specified traffic class.

Router(config-pmap-c)# fair-queue [queue-limit queue-values] Router(config-pmap-c)# queue-limit number-of-packets

The default traffic class for the traffic policy is the traffic class to which traffic is directed if that traffic does not satisfy the match criteria of other traffic classes whose policy is defined in the traffic policy. To configure a policy for more than one traffic class in the same policy map, repeat Step 2 through Step 4. To attach a traffic policy to an interface and enable CBWFQ on the interface, you must create a traffic policy. You can configure traffic class policies for as many traffic classes as are defined on the router, up to the maximum of 64. After configuring the traffic policy with the policy-map command, you must still attach the traffic policy to an interface before it is successfully enabled. For information on attaching a traffic policy to an interface, see the chapter Configuring the Modular Quality of Service Command-Line Interface of this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-188

Configuring Weighted Random Early Detection DWRED Configuration Task List

Configuring DWRED to Use IP Precedence Values in a Traffic Policy

To configure DWRED to drop packets based on IP Precedence values, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3 Step 4
Router(config)# policy-map policy-map

Purpose Specifies the name of the traffic policy to be created or modified. Specifies the name of a traffic class to associate with the traffic policy Configures the exponential weight factor used in calculating the average queue length. Configures the parameters for packets with a specific IP Precedence. The minimum threshold for IP Precedence 0 corresponds to half the maximum threshold for the interface. Repeat this command for each precedence.

Router(config-pmap)# class class-name

Router(config-pmap-c)# random-detect exponential-weighting-constant exponent Router(config-pmap-c)# random-detect precedence precedence min-threshold max-threshold mark-prob-denominator

After configuring the traffic policy with the policy-map command, you must still attach the traffic policy to an interface before it is successfully enabled. For information on attaching a traffic policy to an interface, see the chapter Configuring the Modular Quality of Service Command-Line Interface of this book.

Monitoring and Maintaining DWRED

To display the configuration of a traffic policy and its associated traffic classes, use the following commands in EXEC mode, as needed: Command
Router# show policy-map Router# show policy-map policy-map-name Router# show policy-map interface

Purpose Displays all configured traffic policies. Displays the user-specified traffic policy. Displays statistics and configurations of all input and output policies attached to an interface. Displays configuration and statistics of the input and output policies attached to a particular interface. Displays configuration and statistics of the input policy attached to an interface. Displays configuration statistics of the output policy attached to an interface. Displays the configuration and statistics for the class name configured in the policy.

Router# show policy-map interface interface-spec

Router# show policy-map interface interface-spec input

Router# show policy-map interface interface-spec output

Router# show policy-map [interface [interface-spec [input | output] [class class-name]]]]

Cisco IOS Quality of Service Solutions Configuration Guide

QC-189

Configuring Weighted Random Early Detection Flow-Based WRED Configuration Task List

Flow-Based WRED Configuration Task List

To configure flow-based WRED on an interface, perform the required task described in the Configuring Flow-Based WRED section. See the end of this chapter for the section Flow-Based WRED Configuration Example.

Configuring Flow-Based WRED

Before you can configure flow-based WRED, you must enable WRED and configure it. For information on how to configure WRED, see the section Weighted Random Early Detection Configuration Task List earlier in this chapter. To configure an interface for flow-based WRED, use the following commands in interface configuration mode: Command
Step 1 Step 2 Step 3
Router(config-if)# random-detect flow Router(config-if)# random-detect flow average-depth-factor scaling-factor Router(config-if)# random-detect flow count number

Purpose Enables flow-based WRED. Sets the flow threshold multiplier for flow-based WRED. Sets the maximum flow count for flow-based WRED.

DiffServ Compliant WRED Configuration Task List

To configure the DiffServ Compliant Weighted Random Early Detection feature, perform the tasks described in the following sections. The task in the first section is required; the task in the remaining section is optional.

Configuring WRED to Use the Differentiated Services Code Point Value (Required) Verifying the DSCP Value Configuration (Optional)

See the end of this chapter for the section DiffServ Compliant WRED Configuration Examples.

Configuring WRED to Use the Differentiated Services Code Point Value

The commands used to configure WRED to use the differentiated services code point (DSCP) value vary according to whether WRED is used at the interface level, the per-VC level, or the class level.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-190

Configuring Weighted Random Early Detection DiffServ Compliant WRED Configuration Task List

WRED at the Interface Level

To configure WRED to use the DSCP value when it calculates the drop probability, use the following commands in interface configuration mode: Command
Step 1
Router(config-if)# random-detect dscp-based

Purpose Indicates that WRED is to use the DSCP value when it calculates the drop probability for the packet. Specifies the minimum and maximum thresholds, and, optionally, the mark-probability denominator for the specified DSCP value.

Step 2

Router(config-if)# random-detect dscp dscpvalue min-threshold max-threshold [mark-probability-denominator]

WRED at the per-VC Level

To configure WRED to use the DSCP value when it calculates the drop probability, use the following commands beginning in global configuration mode: Command
Step 1
Router(config)# random-detect-group group-name dscp-based

Purpose Indicates that WRED is to use the DSCP value when it calculates the drop probability for the packet. Specifies the DSCP value, the minimum and maximum packet thresholds and, optionally, the mark-probability denominator for the DSCP value. Enables per-VC WRED or per-VC VIP-DWRED.

Step 2

Router(cfg-red-grp)# dscp dscpvalue min-threshold max-threshold [mark-probability-denominator]

Step 3

Router(config-atm-vc)# random-detect [attach group-name]

WRED at the Class Level

To configure WRED to use the DSCP value when it calculates the drop probability, use the following commands beginning in interface configuration mode. These are the commands to use at the class level, within policy maps. Command
Step 1 Step 2
Router(config-if)# class-map class-map-name

Purpose Creates a class map to be used for matching packets to a specified class. Configures the match criteria for a class map. For more information about match criteria, see the section Creating a Traffic Class in the chapter Configuring the Modular Quality of Service Command-Line Interface in this book. Creates or modifies a policy map that can be attached to one or more interfaces to specify a traffic policy. Specifies the QoS actions for the default class.

Router(config-cmap)# match match criterion

Step 3

Router(config-if)# policy-map policy-map

Step 4

Router(config-pmap)# class class-map-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-191

Configuring Weighted Random Early Detection WRED Configuration Examples

Command
Step 5 Step 6
Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent} Router(config-pmap-c)# random-detect dscp-based

Purpose Specifies or modifies the bandwidth allocated for a class belonging to a policy map. Indicates that WRED is to use the DSCP value when it calculates the drop probability for the packet. Specifies the minimum and maximum packet thresholds and, optionally, the mark-probability denominator for the DSCP value. Attaches a policy map to an output interface or VC to be used as the traffic policy for that interface or VC.

Step 7

Router(config-pmap-c)# random-detect dscp dscpvalue min-threshold max-threshold [mark-probability-denominator] Router(config-if)# service-policy output policy-map

Step 8

Verifying the DSCP Value Configuration

To verify the DSCP value configuration, use the following commands in global configuration mode, as needed: Command
Router# show queueing interface

Purpose Displays the queueing statistics of an interface or VC. Displays the configuration of classes configured for traffic policies on the specified interface or permanent virtual circuit (PVC).

Router# show policy-map interface

WRED Configuration Examples

The following sections provide WRED and DWRED configuration examples:

WRED Configuration Example Parameter-Setting DWRED Example Parameter-Setting WRED Example

For information on how to configure WRED, see the section Weighted Random Early Detection Configuration Task List in this chapter.

WRED Configuration Example

The following example enables WRED with default parameter values:
interface Serial5/0 description to qos1-75a ip address 200.200.14.250 255.255.255.252 random-detect

Use the show interfaces command output to verify the configuration. Notice that the Queueing strategy report lists random early detection (RED).

Cisco IOS Quality of Service Solutions Configuration Guide

QC-192

Configuring Weighted Random Early Detection WRED Configuration Examples

Router# show interfaces serial 5/0 Serial5/0 is up, line protocol is up Hardware is M4T Description: to qos1-75a Internet address is 200.200.14.250/30 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 237/255 Encapsulation HDLC, crc 16, loopback not set Keepalive not set Last input 00:00:15, output 00:00:00, output hang never Last clearing of "show interface" counters 00:05:08 Input queue: 0/75/0 (size/max/drops); Total output drops: 1036 Queueing strategy: random early detection(RED) 5 minutes input rate 0 bits/sec, 2 packets/sec 5 minutes output rate 119000 bits/sec, 126 packets/sec 594 packets input, 37115 bytes, 0 no buffer Received 5 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 37525 packets output, 4428684 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

Use the show queue command output to view the current contents of the interface queue. Notice that there is only a single queue into which packets from all IP precedences are placed after dropping has taken place. The output has been truncated to show only three of the five packets.
Router# show queue serial 5/0 Output queue for Serial5/0 is 5/0 Packet 1, linktype: ip, length: 118, flags: 0x288 source: 190.1.3.4, destination: 190.1.2.2, id: 0x0001, ttl: 254, TOS: 128 prot: 17, source port 11111, destination port 22222 data: 0x2B67 0x56CE 0x005E 0xE89A 0xCBA9 0x8765 0x4321 0x0FED 0xCBA9 0x8765 0x4321 0x0FED 0xCBA9 0x8765 Packet 2, linktype: ip, length: 118, flags: 0x288 source: 190.1.3.5, destination: 190.1.2.2, id: 0x0001, ttl: 254, TOS: 160 prot: 17, source port 11111, destination port 22222 data: 0x2B67 0x56CE 0x005E 0xE89A 0xCBA9 0x8765 0x4321 0x0FED 0xCBA9 0x8765 0x4321 0x0FED 0xCBA9 0x8765 Packet 3, linktype: ip, length: 118, flags: 0x280 source: 190.1.3.6, destination: 190.1.2.2, id: 0x0001, ttl: 254, TOS: 192 prot: 17, source port 11111, destination port 22222 data: 0x2B67 0x56CE 0x005E 0xE89A 0xCBA9 0x8765 0x4321 0x0FED 0xCBA9 0x8765 0x4321 0x0FED 0xCBA9 0x8765

Use the show queueing command output to view the current settings for each of the precedences. Also notice that the default minimum thresholds are spaced evenly between half and the entire maximum threshold. Thresholds are specified in terms of packet count.
Router# show queueing Current random-detect configuration: Serial5/0 Queueing strategy:random early detection (WRED) Exp-weight-constant:9 (1/512) Mean queue depth:28

Cisco IOS Quality of Service Solutions Configuration Guide

QC-193

Configuring Weighted Random Early Detection WRED Configuration Examples

Class 0 1 2 3 4 5 6 7 rsvp

Random drop 330 267 217 156 61 6 0 0 0

Tail drop 0 0 0 0 0 0 0 0 0

Minimum threshold 20 22 24 26 28 31 33 35 37

Maximum threshold 40 40 40 40 40 40 40 40 40

Mark probability 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10

Parameter-Setting DWRED Example

The following example specifies the same parameters for each IP precedence. Thus, all IP precedences receive the same treatment. Start by enabling DWRED.
interface FastEthernet1/0/0 ip address 200.200.14.250 255.255.255.252 random-detect

Next, enter the show queueing random-detect command to determine reasonable values to use for the precedence-specific parameters.
Router# show queueing random-detect Current random-detect configuration: FastEthernet2/0/0 Queueing strategy:fifo Packet drop strategy:VIP-based random early detection (DWRED) Exp-weight-constant:9 (1/512) Mean queue depth:0 Queue size:0 Maximum available buffers:6308 Output packets:5 WRED drops:0 No buffer:0 Class 0 1 2 3 4 5 6 7 Random drop 0 0 0 0 0 0 0 0 Tail drop 0 0 0 0 0 0 0 0 Minimum threshold 109 122 135 148 161 174 187 200 Maximum threshold 218 218 218 218 218 218 218 218 Mark probability 1/10 1/10 1/10 1/10 1/10 1/10 1/10 1/10 Output Packets 5 0 0 0 0 0 0 0

Complete the configuration by assigning the same parameter values to each precedence. Use the values obtained from the show queueing random-detect command output to choose reasonable parameter values.
interface FastEthernet1/0/0 random-detect precedence 0 random-detect precedence 1 random-detect precedence 2 random-detect precedence 3 random-detect precedence 4 random-detect precedence 5 random-detect precedence 6 random-detect precedence 7 100 100 100 100 100 100 100 100 218 218 218 218 218 218 218 218 10 10 10 10 10 10 10 10

Cisco IOS Quality of Service Solutions Configuration Guide

QC-194

Configuring Weighted Random Early Detection DWRED Configuration Examples

Parameter-Setting WRED Example

The following example enables WRED on the interface and specifies parameters for the different IP precedences:
interface Hssi0/0/0 description 45Mbps to R1 ip address 10.200.14.250 random-detect random-detect precedence random-detect precedence random-detect precedence random-detect precedence random-detect precedence random-detect precedence random-detect precedence random-detect precedence random-detect precedence

255.255.255.252 0 32 256 100 1 64 256 100 2 96 256 100 3 120 256 100 4 140 256 100 5 170 256 100 6 290 256 100 7 210 256 100 rsvp 230 256 100

DWRED Configuration Examples

The following sections provide DWRED configuration examples:

DWRED on an Interface Example Modular QoS CLI Example Configuring DWRED in Traffic Policy Example

For information on how to configure DWRED, see the section DWRED Configuration Task List in this chapter.

DWRED on an Interface Example

The following example configures DWRED on an interface with a weight factor of 10:
Router(config)# interface hssi0/0/0 Router(config-if)# description 45mbps to R1 Router(config-if)# ip address 192.168.14.250 255.255.255.252 Router(config-if)# random-detect Router(config-if)# random-detect exponential-weighting-constant 10

Modular QoS CLI Example

The following example enables DWRED using the Legacy CLI (non-Modular QoS Command-Line Interface) feature on the interface and specifies parameters for the different IP precedences:
interface Hssi0/0/0 description 45Mbps to R1 ip address 200.200.14.250 255.255.255.252 random-detect random-detect precedence 0 32 256 100 random-detect precedence 1 64 256 100 random-detect precedence 2 96 256 100 random-detect precedence 3 120 256 100 random-detect precedence 4 140 256 100 random-detect precedence 5 170 256 100

Cisco IOS Quality of Service Solutions Configuration Guide

QC-195

Configuring Weighted Random Early Detection Flow-Based WRED Configuration Example

random-detect precedence 6 290 256 100 random-detect precedence 7 210 256 100 random-detect precedence rsvp 230 256 100

The following example uses the Modular QoS CLI to configure a traffic policy called policy10. For congestion avoidance, WRED packet drop is used, not tail drop. IP Precedence is reset for levels 0 through 5.
policy-map policy10 class acl10 bandwidth 2000 random-detect exponential-weighting-constant 10 random-detect precedence 0 32 256 100 random-detect precedence 1 64 256 100 random-detect precedence 2 96 256 100 random-detect precedence 3 120 256 100 random-detect precedence 4 140 256 100 random-detect precedence 5 170 256 100

Configuring DWRED in Traffic Policy Example

The following example configures policy for a traffic class named int10 to configure the exponential weight factor as 12. This is the weight factor used for the average queue size calculation for the queue for traffic class int10. WRED packet drop is used for congestion avoidance for traffic class int10, not tail drop.
policy-map policy12 class int10 bandwidth 2000 random-detect exponential-weighting-constant 12

Flow-Based WRED Configuration Example

The following example enables WRED on the serial interface 1 and configures flow-based WRED. The random-detect interface configuration command is used to enable WRED. Once WRED is enabled, the random-detect flow command is used to enable flow-based WRED. After flow-based WRED is enabled, the random-detect flow average-depth-factor command is used to set the scaling factor to 8 and the random-detect flow count command is used to set the flow count to 16. The scaling factor is used to scale the number of buffers available per flow and to determine the number of packets allowed in the output queue for each active flow.
configure terminal interface Serial1 random-detect random-detect flow random-detect flow average-depth-factor 8 random-detect flow count 16 end

The following part of the example shows a sample configuration file after the previous flow-based WRED commands are issued:
Router# more system:running-config Building configuration... Current configuration: !

Cisco IOS Quality of Service Solutions Configuration Guide

QC-196

Configuring Weighted Random Early Detection Flow-Based WRED Configuration Example

version 12.0 service timestamps debug datetime msec localtime service timestamps log uptime no service password-encryption service tcp-small-servers ! no logging console enable password lab ! clock timezone PST -8 clock summer-time PDT recurring ip subnet-zero no ip domain-lookup ! interface Ethernet0 no ip address no ip directed-broadcast no ip mroute-cache shutdown ! interface Serial0 no ip address no ip directed-broadcast no ip mroute-cache no keepalive shutdown ! interface Serial1 ip address 190.1.2.1 255.255.255.0 no ip directed-broadcast load-interval 30 no keepalive random-detect random-detect flow random-detect flow count 16 random-detect flow average-depth-factor 8 ! router igrp 8 network 190.1.0.0 ! ip classless no ip http server ! line con 0 transport input none line 1 16 transport input all line aux 0 transport input all line vty 0 4 password lab login ! end

Cisco IOS Quality of Service Solutions Configuration Guide

QC-197

Configuring Weighted Random Early Detection DiffServ Compliant WRED Configuration Examples

DiffServ Compliant WRED Configuration Examples

This following sections provide DiffServ Compliant WRED configuration examples:

WRED Configured to Use the DSCP Value Example DSCP Value Configuration Verification Example

For information on how to configure DiffServ compliant WRED, see the section DiffServ Compliant WRED Configuration Task List in this chapter.

WRED Configured to Use the DSCP Value Example

The following example configures WRED to use the DSCP value 8. The minimum threshold for the DSCP value 8 is 24 and the maximum threshold is 40. This configuration was performed at the interface level.
Router(config-if)# interface seo/0 Router(config-if)# random-detect dscp-based Router(config-if)# random-detect dscp 8 24 40

The following example enables WRED to use the DSCP value 9. The minimum threshold for the DSCP value 9 is 20 and the maximum threshold is 50. This configuration can be attached to other VCs, as required.
Router(config)# random-detect-group sanjose dscp-based Router(cfg-red-grp)# dscp 9 20 50 Router(config-subif-vc)# random-detect attach sanjose

The following example enables WRED to use the DSCP value 8 for the class c1. The minimum threshold for the DSCP value 8 is 24 and the maximum threshold is 40. The last line attaches the traffic policy to the output interface or VC p1.
Router(config-if)# class-map c1 Router(config-cmap)# match access-group 101 Router(config-if)# policy-map p1 Router(config-pmap)# class c1 Router(config-pmap-c)# bandwidth 48 Router(config-pmap-c)# random-detect dscp-based Router(config-pmap-c)# random-detect dscp 8 24 40 Router(config-if)# service-policy output p1

Cisco IOS Quality of Service Solutions Configuration Guide

QC-198

Configuring Weighted Random Early Detection DiffServ Compliant WRED Configuration Examples

DSCP Value Configuration Verification Example

When WRED has been configured to use the DSCP value when it calculates the drop probability of a packet, all entries of the DSCP table are initialized with the appropriate default values. The example in the following section are samples of the show policy interface command for WRED at the class level. This example displays packet statistics along with the entries of the DSCP table, confirming that WRED has been enabled to use the DSCP value when it calculates the drop probability for a packet.
Router# show policy interface Serial6/3 Serial6/3 Service-policy output: test Class-map: c1 (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol ip 0 packets, 0 bytes 5 minute rate 0 bps Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 20 (%) Bandwidth 308 (kbps) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 exponential weight: 9 mean queue depth: 0 dscp af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs1 cs2 cs3 cs4 cs5 cs6 cs7 ef rsvp default Transmitted pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 Random drop pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 Tail drop pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 Minimum Maximum Mark thresh thresh prob 32 40 1/10 28 40 1/10 24 40 1/10 32 40 1/10 28 40 1/10 24 40 1/10 32 40 1/10 28 40 1/10 24 40 1/10 32 40 1/10 28 40 1/10 24 40 1/10 22 40 1/10 24 40 1/10 26 40 1/10 28 40 1/10 30 40 1/10 32 40 1/10 34 40 1/10 36 40 1/10 36 40 1/10 20 40 1/10

Cisco IOS Quality of Service Solutions Configuration Guide

QC-199

Configuring Weighted Random Early Detection DiffServ Compliant WRED Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-200

Policing and Shaping

Policing and Shaping Overview

Cisco IOS QoS offers two kinds of traffic regulation mechanismspolicing and shaping. The rate-limiting features of committed access rate (CAR) and the Traffic Policing feature provide the functionality for policing traffic. The features of Generic Traffic Shaping (GTS), Class-Based Shaping, Distributed Traffic Shaping (DTS), and Frame Relay Traffic Shaping (FRTS) provide the functionality for shaping traffic. You can deploy these features throughout your network to ensure that a packet, or data source, adheres to a stipulated contract and to determine the QoS to render the packet. Both policing and shaping mechanisms use the traffic descriptor for a packetindicated by the classification of the packetto ensure adherence and service. (See the chapter Classification Overview in this book for a description of a traffic descriptor.) Policers and shapers usually identify traffic descriptor violations in an identical manner. They usually differ, however, in the way they respond to violations, for example:

A policer typically drops traffic. (For example, the CAR rate-limiting policer will either drop the packet or rewrite its IP precedence, resetting the type of service bits in the packet header.) A shaper typically delays excess traffic using a buffer, or queueing mechanism, to hold packets and shape the flow when the data rate of the source is higher than expected. (For example, GTS and Class-Based Shaping use a weighted fair queue to delay packets in order to shape the flow, and DTS and FRTS use either a priority queue, a custom queue, or a FIFO queue for the same, depending on how you configure it.)

Traffic shaping and policing can work in tandem. For example, a good traffic shaping scheme should make it easy for nodes inside the network to detect misbehaving flows. This activity is sometimes called policing the traffic of the flow. This chapter gives a brief description of the Cisco IOS QoS traffic policing and shaping mechanisms. Because policing and shaping all use the token bucket mechanism, this chapter first explains how a token bucket works. This chapter includes the following sections:

What Is a Token Bucket? Policing with CAR Traffic Policing Traffic Shaping

Cisco IOS Quality of Service Solutions Configuration Guide

QC-203

Policing and Shaping Overview What Is a Token Bucket?

What Is a Token Bucket?

A token bucket is a formal definition of a rate of transfer. It has three components: a burst size, a mean rate, and a time interval (Tc). Although the mean rate is generally represented as bits per second, any two values may be derived from the third by the relation shown as follows:
mean rate = burst size / time interval

Here are some definitions of these terms:

Mean rateAlso called the committed information rate (CIR), it specifies how much data can be sent or forwarded per unit time on average. Burst sizeAlso called the Committed Burst (Bc) size, it specifies in bits (or bytes) per burst how much traffic can be sent within a given unit of time to not create scheduling concerns. (For a shaper, such as GTS, it specifies bits per burst; for a policer, such as CAR, it specifies bytes per burst.) Time intervalAlso called the measurement interval, it specifies the time quantum in seconds per burst.

By definition, over any integral multiple of the interval, the bit rate of the interface will not exceed the mean rate. The bit rate, however, may be arbitrarily fast within the interval. A token bucket is used to manage a device that regulates the data in a flow. For example, the regulator might be a traffic policer, such as CAR, or a traffic shaper, such as FRTS or GTS. A token bucket itself has no discard or priority policy. Rather, a token bucket discards tokens and leaves to the flow the problem of managing its transmission queue if the flow overdrives the regulator. (Neither CAR nor FRTS and GTS implement either a true token bucket or true leaky bucket.) In the token bucket metaphor, tokens are put into the bucket at a certain rate. The bucket itself has a specified capacity. If the bucket fills to capacity, newly arriving tokens are discarded. Each token is permission for the source to send a certain number of bits into the network. To send a packet, the regulator must remove from the bucket a number of tokens equal in representation to the packet size. If not enough tokens are in the bucket to send a packet, the packet either waits until the bucket has enough tokens (in the case of GTS) or the packet is discarded or marked down (in the case of CAR). If the bucket is already full of tokens, incoming tokens overflow and are not available to future packets. Thus, at any time, the largest burst a source can send into the network is roughly proportional to the size of the bucket. Note that the token bucket mechanism used for traffic shaping has both a token bucket and a data buffer, or queue; if it did not have a data buffer, it would be a policer. For traffic shaping, packets that arrive that cannot be sent immediately are delayed in the data buffer. For traffic shaping, a token bucket permits burstiness but bounds it. It guarantees that the burstiness is bounded so that the flow will never send faster than the capacity of the token bucket plus the time interval multiplied by the established rate at which tokens are placed in the bucket. It also guarantees that the long-term transmission rate will not exceed the established rate at which tokens are placed in the bucket.

Policing with CAR

CAR embodies a rate-limiting feature for policing traffic, in addition to its packet classification feature discussed in the chapter Classification Overview in this book. The rate-limiting feature of CAR manages the access bandwidth policy for a network by ensuring that traffic falling within specified rate parameters is sent, while dropping packets that exceed the acceptable amount of traffic or sending them with a different priority. The exceed action for CAR is to drop or mark down packets.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-204

Policing and Shaping Overview Policing with CAR

The rate-limiting function of CAR does the following:

Allows you to control the maximum rate of traffic sent or received on an interface. Gives you the ability to define Layer 3 aggregate or granular incoming or outgoing (ingress or egress) bandwidth rate limits and to specify traffic handling policies when the traffic either conforms to or exceeds the specified rate limits. Aggregate bandwidth rate limits match all of the packets on an interface or subinterface. Granular bandwidth rate limits match a particular type of traffic based on precedence, MAC address, or other parameters.

CAR is often configured on interfaces at the edge of a network to limit traffic into or out of the network.

How It Works
CAR examines traffic received on an interface or a subset of that traffic selected by access list criteria. It then compares the rate of the traffic to a configured token bucket and takes action based on the result. For example, CAR will drop the packet or rewrite the IP precedence by resetting the type of service (ToS) bits. You can configure CAR to send, drop, or set precedence. Aspects of CAR rate limiting are explained in the following sections:

Matching Criteria Rate Limits Conform and Exceed Actions Multiple Rate Policies

CAR utilizes a token bucket measurement. Tokens are inserted into the bucket at the committed rate. The depth of the bucket is the burst size. Traffic arriving at the bucket when sufficient tokens are available is said to conform, and the corresponding number of tokens are removed from the bucket. If a sufficient number of tokens are not available, then the traffic is said to exceed.

Matching Criteria
Traffic matching entails identification of traffic of interest for rate limiting, precedence setting, or both. Rate policies can be associated with one of the following qualities:

Incoming interface All IP traffic IP precedence (defined by a rate-limit access list) MAC address (defined by a rate-limit access list) IP access list (standard and extended)

CAR provides configurable actions, such as send, drop, or set precedence when traffic conforms to or exceeds the rate limit.

Note

Matching to IP access lists is more processor-intensive than matching based on other criteria.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-205

Policing and Shaping Overview Policing with CAR

Rate Limits
CAR propagates bursts. It does no smoothing or shaping of traffic, and therefore does no buffering and adds no delay. CAR is highly optimized to run on high-speed linksDS3, for examplein distributed mode on Versatile Interface Processors (VIPs) on the Cisco 7500 series. CAR rate limits may be implemented either on input or output interfaces or subinterfaces including Frame Relay and ATM subinterfaces.

What Rate Limits Define

Rate limits define which packets conform to or exceed the defined rate based on the following three parameters:

Average rate. The average rate determines the long-term average transmission rate. Traffic that falls under this rate will always conform. Normal burst size. The normal burst size determines how large traffic bursts can be before some traffic exceeds the rate limit. Excess Burst size. The Excess Burst (Be) size determines how large traffic bursts can be before all traffic exceeds the rate limit. Traffic that falls between the normal burst size and the Excess Burst size exceeds the rate limit with a probability that increases as the burst size increases.

The tokens in a token bucket are replenished at regular intervals, in accordance with the configured committed rate. The maximum number of tokens a bucket can ever contain is determined by the normal burst size configured for the token bucket. When the CAR rate limit is applied to a packet, CAR removes from the bucket tokens that are equivalent in number to the byte size of the packet. If a packet arrives and the byte size of the packet is greater than the number of tokens available in the standard token bucket, extended burst capability is engaged if it is configured.

Extended Burst Value

Extended burst is configured by setting the extended burst value greater than the normal burst value. Setting the extended burst value equal to the normal burst value excludes the extended burst capability. If extended burst is not configured, given the example scenario, the exceed action of CAR takes effect because a sufficient number of tokens are not available. When extended burst is configured and this scenario occurs, the flow is allowed to borrow the needed tokens to allow the packet to be sent. This capability exists so as to avoid tail-drop behavior, and, instead, engage behavior like that of Random Early Detection (RED).

How Extended Burst Capability Works

Here is how the extended burst capability works. If a packet arrives and needs to borrow n number of tokens because the token bucket contains fewer tokens than its packet size requires, then CAR compares the following two values:

Extended burst parameter value. Compounded debt. Compounded debt is computed as the sum over all ai:
a indicates the actual debt value of the flow after packet i is sent. Actual debt is simply a count

of how many tokens the flow has currently borrowed.

i indicates the ith packet that attempts to borrow tokens since the last time a packet was dropped.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-206

Policing and Shaping Overview Policing with CAR

If the compounded debt is greater than the extended burst value, the exceed action of CAR takes effect. After a packet is dropped, the compounded debt is effectively set to 0. CAR will compute a new compounded debt value equal to the actual debt for the next packet that needs to borrow tokens. If the actual debt is greater than the extended limit, all packets will be dropped until the actual debt is reduced through accumulation of tokens in the token bucket. Dropped packets do not count against any rate or burst limit. That is, when a packet is dropped, no tokens are removed from the token bucket.

Note

Though it is true the entire compounded debt is forgiven when a packet is dropped, the actual debt is not forgiven, and the next packet to arrive to insufficient tokens is immediately assigned a new compounded debt value equal to the current actual debt. In this way, actual debt can continue to grow until it is so large that no compounding is needed to cause a packet to be dropped. In effect, at this time, the compounded debt is not really forgiven. This scenario would lead to excessive drops on streams that continually exceed normal burst. (See the example in the following section, Actual and Compounded Debt Example. Testing of TCP traffic suggests that the chosen normal and extended burst values should be on the order of several seconds worth of traffic at the configured average rate. That is, if the average rate is 10 Mbps, then a normal burst size of 10 to 20 Mbps and an Excess Burst size of 20 to 40 Mbps would be appropriate.

Recommended Burst Values

Cisco recommends the following values for the normal and extended burst parameters:
normal burst = configured rate * (1 byte)/(8 bits) * 1.5 seconds extended burst = 2 * normal burst

With the listed choices for parameters, extensive test results have shown CAR to achieve the configured rate. If the burst values are too low, then the achieved rate is often much lower than the configured rate.

Actual and Compounded Debt Example

This example shows how the compounded debt is forgiven, but the actual debt accumulates. For this example, assume the following parameters:

Token rate is 1 data unit per time unit Normal burst size is 2 data units Extended burst size is 4 data units 2 data units arrive per time unit

After 2 time units, the stream has used up its normal burst and must begin borrowing one data unit per time unit, beginning at time unit 3:
Time DU arrivals Actual Debt Compounded Debt ------------------------------------------------------1 2 0 0 2 2 0 0 3 2 1 1 4 2 2 3 5 2 3 (temporary) 6 (temporary)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-207

Policing and Shaping Overview Policing with CAR

At this time a packet is dropped because the new compounded debt (6) would exceed the extended burst limit (4). When the packet is dropped, the compounded debt effectively becomes 0, and the actual debt is 2. (The values 3 and 6 were only temporary and do not remain valid in the case where a packet is dropped.) The final values for time unit 5 follow. The stream begins borrowing again at time unit 6.
Time DU arrivals Actual Debt Compounded Debt ------------------------------------------------------5 2 2 0 6 2 3 3 7 2 4 (temporary) 7 (temporary)

At time unit 6, another packet is dropped and the debt values are adjusted accordingly.
Time DU arrivals Actual Debt Compounded Debt ------------------------------------------------------7 2 3 0

Conform and Exceed Actions

CAR utilizes a token bucket, thus CAR can pass temporary bursts that exceed the rate limit as long as tokens are available. Once a packet has been classified as conforming to or exceeding a particular rate limit, the router performs one of the following actions on the packet:

TransmitThe packet is sent. DropThe packet is discarded. Set precedence and transmitThe IP Precedence (ToS) bits in the packet header are rewritten. The packet is then sent. You can use this action to either color (set precedence) or recolor (modify existing packet precedence) the packet. ContinueThe packet is evaluated using the next rate policy in a chain of rate limits. If there is not another rate policy, the packet is sent. Set precedence and continueSet the IP Precedence bits to a specified value and then evaluate the next rate policy in the chain of rate limits.

For VIP-based platforms, two more actions are possible:

Set QoS group and transmitThe packet is assigned to a QoS group and sent. Set QoS group and continueThe packet is assigned to a QoS group and then evaluated using the next rate policy. If there is not another rate policy, the packet is sent.

Multiple Rate Policies

A single CAR rate policy includes information about the rate limit, conform actions, and exceed actions. Each interface can have multiple CAR rate policies corresponding to different types of traffic. For example, low priority traffic may be limited to a lower rate than high priority traffic. When there are multiple rate policies, the router examines each policy in the order entered until the packet matches. If no match is found, the default action is to send. Rate policies can be independent: each rate policy deals with a different type of traffic. Alternatively, rate policies can be cascading: a packet may be compared to multiple different rate policies in succession. Cascading of rate policies allows a series of rate limits to be applied to packets to specify more granular policies (for example, you could rate limit total traffic on an access link to a specified subrate bandwidth and then rate limit World Wide Web traffic on the same link to a given proportion of the subrate limit)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-208

Policing and Shaping Overview Traffic Policing

or to match packets against an ordered sequence of policies until an applicable rate limit is encountered (for example, rate limiting several MAC addresses with different bandwidth allocations at an exchange point). You can configure up to a 100 rate policies on a subinterface.

Restrictions
CAR and VIP-distributed CAR can only be used with IP traffic. Non-IP traffic is not rate limited. CAR or VIP-distributed CAR can be configured on an interface or subinterface. However, CAR and VIP-distributed CAR are not supported on the following interfaces:

Fast EtherChannel Tunnel PRI Any interface that does not support Cisco Express Forwarding (CEF)

CAR is only supported on ATM subinterfaces with the following encapsulations: aal5snap, aal5mux, and aal5nlpid.

Note

CAR provides rate limiting and does not guarantee bandwidth. CAR should be used with other QoS features, such as distributed weighted fair queueing (WFQ) (DWFQ), if premium bandwidth assurances are required.

Traffic Policing
Traffic policing allows you to control the maximum rate of traffic sent or received on an interface, and to partition a network into multiple priority levels or class of service (CoS). The Traffic Policing feature manages the maximum rate of traffic through a token bucket algorithm. The token bucket algorithm can use the user-configured values to determine the maximum rate of traffic allowed on an interface at a given moment in time. The token bucket algorithm is affected by all traffic entering or leaving (depending on where the traffic policy with Traffic Policing configured) and is useful in managing network bandwidth in cases where several large packets are sent in the same traffic stream. The token bucket algorithm provides users with three actions for each packet: a conform action, an exceed action, and an optional violate action. Traffic entering the interface with Traffic Policing configured is placed in to one of these categories. Within these three categories, users can decide packet treatments. For instance, packets that conform can be configured to be transmitted, packets that exceed can be configured to be sent with a decreased priority, and packets that violate can be configured to be dropped. Traffic Policing is often configured on interfaces at the edge of a network to limit the rate of traffic entering or leaving the network. In the most common Traffic Policing configurations, traffic that conforms is transmitted and traffic that exceeds is sent with a decreased priority or is dropped. Users can change these configuration options to suit their network needs. The Traffic Policing feature supports the following MIBs:

CISCO-CLASS-BASED-QOS-MIB CISCO-CLASS-BASED-QOS-CAPABILITY-MIB

This feature also supports RFC 2697, A Single Rate Three Color Marker.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-209

Policing and Shaping Overview Traffic Policing

For information on how to configure the Traffic Policing feature, see the chapter Configuring Traffic Policing in this book.

Benefits
Bandwidth Management Through Rate Limiting
Traffic policing allows you to control the maximum rate of traffic sent or received on an interface. Traffic policing is often configured on interfaces at the edge of a network to limit traffic into or out of the network. Traffic that falls within the rate parameters is sent, whereas traffic that exceeds the parameters is dropped or sent with a different priority.

Packet Marking Through IP Precedence, QoS Group, and DSCP Value Setting
Packet marking allows you to partition your network into multiple priority levels or classes of service (CoS), as follows:

Use traffic policing to set the IP precedence or differentiated services code point (DSCP) values for packets entering the network. Networking devices within your network can then use the adjusted IP Precedence values to determine how the traffic should be treated. For example, the DWRED feature uses the IP Precedence values to determine the probability that a packet will be dropped. Use traffic policing to assign packets to a QoS group. The router uses the QoS group to determine how to prioritize packets.

Restrictions
The following restrictions apply to the Traffic Policing feature:

On a Cisco 7500 series router, traffic policing can monitor CEF switching paths only. In order to use the Traffic Policing feature, CEF must be configured on both the interface receiving the packet and the interface sending the packet. On a Cisco 7500 series router, traffic policing cannot be applied to packets that originated from or are destined to a router. Traffic policing can be configured on an interface or a subinterface. Traffic policing is not supported on the following interfaces:
Fast EtherChannel Tunnel PRI Any interface on a Cisco 7500 series router that does not support CEF

Prerequisites
On a Cisco 7500 series router, CEF must be configured on the interface before traffic policing can be used. For additional information on CEF, refer to the Cisco IOS Switching Services Configuration Guide.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-210

Policing and Shaping Overview Traffic Shaping

Traffic Shaping
Cisco IOS QoS software has three types of traffic shaping: GTS, class-based, and FRTS. All three of these traffic shaping methods are similar in implementation, though their CLIs differ somewhat and they use different types of queues to contain and shape traffic that is deferred. In particular, the underlying code that determines whether enough credit is in the token bucket for a packet to be sent or whether that packet must be delayed is common to both features. If a packet is deferred, GTS and Class-Based Shaping use a weighted fair queue to hold the delayed traffic. FRTS uses either a custom queue or a priority queue for the same, depending on what you have configured. This section explains how traffic shaping works, then it describes the Cisco IOS QoS traffic shaping mechanisms. It includes the following sections:

About Traffic Shaping Generic Traffic Shaping Class-Based Shaping Distributed Traffic Shaping Frame Relay Traffic Shaping

For description of a token bucket and explanation of how it works, see the section What Is a Token Bucket? earlier in this chapter.

About Traffic Shaping

Traffic shaping allows you to control the traffic going out an interface in order to match its flow to the speed of the remote target interface and to ensure that the traffic conforms to policies contracted for it. Thus, traffic adhering to a particular profile can be shaped to meet downstream requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches.

Why Use Traffic Shaping?

The primary reasons you would use traffic shaping are to control access to available bandwidth, to ensure that traffic conforms to the policies established for it, and to regulate the flow of traffic in order to avoid congestion that can occur when the sent traffic exceeds the access speed of its remote, target interface. Here are some example reasons why you would use traffic shaping:

Control access to bandwidth when, for example, policy dictates that the rate of a given interface should not on the average exceed a certain rate even though the access rate exceeds the speed. Configure traffic shaping on an interface if you have a network with differing access rates. Suppose that one end of the link in a Frame Relay network runs at 256 kbps and the other end of the link runs at 128 kbps. Sending packets at 256 kbps could cause failure of the applications using the link. A similar, more complicated case would be a link-layer network giving indications of congestion that has differing access rates on different attached DTE; the network may be able to deliver more transit speed to a given DTE device at one time than another. (This scenario warrants that the token bucket be derived, and then its rate maintained.)

If you offer a subrate service. In this case, traffic shaping enables you to use the router to partition your T1 or T3 links into smaller channels.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-211

Policing and Shaping Overview Traffic Shaping

Traffic shaping prevents packet loss. Its use is especially important in Frame Relay networks because the switch cannot determine which packets take precedence, and therefore which packets should be dropped when congestion occurs. Moreover, it is of critical importance for real-time traffic such as Voice over Frame Relay that latency be bounded, thereby bounding the amount of traffic and traffic loss in the data link network at any given time by keeping the data in the router that is making the guarantees. Retaining the data in the router allows the router to prioritize traffic according to the guarantees it is making. (Packet loss can result in detrimental consequences for real-time and interactive applications.)

Traffic Shaping and Rate of Transfer

Traffic shaping limits the rate of transmission of data. You can limit the data transfer to one of the following:

A specific configured rate A derived rate based on the level of congestion

As mentioned, the rate of transfer depends on these three components that constitute the token bucket: burst size, mean rate, measurement (time) interval. The mean rate is equal to the burst size divided by the interval. When traffic shaping is enabled, the bit rate of the interface will not exceed the mean rate over any integral multiple of the interval. In other words, during every interval, a maximum of burst size can be sent. Within the interval, however, the bit rate may be faster than the mean rate at any given time. One additional variable applies to traffic shaping: Be size. The Excess Burst size corresponds to the number of noncommitted bitsthose outside the CIRthat are still accepted by the Frame Relay switch but marked as discard eligible (DE). In other words, the Be size allows more than the burst size to be sent during a time interval in certain situations. The switch will allow the packets belonging to the Excess Burst to go through but it will mark them by setting the DE bit. Whether the packets are sent depends on how the switch is configured. When the Be size equals 0, the interface sends no more than the burst size every interval, achieving an average rate no higher than the mean rate. However, when the Be size is greater than 0, the interface can send as many as Bc + Be bits in a burst, if in a previous time period the maximum amount was not sent. Whenever less than the burst size is sent during an interval, the remaining number of bits, up to the Be size, can be used to send more than the burst size in a later interval.

Discard Eligible Bit

You can specify which Frame Relay packets have low priority or low time sensitivity and will be the first to be dropped when a Frame Relay switch is congested. The mechanism that allows a Frame Relay switch to identify such packets is the DE bit. You can define DE lists that identify the characteristics of packets to be eligible for discarding, and you can also specify DE groups to identify the data-link connection identifier (DLCI) that is affected. You can specify DE lists based on the protocol or the interface, and on characteristics such as fragmentation of the packet, a specific TCP or User Datagram Protocol (UDP) port, an access list number, or a packet size.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-212

Policing and Shaping Overview Traffic Shaping

Differences Between Shaping Mechanisms

As mentioned, GTS, Class-Based Shaping, DTS, and FRTS are similar in implementation, sharing the same code and data structures, but they differ in regard to their CLIs and the queue types they use. Here are a few ways in which these mechanisms differ:

For GTS, the shaping queue is a weighted fair queue. For FRTS, the queue can be a weighted fair queue (configured by the frame-relay fair-queue command), a strict priority queue with WFQ (configured by the frame-relay ip rtp priority command in addition to the frame-relay fair-queue command), custom queueing (CQ), priority queueing (PQ), or FIFO. For Class-Based Shaping, GTS can be configured on a class, rather than only on an access control list (ACL). In order to do so, you must first define traffic classes based on match criteria including protocols, ACLs, and input interfaces. You can then apply traffic shaping to each defined class. FRTS supports shaping on a per-DLCI basis; GTS and DTS are configurable per interface or subinterface. DTS supports traffic shaping based on a variety of match criteria, including user-defined classes, and DSCP.

Table 11 summarizes these differences.

Table 11 Differences Between Shaping Mechanisms

Mechanism Command-Line Interface

GTS

Class-Based Applies parameters per subinterface traffic group command supported

DTS

FRTS Applies parameters per interface or subinterface

Applies parameters per interface or per class

Classes of parameters Applies parameters to all virtual circuits (VCs) on an interface through inheritance mechanism No traffic group command WFQ, strict priority queue with WFQ, CQ, PQ, FCFS per VC

Queues Supported

WFQ per subinterface

CBWFQ inside GTS

WFQ, strict priority queue with WFQ, CQ, PQ, first- come, first- served (FCFS) per VC

You can configure GTS to behave the same as FRTS by allocating one DLCI per subinterface and using GTS plus backward explicit congestion notification (BECN) support. The behavior of the two is then the same except for the different shaping queues used.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-213

Policing and Shaping Overview Traffic Shaping

Traffic Shaping and Queueing

Traffic shaping smooths traffic by storing traffic above the configured rate in a queue. When a packet arrives at the interface for transmission, the following sequence happens:
1.

If the queue is empty, the arriving packet is processed by the traffic shaper.
If possible, the traffic shaper sends the packet. Otherwise, the packet is placed in the queue.

2.

If the queue is not empty, the packet is placed in the queue.

When packets are in the queue, the traffic shaper removes the number of packets it can send from the queue every time interval.

Generic Traffic Shaping

GTS shapes traffic by reducing outbound traffic flow to avoid congestion by constraining traffic to a particular bit rate using the token bucket mechanism. (See the section What Is a Token Bucket? earlier in this chapter.) GTS applies on a per-interface basis and can use access lists to select the traffic to shape. It works with a variety of Layer 2 technologies, including Frame Relay, ATM, Switched Multimegabit Data Service (SMDS), and Ethernet. On a Frame Relay subinterface, GTS can be set up to adapt dynamically to available bandwidth by integrating backward explicit congestion notification (BECN) signals, or set up simply to shape to a specified rate. GTS can also be configured on an ATM/ATM Interface Processor (AIP) interface to respond to the Resource Reservation Protocol (RSVP) feature signalled over statically configured ATM permanent virtual circuits (PVCs). GTS is supported on most media and encapsulation types on the router. GTS can also be applied to a specific access list on an interface.

Note

GTS is not supported on Multilink PPP (MLP) interfaces. Figure 12 shows how GTS works.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-214

Policing and Shaping Overview Traffic Shaping

Figure 12

Generic Traffic Shaping

Token bucket Match

Incoming packets
Classify Configured rate

Transmit queue WFQ

Outgoing packets

No match

WFQ is the only supported queueing method

Classification by: extended access list functionality

For information on how to configure GTS, see the chapter Configuring Generic Traffic Shaping in this book.

Class-Based Shaping
Traffic shaping allows you to control the traffic going out an interface in order to match its transmission to the speed of the remote, target interface and to ensure that the traffic conforms to policies contracted for it. Traffic adhering to a particular profile can be shaped to meet downstream requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches. For information on how to configure Class-Based Shaping, see the chapter Configuring Class-Based Shaping in this book.

How It Works
Class-Based Shaping can be enabled on any interface that supports GTS. Using the Class-Based Shaping feature, you can perform the following tasks:

Configure GTS on a traffic class. Configuring GTS to classes provides greater flexibility for configuring traffic shaping. Previously, this ability was limited to the use of ACLs. Specify average rate or peak rate traffic shaping. Specifying peak rate shaping allows you to make better use of available bandwidth by allowing more data than the CIR to be sent if the bandwidth is available. Configure class-based weighted fair queueing (CBWFQ) inside GTS. CBWFQ allows you to specify the exact amount of bandwidth to be allocated for a specific class of traffic. Taking into account available bandwidth on the interface, you can configure up to 64 classes and control distribution among them, which is not the case with flow-based WFQ.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-215

16762

"Token bucket" shaping

Policing and Shaping Overview Traffic Shaping

Flow-based WFQ applies weights to traffic to classify it into conversations and determine how much bandwidth each conversation is allowed relative to other conversations. These weights, and traffic classification, are dependent on and limited to the seven IP Precedence levels. CBWFQ allows you to define what constitutes a class based on criteria that exceed the confines of flow. CBWFQ allows you to use ACLs and protocols or input interface names to define how traffic will be classified, thereby providing coarser granularity. You need not maintain traffic classification on a flow basis. Moreover, you can configure up to 64 discrete classes in a service policy.

Restrictions
Peak and average traffic shaping is configured on a per-interface or per-class basis, and cannot be used in conjunction with commands used to configure GTS from previous versions of Cisco IOS. These commands include the following:

traffic-shape adaptive traffic-shape fecn-adaptive traffic-shape group traffic-shape rate

Adaptive traffic shaping for Frame Relay networks is not supported using the Class-Based Shaping feature. To configure adaptive GTS for Frame Relay networks, you must use the commands from releases prior to Release 12.1(2) of Cisco IOS software.

Distributed Traffic Shaping

The DTS feature provides a method of managing the bandwidth of an interface to avoid congestion, to meet remote site requirements, and to conform to a service rate that is provided on that interface. DTS uses queues to buffer traffic surges that can congest a network and send the data in to the network at a regulated rate. This ensures that traffic will behave to the configured descriptor, as defined by the CIR, Bc, and Be. With the defined average bit rate and burst size that is acceptable on that shaped entity, you can derive a time interval value. The Be size allows more than the Bc size to be sent during a time interval under certain conditions. Therefore, DTS provides two types of shape commands: average and peak. When shape average is configured, the interface sends no more than the Bc size for each interval, achieving an average rate no higher than the CIR. When the shape peak command is configured, the interface sends Bc plus Be bits in each interval. In a link layer network such as Frame Relay, the network sends messages with the forward explicit congestion notification (FECN) or BECN if there is congestion. With the DTS feature, the traffic shaping adaptive mode takes advantage of these signals and adjusts the traffic descriptors, therefore regulating the amount of traffic entering or leaving the interface accordingly. DTS provides the following key benefits:

Offloads traffic shaping from the Route Switch Processor (RSP) to the VIP. Supports up to 200 shape queues per VIP, supporting up to OC-3 rates when the average packet size is 250 bytes or greater and when using a VIP2-50 or better with 8 MB of SRAM. Line rates below T3 are supported with a VIP2-40. Configures DTS at the interface level or subinterface level.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-216

Policing and Shaping Overview Traffic Shaping

Shaping based on the following traffic match criteria:

Access list Packet marking Input port Other matching criteria. For information about other matching criteria, see the section Creating

a Traffic Class in the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

Optional configuration to respond to Frame Relay network congestion (indicated by the presence of BECN or ForeSight signals) by reducing the shaped-to rate for a period of time until congestion is believed to have subsided. Supports FECN, BECN, and ForeSight Frame Relay signalling.

This feature runs on Cisco 7500 series routers with VIP2-40, VIP2-50, or greater. For information on how to configure DTS, see the chapter Configuring Distributed Traffic Shaping in this book.

Restrictions
DTS does not support the following:

Fast EtherChannel interfaces, Multilink PPP (MLP), tunnels and dialer interfaces

Note

Hierarchical DTS (that is, DTS configured in both a parent-level policy and a child-level policy), is not supported on subinterfaces.

Any VIP below a VIP2-40

Note

A VIP2-50 is strongly recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 card is required for OC-3 rates.

Prerequisites
Distributed Cisco Express Forwarding (dCEF) must be enabled on the interface before DTS can be enabled. A policy map and class maps must be created before DTS is enabled.

Frame Relay Traffic Shaping

Cisco has long provided support for FECN for DECnet and OSI, and BECN for Systems Network Architecture (SNA) traffic using Logical Link Control, type 2 (LLC2) encapsulation via RFC 1490 and DE bit support. FRTS builds upon this existing Frame Relay support with additional capabilities that improve the scalability and performance of a Frame Relay network, increasing the density of VCs and improving response time. As is also true of GTS, FRTS can eliminate bottlenecks in Frame Relay networks that have high-speed connections at the central site and low-speed connections at branch sites. You can configure rate enforcementa peak rate configured to limit outbound trafficto limit the rate at which data is sent on the VC at the central site.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-217

Policing and Shaping Overview Traffic Shaping

Using FRTS, you can configure rate enforcement to either the CIR or some other defined value such as the excess information rate on a per-VC basis. The ability to allow the transmission speed used by the router to be controlled by criteria other than line speed (that is, by the CIR or the excess information rate) provides a mechanism for sharing media by multiple VCs. You can allocate bandwidth to each VC, creating a virtual time-division multiplexing (TDM) network. You can also define PQ, CQ, and WFQ at the VC or subinterface level. Using these queueing methods allows for finer granularity in the prioritization and queueing of traffic, providing more control over the traffic flow on an individual VC. If you combine CQ with the per-VC queueing and rate enforcement capabilities, you enable Frame Relay VCs to carry multiple traffic types such as IP, SNA, and Internetwork Packet Exchange (IPX) with bandwidth guaranteed for each traffic type. Using information contained in the BECN-tagged packets received from the network, FRTS can also dynamically throttle traffic. With BECN-based throttling, packets are held in the buffers of the router to reduce the data flow from the router into the Frame Relay network. The throttling is done on a per-VC basis and the transmission rate is adjusted based on the number of BECN-tagged packets received. With the Cisco FRTS feature, you can integrate ATM ForeSight closed loop congestion control to actively adapt to downstream congestion conditions.

Derived Rates
In Frame Relay networks, BECNs and FECNs indicate congestion. BECN and FECN are specified by bits within a Frame Relay frame. FECNs are generated when data is sent out a congested interface; they indicate to a DTE device that congestion was encountered. Traffic is marked with BECN if the queue for the opposite direction is deep enough to trigger FECNs at the current time. BECNs notify the sender to decrease the transmission rate. If the traffic is one-way only (such as multicast traffic), there is no reverse traffic with BECNs to notify the sender to slow down. Thus, when a DTE device receives an FECN, it first determines if it is sending any data in return. If it is sending return data, this data will get marked with a BECN on its way to the other DTE device. However, if the DTE device is not sending any data, the DTE device can send a Q.922 TEST RESPONSE message with the BECN bit set. When an interface configured with traffic shaping receives a BECN, it immediately decreases its maximum rate by a large amount. If, after several intervals, the interface has not received another BECN and traffic is waiting in the queue, the maximum rate increases slightly. The dynamically adjusted maximum rate is called the derived rate. The derived rate will always be between the upper bound and the lower bound configured on the interface. For more information on configuring Frame Relay, refer to the Cisco IOS Wide-Area Networking Configuration Guide. For information on configuring Frame Relay as it relates to voice traffic, refer to the Cisco IOS Voice, Video, and Fax Configuration Guide.

Restrictions
FRTS applies only to Frame Relay PVCs and switched virtual circuits (SVCs).

Cisco IOS Quality of Service Solutions Configuration Guide

QC-218

Configuring Traffic Policing

This chapter describes the tasks for configuring the Traffic Policing feature. For complete conceptual information, see the section Traffic Policing in the Policing and Shaping Overview chapter of this book. For a complete description of the Traffic Policing commands mentioned in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Traffic Policing Configuration Task List

To configure the Traffic Policing feature, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining section are optional.

Configuring Traffic Policing (Required) Verifying the Traffic Policing Configuration (Optional) Monitoring and Maintaining Traffic Policing (Optional)

See the end of this chapter for the section Traffic Policing Configuration Examples.

Configuring Traffic Policing

To successfully configure the Traffic Policing feature, a traffic class and a traffic policy must be created, and the traffic policy must be attached to a specified interface. These tasks are performed using the Modular QoS Command-Line Interface (CLI). For information on the Modular QoS CLI, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-219

Configuring Traffic Policing Traffic Policing Configuration Task List

The Traffic Policing feature is configured in the traffic policy. To configure the Traffic Policing feature, use the following command in policy-map class configuration mode: Command
Router(config-pmap-c)# police bps burst-normal burst-max conform-action action exceed-action action violate-action action

Purpose Specifies a maximum bandwidth usage by a traffic class.The police command polices traffic based on a token bucket algorithm. The variables in the token bucket algorithm are set in this command line.

The command syntax of the police command allows you to specify the action to be taken on a packet when you enable the action keyword. The resulting action corresponding to the keyword choices are listed in Table 12.
Table 12 police Command Action Keywords

Keyword drop set-prec-transmit new-prec set-qos-transmit new-qos set-dscp-transmit new-dscp transmit

Resulting Action Drops the packet. Sets the IP precedence and sends the packet. Sets the QoS group and sends the packet. Sets the differentiated services code point (DSCP) value and sends the packet. Sends the packet.

For more information about the police command, refer to the Cisco IOS Quality of Service Solutions Command Reference. The Traffic Policing feature works with a token bucket mechanism. There are currently two types of token bucket algorithms: a single token bucket algorithm and a two token bucket algorithm. A single token bucket system is used when the violate-action option is not specified, and a two token bucket system is used when the violate-action option is specified. For a description of a single token bucket algorithm and an explanation of how it works, see the What Is a Token Bucket? section of thePolicing and Shaping Overview chapter of this book.

Verifying the Traffic Policing Configuration

To verify that the Traffic Policing feature is configured on your interface, use the following command in EXEC mode: Command
Router# show policy-map interface

Purpose Displays statistics and configurations of all input and output policies attached to an interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-220

Configuring Traffic Policing Traffic Policing Configuration Examples

Monitoring and Maintaining Traffic Policing

To monitor and maintain the Traffic Policing feature, use the following commands in EXEC mode, as needed: Command
Router# show policy-map Router# show policy-map policy-map-name Router# show policy-map interface

Purpose Displays all configured traffic policy. Displays the user-specified traffic policy. Displays statistics and configurations of all input and output policies attached to an interface.

Traffic Policing Configuration Examples

The following sections provide Traffic Policing configuration examples:

Traffic Policy that Includes Traffic Policing Example Verifying the Configuration Example

For information on how to configure the Traffic Policing feature, see the section Traffic Policing Configuration Task List in this chapter.

Traffic Policy that Includes Traffic Policing Example

The following configuration example shows how to define a traffic class (with the class-map command) and associate that traffic class with a traffic policy (with the policy-map command). Traffic policing is applied in the traffic policy. The service-policy command is then used to attach the traffic policy to the interface. For additional information on configuring traffic classes and traffic policies, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book. In this particular example, traffic policing is configured with the average rate at 8000 bits per second, the normal burst size at 2000 bytes, and the excess burst size at 4000 bytes. Packets coming into Fast Ethernet interface 0/0 are evaluated by the token bucket algorithm to analyze whether packets conform exceed, or violate the specified parameters. Packets that conform are sent, packets that exceed are assigned a QoS group value of 4 and are sent, and packets that violate are dropped. For a description of a token bucket and an explanation of how a token bucket works, see the What Is a Token Bucket? section of the Policing and Shaping Overview chapter of this book.
7200-uut(config)# class-map acgroup2 7200-uut(config-cmap)# match access-group 2 7200-uut(config-cmap)# exit 7200-uut(config)# policy-map police 7200-uut(config-pmap)# class acgroup2 7200-uut(config-pmap-c)# police 8000 2000 4000 conform-action transmit exceed-action set-qos-transmit 4 violate-action drop 7200-uut(config-pmap-c)# exit 7200-uut(config-pmap)# exit 7200-uut(config)# interface fastethernet 0/0 7200-uut(config-if)# service-policy input police

Cisco IOS Quality of Service Solutions Configuration Guide

QC-221

Configuring Traffic Policing Traffic Policing Configuration Examples

Verifying the Configuration Example

The following example verifies that the Traffic Policing feature is configured on your interface. If the feature is configured on your interface, the show policy-map interface command output displays policing statistics.
Router# show policy-map interface Ethernet1/7 service-policy output: x class-map: a (match-all) 0 packets, 0 bytes 5 minute rate 0 bps match: ip precedence 0 police: 1000000 bps, 10000 limit, 10000 extended limit conformed 0 packets, 0 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop conformed 0 bps, exceed 0 bps, violate 0 bps

Cisco IOS Quality of Service Solutions Configuration Guide

QC-222

Configuring Generic Traffic Shaping

This chapter describes the tasks for configuring the Generic Traffic Shaping (GTS) feature on a router. For complete conceptual information, see the section Traffic Shaping in the chapter Policing and Shaping Overview in this book. For a complete description of the GTS commands mentioned in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Note

GTS is not supported on Integrated Services Digital Networks (ISDNs), dialup interfaces, or generic routing encapsulation (GRE) tunnel interfaces on the Cisco 7500 series router. Traffic shaping is not supported with flow switching.

Generic Traffic Shaping Configuration Task List

To configure GTS, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Configuring GTS (Required) Configuring GTS for an Access List (Optional) Configuring Adaptive GTS for Frame Relay Networks (Optional) Monitoring the GTS Configuration (Optional)

See the end of this chapter for the section Generic Traffic Shaping Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-223

Configuring Generic Traffic Shaping Generic Traffic Shaping Configuration Task List

Configuring GTS
To configure GTS for outbound traffic on an interface or subinterface, use the following command in interface configuration mode: Command
Router(config-if)# traffic-shape rate bit-rate [burst-size [excess-burst-size]]

Purpose Configures traffic shaping for outbound traffic on an interface.

Configuring GTS for an Access List

To configure GTS for outbound traffic on an access list, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# access-list access-list-number Router(config-if)# interface interface-type interface-number Router(config-if)# traffic-shape group access-list-number bit-rate [burst-size [excess-burst-size]]

Purpose Assigns traffic to an access list. Enters interface configuration mode. Configures traffic shaping for outbound traffic on an interface for the specified access list.

Repeat the steps for each type of traffic you want to rate-limit.

Configuring Adaptive GTS for Frame Relay Networks

If traffic shaping is performed on a Frame Relay network using the traffic-shape rate command, you can also use the traffic-shape adaptive command to specify the minimum bit rate to which the traffic is shaped. To configure adaptive GTS for outbound traffic on an interface or subinterface, use the following commands in interface configuration mode: Command
Step 1
Router(config-if)# traffic-shape rate bit-rate [burst-size [excess-burst-size]] Router(config-if)# traffic-shape adaptive[bit-rate] Router(config-if)# traffic-shape fecn-adapt

Purpose Enables traffic shaping for outbound traffic on an interface.

Step 2 Step 3

Configures minimum bit rate to which traffic is shaped when backward explicit congestion notifications (BECNs) are received on an interface. Configures reflection of forward explicit congestion notifications (FECNs) as BECNs.

With adaptive GTS, the router uses BECNs to estimate the available bandwidth and adjust the transmission rate accordingly. The actual maximum transmission rate will be between the rate specified in the traffic-shape adaptive command and the rate specified in the traffic-shape rate command.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-224

Configuring Generic Traffic Shaping Generic Traffic Shaping Configuration Examples

Configure these commands on both ends of the link, enabling the router at the high-speed end to detect and adapt to congestion even when traffic is flowing primarily in one direction.

Monitoring the GTS Configuration

To monitor the current traffic shaping configuration and statistics, use the following commands in EXEC mode, as needed: Command
Router# show traffic-shape [interface-name] Router# show traffic-shape statistics [interface-name]

Purpose Displays the current traffic shaping configuration. Displays the current traffic shaping statistics.

Generic Traffic Shaping Configuration Examples

The following sections provide GTS configuration examples:

GTS Enabled on the Interface Example Constrained Access Rate Example Different Controlled Rates Through an IP Internet Example Frame Relay Adaptability to Congestion Example Different Accommodated Access Speeds Example

For information on how to configure GTS, see the section Generic Traffic Shaping Configuration Task List in this chapter.

GTS Enabled on the Interface Example

This example shows the configuration of two traffic-shaped interfaces on a router. Ethernet interface 0 is configured to limit User Datagram Protocol (UDP) traffic to 1 Mbps. Ethernet interface 1 is configured to limit all output to 5 Mbps.
access-list 101 permit udp any any interface Ethernet0 traffic-shape group 101 1000000 125000 125000 ! interface Ethernet1 traffic-shape rate 5000000 625000 625000

The following is sample output for the show traffic-shape command for this example:
Router# show traffic-shape Interface Ethernet0 Byte Limit 31250 Sustain bits/int 125000 Excess bits/int 125000 Interval (ms) 125 Increment (bytes) 15625 Adapt Active -

VC -

Access Target List Rate 101 1000000

Cisco IOS Quality of Service Solutions Configuration Guide

QC-225

Configuring Generic Traffic Shaping Generic Traffic Shaping Configuration Examples

Interface

Ethernet1 Byte Sustain Limit bits/int 156250 625000 Excess bits/int 625000 Interval (ms) 125 Increment (bytes) 78125 Adapt Active -

VC -

Access Target List Rate 5000000

The following is sample output for the show traffic-shape statistics command for this example:
Router# show traffic-shape statistics Access Queue List Depth 101 0 0 Packets 2 0 Bytes 180 0 Packets Delayed 0 0 Bytes Delayed 0 0 Shaping Active no no

I/F Et0 Et1

Constrained Access Rate Example

In this example, a T1 line may be used for 100 milliseconds (ms) in a burst, but the long-term average is limited to 64 kbps. This configuration example restricts the amount of load the system can induce on the outbound network interface.
interface serial 4/1:0 traffic-shape rate 64000 6400 6400

If you need to restrict the amount of load the system can induce outbound, and therefore the total load the system can impose on the Internet service provider (ISP), configure traffic shaping on the outbound interfaces.

Different Controlled Rates Through an IP Internet Example

Perhaps you need to restrict the flow of Network News Transfer Protocol (NNTP) to each of some set of sites across an intervening backbone to 64 kbps. This example shows how to configure that control and provide one site with 256 kbps:
access-list 101 permit 10.10.10.10 access-list 102 permit 10.10.10.20 access-list 103 permit 10.10.10.30 ! interface serial 0 traffic-shape group 101 64000 traffic-shape group 102 64000 traffic-shape group 103 256000

Separate token buckets are maintained for each access list, and traffic not matching any access list is not shaped at all.

Frame Relay Adaptability to Congestion Example

This example does not restrict flow across a Frame Relay subinterface that has been layered onto a single data-link connection identifier (DLCI). However, in the presence of BECN bits from the network, the flow is throttled back to the committed information rate (CIR). The access rate of the interface is assumed to be 1544 kbps, and the CIR is 64 kbps.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-226

Configuring Generic Traffic Shaping Generic Traffic Shaping Configuration Examples

interface serial 2 traffic-shape rate 1544000 traffic-shape adaptive 64000 traffic-shape fecn-adapt

If the traffic-shape fecn-adapt command is configured at both ends of the link, the far end will reflect received FECNs as BECNs in Q.922 TEST RESPONSE messages.

Different Accommodated Access Speeds Example

Frame Relay networks are often asymmetrical, that is, the access rate at one site may differ from the access rate at another. In such cases, it may be worthwhile to configure the faster rate to shape to the access rate of the slower rate, and to respond to BECNs. Using the previous example as a starting point, in which the access rate is 1544 kbps and the CIR is 64 kbps, and the access rate at the far end is 128 kbps, the configuration of the subinterfaces would be as follows:
interface serial 3 traffic-shape rate 128000 traffic-shape adaptive 64000

Cisco IOS Quality of Service Solutions Configuration Guide

QC-227

Configuring Generic Traffic Shaping Generic Traffic Shaping Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-228

Configuring Class-Based Shaping

This chapter describes the tasks for configuring the Class-Based Shaping feature. For complete conceptual information, see the section Class-Based Shaping in the chapter Policing and Shaping Overview in this book. For a complete description of the Class-Based Shaping commands mentioned in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Class-Based Shaping Configuration Task List

To configure Class-Based Shaping, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Configuring Class-Based Shaping (Required) Configuring CBWFQ Inside Generic Traffic Shaping (Optional) Verifying the Configuration of Policy Maps and Their Classes (Optional)

See the end of this chapter for the section Class-Based Shaping Configuration Examples.

Configuring Class-Based Shaping

To configure Class-Based Shaping, use the first two commands in global configuration mode to specify the name of the policy map and the name of the class map. To specify average or peak rate, use the remaining commands in class-map configuration mode: Command
Step 1 Step 2
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the name of the class map to be created.

Router(config)# class-map class-map-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-229

Configuring Class-Based Shaping Class-Based Shaping Configuration Task List

Command
Step 3 Step 4
Router(config-pmap-c)# shape {average | peak} cir [bc] [be] Router(config-pmap-c)# shape max-buffers number-of-buffers

Purpose Specifies average or peak rate shaping. (Optional) Specifies the maximum number of buffers allowed on shaping queues.

Configuring CBWFQ Inside Generic Traffic Shaping

To configure class-based weighted fair queueing (CBWFQ) inside GTS, use the first two commands in global configuration mode to specify the name of the policy map and the name of the class map. To specify average or peak rate and to attach the service policy to the class, use the remaining commands in class-map configuration mode: Command
Step 1 Step 2 Step 3 Step 4
Router(config)# policy-map policy-map

Purpose Specifies the name of the policy map to be created or modified. Specifies the name of the class map to be created. Specifies average or peak rate shaping. Attaches the service policy with CBWFQ to the class.

Router(config)# class-map class-map-name Router(config-pmap-c)# shape {average | peak} cir [bc] [be] Router(config-pmap-c)# service-policy policy-map

Verifying the Configuration of Policy Maps and Their Classes

To display the contents of a specific policy map, a specific class from a specific policy map, or all policy maps configured on an interface, use the following commands in EXEC mode, as needed: Command
Router# show policy policy-map

Purpose Displays the configuration of all classes comprising the specified policy map. Displays the configuration of the specified class of the specified policy map. Displays the configuration of all classes configured for all policy maps on the specified interface.

Router# show policy policy-map class class-name

Router# show policy interface interface-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-230

Configuring Class-Based Shaping Class-Based Shaping Configuration Examples

Class-Based Shaping Configuration Examples

The following sections provide Class-Based Shaping configuration examples:

Class-Based Shaping Example CBWFQ in Conjunction with GTS Example CBWFQ Inside GTS Examples Configuration Verification Example

For information on how to configure Class-Based Shaping, see the section Class-Based Shaping Configuration Task List in this chapter.

Class-Based Shaping Example

The following example defines one class, c1. Class c1 is configured to shape traffic to 384 kbps, with a normal burst size of 15440 bits.
Router(config)# policy-map shape Router(config-pmap)# class c1 Router(config-pmap-c)# shape average 38400 15440 Router(config-pmap-c)# configure terminal Router(config)# interface Serial 3/3 Router(config-if)# service out shape

CBWFQ in Conjunction with GTS Example

The following example uses CBWFQ at the interface and shapes the traffic before it is queued to CBWFQ. In this example, two classes are defined, cust1 and cust2. The class called cust1 is ensured a bandwidth of 256 kbps, and the output is shaped to 384 kbps. The class called cust2 is ensured a bandwidth of 384 kbps, but if enough bandwidth is available on the interface, the class can obtain throughput up to a peak of 512 kbps. Figure 13 illustrates this example.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-231

Configuring Class-Based Shaping Class-Based Shaping Configuration Examples

Figure 13

CBWFQ in Conjunction with GTS

shape-cbwfq

cust1

cust2
41109

Bandwidth: 256 kbps Shape: 384 kbps (average)

Bandwidth: 384 kbps Shape: 512 kbps (peak)

The following commands are used to configure this example:

Router(config)# policy-map shape-cbwfq Router(config-pmap)# class cust1 Router(config-pmap-c)# shape average 384000 Router(config-pmap-c)# bandwidth 256 Router(config-pmap)# class cust2 Router(config-pmap-c)# shape peak 512000 Router(config-pmap-c)# bandwidth 384 Router(config-pmap-c)# configure terminal Router(config)# interface Serial 3/3 Router(config-if)# service out shape-cbwfq

CBWFQ Inside GTS Examples

This section provides two examples of configuring CBWFQ inside GTS. The first example uses hierarchical policy maps and configures CBWFQ inside GTS. In the following example, three policy maps are definedcust1-classes, cust2-classes, and cust-policy. The policy maps called cust1-classes and cust2-classes have three classes definedgold, silver, and bronze. For cust1-classes, gold is configured to use 50 percent of the bandwidth. Silver is configured to use 20 percent of the bandwidth, and bronze is configured to use 15 percent of the bandwidth. For cust2-classes, gold is configured to use 30 percent of the bandwidth. Silver is configured to use 15 percent of the bandwidth, and bronze is configured to use 10 percent of the bandwidth. The policy map cust-policy specifies average rate shaping of 384 kbps and assigns the service policy called cust1-classes to the class called cust1. The policy map cust-policy specifies peak rate shaping of 512 kbps and assigns the service policy cust2-classes to the class called cust2. Figure 14 illustrates this example.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-232

Configuring Class-Based Shaping Class-Based Shaping Configuration Examples

Figure 14

Hierarchical Policy Maps Using Class-Based Shaping

cust-policy

Shape average to 384 kbps

cust1classes

cust2classes

Shape peak to 512 kbps

Gold

Silver

Bronze

Gold

Silver

Bronze
41108

Bandwidth: 50%

20%

15%

30%

15%

10%

cust1-classes Configuration
Router(config)# policy-map cust1-classes Router(config-pmap)# class gold Router(config-pmap-c)# bandwidth percent 50 Router(config-pmap)# class silver Router(config-pmap-c)# bandwidth percent 20 Router(config-pmap)# class bronze Router(config-pmap-c)# bandwidth percent 15

cust2-classes Configuration
Router(config)# policy-map cust2-classes Router(config-pmap)# class gold Router(config-pmap-c)# bandwidth percent 30 Router(config-pmap)# class silver Router(config-pmap-c)# bandwidth percent 15 Router(config-pmap)# class bronze Router(config-pmap-c)# bandwidth percent 10

Customer Policy and QoS Features Configuration

Router(config)# policy-map cust-policy Router(config-pmap)# class cust1 Router(config-pmap-c)# shape average 384000 Router(config-pmap-c)# service-policy cust1-classes Router(config-pmap)# class cust2 Router(config-pmap-c)# shape peak 512000 Router(config-pmap-c)# service-policy cust2-classes Router(config-pmap-c)# interface Serial 3/2 Router(config-if)# service out cust-policy

Cisco IOS Quality of Service Solutions Configuration Guide

QC-233

Configuring Class-Based Shaping Class-Based Shaping Configuration Examples

In this second example, the Class-Based Shaping feature is configured for the class called shaped in the policy map called GTS_in_ModCLI. The class shaped is shaped to an average rate of 241,000 bits per second (bps). CBWFQ is also enabled on the class, which guarantees a bandwidth of 241 kbps during times of congestion at the interface. The shaped class is a congestion point for all the subclasses that comprise that class. Therefore, the subclasses can be further differentiated in the shaped class. All these subclasses are part of the policy map, CBWFQ_in_GTS, that is attached to the shaped class.
Policy Map GTS_in_ModCLI Configuration
Router(config)# policy-map GTS_in_ModCLI Router(config-pmap)# class shaped Router(config-pmap-c)# bandwidth 241 Router(config-pmap-c)# shape average 241000 Router(config-pmap-c)# service-policy CBWFQ_in_GTS

Policy Map CBWFQ_in_GTS Configuration

The policy map called CBWFQ_in_GTS has four CBWFQ classes:

Router(config)# policy-map CBWFQ_in_GTS Router(config-pmap)# class cust_A Router(config-pmap-c)# bandwidth percent 25 Router(config-pmap)# class cust_B Router(config-pmap-c)# bandwidth percent 25 Router(config-pmap)# class cust_C Router(config-pmap-c)# bandwidth percent 25 Router(config-pmap)# class class-default Router(config-pmap-c)# fair

Configuration Verification Example

The following example is output of the show policy-map command for GTS_in_ModCLI displays an expanded configuration, including the subclasses:
Router# show policy-map GTS_in_ModCLI Policy Map GTS_in_ModCLI Class shaped Weighted Fair Queueing Bandwidth 241 (kbps) Max Threshold 64 (packets) Traffic Shaping Average Rate Traffic Shaping CIR 241000 (bps) Max. Buffers Limit 1000 (Packets) Policy Map CBWFQ_in_GTS Class cust_A Weighted Fair Queueing Bandwidth 25 (%) Max Threshold 64 (packets) Class cust_B Weighted Fair Queueing Bandwidth 25 (%) Max Threshold 64 (packets) Class cust_C Weighted Fair Queueing Bandwidth 25 (%) Max Threshold 64 (packets) Class class-default Weighted Fair Queueing Flow based Fair Queueing

The policy map called GTS_in_ModCLI can be attached to any logical interface that provides a congestion point. Run-time statistics after attaching to serial interface 3/0 are shown.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-234

Configuring Class-Based Shaping Class-Based Shaping Configuration Examples

Router# show policy interface Serial 3/0 Serial3/0 output : GTS_in_ModCLI Class shaped Weighted Fair Queueing Output Queue: Conversation 267 Bandwidth 241 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 3852/947384 (pkts discards/bytes discards/tail drops) 0/0/0 Traffic Shaping Target Byte Sustain Excess Interval Increment Adapt Rate Limit bits/int bits/int (ms) (bytes) Active 241000 1928 7712 7712 32 964 Queue Packets Bytes Packets Bytes Depth Delayed Delayed Active 41 3980 978872 3967 975686 yes Class cust_A Weighted Fair Queueing Output Queue: Conversation 41 Bandwidth 25 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (pkts discards/bytes discards/tail drops) 0/0/0 Class cust_B Weighted Fair Queueing Output Queue: Conversation 42 Bandwidth 25 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (pkts discards/bytes discards/tail drops) 0/0/0 Class cust_C Weighted Fair Queueing Output Queue: Conversation 43 Bandwidth 25 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (pkts discards/bytes discards/tail drops) 0/0/0 Class class-default Weighted Fair Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 32

Cisco IOS Quality of Service Solutions Configuration Guide

QC-235

Configuring Class-Based Shaping Class-Based Shaping Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-236

Configuring Distributed Traffic Shaping

This chapter describes the tasks for configuring Distributed Traffic Shaping (DTS) feature. For complete conceptual information, see the section Distributed Traffic Shaping in the chapter Policing and Shaping Overview in this book. For a complete description of the DTS commands mentioned in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Distributed Traffic Shaping Configuration Task List

To configure DTS, perform the tasks described in the following sections. The tasks in the first four sections are required; the task in the last section is optional.

Creating a Traffic Class (Required) Configuring a Traffic Policy that Uses DTS (Required) Attaching the Traffic Policy and Enabling DTS (Required) Modifying DTS for an Existing Traffic Class (Required) Monitoring and Maintaining DTS (Optional)

See the end of this chapter for the section Distributed Traffic Shaping Configuration Examples.

Creating a Traffic Class

DTS is enabled using the Modular Quality of Service Command-Line Interface (Modular QoS CLI) feature. The first step in enabling any feature using the Modular QoS CLI is creating a traffic class. For information on the Modular QoS CLI along with the procedure for creating a traffic class, see the chapter Modular Quality of Service Command-Line Interface Overview in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-237

Configuring Distributed Traffic Shaping Distributed Traffic Shaping Configuration Task List

Configuring a Traffic Policy that Uses DTS

To enable DTS you must configure a traffic policy. You can configure traffic policies for as many classes as are defined on the router up to the maximum of 256. To configure a traffic policy, use the policy-map command beginning in global configuration mode to specify the traffic policy name, then use the following configuration commands in policy-map configuration mode to configure the traffic class name and traffic shaping. Traffic is directed to the traffic policy default class if it does not satisfy the match criteria of any other classes whose policies are defined in the traffic policy. Command
Step 1 Step 2
Router(config)# policy-map policy-name Router(config-pmap)# class class-name

Purpose Specifies the name of the traffic policy to be created. Specifies the name of a predefined traffic class included in the traffic policy. The class was defined in the previous step of this process. Specifies the target bits per second (bps) rate.

Step 3

Router(config-pmap-c)# shape <average | peak> <mean rate>[<burst size> [<excess burst size>]]

Attaching the Traffic Policy and Enabling DTS

To attach a traffic policy to the interface and enable DTS on the interface, use the following command in interface configuration mode: Command
Router(config-if)# service-policy output policy-name

Purpose Enables DTS and attaches the specified traffic policy to the interface.

Modifying DTS for an Existing Traffic Class

To change the amount of bandwidth allocated for an existing traffic class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# policy-map policy-name

Purpose Specifies the name of the traffic policy containing the class to be modified. Specifies the name of a traffic class you want to modify. Specifies the new values for the DTS feature.

Router(config-pmap)# class class-name

Router(config-pmap-c)# shape [average | peak] mean-rate [[burst-size] [excess-burst-size]]

Cisco IOS Quality of Service Solutions Configuration Guide

QC-238

Configuring Distributed Traffic Shaping Distributed Traffic Shaping Configuration Examples

Monitoring and Maintaining DTS

To monitor and maintain the DTS feature, use the following commands in EXEC mode, as needed: Command
Router# show interface [interface-name] shape Router# show policy policy-name

Purpose Displays detail status of the traffic shaping. Displays the configuration of all classes composing the specified traffic policy. Displays the configuration of the specified class of the specified traffic policy.

Router# show policy policy-name class class-name

Distributed Traffic Shaping Configuration Examples

This section provides the following DTS configuration examples:

DTS on Main Interface Example Class-Based DTS on Main Interface Example DTS on Frame Relay Point-to-Point Subinterface Example Class-Based DTS on Frame Relay Point-to-Point Subinterface Example

For information on how to configure DTS, see the section Distributed Traffic Shaping Configuration Task List in this chapter.

DTS on Main Interface Example

In the following example, traffic leaving interface pos1/0/0 is shaped at the rate of 10 Mbps:
Router(config)# class-map class-interface-all Router(config-cmap)# match any Router(config-cmap)# exit Router(config)# policy-map dts-interface-all-action Router(config-pmap)# class class-interface-all Router(config-pmap-c)# shape average 10000000 Router(config-pmap-c)# exit Router(config)# interface pos1/0/0 Router(config-if)# service-policy output dts-interface-all-action

Class-Based DTS on Main Interface Example

In the following example, two classes are created and the match criteria is defined based on the access list number. Traffic leaving interface fd4/0/0 and matches access list 10 is shaped to 16 Mbps. Traffic leaving interface fdi 4/0/0 and matches access list 20 is shaped to 8 Mbps.
Router(config)# access-list 10 permit 172.16.0.0 Router(config)# access-list 20 permit 192.168.0.0 Router(config)# class-map class1 Router(config-cmap)# match access-group 10 Router(config-cmap)# exit Router(config)# class-map class2 Router(config-cmap)# match access-group 20

Cisco IOS Quality of Service Solutions Configuration Guide

QC-239

Configuring Distributed Traffic Shaping Distributed Traffic Shaping Configuration Examples

Router(config-cmap)# exit Router(config)# policy-map dts-interface-class-action Router(config-pmap)# class class1 Router(config-pmap-c)# shape average 16000000 Router(config-pmap-c)# exit Router(config-pmap)# class class2 Router(config-pmap-c)# shape average 8000000 Router(config-pmap-c)# exit Router(config-pmap)# interface fd4/0/0 Router(config-if)# service-policy output dts-interface-class-action

DTS on Frame Relay Point-to-Point Subinterface Example

In the following example, traffic leaving sub interface 6/1/0.1 or 6/1/0.2 is shaped to 1 Mbps:
Router(config)# class-map class-p2p-all Router(config-cmap)# match any Router(config-cmap)# exit Router(config)# policy-map dts-p2p-all-action Router(config-pmap)# class class-p2p-all Router(config-pmap-c)# shape average 1000000 Router(config-pmap-c)# exit Router(config)# interface hssi6/1/0.1 point-to-point Router(config-subif)# service-policy output dts-p2p-all-action Router(config-subif)# exit Router(config)# interface hssi6/1/0.2 point-to-point Router(config-subif)# service-policy output dts-p2p-all-action

Class-Based DTS on Frame Relay Point-to-Point Subinterface Example

In the following example, two classes are created with the match criteria defined by QoS number. Traffic leaving subinterface 6/1/0.5 or 6/1/0.6 with the QoS group number 30 shaped to 800 kbps and traffic leaving the same subinterfaces with the QoS group number 40 shaped is to 1.6 Mbps. For the incoming Frame Relay packet that has the forward explicit congestion notification (FECN) bit on, a backward explicit congestion notification (BECN) message is sent out from the interface. For the outgoing Frame Relay packets that match the QoS group number 40, the shape rate could be further reduced to 800 kbps.
Router(config)# class-map class3 Router(config-cmap)# match qos-group 30 Router(config-cmap)# exit Router(config)# class-map class4 Router(config-cmap)# match qos-group 40 Router(config-cmap)# exit Router(config)# policy-map dts-p2p-class-action Router(config-pmap)# class class3 Router(config-pmap-c)# shape average 800000 Router(config-pmap-c)# shape fecn-adapt Router(config-pmap-c)# exit Router(config-pmap)# class class4 Router(config-pmap-c)# shape average 1600000 Router(config-pmap-c)# shape adaptive 800000 Router(config-pmap-c)# exit Router(config)# interface serial 6/1/0.5 point-to-point Router(config-subif)# service-policy output dts-p2p-class-action Router(config-subif)# exit Router(config)# interface serial 6/1/0.6 point-to-point Router(config-subif)# service-policy output dts-p2p-class-action

Cisco IOS Quality of Service Solutions Configuration Guide

QC-240

Signalling

Signalling Overview
In the most general sense, QoS signalling is a form of network communication that allows an end station or network node to communicate with, or signal, its neighbors to request special handling of certain traffic. QoS signalling is useful for coordinating the traffic handling techniques provided by other QoS features. It plays a key role in configuring successful overall end-to-end QoS service across your network. True end-to-end QoS requires that every element in the network pathswitch, router, firewall, host, client, and so ondeliver its part of QoS, and that all of these entities be coordinated with QoS signalling. Many viable QoS signalling solutions provide QoS at some places in the infrastructure; however, they often have limited scope across the network. To achieve end-to-end QoS, signalling must span the entire network. Cisco IOS QoS software takes advantage of IP to meet the challenge of finding a robust QoS signalling solution that can operate over heterogeneous network infrastructures. It overlays Layer 2 technology-specific QoS signalling solutions with Layer 3 IP QoS signalling methods of the Resource Reservation Protocol (RSVP) and IP Precedence features. An IP network can achieve end-to-end QoS, for example, by using part of the IP packet header to request special handling of priority or time-sensitive traffic. Given the ubiquity of IP, QoS signalling that takes advantage of IP provides powerful end-to-end signalling. Both RSVP and IP Precedence fit this category. Either in-band (IP Precedence, 802.1p) or out-of-band (RSVP) signalling is used to indicate that a particular QoS is desired for a particular traffic classification. IP Precedence signals for differentiated QoS, and RSVP for guaranteed QoS.

IP Precedence
As shown in Figure 15, the IP Precedence feature utilizes the three precedence bits in the type of service (ToS) field of the IP version 4 (IPv4) header to specify class of service for each packet. You can partition traffic in up to six classes of service using IP precedence. The queueing technologies throughout the network can then use this signal to provide the appropriate expedited handling.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-243

Signalling Overview Resource Reservation Protocol

Figure 15

IP Precedence ToS Field

IPv4 packet Data

ToS field 3-bit precedence

16757

You can use features such as policy-based routing (PBR) and committed access rate (CAR) to set precedence based on extended access list classification. Use of these features allows considerable flexibility of precedence assignment, including assignment by application or user, or by destination or source subnet. Typically, you deploy these features as close to the edge of the network or the administrative domain as possible, so that each subsequent network element can provide service based on the determined policy. IP precedence can also be set in the host or the network client; however, IP precedence can be overridden by policy within the network. IP precedence enables service classes to be established using existing network queueing mechanisms, such as weighted fair queueing (WFQ) and Weighted Random Early Detection (WRED), with no changes to existing applications and with no complicated network requirements.

Resource Reservation Protocol

RSVP is the first significant industry-standard protocol for dynamically setting up end-to-end QoS across a heterogeneous network. RSVP, which runs over IP, allows an application to dynamically reserve network bandwidth. Using RSVP, applications can request a certain level of QoS for a data flow across a network. The Cisco IOS QoS implementation allows RSVP to be initiated within the network using configured proxy RSVP. Using this capability, you can take advantage of the benefits of RSVP in the network even for non-RSVP enabled applications and hosts. RSVP is the only standard signalling protocol designed to guarantee network bandwidth from end-to-end for IP networks. RSVP does not perform its own routing; instead it uses underlying routing protocols to determine where it should carry reservation requests. As routing changes paths to adapt to topology changes, RSVP adapts its reservation to the new paths wherever reservations are in place. This modularity does not prevent RSVP from using other routing services. RSVP provides transparent operation through router nodes that do not support RSVP. RSVP works in conjunction with, not in place of, current queueing mechanisms. RSVP requests the particular QoS, but it is up to the particular interface queueing mechanism, such as WFQ or WRED, to implement the reservation. You can use RSVP to make two types of dynamic reservations: controlled load and guaranteed rate services, both of which are briefly described in the chapter Quality of Service Overview in this book. A primary feature of RSVP is its scalability. RSVP scales well using the inherent scalability of multicast. RSVP scales to very large multicast groups because it uses receiver-oriented reservation requests that merge as they progress up the multicast tree. Although RSVP is designed specifically for multicast applications, it may also make unicast reservations. However, it does not scale as well with a large number of unicast reservations. RSVP is an important QoS feature, but it does not solve all problems addressed by QoS, and it imposes a few hindrances, such as the time required to set up end-to-end reservation.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-244

Signalling Overview Resource Reservation Protocol

How It Works
Hosts and routers use RSVP to deliver QoS requests to the routers along the paths of the data stream and to maintain router and host state to provide the requested service, usually bandwidth and latency. RSVP uses a mean data ratethe largest amount of data the router will keep in the queueand minimum QoS (that is, guarantee of the requested bandwidth specified when you made the reservation using RSVP) to determine bandwidth reservation. A host uses RSVP to request a specific QoS service from the network on behalf of an application data stream. RSVP requests the particular QoS, but it is up to the interface queueing mechanism to implement the reservation. RSVP carries the request through the network, visiting each node the network uses to carry the stream. At each node, RSVP attempts to make a resource reservation for the stream using its own admission control module, exclusive to RSVP, which determines whether the node has sufficient available resources to supply the requested QoS.

Note

For RSVP, an application could send traffic at a rate higher than the requested QoS, but the application is guaranteed only the minimum requested rate. If bandwidth is available, traffic surpassing the requested rate will go through if sent; if bandwidth is not available, the exceeding traffic will be dropped. If the required resources are available and the user is granted administrative access, the RSVP daemon sets arguments in the packet classifier and packet scheduler to obtain the desired QoS. The classifier determines the QoS class for each packet and the scheduler orders packet transmission to achieve the promised QoS for each stream. If either resource is unavailable or the user is denied administrative permission, the RSVP program returns an error notification to the application process that originated the request. WFQ or WRED sets up the packet classification and the scheduling required for the reserved flows. Using WFQ, RSVP can deliver an integrated services Guaranteed Rate Service. Using WRED, it can deliver a Controlled Load Service. For information on how to configure RSVP, see the chapter Configuring RSVP in this book.

RSVP Support for Low Latency Queueing

RSVP is a network-control protocol that provides a means for reserving network resourcesprimarily bandwidthto guarantee that applications sending end-to-end across networks achieve the desired QoS. RSVP enables real-time traffic (which includes voice flows) to reserve resources necessary for low latency and bandwidth guarantees. Voice traffic has stringent delay and jitter requirements. It must have very low delay and minimal jitter per hop to avoid degradation of end-to-end QoS. This requirement calls for an efficient queueing implementation, such as low latency queueing (LLQ), that can service voice traffic at almost strict priority in order to minimize delay and jitter. RSVP uses WFQ to provide fairness among flows and to assign a low weight to a packet to attain priority. However, the preferential treatment provided by RSVP is insufficient to minimize the jitter because of the nature of the queueing algorithm itself. As a result, the low latency and jitter requirements of voice flows might not be met in the prior implementation of RSVP and WFQ.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-245

Signalling Overview Resource Reservation Protocol

RSVP provides admission control. However, to provide the bandwidth and delay guarantees for voice traffic and get admission control, RSVP must work with LLQ. The RSVP Support for LLQ feature allows RSVP to classify voice flows and queue them into the priority queue within the LLQ system while simultaneously providing reservations for nonvoice flows by getting a reserved queue. Figure 16 shows how RSVP operates with other Voice over IP (VoIP) features, such as ip rtp priority, using the same queueing mechanism, LLQ.
Figure 16 RSVP Support for LLQ

Voice flow Traffic destined for interface Classification RSVP IP RTP priority Non voice flow

Priority queue

Reserved queues

Class priority Scheduler Class 1 Reserved queues Reserved queues Reserved queues Default unreserved queue Output

Class 2 Class default

RSVP is the only protocol that provides admission control based on the availability of network resources such as bandwidth. LLQ provides a means to forward voice traffic with strict priority ahead of other data traffic. When combined, RSVP support for LLQ provides admission control and forwards voice flows with the lowest possible latency and jitter. High priority nonvoice traffic from mission-critical applications can continue to be sent without being adversely affected by voice traffic. Nonconformant traffic receives best-effort treatment, thereby avoiding any degradation that might otherwise occur for all traffic. The RSVP Support for LLQ feature supports the following RFCs:

RFC 2205, Resource Reservation Protoco l RFC 2210, RSVP with IETF Integrated Services RFC 2211, Controlled-Load Network Element Service RFC 2212, Specification of Guaranteed Quality of Service RFC 2215, General Characterization Parameters for Integrated Service Network Elements

Figure 17 shows a sample network topology with LLQ running on each interface. This configuration guarantees QoS for voice traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-246

42294

Signalling Overview Resource Reservation Protocol

Note

If the source is incapable of supporting RSVP, then the router can proxy on behalf of the source.
Figure 17 Topology Showing LLQ on Each Interface
Serial port 1/0 1/3 IP cloud Serial port 1/3 1/0

64 kbps Voice port 1/0/0 Router RLB-1 Dial peer 1 POTS

Router RLB-w

128 kbps

Router R12-e

64 kbps Voice port 1/0/0 Router RLB-2 Dial peer 2 POTS

S6612

Serial port 0/0

Serial port 1/0

For information on how to configure the RSVP Support for LLQ feature, see the chapter Configuring RSVP Support for LLQ in this book.

Restrictions
The following restrictions apply to the RSVP Support for LLQ feature:

The LLQ is not supported on any tunnels. RSVP support for LLQ is dependent on the priority queue. If LLQ is not available on any interface or platform, then RSVP support for LLQ is not available. RSVP support for LLQ on Frame Relay permanent virtual circuits (PVCs) and ATM PVCs is currently not available. Support is planned for future releases.

Prerequisites
The network must support the following Cisco IOS features before RSVP support for LLQ is enabled:

RSVP WFQ or LLQ (WFQ with priority queue support)

RSVP Support for Frame Relay

Network administrators use queueing to manage congestion on a router interface or a virtual circuit (VC). In a Frame Relay environment, the congestion point might not be the interface itself, but the VC because of the committed information rate (CIR). For real-time traffic (voice flows) to be sent in a timely manner, the data rate must not exceed the CIR or packets might be dropped, thereby affecting voice quality. Frame Relay Traffic Shaping (FRTS) is configured on the interfaces to control the outbound traffic rate by preventing the router from exceeding the CIR. This type of configuration means that fancy queueing such as class-based WFQ (CBWFQ), LLQ, or WFQ, can run on the VC to provide the QoS guarantees for the traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-247

Signalling Overview Resource Reservation Protocol

Previously, RSVP reservations were not constrained by the CIR of the outbound VC of the flow. As a result, oversubscription could occur when the sum of the RSVP traffic and other traffic exceeded the CIR. The RSVP Support for Frame Relay feature allows RSVP to function with per-VC (data-link connection identifier (DLCI) queueing for voice-like flows. Traffic shaping must be enabled in a Frame Relay environment for accurate admission control of resources (bandwidth and queues) at the congestion point, that is, the VC itself. Specifically, RSVP can function with VCs defined at the interface and subinterface levels. There is no limit to the number of VCs that can be configured per interface or subinterface.

RSVP Bandwidth Allocation and Modular QoS Command Line Interface (CLI)
RSVP can use an interface (or a PVC) queueing algorithm, such as WFQ, to ensure QoS for its data flows.

Admission Control
When WFQ is running, RSVP can co-exist with other QoS features on an interface (or PVC) that also reserve bandwidth and enforce QoS. When you configure multiple bandwidth-reserving features (such as RSVP, LLQ, CB-WFQ, and ip rtp priority), portions of the interface's (or PVC's) available bandwidth may be assigned to each of these features for use with flows that they classify. An internal interface-based (or PVC-based) bandwidth manager prevents the amount of traffic reserved by these features from oversubscribing the interface (or PVC). You can view this pool of available bandwidth using the show queue command, and it is configured (as a percentage of the interfaces or PVC's capacity) via the max-reserved-bandwidth command. When you configure features such as LLQ and CB-WFQ, any classes that are assigned a bandwidth reserve their bandwidth at the time of configuration, and deduct this bandwidth from the bandwidth manager. If the configured bandwidth exceeds the interface's capacity, the configuration is rejected. When RSVP is configured, no bandwidth is reserved. (The amount of bandwidth specified in the ip rsvp bandwidth command acts as a strict upper limit, and does not guarantee admission of any flows.) Only when an RSVP reservation arrives does RSVP attempt to reserve bandwidth out of the remaining pool of available bandwidth (that is, the bandwidth that has not been dedicated to traffic handled by other features.)

Data Packet Classification

By default, RSVP performs an efficient flow-based, datapacket classification to ensure QoS for its reserved traffic. This classification runs prior to queueing consideration by ip rtp priority or CB-WFQ. Thus, the use of a CB-WFQ class or ip rtp priority command is not required in order for RSVP data flows to be granted QoS. Any ip rtp priority or CB-WFQ configuration will not match RSVP flows, but they will reserve additional bandwidth for any non-RSVP flows that may match their classifiers.

Benefits
The benefits of this feature include the following:

RSVP now provides admission control based on the VC minimum acceptable outgoing (minCIR) value, if defined, instead of the amount of bandwidth available on the interface. RSVP provides QoS guarantees for high priority traffic by reserving resources at the point of congestion, that is, the Frame Relay VC instead of the interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-248

Signalling Overview RSVP-ATM QoS Interworking

RSVP provides support for point-to-point and multipoint interface configurations, thus enabling deployment of services such as VoIP in Frame Relay environments with QoS guarantees. RSVP, CBWFQ, and the ip rtp priority command do not oversubscribe the amount of bandwidth available on the interface or the VC even when they are running simultaneously. Prior to admitting a reservation, these features (and the ip rtp priority command) consult with an internal bandwidth manager to avoid oversubscription. IP QoS features can now be integrated seamlessly from IP into Frame Relay environments with RSVP providing admission control on a per-VC (DLCI) basis.

The RSVP Support for Frame Relay feature supports the following MIB and RFCs:

RFC 2206, RSVP Management Information Base using SMIv2 RFC 220, Resource Reservation Protocol RFC 2210, RSVP with IETF Integrated Services RFC 221, Controlled-Load Network Element Service RFC 2212, Specification of Guaranteed Quality of Service RFC 2215, General Characterization Parameters for Integrated Service Network Elements

For information on how to configure RVSP Support for Frame Relay, see the chapter Configuring RSVP Support for Frame Relay in this book.

Restrictions
The following restrictions apply to the RSVP Support for Frame Relay feature:

Interface-level Generic Traffic Shaping (GTS) is not supported. VC-level queueing and interface-level queueing on the same interface are not supported. Nonvoice RSVP flows are not supported. Multicast flows are not supported.

Prerequisites
The network must support the following Cisco IOS features before RSVP support for Frame Relay is enabled:

RSVP WFQ on the VC LLQ Frame Relay Forum (FRF).12 on the interface

RSVP-ATM QoS Interworking

The RSVP-ATM QoS Interworking feature provides support for Controlled Load Service using RSVP over an ATM core network. This feature requires the ability to signal for establishment of switched virtual circuits (SVCs) across the ATM cloud in response to RSVP reservation request messages. To meet this requirement, RSVP over ATM supports mapping of RSVP sessions to ATM SVCs.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-249

Signalling Overview RSVP-ATM QoS Interworking

The RSVP-ATM QoS Interworking feature allows you to perform the following tasks:

Configure an interface or subinterface to dynamically create SVCs in response to RSVP reservation request messages. To ensure defined QoS, these SVCs are established having QoS profiles consistent with the mapped RSVP flow specifications (flowspecs). Attach Distributed Weighted Random Early Detection (DWRED) group definitions to the Enhanced ATM port adapter (PA-A3) interface to support per-VC DWRED drop policy. Use of per-VC DWRED ensures that if packets must be dropped, then best-effort packets are dropped first and not those that conform to the appropriate QoS determined by the token bucket of RSVP. Configure the IP Precedence and ToS values to be used for packets that conform to or exceed QoS profiles. As part of its input processing, RSVP uses the values that you specify to set the ToS and IP Precedence bits on incoming packets. If per-VC DWRED is configured, it then uses the ToS and IP Precedence bit settings on the output interface of the same router in determining which packets to drop. Also, interfaces on downstream routers use these settings in processing packets.

This feature is supported on Cisco 7500 series routers with a VIP2-50 and Enhanced ATM port adapter (PA-A3). The hardware provides the traffic shaping required by the feature and satisfies the OC-3 rate performance requirement.

How It Works
Traditionally, RSVP has been coupled with WFQ. WFQ provides bandwidth guarantees to RSVP and gives RSVP visibility to all packets visible to it. This visibility allows RSVP to identify and mark packets pertinent to it. The RSVP-ATM QoS Interworking feature allows you to decouple RSVP from WFQ, and instead associate it with ATM SVCs to handle reservation request messages (and provide bandwidth guarantees) and NetFlow to make packets visible to RSVP. To configure an interface or subinterface to use the RSVP-ATM QoS Interworking feature, use the ip rsvp svc-required command. Then, whenever a new RSVP reservation is requested, the router software establishes a new ATM SVC to service the reservation. To ensure correspondence between RSVP and ATM SVC values, the software algorithmically maps the rate and burst size parameters in the RSVP flowspec to the ATM sustained cell rate (SCR) and maximum burst size (MBS). For the peak cell rate (PCR), it uses the value you configure or it defaults to the line rate. RSVP-ATM QoS Interworking requires an Enhanced ATM port adapter (PA-A3) with OC-3 speed. When a packet belonging to a reserved flow arrives on the interface or subinterface, the RSVP-ATM QoS Interworking software uses a token bucket to manage bandwidth guarantees. It measures actual traffic rates against the reservation flowspec to determine if the packet conforms to or exceeds the flowspec. Using values you configure for conformant or exceeding traffic, it sets the IP Precedence and ToS bits in the ToS byte of the header of the packet and delivers the packet to the appropriate virtual circuit (VC) for transmission. For the RSVP-ATM QoS Interworking feature, packets are shaped before they are sent on the ATM SVC. Shaping creates back pressure to the Versatile Interface Processor (VIP) when the offered load exceeds the rate. The RSVP-ATM QoS Interworking software uses per-SVC DWRED to drop packets when shaping causes a queue to build up on the VIP. Use of per-SVC DWRED allows RSVP to deliver Controlled Load Service class, which requires that reserved packets experience performance equivalent to that of an unloaded network (which is one with very low loss and moderate delay). For a more detailed account of how the RSVP-ATM QoS Interworking feature works, see the following example scenario.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-250

Signalling Overview RSVP-ATM QoS Interworking

An Example Scenario
To understand the behavior of the RSVP-ATM QoS Interworking feature, consider the following example, which uses a Cisco 7500 router with VIP ingress and egress interfaces and RSVP ingress functionality implemented on the Route Switch Processor (RSP). Figure 18 illustrates this example; it shows a pair of routers that communicate over the ATM cloud. In this example, a single PVC is used for RSVP request messages and an ATM SVC is established to handle each new reservation request message.
Figure 18 Two Routers Connected over an ATM Core Network

Host X

Router A ATM cloud

Router B

Host Y
18343

RSVP request SVC with requested QoS

Host X, which is upstream from Router A, is directly connected to Router A using FDDI. Host Y, which is downstream from Router B, is directly connected to Router B using FDDI. (In an alternative configuration, these host-router connections could use ATM VCs.) For the RSVP-ATM QoS Interworking feature, reservations are needed primarily between routers across the ATM backbone network. To limit the number of locations where reservations are made, you can enable RSVP selectively only at subinterfaces corresponding to router-to-router connections across the ATM backbone network. Preventing reservations from being made between the host and the router both limits VC usage and reduces load on the router. RSVP RESV messages flow from receiving host to sending host. In this example, Host Y is the sending host and Host X is the receiving host. (Host Y sends a RESV message to Host X.) Router B, which is at the edge of the ATM cloud, receives the RESV message and forwards it upstream to Router A across the PVC used for control messages. The example configuration shown in Figure 18 uses one PVC; as shown, it carries the RSVP request. The ingress interface on Router A is configured for RSVP-ATM, which enables it to establish for each request an SVC to service any new RSVP RESV reservations made on the interface. When it receives a reservation request, the interface on Router A creates a new nonreal-time variable bit rate (nRTVBR) SVC with the appropriate QoS characteristics. The QoS characteristics used to establish the SVC result from algorithmic mapping of the flowspec in the RSVP RESV message to the appropriate set of ATM signalling parameters. In this example, Controlled Load Service is used as the QoS class. The ATM PCR parameter is set to the line rate. If the ip rsvp atm-peak-rate-limit command is used on the interface to configure a rate limiter, the PCR is set to the peak rate limiter. The ATM SCR parameter is set to the RSVP flowspec rate and the ATM MBS is set to the RSVP flowspec burst size. Packets are shaped before they are sent on the ATM SVC. Shaping creates back pressure to the VIP when the offered load exceeds the rate. When a new SVC is set up to handle a reservation request, another state is also set up including a classifier state that uses a source and destination addresses and port numbers of the packet to determine which, if any, reservation the packet belongs to. Also, a token bucket is set up to ensure that if a source sends more data than the data rate and MBS parameters of its flowspec specify, the excess traffic does not interfere with other reservations. The following section describes more specifically, how data traverses the path.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-251

Signalling Overview COPS for RSVP

When a data packet destined for Router B arrives at Router A, before they traverse the ATM cloud, the source and destination addresses and port numbers of the packet are checked against the RSVP filter specification (filterspec) to determine if the packet matches a reservation. If the packet does not match a reservation, it is sent out the best-effort PVC to Router B. If a packet matches a reservation, it is further processed by RSVP. The packet is checked against the token bucket of the reservation to determine whether it conforms to or exceeds the token bucket parameters. (All packets matching a reservation are sent out on the SVC of the reservation to prevent misordering of packets.) To introduce differentiation between flowspec-conformant and flowspec-exceeding packets, you can specify values for RSVP-ATM to use in setting the IP Precedence and ToS bits of the packets. To specify these values, you use the ip rsvp precedence and ip rsvp tos commands. When you set different precedence values for conformant and exceeding packets and use a preferential drop policy such as DWRED, RSVP-ATM ensures that flowspec-exceeding packets are dropped prior to flowspec-conformant packets when the VC is congested. For information on how to configure the RSVP-ATM QoS Interworking feature, see the chapter Configuring RSVP-ATM QoS Interworking in this book.

COPS for RSVP

Common Open Policy Service (COPS) is a protocol for communicating network traffic policy information to network devices. RSVP is a means for reserving network resourcesprimarily bandwidthto guarantee that applications sending end-to-end across the Internet will perform at the desired speed and quality. Combined, COPS with RSVP gives network managers centralized monitoring and control of RSVP, including the following abilities:

Ensure adequate bandwidth and jitter and delay bounds for time-sensitive traffic such as voice transmission Ensure adequate bandwidth for multimedia applications such as video conferencing and distance learning Prevent bandwidth-hungry applications from delaying top priority flows or harming the performance of other applications customarily run over the same network

In so doing, COPS for RSVP supports the following crucial RSVP features:

Admission control. The RSVP reservation is accepted or rejected based on end-to-end available network resources. Bandwidth guarantee. The RSVP reservation, if accepted, will guarantee that those reserved resources will continue to be available while the reservation is in place. Media-independent reservation. An end-to-end RSVP reservation can span arbitrary lower layer media types. Data classification. While a reservation is in place, data packets belonging to that RSVP flow are separated from other packets and forwarded as part of the reserved flow. Data policing. Data packets belonging to an RSVP flow that exceed the reserved bandwidth size are marked with a lower packet precedence.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-252

Signalling Overview COPS for RSVP

Note

In order to use the COPS for RSVP feature, your network must be running Cisco IOS 12.1(1)T or later releases. Moreover, a compatible policy server must be connected to the network, such as the Cisco COPS QoS Policy Manager.

Note

The Cisco IOS 12.1(2)T release of COPS for RSVP does not support RSVP+. COPS for RSVP functions on the following interfaces:

Ethernet Fast Ethernet High-Speed Serial Interface (HSSI): V.35, EIA/TIA-232 T1

The COPS for RSVP feature supports the following RFCs:

RFC 2749, COPS Usage for RSVP RFC 2205, Resource ReSerVation Protocol (RSVP) RFC 2748, The COPS (Common Open Policy Service) Protocol

How It Works
This section provides a high-level overview of how the COPS for RSVP feature works on your network, and provides the general steps for configuring the COPS for RSVP feature. Figure 19 is a sample arrangement of COPS with RSVP.
Figure 19 Sample Arrangement of COPS with RSVP

Policy Decision Point (PDP)

Server running QoS Policy Manager

COPS decision

RSVP sender

COPS request RSVP path RSVP reservation RSVP path RSVP reservation

RSVP receiver

Policy Enforcement Point (PEP)

Cisco router (client)

To configure a router to process all RSVP messages coming to it according to policies stored on a particular policy server (called the Policy Decision Point, or PDP), perform the following steps:
1.

At the PDP server enter the policies using the Cisco COPS QoS Policy Manager or a compatible policy manager application.

Cisco IOS Quality of Service Solutions Configuration Guide

32488

QC-253

Signalling Overview COPS for RSVP

2.

Configure the router (through its command-line interface) to request decisions from the server regarding RSVP messages. After that configuration, network flows are processed by the router designated as the Policy Enforcement Point (PEP), as follows:
a. When an RSVP signalling message arrives at the router, the router asks the PDP server how to

process the message, either to accept, reject, forward, or install the message.
b. The PDP server sends its decision to the router, which then processes the message as instructed. 3.

Alternatively, you may configure the router to make those decisions itself (locally) without it needing to consult first with the PDP server. (The local feature is not supported in this release but will be in a future release.)

A Detailed Look at COPS for RSVP Functioning

Figure 20 traces options available in policy management of RSVP message flows. For each option, an example of the router configuration command used for setting that option is given in brackets and boldface type. The shaded area covers local policy operations; the remainder of the figure illustrates remote policy operation. (Configuring local policy will be available in a future release.)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-254

Signalling Overview COPS for RSVP

Figure 20

Steps in Processing RSVP PATH and RESV Messages

Local Policy
Incoming RSVP message (a) Does it match any local (a-1) policy ACL? Yes [ip rsvp policy local 40 55] (a-2) No Is a default local policy configured? [ip rsvp policy local] (d-2) No Is it rejected by any local operator? (b-2) (b-1) Discard message

Yes

No

(d-1)

Yes

Is the local override flag set for this entry? (c-1) [ip rsvp policy local Yes local-override] (c-2) No

Process message

Does it match any remote policy ACL? [ip rsvp policy cops 40 165 servers] (e-2)

(e-1)

Yes

Send a query to the remote PDP.

No
(g-1)

Is a default remote policy configured? [ip rsvp policy cops servers] (g-2) (h-1)

Yes

No
Does the PDP return a "reject" decision? (f-2)

Discard message

Yes

(h-2)

No

No

Process message

Process message

The following information is keyed to the figure:

a. The router receives a PATH or RESV message and first tries to adjudicate it locally (that is,

without referring to the policy server). If the router has been configured to adjudicate specific access control lists (ACLs) locally and the message matches one of those lists (a-1), the policy module of the router applies the operators with which it had been configured. Otherwise, policy processing continues (a-2).
b. For each message rejected by the operators, the router sends an error message to the sender and

removes the PATH or RESV message from the database (b-1). If the message is not rejected, policy processing continues (b-2).
c. If the local override flag is set for this entry, the message is immediately accepted with the

specified policy operators (c-1). Otherwise, policy processing continues (c-2).

d. If the message does not match any ACL configured for local policy (a-2), the router applies the

default local policy (d-1). However, if no default local policy has been configured, the message is directed toward remote policy processing (d-2).
e. If the router has been configured with specific ACLs against specific policy servers (PDPs), and

the message matches one of these ACLs, the router sends that message to the specific PDP for adjudication (e-1). Otherwise, policy processing continues (e-2).

Cisco IOS Quality of Service Solutions Configuration Guide

32489

Is the default local decision to reject ? [ip rsvp policy default-reject]

(f-1)

Yes

Discard message

QC-255

Signalling Overview COPS for RSVP

f. If the PDP specifies a reject decision (f-1), the message is discarded and an error message is

sent back to the sender, indicating this condition. If the PDP specifies an accept decision (f-2), the message is accepted and processed using normal RSVP processing rules.
g. If the message does not match any ACL configured for specific PDPs (e-2), the router applies

the default PDP configuration. If a default COPS configuration has been entered, policy processing continues (g-1). Otherwise, the message is considered to be unmatched (g-2). If the default policy decision for unmatched messages is to reject (h-1), the message is immediately discarded and an ERROR message is sent to the sender indicating this condition. Otherwise, the message is accepted and processed using normal RSVP processing rules (h-2). Here are additional details about PDP-PEP communication and processing:

Policy request timer. Whenever a request for adjudication (of any sort) is sent to a PDP, a 30-second timer associated with the PATH or RESV message is started. If the timer runs out before the PDP replies to the request, the PDP is assumed to be down and the request is given to the default policy (step g-2 in Figure 20). PDP tracking of PEP reservations. When the PDP specifies that a reservation can be installed, this reservation must then be installed on the router. Once bandwidth capacity has been allocated and the reservation installed, the policy module of the PEP sends a COMMIT message to the PDP. But if the reservation could not be installed because of insufficient resources, the reservation is folded back to the noninstalled state and a NO-COMMIT message is sent to the PDP. If the reservation was also new (no previous state), then a DELETE REQUEST message instead is sent to the PDP. In these ways, the PDP can keep track of reservations on the PEP. Resynchronization. If the PDP sends a SYNCHRONIZE-REQUEST message to the PEP, the policy module of the PEP scans its database for all paths and reservations that were previously adjudicated by this PDP, and resends requests for them. The previously adjudicated policy information is retained until a new decision is received. When all the PATH or RESV states have been reported to the PDP, a SYNCHRONIZE-COMPLETE message is sent by the policy module to the PDP. The PEP also sends queries concerning all flows that were locally adjudicated while the PDP was down. Readjudication:
So long as flows governed by the RSVP session continue to pass through the PEP router, the

PDP can unilaterally decide to readjudicate any of the COPS decisions of that session. For example, the PDP might decide that a particular flow that was earlier granted acceptance now needs to be rejected (due perhaps to a sudden preemption or timeout). In such cases, the PDP sends a new decision message to the PEP, which then adjusts its behavior accordingly.
If the PEP router receives a RESV message in which an object has changed, the policy decision

needs to be readjudicated. For example, if the sender wants to increase or decrease the bandwidth reservation, a new policy decision must be made. In such cases, the policy flags previously applied to this session are retained, and the session is readjudicated.

Tear-downs. The policy module of the PEP is responsible for notifying the PDP whenever a reservation or path that was previously established through policy is torn down for any reason. The PEP notifies the PDP by sending the PDP a DELETE REQUEST message.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-256

Signalling Overview COPS for RSVP

Connection management:
If the connection to the PDP is closed (either because the PDP closed the connection, a TCP/IP

error occurred, or the keepalives failed), the PEP issues a CLIENT-CLOSE message and then attempts to reconnect to the same PDP. If the PEP receives a CLIENT-CLOSE message containing a PDP redirect address, the PEP attempts to connect to the redirected PDP.
If either attempt fails, the PEP attempts to connect to the PDPs previously specified in the

configuration ip rsvp policy cops servers command, obeying the sequence of servers given in that command, always starting with the first server in that list.
If the PEP reaches the end of the list of servers without connecting, it waits a certain time (called

the reconnect delay) before trying again to connect to the first server in the list. This reconnect delay is initially 30 seconds, and doubles each time the PEP reaches the end of the list without having connected, until the reconnect delay becomes its maximum of 30 minutes. As soon as a connection is made, the delay is reset to 30 seconds.

Replacement objectsThe matrix in Table 13 identifies objects that the PDP can replace within RSVP messages passing through the PEP. An x in the column indicates that the PDP can replace the particular object within RSVP messages.
Matrix for Objects the PDP Can Replace Within RSVP Messages Objects

Table 13

Message Context Policy Path In

TSpec

Flowspec

Errorspec

Items Affected

Installed PATH state. All outbound PATH messages for this PATH.

x x

x x

Path Out

This refresh of the PATH (but not the installed PATH state).

Resv In

Installed RESV state (incoming and traffic control installation). All outbound RESV messages for this RESV.

Resv Alloc

x x

Installed resources for this session. This particular refresh of the RESV message (but not the installed RESV state nor the traffic control allocation). The forwarded PATHERROR message. The forwarded PATHERROR message. All RESVERROR messages forwarded by this router. This particular forwarded RESVERROR message.

Resv Out

x x x x x

PathError In PathError Out ResvError In ResvError Out

x x x x

Cisco IOS Quality of Service Solutions Configuration Guide

QC-257

Signalling Overview Subnetwork Bandwidth Manager

If an RSVP message whose object was replaced is later refreshed from upstream, the PEP keeps track of both the old and new versions of the object, and does not wrongly interpret the refresh as a change in the PATH or RESV state. For information on how to configure COPS for RSVP, see the chapter Configuring COPS for RSVP in this book.

Subnetwork Bandwidth Manager

RSVP and its service class definitions are largely independent of the underlying network technologies. This independence requires that a user define the mapping of RSVP onto subnetwork technologies. The Subnetwork Bandwidth Manager (SBM) feature answers this requirement for RSVP in relation to IEEE 802-based networks. SBM specifies a signalling method and protocol for LAN-based admission control for RSVP flows. SBM allows RSVP-enabled routers and Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVP-enabled data flows. The SBM signalling method is similar to that of RSVP itself. SBM protocol entities have the following features:

Reside in Layer 2 or Layer 3 devices. Can manage resources on a segment. A segment is a Layer 2 physical segment shared by one or more senders, such as a shared Ethernet or Token Ring wire. Can become candidates in a dynamic election process that designates one SBM as the segment manager. The elected candidate is called the Designated Subnetwork Bandwidth Manager (DSBM). The elected DSBM is responsible for exercising admission control over requests for resource reservations on a managed segment.

A managed segment includes those interconnected parts of a shared LAN that are not separated by DSBMs. The presence of a DSBM makes the segment a managed one. One or more SBMs may exist on a managed segment, but there can be only one DSBM on each managed segment. You can configure an interface on routers connected to the segment to participate in the DSBM election process. The contender configured with the highest priority becomes the DSBM for the managed segment. If you do not configure a router as a DSBM candidate and RSVP is enabled, then the system interacts with the DSBM if a DSBM is present on the segment. In fact, if a DSBM, identifying itself as such, exists on the segment, the segment is considered a managed segment and all RSVP message forwarding will be based on the SBM message forwarding rules. This behavior exists to allow cases in which you might not want an RSVP-enabled interface on a router connected to a managed segment interface to become a DSBM, but you want it to interact with the DSBM if one is present managing the segment.

Note

SBM is not supported currently on Token Ring LANs. Figure 21 shows a managed segment in a Layer 2 domain that interconnects a set of hosts and routers.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-258

Signalling Overview Subnetwork Bandwidth Manager

Figure 21

DSBM Managed Segment

Router R2

Host C

DSBM

Host B

Router R3

LAN

Host A

Router R1

When a DSBM client sends or forwards an RSVP PATH message over an interface attached to a managed segment, it sends the PATH message to the DSBM of the segment instead of to the RSVP session destination address, as is done in conventional RSVP processing. As part of its message processing procedure, the DSBM builds and maintains a PATH state for the session and notes the previous Layer 2 or Layer 3 hop from which it received the PATH message. After processing the PATH message, the DSBM forwards it toward its destination address. The DSBM receives the RSVP RESV message and processes it in a manner similar to how RSVP itself handles reservation request processing, basing the outcome on available bandwidth. The procedure is as follows:

If it cannot grant the request because of lack of resources, the DSBM returns a RESVERROR message to the requester. If sufficient resources are available and the DSBM can grant the reservation request, it forwards the RESV message toward the previous hops using the local PATH state for the session.

For information on how to configure SBM, see the chapter Configuring Subnetwork Bandwidth Manager in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

22316

QC-259

Signalling Overview Subnetwork Bandwidth Manager

Cisco IOS Quality of Service Solutions Configuration Guide

QC-260

Configuring RSVP
This chapter describes the tasks for configuring the Resource Reservation Protocol (RSVP) feature, which is an IP service that allows end systems or hosts on either side of a router network to establish a reserved-bandwidth path between them to predetermine and ensure QoS for their data transmission. For a complete description of the RSVP commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book. RSVP allows end systems to request QoS guarantees from the network. The need for network resource reservations differs for data traffic versus for real-time traffic, as follows:

Data traffic seldom needs reserved bandwidth because internetworks provide datagram services for data traffic. This asynchronous packet switching may not need guarantees of service quality. End-to-end controls between data traffic senders and receivers help ensure adequate transmission of bursts of information. Real-time traffic (that is, voice or video information) experiences problems when operating over datagram services. Because real-time traffic sends an almost constant flow of information, the network pipes must be consistent. Some guarantee must be provided that service between real-time hosts will not vary. Routers operating on a first-in, first-out (FIFO) basis risk unrecoverable disruption of the real-time information that is being sent.

Data applications, with little need for resource guarantees, frequently demand relatively lower bandwidth than real-time traffic. The almost constant high bit-rate demands of a video conference application and the bursty low bit-rate demands of an interactive data application share available network resources. RSVP prevents the demands of traffic such as large file transfers from impairing the bandwidth resources necessary for bursty data traffic. When RSVP is used, the routers sort and prioritize packets much like a statistical time-division multiplexer (TDM) would sort and prioritize several signal sources that share a single channel. RSVP mechanisms enable real-time traffic to reserve resources necessary for consistent latency. A video conferencing application can use settings in the router to propagate a request for a path with the required bandwidth and delay for video conferencing destinations. RSVP will check and repeat reservations at regular intervals. By this process, RSVP can adjust and alter the path between RSVP end systems to recover from route changes.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-261

Configuring RSVP RSVP Reservation Types

Real-time traffic (unlike data traffic) requires a guaranteed network consistency. Without consistent QoS, real-time traffic faces the following problems:

Jitter. A slight time or phase movement in a transmission signal can introduce loss of synchronization or other errors. Insufficient bandwidth. Voice calls use a digital signal level 0 (DS-0 at 64 kbps), video conferencing uses T1/E1 (1.544 Mbps or 2.048 Mbps), and higher-fidelity video uses much more. Delay variations. If the wait time between when signal elements are sent and when they arrive varies, the real-time traffic will no longer be synchronized and transmission may fail. Information loss. When signal elements drop or arrive too late, lost audio causes distortions with noise or crackle sounds. The lost video causes image blurring, distortions, or blackouts.

RSVP works in conjunction with weighted fair queueing (WFQ) or Random Early Detection (RED). This conjunction of reservation setting with packet queueing uses two key concepts: end-to-end flows with RSVP and router-to-router conversations with WFQ:

RSVP flow. This is a stream that operates multidestination simplex, because data travels across it in only one direction: from the origin to the targets. Flows travel from a set of senders to a set of receivers. The flows can be merged or left unmerged, and the method of merging them varies according to the attributes of the application using the flow. WFQ conversation. This is the traffic for a single transport layer session or network layer flow that crosses a given interface. This conversation is identified from the source and destination address, protocol type, port number, or other attributes in the relevant communications layer.

RSVP allows for hosts to send packets to a subset of all hosts (multicasting). RSVP assumes that resource reservation applies primarily to multicast applications (such as video conferencing). Although the primary target for RSVP is multimedia traffic, a clear interest exists for the reservation of bandwidth for unicast traffic (such as Network File System (NFS) and virtual private network management). A unicast transmission involves a host sending packets to a single host. For more information about RSVP, see the section Resource Reservation Protocol in the chapter Signalling Overview in this book. RSVP cannot be configured with VIP-distributed Cisco Express Forwarding (dCEF).

RSVP Reservation Types

These are the two types of multicast flows:

Distinct reservation. This constitutes a flow that originates from exactly one sender. Shared reservation. This constitutes a flow that originates from one or more senders.

RSVP describes these reservations as having certain algorithmic attributes.

Distinct Reservation
An example of a distinct reservation is a video application in which each sender emits a distinct data stream that requires admission and management in a queue. Such a flow, therefore, requires a separate reservation per sender on each transmission facility it crosses (such as Ethernet, a High-Level Data Link Control (HDLC) line, a Frame Relay data-link connection identifier (DLCI), or an ATM virtual channel). RSVP refers to this distinct reservation as explicit and installs it using a Fixed Filter style of reservation. Use of RSVP for unicast applications is generally a degenerate case of a distinct flow.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-262

Configuring RSVP Planning for RSVP Configuration

Shared Reservation
An example of a shared reservation also is an audio application in which each sender emits a distinct data stream that requires admission and management in a queue. However, because of the nature of the application, a limited number of senders are sending data at any given time. Such a flow, therefore, does not require a separate reservation per sender. Instead, it uses a single reservation that can be applied to any sender within a set as needed. RSVP installs a shared reservation using a Wild Card or Shared Explicit style of reservation, with the difference between the two determined by the scope of application (which is either wild or explicit):

The Wild Card Filter reserves bandwidth and delay characteristics for any sender and is limited by the list of source addresses carried in the reservation message. The Shared Explicit style of reservation identifies the flows for specific network resources.

Planning for RSVP Configuration

You must plan carefully to successfully configure and use RSVP on your network. At a minimum, RSVP must reflect your assessment of bandwidth needs on router interfaces. Consider the following questions as you plan for RSVP configuration:

How much bandwidth should RSVP allow per end-user application flow? You must understand the feeds and speeds of your applications. By default, the amount reservable by a single flow can be the entire reservable bandwidth. You can, however, limit individual reservations to smaller amounts using the single flow bandwidth parameter. The reserved bandwidth value may not exceed the interface reservable amount, and no one flow may reserve more than the amount specified. How much bandwidth is available for RSVP? By default, 75 percent of the bandwidth available on an interface is reservable. If you are using a tunnel interface, RSVP can make a reservation for the tunnel whose bandwidth is the sum of the bandwidths reserved within the tunnel. How much bandwidth must be excluded from RSVP so that it can fairly provide the timely service required by low-volume data conversations? End-to-end controls for data traffic assume that all sessions will behave so as to avoid congestion dynamically. Real-time demands do not follow this behavior. Determine the bandwidth to set aside so bursty data traffic will not be deprived as a side effect of the RSVP QoS configuration.

Note

Before entering RSVP configuration commands, you must plan carefully.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-263

Configuring RSVP Planning for RSVP Configuration

RSVP Implementation Considerations

You should be aware of RSVP implementation considerations as you design your reservation system. RSVP does not model all data links likely to be present on the internetwork. RSVP models an interface as having a queueing system that completely determines the mix of traffic on the interface; bandwidth or delay characteristics are only deterministic to the extent that this model holds. Unfortunately, data links are often imperfectly modeled this way. Use the following guidelines:

Serial line interfacesPPP; HDLC; Link Access Procedure, Balanced (LAPB); High-Speed Serial Interface (HSSI); and similar serial line interfaces are well modeled by RSVP. The device can, therefore, make guarantees on these interfaces. Nonbroadcast multiaccess (NBMA) interfaces are also most in need of reservations. Multiaccess LANsThese data links are not modeled well by RSVP interfaces because the LAN itself represents a queueing system that is not under the control of the device making the guarantees. The device guarantees which load it will offer, but cannot guarantee the competing loads or timings of loads that neighboring LAN systems will offer. The network administrator can use admission controls to control how much traffic is placed on the LAN. The network administrator, however, should focus on the use of admission in network design in order to use RSVP effectively. The Subnetwork Bandwidth Manager (SBM) protocol is an enhancement to RSVP for LANs. One device on each segment is elected the Designated SBM (DSBM). The DSBM handles all reservations on the segment, which prevents multiple RSVP devices from granting reservations and overcommitting the shared LAN bandwidth. The DSBM can also inform hosts of how much traffic they are allowed to send without valid RSVP reservations.

Public X.25 networksIt is not clear that rate or delay reservations can be usefully made on public X.25 networks.

You must use a specialized configuration on Frame Relay and ATM networks, as discussed in the next sections.

Frame Relay Internetwork Considerations

The following RSVP implementation considerations apply as you design your reservation system for a Frame Relay internetwork:

Reservations are made for an interface or subinterface. If subinterfaces contain more than one data-link control (DLC), the bandwidth required and the bandwidth reserved may differ. Therefore, RSVP subinterfaces of Frame Relay interfaces must contain exactly one DLC to operate correctly. In addition, Frame Relay DLCs have committed information rates (CIR) and burst controls (Committed Burst and Excess Burst) that may not be reflected in the configuration and may differ markedly from the interface speed (either adding up to exceed it or being substantially smaller). Therefore, the ip rsvp bandwidth interface configuration command must be entered for both the interface and the subinterface. Both bandwidths are used as admission criteria.

For example, suppose that a Frame Relay interface runs at a T1 rate (1.544 Mbps) and supports several DLCs to remote offices served by 128-kbps and 56-kbps lines. You must configure the amount of the total interface (75 percent of which is 1.158 Mbps) and the amount of each receiving interface (75 percent of which would be 96 and 42 kbps, respectively) that may be reserved. Admission succeeds only if enough bandwidth is available on the DLC (the subinterface) and on the aggregate interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-264

Configuring RSVP Resource Reservation Protocol Configuration Task List

ATM Internetwork Considerations

The following RSVP implementation considerations apply as you design your reservation system for an ATM internetwork:

When ATM is configured, it most likely uses a usable bit rate (UBR) or an available bit rate (ABR) virtual channel (VC) connecting individual routers. With these classes of service, the ATM network makes a best effort to meet the bit-rate requirements of the traffic and assumes that the end stations are responsible for information that does not get through the network. This ATM service can open separate channels for reserved traffic having the necessary characteristics. RSVP should open these VCs and adjust the cache to make effective use of the VC for this purpose.

Resource Reservation Protocol Configuration Task List

After you have planned your RSVP configuration, enter the Cisco IOS commands that implement your configuration plan. To configure RSVP, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Enabling RSVP (Required) Entering Senders in the RSVP Database (Optional) Entering Receivers in the RSVP Database (Optional) Specifying Multicast Destinations (Optional) Controlling Which RSVP Neighbor Can Offer a Reservation (Optional) Enabling RSVP to Attach to NetFlow (Optional) Setting the IP Precedence and ToS Values (Optional) Monitoring RSVP (Optional)

See the end of this chapter for the section RSVP Configuration for a Multicast Session Example.

Enabling RSVP
By default, RSPV is disabled so that it is backward compatible with systems that do not implement RSVP. To enable RSVP for IP on an interface, use the following command in interface configuration mode: Command
Router(config-if)# ip rsvp bandwidth [interface-kbps] [single-flow-kbps]

Purpose Enables RSVP for IP on an interface.

This command starts RSVP and sets the bandwidth and single-flow limits. The default maximum bandwidth is up to 75 percent of the bandwidth available on the interface. By default, the amount reservable by a flow can be up to the entire reservable bandwidth.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-265

Configuring RSVP Resource Reservation Protocol Configuration Task List

On subinterfaces, this command applies the more restrictive of the available bandwidths of the physical interface and the subinterface. For example, a Frame Relay interface might have a T1 connector nominally capable of 1.536 Mbps, and 64-kbps subinterfaces on 128-kbps circuits (64-kbps CIR). RSVP bandwidth can be configured on the main interface up to 1200 kbps, and on each subinterface up to 100 kbps. Reservations on individual circuits that do not exceed 100 kbps normally succeed. If, however, reservations have been made on other circuits adding up to 1.2 Mbps, and a reservation is made on a subinterface that itself has enough remaining bandwidth, the reservation request will still be refused because the physical interface lacks supporting bandwidth.

Entering Senders in the RSVP Database

You can configure the router to behave as though it is periodically receiving an RSVP PATH message from the sender or previous hop routes containing the indicated attributes. To enter senders in the RSVP database, use the following command in global configuration mode: Command
Router(config)# ip rsvp sender session-ip-address sender-ip-address [tcp | udp | ip-protocol] session-dport sender-sport previous-hop-ip-address previous-hop-interface bandwidth burst-size

Purpose Enters the senders in the RSVP database. Enables a router to behave like it is receiving and processing RSVP PATH messages.

The related ip rsvp sender-host command enables a router to simulate a host generating RSVP PATH messages. It is used mostly for debugging and testing purposes.

Entering Receivers in the RSVP Database

You can configure the router to behave as though it is continuously receiving an RSVP RESV message from the originator containing the indicated attributes. To enter receivers in the RSVP database, use the following command in global configuration mode: Command
Router(config)# ip rsvp reservation session-ip-address sender-ip-address [tcp | udp | ip-protocol] session-dport sender-sport next-hop-ip-address next-hop-interface {ff | se | wf} {rate | load} bandwidth burst-size

Purpose Enters the receivers in the RSVP database. Enables a router to behave like it is receiving and processing RSVP RESV messages.

The related ip rsvp reservation-host command enables a router to simulate a host generating RSVP RESV messages. It is used mostly for debugging and testing purposes.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-266

Configuring RSVP Resource Reservation Protocol Configuration Task List

Specifying Multicast Destinations

If RSVP neighbors are discovered to be using User Datagram Protocol (UDP) encapsulation, the router will automatically generate UDP-encapsulated messages for consumption by the neighbors. However, in some cases, a host will not originate such a message until it has first heard from the router, which it can only do via UDP. You must instruct the router to generate UDP-encapsulated RSVP multicasts whenever it generates an IP-encapsulated multicast. To specify multicast destinations that should receive UDP-encapsulated messages, use the following command in global configuration mode: Command
Router(config)# ip rsvp udp-multicasts [multicast-address]

Purpose Specifies multicast destinations that should receive UDP-encapsulated messages.

Controlling Which RSVP Neighbor Can Offer a Reservation

By default, any RSVP neighbor may offer a reservation request. To control which RSVP neighbors can offer a reservation request, use the following command in global configuration mode: Command
Router(config)# ip rsvp neighbor access-list-number

Purpose Limits which routers may offer reservations.

When this command is configured, only neighbors conforming to the access list are accepted. The access list is applied to the IP header.

Enabling RSVP to Attach to NetFlow

To enable RSVP to attach itself to NetFlow so that it can receive information about packets in order to update its token bucket and set IP precedence as required, use the following command in interface configuration mode: Command
Router(config-if)# ip rsvp flow-assist

Purpose Enables RSVP to attach itself to NetFlow.

This task is optional for the following reason: When the interface is configured with the ip rsvp svc-required command to use ATM switched virtual circuits (SVCs), RSVP automatically attaches itself to NetFlow to perform packet flow identification (in which case you need not perform this task). However, if you want to perform IP Precedence-type of service (ToS) bit setting in every packet without using ATM SVCs, then you must use the ip rsvp flow-assist command to instruct RSVP to attach itself to NetFlow.

Note

If you use WFQ, then the ToS and IP Precedence bits will be set only on data packets that RSVP sees, due to congestion.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-267

Configuring RSVP Resource Reservation Protocol Configuration Task List

Setting the IP Precedence and ToS Values

To configure the IP Precedence and ToS values to be used to mark packets in an RSVP reserved path that either conform to or exceed the RSVP flow specification (flowspec), use the following commands in interface configuration mode: Command
Step 1 Step 2
Router(config-if)# ip rsvp precedence {conform precedence-value | exceed precedence-value} Router(config-if)# ip rsvp tos {conform tos-value | exceed tos-value}

Purpose Sets the IP Precedence conform and exceed values. Sets the ToS conform and exceed values.

Note

You must configure the ip rsvp flow-assist command if you want to set IP Precedence or ToS values in every packet and you are not using ATM SVCs; that is, you have not configured the ip rsvp svc-required command. The ToS byte in the IP header defines the three high-order bits as IP Precedence bits and the five low-order bits as ToS bits. The router software checks the source and destination addresses and port numbers of a packet to determine if the packet matches an RSVP reservation. If a match exists, as part of its input processing, RSVP checks the packet for conformance to the flowspec of the reservation. During this process, RSVP determines if the packet conforms to or exceeds the flowspec, and it sets the IP header IP Precedence and ToS bits of the packet accordingly. These IP Precedence and ToS bit settings are used by per-VC Distributed Weighted Random Early Detection (DWRED) on the output interface, and they can be used by interfaces on downstream routers. The combination of scheduling performed by the Enhanced ATM port adapter (PA-A3) and the per-SVC DWRED drop policy ensures that any packet that matches a reservation but exceeds the flowspec (that is, it does not conform to the token bucket for the reservation) is treated as if it were a best-effort packet. It is sent on the SVC for the reservation, but its IP precedence is marked to ensure that it does not interfere with conforming traffic. To display the configured IP Precedence bit values and ToS bit values for an interface, use the show ip rsvp command.

Monitoring RSVP
To allow a user on a remote management station to monitor RSVP-related information, use the following command in global configuration mode: Command
Router(config)# snmp-server enable traps rsvp

Purpose Sends RSVP notifications.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-268

Configuring RSVP RSVP Configuration for a Multicast Session Example

After you configure the RSVP reservations that reflect your network resource policy, to verify the resulting RSVP operations, use the following commands in EXEC mode, as needed: Command
Router# show ip rsvp interface [type number] Router# show ip rsvp installed [type number] Router# show ip rsvp neighbor [type number] Router# show ip rsvp sender [type number] Router# show ip rsvp request [type number] Router# show ip rsvp reservation [type number]

Purpose Displays RSVP-related interface information. Displays RSVP-related filters and bandwidth information. Displays current RSVP neighbors. Displays RSVP sender information. Displays RSVP request information. Displays RSVP receiver information.

RSVP Configuration for a Multicast Session Example

This section describes configuration of RSVP on three Cisco 4500 routers for a multicast session. For information on how to configure RSVP, see the section Resource Reservation Protocol Configuration Task List in this chapter. The three routers form the router network between an RSVP sender application running on an upstream (end system) host and an RSVP receiver application running on a downstream (end system) hostneither host is shown in this example. The router network includes three routers: Router A, Router B, and Router C. The example presumes that the upstream High-Speed Serial Interface (HSSI) interface 0 of Router A links to the upstream host. Router A and Router B are connected by the downstream Ethernet interface1 of Router A, which links to the upstream interface Ethernet 1 of Router B. Router B and Router C are connected by the downstream HSSI interface 0 of Router B, which links to the upstream HSSI interface 0 of Router C. The example presumes that the downstream Ethernet interface 2 of Router C links to the downstream host. Typically, an RSVP-capable application running on an end system host on one side of a router network sends either unicast or multicast RSVP PATH (Set Up) messages to the destination end system or host on the other side of the router network with which it wishes to communicate. The initiating application is referred to as the sender; the target or destination application is called the receiver. In this example, the sender runs on the host upstream from Router A and the receiver runs on the host downstream from Router C. The router network delivers the RSVP PATH messages from the sender to the receiver. The receiver replies with RSVP RESV messages in an attempt to reserve across the network the requested resources that are required between itself and the sender. The RSVP RESV messages specify the parameters for the requisite QoS that the router network connecting the systems should attempt to offer. This example does not show the host that would run the sender application and the host that would run the receiver application. Normally, the first router downstream from the sender in the router networkin this case, Router Awould receive the RSVP PATH message from the sender. Normally, the last router in the router networkthat is, the next hop upstream from the host running the receiver application, in this case, Router Cwould receive an RSVP RESV message from the receiver. Because this example does not explicitly include the hosts on which the sender and receiver applications run, the routers have been configured to act as if they were receiving PATH messages from a sender and RESV messages from a receiver. The commands used for this purpose, allowing RSVP to be more fully illustrated in the example, are the ip rsvp sender command and the ip rsvp reservation command. On Router A, the following command has been issued:

Cisco IOS Quality of Service Solutions Configuration Guide

QC-269

Configuring RSVP RSVP Configuration for a Multicast Session Example

ip rsvp sender 225.1.1.1 12.1.2.1 UDP 7001 7000 12.1.2.1 Hs0 20 1

This command causes the router to act as if it were receiving PATH messages destined to multicast address 225.1.1.1 from a source 12.1.2.1. The previous hop of the PATH message is 12.1.2.1, and the message was received on HSSI interface 0. On Router B, the following command has been issued:
ip rsvp reservation 225.1.1.1 12.1.2.1 UDP 7001 7000 9.1.2.1 Et2 FF LOAD 8 1

This command causes the router to act as if it were receiving RESV messages for the session with multicast destination 225.1.1.1. The messages request a Fixed Filter reservation to source 12.1.2.1, and act as if they had arrived from a receiver on Ethernet interface 2 with address 9.1.2.1. In the example, the RSVP PATH messages flow in one direction: downstream from the sender, which in this example is Router A. (If the host were to initiate the RSVP PATH message, the message would flow from the host to Router A.) Router A sends the message downstream to Router B, and Router B sends it downstream to Router C. (If the downstream host were the actual receiver, Router C would send the RSVP PATH message downstream to the receiver host.) Each router in the router network must process the RSVP PATH message and route it to the next downstream hop. The RSVP RESV messages flow in one direction: upstream from the receiver (in this example, Router C), upstream from Router C to Router B, and upstream from Router B to Router A. If the downstream host were the receiver, the message would originate with the host, which would send it to Router C. If the upstream host were the sender, the final destination of the RSVP RESV message would be the upstream host. At each hop, the router receiving the RSVP RESV message must determine whether it can honor the reservation request. The ip rsvp bandwidth command both enables RSVP on an interface and specifies the amount of bandwidth on the interface that can be reserved (and the amount of bandwidth that can be allocated to a single flow). To ensure QoS for the RSVP reservation, WFQ is configured on the interfaces enabled for the reservation. If the router network is capable of offering the specified (QoS) level of service, then an end-to-end reserved path is established. If not, the reservation attempt is rejected and a RESV ERROR message is sent to the receiver. The ability of each router in the network to honor the requested level of service is verified, link by link, as the RSVP RESV messages are sent across the router network to the sender. However, the data itself for which the bandwidth is reserved travels one way only: from the sender to receiver across an established PATH. Therefore, the QoS is effective in only one direction. This is the common case for one-to-many multicast data flows. After the three routers in the example are configured, the show ip rsvp sender and show ip rsvp reservation commands will make visible the PATH and RESV state.
Router A Configuration

On Router A, RSVP is enabled on Ethernet interface 1 with 10 kbps to be reserved for the data transmission. A weighted fair queue is reserved on this interface to ensure RSVP QoS. (On Router A, RSVP is also enabled on HSSI interface 0 with 1 kbps reserved, but this bandwidth is used simply for passing messages.)
! version 12.0 service config service timestamps debug uptime service timestamps log uptime no service password-encryption service udp-small-servers service tcp-small-servers ! hostname routerA

Cisco IOS Quality of Service Solutions Configuration Guide

QC-270

Configuring RSVP RSVP Configuration for a Multicast Session Example

! ip subnet-zero no ip domain-lookup ip multicast-routing ip dvmrp route-limit 20000 ! ! interface Ethernet0 ip address 2.0.0.193 255.0.0.0 no ip directed-broadcast no ip route-cache no ip mroute-cache media-type 10BaseT ! interface Ethernet1 ip address 11.1.1.2 255.0.0.0 no ip directed-broadcast ip pim dense-mode ip rsvp bandwidth 10 10 fair-queue 64 256 1000 media-type 10BaseT ! interface Hssi0 ip address 12.1.1.1 255.0.0.0 no ip directed-broadcast ip pim dense-mode ip rsvp bandwidth 1 1 ! interface ATM0 no ip address no ip directed-broadcast shutdown ! router ospf 100 network 11.0.0.0 0.255.255.255 area 10 network 12.0.0.0 0.255.255.255 area 10 ! ip classless ip rsvp sender 225.1.1.1 12.1.2.1 UDP 7001 7000 12.1.2.1 Hs0 20 1 ! line con 0 exec-timeout 0 0 length 0 transport input none line aux 0 line vty 0 4 login ! end

Router B Configuration

On Router B, RSVP is enabled on HSSI interface 0 with 20 kbps to be reserved for the data transmission. A weighted fair queue is reserved on this interface to ensure RSVP QoS. (On Router B, RSVP is also enabled on Ethernet interface 1 with 1 kbps reserved, but this bandwidth is used simply for passing messages.)
! version 12.0 service config service timestamps debug uptime service timestamps log uptime no service password-encryption service udp-small-servers

Cisco IOS Quality of Service Solutions Configuration Guide

QC-271

Configuring RSVP RSVP Configuration for a Multicast Session Example

service tcp-small-servers ! hostname routerB ! ip subnet-zero no ip domain-lookup ip multicast-routing ip dvmrp route-limit 20000 clock calendar-valid ! interface Ethernet0 ip address 2.0.0.194 255.0.0.0 no ip directed-broadcast no ip route-cache no ip mroute-cache media-type 10BaseT ! interface Ethernet1 ip address 11.1.1.1 255.0.0.0 no ip directed-broadcast ip pim dense-mode ip rsvp bandwidth 1 1 media-type 10BaseT ! interface Hssi0 ip address 10.1.1.2 255.0.0.0 no ip directed-broadcast ip pim dense-mode ip rsvp bandwidth 20 20 fair-queue 64 256 1000 hssi internal-clock ! interface ATM0 no ip address no ip directed-broadcast shutdown ! router ospf 100 network 10.0.0.0 0.255.255.255 area 10 network 11.0.0.0 0.255.255.255 area 10 ! ip classless ! line con 0 exec-timeout 0 0 length 0 transport input none line aux 0 line vty 0 4 login ! end

Router C Configuration

On Router C, RSVP is enabled on Ethernet interface 2 with 20 kbps to be reserved for the data transmission. A weighted fair queue is reserved on this interface to ensure RSVP QoS. (On Router C, RSVP is also enabled on HSSI interface 0 with 1 kbps reserved, but this bandwidth is used simply for passing messages.)
! version 12.0 service config service timestamps debug uptime

Cisco IOS Quality of Service Solutions Configuration Guide

QC-272

Configuring RSVP RSVP Configuration for a Multicast Session Example

service timestamps log uptime no service password-encryption service udp-small-servers service tcp-small-servers ! hostname routerC ! ip subnet-zero no ip domain-lookup ip multicast-routing ip dvmrp route-limit 20000 ! interface Ethernet0 ip address 2.0.0.195 255.0.0.0 no ip directed-broadcast no ip route-cache no ip mroute-cache media-type 10BaseT ! interface Ethernet1 no ip address no ip directed-broadcast shutdown media-type 10BaseT ! interface Ethernet2 ip address 9.1.1.2 255.0.0.0 no ip directed-broadcast ip pim dense-mode ip rsvp bandwidth 20 20 fair-queue 64 256 1000 media-type 10BaseT ! interface Ethernet3 no ip address no ip directed-broadcast shutdown media-type 10BaseT ! interface Ethernet4 no ip address no ip directed-broadcast shutdown media-type 10BaseT ! interface Ethernet5 no ip address no ip directed-broadcast shutdown media-type 10BaseT ! interface Hssi0 ip address 10.1.1.1 255.0.0.0 no ip directed-broadcast ip pim dense-mode ip rsvp bandwidth 1 1 hssi internal-clock ! interface ATM0 no ip address no ip directed-broadcast shutdown ! router ospf 100

Cisco IOS Quality of Service Solutions Configuration Guide

QC-273

Configuring RSVP RSVP Configuration for a Multicast Session Example

network 9.0.0.0 0.255.255.255 area 10 network 10.0.0.0 0.255.255.255 area 10 network 11.0.0.0 0.255.255.255 area 10 ! ip classless ip rsvp reservation 225.1.1.1 12.1.2.1 UDP 7001 7000 9.1.2.1 Et2 FF LOAD 8 1 ! line con 0 exec-timeout 0 0 length 0 transport input none line aux 0 line vty 0 4 login ! end

Cisco IOS Quality of Service Solutions Configuration Guide

QC-274

Configuring RSVP Support for LLQ

This chapter describes the tasks for configuring the RSVP Support for Low Latency Queueing (LLQ) feature. For complete conceptual information, see the section RSVP Support for Low Latency Queueing in the chapter Signalling Overview in this book. For a complete description of the RSVP Support for LLQ commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

RSVP Support for LLQ Configuration Task List

To configure RSVP support for LLQ, perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.

Configuring Flow Classification (Required) Enabling RSVP and WFQ (Required) Configuring a Burst Factor (Optional) Configuring a Path (Optional) Configuring a Reservation (Optional) Verifying RSVP Support for LLQ Configuration (Optional) Monitoring and Maintaining RSVP Support for LLQ (Optional)

See the end of this chapter for the section RSVP Support for LLQ Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-275

Configuring RSVP Support for LLQ RSVP Support for LLQ Configuration Task List

Configuring Flow Classification

To configure flow classification, use the following command in global configuration mode: Command
Router#(config)# ip rsvp pq-profile

Purpose Specifies the criteria for determining which flows go into the priority queue.

Enabling RSVP and WFQ

To enable RSVP and weighted fair queueing (WFQ), use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3
Router(config)# interface s2/0

Purpose Enables an interface; for example, serial interface 2/0. Enables RSVP on an interface. Enables WFQ on an interface with priority queueing (PQ) support.

Router(config-if)# ip rsvp bandwidth Router(config-if)# fair-queue

Configuring a Burst Factor

To configure a burst factor, use the following command in interface configuration mode: Command
Router(config-if)# ip rsvp burst policing

Purpose Specifies a burst factor on a per-interface basis.

Configuring a Path
To configure a path, use the following command in global configuration mode: Command
Router(config)# ip rsvp sender

Purpose Specifies the RSVP path parameters, including the destination and source addresses, the protocol, the destination and source ports, the previous hop address, the average bit rate, and the burst size.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-276

Configuring RSVP Support for LLQ RSVP Support for LLQ Configuration Task List

Configuring a Reservation
To configure a reservation, use the following command in global configuration mode: Command
Router(config)# ip rsvp reservation

Purpose Specifies the RSVP reservation parameters, including the destination and source addresses, the protocol, the destination and source ports, the next hop address, the input interface, the service type, the average bit rate, and the burst size.

Verifying RSVP Support for LLQ Configuration

To verify RSVP support for LLQ configuration, perform the following steps:
Step 1

Enter the show ip rsvp installed command to display information about interfaces and their admitted reservations. A sample output is shown. This output shows that Ethernet interface 2/1 has four reservations and serial interface 3/0 has none.
Router# show ip rsvp installed RSVP:Ethernet2/1 BPS To From Protoc 44K 145.20.0.202 145.10.0.201 UDP 44K 145.20.0.202 145.10.0.201 UDP 98K 145.20.0.202 145.10.0.201 UDP 1K 145.20.0.202 145.10.0.201 UDP RSVP:Serial3/0 has no installed reservations Router#

DPort 1000 1001 1002 10

Sport 1000 1001 1002 10

Weight 0 13 6 0

Conversation 264 266 265 264

Note

In the sample output, weight 0 is assigned to voice-like flows, which proceed to the priority queue.

Step 2

Enter the show ip rsvp installed detail command to display additional information about interfaces and their current reservations. A sample output is shown.
Router# show ip rsvp installed detail RSVP:Ethernet2/1 has the following installed reservations RSVP Reservation. Destination is 145.20.0.202, Source is 145.10.0.201, Protocol is UDP, Destination port is 1000, Source port is 1000 Reserved bandwidth:44K bits/sec, Maximum burst:1K bytes, Peak rate:44K bits/sec Resource provider for this flow: WFQ on hw idb Se3/0: PRIORITY queue 264. Weight:0, BW 44 kbps Conversation supports 1 reservations Data given reserved service:316 packets (15800 bytes) Data given best-effort service:0 packets (0 bytes) Reserved traffic classified for 104 seconds Long-term average bitrate (bits/sec):1212 reserved, 0M best-effort RSVP Reservation. Destination is 145.20.0.202, Source is 145.10.0.201, Protocol is UDP, Destination port is 1001, Source port is 1001 Reserved bandwidth:44K bits/sec, Maximum burst:3K bytes, Peak rate:44K bits/sec

Cisco IOS Quality of Service Solutions Configuration Guide

QC-277

Configuring RSVP Support for LLQ RSVP Support for LLQ Configuration Examples

Resource provider for this flow: WFQ on hw idb Se3/0: RESERVED queue 266. Weight:13, BW 44 kbps Conversation supports 1 reservations Data given reserved service:9 packets (450 bytes) Data given best-effort service:0 packets (0 bytes) Reserved traffic classified for 107 seconds Long-term average bitrate (bits/sec):33 reserved, 0M best-effort RSVP Reservation. Destination is 145.20.0.202, Source is 145.10.0.201, Protocol is UDP, Destination port is 1002, Source port is 1002 Router#

Note

In the sample output, the first flow gets the priority queue (weight = 0) while the second flow does not.

Monitoring and Maintaining RSVP Support for LLQ

To monitor and maintain the RSVP Support for LLQ feature, use the following commands in EXEC mode, as needed: Command
Router# show ip rsvp installed

Purpose Displays information about interfaces and their admitted reservations. Displays additional information about interfaces and their admitted reservations. Displays queueing configuration and statistics for a particular interface.

Router# show ip rsvp installed detail

Router# show queue interface-type interface-number

RSVP Support for LLQ Configuration Examples

This section provides a configuration example for the RSVP Support for LLQ feature. For information about configuring RSVP support for LLQ, see the section RSVP Support for LLQ Configuration Task List in this chapter. In the following example, PQ parameters, including flow rate and burst factor, are defined:
Router(config)# ip rsvp pq-profile ? <1-1048576> voice-like <cr> Max Flow Rate (bytes/second) Voice-like flows

Router(config)# ip rsvp pq-profile 11000 1500 ? <100-4000> ignore-peak-value <cr> Max Peak to Average Ratio (in %) Ignore the flow's p/r ratio

Router(config)# ip rsvp pq-profile 11000 1500 ignore-peak-value Router(config)# end

Cisco IOS Quality of Service Solutions Configuration Guide

QC-278

Configuring RSVP Support for LLQ RSVP Support for LLQ Configuration Examples

Router# sh run | include pq-profile ip rsvp pq-profile 11000 1500 ignore-peak-value

In the following example, RSVP is enabled:

Router# configure terminal Enter configuration commands, one per line. Router(config)# interface loopback 40 Router(config-if)# ip rsvp bandwidth ? <1-10000000> Reservable Bandwidth(KBPS) <cr> Router(config-if)# ip rsvp bandwidth 300 ? <1-10000000> Largest Reservable Flow(KBPS) <cr> Router(config-if)# ip rsvp bandwidth 300 30 ? <cr> Router(config-if)# ip rsvp bandwidth 300 30 Router(config-if)# end End with CNTL/Z.

In the following example, WFQ is enabled:

Router# configure terminal Enter configuration commands, one per line. Router(config)# interface e0/1 Router(config-if)# fair-queue Router(config-if)# fair-queue 64 End with CNTL/Z.

In the following example, a burst factor is configured:

Router(config)# interface e3/0 Router(config-if)# ip rsvp burst policing 200

In the following example, a path is defined:

Router(config)# ip rsvp sender 145.20.20.202 145.10.10.201 udp 10 20 145.10.10.201 loopback 10 80 10

In the following example, a reservation is defined:

Router(config)# ip rsvp reservation 145.20.20.202 145.10.10.201 udp 10 20 145.20.20.202 lo20 ff load 80 10

Cisco IOS Quality of Service Solutions Configuration Guide

QC-279

Configuring RSVP Support for LLQ RSVP Support for LLQ Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-280

Configuring RSVP Support for Frame Relay

This chapter describes the tasks for configuring the RSVP Support for Frame Relay feature. For complete conceptual information, see the section RSVP Support for Frame Relay in the chapter Signalling Overview in this book. For a complete description of the RSVP Support for Frame Relay commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

RSVP Support for Frame Relay Configuration Task List

To configure Resource Reservation Protocol (RSVP) support for Frame Relay, perform the tasks described in the following sections. Each task is identified as either optional or required.

Enabling Frame Relay Encapsulation on an Interface (Required) Configuring a Virtual Circuit (Required) Enabling Frame Relay Traffic Shaping on an Interface (Required) Enabling Enhanced Local Management Interface (Optional) Enabling RSVP on an Interface (Required) Specifying a Traffic Shaping Map Class for an Interface (Required) Defining a Map Class with WFQ and Traffic Shaping Parameters (Required) Specifying the CIR (Required) Specifying the Minimum CIR (Optional) Enabling WFQ (Required) Enabling FRF.12 (Required) Configuring a Path (Optional) Configuring a Reservation (Optional)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-281

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Task List

Verifying RSVP Support for Frame Relay (Optional) Monitoring and Maintaining RSVP Support for Frame Relay (Optional)

See the end of this chapter for the section RSVP Support for Frame Relay Configuration Examples.

Enabling Frame Relay Encapsulation on an Interface

To enable Frame Relay encapsulation on an interface, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# interface s3/0

Purpose Enables an interface (for example, serial interface 3/0) and enters configuration interface mode. Enables Frame Relay and specifies the encapsulation method.

Router(config-if)# encapsulation frame-relay [cisco | ietf]

Configuring a Virtual Circuit

To configure a virtual circuit (VC), use the following command in interface configuration mode: Command
Router(config-if)# frame-relay interface-dlci dlci

Purpose Assigns a data-link connection identifier (DLCI) to a specified Frame Relay subinterface on a router or access server.

Enabling Frame Relay Traffic Shaping on an Interface

To enable Frame Relay Traffic Shaping (FRTS) on an interface, use the following command in interface configuration mode: Command
Router(config-if)# frame-relay traffic-shaping

Purpose Enables traffic shaping and per-VC queueing for all permanent virtual circuits (PVCs) and switched virtual circuits (SVCs) on a Frame Relay interface.

Enabling Enhanced Local Management Interface

To enable enhanced Local Management Interface (LMI), use the following command in interface configuration mode: Command
Router(config-if)# frame-relay lmi-type

Purpose Selects the LMI type.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-282

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Task List

Enabling RSVP on an Interface

To enable RSVP on an interface, use the following command in interface configuration mode: Command
Router(config-if)# ip rsvp bandwidth

Purpose Enables RSVP on an interface.

Specifying a Traffic Shaping Map Class for an Interface

To specify a traffic shaping map class for an interface, use the following command in interface configuration mode: Command
Router(config-if)# frame-relay class name

Purpose Associates a map class with an interface or subinterface.

Defining a Map Class with WFQ and Traffic Shaping Parameters

To define a map class with weighted fair queueing (WFQ) and traffic shaping parameters, use the following command in global configuration mode: Command
Router(config)# map-class frame-relay map-class-name

Purpose Defines parameters for a specified class.

Specifying the CIR

To specify the committed information rate (CIR), use the following command in map-class configuration mode: Command
Router(config-map-class)# frame-relay cir {in | out} bps

Purpose Specifies the maximum incoming or outgoing CIR for a Frame Relay VC.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-283

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Task List

Specifying the Minimum CIR

To specify the minimum acceptable incoming or outgoing CIR (minCIR) for a Frame Relay VC, use the following command in map-class configuration mode: Command
Router(config-map-class)# frame-relay mincir {in | out} bps

Purpose Specifies the minimum acceptable incoming or outgoing CIR for a Frame Relay VC.
Note

If the minCIR is not configured, then the admission control value is the CIR/2.

Enabling WFQ
To enable WQF, use the following command in map-class configuration mode: Command
Router(config-map-class)# frame-relay fair-queue

Purpose Enables WFQ on a PVC.

Enabling FRF.12
To enable FRF.12, use the following command in map-class configuration mode: Command
Router(config-map-class)# frame-relay fragment fragment-size

Purpose Enables Frame Relay fragmentation on a PVC.

Configuring a Path
To configure a path, use the following command in global configuration mode: Command
Router(config)# ip rsvp sender

Purpose Specifies the RSVP path parameters, including the destination and source addresses, the protocol, the destination and source ports, the previous hop address, the average bit rate, and the burst size.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-284

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Task List

Configuring a Reservation
To configure a reservation, use the following command in global configuration mode: Command
Router(config)# ip rsvp reservation

Purpose Specifies the RSVP reservation parameters, including the destination and source addresses, the protocol, the destination and source ports, the next hop address, the next hop interface, the reservation style, the service type, the average bit rate, and the burst size.

Verifying RSVP Support for Frame Relay

The following sections contain the procedures for verifying RSVP support for Frame Relay in either a multipoint configuration or a point-to-point configuration.

Multipoint Configuration
To verify RSVP support for Frame Relay in a multipoint configuration, perform the following steps:
Step 1

Enter the show ip rsvp installed command to display information about interfaces and their admitted reservations. The output in the following example shows that serial subinterface 3/0.1 has two reservations:
Router# show ip rsvp installed RSVP:Serial3/0 BPS To RSVP:Serial3/0.1 BPS To 40K 145.20.22.212 50K 145.20.21.212

From From 145.10.10.211 145.10.10.211

Protoc DPort Protoc DPort UDP 10 UDP 10

Sport Sport 10 10

Weight Conversation Weight Conversation 0 24 6 25

Note Step 2

Weight 0 is assigned to voice-like flows, which proceed to the priority queue. Enter the show ip rsvp installed detail command to display additional information about interfaces, subinterfaces, DLCI PVCs, and their current reservations.

Note

In the following output, the first flow gets a reserved queue with a weight > 0, and the second flow gets the priority queue with a weight = 0.
Router# show ip rsvp installed detail RSVP:Serial3/0 has the following installed reservations RSVP:Serial3/0.1 has the following installed reservations RSVP Reservation. Destination is 145.20.21.212, Source is 145.10.10.211, Protocol is UDP, Destination port is 10, Source port is 10 Reserved bandwidth:50K bits/sec, Maximum burst:1K bytes, Peak rate:50K bits/sec QoS provider for this flow: WFQ on FR PVC dlci 101 on Se3/0: RESERVED queue 25. Weight:6 Data given reserved service:0 packets (0M bytes)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-285

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Task List

Data given best-effort service:0 packets (0 bytes) Reserved traffic classified for 68 seconds Long-term average bitrate (bits/sec):0M reserved, 0M best-effort RSVP Reservation. Destination is 145.20.22.212, Source is 145.10.10.211, Protocol is UDP, Destination port is 10, Source port is 10 Reserved bandwidth:40K bits/sec, Maximum burst:1K bytes, Peak rate:40K bits/sec QoS provider for this flow: WFQ on FR PVC dlci 101 on Se3/0: PRIORITY queue 24. Weight:0 Data given reserved service:0 packets (0M bytes) Data given best-effort service:0 packets (0 bytes) Reserved traffic classified for 707 seconds Long-term average bitrate (bits/sec):0M reserved, 0M best-effort

Point-to-Point Configuration
To verify RSVP support for Frame Relay in a point-to-point configuration, perform the following steps:
Step 1

Enter the show ip rsvp installed command to display information about interfaces and their admitted reservations. The output in the following example shows that serial subinterface 3/0.1 has one reservation, and serial subinterface 3/0.2 has one reservation.
Router# show ip rsvp installed RSVP:Serial3/0 BPS To RSVP:Serial3/0.1 BPS To 50K 145.20.20.212 RSVP:Serial3/0.2 BPS To 10K 145.20.21.212

From From 145.10.10.211

Protoc DPort Protoc DPort UDP 10

Sport Sport 10

From 145.10.10.211

Protoc DPort UDP 11

Sport 11

Note Step 2

Weight 0 is assigned to voice-like flows, which proceed to the priority queue. Enter the show ip rsvp installed detail command to display additional information about interfaces, subinterfaces, DLCI PVCs, and their current reservations.

Note

In the following output, the first flow with a weight > 0 gets a reserved queue and the second flow with a weight = 0 gets the priority queue.
Router# show ip rsvp installed detail RSVP:Serial3/0 has the following installed reservations RSVP:Serial3/0.1 has the following installed reservations RSVP Reservation. Destination is 145.20.20.212, Source is 145.10.10.211, Protocol is UDP, Destination port is 10, Source port is 10 Reserved bandwidth:50K bits/sec, Maximum burst:1K bytes, Peak rate:50K bits/sec QoS provider for this flow: WFQ on FR PVC dlci 101 on Se3/0: RESERVED queue 25. Weight:6 Data given reserved service:415 packets (509620 bytes) Data given best-effort service:0 packets (0 bytes) Reserved traffic classified for 862 seconds Long-term average bitrate (bits/sec):4724 reserved, 0M best-effort RSVP Reservation. Destination is 145.20.20.212, Source is 145.10.10.211, Protocol is UDP, Destination port is 11, Source port is 11

Cisco IOS Quality of Service Solutions Configuration Guide

QC-286

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Examples

Reserved bandwidth:10K bits/sec, Maximum burst:1K bytes, Peak rate:10K bits/sec QoS provider for this flow: WFQ on FR PVC dlci 101 on Se3/0: PRIORITY queue 24. Weight:0 Data given reserved service:85 packets (104380 bytes) Data given best-effort service:0 packets (0 bytes) Reserved traffic classified for 875 seconds Long-term average bitrate (bits/sec):954 reserved, 0M best-effort RSVP:Serial3/0.2 has the following installedreservations RSVP Reservation. Destination is 145.20.21.212, Source is 145.10.10.211, Protocol is UDP, Destination port is 11, Source port is 11 Reserved bandwidth:10K bits/sec, Maximum burst:1K bytes, Peak rate:10Kbits/sec QoS provider for this flow: WFQ on FR PVC dlci 101 on Se3/0:PRIORITY queue 24. Weight:0 Data given reserved service:85 packets (104380 bytes) Data given best-effort service:0 packets (0 bytes) Reserved traffic classified for 875 seconds Long-term average bitrate (bits/sec):954 reserved, 0M best-effort

Monitoring and Maintaining RSVP Support for Frame Relay

To monitor and maintain RSVP support for Frame Relay, use the following commands in EXEC mode, as needed: Command
Router# show ip rsvp installed

Purpose Displays information about interfaces and their admitted reservations. Displays additional information about interfaces, DLCIs, and their admitted reservations. Displays all or selected configured queueing strategies.

Router# show ip rsvp installed detail

Router# show queueing

RSVP Support for Frame Relay Configuration Examples

The following sections provide RSVP support for Frame Relay configuration examples:

Multipoint Configuration Example Point-to-Point Configuration Example

For information on how to configure the RSVP Support for Frame Relay feature, see the section RSVP Support for Frame Relay Configuration Task List in this chapter.

Multipoint Configuration Example

Figure 22 shows a multipoint interface configuration commonly used in Frame Relay environments in which multiple PVCs are configured on the same subinterface at router R1.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-287

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Examples

Figure 22

Multipoint Interface Configuration

Customer enterprise network R1 Frame Relay access device

Interface bandwidth T1 1.544 Mbps CIR 800 kbps

Serial 3/0.1 10.1.1.1/16 CIR 200 kbps

DLCI 101 Frame Relay switch Interface bandwidth FT1 512 kbps Serial 3/1.1 10.1.1.2/16 Customer enterprise network R2 Frame Relay access device CIR 256 kbps Serial 3/1.2 10.2.1.1/16 DLCI 102

DLCI 201

Frame Relay service provider

DLCI 202

Serial 3/1.1 10.1.1.3/16 Customer enterprise network R3 Frame Relay access device

DLCI 301

DLCI 302

Serial 3/1.2 10.2.1.2/16

RSVP performs admission control based on the minCIR of DLCI 101 and DLCI 201. The congestion point is not the 10.1.1.1/16 subinterface, but the CIR of DLCI 101 and DLCI 201. The following example is a sample output for serial interface 3/0:
interface Serial3/0 no ip address encapsulation frame-relay max-reserved-bandwidth 20 no fair-queue frame-relay traffic-shaping frame-relay lmi-type cisco ip rsvp bandwidth 350 350 ! interface Serial3/0.1 multipoint ip address 10.1.1.1 255.255.0.0 frame-relay interface-dlci 101 class fr-voip frame-relay interface-dlci 201 class fast-vcs ip rsvp bandwidth 350 350 ip rsvp pq-profile 6000 2000 ignore-peak-value

Cisco IOS Quality of Service Solutions Configuration Guide

QC-288

45106

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Examples

! ! map-class frame-relay fr-voip frame-relay cir 800000 frame-relay bc 8000 frame-relay mincir 128000 frame-relay fragment 280 no frame-relay adaptive-shaping frame-relay fair-queue ! map-class frame-relay fast-vcs frame-relay cir 200000 frame-relay bc 2000 frame-relay mincir 60000 frame-relay fragment 280 no frame-relay adaptive-shaping frame-relay fair-queue !

Note

When FRTS is enabled, the Frame Relay Committed Burst (Bc) value (in bits) should be configured to a maximum of 1/100th of the CIR value (in bits per second). This configuration ensures that the FRTS token bucket interval (Bc/CIR) does not exceed 10 Ms, and that voice packets are serviced promptly.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-289

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Examples

Point-to-Point Configuration Example

Figure 23 shows a point-to-point interface configuration commonly used in Frame Relay environments in which one PVC per subinterface is configured at router R1.
Figure 23 Sample Point-to-Point Interface Configuration

Customer enterprise network R1 Interface bandwidth T1 1.544 Mbps Serial 3/0.1 10.1.1.1/16 CIR 800 kbps Serial 3/0.2 10.3.1.1/16 CIR 200 kbps Frame Relay access device

DLCI 101 Frame Relay switch Interface bandwidth FT1 512 kbps Serial 3/1.1 10.1.1.2/16 Customer enterprise network R2 Frame Relay access device CIR 256 kbps Serial 3/1.2 10.2.1.1/16 DLCI 102

DLCI 201

Frame Relay service provider

DLCI 202

Serial 3/1.1 10.1.1.2/16 Customer enterprise network R3 Frame Relay access device

DLCI 301

DLCI 302

Serial 3/1.2 10.2.1.2/16

Notice that the router interface bandwidth for R1 is T1 (1.544 Mbps), whereas the CIR value of DLCI 201 toward R3 is 256 kbps. For traffic flows from R1 to R3 over DLCI 201, the congestion point is the CIR for DLCI 201. As a result, RSVP performs admission control based on the minCIR and reserves resources, including queues and bandwidth, on the WFQ system that runs on each DLCI. The following example is sample output for serial interface 3/0:
interface Serial3/0 no ip address encapsulation frame-relay max-reserved-bandwidth 20 no fair-queue frame-relay traffic-shaping frame-relay lmi-type cisco ip rsvp bandwidth 500 500 !

Cisco IOS Quality of Service Solutions Configuration Guide

QC-290

45107

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Examples

interface Serial3/0.1 point-to-point ip address 10.1.1.1 255.255.0.0 frame-relay interface-dlci 101 class fr-voip ip rsvp bandwidth 350 350 ! interface Serial3/0.2 point-to-point ip address 10.3.1.1 255.255.0.0 frame-relay interface-dlci 201 class fast-vcs ip rsvp bandwidth 150 150 ip rsvp pq-profile 6000 2000 ignore-peak-value ! ! map-class frame-relay fr-voip frame-relay cir 800000 frame-relay bc 8000 frame-relay mincir 128000 frame-relay fragment 280 no frame-relay adaptive-shaping frame-relay fair-queue

Note

When FRTS is enabled, the Frame Relay Committed Burst (Bc) value (in bits) should be configured to a maximum of 1/100th of the CIR value (in bits per second). This configuration ensures that the FRTS token bucket interval (Bc/CIR) does not exceed 10 Ms, and that voice packets are serviced promptly.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-291

Configuring RSVP Support for Frame Relay RSVP Support for Frame Relay Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-292

Configuring RSVP-ATM QoS Interworking

This chapter describes the tasks for configuring the RSVP-ATM QoS Interworking feature, which provides support for Controlled Load Service using RSVP over an ATM core network. For complete conceptual information, see the section RSVP-ATM QoS Interworking in the chapter Signalling Overview in this book. For a complete description of the RSVP-ATM QoS Interworking commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

RSVP-ATM QoS Interworking Configuration Task List

To configure RSVP-ATM QoS Interworking, perform the tasks described in the following sections. Each task is identified as either optional or required.

Enabling RSVP and Limiting Reservable Bandwidth (Required) Enabling Creation of SVCs for Reserved Flows (Required) Limiting the Peak Rate Applied to the PCR for SVCs (Optional) Configuring per-VC DWRED (Required) Monitoring RSVP-ATM Configuration for an Interface (Optional)

Before you configure RSVP-ATM QoS Interworking, you must enable and configure the following features:

Cisco Express Forwarding (CEF) switching (required for RSVP-ATM) Distributed CEF (dCEF) (required for per-switched virtual circuit (SVC) DWRED) NetFlow services

For information on how to configure these features, refer to the Cisco IOS Switching Services Configuration Guide and the Cisco IOS Switching Services Command Reference. The RSVP-ATM QoS Interworking feature does not support Resource Reservation Protocol (RSVP) with multicast. See the end of this chapter for the section RSVP-ATM QoS Interworking Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-293

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Task List

Enabling RSVP and Limiting Reservable Bandwidth

RSVP allows end systems or hosts on either side of a router network to establish a reserved-bandwidth path between them to predetermine and ensure QoS for their data transmission. By default, RSVP is disabled so that it is backward compatible with systems that do not implement RSVP. To enable RSVP on an interface and restrict the total amount of bandwidth that can be reserved for RSVP and the amount that can be reserved for a single RSVP reservation or flow, use the following command in global configuration mode: Command
Router(config)# ip rsvp bandwidth [interface-kbps] [single-flow-kbps]

Purpose Enables RSVP for IP on an interface.

For RSVP over ATM, reservations are needed primarily between routers across the ATM backbone. To limit the number of locations where reservations are made, enable RSVP selectively only at subinterfaces corresponding to router-to-router connections across the backbone network. Preventing reservations being made between the host and the router both limits VC usage and reduces load on the router. The default maximum bandwidth is up to 75 percent of the bandwidth available on the interface. By default, the amount reservable by a flow can be up to the entire reservable bandwidth. On subinterfaces, the more restrictive of the available bandwidths of the physical interface and the subinterface is applied.

Enabling Creation of SVCs for Reserved Flows

Normally, reservations are serviced when RSVP classifies packets and a queueing mechanism polices the packet. To enable establishment of an SVC to service each new RSVP reservation on the interface, use the following command in interface configuration mode: Command
Router(config-if)# ip rsvp svc-required

Purpose Enables creation of an SVC for each new reservation made on the interface or subinterface.

To ensure defined QoS, SVCs created in response to RSVP reservation requests are established having QoS profiles consistent with the mapped RSVP flow specifications. The sustainable cell rate (SCR) of an ATM SVC is equal to the RSVP reservation rate; the maximum burst size (MBS) of an ATM SVC is equal to the RSVP burst size. RSVP attempts to compensate for the cell tax when establishing the reservation so that the requested bandwidth is actually available for IP data traffic. The sustained cell rate formula is given as follows:
r r

atm =

rsvp * (53/48) * (MPS + DLE + (MPS + DLE) % 48)/MPS

The formula terms used in the equation (and subsequent equations) are described in Table 14, followed by an explanation of how the formula was derived.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-294

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Task List

Table 14

SCR Formula Terms

Term
r r

Definition ATM rate (SCR). RSVP rate. Minimum IP packet size, including the IP headers (300 bytes minimum). Data-link encapsulation overhead. For RSVP ATM SVCs, ATM adaptation layer 5 (AAL5), Subnetwork Access Protocol (SNAP) encapsulation is used, which imposes a 5-byte encapsulation header on each protocol data unit (PDU). Modulus operator. It yields the integer remainder from an integer division operation. For example, 57 % 53 results in 4. Cell payload size. The total number of bytes in all the payloads of all the cells required to send a single packet with encapsulation. Unused cell overhead (0 to 47). Compensation factor. CPS divided by MPS.

atm rsvp

MPS DLE

% CPS UCO COMP

There are two reasons for converting from RSVP rate to the ATM cell rate, as follows:

To account for the ATM encapsulation header overhead and cell header overhead To account for the fact that ATM cell sizes are fixed

Because a portion of the last cell is unused, it is possible that a certain IP packet size requires more ATM cell layer bytes. MPS + DLE is the length of the data packet that needs to be segmented into a number of fixed-length (48-byte payload) pieces that would then be put into a cell and sent. Because the CPS needs to be greater than or equal to MPS + DLE, CPS must be larger than MPS. CPS can be calculated as follows:
CPS = ceil((MPS + DLE)/48) * 48

where ceil(x) is the ceiling operator that returns the smallest integer greater than or equal to the real number x. Upon expanding the implementation of the ceil(x) operator, the expression can be arithmetically transformed into the following equation:
CPS = MPS + DLE + (MPS + DLE) % 48

where (MPS + DLE) % 48 yields the integer remainder when MPS + DLE is divided by 48. Because (MPS + DLE) % 48 is equal to the UCO, the equation for CPS can be rewritten as follows:
CPS = MPS + DLE + UCO

Because the IP bit rate was calculated by considering only the IP data and header (that is, packets of length MPS or larger), the IP bit rate (rrsvp) needs to be multiplied by COMP. According to Table 14, COMP = CPS/MPS. Thus:
ATM cell payload bit rate =
r

rsvp * COMP =

rsvp * CPS/MPS

When expanded, the ATM cell payload bit rate is as follows:

ATM cell payload bit rate =
r

rsvp * (MPS + DLE + UCO)/MPS

Cisco IOS Quality of Service Solutions Configuration Guide

QC-295

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Task List

Each ATM cell has a 5-byte header and a 48-byte payload, resulting in a 53-byte cell. Because the entire cell needs to be accounted for (not just the payload), we need to multiply the equation by a compensation factor of 53/48, which yields the desired equation:
r

atm =

rsvp * (53/48) * (MPS + DLE + UCO)/MPS

Thus, the SCR of the SVC created to carry the RSVP flow is calculated by the following formula:
r

atm =

rsvp * (53/48) * (MPS + DLE + (MPS + DLE) % 48)/MPS

The ATM peak cell rate (PCR) is derived using the same formula as the cell rate formula. It is either based on the maximum line rate of the ATM interface or on a configured maximum. The maximum burst size of the SVC is derived by the following formula:
r r

atm =

rsvp * (MPS + DLE + UCO)/(MPS * 48)

Note that the actual PCR, SCR, and MBS will be slightly larger than these formulas indicate. See the task Limiting the Peak Rate Applied to the PCR for SVCs for information on setting the PCR of the ATM SVC. Each new RSVP reservation causes establishment of a new SVC. If an existing reservation is refreshed, no new signalling is needed. If the reservation is not refreshed and it times out, the SVC is torn down. If the reservation is refreshed but the RSVP flowspec has changed, the existing SVC is torn down and a new one with the correct QoS parameters is established.

Limiting the Peak Rate Applied to the PCR for SVCs

To set a limit on the PCR of reservations for all new RSVP SVCs established on the current interface or any of its subinterfaces, use the following command in interface configuration mode: Command
Router(config-if)# ip rsvp atm-peak-rate-limit limit

Purpose Configures the peak rate limit for new RSVP SVCs on an interface or subinterface.

For Controlled Load Service, the nominal peak rate is not defined and is taken as infinity. Consequently, the PCR is set to the available line rate. However, you can use the ip rsvp atm-peak-rate-limit command to further limit the PCR to a specific value on a per-interface basis.

Configuring per-VC DWRED

To configure Distributed Weighted Random Early Detection (DWRED) with per-VC DWRED enabled as a drop policy at the interface level for a specific DWRED group, use the following command in interface configuration mode: Command
Router(config-if)# random-detect [attach group-name]

Purpose Configures interface-level per-VC DWRED for a specific DWRED group.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-296

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Examples

The per SVC-DWRED drop policy ensures that packets that match reservations and conform to the appropriate token bucket have the highest priority. Attaching DWRED group definitions to the interface to support per-VC DWRED drop policy ensures that if packets must be dropped, then best-effort packets are dropped first and not those that conform to the appropriate QoS determined by the token bucket of the RSVP. This drop policy meets the loss requirements of controlled load called for by the Controlled Load Service class. To meet the loss goals of controlled load, it is necessary to ensure that if packets must be dropped, best-effort packets are dropped first. Given that packets matching reservations and conforming to the appropriate token bucket will have the highest precedence, per-SVC DWRED is used as the drop policy.

Note

In order to use per-SVC DWRED, dCEF must be configured on the router. For information on how to configure dCEF, refer to the Cisco IOS Switching Services Configuration Guide and the Cisco IOS Switching Services Command Reference.

Monitoring RSVP-ATM Configuration for an Interface

To display the peak rate limit for the interface, the IP Precedence and ToS bit values configured for packets that conform to and exceed the flowspec, and other RSVP-related information for the interface, such as whether the interface has been configured to establish SVCs to service reservation request messages and whether RSVP is enabled to attach itself to NetFlow, use the following commands in EXEC mode, as needed: Command
Router# show ip rsvp atm-peak-rate-limit [interface] Router# show ip rsvp interface [interface-type interface-number] Router# show ip rsvp {precedence | tos} [interface]

Purpose Displays the current peak rate limit set for an interface, if any. Displays RSVP-related interface information. Displays the IP Precedence bit values and type of service (ToS) bit values to be used to mark the ToS byte of the IP headers of all packets in an RSVP reserved path that conform to or exceed the RSVP flowspec for a given interface.

RSVP-ATM QoS Interworking Configuration Examples

This section provides RSPV-ATM QoS Internetworking configuration examples. For information about configuring RSVP-ATM QoS Internetworking, see the section RSVP-ATM QoS Interworking Configuration Task List in this chapter. The following example configures two Cisco 7500 series routers that connect over an ATM core network through a permanent virtual circuit (PVC) and multiple SVCs. As depicted in Figure 24, Router A is connected to the ATM core network downstream; upstream it is connected across an Ethernet connection to the RSVP sender host system. Router B is connected upstream to the ATM core network and downstream across an Ethernet connection to the RSVP receiver host. The example configuration shows three PVCs, two of which are required by ATM. One of the PVCs is used for RSVP-ATM QoS Interworking. It is used for transmission of best-effort traffic and to control traffic such as routing and RSVP messages. The ATM SVCs are established in response to reservation request messages in order to service those requests.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-297

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Examples

Figure 24

Example RSVP-ATM QoS Interworking Configuration

Sender host Ethernet

Router A ATM

Router B Ethernet

Receiver host
18511

Router A Configuration

The following portion of the example configures Router A in global configuration mode. It enables CEF, which must be turned on before the RSVP-ATM QoS Interworking feature can be enabled at the interface configuration level.
RouterA# config terminal RouterA(config)# ip routing RouterA(config)# ip cef

The following segment of the configuration for Router A configures ATM interface 2/1/0. The ip route-cache flow command enables NetFlow on the interface. If you do not enter the ip rsvp bandwidth command before the ip rsvp svc-required command, a warning is issued requesting that you change the order of the commands. The ip rsvp bandwidth command enables RSVP on the interface with default values for bandwidth allocation to RSVP. The ip rsvp svc-required command enables establishment of an SVC to service each new RSVP reservation on the interface. The ip rsvp tos and ip rsvp precedence commands configure conform and exceed values to be used for setting the ToS and IP Precedence bits of packets that either conform to or exceed the RSVP flowspec. (Note that once set, the ToS and IP Precedence bit values remain for the duration of the packet.) You should configure the ip route-cache flow command only on the input interfaces of a router on whose output interfaces you configured the ip rsvp svc-required command.
RouterA(config)# interface ATM2/1/0 RouterA(config-if)# no shut RouterA(config-if)# ip address 145.5.5.1 255.255.255.0 RouterA(config-if)# no ip proxy RouterA(config-if)# no ip redirects RouterA(config-if)# ip route-cache RouterA(config-if)# ip mroute-cache RouterA(config-if)# ip route-cache flow RouterA(config-if)# no ip mroute-cache RouterA(config-if)# ip route-cache cef RouterA(config-if)# atm pvc 1 0 5 qsaal RouterA(config-if)# atm pvc 2 0 16 ilmi RouterA(config-if)# atm esi-address 111111111151.00 RouterA(config-if)# pvc pvc12 0/51 RouterA(config-if-atm-vc)# inarp 5 RouterA(config-if-atm-vc)# broadcast RouterA(config-if-atm-vc)# exit RouterA(config-if)# ip rsvp bandwidth RouterA(config-if)# ip rsvp svc-required RouterA(config-if)# ip rsvp tos conform 4 RouterA(config-if)# ip rsvp precedence conform 3 exceed 2

The following portion of the configuration configures Ethernet interface 0/1 on Router A that is used for the connection between the sender host and Router A. RSVP is enabled on the interface with default bandwidth allocations.
RouterA(config)# interface Ethernet0/1 RouterA(config-if)# ip address 145.1.1.1 255.255.255.0 RouterA(config-if)# no ip proxy

Cisco IOS Quality of Service Solutions Configuration Guide

QC-298

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Examples

RouterA(config-if)# RouterA(config-if)# RouterA(config-if)# RouterA(config-if)# RouterA(config-if)# RouterA(config-if)# RouterA(config-if)# RouterA(config-if)# RouterA(config-if)#

no ip redirects no shut ip route-cache ip mroute-cache ip route-cache flow no ip mroute-cache ip route-cache cef fair ip rsvp bandwidth

The following section displays configuration for Router A after the preceding commands were used to configure it:
RouterA# write terminal Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname RouterA boot system tftp rsp-jv-mz 171.69.209.28 enable password ! ip subnet-zero ip cef interface Ethernet0/1 ip address 145.1.1.1 255.255.255.0 no ip redirects no ip directed-broadcast no ip proxy-arp ip rsvp bandwidth 7500 7500 no ip route-cache cef no ip mroute-cache fair-queue 64 256 1000 ! interface ATM2/1/0 ip address 145.5.5.1 255.255.255.0 no ip redirects no ip directed-broadcast no ip proxy-arp ip rsvp bandwidth 112320 112320 ip rsvp svc-required ip route-cache flow ip rsvp tos conform 4 ip rsvp precedence conform 3 exceed 2 no ip route-cache cef no ip route-cache distributed no ip mroute-cache atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi atm esi-address 111111111151.00 pvc pvc12 0/51 inarp 5 broadcast !

Cisco IOS Quality of Service Solutions Configuration Guide

QC-299

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Examples

Router B Configuration

Router B is configured similarly to Router A. In the following global configuration portion of the example, Router B is configured so that CEF is e enabled before the RSVP-ATM QoS Interworking feature can be enabled.
RouterB# config terminal RouterB(config)# ip routing RouterB(config)# ip cef

The following segment of the configuration for Router B configures ATM interface 3/0/0. The ip rsvp bandwidth command enables RSVP and the ip route-cache flow command enables NetFlow on the interface. The ip rsvp svc-required command enables the RSVP-ATM QoS Interworking feature, allowing for the establishment of an SVC to service each new RSVP reservation on the interface.
RouterB(config)# interface ATM3/0/0 RouterB(config-if)# atm pvc 1 0 5 qsaal RouterB(config-if)# atm pvc 2 0 16 ilmi RouterB(config-if)# atm esi-address 111111111152.00 RouterB(config-if)# pvc pvc12 0/52 RouterB(config-if-atm-vc)# inarp 5 RouterB(config-if-atm-vc)# broadcast RouterB(config-if-atm-vc)# exit RouterB(config-if)# ip rsvp bandwidth RouterB(config-if)# ip route-cache flow RouterB(config-if)# ip rsvp svc-required

The following portion of the configuration configures the Ethernet interface on Router B. This interface is used for the connection between the receiver host and Router B. RSVP is enabled on the interface.
RouterB(config)# interface Ethernet0/2 RouterB(config-if)# no shut RouterB(config-if)# ip address 145.4.4.2 255.255.255.0 RouterB(config-if)# no ip proxy RouterB(config-if)# no ip redirects RouterB(config-if)# ip route-cache RouterB(config-if)# ip mroute-cache RouterB(config-if)# ip route-cache flow RouterB(config-if)# no ip mroute-cache RouterB(config-if)# ip route-cache cef RouterB(config-if)# fair RouterB(config-if)# ip rsvp bandwidth RouterB(config-if)# end RouterB(config)# ip routing RouterB(config)# router eigrp 17 RouterB(config-router)# network 145.5.5.0 RouterB(config-router)# network 145.4.4.0

The following section displays configuration for Router B after the preceding commands were used to configure it:
RouterB# write terminal Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname RouterB ! ! boot system tftp rsp-jv-mz 171.69.209.28

Cisco IOS Quality of Service Solutions Configuration Guide

QC-300

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Examples

enable password ! ip subnet-zero ip cef distributed interface Ethernet0/2 ip address 145.4.4.2 255.255.255.0 no ip redirects no ip directed-broadcast no ip proxy-arp ip rsvp bandwidth 7500 7500 ip route-cache flow no ip mroute-cache fair-queue 64 256 1000 ! interface ATM3/0/0 ip address 145.5.5.2 255.255.255.0 no ip redirects no ip directed-broadcast no ip proxy-arp ip rsvp bandwidth 112320 112320 ip rsvp svc-required ip route-cache flow no ip route-cache cef no ip route-cache distributed no ip mroute-cache atm pvc 1 0 5 qsaal atm pvc 2 0 16 ilmi atm esi-address 111111111152.00 pvc pvc12 0/52 inarp 5 broadcast !

Cisco IOS Quality of Service Solutions Configuration Guide

QC-301

Configuring RSVP-ATM QoS Interworking RSVP-ATM QoS Interworking Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-302

Configuring COPS for RSVP

This chapter describes the tasks for configuring the COPS for RSVP feature. Common Open Policy Service (COPS) is a protocol for communicating network traffic policy information to network devices. Resource Reservation Protocol (RSVP) is a means for reserving network resourcesprimarily bandwidthto guarantee that applications sending end-to-end across the Internet will perform at the desired speed and quality. For complete conceptual information, see the section COPS for RSVP in the chapter Signalling Overview in this book. For a complete description of the COPS for RSVP commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index, or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

COPS for RSVP Configuration Task List

To configure COPS for RSVP, perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.

Specifying COPS Servers and Enabling COPS for RSVP (Required) Restricting RSVP Policy to Specific Access Control Lists (Optional) Rejecting Unmatched RSVP Messages (Optional) Confining Policy to PATH and RESV Messages (Optional) Retaining RSVP Information After Losing Connection with the COPS Server (Optional) Reporting the Results of Outsourcing and Configuration Decisions (Optional) Verifying the Configuration (Optional)

See the end of this chapter for the section COPS for RSVP Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-303

Configuring COPS for RSVP COPS for RSVP Configuration Task List

Specifying COPS Servers and Enabling COPS for RSVP

To specify COPS servers and enable COPS for RSVP, use the following commands beginning in interface configuration mode: Command
Step 1 Router(config-if)# configure terminal Step 2 Router(config)# ip rsvp policy cops servers
161.44.130.168 161.44.129.6

Purpose Enters global configuration mode. Tells the router to request RSVP policy decisions from the first server listed, and if that fails to connect, from the next server listed. Also enables a COPS-RSVP client on the router.

Restricting RSVP Policy to Specific Access Control Lists

To restrict RSVP policy to specific access control lists (ACLs), use the following commands beginning in interface configuration mode: Command
Step 1 Router(config-if)# configure terminal Step 2 Router(config)# ip rsvp policy cops 40 160
servers 161.44.130.164 161.44.129.2

Purpose Enters global configuration mode. Tells the router to apply RSVP policy to messages that match ACLs 40 and 160, and specifies the servers for those sessions.

Rejecting Unmatched RSVP Messages

To reject unmatched RSVP messages, use the following commands beginning in interface configuration mode: Command
Step 1 Router(config-if)# configure terminal Step 2 Router(config)# ip rsvp policy default-reject

Purpose Enters global configuration mode. Tells the router to reject unmatched PATH and RESV messages, instead of just letting them pass through unadjudicated.

Confining Policy to PATH and RESV Messages

To confine policy to PATH and RESV messages, use the following commands beginning in interface configuration mode:
:

Command
Step 1 Router(config-if)# configure terminal Step 2 Router(config)# ip rsvp policy cops minimal

Purpose Enters global configuration mode. Tells the router to adjudicate only PATH and RESV messages, and to accept and pass onward PATH ERROR, RESV ERROR, and RESV CONFIRM messages.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-304

Configuring COPS for RSVP COPS for RSVP Configuration Examples

Retaining RSVP Information After Losing Connection with the COPS Server
To retain RSVP information after losing connection with the COPS server, use the following commands beginning in interface configuration mode: Command
Step 1 Router(config-if)# configure terminal Step 2 Router(config)# ip rsvp policy cops timeout 600

Purpose Enters global configuration mode. Tells the router to hold policy information for 10 minutes (600 seconds) while attempting to reconnect to a COPS server.

Reporting the Results of Outsourcing and Configuration Decisions

To report the results of outsourcing and configuration decisions, use the following commands beginning in interface configuration mode: Command
Step 1 Router(config-if)# configure terminal Step 2 Router(config)# ip rsvp policy cops report-all

Purpose Enters global configuration mode. Tells the router to report to the Policy Decision Point (PDP) the success or failure of outsourcing and configuration decisions.

Verifying the Configuration

To verify the COPS for RSVP configuration, use the following commands in EXEC mode, as needed: Command
Router# show cops servers

Purpose Displays server addresses, port, state, keepalives, and policy client information. Displays policy server addresses, ACL IDs, and client/server connection status. Displays ACL IDs and their connection status.

Router# show ip rsvp policy cops

Router# show ip rsvp policy

COPS for RSVP Configuration Examples

The following sections provide COPS for RSVP configuration examples:

COPS Server Specified Example RSVP Behavior Customized Example Verification of the COPS for RSVP Configuration Example

For information about configuring COPS for RSVP, see the section COPS for RSVP Configuration Task List in this chapter.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-305

Configuring COPS for RSVP COPS for RSVP Configuration Examples

COPS Server Specified Example

The following example specifies the COPS server and enables COPS for RSVP on the server. Both of these functions are accomplished by using the ip rsvp policy cops command. By implication, the default settings for all remaining COPS for RSVP commands are accepted.
Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# ip rsvp policy cops servers 161.44.130.168 161.44.129.6 Router(config)# exit

RSVP Behavior Customized Example

Once the COPS server has been specified and COPS for RSVP has been enabled, the remaining COPS for RSVP commands can be used to customize the COPS for RSVP behavior of the router. The following example uses the remaining COPS for RSVP commands to customize the RSVP behavior of the router:
Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# ip rsvp policy cops 40 160 servers 161.44.130.168 161.44.129.6 Router(config)# ip rsvp policy default-reject Router(config)# ip rsvp policy cops minimal Router(config)# ip rsvp policy cops timeout 600 Router(config)# ip rsvp policy cops report-all Router(config)# exit

Verification of the COPS for RSVP Configuration Example

The following examples display three views of the COPS for RSVP configuration on the router, which can be used to verify the COPS for RSVP configuration. This example displays the policy server address, state, keepalives, and policy client information:
Router# show cops servers COPS SERVER: Address: 161.44.135.172. Port: 3288. State: 0. Keepalive: 120 sec Number of clients: 1. Number of sessions: 1. COPS CLIENT: Client type: 1. State: 0.

This example displays the policy server address, the ACL ID, and the client/server connection status:
Router# show ip rsvp policy cops COPS/RSVP entry. ACLs: 40 60 PDPs: 161.44.135.172 Current state: Connected Currently connected to PDP 161.44.135.172, port 0

This example displays the ACL ID numbers and the status for each ACL ID:
Router# show ip rsvp policy Local policy: Currently unsupported COPS: ACLs: 40 60 . State: CONNECTED. ACLs: 40 160 . State: CONNECTING.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-306

Configuring Subnetwork Bandwidth Manager

This chapter describes the tasks for configuring the Subnetwork Bandwidth Manager (SBM) feature, which is a signalling feature that enables Resource Reservation Protocol (RSVP)-based admission control over IEEE 802-styled networks. For complete conceptual information, see the section Subnetwork Bandwidth Manager in the chapter Signalling Overview in this book. For a complete description of the SBM commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Subnetwork Bandwidth Manager Configuration Task List

To configure SBM, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.

Configuring an Interface as a Designated SBM Candidate (Required) Configuring the NonResvSendLimit Object (Optional) Verifying Configuration of SBM State (Optional)

See the end of this chapter for the section Subnetwork Bandwidth Manager Candidate Configuration Example.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-307

Configuring Subnetwork Bandwidth Manager Subnetwork Bandwidth Manager Configuration Task List

Configuring an Interface as a Designated SBM Candidate

SBM is used in conjunction with RSVP. Therefore, before you configure an interface as a Designated SBM (DSBM) contender, ensure that RSVP is enabled on that interface. To configure the interface as a DSBM candidate, use the following command in interface configuration mode: Command
Router(config-if)# ip rsvp dsbm candidate [priority]

Purpose Configures the interface to participate as a contender in the DSBM dynamic election process, whose winner is based on the highest priority.

Configuring the NonResvSendLimit Object

The NonResvSendLimit object specifies how much traffic can be sent onto a managed segment without a valid RSVP reservation. To configure the NonResvSendLimit object parameters, use the following commands in interface configuration mode, as needed: Command
Router(config-if)# ip rsvp dsbm non-resv-send-limit rate kBps Router(config-if)# ip rsvp dsbm non-resv-send-limit burst kilobytes Router(config-if)# ip rsvp dsbm non-resv-send-limit peak kBps Router(config-if)# ip rsvp dsbm non-resv-send-limit min-unit bytes Router(config-if)# ip rsvp dsbm non-resv-send-limit max-unit bytes

Purpose Configures the average rate, in kbps, for the DSBM candidate. Configures the maximum burst size, in KB, for the DSBM candidate. Configures the peak rate, in kbps, for the DSBM candidate. Configures the minimum policed unit, in bytes, for the DSBM candidate. Configures the maximum packet size, in bytes, for the DSBM candidate.

To configure the per-flow limit on the amount of traffic that can be sent without a valid RSVP reservation, configure the rate, burst, peak, min-unit, and max-unit keywords for finite values from 0 to infinity. To allow all traffic to be sent without a valid RSVP reservation, configure the rate, burst, peak, min-unit, and max-unit keywords for unlimited. To configure the parameters for unlimited, you can either omit the command or enter the no version of the command (for example, no ip rsvp dsbm non-resv-send-limit rate). Unlimited is the default value. The absence of the NonResvSendLimit object allows any amount of traffic to be sent without a valid RSVP reservation.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-308

Configuring Subnetwork Bandwidth Manager Subnetwork Bandwidth Manager Configuration Task List

Verifying Configuration of SBM State

To display information that enables you to determine if an interface has been configured as a DSBM candidate and which of the contenders has been elected the DSBM, use the following command in EXEC mode: Command
Router# show ip rsvp sbm [detail] [interface]

Purpose Displays information about an SBM configured for a specific RSVP-enabled interface or for all RSVP-enabled interfaces on the router. Using the detail keyword allows you to view the values for the NonResvSendLimit object. The displayed output from the show ip rsvp sbm command identifies the interface by name and IP address, and it shows whether the interface has been configured as a DSBM contender. If the interface is a contender, the DSBM Priority field displays its priority. The DSBM election process is dynamic, addressing any new contenders configured as participants. Consequently, at any given time, an incumbent DSBM might be replaced by one configured with a higher priority. The following example shows sample output from the show ip rsvp sbm command:
Router# show ip rsvp sbm Interface DSBM Addr Et1 1.1.1.1 Et2 145.2.2.150 DSBM Priority 70 100 DSBM Candidate yes yes My Priority 70 100

If you use the detail keyword, the output is shown in a different format. In the left column, the local DSBM candidate configuration is shown; in the right column, the corresponding information for the current DSBM is shown. In the following example, the local DSBM candidate won election and is the current DSBM:
Router# show ip rsvp sbm detail Interface:Ethernet2 Local Configuration IP Address:10.2.2.150 DSBM candidate:yes Priority:100 Non Resv Send Limit Rate:500 Kbytes/sec Burst:1000 Kbytes Peak:500 Kbytes/sec Min Unit:unlimited Max Unit:unlimited

Current DSBM IP Address:10.2.2.150 I Am DSBM:yes Priority:100 Non Resv Send Limit Rate:500 Kbytes/sec Burst:1000 Kbytes Peak:500 Kbytes/sec Min Unit:unlimited Max Unit:unlimited

Cisco IOS Quality of Service Solutions Configuration Guide

QC-309

Configuring Subnetwork Bandwidth Manager Subnetwork Bandwidth Manager Candidate Configuration Example

Subnetwork Bandwidth Manager Candidate Configuration Example

For information about configuring SBM, see the section Subnetwork Bandwidth Manager Configuration Task List in this chapter. In the following example, RSVP and SBM are enabled on Ethernet interface 2. After RSVP is enabled, the interface is configured as a DSBM and SBM candidate with a priority of 100. The configured priority is high, making this interface a good contender for DSBM status. However, the maximum configurable priority value is 128, so another interface configured with a higher priority could win the election and become the DSBM.
interface Ethernet2 ip address 145.2.2.150 255.255.255.0 no ip directed-broadcast ip pim sparse-dense-mode no ip mroute-cache media-type 10BaseT ip rsvp bandwidth 7500 7500 ip rsvp dsbm candidate 100 ip rsvp dsbm non-resv-send-limit rate 500 ip rsvp dsbm non-resv-send-limit burst 1000 ip rsvp dsbm non-resv-send-limit peak 500 end

Cisco IOS Quality of Service Solutions Configuration Guide

QC-310

Link Efficiency Mechanisms

Link Efficiency Mechanisms Overview

Cisco IOS software offers five link-layer efficiency mechanisms or featuresLink Fragmentation and Interleaving (LFI) for Multilink PPP (MLP), Link Fragmentation and Interleaving for Frame Relay and ATM VCs, Frame Relay Fragmentation, Compressed Real-Time Protocol (CRTP), and distributed Compressed Real-Time Protocol (dCRTP)that work with queueing and traffic shaping to improve the efficiency and predictability of the application service levels. This chapter gives a brief introduction to these link-layer efficiency mechanisms described in the following sections:

Link Fragmentation and Interleaving for MLP Link Fragmentation and Interleaving for Frame Relay and ATM VCs Frame Relay Fragmentation Compressed Real-Time Protocol Distributed Compressed Real-Time Protocol

Link Fragmentation and Interleaving for MLP

Interactive traffic such as Telnet and Voice over IP (VoIP) is susceptible to increased latency when the network processes large packets such as LAN-to-LAN FTP transfers traversing a WAN. Packet delay is especially significant when the FTP packets are queued on slower links within the WAN. To solve delay problems on slow bandwidth links, a method for fragmenting larger packets and then queueing the smaller packets between fragments of the large packets is required. The Cisco IOS LFI feature reduces delay on slower-speed links by breaking up large datagrams and interleaving low-delay traffic packets with the smaller packets resulting from the fragmented datagram. The Cisco IOS LFI feature uses the Cisco implementation of MLP, which supports the fragmentation and packet sequencing specifications in RFC 1717. LFI allows reserve queues to be set up so that Real-Time Protocol (RTP) streams can be mapped into a higher priority queue in the configured weighted fair queue set.

Note

A related IETF Draft called Multiclass Extensions to Multilink PPP (MCML) describes the MCML feature, which implements nearly the same function as LFI. For information on how to configure LFI, see the chapter Configuring Link Fragmentation and Interleaving for Multilink PPP or Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-313

Link Efficiency Mechanisms Overview Link Fragmentation and Interleaving for MLP

How It Works
To understand how LFI using MLP works, it helps to understand the problem it addresses. The complete end-to-end delay target for real-time packets, especially voice packets, is 150 to 200 milliseconds (ms). The IP-based datagram transmission techniques for audio transmission do not adequately address the problems posed by limited bandwidth and the very stringent telephony delay bound of 150 ms. Unacceptable queueing delays for small real-time packets exist regardless of use of QoS features such as Resource Reservation Protocol (RSVP) and weighted fair queueing (WFQ), and use of voice compression algorithms such as code excited linear prediction (CELP) compression, which reduces the inherent bit rate from 64 kbps to as low as 8 kbps. Despite these measures, real-time delay continues to exist because per-packet header overhead is too large and large maximum transmission units (MTUs) are needed to produce acceptable bulk transmission efficiency. A large MTU of 1500 bytes takes 215 ms to traverse a 56-kbps line, which exceeds the delay target. Therefore, to limit the delay of real-time packets on relatively slow bandwidth linkslinks such as 56-kbps Frame Relay or 64-kbps ISDN B channelsa method for fragmenting larger packets and queueing smaller packets between fragments of the large packet is needed. MLP helps to solve this problem through LFI. MLP provides a method of splitting, recombining, and sequencing datagrams across multiple logical data links. The LFI scheme is relatively simple: Large datagrams are multilink encapsulated and fragmented to packets of a size small enough to satisfy the delay requirements of the delay-sensitive traffic; small delay-sensitive packets are not multilink encapsulated, but are interleaved between fragments of the large datagram. MLP allows the fragmented packets to be sent at the same time over multiple point-to-point links to the same remote address. The multiple links come up in response to a dialer load threshold that you define. The load can be calculated on inbound traffic, outbound traffic, or on either, as needed for the traffic between the specific sites. MLP provides bandwidth on demand and reduces transmission latency across WAN links. Figure 25 shows the mix of traffic destined for an interface as including both jumbograms and smaller, time-sensitive IP voice packets. Based on their classifications, these arriving packets are sorted into queues. After the packets are queued, the jumbogram is fragmented into smaller packets in preparation for interleaving with the time-sensitive IP voice packets. Because WFQ is configured for the interface, packets from each queuethat is, the jumbogram packet fragments and the IP voice packetsare interleaved and scheduled (fairly and based on their weight) for transmission in the output interface queue. To ensure correct order of transmission and reassembly, LFI adds multilink headers to the datagram fragments after the packets are dequeued and ready to be sent.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-314

Link Efficiency Mechanisms Overview Link Fragmentation and Interleaving for Frame Relay and ATM VCs

Figure 25

Link Fragmentation and Interleaving

Incoming packets
Classify

Transmit queue

Outgoing packets

IP voice Jumbogram WFQ Large packet fragmentation: fragment size based on required delay

Interleaving can occur at process-fast paths. However, because it relies on MLP, its performance is closely tied with multilink behavior.

Note

LFI on PPP over Frame Relay is not supported on Cisco IOS Release 12.1E.

Link Fragmentation and Interleaving for Frame Relay and ATM VCs
The LFI for Frame Relay and ATM VCs feature supports the transport of real-time (voice) and other (data) traffic on lower-speed Frame Relay and ATM virtual circuits (VCs) without causing excessive delay to the real-time traffic. This new feature implements LFI using MLP over Frame Relay and ATM. The feature enables delay-sensitive real-time packets and packets that are not real-time data to share the same link by fragmenting the long data packets into a sequence of smaller data packets (fragments). The fragments are interleaved with the real-time packets. On the receiving side of the link, the fragments are reassembled and the packet reconstructed. This method of fragmenting and interleaving helps guarantee the appropriate QoS for the real-time traffic. Before the introduction of this new feature, MLP supported packet fragmentation and interleaving at the bundle layer; however, it did not support interleaving on Frame Relay or ATM. The LFI for Frame Relay and ATM VCs feature supports low-speed Frame Relay and ATM and also Frame Relay/ATM interworking (FRF.8). This new feature enhances VoIP QoS by preventing delay, delay variation (jitter), and packet loss for voice traffic on low speed ATM-to-ATM and ATM-to-Frame Relay networks. The LFI for Frame Relay and ATM VCs feature works concurrently with and on the same switching path as other QoS features, ensuring high quality and scalable VoIP deployment. This feature works with the following QoS features:

Frame Relay Traffic Shaping (FRTS) Low latency queueing (LLQ) Class-based weighted fair queueing (CBWFQ)

Cisco IOS Quality of Service Solutions Configuration Guide

16761

QC-315

Link Efficiency Mechanisms Overview Frame Relay Fragmentation

The LFI for Frame Relay and ATM VCs feature supports RFC 1990, The PPP Multilink Protocol (MP).

Restrictions
The following restrictions apply to the LFI for Frame Relay and ATM VCs feature:

Only one link per MLP bundle is supported. If more than one link is used, there is no way of knowing which link is doing the LFI. Only voice over IP is supported; voice over Frame Relay and voice over ATM are not supported.

Note

LFI on PPP over Frame Relay is not supported on Cisco IOS Release 12.1E.

Prerequisites
The following prerequisites apply to the LFI for Frame Relay and ATM VCs feature:

FRTS must be configured on Frame Relay interfaces. Per-VC FIFO queueing must be configured on the Frame Relay and ATM VCs associated with MLP. MLP over ATM must use the following ATM network modules:
Multiport T1/E1 ATM Network Module with Inverse Multiplexing over ATM ATM OC-3 Network Module Enhanced ATM Port Adapter

For information on how to configure the LFI for Frame Relay and ATM VCs feature, see the chapter Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits in this book.

Frame Relay Fragmentation

Cisco has developed the following three methods of performing Frame Relay fragmentation:

End-to-end FRF.12 fragmentation Frame Relay fragmentation using FRF.11 Annex C Cisco proprietary voice encapsulation

For more information about Frame Relay fragmentation methods, refer to the Cisco IOS Wide-Area Networking Configuration Guide and the Cisco IOS Voice, Video, and Fax Configuration Guide.

Compressed Real-Time Protocol

Real-Time Protocol (RTP) is the Internet Standard (RFC 1889) protocol for the transport of real-time data. It is intended to provide end-to-end network transport functions for applications that support audio, video, or simulation data over multicast or unicast network services.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-316

Link Efficiency Mechanisms Overview Compressed Real-Time Protocol

RTP provides support for real-time conferencing of groups of any size within the Internet. This support includes source identification and support for gateways such as audio and video bridges, and for multicast-to-unicast translators. RTP offers QoS feedback from receivers to the multicast group and support for the synchronization of different media streams. RTP includes a data portion and a header portion. The data portion of RTP is a thin protocol that provides support for the real-time properties of applications, such as continuous media, including timing reconstruction, loss detection, and content identification. The header portion of RTP is considerably large. As shown in Figure 26, the minimal 12 bytes of the RTP header, combined with 20 bytes of IP header (IPH) and 8 bytes of User Datagram Protocol (UDP) header, create a 40-byte IP/UDP/RTP header. For compressed-payload audio applications, the RTP packet typically has a 20-byte to 160-byte payload. Given the size of the IP/UDP/RTP header combinations, it is inefficient to send the IP/UDP/RTP header without compressing it. To avoid the unnecessary consumption of available bandwidth, the RTP header compression featurereferred to as CRTPis used on a link-by-link basis. For information on how to configure CRTP, see the chapter Configuring Compressed Real-Time Protocol in this book.

How It Works
CRTP compresses the IP/UDP/RTP header in an RTP data packet from 40 bytes to approximately 2 to 5 bytes. Figure 26 illustrates this process.
Figure 26 RTP Header Compression

RTP traffic (video, audio, and so on) Traffic destined for interface

RTP compressor Transmit queue Non-RTP Output line

Classify

Configured queueing

Compression Identify RTP traffic Packet size reduction* ~ 240% ~ 13% ~ 2.3%
13473

12 RTP

8 UDP

20 IPH 5

IP Data IP Data

Efficiencies VoIP SQL FTP

Payload 20 bytes 256 bytes 1500 bytes

*Also ~5 ms reduction in serialization delay at 64 kbps

CRTP accrues major gain in terms of packet compression because although several fields in the header change in every packet, the difference from packet to packet is often constant, and therefore the second-order difference is zero. The decompressor can reconstruct the original header without any loss of information.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-317

Link Efficiency Mechanisms Overview Distributed Compressed Real-Time Protocol

CRTP is a hop-by-hop compression scheme similar to RFC 1144 for TCP header compression.

Why Use CRTP Header?

The CRTP reduction in line overhead for multimedia RTP traffic results in a corresponding reduction in delay; CRTP is especially beneficial when the RTP payload size is small, for example, for compressed audio payloads of 20 to 50 bytes. You should use CRTP on any WAN interface where bandwidth is a concern and there is a high portion of RTP traffic. CRTP can be used for media-on-demand and interactive services such as Internet telephony. As with RTP, CRTP provides support for real-time conferencing of groups of any size within the Internet. This support includes source identification and support for gateways such as audio and video bridges and for multicast-to-unicast translators. CRTP can benefit both telephony voice and multicast backbone (MBONE) applications running over slow links. You should not use CRTP on any high-speed interfacesthat is, anything over T1 speedbecause the trade-offs are not desirable. CRTP is supported on serial lines using Frame Relay, High-Level Data Link Control (HDLC), or PPP encapsulation. It is also supported over ISDN interfaces. CRTP for Frame Relay is supported using Cisco-format encapsulation only.

Express RTP Header Compression

Before Cisco IOS Release 12.0(7)T, if compression of TCP or RTP headers was enabled, compression was performed in the process switching path, which meant that packets traversing interfaces that had TCP or RTP header compression enabled were queued and passed up to the process to be switched. This procedure slowed down transmission of the packet, and therefore some users preferred to fast-switch uncompressed TCP and RTP packets. With Release 12.1, if TCP or RTP header compression is enabled, it occurs by default in the fast-switched path or the Cisco Express Forwarding-switched (CEF-switched) path, depending on which switching method is enabled on the interface. If neither fast-switching nor CEF switching is enabled, if RTP header compression is enabled, it will occur in the process-switched path as before. The Express RTP Header Compression feature is not available for Async and Dialer interfaces. For more information on the Express RTP Header Compression feature, refer to the Cisco IOS IP Configuration Guide.

Distributed Compressed Real-Time Protocol

Before Cisco IOS Release 12.1(5)T, if compression of TCP or RTP headers was enabled on a Cisco 7500 series router with a Versatile Interface Processor (VIP), the compression was performed in the process-switching path, which meant that packets traversing interfaces that had TCP or RTP header compression enabled were queued and passed up to the Route Switch Processor (RSP) to be switched. This procedure slowed down transmission of the packet, and therefore some users preferred to fast-switch uncompressed TCP and RTP packets rather than enable TCP and RTP compression.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-318

Link Efficiency Mechanisms Overview Distributed Compressed Real-Time Protocol

If the dCRTP feature is enabled, the header compression of the combined IP/UDP/RTP header occurs by default in the distributed fast-switched path or the distributed CEF-switched (dCEF-switched) path, depending on which switching method is enabled on the interface. If distributed fast-switching or dCEF switching are disabled, TCP or RTP header compression will occur in the process-switched path as before. This feature is supported on Cisco 7500 series routers with a VIP. The dCRTP feature supports the following RFCs:

RFC 1144, Compressing TCP/IP Headers for Low-Speed Serial Links RFC 2507, IP Header Compression RFC 2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links

For information on how to configure the dCRTP feature, see the chapter Configuring Distributed Compressed Real-Time Protocol in this book.

Benefits
Additional Functionality Capabilities for the RSP
The dCRTP feature offloads the IP/UDP/RTP header compression from the RSP, scaling it for other functionality.

Enhanced 7500 Series Router Scalability for Enterprise and Service Provider Networks
The dCRTP feature helps support Compressed Real-Time Protocol (CRTP) for large enterprise and service provider networks on a single Cisco 7500 series router acting as an aggregation point.

Additional Support for VoIP Streams

The dCRTP feature allows for more VoIP streams to be supported without any major performance degradation on the RSP.

Accelerates Speed of Packet Transmission

The dCRTP feature reduces the size of the packet, which allows for a higher packet transmission speed.

Improved Latency
The dCRTP feature reduces the size of the packet. The smaller packet leaves less latency on a transmission ring, allowing for higher data quality.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-319

Link Efficiency Mechanisms Overview Distributed Compressed Real-Time Protocol

Restrictions
The following restrictions apply to the dCRTP feature:

Because statistical updates are sent to the RSP by the VIP once every 10 seconds, a 10-second delay may be experienced when displaying traffic statistics using the show ip rtp header-compression or show ip tcp header-compression command. The detail option is not available with the show ip rtp header-compression and show ip tcp header-compression commands when distributed fast-switching is enabled. Users who need the detailed information for either of these commands can retrieve this information by disabling distributed fast-switching and then entering the show ip rtp header-compression detail or show ip tcp header-compression detail command. This restriction affects MLP interfaces that use LFI. In this case, if RTP header compression is configured, RTP packets originating on or destined to the router will be fast-switched if the link is limited to one channel. If the link has more than one channel, the packets will be process-switched. This feature is not available for Async and Dialer interfaces.

Prerequisites
In order for this feature to work, the following prerequisites must be met:

Distributed CEF switching or distributed fast-switching must be enabled on the interface. HDLC, PPP, or Frame Relay encapsulation must be configured. TCP or RTP header compression, or both, must be enabled:
For information on configuring RTP header compression, see the chapter Configuring

Compressed Real-Time Protocol in this book. For information on configuring TCP header compression, refer to the Cisco IOS IP Configuration Guide.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-320

Configuring Link Fragmentation and Interleaving for Multilink PPP

The Cisco IOS Link Fragmentation and Interleaving (LFI) feature uses Multilink PPP (MLP). MLP provides a method of splitting, recombining, and sequencing datagrams across multiple logical data links. MLP allows packets to be fragmented and the fragments to be sent at the same time over multiple point-to-point links to the same remote address. This chapter describes the tasks for configuring MLP, and it includes example configurations. For complete conceptual information, see the section Link Fragmentation and Interleaving for MLP in the chapter Link Efficiency Mechanisms Overview in this book. To locate documentation of commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

About MLP Interleaving and Queueing for Real-Time Traffic

Interleaving on MLP allows large packets to be multilink encapsulated and fragmented into a small enough size to satisfy the delay requirements of real-time traffic; small real-time packets are not multilink encapsulated and are sent between fragments of the large packets. The interleaving feature also provides a special transmit queue for the smaller, delay-sensitive packets, enabling them to be sent earlier than other flows. Weighted fair queueing (WFQ) on MLP works at the packet level, not at the level of multilink fragments. Thus, if a small real-time packet gets queued behind a larger best-effort packet and no special queue has been reserved for real-time packets, the small packet will be scheduled for transmission only after all the fragments of the larger packet are scheduled for transmission. WFQ is supported on all interfaces that support MLP, including MLP virtual access interfaces and virtual interface templates. Fair queueing on MLP overcomes a prior restriction. Previously, fair queueing was not allowed on virtual access interfaces and virtual interface templates. Interleaving provides the delay bounds for delay-sensitive voice packets on a slow link that is used for other best-effort traffic.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-321

Configuring Link Fragmentation and Interleaving for Multilink PPP Interleaving for Multilink PPP Configuration Task List

Restrictions
Interleaving applies only to interfaces that can configure a multilink bundle interface. These interfaces include virtual templates, dialer interfaces, and ISDN BRI or PRI interfaces. Multilink and fair queueing are not supported when a multilink bundle is off-loaded to a different system using Multichassis Multilink PPP (MMP). Thus, interleaving is not supported in MMP networking designs.

Note

LFI on PPP over Frame Relay is not supported on Cisco IOS Release 12.1E.

Interleaving for Multilink PPP Configuration Task List

To configure MLP, perform the tasks described in the following sections. The task in the first section is required; the task in the remaining section is optional.

Configuring MLP Interleaving (Required) Displaying Interleaving Statistics (Optional) Monitoring PPP and MLP Interfaces (Optional)

See the end of this chapter for the section MLP and LFI Configuration Examples.

Configuring MLP Interleaving

MLP support for interleaving can be configured on virtual templates, dialer interfaces, and ISDN BRI or PRI interfaces. To configure interleaving, perform the following steps:
Step 1 Step 2

Configure the dialer interface, BRI interface, PRI interface, or virtual interface template, as defined in the relevant Cisco IOS documents. Configure MLP and interleaving on the interface or template.

Note

Fair queueing, which is enabled by default, must remain enabled on the interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-322

Configuring Link Fragmentation and Interleaving for Multilink PPP Interleaving for Multilink PPP Configuration Task List

To configure MLP and interleaving on a configured and operational interface or virtual interface template, use the following commands in interface configuration mode: Command
Step 1 Step 2 Step 3
Router(config-if)# ppp multilink Router(config-if)# ppp multilink interleave Router(config-if)# ppp multilink fragment-delay milliseconds

Purpose Enables MLP. Enables real-time packet interleaving. (Optional) Configures a maximum fragment delay. If, for example, you want a voice stream to have a maximum bound on delay of 20 milliseconds (ms) and you specify 20 ms using this command, MLP will choose a fragment size based on the configured value. Reserves a special queue for real-time packet flows to specified destination User Datagram Protocol (UDP) ports, allowing real-time traffic to have higher priority than other flows. For virtual interface templates only, applies the virtual interface template to the multilink bundle.

Step 4

Router(config-if)# ip rtp reserve lowest-UDP-port range-of-ports [maximum-bandwidth]

Step 5

Router(config-if)# multilink virtual-template

Note

This step is not used for ISDN or dialer interfaces.

Displaying Interleaving Statistics

To display interleaving statistics, use the following command in EXEC mode: Command
Router# show interfaces

Purpose Displays statistics for all interfaces configured on the router or access server.

Monitoring PPP and MLP Interfaces

To monitor virtual interfaces, use the following command in EXEC mode: Command
Router# show ppp multilink

Purpose Displays MLP and MMP.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-323

Configuring Link Fragmentation and Interleaving for Multilink PPP MLP and LFI Configuration Examples

MLP and LFI Configuration Examples

This section provides MLP and LFI configuration examples. For information about configuring MLP and LFI, see Interleaving for Multilink PPP Configuration Task List in this chapter. The following example defines a virtual interface template that configures MLP interleaving and a maximum real-time traffic delay of 20 ms, and then applies that virtual template to the MLP bundle:
interface virtual-template 1 ip unnumbered ethernet 0 ppp multilink ppp multilink interleave ppp multilink fragment-delay 20 ip rtp reserve 32768 20 1000 multilink virtual-template 1

The following example configures MLP interleaving on a dialer interface that controls a rotary group of BRI interfaces. This configuration permits IP packets to trigger calls.
interface BRI0 description connected into a rotary group encapsulation ppp dialer rotary-group 1 ! interface BRI1 no ip address encapsulation ppp dialer rotary-group 1 interface BRI2 encapsulation ppp dialer rotary-group 1 ! interface BRI3 no ip address encapsulation ppp dialer rotary-group 1 ! interface BRI4 encapsulation ppp dialer rotary-group 1 ! interface Dialer0 description Dialer group controlling the BRIs ip address 8.1.1.1 255.255.255.0 encapsulation ppp dialer map ip 8.1.1.2 name angus 14802616900 dialer-group 1 ppp authentication chap ! Enables Multilink PPP interleaving on the dialer interface and reserves ! a special queue. ppp multilink ppp multilink interleave ip rtp reserve 32768 20 1000 ! Keeps fragments of large packets small enough to ensure delay of 20 ms or less. ppp multilink fragment-delay 20 dialer-list 1 protocol ip permit

Cisco IOS Quality of Service Solutions Configuration Guide

QC-324

Configuring Link Fragmentation and Interleaving for Multilink PPP MLP and LFI Configuration Examples

The following is an example of interleaving statistics displayed using the show interfaces command for a particular interface on which interleaving is enabled. Interleaving data is displayed only if there are interleaves. For example, the following line shows interleaves:
Output queue: 315/64/164974/31191 (size/threshold/drops/interleaves)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-325

Configuring Link Fragmentation and Interleaving for Multilink PPP MLP and LFI Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-326

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits
This chapter describes the tasks for configuring the Link Fragmentation and Interleaving (LFI) for Frame Relay and ATM Virtual Circuits (VCs) feature, and it includes example configurations. For complete conceptual information, see the section Link Fragmentation and Interleaving for Frame Relay and ATM VCs in the chapter Link Efficiency Mechanisms Overview in this book. To locate documentation of commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

LFI for Frame Relay and ATM VCs Configuration Task List
To configure the LFI for Frame Relay and ATM VCs feature, perform the tasks described in the following sections. The tasks in the two sections are required; the task in the remaining section is optional.

Configuring LFI Using Multilink Point-to-Point Protocol over Frame Relay (Required) Configuring LFI Using MLP over ATM (Required) Verifying LFI for Frame Relay and ATM (Optional) Monitoring and Maintaining LFI for Frame Relay and ATM (Optional)

See the end of this chapter for the section LFI for Frame Relay and ATM VCs Configuration Examples.

Configuring LFI Using Multilink Point-to-Point Protocol over Frame Relay

To configure LFI using Multilink Point-to-Point Protocol (MLP) over Frame Relay, perform the tasks described in the following sections. The tasks in both sections are required.

Configuring LFI Using MLP in a Virtual Template Interface (Required) Associating the Virtual Template Interface with a Frame Relay Permanent Virtual Circuit (Required)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-327

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Task List

Configuring LFI Using MLP in a Virtual Template Interface

To configure LFI using MLP in a virtual template interface, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3 Step 4 Step 5
Router(config)# interface virtual-template number

Purpose Creates a virtual template and enters interface configuration mode. Sets the bandwidth value for an interface. Attaches the specified policy map to the output interface. Enables MLP on the interface. Configures the maximum delay allowed for transmission of a packet fragment on an MLP bundle. Enables interleaving of RTP packets among the fragments of larger packets on an MLP bundle.

Router(config-if)# bandwidth kilobits Router(config-if)# service-policy output policy-name

Router(config-if)# ppp multilink Router(config-if)# ppp multilink fragment-delay milliseconds

Step 6

Router(config-if)# ppp multilink interleave

The ideal fragment size should allow the fragments to fit into an exact multiple of ATM cells. The fragment size for MLP over ATM can be calculated using the following formula: fragment size = 48 * number of cells 10 Fragment size at the MLP bundle can be configured using the following formula: fragment size = bandwidth * fragment-delay/8

Associating the Virtual Template Interface with a Frame Relay Permanent Virtual Circuit
To associate the virtual template interface with a Frame Relay permanent virtual circuit (PVC), use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3 Step 4
Router(config)# interface type number

Purpose Configures an interface type and enters interface configuration mode. Enables Frame Relay Traffic Shaping on the interface. Associates a virtual template interface with a Frame Relay data-link connection identifier (DLCI). Associates a Frame Relay map class with a DLCI.

Router(config-if)# frame-relay traffic-shaping

Router(config-if)# frame-relay interface-dlci dlci [ppp virtual-template-name] Router(config-if)# class name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-328

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Task List

Configuring LFI Using MLP over ATM

LFI using MLP can be configured over ATM using a virtual template interface or a dialer interface. To configure LFI using MLP over ATM using a virtual template interface or dialer interface, perform the tasks in either the first two or the second two sections:

Configuring LFI Using MLP on a Virtual Template Interface (Required) Associating the Virtual Template Interface with an ATM PVC (Required) Configuring LFI Using MLP on a Dialer Interface (Required) Associating the Dialer Interface with an ATM PVC (Required)

Configuring LFI Using MLP on a Virtual Template Interface

To configure LFI using MLP on a virtual template interface, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3 Step 4 Step 5
Router(config)# interface virtual-template number

Purpose Creates a virtual template and enters interface configuration mode. Sets the bandwidth value for an interface. Attaches the specified policy map to the output interface. Enables MLP on the interface. Configures the maximum delay allowed for transmission of a packet fragment on an MLP bundle. Enables interleaving of Real-Time Protocol (RTP) packets among the fragments of larger packets on an MLP bundle.

Router(config-if)# bandwidth kilobits Router(config-if)# service-policy output policy-name

Router(config-if)# ppp multilink Router(config-if)# ppp multilink fragment-delay milliseconds

Step 6

Router(config-if)# ppp multilink interleave

The ideal fragment size for MLP over ATM should allow the fragments to fit into an exact multiple of ATM cells. The fragment size for MLP over ATM can be calculated using the following formula: fragment size = 48 x number of cells 10 Fragment size at the MLP bundle can be configured using the following formula: fragment size = bandwidth x fragment-delay/8

Cisco IOS Quality of Service Solutions Configuration Guide

QC-329

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Task List

Note

To attach a service policy to a multilink ppp bundle configured through a virtual template, make sure that the multilink ppp bundle interface is operational. If the interface is not operational, attaching the service policy fails. If a multilink ppp bundle interface is configured through a virtual template, at least two virtual access interfaces are configured, (that is, virtual-access 1 and virtual-access 2). One of these virtual access interfaces is a ppp interface and the other is a multilink ppp bundle interface. When a service policy is attached to a virtual template, the error message Class Based Weighted Fair Queuing not supported on interface virtual-access1 appears if the virtual-access1 interface is the ppp interface. Since the service policy is successfully attached to the multilink ppp bundle interface, this is not an error condition. To verify whether the service policy is attached correctly, use the show interfaces command and review the queuing policy.

Associating the Virtual Template Interface with an ATM PVC

To associate the virtual template interface with an ATM PVC, use the following commands beginning in global configuration mode: Command
Step 1
Router(config)# interface atm slot/0

Purpose Specifies the ATM interface type and enters interface configuration mode.

or
Router(config)# interface atm slot/port

Note

To determine the correct form of the interface command, consult your ATM network module, port adapter, or router documentation

Step 2 Step 3

Router(config-if)# pvc [name] vpi/vci Router(config-if-atm-vc)# abr output-pcr output-mcr

Creates an ATM PVC. Selects available bit rate (ABR) QoS and configures the output peak cell rate and output minimum guaranteed cell rate for an ATM PVC. Specifies that PPP is established over the ATM PVC using the configuration from the specified virtual template.

Step 4

Router(config-if-atm-vc)# protocol ppp virtual-template number

Configuring LFI Using MLP on a Dialer Interface

To configure LFI using MLP in a dialer interface, use the following commands beginning in global configuration mode: Command
Step 1 Step 2
Router(config)# interface dialer number

Purpose Creates a dialer interface and enters interface configuration mode. Sets the bandwidth value for an interface.

Router(config-if)# bandwidth kilobits

Cisco IOS Quality of Service Solutions Configuration Guide

QC-330

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Task List

Command
Step 3
Router(config-if)# ip address ip-address mask

Purpose Configures the IP address for the interface.

or
Router(config-if)# ip unnumbered type number

Enables IP processing on a serial interface without assigning an explicit IP address to the interface. Enables PPP encapsulation on the interface. For a dialer interface, specifies which dialing pool to use to connect to a specific destination subnetwork. Attaches a policy map to an output interface or VC to be used as the service policy for that interface or VC. (Optional) Enables Challenge Authentication Protocol (CHAP) on the interface. (Optional) Creates a pool of dialup routers that all appear to be the same host when authenticating with CHAP. (Optional) Enables a router calling a collection of routers that do not support this command (such as routers running older Cisco IOS software images) to configure a common CHAP secret password to use in response to challenges from an unknown peer. Enables MLP on the interface. Configures the maximum delay allowed for transmission of a packet fragment on an MLP bundle. Enables interleaving of RTP packets among the fragments of larger packets on an MLP bundle.

Step 4 Step 5 Step 6 Step 7 Step 8

Router(config-if)# encapsulation ppp Router(config-if)# dialer pool number

Router(config-if)# service-policy output name

Router(config-if)# ppp authentication chap

Router(config-if)# ppp chap hostname name

Step 9

Router(config-if)# ppp chap password secret

Step 10 Step 11 Step 12

Router(config-if)# ppp multilink Router(config-if)# ppp multilink fragment-delay milliseconds Router(config-if)# ppp multilink interleave

Associating the Dialer Interface with an ATM PVC

To associate a dialer interface with an ATM PVC, use the following commands beginning in global configuration mode: Command
Step 1
Router(config)# interface atm slot/0

Purpose Specifies the ATM interface type and enters interface configuration mode.

or
Router(config)# interface atm slot/port

Note

To determine the correct form of the interface atm command, consult your ATM network module, port adapter, or router documentation

Step 2

Router(config-if)# pvc [name] vpi/vci

Creates an ATM PVC.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-331

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Task List

Command
Step 3
Router(config-if-atm-vc)# abr output-pcr output-mcr

Purpose Selects ABR QoS and configures the output peak cell rate and output minimum guaranteed cell rate for an ATM PVC. Specifies that the encapsulation type will be PPP and that the PVC will be associated with a dialer interface. Configures the interface to be a member of a dialer profile dialing pool.

Step 4

Router(config-if-atm-vc)# encapsulation aal5mux ppp dialer

Step 5

Router(config-if-atm-vc)# dialer pool-member number

Verifying LFI for Frame Relay and ATM

To display information about LFI for Frame Relay and ATM, use the following commands in privileged EXEC mode, as needed: Command
Router# show frame-relay pvc dlci

Purpose Displays statistics about PVCs for Frame Relay interfaces. Displays interleaving statistics if any interleaving occurs. Displays bundle information for the MLP bundles and their PPP links in the router.

Router# show interfaces

Router# show ppp multilink

Monitoring and Maintaining LFI for Frame Relay and ATM

To monitor LFI for Frame Relay and ATM, use the following commands in privileged EXEC mode, as needed: Command
Router# debug ppp multilink fragments

Purpose Displays information about individual multilink fragments and important multilink events. Displays information about the interleaving of voice and data packets.

Router# debug voice RTP

Caution

The debug ppp multilink fragments and debug voice RTP commands have memory overhead and should not be used when memory is scarce or when traffic is very high.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-332

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Examples

LFI for Frame Relay and ATM VCs Configuration Examples

This section provides the following LFI for Frame Relay and ATM VCs configuration examples:

LFI over Frame Relay Using a Virtual Template Interface Configuration Example LFI over ATM Using a Virtual Template Interface Configuration Example LFI over ATM Using a Dialer Interface Configuration Example

For information about configuring LFI for Frame Relay and ATM VCs, see LFI for Frame Relay and ATM VCs Configuration Task List in this chapter.

LFI over Frame Relay Using a Virtual Template Interface Configuration Example
The following example shows the configuration of LFI using MLP over Frame Relay using a virtual template interface:
hostname router1 ! username cisco-1 password 7 140417081E013E ! class-map cba match access-group 100 ! policy-map abc class cba priority 48 ! interface Serial5/0 no ip address encapsulation frame-relay frame-relay traffic-shaping ! ! The following commands enable PPP on and associate Virtual-Template1 with DLCI 16. interface Serial5/0.1 point-to-point frame-relay interface-dlci 16 ppp Virtual-Template1 class mlp ! ! The following commands configure MLP using LFI on Virtual-Template1. interface Virtual-Template1 bandwidth 78 ip address 192.168.47.6 255.255.255.252 ip mroute-cache service-policy output abc ppp authentication chap ppp chap hostname router2 ppp multilink ppp multilink fragment-delay 8 ppp multilink interleave ! map-class frame-relay mlp frame-relay cir 64000 frame-relay bc 300 frame-relay be 0 no frame-relay adaptive-shaping ! access-list 100 permit udp any any precedence critical ! ! The following commands configure Voice over IP. dial-peer voice 5 voip

Cisco IOS Quality of Service Solutions Configuration Guide

QC-333

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Examples

destination-pattern 1222 session target ipv4:131.180.80.10 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 1 pots destination-pattern 1333 port 2/1/0

LFI over ATM Using a Virtual Template Interface Configuration Example

The following example shows the configuration of LFI using MLP on an ATM interface. This configuration uses a virtual template interface.
hostname router1 ! username cisco-1 password 7 36497A4872384A ! class-map xyz match access-group 100 ! policy-map xyz class xyz priority 48 ! interface ATM4/0 no ip address no atm ilmi-keepalive ! ! The following commands enable PPP on and associate Virtual-Template1 with PVC 0/32. int atm4/0.1 point-to-point pvc 0/32 abr 100 80 protocol ppp Virtual-Template1 ! ! The following commands configure MLP using LFI on Virtual-Template1. interface Virtual-Template1 bandwidth 78 ip address 192.168.47.17 255.255.255.252 ip mroute-cache service-policy output xyz ppp authentication chap ppp chap hostname router2 ppp multilink ppp multilink fragment-delay 8 ppp multilink interleave ! access-list 100 permit udp any any precedence critical ! ! The following commands configure Voice over IP. dial-peer voice 5 voip destination-pattern 1222 session target ipv4:131.180.80.10 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 1 pots destination-pattern 1333 port 2/1/0

Cisco IOS Quality of Service Solutions Configuration Guide

QC-334

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Examples

LFI over ATM Using a Dialer Interface Configuration Example

The following example shows the configuration of LFI using MLP on an ATM interface. This configuration uses a dialer interface.
! class-map xyz match access-group 100 ! policy-map xyz class xyz priority 48 ! ! The following commands configure MLP using LFI on dialer interface 1. interface Dialer1 bandwidth 86 ip address 192.168.1.18 255.255.255.252 encapsulation ppp dialer pool 1 service-policy output abc authentication chap ppp chap hostname router2 ppp chap password 0 password ppp multilink ppp multilink fragment-delay 8 ppp multilink interleave ! ! The following commands associate PVC 1/32 with dialer interface 1. interface ATM4/0 pvc 1/32 abr 100 80 encapsulation aal5mux ppp dialer dialer pool-member 1 ! access-list 100 permit udp any any precedence critical ! ! The following commands configure Voice over IP. dial-peer voice 5 voip destination-pattern 1222 session target ipv4:131.180.80.10 dtmf-relay cisco-rtp ip precedence 5 ! dial-peer voice 1 pots destination-pattern 1333 port 2/1/0

Cisco IOS Quality of Service Solutions Configuration Guide

QC-335

Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits LFI for Frame Relay and ATM VCs Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-336

Configuring Compressed Real-Time Protocol

This chapter describes the tasks for configuring the Compressed Real-Time Protocol (CRTP) header. For complete conceptual information, see the section Compressed Real-Time Protocol in the chapter Link Efficiency Mechanisms Overview in this book. For a complete description of the CRTP commands in this chapter, refer to the Cisco IOS IP Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Compressed Real-Time Protocol Configuration Task List

To configure the CRTP header, perform the tasks described in the following sections. Either one of the tasks in the first two sections is required; the tasks in the remaining sections are optional.

Enabling CRTP on a Serial Interface (Required) Enabling CRTP with Frame Relay Encapsulation (Required) Changing the Number of Header Compression Connections (Optional) Displaying System and Network Statistics (Optional)

Note

You must enable compression on both ends of a serial connection. See the end of this chapter for Compressed Real-Time Protocol Configuration Examples.

Prerequisites
CRTP is supported on serial lines using Frame Relay, High-Level Data Link Control (HDLC), or PPP encapsulation. It is also supported over ISDN interfaces. You should configure CRTP if the following conditions exist in your network:

Slow links The need to save bandwidth

Cisco IOS Quality of Service Solutions Configuration Guide

QC-337

Configuring Compressed Real-Time Protocol Compressed Real-Time Protocol Configuration Task List

Note

CRTP should not be used on links greater than 2 Mbps. Enabling compression on both ends of a low-bandwidth serial link can greatly reduce the network overhead if it carries a substantial amount of Real-Time Protocol (RTP) traffic. Although the multicast backbone (MBONE)-style RTP traffic has higher payload sizes, compact encodings such as code excited linear prediction (CELP) can also help considerably. Before you can enable RTP header compression, you must have configured a serial line that uses either Frame Relay, HDLC, or PPP encapsulation, or an ISDN interface. To configure RTP header compression, perform the tasks in the following sections.

Enabling CRTP on a Serial Interface

To enable CRTP header for serial encapsulations on a serial interface, use the following command in interface configuration mode: Command
Router(config-if)# ip rtp header-compression [passive]

Purpose Enables RTP header compression.

If you include the passive keyword, the Cisco IOS software compresses outgoing RTP packets only if incoming RTP packets on the same interface are compressed. If you use the command without the passive keyword, the software compresses all RTP traffic.

Enabling CRTP with Frame Relay Encapsulation

To enable the CRTP header with Frame Relay encapsulation, use the following commands in interface configuration mode, as needed: Command
Router(config-if)# frame-relay ip rtp header-compression [passive]

Purpose Enables RTP header compression on the physical interface. All interface maps will inherit it. Subsequently, all maps will perform RTP/IP header compression. Enables RTP header compression only on the particular map specified. Enables both RTP and TCP header compression on this link.

Router(config-if)# frame-relay map ip ip-address dlci [broadcast] rtp header-compression [active | passive] Router(config-if)# frame-relay map ip ip-address dlci [broadcast] compress

Cisco IOS Quality of Service Solutions Configuration Guide

QC-338

Configuring Compressed Real-Time Protocol Compressed Real-Time Protocol Configuration Examples

Changing the Number of Header Compression Connections

By default, the software supports a total of 16 RTP header compression connections on an interface. To change that number, use the following command in interface configuration mode: Command
Router(config-if)# ip rtp compression-connections number

Purpose Specifies the total number of RTP header compression connections supported on an interface.

Displaying System and Network Statistics

You can display specific statistics such as the contents of IP routing tables, caches, and databases. Information provided can be used to determine resource utilization and solve network problems. You can also display information about node reachability and discover the routing path that the packets of your device are taking through the network. To display various routing statistics, use the following commands in EXEC mode, as needed: Command
Router# show frame-relay ip rtp header-compression [interface type number] Router# show ip rtp header-compression [type number] [detail]

Purpose Displays Frame Relay RTP header compression statistics. Displays RTP header compression statistics.

Compressed Real-Time Protocol Configuration Examples

This section provides CRTP configuration examples. For information about configuring CRTP, see the section Compressed Real-Time Protocol Configuration Task List in this chapter. The following example enables RTP header compression for a serial, ISDN, or asynchronous interface. For ISDN, you also need a broadcast dialer map.
interface serial 0 :or interface bri 0 ip rtp header-compression encapsulation ppp ip rtp compression-connections 25

The following example for Frame Relay encapsulation enables RTP header compression on the specified map:
interface serial 0 ip address 1.0.0.2 255.0.0.0 encapsulation frame-relay no keepalive clockrate 64000 frame-relay map ip 1.0.0.1 17 broadcast rtp header-compression

Cisco IOS Quality of Service Solutions Configuration Guide

QC-339

Configuring Compressed Real-Time Protocol Compressed Real-Time Protocol Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-340

Configuring Distributed Compressed Real-Time Protocol

This chapter describes the tasks for configuring the Distributed Compressed Real-Time Protocol (dCRTP) feature. For complete conceptual information, see the section Distributed Compressed Real-Time Protocol in the chapter Link Efficiency Mechanisms Overview in this book. For a complete description of the dCRTP commands in this chapter, refer to the Cisco IOS IP Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Distributed CRTP Configuration Task List

The dCRTP feature is enabled automatically. You can configure the dCRTP feature by changing the number of header compression connections, an optional procedure. To configure the Distributed CRTP feature, complete the task in the following section:

Changing the Number of Header Compression Connections (Optional)

Note

The instructions in this section assume that Real-Time Protocol (RTP) or TCP header compression is already enabled. For information on configuring RTP header compression, see the chapter Configuring Compressed Real-Time Protocol in this book. For information on configuring TCP header compression, refer to the Cisco IOS IP Configuration Guide. If TCP or RTP header compression is enabled, the header compression is performed in the distributed Cisco Express Forwarding (CEF)-switched or distributed fast-switched path automatically. No additional configuration tasks are required. See the end of this chapter for the section Distributed CRTP Configuration Examples.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-341

Configuring Distributed Compressed Real-Time Protocol Distributed CRTP Configuration Examples

Changing the Number of Header Compression Connections

By default, for Frame Relay encapsulation, there can be 256 TCP header compression connections and 256 RTP header compression connections (128 calls for each type). The maximum value is fixed, not configurable. By default, for PPP or High-Level Data Link Control (HDLC) encapsulation, the software allows 32 TCP header compression connections (16 calls). This default can be increased to a maximum of 256 TCP header compression connections. The Cisco IOS software also allows 32 RTP header compression connections (16 calls). This default can be increased to a maximum of 1000 RTP header compression connections on an interface. To change the number of compression connections supported, use the following commands in interface configuration mode, as needed: Command
Router(config-if)# ip tcp compression-connections number

Purpose Specifies the total number of TCP header compression connections supported on the interface. Specifies the total number of RTP header compression connections supported on the interface.

Router(config-if)# ip rtp compression-connections number

Distributed CRTP Configuration Examples

The following sections provide dCRTP configuration examples:

Distributed Compressed RTP Header Compression Example Express TCP Header Compression Example

For information on how to configure the dCRTP feature, see the section Distributed CRTP Configuration Task List in this chapter.

Distributed Compressed RTP Header Compression Example

The following example shows the output of the show ip rtp header command when a Cisco 7500 router with a Versatile Interface Processor (VIP) has the dCRTP feature enabled. When the dCRTP feature is disabled, the distributed fast-switched line of the output, which is in italics for emphasis, does not appear.
Router# show ip rtp header RTP/UDP/IP header compression statistics: Interface Serial4/1/1: Distributed fast switched: 8 seconds since line card sent last stats update Rcvd: 0 total, 0 compressed, 0 errors 0 dropped, 0 buffer copies, 0 buffer failures Sent: 0 total, 0 compressed, 0 bytes saved, 0 bytes sent Connect:16 rx slots, 16 tx slots, 0 long searches, 0 misses 0 collisions

Cisco IOS Quality of Service Solutions Configuration Guide

QC-342

Configuring Distributed Compressed Real-Time Protocol Distributed CRTP Configuration Examples

Express TCP Header Compression Example

The following example shows the output of the show ip tcp header command when a Cisco 7500 router with a VIP has the dCRTP feature enabled. When the dCRTP feature is disabled, the distributed fast-switched line of output, which is in italics for emphasis, does not appear.
Router# show ip tcp header TCP header compression statistics: Interface Serial4/1/1: Distributed fast switched: 8 seconds since line card sent last stats update Rcvd: 0 total, 0 compressed, 0 errors 0 dropped, 0 buffer copies, 0 buffer failures Sent: 0 total, 0 compressed, 0 bytes saved, 0 bytes sent Connect:16 rx slots, 16 tx slots, 0 long searches, 0 misses 0 collisions

Cisco IOS Quality of Service Solutions Configuration Guide

QC-343

Configuring Distributed Compressed Real-Time Protocol Distributed CRTP Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-344

Quality of Service Solutions

IP to ATM Class of Service Overview

This chapter provides a high-level overview of IP to ATM Class of Service (CoS), a feature suite that maps QoS characteristics between IP and ATM. For information on how to configure IP to ATM CoS, see the chapter Configuring IP to ATM Class of Service in this book.

About IP to ATM CoS

The IP to ATM CoS feature implements a solution for coarse-grained mapping of QoS characteristics between IP and ATM, using Cisco Enhanced ATM port adapters (PA-A3) on Cisco 7200 and Cisco 7500 series routers. (This category of coarse-grained QoS is often referred to as CoS). The resulting feature makes it possible to support differential services in network service provider environments. IP to ATM CoS is designed to provide a true working solution to class-based services, without the investment of new ATM network infrastructures. Now networks can offer different service classes (sometimes termed differential service classes ) across the entire WAN, not just the routed portion. Mission-critical applications can be given exceptional service during periods of high network usage and congestion. In addition, noncritical traffic can be restricted in its network usage, which ensures greater QoS for more important traffic and user types. The IP to ATM CoS feature is supported on Cisco 2600, Cisco 3600, Cisco 7200, and Cisco 7500 series routers equipped with the following hardware:

Cisco 2600 and Cisco 3600 series: ATM OC-3, T1 IMA, or E1 IMA port adapter Cisco 7200 series:
NPE-200 or higher (NPE-300 recommended for per-virtual circuit (VC) class-based weighted

fair queueing (CBWFQ)

One of the following Enhanced ATM port adapters (PA-A3): T3, E3, DS3, or OC-3

Cisco 7500 series:

VIP2-50 One of the following Enhanced ATM port adapters (PA-A3): T3, E3, DS3, or OC-3

IP to ATM CoS supports configuration of the following features:

Single ATM VCs VC bundles Per-VC Low Latency Queueing (LLQ), WFQ, and CBWFQ

Cisco IOS Quality of Service Solutions Configuration Guide

QC-347

IP to ATM Class of Service Overview About IP to ATM CoS

Single ATM VC Support

IP to ATM CoS support for a single ATM VC allows network managers to use existing features, such as committed access rate (CAR) or policy-based routing (PBR), to classify and mark different IP traffic by modifying the IP Precedence field in the IP version 4 (IPv4) packet header. Subsequently, Weighted Random Early Detection (WRED) or distributed WRED (DWRED) can be configured on a per-VC basis so that the IP traffic is subject to different drop probabilities (and therefore priorities) as IP traffic coming into a router competes for bandwidth on a particular VC. Enhanced ATM port adapters (PA-A3) provide the ability to shape traffic on each VC according to the ATM service category and traffic parameters employed. When you use the IP to ATM CoS feature, congestion is managed entirely at the IP layer by WRED running on the routers at the edge of the ATM network. Figure 27 illustrates the IP to ATM CoS support for a single ATM VC.
Figure 27 Single ATM Circuit Class
Class of service Class of service

Router configured with CAR

Router configured with per-VC WRED

16026

ATM WAN

VC Bundle Support and Bundle Management

ATM VC bundle management allows you to configure multiple VCs that have different QoS characteristics between any pair of ATM-connected routers. As shown in Figure 28, these VCs are grouped in a bundle and are referred to as bundle members.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-348

IP to ATM Class of Service Overview About IP to ATM CoS

Figure 28

ATM VC Bundle

VC 1

IP Precedence

ATM VC bundle management allows you to define an ATM VC bundle and add VCs to it. Each VC of a bundle has its own ATM traffic class and ATM traffic parameters. You can apply attributes and characteristics to discrete VC bundle members or you can apply them collectively at the bundle level. Using VC bundles, you can create differentiated service by flexibly distributing IP precedence levels over the different VC bundle members. You can map a single precedence level or a range of levels to each discrete VC in the bundle, thereby enabling individual VCs in the bundle to carry packets marked with different precedence levels. You can use WRED (or DWRED) to further differentiate service across traffic that has different IP precedences but that uses the same VC in a bundle. To determine which VC in the bundle to use to forward a packet to its destination, the ATM VC bundle management software matches precedence levels between packets and VCs (see Figure 29). IP traffic is sent to the next hop address for the bundle because all VCs in a bundle share the same destination, but the VC used to carry a packet depends on the value set for that packet in the IP Precedence bits of the type of service (ToS) byte of its header. The ATM VC bundle management software matches the IP precedence of the packet to the IP Precedence value or range of values assigned to a VC, sending the packet out on the appropriate VC. Moreover, the ATM VC bundle management feature allows you to configure how traffic will be redirected when the VC the packet was matched to goes down. Figure 29 illustrates how the ATM VC bundle management software determines which permanent virtual circuit (PVC) bundle member to use to carry a packet and how WRED (or DWRED) is used to differentiate traffic on the same VC.

Cisco IOS Quality of Service Solutions Configuration Guide

22313

QC-349

IP to ATM Class of Service Overview About IP to ATM CoS

Figure 29

ATM VC Bundle PVC Selection for Packet Transfer

VC1 VC2 VC3 VC4

VC selection based on precedence

The support of multiple parallel ATM VCs allows you to create stronger service differentiation at the IP layer. For instance, you might want to provide IP traffic belonging to real-time CoS (such as Voice over IP traffic) on an ATM VC with strict constraints (constant bit rate (CBR) or variable bit rate real-time (VBR-rt), for example), while transporting traffic other than real-time traffic over a more elastic ATM available bit rate (ABR) PVC. Using a configuration such as this would allow you to fully utilize your network capacity. You could also elect to transport best-effort IP traffic over an unspecified bit rate (UBR) PVCUBR is effectively the ATM version of best-effort service.

Per-VC LLQ, WFQ and CBWFQ Support

The IP to ATM CoS feature allows you to apply a policy map to a VC to specify a service policy for that VC so that all traffic sent on that VC is categorized according to the classes and their match criteria defined by the service policy. In other words, IP to ATM CoS takes the functionality defined for standard LLQ, WFQ, and CBWFQ and makes it available for application and use at the discrete VC level. For conceptual information on LLQ, WFQ, and CBWFQ, see the chapter Congestion Management Overview in this book. IP to ATM CoS allows you to configure a single, standalone VC or individual VCs belonging to a bundle. You also can configure collectively all VCs belonging to a bundle. However, for per-VC LLQ, WFQ and CBWFQ, you can configure individual VCs only. That is, you can configure a standalone VC or a VC that belongs to a bundle, but you cannot use per-VC LLQ, WFQ and CBWFQ to configure a bundle of VCs collectively. Per-VC LLQ, WFQ and CBWFQ allows you to differentiate the use of individual VCs within a bundle. For instance, you can apply one service policy to one VC belonging to a VC bundle and apply a different service policy to another VC belonging to the same bundle. You can also apply the same policy map to multiple VCswhether standalone or bundle membersbut each VC can have only one service policy. To concatenate service policies, you must create a third policy map and include in it all the classes that you want to use from policy maps you would have concatenated.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-350

17626

WRED in per-VC queue

IP to ATM Class of Service Overview Why Use IP to ATM CoS?

The following is a summary of how you configure a VC to use CBWFQ:

You define traffic classes to specify the classification policy (class maps). This process determines how many types of packets are to be differentiated from one another. You configure policy maps containing classes that specify the policy for each traffic class. You attach a policy map to a VC that uses IP to ATM CoS to specify the service policy for the VC.

To apply flow-based WFQ on a per-VC basis, you configure WFQ in the predefined CBWFQ default class, which is called class-default, but you do not ascribe bandwidth to the default class. How to configure the default class to specify flow-based fair queueing is explained in the section Configuring a VC to Use Flow-Based WFQ in the Configuring IP to ATM Class of Service chapter in this book.

Why Use IP to ATM CoS?

Internet service classes can be identified and sorted within the router network. But as traffic traverses the wide-area ATM fabric, the relative ATM class definitions are not equivalent, and a traffic type may be treated differently in the ATM switching fabric than in the router network; mission-critical applications or data could be dropped during times of network congestion. The IP to ATM CoS feature uses the Cisco Enhanced ATM port adapter (PA-A3) on Cisco 7500 and Cisco 7200 series routers to provide the ability to map IP CoS and ATM QoS, extending the capability previously available only for IP networks; differentiated services are preserved through the ATM network.

Benefits
Here are some benefits of using IP to ATM CoS:

Ensures effective differential classes over IP and traditional ATM networks. For instance, the VC bundle management feature provides for differentiated QoS by allowing for the coexistence of multiple VCs with different QoS characteristics from the same source to the same destination. Uses existing ATM infrastructures. Implements solutions for coarse-grained mapping of QoS characteristics called CoS between IP and ATM. Employs a high-performance design benefiting from distributed processing on the Cisco 7500 series routers and Versatile Interface Processor (VIP). Uses the Cisco Enhanced ATM port adapter (PA-A3), which supports traffic shaping and has rich ATM Service Category support. This port adapter (PA) is supported on the Cisco 7500+VIP and Cisco 7200 series routers. Provides per-VC queueing on the PA, per-VC back pressure, and per-VC WRED VIP queueing, which bring stability to a network by ensuring that system packets such as Border Gateway Protocol (BGP) and Intermediate System-to-Intermediate System (IS-IS) are never dropped. Provides flexible management of the VC bundle on PVC failure. Provides CBWFQ functionality at the VC level.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-351

IP to ATM Class of Service Overview IP to ATM CoS Features

IP to ATM CoS Features

IP to ATM CoS includes the following features:

Per-VC queueing infrastructure. This feature enables queues to be maintained on a per-VC basis. Packets are queued and dequeued based on the back pressure from the PA. Use of a queue per VC prevents one or more congested VCs from affecting the traffic flow on other VCs that are not congested. Per-VC WRED (or DWRED). This feature applies the WRED algorithm independently to each per-VC queue. The WRED parameters are configurable on a per-VC basis so that congestion management can be configured as appropriate for each VC. Per-VC WRED (or DWRED) statistics. This feature maintains per-flow and per-VC statistics based on IP precedence. Per-VC LLQ, WFQ and CBWFQ. This feature allows you to apply CBWFQ functionalitynormally applicable at the interface or subinterface levels onlyto an individual VC configured for IP to ATM CoS. You can use this feature to apply either CBWFQ or flow-based WFQ on a per-VC basis. Per-VC traffic policing. This feature allows you to police traffic within a traffic policy, per-VC.

Congestion Avoidance
For each VC that is created on the Enhanced ATM port adapter (PA-A3), the PA allocates some of the buffers from its buffer pool to that VC in order to create a queue for that VC. The use of per-VC queues ensures that a direct relationship exists between the outgoing ATM VC and the IP packets to be forwarded on that queue. This mechanism establishes a packet queue for each outgoing ATM VC. In this manner, should an ATM VC become congested, only the packet queue associated with that VC will begin to fill. If the queue overfills, then all other queues remain unaffected. Such a mechanism ensures that an individual VC cannot consume all of the resources of the router should only one of its outgoing VCs be congested or underprovisioned. Queues for buffering more packets for a particular VC are created in the Layer 3 processor system and are mapped one-to-one to the per-VC queues on the PA. When the PA per-VC queues become congested, they signal back pressure to the Layer 3 processor; the Layer 3 processor can then continue to buffer packets for that VC in the corresponding Layer 3 queue. Furthermore, because the Layer 3 queues are accessible by the Layer 3 processor, a user can run flexible software scheduling algorithms on those queues. When you transport data over ATM fabrics, it is essential that decisions to discard data (because of insufficient network resources or congestion) be made at the packet level. To do otherwise would be to send incomplete data packets into the ATM fabric, causing the packets to be discarded by either the ATM switched fabric (if it is equipped with early packet discard) or at the remote end where the packet will be reassembled and found to be incomplete. To initiate effective congestion management techniques, IP to ATM CoS uses per-VC WRED (or DWRED). Per-VC WRED (or DWRED) selectively places TCP sessions in slow start mode to ensure higher aggregate throughput under congestion. Figure 30 shows low priority packets being dropped on VC1 because VC1 is congested. In this example, VC2 is not congested and all packets, regardless of priority, are sent.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-352

IP to ATM Class of Service Overview Bumping and ATM VC Bundles

Figure 30

Traffic Congestion with IP to ATM CoS and Per-VC WRED

Congestion on VC1 (low precedence packets dropped) VC1 VC2 No congestion on VC2 (all packets are sent) ATM WAN

High precedence traffic Low precedence traffic

Running the WRED algorithm independently on each per-VC queue provides differentiated QoS to traffic of different IP Precedence values.

Bumping and ATM VC Bundles

The ATM VC bundle is designed to behave as a single routing link to the destination router while managing the integrity of its group of circuits. The integrity of each circuit is maintained through individual monitoring. Should a circuit fail, appropriate action is taken, in the form of circuit bumping or bundle disabling. VC integrity is maintained through ATM Operation, Administration, and Maintenance (OAM) polling mechanisms. These mechanisms will determine whether a VC is unavailable or severely congested. Should an individual circuit become unavailable, then the device consults a preset series of rules to determine the course of action to take next. These rules are defined by the Internet service provider (ISP) through configuration parameters. Figure 31 conceptualizes a failed VC bundle member whose failure calls into effect the configured bumping rules.

Cisco IOS Quality of Service Solutions Configuration Guide

16467

QC-353

IP to ATM Class of Service Overview Restrictions

Figure 31

VC Bundle Member Circuit Failure Enacting Bumping Rules

Bump Failure VC 1

IP Precedence

In the event of failure, the router responds with one of two methods. The first method dynamically assigns the traffic bound on the failed VC to an alternative VC, which is termed circuit bumping. Bumped traffic is then shared on an existing in-service VC. Traffic typically would be bumped from a higher class to a lower one, although it need not be. For example, should the premium, or first class, data circuit become unavailable, then all premium users would share the second class or general circuit. Preference would then be given to the premium traffic within this shared circuit. The second method is to declare all circuits of the bundle to be down. In effect, the device is declaring the routed bundle inactive and asking the routing layer to search for an alternate. The determination of whether to bump or whether to declare the bundle inactive is predefined by the network provider when administering the network configuration.

Restrictions
The following restrictions apply for IP to ATM CoS:

IP to ATM CoS supports only PVCs:

For PVC connections, it supports multipoint and point-to-point subinterfaces. For PVC encapsulations, it supports only ATM adaptation layer (AAL5), Subnetwork Access

Protocol (SNAP), and multiplex device (mux) interfaces.

IP to ATM CoS does not allow point-to-multipoint VCs in the bundle. All VCs share the same source and destination (target) addresses. IP to ATM CoS does not work with the ATM Interface Processor (AIP) and the ATM port adapter (PA-A1).

Cisco IOS Quality of Service Solutions Configuration Guide

QC-354

22314

Configuring IP to ATM Class of Service

This chapter describes the tasks for configuring the IP to ATM Class of Service (CoS), a feature suite that maps QoS characteristics between IP and ATM. For complete conceptual information, see the chapter IP to ATM Class of Service Overview in this book. For a complete description of the IP to ATM CoS commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

IP to ATM CoS on a Single ATM VC Configuration Task List

To configure IP to ATM CoS for a single ATM virtual circuit (VC), perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.

Defining the WRED Parameter Group (Required) Configuring the WRED Parameter Group (Required) Displaying the WRED Parameters (Optional) Displaying the Queueing Statistics (Optional)

The IP to ATM CoS feature requires ATM permanent virtual circuit (PVC) management. See the end of this chapter for the section Single ATM VC with WRED Group and IP Precedence Example.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-355

Configuring IP to ATM Class of Service IP to ATM CoS on a Single ATM VC Configuration Task List

Defining the WRED Parameter Group

To define the Weighted Random Early Detection (WRED) parameter group, use the following command in global configuration mode: Command
Router(config)# random-detect-group group-name

Purpose Defines the WRED or VIP-distributed WRED (DWRED) parameter group.

Configuring the WRED Parameter Group

To configure the exponential weight factor for the average queue size calculation for a WRED parameter group or to configure a WRED parameter group for a particular IP precedence, use the following commands in global configuration mode: Command
Step 1 Step 2
Router(config)# random-detect-group group-name Router(config)# exponential-weighting-constant exponent

Purpose Specifies the WRED or DWRED parameter group. Configures the exponential weight factor for the average queue size calculation for the specified WRED or DWRED parameter group.

or or
Router(config)# precedence precedence min-threshold max-threshold mark-probability-denominator

Configures the specified WRED or DWRED parameter group for a particular IP precedence.

Displaying the WRED Parameters

To display the configured WRED parameters, use the following command in privileged EXEC mode: Command
Router# show queueing random-detect [interface atm_subinterface [vc [[vpi/] vci]]]

Purpose Displays the parameters of every VC with WRED or DWRED enabled on the specified ATM subinterface.

Displaying the Queueing Statistics

To display the queueing statistics of an interface, use the following command in privileged EXEC mode: Command
Router# show queueing interface interface-number [vc [[vpi/] vci]]

Purpose Displays the queueing statistics of a specific VC on an interface.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-356

Configuring IP to ATM Class of Service IP to ATM CoS on an ATM Bundle Configuration Task List

IP to ATM CoS on an ATM Bundle Configuration Task List

To configure IP to ATM CoS on an ATM bundle, perform the tasks in the following sections. The first four sections are required; the remaining sections are optional.

Creating a VC Bundle (Required) Applying Bundle-Level Parameters (Required)

Configuring Bundle-Level Parameters Configuring VC Class Parameters to Apply to a Bundle Attaching a Class to a Bundle

Committing a VC to a Bundle (Required) Applying Parameters to Individual VCs (Required)

Configuring a VC Bundle Member Directly Configuring VC Class Parameters to Apply to a VC Bundle Member Applying a VC Class to a Discrete VC Bundle Member

Configuring a VC Not to Accept Bumped Traffic (Optional) Monitoring and Maintaining VC Bundles and Their VC Members (Optional)

The IP to ATM CoS feature requires ATM PVC management. See the end of this chapter for the section VC Bundle Configuration Using a VC Class Example.

Creating a VC Bundle
To create a bundle and enter bundle configuration mode in which you can assign attributes and parameters to the bundle and all of its member VCs, use the following command in subinterface configuration mode: Command
Router(config-subif)# bundle bundle-name

Purpose Creates the specified bundle and enters bundle configuration mode.

Applying Bundle-Level Parameters

Bundle-level parameters can be applied either by assigning VC classes or by directly applying them to the bundle. Parameters applied through a VC class assigned to the bundle are superseded by those applied at the bundle level. Bundle-level parameters are superseded by parameters applied to an individual VC.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-357

Configuring IP to ATM Class of Service IP to ATM CoS on an ATM Bundle Configuration Task List

Configuring Bundle-Level Parameters

Configuring bundle-level parameters is optional if a class is attached to the bundle to configure it. To configure parameters that apply to the bundle and all of its members, use the following commands in bundle configuration mode, as needed: Command
Router(config-atm-bundle)# protocol protocol {protocol-address | inarp} [[no] broadcast]

Purpose Configures a static map or enables Inverse Address Resolution Protocol (Inverse ARP) or Inverse ARP broadcasts for the bundle. Configures the ATM adaptation layer (AAL) and encapsulation type for the bundle. Configures the Inverse ARP time period for all VC bundle members. Enables broadcast forwarding for all VC bundle members. Configures the VC bundle parameters related to operation, administration, and maintenance (OAM) management. Enables end-to-end F5 OAM loopback cell generation and OAM management for all VCs in the bundle.

Router(config-atm-bundle)# encapsulation aal-encap

Router(config-atm-bundle)# inarp minutes

Router(config-atm-bundle)# broadcast

Router(config-atm-bundle)# oam retry up-count down-count retry frequency

Router(config-atm-bundle)# oam-bundle [manage] [frequency]

Configuring VC Class Parameters to Apply to a Bundle

Use of a VC class allows you to configure a bundle applying multiple attributes to it at once because you apply the class itself to the bundle. Use of a class allows you to generalize a parameter across all VCs, after which (for some parameters) you can modify that parameter for individual VCs. (See the section Applying Parameters to Individual VCs for more information.) To configure a VC class to contain commands that configure all VC members of a bundle when the class is applied to that bundle, use the following command in vc-class configuration mode. To enter vc-class configuration mode, use the vc-class atm command. Command
Router(config-vc-class)# oam-bundle [manage] [frequency]

Purpose Enables end-to-end F5 OAM loopback cell generation and OAM management for all VCs in the bundle.

In addition to this command, you can add the following commands to a VC class to be used to configure a bundle: broadcast, encapsulation, inarp, oam retry, and protocol. For information on these commands, including configuration tasks and command syntax, refer to the Cisco IOS Wide-Area Networking Configuration Guide and the Cisco IOS Wide-Area Networking Command Reference.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-358

Configuring IP to ATM Class of Service IP to ATM CoS on an ATM Bundle Configuration Task List

Attaching a Class to a Bundle

To attach a preconfigured VC class containing bundle-level configuration commands to a bundle, use the following command in bundle configuration mode: Command
Router(config-atm-bundle)# class-bundle vc-class-name

Purpose Configures a bundle with the bundle-level commands contained in the specified VC class.

Parameters set through bundle-level commands contained in the VC class are applied to the bundle and all of its VC members. Bundle-level parameters applied through commands configured directly on the bundle supersede those applied through a VC class. Note that some bundle-level parameters applied through a VC class or directly to the bundle can be superseded by commands that you directly apply to individual VCs in bundle-vc configuration mode.

Committing a VC to a Bundle
To add a VC to an existing bundle and enter bundle-vc configuration mode, use the following command in bundle configuration mode: Command
Router(config-atm-bundle)# pvc-bundle pvc-name [vpi/] [vci]

Purpose Adds the specified VC to the bundle and enters bundle-vc configuration mode in order to configure the specified VC bundle member.

For information on how to first create the bundle and configure it, see the sections Creating a VC Bundle and Applying Bundle-Level Parameters earlier in this chapter.

Applying Parameters to Individual VCs

Parameters can be applied to individual VCs either by using VC classes or by directly applying them to the bundle members. Parameters applied to an individual VC supersede bundle-level parameters. Parameters applied directly to a VC take precedence over the same parameters applied within a class to the VC at the bundle-vc configuration level.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-359

Configuring IP to ATM Class of Service IP to ATM CoS on an ATM Bundle Configuration Task List

Configuring a VC Bundle Member Directly

Configuring VC bundle members directly is optional if a VC class is attached to the bundle member. To configure an individual VC bundle member directly, use the following commands in bundle-vc configuration mode, as needed: Command
Router(config-if-atm-member)# ubr output-pcr [input-pcr]

Purpose Configures the VC for unspecified bit rate (UBR) QoS and specifies the output peak cell rate (PCR) for it. Configures the VC for UBR QoS and specifies the output PCR and output minimum guaranteed cell rate for it. Configures the VC for variable bit rate nonreal-time (VBR-nrt) QoS and specifies the output PCR, output sustainable cell rate, and output maximum burst cell size for it. Configures the precedence levels for the VC. Configures the bumping rules for the VC. Configures the VC to belong to the protected group of the bundle or to be an individually protected VC bundle member.

Router(config-if-atm-member)# ubr+ output-pcr output-mcr [input-pcr] [input-mcr]

Router(config-if-atm-member)# vbr-nrt output-pcr output-scr output-mbs [input-pcr] [input-scr] [input-mbs]

Router(config-if-atm-member)# precedence [other | range] Router(config-if-atm-member)# bump {implicit | explicit precedence-level | traffic} Router(config-if-atm-member)# protect {group | vc}

Parameters set directly for a VC at the bundle-vc configuration level take precedence over values for these parameters set for the VC at any other level, including application of a VC class at the bundle-vc configuration level.

Configuring VC Class Parameters to Apply to a VC Bundle Member

To configure a VC class to contain commands that configure a specific VC member of a bundle when the class is applied to it, use the following commands in vc-class configuration mode, as needed. To enter vc-class configuration mode, use the vc-class atm command in global configuration mode. Command
Router(config-vc-class)# bump {implicit | explicit precedence-level | traffic}

Purpose Specifies the bumping rules for the VC member to which the class is applied. These rules determine to which VC in the bundle traffic is directed when the carrier VC bundle member goes down. Defines precedence levels for the VC member to which the class is applied. Configures the VC as a member of the protected group of the bundle or as an individually protected VC.

Router(config-vc-class)# precedence precedence min-threshold max-threshold mark-probability-denominator Router(config-vc-class)# protect {group | vc}

You can also add the following commands to a VC class to be used to configure a VC bundle member: ubr, ubr+, and vbr-nrt.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-360

Configuring IP to ATM Class of Service IP to ATM CoS on an ATM Bundle Configuration Task List

Use of a VC class allows you to configure a VC bundle member with multiple attributes at once because you can apply the class to the VC.

Note

When a VC is a member of a VC bundle, the following commands cannot be used in vc-class mode to configure the VC: encapsulation, protocol, inarp, and broadcast. These commands are useful only at the bundle level, not the bundle member level. To configure the way bumping is handled for individual VCs within a bundle, use the bump command in the bundle-vc configuration mode. For more information about the bumping rules, see the section Bumping and ATM VC Bundles in the IP to ATM Class of Service Overview chapter in this book. Configuration for an individual VC overrides the collective configuration applied to all VC bundle members through application of a VC class to the bundle.

Applying a VC Class to a Discrete VC Bundle Member

To attach a preconfigured VC class containing bundle-level configuration commands to a bundle member, use the following command in bundle-vc configuration mode: Command
Router(config-if-atm-member)# class-vc vc-class -name

Purpose Assigns a VC class to a VC bundle member.

Parameters that configure a VC that are contained in a VC class assigned to that VC are superseded by parameters that are directly configured for the VC through discrete commands entered in bundle-vc configuration mode.

Configuring a VC Not to Accept Bumped Traffic

To configure an individual VC bundle member not to accept traffic that otherwise might be directed to it if the original VC carrying the traffic goes down, use the following command in bundle-vc configuration mode: Command
Router(config-if-atm-member)# no bump traffic

Purpose Configures the VC not to accept any bumped traffic that would otherwise be redirected to it.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-361

Configuring IP to ATM Class of Service Per-VC WFQ and CBWFQ Configuration Task List

Monitoring and Maintaining VC Bundles and Their VC Members

To gather information on bundles so as to monitor them or to troubleshoot problems that pertain to their configuration or use, use the following commands in privileged EXEC mode, as needed: Command
Router# show atm bundle bundle-name

Purpose Displays the bundle attributes assigned to each bundle VC member and the current working status of the VC members. Displays statistics or detailed statistics on the specified bundle. Displays a list of all configured ATM static maps to remote hosts on an ATM network and on ATM bundle maps. Displays information on bundle errors. Displays a record of bundle events.

Router# show atm bundle bundle-name statistics [detail] Router# show atm map

Router# debug atm bundle errors Router# debug atm bundle events

Per-VC WFQ and CBWFQ Configuration Task List

To configure IP to ATM CoS for per-VC WFQ and CBWFQ, perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.

Configuring Class-Based Weighted Fair Queueing (Required) Attaching a Service Policy and Enabling CBWFQ for a VC (Required) Configuring a VC to Use Flow-Based WFQ (Optional) Monitoring per-VC WFQ and CBWFQ (Optional) Enabling Logging of Error Messages to the Console (Optional)

The IP to ATM CoS feature requires ATM PVC management. See the end of this chapter for the sections Per-VC WFQ and CBWFQ on a Standalone VC Example and Per-VC WFQ and CBWFQ on Bundle-Member VCs Example.

Configuring Class-Based Weighted Fair Queueing

Before configuring CBWFQ for a VC, you must perform the following tasks using standard CBWFQ commands:

Create one or more classes to be used to classify traffic sent across the VC Define a policy map containing the classes to be used as the service policy

Cisco IOS Quality of Service Solutions Configuration Guide

QC-362

Configuring IP to ATM Class of Service Per-VC WFQ and CBWFQ Configuration Task List

Note

You can configure class policies for as many classes as are defined on the router, up to the maximum of 64. However, the total amount of bandwidth allocated for all classes included in a policy map to be attached to a VC must not exceed 75 percent of the available bandwidth of the VC. The remaining 25 percent of available bandwidth is used for encapsulation, such as the ATM cell overhead (also referred to as ATM cell tax), routing and best-effort traffic, and other functions that assume overhead. For more information on bandwidth allocation, see the section Bandwidth Management in the Congestion Management Overview chapter in this book. For information on how to configure CBWFQ and perform the tasks mentioned, see the chapter Configuring Weighted Fair Queueing in this book.

Attaching a Service Policy and Enabling CBWFQ for a VC

Because CBWFQ gives you minimum bandwidth guarantee, you can only apply CBWFQ to VCs having these classes of service: available bit rate (ABR) and variable bit rate (VBR). You cannot apply per-VC WFQ and CBWFQ to UBR and unspecified bit rate plus (UBR+) VCs because both of these service classes are best-effort classes that do not guarantee minimum bandwidth. When CBWFQ is enabled for a VC, all classes configured as part of the service policy are installed in the fair queueing system. To attach a policy map to a standalone VC to be used as its service policy and to enable CBWFQ on that VC, use the following command in VC submode: Command
Router(config-if-atm-vc)# service-policy output policy-map

Purpose Enables CBWFQ and attaches the specified service policy map to the VC being created or modified.

To attach a policy map to an individual VC bundle member to be used as its service policy and to enable CBWFQ on that VC, use the following command in bundle-vc configuration mode: Command
Router(config-if-atm-member)# service-policy output policy-map

Purpose Enables CBWFQ and attaches the specified service policy map to the VC being created or modified.

Note

The service-policy output and random-detect-group commands are mutually exclusive; you cannot apply a WRED group to a VC for which you have enabled CBWFQ through application of a service policy. Moreover, before you can configure one command, you must disable the other if it is configured.

Configuring a VC to Use Flow-Based WFQ

In addition to configuring CBWFQ at the VC level, the IP to ATM CoS feature allows you to configure flow-based WFQ at the VC level. Because flow-based WFQ gives you best-effort class of servicethat is, it does not guarantee minimum bandwidthyou can configure per-VC WFQ for all types of CoS VCs: ABR, VBR, UBR, and UBR+.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-363

Configuring IP to ATM Class of Service Per-VC WFQ and CBWFQ Configuration Task List

Per-VC WFQ uses the class-default class. Therefore, to configure per-VC WFQ, you must first create a policy map and configure the class-default class. (You need not create the class-default class, which is predefined, but you must configure it.) For per-VC WFQ, the class-default class must be configured with the fair-queue policy-map class configuration command. In addition to configuring the fair-queue policy-map class configuration command, you can configure the default class with either the queue-limit command or the random-detect command, but not both. Moreover, if you want the default class to use flow-based WFQ, you cannot configure the default class with the bandwidth policy-map class configuration commandto do so would disqualify the default class as flow-based WFQ, and therefore limit application of the service policy containing the class to ABR and VBR VCs. To create a policy map and configure the class-default class, use the following commands beginning in global configuration mode: Command
Step 1 Step 2 Step 3 Step 4
Router(config)# policy-map policy-map Router(config-pmap)# class class-default default-class-name Router(config-pmap-c)# fair-queue number-of-dynamic-queues Router(config-pmap-c)# queue-limit number-of-packets

Purpose Specifies the name of the policy map to be created or modified. Specifies the default class so that you can configure or modify its policy. Specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class. Specifies the maximum number of packets that can be queued for the class.

or
Router(config-pmap-c)# random-detect

Enables WRED. The class policy will drop packets using WRED instead of tail drop.

For more information about creating a policy map and configuring the class-default class, see the chapter Configuring Weighted Fair Queueing in this book. By defaultthat is, even if you do not configure the class-default class with the fair-queue policy-map class configuration command and you do not configure it with the bandwidth policy-map class configuration commandthe default class is defined as flow-based WFQ. Note that you can include other classes in the same policy map as the one that contains the flow-based WFQ class. Packets not otherwise matched are selected by the default class-default class match criteria. To attach the policy map containing the class-default class to a standalone VC so that it becomes the service policy enabling WFQ for that VC, use the following command in VC submode: Command
Router(config-if-atm-vc)# service-policy output policy-map

Purpose Enables WFQ for the VC by attaching the specified policy map containing the class-default class to the VC being created or modified.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-364

Configuring IP to ATM Class of Service IP to ATM CoS Configuration Examples

To attach the policy map containing the class-default class to an individual VC bundle member so that the policy map becomes the service policy enabling WFQ for that VC, use the following command in bundle-vc configuration mode: Command
Router(config-if-atm-member)# service-policy output policy-map

Purpose Enables WFQ for the VC bundle member by attaching the specified policy map containing the class-default class to the VC bundle member.

Monitoring per-VC WFQ and CBWFQ

To monitor per-VC WFQ and CBWFQ in your network, use the following commands in EXEC mode, as needed: Command
Router# show queue interface-name interface-number [vc [vpi/] vci]] Router# show queueing interface interface-number [vc [[vpi/] vci]]

Purpose Displays the contents of packets inside a queue for a particular interface or VC. Displays the queueing statistics of a specific VC on an interface.

Enabling Logging of Error Messages to the Console

When you configure a VC in order to create or modify it, the router performs the task in interrupt mode. For this reason, the router cannot issue printf statements to inform you of error conditions, if errors occur. Rather, the router logs all error messages to the console. To accommodate these circumstances, you should enable logging of error messages to the console. To enable logging of error messages to the console, use the following command in global configuration mode: Command
Router(config)# logging console level

Purpose Limits messages logged to the console based on severity.

For information on the logging console command, including configuration tasks and command syntax, refer to the Cisco IOS Configuration Fundamentals Configuration Guide and the Cisco IOS Configuration Fundamentals Command Reference.

IP to ATM CoS Configuration Examples

The following sections provide IP to ATM CoS configuration examples:

Single ATM VC with WRED Group and IP Precedence Example VC Bundle Configuration Using a VC Class Example

Cisco IOS Quality of Service Solutions Configuration Guide

QC-365

Configuring IP to ATM Class of Service IP to ATM CoS Configuration Examples

Per-VC WFQ and CBWFQ on a Standalone VC Example Per-VC WFQ and CBWFQ on Bundle-Member VCs Example

For information on how to configure IP to ATM CoS, see the sections IP to ATM CoS on a Single ATM VC Configuration Task List and IP to ATM CoS on an ATM Bundle Configuration Task List in this chapter.

Single ATM VC with WRED Group and IP Precedence Example

The following example creates a PVC on an ATM interface and applies the WRED parameter group called sanjose to that PVC. Next, the IP Precedence values are configured for the WRED parameter group sanjose.
interface ATM1/1/0.46 multipoint ip address 200.126.186.2 255.255.255.0 no ip mroute-cache shutdown pvc cisco 46 encapsulation aal5nlpid random-detect attach sanjose ! random-detect-group sanjose precedence 0 200 1000 10 precedence 1 300 1000 10 precedence 2 400 1000 10 precedence 3 500 1000 10 precedence 4 600 1000 10 precedence 5 700 1000 10 precedence 6 800 1000 10 precedence 7 900 1000 10

VC Bundle Configuration Using a VC Class Example

This example configures VC bundle management on a router that uses Intermediate System-to-Intermediate System (IS-IS) as its IP routing protocol.

Bundle-Class Class
At the outset, this configuration defines a VC class called bundle-class that includes commands that set VC parameters. When the class bundle-class is applied at the bundle level, these parameters are applied to all VCs that belong to the bundle. Note that any commands applied directly to an individual VC of a bundle in bundle-vc mode take precedence over commands applied globally at the bundle level. Taking into account hierarchy precedence rules, VCs belonging to any bundle to which the class bundle-class is applied will be characterized by these parameters: aal5snap encapsulation, broadcast on, use of Inverse Address Resolution Protocol (ARP) to resolve IP addresses, and operation, administration, and maintenance (OAM) enabled.
router isis net 49.0000.0000.0000.1111.00 vc-class atm bundle-class encapsulation aal5snap broadcast protocol ip inarp oam-bundle manage 3 oam 4 3 10

Cisco IOS Quality of Service Solutions Configuration Guide

QC-366

Configuring IP to ATM Class of Service IP to ATM CoS Configuration Examples

The following sections of the configuration define VC classes that contain commands specifying parameters that can be applied to individual VCs in a bundle by assigning the class to that VC.

Control-Class Class
When the class called control-class is applied to a VC, the VC carries traffic whose IP Precedence level is 7. When the VC to which this class is assigned goes down, it takes the bundle down with it because this class makes the VC a protected one. The QoS type of a VC using this class is vbr-nrt.
vc-class atm control-class precedence 7 protect vc vbr-nrt 1000 5000 32

Premium-Class Class
When the class called premium-class is applied to a VC, the VC carries traffic whose IP Precedence levels are 6 and 5. The VC does not allow other traffic to be bumped onto it. When the VC to which this class is applied goes down, its bumped traffic will be redirected to a VC whose IP Precedence level is 7. This class makes a VC a member of the protected group of the bundle. When all members of a protected group go down, the bundle goes down. The QoS type of a VC using this class is vbr-nrt.
vc-class atm premium-class precedence 6-5 no bump traffic protect group bump explicitly 7 vbr-nrt 20000 10000 32

Priority-Class Class
When the class called priority-class is applied to a VC, the VC is configured to carry traffic with IP Precedence in the 4-2 range. The VC uses the implicit bumping rule, it allows traffic to be bumped, and it belongs to the protected group of the bundle. The QoS type of a VC using this class is ubr+.
vc-class atm priority-class precedence 4-2 protect group ubr+ 10000 3000

Basic-Class Class
When the class called basic-class is applied to a VC, the VC is configured through the precedence other command to carry traffic with IP Precedence levels not specified in the profile. The VC using this class belongs to the protected group of the bundle. The QoS type of a VC using this class is ubr.
vc-class atm basic-class precedence other protect group ubr 10000

The following sets of commands configure three bundles that the router subinterface uses to connect to three of its neighbors. These bundles are called new-york, san-francisco, and los-angeles. Bundle new-york has four VC members, bundle san-francisco has four VC members, and bundle los-angeles has three VC members.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-367

Configuring IP to ATM Class of Service IP to ATM CoS Configuration Examples

new-york Bundle
The first part of this example specifies the IP address of the subinterface, the router protocolthe router uses IS-IS as an IP routing protocoland it creates the first bundle called new-york and enters bundle configuration mode:
interface a1/0.1 multipoint ip address 10.0.0.1 255.255.255.0 ip router isis bundle new-york

From within bundle configuration mode, the next portion of the configuration uses two protocol commands to enable IP and Open Systems Interconnect (OSI) traffic flows in the bundle. The OSI routing packets will use the highest precedence VC in the bundle. The OSI data packets, if any, will use the lowest precedence VC in the bundle. If configured, other protocols, such as IPX or AppleTalk, will always use the lowest precedence VC in the bundle. As the indentation levels of the preceding and following commands suggest, subordinate to bundle new-york is a command that configures its protocol and a command that applies the class called bundle-class to it.
protocol ip 1.1.1.2 broadcast protocol clns 49.0000.0000.2222.00 broadcast class-bundle bundle-class

The class called bundle-class, which is applied to the bundle new-york, includes a protocol ip inarp command. According to inheritance rules, protocol ip, configured at the bundle level, takes precedence over protocol ip inarp specified in the class bundle-class. The next set of commands beginning with pvc-bundle ny-control 207, which are further subordinate, add four VCs (called ny-control, ny-premium, ny-priority, and ny-basic) to the bundle new-york. A particular classthat is, one of the classes predefined in this configuration exampleis applied to each VC to configure it with parameters specified by commands included in the class. As is the case for this configuration, to configure individual VCs belonging to a bundle, the router must be in bundle mode for the mother bundle. For each VC belonging to the bundle, the subordinate mode is pvc-mode for the specific VC. The following commands configure the individual VCs for the bundle new-york:
pvc-bundle ny-control 207 class-vc control-class pvc-bundle ny-premium 206 class-vc premium-class pvc-bundle ny-priority 204 class-vc priority-class pvc-bundle ny-basic 201 class-vc basic-class

san-francisco Bundle
The following set of commands create and configure a bundle called san-francisco. At the bundle configuration level, the configuration commands included in the class bundle-class are ascribed to the bundle san-francisco and to the individual VCs that belong to the bundle. Then, the pvc-bundle command is executed for each individual VC to add it to the bundle. After a VC is added and bundle-vc configuration mode is entered, a particular, preconfigured class is assigned to the VC. The configuration commands comprising that class are used to configure the VC. Rules of hierarchy apply at this point. Command parameters contained in the applied class are superseded by the same parameters applied at the bundle configuration level, which are superseded by the same parameters applied directly to a VC.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-368

Configuring IP to ATM Class of Service IP to ATM CoS Configuration Examples

bundle san-francisco protocol clns 49.0000.0000.0000.333.00 broadcast inarp 1 class-bundle bundle-class pvc-bundle sf-control 307 class-vc control-class pvc-bundle sf-premium 306 class-vc premium-class pvc-bundle sf-priority 304 class-vc priority-class pvc-bundle sf-basic 301 class-vc basic-class

los-angeles Bundle
The following set of commands create and configure a bundle called los-angeles. At the bundle configuration level, the configuration commands included in the class bundle-class are ascribed to the bundle los-angeles and to the individual VCs that belong to the bundle. Then, the pvc-bundle command is executed for each individual VC to add it to the bundle. After a VC is added and bundle-vc configuration mode is entered, precedence is set for the VC and the VC is either configured as a member of a protected group (protect group) or as an individually protected VC. A particular class is then assigned to each VC to further characterize it. Rules of hierarchy apply. Parameters of commands applied directly and discretely to a VC take precedence over the same parameters applied within a class to the VC at the bundle-vc configuration level, which take precedence over the same parameters applied to the entire bundle at the bundle configuration level.
bundle los-angeles protocol ip 1.1.1.4 broadcast protocol clns 49.0000.0000.4444.00 broadcast inarp 1 class-bundle bundle-class pvc-bundle la-high 407 precedence 7-5 protect vc class-vc premium-class pvc-bundle la-mid 404 precedence 4-2 protect group class-vc priority-class pvc-bundle la-low 401 precedence other protect group class-vc basic-class

Per-VC WFQ and CBWFQ on a Standalone VC Example

The following example creates two class maps and defines their match criteria. For the first map class, called class1, the numbered access control list (ACL) 101 is used as the match criterion. For the second map class called class2, the numbered ACL 102 is used as the match criterion. Next, the example includes these classes in a policy map called policy1. For class1, the policy includes a minimum bandwidth allocation request of 500 Mbps and maximum packet count limit of 30 for the queue reserved for the class. For class2, the policy specifies only the minimum bandwidth allocation request of 1000 Mbps, so the default queue limit of 64 packets is assumed. Note that the sum of the bandwidth requests for the two classes comprising policy1 is 75 percent of the total amount of bandwidth (2000 Mbps) for the PVC called cisco to which the policy map is attached.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-369

Configuring IP to ATM Class of Service IP to ATM CoS Configuration Examples

The example attaches the policy map called policy1 to the PVC called cisco. Once the policy map policy1 is attached to PVC cisco, its classes constitute the CBWFQ service policy for that PVC. Packets sent on this PVC will be checked for matching criteria against ACLs 101 and 102 and classified accordingly. Because the class-default command is not explicitly configured for this policy map, all traffic that does not meet the match criteria of the two classes comprising the service policy is handled by the predefined class-default class, which provides best-effort flow-based WFQ.
class-map class1 match access-group 101 class-map class2 match access-group 102 policy-map policy1 class class1 bandwidth 500 queue-limit 30 class class2 bandwidth 1000 interface ATM1/1/0.46 multipoint ip address 200.126.186.2 255.255.255.0 pvc cisco 46 vbr-nrt 2000 2000 encap aal5snap service policy output policy1

Per-VC WFQ and CBWFQ on Bundle-Member VCs Example

The following example shows a PVC bundle called san-francisco with members for which per-VC WFQ and CBWFQ are enabled and service policies configured. The example assumes that the classes included in the following policy maps have been defined and that the policy maps have been created: policy1, policy2, and policy4. For each PVC, the IP to ATM CoS pvc-bundle command is used to specify the PVC to which the specified policy map is to be attached. Note that PVC 0/34 and 0/31 have the same policy map attached to them, policy2. Although you can assign the same policy map to multiple VCs, each VC can have only one policy map attached at an output PVC.
bundle san-francisco protocol ip 1.0.2.20 broadcast encapsulation aal5snap pvc-bundle 0/35 service policy output policy1 vbr-nrt 5000 3000 500 precedence 4-7 pvc-bundle 0/34 service policy output policy2 vbr-nrt 5000 3000 500 precedence 2-3 pvc-bundle 0/33 vbr-nrt 4000 3000 500 precedence 2-3 service policy output policy4 pvc-bundle 0/31 service policy output policy2

Cisco IOS Quality of Service Solutions Configuration Guide

QC-370

QoS Features for Voice

Real-time applications such as voice applications have different characteristics and requirements from those of traditional data applications. Because they are real-time-based, voice applications tolerate minimal variation in the amount of delay affecting delivery of their voice packets. Voice traffic is also intolerant of packet loss and jitter, both of which degrade unacceptably the quality of the voice transmission delivered to the recipient end user. To effectively transport voice traffic over IP, mechanisms are required that ensure reliable delivery of packets with low latency. Cisco IOS QoS features collectively embody these techniques, offering the means to provide priority service that meets the stringent requirements of voice packet delivery. This chapter only provides a high-level overview of Cisco IOS QoS features for voice. For complete conceptual and configuration information for each feature, see the referenced chapters or books. For a list of related Cisco IOS voice documentation, see the section For More Information in this chapter.

Cisco IOS QoS for Voice Features

Cisco IOS includes a rich set of features that enable you to deploy mechanisms that deliver QoS throughout your network. Following are some of the Cisco IOS features that address the requirements of end-to-end QoS and service differentiation for voice packet delivery:

Compressed Real-Time Protocol (CRTP)Used in conjunction with RTP, compresses the extensive RTP header, resulting in decreased consumption of available bandwidth for voice traffic. A corresponding reduction in delay is realized. For conceptual information on CRTP, see the chapter Link Efficiency Mechanisms Overview in this book. For information on how to configure CRTP, see the chapter Configuring Compressed Real-Time Protocol in this book. For information on how to configure Distributed CRTP, see the chapter Configuring Distributed Compressed Real-Time Protocol in this book. Frame Relay Traffic Shaping (FRTS)Delays excess traffic using a buffer, or queueing mechanism, to hold packets and shape the flow when the data rate of the source is higher than expected. For conceptual information on FRTS, see the chapter Policing and Shaping Overview in this book. For information on how to configure FRTS, refer to the Cisco IOS Wide-Area Networking Configuration Guide. FRF.12Ensures predictability for voice traffic, aiming to provide better throughput on low-speed Frame Relay links by interleaving delay-sensitive voice traffic on one virtual circuit (VC) with fragments of a long frame on another VC utilizing the same interface. For more information about FRF.12, refer to the Cisco IOS Wide-Area Networking Configuration Guide.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-371

QoS Features for Voice Cisco IOS QoS for Voice Features

PSTN FallbackThe Public Switched Telephone Network (PSTN) Fallback feature provides a mechanism to monitor congestion in the IP network and either redirect calls to the PSTN or reject calls based on the network congestion. For more information about PSTN Fallback, refer to the Cisco IOS Voice, Video, and Fax Configuration Guide. IP RTP Priority and Frame Relay IP RTP PriorityProvides a strict priority queueing scheme that allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued. These features are especially useful on slow-speed WAN links, including Frame Relay, Multilink PPP (MLP), and T1 ATM links. It works with WFQ and CBWFQ. For conceptual information on IP RTP Priority and Frame Relay IP RTP Priority, see the chapter Congestion Management Overview in this book. For information on how to configure IP RTP Priority and Frame Relay IP RTP Priority, see the chapter Configuring Weighted Fair Queueing in this book. IP to ATM Class of Service (CoS)Includes a feature suite that maps QoS characteristics between IP and ATM. Offers differential service classes across the entire WAN, not just the routed portion. Gives mission-critical applications exceptional service during periods of high network usage and congestion. For conceptual information on IP to ATM CoS, see the chapter IP to ATM Class of Service Overview in this book. For information on how to configure IP to ATM CoS, see the chapter Configuring IP to ATM Class of Service in this book. Low latency queueing (LLQ)Provides strict priority queueing on ATM VCs and serial interfaces. This feature allows you to configure the priority status for a class within CBWFQ, and is not limited to User Datagram Protocol (UDP) port numbers, as is IP RTP Priority. For conceptual information on LLQ, see the chapter Congestion Management Overview in this book. For information on how to configure LLQ, see the chapter Configuring Weighted Fair Queueing in this book. MLP with Link Fragmentation and Interleaving (LFI)Allows large packets to be multilink-encapsulated and fragmented so that they are small enough to satisfy the delay requirements of real-time traffic. LFI also provides a special transmit queue for the smaller, delay-sensitive packets, enabling them to be sent earlier than other flows. For conceptual information on MLP with LFI, see the chapter Link Efficiency Mechanisms Overview in this book. For information on how to configure MLP with LFI, see the chapter Configuring Link Fragmentation and Interleaving for Multilink PPP in this book. For information on how to configure LFI for Frame Relay and ATM virtual circuits, see the chapter Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuitsin this book. QoS Policy Propagation via Border Gateway Protocol (BGP)Leverages BGP to distribute QoS policy to remote routers in your network. It allows you to classify packets and then use other QoS features such as CAR and Weighted Random Early Detection (WRED) to specify and enforce business policies to fit your business model. For conceptual information on Policy Propagation via BGP, see the chapter Classification Overview in this book. For information on how to configure Policy Propagation via BGP, see the chapter Configuring QoS Policy Propagation via Border Gateway Protocol in this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-372

QoS Features for Voice Cisco IOS QoS for Voice Features

Resource Reservation Protocol (RSVP)Supports the reservation of resources across an IP network, allowing end systems to request QoS guarantees from the network. For networks supporting Voice over IP (VoIP), RSVPin conjunction with features that provide queueing, traffic shaping, and voice call signallingcan provide call admission control for voice traffic. Cisco also provides RSVP support for LLQ and Frame Relay. For conceptual information on RSVP, see the chapter Signalling Overview in this book. For information on how to configure RSVP, see the chapter Configuring RSVP in this book. For information on how to configure RSVP support for LLQ, see the chapter Configuring RSVP Support for LLQ in this book. For information on how to configure RSVP support for Frame Relay, see the chapter Configuring RSVP Support for Frame Relay in this book.

Cisco IOS QoS for voice features are best deployed at different points in the network and are designed to be used in conjunction with other QoS features to achieve specific goals such as control over jitter and delay. Not all QoS for voice features are supported on all platforms.

For More Information

For additional information about Cisco IOS QoS for voice, refer to the following publications:

Cisco IOS Voice, Video, and Fax Configuration GuideThis guide shows you how to configure your Cisco router or access server to support voice, video, and broadband transmission. Cisco IOS Voice, Video, and Fax Command ReferenceThis publication documents commands used to configure your Cisco router or access server to support voice, video, and broadband transmission.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-373

QoS Features for Voice Cisco IOS QoS for Voice Features

Cisco IOS Quality of Service Solutions Configuration Guide

QC-374

Implementing DiffServ for End-to-End Quality of Service Overview

About Differentiated Services
Differentiated Services (DiffServ) describes a set of end-to-end QoS capabilities. End-to-end QoS is the ability of the network to deliver service required by specific network traffic from one end of the network to another. Cisco IOS QoS software supports three types of service models: best-effort services, Integrated Services (IntServ), and Differentiated Services. For more information about the best-effort services and IntServ, see the chapter Quality of Service Overview in this book. Differentiated Services is a multiple service model that can satisfy differing QoS requirements. With Differentiated Services, the network tries to deliver a particular kind of service based on the QoS specified by each packet. This specification can occur in different ways, for example, using the 6-bit differentiated services code point (DSCP) setting in IP packets or source and destination addresses. The network uses the QoS specification to classify, mark, shape, and police traffic, and to perform intelligent queueing. Differentiated Services is used for several mission-critical applications and for providing end-to-end QoS. Typically, Differentiated Services is appropriate for aggregate flows because it performs a relatively coarse level of traffic classification. Cisco IOS QoS includes the following features that support Differentiated Services:

Committed access rate (CAR), which performs packet classification through IP Precedence and QoS group settings. CAR performs metering and class-based policing of traffic, providing bandwidth management. Intelligent queueing schemes such as Weighted Random Early Detection (WRED) and weighted fair queueing (WFQ) and their equivalent features on the Versatile Interface Processor (VIP), which are VIP-distributed WRED (DWRED) and VIP-distributed WFQ. These features can be used with CAR for implementing Differentiated Services. Modular QoS Command-Line Interface (Modular QoS CLI), which provides a command-line interface (CLI) used to configure class-based QoS features. Low latency queueing (LLQ), which brings strict priority queueing (PQ) to class-based WFQ (CBWFQ). Strict PQ allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-375

Implementing DiffServ for End-to-End Quality of Service Overview About Differentiated Services

Generic Traffic Shaping (GTS) shapes traffic by reducing outbound traffic flow to avoid congestion by constraining traffic to a particular bit rate using the token bucket mechanism. GTS applies on a per-interface basis and can use access lists to select the traffic to shape. Class-Based Shaping configures GTS on a traffic class, specify average rate or peak rate traffic shaping, and configure CBWFQ inside GTS.

For more information about Cisco IOS QoS features, see the chapter Quality of Service Overview in this book. This feature supports the Differentiated Services, Assured Forwarding, and Expedited Forwarding standards. It also supports the following RFCs:

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 2475, An Architecture for Differentiated Services Framework RFC 2597, Assured Forwarding PHB RFC 2598, An Expedited Forwarding PHB RFC 2697, A Single Rate Three Color Marker

For more information about the specific components and features related to DiffServ, see the sections Differentiated Services Components and Feature Sets sections later in this chapter.

DS Field Definition
A replacement header field, called the DS field, is defined by Differentiated Services. The DS field supersedes the existing definitions of the IP version 4 (IPv4) type of service (ToS) octet (RFC 791) and the IPv6 traffic class octet. Six bits of the DS field are used as the DSCP to select the Per Hop Behavior (PHB) at each interface. A currently unused (CU) 2-bit field is reserved for explicit congestion notification (ECN). The value of the CU bits is ignored by DS-compliant interfaces when determining the PHB to apply to a received packet.

Per-Hop Behaviors
RFC 2475 defines PHB as the externally observable forwarding behavior applied at a DiffServ-compliant node to a DiffServ Behavior Aggregate (BA). With the ability of the system to mark packets according to DSCP setting, collections of packets with the same DSCP setting and sent in a particular direction can be grouped into a BA. Packets from multiple sources or applications can belong to the same BA. In other words, a PHB refers to the packet scheduling, queueing, policing, or shaping behavior of a node on any given packet belonging to a BA, as configured by a service level agreement (SLA) or a policy map. The following sections describe the four available standard PHBs:

Default PHB (as defined in RFC 2474) Class-Selector PHB (as defined in RFC 2474) Assured Forwarding (AFny) PHB (as defined in RFC 2597) Expedited Forwarding (EF) PHB (as defined in RFC 2598)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-376

Implementing DiffServ for End-to-End Quality of Service Overview About Differentiated Services

Default PHB
The default PHB essentially specifies that a packet marked with a DSCP value of 000000 (recommended) receives the traditional best-effort service from a DS-compliant node (that is, a network node that complies with all of the core DiffServ requirements). Also, if a packet arrives at a DS-compliant node, and the DSCP value is not mapped to any other PHB, the packet will get mapped to the default PHB. For more information about default PHB, refer to RFC 2474, Definition of the Differentiated Services Field in IPv4 and IPv6 Headers.

Class-Selector PHB
To preserve backward-compatibility with any IP precedence scheme currently in use on the network, DiffServ has defined a DSCP value in the form xxx000, where x is either 0 or 1. These DSCP values are called Class-Selector Code Points. (The DSCP value for a packet with default PHB 000000 is also called the Class-Selector Code Point.) The PHB associated with a Class-Selector Code Point is a Class-Selector PHB. These Class-Selector PHBs retain most of the forwarding behavior as nodes that implement IP Precedence-based classification and forwarding. For example, packets with a DSCP value of 11000 (the equivalent of the IP Precedence-based value of 110) have preferential forwarding treatment (for scheduling, queueing, and so on), as compared to packets with a DSCP value of 100000 (the equivalent of the IP Precedence-based value of 100). These Class-Selector PHBs ensure that DS-compliant nodes can coexist with IP Precedence-based nodes. For more information about Class-Selector PHB, refer to RFC 2474, Definition of the Differentiated Services Field in IPv4 and IPv6 Headers.

Assured Forwarding PHB

Assured Forwarding (AF) PHB is nearly equivalent to Controlled Load Service available in the integrated services model. AFny PHB defines a method by which BAs can be given different forwarding assurances. For example, network traffic can be divided into the following classes:

Gold: Traffic in this category is allocated 50 percent of the available bandwidth. Silver: Traffic in this category is allocated 30 percent of the available bandwidth. Bronze: Traffic in this category is allocated 20 percent of the available bandwidth.

Further, the AFny PHB defines four AF classes: AF1, AF2, AF3, and AF4. Each class is assigned a specific amount of buffer space and interface bandwidth, according to the SLA with the service provider or policy map. Within each AF class, you can specify three drop precedence (dP) values: 1, 2, and 3. Assured Forwarding PHB can be expressed as follows: AFny In this example, n represents the AF class number (1, 2, or 3) and y represents the dP value (1, 2, or 3) within the AFn class. In instances of network traffic congestion, if packets in a particular AF class (for example, AF1) need to be dropped, packets in the AF1 class will be dropped according to the following guideline: dP(AFny) >= dP(AFnz) >= dP(AFnx)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-377

Implementing DiffServ for End-to-End Quality of Service Overview About Differentiated Services

where dP (AFny) is the probability that packets of the AFny class will be dropped. In other words, y denotes the dP within an AFn class. In the following example, packets in the AF13 class will be dropped before packets in the AF12 class, which in turn will be dropped before packets in the AF11 class: dP(AF13) >= dP (AF12) >= dP(AF11) The dP method penalizes traffic flows within a particular BA that exceed the assigned bandwidth. Packets on these offending flows could be re-marked by a policer to a higher drop precedence. An AFx class can be denoted by the DSCP value, xyzab0, where xyz can be 001, 010, 011, or 100, and ab represents the dP value. Table 15 lists the DSCP value and corresponding dP value for each AF PHB class.
Table 15 DSCP Values and Corresponding Drop Precedence Values for Each AF PHB Class

Drop Precedence
Low drop precedence Medium drop precedence High drop precedence

Class 1 001010 001100 001110

Class 2 010010 010100 010110

Class 3 011010 011100 011110

Class 4 100010 100100 100110

Expedited Forwarding PHB

Resource Reservation Protocol (RSVP), a component of the integrated services model, provides a Guaranteed Bandwidth Service. Applications such as Voice over IP (VoIP), video, and online trading programs require this kind of robust service. The EF PHB, a key ingredient of DiffServ, supplies this kind of robust service by providing low loss, low latency, low jitter, and assured bandwidth service. EF can be implemented using PQ, along with rate-limiting on the class (or BA). When implemented in a DiffServ network, EF PHB provides a virtual leased line, or premium service. For optimal efficiency, however, EF PHB should be reserved for only the most critical applications because, in instances of traffic congestion, it is not feasible to treat all or most traffic as high priority. EF PHB is ideally suited for applications such as VoIP that require low bandwidth, guaranteed bandwidth, low delay, and low jitter. The recommended DSCP value for EF PHB is 101110. For more information about EF PHB, refer to RFC 2598, An Expedited Forwarding PHB.

Benefits
Use the Implementing DiffServ for End-to-End Quality of Service feature set to implement the Differentiated Services architecture. The benefits of implementing Differentiated Services include the following:

Reduces the burden on network devices and easily scales as the network grows Allows customers to keep any existing Layer 3 ToS prioritization scheme that may be in use Allows customers to mix DiffServ-compliant devices with any existing ToS-enabled equipment in use Alleviates bottlenecks through efficient management of current corporate network resources

Cisco IOS Quality of Service Solutions Configuration Guide

QC-378

Implementing DiffServ for End-to-End Quality of Service Overview Differentiated Services Components

Differentiated Services Components

The following components make up the foundation of a Cisco Differentiated Services implementation:

Traffic conditioning (traffic policing and traffic shaping). Traffic conditioning is performed at the edges of a DiffServ domain. Traffic conditioners perform traffic shaping and policing functions to ensure that traffic entering the DiffServ domain conforms to the rules specified by the Traffic Conditioning Agreement (TCA), and comply with the service provisioning policy of the domain. Traffic conditioning may range from simple code point re-marking to complex policing and shaping operations. Packet classification. Packet classification uses a traffic descriptor (for example, the DSCP) to categorize a packet within a specific group in order to define that packet. After the packet has been defined (that is, classified), the packet is then accessible for QoS handling on the network. Using packet classification, you can partition network traffic into multiple priority levels or classes of service. When traffic descriptors are used to classify traffic, the source agrees to adhere to the contracted terms and the network promises a QoS. Traffic policers and traffic shapers use the traffic descriptor of the packet (that is, the classification of the packet) to ensure adherence to that agreement.

Packet marking. Packet marking is related to packet classification. Packet marking allows you to classify a packet based on a specific traffic descriptor (such as the DSCP value). This classification can then be used to apply user-defined differentiated services to the packet and to associate a packet with a local QoS group. Associating a packet with a local QoS group allows users to associate a group ID with a packet. The group ID can be used to classify packets into QoS groups based on prefix, autonomous system, and community string. A user can set up to 64 DSCP values and 100 QoS group markings.

Congestion management. Congestion management (or scheduling) is achieved through traffic scheduling and traffic queueing. When there is network congestion, a scheduling mechanism such as CBWFQ is used to provide guaranteed bandwidth to the different classes of traffic. Congestion avoidance. Congestion avoidance techniques monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottlenecks. Congestion avoidance is achieved through packet dropping. Among the more commonly used congestion avoidance mechanisms is WRED. With WRED and Differentiated Services, you have the option of allowing WRED to use the DSCP value when WRED calculates the drop probability of a packet.

Feature Sets
This section lists the feature sets that correspond to the Differentiated Services components listed earlier. These feature sets provide the necessary functionality that allows you to implement Differentiated Services. This feature set includes the following features:

Modular QoS CLIThis feature provides a CLI structure that is used to configure class-based QoS features. Class-Based Packet MarkingThis feature provides a user-friendly CLI for efficient packet marking by which users can differentiate packets by designating them different identifying values. For example, this feature allows you to mark packets by setting the IP Precedence bits or the IP DSCP in the ToS byte.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-379

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

Traffic PolicingThis feature allows you to limit the input or output transmission rate of a class of traffic based on user-defined criteria. It also enables the system to mark packets by setting the IP Precedence value, the QoS group, or the DSCP value. Class-Based ShapingThis feature allows you to configure Generic Traffic Shaping (GTS) on a traffic class, specify average rate or peak rate traffic shaping, and configure CBWFQ inside GTS. CBWFQThis feature is a scheduling mechanism used to provide a minimum bandwidth guarantee to traffic classes during times of network congestion at an interface. DiffServ Compliant WREDThis feature provides support for the DiffServ standard. It enables WRED to use either the DSCP or the IP Precedence value when calculating the drop probability for a packet. This feature should be used in conjunction with CBWFQ. Enhanced show policy-map interface Command Enhancements for Class-Based AccountingThe show policy-map interface command now displays information such as the incoming traffic rate, the dropped packet rate, the number of matched packets, and the number of matched bytes for traffic classes that are attached to the specified interface. This feature collects and displays common statistics that are used for billing and accounting purposes. For more information, see the release notes for Cisco IOS Release 12.1(5)T. Multiprotocol Label Switching (MPLS) Class of Service (CoS) EnhancementsThis feature allows the service provider to set the MPLS experimental field instead of overwriting the value in the customer IP Precedence field (the first three bits of the DSCP field in the header of an IP packet). For more information about MPLS Class of Service (CoS), refer to the Cisco IOS Switching Services Configuration Guide.

Constructing Services Using DiffServ

The following section provides a sample DiffServ implementation. It includes sample configurations and troubleshooting logs, which can be used for monitoring system performance.

Sample DiffServ Implementation

Figure 32 shows a sample DiffServ implementation with three routers: remote router 1, central router, and remote router 2.
Figure 32 Sample Network Implementing DiffServ

Remote router 1 Internet fe0/0 s0/0 s4/1

Central router ss4/0 s0/0

Remote router 2 s0/1

47181

Internet

In this example, we want to give end-to-end QoS to several different types of traffic classes using the Cisco IOS Differentiated Services feature set. Traffic classes along with the SLAs for each traffic class in use on the sample DiffServ implementation are described as follows:

Cisco IOS Quality of Service Solutions Configuration Guide

QC-380

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

Voice is considered premium class. The gold class of traffic consists of TACACS sessions, along with traffic marked with DSCP values 12 and 14. The silver traffic class consists of Telnet, Simple Main Transfer Protocol (SMTP), and FTP sessions. The bronze traffic class consists of web traffic and traffic marked with DSCP values 28 and 30. Anything else is considered as belonging to best-effort traffic class. The premium class should be forwarded with the lowest delay possible up to a maximum of 500 kBps during periods of congestion. The gold class should be treated preferentially over the silver class, which in turn should be treated preferentially over the bronze class. The gold, silver, and bronze classes should have 35 percent, 25 percent, and 15 percent, respectively, of the interface bandwidth as the minimum bandwidth guarantees. The bronze class should be shaped to 320 kBps, and the best-effort class should be policed to 56 kBps. To provision for the various traffic classes, the traffic needs to be classified based on DSCP values in a DiffServ domain. So that traffic can be classified based on DSCP values, the traffic should be premarked with the appropriate DSCP values at the time of entering the network. In Figure 32, the correct place to do this kind of traffic marking is in the incoming direction of Fast Ethernet interface 0/0 of remote router 1 and the incoming direction of serial interface 0/1 of remote router 2. This marking can be achieved through an input service policy.

Table 16 lists the DSCP values used to mark different classes of traffic entering into the sample network.
Table 16 DSCP Values for Traffic Classes and Traffic Types

Traffic Class Premium Gold Silver

Traffic Type Voice TACACS Telnet SMTP FTP

DSCP Value 46 10 18 20 22 26

Bronze

HTTP

To achieve the marking scheme noted in Table 16, use the following configuration for the policy map called SETDSCP in the input direction of Fast Ethernet interface 0/0 of remote router 1:
class-map match-all EF match access-group 101 class-map match-all AF1 match access-group 102 class-map match-all match access-group class-map match-all match access-group class-map match-all match access-group AF21 108 AF22 109 AF23 110

class-map match-all AF3 match access-group 104 policy-map SETDSCP class EF set ip dscp 46 class AF1 set ip dscp 10

Cisco IOS Quality of Service Solutions Configuration Guide

QC-381

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

class AF21 set ip dscp class AF22 set ip dscp class AF23 set ip dscp class AF3 set ip dscp

18 20 22 26

Once the traffic classes are marked with the appropriate DSCP values using the SETDSCP policy map, the different behavior aggregate requirements for each of the traffic classes can be met by using the configuration for the following policy map called VOIP in the output direction:
class-map match-all premium match ip dscp 46 class-map match-all gold match ip dscp 10 12 14 class-map match-all silver match ip dscp 18 20 22 class-map match-all bronze match ip dscp 26 28 30 class-map best-effort match access-group 105 policy-map VOIP class premium priority 500 class gold bandwidth percent 35 class silver shape average 320000 bandwidth percent 25 class bronze bandwidth percent 15 class best-effort police 56000 1750 1750 conform-action set-dscp-transmit 0

Sample Configurations
This section contains the configurations for each of the routers shown in Figure 32. The examples demonstrate how marking, shaping, policing, and monitoring is done through the Modular QoS CLI.
Remote Router 1 Configuration
Current configuration: Remote1# show running-config Building configuration... ! version 12.1 no service single-slot-reload-enable service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Remote1 ! logging rate-limit console 10 except errors no logging console

Cisco IOS Quality of Service Solutions Configuration Guide

QC-382

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

! ip subnet-zero ! ip dhcp smart-relay ! ip cef ! class-map match-all gold match ip dscp 10 12 14 class-map match-all EF match access-group 101 class-map match-all AF21 match access-group 108 class-map match-all AF23 match access-group 110 class-map match-all AF22 match access-group 109 class-map match-all bronze match ip dscp 26 28 30 class-map match-all platinum match ip dscp 46 class-map match-all silver match ip dscp 18 20 22 class-map match-all best-effort match access-group 105 class-map match-all AF3 match access-group 104 class-map match-all AF1 match access-group 102 ! policy-map VOIP class platinum priority 500 class gold bandwidth percent 50 class bronze shape average 320000 bandwidth percent 15 class silver bandwidth percent 35 class best-effort police 56000 1750 1750 conform-action set-dscp-transmit 0 exceed-action drop violate-action drop policy-map SETDSCP class EF set ip dscp 46 class AF1 set ip dscp 10 class AF3 set ip dscp 26 class AF21 set ip dscp 18 class AF22 set ip dscp 20 class AF23 set ip dscp 22 ! call rsvp-sync cns event-service server ! interface FastEthernet0/0 ip address 4.1.1.1 255.255.255.0 load-interval 60 speed auto

Cisco IOS Quality of Service Solutions Configuration Guide

QC-383

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

half-duplex service-policy input SETDSCP ! interface Serial0/0 bandwidth 2000 ip address 2.1.1.1 255.255.255.0 load-interval 60 service-policy output VOIP ! interface Serial0/1 no ip address shutdown ! ip classless ip route 1.1.1.0 255.255.255.0 2.1.1.2 ip route 3.1.1.0 255.255.255.0 2.1.1.2 ! access-list 101 permit udp any any range 16384 32768 access-list 102 permit tcp any any eq tacacs access-list 104 permit tcp any any eq www access-list 105 permit ip any any access-list 108 permit tcp any any eq telnet access-list 109 permit tcp any any eq smtp access-list 110 permit tcp any any eq ftp ! voice-port 1/0/0 ! voice-port 1/0/1 ! dial-peer cor custom ! dial-peer voice 11 pots destination-pattern 2220 port 1/0/0 ! dial-peer voice 1 voip destination-pattern 1110 session target ipv4:1.1.1.2 ip precedence 5 ! line con 0 transport input none line aux 0 line vty 0 4 login ! no scheduler allocate end

Central Router Configuration

Current configuration: Central# show running-config Building configuration... Current configuration: ! version 12.1 no service single-slot-reload-enable service timestamps debug uptime service timestamps log uptime no service password-encryption

Cisco IOS Quality of Service Solutions Configuration Guide

QC-384

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

! hostname Central ! logging rate-limit console 10 except errors no logging console ip dhcp smart-relay ! ip cef ! class-map match-all gold match ip dscp 10 12 14 class-map match-all bronze match ip dscp 26 28 30 class-map match-all platinum match ip dscp 46 class-map match-all silver match ip dscp 18 20 22 class-map match-all best-effort match ip dscp 0 ! policy-map AVVID class silver bandwidth percent 35 random-detect dscp-based random-detect dscp 18 20 40 random-detect dscp 20 20 40 random-detect dscp 22 2 3 class gold bandwidth percent 50 random-detect dscp-based random-detect dscp 10 20 40 random-detect dscp 12 20 40 random-detect dscp 14 20 40 class bronze bandwidth percent 15 random-detect dscp-based random-detect dscp 26 20 40 random-detect dscp 28 20 40 random-detect dscp 30 20 40 class platinum priority 500 ! cns event-service server ! interface Serial4/0 bandwidth 2000 ip address 3.1.1.1 255.255.255.0 no ip mroute-cache load-interval 60 service-policy output AVVID ! interface Serial4/1 ip address 2.1.1.2 255.255.255.0 no ip mroute-cache service-policy output AVVID clockrate 2015232 ! interface Serial4/2 no ip address no ip mroute-cache shutdown ! interface Serial4/3

10 30 3

10 15 20

10 20 30

Cisco IOS Quality of Service Solutions Configuration Guide

QC-385

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

no ip address no ip mroute-cache shutdown ! ip classless ip route 0.0.0.0 0.0.0.0 10.0.153.1 ip route 1.1.1.0 255.255.255.0 3.1.1.2 ip route 4.1.1.0 255.255.255.0 2.1.1.1 ip http server ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 line vty 5 15 end

Remote Router 2 Configuration

Current configuration: Remote2# show running-config Building configuration... Current configuration: ! version 12.1 no service single-slot-reload-enable service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Remote2 ! logging rate-limit console 10 except errors no logging console ! ip dhcp smart-relay ! ip cef ! class-map match-all gold match ip dscp 10 12 14 class-map match-all EF match access-group 101 class-map match-all AF21 match access-group 108 class-map match-all AF23 match access-group 110 class-map match-all AF22 match access-group 109 class-map match-all bronze match ip dscp 26 28 30 class-map match-all platinum match ip dscp 46 class-map match-all silver match ip dscp 18 20 22 class-map match-all best-effort match access-group 105 class-map match-all AF3 match access-group 104

Cisco IOS Quality of Service Solutions Configuration Guide

QC-386

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

class-map match-all AF1 match access-group 102 ! ! policy-map VOIP class platinum priority 500 class gold bandwidth percent 50 class bronze shape average 320000 bandwidth percent 15 class silver bandwidth percent 35 class best-effort police 56000 1750 1750 conform-action set-dscp-transmit 0 exceed-action drop violate-action drop policy-map SETDSCP class EF set ip dscp 46 class AF1 set ip dscp 10 class AF3 set ip dscp 26 class AF21 set ip dscp 18 class AF22 set ip dscp 20 class AF23 set ip dscp 22 ! interface Serial0/0 bandwidth 2000 ip address 3.1.1.2 255.255.255.0 load-interval 60 service-policy output VOIP clockrate 2000000 ! interface Serial0/1 ip address 1.1.1.1 255.255.255.0 load-interval 60 no keepalive service-policy input SETDSCP clockrate 2000000 ! ip kerberos source-interface any ip classless ip route 2.1.1.0 255.255.255.0 3.1.1.1 ip route 4.1.1.0 255.255.255.0 3.1.1.1 no ip http server ! access-list 101 permit udp any any range 16384 32768 access-list 102 permit tcp any any eq tacacs access-list 104 permit tcp any any eq www access-list 105 permit ip any any access-list 108 permit tcp any any eq telnet access-list 109 permit tcp any any eq smtp access-list 110 permit tcp any any eq ftp ! voice-port 1/0/0 ! voice-port 1/0/1 !

Cisco IOS Quality of Service Solutions Configuration Guide

QC-387

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

dial-peer cor custom ! dial-peer voice 1 voip destination-pattern 2220 session target ipv4:2.1.1.1 ip precedence 5 ! dial-peer voice 11 pots destination-pattern 1110 port 1/0/0 ! ! line con 0 transport input none line aux 0 line vty 0 4 login ! no scheduler allocate end

Troubleshooting Logs
This section contains sample troubleshooting logs for remote router 1 and the central router. These logs can be used for monitoring and maintaining the DiffServ implementation.
Remote Router 1
Remote1# show policy-map SETDSCP Policy Map SETDSCP Class EF set ip dscp 46 Class AF1 set ip dscp 10 Class AF3 set ip dscp 26 Class AF21 set ip dscp 18 Class AF22 set ip dscp 20 Class AF23 set ip dscp 22 Remote1# show policy-map VOIP Policy Map VOIP Class platinum Weighted Fair Queueing Strict Priority Bandwidth 500 (kbps) Burst 12500 (Bytes) Class gold Weighted Fair Queueing Bandwidth 50 (%) Max Threshold 64 (packets) Class bronze Traffic Shaping Average Rate Traffic Shaping CIR 320000 (bps) Max. Buffers Limit 1000 (Packets) Weighted Fair Queueing Bandwidth 15 (%) Max Threshold 64 (packets) Class silver

Cisco IOS Quality of Service Solutions Configuration Guide

QC-388

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

Weighted Fair Queueing Bandwidth 35 (%) Max Threshold 64 (packets) Class best-effort police 56000 1750 1750 conform-action set-dscp-transmit 0 exceed-action drop violate-action drop Remote1# show policy-map interface f0/0 FastEthernet0/0 Service-policy input: SETDSCP (1611) Class-map: EF (match-all) (1612/3) 2154221 packets, 176646532 bytes 1 minute offered rate 642000 bps, drop rate 0 bps Match: access-group 101 (1614) QoS Set ip dscp 46 Packets marked 2154256 Class-map: AF1 (match-all) (1616/12) 46351 packets, 69711904 bytes 1 minute offered rate 254000 bps, drop rate 0 bps Match: access-group 102 (1618) QoS Set ip dscp 10 Packets marked 46352 Class-map: AF3 (match-all) (1620/11) 81757 packets, 122962528 bytes 1 minute offered rate 483000 bps, drop rate 0 bps Match: access-group 104 (1622) QoS Set ip dscp 26 Packets marked 81951 Class-map: AF21 (match-all) (1624/4) 84585 packets, 127215840 bytes 1 minute offered rate 484000 bps, drop rate 0 bps Match: access-group 108 (1626) QoS Set ip dscp 18 Packets marked 84780 Class-map: AF22 (match-all) (1628/6) 75440 packets, 113461760 bytes 1 minute offered rate 423000 bps, drop rate 0 bps Match: access-group 109 (1630) QoS Set ip dscp 20 Packets marked 75612 Class-map: AF23 (match-all) (1632/5) 66212 packets, 99582848 bytes 1 minute offered rate 362000 bps, drop rate 0 bps Match: access-group 110 (1634) QoS Set ip dscp 22 Packets marked 66428 Class-map: class-default (match-any) (1636/0) 2555349 packets, 778812687 bytes 1 minute offered rate 2896000 bps, drop rate 0 bps Match: any (1638)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-389

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

2555358 packets, 778810855 bytes 1 minute rate 2896000 bps Remote1# show policy-map interface s0/0 Serial0/0 Service-policy output: VOIP (1558) Class-map: platinum (match-all) (1559/8) 2988402 packets, 215165016 bytes 1 minute offered rate 564000 bps, drop rate 0 bps Match: ip dscp 46 (1561) Weighted Fair Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 500 (kbps) (pkts matched/bytes matched) 2988422/215166384 (total drops/bytes drops) 330478/23794416 Class-map: gold (match-all) (1563/2) 64300 packets, 96064200 bytes 1 minute offered rate 252000 bps, drop rate 0 bps Match: ip dscp 10 12 14 (1565) Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 50 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 64300/96064200 (depth/total drops/no-buffer drops) 0/0/0 Class-map: bronze (match-all) (1567/7) 115945 packets, 173221830 bytes 1 minute offered rate 479000 bps, drop Match: ip dscp 26 28 30 (1569) Traffic Shaping Target Byte Sustain Excess Rate Limit bits/int bits/int 320000 2000 8000 8000

rate 56000 bps

Interval (ms) 25

Increment Adapt (bytes) Active 1000 -

Queue Packets Bytes Packets Bytes Depth Delayed Delayed Active 64 80006 119528964 72784 108739296 yes Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 15 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 80006/119528964 (depth/total drops/no-buffer drops) 0/12749/0 Class-map: silver (match-all) (1572/9) 315979 packets, 472072626 bytes 1 minute offered rate 1258000 bps, drop rate 646000 bps Match: ip dscp 18 20 22 (1574) Weighted Fair Queueing Output Queue: Conversation 267 Bandwidth 35 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 316253/472481982 (depth/total drops/no-buffer drops) 0/158914/0 Class-map: best-effort (match-all) (1576/10) 3548921 packets, 1051813080 bytes 1 minute offered rate 2801000 bps, drop rate 0 bps Match: access-group 105 (1578) police: 56000 bps, 1750 limit, 1750 extended limit

Cisco IOS Quality of Service Solutions Configuration Guide

QC-390

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

conformed 0 packets, 0 bytes; action: set-dscp-transmit 0 exceeded 0 packets, 0 bytes; action: drop violated 0 packets, 0 bytes; action: drop Class-map: class-default (match-any) (1580/0) 3549281 packets, 1051837716 bytes 1 minute offered rate 2801000 bps, drop rate 0 bps Match: any (1582) 3549281 packets, 1051837644 bytes 1 minute rate 2801000 bps Remote1# show queue serial 0/0 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 631823 Queueing strategy: weighted fair Output queue: 101/1000/64/593935 (size/max total/threshold/drops) Conversations 4/7/256 (active/max active/max total) Reserved Conversations 3/3 (allocated/max allocated) Available Bandwidth 1000 kilobits/sec (depth/weight/total drops/no-buffer drops/interleaves) 5/0/346494/0/0 Conversation 264, linktype: ip, length: 72 source: 0.0.0.0, destination: 1.1.1.2, id: 0x0000, ttl: 59, TOS: 184 prot: 17, source port 0, destination port 16384 (depth/weight/total drops/no-buffer drops/interleaves) 63/45/166791/0/0 Conversation 267, linktype: ip, length: 1494 source: 0.0.0.0, destination: 1.1.1.2, id: 0x0000, ttl: 59, TOS: 72 prot: 6, source port 0, destination port 23 (depth/weight/total drops/no-buffer drops/interleaves) 35/104/13461/0/0 Conversation 266, linktype: ip, length: 1494 source: 0.0.0.0, destination: 1.1.1.2, id: 0x0000, ttl: 59, TOS: 104 prot: 6, source port 0, destination port 80 (depth/weight/total drops/no-buffer drops/interleaves) 1/32384/67216/0/0 Conversation 89, linktype: ip, length: 1482 source: 0.0.0.0, destination: 1.1.1.2, id: 0x0000, ttl: 59, TOS: 0 prot: 17, source port 0, destination port 67 Remote1# show interface serial 0/0 Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Internet address is 2.1.1.1/24 MTU 1500 bytes, BW 2000 Kbit, DLY 20000 usec, reliability 255/255, txload 207/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:03, output 00:00:00, output hang never Last clearing of "show interface" counters 00:50:30 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 595699 Queueing strategy: weighted fair Output queue: 114/1000/64/560199 (size/max total/threshold/drops) Conversations 4/7/256 (active/max active/max total) Reserved Conversations 3/3 (allocated/max allocated) Available Bandwidth 1000 kilobits/sec 1 minute input rate 0 bits/sec, 0 packets/sec

Cisco IOS Quality of Service Solutions Configuration Guide

QC-391

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

1 minute output rate 1624000 bits/sec, 962 packets/sec 354 packets input, 22827 bytes, 0 no buffer Received 354 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 2918044 packets output, 616834104 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

Central Router
Central# show policy-map interface serial 4/0 Serial4/0 Service-policy output: AVVID (2022) Class-map: silver (match-all) (2023/2) 251162 packets, 375236028 bytes 1 minute offered rate 612000 bps, drop rate 0 bps Match: ip dscp 18 20 22 (2025) Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 25 (%) (pkts matched/bytes matched) 3/4482 (depth/total drops/no-buffer drops) 0/0/0 mean queue depth: 0 Dscp (Prec) 0(0) 1 2 3 4 Random drop pkts/bytes 0/0 0/0 0/0 0/0 0/0 Tail drop pkts/bytes 0/0 0/0 0/0 0/0 0/0 Minimum Maximum Mark threshold threshold probability 20 40 1/10 22 40 1/10 24 40 1/10 26 40 1/10 28 40 1/10

(...up to DSCP 63......) 61 62 63 rsvp 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 30 32 34 36 40 40 40 40 1/10 1/10 1/10 1/10

Class-map: gold (match-all) (2027/3) 102479 packets, 153103626 bytes 1 minute offered rate 250000 bps, drop rate 0 bps Match: ip dscp 10 12 14 (2029) Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 35 (%) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 mean queue depth: 0 Dscp (Prec) 0(0) 1 2 3 Random drop pkts/bytes 0/0 0/0 0/0 0/0 Tail drop pkts/bytes 0/0 0/0 0/0 0/0 Minimum Maximum Mark threshold threshold probability 20 40 1/10 22 40 1/10 24 40 1/10 26 40 1/10

...up to DSCP 63......)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-392

Implementing DiffServ for End-to-End Quality of Service Overview Constructing Services Using DiffServ

61 62 63 rsvp

0/0 0/0 0/0 0/0

0/0 0/0 0/0 0/0

30 32 34 36

40 40 40 40

1/10 1/10 1/10 1/10

Class-map: bronze (match-all) (2031/4) 106605 packets, 159267870 bytes 1 minute offered rate 262000 bps, drop rate 0 bps Match: ip dscp 26 28 30 (2033) Weighted Fair Queueing Output Queue: Conversation 267 Bandwidth 15 (%) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 mean queue depth: 0 Dscp (Prec) 0(0) 1 2 3 4 5 6 Random drop pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 Tail drop pkts/bytes 0/0 0/0 0/0 0/0 0/0 0/0 0/0 Minimum Maximum Mark threshold threshold probability 20 40 1/10 22 40 1/10 24 40 1/10 26 40 1/10 28 40 1/10 30 40 1/10 32 40 1/10

(...up to DSCP 63......) 61 62 63 rsvp 0/0 0/0 0/0 0/0 0/0 0/0 0/0 0/0 30 32 34 36 40 40 40 40 1/10 1/10 1/10 1/10

Class-map: platinum (match-all) (2035/5) 4253851 packets, 306277272 bytes 1 minute offered rate 499000 bps, drop rate 0 bps Match: ip dscp 46 (2037) Weighted Fair Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 500 (kbps) (pkts matched/bytes matched) 4248148/305866656 (total drops/bytes drops) 5/360 Class-map: class-default (match-any) (2039/0) 4719109 packets, 1000522466 bytes 1 minute offered rate 1625000 bps, drop rate 0 bps Match: any (2041) 4719109 packets, 1000522466 bytes 1 minute rate 1625000 bps Central# show queue serial 4/0 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 5 Queueing strategy: weighted fair Output queue: 0/1000/64/5 (size/max total/threshold/drops) Conversations 0/2/256 (active/max active/max total) Reserved Conversations 3/3 (allocated/max allocated) Available Bandwidth 1000 kilobits/sec

Cisco IOS Quality of Service Solutions Configuration Guide

QC-393

Implementing DiffServ for End-to-End Quality of Service Overview Class-Based Management

Central# show queue serial 4/1 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/256 (active/max active/max total) Reserved Conversations 3/3 (allocated/max allocated) Available Bandwidth 1011 kilobits/sec

Class-Based Management
The accounting functionality of DiffServ allows you to collect and display service policy statistics on a per-class basis. The show policy-map interface command has been enhanced to include additional information related to traffic classes on a particular interface. The show policy-map interface command now displays information including the incoming traffic rate, the dropped packet rate, the number of matched packets, and the number of matched bytes, for traffic classes that are attached to the specified interface. These details can be used for billing and accounting purposes, and for managing projects, as appropriate. For more information about the show policy-map interface command, refer to the Cisco IOS Quality of Service Solutions Command Reference.

What to Do Next
To configure Differentiated Services, use the following Cisco IOS features:

Modular QoS CLI. For complete conceptual information on the Modular QoS CLI feature, see the chapter Modular Quality of Service Command-Line Interface Overview of this book. For information on how to configure the feature, see the chapter Configuring the Modular Quality of Service Command-Line Interface of this book. Class-Based Packet Marking. For complete conceptual information on the Class-Based Packet Marking feature, see the chapter Classification Overview of this book. For information on how to configure the feature, see the chapter Configuring Class-Based Packet Marking of this book. Traffic Policing. For complete conceptual information on the Traffic Policing feature, see the chapter Policing and Shaping Overview of this book. For information on how to configure the feature, see the chapter Configuring Traffic Policing of this book. Class-Based Shaping. For complete conceptual information on the Class-Based Shaping feature, see the chapter Policing and Shaping Overview of this book. For information on how to configure the feature, see the chapter Configuring Class-Based Shaping of this book. DiffServ Compliant WRED. For complete conceptual information on the DiffServ Compliant Weighted Random Early Detection feature, see the chapter Congestion Avoidance Overview of this book. For information on how to configure the feature, see the chapter Configuring Weighted Random Early Detection of this book. MPLS CoS Enhancements. For more information about MPLS Class of Service (CoS), refer to the Cisco IOS Switching Services Configuration Guide.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-394

Modular Quality of Service Command-Line Interface

Modular Quality of Service Command-Line Interface Overview

This chapter provides a high-level overview of the Modular Quality of Service (QoS) Command-Line Interface (CLI), a feature that allows users to specify a traffic class independently of QoS policies. For information on how to configure the Modular QoS CLI, see the chapter Configuring the Modular Quality of Service Command-Line Interface in this book.

About the Modular QoS CLI

The Modular QoS CLI is a CLI structure that allows users to create traffic polices and attach these polices to interfaces. A traffic policy contains a traffic class and one or more QoS features. A traffic class is used to classify traffic, while the QoS features in the traffic policy determine how to treat the classified traffic. Modular QoS CLI configuration includes contains the following three steps, which are detailed more thoroughly in the Configuring the Modular Quality of Service Command-Line Interface of this book:
Step 1 Step 2 Step 3

Define a traffic class with the class-map command. Create a traffic policy by associating the traffic class with one or more QoS features (using the policy-map command). Attach the traffic policy to the interface with the service-policy command.

The class-map command is used to define a traffic class. The purpose of a traffic class is to classify traffic. A traffic class contains three major elements: a name, a series of match commands, and, if more than one match command exists in the traffic class, an instruction on how to evaluate these match commands. The traffic class is named in the class-map command line; for example, if you enter the class-map cisco command while configuring the traffic class in the CLI, the traffic class would be named cisco.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-397

Modular Quality of Service Command-Line Interface Overview About the Modular QoS CLI

The match commands are used to specify various criteria for classifying packets. Packets are checked to determine whether they match the criteria specified in the match commands; if a packet matches the specified criteria, that packet is considered a member of the class and is forwarded according to the QoS specifications set in the traffic policy. Packets that fail to meet any of the matching criteria are classified as members of the default traffic class. The default traffic class is detailed more thoroughly in the Configuring the Modular Quality of Service Command-Line Interface chapter of this book. The instruction on how to evaluate these match commands needs to be specified if more than one match criterion exists in the traffic class. The evaluation instruction is specified with one of the following two options: class-map match-any or class-map match-all. If match-any is specified as the evaluation instruction, the traffic being evaluated by the traffic class must match one of the specified criteria. If match-all is specified as the evaluation instruction, the traffic being evaluated by the traffic class must match all of the specified criteria. The functionality of these options is detailed more thoroughly in the Configuring the Modular Quality of Service Command-Line Interface chapter of this book. The policy-map command is used to create a traffic policy. The purpose of a traffic policy is to configure the QoS features that should be associated with the traffic that has been classified in a user-specified traffic class or classes. A traffic policy contains three elements: a name, a traffic class (specified with the class command), and the QoS policies (which are detailed in the Configuring the Modular Quality of Service Command-Line Interface chapter of this book). The name of a traffic policy is specified in the policy-map CLI (for example, issuing the policy-map class1 command would create a traffic policy named class1). The traffic class that is used to classify traffic to the specified traffic policy is defined in policy map configuration mode, which is the automatic mode after naming the traffic policy. After choosing the traffic class that is used to classify traffic to the traffic policy, the user can enter the QoS features to apply to the classified traffic. This is done in policy-map class configuration mode. The QoS feature options are detailed more thoroughly in the Configuring the Modular Quality of Service Command-Line Interface chapter of this book. The Modular QoS CLI does not necessarily require that users associate only one traffic class to one traffic policy. When packets match to more than one match criterion, multiple traffic classes can be associated with a single traffic policy. Similarly, the Modular QoS CLI allows multiple traffic classes (nested traffic classes, which are also called nested class maps) to be configured as a single traffic class. This nesting can be achieved with the use of the match class-map command. The only method of combining match-any and match-all characteristics within a single traffic class is with the match class-map command. An example of a nested traffic class configuration using both match-all and match-any is provided in the Configuring the Modular Quality of Service Command-Line Interface chapter of this book.

Note

A packet can match only one traffic class within a traffic policy. If a packet matches more than one traffic class in the traffic policy, the first traffic class defined in the policy will be used. The service-policy command is used to attach the traffic policy, as specified with the policy-map command, to an interface. Because the elements of the traffic policy can be applied to packets entering and leaving the interface, users are required to specify whether the traffic policy characteristics should be applied to incoming or outgoing packets. For instance, the service-policy output class1 command would attach all the characteristics of the traffic policy named class1 to the specified interface. All packets leaving the specified interface are evaluated according to the criteria specified in the traffic policy named class1. For information on using the service-policy command, see the Configuring the Modular Quality of Service Command-Line Interface chapter of this book.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-398

Modular Quality of Service Command-Line Interface Overview About the Modular QoS CLI

Supported MIB
The Class-Based Quality of Service Management Information Base (Class-Based QoS MIB) provides read access to QoS configurations. This MIB also provides QoS statistics information based on the Modular QoS CLI, including information regarding class map and policy map parameters. This Class-Based QoS MIB is actually two MIBs: CISCO-CLASS-BASED-QOS-MIB and CISCO-CLASS-BASED-QOS-CAPABILITY-MIB. Use the Cisco Network Management Toolkit for MIBs tool on Cisco.com to locate MIBs.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-399

Modular Quality of Service Command-Line Interface Overview About the Modular QoS CLI

Cisco IOS Quality of Service Solutions Configuration Guide

QC-400

Configuring the Modular Quality of Service Command-Line Interface

This section describes the tasks for configuring QoS functionality with the Modular Quality of Service (QoS) Command-Line Interface (CLI). For complete conceptual information, see the chapter Modular Quality of Service Command-Line Interface Overview in this book. For a complete description of the QoS commands in this chapter, refer to the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the Identifying Supported Platforms section in the Using Cisco IOS Software chapter in this book.

Modular QoS CLI Configuration Task List

To configure and enable class-based QoS features, perform the tasks described in the following sections. The tasks in the first three sections are required; the task in the remaining section is optional.

Creating a Traffic Class (Required) Creating a Traffic Policy (Required) Attaching a Traffic Policy to an Interface (Required) Verifying the Configuration (Optional)

See the end of this chapter for the section Modular QoS CLI Configuration Examples.

Creating a Traffic Class

The class-map global configuration command is used to create a traffic class. The syntax of the class-map command is as follows: class-map [match-any | match-all] class-name no class-map [match-any | match-all] class-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-401

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Task List

The match all and match any options need to be specified only if more than one match criterion is configured in the traffic class. The class-map match-all command is used when all of the match criteria in the traffic class must be met in order for a packet to match the specified traffic class. The class-map match-any command is used when only one of the match criterion in the traffic class must be met in order for a packet to match the specified traffic class. If neither the match-all nor match-any keyword is specified, the traffic class will behave in a manner consistent with class-map match-all command. The match not command, rather than identifying the specific match parameter to use as a match criterion, is used to specify a match criterion that prevents a packet from being classified as a member of the class. For instance, if the match not qos-group 6 command is issued while you configure the traffic class, QoS group 6 becomes the only QoS group value that is not considered a successful match criterion. All other QoS group values would be successful match criteria. For additional information on using the match-any and match-all options, see the Configuring the Modular Quality of Service Command-Line Interface chapter of this book. To create a traffic class containing match criteria, use the class-map global configuration command to specify the traffic class name, and then use the following match commands in class-map configuration mode, as needed.

Note

This chapter lists the match commands available as of Release 12.2. For the most current information about match commands and Cisco IOS software, see the New Feature Documentation index for your particular Cisco IOS software release on Cisco.com.

Command
Router(config)# class-map class-map-name

Purpose Specifies the user-defined name of the traffic class. Names can be a maximum of 40 alphanumeric characters. If match-all or match-any are not specified, traffic must match all the match criterion to be classified as part of the traffic class. Specifies that all match criterion must be met for traffic entering the traffic class to be classified as part of the traffic class. Specifies that one of the match criterion must be met for traffic entering the traffic class to be classified as part of the traffic class. Specifies the numbered access list against whose contents packets are checked to determine if they belong to the class.
Note

Router(config)# class-map match-all class-map-name Router(config)# class-map match-any class-map-name Router(config-cmap)# match access-group access-group

Access lists configured with the optional log keyword of the access-list command are not supported when configuring a traffic class. For more information about the access-list command, refer to the Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 T.

Router(config-cmap)# match any Router config-cmap)# match class-map class-name Router(config-cmap)# match cos cos-number Router(config-cmap)# match destination-address mac address Router(config-cmap)# match input-interface interface-name

Specifies that all packets will be matched. Specifies the name of a traffic class to be used as a matching criterion (for nesting traffic class [nested class maps] within one another). Specifies the CoS value against whose contents packets are checked to determine if they belong to the class. Specifies the name of the destination MAC address used as a match criterion against which packets are checked to determine if they belong to the class. Specifies the name of the input interface used as a match criterion against which packets are checked to determine if they belong to the class.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-402

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Task List

Command
Router(config-cmap)# match ip dscp ip-dscp-value Router (config-cmap)# match ip precedence ip-precedence-value Router (config-cmap)# match ip rtp starting-port-number port-range Router (config-cmap)# match mpls experimental mpls-values Router (config-cmap)# match not match-criteria

Purpose Specifies up to eight differentiated services code point (DSCP) values used as match criteria. The value of each service code point is from 0 to 63. Specifies up to eight IP Precedence values used as match criteria. Specifies the Real-Time Protocol (RTP) port as the match criterion.

Specifies the Multiprotocol Label Switching (MPLS) values to use as match criterion against which packets are checked to determine if they belong to the class. Specifies a match criterion value that prevents packets from being classified as members of a specified traffic class. All other values of that particular match criterion belong to the class. Specifies the name of the protocol used as a match criterion against which packets are checked to determine if they belong to the class. Specifies the number of the QoS group index used as a match criterion against which packets are checked to determine if they belong to the class. Specifies the name of the source MAC address used as a match criterion against which packets are checked to determine if they belong to the class.

Router (config-cmap)# match protocol protocol Router (config-cmap)# match qos-group qos-group-value Router (config-cmap)# match source-address mac address-destination

Creating a Traffic Policy

To configure a traffic policy, use the policy-map global configuration command to specify the traffic policy name, and the use the following configuration commands to associate a traffic class, which was configured with the class-map command, with one or more QoS features. The traffic class is associated with the traffic policy when the class command is used. The class command must be issued after entering policy-map configuration mode. After entering the class command, you are automatically in policy-map class configuration mode, which is where the QoS policies for the traffic policy are defined. The QoS policies that can be applied in the traffic policy in policy-map class configuration mode are detailed in the following example: The syntax of the policy-map command is: policy-map policy-name no policy-map policy-name The syntax of the class command is: class class-name no class class-name All traffic that fails to meet the matching criteria belongs to the default traffic class. The default traffic class is user-configurable, but the default traffic class cannot be deleted. To configure a traffic policy, use the policy-map global configuration command to specify the traffic policy name, and then use the following configuration commands to associate a traffic class, which was configured with the class-map command, with one or more QoS policies. The traffic class is associated with the traffic policy when the class command is used. The class command must be issued immediately

Cisco IOS Quality of Service Solutions Configuration Guide

QC-403

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Task List

after entering policy-map configuration mode. After entering the class command, you are automatically in policy-map class configuration mode, which is where the QoS policies for the traffic policy are defined. To create a traffic policy, use the following commands beginning in global configuration mode, as needed.

Note

This chapter lists some of the command options for the policy-map configuration mode. These command options are not limited to Release 12.2 and can vary among platforms and Cisco IOS releases. Because software is updated frequently, this list of commands might not represent the most updated software command options. For the most current command options for your Cisco IOS software, see the New Feature Documentation index for your particular Cisco IOS software release on Cisco.com.

Command
Router (config)# policy-map policy-name

Purpose Specifies the name of the traffic policy to configure. Names can be a maximum of 40 alphanumeric characters. Specifies the name of a predefined traffic class, which was configured with the class-map command, used to classify traffic to the traffic policy. Specifies the default class to be created as part of the traffic policy. Specifies a minimum bandwidth guarantee to a traffic class in periods of congestion. A minimum bandwidth guarantee can be specified in kbps or by a percentage of the overall available bandwidth. Sets a command to its default value. Specifies the number of queues to be reserved for a traffic class. Specifies a maximum bandwidth usage by a traffic class through the use of a token bucket algorithm. Specifies the guaranteed allowed bandwidth, in kbps or percentage, for priority (time-sensitive) traffic. The optional bytes argument controls the size of the burst allowed to pass through the system without being considered in excess of the configured kbps rate. Specifies the maximum number of packets queued for a traffic class (in the absence of the random-detect command). Enables a Weighted Random Early Detection (WRED) drop policy for a traffic class that has a bandwidth guarantee. Sets the ATM cell loss priority (CLP) bit to 1.

Router (config-pmap)# class class-name

Router (config-pmap)# class class-default

Router (config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

Router (config-pmap-c)# default command Router (config-pmap-c)# fair-queue number-of-queues

Router (config-pmap-c)# police bps burst-normal burst-max conform-action action exceed-action action violate-action action Router (config-pmap-c)# priority {kbps | percent percent} [bytes]

Router (config-pmap-c)# queue-limit packets

Router (config-pmap-c)# random-detect

Router (config-pmap-c)# set atm-clp

Cisco IOS Quality of Service Solutions Configuration Guide

QC-404

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Task List

Command
Router (config-pmap-c)# set cos cos-value

Purpose Specifies a Class of Service (CoS) value or values to associate with the packet. The number is in the range from 0 to 7. Specifies the IP DSCP of packets within a traffic class. The IP DSCP value can be any value from 0 to 63. Specifies the IP Precedence value of packets within a traffic class. The IP Precedence value can be any value from 0 to 7. Designates the value to which the MPLS bits are set if the packets match the specified policy map. Specifies a QoS group value to associate with the packet. The QoS group value can be any value from 0 to 99. Specifies the name of a traffic policy to be used as a matching criterion (for nesting traffic policies [hierarchical traffic policies] within one another). Shapes traffic to the indicated bit rate according to the algorithm specified.

Router (config-pmap-c)# set ip dscp ip-dscp-value

Router (config-pmap-c)# set ip precedence ip-precedence-value

Router (config-pmap-c)# set mpls experimental value

Router (config-pmap-c)# set qos-group qos-group-value

Router (config-pmap-c)# service-policy policy-map-name

Router (config-pmap-c)# shape {average | peak} mean-rate [burst-size [excess-burst-size]]

Attaching a Traffic Policy to an Interface

Use the service-policy interface configuration command to attach a traffic policy to an interface and to specify the direction in which the policy should be applied (either on packets coming into the interface or packets leaving the interface). Use the no form of the command to detach a traffic policy from an interface. The service-policy command syntax is as follows: service-policy {input | output} policy-map-name no service-policy {input | output} policy-map-name

Note

Depending on the platform and Cisco IOS release, a traffic policy can be attached to an ATM permanent virtual circuit (PVC) subinterface, Frame Relay data-link connection identifier (DLCI), or other type of interface. To attach a traffic policy to an interface, use the following commands in interface configuration mode, as needed:

Command
Router(config-if)# service-policy output policy-map-name

Purpose Specifies the name of the traffic policy to be attached to the output direction of an interface. The traffic policy evaluates all traffic leaving that interface. Specifies the name of the traffic policy to be attached to the input direction of an interface. The traffic policy evaluates all traffic entering that interface.

Router(config-if)# service-policy input policy-map-name

Cisco IOS Quality of Service Solutions Configuration Guide

QC-405

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Examples

Note

Multiple traffic policies on tunnel interfaces and physical interfaces are not supported if the interfaces are associated with each other. For instance, if a traffic policy is attached to a tunnel interface while another traffic policy is attached to a physical interface with which the tunnel interface is associated, only the traffic policy on the tunnel interface works properly.

Verifying the Configuration

To display the information relating to a traffic class or traffic policy, use one of the following commands in EXEC mode, as needed. To display the configuration of a traffic policy and its associated traffic class, use the show policy-map EXEC command. Command
Router# show class-map Router# show class-map class-name

Purpose Displays all traffic class information. Displays the traffic class information for the user-specified traffic class. Displays all configured traffic policies. Displays the user-specified traffic policy. Displays configurations and statistics of all input and output policies attached to an interface. Displays configuration and statistics of the input and output policies attached to a particular interface. Displays configuration and statistics of the input policy attached to an interface. Displays configuration and statistics of the output policy attached to an interface. Displays the configuration and statistics of the class name configured in the policy.

Router# show policy-map Router# show policy-map policy-map-name Router# show policy-map interface

Router# show policy-map interface interface-spec

Router# show policy-map interface interface-spec input

Router# show policy-map interface interface-spec output

Router# show policy-map [ interface [interface-spec [input | output] [ class class-name]]]]

Modular QoS CLI Configuration Examples

This section provides the Modular QoS CLI configuration examples:

Traffic Classes Defined Example Traffic Policy Created Example Traffic Policy Attached to an Interface Example match not Command Example Default Traffic Class Configuration Example class-map match-any and class-map match-all Commands Example Traffic Class as a Match Criterion (Nested Class Maps) Example Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example

Cisco IOS Quality of Service Solutions Configuration Guide

QC-406

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Examples

For information on how to configure the QoS functionality with the Modular QoS CLI, see the section Modular QoS CLI Configuration Task List in this chapter.

Traffic Classes Defined Example

In the following example, two traffic classes are created and their match criteria are defined. For the first traffic class called class1, access control list (ACL) 101 is used as the match criterion. For the second traffic class called class2, ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the class.
Router(config)# class-map class1 Router(config-cmap)# match access-group 101 Router(config-cmap)# exit Router(config)# class-map class2 Router(config-cmap)# match access-group 102 Router(config-cmap)# exit

Traffic Policy Created Example

In the following example, a traffic policy called policy1 is defined to contain policy specifications for the two classesclass1 and class2. The match criteria for these classes were defined in the traffic classes (see the section Creating a Traffic Class in this chapter). For class1, the policy includes a bandwidth allocation request and a maximum packet count limit for the queue reserved for the class. For class2, the policy specifies only a bandwidth allocation request.
Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap)# exit Router(config-pmap)# class class2 Router(config-pmap-c)# bandwidth 2000 Router(config-pmap)# exit

Traffic Policy Attached to an Interface Example

The following example shows how to attach an existing traffic policy (which was created in the preceding Traffic Policy Created Example section) to an interface. After you define a traffic policy with the policy-map command, you can attach it to one or more interfaces to specify the traffic policy for those interfaces by using the service-policy command in interface configuration mode. Although you can assign the same traffic policy to multiple interfaces, each interface can have only one traffic policy attached at the input and only one traffic policy attached at the output.
Router(config)# interface e1/1 Router(config-if)# service-policy output policy1 Router(config-if)# exit Router(config)# interface fa1/0/0 Router(config-if)# service-policy output policy1 Router(config-if)# exit

Cisco IOS Quality of Service Solutions Configuration Guide

QC-407

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Examples

match not Command Example

The match not command is used to specify a specific QoS policy value that is not used as a match criterion. When using the match not command, all other values of that QoS policy become successful match criteria. For instance, if the match not qos-group 4 command is issued in class-map configuration mode, the specified class will accept all QoS group values except 4 as successful match criteria. In the following traffic class, all protocols except IP are considered successful match criteria:
Router(config)# class-map noip Router(config-cmap)# match not protocol ip Router(config-cmap)# exit

Default Traffic Class Configuration Example

Unclassified traffic (traffic that does not meet the match criteria specified in the traffic classes) is treated as belonging to the default traffic class. If the user does not configure a default class, packets are still treated as members of the default class. However, by default, the default class has no enabled features. Therefore, packets belonging to a default class with no configured features have no QoS functionality. These packets are then placed into a FIFO queue and forwarded at a rate determined by the available underlying link bandwidth. This FIFO queue is managed by tail drop. (Tail drop is a means of avoiding congestion that treats all traffic equally and does not differentiate between classes of service. Queues fill during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full). The following example configures a traffic policy for the default class of the traffic policy called policy1. The default class (which is always called class-default) has these characteristics: 10 queues for traffic that does not meet the match criteria of other classes whose policy is defined by the traffic policy policy1, and a maximum of 20 packets per queue before tail drop is enacted to handle additional queued packets.
Router(config)# policy-map policy1 Router(config-pmap)# class class-default Router(config-pmap-c)# fair-queue 10 Router(config-pmap-c)# queue-limit 20

class-map match-any and class-map match-all Commands Example

This section illustrates the difference between the class-map match-any command and the class-map match-all command. The match-any and match-all options determine how packets are evaluated when multiple match criteria exist. Packets must either meet all of the match criteria (match-all) or one of the match criteria (match-any) in order to be considered a member of the traffic class. The following example shows a traffic class configured with the class-map match-all command:
Router(config)# class-map match-all cisco1 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# match access-group 101

If a packet arrives on a router with traffic class called cisco1 configured on the interface, the packet is evaluated to determine if it matches the IP protocol, QoS group 4, and access group 101. If all three of these match criteria are met, the packet matches traffic class cisco1.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-408

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Examples

The following example shows a traffic class configured with the class-map match-any command:
Router(config)# class-map match-any cisco2 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# match access-group 101

In traffic class called cisco2, the match criteria are evaluated consecutively until a successful match criterion is located. The packet is first evaluated to the determine whether IP protocol can be used as a match criterion. If IP protocol can be used as a match criterion, the packet is matched to traffic class george. If IP protocol is not a successful match criterion, then QoS group 4 is evaluated as a match criterion. Each matching criterion is evaluated to see if the packet matches that criterion. Once a successful match occurs, the packet is classified as a member of traffic class cisco2. If the packet matches none of the specified criteria, the packet is classified as a member of the traffic class. Note that the class-map match-all command requires that all of the match criteria must be met in order for the packet to be considered a member of the specified traffic class (a logical AND operator). In the example, protocol IP AND QoS group 4 AND access group 101 have to be successful match criteria. However, only one match criterion must be met for the packet in the class-map match-any command to be classified as a member of the traffic class (a logical OR operator). In the example, protocol IP OR QoS group 4 OR access group 101 have to be successful match criteria.

Traffic Class as a Match Criterion (Nested Class Maps) Example

There are two reasons to use the match class-map command. One reason is maintenance; if a long traffic class currently exists, using the Traffic Class match criterion is simply easier than retyping the same traffic class configuration. The more prominent reason for the match class-map command is to allow users to use match-any and match-all statements in the same traffic class. If you want to combine match-all and match-any characteristics in a traffic policy, create a traffic class using one match criteria evaluation instruction (either match any or match all) and then use this traffic class as a match criterion in a traffic class that uses a different match criteria type. A concept example: Suppose A, B, C, and D were all separate match criterion, and you wanted traffic matching A, B, or C and D (A or B or [C and D]) to be classified as belonging to the traffic class. Without the nested traffic class, traffic would either have to match all 4 of the match criterion (A and B and C and D) or match any of the match criterion (A or B or C or D) to be considered part of the traffic class. You would not be able to combine and (match-all) and or (match-any) statements within the traffic class, and you would therefore be unable to configure the desired configuration. The solution: Create one traffic class using match-all for C and D (which we will call criterion E), and then create a new match-any traffic class using A, B, and E. The new traffic class would have the correct evaluation sequence (A or B or E, which would also be A or B or [C and D]). The desired traffic class configuration has been achieved. The only method of mixing match-all and match-any statements in a traffic class is through the use of the traffic class match criterion.

Nested Traffic Class for Maintenance Example

In the following example, the traffic class called class1 has the same characteristics as traffic class called class2, with the exception that traffic class class1 has added a destination address as a match criterion. Rather than configuring traffic class class1 line by line, a user can enter the match class-map class2

Cisco IOS Quality of Service Solutions Configuration Guide

QC-409

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Examples

command. This command allows all of the characteristics in the traffic class called class2 to be included in the traffic class called class1, and the user can simply add the new destination address match criterion without reconfiguring the entire traffic class.
Router(config)# class-map match-any class2 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 3 Router(config-cmap)# match access-group 2 Router(config-cmap)# exit Router(config)# class-map match-all class1 Router(config-cmap)# match class-map class2 Router(config-cmap)# match destination-address mac 1.1.1 Router(config-cmap)# exit

Nested Traffic Class to Combine match-any and match-all Characteristics in One Traffic Class Example
The only method of including both match-any and match-all characteristics in a single traffic class is to use the match class-map command. To combine match-any and match-all characteristics into a single class, a traffic class created with the match-any instruction must use a class configured with the match-all instruction as a match criterion (through the match class-map command), or vice versa. The following example shows how to combine the characteristics of two traffic classes, one with match-any and one with match-all characteristics, into one traffic class with the match class-map command. The result of traffic class montana requires a packet to match one of the following three match criteria to be considered a member of traffic class class4: IP protocol and QoS group 4, destination MAC address 1.1.1, or access group 2. In this example, only the traffic class called class4 is used with the traffic policy called policy1.
Router(config)# class-map match-all class3 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# exit Router(config)# class-map match-any class4 Router(config-cmap)# match class-map class3 Router(config-cmap)# match destination-address mac 1.1.1 Router(config-cmap)# match access-group 2 Router(config-cmap)# exit Router(config)# policy-map policy1 Router(config-pmap)# class class4 Router(config-pmap-c)# police 8100 1500 2504 conform-action transmit exceed-action set-qos-transmit 4 Router(config-pmap-c)# exit

Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example

A traffic policy can be nested within a QoS policy when the service-policy command is used in policy-map class configuration mode. A traffic policy that contains a nested traffic policy is called a hierarchical traffic policy.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-410

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Examples

A hierarchical traffic policy contains a child and a parent policy. The child policy is the previously defined traffic policy that is being associated with the new traffic policy through the use of the service-policy command. The new traffic policy using the preexisting traffic policy is the parent policy. In the example in this section, traffic policy called child is the child policy and traffic policy called parent is the parent policy. Hierarchical traffic policies can be attached to subinterfaces, Frame Relay PVCs, and ATM PVCs. A hierarchical traffic policy is particularly beneficial when configuring VIP-based distributed FRF.11 and FRF.12 PVCs. When hierarchical traffic policies are used, a single traffic policy (with a child and a parent policy) can be used to shape and prioritize PVC traffic. In the following example, the child policy is responsible for prioritizing traffic and the parent policy is responsible for shaping traffic. In this configuration, the parent policy allows packets to be sent from the interface, and the child policy determines the order in which the packets are sent.
Router(config)# policy-map child Router(config-pmap)# class voice Router(config-pmap-c)# priority 50 Router(config)# policy-map parent Router(config-pmap)# class class-default Router(config-pmap-c)# shape average 10000000 Router(config-pmap-c)# service-policy child

With the exception that the values associated with the priority and shape commands can be modified, the example is the required configuration for PVCs using FRF.11 or FRF.12. The value used with the shape command is provisioned from the committed information rate (CIR) value from the service provider. For additional information on FRF.11 and FRF.12 PVCs, refer to the Cisco IOS Voice, Video, and Fax Configuration Guide. For additional information on hierarchical traffic policies, refer to the Cisco IOS Voice, Video, and Fax Configuration Guide. For information about the service-policy command, refer to the Cisco IOS Quality of Service Solutions Command Reference.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-411

Configuring the Modular Quality of Service Command-Line Interface Modular QoS CLI Configuration Examples

Cisco IOS Quality of Service Solutions Configuration Guide

QC-412

Security Device Manager

Security Device Manager Overview

This chapter provides a high-level overview of the Cisco Security Device Manager.

About the Security Device Manager

The Cisco Router and Security Device Manager (SDM) provides an intuitive, graphical user interface for configuring and monitoring advanced IP-based QoS functionality within Cisco routers, and is used to ease QoS configuration and monitoring for a single device. Additionally, the Cisco SDM provides integrated management of Cisco IOS features like wide-area network (WAN) access, dynamic routing, IPSec virtual private networks (VPNs), firewalls, and intrusion prevention. For more information about the Cisco SDM, please visit http://www.cisco.com/go/sdm.

Cisco IOS Quality of Service Solutions Configuration Guide

QC-415

Security Device Manager Overview About the Security Device Manager

Cisco IOS Quality of Service Solutions Configuration Guide

QC-416

Index

I
BC DC FC IC IPC MWC P2C P3C QC SC TC VC WC XC Cisco IOS Bridging and IBM Networking Configuration Guide Cisco IOS Dial Technologies Configuration Guide Cisco IOS Configuration Fundamentals Configuration Guide Cisco IOS Interface Configuration Guide Cisco IOS IP Routing Configuration Guide Cisco IOS Mobile Wireless Configuration Guide Cisco IOS AppleTalk and Novell IPX Configuration Guide Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide Cisco IOS Quality of Service Solutions Configuration Guide Cisco IOS Security Configuration Guide Cisco IOS Terminal Services Configuration Guide Cisco IOS Voice, Video, and Fax Configuration Guide Cisco IOS Wide-Area Networking Configuration Guide Cisco IOS Switching Services Configuration Guide

N D E X

fragment size for monitoring overview verifying

QC-315 QC-332

QC-328, QC-329

QC-332

RSVP considerations

QC-265

RSVP over ATM network See RSVP-ATM QoS Interworking RSVP reservations, handling static maps, displaying VCs circuit bumping
QC-353 QC-357, QC-362 QC-362 QC-249 QC-362

IP to ATM CoS, configuring per-VC CBWFQ, configuring See also ATM VC bundles ATM VC bundles attributes, configuring bundle management
QC-358

Symbols
<cr>
xxxvii xxxvi

benefits

QC-351 QC-349 QC-349

differentiated service multiple VCs

QC-350

? command

IP Precedence, matching VC bundle members

QC-348, QC-359

A
access-list (extended) command access-list (standard) command access-list rate-limit command access lists GTS, configuring admission control ATM LFI configuration (example) configuring
QC-334 QC-328 to QC-330 QC-224 QC-47 QC-57 QC-50 QC-57

class assignment creating members adding

QC-359 QC-357

QC-359

attributes, configuring configuring monitoring VC class attaching attributes configuring

QC-359 QC-358 QC-358 QC-360

QC-360

Policy Propagation via BGP feature

QC-246

VC class, applying to
QC-362

QC-360

parameters, configuring

QC-358

Cisco IOS Quality of Service Solutions Configuration Guide

QC-419

Index

average rate shaping, configuring

QC-230

policy examples summary

QC-7

QC-7

B
backbone routers, QoS functions bandwidth command service policies traffic classes bandwidths allocation CBWFQ LLQ changing
QC-90 QC-94 QC-125 QC-188, QC-192, QC-404 QC-2 QC-89, QC-136

configuration (example) configuring

QC-55

QC-59

conform and exceed actions IP Precedence, setting monitoring overview

QC-59 QC-208

QC-57

bandwidth (policy-map class) command

QC-244

multiple rate policies

QC-26

packet classification, methods policies, configuring policy requirements rate limits average rate, defined
QC-206 QC-57 QC-58

QC-26

IP RTP Priority
QC-98 QC-238

rate-limit command action keywords

QC-57

management

QC-112 QC-95, QC-112 QC-102

excess burst size, defined extended burst size, defined normal burst size, defined overview summary restrictions
QC-4 QC-204

QC-206 QC-206 QC-206

maximum reserved RSVP considerations FRTS GTS

QC-218 QC-214

priority command, guaranteeing with

QC-263

BECN (backward explicit congestion notification)

recommended burst sizes

QC-13 QC-209 QC-55

QC-207

best-effort service, defined

traffic rate limitation See also DCAR carriage return (<cr>) cautions, usage in text

BGP (Border Gateway Protocol), policy propagation See Policy Propagation via BGP bgp-policy command broadcast command bump command bundle command bundles, VCs See ATM VC bundles burst factor, configuring burst size, configuring
QC-276 QC-140 QC-48 QC-358

xxxvii xxxii

CBWFQ (class-based WFQ) average rate shaping, configuring bandwidth allocation

QC-90, QC-91 QC-119, QC-364 QC-230

QC-360 QC-357

class queue packet limit, configuring configuration (example) configuring enabling

QC-117 QC-143

QC-122, QC-139, QC-363 QC-230, QC-231 QC-149

GTS, configuration (example)

IP RTP Priority, configuration (example)

C
CAR (committed access rate) classification
QC-26

overview per-VC

QC-89 QC-230

peak rate shaping, configuring

QC-350, QC-362 QC-230

policy maps
Cisco IOS Quality of Service Solutions Configuration Guide

QC-420

Index

prerequisites restrictions

QC-180 QC-91 QC-363

class maps, defining GTS NBAR WRED class maps

QC-230 QC-73, QC-74 QC-191

QC-118 QC-136

class policies, configuring

QC-94

service policies, attaching strict priority queueing VCs, CoS supported See also class policies

QC-363

CELP (code excited linear prediction compression) QC-338 Cisco IOS configuration changes, saving class (policy-map) command class-based packet marking configuration (example) configuring prerequisites restrictions verifying
QC-63 QC-29 QC-29 QC-66 QC-67 xl QC-121, QC-138, QC-364

configuration (example) configuring class policies bandwidth, configuring CBWFQ, configuring information, displaying default class, configuring
QC-118

QC-144

match criteria, configuring

QC-118, QC-136

QC-125 QC-90 QC-121, QC-138, QC-364 QC-124, QC-139, QC-230 QC-137 QC-123, QC-126

LLQ priority queue, configuring queue packet limit, configuring tail drop, configuring
QC-230 QC-119

class-based shaping buffers, configuring configuring

QC-229 QC-215

WRED packet drop, configuring class-vc command commands

QC-361

QC-120, QC-188

feature description class-based WFQ

command modes, understanding

xxxv to xxxvi

See CBWFQ; DCBWFQ class-bundle command class command bandwidth, modifying for a service policy IP Precedence value, configuring traffic classes, configuring traffic policies, configuring classification BGP CAR defined methods PBR
QC-7 QC-6, QC-26 QC-21 QC-22 QC-75 QC-188, QC-189 QC-64 QC-126 QC-125 QC-359

context-sensitive help for abbreviating default form, using no form, using command syntax conventions
xxxi xxxvii xl xxxix xxxix

xxxvi

queue limit, modifying for service policy

displaying (example) configurations, saving congestion avoidance defined

QC-171

flow-based WRED IP to ATM CoS RED

QC-172 QC-11 QC-171 QC-175

QC-181 QC-172

global synchronization
QC-352

IP Precedence
QC-21 QC-24

summary tail drop WRED

QC-133 QC-229

class-map command bandwidth, PQ, configuring class-based shaping

congestion management defined

QC-79

Cisco IOS Quality of Service Solutions Configuration Guide

QC-421

Index

IP to ATM CoS queueing CQ FIFO PQ WFQ summary uses

QC-80 QC-79 QC-80 QC-79 QC-8

QC-352

monitoring restrictions

QC-59 QC-26

platform support See also CAR

QC-209

DCBWFQ (distributed class-based WFQ) benefits

QC-92 QC-147

configuration (example) configuring description prerequisites

QC-249 QC-296 QC-125 QC-91 QC-93 QC-93 QC-92

QC-80

Controlled Load Service peak rate limit RSVP-ATM QoS Interworking feature description verifying
QC-305 QC-22 QC-252

restrictions

COPS (Common Open Policy Service), used with RSVP

RSVP interaction

DE (discard eligible) lists, traffic shaping debug atm bundle errors command debug atm bundle events command debug priority command
QC-133 QC-347 QC-362 QC-362

QC-212

CoS (class of service), defining classes CQ (custom queueing) bandwidth allocation behavior byte count configuring
QC-106 QC-108 QC-162 QC-109

differential services, supporting differentiated service model classification defined features CAR
QC-4 QC-4 QC-4 QC-4 QC-22

configuration (example)
QC-159 QC-110

considerations

default priority, assigning how it works (figure) output queues overview window size configuring overview summary
QC-106 QC-106 QC-109

QC-161

WFQ WRED

QC-107

DiffServ (Differentiated Services) components DSCP setting feature sets overview

QC-379 QC-375 QC-376

CRTP (Compressed Real-Time Protocol)

QC-337 QC-316 QC-16 QC-70 QC-160

DS field definition
QC-379

implementation (sample)
QC-375

QC-380

crypto map command

PHB assured forwarding class-selector default

QC-376 QC-378 QC-388 QC-377 QC-377

custom-queue-list command

D
DCAR (Distributed CAR) class-based policy, configuring configuration (example)
QC-59 QC-58

expedited forwarding Distributed CRTP benefits

QC-319

troubleshooting log (sample)

Cisco IOS Quality of Service Solutions Configuration Guide

QC-422

Index

configuration (example) configuring description prerequisites restrictions documentation conventions modules ordering
xxxi QC-341 QC-16 QC-320 QC-320

QC-342

platform support restrictions uses

QC-179

QC-177

QC-180, QC-185

See also WRED

E
xxxiii

feedback, providing
xxvii to xxix

edge routers, QoS functions encapsulation command

QC-2

QC-358 QC-356 QC-318

online, accessing
xxxiii

xxxii

exponential-weighting-constant command Express RTP and TCP Header Compression

xxxii xxx

Documentation CD-ROM DSBM (designated SBM) candidate, configuring definition defined

QC-258

documents and resources, supporting

QC-308

F
fair-queue (class-default) command fair-queue (DWFQ) command fair-queue (WFQ) command fair-queue command fair queueing See DWFQ; WFQ fair-queue limit command
QC-116, QC-117 QC-116 QC-188 QC-116, QC-117 QC-114 QC-116, QC-117 QC-89, QC-136, QC-364

QC-116

DSCP (differentiated services code point) value

QC-182 QC-190

fair-queue aggregate-limit command fair-queue individual-limit command

use with WRED, configuring dscp command

QC-191

DTS (Distributed Traffic Shaping) See traffic shaping, Distributed DWFQ (distributed WFQ) configuration (example) configuring drop policy monitoring requirements restrictions
QC-114 QC-88 QC-115 QC-87 QC-142

fair-queue qos-group command fair-queue tos command Feature Navigator See platforms, supported
QC-117

fair-queue weight command

QC-116, QC-117

platform support
QC-88

QC-87

FECN (forward explicit congestion notification), FRTS QC-218 FIFO (First In First Out) queueing flow-based WRED benefits
QC-181 QC-196 QC-83 xl

DWRED (distributed WRED) configuration (example)

QC-192 QC-188, QC-189

filtering output, show and more commands

exponential weight factor, configuring group definitions, attaching packet drop in traffic policies per-VC DWRED configuring packet drop
QC-296 QC-250 QC-250 QC-188

configuration (example) configuring enabling

QC-190 QC-190

drop policy, supporting

QC-250

flow count value, setting

QC-190 QC-190

flow threshold scaling factor, configuring

Cisco IOS Quality of Service Solutions Configuration Guide

QC-423

Index

overview

QC-181

frame-relay interface-queue priority command frame-relay ip rtp header-compression command

QC-276

QC-130 QC-338

See also WRED flow classification, configuring Frame Relay FRF.12 fragmentation GTS, configuring LFI configuration (example) configuring monitoring overview verifying LLQ enabling verifying
QC-139 QC-105 QC-332 QC-315 QC-332 QC-333 QC-328 to QC-330 QC-316 QC-224

Frame Relay IP RTP Priority configuring monitoring verifying

QC-128 QC-11, QC-96

feature description
QC-129 QC-129

frame-relay ip rtp priority command

QC-128 QC-338

frame-relay map ip compress command

frame-relay map ip rtp header-compression command QC-338 FRF.12 Fragmentation

QC-316 QC-217

FRTS (Frame Relay Traffic Shaping)

prerequisites

G
global configuration mode, summary of GTS (Generic Traffic Shaping) configuration (example) configuring monitoring
QC-96 QC-223 QC-215 QC-225 xxxvi

QC-139 QC-105

VoFR, effect on

PIPQ (PVC Interface Priority Queueing) configuration (example) description enabling

QC-96 QC-130 QC-96 QC-152

how it works (figure)

QC-225 QC-214

FIFO queueing, effect on

Frame Relay traffic shaping, effect on FRF.12 fragmentation, effect on monitoring prerequisites
QC-131 QC-97 QC-130 QC-130 QC-96

overview See RSVP

guaranteed bandwidth, reserved flows

PVC priority, configuring queue size, configuring restrictions verifying

QC-97 QC-131

H
hardware platforms See platforms, supported hashed queues, reserving help command
xxxvi QC-188

PVC Interface Priority Queueing See Frame Relay, PIPQ RSVP configuration (example) configuration tasks considerations described monitoring verifying
QC-247 QC-287 QC-285
Cisco IOS Quality of Service Solutions Configuration Guide

hold queue on ATM adapter

QC-287

configuration (example) configuring verifying

QC-141 QC-141

QC-158

QC-281

QC-264

QC-424

Index

I
ICA traffic, classification by NBAR inarp command indexes, master
QC-358 xxx QC-4 QC-33

where used WRED

QC-22

QC-186 QC-45 QC-296

ip route-cache policy command ip rsvp bandwidth command

ip rsvp atm-peak-rate-limit command ip rsvp burst policing command ip rsvp dsbm candidate command ip rsvp flow-assist command ip rsvp neighbor command
xxxvi

QC-265, QC-294 QC-276 QC-308 QC-308

integrated service models, defined intelligent queueing mechanisms Controlled Load Service guaranteed rate service interface command interfaces priority groups, assigning queueing priority, assigning ip as-path access-list command ip community-list command configuration (example) configuring
QC-64 QC-167 QC-70 QC-4 QC-4

ip rsvp dsbm non-resv-send-limit command

QC-267 QC-267 QC-304

interface configuration mode, summary of

ip rsvp policy cops command

ip rsvp policy cops minimal command ip rsvp policy cops report-all command ip rsvp policy cops servers command ip rsvp policy cops timeout command
QC-48 QC-161 QC-49

QC-304 QC-305 QC-304 QC-305 QC-304

ip bgp-community new-format command

QC-48

ip rsvp policy default-reject command ip rsvp pq-profile command ip rsvp precedence command ip rsvp reservation command
QC-276 QC-268 QC-266

IP DSCP (differentiated services code point) value

QC-67

ip rsvp reservation-host command

QC-45 QC-317

QC-266

ip local policy route-map command ip nbar port-map command

QC-76

ip rsvp sender command

QC-266 QC-266 QC-294

IP multicast routing, RTP header compression ip nbar protocol-discovery command ip policy route-map command IP precedence bit values, displaying CAR
QC-205 QC-67 QC-297 QC-44 QC-76

ip rsvp sender-host command ip rsvp svc-required command ip rsvp tos command

QC-268

ip rsvp udp-multicasts command

QC-267 QC-339, QC-342

ip rtp compression-connections command ip rtp header-compression command IP RTP Priority bandwidth allocation configuring
QC-22 QC-244 QC-250 QC-127 QC-93 QC-95 QC-93, QC-127 QC-323 QC-94 QC-148 QC-64

QC-338

configuration (example) configuring overview

QC-22

configuration (example) overview restrictions

packet classification

queueing mechanisms used setting signaling ToS field

QC-244 QC-243 QC-22 QC-23 QC-349

RSVP-ATM QoS Interworking feature

ip rtp priority command ip rtp reserve command

ip tcp compression-connections command IP to ATM class of service (CoS) bandwidth, maximum available benefits
QC-351 QC-363

QC-342

values (table)

VC bundle members

Cisco IOS Quality of Service Solutions Configuration Guide

QC-425

Index

circuit bumping features overview

QC-352 QC-347

QC-353 QC-365

restrictions verifying Frame Relay enabling verifying overview restrictions verifying

QC-103 QC-135

configuration (example)

QC-139 QC-105

per-VC CBWFQ configuring support restrictions VC bundles configuring support

QC-357 QC-348 QC-362 QC-350 QC-362 QC-354

prerequisites

QC-139 QC-105

VoFR, effect on
QC-97 QC-101 QC-132

prerequisites

See also ATM VC bundles

M
match access-group command
QC-118, QC-136

L
LFI (Link Fragmentation and Interleaving) configuration (example) configuring defined
QC-321 QC-323 QC-324, QC-333 QC-328 to QC-330

match any command

QC-402 QC-49 QC-402 QC-48

match as-path command

match class-map command match cos command

QC-402

match community-list command

match destination-address mac command match input-interface command match ip address command match ip dscp command match ip rtp command match length command match not command
QC-403 QC-403 QC-44, QC-50

QC-402

interleaving statistics, displaying monitoring overview summary verifying

QC-332 QC-313, QC-315 QC-15 QC-332

QC-118, QC-136

match ip precedence command

QC-403 QC-44

See also Frame Relay, LFI; ATM, LFI link efficiency mechanisms CRTP LFI
QC-316 QC-313

match mpls experimental command

QC-403

QC-118

match protocol command match qos-group command

QC-98 QC-140

QC-74, QC-118, QC-136 QC-403 QC-403

LLQ (low latency queueing) bandwidth allocation burst size, configuring configuring Distributed benefits
QC-102 QC-155 QC-131

match source-address mac command maximum reserved bandwidth max-reserved-bandwidth command

QC-95, QC-112 QC-95, QC-127, QC-132

MBONE (multicast backbone), RTP header compression QC-318 memory management, NBAR MIB, descriptions online configuration (example)
xxx QC-35

configuration (examples) configuring description prerequisites

QC-133 QC-101 QC-104

MLP (Multilink Point-to-Point Protocol)

QC-324

Cisco IOS Quality of Service Solutions Configuration Guide

QC-426

Index

defined

QC-321

oam retry command

QC-322

QC-358

interleaving configuring packets monitoring WFQ modes See command modes Modular QoS Command-Line Interface configuration (example) configuration, verifying configuring description
QC-401 QC-397 QC-399 QC-323 QC-406 QC-406 QC-321 QC-323

P
packet classifications See classification packet loss prevention, traffic shaping paths, configuring classification configuring enabling features overview
QC-276 QC-211

QC-321

PBR (policy-based routing)

QC-6 QC-46

configuration (example)
QC-43 QC-43 QC-24

MIB supported

multilink virtual-template command

IP precedence, setting
QC-24 QC-24 QC-25

QC-244

N
NBAR (Network-Based Application Recognition) benefits
QC-31 QC-76

route maps when to use

PDLM (Packet Description Language Module), described QC-35 peak rates DSBM candidate, configuring limiting
QC-296, QC-297 QC-230 QC-308

configuration (examples) configuring description PDLMs

QC-73 QC-8, QC-30

memory management
QC-35 QC-40

QC-35

shape, configuring assured forwarding

PHB (Per-Hop Behavior)

QC-377

restrictions

supported protocols traffic classification verifying

QC-76

QC-36 QC-33 QC-34

class-selector default
QC-377

QC-377

used with Protocol Discovery feature NetFlow services, RSVP attachment to network congestion, defined notes, usage in text
xxxii QC-9

definition

QC-376 QC-378

expedited forwarding
QC-267

See also DiffServ platforms, supported Feature Navigator, identify using release notes, identify using policing CAR
QC-204 QC-203 QC-204 QC-13 xli xli

NonResvSendLimit object, configuring

QC-308

O
oam-bundle command
QC-358

defined

token bucket

used with shaping, summary

Cisco IOS Quality of Service Solutions Configuration Guide

QC-427

Index

policy-map command bandwidth, configuring for service policies

QC-133, QC-361 QC-125,

ppp multilink fragment-delay command ppp multilink interleave command PQ (priority queueing)
QC-229

QC-323

QC-323

class-based shaping, configuring classes, deleting DTS

QC-238 QC-188, QC-189 QC-364 QC-124 QC-64

behavior

QC-110 QC-167

configuration (example) configuring filters group

QC-165 QC-166

DSCP value, configuring DWRED GTS NBAR

default, assigning
QC-110 QC-167

flow-based WFQ
QC-230 QC-73

how it works (figure)

QC-126 QC-75

QC-110 QC-111 QC-160, QC-166

lower-priority traffic, effect on maximum number of packets monitoring overhead overview

QC-230 QC-229 QC-161, QC-167 QC-111 QC-110 QC-111

queue limit, setting WRED

traffic policies, configuring

QC-120, QC-191

policy maps class, attaching class-based shaping, configuring configuration (example) configuring bandwidth queue limit default class deleting GTS
QC-125 QC-126 QC-119, QC-137

packet classification restrictions strict

QC-111 QC-144, QC-145

See IP RTP Priority; LLQ traffic prioritization uses

QC-111 QC-360 QC-356 QC-110

precedence (VC bundle) command priority command bandwidth, configuring

QC-124 QC-364

precedence (WRED group) command

flow-based WFQ
QC-230

QC-133, QC-140

information, displaying

QC-124, QC-139 QC-137

LLQ

QC-97, QC-132 QC-167 QC-166 QC-166 QC-166 QC-166

LLQ priority queue, configuring service policies, configuring VCs, attaching verifying
QC-363, QC-364 QC-230

priority-group command

QC-119

priority-list default command priority-list interface command priority-list protocol command

Policy Propagation via BGP access lists, using

QC-50 QC-49

priority-list queue-limit command priority lists, description priority queue prompts, system protect command
QC-246 QC-111

autonomous system paths, using community lists, using configuration (examples) configuring monitoring overview
QC-47 QC-50 QC-25 QC-48 QC-51

privileged EXEC mode, summary of

xxxvi QC-360 QC-358 QC-34

xxxvi

protocol (ATM) command Protocol Discovery, NBAR

QC-25

packet classification, methods

protocols

Cisco IOS Quality of Service Solutions Configuration Guide

QC-428

Index

queueing priority, assigning supported by NBAR pvc-bundle command

QC-36 QC-359

QC-161

class policies, configuring DWRED

QC-188 QC-364

QC-136

flow-based WFQ traffic classes

queue limit, modifying

QC-126

Q
QoS (quality of service) characteristics defined features classification
QC-5, QC-21 QC-11 QC-8, QC-79 QC-15 QC-1 QC-1 QC-1, QC-3

QC-404 QC-161 QC-161 QC-161 QC-160

queue-list default command queue-list interface command queue-list protocol command

queue-list queue byte-count command queue-list queue limit command queues, strict priority, reserving

end-to-end

QC-160 QC-132 QC-188, QC-189

queue sizes, exponential weight factor

congestion avoidance congestion management policing and shaping signalling for VPNs benefits
QC-29 QC-14

link efficiency mechanisms

QC-13

R
random-detect (interface) command
QC-364 QC-136, QC-191, QC-296

random-detect (per VC) command random-detect command

QC-71 QC-404

configuration (examples) configuring description restrictions verifying group value configuration (examples) configuring service models
QC-65 QC-69 QC-8 QC-30 QC-70

random-detect dscp command class policies DWRED WRED

QC-122

QC-191

random-detect exponential-weighting-constant command

QC-188, QC-189 QC-120, QC-187 QC-190 QC-190

random-detect flow command

QC-68

random-detect flow count command random-detect-group command

QC-415

QC-191, QC-356

SDM (Security Device Manager)

QC-3 QC-70 xxxvi

random-detect precedence command class-based DCAR policies, configuring DWRED WRED

QC-189 QC-120, QC-187 QC-56, QC-57, QC-58 QC-59

qos pre-classify command question mark (?) command queueing comparison

QC-81

rate-limit command rate limits, CAR

QC-82 QC-86

QC-204, QC-206 QC-245

comparison (table) methods, default per-VC

QC-352

real-time traffic

Real-Time Transport Protocol See RTP header compression RED (Random Early Detection) background how it works
QC-172 QC-172

strict priority

QC-10, QC-93, QC-97

See also CQ; FIFO; PQ; WFQ queue-limit command

Cisco IOS Quality of Service Solutions Configuration Guide

QC-429

Index

packet drop probability TCP

QC-173

RFC 1350, The TFTP Protocol (Revision 2) RFC 1436, The Internet Gopher Protocol
QC-172

QC-31

QC-31 QC-31

congestion control mechanism traffic loss strategy release notes See platforms, supported reservation See also RSVP reservation, configuring RFC full text, obtaining
xxx QC-277 QC-174

RFC 1459, Internet Relay Chat Protocol

RFC 1510, The Kerberos Network Authentication Service QC-31 RFC 1542, Clarifications and Extensions for the Bootstrap Protocol QC-32 RFC 1579, Firewall-Friendly FTP RFC 1583, OSPF Version 2
QC-32 QC-32

RFC 1657, Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol QC-32 RFC 1701, Generic Routing Encapsulation
QC-31 QC-31 QC-31 QC-32

RFC 724, NAME/FINGER Protocol RFC 759, Internet Message Protocol

RFC 1730, Internet Message Access Protocol - Version 4 QC-32 RFC 1771, A Border Gateway Protocol 4 (BGP-4) RFC 1777, Lightweight Directory Access Protocol
QC-32 QC-32

RFC 792, Internet Control Message Protocol RFC 793, Transmission Control Protocol RFC 821, Simple Mail Transfer Protocol RFC 827, Exterior Gateway Protocol RFC 854, Telnet Protocol Specification

QC-31 QC-31

QC-31 QC-31 QC-31

RFC 1831, Remote Procedure Call Protocol Specification Version 2 QC-32 RFC 1889, RTP
QC-316 QC-32 QC-32

RFC 888, STUB Exterior Gateway Protocol RFC 904, Exterior Gateway Protocol formal specification QC-31 RFC 951, Bootstrap Protocol
QC-31 QC-31

RFC 1928, SOCKS Protocol Version 5

RFC 1939, Post Office Protocol - Version 3 RFC 1945, Hypertext Transfer Protocol -HTTP/1.0 QC-32 RFC 1964, The Kerberos Version 5 GSS-API Mechanism QC-32

RFC 959, File Transfer Protocol

RFC 977, Network News Transfer Protocol

QC-31

RFC 1990, The PPP Multilink Protocol (MP)

QC-316

RFC 1001, Protocol Standard for a NetBIOS Service on a TCP/UDP Transport (Concepts and Methods) QC-31 RFC 1002, Protocol Standard for a NetBIOS Service on a TCP/UPD Transport (Detailed Specification) QC-31 RFC 1057, Remote Procedure Call
QC-31

RFC 2060, Internet Message Access Protocol - Version 4rev1 QC-32 RFC 2068, Hyptertext Transfer Protocol -HTTP/1.1 QC-32 RFC 2131, Dynamic Host Configuration Protocol RFC 2205, Resource Reservation Protocol
QC-253 QC-32 QC-32, QC-249,

RFC 1094, Network File System Protocol Specification QC-31 RFC 1112, Host Extension for IP multicasting
QC-31

RFC 2206, RSVP Management Information Base using SMIv2 QC-249 RFC 2210, RSVP with IETF Integrated Services
QC-249 QC-246,

RFC 1144, Compressing TCP/IP Headers for Low-Speed Serial Links QC-319 RFC 1144, TCP header compressions RFC 1282, BSD Rlogin
QC-31 QC-31 QC-318 QC-31

RFC 2211, Controlled-Load Network Element Service QC-249 RFC 2212, Specification of Guaranteed Quality of Service QC-249 RFC 2215, General Characterization Parameters for Integrated Service Network Elements QC-249

RFC 1157, Simple Network Management Protocol RFC 1288, The Finger User Information Protocol RFC 1305, Network Time Protocol
QC-31

Cisco IOS Quality of Service Solutions Configuration Guide

QC-430

Index

RFC 2236, Internet Group Management Protocol, Version 2 QC-32 RFC 2251, Lightweight Directory Access Protocol (v3) QC-32 RFC 2252, Lightweight Directory Access Protocol (v3) Attribute Syntax Definitions QC-32 RFC 2253, Lightweight Directory Access Protocol (v3) UTF-8 String Representation of Distinguished Names QC-32 RFC 2326, Real Time Steaming Protocol (RTSP) RFC 2401, Security Architecture for the Internet Protocol QC-32 RFC 2406, IP Encapsulating Security Payload RFC 2453, RIP Version 2
QC-32 QC-32 QC-32

configuring COPS configuring

QC-265

QC-303 QC-252, QC-303

feature description functionality verifying enabling

QC-305

QC-253

QC-265, QC-276, QC-294 QC-269

filters and bandwidth, displaying Frame Relay support configuration (example) configuring described monitoring verifying how it works
QC-281 QC-264 QC-287

considerations

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers QC-26,
QC-182, QC-376

QC-247 QC-287 QC-285 QC-245 QC-264 QC-268, QC-269, QC-297

RFC 2475, An Architecture for Differentiated Services Framework QC-26, QC-182, QC-376 RFC 2507, IP Header Compression
QC-319

implementation considerations interface information, displaying LAN resource support multicast destinations, specifying
QC-26, QC-182, QC-258

RFC 2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links QC-319 RFC 2597, Assured Forwarding PHB
QC-376 QC-26, QC-182,

QC-267 QC-269

RFC 2598, An Expedited Forwarding PHB

QC-376

session, configuration (example) neighbor reservations, limiting neighbors, displaying

QC-269

RFC 2616, Hypertext Transfer Protocol -HTTP/1.1 QC-32 RFC 2697, A Single Rate Three Color Marker
QC-376 QC-209,

QC-267

overview planning

QC-244 QC-263 QC-262 QC-269

RFC 2748, The COPS Protocol ROM monitor mode, summary of route-map (IP) command route maps defining PBR
QC-44 QC-24 QC-48

QC-253 QC-253 xxxvi

real-time traffic problems RED, relationship with SBM, configuring scalability

QC-244

RFC 2749, COPS Usage for RSVP

receiver information, displaying

QC-262

QC-44, QC-48

request information, displaying

QC-308

QC-269

sender information, displaying Shared Explicit reservation traps, enabling uses

QC-87 QC-268

QC-269

router bgp command ATM considerations bandwidth considerations restricting

QC-263

RSVP (Resource Reservation Protocol)

QC-265

WFQ, relationship with

QC-263

QC-87, QC-262

Wild Card Filter WRED

QC-175

QC-263

QC-294

Cisco IOS Quality of Service Solutions Configuration Guide

QC-431

Index

RSVP-ATM QoS Interworking feature configuration (example) data path

QC-251 QC-251 QC-297 QC-251

configuration (example) configuring overview restrictions

QC-310

QC-275, QC-303, QC-307 QC-309

connection over ATM cloud (figure) example scenario configuring setting monitoring overview

interface information, displaying

QC-258 QC-308 QC-258

prerequisites

IP Precedence value
QC-268 QC-250 QC-297 QC-267

SBM state configuration, verifying See also DSBM SDM (Security Device Manager) service models, end-to-end best-effort service
QC-296 QC-4 QC-4

QC-309

QC-415

NetFlow attachment peak rate limit, setting prerequisites restrictions RSVP

QC-293 QC-293

QC-249, QC-293 QC-296

differentiated service integrated service service policies attaching

per-VC DWRED, configuring

QC-4

QC-363, QC-364 QC-122, QC-363 QC-124 QC-144 QC-124, QC-139, QC-230 QC-139

CBWFQ, enabling
QC-294

bandwidth, restricting enabling

QC-294 QC-250

classes, deleting

configuration (example) information, displaying

QC-268

ToS bits, setting

ToS value, configuring RTP header compression configuration (example) connections supported enabling express
QC-338 QC-318

LLQ, enabling for Frame Relay service-policy command CBWFQ GTS NBAR
QC-122, QC-363

QC-339 QC-339, QC-342

QC-230 QC-139

LLQ for Frame Relay

QC-73

Frame Relay encapsulation, using statistics, displaying how it works (figure) passive
QC-338 QC-342, QC-343 QC-338 QC-339 QC-317

policy maps, attaching traffic policies DTS WFQ

QC-238

QC-192

interfaces, attaching
QC-364, QC-365

QC-405

PPP encapsulation (example) prerequisites RTP header

QC-338 QC-317 QC-339

service-policy input command service-policy output command set atm-clp command set cos command
QC-66 QC-65

QC-75, QC-405 QC-75, QC-405

statistics, displaying See also CRTP

set default interface command set interface command

QC-44

QC-44

S
SBM (Subnetwork Bandwidth Manager)
Cisco IOS Quality of Service Solutions Configuration Guide

set ip default next-hop command set ip dscp command set ip next-hop command
QC-44

QC-44

QC-64, QC-405

QC-432

Index

set ip precedence command DSCP value, configuring PBR

QC-44 QC-48 QC-65, QC-66, QC-405 QC-64 QC-64

show ip rsvp policy cops command show ip rsvp request command show ip rsvp sbm command show ip rsvp sender command show policy class command show policy command show ip rsvp reservation command
QC-309

QC-305

QC-269 QC-269

IP Precedence value, configuring policy propagation shape command

QC-269 QC-339

set qos-group command

show ip rtp header-compression command

QC-230 QC-230, QC-239

QC-230, QC-238 QC-230

shape max-buffers command shaping, token bucket

QC-204

show policy interface command

QC-263

QC-135, QC-230 QC-124

Shared Explicit reservation, RSVP show access-lists command show atm bundle command show atm map command show class-map command show cops servers command
QC-59

show policy-map class command show policy-map command class-based packet marking DCBWFQ
QC-126 QC-189 QC-140

show access-lists rate-limit command

QC-362

QC-59

QC-66

show atm bundle statistics command

QC-362

QC-362

DWRED NBAR traffic classes policing

LLQ burst size

QC-75

QC-75, QC-406 QC-305

policy maps

QC-124

show frame-relay ip rtp header-compression command QC-339 show frame relay pvc command show interface command show interfaces command
QC-239 QC-117, QC-161 QC-115, QC-117 QC-59 QC-129

QC-406 QC-221

show policy-map interface command class-based packet marking DCBWFQ DWRED

QC-50 QC-126 QC-192 QC-66

show interfaces fair-queue command show interfaces rate-limit command show ip bgp command
QC-50

DSCP value, configuration, verifying

QC-189

show ip bgp community-list command show ip cache policy command show ip cef command
QC-50 QC-50 QC-45 QC-76 QC-45

LLQ burst size, verifying monitoring NBAR traffic

QC-75 QC-124 QC-133 QC-140

show ip interface command

show ip local policy command show ip nbar port-map command show ip route command show ip rsvp command
QC-50

policy maps
QC-76

show ip nbar protocol-discovery command show ip rsvp atm-peak-rate-limit command

QC-297

classes policing

QC-406 QC-220, QC-221 QC-323

QC-297

show ppp multilink

show queue command

QC-269, QC-278 QC-269, QC-297 QC-269

show ip rsvp installed command show ip rsvp interface command show ip rsvp neighbor command show ip rsvp policy command

CQ lists, monitoring

QC-161 QC-115 QC-129

fair queueing, monitoring LLQ, monitoring

QC-133

Frame Relay IP RTP Priority, verifying

QC-305

Cisco IOS Quality of Service Solutions Configuration Guide

QC-433

Index

policy maps and classes, verifying configuration QC-124 PQ lists, monitoring

QC-167 QC-187

T
Tab key, command completion table-map command tail drops, defined
QC-171 xxxvi

WRED and DWRED, monitoring show queueing command CQ lists, monitoring PQ lists, monitoring
QC-161 QC-115

QC-48, QC-50

TCP (Transmission Control Protocol) header compression connections supported described

QC-187 QC-318 QC-342

fair queueing, monitoring

QC-167

WRED and DWRED, monitoring WRED parameters, displaying show queueing interface command

token buckets burst size CAR

QC-204 QC-205 QC-206 QC-208

QC-356

DSCP value configuration, verifying

QC-192 QC-141

compounded debt defined mean rate

QC-204

per-VC hold queue, verifying configuration per-VC WFQ and CBWFQ, monitoring queueing statistics, displaying show traffic-shape command
QC-356 QC-187

conform and exceed actions extended burst size

QC-204 QC-206

QC-365

WRED and DWRED, monitoring

QC-225

RSVP-ATM QoS Interworking feature

QC-129 QC-225

QC-251

show traffic-shape queue command signaling defined

QC-243 QC-243

time interval

QC-204

show traffic-shape statistics command

ToS (type of service) bit values, displaying CAR, rate limiting

QC-297 QC-205

differentiated QoS guaranteed QoS in-band RSVP SBM

QC-243 QC-243

ToS (type of service) field defined (figure) signalling traffic classes

QC-249 QC-244 QC-250

QC-243

RSVP-ATM QoS Interworking feature

QC-243

out-of-band

QC-244

RSVP-ATM QoS Interworking feature

QC-258 QC-14

configuration (example) creating defining

QC-237 QC-401

QC-147

summary

snmp-server enable traps command static maps, ATM, displaying strict priority queueing

QC-268

NBAR, configuring with traffic policer, defined traffic policies attaching (examples) configuring creating DTS
QC-238 QC-75

QC-76 QC-33

QC-362

traffic classification, with NBAR

QC-21

QC-10, QC-93, QC-97

SVCs (switched virtual circuits) creating for RSVP reservations peak rate limit, setting
QC-296 QC-249 QC-294

QC-148 QC-188

bandwidth, configuring
QC-148, QC-403

RSVP-ATM reservations

DTS, attaching and enabling

Cisco IOS Quality of Service Solutions Configuration Guide

QC-238

QC-434

Index

DWRED

QC-188, QC-189 QC-188

U
ubr+ command ubr command
QC-360 QC-360 xxxvi

hashed queues, configuring interfaces, attaching IP Precedence, specifying See also service policies traffic policing benefits
QC-210

QC-75, QC-405 QC-189

user EXEC mode, summary of

configuration, verifying configuring prerequisites restrictions

QC-219 QC-210 QC-210

QC-220, QC-221

V
vbr-nrt command VC bundle
QC-360

VC classes, assignment
QC-358 QC-360 QC-141 QC-113

traffic priority management, WFQ traffic regulation mechanisms policing, CAR rate limiting traffic shaping FRTS GTS
QC-203 QC-203

VC bundle member VCs (virtual circuits)

vc-hold-queue command
QC-203

ATM, circuit bumping bundles See ATM VC bundles

QC-224 QC-224

QC-353

traffic-shape adaptive command traffic-shape fecn-adapt command traffic-shape group command traffic-shape rate command traffic shaping defined
QC-203, QC-211

VIP-distributed CAR See DCAR VIP-distributed WRED See DWRED virtual template interfaces IP RTP Priority, configuration (examples) LLQ, configuration (examples)
QC-153 QC-149

QC-224 QC-224

Distributed benefits
QC-216 QC-237 QC-217 QC-217 QC-212 QC-14

configuring prerequisites restrictions

Voice over Frame Relay, Frame Relay fragmentation methods QC-316 Voice over IP, strict priority queueing voice traffic, requirements
QC-245 QC-10, QC-93, QC-97

excess burst size feature summary FRTS GTS

QC-217 QC-214 QC-214

W
WFQ (weighted fair queueing) class-based See CBWFQ comparison (table) configuring
QC-114 QC-86 QC-86 QC-115 QC-83

queueing uses

rate of transfer
QC-211

QC-212

See also GTS tx-ring-limit command

QC-101

considerations

default queueing method

effect of custom queueing on

Cisco IOS Quality of Service Solutions Configuration Guide

QC-435

Index

effect of priority queueing on enabling flow-based configuration (example) overview flows high-bandwidth traffic low-bandwidth traffic Frame Relay IP Precedence monitoring overview per-VC classes of service supported configuring restrictions RSVP
QC-364 QC-87 QC-85 QC-84 QC-276, QC-364, QC-365

QC-115

effect on packet flows

QC-356

QC-181 QC-120, QC-122,

exponential weight factor, configuring IP Precedence overview packet drop parameters defining displaying restrictions RSVP TCP uses
QC-363 QC-176 QC-175 QC-349 QC-356 QC-356 QC-177 QC-175

QC-141

QC-172, QC-175 QC-175

QC-85 QC-85

how it works (figure)

QC-86 QC-115 QC-83

platform support
QC-175

QC-185

VC bundles

policy maps, attaching to VCs

QC-86 QC-87

QC-365

service policies, attaching strict priority queueing types uses

QC-79 QC-86

QC-365

QC-94 QC-113

traffic priority management

See also CBWFQ; DCBWFQ Wild Card Filter, RSVP average queue size behavior
QC-175 QC-192 QC-186 QC-263

WRED (Weighted Random Early Detection)

QC-176

configuration (example) DiffServ compliance configuring verifying DSCP value configuration (example) configuring verifying
QC-190 QC-192

congestion avoidance mechanism

QC-183, QC-190 QC-183

usage scenarios
QC-192

QC-198

Cisco IOS Quality of Service Solutions Configuration Guide

QC-436