Swconfig Policy Qos

JUNOSe™ Internet Softwarefor E-series™ Routing Platforms

Policy and QoSConfiguration 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.xWriting: Bruce Gillham, Brian Wesley Simmons, Jane VarkonyiEditing: Ben Mann, Tony Mauro, Fran MuesIllustration: Brian Wesley Simmons, Nathaniel WoodwardCover Design: Edmonds Design

Revision History7 March 2005—Revision 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 AvenueSunnyvale, CA 94089 USAAttn: Contracts Administrator

Table of Contents

About This Guide ix

Objectives ....................................................................................................... ixE-series Routers ...............................................................................................xAudience..........................................................................................................xDocumentation Conventions............................................................................xRelated Juniper Networks Documentation....................................................... xiObtaining Documentation............................................................................. xiiiDocumentation Feedback ............................................................................. xiiiRequesting Support....................................................................................... xiii

Chapter 1 Configuring Policy Management 1

Overview .........................................................................................................2Policy Lists.................................................................................................2Secure Policies...........................................................................................3Classifier Control Lists ...............................................................................4Rate-Limit Profiles .....................................................................................5

One-Rate Rate-Limit Profile.................................................................6Two-Rate Rate-Limit Profile.................................................................8

References .....................................................................................................10Configuration Tasks .......................................................................................10Creating a Rate-Limit Profile ..........................................................................10

One-Rate .................................................................................................11Two-Rate .................................................................................................11

Creating Classifier Control Lists......................................................................18Creating Policy Lists .......................................................................................28

Creating a Policy List for IP......................................................................28Creating a Policy List for IPv6..................................................................29Creating a Policy List for Frame Relay .....................................................30Creating a Policy List for GRE Tunnels .....................................................32Creating a Policy List for L2TP .................................................................33Creating a Policy List for MPLS ................................................................33Creating a Policy List for VLANs...............................................................34

Creating Classifier Groups and Policy Rules....................................................36Policy Rule Support .................................................................................37Rules That Provide Routing Solutions ......................................................38Creating Multiple Forwarding Solutions with IP Policy Lists .....................38Classifier Group Command......................................................................39Policy Rule Commands............................................................................40

Applying Policy Lists to Interfaces and Profiles ..............................................45Enabling IP Options Filtering .........................................................................46Using RADIUS to Create and Apply Policies ...................................................47

Examples—Using the Ascend-Data-Filter Attribute............................49

Table of Contents ! v

vi !

JUNOSe 6.1.x Policy and QoS Configuration Guide

Policy Applications.........................................................................................54Policy Routing .........................................................................................54Security ...................................................................................................55Bandwidth Management..........................................................................56

One-Rate Rate-Limit Profile...............................................................57Two-Rate Rate-Limit Profile...............................................................57

Rate Limiting Individual or Aggregate Packet Flows ................................58Packet Tagging ........................................................................................59

Packet Flow Monitoring ....................................................................60Policy Management and MPLS Topology-Driven LSPs ....................................62

Statically Configured Mapping .................................................................62Signaled Mapping ....................................................................................63

Policy Resources ............................................................................................63FPGA Hardware Classifiers ......................................................................65CAM Hardware Classifiers .......................................................................66Software Classifiers .................................................................................67

Monitoring Policy Management .....................................................................68Setting a Statistics Baseline......................................................................68Policy Management show Commands .....................................................69

Chapter 2 Configuring Quality of Service 91

Overview .......................................................................................................92Terms......................................................................................................93Features...................................................................................................94

References .....................................................................................................96Configuration Tasks .......................................................................................96Traffic Classes ...............................................................................................97

Best-Effort Forwarding.............................................................................97Configuring a Traffic Class ......................................................................97

Traffic-Class Groups .......................................................................................99Configuring Traffic-Class Groups..............................................................99

Queue Profiles..............................................................................................100Static Oversubscription..........................................................................101Dynamic Oversubscription ....................................................................101Overriding Default Queue Allocation .....................................................101Color-Based Thresholding ......................................................................102Configuring Queue Profiles ...................................................................103

Drop Profiles ...............................................................................................105How RED Works ...................................................................................106Configuring RED....................................................................................106RED Configuration Examples ................................................................108

Configuring Average Queue Length ................................................108Configuring Thresholds ..................................................................108Configuring Color-Blind RED ..........................................................108

How WRED Works ................................................................................110Configuring WRED ................................................................................110WRED Configuration Examples ............................................................110

Configuring Different Treatment of Colored Packets ......................110Defining Different Drop Behavior for Each Traffic Class..................111RED and Dynamic Queue Thresholds ............................................112

Scheduler Profiles ........................................................................................114Hierarchical Assured Rate......................................................................115Configuring Scheduler Profiles...............................................................116

Table of Contents

Table of Contents

Shared Shaping ............................................................................................118Sharing Bandwidth with the SAR ...........................................................119How Shared Shaping Works ..................................................................119Simple Shared Shaping..........................................................................119

Simple Shared Shaping Example.....................................................120Simple Shared Shaping on the Best-Effort Scheduler Queue............120Simple Shared Shaping on the Best-Effort Scheduler Node..............121Shared Shaping and Low-CDV Mode ...............................................121

Compound Shared Shaping ...................................................................122Shared Shaping Constituents .................................................................122

Types of Shared Shapers .................................................................124Implicit Constituent Selection..........................................................124Implicit Bandwidth Allocation for Compound Shared Shaping ........127Explicit Constituent Selection..........................................................131Explicit Shared Shaping Example....................................................132Explicit Weighted Compound Shared Shaping Examples ................133

Simple Shared Shaping Configuration Examples ...................................135VC Simple Shared Shaping Example ...............................................136VP Simple Shared Shaping Example ...............................................137Shared Shaping and Individual Shaping ..........................................139

Compound Shared Shaping Configuration Examples.............................139Configuration Restrictions...............................................................141VC Compound Shared Shaping Example.........................................141VP Compound Shared Shaping Example.........................................143

Shared Shaping Caveats ........................................................................145Hardware Dependency ...................................................................145Logical Interface Traffic Carried in Other Queues............................146Traffic Starvation.............................................................................146Oversubscription.............................................................................146Burst Size ........................................................................................146

Statistics Profiles .........................................................................................147Rate Statistics ........................................................................................148Event Statistics ......................................................................................149Memory and Processor Use ...................................................................150Configuring Statistics Profiles ................................................................150

QoS Profiles .................................................................................................151Configuring QoS Profiles........................................................................152

Creating QoS Profiles ......................................................................153Adding Groups, Nodes, and Queues to QoS Profiles ........................153Attaching QoS Profiles ....................................................................154

Configuring QoS for ATM Interfaces.............................................................155Integrating the HRR Scheduler and SAR Scheduler ................................155

Backpressure...................................................................................156Configuring the Integrated Scheduler.....................................................157

Configuring the SAR Scheduler Mode of Operation .........................158Configuring the Operational QoS Shaping Mode .............................158

ATM QoS Configuration Examples.........................................................160Default Integrated Mode..................................................................160Low-Latency Mode ..........................................................................161Low-CDV Mode ...............................................................................163

Configuring QoS for L2TP Interfaces ............................................................167Configuration Procedure........................................................................168

Scheduler Hierarchies .....................................................................169

Table of Contents ! vii

viii !


QoS Profile Attachments ..............................................................................170Attaching a Profile to an Interface .........................................................170Attaching a Profile to a Port Type ..........................................................171Munged QoS Profile...............................................................................172

QoS Profile Configuration Examples ...........................................................174Diffserv Configuration with Multiple Traffic-Class Groups.............................178Strict-Priority Scheduling..............................................................................182Relative Strict-Priority Scheduling ................................................................184

True Strict Priority Versus Relative Strict Priority ..................................185True Strict Priority ..........................................................................185Relative Strict Priority .....................................................................186

Relative Strict Priority on ATM Modules ................................................186Oversubscribing ATM Ports ............................................................187Minimizing Latency on the SAR Scheduler .....................................187

HRR Scheduler Behavior .......................................................................187Zero-Weight Queues .......................................................................188Setting the Burst Size in a Shaping Rate .........................................188Special Shaping Rate for Nonstrict Queues .....................................188

Configuring Relative Strict-Priority Scheduling.......................................189Rate Shaping................................................................................................191Port Shaping ...............................................................................................192Clearing Statistics.........................................................................................193Monitoring QoS............................................................................................193

Index 211

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


x ! E

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 Description

Informational note Indicates important features or instructions.

Caution Indicates a situation that might result in loss of data or hardware damage.

Warning Alerts you to the risk of personal injury.

-series Routers

About This Guide

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.

Table 2: Text and Syntax Conventions

Convention Description Examples

Text Conventions

Bold typeface Represents commands and keywords in text.

! Issue the clock source command.

! Specify the keyword exp-msg.

Bold sans serif typeface Represents text that the user must type. host1(config)#traffic class low-loss1

Fixed-width font Represents information as displayed on your terminal’s screen.

host1#show ip ospf 2

Routing Process OSPF 2 with Router ID 5.5.0.250

Router is an Area Border Router (ABR)

Italic typeface ! Emphasizes words.

! Identifies variables.

! Identifies chapter, appendix, and book names.

! There are two levels of access, user and privileged.

! clusterId, ipAddress.

! Appendix A, System Specifications.

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 Represents keywords. terminal length

Italic typeface Represents variables. mask, accessListName

| (pipe symbol) 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.)

diagnostic | line

[ ] (brackets) Represent optional keywords or variables.

[ internal | external ]

[ ]* (brackets and asterisk) Represent optional keywords or variables that can be entered more than once.

[ level1 | level2 | l1 ]*

{ } (braces) Represent required keywords or variables.

{ permit | deny } { in | out }{ clusterId | ipAddress }

Related Juniper Networks Documentation ! xi


xii !

Table 3: Juniper Networks E-series Technical Publications

Document Description

E-series Hardware Guide 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.

E-series Module Guide 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.

JUNOSe System Basics Configuration Guide 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.

JUNOSe Physical Layer Configuration Guide Describes configuring physical layer interfaces.

JUNOSe Link Layer Configuration Guide Describes configuring link-layer interfaces.

JUNOSe Routing Protocols Configuration Guide, Vol. 1

Provides information about configuring routing policy and configuring IP, IP routing, and IP security.

JUNOSe Routing Protocols Configuration Guide, Vol. 2

Describes BGP routing, MPLS, BGP-MPLS VPNs, and encapsulation of layer 2 services.

JUNOSe Policy and QoS Configuration Guide Provides information about configuring policy management and quality of service (QoS).

JUNOSe Broadband Access Configuration Guide

Provides information about configuring remote access.

JUNOSe Command Reference Guide A to M; JUNOSe Command Reference Guide N to Z

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 command’s related mode, or a description of a command’s 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.

Related Juniper Networks Documentation

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 [email protected], 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

! 1


2 !

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 routing—Predefines 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 marking—Marks packets in a packet flow. See Creating Classifier Control Lists on page 18.

! Packet forwarding—Allows 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 filtering—Drops packets in a packet flow. See the filter command.

! Packet logging—Logs packets in a packet flow. See the log command.

! Rate limiting—Enforces 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 support—Allows you to create and attach a policy to an interface through RADIUS. See Using RADIUS to Create and Apply Policies on page 47.

! Packet mirroring—Uses secure policies to mirror packets and send them to an analyzer. See JUNOSe System Basics Configuration Guide, Chapter 8, Packet Mirroring.

Policy ListsThe 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

Secure PoliciesSecure policies are used by the JUNOSe software’s RADIUS-based packet mirroring feature. The policies are based on packet mirroring–related 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 software’s packet mirroring feature.

��

��

��

��

��

��

� ��

� !��"#$�

� !��"�$�

��

��%&'$(

��%��)$(

��%��*$(

�� !��

��

��&��'��*

� ��

� ��

��

��+�,��

��+�,��

��

��-��%

��,��,��

��.

��

��

��

/&*/0'

��,�� .��, ��

Overview ! 3


4 !

Classifier Control ListsCLACLs 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 Criteria

Frame Relay ! 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


Rate-Limit ProfilesRate 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 router’s 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 profiles—one-rate and two-rate—for 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.

IPv6 ! Color

! Destination IPv6 address

! Destination port


! Internet Control Message Protocol version 6 (ICMPv6)

! IPv6 traffic class

! Locally destined traffic

! Multicast Listener Discovery (MLD)

! Next header

! Source IPv6 address

! Source port


! 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

Table 4: CLACL Criteria (continued)

Type of CLACL Criteria

Overview ! 5


6 !

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

! Committed—Green

! Conformed—Yellow

! Exceeded—Red

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 ProfileThe one-rate rate-limit profile attributes are:

! Committed rate—Target rate for a packet flow

! Committed burst—Amount of bandwidth allocated to accommodate bursty traffic in excess of the rate

! Excess burst—Amount of bandwidth allocated to accommodate a packet in progress when the rate is in excess of the burst

! Committed action—Drop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow does not exceed the rate

! Conformed action—Drop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow exceeds the rate but not the excess burst

! Exceeded action—Drop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow exceeds the rate

! Mask value—Mask to be applied with mark values for the ToS byte; applicable only to IP and IPv6 rate-limit profiles

! EXP mask value—Mask 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 TCP’s 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 TCP’s 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 burst—0.2 to 2.0 seconds of the committed rate

! Excess burst—1.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 ! 7


8 !

Two-Rate Rate-Limit ProfileThe two-rate rate-limit profile attributes are:

! Committed rate—Target rate for a packet flow

! Committed burst—Amount of bandwidth allocated to accommodate bursty traffic in excess of the committed rate

! Peak rate—Amount of bandwidth allocated to accommodate excess traffic flow over the committed rate

! Peak burst—Amount of bandwidth allocated to accommodate bursty traffic in excess of the peak rate

! Committed action—Drop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow does not exceed the committed rate

! Conformed action—Drop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow exceeds the committed rate but remains below the peak rate

! Exceeded action—Drop, transmit, mark (IP and IPv6), or mark-exp (MPLS) when traffic flow exceeds the peak rate

! Mask value—Mask to be applied with mark values for the ToS byte; applicable only to IP and IPv6 rate-limit profiles

! EXP mask value—Mask 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 Committed Rate = 0 Committed Rate Not 0

Peak rate = 0 ! All traffic assigned the exceeded action

! Traffic <= committed rate assigned the committed action

! Traffic > committed rate assigned the exceeded action

Peak rate not 0 ! Traffic <= peak rate assigned the conformed action

! Traffic > peak rate assigned the exceeded action

! Traffic <= committed rate assigned the committed action

! Committed rate < Traffic < peak 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.

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.

Table 6: Two-Rate Rate-Limit Profile Algorithms

Step Result

If B > Tp (t) ! Packet is marked as red and treated as exceeded

If B < Tp (t)

and

B > Tc (t)

! Packet is marked as yellow and treated as conformed

! Tp is decremented by B

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

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

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 ! 9


10 !

References

For more information about policy management, see the following resources:

! RFC 2474—Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (December 1998)

! RFC 2475—An Architecture for Differentiated Services (December 1998)

! RFC 2697—A Single Rate Three Color Marker (September 1999)

! RFC 2698—A Two Rate Three Color Marker (September 1999)

! RFC 3198—Terminology 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.

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-ratehost1(config-rate-limit-profile)#committed-rate 8000000host1(config-rate-limit-profile)#committed-burst 1500000host1(config-rate-limit-profile)#excess-burst 3000000host1(config-rate-limit-profile)#committed-action transmithost1(config-rate-limit-profile)#conformed-action transmithost1(config-rate-limit-profile)#exceeded-action drophost1(config-rate-limit-profile)#mask-val 255

Two-RateTo 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-ratehost1(config-rate-limit-profile)#committed-rate 9000000host1(config-rate-limit-profile)#committed-burst 20000host1(config-rate-limit-profile)#committed-action transmithost1(config-rate-limit-profile)#conformed-action drophost1(config-rate-limit-profile)#exceeded-action drophost1(config-rate-limit-profile)#mask-val 255

Creating a Rate-Limit Profile ! 11


12 !

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-ratehost1(config-rate-limit-profile)#exceeded-action mark 7host1(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:

! drop—Drop the packet.

! transmit—Transmit the packet.

! mark—For 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-exp—For MPLS rate-limit profiles, set the EXP bits of MPLS packets to the specified value in the range 0–7, 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.



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 8000000committed-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.



14 !

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




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 precedence—0xE0 (three most significant bits)

! DS field—0xFC (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



16 !

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

peak-rate 8000000peak-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.

! 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:

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.

Table 7: One-Rate Rate-Limit-Profile Defaults

Policy Attribute Default Value

type one-rate

committed-rate 0

committed-burst 8192

excess-burst 0

committed-action transmit

conformed-action transmit

exceeded-action drop

mask (IP and IPv6 rate-limit profiles) 255

exp-mask (MPLS rate-limit profiles) 7



! 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.

! 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:

! During a software upgrade, certain values are set as follows:

! Committed burst size—Set to 8192 if it was less than that value before the upgrade

! Peak burst size—Set to 8192 if it was less than that value before the upgrade

! Peak rate—Set to 0 if it was nonzero but less than the committed rate before the upgrade

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

Table 8: Two-Rate Rate-Limit-Profile Defaults

Policy Attribute Default Value

type two-rate

committed-rate 0

committed-burst 8192

peak-rate 0

peak-burst 8192

committed-action transmit

conformed-action transmit

exceeded-action drop

mask (IP and IPv6 rate-limit profiles) 255

exp-mask (MPLS rate-limit profiles) 7



18 !

! Example

host1(config)#ip rate-limit-profile hardlimit9Mb two-rate

! Use the no version to remove a rate-limit profile.

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.

! Use the following keywords to configure the list:

! traffic-class—Matches packets with a class that you defined using the traffic-class command

! color

" green—Matches packets with color green, indicating a low drop preference

" yellow—Matches packets with color yellow, indicating a medium drop preference

" red—Matches packets with color red, indicating a high drop preference

! user-packet-class—Matches packets with the specified user packet class value

! de-bit—Matches Frame Relay packets with the specified DE bit value, either 0 or 1

NOTE: Commands that you issue in Rate Limit Profile Configuration mode do not take effect until you exit from that mode.

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.



! 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-class—Matches traffic with a class that you defined using the traffic-class command

! color




! tos, dsfield, and precedence specify the ToS byte in the IP header

" tos—Specifies the use of the whole 8 bits of the ToS byte; range is 0–255

" dsfield—Specifies the use of the upper 6 bits of the ToS byte; range is 0–63

" precedence—Specifies the use of the upper 3 bits of the ToS byte; range is 0–7


! 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.



Creating Classifier Control Lists ! 19


20 !

! 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:

! ip—IP protocol attributes, such as source and destination IP address and mask

! icmp—ICMP protocol attributes, such as source and destination IP address and mask, ICMP type and code

! igmp—IGMP protocol attributes, such as source and destination IP address and mask, and IGMP type

! tcp—TCP protocol attributes, such as source and destination IP address and mask, and source and destination TCP operator and port

! udp—UDP 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:

! portNumber—Single port number or the beginning of a range of port numbers

! portOperator—One of the following:

" eq—equal to

" lt—less than

" gt—greater than



" neq—not equal to

" range—range of ports

! toPortNumber—End 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 1�10:

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-class—Classifies on packets associated with a route class based on the packet’s source address; route-class range is 0–255; default is 0.

! destination-route-class—Classifies on incoming packets associated with a route class based on the packet’s destination address; route-class range is 0–255; default is 0.

! local true—Matches packets that are destined to a local interface.

! local false—Matches 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 10host1(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.



22 !

! 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).

! Use the following keywords to match the ToS byte in the IP header:

! tos—Specifies the use of the whole 8 bits of the ToS byte; range is 0–255; for example:

host1(config)#ip classifier-list tos128 ip any any tos 128

! dsfield—Specifies the use of the upper 6 bits of the ToS byte; range is 0–63; for example:

host1(config)#ip classifier-list low-drop-prec ip any any dsfield 10

! precedence—Specifies the use of the upper 3 bits of the ToS byte; range is 0–7; 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:

! portNumber—Single port number or the beginning of a range of port numbers (TCP and UDP only)

! portOperator—One of the following (TCP and UDP only):

" eq—Equal to

" lt—Less than

" gt—Greater than

" neq—Not equal to

" range—Range of ports

! toPortNumber—End of a range of port numbers (TCP and UDP only)

! icmpType—ICMP message type (ICMP only)

! icmpCode—ICMP message code (ICMP only)

! igmpType—IGMP 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"



! 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 1host1(config)#ip policy-list dosProtecthost1(config-policy-list)#filter classifier-group fragOffsetAttackhost1(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:

! green—Matches packets with color green, indicating a low drop preference

! yellow—Matches packets with color yellow, indicating a medium drop preference

! red—Matches packets with color red, indicating a high drop preference



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



24 !

ipv6 classifier-list! Use to create or modify an IPv6 classifier control list.


! traffic-class—Matches 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:

! icmpv6—ICMP type and code

! tcp—TCP protocol attributes, such as source and destination port, and source and destination TCP operator and port

! udp—UDP 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:

! portNumber—Single port number or the beginning of a range of port numbers

! toPortNumber—End of a range of port numbers

! portOperator—One of the following:

" eq—equal to

" lt—less than

" gt—greater than

" neq—not equal to

" range—range 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"




! For ICMPv6, use the icmp-type option to specify the icmpType and icmpCode parameters:

! icmpType—ICMP message type; in the range 0–255

! icmpCode—ICMP message code; in the range 0–255

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-class—Classifies on packets associated with a route class based on the packet’s source address; route-class range is 0–255; default is 0.

! destination-route-class—Classifies on incoming packets associated with a route class based on the packet’s destination address; route-class range is 0–255; default is 0.

! local true—Matches packets that are destined to a local interface.

! local false—Matches 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 10host1(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



26 !

! Use the following keywords to specify traffic class information in the IPv6 header:

! tcfield—Specifies the use of the whole 8 bits of the traffic-class byte; range is 0–255

! dsfield—Specifies the use of the upper 6 bits of the traffic-class byte; range is 0–63

! precedence—Specifies the use of the upper 3 bits of the traffic-class byte; range is 0–7

! 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.



! color





! 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.







! color





! exp-bits—Specifies the value of the EXP bit to match in the range 0–7

! exp-mask—Specifies the mask applied to the EXP bits in the range 1–7

! 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.



! color





! user-priority—Specifies the value of the user-priority bits, which you define in the policy list

! Example

host1(config)#vlan classifier-list lowLatencyLowDrop user-priority 7host1(config)#vlan classifier-list lowLatencyLowDrop user-priority 6host1(config)#vlan classifier-list lowLatency user-priority 5host1(config)#vlan classifier-list excellentEffort user-priority 4host1(config)#vlan classifier-list bestEffort user-priority 3host1(config)#vlan classifier-list bestEffort user-priority 2host1(config)#vlan classifier-list bestEffort user-priority 1host1(config)#vlan classifier-list bestEffort user-priority 0





28 !

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 IPThe 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 routeForABCCorphost1(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 75host1(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)#exithost1(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)#exithost1(config-policy-list)#exithost1(config)#



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

Creating a Policy List for IPv6The 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 routeForIPv6host1(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 75host1(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 redhost1(config-policy-list-classifier-group)#mark tcfield 7



NOTE: Commands that you issue in Policy Configuration mode do not take effect until you exit from that mode.

Creating Policy Lists ! 29


30 !


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 RelayThe 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 1host1(config-policy-list-classifier-group)#exithost1(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)#exithost1(config-policy-list)#exit

3. Apply the policy lists.

host1(config)#interface serial 5/0:1/1.1host1(config-subif)#frame-relay policy output frOutputPolicy statistics enabledhost1(config-subif)#ip address 10.0.0.1 255.255.255.0host1(config-subif)#exithost1(config)#interface serial 5/1:1/1.1host1(config-subif)#frame-relay policy input frInputPolicy statistics enabledhost1(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 upNumber of sub-interface down transitions is 0Time since last status change 03:04:59No 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 upNumber of sub-interface down transitions is 0Time since last status change 03:05:09No 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




32 !

Creating a Policy List for GRE TunnelsThe 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 150host1(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 redhost1(config-policy-list-classifier-group)#mark dsfield 20host1(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




Creating a Policy List for L2TPThe following example creates an L2TP policy list.

1. Create the policy list routeForl2tp.

host1(config)#l2tp policy-list routeForl2tphost1(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 redhost1(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 MPLSThe following example creates an MPLS policy list.

1. Create the policy list routeForMpls.

host1(config)#mpls policy-list routeForMplshost1(config-policy-list)#

2. Create the classification group.

host1(config-policy-list)#classifier-group * precedence 200host1(config-policy-list-classifier-group)#




34 !

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 2host1(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 VLANsThe 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 routeForVlanhost1(config-policy-list)#

2. Create the classification group.

host1(config-policy-list)#classifier-group lowLatencyLowDrophost1(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




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)#exithost1(config-policy-list)#classifier-group lowLatencyhost1(config-policy-list-classifier-group)#traffic-class lowLatency host1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group excellentEffort host1(config-policy-list-classifier-group)#traffic-class excellentEffort host1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group bestEfforthost1(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




36 !

frame-relay policy-listgre-tunnel policy-list

ip policy-listipv6 policy-listl2tp policy-list

mpls policy-listvlan 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.

! Example

host1(config)#ip policy-list routeForXYZCorphost1(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 groups—you 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.

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 21host1(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

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.

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.)



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 SupportTable 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 CommandFrame Relay GRE IP IPv6 L2TP MPLS VLAN

color Yes Yes Yes Yes Yes Yes Yes

filter Yes Yes Yes Yes Yes Yes Yes

forward Yes Yes Yes Yes Yes Yes Yes

log No No Yes No No No No

mark NA Yes Yes Yes NA NA NA

mark-de Yes NA NA NA NA NA NA

mark-exp NA NA NA NA NA Yes NA

mark-user-priority NA NA NA NA NA NA Yes

next-hop NA No Yes (input policies only)

No NA NA NA

next-interface NA No Yes (input and secondary input policies only)

No NA NA NA

rate-limit-profile No No Yes Yes Yes Yes No

traffic-class Yes Yes Yes Yes Yes Yes Yes

user-packet-class Yes Yes Yes Yes Yes Yes Yes

Creating Classifier Groups and Policy Rules ! 37


38 !

Rules That Provide Routing SolutionsThe 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 ListsBy 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.



! 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.

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

Classifier Group CommandUse 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

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.

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.”



40 !

! Use the no version to remove the classifier group and its rules from a policy list.

Policy Rule CommandsUse the commands described in this section to specify policy rules for classifier groups.

color! Use to color a packet matching the current CLACL as green, yellow, or red:

! green—Highest precedence

! yellow—Intermediate precedence

! red—Lowest 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.

NOTE: Empty classifier groups have no effect on the router’s 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.

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.



forwardforward interfaceforward 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.

! 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.

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.



42 !

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 0–255 and a mask value in the range 1–255

! tos-precedence keyword and a value in the range 0–7

! tos keyword and a value in the range 0–255

! dsfield keyword and a value in the range 0–63

! For IPv6, you must specify one of the following:

! A traffic-class byte in the range 0–255 and a mask in the range 1–255

! tc-precedence keyword and a value in the range 0–7

! tcfield keyword and a value in the range 0–255

! dsfield keyword and a value in the range 0–63

! 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 0–7 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.



mark-user-priority! Use to assign a value in the range 0–7 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.

! 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.

! 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.

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.

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.



44 !

! 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 0–15 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.



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.

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.1host1(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 bostonProfilehost1(config-profile)#l2tp policy output routeForABCCorp

frame-relay policygre-tunnel policy

ip policyipv6 policympls policyl2tp policyvlan 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.

! 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 router’s local IP or IPv6 stack

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.

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.

Applying Policy Lists to Interfaces and Profiles ! 45


46 !

! To protect a router from being overwhelmed by legitimate local traffic

! To apply policies on packets associated with the route class

! 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.

! 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.

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.

NOTE: The gre-tunnel policy command does not support the baseline keyword.

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 router’s 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

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"

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.

Using RADIUS to Create and Apply Policies ! 47


48 !

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 Format Comments

Type 1 byte 0 = generic1 = IP

Filter or forward 1 byte 0 = filter 1 = forward

Indirection 1 byte 0 = egress1 = ingress

Spare 1 byte –

Source IP address 4 bytes –

Destination IP address 4 bytes –

Source IP prefix 1 byte Count of leading zeros in wildcard mask

Destination IP prefix 1 byte Count of leading zeros in wildcard mask

Protocol 1 byte –

Established 1 byte Not implemented

Source port 2 bytes –

Destination port 2 bytes –

Source port qualifier 1 byte 0 = no compare1 = less than2 = equal to3 = greater than4 = not equal to

Destination port qualifier 1 byte 0 = no compare1 = less than2 = equal to3 = greater than4 = not equal to

Reserved 2 bytes –

Marking value 1 byte –

Marking mask 1 byte 0 = no packet marking

Traffic class 1–41 bytes ! 0 = no traffic class (required if there is no 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 1–41 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



A single RADIUS record can contain two policies—one 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.

Examples—Using the Ascend-Data-Filter AttributeThis 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"

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

NOTE: To create a rate-limit profile, traffic class, or marking rule, you must first configure the filter/forward field as forward.

Table 11: Ascend-Data-Filter Example 1 Values

Action or Classifier Hex Value Actual Value

Type 01 IP

Forward 00 Forward

Indirection 01 Ingress

Spare 00 None

Source IP address 0a020100 10.2.1.0

Destination IP address 00000000 Any

Source IP mask 18 24 (0.0.0.255)

Destination IP mask 00 0 (255.255.255.255)

Protocol 00 None

Established 00 None

Source port 0000 None

Destination port 0000 None

Source port qualifier 00 None

Destination port qualifier 00 None

Reserved 0000 None



50 !

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:


Classifier Control List Table ---------- ------- ---- -----IP clin_6.1 tcp 10.2.1.1 gt 9000 anyIP 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



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




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 = "01010100 0A020101 14000000 20080600 00000000 00000000"Ascend-Data-Filter = "01000100 0A020101 00000000 20000600 00000000 00000000"Ascend-Data-Filter = "01010100 0A020101 00000000 20000000 00000000 00000000"Ascend-Data-Filter = "01000100 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 = "01010000 14000000 0A020101 08200600 00000000 00000000"Ascend-Data-Filter = "01000000 00000000 0A020101 00200600 00000000 00000000"Ascend-Data-Filter = "01010000 00000000 0A020101 00200000 00000000 00000000"Ascend-Data-Filter = "01000000 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 ---------- ------- ---- -----IP clin_7_00.1 tcp host 10.2.1.1 20.0.0.0 0.255.255.255IP clin_7_01.1 tcp host 10.2.1.1 anyIP clin_7_02.1 ip host 10.2.1.1 anyIP clout_7_04.1 tcp 20.0.0.0 0.255.255.255 host 10.2.1.1IP clout_7_05.1 tcp any host 10.2.1.1IP clout_7_06.1 ip any host 10.2.1.1



52 !

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



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


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


Type 01 IP

Forward 01 Filter

Indirection 01 Ingress

Spare 00 None

Source IP address 0a020102 10.2.1.2



Use the show classifier-list and show policy-list commands to view information about the policy:


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



Destination IP address 00000000 Any

Source IP mask 20 32 (0.0.0.0)

Destination IP mask 00 0 (255.255.255.255)

Protocol 06 TCP

Established 00 None

Source port 0000 None

Destination port 0000 None

Source port qualifier 00 None

Destination port qualifier 00 None

Reserved 0000 None

Marking value 05 5

Marking mask aa 170

Traffic class 0773 6f6d6554 636c someTcl

Rate-limit profile 0773 6f6d6552 6c70 someRlp

Table 12: Ascend-Data-Filter Example 4 Values (continued)




54 !

Policy Applications

The following sections describe several practical applications of policy management.

Policy RoutingPolicy 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 interface—Causes an interface to forward all packets that satisfy the classification associated with that rule to the next interface specified

! Forward next hop—Causes 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 anyhost1(config)#ip classifier-list claclB ip host 2.2.2.2 anyhost1(config)#ip policy-list IpPolicy100host1(config-policy-list)#classifier-group claclA host1(config-policy-list-classifier-group)#forward interface atm 0/0.1host1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group claclB host1(config-policy-list-classifier-group)#forward interface atm 2/1.1 host1(config-policy-list-classifier-group)#exithost1(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.0host1(config-subif)#ip policy input IpPolicy100 statistics enabled

Policy Applications


SecurityYou can configure policy management to provide a level of network security by using policy rules that selectively forward or filter packet flows:

! Forward—Causes the packet flows that satisfy the classification associated with the rule to be routed by the virtual router

! Filter—Causes 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 attacker’s 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 anyhost1(config)#ip classifier-list claclB tcp host 2.2.2.2 any ip-frag-offset eq 1host1(config)#ip classifier-list claclC tcp any anyhost1(config)#ip policy-list IpPolicy100host1(config-policy-list)#classifier-group claclA host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group claclB host1(config-policy-list-classifier-group)#filterhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group claclC host1(config-policy-list-classifier-group)#forwardhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#filterhost1(config-policy-list-classifier-group)#exit

host1(config)#interface atm 0/0.0host1(config-subif)#ip policy input IpPolicy100 statistics enabled

Policy Applications ! 55


56 !

Bandwidth ManagementTo 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:

! Committed—Green


! Exceeded—Red

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

��

��%�%��% ��-�%��%1�� /&*/'2

Policy Applications


One-Rate Rate-Limit ProfileA 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 terminalhost1(config)#ip rate-limit-profile oneMegRlp one-ratehost1(config-rate-limit-profile)#committed-rate 1000000host1(config-rate-limit-profile)#exit

host1(config)#ip classifier-list claclA ip host 1.1.1.1 anyhost1(config)#ip policy-list testPolicyhost1(config-policy-list)#classifier-group claclAhost1(config-policy-list-classifier-group)#rate-limit-profile oneMegRlphost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#exit

host1(config)#interface atm 0/0.0host1(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-ratehost1(config-rate-limit-profile)#committed-rate 8000000host1(config-rate-limit-profile)#committed-burst 1000000host1(config-rate-limit-profile)#excess-burst 2500000host1(config-rate-limit-profile)#committed-action transmithost1(config-rate-limit-profile)#exceeded-action drop

Two-Rate Rate-Limit ProfileYou 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.



58 !

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 1MbRLPhost1(config-rate-limit-profile)#committed-rate 1000000host1(config-rate-limit-profile)#peak-rate 2000000host1(config-rate-limit-profile)#committed-action transmithost1(config-rate-limit-profile)#conformed-action transmithost1(config-rate-limit-profile)#exceeded-action drophost1(config-rate-limit-profile)#exit

host1(config)#ip classifier-list claclA ip host 1.1.1.1 anyhost1(config)#ip policy-list testPolicyhost1(config-policy-list)#classifier-group claclAhost1(config-policy-list-classifier-group)#rate-limit-profile 1MbRLP host1(config-policy-list-classifier-grouip)#exithost1(config-policy-list)#exit

host1(config)#interface atm 0/0.0host1(config-subif)#ip policy input testPolicy statistics enabled

Rate Limiting Individual or Aggregate Packet FlowsYou 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: IndividualPacket 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 anyhost1(config)#classifier-list clFlow2 ip host 10.1.1.2 anyhost1(config)#classifier-list clFlow3 ip host 10.1.1.3 anyhost1(config)#policy-list plRateLimithost1(config-policy-list)#classifier-group clFlow1host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meghost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group clFlow2host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meghost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group clFlow3host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meghost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#exit host1(config)#interface atm 3/1.1host1(config-subif)#ip policy input plRateLimit statistics enabled

Policy Applications


host1(config-subif)#exithost1(config)#

Example 2: MultipleTraffic 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 anyhost1(config)#classifier-list clFlowAll ip host 10.1.1.2 anyhost1(config)#classifier-list clFlowAll ip host 10.1.1.3 anyhost1(config)#policy-list plRateLimithost1(config-policy-list)#classifier-group clFlowAllhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#exit host1(config)#interface atm 3/1.1host1(config-subif)#ip policy input plRateLimit statistics enabledhost1(config-subif)#exithost1(config)#

Packet TaggingYou 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 ISP’s 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 16host1(config)#ip classifier-list data ip any any dsfield 32host1(config)#ip policy-list colorVideoGreenhost1(config-policy-list)#classifier-group videohost1(config-policy-list-classifier-group)#color green host1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group datahost1(config-policy-list-classifier-group)#color yellow host1(config-policy-list-classifier-group)#exithost1(config-policy-list)#exit



60 !

host1(config)#interface atm 12/1.1host1(config-if)#ip policy input colorVideoGreen statistics enabled

Packet Flow MonitoringThe 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: LoggingIngress 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 testPolicyhost1(config-policy-list)#classifier-group logAhost1(config-policy-list-classifier-group)#loghost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#exithost1(config)#interface atm 0/0.0host1(config-subif)#ip policy input testPolicy statistics enabledhost1(config-subif)#exithost1(config)#log destination console severity infohost1(config)#log severity info policyMgrPacketLoghost1(config)#log verbosity low policyMgrPacketLoghost1(config)#log here

Example 2: Logging aPing 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 icmpEchoReqhost1:vr2(config-policy-list-classifier-group)#log host1:vr2(config-policy-list-classifier-group)#exit host1:vr2(config-policy-list)#exit

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 forwardedINFO 12/16/2003 12:59:47 policyMgrPacketLog ():icmpEchoReq GigabitEthernet0/0 number of hits = 21551INFO 12/16/2003 12:59:50 policyMgrPacketLog ():icmpEchoReq icmp GigabitEthernet0/0 10.10.10.2 10.10.10.1 forwardedINFO 12/16/2003 12:59:50 policyMgrPacketLog ():icmpEchoReq GigabitEthernet0/0 number of hits = 21851INFO 12/16/2003 12:59:53 policyMgrPacketLog ():icmpEchoReq icmp GigabitEthernet0/0 10.10.10.2 10.10.10.1 forwardedINFO 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/0GigabitEthernet0/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



62 !

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.

Statically Configured MappingYou 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.

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.

Policy Management and MPLS Topology-Driven LSPs


Signaled MappingFor 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 classifiers—all 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


64 !

Table 13: Classifier Support (OC48/STM16 and GE-2 Line Modules)

Interface Type Hardware Classifier Software Classifier

All interface types (except IP and IPv6)

! Color

! Traffic class

! User packet class

Frame Relay Not supported ! DE bit

GRE tunnels Not supported ! ToS

IP ! Color


! Destination port


! ICMP type and code

! IGMP type

! IP flags

! IP fragmentation

! Local

! Protocol

! Source address

! Source port


! TCP flags

! ToS

! Traffic class

! User packet class

!

Not supported

IPv6 Not supported Not supported

MPLS Not supported ! EXP

VLAN Not supported ! User priority

Policy Resources


FPGA Hardware ClassifiersFPGA 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 policies—you 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.

Table 14: Classifier Support (All Line Modules Except OC48/STM16 and GE-2)

Interface Type Hardware Classifier Software Classifier

All interface types ! Color

! Traffic class

! User packet class

Frame Relay Not supported ! DE bit

GRE tunnels Not supported ! ToS

IP ! Destination address

! Destination port

! ICMP type and code

! IGMP type

! Protocol

! Source address

! Source port


! IP flags

! IP fragmentation

! Local


! TCP flags

! ToS

IPv6 ! Destination address

! Destination port

! Protocol

! Source address

! Source port


! Local


! TC field

! TCP flags

MPLS Not supported ! EXP

VLAN Not supported ! User priority



66 !

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 ClassifiersCAM 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 1host1(config)#ip classifier-list clacl1 ip host 192.168.1.1 host 192.168.2.2 tos 2host1(config)#ip classifier-list clacl2 tcp any any tcp-flags "SYN"host1(config)#ip policy-list policy1host1(config-policy-list)#classifier-group clacl1host1(config-policy-list-classifier-group)#forwardhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group clacl2host1(config-policy-list-classifier-group)#forwardhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group *host1(config-policy-list-classifier-group)#filterhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#exithost1(config)#

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 it—you can usually achieve the desired behavior without this field.

host1(config)#ip classifier-list clacl4 ip not host 1.1.1.1 any

Software ClassifiersThe 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.

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 anyhost1(config)#classifier-list clacl200 color yellow user-packet-class 6 ip host 10.1.1.1 host 10.1.1.2host1(config)#classifier-list clacl300 color green user-packet-class 5 ip any anyhost1(config)#classifier-list clacl400 color red ip host 10.1.1.10 any host1(config)#policy-list polWestford5host1(config-policy-list)#classifier-group clacl100host1(config-policy-list-classifier-group)#forwardhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group clacl200host1(config-policy-list-classifier-group)#forwardhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group clacl300host1(config-policy-list-classifier-group)#forwardhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group clacl400host1(config-policy-list-classifier-group)#forwardhost1(config-policy-list-classifier-group)#exithost1(config-policy-list)#classifier-group *host1(config-policy-list-classifier-group)#filter

NOTE: Policy consumption is per policy definition per line card.



68 !

host1(config-policy-list-classifier-group)#exithost1(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.

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.1host1(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 deltaatm12/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

Table 15: Resource Consumption

Number of Resources Consumed Classifier Category

1 hardware ! Protocol


! Source address

1 software Color

1 software User-packet-class



Operational debounce-time = disabled Access routing = disabled Multipath mode = hashed

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 CommandsUse 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.

Monitoring Policy Management ! 69


70 !

frame-relay policyip policy

ipv6 policympls policyl2tp policyvlan 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 descriptions—Fields displayed vary depending on the type and configuration of the CLACL:

! Reference count—Number of times the CLACL is referenced by policies

! Entry count—Number of entries in the classifier list

! Classifier-List—Name of the classifier list

! Entry—Entry number of the classifier list rule

! Color—Packet color to match

! Protocol—Protocol type

! Not Protocol—If true, matches any protocol except the preceding protocol; if false, matches the preceding protocol

! Source IP Address—Number of the network or host from which the packet is sent

! Source IP WildCardMask—Mask that indicates addresses to be matched when specific bits are set

! Not Source Ip Address—If 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



! Destination IP Address—Number of the network or host from which the packet is sent

! Destination IP WildCardMask—Mask that indicates addresses to be matched when specific bits are set

! Not Destination Ip Address—If 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 Class—Name of the traffic class to match

! User Packet Class—User packet value to match

! DS Field—DS field value to match

! TOS Byte—ToS value to match

! Precedence—Precedence value to match

! User Priority bits—User priority bits value to match

! Traffic Class Field—Traffic class field value to match

! EXP Bits—MPLS EXP bit value to match

! EXP Mask—Mask applied to EXP bits before matching

! DE Bit—Frame Relay DE bit value to match

! Destination Route Class—Route class used to classify packets based on the packet’s destination address

! Source Route Class—Route class used to classify packets based on the packet’s source address

! Local—If true, matches packets destined to a local interface; if false, matches packets that are traversing the router

! Example 1


Classifier Control List Table ---------- ------- ---- -----GRE Tunnel greClass.1VLAN lowLatencyLowDrop.1VLAN excellentEffort.1VLAN bestEffort.1VLAN lowLatency.1IP wstFd.1 source-route-class 44 destination-route-class 55 3 any anyIP XYZCorpPermit.1 local true color green ip any anyIP routeForXYZCorp.1 color red tcp any anyIP XYZCorpIcmpEchoRequests.1 ip any anyIP XYZCorpPrecedence.1 tcp any any tos 5IP XYZCorpPrecedence67.1 udp any anyIPv6 IPv6Precedence.1 color yellowIPv6 IPv6Precedence67.1L2TP l2tpclass.1 color green user-packet-class 8MPLS mplsClass.1 user-packet-class 10 exp-bits 3 exp-mask 7 Frame relay frMatchDeSet.7 user-packet-class 8 de-bit 0



72 !

! 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



Classifier-List mplsClass Entry 1 User Packet Class: 10 EXP Bits: 3 EXP Mask: 7Frame 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 subinterface’s Frame Relay policy lists.

! Field descriptions related to policy lists

! Frame Relay policy—Type and name of the VLAN policy

! mark-de—DE bit value

! color—Color applied to packet flow for queuing: green, yellow, or red

! classifier-group—Name of the classifier control list used by the policy

! filter—Filter policy action

! forward—Forward policy action

! traffic class—Traffic class in the policy list

! user-packet-class—User packet class in the policy list

! Example

host1#show frame-relay subinterface Frame relay sub-interface SERIAL5/0:1/1.1, status is upNumber of sub-interface down transitions is 0Time since last status change 03:04:59No 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 1Frame relay sub-interface SERIAL5/1:1/1.1, status is upNumber of sub-interface down transitions is 0Time since last status change 03:05:09No 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



74 !

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 input—Policy for outbound traffic

! GRE tunnel policy output—Policy for inbound traffic

! traffic-class—Name of traffic class

! classifier-group—Name of classifier group

! entry—Identifier for the entry in the classifier group

! packets—Number of packets

! bytes—Number of bytes

! mark—ToS byte setting for the classifier control list

! mask—Mask value corresponding to the ToS

! Example

host1#show gre tunnel detail tunnelGre50GRE tunnel tunnelGre50 is DownTunnel 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 UpStatistics packets octets discards errors Data rx 0 0 0 0 Data tx 0 0 0 0 GRE tunnel policy input routeGre25 classifier-group gre6 entry 1 0 packets, 0 bytes traffic-class best-effort mark 4 mask 255GRE tunnel policy output routeGre35 classifier-group gre14 entry 1 0 packets, 0 bytes traffic-class best-effort mark 4 mask 255



show interfaces! Use to display information about a subinterface and its VLAN policy lists.

! You can specify the following keywords:

! delta—Specifies that baselined statistics are to be shown

! brief—Displays the operational status of all configured interfaces

! Field descriptions related to policies

! Subinterface number—Location of the subinterface that carries the VLAN traffic

! Administrative status—Operational state that you configured for this interface: up or down

! VLAN ID—Domain number of the VLAN

! In Bytes—Number of bytes received on the VLAN subinterface

! In Packets—Sum of all unicast, broadcast, and multicast packets received on the VLAN or S-VLAN subinterface

! In Errors—Value is always 0 (zero)

! In Discards—Value is always 0 (zero)

! Out Bytes—Number of bytes sent on the VLAN or stacked VLAN (S-VLAN) subinterface

! Out Packets—Number of packets sent on the VLAN or S-VLAN subinterface

! Out Errors—Value is always 0 (zero)

! Out Discards—Value is always 0 (zero)

! VLAN policy—Type and name of the VLAN policy

! Example

host1#show interfaces fastEthernet 1/0.1FastEthernet1/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



76 !

show ip interface! Use to display information about an IP interface (including policy list statistics).

! Field descriptions related to policy management only

! Network Protocols—Protocols configured on the interface

! Internet address—IP address of the interface

! Broadcast address—Broadcast address used by the interface

! Operational MTU—Operational maximum transmission unit (MTU) for packets sent on this interface

! Administrative MTU—Administrative maximum transmission unit for packets sent on this interface

! Operational speed—Speed known to the IP layer in bits per second; equal to the administrative speed if configured, otherwise inherited from the lower layer

! Administrative speed—Configured speed known to the IP layer in bits per second

! Discontinuity Time—Time since the counters on the interface became invalid—for example, when the line module was reset

! Router Advertisement—When enabled by the ip irdp command, the router advertises its presence via the ICMP Router Discovery Protocol (IRDP)

! Administrative debounce-time—Administrative time delay that an interface must remain in a new state before the routing protocols react to the state change

! Operational debounce-time—Time delay that an interface must remain in a new state before the routing protocols react to the state change

! Access routing—When enabled, an access route is installed to the host on the other end of the interface

! In Received Packets—Packets received on the interface; indicates whether packets are unicast or multicast

! In Received Bytes—Bytes received on the interface; indicates whether bytes are unicast or multicast

! In Policed Packets—Packets policed on the interface; discarded because they exceeded a traffic contract to their destination

! In Policed Bytes—Bytes policed on the interface; discarded because they exceeded a traffic contract to their destination

! In Error Packets—Packets determined to be in error at the interface

! In Invalid Source Address Packets—Packets determined to have originated from an invalid source address

! Out Forwarded Packets—Packets forwarded from the interface; indicates whether packets are unicast or multicast

! Out Forwarded Bytes—Bytes forwarded from the interface; indicates whether bytes are unicast or multicast

! Out Scheduler Drops Packets—Packets dropped by the out scheduler; indicates whether packets are committed, conformed, or exceeded



! Out Scheduler Drops Bytes—Bytes dropped by the out scheduler; indicates whether bytes are committed, conformed, or exceeded

! Policy—Indicates which policy is attached and whether it is on the input or output of the interface

! classifier-group—Name of a CLACL attached to the interface and number of entry

! filter—Number of packets and bytes dropped because of the CLACL

! color—Explicit color applied to packet flow for queuing; green, yellow, or red:

" Packets logged—Number of packets colored

" Bytes logged—Number of bytes colored

! next hop—Address of the next-hop destination:

" Packets transmitted—Number of packets sent to the next-hop address

" Bytes transmitted—Number of bytes sent to the next-hop address

! forward—Number of packets and bytes forwarded because of the CLACL

! rate-limit-profile—Name of the rate-limit profile

" committed—Number of packets and bytes within the committed rate limit

" conformed—Number of packets and bytes exceeding the committed rate limit but within the peak rate

" exceeded—Number of packets and bytes exceeding the peak rate

" action—Action performed on the packets matched by the rules in the rate-limit profile

! Example 1

host1#show ip interface serial 2/1:28/24.1serial2/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 = 0Operational speed = 155520000 Administrative speed = 0

Discontinuity Time = 14695 Router advertisement = disabledAdministrative 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



78 !

IP Policy input pl28241 Classifier-group clacl28241X01 entry 1 0 packets, 0 bytes filter Classifier-group clacl28241X02 entry 1 1 packets, 202 bytes filter Classifier-group clacl28241X03 entry 1 1 packets, 203 bytes filter Classifier-group clacl28241X04 entry 1 1 packets, 204 bytes filter Classifier-group clacl28241X05 entry 1 1 packets, 205 bytes filter

! Example 2

host1#show ip interface serial 2/1:2/1.101serial2/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



! 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

! Description—Optional description for the interface or address specified

! Network Protocols—Network protocols configured on this interface

! Link local address—Local IPv6 address of this interface

! Internet address—External address of this interface

! Operational MTU—Value of the MTU

! Administrative MTU—Value of the MTU if it has been administratively overridden using the configuration

! Operational speed—Speed of the interface

! Administrative speed—Value of the speed if it has been administratively overridden using the configuration

! Creation type—Method by which the interface was created (static or dynamic)

! ND reachable time—Amount of time (in milliseconds) that the neighbor is expected to remain reachable



80 !

! ND duplicate address detection attempts—Number of times that the router attempts to determine a duplicate address

! ND neighbor solicitation retransmission interval—Interval in which the router retransmits neighbor solicitations

! ND proxy—Indicates whether the router will reply to solicitations on behalf of a known neighbor

! ND RA source link layer—Indicates whether the RA includes the link layer

! ND RA interval—Interval (in seconds) of the neighbor discovery router advertisement

! ND RA lifetime—Lifetime (in seconds) of the neighbor discovery router advertisement

! ND RA managed flag—State of the neighbor discovery router advertisement managed flag

! ND RA other config flag—State of the neighbor discovery router advertisement other config flag

! ND RA advertising prefixes—Configured advertisement prefixes for neighbor discovery router advertisement

! In Received Packets, Bytes—Total number of packets and bytes received on this interface

" Unicast Packets, Bytes—Unicast packets and bytes received on the IPv6 interface; link-local received multicast packets (non-multicast-routed frames) are counted as unicast packets

" Multicast Packets, Bytes—Multicast packets and bytes received on the IPv6 interface, which are then multicast-routed and counted as multicast packets

! In Total Dropped Packets, Bytes—Total number of inbound packets and bytes dropped on this interface

" In Policed Packets—Packets that were received and dropped because of rate limits

" In Invalid Source Address Packets—Packets received with invalid source address (for example, spoofed packets)

" In Error Packets—Number of packets received with errors

" In Discarded Packets—Packets received that were discarded for reasons other than rate limits, errors, and invalid source address

! Out Forwarded Packets, Bytes—Total number of packets and bytes that were sent from this interface

" Unicast Packets, Bytes—Unicast packets and bytes that were sent from this interface

" Multicast Routed Packets, Bytes—Multicast packets and bytes that were sent from this interface

! Out Total Dropped Packets—Total number of outbound packets and bytes dropped by this interface

" Out Scheduler Dropped Packets, Bytes—Number of outbound packets and bytes dropped by the scheduler



" Out Policed Packets, Bytes—Number of outbound packets and bytes dropped because of rate limits

" Out Discarded Packets—Number of outbound packets that were discarded for reasons other than those dropped by the scheduler and those dropped because of rate limits

! IPv6 policy—Type (input, output, local-input) and name of the policy

" rate-limit-profile—Name of the profile

" classifier-group entry—Entry index

" Committed—Number of packets and bytes that conform to the committed access rate

" Conformed—Number of packets and bytes that exceed the committed access rate but conform to the peak access rate

" Exceeded—Number of packets and bytes that exceed the peak access rate

! queue, traffic class, bound to ipv6—Queue and traffic class bound to the specified IPv6 interface

" Queue length—Number of bytes in the queue

" Dropped committed packets, bytes—Total number of committed packets and bytes dropped by this interface

" Dropped conformed packets, bytes—Total number of conformed packets and bytes dropped by this interface

" Dropped exceeded packets, bytes—Total number of exceeded packets and bytes dropped by this interface

! Example

host1#show ipv6 interface FastEthernet 9/0.6FastEthernet9/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



82 !

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.


! Interface—Specifier and status of each interface

! base-LSP/remote-addr—Identifies either the tunnel that is selected to forward the traffic or the address of the router at the other end

! group-id—Group ID number for the interface

! vc-id—VC ID number for the interface

! mtu—Maximum transmission unit for the interface



! state/in/out-label—Status of the Layer 2-over-MPLS connection or the incoming/outgoing VC label

! Mpls Statistics

" pkts—Number of packets received or sent

" hcPkts—Number of high-capacity (64-bit) packets received or sent

" octets—Number of octets received or sent

" hcOctets—Number of high-capacity (64-bit) octets received or sent

" errors—Number of packets that are dropped for some reason at receipt or before being sent

" discardPkts—Number of packets that are discarded due to lack of buffer space at receipt or before being sent

! queue, traffic class, bound to—Queue and traffic class bound to the specified interface

" Queue length—Number of bytes in queue

" Forwarded packets, bytes—Total number of packets and bytes forwarded by this interface

" Dropped committed packets, bytes—Total number of committed packets and bytes dropped by this interface

" Dropped conformed packets, bytes—Total number of conformed packets and bytes dropped by this interface

" Dropped exceeded packets, bytes—Total number of exceeded packets and bytes dropped by this interface

! MPLS policy—Type (input, output) and name of policy

! classifier-group—Name of a CLACL attached to the interface and number of entry

" rate-limit-profile—Name of profile

" Committed—Number of packets and bytes conforming to the committed access rate

" Conformed—Number of packets and bytes that exceed the committed access rate but conform to the peak access rate

" Exceeded—Number 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



84 !

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 descriptions—Fields displayed vary depending on the type of policy and the rules assigned to the policy:

! Policy—Name of the policy list.

! Administrative state—For 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 count—Number 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 list—Name of the classifier control list containing policy rules and the precedence assigned to the classifier control list.

! Statistics—Enabled, disabled.

! Rule types are:

" filter—Filter policy action

" forward—Forward policy action

" next-interface—Next-interface policy action

" next-hop—Next-hop policy action

" rate-limit-profile—Rate-limit-profile policy action

" color—Color of a packet; green, yellow, or red

" traffic-class—Traffic class in a policy list

" log—Log policy action



" mark tos—ToS byte in the IP header to a specified value

" mark DS field—DS field value in the IP header to a specified value

" mark TC precedence—Traffic class value in the IPv6 header to a specified value

" mark EXP—Value assigned to EXP bits action

" mark user priority—Value assigned to 802.1p VLAN user priority bit

" mark DE—DE bit action

! Rule status—Indicates 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



86 !

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.


! Rate-Limit-Profile—Name of the rate-limit profile

! Profile Type—One-rate or two-rate profile

! Reference Count—Number of policy lists that reference this rate-limit profile

! Committed rate—Target rate for the traffic, in bits per second

! Committed burst—Amount of bandwidth allocated to accommodate bursty traffic, in bytes

! Excess burst—Amount of bandwidth allocated to accommodate a packet in progress when the rate is in excess of the burst

! Peak rate—Amount of bandwidth allocated to accommodate traffic flow in excess of the committed rate, in bits per second

! Peak burst—Amount of bandwidth allocated to accommodate bursty traffic in excess of the peak rate, in bytes

! Mask—Value of mask applied to ToS byte in IP packet header

! Committed rate action—Policy action (drop, transmit, or mark) taken when traffic flow does not exceed the committed rate

! Conformed rate action—Policy action (drop, transmit, or mark) taken when traffic flow exceeds the committed rate but remains below the peak rate

! Exceeded rate action—Policy action (drop, transmit, or mark) taken when traffic flow exceeds the peak rate



! 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: dropIP 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: two-rate Reference count: 0 Committed rate: 0 Committed burst: 8192 Peak rate: 0 Peak burst: 8192 Committed rate action: transmit Conformed rate action: transmit Exceeded rate action: 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.


! Policy—Type (IP or L2TP) and name of the policy list

! Administrative state—Set to enable when the policy list is created.

! Reference count—Number of attachments to interfaces or profiles

! Classifier control list—Name of the classifier control list, which is always *; (contains mirror policy rule and has precedence value to determine order within policy)

! precedence—Precedence assigned to the classifier control list

! mirror—Mirror action

! analyzer-ip-address—IP address of analyzer device



88 !

! analyzer-virtual-router—Virtual router where the analyzer interface is configured

! analyzer-udp-port—UDP port used to communicate with analyzer device

! mirror-id—Unique identifier of the mirrored session

! session-id—Unique identifier of the user session

! 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

! statistics—Not 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


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 secure-input policy, statistics disabled TUNNEL l2tp:1/msn.pwh.com/1 secure-output policy, statistics disabled


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.



show vlan subinterface! Use to display information about a subinterface’s VLAN policy lists.


! Subinterface number—Location of the subinterface that carries the VLAN traffic

! VLAN ID—Domain number of the VLAN

! VLAN policy—Type and name of the VLAN policy

! filter—Number of packets and bytes that have been policed by the policy

! Example

host1#show vlan subinterface fastEthernet 1/0.1VLAN ID is 100VLAN policy input vlanPol1 classifier-group claclVlanBos entry 1 5 packets, 730 bytes filter



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


92 !

! 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 subscriber’s 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.

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

TermsTable 16 defines terms used in this discussion of QoS.

3,��

�-�� 4��%�� 4��%��

"�� 3��

/&*/'5

Table 16: QoS Terminology Used in This Chapter

Term Description

Assured rate Bandwidth guaranteed until oversubscribed.

Best effort 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.

Best-effort queue For a logical interface, the queue associated with the best-effort traffic class for that logical interface,

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 Cell delay variation. Measures the difference between a cell’s expected and actual transfer delay. Determines the amount of jitter.

CDVT Cell delay variation tolerance. Specifies the acceptable tolerance of CDV (jitter).

Effective weight 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.

Group node 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.

HAR Hierarchical assured rate. Dynamically adjusts bandwidth for scheduler nodes.

HRR Hierarchical round-robin. Allocates bandwidth to queues in proportion to their weights.

Latency Delay in the transmission of a packet through a network from beginning to end.

Proprietary QoS Management Information Base (MIB)

Supported on the E-series router.

Queue First-in-first-out (FIFO) set of buffers that control packets on the data path.

Overview ! 93


94 !

FeaturesTable 17 describes the major QoS features that the E-series router provides.

QoS port-type profile Supplies the QoS information for forwarding interfaces stacked above ports of the associated interface type.

QoS profile attachment Applies the rules in the QoS profile to a specific interface.

Rate shaping Allows you to throttle a queue to a specified rate.

RED Random early detection congestion avoidance technique.

Scheduler hierarchy 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.

Scheduler node 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.

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 Specifies the relative weight for queues in the traffic class.

WRED Weighted random early detection congestion avoidance technique.

Table 16: QoS Terminology Used in This Chapter (continued)

Term Description

Table 17: QoS Features

Feature Description

Best effort 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.

Differentiated services ! Assured forwarding—See RFC 2597.

! Expedited forwarding—See RFC 2598.

Drop profile Template that specifies active queue management in the form of WRED behavior of an egress queue.

Port shaping Shapes the aggregate traffic through a port or channel to a rate that is less than the line or port rate.

QoS port-type profile QoS profile that is automatically attached to ports of the corresponding type if you do not explicitly attach a QoS profile.

QoS profile Collection of QoS commands that specify queue profiles, drop profiles, scheduler profiles, and statistics profiles in combination with interface types.

Queue profile Template that specifies the buffering and tail-dropping behavior of an egress queue.

Overview


Rate shaping 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.

Scheduler profile Configures the bandwidth at which queues drain as a function of relative weight, assured rate, and shaping rate.

Shared rate shaping Mechanism that enables dynamic sharing of logical interface bandwidth for traffic that is queued through separate scheduler hierarchies.

Statistics profile Template that specifies rate statistics and event-gathering characteristics.

Strict-priority scheduling 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.

Traffic class 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.

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.

Table 17: QoS Features (continued)

Feature Description

Overview ! 95


96 !

References

For more information about QoS, see the following resources:

! RFC 2474—Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (December 1998)

! RFC 2475—An Architecture for Differentiated Services (December 1998)

! RFC 2597—Assured Forwarding PHB Group (June 1999)

! RFC 2598—An Expedited Forwarding PHB (June 1999)

! RFC 2698—A Two Rate Three Color Marker (September 1999)

! RFC 2990—Next Steps for the IP QoS Architecture (November 2000)

! RFC 2998—A Framework for Integrated Services Operation over Diffserv Networks (November 2000)

! RFC 3246—An Expedited Forwarding PHB (Per-Hop Behavior) (March 2002)

! RFC 3260—New 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.

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 2597—Assured 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 class–specific 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-loss1host1(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


98 !

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 1–63. Zero is not a valid weight.

! 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-loss1host1(config-traffic-class)#

! Use the no version to delete a specified traffic class.

NOTE: The fabric-weight command works only with ERX-1440 routers.

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 traffic—by service class, for example—when 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 group—either 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 configured—you 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 GroupsTo 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


100 !

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 extendedhost1(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 queue’s 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.

Queue Profiles


Static OversubscriptionStatic 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 OversubscriptionDynamic 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 AllocationTo 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 multicasthost1(config-queue)#committed-length 0 20000host1(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 videohost1(config-queue)#buffer-weight 24host1(config-queue)#exithost1(config)#

Queue Profiles ! 101


102 !

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 1–128 bytes creates a single 128-byte buffer for the queue.

! Specifying a maximum queue length of 129–256 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 64–128 bytes in length or a single packet of 129–256 bytes can be queued.

Color-Based ThresholdingPackets within the router are tagged with a drop precedence:

! Committed—Green


! Exceeded—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.

NOTE: All color-based thresholds vary in proportion to the dynamic queue length.

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.

! 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 videohost1(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

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.

Queue Profiles ! 103


104 !

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 1–63; 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-lengthconformed-lengthexceeded-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 0–1 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-fractionexceeded-fraction

! Use to set the conformed and exceeded drop thresholds as a percentage of the committed threshold.

! exceeded fraction: range is 0–100; default is 25

! conformed fraction: range is 0–100; default is 50

! Example

host1(config-queue)#exceeded-fraction 30

! Use the no version to return the fraction to its default setting.

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 videohost1(config-queue)#exithost1(config)#queue-profile multicasthost1(config-queue)#exithost1(config)#queue-profile internethost1(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


106 !

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

Configuring REDTo configure RED, perform the following steps:

1. Create a drop profile and enter Drop Profile Configuration mode.

host1(config)#drop-profile internetDropProfilehost1(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

/&*6&0

&//7

/7

/ 8��

�� %��

��

��

��

��

��

��+��

$�+��%��

� ��

Drop Profiles


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-thresholdconformed-thresholdexceeded-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 dp1host1(config-drop-profile)#

! Use the no version to remove the drop profile.

Drop Profiles ! 107


108 !

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 averageOnlyhost1(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 colorblind1host1(config-drop-profile)#committed-threshold percent 30 90 5host1(config-drop-profile)#exit

host1(config)#drop-profile colorblind2host1(config-drop-profile)#committed-threshold percent 30 90 5host1(config-drop-profile)#conformed-threshold percent 30 90 5host1(config-drop-profile)#exit

host1(config)#drop-profile colorblind3host1(config-drop-profile)#committed-threshold percent 30 90 5host1(config-drop-profile)#conformed-threshold percent 30 90 5host1(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.

Drop Profiles


Figure 5: Color-Blind RED Drop Profile with Colorless Queue Profile

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 nocolorhost1(config-drop-profile)#committed-threshold percent 30 90 5host1(config-drop-profile)#exithost1(config)#queue-profile colorlesshost1(config-queue)#committed-length 100000 100000 host1(config-queue)#conformed-fraction 100host1(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

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

1��

$�+��% /&*6&9

1��

��7

1��

$�+��% /&*6&6

1��

��7

Drop Profiles ! 109


110 !

! 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 colorblindRedhost1(config-drop-profile)#committed-threshold percent 30 90 5host1(config-drop-profile)#exithost1(config)#queue-profile colorSensitivehost1(config-queue)#committed-length 100000 100000

How WRED WorksWRED 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 WREDYou 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 wredColoredhost1(config-drop-profile)#committed-threshold percent 30 90 3host1(config-drop-profile)#conformed-threshold percent 25 90 5host1(config-drop-profile)#exceeded-threshold percent 20 90 10

Drop Profiles


Figure 7: Different Treatment of Colored Packets

Defining Different Drop Behavior for Each Traffic ClassYou 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

1��

$�+��% /&*6&5

1��

��7

��-�&

��-�'

��-�*

��-�2

��-�5

��-�:

��.��

��

/&*6&2

�� ,��

� ��%��

�;�� %��

1��

��7

1��

��7

1��

��7

<�� &�8��

<�� '�8��

<�� *�8��

��8��

Drop Profiles ! 111


112 !

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 queue’s 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 internetDropProfilehost1(config-drop-profile)#average-length-exponent 9host1(config-drop-profile)#committed-threshold percent 30 90 4 host1(config-drop-profile)#conformed-threshold percent 25 90 5host1(config-drop-profile)#exceeded-threshold percent 20 90 6

Drop Profiles


Figure 9: WRED and Dynamic Queue Thresholding

��7

1��

��7

1��

��7

1��

��7

1��

��7

1��

��7

1��

��7

1��

��7

1��

��7

1��

1��

/

$�+��%

&

'

*

2

5

6

9

0�� .��%��%

/&*6&*

Drop Profiles ! 113


114 !

Scheduler Profiles

The egress line module scheduler is an HRR scheduler. Figure 10 is an example of a QoS scheduler’s hierarchy.

Figure 10: QoS Scheduler Hierarchy

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.

=(��%-�%��>

/&2**2

1��?�� =(��>

�<$�'?/@'�<$�'?/@& �<$�'?/@' �<$�'?/@&

�� ,��=��>

�<$�'?/��

4�-,��"��

(��,��

4�-,��"��

(��,��

4�-,�� ""��

4�-,�� "��

4�-,�� ""��

4�-,�� "��

��

��

��

Scheduler Profiles


! 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.

Hierarchical Assured RateThe 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 queue’s 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.

NOTE: For E-series ASIC modules, strict priority is supported only for a single first-level scheduler node.

Scheduler Profiles ! 115


116 !

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 node’s 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

Configuring Scheduler ProfilesTo configure a scheduler profile, perform the following steps:

1. Create a scheduler profile, and enter Scheduler Profile Configuration mode.

host1(config)#scheduler-profile sp-1mbshost1(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

/&**)&

(��,��%��'/�A��

(��,��%��'/�A��

(��,��%��'/�A��

B�%��&�$��

B�

B�'

C�*

B�& B��

B� B�

Scheduler Profiles


4. (Optional) Set strict-priority scheduling.

host1(config-scheduler-profile)#strict-priority

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 25000–1000000000 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 64000–1000000000 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 0–522240. Specifying 0 enables the router to select an applicable default value.

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.

Scheduler Profiles ! 117


118 !

! 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 0–4080. 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.

Shared Shaping


Sharing Bandwidth with the SAROn 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 WorksYou 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 ShapingSimple 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


120 !

Simple Shared Shaping ExampleIn 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

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.

/&2**5��

#��3�

B��&#��3�

B�� <��D��

B��*#��3�

B�� <��D��

#��

B��'#��

B�%��<��D�%��

B��*#��

B�%��<��D�%��

��<��,��

��<��,��

��<��,��

<�� #�� , ��,�� %��%��B��'�� E

B��&��

B��'��

EB��*��

Shared Shaping


Simple Shared Shaping on the Best-Effort Scheduler NodeIf 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 ModeJUNOSe 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 SAR—the 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.



122 !

Compound Shared ShapingCompound 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 ConstituentsWhen 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.

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.



124 !

Types of Shared ShapersThe 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 implicit—Constituents 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 explicit—The 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 implicit—Constituents 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 explicit—The 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 SelectionThe 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.

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

/&2*09��

#��3�

B��&#��3�

B�� <��D��

B��*#��3�

B�� <��D��

#��

B��'#��

B�%��<��D�%��

B��*#��

B�%��<��D�%��

�� %��,��%,��,��&//////

�

E<�� #�� , ��,�� %��%��B��'��

��<��,��

B��&��

��<��,��

B��'��

E

��<��,��

B��*��



126 !

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 B’s 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

/&2*00��

#��3�

B��&#��3�

B�� <��D��

B��*#��3�

B�� <��D��

#��

B��'#��

B�%��<��D�%��

B��*#��

B�%��<��D�%��

E

(

<�� #�� , ��,�� %��8��B��*��

(�� %��,��%,��,��&//////

��<��,��

B��&��

��<��,��

B��'��

��<��,��

E

B��*��

Shared Shaping


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

Implicit Bandwidth Allocation for Compound Shared ShapingAfter 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.

B��&<��D��

B��*��

B��*<��,��

#��

B��&#��

/&2*0)

��

#��3�

B��&#��3�

E

�� %��,��%,��,��&//////(�� %��,��%,��,��&//////�� %��,�� %,��,��&//////

B��&<��D��

"��&<��D��

"��&<��D�%��

B��&<��D�%��

B��'<��,��

B��'��

"��&<��,��

B��&��

(

�

�

B��&<��%��

E<�� #�� , ��,�� %��8��"��&��

B��&��



128 !

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.

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.



130 !

Figure 16: Weighted Shared Shaping

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.

/&2*00

��

#��3�

B��&#��3�

B�� <��D��

B��'#��3�

B�� <��D��

#��

B��&#��

��<��%��

B��'#��

��<��%��

B��&��

��<��,��

B��'��

��<��,��

<�� #�� , �� %��,��

��%,��,��&//////��%,��, ��-��&(�� %��,��%,��, ��-��*&

� (

Shared Shaping


Explicit Constituent SelectionIf 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 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

! To specify the logical interface for shared 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 for the same logical interface type.

! Constituents consist of all nodes and queues for the same logical interface type.

! Active constituents are automatically selected from all constituents according to the implicit shared shaping rules.

! Active constituents are explicitly selected 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.



132 !

Explicit Shared Shaping ExampleIn 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

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.

/&2*06

��

#��3�

B��&#��3�

B�� <��D��

B��'#��3�

B�� <��D��

#��

B��&#��

B�%��<��D�%��

B��'#��

B�%��<��D�%��

B��&��

��<��,��

B��'��

��<��,��

<�� #�� , ��

�� %��,��%,��,��&//////� ��%��+�� , ��%,��, ��(�� %��,��%,��, ��

� (

Shared Shaping


Explicit Weighted Compound Shared Shaping ExamplesFigure 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

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:

B4�:�'<��D�� &

B4�:�'<��D�� '

/&2*02

��

#��3�

#��

<�� #�� , ��

�� %��,��%,��,��&//////� ��%��+�� , ��%,��, ��-��&(�� %��,��%,��,��&//////� ��%��+�� , ��%,��, ��-��*�� %��,�� %,��, ��-��'�� %��,��%��%,��, ��-��23�� %��,��%,��, ��-��*

�

��

B4�:�'#��3�

B4�:�&#��3�

B4�:�&<��D�� &

B4�:�&<��D�� '

B4�:�&#��(3

B4�:�&<��,��

B4�:�&<��%��

B4�:�'#��(3

B4�:�'<��,��

B4�:�'<��%��

B4�:�&#��

B4�:�&<��D�%��

B4�:�'#��

B4�:�'<��D�%��

( �3�

Table 19: Bandwidth Allocation for Case 1 Explicit Constituents

Explicit Constituent Bandwidth Allocation

VLAN 1 TC voice1 queue Strict constituent that can consume up to its legacy shaping-rate or the shared-shaping rate.

VLAN 1 TC voice2 queue Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 4/10.

VLAN 1 TC video queue Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 3/10.

VLAN 1 TC data queue Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 2/10.

VLAN 1 TC best-effort queue Weighted constituent that shared bandwidth with weighted shared shaper siblings in a proportion of 1/10.



134 !

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

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:

B4�:�'<��D�� &

B4�:�'<��D�� '

/&2*0*

��

#��3�

#��

<�� #�� , ��

(�� %��,��%,��,��&//////� ��%��+�� , ��%,��, ��-��*�� %��,��+��%,��, ��-��' �� %��,��%,��, ��-��2!�� %��,��F��%,��, ��-��*

��#��

B4�:�'#��3�

B4�:�&#��3�

B4�:�&<��D�� &

B4�:�&<��D�� '

B4�:�&#��(3

B4�:�&<��,��

B4�:�&<��%��

B4�:�'#��(3

B4�:�'<��,��

B4�:�'<��%��

B4�:�&#��

B4�:�&<��D�%��

B4�:�'#��

B4�:�'<��D�%��

( �!

Table 20: Bandwidth Allocation for Case 2 Explicit Constituents

Explicit Constituent Bandwidth Allocation

VLAN 1 TC voice1 queue Strict constituent that can consume up to its legacy shaping-rate or the shared-shaping rate.

VLAN 1 TC voice2 queue Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 4/10.

VLAN 1 TC video queue Weighted constituent that shares bandwidth with its weighted shared shaper siblings in a proportion of 3/10.

VLAN 1 TC best-effort node Weighted constituent that shared bandwidth with weighted shared shaper siblings in a proportion of 3/10.

Shared Shaping


Simple Shared Shaping Configuration ExamplesConfigure 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 64000–100000000 bps (64 Kbps–1 Gbps); the default is no shaping rate.

! Burst is the catch-up number associated with the shaper; the range is 0–522240 (0–510 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.



136 !

VC Simple Shared Shaping ExampleThe 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

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 ExampleIn 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.



138 !

Figure 20: VP Shared Shaping

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

B��&

E

/&2**6��<��

#�� , ��,�� %��%��B��&�� E

#��

B�%��<��D�%��B��&

B�%��<��D�%��B��&

#��3�

B�� <��D�� B��&B��&

��

��<��,��

B��'��

��<��,��

B��*��

��<��,��

Shared Shaping


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 ShapingYou 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 ExamplesCompound 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.



140 !

! 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 64000–100000000 bps (64 Kbps–1 Gbps); the default is no shaping rate.

! Burst is the catch-up number associated with the shaper; the range is 0–522240 (0–510 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 1–8 and the default value is 8. A lower value correlates to a higher claim.

! For weighted constituents, the range is 1–31 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.

Shared Shaping


Configuration RestrictionsAlthough 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 ExampleThe 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 800–1000 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 500–1000 Kbps of shared bandwidth.

Figure 21: VC Compound Shared Shaping Example

/&2*0'

��

#��3�

B��&#��3�

B�� <��D��

B��'#��3�

B�� <��D��

#��

B��&#��

B�%��<��D�%��

B��'#��

B�%��<��D�%��

B��&��

��<��,��

B��'��

��<��,��

<�� #�� , ��

��%��%��(��4�� '//A��4�� *//A��

� �(



142 !

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-1Mbpshost1(config-scheduler-profile)#shared-shaping-rate 1000000 burst 32768 autohost1(config)#scheduler-profile 300Kbpshost1(config-scheduler-profile)#shaping-rate 300000host1(config)#scheduler-profile 200Kbpshost1(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 defaulthost1(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 nodehost1(config-qos-profile)#atm-vc node group AFhost1(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-1mbpshost1(config-qos-profile)#atm-vc queue traffic-class video scheduler-profile 300Kbpshost1(config-qos-profile)#atm-vc queue traffic-class voice scheduler-profile 200Kbpshost1(config-qos-profile)#exit

7. Attach the QoS profile to an ATM subinterface.

host1(config)#interface atm 11/0.1host1(config-interface)#qos-profile vcSharedShapinghost1(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

Shared Shaping


To display the sample shared shaper configuration:

host1#show shared-shaper atm 11/0.1

shared current shaping shaping shaping interface rate rate resource rate---------------- ------- ------- ------------------------- -------atm-vc ATM11/0.1 1000000 compound best-effort atm-vc queue atm-vc best-effort node EF voice atm-vc queue 200000 AF video atm-vc queue 300000atm-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 ExampleThe 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.6–5 Mbps on the VP. Finally, the data traffic has the last claim to the remaining 2.6–3 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.



144 !

Figure 22: VP Compound Shared Shaping Example

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-5Mbpshost1(config-scheduler-profile)#shared-shaping-rate 5000000 burst 32768 autohost1(config-scheduler-profile)#exit

3. Configure the scheduler-profile for AF (video) traffic.

host1(config)#scheduler-profile 2Mbpshost1(config-scheduler-profile)#shaping-rate 2000000

4. Configure the scheduler-profile for EF (voice) traffic.

host1(config)#scheduler-profile 400Kbpshost1(config-scheduler-profile)#shaping-rate 400000host1(config-scheduler-profile)#exit


host1(config)#qos-profile vpSharedShaping

6. Create group nodes.

host1(config-qos-profile)#atm group AF scheduler-profile defaulthost1(config-qos-profile)#atm group EF scheduler-profile default

B��*��

B��*<��,��

#��

/&2*0&

��

#��3�

B��&#��3�

��%��%��(��4�� 2//A��4�� '$��

B��*<��D��

B��&<��D��

B��'<��D��

B��'<��,��

B��'��

�

<�� #�� , ��

B��&<��,��

B��&��

B��&#��

B��*<��D�%��

B��&<��D�%��

B��'<��D�%��

( �B��&��

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-5Mbpshost1(config-qos-profile)#atm-vp node group AF scheduler-profile 2Mbpshost1(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-efforthost1(config-qos-profile)#atm-vc queue traffic-class AFhost1(config-qos-profile)#atm-vc queue traffic-class EFhost1(config-qos-profile)#exit

10. Attach the QoS profile to an ATM subinterface.

host1(config)#interface atm 11/0.1host1(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 CaveatsWhen you configure shared shaping, be sure to consider the following behaviors.

Hardware DependencyCompound 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.



146 !

Logical Interface Traffic Carried in Other QueuesA 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 StarvationTraffic 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 strictOnehost1(config-scheduler-profile)#shaping-rate 1000000host1(config-scheduler-profile)#exithost1(config)#scheduler-profile nonStrictOne host1(config-scheduler-profile)#shared-shaping-rate 1500000

OversubscriptionMany 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 SizeThe 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.

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 bestEffortBursthost1(config-scheduler-profile)#shared-shaping-rate 1000000 burst 30000host1(config-scheduler-profile)#exithost1(config)#scheduler-profile voiceBursthost1(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 burstExamplehost1(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 bestEffortBursthost1(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 period—Time 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 threshold—Threshold for forwarding rate events. A forwarding-rate event is counted whenever the forwarding rate exceeds the specified threshold.

! Committed drop threshold—Threshold above which committed drop rate events are counted.

! Conformed drop threshold—Threshold above which conformed drop rate events are counted.

! Exceeded drop threshold—Threshold above which exceeded drop rate events are counted.

Statistics Profiles ! 147


148 !

Rate StatisticsYou 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.

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-5host1(config-statistics-profile)#rate-period 45host1(config-statistics-profile)#exit

2. Reference the statistics profile by a QoS profile.

host1(config)#qos-profile qospro-3host1(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/0host1(config-subif)#qos-profile qospro-3host1(config-subif)#exit

4. (Optional) Display the rate statistics.

host1#show egress-queue rates

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.

Statistics Profiles


Event StatisticsYou 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-1host1(config-statistics-profile)#rate-period 30host1(config-statistics-profile)#forwarding-rate-threshold 10000000host1(config-statistics-profile)#committed-drop-threshold 2000000host1(config-statistics-profile)#conformed-drop-threshold 4000000host1(config-statistics-profile)#exceeded-drop-threshold 6000000host1(config-statistics-profile)#exit

2. Reference the statistics profile by a QoS profile.

host1(config)#qos-profile qospro-1host1(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/0host1(config-subif)#qos-profile qospro-1host1(config-subif)#exit

4. (Optional) Display the rate statistics.

host1#show egress-queue events

Statistics Profiles ! 149


150 !

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.

Configuring Statistics ProfilesTo 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-thresholdconformed-drop-thresholdexceeded-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 0–1073741824 bps; default is no threshold.

! Example

host1(config-scheduler-profile)#committed-drop-rate 50000

! Use the no version to delete the drop rate threshold.

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 you’ve 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.

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 0–1073741824 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 1–43200 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-1host1(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


152 !

Configuring QoS ProfilesTo 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.

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-queuinghost1(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

Table 21: Interface Types and Supported Commands

Interface Type Queue Node Group

atm x x x

atm-vc x x

atm-vp x x

bridge x x

cbf x x

ethernet x x x

fr-vc x x

ip x x

ip-tunnel x x

ipv6 x x

l2tp-session x x

l2tp-tunnel x x

lsp x x

serial x x x

server-port x x x

vlan x x

QoS Profiles


4. (Optional) Display the components of the QoS profile.

host1#show qos-profile

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

Creating QoS ProfilesUse 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 ProfilesUse 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


154 !

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.

! 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 ProfilesUse 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/0host1(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.

NOTE: For ASIC modules, you cannot associate a scheduler profile with a port-type interface unless you also specify the strict-priority group.

QoS Profiles


qos-profile! Use to attach a QoS profile to an interface.

! Example

host1(config)#interface atm 2/0host1(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 series—the 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.

Integrating the HRR Scheduler and SAR SchedulerThe proper integration of the two schedulers is an important element of the router’s ATM QoS support. There are three QoS port modes that control integration of the two schedulers:

! Default integrated QoS port mode—ATM application controls the scheduling facilities of the SAR scheduler.

! Low-latency QoS port mode—HRR scheduler controls the traffic rate.

! Low-CDV QoS port mode—HRR 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.

NOTE: The term HRR scheduler is used in this chapter to describe the scheduling performed by the ASIC on the ATM line module.

Configuring QoS for ATM Interfaces ! 155


156 !

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 scheduler’s 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.

BackpressureATM 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.

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.

Table 22: qos-mode-port Commands

Command Backpressure SAR Buffering Scheduling

no qos-mode-port (default integrated mode) VC and port significant SAR

qos-mode-port low-cdv port normal SAR and HRR

qos-mode-port low-latency port minimal HRR

qos-mode-port port minimal HRR

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.

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.



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

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.

�� %��

�� %��

��,B��%,��

/&2*56

B�'B�&��,�� .��%,��

B�� .��

B�& B�'

"�& "�' "�*

"�& � ��%��%�1�� <��

��- (� .��

C�*��

C�*��



158 !

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-port—The 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-latency—The 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-cdv—The 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.

Configuring the Operational QoS Shaping ModeThe 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.

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.



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

Ruleqos-shaping-modefor the Specific Port

qos-shaping-mode for Port 0

qos-mode-portfor Port 0

Operational Shaping Mode for the Specific Port

Rule 1 Cell Cell low-cdv Cell

Frame Frame low-latency or none Frame

Rule 2 No shaping mode Cell low-cdv Cell

No shaping mode Frame low-latency or none Frame

Rule 3 No shaping mode No shaping mode low-cdv Cell

No shaping mode No shaping mode low-latency or none Frame



160 !

ATM QoS Configuration ExamplesThis section provides configuration examples for the three modes for QoS on ATM interfaces.

Default Integrated ModeIn 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

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

�� %��

�� %��

��,B��%,��

/&2*56

B�'B�&��,�� .��%,��

B�� .��

B�& B�'

"�& "�' "�*

"�& � ��%��%�1�� <��

��- (� .��

C�*��

C�*��



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 ModeIn 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

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 stricthost1(config-traffic-class-group)#traffic-class stricthost1(config-traffic-class-group)#exit

�� %��

/&2*59

B�'B�&��,�� .��%,��

�� .��

"�& "�' "�*

:��B�� .�� C�*��

C�*��

�� %��



162 !

3. Define the scheduler profile for the traffic-class group.

host1(config)#scheduler-profile stricthost1(config-scheduler-profile)#strict-priorityhost1(config-scheduler-profile)#exit

4. Configure the QoS profile with two ATM VC queues.

host1(config)#qos-profile low-latency-q-phost1(config-qos-profile)#atm-vc nodehost1(config-qos-profile)#atm-vc queue traffic-class best-efforthost1(config-qos-profile)#atm group strict scheduler-profile stricthost1(config-qos-profile)#atm-vc queue traffic-class stricthost1(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/0host1(config-if)#qos-mode-port low-latencyhost1(config-if)#qos-profile low-latency-q-p



Low-CDV ModeIn 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)

�� %��

��B��

/&2*5)

B��%,��

��B�� .�� C�*��

C�*��

B�'B�&

B�'B�&

B�& B�' B�* B�2

�� %��



164 !

Figure 27: Low-CDV Mode (per-VC CDVT)

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 stricthost1(config-traffic-class)#exit

2. Set the traffic class in the traffic-class group.

host1(config)#traffic-class-group stricthost1(config-traffic-class-group)#traffic-class stricthost1(config-traffic-class-group)#exit

3. Define the scheduler profiles for the traffic-class group.

host1(config)#scheduler-profile stricthost1(config-scheduler-profile)#strict-priorityhost1(config-scheduler-profile)#exit

host1(config)#scheduler-profile 500khost1(config-scheduler-profile)#shaping-rate 500000host1(config-scheduler-profile)#exit

�� %��

B��

/&2*50

B�& B�' B�* B�2 B�5

B�'B�&��,�� .��%,��

��B�� .��

B�& B�' B�* B�2 B�5

C�*��

C�*�� %��



host1(config)#scheduler-profile 1mhost1(config-scheduler-profile)#shaping-rate 1000000host1(config-scheduler-profile)#exit

host1(config)#scheduler-profile 2mhost1(config-scheduler-profile)#shaping-rate 2000000host1(config-scheduler-profile)#exit

4. Configure the QoS profile with two ATM VC queues.

host1(config)#qos-profile low-cdv-q-phost1(config-qos-profile)#atm-vc node scheduler-profile 1mhost1(config-qos-profile)#atm-vp node scheduler-profile 2mhost1(config-qos-profile)#atm-vc queue traffic-class best-efforthost1(config-qos-profile)#atm group strict scheduler-profile stricthost1(config-qos-profile)#atm-vc queue traffic-class strict scheduler-profile 500khost1(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/0host1(config-if)#atm vp-tunnel 0 0host1(config-if)#atm vp-tunnel 1 0host1(config-if)#qos-mode-port low-cdvhost1(config-if)#qos-profile low-cdv-q-p

host1(config-subif)#interface atm 2/0.5host1(config-subif)#atm pvc 5 0 5 aal5snaphost1(config-subif)#interface atm 2/0.6host1(config-subif)#atm pvc 6 0 6 aal5snaphost1(config-subif)#interface atm 2/0.7host1(config-subif)#atm pvc 7 1 7 aal5snaphost1(config-subif)#interface atm 2/0.8host1(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/0host1(config-if)#atm vp-tunnel 0 0

! Use the no version to remove the VP tunnel specification.



166 !

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.

! When the low-cdv keyword is used:

! 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.

! The following restrictions apply to this command:

! 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)

! Example

host1(config)#interface atm 1/0host1(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.



qos-shaping-mode! Use to configure the ATM QoS shaping mode.

! Specify one of the following shaping modes:

! frame—SAR 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.

! cell—SAR 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/0host1(config-if)#qos-shaping-mode cell

! Use the no version to restore the default setting, frame.

Configuring QoS for L2TP Interfaces

The JUNOSe software supports QoS queues and scheduler nodes for L2TP session interfaces. L2TP QoS provides per–L2TP 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 rule traffic scheduler queue drop statistics group type type class profile profile profile profile-------- ------------ ----- ----------- --------- ------- ------- ---------- l2tp-session queue best-effort default default default default

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 ! 167


168 !

Configuration ProcedureThis 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-defaulthost1(config-qos-profile)#no ip queue traffic-class best-efforthost1(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 voicehost1(config-traffic-class-group)#exit


a. Create the QoS profile, and enter QoS Profile Configuration mode.

host1(config)#qos-profile l2tpQpro25host1(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 400khost1(config-qos-profile)#lt2p-session queue traffic-class voice scheduler-profile 100khost1(config-qos-profile)#exithost1(config)#

4. (Optional) Verify the new QoS profile configuration.

host1(config)#show qos-profile l2tpQpro25

qos-profile l2tpQpro25:t-class interface rule traffic scheduler queue drop statistics group type type class profile profile profile profile-------- --------- ----- ----------- --------- ------- ------- ---------- l2tp-session queue best-effort 400k default default defaulttcGroup1 l2tp-session queue voice 100k default default default

Configuring QoS for L2TP Interfaces


Scheduler HierarchiesThis 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

Figure 29: LNS (MLPPP) QoS Scheduler Hierarchy

Figure 30: LAC over Ethernet (Without VLANs) Scheduler Hierarchy

/&2*9&

(��,��8�� B�� 8��

��D� ��

4'<��

2// &//

� #��&

/&2*60

4'<�� #��&4'<��

B�� 8�� B�� 8��(��,��8��(��,��8��

��D��

2// &// &//2//

/&2*95

(��,��8�� B�� 8��

3��

4'<�� #��&

Configuring QoS for L2TP Interfaces ! 169


170 !

Figure 31: LAC over Ethernet (With LANs) Scheduler Hierarchy

Figure 32: LAC over AT

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 InterfaceTo 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

/&2*9*

(��,��8��

B�� 8��

3��

B4�:

4'<��

� #��&

/&2*99

(��,��8��

B�� 8��

�<$

�<$,B�

4'<��

� #��&



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/1host1(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/1host1(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.

QoS Profile Attachments ! 171


172 !

! 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 ProfileQoS 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. If there is a QoS profile attached at the port, add the profile’s rules to the munged QoS profile, and the munge algorithm is then complete.

b. 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.



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

The port-attached QoS profile on ATM 11.0 contains the following queue rule:

host1(config)#qos-profile atmPorthost1(config-qos-profile)#ip queue traffic-class priority-data scheduler-profile 64kbpshost1(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 atmVchost1(config-qos-profile)#ip queue traffic-class priority-data scheduler-profile 1mbpshost1(config-qos-profile)#ip queue traffic-class voice-over-iphost1(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.

/&*'25

1��G��,%��

��%��62�A��

1��G��,%��

��%��&�$��

1��GD�� ,�D��,"�

�<$&&?/

�<$&&?/@'

�<$&&?/@&

QoS Profile Attachments ! 173


174 !

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.

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.1—QoS profile qp1 is attached


! ATM 11/0.3—No 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 1—Attaching QoS Profiles to ATM Subinterfaces

To configure this example:

1. Create and configure QoS profile qp1.

host1(config)#qos-profile qp-1host1(config-qos-profile)#atm-vp node scheduler-profile sp1 host1(config-qos-profile)#atm-vc queue traffic-class tc1 scheduler-profile sp1 queue-profile qp1 host1(config-qos-profile)#atm-vc queue traffic-class tc2 scheduler-profile sp2 queue-profile qp2host1(config-qos-profile)#atm-vc queue traffic-class tc3 scheduler-profile sp3 queue-profile qp3

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.

�<$�&&?/@&�B� �<$�&&?/@'�B� �<$�&&?/@*�B�

�<$�&&?/��

8��,��8�'8��,��8�&

/&*9'/

8��,��,��,��,%��



host1(config-qos-profile)#atm-vc queue traffic-class tc4 scheduler-profile sp4 queue-profile qp4host1(config-qos-profile)#atm-vc queue traffic-class tc5 scheduler-profile sp5 queue-profile qp5host1(config-qos-profile)#exit

2. Create and configure QoS profile qp2.

host1(config)#qos-profile qp2host1(config-qos-profile)#atm-vp node scheduler-profile sp1 host1(config-qos-profile)#atm-vc queue traffic-class tc1 scheduler-profile sp1 queue-profile qp1host1(config-qos-profile)#atm-vc queue traffic-class tc2 scheduler-profile sp2 queue-profile qp2host1(config-qos-profile)#atm-vc queue traffic-class tc3 scheduler-profile sp3 queue-profile qp3host1(config-qos-profile)#exit

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 qp1host1(config-subif)#exithost1(config)#interface atm 11/0.2host1(config-subif)#qos-profile qp2host1(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/0attachment@ atm-vc ATM11/0.2: qos interface rule traffic scheduler queue t-classprofile type type class profile profile group------- --------- ---- ------- --------- ------- ------- qp2@ATM11/0.2 atm-vp node sp1 defaultqp2@ATM11/0.2 atm-vc queue tc1 sp1 qp1qp2@ATM11/0.2 atm-vc queue tc2 sp2 qp2qp2@ATM11/0.2 atm-vc queue tc3 sp3 qp3atm-default @atm ip node default defaultatm-default @atm atm-vc node default defaultatm-default @atm cbf node default defaultatm-default @atm Bridge node default defaultatm-default @atm ipv6 node default defaultatm-default @atm ip queue best-effort default defaultatm-default @atm atm queue best-effort default defaultatm-default @atm atm-vc queue best-effort default defaultatm-default @atm cbf queue best-effort default defaultatm-default @atm Bridge queue best-effort default defaultatm-default @atm ipv6 queue best-effort default default

QoS Profile Configuration Examples ! 175


176 !

attachment@ atm-vc ATM11/0.1: qos interface rule traffic scheduler queue t-classprofile type type class profile profile group------- --------- ---- ------- --------- ------- ------- qp1@ATM11/0.1 atm-vp node sp1 defaultqp1@ATM11/0.1 atm-vc queue tc1 sp1 qp1qp1@ATM11/0.1 atm-vc queue tc2 sp2 qp2qp1@ATM11/0.1 atm-vc queue tc3 sp3 qp3qp1@ATM11/0.1 atm-vc queue tc4 sp4 qp4qp1@ATM11/0.1 atm-vc queue tc5 sp5 qp5atm-default @atm ip node default defaultatm-default @atm atm-vc node default defaultatm-default @atm cbf node default defaultatm-default @atm Bridge node default defaultatm-default @atm ipv6 node default defaultatm-default @atm ip queue best-effort default defaultatm-default @atm atm queue best-effort default defaultatm-default @atm atm-vc queue best-effort default defaultatm-default @atm cbf queue best-effort default defaultatm-default @atm Bridge queue best-effort default defaultatm-default @atm ipv6 queue best-effort 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.3attachment@ atm ATM11/0: qos interface rule traffic scheduler queue t-classprofile type type class profile profile group------- --------- ---- ------- --------- ------- ------- atm-default@atm ip node default defaultatm-default@atm atm-vc node default defaultatm-default@atm cbf node default defaultatm-default@atm Bridge node default defaultatm-default@atm ipv6 node default defaultatm-default@atm ip queue best-effort default defaultatm-default@atm atm queue best-effort default defaultatm-default@atm atm-vc queue best-effort default defaultatm-default@atm cbf queue best-effort default defaultatm-default@atm Bridge queue best-effort default defaultatm-default@atm ipv6 queue best-effort default default



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.1—No QoS profile is explicitly attached


! ATM 11/0.3—No 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 2—Attaching QoS Profile to ATM Interface and Subinterface

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/0host1(config-if)#qos-profile qp1host1(config-if)#exit

3. Attach QoS profile qp2 to ATM subinterface 11/0.2.

host1(config)#interface atm 11/0.2host1(config-subif)#qos-profile qp2host1(config-subif)#exithost1(config)#exit

4. Display the QoS interface hierarchy for ATM 11/0.

host1#show qos interface-hierarchy atm 11/0qos interface rule traffic scheduler queue t-classprofile type type class profile profile group------- --------- ---- ------- --------- ------- ------- @ATM11/0 atm queue best-effort default defaultqp1@ATM11/0 atm-vp node sp1 defaultqp1@ATM11/0 atm-vc queue tc1 sp1 qp1qp1@ATM11/0 atm-vc queue tc2 sp2 qp2qp1@ATM11/0 atm-vc queue tc3 sp3 qp3qp1@ATM11/0 atm-vc queue tc4 sp4 qp4qp1@ATM11/0 atm-vc queue tc5 sp5 qp5

�<$�&&?/@&�B� �<$�&&?/@'�B� �<$�&&?/@*�B�

�<$�&&?/��

8��,��8�'

8��,��8�& /&*9'&

QoS Profile Configuration Examples ! 177


178 !

attachment@ atm-vc ATM11/0.2:qos interface rule traffic scheduler queue t-classprofile type type class profile profile group------- --------- ---- ------- --------- ------- ------- qp2@ATM11/0.2 atm-vp node sp1 defaultqp2@ATM11/0.2 atm-vc queue tc1 sp1 qp1qp2@ATM11/0.2 atm-vc queue tc2 sp2 qp2qp2@ATM11/0.2 atm-vc queue tc3 sp3 qp3@ATM11/0 atm queue best-effort default defaultqp1@ATM11/0 atm-vc queue tc4 sp4 qp4qp1@ATM11/0 atm-vc queue tc5 sp5 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.



! 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

Diffserv Configuration with Multiple Traffic-Class Groups ! 179


180 !

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.



Figure 36: Diffserv Configuration with Multiple Traffic-Class Groups

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.

"��'"��& "��'"��&"��' "��* "��*"��&

/&22/'

��

��#��

0��

0��

3�#��

9��

9��

)��

)��

)��

(3��H�%��%��-��%��H�D�%��3��+��%��%��-��%��H�D��

2 2 2 5 5 6 6

' *(3

#��

&

Diffserv Configuration with Multiple Traffic-Class Groups ! 181


182 !

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 defaultconfig-qos-profile)#ip queue traffic-class voice scheduler-profile voiceconfig-qos-profile)#ip queue traffic-class video scheduler-profile videoconfig-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

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.

"��'"��& "��'"��&"��' "��*

/&22/*

��

��

"��*"��&

3+��%��%��-��%��=D�� >

��%��-��%��=D�%��>

(��,��=%��>

B�%�� B�%�� B�� B��

Strict-Priority Scheduling


Example

host1(config-qos-profile)#atm group strict scheduler-profile strictpriority

Figure 38 is an example of a QoS scheduler’s hierarchy.

Figure 38: QoS Scheduler Hierarchy

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 strictPriorityBandwidthhost1(config-scheduler-profile)#shaping-rate 20000000host1(config-scheduler-profile)#exit

2. Configure the traffic classes.

host1(config)#traffic-class Low-loss-1host1(config-traffic-class)#exithost1(config)#traffic-class Low-latency-1host1(config-traffic-class)#exithost1(config)#traffic-class Low-latency-2host1(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-priorityhost1(config-traffic-class-group)#traffic-class Low-latency-1host1(config-traffic-class-group)#traffic-class Low-latency-2host1(config-traffic-class-group)#exit

=(��%-�%��>

/&2**2

1��?�� =(��>

�<$�'?/@'�<$�'?/@& �<$�'?/@' �<$�'?/@&

�� ,��=��>

�<$�'?/��

4�-,��"��

(��,��

4�-,��"��

(��,��

4�-,�� ""��

4�-,�� "��

4�-,�� ""��

4�-,�� "��

��

��

��

Strict-Priority Scheduling ! 183


184 !

4. Configure a QoS profile.

host1(config)#qos-profile Example-qos-profilehost1(config-qos-profile)#atm group defaulthost1(config-qos-profile)#atm group Strict-priority scheduler-profile strictPriorityBandwidthhost1(config-qos-profile)#atm-vc node group defaulthost1(config-qos-profile)#atm-vc node group Strict-priorityhost1(config-qos-profile)#atm-vc queue traffic-class best-efforthost1(config-qos-profile)#atm-vc queue traffic-class Low-loss-1host1(config-qos-profile)#atm-vc queue traffic-class Low-latency-1host1(config-qos-profile)#atm-vc queue traffic-class Low-latency-2host1(config-qos-profile)#exit

5. Attach the QoS profile to an interface.

host1(config)#interface atm 2/0host1(config-if)#qos-profile Example-qos-profilehost1(config-if)#exithost1(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.



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

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.

B�� .��

��,B��%,��

IB�&H�(3J IB�'H�(3J IB�&H�� J IB�'H�� J

B�& B�'

B�&

�� %��

/&2*6&

B�' ��

C�*��

C�*��

�� %��

Relative Strict-Priority Scheduling ! 185


186 !

Relative Strict PriorityIn 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

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.

�� %��

��,B��%,��

IB�&H�(3J IB�&H�� J IB�'H�(3J IB�'H�� J

/&2*6/

C�*��

C�*��

B�& B�'

�� %��



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 pre–cell tax rate, whereas true strict priority shapes the aggregate for the VC to a post–cell 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.

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.

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.



188 !

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.



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

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

/&*9&0

IB�&H�:�� J IB�&H��D�� J

B�& IB�&H��J

5//�A��&�$��

&�$��

C�*��

IB�&H�:�� J IB�&H��D�� J

B�& IB�&H��J

&�$��

5//�A��

��

D ��

/&*9&)



190 !

To configure relative strict priority as shown in Figure 42:

1. Create a scheduler profile for the strict-priority queue.

host1(config)#scheduler-profile relativeStricthost1(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 behost1(config-scheduler-profile)#shaping-rate 1000000 burst 1host1(config-scheduler-profile)#weight 8host1(config-scheduler-profile)#exit

3. Create a scheduler profile for the VC aggregate node.

host1(config)#scheduler-profile vcAggregatehost1(config-scheduler-profile)#shaping-rate 1000000host1(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 behost1(config-qos-profile)#atm-vc queue traffic-class voice scheduler-profile relativeStricthost1(config-qos-profile)#exithost1(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




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 64000–1000000000 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 0–522240. 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 0–4080.

! 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


192 !

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

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 80mbpshost1(config-scheduler-profile)#shaping-rate 80000000host1(config-scheduler-profile)#exithost1(config)#qos-profile 80mbpshost1(config-qos-profile)#ethernet node scheduler-profile 80mbpshost1(config-qos-profile)#exit host1(config)#interface fastethernet 2/0host1(config-if)#qos-profile 80mbps

To shape the corresponding HDLC channel down to 20 Mbps:

host1(config)#scheduler-profile 20mbpshost1(config-scheduler-profile)#shaping-rate 20000000host1(config-scheduler-profile)#exithost1(config)#qos-profile 20mbpshost1(config-qos-profile)#serial node scheduler-profile 20mbpshost1(config-qos-profile)#exithost1(config)#interface serial 2/0:1/1host1(config-if)#qos-profile 20mbps

/&2*6'3��

B4�: B4�:

��

�� %��

Port Shaping


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 interfaceshow 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-port—Per-port queuing mode status: disabled, low-latency, low-cdv

! qos-shaping-mode—QoS shaping mode: disabled, frame, cell, none

! Example—This example shows a partial output that includes the qos-mode-port and qos-shaping-mode information

host1#show interfaces atm 2/0ATM Interface 2/0 is up, line protocol is disabled

AAL5 operational status: up time since last status change: 01:08:32ATM operational status: up time since last status change: 01:08:32

Clearing Statistics ! 193


194 !

.

.

.InPackets: 0InBytes: 0InCells: 0OutPackets: 7803262OutBytes: 7803262000OutCells: 163868502InErrors: 0OutErrors: 0InPacketDiscards: 0InByteDiscards: 0InCellErrors: 0

Administrative qos-shaping-mode: frameOperational qos-shaping-mode: frameAdministrative qos-mode-port: noneOperational 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.


! drop profile—Name of the drop profile

! Average length exponent—Exponent used to weight the average queue length over time, controlling WRED responsiveness

! committed threshold—Minimum and maximum committed queue thresholds and maximum drop probability

! conformed threshold—Minimum and maximum conformed queue thresholds and maximum drop probability

! exceeded threshold—Minimum and maximum exceeded queue thresholds and maximum drop probability

! Example

host1#show drop-profile committed conformed exceeded threshold: threshold: threshold: Average min, min, min, drop length max, max, max,profile exponent max drop prob max drop prob max drop prob------- -------- ----------------- ----------------- -----------------default 0 0, <none>, <none> 0, <none>, <none> 0, <none>, <none>drop1 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop2 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop3 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop4 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop5 0 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop6 10 0, <none>, <none> 0, <none>, <none> 0, <none>, <none>drop7 10 10%, 90%, 5% 0, <none>, <none> 0, <none>, <none>

Monitoring QoS


drop8 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop9 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop10 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop11 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop12 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop13 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop14 10 0, 750000, 80% 0, <none>, <none> 0, <none>, <none>drop15 10 0, 750000, 80% 0, <none>, <none> 0, <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.


! interface—Name of the interface

! traffic class—Name of the traffic class

! forwarded events—Number of forwarded rate events

! committed drop events—Number of committed drop events

! conformed drop events—Number of conformed drop events

! exceeded drop events—Number of exceeded drop events

! rate period count—Time frame during which events are counted

! Example

host1#show egress-queue events gigabitEthernet 1/0

committed conformed exceeded rate traffic forwarded drop drop drop period interface class events events events events count---------------------- ------- --------- --------- --------- --------- ---------ip GigabitEthernet1/0 tc1 132 0 0 0 132 tc2 132 132 0 0 132 tc3 6 0 132 0 132 tc4 0 0 0 132 132

Monitoring QoS ! 195


196 !

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.


! interface—Name of interface


! forwarded rate—Forwarded rate statistics

! aggregate drop rate—Total number of all drop rates

! committed drop rate—Drop rate for green packets

! conformed drop rate—Drop rate for yellow packets

! exceeded drop rate—Drop rate for red packets

! Queues reported—Number of queues reported

! Queues filtered—Number 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 queues—Total number of queues within the hierarchical scope of the command

Monitoring QoS


! Example 1

host1#show egress-queue rates brief fastEthernet 9/0.2 traffic forwarded aggregate minimum maximuminterface 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: 0 0 Queues reported: 4 Queues filtered (under threshold): 0 Queues disabled (no rate period): 0 Queues disabled (no resources): 0 Total queues: 4

! Example 2

host1#show egress-queue rates color gigabitEthernet 1/0 traffic forwarded committed conformed exceeded interface class rate drop rate drop rate drop rate---------------------- ------- ------------ ------------ ------------ ------------ip GigabitEthernet1/0 tc1 14645184 0 0 0 tc2 11950400 2706400 0 0 tc3 9960792 0 4707200 0 tc4 7967200 0 0 6705600

Queues reported: 4Queues filtered (under threshold): 0Queues disabled (no rate period): 1Queues disabled (no resources): 0Total queues: 5

! Example 3

host1#show egress-queue rates full atm 11/0 traffic forwarded aggregate minimum maximum interface class rate drop rate rate rate--------------- ------------- --------- --------- -------- --------ip ATM11/0.1 best-effort * * 24979 30000000 tc1 0 0 14987510 30000000 tc2 0 0 9991673 30000000 tc3 0 0 4995836 30000000ip ATM11/0.2 best-effort * * 19980 20000000 tc1 0 0 11988011 20000000 tc2 0 0 7992007 20000000

Queues reported: 5 Queues filtered (under threshold): 0 * Queues disabled (no rate period): 2 **Queues disabled (no resources): 0 Total queues: 7



198 !

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.


! traffic class—Name of the traffic class for which statistics are being displayed

! egress slot—Egress slot for which statistics are being displayed

! type—Type of packet

! forwarded packets—Number of forwarded packet

! forwarded bytes—Number of forwarded bytes

! dropped packets—Number of dropped packets

! dropped bytes—Number of dropped bytes

! Example

host1#show fabric-queue traffic egress forwarded forwarded dropped dropped class slot type packets bytes packets bytes----------- ------ --------- --------- --------- ------- -------best-effort all committed 0 0 0 0best-effort all conformed 0 0 0 0best-effort all exceeded 0 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 0—Number of the queue for which statistics are being displayed and whether the queue is under traffic class control

! traffic class—Name of traffic class

! bound to—Interface to which queue is bound

! Queue length—Size of queue in length and bytes

! Forwarded—Number of forwarded packets and bytes

! Dropped committed—Number of committed packets and bytes dropped

! Dropped conformed—Number of conformed packets and bytes dropped

! Dropped exceeded—Number of exceeded packets and bytes dropped

! Dropped by WRED committed—Number of committed packets and bytes dropped by WRED

Monitoring QoS


! Dropped by WRED conformed—Number of conformed packets and bytes dropped by WRED

! Dropped by WRED exceeded—Number of exceeded packets and bytes dropped by WRED

! Average queue length—Average length of queue in bytes

! Example

host1#show ip interface atm 2/0.1ATM2/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 bytesqueue 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



200 !

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.


! attachment@—Interface for which the hierarchy is being displayed

! qos profile—Name of the QoS profile and its attachment point

! t-class group—Traffic-class groups associated with the interface

! interface type—Type of interface to which the profile is attached

! rule type—Queue, node, or group

! traffic class—Name of the traffic class associated with the queue

! scheduler profile—Scheduler profiles associated with the interface

! queue profile—Queue profiles associated with the interface

! Example

host1#show qos interface-hierarchy atm 11/0.1attachment@ atm-vc ATM11/0.1: t-class interface rule traffic scheduler queue qos profile group type type class profile profile--------------- ------- --------- ----- ----------- ------------ -------qp2@ATM11/0.1 atm-vc node default defaultqp2@ATM11/0.1 atm-vp node default defaultqp2@ATM11/0.1 atm-vc queue best-effort default defaultqp2@ATM11/0.1 atm-vc queue tc5 default defaultqp2@ATM11/0.1 atm-vc queue tc6 default defaultqp2@ATM11/0.1 g1 atm group strictShaper defaultqp2@ATM11/0.1 g1 atm-vc node default defaultqp2@ATM11/0.1 g1 atm-vp node default defaultqp2@ATM11/0.1 g1 atm-vc queue tc1 default defaultqp2@ATM11/0.1 g1 atm-vc queue tc2 default defaultqp2@ATM11/0.1 g2 atm-vp node default defaultqp2@ATM11/0.1 g2 atm-vc queue tc3 default defaultqp2@ATM11/0.1 g2 atm-vc queue tc4 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-profiledefault-port-profile Ethernet qos-profile ethernet-defaultdefault-port-profile Atm qos-profile atm-defaultdefault-port-profile HDLC qos-profile serial-defaultdefault-port-profile ServerPort qos-profile server-default

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-profile—Name of QoS profile

! t-class group—Name of the traffic-class group associated with the interface

! interface type—Type of interface

! rule type—Whether the rule is a group node, scheduler node, or queue

! traffic class—Name of the traffic class associated with the interface

! scheduler profile—Name of the scheduler profile associated with the interface

! queue profile—Name of the queue profile associated with the interface

! drop profile—Name of the drop profile associated with the interface

! statistics profile—Name of the statistics profile associated with the interface

! qos-profile referenced by attachment—Number of interfaces to which the QoS profile is attached

! attachment—Type of interface to which the QoS profile is attached

! Example 1

host1#show qos-profile qpDiffServExample1qos-profile qpDiffServExample1: interface rule traffic scheduler queue drop statistics t-class group type type class profile profile profile profile-------------------- --------- ----- ----------- --------------- ------- ------- ---------- ip queue tc3 best-effort default default default ip queue tc4 best-effort default default default ip queue tc5 best-effort default default defaultexpedited-forwarding ethernet group expeditedGroupexpedited-forwarding ip node defaultexpedited-forwarding ip queue voice voice default default defaultbest-effort ethernet group bestEffortGroupbest-effort ip node defaultbest-effort ip queue best-effort best-effort default default defaultassured-forwarding ethernet group assuredGroupassured-forwarding ip node defaultassured-forwarding ip queue video video default default default



202 !

! Example 2

host1#show qos-profile brief qos-profile atm-default referenced by 1 attachmentqos-profile serial-default referenced by 1 attachmentqos-profile ethernet-default referenced by 1 attachmentqos-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.


! queue-profile—Name of the queue profile

! region—Egress buffer memory region

! egress memory—Amount of memory in each region

! exceeded length—Amount of exceeded traffic that can be queued at this egress memory usage

! conformed length—Amount of conformed traffic that can be queued at this egress memory usage

! committed length—Amount of committed traffic that can be queued at this egress memory usage

! total committed memory—Amount 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.

Monitoring QoS


! Example 1

host1#show qos queue-thresholds egress-slot 9 queue-profile video

queue-profile video 2000 queues total egress exceeded conformed committed committedregion memory length length length memory------ ----------- -------- --------- --------- --------- 0 0MB - 4MB 34944 69888 139648 279296000 1 4MB - 8MB 24448 48896 97792 195584000 2 8MB - 12MB 14080 28032 55936 111872000 3 12MB - 16MB 7040 14080 28032 56064000 4 16MB - 20MB 5248 10496 20992 41984000 5 20MB - 24MB 1280 2560 5120 10240000 6 24MB - 28MB 1152 2176 4224 8448000 7 28MB - 32MB 896 1792 3456 6912000

! 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 router’s memory management. Static and dynamic oversubscription determines that when 8,000 queues are configured and 0–4 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 0region 0 (0MB - 4MB) oversubscription 3330% total exceeded conformed committed queue committedqueue-profile length length length count memory------------- -------- --------- --------- ----- ---------default 34944 69888 139648 2000 279296000video 34944 69888 139648 2000 279296000multicast 34944 69888 139648 2000 279296000internet 34944 69888 139648 2000 279296000

! 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.



204 !

! Example 3


! When 24–28 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 0–4, 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 multicastqueue-profile multicast 2000 queues total egress exceeded conformed committed committedregion 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

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


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


! interface—Type of interface

! resource—Traffic resource associated with the logical interface

! shared shaping rate—Configured shared shaping rate in bits per second

! shaping rate—Individual shaping rate of a traffic resource

! other—Actual current shaping rate in bits per second

! Total shared shapers—Total number of shared shapers

! Total constituents—Total number of resource constituents for all shared shapers

! Total shared shaper failovers—Total number of shared shapers that are disabled (in failover mode) due to lack of resources

! Compound shared shapers are [not] supported—Indication of whether compound shared shapers are supported; determined by installed hardware



206 !

! 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 200000atm-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: 0Compound 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.


! queue profile—Name of the queue profile

! committed length—Greater queue length than the length of the conformed or exceeded length

! conformed length—A queue length that is less than the committed length but greater than the exceeded length

! exceeded length—A queue length less than the conformed length which is less than the committed length

! conformed fraction—Percentage of the total queue that can be occupied before conformed packets are dropped

! exceeded fraction—Percentage of the total queue that can be occupied before exceeded packets are dropped

! buffer weight—Weight of the queue

Monitoring QoS


! Example 1

This is the default format.

host1#show queue-profile committed conformed exceeded fraction: queue length: length: length: conformed, buffer profile min, max min, max min, max exceeded weight ------- --------- --------- --------- ---------- ------ default 0, <none> 0, <none> 0, <none> 50, 25 8

! Example 2

host1#show queue-profile briefqueue-profile default referenced 31 times in qos-profiles

! Example 3

host1#show queue-profile referencesqueue-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.


! scheduler—Name of the scheduler profile

! shaping rate—Maximum bandwidth, in bits per second, provided to a node or queue

! burst—Catch-up number associated with the shaper

! weight—HRR weight of a node or queue

! strict priority—Status of strict priority

! assured rate—Desired bandwidth, in bits per second, provided to a node or queue, or the keyword, hierarchical, to indicate that HAR is used

! Referenced by QoS profiles—QoS profiles that reference this scheduler profile



208 !

! Example 1

host1#show scheduler-profile shaping strict scheduler rate burst weight priority assured rate--------- ------- ----- ------ -------- ------------default <none> 32767 8 no <none>wf100 128000 32767 20 no 75000spSV25 5000000 32767 40 no 64000videoHar <none> 32767 8 no hierarchical

! Example 2

host1#show scheduler-profile briefscheduler-profile default referenced 39 times in qos-profilesscheduler-profile wf100 referenced 1 time in qos-profiles

scheduler-profile spSV25 referenced 2 times in qos-profiles

! Example 3

host1#show scheduler-profile referencesscheduler-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.


! statistics profile—Name of the statistics profile

! forwarding rate threshold—Threshold above which forwarded-rate-exceeded events are counted

! committed drop threshold—Threshold above which committed-drop-events are counted

! conformed drop threshold—Threshold above which conformed-drop-events are counted

Monitoring QoS


! exceeded drop threshold—Threshold above which exceeded-drop-events are counted

! rate period—Time frame during which statistics are gathered

! Example

host1#show statistics-profile forwarding committed conformed exceededstatistics rate drop drop drop rate profile threshold threshold threshold threshold period---------- ---------- --------- --------- --------- ------default <none> <none> <none> <none> <none>statpro-1 10000000 2000000 4000000 6000000 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.



! fabric weight—Weight of the queue in the fabric

! fabric strict priority—Setting strict-priority queues in the fabric

! Referenced by QoS profiles—QoS profiles that reference this traffic class

! Referenced by traffic class groups—Traffic-class groups that reference this traffic class

! Example 1

host1>show traffic-class fabric traffic fabric strictclass weight priority----------- ------ --------best-effort 8 nobest-effort 8 notc1 8 notc2 8 notc3 8 notcs4 8 yestcs5 8 yes

! Example 2

host1#show traffic-class brieftraffic-class best-effort referenced 17 times in qos-profiles



210 !

! Example 3host1#show traffic-class referencetraffic-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.


! traffic-class group—Name of the traffic-class group

! traffic-class—Name of the traffic class

! Referenced in qos-profiles—Number of times group is referenced by QoS profiles

! Referenced by QoS profiles—QoS profiles that reference this traffic class

! Examples

host1#show traffic-class-grouptraffic-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 brieftraffic-class-group g2 referenced 1 time in qos-profilestraffic-class-group g3 referenced 1 time in qos-profilestraffic-class-group g4 referenced 0 times in qos-profilestraffic-class-group g1 referenced 0 times in qos-profiles

host1#show traffic-class-group referencestraffic-class-group g2Referenced by QoS profiles:profile1

traffic-class-group g3Referenced by QoS profiles:None

Monitoring QoS

Index
AAscend-Data-Filter (RADIUS attribute 242)........................47
policy format.............................................................47ASIC scheduler..................................................................92assured rate ......................................................................93assured-rate command ...................................................117ATM (Asynchronous Transfer Mode)

cell shaping .............................................................158frame shaping .........................................................158monitoring ..............................................................193shaping....................................................................158status. See monitoring

ATM modules with relative strict priority.........................186minimizing latency on the SAR ...............................187oversubscribing .......................................................187

atm vp-tunnel command ................................................165atm-vp qos-profile command..................................154, 171audience for documentation ...............................................x

Bbackpressure ..................................................................156

required QoS profile ................................................156bandwidth management...................................................56best effort ...................................................................93, 97best-effort queue...............................................................93best-effort scheduler node ................................................93buffer-weight command .................................................104burst size, setting in a shaping rate .................................188

CCDs

JUNOSe software CD ................................................. xiiCDV ..................................................................................93CDVT ........................................................................93, 159cell delay variation. See CDVcell delay variation tolerance. See CDVTclassifier

CAM hardware ....................................................63, 66consumption .............................................................67FPGA hardware ...................................................63, 65hardware.............................................................63, 66line module support ......................................63, 64, 65policy consumption .............................................63, 67software ..............................................................63, 67

classifier control listcreating or modifying ................................................18matching IP flags .......................................................23matching IP fragmentation offset ..............................23matching TCP flags..............................................22, 24multiple elements in ..................................................21

classifier groupscreating .....................................................................36

classifier-group command.................................................39clear egress-queue command..........................................193clear fabric-queue command ..........................................193color command ................................................................40color-based thresholds ....................................................102committed drop threshold ..............................................147committed-action command.............................................12committed-burst command ..............................................12committed-drop-threshold command .............................150committed-length command...........................................104committed-rate command ................................................13committed-threshold command......................................107compound shared shaping. See shared shapingconformed drop threshold ..............................................147conformed-action command.............................................13conformed-drop-threshold command .............................150conformed-fraction command ........................................104conformed-length command...........................................104conformed-threshold command......................................107constituents, shared-shaping...........................................122conventions defined

icons............................................................................xtext and syntax............................................................x

customer support.............................................................xiii

DDiffserv

configuration example.............................................178networks ...................................................................92

documentation set, E-series ...............................................xicomments on ...........................................................xiii

drop profile .....................................................................105dynamic shaping of traffic ..............................................118

Eeffective weight.................................................................93ERX-14xx models ...............................................................xERX-7xx models .................................................................xE-series documentation set ................................................xi

comments on ...........................................................xiiiE-series models...................................................................x

Index ! 211


212 !

exceeded drop threshold ................................................ 147exceeded-action command............................................... 14exceeded-drop-threshold command ............................... 150exceeded-fraction command .......................................... 104exceeded-length command............................................. 104exceeded-threshold command........................................ 107excess-burst command..................................................... 14explicit packet coloring..................................................... 59exp-mask command......................................................... 14

Ffabric-strict-priority command.......................................... 98fabric-weight command.................................................... 98filter command................................................................. 40forward command...................................................... 38, 41forwarding rate threshold ............................................... 147forwarding-rate-threshold command .............................. 151fragmentation offsets, filtering.......................................... 23frame-relay classifier-list command .................................. 18

Ggre-tunnel classifier-list command .................................... 19group command............................................................. 153group node ....................................................................... 93

HHAR.................................................................................. 93hierarchical assured rate. See HARhierarchical round-robin. See HRRhierarchy, QoS scheduler .................................................. 94HRR.......................................................................... 93, 182HRR scheduler................................................................ 155

relative strict priority on.................................. 184, 187

Iicons defined, notice .......................................................... ximplicit constituents

selection for compound shared shaping .................. 125selection for simple shared shaping ........................ 124

installing the system software............................................ ixinterface profile attachments .......................................... 170ip classifier-list command........................................... 19, 24ip commands

ip filter-options all ..................................................... 46IP fragmentation

offset, matching in a policy ....................................... 23IP options, filtering ........................................................... 46ip rate-limit-profile command. See rate-limit-profile

commandsipv6 rate-limit-profile command. See rate-limit-profile

commands

Ll2tp classifier-list command.............................................. 26l2tp rate-limit-profile command. See rate-limit-profile

commandsL2TP sessions

QoS ......................................................................... 167

latency..............................................................................93log command ...................................................................41

Mmanuals, E-series...............................................................xi

comments on ........................................................... xiiimark command................................................................42mark-de command ...........................................................42mark-exp command .........................................................42mark-user-priority command............................................43mask-val command ..........................................................15MIBs (Management Information Bases) ........................... xiiimodels

ERX-14xx ....................................................................xERX-7xx ......................................................................xE-series........................................................................x

monitoringATM interfaces ........................................................193QoS .........................................................................193

MPLSpolicy management and............................................62

mpls classifier-list command ............................................26mpls commands

mpls classifier-list ......................................................63mpls ldp lsp-policy...............................................62, 63

mpls rate-limit-profile command. See rate-limit-profile commands

MTU (maximum transmission unit)IP...............................................................................76

multiple forwarding solutions ...........................................38munged QoS profile........................................................172

attachments ............................................................172

Nnext-hop command ..........................................................43next-interface command...................................................43node

best-effort scheduler..................................................93group.........................................................................93scheduler...................................................................94

node command ......................................................154, 190notice icons defined ...........................................................x

Ppacket coloring, explicit ....................................................59packet mirroring.................................................................3packet tagging ..................................................................59peak-burst command........................................................15peak-rate command..........................................................15policy action .......................................................................2policy commands

frame-relay policy .....................................................45gre-tunnel policy........................................................45ip policy ....................................................................45l2tp policy .................................................................45mpls policy................................................................45vlan policy.................................................................45

Index

Index

policy listapplying to an interface.............................................45constructing a..............................................................3creating or modifying ................................................28description of ..............................................................2Fast Ethernet port on SRP module.............................45

policy managementapplications ...............................................................54

bandwidth management ....................................56packet mirroring ..................................................3packet tagging....................................................59policy routing .....................................................54secure policies......................................................3security ..............................................................55

applying a policy list to an interface ..........................45Fast Ethernet port on SRP module .....................45

bandwidth management ...........................................56baselining statistics..............................................46, 68classifier control lists .................................................18classifier groups, creating ..........................................36classifier resources ....................................................66committed burst calculation ................................13, 15congestion management ...........................................56constructing a policy list ..............................................3creating a classifier control list ..................................18creating a one-rate rate-limit profile ..........................11creating a policy list...................................................28creating a two-rate rate-limit profile ..........................11creating with RADIUS ................................................47explicit packet coloring..............................................59filtering fragmentation offsets ...................................23filtering IP options .....................................................46matching IP flags in a CLACL.....................................23matching IP fragmentation offset in a CLACL ............23matching TCP flags in a CLACL............................22, 24modifying a classifier control list ...............................18modifying a one-rate rate-limit profile .......................11modifying a policy list ...............................................28modifying a two-rate rate-limit profile .......................11monitoring ................................................................69monitoring packet flow .............................................60MPLS and ..................................................................62one-rate rate-limit profile...........................................57overview......................................................................2packet mirroring..........................................................3packet tagging ...........................................................59policy actions and rate-limit profiles............................8policy lists .............................................................2, 28policy routing ........................................................2, 54policy rules, creating .................................................36QoS classification and marking ...................................2RADIUS .....................................................................47rate limiting.................................................................2rate-limit profile actions ..............................................8rate-limit profile attributes...........................................8rate-limit profile calculations .....................................16rate-limit profile defaults .....................................16, 17rate-limit profiles .........................................................5rate-limiting traffic flows ...........................................58rules ............................................................................2

secure policies .............................................................3security......................................................................55statistics ....................................................................46two-rate rate-limit profile...........................................57

policy management commandsgre-tunnel policy........................................................70ip policy.....................................................................70l2tp policy..................................................................70vlan policy .................................................................70

policy rulescreating .....................................................................36supported commands................................................37

policy-list commandsframe-relay policy-list command ...............................36gre-tunnel policy list command .................................36ip policy-list command ..............................................36ipv6 policy-list command...........................................36l2tp policy-list command ...........................................36mpls policy-list command..........................................36vlan policy-list command...........................................36

port shaping....................................................................192port-type profile, QoS........................................................94

attachments.............................................................171profile

drop.........................................................................105QoS .........................................................................151

attachment .........................................................94port-type ............................................................94rules illustrated.........................................181, 182

scheduler .................................................................114statistics ..................................................................147

QQoS

assured rate...............................................................93best effort ..................................................................93best-effort queue .......................................................93best-effort scheduler node .........................................93CDV...........................................................................93CDVT.........................................................................93color-based thresholds.............................................102description of ............................................................92differentiated services

assured forwarding.............................................92expedited forwarding .........................................92

Diffserv configuration example................................178drop profile..............................................................105dynamic traffic shaping ...........................................118effective weight .........................................................93extends Diffserv ........................................................92features .....................................................................94group node ................................................................93HAR...........................................................................93hierarchical round-robin ..........................................182HRR...........................................................................93interface profile

attachments .....................................................170L2TP sessions ..........................................................167latency.......................................................................93

Index ! 213


214 !

monitoring ..............................................................193multiple traffic class configuration example ............ 178multiple traffic-class groups....................................... 99munged profile........................................................ 172nodes

best-effort scheduler .......................................... 93group ................................................................. 93scheduler ........................................................... 94

operational shaping modeoperational QoS shaping mode ........................ 158

overview ................................................................... 92port shaping ............................................................ 192port-type profile ........................................................ 94port-type profile attachments .................................. 171profile

attachment......................................................... 94drop ................................................................. 105QoS.................................................................. 151rules illustrated ........................................ 181, 182scheduler ......................................................... 114statistics ........................................................... 147

queue ........................................................................ 93bandwidth........................................................ 182profile ..............................................................100profile, configuring........................................... 103

rate shaping ...................................................... 94, 191RED........................................................................... 94

and dynamic queue thresholds ........................ 112configuration examples.................................... 108configuring....................................................... 106configuring average queue length .................... 108configuring color blind RED ............................. 108configuring colored RED .................................. 108how it works .................................................... 106

relative strict-priority scheduling ............................. 184RFCs.......................................................................... 96scheduler

assured rate ............................................. 114, 115hierarchy............................................ 94, 114, 183node .................................................................. 94profile ..............................................................114profile, configuring........................................... 116rate shaping ..................................................... 114relative weight ................................................. 114shaping rate ..................................................... 114weight ..............................................................115

shapingATM ................................................................. 158ATM cell shaping.............................................. 158ATM frame shaping.......................................... 158

shared shaping........................................................ 118statistics .................................................................. 193statistics profile ....................................................... 147

committed drop threshold ............................... 147conformed drop threshold ............................... 147event statistics ................................................. 149exceeded drop threshold.................................. 147failover mode................................................... 150forwarding rate threshold................................. 147maximum ........................................................ 147

rate period ...............................................147, 151rate statistics ....................................................148resource use.....................................................150thresholds ........................................................150

strict-priority scheduling..........................................182TCP friendly ............................................................191terms.........................................................................93traffic class ................................................................97

configuring.........................................................97traffic-class group ......................................................99weight .......................................................................94WRED .......................................................................94

configuration examples............................110, 174configuring.......................................................110

QoS profileattaching .................................................................170attaching to interfaces .............................................154configuring ..............................................................152creating ...................................................................153munged...................................................................172

QoS schedulerHRR.........................................................................155

QoS statisticsATM ................................................................159, 167

qos-mode-port command .......................................158, 166qos-port-type-profile command ......................................171qos-profile command..............................153, 155, 171, 191qos-shaping-mode command .................................156, 167queue ...............................................................................93queue bandwidth............................................................182queue buffers..................................................................102queue command.............................................................154queue length...................................................................102queue profile ..................................................................100

configuring ..............................................................103queue-profile command..................................................105

RRADIUS

applying policies........................................................47random early detection. See REDrate shaping....................................................................191

QoS ...........................................................................94rate-limit profiles

attributes .....................................................................8calculations ...............................................................16creating .....................................................................11default values ......................................................16, 17modifying..................................................................11one-rate.....................................................................57policy actions ..............................................................8two-rate.....................................................................57

rate-limitingaggregate traffic flows ...............................................58individual traffic flows ...............................................58

rate-limit-profile commandsrate-limit-profile.........................................................44rate-limit-profile one-rate...........................................16rate-limit-profile two-rate...........................................17

Index

Index

rate-period command .....................................................151RED ..........................................................................94, 105

and dynamic queue thresholds................................112configuration examples ...........................................108configuring ..............................................................106configuring average queue length............................108configuring color blind RED.....................................108configuring colored RED..........................................108how it works............................................................106

relative strict-priority scheduling.....................................184configuration example.............................................186configuring ..............................................................189on ATM modules .....................................................186

minimizing latency on the SAR ........................187oversubscribing................................................187

setting burst size in shaping rate .............................188shaping rate for nonstrict queues ............................188tuning latency on strict-priority queues ...................189zero-weight queues..................................................188

release notes..................................................................... xii

SSAR scheduler.................................................................155

strict-priority on ......................................................185scheduler

assured rate.....................................................114, 115hierarchy ...................................................94, 114, 183HRR.........................................................................155node, best-effort ........................................................93profile......................................................................114

configuring.......................................................116rate shaping ............................................................114relative weight.........................................................114SAR .........................................................................155shaping rate ............................................................114weight .....................................................................115

scheduler-profile command ....................................117, 191secure policies ..............................................................3, 87security.............................................................................55shapeless tunnel .....................................................165, 166shaping rate

for nonstrict queues ................................................188setting burst size in .................................................188

shaping, QoS ATM...........................................................158cell ..........................................................................158frame ......................................................................158

shaping-rate command...........................................117, 191shared shaping

active constituents...................................................122burst rate.................................................................146caveats ....................................................................145compound...............................................................122

active constituents ...........................................123configuration....................................................139configuration example, VC shared shaping ......141configuration example, VP shared shaping.......143configuration limitations ..................................141example, weighted...........................................129hardware dependency......................................145

constituents .............................................................122active ...............................................................122comparison of explicit and implicit ..................131inactive ............................................................123

explicit constituentsexample ...........................................................132example of weighted ........................................133selection...................................................123, 131

implicit constituentsexample at best-effort node..............................125example at best-effort queue............................126example for mixed interface types ...................127ordering for compound ....................................127selection...........................................................123selection for compound....................................125selection for simple ..........................................124

inactive constituents................................................123individual shaping and.............................................139limiting bandwidth ..................................................119low-CDV mode ........................................................121node-controlled .......................................................119on the SAR, limitations of ........................................119oversubscription ......................................................146overview..........................................................118, 119queue-controlled......................................................119simple .....................................................................119

active constituents............................................123configuration ....................................................135configuration example, VC shared shaping.......136configuration example, VP shared shaping.......137example, basic .................................................120example, on best-effort queue..........................120example, on best-effort scheduler node............121

traffic starvation ......................................................146types, simple versus compound...............................119

shared-shaping-constituent command ............................140shared-shaping-rate command................................135, 139show commands

show atm interface..................................................193show classifier-list......................................................70show drop-profile command....................................194show egress-queue events command ......................195show egress-queue rates command.........................196show fabric-queue command ..................................198show frame-relay subinterface...................................73show gre tunnel .........................................................74show interfaces .........................................................75show ip interface .......................................................76show ipv6 interface ...................................................79show mpls interface l2transport ................................82show policy-list ..........................................................84show qos-port-type profile command ......................200show qos-profile command .....................................201show queue-profile command .................................206show rate-limit-profile................................................86show scheduler-profile command............................207show secure policy-list ...............................................87show statistics-profile command .............................208

Index ! 215


216 !

show traffic-class command.................................... 209show traffic-class-group command.......................... 210show vlan subinterfaces ............................................ 89

show qos commandsshow qos interface-hierarchy command.................. 200show qos queue-thresholds command .................... 202show qos shared-shaper .......................................... 205

simple shared shaping. See shared shapingsoftware, installing............................................................. ixstatistics profile............................................................... 147statistics-profile command.............................................. 151strict-priority command.................................................. 118strict-priority scheduling ................................................. 182

true versus relative.................................................. 185support, requesting.......................................................... xiii

TTCP friendly.................................................................... 191technical support, requesting........................................... xiiiterms

QoS ........................................................................... 93text and syntax conventions defined .................................. xtraffic classes.................................................................... 97

configuring................................................................97multiple, configuration example.............................. 178

traffic flow ........................................................................ 93traffic-class command .......................................... 44, 98, 99traffic-class groups

configuring................................................................99multiple..................................................................... 99

traffic-class-group command .......................................... 100true strict priority scheduling.......................................... 185

Uupdating the system software............................................ ixuser-packet-class command.............................................. 44

Vvlan classifier-list command ............................................. 27

Wweight command.................................................... 118, 191weight, QoS...................................................................... 94weighted random early detection. See WREDWRED ......................................................................94, 105

configuration examples ................................... 110, 174configuring..............................................................110

different drop behavior for each queue ............ 111different treatment of colored packets ............. 110

Zzero-weight queues......................................................... 188

Index

Documents

Swconfig Policy Qos