Qoscf PDF

Cisco 10000 Series Router Quality of
Service Configuration Guide

February 25, 2013
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
Text Part Number: OL-7433-09
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.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this
URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned 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. (1110R)
Cisco 10000 Series Router Quality of Service Configuration Guide
Copyright 2007-2009, Cisco Systems, Inc. All rights reserved.
CONTENTS
About This Guide
xxxv
Guide Revision History

Audience
xxxv
xl
Document Organization
xl
Document Conventions
xlii
Related Documentation
xliii
Obtaining Documentation and Submitting a Service Request
CHAPTER
Quality of Service Overview
xliii
1-1
Benefits of Quality of Service Features
1-2
Restrictions and Limitations for Quality of Service
1-2
Modular QoS Command-Line Interface 1-2

Feature History for MQC 1-3
QoS CLI Migration from PRE2 to PRE3 1-3
Feature History for QoS CLI Migration from PRE2 to PRE3
QoS Management Information Base Support
QoS Implementation Guidelines
QoS Execution on the Router
1-4
1-4
1-4
1-4
QoS Configuration on an Interface
1-5
QoS Models 1-6

Overview of QoS Models 1-6
Model D.2 Definition 1-7
Model F Definition 1-7
Configuration Tasks 1-8
Configuration Steps on Subinterfaces for QoS Model D.2 1-8
Configuration Steps on Sessions for QoS Model D.2 1-8
Configuration Steps for QoS Model F 1-9
Configuration Examples 1-9
QoS Features, Commands, and Changes 1-11
Applying QoS Parameters Dynamically to Sessions 1-12
Applying Traffic Shaping Parameters Using RADIUS Profiles
dbs enable Command 1-12
default dbs enable Command 1-12
1-12

OL-7433-09
iii
Contents
Dynamic Bandwidth Selection Feature 1-13

Attaching QoS Service Policies 1-13
service-policy Command 1-13
Attaching ATM QoS Service Policies 1-14
Attaching Frame Relay QoS Service Policies 1-14
Attaching LAC QoS Service Policies 1-15
Attaching Virtual LAN QoS Service Policies 1-15
Attaching Virtual Access Interface QoS Service Policies 1-15
Classifying Traffic 1-15
class-map Command 1-15
match Commands 1-16
Class Map Feature 1-18
Configuring QoS for MPLS Traffic 1-18
MPLS CoS Multi-VC Mode 1-18
MPLS QoS Feature 1-19
MPLS Traffic EngineeringDiffServ Aware Feature 1-19
Control Plane Policing 1-19
Divert Cause Policer 1-19
Control Plane PolicingPlatform Enhancement 1-20
Controlling Packet Queue Congestion 1-21
queue-limit Command 1-21
random-detect Command 1-22
random-detect basis Command 1-23
show pxf cpu queue interface summary 1-23
Tail Drop Feature 1-23
Random Early Detection Feature 1-24
Weighted Random Early Detection Feature 1-24
Distributing Bandwidth Between Queues 1-25
bandwidth Command 1-25
bandwidth remaining ratio Command 1-26
Distribution of Remaining Bandwidth Using Ratio 1-26
Dynamically Changing VC Weight and Watermark Values 1-26
Hierarchical Queuing Framework 1-27
Hierarchical Queuing Framework Feature 1-27
MQC Hierarchical Queuing with 3 Level Scheduler 1-27
Hierarchical Policies 1-27
Nested Hierarchical Policies 1-27
Three-Level Hierarchical Policies 1-28
Hierarchical Input Policing 1-28
IP Quality of Service for Subscribers 1-29
iv
OL-7433-09
Contents
MQC Support for IP Sessions 1-29

Per-Session Shaping for ATM Interfaces 1-29
Per Session Rate Limiting 1-29
Per User Multiservice Rate Limiting 1-29
Per Session Service Policy Using RADIUS 1-30
Per Session Shaping and Queuing on LNS 1-30
PPP Session Queuing on ATM VCs 1-30
Layer 2 Access Concentrator 1-30
Classification, Policing, and Marking on the LAC 1-30
LAC QoS 1-30
Link Fragmentation and Interleaving 1-31
interface multilink Command 1-31
multilink group Command 1-31
ppp multilink Command 1-32
ppp multilink fragment-delay Command 1-32
ppp multilink fragmentation Command 1-33
ppp multilink fragment disable Command 1-33
ppp multilink group Command 1-33
ppp multilink interleave Command 1-34
MLP Over ATM-Based LFI Feature 1-34
Multi-VC MLP Over ATM-Based LFI Feature 1-34
MLP Over Frame Relay-Based LFI Feature 1-35
MLP Over Serial-Based LFI Feature 1-35
FRF.12 Fragmentation Feature 1-35
Marking Traffic 1-36
set atm-clp Command 1-36
set cos Command 1-36
set discard-class Command 1-36
set fr-de Command 1-37
set ip dscp Command 1-37
set ip precedence Command 1-37
set mpls experimental Command 1-37
set mpls experimental imposition Command 1-38
set qos-group Command 1-38
Marking Feature 1-38
Modular QoS Command Line Interface 1-39
MQC Feature 1-39
QoS CLI Migration from PRE2 to PRE3 1-39
Overhead Accounting 1-39
ATM Overhead Accounting 1-40
OL-7433-09
Contents
Ethernet Overhead Accounting 1-40

Traffic Shaping Overhead Accounting for ATM 1-40
Oversubscribing Physical and Virtual Links 1-41
atm over-subscription-factor Command 1-41
Interface Oversubscription Feature 1-41
ATM Virtual Circuit Oversubscription Feature 1-42
map-class frame-relay Command 1-42
Frame Relay PVC Oversubscription Feature 1-42
Virtual LAN Oversubscription Feature 1-43
queue-depth Command 1-43
weight Command 1-43
Weighting Feature 1-44
Policing Traffic 1-44
police Command (Single-Rate) 1-44
police percent Command 1-45
police Command (Two-Rate) 1-45
show atm vp Command 1-46
Percent-Based Policing Feature 1-46
Policing Feature 1-46
Single-Rate Color Marker Feature 1-47
Two-Rate Three-Color Marker Feature 1-47
ATM VP Average Traffic Rate 1-48
Prioritizing Traffic 1-48
priority Command 1-48
priority level Command 1-49
Child Service Policy Allowed Under Priority Class 1-49
Multi-Level Priority Queues 1-49
Priority Queuing Feature 1-49
PVC Bundles 1-50
bump Command 1-50
bump Command (Frame Relay VC-bundle-member) 1-51
bundle Command 1-51
class-bundle Command 1-51
class-vc Command 1-51
dscp Command (Frame Relay VC-bundle-member) 1-51
exp Command 1-51
frame-relay vc-bundle Command 1-51
mpls experimental Command 1-52
oam-bundle Command 1-52
precedence Command 1-52
vi
OL-7433-09
Contents
precedence Command (Frame Relay VC-bundle-member) 1-52

protect Command 1-52
protect Command (Frame Relay VC-bundle-member) 1-52
pvc-bundle Command 1-53
pvc Command (Frame Relay VC-bundle) 1-53
PVC Bundles Over ATM and Frame Relay Feature 1-53
ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection Feature 1-53
Frame Relay PVC Bundles with QoS Support for IP and MPLS Feature 1-53
QoS Policy Maps 1-53
policy-map Command 1-54
qos match statistics Command 1-54
Policy Maps Feature 1-54
Policy Map Scaling Phase 2 1-54
Qos Policy Propagation through the Border Gateway Protocol 1-55
Shaping PPPoE Over VLAN Sessions Using RADIUS 1-55
Per Session Queuing and Shaping for PPPoE Over VLAN Support Using RADIUS Feature
Shaping Traffic 1-55
atm pvp Command 1-56
pvc Command 1-56
shape Command 1-56
shape percent Command 1-57
vbr-nrt Command 1-57
ATM VC/VP Shaping Feature 1-57
Class-Based Traffic Shaping Feature 1-58
Frame Relay Traffic Shaping Feature 1-58
Hierarchical Shaping Feature 1-58
Percentage-Based Traffic Shaping Feature 1-58
Traffic Shaping Overhead Accounting for ATM Feature 1-59
Sharing Bandwidth Fairly During Congestion 1-59
Bandwidth Fair Queuing Feature 1-59
Class-Based Weighted Fair Queuing Feature 1-59
Class-Based Weighted Fair Queuing for Virtual Access Interfaces Feature 1-60
Simultaneous Policy Maps 1-60
Simultaneous QoS Policy Map on Interface and PPP SessionA-DSLAM Case 1-60
VLAN Tag-Based Quality of Service 1-60
CHAPTER
Classifying Traffic
1-55
1-61
2-1
Traffic Classification Using Class Maps
2-1

OL-7433-09
vii
Contents
Feature History for Class Maps 2-2

System Limits for Class Maps 2-2
PRE3 Class Maps and QoS Scalability 2-3
class-map Command 2-3
Syntax Description 2-4
class-map Command History 2-4
Usage Guidelines for the class-map Command 2-4
qos match statistics Command 2-4
Command Default 2-5
qos match statistics Command History 2-5
Usage Guidelines for the qos match statistics Command
Defining Match Criteria Using the match Commands 2-5
match Commands History 2-9
Usage Guidelines for match Commands 2-10
Class-Default Class 2-11
Restrictions and Limitations for Traffic Classification
2-11
Classifying Traffic Using a Class Map 2-11

Creating a Class Map 2-12
Configuration Examples for Classifying Traffic
Verifying Traffic Classification 2-13
Verification Example 2-13
Defining QoS Policy Actions 2-13
CHAPTER
2-5
2-12
2-14
Configuring QoS Policy Actions and Rules
3-1
QoS Policies 3-1

Feature History for QoS Policies 3-2
Defining QoS Actions Using a Policy Map 3-2
System Limits for Policy Maps 3-2
8K Policy Maps 3-3
policy-map Command 3-3
Usage Guidelines for the policy-map Command
3-4
Types of QoS Actions 3-4

Input and Output Policy Actions 3-4
Policy Map ActionsReleases Prior to Cisco IOS Release 12.0(17)SL 3-7
Policy Map ActionsCisco IOS Release 12.0(17)SL and Later Releases 3-10
Policy Map ActionsCisco IOS Release 12.0(20)ST and Later Releases 3-10
viii
OL-7433-09
Contents
Policy Map ActionsCisco IOS Release 12.0(22)S and Later Releases 3-11
Policy Map ActionsCisco IOS Release 12.2(31)SB2 and Later Releases 3-11
Policing Actions
3-11
QoS Inheritance 3-12

ATM Service Categories 3-13
Constant Bit Rate 3-13
Unspecified Bit Rate 3-14
Variable Bit Rate 3-15
Traffic Subject to QoS Policies
3-17
ATM Virtual Circuits Without QoS Policies

QoS Performance
3-17
3-18
Configuring QoS Policies 3-18

Creating a Policy Map 3-19
Configuration Examples for Creating a Policy Map
Defining QoS Actions in a Policy Map 3-20
Attaching Service Policies 3-20
Verifying QoS Policy Configurations 3-20
Verification Example for Service Policies
CHAPTER
Attaching Service Policies
3-19
3-22
3-23
4-1
Interfaces Supporting QoS Service Policies
4-1
Attaching ATM QoS Service Policies 4-2

Feature History for ATM QoS 4-2
ATM QoS Inheritance 4-2
service-policy Command History 4-3
service-policy Command Modes 4-4
Usage Guidelines for the service-policy Command 4-4
Restrictions and Limitations for Attaching ATM Service Policies 4-5
Attaching ATM QoS Service Policies to ATM Interfaces, Subinterfaces, and PVCs 4-5
Attaching QoS Service Policies to an ATM Interface 4-6
Attaching QoS Service Policies to an ATM Point-to-Point Subinterface 4-7
Attaching QoS Service Policies to an ATM PVC 4-8
Attaching QoS Service Policies to an ATM PVC Range and an ATM PVC in a Range
4-9
Attaching Frame Relay QoS Service Policies 4-11

Feature History for Frame Relay QoS 4-12

OL-7433-09
ix
Contents
Frame Relay QoS Inheritance 4-12

map-class frame-relay Command 4-12
map-class frame-relay Command History 4-13
Usage Guidelines for the map-class frame-relay Command 4-13
Restrictions and Limitations for Frame Relay QoS Service Policies 4-13
Creating and Attaching QoS Policies to Frame Relay Interfaces, Subinterfaces, and Data-Link
Connection Identifiers 4-14
Attaching a QoS Service Policy to a Frame Relay Interface or Point-to-Point Subinterface
Attaching a QoS Service Policy to a Frame Relay DLCI 4-17
4-14
Attaching Virtual LAN QoS Service Policies 4-20

Feature History for VLAN QoS 4-20
VLAN QoS Inheritance 4-21
Restrictions and Limitations for Attaching QoS Services to VLAN Subinterfaces 4-21
Attaching QoS Policies to VLAN Interfaces and Subinterfaces 4-21
Attaching QoS Service Policies to Physical Interfaces with VLAN Subinterfaces 4-22
Attaching QoS Service Policies to VLAN Subinterfaces 4-23
Attaching Virtual Access Interface QoS Service Policies 4-23
Feature History for VAI QoS 4-24
VAI QoS Inheritance 4-24
Restrictions and Limitations for Attaching QoS Services to a VAI 4-25
Attaching QoS Policies to VAIs Using Virtual Template Interfaces 4-25
Applying a QoS Service Policy to a Virtual Template Interface 4-26
Applying a Virtual Template Interface to a BBA Group 4-27
Attaching a BBA Group to an Interface or Subinterface for PPPoE Sessions
4-28
Attaching Layer 2 Access Concentrator QoS Service Policies 4-30

Feature History for LAC QoS 4-30
LAC QoS Inheritance 4-30
Restrictions and Limitations for Attaching LAC QoS 4-31
Attaching QoS Policies to LAC ATM Virtual Circuits 4-31
Applying QoS on Layer 2 Tunnel Packets
4-32
Verifying and Monitoring QoS Service Policies 4-32

Verification Example for QoS Service Policies 4-34
CHAPTER
4-36
Distributing Bandwidth Between Queues
5-1
Bandwidth Distribution Between Queues 5-1

Feature History for Bandwidth Distribution Between Queues
Interfaces Supporting Bandwidth Distribution 5-2
5-2
OL-7433-09
Contents
Unused Bandwidth Allocation 5-3

Traffic Classes That Can Use Excess Bandwidth 5-3
Bandwidth Calculations 5-4
Bandwidth Allocation to PVCs 5-5
Class-Default Bandwidth Guarantee 5-6
Committed Rate Data 5-6
Bandwidth and Priority Service 5-7
Queuing Modes 5-8
Restrictions and Limitations for Bandwidth Distribution 5-9
Configuring Bandwidth Distribution Between Queues 5-10
Configuration Examples for Configuring Bandwidth Distribution 5-10
Configuration Example for Kilobits per Second-Based Bandwidth 5-11
Configuration Example for Percentage-Based Bandwidth 5-11
Configuration Example for Bandwidth-Remaining-Based Bandwidth 5-11
Verifying and Monitoring Bandwidth Distribution 5-12
Verification Example for Bandwidth Distribution 5-13
Distribution of Remaining Bandwidth Using Ratio 5-14
Feature History for Bandwidth-Remaining Ratios 5-14
Bandwidth-Remaining Ratio 5-14
Prerequisites for Distribution of Remaining Bandwidth Using Ratio 5-15
Restrictions for Distribution of Remaining Bandwidth Using Ratio 5-15
Configuring Bandwidth-Remaining Ratios 5-15
Configuring and Applying Bandwidth-Remaining Ratios to Subinterfaces 5-16
Configuring and Applying Bandwidth-Remaining Ratios to Class Queues 5-18
Configuration Examples for Distribution of Remaining Bandwidth Using Ratio 5-20
Configuring Bandwidth-Remaining Ratios on Ethernet Subinterfaces: Example 5-21
Configuring Bandwidth-Remaining Ratios on ATM Subinterfaces: Example 5-21
Configuring Bandwidth-Remaining Ratios on Class Queues: Example 5-22
Verifying Bandwidth Remaining Ratios: Example 5-22
CHAPTER
Policing Traffic
5-26
6-1
Traffic Policing 6-2

Feature History for Traffic Policing
Policing Actions 6-3
6-2
Single-Rate Color Marker for Traffic Policing 6-4

Feature History for the Single-Rate Color Marker 6-5
Configuration Commands for the Single-Rate Color Marker
police Command (Single-Rate) 6-6
6-5

OL-7433-09
xi
Contents
Two-Rate Three-Color Marker for Traffic Policing 6-8

Feature History for the Two-Rate Color Marker 6-9
Configuration Commands for the Two-Rate Color Marker
police Command (Two-Rate) 6-9
Percent-Based Policing 6-11
Feature History for Percent-Based Policing
police percent Command 6-11
Control Plane Policing
6-9
6-11
6-13
AToM Set ATM CLP Bit Using a Policer 6-13

Feature History for Set ATM CLP Bit Marking As a Police Action
AToM Set FR DE as Police Action 6-14
Feature History for AToM Set FR DE as Police Action
6-14
Set Layer 2 CoS as a Policer Action 6-15

Feature History for Set Layer 2 CoS as Policer Action
6-15
Set Inner CoS as a Policer Action 6-15

Feature History for Set Inner CoS as a Policer Action
6-15
Set Inner and Outer CoS as a Policer Action 6-16

Feature History for Set Inner and Outer CoS as a Policer Action
Dual Police Actions 6-16
Feature History for Dual Police Actions
Policing Support for GRE Tunnels
Interfaces Supporting Policing
6-14
6-16
6-17
6-17
6-17
Metering Traffic and Token Buckets 6-18

Metering Traffic Using Token Buckets (Single-Rate Policer) 6-18
Metering Traffic Using Token Buckets (Two-Rate Policer) 6-19
Committed Bursts and Excess Bursts 6-21
Committed Bursts 6-21
Committed Burst Calculation 6-22
Excess Bursts 6-22
Excess Burst Calculation 6-22
Deciding if Packets Conform or Exceed the Committed Rate
Data Included in the Policing Rate
Policing Rate Granularity
6-23
6-23
6-25
Avoiding Bandwidth Starvation Due to Priority Services

Bandwidth and Policing 6-26
Restrictions and Limitations for Traffic Policing
6-25
6-26
Configuring Traffic Policing 6-27

Configuring Single-Rate Traffic Policing Based on Bits per Second
6-28
xii
OL-7433-09
Contents
Configuration Examples for Configuring Single-Rate Traffic Policing Based on Bits per
Second 6-28
Configuring Percent-Based Policing 6-32
Configuration Examples for Configuring Percent-Based Policing 6-32
Configuring Two-Rate Policing 6-35
Configuration Example for Configuring Two-Rate Three-Color Policing 6-35
Marking Traffic Using Police Actions 6-36
Configuration Example for Marking Traffic Using Police Actions 6-36
Configuring Dual Police Actions 6-37
Configuration Example for Configuring Dual Police Actions 6-37
Configuration Example for Dual Actionsset-clp-transmit and set-mpls-exp-transmit
Configuration Example for Dual Actionsset-frde-transmit and
set-mpls-exp-imposition-transmit 6-39
Configuration Example of the set-cos-transmit Police Action 6-40
Verifying and Monitoring Traffic Policing 6-41
Verification Examples for Traffic Policing 6-41
Verifying Policing for a Specific Traffic Class 6-42
Verifying Policing on a Specific Interface 6-42
Verifying Dual Police Actionsset-clp-transmit and set-mpls-exp-transmit
CHAPTER
Marking Traffic
6-38
6-43
6-43
7-1
QoS Packet Marking 7-2

Feature History for QoS Packet Marking
Benefits of QoS Packet Marking 7-3
7-3
IP Precedence Marking 7-4

IP Precedence-Based Weighted Random Early Detection 7-4
set ip precedence Command 7-5
set ip precedence Command History 7-5
Usage Guidelines for the set ip precedence Command 7-5
IP Differentiated Services Code Point Marking 7-6
DSCP Per-Hop Behavior 7-6
Assured Forwarding 7-7
Expedited Forwarding 7-7
Class Selector Code Points 7-7
DSCP Values 7-8
DSCP-Based Weighted Random Early Detection
7-9

OL-7433-09
xiii
Contents
set ip dscp Command 7-9

set ip dscp Command History 7-10
Usage Guidelines for the set ip dscp Command
Class of Service Marking 7-10
QinQ Class of Service Marking 7-12
set cos Command 7-12
set cos Command History 7-12
Usage Guidelines for the set cos Command
7-10
7-12
QoS Group Marking 7-13

set qos-group Command 7-13
set qos-group Command History 7-13
Usage Guidelines for the set qos-group Command
ATM Cell Loss Priority Marking 7-14
set atm-clp Command 7-14
set atm-clp Command History 7-14
Usage Guidelines for the set atm-clp Command
7-13
7-14
MPLS Experimental Marking 7-14

QinQ MPLS Experimental Marking 7-15
set mpls experimental imposition Command 7-15
set mpls experimental imposition Command History 7-15
Usage Guidelines for the set mpls experimental imposition Command
Discard-Class Marking 7-16
set discard-class Command 7-16
set discard-class Command History 7-16
Usage Guidelines for the set discard-class Command
7-17
Class-Based Frame Relay DE Bit Marking 7-17

History for the Class-Based Frame Relay DE Bit Marking Feature
Marking and Policing Traffic
7-17
7-18
Tunnel Header Marking 7-18

Feature History for Tunnel Header Marking
Restrictions and Limitations for Marking
Interfaces Supporting Marking
7-16
7-19
7-19
7-20
Classification and Marking Design Guidelines
7-21
xiv
OL-7433-09
Contents
Recommended Values for Traffic Marking
7-21
Configuring Traffic Marking 7-22

Configuring IP Precedence Marking 7-22
Configuration Examples for IP Precedence Marking and Classification 7-23
Configuring IP DSCP Marking 7-24
Configuration Examples for IP DSCP Marking and Classification 7-25
Configuring Class of Service Marking 7-26
Configuration Examples for CoS Marking and Classification 7-27
Configuring QoS Group Marking 7-28
Configuration Examples for Configuring QoS Group Marking and Classification 7-28
Setting the ATM Cell Loss Priority Bit 7-29
Configuration Example for Setting the ATM CLP Bit 7-30
Configuring MPLS Experimental Marking 7-31
Configuration Examples for Configuring MPLS Experimental Marking and Classification 7-32
Configuring Discard-Class Marking 7-33
Configuration Examples for Configuring Discard-Class Marking and Classification 7-34
Configuring Tunnel Header Marking Using the set Command 7-35
Configuration Example for Tunnel Header Marking Using the set Command 7-35
Configuring Tunnel Header Marking Using the police Command 7-36
Example Configuration for Tunnel Header Marking Using the police Command 7-36
Verifying Traffic Marking 7-37
Verification Examples for Traffic Marking
CHAPTER
Prioritizing Services
7-38
7-39
8-1
Low-Latency Priority Queuing 8-1

Feature History for Low-Latency Priority Queuing
Bandwidth Starvation 8-3
Multi-Level Priority Queues 8-3
Feature History for Multi-Level Priority Queues
Child Service Policy Allowed Under Priority Class
Interfaces Supporting Priority Queuing
Queues per Policy Map
8-2
8-4
8-4
8-4
8-5
Restrictions and Limitations for Priority Queuing

Restrictions for Multi-Level Priority Queues
Configuring a Priority Queue
8-5
8-5
8-6
Configuring Multi-Level Priority Queues
8-7
Configuration Examples for Configuring Priority Queues
8-9

OL-7433-09
xv
Contents
Configuring a Priority Queue with a Guaranteed Bandwidth Based on Kilobits per Second:
Example 8-9
Configuring a Priority Queue with a Percent-Based Bandwidth Guarantee: Example 8-9
Configuring Multi-Level Priority Queues: Example 8-10
Unacceptable MPQ Configurations: Examples 8-10
Verifying and Monitoring Priority Queues
8-11
Verification Examples for Priority Queues 8-11

Verifying a Priority Queue: Example 8-11
Verifying Multi-Level Priority Queues: Example
CHAPTER
Shaping Traffic
8-12
8-13
9-1
Traffic Shaping 9-2

Feature History for Traffic Shaping 9-3
Class-Based Traffic Shaping 9-3
Feature History for Class-Based Traffic Shaping 9-4
System Limits for Class-Based Shaping 9-4
Restrictions and Limitations for Class-Based Shaping 9-4
Hierarchical Shaping 9-4
Feature History for Hierarchical Shaping 9-5
VP-Level Shaping 9-5
VC-Level Shaping 9-5
Shaped UBR PVCs 9-5
How Hierarchical Shaping Works 9-6
Hierarchical Shaping and Oversubscription 9-7
Active ATM VCs 9-7
Restrictions and Limitations for Hierarchical Shaping 9-8
Percentage-Based Traffic Shaping 9-8
History for the Percentage-Based Shaping Feature 9-8
Frame Relay Traffic Shaping 9-8
Feature History for Frame Relay Traffic Shaping 9-9
Restrictions and Limitations for Frame Relay Traffic Shaping
Configuration Commands for Traffic Shaping 9-9
Differences Between Traffic Shaping Mechanisms
Bandwidth and Traffic Shaping
9-9
9-10
9-10
Differences Between Shaping and Policing
9-11
Advantages and Disadvantages of Shaping and Policing for Bandwidth Limiting

Modifying the VC Weight and the VP Shaping Parameters
Example Scenarios of Traffic Shaping Usage
9-11
9-12
9-12
xvi
OL-7433-09
Contents
Interfaces Supporting Traffic Shaping
9-13
Configuring Traffic Shaping 9-13

Shaping a Traffic Class 9-14
Shaping Traffic at the VC-Level and Virtual Path-Level 9-15
Configuration Example for Traffic Shaping at the VC-Level and the VP-Level
Verifying Traffic Shaping 9-17
Verification Examples for Traffic Shaping
9-17
9-19
Configuration Examples for Traffic Shaping 9-21

Configuration Example for Class-Based Shaping 9-21
Configuration Examples for Hierarchical Shaping 9-21
CHAPTER
10
Overhead Accounting
9-22
10-1
Overhead Accounting Features 10-1

Feature History for Overhead Accounting 10-2
ATM Overhead Accounting 10-2
MLP on LNS with HQoS and ATM Overhead Accounting
HQoS 10-3
Overhead Accounting 10-3
Traffic Shaping Overhead Accounting for ATM 10-4
Ethernet Overhead Accounting 10-4
Configuration Commands for Overhead Accounting
Subscriber Line Encapsulation Types
Overhead Calculation on the Router
10-3
10-5
10-5
10-5
Overhead Accounting and Hierarchical Policies
10-6
Restrictions and Limitations for Overhead Accounting
10-7
Configuring Overhead Accounting in a Hierarchical Policy
10-7
Configuration Examples for Overhead Accounting 10-10

Enabling ATM Overhead Accounting 10-10
Enabling ATM Overhead Accounting on the PRE3 and PRE4 for MLPoLNS
Enabling Ethernet Overhead Accounting on the PRE2 10-11
Enabling Ethernet Overhead Accounting on the PRE3 and PRE4 10-12
Verifying Overhead Accounting
10-11
10-12
Verification Examples for Overhead Accounting 10-13

Verifying ATM Overhead Accounting Using show policy-map 10-13
Verifying Overhead Accounting Using show running-config 10-14
Verifying Ethernet Overhead Accounting with User-Defined Option 10-14
10-15
OL-7433-09
xvii
Contents
CHAPTER
11
Managing Packet Queue Congestion

Queue Scaling Limits
11-1
11-1
Queue Limit 11-2

Queue Limit Packet Buffers 11-4
Default Queue Limit and Packet Buffers 11-4
queue-limit Command 11-4
queue-limit Command History 11-5
Default Behavior for the queue-limit Command 11-5
Usage Guidelines for the queue-limit Command 11-6
Queue IDs and Interface Queues
Reserved QIDs 11-6
11-6
Queuing Outbound Traffic 11-7

Queuing Outbound Traffic on ATM Interfaces 11-7
Queuing Outbound Traffic on Frame Relay Interfaces 11-7
Queuing Outbound Traffic on Virtual LAN Interfaces 11-7
Controlling Congestion Using Tail Drop 11-8
Feature History for Tail Drop 11-8
Tail Drop and Random Early Detection 11-8
Controlling Congestion Using Random Early Detection 11-9
Feature History for Random Early Detection 11-9
Random Early Detection and Queue Limit 11-10
Determining Packet Drop Probability 11-10
Recommended Settings for RED Drop Probability 11-11
Controlling Congestion Using Weighted Random Early Detection 11-11
Feature History for Weighted Random Early Detection 11-12
Benefits of Using Weighted Random Early Detection 11-13
How WRED Works 11-13
WRED Drop Mode 11-13
WRED Drop Profiles 11-14
WRED Aggregate Drop Profiles 11-17
Usage Guidelines for the random-detect Command 11-18
Minimum and Maximum Thresholds 11-19
WRED and Queue Limit 11-20
Average Queue Size and the Exponential Weight Constant 11-21
Interfaces Supporting Layer 3 Packet Drop Policies
11-21
Restrictions and Limitations for Controlling Layer 3 Congestion

Configuring Layer 3 Queue Limit and Drop Policies
11-22
11-24
xviii
OL-7433-09
Contents
Controlling Packet Dropping by Setting the Size of a Class Queue 11-24

Configuration Example for Controlling Packet Dropping by Setting a Queue Size 11-25
Dropping Packets Based on a Differentiated Services Code Point 11-26
Configuration Example for Configuring DSCP-Based WRED 11-27
Dropping Packets Based on IP Precedence 11-28
Configuration Example for Dropping Packets Based on IP Precedence 11-29
Dropping Packets Based on the Discard Class 11-29
Configuration Example for Dropping Packets Based on Discard Class 11-30
Dropping Packets Based on the ATM Cell Loss Priority 11-31
Configuration Example for Dropping Packets Based on the Cell Loss Priority 11-31
Verifying and Monitoring Layer 3 Packet Dropping 11-32
Verification Example for Queue Size and Packet Dropping 11-34
Verification Examples for DSCP-Based WRED 11-35
Verification Example for IP Precedence-Based WRED 11-36
Verification Example for Discard-Class-Based WRED 11-37
Verification Examples for ATM CLP-Based WRED 11-38
Controlling Packet Flow on Layer 2 Queues 11-39
Configuring the Depth of Layer 2 Queues 11-40
CHAPTER
12
11-40
Sharing Bandwidth Fairly During Congestion
12-1
Class-Based Weighted Fair Queuing 12-1

Feature History for Class-Based Weighted Fair Queuing
Class-Default Class 12-3
CBWFQ and Bandwidth Allocation 12-3
CBWFQ and RSVP 12-4
Restrictions and Limitations for CBWFQ 12-4
12-3
Class-Based Weighted Fair Queuing for Virtual Access Interfaces

Feature History for CBWFQ for VAIs 12-5
Service Policy Inheritance 12-5
Restrictions and Limitations for CBWFQ for VAIs 12-6
System Limits for CBWFQ
12-4
12-6
Interfaces Supporting Class-Based Weighted Fair Queuing
12-7
Configuring Fair Bandwidth Sharing During Congestion 12-7

Defining Traffic Classes Using Class Maps 12-8
Configuration Example for Defining Traffic Classes Using Class Maps 12-8
Configuring Policy Actions for Traffic Classes Using Policy Maps 12-9
Configuring a Default Traffic Class Policy 12-9
Configuring a Class Policy and Dropping Packets Using Tail Drop 12-11
OL-7433-09
xix
Contents
Configuring a Class Policy and Dropping Packets Using WRED 12-12

Attaching Service Policies 12-15
Attaching a Service Policy to an Interface, Subinterface, or PVC 12-15
Attaching a Service Policy to a Virtual Access Interface 12-16
Modifying the Bandwidth for an Existing Policy Map Class 12-16
Modifying the Queue Limit for an Existing Policy Map Class 12-17
Deleting Classes 12-17
Deleting Policy Maps 12-18
Configuration Examples for Sharing Bandwidth Fairly 12-18
Configuration Example for Configuring CBWFQ and Attaching a Policy to an Ethernet Interface
Configuration Example for Configuring CBWFQ and Attaching a Policy to an ATM
Subinterface 12-19
Configuration Example for Configuring CBWFQ and Attaching a Policy to an RBE Subinterface
Verifying and Monitoring Class-Based Weighted Fair Queuing
CHAPTER
13
12-18
12-19
12-20
12-20
Defining QoS for Multiple Policy Levels
13-1
Hierarchical Policies 13-2

Feature History for Hierarchical Policies
Benefits of Hierarchical Policies 13-3
13-3
Components Common to All Types of Hierarchical Policies

Child Policy 13-4
Parent Policy 13-4
13-3
Types of Hierarchical Policies 13-6

Nested Hierarchical Policies 13-6
Restrictions and Limitations for Nested Hierarchical Policies 13-7
Three-Level Hierarchical Policies 13-8
Restrictions and Limitations for Three-Level Hierarchical Policies 13-9
Hierarchical Input Policing Policies 13-10
Restrictions and Limitations for Hierarchical Input Policing Policies 13-11
Hierarchical Policies and Oversubscription
13-11
Applying Child Policies Under Priority Classes

Interfaces Supporting Hierarchical Policies
13-12
13-12
Guidelines for Configuring QoS for Multiple Queues
13-13
Configuring QoS for Multiple Queues 13-13

Creating Fair Queues at Two Levels of Hierarchy 13-13
Creating Fair Queues at Three Levels of Hierarchy 13-15
xx
OL-7433-09
Contents
Configuring a Bottom-Level Child Policy of a Three-Level Hierarchy

Configuring a Middle-Level Child Policy of a Three-Level Hierarchy
Configuring the Top-Level Parent Policy of a Three-Level Hierarchy
Policing Inbound Traffic at Two Levels of Hierarchy 13-19
Attaching Hierarchical Policies to Physical and Virtual Links 13-21
13-15
13-16
13-18

Configuration Examples for Nested Hierarchical Policies 13-22
Configuration Examples for Three-Level Hierarchical Policies 13-23
Configuration Example for Hierarchical Input Policing 13-25
Configuring Bandwidth-Remaining Ratios on ATM Subinterfaces: Example 13-26
Configuring Bandwidth-Remaining Ratios on Class Queues: Example 13-26
Verifying the Configuration of Hierarchical Policies
Verification Examples for Hierarchical Policies
CHAPTER
14
Simultaneous Policy Maps
13-27
13-29
13-30
14-1
Simultaneous QoS Policy Map on an Interface and PPP Session 14-1

Feature History for Simultaneous Policy Maps 14-2
QoS Actions 14-2
Simultaneous Policies and Displaying Statistical Information 14-2
Restrictions for Simultaneous Policy Maps
14-4
Configuring Simultaneous Policy Maps 14-5

Configuring the Two Policy Maps 14-5
Attaching Simultaneous Policies to PPPoE Sessions Traversing an Ethernet Interface
Attaching a Policy to a PPPoE Session 14-6
Attaching a Policy to an Ethernet Interface 14-7
Attaching Simultaneous Policies to PPPoA Sessions Traversing an ATM VC 14-8
Attaching a Policy to a PPPoA Session 14-8
Attaching a Policy to an ATM VC with PPPoA Sessions 14-9
Attaching Simultaneous Policies to PPPoE Sessions Traversing an ATM VC 14-11
Attaching a Policy to PPPoE Sessions 14-11
Attaching a Policy to an ATM VC with PPPoE Sessions 14-12
14-6
Configuration Examples for Simultaneous Policy Maps 14-14

Configuration Example for Applying Simultaneous Policy Maps on Ethernet Interfaces and PPPoE
Sessions 14-14
Configuration Example for Applying Simultaneous Policies on 802.1Q Interfaces and PPPoE
Sessions 14-16
Configuration Example for Applying Simultaneous Policies on 802.1Q QinQ Interfaces and PPPoE
Sessions 14-17

OL-7433-09
xxi
Contents
Configuration Example for Applying Simultaneous Policies on ATM VCs and PPPoA Sessions
Configuration Example for Applying Simultaneous Policies on ATM VCs and PPPoE Sessions
Verifying Simultaneous Policy Maps
14-17
14-18
14-18
Verification Examples for Traffic Policing 14-19

Displaying Simultaneous Policy Map Information for Interfaces 14-20
Displaying Simultaneous Policy Map Information for PTA Virtual Interfaces 14-21
Displaying Simultaneous Policy Map Information for Virtual Access Interfaces 14-21
Displaying Simultaneous Policy Map Information for a LAC Session 14-22
CHAPTER
15
Oversubscribing Physical and Virtual Links
15-1
Interface Oversubscription 15-2

Feature History for Interface Oversubscription 15-2
Restrictions and Limitations for Interface Oversubscription
15-3
ATM Virtual Circuit Oversubscription 15-3

Feature History for ATM VC Oversubscription 15-4
Oversubscription Factor and Unspecified Bit Rate Virtual Circuits 15-4
ATM VC Oversubscription and ATM Line Cards 15-5
atm over-subscription-factor Command 15-5
atm over-subscription-factor Command History 15-6
Usage Guidelines for the atm over-subscription-factor Command 15-6
Restrictions and Limitations for ATM VC Oversubscription 15-7
Frame Relay PVC Oversubscription 15-7
Feature History for Frame Relay PVC Oversubscription 15-8
Restrictions and Limitations for Frame Relay PVC Oversubscription
Virtual LAN Oversubscription 15-9
Feature History for VLAN Oversubscription 15-9
Restrictions and Limitations for VLAN Oversubscription
Oversubscription and Hierarchical Policies
15-9
15-9
15-10
Configuring Oversubscription 15-10

Oversubscribing ATM VBR-nrt VCs 15-11
Oversubscribing Frame Relay PVCs 15-11
Oversubscribing Frame Relay PVCs Using Hierarchical Policies 15-12
Oversubscribing Frame Relay PVCs Using a Map Class 15-15
Oversubscribing 802.1Q VLANs 15-17
Configuration Example for Oversubscribing 802.1Q VLANs 15-20
How the Router Determines VC Weights 15-20
Feature History for VC Weighting 15-21
Determining VC WeightingCisco IOS Release 12.0(17)SL to Release 12.3(7)XI1
15-21
xxii
OL-7433-09
Contents
Determining VC WeightingCisco IOS Release 12.3(7)XI1 and Later Releases 15-22

Determining VC WeightingCisco IOS Release 12.2(31)SB2 and Later Releases 15-22
Calculating the Default Weight of a VCPRE2 15-23
Calculating the Default Weight of a VCPRE3 15-23
queue-depth Command 15-24
queue-depth Command History 15-24
Usage Guidelines for the queue-depth Command 15-24
weight Command 15-24
weight Command History 15-25
Usage Guidelines for the weight Command 15-25
High Watermark and Low Watermark Default Values 15-25
Guidelines for Changing Watermark Values 15-26
Modifying the VC Weight and the VP Shaping Parameters 15-27
Restrictions and Limitations for VC Weighting 15-27
Configuring VC Weighting 15-28
Configuring ATM VC Weighting 15-28
Configuration Example for Configuring ATM VC Weighting 15-28
Configuring VC Weighting Using a VC Class Map 15-29
Configuration Example for Configuring VC Weighting Using a VC Class Map 15-29
Configuring VC Weighting on a Range of PVCs 15-30
Configuration Example for Configuring VC Weighting on a Range of PVCs 15-30
Configuring VC Weighting On Subinterfaces Using a Bandwidth Remaining Ratio 15-31
Configuration Example for Configuring VC Weighting on a Subinterface Using Bandwidth
Remaining Ratio 15-33
Configuring VC Weighting on Class Queues Using Bandwidth Remaining Ratio 15-34
Configuration Example for VC Weighting on a Class Queue Using Bandwidth Remaining
Ratio 15-37
Configuring VC Queue Depth 15-38
Configuration Example for Configuring VC Queue Depth 15-38
Configuration Example for Oversubscribing a Shaped ATM VC and VP 15-39
Configuration Example for Configuring the Weight of a VC 15-39
Configuration Example for Configuring the Weight of Multiple VCs 15-40
Configuration Example for Configuring VC Weight Using a Bandwidth Remaining Ratio
Configuration Example for Setting High and Low Watermark Thresholds 15-41
15-40
Verifying Oversubscription and VC Weighting 15-41

Verification Examples for Oversubscription and VC Weighting 15-42
Verifying Default High and Low Watermarks on an Interface 15-42
OL-7433-09
xxiii
Contents
Verifying High and Low Watermarks on an Individual VC 15-43

Verifying VC Parameter Configurations and Parameter Inheritance
CHAPTER
16
15-43
15-44
Fragmenting and Interleaving Real-Time and Nonreal-Time Packets
16-1
Link Fragmentation and Interleaving 16-1

Feature History for Link Fragmentation and Interleaving 16-3
System Limits for Link Fragmentation and Interleaving 16-4
Configuration Commands for MLP-Based Fragmentation and Interleaving
interface multilink Command 16-5
interface multilink Command History 16-5
ppp multilink Command 16-6
ppp multilink fragment-delay Command 16-7
ppp multilink interleave Command 16-8
ppp multilink fragmentation Command 16-8
ppp multilink fragment disable Command 16-9
ppp multilink group Command 16-10
16-5
Multilink PPP-Based Link Fragmentation and Interleaving 16-11

How MLP-Based LFI Works 16-12
MLP Over Serial-Based LFI 16-13
Feature History for MLP Over Serial-Based LFI 16-13
Performance and Scalability for MLP Over Serial-Based LFI 16-13
Restrictions and Limitations for MLP Over Serial-Based LFI 16-14
Line Card Support for MLP Over Serial-Based LFI 16-14
Single-VC MLP Over ATM-Based LFI 16-14
Feature History for Single-VC MLP Over ATM-Based LFI 16-15
Fragment Size Calculation for MLP Over ATM-Based LFI 16-15
MLP Bundle Interface and Service Policies 16-16
Transmit Processing 16-17
Receive Processing 16-17
Performance and Scalability for Single-VC MLP Over ATM-Based LFI 16-18
Restrictions and Limitations for Single-VC MLP Over ATM-Based LFI 16-18
Line Card Support for MLP Over ATM-Based LFI 16-18
Multi-VC MLP Over ATM-Based LFI 16-19
Feature History for Multi-VC MLP Over ATM-Based LFI 16-19
Fragment Size Calculation for Multi-VC MLP Over ATM-Based LFI 16-19
Performance and Scalability for Multi-VC MLP Over ATM-Based LFI 16-20
Restrictions and Limitations for Multi-VC MLP Over ATM-Based LFI 16-20
xxiv
OL-7433-09
Contents
Line Card Support for MLP Over ATM-Based LFI 16-21

MLP Over Frame Relay-Based LFI 16-21
Feature History for MLP Over Frame Relay-Based LFI 16-21
Multilink Group Interfaces and Virtual Template Interfaces 16-21
Transmit Processing 16-22
Receive Processing 16-22
Fragment Size Calculation for MLP Over Frame Relay-Based LFI 16-23
Performance and Scalability for MLP Over Frame Relay-Based LFI 16-23
Restrictions and Limitations for MLP Over Frame Relay-Based LFI 16-24
Configuring MLP-Based LFI 16-24
Creating a MLP Bundle Interface 16-25
Enabling MLP on a Virtual Template Interface 16-27
Configuring a Shaping Policy for MLP Over Frame Relay-Based LFI 16-29
Adding a Serial Member Link to a MLP Bundle 16-29
Adding an ATM Member Link to a MLP Bundle 16-30
Adding a Frame Relay Member Link to a MLP Bundle 16-33
Moving a Member Link to a Different MLP Bundle 16-35
Removing a Member Link from a MLP Bundle 16-36
FRF.12 Fragmentation 16-37
Feature History for FRF.12 Fragmentation 16-38
FRF.12 over Multilink Frame Relay 16-38
FRF.12 Fragmentation Inheritance 16-39
FRF.12 Fragmentation and Hierarchical Policies 16-39
PVC-Based FRF.12 Fragmentation 16-40
Interface-Based FRF.12 Fragmentation 16-40
Minimum Fragment Size for FRF.12 Fragmentation 16-40
Configuration Commands for FRF.12 Fragmentation 16-40
frame-relay fragment Command (Map-Class) 16-41
frame-relay fragment end-to-end Command (Interface) 16-41
Performance and Scalability for FRF.12 Fragmentation 16-42
Prerequisites for FRF.12 Fragmentation 16-42
Restrictions and Limitations for FRF.12 Fragmentation 16-43
Configuring PVC-Based FRF.12 Fragmentation 16-44
Enabling FRF.12 Fragmentation on a Map Class 16-44
Attaching the Map Class 16-45
Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation 16-52
Configuring Interface-Based FRF.12 Fragmentation 16-57
Configuration Example for Enabling Interface-Based FRF.12 Fragmentation 16-58
Configuration Examples for Link Fragmentation and Interleaving
16-59

OL-7433-09
xxv
Contents
Configuration Example for MLP Over Serial-Based LFI 16-59

Configuration Example for Single-VC MLP Over ATM-Based LFI 16-60
Configuration Example for Multi-VC MLP Over ATM-Based LFI 16-61
Configuration Example for MLP Over Frame Relay-Based LFI 16-62
Configuration Examples for PVC-Based FRF.12 Fragmentation 16-63
Configuration Example for Interface-Based FRF.12 Fragmentation 16-64
Verifying and Monitoring Link Fragmentation and Interleaving 16-65
Verification Example for MLP Over Serial-Based LFI 16-67
Verification Examples for FRF.12 Fragmentation 16-68
CHAPTER
17
16-69
Configuring Dynamic Subscriber Services
17-1
Applying Traffic Shaping Parameters Using RADIUS Profiles 17-2

Feature History for Dynamic Bandwidth Selection 17-2
Configuration Commands for DBS 17-3
dbs enable Command 17-3
default dbs enable Command 17-4
PCR and SCR Parameters for Multiple Sessions on a VC 17-5
Dynamic Bandwidth Selection Configuration and PPP Sessions 17-6
Network Access Server QoS Management 17-6
Default QoS Parameters and QoS Configuration Precedence 17-6
Accounting Updates 17-7
Service Category Transitions 17-7
Dynamic Bandwidth Selection and Oversubscription 17-7
Prerequisites for Dynamic Bandwidth Selection 17-8
Restrictions and Limitations for Dynamic Bandwidth Selection 17-8
Configuring Dynamic Bandwidth Selection 17-9
Configuring the Router for Dynamic Bandwidth Selection 17-9
Configuring RADIUS Profiles for Dynamic Bandwidth Selection 17-13
Configuration Examples for Dynamic Bandwidth Selection 17-14
Configuration Example for Enabling Dynamic Bandwidth Selection on a VC Class and a
PVC 17-14
Configuration Example for Enabling a RADIUS Domain Service Profile for Dynamic Bandwidth
Selection 17-16
Configuration Example for Enabling a RADIUS User Profile for Dynamic Bandwidth
Selection 17-16
Verifying and Monitoring Dynamic Bandwidth Selection 17-17
Dynamically Changing VC Weight and Watermark Values 17-18
Feature History for Dynamic VC Weight and Watermarks 17-19
Configuration Commands for Dynamic VC Weight and Watermarks
17-19
xxvi
OL-7433-09
Contents
Default High and Low Watermark Values 17-20

High and Low Watermark Threshold Behavior 17-20
Restrictions and Limitations for VC Weight and Watermarks 17-20
Configuring Dynamic VC Weights and Watermarks 17-20
Configuring the Router for Dynamic VC Weights and Watermarks 17-21
Setting Up RADIUS for Dynamic VC Weights and Watermarks 17-22
Verifying Dynamic VC Weights and Watermarks 17-22
Verification Example for Dynamic VC Weights and Watermarks 17-23
Applying QoS Parameters Dynamically to Sessions 17-24
Feature History for Define Interface Policy-Map AV Pairs AAA 17-26
Pulled Policy Maps 17-26
Prerequisites for Define Interface Policy-Map AV Pairs AAA 17-27
Restrictions and Limitations for Define Interface Policy-Map AV Pairs AAA 17-27
Configuring Dynamic QoS Policies at the Session Level 17-27
Prerequisites 17-27
Configuring the Router for Dynamic QoS Policies at the Session Level 17-28
Setting Up RADIUS for Dynamic QoS Policies at the Session Level 17-29
Setting Up the AAA Server 17-29
Configuration Examples for Dynamic QoS Policies at the Session Level 17-30
Configuration Examples for Existing Service Policies and Pulled Policies 17-30
Configuration Examples for Pulled Policies and a Router Without Existing Policies
Verifying Dynamic QoS Policies at the Session Level 17-32
Verification Examples for Dynamic QoS Policies at the Session Level 17-33
17-32
Shaping PPPoE Over VLAN Sessions Using RADIUS 17-34

Feature History for Per Session Queuing and Shaping for PPPoE Over VLANs 17-35
Per Session Shaping Inheritance 17-36
Interfaces Supporting Per Session Queuing and Shaping for PPPoE Over VLANs 17-36
Restrictions and Limitations for Per Session Queuing and Shaping for PPPoE Over VLANs 17-36
Configuring Per Session Queuing and Shaping for PPPoE Over VLANs Using RADIUS 17-37
Configuring a Per Session Queuing and Shaping Policy on the Router 17-37
Setting Up RADIUS for Per Session Queuing and Shaping 17-40
Verifying Per Session Queuing and Shaping Policies 17-42
Shaping and Queuing Per-Session Traffic on LNS 17-44
Feature History for Per Session Shaping and Queuing on LNS 17-45
Prerequisites for Per Session Shaping and Queuing on LNS 17-45
Restrictions and Limitations for Per Session Shaping and Queuing on LNS 17-45
Configuring Per Session Shaping and Queuing on LNS 17-45
Configuring a Per Session Shaping and Queuing on LNS Policy 17-46
Queuing PPP Sessions on ATM VCs
17-50

OL-7433-09
xxvii
Contents
Feature History for PPP Session Queuing on ATM VCs 17-51

Dynamically Applying QoS Policies to PPP Sessions on ATM VCs 17-51
PPP Session Queuing Inheritance 17-52
Interfaces Supporting PPP Session Queuing 17-52
Mixed Configurations and Queuing 17-52
Bandwidth Sharing and ATM Port Oversubscription 17-53
Oversubscription at the Session Level 17-53
Prerequisites for PPP Session Queuing on ATM VCs 17-53
Restrictions and Limitations for PPP Session Queuing on ATM VCs 17-53
Configuring PPP Session Queuing on ATM VCs 17-54
Configuring PPP Session Queuing Using a Virtual Template 17-54
Configuring PPP Session Queuing Using RADIUS 17-60
Configuration Examples for PPP Session Queuing on ATM VCs 17-60
Example of Configuring PPP Session Queuing on ATM VCs 17-61
Example of Configuring and Applying an Hierarchical Policy Map 17-61
Example of Setting Up RADIUS for PPP Session Queuing on ATM VCs 17-62
Verifying PPP Session Queuing on ATM VCs 17-62
Examples of Verifying PPP Session Queuing on ATM VCs 17-63
CHAPTER
18
17-66
Regulating and Shaping Subscriber Traffic
18-1
Subscriber-Based IP Quality of Service 18-2

Per Session Rate Limiting 18-3
Feature History for Per Session Rate Limiting 18-4
Restrictions and Limitations for Per Session Rate Limiting 18-4
Per User Multiservice Rate Limiting 18-4
Feature History for Per User Multiservice Rate Limiting 18-5
System Limits for Per User Multiservice Rate Limiting 18-5
Restrictions and Limitations for Per User Multiservice Rate Limiting 18-5
Per Session Service Policy Using RADIUS 18-5
Feature History for Per Session Service Policy Using RADIUS 18-6
Restrictions and Limitations for per Session Service Policy Using RADIUS 18-6
Input and Output Policy Actions 18-7
Configuring IP Quality of Service for Subscribers 18-9
Configuring per Session Rate Limiting 18-9
Configuring per User Multiservice Rate Limiting 18-10
Configuring per Session Service Policy Using RADIUS 18-11
Configuration Examples for Subscriber-Based IP QoS 18-12
Configuration Example for Per Session Rate Limiting 18-12
xxviii
OL-7433-09
Contents
Configuration Example for Per User Multiservice Rate Limiting 18-13

Configuration Example for Per Session Service Policy Using RADIUS 18-13
Verifying a Subscriber-Based IP QoS Configuration 18-16
Verification Examples for Subscriber-Based IP QoS Configurations 18-17
MQC Support for IP Sessions 18-18
Feature History for MQC Support for IP Sessions 18-19
QoS Actions Supported in IP Session Policy Maps 18-19
Interface Support for MQC on IP Sessions 18-19
Policies and Queues Inheritance Rules 18-19
Service Policy Maps and Service Profiles 18-20
Restrictions and Limitations for MQC Support for IP Sessions 18-20
Configuring MQC on IP Sessions 18-21
Configuring QoS on Service Policy Maps Without Traffic Classes 18-21
Configuring QoS on Service Policy Maps With Traffic Classes 18-22
Configuration Examples for MQC on IP Sessions 18-23
Verifying Service Policies on IP Sessions 18-24
Shaping and Queuing Per-Session Traffic on LNS 18-24
Feature History for Per Session Shaping and Queuing on LNS 18-25
Prerequisites for Per Session Shaping and Queuing on LNS 18-25
Restrictions and Limitations for Per Session Shaping and Queuing on LNS
Configuring Per Session Shaping and Queuing on LNS 18-25
18-25
Queuing PPP Sessions on ATM VCs 18-29

Feature History for PPP Session Queuing on ATM VCs 18-30
Dynamically Applying QoS Policies to PPP Sessions on ATM VCs 18-30
PPP Session Queuing Inheritance 18-31
Interfaces Supporting PPP Session Queuing 18-31
Mixed Configurations and Queuing 18-31
Bandwidth Sharing and ATM Port Oversubscription 18-32
Oversubscription at the Session Level 18-32
Prerequisites for PPP Session Queuing on ATM VCs 18-32
Restrictions and Limitations for PPP Session Queuing on ATM VCs 18-32
Configuring PPP Session Queuing on ATM VCs 18-33
Configuring PPP Session Queuing Using a Virtual Template 18-33
Configuring PPP Session Queuing Using RADIUS 18-38
Configuration Examples for PPP Session Queuing on ATM VCs 18-39
Example of Configuring PPP Session Queuing on ATM VCs 18-39
Example of Configuring and Applying an Hierarchical Policy Map 18-40
Example of Setting Up RADIUS for PPP Session Queuing on ATM VCs 18-41
Verifying PPP Session Queuing on ATM VCs 18-41

OL-7433-09
xxix
Contents
Verification Examples for PPP Session Queuing on ATM VCs
18-42
Per-Session Shaping for ATM Interfaces 18-45

Feature History for Per-Session Shaping for ATM Interfaces 18-46
Restrictions and Limitations for Per-Session Shaping for ATM Interfaces 18-46
Configuring Per-Session Shaping for ATM Interfaces 18-46
Configuration Example for Per-Session Shaping on ATM Interfaces 18-50
Verifying Per-Session Shaping on ATM Interfaces 18-50
CHAPTER
19
18-51
Configuring Quality of Service for PVC Bundles
19-1
PVC Bundles 19-1

Feature History for PVC Bundles 19-2
System Limits for PVC Bundles 19-2
Traffic Bumping 19-3
PVC Bundle Protection Rules 19-3
ATM PVC Selection 19-4
Feature History for ATM PVC Selection 19-5
Configuration Commands for ATM PVC Selection 19-5
bump Command 19-5
bundle Command 19-6
class-bundle Command 19-7
class-vc Command 19-8
mpls experimental Command 19-9
oam-bundle Command 19-10
precedence Command 19-11
protect Command 19-12
pvc-bundle Command 19-13
ATM Bundle Management 19-14
Bumping and ATM PVC Bundles 19-16
Prerequisites for ATM PVC Selection 19-17
Restrictions and Limitations for ATM PVC Selection 19-17
Configuring ATM Bundles 19-18
Creating an ATM Bundle Directly 19-18
Creating an ATM Bundle Using a VC Class 19-20
Adding an ATM PVC to a PVC Bundle 19-23
Configuring ATM Bundle Members 19-23
Configuring an ATM Bundle Member 19-23
Configuring an ATM Bundle Member Using a VC Class 19-25
Configuring a PVC Not to Accept Bumped Traffic 19-27
xxx
OL-7433-09
Contents
Verifying and Monitoring ATM PVC Bundles 19-28

Configuration Examples for Configuring ATM Bundles and PVC Selection 19-29
Configuration Example for ATM Bundle Configuration Using VC Classes 19-29
Configuration Example for MPLS EXP-Based ATM PVC Selection 19-31
Frame Relay PVC Selection 19-31
Feature History for Frame Relay PVC Selection 19-32
Configuration Commands for Frame Relay PVC Selection 19-32
bump Command (Frame Relay VC-bundle-member) 19-33
dscp Command (Frame Relay VC-bundle-member) 19-34
exp Command 19-35
frame-relay vc-bundle Command 19-36
precedence Command (Frame Relay VC-bundle-member) 19-37
protect Command (Frame Relay VC-bundle-member) 19-38
pvc Command (Frame Relay VC-bundle) 19-39
Service Levels and PVC Selection Criteria 19-40
Prerequisites for Frame Relay PVC Selection 19-40
Restrictions and Limitations for Frame Relay PVC Selection 19-41
Configuring Frame Relay Bundles 19-41
Creating a Frame Relay PVC Bundle 19-42
Adding a PVC to a Frame Relay PVC Bundle 19-43
Configuring Frame Relay Bundle Members 19-44
Configuration Examples for Configuring Frame Relay Bundles and PVC Selection 19-49
Configuration Example for Precedence-Based and DSCP-Based Frame Relay PVC
Selection 19-49
Configuration Example for MPLS EXP-Based Frame Relay PVC Selection 19-50
Verifying and Monitoring Frame Relay PVC Selection 19-50
Verification Example for Monitoring PVC Bundles 19-52
CHAPTER
20
19-53
Configuring Quality of Service for MPLS Traffic
20-1
MPLS QoS 20-1

Feature History for MPLS QoS 20-2
MPLS QoS Services 20-2
MPLS Tunneling Modes 20-3
How QoS Works for MPLS Traffic 20-4
MPLS QoS and Packet Priority During Congestion 20-4
Interfaces Supporting MPLS QoS 20-4
MPLS QoS Implementation 20-5
Restrictions and Limitations for MPLS QoS 20-5

OL-7433-09
xxxi
Contents
Configuring MPLS QoS on the Ingress Label Switching Router 20-5

Classifying IP Packets Using a Class Map 20-6
Setting the MPLS EXP Field Using a Policy Map 20-7
Attaching an MPLS QoS Service Policy to an Interface 20-8
Configuration Examples for MPLS QoS 20-8
Configuration Example for Short Pipe Mode 20-9
Configuration Example for Pipe Mode 20-10
MPLS CoS Multi-VC Mode 20-12
Feature History for MPLS CoS Multi-VC Mode 20-12
Label Switched Paths 20-13
Class of Service Map 20-13
QoS for Label-Controlled ATM VCs 20-14
Default Bandwidth for LVCs 20-14
Allocating LVC Bandwidth Using Policy Maps 20-14
MPLS QoS Support in an MPLS Network 20-14
Benefits of MPLS CoS Multi-VC Mode 20-15
Restrictions for MPLS CoS Multi-VC Mode 20-15
Prerequisites for MPLS CoS Multi-VC Mode 20-15
Configuring MPLS CoS Multi-VC Mode 20-16
Configuring Multi-VC Mode in the Core of an ATM Network 20-16
Configuring Queueing Functions on Router Output Interfaces 20-17
Monitoring and Maintaining MPLS CoS Multi-VC Mode Configuration 20-18
Configuration Examples for MPLS CoS Multi-VC Mode 20-18
MPLS Traffic EngineeringDiffServ Aware 20-18
Feature History for MPLS TEDS 20-19
Sub-pool Tunnels 20-19
Global Pool Tunnels 20-20
Prerequisites for DS-TE 20-20
Restrictions and Limitations for DS-TE 20-20
Configuring DS-TE 20-20
Activating Traffic Engineering on the Router 20-21
Activating Traffic Engineering on the Interface 20-23
Configuring the Tunnel Interface 20-24
Configuring Guaranteed Bandwidth Service 20-25
Verifying and Monitoring DS-TE Configurations 20-26
Configuration Examples for DS-TE 20-28
Configuration Examples for Configuring the Tunnel Head Router 20-28
Configuration Examples for Configuring DS-TE on the Midpoint Routers 20-30
Configuration Examples for Configuring the Tail-End Router 20-31
Configuration Examples for Configuring Guaranteed Bandwidth Service 20-31
xxxii
OL-7433-09
Contents
Per VRF AAA
20-32
CHAPTER
21
20-32
VLAN Tag-Based Quality of Service
21-1
VLAN Tag-Based QoS 21-1

Feature History for VLAN Tag-Based QoS 21-2
VLAN-Groups 21-2
VLAN-Group Policy Map 21-2
Modification of a VLAN-Group Policy Map 21-3
VLAN ID 21-3
VLAN-Group Policies and Inheritance 21-3
Aggregate Session Traffic 21-3
System Limits for VLAN Tag-Based QoS 21-4
Statistical Information for VLAN-Group Policies and Classes
VLAN Tag-Based QoS on the PRE2 and PRE3 21-4
Restrictions for VLAN Tag-Based QoS
21-4
21-5
Configuring VLAN Tag-Based QoS 21-7

Configuration Guidelines for VLAN Tag-Based QoS 21-7
Configuring VLAN-Group Class Maps 21-8
Examples 21-8
Configuring a VLAN-Group Policy 21-9
Configuring QoS Policies for Traffic ClassesInbound VLAN Group and Class-Default
Classes 21-9
Configuring QoS Policies for Traffic ClassesOutbound VLAN Group and Class-Default
Classes 21-10
Attaching VLAN Tag-based Policies 21-12
Configuration Examples for VLAN Tag-Based QoS 21-13
Configuring a VLAN Tag-Based QoS Policy: Example 21-14
Configuring a VLAN Tag-Based QoS Policy: Invalid Configuration Example
Related Documents
CHAPTER
22
21-14
21-15
Hierarchical Scheduling and Queuing
22-1
Hierarchical Queuing Framework 22-1

Feature History for Hierarchical Queuing Framework 22-2
Hierarchical Queuing Framework Scaling 22-2
QoS Shaping Using HQF 22-3
ATM Virtual Path Shaping Using HQF 22-3
ATM VC Shaping Using HQF 22-3
Hierarchical ATM VP and VC Shaping Using HQF 22-4
OL-7433-09
xxxiii
Contents
Subinterface Shaping Using HQF 22-4

IP and PPP Session Shaping Using HQF 22-5
MQC Hierarchical Queuing with 3-Level Scheduler 22-5
Feature History for MQC Hierarchical Queuing with 3-Level Scheduler 22-6
Prerequisites for MQC Hierarchical Queuing with 3-Level Scheduler 22-6
Restrictions for MQC Hierarchical Queuing with 3-Level Scheduler 22-6
Scheduling Hierarchy 22-6
Priority Service and Latency 22-7
Latency Requirements 22-7
Priority Propagation with Imposed Burstiness 22-7
Configuring MQC Hierarchical Queuing with 3-Level Scheduler 22-8
Configuration Examples for MQC Hierarchical Queuing with 3-Level Scheduler
Bandwidth AllocationPolicy Attached to an Interface: Example 22-8
Tuning the Bandwidth-Remaining Ratio: Example 22-9
4-Level Scheduler 22-10
Feature History for 4-Level Scheduler
APPENDIX
22-11
22-12
Configuring Frame Relay QoS Using Frame Relay Legacy Commands

Creating a Map Class
Specifying a DLCI Queue Weight

Enabling RED Drop
A-3
A-3
Configuring Frame Relay Traffic Shaping

B
A-2
A-2
Configuring Frame Relay IP RTP Priority
APPENDIX
A-1
A-1
Enabling Weighted Fair Queuing on the Interface

Specifying Tail Drop
22-8
A-4
A-5
QoS Policy Propagation Through the Border Gateway Protocol

QPPB Configuration Example
B-1
B-1
B-4
GLOSSARY
INDEX
xxxiv
OL-7433-09
About This Guide

This guide provides information about the Quality of Service (QoS) features supported on the
Cisco 10000 series router and describes how to configure them.
Guide Revision History

Cisco IOS Release
Part Number
Publication Date
Release 12.2(33)SB2
OL-7433-08
September, 2008
Description
Added the following new and modified features:
MLP at LNS with H-QoS & ATM Overgead AccountingSee the MLP on LNS with HQoS and
ATM Overhead Accounting section on page 10-3
Cisco IOS Release
Part Number
Publication Date
Release 12.2(33)SB
OL-7433-06
March, 2008
Description
Added the following new and modified features:
ATM CLP-Based WREDSee the Controlling Congestion Using Weighted Random Early
Detection section on page 11-11.
ATM Overhead AccountingSee the ATM Overhead Accounting section on page 2.
ATM VP Average Traffic RateSee the ATM VP Average Traffic Rate, Release 12.2(33)SB feature
guide.
AToM Class-Based Match FR DEChapter 2, Classifying Traffic.
AToM Set ATM CLP Bit Using a PolicerSee the AToM Set ATM CLP Bit Using a Policer
section on page 6-13.
AToM Set Frame Relay DE as Police ActionSee the AToM Set FR DE as Police Action section
on page 6-14.
Class-Based Frame Relay DE Bit Matching and MarkingSee Chapter 2, Classifying Traffic and
the Class-Based Frame Relay DE Bit Marking section on page 7-17.

OL-7433-09
xxxv
About This Guide
Control Plane PolicingPlatform EnhancementSee the Control Plane PolicingPlatform

Enhancement, Release 12.2(33)SB feature guide.
Ethernet Overhead AccountingSee the Ethernet Overhead Accounting section on page 10-4.
MQCTraffic Shaping Overhead Accounting for ATMSee the Traffic Shaping Overhead
Accounting for ATM section on page 10-4.
MQC Support for IP SessionsSee the MQC Support for IP Sessions section on page 18-18.
Per-Session Shaping for ATM InterfacesSee the Per-Session Shaping for ATM Interfaces
Policy Map Scaling Phase 2See the System Limits for Policy Maps section on page 3-2.
QoS ModelsSee the QoS Models section on page 1-6.
Simultaneous QoS Policy Map on Interface and PPP Session A-DSLAM caseSee Chapter 14,
Simultaneous Policy Maps.
Traffic Shaping Overhead Accounting for ATMSee the Traffic Shaping Overhead Accounting
for ATM section on page 10-4.
Set Layer 2 CoS as a Policer ActionSee the Set Layer 2 CoS as a Policer Action section on
page 6-15.
Cisco IOS Release
Part Number
Publication Date
Release 12.2(31)SB6
OL-7433-05
July, 2007
Description
Added the following new features:
QoS: Per-Session Shaping and Queuing on LNSSee the Shaping and Queuing Per-Session
Traffic on LNS section on page 17-44.
PPP Session Queuing on ATM Virtual CircuitsSee the Queuing PPP Sessions on ATM VCs
Added the following new section:
qos match statistics CommandSee the qos match statistics Command section on page 2-4.
Cisco IOS Release
Part Number
Publication Date
Release 12.2(31)SB5
OL-7433-04
April, 2007
Description
Added the following new feature:
Per Session Queuing and Shaping for PPPoE Over VLAN Using RADIUSSee the ATM
Overhead Accounting section on page 10-2.
xxxvi
OL-7433-09
About This Guide
Cisco IOS Release
Part Number
Publication Date
Release 12.2(31)SB3
OL-7433-03
February, 2007
Description
The show pxf cpu queue atm command now displays dropped and dequeued packets for classes
associated with sessions that inherit queues from VCsSee the Verifying Traffic Shaping section
on page 9-17.
Cisco IOS Release
Part Number
Publication Date
Release 12.2(31)SB2
OL-7433-02
December, 2006
Description
Updated the valid multilink interface values. These values changed from 1 to 9999 (Release 12.2(28)SB
and later) to from 1 to 9999 and 65,536 to 2,147,483,647. See Multilink PPP-Based Link Fragmentation
and Interleaving section on page 16-11.
Child Service Policy Allowed Under Priority ClassSee the Applying Child Policies Under
Priority Classes section on page 13-12.
Class-Based Ethernet Class of Service Matching and MarkingSee the Defining Match Criteria
Using the match Commands section on page 2-5 and the Class of Service Marking section on
page 7-10.
Class-Based Weighted Fair Queuing (PRE3)See the Class-Based Weighted Fair Queuing
Classification, Policing, and Marking on the L2TP Access Concentrator (LAC)See Classifying
Traffic Policing Traffic and Marking Traffic
Control Plane PolicingSee the Control Plane Policing section on page 6-13.
Differentiated Services-Compliant WREDControlling Congestion Using Weighted Random

Early Detection section on page 11-11.
Distribution of Remaining Bandwidth Using RatioSee the Distribution of Remaining Bandwidth

Using Ratio section on page 5-14
Hierarchical Scheduling and QueuingSee Chapter 22, Hierarchical Scheduling and Queuing
Multi-Level Priority QueuesSee the Multi-Level Priority Queues section on page 8-3.
Percentage-Based ShapingSee the Percentage-Based Traffic Shaping section on page 9-8.
Policing Support for GRE TunnelsSee the Policing Support for GRE Tunnels section on
page 6-17.
PXF-Based Frame Relay DE Bit MarkingSee Class-Based Frame Relay DE Bit Marking
QoS CLI Migration from PRE2 to PRE3See the QoS CLI Migration from PRE2 to PRE3
Three-Level Scheduler Using MQC Hierarchical Queuing FrameworkSee Chapter 22,


OL-7433-09
xxxvii
About This Guide
Tunnel Header MarkingSee the Tunnel Header Marking section on page 7-18.
Traffic Shaping Overhead Accounting for ATMSee the Traffic Shaping Overhead Accounting
for ATM section on page 10-4.
VC Oversubscription (PRE3)See Chapter 15, Oversubscribing Physical and Virtual Links.
VLAN Tag-Based Quality of ServiceSee Chapter 21, VLAN Tag-Based Quality of Service.
Weighted RED support for the PRE3See Chapter 11, Managing Packet Queue Congestion.
Cisco IOS Release
Part Number
Publication Date
Release 12.2(28)SB2
OL-7433-01
July, 2006
Description
Changed the part number and added the following new QoS features:
Hierarchical Input PolicingSee the Hierarchical Input Policing Policies section on page 13-10.
Link fragmentation and interleaving (LFI) for Multilink PPP over ATM and Frame RelaySee
Chapter 16, Fragmenting and Interleaving Real-Time and Nonreal-Time Packets.
Two-Rate Three-Color Marker for traffic policingSee the Two-Rate Three-Color Marker for
Traffic Policing section on page 6-8.
For information about non-QoS features introduced in Cisco IOS Release 12.2(28)SB and existing
features integrated in the release, see the Cross-Platform Release Notes for Cisco IOS
Release 12.2(28)SB.
Cisco IOS Release
Part Number
Publication Date
Release 12.3(7)XI7
OL-4388-06
September, 2005
Description
DBS ExtensionsVC Weight and WatermarksSee the Dynamically Changing VC Weight and
Watermark Values section on page 17-18.
Per Session Queuing and Shaping for PPPoE Over VLAN Using RADIUSSee the ATM
Overhead Accounting section on page 10-2.
Added the following features from the Cisco 10000 Series Router Broadband Aggregation, Leased-Line,
and MPLS Configuration Guide:
PVC BundlesSee Chapter 19, Configuring Quality of Service for PVC Bundles.
MPLS QoSSee Chapter 20, Configuring Quality of Service for MPLS Traffic.
MPLS Traffic EngineeringDiffServ AwareSee Chapter 20, Configuring Quality of Service for
MPLS Traffic.
xxxviii
OL-7433-09
About This Guide
Cisco IOS Release
Part Number
Publication Date
Release 12.2
OL-4388-05
July, 2005
Define Interface Policy-Map AV Pairs AAASee the Applying QoS Parameters Dynamically to
Sessions section on page 17-24.
Dynamic Bandwidth SelectionSee the Applying Traffic Shaping Parameters Using RADIUS
Profiles section on page 17-2.
Per Session Rate LimitingSee the Per Session Rate Limiting section on page 18-3.
Per User Multiservice Rate LimitingSee the Per User Multiservice Rate Limiting section on
page 18-4.
Per Session Service Policy Using RADIUSSee the Per Session Service Policy Using RADIUS
Traffic Shaping and Hierarchical ShapingSee Chapter 9, Shaping Traffic.
Class-Based Weighted Fair QueuingSee Chapter 12, Sharing Bandwidth Fairly During
Congestion.
Cisco IOS Release
Part Number
Publication Date
Release 12.3(7)XI3
OL-4388-04
March, 2005
Description
LAC QoS on VCsSee the Attaching Layer 2 Access Concentrator QoS Service Policies section
on page 4-30.
Nested and 3-level hierarchical policiesSee Chapter 13, Defining QoS for Multiple Policy
Levels.
OversubscriptionSee Chapter 15, Oversubscribing Physical and Virtual Links.
Changed the title of Chapter 9 to Managing Packet Queue Congestion (formerly, Managing Packet
Queues).
Cisco IOS Release
Part Number
Publication Date
Release 12.0(25)SX
Release 12.3(7)XI
OL-4388-03
December, 2004
Description
Revised and reorganized the QoS Configuration Guide. Expanded both technical and configuration
information.
Added some of the QoS features currently in the Cisco 10000 Series Broadband and Leased-Line
Configuration Guide.

OL-7433-09
xxxix
About This Guide
Cisco IOS Release
Part Number
Publication Date
Release 12.0(23)SX1
Release 12.0(25)S
OL-4388-02
April, 2004
Description
Added strict priority queuing. Removed the ability to specify a rate using the priority command.
Cisco IOS Release
Part Number
Publication Date
Release 12.0(25)SX
OL-4388-01
June, 2003
Description
Created the Cisco 10000 Series Router Quality of Service Configuration Guide.
Audience
This guide is designed for system and network managers who are responsible for integrating quality of
service features into their networks. These managers should be experienced using Cisco IOS software
and should be familiar with the operation of the Cisco 10000 series router.
Document Organization
This guide contains the following chapters:
Chapter
Title
Description
Chapter 1
Describes the process and components involved in configuring

QoS on the router. Lists the QoS features supported and feature
changes.
Chapter 2
Classifying Traffic
Describes how to classify traffic using class maps.
Chapter 3
Configuring QoS Policy Actions and

Rules
Describes how to create QoS policies using policy maps and the
types of policy actions supported.
Chapter 4
Describes how to attach QoS policies to various interfaces.
Chapter 5
Distributing Bandwidth Between Queues Describes bandwidth allocation and how to use the bandwidth
command to distribute bandwidth between traffic queues.
Chapter 6
Policing Traffic
Describes traffic policing and how to configure policing for

traffic classes based on kilobits per second or as a percentage of
available bandwidth.
Chapter 7
Marking Traffic
Describes traffic marking and how to configure it on inbound

and outbound interfaces.
Chapter 8
Describes how to configure a traffic class as a priority class that

receives preferential treatment.
Chapter 9
Shaping Traffic
Describes the mechanisms used to shape traffic on the router.
xl
OL-7433-09
About This Guide
Chapter
Title
Description
Chapter 10
Overhead Accounting
Describes the overhead accounting features supported on the

router.
Chapter 11
Describes the mechanisms used to control packet queue

congestion.
Chapter 12
Sharing Bandwidth Fairly During

Congestion
Describes the Class-based Weighted Fair Queuing (CBWFQ)

feature and explains how to configure it.
Chapter 13
Defining QoS for Multiple Policy Levels Describes the types of hierarchical policies supported and how
to configure them.
Chapter 14
Describes how to simultaneously configure policy maps on

sessions and interfaces.
Chapter 15
Oversubscribing Physical and Virtual

Links
Describes interface, virtual circuit, and virtual LAN (VLAN)

oversubscription and how to configure it. Also describes VC
weighting.
Chapter 16
Fragmenting and Interleaving Real-Time Describes fragmentation and interleaving on the router and how
and Nonreal-Time Packets
to configure it.
Chapter 17
Configuring Dynamic Subscriber

Services
Describes how to use the following features:
Dynamic Bandwidth Selection (DBS) featureApply

traffic shaping parameters using RADIUS profiles
Define Interface Policy-Map AV Pairs AAA

featureApply QoS parameters dynamically to sessions
DBS ExtensionVC Weight and WatermarksModify

existing VC weight and watermark values without tearing
down and recreating the VC
Per Session Queuing and Shaping for PPPoE Over VLANs

Using RADIUS featureDynamically apply queuing and
shaping policies to PPPoE over VLAN sessions
Per Session Shaping and Queuing on LNSShape or queue

the traffic from an Internet service provider (ISP) to an ISP
subscriber over a Layer 2 Tunneling Protocol (L2TP)
Network Server (LNS).
PPP Session Queuing on ATM Virtual CircuitsShape and

queue PPP over ATM (PPPoA) and PPP over Ethernet over
ATM (PPPoEoA) sessions to a user specified rate.
Chapter 18
Regulating Subscriber Traffic
Describes subscriber-based traffic regulating and shaping

features.
Chapter 19
Configuring Quality of Service for PVC

Bundles
Describes PVC bundles and QoS-based PVC selection over

ATM and Frame Relay PVCs.
Chapter 20
Configuring Quality of Service for MPLS Describes the MPLS QoS feature and the MPLS Traffic
Traffic
EngineeringDiffServ Aware feature and how to configure
them.
Chapter 21
Describes the VLAN Tag-Based feature that enables you to

apply a single QoS policy to a group of IEEE 802.1Q VLAN
subinterfaces.

OL-7433-09
xli
About This Guide
Chapter
Title
Description
Chapter 22
Describes the hierarchical queuing framework (HQF)

architecture and the three-level scheduler that uses HQF.
Appendix A
Configuring Frame Relay QoS Using

Frame Relay Legacy Commands
Describes the Frame Relay commands used in early releases to

configure QoS on Frame Relay interfaces.
Appendix B
QoS Policy Propagation Through the

Border Gateway Protocol
Provides a configuration example for QoS policy propagation

through the Border Gateway Protocol (QPPB) and references
available documentation.
Document Conventions
This guide uses the following conventions:
Note
Caution
Warning
Bold is used for commands, keywords, and buttons.
Italics are used for command input for which you supply values.
Screen font is used for examples of information that are displayed on the screen.
Bold screen font is used for examples of information that you enter.
Vertical bars ( | ) indicate separate alternative, mutually exclusive elements.
Square brackets ( [ ] ) indicate optional elements.
Braces ( {} ) indicate a required choice.
Braces within square brackets ( [{}] ) indicate a required choice within an optional element.
Means reader take note. Notes contain helpful suggestions or references to material not covered in the
guide.
Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
IMPORTANT SAFETY INSTRUCTIONS

This warning symbol means danger. You are in a situation that could cause bodily injury. Before you
work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar
with standard practices for preventing accidents. Use the statement number provided at the end of
each warning to locate its translation in the translated safety warnings that accompanied this
device.
SAVE THESE INSTRUCTIONS
xlii
OL-7433-09
About This Guide
Each chapter of this guide provides additional documentation you can reference for more information
about specific features.
The Cisco 10000 Series Router Quality of Service Configuration Guide is one of the documents available
for the Cisco series router. Each Cisco 10000 series router document provides specific hardware and
software information to help you integrate and use the router in your network configuration. For a list of
available Cisco 10000 series router documentation, see the following URL:
http://www.cisco.com/en/US/products/hw/routers/ps133/tsd_products_support_series_home.html
Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional
information, see the monthly Whats New in Cisco Product Documentation, which also lists all new and
revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the Whats New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed
and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free
service and Cisco currently supports RSS Version 2.0.

OL-7433-09
xliii
About This Guide
xliv
OL-7433-09
CH A P T E R

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. The QoS features available on the Cisco 10000 series
router provide the following services:
Congestion management
Congestion control
Traffic policing
Traffic shaping
Ability to handle differential services and queuing requirements
This chapter provides an overview of QoS on the Cisco 10000 series router and includes the following
topics:
Benefits of Quality of Service Features, page 1-2
Restrictions and Limitations for Quality of Service, page 1-2
Modular QoS Command-Line Interface, page 1-2
QoS Management Information Base Support, page 1-4
QoS Implementation Guidelines, page 1-4
QoS Execution on the Router, page 1-4
QoS Configuration on an Interface, page 1-5
QoS Models, page 1-6
QoS Features, Commands, and Changes, page 1-11
Related Documentation, page 1-61

OL-7433-09
1-1
Chapter 1

Quality of service (QoS) features enable you to create differentiated services on your network that you
can use to:
Give preferential treatment to different classes of network traffic
Ensure sufficient bandwidth to meet average network loads
Determine the network response during times of congestion
Classify traffic so that different applications or traffic classes receive treatment in accordance with
defined requirements
Ensure adequate resources are allocated so that the network delivers the performance the customer
requires
Restrictions and Limitations for Quality of Service
The ability to apply a QoS feature to an interface does not imply support for all QoS features on the
interface.
The router does not have a limit on the number of interfaces that can have a QoS policy.
Trunk interfaces require multiple flows to achieve line-rate performance at packet sizes smaller than
250 bytes.
A service-policy should not be attached to an interface that has an IP interface session.
Note
A flow consists of IP packets with the same source and destination addresses.
Modular QoS Command-Line Interface

To configure QoS features, use the modular quality of service command-line interface (MQC).
For Frame Relay, you can configure QoS features using the:
Note
MQC, applied on the physical interface
MQC, applied on point-to-point Frame Relay subinterfaces (Release 12.0(19)SL or later)
Frame Relay QoS command-line interface (CLI)
The router does not support interface-based, legacy QoS commands such as the rate-limit and
traffic-shape interface configuration commands. For information on these commands, see Appendix A,
The following apply when you configure QoS on Frame Relay:
When you apply a service policy on the physical interface instead of on the individual subinterfaces,
the aggregate traffic from all PVCs is subject to the service policy. This allows you to apply QoS
policies independently of PVCs.
When you apply a service policy on a Frame Relay point-to-point subinterface, only the subinterface
traffic is subject to the service policy.
1-2
OL-7433-09
Chapter 1

Modular QoS Command-Line Interface
Using the legacy Frame Relay QoS CLI, you can enable Weighted Random Early Detection
(WRED), traffic shaping, fair queuing, and low-latency queuing on a PVC basis.
Using the MQC, you can configure the following elements:
Class mapDefines the criteria by which packets are classified.
Policy mapDefines the actions to be taken on the traffic matching the class map criteria.
Service policyAttaches the service policy to an interface and specifies if the policy is to be applied
to inbound or outbound traffic.
For more information about class maps, policy maps, and service policies, see the following chapters in
this guide:
Chapter 2, Classifying Traffic
Chapter 3, Configuring QoS Policy Actions and Rules
Chapter 4, Attaching Service Policies
Feature History for MQC

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The MQC feature was introduced on the PRE1.
PRE1
Release 12.2(15)BX
This feature was introduced on the PRE2.
PRE2
Release 12.2(28)SB
This feature was integrated in Cisco IOS

Release 12.2(28)SB for the PRE2.
PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3 and included the PRE3
new qos match statistics command.
Enhancements to the MQC allow you to classify packets
on the L2TP access concentrator (LAC) based upon the IP
type of service (ToS) bits in an embedded IP packet. When
a policer is configured, the router uses the packet
classification to police ingress traffic according to the
DSCP value.
Release 12.2(33)SB
PRE4
QoS CLI Migration from PRE2 to PRE3

The Quality of Service (QoS) Command Line Interface (CLI) Migration from PRE2 to PRE3 feature
provides QoS CLI backward-compatibility between the PRE2 and PRE3, thereby enabling the PRE3 to
accept PRE2-style commands.
The PRE2 uses a proprietary version of the modular QoS CLI, while the PRE3 uses a non-proprietary
CLI. The QoS CLI migration feature enables the PRE3 to parse PRE2-style commands and translate
them to PRE3 commands.
For more information, see the QoS CLI Migration from PRE2 to PRE3, Release 12.2(31)SB2 feature
module.

OL-7433-09
1-3
Chapter 1
Feature History for QoS CLI Migration from PRE2 to PRE3

Cisco IOS Release
Description
Required PRE
Release 12.2(31)SB2
This feature was introduced.
PRE3
Release 12.2(33)SB
PRE4

The Cisco 10000 series router supports the Cisco Class-Based Quality of Service Management
Information Base (Class-based QoS MIB). This MIB provides read access to QoS configurations and
also provides QoS statistical information based on the modular QoS CLI (MQC), including information
about class map and policy map parameters.
The Class-based QoS MIB is actually two MIBs: CISCO-CLASS-BASED-QOS-MIB and
CISCO-CLASS-BASED-QOS-CAPABILITY-MIB.
To locate MIBs online, use the Cisco Network Management Toolkit for MIBs tool available on
Cisco.com.
QoS Implementation Guidelines

Typically, the business model that you define and the applications you use determine the QoS features
needed to meet your network requirements. Before deciding which QoS features to implement, consider
the following guidelines:
Provide preferential service to customers or applications that cannot tolerate dropped packets during
periods of congestion.
Provide dedicated bandwidth and low-latency queuing to privileged data that cannot tolerate delay.
Share the bandwidth fairly among competing traffic. For example, allocate percentages of a link
bandwidth to the various applications.
Prevent congestion by using congestion control algorithms such as random early detection (RED)
and weighted random early detection (WRED), instead of using the default tail drop mode of
operation.
Police and shape transmission rates to limit and control traffic that exceeds predefined transmission
rate limits.
Identify, set, or modify traffic priorities to provide end-to-end service quality.
QoS Execution on the Router

The Cisco 10000 series router executes the QoS features in the following order:
1.
Fragment reassembly
2.
QoS Policy Propagation through Border Gateway Protocol (QPPB)
3.
Input classification
4.
Input marking
1-4
OL-7433-09
Chapter 1

5.
Input metering (policing)
6.
Output classification
7.
Output marking
8.
Output metering (policing)
9.
Bandwidth distribution, priority service, traffic shaping, random early detection (RED), and tail
drop
10. Fragmentation

The QoS service policy attached to an interface tells the Cisco 10000 series router how to handle packets
received on the interface. Service policies consist of:
Classification criteriaDefined in class maps and tell the router how to classify packets received on
the interface.
ActionsDefined in policy maps and tell the router the actions and rules to apply to the packets.
To configure a QoS service policy on an interface, do the following:

Step 1
Create a class map. (See Chapter 2, Classifying Traffic.)
Step 2
Create a policy map. (See Chapter 3, Configuring QoS Policy Actions and Rules.)
Step 3
Attach the service policy to an interface. (See Chapter 4, Attaching Service Policies.)
Figure 1-1 shows the process of QoS configuration on an interface.

Quality of Service Process
Class-map commands
tell the router how to
recognize a packet
that is subject to QoS.
Interface
Packet
Line
Card
Service policy command

applies a class-map
and policy-map to a
specific interface.
Backplane
Packet
Performance
Routing
Engine
Packet
Backplane
Packet
Interface
Line
Card
Policy-map commands
tell the router what
to do with a packet.
For example , drop the
packet or let it through.
Packet
126558
Figure 1-1

OL-7433-09
1-5
Chapter 1
QoS Models
QoS Models
This section defines two QoS models with respect to Ether-DSL aggregation, supported on the Cisco
10000 series router. It includes the following topics:
Overview of QoS Models, page 1-6
Configuration Tasks, page 1-8
Configuration Examples, page 1-9
Overview of QoS Models

The E-DSL QoS models are defined based on whether its requirement is generic to all services or
specific to residential or business services.
Generic requirements are common to all subscriber lines regardless of whether they support residential
or business services. Generic requirements per subscriber line include the following:
Avoid indiscriminate loss of traffic downstream at the DSLAM
Minimum assured rate per service or class
Maximum enforced rate per service or class
Ability for one service or class of a particular subscriber to re-use unused bandwidth from another
service or class for the same subscriber.
Business services additionally include the following requirements:
Single point of traffic injection
Enforce a sub modem train rate max (shaped) aggregate rate per subscriber line
Child queuing policy
Analogous to current Layer 3 VPN access QOS services
Residential services additionally include the following requirements:
Support multiple points of traffic injection into the Layer 2 access network
Wholesale bandwidth concept analogous to a virtual path in ATM-DSL
Per session services
Support VLAN aggregation
The two DSLAM model configurations that are supported on Cisco 10000 series router for business and
residential services are:
Model D.2 Definition, page 1-7
Model F Definition, page 1-7
Note
QoS Models D.2 and F are supported on PRE3 and PRE4.
1-6
OL-7433-09
Chapter 1

QoS Models
Model D.2 Definition

This model is equivalent to the ATM-DSL model where shaped virtual circuits (VCs) terminate on an
interface, without shaped virtual paths (VPs). In this model all QoS control is maintained at the
broadband remote access server or network processing engine (BRAS / NPE) and none at the DSLAM.
The traffic to each subscriber line is shaped to less than or equal to the DSLAM modem train rate. This
shaping at the BRAS / NPE accounts for the ATM overhead on the DSLAM-to-CPE link, even though
the downstream interface on the BRAS / NPE is an Ethernet interface.
The subscriber line is represented by individual or groups of IP or Point-to-Point Protocol (PPP)
sessions. The policy for per class policing or marking is applied per PPP or IP session.
The key components of Model D.2 are shown in Figure 1-2.
Figure 1-2
Key Components of Model D.2
Upstream and downstream

per subs/session per class:
1 rate 2 color policer
Treated as any other
trunk network:
Could use per class
PQ+CBQ, or
overprovision
No QOS supported
BRAS
PE-AGG / UPE
E-DSLAM
270995
Downstream per
subscriber line:
shape/min bw
per class PQ +
CBQ+ WRED
CPE
bw = bandwidth
PQ = Priority Queue
CBQ = Class Based Queue
WRED = Weighted Random Early Detection
Model F Definition
This model is functionally equivalent to the ATM model with shaped virtual paths (VPs) and shaped
virtual circuits (VCs). Similar to the Model D.2, this model has all QOS control at the broadband remote
access server or network processing engine (BRAS / NPE) and none at the DSLAM.
The traffic to a group of subscriber lines is shaped to a defined rate, equivalent to a virtual path in ATM.
In the case of residential services, a group of subscribers is represented by a VLAN, and for business
services a group of subscribers is represented by the outer 802.1q tag.
The traffic to individual subscriber lines is shaped to less than or equal to the DSLAM modem train rate.
The subscriber line for business services is identified by the inner and outer 802.1q tag. The subscriber
line is represented by individual or groups of IP or PPP sessions.
QoS Model F requires 3 levels of shaping, queuing and scheduling Subinterface / Session / Class
queues.
The key components of Model F are shown in Figure 1-3.

OL-7433-09
1-7
Chapter 1
QoS Models
Figure 1-3
Key Components of Model F
ISP aggregate:
shape/min bw
Treated as any other

trunk network:
Could use per class
PQ+CBQ, or
overprovision
Downstream per
subscriber line:
shape/min bw
per class PQ+CBQ
Upstream and
downstream per ISP
aggregate per class:
police
No QOS supported
270996
Upstream and downstream,

per session per class:
1 rate 2 color policer
BRAS/NPE
PE-AGG/UPE
E-DSLAM
CPE
Configuration Tasks
Model D.2 supports two types of configurations:
Configuration on subinterfaces consists of hierarchical policy-maps attached to QinQ

subinterfaces, as shown in Example 1-1.
Configuration on IP or PPP sessions consists of hierarchical queuing policy-maps on IP or PPP

sessions, as shown in Example 1-2.
Configuration Steps on Subinterfaces for QoS Model D.2

To configure subinterfaces for QoS Model D.2 follow the steps given below:
Step 1
Discover the GigabitEthernet (GE) interface.
Step 2
Create subinterfaces on the GE interface.
Step 3
Apply policy-map to Subint 1.
Step 4
Apply policy-may to Subint 2.
Configuration Steps on Sessions for QoS Model D.2

To configure sessions for QoS Model D.2 follow the steps given below:
Step 1
Discover the GE interface.
Step 2
Create sessions on the GE interface.
Step 3
Apply policy-map to session S1.
Step 4
Apply policy-map to session S2.
1-8
OL-7433-09
Chapter 1

QoS Models
Model F supports multiple IP and/or PPP sessions per subscriber line with shaping occurring at the
subscriber line level, by using the line ID information present in DHCP option 82 and the PPP tag.
Shaping sessions with a common line ID effects traffic shaping for a particular subscriber line. See
Example 1-3 for more configuration information.
Model F configuration requires three levels of shaping/queuing hierarchy on the BRAS or NPE at the
Subinterface, Session and Class levels.
Configuration Steps for QoS Model F

To configure QoS Model F follow the steps given below:
Step 1
Discover the GE interface.
Step 2
Create subinterface1 on the GE interface.
Step 3
Apply isp_A shape policy to subinterface1.
Step 4
Create sessions on subinterface 1.
Step 5
Apply session-parent policy-map to session S1 belonging to subinterface1
Configuration Examples
An example of Model D.2 subinterface configuration is described in Example 1-1.
Example 1-1
Configuring Model D.2 Subinterface Configuration
Policy business-A-child
class voip
priority level 1
police <rate> <nb>
set cos <cos>
class video
priority level 2
police <rate> <nb>
set cos <cos>
class gaming
bandwidth remaining ratio <i> [account qinq aalx xxx]
set cos <cos>
class class-default
bandwidth remaining ratio <j> [account qinq aalx xxx]
set cos <cos>
Policy company-A-parent
class class-default
bandwidth remaining ratio <number> [account qinq aalx xxx]
shape average <cir> <nb> [account qinq aalx xxx]
service policy business-A-child
interface GigabitEthernet1/0/0.n
description Company A
encapsulation dot1q 1 second-dot1q n
service-policy output company-A-parent
interface GigabitEthernet1/0/0.m
description Company B
encapsulation dot1q 1 second-dot1q m
service-policy output company-B-parent

OL-7433-09
1-9
Chapter 1
QoS Models
An example of Model D.2 session configuration is described in Example 1-2.

Example 1-2
Model D.2 Session Configuration
Policy session-A-child
class voip
priority level 1
police <rate> <nb>
set cos <cos>
class video
priority level 2
police <rate> <nb>
set cos <cos>
class gaming
bandwidth remaining ratio <i> [account xxx aalx xxx]
set cos <cos>
class class-default
bandwidth remaining ratio <j> [account xxx aalx xxx]
set cos <cos>
Policy session-A-parent
bandwidth remaining ratio <number> [account xxx aalx xxx]
shape average <cir> <nb> [account xxx aalx xxx]
service policy session-A-child
Session-N-parent policy-maps attached to PPP/IP sessions via Radius or via a
Virtual-Template
An example of Model F configuration is described in Example 1-3.

Example 1-3
QoS Model F Configuration
Policy session-N-child
class voip
priority level 1
police <rate> <nb>
set cos <cos>
class video
priority level 2
police <rate> <nb>
set cos <cos>
class gaming
bandwidth remaining ratio <i> [account xxx aalx xxx]
set cos <cos>
class class-default
bandwidth remaining ratio <j> [account xxx aalx xxx]
set cos <cos>
Policy session-N-parent
class class-default
bandwidth remaining ratio <number> [account xxx aalx xxx]
shape average <cir> <nb> [account xxx aalx xxx]
service-policy session-N-child
Policy isp_A
class class-default
shape average
interface GigabitEthernet1/0/0.1
encapsulation dot1q 1
service-policy output isp_A
1-10
OL-7433-09
Chapter 1

QoS Features, Commands, and Changes
Or
encapsulation dot1q 1 second-dot1q any
service-policy output isp_A
Session-N-parent policy-maps attached to PPP/IP sessions via Radius or via
Virtual-Templates.

This section describes the QoS features and commands supported on the Cisco 10000 series router, and
lists feature and command changes. It includes the following topics:
Applying QoS Parameters Dynamically to Sessions, page 1-12
Applying Traffic Shaping Parameters Using RADIUS Profiles, page 1-12
Attaching QoS Service Policies, page 1-13
Classifying Traffic, page 1-15
Configuring QoS for MPLS Traffic, page 1-18
Control Plane Policing, page 1-19
Controlling Packet Queue Congestion, page 1-21
Distributing Bandwidth Between Queues, page 1-25
Dynamically Changing VC Weight and Watermark Values, page 1-26
Hierarchical Queuing Framework, page 1-27
Hierarchical Policies, page 1-27
IP Quality of Service for Subscribers, page 1-29
Layer 2 Access Concentrator, page 1-30
Link Fragmentation and Interleaving, page 1-31
Marking Traffic, page 1-36
Modular QoS Command Line Interface, page 1-39
Overhead Accounting, page 1-39
Oversubscribing Physical and Virtual Links, page 1-41
Policing Traffic, page 1-44
Prioritizing Traffic, page 1-48
PVC Bundles, page 1-50
QoS Policy Maps, page 1-53
Qos Policy Propagation through the Border Gateway Protocol, page 1-55
Shaping PPPoE Over VLAN Sessions Using RADIUS, page 1-55
Shaping Traffic, page 1-55
Sharing Bandwidth Fairly During Congestion, page 1-59
Simultaneous Policy Maps, page 1-60

OL-7433-09
1-11
Chapter 1
VLAN Tag-Based Quality of Service, page 1-60
Applying QoS Parameters Dynamically to Sessions

Documentation Reference: Chapter 18, Regulating and Shaping Subscriber Traffic
Cisco IOS Release: Release 12.3(7)XI2
Description: The Define Interface Policy-Map AV Pairs AAA feature was introduced on the PRE2 to
provide two RADIUS vendor-specific attributes (VSAs): cisco-avpair = atm:vc-qos-policy-in=<in
policy name> and cisco-avpair = atm:vc-qos-policy-out=<out policy name>. These VSAs allow you
to apply (pull) a policy map on an ATM virtual circuit (VC) during Point-to-Point Protocol over ATM
(PPPoA) or PPP over Ethernet over ATM (PPPoEoA) session establishment.
Cisco IOS Release: Release 12.2(28)SB
Description: This feature was integrated in Cisco IOS Release 12.2(28)SB and enhanced to provide
push functionality.

Documentation Reference: Chapter 17, Configuring Dynamic Subscriber Services
dbs enable Command, page 1-12
default dbs enable Command, page 1-12
Dynamic Bandwidth Selection Feature, page 1-13
dbs enable Command

Cisco IOS Release: Release 12.2(16)BX
Description: The dbs enable command was introduced on the PRE2 to enable dynamic bandwidth
selection.
Description: This command was integrated in Cisco IOS Release 12.2(28)SB.
default dbs enable Command

Description: The default dbs enable command was introduced on the PRE2 to remove the dbs enable
or no dbs enable command from an existing configuration.
1-12
OL-7433-09
Chapter 1

Dynamic Bandwidth Selection Feature

Description: The Dynamic Bandwidth Selection (DBS) feature was introduced on the PRE2 to
dynamically change ATM traffic shaping parameters based on a subscribers RADIUS profile. This
feature is also known as Per User QoS Using AAA Policy Name.
Description: This feature was integrated in Cisco IOS Release 12.2(28)SB.
Attaching QoS Service Policies

Documentation Reference: Chapter 4, Attaching Service Policies
service-policy Command, page 1-13
Attaching ATM QoS Service Policies, page 1-14
Attaching Frame Relay QoS Service Policies, page 1-14
Attaching LAC QoS Service Policies, page 1-15
Attaching Virtual LAN QoS Service Policies, page 1-15
Attaching Virtual Access Interface QoS Service Policies, page 1-15
service-policy Command
Cisco IOS Release: Release 12.0(17)SL
Description: The service-policy command was introduced on the PRE1 to attach a policy map that the
router can use to apply QoS services to inbound and outbound packets.
Description: This command was introduced on the PRE2.
Description: This command was enhanced on the PRE2 to allow you to attach a policy map to a range
of PVCs, and to a specific PVC within the PVC range.
Cisco IOS Release: Release 12.2(31)SB2

OL-7433-09
1-13
Chapter 1
Attaching ATM QoS Service Policies

Description: The ATM QoS service policies feature was introduced on the PRE1 to enable you to attach
QoS policies to ATM interfaces, subinterfaces, and permanent virtual circuits (PVCs).
Cisco IOS Release: Release 12.0(22)S
Description: This feature was ported to the S train.
Description: This feature was introduced on the PRE2.
Description: This feature was enhanced on the PRE2 to enable you to attach QoS policies to a range of
PVCs and to a specific PVC within the PVC range.
Attaching Frame Relay QoS Service Policies

Cisco IOS Release: Release 12.0(23)SX
Description: The Frame Relay QoS service policies feature was introduced on the PRE1 to enable you
to attach QoS policies to Frame Relay interfaces, subinterfaces, and data-link connection identifiers
(DLCIs).
Description: This feature was ported to the S train.
1-14
OL-7433-09
Chapter 1

Attaching LAC QoS Service Policies

Description: The LAC QoS feature was introduced on the PRE2 to enable you to attach QoS service
policies to ATM virtual circuits (VCs) on the Layer 2 Access Concentrator (LAC).
Attaching Virtual LAN QoS Service Policies

Description: The virtual LAN (VLAN) QoS service policies feature was introduced on the PRE2 to
enable you to attach QoS policies to a physical Ethernet interface, an individual VLAN subinterface, or
to both the physical interface and one or more VLAN subinterfaces.
Attaching Virtual Access Interface QoS Service Policies

Description: The virtual access interface (VAI) QoS service policies feature was introduced on the
PRE2 to enable you to apply virtual template interfaces with QoS policies to VCs. When the router
creates the VAI for a session, the router applies the QoS policies to the VAI.
Classifying Traffic
Documentation Reference: Chapter 2, Classifying Traffic
class-map Command, page 1-15
match Commands, page 1-16
Class Map Feature, page 1-18
class-map Command
Description: The class-map command was introduced on the PRE1 to enable you to configure a
classification policy for traffic classes.

OL-7433-09
1-15
Chapter 1

Enhancements to the modular quality of service CLI (MQC) allow you to classify packets on the L2TP
access concentrator (LAC) based upon the IP type of service (ToS) bits in an embedded IP packet. The
classification is used to police ingress traffic according to the DSCP value.
match Commands
Description: The match command was introduced on the PRE1 to enable you to define the following
match criteria for a class map:
match-all CommandIndicates that a packet must match all of the match criteria specified.
match-any CommandIndicates that a packet must match only one of the match criteria specified.
match access-group CommandIndicates that a packet must match one of the predefined access
control list (ACL) statements.
match input-interface CommandIndicates that the input interface on which the packet arrives
must match the value you set using the set input-interface command.
match ip dscp CommandIndicates that the IP DSCP value of the packet must match the value you
set using the set ip dscp command.
match ip precedence CommandIndicates that the IP precedence value of the packet must match
the value you set using the set ip precedence command.
match ip rtp CommandIndicates that the IP Real-Time Transport Protocol (RTP) value of the
packet must match the value you set using the set ip rtp command.
match qos-group CommandIndicates that the QoS group value of the packet must match the
value you set using the set qos-group command.
match not CommandIndicates that the packet must not match the criteria you set. You can use
the match not command with any match criteria.
For example, to classify packets that do not have a specific class of service value, enter the
match not cos command in the appropriate class map as a match criterion. The router classifies a
packet when the CoS value of the packet does not match the value you set using the set cos
command.

Description: This command was enhanced to enable you to match the MPLS experimental (EXP) bit
value of the class. If you specify the match mpls experimental command, the router classifies a packet
when the MPLS EXP value of the packet matches the value you set using the set mpls experimental
command. The match mpls experimental command is available only on the PRE1.
1-16
OL-7433-09
Chapter 1


Description: This command was enhanced to enable you to match on the class of service of a packet.
When you specify the match cos command, packets that match the value you set using the set cos
command are assigned to the associated traffic class. The match cos command is available only on the
PRE2.
Description: This command was enhanced on the PRE2 to enable you to match the experimental (EXP)
value in the topmost label of the packet. The match mpls experimental topmost command is available
only on the PRE2.
Note
The router does not support the set mpls experimental topmost command.
Cisco IOS Release: Release 12.3(7)XI

Description: This command was enhanced on the PRE2 to enable you to match the MPLS experimental
(EXP) bit value on the imposed label entry of the packet. When you specify the match mpls
experimental imposition command, the router classifies a packet when the MPLS EXP value on the
imposed label entry of the packet matches the value you set using the set mpls experimental imposition
command. This command is available only on the PRE2.
The match command was also enhanced to enable you to match the discard value of the class. The
discard value indicates the drop eligibility of a packet. When you specify the match discard-class
command, the router classifies a packet when the discard value of the packet matches the value you set
using the set discard-class command. The match discard-class command is available only on the
PRE2.
Description: The match commands were integrated in Cisco IOS Release 12.2(28)SB.
Description: This command was introduced on the PRE3 to enable you to match on the class of service
of a packet. When you specify the match cos command, packets that match the value you set using the
set cos command are assigned to the associated traffic class. The match cos command is available on
the PRE2 and PRE3.

OL-7433-09
1-17
Chapter 1

Description: This command was enhanced to enable you to match the Frame Relay discard eligibility
(DE) bit value, and was implemented on the PRE2, PRE3, and PRE4.
Class Map Feature

Description: The class map feature was introduced on the PRE1 to enable you to create and modify a
classification policy for traffic classes.
Configuring QoS for MPLS Traffic

Documentation Reference: Chapter 20, Configuring Quality of Service for MPLS Traffic
MPLS CoS Multi-VC Mode, page 1-18
MPLS QoS Feature, page 1-19
MPLS Traffic EngineeringDiffServ Aware Feature, page 1-19
MPLS CoS Multi-VC Mode

Description: The MPLS CoS Multi-VC Mode feature was introduced on the PRE1 to enable you to map
the experimental (EXP) field values of an MPLS label to an ATM VC, creating sets of labeled virtual
circuits (LVCs) to provide varying levels of QoS services for different types of traffic in an MPLS
network.
1-18
OL-7433-09
Chapter 1


MPLS QoS Feature

Description: The MPLS QoS feature was introduced on the PRE1 to provide varying levels of QoS
services for different types of traffic in an MPLS network.
Description: This feature was enhanced to allow classification and marking based on the MPLS
experimental (EXP) field.
MPLS Traffic EngineeringDiffServ Aware Feature

Description: The MPLS Traffic EngineeringDiffServ Aware (DS-TE) feature was introduced on the
PRE2 to provide stricter quality of service (QoS) guarantees.

Documentation Reference: Control Plane PolicingPlatform Enhancement, Release 12.2(33)SB
feature guide
Divert Cause Policer, page 1-19
Control Plane PolicingPlatform Enhancement, page 1-20
Divert Cause Policer

Description: The Divert Cause Policer was introduced on the PRE3.

OL-7433-09
1-19
Chapter 1

Description: This feature was enhanced on the PRE3 and introduced on the PRE4 to enable you to
configure the rate and burst size of the divert cause policer. See the Control Plane PolicingPlatform
Enhancement feature.
Control Plane PolicingPlatform Enhancement

Description: The Control Plane PolicingPlatform Enhancement feature was introduced on the PRE3
and PRE4 and included:
User-Level Punt Monitoring, page 1-20
Configurable Rate and Burst Size for the Divert Cause Policer, page 1-20
Drop Alarms for Packet Drops by the To-RP Queues and Divert Cause Policer, page 1-20
User-Level Punt Monitoring

Description: The User-Level Punt Monitoring feature was introduced on the PRE3 and PRE4 to prevent
a denial of service (DoS) attack. Using this feature, you can monitor individual users and display
statistical information about traffic that the PXF engine sends (punts) to the route processor (RP).
Configurable Rate and Burst Size for the Divert Cause Policer
Description: The Configurable Rate and Burst Size for the Divert Cause Policer feature was introduced
on the PRE3 and PRE4 to configure the rate and burst size of the divert cause policer.
Drop Alarms for Packet Drops by the To-RP Queues and Divert Cause Policer
Description: The Drop Alarms for Packet Drops by the To-RP Queues and Divert Cause Policer feature
was introduced on the PRE3 and PRE4 to monitor possible DoS attacks by sending warning messages
(alarms) to the console and the syslog log file to alert you when a change in drop activities occurs, such
as packet drops due to congestion in the To-RP queues or due to aggregated traffic that violates the divert
cause policer.
1-20
OL-7433-09
Chapter 1

Controlling Packet Queue Congestion

Documentation Reference: Chapter 11, Managing Packet Queue Congestion
queue-limit Command, page 1-21
random-detect Command, page 1-22
random-detect basis Command, page 1-23
show pxf cpu queue interface summary, page 1-23
Tail Drop Feature, page 1-23
Random Early Detection Feature, page 1-24
Weighted Random Early Detection Feature, page 1-24
queue-limit Command
Description: The queue-limit command was introduced on the PRE1 to allow you to specify or modify
the maximum number of packets that a particular class queue can hold.
Description: This command was enhanced on the PRE1 to allow you to simultaneously configure both
the queue-limit and random-detect commands in the same class of a policy map.
Description: This command was introduced on the PRE2 without the ability to simultaneously
configure the random-detect command and the queue-limit command for the same class queue.
Description: This command was enhanced on the PRE2 to allow you to simultaneously configure both
the queue-limit and random-detect commands in the same class of a policy map.

OL-7433-09
1-21
Chapter 1
random-detect Command
Description: The random-detect command was introduced on the PRE1 to configure a random early
detection drop policy for a traffic class that includes a bandwidth guarantee. The command allows you
to configure a drop policy based on IP precedence. An exponential-weight-constant option allows you
to change the default method random-detect uses to calculate the average queue size.
Cisco IOS Release: Release 12.0(21)ST
Description: This command was enhanced to support the MPLS experimental (EXP) field.
Description: This command was enhanced to allow you to configure a drop policy based on a
differentiated services code point (DSCP).
Description: This command was enhanced to allow you to simultaneously configure the random-detect
command and the queue-limit command for the same class queue.
Description: This command was enhanced on the PRE2 to:
Enable the configuration of eight unique drop precedence levels for one queue instead of four levels
Allow the simultaneous configuration of both the random-detect and queue-limit commands for a
class queue
Support discard-class-based WRED
Maintain separate WRED drop statistics for each IP precedence, discard-class, and DSCP value

Description: This command was enhanced to support the atm-clp clp-value option and implemented on
the PRE2, PRE3, and PRE4. This option allows you to specify a number that indicates the drop eligibility
of a packet based on the ATM CLP bit. Valid values are 0 or 1.
1-22
OL-7433-09
Chapter 1

random-detect basis Command

Description: The random-detect basis command was introduced on the PRE1 with the dscp-based and
prec-based options to enable a weighted random early detection (WRED) drop policy based on a DSCP
value or IP precedence level.
Description: This command was enhanced to enable a drop policy based on a discard-class value. The
discard-class-based option is available only on the PRE2 for Cisco IOS Release 12.3XI images.
Description: This command was integrated in Cisco IOS Release 12.2(28)SB with the dscp-based,
prec-based, and discard-class-based options.
Description: This command was introduced on the PRE3 with the dscp-based, prec-based, and
discard-class-based options.
Description: This command was enhanced to include the atm-clp-based option and implemented on the
PRE2, PRE3, and PRE4.
show pxf cpu queue interface summary

Description: The show pxf cpu queue interface summary command was modified to display only the
physical interface and the number of logical links, and implemented on the PRE3 and PRE4. The output
of the command no longer displays the number of priority queues, class queues and so on.
Tail Drop Feature

Description: The tail drop feature was introduced on the PRE1 to allow you to manage congestion of a
queue. When a queue reaches its configured queue limit, tail drop activates and drops packets. Tail drop
continues to drop packets until the queue is no longer full. Tail drop is the default mechanism used to
control congestion.

OL-7433-09
1-23
Chapter 1

Random Early Detection Feature

Cisco IOS Release: 12.0(17)SL
Description: The random early detection (RED) feature was introduced on the PRE1 to enable the
configuration of a packet drop policy. RED is a mechanism that is used to control congestion by
randomly discarding packets before a queue reaches its queue limit.
Description: This feature was enhanced to include RED based on a differentiated services code point
(DSCP). For the PRE1, DSCP-based RED supports one default drop profile per class, three assured
forwarding (AF) drop profiles per class, and four non-AF drop profiles per policy map.
Description: This feature was enhanced to allow you to simultaneously configure a packet drop policy
for a class queue (using the random-detect command) and the size of the class queue (using the
queue-limit command).
Weighted Random Early Detection Feature

Description: The weighted random early detection (WRED) feature was introduced on the PRE1 to
provide preferential handling of higher priority packets. WRED allows drop policies based on a
differentiated services code point (DSCP) and IP precedence levels.
Description: This feature was enhanced to include WRED based on a differentiated services code point
(DSCP).
Description: This feature was enhanced to allow you to simultaneously configure a packet drop policy
for a class queue (using the random-detect command) and the size of the class queue (using the
queue-limit command).
1-24
OL-7433-09
Chapter 1


Description: This feature was enhanced on the PRE2 to:
Enable the configuration of eight unique drop precedence levels for one queue instead of four levels
Allow the simultaneous configuration of both the random-detect and queue-limit commands for a
class queue
Maintain separate WRED drop statistics for each IP precedence, discard-class, and DSCP value

Description: This feature was integrated in Cisco IOS Release 12.2(28)SB on the PRE2.
Description: This feature was introduced on the PRE3. It provides DiffServ-compliant WRED and uses
per-packet RED.
Description: ATM cell loss priority-based WRED was introduced on the PRE3 and PRE4 to configure
a drop policy for WRED based on the CLP value.

Documentation Reference: Chapter 5, Distributing Bandwidth Between Queues
bandwidth Command, page 1-25
bandwidth remaining ratio Command, page 1-26
Distribution of Remaining Bandwidth Using Ratio, page 1-26
bandwidth Command
Description: The bandwidth command was introduced on the PRE1 to enable bandwidth fair queuing
and to create multiple class queues based on bandwidth.
Description: This command was enhanced to include the percent option.
Description: This command was enhanced to include the remaining percent option.

OL-7433-09
1-25
Chapter 1

Description: This command was introduced on the PRE2 and included the kilobits per second (kbps),
percent, and remaining percent options.
Description: This command supports per-session shaping and queuing on a L2TP Network Server
(LNS) on the PRE3.
Description: This command was enhanced to support overhead accounting.
Description: This command was enhanced to support a user-defined offset, which the router uses when
calculating overhead.
bandwidth remaining ratio Command

Description: The bandwidth remaining ratio command was introduced on the PRE3.
Distribution of Remaining Bandwidth Using Ratio

Description: The distribution of remaining bandwidth using ratio feature was introduced on the PRE3
to allow you to prioritize subscriber traffic during periods of congestion. A bandwidth-remaining ratio
is used to influence how the router allocates excess bandwidth (unused by priority traffic) to a class of
non-priority traffic.
Dynamically Changing VC Weight and Watermark Values

Description: The DBS ExtensionsVC Weight and Watermarks feature was introduced on the PRE2 to
enable you to modify existing VC weight and watermark values without tearing down and recreating the
VC.
1-26
OL-7433-09
Chapter 1

Hierarchical Queuing Framework

Documentation Reference: Chapter 22, Hierarchical Scheduling and Queuing
Hierarchical Queuing Framework Feature, page 1-27
MQC Hierarchical Queuing with 3 Level Scheduler, page 1-27
, page 1-27
Hierarchical Queuing Framework Feature

Description: The Hierarchical Queuing Framework (HQF) feature was introduced on the PRE3 to define
a QoS architecture for implementing hierarchical packet scheduling and queuing. The HQF enables
service providers to manage their QoS at three layers of hierarchy: physical, logical, and class.
MQC Hierarchical Queuing with 3 Level Scheduler

Description: The MQC Hierarchical Queuing with 3 Level Scheduler feature provides a flexible packet
scheduling and queuing system in which you can specify how excess bandwidth is to be allocated among
the subscriber queues and logical interfaces. Rather than allocating an implicit minimum bandwidth
guarantee to each queue, the three-level scheduler uses the bandwidth-remaining ratio parameter to
allocate unused bandwidth to each logical queue.
Hierarchical Policies
Documentation Reference: Chapter 13, Defining QoS for Multiple Policy Levels
Nested Hierarchical Policies, page 1-27
Three-Level Hierarchical Policies, page 1-28
Hierarchical Input Policing, page 1-28
Nested Hierarchical Policies

Description: The nested hierarchical policies feature was introduced on the PRE1. This feature defines
a minimum bandwidth for the multiple classes and a combined maximum bandwidth for the classes. This
feature supports two-level hierarchical policies.

OL-7433-09
1-27
Chapter 1

Three-Level Hierarchical Policies

Description: The nested hierarchical policies feature was enhanced on the PRE1 to support three-level
hierarchical policies.
Description: The nested hierarchical policies feature was enhanced on the PRE2 to support three-level
Hierarchical Input Policing

Description: The hierarchical input policing feature was introduced on the PRE2 to define up to two
levels of hierarchy for inbound traffic only.
1-28
OL-7433-09
Chapter 1

IP Quality of Service for Subscribers

Documentation Reference: Chapter 18, Regulating and Shaping Subscriber Traffic
MQC Support for IP Sessions, page 1-29
Per-Session Shaping for ATM Interfaces, page 1-29
Per Session Rate Limiting, page 1-29
Per User Multiservice Rate Limiting, page 1-29
Per Session Service Policy Using RADIUS, page 1-30
Per Session Shaping and Queuing on LNS, page 1-30
PPP Session Queuing on ATM VCs, page 1-30
MQC Support for IP Sessions

Description: The Modular QoS CLI (MQC) Support for IP Sessions feature was introduced on the
PRE2, PRE3, and PRE4 to support per-user QoS on IP sessions. Using this feature, you can configure
queuing and non-queuing features on IP sessions, either locally on the router or remotely using a
authentication, authorization, and accounting (AAA) server such as RADIUS.
Per-Session Shaping for ATM Interfaces

Description: The Per-Session Shaping for ATM Interfaces feature enables the router to shape session
traffic on L2TP network server (LNS) outbound ATM interfaces. Using this feature, you can apply a
hierarchical QoS policy to an ATM interface and manage the traffic belonging to a session.
Per Session Rate Limiting

Description: The per session rate limiting feature was introduced on the PRE2 to control the maximum
rate of traffic sent or received on an interface for a session.
Per User Multiservice Rate Limiting

Description: The per user multiservice rate limiting feature was introduced on the PRE2 to control the
maximum rate of traffic for each user behind a multiservice subscriber.

OL-7433-09
1-29
Chapter 1
Per Session Service Policy Using RADIUS

Description: The per session service policy using RADIUS feature was introduced on the PRE2 to
enable a subscriber management server (SMS), typically a RADIUS server, to dynamically change the
traffic policing parameters for a user session.
Per Session Shaping and Queuing on LNS

Description: The Per Session Shaping and Queuing on LNS feature was introduced on the PRE3 to
shape or queue traffic from an ISP to a subscriber as it traverses over an LNS.
PPP Session Queuing on ATM VCs

Description: The PPP Session Queuing on ATM VCs feature was introduced on the PRE3 to enable you
to shape and queue PPP over ATM (PPPoA) and PPP over Ethernet over ATM (PPPoEoA) sessions to a
user specified rate.
Layer 2 Access Concentrator

Documentation References: Chapter 2, Classifying Traffic, Chapter 4, Attaching Service Policies,
Chapter 6, Policing Traffic, Chapter 7, Marking Traffic
Classification, Policing, and Marking on the LAC, page 1-30
LAC QoS, page 1-30
Classification, Policing, and Marking on the LAC

Description: The classification, policing, and marking on the LAC feature was introduced on the PRE2
and PRE3 to allow you to configure class maps and policy maps with policers on the LAC.
LAC QoS
Description: The show pxf cpu queue atm command displays dropped and dequeued packets for
classes associated with sessions that inherit queues from VCs.
Description: The LAC QoS feature was introduced on the PRE2 to allow you to attach QoS service
policies to ATM VCs on the on the Layer 2 Access Concentrator (LAC).
1-30
OL-7433-09
Chapter 1

Link Fragmentation and Interleaving

Documentation Reference: Chapter 16, Fragmenting and Interleaving Real-Time and Nonreal-Time
Packets
interface multilink Command, page 1-31
multilink group Command, page 1-31
ppp multilink Command, page 1-32
ppp multilink fragment-delay Command, page 1-32
ppp multilink fragmentation Command, page 1-33
ppp multilink fragment disable Command, page 1-33
ppp multilink group Command, page 1-33
ppp multilink interleave Command, page 1-34
MLP Over ATM-Based LFI Feature, page 1-34
Multi-VC MLP Over ATM-Based LFI Feature, page 1-34
MLP Over Frame Relay-Based LFI Feature, page 1-35
Multi-VC MLP Over ATM-Based LFI Feature, page 1-34
FRF.12 Fragmentation Feature, page 1-35
interface multilink Command

Cisco IOS Release: Release 12.0
Description: The interface multilink command was introduced on the PRE1 to create and configure a
MLP bundle.
Description: This command was introduced on the PRE2 and provides a multilink interface range of 1
to 9999.
Description: This command was introduced on the PRE3 and the valid interface values for MLP over
serial and multi-VC MLP over ATM changed from 1 to 9999 (Release 12.2(28)SB) to from 1 to 9999
and 65,536 to 2,147,483,647.
multilink group Command

Description: The multilink group command was introduced on the PRE1 to assign a physical link to a
multilink group.

OL-7433-09
1-31
Chapter 1

Description: This command was changed to ppp multilink group on the PRE2 to restrict a physical
link to joining only a designated multilink group interface. The multilink-group command is accepted
by the command line interpreter through Cisco IOS Release 12.2.
ppp multilink Command

Description: The ppp multilink command was introduced on the PRE1 to enable Multilink PPP (MLP)
on an interface.
ppp multilink fragment-delay Command

Description: The ppp multilink fragment-delay command was introduced on the PRE1 to specify the
maximum amount of time, in milliseconds, that is required to transmit a fragment.
1-32
OL-7433-09
Chapter 1

ppp multilink fragmentation Command

Description: The ppp multilink fragmentation command was introduced on the PRE1 to enable
fragmentation.
Description: The no ppp multilink fragmentation command was changed to ppp multilink fragment
disable. The no ppp multilink fragmentation command was recognized and accepted through
Cisco IOS Release 12.2.
ppp multilink fragment disable Command

Description: The ppp multilink fragment disable command was introduced on the PRE1 as
ppp multilink fragmentation.
Description: The no ppp multilink fragmentation command was changed to ppp multilink fragment
disable to disable fragmentation. The no ppp multilink fragmentation command was recognized and
accepted through Cisco IOS Release 12.2.
ppp multilink group Command

Description: The ppp multilink group command was introduced on the PRE1 as multilink-group.

OL-7433-09
1-33
Chapter 1

Description: The multilink-group command was changed to ppp multilink group to restrict a physical
link to joining only a designated multilink group interface. The multilink-group command was accepted
by the command line interpreter through Cisco IOS Release 12.2.
ppp multilink interleave Command

Description: The ppp multilink interleave command was introduced on the PRE1 to enable
interleaving of real-time packets among the fragments of larger nonreal-time packets.
MLP Over ATM-Based LFI Feature

Description: The Multilink PPP (MLP) over ATM feature was introduced on the PRE2 to allow you to
fragment and interleave real-time and nonreal-time packets on ATM VCs.
Multi-VC MLP Over ATM-Based LFI Feature

Description: The Multi-VC MLP over ATM-based LFI feature was introduced on the PRE2 to allow you
to fragment and interleave real-time and nonreal-time packets on multiple ATM VCs.
Description: This feature was introduced on the PRE3 and the valid interface values changed from 1 to
9999 (Release 12.2(28)SB and later) to from 1 to 9999 and 65,536 to 2,147,483,647
(Release 12.2(31)SB2 and later).
1-34
OL-7433-09
Chapter 1

MLP Over Frame Relay-Based LFI Feature

Description: The MLP over Frame Relay-based LFI feature was introduced on the PRE2 to allow you
to fragment and interleave real-time and nonreal-time packets on Frame Relay interfaces and DLCIs.
MLP Over Serial-Based LFI Feature

Description: The MLP over serial-based LFI feature was introduced on the PRE1 to allow you to
fragment and interleave real-time and nonreal-time packets on serial links.
Description: This feature was introduced on the PRE3 and the valid interface values changed from 1 to
9999 (Release 12.2(28)SB and later) to from 1 to 9999 and 65,536 to 2,147,483,647
(Release 12.2(31)SB2 and later).
FRF.12 Fragmentation Feature

Description: The PVC-based FRF.12 Fragmentation feature was introduced on the PRE1.
Description: This feature was enhanced to allow interface-based FRF.12 fragmentation.
Description: This feature was introduced on the PRE2 to allow PVC-based and interface-based FRF.12
fragmentation.

OL-7433-09
1-35
Chapter 1
Marking Traffic
Documentation Reference: Chapter 7, Marking Traffic
set atm-clp Command, page 1-36
set cos Command, page 1-36
set discard-class Command, page 1-36
set fr-de Command, page 1-37
set ip dscp Command, page 1-37
set ip precedence Command, page 1-37
set mpls experimental Command, page 1-37
set mpls experimental imposition Command, page 1-38
set qos-group Command, page 1-38
Marking Feature, page 1-38
set atm-clp Command

Description: The set atm-clp command was introduced on the PRE2 to set the cell loss priority (CLP)
bit to 1.
Description: This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.
Description: This command was introduced on the PRE3 and PRE4.
set cos Command

Description: The set cos command was introduced on the PRE2 to set the Layer 2 class of service (CoS)
value of an outgoing packet. This command is available only on the PRE2.
set discard-class Command

Description: The set discard-class command was introduced on the PRE2 to mark a packet with a
discard-class value or to drop a specific traffic type during congestion. This command is available only
on the PRE2.
1-36
OL-7433-09
Chapter 1


set fr-de Command

Description: The set fr-de command was introduced on the PRE2 and PRE3 to mark a Frame Relay
packets discard eligibility (DE) bit.
set ip dscp Command

Description: The set ip dscp command was introduced on the PRE1 to mark a packet by setting the
differentiated services code point (DSCP) value in the type of service (ToS) byte.
Description: This command was introduced on the PRE3 to allow you to mark the IP DSCP bits of
traffic on the L2TP access concentrator (LAC).
set ip precedence Command

Description: The set ip precedence command was introduced on the PRE1 to set the precedence value
in a packet header.
set mpls experimental Command

Description: The set mpls experimental command was introduced on the PRE1 to set the value of the
Multiprotocol Label Switching (MPLS) experimental (EXP) field. This command is available only on
the PRE1.

OL-7433-09
1-37
Chapter 1
set mpls experimental imposition Command

Description: The set mpls experimental imposition command was introduced on the PRE2 to set the
value of the Multiprotocol Label Switching (MPLS) experimental (EXP) field on all imposed label
entries. This command is available only on the PRE2.
set qos-group Command

Description: The set qos-group command was introduced on the PRE1 to set a quality of service (QoS)
group identifier (ID) that can be used later to classify packets.
Marking Feature
Description: The marking feature was introduced on the PRE1 to enable you to differentiate packets
based on designated markings. Other devices can examine the marked bits and classify traffic based on
the marked values.
Description: This feature was enhanced to support MPLS experimental (EXP) marking.
Description: This feature was introduced on the PRE2 and was enhanced to support 802.1Q class of
service (CoS) marking. This enhancement is available only on the PRE2.
Description: This feature was enhanced on the PRE2 to support MPLS experimental (EXP) and
discard-class marking. The discard-class enhancement is available only on the PRE2.
Description: This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.
Description: This feature was introduced on the PRE3 to allow you to mark the IP DSCP bits of traffic
on the L2TP access concentrator (LAC). Frame Relay DE bit marking and tunnel header marking were
also introduced on the PRE3.
1-38
OL-7433-09
Chapter 1


Description: This feature was introduced on the PRE4 and enhanced to allow Frame Relay DE bit
marking.
Modular QoS Command Line Interface

Documentation Reference: Chapter 1, Quality of Service Overview
MQC Feature, page 1-39
QoS CLI Migration from PRE2 to PRE3, page 1-39
MQC Feature
Description: The MQC feature was introduced on the PRE1 to enable you to configure QoS services on
the Cisco 10000 series router.
Description: This feature was introduced on the PRE3. Enhancements to the MQC allow you to classify
packets on the L2TP access concentrator (LAC) based upon the IP type of service (ToS) bits in an
embedded IP packet. When a policer is configured, the router uses packet classification to police ingress
traffic according to the DSCP value.
QoS CLI Migration from PRE2 to PRE3

Description: The QoS CLI Migration from PRE2 to PRE3 feature was introduced on the PRE3 to
provide a migration path from PRE2 CLI commands to PRE3 CLI commands.
Overhead Accounting
Documentation Reference: Chapter 10, Overhead Accounting
bandwidth Command, page 1-25
shape Command, page 1-56
ATM Overhead Accounting, page 1-40
Ethernet Overhead Accounting, page 1-40
Traffic Shaping Overhead Accounting for ATM, page 1-40

OL-7433-09
1-39
Chapter 1
ATM Overhead Accounting

Description: The ATM Overhead Accounting feature was introduced on the PRE2 to enable the router
to account for various encapsulation types when applying QoS to packets. The router uses the
encapsulation type you configure to calculate the ATM overhead per packet.
Description: This feature was enhanced on the PRE3 to allow a user-defined number of overhead bytes.
Ethernet Overhead Accounting

Description: The Ethernet Overhead Accounting feature was introduced on the PRE2, PRE3, and PRE4
to enable the router to account for downstream Ethernet frame headers when applying shaping to
packets. A user-defined offset specifies the number of overhead bytes the router is to use when
calculating the overhead per packet.
Traffic Shaping Overhead Accounting for ATM

Description: The Traffic Shaping Overhead Accounting for ATM feature was introduced on the PRE2
to enable the broadband access system (BRAS) to account for ATM encapsulation on the subscriber line
and the overhead added by cell segmentation. This enables the service provider to prevent overruns at
the subscriber line and ensures that the router executes QoS features on the actual bandwidth used by
ATM subscriber traffic.
1-40
OL-7433-09
Chapter 1


Documentation Reference: Chapter 15, Oversubscribing Physical and Virtual Links
atm over-subscription-factor Command, page 1-41
Interface Oversubscription Feature, page 1-41
ATM Virtual Circuit Oversubscription Feature, page 1-42
map-class frame-relay Command, page 1-42
Frame Relay PVC Oversubscription Feature, page 1-42
Virtual LAN Oversubscription Feature, page 1-43
queue-depth Command, page 1-43
weight Command, page 1-43
Weighting Feature, page 1-44
atm over-subscription-factor Command

Description: The atm over-subscription-factor command was introduced on the PRE2 to enable you
to oversubscribe ATM virtual circuits (VCs). The allowable oversubscription amount is 1 to 50 times the
physical transmission capacity.
Description: The amount of oversubscription you can configure was increased to 500. For example, you
can oversubscribe the physical transmission capacity from 1 to 500 times.
Description: This command was introduced on the PRE3 to allow the aggregate VLAN rates to exceed
the available bandwidth. The oversubscription factor is from 1 to 500.
Interface Oversubscription Feature

Description: The interface oversubscription feature was introduced on the PRE1 to enable you to assign
a total committed information rate (CIR) to a given port that is greater than the speed of the port.
Description: This feature was introduced on the PRE2 to enable you to assign a total committed
information rate (CIR) to a given port that is greater than the speed of the port.

OL-7433-09
1-41
Chapter 1

Description: This command was introduced on the PRE3 with an oversubscription factor from 1 to 500.
ATM Virtual Circuit Oversubscription Feature

Description: The ATM virtual circuit (VC) oversubscription feature was introduced on the PRE2 to
enable you to assign a rate to a variable bit rate-nonreal time (VBR-nrt) VC, a constant bit rate (CBR)
VC, or a virtual path (VP) tunnel that is greater than the speed of the interface. The amount of allowable
oversubscription is 1 to 50 times the physical transmission capacity.
Description: The amount of allowable ATM VC oversubscription was increased to 500 on the PRE2.
For example, you can oversubscribe the physical transmission capacity from 1 to 500 times.
Description: This command was introduced on the PRE3 with an oversubscription factor from 1 to 500.
map-class frame-relay Command

Documentation Reference: Appendix A, Configuring Frame Relay QoS Using Frame Relay Legacy
Commands
Description: The map-class frame-relay command was introduced on the PRE1.
Description: This command was ported to the S train.
Frame Relay PVC Oversubscription Feature

Description: The Frame Relay PVC oversubscription feature was introduced on the PRE2 to enable you
to assign a total committed information rate (CIR) to a given PVC that is greater than the speed of the
interface.
1-42
OL-7433-09
Chapter 1


Virtual LAN Oversubscription Feature

Description: The virtual LAN (VLAN) oversubscription feature was introduced on the PRE2 to enable
you to assign a total committed information rate (CIR) to a given VLAN that is greater than the speed
of the interface.
Description: This command was introduced on the PRE3 to allow the aggregate VLAN rates to exceed
the available bandwidth. The oversubscription factor is a value from 1 to 500.
queue-depth Command
Description: The queue-depth command was introduced on the PRE2 to allow you to configure the
segmentation and reassembly (SAR) line card queue depth for each VC interface queue.
weight Command
Description: The weight command was introduced on the PRE2 to allow you to control virtual circuit
(VC) bandwidth when the virtual path (VP) is congested.

OL-7433-09
1-43
Chapter 1
Weighting Feature
Description: The VC weighting feature was introduced on the PRE2 to control the number of cells for
each VC that is sent into the virtual path (VP).
Policing Traffic
Documentation Reference: Chapter 6, Policing Traffic
police Command (Single-Rate), page 1-44
police percent Command, page 1-45
police Command (Two-Rate), page 1-45
show atm vp Command, page 1-46
Percent-Based Policing Feature, page 1-46
Policing Feature, page 1-46
Single-Rate Color Marker Feature, page 1-47
Two-Rate Three-Color Marker Feature, page 1-47
ATM VP Average Traffic Rate, page 1-48
police Command (Single-Rate)

Description: The police command was introduced on the PRE1 to allow you to control the maximum
rate of traffic sent or received on an interface. This command included a single-rate two-color policer,
which allows you to classify traffic into two groups: traffic that conforms to the specified committed
information rate (CIR) and burst sizes, and traffic that exceeds either the CIR or the burst sizes.
Description: This command was enhanced to include the set-mpls-exp-transmit policing action. This
action is available only on the PRE1.
Description: This command was enhanced to include a three-color marker. A new violate-action
parameter allows you to specify the action to take for traffic that consistently violates the committed rate.
Description: This command was introduced on the PRE2 and included a single-rate two-color marker.
1-44
OL-7433-09
Chapter 1


Description: This command was enhanced on the PRE2 to include a three-color marker and the
set-mpls-exp-imposition-transmit policing action. This action is available only on the PRE2.
Description: This command was introduced on the PRE3 to allow you to police traffic on the L2TP
access concentrator (LAC) based on the value of a packets IP DSCP bits.
Description: This command was enhanced to include the following police actions:
set-cos-transmit to set the class of service (CoS) bit value
set-atm-clp-transmit to set the ATM cell loss priority (CLP) bit value.
set-frde-transmit to set the Frame Relay discard eligibility (DE) bit value.
police percent Command

Description: The police percent command was introduced on the PRE1 to allow you to configure traffic
policing as a percentage of the interface bandwidth on which policing is applied. Configuring traffic
policing based on bandwidth percentage enables you to use the same policy map for multiple interfaces
with differing amounts of bandwidth.
Description: This command was enhanced on the PRE2 to allow you to configure two traffic policing
rates as a percentage: the committed information rate (CIR) and the peak information rate (PIR).
police Command (Two-Rate)

Description: The single-rate police command was enhanced on the PRE2 to allow you to configure two
traffic policing rates: the committed information rate (CIR) and the peak information rate (PIR).

OL-7433-09
1-45
Chapter 1

show atm vp Command

Description: The show atm vp command was enhanced on the PRE2, PRE3, and PRE4 to provide rate
information. Minute counters on the ATM VPs support the show atm vp command.
Percent-Based Policing Feature

Description: The percent-based policing feature was introduced on the PRE1 to allow you to configure
traffic policing as a percentage of the interface bandwidth on which policing is applied. Configuring
traffic policing based on bandwidth percentage enables you to use the same policy map for multiple
interfaces with differing amounts of bandwidth.
Description: This feature was enhanced on the PRE2 to allow you to configure two traffic policing rates
as a percentage: the committed information rate (CIR) and the peak information rate (PIR).
Policing Feature
Description: The policing feature was introduced on the PRE1 to allow you to control the maximum rate
of traffic sent or received on an interface. This feature included a single-rate two-color policer.
Description: This feature was enhanced on the PRE1 to include a three-color marker.
Description: This feature was introduced on the PRE2 and included a single-rate two-color marker.
1-46
OL-7433-09
Chapter 1


Description: This feature was enhanced on the PRE2 to include a two-rate policer.
Description: This feature was introduced on the PRE3 to allow you to police traffic on the L2TP access
concentrator (LAC) based on the value of a packets IP DSCP bits. Control plane policing, policing of
GRE tunnels, and tunnel header marking using a police action were also introduced on the PRE3.
Single-Rate Color Marker Feature

Description: The single-rate color marker feature was introduced on the PRE1 with two-color marking
to allow you to police traffic streams into groups of conforming and non-conforming traffic.
Description: This feature was enhanced on the PRE1 to include a single-rate three-color marker to allow
you to police traffic streams into groups of conforming, non-conforming, and violating traffic.
Description: This feature was introduced on the PRE2 and included a single-rate two-color marker.
concentrator (LAC) based on the value of a packets IP DSCP bits.
Two-Rate Three-Color Marker Feature

Description: The two-rate three-color marker feature was introduced on the PRE2 to allow you to
manage bandwidth by setting the committed information rate (CIR) and the peak information rate. Using
this feature you can police traffic streams into groups of conforming, non-conforming, and violating
traffic.
concentrator (LAC) based on the value of a packets IP DSCP bits.

OL-7433-09
1-47
Chapter 1
ATM VP Average Traffic Rate

Description: This feature was introduced on the PRE2, PRE3, and PRE4 to enable you to display the
5-minute traffic rates on virtual path (VP) counters. This feature is a subscriber and VP traffic reporting
feature that extends the show atm vp command to provide rate information. Minute counters on the
ATM VPs support the show atm vp command.
Prioritizing Traffic
Documentation Reference: Chapter 8, Prioritizing Services
priority Command, page 1-48
priority level Command, page 1-49
Child Service Policy Allowed Under Priority Class, page 1-49
Multi-Level Priority Queues, page 1-49
Priority Queuing Feature, page 1-49
priority Command
Description: The priority command was introduced on the PRE1 to give priority to a traffic class in a
policy map and to set the bandwidth rate for the queue in kilobits per second.
Description: This command was enhanced on the PRE1 to include a percent-based bandwidth rate.
Description: This command was modified on the PRE1 to provide strict priority queuing. Strict priority
queuing guarantees low-latency for any packet that enters a priority queue, regardless of the current
congestion level on the link. To specify a bandwidth rate for a strict priority queue, you must specify the
police command.
Description: This command was introduced on the PRE2 to allow you to set the bandwidth rate for a
queue in kilobits per second or as a percentage.
Description: This command was modified to provide strict priority queuing on the PRE2. To specify a
bandwidth rate for a strict priority queue, you must specify the police command.
1-48
OL-7433-09
Chapter 1


priority level Command

Description: The priority level command was introduced on the PRE3 to allow you to configure
multiple priority queues for multiple traffic classes.

Description: The child service policy allowed under priority class feature was introduced on the PRE3
to allow you to attach a child policy with non-queuing features to a priority class.
Multi-Level Priority Queues

Description: The multi-level priority queues (MPQ) feature was introduced on the PRE3 to allows you
to configure multiple priority queues for multiple traffic classes by specifying a different priority level
for each of the traffic classes in a single service policy map.
Priority Queuing Feature

Description: The priority queuing feature was introduced on the PRE1 to allow the router to dequeue
and transmit delay-sensitive data such as voice before it dequeues and sends packets in other queues.
Using priority queuing, delay-sensitive data receives preferential treatment over other traffic. This
feature allows you to set a bandwidth rate for a queue in kilobits per second.
Description: This feature was enhanced on the PRE1 to allow you to set a bandwidth rate for a queue
as a percentage.
Description: This feature was modified on the PRE1 to provide strict priority queuing. Strict priority
queuing guarantees low-latency for any packet that enters a priority queue, regardless of the current
congestion level on the link. To specify a bandwidth rate for a strict priority queue, you must specify the
police command.
Description: This feature was introduced on the PRE2 to allow you to set a bandwidth rate for a queue
in kilobits per second or as a percentage.

OL-7433-09
1-49
Chapter 1

Description: This feature was modified on the PRE2 to provide strict priority queuing. To specify a
bandwidth rate for a strict priority queue, you must specify the police command.
PVC Bundles
Documentation Reference: Chapter 19, Configuring Quality of Service for PVC Bundles
bump Command, page 1-50
bump Command (Frame Relay VC-bundle-member), page 1-51
bundle Command, page 1-51
class-bundle Command, page 1-51
class-vc Command, page 1-51
dscp Command (Frame Relay VC-bundle-member), page 1-51
exp Command, page 1-51
frame-relay vc-bundle Command, page 1-51
mpls experimental Command, page 1-52
oam-bundle Command, page 1-52
precedence Command, page 1-52
precedence Command (Frame Relay VC-bundle-member), page 1-52
protect Command, page 1-52
protect Command (Frame Relay VC-bundle-member), page 1-52
pvc-bundle Command, page 1-53
pvc Command (Frame Relay VC-bundle), page 1-53
PVC Bundles Over ATM and Frame Relay Feature, page 1-53
ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection Feature, page 1-53
Frame Relay PVC Bundles with QoS Support for IP and MPLS Feature, page 1-53
bump Command
Description: The bump command was introduced on the PRE1 to configure the bumping rules for an
ATM PVC bundle or a specific ATM PVC bundle member.
1-50
OL-7433-09
Chapter 1

bump Command (Frame Relay VC-bundle-member)

Description: The bump command was introduced on the PRE1 to configure the bumping rules for a
Frame Relay permanent virtual circuit (PVC) bundle member.
bundle Command
Description: The bundle command was introduced on the PRE1 to create an ATM bundle or modify an
existing ATM bundle.
class-bundle Command
Description: The class-bundle command was introduced on the PRE1 to configure an ATM virtual
circuit (VC) bundle with the bundle-level commands contained in the specified VC class.
class-vc Command
Description: The class-vc command was introduced on the PRE1 to assign a virtual circuit (VC) class
to an ATM permanent virtual circuit (PVC) or PVC bundle member.
dscp Command (Frame Relay VC-bundle-member)

Description: The dscp command was introduced on the PRE1 to configure the differentiated services
code point (DSCP) levels for a Frame Relay permanent virtual circuit (PVC) bundle member.
exp Command
Description: The exp command was introduced on the PRE1 to configure Multiprotocol Label
Switching (MPLS) experimental (EXP) levels for a Frame Relay permanent virtual circuit (PVC) bundle
member.
frame-relay vc-bundle Command

Description: The frame-relay vc-bundle command was introduced on the PRE1 to create a Frame
Relay permanent virtual circuit (PVC) bundle if it does not already exist, and to enter Frame Relay
VC-bundle configuration mode.

OL-7433-09
1-51
Chapter 1
mpls experimental Command

Description: The mpls experimental command was introduced on the PRE1 to configure MPLS
experimental (EXP) levels for a VC class or for a PVC member of a bundle. The VC class is applied to
the PVC bundle and thus applied to all PVC members of the bundle.
oam-bundle Command
Description: The oam-bundle command was introduced on the PRE1 to enable end-to-end F5
Operation, Administration, and Maintenance (OAM) loopback cell generation and OAM management
for all permanent virtual circuit (PVC) members of a bundle or a VC class that can be applied to a PVC
bundle.
precedence Command
Description: The precedence command was introduced on the PRE1 to configure precedence levels for
a virtual circuit (VC) class, VC, or permanent virtual circuit (PVC) member of a bundle. The VC class
is assigned to a PVC bundle and thus applied to all PVC members of that bundle.
precedence Command (Frame Relay VC-bundle-member)

Description: The precedence command was introduced on the PRE1 to configure the precedence levels
for a Frame Relay permanent virtual circuit (PVC) bundle member.
protect Command
Description: The protect command was introduced on the PRE1 to configure a virtual circuit (VC) class
with protected group or protected VC status for application to a PVC bundle member and to configure a
specific VC or permanent virtual circuit (PVC) as part of a protected group of the bundle or to configure
it as an individually protected VC or PVC bundle member.
protect Command (Frame Relay VC-bundle-member)

Description: The protect command was introduced on the PRE1 to configure a Frame Relay protected
permanent virtual circuit (PVC) bundle member with protected group or protected PVC status.
1-52
OL-7433-09
Chapter 1

pvc-bundle Command
Description: The pvc-bundle command was introduced on the PRE1 to add a permanent virtual circuit
(PVC) to a bundle as a member of the bundle and enter bundle-vc configuration mode in order to
configure that PVC bundle member,
pvc Command (Frame Relay VC-bundle)

Description: The pvc command was introduced on the PRE1 to create a permanent virtual circuit (PVC)
that is a Frame Relay PVC bundle member, and to enter Frame Relay VC-bundle-member configuration
mode.
PVC Bundles Over ATM and Frame Relay Feature

Description: The PVC bundles over ATM and Frame Relay feature was introduced on the PRE1 to
combine PVCs into one logical interface. This feature provides IP precedence and DSCP-based PVC
selection.
ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection Feature

Description: The ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection feature was
introduced on the PRE1 to provide ATM PVC selection based on the MPLS EXP level of a packet.
Frame Relay PVC Bundles with QoS Support for IP and MPLS Feature
Description: The Frame Relay PVC Bundles with QoS Support for IP and MPLS feature was introduced
on the PRE1 to provide Frame Relay PVC selection based on the precedence, DSCP, or MPLS EXP level
of a packet.
QoS Policy Maps

Documentation Reference: Chapter 3, Configuring QoS Policy Actions and Rules
policy-map Command, page 1-54
qos match statistics Command, page 1-54
Policy Maps Feature, page 1-54
Policy Map Scaling Phase 2, page 1-54

OL-7433-09
1-53
Chapter 1
policy-map Command
Description: This command was introduced on the PRE1 to configure a QoS policy map.
Description: This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.
qos match statistics Command

Description: This command was introduced on the PRE3 to configure the router to count QoS matches
for each class or for each match statement and class. Per-class counts provide for greater QoS scalability.
Policy Maps Feature

Description: The QoS policy map feature was introduced on the PRE1 to configure a QoS service
policy.
Policy Map Scaling Phase 2

Description: This feature was introduced on the PRE2, PRE3, and PRE4 to allow up to 8192 policy
maps per system.
1-54
OL-7433-09
Chapter 1

Qos Policy Propagation through the Border Gateway Protocol

Documentation Reference: Appendix B, QoS Policy Propagation Through the Border Gateway
Protocol
Description: The QoS policy propagation through the Border Gateway Protocol (QPPB) feature was
introduced on the PRE1 to enable packet classification based on a Border Gateway Protocol (BGP)
prefix, BGP community list, and BGP autonomous system (AS) paths.
Shaping PPPoE Over VLAN Sessions Using RADIUS

Per Session Queuing and Shaping for PPPoE Over VLAN Support Using RADIUS Feature,
page 1-55
Per Session Queuing and Shaping for PPPoE Over VLAN Support Using RADIUS Feature
Description: The Per Session Queuing and Shaping for PPPoE over VLAN Support Using RADIUS
feature was introduced on the PRE2 to enable dynamic queuing and shaping policies on PPPoEoVLAN
sessions.
Description: This feature was integrated in Cisco IOS Release 12.2(31)SB5 for the PRE2.
Shaping Traffic
Documentation Reference: Chapter 9, Shaping Traffic
atm pvp Command, page 1-56
pvc Command, page 1-56
shape Command, page 1-56
shape percent Command, page 1-57
vbr-nrt Command, page 1-57
ATM VC/VP Shaping Feature, page 1-57
Class-Based Traffic Shaping Feature, page 1-58
Frame Relay Traffic Shaping Feature, page 1-58

OL-7433-09
1-55
Chapter 1
Percentage-Based Traffic Shaping Feature, page 1-58
Percentage-Based Traffic Shaping Feature, page 1-58
Traffic Shaping Overhead Accounting for ATM Feature, page 1-59
atm pvp Command

pvc Command
shape Command
1-56
OL-7433-09
Chapter 1


Description: This command supports per-session shaping and queuing on a L2TP Network Server
(LNS) on the PRE3.
Description: This command was enhanced to support overhead accounting.
Description: This command was enhanced to support a user-defined offset, which the router uses when
calculating overhead.
shape percent Command

vbr-nrt Command
ATM VC/VP Shaping Feature

Description: The ATM VC/VP Shaping feature was introduced on the PRE2 to enable you to shape
traffic at both the VC-level and VP-level.

OL-7433-09
1-57
Chapter 1
Class-Based Traffic Shaping Feature

Description: The Class-Based Traffic Shaping feature was introduced on the PRE1 to allow you to
control a class of 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
Frame Relay Traffic Shaping Feature

Description: The Frame Relay Traffic Shaping (FRTS) feature was introduced on the PRE1 to eliminate
bottlenecks in Frame Relay networks by allowing you to configure rate enforcement to either the
committed information rate (CIR) or some other defined value, such as the excess information rate, on
a per-VC basis.
Hierarchical Shaping Feature

Description: The Hierarchical Shaping feature was introduced on the PRE2 to enable you to shape
traffic at both the VC-level and VP-level.
Percentage-Based Traffic Shaping Feature

Description: This feature was introduced on the PRE3 to enable you to shape traffic based on a
percentage of the available bandwidth.
1-58
OL-7433-09
Chapter 1

Traffic Shaping Overhead Accounting for ATM Feature

Description: The Traffic Shaping Overhead Accounting for ATM feature was introduced on the PRE3
to enable the broadband aggregation system (BRAS) to account for various encapsulation types when
applying QoS to packets. Cisco IOS Release: Release 12.2(31)SB5
Description: The Traffic Shaping Overhead Accounting for ATM feature was enhanced to include a
user-defined offset value on the PRE3.

Documentation Reference: Chapter 12, Sharing Bandwidth Fairly During Congestion
Bandwidth Fair Queuing Feature, page 1-59
Class-Based Weighted Fair Queuing Feature, page 1-59
Class-Based Weighted Fair Queuing for Virtual Access Interfaces Feature, page 1-60
Bandwidth Fair Queuing Feature

Description: The bandwidth fair queuing feature was introduced on the PRE1 to share bandwidth fairly
among competing traffic.
Class-Based Weighted Fair Queuing Feature

Description: The class-based weighted fair queuing (CBWFQ) feature was introduced on the PRE1 to
provide support for user-defined traffic classes based on match criteria including protocols, access
control lists (ACLs), and input interfaces.

OL-7433-09
1-59
Chapter 1

Class-Based Weighted Fair Queuing for Virtual Access Interfaces Feature

Description: The Class-Based Weighted Fair Queuing (CBWFQ) for virtual access interfaces (VAIs)
feature was introduced on the PRE1 to allow a VAI to inherit the service policy of the VC that the VAI
uses.

Documentation Reference: Chapter 14, Simultaneous Policy Maps
Simultaneous QoS Policy Map on Interface and PPP SessionA-DSLAM Case, page 1-60
Simultaneous QoS Policy Map on Interface and PPP SessionA-DSLAM Case

Description: The Simultaneous QoS Policy Map on Interface and PPP SessionA-DSLAM Case
feature was introduced on the PRE2, PRE3, and PRE4 to allow the broadband aggregation system
(BRAS) to provide multiple levels of QoS hierarchy that shape traffic at different points of congestion
in the Layer 2 network. This enables the BRAS to avoid congestion in downstream links within the
network.

Documentation Reference: Chapter 21, VLAN Tag-Based Quality of Service
Description: The QoSVLAN Tag-Based feature was introduced on the PRE2 and PRE3 to enable you
to apply a single QoS policy, referred to as a VLAN-group policy, to a group of IEEE 802.1Q VLAN
subinterfaces.
1-60
OL-7433-09
Chapter 1

This section provides hyperlinks to additional Cisco documentation for the features discussed in this
chapter. To display the documentation, click the document title or a section of the document highlighted
in blue. When appropriate, paths to applicable sections are listed below the documentation title.
Feature
Broadband and lease-line QoS features
Cisco 10000 Series Broadband Aggregation and Leased-Line

Configuration Guide
CISCO-CLASS-BASED-QOS-MIB and
CISCO-CLASS-BASED-QOS-CAPABILITY-MIB
Cisco 10000 Series MIB Documents
Line cards
Cisco 10000 Series Router Line Card Configuration Guide

Technology of Edge Aggregation: Cisco 10000 Series Router
Modular Quality of Service Command-Line Interface

(MQC)
Implementing Quality of Service white paper

Cisco IOS Quality of Service Solutions Configuration Guide,
Release 12.2
Modular Quality of Service Command-Line Interface Overview
Configuring the Modular Quality of Service Command-Line
Interface

OL-7433-09
1-61
Chapter 1
1-62
OL-7433-09
CH A P T E R
Classifying Traffic
This chapter describes how to create traffic classification rules that the Cisco 10000 series router can use
to classify inbound and outbound traffic.
Even with fast interfaces, most networks require a strong quality of service (QoS) management model
to effectively manage the congestion points that occur due to speed-mismatch or diverse traffic patterns.
Real world networks have limited resources and resource bottlenecks, and need QoS policies to ensure
proper resource allocation.
The first step in creating a QoS service policy is to define how you want the router to classify traffic.
The traffic that matches the classification criteria is then subject to the QoS policy you create and apply
to the interface.
This chapter includes the following topics:
Traffic Classification Using Class Maps, page 2-1
Restrictions and Limitations for Traffic Classification, page 2-11
Classifying Traffic Using a Class Map, page 2-11

The Cisco 10000 router must differentiate traffic before it can apply the appropriate QoS actions to the
traffic. The router supports a modular QoS CLI element called a class map, which you can use to define
traffic classification rules or criteria.
Class maps organize data packets into specific categories called classes that can, in turn, receive
user-defined QoS policies. The traffic class defines the classification rules for packets received on an
interface. One or more match command statements in the class map define the criteria by which the
router classifies packets into specific classes. Packets arriving at either the input or output interface
(depending on the service-policy command configuration) are checked against the match criteria of a
class map to determine if the packet belongs to that class.
When configuring a class map, you can use one or more match commands to specify match criteria. For
example, you can use the following commands:
match access-group command
match protocol command
match input-interface command

OL-7433-09
2-1
Chapter 2
Classifying Traffic
Feature History for Class Maps

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The class map feature was introduced on the PRE1.
PRE1
Release 12.2(15)BX
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2

Release 12.2(31)SB2 for the PRE3.
PRE3
Enhancements to the modular quality of service CLI (MQC)

allow you to classify packets on the L2TP access
concentrator (LAC) based upon the IP type of service (ToS)
bits in an embedded IP packet. The classification is used to
police ingress traffic according to the differentiated service
code point (DSCP) value.
Release 12.2(33)SB
This feature was enhanced to support matching on the Frame PRE2, PRE3,
Relay Discard Eligibility (DE) bit.
PRE4
System Limits for Class Maps

Table 2-1 lists the system limits for class maps on the Cisco 10000 series router. In the table, the number
of class maps per system and the number of classes per policy map include the class-default class.
Table 2-1
System Limits for Class Maps
Number of Class
Maps per System
Number of Match
Statements per
Number of Classes
Class Map
per Policy Map
Processor
Cisco IOS Release
PRE1
All Releases earlier than 256

Release 12.0(17)SL
16
16
Release 12.0(17)SL
and later releases
256
16
256
Release 12.0(25)SX
and later releases
256
16
32
Release 12.2(15)BX
and later releases
262,000
16
64
Release 12.3(7)XI
and later releases
262,000
16
127
PRE2
2-2
OL-7433-09
Chapter 2
Classifying Traffic
Table 2-1
System Limits for Class Maps (continued)
Processor
Cisco IOS Release
Number of Class
Maps per System
PRE3
Release 12.2(31)SB2
and later releases
262,144
(per-match mode)
Number of Match
Statements per
Number of Classes
Class Map
per Policy Map
16
64
16
64
4,194,304
(per-class mode)
PRE4
Release 12.2(33)SB and

later releases
262,144
(per-match mode)
4,194,304
(per-class mode)
PRE3 Class Maps and QoS Scalability

The Cisco 10000 series router with a PRE3 counts QoS matches for each class or for each match. As the
following describes, you can achieve greater scalability with per-class mode counting enabled on the
router:
Per-match mode (default mode)The router counts matches for each match statement and class,
and supports 262,144 unique class maps per system.
Per-class modeThe router counts matches for the entire class and supports 4,194,304 unique class
maps. This mode provides greater scalability.
To configure per-match or per-class QoS match statistics, use the qos match statistics command. For
more information, see the qos match statistics Command section on page 2-4.
Note
The qos match statistics command is not available on the PRE2. Due to memory limitations, the PRE2
cannot exceed 262,000 class maps.
When using the show commands in per-class mode, the per-match statistics display a value of zero. In
per-class mode, the per-match statistics are zero in the MIB.
class-map Command
To create or modify a class map, use the class-map command in global configuration mode. To remove
a class map, use the no form of this command. By default, the router uses match-all.
class-map [match-any | match-all] class-map-name
no class-map [match-any | match-all] class-map-name

OL-7433-09
2-3
Chapter 2
Classifying Traffic
Syntax Description
match-any
(Optional) Indicates that a packet must meet at least one of the match
criteria to be considered a member of the class.
match-all
(Optional) Indicates that a packet must meet all of the match criteria to be
considered a member of the class.
class-map-name
Is the name of the class map. The name can be a maximum of

40 alphanumeric characters.
class-map Command History

Cisco IOS Release
Description
Release 12.0(17)SL
The class-map command was introduced on the PRE1.
Release 12.0(15)BX
This command was introduced on the PRE2.
Release 12.2(28)SB
This command was integrated in Cisco IOS Release 12.2(28)SB for the
PRE2.
Release 12.2(31)SB2
This command was integrated in Cisco IOS Release 12.2(31)SB2 for the
PRE3.
Usage Guidelines for the class-map Command

Use the class-map command to create or modify class map match criteria. The router compares the
packets that arrive at the input or output interface to the match criteria configured for a class map. If a
packet matches the criteria, the router designates the packet as belonging to the class.
When you configure a class map, you can use one or more match commands to specify the match
criteria. For example, you can configure the match access-group command, the match protocol
command, and the match input-interface command in a class map. The router compares the arriving
packets to the match criteria in the order in which you entered the criteria.
qos match statistics Command

To configure the router to count QoS matches for each class or for each match statement and class, use
the qos match statistics command in global configuration mode.
qos match statistics {per-class | per-match}
Syntax Description
per-class
Specifies to count QoS matches for the entire class. This mode provides
greater scalability.
per-match
Specifies to count matches for each match statement and class. This mode
provides PRE2 backward compatibility.
2-4
OL-7433-09
Chapter 2
Classifying Traffic
Command Default
Per-match is the default mode.
qos match statistics Command History

Cisco IOS Release
Description
Release 12.2(31)SB2
This command was introduced and implemented on the Cisco 10000 series
router for the PRE3.
Usage Guidelines for the qos match statistics Command

This command does not allow a no form of the command. The command operates in either per-match
mode or per-class mode. Specifying one mode automatically negates the current mode.
The Cisco 10000 series router with a PRE3 supports 262,144 unique class maps per system in per-match
mode and 4,194,304 unique class maps per system in per-class mode. Per-class mode provides greater
QoS scalability.
This command is not available on the PRE2. Due to memory limitations, the PRE2 supports a maximum
of 262,000 class maps per system.
When using the show commands in per-class mode, the per-match statistics display with a value of zero.
In per-class mode, the per-match statistics are zero in the MIB.
Defining Match Criteria Using the match Commands

To define the classification criteria for a class map, use the match commands in class-map configuration
mode. The match statements you define are the criteria the router uses to classify packets. To remove a
match statement, use the no form of this command. The router defaults to match-all.
Command
Purpose
Router(config-cmap)# match access-group {number |

name}
Specifies that the packet must be permitted by the specified access

control list (ACL).
number identifies the ACL applied to an interface. Valid values are
from 1 to 2699.
name specifies that the packet must be permitted by the access list
whose name is name. The name can be a maximum of
Router(config-cmap)# match-all
Specifies that the packet must match all of the matching criteria
defined for a class map.
Router(config-cmap)# match-any
Specifies that the packet must match at least one of the matching
criteria defined for a class map.

OL-7433-09
2-5
Chapter 2
Classifying Traffic
Command
Purpose
Router(config-cmap)# match not criteria
Specifies that the packet must not match this particular matching
criterion value.
criteria specifies the match criterion value that is an unsuccessful
match criterion. All other values of the specified match criterion
are considered successful match criteria.
Router(config-cmap)# match cos value
Specifies that the packet class of service (CoS) bit value must
match the specified CoS value.
value is a number from 0 to 7. You can specify up to four CoS
values, separated by a space.
Note
Router(config-cmap)# match discard-class value
For Cisco IOS Release 12.2(31)SB2 and later releases, this

command is available on the PRE2 and PRE3 for inbound
policies only. For earlier releases, this command is
available only on the PRE2 for inbound policies only.
Specifies that the discard-class value must match the specified

discard-class value.
Packets that match the specified discard-class value are treated
differently from packets marked with other discard-class values.
The discard-class is a matching criterion only, used in defining
per-hop behavior (PHB) for dropping traffic.
value is a number from 0 to 7. You can specify up to 4 values,
separated by a space. The value has no mathematical significance.
For example, the discard class value 2 is not greater than 1. The
value simply indicates that a packet marked with discard class 2
should be treated differently than a packet marked with discard
class 1.
Note
This command requires Cisco IOS Release 12.3(7)XI or

later releases and is available only on the PRE2.
Router(config-cmap)# match fr-de
Specifies that the router is to look for the Frame Relay discard
eligibility (DE) bit in the packets.
Router(config-cmap)# match input-interface name
Specifies that the packet input interface must match the interface
name.
2-6
OL-7433-09
Chapter 2
Classifying Traffic
Command
Purpose
Router(config-cmap)# match ip dscp {ip-dscp-value

| afxy | csx | ef | default}
Specifies that the packet IP differentiated service code point

(DSCP) value must match one or more of the specified attributes.
ip dscp ip-dscp-value specifies the DSCP value to match on. Valid
values are from 0 to 63. You can specify up to 8 code point values,
using a space to separate consecutive values.
Instead of specifying a numeric ip-dscp-value, you can specify one
of the following reserved keywords:
afxy indicates assured forwarding points. The first number (x)

indicates the AF class. Valid values are from 1 to 4. The
second number (y) indicates the level of drop preference
within each class. Valid values are from 1 (low drop) to 3 (high
drop).
cs indicates class selector code points that are

backward-compatible with IP precedence. Valid values for x
are 1 through 7. The CS code points (CS1 through CS7) are
identical to IP precedence values 1 through 7.
ef indicates expedited forwarding.
default indicates best effort or DSCP 0.
For more information, see Table 7-4 on page 7-8.

Note
Router(config-cmap)# match ip precedence

{ip-precedence-value | precedence-name}
In Cisco IOS Release 12.2(31)SB2 and later releases,

enhancements to the modular quality of service CLI
(MQC) allow you to classify packets on the L2TP access
concentrator (LAC) based upon the IP type of service
(ToS) bits in an embedded IP packet. The classification is
used to police ingress traffic according to the DSCP value.
Specifies that the packet IP precedence value must match one or

more precedence values or the name of the precedence.
ip-precedence-value is the IP precedence value to match on. Valid
values are from 0 to 7. You can specify up to 8 precedence values,
using a space to separate consecutive values.
precedence-name is the name of the IP precedence value.
Router(config-cmap)# match ip rtp

{lowest-udp-port range}
Specifies that the packet even UDP port value must be within the
specified range of port numbers. Only even-numbered ports are
matched because they carry the real-time data streams.
Odd-numbered ports are not matched because they only carry
control information.
lowest-udp-port is a number from 0 to 65535 and is the lowest
number in the range.
range specifies a number from 0 to 65535 and is the highest
number in the range.

OL-7433-09
2-7
Chapter 2
Classifying Traffic
Command
Purpose
Router(config-cmap)# match mpls experimental

mpls-exp-value
Specifies that the experimental (EXP) bit value of the packet must
match the MPLS EXP value that you specify.
mpls-exp-value specifies the value to which you want to set the
MPLS EXP bits. Valid values are from 0 to 7. You can specify up
to 8 MPLS EXP values.
Note

imposition value
This command is available only on the PRE1.
Specifies that the experimental (EXP) bit value on the imposed

label entry of the packet must match the MPLS EXP value that you
specify.
value specifies the value to which you want to set the MPLS EXP
bits. Valid values are from 0 to 7. You can specify up to 8 MPLS
EXP values.
Note

topmost value
The match mpls experimental imposition command is

available only on the PRE2.
Matches the experimental (EXP) value in the topmost label.

value specifies the value to which you want to set the MPLS EXP
bits in the topmost label header. Valid values are from 0 to 7.
Note
Router(config-cmap)# match qos-group number
The match mpls experimental topmost command is

Specifies that the packet QoS group number value must match the
specified QoS group number.
number is a group number from 0 to 99.
2-8
OL-7433-09
Chapter 2
Classifying Traffic
match Commands History

Cisco IOS Release
Command
Description
Release 12.0(17)SL
match
The match command was introduced on

the PRE1.
match access-group
This command was enhanced to include

matching on access lists.
match-all

matching on all of the match criteria.
match-any

matching on one match criterion.
match input-interface

matching on the input interface.
match ip dscp

matching on the IP DSCP value.
match ip precedence

matching on the IP precedence value.
match ip rtp

matching on the IP Real-Time Transport
Protocol (RTP).
match qos-group

matching on a QoS group.
Release 12.0(17)SL
match not

matching on criteria that the packet does
not match.
Release 12.0(22)S
match mpls experimental

matching on the MPLS experimental
(EXP) bit value.
Release 12.2(15)BX
match cos
This command was introduced on the

PRE2 and enhanced to include matching
on the class of service for inbound policies
only.
Release 12.2(16)BX

topmost

matching on the experimental (EXP) bit
value on the topmost label entry of the
packet.
Release 12.3(7)XI
match discard-class

matching on the discard-class value.

imposition

matching on the experimental (EXP) bit
value on the imposed label entry of the
packet.
match
This command was integrated in

Cisco IOS Release 12.2(28)SB.
Release 12.2(28)SB

OL-7433-09
2-9
Chapter 2
Classifying Traffic
Cisco IOS Release
Command
Description
Release 12.2(31)SB2
match cos

PRE3 to include matching on the class of
service for inbound policies only.
match ip dscp

PRE3 to include matching on the IP DSCP
value on the L2TP access concentrator
(LAC).
match vlan

PRE3 to include matching on the VLAN
ID for VLAN-group traffic classes.
match fr-de

PRE2, PRE3, and PRE4 to include
matching on the Frame Relay discard
eligibility (DE) bit.
Release 12.2(33)SB
Usage Guidelines for match Commands

match ip dscp
You must use the ip keyword to match DSCP values for IPv4 packets. The router supports only
DSCP matching of IPv4 packets.
match ip precedence
You must use the ip keyword to match precedence values for IPv4 packets. The router supports only
precedence matching of IPv4 packets.
match ip rtp
Use this command to match IP RTP packets destined to all even-numbered user datagram port (UDP)
port numbers in the range you specify.
Matching on the RTP port range is particularly effective for applications that use RTP, such as voice
or video.
match mpls-experimental-topmost
Use this command to include matching on the EXP bit value on the topmost label entry of the packet.
You can enter this command on input and output interfaces.
This command matches only on MPLS packets.
match not
Use this command to specify a QoS policy value that is not used as a match criterion. When you use
the match not command, all other values of that QoS policy become successful match criteria.
For example, if you enter the match not qos-group 4 command in class-map configuration mode,
the specified class accepts all QoS group values except 4 as successful match criteria.
2-10
OL-7433-09
Chapter 2
Classifying Traffic
match qos-group
Use this command to identify a specific QoS group number marking on a packet. You can also use
this command to convey the received MPLS experimental (EXP) field value to the output interface.
The router only uses the QoS group number as an identifying mark. The QoS group numbers have
no mathematical significance. For example, qos-group 2 is not greater than 1. The value simply
indicates that a packet marked with qos-group 2 is different than a packet marked with qos-group 1.
You define the treatment of these packets by defining QoS policies in a policy map.
The QoS group number is local to the router. The QoS group number that is marked on a packet does
not leave the router when the packet leaves the router. To mark the packet with a value that resides
in the packet, use an IP precedence setting, an IP DSCP setting, or another method of packet
marking.
match vlan
Do not use this command with any other match command in a class map.
Class-Default Class
The class named class-default is a predefined traffic class that the router uses to classify traffic that does
match one of the defined classes in a policy map. Although class-default is predefined, you can configure
policy actions for it in the policy map. If you do not configure policy actions, by default the router
classifies class-default traffic as first in, first out (FIFO) and gives the traffic best-effort treatment.
For more information on policy actions, see Chapter 3, Configuring QoS Policy Actions and Rules.
Each class map can have a maximum of 16 match statements.
The Cisco 10000 series router does not have a predefined scaling limit for classification.
A policy map with a traffic class based on the match fr-de command can be applied only on an
inbound Frame Relay interface.
Classifying Traffic Using a Class Map

To classify traffic using a class map, perform the following tasks:
Creating a Class Map, page 2-12 (required)
Verifying Traffic Classification, page 2-13 (optional)
Defining QoS Policy Actions, page 2-13 (required)

(See Chapter 3, Configuring QoS Policy Actions and Rules.)

OL-7433-09
2-11
Chapter 2
Classifying Traffic
Creating a Class Map

To create a class map and specify the way in which the router should classify traffic, enter the following
commands beginning in global configuration mode:
Step 1
Command
Purpose
Router(config)# class-map class-map-name
Creates a class map and enters class-map configuration mode.

class-map-name is the name of the class map. The name can be a
maximum of 40 alphanumeric characters.
Step 2
Router(config-class-map)# match
match_statement
Defines the classification criteria for the class map.

match_statement defines the matching criteria and can be one of
the optional match commands listed in the Defining Match
Criteria Using the match Commands section on page 2-5.
Configuration Examples for Classifying Traffic

Example 2-1 creates three class maps named voice, data, and application. The voice class map matches
traffic using the even UDP port number, which must be within the specified range. In this example, the
lowest port number can be 16384 and the highest port number can be 16383. The data class map matches
traffic using IP precedence 1 and the application class map matches using IP precedence 2.
Example 2-1
Creating a Class Map
Router(config)# class-map voice

Router(config-cmap)# match ip rtp 16384 16383
Router(config-cmap)# exit
Router(config)# class-map data
Router(config-cmap)# match ip precedence 1
Router(config)# class-map application
Example 2-2 creates a class map named class1 that tells the router to look for packets that belong to
access list 1 or that have an IP precedence value of 3 or 7.
Example 2-2
Defining Match Criteria
Router(config)# class-map class1

Router(config-cmap)# match access-group 1
Router(config-cmap)# match ip precedence 3 7
2-12
OL-7433-09
Chapter 2
Classifying Traffic
Verifying Traffic Classification

To verify traffic classification criteria, enter the following command in privileged EXEC configuration
mode:
Command
Purpose
Router# show class-map class-map-name
Displays configuration information about the class map you

specify, including the match criterion.
If you do not specify a class-map-name, the router displays
configuration information for all of the class maps configured on
the router.
Verification Example
Example 2-3 shows configuration information about the class map named class1.
Example 2-3
show class-map Command
Router# show class-map class1

Class Map match-all class1 (id 3)
Match access-group 1
Match ip precedence 3 7
Defining QoS Policy Actions

After you create a class map and configure the match criteria by which the Cisco 10000 series router
classifies traffic, you then need to tell the router how you want it to handle the matching packets. To do
this, you define QoS policy actions in a policy map.
For more information, see Chapter 3, Configuring QoS Policy Actions and Rules.

OL-7433-09
2-13
Chapter 2
Classifying Traffic
document. To display the documentation, click the document title or a section of the document
highlighted in blue. When appropriate, paths to applicable sections are listed below the documentation
title.
Feature
Classification
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2

Part 1: Classification
QoS Packet Marking tech note
QoS: Classification of Locally Sourced Packets, Release 12.0S tech note
Packet Classification Using the Frame Relay DLCI Number, Release 12.0S tech
note
QoS Packet Marking, Implementing Quality of Service tech note
QoS in the Enterprise, Deploying QoS in the Enterprise, Considerations for
Multiservice Networks
Class maps

Part 8: Modular Quality of Service Command-Line Interface > Configuring
the Modular Quality of Service Command-Line Interface > Modular QoS CLI
Configuration Task List > Creating a Traffic Class
Cisco IOS Quality of Service Solutions Command Reference, Release 12.2
access-list rate-limit -- fair-queue (WFQ) > class-map command
match commands

match Commands
Modular Quality of Service

Command-Line Interface (MQC)
Implementing Quality of Service (QoS) white paper

Modular Quality of Service Command-Line Interface Overview
Configuring the Modular Quality of Service Command-Line Interface
2-14
OL-7433-09
CH A P T E R

The second step in creating a QoS service policy is to define how you want the router to handle the
packets that match the classification rules you defined in Chapter 2, Classifying Traffic. The
Cisco 10000 series router supports a modular CLI element called a policy map to enable you to configure
a QoS policy with the appropriate actions and rules.
This chapter describes how to create QoS policies that the Cisco 10000 series router applies to specific
traffic classes. It includes the following topics:
QoS Policies, page 3-1
Types of QoS Actions, page 3-4
Policing Actions, page 3-11
QoS Inheritance, page 3-12
Traffic Subject to QoS Policies, page 3-17
ATM Virtual Circuits Without QoS Policies, page 3-17
QoS Performance, page 3-18
Configuring QoS Policies, page 3-18
Verifying QoS Policy Configurations, page 3-20
QoS Policies
After the Cisco 10000 series router classifies traffic based on the classification rules applied on an
inbound or outbound interface, the router needs to know how to handle the traffic that meets the
matching criteria. A modular quality of service command-line interface (MQC) element called a policy
map enables you to create QoS policies that tell the router the QoS actions and rules to apply to packets
belonging to a particular traffic class.
The following sections describe policy maps and QoS actions:
Feature History for QoS Policies, page 3-2
Defining QoS Actions Using a Policy Map, page 3-2
System Limits for Policy Maps, page 3-2
8K Policy Maps, page 3-3
policy-map Command, page 3-3

OL-7433-09
3-1
Chapter 3
QoS Policies
Feature History for QoS Policies

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The policy map feature was introduced on the router.
PRE1
Release 12.2(15)BX
PRE2
Release 12.2(28)SB
This feature was integrated in Cisco IOS Release 12.2(28)SB PRE2

for the PRE2.
Release 12.2(31)SB
PRE2, PRE3
Release 12.2(33)SB
This feature was enhanced to support 8192 policy maps per

system and implemented on the PRE3 and PRE4.
PRE3, PRE4
Defining QoS Actions Using a Policy Map

A policy map associates a traffic class with one or more QoS actions. When configuring a policy map,
you specify the name of a class map and configure the actions you want the router to take on the matching
traffic. Before you can create class policies in a policy map, the class must have classification criteria
configured in a class map. The router supports QoS actions such as marking, policing, and bandwidth
distribution.
A single policy map can be attached to multiple interfaces concurrently. If you attempt to attach a policy
map to an interface when the sum of the bandwidth assigned to classes is greater than 99 percent of the
available bandwidth, the router logs a warning message and does not allocate the requested bandwidth
to all of the classes. If the policy map is already attached to other interfaces, it is removed from them.
Whenever you modify a class policy in an attached policy map, class-based weighted fair queuing
(CBWFQ) is notified and the new classes are installed as part of the policy map in the CBWFQ system.
System Limits for Policy Maps

Table 3-1 lists the system limits for policy maps supported on the Cisco 10000 series router.
Table 3-1
Cisco IOS Release
Processor
Policy Maps per System1

(up to this amount)
All Releases prior to

Release 12.0(17)SL
PRE1
256
16
Release 12.0(17)SL
and later releases
PRE1
256
256
Release 12.0(25)SX
and later releases
PRE1
4096
32
Release 12.2(15)BX
and later releases
PRE2
256
64
Release 12.3(7)XI
and later releases
PRE2
4096
127
No. Classes per

Policy Map2
3-2
OL-7433-09
Chapter 3

QoS Policies
Table 3-1
Cisco IOS Release
Processor
Policy Maps per System1

(up to this amount)
Release 12.2(27)SBB
PRE2
4096
64
Release 12.2(31)SB2
and later releases
PRE3
4096
64
8192
64
4096
64
Release 12.2(33)SB and PRE3, PRE4

later releases
PRE2
No. Classes per

Policy Map2
1. Depending on the complexity of your configuration

2. Including the class-default class
8K Policy Maps
The 8K Policy Maps feature enables the router to support a maximum of 8192 unique policy maps for
the PRE3 and PRE4, doubling the number supported in previous releases. The router supports up to 4096
policy maps for the PRE2. To configure 8192 policy maps, the router must be running Cisco IOS
Release 12.2(33)SB. The router supports a maximum of 64 classes per policy map.
Note
The numbers above include both configured and attached policies. Each policy-map command counts
as one policy map, which counts against the system limit.
In releases through Cisco IOS Release 12.2(31)SB, the router supports a maximum of 4096 unique
policy maps for the PRE2 and PRE3.
For every additional policy map you create, approximately 2385 + (number of classes x 188) bytes of
memory are used. For example, 8192 policy maps with 64 classes in each uses approximately 118 MB
of memory. This is subtracted from memory that is available for such things as PPP sessions.
If you attempt to create 8193 policy maps, the following error message displays:
No more than 8192 policy maps can be defined.
The number of policy map instances supported on the router depends on the number of interfaces
(VCCIs) configured. The maximum number of interfaces allowed is 61,500. Therefore, the theoretical
maximum number of policy instances equals 2 x 61,500.
The router supports 512,000 policer instances and 4095 class maps.
policy-map Command
To create or modify a policy map, use the policy-map command in global configuration mode. Use the
no form of the command to remove a policy map. This command has no default behavior or values.
policy-map policy-map-name
no policy-map policy-map-name

OL-7433-09
3-3
Chapter 3
Types of QoS Actions
Syntax Description
policy-map-name
Is the name of the policy map. The name can be a maximum of 40

alphanumeric characters.
Usage Guidelines for the policy-map Command

You can configure class policies in a policy map only if the classes have match criteria defined for them
in a class map using the class-map and match commands.
You can attach a single policy map to multiple interfaces concurrently. After attaching the policy to
multiple interfaces, if you modify the policy such that it is no longer usable to the interfaces (for
example, the available bandwidth on the interface cannot accommodate the total bandwidth requested by
the class policies), the router removes the multiple attachments from the interfaces.

The following sections describe the QoS actions supported on the Cisco 10000 series router. These are
the actions that you configure in a policy map for specific traffic classes.
Input and Output Policy Actions, page 3-4
Policy Map ActionsReleases Prior to Cisco IOS Release 12.0(17)SL, page 3-7
Policy Map ActionsCisco IOS Release 12.0(17)SL and Later Releases, page 3-10
Policy Map ActionsCisco IOS Release 12.0(20)ST and Later Releases, page 3-10
Policy Map ActionsCisco IOS Release 12.0(22)S and Later Releases, page 3-11
Input and Output Policy Actions

The Cisco 10000 series router does not impose any restrictions on the classification definitions you
include in a class map. However, it does limit the input and output policy actions that you can define in
a policy map. These limitations are based on the type of interface on which you apply the service policy.
As indicated in Table 3-2 and Table 3-3, the interface types are:
Normal interface, including variable bit rate (VBR) virtual circuits (VCs) on ports configured in pxf
queuing mode
Tag interface (MPLS VPN)
Virtual access interface (VAI)
ATM unspecified bit rate (UBR) VCs and VCs configured on ports in no atm pxf queuing mode
3-4
OL-7433-09
Chapter 3

Table 3-2 lists the input policy actions that you can define in a policy map for specific interface types.
Table 3-2
Note
Input Policy Map Actions
Interface Type
Policy Map
Actions
Normal
Tag (MPLS VPN)
Virtual Access
ATM UBR VCs
bandwidth
Not Applicable
Not Applicable
Not Applicable
Not Applicable
queue-limit
Not Applicable
Not Applicable
Not Applicable
Not Applicable
priority
Not Applicable
Not Applicable
Not Applicable
Not Applicable
shape
Not Available
Not Available
Not Available
Not Available
random-detect
Not Applicable
Not Applicable
Not Applicable
Not Applicable
set ip prec/dscp
Valid
Not Applicable
Valid
Valid
set qos-group
Valid
Valid
Valid
Valid
set atm-clp
Not Applicable
Not Applicable
Not Applicable
Not Applicable
set cos
Not Applicable
Not Applicable
Not Applicable
Not Applicable
police
Valid
Valid
Valid
Valid
set mpls
experimental
Not Available
Not Available
Not Available
Not Available
In Table 3-2 and Table 3-3, Not Applicable indicates that you cannot perform the action on a Cisco
product or that it has no meaning in the context indicated. Not Available means the action is not
supported. When configuring an input policy map for a virtual access interface (VAI), be careful that you
do not include the Not Applicable or Not Available policy actions indicated. If you do, an error
message appears.

OL-7433-09
3-5
Chapter 3
Table 3-3 lists the output policy actions that you can define in a policy map for specific interface types.
Table 3-3
Output Policy Map Actions
Interface Type
Policy Map
Actions
Normal
Tag (MPLS VPN)
Virtual Access
ATM UBR VCs
bandwidth
Valid
Valid
Valid
Not Applicable
(Applied to the
VC, not the VAI)
queue-limit
Valid
Valid
Not Available
Not Available
priority
Valid
Valid
Valid
Not Applicable
(Applied to the
VC, not the VAI)
shape
Valid
Valid
Valid
Not Applicable
(Applied to the
VC, not the VAI)
random-detect
Valid
Valid
Not Available
Not Available
set ip prec/dscp
Valid
Not Applicable
Valid
Valid
set qos-group
Not Applicable
Not Applicable
Not Applicable
Not Applicable
set atm-clp
Valid
Not Available
Not Available
Not Available
set cos
Valid
police
set mpls
experimental
Not Available
Valid
Not Applicable
Valid
Valid
Valid
Valid
Not Applicable
Not Available
Not Applicable
Not Applicable
1. The interface must be an Ethernet interface that is configured for 802.1Q VLAN.
2. The virtual access interface must be using an 802.1Q VLAN interface.
3-6
OL-7433-09
Chapter 3

Policy Map ActionsReleases Prior to Cisco IOS Release 12.0(17)SL

Table 3-4 lists the QoS action commands supported in all releases prior to Cisco IOS
Release 12.0(17)SL. These actions are also available in later releases.
Table 3-4
Policy Map ActionsReleases Prior to Cisco IOS Release 12.0(17)SL
Action
Description
police bps [burst-normal | burst-excess]

Configures traffic policing in policy-map class
[conform-action action | exceed-action action] configuration mode.
bps is the average rate in bits per second. Valid
values are from 8,000 to 200,000,000.
(Optional) burst-normal is the normal burst size in
bytes. Valid values are from 1,000 to 51,200,000.
(Optional) burst-excess is the excess burst size in
bytes. Valid values are from 1,000 to 51,200,000.
conform-action action specifies the action to take
on packets that conform to the rate limit. The default
action is transmit.
exceed-action action specifies the action to take on
packets that exceed the rate limit. The default action
is drop.
Note
You can specify only one action each for

conform or exceed. Do not specify multiple
actions.
See Table 3-9 on page 3-12 for a list of available

policing actions.
queue-limit number-of-packets
Specifies or modifies the maximum number of

packets that the queue can hold for this class.
For PRE1, number-of-packets is a number from 32
to 16,384; the number must be a power of 2. If the
number you specify is not a power of 2, the router
uses the nearest power of 2 to your number.
For Cisco IOS Release 12.2(15)BX and
Release 12.2(16)BX, number-of-packets is a
number from 32 to 16,384. The number does not
need to be a power of 2.
For Cisco IOS Release 12.3(7)XI and later releases,
if the interface speed is less than 500 MB,
number-of-packets is a number from 8 to 4096; the
number must be a power of 2. If the interface speed
is greater than 500 MB, number-of-packets is a
number from 128 to 64,000; the number must be a
power of 2.

OL-7433-09
3-7
Chapter 3
Table 3-4
Policy Map ActionsReleases Prior to Cisco IOS Release 12.0(17)SL (continued)
Action
Description
random-detect dscp dscpvalue min-threshold

max-threshold drop-rate
Changes the minimum and maximum packet

thresholds for the differentiated services code point
(DSCP) value.
dscpvalue specifies the DSCP value, which is a
number from 0 to 63, or one of the following
keywords: EF, AFxy, or CS1 through CS7. For more
information, see the DSCP Per-Hop Behavior
min-threshold is the minimum threshold. Valid
values are from 32 to 16,384 (PRE1) or 1 to 16,384
(PRE2).
max-threshold is the maximum threshold. Valid
(PRE2).
drop-rate is the drop probability and is a number
from 1 to 65,535. For example, if you set this value
to 256, 1 out of 256 packets is dropped when the
average queue is at the maximum threshold.
Note
random-detect exponential-weight-constant
value
Default values for random-detect vary from

release to release. Use the show policy
interface command to view default values.
Allows you to modify the default method that

random-detect uses to calculate average queue size.
Random-detect determines the average queue size
based on the current queue length and the last
average queue length.
value is a number from 1 to 16. The default value is
typically 9.
The higher the value, the more dependent the

average is on the historical average, making
weighted random early detection (WRED) slow
to react to changing traffic conditions that may
be only temporary.
The lower the value, the less dependent the

average is on the historical average, making
WRED more sensitive to rapidly changing
traffic conditions.
Note
In most cases, the benefits of WRED can be

best realized if you enter the random-detect
command without arguments.
3-8
OL-7433-09
Chapter 3

Table 3-4
Policy Map ActionsReleases Prior to Cisco IOS Release 12.0(17)SL (continued)
Action
Description
random-detect precedence precedence

min-threshold max-threshold drop-rate
Changes the minimum and maximum packet

thresholds for the precedence level you specify.
precedence is a number from 0 to 7, where 0
typically represents low priority traffic that can be
aggressively managed (dropped) and 7 represents
high priority traffic. For more information, see the
set ip precedence command in this table.
min-threshold is the minimum threshold. Valid
(PRE2).
max-threshold is the maximum threshold. Valid
(PRE2).
drop-rate is the drop probability and is a number
from 1 to 65,535. For example, if you set this value
to 256, 1 out of 256 packets is dropped when the
average queue is at the maximum threshold.
Note
set atm-clp
Default values for random-detect vary from

release to release. Use the show policy
interface command to view default values.
Sets the cell loss priority (CLP) bit setting.

Configure this command as an output action only.
set ip dscp dscp-value
Marks a packet by setting the IP differentiated

services code point (DSCP) in the type of
service (TOS) byte.
dscp-value is a number from 0 to 63.
set ip precedence {number | name}
Sets the precedence value in the IP header.

number and the corresponding name are listed below
from least important to most important (for
example, 0routine is the least important and
7network is the most important).
0routine, 1priority, 2immediate,
3flash, 4flash-override, 5critical
6internet, 7network
set qos-group group-id
Sets a group ID that can be used later to classify

packets. Configure this command as an input action
only.
group-id is a number from 0 to 99.

OL-7433-09
3-9
Chapter 3
Policy Map ActionsCisco IOS Release 12.0(17)SL and Later Releases

Cisco IOS Release 12.0(17)SL adds support for the QoS action commands listed in Table 3-5. These
commands are also available in later releases.
Table 3-5
Policy Map ActionsCisco IOS Release 12.0(17)SL and Later Releases
Action
Description
bandwidth {bandwidth-kbps | percent percent}
Specifies or modifies the bandwidth allocated for

a traffic class in a policy map.
bandwidth-kbps is the guaranteed minimum
bandwidth (in kilobits per second) that you want
to allocate. Valid values are from 8 to 2,488,320.
percent percent is the percentage of the available
bandwidth that you want to allocate. Valid values
are from 1 to 99.
priority {bandwidth-kbps | percent percent}1
Assigns a priority to a traffic class in a policy

map. The priority class receives preference over
other class queues.
bandwidth-kbps is the guaranteed minimum
bandwidth (in kilobits per second) that you want
to allocate for the priority queue. Valid values are
from 8 to 2,000,000.
percent percent is the percentage of the available
bandwidth that you want to allocate for the
priority queue. Valid values are 1 to 99.
shape rate
Shapes traffic to the specified bit rate.

rate is a number from 8 to 2,488,320.
1. In Cisco IOS Release 12.0(23)SX1, Release 12.0(25)S, and Release 12.3(7)XI, and later releases, the syntax of the priority
command changed to priority (without any arguments). For these later releases, use the priority command with the police
command so that the priority class does not starve other traffic on a link. For more information, see the Avoiding Bandwidth
Starvation Due to Priority Services section on page 6-25 and the Bandwidth Starvation section on page 8-3.
Policy Map ActionsCisco IOS Release 12.0(20)ST and Later Releases

Cisco IOS Release 12.0(20)ST adds support for the QoS action command listed in Table 3-6. This
command is also available in later releases.
Table 3-6
Policy Map ActionsCisco IOS Release 12.0(20)ST and Later Releases
Action
Description
bandwidth remaining percent percent
Specifies or modifies the bandwidth allocated for a

traffic class in a policy map.
percent percent is the percentage of the remaining
bandwidth that you want to allocate. Valid values
are 1 to 99.
3-10
OL-7433-09
Chapter 3

Policing Actions
Policy Map ActionsCisco IOS Release 12.0(22)S and Later Releases

Cisco IOS Release 12.0(22)S adds support for the QoS action command listed in Table 3-7. This
command is also available in later releases.
Table 3-7
Policy Map ActionsCisco IOS Release 12.0(22)S and Later Releases
Action
Description
set mpls experimental value
Copies the setting of the IP precedence or DSCP

bits to the MPLS experimental bits of a packet.
value is a number from 0 to 7. Multiple values must
be space-delimited (for example, 3 4 7).
Policy Map ActionsCisco IOS Release 12.2(31)SB2 and Later Releases

Cisco IOS Release 12.2(31)SB2 adds support for the QoS action command listed in Table 3-8. This
command is also available in later 12.2 SB releases for the PRE3 and PRE4.
Table 3-8
Policy Map ActionsCisco IOS Release 12.2(31)SB2 and Later Releases
Action
Description
priority level level
Assigns priority to a traffic class at the priority

level specified.
level is the level of priority assigned to the priority
class. Valid values are:
1high priority
2low priority
The default value for priority is 1.

Note
In the same policy map, do not specify the

same priority level for two different
classes.
Policing Actions
The police command allows you to specify what you want the router to do when traffic meets, exceeds,
or violates the policing parameters you specified. Table 3-9 describes the policing actions the router
supports and the minimum Cisco IOS release required.

OL-7433-09
3-11
Chapter 3
QoS Inheritance
Table 3-9
Policing Actions
Action
Description
Introduced in Cisco IOS Release
drop
Drops the packet.
Release 12.0(9)SL
This is the default action for traffic that exceeds the

committed rate.
set-clp-transmit value
Sets the ATM cell loss priority (CLP) bit on the

ATM cell. Valid values are from 0 to 1.
Release 12.3(7)XI
set-discard-class-transmit
Sets the discard class attribute of a packet and

transmits the packet with the new discard class
setting.
Release 12.3(7)XI
set-dscp-transmit value
Sets the IP differentiated services code point

Release 12.0(9)SL
(DSCP) value and transmits the packet with the new
IP DSCP value setting. Valid values are from 0 to
63.
set-mpls-exp-transmit value
Sets the Multiprotocol Label Switching (MPLS)

experimental (EXP) bits and transmits the packet
with the new MPLS EXP bit value setting. Valid
values are from 0 to 7.
set-mpls-exp-imposition-transmit
value
Modifies the set-mpls-exp-transmit command to Release 12.3(7)XI

set the MPLS experimental (EXP) bits in the
imposed label headers and transmit the packet with
the new MPLS EXP bit value setting. Valid values
are from 0 to 7.
set-prec-transmit value
Sets the IP precedence and transmits the packet

with the new IP precedence value setting. Valid
set-qos-transmit value
Sets the qos-group value and transmits the packet Release 12.0(9)SL
with the new qos-group value setting. Valid values
are from 0 to 99.
transmit
Transmits the packet. The packet is not altered.
Release 12.0(22)S
Release 12.0(9)SL
Release 12.0(9)SL
QoS Inheritance
The Cisco 10000 series router applies service policies using the following QoS inheritance rules:
ATM portA service policy configured on an ATM port applies to all unspecified bit rate (UBR)
PVCs configured on the port without a service policy. Only unshaped UBR PVCs inherit the service
policy of the port. Variable bit rate (VBR), constant bit rate (CBR), and shaped UBR PVCs
configured on the port do not inherit the service policy of the port.
For more information about the ATM service classes, see the ATM Service Categories section on
page 3-13.
3-12
OL-7433-09
Chapter 3

QoS Inheritance
Label-controlled ATM (LC-ATM) subinterfaceA service policy configured on an LC-ATM

subinterface applies to the traffic of all constituent labeled VCs (LVCs).
Frame Relay physical interfaceA service policy configured on a Frame Relay physical interface
applies to the traffic of all PVCs configured on the port without a service policy.
Ethernet portA service policy configured on an Ethernet port applies to the traffic of all VLANs
configured on the port without a service policy.
SessionIf a service policy is not configured, the session inherits the service policy applied to the
virtual circuit (VC) or the inherited policy of the VC. If a session inherits a policy, the show policy
interface virtual access command does not display the state of the inherited policy. You can display
the state of the policy only on the interface where you configured the policy.
ATM Service Categories

The Cisco 10000 series router supports the following ATM service classes:
Constant Bit Rate, page 3-13
Unspecified Bit Rate, page 3-14
Variable Bit Rate, page 3-15
When operating in no atm pxf queuing mode, the router supports unshaped UBR PVCs, which do not
specify a peak cell rate (PCR). The router can support a high number of VCs when you configure the no
atm pxf queuing command on each port of the router. Point-to-Point Protocol over ATM (PPPoA)
supports one session per VC and requires that you enable no atm pxf queuing to support 32,000 PPPoA
sessions. Layer 2 Tunnel Protocol (L2TP) does not require that you enable no atm pxf queuing and
Point-to-Point Protocol over Ethernet (PPPoE) sessions do not require that you enable this queuing mode
because you can have 32,000 sessions on a single VC.
When operating in atm pxf queuing mode, the router supports the following ATM service classes:
UBR (Unshaped)No peak cell rate (PCR) specified
Shaped UBRPCR specified
VBR-nrtNon-real-time VBR
CBRConstant bit rate with PCR specified
If you specify a PCR value for UBR+, the router accepts the value, but does not use it, and it does not
notify you when this occurs.
For information about how the ATM service classes inherit QoS service policies, see the QoS
Inheritance section on page 3-12.
Constant Bit Rate

The constant bit rate (CBR) service class is a fixed bandwidth class, designed for ATM virtual circuits
(VCs) requiring a specific amount of bandwidth to be continuously available throughout the duration of
an active connection. CBR traffic is more time-dependent, less tolerant of delay, and generally more
deterministic in bandwidth requirements. Voice, circuit emulation, and high-resolution video are typical
examples of traffic utilizing this type of connection.
You define the required bandwidth in kbps by specifying a PCR. For example, the cbr 64 command
creates a CBR PVC with a PCR of 64 kbps.

OL-7433-09
3-13
Chapter 3
QoS Inheritance
An ATM VC configured as CBR can transmit cells at peak cell rate (PCR) at any time and for any
duration. It can also transmit cells at a rate less than the PCR or even emit no cells. CBR is characterized
by PCR.
Unspecified Bit Rate

The unspecified bit rate (UBR) service class is intended for non-real-time applications that do not
require any maximum boundary on the transfer delay or on the cell loss ratio. The router delivers UBR
traffic only when there is spare bandwidth in the network. This behavior is enforced by setting the cell
loss priority (CLP) bit on UBR traffic when it enters a port.
The router delivers UBR traffic out to the network only when no other traffic is waiting to be served first.
The UBR traffic does not affect the trunk loading calculations performed by the switch software.
UBR is the default class of service running at the maximum line rate of the physical interface.
The router supports both unshaped (no PCR specified) and shaped UBRs.
Shaped UBR
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.
Traffic that adheres to a particular profile can be shaped to meet downstream requirements, thereby
eliminating bottlenecks in topologies with data-rate mismatches.
The Cisco 10000 series router supports traffic shaping for unspecified bit rate (UBR) traffic. Traffic
shaping is performed on a per-port basis and involves passing UBR traffic streams through VC queues
for scheduled rate shaping. When traffic shaping is enabled, all traffic exiting the port out to the network
is subject to VC scheduling based on the parameters you configure for the connection.
3-14
OL-7433-09
Chapter 3

QoS Inheritance
Configuring UBRs
To configure a UBR, enter the following commands in ATM VC configuration mode:
Command
Purpose
Step 1
Router(config)# interface type

slot/module/port.subinterface
Specifies an interface or subinterface and enters interface

configuration mode.
Step 2
Router(config-if)# atm pxf queuing
Specifies one of two ATM PXF queuing modes for an

interface or ATM port.
or
Note
Router(config-if)# no atm pxf queuing
Step 3
Router(config-subif)# pvc vci/vpi
Do not change this queuing mode while VCs are

configured on the interface. If you need to change the
mode, delete the VCs first and then change the mode.
Changing the mode while VCs are configured can
produce undesired results, and the change does not
take effect until the router reloads.
Configures a PVC on the subinterface and enters ATM VC

configuration mode.
vci is the virtual channel identifier.
vpi is the virtual path identifier.
Step 4
Router(config-atm-vc)# ubr output-pcr
Creates a UBR.
output-pcr is the output peak cell rate. The router configures
a shaped UBR when you specify the output PCR. Otherwise,
the router configures unshaped UBR.
Variable Bit Rate

Variable bit rate (VBR) connections are classified as one of the following:
Real time (VBR-rt)Used for connections that transmit at a rate varying with time and that can be
described as bursty, often requiring large amounts of bandwidth when active. The VBR-rt class is
intended for applications that require tightly constrained delay and delay variation such as
compressed voice video conferencingfor example, video conferencing requires real-time data
transfer with bandwidth requirements that can vary in proportion to the dynamics of the video image
at any given time. The VBR-rt category is characterized in terms of peak cell rate (PCR), sustained
cell rate (SCR), and maximum burst size (MBS).
Nonreal time (VBR-nrt)Used for connections that are bursty but are not constrained by delay and
delay variation boundaries. For those cells in compliance with the traffic contract, a low cell loss is
expected. Non-time critical data file transfers are an example of a VBR-nrt connection. A VBR-nrt
connection is characterized by PCR, SCR, and MBS.

OL-7433-09
3-15
Chapter 3
QoS Inheritance
Configuring VBRs
To configure VBR-nrt, enter the following commands in ATM VC configuration mode:
Command
Purpose
Step 1

Specifies an interface or subinterface and enters interface

configuration mode.
Step 2
Specifies one of two ATM PXF queuing modes for an

interface or ATM port.
or
Note
Router(config-if)# no atm pxf queuing
Step 3
Router(config-subif)# pvc vci/vpi
Do not change this queuing mode while VCs are

configured on the interface. If you need to change the
mode, remove the VCs first and then change the
mode. Changing the mode while VCs are configured
can produce undesired results, and the change does
not take effect until the router reloads.
Configures a PVC on the subinterface and enters ATM VC

configuration mode.
Step 4
Router(config-atm-vc)# vbr-nrt output-pcr

output-scr output-mbs
Creates a VBR-nrt.
output-pcr is the output peak cell rate (PCR).
output-scr is the output sustained cell rate (SCR).
output-mbs is the output maximum burst cell size (MBS).
Note
If the PCR and SCR values are equal, the MBS value
is 1.
3-16
OL-7433-09
Chapter 3


Table 3-10 lists the types of traffic on the Cisco 10000 series router that are subject to QoS policies.
Table 3-10
QoS Applicability
Traffic Types
Subject to QoS
In-transit IP packets
Yes
Locally Destined Traffic
Layer 2 signaling packets such as PPP or Frame Relay negotiation packets,

status packets, and keepalive messages
No
Packets with IP precedence 6 or 7, which IP-based routing protocols typically No

use
All other locally destined traffic
Yes
Locally Originated Traffic
Packets marked by Cisco IOS software as PAK_Priority
No
Packets marked as IP precedence 6 or 7
No1
All other locally originated traffic
Yes
1. IP precedence 6 and 7 are not subject to QoS in all releases prior to Cisco IOS Release 12.0(22)S and in Cisco IOS
Release 12.3(7)XI2.
ATM Virtual Circuits Without QoS Policies

For all ATM virtual circuits (VCs) that do not have a class-default class configured with a shape service
policy (the shape command is configured), the Cisco 10000 series router limits the transmission rate of
the VC to the interface bandwidth minus the sum of the shape rates of other VCs on the interface that do
have service policies.
For example, if you have two VCs on a 150-Mbps interface and VC1 has a shaped service policy of
90 Mbps and VC2 does not have a service policy, the router polices VC2 to 60 Mbps (150 minus 90).
You can change this default behavior by using a shaped service policy on either the VC or the interface:
If you apply the shaped service policy to a single VC that is not an unshaped UBR VC, the router
applies the specified bandwidth to only that specific VC.
By default, the router first allocates bandwidth to the VBR VCs and then allocates any bandwidth
leftover to unshaped UBR VCs. To override this default behavior, apply a service policy to the
unshaped UBR VC using an hierarchical shaping policy. For more information, see Chapter 13,
Defining QoS for Multiple Policy Levels.
If you apply the policy to an interface, the router applies the specified bandwidth to all of the VCs
on the interface that do not have their own service policies.

OL-7433-09
3-17
Chapter 3
QoS Performance
QoS Performance
The parallel express forwarding (PXF) engine processes QoS traffic. Sometimes the PXF engine cannot
finish processing a packet before the packet completes a single pass through the PXF; the packet requires
additional processing. As a result, the packet is fed back through the PXF and processing continues. This
is referred to as a feedback operation.
Packets that are subject to both inbound and outbound QoS policies require additional PXF processing,
resulting in a feedback. However, packets subject to only one QoS policy (either inbound or outbound)
require only one pass through the PXF; a feedback is not needed.
Extra PXF passes reduce the system forwarding capacity. For example, if x packets per second require y
extra passes, the system forwarding capacity diminishes by xythe system has xy fewer packets per
second forwarding capacity than before. Although the forwarding capacity diminishes, system
performance is not affected. Packet classification processing affects only the forwarding capacity of the
system, not the speed. Packet delay due to additional PXF passes is negligible. Therefore, system
performance degradation occurs only at high system utilization.
The following describes PXF requirements:
All releases prior to Cisco IOS Release 12.0(17)SLFor each packet, the PXF requires one pass per
class-map match statement.
Cisco IOS Release 12.0(17)SLFor each packet, the PXF requires one pass for every four
non-access control list (ACL) class-map match statements. For each packet, the PXF requires one
pass for one ACL class-map match statement.
Cisco IOS Release 12.0(19)SL and later releasesFor each packet, the PXF requires one pass per
policy, regardless of the sum of the match statements in each class of the policy.
Configuring QoS Policies

To create a QoS policy, perform the following required tasks:
Creating a Policy Map, page 3-19
Defining QoS Actions in a Policy Map, page 3-20
Attaching Service Policies, page 3-20 (See Chapter 4, Attaching Service Policies.)
3-18
OL-7433-09
Chapter 3

Configuring QoS Policies
Creating a Policy Map

To create a policy map, enter the following commands beginning in global configuration mode:
Step 1
Command
Purpose
Router(config)# policy-map policy-map-name
Creates or modifies a policy map template with the name you

specify and enters policy-map configuration mode.
policy-map-name is the name of the policy map. The name can
be a maximum of 40 alphanumeric characters.
Step 2
Router(config-pmap)# class class-map-name
Specifies the class to which the policy map applies.

Note
On a given interface, the router uses the class-default

class to assign QoS policies to any packets that do not
belong to the classes defined in a policy map.
class-map-name is the name of the class map. The name can be

a maximum of 40 alphanumeric characters.
Configuration Examples for Creating a Policy Map

Example 3-1 shows how to create two policy maps named bronze and gold. The bronze policy includes
a class map named class1, which is configured with a bandwidth of 100 kbps. The gold policy includes
two class maps named voice and vlan. The voice class is the priority class and is policed at 50 kbps. The
vlan class has a bandwidth configuration of 20 percent of the link bandwidth.
Example 3-1
Assigning a Class to a Policy Map
Router(config)# policy-map bronze

Router(config-pmap)# class class1
Router(config-pmap-c)# bandwidth 100
Router(config-pmap-c)# exit
Router(config)# policy-map gold
Router(config-pmap)# class voice
Router(config-pmap-c)# priority
Router(config-pmap-c)# police 50
Router(config-pmap)# class vlan
Router(config-pmap-c)# bandwidth percent 20
Example 3-2 shows how to configure the class-default class in the policy map named mypolicy. In this
example, class-default has a bandwidth configuration of 128 kbps:
Example 3-2
Assigning the Default Class to a Policy Map
Router(config)# policy-map mypolicy

Router(config-pmap)# class class-default
Note
For more information about defining QoS actions in a policy map, see the Input and Output Policy
Actions section on page 3-4.

OL-7433-09
3-19
Chapter 3
Verifying QoS Policy Configurations
Defining QoS Actions in a Policy Map

To define QoS actions in a policy map, see the appropriate chapter in this guide.

Before the router can apply QoS service policies to packets, it needs to know which service policy to
apply. By attaching a service policy to the appropriate interface or virtual circuit, the router can then
apply the classification rules and QoS actions of the policy to the packets arriving at or leaving the router.
You can apply QoS service policies to:
Physical interfaces
Multilink PPP (MLPPP) and Multilink Frame Relay (MFR) interfaces
ATM unspecified bit rate (UBR) PVCs and point-to-point subinterfaces
ATM shaped UBR PVCs and point-to-point subinterfaces
ATM constant bit rate (CBR) and variable bit rate (VBR) PVCs and point-to-point subinterfaces
Label-controlled ATM (LC-ATM) subinterfaces
Frame Relay PVCs, point-to-point subinterfaces, and map classes
Ethernet VLANs
IP tunnel interfaces
Virtual access interfaces
For more information, see Chapter 4, Attaching Service Policies.

To verify a policy map configuration, enter any of the following commands in privileged EXEC mode:
Command
Purpose
Router# show policy map policy-map-name
Displays the configuration of all classes contained in the policy

map you specify.
policy-map-name is the name of the policy map whose
configuration information you want to display. The name can be
a maximum of 40 characters.
If you do not specify a policy-map-name, the command displays
the configuration of all policy maps configured on the router.
Router# show policy-map policy-map-name class

class-name
Displays the configuration of the class you specify. The policy

map you specify includes this class.
policy-map-name is the name of the policy map that contains the
class configuration you want to display.
class-name is the name of the class whose configuration you want
to display. If you do not specify class-name, the router displays
class configuration for all classes in the policy map.
3-20
OL-7433-09
Chapter 3

Command
Purpose
Router# show policy-map interface
Displays the configuration of all classes configured for all policy

maps attached to all interfaces.
Router# show policy-map interface interface-name

[input | output]
Displays the configuration of all classes configured for all

inbound or outbound policy maps attached to the specified
interface.
interface-name is the name of the interface or subinterface whose
policy configuration you want to display.
input indicates to display the statistics for the attached inbound
policy.
output indicates to display the statistics for the attached
outbound policy.
Note
Router# show policy-map interface [type number]

[input | output]
If you do not specify input or output, the router displays

information about all classes that are configured for all
inbound and outbound policies on all interfaces.

inbound or outbound service policies on all interfaces.
type is the interface type such as ATM.
number is the port number on the selected interface.
Note
Router# show policy-map interface [type number]

{input | output} class class-name

information about all classes that are configured for both
inbound and outbound policies on all interfaces.
Displays the configuration of the class you specify for the

inbound or outbound policy map you specify for all interfaces.
class-name is the name of the class configuration you want to
display.
Router# show queue interface-type

interface-number
Displays queuing configuration information and statistics for the

specified interface.

OL-7433-09
3-21
Chapter 3
Verification Example for Service Policies

Example 3-3 shows the information displayed when you enter the show policy-map interface
command. In the example output, random early detection (RED) drop statistics display for each IP
precedence.
Example 3-3
show policy-map interface Command
Router# show policy-map interface atm 7/0/0.1

ATM7/0/0.1
Service-policy output: wred_1 (21036)
Class-map: prec_0_0 (match-all) (21037/2)
1445 packets, 1502800 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100 (21038)
Output queue: 0/64; 1445/1502800 packets/bytes output, 0 drops
Bandwidth: 75 kbps (Weight 50)
Random-detect (precedence-based):
Exponential weight: 3 (1/8)
Current average queue length: 0 packets
---------------------------------------Min
Max
Prob
Rand-Drops Tail-Drops
0
16
32
1/1
0
0
1
18
32
1/10
0
0
2
20
32
1/10
0
0
3
22
32
1/10
0
0
4
24
32
1/10
0
0
5
26
32
1/10
0
0
6
28
32
1/10
0
0
7
30
32
1/10
0
0
Class-map: prec_0_1 (match-all) (21041/3)
Match: access-group 101 (21042)
---------------------------------------Min
Max
Prob
0
16
32
1/1
0
0
1
18
32
1/10
0
0
2
20
32
1/10
0
0
3
22
32
1/10
0
0
4
24
32
1/10
0
0
5
26
32
1/10
0
0
6
28
32
1/10
0
0
7
30
32
1/10
0
0
Class-map: class-default (match-any) (21045/0)
0 packets, 0 bytes
Match: any (21046)
0 packets, 0 bytes
5 minute rate 0 bps
3-22
OL-7433-09
Chapter 3

Feature
Class maps

Release 12.2
Part 8: Modular Quality of Service Command-Line Interface
> Configuring the Modular Quality of Service
Command-Line Interface > Modular QoS CLI
Cisco IOS Quality of Service Solutions Command Reference,
Release 12.2
access-list rate-limit -- fair-queue (WFQ) > class-map
command
Constant Bit Rate (CBR) ATM service class
ATM Traffic Management, Understanding the CBR Service

Category for ATM VCs
ATM Traffic Management, Understanding Router Support for
ATM Real-Time Service Categories
Policy maps

Release 12.2
Part 8: Modular Quality of Service Command-Line Interface
> Configuring the Modular Quality of Service
Command-Line Interface > Modular QoS CLI
Configuration Task List > Creating a Traffic Policy
Release 12.2
policy map - qos preclassify > policy-map command
Policy map scaling
Release Notes for the Cisco 10000 Series Internet Router for
Cisco IOS Release 12.0(25)SX
New Features in Cisco IOS Release 12.0(25)SX > Policy
Map Scaling
QoS service policies
QoS Configuration and Monitoring, Creating Time-of-Day QoS

Service Policies tech note
QoS Configuration and Monitoring, Monitoring Voice over IP
Quality of Service tech note
Site-to-Site MPLS VPN Solution for Service Providers, Service
Provider Quality-of-Service Overview tech note

OL-7433-09
3-23
Chapter 3
Feature
Unspecified bit rate (UBR) ATM service class
ATM Traffic Management, Understanding the UBR Service

Category for ATM Virtual Circuits
ATM Line Cards > 1-Port OC-12 ATM Line Card
Configuration > Commands > Interface and Subinterface
Commands > Creating a PVC
ATM Line Cards > 4-Port OC-3/STM-1 ATM Line Card
Configuration > ATM Commands > Interface and
Subinterface Commands > Creating a PVC
Cisco BPX 8600 Series Installation and Configuration,
Release 9.3.00
Configuring ATM Connections > ATM Connection Flow >
Traffic Shaping for CBR, rt-VBR, nrt-VBR, and UBR
Configuring ATM Connections > ATM Connection
Configuration > Unspecified Bit Rate Connections
Variable bit rate (VBR) ATM service class
ATM Traffic Management, Understanding the VBR-nrt Service

Category and Traffic Shaping for ATM VCs
Understanding the VBR-nrt Service Category and Traffic
Shaping for ATM VCs tech note
ATM Line Cards > 4-Port OC-3/STM-1 ATM Line Card
Configuration > ATM Commands > ATM PVC Commands
> Configuring VBR-nrt
Cisco BPX 8600 Series Installation and Configuration,
Release 9.3.00
Configuring ATM Connections > ATM Connection Flow >
Traffic Shaping for CBR, rt-VBR, nrt-VBR, and UBR
Configuring ATM Connections > ATM Connection
Configuration > Variable Bit Rate Connections
3-24
OL-7433-09
CH A P T E R

This chapter describes how to attach QoS service policies. After you create a QoS service policy, the
next step is to attach the policy to an interface or virtual circuit (VC). By doing this, the router knows
which service policy to apply to the packets arriving at or leaving the router. An interface can have
different service policies for inbound and outbound packets.
This chapter includes the following topics:
Interfaces Supporting QoS Service Policies, page 4-1
Attaching ATM QoS Service Policies, page 4-2
Attaching Frame Relay QoS Service Policies, page 4-11
Attaching Virtual LAN QoS Service Policies, page 4-20
Attaching Virtual Access Interface QoS Service Policies, page 4-23
Attaching Layer 2 Access Concentrator QoS Service Policies, page 4-30
Applying QoS on Layer 2 Tunnel Packets, page 4-32
Verifying and Monitoring QoS Service Policies, page 4-32
Interfaces Supporting QoS Service Policies

You can attach QoS service policies to:
Physical interfaces
Multilink Point-to-Point Protocol (MLPPP) and Multilink Frame Relay (MFR) interfaces
ATM unspecified bit rate (UBR) permanent virtual circuits (PVCs) and point-to-point subinterfaces
ATM shaped (peak cell rate is specified) UBR PVCs and point-to-point subinterfaces
ATM constant bit rate (CBR) PVCs and point-to-point subinterfaces
ATM variable bit rate (VBR) PVCs and point-to-point subinterfaces
Label-controlled Asynchronous Transfer Mode (LC-ATM) subinterfaces
Ethernet virtual local area networks (VLANs)
IP tunnel interfaces
Virtual access interfaces

OL-7433-09
4-1
Chapter 4
Each interface, subinterface, or PVC can have no more than two policy maps attached: one for inbound
traffic and one for outbound traffic. The router does not require that the inbound and outbound policies
be the same; you can attach different input and output policies.
Note
In a Cisco 10000 series router, we recommend that you do not attach a service-policy to an interface that
has an IP interface session.

You can attach a QoS service policy to an ATM interface, point-to-point subinterface, or PVC using the
service-policy command.
This section describes the following topics:
Feature History for ATM QoS, page 4-2
ATM QoS Inheritance, page 4-2
Restrictions and Limitations for Attaching ATM Service Policies, page 4-5
Attaching ATM QoS Service Policies to ATM Interfaces, Subinterfaces, and PVCs, page 4-5
Feature History for ATM QoS

Cisco IOS Release
Description
Required PRE
12.0(17)SL
The attachment of ATM QoS service policies feature was

introduced on the router.
PRE1
12.2(15)BX
PRE2
12.3(7)XI2
This feature was modified to allow you to attach ATM QoS PRE2
service policies to a range of PVCs and to a specific PVC
within the PVC range.
12.2(28)SB

PRE2
12.2(31)SB2
PRE2
PRE3
ATM QoS Inheritance

The following describes how ATM traffic inherits QoS policies:
For all releases earlier than Cisco IOS Release 12.3(7)XI2, if you attach a service policy only to the
physical interface, the aggregate of all unspecified bit rate (UBR) PVCs is subject to the physical
interfaces service policy.
For Cisco IOS Release 12.3(7)XI2 and later releases, if you attach a service policy only to the
physical interface, the aggregate of all unshaped UBR PVCs is subject to the physical interfaces
service policy. In Cisco IOS Release 12.3(7)XI2 and later releases, the router treats shaped UBR
PVCs like variable bit rate (VBR) and constant bit rate (CBR) PVCs.
4-2
OL-7433-09
Chapter 4

If you attach a service policy only to individual PVCs and not to the physical interface, only the
individual PVC is subject to its attached service policy.
If you attach service policies to both the physical interface and individual PVCs, the aggregate of
all UBR PVCs that do not have a service policy is subject to the physical interfaces service policy.
All PVCs that do have a service policy are individually subject to their attached service policies.
The router can operate in one of two ATM queueing modes: atm pxf queuing or no atm pxf queuing. The
router supports:
Unshaped UBR and nonreal-time VBR (VBR-nrt) PVCs when you configure the atm pxf queuing
command on the ATM interfaces
Unshaped UBR, shaped UBR, and VBR-nrt PVCs when you configure the no atm pxf queuing
command on the ATM interfaces
For more information about ATM service classes, see the ATM Service Categories section on
page 3-13.
The router allocates bandwidth to VBR, CBR, and shaped UBR PVCs before allocating bandwidth to
unshaped UBR PVCs. As a result, a diminished amount of bandwidth is available to allocate to unshaped
UBR PVCs. To override this behavior, create an hierarchical policy with the bandwidth specified and
attach the policy to the ATM port or physical interface. For more information, see Chapter 13, Defining
QoS for Multiple Policy Levels.
To attach a policy map that the router can use to apply QoS services to inbound and outbound packets,
use the service-policy command in interface or map class configuration mode. Use the no form of the
command to remove a service policy. This command has no default value or behavior.
service-policy {input | output} policy-map-name
no service-policy {input | output} policy-map-name
Syntax Description
input
Indicates to apply the QoS policy to inbound packets.
output
Indicates to apply the QoS policy to outbound packets.
policy-map-name
The name of the policy map (created using the policy-map command) you
want to attach. The policy-map-name can be a maximum of
service-policy Command History

Cisco IOS Release
Description
12.0(17)SL
12.2(15)BX
12.3(7)XI2
This command was enhanced on the PRE2 to allow you to attach a policy
map to a range of PVCs, and to a specific PVC within the PVC range.

OL-7433-09
4-3
Chapter 4
Cisco IOS Release
Description
12.2(28)SB
PRE2.
12.2(31)SB2
service-policy Command Modes

You can configure this command in the following configuration modes:
Bundle-VC (for ATM VC bundle members)
Interface
Map-class (for Frame Relay VCs)
PVC-in-range (for ATM VCs)
PVC range (for ATM VCs)
VC submode (for a standalone VC)
Usage Guidelines for the service-policy Command

The service-policy {input | output} policy-map-name command is used to attach a service policy to an
interface.
The service-policy policy-map-name command is used to create hierarchical service policies in
policy-map class configuration mode. Do not specify input or output when using the service-policy
command in an hierarchical policy.
In Cisco IOS Release 12.2(33)SB and later releases, the router no longer accepts the abbreviated form
(ser) of the service-policy command. Instead, you must spell out the command name service- before the
router accepts the command.
For example, when attaching a policy map the following error message appears when you attempt to use
the abbreviated form of the service-policy command:
Router(config)# interface gigabit1/1/0
Router(config-if)# ser out ?
% Unrecognized command
Router(config-if)# ser ?
% Unrecognized command
When you enter the command as service-, the router accepts the command as shown in the following
example:
Router(config-if)# service- ?
input Assign policy-map to the input of an interface
output Assign policy-map to the output of an interface
type
Configure CPL Service Policy
In releases earlier than Cisco IOS Release 12.2(33)SB, the router accepts the abbreviated form of the
service-policy command. For example, the router accepts the following commands:
Router(config)# interface gigabit1/1/0
Router(config-if)# ser out test
4-4
OL-7433-09
Chapter 4

Restrictions and Limitations for Attaching ATM Service Policies
On ATM line cards, you can apply a policy map to the physical interface, point-to-point
subinterfaces, and to individual PVCs. The router does not support applying QoS service policies to
point-to-multipoint subinterfaces. However, you can apply service policies to VCs that are on
multipoint interfaces.
The policy map you assign to a PVC takes precedence over the policy map you assign to the main
interface.
You must first configure the atm pxf queuing command on the interface and then attach the policy
map.
Note
Do not change the queuing mode while VCs are configured on the interface. To change the mode,
first delete the VCs and then change the mode. Changing the mode while VCs are configured
can produce undesired results, and the change does not take effect until the router reloads.
For a policy map to be successfully attached to an interface or ATM VC, the aggregate of the
configured minimum bandwidths of the policy map classes is limited to the speed of the interface,
unless you use the atm over-subscription-factor command to oversubscribe the interface.
The router does not support a service policy based on queuing for unshaped UBR PVCs.
Attaching ATM QoS Service Policies to ATM Interfaces, Subinterfaces, and

PVCs
You can attach a QoS service policy to ATM interfaces, point-to-point subinterfaces, or PVCs.
To attach an ATM QoS service policy, perform one of the following configuration tasks:
Attaching QoS Service Policies to an ATM Interface, page 4-6
Attaching QoS Service Policies to an ATM Point-to-Point Subinterface, page 4-7
Attaching QoS Service Policies to an ATM PVC, page 4-8
Attaching QoS Service Policies to an ATM PVC Range and an ATM PVC in a Range, page 4-9

OL-7433-09
4-5
Chapter 4
Attaching QoS Service Policies to an ATM Interface

To attach a QoS service policy to an ATM interface, enter the following commands beginning in interface
configuration mode:
Command
Purpose
Step 1
Router(config)# interface atm

slot/module/port
Specifies the interface to which you want to attach the QoS

service policy and enters interface configuration mode.
Step 2
Router(config-if)# service-policy {input

| output} policy-map-name
Attaches the service policy you specify to the interface.

input indicates to apply the service policy to inbound traffic on
the interface.
output indicates to apply the service policy to outbound traffic on
the interface.
Note
For QoS policies containing the bandwidth, priority,

random-detect, queue-limit, and shape commands, you
must specify the output keyword. If you use these
commands with the input keyword, the router ignores the
commands.
policy-map-name is the name of the policy map you want to attach

to the subinterface.
Note
The router applies the service policy to the ATM interface

and to all PVCs configured on the interface that do not
have their own QoS policy applied.
Configuration Example for Attaching QoS Service Policies to an ATM Interface

Example 4-1 shows how to attach the QoS service policy named myQoS to inbound traffic arriving at
ATM interface 1/0/0. The router applies the service policy to all of the PVCs configured on the interface.
Example 4-1
Attaching a QoS Policy to an ATM Interface
Router(config)# interface atm 1/0/0

Router(config-if)# service-policy input myQoS
4-6
OL-7433-09
Chapter 4

Attaching QoS Service Policies to an ATM Point-to-Point Subinterface

To attach a QoS service policy to an ATM point-to-point subinterface, enter the following commands
beginning in interface configuration mode:
Note
The router does not support QoS service policies on ATM point-to-multipoint subinterfaces. However,
you can apply service policies to VCs that are configured on multipoint interfaces.
Command
Purpose
Step 1

slot/module/port
Specifies the ATM interface and enters interface configuration

mode.
Step 2
Specifies the interface mode. In this mode, the interface operates

in low VC count. The router operates in atm pxf queuing mode by
default. You do not need to specify this mode unless the router is
currently configured for no atm pxf queuing.
Note
This is the required interface operating mode for

QoS service policies that include queuing actions.
Step 3
Router(config-if)# interface atm

point-to-point
Specifies the point-to-point subinterface and enters subinterface

configuration mode.
Step 4
Router(config-subif)# service-policy
{input | output} policy-map-name
Attaches the service policy you specify to the ATM subinterface.

the interface.
the interface.
Note

commands.

Note
The router applies the service policy to the

ATM subinterface and to all PVCs configured on the
subinterface that does not have its own QoS policy
applied.

OL-7433-09
4-7
Chapter 4
Configuration Example for Attaching QoS Service Policies to an ATM Point-to-Point Subinterface
Example 4-2 attaches a QoS service policy named myQoS to ATM point-to-point subinterface 3/0/0.1
for inbound traffic.
Example 4-2
Attaching a QoS Service Policy to an ATM Point-to-Point Subinterface

Router(config-if)# interface atm 3/0/0.1 point-to-point
Router(config-subif)# service-policy input myQoS
Attaching QoS Service Policies to an ATM PVC

To attach a QoS service policy to an individual ATM PVC, enter the following commands beginning in
interface configuration mode:
Command
Purpose
Step 1

slot/module/port

mode.
Step 2
Specifies the interface mode. In this mode, the interface operates

in low VC count. The router operates in atm pxf queuing mode by
default. You do not need to specify this mode unless the router is
currently configured for no atm pxf queuing.
Note
This is the required interface operating mode for QoS

service policies that include queuing actions.
Step 3

point-to-point
Specifies the point-to-point subinterface and enters subinterface

configuration mode.
Step 4
Router(config-subif)# pvc [name] vpi/vci
Creates an ATM permanent virtual circuit (PVC) and enters

ATM VC configuration mode.
name is the name used to identify the PVC.
vci is the virtual circuit identifier.
4-8
OL-7433-09
Chapter 4

Step 5
Command
Purpose
Router(config-if-atm-vc)# service-policy
[input | output] policy-map-name
Attaches the service policy you specify to the specified

ATM PVC.
the interface.
the interface.
Note

commands.

Note
The router applies the service policy to only the individual

ATM PVC that you specify.
Configuration Example for Attaching QoS Service Policies to an ATM PVC

Example 4-3 shows how to attach a QoS service policy named bronze to PVC 0/101 on the
ATM subinterface 3/0/0.1 for inbound traffic.
Example 4-3
Attaching a QoS Service Policy to an ATM PVC

Router(config)# interface atm 3/0/0.1
Router(config-subif)# pvc 0/101
Router(config-if-atm-vc)# service-policy input bronze
Attaching QoS Service Policies to an ATM PVC Range and an ATM PVC in a Range
To attach a QoS service policy to a range of ATM PVCs or to a specific ATM PVC in a range of PVCs,
enter the following commands beginning in global configuration mode:
Step 1
Command
Purpose

slot/module/port

mode.

OL-7433-09
4-9
Chapter 4
Step 2
Command
Purpose
Router(config-if)# range [range-name] pvc

start-vpi/start-vci end-vpi/end-vci
Defines a range of ATM permanent virtual circuits (PVCs). Enters

ATM range configuration mode.
(Optional) range-name is the name of the range. The range-name
can be a maximum of 15 characters.
start-vpi/ specifies the beginning value for a range of virtual path
identifiers (VPIs). The slash is required. If you do not provide a
VPI value or the slash, the default value of 0 is used. Valid values
for VPI are from 0 to 255.
start-vci specifies the beginning value for a range of virtual
channel identifiers (VCIs). Valid values are from 32 to 65535.
end-vpi/ specifies the end value for a range of virtual path
identifiers (VPIs). The slash is required. If you do not provide a
VPI value or the slash, the start-vpi value is used by default. Valid
values for VPI are from 0 to 255.
end-vci specifies the end value for a range of virtual channel
identifiers (VCIs). Valid values are from 32 to 65535.
Step 3
Router(config-if-atm-range)#
service-policy [input | output]
policy-map-name
Attaches the service policy you specify to the specified ATM PVC
range.
the interface.
the interface.
Note

commands.

Note
Step 4
Router(config-if-atm-range)# pvc-in-range
[pvc-name] vpi/vci
The router applies the service policy to only the PVCs

within the PVC range.
Configures an individual PVC within a PVC range. Enters ATM

range PVC configuration mode.
(Optional) pvc-name is the name given to the PVC. The PVC
name can have a maximum of 15 characters.
vpi/ is the virtual path identifier (VPI) for this PVC. The slash is
required. If you do not specify a VPI value or the slash, the default
value of 0 is used. Valid VPI values are from 0 to 255.
vci is the virtual circuit identifier (VCI) for this PVC. Valid values
are from 32 to 2047.
4-10
OL-7433-09
Chapter 4

Step 5
Command
Purpose
Router(config-if-atm-range-pvc)#
service-policy [input | output]
policy-map-name
Attaches the service policy you specify to the specified PVC

within the ATM PVC range.
the interface.
the interface.
Note

commands.

Note
The router applies the service policy to only the individual

ATM PVC within the PVC range.
Configuration Example for Attaching QoS Service Policies to an ATM PVC

Example 4-4 shows how to attach policy maps to a range of ATM PVCs and to a specific PVC within a
PVC range. In the example, the service policy named voice is attached to the range of ATM PVCs 1/32
to 1/34. The router applies the service policy to all of the PVCs within the PVC range. The service policy
named data is attached to PVC 1/33 within the PVC range. The router applies the service policy to only
PVC 1/33.
Example 4-4
Attaching Policy Maps to ATM PVC Ranges and PVCs in PVC Ranges

Router(config-if)# range pvc 1/32 1/34
Router(config-if-atm-range)# service-policy input voice
Router(config-if-atm-range)# pvc-in-range 1/33
Router(config-if-atm-range-vc)# service-policy input data

You can attach QoS service policies to Frame Relay interfaces, PVCs on subinterfaces, data-link
connection identifiers (DLCIs), and map classes using the map-class frame-relay and service-policy
commands. You can apply a map class to an interface or subinterface.
This section includes the following topics:
Feature History for Frame Relay QoS, page 4-12
Frame Relay QoS Inheritance, page 4-12
map-class frame-relay Command, page 4-12
Restrictions and Limitations for Frame Relay QoS Service Policies, page 4-13
Creating and Attaching QoS Policies to Frame Relay Interfaces, Subinterfaces, and Data-Link
Connection Identifiers, page 4-14

OL-7433-09
4-11
Chapter 4
Feature History for Frame Relay QoS

Cisco IOS Release
Description
Required PRE
12.0(23)SX
The attachment of Frame Relay QoS service policies

feature was introduced on the router.
PRE1
12.0(25)S
This feature was integrated into Cisco IOS

Release 12.0(25)S.
PRE1
Frame Relay QoS Inheritance

On Frame Relay interfaces, you can attach a service policy to the physical interface, an individual PVC,
or to both the physical interface and one or more PVCs. The following describes how Frame Relay traffic
inherits QoS policies:
If you attach a service policy only to the physical interface, the aggregate of all PVCs is subject to
the physical interfaces service policy.
If you attach a service policy only to individual PVCs and not to the physical interface, only the
individual PVC is subject to its attached service policy.
If you attach service policies to both the physical interface and individual PVCs, the aggregate of
all PVCs that do not have a service policy is subject to the physical interfaces service policy. All
PVCs that do have a service policy are individually subject to their attached service policies.
If you attach a service policy to a Frame Relay point-to-point subinterface (either directly or using
a map class), the router applies the QoS service policy to the aggregate of all of the DLCIs
configured on the subinterface.
If you attach a service policy to an individual DLCI (either directly or using a map class), the router
only applies the QoS service policy to the individual DLCI.
map-class frame-relay Command

To attach a QoS service policy to a Frame Relay interface, PVC on a subinterface, DLCI, or map class,
use the map-class frame-relay command in global configuration mode. To remove a map class, use the
no form of the command. This command has no default behavior.
map-class frame-relay map-class-name
no map-class frame-relay map-class-name
Syntax Description
map-class-name
The name of the map class. The map-class-name can be a maximum of

4-12
OL-7433-09
Chapter 4

map-class frame-relay Command History

Cisco IOS Release
Description
12.0(23)SX
12.0(25)S
This command was integrated into Cisco IOS Release 12.0(25)S.
Usage Guidelines for the map-class frame-relay Command

You can attach a QoS service policy to a Frame Relay map class using the service-policy command. For
more information, see the service-policy Command section on page 4-3.
You can apply a map class to a Frame Relay interface and subinterface.
Restrictions and Limitations for Frame Relay QoS Service Policies
Do not configure Frame Relay services using both the modular QoS command-line interface (MQC)
and the Frame Relay legacy commands.
For Cisco IOS Release 12.0(22)S and later releases, use the MQC to configure QoS services for
Frame Relay interfaces.
For all releases earlier than Cisco IOS Release 12.0(22)S, use the Frame Relay commands to
configure Frame Relay QoS services. For more information, see Appendix A, Configuring Frame
Relay QoS Using Frame Relay Legacy Commands.
The router has no preset scaling limit for Frame Relay QoS services. You can apply any number of
Frame Relay QoS services.
The router does not support attaching QoS service policies to Frame Relay point-to-multipoint
subinterfaces.
You cannot attach a policy map and a map class to the same subinterface. For Cisco IOS
Release 12.0(22)S and later releases, use the MQC to create and attach a policy map as described in
this chapter. For all releases earlier than Cisco IOS Release 12.0(22)S, use the Frame Relay legacy
commands to create and attach a Frame Relay QoS policy as described in Appendix A, Configuring
Frame Relay QoS Using Frame Relay Legacy Commands.
Output QoS policies that contain queuing actions must be nested service policies.

OL-7433-09
4-13
Chapter 4
Creating and Attaching QoS Policies to Frame Relay Interfaces, Subinterfaces,

and Data-Link Connection Identifiers
To create a Frame Relay QoS service policy, use the modular QoS CLI (MQC) elements called class
maps and policy maps. For more information, see the Classifying Traffic Using a Class Map section
on page 2-11 and the Creating a Policy Map section on page 3-19.
After you create the policy map, you can attach it to a Frame Relay interface, point-to-point subinterface,
data-link connection identifier (DLCI), or map class. You can apply a map class to an interface or
subinterface.
Note
The router does not support attaching a QoS service policy to a Frame Relay point-to-multipoint
subinterface. You can attach a QoS service policy to either a Frame Relay subinterface, a Frame Relay
DLCI, but not to both.
To attach a QoS service policy to a Frame Relay link, perform any of the following tasks:
Attaching a QoS Service Policy to a Frame Relay Interface or Point-to-Point Subinterface,

page 4-14
Attaching a QoS Service Policy to a Frame Relay DLCI, page 4-17
Attaching a QoS Service Policy to a Frame Relay Interface or Point-to-Point Subinterface

To attach a QoS policy to a Frame Relay interface or point-to-point subinterface, perform either of the
following tasks:
Attaching a QoS Policy Directly to a Frame Relay Interface or Point-to-Point Subinterface,

page 4-15
Attaching a QoS Service Policy to a Frame Relay Interface or Point-to-Point Subinterface Using a
Map Class, page 4-16
Note
You cannot attach a QoS policy to the same Frame Relay interface or subinterface by using both
the MQC and a map class. For releases earlier than Cisco IOS Release 12.0(22)S, use the Frame
Relay commands to attach QoS policies (see Appendix A, Configuring Frame Relay QoS Using
Frame Relay Legacy Commands). For Cisco IOS Release 12.0(22)S and later releases, use the
MQC.
4-14
OL-7433-09
Chapter 4

Attaching a QoS Policy Directly to a Frame Relay Interface or Point-to-Point Subinterface

To attach a QoS policy directly to a Frame Relay interface or point-to-point subinterface, enter the
following commands beginning in global configuration mode:
Command
Purpose
Step 1

slot/subslot/port.subinterface
Specifies the interface or subinterface to which you want to attach

the QoS service policy. Enters interface or subinterface
configuration mode.
Step 2

Applies the service policy you specify to the interface or

subinterface.
input indicates to apply the service policy to the inbound traffic
on the interface.
output indicates to apply the service policy to the outbound
traffic on the interface.
Note

must specify the output keyword. The router ignores
these commands when you use them with the input
keyword.

to the interface.
Note
The router applies the service policy to the aggregate of

all of the data link connection identifies (DLCIs)
configured on the interface or subinterface.
Configuration Examples for Attaching QoS Policies Directly to a Frame Relay Interface or Point-to-Point Subinterface
Example 4-5 shows how to attach the service policy named mypolicy2 to serial subinterface 1/0/0.1 in
the inbound direction.
Example 4-5
Attaching a QoS Policy Directly to a Frame Relay Point-to-Point Subinterface
Router(config)# interface serial 1/0/0.1 point-to-point

Router(config-if)# service-policy input mypolicy2
Example 4-6 shows how to attach the service policy named silver to serial interface 4/0/0 in the inbound
direction.
Example 4-6
Attaching a QoS Policy Directly to a Frame Relay Interface
Router(config)# interface serial 4/0/0

Router(config-if)# service-policy input silver

OL-7433-09
4-15
Chapter 4
Attaching a QoS Service Policy to a Frame Relay Interface or Point-to-Point Subinterface Using a Map Class
To attach a QoS service policy to a Frame Relay interface or point-to-point subinterface using a Frame
Relay map class, enter the following commands beginning in global configuration mode:
Step 1
Command
Purpose
Router(config)# map-class frame-relay

map-class-name
Specifies a map class and enters map-class configuration mode.

map-class-name identifies the map class.
Step 2
Router(config-map-c)# service-policy
Applies the service policy you specify to the map class.

input indicates to apply the service policy to the inbound traffic
on the interface.
output indicates to apply the service policy to the outbound
traffic on the interface.
Note

keyword.
policy-map-name is the name of the policy map.

Step 3
Router(config-map-c)# exit
Exits map-class configuration mode.
Step 4

[point-to-point]
Specifies the interface or subinterface to which you want to attach

the map class. Enters interface or subinterface configuration
mode.
Step 5
Router(config-if)# frame-relay class name
Associates a map class with a Frame Relay subinterface.

name is the name of the map class you want to associate with the
interface.
Note
The router applies the service policy configured in the

map class to the aggregate of all of the data link
connection identifies (DLCIs) on the interface or
subinterface.
Configuration Examples for Attaching a QoS Policy to a Frame Relay Interface or Point-to-Point Subinterface Using a Map Class
Example 4-7 shows how to configure a policy map named policy1 within a Frame Relay map class
named VCs_slow and attach the map class to serial subinterface 1/0/0.1.
Example 4-7
Configuring a QoS Service Policy on a Frame Relay Subinterface Using a Map Class
Router(config)# map-class frame-relay VCs_slow

Router(config-map-c)# service-policy policy1
Router(config-if)# frame-relay class VCs-slow
4-16
OL-7433-09
Chapter 4

Example 4-8 shows how to configure a policy map named bronze within a Frame Relay map class named
slow-VCs and attach the map class to serial interface 2/0/0.
Example 4-8
Configuring a QoS Service Policy on a Frame Relay Interface Using a Map Class
Router(config)# map-class frame-relay slow-VCs

Router(config-map-c)# service-policy bronze
Router(config-if)# frame-relay class slow-VCs
Attaching a QoS Service Policy to a Frame Relay DLCI

To attach a QoS service policy to a Frame Relay DLCI, perform one of the following tasks:
Note
Attaching a QoS Service Policy Directly to a Frame Relay DLCI, page 4-17
Attaching a QoS Service Policy to a Frame Relay DLCI Using a Map Class, page 4-19
You cannot attach a QoS policy to the same Frame Relay interface or subinterface by using both the
MQC and a map class. For releases earlier than Cisco IOS Release 12.0(22)S, use the Frame Relay
commands to attach QoS policies (see Appendix A, Configuring Frame Relay QoS Using Frame Relay
Legacy Commands). For Cisco IOS Release 12.0(22)S and later releases, use the MQC.
Attaching a QoS Service Policy Directly to a Frame Relay DLCI

You can attach a QoS service policy to a Frame Relay DLCI that is configured on an interface or
subinterface.
To attach a QoS service policy directly to a Frame Relay DLCI, enter the following commands beginning
in global configuration mode:
Command
Purpose
Step 1

[point-to-point]
Specifies the interface or subinterface. Enters interface or

subinterface configuration mode.
Step 2
Router(config-if)# frame-relay
interface-dlci dlci
Assigns a data link connection identifier (DLCI) to the Frame

Relay interface or subinterface. Enters Frame Relay DLCI
configuration mode.
dlci is a number that identifies the data link connection on the
interface or subinterface.

OL-7433-09
4-17
Chapter 4
Step 3
Command
Purpose
Router(config-fr-dlci)# service-policy
Attaches the service policy you specify to the individual DLCI.

the interface.
output indicates to apply the service policy to outbound traffic
on the interface.
Note

random-detect, queue-limit, and shape commands,
you must specify the output keyword. If you use these
commands with the input keyword, the router ignores
the commands.

Note
The router applies the service policy only to the

individual DLCI.
Configuration Examples for Attaching a QoS Service Policy Directly to a Frame Relay DLCI
Example 4-9 shows how to attach the service policy named user_policy to the data link connection
identifier (DLCI) 100 on serial subinterface 1/0/0.1 for outbound packets.
Example 4-9
Attaching a QoS Service Policy Directly to a DLCI Configured on a Subinterface

Router(config-if)# frame-relay interface-dlci 100
Router(config-fr-dlci)# service-policy output user_policy
Example 4-10 shows how to attach the service policy named voice to DLCI 201 on serial interface 4/0/0
for outbound packets.
Example 4-10 Attaching a QoS Service Policy Directly to a DLCI Configured on an Interface
Router(config-fr-dlci)# service-policy output voice
4-18
OL-7433-09
Chapter 4

Attaching a QoS Service Policy to a Frame Relay DLCI Using a Map Class
You can attach a map class with a QoS policy to a Frame Relay DLCI that is configured on an interface
or subinterface.
To attach a QoS service policy to a Frame Relay DLCI using a map class, enter the following commands
beginning in global configuration mode:
Command
Purpose
Step 1

map-class-name
Specifies a map class and enters map-class configuration mode.
Step 2

the interface.
the interface.
Note

commands.

Step 3
Step 4

[point-to-point]
Specifies an interface or subinterface. Enters interface or

Step 5
interface-dlci dlci
Assigns a data link connection identifier (DLCI) to the Frame

configuration mode.
dlci is a number that identifies the data link connection on the
Step 6
Router(config-fr-dlci)# frame-relay class

name
Associates a map class with the individual DLCI.

name is the name of the map class that you want to associate with
the DLCI.
Note

map class to only this individual DLCI.

OL-7433-09
4-19
Chapter 4
Configuration Examples for Attaching a QoS Service Policy to a Frame Relay DLCI Using a Map Class
Example 4-11 shows how to configure a policy map named gold within a Frame Relay map class named
group1, and attach the map class to DLCI 101 configured on the serial subinterface 1/0/0.2.
Example 4-11 Attaching a QoS Service Policy to a Frame Relay Subinterface DLCI Using a Map Class
Router(config)# map-class frame-relay group1
Router(config-map-class)# service-policy gold
Router(config-map-class)# exit
Router(config-fr-dlci)# frame-relay class group1
Example 4-12 shows how to configure a policy map named Premium within a Frame Relay map class
named voice, and attach the map class to DLCI 200 configured on the serial interface 3/0/0.
Example 4-12 Attaching a QoS Service Policy to a Frame Relay Interface DLCI Using a Map Class
Router(config)# map-class frame-relay voice
Router(config-map-class)# service-policy Premium
Router(config-map-class)# exit
Router(config-fr-dlci)# frame-relay class voice

On Ethernet interfaces with virtual LANs (VLANs) configured, you can attach a QoS service policy to
the physical interface, an individual VLAN subinterface, or to both the physical interface and one or
more VLAN subinterfaces.
Feature History for VLAN QoS, page 4-20
VLAN QoS Inheritance, page 4-21
Restrictions and Limitations for Attaching QoS Services to VLAN Subinterfaces, page 4-21
Attaching QoS Policies to VLAN Interfaces and Subinterfaces, page 4-21
Feature History for VLAN QoS

Cisco IOS Release
Description
Required PRE
12.0(25)SX
The attachment of virtual LAN QoS service policies was

PRE1
12.2(15)BX
PRE2
12.2(28)SB

PRE2
4-20
OL-7433-09
Chapter 4

VLAN QoS Inheritance

The following describes how VLAN traffic inherits QoS policies:
If you attach a service policy only to the physical interface, the aggregate of all of the VLAN
subinterfaces is subject to the physical interfaces service policy.
If you attach a service policy only to individual VLAN subinterfaces and not to the physical
interface, only the individual VLAN subinterfaces are subject to the attached service policies.
If you attach service policies to both the physical interface and to individual VLAN subinterfaces,
the aggregate of all VLAN subinterfaces without a service policy is subject to the physical
interfaces service policy, and all of the VLAN subinterfaces with a service policy are individually
subject to their attached service policies.
Restrictions and Limitations for Attaching QoS Services to VLAN Subinterfaces
The Cisco 10000 series router currently supports PPPoE over IEEE 802.1Q VLAN on Gigabit
Ethernet and Fast Ethernet 8-port half-height line cards. The Fast Ethernet port (fe0/0/0) of the
performance routing engine (PRE) does not support this feature. This port is for management traffic
only.
For PRE1 and PRE2, output QoS policies that contain queueing actions must be nested service
policies. However, for PRE3 and PRE4, there is no such restriction and thereby a flat queueing
policy can be directly attached to a VLAN subinterface.
Attaching QoS Policies to VLAN Interfaces and Subinterfaces

To attach QoS service policies to VLAN interfaces and subinterfaces, perform any of the following
configuration tasks:
Attaching QoS Service Policies to Physical Interfaces with VLAN Subinterfaces, page 4-22
Attaching QoS Service Policies to VLAN Subinterfaces, page 4-23

OL-7433-09
4-21
Chapter 4
Attaching QoS Service Policies to Physical Interfaces with VLAN Subinterfaces

To attach QoS service policies to physical interfaces with VLAN subinterfaces, enter the following
Command
Purpose
Step 1

slot/module/port
Specifies the physical Ethernet interface to which you want to

attach the QoS service policy. Enters interface configuration
mode.
Step 2

Attaches the service policy you specify to the physical interface.

the interface.
the interface.
Note

commands.

Step 3
Router(config-if)# interface type

Creates a subinterface and enters subinterface configuration

mode.
Step 4
Router(config-subif)# encapsulation dot1q

vlanid
Configures the subinterface as a VLAN subinterface.

dot1q defines the encapsulation format as IEEE 802.1Q VLAN.
vlanid is a number that identifies the VLAN.
Note
The router applies the service policy of the physical

interface to all of the individual VLANs configured on the
interface.
Configuration Example for Attaching QoS Policies to Physical Interfaces with VLAN Subinterfaces
Example 4-13 shows how to attach a service policy named myQoS to the physical Gigabit Ethernet
interface 1/0/0 for inbound traffic. VLAN 4, configured on the GigabitEthernet subinterface 1/0/0.3,
inherits the service policy of the physical Gigabit Ethernet interface 1/0/0.
Example 4-13 Attaching a QoS Policy to a VLAN Interface
Router(config)# interface GigabitEthernet 1/0/0
Router(config-if)# service-policy input myQoS
Router(config-if)# interface GigabitEthernet 1/0/0.3
Router(config-subif)# encapsulation dot1q 4
4-22
OL-7433-09
Chapter 4

Attaching QoS Service Policies to VLAN Subinterfaces

To attach a QoS service policy to a VLAN subinterface, enter the following commands beginning in
global configuration mode:
Command
Purpose
Step 1

Specifies the Ethernet subinterface to which you want to attach

the QoS service policy. Enters subinterface configuration mode.
Step 2

vlanid
Creates a VLAN subinterface.

dot1q defines the encapsulation format as IEEE 802.1Q VLAN.
vlanid is a number that identifies the VLAN.
Step 3
Attaches the service policy you specify to the subinterface.

the interface.
the interface.
Note

must specify the output keyword. When you use these
commands .

Note
The router applies the service policy to only this

individual VLAN subinterface.
Configuration Example for Attaching a QoS Service Policy to a VLAN Subinterface

Example 4-14 shows how to attach a policy map named bronze to VLAN 4 on GigabitEthernet
subinterface 1/0/0.3 for outbound traffic.
Example 4-14 Attaching a QoS Policy to an Individual VLAN
Router(config)# interface GigabitEthernet 1/0/0.3
Router(config-subif)# service-policy output bronze

A virtual access interface (VAI) is a virtual interface that the router dynamically creates and configures
when a remote user initiates a session to the Cisco 10000 series router.
1.
The router uses a template of operational parameters called a virtual template interface to create and
configure the VAI.
2.
When the user connection terminates, the router deletes the VAI and frees the resources for other
client uses.

OL-7433-09
4-23
Chapter 4
The virtual template interface is a logical entity that the router applies dynamically as needed to a
connection. It is a configuration for an interface, but it is not tied to the physical interface. The VAI uses
the attributes of the virtual template to create the session, which results in a VAI that is uniquely
configured for a specific user.
After you configure a virtual template, configure the virtual connection that will use the template and
then apply the template to the virtual connection. The order in which you create virtual templates and
configure the virtual connections that use the templates is not important. However, before a remote user
initiates a session to the router, both the virtual templates and connections must exist.
If you use a RADIUS server, the RADIUS configuration takes precedence over the virtual template
configuration. For example, the RADIUS configuration might override some parameters and the virtual
template provides the remainder of the configuration.
Note
Virtual template interfaces and VAIs do not apply to routed bridge encapsulation (RBE) over ATM.
For more information about virtual templates and VAIs, see the Cisco 10000 Series Broadband
Aggregation and Leased-Line Configuration Guide at:
http://www.cisco.com/en/US/products/hw/routers/ps133/products_configuration_guide_book0918
6a00804d45ca.html
Feature History for VAI QoS, page 4-24
VAI QoS Inheritance, page 4-24
Restrictions and Limitations for Attaching QoS Services to a VAI, page 4-25
Attaching QoS Policies to VAIs Using Virtual Template Interfaces, page 4-25
Feature History for VAI QoS

Cisco IOS Release
Description
Required PRE
12.0(25)SX
The attachment of VAI QoS service policies feature was

PRE1
12.2(15)BX
PRE2
12.2(28)SB

PRE2
12.2(31)SB2
PRE2
PRE3
VAI QoS Inheritance

When you apply a QoS service policy to a virtual circuit (VC), the virtual access interfaces (VAIs) that
use that VC inherit the QoS policy of the VC. Any VAI that uses that VC is subject to the queueing,
policing, and marking actions defined in the VC service policy.
4-24
OL-7433-09
Chapter 4

Restrictions and Limitations for Attaching QoS Services to a VAI
Before a remote user initiates a session to the router, both the virtual template and virtual connection
must exist.
Cisco IOS Release 12.2(25)SX does not support the configuration of broadband aggregation (BBA)
groups using RADIUS. You must configure BBA groups manually.
You can only apply a QoS policy with queueing-related actions to a VC. Do not apply service
policies with class-based weighted fair queueing (CBWFQ) actions to a VAI using a virtual
template. The router supports queueing only when you apply the QoS policy to a VC.
You can apply a QoS policy without queueing-related actions to either a VC or a VAI, but not to both
at the same time.
You cannot use RADIUS to configure a QoS policy on the VC.
If you configure a QoS policy on a VC, the show policy interface VAI command does not display
information to indicate that the VAI is subject to the VC service policy. However, if you apply a
policy directly to a VAI, the show policy interface VAI command displays information about the
policy on the VAI.
Attaching QoS Policies to VAIs Using Virtual Template Interfaces

To attach QoS service policies to virtual access interfaces (VAIs), perform the following required
Applying a QoS Service Policy to a Virtual Template Interface, page 4-26
Applying a Virtual Template Interface to a BBA Group, page 4-27
Attaching a BBA Group to an Interface or Subinterface for PPPoE Sessions, page 4-28

OL-7433-09
4-25
Chapter 4
Applying a QoS Service Policy to a Virtual Template Interface

To apply a QoS service policy to a virtual template interface, enter the following commands beginning
Step 1
Command
Purpose
Router(config)# interface virtual-template

number
Creates a virtual template interface and enters interface

configuration mode.
number is a number from 1 to 200 that identifies the virtual
template.
Step 2
Router(config-if)# service-policy [input |

output] policy-map-name
Attaches the service policy you specify to the virtual template

interface.
the interface.
output indicates to apply the service policy to outbound traffic
on the interface.
Note

random-detect, queue-limit, and shape commands,
you must specify the output keyword. When you use
these commands with the input keyword, the router
ignores the commands.
Configuration Example for Applying QoS Policies to Virtual Template Interfaces

Example 4-15 shows how to apply the policy map named policy1 to the virtual template named
virtual-template1 for all inbound traffic. In this example, the virtual template configuration also includes
CHAP authentication and point-to-point protocol (PPP) authorization and accounting.
Example 4-15 Applying QoS Policies to a Virtual Template Interface
Router(config)# interface virtual-template1
Router(config-if)# ip unnumbered Loopback1
Router(config-if)# no peer default ip address
Router(config-if)# ppp authentication chap vpn1
Router(config-if)# ppp authorization vpn1
Router(config-if)# ppp accounting vpn1
Router(config-if)# service-policy policy1
4-26
OL-7433-09
Chapter 4

Applying a Virtual Template Interface to a BBA Group

A BBA group is a template used to control connections. Cisco IOS Release 12.2(25)SX does not support
the configuration of broadband aggregation (BBA) groups using RADIUS. You must configure BBA
groups manually.
To apply a virtual template interface to a BBA group for Point-to-Point Protocol over Ethernet (PPPoE)
over IEEE 802.1Q VLAN, enter the following commands beginning in global configuration mode:
Step 1
Command
Purpose
Router(config)# bba-group pppoe {name |

global}
Configures a BBA group to be used to establish PPPoE

sessions.
name identifies the BBA group. You can configure multiple
BBA groups.
global is the default BBA group used for PPPoE connections
when a BBA group name is not specified.
Step 2
Router(config-bba)# virtual-template
template-number
Applies the virtual template interface you specify to the BBA

group. The router uses the virtual template interface to clone
virtual access interfaces (VAIs).
template-number is a number that identifies the virtual
template and is used to clone virtual-access interfaces.
Note
You cannot simultaneously configure a BBA group for PPPoE and a VPDN group for PPPoE. If you
configure a BBA group and then you configure a VPDN group, the protocol command in VPDN
accept-dialin configuration mode does not include an option for PPPoE (for example, you cannot specify
the protocol pppoe command). Use the no bba-group pppoe command to re-enable the pppoe option
for the protocol command.
Configuration Example for Applying a Virtual Template Interface to a BBA Group

Example 4-16 shows how to create a BBA group named vpn1 and apply the virtual template named
VirtualTemplate 1 to the group. In the example, the BBA group configuration limits the number of
sessions per VC to 5 and specifies that a maximum of 10 PPPoE sessions can be terminated on the
interface or subinterface to which the BBA group is attached.
Example 4-16 Applying a Virtual Template Interface to a BBA Group
Router(config)# bba-group pppoe vpn1
Router(config-bba)# VirtualTemplate 1
Router(config-bba)# sessions per-vc limit 5
Router(config-bba)# sessions per-mac limit 10

OL-7433-09
4-27
Chapter 4
Attaching a BBA Group to an Interface or Subinterface for PPPoE Sessions

You can attach a BBA group to physical interfaces and subinterfaces with varying encapsulations, or to
permanent virtual circuits (PVCs).
To attach a BBA group to an interface or subinterface, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1

Specifies the interface or subinterface to which you want to

attach the BBA group. Enters subinterface configuration
mode.
Step 2
Router(config-subif)# protocol pppoe group

group-name
Attaches the BBA group to the specified interface or

subinterface. Enables PPP over Ethernet (PPPoE) sessions to
be established on the interface, subinterface, or permanent
virtual circuits (PVCs).
Note
The router applies the QoS policy of the virtual

template associated with the BBA group. The QoS
policy applies to this interface or subinterface and to
any PVCs configured on the interface or subinterface
without a specified policy.
Configuration Examples for Attaching a BBA Group to an Interface or Subinterface

Example 4-17 shows how to attach a BBA group named bba1 to the ATM interface 1/0/0 for PPPoE
sessions.
Example 4-17 Attaching a BBA Group to an Interface
Router(config-if)# protocol pppoe group bba1
Router(config-if)# encapsulation ppp
Router(config-if)# pppoe enable
Example 4-18 shows how to attach a BBA group named bba-voice to ATM subinterface 4/0/0.10 for
PPPoE sessions. The example also assigns VLAN 4 to the subinterface.
Example 4-18 Attaching a BBA Group to a VLAN Subinterface
Router(config-subif)# protocol pppoe group bba-voice
Router(config-subif)# pppoe enable
4-28
OL-7433-09
Chapter 4

Example 4-19 shows how to use a virtual template interface to apply a QoS policy to PPPoE sessions.
The example configuration shows how to create a virtual template interface, apply the virtual template
to a BBA group, and apply the BBA group to an interface or subinterface. The QoS policy named policy1
is applied to the virtual template interface named Virtual-Template1; Virtual-Template1 is applied to the
BBA group named VPN_1; and VPN_1 is applied to the ATM interface 5/0, which is configured for
aalsnap encapsulation. The QoS policy named voice1 is applied to the virtual template interface named
Virtual-Template2; Virtual-Template2 is applied to the BBA group named VPN_2; and VPN_2 is applied
to the FastEthernet subinterface 3/0/0.33, which is configured as a VLAN subinterface.
Example 4-19 Applying a QoS Policy to PPPoE Sessions Using a Virtual Template on a VLAN
Subinterface
Router(config)# interface Virtual-Template1
Router(config-if)# mtu 1492
Router(config-if)# peer default ip address pool pool1
Router(config-if)# ppp authentication chap
Router(config-if)# service-policy input policy1
Router(config-if)# ppp authorization
Router(config-if)# service-policy input voice1
Router(config)# bba-group pppoe VPN_1
Router(config-bba)# virtual-template 1
Router(config-bba)# sessions per-vlan limit 5
!
!
Router(config)# bba-group pppoe VPN_2
Router(config-bba)# virtual-template 2
Router(config-bba)# sessions per-vlan limit 5
!
!
Router(config)# interface atm 5/0
Router(config-if)# protocol pppoe group VPN_1
Router(config-if)# encapsulation aalsnap
!
Router(config)# interface FastEthernet 3/0/0.33
Router(config-subif)# protocol pppoe group VPN_2
Router(config-subif)# encapsulation dot.1q 5
!
!

OL-7433-09
4-29
Chapter 4
Attaching Layer 2 Access Concentrator QoS Service Policies

You can attach a QoS service policy to an ATM VC on the Layer 2 access concentrator (LAC) using the
Feature History for LAC QoS, page 4-30
LAC QoS Inheritance, page 4-30
Restrictions and Limitations for Attaching LAC QoS, page 4-31
Attaching QoS Policies to LAC ATM Virtual Circuits, page 4-31
Feature History for LAC QoS

Cisco IOS Release
Description
Required PRE
12.3(7)XI3
The QoS: Broadband Aggregation Enhancements - Phase 1

feature (also known as LAC QoS) was introduced on the
router to support LAC QoS policies on an ATM virtual
circuit.
PRE2
12.2(28)SB
LAC QoS was integrated in Cisco IOS

Release 12.2(28)SB.
PRE2
LAC QoS Inheritance

The following describes how LAC traffic inherits QoS policies:
If you attach a service policy only to the physical ATM interface, the aggregate of all unshaped UBR
PVCs is subject to the physical interfaces service policy. The router treats shaped UBR PVCs like
variable bit rate (VBR) and constant bit rate (CBR) PVCs.
If you attach a service policy only to individual ATM PVCs and not to the physical ATM interface,
only the individual PVC is subject to its attached service policy.
If you attach service policies to both the physical ATM interface and individual ATM PVCs, the
aggregate of all UBR PVCs without an attached service policy is subject to the physical interfaces
service policy. All PVCs with an attached service policy are individually subject to their attached
service policies.
When a service policy is attached to an individual ATM PVC, sessions that use that PVC inherit the
service policy applied to the PVC or the inherited policy of the PVC. If a session inherits a policy, the
show policy interface virtual access command does not display the state of the inherited policy. You
can display the state of the policy only on the interface where you configured the policy. If you attach a
service policy only to:
The physical Ethernet interface, the aggregate of all of the VLAN subinterfaces is subject to the
physical interfaces service policy.
Individual VLAN subinterfaces, and not to the physical Ethernet interface, only the individual
VLAN subinterfaces are subject to the attached service policies.
4-30
OL-7433-09
Chapter 4

If you attach service policies to both the Ethernet physical interface and to individual VLAN
subinterfaces, the aggregate of all VLAN subinterfaces without a service policy is subject to the
physical interfaces service policy, and all of the VLAN subinterfaces with a service policy are
individually subject to their attached service policies.
Restrictions and Limitations for Attaching LAC QoS
Cisco IOS Release 12.3(7)XI3 does not support the attachment of LAC QoS directly to sessions by
attaching QoS services to a virtual access interface (VAI) using a virtual template. If you apply LAC
QoS to a virtual template, the router ignores it.
On ATM line cards, you can apply a policy map to the physical interface, point-to-point
subinterfaces, and to individual PVCs. The router does not support applying QoS service policies to
point-to-multipoint interfaces. However, you can apply service policies to VCs that are on
multipoint interfaces.
The policy map you assign to an ATM PVC takes precedence over the policy map you assign to the
main interface.
You must first configure the atm pxf queuing command on the ATM interface and then attach the
policy map.
Note
Do not change the queuing mode while VCs are configured on the interface. If you must change
the mode, first delete the VCs and then change the mode. Changing the mode while VCs are
configured can produce undesired results, and the change does not take effect until the router
reloads.
The aggregate bandwidth of the classes configured in a policy map is limited to the speed of the
interface or subinterface to which it is applied. The aggregate bandwidth of a policy applied to a VC
is limited to the capacity of the port, unless you configure oversubscription by using the
atm over-subscription-factor command.
The router does not support a service policy based on queueing for unshaped UBR PVCs.
The Cisco 10000 series router currently supports PPPoE over IEEE 802.1Q VLAN on Gigabit
Ethernet and Fast Ethernet 8-port half-height line cards. In a PPPoE over Ethernet configuration,
you cannot attach a service policy to a subinterface if another service policy is already attached to
its main interface.
The Fast Ethernet port (fe0/0/0) of the performance routing engine (PRE) does not support PPPoE
over Ethernet. This port is for management traffic only.
Output QoS policies that contain queueing actions must be hierarchical service policies. For more
information, see Chapter 13, Defining QoS for Multiple Policy Levels.
Attaching QoS Policies to LAC ATM Virtual Circuits

You can attach QoS policies to ATM virtual circuits on the LAC. For information about how to do this,
see the Attaching QoS Service Policies to an ATM PVC section on page 4-8.

OL-7433-09
4-31
Chapter 4

The following describes how the Cisco 10000 series router applies QoS policies to Layer 2 tunnel
packets:
Inbound Layer 2 Tunnel Packets
1.
When a packet arrives on a physical interface, the router applies the input QoS policy (if one exists)
of the physical interface.
2.
The router then applies the input QoS policy of the packets tunnel interface.
Outbound Layer 2 Tunnel Packets

1.
When a packet leaves the router, it applies the output QoS policy (if one exists) of the outbound
tunnel interface.
2.
The router then applies the output QoS policy of the outbound physical interface.
When applying the QoS policy, the physical interface uses the tunnel outer IP header; the tunnel interface
uses the inner IP header.
When an IP packet is encapsulated in a tunnel, the router copies the packets original IP type of service
(ToS) value into the tunnel header.
Verifying and Monitoring QoS Service Policies

To verify and monitor QoS service policies attached to ATM, Frame Relay, and VLAN subinterfaces,
enter any of the following commands in privileged EXEC mode:
Command
Purpose
Router# show interface
Displays Layer 2 statistics for all interfaces configured on the

router.
Router# show interfaces virtual-access number

[configuration]
Displays statistical and configuration information about the active

VAI that was created using a virtual template interface.
number is the number of the virtual access interface (VAI) that is
used to identify the VAI.
The configuration keyword indicates to display only
configuration information.
4-32
OL-7433-09
Chapter 4

Command
Purpose
Displays the packet statistics of all classes that are configured for
all service policies either on the specified interface or subinterface
or on a specific PVC on the interface.
The following information displays for each policy:
Class map name
Total packets and bytes
30-second traffic rate
Queue statistics
Bandwidth allocated for the class map
Congestion avoidance parameters
In Cisco IOS Release 12.0(25)SX and later releases, the

show policy-map interface command also provides RED drop
counts for each IP precedence.
Router# show policy-map interface virtual-access
number
Displays statistical and configuration information about the

QoS policy configured on the virtual access interface (VAI) you
specify.
number is the number of the virtual access interface (VAI) that
identifies the VAI.
If you configure a QoS policy on a VC, the show policy-map
interface virtual-access command does not display information
to indicate that the VAI is subject to the VC service policy.
However, if you apply a QoS policy directly to a VAI, the show
policy interface virtual-access command displays information
about the QoS policy on the VAI.
Router# show pxf interface interface [detail]
Displays a summary of the statistics accumulated by column 0 of

the PXF for the interface you specify. If you do not specify an
interface, a summary of the statistics for all PXF interfaces on the
router appears.
interface is the type and number of the interface (for example,
serial 4/0/0).
detail indicates to display detailed information rather than a
summary of information.
The command displays information such as the following:
Number of packets input
Number of errors
Overall status of the interface queues
Board-level statistics for connection to the backplane
Router# show pppoe session all
Displays a summary of the status of all active tunnels for each

session ID.
Router# show pppoe session packets
Displays a summary of the status of all packets traveling in and

traveling out of a PPPoE session.

OL-7433-09
4-33
Chapter 4
Note
The show pxf commands are entered as show hardware pxf on the PRE1. For example, to
view a statistical summary of PXF column 0 for the specified interface, enter the
show hardware pxf interface command.
Verification Example for QoS Service Policies

Example 4-20 shows the information displayed when you enter the show policy-map interface
command. In the sample output, random early detection (RED) drop statistics display for each
IP precedence.
The sample output in Example 4-20 is based on the following class map and policy map configurations:
class-map match-all
match access-group
class-map match-all
match access-group
class-map match-any
policy-map wred_1
class prec_0_0
bandwidth 75
random-detect
random-detect
random-detect
class prec_0_1
bandwidth 73
random-detect
random-detect
random-detect
prec_0_0
100
prec_0_1
101
class-default
precedence-based
exponential-weighting-constant3
precedence 0 10 20 10
precedence-based
exponential-weighting-constant 3
precedence 1 10 20 10
Example 4-20 Displaying RED Drop Counts

ATM7/0/0.2: VC 2/101 Service-policy output: wred_1
Class-map: prec_0_0 (match-all)
0 packets, 0 bytes
Match: access-group 100
Output queue: 0/64; 0/0 packets/bytes output, 0/0 drops
Bandwidth : 75 kbps (Weight 3)
----------------------------------------------------------------------TOSMinMaxMarkRand-DropTail-Drop
precedencethresthresprobabilityPktsBytesPktsByte
----------------------------------------------------------------------0 1020 1/100 0 0
0
1 3664 1/100 0 0
0
2 4064 1/100 0 0
0
3 4464 1/100 0 0
0
4 4864 1/100 0 0
0
5 5264 1/100 0 0
0
6 5664 1/100 0 0
0
7 6064 1/100 0 0
0
4-34
OL-7433-09
Chapter 4

Class-map: prec_0_1 (match-all)

0 packets, 0 bytes
----------------------------------------------------------------------TOSMinMaxMarkRand-DropTail-Drop
precedencethresthresprobabilityPktsBytesPktsByte
----------------------------------------------------------------------0 32 64 1/100 0 0
0
1 10 20 1/100 0 0
0
2 40 64 1/100 0 0
0
3 44 64 1/100 0 0
0
4 48 64 1/100 0 0
0
5 52 64 1/100 0 0
0
6 56 64 1/100 0 0
0
7 60 64 1/100 0 0
0
Class-map: class-default (match-any)
0 packets, 0 bytes
Match: any
Example 4-21 shows another example of the information that appears when you enter the
show policy-map interface command. The sample output in Example 4-21 is based on a broadband
configuration with the following class map and policy map configurations:
class-map
match ip
match ip
class-map
match ip
match-any VoIP
dscp ef
precedence 5
match-any VoD
precedence 3
policy-map QOS-Policy1
class VoIP
police 64000 8000 0 conform-action transmit exceed-action drop violate-action drop
priority
class VoD
bandwidth 1500
Example 4-21 Displaying Packet Statistics for a Specific Interface

ATM7/0/0.2: VC 2/101 Service-policy output: QOS-Policy1
Class-map: VoIP (match-any)
0 packets, 0 bytes
Match: ip dscp ef
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip precedence 5
0 packets, 0 bytes
5 minute rate 0 bps
Police:
64000 bps, 8000 limit, 0 extended limit

OL-7433-09
4-35
Chapter 4
conformed 0 packets, 0 bytes; action: transmit

exceeded 0 packets, 0 bytes; action: drop
violated 0 packets, 0 bytes; action: drop
Absolute priority
Class-map: VoD (match-any)
0 packets, 0 bytes
0 packets, 0 bytes
5 minute rate 0 bps
0 packets, 0 bytes
Match: any
This section provides hyperlinks to additional Cisco documentation for the features described in this
Feature
BBA Groups
Cisco 10000 Series Broadband Aggregation and Lease-Line Configuration

Guide
Configuring PPPoE over Ethernet and IEEE 802.1Q VLAN
Frame Relay legacy commands

Subinterface Policy Maps
Cross-Platform Release Notes for Cisco IOS Release 12.0S

Part 2: New Features and Important Notes > New and Changed
Information > New Software Features in Cisco IOS Release 12.0(22)S
> Subinterface Policy Maps
Part 8: Modular Quality of Service Command-Line Interface >
Configuring the Modular Quality of Service Command-Line Interface >
Modular QoS CLI Configuration Task List > Attaching a Traffic Policy
to an Interface
Virtual Access Interfaces

Guide
Configuring Remote Access to MPLS VPN
Virtual Template Interfaces

Guide
Cisco IOS Dial Technologies Configuration Guide, Release 12.2
Configuring Virtual Template Interfaces
4-36
OL-7433-09
CH A P T E R

Developing a queuing strategy is an important step in optimizing network functionality and services.
Equally important is ensuring that bandwidth is shared fairly among the competing traffic queues. By
distributing bandwidth between the different queues of a link, you can increase the capacity of a link and
optimize aspects of your network that have greater importance.
The Cisco 10000 series router allows you to distribute bandwidth to ensure that bandwidth is shared
fairly between the queues of a link. This chapter describes bandwidth distribution between queues on the
Cisco 10000 series router and contains the following topics:
Bandwidth Distribution Between Queues, page 5-1
Interfaces Supporting Bandwidth Distribution, page 5-2
Unused Bandwidth Allocation, page 5-3
Bandwidth Calculations, page 5-4
Bandwidth Allocation to PVCs, page 5-5
Class-Default Bandwidth Guarantee, page 5-6
Committed Rate Data, page 5-6
Bandwidth and Priority Service, page 5-7
Distribution of Remaining Bandwidth Using Ratio, page 5-14
Restrictions and Limitations for Bandwidth Distribution, page 5-9
Configuring Bandwidth Distribution Between Queues, page 5-10
Verifying and Monitoring Bandwidth Distribution, page 5-12
Bandwidth Distribution Between Queues

Distributing bandwidth on a link using the bandwidth command ensures that bandwidth is shared fairly
among competing traffic. The router uses class queues to allocate bandwidth, first servicing priority
queue traffic followed by either bandwidth guarantee or bandwidth remaining queue traffic. By default,
a minimum bandwidth guaranteed queue has buffers for up to 50 milliseconds of 256-byte packets at line
rate, but not less than 32 packets. The router does not ensure latency characteristics for bandwidth
queues.

OL-7433-09
5-1
Chapter 5
The router can commit up to 99 percent of the interface bandwidth to one or more class queues. If you
attempt to attach a policy map to an interface when the sum of the bandwidth assigned to classes is
greater than 99 percent of the available bandwidth, the router logs a warning message and does not
allocate the requested bandwidth to all of the classes. If the policy map is already attached to other
interfaces, it is removed from them.
Bandwidth includes the Layer 2 header, Layer 2 payload, and two bytes of trailer.
On ATM networks, the bandwidth is cell-based and includes Layer 2 overhead and cell overhead
(for example, cell overhead for SNAP and AAL5, the cell header, the AAL5 trailer, and AAL5
padding).
On Frame Relay networks with link fragmentation and interleaving (LFI) enabled, bandwidth is
based on fragments with Layer 2 overhead included.
The router converts the specified bandwidth to the nearest multiple of 1/255 (PRE1) or 1/65535 (PRE2)
of the interface speed. Use the show policy-map interface command to display the actual bandwidth.
Feature History for Bandwidth Distribution Between Queues

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
PRE1
Release 12.2(15)BX
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3. The Distribution PRE2

of Remaining Bandwidth Using Ratio feature was also
PRE3
introduced on the PRE3 only.
Interfaces Supporting Bandwidth Distribution

The following describes interface support for bandwidth distribution using the bandwidth command:
Interfaces Supporting the bandwidth Command (Outbound Only)
Physical
Multilink PPP and Multilink Frame Relay
ATM shaped (peak cell rate is specified) unspecified bit rate (UBR) PVCs and point-to-point
subinterfaces
Label-controlled ATM (LC-ATM) subinterfaces *
Frame Relay PVCs, point-to-point subinterfaces, and map classes *
Ethernet VLANs *
* Requires a specific type of hierarchical policy. For more information, see the Chapter 13, Defining
5-2
OL-7433-09
Chapter 5

Note
The router only supports the bandwidth command on outbound interfaces.

Interfaces Not Supporting the bandwidth Command
Note
ATM unshaped (no peak cell rate specified) UBR PVCs and point-to-point subinterfaces
IP tunnel
Virtual-access (See the VAI QoS Inheritance section on page 4-24.)
The router does not support the bandwidth command on inbound interfaces.
Unused Bandwidth Allocation

After the Cisco 10000 series router allocates bandwidth to priority and bandwidth guaranteed class
queues, the router divides unused (excess) bandwidth among the packets remaining in the class queues.
For all releases prior to Cisco IOS Release 12.0(19)SL, the router divides the unused bandwidth
equally among the class queues with outstanding packets.
For Cisco IOS Release 12.0(19)SL and later releases, the router divides unused bandwidth
proportional to the class bandwidth guarantee. You can override this proportional distribution by
using the bandwidth remaining percent command. The router distributes unused bandwidth only
to non-priority queues; a priority queue never receives more than its guaranteed bandwidth.
In Example 5-1, the policy-map named VLAN guarantees 30 percent of the bandwidth to the class
named Customer1 and 60 percent of the bandwidth to the class named Customer2. If you apply the
VLAN policy map to a 1-Mbps link, 300 kbps is guaranteed to class Customer1 and 600 kbps is
guaranteed to class Customer2, with 100 kbps remaining for the class-default class. If the class-default
class does not need additional bandwidth, the unused 100 kbps is available for use by class Customer1
and class Customer2. If both classes need the bandwidth, they share it in proportion to the configured
rates. In this example, the sharing ratio is 30:60 or 1:2.
Example 5-1
Excess Bandwidth Allocation
Router(config)# policy-map VLAN

Router(config-pmap)# class Customer1
Router(config-pmap)# class Customer2
Traffic Classes That Can Use Excess Bandwidth

The bandwidth and priority commands provide bandwidth guarantees that are often described as
bandwidth that is reserved or set aside. However, neither command implements a true reservation of
bandwidth. If a traffic class is not using its configured bandwidth, the unused bandwidth is shared among
the other classes.
The Cisco 10000 series router guarantees a priority class 95 percent of the bandwidth. As a result, the
priority class can starve other traffic classes unless you configure policing. The router does not police
the priority class unless you configure a policer.

OL-7433-09
5-3
Chapter 5
Table 5-1 describes when a class configured with the bandwidth or priority command can use excess
bandwidth.
Table 5-1
Comparing When a Bandwidth and Priority Class Can Use Excess Bandwidth
Command
Congestion
Non-Congestion
bandwidth
Allowed to exceed the allocated rate.
Allowed to exceed the

allocated rate.
priority
Not allowed to exceed the configured

rate.
Not allowed to exceed the

configured rate.
If you configure a policer for the priority

class, the router polices the priority class
to the configured bps or percentage rate,
and discards any excess packets.
If you configure a policer, the

router polices the priority
class to the configured bps or
percentage rate, and discards
any excess packets.
If you do not configure a policer, the

router guarantees a priority class 95
percent of the bandwidth, which can
result in bandwidth starvation of other
traffic classes.
Bandwidth Calculations
The Cisco 10000 series router can commit up to 99 percent of the interface bandwidth to one or more
class queues. If you attempt to attach a policy map to an interface when the sum of the bandwidth
assigned to classes is greater than 99 percent of the available bandwidth, the router logs a warning
message and does not allocate the requested bandwidth to all of the classes. If the policy map is already
attached to other interfaces, it is removed from them.
For a physical interface, the total bandwidth is the bandwidth of the physical interface. The router
converts the minimum bandwidth that you specify to the nearest multiple of 1/255 (PRE1) or 1/65535
(PRE2) of the interface speed. When you request a value that is not a multiple of 1/255 or 1/65535, the
router chooses the nearest multiple.
The bandwidth percentage is based on the interface bandwidth. In a hierarchical policy, the bandwidth
percentage is based on the nearest parent shape rate.
By default, a minimum bandwidth guaranteed queue has buffers for up to 50 milliseconds of 256-byte
packets at line rate, but not less than 32 packets.
5-4
OL-7433-09
Chapter 5

Table 5-2 describes the data included and excluded in the committed rate when a traffic shaper and
policer are configured on the interface.
Table 5-2
Committed Rate Data for Policing and Shaping
Action
Frame Relay
Ethernet
Policing
No bit or byte
stuffing
Generic Traffic Shaping No cell header

Class-Based Shaping
No 7E flags
No Frame Check
Sequence (FCS)
No Inter-Frame Gap
(IFG)
No Preamble
No Start of Frame
Delimiter (SFD)
ATM
ADSL
SDSL
Class-Based Shaping
Class-Based Shaping
No ATM cell
No AAL Common
overhead
Part Convergence
Sublayer (CPCS) pad No AAL Common
Part Convergence
No ATM trailer
Sublayer (CPCS) pad
No ATM cell
overhead
No AAL Common
Part Convergence
Sublayer (CPCS) pad
No ATM trailer
No ATM trailer
Class-Based Shaping
Class-Based Shaping
No Frame Check
Sequence (FCS)
Shaping
4 bytes of Frame
Check Sequence
(FCS)
No bit or byte
stuffing
No 7E flags
Generic Traffic Shaping ATM cell header

Class-Based Shaping
No Inter-Frame Gap
(IFG)
No Preamble
No Start of Frame
Delimiter (SFD)
AAL Common Part No ATM cell

overhead
Convergence
Sublayer (CPCS) pad No AAL Common
Part Convergence
ATM trailer
Sublayer (CPCS) pad
No ATM cell
overhead
No AAL Common
Part Convergence
Sublayer (CPCS) pad
Frame Check
Sequence (FCS)
1. The router does not account for flags or Frame Check Sequence (FCS) that the hardware adds or removes.
Table 5-3 describes what bandwidth is based on for each media type.
Table 5-3
Basis for Bandwidth
Media
Bandwidth Based On
Frame Relay
Fragments1
Ethernet
Bits
ATM variable bit rate (VBR)
Sustained cell rate (SCR)
ATM unspecified bit rate (UBR)
Peak cell rate (PCR)
ATM constant bit rate (CBR)
1. For Frame Relay networks with link fragmentation and interleaving (LFI) enabled.
Bandwidth Allocation to PVCs

The router allocates bandwidth to variable bit rate (VBR), constant bit rate (CBR), and shaped (specifies
the peak cell rate) unspecified bit rate (UBR) PVCs before allocating bandwidth to unshaped UBR
PVCs. As a result, a diminished amount of bandwidth is available to allocate to unshaped UBR PVCs.
To override this behavior, create a hierarchical (nested) policy with the bandwidth specified and attach
the policy to the ATM port or physical interface.

OL-7433-09
5-5
Chapter 5
Class-Default Bandwidth Guarantee

The Cisco 10000 series router guarantees bandwidth for the class-default class in the following way:
Note
For all releases prior to Cisco IOS Release 12.0(19)SL, when other classes are present, the
class-default class receives no bandwidth guarantee unless it has a bandwidth command configured.
Cisco IOS Release 12.0(19)SL adds support for an implicit bandwidth guarantee. In
Release 12.0(19)SL and later releases, the class-default class receives a bandwidth guarantee of any
uncommitted interface bandwidth plus one percent. You can decrease this guarantee by using the
bandwidth command in the class-default class.
You can decrease the class-default bandwidth guarantee, but you cannot increase it.
Configuring the bandwidth-remaining percent command for the class-default class can lead to
unexpected behavior such as a drop in link throughput or unfair bandwidth sharing between queues. This
occurs because the router allocates 1 percent of the interface bandwidth to the default class, regardless
of the value you specify in the bandwidth-remaining percent command. The router does this so that
the class-default queue has at least a minimum amount of the committed rate to guarantee bandwidth to
any control traffic flowing over the default class. This behavior is unique to the class-default class only
and the PRE2. To workaround this problem, you can:
Configure the bandwidth percent or bandwidth rate command in the policy map instead of the
bandwidth-remaining percent command.
Limit the traffic that flows over the class-default queue by configuring another class queue with the
bandwidth-remaining percent command specified and ensuring that the traffic that would have
flowed over the class-default queue now flows over the newly created queue, leaving the
class-default queue for control traffic.
Committed Rate Data

The committed rate includes the framing overhead, excluding bit and byte stuffing. For ATM, the
committed rate also includes the cell overhead. This causes the actual packet data rate to be lower than
what you specify in the bandwidth command. Therefore, be sure to allow for the framing and cell
overhead when you specify a minimum bandwidth for a class.
For example, if you need to commit a rate of 1000 64-byte packets per second and each have four bytes
of framing overhead, instead of specifying 512 kbps in the bandwidth command, you would specify
544 kbps, which is calculated in the following way:
1000 * (64+4) * 8 / 1000 = 544
A similar setup on ATM would require 848 kbps because each 64-byte packet requires two cells of
53 bytes:
1000 * 2 * 53 * 8 / 1000 = 848
5-6
OL-7433-09
Chapter 5

Bandwidth and Priority Service

To configure priority queuing, use the priority command in policy-map class configuration mode and
configure the bandwidth in the following way:
In releases prior to Cisco IOS Release 12.3(7)XI, specify a minimum bandwidth rate using the
priority command.
In Cisco IOS Release 12.3(7)XI and later releases, specify a minimum bandwidth rate using the
police command. The router no longer supports the percent and bandwidth-kbps options for the
priority command.
When you create a priority queue using the priority command, the router sets the committed information
rate (CIR) of the queue to near link bandwidth. Therefore, the priority queue can consume almost all of
the link bandwidth when packets are transmitted from it. As a result, there is no way to guarantee
bandwidth to the other queues on the link. To resolve this, configure the other queues using the
bandwidth remaining command. This command enables the router to allocate relative amounts of
bandwidth, eliminating the need to constantly change the class bandwidth.
Table 5-4 lists the functional differences between the bandwidth and priority commands:
Table 5-4
Comparison of Functional Differences Between the bandwidth and priority

Commands
Function
bandwidth Command
priority Command
Minimum bandwidth guarantee
Yes
Yes
Maximum bandwidth guarantee
No
Yes
Built-in policer
No
No
Provides low-latency
No
Yes
The bandwidth and priority commands are also designed to meet different QoS policy objectives.
Table 5-5 lists those differing objectives:
Table 5-5
Comparison of QoS Policy Objectives of the bandwidth and priority Commands
Application
bandwidth Command
priority Command
Bandwidth management for WAN links
Yes
Somewhat
Manage delay and variations in delay (jitter)
No
Yes
Improve application response time
No
Yes

OL-7433-09
5-7
Chapter 5
Queuing Modes
The Cisco 10000 series router supports the following queuing modes:
atm pxf queuing Mode, page 5-8
no atm pxf queuing Mode, page 5-9
atm pxf queuing Mode

The atm pxf queuing mode supports low VC counts. Before you configure VCs on an interface, configure
the queuing mode for the port (atm pxf queuing or no atm pxf queuing). After you configure the mode,
then configure the VCs. Do not change the mode while VCs are configured on the interface. If you need
to change the mode, delete the VCs first and then change the mode. Changing the mode while VCs are
configured can produce undesired results.
To support a low VC count, configure the atm pxf queuing command on each port of the Cisco 10000
series router. For Cisco IOS Release 12.3(7)XI2 and later releases, all line cards support a maximum of
28,672 VCs when configured for hierarchical shaping.
Note
For releases prior to Cisco IOS Release 12.3(7)XI2, the OC-3 and OC-12 line cards support a maximum
of 14,336 VCs when configured for hierarchical shaping. The DS3/E3 line card supports a maximum of
8,192 VCs when configured for shaping. You can configure the maximum number of VCs across the
ports in any fashion, provided that you do not exceed the per-port maximum. The OC-3 line card is
limited to 8,192 VCs per port and the DS3 is limited to 4,096 VCs per port.
The Cisco 10000 series router supports the following ATM traffic classes when you configure the atm
pxf queuing command:
Shaped and unshaped unspecified bit rate (UBR)

To configure shaped UBR, enter the ubr command and specify the PCR value. For unshaped UBR,
do not specify the PCR value.
Variable bit rate-nonreal time (VBR-nrt)

To configure VBR-nrt QoS, use the vbr-nrt command and specify the output PCR, output
sustainable cell rate (SCR), and output maximum burst cell size (MBS).
Constant bit rate (CBR)

To configure CBR QoS, use the cbr command and specify the average cell rate for the ATM circuit
emulation service (CES) for an ATM permanent virtual circuit (PVC).
Note
If you use the ubr+ command to configure shaped UBR, the router accepts the PCR value you specify,
but it does not use it. The router does not notify you of this behavior.
5-8
OL-7433-09
Chapter 5

no atm pxf queuing Mode
Note
Cisco recommends that you do not configure no atm pxf queuing mode for QoS-sensitive deployments.
The no atm pxf queuing mode supports high VC counts. Before you configure VCs on an interface,
configure the queuing mode for the port (atm pxf queuing or no atm pxf queuing). After you configure
the mode, then configure the VCs. Do not change the mode while VCs are configured on the interface.
If you need to change the mode, delete the VCs first and then change the mode. Changing the mode while
VCs are configured can produce undesired results.
To support a high number of virtual circuits (VCs), configure the no atm pxf queuing command on each
port of the Cisco 10000 series router. PPPoA supports one session per VC and requires that you enable
no atm pxf queuing mode to support up to 64,000 PPPoA sessions. Enabling no atm pxf queuing mode
is not required for L2TP and might not be required for PPPoE because you can have 64,000 sessions on
a single VC.
The Cisco 10000 series router supports the following ATM traffic classes when you configure the no atm
pxf queuing command:
Shaped and unshaped unspecified bit rate (UBR)

To configure shaped UBR, enter the ubr command and specify the PCR value. For unshaped UBR,
enter the ubr command without specifying the PCR value.
Variable bit rate-nonreal time (VBR-nrt)

To configure VBR-nrt QoS, use the vbr-nrt command and specify the output PCR, output
sustainable cell rate (SCR), and the output maximum burst cell size (MBS) for a VC class.
Note
If you use the ubr+ command to configure shaped UBR, the router accepts the PCR value you specify,
but it does not use it. The router does not notify you of this behavior.
Restrictions and Limitations for Bandwidth Distribution
You cannot configure the bandwidth command on a class with priority service configured.
In a policy map, you can configure the bandwidth, priority, or shape command for a maximum of
14 (PRE1) or 30 (PRE2) non-class-default classes.
The router supports a maximum of 32,767 (PRE1) or 128,000 (PRE2) output packet queues.
A policy map can have only one priority queue.

OL-7433-09
5-9
Chapter 5
Configuring Bandwidth Distribution Between Queues

To configure or modify the amount of bandwidth allocated for a traffic class, enter the following
Step 1
Command
Purpose
Specifies the name of the policy map and enters policy-map

configuration mode.
Step 2
Assigns the traffic class you specify to the policy map. Enters
policy-map class configuration mode.
class-map-name is the name of a previously configured class
map and is the traffic class for which you want to define QoS
actions.
Step 3
Router(config-pmap-c)# bandwidth
{bandwidth-kbps | percent percentage |
remaining percent percentage}
Specifies or modifies the minimum bandwidth allocated for a

traffic class in a policy map.
bandwidth-kbps specifies or modifies the minimum
bandwidth allocated for a class belonging to a policy map.
Valid values are from 8 to 2,488,320, which represents from
1 to 99 percent of the link bandwidth.
Note
The range of valid values for bandwidth-kbps might

be smaller than the values indicated above. Use the
question mark (?) in context-sensitive help to display
the range of valid values.
percent percentage specifies or modifies the minimum

percentage of the link bandwidth allocated for a class
belonging to a policy map. Valid values are from 1 to 99.
remaining percent percentage specifies or modifies the
minimum percentage of unused link bandwidth allocated for
a class belonging to a policy map. Valid values are from 1 to
99.
Note
Configure the amount of bandwidth large enough to

also accommodate Layer 2 overhead.
For information about classifying traffic and creating QoS service policies, see Chapter 2, Classifying
Traffic and Chapter 3, Configuring QoS Policy Actions and Rules.
Configuration Examples for Configuring Bandwidth Distribution

This section provides the following configuration examples:
Configuration Example for Kilobits per Second-Based Bandwidth, page 5-11
Configuration Example for Percentage-Based Bandwidth, page 5-11
Configuration Example for Bandwidth-Remaining-Based Bandwidth, page 5-11
5-10
OL-7433-09
Chapter 5

Configuration Example for Kilobits per Second-Based Bandwidth

Example 5-2 shows how to create a policy-map named account1 and configure a class named gold,
which provides a guaranteed minimum bandwidth of 700 kbps for all gold class traffic. The maximum
queue depth for gold traffic is 64 packets. If the queue depth is reached, the router tail-drops excess
traffic.
Example 5-2
Configuring Bandwidth Based on Kilobits per Second
Router(config)# policy-map account1

Router(config-pmap)# class gold
Router(config-pmap-c)# queue-limit 64
Configuration Example for Percentage-Based Bandwidth

Example 5-3 shows how to create a policy map named mypolicy and configure a class named silver,
which allocates a minimum of 30 percent of the link bandwidth to all silver class traffic. The maximum
queue depth for silver traffic is 64 packets. The random-detect command ensures that excess traffic is
randomly discarded using a precedence-based algorithm.
Example 5-3
Configuring a Percentage-Based Bandwidth

Router(config-pmap)# class silver
Router(config-pmap-c)# random-detect precedence-based
Configuration Example for Bandwidth-Remaining-Based Bandwidth

Example 5-4 shows how to create a policy map named vlan and configure two traffic classes named
priority and premium. The priority class contains both the priority and police commands. The premium
class allocates a minimum of 25 percent of the unused bandwidth to this class.
Example 5-4
Configuring Bandwidth-Remaining-Based Bandwidth
Router(config)# policy-map vlan

Router(config-pmap)# class priority
Router(config-pmap-c)# police percent 50
Router(config-pmap)# class premium
Router(config-pmap-c) bandwidth remaining percent 25

OL-7433-09
5-11
Chapter 5
Verifying and Monitoring Bandwidth Distribution

The Cisco 10000 series router collects statistical information about the current queue length, and the
number of packets and bytes transmitted and dropped (64 bits), which you can display using the show
commands in this section.
To verify and monitor bandwidth distribution in a policy map, enter the following commands in
privileged EXEC mode:
Command
Purpose

Router# show policy-map interface interface

[input | output]
Displays the configuration of all classes configured for all inbound

or outbound policy maps attached to the specified interface.
interface is the name of the interface or subinterface whose policy
configuration you want to display.
policy.
output indicates to display the statistics for the attached outbound
policy.
Note
Router# show policy-map policy-map-name

inbound and outbound policies attached to the interface
you specified.

map you specify.
policy-map-name is the name of the policy map whose
configuration information you want to display. The name can be a
maximum of 40 characters.

class-name

5-12
OL-7433-09
Chapter 5

Verification Example for Bandwidth Distribution

Example 5-5 shows the bandwidth configuration for the class named Business and the class named
Non-Business in the Gold policy map.
Example 5-5
Verifying Class Bandwidth
Router# show policy-map

Policy Map Gold
Class Business
bandwidth 5000
Class Non-Business
bandwidth 2000
Example 5-6 shows the bandwidth that the router allocated to the traffic classes in the Gold policy map.
Example 5-6
Verifying Bandwidth Distribution
Router# show policy-map interface atm 3/0/0

ATM3/0/0
Service-policy output: Gold
Class-map: Business (match-all)
0 packets, 0 bytes
Class-map: Non-Business (match-all)
0 packets, 0 bytes
Match: ip precedence 3 5
Match: any

OL-7433-09
5-13
Chapter 5

The Distribution of Remaining Bandwidth Using Ratio feature allows service providers to prioritize
subscriber traffic during periods of congestion. A bandwidth-remaining ratio is used to influence how
the router allocates excess bandwidth (unused by priority traffic) to a class of non-priority traffic. Instead
of using only bandwidth rate, the router considers configured minimum bandwidth rates, maximum
bandwidth rates, and bandwidth-remaining ratios when determining excess bandwidth allocation. A
bandwidth-remaining ratio adds more flexibility in prioritizing traffic and enables you to influence
excess bandwidth allocation by basing the bandwidth-remaining ratio on factors other than speed.
When bandwidth-remaining ratios are not specified, the hierarchical queuing framework (HQF)
scheduler on the PRE3 does the following:
Computes a default bandwidth-remaining ratio based on the subinterface speedATM interfaces
Uses the minimum bandwidth-remaining ratio allowed (currently 1 on the PRE3)Other interfaces
such as VLANs and Frame Relay DLCIs
With bandwidth-remaining ratios, service providers have more flexibility in assigning priority to
subinterfaces and queues during congestion. In addition to speed, you can base the bandwidth-remaining
ratio on alternative factors, such as a service product or subscription rate. In this way, for example, you
can give higher weight to subinterfaces carrying business services and lower weight to subinterfaces
carrying residential services. The bandwidth-remaining ratio enables the HQF scheduler to service a
subinterface with a low SCR but a high bandwidth-remaining ratio more frequently than servicing a
subinterface with a high SCR but a low bandwidth-remaining ratio.
The Distribution of Remaining Bandwidth Using Ratio feature is available on outbound interfaces only.
Feature History for Bandwidth-Remaining Ratios

Cisco IOS Release
Modification
Release 12.2(31)SB22
This feature was introduced and implemented on the Cisco 10000 series
router for the PRE3.
Bandwidth-Remaining Ratio
A bandwidth-remaining ratio is a value from 1 to 1000 that is used to determine the amount of unused
(excess) bandwidth to allocate to a class queue or subinterface-level queue during congestion. The router
allocates excess bandwidth relative to the other class queues and subinterface-level queues configured
on the physical interface. The bandwidth-remaining ratio value does not indicate a percentage. For
example, a subinterface with a bandwidth-remaining ratio of 100 receives 10 times the unused (excess)
bandwidth during congestion than a subinterface with a bandwidth-remaining ratio of 10.
Without bandwidth-remaining ratios, the router allocates excess bandwidth based on the following:
Speed of the subinterface (for example, the configured SCR)ATM subinterfaces
Minimum bandwidth-remaining ratio allowed (currently 1 on the PRE3)Interface types such as

VLANs and Frame Relay DLCIs
With bandwidth-remaining ratios, excess bandwidth allocation can be based on factors other than the
bandwidth rate (for example, service product or subscription rate).
5-14
OL-7433-09
Chapter 5

Prerequisites for Distribution of Remaining Bandwidth Using Ratio

You must configure traffic classes using the class-map command.
Restrictions for Distribution of Remaining Bandwidth Using Ratio
Bandwidth-remaining ratios are only available on outbound interfaces.
The bandwidth remaining ratio command cannot coexist with another bandwidth command in
different traffic classes of the same policy map. For example, the following configuration is not valid
and causes an error message to display:
policy-map Prec1
class precedence_0
bandwidth remaining ratio 10
class precedence_2
bandwidth 1000
The bandwidth remaining ratio command cannot coexist with another bandwidth command in the
same class. For example, the following configuration is not valid and causes an error message to
display:
policy-map Prec1
class precedence_0
bandwidth 1000
In a hierarchical policy map in which the parent policy has only the class-default class defined with
a child queuing policy applied, the router accepts only the bandwidth remaining ratio form of the
bandwidth command in the class-default class of the parent policy.
The bandwidth remaining ratio command cannot coexist with the priority command in the same
class. For example, the following configuration is not valid and causes an error message to display:
policy-map Prec1
class precedence_1
priority percent 10
Configuring Bandwidth-Remaining Ratios

You can apply bandwidth-remaining ratios to different subinterfaces and to different traffic queues
within a single outbound interface or subinterface.
Use the following procedures to configure bandwidth-remaining ratios:
Configuring and Applying Bandwidth-Remaining Ratios to Subinterfaces, page 5-16
Configuring and Applying Bandwidth-Remaining Ratios to Class Queues, page 5-18

OL-7433-09
5-15
Chapter 5
Configuring and Applying Bandwidth-Remaining Ratios to Subinterfaces

To configure and apply bandwidth-remaining ratios to subinterfaces, enter the following commands
Note
Step 1
You can apply bandwidth-remaining ratios to outbound subinterfaces only.
Command or Action
Purpose
policy-map child-policy-name
Creates or modifies a child policy map. Enters policy-map

configuration mode.
child-policy-name is the name of the child policy map.
Step 2
class class-map-name
Configures the class map that you specify. Enters

class-map-name is the name of a previously created class
map.
Step 3
bandwidth bandwidth-kbps
Specifies the bandwidth, in kbps, to be allocated to this

traffic class.
bandwidth-kbps is the bandwidth in kilobits per second
(kbps).
Step 4
exit
Exits policy-map class configuration mode.
Step 5
exit
Exits policy-map configuration mode.
Step 6
policy-map parent-policy-name
Creates or modifies a parent policy map. Enters policy-map

configuration mode.
parent-policy-name is the name of the parent policy map.
Step 7
class class-default
Configures the class-default class. Enters policy-map class

configuration mode.
Note
Step 8
bandwidth remaining ratio ratio
The router interprets any features configured under

the class-default class as aggregate features on the
subinterface.
Specifies the bandwidth-remaining ratio for the

subinterface.
ratio is the value used to determine the amount of unused
bandwidth to allocate to each queue on the subinterface
during periods of congestion. The scheduler allocates the
excess bandwidth relative to other subinterfaces. Valid
values are 1 to 1000. The default value is
platform-dependent.
The router distinguishes between interface types at the
subinterface level when using default bandwidth-remaining
ratios. On the Cisco 10000 series router the default ratio
value is 1 for VLAN subinterfaces and Frame Relay DLCIs.
For ATM subinterfaces, the router computes the default
based on the subinterface speed.
5-16
OL-7433-09
Chapter 5

Step 9
Command or Action
Purpose
shape {average | peak} cir [bc] [be]
(Optional) Shapes the average or peak rate to the rate you

specify.
average specifies average rate shaping.
peak specifies peak rate shaping.
cir specifies the committed information rate (CIR), in bits
per second (bps).
(Optional) bc specifies the committed burst size, in bits.
(Optional) be specifies the excess burst size, in bits.
Step 10
service-policy child-policy-name
Applies the child policy map you specify to the traffic class.
The router applies the QoS actions specified in the child
policy to the traffic class.
child-policy-name is the name of the child policy.
Note
The service-policy command typically requires that

you specify the direction of the traffic using the
input or output keywords. However, when
applying a child policy to a parent policy, do not
specify traffic direction.
Step 11
exit
Step 12
exit
Step 13
interface type slot/module/port.subinterface

[point-to-point | multipoint]
Creates or modifies the interface you specify. Enters

type is the interface type (for example, Gigabit Ethernet).
slot/module/port.subinterface is the number of the
subinterface that identifies the subinterface (for example,
1/0/0.1).
(Optional) point-to-point indicates that the subinterface is
a point-to-point subinterface.
(Optional) multipoint indicates that the subinterface is a
point-to-multipoint subinterface.

OL-7433-09
5-17
Chapter 5
Step 14
Command or Action
Purpose
service-policy {input | output}

parent-policy-name
Applies the parent policy to the subinterface.

input indicates to apply the service policy to inbound
traffic.
output indicates to apply the service policy to outbound
traffic.
The router shapes the subinterface traffic to the shaping rate
specified in the parent class-default class and applies the
QoS actions specified in the child policy to traffic matching
the traffic classes.
During periods of congestion, the router uses the
bandwidth-remaining ratio specified in the parent policy
map to allocate unused bandwidth on this subinterface
relative to other subinterfaces.
Configuring and Applying Bandwidth-Remaining Ratios to Class Queues

To configure and apply bandwidth-remaining ratios to class queues, enter the following commands
Step 1
Command or Action
Purpose
policy-map child-policy-name

configuration mode.
Step 2
class class-map-name

map.
Step 3

specify.
per second (bps).
5-18
OL-7433-09
Chapter 5

Step 4
Command or Action
Purpose
(Optional) Specifies the bandwidth-remaining ratio for the

traffic class.
platform-dependent.
The router makes no distinction between interface types at
the class level when using the default bandwidth-remaining
ratio. On the Cisco 10000 series router the default
bandwidth-remaining ratio value is 1.
Step 5
exit
Step 6
exit
Step 7
policy-map parent-policy-name

configuration mode.
Step 8
class class-default

configuration mode.
Note
Step 9

subinterface.
Shapes the average or peak rate to the rate you specify.

per second (bps).
Step 10

subinterface.
platform-dependent.

OL-7433-09
5-19
Chapter 5
Step 11
Command or Action
Purpose
service-policy child-policy-name
Note

Step 12
exit
Step 13
exit
Step 14
interface type slot/module/port.subinterface


1/0/0.1).
Step 15
service-policy {input | output}

parent-policy-name

traffic.
traffic.
Note
When congestion occurs, the class queues receive

bandwidth according to the specified class-level
bandwidth-remaining ratios.
Configuration Examples for Distribution of Remaining Bandwidth Using Ratio

Configuring Bandwidth-Remaining Ratios on Ethernet Subinterfaces: Example, page 5-21
Configuring Bandwidth-Remaining Ratios on ATM Subinterfaces: Example, page 5-21
Configuring Bandwidth-Remaining Ratios on Class Queues: Example, page 5-22
Verifying Bandwidth Remaining Ratios: Example, page 5-22
5-20
OL-7433-09
Chapter 5

Configuring Bandwidth-Remaining Ratios on Ethernet Subinterfaces: Example

The following example shows how to configure bandwidth-remaining ratios on an Ethernet subinterface
using a hierarchical policy. In the example, Gigabit Ethernet subinterface 1/0/0.1 is shaped to 100 Mbps.
During congestion, the router uses the bandwidth-remaining ratio of 10 to determine the amount of
excess bandwidth (unused by priority traffic) to allocate to the non-priority traffic on
subinterface 1/0/0.1, relative to the other subinterface-level and class-level queues on the interface.
policy-map Child
class precedence_0
bandwidth 10000
class precedence_1
shape average 100000
bandwidth 100
!
policy-map Parent
class class-default
service-policy Child
!
encapsulation dot1Q 100
ip address 10.1.0.1 255.255.255.0
service-policy output Parent
Configuring Bandwidth-Remaining Ratios on ATM Subinterfaces: Example

The following example shows how to differentiate one ATM PVC from another during congestion by
using bandwidth-remaining ratios. In the example, during periods of congestion in which the traffic on
all PVCs on the interface exceeds the interface speed, the router uses the configured
bandwidth-remaining ratio of 10 to determine the amount of excess (unused by priority traffic)
bandwidth to allocate to non-priority traffic on PVC 0/200, relative to the other ATM PVCs configured
on the interface.
policy-map Child
class precedence_0
bandwidth 100
class precedence_1
bandwidth 10000
!
policy-map Parent
class class-default
!
interface ATM2/0/3.200 point-to-point
ip address 10.20.1.1 255.255.255.0
pvc 0/200
protocol ip 10.20.1.2
vbr-nrt 50000
encapsulation aal5snap
Note
If PVC 98/204 is configured on the same interface as PVC 0/200 and with a bandwidth-remaining ratio
of 1, during times of congestion PVC 0/200 would have 10 times more bandwidth available to it for
non-priority traffic than PVC 98/204 would have.

OL-7433-09
5-21
Chapter 5
Configuring Bandwidth-Remaining Ratios on Class Queues: Example

In the following sample configuration, the vlan10_policy is applied on the subinterface Gigabit
Ethernet 1/0/0.10 and the vlan20_policy is applied on the subinterface Gigabit Ethernet 1/0/0.20. During
congestion on the interface, subinterface GE 1/0/0.20 has 10 times more available bandwidth than
subinterface GE1/0/0.10 because the bandwidth-remaining ratio for subinterface GE 1/0/0.20 is 10 times
more than the bandwidth-remaining ratio for subinterface 1/0/0.10: 100 on subinterface 1/0/0.20 and 10
on subinterface 1/0/0.10.
When congestion occurs within a subinterface level, the class queues receive bandwidth according to the
class-level bandwidth-remaining ratios. In the example, the bandwidth for classes precedence_0,
precedence_1, and precedence_2 is allocated based on the bandwidth-remaining ratios of the classes: 20,
40, and 60, respectively.
policy-map child-policy
class precedence_0
bandwidth remaining ratio 20 <---- Class-level ratio
class precedence_1
class precedence_2
!
policy-map vlan10_policy
class class-default
bandwidth remaining ratio 10 <---- Subinterface-level ratio
service-policy child-policy
!
class class-default
service-policy child_policy
!
!
interface GigabitEthernet 1/0/0.10
service-policy output vlan10_policy
!
Verifying Bandwidth Remaining Ratios: Example

The following sample output from the show policy-map interface command indicates that
bandwidth-remaining ratios are configured on class-level queues in the policy maps named
vlan10_policy and child_policy, which are attached to the Gigabit Ethernet subinterface 1/0/0.10.
Router# show policy-map interface GigabitEthernet1/0/0.10
Service-policy output: vlan10_policy
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
0 packets, 0 bytes
5-22
OL-7433-09
Chapter 5

30 second rate 0 bps

Queueing
queue limit 250 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
shape (average) cir 1000000, bc 4000, be 4000
target shape rate 1000000
Service-policy : child_policy
Class-map: precedence_0 (match-all)
0 packets, 0 bytes
Queueing
0 packets, 0 bytes
Queueing
0 packets, 0 bytes
Queueing
0 packets, 0 bytes
Match: any
0 packets, 0 bytes

OL-7433-09
5-23
Chapter 5
The following sample output from the show policy-map interface command indicates that
bandwidth-remaining ratios are configured on class-level queues in the policy maps named
vlan20_policy and child_policy, which are attached to the Gigabit Ethernet subinterface 1/0/0.20.
Service-policy output: vlan20_policy
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
Queueing
Service-policy : child_policy
0 packets, 0 bytes
Queueing
0 packets, 0 bytes
Queueing
0 packets, 0 bytes
Queueing
0 packets, 0 bytes
Match: any
5-24
OL-7433-09
Chapter 5

0 packets, 0 bytes
The following sample output from the show policy-map command indicates that a bandwidth-remaining
ratio of 10 is configured on the parent class-default class of the policy map named vlan10_policy.
Router# show policy-map vlan10_policy
Policy Map vlan10_policy
Class class-default
Average Rate Traffic Shaping
cir 1000000 (bps)
ratio of 100 is configured on the parent class-default class of the policy map named vlan20_policy.
During congestion, the scheduler allocates the subinterface Gigabit Ethernet 1/0/0.20 10 times the
bandwidth that it allocates subinterface Gigabit Ethernet 1/0/0.10.
Router# show policy-map vlan20_policy
Policy Map vlan20_policy
Class class-default
cir 1000000 (bps)
ratio of 20, 40, and 60 is configured on the class queues precedence_0, precedence_1, and precedence_2,
respectively.
Router# show policy-map child_policy
Policy Map child_policy
Class precedence_0
cir 500000 (bps)
Class precedence_1
cir 500000 (bps)
Class precedence_2
cir 500000 (bps)

OL-7433-09
5-25
Chapter 5
Feature
bandwidth command
Cisco IOS Quality of Service Solutions Command Reference, Release 12.3 T

Quality of Service Commands: A through F > bandwidth (policy-map class)
Comparing the bandwidth and priority Commands of a QoS Service Policy
bandwidth remaining ratio
Distribution of Remaining Bandwidth Using Ratio, Release 12.2(31)SB2 feature

module
Class maps

Hierarchical queuing framework

Policing
Comparing Traffic Shaping and Traffic Policing for Bandwidth Limiting
Policy maps

QoS Configuration and Monitoring, Creating Time-of-Day QoS Service Policies

tech note
QoS Configuration and Monitoring, Monitoring Voice over IP Quality of Service
tech note
Site-to-Site MPLS VPN Solution for Service Providers, Service Provider
Quality-of-Service Overview tech note
Shaping
Three-level scheduler

5-26
OL-7433-09
CH A P T E R
Policing Traffic
It is critical that network resources are available to customers. When network resources are overloaded
due to inadequate traffic management, you lose the benefits that a network provides. Controlling the flow
of data across your network helps to ensure the efficiency of the network.
Policing is an important traffic regulation mechanism. Using policing, you can configure your system to
more effectively handle traffic issues before they overload your network. Policing enables you to
determine how traffic is managed by the network to avoid congestion and system inefficiencies, thereby
increasing network availability and maximizing the use of bandwidth.
This chapter describes the policing capabilities of the Cisco 10000 series router. It includes the following
topics:
Traffic Policing, page 6-2
Single-Rate Color Marker for Traffic Policing, page 6-4
Two-Rate Three-Color Marker for Traffic Policing, page 6-8
Percent-Based Policing, page 6-11
Control Plane Policing, page 6-13
AToM Set ATM CLP Bit Using a Policer, page 6-13
Policing Support for GRE Tunnels, page 6-17
Interfaces Supporting Policing, page 6-17
Metering Traffic and Token Buckets, page 6-18
Committed Bursts and Excess Bursts, page 6-21
Data Included in the Policing Rate, page 6-23
Policing Rate Granularity, page 6-25
Avoiding Bandwidth Starvation Due to Priority Services, page 6-25
Avoiding Bandwidth Starvation Due to Priority Services, page 6-25
Configuring Traffic Policing, page 6-27
Verifying and Monitoring Traffic Policing, page 6-41

OL-7433-09
6-1
Chapter 6
Policing Traffic
Traffic Policing
Traffic Policing
Traffic policing is a traffic regulation mechanism that is used to limit the rate of traffic streams. Policing
allows you to control the maximum rate of traffic sent or received on an interface. Policing propagates
bursts of traffic and is applied to the inbound or outbound traffic on an interface. When the traffic rate
exceeds the configured maximum rate, policing drops or remarks the excess traffic. Although policing
does not buffer excess traffic, a configured queuing mechanism applies to conforming packets that might
need to be queued while waiting to be serialized at the physical interface.
Traffic policing uses a token bucket algorithm to manage the maximum rate of traffic. This algorithm is
used to define the maximum rate of traffic allowed on an interface at a given moment in time. The token
bucket algorithm is especially useful in managing network bandwidth in cases where several large
packets are sent in the same traffic stream. The algorithm puts tokens into the bucket at a certain rate.
Each token is permission for the source to send a specific number of bits into the network. With policing,
the token bucket determines whether a packet exceeds or conforms to the applied rate. In either case,
policing implements the action you configure such as setting the IP precedence or differentiated services
code point (DSCP). For more information about the token bucket, see the Metering Traffic and Token
Buckets section on page 6-18.
Policing restricts the output rate to a maximum kilobits per second (kbps) value or to a percentage of the
available or unused bandwidth. Policing does not provide a minimum bandwidth guarantee during
periods of congestion; to provide these guarantees, you must use the bandwidth or priority command.
Policing is class-based in that the policer is applied to a specific class of traffic within a policy map by
using the police command. When you attach the service policy to an interface, the router applies the
policing action to the packets that match that class.
Feature History for Traffic Policing

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The traffic policing feature was introduced on the router

and included a single-rate two-color policer.
PRE1
Release 12.0(25)S
This feature was enhanced to include a three-color marker. PRE1
Release 12.2(16)BX
PRE2
Release 12.3(7)XI
This feature was enhanced on the PRE2 to include a

three-color marker.
PRE2
Release 12.2(27)SBB
This feature was enhanced on the PRE2 to include a

two-rate policer.
PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3 to allow you to PRE3

police traffic on the L2TP access concentrator (LAC)
based on the value of a packets IP DSCP bits. Control
plane policing, policing of GRE tunnels, tunnel header
marking using a police action, and ATM CLP bit marking
using a police action were also introduced on the PRE3.
Release 12.2(33)SB
This feature was introduced on the PRE4 and enhanced to PRE2, PRE3,
support marking of the ATM CLP bit, Frame Relay DE bit, PRE4
and CoS bit using a police action for the PRE2, PRE3, and
PRE4.
6-2
OL-7433-09
Chapter 6
Policing Traffic
Traffic Policing
Policing Actions
Table 6-1 lists the actions the router can take on packets. These are the actions you specify in the police
command.
Note
Table 6-1
In Table 6-1, the term transmit means that the packet is passed through the policer for further processing.
The policer acts as a filter before the packet is passed on to the next event to happen.
Policing Actions
Action
Description
drop
Drops the packet.
Release 12.0(17)SL
This is the default action for traffic that exceeds or PRE1

violates the committed rate.
set-clp-transmit value
Sets the ATM cell loss priority (CLP) bit of the

ATM cell. Valid values are 0 or 1.
Release 12.3(7)XI
PRE2
Release 12.2(33)SB
PRE2, PRE3, PRE4
set-cos-transmit value
Sets the class of service (CoS) bits of a packet and Release 12.2(33)SB
transmits the packet with the new CoS setting.
PRE2, PRE3, PRE4
Valid values are 0 to 7.
set-cos-inner-transmit value
Sets the inner VLAN CoS bits and transmits the

Release 12.2(33)SB
packet with the new CoS setting. Valid values are 0
PRE2, PRE3, PRE4
to 7.
Note
set-dscp-tunnel-transmit value
set-dscp-transmit value
The router supports this policing action on

QinQ interfaces only. We recommend that
you do not configure this action in 3-level
hierarchical policy maps attached to
non-QinQ interfaces.
Sets the discard class attribute of a packet and

transmits the packet with the new discard class
setting.
Release 12.3(7)XI
PRE2
Sets the DSCP bits in the packet headers of traffic Release 12.2(31)SB2
streams aggregated into the same tunnel. This
PRE3
enables the streams to receive a different level of
QoS processing at the outer ToS fields QoS
domain. Valid values are from 0 to 63 or one of the
following reserved keywords:
EF (expedited forwarding)
AF11 (assured forwarding class AF11)
Sets the IP differentiated services code point

Release 12.0(17)SL
(DSCP) value and transmits the packet with the new
PRE1
IP DSCP value setting. Valid values are from 0 to
63.

OL-7433-09
6-3
Chapter 6
Policing Traffic
Single-Rate Color Marker for Traffic Policing
Table 6-1
Policing Actions (continued)
Action
Description
set-frde-transmit
Sets the Frame Relay discard eligibility (DE) bit

and transmits the frame with the new DE setting.
Release 12.2(33)SB
Sets the Multiprotocol Label Switching (MPLS)

experimental (EXP) bits and transmits the packet
Release 12.0(22)S
Sets the MPLS experimental (EXP) bits in the

imposed label headers and transmits the packet
Release 12.3(7)XI
set-mpls-exp-transmit value
value
PRE2, PRE3, PRE4

PRE1
PRE2
The set-mpls-exp-imposition-transmit command

is available only on the PRE2 and replaces the
set-mpls-exp-transmit command.
set-prec-tunnel-transmit value
Sets the precedence bit in the packet headers of

Release 12.2(31)SB2
traffic streams aggregated into the same tunnel.
PRE3
This enables the streams to receive a different level
of QoS processing at the outer ToS fields QoS
domain. Valid values are from 0 to 7.
set-prec-transmit value
Sets the IP precedence and transmits the packet

with the new IP precedence value setting. Valid
Release 12.0(17)SL
PRE1
set-qos-transmit value
Sets the QoS group value and transmits the packet Release 12.0(17) SL
with the new QoS group value setting. Valid values
PRE1
are from 0 to 99.
transmit
Transmits the packet. The packet is not altered.
Release 12.0(17)SL
PRE1

The Cisco 10000 series router supports a single-rate color marker to police traffic streams into groups
of conforming and nonconforming traffic. This marker is useful in marking packets in a packet stream
with different, decreasing levels of assurances (either absolute or relative). The marker can mark packets
with green, yellow, or red markings, which cause a specific action to occur. For example, a service might
discard all red packets because they exceed both the committed and excess burst sizes, forward yellow
packets as best effort, and forward green packets with a low drop probability.
The router provides two types of single-rate color markers: two-color and three-color.
In all releases prior to Cisco IOS Release 12.0(25)S and Release 12.3(7)XI, the router provides a
two-color marker. A two-color marker classifies traffic into two groups: traffic that conforms to the
specified committed information rate (CIR) and burst sizes, and traffic that exceeds either the CIR
or the burst sizes.
6-4
OL-7433-09
Chapter 6
Policing Traffic
In Cisco IOS Release 12.0(25)S and Release 12.3(7)XI, and later releases, the router adds support
for an IETF-defined, RFC 2697-based, single rate, three-color marker by adding the ability to
classify nonconforming traffic into a third group: traffic that violates the CIR. The three-color
marker distinguishes between the nonconforming traffic that occasionally bursts a certain number
of bytes more than the CIR and the traffic that continually violates the CIR allowance. Applications
can utilize the three-color marker to provide three service levels: guaranteed, best effort, and deny.
The router maintains the behavior of the two-color marker by automatically setting the violate action
to be the same as the exceed action (unless you configure the violate action). Therefore, you can
continue to use the two-color marker. However, it is important to note that the router collects
statistics for conforming, exceeding, and violating packets. Therefore, when verifying packet counts
be sure to observe all three statistical categories to ensure an accurate count.
Feature History for the Single-Rate Color Marker

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The single-rate two-color marker feature was introduced on PRE1

the router.
Release 12.0(25)S
This feature was enhanced to include a single-rate

three-color marker.
PRE1
Release 12.2(16)BX
This feature was introduced on the PRE2 and included a

single-rate two-color marker.
PRE2
Release 12.3(7)XI
This feature was enhanced on the PRE2 and included a

single-rate three-color marker.
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3 to allow you to

PRE3
police traffic on the L2TP access concentrator (LAC) based
on the value of a packets IP DSCP bits.
Configuration Commands for the Single-Rate Color Marker

The commands used to configure the single-rate color marker are:
police Command (Single-Rate), page 6-6

OL-7433-09
6-5
Chapter 6
Policing Traffic
police Command (Single-Rate)

To configure traffic policing based on bits per second, use the police command in policy-map class
configuration mode. To remove traffic policing from the configuration, use the no form of this command.
By default, this command is disabled.
police [cir] bps [bc] burst-normal [be] burst-excess [conform-action action]
[exceed-action action] [violate-action action]
no police [cir] bps [bc] burst-normal [be] burst-excess [conform-action action]
Syntax Description
cir
(Optional) Committed information rate (CIR). Indicates an average rate at

which the policer meters traffic. CIR is based on the interface shape rate.
bps
Specifies the average rate in bits per second (bps). Valid values are from
8,000 to 2,488,320,000 bps. If you only specify police bps, the router
transmits the traffic that conforms to the bps value and drops the traffic that
exceeds the bps value. For information on how the router calculates the
policing rate, see the Policing Rate Granularity section on page 6-25.)
bc burst-normal
(Optional) Normal or committed burst (bc) size used by the first token
bucket for policing. The burst-normal specifies the bc value in bytes. Valid
values are from 1 to 512,000,000. The default is 9,216 bytes. For more
information, see the Committed Bursts and Excess Bursts section on
page 6-21.
be burst-excess
(Optional) Excess burst (be) size used by the second token bucket for
policing. The burst-excess specifies the excess burst in bytes. Valid values
are from 0 to 1,024,000,000 bytes. The default is 0. You must specify
burst-normal before you specify burst-excess. For more information, see
the Committed Bursts and Excess Bursts section on page 6-21.
Note
When the be value equals 0, we recommend that you set the egress
bc value to be greater than or equal to the ingress bc value plus 1.
Otherwise, packet loss can occur. For example:
be = 0
egress bc >= ingress bc + 1
conform-action action
Specifies the action to take on packets that conform to the rate limit. The
default action is transmit. You must specify burst-excess before you specify
the conform-action.
exceed-action action
Specifies the action to take on packets that exceed the rate limit, but not the
PIR. The default action is drop. You must specify the conform-action
before you specify the exceed-action.
violate-action action
(Optional) Specifies the action to take on packets that continuously exceed

the PIR rate limit. The default action is the same as the exceed-action. You
must specify the exceed-action before you specify the violate-action.
See Table 6-1 on page 6-3 for a description of each action you can specify in the police command.
For information about conforming, exceeding, and violating traffic, see the Usage Guidelines for the
police Command section on page 6-7
6-6
OL-7433-09
Chapter 6
Policing Traffic
police Command History

Cisco IOS Release
Description
Release 12.0(17)SL
The police command was introduced on the PRE1 and included a

single-rate two-color marker.
Release 12.0(22)S
This command was enhanced to include the set-mpls-exp-transmit

policing action.
Release 12.0(25)S
This command was enhanced to include a three-color marker. A new

violate-action parameter allows you to specify the action to take for traffic
that consistently violates the committed rate.
Release 12.2(16)BX
This command was introduced on the PRE2 and included a single-rate

two-color marker.
Release 12.3(7)XI
This command was enhanced on the PRE2 and included a three-color

marker and the set-mpls-exp-imposition-transmit policing action. This
action is available on the PRE2 only.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
This command was introduced on the PRE3 to allow you to police traffic on
the L2TP access concentrator (LAC) based on the value of a packets IP
DSCP bits. The set-frde-transmit policing action was also added for the
PRE3.
Usage Guidelines for the police Command

A packet is classified as conforming (or of color green) if its size is at most the size of the normal or
committed burst (bc) and within the allowance of the committed information rate (CIR).
A packet is classified as exceeding (or of color yellow) only if its size is greater than the allowance of
the CIR, but is at most the number of bytes of the excess burst (be) and within the available surplus.
A packet is classified as violating (or of color red) only if its size is greater than both the CIR allowance
and the available surplus, either because the packets size exceeds the excess burst (be) size or because
a previous packet used some of the surplus and the traffic since then has not slowed sufficiently to
acquire the surplus needed for the current packet. The policer starts with a surplus equal to the excess
burst (be) size and replenishes it by the amount of unused CIR allowance until the surplus reaches the
be size.
The policer measures the committed burst size (CBS) and the excess burst size (EBS) in bytes. The
Cisco IOS software converts the policing rate you enter in bits per second to bytes per millisecond. You
must configure the CBS and EBS so that at least one of them is larger than 0.
When the be value equals 0, we recommend that you set the egress bc value to be greater than or equal
to the ingress bc value plus 1. Otherwise, packet loss can occur. For example:
be = 0

OL-7433-09
6-7
Chapter 6
Policing Traffic
Two-Rate Three-Color Marker for Traffic Policing

The two-rate three-color marker improves bandwidth management by allowing you to police traffic
streams according to two separate rates. Unlike the single-rate policer, which allows you to manage
bandwidth by setting the excess burst size (be), the two-rate policer allows you to manage bandwidth by
setting the committed information rate (CIR) and the peak information rate. Therefore, the two-rate
policer supports a higher level of bandwidth management and a sustained excess rate. The two-rate
policer also enables you to implement differentiated services (DiffServ) assured forwarding (AF)
per-hop behavior (PHB) traffic conditioning (see the Implementing DiffServ for End-to-End Quality of
Service section in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.3).
Note
For information about the single-rate color marker, see the Single-Rate Color Marker for Traffic
Policing section on page 6-4.
The two-rate policer is often configured on interfaces at the edge of a network to limit the rate of traffic
entering or leaving the network. In addition to rate-limiting traffic, the policers three-color marker can
mark packets according to whether the packet conforms (green), exceeds (yellow), or violates (red) a
specified rate. You decide the actions you want the router to take for conforming, exceeding, and
violating traffic. For example, you can configure conforming packets to be sent, exceeding packets to be
sent with a decreased priority, and violating packets to be dropped. In most common configurations,
traffic that conforms is sent and traffic that exceeds is sent with decreased priority or is dropped. You
can change these actions according to your network needs.
With packet marking, you can partition your network into multiple priority levels or classes of service
(CoS). For example, you can configure the two-rate three-color marker to do the following:
Assign packets to a QoS group, which the router then uses to determine how to prioritize packets
within the router.
Set the IP precedence level, IP DSCP value, or the MPLS experimental value of packets entering the
network. Networking devices within your network can then use this setting to determine how to treat
the traffic. For example, a weighted random early detection (WRED) drop policy can use the IP
precedence value to determine the drop probability of a packet.
Set the ATM cell loss priority (CLP) bit in ATM cells. The ATM CLP bit is used to prioritize packets
in ATM networks and is set to either 0 or 1. During congestion, the router discards cells with a CLP
bit setting of 1 before it discards cells with a CLP bit setting of 0.
The three-color marker distinguishes between the nonconforming traffic that occasionally bursts a
certain number of bytes more than the CIR and violating traffic that continually violates the PIR
allowance. Applications can utilize the three-color marker to provide three service levels: guaranteed,
best effort, and deny. The three-color marker is useful in marking packets in a packet stream with
different, decreasing levels of assurances (either absolute or relative). For example, a service might
discard all red packets because they exceed both the committed and excess burst sizes, forward yellow
packets as best effort, and forward green packets with a low drop probability.
Note
The router maintains the behavior of the two-color marker by automatically setting the violate action to
be the same as the exceed action (unless you configure the violate action). Therefore, you can continue
to use the two-color marker. However, it is important to note that the router collects statistics for
conforming, exceeding, and violating packets. Therefore, when verifying packet counts be sure to
observe all three statistical categories to ensure an accurate count.
6-8
OL-7433-09
Chapter 6
Policing Traffic
The two-rate three-color marker uses a token bucket algorithm to manage the maximum rate of traffic.
The token bucket algorithm can use the values you specify to determine the maximum rate of traffic
allowed on an interface at a given moment in time. All traffic entering or leaving an interface affects the
token bucket algorithm, depending on whether the two-rate policer is configured on an inbound or
outbound interface. The token bucket algorithm is useful in managing network bandwidth when large
packets are sent in the same traffic stream. For more information about the token bucket algorithm, see
the Metering Traffic and Token Buckets section on page 6-18.
To mark traffic without using a policer, see Chapter 7, Marking Traffic.
Feature History for the Two-Rate Color Marker

Cisco IOS Release
Description
Required PRE
Release 12.2(27)SBB
The two-rate three-color marker feature was introduced on

the router.
PRE2
Release 12.2(31)SB2

PRE3
on the value of a packets IP DSCP bits.
Configuration Commands for the Two-Rate Color Marker

The commands used to configure the two-rate color marker are:
police Command (Two-Rate), page 6-9
police Command (Two-Rate)

To configure traffic policing using the committed information rate (CIR) and the peak information rate
(PIR), use the police command in policy-map class configuration mode. To remove two-rate traffic
policing from the configuration, use the no form of this command. By default, this command is disabled.
police {cir cir} [bc] burst-normal [pir pir] [be] peak-burst [conform-action action]
no police {cir cir} [bc] burst-normal [pir pir] [be] peak-burst [conform-action action]
Syntax Description
cir cir
Committed information rate (CIR). Indicates an average rate at which the

policer meters traffic. CIR is based on the interface shape rate. The cir
specifies the CIR value in bits per second. Valid values are from 8000 to
2,488,320,000 bits per second.
bc burst-normal
(Optional) Specifies the normal or committed burst (bc) size used by the
first token bucket for policing. The burst-normal specifies the bc value in
bytes. Valid values are from 1 to 512,000,000. The default is 9,216 bytes.
For more information, see the Committed Bursts and Excess Bursts

OL-7433-09
6-9
Chapter 6
Policing Traffic
pir pir
Peak information rate (PIR). Indicates the rate at which the second token
bucket is updated. The pir specifies the PIR value in bits per second. Valid
values are from 8000 to 2,488,320,000.
be peak-burst
(Optional) Specifies the peak burst (be) size used by the second token
bucket for policing. The peak-burst specifies the be value in bytes. The size
depends on the interface used. Valid values are 0 to 1,024,000,000.
Note
When the be value equals 0, we recommend that you set the egress
bc value to be greater than or equal to the ingress bc value plus 1.
Otherwise, packet loss can occur. For example:
be = 0
(Optional) Specifies the action to take on packets that conform to the rate
limit. The default action is transmit. You must specify burst-excess before
you specify the conform-action.
(Optional) Specifies the action to take on packets that exceed the rate limit,
but not the PIR. The default action is drop. You must specify the
conform-action before you specify the exceed-action.

See Table 6-1 on page 6-3 for a description of each action you can specify.
police Command section on page 6-7.
police Command History

Cisco IOS Release
Description
Release 12.2(27)SBB
The single-rate police command was enhanced on the PRE2 to allow you to
configure two traffic policing rates: the committed information rate (CIR)
and the peak information rate (PIR).
Release 12.2(31)SB2
DSCP bits.
Usage Guidelines for the police Command

be = 0
6-10
OL-7433-09
Chapter 6
Policing Traffic
Percent-Based Policing
Percent-based policing enables you to configure traffic policing as a percentage of the bandwidth of the
network interface on which policing is applied. Configuring traffic policing based on bandwidth
percentage enables you to use the same policy map for multiple interfaces with differing amounts of
bandwidth.
Percent-based policing also allows you to specify burst sizes in milliseconds (ms). The router calculates
the burst value in milliseconds based on the policing rate.
When you use a percent-based police command within a nested policy, the police percent is based on
the nearest parent shape rate. If no parent shaping exists, the police percent is based on the link
bandwidth. The router calculates the burst value in milliseconds (ms) based on the policing rate.
Percent-based policing supports two traffic policing rates if the parent policy map has only one class
defined: the class-default class. The parent policy does only match-any matching when applying the
class-default shaping rate.
Feature History for Percent-Based Policing

Cisco IOS Release
Description
Required PRE
Release 12.0(25)SX
The percent-based policing feature was introduced on the

router.
PRE1
Release 12.3(7)XI
PRE2
Release 12.2(28)SB
This feature was enhanced on the PRE2 to allow you to

PRE2
configure two traffic policing rates as a percentage: the
committed information rate (CIR) and the peak information
rate (PIR).
Release 12.2(31)SB2

PRE3
on the value of a packets IP DSCP bits. The
set-frde-transmit policing action was also added for the
PRE3.
police percent Command

To configure traffic policing on the basis of a percentage of bandwidth available on an interface, use the
police percent command in policy-map class configuration mode. To remove traffic policing from the
configuration, use the no form of the command. By default, this command is disabled.
police [cir] percent percent [bc] normal-burst-in-msec [pir pir] [be] excess-burst-in-msec
[conform-action action] [exceed-action action] [violate-action action]
no police [cir] percent percent [bc] normal-burst-in-msec [pir pir]
[be] excess-burst-in-msec [conform-action action] [exceed-action action] [violate-action
action]

OL-7433-09
6-11
Chapter 6
Policing Traffic
Syntax Description
cir
(Optional) Committed information rate (CIR). Indicates an average rate at

which the policer meters traffic. CIR is based on the interface shape rate.
percent percent
Indicates to use the percentage of available bandwidth specified in percent

to calculate the CIR. Valid values are from 1 to 100.
bc normal-burst-in-msec (Optional) Specifies the normal or committed burst size (CBS) that the
first token bucket uses for policing traffic. Specify the CBS value in
milliseconds (ms). Valid values are from 1 to 2000. The default value is
the greater of 2 ms worth of bytes at the police rate or the network
minimum transmission unit (MTU).
pir pir
(Optional) Peak information rate (PIR), expressed as a percentage.

Indicates the rate at which the second token bucket is updated. Valid values
are from 1 to 100.
Note
be excess-burst-in-msec
When using percent-based policing, you must explicitly enter the

PIR value.
(Optional) Specifies the excess burst size (EBS) that the second token
bucket uses for policing traffic. Specify the EBS value in milliseconds
(ms). Valid values are from 0 to 2000. The default value is zero (0). You
must specify normal-burst-in msec before you specify
excess-burst-in-msec.
Note
Burst in milliseconds is based on the policing committed

information rate (CIR).
(Optional) Specifies the action to take on packets that conform to the rate
limit. The default action is transmit. You must specify a value for
excess-burst-in-msec before you specify the conform-action.
(Optional) Specifies the action to take on packets that exceed the rate limit,
but not the PIR. The default action is drop. You must specify the
conform-action before you specify the exceed-action.

See Table 6-1 on page 6-3 for a description of each action you can specify.
police Command section on page 6-7.
police percent Command History

Cisco IOS Release
Description
Release 12.0(25)SX
The police percent command was introduced on the PRE1.
Release 12.3(7)XI
6-12
OL-7433-09
Chapter 6
Policing Traffic
Cisco IOS Release
Description
Release 12.2(28)SB
This command was enhanced on the PRE2 to allow you to configure two
traffic policing rates as a percentage: the committed information rate (CIR)
and the peak information rate (PIR)
Release 12.2(31)SB2
DSCP bits.
Usage Guidelines for the police percent Command

Percent-based policing supports two levels of policing if the parent policy map has only one class
defined: the class-default class. The parent policy does only match-any matching when applying the
class-default shaping rate.
Shaping affects the input and output policer. For example, if you configure a percent-based policer on
an input interface and the output interface has a nested policy attached, the policing percentage is based
on the outgoing shape rate.
You must explicitly enter the PIR when using percent-based policing.
Example
The following configuration polices Data traffic at 20 percent and sets the PIR to 25 percent.
Router(config)# policy-map Business
Router(config-pmap)# class Data
Router(config-pmap-c)# police percent 20 3 ms pir 25 10 ms

The Cisco 10000 series router supports control plane policing in Cisco IOS Release 12.2(31)SB2 and
later releases. The Control Plane Policing feature allows you to configure a quality of service (QoS) filter
that manages the traffic flow of control plane packets. This allows you to protect the control plane of the router
against reconnaissance and denial-of-service (DoS) attacks. In this way, the control plane (CP) can help
maintain packet forwarding and protocol states despite an attack or heavy traffic load on the router or switch.
For more information, see the Control Plane Policing, Release 12.2(31)SB2 feature module.
AToM Set ATM CLP Bit Using a Policer

The AToM Set ATM CLP Bit Using a Policer feature enables you to police and mark inbound ATM
traffic before forwarding it onto Any Transport over MPLS (AToM) Layer 2 virtual private network
(VPN) pseudowire. Using this feature, you can configure the police command to set the ATM cell loss
priority (CLP) bit in the packet header. This bit indicates the drop priority of the ATM cell. During ATM
network congestion, the router discards ATM cells with the CLP bit set to 1 before discarding cells with
a CLP bit setting of 0.

OL-7433-09
6-13
Chapter 6
Policing Traffic
AToM Set FR DE as Police Action
The Set ATM CLP Bit Using a Policer feature polices the traffic on the inbound interface of the provider
edge (PE) router where the attachment VC terminates. Marking of the ATM cells using the
set-clp-transmit policing action occurs on the outbound interface. Therefore, when configuring this
feature for AToM, you must attach a policy map that includes the set-clp-transmit action to the interface
upon which the ATM VC terminates or, in other words, attach the policy map to the input interface of
the PE.
The router supports the set-clp-transmit policing action in single-rate and dual-rate policing policies, and
in hierarchical policies.
The router allows you to simultaneously configure the policing actions set-clp-transmit and
set-mpls-exp-imposition-transmit in a single police command on the Layer 2 VPN inbound interface.
Feature History for Set ATM CLP Bit Marking As a Police Action
Cisco IOS Release
Description
Required PRE
Release 12.3(7)XI
PRE2
Release 12.2(33)SB
This feature was introduced on the PRE3 and PRE4.
PRE3, PRE4
AToM Set FR DE as Police Action

The AToM Set FR DE as Police Action feature enables you to police and mark inbound Frame Relay
traffic before forwarding it onto Any Transport over MPLS (AToM) Layer 2 virtual private network
(VPN) pseudowire. Using this feature, you can configure the police command to set the Frame Relay
discard eligibility (DE) bit in the packet header. This bit indicates the drop priority of the frame. During
Frame Relay network congestion, the router discards frames with the DE bit set to 1 before discarding
frames with a DE bit setting of 0.
The AToM Set FR DE as Police Action feature polices the traffic on the inbound interface of the provider
edge (PE) router where the attachment VC terminates. Marking of frames using the set-frde-transmit
policing action occurs on the outbound interface. Therefore, when configuring this feature, you must
attach a policy map that includes the set-frde-transmit action to an input interface of the PE.
The router supports the set-frde-transmit policing action in single-rate and dual-rate policing policies,
and in hierarchical policies.
The router allows you to configure the set-frde-transmit and set-mpls-exp-imposition-transmit policing
actions in a single police command on Any Transport over MPLS (AToM) Layer 2 VPN inbound
interfaces.
Feature History for AToM Set FR DE as Police Action

Cisco IOS Release
Description
Required PRE
Release 12.2(33)SB
This feature was introduced on the PRE2, PRE3, and PRE4. PRE2, PRE3,
PRE4
6-14
OL-7433-09
Chapter 6
Policing Traffic
Set Layer 2 CoS as a Policer Action
Set Layer 2 CoS as a Policer Action

The Set Layer 2 CoS as a Policer Action feature enables you to police and mark inbound VLAN and
QinQ traffic before forwarding the traffic onto the outbound link. Using this feature, you can configure
the police command to set the class of service (CoS) bits for VLAN traffic and to set the outer CoS bits
for QinQ traffic. The 3-bit CoS field is part of the VLAN tag and indicates the priority level of the frame.
IEEE 802.1p establishes eight levels of priority: 0 to 7.
This feature polices the traffic on the inbound interface of the provider edge (PE) router where the
attachment VC terminates. Marking of frames using the set-cos-transmit policing action occurs on the
outbound interface. Therefore, when configuring this feature, you must attach a policy map that includes
the set-cos-transmit action to an outbound interface, not to an inbound interface.
The set-cos-transmit policing action marks the outer CoS bits. To configure marking of outer CoS bits,
configure the police command and specify the set-cos-transmit policing action as a conform, exceed, or
violate action.
The router supports set-cos-transmit as a three-color policing action in single-rate and dual-rate policing
policies, and in hierarchical policies.
Feature History for Set Layer 2 CoS as Policer Action

Cisco IOS Release
Description
Required PRE
Release 12.2(33)SB
This feature was introduced on the router for the PRE2,

PRE3, and PRE4.
PRE2, PRE3,
PRE4
Set Inner CoS as a Policer Action

The Set Inner CoS as a Policer Action feature uses the police command to set the inner VLAN class of
service (CoS) bits for QinQ traffic on the PRE2, PRE3, and PRE4. The 3-bit CoS field is part of the
VLAN tag and indicates the priority level of the frame. IEEE 802.1p establishes eight levels of priority:
0 to 7
attachment VC terminates. Marking of frames using the set-cos-inner-transmit policing action occurs on
the outbound interface. Therefore, when configuring this feature, you must attach a policy map that
includes the set-cos-inner-transmit action to an outbound interface, not to an inbound interface.
To configure marking of inner CoS bits, configure the police command and specify the
set-cos-inner-transmit policing action as a conform, exceed, or violate action.
The router supports the set-cos-inner-transmit policing action in single-rate and dual-rate policing
Feature History for Set Inner CoS as a Policer Action

Cisco IOS Release
Description
Required PRE
Release 12.2(33)SB

PRE3, and PRE4.
PRE2, PRE3,
PRE4

OL-7433-09
6-15
Chapter 6
Policing Traffic
Set Inner and Outer CoS as a Policer Action
Set Inner and Outer CoS as a Policer Action

The Set Inner and Outer CoS as a Policer Action feature uses the police command to set the inner and
outer VLAN class of service (CoS) bits for QinQ traffic on the PRE2, PRE3, and PRE4. The 3-bit CoS
field is part of the VLAN tag and indicates the priority level of the frame. IEEE 802.1p establishes eight
levels of priority: 0 to 7
attachment VC terminates. Marking of frames using the set-cos-transmit and set-cos-inner-transmit
policing actions occurs on the outbound interface. Therefore, when configuring this feature, you must
attach a policy map that includes the both of these policing actions to an outbound interface, not to an
inbound interface.
The set-cos-transmit policing action sets the outer CoS bits whereas the set-cos-inner-transmit action
sets the inner CoS bits. To configure marking of both inner and outer CoS bits at the same time, you must
specify both the set-cos-transmit and set-cos-inner-transmit policing actions in a single police command.
You can specify these policing actions as conform, exceed, or violate actions.
The router supports simultaneous inner and outer CoS marking in single-rate and dual-rate policing
Feature History for Set Inner and Outer CoS as a Policer Action
Cisco IOS Release
Description
Required PRE
Release 12.2(33)SB

PRE3, and PRE4.
PRE2, PRE3,
PRE4
Dual Police Actions

The router allows you to specify dual actions for conforming, exceeding, and violating traffic, one line
at a time. After you provide the police rates, press Return to enter the policy-map-class-police
configuration mode. While in this mode, you can configure the dual conform, exceed, and violate actions
by entering an action keyword and action value, and pressing Return after each specified action. Valid
combinations of dual actions are:
Note
set-clp-transmit and set-mpls-exp-imposition-transmit
set-frde-transmit and set-mpls-exp-imposition-transmit
set-cos-transmit and set-cos-inner-transmit
The router allows only the dual action combinations listed above and does not do error checking for these
actions.
For example, you can specify the first conform-action as set-frde-transmit and the second
conform-action as set-mpls-exp-imposition-transmit. If desired, you can then specify these same two
actions as the action for the first and second exceed actions and for the two violate actions.
6-16
OL-7433-09
Chapter 6
Policing Traffic
If you upgrade from a Cisco IOS software release that does not support dual police actions to a
Cisco IOS release that supports dual police actions, the police command displays on a single line. If you
configure each police action on a separate line and then downgrade to a Cisco IOS release that does not
support dual actions, the router rejects the policer.
For backward compatibility, the router accepts the police command on a single line, but after entering
the police command, the router enters policy-map-class-police configuration mode.
Feature History for Dual Police Actions

Cisco IOS Release
Description
Required PRE
Release 12.2(33)SB
This feature was introduced on the router for the PRE3 and PRE3, PRE4
PRE4.

The Policing Support for GRE Tunnels feature allows you to set the Differentiated Services Code Point
(DSCP) and IP precedence values on Generic Routing Encapsulation (GRE) tunnel packets.
This feature is essential for MPLS carriers to offer QoS on Multicast VPN services. Multicast VPN
(MVPN) uses GRE tunnels between PE devices, and multicast packets are placed in GRE tunnels for
transmission across the MPLS core network. The Policing Support for GRE Tunnels feature allows the
GRE tunnel to reflect the underlying QoS of the multicast packets. Once the GRE packets accurately
reflect the QoS markings of the underlying multicast packets, they may be queued accordingly as they
travel across the core nodes.
For more information, see the Policing Support for GRE Tunnels, Release 12.2(31)SB2 feature module
and the Tunnel Header Marking section on page 7-18.
Interfaces Supporting Policing

The following describes interface support for policing using the police command:
Interfaces Supporting the police Command
Physical
Multilink PPP and multilink Frame Relay
ATM variable bit rate (VBR) and constant bit rate (CBR) PVCs, and point-to-point subinterfaces
Frame Relay permanent virtual circuits (PVCs), point-to-point subinterfaces, and map classes
Ethernet VLANs
IP tunnel

OL-7433-09
6-17
Chapter 6
Policing Traffic
Metering Traffic and Token Buckets
Note
The router supports the police command on inbound and outbound interfaces.
Interfaces Not Supporting the police Command
Fast Ethernet channel
Frame Relay data link connection identifier (DLCI)

The following sections describe how single-rate and two-rate policers meter traffic using token buckets:
Metering Traffic Using Token Buckets (Single-Rate Policer), page 6-18
Metering Traffic Using Token Buckets (Two-Rate Policer), page 6-19
Metering Traffic Using Token Buckets (Single-Rate Policer)

The router uses two token buckets to meter the traffic that passes through the system: conforming and
exceeding. The router uses the first bucket to hold tokens that determine whether the committed
information rate (CIR) is conforming (green) or exceeding (yellow). A traffic stream is conforming when
the average number of bytes over time does not cause the bucket to overflow. The first bucket can hold
bytes up to the size of the committed burst (bc) before overflowing.
A traffic stream exceeds the police rate when it causes the first token bucket to overflow into the second
token bucket. When this occurs, the router marks the traffic stream yellow. The second token bucket is
filled as long as the traffic exceeds the police rate.
The second token bucket can hold bytes up to the size of the excess burst (be) before overflowing. A
traffic stream violates the police rate if the second token bucket overflows. When this occurs, the router
marks the traffic stream red.
The router updates the tokens for both the conforming and exceeding token buckets based on the token
arrival rate or the committed information rate (CIR). When a packet of a given size (for example, B
bytes) arrives at specific time (time T), the following actions occur:
The router updates the tokens in the conforming bucket. If the previous arrival of the packet was at
the rate of T1 (1.544 Mbps) and the current arrival of the packet is at T, the router updates the bucket
with T minus T1 worth of bits based on the token arrival rate. The router places refill tokens in the
conforming bucket. If the tokens overflow the conforming bucket, the router places the overflow
tokens in the exceeding bucket.
The router calculates the token arrival rate in the following way:
(time between packets * policer rate) / 8 bytes
where time between packets equals T T1
If the number of bytes in the conforming bucket is greater than or equal to 0, the packet conforms.
The router removes the number of bytes of the packet from the conforming bucket and takes the
conform action on the packet. In this scenario, the exceeding bucket is unaffected.
If the number of bytes in the conforming bucket is less than 0, the router checks the exceeding bucket
for bytes. If the number of bytes in the exceeding bucket is greater than or equal to 0, the router
removes the number of bytes of the packet from the exceeding token bucket and takes the exceed
action. The router does not remove bytes from the conforming bucket.
6-18
OL-7433-09
Chapter 6
Policing Traffic
If the number of bytes in the exceeding bucket is less than 0, the packet violates the rate and the
router takes the violate action.
Metering Traffic Using Token Buckets (Two-Rate Policer)

The two-rate policer manages the maximum rate of traffic by using two token buckets: the committed
token bucket and the peak token bucket. The dual-token bucket algorithm uses user-configured values to
determine the maximum rate of traffic allowed on a queue at a given moment. In this way, the two-rate
policer can meter traffic at two independent rates: the committed information rate (CIR) and the peak
information rate (PIR).
The committed token bucket can hold bytes up to the size of the committed burst (bc) before
overflowing. This token bucket holds the tokens that determine whether a packet conforms to or exceeds
the CIR as the following describes:
A traffic stream is conforming when the average number of bytes over time does not cause the
committed token bucket to overflow. When this occurs, the token bucket algorithm marks the traffic
stream green.
A traffic stream is exceeding when it causes the committed token bucket to overflow into the peak
token bucket. When this occurs, the token bucket algorithm marks the traffic stream yellow. The
peak token bucket is filled as long as the traffic exceeds the police rate.
The peak token bucket can hold bytes up to the size of the peak burst (be) before overflowing. This token
bucket holds the tokens that determine whether a packet violates the PIR. A traffic stream is violating
when it causes the peak token bucket to overflow. When this occurs, the token bucket algorithm marks
the traffic stream red.
The dual-token bucket algorithm provides users with three actions for each packeta conform action,
an exceed action, and an optional violate action. Traffic entering a queue with the two-rate policer
configured is placed into one of these categories. Within these three categories, users can decide packet
treatments. For instance, packets that conform can be configured to be sent; packets that exceed can be
configured to be sent with a decreased priority; and packets that violate can be configured to be dropped.
Figure 6-1 shows how the two-rate policer marks a packet and assigns a corresponding action to the
packet.

OL-7433-09
6-19
Chapter 6
Policing Traffic
Figure 6-1
Marking Packets and Assigning Actions2-Rate Policer
CIR
PIR
Bc
Be
B > Tp
No
B > Tc
No
Packet of size B
Yes
Violate
Exceed
Conform
Action
Action
Action
60515
Yes
For example, if a data stream with a rate of 250 kbps arrives at the two-rate policer, and the CIR is
100 kbps and the PIR is 200 kbps, the policer marks the packet in the following way:
100 kbps conforms to the rate
100 kbps exceeds the rate
50 kbps violates the rate
The router updates the tokens for both the committed and peak token buckets in the following way:
The router updates the committed token bucket at the CIR value each time a packet arrives at the
interface. The committed token bucket can contain up to the committed burst (bc) value.
The router updates the peak token bucket at the PIR value each time a packet arrives at the interface.
The peak token bucket can contain up to the peak burst (be) value.
When an arriving packet conforms to the CIR, the router takes the conform action on the packet and
decrements both the committed and peak token buckets by the number of bytes of the packet.
When an arriving packet exceeds the CIR, the router takes the exceed action on the packet,
decrements the committed token bucket by the number of bytes of the packet, and decrements the
peak token bucket by the number of overflow bytes of the packet.
When an arriving packet exceeds the PIR, the router takes the violate action on the packet, but does
not decrement the peak token bucket.
6-20
OL-7433-09
Chapter 6
Policing Traffic
Committed Bursts and Excess Bursts

Unlike a traffic shaper, a traffic policer does not buffer excess packets and transmit them later. Instead,
the policer executes a send or do not send policy without buffering. During periods of congestion,
proper configuration of the excess burst parameter enables the policer to drop packets less aggressively.
Therefore, it is important to understand how policing uses the committed (normal) and excess burst
values to ensure the router reaches the configured committed information rate (CIR).
Burst parameters are based on a generic buffering rule for routers, which recommends that you configure
buffering to be equal to the round-trip time bit-rate to accommodate the outstanding TCP windows of all
connections in times of congestion.
The following sections describe committed bursts and excess bursts, and the recommended formula for
calculating each of them:
Committed Bursts, page 6-21
Excess Bursts, page 6-22
Deciding if Packets Conform or Exceed the Committed Rate, page 6-23
Committed Bursts
The committed burst (bc) parameter of the police command implements the first, conforming (green)
token bucket that the router uses to meter traffic. The bc parameter sets the size of this token bucket.
Initially, the token bucket is full and the token count is equal to the committed burst size (CBS).
Thereafter, the meter updates the token counts the number of times per second indicated by the
committed information rate (CIR).
The following describes how the meter uses the conforming token bucket to send packets:
If sufficient tokens are in the conforming token bucket when a packet arrives, the meter marks the
packet green and decrements the conforming token count by the number of bytes of the packet.
If there are insufficient tokens available in the conforming token bucket, the meter allows the traffic
flow to borrow the tokens needed to send the packet. The meter checks the exceeding token bucket
for the number of bytes of the packet. If the exceeding token bucket has a sufficient number of tokens
available, the meter marks the packet:
a. Green and decrements the conforming token count down to the minimum value of 0.
b. Yellow, borrows the remaining tokens needed from the exceeding token bucket, and decrements
the exceeding token count by the number of tokens borrowed down to the minimum value of 0.
Note
If an insufficient number of tokens is available, the meter marks the packet red and does not
decrement either of the conforming or exceeding token counts.
When the meter marks a packet with a specific color, there must be a sufficient number of tokens of that
color to accommodate the entire packet. Therefore, the volume of green packets is never smaller than the
committed information rate (CIR) and committed burst size (CBS). Tokens of a given color are always
used on packets of that color.
The default committed burst size is the greater of 2 milliseconds of bytes at the police rate or the network
maximum transmission unit (MTU).

OL-7433-09
6-21
Chapter 6
Policing Traffic
Committed Burst Calculation

To calculate committed burst, use the following formula:
bc = CIR bps * (1 byte) / (8 bits) * 1.5 seconds
Note
1.5 seconds is the typical round-trip time.

For example, if the committed information rate is 512000 bps, then using the committed burst formula,
the committed burst is 96000 bytes.
bc = 512000 * 1/8 * 1.5
bc = 64000 * 1.5 = 96000
Note
be = 0
Excess Bursts
The excess burst (be) parameter of the police command implements the second, exceeding (yellow)
token bucket that the router uses to meter traffic. The exceeding token bucket is initially full and the
token count is equal to the excess burst size (EBS). Thereafter, the meter updates the token counts the
number of times per second indicated by the committed information rate (CIR).
The following describes how the meter uses the exceeding token bucket to send packets:
When the first token bucket (the conforming bucket) meets the committed burst size (CBS), the
meter allows the traffic flow to borrow the tokens needed from the exceeding token bucket. The
meter marks the packet yellow and then decrements the exceeding token bucket by the number of
bytes of the packet.
If the exceeding token bucket does not have the required tokens to borrow, the meter marks the
packet red and does not decrement the conforming or the exceeding token bucket. Instead, the meter
performs the exceed-action configured in the police command (for example, the policer drops the
packets).
Excess Burst Calculation

To calculate excess burst, use the following formula:
be = 2 * committed burst
For example, if you configure a committed burst of 4000 bytes, then using the excess burst formula, the
excess burst is 8000 bytes.
be = 2 * 4000 = 8000
The default excess burst size is 0.
6-22
OL-7433-09
Chapter 6
Policing Traffic
Deciding if Packets Conform or Exceed the Committed Rate

Policing uses normal or committed burst (bc) and excess burst (be) values to ensure that the configured
committed information rate (CIR) is reached. Policing decides if a packet conforms or exceeds the CIR
based on the burst values you configure. Several factors can influence the policers decision, such as the
following:
Low burst valuesIf you configure burst values too low, the achieved rate might be much lower than
the configured rate.
Temporary burstsThese bursts can have a strong adverse impact on throughput of Transmission
Control Protocol (TCP) traffic.
It is important that you set the burst values high enough to ensure good throughput. If your router drops
packets and reports an exceeded rate even though the conformed rate is less than the configured CIR, use
the show interface command to monitor the current burst, determine whether the displayed value is
consistently close to the committed burst (bc) and excess burst (be) values, and if the actual rates (the
committed rate and exceeded rate) are close to the configured committed rate. If not, the burst values
might be too low. Try reconfiguring the burst rates using the suggested calculations in the Committed
Burst Calculation section on page 6-22 and the Excess Burst Calculation section on page 6-22.

Table 6-2 describes the data included and excluded in the policing rate.
Table 6-2
Policing Rate Data
Media
Data Included
Data Excluded
Frame Relay
Layer 2 framing
No bit or byte stuffing

No 7E flags1
No Frame Check Sequence (FCS)
Ethernet
Layer 2 framing
Generic Traffic Shaping Class-Based

Shaping
No Inter-Frame Gap (IFG)

No Preamble
No Start of Frame Delimiter (SFD)
No Frame Check Sequence (FCS)
ATM
(VBR)
Layer 2 framing
No cell header
Cell overhead
No AAL Common Part Convergence

Sublayer (CPCS) pad
No ATM trailer

OL-7433-09
6-23
Chapter 6
Policing Traffic
Table 6-2
Policing Rate Data
Media
Data Included
Data Excluded
ATM
(UBR)
Layer 2 framing
Class-Based Shaping
Cell overhead
No ATM cell overhead

Sublayer (CPCS) pad
ATM
(CBR)
Layer 2 framing
Class-Based Shaping
Cell overhead
No ATM cell overhead

Sublayer (CPCS) pad
1. The router does not account for flags or Frame Check Sequence (FCS) that the hardware adds or removes.
Table 6-3 describes what bandwidth is based on for each media type.
Table 6-3
Basis for Bandwidth
Media
Bandwidth Based On
Frame Relay
Fragments1
Ethernet
Bits
ATM variable bit rate (VBR)
ATM unspecified bit rate (UBR)
ATM constant bit rate (CBR)
1. For Frame Relay networks with link fragmentation and interleaving (LFI) enabled.
Be sure to take into account the framing and cell overhead when specifying a minimum bandwidth for a
class. For example, if you need to commit a rate of 1000 64-byte packets per second and each packet has
4 bytes of framing overhead, instead of using 512 kbps in the bandwidth or police command, use
544 kbps, calculated as follows:
1000 * (64 + 4) * 8 /1000 = 544
A similar scenario for ATM requires 848 kbps because each 64-byte packet requires two cells of
53 bytes.
1000 * 2 * 53 * 8 / 1000 = 848
6-24
OL-7433-09
Chapter 6
Policing Traffic

Policing
The router converts the policing rate you specify in bits per second to 8,000-byte increments. When
you specify a policing rate, the router rounds the rate up or down to the nearest multiple of 8000.
For example, if you request 127,000 bps, the router rounds up to 128,000 bps; for 124,000 bps, the
router rounds up to 128,000 bps; and for 123,999 bps the router rounds down to 120,000 bps.
The committed information rate (CIR) is based on a percentage of the maximum amount of
bandwidth available on the interface.
For percent-based policing, the burst value in milliseconds is based on the policing rate.
Within a nested policy, the police percentage is based on the nearest parent shape rate. If no parent
shaping exists, the police percentage is based on the link bandwidth.
Avoiding Bandwidth Starvation Due to Priority Services

The Cisco 10000 series router services priority traffic at near line rate to ensure that traffic is handled
with minimal delay. The router gives preference to the priority class over other class queues on a traffic
link. Unless the priority class contains a police command, the router does not police the priority traffic
to its configured rate and the router does not discard excess priority traffic. As a result, excess priority
traffic might cause additional packet delay and other queues on the link might experience bandwidth
starvation.
To prevent the priority queue from starving the other queues, use the police command with the priority
command. To ensure the committed rate of the priority queue, you must set the exceed and violate
actions of the police command to drop. You can use the bandwidth command on the other queues on
the link to create one or more queues with guaranteed bandwidth.
Example 6-1 shows how to configure the priority and police commands for a priority class:
Example 6-1
Configuring the priority and police Commands
Router(config)# policy-map gold

Router(config-pmap-c)# police 512000 8000 1000 conform-action transmit exceed-action drop
violate-action drop
Example 6-2 shows how to configure the priority and police percent commands for a priority class:
Example 6-2
Configuring the priority and police percent Commands
Router(config)# policy-map new-traffic

Router(config-pmap-c)# police percent 25 2 ms 2 ms conform-action transmit exceed-action
drop violate-action drop

OL-7433-09
6-25
Chapter 6
Policing Traffic
Bandwidth and Policing

The police command allows you to police the traffic that passes through the router. You can configure
traffic policing in bits per second (bps) or as a percentage of bandwidth of the network interface on which
policing is applied. Configuring traffic policing based on bandwidth percentage enables you to use the
same policy map for multiple interfaces with differing amounts of bandwidth.
To configure traffic policing on the basis of a percentage of bandwidth available on an interface, use the
police percent command in policy-map class configuration mode. The police percent command
calculates the CIR based on a percentage of the maximum amount of bandwidth available on the
interface. When you attach a policy map to an interface, the router calculates the equivalent CIR values
in bits per second (bps) based on the interface bandwidth and the percentage you entered for the
police percent command.
The police percent command also allows you to optionally specify values for the conform burst size and
the peak burst size in bytes per millisecond. If you specify the burst sizes, be sure to specify the size in
milliseconds.
If the interface bandwidth changes (for example, more is added), the router recalculates the bps values
of the CIR based on the revised amount of bandwidth. If you change the CIR percentage after you attach
the policy map to the interface, the router recalculates the bps value of the CIR.
When you use a percent-based police command within a nested policy, the police percentage is based on
the policys topmost, class-default, shape rate. Otherwise, the police percentage is based on the
bandwidth of the network interface on which the police command is applied.
In a hierarchical policy, the police percent command uses the maximum rate of bandwidth available as
the reference point for calculating the bandwidth percentage. Within a nested policy, the police percent
is based on the policys topmost, class-default, shape rate. Otherwise, the police percent is based on the
bandwidth of the network interface on which the police command is applied.
When the police percent command is configured in a child (secondary-level) policy map, the police
percent command uses the bandwidth amount specified in the next higher-level policy, which in this
case is the parent (primary-level) policy map. The police percent command always looks to the next
higher level for the bandwidth reference point.
You can configure a maximum of 131,072 (PRE1) or 262,144 (PRE2) policing instances.
The router supports only the policing actions listed in Table 6-1 on page 6-3.
You cannot specify multiple conform or exceed actions for a specific class in a policy map.
In releases prior to Cisco IOS Release 12.2(33)SB, the router supports up to 16 police action types.
In Cisco IOS Release 12.2(33)SB and later releases, the router supports up to 32 police action types.
The router does not allow you to attach a policy map to the inbound interface when the policy map
contains a set-cos-transmit or set-cos-inner-transmit policing action.
The router supports only the following combinations of dual actions on the output interface:
The router allows the set-cos-transmit police action only when it is applied to an output policy.
The set-cos-transmit police action sets only the outer CoS bits.
The router allows the set-cos-inner-transmit police action only when it is applied to an output policy.
6-26
OL-7433-09
Chapter 6
Policing Traffic
Configuring Traffic Policing
The set-cos-inner-transmit police action sets only the inner CoS bits.
The router supports the set-cos-inner-transmit policing action only on QinQ subinterfaces. If you
configure this policing action in a flat policy map or a 2-level hierarchical policy and attach the
policy to an interface that is not a QinQ subinterface, the router displays an error message. However,
if you configure the set-cos-inner--transmit action in a 3-level policy map and attach the policy to a
non-QinQ subinterface, no error message displays and the router appears to accept the policy.
Therefore, we recommend that you do not use the set-cos-inner-transmit policing action in a 3-level
policy map attached to non-QinQ subinterfaces.
The router supports the set-clp-transmit and set frde-transmit police actions on the ingress for an
Any Transport over MPLS (AToM) Layer 2 VPN (L2VPN) configuration only.
The router supports only the following combinations of dual actions on the AToM L2VPN ingress:
The router does not perform extensive error checking to reject invalid combinations of dual actions.
If you provide unsupported combinations, the results may be unpredictable.
On the PRE3 and PRE4, the router enters policy-map-class-police configuration mode after you
enter the police command, regardless of whether the command specifies a single action or dual
actions.
On the PRE3 and PRE4, when specifying multiple actions, the router displays each action on a
separate line.

To configure traffic policing, perform any of the following configuration tasks:
Configuring Single-Rate Traffic Policing Based on Bits per Second, page 6-28
Configuring Percent-Based Policing, page 6-32
Configuring Two-Rate Policing, page 6-35
Marking Traffic Using Police Actions, page 6-36
Configuring Dual Police Actions, page 6-37
For more information about classifying traffic and creating QoS service policies, see Chapter 2,
Classifying Traffic and Chapter 3, Configuring QoS Policy Actions and Rules.

OL-7433-09
6-27
Chapter 6
Policing Traffic
Configuring Single-Rate Traffic Policing Based on Bits per Second

To configure traffic policing based on bits per second (bps), enter the following commands beginning in
Step 1
Command
Purpose

configuration mode.
Step 2
Assigns the traffic class you specify to the policy map.

Enters policy-map class configuration mode.
class-map-name is the name of a previously configured
class map and is the traffic class for which you want to
define QoS actions.
Step 3
Router(config-pmap-c)# police [cir] bps

[bc] burst-normal [pir pir] [be] burst-excess
[conform-action action] [exceed-action action]
[violate-action action]
Configures bits per second-based traffic policing.

For more information, see the police Command
(Single-Rate) section on page 6-6 or the police Command
(Two-Rate) section on page 6-9.
Configuration Examples for Configuring Single-Rate Traffic Policing Based on Bits per Second
Configuration Example for Configuring a Single Policing Rate and Burst Sizes, page 6-28
Configuration Example for Configuring Single-Rate Two-Color Policing, page 6-29
Configuration Example for Configuring Single-Rate Three-Color Policing, page 6-29
Configuration Example for Policing a Priority Service, page 6-30
Configuration Example for Configuring Single-Rate Policing in a Hierarchical Policy, page 6-30
Configuration Example for Policing PPPoE over ATM Sessions, page 6-31
Configuration Example for Configuring a Single Policing Rate and Burst Sizes
Example 6-3 shows how to configure a policing rate for the class named group1 in the policy map named
police. In the example, the router polices group1 traffic at 8000 bits per second and allows committed
bursts of 2000 bytes and excess bursts of 4000 bytes.
Example 6-3
Configuring a Policing Rate Based on Bits per Second
Router(config)# class-map group1

Router(config)# policy-map police
Router(config-pmap)# class group1
Router(config-pmap-c)# police 8000 2000 4000
Router(config-pmap)# exit
Router(config)# interface atm 1/0/0.1 point-to-point
Router(config-subif)# service-policy input police
6-28
OL-7433-09
Chapter 6
Policing Traffic
Configuration Example for Configuring Single-Rate Two-Color Policing

Example 6-4 shows how to configure single-rate two-color policing that includes actions for conforming
and exceeding traffic. In the example, policing is configured for the class named Group1 in the policy
map named Premium. The router polices Group1 traffic at 8,000,000 bits per second and allows
committed bursts of 4000 bytes and excess bursts of 6000 bytes. The router transmits Group1 traffic that
conforms to the normal or committed rate and sets the precedence-transmit value to 2 for Group1 traffic
that exceeds the burst sizes. The router polices Group2 traffic at 4,000,000 bits per second and allows
committed bursts of 2000 bytes and excess bursts of 5000 bytes. The router transmits Group2 traffic that
conforms to the policing rate and sets the dscp-transmit value to 5 for Group2 traffic that exceeds the
burst sizes.
Example 6-4
Configuring Single-Rate Two-Color Policing
Router(config)# policy-map Premium

Router(config-pmap)# class Group1
Router(config-pmap-c)# police 8000000 4000 6000 conform-action transmit exceed-action
set-prec-transmit 2
set-dscp-transmit 5
Router(config-subif)# service-policy input Premium
Configuration Example for Configuring Single-Rate Three-Color Policing

Example 6-5 shows how to configure single-rate three-color policing that includes actions for
conforming, exceeding, and violating traffic. In the example, policing is configured for the classes
named Bronze and Silver in the policy map named Policy_0. The router polices Bronze traffic at
4,000,000 bits per second and allows normal or committed bursts of 5000 bytes and excess bursts of 2000
bytes. The router transmits Bronze traffic that conforms to the policing rate, sets the precedence-transmit
value to 2 for Bronze traffic that exceeds the burst sizes, and drops Bronze traffic that violates the
policing rate. The router polices Silver traffic at 8,000,000 bits per second and allows committed bursts
of 6000 bytes and excess bursts of 4000 bytes. The router transmits Silver traffic that conforms to the
policing rate, drops Silver traffic that exceeds the burst sizes, and drops Silver traffic that violates the
policing rate.
Example 6-5
Configuring Single-Rate Three-Color Policing
Router(config)# policy-map Policy_0

Router(config-pmap-c)# set ip precedence 0
Router(config-pmap-c)# class Bronze
set-prec-transmit 2 violate-action drop
Router(config-pmap-c)# class Silver
violate-action drop
Router(config-atm-vc)# service-policy input Policy_0

OL-7433-09
6-29
Chapter 6
Policing Traffic
Configuration Example for Policing a Priority Service

Example 6-6 shows how to configure the police command for a priority service. In the example, the
priority class named Priority-Class is configured in the policy map named Gold. The router polices
Priority-Class traffic at 10200 bits per second and allows committed bursts of 1000 bytes and excess
bursts of 500 bytes. The router transmits Priority-Class traffic that conforms to the policing rate, drops
Priority-Class traffic that exceeds the burst sizes, and drops Priority-Class traffic that violates the
policing rate.
Example 6-6
Policing a Priority Service
Router(config)# policy-map Gold

Router(config-pmap)# class Priority-Class
violate-action drop
Configuration Example for Configuring Single-Rate Policing in a Hierarchical Policy

Example 6-7 shows how to configure a hierarchical policy named Parent-Policy and attach it to VLAN 2
(as indicated in the encapsulation dot1q 2 command) on the Gigabit Ethernet subinterface 1/0/0.1. In
the Parent-Policy class-default class, bandwidth is shaped to 512 kbps. The policy map named
Child-Policy is applied to the Parent-Policy. After the router shapes the bandwidth to 512 kbps as
indicated in class-default, the router then polices Group1 and Group2 traffic configured in the policy
map named Child-Policy. The router polices Group1 traffic at 12000 bits per second and allows
committed bursts of 500 bytes and excess bursts of 1000 bytes. The router polices Group2 traffic at 8000
bits per second and allows committed bursts of 4000 bytes and excess bursts of 2000 bytes. The router
performs three-color policing on both Group1 and Group2 traffic.
Example 6-7
Configuring Single-Rate Policing in a Hierarchical Policy
Router(config)# policy-map Child-Policy

set-qos-transmit 4 violate-action set-qos-transmit 4
Router(config-pmap-c)# class Group2
violate-action drop
Router(config-pmap)# policy-map Parent-Policy
Router(config-pmap-c)# shape 512000
Router(config-pmap-c)# service-policy Child-Policy
Router(config-atm-range)# service-policy output Parent-Policy
6-30
OL-7433-09
Chapter 6
Policing Traffic
Configuration Example for Policing PPPoE over ATM Sessions

Example 6-8 shows how to create a policy map named Group1 and associate it with a virtual template
interface named Virtual-Template 1. In the example, the router polices the Gold traffic at 8000 bits per
second and allows committed bursts of 4000 bytes and excess bursts of 2000 bytes. The router polices
the Bronze traffic at 5000 bits per second and allows committed bursts of 2000 bytes and excess bursts
of 1000 bytes. The router performs three-color policing on the Gold traffic and two-color policing on the
Bronze traffic.
When PPPoE sessions arrive on an interface, the protocol pppoe command configured on the interface
points to a broadband aggregation (BBA) group, which references a virtual template that the router uses
to create the virtual access interface (VAI) for the session. The router applies the QoS policy attached to
the virtual template to the session.
Example 6-8
Configuring Policing for PPPoE Sessions
Router(config)# policy-map Group1

Router(config-pmap)# class Gold
violate-action drop
!
Router(config)# bba-group PPPoE
Router(config-bba)# pppoe limit per-vc 200
Router(config-bba)# protocol pppoe
Router(config-bba)# Virtual-Template 1
!
Router(config)# interface Loopback0
Router(config-if)# ip address 192.168.1.1 255.255.255.0
!
Router(config)# interface atm 1/0/0.132 multipoint
Router(config-atm-vc)# pvc 1/33
Router(config-atm-vc)# encapsulation aal5snap
Router(config-atm-vc)# protocol pppoe group PPPoE
!
Router(config)# interface Virtual-Template 1
Router(config-if)# peer default ip address pool PPPoEpool
Router(config-if)# service-policy input Gold
!
Router(config)# ip local pool PPPoEpool 192.168.1.2 192.168.1.254

OL-7433-09
6-31
Chapter 6
Policing Traffic
Configuring Percent-Based Policing

To configure policing based on a percentage of the bandwidth available on an interface, enter the
Step 1
Command
Purpose
Specifies the name of the policy map and enters

policy-map configuration mode.
Step 2

define QoS actions.
Step 3
Router(config-pmap-c)# police [cir] percent

percent [bc] normal-burst-in-msec
[be] excess-burst-in-msec [conform-action action]
Configures traffic policing based on a percentage of

bandwidth available on an interface.
For more information, see the police percent Command
Configuration Examples for Configuring Percent-Based Policing

Configuration Example for Configuring Percent-Based Policing, page 6-32
Configuration Example for Configuring Percent-Based Two-Color Policing, page 6-33
Configuration Example for Configuring Percent-Based Three-Color Policing, page 6-33
Configuration Example for Configuring Percent-Based Policing in a Hierarchical Policy, page 6-34
Configuration Example for Percent-Based Policing of a Priority Service, page 6-34
Configuration Example for Configuring Percent-Based Policing

Example 6-9 shows how to configure percent-based policing. In the example, the class named Premium
is configured in the policy map named Test. The Premium class is a priority class with a queue depth of
32. The router allocates 5 percent of the committed rate to Premium traffic and allows burst sizes of 2 ms
for both committed and excess bursts.
Example 6-9
Configuration Example for Percent-Based Policing
Router(config)# policy-map Test

Router(config-pmap)# class Premium
Router(config-pmap-c)# police percent 5 2 ms 2 ms
6-32
OL-7433-09
Chapter 6
Policing Traffic
Configuration Example for Configuring Percent-Based Two-Color Policing

Example 6-10 shows how to configure two-color percent-based policing. In the example, policing is
configured for the classes named Voice and Test in the policy map named Premium. The router allocates
10 percent of the committed rate to voice traffic and allows burst sizes of 2 ms. The router transmits
Voice traffic that conforms to the committed rate and sets the precedence-transmit value to 2 for Voice
traffic that exceeds the burst sizes. The router allocates 5 percent of the committed rate to Test traffic
and allows committed bursts of 4 ms and excess bursts of 2 ms. The router transmits Test traffic that
conforms to the committed rate and drops Test traffic that exceeds the burst sizes.
Example 6-10 Configuring Percent-Based Two-Color Policing
Router(config-pmap)# class Voice
set-prec-transmit 2
Router(config-pmap-c)# class Test
drop
Router(config-subif)# service-policy input Premium
Configuration Example for Configuring Percent-Based Three-Color Policing

Example 6-11 shows how to configure three-color percent-based policing. In the example, policing is
configured for the class named Bronze in the policy map named Policy_0. The router allocates 10
percent of the committed rate to Bronze traffic and allows burst sizes of 2 ms. The router transmits
Bronze traffic that conforms to the committed rate, sets the precedence-transmit value to 2 for Bronze
traffic that exceeds the burst sizes, and drops Bronze traffic that violates the committed rate. For the
Silver class, the router polices Silver traffic at 8,000,000 bits per second and allows committed bursts of
4000 bytes and excess bursts of 6000 bytes. The router transmits Silver traffic that conforms to the
committed rate, sets the QoS transmit value to 4 for Silver traffic that exceeds the burst sizes, and drops
Silver traffic that violates the committed rate.
Example 6-11 Configuring Percent-Based Three-Color Policing
Router(config)# policy-map Policy_0
set-qos-transmit 4 violate-action drop
Router(config-if-atm-range)# service-policy input Policy_0

OL-7433-09
6-33
Chapter 6
Policing Traffic
Configuration Example for Configuring Percent-Based Policing in a Hierarchical Policy

Example 6-12 shows how to configure a hierarchical policy and attach it to PVC 5/101. The router first
shapes the bandwidth to 512000 bits per second as indicated in the Parent policy class-default class. The
router then polices the Bronze and Gold classes in the policy-map named Child. The router allocates
30 percent of the committed rate to the Bronze traffic and allows committed bursts of 6 ms and excess
bursts of 4 ms. The router transmits Bronze traffic that conforms to the committed rate and drops Bronze
traffic that exceeds the burst sizes. The router polices Gold traffic at 8000 bits per second and allows
committed bursts of 2000 bytes and excess bursts of 4000 bytes. The router transmits Gold traffic that
conforms to the committed rate and sets the QoS transmit value to 4 for traffic that exceeds burst sizes.
Example 6-12 Policing in a Hierarchical Policy
Router(config)# policy-map Child
Router(config-pmap)# class Bronze
drop
Router(config-pmap-c)# class Gold
set-qos-transmit 4
Router(config-pmap)# policy-map Parent
Router(config-pmap-c)# service-policy Child
!
Router(config-subif)# no atm pxf queuing
Router(config-if-atm-vc)# vbr-nrt 5000 2000
Router(config-if-atm-vc)# service-policy out Parent
Configuration Example for Percent-Based Policing of a Priority Service

Example 6-13 shows how to configure the police percent command for a priority service. In the
example, the priority class named Voice is configured in the policy map named New-Traffic. The router
allocates 25 percent of the committed rate to Voice traffic and allows committed bursts of 4 ms and
excess bursts of 1 ms. The router transmits Voice traffic that conforms to the committed rate, sets the
QoS transmit value to 4 for Voice traffic that exceeds the burst sizes, and drops Voice traffic that violates
the committed rate.
Example 6-13 Policing a Priority Service Using Percent-Based Policing
Router(config)# policy-map New-Traffic
set-qos-transmit 4 violate-action drop
6-34
OL-7433-09
Chapter 6
Policing Traffic
Configuring Two-Rate Policing

To configure policing based on a committed information rate (CIR) and a peak information rate (PIR),
Step 1
Command
Purpose

configuration mode.
Step 2
class-map-name is the name of a previously configured class map
and is the traffic class for which you want to define QoS actions.
Step 3
Router(config-pmap-c)# police {cir cir}

[bc] burst-normal [pir pir]
[be] peak-burst [conform-action action]
[exceed-action action] [violate-action
action]
Configures two-rate traffic policing by specifying both the

committed information rate (CIR) and the peak information rate
(PIR).
For more information, see the police Command (Two-Rate)
Configuration Example for Configuring Two-Rate Three-Color Policing

Example 6-14 shows how to configure two-rate three-color policing for the Premium traffic class in the
policy map named Business. In the example, the committed information rate (CIR) is 512 kbps and the
peak information rate (PIR) is 1 Mbps. Traffic that conforms to the CIR is sent as is. Traffic that exceeds
the CIR, but not the PIR is marked with IP precedence 4. Traffic that exceeds the PIR is dropped. The
burst parameters are set to 10,000 bytes.
Example 6-14 Configuring Two-Rate Three-Color Policing
Router(config)# class-map match-all Premium
Router(config-pmap-c)# police cir 512000 bc 10000 pir 1000000 be 10000 conform-action
transmit exceed-action set-prec-transmit 4 violate-action drop
Router(config-if)# service-policy output Business

OL-7433-09
6-35
Chapter 6
Policing Traffic
Marking Traffic Using Police Actions

To mark traffic using police actions, enter the following commands beginning in global configuration
mode:
Step 1
Command
Purpose

configuration mode.
Step 2
Step 3

[be] peak-burst [conform-action action]
action]
Configures traffic policing and optionally configures the policing

action for conforming, exceeding, or violating traffic.
action specifies the policing action, such as set-clp-transmit,
set-frde-transmit, set-cos-transmit, or set-cos-inner-transmit.
Valid values for these actions are 0 to 7. For more information
about the actions you can specify, see Table 6-1 on page 6-3.
Configuration Example for Marking Traffic Using Police Actions

Example 6-15 shows how to configure conform, exceed, and violate actions in the police command. In
the example configuration, traffic is policed at 8000 bps with the normal burst size set to 2000 bytes and
the peak burst size set to 1000 bytes. Traffic whose rate is less than the conform burst rate has the CLP
bit set to 1; traffic whose rate is within the conform and conform plus exceed burst rate has the CoS bits
set to 3; and traffic whose rate is higher than the conform plus exceed rate has the CoS bits also set to 3.
Example 6-15 Marking Traffic Using Police Actions
Router(config)# policy-map policy1
Router(config-pmap-c)# police 8000 2000 1000 conform-action set-clp-transmit exceed-action
set-cos 3 violate-action set-cos 3
6-36
OL-7433-09
Chapter 6
Policing Traffic
Configuring Dual Police Actions

To configure dual police actions for conform, exceed, and violate actions, enter the following commands
Step 1
Command
Purpose

configuration mode.
Step 2
Step 3

[be] peak-burst conform-action action
Configures traffic policing and specifies the first conform action.

Valid combinations of dual actions are:
Step 4
Router(config-pmap-c-police)#
Configures the second conform action.
Step 5
Configures the first exceed action.
Step 6
Configures the second exceed action.
Step 7
Configures the first violate action.
Step 8
Configures the second violate action.
Configuration Example for Configuring Dual Police Actions

Example 6-16 shows how to configure the dual police actions set-clp-transmit and
set-mpls-exp-imposition-transmit. The example configures set-clp-transmit and set-mpls-exp-transmit
as the conform action and set-clp-transmit and set-mpls-exp-transmit as the exceed and violate actions.
Example 6-16 Configuring Dual Police Actions
Router(config)# policy-map clp
Router(config-pmap-c) police 100000 100 10 conform-action set-clp-transmit
Router(config-pmap-c-police)# conform-action set-mpls-exp-transmit 1
Router(config-pmap-c-police)# exceed-action set-clp-transmit
Router(config-pmap-c-police)# exceed-action set-mpls-exp-transmit 2
Router(config-pmap-c-police)# violate-action set-clp-transmit
Router(config-pmap-c-police)# violate-action set-mpls-exp-transmit 3
Router(config-pmap-c-police)# end
Router#

OL-7433-09
6-37
Chapter 6
Policing Traffic
Configuration Example for Dual Actionsset-clp-transmit and set-mpls-exp-transmit, page 6-38
Configuration Example for Dual Actionsset-frde-transmit and set-mpls-exp-imposition-transmit,

page 6-39
Configuration Example of the set-cos-transmit Police Action, page 6-40
Configuration Example for Dual Actionsset-clp-transmit and

set-mpls-exp-transmit
The following example shows how to configure set-clp-transmit and set-mpls-exp-transmit as the
conform action and set-clp-transmit and set-mpls-exp-transmit as the exceed and violate actions:
policy-map clp
class class-default
police 100000 100 10 conform-action set-clp-transmit
conform-action set-mpls-exp-transmit 1
exceed-action set-clp-transmit
exceed-action set-mpls-exp-transmit 2
violate-action set-clp-transmit
violate-action set-mpls-exp-transmit 3
The following shows sample output from the show policy-map command:
Router# show policy-map clp
Policy Map clp
Class class-default
police 104000 100 10
conform-action set-clp-transmit
The following shows sample output from the show running-config command beginning at the point
where clp is specified:
Router# show running-config | begin clp
|show running-config begin clp
class class-default
police 104000 100 10
If the policy map is attached to an ATM PVC that is configured for Layer 2 VPN, the output from the
show policy-map interface command displays the following information:
Router# show policy-map interface atm4/0/0.1
ATM4/0/0.1: VC 1/100 Service-policy input: clp
6-38
OL-7433-09
Chapter 6
Policing Traffic

0 packets, 0 bytes
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
Police:
conformed 0 packets, 0 bytes; action:
set-clp-transmit
set-mpls-exp-transmit 1
exceeded 0 packets, 0 bytes; action:
set-clp-transmit
violated 0 packets, 0 bytes; action:
set-clp-transmit
Configuration Example for Dual Actionsset-frde-transmit and

The following example shows how to configure set-frde-transmit and set-mpls-exp-imposition-transmit
as the conform action and set-frde-transmit and set-mpls-exp-imposition-transmit as the exceed and
violate actions.
policy-map frde
class class-default
police 100000 100 10 conform-action set-frde-transmit
conform-action set-mpls-exp-imposition-transmit 1
exceed-action set-frde-transmit
exceed-action set-mpls-exp-imposition-transmit 2
violate-action set-frde-transmit
violate-action set-mpls-exp-imposition-transmit 3
The following shows sample output from the show policy-map command:
Router# show policy-map frde
Policy Map frde
Class class-default
police 104000 100 10
conform-action set-frde-transmit
The following shows sample output from the show running-config command:
Router# show running-config | begin frde
|show running-config begin frde
class class-default
police 104000 100 10
conform-action set-frde-transmit

OL-7433-09
6-39
Chapter 6
Policing Traffic
If the policy map is attached to Frame Relay DLCI 101 that is configured for Layer 2 VPN, the output
from the show policy-map interface command displays the following information:
Router# show policy-map serial4/0/0.1
Serial4/0/0.1: DLCI 101 Service-policy input: frde
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
Police:
set-frde-transmit
set-mpls-exp-imposition-transmit 1
set-frde-transmit
set-frde-transmit
Configuration Example of the set-cos-transmit Police Action

The following example shows how to configure the set-cos-transmit police action on the PRE2. In the
example, the traffic class group2 is policed at 20000 bps with a normal burst of 100 bytes. Traffic that
conforms to the rate is transmitted; traffic that exceeds the rate has the CoS bits set to 3; and traffic that
violates the rate has the CoS bits set to 4.
policy-map police
class group2
police 20000 100 0 conform-action transmit exceed-action set-cos-transmit 3
violate-action set-cos-transmit 4
The following example shows sample output from the show running-config command for a 2-level
hierarchical policy that is configured with the set-cos-transmit action on the PRE2:
policy-map in-parent
class class-default
police percent 85 1000 ms 2000 ms conform-action transmit exceed-action drop
violate-action drop
service-policy in-child
policy-map in-child
class c0
priority
police 1000000 20000 30000 conform-action set-cos-transmit
set-cos-transmit 0 violate-action set-cos-transmit 0
class c1
class c2
class c3
0 exceed-action
1 exceed-action
2 exceed-action
3 exceed-action
6-40
OL-7433-09
Chapter 6
Policing Traffic
Verifying and Monitoring Traffic Policing
class c4
police 1000000 20000 30000 conform-action set-cos-transmit 4 exceed-action
class class-default
police 1000000 20000 30000 conform-action set-cos-transmit 5 exceed-action
On the PRE3, output from the show running-config command is the same as the above sample output,
except that the priority command configured in class c0 displays as priority level level-number.
On the PRE2 and PRE3, the show policy-map interface commands displays the set-cos-transmit action
and corresponding value when configured as a police action in a policy map.

The Cisco 10000 series router collects information about the number of conforming, exceeding, and
violating packets and bytes.
To verify and monitor traffic policing, enter any of the following commands in privileged EXEC mode:
Command
Purpose
Displays statistical and configuration information about all of the

configured policy maps.

policy map you specify.

input and output policy maps attached to the interface you
specify.
For Cisco IOS Release 12.2(33)SB and later releases, if the
policy map attached to an interface has the police command
configured in it, the output from the show policy-map interface
command displays the police actions in a new line.
Verification Examples for Traffic Policing

This section provides the following verification examples:
Verifying Policing for a Specific Traffic Class, page 6-42
Verifying Policing on a Specific Interface, page 6-42
Verifying Dual Police Actionsset-clp-transmit and set-mpls-exp-transmit, page 6-43

OL-7433-09
6-41
Chapter 6
Policing Traffic
Verifying Policing for a Specific Traffic Class

The following example shows how to verify policing for a specific traffic class in a policy map. In this
example, the Bronze class in the Child policy map is policed at 30 percent of the available bandwidth.
The committed burst is 6 ms and the excess burst is 4 ms.
Router# show policy-map Child class Bronze
Class Bronze
set dscp 3
Verifying Policing on a Specific Interface

The following example uses the show policy-map interface command to verify traffic policing on the
ATM 3/0/0.3 subinterface. The QoS policy attached to PVC 5/101 on ATM subinterface 3/0/0.3 is a
hierarchical policy that consists of a Parent policy and a Child policy. The Bronze class is policed at
600,000 bps and the Gold class is policed at 8000 bps.
ATM3/0/0.3: VC 5/101 Service-policy output: Parent
0 packets, 0 bytes
Match: any
Shape : 2000 kbps
Service-policy : Child
Class-map: Bronze (match-all)
0 packets, 0 bytes
Police:
exceeded 0 packets, 0 bytes; action: set-prec-transmit 2
Class-map: Gold (match-all)
0 packets, 0 bytes
Police:
exceeded 0 packets, 0 bytes; action: set-qos-transmit 4
0 packets, 0 bytes
Match: any
6-42
OL-7433-09
Chapter 6
Policing Traffic
Verifying Dual Police Actionsset-clp-transmit and set-mpls-exp-transmit

The following shows sample output from the show policy-map command on the PRE3 and PRE4. In the
example, the class-default class is configured for dual police actions: set-clp-transmit and
set-mpls-exp-transmit.
Router# show policy-map clp
Policy Map clp
Class class-default
police 104000 100 10
Feature
Control Plane Policing feature module, Release 12.2(31)SB2
DiffServ

Release 12.3
Part 7: Quality of Service Solutions > Implementing DiffServ
for End-to-End Quality of Service Overview
Policing
Comparing Traffic Policing and Traffic Shaping for Bandwidth

Limiting
Release 12.2
Quality of Service Overview > Policing and Shaping
Single-rate policer
RFC 2697, A Single Rate Three Color Marker

Release 12.2
Part 4: Policing and Shaping > Policing and Shaping Overview
Three-color marker for traffic policing (single-rate)
Release Notes for the Cisco 10000 Series ESR for Cisco IOS
Release 12.0(23)SX
New Features in Cisco IOS Release 12.0(23)SX > Single-Rate
3-Color Marker for Traffic Policing
RFC 2697, A Single Rate Three Color Marker

OL-7433-09
6-43
Chapter 6
Policing Traffic
Feature
Token bucket

Release 12.2
Part 4: Policing and Shaping > Policing and Shaping Overview
> What Is a Token Bucket?
Two-rate policer three-color marker
RFC 2698, A Two Rate Three Color Marker

Two-Rate Policer, Release 12.2(4)T3 feature module
6-44
OL-7433-09
CH A P T E R
Marking Traffic
To service the growing numbers of customers and their needs, service provider networks have become
more complex and often include both Layer 2 and Layer 3 network devices. With this continued growth,
service providers must quickly identify the packets streaming across the network and apply the
appropriate service behavior before sending them to their destinations.
A differentiated service (DiffServ) model enables you to classify packets based on traffic classes. In this
model, traffic marking allows you to partition your network into multiple priority levels or classes of
service. By marking traffic, other network devices along the forwarding path can quickly determine the
proper class of service (CoS) to apply to a traffic flow.
An important aspect of DiffServ is that the markings must be consistently interpreted from end-to-end.
All devices in the network path must understand the per-hop behavior to apply to a specific class of
traffic. If one of the routers in the path does not act appropriately, the overall service for a particular
packet might not be as desired.
This chapter describes the marking capabilities of the Cisco 10000 series router. It includes the following
topics:
QoS Packet Marking, page 7-2
IP Precedence Marking, page 7-4
IP Differentiated Services Code Point Marking, page 7-6
Class of Service Marking, page 7-10
QoS Group Marking, page 7-13
ATM Cell Loss Priority Marking, page 7-14
MPLS Experimental Marking, page 7-14
Discard-Class Marking, page 7-16
Class-Based Frame Relay DE Bit Marking, page 7-17
Marking and Policing Traffic, page 7-18
Tunnel Header Marking, page 7-18
Restrictions and Limitations for Marking, page 7-19
Restrictions and Limitations for Marking, page 7-19
Interfaces Supporting Marking, page 7-20
Classification and Marking Design Guidelines, page 7-21
Recommended Values for Traffic Marking, page 7-21
Configuring Traffic Marking, page 7-22

OL-7433-09
7-1
Chapter 7
Marking Traffic
QoS Packet Marking
Verifying Traffic Marking, page 7-37
QoS Packet Marking

QoS packet marking is a QoS tool used to differentiate packets based on designated markings. Using
marking, you can partition your network into multiple priority levels or classes of service. Marking
simplifies the network Qos design and QoS tools configuration, and reduces the overhead of packet
classification by other QoS tools.
You can configure QoS packet marking on a main interface, subinterface, or an individual virtual
circuit (VC). Traffic marking involves setting bits inside frame, packet, or cell header fields that are
specifically designed for QoS marking. Other devices can examine the marked bits and classify traffic
based on the marked values.
Table 7-1 summarizes the mechanisms you can use to mark packets. The internal mechanisms affect only
the Cisco 10000 series routers behavior; internal marks are not passed on to other routers.
Table 7-1
Traffic Marking Actions
Action
Description
Layer
Section Reference
atm-clp
Sets the ATM cell loss priority 2

(CLP) bit to 1.
ATM Cell Loss Priority

Marking, page 7-14
cos
Sets the IEEE 802.1Q class of 2

service bits in the user priority
field.
Class of Service Marking,

page 7-10
discard-class
Marks a packet with the

discard-class value that you
specify, which indicates the
drop eligibility of a packet.
Internal
Discard-Class Marking,
page 7-16
dscp
Marks a packet with the

differentiated services code
point (DSCP) you specify.
IP Differentiated Services
Code Point Marking,
page 7-6
mpls experimental
imposition
Sets the value of the MPLS

experimental (EXP) field on
all imposed label entries.
MPLS Experimental
Marking, page 7-14
ip precedence
Marks a packet with the IP

precedence level you specify.
IP Precedence Marking,
page 7-4
qos-group
Marks a packet with the QoS

group identifier you specify.
Internal
QoS Group Marking,

page 7-13
7-2
OL-7433-09
Chapter 7
Marking Traffic
QoS Packet Marking
Feature History for QoS Packet Marking

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The marking feature was introduced on the router.
PRE1
Release 12.0(22)S
This feature was enhanced to support MPLS experimental PRE1

marking.
Release 12.2(16)BX
This feature was introduced on the PRE2 and enhanced to PRE2

support 802.1Q class of service marking.
Release 12.3(7)XI1
This feature was enhanced on the PRE2 to support MPLS PRE2

experimental marking on all imposed label entries and
discard-class marking.
Release 12.2(28)SB

Release 12.2(31)SB2
This feature was introduced on the PRE3 for class of

PRE3
service marking. Enhancements to the modular QoS CLI
allow you to mark the IP DSCP bits of traffic on the L2TP
access concentrator (LAC). The Class-Based Frame Relay
DE Bit Marking and Tunnel Header Marking features were
also introduced on the PRE3.
Release 12.2(33)SB
This feature was enhanced to support Class-Based Frame

Relay DE Bit Marking on the PRE4.
PRE2
PRE3, PRE4
Benefits of QoS Packet Marking

Network Partitioning and Categorizing
Packet marking allows you to partition your network into multiple priority levels or classes of service.
Layer 2 to Layer 3 Mapping
If a packet that needs to be marked to differentiate user-defined QoS services is leaving the router and
entering a switch, the router can set the class of service (CoS) value of the packet because the switch can
process the Layer 2 CoS header marking.
Weighted Random Early Detection Configuration
Weighted random early detection (WRED) uses IP precedence values or IP DSCP values to determine
the drop probability of a packet. Therefore, you can use the IP precedence and IP DSCP markings with
the WRED feature.
Improved Bandwidth Management in ATM Networks
The ability to set the ATM CLP bit allows you to extend your 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.

OL-7433-09
7-3
Chapter 7
Marking Traffic
IP Precedence Marking
You can mark the importance of a packet by using the IP precedence marking mechanism. IP precedence
marking helps to do the following:
Manage congestionIP precedence field is used to determine how to schedule packets.
Avoid congestionIP precedence field is used to determine how to handle packets when
packet-dropping mechanisms, such as weighted random early detection (WRED), are configured.
Police trafficNetworking devices within the network can use IP precedence values to determine
how to handle inbound traffic based on the transmission rate.
Layer 2 media often changes as packets traverse from source to destination. A more ubiquitous marking
can occur at Layer 3, using the IP type of service (ToS) byte. The ToS byte is the second byte in an IPv4
packet. The first three bits of the ToS byte are the IP precedence bits, which enable you to set eight IP
precedence markings (0 through 7).
Table 7-2 lists the 8 different IP precedence markings defined in RFC 791. Notice that IP precedence 6
and 7 are used for network control. Do not use IP precedence 6 or 7 to mark packets, unless you are
marking control packets.
Table 7-2
IP Precedence Values
Precedence Value
Precedence Name
Binary Value
Recommended Use
Routine
000
Default marking value
Priority
001
Data applications
Immediate
010
Flash
011
Call signaling
Flash Override
100
Video conferencing and

streaming video
Critic
101
Voice
Internetwork Control
110
Network Control
111
Network control traffic (such

as routing, which is typically
precedence 6)
You can configure a QoS policy to include IP precedence marking for packets entering the network.
Devices within your network can then use the newly marked IP precedence values to determine how to
treat the packets. For example, class-based weighted random early detection (WRED) uses IP
precedence values to determine the probability that a packet is dropped. You can also mark voice packets
with a particular precedence. You can then configure low-latency queuing (LLQ) to place all packets of
that precedence into the priority queue.
IP Precedence-Based Weighted Random Early Detection

When you configure IP precedence-based weighted random early detection (WRED) on an output policy
map and the outgoing packets are MPLS packets, the router drops the MPLS packets based on the three
experimental (EXP) bits in the MPLS label, instead of using the 3-bit IP precedence field in the
underlying IP packets.
7-4
OL-7433-09
Chapter 7
Marking Traffic
set ip precedence Command

To set the precedence value in a packet header, use the set ip precedence command in policy-map class
configuration mode. To remove the precedence value, use the no form of this command. By default, this
command is disabled.
set ip precedence prec-value
no set ip precedence prec-value
Syntax Description
ip
Specifies that the match is for IPv4 packets only. You must specify this
keyword.
precedence prec-value
Sets the precedence value. Valid values are from 0 to 7.
set ip precedence Command History

Cisco IOS Release
Description
Release 12.0(17)SL
The set ip precedence command was introduced on the PRE1.
Release 12.2(16)BX
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Release 12.2(33)SB
Usage Guidelines for the set ip precedence Command

Bit Settings
After the precedence bits are set, other quality of service (QoS) features such as weighted fair queuing
(WFQ) and weighted random early detection (WRED) can then operate on the bit settings.
Precedence Value
The network can give priority (or some type of expedited handling) to marked traffic through the
application of weighted fair queuing (WFQ) or weighted random early detection (WRED) at points
downstream in the network. Typically, you set the precedence value at the edge of the network (or
administrative domain); data then is queued according to the specified precedence. WFQ can speed up
handling for certain precedence traffic at congestion points. WRED can ensure that certain precedence
traffic has lower loss rates than other traffic during times of congestion.
In Cisco IOS Release 12.3(7)XI, the router accepts the set precedence command without specifying the
ip keyword. However, you must specify the set ip precedence command to set the precedence value in
a packet header.

OL-7433-09
7-5
Chapter 7
Marking Traffic
IP Differentiated Services Code Point Marking

IP precedence marking might seem too restrictive and limiting because only eight classes are available
for marking. You might choose instead to use the IP differentiated services code point (DSCP) marking
model, which offers up to 64 different values (0 through 63).
The differentiated services (DiffServ) functionality of the Cisco IOS software is fully compliant with the
Internet Engineering Task Force (IETF) standards defined in the following request for comments (RFCs)
documents:
RFC-2474
RFC-2475
RFC-2597
RFC-2598
The router leverages the IETF definition of the IPv4 1-byte type of service (ToS) field in the IP packet
header by using the six most significant bits of this field (the DSCP bits) to classify traffic into any of
the 64 possible classes. After the router classifies packets, you can use the modular QoS CLI to
implement IETF-defined per-hop behaviors (PHBs), including assured forwarding (AF) and expedited
forwarding (EF).
The router also uses bits in the ToS field to prioritize packets using an IP precedence value. Because the
IP precedence value is actually part of the DSCP value, you cannot simultaneously set both the IP
precedence and DSCP values. If you attempt to, an error message displays.
Figure 7-1 shows the DSCP bits in the ToS field.
Figure 7-1
VER
DSCP Bits in the IP ToS Byte
HL
TOS
LEN
ID
FLAG
OFFSET
TTL
PROTO
CS
SIP
DIP
DSCP
87065
7 6 5 4 3 2 1 0 1-Byte TOS
DSCP Per-Hop Behavior

You can enter DSCP values as numeric values or as special keyword names called per-hop behaviors
(PHBs). For example, DSCP EF is the same as DSCP 46 and DSCP AF31 is the same as DSCP 26.
The router supports the following classes of DSCP PHBs:
Best effort (BE)DSCP 0
Assured forwarding (AF)AF classes 1 through 4
Expedited forwarding (EF)DSCP 46
Class selector code pointsCS1 through CS7
7-6
OL-7433-09
Chapter 7
Marking Traffic
Again, vendor-specific mechanisms need to be configured to implement these PHBs. For more
information about EF PHB, see RFC-2598. To implement the PHBs, you must configure vendor-specific
mechanisms. For more information, see the appropriate RFC as indicated in Table 7-4 on page 7-8.
Assured Forwarding
There are four assured forwarding (AF) classes, AF1x through AF4x. The first number corresponds to
the AF class and the second number (x) refers to the level of drop preference within each AF class. There
are three drop probabilities, ranging from 1 (low drop) through 3 (high drop). Depending on a network
policy, packets can be selected for a PHB based on required throughput, delay, jitter, loss, or according
to the priority of access to network services. AF allows for a committed information rate between
multiple classes in a network according to desired policies.
Table 7-3 provides the DSCP coding and drop probability for AF classes 1 through 4. Bits 0, 1, and 2
define the class; bits 3 and 4 specify the drop probability; bit 5 is always 0.
Table 7-3
Assured Forwarding DSCP Code Points
Drop Probability
Class 1
Class 2
Class 3
Class4
Low Drop
001010
010010
011010
100010
AF11
AF21
AF31
AF41
DSCP 10
DSCP 18
DSCP 26
DSCP 34
001100
010100
011100
100100
AF12
AF 22
AF32
AF42
DSCP 12
DSCP 20
DSCP 28
DSCP 36
001110
010110
011110
100110
AF13
AF23
AF33
AF43
DSCP 14
DSCP 22
DSCP 30
DSCP 38
Medium Drop
High Drop
Expedited Forwarding
The expedited forwarding (EF) PHB is used to build a low-loss, low-latency, low-jitter, assured
bandwidth, end-to-end service through differentiated services (DiffServ) domains. This PHB appears to
the endpoints like a point-to-point connection or a virtual leased line. EF PHB, also referred to as a
premium service, is suitable for applications such as Voice over IP (VoIP).
The recommended code point for the EF PHB is 101110.
Class Selector Code Points

The router also supports class selector (CS) code points, which is a way of marking the six DSCP bits
so that the code points are identical to IP precedence values. These code points can be used with systems
that only support the IP precedence. The CS code points have the form xyz000, where x, y, and z represent
a 1 or 0.
For more information, see the appropriate RFC as indicated in Table 7-4 on page 7-8.

OL-7433-09
7-7
Chapter 7
Marking Traffic
DSCP Values
The following differentiated services (DiffServ) RFCs define DSCP values:
RFC-2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC-2475, An Architecture for Differentiated Services
RFC-2597, Assured Forwarding PHB Group
RFC-2598, An Expedited Forwarding PHB
The RFCs do not dictate the way to implement PHBs; this is the responsibility of the vendor. Cisco
implements queuing techniques that can base their PHB on the IP precedence or DSCP value in the IP
header of a packet. Based on DSCP or IP precedence, traffic can be put into a particular service class.
Packets within a service class are treated the same way.
Table 7-4 lists only the DSCP values suggested by the DiffServ RFCs.
Table 7-4
DSCP Values
DSCP Value
DSCP Name
Binary Value
Defined in RFC
Best Effort or Default
000000
2475
CS1
001000
16
CS2
010000
24
CS3
011000
32
CS4
100000
40
CS5
101000
48
CS6
110000
56
CS7
111000
10
AF11
001010
12
AF12
001100
14
AF13
001110
18
AF21
010010
20
AF22
010100
22
AF23
010110
26
AF31
011010
28
AF32
011100
30
AF33
011110
34
AF41
100010
36
AF42
100100
38
AF43
100110
46
EF
101110
2597
2598
7-8
OL-7433-09
Chapter 7
Marking Traffic
You can configure a QoS policy to include an IP DSCP marking for packets entering the network.
Devices within your network can then use the newly marked IP DSCP values to determine how to treat
the packets. For example, class-based weighted random early detection (WRED) uses IP DSCP values
to determine the probability that a packet is dropped. You can also mark voice packets with a particular
DSCP value. You can then configure low-latency queuing (LLQ) to place all packets of that DSCP value
into the priority queue.
DSCP-Based Weighted Random Early Detection

When you configure DSCP-based weighted random early detection (WRED) on an output policy map
and the outgoing packets are MPLS packets, the router drops the MPLS packets based on the three
experimental (EXP) bits in the MPLS label, instead of using the 6-bit DSCP field in the underlying IP
packets. The router shifts the three EXP bits to the left to make it six bits. For example, if the value of
the EXP bits is 5 (binary 101), the router left-shifts the bits to make them binary 101000, thus making it
look like a 6-bit DSCP field. The router drops packets based on the shifted binary value.
set ip dscp Command

To mark a packet by setting the differentiated services code point (DSCP) value in the type of
service (ToS) byte, use the set ip dscp command in policy-map class configuration mode. To remove a
previously set DSCP value, use the no form of this command. By default, no packets are marked.
set ip dscp {dscp-value | afxy | csx | ef | default}
no set ip dscp {dscp-value | afxy | csx | ef | default}
Syntax Description
ip
Specifies that the match is for IPv4 packets only. You must specify this
keyword.
dscp dscp-value
Sets the DSCP value. Valid values are from 0 to 63.

Instead of specifying a numeric dscp-value, you can specify one of the
afxy indicates assured forwarding.
csx indicates class selector code points that are backward-compatible

with IP precedence. These code points (CS1 through CS7) are identical
to IP precedence values 1 through 7.

OL-7433-09
7-9
Chapter 7
Marking Traffic
Class of Service Marking
set ip dscp Command History

Cisco IOS Release
Description
Release 12.0(17)SL
Release 12.2(16)BX
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
This command was introduced on the PRE3 to allow you to mark the IP
DSCP bits of traffic on the L2TP access concentrator (LAC).
Release 12.2(33)SB
Usage Guidelines for the set ip dscp Command
After the DSCP bit is set, other quality of service (QoS) features can then operate on the bit settings.
You cannot use the set ip dscp command with the set ip precedence command to mark the same
packet. DSCP and precedence values are mutually exclusive. A packet can have one value or the
other, but not both.
The network can give priority (or some type of expedited handling) to marked traffic. Typically, you
set the precedence value at the edge of the network (or administrative domain); data is then queued
according to the precedence. Weighted fair queuing (WFQ) can speed up handling for
high-precedence traffic at congestion points. Weighted random early detection (WRED) can ensure
that high-precedence traffic has lower loss rates than other traffic during times of congestion.
In Cisco IOS Release 12.3(7)XI, the router accepts the set dscp command without specifying the
ip keyword. However, you must specify the set ip dscp command to set the DSCP value in a packet
header. The ip keyword is required.

Class of service (CoS) marking enables the Cisco 10000 series router to interoperate with switches to
deliver end-to-end QoS. The IEEE 802.1p standard enables the router to:
Classify inbound Ethernet packets based on the value in the CoS field
Set the value in the CoS field of outbound packets
For Layer 2 devices, you can assign priority-indexed IEEE 802.1p CoS values to Ethernet frames.
Layer 2 IEEE 802.1Q frame headers have a 2-byte Tag Control Information field in the 802.1p portion
of the header. The three most-significant bits of this field (the User Priority bits) make up the Layer 2
CoS field. This 3-bit field allows you to mark eight classes of service (0 through 7) on Layer 2 Ethernet
frames. Other QoS tools can then use the CoS marking to classify traffic. For IEEE 802.1Q, the User
Priority bits are set to zero (0) in the Ethernet header.
Figure 7-2 shows the PRI field containing the 3-bit User Priority field.
7-10
OL-7433-09
Chapter 7
Marking Traffic
Figure 7-2
User Priority Bits in the IEEE 802.1p Header
4 bytes
DA
SA
EtherType/Tag header
EtherType = 0x8100 PRI
CFI
LEN/TYPE
DATA PAD FCS
VLAN ID
87064
PRE
COS
For CoS-based QoS, the Cisco 10000 series router uses the IP precedence bits in the IP header to give
preference to higher-priority traffic. Layer 3 IP headers have a 1-byte Type of Service (ToS) field. The
router uses the six most significant bits of this field (the differentiated services code point (DSCP) bits)
to prioritize traffic. Figure 5-3 shows the DSCP bits in the TOS field.
Figure 7-3
VER
DSCP Bits in the IP ToS Byte
HL
TOS
LEN
ID
FLAG
OFFSET
TTL
PROTO
CS
SIP
DIP
DSCP
87065
7 6 5 4 3 2 1 0 1-Byte TOS
The router uses the CoS value to determine how to prioritize packets for transmission and can also use
CoS marking to perform Layer 2 to Layer 3 mapping. Using the CoS field, you can differentiate
user-defined QoS services for packets leaving a router and entering a switch. Switches already have the
ability to match and set CoS values; therefore, a router can set the CoS value of a packet to enable
Layer 2 to Layer 3 mapping. The switch can then process the Layer 2 CoS header marking.
To allow the Cisco 10000 series router to interoperate with Layer 2 devices, CoS-based QoS on the router
allows the 802.1p User Priority bits to be mapped to the IP DSCP bits for packets received on inbound
interfaces. The DSCP bits are mapped to the User Priority bits for packets forwarded from outbound
interfaces.
In the inbound direction, you can configure the router to match on the CoS bits and then perform an
action (such as setting the IP precedence or DSCP bits). By default, the router ignores the CoS field of
inbound packets.
In the outbound direction, you can configure the router to set the CoS bits of outbound packets to a value
that you specify. If you do not do this, by default, the router ignores the CoS field and leaves it set to a
default value.

OL-7433-09
7-11
Chapter 7
Marking Traffic
QinQ Class of Service Marking

For EXP-to-CoS mapping in QinQ configurations, the parallel express forwarding (PXF) engine marks
both the inner and outer CoS bits.
For CoS-to-EXP mapping in QinQ configurations, the PXF engine looks at the CoS bits in the outer
dot1q header to determine how to mark the EXP bits.
set cos Command

To set the Layer 2 class of service (CoS) value of an outgoing packet, use the set cos command in
policy-map class configuration mode. To remove a specific CoS value setting, use the no form of this
command. By default, this command is disabled.
set cos cos-value
no set cos cos-value
Syntax Description
cos-value
Is a specific IEEE 802.1Q CoS value from 0 to 7.
set cos Command History

Cisco IOS Release
Description
Release 12.0(16)BX
This command was introduced on the PRE2 only.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
This command was integrated in Cisco IOS Release 12.2(31)SB2 for the
PRE3.
Release 12.2(33)SB
Usage Guidelines for the set cos Command

The set cos command allows switches and routers to interoperate. By configuring the router to match
packets based on the CoS value (using the match cos command) and to set CoS values, you can configure
Layer 2 to Layer 3 mapping. If a packet that needs to be marked to differentiate user-defined QoS
services is leaving a router and entering a switch, the router can set the CoS value of the packet because
the switch can process the Layer 2 header.
Use the set cos command only in service policies that are attached in the output direction of an interface;
packets entering an interface cannot be set with a CoS value. You can configure a CoS value on an
Ethernet interface that is configured for 802.1Q or on a virtual access interface that is using an 802.1Q
interface.
7-12
OL-7433-09
Chapter 7
Marking Traffic
QoS Group Marking
QoS Group Marking

You can use QoS group marking to assign packets to a QoS group. The QoS group field is an internal
marking that exists only within the router. You can set this field as packets pass through the fabric of the
router. The router uses the group ID marking to determine how to prioritize packets for transmission.
QoS groups are used as part of QoS policy propagation through the Border Gateway Protocol (QPPB)
and are useful in configurations that support MPLS QoS tunneling modes: short pipe, long pipe, and
uniform pipe.
You can set up to 100 different QoS group markings.
set qos-group Command

To set a quality of service (QoS) group identifier (ID) that can be used later to classify packets, use the
set qos-group command in policy-map class configuration mode. To remove the group ID, use the no
form of this command. By default, this command is disabled; no group ID is specified.
set qos-group group-id
no set qos-group group-id
Syntax Description
group-id
Is the group identifier. Valid values are from 0 to 99.
set qos-group Command History

Cisco IOS Release
Description
Release 12.0(17)SL
Release 12.2(16)BX
Release 12.2(28)SB
PRE2.
Usage Guidelines for the set qos-group Command

The set qos-group command allows you to associate a group ID with a packet. The group ID can be used
later to classify packets into QoS groups as part of QoS policy propagation through the Border Gateway
Protocol (QPPB). QoS groups are also useful in configurations supporting MPLS QoS tunneling modes:
short pipe, long pipe, and uniform pipe.
A QoS group and discard class are required when the input per-hop behavior (PHB) marking is used for
classifying packets on the output interface

OL-7433-09
7-13
Chapter 7
Marking Traffic
ATM Cell Loss Priority Marking

You can change the cell loss priority (CLP) bit setting in an ATM header of a cell to control the
discarding of cells in congested ATM environments. As congestion occurs in the ATM network, the ATM
network switch can discard cells with the CLP bit set to 1 (discard) before discarding cells with a CLP
bit setting of 0.
You can set ATM CLP marking only on outbound packets. The Cisco 10000 series router does not
support CLP bit matching.
set atm-clp Command

To set the cell loss priority (CLP) bit to 1, use the set atm-clp command in policy-map class
configuration mode. To change the CLP bit setting back to 0, use the no form of the command. By
default, the CLP bit automatically sets to 0 when the router sends packets as ATM cells.
set atm-clp
no set atm-clp
set atm-clp Command History

Cisco IOS Release
Description
Release 12.0(17)SL
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Release 12.2(33)SB
Usage Guidelines for the set atm-clp Command

You can attach a policy map containing the set atm-clp command only as an output policy. The
set atm-clp command does not support packets that originate from the router.
To disable this command, remove the service policy from the interface by using the no service-policy
command.
The router discards packets with the CLP bit set to 1 before it discards packets with the CLP bit set to 0.
MPLS Experimental Marking

The Multiprotocol Layer Switching (MPLS) experimental (EXP) field is a 3-bit field within the MPLS
label that is used in QoS marking. By default, the IP precedence field in the underlying IP packet is
copied to the MPLS EXP field during label imposition. Using the MPLS EXP field does not modify the
DSCP or IP precedence markings in the packet IP header.
The MPLS EXP field allows up to eight different QoS markings that correspond to the eight possible IP
precedence values. For more information, see Table 7-2 on page 7-4.
7-14
OL-7433-09
Chapter 7
Marking Traffic
The value of the EXP bits determines the per-hop behavior (PHB) for MPLS nodes and is also used as
transparency mechanisms when used with MPLS DiffServ tunneling modes such as pipe and uniform
modes. IP marking does not modify an MPLS packet carrying IP data. You must configure MPLS
marking on an input interface. MPLS marking takes effect only during label imposition. You can
combine marking and policing to change the DSCP and MPLS EXP values of an IP packet during MPLS
label imposition.
A provider edge (PE) router at the edge of the MPLS network can be configured to map the DSCP or IP
precedence field to the MPLS EXP field. The router uses the value of the EXP field as the basis for IP
QoS. As a result, MPLS routers can perform QoS features indirectly, based on the original IP precedence
field inside the MPLS-encapsulated IP packet. The IP packet does not need to be opened to examine the
IP precedence field. When a packet leaves the MPLS network, IP QoS is still based on the DSCP or IP
precedence value in the IP header.
QinQ MPLS Experimental Marking

For CoS-to-EXP mapping in QinQ configurations, the parallel express forwarding (PXF) engine looks
at the CoS bits in the outer dot1q header to determine how to mark the EXP bits.
For EXP-to-CoS mapping in QinQ configurations, the PXF marks both the inner and outer CoS bits.
set mpls experimental imposition Command

To set the value of the Multiprotocol Label Switching (MPLS) experimental (EXP) field on all imposed
label entries, use the set mpls experimental imposition command in policy-map class configuration
mode. To disable the setting, use the no form of the command. By default, no MPLS EXP value is set.
set mpls experimental imposition mpls-exp-value
no set mpls experimental imposition mpls-exp-value
Syntax Description
mpls-exp-value
Specifies the value used to set the MPLS EXP bits. Valid values are from 0
to 7.
set mpls experimental imposition Command History

Cisco IOS Release
Description
Release 12.0(22)S
The set mpls experimental command was introduced on the PRE1.
Release 12.3(7)XI1
The set mpls experimental imposition command was introduced on the

PRE2.
Release 12.2(28)SB
PRE2.

OL-7433-09
7-15
Chapter 7
Marking Traffic
Discard-Class Marking
Note
Cisco IOS software replaced the set mpls experimental command with the set mpls experimental
imposition command. However, the Cisco 10000 series router continues to use the set mpls
experimental command for PRE1. For PRE2, the command is set mpls experimental imposition.
Usage Guidelines for the set mpls experimental imposition Command

The set mpls experimental imposition command is supported only on input interfaces. Use this
command during label imposition. This command sets the MPLS EXP field on all imposed label entries.
You can use the set mpls experimental imposition command on the input interface of a provider edge
(PE) router connected to a customer edge (CE) router. In MPLS QoS differentiated services (DiffServ)
tunneling modes, you can also use this command on the input interfaces of CE routers in pipe mode.
Note
The Cisco 10000 series router does not support the set mpls experimental topmost command.
Discard-Class Marking
The discard-class is a 3-bit field that is used to set the per-hop behavior (PHB) for dropping traffic. The
discard-class indicates the drop portion of the PHB. You can set the discard-class on the input interface
to use as a matching criterion and to affect how packets are dropped on the output interface. You can use
the discard-class with weighted random early detection (WRED) on the output interface to classify
packets and determine packet drop probability. You can set up to eight discard-class values (0 through 7).
set discard-class Command

To mark a packet with a discard-class value or to drop a specific traffic type during congestion, use the
set discard-class command in policy-map class configuration mode. To remove a discard-class value or
to disable the discard-class value, use the no form of the command. By default, the discard-value is zero.
set discard-class value
no set discard-class value
Syntax Description
value
Is the priority of a type of traffic. Valid values are from 0 to 7.

Note
This command is available only on the PRE2.
set discard-class Command History

Cisco IOS Release
Description
Release 12.3(7)XI
This command was introduced on the PRE2 only.
Release 12.2(28)SB
PRE2.
7-16
OL-7433-09
Chapter 7
Marking Traffic
Class-Based Frame Relay DE Bit Marking
Usage Guidelines for the set discard-class Command

You can set the discard-class on the input interface to use as a matching criterion and to affect how
packets are dropped on the output interface. You can use the discard-class with weighted random early
detection (WRED) on the output interface to classify packets and determine packet drop probability.
The router supports the set discard-class command only on the PRE2.
Class-Based Frame Relay DE Bit Marking

The Class-Based Frame Relay DE Bit Marking feature provides the ability to prioritize frames in a
Frame Relay network by setting the discard eligibility (DE) bit in the header of Frame Relay frames. As
congestion occurs in the Frame Relay network, frames with the DE bit set are more likely to be dropped,
resulting in improved network performance for higher priority traffic and applications.
This feature supports the classification of inbound Frame Relay traffic based on the DE bit setting and
the marking of the DE bit of outbound Frame Relay traffic. During classification, the router matches the
DE bit of inbound packets to previously configured traffic classes (created using a class map) and
classifies each matching packet as belonging to a specific traffic class.
DE bit marking can occur either as a class-based shaping action or as a class-based policing action. The
modular QoS command-line interface (MQC) commands used to mark the DE bit are the following:
set fr-de command (class-based shaping)
set-frde-transmit command (class-based policing)
The set-frde-transmit command is a policing action for conforming traffic and is used with the police
command. When using the conforming-action set-frde-transmit command, the router sends the frames
through the policers token bucket mechanism for processing and sets the DE bit for all frames that
conform to the committed rate.
The PRE3 and PRE4 support Frame Relay DE bit marking across packet fragments.
History for the Class-Based Frame Relay DE Bit Marking Feature

Cisco IOS Release
Description
Required PRE
PRE2, PRE3
Release 12.2(33)SB
PRE2, PRE3,
PRE4

OL-7433-09
7-17
Chapter 7
Marking Traffic

When you simultaneously configure a class in a policy map to include both marking and policing
commands (the set and police commands), the router processes the set command first and then processes
the police command. As a result, the values set by the police command override the values of the set
command. This occurs regardless of whether you attach a policy map to an inbound or outbound
interface.
For example, if you use the set command to configure a value for the IP precedence field and you
configure a value for the same field by using the police command, the IP precedence value you set for
the police command overrides the IP precedence value you configured for the set command.
The set and police commands allow you to configure the following fields:
IP precedence and IP DSCP
QoS group
MPLS experimental imposition
Discard-class
ATM cell loss priority
Tunnel Header Marking

The Tunnel Header Marking (THM) feature allows you to mark the outer IP headers DSCP or
precedence value during tunnel encapsulation of the packet.
The outer IP header type of service (ToS) field of a tunneled packet is typically exposed to a different
QoS domain from that of the inner IP header. For example, for Multicast Virtual Private Network
(MVPN) packets placed in Generic Routing Encapsulation (GRE) tunnels, the router processes the
packets outer ToS field based on the QoS services of a common core MPLS network. The router
processes the packets inner IP ToS field based on the QoS services of a particular VRF. Using tunnel
header marking, different traffic streams that are aggregated into the same tunnel can mark their outer
ToS field differently. This enables the streams to receive a different level of QoS processing at the outer
ToS fields QoS domain.
A policy map is used to enable tunnel header marking and is applied to the inbound interface. If the
outbound interface is a tunnel, the router marks the outer headers of packets as tunnel encapsulation
occurs. If the outbound interface is not a tunnel, the policy map has no affect on the arriving packet
headers.
As shown in Figure 7-4, the policy map named policy1 has tunnel header marking configured and is
attached to inbound interface P1, and outbound interface P2 is a tunnel. As a result, the router classifies
traffic as it enters the router through interface P1 and marks the traffic as it leaves through interface P2.
7-18
OL-7433-09
Chapter 7
Marking Traffic

190190
Figure 7-4
Cisco 10008 Router

policy-map
Traffic
P1
Inbound
Interface
P2
Packet
headers marked
Tunnel
Outbound
Interface
Tos=xyz
Tos=abc
191282
Tos=abc
Feature History for Tunnel Header Marking

Cisco IOS Release
Description
Required PRE
Release 12.2(31)SB2

mark the outer IP headers DSCP or precedence value
during tunnel encapsulation of the packet.
PRE2

DSCP-Based and Precedence-Based Marking
You cannot simultaneously configure both the set ip dscp command and the set ip precedence
command in a policy map.
Because IP precedence is actually part of the DSCP value, you cannot simultaneously set both the
IP precedence and DSCP values for a traffic class. A packet can have one value or the other, but not
both. If you do configure both values, the router marks the packet with the DSCP value.
Because the router copies the IP precedence value to the MPLS EXP bits during label imposition,
you cannot simultaneously set both IP precedence and MPLS experimental marking for a class.
Marking has no preset scaling limit.
In Cisco IOS Release 12.3(7)XI, the router accepts the set precedence and set dscp commands
without specifying the ip keyword. However, you must specify the set ip precedence command to
set the precedence value in a packet header and the set ip dscp command to set the DSCP value. The
ip keyword is required.
Frame Relay DE Bit Marking Restrictions
In Cisco IOS Release 12.3(7)XI, when you enter the set ? command, the context-sensitive help lists
the fr-de keyword to allow you to set the Frame Relay discard eligibility (DE) bit. However, the
router does not support setting the DE bit in Cisco IOS Release 12.3(7)XI and later releases.

OL-7433-09
7-19
Chapter 7
Marking Traffic
Discard-Class-Based Marking Restrictions
The router supports the set discard-class command only on the PRE2.
When you use the input per-hop behavior (PHB) marking to classify packets on the output interface,
you must configure the set discard-class command in the input policy.
CoS-Based Marking Restrictions
The router supports CoS-based QoS only on Ethernet interfaces or PPPoE sessions associated with
Ethernet interfaces.
The router supports matching and marking for physical Ethernet interfaces and subinterfaces. The
router supports CoS-based QoS for virtual access interfaces (VAIs) associated with PPPoE
interfaces and it supports classification on the input policy and marking on the output policy.
Tunnel Header Marking Restrictions
If the outbound interface is not a tunnel, a policy map with tunnel header marking has no effect on
the packet headers.
The router accepts only input service policies for tunnel header marking. You must apply a policy
map with tunnel header marking to inbound interfaces. If you attempt to apply a service policy with
tunnel header marking to an outbound interface, an error message displays.
You may use the [no] set ip [dscp | precedence] tunnel value command in conjunction with other
input set actions. However, if you specify tunnel header marking as a policer action, using the
set-dscp-tunnel-transmit or set-prec-tunnel-transmit command, then you cannot specify any other
policer action. The router only supports a single police action.
The marking statistics for tunnel header marking are included in the statistical information for the
class map.

The following describes interface support for marking using the set commands:
Interfaces Supporting the set Command
Note
Physical
Frame Relay permanent virtual circuits (PVCs), point-to-point subinterfaces, and map classes
Ethernet VLANs
IP tunnel
The router supports the set command on inbound and outbound interfaces.
7-20
OL-7433-09
Chapter 7
Marking Traffic
Interfaces Not Supporting the set Command
Fast Ethernet channel
Frame Relay data link connection identifier (DLCI)

The Cisco 10000 series router provides many tools for classifying and marking traffic. Your task is to
determine how best to use these tools in your network environment. The following are guidelines to help
you make good design choices for classification and marking tools:
Classify and mark traffic as close to the ingress edge as possible.
Consider the trust boundary in the network, making sure to mark or remark traffic after it reaches a
trusted device in the network.
Because the IP precedence and DSCP marking fields are part of the IP header and, therefore, are
carried end-to-end, mark one of these fields to maximize the benefits of reducing classification
overhead by the other QoS tools enabled in the network.
If LAN switches connected to the router support only Layer 2 QoS (for example, the switch reacts
to marked CoS bits, but not to marked IP precedence or DSCP bits), mark the CoS bits on the router
before sending the frames onto the Ethernet.
We suggest that you use the values indicated in Table 7-5 on page 7-21 for DSCP settings for voice
and video payload, voice and video signaling, and data. Otherwise, follow the differentiated services
(DiffServ) per-hop behavior (PHB) RFCs for DSCP settings as indicated in Table 7-4 on page 7-8.

Table 7-5 lists the recommended values to use for traffic marking.
Table 7-5
Traffic Type
IP Precedence
IP DSCP
Class of Service
Voice payload
EF
Video payload
AF41
Voice and video signaling
AF31
High priority data
AF21
AF22
AF23
Medium priority data
AF11
AF12
AF13
All other traffic
Default

OL-7433-09
7-21
Chapter 7
Marking Traffic
Configuring Traffic Marking

To configure class-based traffic marking, perform any of the following optional tasks:
Configuring IP Precedence Marking, page 7-22
Configuring IP DSCP Marking, page 7-24
Configuring Class of Service Marking, page 7-26
Configuring QoS Group Marking, page 7-28
Setting the ATM Cell Loss Priority Bit, page 7-29
Configuring MPLS Experimental Marking, page 7-31
Configuring Discard-Class Marking, page 7-33
Configuring Tunnel Header Marking Using the set Command, page 7-35
Configuring Tunnel Header Marking Using the police Command, page 7-36
For more information about classifying traffic and creating QoS service policies, see Chapter 2,
Classifying Traffic and Chapter 3, Configuring QoS Policy Actions and Rules.
Configuring IP Precedence Marking

To mark the IP precedence field of packets, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
Router(config-pmap-c)# set ip precedence

prec-value
Specifies the IP precedence of packets within a traffic class.

prec-value is the IP precedence value. Valid values are from
0 to 7. See Table 7-2 on page 7-4.
Note
Be sure you specify the ip keyword.
7-22
OL-7433-09
Chapter 7
Marking Traffic
Command
Purpose
Step 4
Step 5
Step 6
Router(config)# interface type number
Specifies the interface to which you want to attach the service

policy map. Enters interface configuration mode.
type is the type of interface (for example, serial).
number is the number of the interface (for example, 1/0/0).
Step 7
Router(config-if)# service-policy {input |

output} policy-map-name
Attaches the policy map you specify to the interface. The

router applies the service policy to packets on the interface in
either the input or output direction.
packets.
packets.
Configuration Examples for IP Precedence Marking and Classification

Example 7-1 shows how to configure IP precedence marking. In the example, a policy map named
Bronze is created and the class map named Voice is associated with the Bronze policy. For all outbound
packets on the Gigabit Ethernet 2/0/1 interface, the router sets the IP precedence bits to 5.
Example 7-1
Configuring IP Precedence Marking
Router(config)# class-map Voice

Router(config)# policy-map Bronze
Router(config-if)# service-policy output Bronze
Example 7-2 shows how to configure IP precedence-based classification. In the example, a policy map
named Second is created and the class map named ip-prec is associated with the Second policy. For all
outbound packets on Gigabit Ethernet interface 2/0/1, the router classifies packets based on the setting
of their IP precedence bits. If the bits are set to 3, the router assigns the packets to the ip-prec class and
polices the traffic as indicated in the Second policy map.
Example 7-2
Configuring IP Precedence-Based Classification
Router(config)# class-map ip-prec

Router(config)# policy-map Second
Router(config-pmap)# class ip-prec
violate-action drop

OL-7433-09
7-23
Chapter 7
Marking Traffic

Router(config-if)# service-policy output Second
Configuring IP DSCP Marking

To mark the DSCP field of packets, enter the following commands beginning in global configuration
mode:
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
Router(config-pmap-c)# set ip dscp

{dscp-value | afxy | csx | ef | default}
Sets the DSCP value in the ToS byte.

ip specifies that the match is for IPv4 packets only. You must
specify this keyword.
dscp dscp-value sets the DSCP value. Valid values are from 0
to 63.
Instead of specifying a numeric dscp-value, you can specify
one of the following reserved keywords:
afxy indicates assured forwarding points. The first

number (x) indicates the AF class. Valid values are from
1 to 4. The second number (y) indicates the level of drop
preference within each class. Valid values are from
1 (low drop) to 3 (high drop).
cs indicates class selector code points that are

backward-compatible with IP precedence. Valid values
for x are 1 through 7. The CS code points (CS1 through
CS7) are identical to IP precedence values 1 through 7.
7-24
OL-7433-09
Chapter 7
Marking Traffic
Command
Purpose
Step 4
Step 5
Step 6

Step 7


packets.
packets.
Configuration Examples for IP DSCP Marking and Classification

Example 7-3 shows how to configure IP DSCP marking. In the example, the router assigns outbound
traffic on the Gigabit Ethernet 1/0/0 interface to either class1 or class2. The router marks the packets by
setting the DSCP bits of class1 packets to DSCP 5 and by setting the DSCP bits of class2 packets to
DSCP 3 as indicated in the policy map named Silver.
Example 7-3
Configuring IP DSCP Marking

Router(config-cmap)# match qos-group 2
Router(config-cmap)# class class2
Router(config)# policy-map Silver
Router(config-pmap-c)# set ip dscp 5
Router(config-pmap-c)# class class2
Router(config-if)# service-policy output Silver
Example 7-4 shows how to configure IP DSCP-based classification. In the example, the router checks
the DSCP bits of outbound packets on the GigabitEthernet interface 1/0/0. If the packet DSCP bits are
set to 5, the router assigns the packet to the Voice class and gives the packet priority handling as indicated
in the policy map named Platinum. All intermediate routers provide low-latency treatment to the Voice
packets.
Example 7-4
Configuring IP DSCP-Based Classification

Router(config-cmap)# match ip dscp 5
Router(config)# policy-map Platinum

OL-7433-09
7-25
Chapter 7
Marking Traffic

violate-action drop
Router(config-if)# service-policy output Platinum
Configuring Class of Service Marking

To mark the Layer 2 class of service (CoS) field in the 802.1p header of outbound packets, enter the
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
Router(config-pmap-c)# set cos cos-value
Step 4
Step 5
Step 6

Sets the Layer 2 class of service (CoS) value of an outbound

packet.
cos-value is a specific IEEE 802.1Q CoS value from 0 to 7.

Step 7
Router(config-if)# service-policy output

policy-map-name

packets.
Note
You can attach a service policy containing the set cos

command to only an outbound VLAN interface. The
router cannot apply the set cos command to inbound
packets.
7-26
OL-7433-09
Chapter 7
Marking Traffic
Configuration Examples for CoS Marking and Classification

Example 7-5 shows how to configure CoS classification and marking on an interface, setting the Layer 2
CoS value in the 802.1p header. In the example, the router checks the DSCP bits of inbound packets on
the Gigabit Ethernet interface 1/0/0. If the bits are set to DSCP AF11, the router assigns the packet to
the class named Cos-Class and on the outbound interface marks the packet by setting the class of service
bits to 5 as indicated in the policy map named Policy1.
Example 7-5
Configuring CoS Marking
Router(config)# class-map Cos-Class

Router(config-cmap)# match ip dscp AF11
Router(config)# policy-map Policy1
Router(config-pmap)# class Cos-Class
Router(config-pmap-c)# set cos 5
Router(config-if)# service-policy output Policy1
Example 7-6 shows how to configure CoS-based classification on outbound packets. In the example, the
router checks the class of service bits of packets leaving on Gigabit Ethernet interface 4/0/0. If the bits
are set to 3, the router assigns the packet to the class named Voice and marks the packet by setting the
IP DSCP bits to 8 as indicated in the policy map named Policy1.
Note
By default, the router maps the CoS field to the IP DSCP bits for packets received on inbound interfaces.
The router maps IP precedence bits to the user priority bits for packets forwarded in the outbound
direction. You can override this default behavior by creating a QoS policy that specifies the desired
action.
Example 7-6
Configuring CoS-Based Classification

Router(config-cmap)# match cos 3
Router(config-if)# service-policy output Policy1

OL-7433-09
7-27
Chapter 7
Marking Traffic
Configuring QoS Group Marking

To mark packets with a local QoS group ID, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
Router(config-pmap-c)# set qos-group

group-id
Sets a QoS group identifier (ID) to use in classifying packets.

group-id is the group identifier. Valid values are from 0 to 99.
Step 4
Step 5
Step 6

Step 7


packets.
packets.
Configuration Examples for Configuring QoS Group Marking and Classification

Example 7-7 shows how to configure QoS group marking. In this example, the router classifies inbound
packets on the Gigabit Ethernet interface 1/0/0 based on the class of service value. If the packet CoS
value is 5, the router assigns the packet to the class named Group and sets the packet qos-group ID to 4
as indicated in the policy map named Policy1.
Example 7-7
Configuring QoS Group Marking
Router(config)# class-map Group

Router(config-pmap)# class Group
Router(config-pmap-c)# set qos-group 4
7-28
OL-7433-09
Chapter 7
Marking Traffic
Router(config-if)# service-policy input Policy1
Example 7-8 shows how to configure the router to classify packets based on the QoS group ID of the
packet. In this example, the router checks outbound packets on Ethernet interface 1/0/0 for QoS group
ID 5, assigns the matching packets to the traffic class named QoSGroup, defined in the policy map
named Gold, and sets the packet DSCP bits to DSCP 0 (best effort).
Example 7-8
Configuring QoS Group-Based Classification
Router(config)# class-map QoSGroup

Router(config-cmap)# match qos-group 5
Router(config-pmap)# class QoSGroup
Router(config-pmap-c)# set dscp 0
Router(config)# interface Ethernet 1/0/0
Router(config-if)# service-policy output Gold
Setting the ATM Cell Loss Priority Bit

To set the ATM cell loss priority (CLP) bit to 1, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
Router(config-pmap-c)# set atm-clp
Sets the cell loss priority bit to 1. The router discards packets
with the CLP bit set to 1 before it discards packets with the
CLP bit set to 0.
Note
To change the CLP bit back to 0, use the

no set atm-clp command.

OL-7433-09
7-29
Chapter 7
Marking Traffic
Command
Purpose
Step 4
Step 5
Step 6

Step 7


packets.
packets.
Configuration Example for Setting the ATM CLP Bit

Example 7-9 shows how to set the ATM CLP bit of packets. For all packets arriving on the
ATM interface 1/0/1, the router assigns the packets that match access control list (ACL) 100 to the
Class1 traffic class and sets the ATM CLP bit of each packet.
Example 7-9
Setting the ATM CLP Bit
Router(config)# class-map Class1

Router(config-pmap)# class Class1
Router(config-pmap-c)# set atm-clp
Router(config-if)# service-policy output Premium
7-30
OL-7433-09
Chapter 7
Marking Traffic
Configuring MPLS Experimental Marking

To copy the IP precedence or DSCP value to the MPLS experimental bits during label imposition, enter
the following commands beginning in global configuration mode:
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
Router(config-pmap-c)# set mpls experimental

imposition mpls-exp-value
Sets the value of the MPLS experimental (EXP) field on all

imposed label entries.
mpls-exp-value specifies the value used to set the MPLS EXP
bits. Valid values are from 0 to 7.
Step 4
Step 5
Step 6

Step 7


packets.
packets.

OL-7433-09
7-31
Chapter 7
Marking Traffic
Configuration Examples for Configuring MPLS Experimental Marking and Classification

Example 7-10 shows how to configure MPLS Experimental (EXP) marking. In the example, for all
packets on the inbound Gigabit Ethernet interface 1/0/0 that match class of service 3, the router sets the
packet MPLS experimental bits to 5.
Example 7-10 Configuring MPLS EXP Marking
Router(config)# policy-map Silver
Router(config-pmap-c)# set mpls experimental imposition 5
Router(config-if)# mpls ip
Router(config-if)# service-policy input Silver
Example 7-11 shows how to configure MPLS EXP-based classification. In the example, the router
checks the MPLS EXP bits of the packets arriving on the Gigabit Ethernet interface 1/0/0. The router
assigns the packets whose bits have a setting of 5 to the mpls-exp class. As indicated in the policy map,
the router provides low-latency priority handling of MPLS experimental traffic.
Example 7-11 Configuring MPLS EXP-Based Classification
Router(config)# class-map mpls-exp
Router(config-cmap)# match mpls experimental 5
Router(config)# policy-map Platinum
Router(config-pmap)# class mpls-exp
Router(config-pmap-c)# police percent 30 4000 2000 conform-action transmit exceed-action
drop
Router(config-if)# service-policy output Platinum
7-32
OL-7433-09
Chapter 7
Marking Traffic
Configuring Discard-Class Marking

To mark packets with a discard-class value, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
Router(config-pmap-c)# set discard-class

value
Marks a packet with a discard eligibility value, setting the

per-hop behavior (PHB) for dropping traffic.
value is the priority of a type of traffic. Valid values are from
0 to 7.
Note
This command is only available on the PRE2.
Step 4
Step 5
Step 6

Step 7


packets.
packets.

OL-7433-09
7-33
Chapter 7
Marking Traffic
Configuration Examples for Configuring Discard-Class Marking and Classification

Example 7-12 shows how to configure the discard eligibility value for a traffic class. In the example, the
router classifies inbound traffic on Ethernet interface 1/0/0 based on the class of service setting of the
packets. If the CoS value matches 1, the router assigns the matching packets to the class named Class1
and sets the packet discard-class value to 4, as defined in the policy map named MyPolicy.
Example 7-12 Configuring Discard-Class Marking
Router(config)# policy-map MyPolicy
Router(config-pmap-c)# set discard-class 4
Router(config)# interface Ethernet 1/0/0
Router(config-if)# service-policy input MyPolicy
Example 7-13 shows how to configure discard-class-based classification. In the example, the router
classifies outbound traffic on Gigabit Ethernet interface 2/0/1 based on the discard-class setting of the
packets. If the discard-class value matches 3, the router assigns the matching packets to the class named
Group1 and provides a minimum bandwidth guarantee of 8000 kbps to Group1 traffic, as defined in the
policy map named Manhattan.
Example 7-13 Configuring Discard-Class-Based Classification
Router(config)# class-map Group1
Router(config-cmap)# match discard-class 3
Router(config)# policy-map Manhattan
Router (config-pmap)# exit
Router(config-if)# service-policy output Manhattan
7-34
OL-7433-09
Chapter 7
Marking Traffic
Configuring Tunnel Header Marking Using the set Command

To configure tunnel header marking using the set command, enter the following configuration
Step 1
Command
Purpose

configuration mode.
Step 2

define QoS actions.
Step 3
Router(config-pmap-c)# set ip [dscp |

precedence] tunnel value
Marks a packet by setting the differentiated services code

point (DSCP) value or precedence level in the type of
service (ToS) byte.
(DSCP) tunnel value is a number from 0 to 63 or one of the
(Precedence) tunnel value is a number from 0 to 7 that sets

the precedence bit in the packet header.
Configuration Example for Tunnel Header Marking Using the set Command
The following example configuration shows how to configure tunnel header marking using the set
command. In the example, marking is configured for the match_ip traffic class. For all packets belonging
to that class, the router sets the DSCP bits to 3.
class-map match_ip
match protocol ip
policy-map Tunnel_Marking
class match_ip
set ip dscp tunnel 3
class class-default
shape 64000

OL-7433-09
7-35
Chapter 7
Marking Traffic
Configuring Tunnel Header Marking Using the police Command

To configure tunnel header marking using the police command, enter the following commands beginning
Step 1
Command
Purpose

configuration mode.
Step 2

define QoS actions.
Step 3

[bc] burst-normal [pir pir] [be] burst-excess
[conform-action {set-dscp-tunnel-transmit value
| set-prec-tunnel-transmit value}]
[exceed-action {set-dscp-tunnel-transmit value
[violate-action {set-dscp-tunnel-transmit value
Configures policing and uses the policer action to mark a

packets outer tunnel header.
set-dscp-tunnel-transmit value is a number from 0 to 63
or one of the following reserved keywords:
set-prec-tunnel-transmit value is a number from 0 to 7

that sets the precedence bit in the packet header.
For more information, see the police Command
(Single-Rate) section on page 6-6 or the police Command
(Two-Rate) section on page 6-9.
Example Configuration for Tunnel Header Marking Using the police Command
The following example configuration shows how to mark the tunnel header of a packet using the police
command. In the example, the policer sets the DSCP bits to 4 for all conforming traffic belonging to the
match_ip class.
class-map match_ip
match protocol ip
policy-map Tunnel_Marking
class match_ip
police 8000 conform-action set-dscp-tunnel-transmit 4
class class-default
shape 64000
7-36
OL-7433-09
Chapter 7
Marking Traffic
Verifying Traffic Marking

The Cisco 10000 series router collects statistical information about the number of packets and bytes
marked.
To verify traffic marking, enter any of the following commands in privileged EXEC configuration mode:
Command
Purpose
Displays configuration information for all configured policy

maps.
Displays configuration information for the policy map you

specify.
Displays configuration and statistical information for all of the

input and output policies that are attached to an interface.
For example, statistical information such as the incoming traffic
rate, dropped packet rate, and the number of matched packets and
bytes.
Displays configuration and statistical information for the input

and output policies attached to the interface you specify.

[input | output]

interface.
policy.
outbound policy.
Note

class-name

you specified.
Displays the configuration of the class you specify for the policy
map you specify.
to display.

OL-7433-09
7-37
Chapter 7
Marking Traffic
Verification Examples for Traffic Marking

Example 7-14 shows how to verify marking for the traffic classes in a policy map. In this example, traffic
assigned to the Gold class has the precedence bits set to 5.
Example 7-14 Verifying Marking in a Policy Map
Router# show policy-map Child
Policy Map Child
Class Bronze
police percent 30 6 ms 4 ms conform-action transmit exceed-action set-prep
Class Gold
police 8000 2000 4000 conform-action transmit exceed-action set-qos-transp
set ip precedence 5
Example 7-15 shows how to verify marking on a specific interface. In this example, the QoS policy is a
hierarchical policy that is attached to PVC 5/101 on the ATM 3/0/0.3 subinterface. In the Child policy,
the Bronze class indicates to set the DSCP bits of Bronze packets to 3. The Gold class indicates to set
the IP precedence bits of Gold packets to 5.
Example 7-15 Verifying Marking in a Hierarchical Policy
ATM3/0/0.3: VC 5/101 Service-policy output: Parent
0 packets, 0 bytes
Match: any
Shape : 2000 kbps
Service-policy : Child
Class-map: Bronze (match-all)
0 packets, 0 bytes
Police:
QoS Set
dscp 3
Packets marked 0
0 packets, 0 bytes
Police:
exceeded 0 packets, 0 bytes; action: set-qos-transmit 4
QoS Set
precedence 5
7-38
OL-7433-09
Chapter 7
Marking Traffic
Packets marked 0
0 packets, 0 bytes
Match: any
Feature
3-Color Marker for Traffic Policing (single rate)
Release Notes for the Cisco 10000 Series ESR for Cisco IOS
Release 12.0(23)SX
New Features in Cisco IOS Release 12.0(23)SX > Single Rate
3-Color Marker for Traffic Policing
When Does a Router Set the CLP Bit in an ATM Cell?

Release 12.2
Part 1: Classification > Configuring Class-Based Packet
Marking
Classification and Marking

Release 12.2
Marking
Class-Based Marking, Release 12.0(26)S feature module
Configuring Packet Marking on Frame Relay PVCs
QoS Packet Marking, Implementing Quality of Service
Service Provider Quality of Service Design Guide

Release 12.2
Marking
DSCP Marking

Release 12.2
Marking
QoS Packet Marking, Implementing Quality of Service Policies with
DSCP

OL-7433-09
7-39
Chapter 7
Marking Traffic
Feature

Release 12.2
Marking
Cisco IP Solution Center, 3.0: Quality of Service Management User

Guide, Release 3.0
Quality of Service Concepts > MPLS Experimental Values
QoS Group Marking

Release 12.2
Marking
QoS Policy Propagation through the Border Gateway

Protocol (QPPB)

Release 12.2
Part 1: Classification > Classification Overview > QoS Policy
Propagation via Border Gateway Protocol
Part 1: Classification > Configuring QoS Policy Propagation via
7-40
OL-7433-09
CH A P T E R
Voice, video, and data applications have differing quality of service needs. Voice applications, for
example, require a small but guaranteed amount of bandwidth, are less tolerant of packet delay or loss,
and require low jitter. A data application such as File Transfer Protocol (FTP) needs more bandwidth
than voice and can tolerate packet delay and jitter. To provide end-to-end differentiated services, QoS
policies must allow critical applications to receive the resources required while ensuring that other
applications are not neglected.
Priority queuing offers the ability to deliver assured bandwidth, low latency, low jitter, and low packet
loss for voice applications while simultaneously ensuring that other applications receive portions of the
available bandwidth.
This chapter describes low-latency priority queuing and includes the following topics:
Low-Latency Priority Queuing, page 8-1
Multi-Level Priority Queues, page 8-3
Child Service Policy Allowed Under Priority Class, page 8-4
Interfaces Supporting Priority Queuing, page 8-4
Queues per Policy Map, page 8-5
Restrictions and Limitations for Priority Queuing, page 8-5
Restrictions for Multi-Level Priority Queues, page 8-5
Configuring a Priority Queue, page 8-6
Configuring Multi-Level Priority Queues, page 8-7
Configuration Examples for Configuring Priority Queues, page 8-9
Verifying and Monitoring Priority Queues, page 8-11
Verification Examples for Priority Queues, page 8-11
Low-Latency Priority Queuing

Using a single queue for packets from all traffic streams is simple, efficient, and offers optimal average
delay per packet because the queue uses the entire link bandwidth to transmit waiting packets. The
drawback to this method is it does not distinguish among different traffic streamsvoice, data, video.
The more traffic in a stream, the larger its share of the link bandwidth. Packets arriving first are the first
packets out of the queue, regardless of the packet type.

OL-7433-09
8-1
Chapter 8
Priority queuing overcomes the shortcomings of single queuing by allowing the router to dequeue and
transmit delay-sensitive data such as voice before it dequeues and sends packets in other queues. Using
priority queuing, delay-sensitive data receives preferential treatment over other traffic.
In all releases prior to Cisco IOS Release 12.0(25)S and Release 12.3(7)XI, low-latency priority queuing
(LL/PQ) and bandwidth reservation together enabled you to provide differentiated services (DiffServ).
Priority queuing lets you assign a guaranteed minimum bandwidth to one queue to minimize packet
delay. Bandwidth reservation divides the link bandwidth among the different traffic streams into multiple
queues, with each queue receiving its fair share of the link bandwidth divided among all non-empty
queues. By dividing the unused bandwidth among the queues with packets to send, multiple queuing has
the same average delay per packet as the single queue scheme, with the advantage of each queue
receiving its fair share of the bandwidth.
In Cisco IOS Release 12.0(25)S and Release 12.3(7)XI, and later releases, strict priority queuing
guarantees low-latency for any packet that enters a priority queue, regardless of the current congestion
level on the link. With strict priority queuing, the router gives the traffic full priority and services it at
line rate, which can cause bandwidth starvation of other traffic queues. To avoid this, use the police
command to restrict the amount of bandwidth the priority queue can use. When you specify the police
command, the router sets the committed information rate (CIR) for the priority queue to the bandwidth
you specify in the police command. The router must drop packets that exceed the committed rate.
Note
The actual throughput of a priority queue does not exceed its configured value even if other queues on
the link are empty.
For multilink PPP (MLPPP) bundling, the router restricts the priority queue bandwidth to the bandwidth
of one of the bundle members.
Note
The router supports multilink PPP (MLPPP) for Cisco IOS Release 12.3(7)XI2 and later releases. For
Cisco IOS Release 12.2(16)BX3 and Release 12.3(7)XI1, the router does not support MLPPP.
Feature History for Low-Latency Priority Queuing

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The priority queuing feature was introduced on the router PRE1

to allow you to configure a bandwidth rate for a queue in
kilobits per second.
Release 12.0(20)ST
This feature was enhanced to allow you to configure a

bandwidth rate for a queue as a percentage.
PRE1
Release 12.0(25)S
This feature was modified to provide strict priority

queuing on the PRE1.
PRE1
Release 12.2(16)BX

configure a bandwidth rate for a queue in kilobits per
second or as a percentage.
PRE2
Release 12.3(7)XI1
This feature was modified to provide strict priority

queuing on the PRE2.
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
PRE3
8-2
OL-7433-09
Chapter 8
Bandwidth Starvation
In Cisco IOS Release 12.3(7)XI and later releases, to prevent the priority queue from starving other
queues, specify a guaranteed bandwidth using the police command.
Note
In Cisco IOS Release 12.0(25)S and Release 12.3(7)XI, and later releases, the priority command no
longer allows you to specify a priority rate in kbps or as a percentage of the available bandwidth.
In Cisco IOS Release 12.3(7)XI and later releases, the router allocates the bandwidth you specify in the
police command to the priority queue before it allocates bandwidth to the other queues on the link. As
a result, the amount of bandwidth allocated to the other queues is based on the bandwidth remaining after
the priority queue receives its bandwidth allocation. In a policy map, if you configure a traffic class as a
priority queue and you specify a guaranteed bandwidth, you must use the bandwidth remaining
command to configure bandwidth for other traffic classes in the policy map.

The Multi-Level Priority Queues (MPQ) feature allows you to configure multiple priority queues for
multiple traffic classes by specifying a different priority level for each of the traffic classes in a single
service policy map. You can configure multiple service policy maps per router.
Previously, Cisco IOS-based routers could have only one strict priority queue per policy map for all
delay-sensitive trafficthe router associated all priority traffic with this one single priority queue.
However, having only one priority queue can cause significant delay in delivering traffic, especially if
the router sends high priority traffic (for example, voice) behind low priority traffic (for example, video).
Using class-based weighted fair queuing (CBWFQ) to reduce delay by heavily weighting one queue can
affect the granularity of bandwidth allocations to the other queues. The MPQ feature addresses these
issues and improves latency.
The priority command is used to specify that a class of traffic has latency requirements with respect to
other classes. For multiple priority queues, you can use the priority level command to configure a level
of priority service on a class in a policy map. Currently, the router supports two priority levels:
level 1 (high) and level 2 (low). The router places traffic with a high priority level on the outbound link
ahead of traffic with a low priority level. High priority packets, therefore, are not delayed behind low
priority packets.
The router associates a single priority queue with all of the traffic enabled with the same priority level
and services the high level priority queues until empty before servicing the next level priority queues and
non-priority queues. While the router services a queue, the service rate is as fast as possible and is
constrained only by the rate of the underlying link or parent node in a hierarchy. If a rate is configured
and the router determines that a traffic stream has exceeded the configured rate, the router drops the
exceeding packets during periods of congestion. If the link is currently not congested, the router places
the exceeding packets onto the outbound link.
When configuring MPQ on different traffic classes in a policy map, you must specify different priority
levels for the traffic classes. For example, configure one traffic class to have priority level 2 and another
class to have level 1.
If high priority traffic is not policed appropriately, bandwidth starvation of low priority traffic can occur.
Therefore, though not required, we recommend that you configure a policer for high priority traffic using
the police command. If you configure the police command for priority queues, the traffic rate is policed
to the police rate for each of the priority queues.

OL-7433-09
8-3
Chapter 8
You cannot configure the priority command and the priority level command on different classes in the
same policy map.
Feature History for Multi-Level Priority Queues

Cisco IOS Release
Description
Required PRE
Release 12.2(31)SB2
This feature was introduced and implemented on the

Cisco 10000 series router for the PRE3.
PRE3

The Cisco 10000 series router supports the Child Service Policy Allowed Under Priority Class feature
in Cisco IOS Release 12.2(31)SB2. This feature allows you to attach a child policy with non-queuing
features to a priority class. The priority class must be in the middle-level policy of a three-level
hierarchical policy or in the parent policy of a two-level hierarchical policy (nested policy).
For more information, see the Child Service Policy Allowed Under Priority Class, Release 12.2(31)SB2
feature module.
Interfaces Supporting Priority Queuing

The following describes interface support for priority queuing using the priority command:
Interfaces Supporting the priority Command
Physical
subinterfaces
Ethernet VLANs *
* Requires a specific type of hierarchical policy. For more information, see Chapter 13, Defining QoS
for Multiple Policy Levels.
Note
The router only supports the priority command on outbound interfaces.

Interfaces Not Supporting the priority Command
IP tunnel
8-4
OL-7433-09
Chapter 8
Note
The router does not support the priority command on inbound interfaces.

Table 8-1 lists the number of queues per policy map supported on the PRE2 and PRE3.
Table 8-1
Number of Queues per Policy Map
PRE
Queues Supported per Policy Map
PRE2
31 class queues
PRE3
1 priority level one queue

1 priority level two queue
12 class queues
1 default queue
Restrictions and Limitations for Priority Queuing
Each policy map can have only one priority class.
You cannot configure the random-detect or bandwidth commands with a priority service.
Restrictions for Multi-Level Priority Queues
You cannot configure both the priority command and the priority level command for two different
classes in the same policy map.
You cannot specify the same priority level for two different classes in the same policy map.
You cannot configure the default queue as a priority queue at any level. For example, the router
rejects the following configuration:
policy-map P1
class class-default
priority level 1
You cannot configure the bandwidth command and multi-level priority queuing on the same class.
For example, the router rejects the following configuration:
policy-map P1
class C1
priority level 1
bandwidth 200
You cannot configure the shape command and multi-level priority queuing on the same class. For
example, the router rejects the following configuration:
policy-map P1
class C1
priority level 1
shape average 56000

OL-7433-09
8-5
Chapter 8
To convert a one-level (flat) service policy with multiple priority queuing configured to a
hierarchical multi-level priority queuing service policy, you must first detach the flat service policy
from the interface using the no service-policy command, and then add a child policy map to it.

To assign priority to a class in a policy map, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
Assigns priority to the class you specified and reserves a

priority queue for class-based weighted fair queuing
(CBWFQ) traffic.
For Cisco IOS Release 12.0(25)S and Release 12.3(7)XI, and
later releases the priority command does not have any
arguments. You must use the police command to specify a
guaranteed bandwidth.
Releases prior to Cisco IOS Release 12.0(25)S and
Release 12.3(7)XI do not support the priority command
without any arguments. Use the following priority command
syntax for these releases to configure a priority queue and
specify a minimum guaranteed bandwidth (for example,
priority 56 or priority percent 20):
priority {bandwidth-kbps | percent percentage}
Step 4

[bc burst-normal] {pir pir} [be burst-excess]
[conform-action action [exceed-action action
[violate-action action]]]
Configures traffic policing and allows you to configure a rate

for the priority queue.
For more information, see Chapter 6, Policing Traffic.
8-6
OL-7433-09
Chapter 8

To configure Multi-Level Priority Queues (MPQ) in a policy map, enter the following commands
Step 1
Command or Action
Purpose
policy-map policy-name
Creates or modifies a policy map. Enters policy-map

configuration mode.
policy-name is the name of the policy map.
Step 2
class class-name
Specifies a traffic class. Enters policy-map class

configuration mode.
class-name is the name of a previously configured traffic
class.
Step 3
priority level level
Assigns priority to a traffic class at the priority level

specified.
level level is the level of priority assigned to the priority
class. Valid values are 1 (high priority) and 2 (low priority).
Default: 1
Note
Do not specify the same priority level for two

different classes in the same policy map.

OL-7433-09
8-7
Chapter 8
Step 4
Command or Action
Purpose
police [cir] bps [bc] burst-normal [pir pir]

[be] burst-excess [conform-action action]
(Optional) Configures bits per second-based traffic

policing.
(Optional) cir is the committed information rate and is
based on the interface shape rate. Indicates an average rate
at which the policer meters traffic.
bps specifies the average rate in bits per second (bps). Valid
values are from 8,000 to 2,488,320,000 bps.
(Optional) bc burst-normal is the normal or committed
burst (bc) size (in bytes) used by the first token bucket for
policing. Valid values are from 1 to 512,000,000. Default:
9,216
(Optional) pir pir is the peak information rate (PIR),
expressed as a percentage. The pir pir option indicates the
rate at which the second token bucket is updated. Valid
(Optional) be burst-excess is the excess burst (be) size (in
bytes) used by the second token bucket for policing. Valid
values are from 0 to 1,024,000,000 bytes. Default: 0
(Optional) conform-action action specifies the action to
take on packets that conform to the rate limit. Default:
transmit
(Optional) exceed-action action specifies the action to take
on packets that exceed the rate limit (but not the PIR if
two-rate policing is configured). Default: drop
(Optional) violate-action action specifies the action to take
on packets that continuously exceed the PIR rate limit.
Default: same as the exceed-action
Note
Step 5
police [cir] percent percent [bc]

normal-burst-in-msec [pir pir]
[be] excess-burst-in-msec [conform-action
action] [exceed-action action] [violate-action
action]
You must specify burst-normal before you specify

burst-excess, burst-excess before conform-action,
conform-action before exceed-action, and
exceed-action before violate-action.
(Optional) Configures traffic policing based on a

percentage of bandwidth available on the interface.
(Optional) cir is the committed information rate. Indicates
an average rate at which the policer meters traffic. CIR is
based on the interface shape rate.
percent percent indicates to use the percentage of available
bandwidth specified in percent to calculate the CIR. Valid
(Optional) pir pir is the peak information rate (PIR)
expressed as a percentage. The pir pir option indicates the
rate at which the second token bucket is updated. Valid
8-8
OL-7433-09
Chapter 8

Configuring a Priority Queue with a Guaranteed Bandwidth Based on Kilobits per Second:
Example, page 8-9
Configuring a Priority Queue with a Percent-Based Bandwidth Guarantee: Example, page 8-9
Configuring Multi-Level Priority Queues: Example, page 8-10
Unacceptable MPQ Configurations: Examples, page 8-10
Configuring a Priority Queue with a Guaranteed Bandwidth Based on Kilobits

per Second: Example
Example 8-1 shows how to configure a priority queue with a guaranteed bandwidth of 8000 kbps. In the
example, the Voice1 class in the policy map named Gold is configured as the priority queue. The Gold
policy also includes the Voice2 class with a minimum bandwidth guarantee of 48 kbps. The Gold policy
is attached to PVC 0/101 on the outbound ATM subinterface 2/0/0.1.
Example 8-1
Priority Queuing Configuration

Router(config-pmap)# class Voice1
Router(config-pmap)# class Voice2
Router(config-atm-vc)# ubr 10000
Router(config-atm-vc)# service-policy output Gold
Configuring a Priority Queue with a Percent-Based Bandwidth Guarantee:

Example
Example 8-2 shows how to configure a priority queue with a minimum bandwidth guarantee based on a
percentage of the link bandwidth. In the example, the policy map named Premium has two traffic classes:
Class1 is configured as the priority queue and has a minimum guaranteed bandwidth of 25 percent of the
link bandwidth and Class2 has a minimum bandwidth guarantee of 48 kbps. The Premium service policy
is attached to the outbound ATM interface 1/0/0.
Example 8-2
Priority Queue with Bandwidth Percentage

Router(config-cmap)# match ip dscp ef

OL-7433-09
8-9
Chapter 8
Router(config-subif)# service-policy output Premium
Configuring Multi-Level Priority Queues: Example

The following example shows how to configure multiple priority queues. The policy map named
Business has two traffic classes: Bronze and Gold. Bronze traffic has a level 2 (low) priority while Gold
traffic has level 1 (high) priority. To prevent bandwidth starvation of Bronze traffic, the Gold traffic is
policed at 30 percent of the interface bandwidth.
enable
config terminal
policy-map Business
class Bronze
priority level 2
police 1000
exit
class Gold
priority level 1
police percent 30
Note
Although a policer is not required, we recommend that you configure policing for priority traffic to
prevent bandwidth starvation of low priority traffic. When policing is configured, the traffic rate is
policed to the police rate for each of the priority queues.
Unacceptable MPQ Configurations: Examples

You cannot specify both the priority command and the priority level command for two different classes
in the same policy map. For example, the router does not accept the following configuration:
policy-map Map1
class Bronze
priority level 1
exit
class Gold
priority rate 1000
You cannot specify the same priority level for two different classes in the same policy map. For example,
the router does not accept the following configuration:
Router(config)# policy-map Map1
Router(config-pmap-c)# priority level 1
Router(config-pmap-c)# priority level 1
8-10
OL-7433-09
Chapter 8

The Cisco 10000 series router collects statistical information about the current priority queue length, and
the number of packets and bytes transmitted and dropped.
To verify and monitor the contents of the priority queue (such as queue depth and the first packet
queued), and to verify the configuration of multi-level priority queues and to display statistical
information for each priority level, enter any of the following commands in privileged EXEC mode:
Command
Purpose
Displays the contents of the policy map you specify, including the
priority class.
Displays statistical and configuration information about the input

and output policies attached to the interface you specify, and
indicates any dropped packets or bytes for the priority class.
Verification Examples for Priority Queues

Verifying a Priority Queue: Example, page 8-11
Verifying Multi-Level Priority Queues: Example, page 8-12
Verifying a Priority Queue: Example

Example 8-3 shows sample output from the show policy-map interface command. In the example, the
Business class is the priority queue and is policed at 8000 bps with committed bursts of 5000 bytes and
extended bursts of 6000 bytes.
Example 8-3
Verifying Priority Queuing

ATM3/0/0.532: VC 5/32 Service-policy output: Gold
0 packets, 0 bytes
Police:
Absolute priority
0 packets, 0 bytes

OL-7433-09
8-11
Chapter 8
Verification Examples for Priority Queues

0 packets, 0 bytes
Match: any
Verifying Multi-Level Priority Queues: Example

The following example shows sample output from the show policy-map interface command.
Serial2/1/0
Service-policy output: P1
Queue statistics for all priority classes:
.
.
.
0 packets, 0 bytes/*Updated for each priority level configured.*/
Priority: 0 kbps, burst bytes 1500, b/w exceed drops: 0
Priority Level 2:
0 packets, 0 bytes
8-12
OL-7433-09
Chapter 8
Feature
Bandwidth and priority queues
Comparing the Bandwidth and Priority Commands of a QoS Service

Policy
Bandwidth starvation

Prioritizing Services > Low-Latency Priority Queuing >
Child Policy Under Priority Class
Child Service Policy Allowed Under Priority Class feature module,

Release 12.2(31)SB2
QoS Congestion Management (Queuing), Introduction
Multi-Level Priority Queues feature module, Release 12.2(31)SB2
Priority Queuing

Release 12.2
Part 2: Congestion Management > Configuring Priority Queues
ATM Traffic Management, Troubleshooting Output Drops with
Priority Queuing tech note
Low Latency Queuing, Release 12.0S feature module
IP to ATM Class of Service, Low Latency Queuing
Low Latency Queuing, Release 12.0T feature module
priority command

Release 12.3T
Quality of Service Commands: O through P > priority

OL-7433-09
8-13
Chapter 8
8-14
OL-7433-09
CH A P T E R
Shaping Traffic
Managing the flow of data across your network helps to ensure network efficiency by maximizing
bandwidth and avoiding congestion. Manage network traffic using traffic policing and traffic shaping.
Using these tools, you can configure your system to effectively manage issues before an overload on the
network. Traffic policing uses rate-limiting to regulate traffic and traffic shaping regulates traffic by
shaping it to a specified rate. Deploying policing and shaping throughout your network helps to ensure
that a packet, or data source, conforms to the QoS policies contracted for it.
The Cisco 10000 series router supports traffic policing and shaping. This chapter describes traffic
shaping and includes the following topics:
Traffic Shaping, page 9-2
Differences Between Traffic Shaping Mechanisms, page 9-10
Bandwidth and Traffic Shaping, page 9-10
Differences Between Shaping and Policing, page 9-11
Advantages and Disadvantages of Shaping and Policing for Bandwidth Limiting, page 9-11
Modifying the VC Weight and the VP Shaping Parameters, page 9-12
Example Scenarios of Traffic Shaping Usage, page 9-12
Interfaces Supporting Traffic Shaping, page 9-13
Configuring Traffic Shaping, page 9-13
Verifying Traffic Shaping, page 9-17
Configuration Examples for Traffic Shaping, page 9-21
For information about traffic policing, see Chapter 6, Policing Traffic.

For information about per-session traffic shaping and queuing, see Chapter 18, Regulating and Shaping
Subscriber Traffic.

OL-7433-09
9-1
Chapter 9
Shaping Traffic
Traffic Shaping
Traffic Shaping
Traffic shaping is a tool used to manage network traffic by shaping the traffic to a specified rate. Traffic
shaping enables you to control access to available bandwidth, to ensure that traffic conforms to the
policies established for it, and to regulate the flow of traffic to avoid congestion that can occur when the
transmitted traffic exceeds the access speed of its remote target interface.
Traffic shaping uses a traffic descriptor for a packetindicated by the classification of the packetto
ensure that a packet, or data source, adheres to the policies contracted for it and to determine the QoS to
apply to the packet. Traffic shaping enables you to control the traffic leaving an interface, matching its
packet flow to the speed of a particular remote interface. By shaping a class of traffic to conform to
downstream requirements, you can eliminate bottlenecks in topologies with data-rate mismatches.
The Cisco 10000 series routers traffic shaping algorithm is not based on the token bucket model.
Therefore, the concepts of committed burst (Bc) and excess burst (Be) are not applicable. Because
shaping does not use token buckets, the router cannot gather shaping statistics. As a result, you cannot
display the amount of shaped traffic in relation to the amount of traffic forwarded unshaped.
Unlike traffic policing, shaping does not propagate bursts and is applied to only outbound traffic on an
interface. When congestion occurs, policing drops traffic whereas traffic shaping delays the excess
traffic using a buffer or queuing mechanism and then schedules the excess packets for later transmission
over increments of time. This results in a smooth packet output rate. Shaping requires a queue and
sufficient memory to buffer delayed packets. Since queuing is an outbound function, only packets
leaving an interface can be queued and shaped.
When configuring shaping, you must ensure that the following exists:
Sufficient memory to buffer delayed packets
Scheduling function for later transmission of delayed packets
The Cisco 10000 series router supports the following types of traffic shaping:
Class-Based ShapingEnables you to shape a class of traffic to control the flow of traffic on an
interface. A service policy that defines shaping for a particular traffic class is attached to an
interface. Shaping is applied on a per-class basis. For more information, see the Class-Based
Traffic Shaping section on page 9-3.
Hierarchical ShapingProvides two levels of shapingper-VC ATM-level shaping and per-VC

packet-level shapingand provides per-VC and per-VP traffic shaping to control or modify the flow
of traffic on an interface. Traffic shaping ensures that traffic from one VC does not adversely impact
another VC and result in loss of data. For more information, see the Hierarchical Shaping section
on page 9-4.
Percentage-Based ShapingProvides the ability to configure traffic shaping on the basis of a

percentage of bandwidth available on an interface. For more information, see the Percentage-Based
Traffic Shaping section on page 9-8.
Frame Relay Traffic Shaping (FRTS)Shapes traffic on Frame Relay interfaces. Using FRTS,
service providers can organize traffic into per-data-link connection identifier (DLCI) queues, and
shape each DLCI separately. For more information, see the Frame Relay Traffic Shaping section
on page 9-8.
Note
FRTS is available only on the PRE1.
9-2
OL-7433-09
Chapter 9
Shaping Traffic
Traffic Shaping
Feature History for Traffic Shaping

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The Traffic Shaping feature was introduced on the router PRE1

to provide generic traffic shaping and Frame Relay Traffic
Shaping (FRTS).
Release 12.0(25)SX
This feature was enhanced to include the Class-based

Traffic Shaping feature.
PRE1
Release 12.2(16)BX
This feature was introduced on the PRE2 to provide

Class-based Traffic Shaping.
PRE2
Release 12.3(7)XI
This feature was enhanced on the PRE2 to include the

Hierarchical Shaping feature and the ATM VC/VP
Shaping feature, enabling you to shape traffic at both the
VC-level and VP-level.
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2

Class-based Traffic Shaping, Hierarchical Shaping, and
Percentage-based Shaping.
PRE2, PRE3
Release 12.2(33)SB

Class-based Traffic Shaping, Hierarchical Shaping, and
Percentage-based Shaping.
PRE2, PRE3,
PRE4
Class-Based Traffic Shaping

Class-based 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. Class-based traffic shaping creates a class of traffic that is shaped to meet downstream
requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches.
Any interface that supports generic traffic shaping also supports class-based shaping. Using class-based
traffic shaping, you can do the following:
Configure generic traffic shaping on a traffic classConfiguring generic traffic shaping on traffic
classes provides greater flexibility for configuring traffic shaping. Previously, this ability was
limited to the use of ACLs.
Specify average rate traffic shapingSpecifying average rate shaping allows you to make better use
of available bandwidth by allowing the maximum number of bits to be sent out in each interval. This
option is only supported on the PRE3.
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
is classified, thereby providing coarser granularity. You do not need to maintain traffic classification
on a flow basis. Moreover, you can configure up to 64 discrete classes in a service policy.
Configure class-based weighted fair queueing (CBWFQ) inside generic traffic shapingCBWFQ
allows you to specify the exact amount of bandwidth to be allocated for a specific class of traffic.

OL-7433-09
9-3
Chapter 9
Shaping Traffic
Traffic Shaping
Feature History for Class-Based Traffic Shaping

Cisco IOS Release
Description
Required PRE
Release 12.0(25)SX
The Class-Based Traffic Shaping feature was introduced

on the router.
PRE1
Release 12.2(16)BX
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
PRE3
System Limits for Class-Based Shaping

Table 3-1 on page 3-2 lists the system limits for policy maps supported on the Cisco 10000 series router.
Restrictions and Limitations for Class-Based Shaping
A single policy map can be attached to multiple interfaces concurrently. If you attempt to attach a
policy map to an interface when the sum of the bandwidth assigned to classes is greater than 99
percent of the available bandwidth, the router logs a warning message and does not allocate the
requested bandwidth to all of the classes. If the policy map is already attached to other interfaces, it
is removed from them.
Whenever you modify a class policy in an attached policy map, class-based weighted fair queuing
(CBWFQ) is notified and the new classes are installed as part of the policy map in the CBWFQ
system.
Hierarchical Shaping
Hierarchical shaping provides two levels of shapingper-VC ATM-level shaping and per-VC
packet-level shapingand provides per-VC and per-VP traffic shaping to control or modify the flow of
traffic on an interface. Traffic shaping limits throughput by buffering excess traffic instead of dropping
packets. The shaping function also ensures that traffic from one VC does not adversely impact another
VC, resulting in loss of data.
The Cisco 10000 series router supports hierarchical shaping for the following ATM line cards:
OC-12
4-port OC-3
8-port E3/DS3
The router supports hierarchical shaping when operating as a Layer 2 Access Concentrator (LAC) and
in the following modes:
PPP termination and aggregation (PTA)
Router bridge encapsulation (RBE)
RFC 1483
Hierarchical shaping does not require that you configure policy maps. You can use hierarchical shaping
with non-queuing related policy maps configured in a virtual template or configured directly on the VC.
Apply queuing-related policy maps directly to the VC.
9-4
OL-7433-09
Chapter 9
Shaping Traffic
Traffic Shaping
Hierarchical shaping supports the range pvc command to define shaping for a range of PVCs and the
vc-class atm command to create a VC class with shaping defined for a PVC.
Feature History for Hierarchical Shaping

Cisco IOS Release
Description
Required PRE
Release 12.3(7)XI
The Hierarchical Shaping and ATM VC/VP Shaping

features were introduced on the router.
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
PRE3
VP-Level Shaping
The segmentation and reassembly (SAR) mechanism of the Cisco 10000 series router handles VP-level
shaping functions, based on the aggregate VP traffic. VP shaping regulates the output rate of the VP
tunnel, rather than the output rate of the individual VCs. The SAR limits the rate of the overall output of
the VP tunnel to the constant bit rate (CBR) with a peak cell rate (PCR) specified for the tunnel that is
compliant with VP-level shaping requirements.
The SAR sends the cells (from the VCs in the VP tunnel) into the tunnel based on a weighted round robin
format. The weight indicates the number of cells a VC can send into the tunnel before the SAR processes
the next VC. The line card software programs a weight that is proportional to the VCs rate. Only
variable bit rate (VBR) VCs are allowed in the tunnel.
VC-Level Shaping
The parallel express forwarding (PXF) engine of the Cisco 10000 series router handles the VC-level
shaping functions. The PXF shapes the VCs at the packet level, including all ATM overheads based on
the sustained cell rate (SCR). VC-level shaping ensures that the VC traffic stream averages to be no
greater than the SCR, but is not compliant with ATM level instantaneous shaping requirements.
Shaped UBR PVCs

Prior to Cisco IOS Release 12.3(7)XI2, you could configure shaped unspecified bit rate (UBR) PVCs
only when the no atm pxf queuing command is configured. In Cisco IOS Release 12.3(7)XI2 and later
releases, you can configure shaped UBR PVCs when the atm pxf queuing command is configured.
When you specify shaped UBR, the router sets up layer 3 scheduling for the UBR VC in the same fashion
as VBR and CBR VCs. The VC has its own VTMS link and a set of queues assigned to it. The rate of
the link is based on the PCR you specify. Flowbits are assigned to the VC. Unlike VBR and CBR VCs,
only a single flowbit is assigned to the VC; it is not based on rate.
Like VBR and CBR VCs, the shaped UBR VCs can have queuing service policies applied to them. The
UBR VCs are not subject to any CAC checks, but the number of shaped UBR VCs must be within
existing limits, which include the maximum number of VCs per system, maximum number of VCs per
port, and maximum number of VCs with flowbits.

OL-7433-09
9-5
Chapter 9
Shaping Traffic
Traffic Shaping
Shaped UBRs on the ATM OC-12 Line Card

On an ATM OC-12 line card, when you configure UBR PVCs with a shaped value (UBR-PCR) and the
shaped value is greater than one-half of the line rate (for example, 299,520 Kbps), the following
limitations apply:
The number of VCs the OC-12 line card supports is up to one-half of the VC scaling limit of 16,384
VCs. Cisco IOS software counts each UBR-PVC above 299,520 as two VCs. Therefore, the active
VC count must be maintained at the following:
16,384 > (number of VCs at 299,520 and above * 2) + (number of VCs below 299,520)
At any time, if more VCs are active than the allowed number above, the SAR on the line card leaks
buffers, which results in a reduced buffer pool for active VCs and the SAR might fail if enough
buffers are lost. To recover the lost buffers, reboot the system.
The router allows you to enter shaping values between 299,520 and 599,040, which the SAR does
not support. The SAR performs shaping in the range of 599,040 and 299,520 to 299,538. If you
configure a shaping value between 299,528 and 399,032, the shape rate the SAR returns is unclear.
If you initially set a shaping rate of 599,040 and then change to another rate, or you initially
configure a shape rate and change to a rate of 599,040, the router accepts the command and the show
commands display the new rate. However, the SAR does not perform shaping correctly until the next
reload.
If you change the shaping rate from 599,040 to a lower rate, the LP shaper in VTMS allows the
average rate to be met. However, during traffic bursts, ATM-level shaping is not accurate.
How Hierarchical Shaping Works

The virtual time management system (VTMS) provides a single stage shaper at the packet level (IP plus
the appropriate MAC header) and the segmentation and reassembly (SAR) mechanism provides a single
stage shaper at the cell level. You can configure the SAR to shape and schedule at the VC level or VP
level. However, the SAR cannot shape and schedule at both the VC and VP levels simultaneously (for
example, shaping an individual VC and then shaping the aggregate VCs into a VP). When configured to
perform VP shaping, the SAR is configured with permanent virtual path (PVP) parameters.
Hierarchical shaping combines the single-stage VTMS and SAR mechanisms to provide a simultaneous
VC and VP shaping solution. When using hierarchical shaping, VC shaping occurs at the packet level
(using the VTMS) with the ATM VC functioning as a link scheduling mechanism.
From the perspective of the command line interface (CLI), you configure the shaped VC the same way
as you configure a regular VBR-nrt VC. Hierarchical shaping uses the CLI values you enter to configure
VTMS traffic shaping instead of SAR shaping. The VTMS schedules packets at the configured bit rate
for transmission to the appropriate line card SAR.
You configure the VP as a PVP. When you configure the VP as a constant bit rate (CBR) VP service,
hierarchical shaping uses the CLI values you enter to configure the SAR for ATM-based cell scheduling.
Hierarchical shaping shapes the ATM VC at the AAL5 packet layer on the parallel express forwarding
(PXF) processor using the VTMS. (Normally, the SAR provides this function at the cell layer in
non-PVP configurations.) The VTMS shapes the VC at the sustained cell rate (SCR) for VBR-nrt VCs
and at the peak cell rate (PCR) for CBR VCs. The VTMS uses the virtual path identifier (VPI) and the
virtual channel identifier (VCI) of VCs to associate shaped VCs with the appropriate PVP. The VTMS
places all VCs with the same VPI value in a common PVP and schedules the VCs to the SAR.
9-6
OL-7433-09
Chapter 9
Shaping Traffic
Traffic Shaping
The SAR uses weighted round-robin scheduling to schedule the PVP VCs onto the wire. The SAR also
does the following:
Assigns high rate VCs a high weighting
Ensures that cells are scheduled in accordance with the configured rate of the PVP
Offers per-VC buffering to accommodate small bursts at the VC packet level
Ensures that transmitted cells conform to ATM transmission standards, including cell delay
variation tolerance (CDVT)
The priority of the PVP is the same as the priority of CBR VCs on an interface. If the physical interface
experiences congestion, the PVPs and any CBR VC have priority over VBR-nrt VCs and unspecified bit
rate (UBR) VCs.
Hierarchical Shaping and Oversubscription

You can oversubscribe the PVP bandwidth by configuring the VCs in such a way that the sum of the VCs
bandwidths exceeds the configured rate of the PVP. The atm over-subscription-factor command is used
to configure oversubscription. This command sets up flow-control between the SAR and the VTMS, and
provides Caller Admission Control (CAC) based on the configured oversubscription value. Valid values
for oversubscription are from 0 (no oversubscription allowed) to 10.
You cannot oversubscribe the physical interface by oversubscribing the interfaces PVPs. For a given
interface, the sum of the PVPs bandwidth must be less than or equal to the physical interface speed,
minus the appropriate overhead. PVPs are subject to the same CAC mechanisms as the VCs.
The current oversubscription mechanism is optimized for VC-level fairness. When PVP congestion
occurs, the router cannot guarantee bandwidth allocation to an IP traffic class on a given VC.
The current oversubscription mechanism is optimized for VCsit is not designed to handle PVP
congestion. If VCs are oversubscribed and PVP congestion occurs, VC shaping accuracy and bandwidth
distribution can degrade.
Active ATM VCs

Table 9-1 lists the maximum number of active VCs supported on ATM line cards when configured for
hierarchical shaping.
Table 9-1
Active VCs on ATM Line Cards
Line Card
Maximum VCs per Port
Maximum VCs per Module
VBR, CBR, Shaped UBR VCs
E3/DS3
4,096
32,768
28,672
OC-3
8,192
32,768
28,672
OC-12
16,384
16,384
16,384

OL-7433-09
9-7
Chapter 9
Shaping Traffic
Traffic Shaping
Restrictions and Limitations for Hierarchical Shaping
The Cisco 10000 series router supports a maximum of 31,500 VCs when hierarchical shaping is
enabled.
You can configure a maximum of 127 VP tunnels for each ATM line card, configured across the
ports in any fashion.
You can configure the maximum number of VCs across the ports in any fashion, provided that you
do not exceed the per-port maximum.
You must have the atm pxf queuing command configured on the port. If not, the SAR still does VP
shaping and the VCs are sent to the tunnel based on a weighted round robin format; however, the
PXF does not shape the VCs. The default queuing mode for a port is atm pxf queuing.
Only variable bit rate (VBR) VCs are allowed in the VP tunnel. You cannot configure unspecified
bit rate (UBR) VCs or constant bit rate (CBR) VCs in the tunnels.
Congestion is not handled at the VP tunnel or at the port. During congestion, shaping is degraded.
During congestion at the port-level, shaping degrades to simple round robin for all VPs contending
for the ports capacity; shaping is not weighted based on the rate of the VPs.
Percentage-Based Traffic Shaping

Percentage-based shaping allows you to configure traffic shaping on the basis of a percentage of
bandwidth available on the interface. Instead of using a strict fixed-rate for shaping, percentage-based
shaping allows you to offer a shaping service that dynamically adjusts to an interface rate based on the
shape percent command configured in a policy map.
History for the Percentage-Based Shaping Feature

Cisco IOS Release
Description
Release 12.2(31)SB2 This feature was introduced on the PRE3.
PRE Required
PRE3
Frame Relay Traffic Shaping

Note
Frame Relay traffic shaping (FRTS) is available only on the PRE1.

Frame Relay traffic shaping (FRTS) is a shaping mechanism used to eliminate bottlenecks in Frame
Relay networks with high-speed connections at the central site and low-speed connections at the branch
sites. Using FRTS, you can configure rate enforcement to either the committed information rate (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 the mechanism by which multiple VCs can share media.
By allocating bandwidth to each VC, you create a virtual time-division multiplexing (TDM) network.
Defining a priority queue (PQ) or weighted fair queue (WFQ) at the VC or subinterface level allows for
finer granularity in the prioritization and queuing of traffic. As a result, you have more control over the
traffic flow on an individual VC.
9-8
OL-7433-09
Chapter 9
Shaping Traffic
Traffic Shaping
Using information contained in the BECN-tagged packets received from the network, FRTS can
dynamically throttle (decrease) traffic. When an interface configured with FRTS receives a BECN, it
immediately decreases its maximum rate and holds the packets in the buffers of the router to reduce the
data flow from the router into the Frame Relay network. If, after several intervals, the interface has not
received another BECN and traffic is waiting in the queue, the maximum rate increases slightly. FRTS
decreases traffic on a per-VC basis and adjusts the transmission rate based on the number of
BECN-tagged packets received. The dynamically adjusted maximum rate is called the derived rate.
The derived rate is always between the upper bound and the lower bound rate configured on the interface.
For more information, see the Configuring Frame Relay Traffic Shaping section on page A-5.
Feature History for Frame Relay Traffic Shaping

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The Frame Relay Traffic Shaping (FRTS) feature was

PRE1
Restrictions and Limitations for Frame Relay Traffic Shaping
Frame Relay traffic shaping applies only to Frame Relay PVCs.
Configuration Commands for Traffic Shaping

The following commands are used to configure class-based and hierarchical shaping (see the Cisco IOS
command reference documentation):
shape
shape percent
atm pvp
pvc
vbr-nrt
For information about configuring Frame Relay and Generic Traffic Shaping using Frame Relay legacy
commands, see the Configuring Frame Relay Traffic Shaping section on page A-5.

OL-7433-09
9-9
Chapter 9
Shaping Traffic

Table 9-2 describes the differences between traffic shaping mechanisms.
Table 9-2
Comparison of Traffic Shaping Mechanisms
Shaping Type
Shaping Queue
Applies Parameters
Class-Based Shaping
Class-based weighted fair queuing (CBWFQ)

inside generic traffic shaping
Per interface or per class
Not Applicable
Per VC and per VP
Hierarchical Shaping
Frame Relay Traffic Shaping (FRTS)
Weighted fair queue (WFQ), strict priority queue All virtual circuits (VCs) on an
with WFQ, custom queue (CQ), priority queue
interface through the inheritance
(PQ), or First-In-First-Out (FIFO) per VC
mechanism or per DLCI
1. Available only on the PRE1.
Bandwidth and Traffic Shaping

The router uses class queues to allocate bandwidth, first servicing priority queue traffic followed by
either bandwidth guarantee or bandwidth remaining queue traffic. By default, a minimum bandwidth
guaranteed queue has buffers for up to 50 milliseconds of 256-byte packets at line rate, but not less than
32 packets. The router does not ensure latency characteristics for bandwidth queues.
The router can commit up to 99 percent of the interface bandwidth to one or more class queues. If you
attempt to attach a policy map to an interface when the sum of the bandwidth assigned to classes is
greater than 99 percent of the available bandwidth, the router logs a warning message and does not
allocate the requested bandwidth to all of the classes. If the policy map is already attached to other
interfaces, it is removed from them.
Bandwidth includes the Layer 2 header and payload, and two bytes of trailer.
On ATM networks, the bandwidth is cell-based and includes Layer 2 overhead and cell overhead
(for example, it includes the cell overhead for SNAP and AAL5, the cell header, the AAL5 trailer,
and AAL5 padding).
On Frame Relay networks with link fragmentation and interleaving (LFI) enabled, bandwidth is
based on fragments with Layer 2 overhead included.
For a physical interface, the total bandwidth is the bandwidth of the physical interface. The router
converts the minimum bandwidth that you specify to the nearest multiple of 1/255 (PRE1) or 1/65535
(PRE2) of the interface speed. When you request a value that is not a multiple of 1/255 or 1/65535, the
router chooses the nearest multiple. Use the show policy-map interface command to display the actual
bandwidth.
The bandwidth percentage is based on the interface bandwidth. In a hierarchical policy, the bandwidth
percentage is based on the nearest parent shape rate.
9-10
OL-7433-09
Chapter 9
Shaping Traffic

Table 9-3 describes the differences between shaping and policing for bandwidth limiting.
Table 9-3
Comparison of Shaping and Policing for Bandwidth Limiting
Criteria
Shaping
Policing
Primary Function
Buffers and queues excess packets above the

committed rates.
Drops or remarks excess packets above

the committed rates.
Does not buffer.
Token Value
Bits per second (bps)
Bytes
Applicable on Inbound
No
Yes
Applicable on Outbound
Yes
Yes
Bursts
Controls bursts by smoothing the output rate.
Propagates bursts.
Uses a leaky bucket to delay traffic, resulting in Does no smoothing.

a smoothing effect.
Optional Packet Remarking
No
Yes (using the legacy committed access

rate (CAR) feature)
Advantages and Disadvantages of Shaping and Policing for

Bandwidth Limiting
As the following describes, shaping and policing both have advantages and disadvantages for limiting
bandwidth:
Advantages
Shaping
Buffers excess packets, therefore, less likely to drop excess packets.
Buffers packets up to the length of the queue. Drops may occur if excess traffic is sustained at
a high rate.
Typically avoids retransmissions due to dropped packets.
Policing
Controls the output rate through packet drops.
Avoids delays resulting from queuing.
Disadvantages
Shaping
Can introduce delay resulting from queuing (especially when deep queues are used).
Policing
Drops excess packets (when configured), throttles TCP window sizes, and reduces the overall
output rate of affected traffic streams.

OL-7433-09
9-11
Chapter 9
Shaping Traffic
Overly aggressive burst sizes can lead to excess packet drops and throttle the overall output rate
(particularly with TCP-based flows).

In Cisco IOS Release 12.3(7)XI1, when you change the weight of a VC or the VP shaping parameters,
the SAR mechanism brings down the VC or VP and the session goes down.
In Cisco IOS Release 12.3(7)XI2 and later releases, you can change the VC weight, VP shaping
parameters, or VC shaping parameters without affecting the state of the VC or VP. Instead, the VC and
VP remain up and operational.
The dynamic parameters include the following:
ATM VP parameters such as peak cell rate (PCR) and cell delay variation tolerance (CDVT)
VC parameters such as weight, PCR, sustained cell rate (SCR), maximum burst size (MBS), and
CDVT
If VC members of a VP do not have a configured weight and you dynamically modify the VP rate, the
router dynamically adjusts the weight of the member VCs based on the associated tunnels new rate. The
member VCs remain up as their weights are dynamically modified.
If you dynamically modify the tunnel VCs shaping parameters (for example, the PCR or SCR), the
router adjusts the weight of the tunnel VC based on the VC speed if no weight is configured for the VC.
If a VC weight is configured, the router adjusts the weight of the tunnel VC based on the configured
weight.
Example Scenarios of Traffic Shaping Usage

Traffic shaping is primarily used to control access to available bandwidth, to ensure that traffic conforms
to the policies established for it, and to regulate the flow of traffic to avoid congestion that can occur
when the transmitted traffic exceeds the access speed of its remote target interface.
The following describe scenarios in which you can apply traffic shaping to interfaces to regulate traffic:
Controlling access to bandwidthA policy stipulates that the rate of a given interface should not,
on the average, exceed a certain rate, even though the access rate exceeds the speed.
Differing access rates defined in a networkOne end of a 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.
Differing access rates defined on different DTEsA link-layer network is giving indications of
congestion. The network has differing access rates defined on different DTEs attached to the
network. The network might 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.)
Offering subrate servicesIf you offer a subrate service, traffic shaping enables you to partition T1
or T3 links into smaller channels.
Preventing packet lossTraffic shaping prevents packet loss. Using traffic shaping is especially
important in Frame Relay networks because the switch cannot determine which packets take
precedence. As a result, the switch cannot determine which packets to drop when congestion occurs.
It is critically important for real-time traffic 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
9-12
OL-7433-09
Chapter 9
Shaping Traffic
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.)

The following describes interface support for traffic shaping:
Physical
Frame Relay permanent virtual circuits (PVCs), point-to-point subinterfaces, and map classes **
Ethernet VLANs **
* Requires a specific type of hierarchical policy or a policy map with only the class-default class defined.
The class-default class must have the shape command configured.
** Requires a specific type of hierarchical policy. For more information, see Chapter 13, Defining QoS
Note
The router supports traffic shaping only on outbound interfaces.

Interfaces Not Supporting Traffic Shaping
Note
IP tunnel
The router does not support traffic shaping on inbound interfaces.
Configuring Traffic Shaping

To configure traffic shaping, perform the following configuration tasks:
Shaping a Traffic Class, page 9-14
Shaping Traffic at the VC-Level and Virtual Path-Level, page 9-15

OL-7433-09
9-13
Chapter 9
Shaping Traffic
Shaping a Traffic Class

To shape a traffic class to control the flow of traffic on an interface, enter the following commands
Note
Step 1
These steps configure class-based traffic shaping, which can be applied to interfaces, subinterfaces, VCs,
and DLCIs.
Command
Purpose
Creates or modifies a policy map.

policy-map-name is the name of the child policy map. The
name can be a maximum of 40 alphanumeric characters.
Step 2
map and is the traffic class you want to shape.
Step 3
Router(config-pmap-c)# shape [average] cir

or
Router(config-pmap-c)# shape [average]
percent percentage [be excess-burst-in-msec
ms] [bc committed-burst-in-msec ms]
Shapes traffic to the rate you specify, or shapes traffic based

on the percentage of available bandwidth you specify.
average is the committed burst (Bc) that specifies the
maximum number of bits sent out in each interval. This
option is only supported on the PRE3.
cir specifies the committed information rate (CIR), in bits per
second (bps).
percent percentage specifies the percentage of available
bandwidth to allocate.
(Optional) be excess-burst-in-msec ms is the excess (peak)
burst (be) size in milliseconds (ms).
(Optional) bc committed-burst-in-msec ms is the committed
(conform) burst (bc) size in milliseconds (ms).
Step 4
Router(config-pmap-c)# shape max-buffers

number-of-buffers
(Optional) Specifies the maximum number of buffers allowed

on shaping queues.
number-of-buffers specifies the maximum number of buffers.
Valid values are from 1 to 4096.
Step 5
Router(config-pmap-c)# service-policy
policy-map-name
(Optional) Applies the child policy map you specify to the

traffic class. The router applies the QoS actions specified in
the child policy to the traffic class.
policy-map-name is the name of the child policy.
Note
Do not specify the output or input keywords.
For more information, see Chapter 13, Defining QoS for

Multiple Policy Levels.
9-14
OL-7433-09
Chapter 9
Shaping Traffic
Shaping Traffic at the VC-Level and Virtual Path-Level

To shape traffic at the VC-level and simultaneously shape traffic at the virtual path (VP)-level, enter the
Note
Step 1
These steps configure hierarchical shaping. Use these commands to shape an individual VC and then
shape the aggregate VCs into a VP.
Command
Purpose

slot/module/port
Creates or modifies an ATM interface. Enters interface

configuration mode.
slot/module/port is the interface number.
Step 2
Router(config-if)# atm
over-subscription-factor factor
(Optional) Enables oversubscription on ATM virtual circuits and

specifies the factor by which the sum of the sustained cell rate
(SCR) values of all VCs in a tunnel can oversubscribe the tunnels
peak cell rate (PCR).
factor specifies the amount of oversubscription. Valid values are
from 1 to 500. The default value is 1, which indicates no
oversubscription.
Step 3
Router(config-if)# atm pvp vpi

[peak-rate] [cdvt]
Creates a permanent virtual path (PVP) used to multiplex (or

bundle) one or more virtual circuits (VCs).
vpi is the ATM network virtual path identifier (VPI) of the VC.
Valid values are 0 to 255. The vpi value is unique only on a single
link, not throughout the ATM network because it has local
significance only.
Note
The number specified for the vpi must not already exist. If
the number specified is already being used by an existing
VC, the router rejects this command.
(Optional) peak-rate is the maximum rate in kbps at which the

PVP can transmit data. Valid values are 84 kbps to line rate. The
default is the line rate.
(Optional) cdvt is the cell delay variation tolerance (CDVT).
Step 4

Creates or modifies an ATM subinterface.

slot/module/port.subinterface is the number of the subinterface
that identifies the subinterface.
point-to-point indicates that the subinterface is a point-to-point
subinterface.
multipoint indicates that the subinterface is a point-to-multipoint
subinterface.
Step 5
Router(config-if)# pvc vpi/vci
Creates an ATM permanent virtual circuit (PVC) and enters ATM

virtual circuit configuration mode.

OL-7433-09
9-15
Chapter 9
Shaping Traffic
Step 6
Command
Purpose
Router(config-if-atm-vc)# vbr-nrt
output-pcr output-scr output-mbs
Enables shaping on the ATM PVC and configures variable bit

rate-nonreal time (VBR-NRT) quality of service (QoS).
output-pcr is the peak cell rate (PCR) for outbound traffic.
output-scr is the sustained cell rate (SCR) for outbound traffic.
(Optional) output-mbs is the output maximum burst cell size, in
number of cells.
Step 7
Router(config-if-atm-vc)# encapsulation
{aal5mux ppp virtual-template number |
aal5ciscoppp virtual-template number |
aal5snap}
Configures the ATM adaptation layer (AAL) and encapsulation

type for an ATM virtual circuit (VC).
aal5mux ppp specifies the AAL and encapsulation type for
multiplex (MUX)-type VCs. The keyword ppp is Internet
Engineering Task Force (IETF)-compliant PPP over ATM. It
specifies the protocol type being used by the MUX encapsulated
VC.
aal5ciscoppp specifies the AAL and encapsulation type for Cisco
PPP over ATM.
aal5snap specifies the AAL and encapsulation type that supports
Inverse ARP. Logical Link Control/Subnetwork Access Protocol
(LLC/SNAP) precedes the protocol datagram.
virtual-template number is the number used to identify the
virtual template.
Step 8
Router(config-atm-vc)# queue-depth hwm

lwm
(Optional) Defines the queue-depth size by setting the high and

low watermarks. This ensures the correct shaping of traffic.
hwm is the high watermark. The value you specify is not required
to be higher than 288.
lwm is the low watermark. The value you specify is not required
to be higher than 256.
For information about the default high and low watermark values,
see the High Watermark and Low Watermark Default Values
Note
The values for high and low watermarks of a VC queue

depend greatly on the queues configuration, its purpose,
and usage. We recommend that you configure watermark
values small enough so as to avoid exhausting the line
card buffer. When the queues exhaust the buffer, packets
are randomly dropped, which can cause the loss of critical
system traffic.
9-16
OL-7433-09
Chapter 9
Shaping Traffic
Verifying Traffic Shaping
Configuration Example for Traffic Shaping at the VC-Level and the VP-Level
Example 9-1 configures hierarchical shaping and shapes traffic at the VC-level and the VP-level. In the
example, shaping is enabled on PVC 1/36 on ATM interface 5/0/0.
Example 9-1
Configuring Traffic Shaping at the VC-Level and the VP-Level

Router(config-if)# atm over-subscription-factor 50
Router(config-if)# atm pvp 1 1000 cdvt 600
Router(config-if)# pvc 1/36
Router(config-atm-vc)# vbr-nrt 1000 512
Router(config-atm-vc)# encapsulation aal5mux ppp Virtual-Template1
Router(config-atm-vc)# queue-depth 288 256
Router(config-atm-vc)# exit

To verify the configuration of traffic shaping, enter any of the following commands in privileged EXEC
mode:
Command
Purpose
Router# show atm vp [vpi]
Displays the statistics for all virtual paths (VPs) on an interface

or for a specific VP.
(Optional) vpi is the ATM network virtual path identifier (VPI)
for the permanent virtual path (PVP). Valid values are from 0 to
255. The VPI is an 8-bit field in the header of the ATM cell.
Router# show atm vc [vcd] [interface

interface-number]
Displays all ATM permanent virtual circuits (PVCs) and traffic

information.
(Optional) vcd specifies a virtual circuit. When you specify vcd,
information about only the specified virtual circuit displays.
(Optional) interface interface-number is the interface number or
subinterface number of the PVC. When you specify interface
interface-number, information about all of the PVCs on the
specified interface or subinterface displays.
Router# show controllers atm slot/module/port
Displays ATM controller status.

Use this command to ensure that packets are not being discarded
due to internal buffer exhaustion.
slot/module/port is the interface number.
Displays the configuration of all policy maps configured on the

router.
Displays the configuration of all of the classes configured in all

of the policy maps that are attached to all of the router interfaces.

OL-7433-09
9-17
Chapter 9
Shaping Traffic
Command
Purpose

[input | output]

interface.
interface interface is the type and number of the interface or
subinterface to which the policy configuration you want to
display is attached.
policy.
outbound policy.
Note

you specify.

map you specify.
policy-map-name is the name of the policy map for the
configuration information you want to display.

class-name

Router# show pxf cpu queue atm number
Displays the number of dropped and dequeued packets for each

VC on the interface, and for classes associated with sessions that
inherit queues from VCs. Also, monitors the current capacity of
the queue.
number is the number of the interface or subinterface.
Router# show running-config
Displays the contents of the currently running configuration file.
Router# show running-config [interface interface]
Displays the configuration of the interface you specify that is

currently configured in the running-config file, including any
service policies attached to the interface.
(Optional) interface interface is the type and number of the
interface.
9-18
OL-7433-09
Chapter 9
Shaping Traffic
Verification Examples for Traffic Shaping

Example 9-2 shows sample output from the show atm vp command for a specific virtual path identifier
(VPI). The output displays packet counts, AAL and encapsulation, the status of each PVC with a VPI of
10, and the total packet counts for the PVP.
Example 9-2
show atm vp Command Sample Output for a Specific VPI
Router# show atm vp 10

ATM7/0/0 VPI: 10, PeakRate: 1000, CesRate: 0, CDVT: 35.0 Usecs, DataVCs: 10
CesVCs: 0, Status: ACTIVE
VCD VCI Type InPkts OutPkts AAL/Encap Status
1
3
PVC
0
0
F4 OAM ACTIVE
2
4
PVC
0
0
F4 OAM ACTIVE
3
33 PVC 4007
6632
AAL5-MUX ACTIVE
4
34 PVC 4009
6625
AAL5-MUX ACTIVE
5
35 PVC 4008
6625
AAL5-MUX ACTIVE
6
36 PVC 4011
6625
AAL5-MUX ACTIVE
7
37 PVC 4014
6624
AAL5-MUX ACTIVE
8
38 PVC 4013
6636
AAL5-MUX ACTIVE
9
39 PVC 4010
3
AAL5-MUX ACTIVE
10 40 PVC 4012
3
AAL5-MUX ACTIVE
11 41 PVC 4009
3
AAL5-MUX ACTIVE
12 42 PVC 4010
3
AAL5-MUX ACTIVE
TotalInPkts: 40103, TotalOutPkts: 39779, TotalInFast: 0, TotalOutFast: 39779,
TotalBroadcasts: 0
TotalInPktDrops: 0, TotalOutPktDrops: 0
Example 9-3 shows sample output from the show atm vp command. The output displays the
configuration of the virtual path (VP) with an identifier of 10.
Example 9-3
show atm vp Command Sample Output
Router# show atm vp

Data CES Peak CES CDVT
Interface VPI VCs VCs Kbps Kbps Usecs Status
ATM7/0/0
10 10
0 1000
0
35.0 ACTIVE
Example 9-4 shows sample output from the show pxf cpu queue atm command. The output indicates
the number of packets dropped and dequeued for VC 1/229 and VC 1/233.
Example 9-4
show pxf cpu queue Command Sample Output
Router# show pxf cpu queue atm 5/0/2

VCCI 2517: ATM non-aggregated VC 1/229, VCD 1, Handle 1, Rate 500 kbps
VCCI/ClassID
0 2517/0
0 2517/31
ClassName
class-default
pak-priority
QID
269
268
Length/Max
0/4096
0/32
Res
11
11
Dequeues
3
4
Drops
0
0
Queues Owned but Unused by VC (inheritable by sessions)

ClassID
0
31
ClassName
class-default
pak-priority
QID
275
268
Length/Max
0/32
0/32
Res
11
11
Dequeues
100
4
Drops
0
0
VCCI 2517: ATM non-aggregated VC 1/233, VCD 4, Handle 4, Rate 50 kbps

VCCI/ClassID
0 2517/0
ClassName
class-default
QID
269
Length/Max
0/4096
Res
11
Dequeues
3
Drops
0

OL-7433-09
9-19
Chapter 9
Shaping Traffic
0 2517/31
pak-priority
268
0/32
11
Dequeues
0
4
Drops
0
0
Queues Owned but Unused by VC (inheritable by sessions)

ClassID
0
31
ClassName
class-default
pak-priority
QID
274
268
Length/Max
0/32
0/32
Res
11
11
Example 9-5 shows sample output from the show controllers atm command. The output indicates that
no output packets were discarded due to internal buffer exhaustion.
Example 9-5
show controllers atm Command Sample Output
Router# show controllers atm 6/0/0

ATM6/0/0, Card type is 4oc3atm-1 (0x02D8)
The current state of the controller is up.
Current configurable parameter settings;
Clock source is LINE, Loopback is NONE, Framing is SONET,
Cell payload scrambling is enabled, STS stream scrambling is enabled,
MTU is 4470, PXF queuing is enabled, hold-queue is 27230
Burst tolerance floor 2
Total subscribed rate is 50000, flowbit change 90 / no change 0
Configuration collisions 0
SECTION
LOF =0LOS=0RDOOL=0BIP(B1)=0
LINE
AIS=0RDI=0FEBE=0BIP(B2)=0
PATH
AIS=0RDI=0FEBE=0BIP(B3)=0
LOP=0NEWPTR =0PSE=0NSE=0
LCD=0
Active Defects: None
Active Alarms: None
Alarm reporting enabled for: SF SLOS SLOF B1-TCA LAIS LRDI B2-TCA PAIS PLOP PRDI B3-TCA
RDOOL LCD
PATH TRACE BUFFER: STABLE
Remote hostname:
Remote interface:
Remote IP addr:
Remote Rx(K1/K2): / Tx(K1/K2): /
BER thresholds: SF = 10e-3 SD = 10e-6
TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6
Per
0
0
0
0
0
0
0
Card Statistics:
Input Packets Discarded, queue exhaustion
Input Packets Discarded, no host buffers
Output Packets Discarded, no channel
Output Packets Discarded, MRED
Output Packets Discarded, internal buffer exhaustion
Output Packets Discarded, Utopia RX errors
Output Packets Discarded, EPD
9-20
OL-7433-09
Chapter 9
Shaping Traffic
Configuration Examples for Traffic Shaping
Configuration Examples for Traffic Shaping

This section provides the following sample configurations for traffic shaping:
Configuration Example for Class-Based Shaping, page 9-21
Configuration Examples for Hierarchical Shaping, page 9-21
Configuration Example for Class-Based Shaping

Example 9-6 defines one class named c1, which is configured to shape traffic to 384 kbps with a normal
burst size of 15,440 bits.
Example 9-6
Configuring Class-Based Shaping
policy-map shape
class c1
shape average 38400 15440
!
interface serial 3/3/0
service-policy output shape
Note
The shape average command is available only on the PRE3. The PRE2 supports the shape cir command.
Configuration Examples for Hierarchical Shaping

Example 9-7 shows how to configure hierarchical shaping. In this example, the total VC bandwidth (the
sum of SCR) is above the tunnel rate. The PVP is configured with a PCR of 1000 kbps and is
oversubscribed by the total rate of the VCs (2 VCs at 256 kbps and 2 VCs at 512 kbps). The queue-depth
command ensures the correct shaping.
Example 9-7
Configuring Hierarchical Shaping
interface ATM5/0/0
no ip address
no ip mroute-cache
atm over-subscription-factor 50
atm pvp 1 1000 cdvt 600
no atm auto-configuration
no atm ilmi-keepalive
no atm address-registration
no atm ilmi-enable
!
pvc 1/33
vbr-nrt 1000 256
encapsulation aal5mux ppp Virtual-Template1
queue-depth 288 256
!
!
pvc 1/34
vbr-nrt 1000 256
queue-depth 288 256

OL-7433-09
9-21
Chapter 9
Shaping Traffic
!
!
pvc 1/35
vbr-nrt 1000 512
queue-depth 288 256
!
!
pvc 1/36
vbr-nrt 1000 512
queue-depth 288 256
!
Feature
ATM overhead accounting
Traffic Shaping Overhead Accounting for ATM, Release 12.2(31)SB2 feature

module.
Class-based shaping

Part 4: Policing and Shaping > Configuring class-Based Shaping
Class maps

Percentage-Based Traffic Shaping
QoS: Percentage-Based Shaping, Release 12.2(31)SB2 feature module
Policing
Policy maps


tech note
tech note
Traffic shaping

Part 4: Policing and Shaping
9-22
OL-7433-09
CH A P T E R
10
Overhead Accounting
This chapter describes overhead accounting on the Cisco 10000 series router and contains the following
topics:
Overhead Accounting Features, page 10-1
Configuration Commands for Overhead Accounting, page 10-5
Subscriber Line Encapsulation Types, page 10-5
Overhead Calculation on the Router, page 10-5
Overhead Accounting and Hierarchical Policies, page 10-6
Restrictions and Limitations for Overhead Accounting, page 10-7
Configuring Overhead Accounting in a Hierarchical Policy, page 10-7
Configuration Examples for Overhead Accounting, page 10-10
Verifying Overhead Accounting, page 10-12
Verification Examples for Overhead Accounting, page 10-13
Overhead Accounting Features

Overhead accounting enables the router to account for packet overhead when shaping traffic to a specific
rate. This accounting ensures that the router executes quality of service (QoS) features on the actual
bandwidth used by subscriber traffic.
The Cisco 10000 series router supports the following overhead accounting features:
ATM Overhead Accounting, page 10-2
MLP on LNS with HQoS and ATM Overhead Accounting, page 10-3
Traffic Shaping Overhead Accounting for ATM, page 10-4
Ethernet Overhead Accounting, page 10-4

OL-7433-09
10-1
Chapter 10
Overhead Accounting
Feature History for Overhead Accounting

Required PRE1
Cisco IOS Release
Description
Release 12.3(7)XI7
The ATM Overhead Accounting feature was introduced on PRE2

the router to enable the router to account for various
encapsulation types when applying QoS to packets.
Release 12.2(28)SB
The ATM Overhead Accounting feature was introduced in PRE2

Cisco IOS Release 12.2(28)SB.
Release 12.2(31)SB2
The Traffic Shaping Overhead Accounting for ATM

feature was introduced on the PRE3.
Release 12.2(33)SB
The Ethernet Overhead Accounting feature was introduced PRE2

on the PRE2, PRE3, and PRE4. ATM overhead accounting PRE3
was enhanced on the PRE3 to allow a user-defined number PRE4
of overhead bytes and introduced on the PRE4. The PRE4
inherits all overhead accounting features from the PRE3.
Release 12.2(33)SB2
The MLP on LNS with HQoS and ATM Overhead

Accounting feature was introduced on the PRE3 and
PRE4.
PRE3
PRE3
PRE4
1. Performance Routing Engine (PRE)
ATM Overhead Accounting

ATM overhead accounting enables the router to account for various encapsulation types when applying
QoS to packets. Typically, in Ethernet Digital Subscriber Line (DSL) environments, the encapsulation
from the router to the DSLAM is Gigabit Ethernet and the encapsulation from DSLAM to customer
premise equipment (CPE) is ATM. ATM overhead accounting enables the router to account for ATM
encapsulation on the subscriber line and for the overhead added by cell segmentation. This accounting
enables the service provider to prevent overruns at the subscriber line and ensures that the router
executes QoS features on the actual bandwidth used by ATM packets.
The router uses the encapsulation type you configure to calculate the ATM overhead per packet. When
calculating ATM overhead at the subscriber line, the router considers the encapsulation used between
the router and DSLAM and between the DSLAM and CPE (as described in the following list). You
configure the encapsulation type and the router calculates the overhead associated with ATM cell
segmentation.
IEEE 802.1Q and qinq encapsulation are typically used between the router and DSLAM. Because
the DSLAM removes the encapsulation, the router does not account for this encapsulation in the
calculation.
The encapsulation used between the DSLAM and the CPE is based on the Subnetwork Access
Protocol (SNAP) and multiplexer (MUX) formats of ATM Adaptation Layer 5 (AAL5) and AAL3.
These encapsulation types can be routed bridge encapsulation (RBE), PPP over Ethernet (PPPoE),
or PPP over ATM (PPPoA), and IP. Because the DSLAM treats IP and PPPoE packets as payload,
the router does not account for IP and PPPoE encapsulation in the calculation.
AAL5 segmentation processing adds the additional overhead of the 5-byte cell headers, the AAL5
Common Part Convergence Sublayer (CPCS) padding, and the AAL5 trailer. For more information, see
the Overhead Calculation on the Router section on page 10-5.
10-2
OL-7433-09
Chapter 10
Overhead Accounting
MLP on LNS with HQoS and ATM Overhead Accounting

MLP on LNS (MLPoLNS) sessions are shaped at a negotiated bandwidth that reflects the downstream
link bandwidth on the CPE. The link bandwidth on the L2TP network server (LNS) is received on the
line either through the connect speed attribute-value pairs (AVP) or PPPoE tags from the L2TP access
concentrator (LAC).
In releases earlier than Cisco IOS 12.2(33), hierarchical policies were not supported on MLPoLNS
single-member bundles. With MLPoLNS, if LNS sessions do not have a defined bandwidth associated
with the session, users must specify the bandwidth of the MLP bundle in the downstream direction (LNS
toward the CPE) to avoid drops downstream. The bandwidth of the bundle is the aggregate of all the
member links. For single-member MLPoLNS bundles, the bundle bandwidth is the same as the members
link bandwidth. With hierarchical policies, the parent shape value overrides the bandwidth received
through the AVP or PPPoE tag.
For more information on the MLP at LNS feature, see the Configuring Multilink Point-to-Point
Protocol Connections chapter in the Cisco 10000 Series Router Software Configuration Guide at the
following URL:
http://www.cisco.com/en/US/docs/routers/10000/10008/configuration/guides/broadband/mlp.html
The MLP on LNS with HQoS and ATM Overhead Accounting feature is described in the following
sections:
HQoS, page 10-3
Overhead Accounting, page 10-3
Restrictions and Limitations for Overhead Accounting, page 10-7
Enabling ATM Overhead Accounting on the PRE3 and PRE4 for MLPoLNS, page 10-11
HQoS
The HQoS bandwidth from the parent policy overrides the default bandwidth (based on the rate received
on the line) of the bundle. When the parent policy is removed, the default value is restored.
The users RADIUS environment is responsible for providing the HQoS policy after determining the rate
from the connect speed AVP and PPPoE downstream rate tag. The changes assume that platform will be
presented the service policies (after the algorithm has run) through the existing API.
Overhead Accounting
With overhead accounting, the downstream transmission rate from the LNS is adjusted to meet the
LAC-to-CPE bandwidth. This adjustment accounts account for the difference between the LNS-to-LAC
overhead versus the LAC-to-CPE overhead to achieve optimal link utilization for the LAC-to-CPE
interface. The overhead differences include IP/UDP/L2TP headers over the L2TP tunnel, as well as the
header size and segmentation overhead when the physical interface from the LNS is Gigabit Ethernet
and the LAC-to-CPE interface is ATM. Proper accounting can also avoid loss of data from any overruns
between the LAC and the CPE.

OL-7433-09
10-3
Chapter 10
Overhead Accounting
Traffic Shaping Overhead Accounting for ATM

The Traffic Shaping Overhead Accounting for ATM feature enables the broadband aggregation system
(BRAS) to account for various encapsulation types when applying QoS to packets. Typically, in Ethernet
Digital Subscriber Line (DSL) environments, the encapsulation from the BRAS to the DSLAM is
Gigabit Ethernet and the encapsulation from the DSLAM to the CPE is ATM. ATM overhead accounting
enables the BRAS to account for ATM encapsulation on the subscriber line and for the overhead added
by cell segmentation. This accounting enables the service provider to prevent overruns at the subscriber
line and ensures that the router executes QoS features on the actual bandwidth used by ATM subscriber
traffic.
The BRAS uses the encapsulation type you configure for the DSLAM-CPE side to calculate the ATM
overhead per packet, except for IP and PPPoE packets. DSLAM-CPE encapsulation types are based on
SNAP and MUX formats of ATM Adaptation Layer 5 (AAL5), followed by routed bridge encapsulation
(RBE), IP, PPP over Ethernet (PPPoE), or PPP over ATM (PPPoA). Because the DSLAM treats IP and
PPPoE packets as payload, the BRAS does not account for these encapsulations.
On the BRAS-DSLAM side, encapsulation is IEEE 802.1Q VLAN or qinq. However, because the
DSLAM removes the BRAS-DSLAM encapsulation, the BRAS does not account for 802.1Q or qinq
encapsulation.
AAL5 segmentation processing adds the additional overhead of the 5-byte cell headers, the AAL5
Common Part Convergence Sublayer (CPCS) padding, and the AAL5 trailer. For more information, see
the Overhead Calculation on the Router section on page 10-5.
If the parent policy has overhead accounting enabled, you are not required to explicitly enable
accounting on the child policy because, by default, child priority queues that do not contain the shape
or bandwidth command have ATM overhead accounting enabled implicitly.
By default, child priority queues that do not contain the shape or bandwidth command have ATM
overhead accounting enabled implicitly if the parent policy has overhead accounting enabled; you are
not required to explicitly enable accounting on the child policy.
If a child traffic class contains the shape or bandwidth command, you must explicitly enable ATM
overhead accounting on the class.
Ethernet Overhead Accounting

The Ethernet Overhead Accounting feature enables the router to account for downstream Ethernet frame
headers when applying shaping to packets. A user-defined offset specifies the number of overhead bytes
the router is to use when calculating the overhead per packet. Valid offset values are from +63 bytes to
-63 bytes of overhead. Before applying shaping, the router calculates the overhead.
Ethernet interfaces and subinterfaces support overhead accounting. Using the shape or bandwidth
command, you can configure accounting per VLAN and per port.
10-4
OL-7433-09
Chapter 10
Overhead Accounting

To enable overhead accounting, use the shape and bandwidth commands. These commands allow you
to specify the encapsulation type and user-defined offset that the router uses in calculating overhead. The
commands have the following syntax:
shape rate [account {{qinq | dot1q} {aal5 | aal3} {subscriber-encap}} | {user-defined offset
[atm]}]
bandwidth {bandwidth-kbps | percent percentage | remaining percent percentage} {{qinq |
dot1q} {aal5 | aal3} {subscriber-encap}} | {user-defined offset [atm]}]
Note
The options {{qinq | dot1q} {aal5 | aal3} {subscriber-encap}} and {user-defined offset [atm]} are
mutually exclusive.
Subscriber Line Encapsulation Types

The subscriber-encap option of the shape and bandwidth commands specifies the encapsulation type
at the subscriber line. The router supports the following subscriber line encapsulation types:
snap-1483routed
mux-1483routed
snap-dot1q-rbe
mux-dot1q-rbe
snap-pppoa
mux-pppoa
snap-rbe
mux-rbe
Overhead Calculation on the Router

When calculating overhead for traffic shaping, the router considers the encapsulation type used between
the BRAS and the DSLAM, and between the DSLAM and CPE.
Table 10-1 describes the fields the router uses for the various encapsulation types when calculating ATM
overhead.
Table 10-1
Overhead Calculation
Encapsulation Type
Number of Bytes
Description
802.1Q
18
6-byte destination MAC address + 6-byte source MAC

address + 2-byte protocol ID (0x8100) + 2-byte
VID/CFI/PRIORITY + 2-byte length/type
802.3
14

address + 2-byte protocol ID (0x8000)
AAL5 MUX plus 1483
8-byte AAL5 trailer

OL-7433-09
10-5
Chapter 10
Overhead Accounting
Table 10-1
Overhead Calculation (continued)
Encapsulation Type
Number of Bytes
Description
AAL5 MUX plus PPPoA
10
8-byte AAL5 trailer + 2-byte protocol ID (0x0021)
AAL5 SNAP plus 1483
18
8-byte AAL5 trailer + 3-byte LLC header

(0xAAAA03) + 3-byte OUI (0x0080c2) + 2-byte
protocol ID (0x0007) + 2-byte PAD (0x0000)
AAL5 SNAP plus PPPoA
12
8-byte AAL5 trailer + 3-byte LLC header (0xFEFE03)

+ 1-byte protocol ID (0xCF)
PPPoE
1-byte version/type (0x11) + 1-byte code (0x00) +

2-byte session ID + 2-byte length
qinq
22

address + 2-byte protocol ID (0x8100) + 2-byte
VID/CFI/PRIORITY + 2-byte protocol ID + 2-byte
inner tag + 2-byte length or type

In hierarchical policies, you can enable overhead accounting for shaping and bandwidth on top-level
parent policies, middle-level child policies, and bottom-level child policies. If you enable overhead
accounting on a:
Parent class-default class, you are not required to enable accounting on a child traffic class that does
not contain the bandwidth or shape command.
Child policy, then you must enable overhead accounting on the parent policy.
The parent and child classes must specify the same encapsulation type when enabling overhead
accounting and configuring an offset using the user-defined offset [atm] command option.
Table 10-2 summarizes the configuration requirements for overhead accounting. For example, if
overhead accounting is currently enabled for a parent policy, then accounting can be disabled or enabled
on a child policy.
Table 10-2
Overhead Accounting Configuration Requirements
Policy Map or Class
Current Configuration
Configuration Requirement
Parent
Enabled
Enabled on child policy
Child
Enabled
Enabled on parent policy
Child class
Enabled
Enabled on all classes in the child policy map,

except priority classes with policing
Child class (nonpriority

without policing)
Disabled
Disabled on all classes in the child policy map
Child class (priority with

policing)
Disabled
Disabled or enabled on all nonpriority classes

in the child policy map
10-6
OL-7433-09
Chapter 10
Overhead Accounting
You can enable overhead accounting for shaping and bandwidth on top-level parent policies,
middle-level child policies, and bottom-level child policies.
If you enable overhead accounting on a parent policy, you are required to enable accounting on a
child policy that is configured with the shape or bandwidth command. You are not required to
enable accounting on a child policy that does not have the shape or bandwidth command
configured.
If you enable overhead accounting on a child policy, then you must enable overhead accounting on
the parent policy.
In a policy map, you must either enable overhead accounting for all classes in the policy or disable
overhead accounting for all classes in the policy. You cannot enable overhead accounting for some
classes and disable overhead accounting for other classes in the same policy.
The router supports overhead accounting only for the shape and bandwidth commands.
When you enter the show policy-map interface command, the resulting classification byte counts
and the queuing feature byte counts do not match. This mismatch occurs because the classification
byte count does not consider overhead, whereas the queuing features do consider overhead.
This feature supports only Ethernet and ATM interfaces.
Ethernet overhead accounting allows the automatic inclusion of downstream Ethernet frame headers
in the shaped rate. However, policing is not supported for Ethernet overhead accounting.
For the MLPoLNS feature, overhead accounting is supported only on HQoS.
For MLPoLNS, HQoS with overhead accounting is supported only on single-member bundles and
not on multimember bundles.
QoS restriction on the main interface also apply to single-member MLPoLNS virtual-access bundles
(for example, oversubscription of the bundle bandwidth with a parent shaper).
For MLPoLNS single-member bundles with HQoS, 100 Mbps is the default bundle bandwidth. The
bandwidth received on the line (Connect speed of AVP pairs or PPPoE tags) at the LNS overrides
this bandwidth. If the connection speed of an AV pair of the MLP bundle is arbitrarily low,
overriding with shaper is not possible.
For the MLPoLNS feature, applying service policies on physical interfaces is not supported. Service
policies must be applied on the virtual template of the MLP bundle or from the RADIUS server.

To configure overhead accounting in a hierarchical policy, enter the following commands beginning in
Step 1
Command
Purpose
Creates or modifies the child policy. Enters policy-map

configuration mode.

OL-7433-09
10-7
Chapter 10
Overhead Accounting
Step 2
Command
Purpose

class map.
Step 3
remaining percent percentage} [account {{qinq
| dot1q} {aal5} {subscriber-encap}} |
{user-defined offset [atm]}]
Enables class-based fair queuing and overhead accounting.

percentage specifies or modifies the maximum percentage
of the link bandwidth allocated for a class belonging to a
policy map. Valid values are from 1 to 99.
remaining percentage specifies or modifies the minimum
percentage of unused link bandwidth allocated for a class
account enables ATM overhead accounting.
qinq specifies queue-in-queue encapsulation as the
BRAS-DSLAM encapsulation type.
dot1q specifies IEEE 802.1Q VLAN encapsulation as the
aal5 specifies the ATM Adaptation Layer 5 that supports
connection-oriented variable bit rate (VBR) services.
subscriber-encap specifies the encapsulation type at the
subscriber line. For more information, see the Overhead
Accounting and Hierarchical Policies section on
page 10-6.
user-defined indicates that the router is to use the offset
value you specify when calculating ATM overhead.
offset specifies the number of bytes the router is to use when
calculating overhead. Valid values are from -63 to 63 bytes.
atm applies the ATM cell tax in the ATM overhead
calculation.
Note
Configuring both the offset and atm options adjusts

the packet size to the offset size and then adds the
ATM cell tax.
Step 4
Step 5
Router(config-pmap)# policy-map policy-map-name
Creates or modifies the top-level parent policy.

policy-map-name is the name of the parent policy map. The
Step 6
Configures or modifies the parent class-default class.
10-8
OL-7433-09
Chapter 10
Overhead Accounting
Step 7
Command
Purpose
Router(config-pmap-c)# shape [average] rate

[account {{qinq | dot1q} {aal5}
{subscriber-encap}} | {user-defined offset
[atm]}]
Shapes traffic to the indicated bit rate and enables overhead

accounting.
(Optional) average is the committed burst (Bc) that
specifies the maximum number of bits sent out in each
interval. This option is only supported on the PRE3.
rate indicates the bit rate used to shape the traffic, in bits per
second. When this command is used with backward explicit
congestion notification (BECN) approximation, the bit rate
is the upper bound of the range of bit rates that are
permitted.
Accounting and Hierarchical Policies section on
page 10-6.
user-defined indicates that the router is to use the offset
value you specify when calculating ATM overhead.
offset specifies the number of bytes the router is to use when
calculating overhead. Valid values are from -63 to +63
bytes. The router configures the offset size if you do not
specify the offset option.
atm applies the ATM cell tax in the ATM overhead
calculation.
Note
Step 8
policy-map-name
Configuring both the offset and atm options adjusts

the packet size to the offset size and then adds the
ATM cell tax.
Applies a child policy to the parent class-default class.

policy-map-name is the name of a previously configured
child policy map.
Note
Do not specify the input or output keywords when

applying a child policy to a parent class-default
class.

OL-7433-09
10-9
Chapter 10
Overhead Accounting
Configuration Examples for Overhead Accounting

Enabling ATM Overhead Accounting, page 10-10
Enabling ATM Overhead Accounting on the PRE3 and PRE4 for MLPoLNS, page 10-11
Enabling Ethernet Overhead Accounting on the PRE2, page 10-11
Enabling Ethernet Overhead Accounting on the PRE3 and PRE4, page 10-12
Enabling ATM Overhead Accounting

The following configuration example shows how to enable ATM overhead accounting using a
hierarchical policy. The Child policy map has two classes: Business and Nonbusiness. The Business
class has priority and is policed at 128,000 kbps. The Nonbusiness class has ATM overhead accounting
enabled and has a bandwidth of 20 percent of the available bandwidth. The Parent policy map shapes the
aggregate traffic to 256,000 kbps and enables ATM overhead accounting.
Notice that Layer 2 overhead accounting is not explicitly configured for the Business traffic class. If the
class-default class of a parent policy has ATM overhead accounting enabled, you are not required to
enable ATM overhead accounting on a child traffic class that does not contain the bandwidth or shape
command. Therefore, in this example, the Business priority queue implicitly has ATM overhead
accounting enabled because its parent class-default class has overhead accounting enabled.
policy-map Child
class Business
priority
police 128000
class Nonbusiness
bandwidth percent 20 account dot1q aal5 snap-rbe-dot1q
exit
exit
policy-map Parent
class class-default
shape 256000 account dot1q aal5 snap-rbe-dot1q
In the following configuration example, overhead accounting is enabled for bandwidth on the gaming
and class-default classes of the child policy map named subscriber_classes, and on the class-default class
of the parent policy map named subscriber_line. The voip and video classes do not have accounting
explicitly enabled; these classes have ATM overhead accounting implicitly enabled because the parent
policy has overhead accounting enabled. Notice that the features in the parent and child policies use the
same encapsulation type.
policy-map subscriber_classes
class voip
priority level 1
police 8000
class video
priority level 2
police 20
class gaming
bandwidth remaining percent 80 account dot1q aal5 snap-rbe-dot1q
class class-default
bandwidth remaining percent 20 account dot1q aal5 snap-rbe-dot1q
policy-map subscriber_line
class class-default
10-10
OL-7433-09
Chapter 10
Overhead Accounting
bandwidth remaining ratio 10 account dot1q aal5 snap-rbe-dot1q

shape average 512 account dot1q aal5 snap-rbe-dot1q
service policy subscriber_classes
Note
The shape average rate command is available only on the PRE3 and PRE4. The PRE2 supports the
shape rate command.
Example 10-1 shows that the Child policy map has two classes: Business and Nonbusiness. The Business
class has priority and is policed at 128,000 kbps. The Nonbusiness class has ATM overhead accounting
enabled and has a bandwidth of 20 percent of the available bandwidth. The Parent policy map shapes the
aggregate traffic to 256,000 kbps and enables ATM overhead accounting. Notice that Layer 2 overhead
accounting does not occur for the Business traffic class.
Example 10-1 Enabling ATM Overhead Accounting
Router(config-pmap)# class Business
Router(config-pmap-c)# police 128000 //*No Layer 2 overhead accounted*/
Router(config-pmap-c)# class Nonbusiness
Router(config-pmap-c)# bandwidth percent 20 account dot1q aal5 snap-rbe-dot1q
Router(config)# policy-map Parent
Router(config-pmap-c)# shape 256000 account dot1q snap-rbe-dot1q
Enabling ATM Overhead Accounting on the PRE3 and PRE4 for MLPoLNS
Example 10-2 shows how to enable ATM overhead accounting using the hierarchical service policy
where there is a parent with a child policy. In the example, the child policy map has a predefined class
prec2 that shapes the aggregate traffic to 10,000 kbps and enables ATM overhead accounting.
Example 10-2 Enabling ATM Overhead AccountingMLPoLNS
Router(config)# policy-map child
Router(config-pmap)# class prec2
Router(config-pmap-c)# shape average 10000 account user-defined 63 atm
Router(config)# policy-map parent
Router(config-pmap-c)# shape average 256000 account user-defined 63 atm
Router(config-pmap-c)# service-policy child
Enabling Ethernet Overhead Accounting on the PRE2

The following configuration example shows how to enable Ethernet overhead accounting on the PRE2
and specify the number of bytes the router should take into account when calculating the overhead. In
the example, the policy map named ethernet_ovrh contains the class-default class, which has overhead
accounting enabled for shaping and a user-defined offset of 18 bytes specified. The ethernet_ovrh policy
map is attached to subinterface Gigabit Ethernet 1/0/0.100.
policy-map ethernet_ovrh
class class-default

OL-7433-09
10-11
Chapter 10
Overhead Accounting
shape 200 account user-defined 18

!
pppoe enable group global
no snmp trap link-status
service-policy output ethernet_ovrh
Enabling Ethernet Overhead Accounting on the PRE3 and PRE4

The following configuration example shows how to enable Ethernet overhead accounting on the PRE3
or PRE4. In the example, the configuration of the policy map named ethernet_ovrh shapes class-default
traffic at a rate of 200,000 kbps and enables overhead accounting with a user-defined value of 18. The
ethernet_ovrh policy is attached to subinterface Gigabit Ethernet 1/0/0.100, thereby enabling overhead
accounting on the subinterface.
Router# configuration-terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# policy-map ethernet_ovrh
Router(config-pmap-c)# shape average 200000 account user-defined 18
!
Router(config)# interface GigabitEthernet1/0/0.100
Router(config-subif)# service-policy output ethernet_ovrh
!
Router# show running-config | begin 1/0/0.100
pppoe enable group group_pta
service-policy output ethernet_ovrh

To verify overhead accounting, enter any of the following commands in privileged EXEC mode:
Command
Purpose
Router# show policy-map [interface interface]
Displays information about the policy map attached to the

interface you specify, including ATM overhead accounting. If
you do not specify an interface, the command displays
information about all of the policy maps configured on the router.
interface interface is the interface type and number (for example,
atm 4/0/0).
Note
When you enter the show policy-map interface

command, the resulting classification byte counts and the
queuing feature byte counts do not match. This mismatch
occurs because the classification byte count does not
consider overhead, whereas the queuing features do
consider overhead.
10-12
OL-7433-09
Chapter 10
Overhead Accounting
Verification Examples for Overhead Accounting
Command
Purpose
Displays the running configuration on the router. The output

shows the AAA setup and the configuration of the policy map,
ATM VC, PPPoA, dynamic bandwidth selection, virtual
template, and RADIUS server.

Verifying ATM Overhead Accounting Using show policy-map, page 10-13
Verifying Overhead Accounting Using show running-config, page 10-14
Verifying Ethernet Overhead Accounting with User-Defined Option, page 10-14
Verifying ATM Overhead Accounting Using show policy-map

The following sample output from the show policy-map command indicates that ATM overhead
accounting is enabled for shaping and disabled for bandwidth:
Service-policy output:unit-test
Match: any
overhead accounting: enabled
bandwidth 30% (463 kbps)
overhead accounting: disabled
(packets output/bytes output) 100/1000
The following sample output from the show policy-map command indicates that ATM overhead
accounting is enabled for the class-default class for shaping. The BRAS-DSLAM encapsulation is dot1q
and the subscriber line encapsulation is snap-rbe based on the AAL3 service.
Policy Map unit-test
Class class-default
cir 10% account dot1q aal3 snap-rbe
The following sample output from the show policy-map interface command indicates that ATM
overhead accounting is enabled for shaping and disabled for bandwidth:
Service-policy output:unit-test
Match: any

OL-7433-09
10-13
Chapter 10
Overhead Accounting

(packets output/bytes output) 100/1000
Verifying Overhead Accounting Using show running-config

The following sample output from the show running-config command indicates that ATM overhead
accounting is enabled for shaping. The BRAS-DSLAM encapsulation is dot1q and the subscriber line
encapsulation is snap-rbe based on the AAL5 service.
subscriber policy recording rules limit 64
no mpls traffic-eng auto-bw timers frequency 0
call rsvp-sync
!
controller T1 2/0
framing sf
linecode ami
!
controller T1 2/1
framing sf
linecode ami
!
!
policy-map unit-test
class class-default
shape average 10 account dot1q aal5 snap-rbe
Note
The shape average rate command is available only on the PRE3 and PRE4. The PRE2 supports the
shape rate command.
Verifying Ethernet Overhead Accounting with User-Defined Option

The following sample output for the policy map named ethernet_ovrh indicates that Ethernet overhead
accounting is enabled for shaping and the user-defined offset is 18 bytes. The sample output from the
show policy-map interface command indicates that the ethernet_ovrh policy map is attached to the
subinterface Gigabit Ethernet 1/0/0.100, enabling overhead accounting on the subinterface.
Router# show policy-map ethernet_ovrh
Policy Map ethernet_ovrh
Class class-default
cir 200000 (bps) account user-defined 18
GigabitEthernet1/0/0.100
Service-policy output: ethernet_ovrh
0 packets, 0 bytes
Match: any
10-14
OL-7433-09
Chapter 10
Overhead Accounting
0 packets, 0 bytes
Queueing
Overhead Accounting Enabled
This section lists additional Cisco documentation for the features discussed in this chapter. When
appropriate, paths to applicable sections are listed below the documentation title.
Feature
Traffic Shaping Overhead Accounting for ATM, Release 12.2(31)SB2 feature

module
Class-based shaping

Class maps

Percentage-based traffic shaping
QoS: Percentage-Based Shaping, Release 12.2(31)SB2 feature module
Policing
Policy maps


Tech Note
Tech Note
Quality-of-Service Overview Tech Note
Traffic shaping

MLP on LNS
Cisco 10000 Series Router Software Configuration Guide

Chapter 19: Configuring Multilink Point-to-Point Protocol Connections

OL-7433-09
10-15
Chapter 10
Overhead Accounting
10-16
OL-7433-09
CH A P T E R
11

A Layer 3 queuing strategy provides differentiated levels of service and assigns priority to
delay-sensitive packets. Queuing limits the amount of traffic that can be sent to queues so that all of the
packet buffers are not consumed. Commonly used mechanisms, such as random early detection (RED),
monitor network traffic loads to control congestion by acting on the traffic if congestion is about to
occur.
This chapter discusses congestion control mechanisms supported on the Cisco 10000 series router and
includes the following topics:
Queue Scaling Limits, page 11-1
Queue Limit, page 11-2
Queue IDs and Interface Queues, page 11-6
Queuing Outbound Traffic, page 11-7
Controlling Congestion Using Tail Drop, page 11-8
Controlling Congestion Using Random Early Detection, page 11-9
Controlling Congestion Using Weighted Random Early Detection, page 11-11
Interfaces Supporting Layer 3 Packet Drop Policies, page 11-21
Restrictions and Limitations for Controlling Layer 3 Congestion, page 11-22
Configuring Layer 3 Queue Limit and Drop Policies, page 11-24
Verifying and Monitoring Layer 3 Packet Dropping, page 11-32
Controlling Packet Flow on Layer 2 Queues, page 11-39

The router allocates at least two queues for every interface or subinterface for which separate queues are
created. The first queue is the default queue for normal traffic and the second queue is the system queue.
The system queue is used for a small amount of router-generated traffic that bypasses the normal drop
mechanisms. For 32,000 VCs, the router would need to allocate a minimum of 64,000 queues. While
Cisco IOS Release 12.3(7)XI1 adds support for up to 128,000 queues, a more effective use of these
limited resources is to have the subinterfaces on a given main interface share the single system queue of
the main interface.

OL-7433-09
11-1
Chapter 11
Queue Limit
In Cisco IOS Release 12.3(7)XI2, the subinterfaces on a given main interface share the single system
queue of the main interface. This allows for 32,000 subinterfaces with a three-queue model that supports
assured forwarding (AF) queues, expedited forwarding (EF) queues, and the default best effort (BE)
queues. Because a system queue is not allocated for every subinterface, queues are freed up for a
four-queue model.
Table 11-1 lists the scaling limits for class queues.
Table 11-1
Queue Criteria
PRE3
Release 12.2(31)SB2 or later
PRE2
Release 12.3(7)XI or later
PRE2
Release 12.2(16)BX or later
PRE1
Total Number of Queues Per

System1
256,000
131,070
65,534
32,766
No. Queues Per Link
15
322
32
163
Total Number of Packet

Buffers for Queue Depth4
Not Applicable5
4,194,304
4,194,304
1,048,576
1. Includes network-control and default queues.

2. 29 user-configurable queues, 1 class-default queue, 1 system queue, and 1 reserved queue
3. 14 user-configurable queues, 1 class-default queue, 1 system queue
4. With 131,070 queues configured, the average queue limit across all of the configured queues is less than or equal to 32 packets per queue: 4,194,304
divided by 131,070 equals 32.
5. The PRE3 implements queues in such a way that this limit no longer exists.
Queue Limit
Each queue has a limit on the number of packets that the router can place onto the queue. This limit,
referred to as the depth, is a user-configurable limit. During periods of high traffic, a queue fills with
packets waiting for transmission. When a queue reaches its queue limit and becomes full, by default the
router drops packets until the queue is no longer full.
Table 11-2 describes the queuing limits for the various processor cards.
11-2
OL-7433-09
Chapter 11

Queue Limit
Table 11-2
Packets Per Queue
Processor
Cisco IOS Release
Packets Per Queue
PRE1
All releases
32 to 16,384
If you do not specify a value that is a power of 2,
the router uses the nearest power of 2.
PRE2
PRE2
Cisco IOS Release 12.2(15)BX

and Release 12.2(16)BX
32 to 16,384
Cisco IOS Release 12.3(7)XI

and later releases
Interfaces with speeds that are less than 500 MB
The value does not need to be a power of 2.

8 to 4,096 packets per queue
The value must be a power of 2.
Interfaces with speeds that are greater than 500 MB
128 to 64,000 packets per queue

The value must be a power of 2.
PRE3
PRE4
Cisco IOS Release 12.2(31)SB2 16 to 32,767

and later releases
When a packet queue temporarily experiences congestion, increasing the depth of the queue using the
queue-limit command reduces the number of packets dropped. However, setting the queue limit to a
high value might reduce the number of packet buffers available to other interfaces.
The queue limit applies to each buddy queue on links with:
Note
At least 500 Mbps (PRE1)
1 Gbps (PRE2)
The PRE3 does not use buddy queues.

If you do not specify a queue limit, the router calculates the default buffer size for each class queue as
follows:
Note
Class queues with weighted random early detection (WRED)The router uses the default queue
limit of two times the largest WRED maximum threshold value, rounded to the nearest power of 2.
For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX, the router does not round the value
to the nearest power of 2.
Class queues without WREDThe router has buffers for up to 50 milliseconds of 256-byte packets
(PRE2) or 250-byte packets (PRE3) at line rate, but not less than 32 packets (PRE2) or 16 packets
(PRE3).
Priority queues without WREDThe router has buffers for up to 25 milliseconds of 80-byte packets
at line rate, but not less than 32 packets (PRE2) or 16 packets (PRE3).

OL-7433-09
11-3
Chapter 11
Queue Limit
Queue Limit Packet Buffers

The router provides a total of 4,194,304 buffers for queuing packets and calculates the default buffer size
for each class queue as described in the Queue Limit section on page 11-2. Whatever the default queue
size the system calculates, if a class has a random early detection (RED) drop policy configured and one
of the maximum thresholds is configured to be larger than the default buffer size, the router
automatically increases the queue size to the nearest power of 2 of the largest maximum threshold.
You can use the show policy-map interface command to display the actual queue size. To make the
queue size larger than the default size the router calculated, do the following:
Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, and later releasesConfigure the
queue-limit command with RED.
For more information, see the queue-limit Command section on page 11-4, the Random Early
Detection and Queue Limit section on page 11-10, and the WRED and Queue Limit section on
page 11-20.
Releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XIRED with queue-limit is
not supported. As a workaround, configure RED with an unused IP precedence or DSCP level and
define a maximum threshold that is larger than the default size the router calculated. By doing this,
you force the router to increase the queue size to accommodate the larger threshold.
With 131,070 queues configured, the average queue limit across all of the configured queues is less than
or equal to 32 packets per queue:
Total number of packet buffers / Total number of queues
4,194,304 / 131,070 = 32
If you change the queue size several times for 131,070 queues, the queue packet buffers can become
fragmented or might still be in use. For more information, see the Restrictions and Limitations for
Controlling Layer 3 Congestion section on page 11-22.
For more information, see the Average Queue Size and the Exponential Weight Constant section on
page 11-21.
Default Queue Limit and Packet Buffers

When a queue is part of a high-speed interface, the default queue limit is very large. This allows the
queue to store up many packets during congestion. If too many of these type of queues are congested on
the system, it causes system packet buffer exhaustion and all queues in the system experience packet
drop.
queue-limit Command
To specify or modify the maximum number of packets that a particular class queue can hold, use the
queue-limit command in policy-map class configuration mode. To remove the queue packet limit from
a class, use the no form of this command.
queue-limit number-of-packets
no queue-limit number-of-packets
11-4
OL-7433-09
Chapter 11

Queue Limit
Syntax Description
number-of-packets
For PRE1, number-of-packets is a number from 32 to 16384; the number

must be a power of 2. If the number you specify is not a power of 2, the
router converts the number to the nearest power of 2 value.
For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX using the
PRE2, number-of-packets is a number from 32 to 16384. The number does
not need to be a power of 2.
For Cisco IOS Release 12.3(7)XI and later releases using the PRE2, if the
interface speed is less than 500 MB, number-of-packets is a number from 8
to 4096; the number must be a power of 2. If the interface speed is greater
than 500 MB, number-of-packets is a number from 128 to 64000 and must
be a power of 2. If it is not, the router converts the number to the nearest
power of 2 value.
For Cisco IOS Release 12.2(31)SB2 and later releases using the PRE3,
number-of-packets is a number from 1 to 32,767. The number does not need
to be a power of 2.
queue-limit Command History

Cisco IOS Release
Description
Release 12.0(17)SL
The queue-limit command was introduced on the PRE1.
Release 12.0(25)SX
This command was enhanced to allow you to simultaneously configure

both the queue-limit and random-detect commands in the same class of
a policy map.
Release 12.2(16)BX
Release 12.3(7)XI
This command was enhanced on the PRE2 to allow you to simultaneously

configure both the queue-limit and random-detect commands in the
same class of a policy map.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Default Behavior for the queue-limit Command

The following describes the default behavior of the queue-limit command for class queues with and
without weighted random early detection (WRED):
Note
For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX using the PRE2, and for Cisco IOS
Release 12.2(31)SB2 and later releases using the PRE3, the router does not round the value to
the nearest power of 2.
Priority queues and class queues without WREDThe router has buffers for up to 50 milliseconds
of 256-byte packets at line rate, but not less than 32 packets.

OL-7433-09
11-5
Chapter 11
Usage Guidelines for the queue-limit Command

Whenever you configure the bandwidth command for a class queue, the command sets a default queue
limit for the class, which in most cases is sufficient to meet minimum bandwidth guarantees. However,
if you configure all of the 131,070 queues for a system, lower the queue limit so that all of the queues
have enough bandwidth. The queue-limit command overrides the default queue limit set by the
bandwidth command. For more information, see the Queue Limit Packet Buffers section on
page 11-4.
Cisco IOS Release 12.2(16)BX does not require that you specify a queue limit value that is a power of
2; therefore, the router does not round the value to the nearest power of 2.

The router allocates queue IDs (QIDs) to interface queues. The number of queues supported on an
interface and the number of QIDs allocated depend on the speed of the interface and the processor card
installed in the chassis. For each class that has a queue on an interface, the router allocates one or two
QIDs as indicated in Table 11-3.
Table 11-3
QID Allocation for Classes with Queues on an Interface
Processor
Interface Bandwidth
QIDs Allocated
Queues Supported
PRE1
Less than 500 Mbps
500 Mbps or greater
32,766 total queues per

system
Less than 622 Mbps
130,816
622 Mbps or greater
2541
Not applicable 2
256,000
PRE2
PRE3
1. QID 0 and QID 1 are not legal values. Therefore, instead of supporting 256 QIDs, the router supports 254.
2. The PRE3 does not support buddy queues.
Note
The PRE2 has buddy queues only for the OC-48 line card. All other interfaces have 1 queue. The PRE1
requires a buddy queue for the full-height Gigabit Ethernet line card.
Reserved QIDs
On the PRE2, if no more QIDs are left (all of them are used) and you attempt to modify the queue limit
in a policy map that is attached to one or more interfaces, the operation fails and an out of resource
message displays. To avoid this, you can do the following:
Reserve one or more available QIDs
Remove the policy map from the interface first, modify the queue limit, and then attach the new
policy map to the interface
You might desire to reserve a pool of unused queues just in case a service policy is applied on a live
production network and someone attempts to change the queue parameters. By using the show ha pxf
cpu queue summary command, you can learn how many available queues are in the pool and plan
accordingly.
11-6
OL-7433-09
Chapter 11

Queuing Outbound Traffic
Queuing Outbound Traffic

This section describes how the Cisco 10000 series router queues outbound traffic and includes the
following:
Queuing Outbound Traffic on ATM Interfaces, page 11-7
Queuing Outbound Traffic on Frame Relay Interfaces, page 11-7
Queuing Outbound Traffic on Virtual LAN Interfaces, page 11-7
Queuing Outbound Traffic on ATM Interfaces

On ATM interfaces, the Cisco 10000 series router creates one set of queues for all of the unspecified bit
rate (UBR) PVCs and a separate set of queues for each variable bit rate (VBR) PVC. The following lists
the queues the router creates:
One default queue for all unshaped (no PCR specified) UBR PVCs
One default queue for each VBR and shaped (PCR is specified) UBR PVCs
One network control queue for each port
Using a policy map, you can optionally create additional class-based queues for UBR PVCs and each
VBR PVC, and attach the policy map to the physical interface for UBR PVCs or to a VBR PVC.
Unshaped UBR PVCs that have their own service policy use the physical interfaces default queue only.
These PVCs cannot use any user-defined, class-based queue defined on the physical interface.
Queuing Outbound Traffic on Frame Relay Interfaces

The Cisco 10000 series router supports two queuing modes for Frame Relay interfaces: interface-based
queuing and PVC-based queuing. In interface-based queuing, all PVCs share the same set of queues. In
PVC-based queuing, each PVC has its own set of queues for its outbound traffic.
Interface-based queuing is the default queuing mode. In this mode, the system creates a default set of
queues that all PVCs on the interface can use. Using a policy map, you can optionally create additional
class-based queues, which are shared among all the PVCs.
You can configure PVC-based queuing by creating a hierarchical policy. In this way, you can enable
class-based fair queuing for a PVC and shape the total PVC traffic to a desired rate. For more
information, see Chapter 13, Defining QoS for Multiple Policy Levels.
For information about enabling PVC-based fair queuing by using the Frame Relay QoS CLI, see
Appendix A, Configuring Frame Relay QoS Using Frame Relay Legacy Commands.
Queuing Outbound Traffic on Virtual LAN Interfaces

By default, the Cisco 10000 series router does not create a queue for a virtual LAN (VLAN) interface.
All VLANs share the same set of queues on the physical Ethernet interface.
To create a separate queue for a VLAN interface, use a hierarchical policy. For more information, see
Chapter 13, Defining QoS for Multiple Policy Levels.

OL-7433-09
11-7
Chapter 11
Controlling Congestion Using Tail Drop
Controlling Congestion Using Tail Drop

The tail drop mechanism controls congestion using a specific drop policy to ensure that the maximum
number of packets held in a queue is not exceeded.
During periods of high traffic, a queue fills with packets waiting for transmission. When a queue reaches
its queue limit and becomes full, by default the router employs the tail drop mechanism to drop packets
until the queue is no longer full.
Tail drop is the default mechanism used to control congestion for Layer 3 queues. While some
mechanisms activate before a queue reaches its queue limit, tail drop activates when a queue becomes
full. Tail drop treats all traffic equally and does not differentiate between classes of service. When a
queue becomes full, tail drop continues to drop packets until the queue has room for more packets (the
queue is no longer full).
Feature History for Tail Drop

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The tail drop feature was introduced on the router.
PRE1
Release 12.2(16)BX
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
PRE2
PRE3
Tail Drop and Random Early Detection

The Cisco 10000 series router allows you to combine tail drop with another congestion control
mechanism called random early detection (RED). RED does not replace tail drop, but rather
complements it by dropping packets before the queue reaches its queue limit or maximum threshold. Tail
drop occurs after the queue is already full, when the mean queue depth for RED exceeds the maximum
threshold value and when the queue limit is reached.
For more information about random early detection, see the Controlling Congestion Using Random
Early Detection section on page 11-9 and the Controlling Congestion Using Weighted Random Early
Detection section on page 11-11.
11-8
OL-7433-09
Chapter 11

Controlling Congestion Using Random Early Detection

Random early detection (RED) is an alternative mechanism for controlling congestion of Layer 3
queues. Unlike the tail drop mechanism, RED implements a proactive queuing strategy that controls
congestion before a queue reaches its queue limit.
RED randomly discards packets. If the source host is using Transmission Control Protocol (TCP), the
host detects that packets are dropped and decreases its transmission rate until all of the packets reach
their destinations, indicating that the congestion is clear. The host can then resume its original
transmission rate.
You can configure a drop policy for RED that is based on one of the following. Each queue on the router
can have only one type of RED drop policy.
IP precedence-based REDConfigures a drop policy for RED based on an IP precedence level.

Valid values are from 0 to 7, where 0 typically represents low priority traffic that can be aggressively
managed (dropped) and 7 represents high priority traffic. Traffic at a low precedence level typically
has a higher drop probability. When RED drops packets, source hosts using TCP detect the drops
and slow the transmission of packets.
DSCP-based REDConfigures a drop policy for RED based on a differentiated services code point
(DSCP) value. When configured, the router randomly drops packets with the specified DSCP value,
according to the RED thresholds you configure. For the PRE1, DSCP-based RED supports one
default drop profile per class, three assured forwarding (AF) drop profiles per class, and four
non-AF drop profiles per policy map.
Feature History for Random Early Detection

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The random early detection feature was introduced on the PRE1

router.
Release 12.0(22)S
This feature was enhanced to allow you to configure RED PRE1

based on a differentiated services code point (DSCP).
Release 12.0(25)SX
This feature was enhanced to allow you to simultaneously PRE1

configure the random-detect command and the
queue-limit for the same class queue.
Release 12.2(16)BX
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
PRE3

OL-7433-09
11-9
Chapter 11
Random Early Detection and Queue Limit

Random early detection (RED) controls the average congestion level of a class queue and queue limit
controls the instantaneous congestion level of a queue. By using the RED and queue limit mechanisms
together, you can configure a drop policy for a class queue and simultaneously limit the maximum
number of packets allowed to accumulate in the queue.
Note
To simultaneously configure RED and queue limit for a class in a policy map, the router must be running
Cisco IOS Release 12.0(25)SX or later releases. In releases prior to Cisco IOS Release 12.0(25)SX, you
can configure either the random-detect command or the queue-limit command, but not both commands
at the same time.
Determining Packet Drop Probability

RED uses three configurable parameters to determine the drop probability of packets: minimum
threshold, maximum threshold, and mark probability denominator. The following describes how RED
determines packet drop probability:
RED begins dropping packets when the average queue size is equal to the value of the minimum
threshold.
RED continues dropping packets when the average queue size is between the minimum and
maximum threshold values.
As the average queue size approaches the maximum threshold, RED uses the mark probability
denominator value to determine the slope (the increase in drop rate). For example, if the
denominator is 512, RED drops one out of every 512 packets when the average queue limit reaches
the maximum threshold.
RED drops all packets when the average queue size is greater than the maximum threshold value.
Figure 11-1 illustrates how RED determines drop probability.

Figure 11-1
Determining Drop Probability Using RED
Red Drop Rate
100%
Drop
probability
mark
Minimum
threshold
Maximum
threshold
Average Queue Length
126557
Slope
11-10
OL-7433-09
Chapter 11

Controlling Congestion Using Weighted Random Early Detection
Recommended Settings for RED Drop Probability

To ensure an optimum drop policy for RED, use the following threshold settings:
Set the minimum threshold value high enough to utilize the transmission link to the maximum
capability. If you set the minimum threshold too low, RED can drop packets unnecessarily and the
transmission link is not fully used.
Set the maximum threshold value and the minimum threshold value so that the difference between
the two values is large enough to avoid global synchronization. If the difference is too small, RED
drops many packets at one time, which results in global synchronization.

Weighted random early detection (WRED) is another mechanism for controlling congestion of Layer 3
queues. WRED combines the capabilities of the random early detection (RED) mechanism with IP
precedence, differential services code point (DSCP), and discard-class to provide preferential handling
of higher priority packets. When an interface starts to become congested, WRED discards lower priority
traffic with a higher probability. WRED controls the average depth of Layer 3 queues.
Unlike tail drop, WRED attempts to anticipate and avoid congestion. WRED implements a proactive
queuing strategy that manages congestion before a queue reaches its queue depth. By selectively
dropping packets, WRED prevents packets from enqueuing to the Layer 3 queue.
You can configure a drop policy for WRED that is based on one of the following. Each queue on the
router can have only one type of WRED drop policy.
Note
IP precedence-based WREDConfigures a drop policy for WRED based on an IP precedence level.

Valid values are from 0 to 7, where 0 typically represents low priority traffic that can be aggressively
managed (dropped) and 7 represents high priority traffic. Traffic at a low precedence level typically
has a higher drop probability. When WRED drops packets, source hosts using TCP detect the drops
and slow the transmission of packets.
When you configure IP precedence-based WRED on an output policy map and the outgoing
packets are MPLS packets, instead of using the 3-bit IP precedence field in the underlying IP
packets, the router drops the MPLS packets based on the three experimental (EXP) bits in the
MPLS label.
DSCP-based WREDConfigures a drop policy for WRED based on a DSCP value. When
configured, the router randomly drops packets with the specified DSCP value, according to the
WRED thresholds you configure.
Discard-class-based WREDConfigures a drop policy for WRED based on a discard-class value.

Valid values are from 0 to 7. The discard-class value sets the per-hop behavior (PHB) for dropping
traffic. WRED based on discard-class is an egress function.
ATM cell loss priority-based WREDConfigures a drop policy for WRED based on a cell loss
priority (CLP) value. Valid values are 0 or 1. When configured, the router uses the value of the CLP
bit to randomly drop packets leaving the Pseudowire and going out an ATM interface. The router
also supports ATM CLP-based WRED on non-Layer2 VPN outbound ATM interfaces.
CoS-based WREDConfigures a drop policy for WRED based on the specified class of service
(CoS) bit associated with the packet. Valid values are from 0 to 7.

OL-7433-09
11-11
Chapter 11
Frame Relay DE WREDThe discard eligibility (DE) bit in the address field of a frame relay frame
is used to prioritize the discarding of frames in congested frame relay networks. The frame relay DE
bit has only one bit and therefore only has two settings, 0 or 1. If congestion occurs in a frame relay
network, frames with the DE bit set at 1 are discarded before frames with the DE bit set at 0.
Therefore, important traffic should have the DE bit set at 0 while less important traffic should be
forwarded with the DE bit set at 1.
You can also configure WRED to ignore the IP precedence, DSCP, or discard-class when making drop
decisions. As a result, the router implements non-weighted random early detection (RED) behavior when
deciding which packets to drop.
Note
The PRE2 uses sampled RED and the PRE3 uses per-packet RED.
Feature History for Weighted Random Early Detection

Cisco IOS Release
Description
Required PRE
Release 12.0(17)SL
The weighted random early detection feature was

PRE1
Release 12.0(22)S
This feature was enhanced to allow you to configure

WRED based on a differentiated services code point
(DSCP).
PRE1
Release 12.0(25)SX
This feature was enhanced to allow you to simultaneously PRE1

configure the random-detect command and the
queue-limit for the same class queue.
Release 12.2(16)BX
This feature was introduced on the PRE2 and uses sampled PRE2
RED.
Release 12.3(7)XI
This feature was enhanced on the PRE2 to:
Enable the configuration of eight unique drop

precedence levels for one queue instead of four levels
Allow the simultaneous configuration of both the

random-detect and queue-limit commands for a
class queue
Maintain separate WRED drop statistics for each IP

precedence, DSCP value, and discard-class
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3 and uses

PRE3
per-packet RED. This feature is DiffServ-compliant on the
PRE3.
Release 12.2(33)SB
This feature was enhanced to support ATM cell loss

priority-based WRED on the PRE2, PRE3 and PRE4.
PRE2, PRE3,
PRE4
11-12
OL-7433-09
Chapter 11

Benefits of Using Weighted Random Early Detection

Weighted random early detection (WRED) has the following benefits:
WRED provides early detection of congestion for one or multiple traffic classes. It also protects
against global synchronization. For these reasons, WRED is useful on any outbound interface where
you expect congestion to occur.
WRED provides separate thresholds and weights for different IP precedence levels, which allows
you to provide different qualities of service for packet dropping for different traffic types. For
example, during congestion WRED can drop standard traffic more frequently than premium traffic.
How WRED Works

When an output interface begins to show signs of congestion, but is not fully congested yet, WRED
begins selectively dropping packets based on the IP precedence, DSCP, or discard-class level of the
packet. WRED uses the minimum and maximum threshold values to determine the drop probability for
packets. Typically, for drop policies with low values (closer to 0), WRED drops packets with low values
(closer to 0) with a higher probability, based on the drop policy configuration.
For example, IP precedence-based WRED uses the IP precedence level of packets to selectively drop
packets. WRED drops packets with a low precedence value (closer to 0) with a higher probability based
on the WRED configuration. The higher the precedence value of a packet (the closer to 7), the greater
the probability that WRED ignores the packet and allows the router to forward the packet to its
destination.
WRED allows the transmission line to be used fully at all times, especially when most of the traffic is
TCP/IP traffic. For TCP/IP traffic, the action of WRED dropping packets indicates congestion and
causes a source host to reduce its transmission rate. After all of the packets reach their destinations
(indicating reduced congestion), the source host increases the transmission rate again.
By dropping some packets early, WRED avoids dropping large numbers of packets at once and
minimizes the chances of global synchronization. Global synchronization occurs when multiple TCP
hosts reduce their transmission rates in response to packet dropping and then increase their transmission
rates again when congestion reduces.
With protocols other than TCP/IP, packet sources might not respond to dropped packets by reducing their
transmission rates. Instead, such hosts might resend the dropped packets at the same rate. As a result,
when WRED drops packets, congestion is not decreased.
Statistically, WRED drops more packets from large users than from small users. Therefore, WRED is
more likely to slow down the traffic sources that generate the most traffic and not the traffic sources that
generate little traffic.
WRED Drop Mode

A WRED drop mode indicates the basis upon which the WRED drop policy is applied. The router
supports DSCP, IP precedence, discard-class, and ATM cell loss priority (CLP) based WRED.
Table 11-4 lists the commands used to enable the WRED drop modes.
Note
If you do not specify any arguments, WRED uses the default IP precedence in the WRED calculations.

OL-7433-09
11-13
Chapter 11
Table 11-4
WRED Drop Mode Commands
Command
Description
random-detect dscp-based min-thresh-value
Drops packets based on a DSCP value. This

option is available on the PRE2, PRE3, and
PRE4.
max-thresh-value
mark-probability-denominator-value
random-detect prec-based min-thresh-value

max-thresh-value
random-detect discard-class-based
min-thresh-value max-thresh-value
Drops packets based on an IP precedence

value. This option is available on the PRE2,
PRE3, and PRE4.
Drops packets based on a discard-class value.
This option is available on the PRE2, PRE3,
and PRE4.
Note
random-detect atm-clp-based min-thresh-value

max-thresh-value
random-detect cos cos-value min-thres-value

max-thresh-value mark-probability-denominator
The min-thresh-value option is not

available on the PRE3 for this
command.
Drops packets based on an ATM cell loss

priority (CLP) value. This option is available
on the PRE2, PRE3, and PRE4.
Drops packets based on the CoS bit value of
the packet. This option is available on the
PRE3, and PRE4.
The minimum threshold indicates the minimum number of packets allowed in the queue. When the
average queue length reaches the minimum threshold, WRED randomly drops some packets with the
specified DSCP, IP precedence, or discard-class value. Valid minimum threshold values are from 1 to
16,384. This option is not available on the PRE3 for the random detect discard-class command.
The maximum threshold indicates the maximum number of packets allowed in the queue. When the
average queue length exceeds the maximum threshold, WRED drops all packets with the specified
DSCP, IP precedence, or discard-class value. Valid maximum threshold values are from the value of the
min-threshold to 1.
The maximum probability denominator is the drop rate. It specifies the denominator for the fraction of
packets dropped when the average queue depth is at the maximum threshold. For example, if the
denominator is 512, 1 out of every 512 packets is dropped when the average queue is at the maximum
threshold. Valid values are from 1 to 65,535. The default value is 10.
For information about the behavior of the random-detect command on the various PRE processor cards,
see the WRED Drop Profiles section on page 11-14 and the WRED Aggregate Drop Profiles section
on page 11-17.
WRED Drop Profiles

A WRED drop profile specifies DSCP, IP precedence, discard-class, or ATM CLP values, which WRED
uses to determine the drop probability of packets.
Table 11-5 lists the commands used to configure a packet drop policy. The behavior of these commands
depends on the PRE installed in the router as the following describes:
On the PRE2, the random-detect command specifies the default profile for the queue.
11-14
OL-7433-09
Chapter 11

Note
On the PRE3 and PRE4, the supported random-detect commands specify the aggregate profile for
the queue. To configure a default drop profile for a queue, the random-detect basis command is
used (for example, random-detect dscp-based aggregate command). The random-detect
discard-class-based, random-detect atm-clp-based and random-detect atm-clp-based
commands do not have an aggregate form of the command on the PRE3 and PRE4.
If you do not specify any arguments, WRED uses the default IP precedence in the WRED calculations.
Table 11-5
WRED Drop Profile Commands
Command
Description
random-detect dscp dscp-value
A number that indicates the drop eligibility of a

packet based on the differentiated services code
point. Value numbers are from 0 to 63.
PRE3 and PRE4
random-detect dscp values sub-class-val1

[...[sub-class-val8]] minimum-thresh
min-thresh-value maximum-thresh
max-thresh-value mark-prob mark-prob-value
random-detect ip precedence precedence-value

PRE3 and PRE4

packet based on the IP precedence level. Valid
values are from 0 to 7. Typically, 0 represents low
priority traffic that can be aggressively managed
(dropped) and 7 represents high priority traffic.
random-detect precedence values sub-class-val1

min-thresh-value maximum-thresh
max-thresh-value mark-prob mark-prob-value
random-detect discard-class discard-class-value A number that indicates the drop eligibility of a

packet based on the discard-class. Valid values
are from 0 to 7.
PRE3 and PRE4
random-detect discard-class discard-class-value


OL-7433-09
11-15
Chapter 11
Table 11-5
WRED Drop Profile Commands
Command
Description
random-detect atm-clp clp-value

packet based on the ATM CLP. Valid values are 0
or 1.
PRE3 and PRE4
random-detect atm-clp clp-value


max-thresh-value
mark-probability-denominator

packed based on the CoS bit. Valid values are
from 0 to 7.
PRE3 and PRE4

max-thresh-value
mark-probability-denominator
On the PRE3, the number of WRED profiles supported per policy map depends on the number of
interfaces with attached service policies:
When less than 32,000 interfaces have service policies, the PRE3 supports 21 non-default WRED
profiles and 16 default profiles per policy map. The 16 default profiles includes profiles for the
class-default queue, net-control, and two priority queues. However, you cannot configure the default
profiles for net-control and priority queues. Therefore, the PRE3 allows default profiles for 12
non-default (user) queues and one class-default queue per policy map.
When 32,000 to 64,000 interfaces have service policies, the PRE3 supports any combination of
non-default WRED and default profiles. The maximum total number of profiles (non-default and
default) supported in a policy map is 21.
When less than 32,000 interfaces have service policies, the PRE3 supports up to 21 non-default
WRED profiles and up to 16 default profiles per policy map. The 16 default profiles include the
class-default, net-control, and two priority queues. However, the default profiles for net-control and
priority queues are not user-configurable; therefore the actual number of default profiles for
user-configured queues is 12 with one class-default class per policy map.
Table 11-6 summarizes the WRED profiles supported by various PREs.

Table 11-6
WRED Profiles Support
Performance
Routing Engine
Number of NonDefault WRED Profiles
Number of Default Profiles

Per Policy Map
Number Interfaces with

Service Policies
PRE1
No hard limit
Varies1
PRE2
No hard limit
Varies2
PRE3
21 per policy map
163 per policy map
Less than 32,000
21 total explicit and default profiles per policy map
32,000 to 64,000
1. Depends on a combination of factors, such as the number of queues on the router and packet heaps. Changes in the queue
length and the number of classes per policy map also affect the number of interfaces on which policy maps can be applied.
11-16
OL-7433-09
Chapter 11

2. See footnote 1.
3. Includes profiles for class-default, net-control, and two priority queues.
WRED Aggregate Drop Profiles

On the PRE3 and PRE4, WRED is extended to support an aggregate drop profile. A single
random-detect command with multiple subclasses specified is used to configure the profile. The
subclasses (for example, multiple DSCP values) share one specified minimum and maximum threshold
and one specified mark-probability denominator.
Although the PRE3 and PRE4 allow you to specify only one DSCP or IP precedence value in the
random-detect command (which is equivalent to the PRE2 form of the command), the advantage of
aggregating DSCP or IP precedence values is that an aggregate drop profile only counts as one profile
toward the maximum number of profiles allowed. As a result, you can configure drop profiles for more
DSCPs or IP precedence levels using aggregation than you can when specifying only one value for each
WRED profile.
The PRE3 and PRE4 random-detect commands have the following syntax:
random-detect aggregate [minimum-thresh min-thresh-value maximum-thresh max-thresh-value
mark-prob mark-prob-value]
random-detect {precedence-based | dscp-based} aggregate [minimum-thresh min-thresh-value
maximum-thresh max-thresh-value mark-prob mark-prob-value]
random-detect {precedence | dscp} values [sub-class-val1 [...sub-class-val8]
[minimum-thresh min-thresh-value maximum-thresh max-thresh-value mark-prob
mark-prob-value]]
Note
If you enter the random detect command without the aggregate profile, the PRE3 and PRE4 accept the
command, but the default action is to tail drop. For example:
random-detect {precedence-based | dscp-based}
The PRE3 and PRE4 also supports drop profiles based on discard class and cell loss priority (CLP), but
do not use the aggregate form of the command. Instead, the PRE3 and PRE4 support the PRE2 form of
the commands:
random-detect {discard-class-based | atm-clp-based}
random-detect {discard-class discard-class-value | clp clp-value} [min-thresh-value]
[max-thresh-value] [mark-probability-denominator-value]
For example, to configure a WRED DSCP profile, the following command creates drop profiles for
DSCP value 1, DSCP value 2, and so on. Each profile has the same specified drop threshold and
mark-probability denominator. The router aggregates these drop profiles, that is statistics are counted for
the group of all of the DSCP values together.
random-detect dscp values [dscp-val1 [...dscp-val8] [minimum-thresh min-thresh-value
To have the statistics counted for each DSCP separately, enter the random-detect command once for
each DSCP value, using the same threshold values and mark-probability denominator.
Statistics displayed for the subclasses are aggregated and shown in one line. If some subclasses do not
have a user-defined WRED profile, the router collects the statistics as an aggregate for the unconfigured
subclasses and displays the statistics in one line. The router maintains separate statistics for each
random-detect command with a group of subclasses.

OL-7433-09
11-17
Chapter 11
On the PRE3 and PRE4, the random-detect command is used to configure a default drop profile for a
queue and has the following syntax:
random-detect {precedence-based | dscp-based} aggregate [minimum-thresh min-thresh-value
If you enter the random-detect command without the aggregate profile (the equivalent of the PRE2
command), the PRE3 and PRE4 accept the command, but the default action is to tail drop.
random-detect {precedence-based | dscp-based}
The PRE3 and PRE4 support drop profiles based on discard class, ATM CLP and CoS bit, but do not use
the aggregate form of the command. Instead, the PRE3 and PRE4 support the PRE2 form of the
commands:
random-detect discard-class-based
random-detect discard-class discard-class-value min-thresh-value max-thresh-value
random-detect atm-clp-based
random-detect clp clp-value min-thresh-value max-thresh-value
random-detect cos cos-value min-thresh-value max-thresh-value mark-probability-denominator
Usage Guidelines for the random-detect Command

General
If you do not specify any arguments, WRED uses the default IP precedence value to calculate the drop
probability.
When specifying class policy within a policy map, you can use the random-detect command with the
bandwidth command.
To modify the queue length, always use the queue-limit command instead of the max-threshold
parameter of the random-detect command. Modifying the max-threshold parameter does not
necessarily change the queue limit. When you increase the max-threshold parameter, WRED adjusts the
queue length to be no less than the max-threshold value. However, when you reduce the max-threshold
parameter, WRED does not change the queue length.
exponential-weight-constant
The router calculates the average queue size based on the previous average and the current size of the
queue, using the following formula:
Average = (old-average * (1 2 n)) + (current-queue-size * 2 n)
where n is the exponential weight constant
For MPLS packets, when you use precedence-based WRED, the router calculates the average queue size
using the MPLS experimental (EXP) bits.
random-detect dscp
You must first enable the drop mode by using the random-detect dscp-based command. You can then
set the drop probability profile by using the random-detect dscp command.
With the dscp-based keyword, WRED uses the DSCP value (that is, the first six bits of the IP type of
service (ToS) byte) to calculate the drop probability.
11-18
OL-7433-09
Chapter 11

random-detect ip precedence
You must first enable the drop mode by using the random-detect prec-based command. You can then
set the drop probability profile by using the random-detect ip precedence command.
With the prec-based keyword, WRED uses the IP precedence value to calculate the drop probability.
For all precedence levels, the mark-probability-denominator default value is 10, and the max-threshold
is based on the output buffering capacity and the transmission speed for the interface.
If you want weighted random early detection (WRED) to ignore the precedence level when determining
which packets to drop, enter this command with the same parameters for each precedence level.
Remember to use reasonable values for the minimum and maximum thresholds.
random-detect discard-class
You must first enable the drop mode by using the random-detect discard-class-based command. You
can then set the drop probability profile by using the random-detect discard-class command.
With the discard-class-based keyword, WRED uses the discard-class value to calculate the drop
probability.
random-detect cos
You must first enable the drop mode by using the random-detect cos-based command. You can then set
the drop probability profile by using the random-detect cos command.
With the cos-based keyword, WRED uses the cos bit value to calculate the drop probability.
Minimum and Maximum Thresholds

The random-detect command allows you to specify the minimum and maximum threshold settings for
a class queue:
Minimum thresholdThe minimum number of packets allowed in the queue. When the average
queue length reaches the minimum threshold, weighted random early detection (WRED) randomly
drops some packets with the specified DSCP, IP precedence, discard-class, or atm-clp value. Valid
minimum threshold values are from 1 to 16,384.
Maximum thresholdThe maximum number of packets allowed in the queue. When the average
queue length exceeds the maximum threshold, WRED drops all packets with the specified DSCP, IP
precedence, discard-class, or atm-clp value. Valid maximum threshold values are from the value of
the minimum threshold to 16,384.
Table 11-7 lists the default drop thresholds for weighted random early detection (WRED) based on
DSCP, IP precedence, and discard-class. For example, if a user-defined drop profile is not available, for
discard-class 3, the router calculates the minimum and maximum thresholds as follows:
Minimum threshold = 11/32 * queue size
Maximum threshold = 1/2 * queue size
The drop probability indicates that the router drops one packet for every 10 packets.
Note
Table 11-7 applies to the PRE2. On the PRE3, when you specify a WRED default drop profile for a
queue, the same profile applies to all DSCP or precedence values. If you do not configure the default
profile, the behavior is to tail drop.

OL-7433-09
11-19
Chapter 11
Table 11-7
Weighted Random Early Detection Default Drop Thresholds
DSCP, Precedence, and

Discard-Class Values
Minimum Threshold
(times the queue size)
Maximum Threshold
(times the queue size)
Drop Probability
All DSCPs
1/4
1/2
1/10
1/4
1/2
1/10
9/32
1/2
1/10
5/16
1/2
1/10
11/32
1/2
1/10
3/8
1/2
1/10
13/32
1/2
1/10
7/16
1/2
1/10
15/32
1/2
1/10
For more information about how WRED uses the minimum and maximum thresholds, and the drop
probability parameters, see the Determining Packet Drop Probability section on page 11-10.
WRED and Queue Limit

To help you manage packet delay due to congestion, you can configure weighted random early detection
(WRED) on a class queue and customize the size of the queue using the queue-limit command. This
allows you to establish a drop policy for a traffic class and simultaneously limit the maximum number
of packets allowed to accumulate in the class queue.
WRED controls the average length of a queue and queue-limit controls the maximum number of packets
that can be waiting for transmission at any time. Together, these mechanisms limit packet delay.
Note
To simultaneously configure WRED and queue limit for a class in a policy map, the router must be
running Cisco IOS Release 12.3(7)XI or later releases. In releases prior to Cisco IOS Release 12.3(7)XI,
you can configure either the random-detect command or the queue-limit command, but not both
commands at the same time.
If you do not specify a queue limit, the router uses the default queue limit of two times the largest
maximum threshold, rounded to the nearest power of 2.
Note
To modify the queue length, always use the queue-limit command instead of the max-threshold
parameter of the random-detect command. Modifying the max-threshold parameter does not
necessarily change the queue limit. When you increase the max-threshold parameter, WRED adjusts the
queue length to be no less than the max-threshold value. However, when you reduce the max-threshold
parameter, WRED does not change the queue length.
11-20
OL-7433-09
Chapter 11

Average Queue Size and the Exponential Weight Constant

The router calculates the average queue size based on the previous average and the current size of the
queue, using the following formula:
Average = (old-average * (1 2 n)) + (current-queue-size * 2 n)
where n is the exponential weight constant
You can configure the exponential weight constant; however, we recommend that you use the default
value of 9. Valid values are from 1 to 16.
A high exponential weight constant smooths out the peaks and lows in queue length. The average
queue size is unlikely to change very quickly, avoiding drastic swings in size. WRED might be slow
to start dropping packets and can continue dropping packets for a time after the actual queue size
has fallen below the minimum threshold. The slow-moving average accommodates temporary bursts
in traffic.
If the exponential weight constant is too high, WRED does not react to congestion and packets are
transmitted or dropped as if WRED were not in effect.
If the exponential weight constant is too low, the average queue size might fluctuate with changes
in the traffic levels. As a result, WRED responds quickly to long queues, overreacts to temporary
traffic bursts, and drops traffic unnecessarily. After the queue falls below the minimum threshold,
WRED stops dropping packets.

The following describes interface support for tail drop, random early detection (RED), and weighted
random early detection (WRED) drop policies using the queue-limit and random-detect commands:
Interfaces Supporting the queue-limit and random-detect Commands (Outbound Only)
Physical
subinterfaces *
ATM constant bit rate (CBR) PVCs and point-to-point subinterfaces *
ATM variable bit rate (VBR) PVCs and point-to-point subinterfaces *
Label-controlled ATM (LC-ATM) subinterfaces **
Frame Relay PVCs, point-to-point subinterfaces, and map classes **
Ethernet VLANs **
* The PRE3 does not support the queue-limit and random-detect commands on ATM subinterfaces
because the PRE3 only supports MQC policy maps on ATM PVCs.
** Requires a specific type of hierarchical policy. For more information, see the Chapter 13, Defining
Note
The router supports the queue-limit and random-detect commands on outbound interfaces only.

OL-7433-09
11-21
Chapter 11
Interfaces Not Supporting the queue-limit and random-detect Commands
Note
IP tunnel
The router does not support the queue-limit and random-detect commands on inbound interfaces.

Queue Limit
You cannot apply queue limits to ATM unshaped unspecified bit rate (UBR) PVCs. Unshaped UBR
PVCs do not have a peak cell rate (PCR) specified.
For classes other than class-default, when you configure a queue limit, you must also configure one
of the following commands for the class:
bandwidth
bandwidth remaining (PRE2), bandwidth remaining ratio (PRE3), or bandwidth remaining
percent (PRE3)
priority
shape
For releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, you cannot combine the
queue-limit command with the random-detect command.
The router restricts the aggregate sum of queue limits to 1,048,576 (PRE1) or 4,194,304 (PRE2)
packets.
If you attempt to change the queue size when packets are in the queue, the router does not change
the queue size. However, changing the queue size several times can cause the buffers to become
fragmented or the buffers can still be in use. When you attempt to change the queue size again (with
or without traffic running), a traceback message or an out of resources message might appear, or
both messages might appear. The workaround for this is to execute the same queue-limit command
again. Use the show pxf cpu queue summary command to determine if traffic is being properly
distributed. (See CSCed81996.)
Note
In Cisco IOS Release 12.2(33)SB and later releases, the show pxf cpu queue interface
summary command displays the physical interface and the number of logical links. It no longer
displays the number of priority queues, class queues and so on.
The following are examples of the messages that appear:
Without traffic running:
-Traceback= 604D58EC 604C00C0 604C0288 604C43C4 604C43E4 604C254C 604C260C
604C478C 60D4B868 603AC304 6013B410 603C6270 604569C0 604569A4
!
With traffic running:

Router# config terminal
Enter configuration commands, one per line.
End with CNTL/Z.
11-22
OL-7433-09
Chapter 11

Router(config)# policy-map qos_pq_cbwfq_0

Router(config-pmap)# class dscp_10
Queue limit failed on ATM2/0/0.2484 VC 2484 (out of resources)
!
!
!
!
-Traceback= 604D58EC 604C00C0 604C0288 604C43C4 604C43E4 604C254C 604C260C
604C478C 60D4B868 603AC304 6013B410 603C6270 604569C0 604569A4
-Traceback= 6049CA48 6049CCA4 60489224 60493688 604BFA4C 604C3EEC 604C3EE4
604C2554 604C260C 604C478C 60D4B868 603AC304 6013B410 603C6270 604569C0 604569A4
Random Early Detection and Weighted Random Early Detection
For classes other than class-default, you must use random early detection (RED) with the
bandwidth, bandwidth remaining, or shape command.
You cannot use DSCP-based WRED with Multiprotocol Label Switching (MPLS) encapsulated
packets. The router supports this feature for use with IP packets only.
You must configure the bandwidth command before you configure the random-detect dscp-based,
random-detect prec-based, or random-detect discard-class-based command to enable WRED.
For DSCP-based WRED, you can configure:

One default drop profile for each class
Three assured forwarding (AF) drop profiles for each class
Four non-AF drop profiles for each policy map (PRE1) or four non-AF drop profiles for each
class (PRE2)
On the PRE3, when you configure multiple WRED profiles for a specific traffic class in a policy
map, each WRED profile within the same class must be based on the same drop type: DSCP-based,
precedence-based, or discard-class-based. You cannot mix drop types within a class in a policy map.
For example, the following example configuration shows how to configure WRED for the Bronze
class. Notice that each of the WRED profiles is based on a DSCP.
class-map Bronze
match ip dscp 1 2 3
policy-map Business
class Bronze
random-detect dscp 1 100 200 1
random-detect dscp default 200 400 1
On the PRE2, DSCP-based WRED enables you to configure eight unique drop precedence levels for
one queue. Each of the 64 (0 to 63) DSCP values correspond to one of the eight drop levels. The
default setting applies to any DSCP-based WRED without a specified minimum and maximum
threshold value.
On the PRE1, DSCP-based WRED enables you to configure four unique drop precedence levels for
one queue. Each of the 64 DSCP values correspond to one of the four drop levels. When you
configure the four unique drop precedence levels, all of the queues configured on an interface share
the different levels.

OL-7433-09
11-23
Chapter 11
For PRE1, you cannot use DSCP-based and IP precedence-based WRED together in the same policy
map.
On a PRE2, the CoS-based WRED feature is not supported.

To configure the queue limit of a class queue and a drop policy, perform any of the following
Controlling Packet Dropping by Setting the Size of a Class Queue, page 11-24
Dropping Packets Based on a Differentiated Services Code Point, page 11-26
Dropping Packets Based on IP Precedence, page 11-28
Dropping Packets Based on the Discard Class, page 11-29
Dropping Packets Based on the ATM Cell Loss Priority, page 11-31
Controlling Packet Dropping by Setting the Size of a Class Queue

To control when the router drops packets (for example, using tail drop), configure the maximum number
of packets a class queue can hold by entering the following commands beginning in global configuration
mode:
Step 1
Command
Purpose

configuration mode.
Step 2
actions.
Step 3
{bandwidth-kbps | percent percent}
Specifies the amount of bandwidth (in kbps or as a 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.
11-24
OL-7433-09
Chapter 11

Step 4
Command
Purpose
Router# queue-limit number-of-packets
Specifies or modifies the maximum number of packets that

the queue can hold for this class.
For PRE1, number-of-packets is a number from 32 to 16,384;
the number must be a power of 2. If the number you specify
is not a power of 2, the router converts the number to the
nearest power of 2 value.
For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX
with PRE2, number-of-packets is a number from 32 to
16,384. The number does not need to be a power of 2.
For Cisco IOS Release 12.3(7)XI and later releases with
PRE2, if the interface speed is less than 500 MB,
number-of-packets is a number from 8 to 4096; the number
must be a power of 2. If the interface speed is greater than 500
MB, number-of-packets is a number from 128 to 64,000; the
number must be a power of 2.
For PRE3, number-of-packets is a number from 1 to 32,767.
The number does not need to be a power of 2.
If you do not specify number-of-packets, by default the router
uses the values described in the Queue-Limit Default
Behavior section on page 11-25.
Queue-Limit Default Behavior
The following describes the default behavior of the queue-limit command for class queues with and
without weighted random early detection (WRED):
Note
For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX, the router does not round the value
to the nearest power of 2.
Priority queues and class queues without WREDThe router has buffers for up to 50 milliseconds
of 256-byte packets at line rate, but not less than 32 packets.
Configuration Example for Controlling Packet Dropping by Setting a Queue Size

Example 11-1 shows how to create a policy map named Policy1 that contains two classes named Class1
and Class2. The Class1 configuration requests a specific bandwidth allocation and specifies the
maximum number of packets that can be queued for the class. Because Class1 limits the number of
packets that can be held in the queue to 32, the router uses tail drop to drop packets when that limit is
reached. Class2 specifies only the bandwidth allocation request. The Policy1 QoS service policy is
applied to the point-to-point PVC 1/32 for outbound packets.
Example 11-1 Configuring a Queue Limit to Control Tail Drop

OL-7433-09
11-25
Chapter 11
Router(config-subif-atm-vc)# ubr 10000
Router(config-subif-atm-vc)# service-policy output Policy1
Dropping Packets Based on a Differentiated Services Code Point

To configure WRED to drop packets based on a specific differentiated services code point (DSCP) value,
Step 1
Command
Purpose
Router(config-if)# class-map
class-map-name
Creates a class map to be used for matching packets to a specified

class. Enters class map configuration mode.
class-map-name identifies the class map.
Step 2
Router(config-cmap)# match
match-criterion
Configures the match criterion for a class map.

match-criterion is a match statement that indicates how the router
is to classify packets. See the Defining Match Criteria Using the
match Commands section on page 2-5.
Step 3
Exits class map configuration mode.
Step 4
Router(config)# policy-map
policy-map-name
Creates or modifies a policy map that can be attached to one or

more interfaces to specify a service policy. Enters policy map
configuration mode.
Step 5
Specifies the name of the traffic class for which you want to
define QoS actions. Enters policy map class configuration mode.
class-map-name identifies the traffic class. It is the name of the
class-map you configured in Step 1.
Step 6
PRE2
Router(config-pmap-c)# random-detect
dscp-based
PRE3
dscp-based aggregate [minimum-thresh
min-thresh maximum-thresh max-thresh
mark-prob mark-prob]
Indicates that WRED is to use the DSCP value when calculating

the drop probability for a packet.
(Optional) min-thresh is the minimum number of packets allowed
in the queue. Valid minimum threshold values are from 1 to
16,384.
(Optional) max-thresh is the maximum number of packets
allowed in the queue. Valid maximum threshold values are from
the value of the minimum threshold to 16,384.
(Optional) mark-prob is the drop rate. Valid values are from 1 to
65,535. The default value is 10.
11-26
OL-7433-09
Chapter 11

Step 7
Command
Purpose
PRE2
Router(config-pmap-c)# random-detect dscp
dscp-value min-thresh-value
max-thresh-value
Configures WRED to drop packets based on the DSCP value you

specify.
PRE3
dscp values sub-class-val1
mark-prob mark-prob
dscp-value or sub-class-val is a number or keyword that indicates

the differentiated services code point. Value numbers are from 0
to 63, or it can be one of the following keywords: ef, af11, af12,
af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs1, cs2,
cs3, cs4, cs5, or cs7.
min-threshold is the minimum number of packets allowed in the
queue. Valid minimum threshold values are from 1 to 16,384.
max-thresh is the maximum number of packets allowed in the
queue. Valid maximum threshold values are from the value of the
minimum-threshold to 16,384.
mark-probability-denominator-value (PRE2) or mark-prob
(PRE3) is the drop rate. Valid values are from 1 to 65,535. The
default value is 10.
Step 8
Exits policy map class configuration mode.
Step 9
Exits policy map configuration mode.
Step 10

slot/module/port.subinterface-number
Configures an interface type and enters interface configuration

mode.
Step 11

policy-map-name
Attaches a policy map to an output interface or VC to be used as

the service policy for that interface or VC.
policy-map-name is the name of the policy map you configured in
Step 4.
Configuration Example for Configuring DSCP-Based WRED

Example 11-2 shows how to create a class map named Gold and associate it with the policy map named
Business. The configuration enables WRED to drop Gold packets based on DSCP 8 with a minimum
threshold of 24 and a maximum threshold of 40. The Business policy map is attached to the outbound
ATM interface 1/0/0.
Example 11-2 Configuring DSCP-Based WRED
Router(config-if)# class-map Gold
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 8 24 40

OL-7433-09
11-27
Chapter 11
Dropping Packets Based on IP Precedence

To drop packets based on IP precedence, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
policy-map-name
Specifies the name of the policy map to be created or modified.

Enters policy-map configuration mode.
Step 2
Step 3
PRE2
precedence-based
Indicates that weighted random early detection (WRED) is to use

the IP precedence of a packet when calculating the packet drop
probability.
PRE3
precedence-based aggregate
[minimum-thresh min-thresh maximum-thresh
max-thresh mark-prob mark-prob]
(Optional) min-thresh is the minimum number of packets allowed

in the queue. Valid minimum threshold values are from 1 to
16,384.
(Optional) max-thresh is the maximum number of packets
(Optional) mark-prob is the drop rate. Valid values are from 1 to
65,535. The default value is 10.
Step 4
precedence prec-value min-thresh-value
max-thresh-value
PRE3
precedence values sub-class-val1
mark-prob mark-prob
Configures WRED to drop packets based on the IP precedence

value you specify.
prec-value (PRE2) or values sub-class-val (PRE3) is a number
that identifies the IP precedence level. Valid values are from 0 to
7.
min-thresh is the minimum number of packets allowed in the
queue. Valid minimum threshold values are from 1 to 16,384.
max-thresh is the maximum number of packets allowed in the
queue. Valid maximum threshold values are from the value of the
minimum threshold to 16,384.
mark-probability-denominator-value (PRE2) or mark-prob
(PRE3) is the drop rate. Valid values are from 1 to 65,535. The
default value is 10.
11-28
OL-7433-09
Chapter 11

Configuration Example for Dropping Packets Based on IP Precedence

Example 11-3 shows how to enable IP precedence-based weighted random early detection (WRED). In
this example, the configuration of the class map named Class1 indicates to classify traffic based on
IP precedence 3, 4, and 5. Traffic that matches IP precedence 3, 4, or 5 is assigned to the class named
Class1 in the policy map named Policy1. WRED-based packet dropping is configured for Class1 and is
based on IP precedence 3 with a minimum threshold of 500, maximum threshold of 1500, and a
mark-probability-denominator of 200. The QoS policy is applied to PVC 1/32 on the point-to-point ATM
subinterface 1/0/0.1.
Example 11-3 Configuring IP Precedence-Based WRED
Router(config-cmap)# match ip precedence 3 4 5
Router(config-pmap-c)# random-detect prec-based
Router(config-pmap-c)# random-detect precedence 3 500 1500 200
Router(config-subif-atm-vc)# service-policy output policy1
Dropping Packets Based on the Discard Class

To drop packets based on the discard class, enter the following commands beginning in global
configuration mode:
Note
Step 1
Dropping packets based on the discard class requires Cisco IOS Release 12.3(7)XI or later releases
(PRE2), or Cisco IOS Release 12.2(31)SB2 or later releases (PRE3).
Command
Purpose
policy-map-name

Step 2
Step 3
PRE2, PRE3
discard-class-based

the discard class of a packet when calculating the packet drop
probability.

OL-7433-09
11-29
Chapter 11
Step 4
Command
Purpose
PRE2, PRE3
discard-class discard-class-value
Configures WRED to drop packets based on the discard value you

specify.
discard-class-value is a number that indicates the drop eligibility
of a packet. Valid values are from 0 to 7.
min-thresh-value is the minimum number of packets allowed in
the queue. Valid minimum threshold values are from 1 to 16,384.
max-thresh-value is the maximum number of packets allowed in
the queue. Valid maximum threshold values are from the value of
the minimum threshold to 16,384.
mark-probability-denominator-value is the drop rate. Valid values
are from 1 to 65,535. The default value is 10.
Configuration Example for Dropping Packets Based on Discard Class

Example 11-4 shows how to enable discard-class-based weighted random early detection (WRED). In
this example, the configuration of the class map named Silver indicates to classify traffic based on
discard class 3 and 5. Traffic that matches discard class 3 or 5 is assigned to the class named Silver in
the policy map named Premium. The Silver configuration includes WRED packet dropping based on
discard class 5 with a minimum threshold of 500, maximum threshold of 1500, and a
mark-probability-denominator of 200. The QoS policy is applied to PVC 1/81 on point-to-point ATM
subinterface 2/0/0.2 in the outbound direction.
Example 11-4 Configuring Discard-Class-Based WRED
Router(config)# class-map Silver
Router(config-cmap)# match discard-class 3 5
Router(config-pmap)# class Silver
Router(config-pmap-c)# random-detect discard-class-based
Router(config-pmap-c)# random-detect discard-class 5 500 1500 200
Router(config-subif-atm-vc)# service-policy output Premium
11-30
OL-7433-09
Chapter 11

Dropping Packets Based on the ATM Cell Loss Priority

To drop packets based on the ATM cell loss priority (CLP), enter the following commands beginning in
Note
Step 1
Dropping packets based on the CLP requires the PRE3 and Cisco IOS Release 12.2(33)SB, or a later
release.
Command
Purpose
policy-map-name

Step 2
Step 3
atm-clp-based

the CLP value of a packet when calculating the packet drop
probability.
Step 4
Router(config-pmap-c)# random-detect clp

[clp-value] [min-thresh-value]
[max-thresh-value]
[mark-probability-denominator-value]
Configures WRED to drop packets based on the CLP value you

specify.
clp-value is a number that indicates the cell loss priority of a
packet. Valid values are 0 or 1.
(Optional) min-thresh-value is the minimum number of packets
allowed in the queue. Valid minimum threshold values are from 1
to 16,384.
(Optional) max-thresh-value is the maximum number of packets
(Optional) mark-probability-denominator-value is the drop rate.
Valid values are from 1 to 65,535. The default value is 10.
Configuration Example for Dropping Packets Based on the Cell Loss Priority
Example 11-5 shows how to configure ATM CLP-based WRED. In the example, traffic that matches
CLP 1 is classified as belonging to class1. In the policy map named policymap1, the class1 configuration
enables the ATM CLP-based WRED feature and configures WRED to randomly drop traffic with the
CLP bit set to 1 when traffic exceeds the minimum threshold of 12 and the maximum threshold of 25.
WRED uses a mark-probability-denominator of 10.
Example 11-5 Configuring CLP-Based WRED
Router(config-cmap)# match clp 1
Router(config)# policy-map policymap1

OL-7433-09
11-31
Chapter 11
Verifying and Monitoring Layer 3 Packet Dropping

Router(config-pmap-c)# random-detect atm-clp-based
Router(config-pmap-c)# random-detect clp 1 12 25 10

For releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, the router maintains only
the total random and tail drop statistics for all IP precedence levels.
In Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, and later releases, the router maintains
separate WRED drop statistics for each IP precedence, DSCP, and discard-class value.
The router collects the following statistical information:
Current average queue length
Per-precedence random and maximum threshold packets and bytes dropped
To verify and monitor packet dropping, use any of the following commands in privileged EXEC mode:
Command
Purpose
Router# show interface type

Displays configuration information about the interface you

specify, including the current queue limit.
Displays configuration information about the policy map you

specify.
In Cisco IOS Release 12.3(7)XI and later releases, this command
shows WRED drop counts for each IP precedence, DSCP value,
and discard class.
In all releases prior to Cisco IOS Release 12.3(7)XI, this
command shows drop counts for each class.
Displays the configuration of classes configured for service

policies on all interfaces.
Router# show pxf cpu queue interface
Displays the queuing statistics of an interface or VC.
11-32
OL-7433-09
Chapter 11

For diagnostic purposes, use any of the following commands in privileged EXEC mode:
Command
Purpose
Router# show pxf cpu queue interface
Displays the output queue statistics for a particular interface. If

you do not specify an interface, the route processor queue
statistics display.
Use this command to determine if traffic is being properly
distributed.
Note
Each interface has two queues: low and high priorities.

When you enter this command, the output that displays
includes the following fields:
wq_len indicates the current depth of the output queue
for the interface.
wq_limit_drop indicates the number of packets dropped
because the output queue was full.
packet xmit indicates the number of packets that have
been output.
byte xmit indicates the number of bytes that have been
output.
Router# show pxf cpu queue interface summary
Displays queue scaling information such as:
Number of queues and recycled queues
Number of available queue IDs (QIDs)
Number of packet buffers, recycled packet buffers, and free

packet buffers
Note
Router# show pxf cpu schedule
Note
In Cisco IOS Release 12.2(33)SB, this command was

modified to display only the physical interface and the
number of logical links, and was implemented on the
PRE3 and PRE4. The command output no longer displays
the number of priority queues, class queues, and so on.
Displays the rates at which each interface gets packets from the
forwarding engine.
The show pxf commands are entered as show hardware pxf on the PRE1.

OL-7433-09
11-33
Chapter 11
Verification Example for Queue Size and Packet Dropping

Example 11-6 shows sample output for the show policy-map interface command. In this example, the
policy map named Traffic-5-PR is attached to serial interface 1/0/0 and includes three traffic classes. The
Voice-5-PR class has a configured queue limit of 32 packets with 0 packets dropped. The Gold-5-PR
class also indicates that no packets dropped. The Silver-5-PR class has a configured queue limit of 64
packets with 0 packets dropped.
Example 11-6 Displaying Queue Sizes and Packet Drop Counts
Router# show policy-map interface serial 1/0/0
Serial1/0/0
Service-policy output: Traffic-Parent (1051)
2064335 packets, 120273127 bytes
Match: any (1069)
5 minute rate 0 bps
Shape : 6000 kbps
Service-policy : Traffic-5-PR (1052)
Class-map: Voice-5-PR (match-all) (1053/1)
Match: ip precedence 5 (1054)
Absolute priority
Queue-limit: 32 packets
Police:
Class-map: Gold-5-PR (match-any) (1058/2)
1125476 packets, 67528560 bytes
Match: ip precedence 3 4 (1059)
1125476 packets, 67528560 bytes
5 minute rate 0 bps
Class-map: Silver-5-PR (match-any) (1061/3)
Match: ip precedence 0 1 2 (1062)
5 minute rate 0 bps
11-34
OL-7433-09
Chapter 11


------------------------------------------------Min
Max Prob
------------------------------------------------0
16
32 1/10
0
0
1
18
32 1/10
0
0
2
20
32 1/10
0
0
3
22
32 1/10
0
0
4
24
32 1/10
0
0
5
26
32 1/10
0
0
6
28
32 1/10
0
0
7
30
32 1/10
0
0
Queue-limit: 64 packets
Match: any (1067)
5 minute rate 0 bps
Verification Examples for DSCP-Based WRED

Example 11-7 shows sample output for the show policy-map interface command. In this example,
DSCP-based weighted random early detection is configured on the nyusers class queue. The output
shows the exponential weight of 9 used to calculate the average queue size. In this case, WRED has not
dropped any packets based on DSCP 8 and DSCP 0 (default).
Example 11-7 Displaying DSCP-Based WRED Statistics
Router# show policy-map interface GigabitEthernet 3/0/0
GigabitEthernet3/0/0
Service-policy output: manhattan
Class-map: nyusers (match-all)
0 packets, 0 bytes
Random-detect (DSCP-based):
-----------------------------------------------------Diff-Serv
Min
Max
Mark
codepoint thres thres probability
-----------------------------------------------------8
24
40
1/50
0
0
Default
64
128
1/10
0
0
0 packets, 0 bytes
Match: any

OL-7433-09
11-35
Chapter 11
Example 11-8 shows sample output for the show class-map command. The show class-map command
output indicates that the router classifies traffic based on the default DSCP 0 and DSCP 1, 2, 3, and 5.
Traffic must match all of these DSCP values before the router can assign the traffic to the per_dscp_class
traffic class.
Example 11-8 Displaying Sample Output from the show class-map Command
Router# show class-map per_dscp_class
Class Map match-all per_dscp_class (id 11)
Match ip dscp default 1 2 3 5
Example 11-9 shows sample output for the show policy-map command. The show policy-map
command output indicates that the drop policy for the class named per_dscp_class is based on DSCP 1,
2, 3, and 5.
Example 11-9 Displaying Sample Output from the show policy-map Command
Router# show policy-map per_dscp_policy
Policy Map per_dscp_policy
Class per_dscp_class
priority
random-detect dscp-based
Verification Example for IP Precedence-Based WRED

Example 11-10 shows sample output for the show policy-map interface command when IP
precedence-based WRED is configured on the new-users class queue. For each precedence level, the
output indicates the minimum and maximum thresholds, the mark probability value, the number of
packets dropped using RED, and the number of packets dropped using tail drop.
Example 11-10 Displaying IP Precedence-Based WRED Statistics
Router# show policy-map interface FastEthernet 3/0/0
FastEthernet3/0/0
Service-policy output: voice
Class-map: new-users (match-all)
0 packets, 0 bytes
----------------------------------------------------------------------TOS
Min
Max
Mark
Rand-Drops
Tail-Drops
precedence thres
thres probability
----------------------------------------------------------------------0
2048
4096
1/10
10
5
1
2304
4096
1/10
3
1
2
2560
4096
1/10
0
0
11-36
OL-7433-09
Chapter 11

3
4
5
6
7
2816
3072
3328
3584
3840
4096
4096
4096
4096
4096
1/10
1/10
1/10
1/10
1/10
0
5
0
2
0
0
1
0
0
0
Verification Example for Discard-Class-Based WRED

Example 11-11 shows sample output for the show policy-map interface command when
discard-class-based WRED is configured on the vlan1 class queue. For each discard-class level, the
output indicates the minimum and maximum thresholds, the mark probability value, the number of
packets dropped using RED, and the number of packets dropped using tail drop.
Example 11-11 Displaying Discard-Class-Based WRED Statistics
Router# show policy-map interface GigabitEthernet 1/0/0
GigabitEthernet1/0/0
Service-policy output: bronze
Class-map: vlan1 (match-all)
0 packets, 0 bytes
Random-detect (discard-class-based):
--------------------------------------------------------------Discard
Min
Max
Mark
class
thres
thres
probability
--------------------------------------------------------------0
10
100
1/40
2
100
1
100
200
1/40
15
0
2
2560
4096
1/10
0
0
3
2816
4096
1/10
0
0
4
3072
4096
1/10
0
0
5
3328
4096
1/10
0
0
6
3584
4096
1/10
0
0
7
3840
4096
1/10
0
0

OL-7433-09
11-37
Chapter 11
Verification Examples for ATM CLP-Based WRED

Example 11-7 shows sample output for the show policy-map interface command when ATM
CLP-based WRED is configured on a Cisco 10000 series router with a PRE3. The output shows the
threshold values configured for CLP 1.
Example 11-12 Displaying ATM CLP-Based WRED Statistics (PRE3)
Router# show policy-map policymap1
Service-policy output: policymap1
Class-map: class1 (match-all)
0 packets, 0 bytes
Match: none
Queueing
Queue limit 50 packets
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0 bytes
clp
Transmitted Random drop
Tail drop
pkts/bytes
pkts/bytes
pkts/bytes
0
0/0
0/0
0/0
1
0/0
0/0
0/0
Minimum
thresh
0
12
Maximum
thresh
0
25
Mark
prob
1/0
1/10
Example 11-7 shows sample output for the show policy-map command when ATM CLP-based WRED
is configured on a Cisco 10000 series router with a PRE2. The output shows the threshold values
configured for CLP 1.
Example 11-13 Displaying ATM CLP-Based WRED Statistics (PRE2)
Router# show policy-map policymap1
Service-policy output: policymap1
Class-map: class1 (match-all)
0 packets, 0 bytes
Match: none
Random-detect (clp-based) :
------------------------------------------------------------------------ATM
Min
Max
Mark
Rand-Drop
Tail-Drop
CLP
thres
thres
probability Pkts Bytes Pkts Bytes
---------------------------------------------------------------0
4097
8192
1/10
0
0
0
0
1
12
25
1/10
0
0
0
0
11-38
OL-7433-09
Chapter 11

Controlling Packet Flow on Layer 2 Queues
Controlling Packet Flow on Layer 2 Queues

The ATM VC queue depth feature controls the depth of Layer 2 ATM cell queues and is used primarily
for flow control. You specify the VC queue depth when you create the ATM VC on the line card.
To be fully effective, you must set the segmentation and reassembly (SAR) line card queue depth for
each VC interface queue above the weight for VC weighting by using the queue-depth command. This
command enables you to set the high watermark and low watermark, which define the depth of the VC
interface queue. The optimum threshold values for these watermarks are a function of a number of
variables, such as the following:
Number of queues on a VC
Priority queue latency requirements
Bandwidth of the VC
Accuracy of VC bandwidth utilization
Per-queue bandwidth accuracy
Because so many variables influence watermark threshold values, you might need to experiment with
different values to determine the optimum high and low watermark values for your configuration. In
general, the following guidelines apply:
Set the low watermark equal to the VC weight. If the low watermark is less than the VC weight, a
full weight worth of cells might not be enqueued in the SAR mechanism when the scheduler
round-robin gets to the VC. As a result, the VC might not get its fair share.
Set the high watermark equal to the low watermark plus 2.
For more information about the high and low watermarks, see the High Watermark and Low Watermark
Default Values section on page 15-25 in Chapter 15, Oversubscribing Physical and Virtual Links.
Table 11-8 lists the default minimum and maximum threshold values for ATM variable bit rate (VBR)
and unspecified bit rate (UBR) virtual circuits.
Table 11-8
ATM Default Threshold Values
Type of ATM
Virtual Circuit
Virtual Circuit Rate

(in bps)
Minimum
Threshold
Maximum
Threshold
Variable Bit Rate (VBR)
0 to 18999
48
56
19000 to 40999
64
72
41000 to 99999
128
144
100000 to 622000
224
240
Not Applicable
224
240
Unspecified Bit Rate (UBR)
When changing the minimum and maximum threshold values, consider the following guidelines:
To enhance virtual circuit utilization accuracy, increase the minimum threshold and possibly the
maximum threshold.
To enhance per-queue accuracy, increase the spread between the thresholds. For example, if the
minimum threshold is 66 and the maximum threshold is 70, increase the maximum threshold to 72
to increase the spread.
To reduce latency, decrease the maximum threshold.
To increase the number of queues, increase the maximum threshold.

OL-7433-09
11-39
Chapter 11
For more information, see the Configuring VC Weighting section on page 15-28 in Chapter 15,
Oversubscribing Physical and Virtual Links.
Configuring the Depth of Layer 2 Queues

For information about configuring Layer 2 queue depths, see the Configuring VC Queue Depth section
on page 15-38.
Feature
Class-Based Weighted Random Early Detection

(CBWRED)

Release 12.3
Part 2: Congestion Management > Configuring Weighted
Fair Queuing > Class-Based Weighted Fair Queuing
Configuration Task List > Configuring Class Policy in the
Policy Map > Configuring Class Policy Using WRED
Packet Drop
Part 3: Congestion Avoidance > Congestion Avoidance
Overview > About Random Early Detection
Part 3: Congestion Avoidance > Configuring Weighted
Random Early Detection
DiffServ-Compliant WRED
DiffServ Compliant Weighted Random Early Detection,

Release 12.1(5)T feature module
DSCP-Based Weighted Random Early Detection (WRED) DiffServ Compliant Weighted Random Early Detection,
Implementing Quality of Service Policies with DSCP tech notes
DSCP-Compliant WRED
ATM Traffic Management, Troubleshooting Output Drops with

Priority Queuing tech note
Low Latency Queuing, Release 12.0S feature module
IP to ATM Class of Service, Low Latency Queuing
Low Latency Queuing, Release 12.0T feature module
Per-VC Queuing for VBR-nrt

Release 12.2
Part 7: Quality of Service Solutions > IP to ATM Class of
Service Overview > IP to ATM CoS Features
11-40
OL-7433-09
Chapter 11

Feature
Per-VC WRED for VBR-nrt

Release 12.2
Part 7: Quality of Service Solutions > IP to ATM CoS
Overview > IP to ATM CoS Features
Part 7: Quality of Service Solutions > Configuring IP to
ATM CoS > IP to ATM CoS on a Single ATM VC
Configuration Task List
Part 7: Quality of Service Solutions > Configuring IP to
ATM CoS > Per-VC WFQ and CBWFQ Configuration Task
List
Priority Queuing (PQ)/CBWFQ on ATM PVCs

Release 12.2
Part 2: Congestion Management > Congestion Management
Overview > Priority Queuing
Part 2: Congestion Management > Configuring Priority
Queuing
Part 2: Congestion Management > Congestion Management
Overview > Weighted Fair Queuing > Class-Based
Weighted Fair Queuing
Part 2: Congestion Management > Configuring Weighted
Fair Queuing > Class-Based Weighted Fair Queuing
Configuration Task List
Random Early Detection with Queue-Limit
Release Notes for the Cisco 10000 Series Internet Router for
Cisco IOS Release 12.0(25)SX
New Features in Cisco IOS Release 12.0(25)SX > Random
Early Detection with Queue-Limit

OL-7433-09
11-41
Chapter 11
11-42
OL-7433-09
CH A P T E R
12

When no QoS policies exist, the router serves traffic with best effort service. The router makes no
distinction between high and low priority traffic and makes no allowances for the needs of different
applications. This is not a problem until congestion occurs and response time slowslarger packets take
longer to transmit and smaller packets are delayed behind larger packets.
To provide consistent response time to heavy and light traffic without adding excessive bandwidth, the
Cisco 10000 series router provides a queuing technique called Class-Based Weighted Fair Queuing
(CBWFQ). This technique reduces response time for real-time traffic and fairly shares the remaining
bandwidth between high bandwidth flows.
This chapter describes CBWFQ and includes the following topics:
Class-Based Weighted Fair Queuing, page 12-1
Class-Based Weighted Fair Queuing for Virtual Access Interfaces, page 12-4
System Limits for CBWFQ, page 12-6
Interfaces Supporting Class-Based Weighted Fair Queuing, page 12-7
Configuring Fair Bandwidth Sharing During Congestion, page 12-7
Configuration Examples for Sharing Bandwidth Fairly, page 12-18
Verifying and Monitoring Class-Based Weighted Fair Queuing, page 12-20
Class-Based Weighted Fair Queuing

Class-Based Weighted Fair Queuing (CBWFQ) is an automated scheduling method that provides fair
bandwidth allocation to all network traffic. CBWFQ 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. CBWFQ provides consistent response time to heavy and light traffic
without adding excessive bandwidth. CBWFQ reduces response time for real-time traffic and fairly
shares the remaining bandwidth between high bandwidth flows.
CBWFQ provides support for user-defined traffic classes. The router classifies traffic based on match
criteria you define for each class (for example, protocols, access control lists (ACLs), and input
interfaces). Packets satisfying the match criteria for a class constitute the traffic for that class. The router
reserves a first-in first-out (FIFO) queue for each class and directs traffic belonging to a class to the
queue for that class.

OL-7433-09
12-1
Chapter 12
After defining a class according to its match criteria, you can assign it characteristics by assigning it
bandwidth, weight, and maximum packet limit. The bandwidth you assign to a class is the guaranteed
bandwidth delivered to the class during congestion. You can also specify the maximum number of
packets allowed to accumulate in the queue for a class, referred to as the queue limit for the class. Packets
belonging to a class are subject to the bandwidth and queue limits that characterize the class.
After a queue reaches its configured queue limit, enqueueing of additional packets to the class causes
packet drop to occur. The router drops packets using one of the following methods, depending on how
you configured the traffic class:
Note
Tail dropThe default congestion avoidance mechanism for Layer 3 queues. Tail drop activates
when a queue becomes full. After being activated, no packets make it to the queue. Tail drop treats
all traffic equally and does not differentiate between classes of service.
Weighted Random Early Detection (WRED)A mechanism for avoiding congestion of Layer 3
queues. WRED combines the capabilities of the random early detection (RED) mechanism with IP
precedence, differential services code point (DSCP), and discard-class to provide preferential
handling of higher priority packets. WRED attempts to anticipate and avoid congestion. WRED
implements a proactive queuing strategy that manages congestion before a queue reaches its queue
depth. By selectively dropping packets, WRED prevents packets from enqueuing to the Layer 3
queue.
If you use WRED packet drop instead of tail drop for one or more traffic classes in a policy map, the
interface to which you attach that policy map cannot have WRED configured.
If you configure the class-default class using the bandwidth command, the router places all unclassified
traffic into a single FIFO queue and allocates bandwidth according to the configured bandwidth. If you
do not configure the class-default class, then by default the router gives best-effort treatment to the traffic
that does not match any of the configured classes. After the router classifies a packet, all of the standard
mechanisms that you can use to differentiate service among the classes apply.
For CBWFQ, the weight specified for the class becomes the weight of each packet that meets the match
criteria of the class. The router classifies packets that arrive at the output interface according to the match
criteria filters you define. The router then assigns each one the appropriate weight. The router derives
the weight for a packet belonging to a specific class from the bandwidth you assign to the class when
you configure it. In this sense the weight for a class is user-configurable.
After the router assigns the weight for a packet, the router enqueues the packet in the appropriate class
queue. CBWFQ uses the weights assigned to the queued packets to ensure that the router services the
class queue fairly.
You can configure CBWFQ on a physical interface only if the interface is in the default queuing mode.
Serial interfaces at E1 (2.048 Mbps) and below use WFQ by default; other interfaces use FIFO by
default. Enabling CBWFQ on a physical interface overrides the default interface queuing method.
Enabling CBWFQ on an ATM permanent virtual circuit (PVC) does not override the default queuing
method.
12-2
OL-7433-09
Chapter 12

Configuring CBWFQ involves the following processes:
Classifying trafficThis process uses class maps to define the classification criteria the router uses
to differentiate one traffic class from another.
Associating class characteristics with each traffic classThis process uses policy maps to define the
class characteristics (policy actions) the router applies to packets belonging to one of the traffic
classes.
Attaching policies to interfacesThis process uses the service-policy command to associate an

existing policy map (service policy) with an interface. The router applies the policy actions defined
in the service policy to the traffic on the interface that belongs to the traffic classes defined in the
service policy.
Feature History for Class-Based Weighted Fair Queuing

Cisco IOS Release
Description
Required PRE
Release 12.0(19)SL
The class-based weighted fair queuing (CBWFQ) feature

was introduced on the router.
PRE1
Release 12.2(16)BX
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
PRE3
Class-Default Class
The class-default class is used to classify traffic that does not fall into one of the defined classes in a
policy map. After the router classifies a packet, the router applies all the standard mechanisms that are
used to differentiate service among the classes. The class-default class is predefined when you create the
policy map, but you must configure it. If you do not configure the default class, then by default the traffic
that does not match any of the configured classes in a policy map is FIFO-classified and given best-effort
treatment.
CBWFQ and Bandwidth Allocation

CBWFQ allows you to specify the exact amount of bandwidth to allocate for a specific class of traffic.
Distributing bandwidth on a link using the bandwidth command ensures that bandwidth is shared fairly
among competing traffic. The router uses class queues to allocate bandwidth, first servicing priority
queue traffic followed by either bandwidth guarantee or bandwidth remaining queue traffic. By default,
a minimum bandwidth guaranteed queue has buffers for up to 50 milliseconds of 256-byte packets at line
rate, but not less than 32 packets. The router does not ensure latency characteristics for bandwidth
queues.
After the router allocates bandwidth to priority and bandwidth guaranteed class queues, the router
divides unused (excess) bandwidth among the packets remaining in the class queues.
For more information about distributing bandwidth across class queues, including how bandwidth is
calculated, see Chapter 5, Distributing Bandwidth Between Queues.

OL-7433-09
12-3
Chapter 12
CBWFQ and RSVP

You can use Resource Reservation Protocol (RSVP) in conjunction with CBWFQ. When you configure
both RSVP and CBWFQ 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 and Limitations for CBWFQ
If you configure a policy map class to use weighted random early detection (WRED), the interface
to which you attach the service policy cannot have WRED configured.
The router does not support traffic shaping and policing with CBWFQ.
The router supports CBWFQ on variable bit rate (VBR) ATM connections.
Class-Based Weighted Fair Queuing for Virtual Access

Interfaces
Class-based weighted fair queuing (CBWFQ) for virtual access interfaces (VAIs) allows a VAI to inherit
the service policy of the VC that the VAI uses (see the Service Policy Inheritance section on
page 12-5). Using CBWFQ, you can:
Configure user-defined traffic classes
Use access control lists (ACLs), protocols, or input interface names to define how to classify traffic
Specify the exact amount of bandwidth to be allocated for a specific class of traffic
To use CBWFQ, you define traffic classes based on match criteria. Packets satisfying the match criteria
for a class constitute the traffic for that class. CBWFQ reserves a FIFO for each class and directs traffic
belonging to a class to the queue for that class.
After you define the match criteria for a traffic class, you can assign the class characteristics. To
characterize a class, you create a policy map and assign each class such parameters as bandwidth and
queue limit. The bandwidth is the guaranteed bandwidth delivered to the class during congestion. The
bandwidth assigned to a class is used to derive a weight for the class. Each packet that meets the match
criteria of the class is assigned the weight of the class and is then enqueued in the appropriate class
queue. CBWFQ uses the weights assigned to the queued packets to ensure that the class queue is serviced
fairly.
You can also specify the queue limit for a class to indicate the maximum number of packets allowed to
accumulate in the queue for the class. Packets belonging to a class are subject to the queue limits that
characterize the class.
12-4
OL-7433-09
Chapter 12

The following apply to CBWFQ functionality:
The definition and application of policies in a policy map are in a single direction, either input or
output.
Rules apply both to input and output policies.
The first policy defined is the one applied for a given VAI.
Policy behavior of native VC traffic remains unchanged.
The order of definition and removal of policies is not stateful.
For more information about CBWFQ, see the Class-Based Weighted Fair Queuing section on
page 12-1.
Feature History for CBWFQ for VAIs

Cisco IOS Release
Description
Required PRE
Release 12.0(25)SX
This feature was introduced on the router.
PRE1
Release 12.2(16)BX
PRE2
Release 12.2(28)SB

PRE2
Service Policy Inheritance

CBWFQ allows you to configure service policies on VC interfaces or subinterfaces. When a remote user
initiates a session, the router uses a predefined configuration template to dynamically create and
configure a virtual access interface (VAI). The VAI uses the attributes of the template to create the
session, which results in a VAI that is uniquely configured for a specific user.
For CBWFQ, when you apply a service policy to a VC, the VAIs that use that VC inherit the service
policy of the VC. Any VAI that uses that VC is subject to the queuing, policing, and marking actions
defined in the VC service policy.
You can only apply a service policy with queuing-related actions to a VC. Do not apply service policies
with CBWFQ actions to a VAI using a virtual template. The Cisco 10000 router supports queuing only
when you apply the service policy to a VC.
Note
You can apply a service policy without queuing-related actions to either a VC or a VAI, but not to both
at the same time.

OL-7433-09
12-5
Chapter 12
Restrictions and Limitations for CBWFQ for VAIs
Both the virtual template and virtual connection must exist before a remote user initiates a session
to the router.
Cisco IOS Release 12.2(25)SX does not support the configuration of broadband aggregation (BBA)
groups using RADIUS. You must configure BBA groups manually.
You can only apply a QoS policy with queuing-related actions to a VC. Do not apply service policies
with class-based weighted fair queuing (CBWFQ) actions to a VAI using a virtual template. The
router supports queuing only when you apply the QoS policy to a VC.
You can apply a QoS policy without queuing-related actions to either a VC or a VAI, but not to both
at the same time.
You cannot use RADIUS to configure a QoS policy on the VC.
If you configure a QoS policy on a VC, the show policy interface vai command does not display
information to indicate that the VAI is subject to the VC service policy. However, if you apply a
policy directly to a VAI, the show policy interface vai command displays information about the
policy on the VAI.
The port must be in atm pxf queuing mode.
You cannot configure a service policy on a VC and on a session at the same time.

For information about the system limits for class maps and policy maps configured for CBWFQ, see the
System Limits for Class Maps section on page 2-2 and the System Limits for Policy Maps section
on page 3-2.
12-6
OL-7433-09
Chapter 12


The following describes interface support for class-based weighted fair queuing (CBWFQ):
Interfaces Supporting CBWFQ (Outbound Only)
Physical
subinterfaces
Ethernet VLANs *
* Requires a specific type of hierarchical policy. For more information, see Chapter 13, Defining QoS
Note
The router only supports CBWFQ on outbound interfaces.

Interfaces Not Supporting CBWFQ
Note
IP tunnel
The router does not support the CBWFQ on inbound interfaces.
Configuring Fair Bandwidth Sharing During Congestion

To configure fair bandwidth sharing using QoS service policies, perform the following required
configured tasks:
Defining Traffic Classes Using Class Maps, page 12-8
Configuring Policy Actions for Traffic Classes Using Policy Maps, page 12-9
Attaching Service Policies, page 12-15
The following are optional configuration tasks:
Modifying the Bandwidth for an Existing Policy Map Class, page 12-16
Modifying the Queue Limit for an Existing Policy Map Class, page 12-17
Deleting Classes, page 12-17
Deleting Policy Maps, page 12-18

OL-7433-09
12-7
Chapter 12
Defining Traffic Classes Using Class Maps

To define a traffic class using a class map, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
Creates or modifies a class map. Enters class-map configuration

mode.
class-map-name is the name of the class map.
Step 2
Router(config-cmap)# match access-group

{access-group-number | name
access-group-name}
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.
or
access-group-number is the number of the access control list

(ACL) against whose contents you want packets to be checked.
name access-group-name is the name of the ACL.
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
interface-name is the type and number of the interface (for

example, ATM 1/0/0).
Router(config-cmap)# match mpls

experimental number
Specifies the value of the experimental (EXP) field to be used as

a match criterion against which packets are checked to determine
if they belong to the class.
number is the EXP value to be used as a match criterion. Valid
values are from 0 to 7, delimited using spaces (for example, 3 4 7).
For more information about match criteria you can define, see the
Defining Match Criteria Using the match Commands section on
page 2-5.
Configuration Example for Defining Traffic Classes Using Class Maps

Example 12-1 creates two ACLs (101 and 102) and two class maps (class1 and class2). To determine if
packets belong to the class, class1 matches packets using ACL 101 and class2 uses ACL 102 match
criteria.
Example 12-1 Defining Traffic Classes Using a Class Map
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-cmap)# class-map class2
12-8
OL-7433-09
Chapter 12

Configuring Policy Actions for Traffic Classes Using Policy Maps

To configure policy actions for a traffic class using a policy map, perform the following configuration
tasks:
Configuring a Default Traffic Class Policy, page 12-9
Configuring a Class Policy and Dropping Packets Using Tail Drop, page 12-11
Configuring a Class Policy and Dropping Packets Using WRED, page 12-12
For more information about QoS policies, see Chapter 3, Configuring QoS Policy Actions and Rules.
Configuring a Default Traffic Class Policy

The router uses the policy actions defined in the default class named class-default for traffic that does
not match the criteria for a specific class or when a QoS policy does not exist for a traffic class.
To configure a default traffic class policy, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
policy-map-name

configuration mode.
Step 2
Specifies the default class so that you can configure or modify its
policy. Enters policy-map class configuration mode.
Step 3
Specifies the amount of bandwidth (in kbps or as a 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.
bandwidth-kbps specifies or modifies the minimum bandwidth
allocated for a class belonging to a policy map. Valid values are
from 8 to 2,488,320, which represents from 1 to 99 percent of the
link bandwidth.
Note
The range of valid values for bandwidth-kbps might be

smaller than the values indicated above. Use the question
mark (?) in context-sensitive help to display the range of
valid values.

percentage of the link bandwidth allocated for a class belonging
to a policy map. Valid values are from 1 to 99.
minimum percentage of unused link bandwidth allocated for a
class belonging to a policy map. Valid values are from 1 to 99.

OL-7433-09
12-9
Chapter 12
Step 4
Command
Purpose
Router(config-pmap-c)# queue-limit
number-of-packets
(Optional) Specifies the maximum number of packets that the

queue can accumulate for this class.
number-of-packets is a number from 1 to 64. The default number
of queue entries is based on the bandwidth rate.
Note
Step 5
(Optional) Enables WRED.

Note
Step 6
exponential-weighting-constant exponent
When you specify the queue-limit command, the router

uses tail drop to drop packets.
When you specify the random-detect command, the
policy map uses WRED to drop packets, not tail drop. If
you configure a class to use WRED, you must ensure that
WRED is not configured on the interface to which you
intend to attach the service policy.
Configures the exponential weight factor used in calculating the

exponent is a number from 1 to 16 used in the average queue size
calculation.
or
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.
precedence is the IP precedence number. Valid values are from 0
to 7.
min-threshold is the minimum average queue length, expressed in
number of packets. Valid values are from 1 to 4096. When the
average queue length reaches the minimum threshold, WRED
randomly drops some packets with the specified IP precedence.
max-threshold is the maximum average queue length, expressed
in number of packets. Valid values are from the value of the
min-threshold to 4096. When the average queue length exceeds
the maximum threshold, WRED drops all packets with the
specified IP precedence.
mark-prob-denominator is the denominator for the fraction of
packets dropped when the average queue depth is at the maximum
threshold. For example, if the denominator is 512, 1 out of every
512 packets is dropped when the average queue is at the maximum
threshold. Valid values are from 1 to 65536. The default is 10 (1
out of every 10 packets is dropped at the maximum threshold).
12-10
OL-7433-09
Chapter 12

Configuring a Class Policy and Dropping Packets Using Tail Drop

To configure a class policy and drop packets using tail drop, enter the following commands beginning in
Note
Step 1
Repeat Steps 2 through 4 to configure additional classes in the policy map.
Command
Purpose
policy-map-name

configuration mode.
Step 2
Assigns a traffic class to a policy map. Enters policy-map class

configuration mode.
map.
Step 3

link bandwidth.
Note

valid values.

Step 4
number-of-packets
Specifies the maximum number of packets that the queue can

accumulate for this class.
number-of-packets is a number from 1 to 64. The default number
of queue entries is based on the bandwidth rate.
Note
When you specify the queue-limit command, the router

uses tail drop to drop packets.

OL-7433-09
12-11
Chapter 12
Configuration Example for Configuring a Class Policy and Dropping Packets Using Tail Drop
Example 12-2 creates a policy map named policy1 that contains two classes (class1 and class2) whose
match criteria were previously defined (see Example 12-1 on page 12-8). The class1 configuration
requests a specific bandwidth allocation and specifies the maximum number of packets that can be
queued for the class. Because the class1 configuration specifies the queue-limit command, the router
uses tail drop to drop packets. The class2 configuration specifies only the bandwidth allocation request;
therefore, the policy map assumes a default queue limit based on the configured bandwidth rate. The
policy1 service policy is applied to PVC 1/32 for outbound packets.
Example 12-2 Configuring a Class Policy and Dropping Packets Using Tail Drop
Router(config-subif-atm-vc)# service-policy output policy1
Configuring a Class Policy and Dropping Packets Using WRED

To configure a class policy and to drop packets using WRED, enter the following commands beginning
Note
Step 1
Repeat Steps 2 through 5 to assign additional traffic classes to the policy map and to configure a class
policy for the traffic classes.
Command
Purpose
policy-map-name

configuration mode.
Step 2

configuration mode.
map.
12-12
OL-7433-09
Chapter 12

Step 3
Command
Purpose

link bandwidth.
Note

valid values.

Step 4
Enables weighted random early detection (WRED).

Note
When you specify the random-detect command, the

policy map uses WRED to drop packets, not tail drop. If
you configure a class to use WRED, you must ensure that
WRED is not configured on the interface to which you
intend to attach the service policy.

OL-7433-09
12-13
Chapter 12
Step 5
Command
Purpose
exponential-weighting-constant exponent
Configures the exponential weight factor used in calculating the

exponent is a number from 1 to 16 used in the average queue size
calculation.
or
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.
precedence is the IP precedence number. Valid values are from 0
to 7.
min-threshold is the minimum average queue length, expressed in
number of packets. Valid values are from 1 to 4096. When the
average queue length reaches the minimum threshold, WRED
randomly drops some packets with the specified IP precedence.
max-threshold is the maximum average queue length, expressed
in number of packets. Valid values are from the value of the
min-threshold to 4096. When the average queue length exceeds
the maximum threshold, WRED drops all packets with the
specified IP precedence.
mark-prob-denominator is the denominator for the fraction of
packets dropped when the average queue depth is at the maximum
threshold. For example, if the denominator is 512, 1 out of every
512 packets is dropped when the average queue is at the maximum
threshold. Valid values are from 1 to 65536. The default is 10 (1
out of every 10 packets is dropped at the maximum threshold).
Configuration Example for Configuring a Class Policy and Dropping Packets Using WRED
Example 12-3 creates the class map named class1 and defines the match criteria used to determine if
packets belong to the class. The policy map named policy1 contains the class characteristics for class1.
Because the class1 configuration specifies the random-detect command, the policy map uses WRED
packet drop to drop packets. The service policy for policy1 is applied to the PVC range 1/32 to 1/81 for
outbound packets.
Example 12-3 Configuring a Class Policy and Dropping Packets Using WRED
Router(config-cmap)# match input-interface Ethernet0/1
Router(config-subif)# range pvc 1/32 1/81
Router(config-subif-range-vc)# service-policy output policy1
!
12-14
OL-7433-09
Chapter 12


To attach a service policy, perform any of the following configuration tasks:
Attaching a Service Policy to an Interface, Subinterface, or PVC, page 12-15
Attaching a Service Policy to a Virtual Access Interface, page 12-16
For more information, see Chapter 4, Attaching Service Policies.
Attaching a Service Policy to an Interface, Subinterface, or PVC

To attach a service policy to an interface, subinterface, or PVC, enter the following command in the
appropriate configuration mode:
Command
Purpose
Router(config-if)# service-policy [input | output]

policy-map-name
Attaches the policy map you specify to an interface.

packets.
packets.
policy-map-name is the name of the policy map whose QoS
policies you want to apply to the interface, subinterface, or
PVC.
Note
When you attach a service policy to an interface and

the policy map configuration enables CBWFQ, all
classes configured as part of the policy map are
installed in the fair queuing system.
Configuration Example for Attaching a Service Policy to an Interface

As shown in Example 12-4, you can attach the same policy map to multiple interfaces. Example 12-4
attaches the policy map named policy1 to the Ethernet 1/0/0 and serial 1/0/1 interfaces for outbound
packets. Each interface can have only one policy attached for inbound packets and one policy attached
for outbound packets.
Example 12-4 Attaching a Service Policy to an Interface
Router(config)# interface ethernet1/0/0
Router(config-if)# service-policy output policy1
Router(config-if)# interface serial1/0/1
Router(config-if)# exit

OL-7433-09
12-15
Chapter 12
Attaching a Service Policy to a Virtual Access Interface

To attach a service policy to a virtual access interface (VAI), see the Attaching Virtual Access Interface
QoS Service Policies section on page 4-23.
Note
To configure class-based WFQ (CBWFQ) for VAIs, you must specify the bandwidth command for the
traffic classes configured in the policy map and attach the policy map to either a VC or to a virtual
template interface (requires Cisco IOS Release 12.2(16)BX and later releases).
Modifying the Bandwidth for an Existing Policy Map Class

To change the amount of bandwidth allocated for an existing class, enter the following commands
Command
Purpose
Step 1
Specifies the name of the policy map containing the class you
want to modify. Enters policy-map configuration mode.
Step 2

Specifies the name of the class whose bandwidth you want to
modify. Enters policy-map class configuration mode.
Step 3
Specifies the changed amount of bandwidth (in kbps or as a

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.
bandwidth-kbps specifies the minimum bandwidth allocated
for a traffic class. Valid values are from 8 to 2,488,320, which
represents from 1 to 99 percent of the link bandwidth.
Note
The range of valid values for bandwidth-kbps might

be smaller than the values indicated above. Use the
question mark (?) in context-sensitive help to display
the range of valid values.
percent percentage specifies the minimum percentage of the

link bandwidth allocated for a class belonging to a policy
map. Valid values are from 1 to 99.
remaining percent percentage specifies the minimum
belonging to a policy map. Valid values are from 1 to 99
12-16
OL-7433-09
Chapter 12

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,
Step 1
Command
Purpose

configuration mode.
policy-map-name is the name of the policy map containing
the class you want to modify.
Step 2
Creates or modifies a traffic class in a policy map. Enters

class-map-name is the name of the class whose queue limit
you want to modify. This is the name of a previously
configured class map.
Step 3
number-of-packets
Specifies the maximum number of packets that the queue can

accumulate for this class.
number-of-packets is a number from 1 to 64. The default
number of queue entries is based on the bandwidth rate.
Note
When you specify the queue-limit command, the

router uses tail drop to drop packets.
Deleting Classes
To delete one or more classes from a policy map, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
policy-map-name

configuration mode.
policy-map-name is the name of the policy map containing the
classes you want to delete.
Step 2
Router(config-pmap)# no class
class-map-name
Deletes the class you specify.

class-map-name is the name of the traffic class you want to delete.
This is the name of a previously configured class map.

OL-7433-09
12-17
Chapter 12
Configuration Examples for Sharing Bandwidth Fairly
Deleting Policy Maps

To delete a policy map, enter the following command in global configuration mode:
Command
Purpose
Router(config)# no policy-map policy-map-name
Deletes the policy map you specify.


Configuration Example for Configuring CBWFQ and Attaching a Policy to an ATM Subinterface,
page 12-19
Configuration Example for Configuring CBWFQ and Attaching a Policy to an RBE Subinterface,
page 12-19
Configuration Example for Configuring CBWFQ and Attaching a Policy to an

Ethernet Interface
Example 12-5 shows how to configure CBWFQ in a policy map and attach the policy to an Ethernet
interface. The example configures a classification policy named voip and a policy map named policy1,
which defines the class characteristics for the voip, video, and class-default classes. The service policy
is attached to the Ethernet 1/0/1 interface in the outbound direction.
Example 12-5 Configuring CBWFQ and Attaching a Policy to an Ethernet Interface
Router(config)# class-map match-any voip
Router(config-cmap)# class-map match-any video
Router(config-pmap)# class voip
Router(config-pmap-c)# class video
Router(config-pmap-c)# class class-default
Router(config-pmap-c) bandwidth 2560
Router(config)# interface ethernet1/0/1
12-18
OL-7433-09
Chapter 12


ATM Subinterface
Example 12-6 shows how to configure CBWFQ in a policy map and attach the policy to an ATM
subinterface. This example creates a class map named voice to classify traffic and assigns class
characteristics in the policy map named policy1. The service policy is applied to the ATM
subinterface 7/0/0.1, which uses PPPoA encapsulation.
Example 12-6 Configuring CBWFQ and Attaching a Policy to a PPPoA Subinterface
Router(config-cmap)# match any
set-prec-transmit 4
Router(config)# interface atm7/0/0.1 point-to-point
Router(config-subif-atm-pvc)# encapsulation aal5mux ppp virtual-template 1
Router(config-subif-atm-pvc)# service-policy output policy1
Router(config-subif)# interface virtual-template 1
Router(config-if)# ip unnumbered loopback1
Router(config-if)# peer default ip address pool pool1

RBE Subinterface
Example 12-7 shows how to configure CBWFQ in a policy map and attach the policy to an routed bridge
encapsulation (RBE) subinterface. The example creates a class map named voice and a policy map
named map1. The service policy is applied to the ATM subinterface 7/0/1.1, which uses ATM RBE.
Example 12-7 Configuring CBWFQ and Attaching a Policy to an RBE Subinterface
Router(config-cmap)# match all
Router(config)# policy-map map1
Router(config-pmap-c)# police 120000 16000 32000 conform-action transmit exceed-action set
precedence-transmit 4
Router(config-if)# interface atm7/0/1.1 point-to-point
Router(config-subif)# ip unnumbered loopback1
Router(config-subif)# atm route-bridge ip
Router(config-subif)# service-policy output map1
Router(config-subif-atm-pvc)# encapsulation aal5snap

OL-7433-09
12-19
Chapter 12

To verify the configuration of service policy maps and the classes associated with them, enter the
following commands in privileged EXEC mode:
Command
Purpose

router.

map you specify.

class-map-name

traffic class for which you want to display the configuration.
class-map-name is the name of the class map that defines the
traffic class.

maps attached to the interface you specify.
interface is the type and number of the interface.
Note
After you enter the show policy-map interface

command, the counters that display update only if
congestion is present on the interface.
Displays queuing configuration information and statistics for the

interface you specify.
Router# show queue interface
Feature
Weighted fair queuing (WFQ)

Part 2: Congestion Management > Congestion Management Overview >
Weighted Fair Queuing
Class-based weighted fair queuing

(CBWFQ)

Part 2: Congestion Management > Congestion Management Overview >
12-20
OL-7433-09
Chapter 12

Feature
Class maps

Part 8: Modular Quality of Service Command Line Interface > Configuring
the Modular Quality of Service Command Line Interface > Modular QoS CLI
Policy maps


OL-7433-09
12-21
Chapter 12
12-22
OL-7433-09
CH A P T E R
13

In releases prior to Cisco IOS Release 12.0(22)S, you can specify QoS behavior at only one level. For
example, to shape two outbound queues of an interface, you must configure each queue separately,
defining only class-specific actions. You can define a minimum bandwidth for two traffic classes, but
you cannot define a combined maximum bandwidth for the two classes. As a result, you cannot configure
fair queues on virtual circuits where the total throughput of the fair queues must be within the virtual
circuits committed rate.
To implement fair queues on virtual circuits and virtual LANs (VLANs), the Cisco 10000 series router
supports QoS with hierarchical queuing. Within the hierarchical QoS framework, you can enable the
router to prioritize and manage packets at three policy levels (physical, logical, and class levels), thereby
providing a high degree of granularity in traffic management. Congestion control mechanisms such as
weighted random early detection (WRED) and tail drop regulate network traffic and control congestion.
This chapter describes the various types of hierarchical policies and includes the following topics:
Hierarchical Policies, page 13-2
Components Common to All Types of Hierarchical Policies, page 13-3
Types of Hierarchical Policies, page 13-6
Hierarchical Policies and Oversubscription, page 13-11
Applying Child Policies Under Priority Classes, page 13-12
Interfaces Supporting Hierarchical Policies, page 13-12
Guidelines for Configuring QoS for Multiple Queues, page 13-13
Configuring QoS for Multiple Queues, page 13-13
Verifying the Configuration of Hierarchical Policies, page 13-27

OL-7433-09
13-1
Chapter 13
A hierarchical policy is a QoS model that enables you to specify QoS behavior at multiple levels of
hierarchy. The router supports three types of hierarchical policies: nested, three-level, and input policing
policies. Depending on the type of hierarchical policy you configure, you can use hierarchical policies
to:
Note
Specify multiple policy maps to shape multiple queues together
Apply specific policy map actions on the aggregate traffic
Apply class-specific policy map actions
Restrict the maximum bandwidth of a virtual circuit (VC) while allowing policing and marking of
traffic classes within the VC
For more information about the types of hierarchical policies, see the Nested Hierarchical Policies
section on page 13-6, Three-Level Hierarchical Policies section on page 13-8, and the Hierarchical
Input Policing Policies section on page 13-10).
All hierarchical policy types consist of a top-level parent policy and one or more child policies. The
service-policy command is used to apply a policy to another policy, and a policy to an interface,
subinterface, virtual circuit (VC), or virtual LAN (VLAN). For example, in a three-level hierarchical
policy, you use the service-policy command to apply a:
Note
Bottom-level child policy to a middle-level child policy
Middle-level child policy to a top-level parent policy
Top-level parent policy to an interface, subinterface, VC, or VLAN
For more information, see the Child Policy section on page 13-4, the Parent Policy section on
page 13-4, and the service-policy Command section on page 13-5.
When you use hierarchical policies, the router allocates the physical pipe into smaller pipes. Instead of
creating a single versatile time management scheduler (VTMS) link for the physical interface, each
parent policy map has a VTMS link. The router uses this QoS link to service the associated traffic
independently of other traffic.
For releases prior to Cisco IOS Release 12.0(25)SX, the router uses 128 discrete values between 64 kbps
and 1 Gbps as multiqueue shape rates. Therefore, the sum of the nested policy shape rates you specify
for an interface must be 64 kbps less than the total bandwidth of the interface. For example, on a DS1
Frame Relay interface with a total bandwidth of 1536 kbps, the combined shape rate of the hierarchical
policy must be 1472 kbps or less:
1536 kbps 64 kbps = 1472 kbps
If you specify a non-supported rate, the router uses the next lower supported rate instead.
For Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, and later releases, the router allows interface
oversubscription. For more information, see Chapter 15, Oversubscribing Physical and Virtual Links.
13-2
OL-7433-09
Chapter 13

Feature History for Hierarchical Policies

Cisco IOS Release
Description
Required PRE
Release 12.0(22)S
The hierarchical policies feature was introduced on the

PRE1 and support two-level, nested hierarchical policies.
PRE1
Release 12.0(25)SX
This feature was enhanced on the PRE1 to support

three-level hierarchical policies.
PRE1
Release 12.2(16)BX
This feature was introduced on the PRE2 and supported

two-level, nested hierarchical policies.
PRE2
Release 12.3(7)XI
This feature was enhanced on the PRE2 to support

PRE2
Release 12.2(28)SB
This feature was integrated into Cisco IOS

PRE2
Release 12.2(28)SB for the PRE2 and enhanced to support
hierarchical input policing feature on the PRE2.
Release 12.2(31)SB2
This feature was introduced on the PRE3
PRE3
Benefits of Hierarchical Policies

Depending on the type of hierarchical QoS policy you configure, you can:
Shape multiple queues to a single rate
Divide a single class of traffic into one or more subclasses
Specify the maximum transmission rate of a set of traffic classes that are queued separately, which
is essential for virtual interfaces such as Frame Relay PVCs and IEEE 802.1Q virtual LANs
(VLANs)
Configure fair queues on virtual circuits
Shape the aggregate traffic of queues on a physical interface (for example, provide a 10-megabits
per second (Mbps) service on a 100-Mbps physical interface)
Restrict the maximum bandwidth of a VC while allowing policing and marking of classes within the
VC

All types of hierarchical policies use the following components to provide multiple levels of QoS
behavior:
Child Policy, page 13-4
Parent Policy, page 13-4

OL-7433-09
13-3
Chapter 13
Child Policy
A child policy is a policy map in a hierarchical QoS policy that defines QoS behavior for individual
streams of traffic. A child policy defines one or more classes of traffic and the actions you want the router
to take on the traffic, just as non-hierarchical policy maps do. However, in a hierarchical policy, a child
policy map is applied to a parent policy map and can be applied to another child policy, depending on
the type of hierarchical policy it is (see the Types of Hierarchical Policies section on page 13-6).
The following describes the ways in which you can apply child policies for the various types of
hierarchical policies:
Nested hierarchical policiesApply a bottom-level child policy to a top-level parent policy only.
Three-level hierarchical policiesApply a bottom-level child policy to a middle-level child policy;

and apply the middle-level child policy to the top-level parent policy.
Hierarchical input policing policiesApply a bottom-level child policy to a top-level parent policy.
When applying child policies to other child policies or to a parent policy, use the service-policy
command and specify the name of the child policy you are applying as the policy-map-name. Do not
specify the input or output keyword.
If you specify the bandwidth percent command or the police percent command in a child policy, the
percentage you indicate is the percentage of the total shape rate and not the percentage of the interface
bandwidth. The router uses the bandwidth of the nearest parent policy (configured using the shape or
police command) command to calculate the bandwidth percentage for the child policy. The router always
looks to the nearest parent for the bandwidth reference point.
The router executes the child policy and then the parent policy. However, if the child policy contains
policing with a specified drop policy, the router polices and drops the appropriate traffic at the child
level, but does not execute the parent policy on the dropped packets.
The router executes the child policy and then the parent policy. As the packets pass through the routers
forwarding engine, the router applies the QoS actions specified in the child policy. After child processing
completes, the packets are fed back through the forwarding engine and the router applies the parent
policy actions to the aggregate traffic. The router executes the parent policy only on the packets that are
fed back. If the router dropped some packets during child processing (the child policy contained a drop
policy), the router does not execute the parent policy on those dropped packets.
Parent Policy
A parent policy contains only the class-default class; it can contain no other classes. The parent policy
defines the shape rate (nested and three-level hierarchical policies) or the policing rate (hierarchical
input policing policies) for the aggregate traffic on an interface with a service policy applied.
The parent policy class-default class can contain only the following commands. Do not configure any
other commands in the class-default class. Configure the service-policy command last.
shape command(Nested or three-Level Hierarchical Policies) Specifies a single shape rate for all
of the traffic classes defined in the child policies. The router does not allocate unused (or excess)
bandwidth for other traffic. You must configure the shape command when creating nested
hierarchical policies and three-level hierarchical policies; do not configure the police command.
or
police command(Hierarchical Input Policing Policies) Configures traffic policing for the
aggregate traffic of all of the classes defined in the child policies. You must configure the police
command when creating hierarchical input policing policies; do not configure the shape command.
13-4
OL-7433-09
Chapter 13

Note
service-policy commandApplies a child policy to the parent policy to create a single hierarchical
QoS policy. Specify the name of the child policy map as the policy-map-name. Do not specify the
input or output keyword.
For more information about hierarchical policies, see the Types of Hierarchical Policies section on
page 13-6.
Table 13-1 summarizes the commands configured in the parent class-default class for the different types
of hierarchical policies.
Table 13-1
Hierarchical Parent Class-Default Class Commands
Type of Policy
shape Command
police Command
Nested Hierarchical
Yes
No
Yes
Three-Level Hierarchical
Yes
No
Yes
Hierarchical Input Policing
No
Yes
Yes
The router reserves the bandwidth you specify in the parent policy shape or police command for the
exclusive use of the PVC or VLANs to which the policy is applicable. The router does not share unused
bandwidth with other PVCs or VLANs. However, the actual shape rate the router applies to the child
traffic classes might differ from the rate you specify in the parent policy. For example, the router might
map a specified shape rate of 10.5 Mbps to 11 Mbps. Use the show policy-map interface command to
determine the actual shape rate applied.
For hierarchical policies, the service-policy command is used to attach:
Child policies to child policies
Child policies to parent policies
Parent policies to interfaces, subinterfaces, and virtual circuits
When attaching child policies to child or parent policies, do not specify the output or input keyword
when you enter the service-policy command. For example, enter the following command:
Router(config-if)# service-policy policy-map-name
When attaching parent policies to interfaces, subinterfaces, or virtual circuits, enter the service-policy
command and specify the output or input keyword as described below:
Note
Nested hierarchical policies and three-level hierarchical policiesSpecify the output keyword to
tell the router to apply the policy to outbound traffic. For more information, see the Nested
Hierarchical Policies section on page 13-6 and the Three-Level Hierarchical Policies section on
page 13-8.
Hierarchical input policing policiesSpecify the input keyword to apply the policy to inbound
traffic. For more information, see the Hierarchical Input Policing Policies section on page 13-10.
The router does not support nested and three-level hierarchical policies on inbound interfaces, and it
does not support hierarchical input policing on outbound interfaces.

OL-7433-09
13-5
Chapter 13
Types of Hierarchical Policies

The Cisco 10000 series router supports the following types of hierarchical policies:
Nested Hierarchical Policies, page 13-6

Defines up to two levels of hierarchy. A nested policy can define a minimum bandwidth for each
type of traffic on a virtual circuit and a maximum bandwidth for the virtual circuits total traffic.
However, a nested policy cannot actively police a subclass of each guaranteed class while placing a
maximum transmission limit on the aggregate traffic.
Three-Level Hierarchical Policies, page 13-8

Defines up to three levels of hierarchy. A three-level policy can define a minimum bandwidth for
each traffic type on a virtual circuit, define a maximum bandwidth for the virtual circuits total
traffic, police a subclass of each guaranteed class, and place a maximum transmission limit on the
aggregate traffic.
Hierarchical Input Policing Policies, page 13-10

Defines up to two levels of hierarchy for inbound traffic only. A hierarchical input policing policy
can define two levels of policing, one in the parent policy and one in the child policy. The top-level
parent policy is typically used to police an interface, subinterface, ATM VC, Frame Relay DLCI, or
802.1Q VLAN, and is applied to all traffic.
Nested Hierarchical Policies

A nested hierarchical policy is a queuing model that defines a minimum bandwidth for multiple classes
and specifies a combined maximum bandwidth for the classes. Using a nested hierarchical policy, you
can shape two or more queues together into one logical QoS policy. In this way, you can associate
multiple logical links with a physical interface and enable the router to service any group of queues
independently of other queues. The router provides distinct dequeuing rates to the subsets of the queues
on a physical link.
Figure 13-1 shows a sample queuing configuration on a T1 network interface that is running Frame
Relay. The network interface has two PVCs (PVC1 and PVC2), each with a multiqueue shape rate of
768 kbps. Each PVC has two fair queues whose aggregate output is shaped at 768 kbps.
Figure 13-1
Nested Hierarchical Policy on Frame Relay
T1
Fair Queue at 512 Kbps
126793
PVC2 shaped at 768 Kbps
PVC1 shaped at 768 Kbps
13-6
OL-7433-09
Chapter 13

Nested policy maps specify QoS policies at the following two levels of hierarchy:
Child policy (bottom-level)Identifies one or more classes of traffic and defines QoS behavior for
the individual traffic streams. If you specify a class bandwidth in a child policy as a percentage, the
router uses the top-level parent shape rate as the bandwidth reference (100 percent) rather than the
bandwidth of the network interface. For example, in a nested policy shaped at 2 Mbps with a
bottom-level child policy configured for 50 percent bandwidth, the router allocates 1 Mbps of
bandwidth to the child policy (50 percent of the parent shape rate).
Parent policy (top-level)Shapes the output of the traffic classes into a single shape rate. The parent
policy can contain only the class-default class with only the shape command specified.
For releases prior to Cisco IOS Release 12.0(25)SX, the sum of the nested policy shape rates you specify
can be no more than 64 kbps less than the physical interface bandwidth. For example, the sum of the
nested policy shape rates for a DS1 Frame Relay interface must be no more than 1472 kbps, calculated
as follows:
1536 kbps 64 kbps = 1472 kbps
If you specify a non-supported rate, the router uses the next lower supported rate instead.
Note
The above restriction does not apply to Cisco IOS Release 12.0(25)SX and later releases.
For releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, the router does not limit the
number of nested policies you can configure on a physical network interface as long as the sum of the
nested policy shape rates is 64 kbps less than the total bandwidth of the interface. In Cisco IOS Release
12.0(25)SX and Release 12.3(7)XI, and later releases, the router allows oversubscription. For more
information, see Chapter 15, Oversubscribing Physical and Virtual Links.
The router reserves the shape rate you specify in the parent policy for the child traffic classes. The router
does not allocate unused (or excess) bandwidth to other traffic. For example, consider a nested policy
with a shape rate of 64 kbps. If the nested policy traffic rate is 32 kbps, the router does not allocate the
remaining 32 kbps to the other traffic on the network interface.
In some cases, the nested policy shape rate that the system uses might be lower than the shape rate you
specify. Use the show policy-map interface command to verify the actual shape rate.
For Frame Relay PVCs, instead of using a nested policy map to specify the multiqueue shape rate, you
can use the frame-relay traffic-shape command to specify a fair queue policy map.
Restrictions and Limitations for Nested Hierarchical Policies

Note
This section lists restrictions for nested hierarchical policies. These restrictions might not apply to other
types of hierarchical policies.
Nested hierarchical policies can have no more than two levels of hierarchy.
Only the top-level parent policy can have the class-default class defined.
The parent class-default class can have only the shape command configured; you cannot specify any
other policy action. The class-default class can also have the service-policy command configured to
attach a child policy to the parent policy. You must specify the shape command before you specify
the service-policy command.
Queuing services must exist at a single hierarchy level, except for the shape command, which is
defined in the parent policys class-default class.

OL-7433-09
13-7
Chapter 13
You cannot apply a child policy to a traffic class that contains the set or police command.
For the PRE1, the router does not support DotP marking and 802.1P for nested hierarchical policies,
including matching and marking of the 802.1P header.
Three-Level Hierarchical Policies

A three-level hierarchical policy extends the functionality of a nested hierarchical policy from two to
three levels of hierarchy. Using three-level hierarchical policies, you can:
Define QoS policies at three levels of hierarchy
Define a single shaping rate for multiple classes and subclasses of IP traffic
Apply specific actions on the aggregate traffic of multiple classes and execute class-specific actions
Selectively police a subclass of each guaranteed class and place a maximum transmission limit on
the aggregate traffic
For example, you can use a three-level hierarchical policy to define a minimum bandwidth and a
combined maximum bandwidth for two classes. Similarly, you can also define a minimum bandwidth
for each type of traffic on a virtual circuit and a maximum bandwidth for the virtual circuits total traffic.
A three-level policy specifies the following three levels of hierarchy:
Child policy (bottom-level)Specifies marking and metering actions for one or more classes of
traffic using the set and police commands. You cannot apply a child policy to a traffic class that
contains the set or police command.
Child policy (middle-level)Defines class-based queuing actions for one or more classes of traffic.
You must configure all queuing actions (such as the bandwidth and priority commands) at a single
hierarchical level. The exception to this rule is the shape command, which is also configured in the
class-default class of a parent policy.
Parent policy (top-level)Defines the transmission capacity of a physical or virtual link to shape
the output of the traffic classes into a single shape rate. The shape rate you specify in the parent
policy is reserved for the traffic classes you specify in the child policies. The router does not allocate
unused (excess) bandwidth for other traffic.
Note
The actual shape rate the router applies to the child traffic classes might differ from the rate you
specify in the hierarchical policy. Use the show policy-map interface command to determine
the actual shape rate applied.
13-8
OL-7433-09
Chapter 13

Restrictions and Limitations for Three-Level Hierarchical Policies

Note
This section lists restrictions for three-level hierarchical policies. These restrictions might not apply to
other types of hierarchical policies.
A top-level parent policy can have only the class-default class. Do not configure any other traffic
class.
The parent class-default class can have only the shape and service-policy commands configured.
Specify the shape command first and then the service-policy command to apply a child policy to
the parent policy.
A middle-level child policy cannot have the police and set commands configured. If you use these
commands in a middle-level policy, you cannot apply a bottom-level child policy to it using the
A bottom-level child policy can have only the police and set commands configured for a class.
Each bottom-level class map must match only those packets that also match its parent class map. For
example, the union of the set of packets of a bottom-level class and that of its parent class must be
equal to the set of packets that match the parent class.
Note
If a policy does not adhere to the above restriction, the router might incorrectly classify the
traffic affected by the policy.
Example 13-1 shows a configuration that violates the requirement that the bottom-level class map match
only those packets that also match its parent class map. In the example, the class map named Child
matches any packet that is not IP precedence 1 (for example, IP precedence 5). The class map named
Parent matches only IP precedence 1, 2, and 3. As a result, no packets from the Child and Parent classes
intersect.
Example 13-1 Improperly Defining Bottom-Level Child and Top-Level Parent Class Maps
Router(config)# class-map Parent
Router(config-cmap)# math ip precedence 1 2 3
!
Router(config)# class-map Child
Router(config-cmap)# match not ip precedence 1
Example 13-2 modifies the configuration in Example 13-1 to ensure the union of Child and Parent
packets, which in Example 13-2 is IP precedence 2 and 3.
Example 13-2 Properly Defining Bottom-Level Child and Top-Level Parent Class Maps
Router(config)# class-map Parent
Router(config-cmap)# math ip precedence 1 2 3
!
Router(config)# class-map Child
Router(config-cmap)# match ip precedence 2 3

OL-7433-09
13-9
Chapter 13
Hierarchical Input Policing Policies

A hierarchical input policing policy extends the functionality of traffic policing to two levels of
hierarchy for inbound interfaces. The hierarchical input policer limits the rate of the traffic that the router
accepts on the interface with the service policy applied. In this way, the service provider network is
protected on the aggregate traffic level to ensure that the service provider can honor service level
agreements. A two-rate three-color policer limits the rate of individual traffic streams (see the Two-Rate
Three-Color Marker for Traffic Policing section on page 6-8).
Using hierarchical input policing, you can:
Specify policing actions at two levels of hierarchy
Define a policing rate for the traffic that the router accepts on an inbound interface (with a service
policy applied)
Define a policing rate for individual traffic streams
A hierarchical input policing policy specifies the following two levels of hierarchy:
Child policy (bottom-level)Specifies policing actions for individual IP traffic streams by using a
two-rate three-color policer (see the Two-Rate Three-Color Marker for Traffic Policing section on
page 6-8).
Parent policy (top-level)Defines a policing rate for all inbound traffic on the interface,
subinterface, VC, or VLAN on which the service policy is applied.
During hierarchical input policing, the bottom-level policer acts on all of the traffic arriving at the
interface, subinterface, VC, or VLAN on which the hierarchical policer is applied. As the traffic passes
through the forwarding engine of the router for the first time, the bottom-level policer limits the rate of
the individual streams of IP traffic before passing the traffic back through the forwarding engine again.
During this feedback operation, the top-level traffic policer limits the rate of all of the traffic passed to
it. The top-level policer acts only on the packets sent by the bottom-level policer. If the outbound
interface has policing configured, a second feedback occurs during which the outbound policer limits
the rate of the traffic.
Note
Packets dropped during bottom-level child processing are not passed to the top-level parent policer.
Figure 13-2 shows how packets flow between policy maps in a hierarchical input policing policy. In the
figure, 500 packets arrive at the interface with the policy_map_level1 policy attached. Because of the
way in which the policer is configured in policy_map_level1, the policer drops 100 packets and passes
400 packets. The traffic policer in the policy_map_level2 policy then evaluates the 400 packets it
receives, drops 200, and transmits the remaining 200 packets.
13-10
OL-7433-09
Chapter 13

Figure 13-2
Packet Flow Between Hierarchical Input Policing Policies
500 packets received

at the interface
100 packets dropped Bottom-level child policy map:

policy_map_level2
200 packets dropped
126794
Top-level parent policy map: 400 packets transmitted

policy_map_level1
200 packets exit

the interface
Restrictions and Limitations for Hierarchical Input Policing Policies
Packet classification for the bottom-level child policy map occurs before the top-level policer acts
on the traffic classes.
Traffic policing at the top-level parent does not guarantee fairness in sharing bandwidth among the
child classes. If packets from two different traffic classes arrive at the same rate and then go through
a traffic policer, the output rates of the two classes might be different because the hierarchical input
policer acts as an aggregate policer. The parent policer might drop packets in one class in favor of
the other class. This situation can happen when the top-level policer has enough tokens when the
packets for one class arrive, but does not have enough tokens left for the other class. Based on the
arrival pattern of the packets, this pattern could continue indefinitely.

For releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, the router does not allow
oversubscription of interfaces. If you oversubscribe hierarchical policies, instead of reducing the shape
rate of all policies, the router preserves as many policies as possible and reduces the policy shape rates
of a minimum number of policies to bring the sum of the hierarchical policy shape rates to less than the
physical interface bandwidth.
For Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI and later releases, the router allows you to
oversubscribe interfaces. Oversubscription is always enabled.
For more information about oversubscription, see Chapter 15, Oversubscribing Physical and Virtual
Links.

OL-7433-09
13-11
Chapter 13

The Cisco 10000 series router allows you to apply a child policy with non-queuing features under a
priority class in Cisco IOS Release 12.2(31)SB2 and later releases. In a three-level hierarchical policy,
the priority class to which you attach the child policy must be in the middle-level policy. In a two-level
hierarchical policy (nested policy), the priority class to which you attach the child policy is in the parent
policy.
For more information, see the Child Service Policy Allowed Under Priority Class feature module for
Cisco IOS Release 12.2(31)SB2.
Interfaces Supporting Hierarchical Policies

The following describes interface support for hierarchical policies using the service-policy command:
Interfaces Supporting Hierarchical Policies (Outbound Only)
Note
Physical
subinterfaces
Ethernet VLANs
The router only supports nested and three-level hierarchical policies on outbound interfaces.
Interfaces Supporting Hierarchical Policies (Inbound only)
Note
Physical
Label-controlled (LC)-ATM subinterfaces
Ethernet VLANs
The router only supports hierarchical input policing policies on inbound interfaces.
Interfaces Not Supporting Hierarchical Policies
IP tunnel
13-12
OL-7433-09
Chapter 13


When configuring QoS for multiple queues, consider the following guidelines:
Define child policies before you define the parent policy. For example, for a nested policy, define
the bottom-level policy and then the top-level parent policy. For a three-level policy, define the
bottom-level policy, the middle-level policy, and then the top-level parent policy.
Do not specify the input or output keyword in the service-policy command when configuring a
child policy within another child policy or within a parent policy.
Do not configure a child policy in a traffic class of a bottom-level policy. Configure child policies
only in middle-level and top-level parent policies.
Configuring QoS for Multiple Queues

To configure QoS for multiple queues using a hierarchical policy, perform the following configuration
tasks:
Creating Fair Queues at Two Levels of Hierarchy, page 13-13
Creating Fair Queues at Three Levels of Hierarchy, page 13-15
Policing Inbound Traffic at Two Levels of Hierarchy, page 13-19
Policing Inbound Traffic at Two Levels of Hierarchy, page 13-19
Creating Fair Queues at Two Levels of Hierarchy

To create fair queues at two levels of hierarchy, enter the following commands beginning in global
configuration mode:
Note
Step 1
Use the following commands to configure both the child and parent policies. Configure the bottom-level
child policy first and then the top-level parent policy. For information about additional actions you can
specify in child policies, see the Types of QoS Actions section on page 3-4.
Command
Purpose
policy-map-name
Creates or modifies the bottom-level child policy.

policy-map-name is the name of the child policy map. The name
can be a maximum of 40 alphanumeric characters.
Step 2

OL-7433-09
13-13
Chapter 13
Step 3
Command
Purpose
(Optional) Enables class-based fair queuing.

link bandwidth.
Step 4
Step 5
Router(config-pmap)# policy-map
policy-map-name
Creates or modifies the top-level parent policy.

policy-map-name is the name of the parent policy map. The name
Step 6

Note
Step 7
Router(config-pmap-c)# shape kbps-value
You can configure only the class-default class in a parent

policy. Do not configure any other traffic class.
Shapes traffic to the indicated bit rate.

kbps-value is the bit-rate (in kilobits per second) used to shape the
traffic.
Step 8
policy-map-name
Applies a bottom-level child policy to the top-level parent

class-default class.
policy-map-name is the name of the previously configured child
policy map.
Example 13-3 shows how to create a nested hierarchical policy that creates two fair queues: one queue
for the Bronze traffic and one queue for all other traffic. The top-level policy named Top-Parent shapes
the total output rate of both queues to 1 Mbps. The bottom-level policy named Bottom-Child shapes
Bronze traffic to 50 percent of the total output rate, or 500 kbps. The router allocates the remaining
500 kbps to all other traffic.
Example 13-3 Creating Fair Queues at Two Levels of Hierarchy
Router(config)# policy-map Bottom-Child
Router(config-pmap)# policy-map Top-Parent
Router(config-pmap-c)# service-policy Bottom-Child
13-14
OL-7433-09
Chapter 13

Creating Fair Queues at Three Levels of Hierarchy

To create fair queues at three levels of hierarchy, perform the following required configuration tasks:
Configuring a Bottom-Level Child Policy of a Three-Level Hierarchy, page 13-15
Configuring a Middle-Level Child Policy of a Three-Level Hierarchy, page 13-16
Configuring the Top-Level Parent Policy of a Three-Level Hierarchy, page 13-18
Configuring a Bottom-Level Child Policy of a Three-Level Hierarchy

To configure the bottom-level child policy, enter the following commands beginning in global
configuration mode:
Note
Step 1
The bottom-level child policy of a three-level hierarchical policy typically contains only metering or
marking actions. Therefore, configure only the police and set commands in the bottom-level policy.
Command
Purpose
policy-map-name

policy-map-name is the name of the policy map. The name can be
Step 2
Step 3
Step 4
Step 5

[burst-normal] [burst-excess]
conform-action {action} exceed-action
{action} [violate-action {action}]
(Optional) Configures kilobits per second-based traffic policing.
Router(config-pmap-c)# police [cir]

percent percent bc normal-burst-in-msec
[pir pir] be excess-burst-in-msec
conform-action {action}
exceed-action {action} [violate-action
{action}]
(Optional) Configures percent-based traffic policing.
Router(config-pmap-c)# set action
(Optional) Configures traffic marking.

For information about traffic policing actions, see Table 6-1 on
page 6-3.
For a description of the traffic marking actions you can configure,

see Table 13-2 on page 13-15.
Table 13-2 describes the traffic marking actions you can configure using the set command.
Table 13-2
Traffic Marking Actions
Action
Description
atm-clp
Sets the ATM cell loss priority (CLP) bit to 1.
cos
Sets the IEEE 802.1P class of service bits in the user priority field.

OL-7433-09
13-15
Chapter 13
Table 13-2
Traffic Marking Actions (continued)
Action
Description
discard-class
Marks a packet with the discard-class value that you specify, indicating the
drop eligibility of a packet.
dscp
Marks a packet with the differentiated services code point (DSCP) you
specify.
mpls experimental
imposition
Sets the value of the MPLS experimental (EXP) field on all imposed label
entries.
ip precedence
Marks a packet with the IP precedence level you specify.
qos-group
Marks a packet with the QoS group identifier you specify.
Example 13-4 shows how to configure the bottom-level child policy of a three-level hierarchy.
Remember, the bottom-level policy typically defines marking and metering actions. In this example, the
policy map named Gold-Meter defines the policing rate and actions for Business class traffic; the policy
map named Default-Meter defines the default policing rate and actions.
Example 13-4 Configuring a Bottom-Level Child Policy of a Three-Level Hierarchy
Router(config)# policy-map Gold-Meter
set-prec-transmit 1
Router(config-pmap)# policy-map Default-Meter
set-prec-transmit 4
Router(config-pmap)#
Configuring a Middle-Level Child Policy of a Three-Level Hierarchy

To configure a middle-level child policy, enter the following commands beginning in global
configuration mode:
Note
Step 1
For information about additional actions you can specify in child policies, see the Types of QoS
Command
Purpose
policy-map-name
Creates or modifies a middle-level child policy map.

Step 2
13-16
OL-7433-09
Chapter 13

Step 3
Command
Purpose
(Optional) Assigns strict priority to the traffic class.

Note
Step 4
For Cisco IOS Release 12.0(25)S and Release 12.3(7)XI,

and later releases, the priority command has no
arguments. To specify a bandwidth rate, use the police
command (see Chapter 6, Policing Traffic).
(Optional) Specifies the bandwidth allocated for a traffic class.
Step 5
dscp-based
(Optional) Enables DSCP-based WRED.
Step 6
Router(config-pmap-c)# random-detect dscp

dscpvalue min-threshold max-threshold
[mark-probability-denominator]
(Optional) Specifies a packet drop policy based on the DSCP

value you specify.
Note
Do not enter the bandwidth command if you configure

the priority command.
For more information, see Chapter 11, Managing Packet Queue

Congestion.
Step 7
policy-map-name
Applies the bottom-level child policy map to the traffic class. Do

not specify an input or output keyword.
bottom-level child policy map.
Example 13-5 shows how to configure a middle-level child policy using the bottom-level child policy
configured in Example 13-4. In this middle-level policy, the policy map named Southwest defines three
traffic classes: Premium, Gold, and class-default. The configuration of these classes provides the
following QoS behavior:
Premium Traffic
Gives priority service to Premium traffic
Limits Premium packets to 50 percent of the total transmission capacity
Gold Traffic
Uses the Gold-Meter policy to police all Gold traffic (see Example 13-4 on page 13-16)
Guarantees Gold packets a minimum of 15,000 kbps of transmission capacity
Marks any traffic that exceeds 15,000 kbps with IP precedence 1 and then transmits the packet
During congestion, discards Gold packets with IP precedence level 2 or 3 before discarding other
packets
Default Traffic
Uses the Default-Meter policy to police default traffic (see Example 13-4 on page 13-16)
Guarantees default traffic a minimum of 10 percent of the total transmission capacity
Marks any traffic that exceeds 10 percent with IP precedence 4 and then transmits the packet
During congestion, discards default packets with IP precedence level 1 before discarding other
packets

OL-7433-09
13-17
Chapter 13
Example 13-5 Configuring a Middle-Level Child Policy of a Three-Level Hierarchy

Router(config-pmap)# policy-map Southwest
Router(config-pmap-c)# random-detect precedence 2 3
Router(config-pmap-c)# service-policy Gold-Meter
Router(config-pmap-c)# random-detect precedence 1
Router(config-pmap-c)# service-policy Default-Meter
Router(config-pmap)#
Configuring the Top-Level Parent Policy of a Three-Level Hierarchy

To configure a top-level parent policy, enter the following commands beginning in global configuration
mode:
Note
Step 1
In a top-level parent policy, define only the class-default class and specify the shape command and then
the service-policy command in the class configuration. Do not specify any other commands.
Command
Purpose
policy-map-name
Creates or modifies a top-level parent policy map.

Step 2
Configures or modifies the class-default class.
Step 3

kbps-value is the bit-rate (in kilobits per second) used to shape the
traffic.
Step 4
policy-map-name
Applies the middle-level child policy map to the parent

class-default class. Do not specify an input or output keyword.
middle-level child policy map.
13-18
OL-7433-09
Chapter 13

Example 13-6 shows how to configure a top-level parent policy using the middle-level child policy
configured in Example 13-5. In this top-level policy, the shape command indicates a total transmission
capacity of 64,000 kbps for the combined queues. The service-policy command applies the middle-level
policy named Southwest to the parent class-default class.
Example 13-6 Configuring a Top-Level Parent Policy of a Three-Level Hierarchy
Router(config-pmap)# policy-map Region1
Router(config-pmap-c)# service-policy Southwest
Router(config)#
Policing Inbound Traffic at Two Levels of Hierarchy

To police the traffic the router accepts on an inbound interface with a service policy applied, enter the
Note
Step 1
Use the following commands to configure both the child and parent policies. Configure the bottom-level
child policy first and then the top-level parent policy. For information about additional actions you can
specify, see the Types of QoS Actions section on page 3-4.
Command
Purpose
policy-map-name
Creates or modifies a bottom-level child policy map.

Step 2

OL-7433-09
13-19
Chapter 13
Step 3
Command
Purpose

[bc conform-burst] [pir pir] [be
peak-burst] [conform-action action
[exceed-action action [violate-action
action]]]
Configures traffic policing using two rates, the committed

information rate (CIR) and the peak information rate (PIR).
cir is the committed information rate (CIR) and indicates an
average rate at which the policer meters traffic.
cir specifies the CIR value in bits per second. Valid values are
from 8000 to 2,488,320,000.
(Optional) bc conform-burst is conform burst (bc) size used by
the first token bucket for policing. The conform-burst specifies
the bc value in bytes. Valid values are from 1 to 51200,000.
pir pir is the peak information rate (PIR) at which the second
token bucket is updated. The pir specifies the PIR value in bits per
second. Valid values are from 8000 to 2,488,320,000.
(Optional) be peak-burst is the peak burst (be) size used by the
second token bucket for policing. The peak-burst specifies the
peak burst (be) size in bytes. The size varies according to the
interface in use. Valid values are from 0 to 1,024,000,000.
conform-action {action} is the action to take on packets that
conform to the CIR and PIR. The default action is transmit.
exceed-action {action} is the action to take on packets that
conform to the PIR but not the CIR. The default action is drop.
(Optional) violate-action {action} is the action to take on packets
that exceed the PIR. The default action is the same as the
exceed-action.
{action} is the action to take on packets. See Table 6-1 on
page 6-3 for a description of each action.
Step 4
Step 5
policy-map-name
Creates or modifies a top-level parent policy map.

Step 6
Configures or modifies the default traffic class.
Step 7

[bc conform-burst] [pir pir] [be
peak-burst] [conform-action action
[exceed-action action [violate-action
action]]]
Configures traffic policing using two rates, the committed

information rate (CIR) and the peak information rate (PIR).
policy-map-name
Applies the bottom-level child policy map to the parent

class-default class. Do not specify an input or output keyword.
Step 8

{action} is the action to take on packets. See Table 6-1 on
page 6-3 for a description of each action.

bottom-level child policy map.
13-20
OL-7433-09
Chapter 13

Example 13-7 shows how to configure a hierarchical input policing policy to police the traffic that enters
the router on a specific interface. In the example, the two class maps named class-default and Gold define
the criteria the router uses to classify traffic. The bottom-level child policy map named Business defines
the policing actions for traffic classified as Gold; the top-level parent policy map named All_Traffic
defines the policing actions for default traffic. The Business policy map is applied to the All_Traffic
policy, creating a two-level hierarchical input policing policy.
Example 13-7 Policing Inbound Traffic at Two Levels of Hierarchy
Router(config)# class-map class-default
Router(config-cmap)# match any
Router(config-cmap)# class-map Gold
Router(config-pmap-c)# police 20000 200 pir 40000 300 conform-action set-qos-transmit 80
exceed-action set-qos-transmit 35 violate-action drop
Router(config-pmap)# policy-map All_Traffic
Router(config-pmap-c)# police 6400 200 pir 12800 400 conform-action transmit exceed-action
transmit violate-action drop
Router(config-pmap-c)# service-policy Business
Attaching Hierarchical Policies to Physical and Virtual Links

To attach hierarchical policies to interfaces, subinterfaces, virtual circuits, and virtual LANs, enter the
following command:
Command
Purpose
service-policy {input | output} policy-map-name
Attaches the policy map you specify.

input indicates to apply the QoS policy to inbound packets. You
must specify the input keyword for hierarchical input policing
policies.
output indicates to apply the QoS policy to outbound packets. You
must specify the output keyword for nested policies and
policy-map-name is the name of a previously configured top-level
parent policy map.

OL-7433-09
13-21
Chapter 13
Configuration Examples for Nested Hierarchical Policies, page 13-22
Configuration Examples for Three-Level Hierarchical Policies, page 13-23
Configuration Example for Hierarchical Input Policing, page 13-25
Configuring Bandwidth-Remaining Ratios on ATM Subinterfaces: Example, page 13-26
Configuring Bandwidth-Remaining Ratios on Class Queues: Example, page 13-26
Configuration Examples for Nested Hierarchical Policies

Example 13-8 shows how to configure a nested hierarchical policy. This example configuration includes
the following:
A bottom-level Child-Policy that defines two traffic classes: NewUsers and Bronze-Users.
A top-level Parent-Policy that defines the class-default class, which is shaped to a rate of 512 kbps.
The Child-Policy is applied to the class-default class.
The Parent-Policy is attached to ATM interface 1/0/0 in the outbound direction.
Example 13-8 Configuring a Two-Level Hierarchical Policy

Router(config)# policy-map Child-Policy [Defines bottom-level child policy.]
Router(config-pmap)# class NewUsers
drop
Router(config-pmap-c)# class Bronze-Users
Router(config-pmap-c)# random-detect dscp 8 24 40
Router(config-pmap)# policy-map Parent-Policy [Defines top-level parent policy.]
Router(config-pmap-c)# service-policy Child-Policy [Applies child to top-level parent.]
Router(config-if)# service-policy output Parent-Policy [Applies parent to the interface.]
Example 13-9 shows how to configure another nested hierarchical policy. In the example, the
bottom-level child policy named Bottom consists of two traffic classes named Group1 and Group2. The
traffic matching Group1 has a minimum bandwidth guarantee of 5000 kbps; Group2 has a minimum
bandwidth guarantee of 2000 kbps and also has a DSCP-based weighted random early detection
(WRED) packet drop policy defined. The bottom-level child policy is applied to the class-default class
in the top-level Parent policy map. The router shapes the aggregate of all of the Group1 and Group2
traffic to 8000 kbps as specified by the shape command in the Parent class-default class. The
hierarchical policy is attached to outbound ATM interface 1/0/0 using the service-policy command.
13-22
OL-7433-09
Chapter 13

Example 13-9 Configuring a Nested Hierarchical Policy at Two Levels of Hierarchy

Router(config)# policy-map Bottom [Defines bottom-level child policy.]
Router(config-pmap)# bandwidth 2000
Router(config-pmap-c)# random-detect dscp 40 10 20 10
Router(config-pmap)# policy-map Parent [Defines top-level parent policy.]
Router(config-pmap-c)# service-policy Bottom [Applies bottom-level child policy.]
Router(config-if)# service-policy output Parent [Applies top-level parent policy.]
Configuration Examples for Three-Level Hierarchical Policies

Example 13-10 shows how to configure a three-level hierarchical policy. This example configuration
includes the following:
A bottom-level child policy contains two policy maps named DefaultMeter and BusinessMeter.
These policy maps define marking and policing for the associated traffic classes.
A Middle-Level policy defines queuing services for the classes. In the Middle-Level policy map, the
bottom-level BusinessMeter policy is applied to the Business class and the bottom-level
DefaultMeter policy is applied to the Non-Business class.
The Middle-Level policy is applied to the class-default class in the parent policy map named
Top-Level, which shapes the traffic to 8000 kbps.
The hierarchical policy is attached to PVC 1/32 on the point-to-point ATM subinterface 1/0/0.1 in
the outbound direction.
Example 13-10 Configuring a Three-Level Hierarchical Policy

Router(config)# policy-map DefaultMeter [Defines bottom-level child policy.]
Router(config-pmap)# policy-map BusinessMeter [Defines bottom-level child.]
Router(config-pmap-c)# class Group2
Router(config-pmap)# policy-map Middle-Level [Defines middle-level child policy.]
Router(config-pmap-c)# class Business
Router(config-pmap-c)# service-policy BusinessMeter [Applies bottom-level child policy.]
Router(config-pmap-c)# class Non-Business
Router(config-pmap-c)# service-policy DefaultMeter [Applies bottom-level child policy.]
Router(config-pmap)# policy-map Top-Level [Defines top-level parent policy.]

OL-7433-09
13-23
Chapter 13
Router(config-pmap-c)# service-policy Middle-Level [Applies middle-level child to parent.]

Router(config-subif-atm-vc)# service-policy output Top-Level [Attaches parent to PVC.]
Example 13-11 shows how to configure another three-level hierarchical policy. This example
configuration includes the following:
Bottom-level child policies named Business-Meter and Default-Meter that define a policing rate.
A middle-level child policy named Middle-Level that does the following:

Gives priority service to Premium traffic and limits Premium traffic to 8000 bps.
Defines a Business class with a DSCP-based packet drop policy. The bottom-level child policy
named Business-Meter is applied to the Business traffic. The Business-Meter policy indicates
to police traffic at 40 percent of available bandwidth, mark traffic that exceeds 40 percent with
DSCP 40, and during congestion, discard Business class traffic marked with DSCP 40 (the
traffic that exceeds the policing rate) before it discards Business traffic at or below the policing
rate.
Defines a Non-Essential class with a DSCP-based traffic drop policy. Notice that the
bottom-level child policy named Default-Meter is applied to the Non-Essential traffic. The
Default-Meter indicates to police traffic at 10 percent of the available bandwidth, mark
exceeding traffic with DSCP 20, and during congestion, discard Non-Essential traffic marked
with DSCP 20 (the traffic that exceeds the policing rate) before it discards Non-Essential traffic
at or below the policing rate.
A top-level parent policy named Region1 that contains the class-default class, shapes the total
bandwidth rate to 20 kbps. Notice that the Southwest policy is applied to the class-default class,
which enables the router to shape the aggregate of all of the traffic to the shape rate defined in the
Region1 class-default class, in this case 20 kbps.
The three-level hierarchical policy attaches to the point-to-point serial subinterface 5/0/0.1 in the
outbound direction.
Example 13-11 Configuring a QoS Policy at Three Levels of Hierarchy

Router(config)# policy-map Business-Meter [Defines bottom-level child policy.]
Router(config-pmap)# class non-SAA
set-dscp-transmit 40
Router(config)# policy-map Default-Meter [Defines another bottom-level child policy.]
Router(config-pmap)# class non-SAA
set-dscp transmit 20
Router(config-pmap)# policy-map Southwest [Defines middle-level child policy.]
13-24
OL-7433-09
Chapter 13


Router(config-pmap-c)# service-policy Business-Meter [Applies bottom-level child policy.]
Router(config-pmap)# class Non-Essential
Router(config-pmap-c)# service-policy Default-Meter [Applies bottom-level child policy.]
Router(config)# policy-map Region1 [Defines top-level parent policy.]
Router(config-pmap-c)# service-policy Southwest [Applies middle-level child policy.]
Router(config-subif)# ip address 10.1.0.2 255.255.255.252
Router(config-subif)# service-policy output Region1 [Applies top-level parent.]
Configuration Example for Hierarchical Input Policing

Example 13-12 shows how to configure a hierarchical input policing policy to limit the rate of traffic that
the router accepts on an inbound interface. This example configuration includes the following
Class maps named class-default and Click that define the classification criteria the router uses to
classify packets.
A bottom-level child policy map named Policy2 that defines a two-rate three-color policer for the
Click traffic class.
A top-level parent policy named Parentbps1 that contains the class-default class, which defines a
two-rate three-color policer for default traffic. The bottom-level child policy named Policy2 is
applied to the Parentbps1 class-default class.
The top-level parent policy is attached to PVC 101/102 on the ATM point-to-point
Example 13-12 Configuring Hierarchical Input Policing

Router(config)# class-map match-any class-default [Defines classification criterion.]
Router(config-cmap)# class-map Click [Defines classification criterion.]
Router(config)# policy-map Policy2 [Defines bottom-level child policy.]
Router(config-pmap)# class Click
Router(config-pmap-c)# police 200000 2000 pir 400000 3000 conform-action set-dscp-transmit
59 exceed-action set-dscp-transmit 60 violate-action drop [Configures two-rate policer.]
Router(config-pmap)# policy-map Parentbps1 [Defines top-level parent policy.]
Router(config-pmap-c)# police 128000 2000 pir 256000 4000 conform-action transmit
exceed-action transmit violate-action drop [Configures two-rate three-color policer.]
Router(config-pmap-c)# service-policy Policy2 [Applies bottom-level child to parent.]
Router(config-subif-atm-vc)# service-policy input Parentbps1 [Attaches parent to PVC.]

OL-7433-09
13-25
Chapter 13
Configuring Bandwidth-Remaining Ratios on ATM Subinterfaces: Example

on the interface.
policy-map Child
class precedence_0
bandwidth 100
class precedence_1
bandwidth 10000
!
policy-map Parent
class class-default
!
ip address 10.20.1.1 255.255.255.0
pvc 0/200
vbr-nrt 50000
Note
For information on bandwidth-remaining ratios, see Distribution of Remaining Bandwidth Using
Ratio section on page 5-14 or the Distribution of Remaining Bandwidth Using Ratio,
Release 12.2(31)SB2 feature module.
Configuring Bandwidth-Remaining Ratios on Class Queues: Example

class precedence_0
class precedence_1
13-26
OL-7433-09
Chapter 13

class precedence_2
!
class class-default
!
class class-default
!
!
!
For information on bandwidth-remaining ratios, see Distribution of Remaining Bandwidth Using

Ratio section on page 5-14 or the Distribution of Remaining Bandwidth Using Ratio,
Release 12.2(31)SB2 feature module.

To verify hierarchical policies, enter any of the following commands in privileged EXEC mode:
Command
Purpose
Router# show class-map
Displays the configuration of all class maps configured on the

router.

router.


OL-7433-09
13-27
Chapter 13
Command
Purpose

[input | output]
Displays the configuration of all classes configured for all inbound

or outbound policy maps attached to the specified interface.
interface is the name of the interface or subinterface for the policy
policy.
output indicates to display the statistics for the attached outbound
policy.
Note

you specify.

map you specify.
policy-map-name is the name of the policy map for the
configuration information you want to display.

class-name

class-name is the name of the class for the configuration you want
Router# show running-config interface interface
Displays the configuration of the interface you specify that is

currently configured in the running-config file, including any
service policies attached to the interface.
13-28
OL-7433-09
Chapter 13

Verification Examples for Hierarchical Policies

Example 13-13 shows sample output from the show class-map, show policy-map, show policy-map
interface, and show running-config interface commands for the hierarchical input policing policy
configured in Example 13-12.
Example 13-13 Verifying a Hierarchical Input Policing Policy
Class Map match-any class-default (id 0)
Match any
Class Map match-any click (id 3)
Match ip precedence 2
Policy Map policy2
Class click
police 200000 2000 pir 400000 3000 conform-action set-dscp-transmit 59 exceed-action
set-dscp-transmit 60 violate-action drop
Policy Map parentbps1
Class class-default
police 128000 2000 pir 256000 4000 conform-action transmit exceed-action transmit
violate-action drop
service-policy policy2
ATM5/0/0.1
Service-policy input: Parentbps1
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
Police:
128000 bps, 2000 limit, 256000 pir, 4000 extended limit
exceeded 6871 packets, 961940 bytes; action: transmit
Service-policy : policy2
Class-map: click (match-any)
5 minute rate 0 bps
Police:
200000 bps, 2000 limit, 400000 pir, 3000 extended limit
conformed 10727 packets, 1501780 bytes; action: set-dscp-transmit 59
exceeded 5353 packets, 749420 bytes; action: set-dscp-transmit 60

OL-7433-09
13-29
Chapter 13

0 packets, 0 bytes
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
Router# show running-config interface atm 5/0/0.1
Building configuration...
Current configuration : 173 bytes
!
ip address 1.1.1.2 255.255.255.0
pvc 0/100
vbr-nrt 3000 2000 10
!
service-policy input Parentbps1
end
Router#
Feature
Class maps

Release 12.2
Interface > Modular QoS CLI Configuration Task List >
Creating a Traffic Class
Release 12.2
access-list rate-limit fair-queue (WFQ) > class-map command
Oversubscription

Policing
Comparing Traffic Policing and Traffic Shaping for Bandwidth

Limiting tech note
Release 12.2
Release 12.2
Quality of Service Overview > Policing and Shaping
13-30
OL-7433-09
Chapter 13

Feature
Policy maps

Release 12.2
Interface > Modular QoS CLI Configuration Task List >
Creating a Traffic Policy
Release 12.2
policy map - qos preclassify > policy map command
Three level scheduler
Three-Level Scheduler Using MQC Hierarchical Queuing

Framework, Release 12.2(31)SB2 feature module
Two-rate three-color policer
Two-Rate Policer, Release 12.2(4)T3 feature module

RFC 2698A Two Rate Three Color Marker, J. Heinanen,
T. Finland, G. Guerin, September 1999

OL-7433-09
13-31
Chapter 13
13-32
OL-7433-09
CH A P T E R
14

Simultaneous policy maps provide multiple levels of QoS hierarchy that can shape traffic at different
points of congestion in the Layer 2 network.
This chapter describes simultaneous policy maps on the Cisco 10000 series router and consists of the
following topics:
Simultaneous QoS Policy Map on an Interface and PPP Session, page 14-1
Restrictions for Simultaneous Policy Maps, page 14-4
Configuring Simultaneous Policy Maps, page 14-5
Configuration Examples for Simultaneous Policy Maps, page 14-14
Verifying Simultaneous Policy Maps, page 14-18
Verification Examples for Traffic Policing, page 14-19
Simultaneous QoS Policy Map on an Interface and PPP Session

The Simultaneous QoS Policy Map on Interface and PPP SessionA-DSLAM Case feature allows the
broadband aggregation system (BRAS) to provide multiple levels of QoS hierarchy that shape traffic at
different points of congestion in the Layer 2 network. This enables the BRAS to avoid congestion in
downstream links within the network.The BRAS prioritizes the traffic based on the subscribers
contracted bandwidth and subscribed services.
Using simultaneous policy maps, you can apply QoS at the session level and at the Ethernet subinterface
or PVC level for a single ATM PVC with two or more PPPoE sessions. At the session level, you can
configure the BRAS to mark any traffic above a specified rate with a particular designation. When the
traffic arrives at the Ethernet subinterface or ATM PVC, the BRAS uses the specified designation to give
a higher drop probability to packets marked with the designation. As a service provider, this enables you
to ensure that each of the separate sessions receives a minimum level of the subinterface or PVC capacity
and allows any one session to receive the full capacity of the subinterface or PVC if the other sessions
are idle.
When configuring simultaneous policy maps, you configure policy maps at the interface and session
levels in a serial fashion: one policy applied to a VAI or a LAC session and another policy applied to an
ATM PVC or an Ethernet-based subinterface as the following describes:

OL-7433-09
14-1
Chapter 14
Session-level policyYou associate this service policy with a PPP session on the VAI or LAC. This
policy must contain only non-queuing QoS actions such as policing and set actions. You can
statically configure this policy under a virtual template or use RADIUS Attributes 37 and 39 to
dynamically associate the policy with the PPP session. The BRAS applies this policy only at the PPP
session level.
Interface-level policyYou apply this service policy to a main interface, an ATM PVC, or an
Ethernet-based subinterface such as a VLAN subinterface. This policy can contain queuing-related
features, but it cannot have hierarchical policing policies. The BRAS applies this policy to the
aggregate traffic associated with a specific interface.
The BRAS recognizes that simultaneous policy maps exist and applies the appropriate QoS services to
the packets that are subject to both policies. The BRAS aggregates all of the packets of sessions at the
interface level. For example, if policing is applied on a traffic class in an interface policy, the BRAS
polices the aggregate of all of the packets on any of the sessions that match that class.
Feature History for Simultaneous Policy Maps

Cisco IOS Release
Description
Required PRE
Release 12.2(33)SB
The Simultaneous QoS Policy Map on Interface and PPP

SessionA-DSLAM Case feature was introduced on the
PRE2, PRE3, and PRE4.
PRE2, PRE3,
PRE4
QoS Actions
Table 14-1 lists the types of QoS actions allowed in simultaneous policy maps.
Table 14-1
Allowable QoS Actions in Simultaneous Policy Maps
Policy Type
QoS Actions Permitted
Session-level or interface-level input policies

session-level output policies
Non-queuing related actions
VC and Ethernet-based interface-level output

policies
Queuing, policing, and marking actions
Simultaneous Policies and Displaying Statistical Information

To display information about simultaneous policies and their associated statistical information, the
output from the show commands display information at both the interface level and the session level. At
the session level, a unique session owns each policy, and the QoS actions and statistics displayed apply
to that unique session. At the interface level, however, the BRAS treats all of the sessions in aggregate.
The information the BRAS gathers for display represents the aggregate QoS actions and statistics of all
of the sessions passing over the PVC or VLAN.
For simultaneous policies, the way in which the BRAS processes actions at one policy level and at a
subsequent policy level is consistent with the behavior of the BRAS when processing hierarchical input
policies. Table 14-2 describes how the actions at one policy level affect the classification or actions at a
subsequent policy level.
14-2
OL-7433-09
Chapter 14

Table 14-2
Influence of Session-Level Policy Actions on Interface-Level Policy Actions
Session-Level Policy Actions
Effect on Interface-Level Policy Actions
match cos
Valid as an input classification criteria on an Ethernet interface.

Configurable on the Ethernet interface, including a VLAN and
QinQ subinterface, and on a PPPoE session traversing an Ethernet
interface.
The interface-level policy does not influence the classification
done by the session policy.
Both the session-level and interface-level policies may use this
criteria.
Note
match ip precedence
match dscp
The session-level policy with the set cos command can

cause more packets to be classified by an interface-level
policy with the match cos command. The session policy
sets the CoS bits of the appropriate traffic and the
interface policy classifies the packets according to their
CoS values.
Valid as an input or output criteria and valid on all interface and

session types.
The action (or class) taken by the session-level policy influences
the class of the interface-level policy that the packet matches.
match discard-class
match qos-group
Valid as an output criteria on either session-level or

interface-level policies. Set as an input action and used in output
classification. Therefore, the input action does not affect the
output classification.
If both input policies attempt to set the discard-class or qos-group,
the value set by the session-level policy takes precedence.
Note
match interface
Typically, the discard-class is used in a queuing policy to

allow different drop probabilities. Therefore, limit
discard-class usage to only the interface-level policy.
Valid as an output classification criteria and is not influenced by

any actions at any of the policy levels.
Note
In this case, the interface is the session.
match exp
Not applicable to these types of session interfaces.
match acl
Dependent on the statements contained in the ACL. The only

values that may change between the session- and interface-level
policies is the precedence and DSCP fields. All other fields do not
change. Therefore, the session-level policy does not influence the
classification action of the interface-level policy, except in the
case of the precedence and DSCP fields.
match protocol
Valid as an input or output criteria on all interface and session

types, and is unchanged by the policies. Therefore, the
session-level policy does not influence the classification action of
the interface-level policy.

OL-7433-09
14-3
Chapter 14
Table 14-2
Influence of Session-Level Policy Actions on Interface-Level Policy Actions
Session-Level Policy Actions
Effect on Interface-Level Policy Actions
bandwidth, shape, priority,

random-detect, queue-limit
(queuing actions)
Valid in the interface-level output policy only. No interaction with

any other policy levels.
police
Indirect effect from one level to the next level. If a packet is

dropped by the session-level policy, the BRAS does not count the
packet in the token bucket calculations of the interface-level
policy.
set
Direct interaction between policy levels. The action at the

interface-level overrides the action at the session-level. This
occurs if the set command is used or if the set action is specified
in a police command.
A set command configured in a policy applied at the session level
can change the statistical information collected at the interface
level if the interface policy contains an action that matches a set
command in the session policy. For example, suppose a virtual
template policy contains the set ip prec 4 command and the
interface policy contains a policing action that transmits or drops
precedence 4 traffic. The session policy sets precedence 4 on the
appropriate traffic and the interface policy handles the resulting
precedence 4 traffic group by transmitting or dropping the traffic.
Note
Some set commands, such as the set clp command, are

specific to certain interface types, but this does not change
the behavior.
The router does not support hierarchical queuing policies when implementing simultaneous policy
maps. However, you can have nested policy maps.
The interface policy cannot be an hierarchical policing policy.
You cannot configure a hierarchical policing policy as the session policy when a policy is present
on the interface.
The session-level policy must contain only non-queueing actions such as police or set actions.
Queueing and shaping actions can be done in user-defined classes on VLAN subinterface.
Note
The Hierarchical Queueing for Ethernet DSLAMS feature allows a parent shaping and child
queueing policy attached to the session while shaping the VLAN subinterface (in
class-default class only). The VLAN subinterface can aggregate multiple sessions. The
Hierarchical Queueing for Ethernet DSLAMs feature allows a flat shaping policy on the
VLAN subinterface where the flat shaping policy must contain class-default class only. For
more information on the Hierarchical Queueing for Ethernet DSLAM feature, see the
QoS---Hierarchical Queueing for Ethernet DSLAMS guide.
The session-level policy takes precedence over the interface policy.
14-4
OL-7433-09
Chapter 14

Configuring Simultaneous Policy Maps
The simultaneous policy maps feature does not support LNS sessions, multilink PPP (MLPPP)
sessions, or IP sessions.
The simultaneous policy maps feature does not support a policy on an ATM main interface and a
policy on an ATM PVC at the same time. If this occurs, the PVC does not inherit the policy of the
main interface.
You cannot use RADIUS Attributes 37 and 39 to dynamically associate a QoS policy to a VLAN
subinterface.
The show policy-map command does not display the relationship of the two simultaneous policies.
Instead, use the show pxf statistics qos policy-map interface command and the show pxf statistics
qos policy-map session sid commands.
You cannot display the statistical information applicable to the two policies by issuing one CLI
command. Instead, to display the actions taken on the packets traversing the session, you must issue
two separate commands: show pxf statistics qos policy-map interface and show pxf statistics qos
policy-map session sid.

To configure simultaneous policy maps, perform the following configuration tasks for Ethernet or ATM
configurations:
Configuring the Two Policy Maps, page 14-5
Attaching Simultaneous Policies to PPPoE Sessions Traversing an Ethernet Interface, page 14-6
Attaching Simultaneous Policies to PPPoA Sessions Traversing an ATM VC, page 14-8
Attaching Simultaneous Policies to PPPoE Sessions Traversing an ATM VC, page 14-11
Configuring the Two Policy Maps

Simultaneous policy maps requires that you configure a policy map with non-queuing actions for the
session-level policy and a policy map with any actions, including queuing actions, for the interface-level
policy.
To configure the two policy maps, enter the following commands beginning in global configuration
mode:
Step 1
Command
Purpose
Creates or modifies a policy map template with the name you

specify and enters policy-map configuration mode.
policy-map-name is the name of the policy map. The name can
be a maximum of 40 alphanumeric characters.
Step 2

Note
On a given interface, the router uses the class-default

class to assign QoS policies to any packets that do not
belong to the classes defined in a policy map.
class-map-name is the name of the class map. The name can be


OL-7433-09
14-5
Chapter 14
Step 3
Command
Purpose

[be] burst-excess [conform-action action]
action]
(Optional) Configures bits per second-based traffic policing.

For information about the police command options, see the
Cisco IOS Command Reference Guide for Cisco IOS
Release 12.2 SB.
Note
Step 4
For session-level policies, specify the police or set

commands. You can only specify non-queuing actions
for this policy.
(Optional) Specifies the minimum bandwidth allocated for a

traffic class.
For information about the bandwidth command options, see the
Cisco IOS Command Reference Guide for Cisco IOS
Release 12.2 SB.
Note
For interface-level policies, you may specify any valid

QoS actions, including queuing actions, to define the
traffic classes specified in the policy map. See the QoS
Actions section on page 14-2
Attaching Simultaneous Policies to PPPoE Sessions Traversing an Ethernet

Interface
To attach simultaneous policies to PPPoE sessions traversing an Ethernet interface, perform the
following configuration tasks:
Attaching a Policy to a PPPoE Session, page 14-6
Attaching a Policy to an Ethernet Interface, page 14-7
Attaching a Policy to a PPPoE Session

To attach a policy map to a PPPoE session, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
Creates or modifies a subinterface. Enters subinterface

configuration mode.
type is the interface type (for example, GigabitEthernet).
number is the slot, module, port, subinterface number of the
interface (for example, 4/0/1.10).
Step 2
Router(config-subif)# protocol pppoe
Specifies the tunneling protocol that a virtual private dialup

network (VPDN) subgroup is to use, in this case PPPoE.
Step 3
Router(config-subif)# exit
Exits subinterface configuration mode.
14-6
OL-7433-09
Chapter 14

Step 4
Command
Purpose

number
Creates a virtual template interface that can be configured and

applied dynamically in creating virtual access interfaces.
number is a number used to identify the virtual template
interface.
Step 5
Router(config-if)# ip unnumbered type

number
Enables IP processing on an interface without assigning an

explicit IP address to the interface.
type is an interface on which the router has assigned an IP
address (for example, loopback). The interface cannot be an
unnumbered interface.
number is an interface or subinterface number (for example, 1).
Step 6

policy-map-name
Attaches the specified policy map to the interface in the

outbound direction.
policy-map-name is the name of a previously configured policy
map.
Configuration Example of Attaching the Interface Policy for Simultaneous Policy Maps
The following example configuration shows how to attach the interface policy for simultaneous policy
maps. In this example, the policy named pppoe_sess_output_policy is attached to the virtual template
interface named Virtual-Template1, which the BRAS uses when creating a virtual access interface (VAI)
for a session.
protocol pppoe
!
interface Virtual-Template1
ip unnumbered Loopback1
service-policy output pppoe_sess_output_policy
Attaching a Policy to an Ethernet Interface

To attach a policy map to an Ethernet interface, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose

configuration mode.
Step 2
Router(config-subif)# protocol pppoe

Step 3

policy-map-name

outbound direction.
map.

OL-7433-09
14-7
Chapter 14
Configuration Example of Attaching a Policy to an Ethernet Interface

The following example configuration shows how to attach a simultaneous policy map to an Ethernet
interface. In this example, the policy named pppoe_output_policy is attached to the Gigabit Ethernet
subinterface 3/0/0.10 in the outbound direction.
protocol pppoe
service-policy output pppoe_output_policy
Attaching Simultaneous Policies to PPPoA Sessions Traversing an ATM VC

To attach simultaneous policies to PPPoA sessions traversing an ATM VC, perform the following
Attaching a Policy to a PPPoA Session, page 14-8
Attaching a Policy to an ATM VC with PPPoA Sessions, page 14-9
Attaching a Policy to a PPPoA Session

To attach a policy map to a PPPoA session, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose


configuration mode.
point-to-point indicates that the subinterface connects directly
to one endpoint.
multipoint indicates that the subinterface connects to multiple
endpoints.
Step 2
Router(config-subif)# range pvc

start-vpi/end-vpi start-vci/end-vci
Defines a range of ATM permanent virtual circuits (PVCs).

(Optional) start-vpi/ is the beginning value for a range of virtual
path identifiers (VPIs). In the absence of the "/" and a VPI value,
the VPI value defaults to 0. Valid values are from 0 to 255.
(Optional) end-vpi is the end value for a range of virtual path
identifiers (VPIs). In the absence of an end-VPI value, the
end-VPI value defaults to the start-VPI value. Valid values are
from 0 to 255.
start-vci/ is the beginning value for a range of virtual channel
identifiers (VCIs). Valid values are from 32 to 65535. You must
specify the slash mark (/).
end-vci is the end value for a range of virtual channel identifiers
(VCIs). Valid values are from 32 to 65535.
14-8
OL-7433-09
Chapter 14

Step 3
Command
Purpose
Router(config-subif-atm-vc)# encapsulation
aal5mux ppp virtual-template number

type for the PVC range.
ppp configures the interface for PPP routing.
number is a number that identifies the virtual template.
Step 4
Router(config-subif-atm-vc)# exit
Exits ATM VC configuration mode.
Step 5
Step 6

number

Step 7

number
number is a number that identifies the virtual template interface.

Enables IP processing on the an interface without assigning an
loopback is an interface on which the router has assigned an IP
address. The interface cannot be an unnumbered interface.
number identifies the interface or subinterface (for example,
loopback1).
Step 8

policy-map-name

outbound direction.
map.
Configuration Example of Attaching a Policy to PPPoA Sessions

The following example shows how to attach a policy map to PPPoA sessions for simultaneous policy
maps. The example creates Virtual-Template1 and applies the policy map named
pppoa_int_output_policy to it. Virtual-Template1 is applied to PVC range 42/101 42/110 on ATM
interface 3/0/0.42101. The router uses Virtual-Template1 when it creates virtual access interfaces (VAIs)
for the sessions arriving on the PVC range.
interface ATM3/0/0.42101 multipoint
range pvc 42/101 42/110
!
service-policy output pppoa_int_output_policy
Attaching a Policy to an ATM VC with PPPoA Sessions

To attach a simultaneous policy to an ATM VC with PPPoA sessions, enter the following commands

OL-7433-09
14-9
Chapter 14
Step 1
Command
Purpose
Router(config)# interface atm number


configuration mode.
to one endpoint.
endpoints.
Step 2


from 0 to 255.
Step 3
Router(config-subif-atm-vc)# vbr-nrt
Configures the variable bit rate-nonreal time (VBR-NRT)

quality of service (QoS).
output-pcr is the output peak cell rate (PCR), in kbps.
output-scr is the output sustained cell rate (SCR), in kbps.
output-mbs is the output maximum burst cell size, expressed in
number of cells.
Step 4
aal5mux ppp virtual-template number

ppp configures the interface for PPP routing.
number is a number that identifies the virtual template.
Step 5
Router(config-atm-vc)# service-policy
output policy-map-name
Attaches the specified policy map to the specified PVC range in

the outbound direction.
map.
Configuration Example of Attaching a Policy to an ATM VC with PPPoA Sessions

The following example shows how to attach a simultaneous policy map named pppoa_output_policy to
PVCs in the range of 42/101 to 42/110 on the multipoint ATM interface 3/0/0.42101:
range pvc 42/101 42/110
vbr-nrt 2000 2000 1
14-10
OL-7433-09
Chapter 14


service-policy output pppoa_output_policy
Attaching Simultaneous Policies to PPPoE Sessions Traversing an ATM VC

To attach simultaneous policies to PPPoE sessions traversing an ATM VC, perform the following
Attaching a Policy to a PPPoA Session, page 14-8
Attaching a Policy to an ATM VC with PPPoA Sessions, page 14-9
Attaching a Policy to PPPoE Sessions

To attach a policy map to PPPoE sessions, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose


configuration mode.
to one endpoint.
endpoints.
Step 2


from 0 to 255.
Step 3
aal5snap

type for the PVC range
Step 4
Router(config-subif-atm-vc)# protocol
pppoe

Step 5
Router(config-subif-atm-vc)# exit
Step 6

OL-7433-09
14-11
Chapter 14
Step 7
Command
Purpose

number

number is a number that identifies the virtual template interface.
Step 8
Router(config-if)# ip unnumbered loopback

number
Enables IP processing on the an interface without assigning an

loopback is an interface on which the router has assigned an IP
address. The interface cannot be an unnumbered interface.
number identifies the interface or subinterface (for example,
loopback1).
Step 9

policy-map-name

outbound direction.
map.
Configuration Example for Attaching a Policy to PPPoE Sessions

The following example shows how to attach a simultaneous policy map to PPPoE sessions that are
traversing an ATM VC. The example creates Virtual-Template1 and applies the policy map named
pppoe_int_output_policy to it. The Virtual-Template1 is applied to the bba-group named VRF_1, which
is attached to PVC range 81/801 to 81/810 on the multipoint subinterface ATM 2/0/0.81801.
range pvc 81/801 81/810
protocol pppoe group VRF_1
!
bba-group pppoe VRF_1
Virtual-Template 1
sessions per-vc limit 1000
sessions per-mac limit 1000
sessions per-vlan limit 1000
!
service-policy output pppoe_int_output_policy
Attaching a Policy to an ATM VC with PPPoE Sessions

To attach a policy map to an ATM VC with PPPoE sessions, enter the following commands beginning
14-12
OL-7433-09
Chapter 14

Step 1
Command
Purpose


configuration mode.
to one endpoint.
endpoints.
Step 2


from 0 to 255.
Step 3
Router(config-subif-atm-vc)# vbr-nrt
Configures the variable bit rate-nonreal time (VBR-NRT)

output-scr is the output sustained cell rate (SCR), in kbps.
output-mbs is the output maximum burst cell size, expressed in
number of cells.
Step 4
aal5snap

Step 5
Router(config-subif-atm-vc)# protocol
pppoe

Configuration Example for Attaching a Policy to an ATM VC with PPPoE Sessions

The following example shows how to attach a simultaneous policy map to an ATM VC over which
PPPoE sessions traverse the network. The policy map named pppoe_sess_output_policy is attached to
Virtual-Template1, which is applied to the BBA group named VRF_1. The BBA group is attached to the
PVC range 81/801 to 81/810 on subinterface ATM 2/0/0.81801.
range pvc 81/801 81/810
vbr-nrt 2000 2000 1
protocol pppoe group VRF_1
!

OL-7433-09
14-13
Chapter 14
Configuration Examples for Simultaneous Policy Maps
Virtual-Template 1
!

Configuration Example for Applying Simultaneous Policy Maps on Ethernet Interfaces and PPPoE
Sessions, page 14-14
Configuration Example for Applying Simultaneous Policies on 802.1Q Interfaces and PPPoE
Configuration Example for Applying Simultaneous Policies on 802.1Q QinQ Interfaces and PPPoE
Configuration Example for Applying Simultaneous Policies on ATM VCs and PPPoA Sessions,
page 14-17
Configuration Example for Applying Simultaneous Policies on ATM VCs and PPPoE Sessions,
page 14-18
Configuration Example for Applying Simultaneous Policy Maps on Ethernet

Interfaces and PPPoE Sessions
The following configuration example shows how to create and apply simultaneous policy maps on
Ethernet interfaces and PPP sessions. The Client Configuration shows that no policies have been applied.
In the PTA Configuration, the interface policy named cbwfq_out_policy is applied to the Gigabit
subinterface Ethernet 1/0/0.2 and the session policy named police_out_policy is applied to the virtual
template named Virtual-Template1, which is in turn applied to the BBA group named VRF_1.
Client Configuration
virtual-template 1
!
interface GigabitEthernet8/0/0
no ip address
!
pppoe enable group VRF_1
!
Interface Virtual-Template1
mtu 1492
ip address negotiated
keepalive 30
ppp max-terminate 10
ppp max-failure 10
ppp lcp delay 1
ppp pap sent-username gomer1@domain1.com password 0 gomer
14-14
OL-7433-09
Chapter 14

ppp timeout retry 1

ppp timeout authentication 15
PTA Configuration
aaa new-model
!
Username gomer1@domain1.com password 0 gomer
aaa authentication ppp default local
aaa authentication login mylist enable line aaa authentication ppp
vpdn enable
ppp hold-queue 80000
no mpls ldp logging neighbor-changes
no virtual-template snmp
!
buffers small permanent 15000
buffers middle permanent 12000
buffers big permanent 8000
virtual-template 1
!
class-map match-any voip
match ip precedence 5
!
class-map match-any all_pkts
match any
!
class-map match-any video
match ip precedence 4
!
! The policy map named cbwfq_out_policy is the interface policy that is inherited by all sessions.
policy-map cbwfq_out_policy
class voip
priority
class video
bandwidth 20
class class-default
!
policy-map in_pmap
class all_pkts
!
! The policy map named police_out_policy is the session policy that is owned by each session.
policy-map police_out_policy
class voip
class video
police 10000 4000 0 con conform-action transmit exceed-action drop violate-action drop
class class-default
class all_pkts
!
no ip address
!
! Interface policy named cbwfq_out_policy is applied to the GE interface.


OL-7433-09
14-15
Chapter 14
pppoe enable group VRF_1

service-policy output cbwfq_out_policy
!
! Session policy named police_out_policy is applied to the virtual template.

mtu 1492
no logging event link-status
no snmp trap link-status
peer default ip address pool pppoe-pool default
keepalive 30
ppp max-terminate 10
ppp max-failure 10
ppp lcp delay 1
ppp authentication pap
ppp ipcp address required
ppp timeout retry 1
ppp timeout authentication 15
service-policy output police_out_policy
!
ip local pool pppoe-pool 111.1.1.1 111.1.4.254
Configuration Example for Applying Simultaneous Policies on 802.1Q Interfaces

and PPPoE Sessions
The following configuration example shows how to attach simultaneous policy maps to an 802.1Q
interface and PPP sessions. The policy map named pppoe_int_output_policy is attached to subinterface
GigabitEthernet 3/0/0.10. The policy maps named pppoe_sess_output_policy and
pppoe_sess_input_policy are attached to the virtual template named Virtual-Template1. The router
applies the virtual template to the session when it creates the virtual access interface (VAI) for the
session.
Session
pppoe enable
!
service-policy input pppoe_sess_input_policy
Interface
pppoe enable
14-16
OL-7433-09
Chapter 14

Configuration Example for Applying Simultaneous Policies on 802.1Q QinQ

Interfaces and PPPoE Sessions
The following configuration example shows how to attach simultaneous policy maps to an 802.1Q QinQ
interface and PPPoE sessions. The policy maps named pppoe_int_output_policy and
pppoe_int_input_policy are attached to the QinQ subinterface Gigabit Ethernet 3/0/0.10. The policy
named pppoe_sess_output_policy is attached to the virtual template named Virtual-Template1. The
router applies the virtual template to the session when it creates the virtual access interface (VAI) for the
session.
Session
encapsulation dot1Q 10 second-dot1q 19
pppoe enable
!
Interface
encapsulation dot1Q 10 second-dot1q 19
pppoe enable
service-policy input pppoe_int_input_policy
Configuration Example for Applying Simultaneous Policies on ATM VCs and

PPPoA Sessions
The following configuration example shows how to attach simultaneous policy maps to ATM PVCs and
PPPoA sessions. The policy map named pppoa_int_output_policy is attached to the PVC range 42/101
to 42/110 for outbound traffic. The policies named pppoa_sess_output_policy and
pppoa_sess_input_policy are attached to the virtual template named Virtual-Template1 for outbound and
inbound traffic, respectively. The router applies the virtual template to the session when it creates the
virtual access interface (VAI) for the session.
Session
range pvc 42/101 42/110
!
service-policy output pppoa_sess_output_policy
service-policy input pppoa_sess_input_policy
VC
range pvc 42/101 42/110
vbr-nrt 2000 2000 1

OL-7433-09
14-17
Chapter 14
Configuration Example for Applying Simultaneous Policies on ATM VCs and

PPPoE Sessions
The following configuration example shows how to attach simultaneous policy maps to ATM PVCs and
PPPoE sessions traversing the ATM PVCs. The policy maps named pppoa_int_output_policy and
pppoa_int_input_policy are attached to the PVC range 01/001 to 01/010. The policy map named
pppoe_sess_output_policy is attached to the virtual template named Virtual-Template1. The router
applies the virtual template to the session when it creates the virtual access interface (VAI) for the
session.
Session
range pvc 81/801 81/810
protocol pppoe
!
VC
range pvc 81/801 81/810
vbr-nrt 2000 2000 1
service-policy input pppoa_int_input_policy
protocol pppoe

When displaying statistical information for simultaneous policy maps, the BRAS displays information
for both the session-level and interface-level policies as the following describes:
Session levelEach unique session owns each policy. Therefore, the information that displays
represents the statistics of the session.
Interface levelThe information that displays represents the aggregate statistics of all of the
sessions passing over the ATM PVC or Ethernet-based subinterface (the sessions inherited policy).
To verify and monitor simultaneous policy maps, enter any of the following commands in privileged
EXEC mode:
Command
Purpose

configured policy maps.

policy map you specify.
14-18
OL-7433-09
Chapter 14

Command
Purpose

input and output policy maps attached to the interface you
specify.
Note
Router# show policy-map session sid sid
To view the statistics for simultaneous policy maps, you

must issue both the show policy-map interface
command and the show policy-map session sid
command.

policy map applied to the session you specify.
Note
To view the statistics for simultaneous policy maps, you

must issue both the show policy-map interface
command and the show policy-map session sid
command.
Router# show pxf statistics qos policy-map

session sid sid
Displays the relationship of the two simultaneous policies and

statistical information applicable to the two policies. Displays the
policy map applied to the specified session (for example, the
session-owned policy) and the policy map applied to the interface
over which the sessions traverse (for example, the inherited
policy).
Router# show pxf statistics qos policy-map

interface interface
Displays the relationship of the two simultaneous policies and

statistical information applicable to the two policies. Displays
statistical information for the session and for the subinterface or
VC-level policy the session inherited. The information that
displays at the subinterface or VC level is the aggregate
information of all of the sessions using the subinterface or VC;
for example, the aggregate of the packets that were matched,
dropped, marked, queued, and so on.
Note
The router does not support displaying relationships between the two simultaneous policies.

This section provides the following verification examples. In the examples, the policy named parent1 is
applied on the interface and the policy named prec-only is applied on the virtual template or pushed from
RADIUS for the session.
Displaying Simultaneous Policy Map Information for Interfaces, page 14-20
Displaying Simultaneous Policy Map Information for PTA Virtual Interfaces, page 14-21
Displaying Simultaneous Policy Map Information for Virtual Access Interfaces, page 14-21
Displaying Simultaneous Policy Map Information for a LAC Session, page 14-22

OL-7433-09
14-19
Chapter 14
Displaying Simultaneous Policy Map Information for Interfaces

The following example shows sample output from the show pxf statistics qos policy-map interface
command. The output shows policy map information for the specified Gigabit Ethernet
subinterface 6/0/0.2, which is the inherited policy of the sessions that use the subinterface. The output
also shows the policy maps owned by the sessions traversing the subinterface.
Router# show pxf statistics qos policy-map interface gigabitethernet 6/0/0.2
Simultaneous Policymap Info for GigabitEthernet6/0/0.2 Input Policy owned by GigabitEthernet6/0/0.2 [VCCI 2524] - 'parent1':
Class
---------------prec5
class-default
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
----------- ------------ --------------- ----------- ----------1000
66000
0
0
0
0
0
0
0
0
Input Policy owned by Virtual-Access3.4 [VCCI 3241] - ''prec-only:

Class
---------------prec5
prec3
prec2
class-default
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
----------- ------------ --------------- ----------- ----------500
33000
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Input Policy owned by Virtual-Access3.3 [VCCI 3240] - 'prec-only':

Class
---------------prec5
prec3
prec2
class-default
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
----------- ------------ --------------- ----------- ----------500
33000
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
14-20
OL-7433-09
Chapter 14

Displaying Simultaneous Policy Map Information for PTA Virtual Interfaces

The following example shows sample output from the show pxf statistics qos policy-map session
command. The output shows policy map information for the specified session and for the virtual access
interface (VAI) created for the session.
Router# show pxf statistics qos policy-map session sid 11
Simultaneous Policymap Info for Session ID #11 ( Virtual-Access3.3 ) Simultaneous Policymap Info for Virtual-Access3.3 Input Policy owned by Virtual-Access3.3 [VCCI 3240] - 'prec-only':
Class
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
---------------- ----------- ------------ --------------- ----------- ----------prec5
500
33000
0
0
0
prec3
0
0
0
0
0
prec2
0
0
0
0
0
class-default
0
0
0
0
0
Input Policy inherited from GigabitEthernet6/0/0.2 [VCCI 2524] - 'parent1':
Class
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
---------------- ----------- ------------ --------------- ----------- ----------prec5
1000
66000
0
0
0
class-default
0
0
0
0
0
Displaying Simultaneous Policy Map Information for Virtual Access Interfaces

command when a virtual access interface (VAI) is specified as the interface:
Router# show pxf statistics qos policy-map interface vi3.3
Simultaneous Policymap Info for Virtual-Access3.3 Input Policy owned by Virtual-Access3.3 [VCCI 3240] - 'prec-only':
Class
---------------prec5
prec3
prec2
class-default
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
----------- ------------ --------------- ----------- ----------500
33000
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Input Policy inherited from GigabitEthernet6/0/0.2 [VCCI 2524] - 'parent1':

Class
---------------prec5
class-default
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
----------- ------------ --------------- ----------- ----------1000
33000
0
0
0
0
0
0
0
0

OL-7433-09
14-21
Chapter 14
Displaying Simultaneous Policy Map Information for a LAC Session

command when a LAC session is traversing the Gigabit Ethernet subinterface 6/0/0.2.
Router# show pxf statistics qos policy-map interface gigabitethernet 6/0/0.2
Simultaneous Policymap Info for GigabitEthernet6/0/0.2 Input Policy owned by GigabitEthernet6/0/0.2 [VCCI 2524] - 'parent1':
Class
---------------prec5
class-default
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
----------- ------------ --------------- ----------- ----------332
21912
332
0
0
668
44088
668
0
0
Input Policy owned by LAC Session traversing GigabitEthernet6/0/0.2 [VCCI 2529] 'prec-only':
Class
---------------prec5
prec3
prec2
class-default
Pkts
Bytes
Pkts
Pkts
Pkts
Matched
Matched
Conformed
Exceeded
Violated
----------- ------------ --------------- ----------- ----------332
21978
333
0
0
0
0
0
0
0
0
0
0
0
0
667
44022
0
0
0
14-22
OL-7433-09
CH A P T E R
15

Asynchronous Transfer Mode (ATM), Frame Relay, and IEEE 802.1Q Ethernet networks offer
connection-oriented, circuit-based data transfer. Such networks provide statistical multiplexing of traffic
from all the virtual circuits (VCs) sharing the physical port. Some VCs have a built-in method of traffic
capacity. Others like Frame Relay and Ethernet are just best effort. Optionally, a provider may choose
to reserve bandwidth for such a VC through configuration. Once a VC has a defined bandwidth, the
router strives to service the VC traffic at the specified transmission rate, and optionally provides
differentiated service to packets of that VC.
While provisioning bandwidth to virtual circuits, the provider has a choice of offering unconditional or
statistical guarantees. When the sum of the transmission capacities of VCs falls within the bandwidth of
the physical network, it never congests; therefore, each VC receives its bandwidth reservation regardless
of the traffic pattern of any other VC on that network. On the other hand, when the total assigned
bandwidth exceeds the physical capacity, the router allocates each VC bandwidth reservation as long as
a limited number of VCs activate at one time. The former offers unconditional service at the expense of
underutilization of the physical capacity; the latter takes advantage of statistical multiplexing to provide
better network utilization at the expense of degraded service under congestion.
To improve network utilization of otherwise underutilized shared networks, the Cisco 10000 series
router offers oversubscription functionality. Oversubscription helps to offset infrastructure costs and is
an integral part of networking topologies.
This chapter describes interface and virtual circuit oversubscription and includes the following topics:
Interface Oversubscription, page 15-2
ATM Virtual Circuit Oversubscription, page 15-3
Frame Relay PVC Oversubscription, page 15-7
Virtual LAN Oversubscription, page 15-9
Oversubscription and Hierarchical Policies, page 15-10
Configuring Oversubscription, page 15-10
How the Router Determines VC Weights, page 15-20
Configuring VC Weighting, page 15-28
Verifying Oversubscription and VC Weighting, page 15-41

OL-7433-09
15-1
Chapter 15
Interface Oversubscription
Interface Oversubscription
Interface oversubscription enables service providers to assign a total committed information rate (CIR)
to a given port that is greater than the speed of the port. In this way, instead of supporting only
unconditional reservation of network bandwidth to VCs, the Cisco 10000 series router can statistically
guarantee bandwidth to the VCs, thus improving network utilization.
While interface oversubscription offers distinct advantages, it has the potential of degrading system
performance during congestion. The packet scheduler directs traffic to a physical port. Without
oversubscription, the packet scheduler reserves scheduling resources for each VC so that the total
amount is less than or equal to the capacity of the network. With oversubscription, the scheduler assigns
its resources at a rate higher than the transmission capacity of the network. This mismatch of rates
between the scheduler and the network results in reduced scheduling efficiency such as the following:
The scheduling resources that are in excess of the physical capacity fail to perform productively
because of the networks refusal to accept new packets during congestion.
Congestion at the physical layer causes the scheduler to retry packet transmissions until accepted by
the network, which further reduces the schedulers productivity. Prolonged congestion also
interferes with the schedulers operations to serve each traffic class according to its bandwidth
commitment.
With oversubscription, network congestion can occur if all of the network capacity is used concurrently.
However, the risk is low if you avoid oversubscribing a network that is likely to congest and if you do
not oversubscribe a service too much. Without oversubscription, you loose the benefits of
oversubscription such as the following:
Lower cost for port connection
Network bandwidth is available if and when you need it
The statistical multiplexing that is used with oversubscription saves money because data traffic
tends to be bursty
The statistical multiplexer assigns bandwidth on a circuit as needed, thus saving bandwidth
Feature History for Interface Oversubscription

Cisco IOS Release
Description
Required PRE
Release 12.0(25)SX
The interface oversubscription feature was introduced on

the router.
PRE1
Release 12.3(7)XI
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3 and uses

statistical multiplexing on ATM, Frame Relay, and IEEE
802.1Q networks.
PRE3
15-2
OL-7433-09
Chapter 15

ATM Virtual Circuit Oversubscription
Restrictions and Limitations for Interface Oversubscription
Interface oversubscription can potentially degrade system performance during congestion due to a
mismatch of rates between the packet scheduler and the network.
With oversubscription, network congestion can occur if all of the network capacity is used
concurrently. However, the risk is low if you avoid oversubscribing a network that is likely to
congest and if you do not oversubscribe a service too much.
For more information, see the Interface Oversubscription section on page 15-2.

The Cisco 10000 series router supports the oversubscription of variable bit rate-nonreal time (VBR-nrt)
and constant bit rate (CBR) virtual circuits (VCs), and virtual path (VP) tunnels. Oversubscription
enables service providers to improve network utilization of otherwise underutilized shared networks by
leveraging statistical multiplexing on ATM networks. Instead of supporting only unconditional
reservation of network bandwidth to VCs, the router offers VC oversubscription to statistically guarantee
bandwidth to VCs.
VC oversubscription assumes that congestion at the physical port never or rarely occurs. For example,
assume 10 VCs are configured to use 25 percent of the physical network bandwidth. The full capacity
of the network is reached if only four VCs attempt to transmit traffic. VBR-nrt oversubscription is
intended only for networks with low utilization in which congestion is unlikely to exist. If congestion
occurs on the PRE1 or PRE2, the router gives each VC an equal fair share of the bandwidth. If congestion
occurs on the PRE3, the router gives each VC a share of the bandwidth based on the configured weight
of the VC.
In releases prior to Cisco IOS Release Cisco IOS Release 12.2(16)BX, a call admission check (CAC)
prevented you from assigning more bandwidth to virtual circuits (VCs) than a ports total bandwidth.
The Cisco 10000 series router supported unconditional reservation of network bandwidth to VCs. When
the sum of the transmission capacities of VCs falls within the bandwidth of the physical network, the
network does not congest. Each VC receives its bandwidth reservation regardless of the traffic pattern
of any other VC on that network. However, VCs receive this unconditional service at the expense of
underutilization of the physical capacity of the network. Because each VC uses a fraction of the physical
capacity, unless a large number of VCs remain busy, the overall network utilization remains low.
In Cisco IOS Release 12.2(16)BX or later, VBR-nrt oversubscription enables you to specify the amount
of oversubscription (oversubscription factor) you want to allow. Oversubscription of ATM interfaces is
disabled by default.
Note
In releases prior to Cisco IOS Release 12.3(7)XI3, virtual path (VP) tunnel oversubscription does not
behave as intended. Instead, oversubscription of VP tunnels (the number and bandwidth of VCs that can
be in a tunnel) is on by default and is not subject to any oversubscription factor. Oversubscription of VP
tunnels cannot be adjusted or turned off. However, in Cisco IOS Release 12.3(7)XI3 and later releases,
VP tunnel oversubscription is subject to call admission checks and is off by default. The CAC
mechanism checks all of the VCs and VP tunnels going to an interface, and all of the VCs going into a
VP tunnel. You can also specify the amount of oversubscription to allow.
The PRE3 allows the aggregate rate of ATM VCs to exceed the bandwidth of the interface or VP on
which the VCs were created based on the configured oversubscription factor on the ATM interface.

OL-7433-09
15-3
Chapter 15
For optimal performance, configure the oversubscription factor as closely as possible to the sum of all
VCs. The system allows VCs to be added, provided the total subscribed rate is less than or equal to the
port speed times the over-subscription-factor. The CAC is based on the oversubscription factor you
specify and evaluated separately for both VCs and VP tunnels into the port, and VCs into VP tunnels.
Whenever you reduce the oversubscription factor, less bandwidth is available for VC creation. As a
result, a warning message appears indicating that some VCs might not be created. The router does not
explicitly remove the VCs from the configuration; the VCs remain up and functional until you reboot the
router or reset the slot. At this point, the VCs remain in the configuration but they are not up.
When the no atm pxf queuing command is configured on an interface for the PRE1 or PRE2, the router
allows unlimited oversubscription. The ATM oversubscription commands have no effect. For the PRE3,
the no atm pxf queuing command is not supported.
Feature History for ATM VC Oversubscription

Cisco IOS Release
Description
Required PRE
Release 12.2(16)BX
The ATM VC oversubscription feature was introduced on PRE2

the PRE2 with an oversubscription factor from 1 to 50.
Release 12.3(7)XI3
This feature was enhanced on the PRE2 with an

oversubscription factor from 1 to 500.
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3 with an

oversubscription factor from 1 to 500.
PRE3
Oversubscription Factor and Unspecified Bit Rate Virtual Circuits

Unspecified bit rate (UBR) virtual circuits (VCs) are not subject to a call admission check (CAC).
Therefore, by default the router allows unlimited oversubscription of UBR VCs.
For releases prior to Cisco IOS Release 12.3(7)XI1, if you use unshaped (no PCR specified) UBR VCs,
the router allocates bandwidth to the variable bit rate (VBR) and constant bit rate (CBR) VCs, and to the
VP tunnels before allocating the remaining bandwidth to the unshaped UBR VCs. For example:
Port Speed Sum of the VBR VCs = Aggregate UBR bandwidth
The bandwidth the router allocates to the unshaped UBR VCs must be 64 kbps less than the total
bandwidth of the interface.
In Cisco IOS Release 12.3(7)XI1 and later releases, the oversubscription factor is used to evaluate the
amount of bandwidth allocated for unshaped UBR VCs. The CAC adjusts the bandwidth for unshaped
UBR VCs based on the oversubscription factor.
Note
You can apply a hierarchical policy map to the main ATM interface to override this default equation and
set a specific bandwidth for the aggregate UBR queues. For more information about hierarchical
policies, see Chapter 13, Defining QoS for Multiple Policy Levels.
15-4
OL-7433-09
Chapter 15

ATM VC Oversubscription and ATM Line Cards

ATM VC oversubscription controls the allocation of resources that are managed on a line card. If you
enable oversubscription on one port alone, other ports might use more resources than they are supposed
to use, which could result in resource starvation of other ports, causing VC creation to fail. Therefore,
we recommend that you apply VC oversubscription to all ports of an ATM line card.
Table 15-1 lists the number of active VCs the ATM line cards support in atm pxf queuing mode for Cisco
IOS Release 12.3(7)XI2 and later releases.
Table 15-1
Line Card
Active VCs on ATM Line Cards
Max. VCs per Port
Maximum VCs per Module
No. VBR, CBR, Shaped UBR VCs
28,6722
E3/DS3
4,096
32,768
OC-3
8,191
32,7643
28,6724
OC-12
16,384 (previously 14,436)
16,384
16,384
1. For 32,768 VCs per module, 4096 of them must be unshaped UBR VCs.
2. For 28,672 VBR, CBR, and shaped UBR VCs, no VCs can be in shaped VP tunnels. If VCs are in shaped VPs, the number of VBR, CBR, and shaped
UBR VCs is 22,204.
3. For 32,764 VCs per module, 4096 of them must be unshaped UBR VCs.
4. For 28,672 VBR, CBR, and shaped UBR VCs, no VCs can be in shaped VP tunnels. If VCs are in shaped VPs, the number of VBR, CBR, and shaped
UBR VCs is 22,204.
You can configure the maximum number of VCs across the ports in any fashion, provided that you do
not exceed the per-port maximum.
Although the maximum number of VBR, CBR, and shaped UBR VCs per E3/DS3 and OC-3 ATM line
card is 28,672 VCs, the router supports a maximum of 22,204 VBR, CBR, and shaped UBR VCs per line
card that you can place within virtual path (VP) tunnels. If you attempt to bring up more than 22,204
VCs in a configuration that includes VP tunnels and VCs (hierarchical traffic shaping configuration), the
VCs might not assign traffic correctly or the VCs might not come up at all. Be sure to limit the number
of configured VBR, CBR, and shaped UBR VCs on an ATM card to less than 22,204 VCs if you place
the VCs in VP tunnels.
For the OC-12 ATM line card, the router supports 16,384 VCs in VP tunnels.
atm over-subscription-factor Command

To oversubscribe ATM virtual circuits (VCs), use the atm over-subscription-factor command in
interface configuration mode. To prevent oversubscription of an ATM VC, use the no atm
oversubscribe command. By default, oversubscription of ATM interfaces and tunnels is enabled.
atm over-subscription-factor {factor}
no atm over-subscription-factor {factor}

OL-7433-09
15-5
Chapter 15
Syntax Description
factor
Specifies the amount of oversubscription. The default value is 1, which

indicates no oversubscription. Valid values are:
1 to 500 on the PRE2Requires Cisco IOS Release 12.3(7)XI3 or later

releases, or Cisco IOS Release 12.2(28)SB
1 to 500 on the PRE3Requires Cisco IOS Release 12.2(31)SB2 or

later releases
atm over-subscription-factor Command History

Cisco IOS Release
Description
Release 12.2(16)BX
The atm over-subscription-factor command was introduced on the PRE2

with an oversubscription factor from 1 to 50.
Release 12.3(7)XI3
This command was enhanced on the PRE2 with an oversubscription factor

from 1 to 500.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
This command was introduced on the PRE3 with an oversubscription

factor from 1 to 500.
Usage Guidelines for the atm over-subscription-factor Command

An ATM variable bit rate (VBR) VC uses the sustained cell rate (SCR) to define the VCs average
transmission rate. Therefore, use the atm over-subscription-factor command to specify the ATM VC
oversubscription, not the service-policy command.
Use the atm over-subscription-factor command for each ATM interface that you want to oversubscribe.
Because the oversubscription of VBR-nrt VCs requires resources from the entire line card, apply the
atm over-subscription-factor command on all ports of the ATM card (for example, the 4-port OC-3
ATM line card). If you enable the oversubscription on only one port, the other ports can use more
resources than they were configured to use. As a result, some ports do not receive adequate resources,
which results in VC creation failures.
Unlike other Cisco routers, the Cisco 10000 series router uses the atm oversubscribe command in
conjunction with the atm over-subscription-factor command to enable or disable oversubscription for
a particular interface or tunnel. When enabling ATM oversubscription for a particular interface or tunnel,
specify the atm over-subscription-factor command. Do not use the atm oversubscribe command to
enable oversubscription as this can cause undesirable results. Instead, leave it to the default value.
For example, the following configuration enables the oversubscription feature and configures the
interface with an oversubscription factor of 500.
Router(config-if)# atm oversubscribe
Router(config-if)# end
15-6
OL-7433-09
Chapter 15

Frame Relay PVC Oversubscription
To prevent oversubscription of the interface, enter the no atm oversubscribe command. For example,
the following configuration disables oversubscription of the ATM 4/0/0 interface. The previously
configured factor of 500 is configured on the interface, but the router does not allow the
oversubscription.
Router(config-if)# no atm oversubscribe
To enable the oversubscription feature with the previously configured factor 500, enter the
atm oversubscribe command. For example:
Router(config-if)# atm oversubscribe
Restrictions and Limitations for ATM VC Oversubscription

The following restrictions and limitations are applicable only if the port becomes congested:
To oversubscribe ATM VCs requires resources from the entire line card (for example, the 4-port
OC-3 ATM line card). If you configure oversubscription on only one port, the other ports can use
more resources than they were configured to use. As a result, some ports do not receive adequate
resources, which results in VC creation failures. Therefore, apply the atm over-subscription-factor
command on all ports of the ATM card.
Due to congestion on the physical interface, the accuracy of the bandwidth distribution between the
class queues degrades. For example, if you configure each of three queues at a distribution of 50,
30, and 20 percent, the actual distribution might be 45, 40, and 15 percent.
The distribution of bandwidth for each VC might be less than expected based on the speed of the
VC. Typically, low-speed VCs are allocated the expected bandwidth while high-speed VCs share the
remaining bandwidth equally.
The amount of bandwidth allocated for the priority queue or latency might be less than expected.

The Cisco 10000 series router supports the oversubscription of Frame Relay permanent virtual circuits
(PVCs). Oversubscription enables a service provider to assign a total committed information rate (CIR)
to a given PVC that is greater than the speed of the interface.
One of the goals of service providers is to save on expensive interface costs. The intermittent and bursty
nature of Frame Relay traffic practically guarantees that all of the Frame Relay PVCs are not going to
require the maximum committed information rate (CIR) at the same time. Therefore, Frame Relay traffic
is well-suited to oversubscribing available interfaces, thus reducing interface connection costs.
The router uses statistical multiplexing to assign bandwidth on PVCs as needed. This enables service
providers to provide service to a large number of customers over shared bandwidth, rather than dedicated
bandwidth and it enables customers to oversubscribe a PVC and still have guaranteed bandwidth through
the provider network even though the amount of guaranteed network bandwidth might exceed the
interface speed.
Network congestion is a concern when oversubscribing connections. If customers concurrently use all
of the network capacity, congestion can occur; however, the risk of congestion is low if you do not
oversubscribe too much and if you avoid oversubscribing networks that are likely to congest.

OL-7433-09
15-7
Chapter 15
Figure 15-1 shows a Frame Relay network that is oversubscribed. In the figure, the Central Site has a
1.544-Mbps Frame Relay circuit. The network has 18 remote sites with 128-kbps Frame Relay circuits.
The aggregate bandwidth is 2.3 Mbps:
128 kbps * 18 sites = 2.3 Mbps
The Central Site is oversubscribed by 50 percent. However, this configuration is valid because:
The remote users require only e-mail access and the ability to transfer small files using File Transfer
Protocol (FTP).
All of the remote sites are unlikely to try to use all of the available bandwidth at the same time.
All of the remote sites are unlikely to simultaneously access the network.
Figure 15-1
Oversubscribed Frame Relay Network
18 Frame Relay
Access Devices
(FRAD)
Aggregate bandwidth
of remotes exceed egress
128 kbps
1.544 Mbps
Frame Relay
Network
126832
Central site
Feature History for Frame Relay PVC Oversubscription

Cisco IOS Release
Description
Required PRE
Release 12.3(7)XI1
The Frame Relay PVC oversubscription feature was

introduced on the PRE2.
PRE2
Release 12.2(28)SB

PRE2
15-8
OL-7433-09
Chapter 15

Virtual LAN Oversubscription
Restrictions and Limitations for Frame Relay PVC Oversubscription

If customers concurrently use all of the network capacity, congestion can occur. However, the risk of
congestion is low if you do not oversubscribe too much and if you avoid oversubscribing networks that
are likely to congest.
Virtual LAN Oversubscription

The Cisco 10000 series router supports the oversubscription of IEEE 802.1Q virtual LANs (VLANs) to
improve network utilization of otherwise underutilized shared networks by leveraging statistical
multiplexing on 802.1Q networks. Because of the bursty nature of LAN traffic and the typical low
utilization of Ethernet at the network edge, oversubscription is an appropriate solution for eliminating
unused bandwidth on Ethernet networks.
Oversubscription enables you to configure a total committed information rate (CIR) for a particular
VLAN that is greater than the speed of the interface. Because different users require high bandwidth
utilization at different times, service providers can oversubscribe network ports to provide services to
more users and improve network utilization.
Network congestion is a concern, especially when oversubscribing connections. In some circumstances,
the aggregate bandwidth might exceed capacity; however, the implementation of oversubscription
guarantees minimum quality of service and fair treatment of all users. When packet drop is required,
Ethernets congestion avoidance and congestion management mechanisms as well as the
oversubscription logic ensure that packet drops affect lower priority traffic first.
The PRE3 allows the aggregate rate of all VLANs created on an interface to exceed the available
bandwidth. The excess bandwidth is distributed among the VLANs proportionally to their weights using
the shape parent and child policies applied on the subinterface. For more information, see the
Distribution of Remaining Bandwidth Using Ratio section on page 5-14.
Feature History for VLAN Oversubscription

Cisco IOS Release
Description
Release 12.3(7)XI1
The VLAN oversubscription feature was introduced on the PRE2

PRE2.
Required PRE
Release 12.2(28)SB

Release 12.2(31)SB2
This feature was introduced on the PRE3 to allow

PRE3
aggregate VLAN rates to exceed the available bandwidth.
PRE2
Restrictions and Limitations for VLAN Oversubscription

In some circumstances, the aggregate bandwidth might exceed capacity. However, the implementation
of oversubscription guarantees minimum quality of service and fair treatment of all users.

OL-7433-09
15-9
Chapter 15

You can create a hierarchical policy to manage traffic within a virtual circuit. When such a configuration
exists, the router allocates the physical pipe into smaller pipes. Instead of creating a single versatile time
management scheduler (VTMS) link for the physical interface, each parent policy map has a VTMS link.
Previously, the sum of the bandwidths of the parent policies had to be less than the bandwidth of the
physical link. With interface oversubscription, the sum of the parent policies can oversubscribe the link.
For more information about hierarchical policies, see Chapter 13, Defining QoS for Multiple Policy
Levels.
Example 15-1 shows how to oversubscribe a Frame Relay subinterface when defining QoS behavior in
a hierarchical policy. In the example, the traffic class named class1 is policed at 60 percent of the total
transmission capacity and the class named class2 is allocated 45 percent of the total bandwidth.
Therefore, the total requested bandwidth exceeds the link bandwidth.
Example 15-1 Oversubscribing a Link Using Nested Policies
Router(config)# class-map match-all class1
Router(config-cmap)# match access-group1
Router(config)# class-map match-all class2
Router(config-cmap)# match access-group2
Router(config)# policy-map dlci-103 [child policy]
Router(config-pmap)# policy-map shape-2meg-dlci-103 [parent policy]
Router(config-pmap-c)# service-policy dlci-103 [child policy]
Router(config-subif)# service-policy output shape-2meg-dlci-103 [attaches parent policy]
Router(config-subif)# frame-relay interface-dlci 103
For more information about hierarchical policies, see Chapter 13, Defining QoS for Multiple Policy
Levels.
Configuring Oversubscription
To configure oversubscription on ATM, Frame Relay, and 802.1Q VLAN virtual circuits, perform any
of the following configuration tasks:
Oversubscribing ATM VBR-nrt VCs, page 15-11
Oversubscribing Frame Relay PVCs, page 15-11
Oversubscribing 802.1Q VLANs, page 15-17
15-10
OL-7433-09
Chapter 15

Oversubscribing ATM VBR-nrt VCs

To enable oversubscription of ATM VBR-nrt VCs, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1

Specifies the interface or subinterface on which you want to

enable VC oversubscription. Enters interface or
Step 2
Router(config-if)# atm over-subscription-factor

{factor}
Oversubscribes an ATM VC.

factor specifies the amount of oversubscription. The default
value is 1, which indicates no oversubscription. Valid values
are:
1 to 500 on the PRE2Requires Cisco IOS Release

12.3(7)XI3 or later releases, or Cisco IOS
Release 12.2(28)SB
1 to 500 on the PRE3Requires Cisco IOS

Release 12.2(31)SB2 or later releases
Note
Note
Use this command for each ATM interface that you

want to oversubscribe.
You do not need to use the service-policy command to specify the ATM VC oversubscription because a
variable bit rate (VBR) ATM VC uses sustained cell rate (SCR) to define the VCs average transmission
rate.
Example 15-2 oversubscribes an ATM interface by five times the physical transmission capacity.
Example 15-2 Oversubscribing an ATM VC
Router(config)# interface serial 1
Oversubscribing Frame Relay PVCs

To oversubscribe Frame Relay PVCs, perform one of the following configuration tasks:
Oversubscribing Frame Relay PVCs Using Hierarchical Policies, page 15-12
Oversubscribing Frame Relay PVCs Using a Map Class, page 15-15

OL-7433-09
15-11
Chapter 15
Oversubscribing Frame Relay PVCs Using Hierarchical Policies

For information about hierarchical policies, see Chapter 13, Defining QoS for Multiple Policy Levels.
To enable oversubscription of Frame Relay PVCs using hierarchical policies, enter the following
Step 1
Command
Purpose

configuration mode.
policy-map-name is the name of the policy map. The name
Step 2

define QoS actions.
Step 3

Note
In Cisco IOS Release 12.0(25)S and

Release 12.3(7)XI, and later releases, the priority
command has no arguments. To specify a bandwidth
rate, use the police command. For more
information, see Chapter 6, Policing Traffic.
15-12
OL-7433-09
Chapter 15

Step 4
Command
Purpose

percent bc normal-burst-in-msec
be excess-burst-in-msec [conform-action action
[exceed-action action [violate-action action]]]
(Optional) Configures traffic policing on the basis of a

percentage of bandwidth available on an interface.
(Optional) cir is the committed information rate (CIR) and
indicates an average rate at which the policer meters traffic.
CIR is based on the interface shape rate.
bandwidth specified in percent to calculate the CIR. Valid
bc normal-burst-in-msec specifies the normal or committed
burst size (CBS) that the first token bucket uses for policing
traffic. Specify the normal-burst-in-msec value in
milliseconds (ms). Valid values are from 1 to 2000. The
default value is the greater of 2 ms worth of bytes at the
police rate or the network minimum transmission unit
(MTU).
be excess-burst-in-msec specifies the excess burst size
(EBS) that the second token bucket uses for policing traffic.
Specify the excess-burst-in-msec value in milliseconds
(ms). Valid values are from 1 to 2000. The default value is
zero (0). You must specify normal-burst-in msec before you
specify excess-burst-in-msec.
Note
Burst in milliseconds is based on the policing

conform-action action is the action to take on packets that

conform to the rate limit. The default action is transmit. You
must specify a value for excess-burst-in-msec before you
specify the conform-action.
exceed-action action is the action to take on packets that
exceed the rate limit. The default action is drop. You must
specify the conform-action before you specify the
exceed-action.
violate-action action is an optional action that specifies the
action to take on packets that continuously exceed the rate
limit. The default action is the same as the exceed-action.
You must specify the exceed-action before you specify the
violate-action.
See Table 6-1 on page 6-3 for a description of each action
you can specify.
Note
Step 5
Repeat Step 2 through Step 4 to configure additional

traffic classes. For information about additional
actions you can specify, see the Types of QoS

OL-7433-09
15-13
Chapter 15
Step 6
Command
Purpose
Creates or modifies the parent policy map. Enters

Step 7
Configures the class-default traffic class. Enters policy-map

class configuration mode.
Step 8
Router(config-pmap-c)# shape rate

rate indicates the bit rate in bits per second that is used to
shape the traffic.
Step 9
policy-map-name
Applies the child policy map you specify to the parent

policy map.
policy-map-name is the name of the child policy map you
want to apply to the parent policy map.
Step 10
Step 11
Step 12


enable PVC oversubscription. Enters interface or
Step 13
Router(config-if)# ip address address
Sets an address for an interface.

address is the IP address.
Step 14

Applies the policy map you specify to the interface. This is

the parent policy map that you created in Step 7.
input indicates to apply the QoS policy to inbound packets.
output indicates to apply the QoS policy to outbound
packets.
policy-map-name is the name of the policy map you want to
apply to the interface.
Step 15
Router(config-subif)# frame-relay
interface-dlci dlci [ietf | cisco]
Assigns a data-link connection identifier (DLCI) or a PVC

to a Frame Relay interface or subinterface. Enters DLCI
configuration mode.
dlci is the DLCI number to be used on the specified
subinterface.
(Optional) cisco specifies to use Ciscos own Frame Relay
encapsulation, which is a 4-byte header, with 2 bytes to
identify the data-link connection identifier (DLCI) and 2
bytes to identify the packet type.
(Optional) ietf sets the encapsulation method to comply
with the Internet Engineering Task Force (IETF) standard
(RFC 1490). Use this keyword when connecting to another
vendors equipment across a Frame Relay network.
15-14
OL-7433-09
Chapter 15

Configuration Example for Oversubscribing Frame Relay PVCs Using Hierarchical Policies
Example 15-3 shows how to oversubscribe a Frame Relay T1 network using a hierarchical policy to
define QoS behavior. In the example, the traffic class named Gold is policed at 60 percent of the total
transmission capacity and the class named Bronze requests 30 percent of the total bandwidth. The child
policy named dlci50 that contains the Gold and Bronze classes is applied to the parent policy named
shape-rate. The parent policy applied to DLCI 50 and DLCI 100 on serial subinterface 5/0/0.1 shapes
each DLCI with a bandwidth of 1024 kbps or a total of 2048 kbps, which exceeds the transmission
capacity of the T1 network (1536 kbps).
Example 15-3 Configuring Frame Relay Oversubscription Using Hierarchical Policies
Router(config)# policy-map dlci50 [child policy]
Router(config)# policy-map shape-rate [parent policy]
Router(config-pmap-c)# service-policy dlci50 [child policy]
Router(config-if-dlci)# service-policy output shape-rate [attaches parent policy]
Router(config-if-dlci)# frame-relay interface-dlci 100
Router(config-if-dlci)# service-policy output shape-rate [attaches parent policy]
Oversubscribing Frame Relay PVCs Using a Map Class

To enable oversubscription of Frame Relay PVCs using a map class, enter the following commands
Step 1
Command
Purpose

configuration mode.
Step 2

Step 3

shape the traffic.
Step 4
Step 5

OL-7433-09
15-15
Chapter 15
Step 6
Command
Purpose
Router(config)# frame-relay map-class

map-class-name
Creates or modifies a Frame Relay map class. Enters Frame

Relay map-class configuration mode.
map-class-name is the name of the map class.
Step 7
Router(config-fr-mc)# service-policy {input |

Applies the policy map you specify to the Frame Relay map
class. This is the same policy map that you created in Step 1.
packets.
apply to the Frame Relay map class.
Step 8
Router(config-fr-mc)# exit
Exits Frame Relay map-class configuration mode.
Step 9


Step 10
Router(config-subif)# encapsulation frame-relay

[cisco | ietf]
Enables Frame Relay encapsulation on the subinterface.

(Optional) cisco specifies to use Ciscos own encapsulation,
which is a 4-byte header, with 2 bytes to identify the
data-link connection identifier (DLCI) and 2 bytes to
identify the packet type.
Step 11
Assigns a data-link connection identifier (DLCI) or a PVC

to a Frame Relay interface or subinterface. Enters DLCI
configuration mode.
dlci is the DLCI number to be used on the specified
subinterface. This is the DLCI to which you want to attach
the policy map you created in Step 1.
(Optional) cisco specifies to use Ciscos own encapsulation,
which is a 4-byte header, with 2 bytes to identify the
data-link connection identifier (DLCI) and 2 bytes to
identify the packet type.
Step 12
Router(config-if-dlci)# frame-relay class name
Associates a map class with a DLCI.

name is the name of a previously configured map class. This
is the same map class that you created in Step 6.
Note
Repeat Steps 11 and 12 for each DLCI to which you

want to associate the map class.
15-16
OL-7433-09
Chapter 15

Configuration Example for Oversubscribing Frame Relay PVCs Using a Map Class
Example 15-4 shows how to oversubscribe a T1 network with a capacity of 1536 kbps. In the example,
the policy map named Business shapes traffic to 1024 kbps. This QoS policy is applied to both PVCs
(100 and 101) configured on serial interface 1/0/0/1:0. Each PVC has 1024 kbps of bandwidth or a total
of 2048 kbps, which exceeds the capacity of the T1 network. Therefore, the PVCs are oversubscribed.
Alternatively, if each PVC had a bandwidth of 768 kbps or less, they would not be oversubscribed.
Example 15-4 Oversubscription of Frame Relay PVCs
Router(config)# frame-relay map-class Bronze
Router(config-map-c)# service-policy output Business
Router(config)# interface serial 1/0/0/1:0
Router(config-if)# encapsulation frame-relay
Router(config-if-dlci)# frame-relay class Bronze
Router(config-if-dlci)# frame-relay interface-dlci 101
Router(config-if-dlci)# frame-relay class Bronze
Oversubscribing 802.1Q VLANs

To enable oversubscription of 802.1Q VLANs, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose

configuration mode.
Step 2

define QoS actions.
Step 3

Note
In Cisco IOS Release 12.0(25)S and

Release 12.3(7)XI, and later releases, the priority
command has no arguments. To specify a bandwidth
rate, use the police command. For more
information, see Chapter 6, Policing Traffic.

OL-7433-09
15-17
Chapter 15
Step 4
Command
Purpose

percent bc normal-burst-in-msec {pir pir}
be excess-burst-in-msec [conform-action action
[exceed-action action [violate-action action]]]

percentage of bandwidth available on an interface.
indicates an average rate at which the policer meters traffic.
bandwidth specified in percent to calculate the CIR.
bc normal-burst-in-msec specifies the normal or committed
burst size (CBS) that the first token bucket uses for policing
traffic. Specify the normal-burst-in-msec value in
milliseconds (ms). Valid values are from 1 to 2000. The
default value is the greater of 2 ms worth of bytes at the
police rate or the network minimum transmission unit
(MTU).
be excess-burst-in-msec specifies the excess burst size
(EBS) that the second token bucket uses for policing traffic.
Specify the excess-burst-in-msec value in milliseconds
(ms). Valid values are from 1 to 2000. The default value is
zero (0). You must specify normal-burst-in msec before you
specify excess-burst-in-msec.
Note
Burst in milliseconds is based on the policing

conform-action action is the action to take on packets that

conform to the rate limit. The default action is transmit. You
must specify burst-excess before you specify the
conform-action.
exceed-action action is the action to take on packets that
exceed the rate limit, but not the PIR. The default action is
drop. You must specify the conform-action before you
specify the exceed-action.
(Optional) violate-action action is the action to take on
packets that continuously exceed the PIR rate limit. The
default action is the same as the exceed-action. You must
specify the exceed-action before you specify the
violate-action.
See Table 6-1 on page 6-3 for a description of each action
you can specify.
Note
Repeat Step 2 through Step 4 to configure additional

traffic classes. For information about additional
actions you can specify, see the Types of QoS
Step 5
Step 6
Creates or modifies the parent policy map. Enters

15-18
OL-7433-09
Chapter 15

Command
Purpose
Step 7

Step 8

shape the traffic.
Step 9
policy-map-name
Applies the child policy map you specify to the parent

policy map.
policy-map-name is the name of the child policy map you
want to apply to the parent policy map.
Step 10
Step 11
Step 12


Step 13
Router(config-if)# ip address address
Sets an address for an interface.

address is the IP address of the interface.
Step 14

vlanid
Enables IEEE 802.1Q encapsulation of traffic on a specified

subinterface in a virtual LAN (VLAN).
vlanid is the virtual LAN identifier. Valid values are from 1
to 4095.
Step 15

Attaches the policy map you specify to the VLAN on the

subinterface. This is the parent policy map that you created
in Step 7.
packets.
policy-map-name is the name of the parent policy map you
want to attach.

OL-7433-09
15-19
Chapter 15
How the Router Determines VC Weights
Configuration Example for Oversubscribing 802.1Q VLANs

Example 15-5 shows how to oversubscribe an 802.1Q VLAN. In the example, the Bronze business traffic
receives 30 percent of the configured shape rate and Gold priority receives 60 percent. The Business
child policy map is applied to the Business-shape parent policy map, which shapes the aggregate traffic
to 512,000 kbps. The Business-shape policy map attached to VLAN 4 and VLAN 2 shapes the aggregate
traffic of each VLAN to 512,000 kbps or a combined total of 1024 Mbps, which exceeds the transmission
capacity of the Gigabit Ethernet interface. Therefore, the VLANs are oversubscribed.
Example 15-5 Oversubscribing 802.1Q VLANs
Router(config)# policy-map Business [child policy]
Router(config-pmap)# bandwidth percent 30
Router(config-pmap-c)# set ip precedence 1 2
Router(config-pmap-c)# set dscp 50
Router(config)# policy-map Business-shape [parent policy]
Router(config-pmap-c)# service-policy Business [child policy]
Router(config)# interface GigabitEthernet 5/0/0.10 point-to-point
Router(config-subif)# service-policy output Business-shape [attaches parent policy]
Router(config-subif)# interface GigabitEthernet 5/0/0.2 point-to-point
Router(config-subif)3 service-policy output Business-shape [attaches parent policy]

On the PRE1 or PRE2, weight is applicable to VCs in VP tunnels and affects the behavior of the VCs.
On the PRE3, weight is applicable to VCs in VP tunnels and VCs not in a VP tunnel. In both cases, the
weight affects the behavior of the VCs.
The way in which the router determines the weight of a VC depends upon the Cisco IOS release running
on the router. Table 15-2 summarizes VC weighting on the Cisco 10000 series router.
Table 15-2
VC Weighting on the Cisco 10000 Series Router
Cisco IOS Release
User Configurable
VC Weight
Release 12.0(17)SL to Release 12.3(7)XI
No
Proportional to the VC speed.
Release 12.3(7)XI1 and later releases
Yes
Configured using the weight

command.
15-20
OL-7433-09
Chapter 15

Table 15-2
VC Weighting on the Cisco 10000 Series Router
Cisco IOS Release
User Configurable
VC Weight
Release 12.2(28)SB and later releases
Yes

command.
Release 12.2(31)SB2 and later releases
Yes

command or the bandwidth
remaining ratio command
(PRE3).
For information about VC weighting for a specific release, see the following sections:
Feature History for VC Weighting, page 15-21
Determining VC WeightingCisco IOS Release 12.0(17)SL to Release 12.3(7)XI1, page 15-21
Determining VC WeightingCisco IOS Release 12.3(7)XI1 and Later Releases, page 15-22
Determining VC WeightingCisco IOS Release 12.2(31)SB2 and Later Releases, page 15-22
Feature History for VC Weighting

Cisco IOS Release
Description
Required PRE
Release 12.3(7)XI1
The VC weighting feature was introduced on the PRE2.
PRE2
Release 12.2(28)SB

PRE2
Release 12.2(31)SB2
PRE3
Determining VC WeightingCisco IOS Release 12.0(17)SL to Release 12.3(7)XI1

In Cisco IOS Release 12.0(17)SL to Cisco IOS Release 12.3(7)XI1, the router determines the weight of
a particular VC in proportion to the speed of the VC. Without oversubscription, the router allocates
bandwidth to each VC, up to the VCs configured SCR. As a result, VCs with higher SCR values get
more bandwidth.
With oversubscription, the sum of the sustained cell rate (SCR) values of all of the VBR-nrt VCs is
greater than the rate of the interface. If all of an interfaces VCs attempt to send cells to the segmentation
and reassembly (SAR) mechanism of the router at a rate that exceeds their SCR values, bandwidth
calculation occurs in the following ways:
If all of the competing VCs have the same traffic class, the router calculates bandwidth by dividing
the line rate by the number of VCs.
If the competing VCs have differing SCR values, the router either allocates the same bandwidth to
each VC or it allocates more bandwidth to VCs with a higher SCR, depending on the load at a certain
point in time. Because of this, it is difficult to predict the exact bandwidth percentage each VC has.
The SAR mechanism does not drop any cells on the router after a packet is scheduled to it. If the
rate at which VCs send cells to the SAR mechanism exceeds the SAR mechanisms capability to
transmit, the queuing system stores and subsequently drops any excess packets and the ATM
interface driver controls the rate at which it sends packets to the SAR mechanism to avoid starving
the SAR mechanism of its internal buffers.

OL-7433-09
15-21
Chapter 15
Determining VC WeightingCisco IOS Release 12.3(7)XI1 and Later Releases

In Cisco IOS Release 12.3(7)XI1 and later releases, a weight parameter is used to control the number of
cells for each VC that is sent into the virtual path (VP). You can configure this weight parameter directly
for each VC using the weight command. This weight value determines which VCs get priority in the VP
schedules during a congested state.
The versatile time management scheduler (VTMS) shapes the VC rate and the SAR mechanism shapes
the VP rate. Even though the VTMS shapes the VC, the SAR mechanism controls the access of the VCs
to the VP. The SAR mechanism uses a round-robin between the VCs to send a given number of cells per
VC into the VP. The SAR mechanism uses the weight parameter you configure to control the number of
cells for each VC.
To be fully effective, you must set the SAR line card queue depth for each VC interface queue above the
weight for VC weighting by using the queue-depth command. This command enables you to set the high
watermark and low watermark, which define the depth of the VC interface queue. The optimum
threshold values for these watermarks are a function of a number of variables, such as the following:
Number of queues on a VC
Priority queue latency requirements
Bandwidth of the VC
Accuracy of VC bandwidth utilization
Per-queue bandwidth accuracy
Because so many variables influence watermark threshold values, you might need to experiment with
different values to determine the optimum high and low watermark values for your configuration. In
general, the following guidelines apply:
Set the low watermark equal to the VC weight. If the low watermark is less than the VC weight, a
full weight worth of cells might not be enqueued in the SAR mechanism when the scheduler
round-robin gets to the VC. As a result, the VC might not get its fair share.
Set the high watermark equal to the low watermark plus 2.
For more information about the high and low watermarks, see the High Watermark and Low Watermark
Default Values section on page 15-25.
Determining VC WeightingCisco IOS Release 12.2(31)SB2 and Later Releases

On the PRE3, the weight parameter is not only used to control the number of cells for each VC that is
sent into the virtual path (VP), but is also used by the packet scheduler to determine the bandwidth
allocation of the VC during congestion. When congestion occurs in a VP, the bandwidth of the VP is
distributed among the VCs within the VP tunnel in proportion to the weight configured on the VC. When
congestion occurs on an ATM port, the bandwidth of the port is distributed among the VCs in proportion
to the weight configured on the VC.
15-22
OL-7433-09
Chapter 15

Calculating the Default Weight of a VCPRE2

For the PRE2, the router calculates the default weight of a VC programmed in the segmentation and
reassembly (SAR) mechanism by using the following formulas:
Tunnel Speed
VC Speed
Weight Formula
5 MB or less
Greater than 1937 kbps
Weight = 255
All other VC speeds
Weight = 0.1316 * VC speed

The router limits the weight to a maximum of 255. If the calculation
results in a weight that is greater than 255, the router rounds down to
ensure a valid weight.
Greater than 5 MB
Less than 256 kbps
Weight = 0.0459 * VC speed + 3.25

The weight must be between 5 and 255. If the calculation results in a
weight that is not between 5 and 255, the router rounds up or down to
This formula is also used to calculate weight for VBR and CBR VCs.
The value of the SCR (VBR) or the value of the PCR (CBR) is the VC
speed used in the calculation.
Less than or equal to

4010 kbps
Weight = 0.0586 * VC speed
Greater than 4010 kbps
Weight = (20 / (Tunnel PCR 4010)) * VC speed + ((235 * Tunnel PCR

4010) / (Tunnel PCR 4010))
The router limits the weight to a maximum of 255. If the calculation
results in a weight that is greater than 255, the router rounds down to
Calculating the Default Weight of a VCPRE3

For the PRE3, the weight in the SAR mechanism is always programmed to the value 5. The weight of
the VC used in the packet scheduler is based on the committed information rate (CIR) of the VC.
If no weight is assigned to an ATM VC, a default weight is assigned based on the sustained cell rate
(SCR) rate of the VC. The algorithm first checks the VCs with no weight and determines the maximum
and minimum SCR. It then distributes a weight to each VC that is proportional to the VCs SCR. For
example, a VC with an SCR of 50 kbps has a weight that is twice that of a VC with an SCR of 25 kbps.
Note
Because it is not practical to configure weights on some ATM VCs and not on others, either all of the
VCs have VC weights configured or none of them do.
A default weight of 1 is given to non-ATM subinterfaces with no weight assigned to them.

OL-7433-09
15-23
Chapter 15
queue-depth Command
To configure the segmentation and reassembly (SAR) line card queue depth for each VC interface queue,
use the queue-depth command in ATM PVC configuration mode. To remove a queue-depth setting, use
the no form of the command. By default, no line card queue depth is set.
queue-depth hwm lwm
no queue-depth hwm lwm
Syntax Description
hwm
The high watermark.
lwm
The low watermark.
queue-depth Command History

Cisco IOS Release
Description
Release 12.3(7)XI1
The queue-depth command was introduced on the PRE2.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Usage Guidelines for the queue-depth Command

Configure the SAR line card queue depths for each VC above the weight you configure for the VC.
weight Command
To control virtual circuit (VC) bandwidth when the virtual path (VP) is congested, use the weight
command in PVC, PVC range, or ATM VC-class configuration mode. This command defines the weight
of a VC or changes the default weight. To restore the default weight, use the no form of the command.
weight weight_value
no weight weight_value
Syntax Description
weight_value
The number of cells that a VC can send to the VP tunnel before the SAR
mechanism moves on to the next VC. A high value has a high VC priority
in the VP scheduler. Valid values are from 1 to 255 (PRE2) and 1 to 1000
(PRE3).
Note
We recommend that you do not configure the weight_value below

10 (PRE2).
15-24
OL-7433-09
Chapter 15

weight Command History

Cisco IOS Release
Description
Release 12.3(7)XI1
The weight command was introduced on the PRE2.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Usage Guidelines for the weight Command

On the PRE2, for the weight command to be fully effective, use the queue-depth command to set the
segmentation and reassembly (SAR) line card queue depth for each VC interface queue above the VC
weight.
High Watermark and Low Watermark Default Values

On ATM line cards, the SAR mechanism has a queue for each PVC. Each PVC queue has two thresholds
associated with it called the high watermark and low watermark. These watermarks define the number
of cells the queue can hold.
The high and low watermark settings define the depth of the PVC interface queue on the line card.
Table 15-3 lists the default high and low watermark values for ATM variable bit rate (VBR) VCs, based
on the ATM VC rate.
Table 15-3
Default Watermark Values for ATM VBR VCs
VC Rate (bps)
Low Watermark
High Watermark
0 to 18,999
48
56
19,000 to 40,999
64
72
41,000 to 99,999
128
144
100,000 to 622,000
224
240
Table 15-4 lists the default high and low watermark values for ATM unspecified bit rate (UBR) VCs,
based on the ATM VC rate.
Table 15-4
Default Watermark Values for ATM UBR VCs
VC Rate (bps)
Low Watermark
High Watermark
0 to 18,999
224
240
The behavior of the high watermark threshold and the low watermark threshold depends on whether the
atm pxf queuing mode or the no atm pxf queuing mode is configured. In atm pxf queuing mode, the high
watermark is a threshold that triggers a flow-off signal and the low watermark is a threshold that triggers
a flow-on signal. The high watermark is the maximum number of cells that can be in the PVC queue for
the ATM SAR mechanism before a flow-off signal is sent to the PXF. With the exception of priority

OL-7433-09
15-25
Chapter 15
queue packets and system queue packets, the flow-off signal stops packets for this PVC from being sent
to the ATM SAR mechanism. Priority queue packets and system queue packets continue to be sent to the
line card. Packets for other classes are queued at the PXF.
If packets are being queued at the PXF because the flow-off signal has been sent, when the number of
cells in the PVC queue reaches the low watermark threshold, a flow-on signal is sent to the PXF. The
flow-on signal restarts the packet flow (for packets of all classes) from this PVC to the ATM SAR
mechanism.
For example, after router startup the flow signal defaults to on. If the number of cells in the PVC queue
for the ATM SAR mechanism is 50, the high watermark is 56, and the low watermark is 48, and packets
of all classes flow from the PVC to the ATM SAR mechanism. If the number of cells increases to 56, the
high watermark triggers the flow-off signal, which stops packet flow for all packets, except the priority
queue and system queue packets. Packet flow for all other packets is not restarted until the number of
cells decreases to 48 (for example, when the low watermark triggers the flow-on signal).
In no atm pxf queuing mode, the high watermark is the maximum number of cells that can be in the PVC
queue for the ATM SAR mechanism before packet drops occur. The low watermark does not apply in no
atm pxf queuing mode.
Note
While the high watermark threshold and low watermark threshold are defined by the numbers of cells,
the crossing of the high watermark is evaluated on a packet boundary. This means that only whole
packets are placed in the PVC queue for the ATM SAR mechanism.
When you want to better control priority queuing latency or for better TCP performance, modify the
watermark values for each ATM variable bit rate (VBR) VC by using the queue-depth command. For
more information, see the Configuring VC Queue Depth section on page 15-38.
Guidelines for Changing Watermark Values

If you need to change the watermark values, follow these guidelines:
For better VC utilization and accuracy, raise the low watermark value (and possibly the high
watermark value).
For better per-queue accuracy, increase the spread between the watermark values.
For better latency, decrease the high watermark value.
For a higher number of cells in the queue or for better TCP performance, increase the high
watermark value.
The high watermark can be calculated based on the worst-case latency, VC traffic speed, IP packet size,
and ATM encapsulation type used (PPPoE, PPPoA, RBE). The low watermark is typically 80 percent of
the high watermark. The following formula is used to calculate the high watermark:
High_water = ((max latency (ms) (max_pktsize / VC_speed) ms) * VC_speed) / (53 * 8)
where:
High_water is the high watermark.
max latency is the maximum latency in milliseconds (ms).
max_pktsize is the maximum packets size.
VC_speed is the VC rate.
The maximum packet size is calculated using the following formula:
15-26
OL-7433-09
Chapter 15

max_pksize = roundup ((ip framesize + encap_ovh) / 48) * 53 * 8

where:
ip framesize is the size of the IP frame.
encap_ovh is the encapsulation overhead.
For example, suppose that a VCs high and low watermark values need to be configured such that latency
is not greater than 100 ms. The VC uses PPPoEoA; the VC IP frame size is 256; and the VC bandwidth
is 512 kbps. With PPPoEoA, encapsulation overhead (encap_ovh) is 40 bytes.
Max_pksize = roundup ((256 + 40) / 48) * 53 * 8 = 7 * 53 * 8 = 2968
High_water = ((100 (ms) (2968 /512K) ms) * 512K) / (53 * 8)
= ((100 (ms) 5.8 ms) * 512K) / (53 * 8)
= 114
Low_water = 91 (80 percent of High_water)

In Cisco IOS Release 12.3(7)XI1, when you change the weight of a VC or the VP shaping parameters,
the SAR mechanism brings down the VC or VP and the session goes down.
In Cisco IOS Release 12.3(7)XI2 and later releases, you can change the VC weight, VP shaping
parameters, or VC shaping parameters without affecting the state of the VC or VP. Instead, the VC and
VP remain up and operational.
The dynamic parameters include the following:
ATM VP parameters such as peak cell rate (PCR) and cell delay variation tolerance (CDVT)
VC parameters such as weight, PCR, sustained cell rate (SCR), maximum burst size (MBS), and
CDVT
If VC members of a VP do not have a configured weight and you dynamically modify the VP rate, the
router dynamically adjusts the weight of the member VCs based on the associated tunnels new rate. The
member VCs remain up as their weights are dynamically modified.
If you dynamically modify the tunnel VCs shaping parameters (for example, the PCR or SCR), the
router adjusts the tunnel VCs weight based on the VC speed, if no weight is configured for the VC. If
a VC weight is configured, the router adjusts the tunnel VCs weight based on the configured weight.
Restrictions and Limitations for VC Weighting
(PRE2 only) A weight of less than 10 can adversely affect the performance of the ATM port. We
recommend that you do not use a weight that is less than 10.
When you change VC parameters or the VP rate, the VP tunnels effective shape rate can
momentarily fluctuate and cause the router to send cells at a rate that is over or under the configured
rates. The session stays up and no data is lost.
When dynamically modifying an ATM VP or VC configuration, you cannot dynamically change the
queue depth or the type of VC. For example, you cannot dynamically change a constant bit rate
(CBR) VC to a variable bit rate-nonreal time (VBR-nrt) VC.

OL-7433-09
15-27
Chapter 15
Configuring VC Weighting
To configure VC weighting, perform the following configuration tasks:
Configuring ATM VC Weighting, page 15-28
Configuring VC Weighting Using a VC Class Map, page 15-29
Configuring VC Weighting on a Range of PVCs, page 15-30
Configuring VC Weighting On Subinterfaces Using a Bandwidth Remaining Ratio, page 15-31
Configuring VC Weighting on Class Queues Using Bandwidth Remaining Ratio, page 15-34
Configuring VC Queue Depth, page 15-38
Configuring ATM VC Weighting

To configure ATM VC weighting, enter the following commands beginning in global configuration
mode:
Command
Purpose
Step 1

slot/subslot/port.subinterface point-to-point
Selects an ATM interface or subinterface. Enters interface

or subinterface configuration mode.
Step 2
Router(config-subif)# pvc vpi/vci
Selects an ATM PVC.

vpi/ is the virtual path identifier. If you do not specify a VPI
value and the slash character (/), the VPI value defaults to 0.
Step 3
Router(config-if-atm-vc)# weight weight-value
Specifies the weight value.

weight-value is the number of cells that a VC can send to
the VP tunnel before the SAR mechanism moves on to the
next VC. A high value has a higher VC priority in the VP
scheduler. Valid values are from 1 to 255 (PRE2) and 1 to
1000 (PRE3).
Note
We recommend that you do not configure the

weight_value below 10 (PRE2).
Configuration Example for Configuring ATM VC Weighting

Example 15-6 shows how to configure a weight of 10 for ATM PVC 1/32 on the ATM point-to-point
Example 15-6 Configuring ATM VC Weighting
Router(config-if-atm-vc)# weight 10
15-28
OL-7433-09
Chapter 15

Configuring VC Weighting Using a VC Class Map

To configure VC weighting using a VC class map, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
Router(config)# vc-class atm name
Defines a VC class.
name is the name of the VC class.
Step 2
Router(config-atm-vcc)# weight weight-value
weight_value is the number of cells that a VC can send to

scheduler. Valid values are from 1 to 255 and 1 to 1000
(PRE3).
Note

Step 3
Router(config-atm-vcc)# exit
Exits ATM VC class configuration mode.
Step 4

Selects an ATM subinterface. Enters subinterface

configuration mode.
Step 5
Selects an ATM PVC.

Step 6
Router(config-if-atm-vc)# class-vc vc-classname
Applies a VC class to the PVC.

vc-classname is the name of the VC class.
Configuration Example for Configuring VC Weighting Using a VC Class Map

Example 15-7 shows how to configure a weight of 20 on the VC class map named Business.
Example 15-7 Configuring VC Weighting Using a VC Class Map
Router(config)# vc-class atm Business
Router(config-atm-vcc)# weight 20
Router(config-atm-vcc)# exit
Router(config-if-atm-vc)# class-vc Business

OL-7433-09
15-29
Chapter 15
Configuring VC Weighting on a Range of PVCs

To configure VC weighting on a range of PVCs, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1

Selects an ATM subinterface. Enters subinterface

configuration mode.
Step 2
Router(config-subif)# range pvc start_vpi/vci

end_vpi/vci
Specifies an ATM PVC range.

start_vpi/vci specifies the first virtual path identifier/virtual
channel identifier pair in the PVC range.
end_vpi/vci specifies the last virtual path identifier/virtual
channel identifier pair in the PVC range.
Step 3
Router(config-if-atm-range)# weight
weight-value

weight_value is the number of cells that a VC can send to
scheduler. Valid values are from 1 to 255 and 1 to 1000
(PRE3).
Note

Configuration Example for Configuring VC Weighting on a Range of PVCs

Example 15-8 shows how to configure a weight of 255 on the PVCs in the range of 1/32 to 1/00.
Example 15-8 Configuring VC Weighting on a PVC Range
Router(config-if-atm-range)# weight 255
15-30
OL-7433-09
Chapter 15

Configuring VC Weighting On Subinterfaces Using a Bandwidth Remaining

Ratio
To configure VC weighting on a subinterface using a bandwidth remaining ratio, enter the following
Note
Step 1
You can apply bandwidth-remaining ratios to outbound subinterfaces only.
Command or Action
Purpose
Router(config)# policy-map child-policy-name

configuration mode.
Step 2


map.
Step 3
Router(config-pmap-c)# bandwidth bandwidth-kbps
Specifies the bandwidth, in kbps, to be allocated to this

traffic class.
bandwidth-kbps is the bandwidth in kilobits per second
(kbps).
Note
Repeat Steps 4 and 5 to configure additional traffic

classes.
Step 4
Step 5
Step 6
Router(config)# policy-map parent-policy-name

configuration mode.
Step 7

configuration mode.
Note

subinterface.

OL-7433-09
15-31
Chapter 15
Step 8
Command or Action
Purpose
Router(config-pmap-c)# bandwidth remaining

ratio ratio
Specifies the bandwidth-remaining ratio for the

subinterface.
platform-dependent.
Step 9
Router(config-pmap-c)# shape {average | peak}

cir [bc] [be]

specify.
per second (bps).
Step 10
child-policy-name
Note

Step 11
Step 12
15-32
OL-7433-09
Chapter 15

Step 13
Command or Action
Purpose

slot/module/port.subinterface [point-to-point |
multipoint]

1/0/0.1).
Step 14

output} parent-policy-name

traffic.
traffic.
The router shapes the subinterface traffic to the shaping rate
specified in the parent class-default class and applies the
QoS actions specified in the child policy to traffic matching
the traffic classes.
During periods of congestion, the router uses the
bandwidth-remaining ratio specified in the parent policy
map to allocate unused bandwidth on this subinterface
relative to other subinterfaces.
Configuration Example for Configuring VC Weighting on a Subinterface Using Bandwidth Remaining

Ratio
on the interface.
policy-map Child
class precedence_0
bandwidth 100
class precedence_1
bandwidth 10000
!
policy-map Parent
class class-default
!
ip address 10.20.1.1 255.255.255.0
pvc 0/200

OL-7433-09
15-33
Chapter 15
vbr-nrt 50000
Note
The following example shows how to configure bandwidth-remaining ratios on an Ethernet subinterface
using a hierarchical policy. In the example, Gigabit Ethernet subinterface 1/0/0.1 is shaped to 100 Mbps.
During congestion, the router uses the bandwidth-remaining ratio of 10 to determine the amount of
excess bandwidth (unused by priority traffic) to allocate to the non-priority traffic on
subinterface 1/0/0.1, relative to the other subinterface-level and class-level queues on the interface.
policy-map Child
class precedence_0
bandwidth 10000
class precedence_1
bandwidth 100
!
policy-map Parent
class class-default
!
ip address 10.1.0.1 255.255.255.0
Configuring VC Weighting on Class Queues Using Bandwidth Remaining Ratio

To configure VC weighting on a class queue using a bandwidth remaining ratio, enter the following
Step 1
Command or Action
Purpose
Router(config)# policy-map child-policy-name

configuration mode.
Step 2

map.
15-34
OL-7433-09
Chapter 15

Step 3
Command or Action
Purpose

cir [bc] [be]

specify.
per second (bps).
Step 4

ratio ratio

traffic class.
platform-dependent.
The router makes no distinction between interface types at
the class level when using the default bandwidth-remaining
ratio. On the Cisco 10000 series router the default
bandwidth-remaining ratio value is 1.
Note
Repeat Steps 5 and 6 for each class queue you want

to define.
Step 5
Step 6
Step 7
Router(config)# policy-map parent-policy-name

configuration mode.
Step 8

configuration mode.
Note
Step 9

cir [bc] [be]

subinterface.
Shapes the average or peak rate to the rate you specify.

per second (bps).

OL-7433-09
15-35
Chapter 15
Step 10
Command or Action
Purpose

ratio ratio

subinterface.
platform-dependent.
Step 11
child-policy-name
Note

Step 12
Step 13
Step 14

multipoint]

1/0/0.1).
Step 15

output} parent-policy-name

traffic.
traffic.
Note
When congestion occurs, the class queues receive

bandwidth according to the specified class-level
bandwidth-remaining ratios.
15-36
OL-7433-09
Chapter 15

Configuration Example for VC Weighting on a Class Queue Using Bandwidth Remaining Ratio
class precedence_0
class precedence_1
class precedence_2
!
class class-default
!
class class-default
!
!
!

OL-7433-09
15-37
Chapter 15
Configuring VC Queue Depth

To configure the queue depth of a VC, enter the following commands beginning in global configuration
mode:
Command
Purpose
Step 1

Selects an ATM subinterface.
Step 2
Selects an ATM PVC.

Step 3
Router(config-if-atm-vc)# queue-depth hwm lwm
Defines the queue-depth size by setting the high and low

watermarks.
hwm is the high watermark.
lwm is the low watermark.
For information about the default high and low watermark
values, see the High Watermark and Low Watermark
Default Values section on page 15-25.
Configuration Example for Configuring VC Queue Depth

Example 15-9 shows how to set the high watermark to 10 and the low watermark to 8 on PVC 1/32 on
the ATM point-to-point subinterface 1/0/0.1.
Example 15-9 Configuring VC Queue Depth
Router(config)# interface atm 1/0/0/.1 point-to-point
Router(config-if-atm-vc)# queue-depth 10 8
Configuration Example for Oversubscribing a Shaped ATM VC and VP, page 15-39
Configuration Example for Configuring the Weight of a VC, page 15-39
Configuration Example for Configuring the Weight of Multiple VCs, page 15-40
Configuration Example for Configuring VC Weight Using a Bandwidth Remaining Ratio,

page 15-40
Configuration Example for Setting High and Low Watermark Thresholds, page 15-41
15-38
OL-7433-09
Chapter 15

Configuration Example for Oversubscribing a Shaped ATM VC and VP

Example 15-10 shows how to oversubscribe a shaped ATM VC and VP.
Example 15-10 Oversubscribing an ATM Interface
Router(config-if)# no ip address
(The following command sets up the flow bits to optimize latency and per-VC utilization factors. Also sets the system
up for Call Admission Control.)
Router(config-if)# atm sonet stm-4
!
(The following command sets up the permanent virtual path (PVP). This is ALWAYS done at the main interface level.
It is important to note the PVP number as this is used to determine which VCs will be mapped into this PVP. The PVP
number translates to a VPI value at the VC level.)
Router(config-if)# atm pvp 68 1000 no-f4-oam
!
Router(config-subif)# atm pppatm passive
(The following VPI value of 68 ensures that these VCs will be associated with PVP 68.)
(The following command sets up VTMS scheduling on PXF. Packets are sent down a 512-kbps VC to the SAR
mechanism. Remember this is SHAPING (not policing) the VC. Note that the modular CLI shape command is not
used.)
Router(config-if-atm-range)# vbr-nrt 512 38 150
!
Router(config-if-atm-range)# encapsulation aal5autoppp Virtual-Template1
!
Router(config-if)# no ip directed-broadcast
Router(config-if)# no logging event link-status
Router(config-if)# keepalive 120
Router(config-if)# peer default ip address pool adsl
Router(config-if)# ppp authentication chap callin
Configuration Example for Configuring the Weight of a VC

Example 15-11 shows how to configure the weight for an individual VC. This weight value determines
which VCs get priority in the VP schedules in a congested state. In the example, a weight of 10 is
configured for PVC 1/32 on ATM subinterface 1/0/0.1.
Example 15-11 Configuring the Weight of an Individual VC

OL-7433-09
15-39
Chapter 15
Configuration Example for Configuring the Weight of Multiple VCs

Example 15-12 shows how to configure the weight for multiple PVCs. In the example, each PVC has the
same sustained cell rate (SCR), but has different weights configured. The PVCs with the higher weights
get higher priority in the VP scheduler. Therefore, the PVCs in the range of 1/40 to 1/60 with a weight
of 40 have higher priority than the other configured PVCs:
PVC 1/34 with a weight of 30
Example 15-12 Configuring the Weight of Multiple VCs

Router(config-if-atm-vc)# exit
Router(config-subif)# interface atm 1/0/0.2 point-to-point
Router(config-if-atm-range)# vbr-nrt 1024 512
Router(config-if-atm-range)# weight 40
Configuration Example for Configuring VC Weight Using a Bandwidth

Remaining Ratio
Example 15-13 shows how to configure VC weight using a bandwidth remaining ratio. In the example,
the bandwidth remaining ratio command is configured in an hierarchical policy to assign a weight of
100 to the VC.
Example 15-13 Configuring VC Weight Using a Bandwidth Remaining Ratio
interface atm 2/0/4.1801 point-to-point
ip address 10.18.100.1 255.255.255.0
pvc 18/100
vbr-nrt 100 100 50
service-policy output myParentPolicy
!
Policy Map myParentPolicy
Class class-default
cir 25%
service-policy myChildPolicy
!
15-40
OL-7433-09
Chapter 15

Verifying Oversubscription and VC Weighting
Policy Map myChildPolicy

Class prec0
police 4000000 9216
drop
priority level 1
Class prec1
police 4000000 9216
drop
priority level 2
Class prec2
bandwidth remaining
Class prec3
bandwidth remaining
0 conform-action transmit exceed-action drop violate-action
0 conform-action transmit exceed-action drop violate-action
ratio 10
ratio 20
Configuration Example for Setting High and Low Watermark Thresholds

Example 15-14 shows how to set the high and low watermark thresholds for PVC 1/32 on the ATM
subinterface 1/0/0.10. In the example, the high watermark is set to 20 and the low watermark is set to 16.
Example 15-14 Setting High and Low Watermark Thresholds
Router(config-if-atm-vc)# queue-depth 20 16

To verify a virtual circuit oversubscription or weighting configuration, enter any of the following
commands in privileged EXEC mode:
Command
Purpose
Router# show atm class-links {vpi/vci | name}
Displays virtual circuit (VC) parameter configurations and

where the parameter values are inherited from.
name is the name of the VC.
Router# show atm interface interface
Displays the configuration of the interface you specify,

including the default high and low watermark values.
Router# show atm pvc vpi/vci
Displays the high and low watermarks for the individual PVC
that you specify.
Router# show controllers interface
Displays the total subscribed rate of all VCs on the port.

OL-7433-09
15-41
Chapter 15
Command
Purpose
Router# show interfaces type number

Displays information about the interface you specify.

Displays the contents of the currently running configuration

file.
Router# show running-config [interface type number]
Displays the configuration for a specific interface.
Router# show vlans
Displays the configuration of virtual LAN subinterfaces.
Verification Examples for Oversubscription and VC Weighting

This section provides the following examples for verifying oversubscription and VC weighting
configurations:
Verifying Default High and Low Watermarks on an Interface, page 15-42
Verifying High and Low Watermarks on an Individual VC, page 15-43
Verifying VC Parameter Configurations and Parameter Inheritance, page 15-43
Verifying Default High and Low Watermarks on an Interface

Example 15-15 shows how to use the show atm interface command to display the default high and low
watermark values for ATM interface 1/0/0. In the example, the asterisk (*) indicates aggregated VC
settings.
Example 15-15 Verifying Default High and Low Watermarks on an Interface
Router# show atm interface atm1/0/0
Interface ATM1/0/0:
AAL enabled: AAL5 , Maximum VCs: 8191, Current VCCs: 2
Max. Datagram Size: 4482
PLIM Type: SONET - 155000Kbps, TX clocking: LINE
Cell-payload scrambling: ON
sts-stream scrambling: ON
238276 input, 98 output, 0 IN fast, 0 OUT fast
Avail bw = 155000
Config. is ACTIVE
Default Queue Depth settings:
Rate Range
High Watermark
Low Watermark
Kbps
Cells
Cells
0 - 4499
192
128
4500 - 40999
256
256
41000 - 99999
256
256
100000 - 622000
256
256
149760 - 149760* 240
224
15-42
OL-7433-09
Chapter 15

Verifying High and Low Watermarks on an Individual VC

Example 15-16 shows how to use the show atm pvc command to display high and low watermarks for
PVC 1/32.
Example 15-16 Verifying High and Low Watermarks on an Individual VC
Router# show atm pvc 1/32
ATM1/0/0.1: VCD: 1, VPI: 1, VCI: 32
UBR, PeakRate: 149760 (353208 cps)
CDVT: 714.0 Usecs, High Watermark: 192, Low Watermark: 128
AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0, Encapsize: 12
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC Status: Not Managed
ILMI VC status: Not Managed
InARP frequency: 15 minute(s)
High Watermark: 192, Low Watermark: 128
InPkts: 475877, OutPkts: 475512, InBytes: 33317105, OutBytes: 33287714
InPRoc: 238299, OutPRoc: 98, Broadcasts: 0
InFast: 0, OutFast: 0
InPktDrops: 0, OutPktDrops: 0
Out CLP=1 Pkts: 0
OAM cells received: 0
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 0
OAM cells sent: 0
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutRDI: 0
OAM cell drops: 0
Status: UP
PPPOE enabled. Current number of pppoe sessions: 1
Verifying VC Parameter Configurations and Parameter Inheritance

Example 15-17 uses the show atm class-links command to display virtual circuit (VC) parameter
configurations and from where the parameter values are inherited.
Example 15-17 Verifying VC Parameter Configurations and Parameter Inheritance
Router# show atm class-links 1/32
Displaying vc-class inheritance for ATM1/0/0.1, vc 1/32:
no broadcast encapsulation - VC-class configured on vc
no ilmi manage inarp 15 no oam-pvc manage protocol ip inarp no broadcast protocol ipx inarp no broadcast protocol ppp Virtual-Template1 - VC-class configured on vc
ubr no cdvt queue depth high watermark 96 low watermark 80 - VC-class configured on vc

OL-7433-09
15-43
Chapter 15
Feature
Documentation
Hierarchical policies

Line card and VC configuration
PVC autoprovisioning
Cisco 10000 Series Broadband Aggregation and Leased-Line

Configuration Guide
Configuring ATM Permanent Virtual Circuit Autoprovisioning
15-44
OL-7433-09
CH A P T E R
16
Fragmenting and Interleaving Real-Time and

Nonreal-Time Packets
Integrating delay-sensitive real-time traffic with nonreal-time data packets on low-speed links can cause
the real-time packets to experience long queuing delays while waiting for the larger nonreal-time packets
to transmit. Real-time traffic, however, cannot tolerate delay. The challenge becomes how to integrate
real-time and nonreal-time packets while reducing latency for the real-time packets. The Cisco 10000
series router addresses this by breaking larger data packets into fragments and interleaving the smaller
real-time packets between the fragments. In this way, time-sensitive real-time traffic remains intact and
does not experience excessive delay.
This chapter describes fragmentation and interleaving on the Cisco 10000 series router. It includes the
following topics:
Link Fragmentation and Interleaving, page 16-1
Multilink PPP-Based Link Fragmentation and Interleaving, page 16-11
FRF.12 Fragmentation, page 16-37
Configuration Examples for Link Fragmentation and Interleaving, page 16-59
Verifying and Monitoring Link Fragmentation and Interleaving, page 16-65

Link fragmentation and interleaving (LFI) is a method that allows long nonreal-time data packets to be
fragmented into smaller frames and shorter real-time packets to be interleaved between the fragments.
In this way, real-time delay-sensitive packets, such as voice over IP (VoIP), and nonreal-time
delay-insensitive packets, such as data transfer, can be carried together on low-speed links without
causing excessive delay to the real-time traffic.
Real-time delay-sensitive traffic becomes susceptible to increased latency when the network processes
nonreal-time delay-insensitive packets. Long queuing delays can occur while real-time traffic waits for
the nonreal-time packet to be transmitted. Therefore, controlling the maximum one-way end-to-end
delay for time-sensitive traffic becomes challenging when integrating voice and data traffic.

OL-7433-09
16-1
Chapter 16
An important part of delay is the time it takes to actually place the bits onto an interface, referred to as
serialization delay. We recommend that serialization delay not exceed 20 ms. Serialization delay is
calculated using the following formula:
Serialization Delay = Frame Size (bits) / Link Bandwidth (bps)
As shown in Figure 16-1, a nonreal-time data packet of 1500 bytes takes 214 ms to leave the router over
a 56-kbps link. While waiting for the large data packet to transmit, the router queues real-time packets.
However, real-time traffic cannot tolerate delay. For example, good voice quality requires delay to be
less than 150 ms. By fragmenting the nonreal-time large data packet into smaller frames and interleaving
real-time packets between the fragments, both real-time packets and data frames can be carried together
on low-speed links, without causing excessive delay to the real-time traffic.
Figure 16-1
Integrating Voice and Data Packets on Low-Speed Links
Before
Voice
Data
214-ms serialization delay
for 1500-byte frame at 56 kbps
Data
Data
Voice
Data
40822
After
The Cisco 10000 series router supports the following types of link fragmentation and interleaving (LFI):
MLP over Serial-based LFIUses the fragmentation and interleaving capability of MLP to
integrate real-time packets (such as voice packets) and nonreal-time packets (such as data transfers)
on the same link while reducing real-time packet latency. MLP defines the mechanisms to fragment,
reassemble, and sequence large datagrams across multiple logical data links. MLP over serial-based
LFI supports up to 10 member links per MLP bundle, one of which is LFI-enabled. You can
terminate the serial links on multiple line cards in the router chassis if all of the links are the same
type, such as T1 or E1. The router supports subrate T1 interfaces as member links. The link speeds
must be the same for all of the links in the bundle.
Single-VC MLP over ATM-based LFIUses the fragmentation and interleaving capability of MLP
to integrate real-time and nonreal-time packets together on the same link. MLP defines the
mechanisms to fragment, reassemble, and sequence large datagrams across multiple logical data
links. MLP uses the fragmentation and packet sequencing specifications defined in RFC 1990 to
implement link fragmentation and interleaving at the bundle level. Single-VC MLP over ATM-based
LFI supports only one member link per MLP bundle and the link is LFI-enabled.
Multi-VC MLP over ATM-based LFIUses the fragmentation and interleaving capability of MLP
to integrate real-time packets and nonreal-time packets on the same link while reducing real-time
packet latency. MLP implements link fragmentation and interleaving at the bundle level. Multi-VC
MLP over ATM-based LFI supports up to 10 member links, one of which is LFI-enabled.
16-2
OL-7433-09
Chapter 16

MLP over Frame Relay-based LFIUses the fragmentation and interleaving capability of MLP to
transport real-time traffic (for example, voice) and nonreal-time traffic (for example, data transfers)
together on low-speed Frame Relay permanent virtual circuits (PVCs) without causing excessive
delay to the real-time traffic. MLP uses the fragmentation and packet sequencing specifications
defined in RFC 1990 to implement link fragmentation and interleaving at the bundle level.
MLP over Frame Relay-based LFI supports only one member link per MLP bundle and the link is
LFI-enabled.
FRF.12 FragmentationUses Frame Relay Forum FRF.12-based fragmentation on Frame Relay

permanent virtual circuits (PVCs) to allow long, nonreal-time data packets to be broken into smaller
fragments and shorter real-time packets to be interleaved between the fragments. In this way,
real-time and nonreal-time packets can be carried together on low-speed links without causing
excessive delay to the real-time traffic. The real-time packets remain intact and are less likely to
experience long queuing delays.
Feature History for Link Fragmentation and Interleaving

Cisco IOS Release
Description
Required PRE
Release 12.0(23)SX
The PVC-based FRF.12 Fragmentation feature and the

PRE1
MLP over Serial-based LFI feature were introduced on the
router.
Release 12.0(27)S
The FRF.12 Fragmentation feature was enhanced to enable PRE1

interface-based FRF.12 fragmentation.
Release 12.2(27)SBB
The following features were introduced on the PRE2: MLP PRE2

over Serial-based LFI, MLP over Frame Relay-based LFI,
Single-VC and Multi-VC MLP over ATM-based LFI, and
PVC-based and Interface-based FRF.12 Fragmentation.
Release 12.2(31)SB2
The following features were introduced on the PRE3: MLP PRE3

over Serial-based LFI, MLP over Frame Relay-based LFI,
Single-VC and Multi-VC MLP over ATM-based LFI, and
PVC-based and Interface-based FRF.12 Fragmentation.

OL-7433-09
16-3
Chapter 16
System Limits for Link Fragmentation and Interleaving

Table 16-1 lists the system limits for link fragmentation and interleaving (LFI).
Table 16-1
System Limits for Link Fragmentation and Interleaving
Maximum No.
of Members
Per Bundle
Maximum No. Maximum No. of

of Bundles
Member Links
Per System
Per System
MLP over Serial-based

LFI
10
1250
2500
1 to 9999
Yes
(Release12.2(28)SB and
Interleaving on 1
later)
member link
1 to 9999 and 65,536 to
2,147,483,647 (Release
12.2(31)SB2 and later)
Single-VC MLP over

ATM-based LFI
8192
8192
10,000 and higher
Multi-VC MLP over

ATM-based LFI
10
1250
2500
1 to 9999
Yes
(Release12.2(28)SB and
Interleaving on 1
later)
member link
1 to 9999 and 65,536 to
2,147,483,647
(Release 12.2(31)SB2
and later)
MLP over Frame

Relay-based LFI
2048
2048
10,000 and higher
FRF.12 Fragmentation
NA
Feature
Note
Multilink Interface
Range
LFI
Supported
Yes
Interleaving on 1
member link
Yes
Interleaving on 1
member link
NA
4096
NA
Yes
The multilink interface ranges described in Table 16-1 require Cisco IOS Release 12.2(28)SB and later
releases. For releases prior to Cisco IOS Release 12.2(28)SB, the valid multilink interface range is
1 to 2,147,483,647.
16-4
OL-7433-09
Chapter 16

Configuration Commands for MLP-Based Fragmentation and Interleaving

The following commands are used to configure Multilink PPP (MLP)-based fragmentation and
interleaving:
interface multilink Command, page 16-5
ppp multilink Command, page 16-6
ppp multilink fragment-delay Command, page 16-7
ppp multilink interleave Command, page 16-8
ppp multilink fragmentation Command, page 16-8
ppp multilink fragment disable Command, page 16-9
ppp multilink group Command, page 16-10
interface multilink Command

To create and configure a multilink bundle, use the interface multilink command in global configuration
mode. To remove a multilink bundle, use the no form of the command. By default, no multilink
interfaces are configured.
interface multilink multilink-bundle-number
no interface multilink multilink-bundle-number
Syntax Description
multilink-bundle-number
A nonzero number that identifies the multilink bundle.
interface multilink Command History

Cisco IOS Release
Description
Release 12.0
The interface multilink command was introduced on the PRE1.
Release 12.2(16)BX
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
The range of valid values for multilink interfaces was changed from 1 to
9999 (Release 12.2(28)SB and later) to from 1 to 9999 and 65,536 to
2,147,483,647 for MLP over serial and multi-VC MLP over ATM.
Usage Guidelines for the interface multilink Command

The following describes the range of valid values for multilink interfaces:
MLP over Serial-based LFI

1 to 9999 (Cisco IOS Release 12.2(28)SB and later releases)
1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)
Single-VC MLP over ATM-based LFI

10,000 and higher (Cisco IOS Release 12.2(28)SB and later releases)

OL-7433-09
16-5
Chapter 16
Multi-VC MLP over ATM-based LFI

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2 and later releases)
MLP over Frame Relay-based LFI

10,000 and higher
For releases prior to Cisco IOS Release 12.2(28)SB, the valid multilink interface range is 1 to
2,147,483,647.
ppp multilink Command

To enable Multilink PPP (MLP) on an interface, use the ppp multilink command in interface
configuration mode. To disable MLP, use the no form of the command. By default, the command is
disabled.
ppp multilink
no ppp multilink
ppp multilink Command History

Cisco IOS Release
Description
Release 12.0(23)SX
The ppp multilink command was introduced on the PRE1.
Release 12.2(16)BX
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Usage Guidelines for the ppp multilink Command

The ppp multilink command applies only to interfaces that use Point-to-Point Protocol (PPP)
encapsulation.
When you use the ppp multilink command, the first channel negotiates the appropriate Network Control
Protocol (NCP) layers (such as the IP Control Protocol and IPX Control Protocol), but subsequent links
negotiate only the Link Control Protocol (LCP) and MLP.
16-6
OL-7433-09
Chapter 16

ppp multilink fragment-delay Command

To specify a maximum size in units of time for packet fragments on a Multilink PPP (MLP) bundle, use
the ppp multilink fragment-delay command in interface configuration mode. To reset the maximum
delay to the default value, use the no form of the command. By default, if fragmentation is enabled, the
fragment delay is 30 milliseconds.
ppp multilink fragment-delay delay-max
no ppp multilink fragment-delay delay-max
Syntax Description
delay-max
Specifies the maximum amount of time, in milliseconds, that is required to

transmit a fragment. Valid values are from 1 to 1000 milliseconds.
ppp multilink fragment-delay Command History

Cisco IOS Release
Description
Release 12.0(23)SX
The ppp multilink fragment-delay command was introduced on the PRE1.
Release 12.2(16)BX
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Usage Guidelines for the ppp multilink fragment-delay Command

The ppp multilink fragment-delay command is useful when packets are interleaved and traffic
characteristics such as delay, jitter, and load balancing must be tightly controlled.
MLP chooses a fragment size on the basis of the maximum delay allowed. If real-time traffic requires a
certain maximum boundary on delay, using the ppp multilink fragment-delay command to set that
maximum time can ensure that a real-time packet gets interleaved within the fragments of a large packet.
By default, MLP has no fragment size constraint, but the maximum number of fragments is constrained
by the number of links. If interleaving is enabled, or if the bundle contains links that have differing
bandwidths, or if a fragment delay is explicitly configured with the ppp multilink fragment-delay
command, then MLP uses a different fragmentation algorithm. In this mode, the number of fragments is
unconstrained, but the size of each fragment is limited to the fragment-delay value, or 30 milliseconds
if the fragment delay has not been configured.
The ppp multilink fragment-delay command is configured under the multilink interface. The value
assigned to the delay-max argument is scaled by the speed at which a link can convert the time value into
a byte value.

OL-7433-09
16-7
Chapter 16
ppp multilink interleave Command

To enable interleaving of real-time packets among the fragments of larger nonreal-time packets on a
Multilink PPP (MLP) bundle, use the ppp multilink interleave command in interface configuration
mode. To disable interleaving, use the no form of the command. By default, interleaving is disabled.
ppp multilink interleave
no ppp multilink interleave
ppp multilink interleave Command History

Cisco IOS Release
Description
Release 12.0(23)SX
The ppp multilink interleave command was introduced on the PRE1.
Release 12.2(16)BX
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Usage Guidelines for the ppp multilink interleave Command

The ppp multilink interleave command applies to multilink interfaces, which are used to configure a
bundle.
Interleaving works only when the queuing mode on the bundle is set to fair queuing.
If interleaving is enabled when fragment delay is not configured, the default delay is 30 milliseconds.
The fragment size is derived from that delay, depending on the bandwidths of the links.
ppp multilink fragmentation Command

To enable packet fragmentation, use the ppp multilink fragmentation command in interface
configuration mode. To disable fragmentation, use the no form of the command. By default,
fragmentation is enabled.
ppp multilink fragmentation
no ppp multilink fragmentation
ppp multilink fragmentation Command History

Cisco IOS Release
Description
Release 12.0(23)SX
The ppp multilink fragmentation command was introduced on the PRE1.
Release 12.2(16)BX
Release 12.2
The no ppp multilink fragmentation command was changed to

ppp multilink fragment disable. The no ppp multilink fragmentation
command is recognized and accepted through Cisco IOS Release 12.2.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
16-8
OL-7433-09
Chapter 16

ppp multilink fragment disable Command

To disable packet fragmentation, use the ppp multilink fragment disable command in interface
configuration mode. To enable fragmentation, use the no form of this command.
ppp multilink fragment disable
no ppp multilink fragment disable
ppp multilink fragment disable Command History

Cisco IOS Release
Description
Release 11.3
This command was introduced as ppp multilink fragmentation.
Release 12.2
The no ppp multilink fragmentation command was changed to

ppp multilink fragment disable. The no ppp multilink fragmentation
command was recognized and accepted through Cisco IOS Release 12.2.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
Usage Guidelines for the ppp multilink fragment disable Command

The ppp multilink fragment delay and ppp multilink interleave commands have precedence over the
ppp multilink fragment disable command. Therefore, the ppp multilink fragment disable command
has no effect if these commands are configured for a multilink interface and the following message
displays:
Warning: 'ppp multilink fragment disable' or 'ppp multilink fragment maximum' will be
ignored, since multilink interleaving or fragment delay has been configured and have
higher precedence.
To completely disable fragmentation, you must do the following:

Router(config-if)# no ppp multilink fragment delay
Router(config-if)# no ppp multilink interleave
Router(config-if)# ppp multilink fragment disable

OL-7433-09
16-9
Chapter 16
ppp multilink group Command

To restrict a physical link to joining only a designated multilink group interface, use the ppp multilink
group command in interface configuration mode. To remove the restriction, use the no form of the
command. By default, this command is disabled.
ppp multilink group group-number
no ppp multilink group group-number
Syntax Description
group-number
Identifies the multilink group. This number must be identical to the

multilink-bundle-number you assigned to the multilink interface. Valid
values are:

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release
12.2(31)SB2 and later releases)

10,000 and higher

1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS Release
12.2(31)SB2 and later releases)

10,000 and higher
ppp multilink group Command History

Cisco IOS Release
Description
Release 12.0
The ppp multilink group command was introduced on the PRE1 as

multilink-group command.
Release 12.2
The multilink-group command was changed on the PRE2 to ppp multilink

group. The multilink-group command was accepted by the command line
interpreter through Cisco IOS Release 12.2.
Release 12.2(28)SB
PRE2.
Release 12.2(31)SB2
16-10
OL-7433-09
Chapter 16

Multilink PPP-Based Link Fragmentation and Interleaving
Usage Guidelines for the ppp multilink group Command

By default the ppp multilink group command is disabled, which means the link can negotiate to join
any bundle in the system.
When the ppp multilink group command is configured, the physical link is restricted from joining any
but the designated multilink group interface. If a peer at the other end of the link tries to join a different
bundle, the connection is severed. This restriction applies when MLP is negotiated between the local end
and the peer system. The link can still come up as a regular PPP interface.

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 slow links within the WAN. To solve delay
problems on slow bandwidth links, the router supports link fragmentation and interleaving (LFI) based
on the Cisco implementation of Multilink PPP (MLP), which supports the fragmentation and
packet-sequencing specifications in RFC 1990.
LFI allows reserve queues to be set up so that Real-Time Transport Protocol (RTP) streams can be
mapped into a higher priority queue.
As shown in Figure 16-2, without fragmentation and interleaving nonreal-time data packets can
overwhelm real-time packets such as voice. However, when fragmentation and interleaving is enabled,
bandwidth is shared equitably between nonreal-time packets and real-time packets.
Voice
Fragmenting and Interleaving Packets
Data
Voice
Without LFI, data can
overwhelm voice
Voice
Data
Data
With LFI, bandwidth
is equitably shared
to reduce voice jitter
132419
Figure 16-2
MLP fragmentation allows large packets to be multilink encapsulated and fragmented into a small
enough size to satisfy the delay requirements of real-time traffic. MLP fragmentation is enabled by
default. To disable fragmentation, use the no ppp multilink fragmentation or ppp multilink fragment
disable command.
Small real-time packets are not multilink encapsulated. MLP interleaving provides a special transmit
queue (priority queue) for delay-sensitive packets to allow the packets to be sent earlier than other packet
flows. Real-time packets remain intact and are sent (interleaved) between the fragments of the larger
packets.

OL-7433-09
16-11
Chapter 16
The router supports MLP-based fragmentation and interleaving on serial, Frame Relay, and ATM links.
For information on how MLP works and MLP-based LFI, see the following sections:
How MLP-Based LFI Works, page 16-12
MLP Over Serial-Based LFI, page 16-13
Single-VC MLP Over ATM-Based LFI, page 16-14
Multi-VC MLP Over ATM-Based LFI, page 16-19
MLP Over Frame Relay-Based LFI, page 16-21
How MLP-Based LFI Works

To understand how MLP-based LFI 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 queuing delays for small real-time packets exist regardless of the use of QoS features such
as weighted fair queuing (WFQ), and the 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
queuing 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.
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.
16-12
OL-7433-09
Chapter 16

MLP Over Serial-Based LFI

MLP over serial-based LFI uses the fragmentation and interleaving capability of MLP to integrate
real-time packets (such as voice packets) and nonreal-time packets (such as data transfers) on the same
link while reducing real-time packet latency.
MLP allows you to bundle T1 interfaces into logical groups. As indicated in Figure 16-3, you can
configure a MLP bundle with up to 10 T1 links. Using MLP, you can create a degree of redundancy by
configuring a MLP bundle that is made up of T1 links from more than one line card. If one line card
stops operating, the part of the bundle on other line cards continues to operate.
Figure 16-3 shows a MLP bundle that consists of T1 interfaces from three T3 interfaces.
Figure 16-3
MLP Bundle
You can combine up to ten T1s to create a Multilink bundle.

The bundle can include T1 channels assigned to different T3s.
Multilink bundle
T1 T1
T1
T1 T1
T1 T1
T1
T1
T1
T1
T1 T1
T1
T1
T1
T1
T1 T1
T1
T1
T1
T1
T1
T1
T1 T1
T1
T1 T1
T1
T1 T1
T1
T1
T1
T1 T1
T1
T1 T1
T1
T1
T1
T1 T1
T1
T1
T1
T1
T1
T1
T1
T1 T1
T1 T1
T1
T1
T1
T1
T1
T1 T1
T1
T1
T1
T1 T1
T1
T1
T1 T1
T1
T1
T1 T1
T1
T1 T1
T1
T1
38545
T1
T1
Feature History for MLP Over Serial-Based LFI

Cisco IOS Release
Description
Required PRE
Release 12.0(23)SX
The MLP over serial-based LFI feature was introduced on PRE1

the PRE1.
Release 12.2(27)SBB
PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3 and the valid

multilink interface values changed from 1 to 9999
(Release 12.2(28)SB and later) to from 1 to 9999 and
65,536 to 2,147,483,647.
PRE3
Performance and Scalability for MLP Over Serial-Based LFI

To enhance performance and scalability for MLP over serial-based LFI, configure the hold-queue
command in interface configuration mode for all physical interfaces, except when configuring the ATM
OC-12 line card. The OC-12 does not require the hold-queue command. For example:
Router(config-if)# hold-queue 4096 in
For more information, see the Scalability and Performance chapter in the Cisco 10000 Series Router
Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.

OL-7433-09
16-13
Chapter 16
Restrictions and Limitations for MLP Over Serial-Based LFI
A multilink bundle can have up to 10 member links. The router supports subrate T1 interfaces as
member links. The link speeds must be the same for all of the links in the bundle.
The router supports a maximum of 1250 bundles per system and a maximum of 2500 member links
per system.
The valid multilink interface values are from 1 to 9999 (Release 12.2(28)SB and later), or from 1 to
9999 and 65,536 to 2,147,483,647 (Release 12.2(31)SB2 and later). For example:
Router(config)# interface multilink 8
Interleaving is supported on one member link. MLP over Serial-based LFI must be enabled on an
interface that has interleaving turned on.
All member links in a MLP bundle must have the same encapsulation type and bandwidth.
Performance is not guaranteed when member links have different bandwidths.
We strongly recommend that you use only strict priority queues when configuring MLP over
Serial-based LFI. For more information, see Chapter 8, Prioritizing Services.
Line Card Support for MLP Over Serial-Based LFI

The following line cards support MLP over serial-based LFI for the Cisco 10000 series router:
24-port Channelized T1/E1
6-port Channelized T3
4-port Channelized OC-3/STM-1
1-port Channelized OC-12/STM-4
Single-VC MLP Over ATM-Based LFI

Single-VC MLP over ATM-based LFI uses the fragmentation and interleaving capability of MLP to
integrate real-time and nonreal-time packets together on the same link. MLP defines the mechanisms to
fragment, reassemble, and sequence large datagrams across multiple logical data links. MLP uses the
fragmentation and packet sequencing specifications defined in RFC 1990 to implement link
fragmentation and interleaving at the bundle level, supporting only one LFI-enabled member link per
MLP bundle.
16-14
OL-7433-09
Chapter 16

The following describes how MLP implements fragmentation and interleaving:
Delay-Sensitive, Real-Time PacketsOn transmit, MLP encapsulates the packets as PPP over ATM
(PPPoA) and sends the packets to a special transmit queue to enable the router to transmit the
real-time packets earlier than other packet flows. The router interleaves the real-time packets
between the fragments of the larger, nonreal-time packet over a single point-to-point link to the
remote address. Upon receipt, the receiving fragmentation peer processes the real-time packets as
PPPoA packets.
Delay-Insensitive, Nonreal-Time PacketsOn transmit, MLP fragments the large data packets to a
size small enough to satisfy the delay requirements of real-time traffic. MLP encapsulates the
packets as MLP packets and sends the packets to a transmit queue to enable the router to transmit
the fragments at the same time over multiple point-to-point links to the same remote address. The
receiving fragmentation peer reassembles the fragments to the original packet and then processes it
as Point-to-Point Protocol over ATM (PPPoA). The underlying PPP encapsulation conforms to
RFC 1661. All outbound MLP packets with a payload larger than the specified fragment size are
fragmented. The minimum fragment size depends on the AAL5 encapsulation type and whether or
not protocol compression is enabled (see Table 16-2 on page 16-15).
When configuring single-VC MLP over ATM-based LFI, you must configure a virtual template interface
for the MLP bundle. However, the virtual template does not need to be unique for each bundlemultiple
MLP bundles can share the same virtual template.
For more information about MLP, see the Multilink PPP-Based Link Fragmentation and Interleaving
section on page 16-11 and the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and
MPLS Configuration Guide.
Feature History for Single-VC MLP Over ATM-Based LFI

Cisco IOS Release
Description
Required PRE
Release 12.2(27)SBB
The single-VC MLP over ATM-based LFI feature was

introduced on the router for the PRE2.
PRE2
Release 12.2(31)SB2
PRE3
Fragment Size Calculation for MLP Over ATM-Based LFI

For MLP over ATM-based LFI, the ideal fragment size should allow the fragments to fit into an exact
multiple of ATM cells. Table 16-2 lists the minimum fragment sizes for Single-VC and Multi-VC MLP
over ATM-based LFI. As shown in the table, the minimum fragment size depends on the AAL5
encapsulation type used and whether or not protocol compression is enabled.
Table 16-2
ATM Minimum Fragment Size
AAL5 Encapsulation Type
Protocol Compression
Minimum Fragment Size
AAL5 MUX
OFF
82 Bytes
AAL5 SNAP
OFF
78 Bytes
AAL5 Cisco
OFF
80 Bytes
AAL5 MUX
ON
83 Bytes
AAL5 SNAP
ON
79 Bytes
AAL5 Cisco
ON
81 Bytes

OL-7433-09
16-15
Chapter 16
To calculate the fragment size, do the following:

Step 1
Calculate the nominal fragment size (link weight) by using the following formula:
(Link Bandwidth * Fragment-Delay) / 8
Step 2
Determine the number of whole ATM cells the nominal fragment size represents.
If the number of ATM cells is less than two, then use two ATM cells in Step 3. The minimum number of
ATM cells you can have is 2.
Step 3
Calculate the total bytes per fragment, including the MLP header bytes and AAL5 trailer bytes, by
multiplying the number of ATM cells you calculated in Step 2 by 48:
Number of Cells * 48
Step 4
Subtract the MLP header bytes and AAL5 trailer bytes.

The AAL trailer is 8 bytes.
The number of MLP header bytes depends on the AAL5 encapsulation and whether or not protocol
compression is enabled (see Table 16-3).
Table 16-3 lists the number of bytes in the MLP header, depending on the AAL5 encapsulation type and
whether or not protocol compression is used.
Table 16-3
MLP Header Bytes and AAL5 Trailer Bytes
AAL5 Encapsulation
Type
Protocol
Compression
No. of MLP Header

Bytes
No. of AAL5 Trailer

Bytes
AAL5 MUX
OFF
6 Bytes
8 Bytes
AAL5 SNAP
OFF
10 Bytes
8 Bytes
AAL5 Cisco
OFF
8 Bytes
8 Bytes
AAL5 MUX
ON
5 Bytes
8 Bytes
AAL5 SNAP
ON
9 Bytes
8 Bytes
AAL5 Cisco
ON
7 Bytes
8 Bytes
MLP Bundle Interface and Service Policies

The router applies a service policy, attached to a multilink interface, to only the MLP bundle interface.
The QoS actions defined by the service policy are applied to the outbound nonreal-time packets before
the packets reach the bundle first-in first-out (FIFO) queue. The nonreal-time packets are fragmented in
the FIFO queue and then the real-time packets are interleaved between the fragments as the real-time
packets exit their priority queue.
16-16
OL-7433-09
Chapter 16

Transmit Processing
The purpose of MLP over ATM-based LFI transmit processing is to fragment large nonreal-time
delay-insensitive packets and interleave smaller real-time delay-sensitive packets between the
fragments. Each MLP bundle has multiple transmit packet queues. MLP does not interleave packet
fragments from different packet queues associated with a given MLP bundle. Instead, MLP transmits all
of the fragments associated with a nonreal-time packet in order before transmitting fragments from
another nonreal-time packet. MLP posts all of the packets from the various nonreal-time packet queues
to a single bundle first-in first-out (FIFO) queue. It is from this single bundle queue that MLP does the
following:
Fragments nonreal-time traffic
Encapsulates the fragments with MLP
Transmits the fragments
Real-time traffic, such as voice, are queued intact to a priority (low-latency) queue. It is from this queue
that MLP transmits the real-time packets and interleaves them between the nonreal-time fragments.
Because real-time packets are not MLP encapsulated or fragmented, MLP can safely interleave these
packets as needed. Traffic transmitted from the priority queue takes precedence over the MLP
encapsulated traffic that is transmitted from the related bundle queue.
Figure 16-4 shows an example of the packet flow of real-time and nonreal-time packets.
Figure 16-4
Delay Insensitive
Packet Queues
MLP Over ATM-Based LFI Packet Queue Flow
Bundle FIFO
Queue
Delay Sensitive
Packet Queues
132278
Link
Receive Processing
The purpose of MLP over ATM-based LFI receive processing is to reassemble MLP over ATM
encapsulated packet fragments into PPP over ATM packets. During receive processing, the fragments
that arrive out of order and the packets with missing fragments are discarded. Valid fragments are merged
in memory until the entire packet is reassembled.

OL-7433-09
16-17
Chapter 16
Performance and Scalability for Single-VC MLP Over ATM-Based LFI

The following list describes how to enhance performance and scalability for Single-VC MLP over
ATM-based LFI:
Configure the following commands and recommended values on the virtual template interface:
ppp max-configure 110
ppp max-failure 100
ppp timeout retry 5
keepalive 30
Configure the hold-queue command in interface configuration mode for all physical interfaces,
except when configuring the ATM OC-12 line card. The OC-12 does not require the hold-queue
command.
Restrictions and Limitations for Single-VC MLP Over ATM-Based LFI
Single-VC MLP over ATM member links are restricted to non-aggregated PVCs (for example,
variable bit rate-nonreal-time (VBR-nrt) and constant bit rate (CBR) ATM traffic classes only).
The multilink interface can have only one PPP link that is between 64 and 2048 kbps. The router
supports a maximum of one member link per bundle.
per system.
The valid multilink interface values are 10,000 and higher.
Interleaving occurs on one member link.
MLP VCs cannot be on-demand VCs that are automatically provisioned.
Associating MLP over ATM VCs with ATM virtual paths (VPs) is discouraged, though not
prevented.
Cisco IOS software supports a maximum of 4096 total virtual template interfaces.
We strongly recommend that you use only strict priority queues when configuring MLP over
ATM-based LFI. For more information, see Chapter 8, Prioritizing Services.
Line Card Support for MLP Over ATM-Based LFI

The following line cards support MLP over ATM-based LFI for the Cisco 10000 series router:
8-Port E3/DS3 ATM
4-Port OC-3/STM-1 ATM
1-Port OC-12 ATM
16-18
OL-7433-09
Chapter 16

Multi-VC MLP Over ATM-Based LFI

Multi-VC MLP over ATM-based LFI uses the fragmentation and interleaving capability of MLP to
integrate real-time and nonreal-time packets together on the same link. MLP defines the mechanisms to
fragment, reassemble, and sequence large datagrams across multiple logical data links. MLP uses the
fragmentation and packet sequencing specifications defined in RFC 1990 to implement link
fragmentation and interleaving at the bundle level. Multi-VC MLP over ATM-based LFI supports up to
10 member links per MLP bundle, one of which is LFI-enabled.
MLP encapsulates real-time packets as PPP over ATM (PPPoA) and sends the packets to a priority
transmit queue to enable the router to transmit the real-time packets earlier than other packet flows. The
router interleaves the real-time packets between the fragments of the larger, nonreal-time packet over a
single point-to-point link to the remote address. Upon receipt, the receiving fragmentation peer
processes the real-time packets as PPPoA packets.
MLP fragments the large data packets to a size small enough to satisfy the delay requirements of
real-time traffic. MLP encapsulates the packets as MLP packets and sends the packets to a first-in
first-out (FIFO) queue to enable the router to transmit the fragments at the same time over multiple
point-to-point links to the same remote address. Upon receipt, the receiving fragmentation peer
reassembles the fragments to the original packet and then processes it as PPPoA. The underlying PPP
encapsulation conforms to RFC 1661.
MLP fragments all outbound MLP packets with a payload that is larger than the specified fragment size.
The smallest fragment size depends on the AAL5 encapsulation type and whether or not protocol
compression is enabled. For more information, see the Fragment Size Calculation for MLP Over
ATM-Based LFI section on page 16-15.
When configuring Multi-VC MLP over ATM-based LFI, you must configure a virtual template interface
for the MLP bundle. However, the virtual template does not need to be unique for each bundlemultiple
MLP bundles can share the same virtual template.
Feature History for Multi-VC MLP Over ATM-Based LFI

Cisco IOS Release
Description
Required PRE
Release 12.2(27)SBB
The Multi-VC MLP over ATM-based LFI feature was

PRE2
Release 12.2(31)SB2
This feature was introduced on the PRE3 and the valid

multilink interface values changed from 1 to 9999
(Release 12.2(28)SB and later) to from 1 to 9999 and
65,536 to 2,147,483,647.
PRE3
Fragment Size Calculation for Multi-VC MLP Over ATM-Based LFI

For Multi-VC MLP over ATM-based LFI, the ideal fragment size should allow the fragments to fit into
an exact multiple of ATM cells. Table 16-2 on page 16-15 lists the minimum fragment sizes for
Single-VC and Multi-VC MLP over ATM-based LFI. As shown in the table, the minimum fragment size
depends on the AAL5 encapsulation type used and whether or not protocol compression is enabled.
For more information, see the Fragment Size Calculation for MLP Over ATM-Based LFI section on
page 16-15.

OL-7433-09
16-19
Chapter 16

Performance and Scalability for Multi-VC MLP Over ATM-Based LFI

The following list describes how to enhance performance and scalability for Multi-VC MLP over
ATM-based LFI:
ppp max-failure 100
ppp timeout retry 5
keepalive 30
Configure the hold-queue command in interface configuration mode for all physical interfaces,
except when configuring the ATM OC-12 line card. The OC-12 does not require the hold-queue
command.
Restrictions and Limitations for Multi-VC MLP Over ATM-Based LFI
Multi-VC MLP over ATM member links are restricted to non-aggregated PVCs (for example,
variable bit rate-nonreal-time (VBR-nrt) and constant bit rate (CBR) ATM traffic classes only).
Each MLP over ATM member link can be up to 2048 kbps.
The router supports a maximum of 10 member links (ATM PVCs) per bundle.
per system.
For Cisco IOS Release 12.2(28)SB and later releases, the valid multilink interface values are from
1 to 9999. For Cisco IOS Release 12.2(31)SB2 and later releases, valid values are from 1 to 9999
and 65,536 to 2,147,483,647.
All member links in a MLP bundle must have the same encapsulation type and bandwidth.
Performance is not guaranteed when member links have different bandwidths.
Interleaving occurs on one member link.
MLP VCs cannot be on-demand VCs that are automatically provisioned.
Associating MLP over ATM VCs with ATM virtual paths (VPs) is discouraged, though not
prevented.
We strongly recommend that you use only strict priority queues when configuring Multi-VC MLP
over ATM-based LFI. For more information, see Chapter 8, Prioritizing Services.
16-20
OL-7433-09
Chapter 16

Line Card Support for MLP Over ATM-Based LFI

The following line cards support MLP over ATM-based LFI for the Cisco 10000 series router:
8-Port E3/DS3 ATM
4-Port OC-3/STM-1 ATM
1-Port OC-12 ATM
MLP Over Frame Relay-Based LFI

MLP over Frame Relay-based LFI uses the fragmentation and interleaving capability of MLP to
transport real-time traffic (for example, voice) and nonreal-time traffic (for example, data transfers)
together on low-speed Frame Relay permanent virtual circuits (PVCs) without causing excessive delay
to the real-time traffic. MLP over Frame Relay-based LFI supports RFC 1990, The PPP Multilink
Protocol.
MLP over Frame Relay-based LFI makes it possible for delay-sensitive packets and delay-insensitive
packets to share the same link by fragmenting the long data packets into a sequence of smaller data
packets referred to as fragments. The fragments are interleaved with the real-time packets. On the
receiving side of the link, the fragments are reassembled and the packet is reconstructed. This method
of fragmenting and interleaving helps guarantee the appropriate QoS for the real-time traffic.
When configuring MLP over Frame Relay-based LFI, you must configure a virtual template interface
for the MLP bundle. The virtual template must be unique to only that bundlemultiple MLP bundles
cannot share the same virtual template.
For more information about MLP, see the Multilink PPP-Based Link Fragmentation and Interleaving
section on page 16-11 and the Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and
MPLS Configuration Guide.
Feature History for MLP Over Frame Relay-Based LFI

Cisco IOS Release
Description
Required PRE
Release 12.2(27)SBB
The MLP over Frame Relay-based LFI feature was

PRE2
Release 12.2(31)SB2
PRE3
Multilink Group Interfaces and Virtual Template Interfaces

You can configure MLP by assigning a multilink group to a virtual template interface configuration.
Virtual templates allow a virtual access interface (VAI) to dynamically clone interface parameters from
the specified virtual template. If you assign a multilink group to a virtual template and you assign the
virtual template to a physical interface, all of the links that pass through the physical interface belong to
the same multilink bundle.

OL-7433-09
16-21
Chapter 16

Transmit Processing
The purpose of MLP over Frame Relay-based LFI transmit processing is to fragment large nonreal-time
delay-insensitive packets and interleave smaller real-time delay-sensitive packets between the
fragments. Each MLP bundle has multiple transmit packet queues. MLP does not interleave packet
fragments from different packet queues associated with a given MLP bundle. Instead, MLP transmits all
of the fragments associated with a nonreal-time packet in order before transmitting fragments from
another nonreal-time packet. MLP posts all of the packets from the various nonreal-time packet queues
to a single bundle first-in first-out (FIFO) queue.
It is from this single bundle queue that MLP does the following:
Fragments nonreal-time traffic
Encapsulates the fragments with MLP
Transmits the fragments
Real-time traffic, such as voice, are queued intact to a priority (low-latency) queue. It is from this queue
that MLP transmits the real-time packets and interleaves them between the nonreal-time fragments.
Because real-time packets are not MLP encapsulated or fragmented, MLP can safely interleave these
packets as needed. Traffic transmitted from the priority queue takes precedence over the MLP
encapsulated traffic that is transmitted from the related bundle queue.
Figure 16-4 shows an example of the packet flow of real-time and nonreal-time packets.
Figure 16-5
Delay Insensitive
Packet Queues
MLP Over Frame Relay-Based LFI Packet Queue Flow
Bundle FIFO
Queue
Delay Sensitive
Packet Queues
132278
Link
Receive Processing
The purpose of MLP over Frame Relay-based LFI receive processing is to reassemble MLP over Frame
Relay encapsulated packet fragments into PPP over ATM packets. During receive processing, the
fragments that arrive out of order and the packets with missing fragments are discarded. Valid fragments
are merged in memory until the entire packet is reassembled.
16-22
OL-7433-09
Chapter 16

Fragment Size Calculation for MLP Over Frame Relay-Based LFI

To calculate the minimum fragment size for MLP over Frame Relay-based LFI, do the following:
Step 1
Calculate the nominal fragment size (link weight) by using the following formula:
(Link Bandwidth * Fragment-Delay) / 8
Step 2
Subtract the Frame Relay encapsulation bytes and the MLP header bytes by using the following formula:
Nominal Fragment Size (Frame Relay Encap. Bytes + MLP Header Bytes + Cells Checksum)
where:
Frame Relay Encapsulation Bytes is 4.
MLP Header Bytes is 4.
Cells Checksum is 2.
Step 3
If PPP protocol compression is on, subtract 1 byte.

For no protocol compression, subtract 2 bytes.
For MLP over Frame Relay-based LFI, the minimum fragment size is 56, calculated as follows:
(MLP Min. Weight) (PPP Encapsulation Bytes) (MLP Header Bytes) = Min. Fragment Size
where:
MLP Minimum Weight is 64
PPP Encapsulation Bytes is 4.
MLP Header Bytes is 4.
Performance and Scalability for MLP Over Frame Relay-Based LFI

The following list describes how to enhance performance and scalability for MLP over Frame
Relay-based LFI:
ppp max-failure 100
ppp timeout retry 5
keepalive 30
Configure the hold-queue command in interface configuration mode for all Frame Relay physical
interfaces.
For more information, see the Performance and Scalability chapter in the Cisco 10000 Series Router

OL-7433-09
16-23
Chapter 16
Restrictions and Limitations for MLP Over Frame Relay-Based LFI
The router supports a maximum of one member link per bundle. The member link can be up to
2048 kbps.
per system.
The valid multilink interface values are 10,000 and higher.
Interleaving occurs on only one member link.
Interface fragmentation and Frame Relay traffic shaping cannot be configured at the same time on
an interface. Do not configure the frame-relay traffic-shaping command on an interface with
Frame Relay interface fragmentation configured.
The frame-relay fair-dlci queuing command cannot be configured on an interface with Frame
Relay interface fragmentation configured. To specify QoS on LFI-enabled interfaces, use service
policies (see Chapter 13, Defining QoS for Multiple Policy Levels).
Local Management Interface (LMI) traffic is not fragmented.
We strongly recommend that you use only strict priority queues when configuring MLP over Frame
Relay-based LFI. For more information, see Chapter 8, Prioritizing Services.
Configuring MLP-Based LFI

Table 16-4 lists the components you must configure for MLP-based LFI.
Table 16-4
Configuration Requirements for MLP-Based LFI
LFI Type
MLP Bundle
Member Links
Virtual Template
Service Policy
MLP over Serial-Based

LFI
Required
Required
Not Required
Not Required
Single-VC MLP over

ATM-Based LFI
Required
Required
Required
Required1
Multi-VC MLP over

ATM-Based LFI
Required
Required
Required
Required
MLP over Frame

Relay-Based LFI
Required
Required
Required
Required2
1. A service policy with a priority queue defined must be attached to the multilink interface. The VC does not require a service
policy.
2. A service policy with the shape command defined must be attached to the VC. A service policy with a priority queue defined
must be attached to the multilink interface.
16-24
OL-7433-09
Chapter 16

To configure MLP-based fragmentation and interleaving, perform the following configuration tasks:
Creating a MLP Bundle Interface, page 16-25
Enabling MLP on a Virtual Template Interface, page 16-27
Configuring a Shaping Policy for MLP Over Frame Relay-Based LFI, page 16-29
Configuring a Shaping Policy for MLP Over Frame Relay-Based LFI, page 16-29
Adding an ATM Member Link to a MLP Bundle, page 16-30
Adding a Frame Relay Member Link to a MLP Bundle, page 16-33
Creating a MLP Bundle Interface

To create a MLP bundle interface, enter the following commands beginning in global configuration
mode:
Step 1
Command
Purpose
Router(config)# interface multilink

multilink-bundle-number
Creates a multilink bundle. Enters interface configuration

mode to configure the bundle.
multilink-bundle-number is a nonzero number that identifies
the multilink bundle. For Cisco IOS Release 12.2(28)SB and
later releases, valid values are:

1 to 9999 (Cisco IOS Release 12.2(28)SB and later
releases)
1 to 9999 and 65,536 to 2,147,483,647 (Cisco IOS
Release 12.2(31)SB2 and later releases)

10,000 and higher

releases)

10,000 and higher
Note
Step 2
Router(config-if)# ip address address mask
For releases prior to Cisco IOS Release 12.2(28)SB,

valid values are from 1 to 2,147,483,647.
Specifies the IP address and subnet mask assigned to the

interface.
mask is the subnet mask for the associated IP address.

OL-7433-09
16-25
Chapter 16
Step 3
Command
Purpose
Router(config-if)# ppp chap hostname hostname
Identifies the hostname sent in the Challenge Handshake

Authentication Protocol (CHAP) challenge.
hostname is the name of the bundle group. This is the unique
identifier that identifies the bundle.
Note
Step 4

If more than one bundle transmits packets to a peer

system, use this command to distinguish the bundle.
If you configure this command on the bundle and its
member links, specify the same identifier for both the
bundle and the member links.
Attaches the policy map you specify to the multilink

interface.
input indicates to apply the service policy to the traffic on the
inbound interface.
output indicates to apply the service policy to the traffic on
the outbound interface.
Note
For QoS policies containing the bandwidth,

priority, random-detect, queue-limit, and shape
commands, you must specify the output keyword.
The router ignores these commands when you use
them with the input keyword.

Step 5
Router(config-if)# ppp multilink
Enables MLP on the interface.

Note
Step 6

fragment-delay delay-max
MLP fragmentation is enabled by default.
Configures the maximum delay allowed for the transmission

of a packet fragment on an MLP bundle.
delay-max specifies the maximum amount of time, in
milliseconds, that is required to transmit a fragment. Valid
values are from 1 to 1000 milliseconds.
Step 7
Router(config-if)# ppp multilink interleave
Enables interleaving of real-time packets among the

fragments of larger nonreal-time packets on a MLP bundle.
Step 8
Router(config-if)# ppp multilink group

group-number
Restricts a physical link to joining only a designated

multilink group interface.
group-number is a nonzero number that identifies the
multilink group. The number you specify must be identical to
the multilink-bundle-number you specified in Step 1.
16-26
OL-7433-09
Chapter 16

Configuration Example for Creating a MLP Bundle Interface

Example 16-1 shows a sample configuration for creating a MLP bundle interface.
Example 16-1 Creating a MLP Bundle Interface
Router(config)# interface multilink 8
Router(config-if)# ppp chap hostname cambridge
Router(config-if)# service-policy output bronze
Router(config-if)# ppp multilink fragment-delay 50
Router(config-if)# ppp multilink group 8
Enabling MLP on a Virtual Template Interface

The virtual template interface is attached to the member links, not to the MLP bundle. You can apply the
same virtual template to the member links; you are not required to apply a unique virtual template to
each member link.
To enable MLP on a virtual template, enter the following commands beginning in global configuration
mode:
Step 1
Command
Purpose

number
Creates or modifies a virtual template interface that can be

configured and applied dynamically to virtual access
interfaces. Enters interface configuration mode.
number is a number that identifies the virtual template
interface. You can configure up to 5061 total virtual template
interfaces (requires Cisco IOS Release 12.2(28)SB and later
releases).
Step 2
Router(config-if)# ppp max-configure retries
Specifies the maximum number of configure requests to

attempt before stopping the requests due to no response.
retries specifies the maximum number of retries. Valid values
are from 1 to 255. The default is 10 retries. We recommend
110 retries.
Step 3
Router(config-if)# ppp max-failure retries
Configures the maximum number of consecutive Configure

Negative Acknowledgements (CONFNAKs) to permit before
terminating a negotiation.
retries is the maximum number of retries. Valid values are
from 1 to 255. The default is 5 retries. We recommend 100
retries.

OL-7433-09
16-27
Chapter 16
Step 4
Command
Purpose
Router(config-if)# ppp timeout retry

response-time
Sets the maximum time to wait for Point-to-Point Protocol

(PPP) negotiation messages.
response-time specifies the maximum time, in seconds, to
wait for a response during PPP negotiation. We recommend
5 seconds.
Step 5
Router(config-if)# keepalive [period]
Enables keepalive packets to be sent at the specified time

interval to keep the interface active.
period specifies a time interval, in seconds. The default is 10
seconds. We recommend 30 seconds.
Step 6
Removes an IP address.
Step 7
Enables MLP on the virtual template interface.
Step 8

group-number
(MLP over FR only) Associates the interface with a MLP

bundle. Use this command only for MLP over
Frame-Relay-based LFI.
multilink group. Valid values are from 10,000 and higher.
The group-number must be identical to the specified
multilink-bundle-number of the MLP bundle to which you
want to add this link.
Configuration Example for Enabling MLP on a Virtual Template

Example 16-2 shows a sample configuration for enabling MLP on a virtual template.
Example 16-2 Enabling MLP on a Virtual Template
Router(config-if)# ppp max-configure 110
Router(config-if)# ppp max-failure 100
Router(config-if)# ppp timeout retry 5
Router(config-if)# ip mroute-cache
16-28
OL-7433-09
Chapter 16

Configuring a Shaping Policy for MLP Over Frame Relay-Based LFI

MLP over Frame Relay-based LFI required that you configure a QoS policy that shapes traffic.
To configure a QoS policy that shapes traffic for MLP over Frame Relay-based LFI, enter the following
Step 1
Command
Purpose
policy-map-name
Configures the QoS policy. Enters policy-map configuration

mode.
Step 2

configuration mode.
Step 3
Shapes traffic to a specified bit rate.

kbps-value is the bit rate (in kilobits per second) used to shape the
traffic.
Adding a Serial Member Link to a MLP Bundle

You can configure up to 10 member links per MLP bundle for MLP over serial-based LFI. You can also
terminate the serial links on multiple line cards in the router chassis if all of the links are the same type,
such as T1 or E1. The link speeds must be the same for all of the links in the bundle. If the interface you
add to the MLP bundle contains information such as an IP address, routing protocol, or access list, the
router ignores that information. If you remove the interface from the MLP bundle, that information
becomes active again.
To add serial member links to a MLP bundle, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
Router(config-if)# interface serial

slot/module/port.channel:controller-number
Specifies the interface that you want to add to the MLP

bundle. Enters interface configuration mode.
slot/module/port identifies the line card. The slashes are
required.
channel: is the channel group number. The colon is required.
controller-number is the member link controller number.
Step 2
Router(config-if)# hold-queue length {in |

out}
Limits the size of the IP output queue on an interface. We

recommend that you configure this command on all physical
interfaces.
length is a number that specifies the maximum number of
packets in the queue. Valid values are from 0 to 4096. We
recommend 4096 packets for all line cards. By default, the
input queue is 75 packets and the output queue is 40 packets.
in specifies the input queue.
out specifies the output queue.

OL-7433-09
16-29
Chapter 16
Step 3
Command
Purpose
(Optional) Identifies the hostname sent in the Challenge

Handshake Authentication Protocol (CHAP) challenge.
Note

Step 4
Router(config-if)# encapsulation ppp
Specifies Point-to-Point Protocol (PPP) encapsulation for the

interface.
Step 5
Removes any existing IP address from the main interface.
Step 6
Enables MLP on the interface.
Step 7

group-number
Associates the interface with a MLP bundle.

multilink group. Valid values are from 1 to 9999 (Cisco IOS
Release 12.2(28)SB and later releases) or from 1 to 9999 and
65,536 to 2,147,483,647 (Cisco IOS Release 12.2(31)SB2
and later releases).
Adding an ATM Member Link to a MLP Bundle

You can configure up to 10 member links per MLP bundle for Multi-VC MLP over ATM-based LFI.
However, you can configure only one member link per MLP bundle for Single-VC MLP over ATM-based
LFI.
To add ATM member links to a MLP bundle, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1

slot/module/port
Configures or modifies the ATM interface you specify and

enters interface configuration mode.
Step 2

out}

interfaces, except when using the OC-12 ATM line card.
recommend 4096 packets for all line cards, except the ATM
OC-12 line card. By default, the input queue is 75 packets
and the output queue is 40 packets.
Step 3

slot/module/port.subinterface point-to-point
Creates or modifies a point-to-point subinterface. Enters

16-30
OL-7433-09
Chapter 16

Step 4
Command
Purpose
Router(config-subif)# ppp chap hostname

hostname

Note

Step 5
Router(config-subif)# no ip address
Step 6
Creates or modifies an ATM PVC. Enters ATM VC

configuration mode.
name is the name of the ATM PVC.
Step 7
Router(config-if-atm-vc)# vbr-nrt output-pcr

output-scr output-mbs
Configures the variable bit rate-nonreal time (VBR-nrt)

output-scr is the sustainable cell rate (SCR), in kbps.
output-mbs is the output maximum burst cell size (MBS),
expressed in number of cells.
Step 8
Router(config-if-atm-vc)# encapsulation
{aal5mux ppp virtual-template number |
aal5ciscoppp virtual-template number |
aal5snap}
Configures the ATM adaptation layer (AAL) and

encapsulation type for an ATM virtual circuit (VC).
aal5mux ppp specifies the AAL and encapsulation type for
multiplex (MUX)-type VCs. The keyword ppp is Internet
Engineering Task Force (IETF)-compliant PPP over ATM. It
specifies the protocol type being used by the MUX
encapsulated VC. Use this protocol type for Multi-VC MLP
over ATM-based LFI to identify the virtual template. This
protocol is supported on ATM PVCs only.
aal5ciscoppp specifies the AAL and encapsulation type for
Cisco PPP over ATM. Supported on ATM PVCs only.
aal5snap specifies the AAL and encapsulation type that
supports Inverse ARP. Logical Link Control/Subnetwork
Access Protocol (LLC/SNAP) precedes the protocol
datagram.
virtual template.

OL-7433-09
16-31
Chapter 16
Step 9
Command
Purpose
Router(config-if-atm-vc)# protocol ppp

virtual-template number
Enables PPP sessions to be established over the ATM PVC

using the configuration from the virtual template you specify.
Use this command only if you specified aal5snap as the
encapsulation type in Step 11 and you are configuring
multiple VCs for LFI with MLP.
number is a nonzero number that identifies the virtual
template that you want to apply to this ATM PVC.
Step 10
Router(config-if-atm-vc)# ppp multilink group

group-number
Associates the PVC with a MLP bundle.

multilink group. Valid values are:

10,000 and higher

releases)

Configuration Example for Adding ATM Links to a MLP Bundle

Example 16-3 shows how to add an ATM link to a MLP bundle. In the example, MLP is enabled on the
interface named Multilink 10,000 and on the virtual template named virtual-template1. The maximum
delay is set to 8 ms for the transmission of a packet fragment on the MLP bundle. The virtual template
is applied to PVC 1/33 on ATM subinterface 4/0/0.1 and the PVC is associated with the MLP bundle.
Example 16-3 Adding ATM Links to a MLP Bundle
Router(config)# access-list 100 permit udp any any precedence critical
!
Router(config)# class-map Bronze
!
Router(config-pmap)# policy-map Business
!
Router(config)# interface Multilink 10000
16-32
OL-7433-09
Chapter 16


Router(config-if-atm-vc)# vbr-nrt 128 128 1
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol ppp virtual-template1
Router(config-if-atm-vc)# ppp multilink group 10000
Adding a Frame Relay Member Link to a MLP Bundle

You can configure only one member link per MLP bundle for MLP over Frame Relay-based LFI.
To add a Frame Relay member link to a MLP bundle, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1

slot/module/port
Configures or modifies the interface you specify and enters

interface configuration mode.
Step 2

out}

interfaces.
recommend 4096 packets for all line cards. By default, the
input queue is 75 packets and the output queue is 40 packets.
Step 3

Note

system, use this command to distinguish the bundle.

OL-7433-09
16-33
Chapter 16
Step 4
Command
Purpose

[ietf | cisco]
Specifies Frame Relay as the interface encapsulation type.

(Optional) ietf sets the encapsulation method to comply with
the Internet Engineering Task Force (IETF) standard (RFC
1490). Use this keyword when connecting to another
(Optional) cisco indicates to use Ciscos own encapsulation,
which is a 4-byte header, with 2 bytes to identify the data-link
connection identifier (DLCI) and 2 bytes to identify the
packet type. This is the default encapsulation type.
Step 5

slot/module/port.subinterface point-to-point
Configures or modifies the subinterface you specify. Enters

Step 6
interface-dlci dlci ppp virtual-template-name
Assigns a data-link connection identifier (DLCI) to the

Frame Relay subinterface and applies a virtual template
configuration for a PPP session.
dlci is a number that identifies the connection. This number
is specific to the local subinterface.
ppp enables the circuit to use PPP in Frame Relay
encapsulation.
virtual-template-name specifies which virtual template
interface to apply the PPP connection to.
Step 7
Router(config-subif)# service-policy {input |

Applies the service policy you specify to the subinterface.

inbound interface.
output indicates to apply the service policy to the traffic on
the outbound interface.
Note
For QoS policies containing the bandwidth,

priority, random-detect, queue-limit, and shape
commands, you must specify the output keyword.
The router ignores these commands when you use
them with the input keyword.

Example 16-4 shows how to add Frame Relay links to a MLP bundle. In the example, MLP is enabled
on the Multilink 20009 interface and on the virtual template named Virtual-Template 209. The
service-policy named voip is applied to the Multilink 20009 interface. Virtual-Template 209 is applied
to DLCI 18 on the serial subinterface 3/0/1.1.
Example 16-4 Adding Frame Relay Links to a MLP Bundle
frame-relay switching
class-map match-all voip
match ip rtp 16384 1000
policy-map voip
class voip
priority
16-34
OL-7433-09
Chapter 16


policy-map shape
class class-default
shape 100
interface Multilink20009
ip address 10.1.2.2 255.255.255.0
ppp multilink
ppp multilink fragment delay 8
ppp multilink group 20009
service-policy output voip
interface serial 3/0/1
no ip address
encapsulation frame-relay
no keepalive
!
interface serial 3/0/1.1 point-to-point
no keepalive
frame-relay interface-dlci 18 ppp Virtual-Template209
service-policy output shape
!
description mlp_lfi_c10k
no ip address
ppp chap hostname lfiofr-20009
ppp multilink
ppp multilink group 20009
!
Moving a Member Link to a Different MLP Bundle

To move a member link to a different MLP bundle, enter the following commands beginning in interface
configuration mode:
Command
Purpose
Step 1

Specifies the interface that you want to move to a different MLP

Step 2
Router(config-if)# ppp chap hostname

hostname

You must specify the same hostname as the one you assigned
when you created the MLP bundle. For more information, see the
Creating a MLP Bundle Interface section on page 16-25.
Note

system, use this command to distinguish the bundle. If
you configure this command on the bundle and its

OL-7433-09
16-35
Chapter 16
Step 3
Command
Purpose

group-number
Moves this interface to the MLP bundle you specify.

group-number identifies the multilink group. Change this
group-number to the new MLP group group-number. Valid values
are:

releases)

10,000 and higher

releases)
MLP over Frame-Relay-based LFI

10,000 and higher
Removing a Member Link from a MLP Bundle

To remove a member link from a MLP bundle, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1

Specifies the member link that you want to remove from the MLP
Step 2
Router(config-if)# no ppp multilink group

group-number
Removes the member link from the MLP group.

group-number identifies the multilink group.
Step 3
Router(config-if)# no ppp multilink
Disables Multilink PPP for the link.
Step 4
Router(config-if)# no ppp chap hostname
Removes PPP authentication.
16-36
OL-7433-09
Chapter 16

FRF.12 Fragmentation uses Frame Relay Forum FRF.12-based fragmentation on Frame Relay
permanent virtual circuits (PVCs) to allow long, nonreal-time data packets to be broken into smaller
frames and shorter real-time packets to be interleaved between the fragments. In this way, real-time and
nonreal-time packets can be carried together on low-speed links without causing excessive delay to the
real-time traffic. The real-time packets remain intact and are less likely to experience long queuing
delays.
FRF.12 fragmentation is defined by the FRF.12 Implementation Agreement. The router implements the
end-to-end application of the FRF.12 standard. This application specifies fragmentation between two
Frame Relay data terminal equipment (DTE) devices that are interconnected by one or more Frame
Relay networks.
The following describes how FRF.12 mechanisms fragment and reassemble packets:
Nonreal-Time TransmitThe transmitting LFI-enabled data terminal equipment (DTE) fragments

large nonreal-time packets into smaller frames and encapsulates the frames as FRF.12 end-to-end
packets.
Real-Time TransmitThe DTE encapsulates real-time packets as Frame Relay packets and
interleaves the real-time packets between the nonreal-time fragments.
Nonreal-Time ReceiveThe receiving LFI-enabled DTE reassembles the nonreal-time fragments

and processes the reassembled packets as Frame Relay packets.
Real-Time ReceiveBecause real-time packets are whole packets and not fragments, reassembly is
not required. Instead, the receiving DTE simply processes and forwards the Frame Relay packets.
FRF.12 fragmentation transmits in order all fragments associated with a nonreal-time packet before
transmitting fragments from another nonreal-time packet associated with the same PVC. When
fragments arrive out of order, the receiving DTE detects and discards any packets that are missing
fragments.
Figure 16-6 shows an example configuration of end-to-end fragmentation. When FRF.12 fragmentation
is used between two peer DTEs, the fragmentation procedure is transparent to the Frame Relay networks
between the transmitting and receiving DTEs.
Figure 16-6
Frame Relay
DTE
End-to-End Fragmentation and Reassembly
Cisco 10008
Router
DLCI 100
Frame Relay
Network
Frame Relay
DCE
Frame Relay
DTE
DLCI 100
DCE
Interface
DCE
Interface
132277
Frame Relay PVC
Fragmentation Peers
You can configure FRF.12 Fragmentation at the PVC or interface level. For more information, see the
PVC-Based FRF.12 Fragmentation section on page 16-40 and the Interface-Based FRF.12
Fragmentation section on page 16-40.

OL-7433-09
16-37
Chapter 16
Feature History for FRF.12 Fragmentation

Cisco IOS Release
Description
Required PRE
Release 12.0(23)SX
The PVC-based FRF.12 Fragmentation feature was

PRE1
Release 12.0(27)S
This feature was enhanced to allow interface-based

FRF.12 fragmentation.
PRE1
Release 12.2(27)SBB
This feature was introduced on the PRE2 to allow

PVC-based and interface-based FRF.12 fragmentation
only.
PRE2
Release 12.2(31)SB2
PRE3
FRF.12 over Multilink Frame Relay

To remove and re-attach service policies from the FRF.12 over Multilink Frame Relay configuration
when traffic is running, use Example 16-5. In Example 16-5, you remove the map-class, and then remove
the service policy.
Example 16-5 Remove the Map-Class Before Removing the Service Policy
int mfr2001.1
no frame-relay class mfr
no service-policy out mfr1
int mfr2001.1
service-policy out mfr1
frame-relay class mfr
When traffic is stopped, you can remove and re-attach service policies using Example 16-6 and
Example 16-7.
Example 16-6 Removing and Re-attaching the Service Policy
int mfr2001.1
int mfr2001.1
Example 16-7 Remove the Service Policy Before Removing the Map-Class.
int mfr2001.1
no frame-relay class mfr
int mfr2001.1
frame-relay class mfr
16-38
OL-7433-09
Chapter 16

FRF.12 Fragmentation Inheritance

Table 16-4 describes FRF.12 Fragmentation inheritance when you configure LFI on a Frame Relay
interface, subinterface, or DLCI (either directly or using a map class with LFI enabled).
PVC-Based Frame Relay LFI Inheritance
LFI Enabled
Traffic Subject to LFI
Interface
All PVCs on the interface and its subinterfaces
Subinterface
All PVCs on the subinterface
DLCI
DLCI only
FRF.12 Fragmentation and Hierarchical Policies

To configure FRF.12 Fragmentation, you must first configure a hierarchical service policy and attach it
to a Frame Relay interface, subinterface, or data-link connection identifier (DLCI) in one of the
following ways:
Directly using the service-policy command
Using a Frame Relay map class
Fragmentation is enabled only when a hierarchical service policy is attached. The hierarchical service
policy you define must identify and allocate queues for real-time (priority) traffic and nonreal-time
traffic.
Example 16-8 creates a serial T1 interface and defines a service policy for both real-time and
nonreal-time traffic. You can create the T1 interface under any higher level channelized interface that
supports T1 tributaries or the T1/E1 line card interface. In the example, the child policy map named
policy_12_p0 defines QoS actions for three traffic classes: prec_q0 for priority traffic, prec_q1 for
non-priority traffic, and prec_q2 for non-priority traffic. The parent policy map named policy_13 shapes
traffic for all of the traffic classes to 256 kbps. The service-policy command is used to apply the child
policy to the parent policy. When applying the service policy to an interface, subinterface, or DLCI, use
the service-policy command and specify the output keyword for FRF.12 Fragmentation.
Example 16-8 Defining a Hierarchical Service Policy
Router(config)# t1 1 channel-group 1 timeslot 1-24 speed 56
!
Router(config)# class-map match-all prec_q2
Router(config-cmap)# class-map match-all prec_q0
Router(config-cmap)# class-map match-all prec_q1
!
Router(config)# policy-map policy_12_p0
Router(config-pmap)# class prec_q0
Router(config-pmap-c)# class prec_q1
Router(config-pmap-c)# class prec_q2
!
Router(config)# policy-map policy_13

OL-7433-09
16-39
Chapter 16

Router(config-pmap-c)# service-policy policy_12_p0
For more information, see the Configuring Interface-Based FRF.12 Fragmentation section on
page 16-57 and Chapter 13, Defining QoS for Multiple Policy Levels.
PVC-Based FRF.12 Fragmentation

PVC-based FRF.12 Fragmentation allows you to configure LFI on a per-PVC basis using a Frame Relay
map class. Fragmentation is enabled in the map class and then the map class is associated with a specific
Frame Relay subinterface or data-link connection identifier (DLCI). Each PVC performs fragmentation
independently of other PVCs on its interface and each PVC has its own individual queues.
When using PVC-based FRF.12 Fragmentation, fragmentation is enabled only when the PVC or its
subinterface has a hierarchical service policy. For more information, see the FRF.12 Fragmentation and
Hierarchical Policies section on page 16-39 and Chapter 13, Defining QoS for Multiple Policy
Levels.
Interface-Based FRF.12 Fragmentation

Interface-based FRF.12 Fragmentation allows you to configure LFI on a per-interface basis. When LFI
is enabled on an interface, the interface treats all traffic on the interface as one group with one LFI
setting, regardless of which PVC a packet belongs to.
For example, an Internet service provider (ISP) might offer multiple PVCs on an interface to the same
subscriber. In this case, rather than introducing artificial bandwidth divisions among PVCs of the same
subscriber, the service provider might want to treat all of the PVCs together and offer an aggregate
quality of service with LFI at the Frame Relay interface.
When FRF.12 Fragmentation is enabled on an interface, all of the PVCs on the main interface and its
subinterfaces have fragmentation enabled with the same configured fragment size. When the first PVC
is set up, the interface queues become fragmentation queues. The main interface and all of its
subinterfaces share the same set of queues.
When LFI is disabled for each PVC on a Frame Relay interface, interface fragmentation queues become
normal queues when the last PVC is disabled.
Minimum Fragment Size for FRF.12 Fragmentation

FRF.12 Fragmentation fragments all outbound Frame Relay frames that are larger than the specified
fragment size. Although you can configure from 16 to 1600 bytes as the fragment size, the minimum
supported fragment size is 44 bytes. The default fragment size is 53 bytes.
Configuration Commands for FRF.12 Fragmentation

This section describes the commands that are used to configure FRF.12 Fragmentation. It includes the
following commands:
frame-relay fragment Command (Map-Class), page 16-41
frame-relay fragment end-to-end Command (Interface), page 16-41
16-40
OL-7433-09
Chapter 16

frame-relay fragment Command (Map-Class)

To enable the fragmentation of Frame Relay frames on a Frame Relay map class, use the frame-relay
fragment command in map-class configuration mode. To disable Frame Relay fragmentation, use the
no form of the command. By default, fragmentation is disabled.
frame-relay fragment fragment_size
no frame-relay fragment fragment_size
Syntax Description
fragment_size
Specifies the number of payload bytes from the original Frame Relay frame
that go into each fragment. This number excludes the Frame Relay header
of the original frame. Valid values are from 16 to 1600 bytes. However, the
minimum supported fragment size is 44 bytes. The default is 53 bytes.
frame-relay fragment Command History

Cisco IOS Release
Description
Release 12.0(23)SX
The frame-relay fragment command was introduced on the PRE1.
Release 12.2(27)SBB
Release 12.2(31)SB2
Usage Guidelines for the frame-relay fragment Command

Frame Relay fragmentation is enabled on a per-PVC basis. Before enabling Frame Relay fragmentation,
you must first associate a Frame Relay map class with a specific data-link connection identifier (DLCI),
and then enter map-class configuration mode and enable or disable fragmentation for that map class.
All of the fragments of a Frame Relay frame except the last one have a payload size that is equal to the
fragment size. The last fragment has a payload that is less than or equal to the fragment size.
frame-relay fragment end-to-end Command (Interface)

To enable the fragmentation of Frame Relay frames on an interface, use the frame-relay fragment
end-to-end command in interface configuration mode. To disable Frame Relay fragmentation, use the
no form of the command.
frame-relay fragment fragment_size end-to-end
no frame-relay fragment fragment_size end-to-end
Syntax Description
fragment_size
Specifies the number of payload bytes from the original Frame Relay frame
that go into each fragment. This number excludes the Frame Relay header
of the original frame. Valid values are from 16 to 1600 bytes. There is no
default fragment size.
Note
You must specify the fragment_size. If you do not, an error message

displays.

OL-7433-09
16-41
Chapter 16
frame-relay fragment end-to-end Command History

Cisco IOS Release
Description
Release 12.0(27)S
The frame-relay fragment end-to-end command was introduced on the

PRE1.
Release 12.2(27)SBB
Release 12.2(31)SB2
Usage Guidelines for the frame-relay fragment end-to-end Command

When you enable fragmentation on an interface, all of the PVCs on the main interface and its
subinterfaces have fragmentation enabled with the same configured fragment size.
When configuring fragmentation on an interface with priority (low-latency) queuing, configure the
fragment size to be greater than the largest high-priority frame that would be expected. This
configuration prevents higher priority traffic from being fragmented and queued up behind lower priority
fragmented frames. If the size of a priority frame is larger than the configured fragment size, the priority
frame is fragmented.
All of the fragments of a Frame Relay frame except the last one have a payload size that is equal to the
fragment size. The last fragment has a payload that is less than or equal to the fragment size.
Performance and Scalability for FRF.12 Fragmentation

To enhance performance and scalability, configure the hold-queue command in interface configuration
mode for all physical interfaces when configuring FRF.12 Fragmentation. For example:
Prerequisites for FRF.12 Fragmentation
A hierarchical service policy must be configured and applied to a Frame Relay interface,
subinterface, or DLCI either directly using the service-policy command or using a map class. For
more information, see the FRF.12 Fragmentation and Hierarchical Policies section on page 16-39.
The router must be running Cisco IOS Release 12.0(27)S or Release 12.2(27)SBB, or later releases,
and the appropriate processor card must be installed in the router chassis. Cisco IOS
Release 12.0(27)S and later releases require the PRE1 processor card. Cisco IOS Release 12.2SBB
and later releases require the PRE2.
Frame Relay traffic shaping must be disabled on the interface for PVC-based and interface-based
fragmentation.
Note
The PRE2 does not support Frame Relay traffic shaping. However, for FRF.12 to function
properly, a service policy that shapes traffic is required.
Priority queuing (PQ) must be configured on the interface.
16-42
OL-7433-09
Chapter 16

Note
The Cisco 10000 series router does not require that you configure priority (low-latency) queuing to use
interface-based fragmentation. However, the purpose of LFI is to reduce delay for priority traffic;
therefore, the benefit of LFI is realized when you do configure priority queuing. The class of
delay-sensitive traffic is mapped through a service policy to the priority queue.
Restrictions and Limitations for FRF.12 Fragmentation

PVC-Based Fragmentation
Fragmentation is performed after frames are removed from the bundle.
The frame-relay route command does not support fragmentation.
The show frame-relay fragment command does not provide information about the number of
fragments received, dropped, and transmitted.
The show frame-relay fragment interface command does not provide information about the
number of:
Fragmented packets and bytes received
Packets dropped while being reassembled
Received packets in timeouts
Interleaved packets transmitted
Fragmented packets and bytes transmitted
Fragmented packets dropped when transmitted
We strongly recommend that you use only strict priority queues when configuring PVC-based
FRF.12 fragmentation. For more information, see Chapter 8, Prioritizing Services.
Interface-Based Fragmentation
PVC-based and interface-based fragmentation cannot be configured at the same time.
The rate of the interface or subinterface must be between 64 and 2048 kbps.
Interface fragmentation and Frame Relay traffic shaping cannot be configured at the same time on
an interface. Do not configure the frame-relay traffic-shaping command on an interface with
Frame Relay interface fragmentation configured.
The frame-relay fair-dlci queuing command cannot be configured on an interface with Frame
Relay interface fragmentation configured. To specify QoS on FRF.12-enabled interfaces, use service
policies (see Chapter 13, Defining QoS for Multiple Policy Levels.).
We strongly recommend that you use only strict priority queues when configuring interface-based
FRF.12 fragmentation. For more information, see Chapter 8, Prioritizing Services.

OL-7433-09
16-43
Chapter 16
Configuring PVC-Based FRF.12 Fragmentation

To configure PVC-based FRF.12 Fragmentation, perform the following configuration tasks:
Enabling FRF.12 Fragmentation on a Map Class, page 16-44
Attaching the Map Class, page 16-45
Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation, page 16-52
Enabling FRF.12 Fragmentation on a Map Class

To enable FRF.12 Fragmentation on a Frame Relay map class, enter the following commands beginning
Command
Purpose
Step 1

map-class-name
Creates or modifies a map class and enters map-class

configuration mode.
Step 2
Router(config-map-c)# frame-relay fragment

fragment_size

Enables the fragmentation of Frame Relay frames on a Frame
Relay map class.
fragment_size specifies the number of payload bytes from the
original Frame Relay frame that go into each fragment. This
number excludes the Frame Relay header of the original frame.
Valid values are from 16 to 1600 bytes. The default is 53 bytes.
Note
Step 3
All of the fragments of a Frame Relay frame, except the

last, have a payload size that is equal to the fragment_size.
The last fragment has a payload that is less than or equal
to the fragment_size.

inbound interface.
output indicates to apply the service policy to the traffic on the
outbound interface.
Note

keyword.

Step 4
Router(config-map-c)# no frame-relay
adaptive-shaping
Disables Frame Relay adaptive traffic shaping.
16-44
OL-7433-09
Chapter 16

Attaching the Map Class

To attach the map class, perform the following configuration tasks:
Attaching a Map Class to a Frame Relay Interface or Subinterface, page 16-45
Attaching a Map Class to a Frame Relay DLCI, page 16-48
Attaching a Map Class to a Frame Relay Interface and a Service Policy to a Subinterface, page 16-50
Attaching a Map Class to a Frame Relay Interface or Subinterface

To attach a map class to a Frame Relay interface or subinterface, enter the following commands
Command
Purpose
Step 1
Router(config)# interface serial

slot/module/port.T1#:channel
Creates or modifies a serial interface. Enters interface

configuration mode.
Step 2

out}

interfaces.
length is a number that specifies the maximum number of packets
in the queue. Valid values are from 0 to 4096. We recommend
4096 packets for all line cards, except the ATM OC-12 line card.
By default, the input queue is 75 packets and the output queue is
40 packets.
Step 3
Step 4
Router(config-if)# no ip
directed-broadcast
Disables the translation of a directed broadcast to physical

broadcasts. Instead, the directed broadcasts are dropped.
Step 5
Router(config-if)# encapsulation
frame-relay [ietf | cisco]

(Optional) ietf sets the encapsulation method to comply with the
Internet Engineering Task Force (IETF) standard (RFC 1490).
Use this keyword when connecting to another vendors equipment
across a Frame Relay network.
connection identifier (DLCI) and 2 bytes to identify the packet
type. This is the default encapsulation type.
Step 6
Associates a map class with the Frame Relay interface.

name is the name of the map class.
Note

map class to this main interface, any subinterfaces
configured on the main interface, and any DLCIs
configured on the subinterfaces.

OL-7433-09
16-45
Chapter 16
Step 7
Command
Purpose

slot/module/port.T1#:channel.subinterfacenumber [point-to-point]
Creates or modifies a serial subinterface. Enters subinterface

configuration mode.
The point-to-point subinterface is used to establish a PVC
connection to an interface on the remote end of the Frame Relay
connection.
Step 8
Router(config-subif)# ip address address

mask

subinterface.
Step 9
Router(config-subif)# no ip
directed-broadcast

Step 10
Router(config-subif)# frame-relay class

name
Associates a map class with the subinterface.

Note
Step 11

map class to this subinterface and any DLCIs configured
on the subinterface.
Assigns a data-link connection identifier (DLCI) to the Frame

Relay subinterface. Enters Frame Relay DLCI configuration
mode.
dlci is a number that identifies the data-link connection on the
16-46
OL-7433-09
Chapter 16

Configuration Examples for Attaching a Map Class to a Frame Relay Interface and Subinterface
Example 16-9 shows how to attach a map class with fragmentation enabled to a Frame Relay interface.
In the example, fragmentation is enabled in the map class named lfi_map_class and the fragment size is
set at 300 bytes. The QoS service policy named policy_13 is also applied to the map class for outbound
traffic. The map class is applied to the serial interface 5/0/0/1:0, which has two subinterfaces configured.
Serial subinterface 5/0/0/1:0.1 has DLCI 17 and subinterface 5/0/0/1:0.2 has DLCI 18. Because the map
class with fragmentation enabled is applied to the main interface, traffic on DLCI 17 and DLCI 18 is
subject to fragmentation and interleaving.
Example 16-9 Attaching a Map Class to a Frame Relay Interface
Router(config)# map-class frame-relay lfi_map_class
Router(config-map-c)# frame-relay fragment 300
Router(config-map-c)# service-policy output policy_13
Router(config-map-c)# no frame-relay adaptive-shaping
!
Router(config-if)# frame-relay class lfi_map_class
!
Router(config)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-subif)# no ip directed-broadcast
!
Example 16-10 shows how to attach a map class with fragmentation enabled to a subinterface. In the
example, fragmentation is enabled in the map class named lfi_map_class and the fragment size is set at
300 bytes. The QoS service policy named policy_13 is also applied to the map class for outbound traffic.
The map class is applied to the serial subinterface 5/0/0/1:0.1 on which DLCI 17 is configured.
Therefore, Frame Relay traffic on DLCI 17 is subject to fragmentation and interleaving. Because the
lfi_map_class is also attached to serial subinterface 5/0/0/1:0.2, traffic on DLCI 18 is also subject to
fragmentation and interleaving.
Note
If the configuration example specified to apply another map class to subinterface 5/0/0/1:0.2, and that
map class did not enable fragmentation, then DLCI 18 traffic would not be subject to LFIonly
DLCI 17 traffic would be fragmented and interleaved.
Example 16-10 Attaching a Map Class to a Frame Relay Subinterface
!

OL-7433-09
16-47
Chapter 16

!
Router(config-subif)# frame-relay class lfi_map_class
!
Router(config-subif)# frame-relay class lfi_map_class
Attaching a Map Class to a Frame Relay DLCI

To attach a map class to a Frame Relay DLCI, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1


configuration mode.
Step 2

out}

interfaces.
4096 packets for all line cards. By default, the input queue is 75
packets and the output queue is 40 packets.
Step 3
Step 4
directed-broadcast

Step 5

Step 6

Creates or modifies a serial interface or subinterface. Enters

interface or subinterface configuration mode.
16-48
OL-7433-09
Chapter 16

Step 7
Command
Purpose

mask

subinterface.
Step 8
directed-broadcast

Step 9

configuration mode.
Step 10

name
Associates a map class with the DLCI.

Note
When a map class is associated with a DLCI, only traffic

on the DLCI is fragmented.
Configuration Example for Attaching a Map Class to a Frame Relay DLCI

Example 16-11 shows how to attach a map class with LFI enabled to a Frame Relay DLCI. In the
example, fragmentation is enabled in the map class named lfi_map_class and the fragment size is set at
300 bytes. The QoS service policy named policy_13 is also applied to the map class for outbound traffic.
The main interface 5/0/0/1:0 has two subinterfaces with DLCI configured. The lfi_map_class is attached
to DLCI 17 on subinterface 5/0/0/1:0.1. Therefore, the router fragments and interleaves only the traffic
on DLCI 17 and applies the QoS actions defined in policy_13 to only DLCI 17 traffic.
Example 16-11 Attaching a Map Class to a Frame Relay DLCI
!
!

OL-7433-09
16-49
Chapter 16
Router(config-fr-dlci)# frame-relay class lfi_map_class

!
Attaching a Map Class to a Frame Relay Interface and a Service Policy to a Subinterface
To attach a map class to a Frame Relay interface and a service policy to a subinterface, enter the
Command
Purpose
Step 1


configuration mode.
Step 2

out}

interfaces.
Step 3
Step 4
directed-broadcast

Step 5

Step 6
Associates a map class with the main interface.

Note
Step 7


map class to this interface, its subinterfaces, and any
DLCIs configured on the main interface and its
subinterfaces.

configuration mode.
The point-to-point subinterface is used to establish a PVC
connection to an interface on the remote end of the Frame Relay
connection.
16-50
OL-7433-09
Chapter 16

Step 8
Command
Purpose

mask

subinterface.
Step 9
directed-broadcast

Step 10
Attaches the policy map you specify to the subinterface.

inbound interface.
outbound interface.
Note

keyword.

Step 11

Relay subinterface. Enters Frame Relay DLCI configuration
mode.
Configuration Example for Attaching a Map Class to a Frame Relay Interface and a Service Policy to a DLCI
Example 16-12 shows how to attach a map class with fragmentation enabled to a Frame Relay interface
and attach a service policy to a DLCI. In the example, fragmentation is enabled in the map class named
lfi_map_class and the fragment size is set at 300 bytes. The map class is applied to the serial
interface 5/0/0/1:0, which has two subinterfaces configured. DLCI 17 is configured on
subinterface 5/0/0/1:0.1 and DLCI 18 is configured on subinterface 5/0/0/1:0.2. Because the map class
with fragmentation enabled is applied to the main interface, all of the traffic on the main interface, the
two subinterfaces, and the DLCIs is fragmented. However, because the service policy is applied directly
on DLCI 17 and DLCI 18, only the traffic on those DLCIs is subject to the QoS actions defined in the
service policy.

OL-7433-09
16-51
Chapter 16
Example 16-12 Attaching a Map Class to a Frame Relay Interface and a Service Policy to a DLCI
Router(config)# map-class frame-relay lfi_map_class_one
!
Router(config-if)# frame-relay class lfi_map_class
!
Router(config-fr-dlci)# service-policy output policy_13
!
Router(config-fr-dlci)# service-policy output policy_13
Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation

To configure a hierarchical policy and PVC-based FRF.12 Fragmentation, perform the following
Configuring the Child QoS Policy, page 16-52
Configuring the Parent QoS Policy, page 16-53
Enabling FRF.12 Fragmentation on a Frame Relay Map Class, page 16-54
Attaching a Map Class to a Frame Relay DLCI, page 16-55
Configuring the Child QoS Policy

To configure a child QoS policy, enter the following commands beginning in global configuration mode:
Command
Purpose
Step 1
policy-map-name

configuration mode.
Step 2

Note
Repeat this step to create additional traffic classes in the

child policy map. Define policy map actions for each class
such as the action defined in Step 4. Be sure that you
define only one traffic class as the priority class.
16-52
OL-7433-09
Chapter 16

Step 3
Command
Purpose
Configures a traffic class as a priority queue.

Note
Step 4
In Cisco IOS Release 12.0(25)S and Release 12.3(7)XI,

and later releases, this command has no arguments. To
specify a bandwidth rate, use the police command. For
more information, see Chapter 6, Policing Traffic.
Router(config-pmap-c) police [cir] bps

[bc] burst-normal [be] burst-excess
[conform-action action] [exceed-action
action] [violate-action action]
Configures single-rate traffic policing based on bits per second or

as a percentage of the parent policys shape rate, or configures
two-rate traffic policing based on bits per second.
or

indicates an average rate at which the policer meters traffic. CIR
is based on the interface shape rate.
Router(config-pmap-c)# police [cir]

percent percent [bc] normal-burst-in-msec
action] [exceed-action action]
or
police {cir cir} [bc] burst-normal [pir
pir] [be] peak-burst [conform-action

bandwidth specified in percent to calculate the CIR. Valid values
are from 1 to 100.
[bc] burst-normal and [bc] normal-burst-in-msec specify the
normal or committed burst size (CBS) that the first token bucket
uses for policing traffic. Specify the burst-normal value in bytes
and normal-burst-in-msec value in milliseconds (ms).
[be] burst-excess and [be] excess-burst-in-msec specify the
excess burst size (EBS) used by the second token bucket for
policing. Specify the burst-excess value in bytes and
excess-burst-in-msec value in milliseconds (ms).
[be] peak-burst is the peak information rate (PIR). Indicates the
rate at which the second token bucket is updated. The pir specifies
the PIR value in bits per second.
Configuring the Parent QoS Policy

To configure the parent QoS policy, enter the following commands beginning in global configuration
mode:
Command
Purpose
Step 1
policy-map-name
Configures the parent policy. Enters policy-map configuration

mode.
Step 2

Configures the class-default class in the parent policy. Enters

OL-7433-09
16-53
Chapter 16
Step 3
Command
Purpose
Shapes traffic to a specified bit rate.

kbps-value is the bit rate (in kilobits per second) used to shape the
traffic.
Step 4
policy-map-name
Applies the child policy to the parent class-default class.

policy map.
Note
Do not specify the input or output keyword when

applying a service policy to another child policy or to a
parent policy.
Enabling FRF.12 Fragmentation on a Frame Relay Map Class

To enable FRF.12 Fragmentation on a Frame Relay map class, enter the following commands beginning
Command
Purpose
Step 1

map-class-name
Creates or modifies a map class. Enters map-class configuration

mode.
Step 2

inbound interface.
outbound interface. For FRF.12 Fragmentation, specify the
output keyword.
Note

keyword.

Step 3
Router(config-map-c)# frame-relay
fragment fragment_size

Relay map class.
Valid values are from 16 to 1600 bytes. The default is 53 bytes.
16-54
OL-7433-09
Chapter 16

Attaching a Map Class to a Frame Relay DLCI

To attach a map class to a Frame Relay DLCI, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1


configuration mode.
Step 2
Router(config-if)# hold-queue length {in

| out}

interfaces.
Step 3
(Optional) Removes any existing IP address from the main

interface.
Step 4
Router(config-if)# no ip directed
broadcast
(Optional) Disables IP directed broadcasts. Instead, these

broadcasts are dropped.
Step 5

Step 6

slot/module/port/T1#:channel
subinterface-number [point-to-point]

configuration mode.

OL-7433-09
16-55
Chapter 16
Step 7
Command
Purpose

configuration mode.
Step 8

name
Associates a map class with the individual DLCI.

name is the name of the map class that you want to associate with
the DLCI.
Note

map class to only this individual DLCI.
Configuration Example for Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation
Example 16-13 shows how use a hierarchical policy when fragmenting packets on a Frame Relay DLCI.
In the example, access control lists (ACLs) 101 and 102 are defined and used as match criteria in two
class maps to classify traffic. The child policy map named qos_pq_cbwfq_0 defines the traffic class
named acl_101 as priority traffic and polices the traffic at 10 percent of the parent shape rate. The traffic
class named acl_102 requests 30 percent of the bandwidth. The parent policy map named outer_policy
shapes traffic at 768 kbps. The child policy is applied to the parent class-default class. The parent policy
is applied to the map class named PQ_FR_CLASS_0. This map class sets the fragment size at 768 bytes.
The map class is applied to DLCI 27 on serial interface 5/0/0/1:0.1.
Example 16-13 Configuring a Hierarchical Policy and PVC-Based FRF.12 Fragmentation
Router(config)# access-list 101 permit udp any eq 16384 any eq 16384
Router(config)# access-list 102 permit udp any eq 3000 any eq 3000
Router(config)# class-map match-all acl_101
Router(config-cmap)# class-map match-all acl_102
!
Router(config)# policy-map qos_pq_cbwfq_0
Router(config-pmap)# class acl_101
Router(config-pmap-c)# class acl_102
!
Router(config-pmap)# policy-map outer_policy
Router(config-pmap-c)# service-policy qos_pq_cbwfq_0
!
Router(config)# map-class frame-relay PQ_FR_CLASS_0
16-56
OL-7433-09
Chapter 16

Router(config-map-c)# service-policy output outer_policy

!
!
Router(config-if)# interface serial 5/0/0/1:0.1 point-to-point
Router(config-fr-dlci)# frame-relay class PQ_FR_CLASS_0
Configuring Interface-Based FRF.12 Fragmentation

To configure interface-based FRF.12 Fragmentation, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1


configuration mode.
Step 2

out}

interfaces.
Step 3
(Optional) Removes any existing IP address from the main

interface.
Step 4
Router(config-if)# no ip directed
broadcast
(Optional) Disables IP directed broadcasts. Instead, these

broadcasts are dropped.
Step 5


OL-7433-09
16-57
Chapter 16
Step 6
Command
Purpose
Router(config-if)# frame-relay fragment

fragment_size end-to-end

Relay interface.
Valid values are from 16 to 1600 bytes. However, the minimum
supported fragment size is 44 bytes. There is no default value.
Step 7


inbound interface.
outbound interface.
Note

keyword.
Configuration Example for Enabling Interface-Based FRF.12 Fragmentation

Example 16-14 shows how to enable FRF.12 Fragmentation on an interface. In the example, end-to-end
FRF.12 fragmentation is enabled on the main serial interface 5/0/0/1:0 and the fragment size is set at 200
bytes. The service policy named Premium is attached to the main interface in the outbound direction.
The main interface has two subinterfaces: serial subinterface 5/0/0/1:0.1 with DLCI 27 and
subinterface 5/0/0/1:0.2 with DLCI 28.
Example 16-14 Enabling Interface-Based Fragmentation
Router(config-if)# frame-relay fragment 200 end-to-end
Router(config-subif)# no ip directed broadcast
Router(config-subif)# interface serial 5/0/0/1:0.2 point-to-point
Router(config-subif)# no ip directed broadcast
16-58
OL-7433-09
Chapter 16


Configuration Example for MLP Over Serial-Based LFI, page 16-59
Configuration Example for Single-VC MLP Over ATM-Based LFI, page 16-60
Configuration Example for Multi-VC MLP Over ATM-Based LFI, page 16-61
Configuration Examples for PVC-Based FRF.12 Fragmentation, page 16-63
Configuration Example for Interface-Based FRF.12 Fragmentation, page 16-64
Configuration Example for MLP Over Serial-Based LFI

Example 16-15 shows a sample configuration for MLP over serial-based LFI. In the example, the MLP
bundle named Multilink 2 consists of three serial links: 8/0/0.2/7:0, 8/0/0.2/8:0, and 8/0/0.2/9:0.
Fragmentation and interleaving are both enabled on the bundle.
Example 16-15 Configuring MLP Over Serial-Based LFI
!
Router(config)# controller SONET 8/0/0
Router(config-controller)# framing SONET
Router(config-controller)# path 2 controller t3
!
Router(config)# controller T3 8/0/0.2
Router(config-controller)# overhead c2 4
Router(config-controller)# framing m23
Router(config-controller)# t1 7 channel-group 0 timeslots 1-24
!
Router(config)# class-map match-all prec_5
!
Router(config)# policy-map policy_MLPLFI
Router(config-pmap)# class prec_5
Router(config-pmap-c)# bandwidth remaining percent 20
!
Router(config)# interface Multilink2
Router(config-if)# load-interval 30
Router(config-if)# ppp acfc local request
Router(config-if)# ppp acfc remote apply
Router(config-if)# ppp chap hostname group2
Router(config-if)# ppp multilink fragment delay 2
Router(config-if)# service-policy output policy_MLPLFI
!
Router(config)# interface serial 8/0/0.2/7:0
Router(config-subif)# encapsulation ppp
Router(config-subif)# load-interval 30

OL-7433-09
16-59
Chapter 16
Router(config-subif)# no fair-queue
Router(config-subif)# no keepalive
Router(config-subif)# ppp chap hostname group2
Router(config-subif)# ppp multilink
Router(config-subif)# ppp multilink group 2
!
!
Configuration Example for Single-VC MLP Over ATM-Based LFI

Example 16-16 shows a sample configuration for Single-VC MLP over ATM-based LFI. This
configuration uses a multilink interface and a virtual template interface. In the example, MLP and the
interleaving of Real-Time Transport Packets (RTP) is enabled on the Multilink 10,020 interface. The
maximum delay allowed for the transmission of a packet fragment is 8 ms. The Multilink 10,020
interface is associated with the MLP bundle. The QoS service policy named Premium is attached to the
Multilink 10,020 interface. MLP is enabled on the virtual template interface named virtual-template1,
which is applied to PVC 0/32 on ATM subinterface 4/0/0.1. This PVC is associated with the bundle.
Example 16-16 Configuring Single-VC MLP Over ATM-Based LFI
!
Router(config)# class-map Business
!
Router(config-pmap)# policy-map Premium
!
Router(config-if)# ppp chap hostname router2
!
16-60
OL-7433-09
Chapter 16


!
!
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol ppp virtual-template1
Configuration Example for Multi-VC MLP Over ATM-Based LFI

Example 16-17 shows how to configure Multi-VC MLP over ATM-based LFI. In the example, the virtual
template named virtual-template 2 is applied to PVCs 101/34, 101/35, and 101/36. Each of these PVCs
is assigned to MLP bundle group 8. Notice that all of the member links have the same encapsulation type.
The router does not support member links with different encapsulation types.
Example 16-17 Configuring Multi-VC MLP Over ATM-Based LFI
!
Router(config)# class-map Gold
!
Router(config-pmap)# policy-map Business
!
Router(config-if)# ppp chap hostname router2
Router(config-if)# ip mroute-cache
!
Router(config-if)# no atm ilmi-keepalive
!

OL-7433-09
16-61
Chapter 16

Router(config-if-atm-vc)# encapsulation aal5mux
Router(config-if-atm-vc)# ppp virtual-template 2
!
!
Configuration Example for MLP Over Frame Relay-Based LFI

Example 16-18 shows how to add Frame Relay links to a MLP bundle. In the example, MLP is enabled
on the Multilink 10002 interface and on the virtual template named Virtual-Template1. The
service-policy named Business is applied to the Multilink 10002 interface. Virtual-Template 1 is applied
to DLCI 101 on the serial subinterface 1/0/1.1.
Example 16-18 Configuring MLP Over Frame Relay-Based LFI
Router(config-if)# ppp multilink fragment disable
Router(config-if)# ppp multilink fragment delay 8
!
Router(config)# interface serial1/0/1
Router(config-if)# no keepalive
!
Router(config)# interface serial1/0/1.1 point-to-point
Router(config-if)# no keepalive
Router(config-if)# frame-relay interface-dlci 18 ppp Virtual-Template209
!
Router(config-if)# description mlp_lfi_c10k
Router(config-if)# ppp chap hostname lfiofr-10002
!
16-62
OL-7433-09
Chapter 16

Configuration Examples for PVC-Based FRF.12 Fragmentation

Example 16-19 shows how to use a map class to configure PVC-based FRF.12 Fragmentation and attach
the map class to a main interface. In the example, fragmentation is enabled in the map class named frag
and the fragment payload size is set at 40 bytes. The frag map class also enables weighted fair queuing
and has the QoS service policy named Bronze applied for outbound traffic. The frag map class is
associated with serial interface 1/0/0/1:0. The main interface has two subinterfaces configured:
subinterface 1/0/0/1:0.1 with DLCI 100 and subinterface 1/0/0/1:0.2 with DLCI 101. Because the frag
map class with fragmentation enabled is attached to the main interface, fragmentation is also enabled on
DLCI 100 and DLCI 101.
Example 16-19 Configuring PVC-Based FRF.12 Fragmentation on an Interface Using a Map Class
Router(config)# map-class frame-relay frag
Router(config-map-c)# frame-relay cir 128000
Router(config-map-c)# frame-relay bc 1280
Router(config-map-c)# frame-relay fair-queue
Router(config-map-c)# service-policy output Bronze
!
Router(config-if)# frame-relay class frag
!
!
Example 16-20 shows how to use a map class to configure FRF.12 Fragmentation and attach the map
class to a subinterface. In the example, the fragmentation is enabled on the map class named lfi-class1
and the map class is attached to serial subinterface 5/0/0/1:0.1. The QoS service policy named Business
is also attached to subinterface 5/0/0/1:0.1. In this configuration, all of the traffic on
subinterface 5/0/0/1:0.1 and all of the DLCIs configured on the subinterface are subject to fragmentation
and interleaving.
Example 16-20 Configuring PVC-Based FRF.12 Fragmentation on a Subinterface Using a Map Class
Router(config)# map-class frame-relay lfi-class1
!
!

OL-7433-09
16-63
Chapter 16
Router(config-subif)# service-policy Business
Router(config-subif)# frame-relay class lfi-class1
!
Example 16-21 shows how to use a map class to configure FRF.12 Fragmentation and attach the map
class to a Frame Relay DLCI. In the example, fragmentation is enabled in the Frame Relay map class
named Voice and the fragment size is set at 320 bytes. The Voice map class also enables priority queuing.
The policy map named Business is also applied to the Voice map class. The map class is attached to
DLCI 20 configured on the point-to-point serial subinterface 7/0/0/1:0.1.
Example 16-21 Configuring PVC-Based FRF.12 Fragmentation on a DLCI Using a Map Class
Router(config)# map-class frame-relay Voice
Router(config-map-c)# frame-relay ip rtp priority 16384 16383 25
Router(config-map-c)# service-policy output Business
Router(config-if)# encapsulation frame-relay ietf
Router(config-if)# frame-relay intf-type dce
Router(config-fr-dlci)# frame-relay class Voice
Configuration Example for Interface-Based FRF.12 Fragmentation

Example 16-22 shows how to configure FRF.12 Fragmentation on serial interface 3/0/0.1/1:0. In the
example, the fragment size is set at 300 bytes. The service policy named 11q is attached to the serial
interface 3/00/0.1/1:0 and applied to the outbound packets on the main interface, subinterface, and
DLCIs. Because fragmentation is enabled directly on the main interface, all of the traffic on the main
interface, the subinterfaces, and the DLCIs is subject to fragmentation and interleaving.
Example 16-22 Configuring Interface-Based FRF.12 Fragmentation
Router(config)# access-list 101 match ip any host 10.16.0.2
!
Router(config)# policy-map llq
!
16-64
OL-7433-09
Chapter 16

Verifying and Monitoring Link Fragmentation and Interleaving
Router(config-if)# bandwidth 128

Router(config-if)# clock rate 128000
Router(config-if)# service-policy output llq
Router(config-if)# frame-relay fragment 300 end-to-end
!
Router(config)# interface serial 3/0/0.1/1:0.1 point-to-point

The Cisco 10000 series routers collect information about the number of:
Fragments and bytes sent
Unfragmented packets and bytes sent and received
Assembled packets and bytes received
Received fragments and bytes dropped due to excessive size of coalesced packets, out-of-sequence
arrival, duplicate sequence numbers, unexpected begin fragment, or arrival without a begin fragment
The PRE1 counts only output fragments while the PRE2 counts both fragments and packets.
To verify and monitor the configuration of link fragmentation and interleaving, enter the following
Command
Purpose
Router# debug atm lfi
Displays debug information for MLP over ATM-based LFI.
Router# debug frame-relay fragment
Displays information related to Frame Relay fragmentation on a

PVC.
Router# debug frame-relay ppp
Displays error messages for link states and Local Management

Interface (LMI) status changes for PPP over Frame Relay
sessions.
Router# debug ppp multilink events
Displays information about events affecting multilink groups

established for Bandwidth Allocation Control Protocol (BACP).
Router# debug ppp multilink fragments
Displays information about individual multilink fragments and

important multilink events.
Note
Router# show atm pvc
This command has memory overhead and should not be

used when memory is scarce or when traffic is very high.
Displays all ATM permanent virtual connections (PVCs) and

traffic information.

OL-7433-09
16-65
Chapter 16
Command
Purpose
Router# show frame-relay fragment [interface

interface] [dlci]
(FRF.12 Fragmentation only) Displays information about Frame

Relay fragmentation such as fragmentation type, configured
fragment size, and the number of fragments transmitted, received,
and dropped. When you specify a specific interface and DLCI,
additional information appears.
For the PRE2, the show frame-relay fragment command
displays the number of output fragments.
interface is the type of interface for which you want to view
Frame Relay fragmentation information.
interface is the number of the interface containing the data-link
connection identifier (DLCI) for which you want to display
fragmentation information.
dlci is a specific number that identifies a DLCI on the interface.
If you do not specify any parameter options, the command
displays a summary of each DLCI configured for fragmentation.
Router# show frame-relay pvc [interface

interface] [dlci]
Displays statistics about PVCs for Frame Relay interfaces.

For MLP over Frame Relay-based LFI, this command
currently displays statistics for system traffic only. Data
statistics do not display.
Note
interface is the type of interface for which you want to view

Frame Relay fragmentation information.
interface is the number of the interface containing the data-link
connection identifier (DLCI) for which you want to display
fragmentation information.
dlci is a specific number that identifies a DLCI on the interface.
Statistics for the specified PVC also display when you specify a
DLCI.
Router# show interfaces interface
Displays fragment and packet statistics for the interface you

specify.
(FRF.12) For the PRE1, this command displays the number of
output fragments.
(FRF.12) For the PRE2 this command displays the number of
output packets. Output fragments display using the show
frame-relay fragment.
Interleaving data displays only if there are interleaves. For
example, the following line shows interleaves:
Output queue: 315/64/164974/31191
(size/threshold/drops/interleaves)
16-66
OL-7433-09
Chapter 16

Command
Purpose
Router# show interfaces virtual-access number

[configuration]
Displays status, traffic data, and configuration information about

the virtual access interface you specify.
Note
This command currently displays statistics for system

traffic only. Statistics for bundle traffic do not display.
For information about bundle traffic, see the show
interfaces or show ppp multilink command.
number is the number of the virtual access interface.

(Optional) configuration restricts output to configuration
information.
Router# show ppp multilink [bundle-interface]
Displays bundle information for all of the MLP bundles and their
PPP links configured on the router.
If you specify bundle-interface, the command displays
information for only that specific bundle.
(Optional) bundle-interface specifies the multilink interface (for
example, Multilink 5).
Displays information about the current router configuration,

including information about each interface configuration.
Verification Example for MLP Over Serial-Based LFI

Example 16-23 shows sample output from the show ppp multilink interface command. This example
displays information about the MLP over serial-based LFI configuration provided in Example 16-15 on
page 16-59.
Example 16-23 show ppp multilink interface Command Sample Output
Router# show ppp multilink interface Multilink2
Multilink2, bundle name is group2
Endpoint discriminator is group2
Bundle up for 02:31:57, 1/255 load
Receive buffer limit 36000 bytes, frag timeout 1000 ms
Bundle is Distributed
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x0 received sequence, 0x1 sent sequence
C10K Multilink PPP info
Bundle transmit info
send_seq_num
0x1
Bundle reassembly info
expected_seq_num: 0x000000
Member links: 3 active, 0 inactive (max 10, min not set)
Se8/0/0.2/7:0, since 02:31:57, 384 weight, 378 frag size
Se8/0/0.2/9:0, since 00:03:46, 384 weight, 378 frag size
Se8/0/0.2/8:0, since 00:03:06, 384 weight, 378 frag size HQF2_R2#
Multilink2
Service-policy output: policy_MLPLFI
Class-map: prec_5 (match-all)

OL-7433-09
16-67
Chapter 16

Absolute priority
Police:
Match: any
Verification Examples for FRF.12 Fragmentation

Example 16-24 shows sample output from the show frame-relay fragment command. In this example,
the command does not specify a specific interface or DLCI. Therefore, the output displays a summary
of each subinterface and DLCI configured for fragmentation.
Example 16-24 show frame-relay fragment Command Sample OutputAll Subinterfaces and DLCIs
Router# show frame-relay fragment
interfacedlcifrag-typesizein-fragout-fragdropped-frag
se5/0/0/1:0.117end-to-end300000
se5/0/0/1:0.118end-to-end300000
Example 16-25 shows sample output from the show frame-relay fragment command when a specific
interface is specified. The output displays fragmentation information for only the specified subinterface
and DLCI (serial subinterface 3/0/0.1/1:0.1, DLCI 109).
Example 16-25 show frame-relay fragment Command Sample OutputSpecific Subinterface and DLCI
Router# show frame-relay fragment interface serial 3/0/0.1/1:0.1 109
fragment size 300 fragment type end-to-end
in fragmented pkts 0 out fragmented pkts 1320
in fragmented bytes 0 out fragmented bytes 331760
in un-fragmented pkts 0 out un-fragmented pkts 0
in un-fragmented bytes 0 out un-fragmented bytes 0
in assembled pkts 0 out pre-fragmented pkts 0
in assembled bytes 0 out pre-fragmented bytes 0
in dropped reassembling pkts 0 out dropped fragmenting pkts 0
in DE fragmented pkts 0 out DE fragmented pkts 0
in DE un-fragmented pkts 0 out DE un-fragmented pkts 0
in timeouts 0
in out-of-sequence fragments 0
in fragments with unexpected B bit set 0
in fragments with skipped sequence
16-68
OL-7433-09
Chapter 16

Example 16-26 shows sample output from the debug frame-relay fragment command for the specified
interface and DLCI (serial interface 0/0, DLCI 109).
Example 16-26 debug frame-relay fragment Command Sample OutputSpecific Interface and DLCI
Router# debug frame-relay fragment interface serial 0/0 109
This may severely impact network performance.
You are advised to enable 'no logging console debug'. Continue?[confirm]
Frame Relay fragment/packet debugging is on
Displaying fragments/packets on interface Serial0/0 dlci 109 only
Serial0/0(i): dlci 109, rx-seq-num 126, exp_seq-num 126, BE bits set, frag_hdr 04 C0 7E
Serial0/0(o): dlci 109, tx-seq-num 82, BE bits set, frag_hdr 04 C0 52
Feature
Documentation
FRF.12 End-to-End Fragmentation
Frame Relay Fragmentation Implementation Agreement, Frame

Relay Forum, December, 1997
Voice over Frame Relay Using FRF.11 and FRF.12,
Understanding and Troubleshooting Frame Relay Fragmentation
VoIP over Frame Relay with Quality of Service (Fragmentation,
Traffic Shaping, LLQ / IP RTP Priority)
Interface-Based FRF.12 Fragmentation
Frame Relay Queuing and Fragmentation at the Interface,

Release 12.2(14)S feature module
Cisco IOS Wide-Area Networking Configuration Guide,
Release 12.3
Part 1: Wide-Area Networking Protocols > Configuring Frame
Relay > Frame Relay Queueing and Fragmentation at the
Interface
Link Fragmentation and Interleaving for Frame Relay and ATM

Virtual Circuits, Release 12.1(5)T feature module
Cisco IOS Quality of Service Solutions Configuration Guide
Link Efficiency Mechanisms > Link Efficiency Mechanisms
Overview > Link Fragmentation and Interleaving for Frame
Relay and ATM VCs
Configuring Link Fragmentation and Interleaving for Frame
Relay and ATM Virtual Circuits

OL-7433-09
16-69
Chapter 16
Feature
Documentation
Multilink PPP (MLP)
Cisco 10000 Series Router Broadband Aggregation, Leased-Line,

and MPLS Configuration Guide
RFC 1990, The PPP Multilink Protocol
Policy Maps

PPP Encapsulation
RFC 1661, The Point-to-Point Protocol
PPP in Frame Relay
RFC 1973, PPP in Frame Relay
PVC-Based FRF.12 Fragmentation
Release Notes for the Cisco 10000 Series for Cisco IOS
Release 12.0(23)SX
16-70
OL-7433-09
CH A P T E R
17

In previous provisioning models, during the subscription process a subscriber chooses a service level
based on bandwidth options. If the subscriber later decides more bandwidth is needed, the subscriber
calls the provisioning center to change services. For example, a subscriber might choose a basic service
with low bandwidth and later change to a premium service with high bandwidth. The Cisco 10000 series
router, however, offers a dynamic QoS model that allows you to download QoS parameters from the
RADIUS server to an ATM VC.
Dynamic Bandwidth Selection (DBS) allows wholesale service providers to sell different levels of
service to retail service providers, based on the bandwidth of the ATM VC connection. The retail service
provider can then offer subscribers the ability to choose services with varying levels of bandwidth
allocation. If a subscriber changes services, the service provider can dynamically change the ATM
shaping on the VC based on the RADIUS profile of the subscriber. RADIUS accounting mechanisms
control billing for the different services.
An extension to DBS provides the ability to modify an existing VC weight and watermark values using
a RADIUS Pull model in which the subscriber triggers the parameter changes. The DBS
ExtensionsVC Weight and Watermark feature enables the modification of existing VC weight and
watermark values without tearing down and recreating the VC.
The Define Interface Policy-Map AV Pairs AAA feature allows the router to apply QoS parameters
dynamically to sessions, using two RADIUS vendor-specific attributes (VSAs).
Per session queuing and shaping for PPPoE over VLANs using RADIUS enables you to dynamically
apply queuing and shaping policies to PPPoE over VLAN sessions.
This chapter describes the features that support dynamic subscriber services. It includes the following
topics:
Applying Traffic Shaping Parameters Using RADIUS Profiles, page 17-2
Dynamically Changing VC Weight and Watermark Values, page 17-18
Applying QoS Parameters Dynamically to Sessions, page 17-24
Shaping PPPoE Over VLAN Sessions Using RADIUS, page 17-34
Shaping and Queuing Per-Session Traffic on LNS, page 17-44
Queuing PPP Sessions on ATM VCs, page 17-50

OL-7433-09
17-1
Chapter 17

Dynamic bandwidth selection (DBS) dynamically changes ATM traffic shaping parameters based on a
subscribers RADIUS profile. This profile contains such QoS traffic shaping parameters as:
VC traffic management class (VBR or UBR)
The Cisco 10000 series router supports DBS for the unspecified bit rate (UBR) and variable bit
rate-nonreal time (VBR-nrt) categories of the ATM traffic management class:
UBR service classThe router applies only the PCR parameter to a UBR configured VC, depending
on the port configuration.
VBR-nrt service classThe router applies the PCR and SCR parameters to the VBR-nrt VC.
As shown in Figure 17-1, when a subscriber initiates a Point-to-Point Protocol (PPP) over ATM (PPPoA)
or PPP over Ethernet (PPPoE) session to the Cisco 10000 series router, DBS retrieves the RADIUS user
profile and sets the QoS parameters to the shaping parameters specified in the user profile. The profile
might contain PCR and SCR values for DBS configuration. If the profile specifies both values, DBS
configures the ATM VC service class as VBR-nrt. Otherwise, DBS configures the service class as UBR.
Figure 17-1 Dynamic Bandwidth Selection Flow
ATM VC connection
Subscriber
1
2
AAA Server
1. PPPOA/PPPOX session begins.
3. DBS software applies the ATM VC parameters from the profile
to the VC connection.
87060
2. DBS software retrieves subscriber's profile from AAA server.
Feature History for Dynamic Bandwidth Selection

Cisco IOS Release
Description
Required PRE
Release 12.2(16)BX
The Dynamic Bandwidth Selection feature was introduced

on the PRE2. This feature is also known as Per User QoS
Using AAA Policy Name.
PRE2
Release 12.2(28)SB

for the PRE2.
17-2
OL-7433-09
Chapter 17

Configuration Commands for DBS

This section describes the following commands used to configure dynamic bandwidth selection (DBS):
dbs enable Command, page 17-3
default dbs enable Command, page 17-4
dbs enable Command

To enable dynamic bandwidth selection QoS and apply the traffic shaping parameters retrieved from
RADIUS to the ATM virtual circuit (VC) class, ATM VC, ATM PVC range, or ATM PVC within a PVC
range, use the dbs enable command in the appropriate configuration mode. To disable dynamic
bandwidth selection, use the no form of the command. By default, DBS is disabled.
dbs enable
no dbs enable
dbs enable Command History

Cisco IOS Release
Description
Release 12.2(16)BX
The dbs enable command was introduced on the PRE2.
Release 12.2(28)SB
PRE2.
Configuration Modes
You can configure the dbs enable command in the following configuration modes:
ATM VC class
ATM VC
ATM PVC range
ATM PVC-in-range
Usage Guidelines for the dbs enable Command

When changing ATM QoS values dynamically on a VC, the connection might be disrupted for a short
duration (typically milliseconds).
The no dbs enable command configured in any configuration mode (for example, PVC) overrides the
dbs enable command configured in any configuration mode (for example, VC class). For more
information, see the Usage Guidelines for the default dbs enable Command section on page 17-5.
Both the dbs enable and no dbs enable commands are nvgenned, that is, they are saved in the running
configuration and appear, when configured, in the output of the show running-config command. If you
use the default setting of DBS (no dbs enable) without explicitly configuring it, the no dbs enable
command does not appear in the show running-config output.

OL-7433-09
17-3
Chapter 17
When you enter the dbs enable or no dbs enable commands, existing sessions are not disconnected. If
you have a session that has been configured for DBS and you configure the no dbs enable command on
a VC, additional sessions that are configured display DBS-configured QoS values until the first new
session is up. After the first session is brought up, the VC has default and locally configured values. If
you configure the dbs enable command after multiple sessions are already up on the VC, all sessions on
that VC have DBS QoS parameters.
RADIUS QoS attributes are applied to PVCs when a new PPPoE session has PCR and SCR values that
are higher than existing PPPoE sessions. If a new PPPoE session with lower PCR and SCR values is
added to a PVC, the RADIUS QoS attributes are not applied to the new session. If the user with the
PPPoE session with the higher PCR and SCR values logs out, the QoS attributes are set to those of the
lower bandwidth user.
RADIUS QoS attributes override attributes on a PVC configured in ATM PVC-in-range or ATM PVC
range configuration mode. If the RADIUS QoS attributes cannot be applied to a PVC, PPPoE and PPPoA
sessions cannot be established.
When DBS is configured, normal ATM precedences apply. PVC configurations take precedence over VC
class configurations. Thus, if DBS QoS parameters are applied on a VC class and disabled on one PVC
in that VC class, DBS QoS parameters are not applied on the PVC. ATM PVC-in-range configurations
take precedence over PVC range configurations.
When you configure DBS on a PVC, existing sessions on that PVC remain connected.
default dbs enable Command

To remove the dbs enable or no dbs enable command from an existing configuration, use the default
dbs enable command in the appropriate configuration mode.
default dbs enable
no default dbs enable
default dbs enable Command History

Cisco IOS Release
Description
Release 12.2(16)BX
The default dbs enable command was introduced on the PRE2.
Release 12.2(28)SB
PRE2.
Configuration Modes
You can configure the default dbs enable command in the following configuration modes:
ATM VC class
ATM VC
ATM PVC range
ATM PVC-in-range
17-4
OL-7433-09
Chapter 17

Usage Guidelines for the default dbs enable Command

The default dbs enable command is not nvgenned and does not appear in the output of the
show running-config command when configured.
Use the default dbs enable command to remove the dbs enable command or the no dbs enable
command from a configuration. For example, in the following configuration we enable DBS on
PVC 1/55:
Router(config-if-atm-vc)# dbs enable
Router(config-if-atm-vc)# encapsulation aal5mux ppp Virtual-Template1
Router(config-if-atm-vc)# end
We later decide to change the PVC configuration so that a VC class is applied to the PVC. The
configuration of the VC class, named vc-test, includes the dbs enable command. Therefore, we must
remove the dbs enable command from the PVC configuration by using the default dbs enable
command.
The default dbs enable command removes the dbs enable command from the PVC configuration, as
shown in the following configuration, but it does not remove the ability to do DBS under the VC class.
Notice that the default dbs enable command also does not appear in the PVC configuration.
vc-class atm vc-test
vbr-nrt 505 505
dbs enable
!
pvc 1/55
class-vc vc-test
PCR and SCR Parameters for Multiple Sessions on a VC

DBS selects the PCR and SCR parameters for a VC on which multiple PPPoE sessions are allowed and
applies the parameters to the VC. The RADIUS profile values for the first user on a VC override the
default values of the VC. At any time, DBS selects the PCR and SCR values that are the highest of all
the sessions. Adding and removing sessions from the VC can result in changes in the PCR and SCR
parameters.
If users already exist on the VC, each new value overrides the existing configuration only if the value is
higher than the existing value. If the selected PCR value is higher than available bandwidth, DBS applies
the highest value supported on the VC. If the PCR is less than the minimum PCR supported on a VC,
DBS applies the minimum supported value.

OL-7433-09
17-5
Chapter 17
Dynamic Bandwidth Selection Configuration and PPP Sessions

Dynamic bandwidth selection (DBS) is disabled by default on the Cisco 10000 series router. Enabling
or disabling DBS affects new and existing sessions on the VC in the following ways:
If multiple sessions are already up on a VC and you then enable DBS on the VC, when the next
session comes up (the first session after enabling DBS on the VC), that session and all other sessions
on the VC have DBS configured QoS values.
If you enable or disable DBS on a VC, none of the already established sessions on the VC
disconnect.
If a session comes up on a VC that has DBS enabled and then you disable DBS on the VC, that
session and all other sessions that came up before you disabled DBS display the default or
configured VC values. The first session that comes up after you disabled DBS on the VC displays
the default and locally configured QoS values on the VC.
Changing QoS traffic parameters affects sessions on a VC in the following ways:
Changing VC QoS traffic parameters as a result of new simultaneous sessions on the same VC does
not cause already established sessions to disconnect.
Changing RADIUS domain service profile QoS parameters does not cause the QoS traffic
parameters to change automatically for VCs with existing sessions to the domain.
Network Access Server QoS Management

When a network access server (NAS) sends a domain authorization request to a RADIUS server, the
server returns an affirmative response that might include a QoS-management string in attribute 26 (VSA)
for QoS management in the NAS. The QoS-management values, configured as part of the RADIUS
domain service profile attributes, contain PCR and SCR values for a specific VC or permanent VC. The
QoS parameters of the VC on which the PPP session arrived change to UBR or VBR-nrt, and change to
the PCR and SCR values specified for that particular user. If DBS cannot apply the QoS values specified
for a particular user to the VC on which the session arrived, the router ignores the QoS values and usually
establishes the session. For example, if the PVC is unshaped UBR, the router ignores the QoS values for
PCR and SCR and establishes the session.
Default QoS Parameters and QoS Configuration Precedence

You can use the Cisco IOS command line interface (CLI) to configure QoS traffic shaping parameters in
ATM VC configuration mode, VC class mode, PVC range mode, or PVC-in-range mode. The traffic
parameters that you configure in VC class interface or subinterface mode become the default QoS
parameters for the VCs on which the VC class is applied. The QoS parameters in the RADIUS domain
service profile (for the domain the subscriber is logged in to) override the default parameters. If you do
not configure a VC class on a VC, the default is the unspecified bit rate (UBR).
Regardless of the mode in which you configure the parameters, locally configured QoS parameters have
lower precedence than RADIUS QoS parameters. The traffic shaping parameters specified in the
RADIUS domain service profile with higher precedence override the locally configured QoS shaping
parameters.
17-6
OL-7433-09
Chapter 17

Accounting Updates
When dynamic bandwidth selection applies QoS values for a user, it sends an accounting record to the
RADIUS server. The accounting records contain accounting attributes such as the following:
Cisco-Avpair = peak-cell-rate=155000 [flags = 0x00014000]
Cisco-Avpair = sustainable-cell-rate=145000 [flags = 0x00014000]
Service Category Transitions

Table 17-1 lists the service category transitions supported on the Cisco 10000 series router for dynamic
bandwidth selection (DBS).
Table 17-1 Supported Service Category Transitions
From Service Category
To Service Category
Transition
Any
UBR-unshaped
Reject
UBR-unshaped
Any
Reject
UBR-PCR (shaped)
VBR-nrt
Reject
VBR-nrt
UBR-PCR
Reject
UBR-PCR
UBR-PCR
Accept
VBR-nrt
VBR-nrt
Accept
In DBS, the router does not allow you to change a VC traffic class, regardless of the atm pxf queuing
mode of the router. For example, if you have a shaped UBR and DBS downloads peak cell rate (PCR)
and sustained cell rate (SCR) values from RADIUS, the router does not convert the VC to VBR-nrt.
Instead, the VC remains shaped UBR with the PCR configured. The router accepts or rejects the session
on the VC as described below:
If the downloaded PCR and SCR parameters are defined as mandatory attributes in RADIUS, the
router rejects the session.
If the downloaded PCR and SCR parameters are defined as non-mandatory attributes in RADIUS,
the router accepts the session on the VC without changing the VCs traffic class or parameters.
Dynamic Bandwidth Selection and Oversubscription

In releases prior to Cisco IOS Release 12.3(7)XI2, if you simultaneously configure dynamic bandwidth
selection (DBS) and VC oversubscription, RADIUS-provided QoS parameters are not set for some ATM
VCs.
In Cisco IOS Release 12.3(7)XI2 and later releases, the router supports VC oversubscription on VCs that
are modified using DBS. You can simultaneously configure DBS and VC oversubscription without any
adverse affect on the VCs rate modification.

OL-7433-09
17-7
Chapter 17
Prerequisites for Dynamic Bandwidth Selection

To download a service policy to a VC dynamically (through RADIUS), you must first enable dynamic
bandwidth selection on the VC by using the dbs enable command. Otherwise, the input and output
policy map that is pulled from RADIUS is not applied on the VC.
For example, when using the atm:vc-qos-policy-out and atm:vc-qos-policy-in RADIUS attributes, first
enable dynamic bandwidth selection as shown in the following sample configuration:
vc-class atm 416k
vbr-nrt 416 416
dbs enable
create on-demand
idle-timeout 86400
interface ATM 5/0/0.1 multipoint
atm pppatm passive
range pvc 1/101 1/180
class-range 416k
queue-depth 24 20
The input and output policy map is then applied to the PVC 1/101 as shown in the following sample
debug output:
Nov 25 09:49:23.244: Service policy input Ingress policy output Egress applied on 1/101
Nov 25 09:49:23.244: %c10k_atm_modify_vc_policy(ATM5/0/0): 1/101, vcd 1
Nov 25 09:49:23:244: %c10k_atm_modify_vc_policy(ATM5/0/0): Service policy output Egress
applied on 1/101, vcd 1
Nov 25 09:49:23:252: %c10k_atm_modify_vc_policy(ATM5/0/0): Service policy input Ingress
applied on 1/101, vcd 1
Restrictions and Limitations for Dynamic Bandwidth Selection
Dynamic bandwidth selection (DBS) applies the dynamically updated bandwidth to the ATM VC or
permanent VC (PVC). DBS does not support applying the bandwidth to individual sessions.
The Cisco 10000 series router supports DBS for only ATM interface protocols, such as PPPoA and
PPPoEoA. The router does not support DBS for PPPoE natively over Ethernet or over VLAN.
DBS does not support switched virtual circuits (SVCs).
DBS does not allow all QoS class of service category changes due to segmentation and reassembly
(SAR) firmware limitations. For example, if you have VBR-nrt VCs configured, you can modify the
VCs shaping parameters (PCR and SCR) using DBS, but you cannot change VBR VCs to shaped
UBR VCs by downloading only the PCR from RADIUS. This behavior also applies to shaped UBR
VCs. Currently, you can change the ATM VC traffic class only by using the modular QoS command
line interface (CLI). For more information, see the Service Category Transitions section on
page 17-7.
DBS does not allow unspecified bit rate (UBR) unshaped transitions. The Cisco 10000 series router
does not allow all transitions to and from UBR unshaped PVCs. An unshaped UBR PVC is a PVC
that does not have a rate specified or the rate specified is greater than or equal to the actual
bandwidth. In pxf queuing mode, the router treats all UBRs as unshaped. UBR unshaped is not a
unique service category, but rather a pseudo service category based on the local or RADIUS user
configuration.
17-8
OL-7433-09
Chapter 17

DBS does not support constant bit rate (CBR) PVCs. The Cisco 10000 series router supports only
UBR and variable bit rate (VBR) PVCs for DBS.
DBS is supported only on VBR-nrt VCs under virtual path (VP) tunnels in pxf queuing mode.
Configuring Dynamic Bandwidth Selection

Dynamic bandwidth selection enables you to dynamically change ATM QoS traffic shaping parameters
based on RADIUS user or domain profiles (see the Applying Traffic Shaping Parameters Using
RADIUS Profiles section on page 17-2).
To configure dynamic bandwidth selection, perform the following required configuration tasks:
Configuring the Router for Dynamic Bandwidth Selection, page 17-9
Configuring RADIUS Profiles for Dynamic Bandwidth Selection, page 17-13
Configuring the Router for Dynamic Bandwidth Selection

To configure the router for dynamic bandwidth selection, perform any of the following configuration
tasks:
Enabling Dynamic Bandwidth Selection on a VC Class, page 17-9
Enabling Dynamic Bandwidth Selection on ATM PVCs, page 17-10
Enabling Dynamic Bandwidth Selection on a Range of ATM PVCs, page 17-11
Enabling Dynamic Bandwidth Selection on a PVC Within a PVC Range, page 17-12
Enabling Dynamic Bandwidth Selection on a VC Class

To enable dynamic bandwidth selection on a VC class, enter the following commands beginning in
Step 1
Command
Purpose
Configures a VC class for an ATM VC or interface. Enters VC

Step 2
Router(config-vc-class)# dbs enable
Enables dynamic bandwidth selection and allows the traffic

shaping parameters retrieved from RADIUS to be applied to the
VC class.
Configuration Example for Enabling Dynamic Bandwidth Selection on a VC Class

Example 17-1 shows how to enable dynamic bandwidth selection on a VC class. In the example,
dynamic bandwidth selection is enabled on a VC class named cisco.
Example 17-1 Enabling Dynamic Bandwidth Selection on a VC Class
Router(config)# vc-class atm cisco
Router(config-vc-class)# dbs enable

OL-7433-09
17-9
Chapter 17
Enabling Dynamic Bandwidth Selection on ATM PVCs

To enable dynamic bandwidth selection on an ATM PVC, enter the following commands beginning in
Command
Purpose
Step 1

point-to-point
Specifies the ATM interface or subinterface. Enters interface or

Step 2
Router(config-if)# pvc [name] vpi/vci
Specifies an ATM PVC and enters ATM VC configuration mode.

(Optional) name is the name of the PVC. The name can have up
to 16 characters.
vpi/ is the ATM network virtual path identifier (VPI) for the PVC.
Valid values are from 0 to 255. If you do not specify a vpi value,
the vpi value defaults to 0. If the vci value is 0, you cannot set the
vpi value to 0. The slash character is required.
vci is the ATM network virtual channel identifier (VCI) for the
PVC. Valid values are from 1 to 65535. Typically, the lower
values 0 to 31 are reserved for specific traffic and you should not
use these. If the vpi value is 0, you cannot set the vci value to 0.
Note
The VCI is a 16-bit field in the header of the ATM cell and
because the value has local significance only, it is unique
only on a single link, not throughout the ATM network.
Step 3

PVC.
Step 4
Router(config-if-atm-vc)# protocol pppoe
(Optional) Specifies Point-to-Point Protocol over Ethernet

(PPPoE) as the protocol of the ATM PVC.
Configuration Example for Enabling Dynamic Bandwidth Selection on ATM PVCs

Example 17-2 shows how to enable dynamic bandwidth selection on an ATM PVC. In the example,
dynamic bandwidth selection is enabled on the PVC named cisco (PVC 0/100) on the ATM
point-to-point subinterface 0/0/0.5.
Example 17-2 Enabling Dynamic Bandwidth Selection on an ATM PVC
Router(config)# interface atm0/0/0.5 point-to-point
Router(config-subif)# pvc cisco 0/100
Router(config-if-atm-vc)# protocol pppoe
17-10
OL-7433-09
Chapter 17

Enabling Dynamic Bandwidth Selection on a Range of ATM PVCs

To enable dynamic bandwidth selection on a range of PVCs, enter the following commands beginning
Command
Purpose
Step 1

point-to-point | multipoint
Specifies the ATM interface or subinterface. Enters interface or

Step 2
Router(config-subif)# range [range-name]

pvc start-vpi/start-vci end-vpi/end-vci
Defines a range of ATM PVCs and enters ATM range

configuration mode.
range-name is the name of the range. The range-name can have
up to 15 characters.
start-vpi/ is the beginning value for a range of virtual path
identifiers (VPIs). If you do not specify a vpi value, the vpi value
defaults to 0. Valid values are from 0 to 255. The slash is required.
start-vci is the beginning value for a range of virtual channel
identifiers (VCIs). Valid values are from 32 to 65535.
end-vpi/ is the end value for a range of VPIs. If you do not specify
an end-vpi value, the value defaults to the start-vpi value. Valid
values are from 0 to 255. The slash is required.
end-vci is the end value for a range of VCIs. Valid values are from
32 to 65535.
Step 3
Router(config-if-atm-range)# dbs enable
Note

PVC range.
When downloading a service policy dynamically from RADIUS, the router applies the service policy to
a range of PVCs, one PVC at a time. At this point, the PVC range is meaningless. The PVC on which
the router is operating could have been created by any means (for example, individually, in PVC range
mode, VC class mode, PVC-in-range mode, or automatically created on-demand).
Configuration Example for Enabling Dynamic Bandwidth Selection on a Range of ATM PVCs
Example 17-3 shows how to enable dynamic bandwidth selection on a range of PVCs. In the example,
dynamic bandwidth selection is enabled on a range of PVCs named cisco (PVC 0/50 to PVC 0/70) on
the ATM multipoint subinterface 0/0/0.1.
Example 17-3 Enabling Dynamic Bandwidth Selection on a Range of ATM PVCs
Router(config)# interface atm0/0/0.1 multipoint
Router(config-subif)# range cisco pvc 0/50 0/70
Router(config-subif-atm-range)# dbs enable

OL-7433-09
17-11
Chapter 17
Enabling Dynamic Bandwidth Selection on a PVC Within a PVC Range

To enable dynamic bandwidth selection on a specific PVC within a range of PVCs, enter the following
Command
Purpose
Step 1

multipoint]
Specifies the ATM interface or subinterface. Enters

Step 2
Router(config-if)# range [range-name] pvc

start-vpi/start-vci end-vpi/end-vci
Defines a range of ATM PVCs and enters ATM range

configuration mode.
range-name is the name of the range. The range-name can
have up to 15 characters.
start-vpi/ is the beginning value for a range of virtual path
identifiers (VPIs). If you do not specify a vpi value, the vpi
value defaults to 0. Valid values are from 0 to 255. The
slash is required.
start-vci is the beginning value for a range of virtual
channel identifiers (VCIs). Valid values are from 32 to
65535.
end-vpi/ is the end value for a range of VPIs. If you do not
specify an end-vpi value, the value defaults to the start-vpi
value. Valid values are from 0 to 255. The slash is required.
end-vci is the end value for a range of VCIs. Valid values
are from 32 to 65535.
Step 3
Router(config-if-atm-range)# pvc-in-range
[pvc-name] [vpi/vci]
Defines an individual PVC within a PVC range. Enters

PVC-in-range configuration mode.
pvc-name is the name of the PVC. The pvc-name can have
up to 15 characters.
vpi/ is the virtual path identifier for the PVC. If you do not
specify a vpi value, the vpi value defaults to 0. Valid values
are from 0 to 255. The slash is required.
vci is the virtual channel identifier for the PVC. Valid
Step 4
Router(config-if-atm-range-pvc)# dbs enable

shaping parameters retrieved from RADIUS to be applied
to the PVC in the range of PVCs.
17-12
OL-7433-09
Chapter 17

Configuration Example for Enabling Dynamic Bandwidth Selection on a PVC Within a PVC Range
Example 17-4 shows how to enable dynamic bandwidth selection on a PVC within a PVC range. In the
example, dynamic bandwidth selection (DBS) is enabled on PVC 60 in the PVC range named cisco
(PVC 0/50 to PVC 0/70).
Example 17-4 Enabling Dynamic Bandwidth Selection on a PVC Within a PVC Range
Router(config)# interface atm0/0/0.1 multipoint
Router(config-subif)# range cisco pvc 0/50 0/70
Router(config-if-atm-range)# pvc-in-range 60
Router(config-if-atm-range-pvc)# dbs enable
Configuring RADIUS Profiles for Dynamic Bandwidth Selection

To configure RADIUS profiles for dynamic bandwidth selection, configure the dynamic bandwidth
selection (DBS) QoS parameters in the domain service profiles or the user profiles on the authentication,
authorization, and accounting AAA server (such as RADIUS). If you apply the QoS parameters in a
domain service profile, all users that connect to that domain are assigned the same QoS parameters. If
you apply the QoS parameters in a user profile, the locally terminated session for that user is assigned
the QoS parameters. The Cisco 10000 series router downloads the user or domain profile from the
RADIUS server as part of user authentication.
The QoS management string for dynamic bandwidth selection has the following syntax:
Cisco-Avpair = atm:peak-cell-rate=155000
Cisco-Avpair = atm:sustainable-cell-rate=155000
You must configure the peak cell rate (PCR) parameter and you can optionally configure the sustained
cell rate (SCR) parameter. The following configuration rules apply:
If you configure only PCR, the ATM service type is unspecified bit rate (UBR).
If you specify both SCR and PCR, the ATM service type is variable bit rate-nonreal-time (VBR-nrt).
If the PCR value is greater than the maximum rate allowed on the ATM physical interface, the PCR
value applied on the VC is the maximum rate allowed on the interface.
If the PCR value is less than the minimum rate allowed on the physical interface, the PCR value
applied on the VC is the minimum rate allowed on the interface.
If the SCR value exceeds the maximum for the interface, the session is rejected.
Configuration Examples for Configuring RADIUS Profiles for Dynamic Bandwidth Selection
Example 17-5 shows how to configure RADIUS attributes in a domain service profile for dynamic
bandwidth selection.
Example 17-5 Configuring a RADIUS Domain Service Profile for Dynamic Bandwidth Selection
cisco.comPassword
Service-Type=
Cisco-Avpair=
Cisco-Avpair=
Cisco-Avpair=
Cisco-Avpair=
Cisco-Avpair=
Cisco-Avpair=
= cisco,Service-Type = Outbound
Outbound,
vpdn:tunnel-id=shiva,
vpdn:tunnel-type=12tp,
vpdn:12tp-tunnel-password=password2,
vpdn:ip-addresses=172.16.0.0,
atm:peak-cell-rate=155000,
atm:sustainable-cell-rate=155000

OL-7433-09
17-13
Chapter 17
Example 17-6 shows how to configure RADIUS attributes in a user profile for dynamic bandwidth
selection.
Example 17-6 Configuring a RADIUS User Profile for Dynamic Bandwidth Selection
user1@cisco.comPassword = userpassword1,Service-Type = Outbound
Service-Type= Outbound,
Cisco-Avpair= vpdn:tunnel-id=shiva,
Cisco-Avpair= vpdn:tunnel-type=12tp,
Cisco-Avpair= vpdn:12tp-tunnel-password=password2,
Cisco-Avpair= vpdn:ip-addresses=172.16.0.0,
Cisco-Avpair= atm:peak-cell-rate=155000,
Cisco-Avpair= atm:sustainable-cell-rate=155000
Configuration Examples for Dynamic Bandwidth Selection

This section provides additional configuration examples and includes the following:
Configuration Example for Enabling Dynamic Bandwidth Selection on a VC Class and a PVC,
page 17-14
Selection, page 17-16
Configuration Example for Enabling a RADIUS User Profile for Dynamic Bandwidth Selection,
page 17-16
Configuration Example for Enabling Dynamic Bandwidth Selection on a VC Class and a PVC
Example 17-7 shows how to enable dynamic bandwidth selection on a VC class and a PVC.
Example 17-7 Enabling Dynamic Bandwidth Selection on a VC Class and a PVC
!
aaa new-model
!
!aaa authentication ppp default group radius
aaa authorization network default local
aaa session-id common
ip subnet-zero
ip ftp source-interface FastEthernet0/0/0
ip ftp username siv
ip ftp password dev1sit
ip host hardhead 10.10.0.4
ip host balloon 10.10.0.3
ip host seabass 10.10.0.2
!
vpdn enable
vpdn authen-before-forward
!
vpdn-group 2
request-dialin
protocol l2tp
domain cisco.com
initiate-to ip 192.168.1.2
local name c10k-lac
l2tp tunnel password 7 13061E010803
!
mpls ldp log-neighbor-changes
17-14
OL-7433-09
Chapter 17

!
!
controller SONET 2/0/0
no framing
shutdown
!
!
vc-class atm pppoa
vbr-nrt 60 60
dbs enable/* Enables dynamic bandwidth selection on VC class.*/
!
vc-class atm pppoaRange
vbr-nrt 50 50
dbs enable/* Enables dynamic bandwidth selection on VC class.*/
!
interface FastEthernet0/0/0
ip address 10.14.0.25 255.255.0.0
no ip proxy-arp
full-duplex
!
interface POS1/0/0
no ip address
crc 32
!
interface ATM3/0/0
no ip address
atm flag s1s0 0
atm sonet stm-4
pvc 0/16 ilmi
!
!
interface Serial4/0/0
no ip address
!
ip address 192.168.1.1 255.255.255.0
negotiation auto
!
interface POS6/0/0
no ip address
crc 32
!
interface ATM8/0/0
atm pppatm passive
no ip address
no atm pxf queuing
atm sonet stm-4
!
atm pppatm passive
pvc 10/100
vbr-nrt 40 40
dbs enable/* Enables dynamic bandwidth selection on PVC.*/
!
!
atm pppatm passive
pvc 22/222
class-vc pppoa

OL-7433-09
17-15
Chapter 17
!
!
atm pppatm passive
range pvc 33/333 33/344
class-range pppoaRange
!
!
peer default ip address pool pppoa-pool
ppp authentication pap callin
ppp direction callin
!
ip default-gateway 24.1.0.4
ip classless
ip route 10.10.0.0 255.255.0.0 10.14.0.200
no ip http server
ip pim bidir-enable
!
!
radius-server host 10.14.0.210 auth-port 1645 acct-port 1646
radius-server key cisco
radius-server authorization permit missing Service-Type
!
Selection
Example 17-8 shows how to enable a RADIUS domain service profile for dynamic bandwidth selection.
Example 17-8 Enabling a RADIUS Domain Service Profile for Dynamic Bandwidth Selection
cisco.com
Password = cisco, Service-Type = Outbound

cisco-avpair = vpdn:tunnel-id=shiva,
cisco-avpair = vpdn:tunnel-type=l2tp,
cisco-avpair = vpdn:l2tp-tunnel-password=password2,
cisco-avpair = vpdn:ip-addresses=172.16.1.1,
cisco-avpair = atm:peak-cell-rate=155000,
cisco-avpair = atm:sustainable-cell-rate=155000
Configuration Example for Enabling a RADIUS User Profile for Dynamic Bandwidth Selection
Example 17-9 shows how to enable a RADIUS user profile for dynamic bandwidth selection.
Example 17-9 Enabling a RADIUS User Profile for Dynamic Bandwidth Selection
L2TP
user1@cisco.com
Password = cisco, Service-Type = Outbound
cisco-avpair = vpdn:tunnel-id=shiva,
cisco-avpair = vpdn:tunnel-type=l2tp,
cisco-avpair = vpdn:l2tp-tunnel-password=password2,
cisco-avpair = vpdn:ip-addresses=172.16.1.1,
17-16
OL-7433-09
Chapter 17

PPPoA or PPPoE
johndoe
Password = cisco
Service-Type = Frame-User,
Framed-Protocol = PPP,
Verifying and Monitoring Dynamic Bandwidth Selection

To verify and monitor dynamic bandwidth selection, enter any of the following commands in privileged
EXEC mode:
Command
Purpose
Router# show atm pvc
Displays all ATM PVCs and traffic information.
Displays details about the ATM VCs or PVCs.
Router# show atm pvc dbs
Displays information about ATM PVCs that have dynamic

bandwidth selection QoS parameters applied.
Router# show atm vc detailed
Displays detailed information about ATM PVCs.
Router# show interfaces virtual-access
Displays status, traffic data, and configuration information about

virtual access interfaces (VAIs).
Displays the state of the dynamic bandwidth selection QoS

parameters that have been applied.
Note
If you use the dbs enable or no dbs enable command, the

dynamic bandwidth selection QoS parameters appear in
the output of the show running-config command. If you
use the default dbs enable command, the parameters do
not appear.
Router# debug atm events
Displays the normal set of ATM events when a session comes up

or goes down.
Router# debug atm errors
Displays protocol errors and error statistics associated with VCs.
Router# debug atm status
Displays changes in the status of a VC when a session comes up

or goes down, or when the VC configuration is changed.
Router# debug ppp authentication
Displays authentication protocol messages, including Challenge

Authentication Protocol (CHAP) packet exchanges and Password
Authentication Protocol (PAP) exchanges.
Router# debug ppp error
Displays protocol errors and error statistics associated with PPP

connection negotiation and operation.

OL-7433-09
17-17
Chapter 17
Command
Purpose
Router# debug ppp negotiation
Enables debugging of the PPP negotiation process.
Router# debug radius
Displays detailed debugging information associated with

RADIUS.
Router# debug vpdn event
Displays L2TP errors and events that are a part of normal tunnel
establishment or shutdown for VPDNs.
Router# debug vpdn 12x-errors
Displays L2TP protocol errors that prevent tunnel establishment

or normal operation.
Router# debug vpdn 12x-events
Displays L2TP events that are part of tunnel establishment or

shutdown.
Router# debug vpdn pppoe-errors
Displays PPPoE protocol errors that prevent a session from being

established or errors that cause an established session to be
closed.
Router# debug vpdn pppoe-events
Displays PPPoE protocol messages about events that are part of

normal session establishment or shutdown.

The DBS ExtensionsVC Weight and Watermarks feature extends the capability of the Dynamic
Bandwidth Selection (DBS) feature to enable you to dynamically change the existing VC weight and
watermark values applied to a session without tearing down the VC and then recreating it. This
eliminates the need to statically configure each subscribers VC using the modular QoS command line
interface (MQC). As a result, you can save configuration time, reduce the size and complexity of the
routers configuration file, and reduce the time required for router initialization after planned or
unplanned outages.
The VC weight value indicates the number of cells that a VC can send to the virtual path (VP) tunnel
before the line card segmentation and reassembly (SAR) mechanism processes the next VC. A high
weight value has a higher VC priority in the VP scheduler than a VC with a low weight value.
The high and low watermark values define the depth of the PVC interface queue on the line card. The
SAR mechanism on ATM line cards creates a queue for every configured PVC. Each PVC queue has a
high and low watermark that defines the number of cells a queue can hold.
DBS operates with authentication, authorization, and accounting (AAA) servers (such as RADIUS) to
provide ATM VC parameters to the router. To dynamically retrieve VC weight and watermark
parameters from RADIUS, the following Cisco attribute value (AV) pairs are defined on the RADIUS
server:
cisco-avpair = atm:vc-weight=<weight value>
cisco-avpair = atm:vc-watermark-min=<minimum watermark value>
cisco-avpair = atm:vc-watermark-max=<maximum watermark value>
Note
Valid VC weight values are from 1 to 255. However, we recommend that you do not configure the value
below 5.
17-18
OL-7433-09
Chapter 17

For more information abut VC weight and watermarks, see Chapter 15, Oversubscribing Physical and
Virtual Links. The How the Router Determines VC Weights section on page 15-20 and the High
Watermark and Low Watermark Default Values section on page 15-25 describe VC weights and
watermarks.
To pull (download) dynamic VC weights and watermarks from a RADIUS server, you must enable
dynamic bandwidth selection (DBS) on the VC using the dbs enable command. To remove dynamically
modified VC parameters, enter the no dbs enable command. For more information, see the Configuring
Dynamic Bandwidth Selection section on page 17-9.
After the router pulls VC weight and watermark parameters from the RADIUS server and successfully
installs or updates the parameters on the VC, any changes to these VC parameters that you configure
using the modular QoS command line interface (MQC) affect only the nvgen values and not the
RADIUS-pulled values.
The VC weight and watermark parameters pulled from the RADIUS server have precedence over the VC
parameters that you configure on the PVC using the MQC. As a result, the show atm vc detail command
displays the dynamically modified VC weight and watermark values pulled from RADIUS; it does not
display the nvgen values configured using CLI commands.
Feature History for Dynamic VC Weight and Watermarks

Cisco IOS Release
Description
Required PRE
Release 12.3(7)XI7
The DBS ExtensionsVC Weight and Watermarks feature

was introduced on the PRE2.
PRE2
Release 12.2(28)SB
This feature was integrated in Cisco IOS Release 12.2(28)SB. PRE2
Configuration Commands for Dynamic VC Weight and Watermarks

The dbs enable command is used to configure dynamic VC weight and watermarks. For more
information, see the dbs enable Command section on page 17-3.
The following RADIUS VSAs are used to configure dynamic VC weight and watermarks on the
RADIUS server:
Note
Valid VC weight values are from 1 to 255. However, we recommend that you do not configure the value
below 5.
For more information, see the Setting Up RADIUS for Dynamic VC Weights and Watermarks section
on page 17-22.

OL-7433-09
17-19
Chapter 17
Default High and Low Watermark Values

The high and low watermark settings define the depth of the PVC interface queue on the line card.
Table 15-3 on page 15-25 lists the default high and low watermark values for ATM variable bit rate
(VBR) VCs, based on the ATM VC rate.
Table 15-4 on page 15-25 lists the default high and low watermark values for ATM unspecified bit rate
(UBR) VCs, based on the ATM VC rate.
For more information about high and low watermarks, see the Guidelines for Changing Watermark
Values section on page 15-26 and the Modifying the VC Weight and the VP Shaping Parameters
High and Low Watermark Threshold Behavior

The behavior of the high and low watermark thresholds depends on the queuing mode configured, either
atm pxf queuing or no atm pxf queuing mode. Chapter 15, Oversubscribing Physical and Virtual Links
describes threshold behavior for each of these queuing modes. For more information, see the High
Watermark and Low Watermark Default Values section on page 15-25.
Restrictions and Limitations for VC Weight and Watermarks
You must configure the AV pairs for both the high and low watermarks. Configuring only one of the
AV pairs results in the watermark not being configured.
The router does not support RADIUS Pull for automatically provisioned VCs and virtual path (VP)
tunnels.
Configuring Dynamic VC Weights and Watermarks

To configure dynamic VC weights and watermarks on a PVC, perform the following required
Configuring the Router for Dynamic VC Weights and Watermarks, page 17-21
Setting Up RADIUS for Dynamic VC Weights and Watermarks, page 17-22
17-20
OL-7433-09
Chapter 17

Configuring the Router for Dynamic VC Weights and Watermarks

To configure the router for dynamic VC weights and watermarks, enter the following commands
Step 1
Command
Purpose

point-to-point
Specifies the ATM subinterface and enters subinterface

configuration mode.
slot/module/port.subinterface is the number of the subinterface
(for example, 1/0/0.1)
point-to-point indicates the subinterface is a point-to-point
subinterface.
Step 2

to 16 characters.
PVC. Valid values are from 1 to 65,535. Typically, the lower
Note
Step 3

PVC.
Configuration Example for Configuring the Router for Dynamic VC Weights and Watermarks
Example 17-14 shows how to configure the router for dynamic VC weights and watermarks. In the
example, dynamic bandwidth selection is enabled on PVC 1/101 on the ATM subinterface 4/0/0.1.
Example 17-10 Configuring the Router for Dynamic VC Weights and Watermarks
Router(config)# interface
Router(config-subif)# pvc
Router(config-if-atm-vc)#
atm 4/0/0.1
1/101
dbs enable
encapsulation aal5mux ppp Virtual-Template 1

OL-7433-09
17-21
Chapter 17
Setting Up RADIUS for Dynamic VC Weights and Watermarks

To set up RADIUS for dynamic VC weights and watermarks, enter the following Cisco AV pairs in the
user profile on the RADIUS server:
Note
You can configure the VC weight value from 1 to 255. However, we recommend that you do not
configure the value below 5.
Example 17-11 shows how to configure the RADIUS server for dynamic VC weights and watermarks.
In the example, the VC weight is set to 100.
Example 17-11 Setting Up RADIUS for Dynamic VC Weights and Watermarks
cisco-avpair
cisco-avpair
cisco-avpair
cisco-avpair
cisco-avpair
cisco-avpair
cisco-avpair
cisco-avpair
cisco-avpair
cisco-avpair
=
=
=
=
=
=
=
=
=
=
"vpdn:tunnel-id = slow,
"vpdn-tunnel-type = l2tp,
"vpdn:ip-addresses = 10.1.1.22,
"vpdn:nas-password = Tortoise,
"vpdn:gw-password = Hare,
"atm:sustainable-cell-rate = 512,
"atm:maximum-burst-rate = 0,
"atm:vc-weight = 100,
"atm:vc-watermark-min = n,
"atm:vc-watermark-max = n,
When the router requests the policy name, the information in the user file is pulled. A RADIUS users
file contains an entry for each user that the RADIUS server authenticates. Each entry, which is also
referred to as a user profile, establishes an attribute the user can access.
When looking at a user file, the data to the left of the equal (=) character is an attribute defined in the
dictionary file and the data to the right of the equal character is the configuration data.
Verifying Dynamic VC Weights and Watermarks

To verify dynamic VC weights and watermarks, enter any of the following commands in privileged
EXEC mode:
Command
Purpose
Displays the current configuration on the router. The output

shows the VC weights and watermarks that you configure using
the CLI commands. The dynamically modified VC weights and
watermarks do not display.
Router# show atm vc detail
Displays weight and watermark information for all of the VCs

configured.
17-22
OL-7433-09
Chapter 17

Command
Purpose
Router# show atm vc [vcd | interface

interface-number]
Displays traffic information about all ATM permanent virtual

circuits (PVCs).
(Optional) vcd is a specific virtual circuit. When you specify a
VC, information displays about only that VC.
(Optional) interface interface-number is an interface or
subinterface number. When you specify an interface, information
displays about all of the PVCs configured on the specified
Router# show atm pvc dbs
Displays all of the PVCs with dynamic bandwidth selection

(DBS) enabled and that have QoS parameters applied using
RADIUS.
Displays detailed information about an individual PVC.

vpi/ is the virtual path identifier. The slash is required.
Verification Example for Dynamic VC Weights and Watermarks

Example 17-12 shows sample output for the show atm vc command, which enables you to display
information about a particular VC. As indicated in the example, the high watermark for VCD 2 is set to
240 and the low watermark is set to 224. The weight is set to 12.
Example 17-12 Sample Output for the show atm vc Command
Router# show atm vc 2
ATM7/0/0: VCD: 2, VPI: 1, VCI: 100
Channel Weight: 12
OAM frequency: 0 second(s)
InARP frequency: 15 minutes(s)
Out CLP=1 Pkts: 0
OAM cells sent: 0
Status: UP
DBS enabled.
PPPoA Current State = LCP_NEGOTIATION
PPPoA Latest Event = PPP Msg
PPPoA Latest Error = None
PPPoA Session ID = 4
PPPoA Handle = 0xA8000003, SSS Handle = 0x00000000
Switch Handle = 0xF5000003, PPP Handle = 0x18000005
AAA Unique ID = 0x00000005, AIE Handle = 0xBE000003

OL-7433-09
17-23
Chapter 17
Example 17-13 shows sample output for the show atm pvc command, which enables you to display
information about a particular PVC. As indicated in the example, the high watermark for PVC 1/100 is
set to 56 and the low watermark is set to 48. The weight is set to 12.
Example 17-13 Sample Output for the show atm pvc Command
Router# show atm pvc 1/100
ATM7/0/0: VCD: 2, VPI: 1, VCI: 100
Channel Weight: 12
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC Status: Not Managed
ILMI VC status: Not Managed
InARP frequency: 15 minutes(s)
Out CLP=1 Pkts: 0
OAM cells sent: 0
OAM cell drops: 0
Status: UP
DBS enabled.
PPPoA Current State = LCP_NEGOTIATION
PPPoA Latest Event = PPP Msg
PPPoA Latest Error = None
PPPoA Session ID = 14
PPPoA Handle = 0x9300000D, SSS Handle = 0x00000000
Switch Handle = 0x5400000D, PPP Handle = 0x4B00000F
AAA Unique ID = 0x0000000F, AIE Handle = 0x3700000D

The Define Interface Policy-Map AV Pairs AAA feature provides two Cisco vendor-specific attributes
(VSAs) that allow you to dynamically apply a policy map and modify a policy map applied to a session,
without session reauthentication, at the ATM VC level using RADIUS.
The two new Cisco VSAs are set up in the user file on the RADIUS server. These two AV pairs are
vc-qos-policy-in and vc-qos-policy-out, and are formatted as follows:
cisco-avpair = atm:vc-qos-policy-in=<in policy name>
cisco-avpair = atm:vc-qos-policy-out=<out policy name>
The Define Interface Policy-Map AV Pairs AAA feature allows the two new Cisco VSAs to be installed
on an ATM VC after a PPPoA or PPPoEoA session establishment. Using RADIUS, this feature allows
a policy map to be applied (pulled) and then modified by specific events (pushed by the Policy
Server) while that session remains active.
17-24
OL-7433-09
Chapter 17

The push functionality of the feature allows you to modify an existing QoS profile (a policy map) applied
to a session while that session remains active, thus allowing QoS policies to be applied as required
without session re-authentication disruption. Specific events including time-of-day, byte count, and user
request, can signal the policy server to push a policy map onto a specific VC.
In addition, two existing Cisco Generic RADIUS VSAs replace and deprecate two VSAs that do not
correctly follow the Cisco VSA naming guidelines. Table 17-2 lists the replaced VSAs and the VSAs
that replace them. The router supports the old attributes, but you should avoid using them and use the
new VSAs instead.
Table 17-2 Replaced and Deprecated Cisco AV-Pairs
Replaced and Deprecated (Old) Cisco AV-Pairs
Replacement (New) Cisco AV-Pairs
cisco-avpair = ip:sub-policy-In=<in policy name>
cisco-avpair = ip:sub-qos-policy-in=<in policy name>
cisco-avpair = ip:sub-policy-Out=<out policy name>
cisco-avpair = ip:sub-qos-policy-out=<out policy name>
The Cisco VSA (attribute 26) communicates vendor-specific information between the network access
server (NAS) and the RADIUS server. Attribute 26 encapsulates vendor specific attributes that allow
vendors such as Cisco to support their own extended attributes.
In releases prior to Cisco IOS Release 12.3(7)XI2, you can configure a policy map only on a VC or ATM
point-to-point subinterface by using the service-policy command. The service policy is applied to the
sessions on these VCs using RADIUS or manually using a virtual template interface.
In Cisco IOS Release 12.3(7)XI2 and later releases, you can apply a service policy on the VC using
RADIUS for a PPPoA or PPPoEoA session. However, configuring a service policy on the ATM
subinterface still requires that you configure the service-policy command.
When you configure a service policy on the VC (or ATM point-to-point subinterface), the router applies
the service policy to all sessions that use that VC. This allows the router to apply class-based weighted
fair queuing (CBWFQ) to sessions. You can configure a service policy either on a VC or on a session,
but not on both at the same time.
Note
A policy map defines QoS actions and rules for the traffic classes that you define in class maps. In a
policy map, you can define QoS actions for such things as policing and class-based weighted fair
queuing (CBWFQ). When you attach a policy map to an interface, you must specify whether the policy
is to be applied to inbound or outbound traffic. For more information, see Chapter 2, Classifying
Traffic, Chapter 3, Configuring QoS Policy Actions and Rules, or Chapter 4, Attaching Service
Policies.
The Define Interface Policy-Map AV Pairs AAA feature supports all Cisco 10000 series line cards. For
more information, see the Define Interface Policy-Map AV Pairs AAA feature module for Cisco IOS
Release 12.2(28)SB.

OL-7433-09
17-25
Chapter 17
Feature History for Define Interface Policy-Map AV Pairs AAA

Cisco IOS Release
Description
Required PRE
Release 12.3(7)XI2
The Define Interface Policy-Map AV Pairs AAA feature was PRE2

introduced on the PRE2 and the pull functionality was
implemented. This feature provides two RADIUS
vendor-specific attributes (VSAs) that allow you to apply a
policy map on an ATM VC during PPP over ATM (PPPoA) or
PPP over Ethernet over ATM (PPPoEoA) session
establishment.
Release 12.2(28)SB

and the push functionality was implemented.
Pulled Policy Maps

Pulled policy maps are QoS parameters that the router downloads from the RADIUS server to the ATM
VC. If a policy map is already configured on the ATM VC, the policy map pulled from the RADIUS
server has higher precedence. If you enter the show policy-map command, the output displays the policy
map pulled from the RADIUS server.
For example, the following sample output from the show policy-map interface command shows that
two service-policies (voice and outname) are attached to PVC 4/103.
ATM4/0/0.3: PVC 4/103 Service-policy input: voice
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
Service-policy output: outname
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
When the router establishes a PPP over Ethernet over ATM (PPPoEoA) session, the router downloads or
pulls the policy maps set up on the RADIUS server to the VC. The following sample output from the
show policy-map interface command shows that the RADIUS policy maps (test_vc and dyn_out) are
now attached to PVC 4/103.
ATM4/0/0.3: PVC 4/103 Service-policy input: test_vc
0 packets, 0 bytes
17-26
OL-7433-09
Chapter 17


Match: any
0 packets, 0 bytes
5 minute rate 0 bps
Service-policy output: dyn_out
Match: any
5 minute rate 0 bps
After a policy map is successfully pulled on the VC, any configuration changes you make using the
[no] service-policy input/output <name> command do not affect the policy map used by the VC.
Entering the show policy-map command displays the pulled policy map. Entering the
show running-config command displays the current user configuration on the router.
To remove the dynamic policy that is pulled from the RADIUS server, use the no dbs enable command
or clear the PPPoA or PPPoEoA session associated with the VC.
Prerequisites for Define Interface Policy-Map AV Pairs AAA
Authentication, authorization, and accounting (AAA) must be enabled and already set up to use
RADIUS.
When dynamically configuring a service policy on the ATM subinterface, dynamic bandwidth
selection (DBS) must be enabled on the VC using the dbs enable command. For more information
about DBS, see the Applying Traffic Shaping Parameters Using RADIUS Profiles section on
page 17-2.
Restrictions and Limitations for Define Interface Policy-Map AV Pairs AAA

You cannot simultaneously configure a service policy on a VC and on a session.
Configuring Dynamic QoS Policies at the Session Level

To configure dynamic QoS policies at the session level, perform the following configuration tasks:
Configuring the Router for Dynamic QoS Policies at the Session Level, page 17-28
Setting Up RADIUS for Dynamic QoS Policies at the Session Level, page 17-29
Authentication, Authorization, and Accounting (AAA) must be enabled and already set up to use
RADIUS.
PPP over Ethernet over ATM (PPPoEoA) or PPP over ATM (PPPoA) session is established.
Change of authorization functionality is enabled (required for the push functionality)
dbs enable command is configured on the VC.
Policy map is configured on the router.
Prerequisites

OL-7433-09
17-27
Chapter 17
Configuring the Router for Dynamic QoS Policies at the Session Level
To configure the router for dynamic QoS policies at the session level, enter the following commands
Command
Purpose
Step 1

point-to-point
Specifies the ATM subinterface. Enters subinterface

configuration mode.
Step 2

to 16 characters.
PVC. Valid values are from 1 to 65535. Typically, the lower
Note
Step 3

PVC.
Step 4
Step 5
Step 6
policy-map-name
Configures or modifies a policy map. Enters policy-map

configuration mode.
Configuration Example for Configuring the Router for Dynamic QoS Policies at the Session Level
Example 17-14 shows how to configure the router for dynamic QoS policies at the session level. In the
example, dynamic bandwidth selection is enabled on PVC 1/101 on the ATM subinterface 4/0/0.1.
Example 17-14 Configuring the Router for Dynamic QoS Policies at the Session Level
Router(config-subif)# pvc
atm 4/0/0.1
1/101
dbs enable
17-28
OL-7433-09
Chapter 17

Setting Up RADIUS for Dynamic QoS Policies at the Session Level

To set up RADIUS for dynamic QoS policies at the session level, enter the following Cisco AV pairs in
the user profile on the RADIUS server:
atm:vc-qos-policy-in=<in policy name>
atm:vc-qos-policy-out=<out policy name>
Example 17-15 shows how to configure the Cisco AV pairs in the RADIUS user profile. In the example,
the policy map named dyn_out is configured for outbound traffic and the policy map named test_vc is
configured for inbound traffic.
Example 17-15 Setting Up RADIUS for Dynamic QoS Policies at the Session Level
Service-Type = Framed,
cisco-avpair = "atm:vc-qos-policy-out=dyn_out",
cisco-avpair = "atm:vc-qos-policy-in=test_vc"
When the router requests the policy name, the information in the user file is pulled. A RADIUS users
file contains an entry for each user that the RADIUS server authenticates. Each entry, which is also
referred to as a user profile, establishes an attribute the user can access.
When looking at a user file, the data to the left of the equal (=) character is an attribute defined in the
dictionary file, and the data to the right of the equal character is the configuration data.
Setting Up the AAA Server

To set up the local AAA server for dynamic authorization service, which must be enabled to support
change of authorization (CoA) functionality that can push the policy map in an input and output
direction, configure the aaa server radius dynamic-author command with the client and server-key
subcommands.
aaa server radius dynamic-author
client {ip_addr | name} [vrf {vrfname}]
[server-key {string}]
server-key [0 | 7] {string}
port {port-num}
auth-type {any | all | session-key}
ignore session-key
ignore server-key
Configure the server-key by using the client server-key string subcommand to configure at the client
level, or use the server-key string subcommand to configure at the global level. Configuring at the
client level overrides the global level.
For security purposes, we recommend configuring each client and using different server-keys for each
client.
The port, auth-type, ignore session-key, and ignore server-key commands are optional.
The following example sets up the local AAA server:
aaa server radius dynamic-author
client 192.168.0.5 vrf coa server-key cisco1
client 192.168.1.5 vrf coa server-key cisco2

OL-7433-09
17-29
Chapter 17
Configuration Examples for Dynamic QoS Policies at the Session Level

Configuration Examples for Existing Service Policies and Pulled Policies, page 17-30
Configuration Examples for Pulled Policies and a Router Without Existing Policies, page 17-32
Configuration Examples for Existing Service Policies and Pulled Policies

In Example 17-16 the policy maps named voice and outname are already configured on the router. The
sample output from the show policy-map command shows that the voice and outname policies are
attached to PVC 4/103 on ATM subinterface 4/0/0.3. The show policy-map interface command displays
statistical information about the policy maps.
Example 17-16 Displaying Existing Service Policies o the Router
!
no atm enable-ilmi-trap
pvc 4/103
service-policy input voice
service-policy output outname
!
!
ATM4/0/0.3: PVC 4/103 Service-policy input: voice
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
Service-policy output: outname
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
17-30
OL-7433-09
Chapter 17

Example 17-17 shows a sample configuration that includes the dbs enable command to enable dynamic
QoS updates using RADIUS. When the router establishes a PPPoEoA session, the router downloads or
pulls the service policy names test_vc and dyn_out from the RADIUS server to the VC. The policy maps
downloaded from the RADIUS server have higher precedence than the policy maps (voice and outname)
configured directly on the PVC. The sample output from the show policy-map interface command
indicates that the RADIUS policies have been downloaded.
Example 17-17 Pulling QoS Parameters from RADIUS to Existing Policies
!
no atm enable-ilmi-trap
pvc 4/103
dbs enable
encapsulation aal5autoppp Virtual-Template1
service-policy input voice
service-policy output outname
!
end
ATM4/0/0.3: PVC 4/103 Service-policy input: test_vc
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
Service-policy output: dyn_out
Match: any
5 minute rate 0 bps
Router# show pppoe session
PPPoE Session Information
Unique ID PPPoE RemMAC
SID LocMAC VA-st
2
2 0010.1436.bc70
0010.1436.b070
Port VT
ATM4/0.31
VC:4/103
VA
State
Vi3.1
PTA
UP

OL-7433-09
17-31
Chapter 17
Configuration Examples for Pulled Policies and a Router Without Existing Policies
Example 17-18 shows sample output from the show policy-map interface command after a service
policy has been downloaded from RADIUS. In this example, the service policy named voice is
configured on the RADIUS server. The voice policy map is not configured on the router. The router,
however, is configured for Point-to-Point Protocol over ATM (PPPoA) and authentication, authorization,
and accounting (AAA). When a PPPoA session is established, the router pulls the service policy name
(voice) from the RADIUS server. However, as shown in the sample output from the
show running-config interface command, the currently running configuration displays, but information
about the pulled service policy does not display.
Example 17-18 Pulling QoS Parameters from RADIUS to a Router Without Existing Policies
Router# show policy-map interface atm 4/0.1
ATM4/0: VC 1/101 Service-policy input: voice
0 packets, 0 bytes
Match: any
!
Router# show running-config interface atm 4/0.1
!
Building configuration...
Current configuration : 107 bytes
!
interface ATM 4/0.1
pvc 1/101
dbs enable
!
Verifying Dynamic QoS Policies at the Session Level

To verify dynamic QoS policies at the session level, enter any of the following commands in privileged
EXEC mode:
Command
Purpose

interface you specify. If you do not specify an interface, it
displays information about all of the policy maps configured on
the router.
atm 4/0/0).

17-32
OL-7433-09
Chapter 17

Verification Examples for Dynamic QoS Policies at the Session Level

Example 17-19 shows sample output for the show policy-map interface command on the router. In the
example, the policy map named voice is attached to PVC 1/101 on the ATM interface 4/0/0.
Example 17-19 Verifying Dynamic Policies Using the show policy-map interface Command
ATM4/0/0: PVC 1/101 Service-policy input: voice
0 packets, 0 bytes
Match: any
Example 17-20 shows sample output for the show running-config command on the router. This
command displays the routers running-configuration file and displays the following types of
information:
AAA set up
Policy map
ATM VC
PPPoA
DBS enabled
Virtual template
RADIUS server
Example 17-20 Verifying Dynamic Policies on the Router Using the show running-config Command
aaa new-model
!
aaa user profile TEST
!
aaa authentication ppp default group radius
aaa authorization network default group radius
!
ip subnet-zero
!
policy-map voice
class Class-Default
fair-queue
!
interface ATM4/0.1 point-to-point
pvc 1/101
dbs enable
!
peer default ip address pool POOL1
ppp authentication chap
!

OL-7433-09
17-33
Chapter 17
radius-server
radius-server
radius-server
radius-server
!
timeout 15
key 7 060506324F41
vsa send accounting
vsa send authentication
Example 17-21 displays the PPPoA client configuration.

Example 17-21 Displaying the PPPoA Client Configuration Using the show running-config Command
!
interface ATM4/0.1 point-to-point
pvc 1/101
!
peer default ip address pool POOL1
ppp chap hostname userid
ppp chap password 7 030752180500
!

Per Session Queuing and Shaping for PPP over Ethernet (PPPoE) over Virtual LANs (VLANs) Using
RADIUS enables you to shape PPPoE over VLAN sessions to a user specified rate. The router shapes
the sum of all of the traffic to the PPPoE session so that the subscribers connection to the DSLAM does
not become congested. Queuing-related functionality provides different levels of service to the various
applications that execute over the PPPoE session.
A nested, two-level hierarchical service policy is used to configure session shaping directly on the router
using the modular quality of service command-line interface (MQC). The RADIUS server applies the
service policy to a particular PPPoE session by downloading a RADIUS attribute to the router. This
attribute specifies the policy map name to apply to the session. RADIUS notifies the router to apply the
specified policy to the session. Because the service policy contains queuing-related actions, the router
sets up the appropriate class queues and creates a separate versatile management system (VTMS) link
dedicated to the PPPoE session.
When configuring queuing and shaping for PPPoE over VLAN sessions, the child policy of a nested
hierarchical service policy defines QoS actions using any of the following QoS commands:
priority commandAssigns priority to a traffic class and gives preferential treatment to the class.
(See Chapter 8, Prioritizing Services.)
bandwidth commandEnables class-based fair queuing and creates multiple class queues based on
bandwidth. (See Chapter 5, Distributing Bandwidth Between Queues.)
queue-limit commandSpecifies the maximum number of packets that a particular class queue can
hold. (See Chapter 11, Managing Packet Queue Congestion.)
police commandRegulates traffic based on bits per second (bps), using the committed information
rate (CIR) and the peak information rate, or on the basis of a percentage of bandwidth available on
an interface. (See Chapter 6, Policing Traffic.)
random-detect commandDrops packets based on a specified value to control congestion before

a queue reaches its queue limit. The drop policy is based on IP precedence, differentiated services
code point (DSCP), or discard-class. (See Chapter 11, Managing Packet Queue Congestion.)
17-34
OL-7433-09
Chapter 17

set ip precedence commandMarks a packet with the IP precedence level you specify. (See
Chapter 7, Marking Traffic.)
set dscp commandMarks a packet with the differentiated services code point (DSCP) you specify.
(See Chapter 7, Marking Traffic.)
set cos commandSets the IEEE 802.1Q class of service bits in the user priority field. (See
Chapter 7, Marking Traffic.)
The parent policy contains only the class-default class with the shape command configured. This
command shapes traffic to the specified bit rate, according to a specific algorithm. (See Chapter 9,
Shaping Traffic.) For more information about nested hierarchical policies, see the Nested
Hierarchical Policies section on page 13-6.
The router allows you to apply QoS policy maps using RADIUS. The actual configuration of the policy
map occurs on the router using the modular QoS CLI (MQC). The router can apply the QoS policy to
sessions using attributes defined in one of the following RADIUS profiles:
User ProfileThe user profile on the RADIUS server contains an entry that identifies the policy
map name applicable to the user. The policy map name is the service that RADIUS downloads to
the router after a session is authorized.
Service ProfileThe service profile on the RADIUS server specifies a session identifier and an
attribute-value (AV) pair. The session identifier might be, for example, the IP address of the session.
The AV-pair defines the service (policy map name) to which the user belongs.
The following AV-pairs define the QoS policy to be applied dynamically to the session:
"ip:sub-qos-policy-in=<name of the QoS policy in ingress direction>"
"ip:sub-qos-policy-out=<name of egress policy>"
After receiving a service-logon request from the policy server, RADIUS sends a change of authorization
(CoA) request to the router to activate the service for the subscriber, who is already logged in. If the
authorization succeeds, the router downloads the name of the policy map from RADIUS using the above
attribute and applies the QoS policy to the session.
Note
Although the router also supports the RADIUS vendor specific attribute (VSA) 38, Cisco-Policy-Down
and Cisco-Policy-Up, we recommend that you use the above attributes for QoS policy definitions.
Feature History for Per Session Queuing and Shaping for PPPoE Over VLANs
Cisco IOS Release
Description
Required PRE
Release 12.3(7)XI7
The Per Session Queuing and Shaping for PPPoE over

VLAN (PPPoEoVLAN) Support Using RADIUS feature
was introduced on the PRE2 to enable dynamic queuing
and shaping policies on PPPoEoVLAN sessions.
PRE2
Release 12.2(31)SB5
This feature was implemented on the PRE2.
PRE2

OL-7433-09
17-35
Chapter 17
Per Session Shaping Inheritance

Each PPPoE over VLAN session for which per session queuing and shaping is configured has its own
set of queues and its own VTMS link. Therefore, these PPPoE sessions do not inherit policies unless you
remove the service policy applied to the session or you do not configure a policy for the session.
Interfaces Supporting Per Session Queuing and Shaping for PPPoE Over VLANs
The router supports per session queuing and shaping on PPPoE terminated sessions and on an
IEEE 802.1Q VLAN tagged subinterfaces for outbound traffic only.
The router does not support per session queuing and shaping for PPPoE over VLAN sessions using
RADIUS on inbound interfaces.
Restrictions and Limitations for Per Session Queuing and Shaping for PPPoE
Over VLANs
The router does not support per session queuing and shaping for Layer 2 Access Concentrator (LAC)
sessions.
The QoS-related statistics available using the show policy-map interface command are not
available using RADIUS.
The router does not support using a virtual template interface to apply a service policy to a session.
You can only apply per session queuing and shaping policies as output service policies. The router
supports input service policies on sessions for other existing features, but not for per session queuing
and shaping for PPPoE over VLAN using RADIUS. For more information, see Chapter 18,
Regulating and Shaping Subscriber Traffic.
During periods of congestion, the router does not provide specific scheduling between the various
PPPoE sessions. If the entire port becomes congested, the scheduling that results has the following
effects:
The amount of bandwidth that each session receives of the entire ports capacity is not typically
proportionally fair share.

The contribution of each class queue to the sessions total bandwidth might not degrade
proportionally.
The PRE2 does not support ATM overhead accounting for egress packets with Ethernet
encapsulations. Therefore, the router does not consider ATM overhead calculations when
determining that the shaping rate conforms to contracted subscriber rates.
The router does not support the configuration of the policy map using RADIUS. You must use the
modular QoS command line interface (MQC) to configure the policy map on the router.
17-36
OL-7433-09
Chapter 17

Configuring Per Session Queuing and Shaping for PPPoE Over VLANs Using
RADIUS
To configure per session queuing and shaping, perform the following required configuration tasks:
Configuring a Per Session Queuing and Shaping Policy on the Router, page 17-37
Setting Up RADIUS for Per Session Queuing and Shaping, page 17-40
Configuring a Per Session Queuing and Shaping Policy on the Router

To configure a per session queuing and shaping policy on the router for PPPoE over VLAN sessions
using RADIUS, enter the following commands beginning in global configuration mode:
Step 1
Command
Purpose
policy-map-name

Step 2
Note
Step 3
remaining percent percentage} account
{{{qinq | dot1q} {aal5 | aal3}
{subscriber-encapsulation}} |
{user-defined offset [atm]}}
Repeat Steps 2 and 3 for each traffic class you want to

include in the policy map.
Enables class-based fair queuing.

link bandwidth.
account enables ATM overhead accounting. For more
information, see Chapter 10, Overhead Accounting.
qinq specifies queue-in-queue encapsulation as the broadband
aggregation system-DSLAM encapsulation type.
broadband aggregation system-DSLAM encapsulation type.
connection-oriented variable bit rate (VBR) services. You must
specify either aal5 or aal3.

OL-7433-09
17-37
Chapter 17
Step 3
(cont.)
Command
Purpose
aal3 specifies the ATM Adaptation Layer 5 that supports both

connectionless and connection-oriented links. You must specify
either aal3 or aal5.
subscriber-encapsulation specifies the encapsulation type at the
subscriber line.
user-defined indicates that the router is to use the offset you
specify when calculating ATM overhead.
offset specifies the offset size the router is to use when calculating
ATM overhead. Valid values are from -63 to 63 bytes.
Note
The router configures the offset size if you do not specify

the offset option.
atm applies ATM cell tax in the ATM overhead calculation.

Note
Configuring both the offset and atm options adjusts the

packet size to the offset size and then adds ATM cell tax.
Step 4
Step 5
policy-map-name
Creates or modifies the parent policy.

Step 6

Note

17-38
OL-7433-09
Chapter 17

Step 7
Command
Purpose
Router(config-pmap-c)# shape rate account

Shapes traffic to the indicated bit rate and enables ATM overhead
accounting.
rate is the bit-rate used to shape the traffic, expressed in kilobits
per second.
subscriber line.
Note

the user-defined offset option.

Note
Step 8
policy-map-name


policy map.

OL-7433-09
17-39
Chapter 17
Configuration Example for Configuring a Per Session Queuing and Shaping Policy on the Router
Example 17-22 shows how to configure a per session queuing and shaping policy on the router for
PPPoE over VLAN sessions using RADIUS. The example creates two traffic classes: Voice and Video.
The router classifies traffic that matches IP precedence 5 as Voice traffic and traffic that matches IP
precedence 3 as Video traffic. The Child policy map gives priority to Voice traffic and polices traffic at
2400 kbps. The Video class is allocated 80 percent of the remaining bandwidth and has ATM overhead
accounting enabled. The Child policy is applied to the class-default class of the Parent policy map, which
receives 20 percent of the remaining bandwidth and shapes traffic to 10000 bps, and enables ATM
overhead accounting.
Example 17-22 Configuring a Per Session Queuing and Shaping Policy on the Router
Router(config-cmap)# class-map Video
!
violate-action drop
Router(config-pmap-c)# bandwidth remaining percent 80 account aal5 snap-dot1q-rbe
Router(config)# policy-map Parent
Router(config-pmap-c)# shape 10000 account dot1q snap-dot1q-rbe
Setting Up RADIUS for Per Session Queuing and Shaping

The router allows you to apply QoS policy maps using RADIUS. The actual configuration of the policy
map occurs on the router using the modular QoS CLI (MQC). The router can apply the QoS policy to
sessions using attributes defined in one of the following RADIUS profiles:
The following AV-pairs define the QoS policy to be applied dynamically to the session:
authorization succeeds, the router downloads the name of the policy map from RADIUS using the above
attribute and applies the QoS policy to the session.
17-40
OL-7433-09
Chapter 17

Note
and Cisco-Policy-Up, we recommend that you use the above attributes for QoS policy definitions.
Setting Up RADIUS Using VSA 38

The RADIUS vendor specific attribute (VSA) 38 is used for downstream traffic going toward a
subscriber. The service (policy map name) to which the user session belongs resides on the RADIUS
server. The router downloads the name of the policy map from RADIUS using VSA 38 in the user profile
and then applies the policy to the session.
To set up RADIUS for per session queuing and shaping for PPPoE over VLAN support, enter the
following vendor specific attribute (VSA) in the user profile on the RADIUS server:
Cisco:Cisco-Policy-Down = <service policy name>
The actual configuration of the policy map occurs on the router. The user profile on the RADIUS service
contains an entry that identifies the policy map name applicable to the user. This policy map name is the
service RADIUS downloads to the router using VSA 38.
Note
Although the router also supports RADIUS VSA 38, Cisco-Policy-Down and Cisco-Policy-Up, we
recommend that you use the attributes described in the Setting Up RADIUS for Per Session Queuing
and Shaping section on page 17-40 for QoS policy definitions.
Configuration Example for Setting Up RADIUS for Per Session Queuing and Shaping
Example 17-23 and Example 17-24 are example configurations for the Merit RADIUS server and the
associated Layer 2 network server (LNS). In the example, the Cisco-Policy-Down attribute indicates the
name of the policy map to be downloaded, which in this example is rad_output_policy. The RADIUS
dictionary file includes an entry for Cisco VSA 38.
Example 17-23
VSA 38 for Per Session Queuing and Shaping
abc@hello1.com Password = "cisco123"

Service-Type = Framed-User,
Cisco:Cisco-Policy-Down = rad_output_policy
Example 17-24 Merit RADIUS Dictionary File

Cisco.attr Cisco-Policy-Up 37 string (*, *)
Cisco.attr Cisco-Policy-Down 38 string (*, *)

OL-7433-09
17-41
Chapter 17
Verifying Per Session Queuing and Shaping Policies

To display the configuration of per session queuing and shaping policies for PPPoE over VLAN, enter
any of the following commands in privileged EXEC mode:
Command
Purpose

the router.
interface specifies the virtual-access interface and number the
router created for the session (for example, virtual-access 1).
Router# show policy-map session uid uid-number
Displays the session QoS counters for the subscriber session you
specify.
uid uid-number defines a unique session ID. Valid values for
uid-number are from 1 to 65535.

Verification Examples for Per Session Queuing and Shaping Policies

Example 17-25 shows sample output for the show policy-map interface command. In the example,
overhead accounting is enabled for both shaping and bandwidth.
Example 17-25 Sample Output for the show policy-map interface Command
Router# show policy-map interface virtual-access 1
!
!
Service-policy output: TEST
Match: any
17-42
OL-7433-09
Chapter 17

Example 17-26 shows sample output for the show policy-map session command and show policy-map
session uid command, based on a nested hierarchical policy.
Example 17-26 Sample Output of a Hierarchical Policy
Router# show subscriber session
Current Subscriber Information: Total sessions 1
Uniq ID Interface
State
Service
Identifier
Up-time
36
authen
Local Term
peapen@cisco.com
00:01:36
Vi2.1
Router# show policy-map parent

Policy Map parent
Class class-default
cir 10000000 (bps)
service-policy child
Router# show policy-map child
Policy Map child
Class voice
priority
police 8000 9216 0
conform-action transmit
exceed-action drop
violate-action drop
Class video
bandwidth remaining 80 (%)
Router# show policy-map session uid 36
SSS session identifier 36 SSS session identifier 36 Service-policy output: parent
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
Queueing
Service-policy : child
queue stats for all priority classes:
Queueing
Class-map: voice (match-all)
0 packets, 0 bytes
Priority: Strict, burst bytes 1500, b/w exceed drops: 0

OL-7433-09
17-43
Chapter 17
Shaping and Queuing Per-Session Traffic on LNS
Police:
transmit
drop
drop
Class-map: video (match-all)
0 packets, 0 bytes
Queueing
bandwidth remaining 80% (7993 kbps)
0 packets, 0 bytes
Match: any
0 packets, 0 bytes

The Per Session Shaping and Queuing on LNS feature provides the ability to shape (for example, transmit
or drop) or queue (for transmission later) the traffic from an Internet service provider (ISP) to an ISP
subscriber over a Layer 2 Tunneling Protocol (L2TP) Network Server (LNS). The outgoing traffic is shaped
or queued on a per-session basis.
Shaping and queueing traffic on a per-session basis:
Helps to avoid traffic congestion and allows the ISP to adhere to the Service Level Agreement (SLA)
established for managing traffic.
Provides a high degree of granularity for managing traffic on the network. Figure 17-2 is a sample
topology for per-session shaping and queuing on an LNS.
Figure 17-2
Per-Session Shaping and Queuing TopologyPPP Sessions Forwarded
Downstream traffic
ISP
Subscriber
LAC
L2TP tunnel
PPP session
127500
LNS
17-44
OL-7433-09
Chapter 17

In this simplified topology example:

1.
Downstream traffic is forwarded from the ISP (the source) to an ISP subscriber (the destination)
during a PPP session.
2.
From an LNS at the ISP, the traffic is transmitted over an L2TP tunnel to an L2TP Access
Concentrator (LAC) and then to the subscriber.
3.
A user-defined offset size shapes and queues the per session traffic on an LNS. This offset applies
overhead bytes to outgoing traffic and the router uses the offset when calculating ATM overhead.
4.
To specify the overhead offset in child and parent policies, use the bandwidth and shape
commands. The offset values and encapsulation types must match in the child and parent policies.
Feature History for Per Session Shaping and Queuing on LNS

Cisco IOS Release
Description
Release 12.2(31)SB6
The Per Session Shaping and Queuing on LNS feature was PRE3
introduced on the Cisco 10000 series router.
Required PRE
Prerequisites for Per Session Shaping and Queuing on LNS
Verify that the PPPoE (or PPPoA) sessions are enabled.
Verify that L2TP resequencing is disabled.
This feature uses policy maps in which queuing mechanisms (such as class-based weighted fair
queuing [CBWFQ]) are configured.
Cisco IOS Release 12.2(31)SB8 does not support load balancing when per session shaping and
queuing is configured. However, this release does support load balancing if no output QoS is applied
to the session. Cisco IOS Release 12.2(31)SB6 does not support load balancing at all on the LNS.
Cisco IOS Release 12.2(31)SB10 supports load balancing for all QoS configurations, except those
containing a queuing action that is applied to a session. For example, the router does not support
load balancing for a session if the policy map applied to the session contains the shape, bandwidth,
or priority command.
This feature does not support L2TP sequencing.
This feature only applies when the LAC and LNS are connected by Ethernet.
Configuring Per Session Shaping and Queuing on LNS

To configure per session shaping and queuing over a L2TP LNS, perform the following configuration
task:
Configuring a Per Session Shaping and Queuing on LNS Policy, page 17-46

OL-7433-09
17-45
Chapter 17
Configuring a Per Session Shaping and Queuing on LNS Policy

To configure a per session shaping and queuing on LNS policy, enter the following commands beginning
Step 1
Command
Purpose
policy-map-name

Step 2
17-46
OL-7433-09
Chapter 17

Step 3
Command
Purpose

link bandwidth.
subscriber line.
Note

the offset option.

Note

Step 4
Step 5
policy-map-name

Step 6

Note


OL-7433-09
17-47
Chapter 17
Step 7
Command
Purpose

accounting.
per second.
subscriber line.
Note


Note
Step 8
policy-map-name


policy map.
Step 9
Step 10
(Optional) Creates a virtual template interface and enters

Step 11
Router(config-if)# service-policy
policy-map-name
number identifies the virtual template.

(Optional) Attaches the parent policy to the virtual template
interface.
policy-map-name is the name of the previously configured parent
policy map.
17-48
OL-7433-09
Chapter 17

Configuration Example for Configuring a Per Session Shaping and Queuing on LNS Policy
Example 17-27 shows how to configure a per session shaping and queuing on LNS policy. In this
example, the router uses 20 overhead bytes and ATM cell tax in calculating ATM overhead. The child
and parent policies contain the required matching offset values. The parent policy is attached to virtual
template 1.
Example 17-27 Configuring Per Session Shaping and Queuing on LNS Policy on the Router
policy-map child
class class1
bandwidth 500 account user-defined 20 atm
class class2
shape average 30000 account user-defined 20 atm
policy-map parent
class class-default
interface virtual-template 1
service-policy output parent
Verifying Per Session Shaping and Queuing on LNS Policies

To display the configuration of per session shaping and queuing on LNS policies, enter the following
Command
Purpose
Router# show policy-map [policy-map]
Displays the configuration of all classes for a specified service

policy map or all classes for all existing policy maps.
policy-map specifies the name of the policy map.

shows the configuration of the policy maps.

OL-7433-09
17-49
Chapter 17
Verification Examples for Per Session Shaping and Queuing on LNS Policies
Example 17-28 shows sample output for the show policy-map command. In the example, the router uses
20 overhead bytes in calculating ATM overhead.
Example 17-28 Sample Outputshow policy-map Command
Policy Map child
Class Class1
cir 20% account user-defined 20
Example 17-29 shows sample output for the show running-config command. In the example, the output
modifier starts the display at the Parent policy map line.
Example 17-29 Sample Outputshow running-config Command
Router# show running-config | begin Parent
Policy Map Parent
class class1
shape average percent 20 account user-defined 20 atm
policy-map child
class class2
!

PPP Session Queuing on ATM Virtual Circuits (VCs) enables you to shape and queue PPP over ATM
(PPPoA) and PPP over Ethernet over ATM (PPPoEoA) sessions to a user specified rate. Multiple
sessions can exist on any ATM VC and have QoS policies applied, or some of the sessions might have
QoS policies while others do not. The router shapes the sum of all PPPoA or PPPoEoA traffic on a VC
so that the subscribers connection to the DSLAM does not become congested. Queuing-related
functionality provides different levels of service to the various applications that execute over the PPPoA
or PPPoEoA session.
A nested, 2-level hierarchical service policy is used to configure session shaping directly on the router
using the modular quality of service command-line interface (MQC):
Child policy [of the hierarchical service policy]Defines QoS actions using QoS commands such
as the priority, bandwidth, and police commands.
Parent policyContains only the class-default class with the shape or bandwidth remaining ratio
command configured, or with both commands configured:
shape commandShapes the session traffic to the specified bit rate, according to a specific
algorithm.
bandwidth remaining ratio commandSpecifies a ratio value that the router uses to
determine how much unused bandwidth to allocate to the session during congestion.
For more information about nested hierarchical policies, see the Nested Hierarchical Policies section
on page 13-6.
17-50
OL-7433-09
Chapter 17

Note
The PPP Session Queuing on ATM VCs feature applies to both PPP terminated aggregation (PTA) and
L2TP access concentrator (LAC) configurations.
Figure 17-3 illustrates PPP session queuing on ATM VCs.
Figure 17-3
PPPoE Session
Interface with shaper
Voice
ATM VC
Session #1
with QoS
Video
Interface without shaper
pppoe-Session
Data-premium
HW Interface
Class-default
Session #2
without QoS
191919
pppoe-Session
Another VC on same interface
More sessions with

or without QoS
Feature History for PPP Session Queuing on ATM VCs

Cisco IOS Release
Description
Required PRE
Release 12.2(31)SB6
The PPP Session Queuing on ATM VCs feature was

introduced on the Cisco 10000 series router and
implemented on the PRE3.
PRE3
Dynamically Applying QoS Policies to PPP Sessions on ATM VCs

The router allows you to dynamically apply QoS policy maps to PPPoA and PPPoEoA sessions using
RADIUS. Although the actual configuration of the QoS policies occurs on the router, you can configure
the following attribute-value (AV) pairs on RADIUS to specify the name of the policy map to
dynamically apply to the session:
You define the AV-pairs in one of the following RADIUS profiles:

OL-7433-09
17-51
Chapter 17
authorization succeeds, the router downloads the name of the policy map from RADIUS using the
ip:sub-qos-policy-in[out]= AV-pair and applies the QoS policy to the PPPoA or PPPoEoA
session. Because the service policy contains queuing-related actions, the router sets up the appropriate
class queues.
Note
and Cisco-Policy-Up, we recommend that you use the ip:sub-qos-policy-in[out]= AV-pairs for QoS
policy definitions.
PPP Session Queuing Inheritance

Sessions either inherit queues from their parent interface or they have their own queues. Each PPPoA or
PPPoEoA session for which session queuing is configured has its own set of queues.
Table 17-3 describes the queues to which the router directs session traffic.
Table 17-3
Queue Inheritance
Queuing Policy
Queue Used for Session Traffic
No policy
VC default queue
Applied to the VC
VC queues
Applied to the session
Session queues
Interfaces Supporting PPP Session Queuing

The router supports PPP session queuing on shaped ATM virtual circuits (VCs) for outbound traffic only.
The router does not support PPP session queuing on inbound ATM interfaces.
Mixed Configurations and Queuing

A mixed configuration is one in which all sessions do not have QoS applied to them. On some VCs, the
queuing policy is applied at the VC level, while on other VCs the queuing policies are applied on the
sessions. Some sessions have no policy applied at all. As a result, the router uses the hierarchical queuing
framework (HQF) to direct traffic in the following ways:
If no queuing policy is applied at the VC or session level, the router sends all traffic on the VC to
the default queue, including traffic from sessions on the VC that have a policing-only policy applied
or no policy applied.
If a queuing policy is applied at the VC level, but not at the session level, the router sends traffic to
the queues associated with the queuing policy on the VC.
17-52
OL-7433-09
Chapter 17

If queuing policies are applied to some sessions on a VC but not to other sessions, the router sends
the traffic with a policing-only policy or with no policy applied to the VCs default queue. The router
sends traffic with queuing policies to the queues associated with the queuing policy applied to the
session.
Bandwidth Sharing and ATM Port Oversubscription

An ATM port can operate in reserved bandwidth mode or shared bandwidth mode.
When a port is not oversubscribed (the sum of the bandwidths of all VCs on the port is less than the port
bandwidth), the port operates in reserved bandwidth modea specific amount of bandwidth is reserved
for each VC on the port. If a VC does not use all of its allocated bandwidth, the unused bandwidth is not
shared among the VCs on the port.
When the ATM port is oversubscribed (the sum of the bandwidths of all VCs on the port is greater than
the port bandwidth), the port operates in shared bandwidth mode. In this mode, any unused bandwidth
is available for re-use by the other VCs on the port, up to the VCs respective shape ratetraffic on a
VC cannot exceed the shape rate of that VC.
Oversubscription at the Session Level

Oversubscription at the session level occurs after session traffic shaping and when the aggregate session
traffic exceeds the subinterface shape rate. After all priority traffic is accounted, the router distributes
the remaining bandwidth on the VC to the sessions according to the value specified in the bandwidth
remaining ratio command configured in the parent policy of the policy applied to the sessions. If the
bandwidth remaining ratio command is not specified in the parent policy, the router uses a default ratio
of 1.
Prerequisites for PPP Session Queuing on ATM VCs
PPPoA or PPPoEoA sessions must be enabled.
Create traffic classes using the class-map command and specify the match criteria used to classify
traffic.
For dynamic PPPoA or PPPoEoA session queuing using RADIUS, you must:
Enable authentication, authorization, and accounting (AAA) on the router
Configure the RADIUS server for dynamic QoS
Create the subscribers user profile on the RADIUS server
Restrictions and Limitations for PPP Session Queuing on ATM VCs
You cannot configure PPP session queuing on unshaped VCsVCs without a specified peak cell
rate (PCR) or sustained cell rate (SCR).
Although you can configure oversubscription at the VC level, the router does not guarantee priority
queuing (PQ) and fair treatment among VCs during congestion.
VCs with session queuing polices cannot be part of a shaped virtual path (VP).

OL-7433-09
17-53
Chapter 17
PPP session queuing does not allow you to simultaneously configure queuing policies on a VC and
on a session of that VC, although the router permits the configuration.
The maximum number of VCs with PPP session queuing policies cannot exceed 16,000 VCs system
wide.
If the same ATM category (for example, shaped unspecified bit rate (UBR)) contains both high and
low bandwidth VCs, the SAR mechanism can cause low throughput for high bandwidth VCs. The
workaround for this issue is to use different ATM classes for low and high bandwidth VCs. For
example, configure low bandwidth VCs as shaped UBR and high bandwidth VCs as variable bit
rate-nonreal-time (VBR-nrt) or constant bit rate (CBR).
When you apply queuing policies to sessions, do not apply a policy at the VC level on the same VC.
The CLASS-BASED QOS MIB does not include statistics for service policies applied to sessions.
RADIUS accounting does not include queuing statistics.
The router ignores the VC weight when it is configured on a VC with PPP session queuing
configured.
Configuring PPP Session Queuing on ATM VCs

You can apply hierarchical shaping policies to sessions using a virtual template or RADIUS. When you
apply shaping policies to sessions, do not apply a policy at the VC level on the same VC.
To configure PPP session queuing on ATM VCs, perform one of the following configuration tasks:
Configuring PPP Session Queuing Using a Virtual Template, page 17-54
Configuring PPP Session Queuing Using RADIUS, page 17-60
Configuring PPP Session Queuing Using a Virtual Template

To configure PPPoA or PPPoEoA session queuing using a virtual template, perform the following
Configuring an Hierarchical QoS Policy, page 17-54
Associating the Hierarchical Policy Map with a Virtual Template, page 17-57
Applying the Virtual Template to an ATM Subinterface, page 17-58
Configuring an Hierarchical QoS Policy

To configure a hierarchical QoS policy, enter the following commands, beginning in global configuration
mode:
Step 1
Command
Purpose
policy-map-name

configuration mode.
17-54
OL-7433-09
Chapter 17

Step 2
Command
Purpose
Note
Step 3
Router(config-pmap-c)# priority level

level
Repeat Steps 2 through 6 for each traffic class you want

to include in the child policy map. For information about
other QoS actions you can specify for the traffic classes,
see the Input and Output Policy Actions section in the
Configuring QoS Policy Actions and Rules chapter of
the Cisco 10000 Series Router Quality of Service
(Optional) Defines multiple levels of a strict priority service

model. When you enable a traffic class with a specific level of
priority service, the implication is a single priority queue
associated with all traffic enabled with the specified level of
priority service.
level is a number that indicates a specific priority level. Valid
values are from 1 (high priority) to 4 (low priority). Default: 1
Step 4
Router(config-pmap-c)# police bps

[burst-normal] [burst-max] [conform-action
(Optional) Configures traffic policing.

bps is the average rate in bits per second. Valid values are 8000 to
200000000.
(Optional) burst-normal is the normal burst size in bytes. Valid
values are 1000 to 51200000. The default normal burst size is
1500 bytes.
(Optional) burst-max is the excess burst size in bytes. Valid values
are 1000 to 51200000.
(Optional) conform-action action indicates the action to take on
packets that conform to the rate limit.
(Optional) exceed-action action indicates the action to take on
packets that exceed the rate limit.
(Optional) violate-action action indicates the action to take on
packets that violate the normal and maximum burst sizes.
Step 5
Router(config-pmap-c)# set cos value
(Optional) Sets the Layer 2 class of service (CoS) value of an

outgoing packet.
value is a specific IEEE 802.1Q CoS value from 0 to 7.
Step 6
remaining ratio
(Optional) Specifies a bandwidth-remaining ratio for class-level

or subinterface-level queues to be used during congestion to
determine the amount of excess bandwidth (unused by priority
traffic) to allocate to non-priority queues.
ratio specifies the relative weight of this subinterface or queue
with respect to other subinterfaces or queues. Valid values are
from 1 to 1000.
Step 7

OL-7433-09
17-55
Chapter 17
Step 8
Command
Purpose
policy-map-name

Step 9

Note
Step 10
remaining ratio


from 1 to 1000.
Step 11

mean-rate [burst-size]
[excess-burst-size] [account {qinq |
dot1q} aal5 subscriber-encap]
accounting.
(Optional) average is the committed burst (Bc) that specifies the
maximum number of bits sent out in each interval. This option is
only supported on the PRE3.
mean-rate is also called committed information rate (CIR).
Indicates the bit rate used to shape the traffic, in bits per second.
When this command is used with backward explicit congestion
notification (BECN) approximation, the bit rate is the upper
bound of the range of bit rates that are permitted.
(Optional) burst-size is the number of bits in a measurement
interval (Bc).
(Optional) excess-burst-size is the acceptable number of bits
permitted to go over the Be.
aal5 is the ATM Adaptation Layer 5 that supports
subscriber-encaps specifies the encapsulation type at the
subscriber line. For more information, see the Subscriber Line
Encapsulation Types section on page 10-5.
Step 12
policy-map-name

policy-map-name is the name of the child policy map configured
in step 1.
17-56
OL-7433-09
Chapter 17

The following example shows how to configure a hierarchical QoS policy. In the example, the
child-policy configures QoS features for two traffic classes: Premium and Silver. Premium traffic has
priority and is policed at 40 percent. The router sets the IP precedence of Premium traffic to precedence
level 3. Silver traffic is policed at 80000 bps and IP precedence level 3 is set. The child-policy is applied
to the Parent policy class-default class, which shapes traffic to 200,000 Kbps.
Router(config)# policy-map child-policy
Router(config-pmap-c)# police 80000 10000 conform-action transmit exceed-action drop
Router(config-pmap-c)# service-policy output child-policy
Router(config)#
Associating the Hierarchical Policy Map with a Virtual Template

A virtual template is a logical interface whose configuration can specify generic configuration
information for a specific purpose, user-specific configuration information, and router-dependent
information. You configure a virtual template on an interface and apply QoS policy maps to the virtual
template. The virtual template inherits the QoS features specified in the policy map. When the router
establishes sessions on an interface, the router applies the QoS features specified in the virtual template
configuration to the virtual access interfaces (VAIs) created for the sessions, including the QoS features
specified in the policy map attached to the virtual template.
To associate the hierarchical policy map with a virtual template, enter the following commands
Step 1
Command
Purpose
virtual-template template-number
Creates a virtual template and enters interface configuration

mode.
template-number is the number you assign to the virtual template
interface to identify it. Valid values are from 1 to 200.
Note
Step 2

You can configure up to 200 virtual template interfaces on

the router.
Attaches the policy map you specify to the virtual template

interface in the inbound or outbound direction that you specify.
input specifies to apply the policy map to inbound traffic.
output specifies to apply the policy map to outbound traffic.
map.
Step 3
Exits interface configuration mode.

OL-7433-09
17-57
Chapter 17
The following example shows how to associate a policy map with a virtual template. In this example, the
policy map named Parent is associated with the virtual template named VirtualTemplate1.
Router(config-if)# service-policy output Parent
Router(config)#
Applying the Virtual Template to an ATM Subinterface

A broadband aggregation group (bba-group) configured on an ATM interface points to the virtual
template the router uses to apply QoS policies to sessions. When a session arrives on an ATM interface,
the router creates a virtual access interface (VAI) for the session and applies the policies associated with
the virtual template to the sessions.
To apply the virtual template with its associated hierarchical policy to an ATM subinterface, enter the
Step 1
Command
Purpose
Router(config)# bba-group pppoe

group-name
Creates a PPP over Ethernet (PPPoE) profile. Enters BBA group

configuration mode.
group-name is the name of the PPPoE profile.
Step 2
Router(config-bba-grp)# virtual-template
template-number
Associates a BBA group to the virtual template to be used for

cloning virtual access interfaces.
template-number is the identifying number of the virtual
template.
Step 3
Router(config-bba-grp)# exit
Exits BBA group configuration mode.
Step 4

number.subinterface [point-to-point]

configuration mode.
atm is the interface type.
number is the slot, module, and port number of the interface (for
example 1/0/0).
.subinterface is the number of the subinterface (for example,
1/0/0.1).
(Optional) point-to-point indicates that the subinterface connects
directly with another subinterface.
17-58
OL-7433-09
Chapter 17

Step 5
Command
Purpose
Router(config-subif) pvc [name] vpi/vci
Creates or modifies an ATM permanent virtual circuit (PVC).

Enters ATM virtual circuit configuration mode.
(Optional) name identifies the PVC and can contain up to 15
characters.
vpi/ specifies the ATM network virtual path identifier (VPI) for
this PVC. You must specify the slash. Valid values are from 0 to
255. The router treats a value that is outside the range of valid
values as the connection ID. The default value is 0.
Note
The arguments vpi and vci cannot both be set to 0; if one

is 0, the other cannot be 0.
vci specifies the ATM network virtual channel identifier (VCI) for
this PVC. Valid values are from 0 to 1 less than the maximum
value set for this interface by the atm vc-per-vp command. A
value that is out of range causes an "unrecognized command"
error message.
Note
Step 6
Router(config-atm-vc)# protocol pppoe

group group-name
The VCI value has local significance only and, therefore,

is unique only on a single link, not throughout the ATM
network. Typically, lower values from 0 to 31 are reserved
for specific traffic (for example, F4 OAM, SVC signaling,
ILMI, and so on) and should not be used.
Enables PPP over Ethernet (PPPoE) sessions to be established on

group specifies a PPPoE profile (bba-group) to be used by PPPoE
sessions on the interface.
group-name is the name of the PPPoE profile (bba-group) to be
used by PPPoE sessions on the interface.
Note
The group group-name points to the bba-group to be used

for applying a virtual template interface with QoS policies
to sessions.
Step 7
Exits ATM virtual circuit configuration mode.
Step 8
The following example shows how to associate a virtual template interface with an ATM interface and
apply the policies in the virtual template to the sessions on the interface. In the example, the service
policy named Parent is applied to the Virtual-Template 8, which is associated with the bba-group named
pppoeoa-group. The bba-group is applied to PVC 101/210 on ATM subinterface 4/0/1.10.
bba-group pppoe pppoeoa-group
Virtual-Template 8
pvc 101/210
vbr-nrt 4000 2000 50
no dbs enable
protocol pppoe group pppoeoa-group
!

OL-7433-09
17-59
Chapter 17

peer default ip address pool pool-1
Configuring PPP Session Queuing Using RADIUS

To configure PPPoA or PPPoEoA session queuing using RADIUS, perform the following configuration
tasks:
Configuring the Policy Map, page 17-60
Adding the Cisco QoS AV Pairs to the RADIUS Profile, page 17-60
Configuring the Policy Map

The router allows you to use RADIUS to apply QoS policy maps to PPPoA or PPPoEoA sessions. The
actual configuration of the policy map, however, occurs on the router using the modular QoS CLI
(MQC).
To configure QoS policy maps and apply them to virtual template interfaces, see the Configuring an
Hierarchical QoS Policy section on page 17-54 and the Associating the Hierarchical Policy Map with
a Virtual Template section on page 17-57.
Adding the Cisco QoS AV Pairs to the RADIUS Profile

Cisco attribute-value (AV) pairs are vendor-specific attributes (VSAs) that allow vendors such as Cisco
to support their own extended attributes. RADIUS attribute 26 is a Cisco VSA used to communicate
vendor-specific information between the router and the RADIUS server.
The RADIUS user profile contains an entry for each user that the RADIUS server authenticates. Each
entry establishes an attribute the user can access. When configuring PPPoA or PPPoEoA session queuing
using RADIUS, enter the following Cisco AV-pair in the appropriate user profile:
Cisco-AVPair = "ip:sub-qos-policy-out=<name of egress policy>"
The Cisco AV-pair identifies the policy map the router is to use when applying QoS features to a PPPoA
or PPPoEoA session. After receiving a service-logon request from the policy server, RADIUS sends a
change of authorization (CoA) request to the router to activate the service for the user, who is already
logged in. If the authorization succeeds, the router downloads the name of the policy map from RADIUS
using the Cisco AV-pair and applies the QoS policy to the session.
Note
and Cisco-Policy-Up, we recommend that you use the above attribute for QoS policy definitions. For
more information about attribute 38, see the Setting Up RADIUS Using VSA 38 section on
page 17-41.
Configuration Examples for PPP Session Queuing on ATM VCs

Example of Configuring PPP Session Queuing on ATM VCs, page 17-61
Example of Configuring and Applying an Hierarchical Policy Map, page 17-61
Example of Setting Up RADIUS for PPP Session Queuing on ATM VCs, page 17-62
17-60
OL-7433-09
Chapter 17

Example of Configuring PPP Session Queuing on ATM VCs

The following example shows how to configure PPPoA or PPPoEoA session queuing. In the example, a
hierarchical QoS policy named pm_hier2_0_2 is associated with Virtual-Template555, which is applied
to the broadband aggregation group named pppoeoa-group.
Example 17-30 Configuring PPP Session Queuing on ATM VCs
Virtual-Template 555
!
policy-map pm_hier2_child_0_2
class cm_0
priority level 1
violate-action drop
queue-limit 77 packets
class cm_1
shape average percent 80
class class-default
policy-map pm_hier2_0_2
class class-default
service-policy pm_hier_child_0_2
pvc 1/5555
vbr-nrt 4000 2000 50
no dbs enable
!
!
service-policy output pm_hier2_0_2
Example of Configuring and Applying an Hierarchical Policy Map

Example 17-31 shows how to configure a hierarchical policy and apply it to a virtual template. The
example contains a child policy map named child1 with QoS features defined for the gold and bronze
traffic classes. The child1 policy is applied to the parent policy map, which is shaped to 512000 bps. The
hierarchical policy is applied to the virtual template named virtual-template 1.
Example 17-31 Configuring an Hierarchical Policy Map
Router(config)# policy-map child1
Router(config-pmap-c)# class bronze

OL-7433-09
17-61
Chapter 17

Router(config-pmap)# policy-map parent
Router(config-pmap-c)# service-policy child1
Router(config)# interface virtual-template 1
Router(config-if)# service-policy output parent
Example of Setting Up RADIUS for PPP Session Queuing on ATM VCs

Example 17-32 shows how to define the Cisco AV-pairs used to download the policy map name to the
router. The first three lines of a subscribers sample user profile contain the user password, service type,
and protocol type. This information is entered into the subscribers user profile when the user profile is
first created. The last line is an example of the Cisco QoS AV-pair added to the user profile. The policy
map name downloaded to the router is p23.
Example 17-32 Setting Up RADIUS for PPP Session Queuing on ATM VCs
userid
Password = "cisco"
cisco-avpair = "sub-qos-policy-out=p23"
Verifying PPP Session Queuing on ATM VCs

To verify PPPoA or PPPoEoA session queuing, use any of the following commands in privileged EXEC
mode:
Command
Purpose

the router.
atm 4/0/0).
17-62
OL-7433-09
Chapter 17

Command
Purpose
Router# show policy-map session [uid uid-number]

[input | output [class class-name]]
Displays the QoS policy map in effect for subscriber sessions.

(Optional) uid defines a unique session ID.
(Optional) uid-number is a unique session ID. Valid values are
from 1 to 65535.
(Optional) input displays the upstream traffic of the unique
session.
(Optional) output displays the downstream traffic of the unique
session.
(Optional) class identifies the class that is part of the QoS
policy-map definition.
(Optional) class-name provides a class name that is part of the
QoS policy-map definition.
Router# show pxf cpu queue [interface | QID |

summary]
Displays parallel express forwarding (PXF) queuing statistics.

(Optional) interface is the interface for which you want to display
PXF queuing statistics. This displays PXF queuing statistics for
the main interface and all subinterfaces and permanent virtual
circuits (PVCs). It also displays packets intentionally dropped due
to queue lengths.
(Optional) QID is the queue identifier.
(Optional) summary displays queue scaling information such as:
Router# show pxf cpu queue session [sid

sid-value]
Number of queues and recycled queues.
Number of available queue IDs (QIDs).

packet buffers.
Displays PXF queuing statistics for sessions.

(Optional) sid displays queuing statistics for a specific session
identifier.
sid-value is a number that represents a specific session ID. Valid
values are from 1 to 65,535.

ATM VC, PPPoA or PPPoEoA, dynamic bandwidth selection,
virtual template, and RADIUS server.
Examples of Verifying PPP Session Queuing on ATM VCs

Example 17-33 shows the type of information displayed when you enter the show pxf cpu queue session
command. In the example, the show pppoe session command is used to display the sessions established
on the router. In this case, one session is active with a session ID (SID) of 6. The example then displays
configuration and statistical information for that specific session using the show pxf cpu queue session
command.

OL-7433-09
17-63
Chapter 17
Example 17-33 Displaying PPP Session Informationshow pxf cpu queue session Command
1 session in LOCALLY_TERMINATED (PTA) State
1 session total
Uniq ID
14
PPPoE
SID
6
RemMAC
LocMAC
0009.b68d.bb37
0009.b68d.bc37
Port
ATM2/0/7.5555
VC: 1/5555
VT
VA
VA-st
Vi3.1
555
State
Type
PTA
UP
Router#
Router#
Router# show pxf cpu queue session sid 6
ATM2/0/7.5555: PVC 1/5555
VCCI/ClassID
ClassName
2623/0
class-default
$1
2623/1
cm_0
2623/2
cm_1
2623/31
net-control
QID Length/Avg
1858
0/0
1856
0/0
1859
0/0
591
0/1
Max
77
77
40
1105
Dequeues
0
0
0
335137
Drops(Tail/Random)
0/0
0/0
0/0
0/0
Legend:
$x: Priority Queue level x
b: PQ Activation and Dequeue Blocked
~: RED Queue
P: MLP Pkt Queue
F: MFR Pkt Queue
M1:MLP , M5:MLPFR , MA:MLPOA , M6:FRF12 , M7:MLFR, M8:FRF12_16
Example 17-34 uses the show policy-map session command to display QoS policy map statistics for
traffic in the downstream direction. The example also shows the policy map configurations.
Example 17-34 Displaying PPP Session Informationshow policy-map session Command
1 session total
Uniq ID
14
PPPoE
SID
6
RemMAC
Port
LocMAC
0009.b68d.bb37
ATM2/0/7.5555555
0009.b68d.bc37 VC: 1/5555
VT
VA
VA-st
Vi3.1
UP
State
Type
PTA
Router#
Router#
SSS session identifier 14 Service-policy output: pm_hier2_0_2
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
Queueing
17-64
OL-7433-09
Chapter 17


Service-policy : pm_hier2_child_0_2
Queueing
priority level 1
Class-map: cm_0 (match-any)
0 packets, 0 bytes
0 packets, 0 bytes
Priority: 0% (0 kbps), burst bytes 4470, b/w exceed drops: 0
Priority Level: 1
Police:
0 packets, 0 bytes
0 packets, 0 bytes
Queueing
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
Queueing
Router# show policy-map pm_hier2_0_2
Policy Map pm_hier2_0_2
Class class-default
cir 100%
service-policy pm_hier2_child_0_2

OL-7433-09
17-65
Chapter 17
Router# show policy-map pm_hier2_child_0_2

Policy Map pm_hier2_child_0_2
Class cm_0
priority level
police percent
violate-action
queue-limit 77
1
5 2 ms 0 ms conform-action transmit exceed-action drop
drop
packets
Class cm_1
cir 80%
Class class-default
cir 50%
Feature
Pull and push functionality
Define Interface Policy-Map AV Pairs AAA feature module,

Release 12.2(28)SB
Dynamic bandwidth selection
Cisco IOS Wide-Area Networking Configuration Guide,

Release 12.3
Part 2: Broadband Access > Configuring Broadband Access:
PPP and Routed Bridge Encapsulation > Dynamic Subscriber
Bandwidth Selection
Dynamic Bandwidth Selection, Release 12.2(13)T and 12.2SB
feature module
RADIUS
Cisco IOS Security Configuration Guide, Release 12.3

Part 2: Security Server Protocols > Configuring RADIUS
17-66
OL-7433-09
CH A P T E R
18

With the increasing demand for Internet services, service providers must ensure that network resources
are available to all subscribers as contracted in their Service License Agreements (SLAs). Service
providers must determine which traffic enters the network, how to distribute shared resources, and how
to manage the volume and rate of traffic entering the network. Without such management, providing
basic services to subscribers can become difficult.
Rate limiting and shaping subscriber traffic are two tools critical to ensuring successful network
operation. Using these tools to regulate subscriber traffic, service providers can protect shared network
resources and ensure that subscribers use only their fair share of bandwidth.
This chapter describes the following subscriber-based traffic regulating and shaping features:
Subscriber-Based IP Quality of Service, page 18-2

Configuring IP Quality of Service for Subscribers, page 18-9
Configuration Examples for Subscriber-Based IP QoS, page 18-12
Verifying a Subscriber-Based IP QoS Configuration, page 18-16
MQC Support for IP Sessions, page 18-18

Feature History for MQC Support for IP Sessions, page 18-19
QoS Actions Supported in IP Session Policy Maps, page 18-19
Interface Support for MQC on IP Sessions, page 18-19
Service Policy Maps and Service Profiles, page 18-20
Restrictions and Limitations for MQC Support for IP Sessions, page 18-20
Configuring MQC on IP Sessions, page 18-21
Configuration Examples for MQC on IP Sessions, page 18-23
Verifying Service Policies on IP Sessions, page 18-24
Shaping and Queuing Per-Session Traffic on LNS, page 18-24

Feature History for Per Session Shaping and Queuing on LNS, page 18-25
Prerequisites for Per Session Shaping and Queuing on LNS, page 18-25
Restrictions and Limitations for Per Session Shaping and Queuing on LNS, page 18-25
Configuring Per Session Shaping and Queuing on LNS, page 18-25

OL-7433-09
18-1
Chapter 18
Subscriber-Based IP Quality of Service
Queuing PPP Sessions on ATM VCs, page 18-29

Feature History for PPP Session Queuing on ATM VCs, page 18-30
Dynamically Applying QoS Policies to PPP Sessions on ATM VCs, page 18-30
PPP Session Queuing Inheritance, page 18-31
Interfaces Supporting PPP Session Queuing, page 18-31
Mixed Configurations and Queuing, page 18-31
Bandwidth Sharing and ATM Port Oversubscription, page 18-32
Oversubscription at the Session Level, page 18-32
Prerequisites for PPP Session Queuing on ATM VCs, page 18-32
Restrictions and Limitations for PPP Session Queuing on ATM VCs, page 18-32
Configuring PPP Session Queuing on ATM VCs, page 18-33
Configuration Examples for PPP Session Queuing on ATM VCs, page 18-39
Verifying PPP Session Queuing on ATM VCs, page 18-41
Per-Session Shaping for ATM Interfaces, page 18-45

Feature History for Per-Session Shaping for ATM Interfaces, page 18-46
Restrictions and Limitations for Per-Session Shaping for ATM Interfaces, page 18-46
Configuring Per-Session Shaping for ATM Interfaces, page 18-46
Configuration Example for Per-Session Shaping on ATM Interfaces, page 18-50
Verifying Per-Session Shaping on ATM Interfaces, page 18-50

The Cisco 10000 series router supports the following IP quality of service features for subscribers:
Differential marking of the IP ToS bits (see the IP Differentiated Services Code Point Marking
section on page 7-6)
Per User QoS Selection (see the Applying Traffic Shaping Parameters Using RADIUS Profiles
section on page 17-2 in Chapter 17, Configuring Dynamic Subscriber Services.)
18-2
OL-7433-09
Chapter 18

Per Session Rate Limiting

The per session rate limiting feature is a traffic regulation mechanism that allows you to control the
maximum rate of traffic sent or received on an interface for a session. The feature is configured on
interfaces at the edge of a network to limit traffic into or out of the network. The rate limiting feature
uses the modular QoS CLI to provide input and output policing rates for each session.
The Cisco 10000 series router uses policing to manage the access bandwidth policy for the following
subscriber-based sessions:
PPPoA
PPPoE
PPP in L2TP (LNS only)
RBE
The configuration of per session rate limiting involves the following components:
Class mapClassifies the traffic on an interface. The class map uses the match statements that you
define to classify subscriber traffic.
Policy mapDefines QoS actions and rules and associates these to a class map. The policy map
specifies the class map for a session and also indicates the policing actions to perform.
Service policyAttaches a policy map to an interface and specifies the direction (inbound or
outbound) that the policy should be applied.
QoS configuration typically involves applying the service policies to interfaces. For PPPoA, PPPoE, and
PPP in L2TP sessions, however, you apply the service policy to a predefined configuration template
known as the virtual template interface. The virtual template interface is a logical entity that is applied
dynamically as needed to a connection. It is used to create and configure a virtual access interface (VAI).
The VAI uses the virtual template interface to create a session, which results in a VAI that is uniquely
configured for a specific user. All of the VAIs that use the virtual template interface inherit the service
policy applied to the template.
Note
Not all of the QoS actions available through the modular QoS CLI are available to the virtual access
interface. For information about the available actions, see the Input and Output Policy Actions section
on page 18-7.
For CBWFQ on the Cisco 10000 series router, when you apply a service policy to a virtual circuit (VC),
the VAIs that use that VC inherit the service policy of the VC. Any VAI that uses that VC is subject to
the queuing, policing, and marking actions defined in the VC service policy.
Note
Do not apply service policies with CBWFQ actions to a VAI using a virtual template. The Cisco 10000
series router supports queuing only when you apply the service policy to a VC.
You can also configure per session rate limiting using a Cisco vendor specific attribute (VSA) in a
RADIUS user profile. For more information, see the Per Session Service Policy Using RADIUS
For RBE sessions, apply the service policy to the ATM VC or subinterface.

OL-7433-09
18-3
Chapter 18
Feature History for Per Session Rate Limiting

Cisco IOS Release
Description
Required PRE
Release 12.2(16)BX
The per session rate limiting feature was introduced on the PRE2
PRE2.
Release 12.2(28)SB

PRE2
Restrictions and Limitations for Per Session Rate Limiting

Per User Multiservice Rate Limiting

The per user multiservice rate limiting feature allows you to control the maximum rate of traffic for each
user behind a multiservice subscriber. This rate limiting feature uses the modular QoS CLI to provide
input and output policing rates for each user.
The configuration of per user multiservice rate limiting involves the following components:
Access Control Lists (ACLs)Create a unique ACL for each user behind the subscriber. The criteria
you specify, such as a user IP address, is used to filter the traffic coming into or leaving the
Cisco 10000 series router interface.
Class mapClassifies the traffic on an inbound or outbound interface. The class map uses the match
statements that you define to classify subscriber traffic.
Policy mapDefines QoS actions and rules and associates these to a class map. The policy map
specifies the class map for a session and also indicates the policing actions to perform.
Service policyAttaches a policy map to an interface and specifies the direction (inbound or
outbound) that the policy should be applied.
For PPPoA, PPPoE, and PPP in L2TP sessions, apply the service policy to a virtual template interface,
which is used to create and configure a VAI. The VAI uses the virtual template interface to create a
uniquely configured user session. All of the VAIs that use the virtual template interface inherit the
service policy applied to it.
For RBE sessions, apply the service policy to the ATM virtual circuit (VC) or subinterface.
Note
18-4
OL-7433-09
Chapter 18

Feature History for Per User Multiservice Rate Limiting

Cisco IOS Release
Description
Required PRE
Release 12.2(16)BX
The per user multiservice rate limiting feature was

PRE2
Release 12.2(28)SB

PRE2
System Limits for Per User Multiservice Rate Limiting

Table 18-1 lists the system limits for the components used to configure per user multiservice rate
limiting.
Table 18-1 System Limits for Per User Multiservice Rate Limiting Components
Component
Maximum Number Supported
Access Lists
30,000 per system
Class Maps
256 per system (including the class-default class)
Policy Maps
4096 per system
Classes
127 per policy map
Match Statements
16 per class map
Depending on the complexity of your configuration, the Cisco 10000 series router supports up to 4,096
policy maps. In complex configurations the maximum number of policy maps can be as small as a few
hundred. Additionally, when you use percent-based policing in a service policy, the system may convert
a single customer-configured service to multiple service policies (which count against the 4096 limit).
The system uses one such service policy for each different speed interface that uses a service policy with
percent-based policing
Each policy-map command counts as one policy map and applying the same policy map on different
speed interfaces also counts as an extra policy map. The policy-map command syntax is unchanged.
Restrictions and Limitations for Per User Multiservice Rate Limiting

Per Session Service Policy Using RADIUS

The per session service policy using RADIUS feature enables a subscriber management server (SMS),
typically a RADIUS server, to dynamically change the traffic policing parameters for a user session.
The RADIUS server maintains user profiles to define subscriber parameters. The per session rate
limiting parameter is defined in the RADIUS authentication, authorization, and accounting (AAA) user
profiles. When a user logs into the network, the Cisco 10000 series router sends an authorization request
to the RADIUS server. If the user is a registered user, RADIUS sends the user profile to the router. The
user profile might include a per session service policy. If parameter values in the user profile change,
RADIUS sends the changed parameters when the user logs in to the system again.

OL-7433-09
18-5
Chapter 18
Note
The RADIUS server authenticates a user before the server downloads the VSA that is in the user profile.
The RADIUS server does not communicate changes to the Cisco 10000 series router until user
authentication occurs.
The configuration of per session service policy involves the following:
1.
Configure traffic classes and the classification policy.

Configure the classification policy to define how the Cisco 10000 series router differentiates packets
from each other. Create a class map on the Cisco 10000 series router (see the Per Session Rate
Limiting section on page 18-3) using the match command to match and classify packets based on
selected criteria.
2.
Associate class characteristics with each class of traffic.

After you define the classification policy, define the class characteristics to be applied to packets
belonging to a particular class. Create a policy map on the Cisco 10000 series router in which you
associate class characteristics with each class of traffic (see the Per Session Rate Limiting section
on page 18-3).
3.
Download the name of the service policy from the RADIUS server.
You can use a VSA to make the configuration scalable. The service to which the user belongs (the
policy map name) resides on the RADIUS server. The Cisco 10000 series router downloads the
name of the policy map from the RADIUS server using the VSA in the user profile. The
Cisco-Policy-Up VSA 37 is used for upstream traffic coming from a subscriber and the
Cisco-Policy-Down VSA 38 is used for downstream traffic going toward a subscriber. The
PPP/VPDN client processes these VSA attributes.
4.
Attach policies to the interface.
Feature History for Per Session Service Policy Using RADIUS

Cisco IOS Release
Description
Required PRE
Release 12.2(15)BX
The per session service policy using RADIUS feature was PRE2
Release 12.2(28)SB

PRE2
Restrictions and Limitations for per Session Service Policy Using RADIUS
The Cisco 10000 series router routes IP packets for PPPoA, PPPoE, and RBE sessions. Apply input
rate limiting to the packets coming from the client device to the Cisco 10000 series router. Apply
output rate limiting to the packets going to the client device from the Cisco 10000 series router.
You can also apply IP QoS to the PPP tunneled sessions at the L2TP network server (LNS). Apply
input rate limiting to the packets coming out of the L2TP tunnel and output rate limiting to the
packets going into the tunnel.
For PPPoA, PPPoE, PPP in L2TP, and RBE sessions, the Cisco 10000 series router supports the
following QoS features when no atm pxf queuing is enabled or the virtual circuit (VC) is a UBR
VC:
Rate limiting on each session in the input, output, or both input and output directions
18-6
OL-7433-09
Chapter 18

The set qos-group (input only), set ip precedence, and set ip dscp policy map actions
The Cisco 10000 series router does not support the following QoS features when no atm pxf
queuing is enabled or the VC is a UBR VC:
Weighted random early detection (WRED)
Traffic shaping for IP and PPP
For RBE sessions and VAIs that inherit the service policy of the VC, the Cisco 10000 series router
supports the following QoS features when atm pxf queuing is enabled and the VC is a VBR VC:
Rate limiting on each session in the input, output, or in both the input and output directions
The set qos-group (input only), set ip precedence, and set ip dscp policy map actions
Weighted random early detection (WRED)
Traffic shaping
Note
The Cisco 10000 series router has been verified to support a VC count up to 8000 VCs when
atm pxf queuing is enabled. The router supports ATM level QoS, affecting traffic on the ATM
VCs. Both UBR (PCR specified) and VBR (PCR and SCR specified) VCs are available.
The Cisco 10000 series router does not impose any restrictions on the classification definitions you
include in the class map. However, it does limit the input and output policy actions that you can
define in a policy map. These limitations are based on the type of interface on which you apply the
service policy. As indicated in Table 18-2 and Table 18-3, the interface types are:
Normal interface, including VBR VCs on ports configured in pxf queuing mode
Tag interface (MPLS VPN)
Virtual access interface (VAI)
ATM UBR VCs and VCs configured on ports in no atm pxf queuing mode
Input and Output Policy Actions

Table 18-2 lists the input policy actions that you can define in a policy map for specific interface types.

OL-7433-09
18-7
Chapter 18
Table 18-2 Input Policy Map Actions
Note
Interface Type
Policy Map
Actions
Normal
Tag (MPLS VPN)
Virtual Access
ATM UBR VCs
bandwidth
Not Applicable
Not Applicable
Not Applicable
Not Applicable
queue-limit
Not Applicable
Not Applicable
Not Applicable
Not Applicable
priority
Not Applicable
Not Applicable
Not Applicable
Not Applicable
shape
Not Available
Not Available
Not Available
Not Available
random-detect
Not Applicable
Not Applicable
Not Applicable
Not Applicable
set ip prec/dscp
Valid
Not Applicable
Valid
Valid
set qos-group
Valid
Valid
Valid
Valid
set atm-clp
Not Applicable
Not Applicable
Not Applicable
Not Applicable
set cos
Not Applicable
Not Applicable
Not Applicable
Not Applicable
police
Valid
Valid
Valid
Valid
set mpls-exp
Not Available
Not Available
Not Available
Not Available
In Table 18-2 and Table 18-3, Not Applicable indicates that you cannot do the action on a Cisco
product or that it has no meaning in the context indicated. Not Available means the action is not
supported. When configuring an input policy map for a VAI, be careful that you do not include the Not
Applicable or Not Available policy actions indicated. If you do, an error message appears.
Table 18-3 lists the output policy actions that you can define in a policy map for specific interface types.
Table 18-3 Output Policy Map Actions
Interface Type
Policy Map
Actions
Normal
Tag (MPLS VPN)
Virtual Access
ATM UBR VCs
bandwidth
Valid
Valid
Valid
Not Applicable
(Applied to the
VC, not the VAI)
queue-limit
Valid
Valid
Not Available
Not Available
priority
Valid
Valid
Valid
Not Applicable
(Applied to the
VC, not the VAI)
shape
Valid
Valid
Valid
Not Applicable
(Applied to the
VC, not the VAI)
random-detect
Valid
Valid
Not Available
Not Available
18-8
OL-7433-09
Chapter 18

Table 18-3 Output Policy Map Actions
Interface Type
Policy Map
Actions
Normal
Tag (MPLS VPN)
Virtual Access
ATM UBR VCs
set ip prec/dscp
Valid
Not Applicable
Valid
Valid
set qos-group
Not Applicable
Not Applicable
Not Applicable
Not Applicable
set atm-clp
Valid
Not Available
Not Available
Not Available
set cos
Valid
Not Available
Valid
Not Applicable
police
Valid
Valid
Valid
Valid
set mpls-exp
Not Applicable
Not Available
Not Applicable
Not Applicable
Configuring IP Quality of Service for Subscribers

To configure IP QoS for subscribers, perform the following configuration tasks:
Note
Configuring per Session Rate Limiting, page 18-9
Configuring per User Multiservice Rate Limiting, page 18-10
Configuring per Session Service Policy Using RADIUS, page 18-11
If the policing action applies to all traffic through the interface, you can use the predefined class named
class-default. Using one class in the policy map requires less process memory in the Cisco 10000 series
router.
Configuring per Session Rate Limiting

To configure per session rate limiting for PPPoA and PPPoE sessions, enter the following commands
Command
Purpose
Step 1
Router(config)# class-map match [any |

all] class-map-name
Creates a class map with the name you specify and enters
class-map configuration mode.
Step 2
Router(config-cmap)# match parameters

Classifies traffic based on the parameters you specify.
parameters define the classification criteria for the class map.
Step 3
Exits class-map configuration mode.
Step 4
policy-map-name
Creates a policy map with the name you specify and enters
Step 5

map. This is the name of the class map you specified in Step 1.

OL-7433-09
18-9
Chapter 18
Step 6
Command
Purpose
Router(config-pmap)# police parameters
Specifies the actions to be taken.

parameters defines the way in which you want the traffic class to
be policed (see Chapter 6, Policing Traffic).
Step 7
Creates and configures the virtual template interface you specify.

Enters interface configuration mode.
Step 8

Attaches the policy map to the virtual template interface. All VAIs
using the virtual template interface inherit the IP QoS parameters
defined in the policy map.
policy-map-name is the name of the policy map you want to apply
to the virtual template.
Note
Do not apply service policies with Class-Based Weighted Fair Queuing (CBWFQ) actions to a virtual
access interface (VAI) using a virtual template. The Cisco 10000 series router supports queuing only
when you apply the service policy to a VC. For RBE sessions, apply the service policy to the ATM VC
or subinterface.
Configuring per User Multiservice Rate Limiting

To configure per user multiservice rate limiting for PPPoA and PPPoE sessions, enter the following
Command
Purpose
Router(config)# access-list
access-list-number {permit | deny}
protocol [source-address]
[destination-address] port
Creates an access control list (ACL) to filter user traffic.
Step 2
Creates a class map to classify user traffic. Enters class-map

configuration mode.
Step 3
Router(config-cmap)# match access-group

access-list-number
Step 1
Note
Create an ACL for each user behind a multiservice

subscriber.

Defines the classification criteria for the class map. In this case,
the filtering criteria you defined in the ACL is used to classify the
user traffic.
access-list-number identifies the access control list.
Step 4
Exits class-map configuration mode.
Step 5
policy-map-name
Step 6
Specifies the traffic class to which the policy map applies.

map. This is the name of the class map you specified in Step 2.
18-10
OL-7433-09
Chapter 18

Step 7
Command
Purpose
Router(config-pmap)# police parameters
Specifies the actions to be taken on the traffic.

Note
Step 8
Repeat Steps 2 through 6 for each user behind a

multiservice subscriber.
Creates and configures the virtual template you specify. Enters

Step 9

Attaches the policy map to the virtual template. All VAIs using
the virtual template interface inherit the IP QoS parameters
defined in the policy map.
map. In this case, it is the name of the policy map you specified
in Step 5.
Note
series router supports queuing only when you apply the service policy to a VC. For RBE sessions, apply
the service policy to the ATM VC or ATM subinterface.
Configuring per Session Service Policy Using RADIUS

To configure per session service policy, do the following:
Note
Configure the RADIUS server on the router.
Create a class map.
Create a policy map.
Apply the service policy to the RADIUS AAA user profile.
For information on creating a class map and policy map, see the Configuring per Session Rate
Limiting section on page 18-9.
You must configure the RADIUS server on the Cisco 10000 series router. The Configuring RADIUS
chapter in the Cisco IOS Security Configuration Guide, Release 12.2 describes how to set up RADIUS
for authentication, authorization, and accounting (AAA). It includes the following sections that are
relevant to configuring RADIUS on the Cisco 10000 series router:
Configuring the Router to RADIUS Server Communication (Required)
Configuring the Router to Use Vendor-Specific RADIUS Attributes (Required)
Configuring the Router for Vendor-Proprietary RADIUS Server Communication (Optional)
Configuring the Router to Query RADIUS Server for Static Routes and IP Addresses (Optional)
Configuring the Router to Expand Network Access Server Port Information (Optional)
Configuring AAA Server Groups (Optional)
Configuring AAA Server Groups with Deadtime (Optional)

OL-7433-09
18-11
Chapter 18
Configuring AAA Preauthentication
Specifying RADIUS Authentication
Specifying RADIUS Authorization (Optional)
Specifying RADIUS Accounting (Optional)
Configuring RADIUS Login-IP-Host (Optional)
Configuring RADIUS Prompt (Optional)
Configuring Suffix and Password in RADIUS Access Requests (Optional)
Configuration Examples for Subscriber-Based IP QoS

Configuration Example for Per Session Rate Limiting, page 18-12
Configuration Example for Per User Multiservice Rate Limiting, page 18-13
Configuration Example for Per Session Service Policy Using RADIUS, page 18-13
Configuration Example for Per Session Rate Limiting

Example 18-1 creates a class map named voice and a policy map named map1. The voice class map is
used to classify packets. The policing statement defined in the map1 policy map acts on all traffic of the
class voice. The service policy is applied to the virtual template interface (Virtual-Template 1). Output
traffic on all virtual access interfaces (VAIs) cloned from this virtual template interface is rate-limited
to 120,000 bps.
Example 18-1 Configuring Per Session Rate Limiting
Router(config)# policy-map map1
Router(config-pmap)# priority
set-precedence-transmit 4
Router(config-if)# service-policy output map1
Note
Use access control lists (ACLs), protocols, or input interface names to define how to classify traffic.
If the policing action applies to all traffic through the interface, use the predefined class named
class-default. Using one class in the policy map requires less process memory in the Cisco 10000
series router.
The preceding configuration example defines an output policing policy. You can also define an input
policy in a similar way.
18-12
OL-7433-09
Chapter 18

Configuration Example for Per User Multiservice Rate Limiting

Example 18-2 creates two access control lists (ACL 120 and ACL 130) and two class maps (map1 and
map2). Each class map includes a match statement in which the previously configured ACL is used to
classify the traffic through the interface. The map1 class classifies traffic based on the parameters
defined in ACL 130 and the map2 class classifies traffic based on ACL 120.
In the policy map mypolicy, the policing statement defined for each class acts on all traffic that
corresponds to the class. Packets with the destination address 172.16.1.1 are policed at a rate of 8000 bps
and packets with the destination address 172.16.1.2 are policed at a rate of 120,000 bps.
The service policy is applied to the virtual template interface named Virtual-Template 2. Input traffic on
all virtual access interfaces (VAIs) cloned from this virtual template interface is policed.
Example 18-2 Configuring Per User Multiservice Rate Limiting Configuration Example
Router(config)# access-list 120 permit ip any host 172.16.1.1
Router(config)# access-list 130 permit ip any host 172.16.1.2
Router(config)# class-map map1
Router(config)# class-map map2
Router(config-pmap)# class map1
Router(config-pmap)# priority
drop
Router(config-pmap)# class map2
Router(config-if)# service-policy input mypolicy
Router(config-if)# ip unnumbered ethernet 0
Configuration Example for Per Session Service Policy Using RADIUS

To configure per session service policy, perform the following configuration tasks:
Configure the RADIUS server on the Cisco 10000 series router as described in the Configuring
RADIUS chapter in the Cisco IOS Security Configuration Guide, Release 12.2.
Create the class map and policy map as described in the Configuring per Session Rate Limiting
Apply the service policy to the RADIUS AAA user profile.

OL-7433-09
18-13
Chapter 18
In the RADIUS AAA user profile, the lcp:interface-config AV-pair is used to configure class-based
policing or marking. In Example 18-3, the service policy named rad_input_policy is applied to the users
virtual access interface. You create the service policy on the router.
Note
Using the lcp:interface-config AV-pair forces the Cisco 10000 series router to use full access virtual
interfaces, which decreases scaling. We recommend that you do not use this configuration. In
Release 12.2(15)BZ and later releases, you can use a VSA to make the configuration scalable. The router
downloads the name of the policy map to which the user belongs from the RADIUS server using the VSA
in the user profile. The Cisco-Policy-Up VSA 37 is used for upstream traffic coming from a subscriber
(input service policy) and the Cisco-Policy-Down VSA 38 is used for downstream traffic going toward
a subscriber (output service policy). The PPP/VPDN client processes these VSA attributes.
Example 18-3 Sample RADIUS User Profile for Configuring Per Session Service Policy
!Creates the RADIUS user profile.
user1005 Password = user1
Framed-Protocol = PPP
av-pair = ip:addr-pool=pool4,
cisco-av-pair = lcp:interface-config=service-policy input rad_input_policy
........
virtual-profile aaa
!Creates the service policy on the Cisco 10000 series router.
policy-map rad_input_policy
class class-default
priority
police 256000 1500 1500 conform-action transmit exceed-action drop
vpdn enable
.....
interface Virtual-Template 1
........
To use the Cisco-Policy-Up VSA to download the name of the policy from RADIUS and apply the QoS
policy to an interface, configure the following in the user profile on the RADIUS server:
Cisco:Cisco-Policy-Up=rad_input_policy
Example 18-4, Example 18-5, and Example 18-6 are sample configurations for the Merit RADIUS
server and the associated LNS device.
Example 18-4 Merit RADIUS User File
AV Pair Example For Input Service-Policy

av-pair = "lcp:interface-config=service-policy input rad_input_policy",
Framed-Protocol = PPP
18-14
OL-7433-09
Chapter 18

VSA Example For Input and Output Service-Policy

Cisco:Cisco-Policy-Up = rad_input_policy
Cisco:Cisco-Policy-Down = rad_output_policy
Example 18-5 Merit RADIUS Dictionary File

Cisco.attr
Cisco.attr
Cisco-Policy-Up
Cisco-Policy-Down
37
38
string
string
(*, *)
(*, *)
Example 18-6 Associated LNS Configuration
VSA
aaa new-model
!
aaa authorization exec default group radius
aaa authorization configuration default group radius
!
class class-default
priority
!
policy-map rad_output_policy
class class-default
priority
!
AV-Pair
aaa new-model
!
aaa authorization exec default group radius
aaa authorization network default group radius
aaa authorization configuration default group radius
!
class class-default
priority
!
radius-server host 100.1.1.2 auth-port 1645 acct-port 1646 non-standard

OL-7433-09
18-15
Chapter 18
Verifying a Subscriber-Based IP QoS Configuration

To verify a subscriber-based IP QoS configuration, enter any of the following commands in privileged
EXEC mode:
Command
Purpose
Displays all traffic class information.
Router# show class-map class-name
Displays the traffic class information for the user-specified traffic

class.
class-name is the name of the traffic class.
Displays all configured service policies and associated traffic

classes.
Displays the service policy information for the specified policy

map.
Displays configuration information and statistics for the policies

attached to a specific interface.
interface interface is the type and number of the interface.
Router# show policy-map interface interface input
Displays configuration information and statistics for the input

policy attached to a specific interface.
input indicates the inbound service policy.

output
Displays configuration information and statistics for the output

policy attached to a specific interface.
output indicates the outbound service policy.

[input | output] [class class-name]
Displays configuration information and statistics for the class

you specify. This class is included in the policy map attached to
the interface you specify.
input indicates the inbound service policy.
output indicates the outbound service policy.
class class-name is the name of the traffic class previously
configured in a class map.
Router# show caller
Displays information about callers on the PPP termination

aggregation (PTA) device or on the LNS.
Note
The show caller command does not display information

about callers on the LAC.
18-16
OL-7433-09
Chapter 18

Verification Examples for Subscriber-Based IP QoS Configurations

Verification Example for the show policy-map interface Command, page 18-17
Verification Example for the show caller Command, page 18-17
Verification Example for the show policy-map interface Command

Example 18-7 shows sample output from the show policy-map interface command. In the example, the
Gold policy map, attached to ATM interface 3/0/0, contains three traffic classes: Business,
Non-Business, and class-default.
Example 18-7 Displaying Service Policies Using the show policy-map interface Command
ATM3/0/0
Service-policy output: Gold
0 packets, 0 bytes
0 packets, 0 bytes
Match: any
Verification Example for the show caller Command

Example 18-8 shows sample output from the show caller command.
Example 18-8 Displaying Caller Information Using the show caller Command
Router# show caller
Line
con0
vty2
Vi1.1
Vi1.2
Vi1.3
Vi1.4
User
abc@hello1
abc@hello1
abc@hello1
abc@hello1
Service
TTY
VTY
PPPoE
PPPoE
PPPoE
PPPoE
Active Time
00:14:31
00:16:45
00:12:10
00:12:10
00:12:10
00:12:10
Idle Time
00:12:14
00:00:00

OL-7433-09
18-17
Chapter 18

The Modular QoS CLI (MQC) Support for IP Sessions feature extends the routers QoS functionality to
support per-user QoS on IP sessions. Using this feature, you can configure queuing and non-queuing
features on IP sessions, either locally on the router or remotely using a authentication, authorization, and
accounting (AAA) server such as RADIUS. This feature also supports dynamic interface association
(interface redundancy) for IP sessions, L2TP Network Server (LNS) sessions, and L2TP Access
Concentrator (LAC) sessions.
IP sessions provide a way to create subscriber sessions for hosts and subscribers based on an IP source
address or subnet. MQC for IP sessions supports the following session categories:
IP single-host sessionAn IP session that represents a single host. This session is based on an IP
source address.
IP subnet sessionAn IP session that represents a set of end users. This session is based on an IP
subnet.
IP interface sessionA single session that is created for one subscriber interface. The router applies
all MQC features attached to the interface to all traffic arriving and leaving through that interface.
MQC for IP sessions supports policing on an IP session, whether the policing action is configured on
one or more traffic classes of the session or directly on the session. For example, you can configure
shaping on an IP session and configure policing on one or more traffic classes of the IP session. You can
also configure policing statically on an IP session.
MQC for IP sessions supports the dynamic configuration of IP sessions using a RADIUS user or service
profile. The router applies the incoming dynamic policy to the IP session if no policy map exists on the
IP session or the existing policy map is configured from a lower priority source.
Note
The router removes the existing, lower-priority sourced policy map before adding the incoming
dynamic policy.
The router ignores the incoming dynamic policy if a policy map exists on the IP session and it is
configured from a higher priority source.
The following sections describe MQC on IP sessions:
Feature History for MQC Support for IP Sessions, page 18-19
QoS Actions Supported in IP Session Policy Maps, page 18-19
Interface Support for MQC on IP Sessions, page 18-19
Service Policy Maps and Service Profiles, page 18-20
Restrictions and Limitations for MQC Support for IP Sessions, page 18-20
Configuring MQC on IP Sessions, page 18-21
Configuration Examples for MQC on IP Sessions, page 18-23
Verifying Service Policies on IP Sessions, page 18-24
For more information, see the ISG: Flow Control: QoS Control: MQC Support for IP Sessions,
Release 12.2(33)SB feature guide.
18-18
OL-7433-09
Chapter 18

Feature History for MQC Support for IP Sessions

Cisco IOS Release
Description
Required PRE
Release 12.2(33)SB
This feature was introduced on the PRE2, PRE3, and

PRE4.
PRE2, PRE3,
PRE4
QoS Actions Supported in IP Session Policy Maps

Table 18-4 describes the QoS actions supported in inbound and outbound policy maps for IP sessions.
Table 18-4
QoS Actions Supported in IP Session Policy Maps
Policy Map Direction
QoS Actions Supported
Inbound (upstream direction)
Marking
Policing
Outbound (downstream direction)
Queuing
Policing
Marking
Interface Support for MQC on IP Sessions

The router supports the following interfaces for MQC on IP sessions:
Physical Ethernet
IEEE 802.1Q VLAN
QinQ (only unambiguous)
Nonqueuing MQC over ATM
Policies and Queues Inheritance Rules

The following inheritance rules apply to policies and queues from the parent interface:
When a sessions that does not have a policy map starts, it inherits the policy and queues from the
immediate parent that has a policy (for example, a subinterface or main interface).
When a session with an inherited policy receives a policy from the RADIUS server, it first removes
the inherited policy and then applies the policy from the RADIUS server.
When a session without a policy starts and its parent interfaces also do not have a policy, but a policy
is later attached to the parent, one of the following actions occurs:
The policy is attached to the main interface and sessions directly on that interface inherit it.
Sessions on subinterfaces under the main interface that do not have a policy of their own also
inherit it.
The policy is attached to the subinterface and sessions under that subinterface inherit it.

OL-7433-09
18-19
Chapter 18
When you remove a policy from the parent interface, one of the following actions occurs:
The policy is removed from a subinterface and is uninherited from any sessions on the
subinterface that inherited the policy from it. If the main interface has a policy, sessions on the
subinterface from which the policy was removed inherit that.
The policy is removed from the main interface and is uninherited from the main interface and
also from any sessions under its subinterfaces that inherited this policy.
When a session without a policy receives one from the RADIUS server, you only need to install the
new policy. However, when a session with an inherited policy from the parent receives a new policy
from the RADIUS server, you must first uninherit the parent policy and then install the new one.
When a session policy is removed, the session inherits the policy from its nearest parent,
subinterface, or main interface that has a policy.
Service Policy Maps and Service Profiles

An Intelligent Service Gateway (ISG) service is a collection of policies that may be applied to a
subscriber session. Services are defined in service policy maps and service profiles.
Service policy maps and service profiles contain a collection of traffic policies and other functionality.
Traffic policies determine which functionality is applied to which session traffic. A service policy map
or service profile may also contain a network-forwarding policy, a specific type of traffic policy that
determines how session data packets are forwarded to the network.
Service policy maps and service profiles serve the same purpose; the only difference between them is
that a service policy map is defined on the local device using the policy-map type service command,
and a service profile is configured on an external device, such as an authentication, authorization, and
accounting (AAA) server (for example, RADIUS).
Restrictions and Limitations for MQC Support for IP Sessions
Interface redundancy is not supported on the Cisco 10000 series router.
IP session QoS and PPP session QoS are two separate features. IP session QoS does not include PPP
session QoS.
IP sessions over ATM VCs do not support queuing policy maps.
Only the marking and policing features work in upstream traffic. All queuing, policing, and marking
MQC features work in downstream traffic.
The behavior of session and interface oversubscription for the PRE2 and PRE3 is unchanged from
the usual QoS oversubscription behavior on the PRE2 and PRE3.
IP sessions over Gigabit EtherChannel (GEC) is not supported.
The PRE2 does not support three-level hierarchical MQC policies. Therefore, MQC policies applied
to IP sessions on PRE2-based routers must conform to this PRE2 limitation. For example, a shaping
policy that is applied to a session can have just two levels, where one level has all class queues and
the next level is the default queue that does aggregate shaping.
The PRE3 supports three levels of hierarchies. Any limitations of PRE3 hierarchies also apply to the
MQC policies on IP sessions.
The router cannot map IP sessions to an interface. However, the router can map LNS and LAC
sessions to an interface.
18-20
OL-7433-09
Chapter 18

The router does not support QoS on IP sessions over other sessions. For example, consider a
configuration in which a virtual template terminates a PPP session and routes IP traffic, and the
router creates an IP session from the traffic flow. In this case, the router does not support the
configuration because policy maps are attached to the virtual template and applied to the IP session,
too.
The router does not support loadbalancing of IP session traffic.
Currently, the router allows class-level queues only at the top level in session policy maps. All other
levels must have a single-level policy and use the default queues.
The router does not support MQC on IP sessions over the following interfaces:
Bridge-Group Virtual Interface (BVI)
Gigabit EtherChannel (GEC)
PPP sessions (PPPoE and PPPoA)
L2TP sessions on the LNS
Ethernet over MPLS (EoMPLS) termination
MQC on IP sessions does not provide full high availability (HA) functionality. After a switchover
operation, the router recreates the sessions and reapplies the configurations.
Per use ACL is not supported for traffic class on IP sessions on the Cisco 10000 series router.
Configuring MQC on IP Sessions

MQC on IP sessions provides QoS support for local subscriber profiles. To configure the MQC on IP
Sessions feature, perform the following configuration tasks:
Configuring QoS on Service Policy Maps Without Traffic Classes, page 18-21
Configuring QoS on Service Policy Maps With Traffic Classes, page 18-22
Configuring QoS on Service Policy Maps Without Traffic Classes

To configure QoS policy maps on service profiles, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
policy-map-name
Step 2
Specifies the class of traffic to which the policy map applies.

map.

OL-7433-09
18-21
Chapter 18
Step 3
Command
Purpose
Router(config-pmap-c)# police parameters
(Optional) Specifies the policing actions to implement on the

traffic.
be policed. For more information, see the police command in the
command reference documentation for Cisco IOS 12.2 SB.
Note
Configure additional queuing and non-queuing actions as

required. For more information, see the Types of QoS
Step 4
Step 1
Router(config-pmap)# policy-map type

service policy-map-name
Creates or modifies a service policy map, which is used to define

an Intelligent Service Gateway (ISG) subscriber service.
Step 2
Router(config-pmap)# service-policy
policy-map-name is the name of the service policy map.

Attaches the specified policy map to the service profile.
input indicates to apply the policy map to inbound traffic.
output indicates to apply the policy map to outbound traffic.
policy-map-name is the name of the policy map you specified in
Step 1.
Configuring QoS on Service Policy Maps With Traffic Classes

To configure QoS on service policy maps with traffic classes, enter the following commands beginning
Step 1
Command
Purpose
policy-map-name
Step 2
Specifies the class of traffic to which the policy map applies.

map.
Step 3
Router(config-pmap-c)# police parameters
(Optional) Specifies the policing actions to implement on the

traffic.
be policed. For more information, see the police command in the
command reference documentation for Cisco IOS 12.2 SB.
Note
Configure additional queuing and non-queuing actions as

required. For more information, see the Types of QoS
Step 4
Step 5
Router(config-pmap)# policy-map type

service policy-map-name
Creates or modifies a service policy map, which is used to define

an Intelligent Service Gateway (ISG) subscriber service.
policy-map-name is the name of the service policy map.
18-22
OL-7433-09
Chapter 18

Step 6
Command
Purpose
Router(config-pmap)# class type traffic

{class-map-name | default {in-out | input
| output}}
Associates a previously configured traffic class with the policy

map.
map.
default specifies the default traffic class.
in-out specifies the default traffic class for inbound and outbound
traffic.
input specifies the default traffic class for inbound traffic.
output specifies the default traffic class for outbound traffic.
Step 7
Attaches the specified policy map to the service profile.

input indicates to apply the policy map to inbound traffic.
output indicates to apply the policy map to outbound traffic.
policy-map-name is the name of the policy map you specified in
Step 1.
Configuration Examples for MQC on IP Sessions

The following example shows how to configure a service policy map named redirect-profile. This service
policy redirects Gold traffic to the redirect-sg group.
policy-map type service redirect-profile
class type traffic Gold
redirect to group redirect-sg
The following example shows how to configure a service policy named Unauthorized_Redirect_PVC.
This service policy redirects Unauthorized_Traffic to IP address 10.0.0.148 using port 8080.
class-map type traffic Unauthorized_Traffic
match access-group input 100
!
policy-map type service Unauthorized_Redirect_PVC
class type traffic Unauthorized_Traffic
redirect to ip 10.0.0.148 port 8080
The following example shows how to configure a service policy named Service1. This policy has two
traffic classes configured: class1 and the default traffic class. Default traffic is dropped for both inbound
and outbound traffic.
policy-map type service Service1
class type traffic class1
prepaid-config PREPAID
class type traffic default in-out
drop

OL-7433-09
18-23
Chapter 18
Verifying Service Policies on IP Sessions

To verify service policies on IP sessions, enter any of the following commands in privileged EXEC
mode:
Command
Purpose
show class-map type traffic
Displays traffic class maps and their matching criteria.
show policy-map type service
Displays the contents of Intelligent Service Gateway (ISG)

service policy maps and service profiles and session-related
attributes.

The Per Session Shaping and Queuing on LNS feature provides the ability to shape (for example, transmit
or drop) or queue (for transmission later) the traffic from an Internet service provider (ISP) to an ISP
subscriber over a Layer 2 Tunneling Protocol (L2TP) Network Server (LNS). The outgoing traffic is shaped
or queued on a per-session basis.
Shaping and queueing traffic on a per-session basis:
Helps to avoid traffic congestion and allows the ISP to adhere to the Service Level Agreement (SLA)
established for managing traffic.
Provides a high degree of granularity for managing traffic on the network. Figure 18-1 is a sample
topology for per-session shaping and queuing on an LNS.
Figure 18-1
Per-Session Shaping and Queuing TopologyPPP Sessions Forwarded
Downstream traffic
ISP
Subscriber
LAC
L2TP tunnel
PPP session
127500
LNS
In this simplified topology example:

1.
Downstream traffic is forwarded from the ISP (the source) to an ISP subscriber (the destination)
during a PPP session.
2.
From an LNS at the ISP, the traffic is transmitted over an L2TP tunnel to an L2TP Access
Concentrator (LAC) and then to the subscriber.
3.
Shaping and queuing the per-session traffic on an LNS can take into account the overhead between
the LNS, LAC, or E-DSLAM-to-CPE by using the user-defined overhead in the shape or bandwidth
command.
4.
To specify the overhead offset in child and parent policies, use the bandwidth and shape
commands. The offset values and encapsulation types must match in the child and parent policies.
18-24
OL-7433-09
Chapter 18

Feature History for Per Session Shaping and Queuing on LNS

Cisco IOS Release
Description
Required PRE
Release 12.2(31)SB6
The Per Session Shaping and Queuing on LNS feature was PRE3
Prerequisites for Per Session Shaping and Queuing on LNS
Verify that the PPPoE (or PPPoA) sessions are enabled.
Verify that L2TP resequencing is disabled.
This feature uses policy maps in which queuing mechanisms (such as class-based weighted fair
queuing [CBWFQ]) are configured.
Cisco IOS Release 12.2(31)SB8 does not support load balancing when per session shaping and
queuing is configured. However, this release does support load balancing if no output QoS is applied
to the session. Cisco IOS Release 12.2(31)SB6 does not support load balancing at all on the LNS.
Cisco IOS Release 12.2(31)SB10 supports load balancing for all QoS configurations, except those
containing a queuing action that is applied to a session. For example, the router does not support
load balancing for a session if the policy map applied to the session contains the shape, bandwidth,
or priority command.
This feature does not support L2TP sequencing.
This feature only applies when the LAC and LNS are connected by Ethernet and ATM point-to-point
subinterfaces.
Configuring Per Session Shaping and Queuing on LNS

To configure per session shaping and queuing on an LNS policy, enter the following commands
Step 1
Command
Purpose
policy-map-name

Step 2

OL-7433-09
18-25
Chapter 18
Step 3
Command
Purpose
{subscriber-encap}} | {user-defined
offset [atm]}}

link bandwidth.
information, see the ATM Overhead Accounting section on
page 10-2.
Accounting and Hierarchical Policies section on page 10-6.
Step 3
(cont.)
offset [atm]}}

Note

the offset option.

Note

Step 4
Step 5
policy-map-name

Step 6

Note

18-26
OL-7433-09
Chapter 18

Step 7
Command
Purpose

offset [atm]}}
accounting.
per second.
information, see the ATM Overhead Accounting section on
page 10-2.
Accounting and Hierarchical Policies section on page 10-6.
Step 7
(cont.)

offset [atm]}}

Note


Note
Step 8
policy-map-name


policy map.
Step 9
Step 10
(Optional) Creates a virtual template interface and enters

Step 11
Router(config-if)# service-policy
policy-map-name

(Optional) Attaches the parent policy to the virtual template
interface.
policy-map-name is the name of the previously configured parent
policy map.

OL-7433-09
18-27
Chapter 18
Configuration Example for Configuring a Per Session Shaping and Queuing on LNS Policy
Example 18-9 shows how to configure a per session shaping and queuing on LNS policy. In this example,
the router uses 20 overhead bytes and ATM cell tax in calculating ATM overhead. The child and parent
policies contain the required matching offset values. The parent policy is attached to virtual template 1.
Example 18-9 Configuring Per Session Shaping and Queuing on LNS Policy on the Router
policy-map child
class class1
bandwidth 500 account user-defined 20 atm
class class2
policy-map parent
class class-default
interface virtual-template 1
service-policy output parent
Verifying Per Session Shaping and Queuing on LNS Policies

To display the configuration of per session shaping and queuing on LNS policies, enter the following
Command
Purpose
Router# show policy-map [policy-map]
Displays the configuration of all classes for a specified service

policy map or all classes for all existing policy maps.
policy-map specifies the name of the policy map.

shows the configuration of the policy maps.
Verification Examples for Per Session Shaping and Queuing on LNS Policies
Example 18-10 shows sample output for the show policy-map command. In the example, the router uses
20 overhead bytes in calculating ATM overhead.
Example 18-10 Sample Outputshow policy-map Command
Policy Map child
Class Class1
cir 20% account user-defined 20
Example 18-11 shows sample output for the show running-config command. In the example, the output
modifier starts the display at the Parent policy map line.
Example 18-11 Sample Outputshow running-config Command
Router# show running-config | begin Parent
Policy Map Parent
class class1
18-28
OL-7433-09
Chapter 18


policy-map child
class class2
!

PPP Session Queuing on ATM Virtual Circuits (VCs) enables you to shape and queue PPP over ATM
(PPPoA) and PPP over Ethernet over ATM (PPPoEoA) sessions to a user specified rate. Multiple
sessions can exist on any ATM VC and have QoS policies applied, or some of the sessions might have
QoS policies while others do not. The router shapes the sum of all PPPoA or PPPoEoA traffic on a VC
so that the subscribers connection to the DSLAM does not become congested. Queuing-related
functionality provides different levels of service to the various applications that execute over the PPPoA
or PPPoEoA session.
A nested, 2-level hierarchical service policy is used to configure session shaping directly on the router
using the modular quality of service command-line interface (MQC). The hierarchical policy consists of
the following:
Child policyDefines QoS actions using QoS commands such as the priority, bandwidth, and
police commands.
Parent policyContains only the class-default class with the shape or bandwidth remaining ratio
command configured, or with both commands configured:
shape commandShapes the session traffic to the specified bit rate, according to a specific
algorithm.
bandwidth remaining ratio commandSpecifies a ratio value that the router uses to
determine how much unused bandwidth to allocate to the session during congestion.
For more information about nested hierarchical policies, see the Nested Hierarchical Policies section
on page 13-6.
Note
The PPP Session Queuing on ATM VCs feature applies to both PPP terminated aggregation (PTA) and
L2TP access concentrator (LAC) configurations.

OL-7433-09
18-29
Chapter 18
Figure 18-2 illustrates PPP session queuing on ATM VCs.

Figure 18-2
PPPoE Session
Interface with shaper
Voice
ATM VC
Session #1
with QoS
Video
Interface without shaper
pppoe-Session
Data-premium
HW Interface
Class-default
Session #2
without QoS
191919
pppoe-Session
Another VC on same interface
More sessions with

or without QoS
Feature History for PPP Session Queuing on ATM VCs

Cisco IOS Release
Description
Required PRE
Release 12.2(31)SB6
The PPP Session Queuing on ATM VCs feature was

introduced on the Cisco 10000 series router and
implemented on the PRE3.
PRE3
Dynamically Applying QoS Policies to PPP Sessions on ATM VCs

The router allows you to dynamically apply QoS policy maps to PPPoA and PPPoEoA sessions using
RADIUS. Although the actual configuration of the QoS policies occurs on the router, you can configure
the following attribute-value (AV) pairs on RADIUS to specify the name of the policy map to
dynamically apply to the session:
You define the AV-pairs in one of the following RADIUS profiles:
18-30
OL-7433-09
Chapter 18

authorization succeeds, the router downloads the name of the policy map from RADIUS using the
ip:sub-qos-policy-in[out]= AV-pair and applies the QoS policy to the PPPoA or PPPoEoA
session. Because the service policy contains queuing-related actions, the router sets up the appropriate
class queues.
Note
and Cisco-Policy-Up, we recommend that you use the ip:sub-qos-policy-in[out]= AV-pairs for QoS
policy definitions.
PPP Session Queuing Inheritance

Sessions either inherit queues from their parent interface or they have their own queues. Each PPPoA or
PPPoEoA session for which session queuing is configured has its own set of queues.
Table 18-5 describes the queues to which the router directs session traffic.
Table 18-5
Queue Inheritance
Queuing Policy
Queue Used for Session Traffic
No policy
VC default queue
Applied to the VC
VC queues
Applied to the session
Session queues
Interfaces Supporting PPP Session Queuing

The router supports PPP session queuing on shaped ATM virtual circuits (VCs) for outbound traffic only.
The router does not support PPP session queuing on inbound ATM interfaces.
Mixed Configurations and Queuing

A mixed configuration is one in which all sessions do not have QoS applied to them. On some VCs, the
queuing policy is applied at the VC level, while on other VCs the queuing policies are applied on the
sessions. Some sessions have no policy applied at all. As a result, the router uses the hierarchical queuing
framework (HQF) to direct traffic in the following ways:
If no queuing policy is applied at the VC or session level, the router sends all traffic on the VC to
the default queue, including traffic from sessions on the VC that have a policing-only policy applied
or no policy applied.
If a queuing policy is applied at the VC level, but not at the session level, the router sends traffic to
the queues associated with the queuing policy on the VC.
If queuing policies are applied to some sessions on a VC but not to other sessions, the router sends
the traffic with a policing-only policy or with no policy applied to the VCs default queue. The router
sends traffic with queuing policies to the queues associated with the queuing policy applied to the
session.

OL-7433-09
18-31
Chapter 18
Bandwidth Sharing and ATM Port Oversubscription

An ATM port can operate in reserved bandwidth mode or shared bandwidth mode.
When a port is not oversubscribed (the sum of the bandwidths of all VCs on the port is less than the port
bandwidth), the port operates in reserved bandwidth modea specific amount of bandwidth is reserved
for each VC on the port. If a VC does not use all of its allocated bandwidth, the unused bandwidth is not
shared among the VCs on the port.
When the ATM port is oversubscribed (the sum of the bandwidths of all VCs on the port is greater than
the port bandwidth), the port operates in shared bandwidth mode. In this mode, any unused bandwidth
is available for re-use by the other VCs on the port, up to the VCs respective shape ratetraffic on a
VC cannot exceed the shape rate of that VC.
Oversubscription at the Session Level

Oversubscription at the session level occurs after session traffic shaping and when the aggregate session
traffic exceeds the subinterface shape rate. After all priority traffic is accounted, the router distributes
the remaining bandwidth on the VC to the sessions according to the value specified in the bandwidth
remaining ratio command configured in the parent policy of the policy applied to the sessions. If the
bandwidth remaining ratio command is not specified in the parent policy, the router uses a default ratio
of 1.
Prerequisites for PPP Session Queuing on ATM VCs
PPPoA or PPPoEoA sessions must be enabled.
Create traffic classes using the class-map command and specify the match criteria used to classify
traffic.
For dynamic PPPoA or PPPoEoA session queuing using RADIUS, you must:
Enable authentication, authorization, and accounting (AAA) on the router
Configure the RADIUS server for dynamic QoS
Create the subscribers user profile on the RADIUS server
Restrictions and Limitations for PPP Session Queuing on ATM VCs
You cannot configure PPP session queuing on unshaped VCsVCs without a specified peak cell
rate (PCR) or sustained cell rate (SCR).
Although you can configure oversubscription at the VC level, the router does not guarantee priority
queuing (PQ) and fair treatment among VCs during congestion.
VCs with session queuing polices cannot be part of a shaped virtual path (VP).
PPP session queuing does not allow you to simultaneously configure queuing policies on a VC and
on a session of that VC, although the router permits the configuration.
The maximum number of VCs with PPP session queuing policies cannot exceed 16,000 VCs system
wide.
18-32
OL-7433-09
Chapter 18

If the same ATM category (for example, shaped unspecified bit rate (UBR)) contains both high and
low bandwidth VCs, the SAR mechanism can cause low throughput for high bandwidth VCs. The
workaround for this issue is to use different ATM classes for low and high bandwidth VCs. For
example, configure low bandwidth VCs as shaped UBR and high bandwidth VCs as variable bit
rate-nonreal-time (VBR-nrt) or constant bit rate (CBR).
When you apply queuing policies to sessions, do not apply a policy at the VC level on the same VC.
The CLASS-BASED QOS MIB does not include statistics for service policies applied to sessions.
RADIUS accounting does not include queuing statistics.
The router ignores the VC weight when it is configured on a VC with PPP session queuing
configured.
Configuring PPP Session Queuing on ATM VCs

You can apply hierarchical shaping policies to sessions using a virtual template or RADIUS. When you
apply shaping policies to sessions, do not apply a policy at the VC level on the same VC.
To configure PPP session queuing on ATM VCs, perform one of the following configuration tasks:
Configuring PPP Session Queuing Using a Virtual Template, page 18-33
Configuring PPP Session Queuing Using RADIUS, page 18-38
Configuring PPP Session Queuing Using a Virtual Template

To configure PPPoA or PPPoEoA session queuing using a virtual template, perform the following
Configuring an Hierarchical QoS Policy, page 18-33
Associating the Hierarchical Policy Map with a Virtual Template, page 18-36
Applying the Virtual Template to an ATM Subinterface, page 18-36
Configuring an Hierarchical QoS Policy

To configure a hierarchical QoS policy, enter the following commands, beginning in global configuration
mode:
Step 1
Command
Purpose
policy-map-name

configuration mode.

OL-7433-09
18-33
Chapter 18
Step 2
Command
Purpose
Note
Step 3
Router(config-pmap-c)# priority level

level
Repeat Steps 2 through 6 for each traffic class you want

to include in the child policy map. For information about
other QoS actions you can specify for the traffic classes,
see the Input and Output Policy Actions section in the
Configuring QoS Policy Actions and Rules chapter of
the Cisco 10000 Series Router Quality of Service
(Optional) Defines multiple levels of a strict priority service

model. When you enable a traffic class with a specific level of
priority service, the implication is a single priority queue
associated with all traffic enabled with the specified level of
priority service.
level is a number that indicates a specific priority level. Valid
values are from 1 (high priority) to 4 (low priority). Default: 1
Step 4
Router(config-pmap-c)# police bps

[burst-normal] [burst-max] [conform-action
(Optional) Configures traffic policing.

bps is the average rate in bits per second. Valid values are 8000 to
200000000.
(Optional) burst-normal is the normal burst size in bytes. Valid
values are 1000 to 51200000. The default normal burst size is
1500 bytes.
(Optional) burst-max is the excess burst size in bytes. Valid values
are 1000 to 51200000.
(Optional) conform-action action indicates the action to take on
packets that conform to the rate limit.
(Optional) exceed-action action indicates the action to take on
packets that exceed the rate limit.
(Optional) violate-action action indicates the action to take on
packets that violate the normal and maximum burst sizes.
Step 5
Router(config-pmap-c)# set cos value
(Optional) Sets the Layer 2 class of service (CoS) value of an

outgoing packet.
value is a specific IEEE 802.1Q CoS value from 0 to 7.
Step 6
remaining ratio

from 1 to 1000.
Step 7
18-34
OL-7433-09
Chapter 18

Step 8
Command
Purpose
policy-map-name

Step 9

Note
Step 10
remaining ratio


from 1 to 1000.
Step 11

mean-rate [burst-size]
[excess-burst-size]
accounting.
(Optional) average is the committed burst (Bc) that specifies the
maximum number of bits sent out in each interval. This option is
only supported on the PRE3.
mean-rate is also called committed information rate (CIR).
Indicates the bit rate used to shape the traffic, in bits per second.
When this command is used with backward explicit congestion
notification (BECN) approximation, the bit rate is the upper
bound of the range of bit rates that are permitted.
(Optional) burst-size is the number of bits in a measurement
interval (Bc).
(Optional) excess-burst-size is the acceptable number of bits
permitted to go over the Be.
Step 12
policy-map-name

policy-map-name is the name of the child policy map configured
in step 1.
The following example shows how to configure a hierarchical QoS policy. In the example, the
child-policy configures QoS features for two traffic classes: Premium and Silver. Premium traffic has
priority and is policed at 40 percent. The router sets the IP precedence of Premium traffic to precedence
level 3. Silver traffic is policed at 80000 bps and IP precedence level 3 is set. The child-policy is applied
to the Parent policy class-default class, which shapes traffic to 200,000 Kbps.
Router(config)# policy-map child-policy
Router(config-pmap-c)# police 80000 10000 conform-action transmit exceed-action drop

OL-7433-09
18-35
Chapter 18
Router(config-pmap-c)# service-policy output child-policy

Router(config)#
Associating the Hierarchical Policy Map with a Virtual Template

A virtual template is a logical interface whose configuration can specify generic configuration
information for a specific purpose, user-specific configuration information, and router-dependent
information. You configure a virtual template on an interface and apply QoS policy maps to the virtual
template. The virtual template inherits the QoS features specified in the policy map. When the router
establishes sessions on an interface, the router applies the QoS features specified in the virtual template
configuration to the virtual access interfaces (VAIs) created for the sessions, including the QoS features
specified in the policy map attached to the virtual template.
To associate the hierarchical policy map with a virtual template, enter the following commands
Step 1
Command
Purpose
virtual-template template-number

mode.
template-number is the number you assign to the virtual template
interface to identify it. Valid values are from 1 to 200.
Note
Step 2

You can configure up to 200 virtual template interfaces on

the router.

interface in the inbound or outbound direction that you specify.
output specifies to apply the policy map to outbound traffic.
map.
Step 3
The following example shows how to associate a policy map with a virtual template. In this example, the
policy map named Parent is associated with the virtual template named VirtualTemplate1.
Router(config-if)# service-policy output Parent
Router(config)#
Applying the Virtual Template to an ATM Subinterface

A broadband aggregation group (bba-group) configured on an ATM interface points to the virtual
template the router uses to apply QoS policies to sessions. When a session arrives on an ATM interface,
the router creates a virtual access interface (VAI) for the session and applies the policies associated with
the virtual template to the sessions.
To apply the virtual template with its associated hierarchical policy to an ATM subinterface, enter the
18-36
OL-7433-09
Chapter 18

Step 1
Command
Purpose
Router(config)# bba-group pppoe

group-name
Creates a PPP over Ethernet (PPPoE) profile. Enters BBA group

configuration mode.
Step 2
template-number
Associates a BBA group to the virtual template to be used for

cloning virtual access interfaces.
template.
Step 3
Step 4


configuration mode.
number is the slot, module, and port number of the interface (for
example 1/0/0).
.subinterface is the number of the subinterface (for example,
1/0/0.1).
(Optional) point-to-point indicates that the subinterface connects
directly with another subinterface.
Step 5
Creates or modifies an ATM permanent virtual circuit (PVC).

Enters ATM virtual circuit configuration mode.
characters.
vpi/ specifies the ATM network virtual path identifier (VPI) for
this PVC. You must specify the slash. Valid values are from 0 to
255. The router treats a value that is outside the range of valid
values as the connection ID. The default value is 0.
Note
The arguments vpi and vci cannot both be set to 0; if one

is 0, the other cannot be 0.
vci specifies the ATM network virtual channel identifier (VCI) for
this PVC. Valid values are from 0 to 1 less than the maximum
value set for this interface by the atm vc-per-vp command. A
value that is out of range causes an "unrecognized command"
error message.
Note
The VCI value has local significance only and, therefore,

is unique only on a single link, not throughout the ATM
network. Typically, lower values from 0 to 31 are reserved
for specific traffic (for example, F4 OAM, SVC signaling,
ILMI, and so on) and should not be used.

OL-7433-09
18-37
Chapter 18
Step 6
Command
Purpose
Router(config-atm-vc)# protocol pppoe

group group-name
Enables PPP over Ethernet (PPPoE) sessions to be established on

group specifies a PPPoE profile (bba-group) to be used by PPPoE
sessions on the interface.
group-name is the name of the PPPoE profile (bba-group) to be
used by PPPoE sessions on the interface.
Note
The group group-name points to the bba-group to be used

for applying a virtual template interface with QoS policies
to sessions.
Step 7
Step 8
The following example shows how to associate a virtual template interface with an ATM interface and
apply the policies in the virtual template to the sessions on the interface. In the example, the service
policy named Parent is applied to the Virtual-Template 8, which is associated with the bba-group named
pppoeoa-group. The bba-group is applied to PVC 101/210 on ATM subinterface 4/0/1.10.
Virtual-Template 8
pvc 101/210
vbr-nrt 4000 2000 50
no dbs enable
!
Configuring PPP Session Queuing Using RADIUS

To configure PPPoA or PPPoEoA session queuing using RADIUS, perform the following configuration
tasks:
Configuring the Policy Map, page 18-38
Adding the Cisco QoS AV Pairs to the RADIUS Profile, page 18-39
Configuring the Policy Map

The router allows you to use RADIUS to apply QoS policy maps to PPPoA or PPPoEoA sessions. The
actual configuration of the policy map, however, occurs on the router using the modular QoS CLI
(MQC).
To configure QoS policy maps and apply them to virtual template interfaces, see the Configuring an
Hierarchical QoS Policy section on page 18-33 and the Associating the Hierarchical Policy Map with
a Virtual Template section on page 18-36.
18-38
OL-7433-09
Chapter 18

Adding the Cisco QoS AV Pairs to the RADIUS Profile

Cisco attribute-value (AV) pairs are vendor-specific attributes (VSAs) that allow vendors such as Cisco
to support their own extended attributes. RADIUS attribute 26 is a Cisco VSA used to communicate
vendor-specific information between the router and the RADIUS server.
The RADIUS user profile contains an entry for each user that the RADIUS server authenticates. Each
entry establishes an attribute the user can access. When configuring PPPoA or PPPoEoA session queuing
using RADIUS, enter the following Cisco AV-pair in the appropriate user profile:
Cisco-AVPair = "ip:sub-qos-policy-out=<name of egress policy>"
The Cisco AV-pair identifies the policy map the router is to use when applying QoS features to a PPPoA
or PPPoEoA session. After receiving a service-logon request from the policy server, RADIUS sends a
change of authorization (CoA) request to the router to activate the service for the user, who is already
logged in. If the authorization succeeds, the router downloads the name of the policy map from RADIUS
using the Cisco AV-pair and applies the QoS policy to the session.
Note
and Cisco-Policy-Up, we recommend that you use the above attribute for QoS policy definitions.
Configuration Examples for PPP Session Queuing on ATM VCs

Example of Configuring PPP Session Queuing on ATM VCs, page 18-39
Example of Configuring and Applying an Hierarchical Policy Map, page 18-40
Example of Setting Up RADIUS for PPP Session Queuing on ATM VCs, page 18-41
Example of Configuring PPP Session Queuing on ATM VCs

The following example shows how to configure PPPoA or PPPoEoA session queuing. In the example, a
hierarchical QoS policy named pm_hier2_0_2 is associated with Virtual-Template555, which is applied
to the broadband aggregation group named pppoeoa-group.
Example 18-12 Configuring PPP Session Queuing on ATM VCs
Virtual-Template 555
!
policy-map pm_hier2_child_0_2
class cm_0
priority level 1
violate-action drop
queue-limit 77 packets
class cm_1
class class-default
policy-map pm_hier2_0_2

OL-7433-09
18-39
Chapter 18
class class-default
service-policy pm_hier_child_0_2
pvc 1/5555
vbr-nrt 4000 2000 50
no dbs enable
!
!
service-policy output pm_hier2_0_2
Example of Configuring and Applying an Hierarchical Policy Map

Example 18-13 shows how to configure a hierarchical policy and apply it to a virtual template. The
example contains a child policy map named child1 with QoS features defined for the gold and bronze
traffic classes. The child1 policy is applied to the parent policy map, which is shaped to 512000 bps. The
hierarchical policy is applied to the virtual template named virtual-template 1.
Example 18-13 Configuring an Hierarchical Policy Map
Router(config)# policy-map child1
Router(config-pmap-c)# class bronze
Router(config-pmap)# policy-map parent
Router(config-pmap-c)# service-policy child1
Router(config)# interface virtual-template 1
Router(config-if)# service-policy output parent
18-40
OL-7433-09
Chapter 18

Example of Setting Up RADIUS for PPP Session Queuing on ATM VCs

Example 18-14 shows how to define the Cisco AV-pairs used to download the policy map name to the
router. The first three lines of a subscribers sample user profile contain the user password, service type,
and protocol type. This information is entered into the subscribers user profile when the user profile is
first created. The last line is an example of the Cisco QoS AV-pair added to the user profile. The policy
map name downloaded to the router is p23.
Example 18-14 Setting Up RADIUS for PPP Session Queuing on ATM VCs
useridPassword = "cisco"
cisco-avpair = "sub-qos-policy-out=p23"
Verifying PPP Session Queuing on ATM VCs

To verify PPPoA or PPPoEoA session queuing, use any of the following commands in privileged EXEC
mode:
Command
Purpose

the router.
atm 4/0/0).


from 1 to 65535.
session.
session.

OL-7433-09
18-41
Chapter 18
Command
Purpose
Router# show pxf cpu queue [interface | QID |

summary]
Displays parallel express forwarding (PXF) queuing statistics.

(Optional) interface is the interface for which you want to display
PXF queuing statistics. This displays PXF queuing statistics for
the main interface and all subinterfaces and permanent virtual
circuits (PVCs). It also displays packets intentionally dropped due
to queue lengths.
(Optional) QID is the queue identifier.
(Optional) summary displays queue scaling information such as:
Number of queues and recycled queues.
Number of available queue IDs (QIDs).

packet buffers.
Note
Router# show pxf cpu queue session [sid

sid-value]
In Cisco IOS Release 12.2(33)SB and later releases, the

output from the show pxf cpu queue interface summary
command displays only the physical interface and the
number of logical links. The output does not display the
number of priority queues, class queues, and so on. This
modification applies to the PRE3 and PRE4.
Displays PXF queuing statistics for sessions.

(Optional) sid displays queuing statistics for a specific session
identifier.
sid-value is a number that represents a specific session ID. Valid
Verification Examples for PPP Session Queuing on ATM VCs

Example 18-15 shows the type of information displayed when you enter the show pxf cpu queue session
command. In the example, the show pppoe session command is used to display the sessions established
on the router. In this case, one session is active with a session ID (SID) of 6. The example then displays
configuration and statistical information for that specific session using the show pxf cpu queue session
command.
Example 18-15 Displaying PPP Session Informationshow pxf cpu queue session Command
1 session total
Uniq ID
14
PPPoE
SID
6
RemMAC
LocMAC
0009.b68d.bb37
0009.b68d.bc37
Port
VA-st
ATM2/0/7.5555
VC: 1/5555
VT
VA
555
Vi3.1
State
Type
PTA
UP
18-42
OL-7433-09
Chapter 18

Router#
Router#
Router# show pxf cpu queue session sid 6
ATM2/0/7.5555: PVC 1/5555
VCCI/ClassID ClassName
2623/0
class-default
2623/1
cm_0
2623/2
cm_1
2623/31
net-control
QID
1858
1856
1859
591
Length/Avg
0/0
0/0
0/0
0/1
Max Dequeues
77
0
77
0
40
0
1105
335137
Drops(Tail/Random)
0/0
0/0
0/0
0/0
Legend:
$x: Priority Queue level x
b: PQ Activation and Dequeue Blocked
~: RED Queue
P: MLP Pkt Queue
F: MFR Pkt Queue
M1:MLP , M5:MLPFR , MA:MLPOA , M6:FRF12 , M7:MLFR, M8:FRF12_16
Example 18-16 uses the show policy-map session command to display QoS policy map statistics for
traffic in the downstream direction. The example also shows the policy map configurations.
Example 18-16 Displaying PPP Session Informationshow policy-map session Command
1 session total
Uniq ID
14
PPPoE
SID
6
RemMAC
Port
LocMAC
VA-st
0009.b68d.bb37
ATM2/0/7.5555
0009.b68d.bc37 VC: 1/5555
VT
VA
555
Vi3.1
State
Type
PTA
UP
Router#
Router#
SSS session identifier 14 Service-policy output: pm_hier2_0_2
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
Queueing
Service-policy : pm_hier2_child_0_2
Queueing
priority level 1

OL-7433-09
18-43
Chapter 18

0 packets, 0 bytes
0 packets, 0 bytes
Priority: 0% (0 kbps), burst bytes 4470, b/w exceed drops: 0
Priority Level: 1
Police:
0 packets, 0 bytes
0 packets, 0 bytes
Queueing
0 packets, 0 bytes
Match: any
0 packets, 0 bytes
Queueing
Router# show policy-map pm_hier2_0_2
Policy Map pm_hier2_0_2
Class class-default
cir 100%
service-policy pm_hier2_child_0_2
Router# show policy-map pm_hier2_child_0_2
Policy Map pm_hier2_child_0_2
Class cm_0
priority level
police percent
violate-action
queue-limit 77
1
5 2 ms 0 ms conform-action transmit exceed-action drop
drop
packets
Class cm_1
18-44
OL-7433-09
Chapter 18


cir 80%
Class class-default
cir 50%

The Per-Session Shaping for ATM Interfaces feature enables the router to shape session traffic on L2TP
network server (LNS) outbound ATM interfaces. Using this feature, you can apply a hierarchical QoS
policy to an ATM interface and manage the traffic belonging to a session. The shaping feature configured
in the parent policy map shapes the classes of traffic that comprise the session traffic and the queuing
features configured in the child policies enables the router to queue the session packets, rather than drop
them.
When policing is configured to manage session traffic, the policer might drop traffic that is within a
reasonable rate (for example, traffic bursts), which can affect the quality of end applications such as TCP
applications. Instead, queuing packets enables you to avoid packet drops.
When a QoS policy with shaping is attached to an outbound ATM interface, the shaper applied to the
ATM VC shapes the downstream traffic as it passes over the VC. Shaping enables you to apply QoS
services to the classes of session traffic. For example, one class of a session might require low latency
while another session class might require a guaranteed bandwidth.
Per-session shaping on ATM interfaces supports the following functionality:
Hierarchical schedulingThe hierarchical queuing framework (HQF) defines a QoS architecture

for implementing hierarchical packet scheduling and queuing on the PRE3 and PRE4. The HQF
enables service providers to manage their QoS at three layers of hierarchy:
Physical layerUsed for shaping the physical interface such as the OC-3 port.
Logical layerUsed to schedule subinterfaces such as a VLAN or PPP sessions.
Class layerUsed for class queues, defined using the modular QoS command line interface
(MQC) policy map.

The parallel express forwarding (PXF) engine performs all packet-level scheduling using the HQF.
For more information, see Chapter 22, Hierarchical Scheduling and Queuing.
Interface oversubscriptionInterface oversubscription enables service providers to assign a total

committed information rate (CIR) to a given port that is greater than the speed of the port. In this
way, the router can statistically guarantee bandwidth to the VCs, thus improving network utilization.
For more information, see Chapter 15, Oversubscribing Physical and Virtual Links.
Scalability up to 61,500 sessions

OL-7433-09
18-45
Chapter 18
Feature History for Per-Session Shaping for ATM Interfaces

Cisco IOS Release
Description
Required PRE
Release 12.2(33)SB
The Per-Session Shaping for ATM Interfaces feature was PRE3

introduced on Cisco 10000 series router and implemented PRE4
on the PRE3 and PRE4.
Restrictions and Limitations for Per-Session Shaping for ATM Interfaces
If you configure child classes with a guaranteed bandwidth, do not oversubscribe the sessions. If you
do oversubscribe the sessions and the hierarchical policy shapes session traffic, any bandwidth
guarantees configured for the child policies might not be guaranteed. Oversubscription occurs when
the aggregate configured shape rate for all active sessions exceeds the bandwidth of the physical link
through which the session traffic passes when leaving the router.
Per-session shaping for ATM interfaces does not support load-balancing on an L2TP tunnel (for
example, on the LNS). Therefore, if you enable per-session shaping in a service policy, do not
configure load-balancing on the tunnel.
This feature does not support overhead accounting.
Configuring Per-Session Shaping for ATM Interfaces

To configure per-session shaping for ATM interfaces, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
Creates or modifies a child policy. Enters policy-map

configuration mode.
Step 2

class map.
Step 3
Enables class-based fair queuing and overhead accounting.

percentage specifies or modifies the maximum percentage
of the link bandwidth allocated for a class belonging to a
policy map. Valid values are from 1 to 99.
remaining percentage specifies or modifies the minimum
18-46
OL-7433-09
Chapter 18

Step 4
Command
Purpose
Router(config-pmap-c)# class class-map-name

class map.
Step 5
Shapes session traffic to the indicated bit rate.

second.
Step 6
Step 7
Router(config-pmap)# policy-map policy-map-name

policy-map-name is the name of the parent policy map. The
Step 8
Step 9
Shapes traffic to the indicated bit rate and enables overhead

accounting.
second. When this command is used with backward explicit
congestion notification (BECN) approximation, the bit rate
is the upper bound of the range of bit rates that are
permitted.
Step 10
policy-map-name
Applies a child policy to the parent class-default class.

child policy map. In this case, the child policy is the policy
map you configured in step 1.
Note
Do not specify the input or output keywords when

applying a child policy to a parent class-default
class.
Step 11
Step 12
Step 13

template-number

mode.
template-number is the number you assign to the virtual
template interface to identify it. Valid values are from 1 to
200.
Note
You can configure up to 200 virtual template

interfaces on the router.

OL-7433-09
18-47
Chapter 18
Step 14
Command
Purpose


interface in the inbound or outbound direction that you
specify.
output specifies to apply the policy map to outbound
traffic.
policy map.
Step 15
Step 16
Router(config)# bba-group pppoe group-name
Creates a PPP over Ethernet (PPPoE) profile. Enters BBA

group configuration mode.
Step 17
template-number
Associates a BBA group to the virtual template to be used

for cloning virtual access interfaces.
template.
Step 18
Step 19


configuration mode.
number is the slot, module, and port number of the interface
(for example 1/0/0).
.subinterface is the number of the subinterface (for
example, 1/0/0.1).
(Optional) point-to-point indicates that the subinterface
connects directly with another subinterface.
18-48
OL-7433-09
Chapter 18

Step 20
Command
Purpose
Creates or modifies an ATM permanent virtual circuit

(PVC). Enters ATM virtual circuit configuration mode.
characters.
vpi/ specifies the ATM network virtual path identifier (VPI)
for this PVC. You must specify the slash. Valid values are
from 0 to 255. The router treats a value that is outside the
range of valid values as the connection ID. The default
value is 0.
Note
The arguments vpi and vci cannot both be set to 0;

if one is 0, the other cannot be 0.
vci specifies the ATM network virtual channel identifier

(VCI) for this PVC. Valid values are from 0 to 1 less than
the maximum value set for this interface by the atm
vc-per-vp command. A value that is out of range causes an
"unrecognized command" error message.
Note
Step 21
Router(config-atm-vc)# protocol pppoe group

group-name
The VCI value has local significance only and,

therefore, is unique only on a single link, not
throughout the ATM network. Typically, lower
values from 0 to 31 are reserved for specific traffic
(for example, F4 OAM, SVC signaling, ILMI, and
so on) and should not be used.
Enables PPP over Ethernet (PPPoE) sessions to be

established on permanent virtual circuits (PVCs).
group specifies a PPPoE profile (bba-group) to be used by
PPPoE sessions on the interface.
group-name is the name of the PPPoE profile (bba-group) to
be used by PPPoE sessions on the interface.
Note
The group group-name points to the bba-group to

be used for applying a virtual template interface
with QoS policies to sessions.
Step 22
Step 23

OL-7433-09
18-49
Chapter 18
Configuration Example for Per-Session Shaping on ATM Interfaces

The following configuration example shows how to configure per-session shaping. The example shows
how to create two traffic classes named class1 and class2, both of which are defined in the policy map
named child. The class-default class in the Parent policy map has shaping configured. The Child policy
is applied to the Parent policy and this service policy is attached to the virtual template named
VTemplate1, which is associated with the BBA group named East-Region. The BBA group is then
attached to PVC 101/250 on the ATM subinterface 1/0/0.10.
class-map match-all class1
match ip prec 3
!
class-map match-all class2
match access-group 101
!
policy-map Child
class class1
bandwidth 500
class class2
!
policy-map Parent
class class-default
!
interface virtual-template Vtemplate1
!
bba-group pppoe East-Region
virtual-template Vtemplate1
!
interface atm1/0/0.10
pvc 101/250
protocol pppoe group East-Region
Verifying Per-Session Shaping on ATM Interfaces

To verify per-session shaping on ATM interfaces, use any of the following commands in privileged
EXEC mode:
Command
Purpose

the router.
atm 4/0/0).
18-50
OL-7433-09
Chapter 18

Command
Purpose


from 1 to 65535.
session.
session.
Feature
Class maps

ISG commands
Cisco IOS ISG Command Reference
ISG Control Policies
Cisco IOS Intelligent Services Gateway Configuration Guide, Release 12.2SB.

Configuring ISG Control Policies
Per session service policy

using RADIUS
Cisco IOS Security Configuration Guide, Release 12.2
Policing
Part 2: Security Server Protocols > Configuring RADIUS

OL-7433-09
18-51
Chapter 18
Feature
Policy maps


tech note
tech note
18-52
OL-7433-09
CH A P T E R
19

Networks can span many geographical locations and can utilize the full spectrum of networking
technologies available for both network access and the network core. In some networks the core
connections are over existing low-speed Frame Relay or ATM networks. Because service providers have
invested substantially in these networks, providers need a way to differentiate themselves from other
providers and increase profitability while using these low-speed links. The Cisco 10000 series router
offers advanced IP QoS as a solution.
The Cisco 10000 series router provides IP QoS over multiple ATM and Frame Relay PVCs combined
into PVC bundles. By using PVC bundles and QoS-based PVC selection to carry packets, service
providers can increase bandwidth between two routers when the connectivity is limited to low-speed
switched circuits.
This chapter describes PVC bundles and QoS-based PVC selection over ATM and Frame Relay PVCs.
It includes the following topics:
PVC Bundles, page 19-1
ATM PVC Selection, page 19-4
Frame Relay PVC Selection, page 19-31
PVC Bundles
A PVC bundle is a group of permanent virtual circuits (PVCs) combined into a logical group with a
single, virtual interface that connects to a peer system. PVC bundles enable service providers to offer
different levels of service through the use of IP precedence, differentiated services code point (DSCP),
and Multiprotocol Label Switching (MPLS) experimental (EXP) levels, and QoS features. Using the
PVC bundle management software, you can create a bundle of PVCs between a pair of connected routers
and assign different QoS characteristics to individual PVCs in the bundle. Each PVC in a bundle has its
own traffic class and traffic parameters, and is configured to carry packets whose priority matches the
configured range.
Using PVC bundles, you can do the following:
Create differentiated service by distributing IP precedence, DSCP, or MPLS EXP levels over
different PVCs in the bundle.
Map a single precedence, DSCP, or MPLS EXP level or a range of levels to each discrete PVC in
the bundle, thereby enabling individual PVCs in the bundle to carry packets marked with different
levels.

OL-7433-09
19-1
Chapter 19
PVC Bundles
Use Weighted Random Early Detection (WRED) to further differentiate service across traffic that
has different precedence, DSCP, or MPLS EXP levels.
To determine which PVC in the bundle to use to forward an IP or MPLS packet, the router examines the
packets priority bits or Type of Service (ToS) field, or the packets EXP bits. Each PVC in the bundle
is configured to carry packets whose priority matches the configured precedence, DSCP, or MPLS EXP
level. Combined with a queuing mechanism at the output interface, this offers a complete QoS solution
for both data and voice, and allows for further granularization of data types to differentiate data
priorities.
The router supports both ATM and Frame Relay PVC bundles.
Figure 19-1 shows a PVC bundle.
PVC Bundle
132316
Figure 19-1
Point-to-Point
Feature History for PVC Bundles

Cisco IOS Release
Description
Required PRE
Release 12.0(26)S
PVC bundles over ATM and Frame Relay were introduced PRE1
on the PRE1 and included support for IP precedence and
DSCP-based PVC selection. The ATM PVC Bundle
EnhancementMPLS EXP-Based PVC Selection feature
and the Frame Relay PVC Bundles with QoS Support for
IP and MPLS feature were also introduced.
System Limits for PVC Bundles

Table 19-1 lists the system limits for PVC bundles.
Table 19-1 System Limits for PVC Bundles
Bundle
Type
Max. No. of Members

Per Bundle
Max. No. of Bundles

Per System
ATM
16,000
Frame Relay
16,000
19-2
OL-7433-09
Chapter 19

PVC Bundles
Note
IP precedence and MPLS EXP have eight levels that you can assign and DSCP has 64 levels. To include
all DSCP values, you can assign a range of DSCP values (for example, 9-16) to a particular DLCI and
assign the remaining DSCP values to another DLCI using the dscp other command.
Traffic Bumping
Traffic bumping provides a way to keep a PVC bundle up and traffic flowing even though some
individual PVCs might be down. You can configure each PVC bundle member to bump traffic to another
PVC in the bundle when the bundle member does down. You can also specify that a particular PVC can
never accept bumped traffic from another PVC. The default is to accept bumped traffic.
You can specify traffic bumping as either implicit or explicit bumping. Implicit bumping diverts the
traffic from a failed PVC to the PVC having the next lower service level. Explicit bumping forces the
traffic to a specific PVC rather than allowing it to find a PVC carrying traffic of the next lower service
level. The default is to perform implicit traffic bumping.
For example, consider a sample configuration with two PVCs: PVC1 and PVC2. You configure PVC1
to carry precedence level 3 traffic, PVC2 to accept bumped traffic and to carry precedence level 6 traffic,
and PVC1 to bump its traffic to PVC2. If PVC1 goes down, the following occurs:
PVC2 takes over.
If PVC2 is already down or goes down later, the router selects an alternate PVC based on the
bumping rule for PVC2.
If the router cannot find an alternate PVC for the bumped traffic, the entire PVC bundle goes down.
If a bundle member allows PVC bumping, the router selects the next lower precedence level PVC when
a PVC goes down. You can specify only one precedence level for bumping. If the PVC that carries the
bumped traffic fails, the router applies the bumping rules specified for the failed PVC to the traffic. When
the original PVC is up again, the router restores traffic to the original PVC.
PVC Bundle Protection Rules

PVC bundle protection rules provide a way to force the PVC bundle down even though some individual
PVCs are up and might be able to handle all of the traffic, though perhaps not in a satisfactory manner.
The protection rules add flexibility for controlling the state of the PVC bundle.
You can configure a PVC bundle member as an individually protected PVC or as part of a PVC bundle
protected group. Only one protected group can exist within a PVC bundle; however, many individually
protected PVCs can exist.
When a bundle goes down, the router cannot forward traffic using the bundle, even if some of the PVCs
in the bundle are still up. The entire bundle goes down when:
One individually protected PVC goes down
All of the PVCs in a protected group go down.
If you do not specify a protection rule, the PVC bundle goes down only when all of the PVCs go down.
However, if a PVC that has no place to bump its traffic goes down, the router brings down the entire
bundle despite any protection rules that have been set up.

OL-7433-09
19-3
Chapter 19
ATM PVC Selection
ATM PVC Selection

The Cisco 10000 series router can forward packets to ATM bundle members based on the IP precedence
level or Multiprotocol Label Switching (MPLS) experimental (EXP) level of the packets.
The ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection feature allows you to
configure multiple PVCs with different QoS characteristics between any pair of ATM-connected routers
and to configure a group of ATM PVCs with a single next-hop address. Packets are mapped to specific
PVCs in the bundle on the basis of the precedence value or MPLS EXP value in the type of service (ToS)
field of the IP header. Each packet is treated differently according to the QoS configured for each PVC.
The MPLS EXP-Based PVC Selection feature provides flexible PVC management within a PVC bundle
by allowing traffic assigned to a failed PVC to be redirected to an alternate PVC within the bundle. It
also allows you to configure the bundle to go down when certain PVCs go down. IP packets carrying
different types of traffic can be transported on different PVCs within the same PVC bundle.
Using MPLS-based ATM PVC selection, you can do the following:
Map a single precedence level or MPLS EXP level, or a range of precedence or MPLS EXP levels,
to each PVC in the bundle. This enables you to limit an individual PVC to carry only packets marked
with a specific precedence or MPLS EXP level, or packets marked with different precedence or
MPLS EXP levels. For unlabeled packets that do not specify a selection criteria, the router uses IP
precedence level as the default selection criteria for packet forwarding.
Configure a PVC to support unmapped traffic. If the PVC fails, the router attempts to identify an
alternate PVC. If the router cannot locate an alternate PVC, the router stops the PVC bundle.
Create differentiated service using PVC bundles by distributing MPLS EXP levels over the different
PVC bundle members.
Use Weighted Random Early Detection (WRED) to further differentiate service across traffic that
has different MPLS EXP levels.
The Cisco 10000 series router forwards non-IP packets using the PVC that is responsible for carrying
precedence level 6 traffic. The router uses process-switching to forward locally generated packets as
follows:
1.
To determine which PVC in a bundle is used to forward a specific type of traffic, the
ATM VC bundle management software matches MPLS EXP levels between packets and PVCs.
Because all PVCs in a bundle share the same destination, the router forwards IP traffic to the next
hop address for the bundle, but the PVC used to carry a packet depends on the value set for that
packet in the MPLS EXP level of the type of service (ToS) byte of its header.
2.
The ATM PVC bundle management software matches the MPLS EXP level of the packet to the
MPLS EXP levels assigned to a PVC and sends the packet out on the appropriate PVC. The
ATM PVC bundle management software also allows you to configure how traffic is redirected if a
PVC goes down.
3.
MPLS EXP-based PVC selection maps the IP precedence level in the IPv4 header to a PVC
configured with the same value. The three precedence bits in the type of service (ToS) byte of the
IP header defines the precedence levels for IP traffic. You can use a default PVC for all unspecified
precedence levels.
4.
After you define an ATM bundle and add PVCs to it, you can configure attributes and characteristics
to discrete PVC bundle members, or you can apply them collectively at the bundle level. You can
apply ATM traffic shaping to each PVC within a bundle.
19-4
OL-7433-09
Chapter 19

ATM PVC Selection
Feature History for ATM PVC Selection

Cisco IOS Release
Description
Required PRE
Release 12.0(26)S
The ATM PVC Bundle EnhancementMPLS EXP-Based PRE1

PVC Selection feature was introduced on the PRE1.
Configuration Commands for ATM PVC Selection

This section describes the following configuration commands:
bump Command, page 19-5
bundle Command, page 19-6
class-bundle Command, page 19-7
class-vc Command, page 19-8
mpls experimental Command, page 19-9
oam-bundle Command, page 19-10
precedence Command, page 19-11
protect Command, page 19-12
pvc-bundle Command, page 19-13
bump Command
To configure the bumping rules for a PVC bundle or a specific PVC bundle member, use the bump
command in VC class or bundle member configuration mode. To remove the explicit bumping rules and
return to the default condition of implicit bumping, use the no form of the command.
bump {explicit precedence-level | implicit | traffic}
no bump {explicit precedence-level | implicit | traffic}
Syntax Description
explicit
precedence-level
Specifies the precedence level to which traffic on a VC or PVC is bumped

when the VC or PVC goes down. Valid values are from 0 to 7.
implicit
Applies the implicit bumping rule, which is the default, to a single VC or

PVC bundle member, or to all VCs in the bundle (VC-class mode). The
implicit bumping rule stipulates that bumped traffic is to be carried by a VC
or PVC with a lower precedence level.
traffic
Specifies that the VC or PVC accepts bumped traffic. By default, a PVC

permits bumping and accepts bumped traffic.
To configure a PVC to reject bumped traffic from another bundle member,
enter the no bump traffic command.

OL-7433-09
19-5
Chapter 19
ATM PVC Selection
bump Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
Implicit bumping
Permit bumping (VCs accept bumped traffic)
Configuration Mode
VC-class configuration (for a VC class)
Bundle-vc configuration (for an ATM VC bundle member)
Usage Guidelines for the bump Command

If you configure implicit bumping, bumped traffic is sent to the PVC configured to handle the next lower
precedence level. When the original PVC that bumped the traffic comes back up, the traffic that it is
configured to carry is restored to it. If no other positive forms of the bump command are configured, the
bump implicit command takes effect.
If you configure a PVC with the bump explicit command, you can specify the precedence level or MPLS
EXP level to which traffic is bumped when that PVC goes down, and the traffic is directed to a PVC
mapped with that precedence or MPLS EXP level. If the PVC that picks up and carries the traffic goes
down, the traffic is subject to the bumping rules for that PVC. You can specify only one precedence level
for bumping.
The PVC accepts bumped traffic by default. If the PVC has been previously configured to reject bumped
traffic, you must use the bump traffic command to return the PVC to its default condition.
To configure a discrete PVC to reject bumped traffic when the traffic is directed to it, use the no bump
traffic command.
bundle Command
To create a bundle or modify an existing bundle, use the bundle command in subinterface configuration
mode. To remove the specified bundle, use the no form of the command. By default, no bundle is
specified.
bundle bundle-name
no bundle bundle-name
Syntax Description
bundle-name
Specifies the name of the bundle to create or modify. The bundle-name is

limited to 16 alphanumeric characters.
19-6
OL-7433-09
Chapter 19

ATM PVC Selection
bundle Command History

Cisco IOS Release
Description
Release 12.0(26)S
Usage Guidelines for the bundle Command

In the bundle configuration mode you can configure the characteristics and attributes of the bundle and
its members, such as the encapsulation type for all virtual circuits (VCs) in the bundle, the bundle
management parameters, the service type, and so on. Attributes and parameters you configure in bundle
configuration mode are applied to all bundle members.
VCs in a VC bundle are subject to the following configuration inheritance guidelines (listed in order of
next highest precedence):
VC configuration in bundle-vc mode
Bundle configuration in bundle mode
Subinterface configuration in subinterface mode
To display the status of bundles, use the show atm bundle and show atm bundle statistics commands.
class-bundle Command
To configure a virtual circuit (VC) bundle with the bundle-level commands contained in the specified
VC class, use the class-bundle command in bundle configuration mode. To remove the VC class
parameters from a VC bundle, use the no form of the command.
class-bundle vc-class-name
no class-bundle vc-class-name
Syntax Description
vc-class-name
Name of the VC class that you are assigning to your VC bundle.
class-bundle Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
No VC class is assigned to the VC bundle.
Usage Guidelines for the class-bundle Command

To use this command, you must first enter the bundle command to create the bundle and enter bundle
configuration mode.
Use this command to assign a previously defined set of parameters (defined in a VC class) to an ATM
VC bundle. Parameters set through bundle-level commands that are contained in a VC class are applied
to the bundle and its VC members.

OL-7433-09
19-7
Chapter 19
ATM PVC Selection
You can add the following commands to a VC class to be used to configure a VC bundle: broadcast,
encapsulation, inarp, oam-bundle, oam retry, and protocol.
Bundle-level parameters applied through commands that are configured directly on a bundle supersede
bundle-level parameters applied through a VC class by the class-bundle command. 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.
class-vc Command
To assign a virtual circuit (VC) class to an ATM permanent virtual circuit (PVC) or PVC bundle member,
use the class-vc command in the appropriate configuration mode. To remove a VC class, use the no form
of this command.
class-vc vc-class-name
no class-vc vc-class-name
Syntax Description
vc-class-name
Name of the VC class you are assigning to your ATM PVC, SVC, or VC
bundle member.
class-vc Command History

Cisco IOS Release
Description
Release 12.0(26)S
Configuration Modes
Interface-ATM-VC configuration (for ATM PVCs)
Bundle-vc configuration (for VC bundle members)
PVC-range configuration (for PVC ranges)
Usage Guidelines for the class-vc Command

To use this command for assigning a VC class to a VC bundle member, you must first use the pvc-bundle
command to enter bundle-vc configuration mode.
When you create a VC class for a VC bundle member, you can use the following commands to define
your parameters: bump, precedence, protect, ubr, ubr+, and vbr-nrt. You cannot use the following
commands in vc-class configuration mode to configure a VC bundle member: encapsulation, protocol,
inarp, and broadcast. These commands are useful only at the bundle level, not the bundle member level.
Parameters applied to an individual VC supersede bundle-level parameters. Parameters that are directly
configured for a VC through discrete commands entered in bundle-vc configuration mode supersede VC
class parameters assigned to a VC bundle member by the class-vc command.
19-8
OL-7433-09
Chapter 19

ATM PVC Selection
mpls experimental Command

To configure Multiprotocol Label Switching (MPLS) experimental (EXP) levels for a virtual circuit
(VC) class that can be assigned to a PVC bundle and thus applied to all PVC members of that bundle,
use the mpls experimental command in vc-class configuration mode. To remove the MPLS EXP levels
from the VC class, use the no form of the command.
To configure the MPLS EXP levels for a PVC member of a bundle, use the mpls experimental command
in bundle-vc configuration mode. To remove the MPLS EXP levels from the PVC, use the no form of
the command.
mpls experimental [other | range]
no mpls experimental
Syntax Description
other
(Optional) Any MPLS EXP levels that are not explicitly configured.
range
(Optional) A single MPLS EXP level specified as a number from 0 to 7, or

a range of levels specified as a hyphenated range.
mpls experimental Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
Defaults to other, that is, any MPLS EXP levels that are not explicitly configured.
Configuration Modes
Bundle-vc configuration (for ATM VC bundle members)
Usage Guidelines for the mpls experimental Command

Assignment of MPLS EXP levels to VC bundle members allows you to create differentiated service
because you can distribute the MPLS EXP levels over the different VC bundle members. You can map
a single level or a range of levels to each discrete VC in the bundle, thereby enabling VCs in the bundle
to carry packets marked with different levels. Alternatively, you can configure a VC with the
mpls experimental other command to indicate that it can carry traffic marked with levels not
specifically configured for it. Only one VC in the bundle can be configured with the mpls experimental
other command to carry all levels not specified. This VC is considered the default VC.
To use this command in vc-class configuration mode, enter the vc-class atm global configuration
command before you enter this command. This command has no effect if the VC class that contains the
command is attached to a standalone VC, that is, if the VC is not a bundle member.
To use this command to configure an individual bundle member in bundle-vc configuration mode, first
enter the bundle command to enact bundle configuration mode for the bundle to which you want to add
or modify the VC member to be configured. Then, use the pvc-bundle command to specify the VC to
be created or modified and enter bundle-vc configuration mode.

OL-7433-09
19-9
Chapter 19
ATM PVC Selection
next highest MPLS EXP level):
Note
Bundle configuration in bundle mode (with the effect of assigned vc-class configuration)
If you are using an ATM interface, you must configure all MPLS EXP levels (ranging from 0 to 7) for
the bundle. To do this, we recommend configuring one member of the bundle with the mpls
experimental other command. The other keyword defaults to any MPLS EXP levels in the range from
0 to 7 that are not explicitly configured.
oam-bundle Command
To enable end-to-end F5 Operation, Administration, and Maintenance (OAM) loopback cell generation
and OAM management for all permanent virtual circuit (PVC) members of a bundle or a VC class that
can be applied to a PVC bundle, use the oam-bundle command in VC-class configuration mode. To
remove OAM management from the bundle or class configuration, use the no form of the command.
oam-bundle [manage] [frequency]
no oam-bundle [manage] [frequency]
Syntax Description
manage
(Optional) Enables OAM management. If you omit this keyword, loopback

cells are sent, but the bundle is not managed.
frequency
(Optional) Number of seconds between transmitted OAM loopback cells.

Valid values are from 0 to 600 seconds. The default value is 10 seconds.
oam-bundle Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
End-to-end F5 OAM loopback cell generation and OAM management are disabled, but if OAM cells are
received, they are looped back.
Configuration Modes
Bundle configuration (for an ATM VC bundle)
19-10
OL-7433-09
Chapter 19

ATM PVC Selection
Usage Guidelines for the oam-bundle Command

This command defines whether a VC bundle is OAM managed. If this command is configured for a
bundle, every VC member of the bundle is OAM managed. If OAM management is enabled, further
control of OAM management is configured using the oam retry command.
This command has no effect if the VC class that contains the command is attached to a standalone VC;
that is, if the VC is not a bundle member. In this case, the attributes are ignored by the VC.
To use this command in VC-class configuration mode, first enter the vc-class atm global configuration
command.
To use this command in bundle configuration mode, enter the bundle subinterface configuration
command to create the bundle or to specify an existing bundle before you enter this command.
VCs in a VC bundle are subject to the following configuration inheritance rules (listed in order of
next-highest precedence):
VC configuration in bundle-VC mode
Bundle configuration in bundle mode (with effect of assigned VC-class configuration)
precedence Command
To configure precedence levels for a virtual circuit (VC) class that can be assigned to a VC bundle and
thus applied to all VC members of that bundle, use the precedence command in vc-class configuration
mode. To remove the precedence levels from the VC class, use the no form of the command.
To configure the precedence levels for a VC or permanent virtual circuit (PVC) member of a bundle, use
the precedence command in bundle-vc configuration mode for ATM VC bundle members. To remove
the precedence levels from the VC or PVC, use the no form of the command.
precedence [other | range]
no precedence
Syntax Description
other
(Optional) Any precedence levels in the range from 0 to 7 that are not
explicitly configured.
range
(Optional) A single precedence level specified either as a number from 0 to

7 or as a range of precedence levels, specified as a hyphenated range.
precedence Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
Defaults to otherthat is, any precedence levels in the range from 0 to 7 that are not explicitly
configured.

OL-7433-09
19-11
Chapter 19
ATM PVC Selection
Configuration Modes
Usage Guidelines for the precedence Command

Assignment of precedence levels to VC or PVC bundle members allows you to create differentiated
service because you can distribute the IP precedence levels over the various VC/PVC bundle members.
You can map a single precedence level or a range of levels to each discrete VC/PVC in the bundle,
thereby enabling VCs/PVCs in the bundle to carry packets marked with different precedence levels.
Alternatively, you can use the precedence other command to indicate that a VC/PVC can carry traffic
marked with precedence levels not specifically configured for other VCs/PVCs. Only one VC/PVC in
the bundle can be configured using the precedence other command. This VC/PVC is the default
VC/PVC.
To use this command in vc-class configuration mode, first enter the vc-class atm command in global
configuration mode. The precedence command has no effect if the VC class that contains the command
is attached to a standalone VC; that is, if the VC is not a bundle member.
To use the precedence command to configure an individual bundle member in bundle-VC configuration
mode, first enter the bundle command to enter bundle configuration mode. Next, use the pvc-bundle
command to add a PVC to the bundle as a member of the bundle and enter bundle-VC configuration
mode.
next-highest precedence):
Bundle configuration in bundle mode (with effect of assigned vc-class configuration)
protect Command
To configure a virtual circuit (VC) class with protected group or protected VC status for application to
a VC bundle member, use the protect command in vc-class configuration mode. To remove the protected
status from the VC class, use the no form of the command.
To configure a specific VC or permanent virtual circuit (PVC) as part of a protected group of the bundle
or to configure it as an individually protected VC or PVC bundle member, use the protect command in
bundle-vc configuration mode. To remove the protected status from the VC or PVC, use the no form of
the command.
protect {group | vc}
no protect {group | vc}
Syntax Description
group
Configures the VC or PVC bundle member as part of the protected group of

the bundle.
vc
Configures the VC or PVC member as individually protected.
19-12
OL-7433-09
Chapter 19

ATM PVC Selection
protect Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
The VC or PVC neither belongs to the protected group nor is it an individually protected VC or PVC.
Configuration Modes
Usage Guidelines for the protect Command

Use the protect command in vc-class configuration mode to configure a VC class to contain protected
group or individual protected VC status. When the class is applied to the VC bundle member, that VC is
characterized by the protected status. You can also apply this command directly to a VC in bundle-vc
configuration mode.
When a protected VC goes down, it takes the bundle down. When all members of a protected group go
down, the bundle goes down.
To use the protect command in vc-class configuration mode, first enter the vc-class atm global
configuration command.
The protect command has no effect if the VC class that contains the command is attached to a standalone
VC, that is, if the VC is not a bundle member.
To use the protect command in bundle-vc configuration mode, first enter the bundle command to enact
bundle configuration mode for the bundle containing the VC member to be configured. Then enter the
pvc-bundle configuration command to add the VC to the bundle as a member of it.
next highest precedence):
Bundle configuration in bundle mode (with effect of assigned vc-class configuration)
pvc-bundle Command
To add a permanent virtual circuit (PVC) to a bundle as a member of the bundle and enter bundle-vc
configuration mode in order to configure that PVC bundle member, use the pvc-bundle command in
bundle configuration mode. To remove the VC from the bundle, use the no form of the command.
pvc-bundle pvc-name [vpi/] [vci]
no pvc-bundle pvc-name [vpi/] [vci]

OL-7433-09
19-13
Chapter 19
ATM PVC Selection
Syntax Description
pvc-name
The name of the permanent virtual circuit (PVC) bundle.
vpi/
(Optional) ATM network virtual path identifier (VPI) for this PVC. The
absence of the "/" and a vpi value defaults the vpi value to 0.
The vpi and vci arguments cannot both be set to 0; if one is 0, the other
cannot be 0.
vci
(Optional) ATM network virtual channel identifier (VCI) for this PVC. The
value range is from 0 to 1 less than the maximum value set for this interface
by the atm vc-per-vp command. Typically, lower values 0 to 31 are
reserved for specific traffic (F4 Operation, Administration, and
Maintenance (OAM), Integrated Local Management Interface (ILMI), and
so on) and should not be used.
The VCI is a 16-bit field in the header of the ATM cell. The VCI value is
unique only on a single link, not throughout the ATM network, because it
has local significance only.
The vpi and vci arguments cannot both be set to 0; if one is 0, the other
cannot be 0.
pvc-bundle Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
No default behavior or values.
Configuration Modes
Bundle configuration
Usage Guidelines for the pvc-bundle Command

Each bundle can contain multiple VCs having different QoS attributes. This command associates a VC
with a bundle, making it a member of that bundle. Before you can add a VC to a bundle, the bundle must
exist. Use the bundle command to create a bundle. You can also use this command to configure a VC
that already belongs to a bundle. You enter the command in the same way, giving the name of the VC
bundle member.
The pvc-bundle command enters bundle-vc configuration mode, in which you can specify VC-specific
and VC class attributes for the VC.
ATM Bundle Management

ATM PVC bundle management software allows you to configure multiple PVCs that have different QoS
characteristics between any pair of ATM-connected routers. As shown in Figure 19-2, these PVCs are
grouped in a bundle and are referred to as bundle members.
19-14
OL-7433-09
Chapter 19

ATM PVC Selection
Figure 19-2
ATM VC Bundle
IP
Precedence
22313
VC 1
ATM PVC bundle management allows you to define an ATM PVC bundle and add PVCs to it. Each PVC
of a bundle has its own ATM traffic class and ATM traffic parameters. You can apply attributes and
characteristics to discrete PVC bundle members or you can apply them collectively at the bundle level.
Using PVC bundles, you can create differentiated service by flexibly distributing IP precedence levels
or Multiprotocol Label Switching (MPLS) experimental (EXP) levels over the different PVC bundle
members. You can map a single level or a range of levels to each discrete PVC in the bundle, thereby
enabling individual PVCs in the bundle to carry packets marked with different precedence or MPLS EXP
levels. You can use weighted random early detection (WRED) to further differentiate service across
traffic that has different IP precedence or MPLS EXP levels, but that uses the same PVC in a bundle.
To determine which PVC in the bundle to use to forward a packet to its destination, the ATM PVC bundle
management software matches precedence levels or MPLS EXP levels between packets and PVCs (see
Figure 19-3). IP traffic is sent to the next hop address for the bundle because all PVCs in a bundle share
the same destination, but the PVC used to carry a packet depends on the value set for that packet in the
IP precedence bits or the MPLS EXP bits of the type of service (ToS) byte of its header. The ATM PVC
bundle management software matches the IP precedence or MPLS EXP level of the packet to the IP
precedence or MPLS EXP value or range of values assigned to a PVC, sending the packet out on the
appropriate VC.
The ATM PVC bundle management software also allows you to configure how traffic is redirected when
the PVC the packet was matched to goes down. Figure 19-3 shows how the ATM PVC bundle
management software determines which PVC bundle member to use to carry a packet and how WRED
is used to differentiate traffic on the same VC. In the figure PVC selection is based on IP precedence
levels, but it can also be based on MPLS EXP levels.

OL-7433-09
19-15
Chapter 19
ATM PVC Selection
Figure 19-3
ATM PVC Selection
VC1
VC2
VC3
VC4
WRED in
per-VC queue
17626
VC selection
based on
precedence
Bumping and ATM PVC Bundles

The ATM Operation, Administration, and Maintenance (OAM) polling mechanisms maintain the
integrity of the PVCs in an ATM PVC bundle. These mechanisms determine whether a PVC is
unavailable or severely congested. If an individual circuit become unavailable, then the device consults
a preset series of rules to determine the course of action to take next. You configure specific parameters
to define these rules.
Figure 19-4 conceptualizes a failed PVC bundle member whose failure calls into effect the configured
bumping rules.
19-16
OL-7433-09
Chapter 19

ATM PVC Selection
Figure 19-4
PVC Bundle Member Circuit Failure Enacting Bumping Rules
Bump
Failure
IP
Precedence
22314
VC 1
In the event of failure, the router responds with one of two methods:
The first method dynamically assigns the traffic bound on the failed PVC to an alternative PVC,
which is referred to as circuit bumping. Bumped traffic is then shared on an existing in-service PVC.
Although not required, traffic is typically bumped from a higher class to a lower one. For example,
if the premium, or first class, data circuit become unavailable, then all premium users share the
second class or general circuit. Within this shared circuit, preference is given to the premium traffic.
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 network configuration determines whether to bump traffic or whether to declare the bundle inactive.
Prerequisites for ATM PVC Selection
The Cisco 10000 series router must be running Cisco IOS Release 12.0(26)S or later.
To implement ATM PVC bundles between two routers, you must enable IP Cisco Express
Forwarding (CEF) switching on the routers.
Restrictions and Limitations for ATM PVC Selection

PVCs
In Cisco IOS Release 12.0(26)S, the ATM implementation of VC bundles is restricted to PVCs.
You can configure a maximum of 8 PVCs in one PVC bundle.
A PVC can be a member of one and only one PVC bundle.
A PVC that is a bundle member cannot be used in any other capacity. For example, you cannot
configure a PVC bundle member in a map statement.

OL-7433-09
19-17
Chapter 19
ATM PVC Selection
The Cisco 10000 router does not support automapping of PVCs or variable bit rate-real-time
(VBR-rt) for PVCs.
The Cisco 10000 router supports aal5snap and aal5mux encapsulation types for PVCs and
multipoint and point-to-point subinterfaces.
VC Selection
You can map one or multiple precedence or MPLS EXP levels to a single PVC; however, you cannot
map multiple PVCs to one precedence or MPLS EXP level.
A PVC bundle does not come up until you configure all of the precedence or MPLS EXP levels in
the bundle.
If you attach a VC class with bundle attributes to a PVC that is not configured as a member of a
PVC bundle, the Cisco 10000 router ignores the bundle attributes.
ATM Inverse ARP
You can enable or disable inverse ARP for the PVC bundle but not for individual PVCs in the bundle.
ATM inverse ARP for IP uses the PVC configured with precedence level 6.
Inverse ARP for protocols other than IP (for example, IPX) is disabled by default unless you
explicitly configure it in the PVC bundle.
Packet Forwarding
The Cisco 10000 router does not support fast switching of IP packets.
Configuring ATM Bundles

You can configure ATM bundles either directly or by associating a VC class with the bundle.
To configure ATM bundles, perform the following configuration tasks:
Creating an ATM Bundle Directly, page 19-18
Creating an ATM Bundle Using a VC Class, page 19-20
Adding an ATM PVC to a PVC Bundle, page 19-23
Creating an ATM Bundle Directly

The router applies the parameters you configure in ATM bundle configuration mode to the PVC bundle
and to all of the bundle members. These parameters supersede the parameters that you apply by
associating a VC class with the bundle. Parameters that you apply to an individual PVC supersede the
parameters that you apply to the bundle.
To create a PVC bundle directly, enter the following commands beginning in global configuration mode:
Command
Purpose
Step 1

slot/module/port[.subinterface]
Creates or modifies an interface or subinterface. Enters interface

or subinterface configuration mode.
Step 2
Router(config-subif)# mpls ip
(Optional) Enables MPLS forwarding of IPv4 packets along

normally routed paths. You must configure this command if you
configure MPLS EXP-based PVC selection.
19-18
OL-7433-09
Chapter 19

ATM PVC Selection
Step 3
Command
Purpose
Router(config-subif)# bundle bundle-name
Creates or modifies the PVC bundle and enters ATM bundle

configuration mode.
bundle-name is the name of the bundle.
Step 4
Router(config-atm-vcb)# protocol protocol

{protocol-address | inarp} [[no]
broadcast]
Configures a static map for an ATM PVC or VC class, or enables

Inverse Address Resolution Protocol (ARP) or Inverse ARP
broadcasts on an ATM PVC.
protocol is the protocol carried on the VC (for example, ip).
protocol-address is the destination address that is being mapped
to a PVC.
(Valid only for IP and IPX protocols on PVCs) inarp enables
Inverse ARP on an ATM PVC. If you specify a protocol-address
instead of inarp, Inverse ARP is automatically disabled for that
protocol.
(Optional) [no] broadcast indicates that this map entry is used
when the corresponding protocol sends broadcast packets to the
interface. Pseudobroadcasting is supported. The broadcast
keyword of the protocol command takes precedence if you
previously configured the broadcast command on the ATM PVC.
Step 5
Router(config-atm-vcb)# encapsulation
[aal5snap | aal5mux ip]

type for the bundle.
Step 6
Router(config-atm-vcb)# encapsulation
{aal5mux protocol | aal5ciscoppp
virtual-template number | aal5snap}

type for an ATM virtual circuit (VC).
aal5mux is the AAL and encapsulation type for multiplex
(MUX)-type VCs. You must specify a protocol when using this
encapsulation type.
protocol is the protocol type being used by the
MUX-encapsulated VC.
aal5ciscoppp specifies the AAL and encapsulation type for
Cisco PPP over ATM. Supported on ATM PVCs only.
virtual template.
aal5snap specifies the AAL and encapsulation type that supports
Inverse ARP. Logical Link Control/Subnetwork Access Protocol
(LLC/SNAP) precedes the protocol datagram.
Step 7
Router(config-atm-vcb)# class class_name
(Optional) Attaches a VC class to the bundle.

class_name is the name of the VC class.
Step 8
Router(config-atm-vcb)# inarp [minutes]
Configures the Inverse Address Resolution Protocol (ARP) time

period for an ATM PVC, VC class, or VC bundle.
minutes is the number of minutes for the Inverse ARP time period.
Step 9
Router(config-atm-vcb)# broadcast
Enables broadcast forwarding for all VC bundle members.

OL-7433-09
19-19
Chapter 19
ATM PVC Selection
Step 10
Command
Purpose
Router(config-atm-vcb)# oam retry

up-count down-count retry-frequency
Configures parameters related to Operation, Administration, and

Maintenance (OAM) management for each PVC in the bundle.
up-count is the number of consecutive end-to-end F5 OAM
loopback cell responses that must be received in order to change
a PVC connection state to up.
down-count is the number of consecutive end-to-end F5 OAM
loopback cell responses that are not received in order to change a
PVC state to down.
retry-frequency is the frequency (in seconds) that end-to-end F5
OAM loopback cells are transmitted when a change in the
up/down state of a PVC is being verified. For example, if a PVC
is up and a loopback cell response is not received after specifying
retry-frequency, then loopback cells are sent at the
retry-frequency to verify whether the PVC is down.
Step 11
Router(config-atm-vcb)# oam-bundle
[manage] [frequency]
Enables end-to-end F5 Operation, Administration, and

Maintenance (OAM) loopback cell generation and OAM
management for all bundle members or a VC class that can be
applied to a VC bundle
(Optional) manage enables OAM management. If you omit this
keyword, loopback cells are sent, but the bundle is not managed.
(Optional) frequency is the number of seconds between
transmitted OAM loopback cells. Valid values are from 0 to 600
seconds. The default is 10 seconds.
Step 12
Router(config-atm-vcb)# ubr [pcr]
Configures unspecified bit rate (UBR) as the traffic shaping rule.

(Optional) pcr is the peak cell rate.
Step 13
Router(config-atm-vcb)# ubr+ pcr [mcr]
Configures UBR plus (UBR+) as the traffic shaping rule.

pcr is the peak cell rate.
(Optional) mcr is the minimum cell rate.
Step 14
Router(config-atm-vcb)# vbr-nrt pcr scr

[mbs]
Configures variable bit rate-nonreal-time (VBR-nrt) as the traffic

shaping rule.
scr is the sustained cell rate.
(Optional) mbs is the maximum burst size.
Creating an ATM Bundle Using a VC Class

You can use a VC class to configure an ATM PVC bundle. The VC class contains multiple configuration
parameters, including the method used for PVC selection. When you apply the VC class to the bundle,
the VC class parameters apply to all of the members of a bundle.
The parameters that you apply manually to the PVC bundle supersede the parameters that you apply by
associating a VC class with the bundle. Parameters that you apply to an individual PVC supersede the
parameters that you apply to a bundle.
To create an ATM bundle using a VC class, perform the following configuration tasks:
19-20
OL-7433-09
Chapter 19

ATM PVC Selection
Configuring a VC Class and Specifying the Basis for PVC Selection, page 19-21
Attaching a VC Class to an ATM Bundle, page 19-22
Configuring a VC Class and Specifying the Basis for PVC Selection

To configure a VC class and specify the basis for PVC selection, enter the following commands
Step 1
Command
Purpose
Creates or modifies a VC class and enters VC class configuration

mode.
Step 2
Router(config-vc-c)# oam-bundle [manage]

[frequency]

management for a VC class that can be applied to a VC bundle.
Step 3
Router(config-vc-c)# mpls experimental

[other | range]
(Optional) Configures Multiprotocol Label Switching (MPLS)

experimental (EXP) levels for a VC class that can be assigned to
a VC bundle and thus applied to all VC members of that bundle.
This command configures MPLS EXP-based PVC selection.
(Optional) other specifies any MPLS EXP levels that are not
explicitly configured. This is the default setting.
(Optional) range specifies a single MPLS EXP level (2), or a
range of levels (1-3). Valid values are from 0 to 7.
Step 4
Router(config-vc-c)# precedence {level |

other}
(Optional) Configures the precedence levels for a bundle member.

This command configures precedence-based PVC selection.
level specifies the precedence level or levels for this bundle
member. Valid values are from 0 to 7.
You can configure a PVC bundle member with a single
precedence level (0), multiple individual precedence levels
(0,2,3), a range of precedence levels (0-2), multiple ranges of
precedence levels (0-2,4-5), or a combination of individual levels
and level ranges (0,1,2-4,7).
Note
This command is available when the PVC bundle match

type is set to precedence.
other specifies that this bundle member handles all of the

remaining precedence levels that are not explicitly configured on
any other bundle members.
Note
Critical non-IP traffic automatically uses precedence

level 0.

OL-7433-09
19-21
Chapter 19
ATM PVC Selection
Step 5
Command
Purpose
Router(config-vc-c)# bump {explicit

precedence-level | implicit | traffic}
(Optional) Configures the bumping rules for a VC class that can

be assigned to a VC bundle or configures the bumping rules for a
specific VC or PVC member of a bundle. The default is implicit
bumping.
explicit precedence-level specifies the precedence level to which
traffic on a VC or PVC is bumped when the VC or PVC goes
down. Valid values are from 0 to 7.
implicit applies the implicit bumping rule, which is the default,
to a single VC or PVC bundle member, or to all VCs in the bundle
(VC-class mode). The implicit bumping rule stipulates that
bumped traffic is to be carried by a VC or PVC with a lower
precedence level.
traffic specifies that the VC or PVC accepts bumped traffic. By
default, a PVC permits bumping and accepts bumped traffic.
Note
Step 6
Router(config-vc-c)# protect {group | vc}
To configure a PVC to reject bumped traffic from another

bundle member, enter the no bump traffic command.
(Optional) Configures a specific VC or permanent virtual circuit

(PVC) as part of a protected group of the bundle or configures it
as an individually protected VC or PVC bundle member. By
default, the PVC bundle member is not protected.
group configures the VC or PVC bundle member as part of the
protected group of the bundle and specifies that the bundle goes
down when the last PVC in the protected group goes down.
vc configures the bundle member as individually protected and
specifies that the bundle goes down whenever the PVC goes
down.
Attaching a VC Class to an ATM Bundle

To attach a VC class to an ATM bundle, enter the following commands beginning in global configuration
mode:
Command
Purpose
Step 1


configuration mode.
Step 2
Activates the PVC bundle and enters ATM bundle configuration

mode.
bundle-name is the name of the bundle to which you want to
attach the VC class.
Step 3
Router(config-atm-vcb)# class-bundle
vc-class-name
Associates the VC class you specify with the PVC bundle. The
router applies the parameters specified in the VC class to the
bundle.
vc-class-name is the name of the VC class that you are attaching
to the VC bundle.
19-22
OL-7433-09
Chapter 19

ATM PVC Selection
Adding an ATM PVC to a PVC Bundle

To add an ATM PVC to a PVC bundle, enter the following commands beginning in global configuration
mode:
Command
Purpose
Step 1


configuration mode.
Step 2
Creates or modifies the PVC bundle. Enters ATM bundle

configuration mode.
bundle-name is the name of the bundle to which you want to add
a PVC.
Step 3
Router(config-atm-vcb)# pvc-bundle
pvc_name [vpi/]{vci}
Adds the specified PVC to the bundle. Enters ATM bundle

member configuration mode.
pvc-name is a name that you can use to refer to the PVC.
Configuring ATM Bundle Members

You can configure PVC bundle members manually or by associating VC classes to the bundle members.
The parameter values that you configure manually for an individual PVC supersede the parameter values
applied to the ATM bundle. The parameter values that you configure manually for a PVC take
precedence over the parameters applied using a VC class.
To configure ATM bundle members, perform the following configuration tasks:
Configuring an ATM Bundle Member, page 19-23
Configuring an ATM Bundle Member Using a VC Class, page 19-25
Configuring a PVC Not to Accept Bumped Traffic, page 19-27
Configuring an ATM Bundle Member

The parameter values that you configure manually for a PVC in ATM bundle member configuration
mode take precedence over the values of these parameters that you set for the PVC in any other
configuration mode, including a VC class applied in the ATM bundle member configuration mode.
To configure an ATM bundle member, enter the following commands beginning in global configuration
mode:
Command
Purpose
Step 1


configuration mode.
Step 2
Creates or modifies the PVC bundle and enters ATM bundle

configuration mode.
bundle-name is the name of the bundle.

OL-7433-09
19-23
Chapter 19
ATM PVC Selection
Step 3
Command
Purpose
Adds the specified VC to the bundle if it does not exist already

and enters ATM bundle VC configuration mode.
vpi/ is the virtual path identifier (VPI). The slash is required.
vci is the virtual channel identifier (VCI).
Step 4
Router(config-atm-vcb-vc)# bump
{explicit level | implicit | traffic}
(Optional) Configures the bumping rules for the bundle member.

The default is implicit bumping.
explicit level specifies the precedence, experimental (EXP), or
differentiated services code point (DSCP) level to which traffic on
the PVC is bumped if the PVC goes down. You can specify only
one service level for bumping. For PVC bundles that use
precedence or EXP mapping, valid values for level are from 0 to
7. For PVC bundles that use DSCP mapping, valid values are from
0 to 63.
Note
When the PVC goes down, the router directs the traffic to
a PVC mapped with the service level you configure in
explicit level.

to a single bundle member. The implicit bumping rule stipulates
that bumped traffic is to be carried by a PVC that has the lower
precedence level.
traffic specifies that the PVC accepts bumped traffic. By default,
a PVC accepts bumped traffic.
Note
Step 5
Router(config-atm-vcb-vc)# mpls
experimental [other | range]


experimental (EXP) levels for the bundle member. This command
configures MPLS EXP-based PVC selection.
(Optional) range specifies a single MPLS EXP level (2) or a range
of levels (1-3). Valid values are from 0 to 7.
Step 6
Router(config-atm-vcb-vc)# precedence
[other | range]
(Optional) Configures the precedence levels for the VC bundle

member. This command configures precedence-based PVC
selection.
(Optional) other specifies any precedence levels that are not
explicitly configured. Valid values are 0 to 7.
(Optional) range specifies a single precedence level. Valid values
are from 0 to 7, specified either as a single number (3) or a range
of precedence levels (2-4).
Step 7
Router(config-atm-vcb-vc)# class
class-name
Attaches a VC class to the PVC bundle member.

class-name is the name of the VC class.
19-24
OL-7433-09
Chapter 19

ATM PVC Selection
Step 8
Command
Purpose
Router(config-atm-vcb-vc)# protect {group

| vc}
Configures the bundle member as part of the protected group of a

bundle or as an individually protected VC in a bundle.
protected group of the bundle.
vc configures the VC or PVC member as individually protected.
Step 9
Router(config-atm-vcb-vc)# ubr [pcr]
(Optional) Configures unspecified bit rate (UBR) as the traffic

shaping rule for the VC.
(Optional) pcr is the peak cell rate (PCR).
Step 10
Router(config-atm-vcb-vc)# ubr+ pcr [mcr]
(Optional) Configures UBR plus (UBR+) as the traffic shaping

rule.
pcr is the peak cell rate (PCR)
(Optional) mcr is the minimum cell rate (MCR).
Step 11
Router(config-atm-vcb-vc)# vbr-nrt pcr

scr [mbs]
(Optional) Configures variable bit rate-nonreal-time (VBR-nrt) as

the traffic shaping rule.
pcr is the peak cell rate (PCR).
scr is the sustaining cell rate (SCR).
(Optional) mbs is the maximum burst size (MBS).
Configuring an ATM Bundle Member Using a VC Class

To configure an ATM bundle member using a VC class, perform the following configuration tasks:
Configuring an ATM VC Class, page 19-25
Attaching a VC Class to an ATM Bundle Member, page 19-27
Configuring an ATM VC Class

To configure an ATM VC class and specify the basis for ATM PVC selection, enter the following
Command
Purpose
Step 1
Creates or modifies a VC class and enters VC class configuration

mode.
Step 2
Router(config-vc-c)# oam-bundle [manage]

[frequency]

management for a VC class that can be applied to a VC bundle.

OL-7433-09
19-25
Chapter 19
ATM PVC Selection
Step 3
Command
Purpose
Router(config-vc-c)# bump {explicit

precedence-level | implicit | traffic}
(Optional) Configures the bumping rules for a VC class that can

be assigned to a VC bundle or configures the bumping rules for a
specific VC or PVC member of a bundle. The default is implicit
bumping.
explicit precedence-level specifies the precedence level to which
traffic on a VC or PVC is bumped when the VC or PVC goes
down. Valid values are from 0 to 7.
to a single VC or PVC bundle member, or to all VCs in the bundle
(VC-class mode). The implicit bumping rule stipulates that
bumped traffic is to be carried by a VC or PVC with a lower
precedence level.
traffic specifies that the VC or PVC accepts bumped traffic. By
default, a PVC permits bumping and accepts bumped traffic.
Note
Step 4
Router(config-vc-c)# protect {group | vc}

(Optional) Configures a specific VC or permanent virtual circuit

(PVC) as part of a protected group of the bundle or configures it
as an individually protected VC or PVC bundle member. By
default, the PVC bundle member is not protected.
protected group of the bundle and specifies that the bundle goes
down when the last PVC in the protected group goes down.
vc configures the bundle member as individually protected and
specifies that the bundle goes down whenever the PVC goes
down.
Step 5
Router(config-vc-c)# mpls experimental

[other | range]

experimental (EXP) levels for a bundle member. This command
configures MPLS EXP-based PVC selection.
(Optional) range specifies a single MPLS EXP level (2) or a range
of levels (1-3). Valid values are from 0 to 7.
Step 6
Router(config-vc-c)# precedence [other |

range]
(Optional) Configures the precedence levels for a VC bundle

member. This command configures precedence-based PVC
selection.
(Optional) other specifies any precedence levels that are not
explicitly configured. Valid values are 0 to 7.
(Optional) range specifies a single precedence level. Valid values
are from 0 to 7, specified either as a single number (3) or a range
of precedence levels (2-4).
Step 7
Router(config-vc-c)# ubr [pcr]
Configures unspecified bit rate (UBR) as the traffic shaping rule.

(Optional) pcr is the peak cell rate.
19-26
OL-7433-09
Chapter 19

ATM PVC Selection
Step 8
Command
Purpose
Router(config-vc-c)# ubr+ pcr [mcr]
Configures UBR plus (UBR+) as the traffic shaping rule.

(Optional) mcr is the minimum cell rate.
Step 9
Router(config-vc-c)# vbr-nrt pcr scr

[mbs]
Configures variable bit rate-nonreal-time (VBR-nrt) as the traffic

shaping rule.
scr is the sustained cell rate.
(Optional) mbs is the maximum burst size.
Attaching a VC Class to an ATM Bundle Member

The parameters that you configure manually for a PVC in ATM bundle configuration mode supersede
the parameters applied to the PVC using a VC class.
To attach a VC class to a bundle member, enter the following commands beginning in subinterface
configuration mode:
Command
Purpose
Step 1


configuration mode.
Step 1

configuration mode.
Step 2
Adds the specified PVC to the bundle if it does not exist already.
Enters ATM bundle member configuration mode.
(Optional) vpi/ is the virtual path identifier (VPI). The slash is
required.
(Optional) vci is the virtual channel identifier.
Step 3
Router(config-atm-vcb-vc)# class-vc
vc-class-name
Assigns a VC class to a PVC bundle member.

vc-class-name is the name of the VC class.
Configuring a PVC Not to Accept Bumped Traffic

To configure an individual PVC bundle member not to accept traffic that the router forwards to it when
the original PVC carrying the traffic goes down, enter the following command in PVC bundle member
configuration mode:

OL-7433-09
19-27
Chapter 19
ATM PVC Selection
Command
Purpose
Step 1


configuration mode.
Step 2

configuration mode.
Step 3
Adds the specified PVC to the bundle if it does not exist already.
Enters ATM bundle member configuration mode.
(Optional) vpi/ is the virtual path identifier (VPI). The slash is
required.
(Optional) vci is the virtual channel identifier.
Step 4
Router(config-atm-vcb-vc)# no bump
traffic
Configures the PVC not to accept any bumped traffic that would
otherwise be redirected to it.
Verifying and Monitoring ATM PVC Bundles

To verify and monitor QoS for ATM PVC bundles, enter any of the following commands in privileged
EXEC configuration mode:
Command
Purpose
Router# debug atm bundle adjacency events
Displays information about ATM bundle adjacency change

events.
Router# debug atm bundle errors
Displays information about bundle errors.
Router# debug atm bundle events
Displays a record of bundle events.
Router# show atm bundle bundle-name
Displays the bundle attributes assigned to each PVC bundle

member and the current working status of the PVC bundle
members.
bundle-name is the name of the bundle whose member
information is displayed. This is the bundle name specified by the
bundle command when the bundle was created.
Router# show atm bundle bundle-name statistics

[detail]
Displays statistics or detailed statistics about the specified

VC bundle.
bundle-name specifies the name of the bundle whose member
information is displayed. This is the bundle name specified by the
bundle command when the bundle was created.
(Optional) detail displays detailed statistics.
Router# show atm map
Displays a list of all configured ATM static maps to remote hosts

on an ATM network and on ATM bundle maps.
19-28
OL-7433-09
Chapter 19

ATM PVC Selection
Command
Purpose
Router# show atm pvc [vpi/vci | name | interface

atm interface-number] [ppp]
Displays all of the ATM PVCs and traffic information.

(Optional) vpi/vci are the ATM virtual path identifier (VPI) and
virtual channel identifier (VCI) numbers. If you do not specify a
value for vpi, the vpi value defaults to 0. The slash is required.
(Optional) name is the name of the PVC.
(Optional) interface-number displays all PVCs on the specified
ATM interface.
(Optional) ppp displays each PVC configured for PPP over ATM.
Router# show atm vc [vcd] [interface

interface-number]
Displays all ATM permanent virtual circuits (PVCs) and traffic

information.
(Optional) vcd specifies which virtual circuit about which to
display information.
(Optional) interface-number is the interface number or
subinterface number of the PVC. Displays all PVCs on the
specified interface or subinterface.
Configuration Examples for Configuring ATM Bundles and PVC Selection

Configuration Example for ATM Bundle Configuration Using VC Classes, page 19-29
Configuration Example for MPLS EXP-Based ATM PVC Selection, page 19-31
Configuration Example for ATM Bundle Configuration Using VC Classes

Example 19-1 shows how to configure ATM bundles using VC classes. The sample configuration defines
five VC classes: bundle-class, control-class, premium-class, priority-class, and basic-class. The VC
class named bundle-class defines the parameters applicable to every VC in a bundle. The sample
configuration also creates three bundles to which the VC classes are applied: new-york, san-francisco,
and los-angeles.
Example 19-1 Configuring ATM Bundles Using VC Classes
/* This router uses IS-IS as the IP routing protocol. */
router isis
net 49.0000.0000.0000.1111.00
/* The bundle-class defines the parameters applicable to every VC in a bundle. Any bundle
that uses this class has aal5snap encapsulation, broadcast enabled, uses Inverse ARP to
resolve IP addresses, and OAM enabled at the bundle class level in the inheritance
chain.*/
vc-class atm bundle-class
broadcast
protocol ip inarp
oam-bundle manage 3
oam 4 3 10
/* The following VC classes define the parameters applicable to individual VCs in a
bundle. */

OL-7433-09
19-29
Chapter 19
ATM PVC Selection
/* The control-class carries precedence 7 traffic and takes the bundle down when it is
down. It uses the implicit bumping rule. The QoS is set to vbr-nrt. */
vc-class atm control-class
precedence 7
protect vc
vbr-nrt 10000 5000 32
/* The premium-class carries precedence 5 and 6 traffic, and does not allow other traffic
to be bumped onto it. The precedence 7 VC is the alternate VC for the premium-class
traffic when it does down. The premium-class belongs to the protected group of the bundle.
The QoS type is vbr-nrt. */
vc-class atm premium-class
precedence 6-5
no bump traffic
protect group
bump explicitly 7
vbr-nrt 20000 10000 32
/* The priority-class carries precedence 4-2 traffic and uses the implicit bumping rule.
It allows bumped traffic and belongs to the protected group of the bundle. The QoS type is
ubr+. */
vc-class atm priority-class
precedence 4-2
protect group
ubr+ 10000 3000
/* The basic-class carries the traffic of the precedence levels that are not specified in
the profile. It is part of the protected group. The QoS type is ubr. */
vc-class atm basic-class
precedence other
protect group
ubr 10000
/* This subinterface has 3 bundles for connecting to its 3 neighbors. Bundle new-york and
bundle san-francisco have 4 members and bundle los-angeles has 3 members. */
interface a1/0.1 multipoint
ip address 10.16.0.1 255.255.255.0
ip router isis
bundle new-york
/* The following protocol commands enable IP and OSI traffic flows in the bundle.
According to the inheritance rule, the protocol ip command takes precedence over the
protocol ip inarp command in bundle-class. The protocol clns command is configured merely
for using it for integrated IP routing. The OSI routing packets go on the highest
precedence VC in the bundle while the OSI data packets, if any, use the lowest precedence
VC in the bundle. Other protocols, such as IPX or AppleTalk, always use the lowest
precedence VC in the bundle when they are configured. */
protocol ip 10.16.1.2 broadcast
protocol clns 49.0000.0000.0000.2222.00 broadcast
class bundle-class
/* The following commands create the PVCs of bundle new-york. */
pvc-bundle ny-control 207
class control-class
pvc-bundle ny-premium 206
class premium-class
pvc-bundle ny-priority 204
class priority-class
pvc-bundle ny-basic 201
class basic-class
bundle san-francisco
19-30
OL-7433-09
Chapter 19

Frame Relay PVC Selection
inarp 1
class bundle-class
pvc-bundle sf-control 307
class control-class
pvc-bundle sf-premium 306
class premium-class
pvc-bundle sf-priority 304
pvc-bundle sf-basic 301
class basic-class
bundle los-angeles
protocol ip 10.16.1.4 broadcast
inarp 1
class bundle-class
pvc-bundle la-high 407
precedence 7-5
protect vc
class premium-class
pvc-bundle la-mid 404
precedence 4-2
protect group
pvc-bundle la-low 401
precedence other
protect group
class basic-class
/* PVC la-other is a standalone VC and does not belong to any of the bundles. */
pvc la-other 400
no protocol ip inarp
broadcast
Configuration Example for MPLS EXP-Based ATM PVC Selection

Example 19-2 shows how to configure MPLS experimental (EXP)-based ATM PVC selection. The
sample configuration adds PVCs 0/306, 0/304, and 0/301 to the ATM PVC bundle named router2 and
specifies the MPLS experimental bit values to map to each of the PVC bundle members.
Example 19-2 Configuring MPLS EXP-Based ATM PVC Selection
interface ATM1/0/0 point-to-point
mpls label protocol ldp
tag-switching ip
bundle router2
pvc-bundle atm-premium 0/306
mpls experimental 5-7
pvc-bundle atm-priority 0/304
mpls experimental 3-4
pvc-bundle atm-basic 0/301
mpls experimental other

The Cisco 10000 router can forward packets to Frame Relay bundle members based on the IP precedence
level, differentiated services code point (DSCP) level, or the Multiprotocol Label Switching (MPLS)
experimental (EXP) level of the packets.

OL-7433-09
19-31
Chapter 19
The Frame Relay PVC Bundles with QoS Support for IP and MPLS feature allows you to configure
multiple PVCs with different QoS characteristics between any pair of Frame Relay-connected routers
and to configure a group of Frame Relay PVCs with a single next-hop address. Packets are mapped to
specific PVCs in the bundle on the basis of the precedence level, differentiated services code point
(DSCP) level, or MPLS EXP level in the type of service (ToS) field of the IP header. Each packet is
treated differently according to the QoS configured for each PVC.
The Frame Relay PVC bundle management software provides flexible PVC management within a PVC
bundle by allowing traffic assigned to a failed PVC to be redirected to an alternate PVC within the
bundle. It also allows you to configure the bundle to go down when certain PVCs go down. IP packets
carrying different types of traffic can be transported on different PVCs within the same PVC bundle.
To determine which PVC in a bundle is used to forward a specific type of traffic, the Frame
Relay PVC bundle management software matches the IP precedence level, DSCP level, or MPLS EXP
level in the IPv4 header to a PVC configured with the same value. The bundle management software
sends the packet out on the PVC with the same value.
After you define a Frame Relay bundle and add PVCs to it, you can configure attributes and
characteristics to discrete PVC bundle members, or you can apply them collectively at the bundle level.
You can apply Frame Relay traffic shaping to each PVC within a bundle.
You can create differentiated service using PVC bundles by distributing IP precedence levels or DSCP
values over the various bundle members. You can map a single precedence level or DSCP value or a
range of precedence or DSCP levels to each PVC in the bundle. This enables you to either limit an
individual PVC to carry only packets marked with a specific precedence or DSCP level, or enable a PVC
to carry packets marked with different precedence or DSCP levels.
The bundle management software also allows you to configure how traffic is redirected if a PVC goes
down. If this occurs, the router attempts to identify an alternate PVC. If the router cannot locate an
alternate PVC, the router stops the PVC bundle.
The router forwards non-IP packets using the PVC that is responsible for carrying precedence level 6 or
DSCP level 63 traffic. The router uses process-switching to forward locally generated packets.
Feature History for Frame Relay PVC Selection

Cisco IOS Release
Description
Required PRE
Release 12.0(26)S
The Frame Relay PVC Bundles with QoS Support for IP

and MPLS feature was introduced on the PRE1.
PRE1
Configuration Commands for Frame Relay PVC Selection

This section describes the following configuration commands:
bump Command (Frame Relay VC-bundle-member), page 19-33
dscp Command (Frame Relay VC-bundle-member), page 19-34
exp Command, page 19-35
frame-relay vc-bundle Command, page 19-36
precedence Command (Frame Relay VC-bundle-member), page 19-37
protect Command (Frame Relay VC-bundle-member), page 19-38
pvc Command (Frame Relay VC-bundle), page 19-39
19-32
OL-7433-09
Chapter 19

bump Command (Frame Relay VC-bundle-member)

To configure the bumping rules for a Frame Relay permanent virtual circuit (PVC) bundle member, use
the bump command in Frame Relay VC-bundle-member configuration mode.To specify that the PVC
bundle member does not accept any bumped traffic, use the no bump traffic command. (The no bump
explicit and no bump implicit commands have no effect.)
bump {explicit level | implicit | traffic}
no bump traffic
Syntax Description
explicit level
Specifies the precedence, MPLS experimental (EXP), or differentiated

services code point (DSCP) level to which traffic on a PVC is bumped when
the PVC goes down. For PVC bundles that use precedence or MPLS EXP
mapping, valid values for the level argument are from 0 to 7. For PVC
bundles that use DSCP mapping, valid values are from 0 to 63.
implicit
Applies the implicit bumping rule, which is the default, to a single PVC
bundle member. The implicit bumping rule stipulates that bumped traffic is
to be carried by a PVC that has the lower precedence level.
traffic
Specifies that the PVC accepts bumped traffic (the default condition). The
no form stipulates that the PVC does not accept any bumped traffic.
bump Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
Implicit bumping
Bumping permitted (PVCs accept bumped traffic)
Configuration Mode
Frame Relay VC-bundle-member configuration
Usage Guidelines for the bump Command

Use the bump command to configure bumping rules for a discrete PVC bundle member. To change the
configured bumping rules for a PVC bundle member, override the current configuration with a new
bump command entry.
To return to the default condition of implicit bumping, use the bump implicit command.
If you configure implicit bumping, bumped traffic is sent to the PVC configured to handle the next lower
service level. When the original PVC that bumped the traffic comes back up, it resumes transmission of
the configured service level. When the bump explicit command is not configured, the bump implicit
command takes effect by default; however, the bump implicit command does not appear in the output
of the show running-config and show startup-config commands.

OL-7433-09
19-33
Chapter 19
If you configure a PVC with the bump explicit command, you can specify the service level to which
traffic is bumped when that PVC goes down, and the traffic is directed to a PVC mapped with that level.
If the PVC that picks up and carries the traffic goes down, the traffic is subject to the bumping rules for
that PVC. You can specify only one service level for bumping.
The PVC accepts bumped traffic by default. If the PVC has been previously configured to reject bumped
traffic, you must use the bump traffic command to return the PVC to its default condition.
To configure a discrete PVC to reject bumped traffic when the traffic is directed to it, use the no bump
traffic command.
Note
When no alternative PVC can be found to handle bumped traffic, even when there are no packets of that
traffic type present, the bundle is declared down. In the case where default (implicit) bumping is used
for all PVCs, the PVC that is handling the lowest service level can be configured to bump explicitly to
a PVC handling a higher service level.
dscp Command (Frame Relay VC-bundle-member)

To configure the differentiated services code point (DSCP) levels for a Frame Relay permanent virtual
circuit (PVC) bundle member, use the dscp command in Frame Relay VC-bundle-member configuration
mode. To remove the DSCP level configuration from the PVC, use the no form of the command.
dscp {level | other}
no dscp level
Syntax Description
level
Specifies the DSCP level or levels for this Frame Relay PVC bundle
You can configure a PVC bundle member with a single DSCP level (9),
multiple individual DSCP levels (25,35,45), a range of DSCP levels
(25-35), multiple ranges of DSCP levels (25-35,45-55), or a combination of
individual levels and level ranges (10,20,25-35,40,45-55,60).
Note
This command is available when the PVC bundle match type is set
to dscp. By default, the PVC members are configured to reject
bumping when the match-type is dscp.
other
Specifies that this Frame Relay PVC bundle member handles all of the
remaining DSCP levels that are not explicitly configured on any other
bundle members.
Cisco IOS Release
Description
Release 12.0(26)S
dscp Command History
Defaults
DSCP levels are not configured.
19-34
OL-7433-09
Chapter 19

Configuration Mode
Usage Guidelines for the dscp Command

Assignment of DSCP levels to PVC bundle members allows you to create differentiated service because
you can distribute the DSCP levels over the various PVC bundle members. You can map a single DSCP
level or range of levels to each discrete PVC in the bundle, thereby enabling PVCs in the bundle to carry
packets marked with different DSCP levels. Use the dscp other command to configure a PVC to carry
traffic marked with DSCP levels not specifically configured on other PVCs. Only one PVC in the bundle
can be configured with the dscp other command.
This command is available only when the match type for the PVC bundle is set to dscp using the match
dscp command in Frame Relay VC-bundle configuration mode.
You can overwrite the DSCP level configuration on a PVC by re-entering the dscp command with a new
level value.
There is no default value for this command.
When the PVC bundle is set to dscp using the match dscp command, all PVCs in the bundle are reset to
remove any existing DSCP values. If one or more DSCP values are not specifically configured, the
bundle does not come up.
Note, however, that a PVC may exist in a bundle but have no DSCP value associated with it. As long as
all valid DSCP values are handled by one or more of the other PVCs in the bundle, the bundle can come
up, but the PVC that has no DSCP value configured does not participate in it.
A DSCP level can be configured on one PVC-bundle member per bundle. If you configure the same
DSCP level on more than one PVC within a bundle, the following message appears on the console:
%Overlapping diff-serv code points
exp Command
To configure Multiprotocol Label Switching (MPLS) experimental (EXP) levels for a Frame Relay
permanent virtual circuit (PVC) bundle member, use the exp command in Frame Relay
VC-bundle-member configuration mode. To remove the EXP level configuration from the PVC, use the
no form of the command.
exp {level | other}
no exp
Syntax Description
level
Specifies the MPLS EXP level or levels for a Frame Relay PVC bundle
member. Valid values are from 0 to 7. You can configure a PVC bundle
member with a single MPLS EXP level (0), multiple individual MPLS EXP
levels (0,2,3), a range of MPLS EXP levels (0-2), multiple ranges of MPLS
EXP levels (0-2,4-5), or a combination of individual levels and level ranges
(0,1,2-4,7).
other
Specifies that the Frame Relay PVC bundle member handles all of the
remaining MPLS EXP levels that are not explicitly configured on any other
bundle member PVCs.

OL-7433-09
19-35
Chapter 19
exp Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
EXP levels are not configured.
Configuration Mode
Frame-Relay VC-bundle-member configuration
Usage Guidelines for the exp Command

Assignment of MPLS EXP levels to Frame Relay PVC bundle members allows you to create
differentiated service because you can distribute the levels over the various PVC bundle members. You
can map a single level or a range of levels to each discrete PVC in the bundle, thereby enabling PVCs in
the bundle to carry packets marked with different levels. Use the exp other command to indicate that a
PVC can carry traffic marked with EXP levels not specifically configured for other PVCs. Only one PVC
in the bundle can be configured using the exp other command.
All MPLS EXP levels must be accounted for in the PVC bundle configuration, or the bundle does not
come up. Note, however, that a PVC may be a bundle member but have no MPLS EXP level associated
with it. As long as all valid MPLS EXP levels are handled by other PVCs in the bundle, the bundle can
come up, but the PVC that has no MPLS EXP level configured does not participate in it.
The exp command is available only when tag-switching is configured on the interface with the
tag-switching ip command.
You can overwrite the EXP level configuration on a PVC by re-entering the exp command with a new
value.
The MPLS experimental bits are a bit-by-bit copy of the IP precedence bits. When Frame Relay PVC
bundles are configured for IP precedence and tag-switching is enabled, the precedence command is
replaced by the exp command. When tag-switching is disabled, the exp command is replaced by the
precedence command.
frame-relay vc-bundle Command

To create a Frame Relay permanent virtual circuit (PVC) bundle if it does not already exist, and to enter
Frame Relay VC-bundle configuration mode, use the frame-relay vc-bundle command in interface
configuration mode. To remove a Frame Relay PVC bundle, use the no form of the command.
frame-relay vc-bundle vc-bundle-name
no frame-relay vc-bundle vc-bundle-name
Syntax Description
vc-bundle-name
User-defined name of this Frame Relay PVC bundle.
19-36
OL-7433-09
Chapter 19

frame-relay vc-bundle Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
A bundle is not created.
Configuration Mode
Interface configuration
Usage Guidelines for the frame-relay vc-bundle Command

Use this command to create a unique Frame Relay PVC bundle if one has not already been created using
the frame-relay map command. Also, use this command to enter Frame Relay VC-bundle configuration
mode so you can configure PVC bundle attributes and PVC bundle members.
precedence Command (Frame Relay VC-bundle-member)

To configure the precedence levels for a Frame Relay permanent virtual circuit (PVC) bundle member,
use the precedence command in Frame Relay VC-bundle-member configuration mode. To remove the
precedence level configuration from the PVC, use the no form of the command.
precedence {level | other}
no precedence
Syntax Description
level
Specifies the precedence level or levels for this Frame Relay PVC bundle
You can configure a PVC bundle member with a single precedence level (0),
multiple individual precedence levels (0,2,3), a range of precedence levels
(0-2), multiple ranges of precedence levels (0-2,4-5), or a combination of
individual levels and level ranges (0,1,2-4,7).
Note
other
This command is available when the PVC bundle match type is set
to precedence.
Specifies that this Frame Relay PVC bundle member handles all of the
remaining precedence levels that are not explicitly configured on any other
bundle members.
Note
Critical non-IP traffic automatically uses precedence level 0.
precedence Command History

Cisco IOS Release
Description
Release 12.0(26)S

OL-7433-09
19-37
Chapter 19
Defaults
Precedence levels are not configured.
Configuration Mode
Usage Guidelines for the precedence Command

Assignment of precedence levels to PVC bundle members allows you to create differentiated service
because you can distribute the IP precedence levels over the various PVC bundle members. You can map
a single precedence level or a range of levels to each discrete PVC in the bundle, thereby enabling PVCs
in the bundle to carry packets marked with different precedence levels. Use the precedence other
command to indicate that a PVC can carry traffic marked with precedence levels not specifically
configured for other PVCs. Only one PVC in the bundle can be configured using the precedence other
command.
This command is available only when the match type for the PVC bundle is set to precedence using the
match precedence command in Frame Relay VC-bundle configuration mode.
You can overwrite the precedence level configuration on a PVC by re-entering the precedence command
with a new level value.
All precedence levels must be accounted for in the PVC bundle configuration, or the bundle does not
come up. Note, however, that a PVC may be a bundle member but have no precedence level associated
with it. As long as all valid precedence levels are handled by other PVCs in the bundle, the bundle can
come up, but the PVC that has no precedence level configured does not participate in it.
A precedence level can be configured on one PVC bundle member per bundle. If you configure the same
precedence level on more than one PVC within a bundle, the following message appears on the console:
%Overlapping precedence levels
When tag-switching is enabled on the interface by using the tag-switching ip command, MPLS and IP
packets can flow across the interface, and PVC bundles that are configured for IP precedence mapping
are converted to MPLS EXP mapping. The PVC bundle functionality remains the same with respect to
priority levels, bumping, and so on, but the match precedence command is replaced by the match exp
command, and each precedence command is replaced by the exp command. The result is that a
bundle-member PVC previously configured to carry precedence level 1 IP traffic now carries EXP
level 1 MPLS traffic.
When tag-switching is disabled, the match precedence and match dscp commands are restored, and the
exp commands are replaced by precedence commands.
When tag-switching is enabled or disabled, PVC bundles configured for IP precedence mapping or
MPLS EXP mapping stay up, and traffic is transmitted over the appropriate bundle-member PVCs.
protect Command (Frame Relay VC-bundle-member)

To configure a Frame Relay protected permanent virtual circuit (PVC) bundle member with protected
group or protected PVC status, use the protect command in Frame Relay VC-bundle-member
configuration mode. To remove the protected status from the PVC, use the no form of the command.
protect {group | vc}
no protect {group | vc}
19-38
OL-7433-09
Chapter 19

Syntax Description
group
Configures the PVC bundle member as part of a collection of protected

PVCs within the PVC bundle and specifies that the PVC bundle goes down
when the last PVC in the protected group goes down.
vc
Configures the PVC member as individually protected and specifies that the
PVC bundle goes down whenever the PVC goes down.
protect Command History

Cisco IOS Release
Description
Release 12.0(26)S
Defaults
The PVC neither belongs to the protected group nor is an individually protected PVC.
Configuration Mode
Usage Guidelines for the protect Command

When an individually protected PVC goes down, it takes the bundle down. When all members of a
protected group go down, the bundle goes down.
Despite any protection configurations, the PVC bundle goes down if a downed PVC has no PVC to which
to bump its traffic or if the last PVC that is up in a PVC bundle goes down.
pvc Command (Frame Relay VC-bundle)

To create a permanent virtual circuit (PVC) that is a Frame Relay PVC bundle member, and to enter
Frame Relay VC-bundle-member configuration mode, use the pvc command in Frame Relay VC-bundle
configuration mode. To delete the PVC from the Frame Relay PVC bundle, use the no form of the
command.
pvc dlci [vc-name]
no pvc dlci [vc-name]
Syntax Description
dlci
Data-link connection identifier (DLCI) number used to identify the PVC.
vc-name
(Optional) An alphanumeric name for the PVC.
Cisco IOS Release
Description
Release 12.0(26)S
pvc Command History

OL-7433-09
19-39
Chapter 19
Defaults
No PVC is defined.
Configuration Mode
Frame Relay VC-bundle configuration
Usage Guidelines for the pvc Command

To use this command, you must first create a Frame Relay PVC bundle and enter Frame Relay
VC-bundle configuration mode.
A PVC bundle must have at least one PVC for the bundle to come up. A PVC bundle cannot have more
than eight PVCs. If you try to configure more than eight PVCs in a bundle, the following message
appears on the console:
%FR vc-bundle contains 8 members. Cannot add another.
Dynamic PVCs can be specified as PVC bundle members; however, if a PVC has already been created
by using some other configuration command, you cannot add it to a PVC bundle. If you try to add it to
a bundle, the following message appears on the console:
%DLCI 200 is not a dynamic PVC. Cannot add to VC-Bundle.
If a PVC is already a member of a PVC bundle, any attempt to reuse that same PVC in a command that
creates a PVC (for example, frame-relay interface-dlci, frame-relay local-dlci) results in the
following error message:
%Command is inapplicable to vc-bundle PVCs.
Service Levels and PVC Selection Criteria

The DSCP and precedence bits classify the IP packet service levels. The Precedence field consists of the
first three bits of the ToS octet in the IPv4 header. You can use these bits to define a maximum of eight
service levels. When you use DSCP mapping, the DSCP octet replaces the ToS octet in the IPv4 header.
The first six bits are used to define a maximum of 64 service levels.
Using precedence-based or DSCP-based mapping, the router maps each IPv4 packet to a specific PVC
in the bundle, according to the value of the ToS or DSCP octet in the IP header. There is no special
treatment for broadcast or multicast and IP routing packets; the only differentiation in treatment is a
result of the ToS or DSCP octet settings.
Prerequisites for Frame Relay PVC Selection
The Cisco 10000 series router must be running Cisco IOS Release 12.0(26)S or later releases.
To implement Frame Relay PVC bundles between two routers, you must enable IP Cisco Express
Forwarding (CEF) switching on the routers.
19-40
OL-7433-09
Chapter 19

Restrictions and Limitations for Frame Relay PVC Selection

PVCs
In Cisco IOS Release 12.0(26)S, the Frame Relay implementation of VC bundles is restricted to
PVCs.
You can configure a maximum of eight PVCs in a PVC bundle.
A PVC can be a member of one and only one PVC bundle.
A PVC that is a bundle member cannot be used in any other capacity. For example, you cannot
configure a PVC bundle member in a map statement.
The Cisco 10000 router does not support variable bit rate-real-time (VBR-rt) for PVCs.
VC Selection
A PVC bundle does not come up until you configure all of the precedence or DSCP levels in the
bundle.
You can map one or multiple precedence or DSCP levels to a single PVC; however, you cannot map
multiple PVCs to one precedence or DSCP level.
The Cisco 10000 router does not support the auto-mapping of PVCs.
Packet Forwarding
The Cisco 10000 router does not support fast switching of IP packets.
Configuring Frame Relay Bundles

To configure Frame Relay bundles, perform the following configuration tasks:
Creating a Frame Relay PVC Bundle, page 19-42
Adding a PVC to a Frame Relay PVC Bundle, page 19-43

OL-7433-09
19-41
Chapter 19
Creating a Frame Relay PVC Bundle

To create a Frame Relay PVC bundle, enter the following commands beginning in interface
configuration mode:
Step 1
Command
Purpose

Specifies the interface that you want to add to the MLP bundle.
Enters interface configuration mode.
required.
Step 2
Router(config-if)# ip address ip-address

mask [secondary]
Specifies a primary IP address for the interface.

ip-address is the IP address of the interface.
mask is the subnet mask for the IP address.
(Optional) secondary indicates that the address specified is the
secondary IP address. If you omit the secondary keyword, the
address you specify is the primary IP address.
Step 3
frame-relay [cisco | ietf]
Enables Frame Relay encapsulation for the interface.

Use this keyword when connecting to another vendors
equipment across a Frame Relay network.
19-42
OL-7433-09
Chapter 19

Step 4
Command
Purpose
Router(config-if)# frame-relay map

protocol protocol-address {dlci |
vc-bundle vc-bundle-name} [broadcast]
[ietf] [cisco]
(Optional) Maps between a next-hop protocol address and a data

link connection identifier (DLCI) destination address, and
creates a PVC bundle if it does not already exist.
protocol is ip or ipx.
protocol-address is the destination IP address.
dlci is the local DLCI number used to connect to the specified
protocol address on the interface. Valid values are from 16
through 1007.
vc-bundle vc-bundle-name is the name of a specific Frame Relay
PVC bundle configured on the interface.
(Optional) broadcast indicates to forward broadcasts to the
specified address when multicast is not enabled (see the
frame-relay multicast-dlci command for more information
about multicasts).
(Optional) ietf is the Internet Engineering Task Force (IETF)
form of Frame Relay encapsulation, based on RFC 1490 and
RFC 2427. Use the ietf keyword when the router is connected to
another vendor's equipment across a Frame Relay network.
(Optional) cisco is the Cisco-proprietary encapsulation method
consisting of a four-byte header, with two bytes to identify the
DLCI and two bytes to identify the packet type.
Note
Step 5
Router(config-if)# frame-relay vc-bundle

vc-bundle-name
The frame-relay map command is required for

multipoint interfaces if Inverse ARP is disabled or is not
supported at the other end of the connection.
Creates a PVC bundle if it does not already exist. Enters Frame

Relay VC bundle configuration mode.
vc-bundle-name is a name you assign to the Frame Relay PVC
bundle to identify the bundle.
Configuration Example for Creating a Frame Relay PVC Bundle

Example 19-3 shows how to create a Frame Relay PVC bundle. In the example, the PVC bundle is named
vermont.
Example 19-3 Creating a Frame Relay PVC Bundle
Router(config)# interface serial 0
Router(config-if)# ip address 10.1.1.1
Router(config-if)# frame-relay vc-bundle vermont
Adding a PVC to a Frame Relay PVC Bundle

To add a PVC to a Frame Relay PVC bundle, enter the following commands beginning in global
configuration mode:

OL-7433-09
19-43
Chapter 19
Step 1
Command
Purpose


configuration mode.
required.
Step 2

vc-bundle-name
Creates or modifies a PVC bundle. Enters Frame Relay VC

bundle configuration mode.
Step 3
Router(config-fr-vcb)# pvc dlci [vc-name]
Creates a PVC bundle member and enters Frame Relay VC

bundle member configuration mode.
dlci is the local data-link connection identifier (DLCI).
vc-name is a name that identifies the PVC.
Configuration Example for Adding a PVC to a Frame Relay PVC Bundle

Example 19-4 shows how to add a PVC to a Frame Relay PVC bundle. In the example, the PVC named
Bronze (DLCI 100) is added to the Frame Relay PVC bundle named Business.
Example 19-4 Creating a PVC Bundle Member
Router(config-if)# frame-relay vc-bundle Business
Router(config-fr-vcb)# pvc 100 Bronze
Configuring Frame Relay Bundle Members

You can configure a Frame Relay bundle member directly or by associating a Frame Relay map class to
the bundle member. The parameter values that you apply directly to the bundle member supersede the
parameter values that you apply using a map class.
To apply parameters to a PVC bundle, perform either of the following configuration tasks:
Configuring a Frame Relay Bundle Member Directly, page 19-44
Configuring a Frame Relay Bundle Member Using a Map Class, page 19-48
Configuring a Frame Relay Bundle Member Directly

You can configure a Frame Relay bundle member directly or by associating a Frame Relay map class to
the bundle member. The parameter values that you apply manually to the bundle member supersede the
parameter values that you apply using a map class.
Note
We recommend that you configure a PVC bundle on the peer router, especially for applications that rely
on communications on the same PVC (for example, TCP header compression).
19-44
OL-7433-09
Chapter 19

To configure an individual Frame Relay bundle member directly, enter the following commands
Step 1
Command
Purpose


configuration mode.
required.
Step 2

vc-bundle-name

Step 3
Router(config-fr-vcb)# encapsulation [ietf

| cisco]
(Optional) Overrides the encapsulation type you configured on

the interface and configures the Frame Relay encapsulation type
for the PVC bundle.
(Optional) ietf is the Internet Engineering Task Force (IETF)
form of Frame Relay encapsulation, based on RFC 1490 and
RFC 2427. Use the ietf keyword when the router is connected to
another vendor's equipment across a Frame Relay network.
(Optional) cisco is the Cisco-proprietary encapsulation method
consisting of a four-byte header, with two bytes to identify the
DLCI and two bytes to identify the packet type.
Note
Step 4
Router(config-fr-vcb)# match {dscp |

precedence}
Sets the type of matching to use between incoming packet

headers and PVC bundle members. The default match type is
precedence.
Note
Step 5
This command is available only when the PVC bundle is

configured on a point-to-point subinterface. The router
does not support this command for multipoint interfaces.
The Cisco 10000 series router uses the type of matching

you specify to map each IPv4 packet to a specific PVC in
the bundle, according to the value of the ToS or DSCP
octet in the IP header.
Creates or modifies a bundle member. Enters Frame Relay VC

(Optional) vc-name is a name that identifies the PVC.

OL-7433-09
19-45
Chapter 19
Step 6
Command
Purpose
Router(config-fr-vcb-vc)# precedence
{level | other}
(Optional) Configures the precedence levels for a Frame Relay

PVC bundle member. This command configures
precedence-based PVC selection.
level specifies the precedence level or levels for this Frame Relay
PVC bundle member. Valid values are from 0 to 7.
You can configure a PVC bundle member with a single
precedence level (0), multiple individual precedence levels
(0,2,3), a range of precedence levels (0-2), multiple ranges of
precedence levels (0-2,4-5), or a combination of individual levels
and level ranges (0,1,2-4,7).
Note

type is set to precedence.
other specifies that this Frame Relay PVC bundle member

handles all of the remaining precedence levels that are not
explicitly configured on any other bundle members.
Note
Step 7
Router(config-fr-vcb-vc)# dscp {level |

other}
Critical non-IP traffic automatically uses precedence

level 0.
(Optional) Configures the differentiated services code point

(DSCP) levels for a Frame Relay PVC bundle member. This
command configures DSCP-based PVC selection.
level specifies the DSCP level or levels for this Frame Relay
PVC bundle member. Valid values are from 0 to 63.
You can configure a PVC bundle member with a single DSCP
level (9), multiple individual DSCP levels (25,35,45), a range of
DSCP levels (25-35), multiple ranges of DSCP levels
(25-35,45-55), or a combination of individual levels and level
ranges (10,20,25-35,40,45-55,60).
Note

type is set to dscp. By default, the PVC members are
configured to reject bumping when the match-type is
dscp.
other specifies that this Frame Relay PVC bundle member

handles all of the remaining DSCP levels that are not explicitly
configured on any other bundle members.
19-46
OL-7433-09
Chapter 19

Step 8
Command
Purpose
Router(config-fr-vcb-vc)# exp {level |

other}

experimental (EXP) levels for a Frame Relay PVC bundle
member. This command configures MPLS EXP-based PVC
selection.
level specifies the MPLS EXP level or levels for a Frame Relay
PVC bundle member. Valid values are from 0 to 7. You can
configure a PVC bundle member with a single MPLS EXP level
(0), multiple individual MPLS EXP levels (0,2,3), a range of
MPLS EXP levels (0-2), multiple ranges of MPLS EXP levels
(0-2,4-5), or a combination of individual levels and level ranges
(0,1,2-4,7).
other specifies that the Frame Relay PVC bundle member
handles all of the remaining MPLS EXP levels that are not
explicitly configured on any other bundle member PVCs.
Step 9
Router(config-fr-vcb-vc)# bump
{explicit level | implicit | traffic}
(Optional) Configures the bumping rules for a Frame Relay PVC

bundle member. The default is implicit bumping.
explicit level specifies the precedence, MPLS experimental
(EXP), or differentiated services code point (DSCP) level to
which traffic on the PVC is bumped if the PVC goes down. You
can specify only one service level for bumping. For PVC bundles
that use precedence or MPLS EXP mapping, valid values for
level are from 0 to 7. For PVC bundles that use DSCP mapping,
valid values are from 0 to 63.
Note
When the PVC goes down, the router directs the traffic to
a PVC mapped with the service level you configure in
explicit level.

to a single bundle member. The implicit bumping rule stipulates
that bumped traffic is to be carried by a PVC that has the lower
precedence level.
traffic specifies that the PVC accepts bumped traffic. By default,
a PVC accepts bumped traffic.
Note
Step 10
Router(config-fr-vcb-vc)# protect
{group | vc}

(Optional) Specifies the protection rule for a PVC bundle

member. By default, the PVC bundle member is not protected.
group configures the PVC bundle member as part of a collection
of protected PVCs within the PVC bundle and specifies that the
PVC bundle goes down when the last PVC in the protected group
goes down.
vc configures the PVC member as individually protected and
specifies that the PVC bundle goes down whenever the PVC goes
down.
Step 11
Router(config-fr-vcb-vc)# inarp
(Optional) Enables Inverse ARP for the PVC bundle member. By

default, Inverse ARP traffic uses the PVC configured for
precedence level 6 or DSCP level 63.

OL-7433-09
19-47
Chapter 19
Configuration Example for Configuring a Frame Relay Bundle Member Directly

Example 19-5 shows how to configure a Frame Relay bundle member directly. In the example, a VC
bundle named maine is created and precedence is set as the type of matching to use between incoming
packet headers and PVC bundle members. The PVC named Premium (DLCI 100) has precedence, bump,
protect, and inarp parameters applied to it. The PVC is a bundle member of the maine PVC bundle.
Example 19-5 Configuring a Frame Relay Bundle Member
Router(config-if)# frame-relay vc-bundle maine
Router(config-fr-vcb)# encapsulation ietf
Router(config-fr-vcb)# match precedence
Router(config-fr-vcb)# pvc 100 Premium
Router(config-fr-vcb-vc)# precedence 6-7
Router(config-fr-vcb-vc)# bump explicit 7
Router(config-fr-vcb-vc)# protect group
Router(config-fr-vcb-vc)# inarp
Configuring a Frame Relay Bundle Member Using a Map Class

You can use a Frame Relay map class to apply multiple attributes to PVC bundle members at the same
time. The map class parameters apply to all of the PVC bundle members to which you associate the map
class.
To configure a Frame Relay bundle member using a map class, enter the following commands beginning
in interface configuration mode:
Step 1
Command
Purpose


configuration mode.
slot/module/port is the number that identifies the line card. The
slashes are required.
Step 2

vc-bundle-name

Step 3
Creates a PVC bundle member and enters Frame Relay VC

vc-name is a name that identifies the PVC.
Step 4
Router(config-fr-vcb-vc)# class class-name
Associates a map class with a PVC bundle member.

class-name is the name of the map class.
Configuration Example for Configuring a Frame Relay Bundle Member Using a Map Class
Example 19-6 shows how to configure a bundle member using a map class. In the example, the PVC
bundle named Gold is created. The map class named East is applied to the PVC bundle member named
member1 (DLCI 100).
19-48
OL-7433-09
Chapter 19

Example 19-6 Configuring a Frame Relay Bundle Member Using a Map Class
Router(config-if)# frame-relay vc-bundle Gold
Router(config-fr-vcb)# pvc 100 member1
Router(config-fr-vcb-vc)# class East
Configuration Examples for Configuring Frame Relay Bundles and PVC

Selection
Configuration Example for Precedence-Based and DSCP-Based Frame Relay PVC Selection,
page 19-49
Configuration Example for MPLS EXP-Based Frame Relay PVC Selection, page 19-50
Configuration Example for Precedence-Based and DSCP-Based Frame Relay PVC Selection
Example 19-7 shows how to directly configure Frame Relay PVC selection based on the packets
precedence or DSCP level. The sample configuration creates two PVC bundles on a multipoint
subinterface. The PVC bundle named new-york has four members and supports precedence mapping.
The PVC bundle named san-jose has three members and supports DSCP mapping. The example uses
arbitrary DSCP ranges.
Example 19-7 Configuring Precedence-Based and DSCP-Based PVC Selection
interface serial 0.1 multipoint
/* Create a VC bundle map entry for the next hop IP address*/
frame-relay map ip 10.16.0.2 vc-bundle new-york
frame-relay map ip 12.0.0.2 vc-bundle san-jose
frame-relay vc-bundle new-york
match precedence
/* Create the PVCs for VC bundle new-york*/
pvc 100 ny-control
class control
precedence 7
protect vc
pvc 101 ny-premium
class premium
precedence 5-6
protect group
no bump traffic
bump explicit 7
pvc 102 ny-priority
class priority
precedence 2-4
protect group
pvc 103 ny-basic
class basic
precedence other
protect group
frame-relay vc-bundle san-jose
match dscp
pvc 200
class control
dscp 63-60
no bump traffic
protect vc

OL-7433-09
19-49
Chapter 19
pvc 201
class premium
dscp 31-24
protect group
pvc 202
class basic
dscp other
protect group
Configuration Example for MPLS EXP-Based Frame Relay PVC Selection

Example 19-8 shows how to configure MPLS experimental (EXP)-based Frame Relay PVC selection.
The sample configuration adds PVCs 101 and 100 to the PVC bundle named router2 and configures the
MPLS EXP levels for each PVC bundle member.
Example 19-8 Configuring MPLS EXP-Based Frame Relay PVC Selection
interface serial8/0/0
mpls label protocol ldp
tag-switching ip
frame-relay vc-bundle router2
pvc 101
exp 0,2,7
pvc 100
exp other
Verifying and Monitoring Frame Relay PVC Selection

To verify and monitor the configuration and operation of Frame Relay PVC selection, enter any of the
following commands in privileged EXEC configuration mode:
19-50
OL-7433-09
Chapter 19

Command
Purpose
Router# debug frame-relay adjacency {pvc [dlci] |

vc-bundle [vc-bundle-name]}
Displays information about an adjacent node that has one or more

Frame Relay PVCs or PVC bundles.
pvc indicates to display information about the adjacent PVC only.
(Optional) dlci is the data-link connection identifier (DLCI) for a
specific PVC.
vc-bundle indicates to display information regarding the adjacent
PVC bundle and its members.
(Optional) vc-bundle-name is the name of the PVC bundle.
Router# debug frame-relay vc-bundle {detail |

state-change} [vc-bundle-name]
Displays information about the Frame Relay PVC bundles

configured on a router.
Use this command to monitor state changes and Inverse ARP
activity for one or all of the PVC bundles and bundle members
configured on a router.
detail indicates to display detailed information about the
members of the specified bundle. If you do not specify a
vc-bundle-name, detailed information about the members of all
PVC bundles displays.
Note
Using the detail keyword generates a large number of

debug messages that can quickly fill up a log buffer.
state-change indicates to display information pertaining only to

the state changes of the specified PVC bundle and PVC bundle
members. If you do not specify a vc-bundle-name, state-change
information for all PVC bundles and bundle members displays.
(Optional) vc-bundle-name specifies a particular PVC bundle.
Router# show frame-relay vc-bundle
{vc-bundle-name] [detail]
Displays status, bumping information, protection information,

and active and configured precedence or DSCP levels for the
PVCs in a PVC bundle.
vc-bundle-name is the name of the Frame Relay PVC bundle.
detail displays output packet count information in addition to the
other bundle member attributes for each PVC in the bundle.
Router# show frame-relay map
Displays the current Frame Relay map entries and information

about the connections.
Router# show frame-relay pvc
Displays PVC statistics for the PVC-bundle members.
Router# show frame-relay ip rtp

header-compression [interface type number]
Displays Frame Relay Real-Time Transport Protocol (RTP)

header compression statistics.
(Optional) interface type number specifies the interface type and
number.

OL-7433-09
19-51
Chapter 19
Command
Purpose
Router# show frame-relay ip tcp

header-compression [interface type number]
Displays statistics and TCP/IP header compression information

for an interface.
(Optional) interface type number specifies the interface type and
number.
Router# show adjacency [summary [type number]]

[detail]
Displays information about the Cisco Express Forwarding (CEF)

adjacency table or the hardware Layer 3-switching adjacency
table.
(Optional) summary displays a summary of CEF adjacency
information.
(Optional) type number specifies the type and number of the
interface (for example, serial 1/0/0).
(Optional) detail displays the protocol detail and timer
information.
Verification Example for Monitoring PVC Bundles

Example 19-9 shows sample out from the show frame-relay vc-bundle command.
Example 19-9 Sample Output for the show frame-relay vc-bundle Command
Router# show frame-relay vc-bundle new-york
new-york on serial 0.1 - Status: UP Match-type: Precedence
Config.ActiveBumpingPG/CIR
NameDLCILevelLevelto/acceptPVkbpsStatus
ny-control100774/Yespv 56 up
ny-premium1016-56-57/Nopg256up
ny-priority1024-24-21/Yespg512up
ny-basic*1031-01-0-/Yespg256up
* Indicates that this VC is responsible for carrying unmapped traffic.
19-52
OL-7433-09
Chapter 19

Feature
ATM PVC bundles
ATM VC Bundle Management on Cisco 12000 Series 8-Port OC-3 STM-1 ATM
Line Cards, Release 12.0(23)S feature module
Understanding and Configuring ATM PVC Bundles sample configurations
Part 7: Quality of Service Solutions > IP to ATM CoS Overview > VC Bundle
Support and Bundle Management
ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection,
ATM VC Bundle Management on Cisco 12000 Series 8-Port OC-3 STM-1 ATM
Line Cards, Release 12.0(23)S feature module
IP to ATM Class of Service, Release 12.0(3)T feature module
Bumping and bundle protection
Understanding PVC Bundle Bumping and Protection tech note

Part 7: Quality of Service Solutions > IP to ATM CoS Overview > Bumping
and ATM VC Bundles
PVC Bundle Protection tech note
Frame Relay PVC bundles
Frame Relay PVC Bundles with QoS Support for IP and MPLS, Release 12.2(13)T
feature module
MPLS experimental (EXP)

Marking Traffic > MPLS Experimental Marking
ATM PVC Bundle Enhancement MPLS EXP-Based PVC Selection,
Cisco IP Solution Center Quality of Service User Guide, 3.0
Quality of Service Concepts > MPLS Experimental Values

OL-7433-09
19-53
Chapter 19
19-54
OL-7433-09
CH A P T E R
20

Multiprotocol label switching (MPLS) combines the performance and capabilities of Layer 2 (data link
layer) switching with the proven scalability of Layer 3 (network layer) routing. MPLS enables you, as
service providers, to meet the challenges of the explosive growth in network utilization while providing
the opportunity to differentiate services without sacrificing the existing network infrastructure. You can
employ the flexible MPLS architecture in any combination of Layer 2 technologies.
The Cisco 10000 series router offers MPLS support for all Layer 3 protocols.
This chapter describes QoS for MPLS-enabled networks and includes the following topics:
MPLS QoS, page 20-1
MPLS CoS Multi-VC Mode, page 20-12
MPLS Traffic EngineeringDiffServ Aware, page 20-18
Per VRF AAA, page 20-32
MPLS QoS
Multiprotocol Label Switching (MPLS) quality of service (QoS) allows you, as the service provider, to
provide varying levels of QoS services for different types of traffic in an MPLS network. MPLS allows
you to "tunnel" the QoS of a packet. You can classify packets according to their type, input interface,
and other factors without changing the IP precedence or DSCP field of the packet.
The IP precedence and DSCP fields allow you to specify the QoS for an IP packet. The MPLS
experimental (EXP) field, consisting of 3 bits in the IP header, allows you to specify the QoS for an
MPLS packet. The EXP field is used to support differentiated services and can carry all of the
information encoded in the IP precedence or DSCP field. In some cases, the EXP bits are used
exclusively to encode the drop precedence within a traffic class.
The router applies QoS services based on the class of service (CoS) set for a packet. If the IP precedence
field specifies the CoS, the router treats the packet based on the IP precedence marking. In an MPLS
network, the router copies the IP precedence bits into the MPLS EXP field at the edge of the network.
However, based on the service offering, you might need to set the MPLS EXP field to a value that is
different from the IP precedence value. In this case, MPLS QoS allows the IP precedence or DSCP
setting of a packet to remain unmodified as the packet passes through the provider network. During
congestion, packets receive the appropriate priority, based on the MPLS EXP setting.

OL-7433-09
20-1
Chapter 20
MPLS QoS
You can mark the EXP bits independently of the per-hop behavior (PHB). Instead of overwriting the
value in the IP precedence field, you can set the MPLS EXP field, choosing from a variety of criteria
(including those based on IP PHB) to classify a packet and set the MPLS EXP field. For example, you
can classify packets with or without considering the rate of the packets that the PE1 receives. If the rate
is a consideration, you can mark in-rate packets differently from out-of-rate packets.
As the packet travels through the MPLS network, the marking value of an IP packet does not change and
the IP header remains available for use. In some instances, it is desirable to extend the MPLS PHB to
the egress interface between the provider edge (PE) router and customer edge (CE) router. This has the
effect of extending the MPLS QoS tunnel, which allows the MPLS network owner to classify scheduling
and discarding behavior on that final interface.
Feature History for MPLS QoS

Cisco IOS Release
Description
Required PRE
Release 12.0(19)SL
The MPLS QoS feature was introduced on the PRE1.
PRE1
Release 12.0(22)S
This feature was enhanced to allow classification and

marking based on the MPLS experimental (EXP) field.
PRE1
Release 12.2(16)BX
PRE2
Release 12.2(28)SB

for the PRE2.
MPLS QoS Services

The MPLS experimental (EXP) field allow you to specify the QoS for an MPLS packet while the IP
precedence and DSCP fields allow you to specify the QoS for an IP packet. By setting the MPLS EXP
field, the router does not modify the IP precedence or DSCP field of IP packets as they traverse the
network.
MPLS QoS supports the following QoS services:
PolicingClassifies packets according to input or output transmission rates. Allows you to set the
MPLS EXP, IP precedence, or DSCP bits (whichever is appropriate). For more information about
policing, see Chapter 6, Policing Traffic.
Weighted Random Early Detection (WRED)Monitors network traffic to prevent congestion by

dropping packets based on the IP precedence value, DSCP value, MPLS EXP value, or the discard
class value. For more information about WRED, see Chapter 11, Managing Packet Queue
Congestion.
Class-Based Weighted Fair Queuing (CBWFQ) An automated scheduling system that uses a
queuing algorithm to ensure bandwidth allocation to different classes of network traffic. For more
information about CBWFQ, see Chapter 12, Sharing Bandwidth Fairly During Congestion.
20-2
OL-7433-09
Chapter 20

MPLS QoS
MPLS Tunneling Modes

MPLS QoS provides QoS on MPLS packets using the following tunnel modes:
UniformProvides uniformity in per-hop behavior (PHB) throughout the network. In this mode, all
customers of your MPLS network use the same precedence settings.
Short Pipe(Default) Provides for a distinct MPLS PHB layer (on top of the IP PHB layer) across
the entire MPLS network. In this mode, your customers implement their own IP PHB marking
scheme.
PipeSimilar to short pipe mode, except that at the egress of the provider edge (PE) router the
MPLS PHB layer is used to classify the packet for discard and scheduling behavior at the outbound
interface. In this mode, you schedule and discard packets without needing to know your customer
setting.
Figure 20-1 shows a service provider MPLS network that connects two sites of a customers network. To
use these features in a network, set the MPLS experimental field value at PE1 (the ingress label
switching router) by using the modular QoS CLI. This sets the QoS value in the MPLS packet.
Figure 20-1
MPLS Network Connecting Two Sites of a Customer's IP Network
IP
network
MPLS
network
MPLS
network
IP
network
Host A
Host B
PE1
P1
P2
PE2
CE2
41867
CE1
Owned by
service provider
Short pipe tunnel mode discards the MPLS EXP value on label disposition. To enable MPLS EXP-based
classification after label disposition, you can map the EXP values to the qos-group values at the inbound
interface and use qos-group to classify packets into different classes at the outbound interface. However,
Weighted Random Early Detection (WRED) on the outbound interface is still based on the IP type of
service (ToS) value rather than the disposed EXP value.
The Cisco 10000 series router does not support the propagate-cos command to enable uniform mode.
The router does not copy the MPLS EXP values on disposition to the packets IP header, unless you map
the EXP value to a qos-group value at the inbound interface and use the qos-group value to set the IP
ToS value on the outbound interface.

OL-7433-09
20-3
Chapter 20
MPLS QoS
How QoS Works for MPLS Traffic

The Cisco 10000 series router bypasses the IP header-based classification for MPLS packetsyou
cannot classify MPLS packets into distinct classes using the embedded IP header of the MPLS packet.
The router classifies MPLS packets as belonging to the class-default class, except if you specify
qos-group or input-interface match statements for traffic classes.
Normal QoS processing applies to incoming IP packets that the router later tags. Normal QoS processing
resumes for outgoing IP packets that arrived tagged.
Precedence-based Weighted Random Early Detection (WRED) uses the MPLS experimental (EXP)
value for MPLS packets.
Upon MPLS imposition, by default the router sets the EXP values of all pushed labels to the packets IP
precedence value. Upon label swap, the new label carries the EXP value of the swapped label. A set or
police command directive might modify the default EXP setting.
MPLS QoS and Packet Priority During Congestion

The router classifies packets based on the classification and marking criteria you define, such as a source
address, destination address, port, protocol identification, or class of service field. The packets
classification in turn determines each packets priority and how the router treats the packet during
periods of congestion (for example, forward or drop the packet).
For example, service level agreements (SLAs), contracted between providers and their customers,
specify how much traffic the service provider agrees to deliver. Packets that comply with the
agreed-upon rate are considered in-rate and packets that do not comply are considered out-of-rate.
During congestion, the router gives preferential treatment to in-rate packets and might aggressively drop
out-of-rate packets.
Interfaces Supporting MPLS QoS

The following describes interface support for MPLS QoS:
The router supports the match mpls experimental topmost command on both input and output
interfaces on which MPLS is enabled.
The set mpls experimental imposition command and the set mpls experimental command are
supported on the provider edge (PE) router input interface connecting to customer edge (CE) router.
You can also use these commands on input interfaces on the CE, in pipe mode of MPLS QoS
DiffServ tunneling models.
Note
The set mpls experimental imposition command replaces the set mpls experimental
command, which the router supports only for backward compatibility. We recommend that
you use the set mpls experimental imposition command.
The set-mpls-exp-imposition-transmit action of the police command is only supported on the PE

input interface that is connected to the CE.
The mpls ip encapsulate explicit-null command is supported on the CE router interface that is
connected to the PE. This command is only used in pipe mode of MPLS QoS DiffServ tunneling
models.
20-4
OL-7433-09
Chapter 20

MPLS QoS
MPLS QoS Implementation

When precedence-based weighted random early detection (WRED) is configured on an output policy
map and outgoing packets are MPLS packets, the router drops the MPLS packets based on the three EXP
bits in the MPLS label, instead of using the three bits of the IP precedence field in the underlying IP
packets.
When DSCP-based WRED is configured on an output policy map and outgoing packets are MPLS
packets, the router drops the MPLS packets based on the three EXP bits in the MPLS label, instead of
using the six bits of the DSCP field in the underlying IP packets. The router left shifts the three EXP bits
and makes it six bits. For example, if the value of the EXP bits is 5 (binary 101), the router converts them
to binary 101000 (makes it looks like six DSCP bits), and drops packets based on this value.
When configuring the set and police commands in a traffic class, regardless of whether it is an input or
output policy map, the police command is processed later than the set command. This means that the
values implemented by the police command override the values set by the set command. The value can
be IP precedence, DSCP, qos-group, MPLS experimental imposition, discard-class, or ATM CLP bit.
Discard-class is a number between 0 and 7; qos-group is a number between 0 and 63.
Restrictions and Limitations for MPLS QoS

The router does not support the set mpls experimental imposition topmost command.
Configuring MPLS QoS on the Ingress Label Switching Router

A label switching router (LSR) is an ingress provider edge (PE) router, a provider (P) router, or a
penultimate-hop provider router. Setting the MPLS EXP field is only valid for packets that arrive on a
non-MPLS interface of the LSR and leave on an MPLS interface. Therefore, only input service policies
can cause the MPLS EXP bits to be set when the packet goes out an MPLS interface. If the packet arrives
on an MPLS interface, setting the MPLS EXP field has no affect.
The IP header of an outbound IP packet determines the packets QoS. For general information, see the
Cisco IOS Quality of Service Solutions Configuration Guide.
The MPLS EXP field in the topmost label of an outbound MPLS packet determines the packets QoS.
For general information, see the MPLS Class of Service manual.
To configure MPLS QoS on the ingress LSR, perform the following configuration tasks to configure the
ingress label switching router:
Classifying IP Packets Using a Class Map, page 20-6
Setting the MPLS EXP Field Using a Policy Map, page 20-7
Attaching an MPLS QoS Service Policy to an Interface, page 20-8

OL-7433-09
20-5
Chapter 20
MPLS QoS
Classifying IP Packets Using a Class Map

To classify IP packets using a class map, enter the following commands on the ingress LSR beginning
Step 1
Command
Purpose
Creates or modifies a class map.

Step 2

topmost value
(Optional) Specifies the MPLS EXP bits value used to classify

traffic.
Note
Step 3
Router(config-cmap)# match criteria
You can configure MPLS EXP-based classification on

the ingress provider edge (PE), egress PE, provider
(P), or penultimate P router. This command is
Defines criteria by which the router matches packets to this

traffic class.
criteria is the match type (for example, precedence or DSCP
level)
For more information about match types, see the Defining
Match Criteria Using the match Commands section on
page 2-5.
Configuration Example for Classifying IP Packets Using a Class Map

The following example creates a class map named exp4 with MPLS EXP 4 defined as the match
criterion. The router classifies all packets whose EXP bits are set to 4 as belonging to the exp4 traffic
class.
Router(config)# class-map match-all exp4
Router(config-cmap)# match mpls experimental topmost 4
Router(config-cmap)# end
The following example creates a class map named IP_prec4 with IP precedence 4 defined as the match
criterion. The router classifies all packets that contain IP precedence 4 as belonging to the IP_prec4
traffic class.
Router(config)# class-map match-all IP_prec4
The following example creates a class map named http with the access control list (ACL) named http
defined as the match criterion. The router classifies all packets that match the http ACL as belonging to
the http traffic class.
Router(config)# class-map match-all http
Router(config-cmap)# match access-group name http
20-6
OL-7433-09
Chapter 20

MPLS QoS
The following example creates a class map named af41 with DSCP AF41 defined as the match criterion.
The router classifies all packets that contain the IP DSCP binary value 100010 as belonging to the af41
traffic class.
Router(config)# class-map match-all af41
Router(config-cmap)# match ip dscp af41
Setting the MPLS EXP Field Using a Policy Map

To set the MPLS EXP field of packets belonging to a specific traffic class, enter the following commands
Note
Step 1
Even though the commands in Steps 3 through 6 are optional, you must configure one of the commands
to set the MPLS EXP field. The router sets the EXP bits when the packet leaves the router using an MPLS
interface. If the packet arrives on an MPLS interface, the router does not set the EXP bits. You can only
set the EXP bits of packets that arrive on a non-MPLS interface and leave on an MPLS interface.
Command
Purpose
Creates or modifies a policy map that specifies the QoS actions

to take on specific traffic classes.
Step 2

configuration mode.
map.
Step 3
Step 4
Step 5
Step 6

[bc] burst-normal [be] burst-excess
[conform-action
set-mpls-exp-imposition-transmit]
action]
(Optional) Configures traffic policing based on bits per second

and sets the MPLS EXP field for all packets that conform to the
rate.

[bc] burst-normal [pir pir] [be] peak-burst
[conform-action
action]
(Optional) Configures traffic policing using the committed

information rate (CIR) and the peak information rate (PIR) and
sets the MPLS EXP field for all packets that conform to the rate.
police [cir] percent percent [bc]

normal-burst-in-msec [pir pir]
action]

percentage of bandwidth available on an interface and sets the
MPLS EXP field for all packets that conform to the rate.
Router(config-pmap-c)# set mpls

experimental imposition mpls-exp-value
(Optional) Sets the MPLS EXP bits of the packets belonging to

this traffic class.
mpls-exp-value specifies the value used to set the MPLS EXP

bits. Valid values are from 0 to 7.

OL-7433-09
20-7
Chapter 20
MPLS QoS
For more information about other QoS actions you can define in the policy map, see the Types of QoS
Configuration Example for Setting the MPLS EXP Field Using a Policy Map
The following example shows how to set the MPLS EXP field using the set mpls experimental
imposition command. The sample configuration creates a policy map named set_experimental_5 and
defines the traffic class named IP_prec4. The router sets the MPLS EXP bits to 5 for all of the packets
belonging to the IP_prec4 class.
Router(config)# policy-map set_experimental_5
Router(config-pmap)# class IP_prec4
Router(config-pmap-c)# set mpls experimental imposition 5
Router(config-pmap-c)# end
Attaching an MPLS QoS Service Policy to an Interface

An MPLS QoS service policy is a policy map that sets the MPLS EXP field of packets belonging to a
specific traffic class.
To attach an MPLS QoS service policy to an interface, enter the following commands beginning in global
configuration mode:
Step 1
Command
Purpose
Creates or modifies an interface. Enters interface configuration

mode.
Step 2
Router(config-if)# service-policy input

policy-map-name
Attaches the specified policy map to the input interface.

attach to the interface.
Configuration Example for Attaching an MPLS QoS Service Policy to an Interface

The following example applies the MPLS QoS service policy named set_experimental_5 to the Gigabit
Ethernet interface 1/0/0 for inbound packets.
Router(config)# interface GigabitEthernet1/0/0
Router(config-if)# service-policy input set_experimental_5
Configuration Examples for MPLS QoS

This section provides example configurations for the following:
Configuration Example for Short Pipe Mode, page 20-9
Configuration Example for Pipe Mode, page 20-10
20-8
OL-7433-09
Chapter 20

MPLS QoS
Configuration Example for Short Pipe Mode

The following example shows how to configure short pipe mode on the ingress PE router for the
following sample topology. In this topology, esr5 is the CE router, esr6 is the PE router, esr4 is the P
router.
Customer router/switch---(gig4/0/0) esr5 (gig3/0/0.2)---(gig3/0/0.2) esr6 (pos4/0/0)-----(pos4/0/0) esr4 (gig5/0/0)---PE router
Esr6 (ingress PE router):
policy-map set-exp
class http
police 200000000 10000000 10000000 conform-action set-mpls-exp-imposition-transmit 1
exceed-action set-mpls-exp-imposition-transmit 0 violate-action drop
class telnet
set mpls experimental imposition 5
set ip precedence 2
class rtp
set mpls experimental 3
set dscp cs4
class tftp
set mpls experimental 2
class dscp32
class prec6
!
policy-map wred
class exp0
bandwidth percent 10
bandwidth remaining percent 12
random-detect precedence-based
random-detect precedence 0 500 1500 1
shape 120000
class exp1
shape 550000
class exp2
random-detect dscp-based
shape 120000
class exp3
shape 120000
class exp4

OL-7433-09
20-9
Chapter 20
MPLS QoS
random-detect precedence 4 500

shape 120000
class exp5
shape 120000
class exp6
shape 120000
class exp7
bandwidth percent 10vbandwidth
shape 120000
class class-default
1500 1
1500 1
1500 1
remaining percent 12
1500 1
!
ip vrf on forwarding vrf_2
ip address 220.220.56.6 255.255.255.0
service-policy input set-exp
!
!
interface POS4/0/0
ip address 220.220.46.6 255.255.255.0
load-interval 30
tag-switching ip
crc 32
clock source internal
service-policy output wred
Configuration Example for Pipe Mode

The following example shows how to configure pipe mode on the CE and PE routers in the following
sample topology. In this topology, esr5 is the CE router, esr6 is the PE router, esr4 is the P router.
Customer router/switch---(gig4/0/0) esr5 (gig3/0/0.2)---(gig3/0/0.2) esr6 (pos4/0/0)-----(pos4/0/0) esr4 (gig5/0/0)---PE router
Configuration for esr5 (CE router):
class-map
match ip
class-map
match ip
class-map
match ip
class-map
match ip
class-map
match ip
class-map
match ip
class-map
match ip
class-map
match ip
!
match-all prec0
precedence 0
match-all prec1
precedence 1
match-all prec2
precedence 2
match-all prec3
precedence 3
match-all prec4
precedence 4
match-all prec5
precedence 5
match-all prec6
precedence 6
match-all prec7
precedence 7
20-10
OL-7433-09
Chapter 20

MPLS QoS
policy-map prec2exp
class prec0
class prec1
class prec2
class prec3
class prec4
class prec5
class prec6
class prec7
!
!
ip address 220.5.1.1 255.255.255.0
service-policy input prec2exp
load-interval 30
no negotiation auto
no keepalive
!
ip address 220.220.56.5 255.255.255.0
mpls ip encapsulate explicit-null
Configuration for esr6 (ingress PE router):

class-map match-all exp4
match mpls experimental topmost 4
!
policy-map exp2exp
class exp0
set mpls experimental imposition
class exp1
class exp2
class exp3
class exp4
class exp5
class exp6
1
2
3
4
5
6

OL-7433-09
20-11
Chapter 20

class exp7
!
ip vrf forwarding vrf_2
ip address 220.220.56.6 255.255.255.0
service-policy input exp2exp
tag-switching ip

The Multiprotocol Label Switching Class of Service (MPLS CoS) Multi-Virtual Circuit (VC) Mode
feature on the Cisco 10000 router provides multi-VC support on the performance routing engine (part
number PRE1) and extends QoS functionality to Label-Controlled Asynchronous Transfer Mode
(LC-ATM) and multi-VC subinterfaces in a service provider MPLS-enabled network. Such a network
incorporates ATM interfaces on the edge of the network, as well as ATM interfaces within the core of
the network.
The MPLS CoS Multi-VC Mode feature enables you to map the experimental (EXP) field values of an
MPLS label to an ATM VC to create sets of labeled virtual circuits (LVCs). Each set, called an LVC
Service Group, consists of multiple LVCs and each LVC is treated as a member of the set. All members
of a set are associated with a label-switched path (LSP) that is set up between a pair of ATM-connected
routers in the users networking environment. Each member of the set may have a different quality of
service from other members of the set.
By using multi-VC sets, you can provide differentiated services to users of MPLS-enabled service
provider networks. To provide this service differentiation, the provider edge (PE) router in the service
provider network sets an appropriate value in the EXP field in the header of each incoming packet as it
is received. A standard IP access list (ACL) together with a class of service (CoS) map and a prefix map
are used to specify the number of classes (and LVCs) per IP destination. For information on a CoS map,
see theClass of Service Map section on page 20-13.
Each MPLS-enabled ATM interface in the service provider network, including each ATM edge interface
and each ATM router or switch interface within the core of the network, provides QoS support in a
manner similar to that provided for IP packet interfaces. IP packets transiting the service providers
MPLS-enabled network are treated with the same priorities as afforded ATM traffic. Accordingly, MPLS
CoS multi-VC functionality is virtually indistinguishable from the QoS support provided for IP packet
interfaces.
For more information, see the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(2)T feature module.
Feature History for MPLS CoS Multi-VC Mode

Cisco IOS Release
Description
Required PRE
Release 12.0(27)S
This feature was introduced on the router.
PRE1
Release 12.2(16)BX
PRE2
Release 12.2(28)SB

PRE2
20-12
OL-7433-09
Chapter 20

Label Switched Paths

IP packets travel through the core of an MPLS-enabled service provider network by means of multiple,
label-switched paths (LSPs). In ATM networks, label virtual circuits (LVCs) are automatically
established for each IP destination prefix. A standard IP access list (ACL) together with a class of service
(CoS) map and a prefix map are used to specify the number of classes (and LVCs) per IP destination.
For information on a CoS map, see the Class of Service Map section on page 20-13.
If there are multiple equal-cost paths through an ATM network from a P router within the core of the
network to a destination, it is possible that each LVC relating to the same destination could take a
different path through the network, since each LVC could be set up along an alternate equal-cost path.
For example, if four equal-cost paths exist through the network, the first LVC would be set up along the
first path, the second LVC would be set up along the second path, and so on. There is no guarantee,
however, that each LVC would be set up along a parallel path in the network, nor is there any requirement
that each LVC be set up in such a manner.
If there are multiple equal-cost paths through an ATM network from a PE router on the edge of the
network to a destination, LVCs are established for all configured classes of service for each of the
equal-cost paths. The configured load-balancing mechanism determines path selection for data
forwarding.
Class of Service Map

A class of service (CoS) map is a template that maps EXP values to a VC number within an LVC service
group. The Cisco IOS software uses the CoS map to create a binding table that maps EXP values to the
actual VCs. Each LVC has a CoS map and a separate binding table.
You can specify a maximum of four LVCs for each service group. Table 1 shows the default CoS map.
Based on this map, the binding table will have four VCs named available, standard, premium, and
control. The two least significant bits of the EXP field determine the LVC to which the IP packets will
be directed.
Table 1
Default CoS Map
EXP Values
VC Number
VC Name
0, 4
Available
1, 5
Standard
2, 6
Premium
3, 7
Control
You can configure a CoS map to limit the number of LVCs created and to redefine the mapping of the
EXP bits. Table 2 shows a configured CoS map. Based on this map, the binding table will have two VCs
named available and premium.

OL-7433-09
20-13
Chapter 20
Table 2
Configured CoS Map
EXP Values
VC Number
VC Name
0, 4
Available
1, 5
Available
2, 6
Premium
3, 7
Premium
QoS for Label-Controlled ATM VCs

The router dynamically creates label-controlled ATM virtual circuits (LC-ATM VCs), also referred to as
LVCs. In Cisco IOS Release 12.0(28)S and later releases, the implementation of LC-ATM interfaces is
expanded to provide QoS capability for LVCs.
The router treats LVCs like unspecified bit rate (UBR) permanent virtual circuits (PVCs). By default,
the LVCs share the bandwidth on an ATM interface with UBR PVCs. You can configure the bandwidth
on the LC-ATM subinterface using a nested policy map. For more information, see the Allocating LVC
Bandwidth Using Policy Maps section on page 20-14.
Default Bandwidth for LVCs

The default bandwidth is the bandwidth an LC-ATM interface will have when it first becomes active.
LVCs and UBR PVCs share all available bandwidth.
Allocating LVC Bandwidth Using Policy Maps

The router allows you to configure bandwidth for an LC-ATM subinterface. Because the router does not
support a default bandwidth for LVCs, you must use a nested policy map to configure the bandwidth.
The router does not allow non-nested policy maps to be attached to an LC-ATM subinterface.
The nested policy map provides the bandwidth. The router treats the configured bandwidth like the SCR
of the VBR PVCs, in that all LVCs on a specific LC-ATM subinterface use the aggregate bandwidth
specified in the nested policy map. The available bandwidth for UBR PVCs is then reduced by the
configured bandwidth amount.
MPLS QoS Support in an MPLS Network

MPLS QoS provides IOS IP QoS (Layer 3) functionality for MPLS devices, including label edge routers
(LERs), label switching routers (LSRs), and Asynchronous Transfer Mode LSRs (ATM-LSRs). You can
use MPLS QoS in an MPLS-enabled networking environment in several different ways. The method you
choose depends on whether the core of the network contains LSRs or ATM label switching routers
(ATM-LSRs). In either case, the same QoS services are provided, such as CAR, weighted random early
detection (WRED), class-based weighted fair queueing (CBWFQ).
For information about how you can deploy LSRs and ATM-LSRs to take advantage of QoS functions in
an MPLS network, refer to the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(2)T feature module.
20-14
OL-7433-09
Chapter 20

Benefits of MPLS CoS Multi-VC Mode

The MPLS CoS Multi-VC Mode feature has the following benefits:
Ensures effective deployment of differentiated service classes in an MPLS-enabled ATM network
Leverages the use of existing ATM infrastructures
Restrictions for MPLS CoS Multi-VC Mode

The MPLS CoS Multi-VC Mode feature has the following restrictions:
A multi-VC service group can have up to four LVCs.
The Cisco 10000 series router supports a maximum of 500 LVC service groups.
The Cisco 10000 series router does not support available bit rate (ABR) for ATM VCs. Therefore,
the router also does not support ABR LVCs.
All LVCs and the control-VC share the same QoS policy. Any QoS policy changes are applied to the
subinterface. All LVCs will then automatically share the new policy.
Prerequisites for MPLS CoS Multi-VC Mode

The MPLS CoS Multi-VC Mode feature has the following requirements:
The Cisco 10000 series router must be running Cisco IOS Release 12.0(27)S or later releases.
The performance routing engine (PRE), part number PRE1 must be installed in the routers chassis.
To use MPLS QoS to full advantage in your network, the following functionality must be supported:
Multiprotocol Label Switching (MPLS)The standardized label switching protocol defined by
the Internet Engineering Task Force (IETF).

Cisco Express Forwarding (CEF)An advanced Layer 3 IP switching technology that
optimizes performance and scalability in networks that handle large volumes of traffic and
exhibit dynamic traffic patterns.
Asynchronous Transfer Mode (ATM)International standard for cell relay in which multiple
service types (such as voice, video, or data) are conveyed in fixed-length cells. ATM signaling
is required if you use ATM interfaces in your network.
The following QoS features are required:

MPLS CoS Multi-VC Mode to provide QoS functionality on ATM interfaces in a service
provider MPLS-enabled network.

Class-based weighted fair queueing (CBWFQ) to allocate bandwidth fairly to all network
traffic.
Weighted random early detection (WRED) to configure different discard priorities or classes of
service using the MPLS experimental field in the MPLS packet header.

OL-7433-09
20-15
Chapter 20
Configuring MPLS CoS Multi-VC Mode

To configure the MPLS CoS Multi-VC Mode feature on the Cisco 10000 router, perform the following
required configuration tasks:
Configuring Multi-VC Mode in the Core of an ATM Network, page 20-16
Configuring Queueing Functions on Router Output Interfaces, page 20-17
Configuring Multi-VC Mode in the Core of an ATM Network

To configure multi-VC mode in the core of an ATM network, perform the following required
Configuring Multi-VC Mode Using the Default CoS Map, page 20-16
Configuring Multi-VCs Using a Specific CoS Map, page 20-17
Configuring Multi-VC Mode Using the Default CoS Map

To configure multi-VC mode in an MPLS-enabled network using the default CoS map, enter the
Command
Purpose
Step 1

[slot/module/port.subinterface-number] mpls
Configures an ATM MPLS interface or subinterface and enters

Step 2

number
Enables IP processing on the interface without assigning an

Step 3
Router(config-if)# mpls atm multi-vc
Enables ATM multi-VC mode on the interface.

Configures the ATM interface to create one or more label
virtual circuits (VCs) over which packets of different classes
are sent.
Note
This command results in the creation of the default CoS

map shown in Table 1 on page 20-13.
Step 4
Enables MPLS forwarding of IP version 4 (IPv4) packets along

normally routed paths.
Step 5
Router(config-if)# mpls label protocol {ldp

| tdp | both}
Specifies the label distribution protocol to be used on the

interface.
20-16
OL-7433-09
Chapter 20

Configuring Multi-VCs Using a Specific CoS Map

To configure multi-VCs using a CoS map that you specify, enter the following commands beginning in
Command
Purpose
Step 1
Router(config)# mpls cos-map cos-map

number
Creates a class of service (CoS) map that specifies how classes

map to label virtual circuits (LVCs) when they are combined with
a prefix map. Enters cos-map configuration submode.
Step 2
Router(config-tag-cos-map)# class class

[available | standard | premium |control]
Maps traffic classes to LVCs.

class is the precedence of identified traffic to classify traffic.
The default values for assigning traffic classes to the CoS map
range from 0 to 3:
Class 0Available
Class 1Standard
Class 2Premium
Class 3Control
The two least significant bits of the EXP field in the packet header
determine the class of a packet.
Step 3
Router(config-tag-cos-map)# exit
Exits the cos-map configuration submode.
Step 4
Router(config)# access-list
access-list-number permit destination
Creates an access list to control traffic going to the specified

destination address.
Step 5
Router(config)# mpls prefix-map

prefix-map access-list access-list
cos-map cos-map
Configures the router to use a specified QoS map when an MPLS

destination prefix matches the specified access list.
Configuring Queueing Functions on Router Output Interfaces

To configure queuing functions on the routers output interfaces, see Chapter 3, Configuring QoS
Policy Actions and Rules.

OL-7433-09
20-17
Chapter 20
MPLS Traffic EngineeringDiffServ Aware
Monitoring and Maintaining MPLS CoS Multi-VC Mode Configuration

To monitor and maintain the configuration of MPLS CoS Multi-VC Mode on ATM interfaces, enter any
of the following commands in privileged EXEC mode:
Command
Purpose
Router# show mpls interfaces [interface] [detail]
Displays information about one or more interfaces that have been

configured for label switching.
If you do not specify an interface, information about all interfaces
that have been configured for label switching displays.
detail displays detailed label switching information for the
specified interface or for all interfaces if you do not specify an
interface.
Router# show mpls cos-map [cos-map]
Displays the quality of service (QoS) map used to assign a

quantity of label virtual circuits and the associated class of
service (CoS) for those virtual circuits.
cos-map is an optional number that specifies the QoS map to be
displayed.
Router# show mpls prefix-map [prefix-map]
Displays the prefix map used to assign a QoS map to network

prefixes that match a standard IP access list.
prefix-map is an optional number that specifies the prefix map to
be displayed.
Router# debug mpls atm-cos [bind | request]
Displays ATM label VC bind or request activity that is based on

the configuration of a QoS map.
Configuration Examples for MPLS CoS Multi-VC Mode

For an example of how to configure MPLS CoS multi-VC mode functionality, see the Configuration
Examples section in the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(4)T3 feature module.

The MPLS Traffic EngineeringDiffServ Aware (DS-TE) feature extends MPLS traffic engineering
capabilities to provide stricter quality of service (QoS) guarantees. TE tunnels provide differentiated
services (DiffServ) to satisfy bandwidth requirements of regular traffic. However, the bandwidth
currently advertised for TE tunnels and the tunnel traffic does not correspond to any queue. Instead, the
MPLS class of service (CoS) provides DiffServ service, which is adequate for most customer services.
Special services such as voice, however, require stricter QoS guarantees. The DS-TE feature addresses
this need, providing strict bandwidth guarantees for TE tunnels.
The DS-TE feature introduces awareness of a particular class of traffic referred to as the guaranteed
bandwidth traffic. DS-TE enables you, as service providers, to perform separate admission control and
separate route computation of the guaranteed bandwidth traffic. Therefore, you can develop QoS
services for end customers that rely on signaled QoS rather than provisioned QoS, which enables you to
build QoS services with hard commitments and without overprovisioning.
20-18
OL-7433-09
Chapter 20

MPLS traffic engineering allows constraint-based routing of IP traffic. One of the constraints satisfied
by constraint-based routing is the availability of required bandwidth over a selected path. DS-TE extends
MPLS TE so that constraint-based routing and admission control of special TE tunnels (referred to as
guaranteed bandwidth TE tunnels) are performed over a more restrictive bandwidth constraint than
regular TE tunnels. A more restrictive bandwidth constraint enables you to achieve higher QoS
performance (in terms of delay, jitter, or loss) for the guaranteed traffic.
The more restrictive bandwidth is referred to as a sub-pool, while the regular TE tunnel bandwidth is
called the global pool. The sub-pool is a portion of the global pool and applies to tunnels that carry traffic
requiring strict bandwidth guarantees or delay guarantees. The global pool applies to tunnels that carry
traffic requiring only differentiated service.
Having a separate pool for traffic requiring strict guarantees allows you to limit the amount of such
traffic admitted on any given link. Often, it is possible to achieve strict QoS guarantees only if the
amount of guaranteed traffic is limited to a portion of the total link bandwidth.
Having a separate pool for other traffic (best-effort or DiffServ traffic) allows you to have a separate limit
for the amount of such traffic admitted on any given link. This is useful because it allows you to fill up
links with best-effort and DiffServ traffic, thereby achieving a greater utilization of those links.
The DS-TE feature also extends the Open Shortest Path First (OSPF) routing protocol so that the
available sub-pool bandwidth at each preemption level is advertised in addition to the available global
pool bandwidth at each preemption level. The DS-TE feature also modifies constraint-based routing to
take this more complex advertised information into account during path computation.
For more information, see the MPLS Traffic EngineeringDiffServ Aware, Release 12.2(14)S feature
module.
Feature History for MPLS TEDS

Cisco IOS Release
Description
Required PRE
Release 12.3(7)XI
The MPLS Traffic EngineeringDiffServ Aware (DS-TE) PRE2

feature was introduced on the PRE2.
Release 12.2(28)SB

PRE2
Sub-pool Tunnels
A sub-pool tunnel carries traffic that requires strict bandwidth guarantees or delay guarantees, such as
real-time voice, virtual IP leased line, and bandwidth trading traffic. As traffic enters the sub-pool tunnel,
DS-TE marks the traffic with a unique value in the MPLS EXP field. The router places traffic with this
unique value in the guaranteed bandwidth queue at the outbound interface of every tunnel hop. The strict
guaranteed traffic has exclusive use of the guaranteed bandwidth queue; no other traffic can use this
queue.
DS-TE ensures that the guaranteed bandwidth queue is never oversubscribed and limits the amount of
traffic that enters the queue to a percentage of the total bandwidth of the corresponding outbound link.
Therefore, the amount of traffic sent into the sub-pool is never more than the amount the guaranteed
bandwidth queue can handle.

OL-7433-09
20-19
Chapter 20
Global Pool Tunnels

A tunnel that uses global pool bandwidth carries the best-effort class of traffic as well as other classes
of traffic. To ensure that traffic from each class receives differentiated services (DiffServ), each traffic
class has a distinct DiffServ queue and the router marks each class of traffic with a unique value in the
MPLS EXP field. The router places traffic in the appropriate queue based on this unique value. The
router sets tunnel bandwidth based on the expected aggregate traffic across all classes of service.
Prerequisites for DS-TE

To run DS-TE your network must support the following Cisco IOS features:
Note
Multiprotocol Label Switching (MPLS)
IP Cisco Express Forwarding (CEF)
Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS) routing
protocols
Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
QoS
IP CEF is enabled by default on the Cisco 10000 series router and it cannot be turned off. If you attempt
to disable IP CEF, an error appears.
Restrictions and Limitations for DS-TE

The total number of TE tunnels (regular TE tunnels and DS-TE tunnels) that can originate on a device
is limited to 1013 tunnels.
Configuring DS-TE
To configure DS-TE, perform the following required configuration tasks:
Activating Traffic Engineering on the Router, page 20-21
Activating Traffic Engineering on the Interface, page 20-23
Configuring the Tunnel Interface, page 20-24
Configuring Guaranteed Bandwidth Service, page 20-25
20-20
OL-7433-09
Chapter 20

Activating Traffic Engineering on the Router

To globally activate traffic engineering on the router, enter the following commands beginning in global
configuration mode:
Command
Purpose
Step 1
Router(config)# mpls traffic-eng tunnels
Enables MPLS traffic engineering tunnel signaling on the router.
Step 2
Router(config)# router ospf
Invokes the OSPF routing process for IP and enters router

configuration mode. Continue with Step 9.
or
Step 3
Router(config)# router isis
Invokes the IS-IS routing process and enters router configuration

mode. Continue with Step 3.
Router(config-router)# network
network-entity-title
Specifies the IS-IS network entity title (NET) for the routing
process.
network-entity-title specifies the area address and the system ID
for an IS-IS routing process. You can specify an address or a name
for network-entity-title.
Step 4
Router(config-router)# metric-style wide

[transition] [{level-1 | level-2 |
level-1-2}]
Enables the router to generate and accept IS-IS only new-style

type, length, and value (TLV) objects.
Step 5
Router(config-router)# is-type {level-1 |

level-1-2 | level-2-only}
Configures the IS-IS level at which the Cisco IOS software

operates.
When you specify level-1, the router acts as a station router and
learns about destinations inside its area. For interarea routing
information, the router depends on the closest level-1-2 (L1L2)
router.
When you specify level-1-2, the router acts as both a station
router and an area router. The router has one link state database
(LSDB) for destinations inside the area (L1 routing) and runs a
shortest path first (SPF) calculation to discover the area topology.
The router also has another LSDB with link state protocol (LSP)
packets of all other backbone (L2) routers and runs another SPF
calculation to discover the topology of the backbone, and the
existence of all other areas.
When you specify level-2-only, the router acts an area router only.
This router is part of the backbone and does not talk to L1-only
routers in its own area.
Step 6
Router(config-router)# mpls traffic-eng

{level-1 | level-2}
Configures the router to flood MPLS traffic engineering link

information into the IS-IS level you specify. The IS-IS level you
specify must be the same level you specified in the preceding step.

OL-7433-09
20-21
Chapter 20
Step 7
Command
Purpose
Router(config-router)# passive-interface
type number
Disables the IS-IS routing protocol from sending routing updates

on the interface you specify. IS-IS advertises the IP address of the
interface without actually running IS-IS on that interface.
For type number, specify the loopback0 interface.
Note
Step 8

router-id interface-name
When you enable passive-interface on an interface, IS-IS

continues to advertise the subnet to other interfaces and
continues to receive and process updates on the interface
from other routers.
Specifies that the traffic engineering router identifier for the node
is the IP address associated with a specific interface.
interface-name specifies the IP address associated with the
loopback0 interface.
Note
Step 9

area num
For IS-IS configurations, this completes the activation of

TE on the router. Do not continue to Step 9.
Turns on MPLS traffic engineering for a particular OSPF area.
Note
Enter this command for OSPF configurations only. Do not

enter this command for IS-IS configurations.
Configuration Example for Activating Traffic Engineering on the Router

Example 20-1 configures the router for TE using the OSPF routing protocol.
Example 20-1 Activating Traffic Engineering on the Router
Router(config)# mpls traffic-eng tunnels
Router(config)# router ospf 100
Router(config-router)# network 10.1.1.0 0.0.0.255 area 0
Router(config-router)# network 10.16.1.1 0.0.0.0 area 0
Router(config-router)# mpls traffic-eng area 0
Router(config-router)# mpls traffic-eng router-id loopback0
Router(config-router)# exit
20-22
OL-7433-09
Chapter 20

Activating Traffic Engineering on the Interface

To activate traffic engineering on the physical interface, enter the following commands beginning in
Step 1
Command
Purpose
Configures an interface and enters interface configuration mode.

Step 2
Router(config-if)# ip rsvp bandwidth

interface-kbps [sub-pool kbps]
Enables Resource Reservation Protocol (RSVP) for IP on an

interface.
interface-kbps specifies the amount of bandwidth (in kbps) on an
interface to be reserved. Valid values are from 1 to 10,000,000.
(Optional) sub-pool kbps is the amount of bandwidth (in kbps) on
an interface to be reserved to a portion of the total. Valid values
are from 1 to the value of interface-kbps.
Note
The sum of bandwidth used by all tunnels on this interface

cannot exceed interface-kbps and the sum of bandwidth
used by all sub-pool tunnels cannot exceed sub-pool kbps.
Step 3
Router(config-if)# mpls traffic-eng

tunnels
Enables MPLS traffic engineering tunnel signaling on the

interface.
Step 4
Router(config-if)# ip router isis
Enables the IS-IS routing protocol on the interface.

Note
Do not enter this command if you are configuring an

OSPF configuration.
Configuration Example for Activating Traffic Engineering on the Interface

Example 20-2 configures TE on a physical interface using the IS-IS routing protocol.
Example 20-2 Activating Traffic Engineering on a Physical Interface with IS-IS
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
ip address 10.1.1.1 255.255.255.255

ip rsvp bandwidth 130000 130000 sub-pool 80000
mpls traffic-eng tunnels
ip router isis

OL-7433-09
20-23
Chapter 20
Configuring the Tunnel Interface

To configure the attributes for the tunnel on the tunnel interface, enter the following commands
Step 1
Command
Purpose
Router(config)# interface tunnel number
Creates a virtual tunnel interface and enters interface

configuration mode.
number is the number of the tunnel interface that you want to
create or configure. The Cisco 10000 series router does not limit
the number of tunnel interfaces that you can create.
Step 2
Router(config-if)# tunnel mode mpls

traffic-eng
Sets the mode of a tunnel to MPLS for traffic engineering.
Step 3
Router(config-if)# tunnel destination

{hostname | ip-address}
Specifies the destination for a tunnel interface.

hostname is the name of the host destination.
ip-address is the IP address of the host destination.
Step 4
Router(config-if)# tunnel mpls

traffic-eng bandwidth [sub-pool | global]
bandwidth
Configures the bandwidth required for an MPLS traffic

engineering tunnel and assigns the tunnel to the sub-pool or
global pool.
(Optional) sub-pool indicates a subpool tunnel. If you do not
specify sub-pool, the tunnel is global pool.
global indicates a global pool tunnel. By default, all tunnels are
global pool.
bandwidth specifies the bandwidth (in kbps) allocated for the
MPLS traffic engineering tunnel. Valid values are from 1 to
4,294,967,295.
Step 5

traffic-eng priority setup-priority
[hold-priority]
Configures the setup and reservation priority for an MPLS traffic

engineering tunnel.
setup-priority indicates the priority used when signaling a link
state protocol (LSP) for this tunnel to determine which existing
tunnels can be preempted. Valid values are from 0 to 7, where a
lower number indicates a higher priority. Therefore, an LSP with
a setup-priority of 0 can preempt any LSP with a non-0 priority.
hold-priority is the priority associated with an LSP for this tunnel
to determine if it should be preempted by other LSPs that are
being signaled. Valid values are from 0 to 7, where a lower
number indicates a higher priority.
20-24
OL-7433-09
Chapter 20

Step 6
Command
Purpose

traffic-eng path-option [protect] number
{dynamic | explicit {name path-name |
path-number}} [lockdown]
Configures the path (hops) that you want an MPLS traffic

engineering tunnel to use. You can configure many path options
for a single tunnel, including both dynamic and explicit path
options.
(Optional) protect indicates a backup label-switched path (LSP).
When you configure several path options, use lower numbered
options for number.
dynamic indicates that the router dynamically calculates the LSP
path.
explicit indicates that the LSP path is an IP explicit path.
name path-name specifies the path name of the IP explicit path.
This path name represents the specific IP addresses of the hops.
path-number is the path number of the IP explicit path.
lockdown indicates that the LSP cannot be reoptimized.
Configuration Example for Configuring the Tunnel Interface

Example 20-3 configures DS-TE on the tunnel interface.
Example 20-3 Configuring Traffic Engineering on the Tunnel Interface
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#
bandwidth 110000
ip unnumbered loopback0
tunnel destination 10.16.1.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth sub-pool 30000
tunnel mpls traffic-eng priority 0 0
tunnel mpls traffic-eng path-option 1 dynamic
Configuring Guaranteed Bandwidth Service

To configure guaranteed bandwidth service, perform the following required configuration tasks:
Providing Strict QoS Guarantees Using DS-TE Sub-pool Tunnels, page 20-25
Providing Differentiated Service Using DS-TE Global Pool Tunnels, page 20-26
Providing Strict Guarantees and Differentiated Service in the Same Network, page 20-26
For guaranteed bandwidth service configuration examples, see the MPLS Traffic EngineeringDiffServ
Aware, Release 12.2(14)S feature module.
Providing Strict QoS Guarantees Using DS-TE Sub-pool Tunnels

To provide strict QoS guarantees using DS-TE sub-pool tunnels, do the following:
1.
Select a queue (referred to as per-hop behavior (PHB) in DiffServ terminology) to be used

exclusively by the strict guarantee traffic. This queue is referred to as the guaranteed bandwidth
queue.
If you want to provide delay or jitter guarantees, use the DiffServ expedited forwarding queue (EF
PHB). On the Cisco 10000 series router, it is the absolute priority queue.

OL-7433-09
20-25
Chapter 20
If you only want to provide bandwidth guarantees, use the DiffServ assured forwarding queue (AF
PHB). On the Cisco 10000 series router, use one of the existing class-based weighted fair queuing
(CBWFQ) queues.
2.
Ensure that the router places the guaranteed traffic from the sub-pool tunnel in the guaranteed
bandwidth queue at the outbound interface of every tunnel hop, and that the router does not place
any other traffic in this queue. To do this, mark the traffic entering the tunnel with a unique value in
the MPLS EXP field. The router sends only the marked traffic into the guaranteed bandwidth queue.
3.
Ensure that the router does not oversubscribe the queue and instead sends only the amount of traffic
into the sub-pool tunnel that the guaranteed bandwidth queue can handle. To do this, limit the rate
of the guaranteed traffic before it enters the sub-pool tunnel. The aggregate rate of all traffic entering
the sub-pool tunnel is less than or equal to the bandwidth capacity of the sub-pool tunnel. For delay
or jitter guarantees, excess traffic is dropped. For bandwidth guarantees, excess traffic can be
marked differently for preferential discard.
4.
Ensure that the amount of traffic entering the guaranteed bandwidth queue is limited to an
appropriate percentage of the total bandwidth of the corresponding outbound link. The exact
percentage to use depends on several factors that can contribute to accumulated delay in your
network: your QoS performance objective, the total number of tunnel hops, the number of links
folded in along the tunnel path, the burstiness of the input traffic and so on. To do this, set the
sub-pool bandwidth of each outbound link to the appropriate percentage of the total link bandwidth
by adjusting the sub-pool kbps parameter of the ip rsvp bandwidth command.
Providing Differentiated Service Using DS-TE Global Pool Tunnels

To provide differentiated service using DS-TE global pool tunnels, do the following:
1.
Select a separate queue for each traffic class.
2.
Mark each class of traffic using a unique value in the MPLS EXP field.
3.
Ensure that packets marked for a specific traffic class are placed in the queue for that class. The
tunnel bandwidth is set based on the expected aggregate traffic across all classes of service.
To control the amount of DiffServ tunnel traffic you intend to support on a given link, adjust the size of
the global pool on that link.
Providing Strict Guarantees and Differentiated Service in the Same Network

Because DS-TE allows simultaneous constraint-based routing of sub-pool and global pool tunnels, you
can provide strict guarantees and differentiated services (DiffServ) simultaneously in a given network.
Verifying and Monitoring DS-TE Configurations

To verify and monitor DS-TE configurations, enter any of the following commands in privileged EXEC
mode:
20-26
OL-7433-09
Chapter 20

Command
Purpose
Displays the complete DS-TE configuration.
Router# show interfaces tunnel number

[accounting]
Displays tunnel interface information for the tunnel interface you

specify.
number is the port line number.
(Optional) accounting displays the number of packets of each
protocol type that has been sent through the interface.
Router# show ip ospf [process-id]
Displays general information about all OSPF routing processes or

about only the routing process you specify.
(Optional) process-id is the process ID. When specified,
information displays for only the specified routing process.
Router# show ip route [address [mask]

[longer-prefixes]] | [protocol [process-id]]
Displays the current state of the routing table.
Router# show ip rsvp host {host {receivers |

senders} | installed | interface | neighbor |
request | reservation | sender}
Displays Resource Reservation Protocol (RSVP) terminal point

information for receivers or senders, including RSVP installed
reservations, interface information and neighbor information.
request displays RSVP reservations upstream information.
reservation displays RSVP reservation requests from
downstream.
sender displays RSVP PATH state information.
Router# show ip rsvp interface [type number]
Displays RSVP-related interface information.

Use this command to show the current allocation budget and the
maximum allocatable bandwidth.
(Optional) type number is the type and number of an interface (for
example, serial 1/0/0).
Router# show mpls traffic-eng autoroute
Displays tunnels that are announced to Interior Gateway Protocol

(IGP), including interface, destination, and bandwidth. This
command displays which tunnels are currently being used by the
IGP in its enhanced shortest path first (SPF) calculation (tunnels
that are up and have autoroute configured).
Router# show mpls traffic-eng fast-reroute

database
Displays the contents of the Fast Reroute database.
Router# show mpls traffic-eng fast-reroute log

reroutes
Displays the contents of the Fast Reroute event log.
Router# show mpls traffic-eng link-management

admission-control [interface name]
Displays the tunnels that have been admitted locally and their
parameters such as priority, bandwidth, incoming and outgoing
interface, and state.
(Optional) interface name indicates to display only those tunnels
that are admitted on the interface specified by name (for example,
serial 1/0/0).

advertisements
Displays local link information currently being flooded by MPLS

traffic engineering link management into the global traffic
engineering topology.

OL-7433-09
20-27
Chapter 20
Command
Purpose

bandwidth-allocation [interface name]
Displays current local link information.

(Optional) interface name indicates to display only those tunnels
that are admitted on the interface specified by name (for example,
serial 1/0/0).

igp-neighbors [{igp-id {isis isis-address | ospf
ospf-id} | ip A.B.C.D}]
Displays Interior Gateway Protocol (IGP) neighbors.

interfaces [interface]
Displays per-interface resource and configuration information.

(Optional) interface indicates to display information for the
specified interface.

summary [interface name]
Displays summary of link management information.

(Optional) interface name indicates to display information for
the specified interface.
Router# show mpls traffic-eng topology [{A.B.C.D

| igp-id {isis nsapaddr | ospf A.B.C.D}] [brief]
Displays the MPLS traffic engineering global topology as

currently known at this node.
You can specify the node by IP address (router identifier to
interface address), IGP router identifier (igp-id), router
identification (nsapaddr) if using IS-IS, and router identifier
(A.B.C.D) if using OSPF.
(Optional) brief indicates to display a brief form of the output
that provides a less detailed version of the topology.
Router# show mpls traffic-eng tunnels
Displays information about tunnels.
For more information about these commands, see the MPLS Traffic EngineeringDiffServ Aware,
Release 12.2(14)S feature module.
Configuration Examples for DS-TE

This section provides the following example configurations:
Configuration Examples for Configuring the Tunnel Head Router, page 20-28
Configuration Examples for Configuring DS-TE on the Midpoint Routers, page 20-30
Configuration Examples for Configuring the Tail-End Router, page 20-31
Configuration Examples for Configuring Guaranteed Bandwidth Service, page 20-31
Configuration Examples for Configuring the Tunnel Head Router

This section provides the following examples of how to activate DS-TE on the tunnel head router.
Configuration Example for Configuring DS-TE on the Tunnel Head Router, page 20-29
Configuration Example for Configuring DS-TE on the Tunnel Head Physical Interface, page 20-29
Configuration Example for Configuring DS-TE on the Tunnel Interface, page 20-29
20-28
OL-7433-09
Chapter 20

Configuration Example for Configuring DS-TE on the Tunnel Head Router

Example 20-4 activates DS-TE on the router at the head of the tunnel. This DS-TE configuration uses
the OSPF routing protocol and configures the loopback0 virtual interface.
Example 20-4 Configuring DS-TE on the Tunnel Head Router
router-1(config)# mpls traffic-eng tunnels
router-1(config)# router ospf 100
router-1(config-router)# redistribute connected
router-1(config-router)# network 10.1.1.0 0.0.09.255 area 0
router-1(config-router)# network 10.20.1.1 0.0.0.0 area 0
router-1(config-router)# mpls traffic-eng area 0
router-1(config-router)# mpls traffic-eng router-id loopback0
router-1(config-router)# exit
router-1(config)# interface loopback0
router-1(config-if)# ip address 10.22.1.1 255.255.255.255
router-1(config-if)# no ip directed-broadcast
router-1(config-if)# exit
Configuration Example for Configuring DS-TE on the Tunnel Head Physical Interface
Example 20-5 activates DS-TE on the egress physical interface POS 2/0/0. This physical interface is
configured on the tunnel head router.
Example 20-5 Configuring DS-TE on the Tunnel Head Physical Interface
router-1(config)# interface POS2/0/0
router-1(config-if)# mpls traffic-eng tunnels
router-1(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000
Configuration Example for Configuring DS-TE on the Tunnel Interface

Example 20-6 activates DS-TE on the egress Tunnel1 interface. This tunnel interface is configured on
the tunnel head router.
Example 20-6 Configuring DS-TE on the Tunnel Interface
router-1(config)# interface Tunnel1
router-1(config-if)# bandwidth 110000
router-1(config-if)# ip unnumbered loopback0
router-1(config-if)# tunnel destination 10.24.1.1
router-1(config-if)# tunnel mode mpls traffic-eng
router-1(config-if)# tunnel mpls traffic-eng priority 0 0
router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 320000
router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic

OL-7433-09
20-29
Chapter 20
Configuration Examples for Configuring DS-TE on the Midpoint Routers

This section provides the following examples of how to configure DS-TE on the midpoint routers:
Note
Configuration Example for Configuring DS-TE on the Midpoint Router, page 20-30
Configuration Example for Configuring DS-TE on the Midpoint Network Interfaces, page 20-30
Do not configure tunnel interfaces on the midpoint routers.
Configuration Example for Configuring DS-TE on the Midpoint Router

Example 20-7 globally activates DS-TE on the midpoint router. This configuration uses the IS-IS routing
protocol and configures the loopback0 virtual interface.
Example 20-7 Configuring DS-TE on the Midpoint Router
router-2(config)# router isis
router-2(config-router)# net 49.0000.1000.0000.0012.00
router-2(config-router)# metric-style wide
router-2(config-router)# is-type level-1
router-2(config-router)# mpls traffic-eng level-1
router-2(config-router)# passive-interface loopback0
Configuration Example for Configuring DS-TE on the Midpoint Network Interfaces

Example 20-8 activates DS-TE on the physical network interfaces POS 4/0 and POS 4/1 of the midpoint
router. The example uses the IS-IS routing protocol.
Example 20-8 Configuring DS-TE on the Midpoint Network Interfaces
router-2(config)# interface POS4/0
router-2(config-if)# ip router isis
router-2(config-if)# interface POS4/1
20-30
OL-7433-09
Chapter 20

Configuration Examples for Configuring the Tail-End Router

This section provides the following examples of how to configure DS-TE on the tail-end router:
Note
Configuration Example for Configuring DS-TE on the Tail-End Router, page 20-31
Configuration Example for Configuring DS-TE on the Tail-End Physical Interfaces, page 20-31
Do not configure tunnel interfaces on the tail-end router.
Configuration Example for Configuring DS-TE on the Tail-End Router

Example 20-9 activates DS-TE globally on the tail-end router. This example configures the IS-IS routing
protocol and the loopback0 virtual interface.
Example 20-9 Configuring DS-TE on the Tail-End Router
router-3(config)# router isis
router-3(config-router)# net 49.0000.1000.0000.0013.00
router-3(config-router)# metric-style wide
router-3(config-router)# is-type level-1
router-3(config-router)# mpls traffic-eng level-1
router-3(config-router)# passive-interface loopback0
Configuration Example for Configuring DS-TE on the Tail-End Physical Interfaces

Example 20-10 activates DS-TE on the physical interface POS 4/0 of the tail-end router. This example
configuration uses the IS-IS routing protocol.
Example 20-10 Configuring DS-TE on the Tail-End Physical Interface
router-1(config)# interface POS4/0
Configuration Examples for Configuring Guaranteed Bandwidth Service

For examples of guaranteed bandwidth configuration, see the MPLS Traffic EngineeringDiffServ
Aware, Release 12.2(14)S feature module.

OL-7433-09
20-31
Chapter 20
Per VRF AAA
Per VRF AAA

The per VRF AAA feature allows the Cisco 10000 series router to communicate directly with the
customer RADIUS server without having to go through a RADIUS proxy. Using the per VRF AAA
feature, you can partition authentication, authorization, and accounting (AAA) services based on a
virtual routing and forwarding (VRF) instance.
The Cisco 10000 series router supports the per VRF AAA feature in the following deployment models:
Managed L2TP Network Server
PPP Terminated Aggregation (PTA) to VRF
Remote Access (RA) to MPLS VPN
To support the per VRF AAA feature, AAA must be VRF aware. Define operational parameters for each
VRF and secure them to the VRF partitions, using a virtual template interface. For more information
about setting AAA parameters, see the Configuring RADIUS Attribute Accept or Reject Lists section
on page 6-36.
For more information about the Per VRF AAA feature, see the Cisco 10000 Series Router Broadband
Aggregation, Leased-Line, and MPLS Configuration Guide.
Feature
Class maps

DiffServ-Traffic Engineering (DS-TE)
MPLS Traffic EngineeringDiffServ Aware, Release 12.2(14)S feature module
MPLS
Cisco 10000 Series Router Broadband Aggregation, Leased-Line, and MPLS

Configuration Guide
Multiprotocol Label Switching on Cisco Routers, Release 12.1(3)T feature module
MPLS Class of Service manual
20-32
OL-7433-09
Chapter 20

Feature
MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(2)T feature module
MPLS Label Distribution Protocol, Release 12.1(8a)E feature module
Multiprotocol Label Switching on Cisco Routers, Release 12.1(3)T feature module
MPLS Class of Service Enhancements, Release 12.1(5)T feature module
MPLS Virtual Private Networks (VPNs), Release 12.0(22)S feature module
Quality of Service Solutions Configuration Guide, Release 12.2
Policy maps

Part 8: Modular Quality of Service Command Line Interface > Configuring the
Modular Quality of Service Command Line Interface > Modular QoS CLI

OL-7433-09
20-33
Chapter 20
20-34
OL-7433-09
CH A P T E R
21

This chapter describes VLAN tag-based QoS and includes the following topics:
VLAN Tag-Based QoS, page 21-1
Restrictions for VLAN Tag-Based QoS, page 21-5
Configuring VLAN Tag-Based QoS, page 21-7
Configuration Examples for VLAN Tag-Based QoS, page 21-13
Related Documents, page 21-15
VLAN Tag-Based QoS

The QoSVLAN Tag-Based feature enables you to apply a single QoS policy, referred to as a
VLAN-group policy, to a group of IEEE 802.1Q VLAN subinterfaces.
In releases prior to Cisco IOS Release 12.2(31)SB2, you can apply a QoS policy to an interface or a
specific subinterface. When applied on the main interface, all of the VLAN subinterfaces configured on
the interface inherit the QoS policy of the main interface. When applied to a specific subinterface, each
subinterface has its own QoS policy.
In some instances, however, service providers might configure customers in such a way that a single QoS
policy is needed for multiple VLAN subinterfaces, but not for all of the subinterfaces configured on the
main interface. The QoSVLAN Tag-Based feature addresses this need by allowing multiple
subinterfaces to be treated as an aggregated whole, binding all of the matching subinterfaces together
under a single QoS policy.
The configuration of the QoSVLAN Tag-Based feature entails the creation of VLAN-group classes
and the creation of a VLAN-group policy map. Class maps define the groups of VLAN subinterfaces and
enable the router to classify multiple VLANs as belonging to the same traffic class: a VLAN-group class.
The QoS VLAN-group policy map defines the QoS services for specific VLAN groups and for
subinterfaces that do not belong to a specific VLAN group.
You apply the VLAN-group policy to the main interface and if a VLAN subinterface matches one of the
VLAN-group classes defined in the VLAN-group policy, the VLAN subinterface and all of the sessions
established on that subinterface inherit the QoS services defined for that particular VLAN-group class.
If more than one VLAN subinterface matches one of the VLAN-group classes, then the router treats all
of the matching VLAN subinterface traffic as an aggregated whole and applies the single VLAN-group
policy to the trafficin particular that portion of the VLAN-group policy that defines QoS services for
that specific VLAN-group class.

OL-7433-09
21-1
Chapter 21
VLAN Tag-Based QoS
For hierarchical QoS policies, the router applies the parent shape rate to each group of VLANs. At most,
a single VLAN can have a throughput equal to the parent shape rate. If all of the VLANs within the
VLAN group are active, the aggregate traffic of all active VLAN-group members is limited to the shape
rate.
In an 802.1Q VLAN implementation, the router passes a packet to the dot1q-encapsulated subinterface
only if the VLAN ID of the packet matches the VLAN ID configured for the subinterface. Otherwise,
the router passes the packet to the main interface. Therefore, you must create a subinterface with a
specific VLAN ID before the router can apply QoS on a VLAN ID that is configured as part of a VLAN
group.
Feature History for VLAN Tag-Based QoS

Cisco IOS Release
Description
Required PRE

Cisco 10000 series router for the PRE2 and PRE3.
PRE2
PRE3
VLAN-Groups
A VLAN-group is a traffic class that potentially consists of multiple IEEE 802.1Q VLAN subinterfaces.
A class map defines the VLAN group and the match criteria the router uses to classify the traffic as
belonging to a specific VLAN group. All of the subinterfaces belonging to a VLAN group share the
bandwidth allocated to the group and share the same class queue.
The match vlan command allows you to specify the VLANs you want to include in a VLAN group. The
configuration of a VLAN group can include individual VLAN ID values or a range of values. For
example, VLANs with IDs 3, 5-8, and 10 can form a VLAN group. The router treats the VLANs
specified in a VLAN group as an aggregate whole.
Note
If you specify the match vlan command in a class map, you cannot specify other match commands in
the same class map. Use the match vlan command only for VLAN grouping.
Only Ethernet, Fast Ethernet, and Gigabit Ethernet interfaces support VLAN groups. For outbound
VLAN tag-based policies, use a shape command for each VLAN group.
VLAN-Group Policy Map

A VLAN-group policy map defines QoS services for traffic classes that consists of multiple IEEE
802.1Q VLAN subinterfaces (see the VLAN-Groups section on page 21-2). In this way, you can apply
a single QoS policy to multiple VLANs belonging to specific VLAN-group classes.
You can attach a VLAN-group policy map to only the main interface. The subinterfaces on the main
interface inherit the service policy.
The amount of policy space used is equivalent to the number of VLAN groups defined in the policy,
including the VLAN groups defined in match-VLAN class maps and in the class-default class. The limit
of available policy space is equivalent to 4096 policy maps.
21-2
OL-7433-09
Chapter 21

VLAN Tag-Based QoS
For example, consider

the following sample configuration:
Modification of a VLAN-Group
Policy Map
policy-map Input_Parent
Addingclass
or removing
VLAN-group classes from a VLAN-group policy only affects QoS on the
vlangrp1
police
percent
subinterfaces
that you
added10or removed from the policy. Adding or removing class-default classes
service-policy
Child1
affects QoS only on the subinterfaces
that do not belong to any VLAN group.
class vlangrp2
Modifying police
a child policy
that30is applied to a VLAN-group class in a VLAN-group policy affects QoS on
percent
class
vlangrp3 that belong to that VLAN group. Modifying a child policy applied to a
all of the
subinterfaces
shape
class-default
class512000
affects QoS on all of the subinterfaces that do not belong to any VLAN group.
service-policy Child2
class
vlangrp4see the VLAN Tag-Based QoS section on page 21-1,
For more
information,
police 8000
VLAN ID
The class vlangrp1 is a valid configuration for input traffic because it has a non-queuing action
(policing) defined before the Child1 service policy is applied.

The VLAN ID is a number you specify to identify a VLAN subinterface. The router uses the VLAN ID
The class vlangrp2 is a valid configuration because non-queuing actions are permitted for input
of packets to classify them as belonging to specific VLAN groups. Valid VLAN ID values are from 1 to
policies.
4094.
The class vlangrp3 is an invalid configuration for this input parent policy because it contains a
queuing action (shape).
VLAN-Group Policies and Inheritance

If this was anQoS
output
parentthe
policy,
thesupports
class vlangrp3
would be a of
valid
configuration
because
ForNote
non-VLAN-group
policies,
PRE3
the configuration
shaping
only at the
queuing
actions
such
as
shape
are
permitted
for
output
policies.
subinterface level and a hierarchical queuing policy at the virtual template level. In this case, the PPP
session traffic uniquely inherits the policy on the virtual template and the aggregate of all of the PPP
The
class
vlangrp4
is by
a valid
configurationpolicy.
for an input parent policy because it contains a
session
traffic
is also
shaped
the subinterface
non-queuing action (police) before applying the child service policy.
All subinterfaces that are not part of a VLAN group and that do not have a service policy attached inherit
theFor
an output
the PRE2
allows
to configure
only the shape command on the
policy
appliedparent
on thepolicy,
class-default
class
of a you
VLAN-group
policy.
parent class. The PRE3 allows you to configure the shape command and the bandwidth remaining
Forratio
sessions
terminated
a subinterface
is part ofremaining
a VLAN-group
policy, theallows
following
occurs:
command
on theon
parent
class. Thethat
bandwidth
ratio command
you to
define
proportionate
share of applied
the bandwidth
for allocationdoes
to VLAN
groups
during
periods
of congestion.
a If
the virtual template
to the subinterface
not have
a QoS
policy
(non-VLAN-group),
theexample,
virtual access
interface sample
(VAI) that
is created when
PPP
session
creationanoccurs
not policy:
uniquely
For
the following
configuration
shows
how
to configure
outputdoes
parent
inherit the policy inherited by the subinterface. For example, suppose a subinterface policy shapes
policy-map Egress_Parent
traffic to 2 Mbps and two PPPoE sessions initiate. The total traffic from both of the PPPoE sessions
class vgrp1
is aggregately
shaped to 2 Mbps. Each PPP session traffic is not shaped uniquely to 2 Mbps.
shape 128000
service-policy
Child3 to the subinterface has a QoS policy (for example, a non-queuing
If the virtual
template applied
class vgrp2
policy shape
that specifies
policing and marking for the PRE2 or all QoS actions for the PRE3), each PPP
512000
sessionservice-policy
traffic is uniquely
influenced by the policy defined at the virtual template. For example,
Child2
suppose
hierarchical QoS policy is configured to police traffic to 2 Mbps. Each PPPoE session
classa class-default
2000000
traffic shape
is uniquely
policed to 2 Mbps. The policy on the subinterface has no affect.
For input policies, if you apply a child QoS policy to a VLAN-group traffic class (created using the
Aggregate Session
Traffic
match-vlan
command in a class map), you must first configure a policing action. The router
supports non-queuing actions (policing) for input policies, and both queuing (shaping) and
Younon-queuing
cannot shape
the aggregate
session
trafficpolicies.
by applying a shaping policy to a VLAN group. Instead,
(policing)
actions
for output
when applying queuing policies to sessions, shape the aggregate session traffic by applying a shaping
policy
If you
attach
a VLAN-group
policy
in the outbound
direction,
configure
shaper
each VLAN
to an
802.1Q
VLAN or QinQ
subinterface.
For more
information,
seea the
QoS:forHierarchical
group
so
that
the
group
has
its
own
VTMS
link.
Otherwise,
the
traffic
for
that
VLAN
group
uses the
Queuing for Ethernet DSLAMs feature module for Cisco IOS Release 12.2(31)SB2.
VTMS link and queues of the main interface.
Although you cannot shape PPP sessions, you can police the sessions.
For VLAN-based classes with multiple VLAN match filters defined, traffic accounting is updated
as an aggregate under the first match-VLAN filter for the class in the policy. The router does not
maintain individual match-VLAN filter statistics.

OL-7433-09
21-3
Chapter 21
VLAN Tag-Based QoS
System Limits for VLAN Tag-Based QoS

Table 21-1 lists the system limits for VLAN tag-based QoS.
Table 21-1
System Limits for VLAN Tag-Based QoS
Class Maps
per Policy Map1
VLAN Groups
per VLAN-Group Policy
Total Number Class Maps

per VLAN-Group Policy2
255
255
64
1. Excludes the class-default class map.

2. Includes the class maps configured for child policies applied to each match-VLAN class and includes the class-default class
of the VLAN-group policy.
Statistical Information for VLAN-Group Policies and Classes

The router displays packet statistics for VLAN-group policies using the modular QoS command-line
interface (MQC) show commands. Statistical information displayed for VLAN groups represents the
aggregate traffic of all of the subinterface members of the specific VLAN group.
The router updates match-VLAN filter statistics only for the aggregate traffic through the VLAN groups.
VLAN Tag-Based QoS on the PRE2 and PRE3

Table 21-2 describes support for various features on the PRE2 and PRE3 when configured with the
QoSVLAN Tag-Based feature.
Table 21-2
VLAN Tag-Based QoS on the PRE2 and PRE3
Feature
PRE2
PRE3
Aggregate priority queues
Not supported
Supported.
Aggregate priority queues should be well within
90% of the maximum rate to guarantee
performance.
Aggregate WRED
Not supported
Supported
Allows a maximum of 8 profiles per class and a
total of 21 profiles in a policy.
Bandwidth remaining ratio
Not supported
Supported at the parent level of VLAN QoS

policies.
VLAN-group policies
Supports simultaneous VLAN-group policy Does not support both VLAN-group policies and
and subinterface policies that are not part of subinterface policies on the same link
the VLAN-group policy.
simultaneously.
21-4
OL-7433-09
Chapter 21

Table 21-2
VLAN Tag-Based QoS on the PRE2 and PRE3 (continued)
Feature
PRE2
PRE3
Multiple levels of priority

queues
Not supported
Supported
Strict priority queues
Supported
Provides for 2 levels of priority queues.

No supported
Supports a strict priority queue without a

policer. However, we recommend that you
use policers with the priority queue to avoid
bandwidth starvation of other class queues.
When configuring a VLAN tag-based QoS policy map, the router applies the policy to one Ethernet
port and only to the VLANs on that particular port.
Class maps that contain the match vlan command cannot contain any other classification criteria.
Currently, the match vlan command is used only to group VLAN subinterfaces. Do not use the
command for any other purpose.
The match vlan counters update only for one-level QoS policies; they do not update for hierarchical
QoS policies.
The router does not support applying a VLAN-group policy to a virtual template.
The router does not support the random-detect and priority commands for traffic classes created
using the match-vlan command in class maps.
When creating a class map with the match vlan command, configure the match-any command as
the match type.
You cannot specify traffic classes created using the match-vlan command in the following policies:
Child policies
Policies attached to an interface other than a Fast Ethernet or Gigabit Ethernet interface
Policies in which a non-VLAN-based traffic class exists. (This does not include the
class-default class.)
VLAN group members across the VLAN groups in a VLAN-group policy are mutually exclusive.
Do not use VLAN ID 1 in a VLAN group unless you create a subinterface with VLAN ID 1.
For the PRE2, if a policy map specifies a particular VLAN ID, you cannot apply any service policy
map to subinterfaces that have that particular VLAN ID (or dot1q ID). However, on the PRE3, you
cannot apply policies to the main interface and to subinterfaces, even if the subinterface does not
have a matching VLAN-group ID.
You can apply a VLAN-group policy map only to the main interface; you cannot apply it to
subinterfaces.
You cannot add VLAN-group traffic classes to a policy that already has QoS services defined for
traffic classes, even if the class configuration is only the class-default class.
In a class map, you can specify only the match vlan command as the classification criteria if QoS
services are defined for the corresponding traffic class in the parent policy (top-level in a three-level
policy) of a hierarchical policy.

OL-7433-09
21-5
Chapter 21
In a class map, you cannot specify the match-vlan command as the classification criteria if QoS
services are defined for the corresponding traffic class in a child policy of a hierarchical policy.
You can apply a child policy to any traffic class in a VLAN-group policy map. The child policy is
not restricted to being applied only to the class-default class.
In a VLAN-group policy map, if you apply a child service policy to a traffic class of an input parent
policy, you must configure a non-queuing action such as policing before you apply the child policy.
You cannot configure any queuing actions for the parent class, such as shaping, priority, or
class-based weighted fair queuing (CBWFQ).
For example, consider the following sample configuration:
policy-map Input_Parent
class vlangrp1
police percent 10
class vlangrp2
police percent 30
class vlangrp3
shape 512000
class vlangrp4
police 8000
The class vlangrp1 is a valid configuration for input traffic because it has a non-queuing action
(policing) defined before the Child1 service policy is applied.

The class vlangrp2 is a valid configuration because non-queuing actions are permitted for input
policies.
The class vlangrp3 is an invalid configuration for this input parent policy because it contains a
queuing action (shape).
Note
If this was an output parent policy, the class vlangrp3 would be a valid configuration because
queuing actions such as shape are permitted for output policies.
The class vlangrp4 is a valid configuration for an input parent policy because it contains a
non-queuing action (police) before applying the child service policy.
For an output parent policy, the PRE2 allows you to configure only the shape command on the
parent class. The PRE3 allows you to configure the shape command and the bandwidth remaining
ratio command on the parent class. The bandwidth remaining ratio command allows you to define
a proportionate share of the bandwidth for allocation to VLAN groups during periods of congestion.
You can configure the shape command and service-policy command for a traffic class of an output
parent policy.
For example, the following sample configuration shows how to configure an output parent policy:
policy-map Egress_Parent
class vgrp1
shape 128000
class vgrp2
shape 512000
class class-default
shape 2000000
21-6
OL-7433-09
Chapter 21

Configuring VLAN Tag-Based QoS
For the input direction, if you apply a QoS policy to a match-vlan traffic class, you must configure
a police action.
If you attach a VLAN-group policy in the outbound direction, configure a shaper for each VLAN
group so that the group has its own VTMS link. Otherwise, the traffic for that VLAN group uses the
VTMS link and queues of the main interface.
For VLAN-based classes with multiple VLAN match filters defined, traffic accounting is updated
as an aggregate under the first match-VLAN filter for the class in the policy. The router does not
maintain individual match-VLAN filter statistics.
You cannot delete a match-VLAN filter from a class map if only a single filter is configured in the
class map. You can modify the class map filters either by deleting the class from the policy or adding
the required VLAN filters to the class before deleting all of the VLAN filters from the class map.
Although the router supports QinQ subinterfaces, the VLAN Tag-Based feature does not support
QinQ subinterfaces under a VLAN group. You can use only 802.1Q subinterfaces for VLAN groups.
These subinterfaces have a single inner VLAN ID.

To configure VLAN tag-based QoS, perform the following configuration tasks:
Configuring VLAN-Group Class Maps, page 21-8
Configuring a VLAN-Group Policy, page 21-9
Configuration Guidelines for VLAN Tag-Based QoS
Configure the match-vlan command as the only filtering criteria for a class map.
If you attempt to apply a policy map that includes a traffic class for which the match-vlan command
and other match commands are configured, the attempt fails and an error message displays.
Configure the match-any command with the match-vlan command.

A class map configured for classification of VLAN-group traffic must match any of the specified
VLAN criteria. If you do not specify the match-any command as part of the class map match-vlan
criteria and you attempt to specify that class in a policy map, the attempt fails and an error message
displays.
Configure VLAN-group traffic classes (created using the match-vlan command in a class map) only
in the parent class of hierarchical policy maps. For example, in a three-level hierarchical policy, the
parent class is the topmost level of the policy.
If you attempt to configure a VLAN-group traffic class in a child policy, the attempt fails and an
error message displays.
Attach VLAN-group policies (policies containing match-vlan traffic classes) only to Fast Ethernet
and Gigabit Ethernet interfaces.
Do not attach a policy map to an 802.1Q VLAN subinterface with a VLAN ID if the subinterface is
part of a VLAN-group with a defined policy.
If an 802.1Q VLAN subinterface has a VLAN ID that is specified as part of a VLAN-group and a
VLAN-group policy is attached to an interface, if you attempt to attach a QoS policy to the
subinterface participating in the VLAN group, the attempt fails and an error message displays.
Attach child policies under any class defined in a VLAN-group policy.

OL-7433-09
21-7
Chapter 21
For a VLAN-group policy, you are not required to only attach child policies under the class-default
class of a parent policy. You may apply child policies to the class-default class of another child
policy, the class-default class of a parent policy, or to other classes defined in parent and child
policies.
Note
This applies only to VLAN-group policies. For other QoS policies, you must apply child
policies only to the class-default class of a parent policy.
Do not configure any other QoS actions for a parent class if you apply a child policy to that class.
For a VLAN-group policy, if a class of a parent policy map specifies the service-policy command,
do not configure any other QoS actions for that class.
Configure only the shape command in outbound parent classes of a VLAN-group policy if a child
policy is applied to that class.
Configuring VLAN-Group Class Maps

To configure a VLAN-group class map, which creates a VLAN-group traffic class, enter the following
Step 1
Command
Purpose
Router(config)# class-map match-any

class-map-name
Creates or modifies a traffic class. Enters class-map

configuration mode.
(Optional) match-any indicates that if the VLAN ID of a
packet matches any of the specified VLAN IDs, classify the
packet as belonging to the traffic class.
Note
The router does not support the match-all keyword

for VLAN-based classification.
class-map-name is the name of the class map. You can

specify the class-default class as the class map name to
configure a traffic class to which the router assigns all of the
traffic that does not match another configured class.
Step 2
Router(config-cmap)# match vlan vlanid
Configures VLANs as the criteria the router uses to match

packets to the traffic class.
vlanid is a VLAN identification number(s) or a range of
numbers. Valid values are from 1 to 4095.
Examples
The following example configuration creates a VLAN group named customer1 with VLANs 2, 3, 4, 5,
and 7 as members of the group:
Router> enable
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# class-map match-any customer1
Router(config-cmap)# match vlan 2 3-5 7
21-8
OL-7433-09
Chapter 21

Configuring a VLAN-Group Policy

Use the following configuration tasks to configure a VLAN-group policy:
Configuring QoS Policies for Traffic ClassesInbound VLAN Group and Class-Default Classes,
page 21-9
Configuring QoS Policies for Traffic ClassesOutbound VLAN Group and Class-Default Classes,
page 21-10
Attaching VLAN Tag-based Policies, page 21-12
Configuring QoS Policies for Traffic ClassesInbound VLAN Group and Class-Default Classes
The class-default class is the only non-VLAN-group class allowed in a VLAN-group policy.
To configure an inbound QoS policy for VLAN-group traffic classes and the class-default class, enter
Step 1
Command
Purpose
Creates or modifies a policy map for inbound traffic. Enters

policy-map-name is the name of the inbound policy map.
The name can be a maximum of 40 alphanumeric
characters.
Step 2
Router(config-pmap)# class vgrp-cmap-name
Assigns the traffic class you specify to the inbound policy

map. Enters policy-map class configuration mode.
vgrp-cmap-name is the name of a previously configured
match-vlan class map.
Step 3
policy-map-name
Applies the policy map you specify to the inbound

VLAN-group traffic class.
policy-map-name is the name of the policy map that you
want to apply to the traffic class.
Step 4
Configures the class-default class for inbound traffic.

Note
Step 5
policy-map-name
The router uses the class-default class to apply QoS

services to all of the traffic that does not belong to
any other VLAN-group traffic class.
Applies the policy map you specify to the inbound default

traffic class.
want to apply to the default traffic class.

OL-7433-09
21-9
Chapter 21
Example
The following example configuration shows how to configure a VLAN-group policy for inbound traffic.
In the example, QoS policies are created for VLAN traffic (policy1 and policy2) and for default traffic
(policy5). The policy map named input applies QoS services to VLAN groups and to the class-default
class for all of the inbound traffic that does not belong to the VLAN groups classes.
Router(config-pmap)# class vgrp2
Router(config-pmap-c)# class vgrp1
!
!
!
Router(config)# policy-map input
Router(config-pmap)# class vgrp-customer1
Router(config-pmap-c)# service-policy policy1
Router(config-pmap-c)# class vgrp-customer2
Configuring QoS Policies for Traffic ClassesOutbound VLAN Group and Class-Default Classes
To configure an outbound QoS policy for VLAN group traffic classes and the class-default class, enter
Step 1
Command or Action
Purpose
Creates or modifies a policy map for outbound traffic.

policy-map-name is the name of the outbound policy map.
The name can be a maximum of 40 alphanumeric
characters.
Step 2
Assigns the traffic class you specify to the outbound policy

map. Enters policy-map class configuration mode.
define QoS actions. For a VLAN-group policy, specify the
name of a VLAN group traffic class.
21-10
OL-7433-09
Chapter 21

Step 3
Command or Action
Purpose

mean-rate

(Optional) average indicates that the Committed Burst (Bc)
is the maximum number of bits sent out in each interval.
(Optional) mean-rate is also called committed information
rate (CIR). Indicates the bit rate used to shape the traffic, in
bits per second. When this command is used with backward
explicit congestion notification (BECN) approximation, the
bit rate is the upper bound of the range of bit rates that will
be permitted.
Step 4
policy-map-name
(Optional) Applies the policy map you specify to the

outbound traffic class.
Step 5
Configures the class-default class for outbound traffic.

The router uses the class-default class to apply QoS services
to all of the traffic that does not belong to any other traffic
class.
Step 6

mean-rate
Shapes the default traffic to the indicated bit rate.

(Optional) average indicates that the Committed Burst (Bc)
is the maximum number of bits sent out in each interval.
(Optional) mean-rate is also called committed information
rate (CIR). Indicates the bit rate used to shape the traffic, in
bits per second. When this command is used with backward
explicit congestion notification (BECN) approximation, the
bit rate is the upper bound of the range of bit rates that will
be permitted.
Step 7
policy-map-name
Applies the policy map you specify to the outbound default

traffic class.
want to apply to the default traffic class.
Example
The following example configuration shows how to configure a QoS policy for outbound VLAN-group
traffic. In the example, QoS policies are created for VLAN traffic (policy1 through policy4) and for
default traffic (policy5). The policy map named output applies QoS services to VLAN groups and to the
class-default class for all of the traffic that does not belong to the VLAN groups classes.
!

OL-7433-09
21-11
Chapter 21
!
Router(config-pmap-c)# random-detect dscp 6
!
Router(config-pmap-c)# random-detect dscp 3
!
!
Router(config)# policy-map output-policy
Router(config-pmap)# class vgrp-customer1
Router(config-pmap-c)# class vgrp-customer2
Attaching VLAN Tag-based Policies

You must attach a VLAN tag-based policy to a main interface. The router does not support a VLAN
tag-based policy on a subinterface.
To attach a VLAN tag-based policy to an interface, enter the following commands beginning in global
configuration mode:
Step 8
Command or Action
Purpose
Router(config)# interface slot/module/port

type is the interface type, which must be Ethernet, Fast
Ethernet, or Gigabit Ethernet.
1/0/0.1).
(Optional) point-to-point indicates that the subinterface
is a point-to-point subinterface.
21-12
OL-7433-09
Chapter 21

Configuration Examples for VLAN Tag-Based QoS
Step 9
Command or Action
Purpose
Router(config-if)# encapsulation dot1q vlan-id
Enables IEEE 802.1Q encapsulation of traffic on the

specified subinterface in a virtual LAN (VLAN
vlan-id is the virtual LAN identifier. The allowed range is
from 1 to 4095. For the IEEE 802.1Q-in-Q VLAN Tag
Termination feature, the first instance of this argument
defines the outer VLAN ID, and the second and
subsequent instances define the inner VLAN ID.
Step 10
Router(config-if)# service-policy [input |

output] policy-map-name
Applies the policy map you specify to the interface.

input indicates to apply the policy to inbound traffic.
output indicates to apply the policy to outbound traffic.
Example
The following example configuration shows how to attach a VLAN tag-based policy named policy1 to
the Gigabit Ethernet main interface 1/0/0 for outbound traffic.
Router(config)# class-map match-any vlan-customer1
Router(config-cmap)# match vlan 10 -20
Router(config-cmap)# class-map child
Router(config-cmap)# match prec 1
Router(config)# policy-map child-cust1
Router(config-pmap)# class child
Router(config-pmap)# policy-map policy1
Router(config-pmap)# class vlan-customer1
Router(config-pmap-c)# service-policy child-cust1
!
Router(config-subif)# interface GigabitEthernet 1/0/0

Configuring a VLAN Tag-Based QoS Policy: Example, page 21-14
Configuring a VLAN Tag-Based QoS Policy: Invalid Configuration Example, page 21-14

OL-7433-09
21-13
Chapter 21
Configuring a VLAN Tag-Based QoS Policy: Example

The following configuration example shows how to configure a VLAN tag-based QoS policy using the
PRE3 hierarchical queuing framework. In the example, the policy map named service1 defines QoS
services for two VLAN traffic classes: vlans_5_to_10 and vlans_11_to_14. The child-policy1 defines
QoS services for voice, video, data, and default traffic, and is applied to both of the VLAN classes in
service1.
policy-map child-policy1
class voip
police 1000000
priority level 1
class video
police 5000000
priority level 2
class data
class class-default
policy-map service1
class vlans_5_to_10
service-policy child-policy1
class vlans_11_to_14
service-policy child-policy1
Configuring a VLAN Tag-Based QoS Policy: Invalid Configuration Example

The following configuration example shows an invalid configuration in which the subinterface-shaper
policy is attached to the Gigabit Ethernet subinterface 1/1/1.5 and the vlangroup-shapers policy is
attached to the main interface, Gigabit Ethernet interface 1/1/1. In this example, the traffic classes
defined in the subinterface-shaper policy match the VLAN-group classes in the vlangroup-shapers
policy. As a result, this configuration is invalid because the router does not support the attachment of a
QoS policy on a subinterface that matches any of the VLAN-group traffic classes in a policy attached to
the main interface.
policy-map subinterface-shaper
class class-default
!
policy-map vlangroup-shapers
class vlan_5_to_10
class vlan_11_to_14
!
interface GigabitEthernet 1/1/1
service-policy output vlangroup-shapers
!
21-14
OL-7433-09
Chapter 21

Related Documents
service-policy output subinterface-shaper
Related Documents
Related Topic
Document Title
802.1Q VLANs
Configuring IOS Wide-Area Networking Configuration Guide,

Release 12.2
Configuring Broadband Access: PPP and Routed Bridge
Encapsulation > Configuring PPPoE over IEEE 802.1Q VLANs
Bandwidth and priority queues
Comparing the Bandwidth and Priority Commands of a QoS Service

Policy
Bandwidth starvation

Prioritizing Services > Low-Latency Priority Queuing >
QoS Congestion Management (Queuing), Introduction
Hierarchical policy maps

Policing and shaping

Release 12.2
Priority queues

Release 12.2
Part 2: Congestion Management > Configuring Priority Queues

OL-7433-09
21-15
Chapter 21
Related Documents
21-16
OL-7433-09
CH A P T E R
22

The performance routing engine (PRE3 and PRE4) supports a hierarchical queuing framework (HQF)
for scheduling and queuing. This HQF architecture enables service providers to manage their QoS
services at three or four layers of hierarchy. The scheduler uses the HQF to allocate excess bandwidth
among the subscriber queues and logical interfaces. The scheduler services queues based on the
maximum rate and bandwidth-remaining ratio you specify.
This chapter describes hierarchical scheduling and queuing, and includes the following topics:
Hierarchical Queuing Framework, page 22-1
MQC Hierarchical Queuing with 3-Level Scheduler, page 22-5
4-Level Scheduler, page 22-10

The hierarchical queuing framework (HQF) defines a QoS architecture for implementing hierarchical
packet scheduling and queuing on the PRE3 and PRE4. The HQF enables service providers to manage
their QoS at three or four levels of hierarchy. The 3-level HQF scheduler uses the following hierarchy:
Physical layerUsed for shaping the physical interface such as the OC-3 port.
Logical layerUsed to schedule subinterfaces such as a VLAN or PPP sessions.
Class layerUsed for class queues, defined using the modular QoS command line interface (MQC)
policy map.
The 4-level HQF scheduler uses the same hierarchy as above, except that it splits the logical layer into
an upper logical layer for sessions and a lower logical layer for subinterfaces. For more information, see
the 4-Level Scheduler section on page 22-10.
The parallel express forwarding (PXF) engine performs all packet-level scheduling using the HQF.
Figure 22-1 shows the 3-level HQF hierarchy.

OL-7433-09
22-1
Chapter 22
Figure 22-1
HQF 3 Layers of Hierarchy
Pkt queues
Class Layer
Logical LayerVLAN or ATM

VC
Note
153924
Physical LayerInterface or ATM

VP
The PRE1 and PRE2 use the virtual time management system (VTMS) scheduling algorithm and do not
support the HQF architecture.
Feature History for Hierarchical Queuing Framework

Cisco IOS Release
Description
Required PRE
Release 12.2(31)SB2
PRE3
Release 12.2(33)SB
PRE3, PRE4
Hierarchical Queuing Framework Scaling

The hierarchical queuing framework (HQF) supports the following interfaces:
61,500 logical interfaces
16,000 physical interfaces
Up to 15 queues per interface (2 priority queues [PQs], 12 nondefault queues, and 1 default queue)
22-2
OL-7433-09
Chapter 22

QoS Shaping Using HQF

The PRE3 and PRE4 support QoS shaping using the HQF algorithm. The following sections describe
how the HQF is used to provide shaping for various QoS models:
ATM Virtual Path Shaping Using HQF, page 22-3
ATM VC Shaping Using HQF, page 22-3
Hierarchical ATM VP and VC Shaping Using HQF, page 22-4
Subinterface Shaping Using HQF, page 22-4
IP and PPP Session Shaping Using HQF, page 22-5
ATM Virtual Path Shaping Using HQF

A permanent virtual path (PVP) is used to multiplex one or more virtual circuits (VCs). To create a PVP,
use the atm pvp command in interface configuration mode:
atm pvp vpi peak-rate [no-f4-oam]
The HQF algorithm treats ATM virtual paths (VPs) as physical interfaces and uses the peak rate you
specify to shape bandwidth. The ATM segmentation and reassembly (SAR) mechanism is configured the
same as on the PRE2.
The following example shows how to create a PVP with a peak rate of 50,000 kbps:
interface atm 7/0/0
atm pvp 25 50000
ATM VC Shaping Using HQF

HQF treats ATM VCs created on the physical interface as logical interfaces and the ATM port as the
physical layer. The PRE3 and PRE4 do not support ATM SAR-based VC shaping.
The following examples show how to configure ATM VC shaping for the PRE3 and PRE4. The
configuration creates a variable bit rate-nonreal-time (VBR-nrt) VC on the physical ATM interface with
a service policy applied to it. HQF shapes the VC traffic according to the sustained cell rate (SCR) of
the VC (512 kbps). The service policy applied to the interface creates two separate class queues on the
VC: real-time and class-default.
policy-map pppoe_vc_out
class real-time
violate-action drop
priority
class class-default
random-detect aggregate
random-detect precedence values 0 minimum-thresh 10 maximum-thresh 20 mark-prob 10
random-detect precedence values 1 minimum-thresh 40 maximum-thresh 80 mark-prob 10
interface ATM 1/0/0.1 point-to-point
pvc 0/110
vbr-nrt 512 512 94
service-policy output pppoe_vc_out

OL-7433-09
22-3
Chapter 22
Hierarchical ATM VP and VC Shaping Using HQF

When VCs are created in a virtual path (VP), HQF treats the VCs as logical interfaces and the VP as the
physical interface.
HQF shapes the aggregate traffic from all of the VCs at both the packet and ATM levels (see the ATM
Virtual Path Shaping Using HQF section on page 22-3). However, the parallel express forwarding
(PXF) engine shapes the VCs at the packet level. Therefore, VC-level ATM shaping is not guaranteed to
be compliant to an ATM layer policer at the VC level. Multiple cells from the same VC are sent back at
the rate of the VP. The ATM SAR is configured the same as on the PRE2.
The following example shows how to create VBR-nrt VCs in a VP tunnel and apply service policies to
each of the VCs. HQF shapes the VCs individually according to their SCR parameter and shapes the
aggregate traffic from all of the VCs at the VP rate. The service policies applied to the VCs create class
queues on each one of the VCs. Note that unless oversubscription is enabled, the aggregate rates of the
VCs cannot exceed the VP rate.
interface atm 7/0/0
atm pvp 25 50000
pvc 25/100
vbr-nrt 10000 5000 16
pvc 25/101
vbr-nrt 10000 7000 16
pvc 25/110
vbr-nrt 10000 2000 16
Subinterface Shaping Using HQF

HQF treats subinterfaces (such as VLANs, QinQ, Frame Relay DLCIs, and so on) at the lower logical
layer. To shape a subinterface, apply a service policy to the subinterface.
Note
You cannot simultaneously apply service policies to the physical interface and the subinterface.
For example, to shape the aggregate traffic on a VLAN subinterface, apply a hierarchical policy to the
subinterface as shown in the following configuration. In this example, the VLAN is shaped at 100 kbps.
policy-map child
class precedence0
class precedence1
random-detect
policy-map parent
class class-default
22-4
OL-7433-09
Chapter 22

MQC Hierarchical Queuing with 3-Level Scheduler
IP and PPP Session Shaping Using HQF

HQF treats IP and PPP sessions at the upper logical layer to provide bandwidth sharing and maximum
rate shaping. To shape IP or PPP sessions, apply a service policy to the sessions using a virtual template
or a RADIUS server.
HQF allows the oversubscription of sessions on a subinterface (such as VLAN, QinQ, or VC) and at the
same time also allows oversubscription of the VLAN or VC on a physical port. During congestion, HQF
fairly shares the bandwidth first at the subinterface (lower logical layer) and then among the sessions
(upper logical layer). HQF takes the bandwidth that was distributed to the subinterface and fairly shares
it among the sessions of that subinterface. HQF then takes the bandwidth distributed to a session and
fairly shares it among the class queues of that session.

The MQC Hierarchical Queuing with 3-Level Scheduler feature enables you to configure per-session
QoS and subinterface shaping of the aggregate session traffic. This feature provides a flexible packet
scheduling and queuing system in which you can specify how excess bandwidth is to be allocated among
the subscriber queues and logical interfaces. Rather than allocating an implicit minimum bandwidth
guarantee to each queue, the 3-level scheduler uses the bandwidth-remaining ratio parameter to allocate
unused bandwidth to each logical queue. The 3-level scheduler services queues based on the following
user-configurable parameters:
Note
Maximum rateThe specified shape rate of the parent queue
Bandwidth-remaining ratioThe value used to determine the portion of unused, nonguaranteed

bandwidth allocated to a logical queue relative to other queues competing for the unused bandwidth
At the class level, the router converts the values you specify for the bandwidth bps and bandwidth
remaining percent commands to a bandwidth-remaining ratio value. The router does not allow you to
configure the bandwidth bps and bandwidth remaining percent commands on the physical and logical
layers.
The 3-level scheduler on the PRE3 supports priority propagation by propagating the priority guarantees
you configure for subscriber services down to the logical interface level. Therefore, the priority traffic
is serviced first at the logical and class level. After servicing the priority traffic bandwidth, the 3-level
scheduler allocates unused bandwidth to the logical queues based on the configured
bandwidth-remaining ratio. In the default case, the 3-level scheduler allocates an equal share of the
unused bandwidth to each logical queue.
For ATM VCs, the 3-level scheduler shares bandwidth proportionally to each VCs bandwidth, if no
bandwidth remaining ratio (BRR) or VC weight is configured. For other types of subinterfaces, the
scheduler distributes the bandwidth equally, unless BRR is configured. The scheduler uses a default BRR
value of 1 if BRR is not specified, except for the ATM logical layer as mentioned above. The logical
layer BRR is completely independent from the BRRs configured at the class layer.
The 3-level scheduler supports shaping and scheduling only on the egress interface. The bandwidth
command must be configured as a percentage of the available bandwidth or as an absolute bandwidth.
You cannot concurrently configure the bandwidth and bandwidth remaining commands on the same
class queue or the same policy map.
For more information about the bandwidth-remaining ratio, see the Distribution of Remaining
Bandwidth Using Ratio section on page 5-14.

OL-7433-09
22-5
Chapter 22
For more information about the 4 level scheduler, see the 4-Level Scheduler section on page 22-10
Feature History for MQC Hierarchical Queuing with 3-Level Scheduler

Cisco IOS Release
Description
PRE Required
Release 12.2(31)SB2

Cisco 10000 series router for the PRE3.
PRE3
Release 12.2(33)SB
This feature was introduced on the PRE4 for the

Cisco 10000 series router.
PRE4
Prerequisites for MQC Hierarchical Queuing with 3-Level Scheduler

Traffic classes must be configured on the router using the class-map command.
Restrictions for MQC Hierarchical Queuing with 3-Level Scheduler
We recommend that the sum of all priority traffic on a given interface not exceed 90 percent of the
physical bandwidth of that interface.
The 3-level scheduler does not support bandwidth propagation. Therefore, you cannot configure a
bandwidth guarantee for any queue other than a priority queue.
To allow oversubscription provisioning, the admission control check is not performed.
The sum of all priority traffic running on a given port must be less than or equal to 90 percent of the
port bandwidth.
Scheduling Hierarchy
As shown in Figure 22-1, the 3-level scheduler uses the following scheduling hierarchy to allocate
bandwidth for subscriber traffic:
Class layerThe 3-level scheduler uses virtual-time calendars to schedule class queues.
Logical layer (subinterface, session, or ATM VC)Virtual-time calendars perform weighted round
robin based on the weight of the logical interface and the number of bytes dequeued.
Physical layer (interface or ATM virtual path)A real-time calendar ensures that the maximum rate
for the class and the logical interface are not exceeded.
By using VP and VC scheduling with existing Cisco 10000 ATM line cards, the scheduler supports
priority propagation: cell-based VP shaping in the segmentation and reassembly (SAR) mechanism with
frame-based VC scheduling in the performance routing engine 3 (PRE3).
22-6
OL-7433-09
Chapter 22

Priority Service and Latency

The 3-level scheduler supports two levels of priority queues; for example, level 1 for voice traffic and
level 2 for video traffic.
For a priority class with policing configured, the 3-level scheduler always polices the priority traffic to
the rate specified in the police command (1000 kbps as shown in the following sample configuration),
regardless of whether or not the underlying interface is congested.
Note
The 3-level scheduler does not support the priority kbps command.
Latency Requirements
Delay-sensitive traffic incurs a maximum of 10 milliseconds (ms) of latency on edge router interfaces
and a maximum of 1 ms of latency on core router interfaces. For interface speeds at T1/E1 and below,
the 3-level scheduler services 2 maximum transmission units (MTUs) of nonpriority traffic before
servicing a priority packet. Requirements for high-speed interfaces are not as strict as 2 MTUs, but are
always bound by 10 ms on edge interfaces and 1 ms on core interfaces.
The 3-level scheduler also supports the minimal latency requirement (2 MTUs of nonpriority traffic in
front of priority traffic) at the physical link rate. However, in some cases, it is impossible for the 3-level
scheduler to service all competing packets with a latency of 2 MTUs. For example, if many priority
packets compete at the same time for bandwidth, the last one serviced may incur latency that is greater
than 2 MTUs.
Table 22-1 lists the maximum latency requirements for various interface speeds.
Table 22-1
Maximum Latency Requirements
Interface Speed
Maximum Latency
Greater than 2 Mbps
2 MTU + 6 ms
2 Mbps to 1 Gbps
2 MTU
1 Gbps or greater
1 ms
Priority Propagation with Imposed Burstiness

A single physical interface can have large numbers of logical interfaces and each of these logical
interfaces can have both priority and nonpriority traffic competing for the physical link. To minimize
latency, the priority traffic of one logical interface has priority over the nonpriority traffic of other logical
interfaces, thereby imposing burstiness on the minimum rate traffic of other logical interfaces. The
latency that the priority traffic incurs results from the rate constraining the delivered rate of the priority
traffic. In many cases, this constraining rate is not the rate of the priority classs parent policy.
For example, suppose a 10 Gigabit Ethernet (GE) interface has 100 VLANs that are shaped to various
rates. Each VLAN has a priority class and additional classes configured. Through priority propagation,
the scheduler delivers latency to the priority traffic based on the 10 GE rate and not the VLAN rate.

OL-7433-09
22-7
Chapter 22
Note
The VLAN rate is at most 1 to 2 MTUs of nonpriority traffic in front of priority traffic, which would
bound the latency incurred by priority traffic (due to nonpriority traffic) at 1 to 2 MTUs served at the 10
GE rate.
The priority traffic of one logical interface cannot only impose burstiness on other traffic, but also starve
other traffic. The only way to prevent the starvation of other traffic is by configuring a policer on the
priority queue by limiting the percent of priority traffic to less than 90 percent of the parent bandwidth
and the port bandwidth.
Configuring MQC Hierarchical Queuing with 3-Level Scheduler

To configure the 3-level scheduler by allocating excess bandwidth, use the bandwidth remaining ratio
command. For more information, see the Distribution of Remaining Bandwidth Using Ratio section
on page 5-14.
Configuration Examples for MQC Hierarchical Queuing with 3-Level Scheduler

Bandwidth AllocationPolicy Attached to an Interface: Example, page 22-8
Tuning the Bandwidth-Remaining Ratio: Example, page 22-9
Bandwidth AllocationPolicy Attached to an Interface: Example

The following sample configuration consists of one policy map named Child with the following traffic
classes defined: prec0, prec2, and class-default. The policy is attached to ATM interface 1/0/0.
policy-map Child
class prec0
bandwidth 300
class prec2
bandwidth 100
class class-default
bandwidth 50
!
interface atm 1/0/0
service-policy output Child
Assuming that the traffic flow through each class is enough to require maximum possible bandwidth, the
3-level scheduler allocates bandwidth as described in Table 22-2.
Table 22-2
Queuing PresentationPolicy Attached to an Interface
Traffic Class
Bandwidth Ratio
Total Bandwidth Allocated
prec0
666 kbps
prec2
222 kbps
class-default
111 kbps
22-8
OL-7433-09
Chapter 22

Tuning the Bandwidth-Remaining Ratio: Example

The following sample configuration shows how to tune the bandwidth-remaining ratio using the
bandwidth remaining ratio command. In the example, the class-default class of Parent1 has a
bandwidth-remaining ratio of 9 and the class-default class of Parent2 has a bandwidth-remaining ratio
of 7.
policy-map Child
class prec0
police 100
priority level 1
!
class prec2
police 300
priority level 2
!
policy-map Parent1
class class-default
shape average 10000
!
policy-map Parent2
class class-default
shape average 1000
Figure 22-2 shows an example of the queuing presentation based on the above configuration and
assuming that the Parent1 policy is enabled on subinterface 1 and the Parent2 policy is enabled on
subinterface 2, and that the interface speed is 2100 kbps.

OL-7433-09
22-9
Chapter 22
4-Level Scheduler
Figure 22-2
Queuing PresentationTuning the Bandwidth-Remaining Ratio
Video
Voice
Min: 100
Priority
Max: 100
Default
Min: 300
Priority
Max: 300
Min: 0
Bandwidth-remaining
ratio: 7
Max: 1000
Subinterface 2
Subinterface 1
Default
Min-rate : 0 kbps
Bandwidth-remaining
ratio: 7
Max-rate : 1000 kbps
Min-rate : 0 kbps
Bandwidth-remaining
ratio: 9
Min-rate : 0 kbps
Bandwidth-remaining
ratio: 1
Interface with
2100 kbps speed
190035
Interface
Based on the preceding configuration, the 3-level scheduler distributes bandwidth in the following way
(assuming that the voice traffic is active on subinterface 1 only and the video traffic is active on
subinterface 2 only):
A total of 400 kbps of bandwidth is used from the interface: 100 kbps-bandwidth guarantee for voice
traffic on subinterface 1 and 300-kbps bandwidth guarantee for video traffic on subinterface 2.
The remaining 1700-kbps bandwidth is distributed across the subinterface-level queues based on
their bandwidth-remaining ratios:
Subinterface 1 with bandwidth-remaining ratio 9 receives 956 kbps.
Subinterface 2 with bandwidth-remaining ratio 7 receives 743 kbps.
4-Level Scheduler
The 4-Level Scheduler feature enables you to configure per-session QoS and subinterface shaping of the
aggregate session traffic, just as the 3-level scheduler does. However, unlike the 3-level scheduler, the
4-level scheduler uses the following scheduling hierarchy to allocate bandwidth for subscriber traffic:
Class layerThe 4-level scheduler uses virtual-time calendars to schedule class queues and logical
interfaces.
Session layer (upper logical)Virtual-time calendars perform weighted round robin based on the
weight of the logical interface and the number of bytes dequeued.
Subinterface layer (lower logical) (VLAN, QinQ, or ATM VC)Virtual-time calendars ensure that
the maximum rate for the class and the logical interface are not exceeded.
22-10
OL-7433-09
Chapter 22

4-Level Scheduler
Note
The subinterface layer (lower logical) supports the bandwidth remaining ratio command for Ethernet
VLANs and ATM VCs, and the weight command for ATM VCs.
Physical layer (Ethernet interface or ATM virtual path)A real-time calendar ensures that the
maximum rate for the class and the logical interface are not exceeded.
The 4-level scheduler provides bandwidth sharing and maximum rate shaping among the sessions at the
session layer (upper logical) and at the same time among the VLANs and VCs at the subinterface layer
(lower logical). The scheduler supports the simultaneous oversubscription of the sessions on a VLAN or
VC and of the VLAN or VC on a physical port.
During congestion, the 4-level scheduler does the following:
1.
Shares bandwidth fairly at the VLAN, QinQ, or VC level.
2.
Shares the distributed VLAN, QinQ, or VC bandwidth fairly among the sessions of that VLAN,
QinQ, or VC.
3.
Shares the bandwidth distributed to a session fairly among the class queues of that session.
The 4-level scheduler is disabled by default.
Note
The router does not convert 3-level queuing hierarchies to 4-level hierarchies. Instead, if 3 levels are
needed, then the router uses only 3 levels.
For information about the 3-level scheduler, see the MQC Hierarchical Queuing with 3-Level
Scheduler section on page 22-5.
Feature History for 4-Level Scheduler

Cisco IOS Release
Description
PRE Required
Release 12.2(33)XNE1
This feature was introduced on the Cisco 10000 series

router for the PRE3 and PRE4.
PRE3, PRE4

OL-7433-09
22-11
Chapter 22
Feature
Class-based shaping

Class maps

Policing
Policy maps


Tech Note
Tech Note
Quality-of-Service Overview Tech Note
Traffic shaping

22-12
OL-7433-09
A P P E N D I X
Configuring Frame Relay QoS Using Frame Relay

Legacy Commands
This appendix describes how to configure Frame Relay QoS using Frame Relay legacy commands using
the following procedures:
1.
Creating a Map Class, page A-1
2.
Enabling Weighted Fair Queuing on the Interface, page A-2
3.
Specifying a DLCI Queue Weight, page A-2
4.
Specifying Tail Drop, page A-3
5.
Enabling RED Drop, page A-3
6.
Configuring Frame Relay IP RTP Priority, page A-4
7.
Configuring Frame Relay Traffic Shaping, page A-5
Creating a Map Class

To create a Frame Relay map class, enter the following command in global configuration mode:
Command
Purpose

class-map-name
Creates a Frame Relay map class.

Example A-1 creates a map class named camry.

Example A-1
Configuring a Frame Relay Map Class
Router(config)# map-class frame-relay camry

Router(config-map-class)#

OL-7433-09
A-1
Appendix A

Frame Relay weighted fair queuing allows each PVC to receive a weighted share of the link bandwidth.
To enable Frame Relay weighted fair queuing to the interface, enter the following command in map class
configuration mode:
Command
Purpose
Router(config-map-class)# frame-relay
interface-queue fair
Enables weighted fair queuing.

Note
An error message displays if a service policy is already

attached to the interface.
Example A-2 enables Frame Relay weighted fair queuing.

Example A-2
Enabling Frame Relay Weighted Fair Queuing
Router(config-map-class)# frame-relay interface-queue fair

Specifying a DLCI Queue Weight

Frame Relay weighted fair queuing allows each PVC to receive a weighted share of the link bandwidth.
To allocate more or less bandwidth share to a PVC, use the following command in map class
configuration mode:
Command
Purpose
interface-queue fair weight weight
Specifies a DLCI queue weight.

weight is the value assigned to the DLCI (1 to 99). If you do not
specify a value, the router treats all PVCs equally.
Example A-3 sets the DLCI queue weight to 80.

Example A-3
Configuring a DLCI Queue Weight
Router(config-map-class)# frame-relay interface-queue fair weight 80

A-2
OL-7433-09
Appendix A


You can only specify one packet drop policy on a Frame Relay interface, either tail drop or RED drop.
To set the maximum threshold for packet tail drop, enter the following command in map class
configuration mode. This procedure is optional.
Command
Purpose
interface-queue fair queue-limit limit
Configures tail drop.

limit is the queue maximum threshold value for packet drop.
Valid values are from 32 to 16,384 in powers of 2 (for example,
64, 128, 256, and so on).
Example A-4 sets the threshold limit for packet drop to 2048.
Example A-4
Configuring Tail Drop
Router(config-map-class)# frame-relay interface-queue fair queue-limit 2048

Enabling RED Drop

You can only specify one packet drop policy on a Frame Relay interface. You cannot configure RED on
a priority queue.
To enable RED drop to distribute traffic losses in the event of a buffer overflow, enter the following
commands in map class configuration mode:
Command
Purpose
Step 1
interface-queue fair random-detect
(Optional) Enables RED drop.
Step 2
exponential-weight-constant exp
Specifies an exponential weight constant.
precedence [precedence min_threshold
max_threshold probability]
Specifies precedence parameters.
Step 3
exp is the exponential-weight-constant value and is a number

from 1 to 16.
precedence is a number between 0 and 7, where 0 represents
low-priority traffic and 7 represents high-priority traffic.
min_threshold is the number of packets from 1 to 32,768.
max_threshold is the number of packets from 1 to 32,768.
probability is the mark-probability-denominator value. Valid

OL-7433-09
A-3
Appendix A
Example A-5 sets the exponential weight constant to 16.

Example A-5
Setting the Exponential Weight Constant
Router(config-map-class)# frame-relay interface-queue fair random-detect

Router(config-map-class)# frame-relay interface-queue fair random-detect
exponential-weight-constant 16
Example A-6 sets the precedence parameters.

Example A-6
Setting the Precedence Parameters
Router(config-map-class)# frame-relay interface-queue fair random-detect precedence 2

32000 32000 65000
Router(config-map-cl)#

The Frame Relay IP RTP Priority feature allows Voice over Internet Protocol (VoIP) packet classification
at the DLCI level. This classification is based on whether or not the packet IP Real-Time Protocol (RTP)
has an even-numbered UDP port within (or outside of) the specified range. Only even ports are matched
because they carry the real-time data streams. Odd ports are not matched because they only carry control
information. If the IP RTP even-numbered port is within the configured range, the packet is identified as
a real-time packet. Real-time packets are given higher priority than regular data packets and are queued
to a priority output queue.
Note
You must configure the Frame Relay weighted fair queue interface to use this feature (see Specifying
a DLCI Queue Weight section on page A-2). A priority queue is created for each DLCI that has
frame-relay ip rtp priority configured.
Parameters for Frame Relay IP RTP priority are configured using the map-class frame-relay command
(see the Creating a Map Class section on page A-1). When a map class with IP RTP defined is
associated with a Frame Relay interface, all DLCIs created for that interface are assigned a priority
queue for the RTP packets. A different map class can be associated with a different DLCI, which means
each DLCI is assigned a different RTP port range.
The following are examples of priority queues:
DLCI 2 RTP queue
DLCI 1 RTP queue
The following are examples of non-priority queues:
NCQ
DLCI 3 data queue
DLCI 2 data queue
A-4
OL-7433-09
Appendix A

To specify the RTP priority policy, enter the following command in map class configuration mode:
Command
Purpose
Router(config-map-c)# frame-relay ip rtp priority

min_udp_port port_range bandwidth
Specifies the Frame Relay IP RTP priority policy.

min_udp_port is the starting UDP destination port number. Valid
numbers are from 2000 to 65,535.
port_range is the range of UDP destination port values. Valid
bandwidth is the maximum allowed bandwidth in kbps. Valid
Example A-7 sets the IP RTP priority parameters for the map class named voice-traffic and applies the
class to serial interface 1/0/0/1:1. The example also assigns DLCI 927 and DLCI 928 to the voice-traffic
class.
Example A-7
Setting the IP RTP Priority Parameters
Router(config)# map-class frame-relay voice-traffic

Router(config-map-c)# frame-relay ip rtp priority 16384 16383 128
Router(config-if)# frame-relay interface-queue fair
Router(config-if)# frame-relay class voice-traffic

The Cisco 10000 series router supports Frame Relay traffic shaping (FRTS) and generic traffic shaping
(GTS) on Frame Relay interfaces; however, you cannot enable both of these interfaces at the same time.
While GTS supports traffic at the modular CLI level, FRTS supports traffic shaping per PVC on the
interface by using Frame Relay encapsulation.

OL-7433-09
A-5
Appendix A
To configure Frame Relay traffic shaping, enter the following commands beginning in interface
configuration mode:
Step 1
Command
Purpose

map-class-name
Creates a Frame Relay map class for Frame Relay traffic shaping.
Step 2
Router(config-map-c)# frame-relay
traffic-rate bps
Sets the traffic shape rate.

bps is a number from 1 to 45,000,000.
or
Router(config-map-c)# frame-relay cir bps
Sets the committed information rate (CIR).
and
Router(config-map-c)# frame-relay mincir
bps
Sets the minimum rate in times of congestion.
Step 3
Step 4

slot/subslot/port
Configures the interface you specify.
Step 5
Router(config-if)# ip address ip-address

subnet-mask
Configures an IP address and subnet mask for the interface.
Step 6
frame-relay
Enables Frame Relay encapsulation.
Step 7
traffic-shaping
Enables Frame Relay traffic shaping.
Step 8
Router(config-if)# frame-relay class

map-class-name
Applies the Frame Relay map class to the DLCIs on this interface.
Step 9
interface-dlci dlci-number
Creates the DLCIs on this interface. The DLCIs inherit the Frame
Relay map class applied on this interface.
Example A-8 creates a Frame Relay map class named frts with a committed information rate of 64,000
and a minimum rate of 64,000 during congestion. The example enables traffic shaping on serial
interface 1/0/0/1:1. DLCI 27, created on the interface, inherits the frts class applied to the interface.
Example A-8
Enabling Frame Relay Traffic Shaping
Router(config)# map-class frame-relay frts

Router(config-map-c)# frame-relay cir 64000
Router(config-map-c)# frame-relay mincir 64000
Router(config-if)# frame-relay traffic-shaping
Router(config-if)# frame-relay class frts
A-6
OL-7433-09
A P P E N D I X
QoS Policy Propagation Through the Border

Gateway Protocol
QoS Policy Propagation through Border Gateway Protocol (QPPB) allows you to classify packets by IP
precedence based on BGP community lists, BGP autonomous system paths, and access control lists
(ACLs). After a packet has been classified, you can use other QoS features such as policing and weighted
random early detection (WRED) to specify and enforce policies to fit your business model.
This appendix provides an example of how to:
1.
Create route maps to match BGP community lists, access control lists, and BGP AS paths
2.
Apply IP precedence to routes learned from neighbors

In this example, the Cisco 10000 series router learns routes from autonomous system (AS) 10 and AS 60.
QoS policy is applied to all packets that match the defined route maps. Any packets from the
Cisco 10000 series router to AS 10 or AS 60 are sent to the appropriate QoS policy (Figure B-1).
Cisco 10000 Series Router Routes and QoS Policy Application
1. Route announced
2. Route arrives
3. QoS policy applied
Cisco
10000
series
Autonomous
system 60
Router
B
Autonomous
system 30
Autonomous
10737
Figure B-1
system 10
4. Packet sent with QoS policy

OL-7433-09
B-1
Appendix B
Cisco 10000 Series Router Configuration

Router(config)# router bgp 30
Router(config)# table-map precedence-map
Router(config-router)# neighbor 20.20.20.1 remote-as 10
Router(config-router)# neighbor 20.20.20.1 send-community
Router(config-router)# neigh 20.20.20.1 route-map precedence-map out
!
Router(config)# ip bgp-community new-format
Match community 1, set the IP precedence to priority, and set the QoS group to 1.
Router(config)# route-map precedence-map permit 10
Router(config-route-ma)# match community 1
Router(config-route-ma)# set ip precedence priority
Router(config-route-ma)# set ip qos-group 1
Match community 2 and set the IP precedence to immediate.

Router(config-route-ma)# set ip precedence immediate
Match community 3 and set the IP precedence to Flash.

Router(config-route-ma)# set ip precedence flash
Match community 4 and set the IP precedence to Flash-override.

Router(config-route-ma)# set ip precedence flash-override
Match community 5 and set the IP precedence to critical.

Router(config-route-ma)# set ip precedence critical
Match community 6 and set the IP precedence to internet.

Router(config-route-ma)# set ip precedence internet
Match community 7 and set the IP precedence to network.

Router(config-route-ma)# set ip precedence network
Match IP address access list 69 or match AS path 1, set the IP precedence to critical, and set the QoS
group to 9.
Router(config-route-ma)# match ip address 69
Router(config-route-ma)# match as-path 1
Router(config-route-ma)# set ip precedence critical
Router(config-route-ma)# set ip qos-group 9
For everything else, set the IP precedence to routine.

Router(config-route-ma)# set ip precedence routine
B-2
OL-7433-09
Appendix B

Define the community lists.

Router(config)#
Router(config)#
Router(config)#
Router(config)#
Router(config)#
Router(config)#
Router(config)#
ip
ip
ip
ip
ip
ip
ip
community-list
community-list
community-list
community-list
community-list
community-list
community-list
1
2
3
4
5
6
7
permit
permit
permit
permit
permit
permit
permit
60:1
60:2
60:3
60:4
60:5
60:6
60:7
Define the AS path.

Router(config)# ip as-path access-list 1 permit ^10_60
Define the access control list.

Router(config)# access-list 69 permit 69.0.0.0
Router B Running Configuration

RouterB(config)# router bgp 10
RouterB(config-router)# neighbor 30.30.30.1 remote-as 30
RouterB(config-router)# neighbor 30.30.30.1 send-community
RouterB(config-router)# neigh 30.30.30.1 route-map send_community out
!
RouterB(config)# ip bgp-community new-format
Match prefix 10 and set community to 60:1.

RouterB(config)# route-map send_community permit 10
RouterB(config-route-ma)# match ip address 10
RouterB(config-route-ma)# set community 60:1






OL-7433-09
B-3
Appendix B

For all others, set community to 60:8.

Define the access control lists.

RouterB(config)#
RouterB(config)#
RouterB(config)#
RouterB(config)#
RouterB(config)#
RouterB(config)#
RouterB(config)#
access-list
access-list
access-list
access-list
access-list
access-list
access-list
10
20
30
40
50
60
70
permit
permit
permit
permit
permit
permit
permit
61.0.0.0
62.0.0.0
63.0.0.0
64.0.0.0
65.0.0.0
66.0.0.0
67.0.0.0
The following example shows how to configure several interfaces to classify packets based on the IP
precedence and QoS group ID:
interface serial 5/0/0/1:0
ip address 200.28.38.2 255.255.255.0
bgp-policy source ip-prec-map
no ip mroute-cache
no cdp enable
frame-relay interface-dlci 20 IETF
interface serial 6/0/0/1:0
ip address 200.28.28.2 255.255.255.0
bgp-policy source ip-qos-group
no ip mroute-cache
no cdp enable
frame-relay interface-dlci 20 IETF
Feature
QoS Policy Propagation through Border Gateway

Protocol (QPPB)

Release 12.2
Part 1: Classification > Classification Overview > QoS Policy
Propagation via Border Gateway Protocol
Part 1: Classification > Configuring QoS Policy Propagation via
B-4
OL-7433-09
GLOSSARY
A
AAA
authentication, authorization, and accounting (pronounced triple a).
AAL5
See ATM adaptation layer 5.
ABR
See available bit rate.
ADSL
See asymmetric digital subscriber line.
anonymous link
A link that does not provide a PPP username or endpoint. Multilink PPP (MLP) combines all of the
anonymous links into a single bundle called an anonymous bundle or default bundle.
asymmetric digital
subscriber line
A digital subscriber line (DSL) technology in which the transmission of data from server to client is
much faster than the transmission from the client to the server.
Asynchronous
Transfer Mode
International standard for cell relay in which multiple service types (such as voice, video, or data) are
conveyed in fixed-length cells. Fixed-length cells allow cell processing to occur in hardware, thereby
reducing transit delays. ATM is designed to take advantage of high-speed transmission media such as
E3, SONET, and T3.
ATM adaptation
layer 5
This layer maps higher layer user data into ATM cells, making the data suitable for transport through
the ATM network.
available bit rate
QoS class defined by the ATM Forum for ATM networks. ABR is used for connections that do not
require timing relationships between source and destination. ABR provides no guarantees in terms of
cell loss or delay, providing only best-effort service. Traffic sources adjust their transmission rates in
response to information they receive describing the status of the network and its capability to
successfully deliver data.
ATM
See Asynchronous Transfer Mode.
B
bandwidth
The range of frequencies a transmission line or channel can carry. The greater the bandwidth, the
greater the information-carrying capacity of a channel. For a digital channel this is defined in bits. For
an analog channel it is dependent on the type and method of modulation used to encode the data.
BGP
See Border Gateway Protocol.
Border Gateway
Protocol
Interdomain routing protocol that exchanges reachability information with other BGP systems. It is
defined in RFC 1163.

OL-7433-09
GL-1
Glossary
bps
Bits per second. A standard measurement of digital transmission speeds.
bundle
A logical group of permanent virtual circuits (PVCs) with one virtual interface connecting to a peer
system.
C
CAR
Committed access rate.
CBR
See constant bit rate.

See Class-based Weighted Fair Queuing.
CBWFQ
CEF
See Cisco Express Forwarding.
child policy
A policy map that defines one or more classes of traffic and the actions you want the router to take on
the traffic, just as non-hierarchical policy maps do. However, in hierarchical policy maps, child policies
are nested within a top-level parent policy, and then the parent policy is attached to the interface.
CIR
See committed information rate.
Cisco express
forwarding
An advanced Layer 3 IP switching technology. Cisco express forwarding (CEF) optimizes network
performance and scalability for networks with large and dynamic traffic patterns such as the Internet,
on networks characterized by intensive Web-based applications, or interactive sessions.
class-based
weighted fair
queuing
Extends the standard weighted fair queuing (WFQ) functionality to provide support for user-defined
traffic classes. For class-based weighted fair queuing (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 queue is reserved for each class and
traffic belonging to a class is directed to the queue for that class. On the Cisco 10000 series router, the
CBWFQ feature allows a virtual access interface (VAI) to inherit the service policy of the virtual circuit
(VC) that the VAI uses.
class maps
A modular QoS CLI element that you can use to define traffic classification rules or criteria. Class maps
organize data packets into specific categories called classes that can, in turn, receive user-defined QoS
policies. The traffic class defines the classification rules for packets received on an interface.
class of service
The three most significant bits (the User Priority bits) of the 2-byte Tag Control Information field in
the IEEE 802.1p portion of a Layer 2 IEEE 802.1Q frame header. QoS uses the User Priority bits for
Layer 2 CoS information. IEEE 802.1p class of service-based packet matching and marking feature
enables the Cisco 10000 series router to interoperate with switches to deliver end-to-end QoS. The
IEEE 802.1p standard allows QoS to classify inbound Ethernet packets based on the value in the class
of service (CoS) field and to explicitly set the value in the CoS field of outbound packets.
committed
information rate
The reserved bandwidth for the queue. The rate at which a Frame Relay network agrees to transfer
information under normal conditions, averaged over a minimum increment of time. Committed
information rate (CIR), measured in bits per second, is one of the key negotiated tariff metrics.
constant bit rate
QoS class defined by the ATM Forum for ATM networks. Constant bit rate (CBR) is used for
connections that depend on precise clocking to ensure undistorted delivery.
CoS
See class of service.
GL-2
OL-7433-09
Glossary
D
data-link connection A value that specifies a PVC in a Frame Relay network. In the basic Frame Relay specification, DLCIs
identifier
are locally significant (connected devices might use different values to specify the same connection).
In the LMI extended specification, DLCIs are globally significant (DLCIs specify individual end
devices).
DLCI
See data-link connection identifier.
downstream rate
The line rate for return messages or data transfers from the network machine to the users customer
premises machine.
DSCP
Differentiated service code point.
DSL
Digital Subscriber Line.
E
encapsulation
The technique used by layered protocols in which a layer adds header information to the protocol data
unit (PDU) from the layer above.
endpoint
discriminator
A value a system uses when negotiating the use of Multilink PPP (MLP) with the peer system. The
default value is the username that is used for authentication.
Ethernet
One of the most common local area network (LAN) wiring schemes, Ethernet has a transmission rate
of 10, 100, or 1000 Mbps.
F
fragmentation
See link fragmentation and interleaving.
G
GE
Gigabit Ethernet.
GRE
Generic Route Encapsulation. A method of encapsulating any network protocol in another protocol.
H
hierarchical policy
A QoS policy in which multiple policies are configured into a single QoS policy. The hierarchical
policy combines one or more classes to apply specific actions on the aggregate traffic and to execute
class-specific actions. The non-hierarchical policy, on the other hand, defines only class-specific
actions. Hierarchical policies can have up to three levels configured.

OL-7433-09
GL-3
Glossary
hierarchical input
policing
A QoS model that defines policing policies at multiple levels of hierarchy for inbound packets. See also
HTML
Hypertext Markup Language. The page-coding language for the World Wide Web.
http
Hypertext Transfer Protocol. The protocol used to carry world-wide web (www) traffic between a www
browser computer and the www server being accessed.
I
interleaving
Internet
A collection of networks interconnected by a set of routers that allow them to function as a single, large
virtual network.
Internet Protocol
The network layer protocol for the Internet protocol suite.
IP
See Internet Protocol.
L
LFI
link fragmentation
and interleaving
The ability to fragment network level datagrams (and possibly interleave them) at the link layer.
Multilink inherently includes link fragmentation and interleaving capabilities, as do some other
technologies such as ATM.
load balancing
In routing, the capability of a router to distribute traffic over all its network ports that are the same
distance from the destination address. Good load-balancing algorithms use both line speed and
reliability information. Load balancing increases the use of network segments, thus increasing effective
network bandwidth.
M
Management
Information Base
Database of network management information that is used and maintained by a network management
protocol, such as SNMP or CMIP (Common Management Information Protocol). The value of a MIB
object can be changed or retrieved using SNMP commands, usually through a Network Management
System (NMS). MIB objects are organized in a tree structure that includes public (standard) and private
(proprietary) branches.
marking
A QoS tool used to differentiate packets based on designated markings. Using marking, you can
partition your network into multiple priority levels or classes of service. Marking simplifies the
network Qos design and QoS tools configuration, and reduces the overhead of packet classification by
other QoS tools.
MIB
See Management Information Base.
MLP
See Multilink PPP.
GL-4
OL-7433-09
Glossary
MLP bundle
A virtual interface that connects to a peer system. MLP bundles consist of multiple physical links.
MP
See Multilink PPP.
Modular QoS
command-line
interface
Also referred to as modular CLI. A platform-independent CLI for configuring QoS features on Cisco
products.
MPLS
See Multiprotocol Label Switching.
MPLS VPN
MPLS-based virtual private network.
MQC
See modular QoS command-line interface.
multicast
Single packets copied by the network and sent to a specific subset of network addresses. These
addresses are specified in the Destination Address Field.
Multilink PPP
Multilink Point-to-Point Protocol, RFC 1990. Commonly abbreviated as MLP within Cisco; however,
the correct abbreviation is MP. This protocol is a method of splitting, recombining, and sequencing
datagrams across multiple logical data links.
multipoint
subinterface
Multipoint networks have three or more routers in the same subnet. For Dynamic Bandwidth Selection,
if you put the PVC in a point-to-multipoint subinterface or in the main interface (which is multipoint
by default), you need to either configure a static mapping or enable inverse Address Resolution
Protocol (ARP) for dynamic mapping.
Multiprotocol Label
Switching
Switching method that forwards IP traffic using a label. This label instructs the routers and the switches
in the network where to forward the packets based on preestablished IP routing information.
N
NAS
See network access server.
nested hierarchical
policy
A QoS model that defines policies at two levels of hierarchy. See also hierarchical policies.
NetFlow
A Cisco-proprietary IP statistics collection feature that collects information on IP flows passing

through a router.
network access
server
Cisco platform (or collection of platforms) that interfaces between the packet world (for example, the
Internet) and the circuit world (for example, PSTN).
NVRAM
See Non-Volatile Random Access Memory.
Non-Volatile
Random Access
Memory
The router uses this memory to store configuration information. The contents of this memory are not
lost after a reboot or power cycle of the unit.

OL-7433-09
GL-5
Glossary
O
oversubscription
A method of improving network utilization by assigning a committed rate that is greater than the speed
of an interface or subinterface, or greater than the capacity of a VC port.
P
parent policy
A QoS policy that defines the shape rate for the child traffic on an interface. The parent policy contains
only the class-default class; it can contain no other classes.
PCR
See peak cell rate.
peak cell rate
Parameter defined by the ATM Forum for ATM traffic management.
permanent virtual
circuit
Virtual circuit that is permanently established. PVCs save bandwidth associated with circuit
establishment and tear down in situations where certain virtual circuits must exist all the time. In ATM
terminology, called a permanent virtual connection. See also virtual circuit (VC).
permanent virtual
path
A virtual path that consists of PVCs.
Point-to-Point
Protocol
The successor to SLIP, Point-to-Point Protocol (PPP) provides router-to-router and host-to-network
connections over both synchronous and asynchronous circuits.
point-to-point
subinterface
With point-to-point subinterfaces, each pair of routers has its own subnet. If you put the PVC on a
point-to-point subinterface, the router assumes that there is only one point-to-point PVC configured on
the subinterface. Therefore, any IP packets with a destination IP address in the same subnet are
forwarded on this VC. This is the simplest way to configure the mapping and is, therefore, the
recommended method.
policing
A traffic regulation mechanism that is used to limit the rate of traffic streams. Policing allows you to
control the maximum rate of traffic sent or received on an interface. Policing propagates bursts of traffic
and is applied to the inbound or outbound traffic on an interface. When the traffic rate exceeds the
configured maximum rate, policing drops or remarks the excess traffic.
policy map
A modular CLI (MQC) element that enables you to create QoS policies to tell the router the QoS actions
and rules to apply to packets belonging to a particular traffic class.
PPP
See Point-to-Point Protocol.
PPPoA
PPP over ATM. Enables a high-capacity central site router with an Asynchronous Transfer Mode
(ATM) interface to terminate multiple remote PPP connections.
PPPoE
PPP over Ethernet. Allows a PPP session to be initiated on a simple bridging Ethernet connected client.
Refers to a signaling protocol defined within PPPoE as well as the encapsulation method. See also
RFC 2516.
PPPoEoA
PPP over Ethernet over ATM. Allows tunneling and termination of PPP sessions over Ethernet links
and allows for Ethernet PPP connections over ATM links.
PPPoEoE
PPP over Ethernet over on Ethernet. Allows tunneling and termination of PPP sessions over Ethernet
links and allows for Ethernet PPP connections over Ethernet links.
GL-6
OL-7433-09
Glossary
PPPoEo802.1Q
VLAN
PPP over Ethernet over IEEE 802.1Q VLANs. Allows tunneling and termination of Ethernet PPP
sessions across VLAN links. IEEE 802.1Q encapsulation is used to interconnect a VLAN-capable
router with another VLAN-capable networking device. The packets on the 802.1Q link contain a
standard Ethernet frame and the VLAN information associated with that frame.
PPPoX
PPP over PPPoA or PPPoE or both.
PQ
See priority queuing.
priority queuing
A class queue that is given priority over other queues. The router dequeues and transmits priority queue
data before it dequeues and sends packets in other queues. Using priority queuing, delay-sensitive data
such as voice receives preferential treatment over other traffic.
PTA
PPP termination aggregation. A method of aggregating IP traffic by terminating PPP sessions and
aggregating the IP traffic into a single routing domain.
PTA-MD
PTA Multi-Domain. A method of aggregating IP traffic by terminating PPP sessions and aggregating
the IP traffic into a VPN or multiple IP routing domains.
PVC
See permanent virtual circuit or connection.
PVP
See permanent virtual path.
Q
QoS
See quality of service.
QPPB
QoS policy propagation through the Border Gateway Protocol.
quality of service
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. Cisco IOS QoS technology lets complex networks
control and predictably service a variety of networked applications and traffic types.
queue depth
A user-configurable limit on the number of packets that the router can place onto a queue. During
periods of high traffic, a queue fills with packets waiting for transmission. When a queue reaches its
queue depth and becomes full, by default the router drops packets until the congestion is eliminated and
the queue is no longer full.
queuing delay
Amount of time that data must wait before it can be transmitted onto a statistically multiplexed physical
circuit.
R
RADIUS
Remote Authentication Dial-In User Service (RADIUS). A client/server security protocol created by
Livingston Enterprises. Security information is stored in a central location, known as the RADIUS
server.

OL-7433-09
GL-7
Glossary
random early
detection
An alternative mechanism for avoiding congestion of Layer 3 queues. Random early detection (RED)
implements a proactive queuing strategy that manages congestion before a queue reaches its queue
depth or limit.
RIP
Routing Information Protocol. An IGP used to exchange routing information within an autonomous
system, RIP uses hop count as a routing metric.
route
The path that network traffic takes from its source to its destination. The route a datagram follows can
include many gateways and many physical networks. In the Internet, each datagram is routed
separately.
router
A system responsible for making decisions about which of several paths network (or Internet) traffic
will follow. To do this, it uses a routing protocol to gain information about the network and algorithms
to choose the best route based on several criteria known as routing metrics.
routing table
Information stored within a router that contains network path and status information. It is used to select
the most appropriate route to forward information along.
S
See sustainable cell rate.
SCR
sustainable cell rate Parameter defined by the ATM Forum for ATM traffic management. For VBR connnections, SCR
determines the long-term average cell rate that can be transmitted.

SVC
See switched virtual circuit.
switched virtual
circuit
A virtual circuit that is dynamically established on demand and is torn down when transmission is
complete. SVCs are used in situations where data transmission is sporadic. Called a switched virtual
connection in ATM terminology.
T
tail drop
The default congestion avoidance mechanism for Layer 3 queues. Tail drop activates when a queue
becomes full. After being activated, no packets make it to the queue. Tail drop treats all traffic equally
and does not differentiate between classes of service.
three-level
hierarchical policy
A QoS model that defines policies at three levels of hierarchy. See also hierarchical policies.
token bucket
An algorithm used o manage the maximum rate of traffic. This algorithm defines the maximum rate of
traffic allowed on an interface at a given moment in time. The token bucket algorithm is especially
useful in managing network bandwidth in cases where several large packets are sent in the same traffic
stream. The algorithm puts tokens into the bucket at a certain rate. Each token is permission for the
source to send a specific number of bits into the network.
ToS
Type of service. First defined in RFC 791.
GL-8
OL-7433-09
Glossary
U
UBR
See unspecified bit rate.
unspecified bit rate
A QoS class defined by the ATM Forum for ATM networks. UBR allows any amount of data up to a
specified maximum to be sent across the network, but there are not guarantees in terms of cell loss rate
and delay.
upstream rate
The line rate for message or data transfer from the source machine to a destination machine on the
network.
V
VAI
See virtual access interface.
VBR
See variable bit rate.
VBR-nrt
See variable bit rate-nonreal time.
VBR-rt
See variable bit rate-real time.
VC
See virtual circuit.
VCI
See virtual channel identifier.
VCL
See virtual channel link.
variable bit rate
A QoS class defined by the ATM Forum for ATM networks. Variable bit rate (VBR) is subdivided into
a real time (rt) class and nonreal time (nrt) class. See also variable bit rate-nonreal time and variable
bit rate-real time.
variable bit
rate-nonreal time
A QoS class defined by the ATM Forum for ATM networks. Variable bit rate-nonreal time (VBR-nrt)
is used for connections in which there is no fixed timing relationship between samples, but that still
need a guaranteed QoS.
variable bit rate-real A QoS class defined by the ATM Forum for ATM networks. Variable bit rate-real time (VBR-rt) is used
time
for connections in which there is a fixed timing relationship between samples.
virtual access
interface
An instance of a unique virtual interface that is created dynamically and exists temporarily. Virtual
access interfaces can be created and configured differently by different applications, such as virtual
profiles and virtual private dialup networks (VPDNs).Virtual access interfaces are cloned from virtual
template interfaces.
virtual channel
identifier
A 16-bit field in the header of an ATM cell. The virtual channel identifier (VCI), together with the VPI,
is used to identify the next destination of a cell as it passes through a series of ATM switches on its way
to its destination. ATM switches use the VPI/VCI fields to identify the next network VCL that a cell
needs to transmit on its way to its final destination. The function of the VCI is similar to that of the
DLCI in Frame Relay.
virtual channel link
Connection between two ATM devices. A virtual channel connection is made up of one or more VCLs.

OL-7433-09
GL-9
Glossary
virtual circuit
Logical circuit created to ensure reliable communication between two network devices. A virtual
circuit is defined by a VPI/VCI pair, and can be either permanent (PVC) or switched (SVC). Virtual
circuits are used in Frame Relay and X.25. In ATM, a virtual circuit is called a virtual channel.
Sometimes abbreviated VC.
virtual LAN
A group of devices on one or more local area networks (LANs) that are configured (using management
software) so that they can communicate as if they were attached to the same wire, when in fact they are
located on a number of different LAN segments. Because virtual LANs (VLANs) are based on logical
instead of physical connections, they are extremely flexible.
virtual path
One of two types of ATM circuits identified by a VPI. A virtual path is a bundle of virtual channels,
all of which are switched transparently across an ATM network based on a common VPI.
virtual path
identifier
An 8-bit field in the header of an ATM cell. The VPI, together with the VCI, is used to identify the next
destination of a cell as it passes through a series of ATM switches on its way to its destination. ATM
switches use the VPI/VCI fields to identify the next VCL that a cell needs to transmit on its way to its
final destination. The function of the VPI is similar to that of the DLCI in Frame Relay.
virtual template
interface
A logical interface configured with generic configuration information for a specific purpose or
configuration common to specific users, plus router-dependent information. The template takes the
form of a list of Cisco IOS interface commands that are applied to virtual access interfaces, as needed.
VLAN
See virtual LAN.
VPI
See virtual path identifier.
W
WAN
See wide area network.
weighted fair
queuing
Congestion management algorithm that identifies conversations (in the form of traffic streams),
separates packets that belong to each conversation, and ensures that capacity is shared fairly between
these individual conversations. WFQ is an automatic way of stabilizing network behavior during
congestion and results in increased performance and reduced retransmission.
weighted random
early detection
A mechanism for avoiding congestion of Layer 3 queues. Weighted random early detection (WRED)
combines the capabilities of the random early detection (RED) mechanism with IP precedence,
differential services code point (DSCP), and discard-class to provide preferential handling of higher
priority packets. WRED attempts to anticipate and avoid congestion. WRED implements a proactive
queuing strategy that manages congestion before a queue reaches its queue depth. By selectively
dropping packets, WRED prevents packets from enqueuing to the Layer 3 queue.
WFQ
See weighted fair queuing.
wide area network
A data communications network that spans any distance and is usually provided by a public carrier
(such as a telephone company or service provider).
WRED
See Weighted Random Early Detection.
X
GL-10
OL-7433-09
Glossary
xDSL
Various types of digital subscriber lines. Examples include ADSL, HDLS, and VDSL.

OL-7433-09
GL-11
Glossary
GL-12
OL-7433-09
INDEX
cell loss priority
Numerics
marking
3-level hierarchical policies
parent policies
matching
10
14
setting CLP bit
802.1P headers, in nested hierarchical policies

8K policy maps
14
3, 29
comparing committed rate data for policing and

shaping 5
configuring VBR-nrt VC oversubscription

interface QoS inheritance
11
12
line cards
aa5snap
maximum VCs supported
16
VC scaling and hierarchical shaping
AAA
user profiles
oversubscription factor
5, 14
AAL5 CPCS padding
access list command
10
ACL
queuing modes
9
7
service categories
atm pxf queuing mode
activating traffic engineering

on routers
15, 4
queuing outbound traffic
4, 10, 12, 13
on interfaces
13
no atm pxf queuing mode
23
13
traffic classes
21
in atm pxf queuing mode
adding
ATM bundle members
23
ATM PVCs to bundles
23
in no atm pxf queuing mode

allowable oversubscription
bundle members directly
ATM line cards
43
Frame Relay bundle members directly
48
virtual circuits
unshaped
AF, See assured forwarding.
17
17
assured forwarding, DSCP code point
5, 6
ATM CLP
in random-detect command
ATM
atm pxf queuing command
WRED
31
11
13, 15, 3, 5, 31, 8, 25
configuration examples
attaching policies containing the set cos command
See also oversubscription.
45
Frame Relay bundle members using map classes

aggregate drop profiles
VC oversubscription
Frame Relay
attaching policies
26
description
10

OL-7433-09
IN-1
Index
verification examples
minimum guaranteed queue buffers
13
atm oversubscribe command
minimum percentage
atm over-subscription-factor command

atm pxf queuing command
atm vc-per-vp command
2, 10
overriding default queue limit
15, 8, 7
recalculation after bandwidth changes
14
ATM VC queue depth

for flow control
10, 8, 9, 11, 13, 16, 14, 37, 47, 26, 46
overheads in ATM networks
5, 31, 7, 15, 6, 11
1, 4, 10, 3
39
AToM
reservation
restrictions
26
specifying bandwidth with the priority command
set ATM CLP bit

set FR DE bit
starvation
13
total bandwidth
14
attaching
4, 10
unused bandwidth
MPLS QoS policies to interfaces

VC classes to ATM bundles
bandwidth command
22
VC classes to bundle members
verifying and monitoring bandwidth
average cell rate,specifying for constant bit rate PVCs

average queue size
2, 7
non-supporting interfaces
bandwidth percent command
controlling queue length
20
modifying method of calculation
12
5, 6, 10, 11, 16, 34
interfaces supporting
27
9, 3
3
4
bandwidth remaining command
7, 3
bandwidth-remaining command
bandwidth remaining percent command
10, 3, 8
BBA group
attaching to interfaces
bba-group command
bandwidth
allocating PVC bandwidth share
allocating unused bandwidth
28
27
configuration example
configuring PPPoE
27
27
Bc
assigning to DLCIs and PVCs
avoiding bandwidth starvation
25, 2
bandwidth remaining command
committed burst
specifying
bandwidth remaining percent command
12, 13, 18, 53
See also committed burst.
10, 14, 37, 47,
26, 46
21
Be
committed rate data for policing and shaping

comparing bandwidth and priority
converting specified bandwidth
distributing between queues
excess bandwidth
metering
2, 4, 10
specifying
10
BECN
Frame Relay networks
2, 10
11
2, 4, 10
maximum queues supported
22
12, 13
best effort, BE (DSCP 0)
10, 8, 9, 11, 13, 16, 14, 37, 47, 26, 46
limiting, advantage of shaping and policing

maximum percentage
22
See also excess burst.
kilobits per second
calculating
4, 7
bits
14
bottom-level policies
nesting child policies
13
using set and police commands
IN-2
OL-7433-09
Index
BRAS-DSLAM encapsulation types

bump command
bump command (Frame Relay VC-bundle-member)

bump explicit command
bump implicit command
33
calculating
bandwidth in kilobits per second
bandwidth percentage
bumping
circuit
committed burst
17
not accepting bumped traffic, configuring

traffic in bundles
bumping PVCs
27
3, 16
4, 10
excess burst
22
policing rate
25
3
CBR, See constant bit rate.
6, 9
cbr command
16
13, 8
CBS, See committed burst.
adding
ATM PVC members
bundle members
CBWFQ
23
4, 7
service policy inheritance
23
Frame Relay members directly
CDVT
43, 45
Frame Relay members using map classes
48
CEF
VC classes
20
in random-detect command
29
WRED
creating
ATM bundles
configuration guidelines
mapping for PVC bundles
1
31
traffic bumping
verifying bundles
13
31
description of
16
nested hierarchical policies
system limits for bundles
hierarchical input policing policies
52
restrictions for bundles
9, 12, 14
creating in three-level hierarchical policies
40
mapping MPLS EXP to bundle members
PVC selection
bandwidth percent command
49
4, 14
protection rules
11
child policies
36, 42
Frame Relay configuration examples
monitoring bundles
31
cell loss priority, setting the CLP bit
18, 20
Frame Relay bundles

management of
12, 27
cell loss priority
22, 27
12, 27
cell delay variation tolerance
attaching
PVC
4, 10
22
call admission check
16
bundle command
bundles
CAC, See call admission check.
10
three-level hierarchical policies
using set and police commands
CIR, See committed information rate.
17
2
circuit bumping
17
class
3
28
class-default
9, 12
burst-excess
deleting from policy map
burst-normal
maximum non-class-default classes

traffic class
17
9
4, 16
class-based traffic shaping

OL-7433-09
IN-3
Index
class-based weighted fair queuing, See CBWFQ.
configuring using tail drop
class-bundle command
configuring using WRED packet drop
class command
description of
19, 3, 5
allocating queue IDs
11
maximum number
minimum bandwidth guarantee
classification
classification byte counts
class-vc command
by DSCP
command line interface, See modular QoS CLI for

implementing QoS.
by IP precedence level
creating class maps
commands
access list
1, 11, 12
defining match criteria
restrictions and limitations
11
verifying traffic criteria

class-map command
atm pxf queuing

atm vc-per-vp
13
bandwidth
12
defining
11
bandwidth remaining
7, 3
bandwidth-remaining
bump
3, 1
3, 4
match statements
bump implicit
class
for Layer 2 to Layer 3 mapping

for prioritizing packets
11
13, 8
19, 9, 10, 21
class-map
class-vc
10
3, 12
9, 10
dbs enable
10
12
dscp (Frame Relay VC-bundle-member)
21
class policies
configuring in a policy map
class-map match
11
33
6, 9
class-bundle
class of service
recommended values
bump explicit
cbr
IEEE 802.1p standard
27
bundle
5, 7
maximum number supported
10, 3
bump (Frame Relay VC-bundle-member)
for per session rate limiting
system limits
6, 10, 34
bba-group
example configuration
Frame Relay
14
bandwidth remaining percent
description of
31, 15, 6, 11
15, 8
bandwidth percent
10
class maps
classifying traffic
atm over-subscription-factor
3, 12
class-map match command
10
atm oversubscribe
IP packets using class maps
creating
CLP, See ATM cell loss priority.
by group ID
6, 7
CLI, See modular QoS CLI for implementing QoS.
12
classifying packets
marking
scaling limits
class selector code points
defining match criteria
12
class queues
19, 5, 9, 10, 21
class-default class
11
encapsulation dot.1q
19
encapsulation dot1.q
22
34
IN-4
OL-7433-09
Index
exp other
ppp multilink
16
ppp multilink fragmentation
36
frame-relay class
19, 16, 45
frame-relay interface-dlci
17, 16
frame-relay interface-queue
frame-relay ip rtp priority
precedence
2, 3
precedence other
frame-relay traffic rate
priority
interface multilink
protect
36
pvc
match-all
12, 13
15
pvc-bundle
match-any
queue-depth
match cos
queue-limit
match discard-class
match fr-de
service-policy
set
match mpls-experimental
match mpls experimental topmost
set discard-class
15, 9, 6
5, 6, 9
5, 6, 9, 5
set mpls experimental topmost
11, 35
3, 9, 21
15, 4
16
5, 6, 9, 13
5, 6, 10, 4
show atm class-links
police percent
5, 6, 11
shape
11
16
19
set qos-group
10
5, 6, 9
policy-map
5, 6, 9, 14
set mpls experimental
mpls ip encapsulate explicit-null

no atm pxf queuing
3, 10, 5
set ip precedence
5, 6, 12
set ip dscp
mpls experimental other
police
set cos
set fr-de
mpls experimental
oam retry
8, 4
set atm-clp
16
match mpls-experimental-imposition
match qos-group
random-detect precedence
match ip precedence
oam-bundle
5, 6
random-detect exponential-weight-constant
match ip rtp
5, 6, 4
random-detect dscp
match ip dscp
16, 22, 24, 38
random-detect
match input-interface
match-not
12
qos match statistics
39
8, 9, 13
pvc-in-range
10
38
28
pvc (Frame Relay VC-bundle)
12, 19, 54, 4
1, 5
match access-group
protocol pppoe group
10, 11
26
map-class frame-relay
match
38
protect (Frame Relay VC-bundle-member)
interface virtual-template
37
5, 6, 10
propagate-cos
ip rsvp bandwidth
8, 9, 26
precedence (Frame Relay VC-bundle-member)
16
frame-relay vc-bundle
11
frame-relay map-class
frame-relay traffic-shape
show atm interface

show caller
41
41
16

OL-7433-09
IN-5
Index
show class-map
discard-class marking
13, 16
show controllers
Frame Relay traffic shaping
41
show ha pxf cpu queue summary

show hardware pxf
show interface
queue size
33
32
show pxf cpu queue summary
33
sub-pool
ubr
WRED based on ATM CLP
33
31
WRED based on discard class
33
WRED based on DSCP
42
29
26
WRED based on IP precedence
26
28
conforming traffic
conform-action
8, 9
7, 6, 10, 20
metering and conforming token bucket
vbr-nrt
16, 8
vc-class
29
packet sizes
9, 11
virtual-template
token buckets, single-rate policer
27
tail drop
6, 9, 21, 8
committed rate, policing data
controlling using random early detection

32
management of
queue limit
configuring
ATM cell loss priority marking
25
constant bit rate
29
bumping rules, Frame Relay members
22
13, 8
10
creating
26
differentiated services code point marking
34
controlling, average queue length

33
11
restrictions for controlling
ATM bundle members, VC class
8, 9
using weighted random early detection
6, 23
class of service marking
using random early detection

6, 9, 12
communicating directly with RADIUS, no proxy

community list
using precedence marking
22
committed information rate
18
controlling
committed burst
calculating
26
congestion
22, 24
burst size
21
specifying multiple conforming actions
vc-class atm
weight
20
zzzz>
15, 8
ubr+
RED, See configuring random early

detection.<configuring
show pxf cpu queue interface
show pxf interface
38
28
random early detection
33
33
show pxf cpu schedule
11, 26
QoS group marking
show pppoe session packets

show pxf cpu queue
QoS
8, 33, 27
20
show pppoe session all
31
protected bundle members, Frame Relay
12, 18, 28
show policy-map interface

show policy-map map
22
precedence levels for bundle members, Frame

Relay 37
32
12, 18, 28, 16
show policy-map class
5, 6
MPLS experimental marking
34, 33
show interfaces virtual-access
show vlans
IP precedence marking
32, 23, 32
show policy-map
33
ATM bundles
18, 20
24
IN-6
OL-7433-09
Index
class maps
weighted random early detection based on DSCP
12
Frame Relay bundles

policy maps
differentiated services code point
36, 39, 42
map classes for Frame Relay
assured forwarding
binary values
19
CS1 through CS7
bits
code point values
DSCP
D
data, policing rate
23
allocating PVC bandwidth share
discard-class
marking traffic
17, 16
VoIP packet classification

IP RTP Priority
setting
12
6
displaying, statistics and configuration information for

policing 41
DBS, See dynamic bandwidth selection.

dbs enable command
16, 33
discard eligibility bit
See also DLCI.
DLCI
12
assigning
16
associating map classes to
default class
bandwidth-remaining command
default traffic class
delay, managing
based on CLP
31
drop policing action
12, 3
drop probability, assured forwarding classes
assured forwarding
assured forwarding, class drop probability
assured forwarding classes
best effort, DSCP 0
class selector code points
drop rate in random-detect command
10
interfaces not supporting drop policies
22
DiffServ suggested DSCP values
32
weighted random early detection
expedited forwarding, per-hop behavior

matching criteria
per-hop behavior
17
drop rate, random-detect command

DSCP, See differentiated services.
12
DS3/E3 line card, maximum virtual circuits supported
21
RFCs defining DSCP values
9, 11
drop profiles
for WRED
recommended values
21
verifying packet dropping
how RED determines drop probability

interfaces supporting drop policies
6, 7
compliance with IETF standards
setting DSCP bits
dropping packets
11
reserved keywords
16
DotP marking, in nested hierarchical policies
differentiated services
DSCP
values
RFCs, defining DSCPs
19
description of
DE bit
expedited forwarding
data-link connection identifier

assigning
names
DSCP-based mapping for PVC bundles
40
dscp command (Frame Relay VC-bundle-member)
34

OL-7433-09
IN-7
Index
DSLAM-CPE encapsulation types
policing policies
dynamic bandwidth selection

accounting record
affect on sessions
bandwidth updates
CBR PVCs
shaped rate and frame headers

police command
exceeding packets
individual PVC in a PVC range
12
comparing bandwidth and priority
excess burst
17
calculation of
9, 11
NAS QoS management
default size
PCR and SCR parameters
22
22
police command
5, 13
protocols supported
size
RADIUS attributes
13
specifying
EXP bit
service category
6, 22
22
12, 13
exp command, Frame Relay bundle member
changes to, restrictions

SVCs
18, 22
allocating unused bandwidth
debug commands
transitions
26
exceeding token bucket
10
restrictions
7, 6, 10, 20
excess bandwidth
11
VC classes
enabling
14
specifying multiple actions
PVC ranges
exceeding actions
configuring
PVCs
expedited forwarding
expedited forwarding, per-hop behavior
experimental field value, MPLS QoS
UBR unshaped transitions
35
average queue size

Frame Relay
21
random-detect command
exp other command
EBS, See excess burst size.
36
EF, See expedited forwarding.

encapsulation
subscriber line
encapsulation dot.1q command
19
encapsulation dot1.q command
22
encapsulation frame-relay command
fair queues
creating at three levels
16
Ethernet
creating at two levels

Fast Ethernet port

shaping 5
interface QoS inheritance
Ethernet overhead accounting
13
4
11, 12
15
13
21, 31
fe0/0/0 management port
21, 31
feedbacks, parallel express forwarding
18
flow control
on Layer 2 queues
39
forcing, PVC bundles down
IN-8
OL-7433-09
Index
fragmentation
differentiated service
Frame Relay
in DS-TE
attaching, QoS policies using map classes
16

shaping 5
configuring PVC oversubscription
creating map classes
DE bit
18
guaranteed minimum bandwidth
10
hierarchical input policing

42
child policies
3
oversubscription
15
6, 10
restrictions for
11
attaching
9
13
4
13
4, 7, 8, 10
configuring percent-based policing

description of
16, 19, 16, 45
frame-relay interface-dlci command
17, 19, 16
frame-relay interface-queue commands

frame-relay ip rtp priority command
frame-relay map-class command
16
frame-relay traffic rate command
frame-relay traffic-shape command

frame-relay vc-bundle command
2, 3
guidelines for configuring
13
hierarchical input policing
6, 10
interfaces not supporting hierarchical policies

interfaces supporting hierarchical policies
oversubscription
36
parent policies
4, 7, 8, 10
6, 8
verifying
FRTS, See Frame Relay traffic shaping.
29
27
hierarchical shaping
4, 5, 6
21
maximum line card virtual circuits
overview
19
12
11, 10
12
6, 7

types of
See also LFI.
34
global pool tunnels
22
configuring overhead accounting
2, 4
8, 5, 6
frame-relay class command
benefits of
child policies
QoS policies restrictions
weighted fair queuing
21
bandwidth percent command in child policies
physical interface QoS inheritance
traffic shaping
description of
hierarchical policies
priority queues
19
See also, hierarchical policies.
map classes
restrictions
10
configuring
4, 5
IP RTP priority (VoIP)
FRTS
green token bucket
13
FRF.12
global synchronization, maximizing
encapsulation types
PVCs
20
11, 12
drop policy
IP RTP
26
restrictions
4
8

OL-7433-09
IN-9
Index
shaped UBR PVCs

VC scaling
high watermark
hwm
bandwidth command
2, 7
12
22, 24, 25, 38
marking
20
packet drop policies
24, 38
See also high watermark.
policing
17
priority queuing
queue-limit
I
IEEE 802.1p, for inbound and outbound packets
IEEE 802.1Q, frame headers
random-detect
21
traffic shaping
13
5, 31, 2, 45
See also oversubscribing.
12
packet input match statement
10
ATM QoS
QoS inheritance
Frame Relay QoS

LAC QoS
21
oversubscribing
10
inbound interfaces, hierachical policies

inheritance
10
21
12
supporting the attachment of QoS policies
12
virtual LAN, queuing outbound traffic
30
interface multilink command
interleaving
internal marking
interfaces
ATM, queuing outbound traffic
discard-class
qos-group
attaching
ATM QoS policies
LAC QoS
11, 14, 15, 16, 17, 19
30
policy maps
QoS policies, service-policy command

virtual access interface QoS policies
configuring QoS
3
23
12
4
9
precedence levels 6 and 7
17
21
setting the precedence level

values
12
7, 4
weighted random early detection,

precedence-based 4, 5, 9, 11
20
packet drop policies
22
18
IP Real-Time Protocol
ip rsvp bandwidth command
priority queuing
22
random-detect
shaping
VoIP
recommended values
bandwidth command
queue-limit
DSCP value
IP precedence
interfaces not supporting
policing
Internet Engineering Task Force, differentiated services

RFCs 6
IP differentiated services, setting the DSCP bits
21, 22, 23, 31
Frame Relay, queuing outbound traffic
marking
13
Internet Protocol
12, 32
VLAN QoS policies
set qos-group
2, 5, 7, 8
Frame Relay QoS policies
IP RTP
26
4, 5
IP RTP priority for VoIP (Frame Relay)

22
13
IP sessions
configuration examples for MQC
23
interfaces supporting
IN-10
OL-7433-09
Index
configuring MQC
interface support
MQC support
IPv4 packets
45
locally originated traffic, subject to QoS policies
19
17
low-latency priority queuing, See priority queuing.
18
policy map actions

restrictions
per-session shaping
21
low watermark
19
20
LSR
lwm
24, 38
22, 24, 25, 38
See also low watermark.
J
jitter, managing
management information base, QoS MIBs

management port
21, 31
managing PVC bundles

attaching
10
priority queues
map classes
kilobits per second

bandwidth
10
16
oversubscribing Frame Relay PVCs

map-class frame-relay command
16
12, 19, 54, 4
mapping MPLS EXP to bundle members
label-controlled ATM subinterface, QoS inheritance

label imposition, MPLS
label switching router
13
class of service
attaching QoS policies
2, 10, 15
Layer 2, applying QoS policies to tunnel packets
class of service
32
Layer 2 access concentrator, attaching QoS policies
30
MLP over Frame Relay

MLP over serial
QoS group
description of
discard-class
single-VC MLP over ATM
DSCP marking
limiting, number of packets in queues
28
2
21
2, 16, 15
2, 15
interfaces not supporting marking
10
links, assigning bandwidth to DLCIs and PVCs

LNS
31
design guidelines for marking
24
22
MPLS experimental
multi-VC MLP over ATM

overview
26
33
IP precedence
3
29
differentiated services code point

discard-class
13
LFI
FRF.12 fragmentation
14
configuring
31
30
LC-ATM, QoS inheritance
31
marking
actions
15
LAC
QoS inheritance
interfaces supporting marking

IP precedence marking
20
20
2, 15
14

OL-7433-09
IN-11
Index
policing and marking traffic

QoS group marking
guidelines for changing
18
in the random-detect command
2, 13, 15
recommended values for marking

restrictions for traffic marking
set atm-clp command
MLP
20
set qos-group command
2, 15
verifying traffic marking
37
match command
pxf queuing
class map
3, 4
implementing QoS
12, 10
2, 34, 50, 29
3, 4
service-policy
3, 4
monitoring
1, 5, 9
bursts
match discard-class command
CE routers
16
MPLS experimental field
MPLS experimental
match mpls-experimental command
bits
16
match mpls-experimental-imposition command

match mpls experimental topmost command
4
8, 12, 31
mpls experimental command
8, 4
15
14
configuring marking
mpls experimental other command
match qos-group command
32
MPLS DiffServ tunneling modes
match ip precedence command

match ip rtp command
41
QoS policies
match input-interface command

match ip dscp command
23
policing
match-not command
4, 7
policy map
match fr-de command
4, 6, 7
modular QoS CLI
match cos command
no atm pxf queuing
2, 15
See also traffic marking.
match-any command
MPLS EXP field
match statements in class maps
See also MPLS experimental.
2, 5, 7, 11
maximum burst size
15
MPLS EXP field, setting using policy maps
maximum threshold
mpls ip encapsulate explicit-null command
default values
39
description of
19
11
modes for queuing
set mpls experimental imposition command
match-all command
recommended setting for random early detection
21
2, 15
match access-group command
39
MPLS QoS
in the random-detect command
services supported
tunnel modes
recommended setting for random early detection
11
MBS, See maximum burst size.
pipe mode
10
short pipe mode
metering, See policing.
MQC, See modular QoS CLI.
MIB, See management information base.
MQC support for IP sessions
minimum threshold
multilink PPP bundling, priority queuing
experimental field value

39
18
2
default values
39
multiple queues, guidelines for configuring QoS
description of
19
multi-VC MLP
13
IN-12
OL-7433-09
Index
N
NAS
classification byte counts
12
configuration commands
5, 7
NCP, See Network Control Protocol.
configuration requirements for hierarchical

policies 6

creating
configuring
13
description of
Ethernet
parent policies
restrictions for
4
7
examples of verifying ATM accounting
26
feature history
features
31
7
See also, hierarchical policies.
interfaces supported
policing and Ethernet accounting
network access server
PRE requirements
network-forwarding policy
no atm pxf queuing command

restrictions
20
show policy-map interface command
4, 13, 3, 9, 25, 6, 7
nonreal-time variable bit rate
12
shape command
15, 9
queuing byte counts
subscriber line encapsulation
13
14
nested hierarchical policies, See also hierarchical policies.

Network Control Protocol
13
examples of verifying Ethernet accounting
11
queuing actions
Ethernet frame headers
nested policy maps

percent-based bandwidth
10, 11, 12
traffic shaping overhead accounting for ATM
See also variable bit rate.

no policy-map command
18
user-defined offset
normal burst, specifying
12, 13, 18, 53
verifying
4, 8, 9
12
oversubscription
ATM line cards
ATM oversubscription factor
oam-bundle command
oam retry command
atm over-subscription-factor command
10
ATM port and bandwidth sharing
11
OC-12 line card, maximum virtual circuits
OC-3 line card, maximum virtual circuits
outbound interfaces, hierarchical policies
12
out of resource message
22
ATM
benefits of
configuring
38
10
17
disabling on ATM interfaces
bandwidth command
child priority queues
Frame Relay PVCs

5
4
interface
15, 5
53
configuring on VBR-nrt virtual circuits
calculation
ATM VC
configuring for VLANs
overhead accounting
AAL5
11
7, 11, 12, 15
11, 10
2, 45

OL-7433-09
IN-13
Index
restrictions
feedbacks
Frame Relay PVC oversubscription

interface oversubscription
VLAN oversubscription
session level
18
parent policies
description of
hierarchical input policing policies
VBR-nrt virtual circuits

VLAN
QoS performance
shaping VCs
53
UBR virtual circuits

verifying
18
in nested hierarchical policies
service-policy command
41
shape command
oversubscription factor
15
10
8, 18
PCR
See peak cell rate.
peak cell rate
packet buffers, queue limit
constant bit rate PVCs
13
dynamic bandwidth selection
packet drops
verifying
multiple sessions
32
packet marking
unshaped and shaped unspecified bit rate PVCs
variable bit rate PVCs
packets
classifying
conforming or exceeding, determining

conforming packets
23
defining traffic classes
priority, configuring
per-class mode

exceeding packets
green packets
20
red packets
10
per-match mode
6, 7
4
3, 9, 12
5, 11, 13
per-session shaping on ATM interfaces

configuring
violating packets
45
50
per user multiservice rate limiting
VoIP classification
verifying
50
46
description of
MPLS packets
yellow packets
per-hop behavior
service policy
specifying QoS
IP packets
26, 32, 34, 35
rate limiting
queue limit
10
per session
matching packets
PAK_Priority
percent-based
policing, configuring
drop policy
Frame Relay
bandwidth, configuring
13
15
percentage-based shaping
IPv4 packets
13
17
parallel express forwarding
per VRF AAA
4, 10, 13
32
PHB, See per-hop behavior.

pipe tunneling mode
3, 10
police actions
IN-14
OL-7433-09
Index
set-cos-transmit
set-frde-transmit
police command
15
set-dscp-transmit
14
police percent command
12, 3
set-dscp-tunnel-transmit
5, 6, 7, 6, 9
set-frde-transmit
11, 32, 35
12, 3
policer, See policing.
policies
set-mpls-exp-transmit
attaching
set-prec-transmit
ATM QoS policies

LAC QoS
policing rate data
QoS policies, service-policy command
Frame Relay QoS restrictions

policing
14
23
policing traffic, percent-based

red packets
25
single-rate color marker
class-based policing
conform-action
effects of shaping
violate-action
13
input
inbound traffic at two levels
interfaces not supporting policing

interfaces supporting policing
marking and policing traffic
metering using token buckets
output
19
17
18
18
18
7
7
5
6
prior to Release 12.0(17)SL

Release 12.0(17)SL
11, 34
policing actions
Release 12.0(17)SL and later
10
Release 12.0(20)ST and later
10
11
policy map
2, 12, 32, 4
class bandwidth allocation
12, 3
6, 7
Release 12.0(22)S and later
11
41
6, 12
yellow packets
policy actions
nested policies
violating packets
6, 22
green packets
verifying and monitoring
6, 10, 20
exceeding packets
excess burst
two-color marker
6, 10, 20
conforming packets
transmit policing action
6, 9, 20
26
traffic policing overview
6, 9, 8
12
4, 5, 33
token bucket algorithm
committed information rate
exceed-action
three-color marker
28
26
specifying multiple actions
committed burst
11, 26
set-qos-transmit policing action
31
bits per second-based policing
drop
restrictions and limitations for policing
13
actions
rate granularity
21, 22, 23
creating Frame Relay QoS policies

queuing actions
12, 4
set-qos-transmit
11, 15, 17, 19
30, 31
VLAN QoS policies
12, 4
set-prec-tunnel-transmit
2, 5
12, 4
set-clp-transmit
12, 3
class queue limit
set-cos-transmit
10, 16
17
25, 29, 30, 12, 14

OL-7433-09
IN-15
Index
creating policy maps
3, 19
precedence levels
defining QoS actions
2, 20
precedence other command
definition of
deleting classes from policy maps

deleting policy maps
input actions
priority
17
class, minimum guaranteed bandwidth percentage
18
comparing priority and bandwidth
1, 2
maximum priority queues
modifying a class policy
2, 4
output actions
field
queue
priority queuing
bandwidth command
bandwidth starvation of other queues
policy-map command
qos match statistics
configuring
3, 9, 10, 21
system limits, policy maps
2, 4
verifying configuration
Frame Relay
1
4
guaranteed minimum bandwidth

interfaces not supporting
12, 20
policy maps
multilink PPP bundling

police command
policy-map-type service command
25
5
restrictions for priority queues

applying rate limiting
strict priority queuing
PPPoA, PPPoE, and RBE sessions

ppp multilink command
propagate-cos command
protect command
ppp multilink fragmentation command

ppp multilink interleave command
PVC bundles
precedence command
28
8, 9, 13
ATM PVC members
precedence-based mapping for PVC bundles
38
adding
33
28
40
11
precedence command (Frame Relay

VC-bundle-member) 37
precedence field
12, 13
pvc-bundle command
PPPoE
sessions
protocol pppoe group command
8, 9, 26
displaying status of active tunnels
11
protect command (Frame Relay VC-bundle-member)
ppp multilink fragment disable command
verifying priority queues
20
PPP
tunneled sessions
interfaces supporting priority queuing
3, 19, 5
25
description of
restrictions for policy maps
8k
5, 6, 10
priority queuing, See priority queuing.
policy-map command
21
10
priority command
per session rate limiting
data, recommended marking values
maximum number supported
policy actions
38
PRI field, See priority field.
description of
40
bundle members
23
23
Frame Relay bundle members
43
Frame Relay bundle members directly
45
Frame Relay members using map classes

ATM members
48
23
IN-16
OL-7433-09
Index
attaching
virtual access interface QoS policies
VC classes
VLAN QoS policies
22, 27
bumping PVCs
benefits of QoS
29
creating
class map
ATM bundles
49
configuring QoS
monitoring bundles
protection rules
PVC selection
31
inheritance
1, 2
12
traffic shaping
17
system limits for bundles
LAC inheritance
4, 6, 7, 8
30
management information base for QoS
28
Model D.2
pvc command (Frame Relay VC-bundle)

pvc-in-range command
5, 6
input and output policy-map actions
15
39
Model F
7
7
modular command line interface for implementing

QoS 2, 34, 50, 29
12
PVCs, attaching ATM policies
18
objectives of bandwidth and priority commands
pxf queuing mode
Frame Relay
restrictions for bundles
PXF and shaping
14
for subscribers
52
31
verifying bundles
features
11
DSLAM model configurations
40
traffic bumping
MPLS EXP to bundle members
PXF
3, 4
creating Frame Relay policy
4, 14
mapping
pvc command
configuring per session service policy
20, 36, 42
Frame Relay configuration examples
for PVC bundles
CLI migration from PRE2 to PRE3
18
Frame Relay bundles

management of
21, 22, 23
attaching ATM QoS policies
16
23
order of execution for QoS features
packet marking
per session
rate limiting
service policy
QID, See queue IDs.
policing traffic
QoS
applying service policies
policy map
ATM attaching QoS policies

ATM inheritance
3, 5, 31
3, 4
QoS actions
11, 14, 16, 17, 19
QoS features and changes
11, 26
definition of
precedence
attaching
ATM QoS policies
QoS policies
11
QoS group
identifier, setting
28

OL-7433-09
IN-17
Index
maximum number
queue-depth command
13
policing action, setting
queue IDs
12
QoS implementation guidelines

QoS inheritance
allocating
QoS restrictions and limitations
changing
description of
3
specifying QoS, IP and MPLS packets
traffic subject to QoS

types of QoS actions
5, 25
2
overriding default
4
17
packet buffers
restrictions
22
allocating queue IDs
QoS models
changing size of
8
8
priority
D.2 configuration tasks
9, 10
scaling limits
D.2 configuration example
22
maximum number
configure subinterfaces
D.2 key components
5, 6, 4, 10, 11, 17
queues
qos match statistics command

configure sessions
queue-limit command
queue size
calculating the average size
configuring
F configuration tasks
F key components
10
generic requirements
QoS service
20
18, 21
modifying method of calculation

queue weight
18, 21
24
controlling using queue-limit
F configuration example
22
default behavior
3
queuing byte counts
12
queuing modes
business
residential
atm pxf queuing

6
QPPB, See QoS policy propagation through the Border

Gateway Protocol.
quality of service, See QoS.
queue depth
22
configuring
22
combining with random detection

5
definition of
D.2
reserving
as a power of 2
service policies
components
aggregate sum restrictions

20
creating
out of resource message
queue limit
31
random early detection (RED)

scalability
determining available queues
12
QoS policy propagation through the Border Gateway

Protocol 13
queuing actions
16, 22, 24, 38
16, 38
changing
3, 5, 31, 8, 25
5, 31
no atm pxf queuing

specifying
3, 9, 25
15

ATM interfaces
IN-18
OL-7433-09
Index
Frame Relay interfaces

VLANs
red packets
response time, improving
restrictions and limitations

ATM PVC selection
17

LAC QoS policies
RADIUS
AAA user profiles
policy maps
5, 14
configuring RADIUS on the router

server
RFC 1490
drop rate
RFC 791
13
RTP
input policy map action

maximum threshold
minimum threshold
SAR
5, 7, 39, 22, 24, 25
random-detect ip precedence command
segmentation and reassembly

serialization delay
19
applying
10
components
creating
20
recommended threshold settings

rate, committed rate data
52
IP session support
4, 10
RBE, applying service-policies to sessions
18
session level, oversubscription
53
session queuing
RED, See random early detection.
3, 5, 10, 11
session categories
3, 10
12
service-policy command
PPPoA, PPPoE and RBE sessions
Real-Time Protocol
5, 2
service profile
PPP tunneled sessions
definition of
rate limiting
per user multiservice
15
defining input and output policies
11
23
13
service policies
determining drop probability
13
10
9, 34
restrictions for RED
combining with tail drop
service categories

combining with queue limit
SCR, See sustained cell rate.
8, 19
random-detect precedence command
21
scalability, qos match statistics command
19
random-detect exponential-weight-constant command
queue limit
16
determining VC weights
18
random-detect dscp command
enabling
21
random-detect discard-class command
description of
output policy map action

usage guidelines
31
VLAN QoS policies
11
13
10
configuring on ATM VCs

configuring on RADIUS
54
60
configuring on virtual templates
54

OL-7433-09
IN-19
Index
examples of configuring on ATM VCs

interfaces supported
restrictions on ATM VCs

verifying on ATM VCs
set ATM CLP bit
Frame Relay
53
4, 15
interfaces not supporting shaping

overview
13
VC level
12, 3
14
5, 15
verifying traffic shaping

short pipe tunneling mode
5, 6, 12
set-cos-transmit policing action

set discard-class command
set-discard-class-transmit policing action
set fr-de command
show atm vp command
12, 3
show caller command
12, 3
set-dscp-tunnel-transmit policing action

set Frame Relay DE bit
16
13, 16
show controllers command
set-frde-transmit policing action
41
show hardware pxf command

show interface command
5, 6, 9, 5
set mpls experimental command
set mpls experimental topmost command
show policy-map
15, 4
12, 4
12, 4
12, 4
setting
20, 12, 18, 20, 28, 16
24
MPLS EXP field
shape command
overhead accounting restrictions

show pppoe session all command
shaped UBR PVCs

shaping
19
32
show pxf cpu queue summary command
33
33
33
show pxf statistics qos policy-map interface command
20,
21
shaping traffic
atm pxf queuing and shaping
33
show pxf cpu queue interface command
show pxf interface command
percentage
33
33
show pxf cpu schedule command
13, 14, 5
show pppoe session packets command

show pxf cpu queue command
5, 6, 10, 4
8, 33, 27
12
show pxf cpu queue atm command
class queue size
12, 18, 28
show policy-map interface command
32
18, 28
overhead accounting
5, 6, 9, 13, 7
set-qos-transmit policing action
32, 23, 32
show policy-map command
12, 4
set-prec-tunnel-transmit policing action
34, 33
show policy-map class command
16
set-mpls-exp-imposition-transmit policing action

set-mpls-exp-transmit policing action
show interfaces virtual-access command
5, 6, 11
set mpls experimental imposition command
set-prec-transmit policing action
20
show ha pxf cpu queue summary
5, 6, 9
set qos-group command
41
show controllers atm command
14
set ip precedence command
41
19
show class-map command
19
set ip dscp command
3, 9
show atm interface command
16
set-dscp-transmit policing action
17
show atm class-links command
3, 15
13
shaping classes
5, 6, 9, 14
set cos command
11
62
set-clp-transmit policing action

set command
3, 14
comparing shaping and policing
53
52
set atm-clp command
10
class-based
52
prerequisites for ATM VCs
session traffic queues
bandwidth
61
show pxf statistics qos policy-map session command
21
IN-20
OL-7433-09
Index
show queue command

show vlans command
system limits
20
class maps
42
simultaneous policy maps
link fragmentation and interleaving
attaching to ATM VCs
policy maps
9, 12
attaching to Ethernet interface

8
attaching to PPPoE sessions
6, 11
configuring
tag control information field

14
tag interface
tail drop
displaying statistics for LAC sessions

interface-level policy
5, 6
8, 3
three-color marker, example configuration

1
three-color policer
13
33
44, 7
child policies
session-level policy
creating
18
single-rate color marker

slope, determining
SMS
10
TCP/IP traffic, weighted random early detection
restrictions
verifying
22
on interface and PPP session

QoS actions
2, 4
attaching to PPPoA sessions

attributes 37 and 39
10
15
description of
6, 8
parent policies
restrictions for
See also hierarchical policies.
specifying QoS
statements, match
thresholds
2, 5, 11
statistics
maximum and minimum
collecting priority queuing information
11
12
token bucket
37
ToS, See type of service field.
policing information
41
traffic
displaying drop information

strict QoS guarantees
32
classes
25
drop policies
21
Frame Relay
VLAN QoS policies

sub-pool command
11, 16
congestion
subinterfaces, attaching
31
20
19
marking
differentiated services-traffic engineering

25
subscriber management server

15, 13
26
strict QoS guarantees
19
2, 18, 21
marking information
sustained cell rate
11
WRED default drop thresholds
bandwidth information
sub-pool tunnels
19
RED recommended settings
displaying
QoS policies
39
19
802.1p
10
actions

class of service
14, 29
10, 26

OL-7433-09
IN-21
Index
description of
traffic shaping
2, 15
design guidelines for marking

discard-class
internal
atm pxf queuing and shaping
21
bandwidth
16, 33
IP precedence
Layer 2 to Layer 3 mapping

Layer 3 marking
3, 14
comparing
22
Layer 2 marking
shaping and policing
11
shaping mechanisms
10
Frame Relay
MPLS experimental
QoS group
10
class-based
8, 5, 6
31
4, 15
interfaces not supporting shaping
28
recommended values for marking

restrictions for marking
interfaces supporting shaping
21
overview
20
shaping classes
verifying marking
verifying traffic shaping
VC level
37
weighted random early detection marking

14
traffic bumping
MPLS QoS
pipe
6
17
3, 10
short pipe
uniform
traffic engineering
3, 9
3
tunnel interfaces, configuring attributes
activating
tunnel packets, applying QoS policies
interfaces
routers
15
tunneling mode
13
shaping, Frame Relay
13
14
transmit policing action
11, 26
QoS group marking
23
24
32
tunnels
21
global pool
midpoint routers
tail-end routers
13
set ip dscp and set ip precedence commands for a

packet 10
policing
sub-pool
30
19
type of service field
31
tunnel head routers
20
description of
28
verifying configurations
DSCP bits
26
traffic marking
class of service
11
configuring differentiated services code point

interfaces not supporting marking
interfaces supporting marking
IP precedence values
MPLS marking
20
20
ubr+ command
8, 9
UBR, See unspecified bit rate.

ubr command
15, 8
uniform tunneling mode
15
multiple priority levels

QoS group
24
unshaped UBR
3
13
13
14, 15, 8, 9
user-defined offset
IN-22
OL-7433-09
Index
for overhead accounting

user profile
changing the weight of
4, 9
12, 27
configuring queue depth
51
38
configuring weight using class maps

maximum VCs on ATM line cards
supporting low count
VAI
weighting configuration examples
nonreal time VBR

real time VBR
16, 8, 9
15
configuring oversubscription
17
creating VLAN subinterfaces
23
encapsulating
variable bit rate-nonreal time

configuring in atm pxf queuing mode
interfaces
oversubscribing
vbr-nrt command
16, 8, 9
VC class, adding bundle members

vc-class command
virtual path
25
9, 19
7
22
virtual path identifier
9, 11
15, 10, 21
virtual path tunnels, maximum VCs on ATM line cards
29
virtual-template command
10
VC scaling, active ATM VCs

VC weights, determining
20
Frame Relay PVC selection

27, 10, 11
virtual template interface
verifying
packet dropping
applying service policies
3, 13
applying to BBA groups
27
attaching policy maps
50
RADIUS server
27
10, 11
23
routed bridge encapsulation over ATM
32
virtual access interfaces
41
priority queuing
virtual time management system
11
2, 10, 22
28
VLAN, See virtual LAN.
QoS policies
32
voice over Internet Protocol (VoIP)
traffic engineering configurations
video traffic, recommended marking values
VP parameters, changing shaping parameters
5, 6
attaching QoS policies

creating
VoIP, See voice over Internet Protocol.

VPI, See virtual path identifier.
virtual access interface
21
21
VP, See virtual path tunnels.
6, 10, 12
violating packets
voice traffic, recommended marking values
26
24
23
PVC bundles
violate-action
38
19
VBR-nrt, See variable bit rate-nonreal time.
vc-class atm command
41
virtual LAN
15
nonreal time VBRs
policing
verifying oversubscription and weighting
3, 12, 13
variable bit rate
VCI
29
12, 27
VTMS, See virtual time management system.
23
See also VAI.

virtual channel identifier
15
virtual circuit
calculating default weight
watermarks, high and low

23
22, 24, 25, 38
weight
OL-7433-09
IN-23
Index
calculating default VC weight
23
configuring
for ATM virtual circuits
on range of PVCs
28, 31
30
using class maps
29
determining VC weights
20, 22
restrictions for virtual circuit weighting

weight command
27
22, 24
weighted fair queuing
7, 2, 4

aggregate drop profiles
17
based on ATM cell loss priority

based on ATM CLP
31
based on discard class
29
based on discard-class
11
based on DSCP
11, 26
based on IP precedence
benefits of
11
9, 11, 28
13
description of
drop modes
13, 14
drop profiles
14
drop profiles on PRE3

how WRED works
queue-limit
16
13
20
random-detect command usage guidelines

restrictions for WRED
supported features
traffic marking
23
verifying packet dropping

WFQ
18
32
WRED, See weighted random early detection.
Y
yellow
packets
token bucket
18
IN-24
OL-7433-09

Qoscf PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Qoscf PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Cisco 10000 Series Router Quality of

Service Configuration Guide

Text Part Number: OL-7433-09

Guide Revision History

Obtaining Documentation and Submitting a Service Request

Quality of Service Overview

Benefits of Quality of Service Features

Restrictions and Limitations for Quality of Service

Modular QoS Command-Line Interface 1-2

QoS Configuration on an Interface

QoS Models 1-6

Cisco 10000 Series Router Quality of Service Configuration Guide

Dynamic Bandwidth Selection Feature 1-13

MQC Support for IP Sessions 1-29

Ethernet Overhead Accounting 1-40

precedence Command (Frame Relay VC-bundle-member) 1-52

Traffic Classification Using Class Maps

Cisco 10000 Series Router Quality of Service Configuration Guide

Feature History for Class Maps 2-2

Classifying Traffic Using a Class Map 2-11

Configuring QoS Policy Actions and Rules

QoS Policies 3-1

Types of QoS Actions 3-4

QoS Inheritance 3-12

ATM Virtual Circuits Without QoS Policies

Configuring QoS Policies 3-18

Attaching Service Policies

Interfaces Supporting QoS Service Policies

Attaching ATM QoS Service Policies 4-2

Attaching Frame Relay QoS Service Policies 4-11

Cisco 10000 Series Router Quality of Service Configuration Guide

Frame Relay QoS Inheritance 4-12

Attaching Virtual LAN QoS Service Policies 4-20

Attaching Layer 2 Access Concentrator QoS Service Policies 4-30

Verifying and Monitoring QoS Service Policies 4-32

Distributing Bandwidth Between Queues

Bandwidth Distribution Between Queues 5-1

Cisco 10000 Series Router Quality of Service Configuration Guide

Unused Bandwidth Allocation 5-3

Traffic Policing 6-2

Single-Rate Color Marker for Traffic Policing 6-4

Cisco 10000 Series Router Quality of Service Configuration Guide

Two-Rate Three-Color Marker for Traffic Policing 6-8

AToM Set ATM CLP Bit Using a Policer 6-13

Set Layer 2 CoS as a Policer Action 6-15

Set Inner CoS as a Policer Action 6-15

Set Inner and Outer CoS as a Policer Action 6-16

Metering Traffic and Token Buckets 6-18

Avoiding Bandwidth Starvation Due to Priority Services

Configuring Traffic Policing 6-27

Cisco 10000 Series Router Quality of Service Configuration Guide

QoS Packet Marking 7-2

IP Precedence Marking 7-4

Cisco 10000 Series Router Quality of Service Configuration Guide

set ip dscp Command 7-9

QoS Group Marking 7-13

MPLS Experimental Marking 7-14

Class-Based Frame Relay DE Bit Marking 7-17

Tunnel Header Marking 7-18

Classification and Marking Design Guidelines

Cisco 10000 Series Router Quality of Service Configuration Guide

Recommended Values for Traffic Marking

Configuring Traffic Marking 7-22