Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - POLICY MANAGEMENT CONFIGURATION GUIDE 2010-10-04, JUNOSE 11.3 Configuration Manual

Download

Page 1

JunosE™ Software for E Series™ Broadband Services Routers

Policy Management Configuration Guide

Release

11.3.x

Published: 2010-10-04

Page 2

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net

Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

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.

Products made or sold by Juniper Networks 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.

JunosE™ Software for E Series™ Broadband Services Routers Policy Management Configuration Guide

Writing: Subash Babu Asokan, Krupa Chandrashekar, Diane Florio, Bruce Gillham, Sarah Lesway-Ball, Brian Wesley Simmons, Namrata Mehta Editing: Benjamin Mann Illustration: Nathaniel Woodward Cover Design: Edmonds Design

Revision History October 2010—FRS JunosE 11.3.x

The information in this document is current as of the date listed in the revision history.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. The Junos OS has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

Page 3

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 THISAGREEMENT. IF YOU DO NOTOR CANNOT AGREE TO THE TERMSCONTAINED 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 (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or Juniper Networks(Cayman)Limited(if the Customer’s principaloffice is locatedoutside the Americas) (such applicable entity beingreferred to herein as“Juniper”), and (ii)the person ororganizationthat originally purchased from Juniperor 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, for which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by Juniper in equipment which Customer purchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades and new releases of such software. “Embedded Software” means Software which Juniper has embedded in or loaded onto the Juniper equipment and any updates, upgrades, additions or replacements which are subsequently embedded in or loaded onto the equipment.

3. License Grant. Subject to payment of the applicablefeesand the limitations andrestrictions set forthherein, Juniper grantsto 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 Embedded Software solely as embedded in, and for execution on, Juniper equipment originally purchased by Customer from Juniper or an authorized Juniper reseller.

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; provided, however, with respect to the Steel-Belted Radius or Odyssey Access Client software only, Customer shall use such Software on a single computer containing a single physical random access memory space and containing any number of processors. Use of the Steel-Belted Radius or IMS AAA software on multiple computers or virtual machines (e.g., Solaris zones) requires multiple licenses, regardless of whether such computers or virtualizations are physically contained on a single chassis.

c. Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may specify limitstoCustomer’suse ofthe Software.Such limitsmay restrict use toa maximum number of seats, registeredendpoints, concurrent users, sessions, calls, connections, subscribers, clusters, nodes, realms, devices, links, ports or transactions, or require the purchase of separate licenses to use particular features, functionalities, services, applications, operations, or capabilities, or provide throughput, performance, configuration, bandwidth, interface, processing, temporal, or geographical limits. In addition, such limits may restrict the use of the Software to managing certain kinds of networks or require the Software to be used only in conjunction with other specific Software. Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable licenses.

d. For any trial copy of the Software, Customer’s right to use the Software expires 30 days after download, installation or use of the Software. Customer may operate the Software after the 30-day trial period only if Customer pays for a license to do so. Customer may not extend or create an additional trial period by re-installing the Software after the 30-day trial period.

e. The Global Enterprise Edition of the Steel-Belted Radius software may be used by Customer only to manage access to Customer’s enterprise network. Specifically, service provider customers are expressly prohibited from using the Global Enterprise Edition of the Steel-Belted Radius software to support any commercial network access services.

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, sell, transfer, or grant any rights in and to any copy of the Software,in anyform, to anythird party; (d)removeany proprietary notices, labels,or marks on or in any copyof the Software or anyproduct in which the Software is embedded; (e) distribute any copy of the Software to any third party, including as may be embedded in Juniper equipment sold in thesecondhandmarket;(f) use any‘locked’ orkey-restricted feature,function, service, application,operation,or capability without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even if such feature, function, service, application, operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to any third party; (h) use the

Page 4

Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper reseller; (i) use Embedded Software on non-Juniper equipment; (j) use Embedded Software (or make it available for use) on Juniper equipment that the Customer did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of testing or benchmarking of the Software to any third party without the prior written consent of Juniper; or (l) 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 commercialefforts to maintain the Software and associated documentation in confidence, which at a minimum includes restrictingaccess to the Software to Customer employees and contractors havinga need to use the Software for Customer’s internal business purposes.

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. The warranty applicable to the Software shall be as set forth in the warranty statementthataccompaniesthe Software (the “Warranty Statement”). Nothing inthis Agreement shallgive rise to anyobligation tosupport the Software. Support services may be purchased separately. Any such support shall be governed by a separate, written support services agreement. TO THE MAXIMUM EXTENT PERMITTED BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, OR COSTS ORPROCUREMENT OFSUBSTITUTE GOODSOR SERVICES,OR FORANYSPECIAL,INDIRECT, ORCONSEQUENTIALDAMAGES ARISING OUTOF THIS AGREEMENT,THE SOFTWARE,OR ANY JUNIPEROR JUNIPER-SUPPLIED SOFTWARE. IN NOEVENT SHALL JUNIPER BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY STATEMENT 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. In no event shall Juniper’s or its suppliers’ or licensors’ liability to Customer, whether in contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid by Customer for the Software that gave rise to the claim, or if the Software is embedded in another Juniper product, the price paid by Customer for such other product. Customer acknowledges and agrees that Juniper has set its prices and entered into this Agreement in reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an allocation of risk between the Parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss), and that the same form an essential basis of the bargain between the Parties.

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 payable under this agreement are exclusive of tax. Customer shall be responsible for paying Taxes arising from the purchase of the license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction shall be provided to Juniper prior to invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All payments made by Customer shall be net of any applicable withholding tax. Customer will provide reasonable assistance to Juniper in connection with such withholding taxes by promptly: providing Juniper with valid tax receipts and other required documentation showing Customer’s payment of any withholding taxes; completing appropriate applications that would reduce the amount of withholding tax to be paid; and notifying and assisting Juniper in any audit or tax proceeding related to transactions hereunder. Customer shall comply with all applicable tax laws and regulations, and Customer will promptly pay or reimburse Juniper for all costs and damages related to any liability incurred by Juniper as a result of Customer’s non-compliance or delay with its responsibilities herein. Customer’s obligations under this Section shall survive termination or expiration of this Agreement.

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 Customer may contain encryption or other capabilities restricting Customer’s ability to export the Software without an export license.

Page 5

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. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer with the interface information needed to achieve interoperability between the Software and another independently created program, on payment of applicable fee, if any. Customer shall observe strict obligations of confidentiality with respect to such information and shall use such information in compliance with any applicable terms and conditions upon which Juniper makes such information available.

14. Third Party Software. Any licensor of Juniper whose software is embeddedin the Software and any supplier of Juniper whose products or technology are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement, and such licensor or vendor shallhave theright to enforce this Agreement in its own nameas if it were Juniper. In addition, certain third party software may be provided with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent portions of the Software are distributed under and subject to open source licenses obligating Juniper to make the source code for such portions publicly available (such as the GNU General Public License (“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper will make such source code portions (including Juniper modifications, as appropriate) available upon request for a period of up to three years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA 94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL

at http://www.gnu.org/licenses/lgpl.html .

15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. The provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. 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. This Agreement and associated documentation has been written in the English language, and the Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de même que tous les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that this Agreement and all related documentation is and will be in the English language)).

Page 6

Page 7

Abbreviated Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Part 1 Policy Management

Chapter 1 Managing Policies on the E Series Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 Creating Classifier Control Lists for Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 3 Creating Policy Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 4 Creating Classifier Groups and Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 5 Creating Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Chapter 6 Merging Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Chapter 7 Creating Hierarchical Policies for Interface Groups . . . . . . . . . . . . . . . . . . . . 123

Chapter 8 Policy Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Chapter 9 Monitoring Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Part 2 Packet Mirroring

Chapter 10 Packet Mirroring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Chapter 11 Configuring CLI-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Chapter 12 Configuring RADIUS-Based Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Chapter 13 Managing Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Chapter 14 Monitoring Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Part 3 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Page 8

JunosE 11.3.x Policy Management Configuration Guide

Page 9

Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

E Series and JunosE Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . xxi

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

E Series and JunosE Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . xxi

Obtaining Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Part 1 Policy Management

Chapter 1 Managing Policies on the E Series Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Policy Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Description of a Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Policy Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Policy References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Policy Management Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2 Creating Classifier Control Lists for Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Classifier Control Lists Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Creating or Modifying Classifier Control Lists for ATM Policy Lists . . . . . . . . . . . . . . 9

Creating or Modifying Classifier Control Lists for Frame-Relay Policy Lists . . . . . . . 9

Creating or Modifying Classifier Control Lists for GRE Tunnel Policy Lists . . . . . . . 10

Creating or Modifying Classifier Control Lists for IP Policy Lists . . . . . . . . . . . . . . . 10

Creating Classifier Control List for Only IP Policy Lists . . . . . . . . . . . . . . . . . . . 10

Setting Up an IP Classifier Control List to Accept Traffic from All

Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Classifying IP Traffic Based on Source and Destination Addresses . . . . . . . . . 11

Using IP Classifier Control Lists to Match Route Class Values . . . . . . . . . . . . . 11

Creating IP Classifier Control Lists for TCP and UDP Ports . . . . . . . . . . . . . . . . 11

Creating an IP Classifier Control List That Matches the ToS Byte . . . . . . . . . . 12

Creating an IP Classifier Control List That Filters ICMP Echo Requests . . . . . . 12

Creating IP Classifier Control Lists That Use TCP or IP Flags . . . . . . . . . . . . . . 12

Creating IP Classifier Control Lists That Match the IP Fragmentation

Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Creating or Modifying Classifier Control Lists for IPv6 Policy Lists . . . . . . . . . . . . . 12

Creating or Modifying Classifier Control Lists for L2TP Policy Lists . . . . . . . . . . . . 13

Creating or Modifying Classifier Control Lists for MPLS Policy Lists . . . . . . . . . . . . 13

Creating or Modifying Classifier Control Lists for VLAN Policy Lists . . . . . . . . . . . . 13

Page 10

JunosE 11.3.x Policy Management Configuration Guide

Chapter 3 Creating Policy Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Policy Lists Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Creating Policy Lists for ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Creating Policy Lists for Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Creating Policy Lists for GRE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Creating Policy Lists for IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Creating Policy Lists for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Creating Policy Lists for L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Creating Policy Lists for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Creating Policy Lists for VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 4 Creating Classifier Groups and Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Classifier Groups and Policy Rules Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Policy Rule Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Using Policy Rules to Provide Routing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Configuring Policies to Provide Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Creating an Exception Rule within a Policy Classifier Group . . . . . . . . . . . . . . . . . . 32

Defining Policy Rules for Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Assigning Values to the ATM CLP Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Enabling ATM Cell Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Enabling IP Options Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Packet Tagging Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Creating Multiple Forwarding Solutions with IP Policy Lists . . . . . . . . . . . . . . . . . . 36

Creating a Classifier Group for a Policy List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Applying Policy Lists to Interfaces and Profiles Overview . . . . . . . . . . . . . . . . . . . 39

Using RADIUS to Create and Apply Policies Overview . . . . . . . . . . . . . . . . . . . . . . 42

Construction of IPv6 Classifiers from the Hexadecimal Ascend-Data-Filter

Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Ascend-Data-Filter Attribute for IPv4/IPv6 Subscribers in a Dual Stack . . . . 45

Examples: Using the Ascend-Data-Filter Attribute for IPv4 Subscribers . . . . . . . . 47

Examples: Using the Ascend-Data-Filter Attribute for IPv6 Subscribers . . . . . . . . 52

Chapter 5 Creating Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Rate Limits for Interfaces Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Hierarchical Rate Limits Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Hierarchical Classifier Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Hierarchical Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Hierarchical Rate-Limit Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Example: Multiple Flows Sharing Preferred Bandwidth Rate-Limiting

Hierarchical Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Example: Multiple Flows Sharing a Rate Limit Hierarchical Policy . . . . . . . . . 64

Example: Shared Pool of Additional Bandwidth with Select Flows

Rate-Limiting Hierarchical Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Example: Aggregate Marking with Oversubscription Rate-Limiting

Hierarchical Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Color-Aware Configuration for Rate-Limiting Hierarchical Policy . . . . . . . . . 68

Percent-Based Rates for Rate-Limit Profiles Overview . . . . . . . . . . . . . . . . . . . . . 69

Policy Parameter Reference-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Specifying Rates Within Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Page 11

Table of Contents

Specifying Burst Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Using Service Manager with Merged Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Policy Parameter Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . . . 71

Policy Parameter Quick Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Creating Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

One-Rate Rate-Limit Profiles Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Creating a One-Rate Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Configuring a TCP-Friendly One-Rate Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . 79

Two-Rate Rate-Limits Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Creating a Two-Rate Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Setting the Committed Action for a Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . 85

Setting the Committed Burst for a Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . 85

Setting the Committed Rate for a Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . . 86

Setting the Conformed Action for a Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . 86

Setting the Exceeded Action for a Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . . 87

Setting the Excess Burst for a Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Setting the Mask Value for MPLS Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . 88

Setting the Mask Value for IP and IPv6 Rate-Limit Profiles . . . . . . . . . . . . . . . . . . 88

Setting the Peak Burst for Two-Rate Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . 88

Setting the Peak Rate for Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Setting a One-Rate Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Setting a Two-Rate Rate-Limit-Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Bandwidth Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Examples: One-Rate Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Examples: Two-Rate Rate-Limit Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Examples: Rate-Limiting Individual or Aggregate Packet Flows . . . . . . . . . . . 94

Rate-Limiting Traffic Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Chapter 6 Merging Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Merging Policies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Resolving Policy Merge Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Merged Policy Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Reference Counting for Merged Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Persistent Configuration Differences for Merged Policies Through Service

Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Policy Attachment Sequence at Login Through Service Manager . . . . . . . . . . . . 102

Policy Attachment Rules for Merged Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Error Conditions for Merged Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Merging Policies Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Parent Group Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Overlapping Classification for IP Input Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Starting Policy Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Processing the Classifier Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Processing the Auxiliary-Input Policy Attachment . . . . . . . . . . . . . . . . . . . . . 120

Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Chapter 7 Creating Hierarchical Policies for Interface Groups . . . . . . . . . . . . . . . . . . . . 123

Hierarchical Policies for Interface Groups Overview . . . . . . . . . . . . . . . . . . . . . . . 123

External Parent Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Example: Configuring Hierarchical Policy Parameters . . . . . . . . . . . . . . . . . . . . . 124

Page 12

JunosE 11.3.x Policy Management Configuration Guide

Hierarchical Aggregation Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

RADIUS and Profile Configuration for Hierarchical Policies . . . . . . . . . . . . . . . . . . 127

Applying a Profile to Interfaces with Service Manager . . . . . . . . . . . . . . . . . . . . . . 127

Hierarchical Policy Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 127

Example: Hierarchical Policy Quick Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 128

Example: Configuring Hierarchical Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Example: VLAN Rate Limit Hierarchical Policy for Interface Groups

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Example: Wholesale L2TP Model Hierarchical Policy Configuration . . . . . . . . . . 135

Example: Aggregate Rate Limit for All Nonvoice Traffic Hierarchical Policy

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Example: Arbitrary Interface Groups Hierarchical Policy Configuration . . . . . . . . 140

Example: Service and User Rate-Limit Hierarchy Overlap Hierarchical Policy

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Example: Percentage-Based Hierarchical Rate-Limit Profile for External Parent

Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Example: PPP Interfaces Hierarchical Policy Configuration . . . . . . . . . . . . . . . . . 147

Chapter 8 Policy Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Policy Resources Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

FPGA Hardware Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

CAM Hardware Classifiers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Size Limit for IP and IPv6 CAM Hardware Classifiers . . . . . . . . . . . . . . . . . . . . . . 155

IP Classifiers and Size Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

IPv6 Classifiers and Size Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Creating and Attaching a Policy with IP Classifiers . . . . . . . . . . . . . . . . . . . . . . . . 160

Variable-Sized CAM Classification for IPv6 Policies Examples . . . . . . . . . . . . . . . 162

144-bit IPv6 Classification Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

288-bit IPv6 Classification Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

576-bit IPv6 Classification Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Performance Impact and Scalability Considerations . . . . . . . . . . . . . . . . . . . . . . 166

Performance Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Scalability Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

CAM Device Block Size and CAM Entry Allocation . . . . . . . . . . . . . . . . . 167

Number of CAM Entries Per Allocation and Free Entries . . . . . . . . . . . . 167

Software Classifiers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Interface Attachment Resources Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

CAM Hardware Classifiers and Interface Attachment Resources . . . . . . . . . . . . . 171

Range Vector Hardware Classifiers and Interface Attachment Resources . . . . . . 171

Chapter 9 Monitoring Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Monitoring Policy Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Setting a Statistics Baseline for Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Monitoring the Policy Configuration of ATM Subinterfaces . . . . . . . . . . . . . . . . . . 175

Monitoring Classifier Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Monitoring Color-Mark Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Monitoring Control Plane Policer Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Monitoring the Policy Configuration of Frame Relay Subinterfaces . . . . . . . . . . . 180

Monitoring GRE Tunnel Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Monitoring Interfaces and Policy Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Page 13

Table of Contents

Monitoring the Policy Configuration of IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . 185

Monitoring the Policy Configuration of IPv6 Interfaces . . . . . . . . . . . . . . . . . . . . . 189

Monitoring the Policy Configuration of Layer 2 Services over MPLS . . . . . . . . . . . 193

Monitoring External Parent Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Monitoring Policy Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Monitoring Policy List Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Monitoring Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Monitoring the Policy Configuration of VLAN Subinterfaces . . . . . . . . . . . . . . . . 205

Packet Flow Monitoring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Part 2 Packet Mirroring

Chapter 10 Packet Mirroring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Packet Mirroring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Comparing CLI-Based Mirroring and RADIUS-Based Mirroring . . . . . . . . . . . . . . 214

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Packet-Mirroring Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Packet Mirroring Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Packet Mirroring References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Chapter 11 Configuring CLI-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

CLI-Based Packet Mirroring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Enabling and Securing CLI-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . 220

Reloading a CLI-Based Packet-Mirroring Configuration . . . . . . . . . . . . . . . . . . . . 222

Using TACACS+ and Vty Access Lists to Secure Packet Mirroring . . . . . . . . . . . . 222

Using Vty Access Lists to Secure Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . 222

CLI-Based Packet Mirroring Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . 223

Configuring CLI-Based Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Configuring Triggers for CLI-Based Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Configuring the Analyzer Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Configuring the E Series Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Example: Configuring CLI-Based Interface-Specific Mirroring . . . . . . . . . . . . . . . 228

Example: Configuring CLI-Based User-Specific Mirroring . . . . . . . . . . . . . . . . . . 229

Chapter 12 Configuring RADIUS-Based Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

RADIUS-Based Mirroring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

RADIUS Attributes Used for Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

RADIUS-Based Packet Mirroring Dynamically Created Secure Policies . . . . . . . . 235

RADIUS-Based Packet Mirroring MLPPP Sessions . . . . . . . . . . . . . . . . . . . . . . . . 235

RADIUS-Based Mirroring Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Configuring Router to Start Mirroring When User Logs On . . . . . . . . . . . . . . . . . . 237

Configuring Router to Mirror Users Already Logged In . . . . . . . . . . . . . . . . . . . . . 238

Page 14

JunosE 11.3.x Policy Management Configuration Guide

Chapter 13 Managing Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Avoiding Conflicts Between Multiple Packet Mirroring Configurations . . . . . . . . . 241

Understanding the Prepended Header During a Packet Mirroring Session . . . . . 243

Format of the Mirror Header Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

8-Byte Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

4-Byte Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Resolving and Tracking the Analyzer Device’s Address . . . . . . . . . . . . . . . . . . . . 246

Using Multiple Triggers for CLI-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . 247

Optimizing Packet Mirroring Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Determine Traffic Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Establish Resource Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Logging Packet Mirroring Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Using SNMP Secure Packet Mirroring Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Additional Packet-Mirroring Traps for CALEA Compliance . . . . . . . . . . . . . . 251

Packet Mirroring Trap Severity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Configuring SNMP Secure Packet Mirroring Traps . . . . . . . . . . . . . . . . . . . . . . . . 253

Capturing SNMP Secure Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Chapter 14 Monitoring Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Monitoring Packet Mirroring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Monitoring CLI-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Monitoring the Packet Mirroring Configuration of IP Interfaces . . . . . . . . . . . . . . 259

Monitoring Failure Messages for Secure Policies . . . . . . . . . . . . . . . . . . . . . . . . . 260

Monitoring Packet Mirroring Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Monitoring Packet Mirroring Subscriber Information . . . . . . . . . . . . . . . . . . . . . . 262

Monitoring RADIUS Dynamic-Request Server Information . . . . . . . . . . . . . . . . . 263

Monitoring Secure CLACL Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Monitoring Secure Policy Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Monitoring Information for Secure Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Monitoring SNMP Secure Packet Mirroring Traps . . . . . . . . . . . . . . . . . . . . . . . . . 269

Monitoring SNMP Secure Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Part 3 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Page 15

List of Figures

Part 1 Policy Management

Chapter 3 Creating Policy Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 1: Constructing an IP Policy List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 5 Creating Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Figure 2: Multiple Flows Sharing Preferred Bandwidth . . . . . . . . . . . . . . . . . . . . . . 63

Figure 3: Multiple Packet Flows Sharing a Rate Limit . . . . . . . . . . . . . . . . . . . . . . . 64

Figure 4: Shared Pool of Additional Bandwidth with Select Flows . . . . . . . . . . . . 65

Figure 5: Aggregate Marking with Oversubscription . . . . . . . . . . . . . . . . . . . . . . . . 67

Figure 6: Congestion Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Chapter 6 Merging Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Figure 7: Input Policy with Primary Stage and Auxiliary Substage . . . . . . . . . . . . . 119

Chapter 7 Creating Hierarchical Policies for Interface Groups . . . . . . . . . . . . . . . . . . . . 123

Figure 8: Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Figure 9: VLAN Rate-Limit Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Figure 10: Interface Stack for Wholesale L2TP Mode . . . . . . . . . . . . . . . . . . . . . . 135

Figure 11: Wholesale L2TP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Figure 12: Interface Stack for Aggregate Rate Limit . . . . . . . . . . . . . . . . . . . . . . . . 138

Figure 13: Aggregate Rate Limit for Nonvoice Traffic Configuration . . . . . . . . . . . 139

Figure 14: Interface Stack for Arbitrary Interface Groups . . . . . . . . . . . . . . . . . . . . 141

Figure 15: Arbitrary Interface Groups Configuration . . . . . . . . . . . . . . . . . . . . . . . . 141

Figure 16: Interface Stack for Service and User Rate-Limit Hierarchy Overlap . . . 143

Figure 17: Service and User Rate-Limit Hierarchy Overlap Configuration . . . . . . . 144

Figure 18: Interface Stack for Hierarchical Policy Configuration . . . . . . . . . . . . . . 148

Part 2 Packet Mirroring

Chapter 11 Configuring CLI-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Figure 19: CLI-Based Interface Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Figure 20: CLI-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Chapter 12 Configuring RADIUS-Based Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Figure 21: RADIUS-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Chapter 13 Managing Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Figure 22: Prepended Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Figure 23: 8-Byte Format of VSA 26-59 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Figure 24: 4-Byte Format of VSA 26-59 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Page 16

JunosE 11.3.x Policy Management Configuration Guide

Page 17

List of Tables

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

Part 1 Policy Management

Chapter 2 Creating Classifier Control Lists for Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Table 3: CLACL Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 4 Creating Classifier Groups and Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Table 4: Policy Rule Commands and Precedence . . . . . . . . . . . . . . . . . . . . . . . . . 29

Table 5: Ascend-Data-Filter Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Table 6: Ascend-Data-Filter Attribute for an Input Policy on an IPv4

Table 7: Ascend-Data-Filter Attribute Values for a RADIUS Record . . . . . . . . . . . . 51

Table 8: Ascend-Data-Filter Attribute for an Output Policy on an IPv6

Table 9: Ascend-Data-Filter Attribute for an Input Policy on an IPv6

Chapter 5 Creating Rate-Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 10: TCP-Friendly One-Rate Rate-Limit Profile Algorithms . . . . . . . . . . . . . . 81

Table 11: Policy Action Applied Based on Rate Settings and Traffic Rate . . . . . . . 83

Table 12: Two-Rate Rate-Limit Profile Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 83

Table 13: One-Rate Rate-Limit-Profile Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table 14: Two-Rate Rate-Limit-Profile Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Chapter 6 Merging Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Table 15: Input Action and Secondary Input Actions . . . . . . . . . . . . . . . . . . . . . . . 121

Chapter 7 Creating Hierarchical Policies for Interface Groups . . . . . . . . . . . . . . . . . . . . 123

Table 16: Shorthand Notation Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Chapter 8 Policy Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Table 17: Classifier Support (OC48/STM16, GE-2, and GE-HDE Line

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

Table 19: Size Limit of Individual IP Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Table 20: Size Limit of Combined IP Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Table 21: Size Limit of Individual IPv6 Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Table 22: Size Limit of Combined IPv6 Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . 159

Table 23: Classification Fields for Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Modules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

GE-HDE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Page 18

JunosE 11.3.x Policy Management Configuration Guide

Table 24: Classification Fields for Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Table 25: IPv6 Classification Fields for a 144-bit CAM Entry . . . . . . . . . . . . . . . . . 164

Table 26: IPv6 Classification Fields for a 288-bit CAM Entry . . . . . . . . . . . . . . . . 164

Table 27: IPv6 Classification Fields for a 576-bit CAM Entry . . . . . . . . . . . . . . . . . 165

Table 28: Maximum Policies with One Classifier per Policy for GE-2 LMs . . . . . . 168

Table 29: Maximum Policies with Four Classifiers per Policy for GE-2 LMs . . . . . 169

Table 30: Resource Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Chapter 9 Monitoring Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Table 31: show atm subinterface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Table 32: show classifier-list Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Table 33: show color-mark-profile Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 179

Table 34: show control-plane policer Output Fields . . . . . . . . . . . . . . . . . . . . . . . 180

Table 35: show frame-relay subinterface Output Fields . . . . . . . . . . . . . . . . . . . . 181

Table 36: show gre tunnel Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Table 37: show interfaces Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Table 38: show ip interfaces Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Table 39: show ipv6 interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Table 40: show mpls l2transport interface Output Fields . . . . . . . . . . . . . . . . . . 194

Table 41: show parent-group Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Table 42: show policy-list Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Table 43: show policy-parameter Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 203

Table 44: show rate-limit-profile Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Table 45: show vlan subinterface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 205

Part 2 Packet Mirroring

Chapter 10 Packet Mirroring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Table 46: Packet-Mirroring Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Chapter 11 Configuring CLI-Based Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Table 47: Commands Made Visible by the mirror-enable Command . . . . . . . . . . 221

Table 48: Setting Up the CLI-Based Packet-Mirroring Environment . . . . . . . . . . 223

Table 49: CLI-Based User-Specific Mirroring During Session Start . . . . . . . . . . . 224

Table 50: CLI-Based Mirroring of Currently Running Session . . . . . . . . . . . . . . . . 224

Chapter 12 Configuring RADIUS-Based Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Table 51: RADIUS Attributes Used as Packet Mirroring Triggers (Vendor ID

4874) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Table 52: RADIUS Attributes Used as Packet Mirroring Triggers (Vendor ID

3561) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Table 53: RADIUS-Based Mirroring Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Table 54: Setting Up the RADIUS-Based Packet-Mirroring Environment . . . . . . 236

Table 55: RADIUS-Based Mirroring During Session Start (User-Initiated) . . . . . . 237

Table 56: RADIUS-Based Mirroring of Currently Running Session

(RADIUS-Initiated) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Chapter 13 Managing Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Table 57: Prepended Header Field Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Table 58: Packet-Mirroring SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Table 59: Packet-Mirroring Traps for CALEA Compliance . . . . . . . . . . . . . . . . . . 252

Page 19

List of Tables

Table 60: Packet Mirroring Trap Severity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Chapter 14 Monitoring Packet Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Table 61: show ip interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Table 62: show ip mirror interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 260

Table 63: show mirror log Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Table 64: show mirror rules Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Table 65: show mirror subscribers Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 262

Table 66: show radius dynamic-request statistics Output Fields . . . . . . . . . . . . 263

Table 67: show secure classifier-list Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 265

Table 68: show secure policy-list Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 268

Table 69: show mirror log Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Table 70: show snmp trap Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Table 71: show snmp secure-log Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Page 20

JunosE 11.3.x Policy Management Configuration Guide

Page 21

About the Documentation

•

E Series and JunosE Documentation and Release Notes on page xxi

•

Audience on page xxi

•

E Series and JunosE Text and Syntax Conventions on page xxi

•

Obtaining Documentation on page xxiii

•

Documentation Feedback on page xxiii

•

Requesting Technical Support on page xxiii

E Series and JunosE Documentation and Release Notes

For a list of related JunosE documentation, see

http://www.juniper.net/techpubs/software/index.html .

If the information in the latest release notes differs from the information in the documentation, follow the JunosE Release Notes.

To obtain the most current version of all Juniper Networks®technical documentation, see the product documentation page on the Juniper Networks website at

http://www.juniper.net/techpubs/.

Audience

This guide is intended for experienced system and network specialists working with Juniper Networks E SeriesBroadband Services Routers in an Internet access environment.

E Series and JunosE Text and Syntax Conventions

Table 1 on page xxii defines notice icons used in this documentation.

Page 22

JunosE 11.3.x Policy Management Configuration Guide

Table 1: Notice Icons

Table 2 on page xxii defines text and syntax conventions that we use throughout the E Series and JunosE documentation.

DescriptionMeaningIcon

Indicates important features or instructions.Informational note

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

Alerts you to the risk of personal injury or death.Warning

Alerts you to the risk of personal injury from a laser.Laser warning

Table 2: Text and Syntax Conventions

Representscommandsand keywordsin text.Bold text like this

Fixed-width text like this

Italic text like this

Plus sign (+) linking key names

Syntax Conventions in the Command Reference Guide

Representsinformationas displayedon your terminal’s screen.

•

Emphasizes words.

•

Identifies variables.

•

Identifies chapter, appendix, and book names.

keys simultaneously.

ExamplesDescriptionConvention

•

Issue the clock source command.

•

Specify the keyword exp-msg.

host1(config)#traffic class low-loss1Represents text that the user must type.Bold text like this

host1#show ip ospf 2

Routing Process OSPF 2 with Router ID 5.5.0.250

Router is an Area Border Router (ABR)

•

There are two levels of access: user and privileged.

•

clusterId, ipAddress.

•

Appendix A, System Specifications

Press Ctrl + b.Indicates that you must press two or more

terminal lengthRepresents keywords.Plain text like this

mask, accessListNameRepresents variables.Italic text like this

Page 23

Table 2: Text and Syntax Conventions (continued)

About the Documentation

ExamplesDescriptionConvention

| (pipe symbol)

or variable to the left or to the right of this symbol. (The keyword or variable can be either optional or required.)

[ ]* (brackets and asterisk)

that can be entered more than once.

Represent required keywords or variables.{ } (braces)

Obtaining Documentation

To obtain the most current version of all Juniper Networks technical documentation, see the Technical Documentation page on the Juniper Networks Web site at

http://www.juniper.net/.

To download complete sets of technical documentation to create your own documentation CD-ROMs or DVD-ROMs, see the Portable Libraries page at

http://www.juniper.net/techpubs/resources/index.html

diagnostic | lineRepresents a choice to select one keyword

[ internal | external ]Represent optional keywords or variables.[ ] (brackets)

[ level1 | level2 | l1 ]*Represent optional keywords or variables

{ permit | deny } { in | out }

{ clusterId | ipAddress }

Copies of the Management Information Bases (MIBs) for a particular software release are available for download in the software image bundle from the Juniper Networks Web site athttp://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. Send your comments to

techpubs-comments@juniper.net, or fill out the documentation feedback form at

https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include

the following information with your comments:

•

Document or topic name

•

URL or page number

•

Software release version

Requesting Technical Support

Technical productsupport isavailable through theJuniper NetworksTechnical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

Page 24

JunosE 11.3.x Policy Management Configuration Guide

or are covered under warranty, and need post-sales technical support, you can access our tools and resources online or open a case with JTAC.

•

JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTAC User Guide located at

http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf .

•

Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/ .

•

JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week, 365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called the Customer Support Center (CSC) that provides you with the following features:

•

Find CSC offerings: http://www.juniper.net/customers/support/

•

Search for known bugs: http://www2.juniper.net/kb/

•

Find product documentation: http://www.juniper.net/techpubs/

•

Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/

•

Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/

•

Search technical bulletins for relevant hardware and software notifications:

https://www.juniper.net/alerts/

•

Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/

•

Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/

To verifyservice entitlement by product serialnumber, use our Serial Number Entitlement (SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

•

Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .

•

Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, see

http://www.juniper.net/support/requesting-support.html .

Page 25

PART 1

Policy Management

•

Managing Policies on the E Series Router on page 3

•

Creating Classifier Control Lists for Policies on page 7

•

Creating Policy Lists on page 15

•

Creating Classifier Groups and Policy Rules on page 27

•

Creating Rate-Limit Profiles on page 57

•

Merging Policies on page 97

•

Creating Hierarchical Policies for Interface Groups on page 123

•

Policy Resources on page 151

•

Monitoring Policy Management on page 173

Page 26

JunosE 11.3.x Policy Management Configuration Guide

Page 27

CHAPTER 1

Managing Policies on the E Series Router

This chapter discusses the following topics:

•

Policy Management Overview on page 3

•

Description of a Policy on page 5

•

Policy Platform Considerations on page 5

•

Policy References on page 6

•

Policy Management Configuration Tasks on page 6

Policy Management Overview

This chapter introduces policy-based routing management on E Series routers. Policy management enables you to configure, manage, and monitor policies that selectively cause packets to take different pathswithout requiring a routingtablelookup.The JunosE Software’s packet-mirroring feature uses secure policies.

Policy management enables network service providers to configure services that customize the treatment of individual packet flows received on a subscriber’s interface. The main tool for implementing policy management is a policy list. A policy list is a set of rules, each of which specifies a policy action. A rule is a policy action optionally combined with a classification.

Packets are sorted at ingress or egress into packet flows based on attributes defined in classifier control lists (CLACLs). You can apply policy lists to packets arriving and leaving an interface. You can use policy management on ATM, Frame Relay, generic routing encapsulation (GRE), IP, IPv6, Layer 2 Tunneling Protocol (L2TP), Multiprotocol Label Switching (MPLS), and virtual local area network (VLAN) traffic.

Policy management provides:

•

Policy routing—Predefines a classified packet flow to a destination port or IP address. The router doesnot perform arouting table lookup onthe packet. This provides superior performance for real-time applications.

•

Bandwidth management—Rate-limits a classified packet flow at ingress to enforce ingress data rates below thephysical line rateof a port, A rate-limit profile with a policy rate-limit profile rule provides this capability. You can construct policies to provide rate limiting for individual packet flowsor for the aggregate of multiple packetflows. Juniper

Page 28

JunosE 11.3.x Policy Management Configuration Guide

Networks E Series Broadband Services Router 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. 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. You can configure rate-limit profiles to provide a variety of services, including tiered bandwidth service where traffic conforming to configured bandwidth levels is treated differently than traffic that exceeds the configured values, and a hard-limit service where a fixed bandwidth limit is applied to a traffic flow. Finally, you can configure rate-limit profiles to provide a TCP-friendly rate-limiting service that works in conjunction with TCP’s native flow-control functionality.

•

Security—Provides a level of network security by using policy rules that selectively forwardor filter packet flows. Youcan use a filter rule to stop adenial-of-service attack. You can use secure policies to mirror packets and send them to an analyzer.

•

RADIUS policy support—Enables you to create and attach a policy to an interface through RADIUS.

•

Packet tagging—Enables the traffic-class rule in policies to tag a packet flow so that the Quality of Service (QoS) application can providetraffic-class queuing. Policies can perform both in-band and out-of-band packet tagging.

•

Packet forwarding—Allows forwarding of packets in a packet flow.

•

Packet filtering—Drops packets in a packet flow.

•

Packetmirroring—Uses secure policiesto mirror packets and send them to an analyzer.

•

Packet logging—Logs packets in a packet flow.

Policy management gives you the CLI tools to build databases, which can then be drawn from to implement a policy. Each database contains global traffic specifications. When building a policy, you specify input from one or more of these databases and then attach the policy to an interface. By combining the information from the various databases into policies, you can deploy a wide variety of services.

NOTE: When applying policies to interfaces that are managed by the SRC,

avoid using any other policy management tools, such as CLI, RADIUS, CoA, or Service Manager. SRC is not compatible with other types of policy management tools. When policies are applied to the interface before SRC management begins, such as at access-accept time, these policies are properly replaced.However,if other policy managers change existing policies while SRC management is active, problems can occur. The precedence of each source when modifying configurations is:

•

If you have a pre-configured policy through CLI as part of subscriber PVC/VLANprovisioning,SRC overwritesthe policy when the SRC manages the interface

•

If you have a policy in the Access-Accept, SRC overwrites the policy when the SRC manages the interface

Page 29

Description of a Policy

A policy is a condition and an action that is attached to an interface. The condition and action cause the router to handle the packets passing through the interface in a certain way. A policycan beattachedto IP interfaces and certainlayer2 interfacessuch as Frame Relay, L2TP, MPLS,and VLAN interfaces. The policies do not need to be the same in both directions.

Packets are sorted at ingress or egress into packet flows based on attributes defined in classifier control lists. Policy lists contain rules that associate actions with these CLACLs. A rule is a policy action optionally combined with a classification.

When packets arrive on an interface, you can have a policy evaluate a condition before the normal route lookup; this kind of policy is known as an input policy. You can also have conditions evaluated after a route lookup; this kind of policy is known as a secondary input policy. You can use secondary input policies to defeat denial-of-service attacks directed at a router’s local interface or to protect a router from being overwhelmed by legitimate local traffic. If you have a policy applied to packets before they leave an interface, this is known as an output policy.

Chapter 1: Managing Policies on the E Series Router

Classification is the process of taking a single data stream in and sorting it into multiple output substreams. The classifier engine on an E Series router is a combination of PowerPC processors, working with a Field ProgrammableGate Array (FPGA) for a hardware assist.

In the Differentiated Services (DiffServ) architecture, two basic types of classifiers exist. The first classifier type is a multifield (MF) classifier, which examines multiple fields in the IP datagram header to determine the service class to which a packet belongs. The second type of classifier is a behavior aggregate (BA) classifier, which examines a single field in an IP datagram header and assigns the packet to a service class based on what it finds.

There are two categories of hardware classifiers, depending on the type of line module being used. ES2 4G LM, ES210G Uplink LM, ES210G LM, OC48/STM16,GE-2, and GE-HDE line modules support content-addressable memory (CAM) hardware classifiers—all other line modules support FPGA hardware classifiers.

The maximum number of policies that you can attach to interfaces on an E Series router depends on the classifier entries that make up the policy and the number of attachment resources available on the interface. JunosE Software allocates interface attachment resources when you attach policies to interfaces. E Series routers support software and hardware classifiers. A policy can be made up of any combination of software and hardware classifiers.

Policy Platform Considerations

Policy services are supported on all E Series routers.

For information about the modules supported on E Series routers:

Page 30

JunosE 11.3.x Policy Management Configuration Guide

•

See the ERXModuleGuide for modulessupportedon ERX7xx models,ERX14xx models, and the Juniper Networks ERX310 Broadband Services Router.

•

See the E120 and E320 Module Guide for modules supported on the Juniper Networks E120 and E320 Broadband Services Routers.

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

Policy Management Configuration Tasks

Perform the required tasks and also any optional tasks that you need for your policy management configuration:

1. Create a CLACL (optional).

See “Classifier Control Lists Overview” on page 7

2. Create a rate-limit profile (optional).

See “Creating Rate-Limit Profiles” on page 73

3. Create a policy list.

See “Policy Lists Overview” on page 15

4. Create a classifier group.

See “Classifier Groups and Policy Rules Overview” on page 27

5. Create one or more policy rules within the classifier group.

See “Rate Limits for Interfaces Overview” on page 58

6. Apply a policy list to an interface or profile.

See “Classifier Groups and Policy Rules Overview” on page 27

Page 31

CHAPTER 2

Creating Classifier Control Lists for Policies

This chapter provides information for configuring policy-based routing management on E Seriesrouters. See the E120 and E320 Module Guide for modules supported on the E120 and E320 Broadband Services Routers. The chapter discusses the following topics:

•

Classifier Control Lists Overview on page 7

•

Creating or Modifying Classifier Control Lists for ATM Policy Lists on page 9

•

Creating or Modifying Classifier Control Lists for Frame-Relay Policy Lists on page 9

•

Creating or Modifying Classifier Control Lists for GRE Tunnel Policy Lists on page 10

•

Creating or Modifying Classifier Control Lists for IP Policy Lists on page 10

•

Creating or Modifying Classifier Control Lists for IPv6 Policy Lists on page 12

•

Creating or Modifying Classifier Control Lists for L2TP Policy Lists on page 13

•

Creating or Modifying Classifier Control Lists for MPLS Policy Lists on page 13

•

Creating or Modifying Classifier Control Lists for VLAN Policy Lists on page 13

Classifier Control Lists Overview

Classifier control lists (CLACLs) specify the criteria by which the router defines a packet flow. Table 3 on page 7 lists the criteria that you can use to create CLACLs for different types of traffic flows.

Table 3: CLACL Criteria

ATM

Frame Relay

CriteriaType of CLACL

•

CLP

•

Color

•

Traffic class

•

User packet class

•

Color

•

Mark discard eligibility (DE) bit

•

Traffic class

•

User packet class

Page 32

JunosE 11.3.x Policy Management Configuration Guide

Table 3: CLACL Criteria (continued)

GRE

CriteriaType of CLACL

•

Color

•

Traffic class

•

Type-of-service (ToS) byte

•

User packet class

•

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

IPv6

L2TP

•

Color

•

Destination IPv6 address

•

Destination port

•

Destination route class

•

Internet Control Message Protocol version 6 (ICMPv6)

•

IPv6 traffic class

•

Locally destined traffic

•

Multicast Listener Discovery (MLD)

•

Next header

•

Source IPv6 address

•

Source port

•

Source route class

•

Traffic class

•

Transmission Control Protocol (TCP)

•

User Datagram Protocol (UDP)

•

User packet class

•

Color

•

Traffic class

•

User packet class

Page 33

Chapter 2: Creating Classifier Control Lists for Policies

Table 3: CLACL Criteria (continued)

CriteriaType of CLACL

•

MPLS

VLAN

You configure CLACLs with a name and then values to match in the IP datagram header. A CLACL does not include an action: actions take place when a match is included in a policy list.

Color

•

Mark experimental (EXP) bit

•

Traffic class

•

User packet class

•

Color

•

Traffic class

•

User packet class

•

User priority

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.

If you do not specify one of the frame-relay, gre-tunnel, ip, ipv6, l2tp, mpls, or vlan keywords, the router creates an IP classifier list. This version of the command has been deprecated and may be removed in a future release.

Documentation

For information about the hardware and software CLACLs that are supported for each

•

interface type, see Policy Resources Overview on page 151.

• For information about monitoring Classifier Lists, see Monitoring Policy Management

Overview on page 173.

Creating or Modifying Classifier Control Lists for ATM Policy Lists

You can create or modify a classifier control list that can be used only in ATM policy lists.

•

Issue the atm classifier-list command:

host1(config)#atm classifier-list atmclassifier color red user-packet-class 10

clp 1

Documentation

atm classifier-list•

Creating or Modifying Classifier Control Lists for Frame-Relay Policy Lists

You can create or modify a classifier control list that can be used only in Frame Relay policy lists.

•

Issue the frame-relay classifier-list command.;

Page 34

JunosE 11.3.x Policy Management Configuration Guide

host1(config)#frame-relay classifier-list frclassifier color red user-packet-class 10

de-bit 1

frame-relay classifier-list•

Documentation

Creating or Modifying Classifier Control Lists for GRE Tunnel Policy Lists

You can create or modify a classifier control listthat can be used only inGRE tunnelpolicy lists.

•

Issue the gre-tunnel classifier-list command:

host1(config)#gre-tunnel classifier-list greClassifier50 color yellow user-packet-class

7 dsfield 40

gre-tunnel classifier-list•

Documentation

Creating or Modifying Classifier Control Lists for IP Policy Lists

Tasks to create or modify classifier control lists for IP policy lists:

•

Creating Classifier Control List for Only IP Policy Lists on page 10

•

Setting Up an IP Classifier Control List to Accept Traffic from All Sources on page 10

•

Classifying IP Traffic Based on Source and Destination Addresses on page 11

•

Using IP Classifier Control Lists to Match Route Class Values on page 11

•

Creating IP Classifier Control Lists for TCP and UDP Ports on page 11

•

Creating an IP Classifier Control List That Matches the ToS Byte on page 12

•

Creating an IP Classifier Control List That Filters ICMP Echo Requests on page 12

•

Creating IP Classifier Control Lists That Use TCP or IP Flags on page 12

•

Creating IP Classifier Control Lists That Match the IP Fragmentation Offset on page 12

Creating Classifier Control List for Only IP Policy Lists

You can create or modify a classifier control list that can be used only in IP policylists.The behavior ofmultiple-element classifier-list classificationis the logical OR of the elements in the CLACL.

•

Issue theip classifier-list command 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

Setting Up an IP Classifier Control List to Accept Traffic from All Sources

You can set up a CLACL to accept IP traffic from all source addresses on the subnet.

•

Issue the ip classifier-list command:

Page 35

Chapter 2: Creating Classifier Control Lists for Policies

host1(config)#ip classifier-list XYZCorpPermit ip 192.168.0.0 0.0.255.255 any

Classifying IP Traffic Based on Source and Destination Addresses

You can classify traffic based on source and destination addresses, You can specify the address as a host address, or a subnet with 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.

•

Issue the ip classifier-list command to classify traffic on any source or destination address:

host1(config)#ip classifier-list YourListName ip any any host1(config)#ip classifier-list YourListName ip host 10.10.10.10 any host1(config)#ip classifier-list YourListName ip 10.10.0.0 0.0.255.255 host 10.10.10.2

Using IP Classifier Control Lists to Match Route Class Values

You can set upclassifiercontrollists to match route-class values.In thisexample, 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, and 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).

•

Issue the ip classifier-list command:

host1(config)#ip classifier-list svale20 source-route-class 1 ip any any host1(config)#ip classifier-list svale30 destination-route-class 1 ip any any

tos 10

host1(config)#ip classifier-list svale40 source-route-class 1 local true ip any any host1(config)#ip classifier-list west25 source-route-class 1 local false ip any any

Creating IP Classifier Control Lists for TCP and UDP Ports

You can specify a single TCP or UDP port or a range of ports, where packets are matched with source address 198.168.30.100 and UDP source port numbers in the range 1–10.

•

Issue the ip classifier-list command to create a CLACL on a UDP host:

host1(config)#ip classifier-list YourListName udp host 192.168.30.100 range 1 10 any

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

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

To specify a single TCP or UDP port or range of ports, an ICMP code and optional type, or anIGMP type, whichmatchespacketswith source address 198.168.30.100 andICMP type 2 and code 10:

host1(config)#ip classifier-list YourListName icmp host 192.168.30.100 any 2 10

Page 36

JunosE 11.3.x Policy Management Configuration Guide

Creating an IP Classifier Control List That Matches the ToS Byte

You can create an IP CLACL that matches the ToS byte in the IP header.

•

Issue the ip classifier-list command using the tos keyword.

host1(config)#ip classifier-list tos128 ip any any tos 128 host1(config)#ip classifier-list low-drop-prec ip any any dsfield 10 host1(config)#ip classifier-list priority ip any any precedence 1

Creating an IP Classifier Control List That Filters ICMP Echo Requests

You can create a CLACL that filters all ICMP echo requests headed toward an access link under a denial-of-service attack.

•

Issue the ip classifier-list command:

host1(config)#ip classifier-list XYZCorpIcmpEchoReqs icmp any any 8 0 host1(config)#ip classifier-list XYZCorpIgmpType1 igmp any any 1

Creating IP Classifier Control Lists That Use TCP or IP Flags

You can create CLACLs that use TCP or IP flags. For both IP flags and TCP flags, if you specify only a single flag, the logical equation does not require quotation marks.

•

Issue the ip classifier-list command with thetcp-flagskeywordand a logical equation (a quotation-enclosed string using ! for NOT, & for AND) to match one or more of the ack, fin, psh, rst, syn, or urg TCP flags:

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"

•

Issue the ip classifier-list command with the ip-flags keyword and a logical equation (a quotation-enclosed string using ! for NOT, & for AND) to match one or more of the dont-fragment, more-fragments,, or reserved IP flags:

host1(config)#ip classifier-list dontFragment ip any any ip-flags "dont-fragment"

Creating IP Classifier Control Lists That Match the IP Fragmentation Offset

You can create CLACLs that match the IP fragmentation offset.

•

Issue the ip classifier-list command with 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:

host1(config)#ip classifier-list fragOffsetAttack ip any host 10.10.10.10 ip-frag-offset

eq 1

host1(config)#ip policy-list dosProtect host1(config-policy-list)#filter classifier-group fragOffsetAttack host1(config-policy-list)#forward

Creating or Modifying Classifier Control Lists for IPv6 Policy Lists

You can create or modify a classifier control list that can be used only in IPv6 policy lists.

Page 37

Chapter 2: Creating Classifier Control Lists for Policies

•

Issue the ipv6 classifier-list command:

host1(config)#ipv6 classifier-list ipv6classifier color red user-packet-class 5 tcfield 10 host1(config)#ipv6 classifier-list YourListName udp destination-port eq 75 host1(config)#ipv6 classifier-list telnetConnects tcp destination-port eq 23 tcp-flags

"syn & !ack"

host1(config)#ipv6 classifier-list listname icmpv6 icmp-type 3 icmp-code 6 host1(config)#ipv6 classifier-list svale20 source-route-class 1 host1(config)#ipv6 classifier-list svale30 destination-route-class 1 tcfield 10 host1(config)#ipv6 classifier-list svale40 source-route-class 1 local true host1(config)#ipv6 classifier-list west25 source-route-class 1 local false host1(config)#ipv6 classifier-list YourClaclList source-host 2001:db8:1::8001

destination-address 2001:db8:3::/48

ipv6 classifier-list•

Documentation

Creating or Modifying Classifier Control Lists for L2TP Policy Lists

You can create or modify a classifier control list that can be used only in L2TP policy lists.

•

Issue the l2tp classifier-list command:

host1(config)#l2tp classifier-list l2tpclassifier color red user-packet-class 7

l2tp classifier-list•

Documentation

Creating or Modifying Classifier Control Lists for MPLS Policy Lists

You can create or modify a classifier control list that can be used only in MPLS policy lists.

•

Issue the mpls classifier-list command:

host1(config)#mplsclassifier-listmplsClass user-packet-class10 exp-bits 3 exp-mask

Documentation

mpls classifier-list•

Creating or Modifying Classifier Control Lists for VLAN Policy Lists

You can create or modify a classifier control list that can be used only in VLAN policy lists.

•

Issue the vlan classifier-list command:

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

Page 38

JunosE 11.3.x Policy Management Configuration Guide

host1(config)#vlan classifier-list bestEffort user-priority 1 host1(config)#vlan classifier-list bestEffort user-priority 0

NOTE: You cannot configure classifier control lists (CLACLs) for policy lists to be attached to VLAN interfaces, without specifying the criteria by which the router defines a packet flow. Although the carriage return, <cr>, option is displayed when you type a question mark (?) after entering the vlan classifier list classiferName command without defining any other keyword or CLACL criterion, an error message is displayed when you press Enter to configure the VLAN CLACL with only the name. You must specify at least one criterion for the VLAN CLACL to be successfully configured.

Documentation

• vlan classifier-list

Page 39

CHAPTER 3

Creating Policy Lists

This chapter provides information for configuring policy lists on E Series Broadband Services Routers. See the E120 and E320 Module Guide for modules supported on the E120 and E320 Broadband Services Routers. The chapter discusses the following topics:

•

Policy Lists Overview on page 15

•

Creating Policy Lists for ATM on page 17

•

Creating Policy Lists for Frame Relay on page 19

•

Creating Policy Lists for GRE Tunnels on page 20

•

Creating Policy Lists for IP on page 21

•

Creating Policy Lists for IPv6 on page 22

•

Creating Policy Lists for L2TP on page 24

•

Creating Policy Lists for MPLS on page 24

•

Creating Policy Lists for VLANs on page 25

Policy Lists Overview

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 policy, secondary-input policy, or output policy. The router applies the rules in the attached policy list to the packets traversing that interface.

You can apply policy lists to packets:

•

Figure 1 on page 16 shows how a sample IP policy list is constructed.

Arriving at aninterface(input policy); onIP andIPv6 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)

Page 40

JunosE 11.3.x Policy Management Configuration Guide

Figure 1: Constructing an IP Policy List

Documentation

You can createa policylist with an unlimitednumber of classifier groups, eachcontaining an unlimited number of rules. These rules can reference up to 512 classifier entries.

If you enter a policy-list command and then enter exit, the router creates a policy list with no rules. If the router does not find any rules in a policy, it inserts a default filter rule. Attaching this policy list to an interface filters all packets on that interface.

NOTE: If you do not specify one of the frame-relay, gre-tunnel, ip, ipv6, l2tp,

mpls, or vlan keywords, the router creates an IP policy list. This version of the command has been deprecated and may be removed in a future release.

You can create policy lists for ATM, Frame Relay, IP, IPv6, GRE tunnels, L2TP, MPLS, and VLANs.

NOTE: Commands that you issue in Policy Configuration mode do not take

effect until you exit from that mode.

Policy Lists Overview on page 15•

• Monitoring Policy Management Overview on page 173

Page 41

Creating Policy Lists for ATM

In the following example, you create two policies: one for CBR traffic and one for UBR traffic. One policy is attached to an interface that contains CBR traffic and the other to an interface that contains UBR traffic.

1. Create a CBR policy list.

host1(config)#atm policy-list polCbr host1(config-policy-list)#

2. Create the classification group and assign a strict priority traffic class and color green.

host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#traffic-class strict-priority host1(config-policy-list-classifier-group)#color green

3. Exit Policy List Configuration mode to save the configuration.

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

Chapter 3: Creating Policy Lists

4. Create a UBR policy that maps to the strict best-effort traffic class and color red.

host1(config)#atm policy-list polUbr host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#traffic-class best-effort host1(config-policy-list-classifier-group)#color red

5. Exit Policy List Configuration mode to save the configuration.

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

6. Attach the policies to ATM subinterfaces.

host1(config)#interface atm 0/0.100 host1(config-if)#atm policy input polUbr statistics enabled host1(config-if)#exit host1(config)#interface atm 0/0.101 host1(config-if)#atm policy input polCbr statistics enabled host1(config-if)#exit

7. Display the policy lists.

host1#show atm subinterface atm 0/0.100

Circuit Interface Interface ATM-Prot VCD VPI VCI Type Encap MTU Status Type

----------- -------- --- --- --- ------- ----- ---- ------ --------ATM 0/0.100 RFC-1483 100 0 100 PVC SNAP 9180 up Static

Auto configure status : static Auto configure interface(s) : none Detected 1483 encapsulation : none Detected dynamic interface : none Interface types in lockout : none

Page 42

JunosE 11.3.x Policy Management Configuration Guide

Assigned profile (IP) : none assigned Assigned profile (BridgedEnet): none assigned Assigned profile (PPP) : none assigned Assigned profile (PPPoE) : none assigned Assigned profile (any) : none assigned

SNMP trap link-status: disabled

InPackets: 0 InBytes: 0 OutPackets: 0 OutBytes: 0 InErrors: 0 OutErrors: 0 InPacketDiscards: 0 InPacketsUnknownProtocol: 0 OutDiscards: 0 ATM policy input polUbr Statistics are disabled 1 interface(s) found

host1#show atm subinterface atm 0/0.101

Circuit Interface Interface ATM-Prot VCD VPI VCI Type Encap MTU Status Type

----------- -------- --- --- --- ------- ----- ---- ------ --------ATM 0/0.101 RFC-1483 101 0 101 PVC SNAP 9180 up Static

Auto configure status : static Auto configure interface(s) : none Detected 1483 encapsulation : none Detected dynamic interface : none Interface types in lockout : none

SNMP trap link-status: disabled

InPackets: 0 InBytes: 0 OutPackets: 0 OutBytes: 0 InErrors: 0 OutErrors: 0 InPacketDiscards: 0 InPacketsUnknownProtocol: 0 OutDiscards: 0 ATM policy input polCbr classifier-group * 3096 packets, 377678 bytes traffic-class best-effort color green 1 interface(s) found

atm policy-list•

Documentation

Page 43

Creating Policy Lists for Frame Relay

The following example creates a Frame Relay policy that on egress marks the DE bit to 1, and on ingress colors frames with a DE bit of 1 as red.

1. Create the policy list used to mark egress traffic, then create the classifier group for

packets conforming to CLACL frMatchDeSet. Add a rule that marks the DE bit as 1.

host1(config)#frame-relay policy-list frOutputPolicy host1(config-policy-list)#classifier-group frMatchDeSet host1(config-policy-list-classifier-group)#mark-de 1 host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit

2. Create the policy list used for the ingress traffic. and create the classifier group

conforming to CLACL frMatchDeSet. Add a rule that colors the ingress traffic.

host1(config)#frame-relay policy-list frInputPolicy host1(config-policy-list)#classifier-group frGroupA host1(config-policy-list-classifier-group)#color red host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit

Chapter 3: Creating Policy Lists

3. Apply the policy lists.

host1(config)#interface serial 5/0:1/1.1 host1(config-subif)#frame-relay policy output frOutputPolicy statistics enabled host1(config-subif)#ip address 10.0.0.1 255.255.255.0 host1(config-subif)#exit host1(config)#interface serial 5/1:1/1.1 host1(config-subif)#frame-relay policy input frInputPolicy statistics enabled host1(config-subif)#exit

4. Display interface information to view the applied policies.

host1#show frame-relay subinterface

Frame relay sub-interface SERIAL5/0:1/1.1, status is up Number of sub-interface down transitions is 0 Time since last status change 03:04:59 No baseline has been set In bytes: 660 Out bytes: 660 In frames: 5 Out frames: 5 In errors: 0 Out errors: 0 In discards: 0 Out discards: 0 In unknown protos: 0 Frame relay policy output frOutputPolicy classifier-group frGroupA entry 1 5 packets, 640 bytes mark-de 1 Frame relay sub-interface SERIAL5/1:1/1.1, status is up Number of sub-interface down transitions is 0 Time since last status change 03:05:09 No baseline has been set In bytes: 660 Out bytes: 660 In frames: 5 Out frames: 5 In errors: 0 Out errors: 0 In discards: 0 Out discards: 0 In unknown protos: 0

Page 44

JunosE 11.3.x Policy Management Configuration Guide

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

frame-relay policy-list•

Documentation

Creating Policy Lists for GRE Tunnels

The following example createsa GREtunnel policy listnamed routeGre50. For information about creating the CLACL used in this example, see the previous sections.

1. Create the policy list routeGre50.

host1(config)#gre-tunnel policy-list routeGre50

2. Create the classification group for the CLACL named gre8 and assign a precedence

of 150 to it.

host1(config-policy-list)#classifier-group gre8 precedence 150 host1(config-policy-list-classifier-group)#

3. Add two rules for traffic based on the CLACL named gre8: one rule to color packets

as red, and a second rule that specifies the ToS DS field value to be assigned to the packets.

Page 45

host1(config-policy-list-classifier-group)#color red host1(config-policy-list-classifier-group)#mark dsfield 20 host1(config-policy-list-classifier-group)#

4. Exit Policy List Configuration mode to save the configuration.

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

5. Display the policy list.

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

Chapter 3: Creating Policy Lists

gre-tunnel policy-list•

Documentation

Creating Policy Lists for IP

The following examplecreates an IP policy list named routeForABCCorp. For information about creating the CLACLs and rate-limit profile used in this example, see the previous sections.

1. Create the policy list routeForABCCorp.

host1(config)#ip policy-list routeForABCCorp host1(config-policy-list)#

2. Create the classification group for the CLACL named ipCLACL10 and assign the

precedence to the classification group.

host1(config-policy-list)#classifier-group ipCLACL10 precedence 75 host1(config-policy-list-classifier-group)#

3. Add a rule that specifies a group of forwarding solutions based on classifier list

ipCLACL10.

host1(config-policy-list-classifier-group)#forward next-hop 192.0.2.12 order 10 host1(config-policy-list-classifier-group)#forward next-hop 192.0.100.109

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

order 20

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.

Page 46

JunosE 11.3.x Policy Management Configuration Guide

host1(config-policy-list-classifier-group)#rate-limit-profile ipRLP25

6. Exit Classifier Group Configuration mode for ipCLACL10, then create a new

classification group for classifier list ipCLACL20. Add a rule that filters packets based on classifier list ipCLACL20.

host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group ipCLACL20 precedence 125 host1(config-policy-list-classifier-group)#filter

7. Exit Policy List Configuration mode to save the configuration.

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

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

ip policy-list•

Documentation

Creating Policy Lists for IPv6

The following example creates an IPv6 policy list named routeForIPv6. For information about creating the CLACL used in this example, see the previous sections.

1. Create the policy list routeForIPv6.

host1(config)#ipv6 policy-list routeForIPv6 host1(config-policy-list)#

2. Create the classification group for the CLACL named ipv6tc67 and assign the

precedence to the classification group.

host1(config-policy-list)#classifier-group ipv6tc67 precedence 75 host1(config-policy-list-classifier-group)#

3. Add a rule to color packets as red, and a second rule that sets the traffic class field

of the packets to 7.

Page 47

Chapter 3: Creating Policy Lists

host1(config-policy-list-classifier-group)#color red host1(config-policy-list-classifier-group)#mark tcfield 7

4. Exit Policy List Configuration mode to save the configuration.

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

5. Display the policy list.

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

You use the exceptionhttp-redirect command tocreate anexceptionrule withina policy classifier group to specify the client application for the destination of packets rather than forwarding them using the forwarding controller (FC).

In lower-numbered releases, the exception http-redirect command only supported the creation of exception rules within IPv4 policy lists. You can now configure the exception http-redirect command to create exception rules within IPv4 and IPv6 policy lists.

The following example creates an IPv6 policy list, epIPv6 for the http-redirect exception:

1. Create the policy list epIPv6.

host1(config)#ipv6 policy-list epIPv6 host1(config-policy-list)#

2. Create the classification group to match all packets.

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

3. Create an exception policy for http-redirect.

host1(config-policy-list-classifier-group)#exception http-redirect

4. Exit Policy List Configuration mode to save the configuration.

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

5. Display the policy list.

host1#show policy-list epIPv6

Policy Table

------ ----IPv6 Policy epIPv6 Administrative state: enable Reference count: 0 Classifier control list: *, precedence 100

Page 48

JunosE 11.3.x Policy Management Configuration Guide

exception http-redirect

Documentation

ipv6 policy-list•

• exception http-redirect

Creating Policy Lists for L2TP

The following example creates an L2TP policy list.

1. Create the policy list routeForl2tp.

host1(config)#l2tp policy-list routeForl2tp host1(config-policy-list)#

2. Create the classification group to match all packets.

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

3. Add a rule to color packets as red, and a second rule that uses the rate-limit profile

l2tpRLP10.

host1(config-policy-list-classifier-group)#color red host1(config-policy-list-classifier-group)#rate-limit-profile l2tpRLP10

4. Exit Policy List Configuration mode to save the configuration.

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

5. Display the policy list.

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

l2tp policy-list•

Documentation

Creating Policy Lists for MPLS

The following example creates an MPLS policy list.

1. Create the policy list routeForMpls.

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

Page 49

Chapter 3: Creating Policy Lists

2. Create the classification group.

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

3. Add one rule that sets the EXP bits for all packets to 2, and a second rule that uses

the rate-limit profile mplsRLP

host1(config-policy-list-classifier-group)#mark-exp 2 host1(config-policy-list-classifier-group)#rate-limit-profile mplsRLP5

4. Exit Policy List Configuration mode to save the configuration.

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

5. Display the policy list.

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

mpls policy-list•

Documentation

Creating Policy Lists for VLANs

The following example creates a VLAN policy list named routeForVlan. The classifier group lowLatencyLowDrop uses the default precedence of 100.

1. Create the policy list routeForVlan.

host1(config)#vlan policy-list routeForVlan host1(config-policy-list)#

2. Create the classification group.

host1(config-policy-list)#classifier-group lowLatencyLowDrop host1(config-policy-list-classifier-group)#

3. Create a rule that adds the lowLatencyLowDrop traffic class for all packets that fall

into the lowLatencyLowDrop classification.

host1(config-policy-list-classifier-group)#traffic-class lowLatencyLowDrop

4. Add a rule that sets the drop precedence for all packets that fall into the

lowLatencyLowDrop classification to green.

host1(config-policy-list-classifier-group)#color green

5. Add a rule that sets the user-priority bits for all packets that fall into the

lowLatencyLowDrop classification to 7.

Page 50

JunosE 11.3.x Policy Management Configuration Guide

host1(config-policy-list-classifier-group)#mark-user-priority 7

6. Exit to Policy List Configuration mode, then add traffic class rules for packets that

conform to different CLACLs.

host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group lowLatency host1(config-policy-list-classifier-group)#traffic-class lowLatency host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group excellentEffort host1(config-policy-list-classifier-group)#traffic-class excellentEffort host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group bestEffort host1(config-policy-list-classifier-group)#traffic-class bestEffort

7. Exit Policy List Configuration mode to save the configuration.

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

8. Display the policy list.

Documentation

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

• vlan policy-list

Page 51

CHAPTER 4

Creating Classifier Groups and Policy Rules

This chapter provides information for configuring policy-based routing management on E Seriesrouters. See the E120 and E320 Module Guide for modules supported on the E120 and E320 routers. The chapter discusses the following topics:

•

Classifier Groups and Policy Rules Overview on page 27

•

Policy Rule Precedence on page 28

•

Using Policy Rules to Provide Routing Solutions on page 31

•

Configuring Policies to Provide Network Security on page 31

•

Creating an Exception Rule within a Policy Classifier Group on page 32

•

Defining Policy Rules for Forwarding on page 33

•

Assigning Values to the ATM CLP Bit on page 34

•

Enabling ATM Cell Mode on page 35

•

Enabling IP Options Filtering on page 35

•

Packet Tagging Overview on page 35

•

Creating Multiple Forwarding Solutions with IP Policy Lists on page 36

•

Creating a Classifier Group for a Policy List on page 38

•

Applying Policy Lists to Interfaces and Profiles Overview on page 39

•

Using RADIUS to Create and Apply Policies Overview on page 42

•

Examples: Using the Ascend-Data-Filter Attribute for IPv4 Subscribers on page 47

•

Examples: Using the Ascend-Data-Filter Attribute for IPv6 Subscribers on page 52

Classifier Groups and Policy Rules Overview

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

Page 52

JunosE 11.3.x Policy Management Configuration Guide

lowest precedence value. Classifier groups with equal precedence are evaluated in the order of creation.

NOTE: For IP policies, the forward command supports the order keyword,

which enables you to order multiple forward rules within a single classifier group. (See “Using Policy Rules to Provide Routing Solutions” on page 31.)

From Policy Configuration mode, you can assign a precedence value to a CLACL by using the precedence keyword when you create a classifier group. The default precedence value is 100. For example:

host1(config-policy-list)#classifier-group ipCLACL25 precedence 21 host1(config-policy-list-classifier-group)#

The classifier-group command puts you in Classifier Group Configuration mode. In this mode you configure the policy rules that make up the policy list. For example:

host1(config-policy-list-classifier-group)#forward next-hop 172.18.20.54

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 Precedence

Because of the flexibility in creating policy lists and classifier groups, you can configure a classifier group that has multiple policy rules.

If a classifier group has multiple rules, the router uses the rules according to their precedence—not in the order in which you created the rules. The first rule listed (the forward rule) for a policy list type has the highest precedence and the last rule has the lowest. The precedence is based on the order in which the router performs rules. Rules are performed in order from lower to higherprecedence. Inthe event of a conflict, ahigher precedence rule overrides the lower precedent rule.

The precedence of rulesis importantif you wanta specificrule to beapplied. Forexample, if an IP policy list has both a rate-limit-profile rule (which specifies a color) and a color rule in the same classifier-group, the colorspecified by the color rule isalways usedrather than thecolor implied in the rate-limit-profilerule (the color rule has ahigher precedence).

Table 4 on page 29 lists the policy rule commands that you can use for each type of policy list. The table lists the rules in their order of precedence.

Page 53

NOTE: The ES2 10G Uplink LM and the ES2 10G LM support only IP, MPLS,

and VLAN interfaces.

Table 4: Policy Rule Commands and Precedence

Frame RelayATM

Chapter 4: Creating Classifier Groups and Policy Rules

VLANMPLSL2TPIPv6IPGRE

forwardforwardforwardforwardforwardforwardforwardforward

(See mark-clp in theJunosE

Command Reference Guide for

platform support information.)

colorcolorcolor

interface (input, secondary input, and output policies only)

–––

input and secondary input policies only (not supported on ES2 10G Uplink LM)

markmark-demark-clp

forward next-hop for input policies only

rate-limitprofile

colorcolorcolorcolorforward

––––exception for

mark-userpriority

user-packetclass

traffic-classtraffic-classtraffic-class

colorfilterfilterfilter

profile

class

traffic-classrate-limit-

class

traffic-classmarkuser-packet-

filteruser-packet-

class

filtermark-expfilteruser-packet-

user-packetclass

traffic-classuser-packet-

–traffic-class–filtertraffic-class–––

––––mark–––

––––filter–––

Page 54

JunosE 11.3.x Policy Management Configuration Guide

Table 4: Policy Rule Commands and Precedence (continued)

Frame RelayATM

VLANMPLSL2TPIPv6IPGRE

Documentation

–––

supported on ES2 10G Uplink LM or ES2 10G LM)

NOTE: The commands listed in this section replace the Policy List

Configuration mode versions of the commands. 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.

Classifier Groups and Policy Rules Overview on page 27•

• Monitoring Policy Management Overview on page 173

• color

• color-mark-profile

• filter

• green-mark

• log

––––log (not

• mark

• mark-clp

• mark-de

• mark-exp

• mark-user-priority

• next-hop

• next-interface

• rate-limit-profile

• red-mark

• reference-rate

• traffic-class

• user-packet-class

• yellow-mark

Page 55

Using Policy Rules to Provide Routing Solutions

The next-interface, next-hop, filter, and forward rules provide routing solutions for traffic matching a classifier.A classifier can haveonly one action that provides a routing solution.

If you configure tworouting solution rules, suchasfilter and forward, in the sameclassifier group, the router displays a warning message, and the rule configured last replaces the previous rule.

For IP policy lists, policy rules are available to enable 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:

Chapter 4: Creating Classifier Groups and Policy Rules

•

Packets from source 1.1.1.1 are forwarded out of interface ATM 0/0.1.

•

Packets from source 2.2.2.2 are forwarded out of interface ATM 2/1.1.

•

All other packets are dropped.

To configure this routing policy, issue the following commands:

host1(config)#ip classifier-list claclA ip host 1.1.1.1 any host1(config)#ip classifier-list claclB ip host 2.2.2.2 any host1(config)#ip policy-list IpPolicy100 host1(config-policy-list)#classifier-group claclA host1(config-policy-list-classifier-group)#forward interface atm 0/0.1 host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group claclB host1(config-policy-list-classifier-group)#forward interface atm 2/1.1 host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#filter host1(config-policy-list-classifier-group)#exit host1(config)#interface atm 0/0.0 host1(config-subif)#ip policy input IpPolicy100 statistics enabled

Configuring Policies to Provide Network Security

You 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

Page 56

JunosE 11.3.x Policy Management Configuration Guide

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. To determine the criteria for this classifier list, you need to analyze the traffic received on an interface. “Monitoring Policy Management Overview” on page 173 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.

•

TCPpackets from source 2.2.2.2 with the IP fragmentation offset setto one aredropped.

•

All other TCP packets are routed.

•

All other packets are dropped.

To configure this policy, issue the following commands:

host1(config)#ip classifier-list claclA ip host 1.1.1.1 any host1(config)#ip classifier-list claclB tcp host 2.2.2.2 any ip-frag-offset eq 1 host1(config)#ip classifier-list claclC tcp any any host1(config)#ip policy-list IpPolicy100 host1(config-policy-list)#classifier-group claclA host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group claclB host1(config-policy-list-classifier-group)#filter host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group claclC host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group * host1(config-policy-list-classifier-group)#filter host1(config-policy-list-classifier-group)#exit host1(config)#interface atm 0/0.0 host1(config-subif)#ip policy input IpPolicy100 statistics enabled

Creating an Exception Rule within a Policy Classifier Group

To create the exception rule within an IP policy classifier group to specify the client application for the destination of packets rather than forwarding them by the forwarding controller (FC), use the exception http-redirect command. Doing this enables the application to then perform an application-dependent action on the content of the packet. The exception rule applies to input and secondary-input policies.

The guidelines for creating exception rules within an IPv6 policy classifier group are the same as those for creating exception rules within an IPv4 policy classifier group.

NOTE: The exception http-redirect command is not supported for the ES2 10G Uplink LM.

Page 57

Chapter 4: Creating Classifier Groups and Policy Rules

An exception rule in the input policy only takes effect if neither the input policy nor the secondary policy drops the packet. Packets dropped by input or secondary policies are not exceptionedto the SRP module. HTTP redirect isthe only application that is available as a destination of the exception rule.

Because classifier groups can contain multiple actions, the following list describes how each rule interacts with the exception rule:

•

color—Packets are colored and the exception rule is applied.

•

filter—Packets are filtered and the exception rule is not applied. When the filter rule is present, other rules are not applied.

•

forward—Forward rule is ignored and the exception rule is applied to packets.

•

log—Packets are logged and the exception rule is applied.

•

mark—Packets are marked and the exception rule is applied.

•

next-hop—Next-hop rule is ignored and the exception rule is applied to packets.

•

next-interface—Next-interface rule is ignored and the exception rule is applied to packets.

•

rate-limit-profile—Rate limit is applied and the exception rule is applied to packets.

•

traffic-class—Traffic class is set and the exception rule is applied to packets.

•

user-packet-class—User packet classis setand theexceptionrule is appliedto packets.

•

exception—Exception rule is applied to packets.

Documentation

exception http-redirect•

• Classifier Groups and Policy Rules Overview on page 27

Defining Policy Rules for Forwarding

The forward next-hop command defines a rule that creates the forwarding solution for packetsmatchingthe current CLACL.The forward command canbe used whilethe policy list is referenced by interfaces. The suspend version suspends the forward rule within the classifier group.

For IP policy lists only:

Page 58

JunosE 11.3.x Policy Management Configuration Guide

•

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. Therouter uses the first reachable solution in the list, starting with the solution with the lowest order value. The default order value is 100.

NOTE: The forward interface and forward next-hop commands replace

the nest-interface and next-hop commands.

The switch route processor (SRP) module Fast Ethernet port cannot be the destination of the forward next-hop and forward next-interface commands.

•

If you specify a next-hop address as the forwarding solution, you can specify that the default route is not used as a routing solution for the next-hop address when selecting a reachable forward rule entry.

•

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.

•

You can no longer use an interface specifier of tunnel:mplswith the forward interface command, because that usage requires IP interfaces on top of RSVP-TE tunnels. Such interfaces are no longer present in the redesigned MPLS architecture. However, you can configure a static route for an address that is not otherwise used to point to a tunnel, and then use the forward next-hop command in the policy:

host1(config)#ip route 10.10.10.10/32 tunnel mpls:foo host1(config)#ip policy-list bar host1(config-policy-list-classifier-group)#forward next-hop 10.10.10.10

Documentation

forward•

• forward interface

• forward next-hop

Assigning Values to the ATM CLP Bit

The mark-clp command assigns a value of 0 or 1 to the ATM CLP bit for packets conforming to the current classifier control list.

Moduleson ESeriesrouterssupport classifying and markingof theATM CLPbit according to the following rules:

•

Modules on E120 and E320 routers support classifying of the ATM CLP bit only for frame-based interfaces (ATM Adaptation Layer 5 [AAL5] encapsulation), but not for individual ATM cells (ATM Adaptation Layer 0 [AAL0] encapsulation). In this case, if the CLP bit in any cell in the frame has a value of 1, the router treats the reassembled AAL5 frame as if it also had a CLP value of 1.

Page 59

Chapter 4: Creating Classifier Groups and Policy Rules

•

Modules on E120 and E320routers support markingof theATM CLP biton frame-based interfaces. In this case, every cell of the segmented frame leaves the router with the same CLP value.

•

Modules on ERX7xx models, ERX14xx models, and the ERX310 Broadband Services Router support classifying and marking of the ATM CLP bit for individual ATM cells (AAL0 encapsulation), but not for frame-based interfaces (AAL5 encapsulation).

mark-clp•

Documentation

Enabling ATM Cell Mode

When you configure a rate limit profile to account for ATM cell tax, the forwarding code calculates this information to determine the size of a frame instead of using only the frame size.

•

Issue the atm-cell-mode command to account for the ATM cell tax in statistics and rate calculations:

host1(config-policy-list)#atm-cell-mode

Use the show rate-limit-profile command to display the state of the mode.

Documentation

Monitoring Policy Management Overview on page 173•

• atm-cell-mode

• show rate-limit-profile

Enabling IP Options Filtering

You can filter packets with IP options on an interface:

•

Issue the ip filter-options all command.

host1(config-if)#ip filter-options all

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.

Documentation

Classifier Groups and Policy Rules Overview on page 27•

• ip filter-options all

Packet Tagging Overview

You can use the traffic-class rule in policies to tag a packet flow so that the QoS application can provide traffic-class queuing. Policies can perform both in-band and out-of-band packet tagging:

Page 60

JunosE 11.3.x Policy Management Configuration Guide

•

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 “Creating Rate-Limit Profiles” on page 73.

For example, 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 16 host1(config)#ip classifier-list data ip any any dsfield 32 host1(config)#ip policy-list colorVideoGreen host1(config-policy-list)#classifier-group video host1(config-policy-list-classifier-group)#color green host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group data host1(config-policy-list-classifier-group)#color yellow host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#exit host1(config)#interface atm 12/ 1.1 host1(config-if)#ip policy input colorVideoGreen statistics enabled

Creating Multiple Forwarding Solutions with IP Policy Lists

By default, the router uses a single route table lookup to determine theforwardingsolution 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 asolution.The router evaluatesthe forwarding solutions inthe 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:

Page 61

Chapter 4: Creating Classifier Groups and Policy Rules

•

You can specify a maximum of 20 forwarding solutions for a classifier.

•

The interfaceand next-hop elementsof aforwarding solution must existwithin 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 virtualrouter contextof thecommand-line interface (CLI),making the policy specific to that VR. The policy can be attached only to interfaces that belong to that VR. However, the policy can still be displayed and modified from any VR. The outputof theshowconfigurationcommand displays the policy in the section of outputrelated to that VRrather than in the sectionfor thedefault VR.This behavior ensures that when you use that outputfor a configuration script, the policy is specific to the correct VR, and the original configuration is re-created.

•

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 specifya next-hop address, thenyou can optionally specifythat the default route be ignored.

•

If youdeletethe target (interface or next-hopaddress) referencedin arule, 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 sameorder value arereachable, thenthe rule that was created first is used.

NOTE: The forward interface and forward next-hop commands are

replacingthe next-interfaceand next-hop commands, which do not support multiple forwarding solutions in a single forward rule.

In the following sample classifier group of a policy list, the forwarding solution of ATM interface 0/0.1 has the lowest order value in the group, and would therefore be selected as the solution for the policy list. However, if this interface is not reachable, the router then attempts to usethe solution with the next higherorder; which would beATM 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

Page 62

JunosE 11.3.x Policy Management Configuration Guide

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

Creating a Classifier Group for a Policy List

To create a classifier group for a policy list and assigns precedence to the specific CLACL that is referenced in the group:

1. Create a classifier group.

host1(config-policy-list)#classifier-group C1 parent-group IPG1

2. Assign a precedence to the CLACL.

host1(config-policy-list)#classifier-group westfordClacl precedence 150

3. Create a hierarchical policy parameter list.

host1(config)#policy-parameter A hierarchical host1(config)#parent-group EPG1 host1(config-parent-group)#exit host1(config)#ip policy-list POL host1(config-policy-list)#classifier-group C1 external parent-group EPG1 parameter

host1(config-policy-list)#exit

The no version removes the classifier group and its rules from a policy list. The precedence keyword specifies 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.

The parent-group keyword creates a parent group in a rate-limit hierarchy for IP, IPv6, L2TP, and MPLS. The external parent-group keyword creates an external parent group in a rate-limit hierarchy for IP, IPv6, L2TP, and MPLS. All packets matching the classifierare sentto the parentgroup for furtherprocessing,exceptfor packets dropped by the classifier using the filter rule.

More than one classifier group can have the same parent group, which enables you to create hierarchies.

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.

Page 63

Chapter 4: Creating Classifier Groups and Policy Rules

Documentation

Classifier Groups and Policy Rules Overview on page 27•

• Creating Rate-Limit Profiles on page 73

• Monitoring Policy Management Overview on page 173

• aggregation-node

• classifier-group

• ip policy-parameter hierarchical

• ip policy-parameter reference-rate

• ipv6 policy-parameter hierarchical

• ipv6 policy-parameter reference-rate

• l2tp policy-parameter hierarchical

• l2tp policy-parameter reference-rate

• mpls policy-parameter hierarchical

• mpls policy-parameter reference-rate

• next-parent

• parent-group

• policy-parameter hierarchical

Applying Policy Lists to Interfaces and Profiles Overview

You can assign a policy list to supportedinterfacesand profiles. Policy lists aresupported 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. Ineither case, you can enable or disable the recording of statistics for bytes and packets affected by the assigned policy.

You can also preserve statistics when you attach a new policy that has a classifier list that is the same for both the original and the new policy attachments.

You can use policy commands to assign an ATM, Frame Relay, GRE tunnel, IP, IPv6, MPLS, or VLAN policy list to an interface. Also, you can use them 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

Page 64

JunosE 11.3.x Policy Management Configuration Guide

NOTE:

•

The mpls policy command is used to attach policies to MPLS Layer 2 circuits only.

•

The SRP module Fast Ethernet port does not support policy attachments, nor can the module be the destination for the forward next-hop, forward next-interface, next-hop, and next-interface commands

Use the input or output keyword to assign the policy list to the ingress or egress of the interface. For ATM, IP, and IPv6 policy lists, use the secondary-input keyword to assign the policy list, after route lookup, to data destined for local or remote destinations. 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

•

To protect a router from being overwhelmed by legitimate local traffic

•

To apply policies on packets associated with the route class

NOTE: The local-input keyword for the ip policy and ipv6 policy commands

is deprecated, and may be completely removed in a future release. We recommend you remove the keyword from scripts. Re-create any local input policies using the ip classifier-list local true command and attaching the policies using the ip policy secondary-input command.

You can enable or disablethe recordingof routingstatisticsfor bytes and packets affected by the policy. If you enable statistics, you can enable or disable baselining of the statistics. The router implements the baseline by reading and storing the statistics at the time the baseline is set and then subtracting this baseline whenever baseline-relative statistics are retrieved. You must also enable baselining on the interface with the appropriate baseline command.

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

keyword.

You can use the preserve keyword to savethe existing statistics when you attach a policy to an interface that already has a policy attached. This keyword saves the statistics for any classifier-list that is the same for both the new and old policy attachments. Without the preserve keyword, all statistics are deleted when you attach the new policy.

Page 65

Chapter 4: Creating Classifier Groups and Policy Rules

For example, when youreplacea policyattachmentthat referencesthe originalpolicy-list plOne with a new attachment referencing policy-list plTwo, the existing statistics for the classifier group referencing clOne and the default classifier group are saved.

CommentNew Policy AttachmentOriginal Policy Attachment

-ip policy-list plTwoip policy-list plOne

statistics from plOneare savedip classifier-list clOneip classifier-list clOne

-ForwardForward

-ip classifier-list clFourip classifier-list clTwo

-ForwardForward

-ip classifier-list clFiveip classifier-list clThree

-ForwardForward

Documentation

statistics from plOneare savedclassifier-list *classifier-list *

-FilterFilter

You can use the merge keyword to enable merging of multiple policies to form a single policy.

host1(config)#vlan policy input VlanPolicy33 statistics enabled preserve

host1(config)#ipv6 policy secondary-input my-policy

To assign the policy list named routeForXYZCorp with statistics enabled to the ingress IP interface over an ATM subinterface:

host1(config)#interface atm 12/0.1 host1(config)#ip policy input routeForXYZCorp statistics enabled

To create an L2TP profile that applies the policy list routeForABCCorp to the egress of an interface:

host1(config)#profile bostonProfile host1(config)#l2tp policy output routeForABCCorp

atm policy•

• frame-relay policy

• gre-tunnel policy

• ip policy

• ipv6 policy

• l2tp policy

• mpls policy

Page 66

JunosE 11.3.x Policy Management Configuration Guide

• vlan policy

Using RADIUS to Create and Apply Policies Overview

E Series routers enable you to use RADIUS to create and apply policies on IPv4 and IPv6 interfaces. This featuresupports theAscend-Data-Filterattribute[242] through aRADIUS vendor-specific attribute (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

NOTE: An E Series router dynamically assigns names to the new classifier

list and policy list as described in “Ascend-Data-Filter Attribute for IPv4/IPv6 Subscribers in a Dual Stack” on page 45.

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"

Table 5 on page 43 lists the fields in the order in which they are specified in the hexadecimal Ascend-Data-Filter attribute.

Page 67

Table 5: Ascend-Data-Filter Fields

Chapter 4: Creating Classifier Groups and Policy Rules

CommentsFormatAction or Classifier

Source IP address

Destination IP address

1 byteType

1 byteFilter or forward

1 byteIndirection

16 bytes for IPv6

1 byteSource IP prefix

1=IPv4

3=IPv6

0=filter

1=forward

0=egress

1=ingress

-1 byteSpare

-4 bytes for IPv4

Type 1 = Number of leading zeros in the wildcard mask

Type 3 = Higher-order contiguous bits of the address that comprise the network portion of the address

1 byteDestination IP prefix

1 byteSource port qualifier

Type 1 = Number of leading zeros in the wildcard mask

Type 3 = Higher-order contiguous bits of the address that comprise the network portion of the address

-1 byteProtocol

Non implemented1 byteEstablished

-2 bytesSource port

-2 bytesDestination port

0= no compare

1= less than

2= equal to

3= greater than

4= not equal to

Page 68

JunosE 11.3.x Policy Management Configuration Guide

Table 5: Ascend-Data-Filter Fields (continued)

CommentsFormatAction or Classifier

1 byteDestination port qualifier

0= no compare

1= less than

2= equal to

3= greater than

4= not equal to

-2 bytesReserved

1 byteMarking value

Type of Service (ToS)—for IPv4

Differentiated Services Code Point (DSCP)—for IPv6

0= no packet marking1 byteMarking mask

•

1–41 bytesTraffic class

0= no traffic class (required if there is no profile)

•

First byte specifies thelength of the ASCII name of the traffic class

•

Traffic class must be statically configured

•

Name can optionally be null terminated, which consumes 1 byte

•

Although the traffic class name field supports up to 41 bytes, you can create an Ascend-Data-Filter attribute with the traffic class name field set to a maximum of 32 bytes only (including null characters). This restriction occurs because the traffic class group configuration enables a traffic class name of up to 31 characters only.

•

1–41 bytesRate-limit profile

0= no rate limit (required if there is no profile)

•

First byte specifies the length of the ASCII, followed by the ASCII name of the profile

•

Profile must be statically configured

•

Name can optionally be null terminated, which consumes 1 byte

NOTE: To create a rate-limit profile, traffic class, or marking rule, you must

first configure the filter/forward field as forward.

A single RADIUS record can contain two policies—one ingress policy and one egress policy.Each policy canhave a maximum of 512 ascend-datafilters.Each ascend data-filter creates a classifier group and the action associated with the classifier group.

Construction of IPv6 Classifiers from the Hexadecimal Ascend-Data-Filter Attribute

If both the source and destination IP prefixes are 128, the IPv6 classifier is created using the IPv6 host argument as follows:

IPv6 classifier-list testipv6 source-host 2001:db8:85a3::8a2e:370:7334 destination-host

2001:db8::1428:57ab

Page 69

Chapter 4: Creating Classifier Groups and Policy Rules

If eitherthe source ordestination IP prefixis non-zero, but lessthan 128bits, (for example, 64 bits), the IPv6 classifier is created using the IPv6 address argument as follows:

IPv6 classifier-list v6cl4 source-address 2001:db8:85a3::8a2e:370:7334/64

destination-address 2001:db8::1428:57ab/64

NOTE: In JunosE Release 10.1.x and earlier, the maximum width of a CAM hardware classifier entry for IPv4 or IPv6 in a single policy was 128 bits. In JunosE Release 10.2.x and later, based on the size limit for a combined IPv6 classifier entry, a maximum of 336 bits of CAM entry is supported for full IPv6 classificationwith an additional 16 bits for rule set ID. However, OC48/STM16 line modules on ERX14xx models, ERX7xx models, and the ERX310 router support only 128-bit IPv6 classification. For more information on size limits for IP and IPv6 classifiers, see “Size Limit for IP and IPv6 CAM Hardware Classifiers” on page 155.

Ascend-Data-Filter Attribute for IPv4/IPv6 Subscribers in a Dual Stack

The PPP link between the customer premises equipment (CPE) and the provider edge (PE) device or E Series router equipment might require both IPv4 and IPv6 protocols for transmission of data. Such networks require that PE devices run a dual stack of IPv4 and IPv6 services. Dual-stack routers allow simultaneous support for both IPv4 and IPv6 applications. The following guidelines are used to create a policy defined in the Ascend-Data-Filter attribute when IPv4 and IPv6 subscribers are in a network:

•

If a subscriber requires only IPv4 services, only the Type 1 action is used in the Access-Accept message returned from the RADIUS server in response to the client authentication request.

•

If a subscriber requires only IPv6 services, only the Type 3 action is used in the Access-Accept message returned from the RADIUS server.

•

If both IPv4 and IPv6 addresses are assigned to the subscriber interface, then either Type 1 or Type 3 or both the actions are used in the Access-Accept message.

•

If the Type 1 action is used and the Indirection action field is set to 01 in the Ascend-Data-Filter attribute, one primary input policy is created and applied on the ingress IPv4 interface.

•

If the Type 3 action is used and the Indirection action field is set to 01 in the Ascend-Data-Filter attribute, one primary input policy is created and applied on the ingress IPv6 interface.

•

If the Type 1 action is used and the Indirection action field is set to 00 in the Ascend-Data-Filter attribute, one primary output policy is created and applied on the egress IPv4 interface.

Page 70

JunosE 11.3.x Policy Management Configuration Guide

•

If the Type 3 action is used and the Indirection action field is set to 00 in the Ascend-Data-Filter attribute, one primary output policy is created and applied on the egress IPv6 interface.

•

Ascend-Data-Filter attributes for both IPv4 and IPv6 interfaces are stored on the RADIUS server andthe appropriatepolicies are created and applied tothe corresponding interfaces when they come up, depending on the type of subscribers.

In lower-numbered releases, the formats of the input and output classifier list names and policy list names were as follows:

•

clin_<InterfaceId>_<filterNum>

•

clout_<InterfaceId>_<filterNum>

•

plin_<InterfaceId>

•

plout_<InterfaceId>

where:

•

clin—Classifier list included in an input policy list

•

clout—Classifier list included in an output policy list

•

plin—Policy list applied to the ingress interface

•

plout—Policy list applied to the egress interface

•

InterfaceId—A unique identifier for the interface to which the policy is applied

•

filterNum—A value that denotes the sequence of Ascend-Data-Filter attribute configured on the RADIUS server

In this release, the formats of the input and output classifier list names and policy list names are modified to support IPv6 subscribers. The following is the new format of the input and output classifier list and policy list:

•

clin_<AuthId>_<filterNum>

•

clout_<AuthId>_<filterNum>

•

plin_<ip/ipv6>_<AuthId>

•

plout_<ip/ipv6>_<AuthId>

where:

•

AuthId—A unique identifier that is used during the authentication of the client with the RADIUS server

•

ip/ipv6—Type of protocol used based on the Type action field

Documentation

Examples: Using the Ascend-Data-Filter Attribute for IPv4 Subscribers on page 47•

• Examples: Using the Ascend-Data-Filter Attribute for IPv6 Subscribers on page 52

Page 71

Chapter 4: Creating Classifier Groups and Policy Rules

Examples: Using the Ascend-Data-Filter Attribute for IPv4 Subscribers

This section provides examples showing the configuration of policies that use the Ascend-Data-Filter attribute for IPv4 subscribers.

In this example, the following Ascend-Data-Filter attribute creates a RADIUS record that configuresan input policy.The policyfiltersall packets from network 10.2.1.0 with wildcard mask 0.0.0.255 to any destination.

Ascend-Data-Filter="01000100 0A020100 00000000 18000000 00000000 00000000"

Table 6 on page 47 lists the values specified in the Ascend-Data-Filter attribute.

Table 6: Ascend-Data-Filter Attribute for an Input Policy on an IPv4 Interface

Actual ValueHex ValueAction or Classifier

IPv401Type

Filter00Filter or Forward

Ingress01Indirection

None00Spare

10.2.1.00a020100Source IP address

Any00000000Destination IP address

24 (0.0.0.255)18Source IP mask

0 (255,255,255,255)00Destination IP mask

None00Protocol

None00Established

None0000Source port

None0000Destination port

None00Source port qualifier

None00Destination port qualifier

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

None0000Reserved

Page 72

JunosE 11.3.x Policy Management Configuration Guide

host1#show classifier-list

Classifier Control List Table

---------- ------- ---- -----

IP clin_1800020_00.1 ip 10.2.1.0 0.0.0.255 any

host1#show policy-list

Policy Table

------ ----IP Policy plin_ip_1800020 Administrative state: enable Reference count: 1 Classifier control list: clin_1800020_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

In this example, the Ascend-Data-Filter attribute is used to create RADIUS records that configure two policies. The first policy is an input policy that filters all TCP packets that come from a port greater than 9000 on host 10.2.1.1 and that go to any destination. The second policy is an output policy that filters all UDP packets from network 20.1.0.0 to host 10.2.1.1, port 3090.

Ascend-Data-Filter = "01000100 0A020101 00000000 20000600 23280000 03000000"

Ascend-Data-Filter= "01000000 14010000 0A020101 10201100 00000C12 00020000"

Using the show classifier-list and show policy-list commands produces the following information about the new policies:

host1#show classifier-list

Classifier Control List Table

---------- ------- ---- ----IP clin_1800021_00.1 tcp 10.2.1.1 gt 9000 any IP clout_1800021_01.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_ip_1800021 Administrative state: enable Reference count: 1 Classifier control list: clin_1800021_00, precedence 100 filter

Referenced by interface(s): ATM4/0.0 input policy, statistics enabled, virtual-router default

Referenced by profile(s): No profile references

IP Policy plout_ip_1800021

Page 73

Chapter 4: Creating Classifier Groups and Policy Rules

Administrative state: enable Reference count: 1 Classifier control list: clout_1800021_01, precedence 100 filter

Referenced by interface(s): ATM4/0.0 output policy, statistics enabled, virtual-router default

Referenced by profile(s): No profile references

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"

Page 74

JunosE 11.3.x Policy Management Configuration Guide

Using the show classifier-list and show policy-list commands produces the following information about the new policies:

host1#show classifier-list

Classifier Control List Table

---------- ------- ---- ----IP clin_1800022_00.1 tcp host 10.2.1.1 20.0.0.0 0.255.255.255 IP clin_1800022_01.1 tcp host 10.2.1.1 any IP clin_1800022_02.1 ip host 10.2.1.1 any IP clout_1800022_04.1 tcp 20.0.0.0 0.255.255.255 host 10.2.1.1 IP clout_1800022_05.1 tcp any host 10.2.1.1 IP clout_1800022_06.1 ip any host 10.2.1.1

host1#show policy-list

Policy Table

------ ----IP Policy plin_ip_1800022 Administrative state: enable Reference count: 1 Classifier control list: clin_1800022_00, precedence 100 forward Classifier control list: clin_1800022_01, precedence 100 filter Classifier control list: clin_1800022_02, precedence 100 forward Classifier control list: *, precedence 100 filter

Referenced by interface(s): ATM4/0.0 input policy, statistics enabled, virtual-router default

Referenced by profile(s): No profile references

IP Policy plout_ip_1800022 Administrative state: enable Reference count: 1 Classifier control list: clout_1800022_04, precedence 100 forward Classifier control list: clout_1800022_05, precedence 100 filter Classifier control list: clout_1800022_06, precedence 100 forward Classifier control list: *, precedence 100 filter

Referenced by interface(s): ATM4/0.0 output policy, statistics enabled, virtual-router default

Referenced by profile(s): No profile reference

In this example, the following Ascend-Data-Filter attribute creates a RADIUS record that configures an input policy on an IPv4 interface. 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.

Page 75

Chapter 4: Creating Classifier Groups and Policy Rules

Ascend-Data-Filter="010101000a020102 00000000 20000600 045708ae02010000

05aa0773 6f6d6554 636c0773 6f6d6552 6c70"

Table 7 on page 51 lists the values specified in the Ascend-Data-Filter attribute.

Table 7: Ascend-Data-Filter Attribute Values for a RADIUS Record

Actual ValueHex ValueAction or Classifier

IPv401Type

Filter01Forward

Ingress01Indirection

None00Spare

10.2.1.20a020102Source IP address

Any00000000Destination IP address

32 (0.0.0.0)20Source IP mask

0 (255,255,255,255)00Destination IP mask

TCP06Protocol

None00Established

None0000Source port

None0000Destination port

None00Source port qualifier

None00Destination port qualifier

None0000Reserved

505Marking value

170aaMarking mask

someTcl0773 6f6d6554 636cTraffic class

someRlp0773 6f6d6552 6c70Rate-limit profile

host1#show classifier-list

Classifier Control List Table

Page 76

JunosE 11.3.x Policy Management Configuration Guide

---------- ------- ---- ----IP clin_1800023_00.1 tcp host 10.2.1.2

host1#show policy-list

Policy Table

------ ----IP Policy plin_ip_1800023 Administrative state: enable Reference count: 1 Classifier control list: clin_1800023_00, precedence 100 mark 5 mask 170 traffic-class someTcl rate-limit-profile someRlp

Referenced by interface(s): ATM11/0.0 input policy, statistics enabled, virtual-router default

Referenced by profile(s): No profile references

Documentation

Examples: Using the Ascend-Data-Filter Attribute for IPv6 Subscribers on page 52•

• Using RADIUS to Create and Apply Policies Overview on page 42

Examples: Using the Ascend-Data-Filter Attribute for IPv6 Subscribers

This section provides examples showing the configuration of policies that use the Ascend-Data-Filter attribute when there are IPv6 subscribers in a network.

In this example, the following two Ascend-Data-Filter attributes are used to create RADIUS records that configure two policies. The first policy is anoutput policy that filters all UDP packets from network 2001:82ab:1020:87ec::0/64 to host 2001:82ab:1020:87ec:1234:0917:3415:0012, port 3090. The second policy is an input policy that filters all TCP packets that come from a port greater than 9000 on host 2001:82ab:1020:87ec:1234:0917:3415:0012 and that go to any destination.

Ascend-Data-Filter1 = "03000000 300182ab 102087ec 00000000 00000000 200182ab 102087ec 12340917 34150012 40801100 00000C12 00020000" Ascend-Data-Filter2 = "03000100 200182ab 102087ec 12340917 34150012 00000000

00000000 00000000 00000000 80000600 23280000 03000000"

Table 8 on page 52 lists the values specified in the Ascend-Data-Filter1 attribute that are used to create an output policy.

Table 8: Ascend-Data-Filter Attribute for an Output Policy on an IPv6 Interface

Actual ValueHex ValueAction or Classifier

IPv603Type

Filter00Forward

Egress00Indirection

Page 77

Chapter 4: Creating Classifier Groups and Policy Rules

Table 8: Ascend-Data-Filter Attribute for an Output Policy on an IPv6 Interface (continued)

Actual ValueHex ValueAction or Classifier

None00Spare

Source IPv6 address

Destination IPv6 address

300182ab 102087ec 00000000 00000000

200182ab 102087ec 12340917 34150012

3001:82ab:1020:87ec: 0000:0000:0000:0000

2001:82ab:1020:87ec: 1234:0917:3415:0012

6440Source IPv6 prefix

12880Destination IPv6 prefix

UDP11Protocol

None00Established

None0000Source port

30900C12Destination port

None00Source port qualifier

Equal to02Destination port qualifier

None0000Reserved

Table 9 on page 53 lists the values specified in the Ascend-Data-Filter2 attribute that are used to create an input policy.

Table 9: Ascend-Data-Filter Attribute for an Input Policy on an IPv6 Interface

Actual ValueHex ValueAction or Classifier

IPv603Type

Filter00Forward

Ingress01Indirection

None00Spare

2001:82ab:1020:87ec:1234:0917:3415:0012200182ab 102087ec12340917 34150012Source IPv6 address

Destination IPv6 address

00000000

Any00000000 00000000 00000000

12880Source IPv6 prefix

Page 78

JunosE 11.3.x Policy Management Configuration Guide

Table 9: Ascend-Data-Filter Attribute for an Input Policy on an IPv6 Interface (continued)

Actual ValueHex ValueAction or Classifier

000Destination IPv6 prefix

TCP06Protocol

None00Established

90002328Source port

None0000Destination port

Greater than03Source port qualifier

None00Destination port qualifier

None0000Reserved

Use the show classifier-list and show policy-list commands to view information about the configured input and output policies:

host1#show classifier-list

Classifier Control List Table

---------- ------- ---- -----

IPv6 clout_1800020_00.1 udp source-address 3001:82ab:1020:87ec::/64 destination-host 2001:82ab:1020:87ec:1234:917:3415:12 destination-port eq 3090 IPv6 clin_1800020_01.1 tcp source-host 2001:82ab:1020:87ec:1234:917:3415:12 source-port gt 9000

host1#show policy-list

Policy Table

------ ----IPv6 Policy plout_ipv6_1800020 Administrative state: enable Reference count: 1 Classifier control list: clout_1800020_00, precedence 100 filter

Referenced by interface(s): GigabitEthernet10/0.2 output policy, statistics enabled, virtual-router default

Referenced by profile(s): None

Referenced by merged policies: None

IPv6 Policy plin_ipv6_1800020 Administrative state: enable Reference count: 1

Page 79

Chapter 4: Creating Classifier Groups and Policy Rules

Classifier control list: clin_1800020_01, precedence 100 filter

Referenced by interface(s): GigabitEthernet10/0.2 input policy, statistics enabled, virtual-router default

Referenced by profile(s): None

Referenced by merged policies: None

Documentation

• Examples: Using the Ascend-Data-Filter Attribute for IPv4 Subscribers on page 47

• Using RADIUS to Create and Apply Policies Overview on page 42

Page 80

JunosE 11.3.x Policy Management Configuration Guide

Page 81

CHAPTER 5

Creating Rate-Limit Profiles

This chapter provides information for configuring rate-limit policy management onE Series routers. For information on monitoring rate-limit profiles, see “Monitoring Rate-Limit Profiles” on page 203

This chapter discusses the following topics:

•

Rate Limits for Interfaces Overview on page 58

•

Hierarchical Rate Limits Overview on page 59

•

Percent-Based Rates for Rate-Limit Profiles Overview on page 69

•

Policy Parameter Quick Configuration on page 73

•

Creating Rate-Limit Profiles on page 73

•

One-Rate Rate-Limit Profiles Overview on page 78

•

Creating a One-Rate Rate-Limit Profile on page 79

•

Configuring a TCP-Friendly One-Rate Rate-Limit Profile on page 79

•

Two-Rate Rate-Limits Overview on page 81

•

Creating a Two-Rate Rate-Limit Profile on page 84

•

Setting the Committed Action for a Rate-Limit Profile on page 85

•

Setting the Committed Burst for a Rate-Limit Profile on page 85

•

Setting the Committed Rate for a Rate-Limit Profile on page 86

•

Setting the Conformed Action for a Rate-Limit Profile on page 86

•

Setting the Exceeded Action for a Rate-Limit Profile on page 87

•

Setting the Excess Burst for a Rate-Limit Profile on page 87

•

Setting the Mask Value for MPLS Rate-Limit Profiles on page 88

•

Setting the Mask Value for IP and IPv6 Rate-Limit Profiles on page 88

•

Setting the Peak Burst for Two-Rate Rate-Limit Profiles on page 88

•

Setting the Peak Rate for Rate-Limit Profiles on page 89

•

Setting a One-Rate Rate-Limit Profile on page 89

•

Setting a Two-Rate Rate-Limit-Profile on page 91

•

Bandwidth Management Overview on page 92

•

Rate-Limiting Traffic Flows on page 95

Page 82

JunosE 11.3.x Policy Management Configuration Guide

Rate Limits for Interfaces Overview

To configure rate limiting for interfaces, you first create a rate-limit profile, which is a set of bandwidth attributes and associated actions. Your router supports two types of rate-limitprofiles—one-rate and two-rate—for IP, IPv6,LT2P, and MPLS Layer 2transport 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.

You configure rate limit profiles from Global Configuration Mode.

NOTE: Commands that you issue in Rate Limit Profile Configuration mode

do not take effect until you exit from that mode.

When packets enter an interface that has a rate-limit profile applied, the router performs the following:

•

Counts the number of bytes (packets) over time

•

Categorizes each packet as committed, conformed, or exceeded

•

Assigns a transmit, drop, or mark action

NOTE: Mark actions and mask values are supported only on IP, IPv6, and

MPLS rate-limit profiles. They are not supported on hierarchical rate limits, but are replaced by color-mark profiles.

An additional function of rate limiting is to apply a color code to packets assigned toeach category: green for committed, yellow for conformed, and red for exceeded. The system uses the color code internally to indicate drop preference when an outbound interface is congested.

Rate limiters are implemented using a dual token bucket scheme: a token bucket for conformed (yellow) packets and a token bucket for committed (green) packets. One token is synonymous with one byte. The capacity of the buckets is the maximum number of tokens that can be placed in each bucket.

You configure the bucket capacity with the peak burst parameteror the committed burst parameter. Theburst parametersare in bytes (not bytes per second), which isthe number of tokens in a full bucket. When a packet passes through a rate limiter, its size iscompared to the contents of both buckets, the packet is categorized, and the rate-limiter action is taken on the packet.

Peak rate and committed rate determine the fill rate of their respective buckets. If you set the committed rate to 128,000 bps, tokens are added to the committed (green) bucket at a rate of 128,000 bps (16 K bytes per second), regardless of the traffic. If no traffic passes through the rate limiter, the bucket continues to fill until it reaches the committed burst setting.

Page 83

Traffic passes through the rate limiter causing a draining of tokens. The drain rate is dependent on how large the packets are and how much time elapses between packets. At any given instant the level of tokens in each bucket is a function of the fill rate, size of packets, and elapsed time between packets.

When packets are received on an interface with a rate limiter applied, the level of tokens in each bucket dynamically changes in both of the following ways:

•

Tokens are added every 100-ms sample period

•

Tokens are removed based on the size and rate of incoming packets

Hierarchical Rate Limits Overview

In anothertype of rate limiting, rate-limit hierarchies enable lower priority traffic to access unused bandwidth allocated for real-time traffic, such as voice or video, during times when no real-time traffic is flowing. IPsubscribers receive multiple services, such as Web, video, andfile transfer, that have amaximum bandwidth. A rate-limit hierarchy can apply a common rate limit to several classified flows, enabling them to share bandwidth according to the preferences set in the hierarchical rate limits.

Chapter 5: Creating Rate-Limit Profiles

You can also use rate-limit hierarchies in a layer 2 (ATM) access network for DSL where many routing gateways lead into one Broadband Access Server. The Broadband Access Server uses rate-limit hierarchies to allocate shareable bandwidth to each routing gateway, which enables unused bandwidth from one routing gateway to be used by others. The hierarchy in the rate limit represents the hierarchy in the access network.

Rate-limithierarchies enable you to shareunused bandwidth dynamically, takingunused preferred bandwidth. They also enable real-time traffic to use all guaranteed bandwidth at any time without violating the configured limit on the total interface bandwidth. While preferredtrafficfluctuates, theinterface rate limit adjusts,dropping non-preferred packets to keep the total flow through the interface under a configured maximum rate, because preferred packets cannot be dropped by the shared rate limits, only by their individual rate limits.

Shared rate limits in the hierarchy keep the combined traffic below a configured maximum without dropping preferred packets. Preferred packets always reduce tokens on these rate limits, making their token counts negative, if necessary. Later non-preferred packets are then dropped in greater volume, bringingthe totaltraffic through the shared rate limit below its configured maximum.

Every packet passing through a rate limit hierarchy has an owner, which is the last rate limit that canmodify thepacket;for example, by changing itscolor or droppingit. Preferred packetsare owned by their individual preferredratelimits, whichdo nottransferownership of the packet while the packet traverses the hierarchy. Ownership of non-preferred packets is transferred while they move from one rate-limit to the next in the hierarchy, so shared rate limits can change the packet color or drop them.

Page 84

JunosE 11.3.x Policy Management Configuration Guide

Hierarchical Classifier Groups

Rate-limit hierarchies can be intra-interface, where different flows from classifier groups are in one policy attachment on an interface. Each time the policy is attached to another interface the rate-limit hierarchy is replicated, with no rate limits shared between attachments. Hierarchical rate-limits are only applied at forwarding interfaces because they provide the most accurate classification of packets.

You can configure rate-limit hierarchies by defining a hierarchy of policy classifier and parent groups, each with a rate limit. This hierarchy applies to the packet flow on one interface attachment for the policy. Each policy attachment creates its own copy of the rate-limit hierarchy. There are no shared rate limits across interface attachments.

A policy-based rate-limit hierarchy consists of classifier groups with an aggregate node policy object.Aggregate nodes create theinterior nodesof a policy-based hierarchy; they are not classifier groups and the only policy rule applicable to them is the rate limit rule. Every classifier group or aggregate node can select another aggregate node as its parent. The policy manager ensures that these choices always result in a hierarchy. Not every classifier group witha parentaggregate node musthave a rate limit rule; multiple classifier groups can share a common parent group, which may have a rate limit rule.

A policy imposes a limit of three parent groups that can be traversed from any classifier group. However, the total number of parent groups in one policy can be up to 512, but every packet must pass through no more than three parent groups at any point.

In a hierarchy of rate limits, a rate limit can be color-blind or color-aware; color-blind rate limits run the same algorithm for all packets, regardless of their color. Color-aware rate limits can change the algorithm used, depending on the color of the incoming packet (possibly set in the previousrate limitor anearlier policy, such asa VLANpolicy oningress or an IP policy). The color mark profile action changes the ToS field for the packet, depending on packet type (EXP for MPLS, DSCP or ToS for IPv4), and transmits the packet. If the mark action uses a color-mark profile, the ToS values marked can depend on the color of the packet.

Hierarchical Rate-Limit Profiles

Hierarchical rate-limit profiles are independent from interface types. You can apply the green, yellow, or red mark values to the rate-limit profile for every type of forwarding interface that accepts ToS marking for packets. The same rate limit can be reused for a different interface type. Hierarchical rate limits have two-rate or TCP-friendly rate types.

The value applied to the ToS field is configured in the CLACL group for green, yellow, or red packets but the coloring of the packet as green, yellow, or red depends on the entire rate-limit hierarchy.

•

Preferred packets are transmitted unconditionally. Rate limits that process packets transmitted unconditionally always decrement their token count, if necessary, making it negative.

•

Red packets cannot betransmittedunconditionally, to avoid cases where an aggregate rate limit is oversubscribed with transmit-unconditional rates.

Page 85

•

Color-aware uses the incoming packet color in its algorithm

•

Not promoting packets means that if the packet enters the rate limit as yellow and the rate-limit then determines that it is green, the packet remains yellow. If the rate limit determines it is red, then the packet is colored red.

A rate-limit rule is an instance of a rate-limit profile. The same profile can be used to create many rate-limit rules in the same hierarchy or in different rate-limit hierarchies. The classifier group that defines the flow can use a mark rule with color-mark profile to set the packet ToS field based on the packet color. A rate-limit hierarchy invoked from the classifier group is one way of changing the packet color; the rate-limit hierarchy is invoked before the classifier group runs the mark rule to set the packet ToS.

Hierarchical Rate-Limit Actions

Every packet traversing a rate-limit hierarchy has an owner that is defined by the last rate limit that can apply its actions to the packet; this is a configuration option.

A rate limit in the hierarchy that does not own the packet only decrements its tokens, but cannot perform any of the following actions:

Chapter 5: Creating Rate-Limit Profiles

•

Transfer ownership of the packet to the next rate limit.

•

Retain ownership of the packet but consume tokens from the remaining rate limits in the hierarchy.

•

Exit the rate-limit hierarchy, making that rate limit the final one for the packet.

These actions becomethe sameaction ifthe hierarchy has only oneratelimit. Combining these actions with the additional choices to transmit or drop packets results in the following possible actions:

•

Drop—Drops the packet at that rate limit in the hierarchy. The packet does not change the state of any rate limit further down the hierarchy.

•

Transmit final—Sets the packet color and ends the packet's traversal of the rate-limit hierarchy at the current rate limit. The packet is forwarded and the rate limits further down the hierarchy are not affected. Because transmit final is based on the result of the rate limit, transmit is not an attribute of the node in the rate-limit hierarchy. Committed packets can exit the hierarchy while conformed and exceeded packets continue to the next rate limit.

•

Transmit conditional—Sets the packet color to the result calculated by the rate limit and forwards the packetto the nextratelimit for processing, also transferring ownership of the packet to the next rate limit. The next rate limit can then set the packet color according to the state of its token buckets and apply its actions to the packet. The transmit conditional option is the same as connecting the two rate limits in series.

•

Transmit unconditional—Sets the packet color to the result calculated bythe rate limit, retains ownership of the packet, and forwards the packet to the next rate limit. Later rate limits only decrement their current token counts by the packet length but do not otherwise affect the packet, either by changing its color or applying their actions to it. Although the packet is not affected, the remaining rate limits change because the

Page 86

JunosE 11.3.x Policy Management Configuration Guide

token counts are reduced, making them more likely to make other packets conformed or exceeded. Transmit unconditional is not allowed as an exceeded action.

After the transmit-unconditional completes, the packet traverses to the end of the hierarchy. Because ownership of the packet has been retained, no rate limit further down can apply its actions to it. Some of the later rate limits might already have very low token counts, which must still be decremented when processing a transmit-unconditional packet (if necessary, by making the token count negative). Negative token counts enable the remaining rate limits to restrict the total traffic through them to their peak rate (over a large enough averaging interval, which is a function of rates and burst sizes only). Transmit unconditional packets traversing the rate-limit hierarchy reduce the number of tokens available for other packets.

A rate limit has one of the four preceding actions configured for each possible result: committed, conformed, and exceeded. (Transmit unconditional is not allowed as an exceeded action.) The action taken depends only on the result of that rate limit, its rates, burst sizes, andcurrent token state.In addition, therate limitassigns a color to the packet, depending on both the result of the rate limit and the packet's incoming color. The final color after a packet has finished traversing a rate-limit hierarchy is a function of all the rate limits that owned the packet.

Policy actions are processed in the following order:

1. log

2. filter

3. traffic class

4. user packet class

5. next hop

6. rate limit

7. color status

8. color action

9. parent group

10. mark

The mark action is the last action that occurs, after parent-group, so that the color-mark profile can mark the packet with the final color from the hierarchy.

NOTE: To avoid saturation when using dual token buckets, the total amount

of yellow transmit unconditional traffic should be less than the peak rate minus the committed rate; the green transmit unconditional traffic should be less than the committed rate.

Page 87

Chapter 5: Creating Rate-Limit Profiles

Example: Multiple Flows Sharing Preferred Bandwidth Rate-Limiting Hierarchical Policy

Figure 2on page 63 shows an interface with an attached policythat has a Video classifier that singles out a substream of the packets flowing onthat interface. The Video classifier can be allocated 6 Mbps out of the 10 Mbps interface rate. All other packets on the interface are Internet. The common rate limit cannot drop Video packets, but must limit the total flow (Video and Internet) to under 10 Mbps. Internet traffic can use the Video bandwidth when there are no active Video calls, while avoiding hard partitioning of interface bandwidth.

NOTE: To avoid rate-limit saturation, we recommend that you set the rate

limit profile to color-aware when the rate limit is set to receive transmit conditional.

Figure 2: Multiple Flows Sharing Preferred Bandwidth

host1(config)#rate-limit-profile video two-rate hierarchical host1(config-rate-limit-profile)#committed-action transmit unconditional host1(config-rate-limit-profile)#conformed-action transmit unconditional host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#peak-rate 60000000 host1(config-rate-limit-profile)#exit host1(config)#rate-limit-profile common two-rate hierarchical host1(config-rate-limit-profile)# color-aware host1(config-rate-limit-profile)#committed-action transmit conditional host1(config-rate-limit-profile)#conformed-action transmit conditional host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#peak-rate 100000000 host1(config-rate-limit-profile)#exit host1(config)#policy-list mycompany host1(config-policy-list)#classifier-group video parent-group all host1(config-policy-list-classifier-group)#rate-limit-profile video host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group * parent-group all host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#parent-group all host1(config-policy-list-parent-group)#rate-limit-profile common host1(config-policy-list-parent-group)#exit

In this example, the rate limit Common is color-aware, using the color of the incoming packets instead of setting them to Green. This causes the rate limit Preferred to send 6 Mbps of yellow, transmit unconditional packets. The rate limit Common counts the packets against the yellow token bucket, which has a rate of 10 Mbps. However, if the rate limit Common is color-blind, it treats all packets as Green so the green token bucket gets 6 Mbps of transmit unconditional traffic, which eventually causes all packets to be saturated and dropped.

Page 88

JunosE 11.3.x Policy Management Configuration Guide

Example: Multiple Flows Sharing a Rate Limit Hierarchical Policy

Figure 3 on page 64 shows an interface that has one rate limit and three classified flows, A, B, and C. The combined traffic for A, B, and C must be below a peak rate of 4 Mbps, but each individual flow can burst up to that amount. Statistics can be collected separately on A, B, and C, while limiting only the aggregate of all three. None of the flows has any preference in accessing the rate limit, and the rate limit is shared on a first-come first-serve basis.

Figure 3: Multiple Packet Flows Sharing a Rate Limit

This example uses committed and conformed actions for a preferred rate limit profile so that the common rate limit drops only exceeded packets (those packets that raise the traffic load above 4 Mbps); packets below 4 Mbps are transmitted. By specifying classifier-group * parent-group all, all packets are sent to the parent group. There is no individual rate limit so that those packet use any available, unused bandwidth in the parent group rate limit.

host1(config)#rate-limit-profile All two-rate hierarchical host1(config-rate-limit-profile)#committed-action transmit conditional host1(config-rate-limit-profile)#conformed-action transmit conditional host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#peak-rate 40000000 host1(config-rate-limit-profile)#exit host1(config)#policy-list rlpshare host1(config-policy-list)#classifier-group A parent-group All host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group B parent-group All host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group C parent-group All host1(config-policy-list-classifier-group)#forward host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#parent-group All host1(config-policy-list-parent-group)#rate-limit-profile All host1(config-policy-list-parent-group)#exit

Page 89

Chapter 5: Creating Rate-Limit Profiles

Example: Shared Pool of Additional Bandwidth with Select Flows Rate-Limiting Hierarchical Policy

Figure 4 on page 65 shows three classified flows, A, B, and C, each of which has an individual rate limit with a peak rate of 1 Mbps. If flow A is exceeding its peak rate, rather than drop the packet, the flow tries to use any bandwidth left in a shared rate limit (extrabw) of peak rate of 2 Mbps. The packet is dropped only if both the individual and the shared rate limit have no bandwidth left.

The total flow is limited to 5 Mbps, which is the sum of all the individual peak rates plus the peakrate ofthe sharedrate limit.Individual flows A, B, and C are limitedto a maximum of 3 Mbps (1 Mbps from its individual rate limit and up to 2 Mbps if it can consume the entire shared pool); however, it cannotgo below a1 Mbpsratebecause of the other flows. A shared rate limit enables many flows to share the extra bandwidth dynamically.

Figure 4: Shared Pool of Additional Bandwidth with Select Flows

This example uses transmit final so thatthose packets do not pass through the common rate limit. Transmit final also indicates that there is no shared maximum. If the packets are committed or conformed, they do not need to borrow extra bandwidth or subtract tokens from it. The example uses exceeded action transmit conditional so that packets above the individual rate-limit maximum are not dropped but sent to the next rate limit in the hierarchy. Because this is transmit conditional, ownership of the packet also transfers so the common rate limit can drop these packets if it has no bandwidth left.

host1(config)#rate-limit-profile indiv two-rate hierarchical host1(config-rate-limit-profile)#committed-action transmit final

Page 90

JunosE 11.3.x Policy Management Configuration Guide

host1(config-rate-limit-profile)#conformed-action transmit final host1(config-rate-limit-profile)#exceeded-action transmit conditional host1(config-rate-limit-profile)#peak-rate 10000000 host1(config-rate-limit-profile)#exit host1(config)#rate-limit-profile extrabw two-rate hierarchical host1(config-rate-limit-profile)#committed-action transmit conditional host1(config-rate-limit-profile)#conformed-action transmit conditional host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#peak-rate 20000000 host1(config-rate-limit-profile)#exit host1(config)#policy-list mypolicy host1(config-policy-list)#classifier-group A parent-group extrabw host1(config-policy-list-classifier-group)#rate-limit-profile indiv host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group B parent-group extrabw host1(config-policy-list-classifier-group)#rate-limit-profile indiv host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group C parent-group extrabw host1(config-policy-list-classifier-group)#rate-limit-profile indiv host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#parent-group extrabw host1(config-policy-list-parent-group)#rate-limit-profile extrabw host1(config-policy-list-parent-group)#exit

Example: Aggregate Marking with Oversubscription Rate-Limiting Hierarchical Policy

Figure 5 on page 67 shows an aggregate rate limit that enables up to 2 Mbps of traffic to be sent with a ToS value marked as 10. Traffic above that rate is sent with a ToS value marked as 20 or 30 (depending on packet type) and traffic above 6 Mbps is dropped. The 2 Mbps of traffic with the ToS value of 10 is oversubscribed among individual flows A, B, and C, each of which can have up to 1 Mbps of traffic with the ToS value of 10. An individual flow can mark a packet with the ToS value of 10, but if there is insufficient bandwidth at the shared rate limit because of oversubscription, the packet is demoted and remarked.

The demoted packets from flow A are marked with the ToS value of 20 but the demoted packets from flows B and C are marked with the ToS value of 30. The shared rate limit determines whether to demote thepacket, in whichcaseeach individual rate limit selects the new ToS marking. Individual flows are not required to mark demoted packets with the same value.

The committed and conformed actions are transmit conditional so that all packets also go through rate limit S, because rate limit S imposes the limit of 2 Mbps of traffic with a ToS value of 10 (total across A, B, and C).

Committed packets are transmitted conditionally to rate limit S, which has a peak rate of 6 Mbps and a committed rate of 2 Mbps; these packets can be demoted by S to Y (yellow), in which case they are remarked with the ToS value of 20 or 30. If S leaves them as G (green), they are marked with the ToS value of 10. All conformed packets from A, B, and C are also transmitted conditionally to S but arrive as Y because rate limits do not promote packets in color. S is color-aware so these Y packets do not take away G tokens, leaving them reserved only for the G packets coming from A, B, and C.

Page 91

Rate-limits for A, B, C:

Packets under 1 Mbps marked TOS1 Packets between 1-2 Mbps marked with ToS value 20 (A only) or ToS value 30 (B, C) All packets sent to rate limit S for check for ToS value 10

Rate-limit S:

Receives packets from A, B, C Packets under 2 Mbps are not affected Drops packets that exceed 6 Mbps rate Demotes packets over 2 Mbps

Configuration:

Peak Rate: 6 Mbps Committed rate: 2 Mbps Committed action: transmit Conformed action: transmit Exceeded action: drop Color-aware

Configuration A

Peak Rate: 2 Mbps Committed rate: 1 Mbps Committed action: transmit conditional Conformed action: transmit conditional Exceeded action: drop G mark: TOS value 10 Y mark: TOS value 20 R mark: TOS value 20

Configuration B, C

g016526

Chapter 5: Creating Rate-Limit Profiles

Figure 5: Aggregate Marking with Oversubscription

host1(config)#rate-limit-profile indiv two-rate hierarchical host1(config-rate-limit-profile)#committed-action transmit conditional host1(config-rate-limit-profile)#conformed-action transmit conditional host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#committed-rate 10000000 host1(config-rate-limit-profile)#peak-rate 20000000 host1(config-rate-limit-profile)#exit host1(config)#rate-limit-profile S two-rate hierarchical host1(config-rate-limit-profile)#committed-action transmit conditional host1(config-rate-limit-profile)#conformed-action transmit conditional host1(config-rate-limit-profile)#exceeded-action drop host1(config-rate-limit-profile)#committed-rate 20000000 host1(config-rate-limit-profile)#peak-rate 60000000 host1(config-rate-limit-profile)#color-aware host1(config-rate-limit-profile)#exit host1(config)#ip color-mark-profile A host1(config-color-mark-profile)#green-mark 10 host1(config-color-mark-profile)#yellow-mark 20 host1(config-color-mark-profile)#red-mark 20 host1(config-color-mark-profile)#exit host1(config)#ip color-mark-profile BC host1(config-color-mark-profile)# green-mark 10 host1(config-color-mark-profile)# yellow-mark 30 host1(config-color-mark-profile)# red-mark 30 host1(config-color-mark-profile)# exit host1(config)#policy-list ToS_value_10_oversubsribed host1(config-policy-list)#classifier-group A parent-group S host1(config-policy-list-classifier-group)#rate-limit-profile indiv host1(config-policy-list-classifier-group)#mark profile A host1(config-classifier-group)#exit host1(config-policy-list)#classifier-group B parent-group S

host1(config-policy-list-classifier-group)#rate-limit-profile indiv host1(config-policy-list-classifier-group)#mark profile BC host1(config-classifier-group)#exit

Page 92

JunosE 11.3.x Policy Management Configuration Guide

host1(config-policy-list)#classifier-group C parent-group S host1(config-policy-list-classifier-group)#rate-limit-profile indiv host1(config-policy-list-classifier-group)#mark profile BC host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#parent-group S host1(config-policy-list-parent-group)#rate-limit-profile S host1(config-policy-list-parent-group)#exit

Color-Aware Configuration for Rate-Limiting Hierarchical Policy

Common to manyrate-limithierarchiesis a largeaggregate ratelimit thatreceives packets from manysmaller individual rate limits. An individual rate limit can marka packet yellow but, if few individual flows are active, the aggregate rate limit is likely to try to promote it to green, overriding the individual rate limit. For this reason, rate limits never promote packets in color; color-aware rate limits use the incoming color in their algorithm, but the final result is always equal to or less than the initial packet color.

Rate-limit profiles for rate-limit hierarchies include a non-default configuration option for color-aware. For two-rate rate limits this option enables the color-aware algorithm. If hierarchical, TCP-friendly one-rate rate limits have a color-aware algorithm defined.

In the following color-aware example, the non-preferred packets do not take any green tokens from rate-limit A, leaving them all for preferred packets. Preferred packets may take green and also take yellow tokens (which reduces the flow of non-preferred). In this way the non-preferred packets do not reduce the number of green preferred packets, only the number of yellow preferred packets; preferred packets are then marked from a color-mark profile.

class non-preferred parent A color yellow class preferred parent A mark profile cm parent A rate-limit A !! a color-aware rate limit

The color-mark profile translates the packet color, which is independent of its type, to a type-dependent mark for ToS or EXP and applies it to a packet after it has exited the rate-limit hierarchy. If no translation is configured for a color, then packets of that color are not changed.

Transmit-unconditional packets entering a color-aware rate limit uses the color on the packet for the rate-limit algorithm. Doing this ensures that the color-aware rate limit depletes tokens from the token buckets to account for these packets.

Every packet sent through a rate-limit hierarchy is either dropped inside the hierarchy or emerges with a green, yellow, or red color assigned to it by the rate-limit hierarchy. The color depends on the last rate limit in the hierarchy that owned the packet and all prior rate limits. The green, yellow, or red classification applies to packets of any type and is not interface-type dependent.

A packet that has traversed the hierarchy either has been dropped or emerges with a color (green, yellow or red). This final color can be used by a mark rule with a color-mark profile to select the ToS marking for the packet. Because this operation is interface-type

Page 93

Chapter 5: Creating Rate-Limit Profiles

dependent, the actual value is configured where the packet entered the hierarchy; however, the color is set by the entire rate-limit hierarchy.

We recommend that all rate-limit profiles that receive transmit unconditional packets should be color-aware. If not color-aware, yellow transmit unconditional packets are processed through both the green and yellow token buckets; if the green rate is low, this causes an oversubscription of transmit unconditional packets and leads to saturation. By makingthe ratelimit color-aware, theyellowtransmit unconditional packets ar counted only against the yellow token bucket.

Documentation

color•

• color-aware

• color-mark-profile

• green-mark

• red-mark

• yellow-mark

Percent-Based Rates for Rate-Limit Profiles Overview

Percent-based rate-limit profiles enable you to divide the reference rate as percentages instead of specific values. Youcan specify the reference rateon eachinterface andspecify these rates in terms of percentage of this reference rate within the rate-limit profile to derive the appropriate rate. This enables you to define rate-limit profiles with rates in terms of percentage and bursts in terms of milliseconds.

You can use percent-based rate-limit profiles to:

•

Configure rates in rate-limit profiles based on a percentage of a parameter. You can assign values to these parameters at the time of attachment, which enables you to use the same policy for multiple interfaces with different parameter values.

•

Specify burst sizes in milliseconds when you configure percent-based rate-limits.

•

Provide a generic way to configure and use policy parameters. You can use parameter names when you create policy objects and defer assigning values to these parameters until policyattachment.This enables you to share policyobjects by attaching the same policy at multipleinterfaces with differentparametervalues.You do not haveto specify values each timeyou attach a policy; ifyou donot specifyinterface-specific, thesystem uses the global value.

Policy Parameter Reference-Rate

You can use a policy parameter reference-rate to derive the rates in rate-limit profiles. You can configure rate-limit profiles as a percentage of this parameter. The system calculates the rate at the time of attachment using the value assigned to this parameter for that interface.

Page 94

JunosE 11.3.x Policy Management Configuration Guide

If you do not specify a value for this parameter in Interface Configuration mode, then the Global configuration value is used.

You can modify the value of this parameter in Global Configuration mode or Interface Configuration mode. In Interface Configuration mode, you can change the value using the increase keyword.

If youuse the no versionof the command in Interface Configuration mode, the parameter value is set to the global default value. The no version of the command with the increase keyword decrements the value. The parameter value cannot have a negative value. The no version of the command in Global Configuration mode deletes the parameter if it is not used anywhere else.

Modified values affect the rates in the rate-limit profiles that are using the reference-rate parameter.

NOTE: Beginning with JunosE Release 10.3.x, you cannot modify the policy

reference-rate parameter in Interface Configuration mode, if the percent-based rate-limit profile is used in external parent groups. If you attemptto change the reference-rate parameter that is referencedby multiple classificationoperations using the policy-parameterreference-ratecommand at the interface level, an error message is displayed in the CLI interface. This restriction exists because multipleinterfacesmight refer to the same external parent group resource and to prevent such interfaces from losing their reference to the older external parent group resources. However, you can modify the percent-based rate-limit profiles for external parent groups at the hierarchical rate-limit profile level.

Specifying Rates Within Rate-Limit Profiles

Within a rate-limit profile you can specify the rate either as a percentage or a specific value. In two-rate rate-limit profiles, you can select committed rate and peak rate. You can specify one rate in terms of percentage and another as a specific value. Also, one rate can be a percentage of one parameter and another rate can be a percentage of another parameter.

If the rate in a rate-limit profile is x percent, then the actual rate can be calculated from a parameter value as:

Actual rate (in bits per second) = (parameter value *x)/100

The committed rate can be inthe range 0—100percent of the parameter value. The peak rate can be in the range 0—1000 percent of the parameter value.

The parameter value derives the appropriate rate within the rate-limit profile using a percentage. There are no validations to make the total rate less than or equal to the parameter value.

Page 95

Specifying Burst Sizes

Within a rate-limit profile you can specify the burst size in milliseconds or bytes. Because rate-limit profiles have multiple rates and no restrictions, you can specify one burst in terms of milliseconds and another as bytes whether or not the corresponding rate is a percentage.

If the burst size is m milliseconds, it is calculated as:

Burst size in bytes = (rate in bps * m) / (8*1000)

In this example, the burst size can be in the range 0—10000 ms (10 seconds).

The maximum burst size is 4294967295 bytes (32 bit).

If you do not set the burst size, the system sets the default committed burst and peak burst to 100 ms. If the default burst size is less then 8192, the system changes it to 8192.

Using Service Manager with Merged Policies

Chapter 5: Creating Rate-Limit Profiles

When you usethe Service Manager,you can attachmultiplepolicies to thesame interface point with the merge keyword and these policies are then merged into a new policy. The increase keyword enables you to change the parameter value for the profile.

If you activate the service without the increase keyword, the interface-specific value of the parameter is set to the value specified in the profile. However, if you activate the service with the increase keyword, the interface-specific value ofthe parameter increases by the value specified in the profile. If there was no interface-specific value at the time of activation of the profile with the increase keyword, then it increases from 0.

If you deactivate the service that used the increase keyword, the value of the parameter decreases. But if the profile did not use the increase keyword, deactivation does not change the current interface-specific value for that parameter. The interface-specific parameter remains until the interface is deleted.

Policy Parameter Configuration Considerations

The following list describes the rules for using policy parameters:

•

Policy parameter names must be unique regardless of its type. If you configure a policy parameter with a reference-rate type, then you cannot configure it with another type until it is deleted.

•

You can create policy parameters in Global Configuration mode and in Interface Configuration mode in any order.

•

In Global Configuration mode, you can assign a parameter type to a parameter name and assign a default value for this parameter.

•

If a parameter is configured in Global Configuration mode, but you do not assign a default value, then the system assigns a default value to the parameter. The system default value for any parameter of type reference-rate is 64K (65536).

Page 96

JunosE 11.3.x Policy Management Configuration Guide

•

In InterfaceConfigurationmode, you assigna parameter type and value for an interface. Policy parameters configured in Interface Configurationmode thathave interface-type IP, IPv6, or L2TP specified with the command associate the command with the respective interface in the stack.

•

If a parameter is configured in Interface Configuration mode without configuring it in Global Configuration mode, a global configuration is automatically created for this parameter with the type specified in interface configuration and a system-specified default value.

•

A parameter value specified in Interface Configuration mode overrides the value specified in Global Configuration mode.

•

If the parameter is not configured in Interface Configuration mode, the value from the global configuration is used. If the global value satisfies most of the interfaces, then you do not have to configure parameters for each interface separately, which reduces the number of configuration steps you need to take.

•

When you delete an interface, the interface-specific configuration of the parameter is deleted. However, the global configuration remains until you delete it whether it was created explicitly in Global Configuration mode or automatically created in Interface Configuration mode.

For example, you can configure policy parameter param1 of type reference-rate in Global Configuration mode with a default value of 100000 and then configure it as 200000 in Interface Configuration mode for inf1. If you configure a policy parameter as 500000 in Interface Configurationmode for interfaceinf1, thesystemautomatically creates parameter param2 with a 64K (65536) global default value. When you delete interface inf1, the system deletes the interface-specific configuration for param1 and param2, but the global configuration values of 100000 and 64K (65536) remain until you explicitly delete them.

•

You must create policy parameters in either Global Configuration mode or Interface Configuration mode before they can be used or referenced as policy objects. For example. before you define a rate in a rate-limit profile in terms of percentage of a policy parameter param1, you mustconfigureparam1 as parameter type reference-rate.

•

You can configure multiple policy parameters; there are no restrictions on the number of parameters.

•

If you modify a policy parameter value in Interface Configuration mode, it affects all policies attached to that interface. If a parameter value is changed for an interface, only the input, secondary-input, and output policies attached to that interface are affected by this change.

•

If you modify a policy parameter value in Global Configuration mode, it affects all policies attached to all interfaces that use the global values. For example,if parameter param1 is used in policies attached to two interfaces, but param1 is only configured for interface i1, when you modify the default value for param1 in Global Configuration mode, it affects only the attachment on the second interface i2.

•

You can specify a rate within a rate-limit profile as a percentage of the parameter and burst size in milliseconds. You can use this rate-limit profile in a policy. You can assign values to theseparameters for aninterface. The actual rateand burstsize are calculated

Page 97

at the time of attachment. You can attach the same policy to multiple interfaces with different parameter values.

•

A hierarchical rate-limit profile that contains percentage-based parameters can be used in an external parent-group and the global default values can be changed for each external parent group instance. The following restrictions apply:

•

When you attach policies that reference such same external parent group instances to each interface, you must specify the same reference-rate policy-parameter value.

•

You cannot change the reference-rate policy-parameter values at interface level when a policy attachment to the interface exists.

Policy Parameter Quick Configuration

To configure policing, use the following steps:

1. Configure a policy parameter in Global Configuration mode.

2. Assign the parameter type and global default value to a parameter.

Chapter 5: Creating Rate-Limit Profiles

3. Use this policy parameter in policy objects, create a generic policy, and attach it to

multiple interfaces.

4. Adjust the policy parameter value for a specific interface by configuring it in Interface

Configuration mode for any interface.

Creating Rate-Limit Profiles

Create rate-limit profiles with a rate based on percentage and a burst in milliseconds. The system creates a policy using these rate-limit profiles and then attaches them to different interfaces using different parameter values.

1. Create policy parameter refRlpRate.

host1(config)#policy-parameter refRlpRate reference-rate host1(config-policy-param-reference-rate)#reference-rate 100000 host1(config-policy-param-reference-rate)#exit

2. Create rate-limit profile rlpData.

host1(config)#ip rate-limit-profile rlpData host1(config-rate-limit-profile)#committed-rate refRlpRate percentage 10 host1(config-rate-limit-profile)#committed-burst millisecond 100 host1(config-rate-limit-profile)#peak-rate refRlpRate percentage 100 host1(config-rate-limit-profile)#peak-burst millisecond 150 host1(config-rate-limit-profile)#exit

3. Create rate-limit profile rlpVoice.

host1(config)#ip rate-limit-profile rlpVoice host1(config-rate-limit-profile)#committed-rate 64000 host1(config-rate-limit-profile)#committed-burst 100000 host1(config-rate-limit-profile)#peak-rate refRlpRate percentage 100 host1(config-rate-limit-profile)#peak-burst millisecond 150 host1(config-rate-limit-profile)#exit

Page 98

JunosE 11.3.x Policy Management Configuration Guide

4. Create rate-limit profile rlpVideo.

host1(config)#ip rate-limit-profile rlpVideo host1(config-rate-limit-profile)#committed-rate refRlpRate percentage 70 host1(config-rate-limit-profile)#committed-burst millisecond 100 host1(config-rate-limit-profile)#peak-rate refRlpRate percentage 100 host1(config-rate-limit-profile)#peak-burst millisecond 150 host1(config-rate-limit-profile)#exit

5. Create the policy.

host1(config)#ip policy-list P host1(config-policy)#classifier-group data host1(config-policy-classifier-group)#rate-limit-profile rlpData host1(config-policy-classifier-group)#exit host1(config-policy)#classifier-group voice host1(config-policy-classifier-group)#rate-limit-profile rlpVoice host1(config-policy-classifier-group)#exit host1(config-policy)#classifier-group video host1(config-policy-classifier-group)#rate-limit-profile rlpVideo host1(config-policy-classifier-group)#exit host1(config-policy)#exit

6. Attach IP Policy P at interface atm5/0.1.

host1(config)#interface atm 5/0.1 host1(config-if)#ip policy-parameter reference-rate refRlpRate 1000000 host1(config-if)#ip policy input P

7. Attach IP Policy P at interface atm5/0.2 with merge.

host1(config)#interface atm 5/0.2 host1(config-if)#ip policy input P stats enabled merge

8. Display the policy list.

host1#show policy-list

Policy Table

------ ----IP Policy P Administrative state: enable Reference count: 1 Classifier control list: data, precedence 100 rate-limit-profile rlpData Classifier control list: voice, precedence 100 rate-limit-profile rlpVoice Classifier control list: video, precedence 100 rate-limit-profile rlpVideo

Referenced by interfaces: ATM5/0.1 input policy, statistics disabled, virtual-router default ATM5/0.2 input policy, statistics enabled, virtual-router default

9. Display the rate-limit profiles.

Referenced by profiles: None

Referenced by merge policies: None

Page 99

Chapter 5: Creating Rate-Limit Profiles

host1#show rate-limit-profile

Rate Limit Profile Table

---- ----- ------- ----IP Rate-Limit-Profile: rlpData Profile Type: two-rate Reference count: 1 Committed rate: refRlpRate % 10 Committed burst: 100 milliseconds Peak rate: refRlpRate % 100 Peak burst: 150 milliseconds Mask: 255 Committed rate action: transmit Conformed rate action: transmit Exceeded rate action: drop

IP Rate-Limit-Profile: rlpVoice Profile Type: two-rate Reference count: 1 Committed rate: 64000 Committed burst: 100000 Peak rate: refRlpRate % 100 Peak burst: 150 milliseconds Mask: 255 Committed rate action: transmit Conformed rate action: transmit Exceeded rate action: drop

IP Rate-Limit-Profile: rlpVideo Profile Type: two-rate Reference count: 1 Committed rate: refRlpRate % 70 Committed burst: 100 milliseconds Peak rate: refRlpRate % 100 Peak burst: 150 milliseconds Mask: 255 Committed rate action: transmit Conformed rate action: transmit Exceeded rate action: drop

10. Display policy parameters. If a rate-limit profile uses this parameter twice then it

increases the reference count by 2.

host1#show policy-parameter brief Reference-rate refRlpRate: 100000, 6 references

Display policy parameters host1#show policy-parameter Policy Parameter refRlpRate Type: reference-rate Rate: 100000 Reference count: 6 Referenced by interfaces: 1 references IP interface ATM5/0.1: 1000000

Referenced by rate-limit profiles: 5 references rlpData rlpVoice rlpVideo

11. Display interface atm5/0.1.

Page 100

JunosE 11.3.x Policy Management Configuration Guide

host1#show ip interface atm 5/0.1 ATM5/0.1 line protocol Atm1483 is down, ip is down (ready) Network Protocols: IP Internet address is 1.1.1.1/255.255.255.255 Broadcast address is 255.255.255.255 Operational MTU = 0 Administrative MTU = 0 Operational speed = 100000000 Administrative speed = 0 Discontinuity Time = 0 Router advertisement = disabled Proxy Arp = disabled Network Address Translation is disabled TCP MSS Adjustment = 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 0, Bytes 0 Unicast Packets 0, Bytes 0 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 0, Bytes 0 Unicast Packets 0, Bytes 0 Multicast Routed Packets 0, Bytes 0 Out Scheduler Dropped Packets 0, Bytes 0 Out Policed Packets 0, Bytes 0 Out Discarded Packets 0

IP policy input P Statistics are disabled

12. Display interface atm5/0.2.

host1#show ip interface atm 5/0.2 ATM5/0.2 line protocol Atm1483 is down, ip is down (ready) Network Protocols: IP Internet address is 2.2.2.2/255.255.255.255 Broadcast address is 255.255.255.255 Operational MTU = 0 Administrative MTU = 0 Operational speed = 100000000 Administrative speed = 0 Discontinuity Time = 0 Router advertisement = disabled Proxy Arp = disabled Network Address Translation is disabled TCP MSS Adjustment = 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 0, Bytes 0 Unicast Packets 0, Bytes 0 Multicast Packets 0, Bytes 0

Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - POLICY MANAGEMENT CONFIGURATION GUIDE 2010-10-04, JUNOSE 11.3 Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual