Swconfig Policy Qos

JUNOSe Internet Software for E-series Routing Platforms
Policy and QoS Configuration Guide
Release 6.1.x
Juniper Networks, Inc.

1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000
www.juniper.net
Part Number: 162-01067-00, Revision A00
Juniper Networks, the Juniper Networks logo, NetScreen, NetScreen Technologies, the NetScreen logo, NetScreen-Global Pro, ScreenOS, and GigaScreen are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The following are trademarks of Juniper Networks, Inc.: ERX, ESP, E-series, Instant Virtual Extranet, Internet Processor, J2300, J4300, J6300, J-Protect, J-series, J-Web, JUNOS, JUNOScope, JUNOScript, JUNOSe, M5, M7i, M10, M10i, M20, M40, M40e, M160, M320, M-series, MMD, NetScreen-5GT, NetScreen-5XP, NetScreen-5XT, NetScreen-25, NetScreen-50, NetScreen-204, NetScreen-208, NetScreen-500, NetScreen-5200, NetScreen-5400, NetScreen-IDP 10, NetScreen-IDP 100, NetScreen-IDP 500, NetScreen-Remote Security Client, NetScreen-Remote VPN Client, NetScreen-SA 1000 Series, NetScreen-SA 3000 Series, NetScreen-SA 5000 Series, NetScreen-SA Central Manager, NetScreen Secure Access, NetScreen-SM 3000, NetScreen-Security Manager, NMC-RX, SDX, Stateful Signature, T320, T640, and T-series. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. All specifications are subject to change without notice. Products made or sold by Juniper Networks (including the ERX-310, ERX-705, ERX-710, ERX-1410, ERX-1440, M5, M7i, M10, M10i, M20, M40, M40e, M160, M320, and T320 routers, T640 routing node, and the JUNOS, JUNOSe, and SDX-300 software) or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785. Copyright 2005, Juniper Networks, Inc. All rights reserved. Printed in USA. JUNOSe Internet Software for E-series Routing Platforms Policy and QoS Configuration Guide, Release 6.1.x Writing: Bruce Gillham, Brian Wesley Simmons, Jane Varkonyi Editing: Ben Mann, Tony Mauro, Fran Mues Illustration: Brian Wesley Simmons, Nathaniel Woodward Cover Design: Edmonds Design Revision History 7 March 2005Revision 1 The information in this document is current as of the date listed in the revision history. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer or otherwise revise this publication without notice.
Software License
The terms and conditions for using this software are described in the software license contained in the acknowledgment to your purchase order or, to the extent applicable, to any reseller agreement or end-user purchase agreement executed between you and Juniper Networks. By using this software, you indicate that you understand and agree to be bound by those terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the software and may contain prohibitions against certain uses. The software license may state conditions under which the license is automatically terminated. You should consult the license for further details. For complete product documentation, please see the Juniper Networks Web site at www.juniper.net/techpubs.
End User License Agreement

READ THIS END USER LICENSE AGREEMENT ("AGREEMENT") BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE. BY DOWNLOADING, INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS CONTAINED HEREIN, YOU (AS CUSTOMER OR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO BIND THE CUSTOMER) CONSENT TO BE BOUND BY THIS AGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS REGARDING LICENSE TERMS. 1. The Parties. The parties to this Agreement are Juniper Networks, Inc. and its subsidiaries (collectively "Juniper"), and the person or organization that originally purchased from Juniper or an authorized Juniper reseller the applicable license(s) for use of the Software ("Customer") (collectively, the "Parties"). 2. The Software. In this Agreement, "Software" means the program modules and features of the Juniper or Juniper-supplied software, and updates and releases of such software, for which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller. 3. License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer a non-exclusive and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the following use restrictions: a. Customer shall use the Software solely as embedded in, and for execution on, Juniper equipment originally purchased by Customer from Juniper or an authorized Juniper reseller, unless the applicable Juniper documentation expressly permits installation on non-Juniper equipment. b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units for which Customer has paid the applicable license fees. c. Other Juniper documentation for the Software (such as product purchase documents, documents accompanying the product, the Software user manual(s), Juniper's website for the Software, or messages displayed by the Software) may specify limits to Customer's use of the Software. Such limits may restrict use to a maximum number of seats, concurrent users, sessions, subscribers, nodes, or transactions, or require the purchase of separate licenses to use particular features, functionalities, or capabilities, or provide temporal or geographical limits. Customer's use of the Software shall be subject to all such limitations and purchase of all applicable licenses. The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase the applicable license(s) for the Software from Juniper or an authorized Juniper reseller.
4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees not to and shall not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized copies of the Software (except as necessary for backup purposes); (c) rent, transfer, or grant any rights in and to any copy of the Software, in any form, to any third party; (d) remove any proprietary notices, labels, or marks on or in any copy of the Software; (e) distribute any copy of the Software to any third party, including as may be embedded in Juniper equipment sold in the secondhand market; (f) use any 'locked' or key-restricted feature, function, or capability without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even if such feature, function, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to any third party; (h) use the Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper reseller; (i) use the Software on non-Juniper equipment where the Juniper documentation does not expressly permit installation on non-Juniper equipment; (j) use the Software (or make it available for use) on Juniper equipment that the Customer did not originally purchase from Juniper or an authorized Juniper reseller; or (k) use the Software in any manner other than as expressly provided herein. 5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper, Customer shall furnish such records to Juniper and certify its compliance with this Agreement. 6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper. As such, Customer shall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence, which at a minimum includes restricting access to the Software to Customer employees and contractors having a need to use the Software. 7. Ownership. Juniper and Juniper's licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to the Software, associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance of any right, title, or interest in the Software or associated documentation, or a sale of the Software, associated documentation, or copies of the Software. 8. Warranty, Limitation of Liability, Disclaimer of Warranty. If the Software is distributed on physical media (such as CD), Juniper warrants for 90 days from delivery that the media on which the Software is delivered will be free of defects in material and workmanship under normal use. This limited warranty extends only to the Customer. Except as may be expressly provided in separate documentation from Juniper, no other warranties apply to the Software, and the Software is otherwise provided AS IS. Customer assumes all risks arising from use of the Software. Customer's sole remedy and Juniper's entire liability under this limited warranty is that Juniper, at its option, will repair or replace the media containing the Software, or provide a refund, provided that Customer makes a proper warranty claim to Juniper, in writing, within the warranty period. Nothing in this Agreement shall give rise to any obligation to support the Software. Any such support shall be governed by a separate, written agreement. To the maximum extent permitted by law, Juniper shall not be liable for any liability for lost profits, loss of data or costs or procurement of substitute goods or services, or for any special, indirect, or consequential damages arising out of this Agreement, the Software, or any Juniper or Juniper-supplied software. In no event shall Juniper be liable for damages arising from unauthorized or improper use of any Juniper or Juniper-supplied software. EXCEPT AS EXPRESSLY PROVIDED HEREIN OR IN SEPARATE DOCUMENTATION PROVIDED FROM JUNIPER AND TO THE EXTENT PERMITTED BY LAW, JUNIPER DISCLAIMS ANY AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE), INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT ERROR OR INTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK. 9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination of the license granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related documentation in Customer's possession or control. 10. Taxes. All license fees for the Software are exclusive of taxes, withholdings, duties, or levies (collectively "Taxes"). Customer shall be responsible for paying Taxes arising from the purchase of the license, or importation or use of the Software. 11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any applicable foreign agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such restrictions, laws or regulations, or without all necessary approvals. Customer shall be liable for any such violations. The version of the Software supplied to you may contain encryption or other capabilities restricting your ability to export the Software without an export license. 12. Commercial Computer Software. The Software is "commercial computer software" and is provided with restricted rights. Use, duplication, or disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS 227.7201 through 227.7202-4, FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable. 13. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. For any disputes arising under this Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written (including any inconsistent terms contained in a purchase order), except that the terms of a separate written agreement executed by an authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict with terms contained herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in writing by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity of the remainder of this Agreement. If you have any questions about this agreement, contact Juniper Networks at the following address: Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA Attn: Contracts Administrator
Table of Contents
About This Guide ix Objectives ....................................................................................................... ix E-series Routers ............................................................................................... x Audience.......................................................................................................... x Documentation Conventions............................................................................ x Related Juniper Networks Documentation....................................................... xi Obtaining Documentation............................................................................. xiii Documentation Feedback ............................................................................. xiii Requesting Support....................................................................................... xiii Chapter 1 Configuring Policy Management 1
Overview ......................................................................................................... 2 Policy Lists................................................................................................. 2 Secure Policies........................................................................................... 3 Classifier Control Lists ............................................................................... 4 Rate-Limit Profiles ..................................................................................... 5 One-Rate Rate-Limit Profile................................................................. 6 Two-Rate Rate-Limit Profile................................................................. 8 References ..................................................................................................... 10 Configuration Tasks ....................................................................................... 10 Creating a Rate-Limit Profile .......................................................................... 10 One-Rate ................................................................................................. 11 Two-Rate ................................................................................................. 11 Creating Classifier Control Lists...................................................................... 18 Creating Policy Lists ....................................................................................... 28 Creating a Policy List for IP...................................................................... 28 Creating a Policy List for IPv6 .................................................................. 29 Creating a Policy List for Frame Relay ..................................................... 30 Creating a Policy List for GRE Tunnels ..................................................... 32 Creating a Policy List for L2TP .................................................................33 Creating a Policy List for MPLS ................................................................ 33 Creating a Policy List for VLANs............................................................... 34 Creating Classifier Groups and Policy Rules....................................................36 Policy Rule Support ................................................................................. 37 Rules That Provide Routing Solutions ...................................................... 38 Creating Multiple Forwarding Solutions with IP Policy Lists ..................... 38 Classifier Group Command ...................................................................... 39 Policy Rule Commands............................................................................ 40 Applying Policy Lists to Interfaces and Profiles .............................................. 45 Enabling IP Options Filtering ......................................................................... 46 Using RADIUS to Create and Apply Policies ................................................... 47 ExamplesUsing the Ascend-Data-Filter Attribute............................ 49
Table of Contents
JUNOSe 6.1.x Policy and QoS Configuration Guide
Policy Applications......................................................................................... 54 Policy Routing ......................................................................................... 54 Security ................................................................................................... 55 Bandwidth Management.......................................................................... 56 One-Rate Rate-Limit Profile............................................................... 57 Two-Rate Rate-Limit Profile............................................................... 57 Rate Limiting Individual or Aggregate Packet Flows ................................ 58 Packet Tagging ........................................................................................ 59 Packet Flow Monitoring .................................................................... 60 Policy Management and MPLS Topology-Driven LSPs .................................... 62 Statically Configured Mapping .................................................................62 Signaled Mapping .................................................................................... 63 Policy Resources ............................................................................................ 63 FPGA Hardware Classifiers ...................................................................... 65 CAM Hardware Classifiers ....................................................................... 66 Software Classifiers ................................................................................. 67 Monitoring Policy Management ..................................................................... 68 Setting a Statistics Baseline...................................................................... 68 Policy Management show Commands ..................................................... 69 Chapter 2 Configuring Quality of Service 91
Overview ....................................................................................................... 92 Terms ...................................................................................................... 93 Features................................................................................................... 94 References ..................................................................................................... 96 Configuration Tasks ....................................................................................... 96 Traffic Classes ............................................................................................... 97 Best-Effort Forwarding............................................................................. 97 Configuring a Traffic Class ...................................................................... 97 Traffic-Class Groups ....................................................................................... 99 Configuring Traffic-Class Groups.............................................................. 99 Queue Profiles..............................................................................................100 Static Oversubscription..........................................................................101 Dynamic Oversubscription ....................................................................101 Overriding Default Queue Allocation .....................................................101 Color-Based Thresholding ......................................................................102 Configuring Queue Profiles ...................................................................103 Drop Profiles ...............................................................................................105 How RED Works ...................................................................................106 Configuring RED....................................................................................106 RED Configuration Examples ................................................................108 Configuring Average Queue Length ................................................108 Configuring Thresholds ..................................................................108 Configuring Color-Blind RED ..........................................................108 How WRED Works ................................................................................110 Configuring WRED ................................................................................110 WRED Configuration Examples ............................................................110 Configuring Different Treatment of Colored Packets ......................110 Defining Different Drop Behavior for Each Traffic Class..................111 RED and Dynamic Queue Thresholds ............................................112 Scheduler Profiles ........................................................................................114 Hierarchical Assured Rate......................................................................115 Configuring Scheduler Profiles...............................................................116
vi
Table of Contents
Table of Contents
Shared Shaping ............................................................................................118 Sharing Bandwidth with the SAR ...........................................................119 How Shared Shaping Works ..................................................................119 Simple Shared Shaping..........................................................................119 Simple Shared Shaping Example.....................................................120 Simple Shared Shaping on the Best-Effort Scheduler Queue............120 Simple Shared Shaping on the Best-Effort Scheduler Node..............121 Shared Shaping and Low-CDV Mode ...............................................121 Compound Shared Shaping ...................................................................122 Shared Shaping Constituents .................................................................122 Types of Shared Shapers .................................................................124 Implicit Constituent Selection..........................................................124 Implicit Bandwidth Allocation for Compound Shared Shaping ........127 Explicit Constituent Selection ..........................................................131 Explicit Shared Shaping Example....................................................132 Explicit Weighted Compound Shared Shaping Examples ................133 Simple Shared Shaping Configuration Examples ...................................135 VC Simple Shared Shaping Example ...............................................136 VP Simple Shared Shaping Example ...............................................137 Shared Shaping and Individual Shaping ..........................................139 Compound Shared Shaping Configuration Examples .............................139 Configuration Restrictions ...............................................................141 VC Compound Shared Shaping Example.........................................141 VP Compound Shared Shaping Example.........................................143 Shared Shaping Caveats ........................................................................145 Hardware Dependency ...................................................................145 Logical Interface Traffic Carried in Other Queues............................146 Traffic Starvation.............................................................................146 Oversubscription.............................................................................146 Burst Size ........................................................................................146 Statistics Profiles .........................................................................................147 Rate Statistics ........................................................................................148 Event Statistics ......................................................................................149 Memory and Processor Use ...................................................................150 Configuring Statistics Profiles ................................................................150 QoS Profiles .................................................................................................151 Configuring QoS Profiles........................................................................152 Creating QoS Profiles ......................................................................153 Adding Groups, Nodes, and Queues to QoS Profiles ........................153 Attaching QoS Profiles ....................................................................154 Configuring QoS for ATM Interfaces.............................................................155 Integrating the HRR Scheduler and SAR Scheduler ................................155 Backpressure...................................................................................156 Configuring the Integrated Scheduler.....................................................157 Configuring the SAR Scheduler Mode of Operation .........................158 Configuring the Operational QoS Shaping Mode .............................158 ATM QoS Configuration Examples.........................................................160 Default Integrated Mode..................................................................160 Low-Latency Mode ..........................................................................161 Low-CDV Mode ...............................................................................163 Configuring QoS for L2TP Interfaces ............................................................167 Configuration Procedure........................................................................168 Scheduler Hierarchies .....................................................................169
Table of Contents !
vii
QoS Profile Attachments ..............................................................................170 Attaching a Profile to an Interface .........................................................170 Attaching a Profile to a Port Type ..........................................................171 Munged QoS Profile...............................................................................172 QoS Profile Configuration Examples ...........................................................174 Diffserv Configuration with Multiple Traffic-Class Groups.............................178 Strict-Priority Scheduling..............................................................................182 Relative Strict-Priority Scheduling ................................................................184 True Strict Priority Versus Relative Strict Priority ..................................185 True Strict Priority ..........................................................................185 Relative Strict Priority .....................................................................186 Relative Strict Priority on ATM Modules ................................................186 Oversubscribing ATM Ports ............................................................187 Minimizing Latency on the SAR Scheduler .....................................187 HRR Scheduler Behavior .......................................................................187 Zero-Weight Queues .......................................................................188 Setting the Burst Size in a Shaping Rate .........................................188 Special Shaping Rate for Nonstrict Queues .....................................188 Configuring Relative Strict-Priority Scheduling.......................................189 Rate Shaping................................................................................................191 Port Shaping ...............................................................................................192 Clearing Statistics.........................................................................................193 Monitoring QoS............................................................................................193 Index 211
viii
Table of Contents
About This Guide

This preface provides the following guidelines for using JUNOSe Internet Software for E-series Routing Platforms Policy and QoS Configuration Guide:
! ! ! ! ! ! ! !
Objectives on page ix E-series Routers on page x Audience on page x Documentation Conventions on page x Related Juniper Networks Documentation on page xi Obtaining Documentation on page xiii Documentation Feedback on page xiii Requesting Support on page xiii
Objectives
This guide provides the information you need to configure policy management and quality of service (QoS) on your E-series router. An E-series router is shipped with the latest system software installed. If you need to install a future release or reinstall the system software, refer to the procedures in the E-series Hardware Guide, Appendix B, Installing JUNOSe Software.
NOTE: If the information in the latest JUNOSe Release Notes differs from the information in this guide, follow the JUNOSe Release Notes.
Objectives
ix
E-series Routers
Five models of E-series routers are available:
! ! ! ! !
ERX-1440 router ERX-1410 router ERX-710 router ERX-705 router ERX-310 router
All models use the same software. For information about the differences between the models, see E-series Hardware Guide, Chapter 1, E-series Overview. In the E-series documentation, the term ERX-14xx models refers to both the ERX-1440 router and the ERX-1410 router. Similarly, the term ERX-7xx models refers to both the ERX-710 router and the ERX-705 router. The terms ERX-1440 router, ERX-1410 router, ERX-710 router, ERX-705 router, and ERX-310 router refer to the specific models.
Audience
This guide is intended for experienced system and network specialists working with E-series routers in an Internet access environment.
Documentation Conventions
Table 1 defines notice icons used in this guide. Table 2 defines text conventions used in this guide and the syntax conventions used primarily in the JUNOSe Command Reference Guide. For more information about command syntax, see JUNOSe System Basics Configuration Guide, Chapter 2, Command-Line Interface.
Table 1: Notice Icons Icon Meaning
Informational note Caution
Description
Indicates important features or instructions. Indicates a situation that might result in loss of data or hardware damage. Alerts you to the risk of personal injury.
Warning
E-series Routers
About This Guide
Table 2: Text and Syntax Conventions Convention

Text Conventions Bold typeface Represents commands and keywords in ! Issue the clock source command. text. ! Specify the keyword exp-msg. Represents text that the user must type. host1(config)#traffic class low-loss1 Represents information as displayed on host1#show ip ospf 2 your terminals screen. Routing Process OSPF 2 with Router ID
5.5.0.250 Router is an Area Border Router (ABR)
Description
Examples
Bold sans serif typeface

Fixed-width font
Italic typeface
! Emphasizes words. ! Identifies variables. ! Identifies chapter, appendix, and
! There are two levels of access, user and
privileged.
! clusterId, ipAddress. ! Appendix A, System Specifications.
book names. Plus sign (+) linking key names Indicates that you must press two or more keys simultaneously.
Press Ctrl+b.
Syntax Conventions in the Command Reference Guide Plain typeface Italic typeface | (pipe symbol) Represents keywords. Represents variables. Represents a choice to select one keyword or variable to the left or right of this symbol. (The keyword or variable can be either optional or required.) Represent optional keywords or variables. terminal length mask, accessListName diagnostic | line
[ ] (brackets) [ ]* (brackets and asterisk)
[ internal | external ]
[ level1 | level2 | l1 ]* Represent optional keywords or variables that can be entered more than once. Represent required keywords or variables. { permit | deny } { in | out } { clusterId | ipAddress }
{ } (braces)
Related Juniper Networks Documentation

The E-series Installation Quick Start poster is shipped in the box with all new routers. This poster provides the basic procedures to help you get the router up and running quickly. Table 3 lists and describes the E-series document set. A complete list of abbreviations used in this document set, along with their spelled-out terms, is provided in the JUNOSe System Basics Configuration Guide, Appendix A, Abbreviations and Acronyms.
xi
Table 3: Juniper Networks E-series Technical Publications Document

E-series Hardware Guide
Description
Provides the necessary procedures for getting the router operational, including information about installing, cabling, powering up, configuring the router for management access, and general troubleshooting. Describes SRP modules, line modules, and I/O modules available for the E-series routers. Provides detailed specifications for line modules and I/O modules, and information about the compatibility of these modules with JUNOSe software releases. Lists the layer 2 protocols, layer 3 protocols, and applications that line modules and their corresponding I/O modules support. Provides module LED information. Describes planning and configuring your network, managing the router, configuring passwords and security, configuring the router clock, and configuring virtual routers. Includes a list of references that provide information about the protocols and features supported by the router. Describes configuring physical layer interfaces. Describes configuring link-layer interfaces. Provides information about configuring routing policy and configuring IP, IP routing, and IP security. Describes BGP routing, MPLS, BGP-MPLS VPNs, and encapsulation of layer 2 services.
E-series Module Guide
JUNOSe System Basics Configuration Guide
JUNOSe Physical Layer Configuration Guide JUNOSe Link Layer Configuration Guide JUNOSe Routing Protocols Configuration Guide, Vol. 1 JUNOSe Routing Protocols Configuration Guide, Vol. 2
JUNOSe Policy and QoS Configuration Guide Provides information about configuring policy management and quality of service (QoS). JUNOSe Broadband Access Configuration Guide JUNOSe Command Reference Guide A to M; JUNOSe Command Reference Guide N to Z Provides information about configuring remote access. Together constitute the JUNOSe Command Reference Guide. Contain important information about commands implemented in the system software. Use to look up command descriptions, command syntax, a commands related mode, or a description of a commands parameters. Use with the JUNOSe configuration guides.
Release Notes JUNOSe Release Notes In the Release Notes, you will find the latest information about features, changes, known problems, resolved problems, and system maximum values. If the information in the Release Notes differs from the information found in the documentation set, follow the Release Notes. Release notes are included on the corresponding software CD and are available on the Web.
xii
About This Guide
Obtaining Documentation
To obtain the most current version of all Juniper Networks technical documentation, see the products documentation page on the Juniper Networks Web site at http://www.juniper.net/. To order printed copies of this manual and other Juniper Networks technical documents, or to order a documentation CD, which contains this manual, contact your sales representative. Copies of the Management Information Bases (MIBs) available in a software release are included on the software CDs and at http://www.juniper.net/.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation to better meet your needs. You can send your comments to techpubs-comments@juniper.net, or fill out the documentation feedback form at http://www.juniper.net/techpubs/docbug/docbugreport.html. If you are using e-mail, be sure to include the following information with your comments:
! ! ! !
Document name Document part number Page number Software release version
Requesting Support
For technical support, open a support case using the Case Manager link at http://www.juniper.net/support/ or call 1-888-314-JTAC (within the United States) or 1-408-745-9500 (outside the United States).
Obtaining Documentation
xiii
xiv
Requesting Support
Chapter 1
Configuring Policy Management

This chapter provides information for configuring policy-based routing management on E-series routers. You can use policy management on Frame Relay, generic routing encapsulation (GRE), IP, IPv6, Layer 2 Tunneling Protocol (L2TP), Multiprotocol Label Switching (MPLS), and virtual local area network (VLAN) traffic. This chapter discusses the following topics:
! ! ! ! ! ! ! ! ! ! ! ! ! !
Overview on page 2 References on page 10 Configuration Tasks on page 10 Creating a Rate-Limit Profile on page 10 Creating Classifier Control Lists on page 18 Creating Policy Lists on page 28 Creating Classifier Groups and Policy Rules on page 36 Applying Policy Lists to Interfaces and Profiles on page 45 Enabling IP Options Filtering on page 46 Using RADIUS to Create and Apply Policies on page 47 Policy Applications on page 54 Policy Management and MPLS Topology-Driven LSPs on page 62 Policy Resources on page 63 Monitoring Policy Management on page 68
Overview
Policy management allows network service providers to implement packet forwarding and routing specifically tailored to their customers requirements. Using policy management, you can implement policies that selectively cause packets to take different paths without requiring a routing table lookup. Packets are sorted at ingress or egress into packet flows based on attributes defined in classifier control lists (CLACLs). Policy lists contain rules that associate actions with these CLACLs. Policy management provides:
!
Policy routingPredefines a classified packet flow to a destination port or IP address. The router does not perform a routing table lookup on the packet. On ingress, the packets are classified into a packet flow and sent to the preconfigured destination port. See the forward forward interface forward next-hop, forward forward interface forward next-hop, and forward forward interface forward next-hop commands for more details. Quality of service (QoS) classification and markingMarks packets in a packet flow. See Creating Classifier Control Lists on page 18. Packet forwardingAllows forwarding of packets in a packet flow. See the forward forward interface forward next-hop, forward forward interface forward next-hop, and forward forward interface forward next-hop command. Packet filteringDrops packets in a packet flow. See the filter command. Packet loggingLogs packets in a packet flow. See the log command. Rate limitingEnforces line rates below the physical line rate of the port and sets limits on packet flows. See Creating a Rate-Limit Profile on page 10. RADIUS policy supportAllows you to create and attach a policy to an interface through RADIUS. See Using RADIUS to Create and Apply Policies on page 47. Packet mirroringUses secure policies to mirror packets and send them to an analyzer. See JUNOSe System Basics Configuration Guide, Chapter 8, Packet Mirroring.
! ! !
Policy Lists
The main tool for implementing policy management is a policy list. A policy list is a set of rules, each of which specifies a policy action. A rule is a policy action optionally combined with a classification. You can apply policy lists to packets:
!
Arriving at an interface (input policy); on IP and IPv6 interfaces the packets arrive before route lookup Arriving at the interface, but after route lookup (secondary input policy); secondary input policies are supported only on IP and IPv6 interfaces Leaving an interface (output policy)
Overview
Chapter 1: Configuring Policy Management
You create a policy rule by specifying a policy action within a classifier group that references a CLACL. These rules become part of a policy list that you can attach to an interface as either an input, secondary-input, or output policy. The router applies the rules in the attached policy list to the packets traversing that interface. Figure 1 shows how a sample IP policy list is constructed.
Figure 1: Constructing an IP Policy List
tiered12MB hardlimit9MB hardlimit3MB Rate limit profiles
Database
AcmeCompanyUDP XYZCorpIGMP XYZCorpICMP Classifier control lists
filterForHighSecurity next-interface next-hop filter forward rate-limit-profile mark color traffic class
g013082
routeForAcmeCompany action routeForXYZCorp Rule 1 Rule 2 Rule 3 action Rule n Policy lists classification
Rule = Action + Classification
log user-packet-class Policy action
Secure Policies
Secure policies are used by the JUNOSe softwares RADIUS-based packet mirroring feature. The policies are based on packet mirroringrelated RADIUS VSAs, which are created by authorized RADIUS administrators. Secure policies are dynamically created when the RADIUS-based mirroring session is initiated at the RADIUS server and then applied to the interface that is created for the user whose traffic is being mirrored. The secure policy is deleted from the interface when the mirroring operation is disabled or if the interface is deleted. When a secure policy is created, the router creates a name that consists of the string spl followed by a hexadecimal integer, such as spl_0x88000008. Authorized users can use the show secure policy-list command to view information about secure policies. See JUNOSe System Basics Configuration Guide, Chapter 8, Packet Mirroring for information about the JUNOSe softwares packet mirroring feature.
Overview
Classifier Control Lists

CLACLs specify the criteria by which the router defines a packet flow. Table 4 shows the criteria that you can use to create CLACLs for different types of traffic flows. See Policy Resources on page 63 for more information about the hardware and software CLACLs that are supported for each interface types.
Table 4: CLACL Criteria Type of CLACL
Frame Relay
Criteria
! Color ! Mark discard eligibility (DE) bit ! Traffic class ! User packet class
GRE
! Color ! Traffic class ! Type-of-service (ToS) byte ! User packet class
IP
! Color ! Destination IP address ! Destination port ! Destination route class ! Internet Control Message Protocol (ICMP) ! Internet Gateway Management Protocol (IGMP) ! IP flags ! IP fragmentation offset ! Locally destined traffic ! Protocol ! Source IP address ! Source port ! Source route class ! Transmission Control Protocol (TCP) ! Traffic class ! Type-of-service (ToS) byte ! User Datagram Protocol (UDP) ! User packet class
Overview
Table 4: CLACL Criteria (continued) Type of CLACL

IPv6
Criteria
! Color ! Destination IPv6 address ! Destination port ! Destination route class ! Internet Control Message Protocol version 6 (ICMPv6) ! IPv6 traffic class ! Locally destined traffic ! Multicast Listener Discovery (MLD) ! Next header ! Source IPv6 address ! Source port ! Source route class ! Traffic class ! Transmission Control Protocol (TCP) ! User Datagram Protocol (UDP) ! User packet class
L2TP
! Color ! Traffic class ! User packet class
MPLS
! Color ! Mark experimental (EXP) bit ! Traffic class ! User packet class
VLAN
! Color ! Traffic class ! User packet class ! User priority
Rate-Limit Profiles
Rate limiting is the process of limiting a classified packet flow or a source interface to a rate that is less than the physical rate of the port. The E-series routers rate limits are calculated based on the layer 2 packet size. To configure rate limiting, you first create a rate-limit profile, which is a set of bandwidth attributes and associated actions. Your router supports two types of rate-limit profilesone-rate and two-ratefor IP, IPv6, LT2P, and MPLS Layer 2 transport traffic. You next create a policy list with a rule that has rate limit as the action and associate a rate-limit profile with this rule. Rate-limit actions include drop, transmit, or mark. The default is to transmit committed and conformed packets, and to drop exceeded packets.
Overview
A color-coded tag is added automatically to each packet based on categories:

! ! !
CommittedGreen ConformedYellow ExceededRed
The queuing system uses drop eligibility to select packets for dropping when there is congestion on an egress interface. This method is called dynamic color-based threshold dropping. Each packet queue has two color-based thresholds as well as a queue limit:
!
Red packets are dropped when congestion causes the queue to fill above the red threshold. Yellow packets are dropped when the yellow threshold is reached. Green packets are dropped when the queue limit is reached.
! !
See Chapter 2, Configuring Quality of Service for information about configuring queue thresholds.
One-Rate Rate-Limit Profile

The one-rate rate-limit profile attributes are:
! !
Committed rateTarget rate for a packet flow Committed burstAmount of bandwidth allocated to accommodate bursty traffic in excess of the rate Excess burstAmount of bandwidth allocated to accommodate a packet in progress when the rate is in excess of the burst Committed actionDrop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow does not exceed the rate Conformed actionDrop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow exceeds the rate but not the excess burst Exceeded actionDrop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow exceeds the rate Mask valueMask to be applied with mark values for the ToS byte; applicable only to IP and IPv6 rate-limit profiles EXP mask valueMask to be applied with mark-exp values; applicable only to MPLS rate-limit profiles
Overview
Configuring a TCP-Friendly One-Rate Rate-Limit Profile The E-series router provides a TCP-friendly rate-limiting mechanism that is implemented with token buckets. You can configure a committed rate, committed burst, and excess burst for the token bucket. For example, to configure a rate-limit process with hard tail dropping of packets when tokens are unavailable, set the committed rate and committed burst to a nonzero value, and set the excess burst to zero. Setting the excess burst to a nonzero value causes the router to drop packets in a more friendly way. The configuration values for the above attributes determine the degree of friendliness of the rate-limit process. The general idea is that instead of tail dropping packets that arrive outside the committed and burst rate envelope, the TCP-friendly bucket allows more tokens to be borrowed, up to a limit determined by the excess burst size. The next packet that borrows tokens in excess of the excess burst size is deemed excessive and is dropped if the exceeded action is set to drop. The rate-limit algorithm is designed to avoid consecutive packet drops in the initial stages of congestion when the packet flow rate exceeds the committed rate of the token bucket. The intention is that just a few packet drops are sufficient for TCPs congestion control algorithm to drastically scale back its sending rate. Eventually, the packet flow rate falls below the committed rate, which allows the token bucket to replenish faster because of the reduced load. If the packet flow rate exceeds the committed rate for an extended period of time, the rate-limit algorithm tends toward hard tail dropping. In a properly configured scenario, the rate limiter is consistently driven to borrow tokens because of TCPs aggressive nature, but it replenishes the tokens as TCP backs off, resulting in a delivered rate that is very close to the rate configured in the rate-limit profile. The recommended burst sizes for TCP-friendly behavior are:
! !
Committed burst0.2 to 2.0 seconds of the committed rate Excess burst1.0 to 2.0 seconds of the committed rate, plus the committed burst
For example, if the committed rate is 1,000,000 bps, the recommended burst sizes are as follows:
!
Committed burst is 1,000,000 x 1.0 x 1/8 = 125,000 bytes Multiplying the committed rate by 1.0 converts the rate to bits, then multiplying the number of bits by 1/8 converts the value to bytes.
Excess burst is 1,000,000 x 1.5 x 1/8 + 125,000 = 312,500 bytes Multiplying the committed rate by 1.5 converts the rate to bits, then multiplying the number of bits by 1/8 converts the value to bytes.
Overview
Two-Rate Rate-Limit Profile

The two-rate rate-limit profile attributes are:
! !
Committed rateTarget rate for a packet flow Committed burstAmount of bandwidth allocated to accommodate bursty traffic in excess of the committed rate Peak rateAmount of bandwidth allocated to accommodate excess traffic flow over the committed rate Peak burstAmount of bandwidth allocated to accommodate bursty traffic in excess of the peak rate Committed actionDrop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow does not exceed the committed rate Conformed actionDrop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow exceeds the committed rate but remains below the peak rate Exceeded actionDrop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow exceeds the peak rate Mask valueMask to be applied with mark values for the ToS byte; applicable only to IP and IPv6 rate-limit profiles EXP mask valueMask to be applied with mark-exp values; applicable only to MPLS rate-limit profiles
Table 5 shows the interaction between the rate settings and the actual traffic rate to determine the action taken by a rate-limit rule in a policy when applied to a traffic flow.
Table 5: Policy Action Applied Based on Rate Settings and Traffic Rate Peak Rate
Peak rate = 0
Committed Rate = 0
! All traffic assigned the exceeded
Committed Rate Not 0

! Traffic <= committed rate
action
assigned the committed action

! Traffic > committed rate assigned
the exceeded action Peak rate not 0

! Traffic <= peak rate assigned the ! Traffic <= committed rate
conformed action
! Traffic > peak rate assigned the
assigned the committed action

! Committed rate < Traffic < peak
exceeded action
rate assigned the conformed action

! Traffic > peak rate assigned the
exceeded action
Overview
This implementation is known as a two-rate, three-color marking mechanism. Token buckets control how many packets per second are accepted at each of the configured rates. The token buckets provide flexibility in dealing with the bursty nature of data traffic. The committed burst sets the depth of the committed token bucket. The committed rate is the speed at which the committed token bucket is filled. The peak burst sets the depth of the peak token bucket. The peak rate is the speed at which the peak token bucket is filled. At the beginning of each sample period, the two buckets are filled with tokens based on the configured burst sizes. Traffic is metered to measure its volume. When traffic is received, if tokens remain in both buckets, one token is removed from each bucket for every byte of data processed. As long as there are still tokens in the committed burst bucket, the traffic is treated as committed. When the committed burst token bucket is empty but tokens remain in the peak burst bucket, traffic is treated as conformed. When the peak burst token bucket is empty, traffic is treated as exceeded. Table 6 shows equations that can also represent the algorithm for the two-rate rate-limit profile.
Table 6: Two-Rate Rate-Limit Profile Algorithms Step
If B > Tp (t) If B < Tp (t) and B > Tc (t) If B < Tp (t) and B < Tc (t)
! Packet is marked as green and treated as committed ! Tp is decremented by B ! Tc is decremented by B
Result
! Packet is marked as red and treated as exceeded ! Packet is marked as yellow and treated as conformed ! Tp is decremented by B
where: B = size of packet in bytes Tp = size of peak token bucket in bytes. The maximum size of this bucket is the configured peak burst. Tc = size of the committed token bucket in bytes. The maximum size of this bucket is the configured committed burst. t = time
To configure a single-rate hard limit, set the committed rate and burst rate to the desired values, the committed action to transmit, the conformed action to drop, and the exceeded action to drop. The peak rate must be set to zero.
NOTE: You can also achieve the characteristics of the single-rate hard limit by configuring a one-rate rate-limit profile with the extended burst rate set to zero.
Overview
References
For more information about policy management, see the following resources:
!
RFC 2474Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (December 1998) RFC 2475An Architecture for Differentiated Services (December 1998) RFC 2697A Single Rate Three Color Marker (September 1999) RFC 2698A Two Rate Three Color Marker (September 1999) RFC 3198Terminology for Policy-Based Management (November 2001)
! ! ! !
Configuration Tasks
Several of the following tasks are optional. Perform the required tasks and also any optional tasks that you need for your policy management configuration:
! ! ! ! ! !
(Optional) Create a rate-limit profile. (Optional) Create a CLACL. Create a policy list. Create a classifier group. Create one or more policy rules within the classifier group. Apply a policy list to an interface or profile.
Creating a Rate-Limit Profile

You can create one-rate or two-rate rate-limit profiles. The rate-limit-profile one-rate command provides a hard-limit rate limiter or a TCP-friendly rate limiter. The rate-limit-profile two-rate command provides a two-rate, three-color marking mechanism.
NOTE: Mark actions and mask values are supported only on IP, IPv6, and MPLS
rate-limit profiles.
10
References
One-Rate
To create or modify a one-rate rate-limit profile, use the following commands with the one-rate keyword:
! ! ! !
ip rate-limit-profile ipv6 rate-limit-profile mpls rate-limit-profile l2tp rate-limit-profile
The following example creates a rate-limit profile named tcpFriendly8Mb. This rate-limit profile, when included as part of a rule in a policy list, sets a TCP-friendly rate for a specified flow:
host1(config)#ip rate-limit-profile tcpFriendly8Mb one-rate host1(config-rate-limit-profile)#committed-rate 8000000 host1(config-rate-limit-profile)#committed-burst 1500000 host1(config-rate-limit-profile)#excess-burst 3000000 host1(config-rate-limit-profile)#committed-action transmit host1(config-rate-limit-profile)#conformed-action transmit host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#mask-val 255
Two-Rate
To create or modify a two-rate rate-limit profile, use the following commands with the two-rate keyword:
! ! ! !
ip rate-limit-profile ipv6 rate-limit-profile mpls rate-limit-profile l2tp rate-limit-profile
The following example creates a rate-limit profile named hardlimit9Mb. This rate-limit profile, when included as part of a rule in a policy list, sets a hard limit on the specified committed rate with no peak rate or peak burst ability:
host1(config)#ip rate-limit-profile hardlimit9Mb two-rate host1(config-rate-limit-profile)#committed-rate 9000000 host1(config-rate-limit-profile)#committed-burst 20000 host1(config-rate-limit-profile)#committed-action transmit host1(config-rate-limit-profile)#conformed-action drop host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#mask-val 255
11
The following example modifies the rate-limit profile named hardlimit9Mb to include an exceeded action that marks the packets that exceed the peak rate. This marking action sets the DS field in the ToS byte (the six most significant bits) to the decimal value of 7 using a mask value of 0xFC:
host1(config)#ip rate-limit-profile hardlimit9Mb two-rate host1(config-rate-limit-profile)#exceeded-action mark 7 host1(config-rate-limit-profile)#mask-val 252
To set IP precedence in the ToS byte, use the mask value of 0xE0, for visibility into the three most significant bits. committed-action
! !
Use to set the committed action for a rate-limit profile. Valid committed actions are:
! ! !
dropDrop the packet. transmitTransmit the packet. markFor IP and IPv6 rate-limit profiles, mark the packet by setting the ToS byte (IP) or traffic class field (IPv6) to the specified 8-bit value, and transmit the packet. The mark value is masked with the default 255 unless it is overridden by the mask-val command to specify a different mask. mark-expFor MPLS rate-limit profiles, set the EXP bits of MPLS packets to the specified value in the range 07, and transmit the packet. The mark EXP value is masked with the default 7 unless you use the exp-mask command to specify a different mask.
! !
Packets are colored green. Example

host1(config-rate-limit-profile)#committed-action transmit
Use the no version to restore the default value, transmit.
committed-burst
! !
Use to set the committed burst in bytes for a rate-limit profile. When you specify a nonzero value for the rate, the burst size is automatically calculated for a 100-ms burst as described below for the committed-rate command. If the calculated burst size is less than the default value of 8 KB, the default value is used. During a software upgrade, the committed burst size in a rate-limit profile is automatically set to 8192 bytes if it was less than that value before the upgrade. Example
host1(config-rate-limit-profile)#committed-burst 1500000
Use the no version to restore the default value, 8192 bytes.
12
committed-rate
! !
Use to set the committed rate in bits per second for a rate-limit profile. When you specify a nonzero value for the committed rate, the committed burst size is calculated based on a 100-ms burst as follows:
committed burst in bytes = (committed rate in bps x 100 ms) 8 bits per byte
The router displays committed rate in bits per second and committed burst in bytes. For example, if the rate is 8 Mbps, the burst size is 100 ms x 8 Mbps = 800,000 bits or 100,000 bytes:
committed burst = (8,000,000 bps x 100 ms) 8 = 100,000 bytes
For this example, displaying the rate-limit profile shows:

committed-rate 8000000 committed-burst 100000
If the calculated burst value is less than the default burst size of 8 KB, the default burst size is used. For most configurations this value should be sufficient, making it optional for you to configure a value for the associated committed burst size.
!
Example
host1(config-rate-limit-profile)#committed-rate 800000
Use the no version to restore the default value, 0.
conformed-action
! !
Use to set the conformed action for a rate-limit profile. Valid conformed actions are:
! ! !
! !
Packets are colored yellow. Example

host1(config-rate-limit-profile)#conformed-action transmit
Use the no version to restore the default value, transmit.
13
exceeded-action
! !
Use to set the exceeded action for a rate-limit profile. Valid exceeded actions are:
! ! !
! !
Packets are colored red. Example

host1(config-rate-limit-profile)#exceeded-action drop
Use the no version to restore the default value, drop.
excess-burst
!
For one-rate rate-limit profiles only, use to set the excess burst in bytes for a rate-limit profile. Example
host1(config-rate-limit-profile)#excess-burst 3000000
exp-mask
! !
Use to set the mask value used for MPLS rate-limit profiles. This command is associated with the following commands:
! ! !
committed-action conformed-action exceeded-action
Example
host1(config-rate-limit-profile)#exp-mask 5
14
mask-val
! !
Use to set the mask value used for IP and IPv6 rate-limit profiles. This command is associated with the following commands:
! ! !
committed-action conformed-action exceeded-action
Use the following mask values to set the appropriate bits in the ToS field of the IP packet header or in the traffic class field of the IPv6 packet header:
! ! !
IP precedence0xE0 (three most significant bits) DS field0xFC (six most significant bits) TOS (IP) or Traffic Class field (IPv6)0xFF (default)
Example
host1(config-rate-limit-profile)#mask-val 0XFC
peak-burst
!
For two-rate rate-limit profiles only, use to set the peak burst in bytes for a rate-limit profile. When you specify a nonzero value for the peak rate, the peak burst size is automatically calculated for a 100-ms burst as described below for the peak-rate command. If the calculated peak burst size is less than the default value of 8192 bytes, the default value is used. During a software upgrade, the committed burst size in a rate-limit profile is automatically set to 8192 bytes if it was less than that value before the upgrade. Example
host1(config-rate-limit-profile)#peak-burst 96256
Use the no version to restore the default value, 8192 bytes.
peak-rate
!
For two-rate rate-limit profiles only, use to set the peak rate in bits per second for a rate-limit profile. When you specify a nonzero value for the peak rate, the peak burst size is calculated based on a 100-ms burst as follows:
peak burst in bytes = (peak rate in bps x 100 ms) 8 bits per byte
The CLI displays peak rate in bits per second and peak burst in bytes. For example, if the rate is 8 Mbps, the burst size is 100 ms x 8 Mbps = 800,000 bits or 100,000 bytes:
peak burst = (8,000,000 bps x 100 ms) 8 = 100,000 bytes
15
For this example, displaying the rate-limit profile shows:

peak-rate 8000000 peak-burst 100000
If the calculated peak burst value is less than the default peak burst size of 8 KB, the default burst size is used. For most configurations this value is sufficient, making it optional to configure the associated peak burst size.
!
During a software upgrade, the peak rate in a rate-limit profile is automatically set to 0 if it was nonzero but less than the committed rate before the upgrade. Example
host1(config-rate-limit-profile)#peak-rate 0
rate-limit-profile one-rate
!
Use to create a rate-limit profile and enter Rate Limit Profile Configuration mode, from which you can configure attributes for the rate-limit profile. See Table 5 on page 8.
NOTE: The JUNOSe software includes the layer 2 headers in the calculations it uses
to enforce the rates that you specify in rate-limit profiles.

!
Use one of the ip, ipv6, l2tp, or mpls keywords in front of the command to specify the type of rate-limit-profile you want to create or modify. If you do not include one of the keywords, the router creates an IP rate-limit profile by default. If you do not include a one-rate or two-rate keyword, the default is a two-rate rate-limit profile. If you enter a rate-limit-profile command with the one-rate keyword and then type exit, the router creates a rate-limit profile with the default values shown in Table 7:
Table 7: One-Rate Rate-Limit-Profile Defaults Policy Attribute
type committed-rate committed-burst excess-burst committed-action conformed-action exceeded-action mask (IP and IPv6 rate-limit profiles) exp-mask (MPLS rate-limit profiles)
Default Value
one-rate 0 8192 0 transmit transmit drop 255 7
16
Example
host1(config)#ip rate-limit-profile tcpFriendly10Mb one-rate
Use the no version to remove a rate-limit profile.
rate-limit-profile two-rate
!
Use to create a rate-limit profile and enter Rate Limit Profile Configuration mode, from which you can configure attributes for the rate-limit profile. See Table 5 on page 8.
NOTE: The JUNOSe software includes the layer 2 headers in the calculations it uses
to enforce the rates that you specify in rate-limit profiles

!
Use one of the ip, ipv6, l2tp, or mpls keywords in front of the command to specify the type of rate-limit profile you want to create or modify. If you do not include one of the keywords, the router creates an IP rate-limit profile by default. If you do not include a one-rate or two-rate keyword, the default is a two-rate rate-limit profile. If you enter a rate-limit-profile command and then type exit, the router creates a rate-limit profile with the default values shown in Table 8:
Table 8: Two-Rate Rate-Limit-Profile Defaults Policy Attribute
type committed-rate committed-burst peak-rate peak-burst committed-action conformed-action exceeded-action mask (IP and IPv6 rate-limit profiles) exp-mask (MPLS rate-limit profiles)
Default Value
two-rate 0 8192 0 8192 transmit transmit drop 255 7
During a software upgrade, certain values are set as follows:

!
Committed burst sizeSet to 8192 if it was less than that value before the upgrade Peak burst sizeSet to 8192 if it was less than that value before the upgrade Peak rateSet to 0 if it was nonzero but less than the committed rate before the upgrade
17
Example
host1(config)#ip rate-limit-profile hardlimit9Mb two-rate
Use the no version to remove a rate-limit profile.
NOTE: Commands that you issue in Rate Limit Profile Configuration mode do not take effect until you exit from that mode.
Creating Classifier Control Lists

Use the following commands to create or modify CLACLs:
! ! ! ! ! ! !
frame-relay classifier-list gre-tunnel classifier-list ip classifier-list ipv6 classifier-list l2tp classifier-list mpls classifier-list vlan classifier-list
frame-relay classifier-list
!
Use to create or modify a Frame Relay classifier control list.
NOTE: Do not use the asterisk (*) for the name of a classifier list. The asterisk is used as a wildcard for the classifier-group command.
!
Use the following keywords to configure the list:

!
traffic-classMatches packets with a class that you defined using the traffic-class command color
"
greenMatches packets with color green, indicating a low drop preference yellowMatches packets with color yellow, indicating a medium drop preference redMatches packets with color red, indicating a high drop preference
"
" !
user-packet-classMatches packets with the specified user packet class value de-bitMatches Frame Relay packets with the specified DE bit value, either 0 or 1
18
Example
host1(config)#frame-relay classifier-list frclassifier color red user-packet-class 10 de-bit 1
Use the no version to remove the classifier control list.
gre-tunnel classifier-list
!
Use to create or modify a GRE tunnel classifier control list.
!

!
traffic-classMatches traffic with a class that you defined using the traffic-class command color
"
greenMatches packets with color green, indicating a low drop preference yellowMatches packets with color yellow, indicating a medium drop preference redMatches packets with color red, indicating a high drop preference tosSpecifies the use of the whole 8 bits of the ToS byte; range is 0255 dsfieldSpecifies the use of the upper 6 bits of the ToS byte; range is 063 precedenceSpecifies the use of the upper 3 bits of the ToS byte; range is 07
"
" !
tos, dsfield, and precedence specify the ToS byte in the IP header
"
"
"
user-packet-classMatches packets with the specified user packet class value
Example
host1(config)#gre-tunnel classifier-list greClassifier50 color yellow user-packet-class 7 dsfield 40
ip classifier-list
!
Use to create or modify an IP classifier control list.

host1(config)#ip classifier-list YourListName ip any any
!
Use the user-packet-class keyword to match packets with the specified user packet class value.
!
19
Use the notProtocol, notSourceIpAddr, and notDestinationIpAddr options to cause a match when those attributes in the packet being compared have different values. For example, to match a non-TCP packet originating from IP address 172.28.100.52:
host1(config)#ip classifier-list YourListName not tcp host 172.28.100.52 any
Use the protocol option to match a specific protocol number or to match only packets of one of the following protocol types:
!
ipIP protocol attributes, such as source and destination IP address and mask icmpICMP protocol attributes, such as source and destination IP address and mask, ICMP type and code igmpIGMP protocol attributes, such as source and destination IP address and mask, and IGMP type tcpTCP protocol attributes, such as source and destination IP address and mask, and source and destination TCP operator and port udpUDP protocol attributes, such as source and destination IP address and mask, and source and destination UDP operator and port
Use the sourceAddress and destinationAddress options to classify traffic based on source and destination addresses. You can specify the address as a host address, a subnet, or a wildcard. If you specify the address as a subnet, the mask, in binary notation, must be a series of contiguous zeros, followed by a series of contiguous ones. The any keyword is the address wildcard, matching traffic for any address.
!
In the following example, traffic is classified on any source or destination address:

host1(config)#ip classifier-list YourListName ip any any
In the following example, traffic is classified on source host address 10.10.10.10 and any destination address:
host1(config)#ip classifier-list YourListName ip host 10.10.10.10 any
In the following example, traffic is classified on source address subnet 10.10.x.x and destination host address 10.10.10.2:
host1(config)#ip classifier-list YourListName ip 10.10.0.0 0.0.255.255 host 10.10.10.2
Use the sourceQualifier option to specify a single TCP or UDP port or a range of ports. The sourceQualifier option is composed of:
!
portNumberSingle port number or the beginning of a range of port numbers portOperatorOne of the following:
" " "
eqequal to ltless than gtgreater than
20
" " !
neqnot equal to rangerange of ports
toPortNumberEnd of a range of port numbers
For example, the following command matches packets with source address 198.168.30.100 and UDP source port numbers in the range 110:
host1(config)#ip classifier-list YourListName udp host 192.168.30.100 range 1 10 any
!
Use multiple elements in classifier lists to configure classification to match any of multiple field combinations. The behavior of multiple-element classifier-list classification is the logical OR of the elements in the CLACL. For example, to match all packets that have a source IP address of 192.168.30.100 or have a destination IP address of 192.168.30.200:
host1(config)#ip classifier-list boston5 ip host 192.168.30.100 any host1(config)#ip classifier-list boston5 ip any host 192.168.30.200
The classifier control list boston5 matches all packets with the source IP address of 192.168.30.100 or with the destination IP address of 192.168.30.200.
!
Use the following keywords to configure classification to match route-class values:

!
source-route-classClassifies on packets associated with a route class based on the packets source address; route-class range is 0255; default is 0. destination-route-classClassifies on incoming packets associated with a route class based on the packets destination address; route-class range is 0255; default is 0. local trueMatches packets that are destined to a local interface. local falseMatches packets that are traversing the router; this is the default setting.
! !
For example:
host1(config)#ip classifier-list svale20 source-route-class 1 ip any any host1(config)#ip classifier-list svale30 destination-route-class 1 ip any any tos 10 host1(config)#ip classifier-list svale40 source-route-class 1 local true ip any any host1(config)#ip classifier-list west25 source-route-class 1 local false ip any any
In the previous example, classifier control lists match route-class values as follows:
! !
svale20 matches the source address lookup route-class value of 1. svale30 matches the destination address lookup route-class value of 1 and a ToS byte value of 10. svale40 matches the source address lookup route-class value of 1 and the packets destined to a local interface.
21
west20 matches the source address lookup route-class value of 1 and packets that are not destined for a local interface (packets destined for remote interfaces). tosSpecifies the use of the whole 8 bits of the ToS byte; range is 0255; for example:
host1(config)#ip classifier-list tos128 ip any any tos 128
Use the following keywords to match the ToS byte in the IP header:
!
dsfieldSpecifies the use of the upper 6 bits of the ToS byte; range is 063; for example:
host1(config)#ip classifier-list low-drop-prec ip any any dsfield 10
precedenceSpecifies the use of the upper 3 bits of the ToS byte; range is 07; for example:
host1(config)#ip classifier-list priority ip any any precedence 1
Use the destinationQualifier option to specify a single TCP or UDP port or range of ports, an ICMP code and optional type, or an IGMP type. The destinationQualifier option is composed of the following suboptions:
!
portNumberSingle port number or the beginning of a range of port numbers (TCP and UDP only) portOperatorOne of the following (TCP and UDP only):
" " " " "
eqEqual to ltLess than gtGreater than neqNot equal to rangeRange of ports
! ! ! !
toPortNumberEnd of a range of port numbers (TCP and UDP only) icmpTypeICMP message type (ICMP only) icmpCodeICMP message code (ICMP only) igmpTypeIGMP message type (IGMP only)
For example, the following command matches packets with source address 198.168.30.100 and ICMP type 2 and code 10:
host1(config)#ip classifier-list YourListName icmp host 192.168.30.100 any 2 10
!
Use the tcp-flags keyword and a logical equation (a quotation-enclosed string using ! for NOT, & for AND) to match one or more of the following TCP flags: ack, fin, psh, rst, syn, urg. For example:
host1(config)#ip classifier-list telnetConnects tcp 192.168.10.0 0.0.0.255 host 10.10.10.10 eq 23 tcp-flags "syn & !ack"
22
Use the ip-flags keyword and a logical equation (a quotation-enclosed string using ! for NOT, & for AND) to match one or more of the following IP flags: dont-fragment, more-fragments, reserved. For example:
host1(config)#ip classifier-list dontFragment ip any any ip-flags "dont-fragment"
For both IP flags and TCP flags, if you specify only a single flag, the logical equation does not require quotation marks. Use the ip-frag-offset keyword and the eq or gt operator to match an IP fragmentation offset equal to 0, 1, or greater than 1. For example, the following commands configure a policy to filter fragmentation offsets equal to 1:
host1(config)#ip classifier-list fragOffsetAttack ip any host 10.10.10.10 ip-frag-offset eq 1 host1(config)#ip policy-list dosProtect host1(config-policy-list)#filter classifier-group fragOffsetAttack host1(config-policy-list)#forward
Use the traffic-class keyword to match packets with a traffic class that you defined using the traffic-class command. Use the color keyword to match on one of the following:
! !
greenMatches packets with color green, indicating a low drop preference yellowMatches packets with color yellow, indicating a medium drop preference redMatches packets with color red, indicating a high drop preference user-packet-classMatches packets with the specified user packet class value
! !
Examples: IP CLACLs
To set up a CLACL to accept IP traffic from all source addresses on the subnet of XYZ Corp:
host1(config)#ip classifier-list XYZCorpPermit ip 192.168.0.0 0.0.255.255 any
To create a CLACL that filters all ICMP echo requests headed toward an access link for XYZ Corp under a denial-of-service attack:
host1(config)#ip classifier-list XYZCorpIcmpEchoReqs icmp any any 8 0
To create a CLACL that matches all IGMP type 1 packets:

host1(config)#ip classifier-list XYZCorpIgmpType1 igmp any any 1
To create a CLACL that matches all traffic on UDP source ports greater than 100:
host1(config)#ip classifier-list XYZCorpUdp udp any gt 100 172.17.2.1 0.0.255.255
23
ipv6 classifier-list
!
Use to create or modify an IPv6 classifier control list.
!

!
traffic-classMatches packets with a traffic class that you defined using the traffic-class command color
"
"
" !
Use the protocol option to match a specific protocol number and specify protocol attributes:
! !
icmpv6ICMP type and code tcpTCP protocol attributes, such as source and destination port, and source and destination TCP operator and port udpUDP protocol attributes, such as source and destination port
! !
For TCP and UDP, use the portQualifier option to specify a single port or a range of source or destination ports. The portQualifier option is composed of:
!
portNumberSingle port number or the beginning of a range of port numbers toPortNumberEnd of a range of port numbers portOperatorOne of the following:
" " " " "
! !
eqequal to ltless than gtgreater than neqnot equal to rangerange of ports
For example, the following command matches packets from port 75:
host1(config)#ipv6 classifier-list YourListName udp destination-port eq 75
!
For TCP, use the tcp-flags keyword and a logical equation (a quotation-enclosed string using ! for NOT, & for AND) to match one or more of the following TCP flags: ack, fin, psh, rst, syn, urg. For example:
host1(config)#ipv6 classifier-list telnetConnects tcp destination-port eq 23 tcp-flags "syn & !ack"
24
For ICMPv6, use the icmp-type option to specify the icmpType and icmpCode parameters:
! !
icmpTypeICMP message type; in the range 0255 icmpCodeICMP message code; in the range 0255
For example, the following command matches ICMPv6 packets with an ICMP type of 3 and code of 6:
host1(config)#ipv6 classifier-list listname icmpv6 icmp-type 3 icmp-code 6
!
Use the following keywords to configure classification to match route-class values:

!
source-route-classClassifies on packets associated with a route class based on the packets source address; route-class range is 0255; default is 0. destination-route-classClassifies on incoming packets associated with a route class based on the packets destination address; route-class range is 0255; default is 0. local trueMatches packets that are destined to a local interface. local falseMatches packets that are traversing the router; this is the default setting.
! !
For example:
host1(config)#ipv6 classifier-list svale20 source-route-class 1 host1(config)#ipv6 classifier-list svale30 destination-route-class 1 tcfield 10 host1(config)#ipv6 classifier-list svale40 source-route-class 1 local true host1(config)#ipv6 classifier-list west25 source-route-class 1 local false
In the previous example, classifier control lists match route-class values as follows:
! !
svale20 matches the source address lookup route-class value of 1. svale30 matches the destination address lookup route-class value of 1 and a traffic-class value of 10. svale40 matches the source address lookup route-class value of 1 and the packets destined to the local interface. west25 matches the source address lookup route-class value of 1 and packets that are not destined for the local interface (packets destined for remote interfaces).
Use the source-address, source-host, destination-address, and destination-host options to classify traffic based on source and destination addresses. You can specify the address as an IPv6 address or an IPv6 prefix. In the following example, traffic is classified on source host address 2001:db8:1::8001 and destination address 2001:db8:3::/48:
host1(config)#ipv6 classifier-list YourClaclList source-host 2001:db8:1::8001 destination-address 2001:db8:3::/48
25
Use the following keywords to specify traffic class information in the IPv6 header:
!
tcfieldSpecifies the use of the whole 8 bits of the traffic-class byte; range is 0255 dsfieldSpecifies the use of the upper 6 bits of the traffic-class byte; range is 063 precedenceSpecifies the use of the upper 3 bits of the traffic-class byte; range is 07
Example
host1(config)#ipv6 classifier-list ipv6classifier color red user-packet-class 5 tcfield 10
l2tp classifier-list
!
Use to create or modify an L2TP classifier control list.
!

!
"
"
" !
Example
host1(config)#l2tp classifier-list l2tpclassifier color red user-packet-class 7
mpls classifier-list
!
Use to create or modify an MPLS classifier control list.
!

!
traffic-classMatches packets with a traffic class that you defined using the traffic-class command
26
color
"
"
" !
user-packet-classMatches packets with the specified user packet class value exp-bitsSpecifies the value of the EXP bit to match in the range 07 exp-maskSpecifies the mask applied to the EXP bits in the range 17
! ! !
Example
host1(config)#mpls classifier-list mplsClass user-packet-class 10 exp-bits 3 exp-mask 5
vlan classifier-list
!
Use to create or modify a VLAN classifier control list.
!

!
"
"
" !
user-packet-classMatches packets with the specified user packet class value user-prioritySpecifies the value of the user-priority bits, which you define in the policy list
classifier-list classifier-list classifier-list classifier-list classifier-list classifier-list classifier-list classifier-list lowLatencyLowDrop user-priority 7 lowLatencyLowDrop user-priority 6 lowLatency user-priority 5 excellentEffort user-priority 4 bestEffort user-priority 3 bestEffort user-priority 2 bestEffort user-priority 1 bestEffort user-priority 0
Example
host1(config)#vlan host1(config)#vlan host1(config)#vlan host1(config)#vlan host1(config)#vlan host1(config)#vlan host1(config)#vlan host1(config)#vlan

!
27
Creating Policy Lists

You can create a policy list with an unlimited number of classifier groups, each containing an unlimited number of rules. These rules can reference up to 512 classifier entries. You can create policy lists for Frame Relay, IP, IPv6, GRE tunnels, L2TP, MPLS, and VLANs.
Creating a Policy List for IP

The following example creates an IP policy list named routeForABCCorp. For information about creating the CLACLs and rate-limit profile used in this example, see the previous sections. 1. Create the policy list routeForABCCorp.
host1(config)#ip policy-list routeForABCCorp host1(config-policy-list)#
2. Create the classification group for the CLACL named ipCLACL10 and assign the precedence to the classification group.
host1(config-policy-list)#classifier-group ipCLACL10 precedence 75 host1(config-policy-list-classifier-group)#
3. Add a rule that specifies a group of forwarding solutions based on classifier list ipCLACL10.
host1(config-policy-list-classifier-group)#forward next-hop 192.0.2.12 order 10 host1(config-policy-list-classifier-group)#forward next-hop 192.0.100.109 order 20 host1(config-policy-list-classifier-group)#forward next-hop 192.120.17.5 order 30 host1(config-policy-list-classifier-group)#forward interface ip 3/1 order 40
4. Add a rule that sets a ToS byte value of 125 for packets based on classifier list ipCLACL10.
host1(config-policy-list-classifier-group)#mark tos 125
5. Add a rule that uses rate-limit profile ipRLP25.

host1(config-policy-list-classifier-group)#rate-limit-profile ipRLP25
6. Exit Classifier Group Configuration mode for ipCLACL10, then create a new classification group for classifier list ipCLACL20. Add a rule that filters packets based on classifier list ipCLACL20.
host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group ipCLACL20 precedence 125 host1(config-policy-list-classifier-group)#filter
7. Exit Policy List Configuration mode to save the configuration.

host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit host1(config)# 28
!
8. Display the policy list.

host1#show policy-list routeForABCCorp Policy Table ------ ----IP Policy routeForABCCorp Administrative state: enable Reference count: 0 Classifier control list: ipCLACL10, precedence 75 forward Virtual-router: default List: next-hop 192.0.2.12, order 10, rule 2 (active) next-hop 192.0.100.109, order 20, rule 3 (reachable) next-hop 192.120.17.5, order 30, rule 4 (reachable) interface ip3/1, order 40, rule 5 mark tos 125 rate-limit-profile ipRLP25 Classifier control list: ipCLACL20, precedence 125 filter
NOTE: Commands that you issue in Policy Configuration mode do not take effect until you exit from that mode.
Creating a Policy List for IPv6

The following example creates an IPv6 policy list named routeForIPv6. For information about creating the CLACL used in this example, see the previous sections. 1. Create the policy list routeForIPv6.
host1(config)#ipv6 policy-list routeForIPv6 host1(config-policy-list)#
2. Create the classification group for the CLACL named ipv6tc67 and assign the precedence to the classification group.
host1(config-policy-list)#classifier-group ipv6tc67 precedence 75 host1(config-policy-list-classifier-group)#
3. Add a rule to color packets as red, and a second rule that sets the traffic class field of the packets to 7.
host1(config-policy-list-classifier-group)#color red host1(config-policy-list-classifier-group)#mark tcfield 7

host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit host1(config)#
29

host1#show policy-list routeForIPv6 Policy Table ------ ----IPv6 Policy routeForIPv6 Administrative state: enable Reference count: 0 Classifier control list: ipv6tc67, precedence 75 color red mark tc-precedence 7
Creating a Policy List for Frame Relay

The following example creates a Frame Relay policy that on egress marks the DE bit to 1, and on ingress colors frames with a DE bit of 1 as red. 1. Create the policy list used to mark egress traffic, then create the classifier group for packets conforming to CLACL frMatchDeSet. Add a rule that marks the DE bit as 1.
host1(config)#frame-relay policy-list frOutputPolicy host1(config-policy-list)#classifier-group frMatchDeSet host1(config-policy-list-classifier-group)#mark-de 1 host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit
2. Create the policy list used for the ingress traffic. and create the classifier group conforming to CLACL frMatchDeSet. Add a rule that colors the ingress traffic.
host1(config)#frame-relay policy-list frInputPolicy host1(config-policy-list)#classifier-group frGroupA host1(config-policy-list-classifier-group)#color red host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit
3. Apply the policy lists.

host1(config)#interface serial 5/0:1/1.1 host1(config-subif)#frame-relay policy output frOutputPolicy statistics enabled host1(config-subif)#ip address 10.0.0.1 255.255.255.0 host1(config-subif)#exit host1(config)#interface serial 5/1:1/1.1 host1(config-subif)#frame-relay policy input frInputPolicy statistics enabled host1(config-subif)#exit
4. Display interface information to view the applied policies.

host1#show frame-relay subinterface Frame relay sub-interface SERIAL5/0:1/1.1, status is up Number of sub-interface down transitions is 0 Time since last status change 03:04:59 No baseline has been set !
30
In bytes: 660 Out bytes: 660 In frames: 5 Out frames: 5 In errors: 0 Out errors: 0 In discards: 0 Out discards: 0 In unknown protos: 0 Frame relay policy output frOutputPolicy classifier-group frGroupA entry 1 5 packets, 640 bytes mark-de 1 Frame relay sub-interface SERIAL5/1:1/1.1, status is up Number of sub-interface down transitions is 0 Time since last status change 03:05:09 No baseline has been set In bytes: 660 Out bytes: 660 In frames: 5 Out frames: 5 In errors: 0 Out errors: 0 In discards: 0 Out discards: 0 In unknown protos: 0 Frame relay policy input frInputPolicy classifier-group frMatchDeSet entry 1 5 packets, 660 bytes color red
5. Display the classifier list.

host1#show classifier-list detailed Classifier Control List Table ---------- ------- ---- ----Frame relay Classifier Control List frMatchDeSet Reference count: 1 Entry count: 1 Classifier-List frMatchDeSet Entry 1 DE Bit: 1
6. Display the policy lists.

host1#show policy-list Policy Table ------ ----Frame relay Policy frOutputPolicy Administrative state: enable Reference count: 0 Classifier control list: frMatchDeSet, precedence 100 mark-de 1 Frame relay Policy frInputPolicy Administrative state: enable Reference count: 0 Classifier control list: frGroupA, precedence 100 color red
31
Creating a Policy List for GRE Tunnels

The following example creates a GRE tunnel policy list named routeGre50. For information about creating the CLACL used in this example, see the previous sections. 1. Create the policy list routeGre50.
host1(config)#gre-tunnel policy-list routeGre50
2. Create the classification group for the CLACL named gre8 and assign a precedence of 150 to it.
host1(config-policy-list)#classifier-group gre8 precedence 150 host1(config-policy-list-classifier-group)#
3. Add two rules for traffic based on the CLACL named gre8: one rule to color packets as red, and a second rule that specifies the ToS DS field value to be assigned to the packets.
host1(config-policy-list-classifier-group)#color red host1(config-policy-list-classifier-group)#mark dsfield 20 host1(config-policy-list-classifier-group)#


host1#show policy-list routeGre50 Policy Table ------ ----GRE Tunnel Policy routeGre50 Administrative state: enable Reference count: 0 Classifier control list: gre8, precedence 150 color red mark dsfield 20
32
Creating a Policy List for L2TP

The following example creates an L2TP policy list. 1. Create the policy list routeForl2tp.
host1(config)#l2tp policy-list routeForl2tp host1(config-policy-list)#
2. Create the classification group to match all packets.

host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#
3. Add a rule to color packets as red, and a second rule that uses the rate-limit profile l2tpRLP10.
host1(config-policy-list-classifier-group)#color red host1(config-policy-list-classifier-group)#rate-limit-profile l2tpRLP10


host1#show policy-list routeForl2tp Policy Table ------ ----L2TP Policy routeForl2tp Administrative state: enable Reference count: 0 Classifier control list: *, precedence 100 color red rate-limit-profile l2tpRLP20
Creating a Policy List for MPLS

The following example creates an MPLS policy list. 1. Create the policy list routeForMpls.
host1(config)#mpls policy-list routeForMpls host1(config-policy-list)#
2. Create the classification group.

host1(config-policy-list)#classifier-group * precedence 200 host1(config-policy-list-classifier-group)#
33
3. Add one rule that sets the EXP bits for all packets to 2, and a second rule that uses the rate-limit profile mplsRLP5.
host1(config-policy-list-classifier-group)#mark-exp 2 host1(config-policy-list-classifier-group)#rate-limit-profile mplsRLP5


host1#show policy-list routeForMpls Policy Table ------ ----MPLS Policy routeForMpls Administrative state: enable Reference count: 0 Classifier control list: *, precedence 200 mark-exp 2 mask 7 rate-limit-profile mplsRLP5
Creating a Policy List for VLANs

The following example creates a VLAN policy list named routeForVlan. The classifier group lowLatencyLowDrop uses the default precedence of 100. 1. Create the policy list routeForVlan.
host1(config)#vlan policy-list routeForVlan host1(config-policy-list)#
2. Create the classification group.

host1(config-policy-list)#classifier-group lowLatencyLowDrop host1(config-policy-list-classifier-group)#
3. Create a rule that adds the lowLatencyLowDrop traffic class for all packets that fall into the lowLatencyLowDrop classification.
host1(config-policy-list-classifier-group)#traffic-class lowLatencyLowDrop
4. Add a rule that sets the drop precedence for all packets that fall into the lowLatencyLowDrop classification to green.
host1(config-policy-list-classifier-group)#color green
34
5. Add a rule that sets the user-priority bits for all packets that fall into the lowLatencyLowDrop classification to 7.
host1(config-policy-list-classifier-group)#mark-user-priority 7
6. Exit to Policy List Configuration mode, then add traffic class rules for packets that conform to different CLACLs.
host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group lowLatency host1(config-policy-list-classifier-group)#traffic-class lowLatency host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group excellentEffort host1(config-policy-list-classifier-group)#traffic-class excellentEffort host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group bestEffort host1(config-policy-list-classifier-group)#traffic-class bestEffort


host1#show policy-list routeForVlan Policy Table ------ ----VLAN Policy routeForVlan Administrative state: enable Reference count: 0 Classifier control list: lowLatencyLowDrop, precedence 100 traffic-class lowLatencyLowDrop color green mark-user-priority 7 Classifier control list: lowLatency, precedence 100 traffic-class lowLatency Classifier control list: excellentEffort, precedence 100 traffic-class excellentEffort Classifier control list: bestEffort, precedence 100 traffic-class bestEffort
35
frame-relay policy-list gre-tunnel policy-list ip policy-list ipv6 policy-list l2tp policy-list mpls policy-list vlan policy-list
! !
Use to create or modify a policy list and to enter Policy List Configuration mode. If you enter a policy-list command and then enter exit, the router creates a policy list with no rules. If the router does not find any rules in a policy, it inserts a default filter rule. Attaching this policy list to an interface filters all packets on that interface.
NOTE: If you do not specify one of the frame-relay, gre-tunnel, ip, ipv6, l2tp, mpls, or vlan keywords, the router creates an IP policy list.
!
Example
host1(config)#ip policy-list routeForXYZCorp host1(config-policy-list)#
Use the no version to remove a policy list.
Creating Classifier Groups and Policy Rules

Classifier groups contain the policy rules that make up a policy list. A policy rule is an association between a policy action and an optional CLACL. The CLACL defines the packet flow on which the policy action is taken. A policy list might contain multiple classifier groupsyou can specify the precedence in which classifier groups are evaluated. Classifier groups are evaluated starting with the lowest precedence value. Classifier groups with equal precedence are evaluated in the order of creation.
NOTE: For IP policies, the forward command supports the order keyword, which
enables you to order multiple forward rules within a single classifier group. (See Creating Multiple Forwarding Solutions with IP Policy Lists on page 38.) From Policy Configuration mode, you can assign a precedence value to a CLACL by using the precedence keyword when you create a classifier group. The default precedence value is 100. For example:
host1(config-policy-list)#classifier-group ipCLACL25 precedence 21 host1(config-policy-list-classifier-group)#
The classifier-group command puts you in Classifier Group Configuration mode. In this mode you configure the policy rules that make up the policy list. For example:
host1(config-policy-list-classifier-group)#forward next-hop 172.18.20.54
36
To stop and start a policy rule without losing statistics, you can suspend the rule. Suspending a rule maintains the policy rule with its current statistics, but the rule no longer affects packets in the forwarding path. From Classifier Group Configuration mode, you can suspend a rule by using the suspend version of that policy rule command. The no suspend version reactivates a suspended rule. For example:
host1(config-policy-list-classifier-group)#suspend forward next-hop 172.18.20.54 host1(config-policy-list-classifier-group)#no suspend forward next-hop 172.18.20.54
You can add, remove, or suspend policy rules while the policy is attached to one or more interfaces. The modified policy takes effect once you exit Policy Configuration mode.
Policy Rule Support

Table 9 shows the policy rule commands that you can use for each type of policy list. Yes and No indicate whether the command is supported. NA indicates that the command does not apply to that type of interface.
Table 9: Policy Rule Commands Policy Command
color filter forward log mark mark-de mark-exp mark-user-priority next-hop next-interface
Frame Relay
Yes Yes Yes No NA Yes NA NA NA NA
GRE
Yes Yes Yes No Yes NA NA NA No No
IP
Yes Yes Yes Yes Yes NA NA NA Yes (input policies only) Yes (input and secondary input policies only) Yes Yes Yes
IPv6
Yes Yes Yes No Yes NA NA NA No No
L2TP
Yes Yes Yes No NA NA NA NA NA NA
MPLS
Yes Yes Yes No NA NA Yes NA NA NA
VLAN
Yes Yes Yes No NA NA NA Yes NA NA
rate-limit-profile traffic-class user-packet-class
No Yes Yes
No Yes Yes
Yes Yes Yes
Yes Yes Yes
Yes Yes Yes
No Yes Yes
37
Rules That Provide Routing Solutions

The next interface, next hop, filter, and forward rules provide routing solutions for traffic matching a classifier. A classifier can have only one action that provides a routing solution. If you configure two routing solution rules, such as filter and forward, in the same classifier group, the router displays a warning message, and the rule configured last replaces the previous rule.
Creating Multiple Forwarding Solutions with IP Policy Lists

By default, the router uses a single route table lookup to determine the forwarding solution for packets. For IP policy lists only, the forward command enables you to configure one or more unique forwarding solutions (interfaces or next-hop addresses) that override the route table lookup. By creating a group of forwarding solutions, you can ensure that there is a reachable solution for the packets. You can use the order keyword to specify the order of the group of forwarding solutions within a single forward rule. If no order value is specified, then the default order of 100 is assigned to a solution. The router evaluates the forwarding solutions in the group, starting at the solution with the lowest order value, and then uses the first reachable solution. To be considered a reachable solution, a solution must be a reachable interface or a next-hop address that has a route in the routing table. If no solutions are reachable, the traffic is dropped. The following guidelines apply when you create a group of forwarding solutions in an IP policy list:
! !
You can specify a maximum of 20 forwarding solutions for a classifier. The interface and next-hop elements of a forwarding solution must exist within a single virtual router:
!
Next-interface elements are associated with the virtual router where that interface exists. You can include an optional parameter to specify the virtual router when you define next-hop elements. If only next-hop elements exist and you do not use the virtual router option, then the policy assumes the virtual router context of the command-line interface (CLI).
If you specify both an interface element and a next-hop address element, then they both must be reachable to be used. Also, the interface must be the correct interface for the next-hop address. If you specify a next-hop address, then you can optionally specify that the default route be ignored. If you delete the target (interface or next-hop address) referenced in a rule, that solution is replaced by the null interface but retains the same order number in the policy list. The null interface is always considered unreachable.
38
When a forwarding solution with a lower order value than the currently active solution becomes reachable, the router switches to the lower-ordered solution. If two rules that have the same order value are reachable, then the rule that was created first is used.
NOTE: The forward interface and forward next-hop commands are replacing the next-interface and next-hop commands, which do not support multiple forwarding solutions in a single forward rule.
In the following sample classifier group of a policy list, the forwarding solution of ATM interface 0/0.1 has the lowest order value in the group, and would therefore be selected as the solution for the policy list. However, if this interface is not reachable, the router then attempts to use the solution with the next higher order; which would be ATM interface 12/0.1. If none of the solutions in the group is reachable, the traffic is dropped.
host1(config-policy-list)#classifier-group westfordClacl precedence 200 host1(config-policy-list-classifier-group)#forward interface atm 0/0.1 order 10 host1(config-policy-list-classifier-group)#forward interface atm 12/0.1 order 50 host1(config-policy-list-classifier-group)#forward interface atm 3/0.25 order 300 NOTE: You can use the suspend version of the command to suspend an individual entry in a group of forwarding solutions. The forward rule remains active as long as there is a reachable or active entry in the group of forwarding solutions. If you suspend all entries in the group, the status of the forward rule is changed to suspended.
Classifier Group Command

Use the command described in this section to create classifier groups. See Rate Limiting Individual or Aggregate Packet Flows on page 58 for examples of using this command to rate limit traffic flows. classifier-group
!
Creates a classifier group for a policy list and assigns precedence to the specific CLACL that is referenced in the group; enters Classifier Group Configuration mode, in which you create policy rule configurations related to the specified CLACL. Use the precedence keyword to specify the order in which a classifier group is evaluated compared to other classifier groups. Classifier groups are evaluated from lowest to highest precedence value (for example, a classifier group with a precedence of 1 is used before a classifier group with a precedence of 2). Classifier groups with equal precedence are evaluated in the order of creation, with the group created first having precedence. A default value of 100 is used if no precedence is specified. Example
host1(config-policy-list)#classifier-group westfordClacl precedence 150
39
Use the no version to remove the classifier group and its rules from a policy list.
NOTE: Empty classifier groups have no effect on the routers classification of packets and are ignored by the router. You might inadvertently create empty classifier groups in a policy if you use both the newer CLI style and the older CLI style, which used the Policy List Configuration mode version of the classifier list commands.
Policy Rule Commands

Use the commands described in this section to specify policy rules for classifier groups.
NOTE: The commands listed in this section replace the Policy List Configuration mode versions of the command. For example, the color command replaces the Policy List Configuration mode version of the color command. The original command may be removed completely in a future release.
color
!
Use to color a packet matching the current CLACL as green, yellow, or red:
! ! !
greenHighest precedence yellowIntermediate precedence redLowest precedence
Example
host1(config-policy-list-classifier-group)#color green
! !
Use the suspend version to suspend the color rule within the classifier group. Use the no version to remove the color rule from the classifier group.
filter
! !
Use to define a rule that drops all packets matching the current CLACL. You can enter the filter command while the policy list is referenced by interfaces. Example
host1(config-policy-list-classifier-group)#filter
! !
Use the suspend version to suspend a filter rule within the classifier group. Use the no version to remove the filter rule from the classifier group.
40
forward forward interface forward next-hop

!
Use to define a rule that creates the forwarding solution for packets matching the current CLACL. The forward command can be used while the policy list is referenced by interfaces.
!
Example
host1(config-policy-list-classifier-group)#forward
! !
Use the suspend version to suspend the forward rule within the classifier group. For IP policy lists only:
!
You can use the forward interface command to specify multiple interfaces and the forward next-hop command to specify next-hop addresses as possible forwarding solutions. If you define multiple forwarding solutions for a single CLACL, use the order keyword to specify the order in which the router chooses the solutions. The router uses the first reachable solution in the list, starting with the solution with the lowest order value. The default order value is 100.
NOTE: The forward interface and forward next-hop commands are replacing the next-interface and next-hop commands.
The switch route processor (SRP) module Fast Ethernet port cannot be the destination of the forward next-hop and forward next-interface commands.
!
If you specify a next-hop address as the forwarding solution, you can specify that the default route is not used as a routing solution for the next-hop address when selecting a reachable forward rule entry.
Example
host1(config-policy-list-classifier-group)#forward interface atm 0/0.1 order 10 host1(config-policy-list-classifier-group)#forward interface atm 3/1.2 order 20
Use the no version to remove the forward rule from the classifier group.
log
! !
Use to define a rule that logs all packets conforming to the current CLACL. Example
host1(config-policy-list-classifier-group)#log
! !
Use the suspend version to suspend the log rule within the classifier group. Use the no version to remove the log rule from the classifier group.
41
mark
!
Use to set the ToS field in the IP header or the traffic-class field in the IPv6 header to a specified value for packets conforming to the current CLACL. For IPv4, you must specify one of the following:
! ! ! !
A ToS byte value in the range 0255 and a mask value in the range 1255 tos-precedence keyword and a value in the range 07 tos keyword and a value in the range 0255 dsfield keyword and a value in the range 063 A traffic-class byte in the range 0255 and a mask in the range 1255 tc-precedence keyword and a value in the range 07 tcfield keyword and a value in the range 0255 dsfield keyword and a value in the range 063
For IPv6, you must specify one of the following:

! ! ! !
Only one mask value is allowed per policy. Multiple mark rules are allowed with various mark values, but the mask for each of these rules must be the same. Example
host1(config-policy-list-classifier-group)#mark tos-precedence 3
! !
Use the suspend version to suspend the mark rule within the classifier group. Use the no version to remove the mark rule from the classifier group.
mark-de
!
Use to assign a value of 0 or 1 to the Frame Relay DE bit for packets conforming to the current CLACL. Example
host1(config-policy-list-classifier-group)#mark-de 1
Use the suspend version to suspend the mark DE rule within the classifier group. Use the no version to remove the mark DE rule from the classifier group.
mark-exp
!
Use to assign a value in the range 07 to the MPLS EXP field for packets conforming to the current CLACL. Example
host1(config-policy-list-classifier-group)#mark-exp 5
Use the suspend version to suspend the mark EXP rule within the classifier group. Use the no version to remove the mark EXP rule from the classifier group.
42
mark-user-priority
!
Use to assign a value in the range 07 to the 802.1p VLAN priority field for packets conforming to the current CLACL. Example
host1(config-policy-list-classifier-group)#mark-user-priority 5
Use the suspend version to suspend the mark-user-priority rule within the classifier group. Use the no version to remove the mark-user-priority rule from the classifier group.
next-hop
!
Use to define the IP address of the next hop to which the packets are forwarded for packets conforming to the current CLACL.
NOTE: The forward forward interface forward next-hop next-hop command is
replacing the next-hop command. The next-hop command may be removed in a future release. See the forward forward interface forward next-hop command for details. The SRP module Fast Ethernet port cannot be the destination of the next-hop command.
! !
For IP interfaces, this command is supported only on input policies. Example

host1(config-policy-list-classifier-group)#next-hop 10.10.10.1
Use the suspend version to suspend the next-hop rule within the classifier group. Use the no version to remove the next-hop rule from the classifier group.
next-interface
!
Use to define an output interface to which the packets conforming to the current CLACL are forwarded.
NOTE: The forward forward interface forward next-hop interface command is replacing the next-interface command. The next-interface command may be removed in a future release. See the forward forward interface forward next-hop command for details.
The SRP module Fast Ethernet port cannot be the destination of the next-interface command.
! !
For IP interfaces, this command is supported only on input policies. IP interfaces referenced with this command can be tracked if they move. Policies attached to an interface also move if the interface moves. However, statistics are not maintained across the move.
43
Example
host1(config-policy-list-classifier-group)#next-interface atm 0/0.1
Use the suspend version to suspend the next-interface rule within the classifier group. Use the no version to remove the next-interface rule from the classifier group.
rate-limit-profile
!
Use to specify a rate-limit rule for packets conforming to the current CLACL. See Rate Limiting Individual or Aggregate Packet Flows on page 58 for examples of using this command to rate limit traffic flows. Example
host1(config-policy-list-classifier-group)#rate-limit-profile tcpFriendly8MB
Use the suspend version to suspend the rate-limit-profile rule within the classifier group. Use the no version to remove the rate-limit-profile from the classifier group.
traffic-class
! !
Use to specify a traffic-class rule for packets conforming to the current CLACL. When this rule is applied to a packet, the packet will be associated with this traffic class within the router. Example
host1(config-policy-list-classifier-group)#traffic-class goldClass
Use the suspend version to temporarily suspend the traffic class within the classifier group. Use the no version to remove the traffic class from the classifier group.
user-packet-class
!
Use to add a user packet class rule that sets the use-packet-class attribute of packets that match the current CLACL. The user packet class is associated with every packet that is forwarded through the router. It is a value in the range 015 that the router initializes to zero when it receives the packet on an ingress interface. The value travels with the packet throughout the router until the packet is transmitted out an egress interface. You can modify the value by using this command and then classify packets based on the value. Example
host1(config-policy-list-classifier-group)#user-packet-class 3
Use the suspend version to temporarily suspend the rule within the classifier group. Use the no version to remove the user-packet-class rule from the classifier group.
44
Applying Policy Lists to Interfaces and Profiles

You can assign a policy list to supported interfaces and profiles. Policy lists are supported on Frame Relay, IP, IPv6, GRE tunnel, MPLS layer 2, and VLAN interfaces. You can also specify IP, IPv6, and L2TP policies in profiles to assign a policy list to an interface. In either case, you can enable or disable the recording of statistics for bytes and packets affected by the assigned policy.
NOTE: You can apply policies to MPLS topology-driven label-switched paths (LSPs) by using the mpls ldp lsp-policy command. See Policy Management and MPLS Topology-Driven LSPs on page 62.
Examples
To assign the policy list named routeForXYZCorp with statistics enabled to the ingress IP interface over an ATM subinterface:
host1(config)#interface atm 12/0.1 host1(config-subif)#ip policy input routeForXYZCorp statistics enabled
To create an L2TP profile that applies the policy list routeForABCCorp to the egress of an interface:
host1(config)#profile bostonProfile host1(config-profile)#l2tp policy output routeForABCCorp
frame-relay policy gre-tunnel policy ip policy ipv6 policy mpls policy l2tp policy vlan policy
!
Use to assign a Frame Relay, IP, IPv6, GRE tunnel, MPLS, or VLAN policy list to an interface. Also use to specify an IP, IPv6, or L2TP policy list to a profile, which then assigns the policy to the interfaces to which the profile is attached.
NOTE: The mpls policy command is used to attach policies to MPLS Layer 2 circuits only. NOTE: The SRP module Fast Ethernet port does not support policy attachments, nor can the module be the destination for the forward next-hop, forward next-interface, next-hop, and next-interface commands.
!
Use the input or output keyword to assign the policy list to the ingress or egress of the interface. For IP and IPv6 policy lists, use the secondary-input keyword to assign the policy list, after route lookup, to data destined to local or remote destinations. The router supports secondary input policies whose principal applications are:
!
To defeat denial-of-service attacks directed at a routers local IP or IPv6 stack
Applying Policy Lists to Interfaces and Profiles ! 45
! !
To protect a router from being overwhelmed by legitimate local traffic To apply policies on packets associated with the route class
NOTE: The local-input keyword for the ip policy and ipv6 policy commands is
deprecated, and may be completely removed in a future release. The keyword should be removed from scripts. You should recreate any local input policies using the ip classifier-list local true command and attaching the policies using the ip policy secondary-input command.
!
You can enable or disable the recording of routing statistics for bytes and packets affected by the policy. If you enable statistics, you can enable or disable baselining of the statistics. The router implements the baseline by reading and storing the statistics at the time the baseline is set and then subtracting this baseline whenever baseline-relative statistics are retrieved. You must also enable baselining on the interface with the appropriate baseline command.
NOTE: The gre-tunnel policy command does not support the baseline keyword.
Example 1
host1(config-if)#vlan policy input VlanPolicy33 statistics disabled
Example 2
host1(config-if)#ipv6 policy secondary-input my-policy
Use the no version to remove the association between a policy list and an interface or a profile.
Enabling IP Options Filtering

You can filter packets with IP options on an interface. When a packet arrives on an interface, the router checks to see if the packet contains IP options. If it does and if IP options filtering is enabled, that packet is dropped. IP options filtering is disabled by default. ip filter-options all
! !
Use to enable filtering of packets with IP options. Example

host1(config-if)#ip filter-options all
Use the no version to disable filtering of packets with IP options.
46
Enabling IP Options Filtering
Using RADIUS to Create and Apply Policies

The E-series router enables you to use RADIUS to create and apply policies on IP interfaces. This feature supports the Ascend-Data-Filter attribute [242] through a RADIUS VSA that specifies a hexadecimal field. The hexadecimal field is encoded with policy attachment, classification, and policy action information. The policy defined in the Ascend-Data-Filter attribute is applied when RADIUS receives a client authorization request and replies with an Access-Accept message. When you use RADIUS to apply policies, a subset of the routers classification fields and actions is supported. The supported actions and classification fields are:
!
Actions
! ! ! ! !
Filter Forward Packet marking Rate limit Traffic class
Classifiers
! ! ! ! !
Destination address Destination port Protocol Source address Source port
NOTE: The E-series router dynamically assigns names to the new classifier list and policy list based on information such as the interface and direction of the policy.
To create a policy, you use hexadecimal format to configure the Ascend-Data-Filter attribute on the RADIUS server. For example:
Ascend-Data-Filter="01000100 0A020100 00000000 18000000 00000000 00000000"
47
Table 10 shows the fields in the order in which they are specified in the hexadecimal Ascend-Data-Filter attribute.
Table 10: Ascend-Data-Filter Policy Format Action or Classifier
Type Filter or forward Indirection Spare Source IP address Destination IP address Source IP prefix Destination IP prefix Protocol Established Source port Destination port Source port qualifier
Format
1 byte 1 byte 1 byte 1 byte 4 bytes 4 bytes 1 byte 1 byte 1 byte 1 byte 2 bytes 2 bytes 1 byte
Comments
0 = generic 1 = IP 0 = filter 1 = forward 0 = egress 1 = ingress Count of leading zeros in wildcard mask Count of leading zeros in wildcard mask Not implemented 0 = no compare 1 = less than 2 = equal to 3 = greater than 4 = not equal to 0 = no compare 1 = less than 2 = equal to 3 = greater than 4 = not equal to 0 = no packet marking
! 0 = no traffic class (required if there is no
Destination port qualifier
1 byte
Reserved Marking value Marking mask Traffic class
2 bytes 1 byte 1 byte 141 bytes
profile)
! First byte specifies the length of the ASCII string,
followed by the ASCII name of the traffic class

! Traffic class must be statically configured ! Name can optionally be null terminated, which
consumes 1 byte Rate-limit profile 141 bytes

! 0 = no rate limit (required if there is no profile) ! First byte specifies the length of the ASCII string,
followed by the ASCII name of the profile

! Profile must be statically configured ! Name can optionally be null terminated, which
consumes 1 byte
48
NOTE: To create a rate-limit profile, traffic class, or marking rule, you must first configure the filter/forward field as forward.
A single RADIUS record can contain two policiesone ingress policy and one egress policy. Each policy can have a maximum of 512 ascend-data filters. Each ascend data-filter creates a classifier group and the action associated with the classifier group.
ExamplesUsing the Ascend-Data-Filter Attribute

This section provides examples showing the configuration of policies that use the Ascend-Data-Filter attribute.
Example 1
In this example, the following Ascend-Data-Filter attribute creates a RADIUS record that configures an input policy. The policy filters all packets from network 10.2.1.0 with wildcard mask 0.0.0.255 to any destination. The values specified in the Ascend-Data-Filter attribute are shown in Table 11.
Ascend-Data-Filter="01000100 0A020100 00000000 18000000 00000000 00000000"
Table 11: Ascend-Data-Filter Example 1 Values Action or Classifier

Type Forward Indirection Spare Source IP address Destination IP address Source IP mask Destination IP mask Protocol Established Source port Destination port Source port qualifier Destination port qualifier Reserved
Hex Value
01 00 01 00 0a020100 00000000 18 00 00 00 0000 0000 00 00 0000
Actual Value
IP Forward Ingress None 10.2.1.0 Any 24 (0.0.0.255) 0 (255.255.255.255) None None None None None None None
Use the show classifier-list and show policy-list commands to view information about the policy:
host1#show classifier-list Classifier Control List Table ---------- ------- ---- ----IP clin_5_00.1 ip 10.2.1.0 0.0.0.255 any
49
host1#show policy-list Policy Table ------ ----IP Policy plin_5 Administrative state: enable Reference count: 1 Classifier control list: clin_5_00, precedence 100 filter Referenced by interface(s): ATM4/0.0 input policy, statistics enabled, virtual-router default Referenced by profile(s): No profile references
Example 2
In this example, the Ascend-Data-Filter attribute is used to create RADIUS records that configure two policies. The first policy is an input policy that filters all TCP packets that come from a port greater than 9000 on host 10.2.1.1 and that go to any destination. The second policy is an output policy that filters all UDP packets from network 20.1.0.0 to host 10.2.1.1, port 3090.
Ascend-Data-Filter = "01000100 0A020101 00000000 20000600 23280000 03000000" Ascend-Data-Filter = "01000000 14010000 0A020101 10201100 00000C12 00020000"
Using the show classifier-list and show policy-list commands produces the following information about the new policies:
host1#show classifier-list Classifier Control List Table ---------- ------- ---- ----IP clin_6.1 tcp 10.2.1.1 gt 9000 any IP clout_6.1 udp 20.1.0.0 0.0.255.255 10.2.1.1 eq 3090 host1#show policy-list Policy Table ------ ----IP Policy plin_6 Administrative state: enable Reference count: 1 Classifier control list: clin_6_00, precedence 100 filter Referenced by interface(s): ATM4/0.0 input policy, statistics enabled, virtual-router default Referenced by profile(s): No profile references IP Policy plout_6 Administrative state: enable Reference count: 1 Classifier control list: clout_6_01, precedence 100 filter Referenced by interface(s): ATM4/0.0 output policy, statistics enabled, virtual-router default Referenced by profile(s): No profile references
50
Example 3
This example creates an input policy and an output policy, each with multiple rules. The rules for the two policies are shown in the following list:
!
Input policy rules

!
Forward all TCP packets from host 10.2.1.1 to destination 20.0.0.0 0.255.255.255. Filter all TCP packets from host 10.2.1.1 to any destination. Forward all packets from host 10.2.1.1 to any destination. Filter all other traffic.
! ! !
The rules for the input policy translate to the following VSAs. The VSAs must be specified in this order:
Ascend-Data-Filter Ascend-Data-Filter Ascend-Data-Filter Ascend-Data-Filter ! = = = = "01010100 "01000100 "01010100 "01000100 0A020101 0A020101 0A020101 00000000 14000000 00000000 00000000 00000000 20080600 20000600 20000000 00000000 00000000 00000000 00000000 00000000 00000000" 00000000" 00000000" 00000000"
Output policy rules

! ! ! !
Forward all TCP packets from 20.0.0.0 0.255.255.255 to host 10.2.1.1. Filter all TCP packets from any source to host 10.2.1.1. Forward all packets from any source to host 10.2.1.1. Filter all other traffic.
The rules for the input policy translate to the following VSAs. The VSAs must be specified in this order:
Ascend-Data-Filter Ascend-Data-Filter Ascend-Data-Filter Ascend-Data-Filter = = = = "01010000 "01000000 "01010000 "01000000 14000000 00000000 00000000 00000000 0A020101 0A020101 0A020101 00000000 08200600 00200600 00200000 00000000 00000000 00000000 00000000 00000000 00000000" 00000000" 00000000" 00000000"
Using the show classifier-list and show policy-list commands produces the following information about the new policies:
host1:vr0#show classifier-list Classifier Control List Table ---------- ------- ---- ----clin_7_00.1 tcp host 10.2.1.1 20.0.0.0 0.255.255.255 clin_7_01.1 tcp host 10.2.1.1 any clin_7_02.1 ip host 10.2.1.1 any clout_7_04.1 tcp 20.0.0.0 0.255.255.255 host 10.2.1.1 clout_7_05.1 tcp any host 10.2.1.1 clout_7_06.1 ip any host 10.2.1.1
IP IP IP IP IP IP
51
host1:vr0#show policy-list Policy Table ------ ----IP Policy plin_7 Administrative state: enable Reference count: 1 Classifier control list: clin_7_00, precedence 100 forward Classifier control list: clin_7_01, precedence 100 filter Classifier control list: clin_7_02, precedence 100 forward Classifier control list: *, precedence 100 filter Referenced by interface(s): ATM4/0.0 input policy, statistics enabled, virtual-router default Referenced by profile(s): No profile references IP Policy plout_7 Administrative state: enable Reference count: 1 Classifier control list: clout_7_04, precedence 100 forward Classifier control list: clout_7_05, precedence 100 filter Classifier control list: clout_7_06, precedence 100 forward Classifier control list: *, precedence 100 filter Referenced by interface(s): ATM4/0.0 output policy, statistics enabled, virtual-router default Referenced by profile(s): No profile references
Example 4
In this example, the following Ascend-Data-Filter attribute creates a RADIUS record that configures an input policy. The policy filters TCP packets from host address 10.2.1.2 to any destination. The policy marks the packets with a ToS byte of 5 and a mask of 170. The policy also applies a traffic class named someTcl and a rate-limit profile named someRlp. The values specified in the Ascend-Data-Filter attribute are shown in Table 12.
Ascend-Data-Filter="01010100 0a020102 00000000 20000600 045708ae 02010000 05aa0773 6f6d6554 636c0773 6f6d6552 6c70"
Table 12: Ascend-Data-Filter Example 4 Values Action or Classifier

Type Forward Indirection Spare Source IP address
Hex Value
01 01 01 00 0a020102
Actual Value
IP Filter Ingress None 10.2.1.2
52
Table 12: Ascend-Data-Filter Example 4 Values (continued) Action or Classifier

Destination IP address Source IP mask Destination IP mask Protocol Established Source port Destination port Source port qualifier Destination port qualifier Reserved Marking value Marking mask Traffic class Rate-limit profile
Hex Value
00000000 20 00 06 00 0000 0000 00 00 0000 05 aa 0773 6f6d6554 636c 0773 6f6d6552 6c70
Actual Value
Any 32 (0.0.0.0) 0 (255.255.255.255) TCP None None None None None None 5 170 someTcl someRlp
Use the show classifier-list and show policy-list commands to view information about the policy:
host1#show classifier-list Classifier Control List Table ---------- ------- ---- ----IP clin_8_00.1 tcp host 10.2.1.2 host1#show policy-list Policy Table ------ ----IP Policy plin_8 Administrative state: enable Reference count: 1 Classifier control list: clin_8_00, precedence 100 mark 5 mask 170 traffic-class someTcl rate-limit-profile someRlp Referenced by interface(s): ATM11/0.0 input policy, statistics enabled, virtual-router default Referenced by profile(s): No profile references
53
Policy Applications
The following sections describe several practical applications of policy management.
Policy Routing
Policy routing allows the router to classify a packet on ingress and make a forwarding decision based on that classification, without performing the normal routing table processing. This feature provides superior performance for real-time applications. For IP policy lists, policy rules are available to allow you to make a forwarding decision that includes the next interface and next hop:
!
Forward next interfaceCauses an interface to forward all packets that satisfy the classification associated with that rule to the next interface specified Forward next hopCauses an interface to forward all packets that satisfy the classification associated with that rule to the next-hop address specified
For example, you can route packets arriving at IP interface ATM 0/0.0 so that they area handled as indicated:
! ! !
Packets from source 1.1.1.1 are forwarded out of interface ATM 0/0.1. Packets from source 2.2.2.2 are forwarded out of interface ATM 2/1.1. All other packets are dropped.
To configure this routing policy, issue the following commands:

host1(config)#ip classifier-list claclA ip host 1.1.1.1 any host1(config)#ip classifier-list claclB ip host 2.2.2.2 any host1(config)#ip policy-list IpPolicy100 host1(config-policy-list)#classifier-group claclA host1(config-policy-list-classifier-group)#forward interface atm 0/0.1 host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group claclB host1(config-policy-list-classifier-group)#forward interface atm 2/1.1 host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#filter host1(config-policy-list-classifier-group)#exit host1(config)#interface atm 0/0.0 host1(config-subif)#ip policy input IpPolicy100 statistics enabled
54
Policy Applications
Security
You can configure policy management to provide a level of network security by using policy rules that selectively forward or filter packet flows:
!
ForwardCauses the packet flows that satisfy the classification associated with the rule to be routed by the virtual router FilterCauses the interface to drop all packets of the packet flow that satisfy the classification associated with the rule
To stop a denial-of-service attack, you can use a policy with a filter rule. You need to construct the classifier list associated with the filter rule so that it isolates the attackers traffic into a flow. You should determine the criteria for this classifier list by analyzing the traffic received on an interface. Packet Flow Monitoring on page 60, describes how to capture packets into a log. For example, you can route packets entering an IP interface (ATM 0/0.0) so that they are handled as indicated:
! !
Packets from source 1.1.1.1 are routed. TCP packets from source 2.2.2.2 with the IP fragmentation offset set to one are dropped. All other TCP packets are routed. All other packets are dropped.
! !
To configure this policy, issue the following commands:

host1(config)#ip classifier-list claclA ip host 1.1.1.1 any host1(config)#ip classifier-list claclB tcp host 2.2.2.2 any ip-frag-offset eq 1 host1(config)#ip classifier-list claclC tcp any any host1(config)#ip policy-list IpPolicy100 host1(config-policy-list)#classifier-group claclA host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group claclB host1(config-policy-list-classifier-group)#filter host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group claclC host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#filter host1(config-policy-list-classifier-group)#exit host1(config)#interface atm 0/0.0 host1(config-subif)#ip policy input IpPolicy100 statistics enabled
Policy Applications
55
Bandwidth Management
To enforce ingress data rates below the physical line rate of a port, you can rate limit a classified packet flow at ingress. A rate-limit profile with a policy rate-limit profile rule provides this capability. The rate-limit profile defines the attributes of the desired rate. You can set an action based on one rate or two rates. These actions include drop, transmit, or mark. The default is to transmit committed and conformed packets, and to drop exceeded packets. A color-coded tag is added automatically to each packet based on the following categories:
! ! !
The queuing system uses drop eligibility to select packets for dropping when there is congestion on an egress interface. This method is called dynamic color-based threshold dropping. Each packet queue has two color-based thresholds as well as a queue limit:
!
Red packets are dropped when congestion causes the queue to fill above the red threshold. Yellow packets are dropped when the yellow threshold is reached. Green packets are dropped when the queue limit is reached.
! !
Figure 2 illustrates congestion management.

Figure 2: Congestion Management
Queue
Queue limit
Yellow drop threshold
Red drop threshold
56
Policy Applications
g013024
One-Rate Rate-Limit Profile

A one-rate rate-limit profile can be configured for hard tail drop rate-limit or TCP-friendly behavior. Packets can be categorized as committed, conformed, or exceeded.
Example 1
You can configure a one-rate rate-limit profile to hard limit a packet flow to a specified rate. To rate limit the traffic on an interface from source IP address 1.1.1.1 to 1 Mbps, issue the following commands:
host1#configure terminal host1(config)#ip rate-limit-profile oneMegRlp one-rate host1(config-rate-limit-profile)#committed-rate 1000000 host1(config-rate-limit-profile)#exit host1(config)#ip classifier-list claclA ip host 1.1.1.1 any host1(config)#ip policy-list testPolicy host1(config-policy-list)#classifier-group claclA host1(config-policy-list-classifier-group)#rate-limit-profile oneMegRlp host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit host1(config)#interface atm 0/0.0 host1(config-subif)#ip policy input testPolicy statistics enabled
Example 2
You can also configure a one-rate rate-limit profile to provide a TCP-friendly rate limiter. To configure a rate limiter with TCP-friendly characteristics, we recommend that you set the committed burst to allow for 1 second of data at the specified rate, and the excess burst to allow 1.5 seconds of data at the specified committed rate plus the committed burst. For example:
host1(config)#ip rate-limit-profile tcpFriendly8MB one-rate host1(config-rate-limit-profile)#committed-rate 8000000 host1(config-rate-limit-profile)#committed-burst 1000000 host1(config-rate-limit-profile)#excess-burst 2500000 host1(config-rate-limit-profile)#committed-action transmit host1(config-rate-limit-profile)#exceeded-action drop
Two-Rate Rate-Limit Profile

You can configure a two-rate rate-limit profile for two different rates, committed and peak, that are used to define a two-rate, three-color marking mechanism. You can categorize packets as committed, conformed, or exceeded:
! ! !
Up to the committed rate, packets are considered to be committed. From the committed to peak rate, packets are considered to be conformed. After the peak rate, packets are considered to be exceeded.
This configuration is implemented with token buckets. See RFC 2698 for more details.
Policy Applications
57
Example
The following example rate limits traffic on an interface from source IP address 1.1.1.1 so that traffic at a rate up to 1 Mbps is colored green and transmitted, traffic at a rate from 1 Mbps to 2 Mbps is colored yellow and transmitted, and traffic at a rate above 2 Mbps is dropped.
host1(config)#ip rate-limit-profile 1MbRLP host1(config-rate-limit-profile)#committed-rate 1000000 host1(config-rate-limit-profile)#peak-rate 2000000 host1(config-rate-limit-profile)#committed-action transmit host1(config-rate-limit-profile)#conformed-action transmit host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#exit host1(config)#ip classifier-list claclA ip host 1.1.1.1 any host1(config)#ip policy-list testPolicy host1(config-policy-list)#classifier-group claclA host1(config-policy-list-classifier-group)#rate-limit-profile 1MbRLP host1(config-policy-list-classifier-grouip)#exit host1(config-policy-list)#exit host1(config)#interface atm 0/0.0 host1(config-subif)#ip policy input testPolicy statistics enabled
Rate Limiting Individual or Aggregate Packet Flows

You can construct policies to provide rate limiting for individual packet flows or for the aggregate of multiple packet flows. For example, if you have traffic from multiple sources, you can either rate limit each traffic flow individually, or you can rate limit the aggregate flow for the traffic from all sources.
!
To rate limit individual packet flows, use a separate classifier list to classify each flow. See Example 1: Individual Packet Flows. To rate limit the aggregate of multiple traffic flows, use a single classifier list for the multiple entries. See Example 2: Multiple Traffic Flows.
Example 1: Individual Packet Flows
In the following example, interface ATM 3/1.1 classifies on three traffic flows from different sources. Each traffic flow is rate limited to 1MB (which is defined by the rate-limit profile rl1Meg).
host1(config)#classifier-list clFlow1 ip host 10.1.1.1 any host1(config)#classifier-list clFlow2 ip host 10.1.1.2 any host1(config)#classifier-list clFlow3 ip host 10.1.1.3 any host1(config)#policy-list plRateLimit host1(config-policy-list)#classifier-group clFlow1 host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meg host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group clFlow2 host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meg host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group clFlow3 host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meg host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit host1(config)#interface atm 3/1.1 host1(config-subif)#ip policy input plRateLimit statistics enabled
58
Policy Applications
host1(config-subif)#exit host1(config)#
Example 2: Multiple Traffic Flows
In the following example, interface ATM 3/1.1 again classifies on three traffic flows; however, this policy rate limits the aggregate of the three flows to 1MB.
host1(config)#classifier-list clFlowAll ip host 10.1.1.1 any host1(config)#classifier-list clFlowAll ip host 10.1.1.2 any host1(config)#classifier-list clFlowAll ip host 10.1.1.3 any host1(config)#policy-list plRateLimit host1(config-policy-list)#classifier-group clFlowAll host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit host1(config)#interface atm 3/1.1 host1(config-subif)#ip policy input plRateLimit statistics enabled host1(config-subif)#exit host1(config)#
Packet Tagging
You can use the traffic-class rule in policies to tag a packet flow so that the QoS application can provide traffic-class queuing. Policies can perform both in-band and out-of-band packet tagging:
!
Policies perform in-band tagging by using their respective mark rule to modify a packet header field. For example, IP policies use the mark rule to modify an IP packet heard ToS field, and Frame Relay policies use the mark-de rule to modify the DE bit. Policies perform out-of-band tagging by using the traffic class or color rule. Explicit packet coloring lets you configure prioritized packet flows without having to configure a rate-limit profile. The router uses the color to queue packets for egress queue threshold dropping as described in Bandwidth Management on page 56.
Example
Suppose an Internet service provider (ISP) provides a Broadband Remote Access Server (B-RAS) service that has both video and data components, and the ISP wants to guarantee that the video traffic gets priority treatment relative to the data traffic. The ISPs users have a 1.5 Mbps virtual circuit (VC) terminating on a digital subscriber line access multiplexer (DSLAM). The ISP wants to allocate 800 Kbps of this link for video, if there is a video stream. The ISP creates a classifier list to define a video packet flow, creates a policy to color the packets, and applies the policy to the interface:
host1(config)#ip classifier-list video ip any any dsfield 16 host1(config)#ip classifier-list data ip any any dsfield 32 host1(config)#ip policy-list colorVideoGreen host1(config-policy-list)#classifier-group video host1(config-policy-list-classifier-group)#color green host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group data host1(config-policy-list-classifier-group)#color yellow host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit
Policy Applications
59
host1(config)#interface atm 12/1.1 host1(config-if)#ip policy input colorVideoGreen statistics enabled
Packet Flow Monitoring

The policy log rule provides a way to monitor a packet flow by capturing a sample of the packets that satisfy the classification of the rule in the system log. See JUNOSe System Basics Configuration Guide, Chapter 13, Logging System Events for information about logging. To capture the interface, protocol, source address, destination address, source port, and destination port, set the policyMgrPacketLog event category to log at severity info and at low verbosity. To capture the version, ToS, len ID, flags, time to live (TTL), protocol, and checksum in addition to the information captured at low verbosity, set the verbosity to medium or high. When the policy is configured, all packets are examined and the matching packets are placed in the log. No more than 512 packets will be logged every three seconds. The router maintains a count of the total number of matching packets. This count is incremented even if the packet cannot be stored in the log (for example, because the count exceeds the 512-packet threshold).
Example 1: Logging Ingress Packets on an Interface
This example shows how you might use classification to specify the ingress packets that are logged on an interface.
host1(config)#ip policy-list testPolicy host1(config-policy-list)#classifier-group logA host1(config-policy-list-classifier-group)#log host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit host1(config)#interface atm 0/0.0 host1(config-subif)#ip policy input testPolicy statistics enabled host1(config-subif)#exit host1(config)#log destination console severity info host1(config)#log severity info policyMgrPacketLog host1(config)#log verbosity low policyMgrPacketLog host1(config)#log here
Example 2: Logging a Ping Attack
This example provides a more detailed procedure that an ISP might use to log information during a ping attack on the network. The procedure includes the creation of the classifier and policy lists to specify the desired packet flow to monitor, the logging of the output of the classification operation, and the output of the show command. In this example, a customer has reported to their ISP that an attack is occurring on their internal servers. The attack is a simple ping flood. 1. The ISP creates a classifier list to define an ICMP echo request packet flow.
host1:vr2(config)#classifier-list icmpEchoReq icmp any any 8 0 host1:vr2(config)#policy-list pingAttack host1:vr2(config-policy-list)#classifier-group icmpEchoReq host1:vr2(config-policy-list-classifier-group)#log host1:vr2(config-policy-list-classifier-group)#exit host1:vr2(config-policy-list)#exit
60
Policy Applications
host1:vr2(config)#interface gigabitEthernet 2/0 host1:vr2(config-if)#ip address 10.10.10.2 255.255.255.0 host1:vr2(config-if)#exit host1:vr2(config)#virtual-router vr1 host1:vr1(config)#interface gigabitEthernet 0/0 host1:vr1(config-if)#ip address 10.10.10.1 255.255.255.0 host1:vr1(config-if)#ip policy input pingAttack statistics enabled host1:vr1(config-if)#exit host1:vr1(config)#exit
2. The ISP configures standard logging on the E-series router.

host1(config)#log destination console severity info host1(config)#log severity info policyMgrPacketLog host1(config)#log here INFO 12/16/2003 12:59:47 policyMgrPacketLog (): icmpEchoReq icmp GigabitEthernet0/0 10.10.10.2 10.10.10.1 forwarded INFO 12/16/2003 12:59:47 policyMgrPacketLog (): icmpEchoReq GigabitEthernet0/0 number of hits = 21551 INFO 12/16/2003 12:59:50 policyMgrPacketLog (): icmpEchoReq icmp GigabitEthernet0/0 10.10.10.2 10.10.10.1 forwarded INFO 12/16/2003 12:59:50 policyMgrPacketLog (): icmpEchoReq GigabitEthernet0/0 number of hits = 21851 INFO 12/16/2003 12:59:53 policyMgrPacketLog (): icmpEchoReq icmp GigabitEthernet0/0 10.10.10.2 10.10.10.1 forwarded INFO 12/16/2003 12:59:53 policyMgrPacketLog (): icmpEchoReq GigabitEthernet0/0 number of hits = 22151
3. The ISP displays statistics for the interface.

host1:vr1#show ip interface gigabitEthernet 0/0 GigabitEthernet0/0 line protocol Ethernet is up, ip is up Network Protocols: IP Internet address is 10.10.10.1/255.255.255.0 Broadcast address is 255.255.255.255 Operational MTU = 1500 Administrative MTU = 0 Operational speed = 1000000000 Administrative speed = 0 Discontinuity Time = 1092358 Router advertisement = disabled Proxy Arp = enabled Network Address Translation is disabled Administrative debounce-time = disabled Operational debounce-time = disabled Access routing = disabled Multipath mode = hashed Auto Configure = disabled Auto Detect = disabled Inactivity Timer = disabled In Received Packets 488421, Bytes 62517888 Unicast Packets 488421, Bytes 62517888 Multicast Packets 0, Bytes 0 In Policed Packets 0, Bytes 0 In Error Packets 0 In Invalid Source Address Packets 0 In Discarded Packets 0 Out Forwarded Packets 486152, Bytes 62232048
Policy Applications
61
Unicast Packets 486152, Bytes 62232048 Multicast Routed Packets 0, Bytes 0 Out Scheduler Dropped Packets 0, Bytes 0 Out Policed Packets 0, Bytes 0 Out Discarded Packets 2269 IP policy input pingAttack classifier-group icmpEchoReq entry 1 488421 packets, 69355782 bytes log queue 0: traffic class best-effort, bound to ip GigabitEthernet0/0 Queue length 0 bytes Forwarded packets 485988, bytes 70954248 Dropped committed packets 0, bytes 0 Dropped conformed packets 0, bytes 0 Dropped exceeded packets 0, bytes 0
Policy Management and MPLS Topology-Driven LSPs

Most policy management for MPLS is handled automatically by MPLS. However, in the case of both statically configured and signaled mapping between EXP bits and per-hop behavior (PHB), you must manually configure certain policy features for topology-driven LSPs only. See JUNOSe Routing Protocols Configuration Guide, Vol. 2, Chapter 2, Configuring MPLS for more information about and application of this feature.
NOTE: You apply policies to MPLS layer 2 interfaces by using the mpls policy command. See Applying Policy Lists to Interfaces and Profiles on page 45.
Statically Configured Mapping

You can specify a policy to be attached to all topology-driven LSPs in a VR. The policy is automatically attached when the LSP is created if the destination matches the access list. mpls ldp lsp-policy
!
Use to specify a policy that is automatically attached to all topology-driven LSPs in a VR when the LSP is created, if the destination matches the access list. Use the input keyword to have the policy applied to the incoming LSP (for which a label was advertised) to match on the EXP bits of incoming packets. Use the output keyword to have the policy applied to the outgoing LSP (for which a label was received) to set the EXP bits of outgoing packets. Example
host1(config)#mpls ldp lsp-policy input ingold access-list xyzcorp
Use the no version to halt the attachment of the policy to subsequently created topology-driven LSPs.
62
Policy Management and MPLS Topology-Driven LSPs
Signaled Mapping
For signaled mapping between EXP bits and PHB, policies apply the EXP bits matching and setting on a per-LSP basis rather than a per-VR basis. For a topology-driven LSP, you must manually create the policies and specify the association between policies and LSPs. mpls classifier-list
!
Use to create or modify an MPLS classifier control list to match on traffic class/color combination or EXP bits. Example
host1(config)#mpls classifier-list be-green traffic-class best-effort color yellow
Use the no version to remove the classifier control list from the LSP.
mpls ldp lsp-policy

!
Use to specify a policy that is automatically attached to the topology-driven LSP when the LSP is created, if the destination matches on the access list. Use the input version to have the policy applied to the incoming LSP (for which a label was advertised) to match on the EXP bits of incoming packets. Use the output keyword to have the policy applied to the outgoing LSP (for which a label was received) to set the EXP bits of outgoing packets. Example
host1(config)#mpls ldp lsp-policy input ingold access-list xyzcorp
Use the no version to halt the attachment of the policy to subsequently created topology-driven LSPs.
Policy Resources
The maximum number of policies that you can attach to interfaces on the E-series router depends on the classifier entries that make up the policy. The E-series router supports software and hardware classifiers. A policy can be made up of any combination of software and hardware classifiers. You use the classifier-list command to configure all classifiers. There are two categories of hardware classifiers, depending on the type of line module being used. OC48/STM16 and GE-2 line modules support content-addressable memory (CAM) hardware classifiersall other line modules support FPGA hardware classifiers. Table 13 lists the classifiers supported on OC48/STM16 and GE-2 line modules; Table 14 lists the classifiers supported on all other line modules.
Policy Resources
63
Table 13: Classifier Support (OC48/STM16 and GE-2 Line Modules) Interface Type
All interface types (except IP and IPv6)
Hardware Classifier
Software Classifier
Frame Relay GRE tunnels IP
Not supported Not supported

! Color ! Destination address ! Destination port ! Destination route class ! ICMP type and code ! IGMP type ! IP flags ! IP fragmentation ! Local ! Protocol ! Source address ! Source port ! Source route class ! TCP flags ! ToS ! Traffic class ! User packet class !
! DE bit ! ToS
Not supported
IPv6 MPLS VLAN
Not supported Not supported Not supported
Not supported
! EXP ! User priority
64
Policy Resources
Table 14: Classifier Support (All Line Modules Except OC48/STM16 and GE-2) Interface Type
All interface types
Hardware Classifier
Software Classifier
Frame Relay GRE tunnels IP

! Destination address ! Destination port ! ICMP type and code ! IGMP type ! Protocol ! Source address ! Source port
! DE bit ! ToS ! Destination route class ! IP flags ! IP fragmentation ! Local ! Source route class ! TCP flags ! ToS ! Destination route class ! Local ! Source route class ! TC field ! TCP flags ! EXP ! User priority
IPv6
! Destination address ! Destination port ! Protocol ! Source address ! Source port
MPLS VLAN
FPGA Hardware Classifiers

FPGA hardware classifiers are supported on all line modules except the OC48/STM16 and GE-2 line modules. Table 14 lists the FPGA classifiers and software classifiers supported for each interface type. The E-series router supports two versions of policies that are based on FPGA hardware classifiers. One version has a maximum of 16 classifier entries per policy, and the second version has 16 to 32 classifier entries per policy. The line module supports 16,255 policies when all policies have 16 hardware classifier entries or fewer, and supports 8127 policies if all policies have 16 to 32 hardware classifier entries. The router allows you to configure a combination of the two versions of FPGA hardware classifier-based policiesyou can have some that contain 16 or fewer classifier entries and others with more than 16 entries. In this case, the number of policies that is supported will be between 8127 and 16,255, depending on the actual configuration.
Policy Resources
65
You can also configure hardware classifier-based policies that have more than 32 classifier entries. The router groups the classifiers into blocks of 32. For example, if you configure a policy with 100 classifier entries, the router views this as three policies that have 32 classifier entries and one policy with 4 classifier entries. Note that the group with 4 classifier entries actually consumes 16 classifier resources, which is the minimum number consumed for a group in a mixed-mode hardware classifier configuration. Unlike policies that are based on software classifiers, policies that are based on FPGA hardware classifiers consume resources at a rate of one resource per policy, regardless of the number of different hardware classifier categories in the policy. For example, if a classifier list has three hardware classifiers, such as destination address, source address, and protocol, the policy referencing that classifier list would consume only a single hardware classifier resource. The same is true if multiple policy rules reference the classifier list. For example, if four policy rules reference the same classifier list (which contains three hardware classifiers), then still only one classifier entry would be consumed.
CAM Hardware Classifiers

CAM hardware classifiers are supported on the OC48/STM16 and GE-2 line modules. Table 13 lists CAM hardware classifiers and the software classifiers supported for each interface type. The OC48/STM16 line module supports 128,000 CAM entries, and the GE-2 line module supports 64,000 CAM entries. For most configurations, each classifier entry in a policy consumes one CAM entry. However, a policy that has only the default classifier consumes no CAM resources.
Example
In this example, the policy consumes a total of four CAM entries: two entries for clacl1, one for clacl2, and one for the default classifier.
host1(config)#ip classifier-list clacl1 ip host 192.168.1.1 host 192.168.2.2 tos 1 host1(config)#ip classifier-list clacl1 ip host 192.168.1.1 host 192.168.2.2 tos 2 host1(config)#ip classifier-list clacl2 tcp any any tcp-flags "SYN" host1(config)#ip policy-list policy1 host1(config-policy-list)#classifier-group clacl1 host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group clacl2 host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#filter host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit host1(config)#
66
Policy Resources
There are two exceptions in which a single classifier entry will consume more than one CAM entry. In these cases, the actual number of entries that are consumed depends on the configuration. The two exceptions are: 1. When a classifier entry contains a port range. For example:
host1(config)#ip classifier-list clacl3 tcp any any range 5 8
2. When a classifier entry contains the not keyword. Although this keyword is supported for IP classifier lists, it is recommended that you not use ityou can usually achieve the desired behavior without this field.
host1(config)#ip classifier-list clacl4 ip not host 1.1.1.1 any
Software Classifiers
The E-series router supports a variety of software classifiers, depending on the type of interface. Table 13 and Table 14 list the supported software classifiers for each interface type. A line module supports 16,383 software classifiers. Software classifiers are consumed at a rate of one resource per classifier category per policy. For example, if you configure a policy that has three different destination route class rules, then because all three rules are for the same classifier category, that policy would consume only one software classifier resource. However, if you configure a policy that requires classification on three different classifier categories, such as ToS, color, and TCP flags, then that policy would consume three of the available 16,383 software classifier resources.
NOTE: Policy consumption is per policy definition per line card.
Example
In this example, the policy list named polWestford5 references four classifier lists with a combination of software and hardware classifiers:
host1(config)#classifier-list clacl100 color red ip any any host1(config)#classifier-list clacl200 color yellow user-packet-class 6 ip host 10.1.1.1 host 10.1.1.2 host1(config)#classifier-list clacl300 color green user-packet-class 5 ip any any host1(config)#classifier-list clacl400 color red ip host 10.1.1.10 any host1(config)#policy-list polWestford5 host1(config-policy-list)#classifier-group clacl100 host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group clacl200 host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group clacl300 host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group clacl400 host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#filter
Policy Resources
!
67
host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit
For a given line module, the policy list named polWestford5 consumes a total of one FPGA hardware classifier resource and two software classifier resources, as shown in Table 15.
Table 15: Resource Consumption Number of Resources Consumed
1 hardware
Classifier Category
! Protocol ! Destination address ! Source address
1 software 1 software
Color User-packet-class
Monitoring Policy Management

This section shows how to set a statistics baseline and use the show command to view your policy configuration and monitor policy statistics.
Setting a Statistics Baseline

You can set a baseline for policy statistics by using the baseline interface command and the frame-relay policy, ip policy, ipv6 policy, l2tp policy, mpls policy, and vlan policy commands. If you do not enable baselining, show command output fields for baseline counters display the contents of the regular statistics counters. When you set baseline statistics, you can retrieve statistics beginning at the time when the baselining is set. To enable a baseline for the statistics for the attachment of the policy list named routeForXYZCorp with statistics enabled to the ingress of an interface, use the following commands:
host1(config)#interface atm 12/0.1 host1(config-subif)#ip policy input routeForXYZCorp statistics enabled baseline enabled
To show baseline counters, run the show ip interface command with the delta keyword:
host1#show ip interface atm 12/0.1 delta atm12/0.1 is up, line protocol is up Network Protocols: IP Internet address is 200.200.1.1/255.255.255.0 Broadcast address is 255.255.255.255 Operational MTU = 9180 Administrative MTU = 0 Operational speed = 155520000 Administrative speed = 0 Discontinuity Time = 1251181 Router advertisement = disabled Administrative debounce-time = disabled
68
Operational debounce-time Access routing = disabled Multipath mode = hashed
= disabled
In Received Packets 5, Bytes 540 In Policed Packets 0, Bytes 0 In Error Packets 0 In Invalid Source Address Packets 0 In Discarded Packets 0 Out Forwarded Packets 5, Bytes 540 Out Scheduler Drops Packets 0, Bytes 0 Out Policed Packets 5, Bytes 540 Out Discarded Packets 0 IP Policy input routeForXYZCorp classifier-group * filter 5 Packets 540 Bytes dropped
Policy Management show Commands

Use the following show commands to display statistics for policy lists:
! ! ! ! ! ! ! ! ! ! ! !
show classifier-list show frame-relay subinterface show gre-tunnel show interfaces show ip interface show ipv6 interface show l2tp tunnel show mpls interface show policy-list show rate-limit-profile show secure policy-list show vlan subinterface
You can use the output filtering feature of the show command to include or exclude lines of output based on a text string you specify. See JUNOSe System Basics Configuration Guide, Chapter 2, Command-Line Interface for details.
69
frame-relay policy ip policy ipv6 policy mpls policy l2tp policy vlan policy
!
Use to assign a policy list to an interface and enable or disable the recording of routing statistics for bytes and packets affected by the policy. If you enable statistics, you can enable or disable baselining of the statistics. The router implements the baseline by reading and storing the statistics at the time the baseline is set and then subtracting this baseline when baseline-relative statistics are retrieved. Unlike other baseline statistics, policy baseline statistics are not stored in nonvolatile storage (NVS). Baselining must also be enabled on the interface with the appropriate baseline interface command. If you issue the baseline interface command for an interface without first enabling policy statistics baselining on that interface, a warning message indicates:
Policy baseline statistics are not enabled
Example
host1(config-if)#ip policy secondary-input my-policy statistics enabled baseline enabled
Use the no version to remove the association between a policy list and an interface.
show classifier-list
! !
Use to display CLACL configurations. Field descriptionsFields displayed vary depending on the type and configuration of the CLACL:
! ! ! ! ! ! !
Reference countNumber of times the CLACL is referenced by policies Entry countNumber of entries in the classifier list Classifier-ListName of the classifier list EntryEntry number of the classifier list rule ColorPacket color to match ProtocolProtocol type Not ProtocolIf true, matches any protocol except the preceding protocol; if false, matches the preceding protocol Source IP AddressNumber of the network or host from which the packet is sent Source IP WildCardMaskMask that indicates addresses to be matched when specific bits are set Not Source Ip AddressIf true, matches any source IP address and mask except the preceding source IP address and mask; if false, matches the preceding source IP address and mask
70
Destination IP AddressNumber of the network or host from which the packet is sent Destination IP WildCardMaskMask that indicates addresses to be matched when specific bits are set Not Destination Ip AddressIf true, matches any destination IP address and mask except the preceding destination IP address and mask; if false, matches the preceding destination IP address and mask Traffic ClassName of the traffic class to match User Packet ClassUser packet value to match DS FieldDS field value to match TOS ByteToS value to match PrecedencePrecedence value to match User Priority bitsUser priority bits value to match Traffic Class FieldTraffic class field value to match EXP BitsMPLS EXP bit value to match EXP MaskMask applied to EXP bits before matching DE BitFrame Relay DE bit value to match Destination Route ClassRoute class used to classify packets based on the packets destination address Source Route ClassRoute class used to classify packets based on the packets source address LocalIf true, matches packets destined to a local interface; if false, matches packets that are traversing the router
! ! ! ! ! ! ! ! ! ! !
Example 1
host1#show classifier-list Classifier Control List Table ---------- ------- ---- ----GRE Tunnel greClass.1 VLAN lowLatencyLowDrop.1 VLAN excellentEffort.1 VLAN bestEffort.1 VLAN lowLatency.1 IP wstFd.1 source-route-class 44 destination-route-class 55 3 any any IP XYZCorpPermit.1 local true color green ip any any IP routeForXYZCorp.1 color red tcp any any IP XYZCorpIcmpEchoRequests.1 ip any any IP XYZCorpPrecedence.1 tcp any any tos 5 IP XYZCorpPrecedence67.1 udp any any IPv6 IPv6Precedence.1 color yellow IPv6 IPv6Precedence67.1 L2TP l2tpclass.1 color green user-packet-class 8 MPLS mplsClass.1 user-packet-class 10 exp-bits 3 exp-mask 7 Frame relay frMatchDeSet.7 user-packet-class 8 de-bit 0
71
Example 2
host1#show classifier-list detailed Classifier Control List Table ---------- ------- ---- ----IP Classifier Control List XYZCorpPermit Reference count: 1 Entry count: 1 Classifier-List XYZCorpPermit Entry 1 Color: green Protocol: ip Not Protocol: false Source IP Address: 0.0.0.0 Source IP WildcardMask: 255.255.255.255 Not Source Ip Address: false Destination IP Address: 0.0.0.0 Destination IP WildcardMask:255.255.255.255 Not Destination Ip Address: false GRE Tunnel Classifier Control List greClass Reference count: 0 Entry count: 2 Classifier-List greClass Entry 1 User Packet Class: 8 DS Field: 3 Classifier-List greClass Entry 2 Color: yellow VLAN Classifier Control List bestEffort Reference count: 0 Entry count: 1 Classifier-List bestEffort Entry 1 Color: red User Packet Class: 15 User Priority bits: 7 IPv6 Classifier Control List IPv6Classifier Reference count: 0 Entry count: 1 Classifier-List IPv6Classifier Entry 1 User Packet Class: 3 Traffic Class Field: 200 L2TP Classifier Control List l2tpclass Reference count: 0 Entry count: 1 Classifier-List l2tpclass Entry 1 Color: green User Packet Class: 8 MPLS Classifier Control List mplsClass Reference count: 0 Entry count: 1
72
Classifier-List mplsClass Entry 1 User Packet Class: 10 EXP Bits: 3 EXP Mask: 7 Frame relay Classifier Control List frMatchDeSet Reference count: 2 Entry count: 1 Classifier-List frMatchDeSet Entry 7 Traffic Class: toBoston User Packet Class: 8 DE Bit: 0
show frame-relay subinterface ! Use to display information about a subinterfaces Frame Relay policy lists.
!
Field descriptions related to policy lists

! ! ! ! ! ! ! !
Frame Relay policyType and name of the VLAN policy mark-deDE bit value colorColor applied to packet flow for queuing: green, yellow, or red classifier-groupName of the classifier control list used by the policy filterFilter policy action forwardForward policy action traffic classTraffic class in the policy list user-packet-classUser packet class in the policy list
Example
host1#show frame-relay subinterface Frame relay sub-interface SERIAL5/0:1/1.1, status is up Number of sub-interface down transitions is 0 Time since last status change 03:04:59 No baseline has been set In bytes: 660 Out bytes: 660 In frames: 5 Out frames: 5 In errors: 0 Out errors: 0 In discards: 0 Out discards: 0 In unknown protos: 0 Frame relay policy output frOutputPolicy classifier-group frGroupA entry 1 5 packets, 640 bytes mark-de 1 Frame relay sub-interface SERIAL5/1:1/1.1, status is up Number of sub-interface down transitions is 0 Time since last status change 03:05:09 No baseline has been set In bytes: 660 Out bytes: 660 In frames: 5 Out frames: 5 In errors: 0 Out errors: 0 In discards: 0 Out discards: 0 In unknown protos: 0 Frame relay policy input frInputPolicy classifier-group frMatchDeSet entry 1 5 packets, 660 bytes color red
73
show gre tunnel

! !
Use to display information about GRE tunnels. Use the state keyword to display tunnels that are in a specific state: disabled, down, enabled, not-present, or up. Use the ip keyword to display tunnels associated with an IP address. To display information about a specific tunnel, include the name of the tunnel. To display information about tunnels on a specific virtual router, include the name of the virtual router. Field descriptions related to policies
! ! ! ! ! ! ! ! !
! ! !
GRE tunnel policy inputPolicy for outbound traffic GRE tunnel policy outputPolicy for inbound traffic traffic-className of traffic class classifier-groupName of classifier group entryIdentifier for the entry in the classifier group packetsNumber of packets bytesNumber of bytes markToS byte setting for the classifier control list maskMask value corresponding to the ToS
Example
host1#show gre tunnel detail tunnelGre50 GRE tunnel tunnelGre50 is Down Tunnel operational configuration Tunnel mtu is '10240' Tunnel source address is '0.0.0.0' Tunnel destination address is '0.0.0.0' Tunnel transport virtual router is source Tunnel checksum option is disabled Tunnel sequence number option is disabled Tunnel up/down trap is enabled Tunnel-server location is 6/0 Tunnel administrative state is Up Statistics packets octets discards Data rx 0 0 0 Data tx 0 0 0 GRE tunnel policy input routeGre25 classifier-group gre6 entry 1 0 packets, 0 bytes traffic-class best-effort mark 4 mask 255 GRE tunnel policy output routeGre35 classifier-group gre14 entry 1 0 packets, 0 bytes traffic-class best-effort mark 4 mask 255
errors 0 0
74
show interfaces
! !
Use to display information about a subinterface and its VLAN policy lists. You can specify the following keywords:
! !
deltaSpecifies that baselined statistics are to be shown briefDisplays the operational status of all configured interfaces Subinterface numberLocation of the subinterface that carries the VLAN traffic Administrative statusOperational state that you configured for this interface: up or down VLAN IDDomain number of the VLAN In BytesNumber of bytes received on the VLAN subinterface In PacketsSum of all unicast, broadcast, and multicast packets received on the VLAN or S-VLAN subinterface In ErrorsValue is always 0 (zero) In DiscardsValue is always 0 (zero) Out BytesNumber of bytes sent on the VLAN or stacked VLAN (S-VLAN) subinterface Out PacketsNumber of packets sent on the VLAN or S-VLAN subinterface Out ErrorsValue is always 0 (zero) Out DiscardsValue is always 0 (zero) VLAN policyType and name of the VLAN policy
Field descriptions related to policies

!
! ! !
! ! !
! ! ! ! !
Example
host1#show interfaces fastEthernet 1/0.1 FastEthernet1/0.1 is Up, Administrative status is Up VLAN ID: 100 In: Bytes 4156, Packets 30 Errors 0, Discards 0 Out: Bytes 6406, Packets 45 Errors 0, Discards 0 VLAN policy input vlanPol1 classifier-group vlan20 entry 1 5 packets, 730 bytes filter
75
show ip interface
! !
Use to display information about an IP interface (including policy list statistics). Field descriptions related to policy management only
! ! ! !
Network ProtocolsProtocols configured on the interface Internet addressIP address of the interface Broadcast addressBroadcast address used by the interface Operational MTUOperational maximum transmission unit (MTU) for packets sent on this interface Administrative MTUAdministrative maximum transmission unit for packets sent on this interface Operational speedSpeed known to the IP layer in bits per second; equal to the administrative speed if configured, otherwise inherited from the lower layer Administrative speedConfigured speed known to the IP layer in bits per second Discontinuity TimeTime since the counters on the interface became invalidfor example, when the line module was reset Router AdvertisementWhen enabled by the ip irdp command, the router advertises its presence via the ICMP Router Discovery Protocol (IRDP) Administrative debounce-timeAdministrative time delay that an interface must remain in a new state before the routing protocols react to the state change Operational debounce-timeTime delay that an interface must remain in a new state before the routing protocols react to the state change Access routingWhen enabled, an access route is installed to the host on the other end of the interface In Received PacketsPackets received on the interface; indicates whether packets are unicast or multicast In Received BytesBytes received on the interface; indicates whether bytes are unicast or multicast In Policed PacketsPackets policed on the interface; discarded because they exceeded a traffic contract to their destination In Policed BytesBytes policed on the interface; discarded because they exceeded a traffic contract to their destination In Error PacketsPackets determined to be in error at the interface In Invalid Source Address PacketsPackets determined to have originated from an invalid source address Out Forwarded PacketsPackets forwarded from the interface; indicates whether packets are unicast or multicast Out Forwarded BytesBytes forwarded from the interface; indicates whether bytes are unicast or multicast Out Scheduler Drops PacketsPackets dropped by the out scheduler; indicates whether packets are committed, conformed, or exceeded
! !
76
Out Scheduler Drops BytesBytes dropped by the out scheduler; indicates whether bytes are committed, conformed, or exceeded PolicyIndicates which policy is attached and whether it is on the input or output of the interface classifier-groupName of a CLACL attached to the interface and number of entry filterNumber of packets and bytes dropped because of the CLACL colorExplicit color applied to packet flow for queuing; green, yellow, or red:
" "
! !
Packets loggedNumber of packets colored Bytes loggedNumber of bytes colored Packets transmittedNumber of packets sent to the next-hop address Bytes transmittedNumber of bytes sent to the next-hop address
next hopAddress of the next-hop destination:

" "
! !
forwardNumber of packets and bytes forwarded because of the CLACL rate-limit-profileName of the rate-limit profile
"
committedNumber of packets and bytes within the committed rate limit conformedNumber of packets and bytes exceeding the committed rate limit but within the peak rate exceededNumber of packets and bytes exceeding the peak rate actionAction performed on the packets matched by the rules in the rate-limit profile
"
" "
Example 1
host1#show ip interface serial 2/1:28/24.1 serial2/1:28/24.1 is up, line protocol is up Network Protocols: IP Internet address is 172.24.1.101/255.255.255.0 Broadcast address is 255.255.255.255 Operational MTU = 1600 Administrative MTU = 0 Operational speed = 155520000 Administrative speed = 0 Discontinuity Time = 14695 Router advertisement = disabled Administrative debounce-time = disabled Operational debounce-time = disabled Access routing = disabled In Received Packets 15, Bytes 3135 In Policed Packets 0, Bytes 0 In Error Packets 0 In Invalid Source Address Packets 0 Out Forwarded Packets 0, Bytes 0 Out Scheduler Drops Packets 0, Bytes 0
77
IP Policy input pl28241 Classifier-group clacl28241X01 0 packets, 0 bytes filter Classifier-group clacl28241X02 1 packets, 202 bytes filter Classifier-group clacl28241X03 1 packets, 203 bytes filter Classifier-group clacl28241X04 1 packets, 204 bytes filter Classifier-group clacl28241X05 1 packets, 205 bytes filter !
entry 1
entry 1
entry 1
entry 1
entry 1
Example 2
host1#show ip interface serial 2/1:2/1.101 serial2/1:2/1.101 is up, line protocol is up Network Protocols: IP Internet address is 192.1.2.101/255.255.255.0 Broadcast address is 255.255.255.255 Operational MTU = 1600 Administrative MTU = 0 Router advertisement = disabled Administrative debounce-time = disabled Operational debounce-time = disabled Access routing = disabled In Received Packets 464, Bytes 686788 In Policed Packets 0, Bytes 0 In Error Packets 0 In Invalid Source Address Packets 0 Out Forwarded Packets 350, Bytes 256728 Out Scheduler Drops Packets 0, Bytes 0 Policy input pl02001 classifier-group clacl02001 entry 1 1 packets, 1596 bytes next-hop 192.2.2.201 classifier-group clacl02001 entry 2 rate-limit-profile rlp02001 committed: 1 packets, 1596 bytes action: drop conformed: 2 packets, 1016 bytes action: drop exceeded: 89 packets, 140956 bytes action: drop classifier-group clacl02002 entry 1 98 packets, 144716 bytes next-hop 192.2.2.201 classifier-group clacl02002 entry 2 rate-limit-profile rlp02002 committed: 98 packets, 144716 bytes action: drop conformed: 0 packets, 0 bytes action: drop exceeded: 0 packets, 0 bytes action: drop classifier-group clacl02003 entry 1 15 packets, 20340 bytes next-hop 192.2.2.201 classifier-group clacl02004 entry 1 20 packets, 25440 bytes next-hop 192.2.2.201 classifier-group clacl02005 entry 1 20 packets, 30440 bytes next-hop 192.2.2.201
78
Example 3 If you have enabled policy statistics and baselining, consider the difference in standard and baselined statistics. First display standard policy statistics:
host1#show ip interface atm 9/1.1
Partial results might be:

Policy output 2egress classifier-group claclWst10 entry 1 98 packets, 12544 bytes forward
Now display baselined statistics:

host1#show ip interface atm 9/1.1 delta
Partial results might be:

Policy output 2egress classifier-group claclWst10 entry 1 10 packets, 1280 bytes forward
show ipv6 interface

!
Use to display detailed or summary information, including policy and classifier information, for a particular IPv6 interface or for all interfaces. The default for the show ipv6 interface command is all interface types and all interfaces. Use the brief or detail keywords with the show ipv6 interface command to display different levels of information. Field descriptions
! ! ! ! ! !
DescriptionOptional description for the interface or address specified Network ProtocolsNetwork protocols configured on this interface Link local addressLocal IPv6 address of this interface Internet addressExternal address of this interface Operational MTUValue of the MTU Administrative MTUValue of the MTU if it has been administratively overridden using the configuration Operational speedSpeed of the interface Administrative speedValue of the speed if it has been administratively overridden using the configuration Creation typeMethod by which the interface was created (static or dynamic) ND reachable timeAmount of time (in milliseconds) that the neighbor is expected to remain reachable
! !
79
ND duplicate address detection attemptsNumber of times that the router attempts to determine a duplicate address ND neighbor solicitation retransmission intervalInterval in which the router retransmits neighbor solicitations ND proxyIndicates whether the router will reply to solicitations on behalf of a known neighbor ND RA source link layerIndicates whether the RA includes the link layer ND RA intervalInterval (in seconds) of the neighbor discovery router advertisement ND RA lifetimeLifetime (in seconds) of the neighbor discovery router advertisement ND RA managed flagState of the neighbor discovery router advertisement managed flag ND RA other config flagState of the neighbor discovery router advertisement other config flag ND RA advertising prefixesConfigured advertisement prefixes for neighbor discovery router advertisement In Received Packets, BytesTotal number of packets and bytes received on this interface
"
! !
Unicast Packets, BytesUnicast packets and bytes received on the IPv6 interface; link-local received multicast packets (non-multicast-routed frames) are counted as unicast packets Multicast Packets, BytesMulticast packets and bytes received on the IPv6 interface, which are then multicast-routed and counted as multicast packets
"
In Total Dropped Packets, BytesTotal number of inbound packets and bytes dropped on this interface
"
In Policed PacketsPackets that were received and dropped because of rate limits In Invalid Source Address PacketsPackets received with invalid source address (for example, spoofed packets) In Error PacketsNumber of packets received with errors In Discarded PacketsPackets received that were discarded for reasons other than rate limits, errors, and invalid source address
"
" "
Out Forwarded Packets, BytesTotal number of packets and bytes that were sent from this interface
"
Unicast Packets, BytesUnicast packets and bytes that were sent from this interface Multicast Routed Packets, BytesMulticast packets and bytes that were sent from this interface
"
Out Total Dropped PacketsTotal number of outbound packets and bytes dropped by this interface
"
Out Scheduler Dropped Packets, BytesNumber of outbound packets and bytes dropped by the scheduler
80
"
Out Policed Packets, BytesNumber of outbound packets and bytes dropped because of rate limits Out Discarded PacketsNumber of outbound packets that were discarded for reasons other than those dropped by the scheduler and those dropped because of rate limits rate-limit-profileName of the profile classifier-group entryEntry index CommittedNumber of packets and bytes that conform to the committed access rate ConformedNumber of packets and bytes that exceed the committed access rate but conform to the peak access rate ExceededNumber of packets and bytes that exceed the peak access rate
"
IPv6 policyType (input, output, local-input) and name of the policy

" " "
"
"
queue, traffic class, bound to ipv6Queue and traffic class bound to the specified IPv6 interface
" "
Queue lengthNumber of bytes in the queue Dropped committed packets, bytesTotal number of committed packets and bytes dropped by this interface Dropped conformed packets, bytesTotal number of conformed packets and bytes dropped by this interface Dropped exceeded packets, bytesTotal number of exceeded packets and bytes dropped by this interface
"
"
Example
host1#show ipv6 interface FastEthernet 9/0.6 FastEthernet9/0.6 line protocol VlanSub is up, ipv6 is up Description: IPv6 interface in Virtual Router Hop6 Network Protocols: IPv6 Link local address: fe80::90:1a00:740:31cd Internet address: 2001:db8:1::/48 Operational MTU 1500 Administrative MTU 0 Operational speed 100000000 Administrative speed 0 Creation type Static ND reachable time is 3600000 milliseconds ND duplicate address detection attempts is 100 ND neighbor solicitation retransmission interval is 1000 milliseconds ND proxy is enabled ND RA source link layer is advertised ND RA interval is 200 seconds, lifetime is 1800 seconds ND RA managed flag is disabled, other config flag is disabled ND RA advertising prefixes configured on interface In Received Packets 0, Bytes 0 Unicast Packets 0, Bytes 0 Multicast Packets 0, Bytes 0 In Total Dropped Packets 0, Bytes 0 In Policed Packets 0 In Invalid Source Address Packets 0 In Error Packets 0 In Discarded Packets 0
81
Out Forwarded Packets 8, Bytes 768 Unicast Packets 8, Bytes 768 Multicast Routed Packets 0, Bytes 0 Out Total Dropped Packets 5, Bytes 0 Out Scheduler Dropped Packets 0, Bytes 0 Out Policed Packets 0 Out Discarded Packets 5 IPv6 policy input ipv6InPol25 rate-limit-profile Rlp2Mb classifier-group clgA entry 1 Committed: 0 packets, 0 bytes Conformed: 0 packets, 0 bytes Exceeded: 0 packets, 0 bytes rate-limit-profile Rlp8Mb Committed: 0 packets, 0 bytes Conformed: 0 packets, 0 bytes Exceeded: 0 packets, 0 bytes IPv6 policy output ipv6PolOut2 rate-limit-profile RlpOutA classifier-group clgB entry 1 Committed: 0 packets, 0 bytes Conformed: 0 packets, 0 bytes Exceeded: 0 packets, 0 bytes rate-limit-profile RlpOutB Committed: 0 packets, 0 bytes Conformed: 0 packets, 0 bytes Exceeded: 0 packets, 0 bytes IPv6 policy local-input ipv6PolLocIn5 rate-limit-profile Rlp1Mb classifier-group clgC entry 1 Committed: 0 packets, 0 bytes Conformed: 0 packets, 0 bytes Exceeded: 0 packets, 0 bytes rate-limit-profile Rlp5Mb Committed: 0 packets, 0 bytes Conformed: 0 packets, 0 bytes Exceeded: 0 packets, 0 bytes queue 0: traffic class best-effort, bound to ipv6 FastEthernet9/0.6 Queue length 0 bytes Forwarded packets 0, bytes 0 Dropped committed packets 0, bytes 0 Dropped conformed packets 0, bytes 0 Dropped exceeded packets 0, bytes 0
show mpls l2transport interface ! Use to display status and configuration information about MPLS Layer 2 interfaces.
!
When the keyword l2transport is specified, only Layer 2 circuits for the specified interface are displayed. Field descriptions
! !
InterfaceSpecifier and status of each interface base-LSP/remote-addrIdentifies either the tunnel that is selected to forward the traffic or the address of the router at the other end group-idGroup ID number for the interface vc-idVC ID number for the interface mtuMaximum transmission unit for the interface
! ! !
82
state/in/out-labelStatus of the Layer 2-over-MPLS connection or the incoming/outgoing VC label Mpls Statistics
" " " " "
pktsNumber of packets received or sent hcPktsNumber of high-capacity (64-bit) packets received or sent octetsNumber of octets received or sent hcOctetsNumber of high-capacity (64-bit) octets received or sent errorsNumber of packets that are dropped for some reason at receipt or before being sent discardPktsNumber of packets that are discarded due to lack of buffer space at receipt or before being sent
"
queue, traffic class, bound toQueue and traffic class bound to the specified interface
" "
Queue lengthNumber of bytes in queue Forwarded packets, bytesTotal number of packets and bytes forwarded by this interface Dropped committed packets, bytesTotal number of committed packets and bytes dropped by this interface Dropped conformed packets, bytesTotal number of conformed packets and bytes dropped by this interface Dropped exceeded packets, bytesTotal number of exceeded packets and bytes dropped by this interface
"
"
"
! !
MPLS policyType (input, output) and name of policy classifier-groupName of a CLACL attached to the interface and number of entry
" "
rate-limit-profileName of profile CommittedNumber of packets and bytes conforming to the committed access rate ConformedNumber of packets and bytes that exceed the committed access rate but conform to the peak access rate ExceededNumber of packets and bytes exceeding the peak access rate
"
"
Example
host1#show mpls l2transport interface FastEthernet9/0.1 routed to 222.9.1.3 on base LSP tun mpls:lsp-de090100-24-37 group-id 2 vc-id 900001 mtu 1500 State UP In Label 48 on stack 0 pkts, 0 hcPkts, 0 octets 0 hcOctets, 0 errors, 0 discardPkts Out Label 49 on tun mpls:lsp-de090100-24-37 0 pkts, 0 hcPkts, 0 octets 0 hcOctets, 0 errors, 0 discardPkts queue 0: traffic class best-effort, bound to atm-vc ATM1/0.1
83
Queue length 0 bytes Forwarded packets 0, bytes 0 Dropped committed packets 0, bytes 0 Dropped conformed packets 0, bytes 0 Dropped exceeded packets 0, bytes 0 MPLS policy input mplsInputPolicy classifier-group claclWst50 entry 1 0 packets, 0 bytes rate-limit-profile rlp committed: 0 packets, 0 bytes, action: transmit conformed: 0 packets, 0 bytes, action: transmit exceeded: 0 packets, 0 bytes, action drop MPLS policy output mplsOutputPolicy classifier-group claclWst75 entry 1 0 packets, 0 bytes rate-limit-profile rlp committed: 0 packets, 0 bytes, action: transmit conformed: 0 packets, 0 bytes, action: transmit exceeded: 0 packets, 0 bytes, action: drop
show policy-list
! !
Use to display information about policy lists. Field descriptionsFields displayed vary depending on the type of policy and the rules assigned to the policy:
! !
PolicyName of the policy list. Administrative stateFor SNMP use; goes to enable when the policy list is created. Users modifying the policy list commands via telnet see the state as disabled. Modifications of a policy are not applied to an interface until the administrative state is disabled and enabled. Reference countNumber of attachments to interfaces or profiles. Referenced by interface(s)List of interfaces to which policy is attached; indicates whether the attachment is at input or output of interface. Referenced by profile(s)List of profiles to which policy is attached; indicates whether the attachment is at input, secondary-input, or output of interface created by the profile. Classifier control listName of the classifier control list containing policy rules and the precedence assigned to the classifier control list. StatisticsEnabled, disabled. Rule types are:
" " " " " " " "
! !
! !
filterFilter policy action forwardForward policy action next-interfaceNext-interface policy action next-hopNext-hop policy action rate-limit-profileRate-limit-profile policy action colorColor of a packet; green, yellow, or red traffic-classTraffic class in a policy list logLog policy action
84
" " "
mark tosToS byte in the IP header to a specified value mark DS fieldDS field value in the IP header to a specified value mark TC precedenceTraffic class value in the IPv6 header to a specified value mark EXPValue assigned to EXP bits action mark user priorityValue assigned to 802.1p VLAN user priority bit mark DEDE bit action
" " " ! !
Rule statusIndicates if the rule is suspended.
Example
host1#show policy-list Policy Table ------ ----IP Policy routeForABCCorp Administrative state: enable Reference count: 0 Classifier control list: ipCLACL10, precedence 75 forward Virtual-router: default List: next-hop 192.0.2.12, order 10, rule 2 (active) next-hop 192.0.100.109, order 20, rule 3 (reachable) next-hop 192.120.17.5, order 30, rule 4 (reachable) interface ip3/1, order 40, rule 5 mark tos 125 rate-limit-profile ipRLP25 Classifier control list: ipCLACL20, precedence 125 filter IPv6 Policy routeForIPv6 Administrative state: enable Reference count: 0 Classifier control list: ipv6tc67, precedence 75 color red mark tc-precedence 7 Frame relay Policy frOutputPolicy Administrative state: enable Reference count: 0 Classifier control list: frMatchDeSet, precedence 100 mark-de 1 Frame relay Policy frInputPolicy Administrative state: enable Reference count: 0 Classifier control list: frMatchDeSet, precedence 100 color red GRE Tunnel Policy routeGre50 Administrative state: enable Reference count: 0 Classifier control list: gre8, precedence 150 color red mark dsfield 20 filter L2TP Policy routeForl2tp
85
Administrative state: enable Reference count: 0 Classifier control list: *, precedence 100 color red rate-limit-profile l2tpRLP20 MPLS Policy routeForMpls Administrative state: enable Reference count: 0 Classifier control list: *, precedence 200 mark-exp 2 mask 7 rate-limit-profile mplsRLP5 VLAN Policy routeForVlan Administrative state: enable Reference count: 0 Classifier control list: lowLatencyLowDrop, precedence 100 traffic-class lowLatencyLowDrop color green mark-user-priority 7 Classifier control list: lowLatency, precedence 100 traffic-class lowLatency (suspended) Classifier control list: excellentEffort, precedence 100 traffic-class excellentEffort Classifier control list: bestEffort, precedence 100 traffic-class bestEffort
show rate-limit-profile
! !
Use to display information about rate-limit profiles. Field descriptions

! ! !
Rate-Limit-ProfileName of the rate-limit profile Profile TypeOne-rate or two-rate profile Reference CountNumber of policy lists that reference this rate-limit profile Committed rateTarget rate for the traffic, in bits per second Committed burstAmount of bandwidth allocated to accommodate bursty traffic, in bytes Excess burstAmount of bandwidth allocated to accommodate a packet in progress when the rate is in excess of the burst Peak rateAmount of bandwidth allocated to accommodate traffic flow in excess of the committed rate, in bits per second Peak burstAmount of bandwidth allocated to accommodate bursty traffic in excess of the peak rate, in bytes MaskValue of mask applied to ToS byte in IP packet header Committed rate actionPolicy action (drop, transmit, or mark) taken when traffic flow does not exceed the committed rate Conformed rate actionPolicy action (drop, transmit, or mark) taken when traffic flow exceeds the committed rate but remains below the peak rate Exceeded rate actionPolicy action (drop, transmit, or mark) taken when traffic flow exceeds the peak rate
! !
! !
86
Example
host1#show rate-limit-profile Rate Limit Profile Table ---- ----- ------- ----IP Rate-Limit-Profile: rlp Profile Type: one-rate Reference count: 0 Committed rate: 0 Committed burst: 8192 Excess burst: 0 Mask: 255 Committed rate action: transmit Conformed rate action: transmit Exceeded rate action: drop IP Rate-Limit-Profile: rlp Profile Type: two-rate Reference count: 0 Committed rate: 0 Committed burst: 8192 Peak rate: 0 Peak burst: 8192 Mask: 255 Committed rate action: transmit Conformed rate action: transmit Exceeded rate action: drop L2TP Rate-Limit-Profile: L2tpRlp Profile Type: Reference count: Committed rate: Committed burst: Peak rate: Peak burst: Committed rate action: Conformed rate action: Exceeded rate action:
two-rate 0 0 8192 0 8192 transmit transmit drop
show secure policy-list

!
Use to display information about secure policy lists, which are used for packet mirroring. You must have CLI access level 13 or above to use this command; the level can be modified by an administrator. Field descriptions
! ! ! !
PolicyType (IP or L2TP) and name of the policy list Administrative stateSet to enable when the policy list is created. Reference countNumber of attachments to interfaces or profiles Classifier control listName of the classifier control list, which is always *; (contains mirror policy rule and has precedence value to determine order within policy) precedencePrecedence assigned to the classifier control list mirrorMirror action analyzer-ip-addressIP address of analyzer device
! ! !
87
analyzer-virtual-routerVirtual router where the analyzer interface is configured analyzer-udp-portUDP port used to communicate with analyzer device mirror-idUnique identifier of the mirrored session session-idUnique identifier of the user session
! ! !
NOTE: A status of unreachable after the session-id indicates that the analyzer interface is either not in analyzer mode or that it is in a down state.
!
Referenced by interface(s)Interfaces to which policy is attached; indicates whether the attachment is at secure input or secure output of interface; also indicates the virtual router at which the interface attachment exists Referenced by profile(s)Not currently supported; always null statisticsNot currently supported; always disabled
! ! !
Example
host1#show secure policy-list Policy Table ------ ----Secure IP Policy secureIpPolicy Administrative state: enable Reference count: 2 Classifier control list: *, precedence 100 mirror analyzer-ip-address 192.168.1.1 analyzer-virtual-router default analyzer-udp-port 3000 mirror-id 6789 session-id 6543 Referenced by interface(s): ATM5/0.1 secure-input policy, statistics disabled, virtual-router default ATM5/0.1 secure-output policy, statistics disabled, virtual-router default Referenced by profile(s): No profile references L2TP Secure Policy secureL2tpPolicy Administrative state: enable Reference count: 2 Classifier control list: *, precedence 100 mirror analyzer-ip-address 192.168.2.1 analyzer-virtual-router default analyzer-udp-port 3000 mirror-id 6789 session-id 6543 (unreachable) Referenced by interface(s): TUNNEL l2tp:1/msn.pwh.com/1 TUNNEL l2tp:1/msn.pwh.com/1 Referenced by profile(s): No profile references
secure-input policy, statistics disabled secure-output policy, statistics disabled
88
show vlan subinterface

! !
Use to display information about a subinterfaces VLAN policy lists. Field descriptions
!
Subinterface numberLocation of the subinterface that carries the VLAN traffic VLAN IDDomain number of the VLAN VLAN policyType and name of the VLAN policy filterNumber of packets and bytes that have been policed by the policy
! ! ! !
Example
host1#show vlan subinterface fastEthernet 1/0.1 VLAN ID is 100 VLAN policy input vlanPol1 classifier-group claclVlanBos entry 1 5 packets, 730 bytes filter
89
90
Chapter 2
Configuring Quality of Service

This chapter provides information for configuring quality of service (QoS) on the E-series router. The QoS feature enables your router to distinguish traffic with strict timing requirements from traffic that can tolerate delay, jitter, and loss. QoS topics are discussed in the following sections:
! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
Overview on page 92 References on page 96 Configuration Tasks on page 96 Traffic Classes on page 97 Traffic-Class Groups on page 99 Queue Profiles on page 100 Drop Profiles on page 105 Scheduler Profiles on page 114 Shared Shaping on page 118 Statistics Profiles on page 147 QoS Profiles on page 151 Configuring QoS for ATM Interfaces on page 155 Configuring QoS for L2TP Interfaces on page 167 QoS Profile Attachments on page 170 QoS Profile Configuration Examples on page 174 Diffserv Configuration with Multiple Traffic-Class Groups on page 178 Strict-Priority Scheduling on page 182
91
! ! ! ! !
Relative Strict-Priority Scheduling on page 184 Rate Shaping on page 191 Port Shaping on page 192 Clearing Statistics on page 193 Monitoring QoS on page 193
Overview
QoS is a suite of features that configure queuing and scheduling on the forwarding path of the E-series router. QoS provides a level of predictability and control beyond the best-effort delivery that the router provides by default. Best-effort service provides packet transmission with no assurance of reliability, delay, jitter, or throughput. QoS as developed for E-series routers conforms to the IETF Differentiated Services (DiffServ) model (RFCs 2597 and 2598). DiffServ networks classify packets into one of a small number of aggregated flows or traffic classes for which you can configure different QoS characteristics. The Juniper Networks QoS architecture extends DiffServ to support edge features such as high-density queuing. The E-series router supports:
! ! !
IETF architecture for differentiated services Assured forwarding per-hop-behavior (PHB) groups Expedited forwarding PHB groups
See References on page 96 for a list of related RFCs. The router supports configurable queuing and scheduling. It has an application-specific integrated circuit (ASIC) scheduler that supports thousands of queues in a hierarchical round-robin (HRR) scheduler. The scheduler allows the router to allocate separate queues for each forwarding interface. Separate queues enable fair access to buffers and bandwidth for each subscriber connected to the router. Allocating queues per interface allows an Internet service provider (ISP) to shape an individual subscribers traffic flows to specified rates independent of the underlying Layer 2 network type. The E-series router supports QoS on the 5-, 10-, and 40-Gbps fabric boards. It supports egress line module functions only on ASIC-based line modules.
92
Overview
Chapter 2: Configuring Quality of Service
Figure 3 shows the traffic flow through the router.

Figure 3: Traffic Flow Through an E-series Router
Ingress
Line module
Switch fabric
Line module
Egress
g013025
E-series router
Terms
Table 16 defines terms used in this discussion of QoS.
Table 16: QoS Terminology Used in This Chapter Term
Assured rate Best effort
Description
Bandwidth guaranteed until oversubscribed. Network forwards as many packets as possible in as reasonable a time as possible. This is the default per-hop behavior (PHB) for packet transmission. For a logical interface, the queue associated with the best-effort traffic class for that logical interface,
Best-effort queue
Best-effort scheduler node The scheduler node associated with a logical interface and traffic class group pair, and where the traffic class group contains the best-effort traffic class. Also known as best-effort node. CDV CDVT Effective weight Cell delay variation. Measures the difference between a cells expected and actual transfer delay. Determines the amount of jitter. Cell delay variation tolerance. Specifies the acceptable tolerance of CDV (jitter). The result of a weight or an assured rate. Users configure the scheduler node by specifying either an assured rate or a weight within a scheduler profile. An assured rate, in bits per second, is translated into a weight. The resultant weight is referred to as an effective weight. A scheduler node associated with a {port interface, traffic-class group} pair. Because the logical interface is the port, only one such scheduler node can exist for each traffic-class group above the port. This node aggregates all traffic for traffic classes in the group. Hierarchical assured rate. Dynamically adjusts bandwidth for scheduler nodes. Hierarchical round-robin. Allocates bandwidth to queues in proportion to their weights. Delay in the transmission of a packet through a network from beginning to end. Supported on the E-series router.
Group node
HAR HRR Latency Proprietary QoS Management Information Base (MIB) Queue
First-in-first-out (FIFO) set of buffers that control packets on the data path.
Overview
93
Table 16: QoS Terminology Used in This Chapter (continued) Term

QoS port-type profile QoS profile attachment Rate shaping RED Scheduler hierarchy
Description
Supplies the QoS information for forwarding interfaces stacked above ports of the associated interface type. Applies the rules in the QoS profile to a specific interface. Allows you to throttle a queue to a specified rate. Random early detection congestion avoidance technique. A hierarchical, tree-like arrangement of scheduler nodes and queues. The router supports up to three levels of scheduler nodes stacked above a port (level 0), with a final level of queues stacked above the nodes. A traffic-class group uses a scheduler level at level 1. An element within the hierarchical scheduler that implements bandwidth controls for a group of queues. Queues are stacked above scheduler nodes in a hierarchy. The root node is associated with a channel or physical port.
Scheduler node
Shared shaper constituent All nodes and queues that are associated with a logical interface that is being shared shaped are considered potential constituents of the shared shaper. Weight WRED Specifies the relative weight for queues in the traffic class. Weighted random early detection congestion avoidance technique.
Features
Table 17 describes the major QoS features that the E-series router provides.
Table 17: QoS Features Feature
Best effort
Description
Default traffic class for packets being forwarded across the device. Packets that are not assigned to a specific traffic class are assigned to the best-effort traffic class.
! Assured forwardingSee RFC 2597. ! Expedited forwardingSee RFC 2598.
Differentiated services
Drop profile Port shaping QoS port-type profile QoS profile
Template that specifies active queue management in the form of WRED behavior of an egress queue. Shapes the aggregate traffic through a port or channel to a rate that is less than the line or port rate. QoS profile that is automatically attached to ports of the corresponding type if you do not explicitly attach a QoS profile. Collection of QoS commands that specify queue profiles, drop profiles, scheduler profiles, and statistics profiles in combination with interface types. Template that specifies the buffering and tail-dropping behavior of an egress queue.
Queue profile
94
Overview
Table 17: QoS Features (continued) Feature

Rate shaping
Description
Mechanism that throttles the rate at which an interface can transmit packets. Note: Rate shaping as presented in policy management in releases before JUNOSe 4.0 is deprecated and converted to QoS profiles and scheduler profiles.
Relative strict-priority scheduling
Provides strict-priority scheduling within a shaped aggregate rate. For example, it lets you provide 1 Mbps of aggregate bandwidth to a subscriber, with up to 500 Kbps of the bandwidth for low-latency traffic. If there is no strict-priority traffic, the low-latency traffic can use up to the full aggregate rate of 1 Mbps. Configures the bandwidth at which queues drain as a function of relative weight, assured rate, and shaping rate. Mechanism that enables dynamic sharing of logical interface bandwidth for traffic that is queued through separate scheduler hierarchies. Template that specifies rate statistics and event-gathering characteristics. Designates the traffic class (queue) that receives top priority for transmission of its packets through a port. It is implemented with a special strict-priority scheduler node that is stacked directly above the port. A chassis-wide grouping of queues and buffers that support transmission of a designated set of traffic across the chassis, from ingress line module, through the switch fabric, and onto the egress line module. The router supports up to eight traffic classes, and therefore up to eight queues per logical interface.
Scheduler profile Shared rate shaping
Statistics profile Strict-priority scheduling
Traffic class
Traffic-class group
Separate hierarchy of scheduler nodes and queues over a port. A traffic-class group uses one level of the scheduler hierarchy, level 1. Traffic classes belong to the default group unless they are specifically assigned to a named group. All queues are stacked in a single scheduler hierarchy above the physical port. When you configure a traffic class inside a group, its queues are stacked separately. The most common reason for creating separate scheduler hierarchies is to implement strict priority scheduling for all queues in the group. The router supports up to four traffic-class groups. A traffic class cannot belong to more than one group.
WRED
Signals end-to-end protocols such as TCP that the router is becoming congested along a particular egress path. The intent is to trigger TCP congestion avoidance in a random set of TCP flows before congestion becomes severe and causes tail dropping on a large number of flows.
Overview
95
References
For more information about QoS, see the following resources:
!
RFC 2474Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (December 1998) RFC 2475An Architecture for Differentiated Services (December 1998) RFC 2597Assured Forwarding PHB Group (June 1999) RFC 2598An Expedited Forwarding PHB (June 1999) RFC 2698A Two Rate Three Color Marker (September 1999) RFC 2990Next Steps for the IP QoS Architecture (November 2000) RFC 2998A Framework for Integrated Services Operation over Diffserv Networks (November 2000) RFC 3246An Expedited Forwarding PHB (Per-Hop Behavior) (March 2002) RFC 3260New Terminology and Clarifications for Diffserv (April 2002) Floyd, S., and Jacobson, V. Random Early Detection for Congestion Avoidance. IEEE/ACM Transactions on Networking 1(4), August 1993
! ! ! ! ! !
! ! !
Configuration Tasks
Several of the following tasks are optional. Perform the required tasks and also any optional tasks that you need for your QoS configuration: 1. Create and configure a traffic class. 2. (Optional) Create one or more traffic-class groups. 3. (Optional) To configure nondefault buffer management, create a queue profile. 4. (Optional) To configure RED or WRED, create a drop profile. 5. (Optional) To gather rate statistics, create a statistics profile. 6. Create a scheduler profile. 7. Create a QoS profile. QoS profiles reference queue, drop, statistics, and scheduler profiles. 8. Attach the QoS profile to one or more interfaces, or specify the profile as a QoS port-type profile for a given interface type.
96
References
Traffic Classes
A traffic class is a systemwide collection of buffers, queues, and bandwidth that you can allocate to provide a defined level of service to packets in the traffic class. A traffic class corresponds to what the IETF DiffServ working group calls a traffic class in RFC 2597Assured Forwarding PHB Group (June 1999). Traffic classes are global to the router. Packets are:
! ! ! !
Classified into a traffic class on ingress or egress Queued on fabric queues that are specific to the traffic class Queued on the egress line module on queues that are specific to the traffic class Scheduled for transmission
Input policies classify packets into the traffic class; the fabric carries the packets to an egress line module in a fabric queue that is specific to the traffic class; the packets are placed into traffic classspecific queues on the egress line module; and the scheduler schedules the packets for transmission.
Best-Effort Forwarding
The router has a default traffic class called best-effort. You cannot delete this class. You can add the best-effort class to a traffic-class group. The router assigns packets to the best-effort class in each of the following cases:
! ! !
You do not create any other traffic classes. Packets are not classified into a traffic class. Packets arrive at an egress line module that has no queues allocated for their traffic class.
Configuring a Traffic Class

To configure a traffic class: 1. Create a traffic class and enter Traffic Class Configuration mode.
host1(config)#traffic class low-loss1 host1(config-traffic-class)#
2. (Optional) For ERX-1440 routers, specify the relative weight for queues in the traffic class in the fabric.
host1(config-traffic-class)#fabric-weight 12
3. (Optional) Specify strict-priority scheduling across the fabric.

host1(config-traffic-class)#fabric-strict-priority
Traffic Classes
97
fabric-strict-priority
!
Use to specify strict-priority scheduling across the fabric for queues in the traffic class. If multiple traffic classes are strict priority, the fabric weight determines which class gets more bandwidth. Example
host1(config-traffic-class)#fabric-strict-priority
Use the no version to delete the strict-priority setting.
fabric-weight
! !
Use to specify the relative weight for queues in the traffic class in the fabric. Fabric weight controls the bandwidth of fabric queues associated with the traffic class. It does not control the weight of egress queues associated with the traffic class. The weight value is in the range 163. Zero is not a valid weight.
NOTE: The fabric-weight command works only with ERX-1440 routers.
Example
host1(config-traffic-class)#fabric-weight 12
Use the no version to set the fabric to the default weight value, 8.
traffic-class
! ! ! !
Use to configure a traffic class and enter Traffic Class Configuration mode. The traffic class name can be up to 32 characters. It cannot include spaces. The router supports up to eight global traffic classes. Each traffic class can appear in only one traffic-class group. If not explicitly added to a traffic-class group, the traffic class is considered to be ungrouped. Example
host1(config)#traffic class low-loss1 host1(config-traffic-class)#
Use the no version to delete a specified traffic class.
98
Traffic Classes
Traffic-Class Groups
You can put traffic classes into a group to create a hierarchy of scheduler nodes and queues. Organizing traffic into multiple traffic-class groups enables you to manage and shape trafficby service class, for examplewhen the traffic classes are distributed across different VCs. A traffic-class group contains one or more traffic classes, but a particular traffic class can belong to a single groupeither the default group or one named group. Previous releases of the JUNOSe software supported a single strict-priority traffic-class group. Now you can configure an auto-strict group and up the three extended traffic-class groups. You must put traffic classes that require strict priority scheduling in the auto-strict group. You can optionally put traffic classes that need a separate round robin (for example, video) in an extended group. A traffic class that is not contained in any named group is considered to belong to the default group. Traffic classes are placed in the default traffic-class group when the classes are configuredyou can then move a class to another traffic-class group. When you delete a traffic-class from a named group, the class is automatically moved to the default traffic-class group. ATM VC nodes that are configured in the default group (which is the factory default configuration) receive backpressure from the segmentation and reassembly (SAR) feature. Traffic-class groups are global in scope by default. However, you may wish to manage certain traffic classes through particular line modules. If you have already created a traffic-class group, you can subsequently specify a slot number to create a local instance of the group that is restricted to the module occupying that slot. Characteristics configured for the local group on the line module override those of the global group, for only that line module. Traffic classes in a globally scoped traffic-class group cannot belong to any other group. Traffic classes in a local traffic-class group cannot belong to any other group.
Configuring Traffic-Class Groups

To configure a traffic-class group: 1. Create a traffic-class group and enter Traffic Class Group Configuration mode.
host1(config)#traffic-class-group assuredForwarding host1(config-traffic-class-group)#
2. Add traffic classes to the traffic-class group.

host1(config-traffic-class-group)#traffic-class low-latency-traffic-class
traffic-class
! !
Use to add a traffic class to the traffic-class group. Example

host1(config-traffic-class-group)#traffic-class low-latency-traffic-class
Use the no version to delete a traffic class from a traffic-class group.
Traffic-Class Groups
99
traffic-class-group
!
Use to configure a traffic-class group and enter Traffic Class Group Configuration mode, from which you can add classes to or delete classes from the group. If you do not specify a keyword, the group is strict-priority by default. You can use the auto-strict-priority keyword to explicitly configure a single traffic-class group with strict-priority scheduling, regardless of the scheduler profile associated with the group node. You can use the extended keyword to configure up to three extended traffic-class groups. Scheduling for these groups is determined by the scheduler profile associated with the group node. If an explicitly configured strict-priority group exists, the scheduler for the extended groups may not specify strict-priority scheduling. Use the slot slotNumber option to associate a pre-existing global traffic-class group with the module occupying that slot. Characteristics configured for the local group on the line module override those of the global group. Example
host1(config)#traffic-class-group assured slot 9 extended host1(config-traffic-class-group)#
! !
Use the no version to remove the selected traffic-class group. You must remove all local (slot-based) instances of a traffic-class group before you can remove the global group.
Queue Profiles
A queue is a set of FIFO buffers that buffer packets on the data path. QoS associates queues with a traffic class/interface pair. For example, if you create 4,000 IP interfaces and configure each interface with four traffic classes, then 16,000 queues are created. The E-series router dynamically manages the shared memory on egress line modules to provide a good balance between sharing the memory among queues and protecting an individual queues claim on its fair share of the egress memory. When egress packet memory is in high demand and aggregate utilization of the 32-MB memory is high, queue lengths are set to lengths that strictly partition egress memory into per-queue memory sections. This conservative buffer-management strategy reserves a fair share of buffers for each queue, so that high bandwidth consumers cannot starve out moderate traffic consumers by allocating all the shared memory resource for themselves. When egress packet memory is in low demand, a more liberal buffer management strategy is used to provide active queues with more access to the shared memory resource. The router dynamically varies queue lengths for all queues as the real-time demand on the egress packet memory changes. You can configure limits to prevent the router from setting queue lengths too low or too high.
100
Queue Profiles
Static Oversubscription
Static oversubscription lets the router vary queue thresholds based on the number of queues currently configured, which is relatively static. Static oversubscription is based on the assumption that, when a few queues are configured, it is likely that many of the queues will be active at the same time; and when a large number of queues are configured, it is likely that fewer queues will be active at the same time. When few queues are configured, buffer memory is strictly partitioned between queues to ensure that buffers are available for all queues. As the number of configured queues increases, buffer memory is increasingly oversubscribed to allow more buffer sharing. It is unnecessary and wasteful to reserve buffer space for all queues when many are expected to be idle.
Dynamic Oversubscription
Dynamic oversubscription lets the router vary queue thresholds based on the amount of egress buffer memory in use. The router divides egress buffer memory into eight regions of 4 MB each. When buffer memory is in low demand, queues are given large amounts of buffer memory. As the demand for buffer memory increases, queues are given progressively smaller amounts of buffer memory.
Overriding Default Queue Allocation

To prevent the router from setting queue thresholds too low or too high, you can specify minimum and maximum queue thresholds. You can also specify the conformed length and exceeded length as percentages of the committed length. You may want to limit latency of your multicast traffic by bounding the queue length. The following example configures the multicast queues so that the committed threshold never exceeds 20 KB, even when the egress memory is lightly loaded. The forfeited buffers are allocated to other queues.
host1(config)#queue-profile multicast host1(config-queue)#committed-length 0 20000 host1(config-queue)#exit
You can also set the buffer weight to ensure that some sets of queues get higher thresholds than others. Buffer weight is analogous to weight in a scheduler profile. It directs the router to set the queue thresholds proportionately. For example, suppose a line module with 4000 IP interfaces is configured with four queues per IP interface, corresponding to four traffic classes. Suppose that queues in two of the traffic classes are configured with a buffer weight of 24 to increase burst tolerance. The following example configures the video queue:
host1(config)#queue-profile video host1(config-queue)#buffer-weight 24 host1(config-queue)#exit host1(config)#
Queue Profiles
101
When the egress memory is fully loaded, dynamic oversubscription is 0 percent, and the 8000 queues with the default buffer weight strictly partition 25 percent of the 32-MB memory, leaving 75 percent of the memory for the queues weighted 24 (corresponding to the ratio 75 percent:25 percent, or 24:8). Therefore, these queues have committed thresholds of 1 KB each, and queues with the buffer weight of 24 have committed thresholds of 3 KB each. As the egress memory becomes progressively less loaded, all the queue thresholds increase proportionally, based on dynamic oversubscription, but the queues with buffer weight 24 are always set with thresholds three times larger than the default thresholds. If the queue thresholds are constrained by committed or conformed threshold settings, any unused memory is redistributed to queues whose thresholds are not constrained. This use of thresholds is analogous to the way that shaping rates constrain bandwidth and cause bandwidth redistribution to unconstrained queues. JUNOSe software uses 128-byte buffers. When setting very small queue thresholds, keep the following guidelines in mind:
!
Specifying a maximum queue length of 0 bytes disables queuing of packets on the queue. Specifying a maximum queue length of 1128 bytes creates a single 128-byte buffer for the queue. Specifying a maximum queue length of 129256 bytes creates two 128-byte buffers for the queue. Packets and cells consume at least one buffer. For example, a 64-byte packet consumes a single 128-byte buffer. If you specify a maximum queue length of 256 bytes, then either two packets of 64128 bytes in length or a single packet of 129256 bytes can be queued.
Color-Based Thresholding
Packets within the router are tagged with a drop precedence:
! ! !
When the queue fills above the exceeded threshold, the router drops red packets, but still queues yellow and green packets. When the queue fills above the conformed drop threshold, the router queues only green packets.
NOTE: All color-based thresholds vary in proportion to the dynamic queue length.
102
Queue Profiles
Configuring Queue Profiles

A queue profile controls the buffering and dropping behavior of a set of egress queues by letting you set the buffer weight of the queue, the drop thresholds, and the constraints on queue lengths. Set the queue lengths as follows:
!
To oversubscribe buffer memory, set a minimum queue length.
NOTE: If the sum of the queue minimum lengths is greater than the amount of egress buffer memory, then the egress buffer memory is oversubscribed.
! !
To guarantee a minimum level of buffering, set a maximum queue length. To limit the buffering in queues, set a maximum queue length.
If you do not set the queue lengths, the router varies the queue length dynamically between 1 KB and 7 MB. 1. Create a queue profile and enter Queue Configuration mode.
host1(config)#queue-profile video host1(config-queue)#
2. (Optional) Set the buffer weight of the queue.

host1(config-queue)#buffer-weight 16
3. (Optional) Set a minimum or maximum queue length for committed packets.

host1(config-queue)#committed-length 11000 15000
4. (Optional) Set a minimum or maximum queue length for conformed packets.

host1(config-queue)#conformed-length 10000 14000
5. (Optional) Set a minimum or maximum queue length for exceeded packets.

host1(config-queue)#exceeded-length 9000 10000
6. (Optional) Set the conformed drop threshold as a percentage of the committed threshold.
host1(config-queue)#conformed-fraction 60
7. (Optional) Set the exceeded drop threshold as a percentage of the committed threshold.
host1(config-queue)#exceeded-fraction 40
Queue Profiles
103
buffer-weight
!
Use to set the buffer weight of the queue. Queues with a buffer weight of 16 are twice as long as queues with a buffer weight of 8. The range is 163; the default is 8. Example
host1(config-queue)#buffer-weight 16
! !
Use the no version to return the buffer weight to the default, 8.
committed-length conformed-length exceeded-length

!
Use to set minimum or maximum constraints on queue lengths for committed, conformed, or exceeded packets. You can set minimum and maximum constraints. For both, the range of lengths is 01 GB. By default, there is no minimum or maximum length. The committed-length command sets a minimum or maximum queue length for committed packets. The color for committed packets is green. The conformed-length command sets a minimum or maximum queue length for conformed packets. The color for conformed packets is yellow. The exceeded-length command sets a minimum or maximum queue length for exceeded packets. The color for exceeded packets is red. Example
host1(config-queue)#committed-length 8000 10000
Use the no version to remove constraints on the queue length.
conformed-fraction exceeded-fraction
!
Use to set the conformed and exceeded drop thresholds as a percentage of the committed threshold.
! !
exceeded fraction: range is 0100; default is 25 conformed fraction: range is 0100; default is 50
Example
host1(config-queue)#exceeded-fraction 30
Use the no version to return the fraction to its default setting.
104
Queue Profiles
queue-profile
! ! !
Use to configure a queue profile and enter Queue Configuration mode. You can configure 16 queue profiles on a router. Example
host1(config)#queue-profile video host1(config-queue)#exit host1(config)#queue-profile multicast host1(config-queue)#exit host1(config)#queue-profile internet host1(config-queue)#
Use the no version to remove the queue profile.
Drop Profiles
Drop profiles control the dropping behavior of a set of egress queues. They define the range within the queue where RED operates, the maximum percentage of packets to drop, and sensitivity to bursts of packets. WRED is an extension to RED that allows you to assign different RED drop profiles to each color of traffic. The purpose of RED and WRED is to signal end-to-end protocols, such as TCP, that the router is becoming congested along a particular egress path. The intent is to trigger TCP congestion avoidance in a random set of TCP flows before congestion becomes severe and causes tail dropping on a large number of flows. Tail dropping can lead to TCP slow-starts, and tail dropping on a large number of flows results in global synchronization. By default, tail dropping occurs when the length of a queue exceeds a threshold. Drop profiles allow you to employ active queue management by specifying RED/WRED parameters to be applied to an egress queue. Congestion of an egress queue occurs when the rate of traffic destined for the queue exceeds the rate of traffic draining from the queue; the queue fills to its limit, and any further traffic destined to it must be discarded until there is room in the queue. RED and WRED monitor average queue length over time to detect incipient congestion. You can combine drop profiles and queue profiles within a queue rule of a QoS profile to specify up to 256 unique queuing behaviors within the router. You can then associate these queuing behaviors in any combination with any of the egress queues.
Drop Profiles
105
How RED Works

The scheduler maintains an average queue length for each queue configured for RED. When a packet is enqueued, the current queue length is weighted into the average queue length based on the average-length exponent in the drop profile.
!
Small exponent values weight the current queue length heavily, so the average queue length is more responsive to transient bursts. Large exponent values weight the current queue length lightly, so the average queue length is less responsive to bursts.
When the average queue length exceeds the minimum threshold, RED begins randomly dropping packets. As the average queue length increases toward the maximum threshold, RED drops packets with increasing frequency, up to the maximum drop probability. When the average queue length exceeds the maximum drop threshold, all packets are dropped. Figure 4 shows this behavior.
Figure 4: Packets Dropped as Queue Length Increases
Drop none 100% Drop randomly Drop all
Maximum drop probability Drop profile
maximum
minimum
0% 0 Average queue length
queue limit
Configuring RED
To configure RED, perform the following steps: 1. Create a drop profile and enter Drop Profile Configuration mode.
host1(config)#drop-profile internetDropProfile host1(config-drop-profile)#
2. Set the average-length exponent.

host1(config-drop-profile)#average-length-exponent 9
3. (Optional) Set the minimum and maximum threshold for committed traffic.
host1(config-drop-profile)#committed-threshold percent 30 90 4 106
!
Drop Profiles
g013618
4. (Optional) Set the minimum and maximum threshold for conformed traffic.
host1(config-drop-profile)#conformed-threshold percent 25 90 5
5. (Optional) Set the minimum and maximum threshold for exceeded traffic.
host1(config-drop-profile)#exceeded-threshold percent 20 90 6
average-length-exponent
!
Use to set the average-length exponent, which specifies the exponent used to weight the average queue length over time, controlling WRED responsiveness. Specifying an average-length exponent enables the RED average queue length computation. A higher value smooths out the average and slows WRED reaction to congestion and decongestion, accommodating short bursts without dropping. Too large a value can smooth the average to the point that WRED does not react at all. A lower value speeds up WRED reaction. Too low a value can cause overreaction to short bursts, dropping packets unnecessarily. Example
host1(config-drop-profile)#average-length-exponent 5
Use the no version to negate the average-length exponent.
committed-threshold conformed-threshold exceeded-threshold

!
Use to specify the minimum and maximum queue thresholds and maximum drop probability for WRED. You can express thresholds as either percentages of maximum queue size by including the keyword percent, or as absolute byte values by omitting the keyword. The thresholds specify a linear relationship between average queue length and drop probability. Example
host1(config-drop-profile#committed-threshold percent 10 20 30
Use the no version to remove the threshold.
drop-profile
! ! !
Use to configure a drop profile. You can configure up to 16 drop profiles. Example
host1(config)#drop-profile dp1 host1(config-drop-profile)#
Use the no version to remove the drop profile.

Drop Profiles
!
107
RED Configuration Examples

This section describes how to configure the RED average queue length computation, configure RED for colored traffic, and configure RED so that packets are dropped without regard to color.
Configuring Average Queue Length

To enable calculation of average queue length, create a drop profile with a nonzero average-length exponent, reference the drop profile within a QoS profile, and attach the QoS profile to an interface. The following drop profile enables the average queue length calculation, but does not initiate RED dropping behavior:
host1(config)#drop-profile averageOnly host1(config-drop-profile)#average-length-exponent 10
Configuring Thresholds
You can specify different dropping behavior for committed (green), conformed (yellow), and exceeded (red) packets by specifying a minimum queue threshold, maximum queue threshold, and maximum drop probability for each color of traffic. By default, conformed threshold and exceeded threshold take the same values as the committed threshold. Therefore, if you specify only a committed threshold, conformed and exceeded traffic is treated like committed traffic. Similarly, if you specify a conformed threshold without an exceeded threshold, exceeded traffic is treated like committed traffic. The following drop profiles result in identical behavior:
host1(config)#drop-profile colorblind1 host1(config-drop-profile)#committed-threshold percent 30 90 5 host1(config-drop-profile)#exit host1(config)#drop-profile colorblind2 host1(config-drop-profile)#committed-threshold percent 30 90 5 host1(config-drop-profile)#conformed-threshold percent 30 90 5 host1(config-drop-profile)#exit host1(config)#drop-profile colorblind3 host1(config-drop-profile)#committed-threshold percent 30 90 5 host1(config-drop-profile)#conformed-threshold percent 30 90 5 host1(config-drop-profile)#exceeded-threshold percent 30 90 5
Configuring Color-Blind RED

You can configure RED so that packets are dropped without regard to color. To do so, you combine a drop profile that has a committed threshold configured with a queue profile that specifies the same queue length for committed, conformed, and exceeded packets, as shown in Figure 5.
108
Drop Profiles
Figure 5: Color-Blind RED Drop Profile with Colorless Queue Profile
Queue Drop %
g013617
Queue limits
Maximum threshold
In the following example, the drop profile and queue profile combine to specify the following:
!
When the average queue length is between 30 percent full (30 KB) and 90 percent full (90 KB), up to 5 percent of the packets are randomly dropped regardless of their color. When the average queue length is greater than 90 percent, all packets are dropped regardless of color.
host1(config)#drop-profile nocolor host1(config-drop-profile)#committed-threshold percent 30 90 5 host1(config-drop-profile)#exit host1(config)#queue-profile colorless host1(config-queue)#committed-length 100000 100000 host1(config-queue)#conformed-fraction 100 host1(config-queue)#exceeded-fraction 100
To achieve the same drop treatment for each color, you can specify color-blind RED in combination with a color-sensitive queue profile, as shown in Figure 6.
Figure 6: Color-Blind RED Drop Profile with Color-Sensitive Queue Profile
Queue Drop % Maximum threshold
g013616
Queue limits
In the example below, the drop profile and queue profile combine to specify the following:
!
When the average queue length is between 30 percent full (30 KB) and 90 percent full (90 KB), up to 5 percent of the packets are dropped randomly. In this case, the maximum queue length is 100 KB for green packets, 50 KB for yellow packets, and 25 KB for red packets. Therefore, the router randomly drops:
! ! !
Red packets when the average queue length is between 7.5 KB and 22.5 KB Yellow packets when the average queue length is between 15 KB and 45 KB Green packets when the average queue length is between 30 KB and 90 KB
Drop Profiles
109
When the average queue length is greater than 90 percent of the maximum queue length, all packets are dropped. Therefore, the router drops:
! ! !
Red packets when the average queue length is greater than 22.5 KB Yellow packets when the average queue length is greater than 45 KB Green packets when the average queue length is greater than 90 KB
host1(config)#drop-profile colorblindRed host1(config-drop-profile)#committed-threshold percent 30 90 5 host1(config-drop-profile)#exit host1(config)#queue-profile colorSensitive host1(config-queue)#committed-length 100000 100000
How WRED Works

WRED is an extension of RED that allows you to assign different RED drop thresholds to each color of traffic. The router assigns a color to each packet. Committed means green, conformed means yellow, and exceeded means red. When the queue fills above the exceeded threshold, the router drops red packets, but still queues yellow and green packets. When the queue fills above the conformed drop threshold, the router queues only green packets.
Configuring WRED
You configure WRED by creating a drop profile using the same steps in Configuring RED on page 106. The main difference between RED and WRED is that WRED deals with different colored packets. As previously discussed, you can configure E-series RED by using a subset of its QoS capabilities.
WRED Configuration Examples

This section shows how to configure different treatment of colored packets, different drop behavior for each queue, RED and dynamic queue thresholds, and average queue lengths for WRED.
Configuring Different Treatment of Colored Packets

Figure 7 shows a WRED drop profile that yields progressively more aggressive drop treatment for each color. Exceeded traffic is dropped over a wider range and with greater maximum drop probability than conformed or committed traffic. Conformed traffic is dropped over a wider range and with greater maximum drop probability than committed traffic. The commands to configure this example are:
host1(config)#drop-profile wredColored host1(config-drop-profile)#committed-threshold percent 30 90 3 host1(config-drop-profile)#conformed-threshold percent 25 90 5 host1(config-drop-profile)#exceeded-threshold percent 20 90 10
110
Drop Profiles
Figure 7: Different Treatment of Colored Packets

Queue Drop % Maximum threshold
g013615
Queue limits
Defining Different Drop Behavior for Each Traffic Class

You can define different dropping behaviors for each traffic class in the router. By doing so, you can assign less aggressive drop profiles to higher-priority queues and more aggressive drop profiles to lower-priority queues. Figure 8 shows an example that classifies packets into one of four traffic classes. Each traffic class has a different queueing behavior, drop treatment, and scheduler treatment.
Figure 8: Defining Different Drop Behavior for Each Queue
Traffic class 1 queue
Drop % Flow 1 Flow 2 Flow 3 Classifier marker Drop % Queue limits Traffic class 3 queue Queue limits Traffic class 2 queue
DWRR scheduler
Port
Flow 4 Flow 5 Flow N
Drop % Queue limits Priority queue Strictpriority scheduler

g013614
Drop Profiles
111
RED and Dynamic Queue Thresholds

RED typically operates on fixed-size queues, and you can configure the router to use fixed-size queues. However, by default, the router employs dynamic queue thresholds to provide a good balance between sharing the egress buffer memory between queues and protecting an individual queues claim on its fair share of the egress memory. Fixed-size queues become problematic as the number of configured queues scales into the thousands, because allocating disjointed partitions of buffer memory to each queue means the allocations become quite small, and most likely not all queues are simultaneously active. In general, you use queues as follows:
!
Fixed-size queues on core routers and core-facing interfaces where the number of queues is relatively small (tens or hundreds, but not thousands). Dynamic queues on edge-facing interfaces where the number of queues is relatively large (thousands).
As shown in Figure 9, queue lengths extend to oversubscribe memory when aggregate memory utilization is low, and contract to strictly partition memory when memory utilization is high. Dynamic thresholding enforces fairness when free buffers are scarce and promotes sharing when buffers are plentiful. Dynamic queue thresholds are discussed in Queue Profiles on page 100. Figure 9 illustrates WRED behavior with dynamic queue thresholding. To configure WRED to run on queues whose limits dynamically expand and contract, use the percent keyword when you configure thresholds in a drop profile. For example:
host1(config)#drop-profile internetDropProfile host1(config-drop-profile)#average-length-exponent 9 host1(config-drop-profile)#committed-threshold percent 30 90 4 host1(config-drop-profile)#conformed-threshold percent 25 90 5 host1(config-drop-profile)#exceeded-threshold percent 20 90 6
112
Drop Profiles
Figure 9: WRED and Dynamic Queue Thresholding
Drop %
Queue Queue limits
Region 0
Maximum threshold
Drop %
1 Queue limits
Drop %
2 Queue limits
Drop %
3 Queue limits
Drop %
4 Queue limits
Drop %
5 Queue limits
Drop %
6 Queue limits
Drop %
7 Queue limits
Drop %
Queue limits
All packets dropped
g013613
Drop Profiles
113
Scheduler Profiles
The egress line module scheduler is an HRR scheduler. Figure 10 is an example of a QoS schedulers hierarchy.
Figure 10: QoS Scheduler Hierarchy
Besteffort traffic class
Lowloss I traffic class
Lowloss I traffic class
Lowlatency I traffic class
Lowlatency II traffic class
Lowlatency I traffic class
Lowlatency II Queues/traffic classes traffic (Buffer management) class Scheduler level 3
ATM 2/0.1
ATM 2/0.2
ATM 2/0.1
ATM 2/0.2
Scheduler level 2 (Bandwidth management)
(Default group)
Strict-priority group
Scheduler level 1
ATM 2/0 port
As shown in Figure 10, the queues feeding a physical port are organized in a hierarchy. At each level in the hierarchy, the scheduler uses shaping rates, hierarchical or assured rates, and relative weights to determine the allocated bandwidth:
! !
The scheduler selects a first-level node based on the allocated bandwidth. The scheduler then selects a second-level node from the group of nodes that are stacked above the selected first-level node. This selection is also based on the allocated bandwidth. Finally, the scheduler selects a queue from the group of queues stacked above the second-level node.
The scheduler supports hierarchical and static assured rates, relative weights, and shaping rates on all three levels of the hierarchy: first-level node, second-level node, and queue. The bandwidth delivered from a given node or queue is a function of the shaping rate and either the assured rate or relative weight:
!
When the scheduler is not congested, the shaping rates determine which node or queue can claim the bandwidth. The shaping rate specifies the maximum bandwidth to the node or queue.
114
Scheduler Profiles
g014334
When the scheduler is congested, either the hierarchical or static assured rate or the weight specifies the minimum bandwidth.
!
If the scheduler is configured to use a static assured rate and the assured rate is other than none (the default), it is used to determine the allocated bandwidth, and the weight setting is ignored. If the assured rate is zero, the weight setting is used to determine the bandwidth. The static assured rate specifies the desired bandwidth. This rate is guaranteed until the bandwidth becomes oversubscribed.
If the scheduler is configured to use hierarchical assured rate, the scheduler dynamically adjusts the amount of allocated bandwidth for service delivery based on the sum of the assured rates of all child nodes and queues. For a description of hierarchical assured rate (HAR), see Hierarchical Assured Rate on page 115. The assured rate also specifies that if bandwidth is over- or undersubscribed, all adjustments are made in proportion to the original assured-rate specification.
For example, if Node A is configured to receive 40 Mbps and Node B receives 20 Mbps, any available bandwidth above the subscribed total of 60 Mbps would be allocated to the two nodes at the same 2-to-1 ratio. Similarly, if the bandwidth were oversubscribed and only 30 Mbps were available, this amount would also be allocated to the two nodes at the 2-to-1 ratio, with Node A getting 20 Mbps and Node B getting 10 Mbps.
NOTE: For E-series ASIC modules, strict priority is supported only for a single first-level scheduler node.
Hierarchical Assured Rate

The JUNOSe hierarchical assured rate (HAR) feature provides a more powerful and efficient method of configuring assured rates than static assured rates. When you use static assured rates, a queue is guaranteed to receive its assured rate only when its parent node is configured with an assured rate that equals the sum of all its child assured rates. Therefore, to ensure that a queue receives its specified assured rate, you must frequently recalculate the assured rates on all parent nodes in the queues hierarchy. This recalculation is necessary because of the number of scheduler nodes and queues that may be dynamically created or deleted through applications such as bandwidth-on-demand. Eventually, this complicated manual recalculation process becomes unreasonable and virtually impossible. HAR replaces the manual recalculation process by directing the router to dynamically calculate the assured rate for a scheduler node based on the sum of the assured rates of all its child nodes and queues. For example, you might use HAR to increase the effective weight of an ATM-VC scheduler node when a video queue is created, and to later restore the effective rate of the node when the video queue is deleted.
Scheduler Profiles
115
HAR is applicable only to level 1 and level 2 scheduler nodes, and is not applicable to queues or ports. When you configure HAR, the changes take place immediately. When you disable HAR, the scheduler nodes previous weight is restored. Figure 11 shows an application of HAR for VC nodes. In the example, VCs, which are configured for HAR, are stacked over virtual path (VP) nodes. The VP nodes are in turn stacked over an OC-3 ATM port. Each VC has a best-effort data queue, which currently has an assured rate of 20 Kbps. The VCs share equal portions of their parent VP's bandwidth. However, when the video queue is added to VC2, HAR enables VC2's share of the VP bandwidth to increase in proportion to the 1-Mbps video queue that was created. The bandwidth of sibling VC nodes, which have only a data queue, is decreased in equal proportions.
Figure 11: Hierarchical Assured Rate
Best-effort data AR = 20 Kbps Best-effort data AR = 20 Kbps Video AR = 1 Mbps Best-effort data AR = 20 Kbps
VC1
VC2
VCn
VP
VP
VP
OC3
Configuring Scheduler Profiles

To configure a scheduler profile, perform the following steps: 1. Create a scheduler profile, and enter Scheduler Profile Configuration mode.
host1(config)#scheduler-profile sp-1mbs host1(config-scheduler-profile)#
2. (Optional) Set the shaping rate of the scheduler node or queue in bits per second.
host1(config-scheduler-profile)#shaping-rate 128000
3. (Optional) Set the effective weight of the scheduler node or queue; you can set the HRR weight, a static assured rate, or an HAR.
host1(config-scheduler-profile)#assured-rate 56000
116
Scheduler Profiles
g013391
4. (Optional) Set strict-priority scheduling.

host1(config-scheduler-profile)#strict-priority NOTE: If you configured traffic shaping through traffic shape profiles in JUNOSe releases before 4.0, traffic shaping is replaced with the rate-shaping feature, which is configured when you configure a scheduler profile.
assured-rate
!
Use to set the assured rate of the scheduler node or queue. If the assured rate setting is other than none (the default), then the assured rate is used instead of the HRR weight setting for the scheduler node or queue. Use the hierarchical keyword to specify that the HAR is used for scheduler nodes (HAR is not used for queues or ports). HAR dynamically adjusts the available bandwidth for a scheduler node based on the creation and deletion of other scheduler nodes. Example
host1(config-scheduler-profile)#assured-rate hierarchical
For a static assured rate, specify the bits per second value in the range 250001000000000 bps (25 Kbps to 1 Gbps); the default is none (no assured rate). Example
host1(config-scheduler-profile)#assured-rate 128000
Use the no version to delete the assured rate and revert to using the HRR weight specification.
scheduler-profile
!
Use to configure a scheduler profile and enter Scheduler Profile Configuration mode. The router supports up to 1,000 scheduler profiles. Example
! !
Use the no version to remove the scheduler profile.
shaping-rate
! !
Use to set the shaping rate of the scheduler node or queue in bits per second. Shaping rate range is 640001000000000 bps (64 Kbps to 1 Gbps); default is no shaping rate. The router rounds the rate to the next higher 8 Kbps. Burst is the catch-up number associated with the shaper; the range is 0522240. Specifying 0 enables the router to select an applicable default value.
Scheduler Profiles
117
Example
host1(config-scheduler-profile)#shaping-rate 128000 burst 32767
Use the no version to delete the shaping rate.
strict-priority
! !
Use to set strict-priority scheduling for the scheduler node. Example

host1(config-scheduler-profile)#strict-priority
Use the no version to delete the strict-priority setting.
weight
! !
Use to set the HRR weight of the scheduler node or queue. The weight value is in the range 04080. Weight 0 (zero) is a special weight used for relative strict-priority scheduling, which is discussed in Relative Strict-Priority Scheduling on page 184. The weight value is used when there is no assured rate set. Example
host1(config-scheduler-profile)#weight 8
Use the no version to return to the default weight, 8.
Shared Shaping
In the JUNOSe QoS implementation, you configure a traffic-class group to create a separate scheduler hierarchy. Traffic classes in a traffic-class group are queued through a scheduler hierarchy dedicated to that group. QoS supports up to five user-configurable, named traffic-class groups. Traffic classes that do not belong to any named group are considered to belong to the default traffic-class group. With the factory default configuration, the best-effort traffic class is in the default traffic-class group. Shared shaping is a mechanism for shaping a logical interface's aggregate traffic to a rate when the traffic for that logical interface is queued through more than one scheduler hierarchy. For example, a service provider may configure QoS for voice, video, and data traffic on a single ATM VC. The video traffic and the voice traffic are placed in separate scheduler hierarchies from the data traffic to provision the low latency that is required for voice traffic and the higher bandwidth that is required for video traffic. In this scenario, the data traffic needs to be dynamically shaped so that its rate matches the bandwidth available after the voice and video bandwidth requirements are met. When less voice and video traffic is being forwarded, then the data traffic should expand to fill the line rate. Shared shaping is typically enabled on the access-facing line module, but you can enable the feature for any interface type recognized by QoS, on any line module and any JUNOSe router.
118
Shared Shaping
Sharing Bandwidth with the SAR

On ATM line modules, providers can use the SAR to implement bandwidth sharing for VCs. When the SAR is operating in default mode (that is, when the no qos-mode-port command is in effect), the SAR backpressures the VC node in the default traffic-class group, but traffic that is queued through a named traffic-class group is unaffected by VC backpressure. In the absence of voice and video traffic, the VC runs data traffic at the shared rate. When voice and video traffic start streaming, the SAR backpressures just the VC node in the default traffic-class group, thus sharing the bandwidth. However, providers need to configure shared shaping on more than just ATM VCs. The SAR cannot support shared shaping per virtual path on ATM, and there is no SAR on Ethernet line modules. The shared shaper implemented in the HRR scheduler can support shared shaping for all these different configurations.
How Shared Shaping Works

You can configure the shared-shaping rate on either the best-effort scheduler node or the best-effort queue for the logical interface. If you specify shared shaping for the best-effort node, the shared shaper is said to be node controlled. If you specify shared shaping for the best-effort queue, the shared shaper is said to be queue controlled. The router locates the queues in named traffic-class groups that are associated with the logical interface and shapes that set of queues to the shared rate. The shared-shaping rate is the total bandwidth for the logical interface. A typical configuration places the low-latency voice traffic in the auto-strict-priority traffic-class group and video traffic in a separate extended traffic-class group. The data traffic is usually queued in the best-effort traffic class in the default traffic-class group. Two types of shared shaping are available, depending on your hardware. Simple shared shaping can shape the best-effort node or queue associated with a logical interface to a shared rate. Compound shared shaping is a hardware-assisted mode that controls bandwidth for all scheduler objects associated with the subscriber logical interface. The constraints of both the legacy hierarchical scheduler and the shared shaper affect the bandwidth of scheduler objects. The shared shaper limits the bandwidth even when the port or VP is not congested. When the port or VP is congested, the legacy scheduler is dominant. For example, when a heavily oversubscribed VP becomes congested, the legacy hierarchical scheduler may limit the VP bandwidth to a lower rate, so that shared shaping of excess bandwidth is moot.
Simple Shared Shaping

Simple shared shaping shapes the best-effort node or queue associated with a logical interface to a shared rate. Once per second, the simple shared shaper calculates the combined rate of the voice and video queues for the logical interface, and shapes the best-effort queue for the data traffic to the shared rate minus the video and voice queue rates. The bandwidth for the voice and video queues is determined by the configuration of the hierarchical scheduler. The shared shaper does not actively manage the video and voice queues.
Shared Shaping
119
Simple Shared Shaping Example

In Figure 12, the AF traffic-class group contains the video traffic class. The EF traffic-class group contains the voice traffic class. The best-effort traffic class remains outside any traffic-class group. Because the voice, video, and data queues are stacked in separate scheduler hierarchies, you must use the shared shaper to shape the logical interface aggregate to a single rate. In this example, VC 1 is configured for voice and data. VC 2 is configured for data and video. VC 3 is configured for data, voice, and video. The shared shaper is configured on the best-effort node or queue for VC 1; the corresponding voice queue for VC 1 shares the configured rate.
Figure 12: Simple Shared Shaping
Voice TC voice Voice TC voice Video TC video Video TC video
Data TC best-effort
Data TC best-effort
Data TC best-effort VC 1 Group EF VC 3 Group EF VC 2 Group AF VC 3 Group AF
VC 1 Default group
VC 2 Default group
VC 3 Default group
Group EF
Group AF
TC = traffic class Group = traffic-class group = best-effort scheduler node for VC 2 Port = logical interface
Simple Shared Shaping on the Best-Effort Scheduler Queue

If you configure shared shaping for the best-effort queue, the shared shaper is queue controlled. Node-controlled shared shaping is generally preferable for the following reasons:
!
With this configuration, the legacy scheduler can still allocate bandwidth to queues above the best-effort node based on their relative weights. Queues stacked above the best-effort node will still be shaped, even if they are for interfaces stacked above the shared shaper logical interface. For ATM in low-CDV mode, the shared-shaping rate for ATM VCs and VPs is also applied in the SAR.
120
Shared Shaping
g014335
Port
Simple Shared Shaping on the Best-Effort Scheduler Node

If you have a second traffic class for data in addition to the best-effort data traffic class, you should configure shared shaping on the best-effort scheduler node. This is known as node-controlled shared shaping. In this scenario, two weighted queues are stacked above the best-effort scheduler node, one for the best-effort traffic class and the other for the second data traffic class. If you configure the shared-shaping rate on the best-effort queue, then the shared shaper may have a tendency to starve the best-effort queue in favor of the second data queue. If you instead configure the shared-shaping rate on the best-effort node, the hierarchical scheduler will allocate bandwidth between multiple data queues based on their relative weight and assured rate. If you are configuring VP shared shaping, you should configure shared shaping on the best-effort scheduler node for the VP. Shaping the best-effort scheduler node for the VP has the effect of shaping all the VC best-effort queues for that VP. This enables you to retain the advantages of per-VC queuing in the hierarchical scheduler. If you are configuring VC shared shaping and the SAR is operating in low-CDV mode, you generally should configure the shared-shaping rate on the best-effort scheduler node for the VP or VC. The router sets the SAR shaper for the VC or VP to match the shared-shaping rate on VC and VP nodes in the hierarchical scheduler; this is usually the desired behavior. A shared shaper configured on the best-effort queue does not trigger the matching shaper in the SAR.
Shared Shaping and Low-CDV Mode

JUNOSe releases before 6.0.0 implemented a carve-out scheduling model. If you configured multiple scheduler nodes for a VC or VP, the router added together the shaping rates for each scheduler node and shaped the corresponding VC or VP tunnel in the SAR to the sum of the rates. This implementation forced a strict-priority carve-out model for a logical interface, because the best-effort traffic cannot share unused bandwidth from the strict-priority traffic-class group. Beginning with the JUNOSe 6.0 release, the router synchronizes the SAR rate for a VC or VP to the shared-shaping rate for the best-effort scheduler node for the VC or VP, so that the default behavior for low-CDV mode becomes shared shaping. Applying shared shaping to the best-effort queue does not synchronize the rate for the corresponding VC or VP in the SAR. JUNOSe releases before 6.1.0 had a different behavior when multiple traffic-class groups were configured in low-CDV mode. In those releases, the shaping rates of the VC nodes in each group were added together, and the corresponding VC queue in the SAR was shaped to the sum. The same algorithm was used for shaping VP tunnels in the SARthe shaping rates of all VP nodes in the hierarchical scheduler were added together to shape the VP tunnel in the SAR. This behavior implements a carve-out model for scheduling into VPs and VCs and generally is not as desirable as the shared shaping model supported in JUNOSe 6.1.0 and higher releases. Beginning with JUNOSe 6.1.0, low-CDV mode causes SAR shaping of VCs and VPs only when you specify the shared-shaping-rate command for the best-effort VC or VP node in the HRR scheduler.
Shared Shaping
121
Compound Shared Shaping

Compound shared shaping is a hardware-assisted mode that can control bandwidth for all scheduler objects associated with the subscriber logical interface. Thus it can manage voice and video queues in addition to data queues, so that the shared rate cannot be exceeded. Compound shared shaping can shape scheduler nodes in addition to scheduler queues. This capability makes it possible to implement hierarchical shared shaping by configuring shared shaping on VP nodes and simultaneously configure shared shaping for the VC queues stacked above the node. Compound shared shaping responds to changes in traffic rates more rapidly than simple shared shaping, on the order of milliseconds. If you configure a compound shared shaper on hardware that does not support it, the CLI displays the following message:
host1config)#ERROR 02/08/2005 14:06:36 qos: line card in slot 11: EFA2 hardware not installed. 1 compound shared shaper(s) converted to simple.
QoS automatically converts the erroneously configured compound shared shaper to a supported simple shared shaper.
Shared Shaping Constituents

When you specify a shared-shaping rate on a best-effort node or queue, QoS shapes the aggregate of traffic for the logical interface that owns the best-effort queue or node. QoS locates the queues and nodes owned by that logical interface and applies the shared shaper to them. The nodes and queues owned by the interface are called the constituents of the shared shaper instance. For example, if the logical interface type is VC, the constituents are all VC objects: VC nodes and VC queues. A shared-shaping rule in a profile can apply to up to eight constituents. Active constituents are those that are actively controlled by the shared shaper mechanism. Inactive constituents are those that are not controlled. For example, when ATM VC queues are stacked above an ATM VC node, the ATM VC node might be an active constituent. In this case, the queues stacked above the node are shaped to the shared rate indirectly by the hierarchical scheduler, making the queues inactive constituents of the shared shaper. If the ATM VC queues are the active constituents, then the ATM VC node is inactive. Shared shaping supports both implicit and explicit constituent selection. Implicit constituent selection is the easier of the two methods and works well for most cases. With implicit selection, you configure a shared-shaping rate on the best-effort node or queue and QoS locates the other constituents automatically. The mechanism that determines which constituents are considered active differs for simple and compound shared shapers. Generally, simple implicit shared shapers activate the queues in named traffic-class groups, but compound implicit shared shapers activate the nodes in the named groups.
122
Shared Shaping
Explicit selection is important if you want to shape a subset of the interface traffic to the shared rate. An example of this is when you want the sum of best-effort and voice traffic to be shaped to the shared rate, but want video traffic to be exempt from the shared shaping rate. Active constituents are selected either implicitly by QoS or explicitly by the user. Active constituents of the simple shared shaper can be the best-effort node and any queues in named traffic-class groups. A node that is not a best-effort node cannot be an active constituent of the simple shared shaper. If you choose the best-effort node as an active constituent, queues above that node are not active constituents. Active constituents of the compound shared shaper can be nodes or queues. If you choose a node as an active constituent, queues above it are not active constituents. Inactive constituents are queues that are stacked above an active node or nodes stacked below active queues. For both of these situations, the shared shaper controls the active constituents, and the legacy scheduler indirectly controls the inactive constituents to achieve the shared rate. The other case for inactive constituents is when you use explicit constituent selection and some of the nodes and queues are explicitly not included in the shared shaper. To use implicit constituent selection, you specify only the shared-shaping rate and the logical interface. The router identifies the constituents associated with the logical interface type and their allocated bandwidth. This method is appropriate for the mainstream case where the intent is to shape all subscriber queues to the shared rate. For more information and examples about implicit selection, see Implicit Constituent Selection on page 124. If you want instead to shape a subset of the queues for a subscriber to the shared rate, the explicit selection process is appropriate. Explicit selection is also useful when you want queues as the active constituents instead of the node below them. By choosing queues you can assign appropriate priority or weights. For more information and examples about explicit selection, see Explicit Constituent Selection on page 131.
Shared Shaping
123
Types of Shared Shapers

The shared-shaping-constituent command in a scheduler profile specifies constituents and their attributes. The command has two aspects. For explicit constituent selection, this command specifies the constituents. For the compound shared shaper only, this command specifies scheduling attributes of shared shaping: the shared priority and the shared weight. A shared shaper can be one of the following four types:
!
Simple implicitConstituents are the best-effort node or queues, and all queues in named traffic-class groups. Nodes in named groups are not constituents. The constituents in named groups are monitored but not controlled. The shared-shaping-constituent command is ignored. Simple explicitThe software selects constituents based on the shared-shaping-constituent command, but it cannot activate scheduler nodes in the named traffic-class groups. The weight and priority attributes of the shared-shaping-constituent command are ignored, because the simple shared shaper does not allocate bandwidth among constituents; instead it controls just the best-effort queue or node. Compound implicitConstituents are selected automatically by the software. If a node exists in a given traffic-class group, the node is active and the queues stacked above it are inactive constituents. The shared-shaping-constituent command does not affect constituent selection. However, if the command is present for a constituent that was implicitly selected, the software configures that constituent with the shared priority and shared weight as indicated. Compound explicitThe software selects constituents based on the shared priority and shared weight configured with the shared-shaping-constituent command. If no attributes are specified, the software supplies a shared priority consistent with the legacy scheduler configuration.
Implicit Constituent Selection

The implicit selection process for simple shared shaping operates according to the following rules: 1. The point at which the scheduler profile that contains a shared-shaping-rate command is associated with a best-effort node or best-effort queue determines the logical interface type that the shared shaper applies to. Logical interface types include IP, VP, VC, VLAN, and so on. 2. All nodes and queues for the same logical interface are potential constituents. 3. The best-effort node is selected if you configure node-based shared shaping. The best-effort queue is selected if you configure queue-based shared shaping. If you configure both, then the best-effort node is selected over the best-effort queue. 4. Non-best-effort queues are selected.
124
Shared Shaping
The implicit selection process for compound shared shaping operates according to the following rules: 1. The point at which the scheduler profile that contains a shared-shaping-rate command is associated with a best-effort node or best-effort queue determines the logical interface type that the shared shaper applies to. Logical interface types include IP, VP, VC, VLAN, and so on. 2. All nodes and queues for the same logical interface are potential constituents. 3. Nodes are selected over queues. For example, suppose a shared shaper is associated with a particular interface type. A node for that interface type is present and has a queue for that interface type stacked above it. The node is selected and becomes an active constituent; the queue is not selected. Now suppose a shared shaper is associated with a logical interface at the best-effort node, and a second shared shaper is simultaneously associated with the same interface at the best-effort queue, In this case, the node is selected as the constituent, because nodes are selected over queues. In Figure 13, scheduler profile A includes a shared-shaping rule, and is associated with the best-effort node for VC 2. The constituents are all the scheduler objects associated with VC 2: VC 2 nodes and VC 2 queues. Nodes are selected over queues, so the implicitly selected active constituents are the VC 2 default group node, the VC 2 Group EF node, and the VC 2 Group AF node.
Figure 13: Implicit Constituent Selection for Compound Shared Shaper at Best-Effort Node
Data TC best-effort
Data TC best-effort
Data TC best-effort VC 1 Group EF VC 3 Group EF VC 2 Group AF VC 3 Group AF
A
VC 1 Default group VC 2 Default group
VC 3 Default group
Group EF
Group AF
A = scheduler-profile a shared-shaping-rate 1000000
g014387
TC = traffic class Group = traffic-class group = best-effort scheduler node for VC 2 Port = logical interface
Port
Shared Shaping
125
In Figure 14, scheduler profile B is associated with the best-effort queue for VC 3. This association indicates that the logical interface type being shared is VC. The constituents are all the scheduler objects associated with VC 3: VC 3 nodes and VC 3 queues. Nodes are selected over queues, so the implicitly selected active constituents for profile Bs shared shaper are the VC 3 default group queue, the VC 3 Group EF node, and the VC 3 Group AF node. The VC 3 default group queue is selected instead of the VC 3 default group node because the shared shaper is associated with that best-effort queue.
Figure 14: Implicit Constituent Selection for Compound Shared Shaper at Best-Effort Queue
Data TC best-effort
Data TC best-effort
Data TC best-effort
*
VC 1 Default group VC 2 Default group VC 3 Default group
VC 1 Group EF
VC 3 Group EF
VC 2 Group AF
VC 3 Group AF
B
Group EF Group AF
TC = traffic class Group = traffic-class group = best-effort scheduler queue for VC 3 Port = logical interface
B = scheduler-profile b shared-shaping-rate 1000000
126
Shared Shaping
g014388
Port
Figure 15 illustrates some other examples of implicit constituent selection. It does not reflect typical configurations, but includes a mixture of interface types: IP, VC, and VP. If only scheduler profile A is applied, the associated interface is VC 1. The selected constituents then consist of the VC 1 best-effort node, the VC 1 TC voice queue, and the VC 1 TC video queue. If instead only scheduler profile B is applied, the associated interface is IP 1. The selected constituents then consist of the IP 1 best-effort queue, the IP 1 TC voice queue, and the IP 1 TC video queue. Finally, if only scheduler profile C is applied, the associated interface is VP 1. The selected constituents then consist of the VP 1 default group node, the VP 1 Group EF node, and the VP 1 Group AF node.
Figure 15: Implicit Constituent Selection for Compound Shared Shaper: Mixed Interface Types
IP 1 TC best-effort VC 1 TC data VC 2 TC best-effort VC 3 TC best-effort IP 1 TC voice VC 1 TC voice VP 1 TC voice IP 1 TC video VC 1 TC video
*
A
B
VC 1 best effort VC 2 best effort VC 3 best effort VP 1 Group EF VP 1 Group AF
VP 1 Default group
Group EF
Group AF
C
Port
Implicit Bandwidth Allocation for Compound Shared Shaping

After selecting the implicit constituents for compound shared shaping, the router places the constituents in an order that determines how the constituents can claim a share of the available shared bandwidth. The compound shared shaper mechanism actively allocates the bandwidth it receives from the hierarchical scheduler to each active constituent, based on its own rules, independent of the hierarchical scheduler. Constituents are either priority constituents or weighted constituents. These attributes are specified either explicitly, using the shared-shaper-constituent command, or implicitly.
g014389
TC = traffic class Group = traffic-class group = best-effort scheduler queue for IP 1 Port = logical interface
A = scheduler-profile a shared-shaping-rate 1000000 B = scheduler-profile b shared-shaping-rate 1000000 C = scheduler-profile c shared-shaping-rate 1000000
Shared Shaping
127
Compound shared shaper scheduling allocates bandwidth as follows. Priority constituents consume as much of the shared bandwidth as they can, subject to the bandwidth allocated to them by the hierarchical scheduler. Priority constituents are ordered according to their priority. The weighted constituents subdivide the remaining shared bandwidth in proportion to their shared weights, again subject to the bandwidth allocated to them by the hierarchical scheduler. When it implements compound implicit shared shapers, the software selects attributes for the active constituents consistent with the hierarchical scheduler. Auto-strict nodes and queues have the highest priority. Nodes and queues in extended traffic-class groups are next. Nodes and queues in the default traffic-class group have the lowest priority. For example, suppose a compound shared shaper has a rate of 2 Mbps. The shared shaper has three active constituents: the best-effort node, a voice queue in the auto-strict traffic-class group, and a video queue in an extended traffic-class group. For compound implicit shared shaping, the shared shaper assigns the voice queue all the 2MB, the video queue the next priority, and the best-effort node the last priority. The voice queue is unlikely to drop because it has highest priority in the hierarchical scheduler as well as highest priority within its shared shaper. The video queue is less likely to drop, but you must still take care that the hierarchical scheduler is provisioned to allocate the proper assured bandwidth to video. The shared shaper can shape, or deny, bandwidth to its constituents, but it cannot allocate assured bandwidth in the hierarchical scheduler. Another view of the compound shared shaper mechanism is the following. In the legacy scheduler, weight and shaping rate are independent attributes that together determine bandwidth allocation. The scheduler allocates bandwidth based on relative weights, and the shaper can deny that bandwidth when the shaping rate is reached. With the shared shaper in effect, there are two independent shaping rates that must be satisfied in order for the queue or node to dequeue. A deficit in either type of shaping will bound the bandwidth. As a general way of predicting the scheduler behavior, if the physical port is congested because there are many queues and nodes competing in the hierarchical scheduler, the legacy weights and shaping rates will dominate the scheduler outcome. If the hierarchical scheduler is not congested, a shared shaper configured for a logical interface will dominate the outcome for the traffic scheduled through that logical interface. The compound shared shaper orders constituents, and allocates shared bandwidth to them, according to the following rules: 1. Strict constituents in the auto-strict-priority traffic-class group, For multiple strict-priority traffic-class groups, bandwidth allocation order is the same order in which the additional strict traffic class groups were configured. You can issue the show traffic-class-groups command to view this order. 2. Strict constituents in extended traffic-class groups, For multiple extended traffic class groups, bandwidth allocation order is the same order in which the traffic class groups were configured. You can issue the show traffic-class-groups command to view this order.
128
Shared Shaping
3. Strict constituents in the default group. 4. Weighted constituents in the auto-strict-priority traffic class group. 5. Weighted constituents in extended traffic class groups. 6. Weighted constituents in the default group. Strict constituents transmit traffic at a rate up to the lesser of their shared-shaping rate or the legacy shaping rate. This behavior is the default. Individual strict constituents can be allocated any bandwidth value less than the shared rate. The sum of all constituent rate credits does not have to be less than the shared rate. Individual constituent rates are not capped, because it is often the case that a particular traffic class won't exceed a limit because of admission control, or because the class is policed at some point in the path. Unlike strict constituents, which can consume bandwidth up to the legacy shaping rate or the shared-shaping rate, weighted constituents share bandwidth with their peers solely in proportion to their shared-shaping-weight. A higher weight value grants the constituent a greater proportion of the available bandwidth. Although a shared shaper can be applied to up to eight constituents, only four of these can be weighted constituents. If you configure more than four weighted constituents as part of the same shared shaper, the first four are treated as weighted constituents but the remainder are handled as strict constituents, generating a warning message. Weighted Compound Shared Shaping Example Weighted shared shaping is most useful for sharing bandwidth between traffic classes carrying TCP data. Figure 16 shows an application of weighted shared shaping where weighted constituents span multiple traffic class groups, making them ineligible for legacy weighted scheduling. Best-effort data and premium data constituents are weighted.
Shared Shaping
129
Figure 16: Weighted Shared Shaping

Data TC best-effort Data TC best-effort Voice TC voice Voice TC voice Data Data TC premium data TC premium data
A
VC 1 best effort VC 2 best effort VC 1 Group EF VC 2 Group EF
B
VC 1 Group AF VC 2 Group AF
Group EF
Group AF
TC = traffic class Group = traffic-class group Port = logical interface
Port
A = scheduler-profile a shared-shaping-rate 1000000 shared-shaping-constituent weight 1 B = scheduler-profile b shared-shaping-constituent weight 31
Scheduler profile A specifies the shared-shaping rate of 1Mbps for the best-effort node, which is associated with a VC logical interface. The node is further configured with a weight of 1. Scheduler profile B specifies the VC 1 AF node as a weighted constituent with a weight of 31. The implicitly selected constituents of the shared shaper are the VC 1 best-effort node, the VC 1 AF group node, and the VC 1 EF group node. Bandwidth is allocated as follows:
!
The VC 1 EF group node is strict and can transmit up to the shared-shaping rate of 1Mbps. Any remaining bandwidth is available to the remaining constituents. The VC 1 AF group node is weighted with the VC 1 best-effort node. The sum of the constituent weights is 32. With a weight of 31, the VC 1 AF group node can transmit 31/32nds of the available bandwidth when both constituents are competing for bandwidth. The VC 1 best-effort node is weighted with VC 1 AF group node. The sum of the constituent weights is 32. With a weight of 1, the VC 1 best-effort node can transmit 1/32 of the available bandwidth when both constituents are competing for bandwidth.
130
Shared Shaping
g014388
Explicit Constituent Selection

If you want only a subset of the queues for a subscriber to be shaped to the shared rate, then you must explicitly identify the desired constituents rather than accepting the implicitly selected constituents. For compound shared shaping, explicit selection is also useful when you want queues as the active constituents instead of the node below them. By choosing queues you can assign appropriate priority or weights. In the set of nodes and queues for a logical interface, only scheduler objects associated with a scheduler profile that includes a shared-shaping-constituent command are considered constituents. Objects that are not explicitly selected are exempt from the shared shaper. To identify the constituents for simple shared shaping, include the explicit-constituents keyword with the shared-shaping-rate simple command in a scheduler profile that you associate with a best-effort node or queue to identify the logical interface. For compound shared shaping, omit the simple keyword. For a compound shared shaper, you can further designate the explicit constituents as strict or weighted. Table 18 compares implicit and explicit shared shaping.
Table 18: Comparison of Implicit and Explicit Shared Shaping Implicit Shared Shaping
! To specify the logical interface for shared
Explicit Shared Shaping

! To specify the logical interface for shared
shaping, associate a scheduler profile that includes the shared-shaping-rate command or the shared-shaping-rate simple command with a best-effort node or queue
shaping, associate a scheduler profile that includes the shared-shaping-rate rate explicit-constituents command or the shared-shaping-rate rate simple explicit-constituents command with a best-effort node or queue
! Constituents consist of all nodes and queues
! Constituents consist of all nodes and queues
for the same logical interface type.

! Active constituents are automatically
for the same logical interface type.

! Active constituents are explicitly selected
selected from all constituents according to the implicit shared shaping rules.
from all constituents by association with a scheduler profile that includes the shared-shaper-constituent command.
! If the scheduler profile associated with a
constituent does not include this command, then the constituent is not active and is not shaped by the shared shaper.
Shared Shaping
131
Explicit Shared Shaping Example

In Figure 17, two scheduler profiles are applied to scheduler objects VC 1 best effort node, VC 1 AF node, and VC 1 EF node. The shared-shaping-constituent command in each profile specifies that the associated object is an explicit constituent of the shared shaper.
Figure 17: Explicit Constituent Selection
Data TC best-effort Data TC best-effort Voice TC voice Voice TC voice Video TC video Video TC video
A
VC 1 best effort VC 2 best effort VC 1 Group EF VC 2 Group EF
B
Group EF
Group AF
Port
g014386
A = scheduler-profile a shared-shaping-rate 1000000 compound explicit-constituents shared-shaping-constituent B = scheduler-profile b shared-shaping-constituent
In this example, the VC shared shaper has two explicit constituents, the VC 1 best effort node and the VC 1 Group EF node. By default, these constituents are considered to be strict constituents with a priority of 8. If implicit selection rules were followed in this example, the association of the shared shaper with the VC 1 best-effort node would have selected the VC 1 best effort node, the VC 1 Group EF node, and the VC 1 Group AF node.
132
Shared Shaping
Explicit Weighted Compound Shared Shaping Examples

Figure 18 illustrates a case where scheduler profiles A, B, C, D and E are applied to scheduler objects.
Figure 18: Case 1: Explicit Constituent Selection with Weighted Constituents
VLAN 1 VLAN 2 VLAN 2 VLAN 1 TC voice1 TC voice2 TC voice1 TC voice2 VLAN 1 VLAN 1 TC best-effort TC data VLAN 2 VLAN 2 TC best-effort TC data
VLAN 1 TC video
VLAN 2 TC video
VLAN 1 Group BE
VLAN 1 Group EF VLAN 2 Group BE
VLAN 2 Group EF VLAN 1 Group AF
E
VLAN 2 Group AF
Default group
Group EF
Group AF
Port A = scheduler-profile a shared-shaping-rate 1000000 compound explicit-constituents shared-shaping-constituent weight 1 B = scheduler-profile b shared-shaping-rate 1000000 compound explicit-constituents shared-shaping-constituent weight 3 C = scheduler-profile c shared-shaping-constituent weight 2 D = scheduler-profile d shared-shaping-constituent weight 4 E = scheduler-profile e shared-shaping-constituent weight 3
In Case 1, scheduler profile A associates the shared-shaping rate with the VLAN 1 best-effort queue. Table 19 lists the explicit constituents of the shared shaper and the bandwidth allocated to each constituent:
Table 19: Bandwidth Allocation for Case 1 Explicit Constituents Explicit Constituent
VLAN 1 TC voice1 queue VLAN 1 TC voice2 queue VLAN 1 TC video queue VLAN 1 TC data queue VLAN 1 TC best-effort queue
Bandwidth Allocation
Strict constituent that can consume up to its legacy shaping-rate or the shared-shaping rate. Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 4/10. Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 3/10. Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 2/10. Weighted constituent that shared bandwidth with weighted shared shaper siblings in a proportion of 1/10.
g014384
Shared Shaping
133
Figure 19 illustrates another case where scheduler profiles B, X, Y, and Z are applied to scheduler objects. Each profile assigns a weight to an explicit constituent.
Figure 19: Case 2: Explicit Constituent Selection with Weighted Constituents
VLAN 1 VLAN 1 VLAN 2 VLAN 2 TC voice1 TC voice2 TC voice1 TC voice2 VLAN 1 VLAN 1 TC best-effort TC data VLAN 2 VLAN 2 TC best-effort TC data
VLAN 1 TC video
VLAN 2 TC video
VLAN 1 Group BE
VLAN 1 Group EF VLAN 2 Group BE
VLAN 2 Group EF VLAN 1 Group AF
Z
VLAN 2 Group AF
Default Group
Group EF
Group AF
Port B = scheduler-profile b shared-shaping-rate 1000000 compound explicit-constituents shared-shaping-constituent weight 3 X = scheduler-profile x shared-shaping-constituent weight 2 Y = scheduler-profile y shared-shaping-constituent weight 4 Z = scheduler-profile z shared-shaping-constituent weight 3
In Case 2, scheduler profile B associates the shared-shaping rate with the VLAN 1 best-effort queue. Table 20 lists the explicit constituents of the shared shaper and the bandwidth allocated to each constituent:
Table 20: Bandwidth Allocation for Case 2 Explicit Constituents Explicit Constituent
VLAN 1 TC voice1 queue VLAN 1 TC voice2 queue VLAN 1 TC video queue VLAN 1 TC best-effort node
Bandwidth Allocation
Strict constituent that can consume up to its legacy shaping-rate or the shared-shaping rate. Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 4/10. Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 3/10. Weighted constituent that shared bandwidth with weighted shared shaper siblings in a proportion of 3/10.
134
Shared Shaping
g014383
Simple Shared Shaping Configuration Examples

Configure the shared shaper by specifying a shared-shaping rate for either the best-effort queue or the best-effort scheduler node for the logical interface. The router locates the other queues associated with the logical interface and shapes that set of queues to the shared rate. You do not explicitly specify shared shaping on the other queues for the logical interface. You can configure individual shaping rates on the other queues that are less than the shared rate. These individual shapers have the effect of reserving some of the shared bandwidth for the other queues. shared-shaping-rate
! !
Use to set shared-shaping rate and burst size for the logical interface. To configure the shared shaping feature, this command must appear in the scheduler profile for either the best-effort queue or the best-effort scheduler node. You can specify simple to shape data queue rates to the the value of the shared rate minus the combined voice and video traffic rate. By default, shared shaping is set to auto. In this mode, the router selects the type of shared shaping that is applied according to the type of line module. Compound shared shaping is hardware-dependent. If you specify compound for line modules that do not support it, an error message is generated and the router applies simple shared shaping. The explicit-constituents keyword overrides automatic selection of compound shared-shaping constituents and enables you to explicitly specify constituents and bandwidth allocation. This keyword does not apply to simple shared shaping. If you issue the keyword for modules that do not support compound shared shaping, the CLI generates an error message and the keyword has no effect. The range for the shared-shaping rate is 64000100000000 bps (64 Kbps1 Gbps); the default is no shaping rate. Burst is the catch-up number associated with the shaper; the range is 0522240 (0510 KB). You can specify 0 to enable the router to select an applicable default value. Example
host1(config-scheduler-profile)#shared-shaping-rate 128000 burst 32767 simple
Use the no version to delete the shared-shaping rate.
Shared Shaping
135
VC Simple Shared Shaping Example

The following commands configure a simple shared shaper for a VC, as shown in Figure 12 on page 120. In this example, the best-effort queue for logical interface VC 3 is shaped to a shared rate of 1 Mbps. The voice and video queues for VC 3 share the 1 Mbps with the best-effort traffic. The voice queue has first claim on the shared 1 Mbps, but only up to its individual shaping rate of 200 Kbps. The video queue claims up to the next 300 Kbps. The best-effort queue obtains whatever bandwidth remains of the 1 Mbps after the voice and video traffic have made their claims. 1. Configure the traffic classes and traffic-class groups.
(config)#traffic-class voice (config-traffic-class)#fabric-strict-priority (config-traffic-class)#exit (config)#traffic-class video (config-traffic-class)#exit (config)#traffic-class-group EF auto-strict-priority (config-traffic-class-group)#traffic-class voice (config-traffic-class-group)#exit ((config)#traffic-class-group AF extended (config-traffic-class-group)#traffic-class video (config-traffic-class-group)#exit
2. Configure the shared shaper.

(config)#scheduler-profile 200kbps (config-scheduler-profile)#shaping-rate 200000 (config-scheduler-profile)#exit (config)#scheduler-profile 300kbps (config-scheduler-profile)#shaping-rate 300000 (config-scheduler-profile)#exit (config)#scheduler-profile shared-1mbps (config-scheduler-profile)#shared-shaping-rate 1000000 simple (config-scheduler-profile)#exit (config)#qos-profile subscriber-default-mode (config-qos-profile)#atm-vc node (config-qos-profile)#atm-vc node group AF (config-qos-profile)#atm-vc node group EF (config-qos-profile)#atm-vc queue traffic-class best-effort scheduler-profile shared-1mbps (config-qos-profile)#atm-vc queue traffic-class video scheduler-profile 300kbps (config-qos-profile)#atm-vc queue traffic-class voice scheduler-profile 200kbps (config-qos-profile)#exit
3. Delete the rule in the default port type profile that creates IP best-effort queues by default.
config)#qos-profile atm-default (config-qos-profile)#no ip queue traffic-class best-effort (config-qos-profile)#exit
136
Shared Shaping
4. Attach the profile to the ATM subinterface for VC 3.

(config)#interface atm 11/0.10 (config-subif)#qos-profile subscriber-default-mode (config-scheduler-profile)#exit
The qos-profile subscriber-default-mode command shown in this example is appropriate if you have configured the SAR to be in default mode (by issuing the no qos-mode-port command). If this QoS profile were attached in low-CDV mode, the shaper would be effective but the CDV would not be correctly bounded, because the VC will not be reshaped in the SAR. The following commands configure a QoS profile different from the one shown above. In this example, the best-effort scheduler node for VC 3 is shaped to a shared rate of 1 Mbps. The qos-profile subscriber-low-cdv-mode command is appropriate if you configure the SAR in low-CDV mode (by issuing the qos-mode-port low-cdv command). Here the VC will be reshaped to 1 Mbps in the SAR. If this QoS profile were attached in the SAR default mode, the 1-Mbps shaper would be disabled by VC backpressure from the SAR.
(config)#qos-profile subscriber-low-cdv-mode (config-qos-profile)#atm-vc node scheduler-profile shared-1mbps (config-qos-profile)#atm-vc node group AF (config-qos-profile)#atm-vc node group EF (config-qos-profile)#atm-vc queue traffic-class best-effort (config-qos-profile)#atm-vc queue traffic-class video scheduler-profile 300kbps (config-qos-profile)#atm-vc queue traffic-class voice scheduler-profile 200kbps (config-qos-profile)#exit
VP Simple Shared Shaping Example

In the example shown in Figure 20, VP 1 is shaped to a shared rate of 5 Mbps. The shared shaper requires that voice and video traffic be carried in queues associated with the logical interface, which in this scenario is the VP. VP-level queuing does not guarantee fairness to the voice and video traffic for each VC, but fairness is not a major issue because admission control guarantees that the voice and video queues will not become congested. This example assumes the same traffic class and traffic-class group configurations that were used in VC Simple Shared Shaping Example on page 136.
Shared Shaping
137
Figure 20: VP Shared Shaping

Data TC best-effort Data TC best-effort Data TC best-effort
VC 1 Default group
VC 2 Default group
VC 3 Default group
Video TC video VP 1
Voice TC voice VP 1
VP 1
Group AF
Group EF
TC = traffic class Group = traffic-class group = best-effort scheduler node for VP 1 Port = logical interface
The following set of commands configures the shared shaper in Figure 20.
(config)#scheduler-profile 2mbps (config-scheduler-profile)#shaping-rate 2000000 (config-scheduler-profile)#exit (config)#scheduler-profile 400kbps (config-scheduler-profile)#shaping-rate 400000 (config-scheduler-profile)#exit (config)#scheduler-profile shared-5mbps (config-scheduler-profile)#shared-shaping-rate 5000000 simple (config-scheduler-profile)#exit (config)#qos-profile vp-subscriber1 (config-qos-profile)#atm-vp node scheduler-profile shared-5mbps (config-qos-profile)#atm-vp node group AF (config-qos-profile)#atm-vp node group EF (config-qos-profile)#atm-vc node (config-qos-profile)#atm-vc queue traffic-class best-effort scheduler-profile default (config-qos-profile)#atm-vp queue traffic-class video scheduler-profile 2mbps (config-qos-profile)#atm-vp queue traffic-class voice scheduler-profile 400kbps (config-qos-profile)#exit
138
Shared Shaping
g014336
Port
In this example, the best-effort scheduler node for the VP is shaped to a shared rate of 5 Mbps. The EF and AF queues for the VP share the 5 Mbps with the best-effort traffic. The EF queue has first claim on the shared 5 Mbps, but only up to its individual shaping rate of 400 Kbps. The AF queue claims up to the next 2 Mbps. The VC-level best-effort queues obtain whatever bandwidth remains of the 5 Mbps after the AF traffic and EF traffic have made their claims. This QoS profile is appropriate for low-CDV mode. If the provider configures a shapeless VP tunnel in the SAR, QoS sets the SAR shaper for the VP to match the 5-Mbps shared-shaping rate, and the CDV will be bounded for the VP tunnel.
Shared Shaping and Individual Shaping

You can use both the shared-shaping-rate command and the shaping-rate command in a single scheduler profile. For example, you can shape the best-effort node or queue to accept less than the remainder of the shared-shaping rate as in the following commands:
(config)#scheduler-profile shared-1mbps (config-scheduler-profile)#shared-shaping-rate 1000000 simple (config-scheduler-profile)#shaping-rate 500000
If you configure a shaping rate higher than the shared-shaping rate, the rate will never exceed the shared rate anyway, so the router issues the following error message:
% shaping-rate cannot be greater than the shared-shaping-rate
Compound Shared Shaping Configuration Examples

Compound shared shaping requires that you set a shared-shaping rate in a scheduler profile associated with a best-effort node or queue. You can let the router implicitly select the constituents of the shared shaper, or you can explicitly select the constituents by issuing the explicit-constituents keyword when you set the shared-shaping rate. The shared-shaping-constituent command enables you to identify specific explicit constituents. Use the same command to set attributes for both implicit and explicit constituents that determine how bandwidth is allocated among the constituents. shared-shaping-rate
! !
Use to set shared-shaping rate and burst size for the logical interface. To configure the shared shaping feature, this command must appear in the scheduler profile for either the best-effort queue or the best-effort scheduler node. Specify the compound keyword to actively shape voice and video traffic so that the shared rate cannot be exceeded, and shape data queue rates to the value of the shared rate minus the combined voice and video traffic rate.
Shared Shaping
139
By default, shared shaping is set to auto, where the router selects the type of shared shaping that is configured, depending on the line module. An error message is generated if you specify compound for line modules that do not support it, and the router applies simple shared shaping. The simple keyword is appropriate for simple shared shaping, where you want to shape data queue rates to the the value of the shared rate minus the combined voice and video traffic rate. By default the router identifies the shared shaper constituents associated with the logical interface. You can override this automatic selection by issuing the explicit-constituents keyword. Specify the desired subset of the potential constituents and their bandwidth with the shared-shaping-constituents command. The range for the shared-shaping rate is 64000100000000 bps (64 Kbps1 Gbps); the default is no shaping rate. Burst is the catch-up number associated with the shaper; the range is 0522240 (0510 KB). Specifying 0 enables the router to select an applicable default value. Example
host1(config-scheduler-profile)#shared-shaping-rate 128000 burst 32767 compound explicit-constituents
Use the no version to delete the shared-shaping rate.
shared-shaping-constituent
!
Use to specify explicit constituents and to set the attributes of both implicit and explicit shared-shaping constituents that determine how bandwidth is allocated to them. You can specify a constituent as strict or weighted. Strict-priority constituents are allocated bandwidth ahead of weighted constituents. You can optionally set a value that determines the precedence of a constituent among its peers (strict or weighted) for claiming bandwidth.
!
For strict-priority constituents, the range is 18 and the default value is 8. A lower value correlates to a higher claim. For weighted constituents, the range is 131 and the default value is 8. The weights of all sibling weighted constituents are added together. Then each weighted constituent is allocated bandwidth according to the proportion of its weight to the total.
! !
By default, constituents are considered to be strict-priority with a value of 8. Example

host1(config-scheduler-profile)#shared-shaping-constituent weight 28
Use the no version to delete the attributes of a constituent or to delete an explicit constituent.
140
Shared Shaping
Configuration Restrictions
Although you can configure a shared-shaping rate and a shaping rate in the same scheduler profile, the shaping-rate must not exceed the shared-shaping rate. A scheduler profile that includes a shaping rate must not contain a shared-shaping rate that specifies a constituent as weighted. A scheduler profile that includes a shared-shaping rate cannot be associated with a queue other than the best-effort queue or a node other than the best-effort node. A scheduler profile that is referenced by nodes or queues that are not best effort cannot be modified to include a shared-shaping rate command. A scheduler profile that includes a shared-shaping rate command cannot be associated with a group node.
VC Compound Shared Shaping Example

The following commands configure the network shown in Figure 21. This example illustrates a typical DSL triple play configuration, involving voice, video, and data traffic. In this example, 1 Mbps of bandwidth is allocated to voice, video, and best-effort data traffic associated with the VC 1 logical interface. The voice queue in the EF traffic-class group for VC 1 is a strict constituent that has first claim on up to 200 Kbps of the shared bandwidth. The video queue in the AF traffic-class group is a strict constituent that can claim up to 300 Kbps of the remaining 8001000 Kbps of shared bandwidth. The best-effort queue for logical interface VC 1 is a strict constituent that has the last claim to the remaining 5001000 Kbps of shared bandwidth.
Figure 21: VC Compound Shared Shaping Example
Data TC best-effort Data TC best-effort Voice TC voice Voice TC voice Video TC video Video TC video
A
VC 1 best effort VC 2 best effort
B
VC 1 Group EF VC 2 Group EF
C
Group EF
Group AF
g014382
Port
A = Compound shared shaper B = Legacy shaper 200Kbps C = Legacy shaper 300Kbps
Shared Shaping
141
1. Configure the traffic classes, traffic-class groups, and additional scheduler profiles. 2. Configure the scheduler profile that defines the shared shaper and the profiles that apply the legacy shaper.
host1(config)#scheduler-profile shared-1Mbps host1(config-scheduler-profile)#shared-shaping-rate 1000000 burst 32768 auto host1(config)#scheduler-profile 300Kbps host1(config-scheduler-profile)#shaping-rate 300000 host1(config)#scheduler-profile 200Kbps host1(config-scheduler-profile)#shaping-rate 200000
3. Configure the QoS profile.

host1(config)#qos-profile vcSharedShaping
4. Create group nodes.

host1(config-qos-profile)#atm group AF scheduler-profile default host1(config-qos-profile)#atm group EF scheduler-profile default
5. Create VC nodes for each group and for traffic in the default group.
host1(config-qos-profile)#atm-vc node host1(config-qos-profile)#atm-vc node group AF host1(config-qos-profile)#atm-vc node group EF
6. Create queues for the best-effort, video, and voice traffic. Apply the scheduler profile that defines the shared shaping rate to the best-effort queue. Apply the legacy shaper profiles to the voice and video traffic queues.
host1(config-qos-profile)#atm-vc queue traffic-class best-effort scheduler-profile shared-1mbps host1(config-qos-profile)#atm-vc queue traffic-class video scheduler-profile 300Kbps host1(config-qos-profile)#atm-vc queue traffic-class voice scheduler-profile 200Kbps host1(config-qos-profile)#exit
7. Attach the QoS profile to an ATM subinterface.

host1(config)#interface atm 11/0.1 host1(config-interface)#qos-profile vcSharedShaping host1(config-interface)#exit
In this example, the constituents of the VC shared shaper are the VC 1 best effort node, the VC 1 Group EF node, and the VC 1 Group AF node. The available bandwidth is strictly allocated in the following order: 1. VC 1 EF group node 2. VC 1 AF group node 3. VC 1 best effort node
142
Shared Shaping
To display the sample shared shaper configuration:

host1#show shared-shaper atm 11/0.1
shared shaping interface rate ---------------- ------atm-vc ATM11/0.1 1000000 current shaping shaping rate resource rate ------- ------------------------- ------compound best-effort atm-vc queue atm-vc best-effort node EF voice atm-vc queue 200000 AF video atm-vc queue 300000 atm-vc ATM11/0.2 1000000 compound best-effort atm-vc queue atm-vc best-effort node EF voice atm-vc queue 200000 AF video atm-vc queue 300000 Total shared shapers: 2 Total constituents: 8 Total failovers: 0
VP Compound Shared Shaping Example

The following commands configure a compound shared shaper for a VP interface, as shown in Figure 22. VP shared shaping enables a shared shaper to apply to all the aggregate rates of all VCs within the VP. In this example, the VP is shaped to a compound shared rate of 5 Mbps. The voice traffic gets strict priority scheduling for up to 400 Kbps of the shared rate on the VP. The video traffic gets up to 2 Mbps of the remaining 4.65 Mbps on the VP. Finally, the data traffic has the last claim to the remaining 2.63 Mbps of shared VP bandwidth. This configuration enables data traffic to flow at 2.6 Mbps when voice and video are both using their limit. When both voice and video are quiescent, data can flow at the full 5 Mbps shared rate. The QoS profile used in this example is appropriate for low-CDV mode. If the provider configures a shapeless VP tunnel in the SAR, QoS sets the SAR shaper for the VP to match the 5 Mbps shared-shaping rate, and the CDV is bounded for the VP tunnel. VP-level queuing does not guarantee fairness to the voice and video for each VC.
Shared Shaping
143
Figure 22: VP Compound Shared Shaping Example

VC 2 TC voice VC 1 TC voice VC 3 TC voice VC 2 TC video VC 1 TC video VC 3 TC video
VC 1 TC best-effort
VC 2 TC best-effort
VC 3 TC best-effort
VC 1 best effort
VC 2 best effort
VC 3 best effort
VP 1 Group EF
VP 1 Group AF
VP 1 Default group
B
Group EF
C
Group AF
A
g014381
Port
A = Compound shared shaper B = Legacy shaper 400Kbps C = Legacy shaper 2Mbps
1. Configure the traffic classes, traffic-class groups, and additional scheduler profiles. 2. Configure the scheduler profile that defines the shared shaper and the profiles that apply the legacy shaper.
host1(config)#scheduler-profile shared-5Mbps host1(config-scheduler-profile)#shared-shaping-rate 5000000 burst 32768 auto host1(config-scheduler-profile)#exit
3. Configure the scheduler-profile for AF (video) traffic.

host1(config)#scheduler-profile 2Mbps host1(config-scheduler-profile)#shaping-rate 2000000
4. Configure the scheduler-profile for EF (voice) traffic.

host1(config)#scheduler-profile 400Kbps host1(config-scheduler-profile)#shaping-rate 400000 host1(config-scheduler-profile)#exit
5. Configure the QoS profile.

host1(config)#qos-profile vpSharedShaping
6. Create group nodes.

host1(config-qos-profile)#atm group AF scheduler-profile default host1(config-qos-profile)#atm group EF scheduler-profile default
144
Shared Shaping
7. Create VP nodes for each group and for traffic in the default group. The scheduler profile containing the shared-shaping rate is applied to the VP node that is in the default group and contains the best-effort queue.
host1(config-qos-profile)#atm-vp node scheduler-profile shared-5Mbps host1(config-qos-profile)#atm-vp node group AF scheduler-profile 2Mbps host1(config-qos-profile)#atm-vp node group EF scheduler-profile 400Kbps
8. Create a VC node for the default group.

host1(config-qos-profile)#atm-vc node
9. Create queues for the best-effort, video, and voice traffic.

host1(config-qos-profile)#atm-vc queue traffic-class best-effort host1(config-qos-profile)#atm-vc queue traffic-class AF host1(config-qos-profile)#atm-vc queue traffic-class EF host1(config-qos-profile)#exit
10. Attach the QoS profile to an ATM subinterface.

host1(config)#interface atm 11/0.1 host1(config-interface)#qos-profile vpSharedShaping
In this example, the constituents of the VP shared shaper are the VP 1 default group node, the VP 1 Group EF node, and the VP 1 Group AF node. The available bandwidth is strictly allocated in the following order: 1. VP1 EF group node 2. VP1 AF group node 3. VP1 default group node
Shared Shaping Caveats

When you configure shared shaping, be sure to consider the following behaviors.
Hardware Dependency
Compound shared shaping requires new hardware that will be available in a future release, You can contact your Juniper Networks account representative for more information. If you configure compound shared shaping on modules that do not support this feature, an error message is generated.
Shared Shaping
145
Logical Interface Traffic Carried in Other Queues

A shared shaper affects only the queues and nodes for a single interface. Queues associated with other interfaces are not constrained by the shared shaper. This behavior should cause no problems if you configure all queues for a single logical interface type. However, if you configure queues for multiple interface types, you may have problems with shared shaping. For example, a shared shaper for VC 1 does not directly constrain the rate for a queue for IP 1 unless that queue is stacked above a node for VC 1 in the scheduler hierarchy. If the IP queue is stacked above a node for VC 1, then the shared shaper indirectly controls the queue bandwidth through the VC 1 node. But if the IP 1 queue is not stacked above a VC 1 node, it is immune to the shared shaper, and the total bandwidth for VC 1 may exceed the shared rate. As another example, if a shared queue exists for VP 1 where VC 1 is contained within VP 1, the shared shaper for VC 1 does not constrain the bandwidth of a VP queue. The total bandwidth for VC 1 may again exceed the shared rate. Figure 15 on page 127 illustrates an example of mixed interface shaping and its implications for implicit constituent selection for compound shared shaping.
Traffic Starvation
Traffic in the strict-priority traffic-class group can starve out other traffic competing within the shared shaper. You may wish to configure an individual shaping rate for strict-priority queues, thus reserving the remaining shared bandwidth for nonstrict traffic. For example, the following scheduler profiles limit the subscriber's strict priority traffic to 1.0 Mbps and limits the subscriber's aggregate traffic to 1.5 Mbps. If scheduler profile strictOne specified a shaping rate greater than or equal to 1.5 Mbps, nonstrict traffic might face starvation.
host1(config)#scheduler-profile strictOne host1(config-scheduler-profile)#shaping-rate 1000000 host1(config-scheduler-profile)#exit host1(config)#scheduler-profile nonStrictOne host1(config-scheduler-profile)#shared-shaping-rate 1500000
Oversubscription
Many providers configure voice and video queues that combine to oversubscribe the shared rate. The intent is that an external admission control agent, such as RADIUS, is controlling traffic flows such that the offered load will not ever really oversubscribe the shared rate. The static oversubscribed configuration on the router removes the need for the provider to signal voice or video traffic to the router.
Burst Size
The burst size for constituents is typically shaped by the burst value that you specify in the scheduler profile with the shared-shaping-rate command. You can override this burst for a particular constituent by applying another scheduler profile to that constituent and specifying the burst value with the shaping-rate command.
146
Shared Shaping
The following commands configures a VC shared shaper with two constituents, best effort and voice. The best-effort constituent has a burst of 30000 and the voice constituent has a burst of 16384.
host1(config)#scheduler-profile bestEffortBurst host1(config-scheduler-profile)#shared-shaping-rate 1000000 burst 30000 host1(config-scheduler-profile)#exit host1(config)#scheduler-profile voiceBurst host1(config-scheduler-profile)#shaping-rate 300000 burst 16384 host1(config-scheduler-profile)#exit
Configure the QoS profile that applies the scheduler profiles:

host1(config)#qos-profile burstExample host1(config-qos-profile)#atm-vc node host1(config-qos-profile)#atm-vc node group EF host1(config-qos-profile)#atm-vc queue traffic-class best-effort scheduler-profile bestEffortBurst host1(config-qos-profile)#atm-vc queue traffic-class voice scheduler-profile voiceBurst
Statistics Profiles
Statistics profiles enable you to gather statistics for the rate at which packets are forwarded out of a queue and for the rate at which committed, conformed, or exceeded packets are dropped. Statistics profiles also enable you to use events to monitor the rate statistics. You can then use show commands to view the results of the statistics gathering. You can create up to 250 statistics profiles on the E-series router. The profiles are referenced by a queue rule within a QoS profile. When you create a statistics profile, you specify the time period over which statistics are gathered. To gather event statistics, you configure the thresholds for triggering rate-event reporting.
!
Rate periodTime period, in seconds, over which statistics are gathered. For example, a 30-second rate period results in rate statistics being gathered over 30-second time segments. Forwarding rate thresholdThreshold for forwarding rate events. A forwarding-rate event is counted whenever the forwarding rate exceeds the specified threshold. Committed drop thresholdThreshold above which committed drop rate events are counted. Conformed drop thresholdThreshold above which conformed drop rate events are counted. Exceeded drop thresholdThreshold above which exceeded drop rate events are counted.
Statistics Profiles
147
Rate Statistics
You can configure the E-series router to gather statistics for the rate at which queues forward and drop packets. Queue rate statistics measure the forwarding and drop rates of each queue in bits per second. All bytes in the Layer 2 encapsulation are included in the rate calculation. For example, rates for a queue on Ethernet include the Ethernet and VLAN encapsulations. For ATM modules, you can optionally configure queue statistics and queue rates to include the cell encapsulation and padding. Cell encapsulation and padding are referred to as the cell tax. The QoS shaping mode that you set on ATM line modules determines whether queue rate statistics include cell tax.
!
If you use the qos-shaping-mode frame command, the egress queue statistics measure frame rates; an ATM cell tax is not included. If you use the qos-shaping-mode cell command, the egress queue statistics measure cell rates; cell rates include ATM Adaptation Layer 5 (AAL5) encapsulation and cell padding.
NOTE: If you change the QoS shaping mode value in the middle of a rate period, the gathered rates are a mixture of cell- and frame-based rates for that one rate period. The next rate period will use a rate based on the new QoS shaping mode setting.
To configure the router to gather rate statistics on a queue, you create the statistics profile and configure the rate period for the profile. You then reference the statistics profile in a QoS profile, and attach the QoS profile to an interface. Finally, you use the show egress-queue rates command to display statistics that have been gathered. To gather rate statistics, perform the following steps: 1. Configure the statistics profile.
host1(config)#statistics-profile statpro-5 host1(config-statistics-profile)#rate-period 45 host1(config-statistics-profile)#exit
2. Reference the statistics profile by a QoS profile.

host1(config)#qos-profile qospro-3 host1(config-qos-profile)#ip queue traffic-class tc1 scheduler-profile sp1 statistics-profile statpro-5
3. Attach the QoS profile to the appropriate interface.

host1(config)#interface gigabitEthernet 1/0 host1(config-subif)#qos-profile qospro-3 host1(config-subif)#exit
4. (Optional) Display the rate statistics.

host1#show egress-queue rates 148
!
Statistics Profiles
Event Statistics
You can configure the E-series router to count the number of times that forwarding or drop rates exceed a specific threshold. Events can be useful when you are monitoring service level agreements. For example, you might count the number of times that the drop rate of a queue is nonzero. To configure the router to count rate events on a queue, you create the statistics profile and configure the event thresholds for the profile. You then reference the statistics profile in a QoS profile, and attach the QoS profile to an interface. Finally, you use the show egress-queue events command to display the event statistics that you have gathered. To count rate events, perform the following steps: 1. Configure the statistics profile.
host1(config)#statistics-profile statpro-1 host1(config-statistics-profile)#rate-period 30 host1(config-statistics-profile)#forwarding-rate-threshold 10000000 host1(config-statistics-profile)#committed-drop-threshold 2000000 host1(config-statistics-profile)#conformed-drop-threshold 4000000 host1(config-statistics-profile)#exceeded-drop-threshold 6000000 host1(config-statistics-profile)#exit
2. Reference the statistics profile by a QoS profile.

host1(config)#qos-profile qospro-1 host1(config-qos-profile)#ip queue traffic-class tc1 scheduler-profile sp1 statistics-profile statpro-1
3. Attach the QoS profile to the appropriate interface.

host1(config)#interface gigabitEthernet 1/0 host1(config-subif)#qos-profile qospro-1 host1(config-subif)#exit
4. (Optional) Display the rate statistics.

host1#show egress-queue events
Statistics Profiles
149
Memory and Processor Use

The E-series router uses shared processing and memory when it gathers egress queue rate statistics and events. If sufficient memory is not available, the statistics gathering is temporarily disabled and the queues are considered to be in failover mode until memory becomes available. The router displays a CLI message whenever queues are put into failover mode and when they recover from failover mode. The show egress-queue command displays the number of queues that are disabled due to no resources.
NOTE: When an extremely large number of statistics is being gathered over a short period of time, the router might release the processor to perform more important tasks. This can result in longer rate periods than you have configured. For example, if youve configured 10,000 queues to gather statistics every second on a line card, the router might actually lengthen the rate to 2 seconds or more.
Configuring Statistics Profiles

To configure a statistics profile, perform the following steps: 1. Create a statistics profile, and enter Statistics Profile Configuration mode.
host1(config)#statistics-profile statpro-1 host1(config-statistics-profile)#
2. (Optional) Set the time period for calculating queue rate statistics.
host1(config-statistics-profile)#rate-period 30
3. (Optional) Set the threshold for logging events. You can set thresholds for committed drop, conformed drop, exceeded drop, and forwarding rate events.
host1(config-statistics-profile)#committed-drop-threshold 50000
committed-drop-threshold conformed-drop-threshold exceeded-drop-threshold

!
Use to set the threshold above which drop events are counted. A drop event occurs each time the number of packets dropped exceeds the threshold during the specified rate period. The committed-drop-threshold command sets a threshold for committed (green) packets. The conformed-drop-threshold command sets a threshold for conformed (yellow) packets. The exceeded-drop-threshold command sets a threshold for exceeded (red) packets. Drop rate threshold range is 01073741824 bps; default is no threshold. Example
host1(config-scheduler-profile)#committed-drop-rate 50000
! !
Use the no version to delete the drop rate threshold.
150
Statistics Profiles
forwarding-rate-threshold
!
Use to set the threshold above which forwarding rate events are counted. This type of event occurs each time the forwarding rate exceeds the threshold during the specified rate period. Forwarding rate threshold range is 01073741824 bps; default is no threshold. Example
host1(config-scheduler-profile)#forwarding-rate-exceeded 100000
! !
Use the no version to delete the threshold.
rate-period
! ! !
Use to set the length of time during which statistics are counted. Rate period range is 143200 seconds. Example
host1(config-scheduler-profile)#rate-period 30
Use the no version to delete the rate period; statistics will not be gathered.
statistics-profile
!
Use to configure a statistics profile and enter Statistics Profile Configuration mode. The router supports up to 250 statistics profiles. Example
host1(config)#statistics-profile statpro-1 host1(config-statistics-profile)#
! !
Use the no version to remove the statistics profile.
QoS Profiles
A QoS profile specifies queue profiles, drop profiles, statistics profiles, and scheduler profiles in combination with interface types. A QoS profile specifies the queue, drop statistics gathering, and scheduler configuration for a subtree of the interface hierarchy. The QoS profile controls the way scheduler nodes and queues are bound to the interfaces above its attachment point in the interface hierarchy. A QoS profile is attached to the interface at the base of the subtree hierarchy. For example, a QoS profile attached to an ATM port specifies queuing attributes for interfaces of all types that are stacked over the port.
NOTE: QoS profile commands affect only ASIC modules.
QoS Profiles
151
Configuring QoS Profiles

To configure a QoS profile, you name the profile and also name the traffic class and/or the queue profile, drop profile, statistics profile, scheduler profile, or traffic-class group that belongs to the QoS profile. Each command begins with a keyword that designates an interface type. Table 21 lists the interface types and the commands that you can use with them.
Table 21: Interface Types and Supported Commands Interface Type
atm atm-vc atm-vp bridge cbf ethernet fr-vc ip ip-tunnel ipv6 l2tp-session l2tp-tunnel lsp serial server-port vlan
Queue
x x x x x x x x x x x x x x x x
Node
x x x x x x x x x x x x x x x x
Group
x
x x
To configure a QoS profile, perform the following steps: 1. Create a QoS profile and enter QoS Profile Configuration mode.
host1(config)#qos-profile qosp-vc-queuing host1(config-qos-profile)#
2. (Optional) Add a traffic-class group, a scheduler profile, and a statistics profile to the QoS profile.
host1(config-qos-profile)#atm group groupA scheduler-profile scheduler1 statistics-profile statpro-1
3. (Optional) Configure a queue for interfaces in the specified traffic class.

host1(config-qos-profile)#atm queue traffic-class strict-priority scheduler-profile scheduler1
152
QoS Profiles
4. (Optional) Display the components of the QoS profile.

host1#show qos-profile qos-profile qosp-vc-queuing: interface rule type type traffic class --------- ----- --------------atm queue strict-priority atm group
scheduler queue t-class drop statistics profile profile group profile profile ---------- ------- ------- ------- ---------scheduler1 default default statpro-1 scheduler1 groupA
Creating QoS Profiles

Use the following command in Configuration mode to create QoS profiles. qos-profile
! !
Use to create a QoS profile and to enter QoS Profile Configuration mode. Example
Use the no version to remove the QoS profile.
Adding Groups, Nodes, and Queues to QoS Profiles

Use the commands in this section in QoS Profile Configuration mode to add groups, nodes, and queues to QoS profiles. group
! ! ! !
Use to configure a group node for each interface of the specified type. The group defaults to default group. The router supports only one named traffic-class group above a given port. Each traffic class can belong to only one traffic-class group (either the default group or a named group). Examples To create a group node in the default group:
host1(config-qos-profile)#atm group default
To create a group node in a named group:

host1(config-qos-profile)#atm group groupA
To associate a scheduler profile with a named group:

host1(config-qos-profile)#atm group groupA scheduler-profile scheduler1
!
Use the no version to remove this rule from the QoS profile.
QoS Profiles
153
node
! !
Use to configure a scheduler node for each interface of the specified type. The optional scheduler profile supplies a relative weight and potentially a shaping rate to be applied at the scheduler node.
NOTE: For ASIC modules, you cannot associate a scheduler profile with a port-type interface unless you also specify the strict-priority group.
!
Example
host1(config-qos-profile)#ip node scheduler-profile scheduler1 group strict-priority
queue
! !
Use to configure a queue for each interface in the specified traffic class. You can include any of the following profiles:
!
The scheduler profile supplies a relative weight and potentially a shaping rate to be applied at the queue. The queue profile supplies threshold information for the queue if the router defaults are not appropriate. The drop profile supplies dropping behavior of a set of egress queues.
! ! !
Each queue traffic class can appear in only one traffic-class group. Example
host1(config-qos-profile)#atm queue traffic-class strictPriority
Attaching QoS Profiles

Use the commands in this section in Configuration mode to attach QoS profiles to interfaces. atm-vp qos-profile
! !
Use to attach a QoS profile to the specified VP on the ATM interface. The profile applies to all VCs in the VP; for example, the profile specifies the hierarchy of scheduler nodes and queues for all VCs, IP interfaces, and L2TP session stacked above the VP. Example
host1(config)#interface atm 3/0 host1(config-if)#host1(config-if)#atm-vp 50 qos-profile qosp-vp-strictbw
Use the no version to detach the QoS profile from a given VP.
154
QoS Profiles
qos-profile
! !
Use to attach a QoS profile to an interface. Example

host1(config)#interface atm 2/0 host1(config-if)#qos-profile low-latency-q-p
Configuring QoS for ATM Interfaces

The E-series router provides extended ATM QoS functionality through its integrated scheduler. The integrated scheduler consists of two schedulers in seriesthe hierarchical round robin (HRR) scheduler and the segmentation and reassembly (SAR) scheduler. The integrated scheduler enables you to configure QoS on your ATM networks using the HRR scheduler that is used on all E-series ASIC-enabled line modules. In addition, you can use the commercial SAR scheduler to configure traditional ATM cell-based QoS.
NOTE: The term HRR scheduler is used in this chapter to describe the scheduling performed by the ASIC on the ATM line module.
Integrating the HRR Scheduler and SAR Scheduler

The proper integration of the two schedulers is an important element of the routers ATM QoS support. There are three QoS port modes that control integration of the two schedulers:
!
Default integrated QoS port modeATM application controls the scheduling facilities of the SAR scheduler. Low-latency QoS port modeHRR scheduler controls the traffic rate. Low-CDV QoS port modeHRR scheduler and the SAR scheduler operate in concert, with both contributing to the traffic scheduling.
! !
Improper configuration of the two schedulers might create an inefficient scenario in which extra latency is introduced, or might cause the scheduler to underuse the link. To configure integration of the schedulers, use the qos-mode-port commands shown in Table 22.
155
Table 22: qos-mode-port Commands Command Backpressure SAR Buffering Scheduling

significant normal minimal minimal SAR SAR and HRR HRR HRR
no qos-mode-port (default integrated mode) VC and port qos-mode-port low-cdv qos-mode-port low-latency qos-mode-port port port port
NOTE: For ERX-7xx models, ERX-14xx models, and the ERX-310, the qos-mode-port commands are valid only for the major interface on port 0.
It is important that you ensure that the HRR and the SAR schedulers shape packets at the same rate. If the HRR scheduler sends packets at a higher rate than the SAR scheduler shapes them, the SAR scheduler could become congested and block the entire port. To manage the integration of the HRR and the SAR schedulers, first use the qos-shaping-mode cell command to specify the cell-based shaping mode. Next, use the qos-mode-port low-cdv command to configure low-CDV QoS port mode, which ensures that the HRR and SAR schedulers are configured at the same rate. Finally, configure the QoS application to control the SAR schedulers operation. In this mode you configure both schedulers using scheduler profiles and QoS profiles. The E-series router then ensures that VPs and VCs are shaped to the same rates in both schedulers.
Backpressure
ATM packets are initially scheduled through the HRR scheduler and then sent to the SAR scheduler, from where the cells are scheduled onto the circuit. If a SAR VC queue begins to fill up, the SAR scheduler issues VC backpressure messages to the HRR scheduler. The backpressure messages control the amount of traffic the HRR scheduler sends to the SAR scheduler. The SAR scheduler can also exert port backpressure on the HRR scheduler. Backpressure is a critical mechanism that allows the two schedulers in series to operate as a single integrated scheduler. Backpressure ensures that packets do not drain over internal data paths at an unmanageable rate from the HRR scheduler to the SAR scheduler. Without backpressure from the SAR scheduler, the HRR scheduler would see no congestion even if the SAR scheduler is completely saturated.
NOTE: The default QoS profile for ATM (atm-default) contains the atm-vc node
command, which creates the scheduler node that is required by the SAR VC backpressure mechanism. If the SAR scheduler is operating in default integrated mode, this command must be in QoS profiles that are attached to ATM ports. Figure 23 shows the HRR and SAR schedulers working together to form the integrated scheduler. When the SAR VC queues start to back up, the SAR exerts VC backpressure to the corresponding VC node in the HRR scheduler.
156
VC backpressure affects only VC nodes that are in the default traffic-class group. As a consequence, VC nodes that are in named traffic-class groups within the scheduler hierarchy are not affected by VC backpressure.
Figure 23: Integrated ATM Scheduler
IP1
IP2
IP3
Per-packet round-robin
VC1
VC2
VC backpressure
OC3 rate
HRR scheduler
SAR scheduler
VC1
VC2
Per-VC round-robin
OC3 rate
Queue
IP1
Scheduler node
Traffic shaper
g014356
Data flow
Backpressure message
Configuring the Integrated Scheduler

The HRR scheduler and the SAR scheduler work together as an integrated scheduler for ATM traffic. The HRR scheduler is configured by default with per-VC and per-IP interface scheduler nodes, and one best-effort class queue for each IP interface. The SAR scheduler implements weighted round-robin scheduling with one queue per VC. The VC queues are grouped into round robins based on the ATM service classes and the VP tunnels you have configured.
157
In the default integrated mode, controlled by the ATM application, the SAR scheduler controls the scheduling via the VC backpressure messages it sends to the HRR scheduler. When the HRR scheduler receives a backpressure message from the SAR scheduler, the HRR scheduler disables the node regardless of the node weight or shaping rate. When the HRR scheduler receives a backpressure release, the scheduler node is reenabled.
Configuring the SAR Scheduler Mode of Operation

You use the qos-mode-port command to configure port queuing on the SAR scheduler, enabling per-packet rather than per-circuit scheduling. Port queuing mode allows you to use more of the facilities of the HRR scheduler, which are effectively disabled in default integrated mode, while at the same time making the SAR scheduler more transparent. In port queuing mode, you use the QoS application to configure the three levels of the HRR scheduler, including weighted round robin, traffic shaping, and strict priority scheduling. The qos-mode-port commands, including the no version, are described in the following list:
!
no qos-mode-portThe default integrated mode, in which the ATM SAR scheduler does the scheduling. Both VC and port backpressure are enabled, and the HRR scheduler does minimal scheduling. The SAR scheduler performs significant buffering. qos-mode-port low-latencyThe HRR scheduler does the scheduling. All QoS configurations are supported. VC backpressure is disabled, port backpressure is set as aggressive, and the SAR scheduler does minimal buffering. This mode enables the lowest latency for packets scheduled in the HRR scheduler with strict priority. Because the SAR scheduler is running with minimal buffering, there is no head-of-line blocking. qos-mode-port low-cdvThe HRR and SAR schedulers both perform scheduling; QoS synchronizes the rates of the two schedulers. All QoS configurations are supported. VC backpressure is disabled, and port backpressure is set to the default thresholds of 6 MB per OC3 port and 24 MB per OC12 port. This mode allows you to configure shaping in both the SAR scheduler and the HRR scheduler; low-cdv mode works with cell shaping mode only and enables relative weighted VCs and hierarchical shaping in the HRR scheduler. The SAR scheduler performs normal buffering and can shape either the VC or VP, but not both.
NOTE: For ERX-7xx models, ERX-14xx models, and the ERX-310, the qos-mode-port commands are valid only for the major interface on port 0.
Configuring the Operational QoS Shaping Mode

The E-series router enables you to shape ATM traffic based on either frames or cells. The default frame shaping mode provides compatibility with previous versions of the E-series software. When you use cell shaping mode to configure the shaping or policing rate, the resulting traffic stream conforms exactly to the policing rates configured in downstream ATM switches. Using cell shaping also reduces the number of packet drops in the ATM network.
158
ATM policing is sensitive to cell delay variation tolerance (CDVT). If the cells on a particular VC or VP arrive too closely spaced, an ATM switch might drop cells. However, the cell scheduler reduces CDVT by ensuring cell spacing. The router enables you to use techniques such as WRR on the HRR scheduler to achieve the proper packet scheduling. You use the SAR scheduler in series with the HRR scheduler to even out cell bursts into smoother per-VC and per-VP traffic profiles that bound CDVT. You accomplish this by using the qos-shaping-mode cell command to configure the QoS shaping mode, and the qos-mode-port low-cdv command to configure the port queuing mode. The QoS shaping mode also determines how QoS statistics are reported. Frame shaping reports QoS statistics such as transmitted bytes and dropped bytes based on bytes within frames. Cell shaping reports the statistics in bytes within cells and also accounts for cell encapsulation and padding overhead. The router uses an operational shaping mode, which is based on the following two commands:
!
The QoS shaping mode you set with the qos-shaping-mode command on port 0 and on the specific port The port queuing mode you set with the qos-mode-port command on port 0
The router uses the following rules to determine the operational shaping mode used for a port. 1. If the specific port has a QoS shaping mode configured, the operational shaping mode for that port is the same as the QoS shaping mode. 2. If the specific port has no QoS shaping mode configured, the operational shaping mode is the same as the QoS shaping mode for port 0, if one is configured. 3. If both the specific port and port 0 have no QoS shaping mode configured, the operational shaping mode is based on the port 0 queuing mode. If the port 0 queuing mode (set by the qos-mode-port command) is low-cdv, the operational shaping mode is cell; otherwise the operational shaping mode is frame. Table 23 lists the possible combinations of the two commands and the resultant operational shaping mode.
Table 23: Operational Shaping Modes Rule
Rule 1
qos-shaping-mode for the Specific Port

Cell Frame
qos-shaping-mode for Port 0

Cell Frame Cell Frame No shaping mode No shaping mode
qos-mode-port for Port 0

low-cdv low-latency or none low-cdv low-latency or none low-cdv low-latency or none
Operational Shaping Mode for the Specific Port

Cell Frame Cell Frame Cell Frame
Rule 2
No shaping mode No shaping mode
Rule 3
No shaping mode No shaping mode
159
ATM QoS Configuration Examples

This section provides configuration examples for the three modes for QoS on ATM interfaces.
Default Integrated Mode

In the default integrated mode, the SAR scheduler is the dominant scheduler, and it backpressures the first-stage (HRR) scheduler per VC. Each VC buffers only a few hundred bytes. Figure 24 shows the default integrated mode.
Figure 24: Default Integrated Mode
IP1
IP2
IP3
VC1
VC2
VC backpressure
OC3 rate
HRR scheduler
SAR scheduler
VC1
VC2
Per-VC round-robin
OC3 rate
Queue
IP1
Scheduler node
Traffic shaper
g014356
Data flow
Backpressure message
The following example creates the default integrated mode. 1. From the desired port, set the QoS port mode to default integrated mode. (For ATM interfaces on ERX-7xx models, ERX-14xx models, and the ERX-310, you must use port 0.)
host1(config)#interface atm 2/0 host1(config-if)#no qos-mode-port
160
2. Specify the VP shaping rate.

host1(config-if)#atm vp-tunnel 0 2000
3. Specify the shaping rate for the ATM subinterface.

host1(config-if)#interface atm 2/0.5 host1(config-subif)#atm-pvc 5 0 5 aal5snap 768
Low-Latency Mode
In low-latency mode, the SAR scheduler backpressures the HRR scheduler per physical port; each physical port buffers only a few kilobytes. In this mode, the SAR scheduler is neutralized and the HRR scheduler is dominant. Figure 25 shows the low-latency mode.
Figure 25: Low-Latency Mode
IP1
IP2
IP3
VC1
VC2
No VC backpressure
OC3 rate
HRR scheduler
Port backpressure
SAR scheduler
OC3 rate
In the following example, low-latency mode configuration is used with a strict-priority queue and a best-effort queue. 1. Configure the traffic class.
host1(config)#traffic-class strict host1(config-traffic-class)#exit
2. Set the traffic class in the traffic-class group.

host1(config)#traffic-class-group strict host1(config-traffic-class-group)#traffic-class strict host1(config-traffic-class-group)#exit
!
g014357
161
3. Define the scheduler profile for the traffic-class group.

host1(config)#scheduler-profile strict host1(config-scheduler-profile)#strict-priority host1(config-scheduler-profile)#exit
4. Configure the QoS profile with two ATM VC queues.

host1(config)#qos-profile low-latency-q-p host1(config-qos-profile)#atm-vc node host1(config-qos-profile)#atm-vc queue traffic-class best-effort host1(config-qos-profile)#atm group strict scheduler-profile strict host1(config-qos-profile)#atm-vc queue traffic-class strict host1(config-qos-profile)#exit
5. From the desired port, set the QoS port mode to low latency. (For ATM interfaces on ERX-7xx models, ERX-14xx models, and the ERX-310, you must use port 0.)
host1(config)#interface atm 2/0 host1(config-if)#qos-mode-port low-latency host1(config-if)#qos-profile low-latency-q-p
162
Low-CDV Mode
In low-CDV mode, the HRR scheduler and the SAR scheduler operate in concert. The SAR scheduler shapes VPs, VCs, or both according to the QoS scheduler shaping rate. Therefore, the QoS shaping mode must be set to the cell mode. In low-CDV mode, the SAR scheduler converts frame-atomic bursts of cells to CDVT-conformant streams of interleaved cells. There is no VC backpressure, and the port backpressure is loose, so several megabytes of cells can reside in the SAR buffer pool. Figure 26 shows low-CDV mode with per-VP CDVT, and Figure 27 shows low-CDV mode with per-VC CDVT.
Figure 26: Low-CDV Mode (per-VP CDVT)
VC1
VC2
VC3
VC4
VP1
VP2
no VC backpressure
OC3 rate
HRR scheduler
SAR scheduler
VP1
VP2
Shapeless VP tunnels
g014359
VP tunnel round-robins
OC3 rate
163
Figure 27: Low-CDV Mode (per-VC CDVT)
VC1
VC2
VC3
VC4
VC5
VP1
VP2
no VC backpressure
OC3 rate
HRR scheduler SAR scheduler
VC1
VC2
VC3
VC4
VC5
VC cell shaping
g014358
OC3 rate
In the following example, low-CDV mode is used with a strict-priority queue and a best-effort queue. 1. Configure the traffic class.
host1(config)#traffic-class strict host1(config-traffic-class)#exit
2. Set the traffic class in the traffic-class group.

host1(config)#traffic-class-group strict host1(config-traffic-class-group)#traffic-class strict host1(config-traffic-class-group)#exit
3. Define the scheduler profiles for the traffic-class group.

host1(config)#scheduler-profile strict host1(config-scheduler-profile)#strict-priority host1(config-scheduler-profile)#exit host1(config)#scheduler-profile 500k host1(config-scheduler-profile)#shaping-rate 500000 host1(config-scheduler-profile)#exit
164
host1(config)#scheduler-profile 1m host1(config-scheduler-profile)#shaping-rate 1000000 host1(config-scheduler-profile)#exit host1(config)#scheduler-profile 2m host1(config-scheduler-profile)#shaping-rate 2000000 host1(config-scheduler-profile)#exit
4. Configure the QoS profile with two ATM VC queues.

host1(config)#qos-profile low-cdv-q-p host1(config-qos-profile)#atm-vc node scheduler-profile 1m host1(config-qos-profile)#atm-vp node scheduler-profile 2m host1(config-qos-profile)#atm-vc queue traffic-class best-effort host1(config-qos-profile)#atm group strict scheduler-profile strict host1(config-qos-profile)#atm-vc queue traffic-class strict scheduler-profile 500k host1(config-qos-profile)#exit
5. From the desired port, configure shapeless VP tunnels and set the QoS port mode to low CDV. (For ATM interfaces on ERX-7xx models, ERX-14xx models, and the ERX-310, you must use port 0.)
host1(config)#interface atm 2/0 host1(config-if)#atm vp-tunnel 0 0 host1(config-if)#atm vp-tunnel 1 0 host1(config-if)#qos-mode-port low-cdv host1(config-if)#qos-profile low-cdv-q-p host1(config-subif)#interface atm 2/0.5 host1(config-subif)#atm pvc 5 0 5 aal5snap host1(config-subif)#interface atm 2/0.6 host1(config-subif)#atm pvc 6 0 6 aal5snap host1(config-subif)#interface atm 2/0.7 host1(config-subif)#atm pvc 7 1 7 aal5snap host1(config-subif)#interface atm 2/0.8 host1(config-subif)#atm pvc 8 1 8 aal5snap
atm vp-tunnel
!
Use to configure a shapeless virtual path tunnel that is used when the QoS application controls SAR scheduler shaping. Configure shapeless virtual path tunnels by specifying a VP tunnel shaping rate of 0. In low-CDV QoS port mode, QoS automatically configures the shaping rate of the tunnel based on the QoS profile and the scheduler profile. Example
host1(config)#interface atm 1/0 host1(config-if)#atm vp-tunnel 0 0
Use the no version to remove the VP tunnel specification.
165
qos-mode-port
!
Use to configure an ATM port for per-port queuing, and enable certain scheduling features for the HRR scheduler that are effectively disabled in default integrated mode. For ATM interfaces on ERX-7xx models, ERX-14xx models, and the ERX-310, you can configure per-port queuing only on port 0 (zero). When the low-latency keyword or no keyword is used:
! ! !
VC backpressure is disabled. Port backpressure is enabled as aggressive. SAR scheduler performs minimal buffering. QoS synchronizes the shaping rates for VPs and VCs in the HRR and SAR schedulers. VC backpressure is disabled. Port backpressure is set to default thresholds of 6 MB per OC3 port and 24 MB per OC12 port. SAR scheduler performs more buffering than in low-latency mode. Cell QoS shaping mode should be used. For ATM interfaces on ERX-7xx models, ERX-14xx models, and the ERX-310, this command must be issued on ATM port 0 Excludes non-UBR ATM QoS services on any VC on the ATM module; for example, PCR, nrtVBR, and CBR Cannot be used if shaping is currently configured on the SAR scheduler Cannot be used with ATM VP tunnels with nonzero rates; however, can be used with tunnels with rates of zero (shapeless tunnels)
When the low-cdv keyword is used:

!
! !
! ! !
The following restrictions apply to this command:

!
! !
Example
host1(config)#interface atm 1/0 host1(config-if)#qos-mode-port low-latency
Use the no version to remove per-port queuing on the ATM port and restore the default integrated mode setting. When per-port queuing is disabled:
! ! ! !
Both VC and port backpressure are enabled. HRR scheduler does minimal scheduling. SAR scheduler performs significant buffering. The atm-vc node command must appear in the QoS profile attached to the ATM port.
166
qos-shaping-mode
! !
Use to configure the ATM QoS shaping mode. Specify one of the following shaping modes:
!
frameSAR shaping is controlled by the ATM application. Shaping is based on the number of bytes in the frame, without regard to cell encapsulation or padding overhead; this is the default mode. cellSAR shaping is controlled by the QoS application. Shaping is based on the number of bytes in cells, and accounts for the ATM cell encapsulation and padding overhead.
For ATM interfaces on ERX-7xx models, ERX-14xx models, and the ERX-310, this command must be issued on ATM port 0. Example
host1(config)#interface atm 1/0 host1(config-if)#qos-shaping-mode cell
Use the no version to restore the default setting, frame.
NOTE: We recommend that you clear the statistics counters whenever you change
the QoS shaping mode. Otherwise, the statistics contain a mixture of frame-based and cell-based values.
Configuring QoS for L2TP Interfaces

The JUNOSe software supports QoS queues and scheduler nodes for L2TP session interfaces. L2TP QoS provides perL2TP session queuing and allows QoS profiles to be dynamically attached to L2TP session interfaces on E-series routers. The routers can be configured as either an LAC or LNS. The dynamic attachment process uses RADIUS and AAA, enabling a QoS profile to be attached to a dynamic L2TP session interface when the newly created interface has the QoS-Profile-Name [26-26] RADIUS VSA associated with it. L2TP QoS support gives you the ability to shape tunneled users through L2TP interfaces. L2TP QoS profiles are attached at the L2TP session interface, except on the LNS with nonmultilink interfaces. On the LNS with nonmultilink interfaces, L2TP QoS profiles are attached at the IP interface. The queues and scheduler node are built at the L2TP client interface on the line module. L2TP session interfaces have default QoS profiles and scheduler nodes. The default configuration includes the following settings:
host1(config)#show qos-profile l2tp-session-default t-class interface group type -------- -----------l2tp-session rule traffic scheduler queue drop statistics type class profile profile profile profile ----- ----------- --------- ------- ------- ---------queue best-effort default default default default
167
Configuration Procedure
This section describes a sample procedure that configures L2TP QoS. The configuration steps are identical for QoS on an LAC or an LNS; however, the resulting scheduler hierarchy depends on the type of environment. Scheduler Hierarchies on page 169 shows the scheduler hierarchies that the configuration example would create for different environments. The following example assumes that the traffic class (voice) and the two scheduler profiles (100k, and 400k) have already been created. 1. (Optional) This step is required if you are configuring QoS on an LNS; it is not required for QoS on an LAC. Remove the best-effort traffic class rule from the IP interface type of the server-default QoS profile; this enables you to create L2TP session queues.
host1(config)#qos-profile server-default host1(config-qos-profile)#no ip queue traffic-class best-effort host1(config-qos-profile)#exit
2. Create a traffic-class group, and enter Traffic Class Group Configuration mode. Add the traffic class voice to the new group.
host1(config)#traffic-class-group tcGroup1 host1(config-traffic-class-group)#traffic-class voice host1(config-traffic-class-group)#exit
3. Configure the QoS profile. a. Create the QoS profile, and enter QoS Profile Configuration mode.
host1(config)#qos-profile l2tpQpro25 host1(config-qos-profile)#
b.
Add two queues for L2TP session interfaces to the QoS profile.
host1(config-qos-profile)#lt2p-session queue traffic-class best-effort scheduler-profile 400k host1(config-qos-profile)#lt2p-session queue traffic-class voice scheduler-profile 100k host1(config-qos-profile)#exit host1(config)#
4. (Optional) Verify the new QoS profile configuration.

host1(config)#show qos-profile l2tpQpro25 qos-profile l2tpQpro25: t-class interface rule traffic scheduler group type type class profile -------- ------------- ----------- --------l2tp-session queue best-effort 400k tcGroup1 l2tp-session queue voice 100k
queue profile ------default default
drop profile ------default default
statistics profile ---------default default
168
Scheduler Hierarchies
This section shows the different scheduler hierarchies that might be built by the procedure shown in Configuration Procedure on page 168. The type of networking architecture in which the QoS profile is used determines the actual hierarchy that is built. Figure 28 through Figure 32 show scheduler hierarchies for different networking architectures.
Figure 28: LNS (Non-MLPPP) Scheduler Hierarchy
Best-effort queue Voice queue
400 L2TP session
100 tcGroup1
Service port
Figure 29: LNS (MLPPP) QoS Scheduler Hierarchy

Best-effort queue Best-effort queue Voice queue Voice queue
400 L2TP session
400 L2TP session
100
100
tcGroup1
g014371
Server port
Figure 30: LAC over Ethernet (Without VLANs) Scheduler Hierarchy

Best-effort queue Voice queue
L2TP session
tcGroup1
Ethernet
g014375
g014368
169
Figure 31: LAC over Ethernet (With LANs) Scheduler Hierarchy

Best-effort queue
Voice queue L2TP session
VLAN
tcGroup1
Ethernet
Figure 32: LAC over AT

Best-effort queue
Voice queue L2TP session
ATM-VC
tcGroup1
ATM
QoS Profile Attachments

You can attach a QoS profile to an interface at the base of an interface hierarchy, or you can associate a QoS profile with all the ports of a certain interface type.
Attaching a Profile to an Interface

To attach a profile to an interface: 1. Enter Interface Configuration mode for the interface.
host1(config)#interface atm 1.0/1
2. Attach a QoS profile to the interface.

host1(config-if)#qos-profile qosp-vc-queuing 170
!
g014377
g014373
atm-vp qos-profile
! !
Use to attach a QoS profile to a VP. The profile applies to all VCs in the VP; for example, the profile specifies the scheduler hierarchy of scheduler nodes and queues for all VCs, IP interfaces, and L2TP sessions stacked above the VP. Example
host1(config)#interface atm 1.0/1 host1(config-if)#atm-vp 50 qos-profile qosp-vp-strictbw
Use the no version to remove the QoS profile from a given VP.
interface
!
Use to create an interface and enter Interface Configuration mode. See Table 21 on page 152. Example
host1(config)#interface atm 1.0/1 host1(config-if)#
Use the no version to remove the interface.
qos-profile
! !
Use to attach a QoS profile to an interface. Interface types below the attachment point cannot be referenced in the QoS profile. Example
host1(config)#interface atm 3/1 host1(config-if)#qos-profile qosp-vc-queuing
Use the no version to remove the QoS profile from an interface.
Attaching a Profile to a Port Type

By default, the router attaches a QoS port-type profile to all ATM, Ethernet, serial, or server ports. The port-type profile supplies QoS information for all forwarding interfaces stacked above all ports of the associated interface type. Instead of using the default port-type profile, you can explicitly attach a QoS profile to a port. The QoS profile overrides the default QoS port-type profile. The QoS profile associates queue profiles, drop profiles, statistics profiles, and scheduler profiles with interface types, and it applies to all interfaces stacked above ports of the associated type. qos-port-type-profile
! ! !
Use to associate a QoS profile with all the ports of an interface type. The interface type can be: atm, serial, ethernet, or server-port. A profile attached to a port must specify a queue for each forwarding interface type in the best-effort traffic class.
171
Example
host1(config)#qos-port-type-profile atm qos-profile strict-priority
There is no no version. To restore the default, enter qos-port-type-profile server-port qos-profile server-default.
Munged QoS Profile

QoS profile attachments affect the queuing configuration of all the forwarding interfaces stacked above the attachment point. The subtree of the interface hierarchy stacked above the attachment point is the scope of the attachment. When multiple QoS profiles are attached beneath a forwarding interface, the forwarding interface lies in the scope of all the QoS profiles. Rules from all the QoS profiles are combined in a process called mungeing. The set of rules used for a given forwarding interface is called the munged QoS profile. When a QoS profile is attached to an interface, the router searches the interface stack, from the point of attachment down to the port interface at the base of the interface hierarchy, to find all QoS profiles attached under that interface. The rules are combined to form the munged QoS profile. The router reconfigures queues for all forwarding interfaces in the scope of the attachment to conform to the munged profile. The munge algorithm works as follows: 1. Start with the rules in the QoS profile being attached. 2. Traverse down the stack of interfaces until another QoS profile attachment is found. 3. Add rules from the lower-attached QoS profile to the munged QoS profile. Conflicting rules from the lower-attached QoS profile are not added: rules in higher-attached QoS profiles override or eclipse rules in lower-attached QoS profiles. 4. Repeat Steps 2 and 3 until a port interface is reached at the bottom of the interface stack. a. b. If there is a QoS profile attached at the port, add the profiles rules to the munged QoS profile, and the munge algorithm is then complete. If there is no QoS profile attached at the port, then locate the QoS profile indicated in the qos-port-type-profile command that corresponds to the interface type of the port. For example, if the port is an ATM interface, the default QoS port-type profile for type ATM is named atm-default. Add the rules in the QoS port-type profile to the munged QoS profile. The entries in the QoS profile specified in the corresponding qos-port-type-profile command have the lowest precedence. Once the munged QoS profile is complete, the router reprocesses the queues for all forwarding interfaces in the scope of the attachment, adding, deleting, or modifying the scheduler hierarchy as required by the munged QoS profile rules.
172
In Step 3, the router must decide which rules from a QoS profile conflict with rules already contained within the munged QoS profile. Queue rules are identified by their {interface type, traffic class} pair; two queue rules with the same interface type and traffic class are deemed conflicting. Node rules are identified by their {interface type, traffic-class group} pair; two node rules with the same interface type and traffic-class group are deemed conflicting.
Example
Figure 33 shows the relationship between a port-attached QoS profile and a QoS profile that is attached to the specific interface, ATM 11/0.2.
Figure 33: Munged Profile Example
Queue: priority-data shaped to 64 Kbps Queue: Queue: priority-data voice-over-IP shaped to 1 Mbps
ATM 11/0.1
ATM 11/0.2
The port-attached QoS profile on ATM 11.0 contains the following queue rule:
host1(config)#qos-profile atmPort host1(config-qos-profile)#ip queue traffic-class priority-data scheduler-profile 64kbps host1(config-qos-profile)#exit
All forwarding interfaces stacked above the port are within the scope of the attachment, so all IP interfaces stacked above the port will be provisioned with a queue in the priority-data traffic class, shaped to 64 Kbps. The QoS profile attached at subinterface ATM 11/0.2 contains the following two rules:
host1(config)#qos-profile atmVc host1(config-qos-profile)#ip queue traffic-class priority-data scheduler-profile 1mbps host1(config-qos-profile)#ip queue traffic-class voice-over-ip host1(config-qos-profile)#exit
The queue rule for {interface type IP, traffic-class priority-data} in the QoS profile that is attached to ATM 11/0.2 effectively overrides the queue rule for the same interface type and traffic class in the port-attached QoS profile on ATM11.0.
g013245
ATM 11/0
173
The second queue rule, which is for the voice-over-ip traffic-class, is not conflicting. In this configuration, the provider has configured a 64 Kbps priority-data queue for each IP interface stacked above the port. But the IP interface above the ATM 11/0.2 attachment provides 1 Mbps for priority-data, and also has a second queue provisioned for VoIP.
NOTE: When a QoS profile is attached to an interface, the router first searches to determine if a munged QoS profile already exists. If you modify an existing QoS profile, the router automatically updates all munged QoS profiles that are dependent on the modified profile.
QoS Profile Configuration Examples

This section provides examples of port-attached and port-type QoS profiles.
Example 1
In this example, three ATM subinterfaces are configured on an ATM port:

! ! !
ATM 11/0.1QoS profile qp1 is attached ATM 11/0.2QoS profile qp2 is attached ATM 11/0.3No QoS profile is attached
The major ATM interface, 11/0, does not have a QoS profile explicitly attached. Therefore, by default the atm-default QoS port-type profile is attached.
Figure 34: Example 1Attaching QoS Profiles to ATM Subinterfaces
qos-profile qp1 ATM 11/0.1 VC
qos-profile qp2 ATM 11/0.2 VC ATM 11/0.3 VC
qos-port-type-profile atm-default
To configure this example: 1. Create and configure QoS profile qp1.

host1(config)#qos-profile qp-1 host1(config-qos-profile)#atm-vp host1(config-qos-profile)#atm-vc queue-profile qp1 host1(config-qos-profile)#atm-vc queue-profile qp2 host1(config-qos-profile)#atm-vc queue-profile qp3 node scheduler-profile sp1 queue traffic-class tc1 scheduler-profile sp1 queue traffic-class tc2 scheduler-profile sp2 queue traffic-class tc3 scheduler-profile sp3
174
g013720
ATM 11/0 Port
host1(config-qos-profile)#atm-vc queue traffic-class tc4 scheduler-profile sp4 queue-profile qp4 host1(config-qos-profile)#atm-vc queue traffic-class tc5 scheduler-profile sp5 queue-profile qp5 host1(config-qos-profile)#exit
2. Create and configure QoS profile qp2.

host1(config)#qos-profile qp2 host1(config-qos-profile)#atm-vp host1(config-qos-profile)#atm-vc queue-profile qp1 host1(config-qos-profile)#atm-vc queue-profile qp2 host1(config-qos-profile)#atm-vc queue-profile qp3 host1(config-qos-profile)#exit node scheduler-profile sp1 queue traffic-class tc1 scheduler-profile sp1 queue traffic-class tc2 scheduler-profile sp2 queue traffic-class tc3 scheduler-profile sp3
3. Attach the QoS profiles to the ATM subinterfaces, as shown in Figure 34.
host1(config)#interface atm 11/0.1 host1(config-subif)#qos-profile qp1 host1(config-subif)#exit host1(config)#interface atm 11/0.2 host1(config-subif)#qos-profile qp2 host1(config-subif)#exit
4. Display the QoS interface hierarchy for ATM interface 11/0. This display shows all QoS attachments above interface 11/0. If no QoS profiles are attached above the specified interface, the router shows the first attachment below the specified interface.
host1#show qos interface-hierarchy atm 11/0 attachment@ atm-vc ATM11/0.2: qos interface rule traffic profile type type class --------------- ---- ------qp2@ATM11/0.2 atm-vp node qp2@ATM11/0.2 atm-vc queue tc1 qp2@ATM11/0.2 atm-vc queue tc2 qp2@ATM11/0.2 atm-vc queue tc3 atm-default @atm ip node atm-default @atm atm-vc node atm-default @atm cbf node atm-default @atm Bridge node atm-default @atm ipv6 node atm-default @atm ip queue best-effort atm-default @atm atm queue best-effort atm-default @atm atm-vc queue best-effort atm-default @atm cbf queue best-effort atm-default @atm Bridge queue best-effort atm-default @atm ipv6 queue best-effort
scheduler profile --------sp1 sp1 sp2 sp3 default default default default default default default default default default default
queue t-class profile group ------- ------default qp1 qp2 qp3 default default default default default default default default default default default
175
attachment@ atm-vc ATM11/0.1: qos interface rule traffic profile type type class --------------- ---- ------qp1@ATM11/0.1 atm-vp node qp1@ATM11/0.1 atm-vc queue tc1 qp1@ATM11/0.1 atm-vc queue tc2 qp1@ATM11/0.1 atm-vc queue tc3 qp1@ATM11/0.1 atm-vc queue tc4 qp1@ATM11/0.1 atm-vc queue tc5 atm-default @atm ip node atm-default @atm atm-vc node atm-default @atm cbf node atm-default @atm Bridge node atm-default @atm ipv6 node atm-default @atm ip queue best-effort atm-default @atm atm queue best-effort atm-default @atm atm-vc queue best-effort atm-default @atm cbf queue best-effort atm-default @atm Bridge queue best-effort atm-default @atm ipv6 queue best-effort
scheduler profile --------sp1 sp1 sp2 sp3 sp4 sp5 default default default default default default default default default default default
queue t-class profile group ------- ------default qp1 qp2 qp3 qp4 qp5 default default default default default default default default default default default
Notice that ATM subinterface 11/0.3 was not shown because there is no QoS profile attached to it. You can display the QoS interface hierarchy for subinterface 11/0.3 by specifying the subinterface, as shown below. In this case, the QoS port-type profile, atm-default, is attached (by default) to the ATM major interface, ATM 11/0, below ATM subinterface 11/0.3. Because no QoS profile is attached to this ATM subinterface, the QoS port-type profile is applied. The @atm in the qos profile column indicates that the row comes from a default QoS port-type profile that is below the interfaces shown: subinterfaces ATM 11/0.2 and ATM 11/0.1 in this example. You can explicitly show the ATM subinterface that has no explicit QoS profile attachment, as shown below. In this case, attachment@ indicates the ATM major interface (11/0) below the subinterface.
host1#show qos interface-hierarchy atm 11/0.3 attachment@ atm ATM11/0: qos interface rule traffic profile type type class --------------- ---- ------atm-default@atm ip node atm-default@atm atm-vc node atm-default@atm cbf node atm-default@atm Bridge node atm-default@atm ipv6 node atm-default@atm ip queue best-effort atm-default@atm atm queue best-effort atm-default@atm atm-vc queue best-effort atm-default@atm cbf queue best-effort atm-default@atm Bridge queue best-effort atm-default@atm ipv6 queue best-effort
scheduler profile --------default default default default default default default default default default default
queue t-class profile group ------- ------default default default default default default default default default default default
176
Example 2
In Figure 35, the major ATM interface, 11/0, has QoS profile qp1 explicitly attached. The major ATM interface has three ATM subinterfaces configured:
! ! !
ATM 11/0.1No QoS profile is explicitly attached ATM 11/0.2QoS profile qp2 is attached ATM 11/0.3No QoS profile is explicitly attached
The qp1 profile overrides the QoS port-type profile, atm-default, on subinterfaces 1 and 3. It does not override profile qp2, which was explicitly attached to subinterface 2.
Figure 35: Example 2Attaching QoS Profile to ATM Interface and Subinterface
qos-profile qp2 ATM 11/0.1 VC ATM 11/0.2 VC ATM 11/0.3 VC
qos-profile qp1
To configure this example: 1. Create and configure QoS profiles qp1 and qp2 as shown in Example 1 on page 174. 2. Attach QoS profile qp1 to ATM interface 11/0.
host1(config)#interface atm 11/0 host1(config-if)#qos-profile qp1 host1(config-if)#exit
3. Attach QoS profile qp2 to ATM subinterface 11/0.2.

host1(config)#interface atm 11/0.2 host1(config-subif)#qos-profile qp2 host1(config-subif)#exit host1(config)#exit
4. Display the QoS interface hierarchy for ATM 11/0.

host1#show qos interface-hierarchy atm 11/0 qos interface rule traffic profile type type class --------------- ---------@ATM11/0 atm queue best-effort qp1@ATM11/0 atm-vp node qp1@ATM11/0 atm-vc queue tc1 qp1@ATM11/0 atm-vc queue tc2 qp1@ATM11/0 atm-vc queue tc3 qp1@ATM11/0 atm-vc queue tc4 qp1@ATM11/0 atm-vc queue tc5 scheduler profile --------default sp1 sp1 sp2 sp3 sp4 sp5 queue t-class profile group ------- ------default default qp1 qp2 qp3 qp4 qp5
g013721
ATM 11/0 Port
177
attachment@ atm-vc ATM11/0.2: qos interface rule traffic profile type type class --------------- ---------qp2@ATM11/0.2 atm-vp node qp2@ATM11/0.2 atm-vc queue tc1 qp2@ATM11/0.2 atm-vc queue tc2 qp2@ATM11/0.2 atm-vc queue tc3 @ATM11/0 atm queue best-effort qp1@ATM11/0 atm-vc queue tc4 qp1@ATM11/0 atm-vc queue tc5
scheduler profile --------sp1 sp1 sp2 sp3 default sp4 sp5
queue t-class profile group ------- ------default qp1 qp2 qp3 default qp4 qp5
Note that:
!
ATM best-effort queues are created on ATM interface @ATM11/0 and ATM 11/0.2. ATM 11/0.2 subinterface has three queues (traffic classes tc1, tc2, and tc3) that come from QoS profile qp2. Traffic class tc3 is defined in both QoS profile qp1 and qp2. The QoS profile attached closest to the leaf node is used, however. Traffic class tc3 comes from QoS profile qp2, which is attached to ATM subinterface ATM 11/0.2. Queues for traffic classes tc4 and tc5 come from QoS profile qp1, which is attached at the ATM major interface.
Diffserv Configuration with Multiple Traffic-Class Groups

In this example configuration, a service provider offers three types of service: data, video-on-demand, and voice. Each service has different QoS requirements. The data users log in and can dynamically subscribe to video and voice services. The data service is a best-effort service. The video service is a better than best effort service, which corresponds to assured forwarding PHB. The voice service is a low-latency service, which corresponds expedited forwarding PHB. You can meet these varying traffic requirements by creating a traffic class group for each of the three services. Creating groups enables you to apply QoS to the group nodes. For example, you could specify the following:
!
The voice service gets low-latency, strict priority treatment through the fabric and on egress. You configure an assured rate of 20 Mbps, and shape the traffic to 20 Mbps. Each voice user is shaped to 1 Mbps to support up to 20 voice subscribers without oversubscription. Call admission control ensures that there are no more than 20 simultaneous voice service subscribers. Unused bandwidth is divided among the video and best-effort users. The video service is scheduled by the HRR scheduler and gets the hierarchical assured rate. You shape the video traffic to 50 Mbps. Each video service user is assured 1 Mbps, and is shaped to 1 Mbps to support up to 50 video subscribers without oversubscription. Call admission control ensures that there are no more than 50 simultaneous video service subscribers. Unused bandwidth is divided among the best-effort users.
178
The best-effort data service is scheduled by the HRR scheduler and gets the bandwidth left over from the voice and video services.
Configure this implementation as follows. 1. Create the video and voice traffic classes. Assign the voice traffic class a strict-priority treatment within the fabric. Note that manually creating a best-effort traffic class is superfluous because the router creates this class by default.
(config)#traffic-class video (config-traffic-class)#exit (config)#traffic-class voice (config-traffic-class)#fabric-strict-priority (config-traffic-class)#exit (config)#traffic-class best-effort (config-traffic-class)#exit
2. Create scheduler profiles for the assured forwarding, expedited forwarding, and best-effort groups. Specify strict priority scheduling for the expedited forwarding traffic and shape it to 20 Mbps.
(config)#scheduler-profile expeditedGroup (config-scheduler-profile)#strict-priority (config-scheduler-profile)#shaping-rate 20000000 (config-scheduler-profile)#assured-rate 20000000 (config-scheduler-profile)#exit
3. Assured traffic is not strict, so it is scheduled by the HRR scheduler. Shape the assured traffic to 50 Mbps, and specify the hierarchical assured rate to give assured traffic preferential treatment over best-effort traffic.
(config)#scheduler-profile assuredGroup (config-scheduler-profile)#shaping-rate 50000000 (config-scheduler-profile)#assured-rate hierarchical (config-scheduler-profile)#exit
4. Best effort traffic is also scheduled by the HRR scheduler. You do not apply any shaping for this traffic because it simply gets the leftover bandwidth.
(config)#scheduler-profile bestEffortGroup (config-scheduler-profile)#exit
5. Create scheduler profiles for the voice, video, and best-effort service classes. Shape voice and video to 1 Mbps. Because you do not specify a shaping rate, the best-effort traffic can borrow unused bandwidth.
(config)#scheduler-profile voice (config-scheduler-profile)#shaping-rate 1000000 (config-scheduler-profile)#exit (config)#scheduler-profile video (config-scheduler-profile)#shaping-rate 1000000 (config-scheduler-profile)#exit (config)#scheduler-profile best-effort (config-scheduler-profile)#exit
179
6. Put the video traffic class into the assured-forwarding traffic-class group and specify the group as strict priority. Put the voice traffic class into the expedited-forwarding traffic-class group. Put the best-effort traffic class into the best-effort traffic-class group.
(config)#traffic-class-group assured-forwarding auto-strict-priority (config-traffic-class-group)#traffic-class video (config-traffic-class-group)#exit (config)#traffic-class-group expedited-forwarding extended (config-traffic-class-group)#traffic-class voice (config-traffic-class-group)#exit (config)#traffic-class-group best-effort extended (config-traffic-class-group)#traffic-class best-effort (config-traffic-class)#exit
7. Create a QoS profile that contains the group rules for the assured-forwarding, expedited-forwarding, and best-effort traffic-class groups.
(config)#qos-profile qpDiffServExample (config-qos-profile)#ethernet group assured-fwd scheduler-profile assuredGroup (config-qos-profile)#ethernet group expedited-fwd scheduler-profile expeditedGroup (config-qos-profile)#ethernet group best-effort scheduler-profile bestEffortGroup (config-qos-profile)#ip node group assured-fwd scheduler-profile default (config-qos-profile)#ip node group expedited-fwd scheduler-profile default (config-qos-profile)#ip node group best-effort scheduler-profile default (config-qos-profile)#ip queue traffic-class voice scheduler-profile voice (config-qos-profile)#ip queue traffic-class video scheduler-profile video (config-qos-profile)#ip queue traffic class best-effort scheduler-profile best-effort (config-qos-profile)#exit
8. Attach the QoS profile to an Ethernet port.

(config)#interface fastEthernet 9/0 (config-if)#qos-profile qpDiffServExample (config-if)#exit
Figure 36 shows this configuration with 3 users: IP 1, IP 2, and IP 3.

! ! !
IP 1 subscribes to data, video, and voice services. IP 2 subscribes to data and video services. IP 3 subscribes to data and voice services.
180
Figure 36: Diffserv Configuration with Multiple Traffic-Class Groups

9 Data 9 Data 9 Data 8 Data 8 Data 7 Data 7 Data
4 IP 1
4 IP 2
4 IP 3
5 IP 1
5 IP 2
6 IP 1
6 IP 3
BE Group
2 AF Group
3 EF Group
The following set of commands configure the QoS profile as in Step 7. Each line in the profile is known as a profile rule. The numbers associated with each rule below correspond to the numbers in Figure 36.
(config)#qos-profile qpDiffServExample (1) (config-qos-profile)#ethernet group best-effort scheduler-profile bestEffortGroup (2) (config-qos-profile)#ethernet group assured-fwd scheduler-profile assuredGroup (3) (config-qos-profile)#ethernet group expedited-fwd scheduler-profile expeditedGroup (4) (config-qos-profile)#ip node group best-effort scheduler-profile default (5) (config-qos-profile)#ip node group assured-fwd scheduler-profile default (6) (config-qos-profile)#ip node group expedited-fwd scheduler-profile default (7) (config-qos-profile)#ip queue traffic-class voice scheduler-profile voice (8) (config-qos-profile)#ip queue traffic-class video scheduler-profile video (9) (config-qos-profile)#ip queue traffic class best-effort scheduler-profile best-effort
Note that when you specify a group rule within an attached QoS profile, nodes and queue may be attached to group nodes. If the qpDiffServExample QoS profile used in the example above did not contain group rules, then the groups would exist with no attachments.
g014402
BE group = best effort group, data AF group = assured forwarding group, video EF group = expedited forwarding group, voice
Port
181
For example, the following set of commands configures the same QoS profile, but with the group removed, as shown in Figure 37.
(config)#qos-profile qpDiffServExample (config-qos-profile)#ip node scheduler-profile default config-qos-profile)#ip queue traffic-class voice scheduler-profile voice config-qos-profile)#ip queue traffic-class video scheduler-profile video config-qos-profile)#ip queue traffic class best-effort scheduler-profile best-effort
In this case, the configuration creates the groups but does not place any of the traffic classes into the groups. Figure 37 shows that IP 1, IP 2, and IP 3 contain the ungrouped traffic classes, data, video, and voice.
Figure 37: Diffserv Configuration Without Traffic-Class Groups
Best-effort group (data) Assured forwarding group (video) Expedited forwarding group (voice)
Data
Data
Data
Video
Video
Voice
Voice
IP 1
IP 2
IP 3
IP 1
IP 2
IP 1
IP 3
Port
Because the BE, AF, and EF groups have no queues, their scheduler attributes (weight, assured rate, shaping rate) do not affect the HRR scheduler's distribution of bandwidth.
Strict-Priority Scheduling
You can configure one or more strict-priority queues per interface. Strict-priority scheduling is implemented with a special strict-priority scheduler node that is stacked directly above the port. Queues stacked on top of the strict-priority scheduler node always get bandwidth before other queues. You can configure only one node at the first scheduler level as strict priority. If any node or queue above the strict-priority node has packets, it is scheduled next. If multiple queues above the strict-priority node have packets, the HRR algorithm selects which strict-priority queue is scheduled next.
182
g014403
Example
host1(config-qos-profile)#atm group strict scheduler-profile strictpriority
Figure 38 is an example of a QoS schedulers hierarchy.

Figure 38: QoS Scheduler Hierarchy
Besteffort traffic class Lowloss I traffic class Lowloss I traffic class Lowlatency I traffic class Lowlatency II traffic class Lowlatency I traffic class Lowlatency II Queues/traffic classes traffic (Buffer management) class Scheduler level 3
ATM 2/0.1
ATM 2/0.2
ATM 2/0.1
ATM 2/0.2
Scheduler level 2 (Bandwidth management)
(Default group)
Strict-priority group
Scheduler level 1
ATM 2/0 port
There is one strict priority traffic-class group called the auto-strict-priority group. The scheduler nodes and queues in the auto-strict-priority group receive strict-priority scheduling. If multiple queues above the strict-priority node have packets, the HRR algorithm selects which strict-priority queue is scheduled next. The following set of commands creates the configuration in Figure 38: 1. Configure a scheduler profile for strict-priority traffic.
host1(config)#scheduler-profile strictPriorityBandwidth host1(config-scheduler-profile)#shaping-rate 20000000 host1(config-scheduler-profile)#exit
2. Configure the traffic classes.

host1(config)#traffic-class Low-loss-1 host1(config-traffic-class)#exit host1(config)#traffic-class Low-latency-1 host1(config-traffic-class)#exit host1(config)#traffic-class Low-latency-2 host1(config-traffic-class)#exit
3. Configure the auto-strict-priority traffic-class group, and add the traffic classes that must receive strict-priority scheduling to the group.
host1(config)#traffic-class-group Strict-priority auto-strict-priority host1(config-traffic-class-group)#traffic-class Low-latency-1 host1(config-traffic-class-group)#traffic-class Low-latency-2 host1(config-traffic-class-group)#exit
g014334
183
4. Configure a QoS profile.

host1(config)#qos-profile Example-qos-profile host1(config-qos-profile)#atm group default host1(config-qos-profile)#atm group Strict-priority scheduler-profile strictPriorityBandwidth host1(config-qos-profile)#atm-vc node group default host1(config-qos-profile)#atm-vc node group Strict-priority host1(config-qos-profile)#atm-vc queue traffic-class best-effort host1(config-qos-profile)#atm-vc queue traffic-class Low-loss-1 host1(config-qos-profile)#atm-vc queue traffic-class Low-latency-1 host1(config-qos-profile)#atm-vc queue traffic-class Low-latency-2 host1(config-qos-profile)#exit
5. Attach the QoS profile to an interface.

host1(config)#interface atm 2/0 host1(config-if)#qos-profile Example-qos-profile host1(config-if)#exit host1(config)#
Relative Strict-Priority Scheduling

Relative strict-priority scheduling provides strict-priority scheduling within a shaped aggregate rate. For example, it allows you to provide 1 Mbps of aggregate bandwidth to a subscriber, with up to 500 Kbps of the bandwidth for low-latency traffic. If there is no strict-priority traffic, the low-latency traffic can use up to the full aggregate rate of 1 Mbps. Relative strict priority differs from true strict priority in that it can implement the aggregate shaping rate for both strict and nonstrict traffic. With true strict priority, you can shape the nonstrict or the strict traffic separately, but you cannot shape the aggregate to a single rate. The best application of relative strict priority is on Ethernet, where you can shape the aggregate for each VLAN to a specified rate, and provision a strict and nonstrict queue for each VLAN above the shaped VLAN node. To use relative strict priority, you configure strict-priority queues above the VC or VLAN scheduler node, thereby providing for strict-priority scheduling of the queues within the VC or VLAN. You configure relative strict priority without using QoS traffic-class groups, which causes strict-priority queues to appear in the same scheduler hierarchy as the nonstrict queues. Relative strict priority provides low latency only if you undersubscribe the port by shaping all VCs on the port so that the sum of the shaping rates is less than the port rate. The port will not become congested, and the latency caused by the round-robin behavior of both the HRR and cell schedulers is nominal. In these undersubscribed conditions, the latency of a strict-priority queue within each VC is calculated as if the VC were draining onto a wire with bandwidth equal to the shaped rate. Relative strict priority is carried out in the HRR scheduler on E-series ASIC line modules.
184
!
True Strict Priority Versus Relative Strict Priority

This section shows how the HRR and SAR schedulers handle true strict-priority and relative strict-priority configurations.
True Strict Priority

In the strict-priority configuration in Figure 39, the queues stacked above the single strict priority scheduler node make up a round-robin separate from the nonstrict queues. All strict queues are drained to completion first, and any residual bandwidth is allocated to the nonstrict round-robin.
Figure 39: True Strict-Priority Configuration
{VC1, BE}
{VC2, BE}
{VC1, Strict}
{VC2, Strict}
VC1
VC2
VC1
VC2
Strict
VC backpressure
OC3 rate
HRR scheduler
SAR scheduler
Per-VC round-robin
OC3 rate
This configuration provides low latency for the strict-priority queues, irrespective of the state of the nonstrict queues. The worst-case latency for a strict packet caused by a nonstrict packet is the propagation delay of a single large packet at the port rate. For a 1500 byte frame at OC3 rate, that latency is less than 100 microseconds. Because the strict and nonstrict packets for a VC are scheduled in separate round robins, the scheduler cannot enforce an aggregate rate for both of them.
g014361
185
Relative Strict Priority

In the relative strict-priority configuration in Figure 40, the scheduler provides relative strict-priority scheduling relative to the VC. If the port is not oversubscribed, the VC round robin does not cause significant latency.
Figure 40: Relative Strict-Priority Configuration
{VC1, BE}
{VC1, Strict}
{VC2, BE}
{VC2, Strict}
VC1
VC2
OC3 rate
HRR scheduler
SAR scheduler
OC3 rate
This configuration provides a latency bound for the relative strict-priority queues. The worst-case latency caused by a nonstrict packet is the propagation delay of a single large packet at the VC rate. For a 1500 byte frame at a 2 Mbps rate, that delay is about 6 milliseconds. This configuration provides for shaping the aggregate of nonstrict and relative strict packets to a single rate, and it is consistent with the traditional ATM model. It does not scale as well as true strict priority, because the nonstrict and relative strict traffic together must not oversubscribe the port rate.
Relative Strict Priority on ATM Modules

You can use relative strict priority on any type of E-series line module; however, on ATM line modules you have an alternative. On ATM line modules you can configure true strict-priority queues in the HRR scheduler and shape the aggregate for the VC in the SAR scheduler. VC backpressure affects only the nonstrict traffic for the VC. For this type of configuration, you should shape the relative strict traffic for each VC in the HRR scheduler to a rate that is less than the aggregate VC rate. This shaping prevents the VC queue in the SAR scheduler from being congested with strict-priority traffic.
186
g014360
Per-VC round-robin
The major difference between relative and true strict priority on ATM line modules is that relative strict priority shapes the aggregate for the VC to a precell tax rate, whereas true strict priority shapes the aggregate for the VC to a postcell tax rate. For example, shaping the VC to 1 Mbps in the HRR scheduler allows 1 Mbps of frame data, but cell tax adds anywhere from 100 Kbps to 1 Mbps additional bandwidth, depending on packet size. Shaping the VC to 1 Mbps in the SAR scheduler allows just 1 Mbps of cell bytes regardless of packet size.
Oversubscribing ATM Ports

You cannot oversubscribe ATM ports and still achieve low latency with relative strict-priority scheduling. There are several ways to ensure that ports are not oversubscribed. The most common is to use a per-VC scheduler by configuring the HRR scheduler with either ATM VP or VC node shaping (using the atm-vp node or atm-vc node commands), and setting the sum of the shaping rates less than the port rate. In these scenarios, the cell residency in the SAR scheduler is minimal, and cell scheduling does not interfere with relative strict priority.
Minimizing Latency on the SAR Scheduler

There are two methods you can use to control latency on the SAR scheduler. In the first method, you set the ATM QoS port mode to low-latency mode. In low-latency mode, the HRR scheduler controls scheduling, buffering in the SAR scheduler is limited, and latency caused by the SAR scheduler is minimized. You can also use the default no qos-mode-port mode of SAR operation to minimize the latency induced by the SAR. In this method, you set qos shaping-mode cell and shape an OC-3 ATM port to 149 Mbps, or an OC-12 ATM port to 600 Mbps. By throttling the rate at which the HRR scheduler delivers packets to the SAR, you bound SAR buffering and latency. This approach retains the flexibility to configure different ATM QoS in the SAR, including shaped VP tunnels, UBR+PCR, nrtVBR, and CBR services. To set the SAR mode, use the qos-mode-port command. For more information about operational modes on ATM interfaces, see Configuring QoS for ATM Interfaces on page 155.
NOTE: Controlling latency is not normally required. If you undersubscribe the port
rate in the HRR scheduler, you can obtain latency bounds without modifying the SAR mode of operation.
HRR Scheduler Behavior

The HRR scheduler does not offer native strict-priority scheduling above the first scheduler level in the hardware; however, you can configure very large weights in the round robin in the HRR scheduler to obtain approximate strict-priority scheduling. Note that under conditions of low VC bandwidth and large packet sizes, latency and jitter increase because of the inherent propagation delay of large packets over a small shaping rate. The following sections describe additional configuration steps that will ensure that no more than a single nonstrict packet can precede a strict-priority packet on the VC.
187
Zero-Weight Queues
To reduce latency and jitter, you can configure the relative strict-priority queue with a weight of 0 (zero), which gives the queue infinite weight. When a packet arrives at a zero-weighted queue, the queue remains in the active WRR until it is drained, whereas competing queues must leave the active WRR because their weight credits are exhausted. Therefore, the zero-weighted queue is eventually alone in the active round robin and is effectively drained at strict priority. You should configure only one zero-weighted queue or node above a parent node. Otherwise, the scheduler will drain only one of the zero-weighted nodes or queues, as opposed to performing a round robin that includes both of the zero-weighted nodes. This behavior leads to nondeterministic sharing of bandwidth between the two zero-weighted queues. To configure more than one relative strict queue or node, simply configure a maximum weight, and the two relative strict queues or nodes will share bandwidth fairly. You can shape the nonstrict queue, as described in the next section, to keep latency bounded. Also, you should configure only a few nonstrict nodes or queues to prevent additional latency and jitter of the relative strict-priority traffic when the nodes or queues are in the round robin and a packet arrives in the zero-weighted queue. The number of nonstrict frames that precede a relative strict frame equals the number of nonzero weighted queues among the sibling scheduler nodes. It is important to note that nonstrict queues must still exhaust their weight credits before they leave the active round robin. The result is that occasionally more than one nonstrict frame may precede a relative strict frame, causing more jitter than may be acceptable. You can eliminate this source of latency by shaping the nonstrict queue to the aggregate rate with a burst size of 1.
Setting the Burst Size in a Shaping Rate

The burst value in a shaping rate determines the number of rate credits that can accrue when the queue or scheduler node is held in the inactive round robin. When the queue is back on the active list, the accrued credits allow the queue or node to catch up to the configured rate, up to the burst value. Normally, the burst size is several packet lengths to allow a queue deprived of bandwidth because of congestion to catch up to its rate. Larger burst sizes allow more bursting to allow the queue to attain its shaped rate under bursty congestion scenarios.
Special Shaping Rate for Nonstrict Queues

To remove additional jitter, you can configure the nonstrict queue with a special shaping rate that causes the hardware to temporarily eject the queue from the active round robin whenever it sends a frame. The result is that at most one nonstrict frame can precede a relative strict-priority frame. The special shaping rate is the same rate as the aggregate rate, but with a configured burst size of 1. You can still configure a shaping rate for the zero-weighted queue or node. This is useful for limiting starvation of the nonstrict traffic in the aggregate.
188
In Figure 41, the VC node is shaped in the HRR scheduler to 1 Mbps to limit the aggregate traffic for the subscriber. The relative strict traffic is shaped to 500 Kbps. This shaping limits relative strict traffic to 500 Kbps, and prevents the relative strict-priority traffic from starving out the nonstrict traffic. The third shaper, on the nonstrict queue, is subtle. The rate is 1 Mbps, which allows the nonstrict traffic to consume up to the full aggregate rate of the VC. But the burst size is 1, which causes the nonstrict queue to always yield to the relative strict-priority queue after sending a packet. This burst size limits the number of nonstrict packets that can precede a relative strict-priority packet to the minimum, one packet.
Figure 41: Tuning Latency on Strict-Priority Queues
{VC1, Nonstrict} 1 Mbps
{VC1, Relative strict} 500 Kbps
VC1
{VC1, Aggregate} 1 Mbps
Configuring Relative Strict-Priority Scheduling

This section shows how to configure the example in Figure 42. The example has two queues and a node that are shaped to a shared shaping rate of 1 Mbps. One queue is relative strict priority and is shaped to 500 Kbps. The other queue and the aggregate node divide the residual bandwidth equally.
Figure 42: Relative Strict-Priority Configuration Example
{VC1, Nonstrict} be
{VC1, Relative strict} strict
500 Kbps VC1 {VC1, Aggregate}

g013719
vcAggregate 1 Mbps
g013718
OC3 rate
189
To configure relative strict priority as shown in Figure 42: 1. Create a scheduler profile for the strict-priority queue.
host1(config)#scheduler-profile relativeStrict host1(config-scheduler-profile)#shaping-rate 500000 host1(config-scheduler-profile)#weight 0 host1(config-scheduler-profile)#exit
2. Create a scheduler profile for the nonstrict best-effort queue.

host1(config)#scheduler-profile be host1(config-scheduler-profile)#shaping-rate 1000000 burst 1 host1(config-scheduler-profile)#weight 8 host1(config-scheduler-profile)#exit
3. Create a scheduler profile for the VC aggregate node.

host1(config)#scheduler-profile vcAggregate host1(config-scheduler-profile)#shaping-rate 1000000 host1(config-scheduler-profile)#exit
4. Create a QoS profile, configure ATM VC node shaping for each queue, and add each of the queues to the QoS profile.
host1(config)#qos-profile relative-strict-aggregate host1(config-qos-profile)#atm-vc node scheduler-profile vcAggregate host1(config-qos-profile)#atm-vc queue traffic-class best-effort scheduler-profile be host1(config-qos-profile)#atm-vc queue traffic-class voice scheduler-profile relativeStrict host1(config-qos-profile)#exit host1(config)#
Note that if you need to impose a shaping rate on the nonstrict queues to meet a functional requirement, you can specify a rate less than the aggregate rate. The key is that the burst size must be one, or small. The burst size determines the maximum-sized packet that can squeeze in front of a relative strict-priority packet in the round robin. atm-vc node
! !
Use to configure a scheduler node for interfaces of the specified type. The optional scheduler profile supplies a relative weight and potentially a shaping rate to be applied at the scheduler node. Example
host1(config-qos-profile)#atm-vc node scheduler-profile scheduler1 group strict-priority
190
qos-profile
! !
Use to create a QoS profile and enter QoS Profile Configuration mode. Example
scheduler-profile
!
Use to create a scheduler profile and enter Scheduler Profile Configuration mode. The router supports up to 1,000 scheduler profiles. Example
! !
Use the no version to remove the scheduler profile.
shaping-rate
! !
Use to set the shaping rate of the scheduler node or queue in bits per second. Shaping rate range is 640001000000000 bps (64 Kbps to 1 Gbps); default is no shaping rate. The router rounds the rate to the next higher 8 Kbps. Burst is the catch-up number associated with the shaper; the range is 0522240. Specifying 0 enables the router to select an applicable default value. Example
host1(config-scheduler-profile)#shaping-rate 128000 burst 32767
Use the no version to delete the shaping rate.
weight
! ! !
Use to set the HRR weight of the scheduler node or queue. The weight value is in the range 04080. Example
host1(config-scheduler-profile)#weight 12
Use the no version to set the weight setting to the default weight, 8.
Rate Shaping
Rate shaping throttles the rate at which queues transmit packets. Rate shaping is TCP friendly; that is, it buffers packets that are above the rate, rather than dropping them. The router supports 64,000 rate shapers per line module. Shaping rates are multiples of 1 Kbps.
NOTE: You configure rate shaping in the scheduler profile. See Configuring
Scheduler Profiles on page 116.

!
Rate Shaping
191
Port Shaping
Port shaping allows you to shape the aggregate traffic through a port or channel to a rate that is less than the line or port rate. It works by allowing you to configure scheduler nodes at the port level, as shown in Figure 43.
Figure 43: Port Shaping on an Ethernet Module
VLAN
VLAN
Ethernet HRR scheduler Port shaper
The per-port shaping feature provides the ability to shape the output of a port. You configure port shaping in a QoS profile using the node command with the atm, serial, ethernet, or server-port keyword to specify the port type. For example, to shape Fast Ethernet port 2/0 to a rate no higher than 80 Mbps:
host1(config)#scheduler-profile 80mbps host1(config-scheduler-profile)#shaping-rate 80000000 host1(config-scheduler-profile)#exit host1(config)#qos-profile 80mbps host1(config-qos-profile)#ethernet node scheduler-profile 80mbps host1(config-qos-profile)#exit host1(config)#interface fastethernet 2/0 host1(config-if)#qos-profile 80mbps
To shape the corresponding HDLC channel down to 20 Mbps:

host1(config)#scheduler-profile 20mbps host1(config-scheduler-profile)#shaping-rate 20000000 host1(config-scheduler-profile)#exit host1(config)#qos-profile 20mbps host1(config-qos-profile)#serial node scheduler-profile 20mbps host1(config-qos-profile)#exit host1(config)#interface serial 2/0:1/1 host1(config-if)#qos-profile 20mbps
192
Port Shaping
g014362
Clearing Statistics
To clear QoS-related statistics, use the following commands. clear egress-queue
!
Use to clear statistics from the egress queue for the specified interface and traffic class. Use the explicit keyword to clear queues only on the specified interface and not queues stacked above the interface. Example
host1#clear egress-queue atm 3/0 explicit traffic-class class15
There is no no version.
clear fabric-queue
!
Use to clear statistics from the fabric queue for the specified traffic class and egress slot. The default is that statistics for all traffic classes and all slots are cleared. Example
host1#clear fabric-queue traffic-class class15 egress-slot 3
! !
There is no no version.
Monitoring QoS
To monitor the elements and profiles that QoS supports, use the following commands. show atm interface show interfaces atm
!
Use to display ATM port queuing mode and QoS shaping mode status for a specific ATM interface. For a detailed description of all fields displayed by this command see JUNOSe Link Layer Configuration Guide. Related field descriptions
!
qos-mode-portPer-port queuing mode status: disabled, low-latency, low-cdv qos-shaping-modeQoS shaping mode: disabled, frame, cell, none
! !
ExampleThis example shows a partial output that includes the qos-mode-port and qos-shaping-mode information
host1#show interfaces atm 2/0 ATM Interface 2/0 is up, line protocol is disabled AAL5 operational status: up time since last status change: 01:08:32 ATM operational status: up time since last status change: 01:08:32
Clearing Statistics
193
. . . InPackets: InBytes: InCells: OutPackets: OutBytes: OutCells: InErrors: OutErrors: InPacketDiscards: InByteDiscards: InCellErrors:
0 0 0 7803262 7803262000 163868502 0 0 0 0 0
Administrative qos-shaping-mode: frame Operational qos-shaping-mode: frame Administrative qos-mode-port: none Operational qos-mode-port: none Operational qos-mode-port: nonequeue 0: traffic class control, bound to ATM2/0 Queue length 0 bytes Forwarded packets 0, bytes 0 Dropped committed packets 0, bytes 0 Dropped conformed packets 0, bytes 0 Dropped exceeded packets 0, bytes 0
show drop-profile
! !
Use to display information about a drop profile. Field descriptions

! !
drop profileName of the drop profile Average length exponentExponent used to weight the average queue length over time, controlling WRED responsiveness committed thresholdMinimum and maximum committed queue thresholds and maximum drop probability conformed thresholdMinimum and maximum conformed queue thresholds and maximum drop probability exceeded thresholdMinimum and maximum exceeded queue thresholds and maximum drop probability
Example
host1#show drop-profile committed threshold: Average min, drop length max, profile exponent max drop prob ------- -------- ----------------default 0 0, <none>, <none> drop1 10 0, 750000, 80% drop2 10 0, 750000, 80% drop3 10 0, 750000, 80% drop4 10 0, 750000, 80% drop5 0 0, 750000, 80% drop6 10 0, <none>, <none> drop7 10 10%, 90%, 5% conformed threshold: min, max, max drop prob ----------------0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> exceeded threshold: min, max, max drop prob ----------------0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none> 0, <none>, <none>
194
Monitoring QoS
drop8 drop9 drop10 drop11 drop12 drop13 drop14 drop15
10 10 10 10 10 10 10 10
0, 0, 0, 0, 0, 0, 0, 0,
750000, 750000, 750000, 750000, 750000, 750000, 750000, 750000,
80% 80% 80% 80% 80% 80% 80% 80%
0, 0, 0, 0, 0, 0, 0, 0,
<none>, <none>, <none>, <none>, <none>, <none>, <none>, <none>,
<none> <none> <none> <none> <none> <none> <none> <none>
0, 0, 0, 0, 0, 0, 0, 0,
<none>, <none>, <none>, <none>, <none>, <none>, <none>, <none>,
<none> <none> <none> <none> <none> <none> <none> <none>
show egress-queue events

!
Use to display information about egress queue forwarding and drop event counts. For information about configuring egress queue events, see Statistics Profiles on page 147. Use the explicit keyword to display events for queues only on the specified interface and not stacked above the interface. Use the summary keyword to display the sum of events for the queues bound to interfaces that are stacked above the specified interface. Use the traffic-class keyword to display events for queues belonging to a specific traffic class. Use the event-exceeding keyword together with the committed, conformed, exceeded, or forwarded keywords to filter output based on the number of events that exceed the specified value. Field descriptions
! ! ! ! ! ! !
interfaceName of the interface traffic className of the traffic class forwarded eventsNumber of forwarded rate events committed drop eventsNumber of committed drop events conformed drop eventsNumber of conformed drop events exceeded drop eventsNumber of exceeded drop events rate period countTime frame during which events are counted
Example
host1#show egress-queue events gigabitEthernet 1/0 committed drop events --------0 132 0 0 conformed drop events --------0 0 132 0 exceeded drop events --------0 0 0 132 rate period count --------132 132 132 132
interface ---------------------ip GigabitEthernet1/0
traffic class ------tc1 tc2 tc3 tc4
forwarded events --------132 132 6 0
Monitoring QoS
195
show egress-queue rates

!
Use to display information about egress queue forwarding and drop rates. For information about configuring egress queue forwarding see Statistics Profiles on page 147. This command is useful even if no statistics profiles are configured. Use the full keyword to display all of the configured queues, along with the minimum and maximum rates for the queues, even when statistics gathering has not been enabled.
Use the color keyword to display statistics by color rather than as an aggregate of all colors. Use the previous and current keywords to display statistics for the previous or current rate period; previous is the default. Use the full keyword to display statistics for all queues or the brief keyword to limit the display only to those queues that have rate statistics enabled; brief is the default. Use the explicit keyword to display statistics for queues bound to the specified interface. Use the summary keyword to display the sum of all rates of queues bound to interfaces that are stacked above the specified interface. Use the traffic-class keyword to display rates for queues belonging to a specific traffic class. Use the rate-exceeding keyword together with the aggregate, committed, conformed, exceeded, forwarded, minimum, or maximum keywords to filter output based on queues whose rates exceed the specified value. Field descriptions
! ! ! ! ! ! ! ! !
interfaceName of interface traffic className of the traffic class forwarded rateForwarded rate statistics aggregate drop rateTotal number of all drop rates committed drop rateDrop rate for green packets conformed drop rateDrop rate for yellow packets exceeded drop rateDrop rate for red packets Queues reportedNumber of queues reported Queues filteredNumber of queues not reported because they are under the threshold Queues disabled (no rate period)Number of queues not displayed because statistics gathering is disabled (that is, the referenced statistics profile does not have a rate period set) Queues disabled (no resources)Number of queues not displayed because no resources were available Total queuesTotal number of queues within the hierarchical scope of the command
196
Monitoring QoS
Example 1
host1#show egress-queue rates brief fastEthernet 9/0.2 traffic forwarded aggregate minimum maximum interface class rate drop rate rate rate ---------------------- ----------------------- --------- --------- ------- ------ip FastEthernet9/0.2 best-effort 0 0 25000 1000000 videoTrafficClass 0 0 375000 1000000 multicastTrafficClass 0 0 925000 1000000 internetTrafficClass 0 0 50000 1000000 Total: Queues reported: Queues filtered (under threshold): Queues disabled (no rate period): Queues disabled (no resources): Total queues: ! 4 0 0 0 4 0 0
Example 2
conformed drop rate -----------0 0 4707200 0 exceeded drop rate -----------0 0 0 6705600
host1#show egress-queue rates color gigabitEthernet 1/0 traffic forwarded committed interface class rate drop rate ---------------------- ------- ------------ -----------ip GigabitEthernet1/0 tc1 14645184 0 tc2 11950400 2706400 tc3 9960792 0 tc4 7967200 0 Queues reported: Queues filtered (under threshold): Queues disabled (no rate period): Queues disabled (no resources): Total queues: ! 4 0 1 0 5
Example 3
minimum rate -------24979 14987510 9991673 4995836 19980 11988011 7992007 maximum rate -------30000000 30000000 30000000 30000000 20000000 20000000 20000000
host1#show egress-queue rates full atm 11/0 traffic forwarded aggregate interface class rate drop rate --------------- ------------- --------- --------ip ATM11/0.1 best-effort * * tc1 0 0 tc2 0 0 tc3 0 0 ip ATM11/0.2 best-effort * * tc1 0 0 tc2 0 0 Queues reported: Queues filtered (under threshold): * Queues disabled (no rate period): **Queues disabled (no resources): Total queues: 5 0 2 0 7
Monitoring QoS
197
show fabric-queue
! !
Use to display forwarded and dropped statistics for the fabric. If you do not specify one of the keywords (traffic-class, egress-slot, or detail), this command displays general data about the fabric queue. Field descriptions
!
traffic className of the traffic class for which statistics are being displayed egress slotEgress slot for which statistics are being displayed typeType of packet forwarded packetsNumber of forwarded packet forwarded bytesNumber of forwarded bytes dropped packetsNumber of dropped packets dropped bytesNumber of dropped bytes
! ! ! ! ! ! !
Example
host1#show fabric-queue traffic egress class slot type -----------------------best-effort all committed best-effort all conformed best-effort all exceeded forwarded packets --------0 0 0 forwarded bytes --------0 0 0 dropped packets ------0 0 0 dropped bytes ------0 0 0
show ip interface
! !
Use to display QoS parameters on a particular interface. A dynamic IP interface can have a QoS profile attached by RADIUS. For example, if configured by RADIUS, the show ip interface command might show the following:
Attached QoS profile: Strict-qos
However, if the profile is configured statically, the QoS profile is attached to the ATM subinterface, and the attachment is displayed by the show atm subinterface command rather than show ip interface.
!
Related field descriptions

!
queue 0Number of the queue for which statistics are being displayed and whether the queue is under traffic class control traffic className of traffic class bound toInterface to which queue is bound Queue lengthSize of queue in length and bytes ForwardedNumber of forwarded packets and bytes Dropped committedNumber of committed packets and bytes dropped Dropped conformedNumber of conformed packets and bytes dropped Dropped exceededNumber of exceeded packets and bytes dropped Dropped by WRED committedNumber of committed packets and bytes dropped by WRED
! ! ! ! ! ! ! !
198
Monitoring QoS
Dropped by WRED conformedNumber of conformed packets and bytes dropped by WRED Dropped by WRED exceededNumber of exceeded packets and bytes dropped by WRED Average queue lengthAverage length of queue in bytes
! !
Example
host1#show ip interface atm 2/0.1 ATM2/0.1 line protocol Atm1483 is up, ip is up Network Protocols: IP Internet address is 90.120.1.1/255.255.0.0 Broadcast address is 255.255.255.255 Operational MTU = 9180 Administrative MTU = 0 Operational speed = 155520000 Administrative speed = 0 Discontinuity Time = 722186 Router advertisement = disabled Proxy Arp = disabled Administrative debounce-time = disabled Operational debounce-time = disabled Access routing = disabled Multipath mode = hashed In Received Packets 2, Bytes 256 Unicast Packets 2, Bytes 256 Multicast Packets 0, Bytes 0 In Policed Packets 0, Bytes 0 In Error Packets 0 In Invalid Source Address Packets 0 In Discarded Packets 0 Out Forwarded Packets 2, Bytes 256 Unicast Packets 2, Bytes 256 Multicast Routed Packets 0, Bytes 0 Out Scheduler Dropped Packets 0, Bytes 0 Out Policed Packets 0, Bytes 0 Out Discarded Packets 0 queue 0: traffic class best-effort, bound to ip ATM2/0.1 Queue length 0 Bytes Forwarded packets 0, Bytes 0 Dropped committed packets 0, Bytes 0 Dropped conformed packets 0, Bytes 0 Dropped exceeded packets 0, Bytes 0 Dropped by WRED committed packets 0, bytes 0 Dropped by WRED conformed packets 0, bytes 0 Dropped by WRED exceeded packets 0, bytes 0 Average queue length 150576 bytes queue 1: traffic class tc1, bound to ip ATM2/0.1 Queue length 0 Bytes Forwarded packets 0, Bytes 0 Dropped committed packets 0, Bytes 0 Dropped conformed packets 0, Bytes 0 Dropped exceeded packets 0, Bytes 0 Dropped by WRED committed packets 0, bytes 0 Dropped by WRED conformed packets 0, bytes 0 Dropped by WRED exceeded packets 0, bytes 0 Average queue length 150576 bytes
Monitoring QoS
199
show qos interface-hierarchy

!
Use to display the QoS profiles in effect for and stacked above the specified interface. If there are no QoS profiles attached to the interface or above the interface, the router displays the QoS profile that is in effect down the interface stack toward the port interface. Field descriptions
! ! ! ! ! ! ! !
attachment@Interface for which the hierarchy is being displayed qos profileName of the QoS profile and its attachment point t-class groupTraffic-class groups associated with the interface interface typeType of interface to which the profile is attached rule typeQueue, node, or group traffic className of the traffic class associated with the queue scheduler profileScheduler profiles associated with the interface queue profileQueue profiles associated with the interface
Example
host1#show qos interface-hierarchy atm 11/0.1 attachment@ atm-vc ATM11/0.1: t-class interface rule traffic qos profile group type type class --------------- ------- --------- ----- ----------qp2@ATM11/0.1 atm-vc node qp2@ATM11/0.1 atm-vp node qp2@ATM11/0.1 atm-vc queue best-effort qp2@ATM11/0.1 atm-vc queue tc5 qp2@ATM11/0.1 atm-vc queue tc6 qp2@ATM11/0.1 g1 atm group qp2@ATM11/0.1 g1 atm-vc node qp2@ATM11/0.1 g1 atm-vp node qp2@ATM11/0.1 g1 atm-vc queue tc1 qp2@ATM11/0.1 g1 atm-vc queue tc2 qp2@ATM11/0.1 g2 atm-vp node qp2@ATM11/0.1 g2 atm-vc queue tc3 qp2@ATM11/0.1 g2 atm-vc queue tc4
scheduler profile -----------default default default default default strictShaper default default default default default default default
queue profile ------default default default default default default default default default default default default default
show qos-port-type-profile
! ! !
Use to display information about QoS port-type profiles. If you do not specify the profile name, data for all interface types is displayed. The default format contains a list of all the qos-port-type-profile commands as they have been entered. Example
host1#show qos-port-type-profile default-port-profile Ethernet qos-profile ethernet-default default-port-profile Atm qos-profile atm-default default-port-profile HDLC qos-profile serial-default default-port-profile ServerPort qos-profile server-default
200
Monitoring QoS
show qos-profile
! ! !
Use to display information about QoS profiles. If you do not specify the QoS profile name, data for all QoS profiles is displayed. Use the brief keyword to display a reference count for QoS profiles. The reference count is the number of times the QoS profile is referenced by an interface or protocol profile. Use the references keyword to display interface profiles that reference this profile. This command displays groups, nodes, and queues, in that order, according to the following sequence:
! ! !
not members of a traffic-class group members of the strict-priority traffic-class group members of an extended traffic-class group in the order of configuration qos-profileName of QoS profile t-class groupName of the traffic-class group associated with the interface interface typeType of interface rule typeWhether the rule is a group node, scheduler node, or queue traffic className of the traffic class associated with the interface scheduler profileName of the scheduler profile associated with the interface queue profileName of the queue profile associated with the interface drop profileName of the drop profile associated with the interface statistics profileName of the statistics profile associated with the interface qos-profile referenced by attachmentNumber of interfaces to which the QoS profile is attached attachmentType of interface to which the QoS profile is attached
Field descriptions
! ! ! ! ! !
! ! !
! !
Example 1
host1#show qos-profile qpDiffServExample1 qos-profile qpDiffServExample1: interface rule traffic t-class group type type class -------------------- --------- ----- ----------ip queue tc3 ip queue tc4 ip queue tc5 expedited-forwarding ethernet group expedited-forwarding ip node expedited-forwarding ip queue voice best-effort ethernet group best-effort ip node best-effort ip queue best-effort assured-forwarding ethernet group assured-forwarding ip node assured-forwarding ip queue video
scheduler profile --------------best-effort best-effort best-effort expeditedGroup default voice bestEffortGroup default best-effort assuredGroup default video
queue profile ------default default default
drop profile ------default default default
statistics profile ---------default default default
default default default
Monitoring QoS
201
Example 2
host1#show qos-profile brief qos-profile atm-default referenced by 1 attachment qos-profile serial-default referenced by 1 attachment qos-profile ethernet-default referenced by 1 attachment qos-profile server-default referenced by 1 attachment
Example 3
host1#show qos-profile references qos profile attachment -------------------- ----------------------------------atm-default atm (qos-port-type-profile) serial-default serial (qos-port-type-profile) ethernet-default ethernet (qos-port-type-profile) server-default server-port (qos-port-type-profile)
show qos queue-thresholds

! !
Use to display the color-based thresholds for queues on each egress slot. Showing queue thresholds by queue profile shows buffer memory information for each queue profile and, within that profile, shows the thresholds for each region. Field descriptions
! ! ! !
queue-profileName of the queue profile regionEgress buffer memory region egress memoryAmount of memory in each region exceeded lengthAmount of exceeded traffic that can be queued at this egress memory usage conformed lengthAmount of conformed traffic that can be queued at this egress memory usage committed lengthAmount of committed traffic that can be queued at this egress memory usage total committed memoryAmount of committed memory allocated to the queue
Example 1 shows the color-based queue thresholds for each of the 2000 video queues when 8000 total queues are configured. As shown, when all of the egress memory in use is between 0 MB and 4 MB, each video queue can queue 139,648 bytes of committed traffic. Because the default conformed fraction is 50 percent and the default exceeded fraction is 25 percent, half of the committed length, or 69,888 bytes, can be queued before conformed traffic is dropped, and one quarter of the committed length, or 34,944 bytes, can be queued before exceeded traffic is dropped. As memory fills, the video queues are given progressively smaller amounts of memory. For example, when 28 to 32 MB of buffer memory is in use, each video queue is limited to 3456 bytes. As memory fills beyond the last region, all frames are dropped except control traffic, until the queues are drained and memory usage falls back into one of the regions.
202
Monitoring QoS
Example 1
host1#show qos queue-thresholds egress-slot 9 queue-profile video queue-profile video 2000 queues egress memory ----------0MB - 4MB 4MB - 8MB 8MB - 12MB 12MB - 16MB 16MB - 20MB 20MB - 24MB 24MB - 28MB 28MB - 32MB exceeded length -------34944 24448 14080 7040 5248 1280 1152 896 conformed length --------69888 48896 28032 14080 10496 2560 2176 1792 committed length --------139648 97792 55936 28032 20992 5120 4224 3456 total committed memory --------279296000 195584000 111872000 56064000 41984000 10240000 8448000 6912000
region -----0 1 2 3 4 5 6 7 !
Showing queue thresholds by region organizes the buffer memory information by queue region and, within each region, shows the buffer allocations for each queue profile. Example 2 shows the routers memory management. Static and dynamic oversubscription determines that when 8,000 queues are configured and 04 MB of egress buffer memory is in use, memory is oversubscribed by 3330 percent. If significantly fewer queues are configured, there is less oversubscription. This example illustrates static oversubscription. Because all of the queues in Example 2 use default queue profiles, all queues have the same lengths. Each queue is allocated 139,648 bytes of committed buffer memory when operating within this region. This allocation allows active queues to burst traffic by using memory that is unused by quiescent queues. This example illustrates dynamic oversubscription, which is based on the assumption that when a large number of queues is configured, only a fraction of the queues is active at a given time. As more queues become active, memory fills and spills into another region. When this occurs, queues are given progressively smaller queue limits. Example 2
host1#show qos queue-thresholds egress-slot 9 region 0 region 0 (0MB - 4MB) oversubscription 3330% exceeded length -------34944 34944 34944 34944 conformed length --------69888 69888 69888 69888 committed length --------139648 139648 139648 139648 queue count ----2000 2000 2000 2000 total committed memory --------279296000 279296000 279296000 279296000
queue-profile ------------default video multicast internet !
In memory regions 1 through 5, queue limits are progressively reduced. In region 6, memory is strictly partitioned among queues; oversubscription is 100 percent in Example 3.
Monitoring QoS
203
Example 3
When 2428 MB of the memory is in use, there is no oversubscription of egress buffer memory; 32 MB of the 32-MB memory is allocated. In this example, each of the 8000 egress queues is given a queue of 4224 bytes, for a total of 16 MB. If memory continues to fill into region 7, egress buffer memory is undersubscribed, allowing control traffic to flow within the router. As shown in Example 4, when operating in region 7, only 80 percent of the 32-MB memory is allocated. Example 4
Example 4 has 2000 IP users, each with four queues. Each of the four queues use default queue profiles. In Example 5, the multicast queue profile is configured with a committed length of 10,000 minimum and 20,000 maximum. When in regions 04, these queues would normally get more memory than the 20,000 byte maximum requested. In this case, the queue is limited to the maximum, and any excess memory is redistributed to other queues. Example 5
host1#show qos queue-thresholds egress-slot 9 queue-profile multicast queue-profile multicast 2000 queues total egress exceeded conformed committed committed region memory length length length memory ------ ----------- -------- --------- --------- --------0 0MB - 4MB 5120 10112 20096 40192000 1 4MB - 8MB 5120 10112 20096 40192000 2 8MB - 12MB 5120 10112 20096 40192000 3 12MB - 16MB 5120 10112 20096 40192000 4 16MB - 20MB 5120 10112 20096 40192000 5 20MB - 24MB 1280 2560 10112 20224000 6 24MB - 28MB 1152 2176 4224 8448000 7 28MB - 32MB 896 1792 3456 6912000
204
Monitoring QoS
In region 5, there is not enough memory to honor the 20,000 byte maximum requested. Although a 20,000 byte maximum was requested, the router provisions memory in 128 byte blocks, rounded up or down per each request; 20,096 bytes is 157 blocks of 128 bytes. In region 6, memory is strictly partitioned, and neither the minimum nor maximum request is honored. Instead, each multicast queue is given a fair share of the queue length so that aggressive bandwidth consumers cannot starve out moderate traffic consumers. In region 7, memory is underprovisioned to allow queues to drain and to avoid starvation that occurs when egress buffer memory fills completely. You could configure video queues with a buffer weight of 16 and Internet and multicast queues with a buffer weight of 8 to ensure that video queues get to queue twice as much traffic as Internet and multicast queues. See Example 6. Example 6
queue-profile ------------default video multicast internet
show qos shared-shaper

! !
Use to display information about the configured shared shapers. The best-effort queue is listed as the first resource for shared shapers that are queue controlled. The best-effort scheduler node is listed as the first resource for shared shapers that are node controlled. Comnpound shared shpers Field descriptions
! ! ! ! ! ! !
! !
interfaceType of interface resourceTraffic resource associated with the logical interface shared shaping rateConfigured shared shaping rate in bits per second shaping rateIndividual shaping rate of a traffic resource otherActual current shaping rate in bits per second Total shared shapersTotal number of shared shapers Total constituentsTotal number of resource constituents for all shared shapers Total shared shaper failoversTotal number of shared shapers that are disabled (in failover mode) due to lack of resources Compound shared shapers are [not] supportedIndication of whether compound shared shapers are supported; determined by installed hardware
Monitoring QoS
205
Example
host1#show qos shared-shaper atm 11/0 shared shaping shaping interface resource rate rate other ----------------- --------------------------- ------- ------- ----------atm-vc ATM11/0.10 A atm-vc node 500000 rate 500000 atm-vc queue best-effort atm-vc node EF A atm-vc queue EF voice 100000 atm-vc node AF A atm-vc queue AF video 200000 atm-vc ATM11/0.11 A atm-vc node 500000 rate 500000 atm-vc queue best-effort atm-vc node EF A atm-vc queue EF voice 100000 atm-vc node AF A atm-vc queue AF video 200000 Total shared shapers: 2 Total constituents: 12 Total shared shaper failovers: 0 Compound shared shapers are not supported
show queue-profile
! !
Use to display information about a queue profile. If you do not specify the queue profile name, data for all queue profiles is displayed. Use the brief keyword to display a reference count for queue profiles. The reference count is the number of times that a QoS profile references the queue profile. Use the references keyword to display a list of QoS profiles that reference the queue profile. Field descriptions
! !
queue profileName of the queue profile committed lengthGreater queue length than the length of the conformed or exceeded length conformed lengthA queue length that is less than the committed length but greater than the exceeded length exceeded lengthA queue length less than the conformed length which is less than the committed length conformed fractionPercentage of the total queue that can be occupied before conformed packets are dropped exceeded fractionPercentage of the total queue that can be occupied before exceeded packets are dropped buffer weightWeight of the queue
206
Monitoring QoS
Example 1 This is the default format.

host1#show queue-profile committed queue length: profile min, max --------------default 0, <none> conformed length: min, max --------0, <none> exceeded length: min, max --------0, <none> fraction: conformed, buffer exceeded weight ---------- -----50, 25 8
Example 2
host1#show queue-profile brief queue-profile default referenced 31 times in qos-profiles
Example 3
host1#show queue-profile references queue-profile default Referenced by QoS profiles: atm-default serial-default ethernet-default server-default
show scheduler-profile
! !
Use to display information about a scheduler profile. If you do not specify the scheduler profile name, data for all scheduler profiles is displayed. Use the brief keyword to display a reference count for scheduler profiles. The reference count is the number of times that a QoS profile references the scheduler profile. Use the references keyword to display a list of QoS profiles that reference the scheduler profile. Field descriptions
! !
schedulerName of the scheduler profile shaping rateMaximum bandwidth, in bits per second, provided to a node or queue burstCatch-up number associated with the shaper weightHRR weight of a node or queue strict priorityStatus of strict priority assured rateDesired bandwidth, in bits per second, provided to a node or queue, or the keyword, hierarchical, to indicate that HAR is used Referenced by QoS profilesQoS profiles that reference this scheduler profile
! ! ! !
Monitoring QoS
207
Example 1
host1#show scheduler-profile shaping scheduler rate burst ------------------default <none> 32767 wf100 128000 32767 spSV25 5000000 32767 videoHar <none> 32767 strict priority -------no no no no
weight -----8 20 40 8
assured rate -----------<none> 75000 64000 hierarchical
Example 2
host1#show scheduler-profile brief scheduler-profile default referenced 39 times in qos-profiles scheduler-profile wf100 referenced 1 time in qos-profiles
scheduler-profile spSV25 referenced 2 times in qos-profiles

!
Example 3
host1#show scheduler-profile references scheduler-profile default Referenced by QoS profiles: atm-default serial-default ethernet-default server-default scheduler-profile wf100 Referenced by QoS profiles: ipV610 scheduler-profile spSV25 Referenced by QoS profiles: qospro25
show statistics-profile
! !
Use to display information about a statistics profile. If you do not specify a profile name, information for all statistics profiles is displayed. Use the brief keyword to display a reference count for statistics profiles. The reference count is the number of times that a QoS profile references the statistics profile. Use the references keyword to display a list of QoS profiles that reference the statistics profile. Field descriptions
! !
statistics profileName of the statistics profile forwarding rate thresholdThreshold above which forwarded-rate-exceeded events are counted committed drop thresholdThreshold above which committed-drop-events are counted conformed drop thresholdThreshold above which conformed-drop-events are counted
208
Monitoring QoS
exceeded drop thresholdThreshold above which exceeded-drop-events are counted rate periodTime frame during which statistics are gathered
! !
Example
host1#show statistics-profile forwarding committed statistics rate drop profile threshold threshold --------------------------default <none> <none> statpro-1 10000000 2000000 conformed drop threshold --------<none> 4000000 exceeded drop threshold --------<none> 6000000
rate period -----<none> 30
show traffic-class
! !
Use to display information about a traffic class. If you do not specify the traffic-class name, data for all traffic classes is displayed. Use the brief keyword to display a reference count for traffic classes. The reference count is the number of times that a QoS profile references the traffic class. Use the references keyword to display a list of QoS profiles and traffic-class groups that reference the traffic class. Field descriptions
! ! ! ! !
traffic className of the traffic class fabric weightWeight of the queue in the fabric fabric strict prioritySetting strict-priority queues in the fabric Referenced by QoS profilesQoS profiles that reference this traffic class Referenced by traffic class groupsTraffic-class groups that reference this traffic class
Example 1
host1>show traffic-class fabric traffic fabric strict class weight priority ----------------------best-effort 8 no best-effort 8 no tc1 8 no tc2 8 no tc3 8 no tcs4 8 yes tcs5 8 yes
Example 2
host1#show traffic-class brief traffic-class best-effort referenced 17 times in qos-profiles
Monitoring QoS
209
Example 3
host1#show traffic-class reference traffic-class best-effort Referenced by QoS profiles: atm-default serial-default ethernet-default server-default Referenced by traffic class groups: None
show traffic-class-group
! !
Use to display the name of a traffic-class group and the classes in the group. Use the brief keyword to display a reference count, the number of times the each traffic-class group is referenced by a profile. Use the references keyword to display interface profiles that reference the configured traffic-class groups. Field descriptions
! ! !
traffic-class groupName of the traffic-class group traffic-className of the traffic class Referenced in qos-profilesNumber of times group is referenced by QoS profiles Referenced by QoS profilesQoS profiles that reference this traffic class
! !
Examples
host1#show traffic-class-group traffic-class-group assured-fwd traffic-class video traffic-class-group assured-fwd slot 11 traffic-class video traffic-class voice host1#show traffic-class-group brief traffic-class-group g2 referenced 1 time in qos-profiles traffic-class-group g3 referenced 1 time in qos-profiles traffic-class-group g4 referenced 0 times in qos-profiles traffic-class-group g1 referenced 0 times in qos-profiles host1#show traffic-class-group references traffic-class-group g2 Referenced by QoS profiles: profile1 traffic-class-group g3 Referenced by QoS profiles: None
210
Monitoring QoS
Index
A
Ascend-Data-Filter (RADIUS attribute 242)........................47 policy format .............................................................47 ASIC scheduler..................................................................92 assured rate ......................................................................93 assured-rate command ...................................................117 ATM (Asynchronous Transfer Mode) cell shaping .............................................................158 frame shaping .........................................................158 monitoring ..............................................................193 shaping....................................................................158 status. See monitoring ATM modules with relative strict priority.........................186 minimizing latency on the SAR ...............................187 oversubscribing .......................................................187 atm vp-tunnel command ................................................165 atm-vp qos-profile command..................................154, 171 audience for documentation ............................................... x classifier control list creating or modifying ................................................18 matching IP flags .......................................................23 matching IP fragmentation offset ..............................23 matching TCP flags..............................................22, 24 multiple elements in ..................................................21 classifier groups creating .....................................................................36 classifier-group command.................................................39 clear egress-queue command..........................................193 clear fabric-queue command ..........................................193 color command ................................................................40 color-based thresholds ....................................................102 committed drop threshold ..............................................147 committed-action command.............................................12 committed-burst command ..............................................12 committed-drop-threshold command .............................150 committed-length command...........................................104 committed-rate command ................................................13 committed-threshold command......................................107 compound shared shaping. See shared shaping conformed drop threshold ..............................................147 conformed-action command.............................................13 conformed-drop-threshold command .............................150 conformed-fraction command ........................................104 conformed-length command...........................................104 conformed-threshold command......................................107 constituents, shared-shaping...........................................122 conventions defined icons............................................................................x text and syntax............................................................x customer support............................................................. xiii
B
backpressure ..................................................................156 required QoS profile ................................................156 bandwidth management...................................................56 best effort ...................................................................93, 97 best-effort queue...............................................................93 best-effort scheduler node ................................................93 buffer-weight command .................................................104 burst size, setting in a shaping rate .................................188
C
CDs JUNOSe software CD ................................................. xii CDV ..................................................................................93 CDVT ........................................................................93, 159 cell delay variation. See CDV cell delay variation tolerance. See CDVT classifier CAM hardware ....................................................63, 66 consumption .............................................................67 FPGA hardware ...................................................63, 65 hardware .............................................................63, 66 line module support ......................................63, 64, 65 policy consumption .............................................63, 67 software ..............................................................63, 67
D
Diffserv configuration example.............................................178 networks ...................................................................92 documentation set, E-series ...............................................xi comments on ........................................................... xiii drop profile .....................................................................105 dynamic shaping of traffic ..............................................118
E
effective weight.................................................................93 ERX-14xx models ...............................................................x ERX-7xx models .................................................................x E-series documentation set ................................................xi comments on ........................................................... xiii E-series models...................................................................x
Index
!
211
exceeded drop threshold ................................................ 147 exceeded-action command............................................... 14 exceeded-drop-threshold command ............................... 150 exceeded-fraction command .......................................... 104 exceeded-length command............................................. 104 exceeded-threshold command........................................ 107 excess-burst command..................................................... 14 explicit packet coloring..................................................... 59 exp-mask command......................................................... 14
latency..............................................................................93 log command ...................................................................41
M
manuals, E-series............................................................... xi comments on ........................................................... xiii mark command................................................................42 mark-de command ...........................................................42 mark-exp command .........................................................42 mark-user-priority command............................................43 mask-val command ..........................................................15 MIBs (Management Information Bases) ........................... xiii models ERX-14xx .................................................................... x ERX-7xx ...................................................................... x E-series........................................................................ x monitoring ATM interfaces ........................................................193 QoS .........................................................................193 MPLS policy management and............................................62 mpls classifier-list command ............................................26 mpls commands mpls classifier-list ......................................................63 mpls ldp lsp-policy...............................................62, 63 mpls rate-limit-profile command. See rate-limit-profile commands MTU (maximum transmission unit) IP...............................................................................76 multiple forwarding solutions ...........................................38 munged QoS profile........................................................172 attachments ............................................................172
F
fabric-strict-priority command.......................................... 98 fabric-weight command.................................................... 98 filter command................................................................. 40 forward command...................................................... 38, 41 forwarding rate threshold ............................................... 147 forwarding-rate-threshold command .............................. 151 fragmentation offsets, filtering.......................................... 23 frame-relay classifier-list command .................................. 18
G
gre-tunnel classifier-list command .................................... 19 group command ............................................................. 153 group node ....................................................................... 93
H
HAR.................................................................................. 93 hierarchical assured rate. See HAR hierarchical round-robin. See HRR hierarchy, QoS scheduler .................................................. 94 HRR.......................................................................... 93, 182 HRR scheduler................................................................ 155 relative strict priority on.................................. 184, 187
N
next-hop command ..........................................................43 next-interface command...................................................43 node best-effort scheduler..................................................93 group.........................................................................93 scheduler...................................................................94 node command ......................................................154, 190 notice icons defined ........................................................... x
I
icons defined, notice .......................................................... x implicit constituents selection for compound shared shaping .................. 125 selection for simple shared shaping ........................ 124 installing the system software............................................ ix interface profile attachments .......................................... 170 ip classifier-list command ........................................... 19, 24 ip commands ip filter-options all ..................................................... 46 IP fragmentation offset, matching in a policy ....................................... 23 IP options, filtering ........................................................... 46 ip rate-limit-profile command. See rate-limit-profile commands ipv6 rate-limit-profile command. See rate-limit-profile commands
P
packet coloring, explicit ....................................................59 packet mirroring .................................................................3 packet tagging ..................................................................59 peak-burst command........................................................15 peak-rate command..........................................................15 policy action .......................................................................2 policy commands frame-relay policy .....................................................45 gre-tunnel policy........................................................45 ip policy ....................................................................45 l2tp policy .................................................................45 mpls policy................................................................45 vlan policy .................................................................45
L
l2tp classifier-list command.............................................. 26 l2tp rate-limit-profile command. See rate-limit-profile commands L2TP sessions QoS ......................................................................... 167
212
Index
Index
policy list applying to an interface.............................................45 constructing a..............................................................3 creating or modifying ................................................28 description of ..............................................................2 Fast Ethernet port on SRP module.............................45 policy management applications ...............................................................54 bandwidth management ....................................56 packet mirroring ..................................................3 packet tagging ....................................................59 policy routing .....................................................54 secure policies......................................................3 security ..............................................................55 applying a policy list to an interface ..........................45 Fast Ethernet port on SRP module .....................45 bandwidth management ...........................................56 baselining statistics..............................................46, 68 classifier control lists .................................................18 classifier groups, creating ..........................................36 classifier resources ....................................................66 committed burst calculation ................................13, 15 congestion management ...........................................56 constructing a policy list ..............................................3 creating a classifier control list ..................................18 creating a one-rate rate-limit profile ..........................11 creating a policy list...................................................28 creating a two-rate rate-limit profile ..........................11 creating with RADIUS ................................................47 explicit packet coloring..............................................59 filtering fragmentation offsets ...................................23 filtering IP options .....................................................46 matching IP flags in a CLACL.....................................23 matching IP fragmentation offset in a CLACL ............23 matching TCP flags in a CLACL............................22, 24 modifying a classifier control list ...............................18 modifying a one-rate rate-limit profile .......................11 modifying a policy list ...............................................28 modifying a two-rate rate-limit profile .......................11 monitoring ................................................................69 monitoring packet flow .............................................60 MPLS and ..................................................................62 one-rate rate-limit profile...........................................57 overview......................................................................2 packet mirroring..........................................................3 packet tagging ...........................................................59 policy actions and rate-limit profiles............................8 policy lists .............................................................2, 28 policy routing ........................................................2, 54 policy rules, creating .................................................36 QoS classification and marking ...................................2 RADIUS .....................................................................47 rate limiting.................................................................2 rate-limit profile actions ..............................................8 rate-limit profile attributes...........................................8 rate-limit profile calculations .....................................16 rate-limit profile defaults .....................................16, 17 rate-limit profiles .........................................................5 rate-limiting traffic flows ...........................................58 rules ............................................................................2
secure policies .............................................................3 security......................................................................55 statistics ....................................................................46 two-rate rate-limit profile ...........................................57 policy management commands gre-tunnel policy........................................................70 ip policy.....................................................................70 l2tp policy..................................................................70 vlan policy .................................................................70 policy rules creating .....................................................................36 supported commands................................................37 policy-list commands frame-relay policy-list command ...............................36 gre-tunnel policy list command .................................36 ip policy-list command ..............................................36 ipv6 policy-list command...........................................36 l2tp policy-list command ...........................................36 mpls policy-list command..........................................36 vlan policy-list command...........................................36 port shaping....................................................................192 port-type profile, QoS........................................................94 attachments.............................................................171 profile drop.........................................................................105 QoS .........................................................................151 attachment .........................................................94 port-type ............................................................94 rules illustrated.........................................181, 182 scheduler .................................................................114 statistics ..................................................................147
Q
QoS assured rate...............................................................93 best effort ..................................................................93 best-effort queue .......................................................93 best-effort scheduler node .........................................93 CDV ...........................................................................93 CDVT .........................................................................93 color-based thresholds.............................................102 description of ............................................................92 differentiated services assured forwarding.............................................92 expedited forwarding .........................................92 Diffserv configuration example................................178 drop profile..............................................................105 dynamic traffic shaping ...........................................118 effective weight .........................................................93 extends Diffserv ........................................................92 features .....................................................................94 group node ................................................................93 HAR...........................................................................93 hierarchical round-robin ..........................................182 HRR...........................................................................93 interface profile attachments .....................................................170 L2TP sessions ..........................................................167 latency.......................................................................93
Index
213
monitoring .............................................................. 193 multiple traffic class configuration example ............ 178 multiple traffic-class groups....................................... 99 munged profile........................................................ 172 nodes best-effort scheduler .......................................... 93 group ................................................................. 93 scheduler ........................................................... 94 operational shaping mode operational QoS shaping mode ........................ 158 overview ................................................................... 92 port shaping ............................................................ 192 port-type profile ........................................................ 94 port-type profile attachments .................................. 171 profile attachment......................................................... 94 drop ................................................................. 105 QoS.................................................................. 151 rules illustrated ........................................ 181, 182 scheduler ......................................................... 114 statistics ........................................................... 147 queue ........................................................................ 93 bandwidth........................................................ 182 profile .............................................................. 100 profile, configuring........................................... 103 rate shaping ...................................................... 94, 191 RED........................................................................... 94 and dynamic queue thresholds ........................ 112 configuration examples.................................... 108 configuring....................................................... 106 configuring average queue length .................... 108 configuring color blind RED ............................. 108 configuring colored RED .................................. 108 how it works .................................................... 106 relative strict-priority scheduling ............................. 184 RFCs.......................................................................... 96 scheduler assured rate ............................................. 114, 115 hierarchy............................................ 94, 114, 183 node .................................................................. 94 profile .............................................................. 114 profile, configuring........................................... 116 rate shaping ..................................................... 114 relative weight ................................................. 114 shaping rate ..................................................... 114 weight .............................................................. 115 shaping ATM ................................................................. 158 ATM cell shaping.............................................. 158 ATM frame shaping.......................................... 158 shared shaping ........................................................ 118 statistics .................................................................. 193 statistics profile ....................................................... 147 committed drop threshold ............................... 147 conformed drop threshold ............................... 147 event statistics ................................................. 149 exceeded drop threshold.................................. 147 failover mode................................................... 150 forwarding rate threshold................................. 147 maximum ........................................................ 147
rate period ...............................................147, 151 rate statistics ....................................................148 resource use.....................................................150 thresholds ........................................................150 strict-priority scheduling ..........................................182 TCP friendly ............................................................191 terms.........................................................................93 traffic class ................................................................97 configuring.........................................................97 traffic-class group ......................................................99 weight .......................................................................94 WRED .......................................................................94 configuration examples ............................110, 174 configuring .......................................................110 QoS profile attaching .................................................................170 attaching to interfaces .............................................154 configuring ..............................................................152 creating ...................................................................153 munged...................................................................172 QoS scheduler HRR.........................................................................155 QoS statistics ATM ................................................................159, 167 qos-mode-port command .......................................158, 166 qos-port-type-profile command ......................................171 qos-profile command..............................153, 155, 171, 191 qos-shaping-mode command .................................156, 167 queue ...............................................................................93 queue bandwidth............................................................182 queue buffers..................................................................102 queue command.............................................................154 queue length...................................................................102 queue profile ..................................................................100 configuring ..............................................................103 queue-profile command..................................................105
R
RADIUS applying policies........................................................47 random early detection. See RED rate shaping....................................................................191 QoS ...........................................................................94 rate-limit profiles attributes .....................................................................8 calculations ...............................................................16 creating .....................................................................11 default values ......................................................16, 17 modifying..................................................................11 one-rate.....................................................................57 policy actions ..............................................................8 two-rate.....................................................................57 rate-limiting aggregate traffic flows ...............................................58 individual traffic flows ...............................................58 rate-limit-profile commands rate-limit-profile.........................................................44 rate-limit-profile one-rate...........................................16 rate-limit-profile two-rate...........................................17
214
Index
Index
rate-period command .....................................................151 RED ..........................................................................94, 105 and dynamic queue thresholds................................112 configuration examples ...........................................108 configuring ..............................................................106 configuring average queue length............................108 configuring color blind RED.....................................108 configuring colored RED..........................................108 how it works............................................................106 relative strict-priority scheduling.....................................184 configuration example.............................................186 configuring ..............................................................189 on ATM modules .....................................................186 minimizing latency on the SAR ........................187 oversubscribing ................................................187 setting burst size in shaping rate .............................188 shaping rate for nonstrict queues ............................188 tuning latency on strict-priority queues ...................189 zero-weight queues..................................................188 release notes..................................................................... xii
S
SAR scheduler.................................................................155 strict-priority on ......................................................185 scheduler assured rate.....................................................114, 115 hierarchy ...................................................94, 114, 183 HRR.........................................................................155 node, best-effort ........................................................93 profile......................................................................114 configuring .......................................................116 rate shaping ............................................................114 relative weight.........................................................114 SAR .........................................................................155 shaping rate ............................................................114 weight .....................................................................115 scheduler-profile command ....................................117, 191 secure policies ..............................................................3, 87 security.............................................................................55 shapeless tunnel .....................................................165, 166 shaping rate for nonstrict queues ................................................188 setting burst size in .................................................188 shaping, QoS ATM...........................................................158 cell ..........................................................................158 frame ......................................................................158 shaping-rate command ...........................................117, 191 shared shaping active constituents...................................................122 burst rate.................................................................146 caveats ....................................................................145 compound ...............................................................122 active constituents ...........................................123 configuration....................................................139 configuration example, VC shared shaping ......141 configuration example, VP shared shaping.......143 configuration limitations ..................................141 example, weighted ...........................................129 hardware dependency......................................145
constituents .............................................................122 active ...............................................................122 comparison of explicit and implicit ..................131 inactive ............................................................123 explicit constituents example ...........................................................132 example of weighted ........................................133 selection ...................................................123, 131 implicit constituents example at best-effort node..............................125 example at best-effort queue ............................126 example for mixed interface types ...................127 ordering for compound ....................................127 selection ...........................................................123 selection for compound....................................125 selection for simple ..........................................124 inactive constituents................................................123 individual shaping and.............................................139 limiting bandwidth ..................................................119 low-CDV mode ........................................................121 node-controlled .......................................................119 on the SAR, limitations of ........................................119 oversubscription ......................................................146 overview..........................................................118, 119 queue-controlled......................................................119 simple .....................................................................119 active constituents............................................123 configuration ....................................................135 configuration example, VC shared shaping.......136 configuration example, VP shared shaping.......137 example, basic .................................................120 example, on best-effort queue..........................120 example, on best-effort scheduler node............121 traffic starvation ......................................................146 types, simple versus compound...............................119 shared-shaping-constituent command ............................140 shared-shaping-rate command................................135, 139 show commands show atm interface ..................................................193 show classifier-list......................................................70 show drop-profile command....................................194 show egress-queue events command ......................195 show egress-queue rates command .........................196 show fabric-queue command ..................................198 show frame-relay subinterface...................................73 show gre tunnel.........................................................74 show interfaces .........................................................75 show ip interface .......................................................76 show ipv6 interface ...................................................79 show mpls interface l2transport ................................82 show policy-list ..........................................................84 show qos-port-type profile command ......................200 show qos-profile command .....................................201 show queue-profile command .................................206 show rate-limit-profile................................................86 show scheduler-profile command............................207 show secure policy-list...............................................87 show statistics-profile command .............................208
Index
215
show traffic-class command .................................... 209 show traffic-class-group command .......................... 210 show vlan subinterfaces ............................................ 89 show qos commands show qos interface-hierarchy command.................. 200 show qos queue-thresholds command .................... 202 show qos shared-shaper .......................................... 205 simple shared shaping. See shared shaping software, installing............................................................. ix statistics profile............................................................... 147 statistics-profile command.............................................. 151 strict-priority command.................................................. 118 strict-priority scheduling ................................................. 182 true versus relative .................................................. 185 support, requesting.......................................................... xiii
T
TCP friendly.................................................................... 191 technical support, requesting........................................... xiii terms QoS ........................................................................... 93 text and syntax conventions defined .................................. x traffic classes .................................................................... 97 configuring ................................................................ 97 multiple, configuration example.............................. 178 traffic flow ........................................................................ 93 traffic-class command .......................................... 44, 98, 99 traffic-class groups configuring ................................................................ 99 multiple..................................................................... 99 traffic-class-group command .......................................... 100 true strict priority scheduling.......................................... 185
U
updating the system software............................................ ix user-packet-class command.............................................. 44
V
vlan classifier-list command ............................................. 27
W
weight command.................................................... 118, 191 weight, QoS ...................................................................... 94 weighted random early detection. See WRED WRED ...................................................................... 94, 105 configuration examples ................................... 110, 174 configuring .............................................................. 110 different drop behavior for each queue ............ 111 different treatment of colored packets ............. 110
Z
zero-weight queues......................................................... 188
216
Index

Swconfig Policy Qos

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Swconfig Policy Qos

Uploaded by

Copyright:

Available Formats

JUNOSe Internet Software for E-series Routing Platforms

Policy and QoS Configuration Guide

Juniper Networks, Inc.

End User License Agreement

JUNOSe 6.1.x Policy and QoS Configuration Guide

JUNOSe 6.1.x Policy and QoS Configuration Guide

About This Guide

JUNOSe 6.1.x Policy and QoS Configuration Guide

About This Guide

Table 2: Text and Syntax Conventions Convention

Bold sans serif typeface

! Emphasizes words. ! Identifies variables. ! Identifies chapter, appendix, and

! There are two levels of access, user and

[ ] (brackets) [ ]* (brackets and asterisk)

Related Juniper Networks Documentation

Related Juniper Networks Documentation

JUNOSe 6.1.x Policy and QoS Configuration Guide

Table 3: Juniper Networks E-series Technical Publications Document

E-series Module Guide

JUNOSe System Basics Configuration Guide

Related Juniper Networks Documentation

About This Guide

JUNOSe 6.1.x Policy and QoS Configuration Guide

Configuring Policy Management

JUNOSe 6.1.x Policy and QoS Configuration Guide

Chapter 1: Configuring Policy Management

tiered12MB hardlimit9MB hardlimit3MB Rate limit profiles

AcmeCompanyUDP XYZCorpIGMP XYZCorpICMP Classifier control lists

Rule = Action + Classification

log user-packet-class Policy action

JUNOSe 6.1.x Policy and QoS Configuration Guide

Classifier Control Lists

! Color ! Traffic class ! Type-of-service (ToS) byte ! User packet class

Chapter 1: Configuring Policy Management

Table 4: CLACL Criteria (continued) Type of CLACL

! Color ! Traffic class ! User packet class

! Color ! Traffic class ! User packet class ! User priority

JUNOSe 6.1.x Policy and QoS Configuration Guide

A color-coded tag is added automatically to each packet based on categories:

CommittedGreen ConformedYellow ExceededRed

One-Rate Rate-Limit Profile

Chapter 1: Configuring Policy Management

JUNOSe 6.1.x Policy and QoS Configuration Guide

Two-Rate Rate-Limit Profile

Committed Rate Not 0

assigned the committed action

the exceeded action Peak rate not 0

assigned the committed action

rate assigned the conformed action

Chapter 1: Configuring Policy Management

JUNOSe 6.1.x Policy and QoS Configuration Guide

Creating a Rate-Limit Profile

Chapter 1: Configuring Policy Management

ip rate-limit-profile ipv6 rate-limit-profile mpls rate-limit-profile l2tp rate-limit-profile

ip rate-limit-profile ipv6 rate-limit-profile mpls rate-limit-profile l2tp rate-limit-profile

Creating a Rate-Limit Profile

JUNOSe 6.1.x Policy and QoS Configuration Guide

Packets are colored green. Example

Use the no version to restore the default value, transmit.

Use the no version to restore the default value, 8192 bytes.

Creating a Rate-Limit Profile

Chapter 1: Configuring Policy Management

For this example, displaying the rate-limit profile shows: