Config Guide Policy

JUNOS® Software

Policy Framework Configuration Guide

Release 9.6

Juniper Networks, Inc.1194 North Mathilda Avenue

Sunnyvale, California 94089

USA

408-745-2000

www.juniper.net

Published: 2009-07-28

This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986-1997, EpilogueTechnology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part of them is in the publicdomain.

This product includes memory allocation software developed by Mark Moraes, copyright © 1988, 1989, 1993, University of Toronto.

This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation and softwareincluded in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright © 1979, 1980, 1983, 1986, 1988,1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.

GateD software copyright © 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed through release 3.0 byCornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’s HELLO routing protocol.Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD software copyright © 1988, Regents of theUniversity of California. All rights reserved. Portions of the GateD software copyright © 1991, D. L. S. Associates.

This product includes software developed by Maker Communications, Inc., copyright © 1996, 1997, Maker Communications, Inc.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc. inthe United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, orregistered 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, orotherwise 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 licensedto 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.

JUNOS® Software Policy Framework Configuration Guide,Release 9.6Copyright © 2009, Juniper Networks, Inc.All rights reserved. Printed in USA.

Writing: Ines Salazar, Fran Singer, Alan Twhigg, Lisa KellyEditing: Nancy KurahashiIllustration: Faith Bradford, Nathaniel WoodwardCover Design: Edmonds Design

Revision HistoryJuly 2009—R1 JUNOS 9.6

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 Software has no known time-related limitations through the year2038. However, the NTP application is known to have some difficulty in the year 2036.

ii ■

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 CUSTOMEROR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO BIND THE CUSTOMER) CONSENT TO BE BOUND BY THISAGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE,AND (B) YOU MAY CONTACT JUNIPER NETWORKS REGARDING LICENSE TERMS.

1. The Parties. The parties to this Agreement are (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or Juniper Networks(Cayman) Limited (if the Customer’s principal office is located outside the Americas) (such applicable entity being referred to herein as “Juniper”), and (ii)the person or organization that originally purchased from Juniper or an authorized Juniper reseller the applicable license(s) for use of the Software (“Customer”)(collectively, the “Parties”).

2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, for which Customerhas paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by Juniper in equipment which Customerpurchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades and new releases of such software. “EmbeddedSoftware” means Software which Juniper has embedded in or loaded onto the Juniper equipment and any updates, upgrades, additions or replacementswhich are subsequently embedded in or loaded onto the equipment.

3. License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer a non-exclusiveand 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 Juniperor 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 Customerhas paid the applicable license fees; provided, however, with respect to the Steel-Belted Radius or Odyssey Access Client software only, Customer shall usesuch Software on a single computer containing a single physical random access memory space and containing any number of processors. Use of theSteel-Belted Radius or IMS AAA software on multiple computers or virtual machines (e.g., Solaris zones) requires multiple licenses, regardless of whethersuch 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 limits toCustomer’s use of the Software. Such limits may restrict use to a maximum number of seats, registered endpoints, 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 Softwareto 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 applicablelicenses.

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. Customermay 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 trialperiod 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 anycommercial 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 applicablelicense(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 shallnot: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized copies of the Software (except asnecessary for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the Software, in any form, to any third party; (d) removeany proprietary notices, labels, or marks on or in any copy of the Software or any product in which the Software is embedded; (e) distribute any copy ofthe Software to any third party, including as may be embedded in Juniper equipment sold in the secondhand market; (f) use any ‘locked’ or key-restrictedfeature, function, service, application, operation, or capability without first purchasing the applicable license(s) and obtaining a valid key from Juniper, evenif such feature, function, service, application, operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniperto any third party; (h) use the Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniperreseller; (i) use Embedded Software on non-Juniper equipment; (j) use Embedded Software (or make it available for use) on Juniper equipment that theCustomer did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of testing or benchmarking of the Software toany 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 furnishsuch records to Juniper and certify its compliance with this Agreement.

■ iii

6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper. As such, Customershall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence, which at a minimum includesrestricting access to the Software to Customer employees and contractors having a 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 inthe 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 statement thataccompanies the Software (the “Warranty Statement”). Nothing in this Agreement shall give rise to any obligation to support the Software. Support servicesmay be purchased separately. Any such support shall be governed by a separate, written support services agreement. TO THE MAXIMUM EXTENT PERMITTEDBY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, OR COSTS OR PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES,OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, THE SOFTWARE, OR ANY JUNIPER ORJUNIPER-SUPPLIED SOFTWARE. IN NO EVENT SHALL JUNIPER BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF ANYJUNIPER 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), INCLUDINGANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES JUNIPERWARRANT 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, whetherin contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid by Customer for the Software that gave rise to the claim, orif the Software is embedded in another Juniper product, the price paid by Customer for such other product. Customer acknowledges and agrees that Juniperhas 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 samereflect 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 licensegranted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related documentation in Customer’spossession 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 ofthe license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction shall be provided to Juniper priorto invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All payments made by Customer shall be net of anyapplicable withholding tax. Customer will provide reasonable assistance to Juniper in connection with such withholding taxes by promptly: providing Juniperwith valid tax receipts and other required documentation showing Customer’s payment of any withholding taxes; completing appropriate applications thatwould 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 relatedto any liability incurred by Juniper as a result of Customer’s non-compliance or delay with its responsibilities herein. Customer’s obligations under thisSection 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 foreignagency 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, orwithout all necessary approvals. Customer shall be liable for any such violations. The version of the Software supplied to Customer may contain encryptionor other capabilities restricting Customer’s ability to export the Software without an export license.

12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use, duplication, or disclosureby 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 interfaceinformation 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 applicableterms and conditions upon which Juniper makes such information available.

14. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier of Juniper whose products or technologyare embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement, and such licensor or vendorshall have the right to enforce this Agreement in its own name as if it were Juniper. In addition, certain third party software may be provided with theSoftware 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 andsubject 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., 1194N. Mathilda Ave., Sunnyvale, CA 94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, anda 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 provisionsof the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes arising under this Agreement, the Partieshereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara County, California. This Agreementconstitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and supersedes all prior and contemporaneous

iv ■

http://www.gnu.org/licenses/gpl.html

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

agreements relating to the Software, whether oral or written (including any inconsistent terms contained in a purchase order), except that the terms of aseparate written agreement executed by an authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflictwith terms contained herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to inwriting 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 theremainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the Parties agree that the Englishversion 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 toutavis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that this Agreement and all related documentation is and will bein the English language)).

■ v

vi ■

Abbreviated Table of Contents

About This Guide xxvii

Part 1 Policy FrameworkChapter 1 Introduction to Policy Framework 3

Part 2 Routing PoliciesChapter 2 Introduction to Routing Policy 15Chapter 3 Routing Policy Configuration Statements 35Chapter 4 Routing Policy Configuration 39Chapter 5 Extended Match Conditions Configuration 97Chapter 6 Extended Actions Configuration 137Chapter 7 Summary of Routing Policy Configuration Statements 155

Part 3 Firewall FiltersChapter 8 Introduction to Firewall Filters 173Chapter 9 Firewall Filter Configuration 177Chapter 10 Policer Overview 253Chapter 11 Policer Configuration 255Chapter 12 Summary of Firewall Filter and Policer Configuration Statements 283

Part 4 Traffic Sampling, Forwarding and MonitoringChapter 13 Traffic Sampling, Forwarding, and Monitoring Overview 305Chapter 14 Introduction to Traffic Sampling Configuration 307Chapter 15 Traffic Forwarding and Monitoring Configuration 321Chapter 16 Extended DHCP Relay Agent Configuration 345Chapter 17 Summary of Traffic Sampling, Forwarding, and Monitoring

Configuration Statements 369

Part 5 IndexesIndex 485Index of Statements and Commands 495

Abbreviated Table of Contents ■ vii

viii ■

JUNOS 9.6 Policy Framework Configuration Guide

Table of Contents

About This Guide xxvii

JUNOS Documentation and Release Notes .................................................xxviiObjectives .................................................................................................xxviiiAudience ...................................................................................................xxviiiSupported Platforms .................................................................................xxviiiUsing the Indexes .......................................................................................xxixUsing the Examples in This Manual ............................................................xxix

Merging a Full Example ........................................................................xxixMerging a Snippet .................................................................................xxx

Documentation Conventions .......................................................................xxxDocumentation Feedback ..........................................................................xxxiiRequesting Technical Support ...................................................................xxxiii

Part 1 Policy Framework

Chapter 1 Introduction to Policy Framework 3

Policy Framework Overview ...........................................................................3Router Flows Affected by Policies ....................................................................3Policy Architecture ..........................................................................................6Control Points .................................................................................................6Policy Components .........................................................................................7Default Policies and Actions ............................................................................8Configuration Tasks .........................................................................................8Policy Configuration Recommendations ..........................................................8Comparison of Routing Policies and Firewall Filters ........................................9

Part 2 Routing Policies

Chapter 2 Introduction to Routing Policy 15

Routing Policy Overview ...............................................................................16Importing and Exporting Routes ...................................................................17Protocols That Can Be Imported To and Exported From the Routing

Table .......................................................................................................18Routing Tables Affected by Routing Policies ..................................................19

Table of Contents ■ ix

Default Routing Policies and Actions .............................................................20Default Import and Export Policies for Protocols ...........................................21Creating Routing Policies ...............................................................................22Configuring a Routing Policy .........................................................................23Routing Policy Match Conditions ...................................................................24Routing Policy Named Match Conditions .......................................................25Routing Policy Actions ...................................................................................25Routing Policy Terms ....................................................................................26Applying Routing Policy ................................................................................26Routing Protocol Support for Import and Export Policy .................................27Protocol Support for Import and Export Policies ...........................................28Applying Routing Policy to Routing Protocols ................................................28Applying Export Policies to the Forwarding Table .........................................29Evaluating a Routing Policy ...........................................................................29How a Routing Policy Is Evaluated ................................................................29How a Routing Policy Chain Is Evaluated ......................................................30How a Routing Policy Expression Is Evaluated ..............................................31How a Routing Policy Subroutine Is Evaluated ..............................................31Routing Policy Tests ......................................................................................33

Chapter 3 Routing Policy Configuration Statements 35

Configuring Routing Policy ............................................................................35Minimum Routing Policy Configuration .........................................................36Minimum Routing Policy Chain Configuration ...............................................36Minimum Subroutine Configuration ..............................................................37

Chapter 4 Routing Policy Configuration 39

Defining Routing Policies ..............................................................................40Configuring Match Conditions in Routing Policy Terms .................................41Configuring Actions in Routing Policy Terms .................................................47

Configuring Flow Control Actions ...........................................................48Configuring Actions That Manipulate Route Characteristics ....................49Configuring the Default Action in Routing Policies ..................................54

Example: Configuring the Default Action in a Routing Policy ............55Configuring a Final Action in Routing Policies .........................................56Logging Matches to a Routing Policy Term .............................................56Configuring Separate Actions for Routes in Route Lists ...........................57

Applying Routing Policies and Policy Chains to Routing Protocols .................57Effect of Omitting Ingress Match Conditions from Export Policies ..........58

Applying Policy Expressions to Routes Exported from Routing Tables ..........59Policy Expression Examples ...................................................................61How a Policy Expression Is Evaluated .....................................................62Example: Evaluating Policy Expressions .................................................63

Applying Routing Policies to the Forwarding Table ........................................64

x ■ Table of Contents


Configuring Dynamic Routing Policies ...........................................................65Configuring Routing Policies and Policy Objects in the Dynamic

Database ..........................................................................................66Configuring Routing Policies Based on Dynamic Database

Configuration ...................................................................................67Applying Dynamic Routing Policies to BGP .............................................68Preventing Reestablishment of BGP Peering Sessions After NSR Routing

Engine Switchover ............................................................................68Example: Configuring a BGP Export Policy That References a Dynamic

Routing Policy ..................................................................................69Forwarding Packets to the Discard Interface .................................................71Testing Routing Policies ................................................................................72

Example: Testing a Routing Policy ..........................................................72Routing Policy Examples ...............................................................................72Example: Defining a Routing Policy from BGP to IS-IS ..................................73Example: Using Routing Policy to Set a Preference .......................................74Example: Importing and Exporting Access and Access-Internal Routes in a

Routing Policy .........................................................................................74Example: Exporting Routes to IS-IS ...............................................................75Example: Applying Export and Import Policies to BGP Peer Groups ..............75Example: Applying a Prefix to Routes Learned from a Peer ..........................76Example: Redistributing BGP Routes with a Specific Community Tag into

IS-IS ........................................................................................................76Example: Redistributing OSPF Routes into BGP ............................................76Example: Exporting Direct Routes Into IS-IS ..................................................77Example: Exporting Internal IS-IS Level 1 Routes to Level 2 ..........................77Example: Exporting IS-IS Level 2 Routes to Level 1 .......................................78Example: Assigning Different Forwarding Next-Hop LSPs to Different

Destination Prefixes ................................................................................78Example: Grouping Destination Prefixes .......................................................79Example: Grouping Source Prefixes ...............................................................80Example: Grouping Source and Destination Prefixes in a Forwarding

Class .......................................................................................................81Example: Accepting Routes with Specific Destination Prefixes ......................82Example: Accepting Routes from BGP with a Specific Destination Prefix ......83Example: Using Routing Policy in an ISP Network .........................................83Requesting a Single Default Route on the Customer 1 Router ........................85Requesting Specific Routes on the Customer 2 Router ..................................86Configuring a Peer Policy on ISP Router 3 .....................................................88Configuring Private and Exchange Peers on ISP Router 1 and 2 ....................90Configuring Locally Defined Static Routes on the Exchange Peer 2

Router .....................................................................................................93Configuring Outbound and Generated Routes on the Private Peer 2

Router .....................................................................................................93

Table of Contents ■ xi

Table of Contents

Chapter 5 Extended Match Conditions Configuration 97

Configuring AS Path Regular Expressions to Use as Routing Policy MatchConditions ..............................................................................................97Configuring AS Path Regular Expressions ...............................................98

Configuring a Null AS Path .............................................................102How AS Path Regular Expressions Are Evaluated ..................................103Examples: Configuring AS Path Regular Expressions ............................103

Overview of BGP Communities and Extended Communities as Routing PolicyMatch Conditions ..................................................................................104

Defining BGP Communities and Extended Communities for Use in RoutingPolicy Match Conditions .......................................................................106Defining BGP Communities for Use in Routing Policy Match

Conditions ......................................................................................106Using UNIX Regular Expressions in Community Names .................107

Defining BGP Extended Communities for Use in Routing Policy MatchConditions ......................................................................................109Examples: Defining BGP Extended Communities ...........................111

Inverting Community Matches ..............................................................111Including BGP Communities and Extended Communities in Routing Policy

Match Conditions ..................................................................................111How BGP Communities and Extended Communities Are Evaluated in Routing

Policy Match Conditions .......................................................................112Using Routing Policies to Prevent Advertisement of BGP Communities to

Neighbors .............................................................................................113Examples: Configuring BGP Communities as Routing Policy Match

Conditions ............................................................................................113Configuring Prefix Lists for Use in Routing Policy Match Conditions ............117

Configuring Prefix Lists .........................................................................118How Prefix Lists Are Evaluated in Routing Policy Match Conditions ......119Configuring Prefix List Filters ................................................................120Example: Configuring a Prefix List ........................................................120

Configuring Route Lists for Use in Routing Policy Match Conditions ............121Configuring Route Lists .........................................................................122How Route Lists Are Evaluated in Routing Policy Match Conditions ......124

How Prefix Order Affects Route List Evaluation ..............................125Common Configuration Problem with the Longest-Match

Lookup .....................................................................................125Route List Examples .............................................................................126

Example: Rejecting Routes with Specific Destination Prefixes andMask Lengths ...........................................................................126

Example: Rejecting Routes with a Mask Length Greater thanEight ........................................................................................127

Example: Rejecting Routes with Mask Length Between 26 and29 ............................................................................................127

Example: Rejecting Routes from Specific Hosts ..............................127Example: Accepting Routes with a Defined Set of Prefixes .............128Example: Rejecting Routes with a Defined Set of Prefixes ..............128Example: Rejecting Routes with Prefixes Longer than 24 Bits ........129

xii ■ Table of Contents


Example: Rejecting PIM Multicast Traffic Joins ...............................129Example: Rejecting PIM Traffic .......................................................130

Configuring Subroutines in Routing Policy Match Conditions ......................130Configuring Subroutines .......................................................................130

Possible Consequences of Termination Actions in Subroutines ......131Example: Configuring a Subroutine .......................................................134

Configuring Routing Policy Match Conditions Based on Routing TableEntries ..................................................................................................134

Chapter 6 Extended Actions Configuration 137

Prepending AS Numbers to BGP AS Paths ...................................................137Adding AS Numbers to BGP AS Paths ..........................................................138Using Routing Policies to Damp BGP Route Flapping ...................................138

Configuring BGP Flap Damping Parameters ..........................................139Specifying BGP Flap Damping as the Action in Routing Policy Terms ....141Disabling Damping for Specific Address Prefixes ..................................142

Example: Disabling Damping for a Specific Address Prefix ............142Example: Configuring BGP Flap Damping .............................................142

Overview of Per-Packet Load Balancing ......................................................144Configuring Per-Packet Load Balancing .......................................................145

Per-Packet Load Balancing Examples ....................................................147Configuring Load Balancing Based on MPLS Labels .....................................147Configuring Load Balancing for Ethernet Pseudowires ................................150Configuring Load Balancing Based on MAC Addresses ................................151Configuring VPLS Load Balancing Based on IP and MPLS Information ........151Configuring VPLS Load Balancing on MX Series Ethernet Services

Routers .................................................................................................153

Chapter 7 Summary of Routing Policy Configuration Statements 155

apply-path ...................................................................................................155as-path ........................................................................................................156as-path-group ..............................................................................................157community ..................................................................................................158condition .....................................................................................................160damping ......................................................................................................161dynamic-db .................................................................................................162export .........................................................................................................163import .........................................................................................................165policy-options ..............................................................................................166policy-statement ..........................................................................................167prefix-list .....................................................................................................169prefix-list-filter .............................................................................................170

Table of Contents ■ xiii

Table of Contents

Part 3 Firewall Filters

Chapter 8 Introduction to Firewall Filters 173

Firewall Filter Overview ..............................................................................173Firewall Filter Components .........................................................................173

Firewall Filter Types ..............................................................................175Supported Standards ...................................................................................176

Chapter 9 Firewall Filter Configuration 177

Configuring Firewall Filters ..........................................................................178Configuring Standard Firewall Filters ...........................................................179

Configuring the Address Family ............................................................179Configuring the Filter Name ..................................................................180Configuring Firewall Filter Terms ..........................................................180How Firewall Filters Are Evaluated .......................................................181

Configuring Match Conditions in Firewall Filter Terms ................................182Configuring Numeric Range Match Conditions ......................................183Configuring IP Address Match Conditions .............................................200Configuring Bit-Field Match Conditions .................................................203Configuring Class-Based Match Conditions ...........................................205Configuring Protocol Match Conditions .................................................206

Example: Ignoring Packet Protocol .................................................207Configuring Match Conditions for Small Packets ...................................207

Configuring Actions in Firewall Filter Terms ................................................208Example: Counting and Sampling Accepted Packets .............................212Example: Setting the DSCP Bit to Zero ..................................................214

Configuring Nested Firewall Filters ..............................................................214Example: Configuring Nested Filters .....................................................215

Applying Firewall Filters to Interfaces ..........................................................216Configuring Interface-Specific Counters ................................................217

Example: Configuring Interface-Specific Counters ..........................217Defining Interface Groups .....................................................................218

Example: Defining Interface Groups ...............................................219Firewall Filter Examples ..............................................................................220Example: Blocking Telnet and SSH Access ..................................................220Example: Blocking TFTP Access ..................................................................221Example: Accepting DHCP Packets with Specific Addresses ........................222Example: Defining a Policer for a Destination Class ....................................222Example: Counting IP Option Packets .........................................................223Example: Accepting OSPF Packets from Certain Addresses .........................224Example: Matching Packets Based on Two Unrelated Criteria .....................224Example: Counting Both Accepted and Rejected Packets ............................225Example: Blocking TCP Connections to a Certain Port Except from BGP

Peers .....................................................................................................225Example: Accepting Packets with Specific IPv6 TCP Flags ...........................226Example: Setting a Rate Limit for Incoming Layer 2 Control Packets ..........227Configuring Service Filters ...........................................................................228

xiv ■ Table of Contents


Configuring Simple Filters ...........................................................................229Example: Configuring a Simple Filter ....................................................230

Configuring Firewall Filters for Logical Systems ...........................................231Guidelines for Firewall Configuration in Logical Systems ......................232

Scenario 1: Firewall Objects Reference Other Firewall Objects .......232Scenario 2: Nonfirewall Objects Reference Firewall Objects ...........233Scenario 3: Firewall Objects Reference Nonfirewall Objects ...........237

Unsupported Configuration Statements, Actions, and ActionModifiers ........................................................................................239

Configuring Accounting for Firewall Filters ..................................................244Configuring Filter-Based Forwarding ...........................................................245

Examples: Configuring Filter-Based Forwarding ....................................246Configuring Forwarding Table Filters ...........................................................247

Overview of Forwarding Table Filters ...................................................247Configuring a Forwarding Table Filter ...................................................248

Configuring System Logging of Firewall Filter Operations ...........................249Example: Configuring Firewall Filter System Logging ............................250

Chapter 10 Policer Overview 253

Chapter 11 Policer Configuration 255

Configuring Policers ....................................................................................255Minimum Policer Configuration ...................................................................256Configuring Policers ....................................................................................257

Configuring Rate Limiting .....................................................................258Configuring Policer Actions ...................................................................259

Example: Configuring a Policer Action ...........................................259Configuring Multifield Classifiers for Policing ...............................................259

Configuring Filter-Specific Policers ........................................................261Configuring Policer Actions for Specific Address Prefixes .....................262

Examples: Configuring Policer Actions for Specific AddressPrefixes ....................................................................................263

Examples: Classifying Traffic ................................................................266Configuring Interface Sets ...........................................................................267Applying Interface Policers ..........................................................................267

Example: Applying an Interface Policer ................................................268Configuring Aggregate Policers ....................................................................268

Example: Configuring an Aggregate Policer ..........................................269Physical Interface Policer Overview .............................................................270Configuring Physical Interface Policers ........................................................270

Configuring Physical Interface Policers .................................................271Configuring Firewall Filters That Reference Physical Interface

Policers ..........................................................................................272Applying Firewall Filters That Reference Physical Interface Policers .....273

Configuring Bandwidth Policers ..................................................................274Example: Configuring a Bandwidth Policer ...........................................274

Table of Contents ■ xv

Table of Contents

Configuring Load-Balance Groups ................................................................275Configuring Tricolor Marking .......................................................................275

Configuring Tricolor Marking Policers ...................................................275Example: Configuring a Tricolor Marking Policer ............................277

Configuring Interface Policers Using Tricolor Marking Policing .............277Example: Rate-Limiting Bandwidth Using Tricolor Marking

Policing ....................................................................................278Examples: Configuring Policing ...................................................................279

Chapter 12 Summary of Firewall Filter and Policer Configuration Statements 283

accounting-profile ........................................................................................283action ..........................................................................................................284family ..........................................................................................................285filter ............................................................................................................286filter-specific ................................................................................................287firewall ........................................................................................................287if-exceeding .................................................................................................288interface-set ................................................................................................289interface-specific .........................................................................................289load-balance-group ......................................................................................290logical-bandwidth-policer ............................................................................290logical-interface-policer ...............................................................................291physical-interface-filter ................................................................................291physical-interface-policer .............................................................................292policer .........................................................................................................293prefix-action ................................................................................................294service-filter ................................................................................................295simple-filter .................................................................................................296term ............................................................................................................297three-color-policer .......................................................................................299

three-color-policer (Applying) ................................................................299three-color-policer (Configuring) ...........................................................300

virtual-channel ............................................................................................301

Part 4 Traffic Sampling, Forwarding and Monitoring

Chapter 13 Traffic Sampling, Forwarding, and Monitoring Overview 305

Chapter 14 Introduction to Traffic Sampling Configuration 307

Traffic Sampling Configuration ....................................................................307Minimum Traffic Sampling Configuration ....................................................308Configuring Traffic Sampling .......................................................................309Disabling Traffic Sampling ...........................................................................311Configuring the Output File for Traffic Sampling .........................................311

Traffic Sampling Output Format ...........................................................312

xvi ■ Table of Contents


Tracing Traffic Sampling Operations ...........................................................313Configuring Flow Aggregation (cflowd) ........................................................313

Debugging cflowd Flow Aggregation .....................................................315Configuring Active Flow Monitoring Using Version 9 ...................................316

Example: Configuring Active Flow Monitoring Using Version 9 .............317Traffic Sampling Examples ..........................................................................317Example: Sampling a Single SONET/SDH Interface .....................................317Example: Sampling All Traffic from a Single IP Address ..............................318Example: Sampling All FTP Traffic ..............................................................319

Chapter 15 Traffic Forwarding and Monitoring Configuration 321

Configuring Traffic Forwarding and Monitoring ...........................................321Applying Filters to Forwarding Tables .........................................................325Configuring IPv6 Accounting .......................................................................326Configuring Discard Accounting ..................................................................326Configuring Flow Monitoring .......................................................................328Configuring Next-Hop Groups ......................................................................329Per-Flow and Per-Prefix Load Balancing Overview ......................................329Configuring Per-Prefix Load Balancing ........................................................330Configuring Per-Flow Load Balancing Based on Hash Values .......................331Configuring Routers and Interfaces as DHCP and BOOTP Relay Agents ......331Configuring DNS and TFTP Packet Forwarding ............................................333

Tracing BOOTP, DNS, and TFTP Forwarding Operations ......................334Configuring the Log Filename .........................................................335Configuring the Number and Size of Log Files ................................335Configuring Access to the Log File ..................................................335Configuring a Regular Expression for Lines to Be Logged ...............336

Example: Configuring DNS Packet Forwarding .....................................336Preventing DHCP Spoofing on MX Series Ethernet Services Routers ...........336Configuring Port Mirroring ..........................................................................337

Configuration Guidelines .......................................................................338Configuring Port Mirroring ....................................................................339

Configuring the Port-Mirroring Address Family and Interface .........339Configuring Multiple Port-Mirroring Instances .......................................339

Configuring Port-Mirroring Instances ..............................................340Associating a Port-Mirroring Instance on M320 Routers .................340Associating a Port-Mirroring Instance on M120 Routers .................341Configuring MX Series Ethernet Services Routers and M120 Routers

to Mirror Traffic Only Once ......................................................341Configuring Packet Capture .........................................................................341

Chapter 16 Extended DHCP Relay Agent Configuration 345

Extended DHCP Agent Overview ................................................................345Interaction Between the DHCP Relay Agent, Clients, and Servers ...............346

Table of Contents ■ xvii

Table of Contents

Access and Access-Internal Routes ..............................................................347Graceful Routing Engine Switchover ............................................................347Configuring the Extended DHCP Agent .......................................................348Overriding the Default Configuration for the Extended DHCP Relay

Agent ....................................................................................................350Overwriting giaddr Information ............................................................351Overriding Option 82 Information ........................................................351Using Layer 2 Unicast Transmission for DHCP Packets .........................351Trusting Option 82 Information ............................................................352Disabling DHCP Relay ...........................................................................352

Using Option 60 Information to Forward Client Traffic to Specific DHCPServers ..................................................................................................352Using Matching Option 60 Strings to Process DHCP Client Traffic ........352Using Nonmatching Option 60 Strings to Process DHCP Client

Traffic .............................................................................................354Displaying a Count of Discarded DHCP Packets with Option 60

Information ....................................................................................354Enabling and Disabling Insertion of Option 82 Information ........................354

Configuring Agent-Circuit-Id Information ..............................................355Configuring an Option 82 Prefix ...........................................................355

Configuring Server Groups ..........................................................................357Configuring Active Server Groups ................................................................357Grouping Interfaces with Common DHCP Relay Configuration ....................358

Configuring Group-Specific DHCP Relay Options ..................................359Enabling the DHCP Relay Agent on Specified Interfaces .......................359

Using External AAA Authentication Services with the Extended DHCP RelayAgent ....................................................................................................359

Verifying and Managing Clients of the Extended DHCP Relay Agent ...........360Tracing Extended DHCP Relay Agent Operations ........................................360

Configuring the Extended DHCP Relay Agent Log Filename .................361Configuring the Number and Size of Extended DHCP Relay Agent Log

Files ................................................................................................362Configuring Access to the Extended DHCP Relay Agent Log File ...........362Configuring a Regular Expression for Extended DHCP Relay Agent Lines

to Be Logged ..................................................................................362Configuring the Extended DHCP Relay Agent Tracing Flags ..................363

Example: Minimum DHCP Relay Agent Configuration .................................363Example: DHCP Relay Agent Configuration with Multiple Clients and

Servers ..................................................................................................364Example: Using Option 60 Strings to Forward DHCP Client Traffic .............365Example: Using Option 60 Strings to Drop DHCP Client Traffic ...................366

Chapter 17 Summary of Traffic Sampling, Forwarding, and MonitoringConfiguration Statements 369

accounting ...................................................................................................370active-server-group ......................................................................................371aggregation .................................................................................................372always-write-giaddr .....................................................................................373always-write-option-82 ................................................................................374

xviii ■ Table of Contents


authentication .............................................................................................375autonomous-system-type ............................................................................376bootp ...........................................................................................................377cflowd .........................................................................................................378

cflowd (Discard Accounting) .................................................................378cflowd (Flow Monitoring) ......................................................................379cflowd (Sampling) .................................................................................380

circuit-id ......................................................................................................381circuit-type ..................................................................................................382client-response-ttl ........................................................................................382default-local-server-group ............................................................................383default-relay-server-group ............................................................................384delimiter ......................................................................................................385description ..................................................................................................386dhcp-relay ...................................................................................................387

dhcp-relay (Extended DHCP Relay Agent) .............................................388dhcp-relay (DHCP Spoofing Prevention) ................................................391

disable .........................................................................................................391disable-relay ................................................................................................392domain ........................................................................................................393domain-name ..............................................................................................394drop ............................................................................................................395export-format ..............................................................................................396family ..........................................................................................................397

family (Filtering) ...................................................................................397family (Monitoring) ...............................................................................398family (Port Mirroring) ..........................................................................399family (Sampling) ..................................................................................400

family inet ...................................................................................................400family mpls .................................................................................................401family multiservice ......................................................................................403file ...............................................................................................................405

file (Extended DHCP Relay Agent and Helpers Trace Options) ..............405file (Packet Capture) ..............................................................................405file (Sampling) .......................................................................................406file (Trace Options) ...............................................................................406

filename ......................................................................................................407filename (Packet Capture) .....................................................................407filename (Sampling) ..............................................................................407

files .............................................................................................................408files (Packet Capture) ............................................................................408files (Sampling and Traceoptions) .........................................................408

filter ............................................................................................................409filter (IPv4, IPv6, and MPLS) .................................................................409filter (VPLS) ...........................................................................................409

flood ............................................................................................................410flow-active-timeout ......................................................................................410flow-export-destination ...............................................................................411flow-inactive-timeout ...................................................................................411forwarding-options ......................................................................................412

Table of Contents ■ xix

Table of Contents

group ...........................................................................................................413group (DHCP Relay Agent) ....................................................................414group (DHCP Spoofing Prevention) .......................................................415

hash-key ......................................................................................................416helpers ........................................................................................................419indexed-next-hop ........................................................................................420input ...........................................................................................................421

input (Forwarding Table) .......................................................................421input (Port Mirroring) ............................................................................421input (Sampling) ...................................................................................422

instance .......................................................................................................423interface ......................................................................................................424

interface (Accounting or Sampling) .......................................................424interface (BOOTP) .................................................................................425interface (DHCP Spoofing Prevention) ..................................................426interface (DNS and TFTP Packet Forwarding or Relay Agent) ...............426interface (Extended DHCP Relay Agent) ...............................................427interface (Monitoring) ...........................................................................428interface (Next-Hop Group) ...................................................................428interface (Port Mirroring) ......................................................................429

layer2-unicast-replies ...................................................................................429load-balance ................................................................................................430local-dump ..................................................................................................431local-server-group ........................................................................................432logical-system-name ....................................................................................433mac-address ................................................................................................434max-packets-per-second ..............................................................................434maximum-capture-size ................................................................................435maximum-hop-count ...................................................................................435maximum-packet-length .............................................................................436minimum-wait-time ....................................................................................436mirror-once .................................................................................................437monitoring ..................................................................................................438next-hop ......................................................................................................439next-hop-group ............................................................................................440no-filter-check .............................................................................................441no-listen ......................................................................................................441no-local-dump .............................................................................................441no-stamp .....................................................................................................441no-world-readable .......................................................................................442option-60 .....................................................................................................442option-82 .....................................................................................................443output .........................................................................................................444

output (Accounting) ..............................................................................444output (Forwarding Table) .....................................................................445output (Monitoring) ...............................................................................445output (Port Mirroring) ..........................................................................446output (Sampling) .................................................................................447

overrides .....................................................................................................448packet-capture .............................................................................................449password .....................................................................................................450

xx ■ Table of Contents


per-flow .......................................................................................................451per-prefix ....................................................................................................452port .............................................................................................................452port-mirroring .............................................................................................453prefix ..........................................................................................................455rate .............................................................................................................456relay-option-60 ............................................................................................457relay-option-82 ............................................................................................458relay-server-group .......................................................................................459replace-ip-source-with .................................................................................460route-accounting .........................................................................................460routing-instance-name .................................................................................461run-length ....................................................................................................462sampling .....................................................................................................463server ..........................................................................................................465

server (DHCP and BOOTP Relay Agent) ................................................465server (DNS and TFTP Service) .............................................................466

server-group ................................................................................................467size ..............................................................................................................468

size (Packet Capture) ............................................................................468size (Sampling and Traceoptions) .........................................................469

stamp ..........................................................................................................469tftp ..............................................................................................................470traceoptions ................................................................................................471

traceoptions (DNS and TFTP Packet Forwarding) ..................................472traceoptions (Extended DHCP Relay Agent) ..........................................474traceoptions (Port Mirroring and Traffic Sampling) ...............................476

trust-option-82 ............................................................................................476user-prefix ...................................................................................................477username-include ........................................................................................478vendor-option ..............................................................................................479version ........................................................................................................480version9 ......................................................................................................481world-readable ............................................................................................481

Part 5 Indexes

Index ...........................................................................................................485Index of Statements and Commands ..........................................................495

Table of Contents ■ xxi

Table of Contents

xxii ■ Table of Contents


List of Figures


Figure 1: Flows of Routing Information and Packets .......................................4Figure 2: Routing Policies to Control Routing Information Flow ......................5Figure 3: Firewall Filters to Control Packet Flow ..............................................6Figure 4: Policy Control Points ........................................................................7

Part 2 Routing PoliciesChapter 2 Introduction to Routing Policy 15

Figure 5: Importing and Exporting Routes .....................................................17Figure 6: Importing and Exporting Routing Policies .......................................23Figure 7: Routing Policy Components ............................................................23Figure 8: Routing Policy Evaluation ...............................................................30Figure 9: Routing Policy Chain Evaluation .....................................................31Figure 10: Routing Policy Subroutine Evaluation ...........................................33

Chapter 4 Routing Policy Configuration 39Figure 11: ISP Network Example ...................................................................84

Part 3 Firewall FiltersChapter 11 Policer Configuration 255

Figure 12: Incoming and Outgoing Interface Policers ..................................268

Part 4 Traffic Sampling, Forwarding and MonitoringChapter 14 Introduction to Traffic Sampling Configuration 307

Figure 13: Configure Sampling Rate ............................................................310

List of Figures ■ xxiii

xxiv ■ List of Figures


List of Tables

About This Guide xxviiTable 1: Notice Icons ..................................................................................xxxiTable 2: Text and Syntax Conventions .......................................................xxxi


Table 3: Purpose of Routing Policies and Firewall Filters .................................9Table 4: Implementation Differences Between Routing Policies and Firewall

Filters ........................................................................................................9

Part 2 Routing PoliciesChapter 2 Introduction to Routing Policy 15

Table 5: Protocols That Can Be Imported To and Exported From the RoutingTable .......................................................................................................18

Table 6: Routing Tables Affected by Routing Policies ....................................19Table 7: Default Import and Export Policies for Protocols .............................21Table 8: Match Conditions .............................................................................24Table 9: Protocol Support for Import and Export Policies ..............................28

Chapter 4 Routing Policy Configuration 39Table 10: Routing Policy Match Conditions ...................................................42Table 11: Flow Control Actions ......................................................................49Table 12: Actions That Manipulate Route Characteristics ...............................49Table 13: Policy Action Conversion Values ....................................................60Table 14: Policy Expression Logical Operators ..............................................60

Chapter 5 Extended Match Conditions Configuration 97Table 15: AS Path Regular Expression Operators ........................................100Table 16: Examples of AS Path Regular Expressions ...................................100Table 17: Community Attribute Regular Expression Operators ....................108Table 18: Examples of Community Attribute Regular Expressions ..............109Table 19: Prefix List and Route List Differences ..........................................118Table 20: Route List Match Types for a Prefix List Filter ..............................120Table 21: Route List Match Types for a Prefix List .......................................123Table 22: Match Type Examples ..................................................................123

Chapter 6 Extended Actions Configuration 137Table 23: Damping Parameters ...................................................................140

List of Tables ■ xxv

Part 3 Firewall FiltersChapter 9 Firewall Filter Configuration 177

Table 24: IPv4 Firewall Filter Match Conditions ...........................................185Table 25: IPv6 Firewall Filter Match Conditions ...........................................189Table 26: VPLS Firewall Filter Match Conditions ..........................................192Table 27: MPLS Firewall Filter Match Conditions .........................................196Table 28: Protocol-Independent Firewall Filter Match Conditions ................196Table 29: Layer 2 Circuit Cross-Connect Firewall Filter Match Conditions ....197Table 30: Layer 2 Bridging Firewall Filter Match Conditions (MX Series

Ethernet Services Routers Only) ............................................................197Table 31: Address Firewall Filter Match Conditions .....................................201Table 32: Bit-Field Firewall Filter Match Conditions .....................................204Table 33: Bit-Field Logical Operators ...........................................................205Table 34: Firewall Filter Actions and Action Modifiers .................................210Table 35: Unsupported Firewall Statements for Logical Systems .................239Table 36: Unsupported Firewall Actions and Action Modifiers for Logical

Systems ................................................................................................240

xxvi ■ List of Tables


About This Guide

This preface provides the following guidelines for using the JUNOS® Software PolicyFramework Configuration Guide:

■ JUNOS Documentation and Release Notes on page xxvii

■ Objectives on page xxviii

■ Audience on page xxviii

■ Supported Platforms on page xxviii

■ Using the Indexes on page xxix

■ Using the Examples in This Manual on page xxix

■ Documentation Conventions on page xxx

■ Documentation Feedback on page xxxii

■ Requesting Technical Support on page xxxiii

JUNOS Documentation and Release Notes

For a list of related JUNOS documentation, seehttp://www.juniper.net/techpubs/software/junos/.

If the information in the latest release notes differs from the information in thedocumentation, follow the JUNOS Software Release Notes.

To obtain the most current version of all Juniper Networks® technical documentation,see the product documentation page on the Juniper Networks website athttp://www.juniper.net/techpubs/.

Juniper Networks supports a technical book program to publish books by JuniperNetworks engineers and subject matter experts with book publishers around theworld. These books go beyond the technical documentation to explore the nuancesof network architecture, deployment, and administration using JUNOS Software andJuniper Networks devices. In addition, the Juniper Networks Technical Library,published in conjunction with O'Reilly Media, explores improving network security,reliability, and availability using JUNOS configuration techniques. All the books arefor sale at technical bookstores and book outlets around the world. The current listcan be viewed at http://www.juniper.net/books.

JUNOS Documentation and Release Notes ■ xxvii

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

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

http://www.juniper.net/books

Objectives

This guide is designed for network administrators who are configuring and monitoringa Juniper Networks J Series Services Routers, M Series Multiservice Edge Routers,MX Series Ethernet Services Routers, or T Series Core Routers.

NOTE: For additional information about JUNOS Software—either corrections to orinformation that might have been omitted from this guide—see the software releasenotes at http://www.juniper.net/.

Audience

This guide is designed for network administrators who are configuring and monitoringa Juniper Networks M Series, MX Series, T Series, EX Series, or J Series router orswitch.

To use this guide, you need a broad understanding of networks in general, the Internetin particular, networking principles, and network configuration. You must also befamiliar with one or more of the following Internet routing protocols:

■ Border Gateway Protocol (BGP)

■ Distance Vector Multicast Routing Protocol (DVMRP)

■ Intermediate System-to-Intermediate System (IS-IS)

■ Internet Control Message Protocol (ICMP) router discovery

■ Internet Group Management Protocol (IGMP)

■ Multiprotocol Label Switching (MPLS)

■ Open Shortest Path First (OSPF)

■ Protocol-Independent Multicast (PIM)

■ Resource Reservation Protocol (RSVP)

■ Routing Information Protocol (RIP)

■ Simple Network Management Protocol (SNMP)

Personnel operating the equipment must be trained and competent; must not conductthemselves in a careless, willfully negligent, or hostile manner; and must abide bythe instructions provided by the documentation.

Supported Platforms

For the features described in this manual, JUNOS Software currently supports thefollowing platforms:

■ J Series

■ M Series

xxviii ■ Objectives


http://www.juniper.net/

■ MX Series

■ T Series

■ EX Series

Using the Indexes

This reference contains two indexes: a complete index that includes topic entries,and an index of statements and commands only.

In the index of statements and commands, an entry refers to a statement summarysection only. In the complete index, the entry for a configuration statement orcommand contains at least two parts:

■ The primary entry refers to the statement summary section.

■ The secondary entry, usage guidelines, refers to the section in a configurationguidelines chapter that describes how to use the statement or command.

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or theload merge relative command. These commands cause the software to merge theincoming configuration into the current candidate configuration. If the exampleconfiguration contains the top level of the hierarchy (or multiple hierarchies), theexample is a full example. In this case, use the load merge command.

If the example configuration does not start at the top level of the hierarchy, theexample is a snippet. In this case, use the load merge relative command. Theseprocedures are described in the following sections.

Merging a Full Example

To merge a full example, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration exampleinto a text file, save the file with a name, and copy the file to a directory on yourrouting platform.

For example, copy the following configuration to a file and name the fileex-script.conf. Copy the ex-script.conf file to the /var/tmp directory on your routingplatform.

system {scripts {

commit {file ex-script.xsl;

}}

}interfaces {

fxp0 {

Using the Indexes ■ xxix

About This Guide

disable;unit 0 {

family inet {address 10.0.0.1/24;

}}

}}

2. Merge the contents of the file into your routing platform configuration by issuingthe load merge configuration mode command:

[edit]user@host# load merge /var/tmp/ex-script.confload complete

Merging a Snippet

To merge a snippet, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration snippet intoa text file, save the file with a name, and copy the file to a directory on yourrouting platform.

For example, copy the following snippet to a file and name the fileex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directoryon your routing platform.

commit {file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the followingconfiguration mode command:

[edit]user@host# edit system scripts[edit system scripts]

3. Merge the contents of the file into your routing platform configuration by issuingthe load merge relative configuration mode command:

[edit system scripts]user@host# load merge relative /var/tmp/ex-script-snippet.confload complete

For more information about the load command, see the JUNOS CLI User Guide.

Documentation Conventions

Table 1 on page xxxi defines notice icons used in this guide.

xxx ■ Documentation Conventions


Table 1: Notice Icons

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 on page xxxi defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

ExamplesDescriptionConvention

To enter configuration mode, type theconfigure command:

user@host> configure

Represents text that you type.Bold text like this

user@host> show chassis alarmsNo alarms currently active

Represents output that appears on theterminal screen.

Fixed-width text like this

■ A policy term is a named structurethat defines match conditions andactions.

■ JUNOS System Basics ConfigurationGuide

■ RFC 1997, BGP CommunitiesAttribute

■ Introduces important new terms.

■ Identifies book names.

■ Identifies RFC and Internet drafttitles.

Italic text like this

Configure the machine’s domain name:

[edit]root@# set system domain-name

domain-name

Represents variables (options for whichyou substitute a value) in commands orconfiguration statements.

Italic text like this

■ To configure a stub area, includethe stub statement at the [editprotocols ospf area area-id]hierarchy level.

■ The console port is labeledCONSOLE.

Represents names of configurationstatements, commands, files, anddirectories; IP addresses; configurationhierarchy levels; or labels on routingplatform components.

Plain text like this

stub <default-metric metric>;Enclose optional keywords or variables.< > (angle brackets)

Documentation Conventions ■ xxxi

About This Guide

Table 2: Text and Syntax Conventions (continued)

ExamplesDescriptionConvention

broadcast | multicast

(string1 | string2 | string3)

Indicates a choice between the mutuallyexclusive keywords or variables on eitherside of the symbol. The set of choices isoften enclosed in parentheses for clarity.

| (pipe symbol)

rsvp { # Required for dynamic MPLS onlyIndicates a comment specified on thesame line as the configuration statementto which it applies.

# (pound sign)

community name members [community-ids ]

Enclose a variable for which you cansubstitute one or more values.

[ ] (square brackets)

[edit]routing-options {

static {route default {

nexthop address;retain;

}}

}

Identify a level in the configurationhierarchy.

Indention and braces ( { } )

Identifies a leaf statement at aconfiguration hierarchy level.

; (semicolon)

J-Web GUI Conventions

■ In the Logical Interfaces box, selectAll Interfaces.

■ To cancel the configuration, clickCancel.

Represents J-Web graphical userinterface (GUI) items you click or select.

Bold text like this

In the configuration editor hierarchy,select Protocols>Ospf.

Separates levels in a hierarchy of J-Webselections.

> (bold right angle bracket)

Documentation Feedback

We encourage you to provide feedback, comments, and suggestions so that we canimprove the documentation. You can send your comments [email protected], or fill out the documentation feedback form athttps://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to includethe following information with your comments:

■ Document name

■ Document part number

■ Page number

■ Software release version (not required for Network Operations Guides [NOGs])

xxxii ■ Documentation Feedback


mailto:[email protected]

https://www.juniper.net/cgi-bin/docbugreport/

Requesting Technical Support

Technical product support is available through the Juniper Networks TechnicalAssistance Center (JTAC). If you are a customer with an active J-Care or JNASC supportcontract, or are covered under warranty, and need postsales technical support, youcan 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 athttp://www.juniper.net/customers/support/downloads/710059.pdf.

■ Product warranties—For product warranty information, visithttp://www.juniper.net/support/warranty/.

■ JTAC Hours of Operation —The JTAC centers have resources available 24 hoursa 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 onlineself-service portal called the Customer Support Center (CSC) that provides you withthe 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 verify service entitlement by product serial number, use our Serial NumberEntitlement (SNE) Tool located at 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, visitus at http://www.juniper.net/support/requesting-support.html.

Requesting Technical Support ■ xxxiii

About This Guide

http://www.juniper.net/customers/support/downloads/710059.pdf

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

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

http://www2.juniper.net/kb/

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

http://kb.juniper.net/

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

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

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

http://www.juniper.net/cm/

https://tools.juniper.net/SerialNumberEntitlementSearch/

http://www.juniper.net/cm/

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

xxxiv ■ Requesting Technical Support


Part 1

Policy Framework

■ Introduction to Policy Framework on page 3

Policy Framework ■ 1

2 ■ Policy Framework


Chapter 1

Introduction to Policy Framework

This chapter discusses the following topics related to understanding the JUNOS policyframework:

■ Policy Framework Overview on page 3

■ Router Flows Affected by Policies on page 3

■ Policy Architecture on page 6

■ Control Points on page 6

■ Policy Components on page 7

■ Default Policies and Actions on page 8

■ Configuration Tasks on page 8

■ Policy Configuration Recommendations on page 8

■ Comparison of Routing Policies and Firewall Filters on page 9

Policy Framework Overview

The JUNOS Software provides a policy framework, which is a collection of JUNOSpolicies that allows you to control flows of routing information and packets. Thepolicy framework is composed of the following policies:

■ Routing policy—Allows you to control the routing information between the routingprotocols and the routing tables and between the routing tables and theforwarding table

■ Firewall filter policy—Allows you to control packets transiting the router to anetwork destination and packets destined for and sent by the router

NOTE: The term firewall filter policy is used here to emphasize that a firewall filteris a policy and shares some fundamental similarities with a routing policy. However,when referring to a firewall filter policy in the rest of this manual, the term firewallfilter is used.

Router Flows Affected by Policies

The JUNOS policies affect the following router flows:

Policy Framework Overview ■ 3

■ Flow of routing information between the routing protocols and the routing tablesand between the routing tables and the forwarding table. The Routing Enginehandles this flow. Routing information is the information about routes learnedby the routing protocols from a router’s neighbors. This information is stored inrouting tables and is subsequently advertised by the routing protocols to therouter’s neighbors. Routing policies allow you to control the flow of thisinformation.

■ Flow of data packets in and out of the router’s physical interfaces. The PacketForwarding Engine handles this flow. Data packets are chunks of data that transitthe router as they are being forwarded from a source to a destination. When arouter receives a data packet on an interface, it determines where to forwardthe packet by looking in the forwarding table for the best route to a destination.The router then forwards the data packet toward its destination through theappropriate interface. Firewall filters allow you to control the flow of these datapackets.

■ Flow of local packets from the router’s physical interfaces and to the RoutingEngine. The Routing Engine handles this flow. Local packets are chunks of datathat are destined for or sent by the router. Local packets usually contain routingprotocol data, data for IP services such as Telnet or SSH, and data foradministrative protocols such as the Internet Control Message Protocol (ICMP).When the Routing Engine receives a local packet, it forwards the packet to theappropriate process or to the kernel, which are both part of the Routing Engine,or to the Packet Forwarding Engine. Firewall filters allow you to control the flowof these local packets.

NOTE: In the rest of this chapter, the term packets refers to both data and localpackets unless explicitly stated otherwise.

Figure 1 on page 4 illustrates the flows through the router. Although the flows arevery different from each other, they are also interdependent. Routing policiesdetermine which routes are placed in the forwarding table. The forwarding table, inturn, has an integral role in determining the appropriate physical interface throughwhich to forward a packet.

Figure 1: Flows of Routing Information and Packets

You can configure routing policies to control which routes the routing protocols placein the routing tables and to control which routes the routing protocols advertise from

4 ■ Router Flows Affected by Policies


the routing tables (see Figure 2 on page 5). The routing protocols advertise activeroutes only from the routing tables. (An active route is a route that is chosen from allroutes in the routing table to reach a destination. For information about the activeroute selection process, see the JUNOS Routing Protocols Configuration Guide.)

You can also use routing policies to do the following:

■ Change specific route characteristics, which allow you to control which route isselected as the active route to reach a destination. In general, the active route isalso advertised to a router’s neighbors.

■ Change to the default BGP route flap-damping values.

■ Perform per-packet load balancing.

■ Enable class of service (CoS).

Figure 2: Routing Policies to Control Routing Information Flow

You can configure firewall filters to control the following (see Figure 3 on page 6):

■ Which data packets are accepted on and transmitted from the physical interfaces.To control the flow of data packets, you apply firewall filters to the physicalinterfaces.

■ Which local packets are transmitted from the physical interfaces and to theRouting Engine. To control local packets, you apply firewall filters on the loopbackinterface, which is the interface to the Routing Engine.

Firewall filters provide a means of protecting your router from excessive traffictransiting the router to a network destination or destined for the Routing Engine.Firewall filters that control local packets can also protect your router from externalincidents such as denial-of-service attacks.

Router Flows Affected by Policies ■ 5

Chapter 1: Introduction to Policy Framework

Figure 3: Firewall Filters to Control Packet Flow

Policy Architecture

A policy is a mechanism in the JUNOS policy framework that allows you to configurecriteria against which something can be compared and an action that is performedif the criteria are met.

All policies in the JUNOS policy framework share the following architecture andconfiguration fundamentals:

■ Control Points on page 6

■ Policy Components on page 7

■ Default Policies and Actions on page 8

■ Configuration Tasks on page 8

■ Policy Configuration Recommendations on page 8

NOTE: This section highlights the fundamental architecture that all policies share.Note, however, that the implementation details of routing policies and firewall filtersare very different. For information about these differences, see “Comparison ofRouting Policies and Firewall Filters” on page 9.

Control Points

All policies provide two points at which you can control routing information or packetsthrough the router (see Figure 4 on page 7). These control points allow you to controlthe following:

■ Routing information before and after it is placed in the routing table.

■ Data packets before and after a forwarding table lookup.

6 ■ Policy Architecture


■ Local packets before and after they are received by the Routing Engine. (Figure4 on page 7 appears to depict only one control point but because of thebidirectional flow of the local packets, two control points actually exist.)

Figure 4: Policy Control Points

Because there are two control points, you can configure policies that control therouting information or data packets before and after their interaction with theirrespective tables, and policies that control local packets before and after theirinteraction with the Routing Engine. Import routing policies control the routinginformation that is placed in the routing tables, whereas export routing policies controlthe routing information that is advertised from the routing tables. Input firewall filterscontrol packets that are received on a router interface, whereas output firewall filterscontrol packets that are transmitted from a router interface.

Policy Components

All policies are composed of the following components that you configure:

■ Match conditions—Criteria against which a route or packets are compared. Youcan configure one or more criteria. If all criteria match, one or more actions areapplied.

■ Actions—What happens if all criteria match. You can configure one or moreactions.

■ Terms—Named structures in which match conditions and actions are defined.You can define one or more terms.

For more information about these concepts and how they fit into the context of theirrespective policies, see “Configuring a Routing Policy” on page 23 and “Firewall FilterComponents” on page 173.

The policy framework software evaluates each incoming and outgoing route or packetagainst the match conditions in a term. If the criteria in the match conditions aremet, the defined action is taken.

Policy Components ■ 7


In general, the policy framework software compares the route or packet against thematch conditions in the first term in the policy, then goes on to the next term, andso on. (For specific information about when the evaluation process ends for eachpolicy, see “Comparison of Routing Policies and Firewall Filters” on page 9.)Therefore, the order in which you arrange terms in a policy is relevant.

The order of match conditions within a term is not relevant because a route or packetmust match all match conditions in a term for an action to be taken.

Default Policies and Actions

If an incoming or outgoing route or packet arrives and there is no explicitly configuredpolicy related to the route or to the interface upon which the packet arrives, theaction specified by the default policy is taken. A default policy is a rule or a set ofrules that determine whether the route is placed in or advertised from the routingtable, or whether the packet is accepted into or transmitted from the router interface.

All policies also have default actions in case one of the following situations arisesduring policy evaluation:

■ A policy does not specify a match condition.

■ A match occurs, but a policy does not specify an action.

■ A match does not occur with a term in a policy and subsequent terms in thesame policy exist.

■ A match does not occur by the end of a policy.

Configuration Tasks

All policies share a two-step configuration process:

■ Define the policy—Define the policy components. The components includecriteria against which routes or packets are compared and actions that areperformed if the criteria are met. For more information, see “Policy Components”on page 7.

■ Apply the policy—Apply the policy to whatever moves the routing informationor packets through the router, for example, the routing protocol or the routerinterface.

NOTE: A defined policy does not take effect until you apply it.

Policy Configuration Recommendations

The JUNOS policy architecture is simple and straightforward. However, the actualimplementation of each policy adds layers of complexity to the policy as well asadding power and flexibility to your router’s capabilities. Configuring a policy has amajor impact on the flow of routing information or packets within and through the

8 ■ Default Policies and Actions


router. For example, you can configure a routing policy that does not allow routesassociated with a particular customer to be placed in the routing table. As a result ofthis routing policy, the customer routes are not used to forward data packets tovarious destinations and the routes are not advertised by the routing protocol toneighbors.

Before configuring a policy, determine what you want to accomplish with it andthoroughly understand how to achieve your goal using the various match conditionsand actions. Also, make certain that you understand the default policies and actionsfor the policy you are configuring.

Comparison of Routing Policies and Firewall Filters

Although routing policies and firewall filters share an architecture, as described in“Policy Architecture” on page 6, their purposes, implementation, and configurationare different. Table 3 on page 9 describes their purposes. Table 4 on page 9compares the implementation details for routing policies and firewall filters,highlighting the similarities and differences in their configuration.

For complete information about routing policies, see “Routing Policies” on page 13.For complete information about firewall filters, see “Firewall Filters” on page 171.

Table 3: Purpose of Routing Policies and Firewall Filters

Policy PurposeSourcePolicies

To control the size and content of the routing tables,which routes are advertised, and which routes areconsidered the best to reach various destinations.

Routing information is generated by internalnetworking peers.

Routing policies

To protect your router and network from excessiveincoming traffic or hostile attacks that can disruptnetwork service, and to control which packets areforwarded from which router interfaces.

Packets are generated by internal and externaldevices through which hostile attacks can beperpetrated.

Firewall filters

Table 4: Implementation Differences Between Routing Policies and Firewall Filters

Firewall Filter ImplementationRouting Policy ImplementationPolicyArchitecture

Control packets that are accepted on a routerinterface with an input firewall filter and that areforwarded from an interface with an output firewallfilter.

Control routing information that is placed in therouting table with an import routing policy andadvertised from the routing table with an exportrouting policy.

Control points

Comparison of Routing Policies and Firewall Filters ■ 9


Table 4: Implementation Differences Between Routing Policies and FirewallFilters (continued)


Define a policy that contains terms, matchconditions, and actions.

Apply one input or output firewall filter to a physicalinterface or physical interface group to filter datapackets received by or forwarded to a physicalinterface (on routing platforms with an InternetProcessor II application-specific integrated circuit[ASIC] only).

You can also apply one input or output firewall filterto the routing platform’s loopback interface, whichis the interface to the Routing Engine (on all routingplatforms). This allows you to filter local packetsreceived by or forwarded from the Routing Engine.

Define a policy that contains terms, matchconditions, and actions.

Apply one or more export or import policies to arouting protocol. You can also apply a policyexpression, which uses Boolean logical operatorswith multiple import or export policies.

You can also apply one or more export policies tothe forwarding table.

Configurationtasks:

■ Definepolicy

■ Applypolicy

Configure as many terms as desired. Define a namefor each term.

Terms are evaluated in the order in which youspecify them.

Evaluation of a firewall filter ends after a packetmatches the criteria in a term and the defined ordefault action is taken. The packet is not evaluatedagainst subsequent terms in the firewall filter.

Configure as many terms as desired. Define a namefor each term.

Terms are evaluated in the order in which youspecify them.

Evaluation of a policy ends after a packet matchesthe criteria in a term and the defined or defaultpolicy action of accept or reject is taken. The routeis not evaluated against subsequent terms in thesame policy or subsequent policies.

Terms

Specify zero or more criteria that a packet mustmatch. You must match various fields in the packet’sheader. The fields are grouped into the followingcategories:

■ Numeric values, such as port and protocolnumbers.

■ Prefix values, such as IP source and destinationprefixes.

■ Bit-field values—Whether particular bits in thefields are set, such as IP options, TransmissionControl Protocol (TCP) flags, and IPfragmentation fields. You can specify the fieldsusing Boolean logical operators.

Specify zero or more criteria that a route mustmatch. You can specify criteria based on source,destination, or properties of a route. You can alsospecify the following match conditions, whichrequire more configuration:

■ Autonomous system (AS) path expression—Acombination of AS numbers and regularexpression operators.

■ Community—A group of destinations that sharea common property.

■ Prefix list—A named list of prefixes.

■ Route list—A list of destination prefixes.

■ Subroutine—A routing policy that is calledrepeatedly from other routing policies.

Match conditions

10 ■ Comparison of Routing Policies and Firewall Filters




Specify zero or one action to take if a packetmatches all criteria. (We recommend that youalways explicitly configure an action.) You canspecify the following actions:

■ Accept—Accept a packet.

■ Discard—Discard a packet silently, withoutsending an ICMP message.

■ Reject—Discard a packet, and send an ICMPdestination unreachable message.

■ Routing instance—Specify a routing table towhich packets are forwarded.

■ Next term—Evaluate the next term in thefirewall filter.

In addition to zero or the preceding actions, you canalso specify zero or more action modifiers. You canspecify the following action modifiers:

■ Count—Add packet to a count total.

■ Forwarding class—Set the packet forwardingclass to a specified value from 0 through 3.

■ IPsec security association—Used with thesource and destination address matchconditions, specify an IP Security (IPsec)security association (SA) for the packet.

■ Log—Store the header information of a packeton the Routing Engine.

■ Loss priority—Set the packet loss priority (PLP)bit to a specified value, 0 or 1.

■ Policer—Apply rate-limiting procedures to thetraffic.

■ Sample—Sample the packet traffic.

■ Syslog—Log an alert for the packet.

Specify zero or one action to take if a route matchesall criteria. You can specify the following actions:

■ Accept—Accept the route into the routing table,and propagate it. After this action is taken, theevaluation of subsequent terms and policiesends.

■ Reject—Do not accept the route into the routingtable, and do not propagate it. After this actionis taken, the evaluation of subsequent termsand policies ends.

In addition to the preceding actions, you can alsospecify zero or more of the following types ofactions:

■ Next term—Evaluate the next term in therouting policy.

■ Next policy—Evaluate the next routing policy.

■ Actions that manipulate characteristicsassociated with a route as the routing protocolplaces it in the routing table or advertises itfrom the routing table.

■ Trace action, which logs route matches.

Actions

Comparison of Routing Policies and Firewall Filters ■ 11




If an incoming or outgoing packet arrives on aninterface and a firewall filter is not configured forthe interface, the default policy is taken (the packetis accepted).

The following default actions exist for firewall filters:

■ If a firewall filter does not specify a matchcondition, all packets are considered to match.

■ If a match occurs but the firewall filter doesnot specify an action, the packet is accepted.

■ If a match occurs, the defined or default actionis taken and the evaluation ends. Subsequentterms in the firewall filter are not evaluated,unless the next term action is specified.

■ If a match does not occur with a term in afirewall filter and subsequent terms in the samefilter exist, the next term is evaluated.

■ If a match does not occur by the end of afirewall filter, the packet is discarded.

If an incoming or outgoing route arrives and a policyrelated to the route is not explicitly configured, theaction specified by the default policy for theassociated routing protocol is taken.

The following default actions exist for routingpolicies:

■ If a policy does not specify a match condition,all routes evaluated against the policy match.

■ If a match occurs but the policy does notspecify an accept, reject, next term, or nextpolicy action, one of the following occurs:

■ The next term, if present, is evaluated.

■ If no other terms are present, the nextpolicy is evaluated.

■ If no other policies are present, the actionspecified by the default policy is taken.

■ If a match does not occur with a term in apolicy and subsequent terms in the same policyexist, the next term is evaluated.

■ If a match does not occur with any terms in apolicy and subsequent policies exist, the nextpolicy is evaluated.

■ If a match does not occur by the end of a policyand no other policies exist, the accept or rejectaction specified by the default policy is taken.

Default policiesand actions

12 ■ Comparison of Routing Policies and Firewall Filters


Part 2

Routing Policies

■ Introduction to Routing Policy on page 15

■ Routing Policy Configuration Statements on page 35

■ Routing Policy Configuration on page 39

■ Extended Match Conditions Configuration on page 97

■ Extended Actions Configuration on page 137

■ Summary of Routing Policy Configuration Statements on page 155

Routing Policies ■ 13

14 ■ Routing Policies


Chapter 2

Introduction to Routing Policy

This chapter discusses the following topics related to understanding and creatingrouting policies:

■ Routing Policy Overview on page 16

■ Importing and Exporting Routes on page 17

■ Protocols That Can Be Imported To and Exported From the RoutingTable on page 18

■ Routing Tables Affected by Routing Policies on page 19

■ Default Routing Policies and Actions on page 20

■ Default Import and Export Policies for Protocols on page 21

■ Creating Routing Policies on page 22

■ Configuring a Routing Policy on page 23

■ Routing Policy Match Conditions on page 24

■ Routing Policy Named Match Conditions on page 25

■ Routing Policy Actions on page 25

■ Routing Policy Terms on page 26

■ Applying Routing Policy on page 26

■ Routing Protocol Support for Import and Export Policy on page 27

■ Protocol Support for Import and Export Policies on page 28

■ Applying Routing Policy to Routing Protocols on page 28

■ Applying Export Policies to the Forwarding Table on page 29

■ Evaluating a Routing Policy on page 29

■ How a Routing Policy Is Evaluated on page 29

■ How a Routing Policy Chain Is Evaluated on page 30

■ How a Routing Policy Expression Is Evaluated on page 31

■ How a Routing Policy Subroutine Is Evaluated on page 31

■ Routing Policy Tests on page 33

■ 15

Routing Policy Overview

All routing protocols store their routing information in routing tables. From thesetables, the routing protocols calculate the best route to each destination and placethese routes in a forwarding table. These routes are then used to forward routingprotocol traffic toward a destination, and they can be advertised to neighbors usingone or more routing protocols.

NOTE: Instead of referring to the multiple routing tables that the JUNOS Softwaremaintains, the discussion in the rest of this chapter assumes the inet.0 routing tableunless explicitly stated otherwise. By default, the JUNOS Software stores unicast IPversion 4 (IPv4) routes in the inet.0 routing table. For information about all the routingtables, see “Routing Tables Affected by Routing Policies” on page 19.

In general, the routing protocols place all their routes in the routing table and advertisea limited set of routes from the routing table. The general rules for handling therouting information between the routing protocols and the routing table are knownas the routing policy framework.

The routing policy framework is composed of default rules for each routing protocolthat determine which routes the protocol places in the routing table and advertisesfrom the routing table. The default rules for each routing protocol are known asdefault routing policies.

You can create routing policies to preempt the default policies, which are alwayspresent. A routing policy is a mechanism in the JUNOS Software that allows you tomodify the routing policy framework to suit your needs. You can create andimplement your own routing policies to do the following:

■ Control which routes a routing protocol places in the routing table.

■ Control which active routes a routing protocol advertises from the routing table.(An active route is a route that is chosen from all routes in the routing table toreach a destination. For information about the active route selection process,see the JUNOS Routing Protocols Configuration Guide.)

■ Manipulate the route characteristics as a routing protocol places it in the routingtable or advertises it from the routing table.

You can manipulate the route characteristics to control which route is selected asthe active route to reach a destination. The active route is placed in the forwardingtable and used to forward traffic toward the route’s destination. In general, the activeroute is also advertised to a router’s neighbors.

To create a routing policy, you must define the policy and apply it. You define thepolicy by specifying the criteria that a route must match and the actions to performif a match occurs. You then apply the policy to a routing protocol or to the forwardingtable.

16 ■ Routing Policy Overview


NOTE: Before you create your routing policies, we recommend that you read throughthis entire section to become familiar with the terminology, concepts, andconfiguration guidelines.

In JUNOS Release 9.5 and later, you can configure routing policies and certain routingpolicy objects in a dynamic database that is not subject to the same verificationrequired by the standard configuration database. As a result, you can quickly committhese routing policies and policy objects, which can be referenced and applied in thestandard configuration as needed. BGP is the only protocol to which you can applyrouting policies that reference policies configured in the dynamic database. After arouting policy based on the dynamic database is configured and committed in thestandard configuration, you can quickly make changes to existing routing policiesby modifying policy objects in the dynamic database. Because the JUNOS Softwaredoes not validate configuration changes to the dynamic database, when you use thisfeature, you should test and verify all configuration changes before committing them.For more information about configuring dynamic routing policies, see “ConfiguringDynamic Routing Policies” on page 65.

Importing and Exporting Routes

Two terms—import and export—explain how routes move between the routingprotocols and the routing table (see Figure 5 on page 17):

■ When the Routing Engine places the routes of a routing protocol into the routingtable, it is importing routes into the routing table.

■ When the Routing Engine uses active routes from the routing table to send aprotocol advertisement, it is exporting routes from the routing table.

NOTE: The process of moving routes between a routing protocol and the routingtable is described always from the point of view of the routing table. That is, routesare imported into a routing table from a routing protocol and they are exported froma routing table to a routing protocol. Remember this distinction when working withrouting policies.

Figure 5: Importing and Exporting Routes

When evaluating routes for export, the Routing Engine uses only active routes fromthe routing table. For example, if a routing table contains multiple routes to the same

Importing and Exporting Routes ■ 17

Chapter 2: Introduction to Routing Policy

destination and one route has a preferable metric, only that route is evaluated. Inother words, an export policy does not evaluate all routes; it evaluates only thoseroutes that a routing protocol is allowed to advertise to a neighbor. For moreinformation about the active path selection algorithm, see the JUNOS Routing ProtocolsConfiguration Guide.

NOTE: By default, BGP advertises active routes. However, you can configure BGP toadvertise inactive routes, which go to the same destination as other routes but haveless preferable metrics. For more information about advertising inactive routes, seethe JUNOS Routing Protocols Configuration Guide.

Table 5 on page 18 lists the routing protocols from which the routing table can importroutes and to which the routing table can export routes. Table 5 on page 18 also listsdirect and explicitly configured routes, which for the purposes of this table areconsidered a pseudoprotocol. (An explicitly configured route is a route that you haveconfigured. Direct routes are not explicitly configured; they are created as a result ofIP addresses being configured on an interface.) Explicitly configured routes includeaggregate, generated, local, and static routes. (An aggregate route is a route that distillsgroups of routes with common addresses into one route. A generated route is a routeused when the routing table has no information about how to reach a particulardestination. A local route is an IP address assigned to a router interface. A static routeis an unchanging route to a destination.)

The policy framework software treats direct and explicitly configured routes as ifthey are learned through routing protocols; therefore, they can be imported into therouting table. Routes cannot be exported from the routing table to the pseudoprotocol,because this protocol is not a real routing protocol. However, aggregate, direct,generated, and static routes can be exported from the routing table to routingprotocols, whereas local routes cannot.

For information about the default routing policies for each routing protocol, see Table7 on page 21. For information about the import and export routing policies supportedfor each routing protocol and the level at which you can apply these policies, seeTable 5 on page 18.

Protocols That Can Be Imported To and Exported From the Routing Table

Table 5: Protocols That Can Be Imported To and Exported From the Routing Table

ExportImportProtocol

YesYesBGP

YesYesDistance Vector Multicast Routing Protocol (DVMRP)

YesYesIS-IS

YesYesLDP

NoYesMPLS

18 ■ Protocols That Can Be Imported To and Exported From the Routing Table


Table 5: Protocols That Can Be Imported To and Exported From the RoutingTable (continued)

ExportImportProtocol

YesYesOSPF

YesYesProtocol Independent Multicast (PIM) dense mode

YesYesPIM sparse mode

YesYesPIM sparse-dense mode

NoYesPseudoprotocol:

■ Direct routes

■ Explicitly configured routes

■ Aggregate routes

■ Generated routes

■ Local routes

■ Static routes

YesYesRouting Information Protocol (RIP) and RoutingInformation Protocol next generation (RIPng)

Routing Tables Affected by Routing Policies

Table 6 on page 19 lists the routing tables affected by default and user-defined routingpolicies and the types of routes that each routing table stores.

Table 6: Routing Tables Affected by Routing Policies

Type of Routes StoredRouting Table

Unicast IPv4 routesinet.0

Unicast IPv4 routes for a particular routing instance.inet.0 instance-name

Multicast IPv4 routesinet.1

Unicast IPv4 routes for multicast reverse-path forwarding (RPF)lookup

inet.2

MPLS routesinet.3

MPLS routes for label-switched path (LSP) next hopsmpls.0

Unicast IP version 6 (IPv6) routesinet6.0

Routing Tables Affected by Routing Policies ■ 19


NOTE: The discussion in the rest of this chapter assumes that the routing table isinet.0 unless explicitly stated otherwise.

For more information about routing tables, see the JUNOS Routing ProtocolsConfiguration Guide.

Default Routing Policies and Actions

You must be familiar with the default routing policies to know when you need tomodify them to suit your needs. Table 7 on page 21 summarizes the for each routingprotocol that imports and exports routes. The actions in the are taken if you havenot explicitly configured a routing policy. This table also shows direct and explicitlyconfigured routes, which for the purposes of this table are considered apseudoprotocol. Explicitly configured routes include aggregate, generated, and staticroutes.

When multiple routes for a destination exist in the routing table, the protocol selectsan active route and that route is placed in the appropriate routing table. For equal-costroutes, the JUNOS Software places multiple next hops in the appropriate routingtable.

When a protocol is exporting routes from the routing table, it exports active routesonly. This applies to actions specified by both default and user-defined export policies.

You cannot change the default import policy for the link-state protocols IS-IS andOSPF. As link-state protocols, IS-IS and OSPF exchange routes between systemswithin an autonomous system (AS). All routers and systems within an AS must sharethe same link-state database, which includes routes to reachable prefixes and themetrics associated with the prefixes. If an import policy is configured and appliedto IS-IS or OSPF, some routes might not be learned or advertised or the metrics forlearned routes might be altered, which would make a consistent link-state databaseimpossible.

The default export policy for IS-IS and OSPF protocols is to reject everything. Theseprotocols do not actually export their internally learned routes (the directly connectedroutes on interfaces that are running the protocol). Both IS-IS and OSPF protocolsuse a procedure called flooding to announce local routes and any routes learned bythe protocol. The flooding procedure is internal to the protocol, and is unaffected bythe policy framework. Exporting can be used only to announce information fromother protocols, and the default is not to do so.

For information about the routing protocols from which the routing table can importroutes and to which routing protocols the routing table can export routes, see Table5 on page 18. For information about the user-defined import and export policiessupported for each routing protocol and the level at which you can apply thesepolicies, see Table 9 on page 28.

The following default actions are taken if the following situations arise during policyevaluation:

20 ■ Default Routing Policies and Actions


■ If a policy does not specify a match condition, all routes evaluated against thepolicy match.

■ If a match occurs but the policy does not specify an accept, reject, next term, ornext policy action, one of the following occurs:

■ The next term, if present, is evaluated.

■ If no other terms are present, the next policy is evaluated.

■ If no other policies are present, the action specified by the default policy istaken.

■ If a match does not occur with a term in a policy and subsequent terms in thesame policy exist, the next term is evaluated.

■ If a match does not occur with any terms in a policy and subsequent policiesexist, the next policy is evaluated.

■ If a match does not occur by the end of a policy or all policies, the accept orreject action specified by the default policy is taken.

The default import policy is always the same: accept all routes learned from theprotocol. Table 7 on page 21 includes information about the routing tables used byeach protocol.

Default Import and Export Policies for Protocols

Table 7: Default Import and Export Policies for Protocols

Default Export PolicyDefault Import PolicyImporting or ExportingProtocol

Accept and export active BGProutes.

Accept all BGP IPv4 routes learnedfrom configured neighbors andimport into the inet.0 routingtable. Accept all BGP IPv6 routeslearned from configuredneighbors and import into theinet6.0 routing table.

BGP

Accept and export active DVMRProutes.

Accept all DVMRP routes andimport into the inet.1 routingtable.

DVMRP

Reject everything. (The protocoluses flooding to announce localroutes and any learned routes.)

Accept all IS-IS routes and importinto the inet.0 and inet6.0 routingtables. (You cannot override orchange this default policy.)

IS-IS

Reject everything.Accept all LDP routes and importinto the inet.3 routing table.

LDP

Accept and export active MPLSroutes.

Accept all MPLS routes and importinto the inet.3 routing table.

MPLS

Default Import and Export Policies for Protocols ■ 21


Table 7: Default Import and Export Policies for Protocols (continued)

Default Export PolicyDefault Import PolicyImporting or ExportingProtocol

Reject everything. (The protocoluses flooding to announce localroutes and any learned routes.)

Accept all OSPF routes and importinto the inet.0 routing table. (Youcannot override or change thisdefault policy.)

OSPF

Accept active PIM dense moderoutes.

Accept all PIM dense mode routesand import into the inet.1 routingtable.

PIM dense mode

Accept and export active PIMsparse mode routes.

Accept all PIM sparse mode routesand import into the inet.1 routingtable.

PIM sparse mode

The pseudoprotocol cannot exportany routes from the routing tablebecause it is not a routingprotocol.

Routing protocols can export theseor any routes from the routingtable.

Accept all direct and explicitlyconfigured routes and import intothe inet.0 routing table.

Pseudoprotocol:

■ Direct routes

■ Explicitlyconfigured routes:

■ Aggregateroutes

■ Generatedroutes

■ Static routes

Reject everything. To export RIProutes, you must configure anexport policy for RIP.

Accept all RIP routes learned fromconfigured neighbors and importinto the inet.0 routing table.

RIP

Reject everything. To export RIPngroutes, you must configure anexport policy for RIPng.

Accept all RIPng routes learnedfrom configured neighbors andimport into the inet6.0 routingtable.

RIPng

Accept all routes. For additional information about test policy, see“Routing Policy Tests” on page 33.

Test policy

Creating Routing Policies

The following are typical circumstances under which you might want to preempt thedefault routing policies in the routing policy framework by creating your own routingpolicies:

■ You do not want a protocol to import all routes into the routing table. If therouting table does not learn about certain routes, they can never be used toforward packets and they can never be redistributed into other routing protocols.

■ You do not want a routing protocol to export all the active routes it learns.

■ You want a routing protocol to announce active routes learned from anotherrouting protocol, which is sometimes called route redistribution.

22 ■ Creating Routing Policies


■ You want to manipulate route characteristics, such as the preference value, ASpath, or community. You can manipulate the route characteristics to controlwhich route is selected as the active route to reach a destination. In general, theactive route is also advertised to a router’s neighbors.

■ You want to change the default BGP route flap-damping parameters.

■ You want to perform per-packet load balancing.

■ You want to enable class of service (CoS).

Configuring a Routing Policy

As shown in Figure 6 on page 23, you use import routing policies to control whichroutes routing protocols place in the routing table, and export routing policies tocontrol which routes a routing protocol advertises from the routing table to itsneighbors.

Figure 6: Importing and Exporting Routing Policies

To create a routing policy, you must define the following components:

■ Match conditions—Criteria that a route must match. If a route matches all of thecriteria, one or more actions are applied to the route.

■ Actions—What to do if a route matches. The actions can specify whether toaccept or reject the route, control how a series of policies is evaluated, andmanipulate the characteristics associated with a route. You can configure oneor more actions.

You typically define match conditions and actions within a term. Figure 7 on page23 shows the routing policy components, including the term.

Figure 7: Routing Policy Components

Configuring a Routing Policy ■ 23


After defining a routing policy, you then apply it to a routing protocol or to theforwarding table.

This section provides more information about creating routing policies:

■ Routing Policy Match Conditions on page 24

■ Routing Policy Named Match Conditions on page 25

■ Routing Policy Actions on page 25

■ Routing Policy Terms on page 26

■ Applying Routing Policy on page 26

Routing Policy Match Conditions

A match condition defines the criteria that a route must match. You can define oneor more match conditions. If a route matches all match conditions, one or moreactions are applied to the route.

Match conditions fall into two categories: standard and extended. In general, theextended match conditions include criteria that are defined separately from therouting policy (AS path regular expressions, communities, and prefix lists) and aremore complex than standard match conditions. The extended match conditionsprovide many powerful capabilities. For more information about them, see “ExtendedMatch Conditions Configuration” on page 97. The standard match conditions includecriteria that are defined within a routing policy and are less complex than theextended match conditions, also called named match conditions.

Table 8 on page 24 describes each match condition, including its category, whenyou typically use it, and any relevant notes about it. For more information aboutmatch conditions, see Table 10 on page 42.

Table 8: Match Conditions

NotesWhen to UseCategoryMatch Condition

You use regularexpressions to match theAS path.

(BGP only) Match a route based on its AS path.(An AS path consists of the AS numbers of allrouters a packet must go through to reach adestination.) You can specify an exact matchwith a particular AS path or a less precisematch.

ExtendedAS path regular expression—Acombination of AS numbers andregular expression operators.

Actions can be performedon the entire group.

You can create multiplecommunities associatedwith a particulardestination.

You can create matchconditions using regularexpressions.

Match a group of destinations that share aproperty. Use a routing policy to define acommunity that specifies a group ofdestinations you want to match and one ormore actions that you want taken on thiscommunity.

ExtendedCommunity—A group ofdestinations that share aproperty. (Communityinformation is included as apath attribute in BGP updatemessages.)

24 ■ Routing Policy Match Conditions


Table 8: Match Conditions (continued)

NotesWhen to UseCategoryMatch Condition

You can specify a commonaction only for all prefixesin the list.

Match a route based on prefix information.You can specify an exact match of a particularroute only.

ExtendedPrefix list—A named list of IPaddresses.

You can specify an actionfor each prefix in the routelist or a common action forall prefixes in the route list.

Match a route based on prefix information.You can specify an exact match of a particularroute or a less precise match.

ExtendedRoute list—A list of destinationprefixes.

None.Match a route based on one of the followingcriteria: area ID, color, external route, family,instance (routing), interface name, levelnumber, local preference, metric, neighboraddress, next-hop address, origin, preference,protocol, routing table name, or tag.

For the protocol criterion, you can specify oneof the following: BGP, direct, DVMRP, IS-IS,local, MPLS, OSPF, PIM dense mode, PIMsparse mode, RIP, RIPng, static, and aggregate.

StandardStandard—A collection ofcriteria that can match a route.

The subroutine actioninfluences but does notnecessarily determine thefinal action. For moreinformation, see “How aRouting Policy SubroutineIs Evaluated” on page 31.

Use an effective routing policy in other routingpolicies. You can create a subroutine that youcan call over and over from other routingpolicies.

ExtendedSubroutine—A routing policythat is called repeatedly fromanother routing policy.

Routing Policy Named Match Conditions

Some match conditions are defined separately from the routing policy and are givennames. You then reference the name of the match condition in the definition of therouting policy itself. Named match conditions allow you to do the following:

■ Reuse match conditions in other routing policies.

■ Read configurations that include complex match conditions more easily.

Named match conditions include communities, prefix lists, and AS path regularexpressions. For more information about these match conditions, see Table 8 onpage 24.

Routing Policy Actions

An action is what the policy framework software does if a route matches all criteriadefined in a match condition. You can configure one or more actions in a term. Thepolicy framework software supports the following types of actions:

■ Flow control actions, which affect whether to accept or reject the route or whetherto evaluate the next term or routing policy

Routing Policy Named Match Conditions ■ 25


■ Actions that manipulate route characteristics

■ Trace action, which logs route matches

Manipulating the route characteristics allows you to control which route is selectedas the active route to reach a destination. In general, the active route is also advertisedto a routing platform’s neighbors. You can manipulate the following routecharacteristics: AS path, class, color, community, damping parameters, destinationclass, external type, next hop, load balance, local preference, metric, origin,preference, and tag.

For the numeric information (color, local preference, metric, preference, and tag),you can set a specific value or change the value by adding or subtracting a specifiedamount. The addition and subtraction operations do not allow the value to exceeda maximum value and drop below a minimum value.

For more information about the properties you can change and the addition andsubtraction operations, see Table 12 on page 49.

Routing Policy Terms

A term is a named structure in which match conditions and actions are defined. Youcan define one or more terms.

In general, the policy framework software compares a route against the matchconditions in the first term in the first routing policy, then goes on to the next termand the next policy if present, and so on, until an explicitly configured or defaultaction of accept or reject is taken. Therefore, the order in which you arrange termsin a policy is relevant.

The order of match conditions in a term is not relevant, because a route must matchall match conditions in a term for an action to be taken.

Applying Routing Policy

After defining a routing policy, as discussed in “Routing Policy Match Conditions”on page 24 and “Routing Policy Actions” on page 25, you can apply it to one of thefollowing:

■ Routing protocols—BGP, DVMRP, IS-IS, LDP, MPLS, OSPF, PIM dense mode, PIMsparse mode, PIM sparse-dense mode, RIP, and RIPng

■ Pseudoprotocol—Explicitly created routes, which include aggregate and generatedroutes

■ Forwarding table

The following sections discuss the following topics:

■ Routing Protocol Support for Import and Export Policy on page 27

■ Protocol Support for Import and Export Policies on page 28

26 ■ Routing Policy Terms


■ Applying Routing Policy to Routing Protocols on page 28

■ Applying Export Policies to the Forwarding Table on page 29

Routing Protocol Support for Import and Export Policy

When applying routing policies to routing protocols, you must know whether eachprotocol supports import and export policies and the level at which you can applythese policies. Table 9 on page 28 summarizes the import and export policy supportfor each routing protocol. Table 5 on page 18 also lists explicitly configured routes,which for the purposes of this table are considered a pseudoprotocol. Explicitlyconfigured routes include aggregate and generated routes.

You can apply an import policy to aggregate and generated routes, but you cannotapply an export policy to these routes. These routes cannot be exported from therouting table to the pseudoprotocol, because this protocol is not a real routing protocol.However, aggregate and generated routes can be exported from the routing table torouting protocols.

You cannot apply import policies to the link-state protocols IS-IS and OSPF. Aslink-state protocols, IS-IS and OSPF exchange routes between systems within an AS.All routers and systems within an AS must share the same link-state database, whichincludes routes to reachable prefixes and the metrics associated with the prefixes.If an import policy is configured and applied to IS-IS or OSPF, some routes mightnot be learned or advertised, or the metrics for learned routes might be altered,which would make a consistent link-state database impossible.

For BGP only, you can also apply import and export policies at group and peer levelsas well as at the global level. A peer import or export policy overrides a group importor export policy. A group import or export policy overrides a global import or exportpolicy.

For example, if you define an import policy for an individual peer at the peer leveland also define an import policy for the group to which it belongs, the import policydefined for the peer level only is invoked. The group import policy is not used forthat peer, but it is applied to other peers in that group.

For RIP and RIPng only, you can apply import policies at the global and neighborlevels and export policies at a group level. For more information about RIP and RIPng,see the JUNOS Routing Protocols Configuration Guide.

For information about the routing protocols from which the routing table can importroutes and to which routing protocols the routing table can export routes, see Table5 on page 18. For information about the default routing policies for each routingprotocol, see Table 7 on page 21.

Routing Protocol Support for Import and Export Policy ■ 27


Protocol Support for Import and Export Policies

Table 9: Protocol Support for Import and Export Policies

Supported LevelsExport PolicyImport PolicyProtocol

Import: global, group,peerExport: global, group,peer

YesYesBGP

GlobalYesYesDVMRP

Export: globalYesNoIS-IS

GlobalYesYesLDP

–NoNoMPLS

Export: global

Import: externalroutes only

YesYesOSPF

GlobalYesYesPIM dense mode

GlobalYesYesPIM sparse mode

Import: globalNoYesPseudoprotocol—Explicitlyconfigured routes, which include thefollowing:

■ Aggregate routes

■ Generated routes

Import: global,neighborExport: group

YesYesRIP and RIPng

Applying Routing Policy to Routing Protocols

You can apply the following routing policy elements to a routing protocol:

■ Routing policy—You can apply a single routing policy to a routing protocol.

■ Chain of routing policies—You can apply multiple routing policies (chains) to arouting protocol.

■ Policy expression—You can apply a policy expression to a routing protocol. Apolicy expression uses Boolean logical operators with a routing policy and routingpolicy chains. The logical operators establish rules by which the policy or chainsare evaluated.

28 ■ Protocol Support for Import and Export Policies


Applying Export Policies to the Forwarding Table

You can apply export policies to routes being exported from the routing table intothe forwarding table for the following features:

■ Per-packet load balancing

■ CoS

For more information about per-packet load balancing, see “Overview of Per-PacketLoad Balancing” on page 144. For more information about CoS, see the JUNOS Classof Service Configuration Guide.

Evaluating a Routing Policy

This section provides information about how routing policies are evaluated. Itdiscusses the following topics:

■ How a Routing Policy Is Evaluated on page 29

■ How a Routing Policy Chain Is Evaluated on page 30

■ How a Routing Policy Expression Is Evaluated on page 31

■ How a Routing Policy Subroutine Is Evaluated on page 31

For specific information about how the various match conditions are evaluated, see“Configuring Match Conditions in Routing Policy Terms” on page 41 and “ExtendedMatch Conditions Configuration” on page 97.

How a Routing Policy Is Evaluated

Figure 8 on page 30 shows how a single routing policy is evaluated. This routingpolicy consists of multiple terms. Each term consists of match conditions and actionsto apply to matching routes. Each route is evaluated against the policy as follows:

1. The route is evaluated against the first term. If it matches, the specified actionis taken. If the action is to accept or reject the route, that action is taken and theevaluation of the route ends. If the next term action is specified, if no action isspecified, or if the route does not match, the evaluation continues as describedin Step 2. If the next policy action is specified, any accept or reject action specifiedin this term is skipped, all remaining terms in this policy are skipped, all otheractions are taken, and the evaluation continues as described in Step 3.

2. The route is evaluated against the second term. If it matches, the specified actionis taken. If the action is to accept or reject the route, that action is taken and theevaluation of the route ends. If the next term action is specified, if no action isspecified, or if the route does not match, the evaluation continues in a similarmanner against the last term. If the next policy action is specified, any acceptor reject action specified in this term is skipped, all remaining terms in this policyare skipped, all other actions are taken, and the evaluation continues as describedin Step 3.

Applying Export Policies to the Forwarding Table ■ 29


3. If the route matches no terms in the routing policy or the next policy action isspecified, the accept or reject action specified by the default policy is taken. Formore information about the default routing policies, see “Default Routing Policiesand Actions” on page 20.

Figure 8: Routing Policy Evaluation

How a Routing Policy Chain Is Evaluated

Figure 9 on page 31 shows how a chain of routing policies is evaluated. These routingpolicies consist of multiple terms. Each term consists of match conditions and actionsto apply to matching routes. Each route is evaluated against the policies as follows:

1. The route is evaluated against the first term in the first routing policy. If itmatches, the specified action is taken. If the action is to accept or reject theroute, that action is taken and the evaluation of the route ends. If the next termaction is specified, if no action is specified, or if the route does not match, theevaluation continues as described in Step 2. If the next policy action is specified,any accept or reject action specified in this term is skipped, all remaining termsin this policy are skipped, all other actions are taken, and the evaluation continuesas described in Step 3.

2. The route is evaluated against the second term in the first routing policy. If itmatches, the specified action is taken. If the action is to accept or reject theroute, that action is taken and the evaluation of the route ends. If the next termaction is specified, if no action is specified, or if the route does not match, theevaluation continues in a similar manner against the last term in the first routingpolicy. If the next policy action is specified, any accept or reject action specifiedin this term is skipped, all remaining terms in this policy are skipped, all otheractions are taken, and the evaluation continues as described in Step 3.

30 ■ How a Routing Policy Chain Is Evaluated


3. If the route does not match a term or matches a term with a next policy actionin the first routing policy, it is evaluated against the first term in the secondrouting policy.

4. The evaluation continues until the route matches a term with an accept or rejectaction defined or until there are no more routing policies to evaluate. If thereare no more routing policies, then the accept or reject action specified by thedefault policy is taken. For more information about default routing policies, see“Default Routing Policies and Actions” on page 20.

Figure 9: Routing Policy Chain Evaluation

How a Routing Policy Expression Is Evaluated

To understand how a policy expression is evaluated, you must first understand theBoolean logical operators and the associated logic used in evaluating a policyexpression. For more information about policy expressions, including how they areevaluated, see “Applying Policy Expressions to Routes Exported from Routing Tables”on page 59.

How a Routing Policy Subroutine Is Evaluated

Figure 10 on page 33 shows how a subroutine is evaluated. The subroutine is includedin the first term of the first routing policy in a chain. Each route is evaluated againstthe subroutine as follows:

1. The route is evaluated against the first term in the first routing policy. If the routedoes not match all match conditions specified before the subroutine, thesubroutine is skipped and the next term in the routing policy is evaluated (seeStep 2). If the route matches all match conditions specified before the subroutine,the route is evaluated against the subroutine. If the route matches the match

How a Routing Policy Expression Is Evaluated ■ 31


conditions in any of the subroutine terms, two levels of evaluation occur in thefollowing order:

a. The actions in the subroutine term are evaluated. If one of the actions isaccept, evaluation of the subroutine ends and a Boolean value of TRUE isreturned to the calling policy. If one of the actions is reject, evaluation of thesubroutine ends and FALSE is returned to the calling policy. If one of theactions is meant to manipulate route characteristics, the characteristic ischanged regardless of whether accept, reject, or neither action is specified.

If the subroutine does not specify the accept, reject or next-policy action, ituses the accept or reject action specified by the default policy, and the valuesof TRUE or FALSE are returned to the calling policy as described in theprevious paragraph. (For information about what happens if a terminationaction is not specified in the term, see “Possible Consequences of TerminationActions in Subroutines” on page 131. For more information about the defaultrouting policies, see “Default Routing Policies and Actions” on page 20.)

b. The calling policy’s subroutine match condition is evaluated. During this partof the evaluation, TRUE equals a match and FALSE equals no match. If thesubroutine returns TRUE to the calling policy, then the evaluation of thecalling policy continues. If the subroutine returns FALSE to the calling policy,then the evaluation of the current term ends and the next term is evaluated.

2. The route is evaluated against the second term in the first routing policy. Forinformation about how the subsequent terms and policies are evaluated, see“How a Routing Policy Chain Is Evaluated” on page 30.

NOTE: If you specify a policy chain as a subroutine, the entire chain acts as a singlesubroutine. As with other chains, the action specified by the default policy is takenonly when the entire chain does not accept or reject a route.

NOTE: If a term defines multiple match conditions, including a subroutine, and aroute does not match a condition specified before the subroutine, the evaluation ofthe term ends and the subroutine is not called and evaluated. In this situation, anaction specified in the subroutine that manipulates a route’s characteristics is notimplemented.

32 ■ How a Routing Policy Subroutine Is Evaluated


Figure 10: Routing Policy Subroutine Evaluation

Routing Policy Tests

After you have created a routing policy, you can use the test policy command toensure that the policy produces the results that you expect before applying the policyin a live environment. This command determines whether the routes specified inyour routing policy are accepted or rejected. The default action of the test policycommand is accept.

NOTE: The default policy of the test policy command accepts all routes from allprotocols. Test output can be misleading when you are evaluating protocol-specificconditions.

For example, if you define a policy for BGP that accepts routes of a specified prefixand apply it to BGP as an export policy, BGP routes that match the prefix areadvertised to BGP peers. However, if you test the same policy using the test policycommand, the test output might indicate that non-BGP routes have been accepted.

Routing Policy Tests ■ 33


34 ■ Routing Policy Tests


Chapter 3

Routing Policy Configuration Statements

This section includes the following minimum configurations:

■ Configuring Routing Policy on page 35

■ Minimum Routing Policy Configuration on page 36

■ Minimum Routing Policy Chain Configuration on page 36

■ Minimum Subroutine Configuration on page 37

Configuring Routing Policy

To create a routing policy, you can include the policy-options statement in theconfiguration:

policy-options {name regular-expression;as-path-group group-name;community name {

invert-match;members [ community-ids ];

}condition condition-name {

if-route-exists address table table-name;}damping name {

disable;half-life minutes;max-suppress minutes;reuse number;suppress number;

}policy-statement policy-name {

term term-name {from {

family;match-conditions;policy subroutine-policy-name;prefix-list name;route-filter destination-prefix match-type <actions>;source-address-filter destination-prefix match-type <actions>;

}to {

match-conditions;

Configuring Routing Policy ■ 35

policy subroutine-policy-name;}then actions;default-action (accept | reject);

}}prefix-list name {

ip-addresses;}

}protocols {

protocol-name {import [ policy-names ];export [ policy-names ];

}}

Minimum Routing Policy Configuration

To define and apply a routing policy, you must include at least the followingstatements at the [edit policy-options] and [edit protocols] hierarchy levels. At the [editprotocols] hierarchy level, you can define one or more policy names.

[edit]policy-options {

policy-statement policy-name {term term-name {

from {family family-name;match-conditions;prefix-list name;route-filter destination-prefix match-type <actions>;source-address-filter destination-prefix match-type <actions>;

}to {

match-conditions;}then actions;

}}

}protocols {


}}

Minimum Routing Policy Chain Configuration

To define and apply a routing policy chain, you must include at least the followingstatements at the [edit policy-options] and [edit protocols] hierarchy levels. At the [edit

36 ■ Minimum Routing Policy Configuration


protocols] hierarchy level, you can define a chain of policy names that are evaluatedin order.



from {family family-name;match-conditions;prefix-list name;route-filter destination-prefix match-type <actions>;source-address-filter destination-prefix match-type <actions>;

}to {


}}policy-statement policy-name {


family family-name;match-conditions;prefix-list name;route-filter destination-prefix match-type <actions>;source-address-filter destination-prefix match-type <actions>;

}to {


}}prefix-list name {

ip-addresses;}

}protocols {


}}

Minimum Subroutine Configuration

To configure a routing policy that calls a subroutine from another routing policy, youmust include at least the following statements at the [edit policy-options] and [editprotocols] hierarchy levels. At the [edit protocols protocol-name (export | import)]hierarchy levels, you can specify one or more policy names.

[edit]

Minimum Subroutine Configuration ■ 37

Chapter 3: Routing Policy Configuration Statements

policy-options {policy-statement subroutine-policy-name {


family family-name;match-conditions;prefix-list name;route-filter destination-prefix match-type <actions>;source-address-filter destination-prefix match-type <actions>;

}to {


}}policy-statement policy-name {


family family-name;policy subroutine-policy-name;

}to {

policy subroutine-policy-name;}then actions;

}}

}protocols {


}}

38 ■ Minimum Subroutine Configuration


Chapter 4

Routing Policy Configuration

This chapter describes the following tasks for configuring routing policies and providesthe following examples:

■ Defining Routing Policies on page 40

■ Configuring Match Conditions in Routing Policy Terms on page 41

■ Configuring Actions in Routing Policy Terms on page 47

■ Applying Routing Policies and Policy Chains to Routing Protocols on page 57

■ Applying Policy Expressions to Routes Exported from Routing Tables on page 59

■ Applying Routing Policies to the Forwarding Table on page 64

■ Configuring Dynamic Routing Policies on page 65

■ Forwarding Packets to the Discard Interface on page 71

■ Testing Routing Policies on page 72

■ Routing Policy Examples on page 72

■ Example: Defining a Routing Policy from BGP to IS-IS on page 73

■ Example: Using Routing Policy to Set a Preference on page 74

■ Example: Importing and Exporting Access and Access-Internal Routes in a RoutingPolicy on page 74

■ Example: Exporting Routes to IS-IS on page 75

■ Example: Applying Export and Import Policies to BGP Peer Groups on page 75

■ Example: Applying a Prefix to Routes Learned from a Peer on page 76

■ Example: Redistributing BGP Routes with a Specific Community Tag intoIS-IS on page 76

■ Example: Redistributing OSPF Routes into BGP on page 76

■ Example: Exporting Direct Routes Into IS-IS on page 77

■ Example: Exporting Internal IS-IS Level 1 Routes to Level 2 on page 77

■ Example: Exporting IS-IS Level 2 Routes to Level 1 on page 78

■ Example: Assigning Different Forwarding Next-Hop LSPs to Different DestinationPrefixes on page 78

■ Example: Grouping Destination Prefixes on page 79

■ Example: Grouping Source Prefixes on page 80

■ 39

■ Example: Grouping Source and Destination Prefixes in a ForwardingClass on page 81

■ Example: Accepting Routes with Specific Destination Prefixes on page 82

■ Example: Accepting Routes from BGP with a Specific DestinationPrefix on page 83

■ Example: Using Routing Policy in an ISP Network on page 83

■ Requesting a Single Default Route on the Customer 1 Router on page 85

■ Requesting Specific Routes on the Customer 2 Router on page 86

■ Configuring a Peer Policy on ISP Router 3 on page 88

■ Configuring Private and Exchange Peers on ISP Router 1 and 2 on page 90

■ Configuring Locally Defined Static Routes on the Exchange Peer 2Router on page 93

■ Configuring Outbound and Generated Routes on the Private Peer 2Router on page 93

Defining Routing Policies

To define a routing policy, include the policy-statement statement:


from {family family-namematch-conditions;policy subroutine-policy-name;prefix-list name;route-filter destination-prefix match-type <actions>;source-address-filter destination-prefix match-type <actions>;

}to {

match-conditions;policy subroutine-policy-name;

}then actions;

}}

You can include this statement at the following hierarchy levels:

■ [edit policy-options]

■ [edit logical-systems logical-system-name policy-options]

policy-name specifies the policy name and must be unique in the configuration. It cancontain letters, numbers, and hyphens (-) and can be up to 255 characters long. Toinclude spaces in the name, enclose the entire name in quotation marks (“ ”).

term-name specifies the name of a term in the policy and must be unique in thatpolicy. It can contain letters, numbers, and hyphens (-) and can be up to 64 characters

40 ■ Defining Routing Policies


long. To include spaces in the name, enclose the entire name in quotation marks(“ ”).

A policy statement can include multiple terms, including a unnamed term whichmust be the final term in the policy. To configure an unnamed term, omit the termstatement when defining match conditions and actions. However, recommend thatyou name all terms.

For information about configuring the components of a term, see the followingsections:

■ Configuring Match Conditions in Routing Policy Terms on page 41

■ Configuring Actions in Routing Policy Terms on page 47

Configuring Match Conditions in Routing Policy Terms

Each term in a routing policy can include two statements, from and to, to define theconditions that a route must match for the policy to apply:

from {family family-name;match-conditions;policy subroutine-policy-name;prefix-list name;route-filter destination-prefix match-type <actions>;source-address-filter source-prefix match-type <actions>;

}to {


}

You can include these statements at the following hierarchy levels:

■ [edit policy-options policy-statement policy-name term term-name]

■ [edit logical-systems logical-system-name policy-options policy-statement policy-nameterm term-name]

In the from statement, you define the criteria that an incoming route must match.You can specify one or more match conditions. If you specify more than one, theyall must match the route for a match to occur.

The from statement is optional. If you omit the from and the to statements, all routesare considered to match.

NOTE: In export policies, omitting the from statement from a routing policy termmight lead to unexpected results. For more information, see “Effect of OmittingIngress Match Conditions from Export Policies” on page 58.

Configuring Match Conditions in Routing Policy Terms ■ 41

Chapter 4: Routing Policy Configuration

In the to statement, you define the criteria that an outgoing route must match. Youcan specify one or more match conditions. If you specify more than one, they allmust match the route for a match to occur. You can specify most of the same matchconditions in the to statement that you can in the from statement. In most cases,specifying a match condition in the to statement produces the same result asspecifying the same match condition in the from statement.

The to statement is optional. If you omit both the to and the from statements, allroutes are considered to match.

NOTE: All conditions in the from and to statements must match for the action to betaken. The match conditions defined in Table 10 on page 42 are effectively a logicalAND operation. Matching in prefix lists and route lists is handled differently. Theyare effectively a logical OR operation. For more information about how matchingoccurs for prefix lists and route lists, including how they are evaluated, see“Configuring Prefix Lists for Use in Routing Policy Match Conditions” on page 117and “Configuring Route Lists for Use in Routing Policy Match Conditions” on page121. If you configure a policy that includes some combination of route filters, prefixlists, and source address filters, they are evaluated according to a logical OR operationor a longest-route match lookup.

Table 10 on page 42 describes the match conditions available for matching anincoming or outgoing route. The table indicates whether you can use the matchcondition in both from and to statements and whether the match condition functionsthe same or differently when used with both statements. If a match conditionfunctions differently in a from statement than in a to statement, or if the conditioncannot be used in one type of statement, there is a separate description for eachtype of statement. Otherwise, the same description applies to both types ofstatements.

Table 10 on page 42 also indicates whether the match condition is standard orextended. In general, the extended match conditions include criteria that are definedseparately from the routing policy (autonomous system [AS] path regular expressions,communities, and prefix lists) and are more complex than standard match conditions.The extended match conditions provide many powerful capabilities. For moreinformation about them, see “Extended Match Conditions Configuration” on page97. The standard match conditions include criteria that are defined within a routingpolicy and are less complex than the extended match conditions.

For examples of how to use the from and to statements, see “Routing Policy Examples”on page 72.

Table 10: Routing Policy Match Conditions

to Statement Descriptionfrom Statement Description

MatchConditionCategoryMatch Condition

Match routes that are contributing to a configured aggregate. This match conditioncan be used to suppress a contributor in an aggregate route.

Standardaggregate-contributor

42 ■ Configuring Match Conditions in Routing Policy Terms


Table 10: Routing Policy Match Conditions (continued)



(Open Shortest Path First [OSPF] only) Area identifier.

In a from statement used with an export policy, match a route learned from thespecified OSPF area when exporting OSPF routes into other protocols.

Standardarea area-id

(Border Gateway Protocol [BGP] only) Name of an AS path regular expression. Formore information, see “Configuring AS Path Regular Expressions to Use as RoutingPolicy Match Conditions” on page 97.

Extendedas-path name

(BGP only) Name of an AS path group regular expression. For more information, see“Configuring AS Path Regular Expressions to Use as Routing Policy Match Conditions”on page 97.

Extendedas-path-groupgroup-name

Color value. You can specify preference values (color and color2) that are finer-grainedthan those specified in the preference and preference2 match conditions. The colorvalue can be a number in the range from 0 through 4,294,967,295 (232 – 1). A lowernumber indicates a more preferred route. For more information about preferencevalues, see the JUNOS Routing Protocols Configuration Guide.

Standardcolor preferencecolor2 preference

Name of one or more communities. If you list more than one name, only one nameneeds to match for a match to occur (the matching is effectively a logical ORoperation). For more information, see “Overview of BGP Communities and ExtendedCommunities as Routing Policy Match Conditions” on page 104.

Extendedcommunity [ names ]

(OSPF only) Match external routes, including routes exported from one level toanother. type is an optional keyword. metric can either be 1 or 2. When you do notspecify type, this condition matches all external routes. When you specify type, thiscondition matches only OSPF routes with the specified OSPF metric type.

Standardexternal [ typemetric-type ]

Name of an address family. family-name can be either inet or inet6. Match the addressfamily IP version 4 (IPv4) or IP version 6 (IPv6) of the route. Default setting is inet.

Standardfamily family-name

Name of one or more routing instances.

Match a route to be advertised over oneof the specified instances.

Name of one or more routing instances.

Match a route learned from one of thespecified instances.

Standardinstanceinstance-name

Name or IP address of one or morerouter interfaces. Do not use thisqualifier with protocols that are notinterface-specific, such as IBGP.

Match a route to be advertised from oneof the specified interfaces.

Name or IP address of one or more routerinterfaces. Do not use this qualifier withprotocols that are not interface-specific,such as IBGP.

Match a route learned from one of thespecified interfaces. Direct routes matchroutes configured on the specifiedinterface.

Standardinterfaceinterface-name

Match a routing policy against the internal flag for simplified next-hop self policies.Standardinternal






(IS-IS only) IS-IS level.

Match a route to be advertised to aspecified level.

(Intermediate System-to-IntermediateSystem [IS-IS] only) IS-IS level.

Match a route learned from a specifiedlevel.

Standardlevel level

(BGP only) BGP local preference (LOCAL_PREF) attribute. The preference value can bea number in the range 0 through 4,294,967,295 (232 – 1).

Standardlocal-preferencevalue

Metric value. You can specify up to four metric values, starting with metric (for thefirst metric value) and continuing with metric2, metric3, and metric4.

(BGP only) metric corresponds to the multiple exit discriminator (MED), and metric2corresponds to the interior gateway protocol (IGP) metric if the BGP next hop runsback through another route.

Standardmetric metric metric2metric metric3 metricmetric4 metric

Multicast scope value of IPv4 or IPv6 multicast group address. The multicast-scopingname corresponds to an IPv4 prefix. You can match on a specific multicast-scopingprefix or on a range of prefixes. Specify orhigher to match on a scope and numericallyhigher scopes, or orlower to match on a scope and numerically lower scopes. Formore information, see the JUNOS Multicast Protocols Configuration Guide.

You can apply this scoping policy to the routing table by including the scope-policystatement at the [edit routing-options] hierarchy level.

The number value can be any hexadecimal number from 0 through F. Themulticast-scope value is a number from 0 through 15, or one of the following keywordswith the associated meanings:

■ node-local (value=1)—No corresponding prefix

■ link-local (value=2)—Corresponding prefix 224.0.0.0/24

■ site-local (value=5)—No corresponding prefix

■ global (value=14)—Corresponding prefix 224.0.1.0 through 238.255.255.255

■ organization-local (value=8)—Corresponding prefix 239.192.0.0/14

Standardmulticast-scoping(scoping-name |number) < (orhigher| orlower) >






Address of one or more neighbors(peers).

For BGP import policies, specifying toneighbor produces the same result asspecifying from neighbor.

For BGP export policies, specifying theneighbor match condition has no effectand is ignored.

For all other protocols, the to statementmatches the neighbor to which theadvertisement is sent.

NOTE: The neighbor address matchcondition is not valid for the RoutingInformation Protocol (RIP).

Address of one or more neighbors (peers).

For BGP, the address can be a directlyconnected or indirectly connected peer.

For all other protocols, the address is theneighbor from which the advertisementis received.

NOTE: The neighbor address matchcondition is not valid for the RoutingInformation Protocol (RIP).

Standardneighbor address

Next-hop address or addresses specified in the routing information for a particularroute. For BGP routes, matches are performed against each protocol next hop.

Standardnext-hop address

You cannot specify this match condition.LDP generates next hop based on RSVPand IP next hops available to usecombined with the forwarding-classmapping.

Standardnext-hop-type merged

(BGP only) BGP origin attribute, which is the origin of the AS path information. Thevalue can be one of the following:

■ egp—Path information originated in another AS.

■ igp—Path information originated within the local AS.

■ incomplete—Path information was learned by some other means.

Standardorigin value

Name of a policy to evaluate as a subroutine.

For information about this extended match condition, see “Configuring Subroutinesin Routing Policy Match Conditions” on page 130.

Extendedpolicy [ policy-name ]

Preference value. You can specify a primary preference value (preference) and asecondary preference value (preference2). The preference value can be a numberfrom 0 through 4,294,967,295 (232 – 1). A lower number indicates a more preferredroute.

To specify even finer-grained preference values, see the color and color2 matchconditions in this table.

For more information about preference values, see the JUNOS Routing ProtocolsConfiguration Guide.

Standardpreferencepreferencepreference2preference






You cannot specify this match condition.Named list of IP addresses. You canspecify an exact match with incomingroutes.

For information about this extendedmatch condition, see “Configuring PrefixLists for Use in Routing Policy MatchConditions” on page 117.

Extendedprefix-listprefix-list-nameip-addresses

You cannot specify this match condition.Named prefix list. You can specify prefixlength qualifiers for the list of prefixes inthe prefix list.

For information about this extendedmatch condition, see “Configuring PrefixLists for Use in Routing Policy MatchConditions” on page 117.

Extendedprefix-list-filterprefix-list-namematch-type

Name of the protocol from which the route was learned or to which the route is beingadvertised. It can be one of the following: access, access-internal, aggregate, bgp,direct, dvmrp, isis, local, ospf, ospf2, ospf3, pim-dense, pim-sparse, rip, ripng, or static.

NOTE: The ospf2 statement matches on OSPFv2 routes. The ospf3 statement matcheson OSPFv3 routes. The ospf statement matches on both OSPFv2 and OSPFv3 routes.

For more information about access routes and access-internal routes, see “Example:Importing and Exporting Access and Access-Internal Routes in a Routing Policy” onpage 74.

Standardprotocol protocol

Name of a routing table. The value of routing-table can be one of the following:

■ inet.0—Unicast IPv4 routes

■ instance-name inet.0—Unicast IPv4 routes for a particular routing instance

■ inet.1—Multicast IPv4 routes

■ inet.2—Unicast IPv4 routes for multicast reverse-path forwarding (RPF) lookup

■ inet.3—MPLS routes

■ mpls.0—MPLS routes for label-switched path (LSP) next hops

■ inet6.0—Unicast IPv6 routes

Standardrib routing-table

You cannot specify this match condition.List of destination prefixes. Whenspecifying a destination prefix, you canspecify an exact match with a specificroute or a less precise match using matchtypes. You can configure either a commonaction that applies to the entire list or anaction associated with each prefix. Formore information, see “Configuring RouteLists for Use in Routing Policy MatchConditions” on page 121.

Extendedroute-filterdestination-prefixmatch-type <actions>






Type of route. The value can be one of the following:

■ external—External route.

■ internal—Internal route.

Standardroute-type value

You cannot specify this match condition.List of multicast source addresses. Whenspecifying a source address, you canspecify an exact match with a specificroute or a less precise match using matchtypes. You can configure either a commonaction that applies to the entire list or anaction associated with each prefix. Formore information, see “Configuring RouteLists for Use in Routing Policy MatchConditions” on page 121.

Extendedsource-address-filterdestination-prefixmatch-type <actions>

(BGP export only) Match on the following types of advertised routes:

■ active—An active BGP route

■ inactive—A route advertised to internal BGP peers as the best external path evenif the best path is an internal route

■ inactive—A route advertised by BGP as the best route even if the routing tabledid not select it to be an active route

Standardstate (active |inactive)

Tag value. You can specify two tag strings: tag (for the first string) and tag2. Thesevalues are local to the router and can be set on configured routes or by using animport routing policy.

You can specify multiple tags under one match condition by including the tags withina bracketed list. For example: from tag [ tag1 tag2 tag3 ];

For OSPF and IS-IS, the tag match conditions match the 32-bit tag field in externallink-state advertisement (LSA) packets.

Standardtag string tag2 string

Configuring Actions in Routing Policy Terms

Each term in a routing policy can include a then statement, which defines the actionsto take if a route matches all the conditions in the from and to statements in the term:

then {actions;

}




Configuring Actions in Routing Policy Terms ■ 47


If a term does not have from and to statements, all routes are considered to match,and the actions apply to them all. For information about the from and to statements,see “Configuring Match Conditions in Routing Policy Terms” on page 41.

You can specify one or more actions in the then statement. There are three types ofactions:

■ Flow control actions, which affect whether to accept or reject the route andwhether to evaluate the next term or routing policy.

■ Actions that manipulate route characteristics.

■ Trace action, which logs route matches.

NOTE: When you specify an action that manipulates the route characteristics, thechanges occur in a copy of the source route. The source route itself does not change.The effect of the action is visible only after the route is imported into or exportedfrom the routing table. To view the source route before the routing policy has beenapplied, use the show route receive-protocol command. To view a route after an exportpolicy has been applied, use the show route advertised-protocol command.

During policy evaluation, the characteristics in the copy of the source route alwayschange immediately after the action is evaluated. However, the route is not copiedto the routing table or a routing protocol until the completion of the policy evaluationis complete.

The then statement is optional. If you omit it, one of the following occurs:

■ The next term in the routing policy, if one is present, is evaluated.

■ If there are no more terms in the routing policy, the next routing policy, if oneis present, is evaluated.

■ If there are no more terms or routing policies, the accept or reject action specifiedby the default policy is taken. For more information, see “Default Routing Policiesand Actions” on page 20.

The following sections discuss the following actions:

■ Configuring Flow Control Actions on page 48

■ Configuring Actions That Manipulate Route Characteristics on page 49

■ Configuring the Default Action in Routing Policies on page 54

■ Configuring a Final Action in Routing Policies on page 56

■ Logging Matches to a Routing Policy Term on page 56

■ Configuring Separate Actions for Routes in Route Lists on page 57

Configuring Flow Control Actions

Table 11 on page 49 lists the flow control actions. You can specify one of theseactions along with the trace action (see “Logging Matches to a Routing Policy Term”

48 ■ Configuring Actions in Routing Policy Terms


on page 56) or one or more of the actions that manipulate route characteristics (see“Configuring Actions That Manipulate Route Characteristics” on page 49).

Table 11: Flow Control Actions

DescriptionFlow ControlAction

Accept the route and propagate it. After a route is accepted, no other terms in the routing policy and noother routing policies are evaluated.

accept

Accept and override any action intrinsic to the protocol. This is a nonterminating policy action.default-action accept

Reject the route and do not propagate it. After a route is rejected, no other terms in the routing policyand no other routing policies are evaluated.

reject

Reject and override any action intrinsic to the protocol. This is a nonterminating policy action.default-action reject

Skip to and evaluate the next term in the same routing policy. Any accept or reject action specified inthe then statement is skipped. Any actions in the then statement that manipulate route characteristicsare applied to the route.

next term is the default control action if a match occurs and you do not specify a flow control action.

next term

Skip to and evaluate the next routing policy. Any accept or reject action specified in the then statementis skipped. Any actions in the then statement that manipulate route characteristics are applied to theroute.

next policy is the default control action if a match occurs, you do not specify a flow control action, andthere are no further terms in the current routing policy.

next policy

Configuring Actions That Manipulate Route Characteristics

You can specify one or more of the actions listed in Table 12 on page 49 to manipulateroute characteristics.

Table 12: Actions That Manipulate Route Characteristics

DescriptionAction

(BGP only) Affix one or more AS numbers at the beginning of the AS path. If specifying morethan one AS number, enclose the numbers in quotation marks (“ ”. The AS numbers are addedafter the local AS number has been added to the path. This action adds AS numbers to ASsequences only, not to AS sets. If the existing AS path begins with a confederation sequenceor set, the affixed AS numbers are placed within a confederation sequence. Otherwise, theaffixed AS numbers are placed with a nonconfederation sequence. For more information, see“Prepending AS Numbers to BGP AS Paths” on page 137.

In JUNOS Release 9.1 and later, you can specify 4-byte AS numbers as defined in RFC 4893,BGP Support for Four-octet AS Number Space, as well as the 2-byte AS numbers that aresupported in earlier releases of the JUNOS Software. For more information about configuringAS numbers, see the JUNOS Routing Protocols Configuration Guide.

as-path-prepend as-path



Table 12: Actions That Manipulate Route Characteristics (continued)

DescriptionAction

(BGP only) Extract the last AS number in the existing AS path and affix that AS number to thebeginning of the AS path n times, where n is a number from 1 through 32. The AS number isadded before the local AS number has been added to the path. This action adds AS numbersto AS sequences only, not to AS sets. If the existing AS path begins with a confederationsequence or set, the affixed AS numbers are placed within a confederation sequence. Otherwise,the affixed AS numbers are placed within a nonconfederation sequence. This option is typicallyused in non-IBGP export policies.

as-path-expand last-as count n

(Class of service [CoS] only) Apply the specified class-of-service parameters to routes installedinto the routing table. For more information, see the JUNOS Class of Service ConfigurationGuide.

class class-name

Set the preference value to the specified value. The color and color2 preference values are evenmore fine-grained than those specified in the preference and preference2 actions. The colorvalue can be a number in the range from 0 through 4,294,967,295 (232 – 1). A lower numberindicates a more preferred route.

If you set the preference with the color action, the value is internal to the JUNOS Software andis not transitive.

For more information about preference values, see the JUNOS Routing Protocols ConfigurationGuide.

color preference color2preference

Change the color preference value by the specified amount. If an addition operation resultsin a value that is greater than 4,294,967,295 (232 – 1), the value is set to 232 – 1. If asubtraction operation results in a value less than 0, the value is set to 0. If an attribute valueis not already set at the time of the addition or subtraction operation, the attribute valuedefaults to a value of 0 regardless of the amount specified. If you perform an addition to anattribute with a value of 0, the number you add becomes the resulting attribute value.

color (add | subtract) numbercolor2 (add | subtract) number

(BGP only) Add the specified communities to the set of communities in the route. For moreinformation, see “Overview of BGP Communities and Extended Communities as RoutingPolicy Match Conditions” on page 104.

community (+ | add) [ names ]

(BGP only) Delete the specified communities from the set of communities in the route. Formore information, see “Overview of BGP Communities and Extended Communities as RoutingPolicy Match Conditions” on page 104.

community (– | delete) [ names ]

(BGP only) Replace any communities that were in the route in with the specified communities.For more information, see “Overview of BGP Communities and Extended Communities asRouting Policy Match Conditions” on page 104.

community (= | set) [ names ]

Set CoS-based next-hop map in forwarding table.cos-next-hop-map map-name

(BGP only) Apply the specified route-damping parameters to the route. These parametersoverride the default damping parameters. This action is useful only in an import policy, becausethe damping parameters affect the state of routes in the routing table.

To apply damping parameters, you must enable BGP flap damping as described in the JUNOSRouting Protocols Configuration Guide, and you must create a named list of parameters asdescribed in “Using Routing Policies to Damp BGP Route Flapping” on page 138.

damping name




DescriptionAction

Maintain packet counts for a route passing through your network, based on the destinationaddress in the packet. You can do the following:

■ Configure group destination prefixes by configuring a routing policy; see “Defining RoutingPolicies” on page 40 and “Routing Policy Examples” on page 72.

■ Apply that routing policy to the forwarding table with the corresponding destination class;see “Applying Routing Policies to the Forwarding Table” on page 64. For more informationabout the forwarding-table configuration statement, see the JUNOS Routing ProtocolsConfiguration Guide.

■ Enable packet counting on one or more interfaces by including the destination-class-usagestatement at the [edit interfaces interface-name unit logical-unit-number family inet accounting]hierarchy level (see the JUNOS Class of Service Configuration Guide). See “Routing PolicyExamples” on page 72.

■ View the output by using one of the following commands: show interfaces destination-class(all | destination-class-name logical-interface-name), show interfaces interface-name extensive,or show interfaces interface-name statistics (see the JUNOS Interfaces Command Reference).

■ To configure a packet count based on the source address, use the source-class statementdescribed in this table.

destination-classdestination-class-name

Set the external metric type for routes exported by OSPF. You must specify the keyword type.external type metric

Create the forwarding class that includes packets based on both the destination address andthe source address in the packet. You can do the following:

■ Configure group prefixes by configuring a routing policy; see “Defining Routing Policies”on page 40 and “Routing Policy Examples” on page 72.

■ Apply that routing policy to the forwarding table with the corresponding forwarding class;see “Applying Routing Policies to the Forwarding Table” on page 64. For more informationabout the forwarding-table configuration statement, see the JUNOS Routing ProtocolsConfiguration Guide.

■ Enable packet counting on one or more interfaces by using the procedure described ineither the destination-class or source-class actions defined in this table.

forwarding-classforwarding-class-name

Choose which next hops, among a set of equal LSP next hops, are installed in the forwardingtable. Use the export policy for the forwarding table to specify the LSP next hop to be usedfor the desired routes. Specify the strict option to enable strict mode, which checks to see ifany of the LSP next hops specified in the policy are up. If none of the specified LSP next hopsare up, the policy installs the discard next hop.

install-nexthop <strict> lsplsp-name

(For export to the forwarding table only) Install all next-hop addresses in the forwarding tableand have the forwarding table perform per-packet load balancing. This policy action allowsyou to optimize VPLS traffic flows across multiple paths. For more information, see “Overviewof Per-Packet Load Balancing” on page 144.

load-balance per-packet

(BGP only) Set the BGP local preference (LOCAL_PREF) attribute. The preference value can bea number in the range from 0 through 4,294,967,295 (232 – 1).

local-preference value




DescriptionAction

Change the local preference value by the specified amount. If an addition operation results ina value that is greater than 4,294,967,295 (232 – 1), the value is set to 232 – 1. If a subtractionoperation results in a value less than 0, the value is set to 0. If an attribute value is not alreadyset at the time of the addition or subtraction operation, the attribute value defaults to a valueof 0 regardless of the amount specified. If you perform an addition to an attribute with a valueof 0, the number you add becomes the resulting attribute value.

For BGP, if the attribute value is not known, it is initialized to 100 before the routing policy isapplied.

local-preference (add | subtract)number

Sets the map-to-interface value which is similar to existing metric or tag actions. Themap-to-interface action requires you to specify one of the following:

■ A logical interface (for example, ge-0/0/0.0). The logical interface can be any interfacethat multicast currently supports, including VLAN and aggregated Ethernet interfaces.

NOTE: If you specify a physical interface as the map-to-interface (for example, ge-0/0/0), avalue of .0 is appended to physical interface to create a logical interface.

■ The keyword self. The self keyword specifies that multicast data packets are sent on thesame interface as the control packets and no mapping occurs.

If no term matches, then no multicast data packets are sent.

map-to-interface (interface-name| self)

Set the metric. You can specify up to four metric values, starting with metric (for the first metricvalue) and continuing with metric2, metric3, and metric4.

(BGP only) metric corresponds to the MED, and metric2 corresponds to the IGP metric if theBGP next hop loops through another router.

metric metric metric2 metricmetric3 metric metric4 metric

Change the metric value by the specified amount. If an addition operation results in a valuethat is greater than 4,294,967,295 (232 – 1), the value is set to 232 – 1. If a subtractionoperation results in a value less than 0, the value is set to 0. If an attribute value is not alreadyset at the time of the addition or subtraction operation, the attribute value defaults to a valueof 0 regardless of the amount specified. If you perform an addition to an attribute with a valueof 0, the number you add becomes the resulting attribute value.

metric (add | subtract) numbermetric2 (add | subtract) numbermetric3 (add | subtract) numbermetric4 (add | subtract) number

Calculate a metric based on the current values of metric and metric2.

This policy action overrides the current value of the metric attribute with the result of theexpression

((x * metric) + a) + ((y * metric2) + b)

where metric and metric2 are the current input values. Metric multipliers are limited in rangeto eight significant digits.

metric expression (metricmultiplier x offset a | metric2multiplier y offset b)

(BGP only) Change the metric (MED) value by the specified negative or positive offset. Thisaction is useful only in an external BGP (EBGP) export policy.

metric (igp | minimum-igp)site-offset




DescriptionAction

Set the next-hop address. When the advertising protocol is BGP, you can set the next hop onlywhen any third-party next hop can be advertised; that is, when you are using IBGP or EBGPconfederations.

If you specify self, the next-hop address is replaced by one of the local router’s addresses. Theadvertising protocol determines which address to use. When the advertising protocol is BGP,this address is set to the local IP address used for the BGP adjacency. A router cannot installroutes with itself as the next hop.

If you specify peer-address, the next-hop address is replaced by the peer’s IP address. Thisoption is valid only in import policies. Primarily used by BGP to enforce using the peer’s IPaddress for advertised routes, this option is meaningful only when the next hop is theadvertising router or another directly connected router.

If you specify discard, the next-hop address is replaced by a discard next hop.

If you specify next-table, the router performs a forwarding lookup in the specified table.

If you specify reject, the next-hop address is replaced by a reject next hop.

next-hop (address | discard |next-table routing-table-name |peer-address | reject | self)

(BGP only) Set the BGP origin attribute to one of the following values:

■ igp—Path information originated within the local AS.

■ egp—Path information originated in another AS.

■ incomplete—Path information learned by some other means.

origin value

Set the preference value. You can specify a primary preference value (preference) and asecondary preference value (preference2). The preference value can be a number in the rangefrom 0 through 4,294,967,295 (232 – 1). A lower number indicates a more preferred route.

To specify even finer-grained preference values, see the color and color2 actions in this table.

If you set the preference with the preference action, the new preference remains associatedwith the route. The new preference is internal to the JUNOS Software and is not transitive.

For more information about preference values, see the JUNOS Routing Protocols ConfigurationGuide.

preference preferencepreference2 preference

Change the preference value by the specified amount. If an addition operation results in avalue that is greater than 4,294,967,295 (232 – 1), the value is set to 232 – 1. If a subtractionoperation results in a value less than 0, the value is set to 0. If an attribute value is not alreadyset at the time of the addition or subtraction operation, the attribute value defaults to a valueof 0 regardless of the amount specified. If you perform an addition to an attribute with a valueof 0, the number you add becomes the resulting attribute value.

preference (add | subtract)number preference2 (add |subtract) number

(OSPF import only) Specify a priority for prefixes included in an OSPF import policy. Prefixeslearned through OSPF are installed in the routing table based on the priority assigned to theprefixes. Prefixes assigned a priority of high are installed first, while prefixes assigned a priorityof low are installed last. For more detailed information about configuring priority for prefixesincluded in OSPF import policy, see the JUNOS Routing Protocols Configuration Guide.

NOTE: OSPF import policy can only be used to set priority or to filter OSPF external routes.If an OSPF import policy is applied that results in a reject terminating action for a nonexternalroute, then the reject action is ignored and the route is accepted anyway.

priority (low | medium | high)




DescriptionAction

Maintain packet counts for a route passing through your network, based on the source address.You can do the following:

■ Configure group source prefixes by configuring a routing policy; see “Defining RoutingPolicies” on page 40 and “Routing Policy Examples” on page 72.

■ Apply that routing policy to the forwarding table with the corresponding source class;see “Applying Routing Policies to the Forwarding Table” on page 64. For more informationabout the forwarding-table configuration statement, see the JUNOS Routing ProtocolsConfiguration Guide.

■ Enable packet counting on one or more interfaces by including the source-class-usageinterface-name statement at the [edit interfaces logical-unit-number unit family inet accounting]hierarchy level (see the JUNOS Network Interfaces Configuration Guide). Also, follow thesource-class-usage statement with the input or output statement to define the inboundand outbound interfaces on which traffic monitored for source-class usage (SCU) is arrivingand departing (or define one interface for both). The complete syntax is [edit interfacesinterface-name unit family inet accounting source-class-usage (input | output | input output)unit-number]. See the example in “Routing Policy Examples” on page 72.

■ View the output by using one of the following commands: show interfaces interface-namesource-class source-class-name, show interfaces interface-name extensive, or show interfacesinterface-name statistics (see the JUNOS Interfaces Command Reference).

■ To configure a packet count based on the destination address, use the destination-classstatement described in this table.

■ For a detailed source-class usage example configuration, see the JUNOS Feature Guide.

source-class source-class-name

Set the tag value. You can specify two tag strings: tag (for the first string) and tag2. Thesevalues are local to the router.

■ For OSPF routes the tag actions set the 32-bit tag field in OSPF external link-stateadvertisement (LSA) packets.

■ For IS-IS routes, the tag actions set the 32-bit flag in the IS-IS IP prefix type length values(TLV).

■ For RIPv2 routes, the tag actions set the route-tag community.

tag tag tag2 tag

Change the tag value by the specified amount. If an addition operation results in a value thatis greater than 4,294,967,295 (232 – 1), the value is set to 232 – 1. If a subtraction operationresults in a value less than 0, the value is set to 0. If an attribute value is not already set at thetime of the addition or subtraction operation, the attribute value defaults to a value of 0regardless of the amount specified. If you perform an addition to an attribute with a valueof 0, the number you add becomes the resulting attribute value.

tag (add | subtract) number tag2(add | subtract) number

Configuring the Default Action in Routing Policies

The default-action statement overrides any action intrinsic to the protocol. This actionis also nonterminating, so that various policy terms can be evaluated before thepolicy is terminated. You can specify a default action, either accept or reject, asfollows:






}to {


}then {

actions;default-action (accept | reject);

}}

}}

The resulting action is set either by the protocol or by the last policy term that ismatched.

Example: Configuring the Default Action in a Routing Policy

Configure a routing policy that matches routes based on three policy terms. If theroute matches the first term, a certain community tag is attached. If the route matchestwo separate terms, then both community tags are attached. If the route does notmatch any terms, it is rejected (protocol’s default action). Note that the terms huband spoke are mutually exclusive.


policy-statement test {term set-default {

then default-action reject;}term hub {

from interface ge-2/1/0.5;then {

community add test-01-hub;default-action accept;

}}term spoke {

from interface [ ge-2/1/0.1 ge-2/1/0.2 ];then {

community add test-01-spoke;default-action accept;

}}term management {

from protocol direct;then {

community add management;



default-action accept;}

}}

}

Configuring a Final Action in Routing Policies

In addition to specifying an action using the then statement in a named term, youcan also specify an action using the then statement in an unnamed term, as follows:




}to {


}then {

actions;}

}then action;

}}

Logging Matches to a Routing Policy Term

If you specify the trace action, the match is logged to a trace file. To set up a tracefile, you must specify the following elements in the global traceoptions statement:

■ Trace filename

■ policy option in the flag statement

For more information about the global traceoptions statement, see the JUNOS RoutingProtocols Configuration Guide.

The following example uses the trace filename of policy-log:


traceoptions {file “policy-log";flag policy;



}}

This action does not affect the flow control during routing policy evaluation.

If a term that specifies a trace action also specifies a flow control action, the nameof the term is logged in the trace file. If a term specifies a trace action only, the word<default> is logged.

Configuring Separate Actions for Routes in Route Lists

If you specify route lists in the from statement, for each route in the list, you canspecify an action to take on that individual route directly, without including a thenstatement. For more information, see “Configuring Route Lists for Use in RoutingPolicy Match Conditions” on page 121.

Applying Routing Policies and Policy Chains to Routing Protocols

For a routing policy to take effect, you must apply it to either a routing protocol orthe forwarding table.

Before applying routing policies to routing protocols, you must know if each protocolsupports import and export policies and the level at which you can apply thesepolicies. Table 5 on page 18 summarizes the import and export policy support foreach routing protocol and the level at which you can apply these policies.

For more information about applying routing policies to individual routing protocols,see the JUNOS Routing Protocols Configuration Guide.

To apply one or more routing policies to a routing protocol, include the import andexport statements:

import [ policy-names ];export [ policy-names ];

You can include the statements at the following hierarchy levels:

■ [edit protocols protocol-name]

■ [edit logical-systems logical-system-name protocols protocol-name]

An ordered set of policies is referred to as a policy chain.

In the import statement, list the names of one or more routing policies to be evaluatedwhen routes are imported into the routing table from the routing protocol.

In the export statement, list the names of one or more routing policies to be evaluatedwhen routes are being exported from the routing table into a dynamic routingprotocol. Only active routes are exported from the routing table.

You can reference the same routing policy one or more times in the same or differentimport and export statements.

Applying Routing Policies and Policy Chains to Routing Protocols ■ 57


The policy framework software evaluates the routing policies in a chain sequentially,from left to right. If an action specified in one of the policies manipulates a routecharacteristic, the policy framework software carries the new route characteristicforward during the evaluation of the remaining policies. For example, if the actionspecified in the first policy of a chain sets a route’s metric to 500, this route matchesthe criterion of metric 500 defined in the next policy.

For information about how the policy framework software evaluates routing policiesand policy chains, see “Evaluating a Routing Policy” on page 29.

Effect of Omitting Ingress Match Conditions from Export Policies

In export policies, omitting the from statement in a term might lead to unexpectedresults. By default, if you omit the from statement, all routes are considered to match.For example, static and direct routes are not exported by BGP by default. However,if you create a term with an empty from statement, these routes inadvertently couldbe exported because they matched the from statement. For example, the followingrouting policy is designed to reject a few route ranges and then export routes learnedby BGP (which is the default export behavior):


autonomous-system 56;}protocols {

bgp {group 4 {

export statics-policy;type external;peer-as 47;neighbor 192.168.1.1;

}}

}policy-options {

policy-statement statics-policy {term term1 {

from {route-filter 192.168.0.0/16 orlonger;route-filter 172.16.1.1/3 orlonger;

}then reject; # reject the prefixes in the route list

}term term2 {

then {accept; # accept all other routes, including static and direct routes

}}

}}

However, this routing policy results in BGP advertising static and direct routes to itspeers because:

■ term1 rejects the destination prefixes enumerated in the route list.

58 ■ Applying Routing Policies and Policy Chains to Routing Protocols


■ term2, because it has no from statement, matches all other routes, includingstatic and direct routes, and accepts all these routes (with the accept statement).

To modify the preceding routing policy so that an IGP does not export unwantedroutes, you can specify the following additional terms:



isis {export statics-policy;

}}policy-options {

policy-statement statics-policy {term term1 {

from {route-filter 192.168.0.0/16 orlonger;route-filter 172.16.1.1/3 orlonger;

}then reject; # reject the prefixes in the route list

}term term2 { # reject direct routes

from protocol direct;then reject;

}term term3 { # reject static routes

from protocol static;then reject;

}term term4 { # reject local routes

from protocol local;then reject;

}term term5 { # reject aggregate routes

from protocol aggregate;then reject;

}term term6 {

then accept; # accept all other routes}

}}

Applying Policy Expressions to Routes Exported from Routing Tables

Policy expressions give the policy framework software a different way to evaluaterouting policies. A policy expression uses Boolean logical operators with policies. Thelogical operators establish rules by which the policies are evaluated.

During evaluation of a routing policy in a policy expression, the policy action ofaccept, reject, or next policy is converted to the value of TRUE or FALSE. This value

Applying Policy Expressions to Routes Exported from Routing Tables ■ 59


is then evaluated against the specified logical operator to produce output of eitherTRUE or FALSE. The output is then converted back to a flow control action of accept,reject, or next policy. The result of the policy expression is applied as it would beapplied to a single policy; the route is accepted or rejected and the evaluation ends,or the next policy is evaluated.

Table 13 on page 60 summarizes the policy actions and their corresponding TRUEand FALSE values and flow control action values. Table 14 on page 60 describes thelogical operators. For complete information about policy expression evaluation, see“How a Policy Expression Is Evaluated” on page 62.

You must enclose a policy expression in parentheses. You can place a policyexpression anywhere in the import or export statements and in the from policystatement.

Table 13: Policy Action Conversion Values

Flow Control Action Conversion ValueConversion ValuePolicy Action

AcceptTRUEAccept

RejectFALSEReject

Next policyTRUENext policy

Table 14: Policy Expression Logical Operators

How Logical Operator Affects Policy Expression EvaluationPolicy Expression LogicLogical Operator

If the first routing policy returns the value of TRUE, the nextpolicy is evaluated. If the first policy returns the value ofFALSE, the evaluation of the expression ends and subsequentpolicies in the expression are not evaluated.

Logical AND requires that all values mustbe TRUE to produce output of TRUE.

Routing policy value of TRUE and TRUEproduces output of TRUE. Value of TRUEand FALSE produces output of FALSE.Value of FALSE and FALSE producesoutput of FALSE.

&& (Logical AND)

If the first routing policy returns the value of TRUE, theevaluation of the expression ends and subsequent policiesin the expression are not evaluated. If the first policy returnsthe value of FALSE, the next policy is evaluated.

Logical OR requires that at least onevalue must be TRUE to produce outputof TRUE.

Routing policy value of TRUE and FALSEproduces output of TRUE. Value of TRUEand TRUE produces output of TRUE.Value of FALSE and FALSE producesoutput of FALSE.

|| (Logical OR)

60 ■ Applying Policy Expressions to Routes Exported from Routing Tables


Table 14: Policy Expression Logical Operators (continued)

How Logical Operator Affects Policy Expression EvaluationPolicy Expression LogicLogical Operator

If used with the logical AND operator and the first routingpolicy value of FALSE is reversed to TRUE, the next policy isevaluated. If the value of TRUE is reversed to FALSE, theevaluation of the expression ends and subsequent policiesin the expression are not evaluated.

If used with the logical OR operator and the first routingpolicy value of FALSE is reversed to TRUE, the evaluation ofthe expression ends and subsequent policies in theexpression are not evaluated. If the value of TRUE is reversedto FALSE, the next policy is evaluated.

If used with a policy and the flow control action is accept ornext policy, these actions are reversed to reject. If the flowcontrol action is reject, this action is reversed to accept.

Logical NOT reverses value of TRUE toFALSE and of FALSE to TRUE. It alsoreverses the actions of accept and nextpolicy to reject, and reject to accept.

! (Logical NOT)

For more information, see the following sections:

■ Policy Expression Examples on page 61

■ How a Policy Expression Is Evaluated on page 62

■ Example: Evaluating Policy Expressions on page 63

Policy Expression Examples

The following examples show how to use the logical operators to create policyexpressions:

■ Logical AND—In the following example, policy1 is evaluated first. If after policy1is evaluated, a value of TRUE is returned, policy2 is evaluated. If a value of FALSEis returned, policy2 is not evaluated.

export (policy1 && policy2)

■ Logical OR—In the following example, policy1 is evaluated first. If after policy1is evaluated, a value of TRUE is returned, policy2 is not evaluated. If a value ofFALSE is returned, policy2 is evaluated.

export (policy1 || policy2)

■ Logical OR and logical AND—In the following example, policy1 is evaluated first.If after policy1 is evaluated, a value of TRUE is returned, policy2 is skipped andpolicy3 is evaluated. If after policy1 is evaluated, a value of FALSE is returned,policy2 is evaluated. If policy2 returns a value of TRUE, policy3 is evaluated. Ifpolicy2 returns a value of FALSE, policy3 is not evaluated.

export [(policy1 || policy2) && policy3]

■ Logical NOT—In the following example, policy1 is evaluated first. If after policy1is evaluated, a value of TRUE is returned, the value is reversed to FALSE and



policy2 is not evaluated. If a value of FALSE is returned, the value is reversed toTRUE and policy2 is evaluated.

export (!policy1 && policy2)

The sequential list [policy1 policy2 policy3] is not the same as the policy expression(policy1 && policy2 && policy3).

The sequential list is evaluated on the basis of a route matching a routing policy. Forexample, if policy1 matches and the action is accept or reject, policy2 and policy3 arenot evaluated. If policy1 does not match, policy2 is evaluated and so on until a matchoccurs and the action is accept or reject.

The policy expressions are evaluated on the basis of the action in a routing policythat is converted to the value of TRUE or FALSE and the logic of the specified logicaloperator. (For complete information about policy expression evaluation, see “Howa Policy Expression Is Evaluated” on page 62.) For example, if policy1 returns a valueof FALSE, policy2 and policy3 are not evaluated. If policy1 returns a value of TRUE,policy2 is evaluated. If policy2 returns a value of FALSE, policy3 is not evaluated. Ifpolicy2 returns a value of TRUE, policy3 is evaluated.

You can also combine policy expressions and sequential lists. In the followingexample, if policy1 returns a value of FALSE, policy2 is evaluated. If policy2 returnsa value of TRUE and contains a next policy action, policy3 is evaluated. If policy2returns a value of TRUE but does not contain an action, including a next policy action,policy3 is still evaluated (because if you do not specify an action, next term or nextpolicy are the default actions). If policy2 returns a value of TRUE and contains anaccept action, policy3 is not evaluated.

export [(policy1 || policy2) policy3]

How a Policy Expression Is Evaluated

During evaluation, the policy framework software converts policy actions to valuesof TRUE or FALSE, which are factors in determining the flow control action that isperformed upon a route. However, the software does not actually perform a flowcontrol action on a route until it evaluates an entire policy expression.

The policy framework software evaluates a policy expression as follows:

1. The software evaluates a route against the first routing policy in a policyexpression and converts the specified or default action to a value of TRUE orFALSE. (For information about the policy action conversion values, see Table 13on page 60.)

2. The software takes the value of TRUE or FALSE and evaluates it against the logicaloperator used in the policy expression (see Table 14 on page 60). Based uponthe logical operator used, the software determines whether or not to evaluatethe next policy, if one is present.

The policy framework software uses a shortcut method of evaluation: if the resultof evaluating a policy predetermines the value of the entire policy expression,the software does not evaluate the subsequent policies in the expression. For

62 ■ Applying Policy Expressions to Routes Exported from Routing Tables


example, if the policy expression uses the logical AND operator and the evaluationof a policy returns the value of FALSE, the software does not evaluate subsequentpolicies in the expression because the final value of the expression is guaranteedto be FALSE no matter what the values of the unevaluated policies.

3. The software performs Step 1 and Step 2 for each subsequent routing policy inthe policy expression, if they are present and it is necessary to evaluate them.

4. After evaluating the last routing policy, if it is appropriate, the software evaluatesthe value of TRUE or FALSE obtained from each routing policy evaluation. Basedupon the logical operator used, it calculates an output of TRUE or FALSE.

5. The software converts the output of TRUE or FALSE back to an action. (Forinformation about the policy action conversion values, see Table 13 on page 60.)The action is performed.

If each policy in the expression returned a value of TRUE, the software convertsthe output of TRUE back to the flow control action specified in the last policy.For example, if the policy expression (policy1 && policy2) is specified and policy1specifies accept and policy2 specifies next term, the next term action is performed.

If an action specified in one of the policies manipulates a route characteristic,the policy framework software carries the new route characteristic forward duringthe evaluation of the remaining policies. For example, if the action specified inthe first policy of a policy expression sets a route’s metric to 500, this routematches the criteria of metric 500 defined in the next policy. However, if a routecharacteristic manipulation action is specified in a policy located in the middleor the end of a policy expression, it is possible, because of the shortcut evaluation,that the policy is never evaluated and the manipulation of the route characteristicnever occurs.

Example: Evaluating Policy Expressions

The following sample routing policy uses three policy expressions:


policy-statement policy-A {from {

route-filter 10.10.0.0/16 orlonger;}then reject;

}}policy-options {

policy-statement policy-B {from {

route-filter 10.20.0.0/16 orlonger;}then accept;

}}protocols {

bgp {neighbor 192.168.1.1 {



export (policy-A && policy-B);}neighbor 192.168.2.1 {

export (policy-A || policy-B);}neighbor 192.168.3.1 {

export (!policy-A);}

}}

The policy framework software evaluates the transit BGP route 10.10.1.0/24 againstthe three policy expressions specified in the sample routing policy as follows:

■ (policy-A && policy-B)—10.10.1.0/24 is evaluated against policy-A. 10.10.1.0/24matches the route list specified in policy-A, so the specified action of reject isreturned. reject is converted to a value of FALSE, and FALSE is evaluated againstthe specified logical AND. Because the result of FALSE is certain no matter whatthe results of the evaluation of policy-B are (in policy expression logic, any resultAND a value of FALSE produces the output of FALSE), policy-B is not evaluatedand the output of FALSE is produced. The FALSE output is converted to reject,and 10.10.1.0/24 is rejected.

■ (policy-A || policy-B)—10.10.1.0/24 is evaluated against policy-A. 10.10.1.0/24matches the route list specified in policy-A, so the specified action of reject isreturned. reject is converted to a value of FALSE, then FALSE is evaluated againstthe specified logical OR. Because logical OR requires at least one value of TRUEto produce an output of TRUE, 10.10.1.0/24 is evaluated against policy-B.10.10.1.0/24 does not match policy-B, so the default action of next-policy isreturned. The next-policy is converted to a value of TRUE, then the value of FALSE(for policy-A evaluation) and TRUE (for policy-B evaluation) are evaluated againstthe specified logical OR. In policy expression logic, FALSE OR TRUE produce anoutput of TRUE. The output of TRUE is converted to next-policy. (TRUE is convertedto next-policy because next-policy was the last action retained by the policyframework software.) policy-B is the last routing policy in the policy expression,so the action specified by the default export policy for BGP, accept, is taken.

■ (!policy-A)—10.10.1.0/24 is evaluated against policy-A. 10.10.1.0/24 matchesthe route list specified in policy-A, so the specified action of reject is returned.reject is converted to a value of FALSE, and FALSE is evaluated against thespecified logical NOT. The value of FALSE is reversed to an output of TRUE basedon the rules of logical NOT. The output of TRUE is converted to accept, and route10.10.1.0/24 is accepted.

Applying Routing Policies to the Forwarding Table

To apply an export routing policy to the forwarding table, include the export statement:

export [ policy-names ];


■ [edit routing-options forwarding-table]

64 ■ Applying Routing Policies to the Forwarding Table


■ [edit logical-systems logical-system-name routing-options forwarding-table]

In the export statement, list the name of the routing policy to be evaluated whenroutes are being exported from the routing table into the forwarding table. Onlyactive routes are exported from the routing table.

You can reference the same routing policy one or more times in the same or adifferent export statement.

For information about how the policy framework software evaluates a routing policy,see “How a Routing Policy Is Evaluated” on page 29.

You can apply export policies to routes being exported from the routing table intothe forwarding table for the following features:

■ Per-packet load balancing

■ Class of service (CoS)

For more information about per-packet load balancing, see “Overview of Per-PacketLoad Balancing” on page 144. For more information about CoS, see the JUNOS Classof Service Configuration Guide.

Configuring Dynamic Routing Policies

The verification process required to commit configuration changes can entail asignificant amount of overhead and time. For example, changing a prefix in one lineof a routing policy that is 20,000 lines long can take up to 20 seconds to commit. Itcan be useful to be able to commit routing policy changes much more quickly.

In JUNOS Release 9.5 and later, you can configure routing policies and certain routingpolicy objects in a dynamic database that is not subject to the same verificationrequired in the standard configuration database. As a result, the time it takes tocommit changes to the dynamic database is much shorter than for the standardconfiguration database. You can then reference these policies and policy objects inrouting policies you configure in the standard database. BGP is the only protocol towhich you can apply routing policies that reference policies and policy objectsconfigured in the dynamic database. After you configure and commit a routing policybased on the objects configured in the dynamic database, you can quickly updateany existing routing policy by making changes to the dynamic database configuration.

CAUTION: Because the JUNOS Software does not validate configuration changes tothe dynamic database, when you use this feature, you should test and verify allconfiguration changes before committing them.

This section discusses the following topics:

■ Configuring Routing Policies and Policy Objects in the DynamicDatabase on page 66

■ Configuring Routing Policies Based on Dynamic DatabaseConfiguration on page 67

Configuring Dynamic Routing Policies ■ 65


■ Applying Dynamic Routing Policies to BGP on page 68

■ Preventing Reestablishment of BGP Peering Sessions After NSR Routing EngineSwitchover on page 68

■ Example: Configuring a BGP Export Policy That References a Dynamic RoutingPolicy on page 69

Configuring Routing Policies and Policy Objects in the Dynamic Database

JUNOS Release 9.5 and later support a configuration database, the dynamic database,which can be edited in a similar way to the standard configuration database butwhich is not subject to the same verification process to commit configuration changes.As a result, the time it takes to commit a configuration change is much faster. Thepolicies and policy objects defined in the dynamic database can then be referencedin routing policies configured in the standard configuration. The dynamic databaseis stored in the /var/run/db/juniper.dyn directory.

To configure the dynamic database, enter the configure dynamic command to enterthe configuration mode for the dynamic database:

user@host> configure dynamicEntering configuration mode

[edit dynamic]user@host#

In this dynamic configuration database, you can configure the following statementsat the [edit policy-options] hierarchy level:

■ as-path name

■ as-path-group group-name

■ community community-name

■ condition condition-name

■ prefix-list prefix-list-name

■ policy-statement policy-statement-name

NOTE: No other configuration is supported at the [edit dynamic] hierarchy level.

Use the policy-statement policy-statement-name statement to configure routing policiesas you would in the standard configuration database.

To exit configuration mode for the dynamic database, issue the exit configuration-modecommand from any level within the [edit dynamic] hierarchy, or use the exit commandfrom the top level.

66 ■ Configuring Dynamic Routing Policies


Configuring Routing Policies Based on Dynamic Database Configuration

In the standard configuration mode, you can configure routing policies that referencepolicies and policy objects configured at the [edit dynamic] hierarchy level in thedynamic database. To define a routing policy that references the dynamic databaseconfiguration, include the dynamic-db statement at the [edit policy-optionspolicy-statement policy-statement-name] hierarchy level:

[edit policy-options]policy-statement policy-statement-name {

dynamic-db;}

You can also define specific policy objects based on the configuration of these objectsin the dynamic database. To define a policy object based on the dynamic database,include the dynamic-db statement with the following statements at the [editpolicy-options] hierarchy level:

■ as-path name

■ as-path-group group-name

■ community community-name

■ condition condition-name

■ prefix-list prefix-list-name

In the standard configuration, you can also define a routing policy that referencesany policy object you have configured in the standard configuration that referencesan object configured in the dynamic database.

For example, in standard configuration mode, you configure a prefix list prefix-listpl2 that references a prefix list, also named prefix-list pl2, that has been configuredin the dynamic database:

[edit policy-options]prefix-list pl2 {

dynamic-db; # Reference a prefix list configured in the dynamic database.}

You then configure a routing policy in the standard configuration that includesprefix-list pl2:

[edit policy-options]policy-statement one {

term term1 {from {

prefix-list pl2; # Include the prefix list configured in the standard configuration# database, but which references a prefix list configured in the dynamicdatabase.

}then accept;

}then reject;



}

If you need to update the configuration of prefix-list pl2, you do so in the dynamicdatabase configuration using the [edit dynamic] hierarchy level. This enables you tomake commit configuration changes to the prefix list more quickly than you can inthe standard configuration database.

NOTE: If you are downgrading the JUNOS Software to JUNOS Release 9.4 or earlier,you must first delete any routing policies that reference the dynamic database. Thatis, you must delete any routing policies or policy objects configured with thedynamic-db statement.

Applying Dynamic Routing Policies to BGP

BGP is the only routing protocol to which you can apply routing policies that referencethe dynamic database configuration. You must apply these policies in the standardconfiguration. Dynamic policies can be applied to BGP export or import policy. Theycan also be applied at the global, group, or neighbor hierarchy level.

To apply a BGP export policy, include the export [ policy-names ] statement at the [editprotocols bgp], [edit protocols bgp group group-name], or [edit protocols bgp groupgroup-name neighbor address] hierarchy level.

[edit]protocols

bgp {export [ policy-names ];

}}

To apply a BGP import policy, include the import [ policy-names ] statement at the[edit protocols bgp], [edit protocols bgp group group-name], or [edit protocols bgp groupgroup-name neighbor address] hierarchy level.

[edit]protocols

bgp {import [ policy-names ];

}}

Include one or more policy names configured in that standard configuration at the[edit policy-options policy-statement] hierarchy level that reference policies configuredin the dynamic database. For more general information about configuring BGP importand export policy, see the JUNOS Routing Protocols Configuration Guide.

Preventing Reestablishment of BGP Peering Sessions After NSR Routing Engine Switchover

If you have active nonstop routing (NSR) enabled, the dynamic database is notsynchronized with the backup Routing Engine. As a result, if a switchover to a backupRouting Engine occurs, import and export policies running on the master Routing



Engine at the time of the switchover might no longer be available. Therefore, youmight want to prevent a BGP peering session from automatically being reestablishedas soon as a switchover occurs.

You can configure the router not to reestablish a BGP peering session after an activenonstop routing switchover either for a specified period or until you manuallyreestablish the session. Include the idle-after-switch-over (seconds | forever) statementat the [edit protocols bgp], [edit protocols bgp group group-name], or [edit protocols bgpgroup group-name neighbor address] hierarchy level:

[edit]bgp {

protocols {idle-after-switch-over (seconds | never);

}}

For seconds, specify a value from 1 through 4,294,967,295 (232 – 1). The BGP peeringsession is not reestablished until after the specified period. If you specify the foreveroption, the BGP peering session is not established until you issue the clear bgp neighborcommand. For more information about BGP and the configuration statement summaryof the idle-after-switch-over statement, see the JUNOS Routing Protocols ConfigurationGuide. For more information about configuring active nonstop routing, see the JUNOSHigh Availability Configuration Guide.

Example: Configuring a BGP Export Policy That References a Dynamic Routing Policy

In this example, you configure the following in the dynamic database: a routingpolicy, policy-statement one, and two prefix lists: prefix-list pl1, which is referencedin policy-statement one, and prefix-list pl2.

In the standard configuration database, you configure the following routing policiesand policy objects: a routing policy (policy-statement one) that references the routingpolicy with the same name configured in the dynamic database; a prefix list(prefix-list pl2) that references the prefix list with the same name configured in thedynamic database; and a routing policy (policy-statement two) that references theprefix list prefix-list pl2 you configured in the standard configuration and referencesthe prefix list with the same name configured in the dynamic database.

You then create and apply a policy expression that includes policy-statement one andpolicy-statement two to BGP export policy in the standard configuration.

In the dynamic database, configure policy-statement one, prefix-list pl1, andprefix-list pl2:

[edit dynamic]policy-options {

prefix-list pl1 {8.8.0.0/16;12.12.12.3/32

}prefix-list pl2;

10.10.0.0/16



}policy-statement one {

term term1from {

prefix-list pl1}then accept;

}then reject;

}}

In the standard configuration database, configure policy-statement one based on thepolicy with the same name configured in the dynamic database. In addition, configureprefix-list pl2, which references the prefix list with the same name in the dynamicdatabase, and configure policy-statement two, which references prefix-list pl2.


prefix-list pl2;dynamic-db; # Reference ’prefix-list pl2’ configured in the dynamic database.

}policy-statement two {

term term1 {from {

prefix-list pl2; # Configure a routing policy that includes a prefix list that# references the dynamic database.

}then accept;

}then reject;

}policy-statement one;

dynamic-db; # Configure a policy in the standard configuration that references# the policy configured in the dynamic database.

}}

Apply a policy expression that includes routing policies one and two to BGP exportpolicy for an internal BGP group test.

[edit]protocols {

bgp {group test;

type internal;local-address 10.255.245.44;export ( one && two ); # If routing policy one returns the value of TRUE, policy

# two is evaluated.# If policy one returns the value of FALSE, the evaluation of the expression# ends and policy two is not evaluated.

}}

}



Forwarding Packets to the Discard Interface

The discard interface allows you to protect a network from denial-of-service (DoS)attacks by identifying the target IP address that is being attacked and configuring apolicy to forward all packets to a discard interface. All packets forwarded to thediscard interface are dropped.

To configure the discard interface, include the dsc statement:

dsc {unit 0 {

family inet {filter {

input filter-name;output filter-name;

}}

}}


■ [edit interfaces interface-name]

■ [edit logical-systems logical-system-name interfaces interface-name]

The dsc interface name denotes the discard interface. The discard interface supportsonly unit 0. For more information about configuring interfaces, see the JUNOS NetworkInterfaces Configuration Guide.

The following two configurations are required to configure a policy to forward allpackets to the discard interface.

Configure an input policy to associate a community with the discard interface:


community community-name members [ community-id ];policy-statement statement-name {

term term-name {from community community-name;then {

next-hop address; # Remote end of the point-to-point interfaceaccept;

}}

}}

Configure an output policy to set up the community on the routes injected into thenetwork:


Forwarding Packets to the Discard Interface ■ 71


policy-statement statement-name {term term-name {

from prefix-list name;then community (set | add | delete) community-name;

}}

}

Testing Routing Policies

Before applying a routing policy, you can issue the test policy command to ensurethat the policy produces the results that you expect:

user@host> test policy policy-name prefix

For more information about test commands, see the JUNOS Routing Protocols andPolicies Command Reference.

Example: Testing a Routing Policy

Test the following policy, which looks for unwanted routes and rejects them:

[edit policy-options]policy-statement reject-unwanted-routes {

term drop-these-routes {from {

route-filter 0/0 exact;route-filter 10/8 orlonger;route-filter 172.16/12 orlonger;route-filter 192.168/16 orlonger;route-filter 224/3 orlonger;

}then reject;

}}

Test this policy against all routes in the routing table:

user@host> test policy reject-unwanted-routes 0/0

Test this policy against a specific set of routes:

user@host> test policy reject-unwanted-routes 10.49.0.0/16

Routing Policy Examples

The following examples show how to configure routing policies for various purposes:

■ Example: Defining a Routing Policy from BGP to IS-IS on page 73

■ Example: Using Routing Policy to Set a Preference on page 74

■ Example: Importing and Exporting Access and Access-Internal Routes in a RoutingPolicy on page 74

72 ■ Testing Routing Policies


■ Example: Exporting Routes to IS-IS on page 75

■ Example: Applying Export and Import Policies to BGP Peer Groups on page 75

■ Example: Applying a Prefix to Routes Learned from a Peer on page 76

■ Example: Redistributing BGP Routes with a Specific Community Tag into IS-ISon page 76

■ Example: Redistributing OSPF Routes into BGP on page 76

■ Example: Exporting Direct Routes Into IS-IS on page 77

■ Example: Exporting Internal IS-IS Level 1 Routes to Level 2 on page 77

■ Example: Exporting IS-IS Level 2 Routes to Level 1 on page 78

■ Example: Assigning Different Forwarding Next-Hop LSPs to Different DestinationPrefixes on page 78

■ Example: Grouping Destination Prefixes on page 79

■ Example: Grouping Source Prefixes on page 80

■ Example: Grouping Source and Destination Prefixes in a Forwarding Class onpage 81

■ Example: Accepting Routes with Specific Destination Prefixes on page 82

■ Example: Accepting Routes from BGP with a Specific Destination Prefix on page83

Example: Defining a Routing Policy from BGP to IS-IS

Accept BGP routes advertised by the peer 192.168.1.1. If a route matches, it isaccepted, and no further evaluation is performed on that route. If a route does notmatch, the accept or reject action specified by the default policy is taken. (For moreinformation about the default routing policies, see “Default Routing Policies andActions” on page 20.) If you apply this routing policy to imported BGP routes, onlythe routes learned from the peer 192.168.1.1 and BGP transit routes are acceptedfrom BGP peers.


policy-statement bgp-to-isis {term term1 {

from {neighbor 192.168.1.1;

}then {

accept;}

}}

}

Example: Defining a Routing Policy from BGP to IS-IS ■ 73


Example: Using Routing Policy to Set a Preference

Define a routing policy which matches routes from specific next hops that are beingadvertised to specific neighbors and which sets a preference. If a route does notmatch the first term, it is evaluated by the second term. If it still does not match, thenext routing policy, if configured, is evaluated; then the accept or reject actionspecified by the default policy is taken. (For more information about the defaultrouting policies, see “Default Routing Policies and Actions” on page 20.)


policy-statement set-preference {term term1 {

from {next-hop [ 10.0.0.1 10.0.0.2 ];

}to {

neighbor 192.168.1.1;}then {

preference 10;}

}term term2 {

from {next-hop 10.0.0.3;

}to {

neighbor 192.168.1.1;}then {

preference 15;}

}}

}

Example: Importing and Exporting Access and Access-Internal Routes in a RoutingPolicy

Configure import and export of access routes and access-internal routes in a routingpolicy. These routes are used by the DHCP application on a video services router torepresent either the end users or the networks behind the attached video servicesrouter. (For more information about configuring DHCP relay on the router, see“Configuring the Extended DHCP Agent” on page 348.)

An access route represents a network behind an attached video services router, andis set to a preference of 13. An access-internal route is a /32 route that represents adirectly attached end user, and is set to a preference of 12.


74 ■ Example: Using Routing Policy to Set a Preference


policy-statement foo {term term1 {

from protocol {access;access-internal;

}then accept;

}}

}

Example: Exporting Routes to IS-IS

Configure the router to export to IS-IS the routes that match the dmz andlocal-customers routing policies.

[edit]protocols {

isis {export [ dmz local-customers ];

}}

Example: Applying Export and Import Policies to BGP Peer Groups

For three BGP peer groups, apply various export and import filters.

[edit]protocols {

bgp {group 1 {

type external;peer-as 47;export local-customers;import [ martian-filter long-prefix-filter as47-filter ];neighbor 192.168.1.4;neighbor 192.168.1.5;

}group 2 {

type external;peer-as 42;export local-customers;import [ martian-filter long-prefix-filter as42-filter ];neighbor 192.168.1.4;neighbor 192.168.1.5;

}group 3 {

type internal;export local-customers;neighbor 10.1.1.1;

}}

}

Example: Exporting Routes to IS-IS ■ 75


Example: Applying a Prefix to Routes Learned from a Peer

Apply the long-prefix-filter prefix only to routes learned from a particular peer withina group.

[edit]protocols {

bgp {group 4 {

type external;peer-as 47;export local-customers;import [ martian-filter as47-filter ];neighbor 192.168.1.4;neighbor 192.168.1.5;neighbor 192.168.1.6 {

import [ martian-filter as47-filter long-prefix-filter ];}

}}

}

Example: Redistributing BGP Routes with a Specific Community Tag into IS-IS

Redistribute BGP routes with a community tag of 444:5 into IS-IS, changing the metricto 14.

[edit]protocols {

isis {export edu-to-isis;

}}policy-options {

community edu members 444:5;policy-statement edu-to-isis {

from {protocol bgp;community edu;

}then {

metric 14;accept;

}}

}

Example: Redistributing OSPF Routes into BGP

Redistribute OSPF routes from Area 1 only into BGP, and do not advertise routeslearned by BGP.

76 ■ Example: Applying a Prefix to Routes Learned from a Peer




bgp {export ospf-into-bgp;group {

type external;peer-as 23;allow {

0.0.0.0/0;}

}}

}policy-options {

policy-statement ospf-into-bgp {term ospf-only {

from {protocol ospf;area 1;then accept;

}}

}}

Example: Exporting Direct Routes Into IS-IS

Export direct routes into IS-IS for all interfaces, even if IS-IS is not configured on aninterface.

[edit]protocols {

isis {export direct-routes;

}}policy-options {

policy-statement direct-routes {from protocol direct;then accept;

}}

Example: Exporting Internal IS-IS Level 1 Routes to Level 2

Export IS-IS Level 1 internal-only routes into Level 2.

[edit]protocols {

isis {export L1-L2;

Example: Exporting Direct Routes Into IS-IS ■ 77


}}policy-statement L1-L2 {

term one {from {

level 1;external;

}then reject;

}term two {

from level 1;to level 2;then accept;

}}

Example: Exporting IS-IS Level 2 Routes to Level 1

Export IS-IS Level 2 routes into Level 1.

[edit]protocols {

isis {export L2-L1;

}}policy-statement L2-L1 {

term one {from level 2;to level 1;then accept;

}}

Example: Assigning Different Forwarding Next-Hop LSPs to Different DestinationPrefixes

Assign different forwarding next-hop LSPs to different destination prefixes learnedfrom BGP.

routing-options {router-id 10.10.20.101;autonomous-system 2;forwarding-table {

export forwarding-policy;}

}policy-options {

policy-statement forwarding-policy {term one {

from {protocol bgp;route-filter 10.1.0.0/16 orlonger;

78 ■ Example: Exporting IS-IS Level 2 Routes to Level 1


}then {

install-nexthop lsp mc-c-lsp-1;accept;

}}term two {


}then {


}}term three {


}then {


}}

}}protocols {

mpls {label-switched-path mc-c-lsp-1 {

from 10.10.20.101;to 10.10.20.103;

}label-switched-path mc-c-lsp-2 {

from 10.10.20.101;to 10.10.20.103;

}label-switched-path mc-c-lsp-3 {

from 10.10.20.101;to 10.10.20.103;

}}

}

Example: Grouping Destination Prefixes

Configure a routing policy to group destination prefixes.


policy-statement set-dest-class {term 1 {

from community nets1;then {

Example: Grouping Destination Prefixes ■ 79


destination-class on-net;accept;

}}term 2 {

from community nets2;then {

destination-class off-net;accept;

}}

}community nets1 [7:8 9:10];community nets2 [1:2 4:5];

}

Apply a routing policy to the forwarding table with the corresponding destinationclass.


forwarding-table {export set-dest-class;

}}

Enable packet counting on an interface.

[edit interfaces]interfaces so-1/0/1 {

unit 0 {family inet6 {

accounting {destination-class-usage;

}}

}}

Example: Grouping Source Prefixes

Configure a routing policy to group source prefixes, and allow prefixes that matchthe policy statement to have a source class created for them.


policy-statement set-gold-class {term {

fromroute-filter 10.210.0.0/16 orlonger;route-filter 10.215.0.0/16 orlonger;then {

source-class gold-class;}

}

80 ■ Example: Grouping Source Prefixes


}}

Apply a routing policy to the forwarding table with the corresponding source class.


forwarding-table {export set-gold-class;

}}

Enable packet counting on an interface. In this example, one interface accommodatesboth input and output.

[edit interfaces]interfaces ge/0/0/0 {

unit 0 {family inet {

accounting {source-class-usage {

input;output;

}}

}}

}

Example: Grouping Source and Destination Prefixes in a Forwarding Class

Configure a routing policy to group source and destination prefixes in a forwardingclass.


policy-statement set-bronze-class {term {

fromroute-filter 10.210.0.0/16 orlonger;route-filter 10.215.0.0/16 orlonger;then {

forwarding-class bronze-class;}

}}

}

Apply a routing policy to the forwarding table with the corresponding forwardingclass.


forwarding-table {export set-bronze-class;

Example: Grouping Source and Destination Prefixes in a Forwarding Class ■ 81


}}

Enable counting of incoming source packets on an interface.

[edit interfaces]interfaces fe/1/0/0 {



input;}

}}

}}interfaces fe/1/0/1 {



output;}

}}

}}interfaces fe/1/0/2 {


accounting {destination-class-usage;

}}

}}

Example: Accepting Routes with Specific Destination Prefixes

Accept routes with destination prefixes 201:db8::8000/32 and 201:db8::8001/32.

[edit policy-options]policy-statement export-exact {

term a {from {

route-filter 201:db8::8000/32 exact;route-filter 201:db8::8001/32 exact;

}then {

accept;}

}term b {

then {

82 ■ Example: Accepting Routes with Specific Destination Prefixes


reject;}

}}

Example: Accepting Routes from BGP with a Specific Destination Prefix

Accepts routes from BGP that have destination prefix 201:db8::8000/32.

[edit policy-options]policy-statement export-exact {

term a {from {

protocol bgp;route-filter 201:db8::8000/32 exact;

}then {

accept;}

}term b {

then {reject;

}}

}

Example: Using Routing Policy in an ISP Network

This section provides an example of how policies might be used in a typical Internetservice provider (ISP) network. In this network example (see Figure 11 on page 84),the ISP’s AS number is 1000. The ISP has two transit peers (AS 11111 and AS 22222)to which it connects at an exchange point. The ISP is also connected to two privatepeers (AS 7000 and AS 8000) with which it exchanges specific customer routes. TheISP has two customers (AS 1234 and AS 2468) to which it connects using BGP.

Example: Accepting Routes from BGP with a Specific Destination Prefix ■ 83


Figure 11: ISP Network Example

In this example, the ISP policies are configured in an outbound direction; that is, theexample focuses on the routes that the ISP announces to its peers and customers,and includes the following:

1. The ISP has been assigned AS 1000 and the routing space of 192.168.0/17.With the exception of the two customer networks shown in Figure 11 on page84, all other customer routes are simulated with static routes.

2. The ISP has connectivity to two different exchange peers: AS 11111 andAS 22222. These peers are used for transit service to other portions of theInternet. This means that the ISP is accepting all routes (the full Internet routingtable) from those BGP peers. To help maintain an optimized Internet routingtable, the ISP is configured to advertise only two aggregate routes to the transitpeers.

3. The ISP also has direct connectivity to two private peers: AS 7000 and AS 8000.The ISP administrators want all data to the private peers to use this direct link.As a result, all the customer routes from the ISP are advertised to those privatepeers. These peers then advertise all their customer routes to the ISP.

4. Finally, the ISP has two customers with which it communicates using BGP:AS 1234 and AS 2468. Each customer has a different set of requirements.

84 ■ Example: Using Routing Policy in an ISP Network



■ Requesting a Single Default Route on the Customer 1 Router on page 85

■ Requesting Specific Routes on the Customer 2 Router on page 86

■ Configuring a Peer Policy on ISP Router 3 on page 88

■ Configuring Private and Exchange Peers on ISP Router 1 and 2 on page 90

■ Configuring Locally Defined Static Routes on the Exchange Peer 2 Router onpage 93

■ Configuring Outbound and Generated Routes on the Private Peer 2 Router onpage 93

Requesting a Single Default Route on the Customer 1 Router

Customer 1 has only a single route to the ISP and is using the ISP for transit service.This customer has requested a single default route (0.0.0.0/0) from the ISP.

[edit]interfaces {

so-0/0/1 {description "Connection to ISP Router 3";unit 0 {


}}

}fxp0 {

description "MGMT INTERFACE - DO NOT DELETE";unit 0 {


}}

}lo0 {


address 192.168.16.1/32;}

}}

}routing-options {

static {route 192.168.16.0/27 reject;route 192.168.16.32/27 reject;route 192.168.16.64/27 reject;route 192.168.16.96/27 reject;route 192.168.16.128/27 reject;route 192.168.16.160/27 reject;route 192.168.16.192/27 reject;

}

Requesting a Single Default Route on the Customer 1 Router ■ 85



bgp {group AS1000-Peers {

type external;export send-statics;peer-as 1000;neighbor 10.222.70.2;

}}

}policy-options {

policy-statement send-statics {term static-routes {

from protocol static;then accept;

}}

}

Requesting Specific Routes on the Customer 2 Router

Customer 2 has a link to the ISP, as well as a link to AS 8000. This customer hasrequested specific customer routes from the ISP, as well as from AS 8000.Customer 2 wants to use the ISP for transit service to the Internet, and has requesteda default route from the ISP.

[edit]interfaces {

so-0/0/1 {description "Connection to ISP Router 3";unit 0 {


}}

}so-0/0/2 {

description "Connection to Private-Peer 2";unit 0 {


}}

}fxp0 {

description "MGMT INTERFACE - DO NOT DELETE";unit 0 {


}}

}lo0 {

86 ■ Requesting Specific Routes on the Customer 2 Router



address 192.168.64.1/32;}

}}

}routing-options {

static {route 192.168.64.0/25 reject;route 192.168.64.128/25 reject;route 192.168.65.0/25 reject;route 192.168.66.0/25 reject;route 192.168.67.0/25 reject;route 192.168.65.128/25 reject;route 192.168.66.128/25 reject;route 192.168.67.128/25 reject;

}autonomous-system 2468;

}protocols {

bgp {group External-Peers {

type external;import inbound-routes;export outbound-routes;neighbor 10.222.61.1 {

peer-as 1000;}neighbor 10.222.6.2 {

peer-as 8000;}

}}

}policy-options {

policy-statement outbound-routes {term statics {


}term internal-bgp-routes {

from {protocol bgp;as-path my-own-routes;

}then accept;

}term no-transit {

then reject;}

}policy-statement inbound-routes {

term AS1000-primary {from {

protocol bgp;

Requesting Specific Routes on the Customer 2 Router ■ 87


as-path AS1000-routes;}then {

local-preference 200;accept;

}}term AS8000-backup {

from {protocol bgp;as-path AS8000-routes;

}then {


}}

}as-path my-own-routes "()";as-path AS1000-routes "1000 .*";as-path AS8000-routes "8000 .*";

}

Configuring a Peer Policy on ISP Router 3

On ISP Router 3, a separate policy is in place for each customer. The default routefor Customer 1 is being sent by the customer-1-peer policy. This policy finds the0.0.0.0/0 default route in inet.0 and accepts it. The policy also rejects all other routes,thereby not sending all BGP routes on the ISP router. The customer-2-peer policy isfor Customer 2 and contains the same policy terms, which also send the default routeand no other transit BGP routes. The additional terms in the customer-2-peer policysend the ISP customer routes to Customer 2. Because there are local static routes onISP router 3 that represent local customers, these routes are sent as well as all otherinternal (192.168.0/17) routes announced to the local router by the other ISP routers.


static { # simulate local customer routesroute 192.168.72.0/22 reject;route 192.168.76.0/22 reject;route 192.168.80.0/22 reject;route 192.168.84.0/22 reject;route 192.168.88.0/22 reject;route 192.168.92.0/22 reject;route 192.168.72.0/21 reject;route 192.168.80.0/21 reject;route 192.168.88.0/21 reject;

}generate { # install a default route if certain routes

route 0.0.0.0/0 policy if-upstream-routes-exist; # from the exchange peers areadvertised using BGP


}

88 ■ Configuring a Peer Policy on ISP Router 3


protocols {bgp {

group Internal-Peers {type internal;local-address 192.168.0.3;export internal-peers;neighbor 192.168.0.1;neighbor 192.168.0.2;

}group Customer-2 {

type external;export customer-2-peer;peer-as 2468;neighbor 10.222.61.2;

}group Customer-1 {

type external;export customer-1-peer;peer-as 1234;neighbor 10.222.70.1;

}}isis {

level 1 disable;interface so-0/0/0.0;interface ge-0/1/0.0;interface lo0.0;

}}policy-options {

policy-statement internal-peers { # advertise local customer routes to peersterm statics {


}term next hop self { # set the BGP routes next hop to self for EBGP

then { # routes advertised to IBGP peersnext-hop self;

}}

}policy-statement if-upstream-routes-exist {

term only-certain-contributing-routes {from { # allow either the 10.100.0.0/17 or the 10.101.0.0/27 route

route-filter 10.100.0.0/17 exact; # route to activate the generated routeroute-filter 10.101.0.0/27 exact; # route to activate the generated route

}then accept; # do not allow any other route to activate

} # the generated route in the routing tableterm reject-all-other-routes {

then reject;}

}policy-statement customer-2--peer { # advertise customer routes to all peers

term statics {from protocol static;

Configuring a Peer Policy on ISP Router 3 ■ 89


then accept;}term-isp-and-customer routes { # advertise internal AS 1000 customer

from { # to the customerprotocol-bgp;route-filter 192.168.0.0/17 orlonger;

}then accept;

} # advertise just the default route to AS 2468term default-route {

from {route-filter 0.0.0.0/exact;

}then accept;

}term reject-all-other-routes { # do not advertise any other routes

then reject;}

}policy-statement customer-1-peer {

term default-route { # advertise just the default route to AS 1234from {

route-filter 0.0.0.0/0 exact;}then accept;


then reject;}

}}

Configuring Private and Exchange Peers on ISP Router 1 and 2

ISP Router 1 and ISP Router 2 each have two policies configured: the private-peerspolicy and the exchange-peers policy. Because of their similar configurations, thisexample describes the configuration only for ISP Router 2.

On ISP Router 2, the private-peers policy sends the ISP customer routes to the PrivatePeer 2 router. The policy accepts all local static routes (local ISP Router 2 customers)and all BGP routes in the 192.168.0/17 range (advertised by other ISP routers). Thesetwo terms represent the ISP customer routes. The final term rejects all other routes,which includes the entire Internet routing table sent by the exchange peers. Theseroutes do not need to be sent to Private Peer 2 for two reasons:

■ The peer already maintains a connection to Exchange Peer 2 in our example,so the routes are redundant.

■ The Private Peer wants customer routes only. The private-peers policyaccomplishes this goal. The exchange-peers policy sends routes to the ExchangePeer 2 router.

In the example, only two routes need to be sent to Exchange Peer 2:

90 ■ Configuring Private and Exchange Peers on ISP Router 1 and 2


■ The aggregate route that represents the AS 1000 routing space of 192.168.0/17.This route is configured as an aggregate route locally and is advertised by theexchange-peers policy.

■ The address space assigned to Customer 2, 192.168.64/22. This smalleraggregate route needs to be sent to Exchange Peer 2 because the customer isalso attached to the AS 8000 peer (Private Peer 2).

Sending these two routes to Exchange Peer 2 allows other networks in the Internetto reach the customer through either the ISP or the Private Peer. If just the PrivatePeer were to advertise the /22 network while the ISP maintained only its /17aggregate, then all traffic destined for the customer would transit AS 8000 only.Because the customer also wants routes from the ISP, the 192.168.64/22 route isannounced by ISP Router 2. Like the larger aggregate route, the 192.168.64/22 routeis configured locally and is advertised by the exchange-peers policy. The final termin that policy rejects all routes, including the specific customer networks of the ISP,the customer routes from Private Peer 1, the customer routes from Private Peer 2,and the routing table from Exchange Peer 1. In essence, this final term prevents theISP from performing transit services for the Internet at large.


static {route 192.168.32.0/22 reject;route 192.168.36.0/22 reject;route 192.168.40.0/22 reject;route 192.168.44.0/22 reject;route 192.168.48.0/22 reject;route 192.168.52.0/22 reject;route 192.168.32.0/21 reject;route 192.168.40.0/21 reject;route 192.168.48.0/21 reject;

}aggregate {

route 192.168.0.0/17;route 192.168.64.0/22;


}protocols {

bgp {group Internal-Peers {

type internal;local-address 192.168.0.2;export internal-peers;neighbor 192.168.0.1;neighbor 192.168.0.3;

}group AS8000-Peers {

type external;export private-peers;peer-as 8000;neighbor 10.222.45.2;

}group AS22222-Peers {

Configuring Private and Exchange Peers on ISP Router 1 and 2 ■ 91


type external;export exchange-peers;peer-as 22222;neighbor 10.222.46.1;

}}isis {

level 1 disable;interface so-0/0/0.0;interface ge-0/2/0.0;interface lo0.0;

}}policy-options {

policy-statement internal-peers {term statics {


}term next-hop-self {

then {next-hop self;

}}

}policy-statement private-peers {

term statics {from protocol static;then accept;

}term isp-and-customer-routes {


}then accept;

}term reject-all {

then reject;}

}policy-statement exchange-peers {

term AS1000-Aggregate {from {

protocol aggregate;route-filter 192.168.0.0/17 exact;

}then accept;

}term Customer-2-Aggregate {

from {protocol aggregate;route-filter 192.168.64.0/22 exact;

}then accept;

}

92 ■ Configuring Private and Exchange Peers on ISP Router 1 and 2


term reject-all-other-routes {then reject;

}}

}

Configuring Locally Defined Static Routes on the Exchange Peer 2 Router

The Exchange Peer 2 router exchanges all routes with all BGP peers. Theoutbound-routes policy for Exchange Peer 2 advertises locally defined static routesusing BGP.

[edit]protocols {

bgp {group Peers {

type external;export outbound-routes;neighbor 10.222.4.1 {

peer-as 11111;}neighbor 10.222.44.2 {

peer-as 8000;}neighbor 10.222.46.2 {

peer-as 1000;}

}}

}policy-options {

policy-statement outbound-routes { # advertise the simulated Internet routesterm statics { # to all BGP peers


}}

}

Configuring Outbound and Generated Routes on the Private Peer 2 Router

The Private Peer 2 router performs two main functions:

■ Advertises routes local to AS 8000 to both the Exchange Peers and the ISP routers.The outbound-routes policy advertises the local static routes (that is, customers)on the router, and also advertises all routes learned by BGP that originated ineither AS 8000 or AS 2468. These routes include other AS 8000 customer routesin addition to the AS 2468 customer. The AS routes are identified by an AS pathregular expression match criteria in the policy.

■ Advertises the 0.0.0.0/0 default route to the AS 2468 customer router. Toaccomplish this, the Private Peer creates a generated route for 0.0.0.0/0 locallyon the router. This generated route is further assigned a policy calledif-upstream-routes-exist, which allows only certain routes to contribute to the

Configuring Locally Defined Static Routes on the Exchange Peer 2 Router ■ 93


generated route, making it an active route in the routing table. Once the routeis active, it can be sent to the AS 2468 router using BGP and the configuredpolicies. The if-upstream-routes-exist policy accepts only the 20.100.0.0/17 routefrom Exchange Peer 2, and rejects all other routes. If the 20.100.0.0/17 routeis withdrawn by the Exchange Peer, the Private Peer loses the 0.0.0.0/0 defaultroute and withdraws the default route from the AS 2468 customer router.

[edit]routing-options { # simulate local customer routes

static {route 172.16.64.0/20 reject;route 172.16.80.0/20 reject;route 172.16.96.0/20 reject;route 172.16.112.0/20 reject;route 172.16.72.0/21 reject;route 172.16.88.0/21 reject;route 172.16.104.0/21 reject;route 172.16.120.0/21 reject;

}generate {

route 0.0.0.0/0 policy if-upstream-routes-exist;}autonomous-system 8000;protocols {

bgp {group External-Peers {

type external;export outbound-routes;neighbor 10.222.44.1 {

peer-as 22222;}neighbor 10.222.45.1 {

peer-as 1000;}

}group Customers {

type external;export internal-routes;neighbor 10.222.6.1 {

peer-as 2468;}

}}

}policy-options {

policy-statement outbound-routes { # advertise local customer routesterm statics {


}term allowed-bgp-routes {

from { # advertise routesas-path [ my-own-routes AS2468-routes ];}then accept;

}

94 ■ Configuring Outbound and Generated Routes on the Private Peer 2 Router


term no-transit {then reject; # do not advertise any other routes

}}policy-statement internal-routes { # advertise local customer routes

term statics {from protocol static;then accept;

}term default-route { # advertise just the default route

from {route-filter 0.0.0.0/0 exact;

}then accept;


then reject;}

}policy-statement if-upstream-routes-exist {

term as-22222-routes {from { # allow the 10.100.0.0/17 route to activate

route-filter 10.100.0.0/17 exact; # the generated route in the routing# table

}then accept;

}term reject-all-other-routes {

then reject; # do not allow any other route to activate} # the generated route in the routing table

}as-path my-own-routes "()";as-path AS2468-routes "2468";

}

Configuring Outbound and Generated Routes on the Private Peer 2 Router ■ 95


96 ■ Configuring Outbound and Generated Routes on the Private Peer 2 Router


Chapter 5

Extended Match Conditions Configuration

This chapter describes how to configure extended match conditions:

■ Configuring AS Path Regular Expressions to Use as Routing Policy MatchConditions on page 97

■ Overview of BGP Communities and Extended Communities as Routing PolicyMatch Conditions on page 104

■ Defining BGP Communities and Extended Communities for Use in Routing PolicyMatch Conditions on page 106

■ Including BGP Communities and Extended Communities in Routing Policy MatchConditions on page 111

■ How BGP Communities and Extended Communities Are Evaluated in RoutingPolicy Match Conditions on page 112

■ Using Routing Policies to Prevent Advertisement of BGP Communities toNeighbors on page 113

■ Examples: Configuring BGP Communities as Routing Policy MatchConditions on page 113

■ Configuring Prefix Lists for Use in Routing Policy Match Conditions on page 117

■ Configuring Route Lists for Use in Routing Policy Match Conditions on page 121

■ Configuring Subroutines in Routing Policy Match Conditions on page 130

■ Configuring Routing Policy Match Conditions Based on Routing TableEntries on page 134

Configuring AS Path Regular Expressions to Use as Routing Policy Match Conditions

A BGP AS path is a path to a destination. An AS path consists of the AS numbers ofnetworks that a packet traverses if it takes the associated route to a destination. TheAS numbers are assembled in a sequence, or path, that is read from right to left. Forexample, for a packet to reach a destination using a route with an AS path 5 4 3 2 1,the packet first traverses AS 1 and so on until it reaches AS 5, which is the last ASbefore its destination.

You can define a match condition based on all or portions of the AS path. To do this,you create a named AS path regular expression and then include it in a routing policy.

Configuring AS Path Regular Expressions to Use as Routing Policy Match Conditions ■ 97

The following sections discuss the following tasks for configuring AS path regularexpressions and provides the following examples:

■ Configuring AS Path Regular Expressions on page 98

■ How AS Path Regular Expressions Are Evaluated on page 103

■ Examples: Configuring AS Path Regular Expressions on page 103

Configuring AS Path Regular Expressions

You can create a named AS path regular expression and then include it in a routingpolicy with the as-path match condition (described in Table 10 on page 42). To createa named AS path regular expression, include the as-path statement:

as-path name regular-expression;




To include the AS path regular expression in a routing policy, include the as-pathmatch condition in the from statement:

as-path name regular-expression;policy-statement policy-name {


names;}

}}

Additionally, you can create a named AS path group made up of AS path regularexpressions and then include it in a routing policy with the as-path-group matchcondition. To create a named AS path group, include the as-path-group statement:

as-path-group group-name {name [ regular-expressions ];

}




To include the AS path regular expressions within the AS path group in a routingpolicy, include the as-path-group match condition in the from statement:

as-path-group group-name {name [ regular-expressions ];

}policy-statement policy-name {

98 ■ Configuring AS Path Regular Expressions to Use as Routing Policy Match Conditions



as-path-group group-name;}

}}

NOTE: You cannot include both of the as-path and as-path-group statements in thesame policy term.

NOTE: You can include the names of multiple AS path regular expressions in theas-path match condition in the from statement. If you do this, only one AS path regularexpression needs to match for a match to occur. The AS path regular expressionmatching is effectively a logical OR operation.

The AS path name identifies the regular expression. It can contain letters, numbers,and hyphens (-), and can be up to 255 characters. To include spaces in the name,enclose the entire name in quotation marks (“ ”).

The regular expression is used to match all or portions of the AS path. It consists oftwo components, which you specify in the following format:

term <operator>

■ term—Identifies an AS. You can specify it in one of the following ways:

■ AS number—The entire AS number composes one term. You cannotreference individual characters within an AS number, which differs fromregular expressions as defined in POSIX 1003.2.

■ Wildcard character—Matches any single AS number. The wildcard characteris a period (.). You can specify multiple wildcard characters.

■ AS path—A single AS number or a group of AS numbers enclosed inparentheses. Grouping the regular expression in this way allows you toperform a common operation on the group as a whole and to give the groupprecedence. The grouped path can itself include operators.

In JUNOS Release 9.1 and later, you can specify 4-byte AS numbers as definedin RFC 4893, BGP Support for Four-octet AS Number Space, as well as the2-byte AS numbers that are supported in earlier releases of the JUNOSSoftware. You can configure a value in the range from 1through 4,294,967,295. For more information about configuring AS numbers,see the JUNOS Routing Protocols Configuration Guide.

■ operator—(Optional) An operator specifying how the term must match. Mostoperators describe how many times the term must be found to be considered amatch (for example, any number of occurrences, or zero, or one occurrence).Table 15 on page 100 lists the regular expression operators supported for ASpaths. You place operators immediately after term with no intervening space,


Chapter 5: Extended Match Conditions Configuration

except for the pipe ( | ) and dash (–) operators, which you place between twoterms, and parentheses, with which you enclose terms.

You can specify one or more term–operator pairs in a single regular expression.

Table 16 on page 100 shows examples of how to define regular expressions to matchAS paths.

Table 15: AS Path Regular Expression Operators

Match DefinitionOperator

At least m and at most n repetitions of term. Both m and n must be positive integers,and m must be smaller than n.

{m,n}

Exactly m repetitions of term. m must be a positive integer.{m}

m or more repetitions of term. m must be a positive integer.{m,}

Zero or more repetitions of term. This is equivalent to {0,}.*

One or more repetitions of term. This is equivalent to {1,}.+

Zero or one repetition of term. This is equivalent to {0,1}.?

One of two terms on either side of the pipe.|

Between a starting and ending range, inclusive.–

A character at the beginning of a community attribute regular expression. Thischaracter is added implicitly; therefore, the use of it is optional.

^

A character at the end of a community attribute regular expression. This characteris added implicitly; therefore, the use of it is optional.

$

A group of terms that are enclosed in the parentheses. Intervening space betweenthe parentheses and the terms is ignored. If a set of parentheses is enclosed inquotation marks with no intervening space "()", it indicates a null path.

( )

Set of AS numbers. One AS number from the set must match. To specify the startand end of a range, use a hyphen (-). A carrot (^) may be used to indicate that itdoes not match a particular AS number in the set, for example [^123].

[ ]

Table 16: Examples of AS Path Regular Expressions

Sample MatchesRegular ExpressionAS Path to Match

12341234AS path is 1234



Table 16: Examples of AS Path Regular Expressions (continued)


1234

1234 1234

1234 1234 1234

Null AS path

1234*Zero or more occurrences of AS number 1234

1234

Null AS path

1234? or1234{0,1}

Zero or one occurrence of AS number 1234

1234

1234 1234

1234 1234 1234

1234 1234 12341234

1234{1,4}One through four occurrences of AS number 1234

12 34

12 12 34

12 12 12 34

12 12 12 12 34

12{1,4} 34One through four occurrences of AS number 12,followed by one occurrence of AS number 34

123

124

125

123–125Range of AS numbers to match a single AS number

Null AS path

123

124 124

125 125 125

123 124 125 123

[123–125]*

1234 56

1234 78

9876 56

3857 78

(. 56) | (. 78) or. (56 | 78)

Path whose second AS number must be 56 or 78



Table 16: Examples of AS Path Regular Expressions (continued)


1234 56 52

34 56 1234

1234 78 39

794 78 2

. (56 | 78)?Path whose second AS number might be 56 or 78

123 56

123 78

123 (56|78)Path whose first AS number is 123 and second ASnumber is either 56 or 78

1234 1234 5678 1234 5 6 7 8. .* or . .{0,}Path of any length, except nonexistent, whosesecond AS number can be anything, includingnonexistent

1 2 31 2 3AS path is 1 2 3

1 2 3

1 2 3 3

1 2 3 3 3

1 2 3+One occurrence of the AS numbers 1 and 2, followedby one or more occurrences of the AS number 3

1 2 3

1 1 2 3

1 1 2 2 3

1 1 2 2 3 3

1+ 2+ 3+One or more occurrences of AS number 1, followedby one or more occurrences of AS number 2,followed by one or more occurrences of ASnumber 3

4 5 6

4 5 6 7 8 9

4 5 6 .*Path of any length that begins with AS numbers 4,5, 6

4 5 6

1 2 3 4 5 6

4 9 4 5 6

.* 4 5 6Path of any length that ends with AS numbers 4,5, 6

5

12

18

5 | 12 | 18AS path 5, 12, or 18

Configuring a Null AS Path

You can use AS path regular expressions to create a null AS path that matches routes(prefixes) that have originated in your AS. These routes have not been advertised to



your AS by any external peers. To create a null AS path, use the parentheses operatorenclosed in quotation marks with no intervening spaces:

“()"

In the following example, locally administered AS 2 is connected to AS 1 (10.2.2.6)and AS 3. AS 3 advertises its routes to AS 2, but the administrator for AS 2 does notwant to advertise AS 3 routes to AS 1 and thereby allow transit traffic from AS 1 toAS 3 through AS 2. To prevent transit traffic, the export policy only-my-routes is appliedto AS 1. It permits advertisement of routes from AS 2 to AS 1 but preventsadvertisement of routes for AS 3 (or routes for any other connected AS) to AS 1:

[edit policy-options]null-as "()";policy-statement only-my-routes {

term just-my-as {from {

protocol bgp;as-path null-as;

}then accept;

}term nothing-else {

then reject;}

}protocol {

bgp {neighbor 10.2.2.6 {

export only-my-routes;}

}}

How AS Path Regular Expressions Are Evaluated

AS path regular expressions implement the extended (modern) regular expressionsas defined in POSIX 1003.2. They are identical to the UNIX regular expressions withthe following exceptions:

■ The basic unit of matching in an AS path regular expression is the AS numberand not an individual character.

■ A regular expression matches a route only if the AS path in the route exactlymatches regular-expression. The equivalent UNIX regular expression is^regular-expression$. For example, the AS path regular expression 1234 isequivalent to the UNIX regular expression ^1234$.

■ You can specify a regular expression using wildcard operators.

Examples: Configuring AS Path Regular Expressions

Exactly match routes with the AS path 1234 56 78 9 and accept them:

[edit]



policy-options {wellington "1234 56 78 9";policy-statement from-wellington {

term term1 {from as-path wellington;

}then {

preference 200;accept;

}term term2 {

then reject;}

}}

Match alternate paths to an AS and accept them after modifying the preference:


wellington-alternate “1234{1,6} (56|47)? (78|101|112)* 9+”;policy-statement from-wellington {

from as-path wellington-alternate;}then {


}}

}

Match routes with an AS path of 123, 124, or 125 and accept them after modifyingthe preference:


addison "123–125";policy-statement from-addison {

from as-path addison;}then {


}}

}

Overview of BGP Communities and Extended Communities as Routing Policy MatchConditions

A BGP community is a group of destinations that share a common property.Community information is included as a path attribute in BGP update messages. Thisinformation identifies community members and allows you to perform actions ona group without having to elaborate upon each member. You can create a named

104 ■ Overview of BGP Communities and Extended Communities as Routing Policy Match Conditions


community and include it in a routing policy with the community match condition,which is described in Table 10 on page 42. For a list of the actions that can beconfigured for communities, see Table 12 on page 49.

You can configure the standard community attribute and the extended communitiesattribute for inclusion in BGP update messages. The standard community attributeis four octets whereas the extended communities attribute is eight octets, providinga larger range for grouping or categorizing communities. You can use communityand extended communities attributes to trigger routing decisions, such as acceptance,rejection, preference, or redistribution.

The BGP community attribute format is as-number:community-value. The BGP extendedcommunities attribute format instead has three fields:type:administrator:assigned-number.

When specifying community IDs for the standard community attribute, you can useUNIX-style regular expressions. Regular expressions are not supported for theextended communities attribute.

NOTE: You can assign community tags to non-BGP routes through configuration (forstatic, aggregate, or generated routes) or an import routing policy. These tags canthen be matched when BGP exports the routes.

To use a BGP community or extended community as a routing policy match condition,you define the community and its members and then include the community in amatch condition.

The JUNOS Software supports the following standard:

■ RFC 1997, BGP Communities Attribute

For configuration instructions, see the following topics:

■ Defining BGP Communities and Extended Communities for Use in Routing PolicyMatch Conditions on page 106

■ Including BGP Communities and Extended Communities in Routing Policy MatchConditions on page 111

■ How BGP Communities and Extended Communities Are Evaluated in RoutingPolicy Match Conditions on page 112

■ Using Routing Policies to Prevent Advertisement of BGP Communities toNeighbors on page 113

■ Examples: Configuring BGP Communities as Routing Policy Match Conditionson page 113

Overview of BGP Communities and Extended Communities as Routing Policy Match Conditions ■ 105


Defining BGP Communities and Extended Communities for Use in Routing PolicyMatch Conditions

To use a BGP community or extended community as a routing policy match condition,you define the community as described in the following sections:

■ Defining BGP Communities for Use in Routing Policy Match Conditions on page 106

■ Defining BGP Extended Communities for Use in Routing Policy MatchConditions on page 109

■ Inverting Community Matches on page 111

Defining BGP Communities for Use in Routing Policy Match Conditions

To create a named BGP community and define the community members, includethe community statement:

community name {invert-match;members [ community-ids ];

}




name identifies the community. It can contain letters, numbers, and hyphens (-) andcan be up to 255 characters long. To include spaces in the name, enclose the entirename in quotation marks (“ ”).

community-ids identifies one or more members of the community. Each communityID consists of two components, which you specify in the following format:

as-number:community-value;

■ as-number—AS number of the community member. It can be a value from 0through 65,535. For more information about configuring AS numbers, see theJUNOS Routing Protocols Configuration Guide. You can use the following notationin specifying the AS number:

■ String of digits.

■ Asterisk (*)—A wildcard character that matches all AS numbers. (In thedefinition of the community attribute, the asterisk also functions as describedin Table 17 on page 108.)

■ Period (.)—A wildcard character that matches any single digit in an ASnumber.

■ Group of AS numbers—A single AS number or a group of AS numbersenclosed in parentheses. Grouping the numbers in this way allows you toperform a common operation on the group as a whole and to give the group

106 ■ Defining BGP Communities and Extended Communities for Use in Routing Policy Match Conditions


precedence. The grouped numbers can themselves include regular expressionoperators. For more information about regular expressions, see “Using UNIXRegular Expressions in Community Names” on page 107.

■ community-value—Identifier of the community member. It can be a numberfrom 0 through 65,535. You can use the following notation in specifying thecommunity ID:

■ String of digits.

■ Asterisk (*)—A wildcard character that matches all community values. (Inthe definition of the community attribute, the asterisk also functions asdescribed in Table 17 on page 108.)

■ Period (.)—A wildcard character that matches any single digit in a communityvalue number.

■ Group of community value numbers—A single community value number ora group of community value numbers enclosed in parentheses. Groupingthe regular expression in this way allows you to perform a common operationon the group as a whole and to give the group precedence. The grouped pathcan itself include regular expression operators.

You can also include one of the following well-known community names (definedin RFC 1997, BGP Communities Attribute) in the community-ids option for the membersstatement:

■ no-advertise—Routes in this community name must not be advertised to otherBGP peers.

■ no-export—Routes in this community must not be advertised outside a BGPconfederation boundary.

■ no-export-subconfed—Routes in this community must not be advertised to externalBGP peers, including peers in other members’ ASs inside a BGP confederation.

Using UNIX Regular Expressions in Community Names

When specifying the members of a named BGP community (in themembers [ community-ids ] statement), you can use UNIX-style regular expressionsto specify the AS number and the member identifier. A regular expression consistsof two components, which you specify in the following format:

term operator;

term identifies the string to match.

operator specifies how the term must match. Table 17 on page 108 lists the regularexpression operators supported in community IDs. You place an operator immediatelyafter term with no intervening space, except for the pipe ( | ) and dash (–) operators,which you place between two terms, and parentheses, with which you enclose terms.Table 18 on page 109 shows examples of how to define community-ids using communityregular expressions. The operator is optional.

Defining BGP Communities and Extended Communities for Use in Routing Policy Match Conditions ■ 107


Community regular expressions are identical to the UNIX regular expressions. Bothimplement the extended (or modern) regular expressions as defined in POSIX 1003.2.

Community regular expressions evaluate the string specified in term on acharacter-by-character basis. For example, if you specify 1234:5678 as term, theregular expressions see nine discrete characters, including the colon (:), instead oftwo sets of numbers (1234 and 5678) separated by a colon.

NOTE: In JUNOS Release 9.1 and later, you can specify 4-byte AS numbers as definedin RFC 4893, BGP Support for Four-octet AS Number Space, as well as the 2-byte ASnumbers that are supported in earlier releases of the JUNOS Software. For moreinformation about configuring AS numbers, see the JUNOS Routing ProtocolsConfiguration Guide.

Table 17: Community Attribute Regular Expression Operators


At least m and at most n repetitions of term. Both m and n must be positive integers,and m must be smaller than n.

{m,n}

Exactly m repetitions of term. m must be a positive integer.{m}

m or more repetitions of term. m must be a positive integer.{m,}

Zero or more repetitions of term. This is equivalent to {0,}.*

One or more repetitions of term. This is equivalent to {1,}.+

Zero or one repetition of term. This is equivalent to {0,1}.?

One of the two terms on either side of the pipe.|

Between a starting and ending range, inclusive.–

Character at the beginning of a community attribute regular expression. Werecommend the use of this operator for the clearest interpretation of your communityattribute regular expression. If you do not use this operator, the regular expression123:456 could also match a route tagged with 5123:456.

^

Character at the end of a community attribute regular expression. We recommendthe use of this operator for the clearest interpretation of your community attributeregular expression. If you do not use this operator, the regular expression 123:456could also match a route tagged with 123:4563.

$

Set of characters. One character from the set can match. To specify the start andend of a range, use a hyphen (-). To specify a set of characters that do not match,use the caret (^) as the first character after the opening square bracket ([).

[ ]

Group of terms that are enclosed in parentheses. If enclosed in quotation markswith no intervening space ("()" ), indicates a null. Intervening space between theparentheses and the terms is ignored.

( )



Table 17: Community Attribute Regular Expression Operators (continued)


Characters (such as space, tab, question mark, and bracket) that are enclosed withinquotation marks in a community attribute regular expression indicate specialcharacters.

“ ”

Table 18: Examples of Community Attribute Regular Expressions

Sample MatchesRegular ExpressionCommunity Attribute to Match

56:1000

78:65000

^((56) | (78)):(.*)$AS number is 56 or 78. Community value is anynumber.

56:2

56:222

56:234

^56:(2.*)$AS number is 56. Community value is any numberthat starts with 2.

1234:5

78:2357

34:65009

^(.*):(.*[579])$AS number is any number. Community value isany number that ends with 5, 7, or 9.

56:22

56:21197

78:2678

^((56) |(78)):(2.*[2–8])$

AS number is 56 or 78. Community value is anynumber that starts with 2 and ends with 2through 8.

Defining BGP Extended Communities for Use in Routing Policy Match Conditions

To create a named BGP community and define the community members, includethe community statement:

community name {invert-match;members [ community-ids ];

}




name identifies the community. It can contain letters, numbers, and hyphens (-) andcan be up to 255 characters long. To include spaces in the name, enclose the entirename in quotation marks (“ ”).

Defining BGP Communities and Extended Communities for Use in Routing Policy Match Conditions ■ 109


community-ids identifies one or more members of the community. Each communityID consists of three components, which you specify in the following format:

type:administrator:assigned-number

type is the type of extended community and can be either the 16-bit numericalidentifier of a specific BGP extended community or one of these types:

■ bandwidth—Sets up the bandwidth extended community. Specifying linkbandwidth allows you to distribute traffic unequally among different BGP paths.

NOTE: The link bandwidth attribute does not work concurrently with per-prefix loadbalancing.

■ domain-id—Identifies the OSPF domain from which the route originated.

■ origin—Identifies where the route originated.

■ rt-import—Identifies the route to install in the routing table.

NOTE: You must identify the route by an IP address, not an AS number.

■ src-as—Identifies the AS from which the route originated. You must specify anAS number, not an IP address.

NOTE: You must identify the AS by an AS number, not an IP address.

■ target—Identifies the destination to which the route is going.

administrator is the administrator. It is either an AS number or an IP version 4 (IPv4)address prefix, depending on the type of extended community.

assigned-number identifies the local provider.

In JUNOS Release 9.1 and later, you can specify 4-byte AS numbers as defined inRFC 4893, BGP Support for Four-octet AS Number Space, as well as the 2-byte ASnumbers that are supported in earlier releases of the JUNOS Software. In plain-numberformat, you can configure a value in the range from 1 through 4,294,967,295. Toconfigure a target or origin extended community that includes a 4-byte AS numberin the plain-number format, append the letter “L” to the end of number. For example,a target community with the 4-byte AS number 334,324 and an assigned numberof 132 is represented as target:334324L:132.

In JUNOS Release 9.2 and later, you can also use AS-dot notation when defining a4-byte AS number for the target and origin extended communities. Specify two integersjoined by a period: 16-bit high-order value in decimal.16-bit low-order value in decimal.For example, the 4-byte AS number represented in plain-number format as 65546is represented in AS-dot notation as 1.10.



For more information about configuring AS numbers, see the JUNOS Routing ProtocolsConfiguration Guide.

Examples: Defining BGP Extended Communities

Configure a target community with an administrative field of 10458 and an assignednumber of 20:

[edit policy-options]community test-a members [ target:10458:20 ];

Configure a target community with an administrative field of 10.1.1.1 and an assignednumber of 20:

[edit policy-options]community test-a members [ target:10.1.1.1:20 ];

Configure an origin community with an administrative field of 10.1.1.1 and anassigned number of 20:

[edit policy-options]community test-a members [ origin:10.1.1.1:20 ];

Inverting Community Matches

To invert the results of the community expression matching, include the invert-matchstatement:

invert-match;


■ [edit policy-options community name]

■ [edit logical-systems logical-system-name policy-options community name]

Including BGP Communities and Extended Communities in Routing Policy MatchConditions

To include a BGP community or extended community in a routing policy matchcondition, include the community condition in the from statement of a policy term:

from {community [ names ];

}




Including BGP Communities and Extended Communities in Routing Policy Match Conditions ■ 111


Additionally, you can explicitly exclude BGP community information with a staticroute by using the none option. Include this option when configuring an individualroute in the route portion to override a community option specified in the defaultsportion.

NOTE: You can include the names of multiple communities in the community matchcondition. If you do this, only one community needs to match for a match to occur(matching is effectively a logical OR operation).

How BGP Communities and Extended Communities Are Evaluated in Routing PolicyMatch Conditions

When you use BGP communities and extended communities as match conditionsin a routing policy, the policy framework software evaluates them as follows:

■ Each route is evaluated against each named community in a routing policy fromstatement. If a route matches one of the named communities in the fromstatement, the evaluation of the current term continues. If a route does notmatch, the evaluation of the current term ends.

■ The route is evaluated against each member of a named community. Theevaluation of all members must be successful for the named communityevaluation to be successful.

■ Each member in a named community is identified by either a literal communityvalue or a regular expression (for information about using regular expressions,see “Using UNIX Regular Expressions in Community Names” on page 107). Eachmember is evaluated against each community associated with the route.(Communities are an unordered property of a route. For example, 1:2 3:4 is thesame as 3:4 1:2.) Only one community from the route is required to match forthe member evaluation to be successful.

■ Community regular expressions are evaluated on a character-by-character basis.For example, if a route contains community 1234:5678, the regular expressionssee nine discrete characters, including the colon (:), instead of two sets of numbers(1234 and 5678) separated by a colon. For example:


policy-statement one {from {

community [comm-one comm-two];}

}community comm-one members [ 1:2 "^4:(5|6)$" ];community comm-two members [ 7:8 9:10 ];

}

NOTE: If a community member is a regular expression, a string match is made ratherthan a numeric match.

112 ■ How BGP Communities and Extended Communities Are Evaluated in Routing Policy Match Conditions


■ To match routing policy one, the route must match either comm-one or comm-two.

■ To match comm-one, the route must have a community that matches 1:2 and acommunity that matches 4:5 or 4:6.

■ To match comm-two, the route must have a community that matches 7:8 and acommunity that matches 9:10.

Using Routing Policies to Prevent Advertisement of BGP Communities to Neighbors

By default, communities are sent to BGP peers. To suppress the advertisement ofcommunities to a neighbor, remove all communities. When the result of an exportpolicy is an empty set of communities, the community attribute is not sent. To removeall communities, first define a wildcard set of communities (here, the community isnamed wild):

[edit policy-options]community wild members "* : *";

Then, in the routing policy statement, specify the community delete action:

[edit policy-options]policy-statement policy-name {

term term-name {then community delete wild;

}}

To suppress a particular community from any AS, define the community as communitywild members "*:community-value".

Examples: Configuring BGP Communities as Routing Policy Match Conditions

Create a community named dunedin and apply it in a routing policy statement:


community dunedin members [ 56:2379 23:46944 ];policy-statement from-dunedin {

from community dunedin;then {

metric 2;preference 100;next policy;

}}

}

The preceding example modifies the metric and preference for routes that containmembers of community dunedin only.

Using Routing Policies to Prevent Advertisement of BGP Communities to Neighbors ■ 113


NOTE: You cannot set or add a community in a policy whose members use regularexpressions or a wildcard.

Delete a particular community from a route, leaving remaining communitiesuntouched:


community dunedin members 701:555;policy-statement delete-dunedin {

then {community delete dunedin;

}}

}

Remove any community from a route with the AS number of 65534 or 65535:


community my-as1-transit members [ 65535:10 65535:11 ];community my-as2-transit members [ 65534:10 65534:11 ];community my-wild members [ 65534:* 65535:* ];policy-statement delete-communities {

from {community [ my-as1-transit my-as2-transit ];

}then {

community delete my-wild;}

}}

Match the set of community members 5000, 5010, 5020, 5030, and so on up to 5090:


community customers members "^1111:50.0$";policy-statement advertise-customers {

from community customers;then accept;

}}

Reject routes that are longer than /19 in Class A space, /16 in Class B space, and/24 in Class C space:

[edit policy-options]community auckland-accept members 555:1;policy-statement drop-specific-routes {

from {route-filter 0.0.0.0/1 upto /19 {

community add auckland-accept;next policy;

114 ■ Examples: Configuring BGP Communities as Routing Policy Match Conditions


}route-filter 172.16.0.0/2 upto /16 {


}route-filter 192.168.0.0/3 upto /24 {


}}then reject;

}

In the preceding example, for routes that are not rejected, the tag auckland-accept isadded.

Create routing policies to handle peer and customer communities. This exampledoes the following:

■ Customer routes that match the attributes defined in the lcl20x-low communities,for example, lcl201-low, are accepted and their local preference is changed to 80.

■ Customer routes that match the attributes defined in the lcl20x-high communities,for example, lcl201-high, are accepted and have their local preference changedto 120.

■ Internal routes that match the attributes defined in the internal20x communities,for example, internal201, are rejected and not advertised to customers.

■ Routes received from a peer are assigned a metric of 10 and the communitydefined in peer201.

■ Routes that match the attributes defined in the prepend20x-x communities, forexample, prepend201-1, prepend201-2, or prepend201-3, are sent to peers andhave the AS number 201 prepended the specified number of times.

■ Routes that match the attributes defined in the peer20x, custpeer20x, andinternal20x communities, for example, peer201, custpeer201, or internal201,respectively, are rejected and not advertised to peers.


community internal201 members 201:112;community internal202 members 202:112;community internal203 members 203:112;community internal204 members 204:112;community internal205 members 205:112;community peer201 members 201:555;community peer202 members 202:555;community peer203 members 203:555;community peer204 members 204:555;community peer205 members 205:555;community custpeer201 members 201:20;community custpeer202 members 202:20;community custpeer203 members 203:20;community custpeer204 members 204:20;community custpeer205 members 205:20;

Examples: Configuring BGP Communities as Routing Policy Match Conditions ■ 115


community prepend201-1 members 201:1;community prepend202-1 members 202:1;community prepend203-1 members 203:1;community prepend204-1 members 204:1;community prepend205-1 members 205:1;community prepend201-2 members 201:2;community prepend202-2 members 202:2;community prepend203-2 members 203:2;community prepend204-2 members 204:2;community prepend205-2 members 205:2;community prepend201-3 members 201:3;community prepend202-3 members 202:3;community prepend203-3 members 203:3;community prepend204-3 members 204:3;community prepend205-3 members 205:3;community lcl201-low members 201:80;community lcl202-low members 202:80;community lcl203-low members 203:80;community lcl204-low members 204:80;community lcl205-low members 205:80;community lcl20x-high members "^20 [ 1-5 ] : 120$";policy-statement in-customer {

term term1 {from {

protocol bgp;community lcl20x-high;

}then {


}}term term2 {

from {protocol bgp;community [ lcl201-high lcl202-high lcl203-high lcl204-high lcl205-high

];}then local-preference 120;

}then next policy;

}policy-statement out-customer {

term term1 {from {

protocol bgp;community [internal201 internal202 internal203 internal204 internal205];

}then reject;

}then next policy;

}policy-statement in-peer {

from protocol bgp;then {

metric 10;

116 ■ Examples: Configuring BGP Communities as Routing Policy Match Conditions


community set peer201;}

}policy-statement out-peer {

term term1 {from {

protocol bgp;community [ prepend201-1 prepend202-1 prepend203-1 prepend204-1

prepend205-1 ];}then as-path-prepend 201;

}term term2 {

from {protocol bgp;community [ prepend201-2 prepend202-2 prepend203-2 prepend204-2

prepend205-2 ];}then as-path-prepend "201 201";

}term term3 {

from {protocol bgp;community [ prepend201-3 prepend202-3 prepend203-3 prepend204-3

prepend205-3 ];}then as-path-prepend "201 201 201";

}term term4 {

from {protocol bgp;community [ peer201 peer202 peer203 peer204 peer205 custpeer201

custpeer202 custpeer203 custpeer204 custpeer205 internal201internal202 internal203 internal204 internal205 ];

}then reject;

}then next policy;

}}

Configuring Prefix Lists for Use in Routing Policy Match Conditions

A prefix list is a named list of IP addresses. You can specify an exact match withincoming routes and apply a common action to all matching prefixes in the list.

NOTE: Because the configuration of prefix lists includes setting up prefixes and prefixlengths, we strongly recommend that you have a thorough understanding of IPaddressing, including supernetting, before proceeding with the configuration.

Configuring Prefix Lists for Use in Routing Policy Match Conditions ■ 117


A prefix list functions like a route list that contains multiple instances of the exactmatch type only. The differences between these two extended match conditions aresummarized in Table 19 on page 118.

Table 19: Prefix List and Route List Differences

Route ListsPrefix ListFeature

Can specify action that is applied toa particular prefix in a route-filtermatch condition in a from statement,or to all prefixes in the list using athen statement.

Can specify action in a thenstatement only. These actions areapplied to all prefixes that matchthe term.

Action

For information about configuring route lists, see “Configuring Route Lists for Usein Routing Policy Match Conditions” on page 121.

This section includes the following information:

■ Configuring Prefix Lists on page 118

■ How Prefix Lists Are Evaluated in Routing Policy Match Conditions on page 119

■ Configuring Prefix List Filters on page 120

■ Example: Configuring a Prefix List on page 120

Configuring Prefix Lists

You can create a named prefix list and include it in a routing policy with the prefix-listmatch condition (described in Table 10 on page 42).

To define a prefix list, include the prefix-list statement:

prefix-list prefix-list-name {apply-path path;ip-addresses;

}




You can use the apply-path statement to include all prefixes pointed to by a definedpath, or you can specify one or more addresses, or both.

To include a prefix list in a routing policy, specify the prefix-list match condition inthe from statement at the [edit policy-options policy-statement policy-name termterm-name] hierarchy level:

[edit policy-options policy-statement policy-name term term-name]from {

prefix-list prefix-list-name;

118 ■ Configuring Prefix Lists for Use in Routing Policy Match Conditions


}then actions;

name identifies the prefix list. It can contain letters, numbers, and hyphens (-) andcan be up to 255 characters long. To include spaces in the name, enclose the entirename in quotation marks (“ ”).

ip-addresses are the IPv4 or IP version 6 (IPv6) prefixes specified as prefix/prefix-length.If you omit prefix-length for an IPv4 prefix, the default is /32. If you omit prefix-lengthfor an IPv6 prefix, the default is /128. Prefixes specified in a from statement mustbe either all IPv4 addresses or all IPv6 addresses.

NOTE: You cannot apply actions to individual prefixes in the list.

You can specify the same prefix list in the from statement of multiple routing policiesor firewall filters. For information about firewall filters, see “Configuring StandardFirewall Filters” on page 179.

Use the apply-path statement to configure a prefix list comprising all IP prefixespointed to by a defined path. This eliminates most of the effort required to maintaina group prefix list.

The path consists of elements separated by spaces. Each element matches aconfiguration keyword or an identifier, and you can use wildcards to match morethan one identifier. Wildcards must be enclosed in angle brackets, for example,<*>.

NOTE: You cannot add a path element, including wildcards, after a leaf statementin the apply-path statement. Path elements, including wildcards, can only be usedafter a container statement.

NOTE: When you use apply-path to define a prefix list, you can also use the sameprefix list in a policy statement.

For examples of configuring a prefix list, see “Example: Configuring a Prefix List”on page 120; for examples of configuring a firewall filter, see “Configuring StandardFirewall Filters” on page 179.

How Prefix Lists Are Evaluated in Routing Policy Match Conditions

During prefix list evaluation, the policy framework software performs a longest-matchlookup, which means that the software searches for the prefix in the list with thelongest length. The order in which you specify the prefixes, from top to bottom, doesnot matter. The software then compares a route’s source address to the longestprefix.

Configuring Prefix Lists for Use in Routing Policy Match Conditions ■ 119


You can use prefix list qualifiers for prefixes contained in a prefix list by configuringa prefix list filter. For more information, see “Configuring Prefix Lists for Use inRouting Policy Match Conditions” on page 117.

If a match occurs, the evaluation of the current term continues. If a match does notoccur, the evaluation of the current term ends.

NOTE: If you specify multiple prefixes in the prefix list, only one prefix must matchfor a match to occur. The prefix list matching is effectively a logical OR operation.

Configuring Prefix List Filters

A prefix list filter allows you to apply prefix list qualifiers to a list of prefixes withina prefix list. The prefixes within the list are evaluated using the specified qualifiers.You can configure multiple prefix list filters under the same policy term.

To configure a prefix list filter, include the prefix-list-filter statement at the [editpolicy-options policy-statement policy-name from] hierarchy level:

[edit policy-options policy-statement policy-name]from {

prefix-list-filter prefix-list-name match-type actions;}

The prefix-list-name option is the name of the prefix list to be used for evaluation. Youcan specify only one prefix list.

The match-type option is the type of match to apply to the prefixes in the prefix list.It can be one of the match types listed in Table 20 on page 120.

The actions option is the action to take if the prefix list matches. It can be one ormore of the actions listed in Table 11 on page 49 and Table 12 on page 49.

Table 20: Route List Match Types for a Prefix List Filter

Match ConditionMatch Type

The route shares the same most-significant bits (described by prefix-length), and prefix-length is equalto the route’s prefix length.

exact

The route shares the same most-significant bits (described by prefix-length), and prefix-length is greaterthan the route’s prefix length.

longer

The route shares the same most-significant bits (described by prefix-length), and prefix-length is equalto or greater than the route’s prefix length.

orlonger

Example: Configuring a Prefix List

The following example accepts and rejects traffic from sites specified using prefixlists:

120 ■ Configuring Prefix Lists for Use in Routing Policy Match Conditions



policy-statement prefix-list-policy {term ok-sites {

from {prefix-list known-ok-sites;

}then accept;

}term reject-bcasts {

from {prefix-list known-dir-bcast-sites;

}then reject;

}}

}[edit]policy-options {

prefix-list known-ok-sites {172.16.0.3;10.10.0.0/16;192.168.12.0/24;

}[edit]policy-options {

prefix-list known-dir-bcast-sites {10.3.4.6;10.2.0.0/16;192.168.1.0/24;

}}

}

Configuring Route Lists for Use in Routing Policy Match Conditions

A route list is a collection of destination prefixes. When specifying a prefix, you canspecify an exact match with a particular route or a less precise match. You canconfigure either a common action that applies to the entire list or an action associatedwith each prefix.

NOTE: Because the configuration of route lists includes setting up prefixes and prefixlengths, we strongly recommend that you have a thorough understanding of IPaddressing, including supernetting, before proceeding with the configuration.

It is also important to understand how a route list is evaluated, particularly if theroute list includes multiple route-filter options in a from statement. We stronglyrecommend that you read “How Route Lists Are Evaluated in Routing Policy MatchConditions” on page 124 before proceeding with the configuration. Not fullyunderstanding the evaluation process could result in faulty configuration andunexpected results.

Configuring Route Lists for Use in Routing Policy Match Conditions ■ 121


This section discusses the following topics:

■ Configuring Route Lists on page 122

■ How Route Lists Are Evaluated in Routing Policy Match Conditions on page 124

■ Route List Examples on page 126

Configuring Route Lists

To configure a route list, include one or more route-filter or source-address-filterstatements at the [edit policy-options policy-statement policy-name term term-name from]hierarchy level:

[edit policy-options policy-statement policy-name term term-name from]route-filter prefix match-type {

action;}source-address-filter source-prefix match-type {

action;}

The route-filter option is typically used to match prefixes of any type except for unicastsource addresses.

The source-address-filter option is typically used to match unicast source addressesin multiprotocol BGP (MBGP) and Multicast Source Discovery Protocol (MSDP)environments.

source-prefix is the IPv4 or IPv6 prefix specified as prefix/prefix-length. If you omitprefix-length for an IPv4 prefix, the default is /32. If you omit prefix-length for an IPv6prefix, the default is /128. Prefixes specified in a from statement must be either allIPv4 addresses or all IPv6 addresses.

match-type is the type of match to apply to the destination prefix. It can be one ofthe match types listed in Table 21 on page 123. For examples of the match types andthe results when presented with various routes, see Table 22 on page 123.

actions is the action to take if the destination prefix matches. It can be one or moreof the actions listed in Table 11 on page 49 and Table 12 on page 49.

In route lists, you can specify actions in two ways:

■ In the route-filter or source-address-filter option—These actions are takenimmediately after a match occurs, and the then statement is not evaluated.

■ In the then statement—These actions are taken after a match occurs and if anaction is not specified in the route-filter or source-address-filter option.

The upto and prefix-length-range match types are similar in that both specify themost-significant bits and provide a range of prefix lengths that can match. Thedifference is that upto allows you to specify an upper limit only for the prefix lengthrange, whereas prefix-length-range allows you to specify both lower and upper limits.

122 ■ Configuring Route Lists for Use in Routing Policy Match Conditions


For more examples of these route list match types, see “Route List Examples” onpage 126.

Table 21: Route List Match Types for a Prefix List

Match ConditionMatch Type

The route shares the same most-significant bits (described by prefix-length), and prefix-length is equalto the route’s prefix length.

exact

The route shares the same most-significant bits (described by prefix-length), and prefix-length is greaterthan the route’s prefix length.

longer

The route shares the same most-significant bits (described by prefix-length), and prefix-length is equalto or greater than the route’s prefix length.

orlonger

The route shares the same most-significant bits (described by prefix-length), and the route’s prefixlength falls between prefix-length2 and prefix-length3, inclusive.

prefix-length-rangeprefix-length2–prefix-length3

All the following are true:

■ The route shares the same most-significant bits (described by prefix-length) of the first destinationprefix.

■ The route shares the same most-significant bits (described by prefix-length) of the seconddestination prefix for the number of bits in the prefix length.

■ The number of bits in the route’s prefix length is less than or equal to the number of bits in thesecond prefix.

You do not use the through match type in most routing policy configurations. (For an example, see“Route List Examples” on page 126.)

throughdestination-prefix

The route shares the same most-significant bits (described by prefix-length) and the route’s prefixlength falls between prefix-length and prefix-length2.

upto prefix-length2

Table 22: Match Type Examples

192.168/16prefix lengthrange /18–/20

192.168/16through192.168.16/20

192.168/16upto /24

192.168/16orlonger

192.168/16longer

192.168/16exactPrefix

––––––10.0.0.0/8

–MatchMatchMatch–Match192.168.0.0/16

–MatchMatchMatchMatch–192.168.0.0/17

MatchMatchMatchMatchMatch–192.168.0.0/18


––MatchMatchMatch–192.168.4.0/24

–––MatchMatch–192.168.5.4/30

–––MatchMatch–192.168.12.4/30



Table 22: Match Type Examples (continued)

192.168/16prefix lengthrange /18–/20

192.168/16through192.168.16/20

192.168/16upto /24

192.168/16orlonger

192.168/16longer

192.168/16exactPrefix

–––MatchMatch–192.168.12.128/32


Match–MatchMatchMatch–192.168.192.0/18

Match–MatchMatchMatch–192.168.224.0/19

––––––10.169.1.0/24

––––––10.170.0.0/16

How Route Lists Are Evaluated in Routing Policy Match Conditions

During route list evaluation, the policy framework software compares each route’ssource address with the destination prefixes in the route list. The evaluation occursin two steps:

1. The policy framework software performs a longest-match lookup, which meansthat the software searches for the prefix in the list with the longest length.

The longest-match lookup considers the prefix and prefix length only and notthe match type. The following sample route list illustrates this point:

from {route-filter 192.168.0.0/14 upto /24 reject;route-filter 192.168.0.0/15 exact;

}then accept;

The longest match is the second route-filter, 192.168.0.0/15, which is based onprefix and prefix length only.

2. Once an incoming route matches a prefix (longest first), the following occur:

■ The route filter stops evaluating other prefixes, even if the match type fails.

■ The software examines the match type and action associated with that prefix.

In Step 1, if route 192.168.1.0/24 were evaluated, it would fail to match. It matchesthe longest prefix of 192.168.0.0/15, but it does not match exact. The route filter isfinished because it matched a prefix, but the result is a failed match because thematch type failed.

If a match occurs, the action specified with the prefix is taken. If an action is notspecified with the prefix, the action in the then statement is taken. If neither actionis specified, the software evaluates the next term or routing policy, if present, ortakes the accept or reject action specified by the default policy. For more information



about the default routing policies, see “Default Routing Policies and Actions” on page20.

NOTE: If you specify multiple prefixes in the route list, only one prefix needs tomatch for a match to occur. The route list matching is effectively a logical ORoperation.

If a match does not occur, the software evaluates the next term or routing policy, ifpresent, or takes the accept or reject action specified by the default policy.

For example, compare the prefix 192.168.254.0/24 against the following route list:

route-filter 192.168.0.0/16 orlonger;route-filter 192.168.254.0/23 exact;

The prefix 192.168.254.0/23 is determined to be the longest prefix. When thesoftware evaluates 192.168.254.0/24 against the longest prefix, a match occurs(192.168.254.0/24 is a subset of 192.168.254.0/23). Because of the match between192.168.254.0/24 and the longest prefix, the evaluation continues. However, whenthe software evaluates the match type, a match does not occur between192.168.254.0/24 and 192.168.254.0/23 exact. The software concludes that theterm does not match and goes on to the next term or routing policy, if present, ortakes the accept or reject action specified by the default policy.

How Prefix Order Affects Route List Evaluation

The order in which the prefixes are specified (from top to bottom) typically does notmatter, because the policy framework software scans the route list looking for thelongest prefix during evaluation. An exception to this rule is when you use the samedestination prefix multiple times in a list. In this case, the order of the prefixes isimportant, because the list of identical prefixes is scanned from top to bottom, andthe first match type that matches the route applies.

In the following example, different match types are specified for the same prefix.The route 0.0.0.0/0 would be rejected, the route 0.0.0.0/8 would be marked withnext-hop self, and the route 0.0.0.0/25 would be rejected.

route-filter 0.0.0.0/0 upto /7 reject;route-filter 0.0.0.0/0 upto /24 next-hop self;route-filter 0.0.0.0/0 orlonger reject;

Common Configuration Problem with the Longest-Match Lookup

A common problem when defining a route list is including a shorter prefix that youwant to match with a longer, similar prefix in the same list. For example, imaginethat the prefix 192.168.254.0/24 is compared against the following route list:

route-filter 192.168.0.0/16 orlonger;route-filter 192.168.254.0/23 exact;



Because the policy framework software performs longest-match lookup, the prefix192.168.254.0/23 is determined to be the longest prefix. An exact match does notoccur between 192.168.254.0/24 and 192.168.254.0/23 exact. The softwaredetermines that the term does not match and goes on to the next term or routingpolicy, if present, or takes the accept or reject action specified by the default policy.(For more information about the default routing policies, see “Default Routing Policiesand Actions” on page 20.) The shorter prefix 192.168.0.0/16 orlonger that youwanted to match is inadvertently ignored.

One solution to this problem is to remove the prefix 192.168.0.0/16 orlonger fromthe route list in this term and move it to a previous term where it is the only prefixor the longest prefix in the list.

Route List Examples

The examples in this section show only fragments of routing policies. Normally, youwould combine these fragments with other terms or routing policies.

In all examples, remember that the following actions apply to nonmatching routes:

■ Evaluate next term, if present.

■ Evaluate next policy, if present.

■ Take the accept or reject action specified by the default policy. For moreinformation about the default routing policies, see “Default Routing Policies andActions” on page 20.

The following examples show how to configure route lists for various purposes:

■ Example: Rejecting Routes with Specific Destination Prefixes and MaskLengths on page 126

■ Example: Rejecting Routes with a Mask Length Greater than Eight on page 127

■ Example: Rejecting Routes with Mask Length Between 26 and 29 on page 127

■ Example: Rejecting Routes from Specific Hosts on page 127

■ Example: Accepting Routes with a Defined Set of Prefixes on page 128

■ Example: Rejecting Routes with a Defined Set of Prefixes on page 128

■ Example: Rejecting Routes with Prefixes Longer than 24 Bits on page 129

■ Example: Rejecting PIM Multicast Traffic Joins on page 129

■ Example: Rejecting PIM Traffic on page 130

Example: Rejecting Routes with Specific Destination Prefixes and MaskLengths

Reject routes with a destination prefix of 0.0.0.0 and a mask length from 0 through 8,and accept all other routes:


policy-statement policy-statement from-hall2 {



term 1 {from {

route-filter 0.0.0.0/0 upto /8 reject;}

}then accept;

}}

Example: Rejecting Routes with a Mask Length Greater than Eight

Reject routes with a mask of /8 and greater (that is, /8, /9, /10, and so on) that havethe first 8 bits set to 0 and accept routes less than 8 bits in length:


policy-statement from-hall3 {term term1 {

from {route-filter 0/0 upto /7 accept;route-filter 0/8 orlonger;

}then reject;

}}

}

Example: Rejecting Routes with Mask Length Between 26 and 29

Reject routes with the destination prefix of 192.168.10/24 and a mask between /26and /29 and accept all other routes:


policy-statement from-customer-a {term term1 {

from {route-filter 192.168.10/24 prefix-length-range /26–/29 reject;route-filter 0/0;

}then accept;

}}

}

Example: Rejecting Routes from Specific Hosts

Reject a range of routes from specific hosts, and accept all other routes:


policy-statement hosts-only {from {

route-filter 10.125.0.0/16 upto /31 reject;



route-filter 0/0;}then accept;

}}

You do not use the through match type in most routing policy configurations. Youshould think of through as a tool to group a contiguous set of exact matches. Forexample, instead of specifying four exact matches:

from route-filter 0.0.0.0/1 exactfrom route-filter 0.0.0.0/2 exactfrom route-filter 0.0.0.0/3 exactfrom route-filter 0.0.0.0/4 exact

You could represent them with the following single match:

from route-filter 0.0.0.0/1 through 0.0.0.0/4

Example: Accepting Routes with a Defined Set of Prefixes

Explicitly accept a limited set of prefixes (in the first term) and reject all others (inthe second term):

policy-options {policy-statement internet-in {

term 1 {from {

route-filter 192.168.231.0/24 exact accept;route-filter 192.168.244.0/24 exact accept;route-filter 192.168.198.0/24 exact accept;route-filter 192.168.160.0/24 exact accept;route-filter 192.168.59.0/24 exact accept;

}}term 2 {

then {reject;

}}

}

Example: Rejecting Routes with a Defined Set of Prefixes

Reject a few groups of prefixes, and accept the remaining prefixes:

[edit policy-options]policy-statement drop-routes {

term 1{from { # first, reject a number of prefixes:

route-filter default exact reject; # reject 0.0.0.0/0 exactroute-filter 0.0.0.0/8 orlonger reject; # reject prefix 0, mask /8 or longerroute-filter 10.0.0.0/8 orlonger reject; # reject loopback addresses}route-filter 10.105.0.0/16 exact { # accept 10.105.0.0/16



as-path-prepend “1 2 3”;accept;

}route-filter 192.0.2.0/24 orlonger reject; # reject test network packetsroute-filter 224.0.0.0/3 orlonger reject; # reject multicast and higherroute-filter 0.0.0.0/0 upto /24 accept; # accept everything up to /24route-filter 0.0.0.0/0 orlonger accept; # accept everything else}

}}

}

Example: Rejecting Routes with Prefixes Longer than 24 Bits

Reject all prefixes longer than 24 bits. You would install this routing policy in asequence of routing policies in an export statement. The first term in this filter passeson all routes with a prefix length of up to 24 bits. The second, unnamed term rejectseverything else.

[edit policy-options]policy-statement 24bit-filter {

term acl20 {from {

route-filter 0.0.0.0/0 upto /24;}then next policy;

}then reject;

}

If, in this example, you were to specify route-filter 0.0.0.0/0 upto /24 accept, matchingprefixes would be accepted immediately and the next routing policy in the exportstatement would never get evaluated.

If you were to include the then reject statement in the term acl20, prefixes greaterthan 24 bits would never get rejected because the policy framework software, whenevaluating the term, would move on to evaluating the next statement before reachingthe then reject statement.

Example: Rejecting PIM Multicast Traffic Joins

Configure a routing policy for rejecting Protocol Independent Multicast (PIM) multicasttraffic joins for a source destination prefix from a neighbor:


policy-statement join-filter {from {

neighbor 10.14.12.20;source-address-filter 10.83.0.0/16 orlonger;

}then reject;

}}



Example: Rejecting PIM Traffic

Configure a routing policy for rejecting PIM traffic for a source destination prefixfrom an interface:


policy-statement join-filter {from {

interface so-1/0/0.0;source-address-filter 10.83.0.0/16 orlonger;

}then reject;

}}

The following routing policy qualifiers apply to PIM:

■ interface—Interface over which a join is received

■ neighbor—Source from which a join originates

■ route-filter—Group address

■ source-address-filter—Source address for which to reject a join

For more information about importing a PIM join filter in a PIM protocol definition,see the JUNOS Multicast Protocols Configuration Guide.

Configuring Subroutines in Routing Policy Match Conditions

You can use a routing policy called from another routing policy as a match condition.This process makes the called policy a subroutine.

For configuration instructions and examples, see the following section:

■ Configuring Subroutines on page 130

■ Example: Configuring a Subroutine on page 134

Configuring Subroutines

To configure a subroutine in a routing policy to be called from another routing policy,create the subroutine and specify its name using the policy match condition (describedin Table 10 on page 42) in the from or to statement of another routing policy:


policy-statement subroutine-policy-name {term term-name {

from {match-conditions;route-filter destination-prefix match-type <actions>;source-address-filter destination-prefix match-type <actions>;

130 ■ Configuring Subroutines in Routing Policy Match Conditions


prefix-list name;}to {


}}

}policy-options {


from {policy subroutine-policy-name;

}to {

policy subroutine-policy-name;}then actions;

}}

}

NOTE: Do not evaluate a routing policy within itself. The result is that no prefixesever match the routing policy.

The action specified in a subroutine is used to provide a match condition to the callingpolicy. If the subroutine specifies an action of accept, the calling policy considers theroute to be a match. If the subroutine specifies an action of reject, the calling policyconsiders the route not to match. If the subroutine specifies an action that is meantto manipulate the route characteristics, the changes are made. For more details aboutthe subroutine evaluation, see “How a Routing Policy Subroutine Is Evaluated” onpage 31.

Possible Consequences of Termination Actions in Subroutines

A subroutine with particular statements can behave differently from a routing policythat contains the same statements. With a subroutine, you must remember that thepossible termination actions of accept or reject specified by the subroutine or thedefault policy can greatly affect the expected results. (For more information aboutdefault routing policies, see “Default Routing Policies and Actions” on page 20.)

In particular, you must consider what happens if a match does not occur with routesspecified in a subroutine and if the default policy action that is taken is the actionthat you expect and want.

For example, imagine that you are a network administrator at an Internet serviceprovider (ISP) that provides service to Customer A. You have configured severalrouting policies for the different classes of neighbors that Customer A presents onvarious links. To save time maintaining the routing policies for Customer A, you haveconfigured a subroutine that identifies their routes and various routing policies thatcall the subroutine, as shown below:

Configuring Subroutines in Routing Policy Match Conditions ■ 131



policy-statement customer-a-subroutine {from {

route-filter 10.1/16 exact;route-filter 10.5/16 exact;route-filter 192.168.10/24 exact;

}then accept;

}}policy-options {

policy-statement send-customer-a-default {from {

policy customer-a-subroutine;}then {

set metric 500;accept;

}}

}policy-options {

policy-statement send-customer-a-primary {from {



}}

}policy-options {

policy-statement send-customer-a-secondary {from {



}}

}protocols {

bgp {group customer-a {

export send-customer-a-default;neighbor 10.1.1.1;neighbor 10.1.2.1;neighbor 10.1.3.1 {

export send-customer-a-primary;}neighbor 10.1.4.1 {

export send-customer-a-secondary;}

132 ■ Configuring Subroutines in Routing Policy Match Conditions


}}

}

The following results occur with this configuration:

■ The group-level export statement resets the metric to 500 when advertising allBGP routes to neighbors 10.1.1.1 and 10.1.2.1 rather than just the routes thatmatch the subroutine route filters.

■ The neighbor-level export statements reset the metric to 100 and 200 whenadvertising all BGP routes to neighbors 10.1.3.1 and 10.1.4.1, respectively, ratherthan just the BGP routes that match the subroutine route filters.

These unexpected results occur because the subroutine policy does not specify atermination action for routes that do not match the route filter and therefore, thedefault BGP export policy of accepting all BGP routes is taken.

If the statements included in this particular subroutine had been contained withinthe calling policies themselves, only the desired routes would have their metrics reset.

This example illustrates the differences between routing policies and subroutinesand the importance of the termination action in a subroutine. Here, the default BGPexport policy action for the subroutine was not carefully considered. A solution tothis particular example is to add one more term to the subroutine that rejects allother routes that do not match the route filters:


policy-statement customer-a-subroutine {term accept-exact {

from {route-filter 10.1/16 exact;route-filter 10.5/16 exact;route-filter 192.168.10/24 exact;

}then accept;

}term reject-others {

then reject;}

}}

Termination action strategies for subroutines in general include the following:

■ Depend upon the default policy action to handle all other routes.

■ Add a term that accepts all other routes. (Also see “Effect of Omitting IngressMatch Conditions from Export Policies” on page 58.)

■ Add a term that rejects all other routes.

The option that you choose depends upon what you want to achieve with yoursubroutine. Plan your subroutines carefully.

Configuring Subroutines in Routing Policy Match Conditions ■ 133


Example: Configuring a Subroutine

Create the subroutine is-customer and call it from the routing policies export-customerand import-customer. In import-customer, the action is taken only on routes that matchthe route filters defined in is-customer.


policy-statement is-customer {term match-customer {

from {route-filter 10.100.1.0/24 exact;route-filter 10.186.100.0/24 exact;

}then accept;

}term drop-others {

then reject;}

}policy-statement export-customer {

from policy is-customer;then accept;

}policy-statement import-customer {

from {protocol bgp;policy is-customer;

}then {


}}

}

Configuring Routing Policy Match Conditions Based on Routing Table Entries

In addition to defining match conditions in the from statement of a policy, you canuse the condition statement to define conditions used during policy evaluation:

condition condition-name {if-route-exists address table table-name;

}




134 ■ Configuring Routing Policy Match Conditions Based on Routing Table Entries


To define a policy condition based on the existence of routes in specific tables foruse in BGP export policies, specify a name for the condition and include the followingoptions:

■ if-route-exists address—Specify the address of the route in question.

■ table table-name—Specify a routing table.

You can then add the defined condition to the from statement of a policy:

policy-options {policy-statement policy-name {

term 1 {from {

protocols bgp;condition condition-name;

}then {

accept;}

}...

}

The condition statement is available on all platforms, but is limited to use in BGPexport policies. To view the configured policy conditions and their associated routingtables and dependent routes, issue the show policy conditions operational modecommand; for more information, see the JUNOS Routing Protocols and PoliciesCommand Reference.

Configuring Routing Policy Match Conditions Based on Routing Table Entries ■ 135


136 ■ Configuring Routing Policy Match Conditions Based on Routing Table Entries


Chapter 6

Extended Actions Configuration

This chapter provides information about the following routing policy actionsconfiguration tasks:

■ Prepending AS Numbers to BGP AS Paths on page 137

■ Adding AS Numbers to BGP AS Paths on page 138

■ Using Routing Policies to Damp BGP Route Flapping on page 138

■ Overview of Per-Packet Load Balancing on page 144

■ Configuring Per-Packet Load Balancing on page 145

■ Configuring Load Balancing Based on MPLS Labels on page 147

■ Configuring Load Balancing for Ethernet Pseudowires on page 150

■ Configuring Load Balancing Based on MAC Addresses on page 151

■ Configuring VPLS Load Balancing Based on IP and MPLS Information on page 151

■ Configuring VPLS Load Balancing on MX Series Ethernet ServicesRouters on page 153

Prepending AS Numbers to BGP AS Paths

You can prepend one or more autonomous system (AS) numbers at the beginning ofan AS path. The AS numbers are added at the beginning of the path after the actualAS number from which the route originates has been added to the path. Prependingan AS path makes a shorter AS path look longer and therefore less preferable to BGP.

In JUNOS Release 9.1 and later, you can specify 4-byte AS numbers as defined inRFC 4893, BGP Support for Four-octet AS Number Space, as well as the 2-byte ASnumbers that are supported in earlier releases of the JUNOS Software. In plain-numberformat, you can configure a value in the range from 1 through 4,294,967,295. Formore information about configuring AS numbers, see the JUNOS Routing ProtocolsConfiguration Guide.

In the following example, from AS 1 there are two equal paths (through AS 2 andAS 3) to reach AS 4. You might want packets from certain sources to use the paththrough AS 2. Therefore, you must make the path through AS 3 look less preferableso that BGP chooses the path through AS 2. In the configuration for AS 1, prependmultiple AS numbers:


Prepending AS Numbers to BGP AS Paths ■ 137

policy-statement as-path-prepend {term prepend {

from {route-filter 192.168.0.0/16 orlonger;route-filter 172.16.0.0/12 orlonger;route-filter 10.0.0.0/8 orlonger;

}then as-path-prepend "1 1 1 1";

}}

}

Adding AS Numbers to BGP AS Paths

You can expand or add one or more AS numbers to an AS sequence. The AS numbersare added before the local AS number has been added to the path. Expanding an ASpath makes a shorter AS path look longer and therefore less preferable to BGP. Thelast AS number in the existing path is extracted and prepended n times, where n isa number from 1 through 32. This is similar to the AS path prepend action, exceptthat the AS path expand action adds an arbitrary sequence of AS numbers.

For example, from AS 1 there are two equal paths (through AS 2 and AS 3) to reachAS 4. You might want packets from certain sources to use the path through AS 2.Therefore, you must make the path through AS 3 less preferable so that BGP choosesthe path through AS 2. In AS 1, you can expand multiple AS numbers.


policy-statement as-path-expand {term expand {

from {route-filter 192.168.0.0/16 orlonger;route-filter 172.16.0.0/12 orlonger;route-filter 10.0.0.0/8 orlonger;

}then as-path-expand last-as count 4;

}}

}

For routes from AS 2, this makes the route look like 1 2 2 2 2 2 when advertised,where 1 is from AS 1, the 2 from AS 2 is prepended four times, and the final 2 is theoriginal 2 received from the neighbor router.

Using Routing Policies to Damp BGP Route Flapping

BGP route flapping describes the situation in which BGP systems send an excessivenumber of update messages to advertise network reachability information. BGP flapdamping is a way to reduce the number of update messages sent between BGP peers,thereby reducing the load on these peers without adversely affecting the routeconvergence time.

138 ■ Adding AS Numbers to BGP AS Paths


Flap damping reduces the number of update messages by marking routes as ineligiblefor selection as the active or preferable route. Doing this leads to some delay, orsuppression, in the propagation of route information, but the result is increasednetwork stability. You typically apply flap damping to external BGP (EBGP) routes(that is, to routes in different ASs). You can also apply it within a confederation,between confederation member ASs. Because routing consistency within an AS isimportant, do not apply flap damping to IBGP routes. (If you do, it is ignored.)

BGP flap damping is defined in RFC 2439, BGP Route Flap Damping.

To effect changes to the default BGP flap damping values, you define actions bycreating a named set of damping parameters and including it in a routing policy withthe damping action (described in Table 12 on page 49). For the damping routingpolicy to work, you also must enable BGP route flap damping.

For further information about enabling BGP route flap damping, see the JUNOS RoutingProtocols Configuration Guide.


■ Configuring BGP Flap Damping Parameters on page 139

■ Specifying BGP Flap Damping as the Action in Routing Policy Terms on page 141

■ Disabling Damping for Specific Address Prefixes on page 142

■ Example: Configuring BGP Flap Damping on page 142

Configuring BGP Flap Damping Parameters

To define damping parameters, include the damping statement:

damping name {disable;half-life minutes;max-suppress minutes;reuse number;suppress number;

}




The name identifies the group of damping parameters. It can contain letters, numbers,and hyphens (-) and can be up to 255 characters. To include spaces in the name,enclose the entire name in quotation marks (“ ”).

You can specify one or more of the damping parameters described in Table 23 onpage 140.

Using Routing Policies to Damp BGP Route Flapping ■ 139

Chapter 6: Extended Actions Configuration

Table 23: Damping Parameters

Possible ValuesDefaultDescriptionDamping Parameter

1 through 45 minutes15 minutesDecay half-life, in minuteshalf-life minutes

1 through 720 minutes60 minutesMaximum hold-downtime, in minutes

max-suppress minutes

1 through 20,000(unitless)

750 (unitless)Reuse thresholdreuse

1 through 20,000(unitless)

3000 (unitless)Cutoff (suppression)threshold

suppress

If you do not specify one or more of the damping parameters, the default value ofthe parameter is used.

To understand how to configure these parameters, you need to understand howdamping suppresses routes. How long a route can be suppressed is based on a figureof merit, which is a value that correlates to the probability of future instability of aroute. Routes with higher figure-of-merit values are suppressed for longer periods oftime. The figure-of-merit value decays exponentially over time.

A figure-of-merit value of zero is assigned to each new route. The value is increasedeach time the route is withdrawn or readvertised, or when one of its path attributeschanges. With each incident of instability, the value increases as follows:

■ Route is withdrawn—1000

■ Route is readvertised—1000

■ Route’s path attributes change—500

NOTE: Other vendors’ implementations for figure-of-merit increase the value onlywhen a route is withdrawn. The JUNOS implementation for figure-of-merit increasesthe value for both route withdrawal and route readvertisement. To accommodateother implementations for figure-of-merit, multiply the reuse and suppress thresholdvalues by 2.

When a route’s figure-of-merit value reaches a particular level, called the cutoff orsuppression threshold, the route is suppressed. If a route is suppressed, the routingtable no longer installs the route into the forwarding table and no longer exports thisroute to any of the routing protocols. By default, a route is suppressed when itsfigure-of-merit value reaches 3000. To modify this default, include the suppressoption at the [edit policy-options damping name] hierarchy level.

If a route has flapped, but then becomes stable so that none of the incidents listedpreviously occur within a configurable amount of time, the figure-of-merit value forthe route decays exponentially. The default half-life is 15 minutes. For example, fora route with a figure-of-merit value of 1500, if no incidents occur, its figure-of-meritvalue is reduced to 750 after 15 minutes and to 375 after another 15 minutes. To

140 ■ Using Routing Policies to Damp BGP Route Flapping


modify the default half-life, include the half-life option at the [edit policy-options dampingname] hierarchy level.

A suppressed route becomes reusable when its figure-of-merit value decays to a valuebelow a reuse threshold, thus allowing routes that experience transient instability toonce again be considered valid. The default reuse threshold is 750. When thefigure-of-merit value passes below the reuse threshold, the route once again isconsidered usable and can be installed in the forwarding table and exported fromthe routing table. To modify the default reuse threshold, include the reuse option atthe [edit policy-options damping name] hierarchy level.

The maximum suppression time provides an upper bound on the time that a routecan remain suppressed. The default maximum suppression time is 60 minutes. Tomodify the default, include the max-suppress option at the [edit policy-options dampingname] hierarchy level.

A route’s figure-of-merit value stops increasing when it reaches a maximumsuppression threshold, which is determined based on the route’s suppression thresholdlevel, half-life, reuse threshold, and maximum hold-down time.

The merit ceiling, εc, which is the maximum merit that a flapping route can collect,is calculated using the following formula:

εc ≤ εr e(t/λ) (ln 2)

εr is the figure-of-merit reuse threshold, t is the maximum hold-down time in minutes,and λ is the half-life in minutes. For example, if you use the default figure-of-meritvalues in this formula, but use a half-life of 30 minutes, the calculation is as follows:

εc ≤ 750 e(60/30) (ln 2)

εc ≤ 3000

NOTE: The cutoff threshold, which you configure using the suppress option, mustbe less than or equal to the merit ceiling, εc. If the configured cutoff threshold or thedefault cutoff threshold is greater than the merit ceiling, the route is never suppressedand damping never occurs.

To display figure-of-merit information, use the show policy damping command.

A route that has been assigned a figure of merit is considered to have a dampingstate. To display the current damping information on the router, use the show routedetail command.

Specifying BGP Flap Damping as the Action in Routing Policy Terms

To BGP flap damping as the action in a routing policy term, include the dampingstatement and the name of the configured damping parameters either as an optionof the route-filter statement at the [edit policy-options policy-statement policy-name termterm-name from] hierarchy level:




damping damping-parameters;}

or at the [edit policy-options policy-statement policy-name term term-name then] hierarchylevel:

[edit policy-options policy-statement policy-name term term-name then]damping damping-parameters;

Disabling Damping for Specific Address Prefixes

Normally, you enable or disable damping on a per-peer basis. However, you candisable damping for a specific prefix received from a peer by including the disableoption:

disable;


■ [edit policy-options damping name]

■ [edit logical-systems logical-system-name policy-options damping name]

Example: Disabling Damping for a Specific Address Prefix

In this routing policy example, although damping is enabled for the peer, the dampingnone statement specifies that damping be disabled for prefix 10.0.0.0/8 in Policy-A.This route is not damped because the routing policy statement named Policy-A filterson the prefix 10.0.0.0/8 and the action points to the damping statement named none.The remaining prefixes are damped using the default parameters.


policy-statement Policy-A {from {

route-filter 10.0.0.0/8 exact;}then damping none;

}damping none {

disable;}

}

Example: Configuring BGP Flap Damping

Enable BGP flap damping and configure damping parameters:


autonomous-system 666;}

142 ■ Using Routing Policies to Damp BGP Route Flapping


protocols {bgp {

damping;group group1 {

traceoptions {file bgp-log size 1m files 10;flag damping;

}import damp;type external;peer-as 10458;neighbor 192.168.2.30;

}}

}policy-options {

policy-statement damp {from {

route-filter 192.168.0.0/32 exact {damping high;accept;

}route-filter 172.16.0.0/32 exact {

damping medium;accept;

}route-filter 10.0.0.0/8 exact {

damping none;accept;

}}

}damping high {

half-life 30;suppress 3000;reuse 750;max-suppress 60;

}damping medium {

half-life 15;suppress 3000;reuse 750;max-suppress 45;

}damping none {

disable;}

}

To display damping parameters for this configuration, use the show policy dampingcommand:

user@host> show policy dampingDamping information for "high": Halflife: 30 minutes Reuse merit: 750 Suppress/cutoff merit: 3000



Maximum suppress time: 60 minutes Computed values: Merit ceiling: 3008 Maximum decay: 24933Damping information for "medium": Halflife: 15 minutes Reuse merit: 750 Suppress/cutoff merit: 3000 Maximum suppress time: 45 minutes Computed values: Merit ceiling: 6024 Maximum decay: 12449 Damping information for "none":Damping disabled

Overview of Per-Packet Load Balancing

By default, when there are multiple equal-cost paths to the same destination for theactive route, the JUNOS Software uses a hash algorithm to choose one of the next-hopaddresses to install in the forwarding table. Whenever the set of next hops for adestination changes in any way, the next-hop address is rechosen using the hashalgorithm.

You can configure the JUNOS Software so that, for the active route, all next-hopaddresses for a destination are installed in the forwarding table. This feature is calledper-packet load balancing. You can use load balancing to spread traffic across multiplepaths between routers. The behavior of the load-balance per-packet function dependson the version of the Internet Processor application-specific integrated circuit (ASIC)in your routing platform:

■ On routing platforms with the Internet Processor ASIC, when per-packet loadbalancing is configured, traffic between routers with multiple paths is spreadusing the hash algorithm across the available interfaces. The forwarding tablebalances the traffic headed to a destination, transmitting it in round-robin fashionamong the multiple next hops (up to a maximum of eight equal-cost load-balancedpaths). The traffic is load-balanced on a per-packet basis.

■ On routing platforms with the Internet Processor II ASIC, when per-packet loadbalancing is configured, traffic between routers with multiple paths is dividedinto individual traffic flows (up to a maximum of 16 equal-cost load-balancedpaths). Packets for each individual flow are kept on a single interface.

NOTE: You can configure per-packet load balancing to optimize VPLS traffic flowsacross multiple paths.

For information about configuring per-packet load balancing, see the following topics:

■ Configuring Per-Packet Load Balancing on page 145

■ Configuring Load Balancing Based on MPLS Labels on page 147

■ Configuring Load Balancing for Ethernet Pseudowires on page 150

■ Configuring Load Balancing Based on MAC Addresses on page 151

144 ■ Overview of Per-Packet Load Balancing


■ Configuring VPLS Load Balancing Based on IP and MPLS Information on page151

■ Configuring VPLS Load Balancing on MX Series Ethernet Services Routers onpage 153

Configuring Per-Packet Load Balancing

To configure per-packet load balancing as described in “Overview of Per-Packet LoadBalancing” on page 144, include the load-balance per-packet statement either as anoption of the route-filter statement at the [edit policy-options policy-statement policy-nameterm term-name from] hierarchy level:


load-balance per-packet;}

or at the [edit policy-options policy-statement policy-name term term-name then] hierarchylevel:

[edit policy-options policy-statement policy-name term term-name then]load-balance per-packet;

To complete the configuration you must apply the routing policy to routes exportedfrom the routing table to the forwarding table, by including the policy name in thelist specified by the export statement:

export [ policy-names ];


■ [edit routing-options forwarding-table]

■ [edit routing-instances routing-instance-name routing-options forwarding-table]

■ [edit logical-systems logical-system-name routing-options forwarding-table]

■ [edit logical-systems logical-system-name routing-instances routing-instance-namerouting-options forwarding-table]

By default, the software ignores port data when determining flows. To enable per-flowload balancing, you must set the load-balance per-packet action in the routing policyconfiguration; for more information about this action, see “Routing PolicyConfiguration” on page 39.

To include port data in the flow determination, include the family inet statement atthe [edit forwarding-options hash-key] hierarchy level:

[edit forwarding-options hash-key]family inet {

layer-3;layer-4;

}

Configuring Per-Packet Load Balancing ■ 145


If you include both the layer-3 and layer-4 statements, the router uses the followingLayer 3 and Layer 4 information to load-balance:

■ Source IP address

■ Destination IP address

■ Protocol

■ Source port number

■ Destination port number

■ Incoming interface index

■ IP type of service

The router recognizes packets in which all of these layer-3 and layer-4 parameters areidentical, and ensures that these packets are sent out through the same interface.This prevents problems that might otherwise occur with packets arriving at theirdestination out of their original sequence.

This is appropriate behavior for Transmission Control Protocol (TCP) and UserDatagram Protocol (UDP) packets. For Internet Control Message Protocol (ICMP)packets, the field location offset is the checksum field, which makes each ping packeta separate “flow.” There are other protocols that can be encapsulated in IP that mayhave a varying value in the 32-bit offset. This may also be problematic because theseprotocols are seen as a separate flow.

With M Series (with the exception of the M120 router) and T Series routers, the firstfragment is mapped to the same load-balanced destination as the unfragmentedpackets. The other fragments can be mapped to other load-balanced destinations.

For the M120 router only, all fragments are mapped to the same load-balanceddestination. This destination is not necessarily the same as that for unfragmentedpackets.

By default, or if you include only the layer-3 statement, the router uses the incominginterface index as well as the following Layer 3 information in the packet header toload balance traffic:



■ Protocol

By default, IP version 6 (IPv6) packets are automatically load-balanced based on thefollowing Layer 3 and Layer 4 information:



■ Protocol

■ Source port number

■ Destination port number

146 ■ Configuring Per-Packet Load Balancing


■ Incoming interface index

■ Traffic class

Per-Packet Load Balancing Examples

Perform per-packet load balancing for all routes:


policy-statement load-balancing-policy {then {


}}routing-options {

forwarding-table {export load-balancing-policy;

}}

Perform per-packet load balancing only for a limited set of routes:


policy-statement load-balancing-policy {from {

route-filter 192.168.10/24 orlonger;route-filter 10.114/16 orlonger;

}then {


}}routing-options {

forwarding-table {export load-balancing-policy;

}}

Configuring Load Balancing Based on MPLS Labels

To load-balance based on the MPLS label information, include the family mplsstatement at the [edit forwarding-options hash-key] hierarchy level:

[edit forwarding-options hash-key]family mpls {

label-1;label-2;label-3;no-labels;no-label-1-exp;

Configuring Load Balancing Based on MPLS Labels ■ 147


payload {ether-pseudowire;ip {

layer-3-only;port-data {

destination-lsb;destination-msb;source-lsb;source-msb;

}}

}}

This feature applies to aggregated Ethernet and aggregated SONET/SDH interfacesas well as multiple equal-cost MPLS next hops. In addition, on the T Series, MX Series,M120, and M320 routers only, you can configure load balancing for IPv4 traffic overLayer 2 Ethernet pseudowires. You can also configure load balancing for Ethernetpseudowires based on IP information. The option to include IP information in thehash key provides support for Ethernet circuit cross-connect (CCC) connections. Formore information about configuring load balancing for Ethernet pseudowires, see“Configuring Load Balancing for Ethernet Pseudowires” on page 150.

To include the first label in the hash key, include the label-1 option. This is used fora one-label packet.

To include the first and second label in the hash key, include both the label-1 andlabel-2 options. This is used for a two-label packet. The router provides hashing onthe first and second labels by default. If both labels are specified, the entire first labeland the first 16 bits of the second label are hashed.

To include the third MPLS label in the hash function, include the label-3 option at the[edit forwarding-options hash-key family mpls] hierarchy level. To include no MPLSlabels in the hash function, include the no-labels option at the [edit forwarding-optionshash-key family mpls] hierarchy level.

Hashing can include IP addresses to provide better distribution of traffic to aggregatedinterfaces.

To include the bits in the IP address of the IPv4 or IPv6 payload as well as the firstlabel in the hash key, include the label-1 and payload ip statements at the[edit forwarding-options hash-key family mpls] hierarchy level:


label-1;payload {

ip;}

}

To include the bits of the IP address of the IPv4 or IPv6 payload as well as both thefirst label and the second label in the hash key, include the label-1, label-2, and payloadip statements at the [edit forwarding-options hash-key family mpls] hierarchy level.

148 ■ Configuring Load Balancing Based on MPLS Labels


[edit forwarding-options hash-key family mpls]label-1;

label-2;label-3;no-labels;payload {

ip {layer-3-only;port-data {

source-msb;source-lsb;destination-msb;destination-lsb;

}}

}}

To include only Layer 3 IP information in the hash key, specify the layer-3-only optionat the [edit forwarding-options hash-key family mpls payload ip] hierarchy level. Toinclude the most significant byte of the source port, specify the source-msb option.To include the least significant byte of the source port, specify the source-lsb option.To include the most significant byte of the destination port, specify the destination-msboption. To include the least significant byte of the destination port, specify thedestination-lsb option.

By default, the most significant byte and least significant byte of the source anddestination port fields are hashed. To select specific bytes to be hashed, include oneor more of the source-msb, source-lsb, destination-msb, and destination-lsb options atthe [edit forwarding-options hash-key family mpls payload ip port-data] hierarchy level.To prevent all four bytes from being hashed, include the layer-3-only option at the[edit forwarding-options hash-key family mpls payload ip] hierarchy level.

In an Layer 2 VPN scenario, the router could encounter a reordering complication.When a burst of traffic pushes the customer traffic bandwidth to exceed its limits,the traffic might be affected in mid flow. Packets may be reordered as a result.

You can configure the EXP bit of the top label to be excluded from the hashcalculations to avoid the reordering complication. To exclude the EXP bit of the firstlabel from the hash calculations, include the no-label-1-exp statement at the[edit forwarding-options hash-key family mpls] hierarchy level:


label-1;no-label-1-exp;payload {

ip;}

}

You must also configure the label-1 statement when configuring the no-label-1-expstatement.

Configuring Load Balancing Based on MPLS Labels ■ 149


Configuring Load Balancing for Ethernet Pseudowires

You can configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires.You can also configure load balancing for Ethernet pseudowires based on IPinformation. The option to include IP information in the hash key provides supportfor Ethernet circuit cross-connect (CCC) connections.

NOTE: This feature is supported only on M120, M320, MX Series, and T Series routers.

To configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires, includethe ether-pseudowire statement at the [edit forwarding-options hash-key family mplspayload] hierarchy level:

[edit forwarding-options]hash-key {

family mpls {(label-1 | no-labels);payload {

ether-pseudowire;}

}}

NOTE: You must also configure either the label-1 or the no-labels statement at the[edit forwarding-options hash-key family mpls] hierarchy level.

You can also configure load balancing for Ethernet pseudowires based on IPinformation. This functionality provides support for load balancing for Ethernetcross-circuit connect (CCC) connections. To include IP information in the hash key,include the ip statement at the [edit forwarding-options hash-key family mpls payload]hierarchy level:



ip;}

}}

NOTE: You must also configure either the label-1 or no-labels statement at the [editforwarding-options hash-key family mpls] hierarchy level.

You can configure load balancing for IPv4 traffic over Ethernet pseudowires to includeonly Layer 3 IP information in the hash key. To include only Layer 3 IP information,

150 ■ Configuring Load Balancing for Ethernet Pseudowires


include the layer-3-only option at the [edit forwarding-options family mpls hash-keypayload ip] hierarchy level:



ip {layer-3-only;

}}

}}

NOTE: You must also configure either the label-1 or no-labels statement at the [editforwarding-options hash-key family mpls] hierarchy level.

Configuring Load Balancing Based on MAC Addresses

To load-balance traffic based on Layer 2 media access control (MAC) information,include the family multiservice statement at the [edit forwarding-options hash-key]hierarchy level:

family multiservice {destination-mac;source-mac;

}

To include the destination-address MAC information in the hash key, include thedestination-mac option. To include the source-address MAC information in the hashkey, include the source-mac option.

NOTE: You can configure per-packet load balancing to optimize VPLS traffic flowsacross multiple paths. For more detailed information, see the JUNOS VPNsConfiguration Guide.

NOTE: J Series Services Routers do not support this feature.

Configuring VPLS Load Balancing Based on IP and MPLS Information

In JUNOS Release 9.4 and later, you can configure load balancing for VPLS traffic tohave the hash key include IP information and MPLS labels on the M120 and M320routers only. In earlier JUNOS releases, you can configure load balancing based onlyon Layer 2 information. In JUNOS Release 9.5 and later, you can configure loadbalancing for VPLS traffic based on Layer 3 IP and Layer 4 information on MX Series

Configuring Load Balancing Based on MAC Addresses ■ 151


routers only. For more information, see “Configuring VPLS Load Balancing on MXSeries Ethernet Services Routers” on page 153.

For IPv4 traffic, only the IP source and destination addresses are included in thehash key. For MPLS and IPv4 traffic, one or two MPLS labels and IPv4 source anddestination addresses are included. For MPLS Ethernet pseudowires, only one or twoMPLS labels are included in the hash key.

NOTE: VPLS load balancing based on MPLS labels and IP information is supportedonly on the M120 and M320 routers. In JUNOS Release 9.5 and later, on MX Seriesrouters only, you can configure VPLS load balancing based on IP and Layer 4information.

To optimize VPLS flows across multiple paths based on IP and MPLS information,include the family multiservice statement at the [edit forwarding-options hash-key]hierarchy level:

family multiservice {label-1;label-2;payload {

ip {layer-3-only;

}}

}

To use the first MPLS label in the hash key, include the label-1 statement:

[edit forwarding-options hash-key family multiservice]label-1;

To use the second MPLS label, include both the label-1 and label-2 statements:

[edit forwarding-options hash-key family multiservice]label-1;label-2;

To use the packet’s IPv4 payload in the hash key, include the payload and ipstatements:

[edit forwarding-options hash-key family multiservice]payload {

ip;}

NOTE: Only IPv4 is supported.

To include only Layer 3 information from the IPv4 payload, specify the layer-3-onlyoption to the payload ip statement:

152 ■ Configuring VPLS Load Balancing Based on IP and MPLS Information


[edit forwarding-options hash-key family multiservice]payload {

ip {layer-3-only;

}}

To use the first and second MPLS labels and the packet’s IP payload in the hash key,include the label-1, label-2, and payload ip statements:

[edit forwarding-options hash-key family multiservice]label-1;label-2;payload {

ip;}

Configuring VPLS Load Balancing on MX Series Ethernet Services Routers

In JUNOS Release 9.5 and later, on MX Series routers, you can configure the loadbalancing hash key for Layer 2 traffic to use fields in the Layer 3 and Layer 4 headersinside the frame payload. You can also configure VPLS load balancing based on IPand MPLS information on M120 and M320 routers only. For more information, see“Configuring VPLS Load Balancing Based on IP and MPLS Information” on page 151.

You can configure load balancing on MX Series routers based on Layer 3 or Layer 4information or both.

To configure VPLS load balancing on the MX Series router to include either Layer 3IP information or Layer 4 headers or both:

1. Include the payload statement at the [edit forwarding-options hash-key familymultiservice] hierarchy level.

2. Include the ip statement at the [edit forwarding-options hash-key family multiservicepayload] hierarchy level.

To configure VPLS load balancing to include the Layer 3 information:

1. Include the layer-3 statement at the [edit forwarding-options hash-key familymultiservice payload ip] hierarchy level.

2. Include the source-address-only statement at the [edit forwarding-options hash-keyfamily multiservice payload ip layer-3] hierarchy level to include information aboutthe IP source address only in the hash key.

3. Include destination-address-only statement at the [edit forwarding-options haskh-keyfamily multiservice payload ip layer-3] hierarchy level to include information aboutthe IP destination address only in the hash key.

NOTE: You can configure either the source-address-only or the destination-address-onlystatements at a time, not both. They are mutually exclusive.

Configuring VPLS Load Balancing on MX Series Ethernet Services Routers ■ 153


To configure VPLS load balancing to include Layer 4 information:

■ Include the layer-4 statement at the [edit forwarding-options hash-key familymultiservice payload ip] hierarchy level.

The following example shows load balancing configured to use the source Layer 3IP address option and Layer 4 header fields as well as the source and destinationMAC addresses:

[edit forwarding-options hash-key]family multiservice {

source-mac;destination-mac;payload {

ip {layer-3 {

source-address-only;}layer-4;

}}

}Related Topics ■ family multiservice

■ hash-key

154 ■ Configuring VPLS Load Balancing on MX Series Ethernet Services Routers


Chapter 7

Summary of Routing Policy ConfigurationStatements

The following sections explain each of the routing policy configuration statements.The statements are organized alphabetically.

apply-path

Syntax apply-path path;

Hierarchy Level [edit logical-systems logical-system-name policy-options prefix-list name],[edit policy-options prefix-list name]

Release Information Statement introduced before JUNOS Release 7.4.

Description Expand a prefix list to include all prefixes pointed to by a defined path.

Options path—String of elements composed of identifiers or configuration keywords thatpoints to a set of prefixes. You can include wildcards (enclosed in angle brackets)to match more than one identifier. You cannot add a path element, includingwildcards, after a leaf statement. Path elements, including wildcards, can onlybe used after a container statement.

prefix-list name—Name of a list of IP version 4 (IPv4) or IP version 6 (IPv6) prefixes.To create a named list of IP address prefixes, see “Extended Match ConditionsConfiguration” on page 97.

Usage Guidelines See “Configuring Prefix Lists” on page 118.

Required Privilege Level routing—To view this statement in the configuration.routing-control—To add this statement to the configuration.

apply-path ■ 155

as-path

Syntax as-path name regular-expression;

Hierarchy Level [edit dynamic policy-options],[edit logical-systems logical-system-name policy-options],[edit policy-options]

Release Information Statement introduced before JUNOS Release 7.4.Support for configuration in the dynamic database introduced in JUNOS Release 9.5.

Description Define an autonomous system (AS) path regular expression for use in a routing policymatch condition.

Options name—Name that identifies the regular expression. The name can contain letters,numbers, and hyphens (-) and can be up to 255 characters long. To includespaces in the name, enclose it in quotation marks (“ ”).

regular-expression—One or more regular expressions used to match the AS path.

Usage Guidelines See “Configuring AS Path Regular Expressions to Use as Routing Policy MatchConditions” on page 97 and “Configuring Routing Policies and Policy Objects in theDynamic Database” on page 66.

NOTE: Because the JUNOS Software does not validate configuration changes to thedynamic database, when you use this feature, you should test and verify allconfiguration changes before committing them.


Related Topics dynamic-db

156 ■ as-path


as-path-group

Syntax as-path-group group-name {as-path name regular-expression;

}


Release Information Statement introduced before JUNOS Release 7.4.Support for dynamic database configuration introduced in JUNOS Release 9.5.

Description Define a group containing multiple AS path regular expressions for use in a routingpolicy match condition.

Options group-name—Name that identifies the AS path group. One or more AS path regularexpressions must be listed below the as-path-group hierarchy.

name—Name that identifies the regular expression. The name can contain letters,numbers, and hyphens (-) and can be up to 255 characters long. To includespaces in the name, enclose it in quotation marks (“ ”).

regular-expression—One or more regular expressions used to match the AS path.

Usage Guidelines See “Configuring AS Path Regular Expressions to Use as Routing Policy MatchConditions” on page 97 and “Configuring Routing Policies and Policy Objects in theDynamic Database” on page 66.




as-path-group ■ 157

Chapter 7: Summary of Routing Policy Configuration Statements

community

Syntax community name {invert-match;members [ community-ids ];

}



Description Define a community or extended community for use in a routing policy matchcondition.

Options name—Name that identifies the regular expression. The name can contain letters,numbers, and hyphens (-) and can be up to 255 characters. To include spacesin the name, enclose it in quotation marks (“ ”).

invert-match—Invert the results of the community expression matching.

members community-ids—One or more community members. If you specify morethan one member, you must enclose all members in brackets.

The format for community-ids is:

as-number:community-value

as-number is the AS number and can be a value in the range from 0 through 65,535.community-value is the community identifier and can be a number in the rangefrom 0 through 65,535.

You also can specify community-ids for communities as one of the following well-knowncommunity names, which are defined in RFC 1997, BGP Communities Attribute:

■ no-export—Routes containing this community name are not advertised outsidea BGP confederation boundary.

■ no-advertise—Routes containing this community name are not advertised toother BGP peers.

■ no-export-subconfed—Routes containing this community name are not advertisedto external BGP peers, including peers in other members' ASs inside a BGPconfederation.

You can explicitly exclude BGP community information with a static route using thenone option. Include none when configuring an individual route in the routeportion of the static statement to override a community option specified in thedefaults portion of the statement.

158 ■ community


The format for extended community-ids is the following:

type:administrator:assigned-number

type is the type of extended community and can be either a bandwidth, target, origin,domain-id, src-as, or rt-import community or a 16-bit number that identifies aspecific BGP extended community. The target community identifies thedestination to which the route is going. The origin community identifies wherethe route originated. The domain-id community identifies the OSPF domain fromwhich the route originated. The src-as community identifies the autonomoussystem from which the route originated. The rt-import community identifies theroute to install in the routing table.

NOTE: For src-as, you can specify only an AS number and not an IP address. Forrt-import, you can specify only an IP address and not an AS number.

administrator is the administrator. It is either an AS number or an IPv4 address prefix,depending on the type of extended community.

assigned-number identifies the local provider.

The format for linking a bandwidth with an AS number is:

bandwidth:as-number:bandwidth

as-number specifies the AS number and bandwidth specifies the bandwidth in bytesper second.

NOTE: In JUNOS Release 9.1 and later, you can specify 4-byte AS numbers as definedin RFC 4893, BGP Support for Four-octet AS Number Space, as well as the 2-byte ASnumbers that are supported in earlier releases of the JUNOS Software. In plain-numberformat, you can configure a value in the range from 1 through 4,294,967,295. Toconfigure a target or origin extended community that includes a 4-byte AS numberin the plain-number format, append the letter “L” to the end of number. For example,a target community with the 4-byte AS number 334,324 and an assigned numberof 132 is represented as target:334324L:132.

In JUNOS Release 9.2 and later, you can also use AS-dot notation when defining a4-byte AS number for the target and origin extended communities. Specify two integersjoined by a period: 16-bit high-order value in decimal.16-bit low-order value in decimal.For example, the 4-byte AS number represented in plain-number format as 65546is represented in AS-dot notation as 1.10.

For more information about configuring AS numbers, see the JUNOS Routing ProtocolsConfiguration Guide.

community ■ 159


Usage Guidelines See “Overview of BGP Communities and Extended Communities as Routing PolicyMatch Conditions” on page 104, “Defining BGP Communities and ExtendedCommunities for Use in Routing Policy Match Conditions” on page 106, and“Configuring Routing Policies and Policy Objects in the Dynamic Database” on page66.




condition

Syntax condition condition-name {if-route-exists address table table-name;

}


Release Information Statement introduced in JUNOS Release 9.0.Support for configuration in the dynamic database introduced in JUNOS Release 9.5.

Description Define a policy condition based on the existence of routes in specific tables for usein BGP export policies.

Options if-route-exists address—Specify the address of the route in question.

table table-name—Specify a routing table.

Usage Guidelines See “Configuring Routing Policy Match Conditions Based on Routing Table Entries”on page 134 and “Configuring Routing Policies and Policy Objects in the DynamicDatabase” on page 66.




160 ■ condition


damping

Syntax damping name {disable;half-life minutes;max-suppress minutes;reuse number;suppress number;

}

Hierarchy Level [edit logical-systems logical-system-name policy-options],[edit policy-options]


Description Define route flap damping properties to set on BGP routes.

Options disable—Disable damping on a per-prefix basis. Any damping state that is presentin the routing table for a prefix is deleted if damping is disabled.

half-life minutes—Decay half-life. minutes is the interval after which the accumulatedfigure-of-merit value is reduced by half if the route remains stable.Range: 1 through 45Default: 15 minutes

max-suppress minutes—Maximum hold-down time. minutes is the maximum timethat a route can be suppressed no matter how unstable it has been.Range: 1 through 720Default: 60 minutes

name—Name that identifies the set of damping parameters. The name can containletters, numbers, and hyphens (-) and can be up to 255 characters long. Toinclude spaces in the name, enclose it in quotation marks (“ ”).

reuse number—Reuse threshold. number is the figure-of-merit value below which asuppressed route can be used again.Range: 1 through 20,000Default: 750 (unitless)

suppress number—Cutoff (suppression) threshold. number is the figure-of-merit valueabove which a route is suppressed for use or inclusion in advertisements.Range: 1 through 20,000Default: 3000 (unitless)

Usage Guidelines See “Configuring BGP Flap Damping Parameters” on page 139.


damping ■ 161


dynamic-db

Syntax dynamic-db;

Hierarchy Level [edit logical-systems logical-system-name policy-options as-path path-name],[edit logical-systems logical-system-name policy-options as-path-group group-name],[edit logical-systems logical-system-name policy-options community community-name],[edit logical-systems logical-system-name policy-options condition condition-name],[edit logical-systems logical-system-name policy-options policy-statement

policy-statement-name],[edit logical-systems logical-system-name policy-options prefix-list prefix-list-name],[edit policy-options as-path path-name],[edit policy-options as-path-group group-name],[edit policy-options community community-name],[edit policy-options condition condition-name],[edit policy-options policy-statement policy-statement-name],[edit policy-options prefix-list prefix-list-name]

Release Information Statement introduced in JUNOS Release 9.5.

Description Define routing policies and policy objects that reference policies configured in thedynamic database at the [edit dynamic] hierarchy level.

Usage Guidelines See “Configuring Routing Policies Based on Dynamic Database Configuration” onpage 67.

Required Privilege Level routing—To view this statement in the configuration.routing-control-level—To add this statement to the configuration.

162 ■ dynamic-db


export

Syntax export [ policy-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols bgp],[edit logical-systems logical-system-name protocols bgp group group-name],[edit logical-systems logical-system-name protocols bgp group group-name neighbor

address],[edit logical-systems logical-system-name protocols bgp group group-name neighbor

address out-delay seconds],[edit logical-systems logical-system-name protocols dvmrp],[edit logical-systems logical-system-name protocols isis],[edit logical-systems logical-system-name protocols ldp],[edit logical-systems logical-system-name protocols msdp],[edit logical-systems logical-system-name protocols msdp group group-name],[edit logical-systems logical-system-name protocols msdp group group-name peer address],[edit logical-systems logical-system-name protocols ospf],[edit logical-systems logical-system-name protocols ospf3],[edit logical-systems logical-system-name protocols pim rp bootstrap family (inet | inet6)],[edit logical-systems logical-system-name rip group group-name],[edit logical-systems logical-system-name ripng group group-name],[edit protocols bgp],[edit protocols bgp group group-name],[edit protocols bgp group-name neighbor address],[edit protocols bgp group group-name neighbor address out-delay seconds],[edit protocols bgp out-delay seconds],[edit protocols dvmrp],[edit protocols isis],[edit protocols ldp],[edit protocols msdp],[edit protocols msdp group group-name],[edit protocols msdp group group-name peer peer-address],[edit protocols msdp peer address],[edit protocols ospf],[edit protocols ospf3],[edit protocols pim rp bootstrap family (inet | inet6)],[edit rip group group-name],[edit ripng group group-name],[edit routing-instances routing-instance-name protocols bgp],[edit routing-instances routing-instance-name protocols bgp group group-name],[edit routing-instances routing-instance-name protocols bgp group group-name neighbor

address],[edit routing-instances routing-instance-name protocols bgp group group-name neighbor

address out-delay seconds],[edit routing-instances routing-instance-name protocols bgp out-delay seconds],[edit routing-instances routing-instance-name protocols dvmrp],[edit routing-instances routing-instance-name protocols isis],[edit routing-instances routing-instance-name protocols ldp],[edit routing-instances routing-instance-name protocols msdp],[edit routing-instances routing-instance-name protocols msdp group group-name],[edit routing-instances routing-instance-name protocols msdp group group-name peer

address],

export ■ 163


[edit routing-instances routing-instance-name protocols msdp peer address],[edit routing-instances routing-instance-name protocols ospf],[edit routing-instances routing-instance-name protocols ospf3],[edit routing-instances routing-instance-name protocols pim rp bootstrap family (inet |

inet6)],[edit routing-instances routing-instance-name protocols rip group group-name],[edit routing-instances routing-instance-name protocols ripng group group-name]


Description Apply one or more policies to routes being exported from the routing table into arouting protocol.

Options policy-names—Names of one or more policies defined with a policy-statementstatement.

Usage Guidelines See “Applying Routing Policies and Policy Chains to Routing Protocols” on page 57.


164 ■ export


import

Syntax import [ policy-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols bgp],[edit logical-systems logical-system-name protocols bgp group group-name],[edit logical-systems logical-system-name protocols dvmrp],[edit logical-systems logical-system-name protocols ldp],[edit logical-systems logical-system-name protocols msdp],[edit logical-systems logical-system-name protocols msdp peer address],[edit logical-systems logical-system-name protocols msdp group group-name],[edit logical-systems logical-system-name protocols msdp group group-name peer address],[edit logical-systems logical-system-name protocols ospf],[edit logical-systems logical-system-name protocols ospf3],[edit logical-systems logical-system-name protocols pim],[edit logical-systems logical-system-name protocols pim rp bootstrap family (inet | inet6)],[edit logical-systems logical-system-name protocols rip],[edit logical-systems logical-system-name protocols rip group group-name],[edit logical-systems logical-system-name protocols rip group group-name neighbor

address],[edit logical-systems logical-system-name protocols ripng],[edit logical-systems logical-system-name protocols ripng group group-name],[edit logical-systems logical-system-name protocols ripng group group-name neighbor

address],[edit protocols bgp],[edit protocols bgp group group-name],[edit protocols bgp group group-name neighbor address],[edit protocols dvmrp],[edit protocols ldp],[edit protocols msdp],[edit protocols msdp peer address],[edit protocols msdp group group-name],[edit protocols msdp group group-name peer address],[edit protocols ospf],[edit protocols ospf3],[edit protocols pim],[edit protocols pim rp bootstrap family (inet | inet6)],[edit protocols rip],[edit protocols rip group group-name],[edit protocols rip group group-name neighbor address],[edit protocols ripng],[edit protocols ripng group group-name],[edit protocols ripng group group-name neighbor address],[edit routing-instances routing-instance-name protocols bgp],[edit routing-instances routing-instance-name protocols bgp group group-name neighbor

address],[edit routing-instances routing-instance-name protocols dvmrp],[edit routing-instances routing-instance-name protocols ldp],[edit routing-instances routing-instance-name protocols msdp],[edit routing-instances routing-instance-name protocols msdp peer address],[edit routing-instances routing-instance-name protocols msdp group group-name],

import ■ 165


[edit routing-instances routing-instance-name protocols msdp group group-name peeraddress],

[edit routing-instances routing-instance-name protocols ospf],[edit routing-instances routing-instance-name protocols ospf3],[edit routing-instances routing-instance-name protocols pim],[edit routing-instances routing-instance-name protocols pim rp bootstrap family (inet |

inet6)],[edit routing-instances routing-instance-name protocols rip],[edit routing-instances routing-instance-name protocols rip group group-name],[edit routing-instances routing-instance-name protocols rip group group-name neighbor

address],[edit routing-instances routing-instance-name protocols ripng],[edit routing-instances routing-instance-name protocols ripng group group-name],[edit routing-instances routing-instance-name protocols ripng group group-name neighbor

address]


Description Apply one or more policies to routes being imported into the routing table from arouting protocol.

Options policy-names—Names of one or more policies defined with a policy-statementstatement.

Usage Guidelines See “Applying Routing Policies and Policy Chains to Routing Protocols” on page 57.


policy-options

Syntax policy-options { ... }

Hierarchy Level [edit],[edit dynamic]


Description Configure routing policy.

Options The statements are explained separately.

Usage Guidelines See “Defining Routing Policies” on page 40.


166 ■ policy-options


policy-statement

Syntax policy-statement policy-name {term term-name {

from {family family-name;match-conditions;policy subroutine-policy-name;prefix-list prefix-list-name;prefix-list-filter prefix-list-name match-type <actions>;route-filter destination-prefix match-type <actions>;source-address-filter source-prefix match-type <actions>;

}to {


}then actions;

}}



Description Define a routing policy, including subroutine policies.

Options actions—(Optional) One or more actions to take if the conditions match. The actionsare described in Table 11 on page 49 and Table 12 on page 49.

family family-name—(Optional) Specify an address family protocol. Specify inet for anIPv4 address protocol. Specify inet6 for a 128-bit IPv6 address protocol, and toenable interpretation of IPv6 router filter addresses. For IS-IS traffic, For IPv4multicast VPN traffic, specify inet-mvpn. For IPv6 multicast VPN traffic, specifyinet6–mvpn.

NOTE: When family is not specified, the router uses the default IPv4 setting.

from—(Optional) Match a route based on its source address.

match-conditions—(Optional in from statement; required in to statement) One or moreconditions to use to make a match. The qualifiers are described in Table 10 onpage 42.

policy subroutine-policy-name—Use another policy as a match condition within thispolicy. The name identifying the subroutine policy can contain letters, numbers,and hyphens (-) and can be up to 255 characters long. To include spaces in the

policy-statement ■ 167


name, enclose it in quotation marks (“ ”). For information about how to configuresubroutines, see “Configuring Subroutines in Routing Policy Match Conditions”on page 130.

policy-name—Name that identifies the policy. The name can contain letters, numbers,and hyphens (-) and can be up to 255 characters long. To include spaces in thename, enclose it in quotation marks (“ ”).

prefix-list prefix-list-name —Name of a list of IPv4 or IPv6 prefixes. To create a namedlist of IP address prefixes, see “Extended Match Conditions Configuration” onpage 97.

prefix-list-filter prefix-list-name—Name of a prefix list to evaluate using qualifiers;match-type is the type of match (see Table 21 on page 123), and actions is theaction to take if the prefixes match.

route-filter destination-prefix match-type <actions>—(Optional) List of routes on whichto perform an immediate match; destination-prefix is the IPv4 or IPv6 route prefixto match, match-type is the type of match (see Table 20 on page 120), and actionsis the action to take if the destination-prefix matches.

source-address-filter source-prefix match-type <actions>—(Optional) Unicast sourceaddresses in multiprotocol BGP (MBGP) and Multicast Source Discovery Protocol(MSDP) environments on which to perform an immediate match. source-prefixis the IPv4 or IPv6 route prefix to match, match-type is the type of match (seeTable 21 on page 123), and actions is the action to take if the source-prefix matches.

term term-name—Name that identifies the term.

to—(Optional) Match a route based on its destination address or the protocols intowhich the route is being advertised.

then—(Optional) Actions to take on matching routes. The actions are described inTable 11 on page 49 and Table 12 on page 49.

Usage Guidelines See “Defining Routing Policies” on page 40, “Extended Match ConditionsConfiguration” on page 97 and “Configuring Routing Policies and Policy Objects inthe Dynamic Database” on page 66.




168 ■ policy-statement


prefix-list

Syntax prefix-list name {ip-addresses;apply-path path;

}



Description Define a list of IPv4 or IPv6 address prefixes for use in a routing policy statement orfirewall filter statement.

Options name—Name that identifies the list of IPv4 or IPv6 address prefixes.

ip-addresses—List of IPv4 or IPv6 address prefixes, one IP address per line in theconfiguration.

The remaining statement is explained separately in this chapter.

Usage Guidelines See “Configuring Prefix Lists for Use in Routing Policy Match Conditions” on page117 and “Configuring Routing Policies and Policy Objects in the Dynamic Database”on page 66.



prefix-list ■ 169


prefix-list-filter

Syntax prefix-list-filter prefix-list-name match-type <actions>;

Hierarchy Level [edit logical-systems logical-system-name policy-options],[edit policy-options]


Description Evaluate a list of prefixes within a prefix list using specified qualifiers.

Options prefix-list-name—Name of the prefix list to evaluate.

match-type—Prefix length qualifiers.

<actions>—(Optional) Actions to take on match.

Usage Guidelines See “Configuring Prefix Lists for Use in Routing Policy Match Conditions” on page117.


170 ■ prefix-list-filter


Part 3

Firewall Filters

■ Introduction to Firewall Filters on page 173

■ Firewall Filter Configuration on page 177

■ Policer Overview on page 253

■ Policer Configuration on page 255

■ Summary of Firewall Filter and Policer Configuration Statements on page 283

Firewall Filters ■ 171

172 ■ Firewall Filters


Chapter 8

Introduction to Firewall Filters

This chapter describes the following topics:

■ Firewall Filter Overview on page 173

■ Firewall Filter Components on page 173

■ Supported Standards on page 176

Firewall Filter Overview

The JUNOS Software firewall filters support a rich set of packet-matching criteria thatyou can use to match on specific traffic and perform specific actions, such asforwarding or dropping packets that match the criteria you specify. The basic purposeof a firewall filter is to enhance security through the use of packet filtering. The rulesyou define in a firewall filter are used to determine whether to accept, deny, orforward specific types of traffic. You can configure firewall filters to protect the localrouter or to protect another device that is either directly or indirectly connected tothe local router. For example, you can use the filters to restrict the local packets thatpass from the router’s physical interfaces to the Routing Engine. Such filters areuseful in protecting the IP services that run on the Routing Engine, such as Telnet,SSH, and BGP, from denial-of-service attacks. You can also use firewall filters toperform multifield classification, counting, and policing. Multifield classification isused to perform specialized packet handling, including filter-based forwarding, orpolicy-based routing. Counting lets you gather usage statistics. Policing is used toenforce bandwidth restrictions. Firewall filters are stateless, that is, they cannotstatefully inspect traffic. Firewall Filters that perform all these functions are standardfirewall filters. The JUNOS Software also supports two additional specialized firewallfilter types: simple filters and service filters.

NOTE: There is no limit to the number of filters and counters you can set, but thereare some practical considerations. More counters require more terms, and a largenumber of terms can take a long time to process during a commit operation. However,filters with more than 4000 terms and counters have been implemented successfully.

Firewall Filter Components

A firewall filter consists of a protocol family and one or more terms that specify thefiltering criteria and the action to take if a match occurs. After you define a firewallfilter, you apply it to specific interfaces. Because the firewall filter process consists

Firewall Filter Overview ■ 173

of two aspects—creating filters and then applying filters—you can reuse the samefilters on your router. Also, when you need to update the firewall filter itself, youhave to make the change only in one place.

When writing a firewall filter, you start by selecting the protocol family for whichyou want to specify filtering criteria. Firewall filters support the following protocolfamilies:

■ IPv4 (inet)

■ IPv6 (inet6)

■ MPLS (mpls)

■ VPLS (vpls)

■ Circuit cross-connects (ccc)

■ (MX Series Ethernet Services routers only) Bridge (bridge)

■ Protocol-independent (any)

Firewall filters require you to use terms. Each term can include both match criteriaand actions. After you define the firewall filter, you must apply it to an attachmentpoint. These attachment points include logical interfaces, physical interfaces, routinginterfaces and routing instances. You can apply a firewall filter as an input filter oran output filter, or both at the same time. Input filters take action on packets beingreceived on the specified interface, whereas output filters take action on packets thatare transmitted through the specified interface. You typically apply one filter withmultiple terms to a single logical interface, to incoming traffic, outbound traffic, orboth. However, there are times when you might want to chain mulitple firewall filters(with single or multiple terms) together and apply them to an interface. For example,on a router with hundreds of interfaces, it can be more efficient to configure andapply a set of filters that you can apply to multiple interfaces rather than to configurehundreds of filters, one for each interface. You use an input list to apply multiplefirewall filters to the incoming traffic on an interface. You use an output list to applymultiple firewall filters to the outbound traffic on an interface. You can include upto 16 filters in an input or an output list.

The order in which you configure firewall filter terms is important. Terms areevaluated in the order in which they are configured. By default, new terms are alwaysadded to the end of the existing filter. You can use the insert command to reorderthe terms of a firewall filter.

By default, each firewall filter ends with an implicit deny-all term. The final defaultaction is to discard all packets. Packets that do not match any of the configuredmatch conditions in a firewall filter are silently discarded.

If a packet arrives on an interface and a firewall filter is not configured for theincoming traffic on that interface, the packet is accepted by default.

Match conditions are the fields or values that the packet must contain. You can definevarious match conditions, including the IP source address field, IP destination addressfield, Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) sourceport field, IP protocol field, Internet Control Message Protocol (ICMP) packet type,

174 ■ Firewall Filter Components


IP options, TCP flags, incoming logical or physical interface, and outgoing logical orphysical interface.

Within a single term, all the match conditions configured must match the packetbefore the configured action is taken on the packet. For a single match conditionconfigured with multiple values, such as a range of values, only one of the valuesmust match the packet before the match occurs and the configured action is takenon the packet.

Actions fall into the following categories:

■ Terminating—A terminating action halts all evaluation of a firewall filter for aspecific packet. The router performs the specified action, and no additional termsare examined.

■ Modifiers—Action modifiers are used to perform other functions on a packet,such as incrementing a counter, logging information about the packet header,sampling the packet data, or sending information to a remote host using thesystem log functionality.

■ Flow control—The flow-control action next term enables the router to performconfigured actions on the packet and then evaluate the following term in thefilter, rather than terminating the filter. If the next term action is included, thematching packet is then evaluated against the next term in the firewall filter;otherwise, the matching packet is not evaluated against subsequent terms in thefirewall filter. For example, When you configure a term with the action modifiercount, the term’s action changes from an implicit discard to an implicit accept.The next term action forces the continued evaluation of the firewall filter.

Actions and action modifiers that are configured within a single term are all takenon traffic that matches the conditions configured.

Firewall Filter Types

In addition to standard firewall filters, the JUNOS Software firewall filterimplementation also supports two other firewall filter types: service filters and simplefilters.

Service filters enable you to define filters associated with a defined set of services.Service filters are supported on services interfaces, which provide specific capabilitiesfor manipulating traffic before it is delivered to its destination. You use service filtersto refine the target of the set of services and also to process traffic. Only IPv4 andIPv6 traffic are supported on service filters. No other protocol families are supported.

Simple filters are supported on Gigabit Ethernet intelligent queuing (IQ2) andEnhanced Queuing Dense Port Concentrator (EQ DPC) interfaces only. Unlike standardfilters, simple filters support IPv4 traffic only and have a number of restrictions. Forexample, you cannot configure a terminating action for a simple fllter. Simple filtersalways accept packets. Also, simple filters can be applied only as input filters. Theyare not supported on outbound traffic. Simple filters are recommended formetropolitan Ethernet applications.

Firewall Filter Components ■ 175

Chapter 8: Introduction to Firewall Filters

Supported Standards

The JUNOS Software supports the following RFCs related to filtering:

■ RFC 792, Inernet Control Message Protocol

■ RFC 2460, Internet Protocol, Version 6 (IPv6)

■ RFC 2474, Definition of the Differentiated Services (DS) Field

■ RFC 2475, An Architecture for Differentiated Services

■ RFC 2597, Assured Forwarding PHB Group

■ RFC 3246, An Expedited Forwarding PHB (Per-Hop Behavior)

■ RFC 4291, IP Version 6 Addressing Architecture

■ RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet ProtocolVersion 6 (IPv6) Specification

176 ■ Supported Standards


Chapter 9

Firewall Filter Configuration

This chapter describes the following tasks for configuring firewall filters:

■ Configuring Firewall Filters on page 178

■ Configuring Standard Firewall Filters on page 179

■ Configuring Match Conditions in Firewall Filter Terms on page 182

■ Configuring Actions in Firewall Filter Terms on page 208

■ Configuring Nested Firewall Filters on page 214

■ Applying Firewall Filters to Interfaces on page 216

■ Firewall Filter Examples on page 220

■ Example: Blocking Telnet and SSH Access on page 220

■ Example: Blocking TFTP Access on page 221

■ Example: Accepting DHCP Packets with Specific Addresses on page 222

■ Example: Defining a Policer for a Destination Class on page 222

■ Example: Counting IP Option Packets on page 223

■ Example: Accepting OSPF Packets from Certain Addresses on page 224

■ Example: Matching Packets Based on Two Unrelated Criteria on page 224

■ Example: Counting Both Accepted and Rejected Packets on page 225

■ Example: Blocking TCP Connections to a Certain Port Except from BGPPeers on page 225

■ Example: Accepting Packets with Specific IPv6 TCP Flags on page 226

■ Example: Setting a Rate Limit for Incoming Layer 2 Control Packets on page 227

■ Configuring Service Filters on page 228

■ Configuring Simple Filters on page 229

■ Configuring Firewall Filters for Logical Systems on page 231

■ Configuring Accounting for Firewall Filters on page 244

■ Configuring Filter-Based Forwarding on page 245

■ Configuring Forwarding Table Filters on page 247

■ Configuring System Logging of Firewall Filter Operations on page 249

■ 177

Configuring Firewall Filters

This section shows this complete set of statements that can be configured at the [editfirewall] hierarchy level to create a firewall filter.

[edit firewall]family family-name {

filter filter-name {<accounting-profile name>;<interface-specific>;<physical-interface-filter>;term term-name {

filter filter-name;from {

match-conditions;}then {

action;action-modifiers;

}}

}<service-filter filter-name> {




}}

}<simple-filter filter-name> {




}}

}}

To configure an IPv4 firewall filter, you can configure the filter at the [edit firewall]hierarchy level without including the family inet statement. The [edit firewall] and [editfirewall filter family inet] hierarchies are equivalent. The family family-name statementis required only to specify a protocol family other than IPv4.

178 ■ Configuring Firewall Filters


NOTE: For stateless firewall filtering, you must allow the output tunnel traffic throughthe firewall filter applied to input traffic on the interface that is the next-hop interfacetowards the tunnel destination. The firewall filter affects only the packets exiting therouter by way of the tunnel.

Configuring Standard Firewall Filters

To configure standard firewall filters, include the firewall statement at the [edit]hierarchy level:

[edit]firewall {

family family-name {filter filter-name {

<accounting-profile name>;<interface-specific>;term term-name {

from {match-conditions;

}then {


}}

}}

}

The following sections describe how to configure firewall filters and how they areevaluated:

■ Configuring the Address Family on page 179

■ Configuring the Filter Name on page 180

■ Configuring Firewall Filter Terms on page 180

■ How Firewall Filters Are Evaluated on page 181

Configuring the Address Family

To configure the address family of the packets that a firewall filter matches, includethe family family-name statement at the [edit firewall] hierarchy level:


... filter-configuration ...}

For the family-name variable, specify inet to filter IPv4 packets. Specify inet6 to filterIP version 6 (IPv6) packets. Specify mpls to filter MPLS packets. Specify vpls to filter

Configuring Standard Firewall Filters ■ 179

Chapter 9: Firewall Filter Configuration

virtual private LAN service (VPLS) packets. Specify ccc to filter Layer 2 switchingcross-connects.

On the MX Series router only, specify bridge to filter Layer 2 packets in a bridgingenvironment.

Specify any to filter packets based upon protocol-independent fields. Filters definedfor this family type can match on the following protocol-independent matchconditions: forwarding-class, forwarding-class-except, interface, packet-length,packet-length-except, interface-index, and interface-set.

For a complete list of the match conditions supported by each protocol family, see“Configuring Match Conditions in Firewall Filter Terms” on page 182.

Configuring the Filter Name

To configure the filter name, include the filter statement at the [edit firewall familyfamily-name] hierarchy level:

[edit firewall family family-name]filter filter-name {

... term-configuration ...}

The filter name can contain letters, numbers, and hyphens (-) and can be up to64 characters long. To include spaces in the name, enclose the entire name inquotation marks (“ ”).

Configuring Firewall Filter Terms

Each firewall filter consists of one or more terms. To configure a term, include theterm statement at the [edit firewall family family-name filter filter-name] hierarchy level:

[edit firewall family family-name filter filter-name]term term-name {

...match-conditions ...

...actions}

For IPv4 traffic, configure the filter terms at the [edit firewall family inet filter filter-name]hierarchy level. For IPv6 traffic, configure the filter terms at the [edit firewall familyinet6 filter filter-name] hierarchy level. For MPLS traffic, configure the filter terms atthe [edit firewall family mpls filter filter-name] hierarchy level. For VPLS trafffic, configurethe filter terms at the [edit firewall family vpls filter filter-name] hierarchy level. Forcircuit cross-connect (CCC) traffic, configure the filter terms at the [edit firewall famlyccc filter filter-name] hierarchy level. For protocol-independent traffic, configure thefilter terms at the [edit firewalll family any filter filter-name] hierarchy level. For Layer 2bridging traffic, configure the filter terms at the [edit firewall family bridge filterfilter-name] hierarchy level.

180 ■ Configuring Standard Firewall Filters


NOTE: Layer 2 bridging is supported only on the MX Series routers. For moreinformation about how to configure Layer 2 bridging, see the JUNOS Network InterfacesConfiguration Guide, the JUNOS MX Series Ethernet Services Routers Solutions Guide,and the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide.

The name can contain letters, numbers, and hyphens (-) and can be up to64 characters long. To include spaces in the name, enclose the entire name inquotation marks (“ ”).

Each term name must be unique within the filter.

You can specify multiple terms in a filter, effectively chaining together a series ofmatch-action operations to apply to the packets on an interface. You can also usethe next term action so that, when a match condition is met, the evaluation continuesto the next term, rather than terminating.

Firewall filter terms are evaluated in the order in which you specify them in theconfiguration. To reorder terms, use the configuration mode insert command. Forexample, the command insert term up before term start places the term up beforethe term start.

For information about configuring the match conditions and actions in a firewallfilter, see the following sections

■ Configuring Match Conditions in Firewall Filter Terms on page 182

■ Configuring Actions in Firewall Filter Terms on page 208

How Firewall Filters Are Evaluated

When a firewall filter consists of a single term, the filter is evaluated as follows:

■ If the packet matches all the conditions, the action in the then statement is taken.

■ If the packet matches all the conditions, and if there is no action specified in thethen statement, the default action accept is used.

■ If the packet does not match all the conditions, it is discarded.

When a firewall filter consists of more than one term, the terms in the filter areevaluated sequentially:

1. The packet is evaluated against the conditions in the from statement in the firstterm.

2. If the packet matches the from statement, the action in the then statement isperformed. Then:

■ If the next term action is not specified, the evaluation ends. Subsequent termsin the filter are not evaluated.

■ If the next term action is present, the evaluation continues to the next term.

Configuring Standard Firewall Filters ■ 181


3. If the packet does not match the from statement in the first term, it is evaluatedagainst the conditions in the from statement in the second term.

This process continues until either the packet matches the from conditions inone of the subsequent terms or there are no more terms.

Both for filters with a single term and for filters with multiple terms, if a term doesnot contain a from statement, the action in the term’s then statement is performedon all packets.

If a term does not contain a then statement or if you do not specify an action in thethen statement, and if the packet matches the conditions in the term’s from statement,the packet is accepted.

Each firewall filter has an implicit discard action at the end of the filter, which isequivalent to the following explicit filter term:

term implicit-rule {then discard;

}

Therefore, if a packet matches none of the terms in the filter, it is discarded.

Configuring Match Conditions in Firewall Filter Terms

In the from statement in a firewall filter term, you specify characteristics that thepacket must have for the action in the subsequent then statement to be performed.The characteristics are referred to as match conditions. The packet must match allconditions in the from statement for the action to be performed, which also meansthat their order in the from statement is not important.

To configure match conditions, include the from statement at the [edit firewall familyfamily-name filter filter-name term term-name] hierarchy level:

[edit firewall family family-name filter filter-name term term-name]from {

match-conditions;}

Table 24 on page 185 describes the numeric range filter match conditions forIPv4 addresses, and Table 25 on page 189 describes them for IPv6 addresses.

Table 26 on page 192 describes the filter match conditions supported for VPLS traffic.Not all match conditions for VPLS traffic are supported on all routing platforms. Anumber of match conditions for VPLS traffic are supported only on MX Series EthernetServices Routers, as noted in the Table 26 on page 192.Table 27 on page 196 describesthe firewall filter match conditions supported for MPLS traffic. No other matchconditions are supported for the family mpls statement. Table 28 on page 196 describesthe firewall match conditions supported for protocol-independent traffic. Firewallfilter match conditions configured for protocol-independent traffic can be appliedboth to loopback (lo0) and logical interfaces. No other match conditions are supportedfor the family any statement. Table 29 on page 197 describes the firewall filter match

182 ■ Configuring Match Conditions in Firewall Filter Terms


conditions supported for Layer 2 circuit cross-connect (CCC) traffic. No other matchconditions are supported for the family ccc statement.

The MX Series router also supports match conditions for Layer 2 bridging traffic.Table 30 on page 197 describes these filter match conditions, which are supportedwith the family bridge statement on MX Series routers only. For more informationabout how to configure Layer 2 services on the MX Series routers, see the JUNOSNetwork Interfaces Configuration Guide, the JUNOS MX Series Ethernet Services RoutersLayer 2 Configuration Guide, and the JUNOS MX Series Ethernet Services RoutersSolutions Guide.

You can specify zero or more match conditions in a single from statement. For amatch to occur, the packet must match all the conditions in the term.

An individual condition in a from statement can contain a list of values. For example,you can specify numeric ranges or multiple source or destination addresses. Whena condition defines a list of values, a match occurs if any the values matches thepacket.

You can also define individual conditions negatively. If a packet matches a negatedcondition, it is immediately considered not to match the from statement, and thenext term in the filter is evaluated, if there is one; if there are no more terms, thepacket is discarded.

The from statement is optional. If you omit it, the actions specified in the term’s thenstatement are performed on all packets.

For information about configuring actions, see “Configuring Actions in Firewall FilterTerms” on page 208.

For instructions for configuring different kinds of match conditions, see the followingsections:

■ Configuring Numeric Range Match Conditions on page 183

■ Configuring IP Address Match Conditions on page 200

■ Configuring Bit-Field Match Conditions on page 203

■ Configuring Class-Based Match Conditions on page 205

■ Configuring Protocol Match Conditions on page 206

■ Configuring Match Conditions for Small Packets on page 207

Configuring Numeric Range Match Conditions

Numeric range filter conditions match packet fields that can be identified by a numericvalue, such as port and protocol numbers. For numeric range filter match conditions,you specify a keyword that identifies the condition and a single value or a range ofvalues that a field in a packet must match. Table 24 on page 185 describes the numericrange filter match conditions for IPv4 addresses, and Table 25 on page 189 describesthem for IPv6 addresses.

Table 26 on page 192 describes the filter match conditions supported for VPLS traffic.Not all match conditions for VPLS traffic are supported on all routing platforms. A

Configuring Match Conditions in Firewall Filter Terms ■ 183


number of match conditions for VPLS traffic are supported only on MX Series EthernetServices Routers, as noted in the Table 26 on page 192.Table 27 on page 196 describesthe firewall filter match conditions supported for MPLS traffic. No other matchconditions are supported for the family mpls statement. Table 28 on page 196 describesthe firewall match conditions supported for protocol-independent traffic. Firewallfilter match conditions configured for protocol-independent traffic can be appliedboth to loopback (lo0) and logical interfaces. No other match conditions are supportedfor the family any statement. Table 29 on page 197 describes the firewall filter matchconditions supported for Layer 2 circuit cross-connect (CCC) traffic. No other matchconditions are supported for the family ccc statement.

The MX Series router also supports match conditions for Layer 2 bridging traffic.Table 30 on page 197 describes these filter match conditions, which are supportedwith the family bridge statement on MX Series routers only. For more informationabout how to configure Layer 2 services on the MX Series routers, see the JUNOSNetwork Interfaces Configuration Guide, the JUNOS MX Series Ethernet Services RoutersLayer 2 Configuration Guide, and the JUNOS MX Series Ethernet Services RoutersSolutions Guide.

You can specify the numeric range value in one of the following ways:

■ Single number. A match occurs if the value of the field matches the number. Forexample:

source-port 25;

■ Range of numbers. A match occurs if the value of the field falls within thespecified range. The following example matches source ports 1024through 65,535, inclusive:

source-port 1024-65535;

■ Text synonym for a single number. A match occurs if the value of the fieldmatches the number that corresponds to the synonym. For example:

source-port smtp;

To specify multiple values in a single match condition, group the values within squarebrackets following the keyword. For example:

source-port [ smtp ftp-data 25 1024-65535 ];

To exclude a numeric value, append the string -except to the match keyword. Forexample, the following condition would match only if the source port is not 25:

source-port-except 25;

The following condition would match only if the port number is not one of those inthe list:

source-port-except [ smtp ftp-data 666 1024-65535 ];



NOTE: To match only on a source address, destination address, source port, ordestination port, include the appropriate matching condition (source-address,destination-address, source-port, or destination-port, respectively) at the [edit firewallfilter filter-name term term-name from] hierarchy level instead of using the port oraddress matching condition at the same hierarchy level.

Table 24: IPv4 Firewall Filter Match Conditions

DescriptionMatch Condition

Negate a match. For example, destination-port-except number.keyword-except

IPsec authentication header (AH) security parameter index (SPI) value. Match on this specific SPIvalue.

ah-spi spi-value

IPsec AH SPI value. Do not match on this specific SPI value.ah-spi-except spi-value

Destination prefix.destination-addressaddress

Destination media access control (MAC) address of a VPLS packet.destination-mac-addressaddress

TCP or User Datagram Protocol (UDP) destination port field. You cannot specify both the port anddestination-port match conditions in the same term.

Normally, you specify this match in conjunction with the protocol match statement to determinewhich protocol is being used on the port. For more information, see “Configuring Protocol MatchConditions” on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the port numbersare also listed): afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401),dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20),http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761),krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434),mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049),nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius (1812),rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22),sunrpc (111), syslog (514), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513),xdmcp (177).

destination-portnumber

Destination prefixes in the specified list name. Specify the name of a prefix list defined at the [editpolicy-options prefix-list prefix-list-name] hierarchy level.

destination-prefix-listname



Table 24: IPv4 Firewall Filter Match Conditions (continued)


Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) bytein the IP header. The most significant 6 bits of this byte form the DSCP. For more information, seethe JUNOS Class of Service Configuration Guide.

You can specify DSCP in hexadecimal, binary, or decimal form.

In place of the numeric value, you can specify one of the following text synonyms (the field valuesare also listed):

■ RFC 3246, An Expedited Forwarding PHB (Per-Hop Behavior), defines one code point: ef (46).

■ RFC 2597, Assured Forwarding PHB Group, defines 4 classes, with 3 drop precedences in eachclass, for a total of 12 code points:

af11 (10), af12 (12), af13 (14)

af21 (18), af22 (20), af23 (22)

af31 (26), af32 (28), af33 (30)

af41 (34), af42 (36), af43 (38)

dscp number

Ethernet type field of a VPLS packet.ether-type value

Do not match on the Ethernet type field of a VPLS packet.ether-type-except value

IPsec encapsulating security payload (ESP) SPI value. Match on this specific SPI value. You can specifythe ESP SPI value in hexadecimal, binary, or decimal form.

esp-spi spi-value

IPsec ESP SPI value. Do not match on this specific SPI value.esp-spi-except spi-value

First fragment of a fragmented packet. This condition does not match unfragmented packets.first-fragment

Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control.forwarding-class class

Do not match on the forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, ornetwork-control.

forwarding-class-exceptclass

IP fragmentation flags. In place of the numeric field value, you can specify one of the followingkeywords (the field values are also listed): dont-fragment (0x4000), more-fragments (0x2000), orreserved (0x8000).

fragment-flags number

Fragment offset field.fragment-offset number





ICMP code field. This value or keyword provides more specific information than icmp-type. Becausethe value’s meaning depends upon the associated icmp-type, you must specify icmp-type along withicmp-code. For more information, see “Configuring Protocol Match Conditions” on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the field valuesare also listed). The keywords are grouped by the ICMP type with which they are associated:

■ parameter-problem: ip-header-bad (0), required-option-missing (1)

■ redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-host (3),redirect-for-tos-and-net (2)

■ time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)

■ unreachable: communication-prohibited-by-filtering (13), destination-host-prohibited (10),destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6),fragmentation-needed (4), host-precedence-violation (14), host-unreachable (1),host-unreachable-for-TOS (12), network-unreachable (0), network-unreachable-for-TOS (11),port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8),source-route-failed (5)

icmp-code number

ICMP packet type field. Normally, you specify this match in conjunction with the protocol matchstatement to determine which protocol is being used on the port. For more information, see“Configuring Protocol Match Conditions” on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the field valuesare also listed): echo-reply (0), echo-request (8), info-reply (16), info-request (15), mask-request (17),mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10),source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14), or unreachable (3).

icmp-type number

Interface on which the packet was received. You can configure a match condition that matches packetsbased on the interface on which they were received.

interfaceinterface-name

Interface group on which the packet was received. An interface group is a set of one or more logicalinterfaces. For group-number, specify a value from 0 through 255. For information about configuringinterface groups, see “Applying Firewall Filters to Interfaces” on page 216.

interface-groupgroup-number

(MX Series routers and routers with Enhanced IQ2 [IQ2E] PICs only) Interface set on which the packetwas received. An interface set is a set of logical interfaces used to configure hierarchical class ofservice schedulers. For information about configuring an interface set, see the JUNOS Class of ServiceConfiguration Guide and the JUNOS Network Interfaces Configuration Guide.

interface-setinterface-set-name

IP options. In place of the numeric value, you can specify one of the following text synonyms (thefield values are also listed): any, loose-source-route (131), record-route (7), router-alert (148), security(130), stream-id (136),strict-source-route (137), or timestamp (68).

ip-options number

This condition matches if the packet is a trailing fragment; it does not match the first fragment of afragmented packet. To match both first and trailing fragments, you can use two terms.

is-fragment





Packet loss priority (PLP) level. Specify a single level or multiple levels: low, medium-low, medium-high,or high.

Supported on MX Series routers; M120 and M320 routers; and M7i and M10i routers with the EnhancedCFEB (CFEB-E).

On M320 routers, you must enable the tricolor statement at the [edit class-of-service] hierarchy levelto commit a PLP configuration with any of the four levels specified. If the tricolor statement is notreferenced, you can only configure the high and low levels. This applies to all protocol families.

For information about using behavior aggregate (BA) classifiers to set the PLP level of incomingpackets, see the JUNOS Class of Service Configuration Guide.

loss-priority level

Do not match on the packet loss priority level. Specify a single level or multiple levels: low, medium-low,medium-high, or high.

For information about using behavior aggregate (BA) classifiers to set the PLP level of incomingpackets, see the JUNOS Class of Service Configuration Guide.

loss-priority-except level

Length of the received packet, in bytes. The length refers only to the IP packet, including the packetheader, and does not include any Layer 2 encapsulation overhead.

packet-length bytes

TCP or UDP source or destination port field. You cannot specify both the port match and either thedestination-port or source-port match conditions in the same term.


In place of the numeric value, you can specify one of the text synonyms listed under destination-port.

port number

IP precedence field. In place of the numeric field value, you can specify one of the following textsynonyms (the field values are also listed): critical-ecp (0xa0), flash (0x60), flash-override (0x80),immediate (0x40), internet-control (0xc0), net-control (0xe0), priority (0x20), or routine (0x00). You canspecify precedence in hexadecimal, binary, or decimal form.

precedenceip-precedence-field

Destination or source prefixes in the specified list name. Specify the name of a prefix list defined atthe [edit policy-options prefix-list prefix-list-name] hierarchy level.

prefix-list name

IP protocol field. In place of the numeric value, you can specify one of the following text synonyms(the field values are also listed): ah (51), egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4), ipv6 (41),ospf (89), pim (103), rsvp (46), tcp (6), or udp (17).

protocol number

TCP or UDP source port field. You cannot specify the port and source-port match conditions in thesame term.


In place of the numeric field, you can specify one of the text synonyms listed under destination-port.

source-port number

Source prefixes in the specified list name. Specify the name of a prefix list defined at the [editpolicy-options prefix-list prefix-list-name] hierarchy level.

source-prefix-list name





TCP packets other than the first packet of a connection. This is a synonym for " (ack | rst)".

This condition does not implicitly check that the protocol is TCP. To check this, specify the protocoltcp match condition.

tcp-established

TCP flags.

Normally, you specify this match in conjunction with the protocol match statement to determinewhich protocol is being used on the port. For more details, see “Configuring Protocol Match Conditions”on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the field valuesare also listed): ack (0x10), fin (0x01), push (0x08), rst (0x04), syn (0x02), or urgent (0x20).

tcp-flags number

First TCP packet of a connection. This is a synonym for "(syn & !ack)".


tcp-initial

IPv4 TTL number. Specify a TTL value or a range of TTL values. For number, you can specify one ormore values from 0 through 255. This match condition is supported only on M120, M320, MX Series,and T Series routers.

ttl number

Do not match on the IPv4 TTL number. Specify a TTL value or a range of values. For number, you canspecify one or more values from 0 through 255. This match condition is supported only on M120,M320, MX Series, and T Series routers.

ttl-except number

Virtual local area network (VLAN) Ethernet type field of a VPLS packet.vlan-ether-type value

Do not match on the VLAN Ethernet type field of a VPLS packet.vlan-ether-type-exceptvalue

Table 25: IPv6 Firewall Filter Match Conditions


128-bit address that supports the standard syntax for IPv6 addresses. For more information, see theJUNOS Routing Protocols Configuration Guide.

address address

128-bit address that is the final destination node address for the packet. The filter description syntaxsupports the text representations for IPv6 addresses as described in RFC 2373, IP Version 6 AddressingArchitecture. For more information about IPv6 address syntax, see the JUNOS Routing ProtocolsConfiguration Guide.

destination-addressaddress





TCP or UDP destination port field. You cannot specify both the port and destination-port match conditionsin the same term.

Normally, you specify this match in conjunction with the next-header match statement to determinewhich protocol is being used on the port. For more information, see “Configuring Protocol MatchConditions” on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the port numbersare also listed): afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401),dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20),http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761),krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), mobilip-mn (435),msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518),ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius (1812), rip (520), rkinit (2108),smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514),tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), xdmcp (177), zephyr-clt (2103),or zephyr-hm (2104).


Destination prefixes in the specified list name. Specify the name of a prefix list defined at the [editpolicy-options prefix-list prefix-list-name] hierarchy level.

destination-prefix-listname

Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, and network-control.forwarding-class class

ICMP code field. This value or keyword provides more specific information than icmp-type. Becausethe value’s meaning depends upon the associated icmp-type, you must specify icmp-type along withicmp-code. For more information, see “Configuring Protocol Match Conditions” on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the field valuesare also listed). The keywords are grouped by the ICMP type with which they are associated:

■ parameter-problem: ip6-header-bad (0), unrecognized-next-header (1), unrecognized-option (2)


■ destination-unreachable: no-route-to-destination (0), administratively-prohibited (1),address-unreachable (3), port-unreachable (4)

icmp-code number

ICMP packet type field. Normally, you specify this match in conjunction with the protocol matchstatement to determine which protocol is being used on the port. For more information, see“Configuring Protocol Match Conditions” on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the field valuesare also listed): echo-reply (129), echo-request (128), membership-query (130), membership-report (131),membership-termination (132), neighbor-advertisement (136), neighbor-solicit (135), node-information-reply(140), node-information-request (139), packet-too-big (2), parameter-problem (4), redirect (137),router-advertisement (134), router-renumbering (138), router-solicit (133), time-exceeded (3), ordestination-unreachable (1).

icmp-type number



Interface group on which the packet was received. An interface group is a set of one or more logicalinterfaces. For information about configuring interface groups, see “Applying Firewall Filters toInterfaces” on page 216.






(MX Series routers and routers with Enhanced IQ2 (IQ2E) PICs only) Interface set on which the packetwas received. An interface set is a set of logical interfaces used to configure hierarchical class of serviceschedulers. For information about configuring an interface set, see the JUNOS Class of ServiceConfiguration Guide and the JUNOS Network Interfaces Configuration Guide.




On M320 routers, you must enable the tricolor statement at the [edit class-of-service] hierarchy levelto commit a PLP configuration with any of the four levels specified. If the tricolor statement is notreferenced, you can only configure the high and low levels. This applies to all protocol families.

For information about using behavior aggregate (BA) classifiers to set the PLP level of incoming packets,see the JUNOS Class of Service Configuration Guide.

loss-priority level



loss-priority-except level

8-bit IP protocol field that identifies the type of header immediately following the IPv6 header. Inplace of the numeric value, you can specify one of the following text synonyms (the field values arealso listed): ah (51), dstops (60),egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmpv6(1), igmp (2), ipip (4), ipv6 (41), no-next-header (59), ospf (89), pim (103), routing (43), rsvp (46), sctp (132),tcp (6), udp (17), or vrrp (112).

next-header bytes


packet-length bytes

TCP or UDP source or destination port field. You cannot specify both the port match and either thedestination-port or source-port match conditions in the same term.

Typically, you specify this match in conjunction with the protocol match statement to determine whichprotocol is being used on the port. For more information, see “Configuring Protocol Match Conditions”on page 206.

In place of the numeric value, you can specify one of the text synonyms listed under destination-port.

port number

Source or destination prefixes in the specified list name. Specify the name of a list defined at the [editrouting-options prefix-list prefix-list-name] hierarchy level.

prefix-list name

Address of the source node sending the packet; 128 bits in length. The filter description syntax supportsthe text representations for IPv6 addresses as described in RFC 2373. For more information aboutIPv6 address syntax, see the JUNOS Routing Protocols Configuration Guide.

source-addressaddress






Normally, you specify this match in conjunction with the protocol match statement to determine whichprotocol is being used on the port. For more information, see “Configuring Protocol Match Conditions”on page 206.

In place of the numeric field, you can specify one of the text synonyms listed under destination-port.

source-port number

Source prefixes in the specified prefix list. Specify a prefix list name defined at the [edit policy-optionsprefix-list prefix-list-name] hierarchy level.

source-prefix-list name



tcp-established

One or more of the following TCP flags:

■ bit-name: fin, syn, rst, push, ack, urgent

You can string together multiple flags using logical operators.

■ numerical value: 0x01 through 0x20

■ text synonym: tcp-established, tcp-initial

Configuring the tcp-flags match condition requires that you configure the next-header tcp matchcondition.

tcp-flags flags

Initial packet of a TCP connection. Configuring the tcp-initial match condition also requires you toconfigure the next-header match condition.

tcp-initial

8-bit field that specifies the class-of-service (CoS) priority of the packet. The traffic-class field is usedto specify a DiffServ code point (DSCP) value. The numerical value cannot be greater than 0x3f.

This field was previously used as the ToS field in IPv4. However, the semantics of this field (forexample, DSCP) are identical to IPv4.

traffic-class number

Table 26: VPLS Firewall Filter Match Conditions


Destination media access control (MAC) address of a VPLS packet.destinationmac-address address

(MX Series routers only) TCP or UDP destination port field. You cannot specify both the port anddestination-port match conditions in the same term.


(MX Series routers only) Do not match on the TCP or UDP destination port field. You cannot specifyboth the port and destination-port match conditions in the same term.

destination-port-exceptnumber



Table 26: VPLS Firewall Filter Match Conditions (continued)


(MX Series routers only) Differentiated Services code point (DSCP). The DiffServ protocol uses thetype-of-service (ToS) byte in the IP header. The most significant 6 bits of this byte form the DSCP. Formore information, see the JUNOS Class of Service Configuration Guide.

You can specify DSCP in either hexadecimal, binary, or decimal form.

In place of the numeric value, you can specify one of the following text synonyms (the field values arealso listed):

■ RFC 3246, An Expedited Forwarding PHB (Per-Hop Behavior), defines one code point: ef (46).

■ RFC 2597, Assured Forwarding PHB Group, defines 4 classes, with 3 drop precedences in eachclass, for a total of 12 code points:

af11 (10), af12 (12), af13 (14),

af21 (18), af22 (20), af23 (22),

af31 (26), af32 (28), af33 (30),

af41 (34), af42 (36), af43 (38)

dscp number

(MX Series routers only) Do not match on the DSCP.dscp-except number

Ethernet type field of a VPLS packet.ether-type number

Do not match on the Ethernet type field of a VPLS packet.ether-type-exceptnumber




(MX Series routers only) ICMP code field. This value or keyword provides more specific informationthan icmp-type. Because the value’s meaning depends upon the associated icmp-type, you must specifyicmp-type along with icmp-code. For more information, see “Configuring Protocol Match Conditions”on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the field values arealso listed). The keywords are grouped by the ICMP type with which they are associated:

■ parameter-problem: ip-header-bad (0), required-option-missing (1)

■ redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-host (3),redirect-for-tos-and-net (2)


■ unreachable: communication-prohibited-by-filtering (13), destination-host-prohibited (10),destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6),fragmentation-needed (4), host-precedence-violation (14), host-unreachable (1),host-unreachable-for-TOS (12), network-unreachable (0), network-unreachable-for-TOS (11),port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8),source-route-failed (5)

icmp-code number

(MX Series routers only) Do not match on the ICMP code field.icmp-code-exceptnumber





(MX Series routers only) ICMP packet type field. Normally, you specify this match in conjunction withthe protocol match statement to determine which protocol is being used on the port. For moreinformation, see “Configuring Protocol Match Conditions” on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the field values arealso listed): echo-reply (0), echo-request (8), info-reply (16), info-request (15), mask-request (17),mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10),source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14), or unreachable (3).

icmp-type number

(MX Series routers only) Do not match on the ICMP packet type field.icmp-type-exceptnumber

Interface group on which the packet was received. An interface group is a set of one or more logicalinterfaces. For information about configuring interface groups, see “Applying Firewall Filters toInterfaces” on page 216.

interface-groupgroup-name

Do not match on the interface group.interface-group-exceptgroup-name

(MX Series routers only) 32-bit address that supports the standard syntax for IPv4 addresses.ip-address address

(MX Series routers only) 32-bit address that is the final destination node address for the packet.ip-destination-addressaddress

(MX Series routers only) IP precedence field. In place of the numeric field value, you can specify oneof the following text synonyms (the field values are also listed): critical-ecp (0xa0), flash (0x60),flash-override (0x80), immediate (0x40), internet-control (0xc0), net-control (0xe0), priority (0x20), orroutine (0x00).

ip-precedenceip-precedece-field

(MX Series routers only) Do not match on the IP precedence field.ip-precedence-exceptip-precedence-field

(MX Series routers only) IP protocol fieldip-protocol number

(MX Series routers only) Do not match on the IP protocol field.ip-protocol-exceptnumber

(MX Series routers only) IP address of the source node sending the packet.ip-source-addressaddress

(MX Series routers only) IEEE 802.1p learned VLAN priority field. Specify a single value or multiplevalues from 0 through 7.

learn-vlan-1p-prioritynumber

(MX Series routers only) Do not match on the IEEE 802.1p learned VLAN priority field. Specify a singlevalue or multiple values from 0 through 7.

learn-vlan-1p-priority-exceptnumber

(MX Series routers only) VLAN identifier used for MAC learning.learn-vlan-id number

(MX Series routers only) Do not match on the VLAN identifier used for MAC learning.learn-vlan-id-exceptnumber







On M320 routers, you must enable the tricolor statement at the [edit class-of-service] hierarchy level tocommit a PLP configuration with any of the four levels specified. If the tricolor statement is notreferenced, you can only configure the high and low levels. This applies to all protocol families.


loss-priority level



loss-priority-exceptlevel

(MX Series routers only) TCP or UDP source or destination port. You cannot specify both the port matchcondition and either the destination-port or source-port match condition in the same term.

port number

(MX Series routers only) Do not match on the TCP or UDP source or destination port. You cannotspecify both the port match condition and either the destination-port or source-port match condition inthe same term.

port-except number

Source MAC address of a VPLS packet.source-mac-addressaddress

(MX Series routers only) TCP or UDP source port field. You cannot specify the port and source-portmatch conditions in the same term.

source-port number

(MX Series routers only) Do not match on the TCP or UDP source port field. You cannot specify theport and source-port match conditions in the same term.

source-port-exceptnumber

(MX Series routers only) One or more of the following TCP flags:

■ Bit-name: fin, syn, rst, push, ack, urgent

■ Numerical value: 0x01 through 0x20

■ Text synonym: tcp-established, tcp-initial


Configuring the tcp-flags match condition requires that you configure the next-header-tcp match condition.

tcp-flags flags

(MX Series routers only) Traffic type. Specify broadcast, multicast, unknown-unicast, or known-unicast.traffic-type type-name

(MX Series routers only) Do not match on the traffic type. Specify broadcast, multicast, unknown-unicast,or known-unicast.

traffic-type-excepttype-name

IEEE 802.1p user priority field. Specify a single value or multiple values from 0 through 7.user-vlan-1p-prioritynumber





Do not match on the IEEE 802.1p user priority field. Specify a single value or multiple values from 0through 7.

user-vlan-1p-priority-exceptnumber

(MX Series routers only) First VLAN identifier that is part of the payload.user-vlan-id number

(MX Series routers only) Do not match on the first VLAN identifier that is part of the payload.user-vlan-id-exceptnumber

VLAN Ethernet type field of a VPLS packet.vlan-ether-type value

Do not match on the VLAN Ethernet type field of a VPLS packet.vlan-ether-type-exceptvalue

Table 27: MPLS Firewall Filter Match Conditions


Experimental (EXP) bit number or range of bit numbers in the MPLS header. For number, you canspecify one or more values from 0 through 7 in decimal, binary, or hexadecimal format.

expnumber

Do not match on the EXP bit number or range of bit numbers in the MPLS header. For number, youcan specify one or more values from 0 through 7.

exp-except number

Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control.forwarding-classclass







Table 28: Protocol-Independent Firewall Filter Match Conditions











Table 28: Protocol-Independent Firewall Filter Match Conditions (continued)



packet-length bytes

Do not match on the received packet length, in bytes.packet-length-exceptbytes

Table 29: Layer 2 Circuit Cross-Connect Firewall Filter Match Conditions


Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control.forwarding-classclass



Interface group on which the packet was received. An interface group is a set of one or more logicalinterfaces. For group-number, specify a value from 0 through 255. For information about configurationinterface groups, see “Applying Firewall Filters to Interfaces” on page 216.


Do not match on the interface group in which the packet was received. For group-number, specify avalue from 0 through 255.

inteface-group-exceptnumber



On M320 routers, you must enable the tricolor statement at the [edit class-of-service] hierarchy level tocommit a PLP configuration with any of the four levels specified. If the tricolor statement is notreferenced, you can only configure the high and low levels. This applies to all protocol families.


loss-priority level




Table 30: Layer 2 Bridging Firewall Filter Match Conditions (MX Series Ethernet Services Routers Only)


Destination media access control (MAC) address of a Layer 2 packet in a bridging environment.destination-mac-addressaddress

TCP or UDP destination port field. You cannot specify both the port and destination-port matchconditions in the same term.




Table 30: Layer 2 Bridging Firewall Filter Match Conditions (MX Series Ethernet Services RoutersOnly) (continued)


Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) bytein the IP header. The most significant 6 bits of this byte form the DSCP. For more information, seethe JUNOS Class of Service Configuration Guide.

You can specify DSCP in hexadecimal, binary, or decimal form.

dscp number

Ethernet type field of a Layer 2 packet in a bridging environment.ether-type value

Do not match on the Ethernet type field of a Layer 2 packet.ether-type-except value

Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control.forwarding class class

Ethernet type field of a Layer 2 packet environment. Specify assured-forwarding, best-effort,expedited-forwarding, or network-control.


ICMP code field. The value or keyword provides more specific information than icmp-type. Becausethe value’s meaning depends on the associated icmp-type, you must specify icmp-type along withicmp-code.

icmp-code number

ICMP packet type field. Normally, you specify this match in conjunction with the protocol matchstatement to determine which protocol is being used on the port.

icmp-type number

Interface group on which the packet was received. An interface group is a set of one or more logicalinterfaces. For group-number, specify a value from 0 through 255.


Do not match on the interface group on which the packet was received.interface-group-exceptnumber

32-bit address that supports the standard syntax for IPv4 addresses.ip-address address

32-bit address that is the final destination node address for the packet.ip-destination-addressaddress

IP precedence field. In place of the numeric field value, you can specify one of the following textsynonyms (the field values are also listed): critical-ecp (0xa0), flash (0x60), flash-override (0x80),immediate (0x40), internet-control (0xc0), net-control (0xe0), priority (0x20), or routine (0x00).

ip-precedenceip-precedence-field

Do not match on the IP precedence field.ip-precedence-except

IP protocol field.ip-protocol number

IP address of the source node sending the packet.ip-source-addressaddress

(Supported with bridging, VPLS, and Layer 2 circuit cross-connect [CCC] traffic only) IEEE 802.1plearned VLAN priority field. Specify a single value or multiple values from 0 through 7.

learn-vlan-1p-priorityvalue

(Supported with bridging, VPLS, and Layer 2 circuit cross-connect [CCC] traffic only) Do not matchon the IEEE 802.1p learned VLAN priority field. Specify a single value or multiple values from 0 through7.

learn-vlan-1p-priority-exceptvalue

VLAN identifier used for MAC learning.learn-vlan-id number





Do not match on the VLAN identifier used for MAC learning.learn-vlan-id-exceptnumber



loss-priority level




TCP or UDP source or destination port. You cannot specify both the port match condition and eitherthe destination-port or source-port match conditions in the same term.

port number

Source MAC address of a Layer 2 packet.source-mac-addressaddress


source-port number

One or more of the following TCP flags:

■ Bit-name: fin, syn, rst, push, ack, urgent

■ Numerical value: 0x01 through 0x20

■ Text synonym: tcp-established, tcp-initial


Configuring the tcp-flags match condition requires that you configure the next-header-tcp matchcondition.

tcp-flags flags

Traffic type. Specify broadcast, multicast, unknown-unicast, or known-unicast.traffic-type type

Do not match on the traffic type.traffic-type-except type

(Supported with bridging, VPLS, and Layer 2 VPN traffic only) IEEE 802.1p user priority field. Specifya single value or multiple values from 0 through 7.

user-vlan-1p-priorityvalue

(Supported with bridging, VPLS, and Layer 2 VPN traffic only) Do not match on the IEEE 802.1p userpriority field. Specify a single value or multiple values from 0 through 7.

user-vlan-1p-priority-exceptvalue

First VLAN identifier that is part of the payload.user-vlan-id number

Do not match on the first VLAN identifier that is part of the payload.user-vlan-id-exceptnumber

VLAN Ethernet type field of a Layer 2 bridging or VPLS packet.vlan-ether-type value





Do not match on the VLAN Ethernet type field of a Layer 2 bridging or VPLS packet.vlan-ether-type-exceptvalue

Configuring IP Address Match Conditions

Address filter conditions match prefix values in a packet, such as IP source anddestination prefixes. For address filter match conditions, you specify a keyword thatidentifies the field and one or more prefixes of that type that a packet must match.Table 31 on page 201 describes the address filter match conditions.

You can specify the address in one of the following ways:

■ Single prefix. A match occurs if the value of the field matches the prefix. Forexample:

[edit firewall family family-name filter filter-name term term-name from]destination-address 10.0.0.0/8;

■ Multiple prefixes. A match occurs if any one of the prefixes in the list matchesthe packet. For example:

[edit firewall family family-name filter filter-name term term-name from]destination-address {

10.0.0.0/8;192.168.0.0/32;

}

The order in which you list prefixes in the list is not significant. They are all evaluatedto determine whether a match occurs. If prefixes overlap, longest-match rules areused to determine whether a match occurs. Each list of prefixes contains an implicit0/0 except statement, which means that any prefix that does not match any prefixin the list is explicitly considered not to match.

To specify the address prefix, use the notation prefix/prefix-length. If you omitprefix-length, it defaults to /32. For example:

[edit firewall family family-name filter filter-name term term-name from]user@host# set destination-address 10[edit firewall family family-name filter filter-name term term-name from]user@host# showdestination-address {

10.0.0.0/32;}

To exclude a prefix, specify the string except after the prefix. In the following example,any addresses that fall under 192.168.10.0/8 match, except for addresses that fallunder 192.168.0.0/16. All other addresses implicitly do not match this condition.




192.168.0.0/16 except;192.168.10.0/8;

}

To match all destinations except one, in this example 10.1.1.0/24, configure thematch conditions as follows:


0.0.0.0/0;10.1.1.0/24 except;

}

Because the prefixes are order-independent and use longest-match rules, longerprefixes subsume shorter ones as long as they are the same type (whether you specifyexcept or not). This is because anything that would match the longer prefix wouldalso match the shorter one. In the following example:

■ 172.16.1.2 matches the 172.16.0.0/10 prefix, and thus the action in the thenstatement is taken.

■ 172.16.2.2 matches the 172.16.2.0/16 prefix. Because this prefix is negated(that is, marked as except), an explicit mismatch occurs. The next term in thefilter is evaluated, if there is one. If there are no more terms, the packet isdiscarded.

■ 10.1.2.3 does not match any of the prefixes included in the source-addresscondition. Instead, it matches the implicit 0.0.0.0/0 except at the end of the list,and is considered to be a mismatch.

■ The 172.16.3.0/16 statement is ignored because it falls under the address172.16.0.0/10—both are the same type.

■ The 10.2.2.2 except statement is ignored because it is subsumed by the implicit0.0.0.0/0 except statement at the end of the list.

[edit firewall family family-name filter filter-name term term-name from]source-address {

172.16.0.0/10;172.16.2.0/16 except;192.168.1.0;192.168.1.192/26 except;192.168.1.254;172.16.3.0/16; # ignored0.0.0.0/0 except; # ignored

}

Table 31: Address Firewall Filter Match Conditions


IP source or destination address field. You cannot specify both the address and the destination-addressor source-address match conditions in the same term.

address prefix



Table 31: Address Firewall Filter Match Conditions (continued)


IP destination address field. You cannot specify the destination-address and address match conditionsin the same term.

destination-addressprefix

IP destination prefix list field. You cannot specify the destination-prefix-list and prefix-list match conditionsin the same term.

destination-prefix-listprefix-list

IP source or destination prefix list field. You cannot specify both the prefix-list and thedestination-prefix-list or source-prefix-list match conditions in the same term.

prefix-list prefix-list

IP source address field. You cannot specify the source-address and address match conditions in thesame rule.

source-address prefix

IP source prefix list field. You cannot specify the source-prefix-list and prefix-list match conditions inthe same term.

source-prefix-listprefix-list

You can also define a list of IP address prefixes under a prefix-list alias for frequentreference. You make this definition at the [edit policy-options] hierarchy level:

[edit policy-options]policy-options {prefix-list prefix-list {

address;address;address;

}

Once you have defined a prefix list, you can use it when defining firewall filters:

[edit firewall family family-name filter filter-name term term-name]from {

source-prefix-list {prefix-list1;prefix-list2;

}destination-prefix-list {

prefix-list1;}

}

You can specify noncontiguous address prefixes in a filter term for firewall filters.Noncontiguous address prefixes are prefixes that are not adjacent or neighboring toone another. For example, in the following example, the following prefixes arenoncontiguous: 0.0.0.10/0.0.0.255, 0.10.0.10/0.255.0.255, and0.12.10.9/0.255.255.255:

[edit firewall family inet filter filter-name]term term-name {

address 0.0.0.10/0.0.0.255;destination-address 0.10.0.10/0.255.0.255;source-address 0.12.10.9/0.255.255.255 except;

}



NOTE: Noncontiguous address prefixes are valid only for IPv4 filters. IPv6 filters donot support noncontiguous address prefixes.

You can also specify a netmask value rather than a prefix length, for example:

[edit firewall family inet filter filter-name]term term-name {

address 10.0.0.10/255.0.0.255;}

The prefix notation shown matches any address with a first and last octet of 10. Theaddress and netmask are separated by a forward slash (/). The second and thirdbytes of the prefix can be any value from 0 through 255.

NOTE: When a firewall filter term includes the from address address match conditionand a subsequent term includes the from source-address address match condition forthe same address, packets may be processed by the latter term before they areevaluated by any intervening terms. Therefore, packets that should be rejected bythe intervening terms may be accepted, or packets that should be accepted may berejected.

To prevent this from occurring, we recommend you do the following. For everyfirewall filter term that contains the from address address match condition, replacethat term with two separate terms: one that contains the from source-address addressmatch condition, and another that contains the from destination-address addressmatch condition.

For more information about prefixes, see the JUNOS Routing Protocols ConfigurationGuide.

Configuring Bit-Field Match Conditions

Bit-field filter conditions match packet fields if particular bits in those fields are orare not set. You can match the IP options, TCP flags, and IP fragmentation fields.For bit-field filter match conditions, you specify a keyword that identifies the fieldand tests to determine that the option is present in the field. Table 32 on page 204describes the bit-field match conditions.

NOTE: The JUNOS Software does not automatically check the first fragment bit whenmatching TCP flags. To include the first fragment bit, include the fragment-offsetmatch condition described in Table 24 on page 185.

To specify the bit-field value to match, enclose the value in quotation marks (“ ”).For example, a match occurs if the RST bit in the TCP flags field is set:

tcp-flags “rst”;



Generally, you specify the bits being tested using keywords. Bit-field match keywordsalways map to a single bit value. You also can specify bit fields as hexadecimal ordecimal numbers.

To negate a match, precede the value with an exclamation point. For example, amatch occurs only if the RST bit in the TCP flags field is not set:

tcp-flags “!rst”;

To match multiple bit-field values, use the logical operators list in Table 33 on page205. The operators are listed in order, from highest precedence to lowest precedence.Operations are left-associative.

As an example of a logical AND operation, in the following, a match occurs if thepacket is the initial packet on a TCP session:

tcp-flags “syn & !ack”;

As an example of a logical OR operation, in the following, a match occurs if thepacket is not the initial packet on a TCP session:

tcp-flags "!syn | ack";

As an example of grouping, in the following, a match occurs for any packet that iseither a TCP reset or is not the initial packet in the session:

tcp-flags “!(syn & !ack) | rst”;

When you specify a numeric value that has more than one bit set, the value is treatedas a logical AND of the set bits. For example, the following two values are the sameand a match occurs only if either bit 0x01 or 0x02 is not set:

tcp-flags “!0x3”;tcp-flags “!(0x01 & 0x02)”;

You can use text synonyms to specify some common bit-field matches. You specifythese matches as a single keyword. For example:

tcp-established;

Table 32: Bit-Field Firewall Filter Match Conditions


Conditions with Variables

IP fragmentation flags. In place of the numeric field value, you can specify one of the followingkeywords (the field values are also listed): dont-fragment (0x4000), more-fragments (0x2000), orreserved (0x8000).

fragment-flags number

IP options. In place of the numeric value, you can specify one of the following text synonyms (thefield values are also listed): any, loose-source-route (131), record-route (7), router-alert (148), security(130), stream-id (136),strict-source-route (137), or timestamp (68).

ip-options number



Table 32: Bit-Field Firewall Filter Match Conditions (continued)


TCP flags.

Normally, you specify this match in conjunction with the protocol match statement to determinewhich protocol is being used on the port. For more details, see “Configuring Protocol Match Conditions”on page 206.

In place of the numeric value, you can specify one of the following text synonyms (the field valuesare also listed): ack (0x10), fin (0x01), push (0x08), rst (0x04), syn (0x02), or urgent (0x20).

tcp-flags number

Text Synonyms

First fragment of a fragmented packet. This condition does not match unfragmented packets.first-fragment

This condition matches if the packet is a trailing fragment; it does not match the first fragment of afragmented packet. To match both first and trailing fragments, you can use two terms.

is-fragment



tcp-established

First TCP packet of a connection. This is a synonym for "(syn & !ack)".


tcp-initial

Table 33: Bit-Field Logical Operators

DescriptionLogical Operator

Grouping(...)

Negation!

Logical AND& or +

Logical OR| or ,

Configuring Class-Based Match Conditions

Class-based filter conditions match packet fields based on source class or destinationclass. A source class is a set of source prefixes grouped together and given a classname. A destination class is a set of destination prefixes grouped together and givena class name.

You can specify the source class in the following way:

[edit firewall filter inet filter-name term term-name]from {

source-class class-name;



}

You can specify the destination class in the following way:

[edit firewall filter inet filter-name term term-name]from {

destination-class class-name;}

You can specify a source class or destination class for an output firewall filter. Althoughyou can specify a source class and destination class for an input firewall filter, thecounters are incremented only if the firewall filter is applied on the output interface.

The class-based filter match condition works only for output filters because the sourceclass usage (SCU) and destination class usage (DCU) are determined after routelookup.

NOTE: For transit packets exiting the router through the tunnel, source class usageand destination class usage are not supported on the interfaces you configure as theoutput interface for tunnel traffic.

NOTE: Class-based filter match conditions are not supported on the J Series ServicesRouters.

NOTE: Class-based filter match conditions are supported for inet and inet6 addressfamilies on the M Series routers.

Configuring Protocol Match Conditions

If you specify a port match condition or a match of the ICMP type or TCP flags field,there is no implied protocol match. If you use one of the following match conditionsin a term, you should explicitly specify the protocol in the same term:

■ destination-port—For IPv4, specify the match protocol tcp or protocol udp in thesame term. For IPv6, specify the match next-header tcp or next-header udp in thesame term.

■ icmp-code—Specify the match protocol icmp in the same term.

■ icmp-type—Specify the match protocol icmp in the same term.

■ port—Specify the match protocol tcp or protocol udp in the same term.

■ source-port—Specify the match protocol tcp or protocol udp in the same term.

■ tcp-flags—Specify the match protocol tcp in the same term.

When examining match conditions, the policy framework software tests only thespecified field itself. The software does not also test the IP header to determine thatthe packet is indeed an IP packet.



If you do not explicitly specify the protocol, when using the fields listed previously,design your filters carefully to ensure that they are performing the expected matches.If you specify a match of destination-port ssh, the policy framework softwaredeterministically matches any packets that have a value of 22 in the 2-byte field thatis 2 bytes beyond the end of the IP header, without ever checking the IP protocolfield.

Example: Ignoring Packet Protocol

The first term matches all packets except for TCP and UDP packets, so only TCP andUDP packets are evaluated by the third term (term test-a-port):

[edit]firewall {

family inet {filter test-filter {

term all-but-tcp-and-udp {from {

protocol-except [tcp udp];}then accept;

}term test-an-address {

from {address 192.168/16;

}then reject;

}term test-a-port {

from {destination-port [ssh dns];

}then accept;

}term dump-anything-else {

then reject;}

}}

}

Configuring Match Conditions for Small Packets

By default, firewall filtering is not supported for packets that are less than 5 bytes inlength. To filter packets less than 5 bytes in length, include an additional term tomatch the packet size.

For example, consider the following filter term:

term 1 {from {

fragment-offset-except 0;}then {



reject;}

}

To consider packets of 1 through 4 bytes in length, include an additional term thatmatches the packet size:

term 2 {from {

packet-length [ 21 - 24 ];}then {

reject;}

}

Configuring Actions in Firewall Filter Terms

In the then statement in a firewall filter term, you specify the actions to perform onpackets whose characteristics match the conditions specified in the preceding fromstatement. To configure a filter action, include the then statement at the [edit firewallfamily family-name filter filter-name term term-name] hierarchy level:

[edit firewall family family-name filter filter-name term term-name]then {


}

For IPv4 traffic, configure the filter action at the [edit firewall family inet filter filter-nameterm term-name] hierarchy level. For IPv6 traffic, configure the filter action at the [editfirewall family inet6 filter filter-name term term-name] hierarchy level. For MPLS traffic,configure the filter action at the [edit firewall family mpls filter filter-name termterm-name] hierarchy level. For Layer 2 VPN traffic, configure the filter action at the[edit firewall family ccc filter filter-name term term-name] hierarchy level.

For Layer 2 traffic in a bridging environment, configure the filter action at the [editfirewall family bridge filter filter-name term term-name] hierarchy level. The bridge optionis supported only on MX Series routers.

NOTE: We strongly recommend that you always explicitly configure an action in thethen statement. If you do not, or if you omit the then statement entirely, packets thatmatch the conditions in the from statement are accepted.

You can specify one of the following filter actions:

■ accept—Accept the packet, which is then sent to its destination.

■ discard—Discard the packet, which is not processed further.

■ next term—Evaluate the next term in the firewall filter.

208 ■ Configuring Actions in Firewall Filter Terms


■ reject—Reject the packet and send a rejection message. Rejected packets canbe logged or sampled.

■ routing-instance—Accept the packet, which is then routed by the specified routinginstance. For more information, see “Configuring Filter-Based Forwarding” onpage 245.

■ topology—Accept the packet, which is then installed in the routing table of thespecified topology. For more information, see the “Configuring MultitopologyRouting” chapter in the JUNOS Routing Protocols Configuration Guide.

In the filter action statement, you can also specify one or more of the followingaction modifiers:

■ count—Add the packet to a count total.

■ forwarding-class—Specify the packet forwarding class name.

■ ipsec-sa sa-name—Specify an IP Security (IPsec) security association (SA) for thepacket. This is used with the source-address and destination-address matchconditions.

■ log—Store the packet header information in a buffer within the Packet ForwardingEngine.

■ loss-priority—Set the packet loss priority (PLP) to low, medium-low, medium-high,or high.

Supported on MX Series routers; M120 and M320 routers; and M7i and M10irouters with the Enhanced CFEB (CFEB-E).

NOTE: On M320 routers, you must enable the tricolor statement at the [editclass-of-service] hierarchy level to commit the PLP configuration with any of the fourlevels. If the tricolor statement is not referenced, you can only configure the high andlow levels. This applies to all protocol families.

■ policer—Apply rate-limiting procedures to the traffic. For more information, see“Policer Configuration” on page 255.

■ port-mirror—Perform port mirroring on the specified traffic.

■ sample—Sample the packet traffic. Apply this option only if you have enabledtraffic sampling. For more information, see “Introduction to Traffic SamplingConfiguration” on page 307.

■ syslog—Store the packet header information on the Routing Engine and log itto the system log.

NOTE: The firewall filter syslog action stops logging at a high traffic rate to protectthe Routing Engine from an excessive flow of messages.

Configuring Actions in Firewall Filter Terms ■ 209


NOTE: You cannot configure both the loss-priority and three-color-policer actionmodifiers for the same firewall filter term.

You can specify only one filter action statement (or omit it), but you can specify anycombination of action modifiers. For the action or action modifier to take effect, allconditions in the from statement must match. If you specify log as one of the actionsin a term, this constitutes a termination action; whether any additional terms in thefilter are processed depends on the traffic through the filter.

The action modifier operations carry a default accept action. For example, if youspecify an action modifier and do not specify an action, the specified action modifieris implemented and the packet is accepted.

Policing uses a specific type of action, known as a policer action. For moreinformation, see “Policer Configuration” on page 255.

For more information about forwarding classes and loss priority, see the JUNOS Classof Service Configuration Guide.

Table 34 on page 210 shows the complete list of filter actions and action modifiers.

Table 34: Firewall Filter Actions and Action Modifiers

DescriptionAction orAction Modifier

Actions

Accept a packet.accept

Count the packet in the specified counter.countcounter-name

Set the IPv4 or the IPv6 Differentiated Services code point (DSCP) bit to 0.dscp

Discard a packet silently, without sending an Internet Control Message Protocol (ICMP) message. Discardedpackets are available for logging and sampling.

discard

Classify the packet into one of the following forwarding classes: as, assured-forwarding, best-effort,expedited-forwarding, or network-control.

forwarding-classclass

Use the specified IPsec security association.ipsec-sa ipsec-sa

Use the specified load-balancing group.load-balancegroup-name

Use the specified logical system. This action is supported for both IPv4 and IPv6 firewall filters.logical-systemlogical-system-name



Table 34: Firewall Filter Actions and Action Modifiers (continued)


Set the loss priority level for packets.


On M320 routers, you must enable the tricolor statement at the [edit class-of-service] hierarchy level tocommit a PLP configuration with any of the four levels specified. If the tricolor statement is not referenced,you can only configure the high and low levels. This applies to all protocol families.

loss-priority (high |medium-high |medium-low| low)

Indicate that the upper or lower bound of a policer has been met and starvation of queues is possible.The packets are marked as out of the profile of the policer. This action is supported on the J Series ServicesRouter only as part of strict priority queuing. Out-of-profile packets are queued only if the port is notcongested.

out-of-profile

Continue to the next term for evaluation.next term

Use the specified next-hop group.next-hop-groupgroup-name

Rate-limit packets based on the specified policer.policerpolicer-name

Port mirror packets based on the specified family. Supported on M120 routers, M320 routers configuredwith Enhanced III FPCs, and MX Series routers only.

port-mirror

Count or police packets based on the specified action name.prefix-action name

Discard a packet, sending an ICMPv4 or an ICMPv6 destination unreachable message. Rejected packetscan be logged or sampled if you configure either the sample or the syslog action modifier. You can specifyone of the following message codes: administratively-prohibited (default), bad-host-tos, bad-network-tos,host-prohibited, host-unknown, host-unreachable, network-prohibited, network-unknown, network-unreachable,port-unreachable, precedence-cutoff, precedence-violation, protocol-unreachable, source-host-isolated,source-route-failed, or tcp-reset. If you specify tcp-reset, a Transmission Control Protocol (TCP) reset isreturned if the packet is a TCP packet. Otherwise, the default code of administratively-prohibited, whichhas a value of 13, is returned.

rejectmessage-type

Specify a routing instance to which packets are forwarded.routing-instancerouting-instance

Sample the packets.sample

Specify a topology to which packets are forwarded.topologytopology-name

Action Modifiers

Number of packets passing this filter/term/policer. The name can contain letters, numbers, underscores(_), and hyphens (-), and can be up to 64 characters long. A counter name is specific to the filter that usesit, so all interfaces that use the same filter increment the same counter.

countcounter-name

Particular forwarding class.forwarding-classclass-name

IPsec SA for the packet. Used with the source-address and destination-address match conditions.ipsec-sa sa-name



Table 34: Firewall Filter Actions and Action Modifiers (continued)


Log the packet header information in a buffer within the Packet Forwarding Engine. You can access thisinformation by issuing the show firewall log command at the command-line interface (CLI).

log

Set the PLP to low, medium-low, medium-high, or high.

On M320 routers, you must enable the tricolor statement at the [edit class-of-service] hierarchy level tocommit a PLP configuration with any of the four levels specified. If the tricolor statement is not referenced,you can only configure the high and low levels. This applies to all protocol families.

You cannot also configure the three-color-policer action modifier for the same firewall filter term. Thesetwo action modifiers are mutually exclusive.

loss-priority priority

Apply rate limits to the traffic using the named policer.policerpolicer-name

Sample the traffic on the interface. Use this modifier only when traffic sampling is enabled. For moreinformation, see “Introduction to Traffic Sampling Configuration” on page 307.

sample

Store the packet header information on the Routing Engine and log it to the system log.syslog

Apply rate limits to the traffic using the tricolor marking policer.

You cannot also configure the loss-priority action modifier for the same firewall filter term. These twoaction modifiers are mutually exclusive.

three-color-policerpolicer-name

Example: Counting and Sampling Accepted Packets

Count, sample, and accept the traffic:

term all {then {

count sam-1;sample; # default action is accept

}}

Display the packet counter:

user@host> show firewall filter samFilter:Counters:Name Bytes Packetssamsam-1 98 8028

Display the firewall log output:

user@host> show firewall logTime Filter A Interface Pro Source address Destination address23:09:09 - A at-2/0/0.301 TCP 10.2.0.25 10.211.211.1:80



23:09:07 - A at-2/0/0.301 TCP 10.2.0.25 10.211.211.1:5623:09:07 - A at-2/0/0.301 ICM 10.2.0.25 10.211.211.1:4955223:02:27 - A at-2/0/0.301 TCP 10.2.0.25 10.211.211.1:5623:02:25 - A at-2/0/0.301 TCP 10.2.0.25 10.211.211.1:8023:01:22 - A at-2/0/0.301 ICM 10.2.2.101 10.211.211.1:2325123:01:21 - A at-2/0/0.301 ICM 10.2.2.101 10.211.211.1:1655723:01:20 - A at-2/0/0.301 ICM 10.2.2.101 10.211.211.1:2947123:01:19 - A at-2/0/0.301 ICM 10.2.2.101 10.211.211.1:26873

This output file contains the following fields:

■ Time—Time at which the packet was received (not shown in the default).

■ Filter—Name of a filter that has been configured with the filter statement at the[edit firewall] hierarchy level. A hyphen (-) or the abbreviation pfe indicates thatthe packet was handled by the Packet Forwarding Engine. A space (no hyphen)indicates that the packet was handled by the Routing Engine.

■ A—Filter action:

■ A—Accept (or next term)

■ D—Discard

■ R—Reject

■ Interface—Interface on which the filter is configured.

NOTE: We strongly recommend that you always explicitly configure an action in thethen statement.

■ Pro—Packet’s protocol name or number.

■ Source address—Source IP address in the packet.

■ Destination address—Destination IP address in the packet.

Display the sampling output:

user@host> show log /var/tmp/sam# Apr 7 15:48:50Time Dest Src Dest Src Proto TOS Pkt Intf IP TCP

addr addr port port len num frag flagsApr 7 15:48:54 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0Apr 7 15:48:55 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0Apr 7 15:48:56 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0

NOTE: When you enable reverse path forwarding (RPF) on an interface with an inputfilter for firewall log and count, the input firewall filter does not log the packetsrejected by RPF, although the rejected packets are counted. To log the rejectedpackets, use an RPF check fail filter.



For more information about sampling output, see “Applying Filters to ForwardingTables” on page 325.

Example: Setting the DSCP Bit to Zero

Set the DSCP bit to 0 (zero) using a firewall filter:

firewall {filter filter1 {

term 1 {from {

dscp 2;}then {

dscp 0;forwarding-class best-effort;

}}term 2 {

from {dscp 3;

}then {

forwarding-class best-effort;}

}}

}

Apply this filter to the logical interface corresponding to the VPN routing andforwarding (VRF) instance:

interfaces so-0/1/0 {unit 0 {

family inet {filter input filter1;

}}

}

Configuring Nested Firewall Filters

You can configure a filter within the term of another filter to minimize the workneeded to configure terms common to numerous filters. Each firewall filter consistsof one or more terms. You can configure one filter with the common desired terms,and apply them to other filters. To make changes to the common desired terms, youneed to make term modifications only to the filter with the common terms insteadof changing terms on every filter.

To configure a filter within a filter, include the filter statement at the [edit firewall filterinet filter-name term term-name] hierarchy level:

term term-name {filter filter-name;

214 ■ Configuring Nested Firewall Filters


}

A filter within a filter cannot reference yet another filter. For example, the followingconfiguration is not valid:

[edit]firewall {

filter filter-name {term t1 {

filter filter-name2 {term t2 {

filter filter-name3;}

}}

}}

You cannot configure the from or then statement under the same filter term thatreferences a filter within a filter. For example, the following configuration is not valid:

[edit]firewall {

filter filter-name {term t1 {

filter filter-name2 {then {

accept;}

}}

}}

The maximum number of filters within a filter is limited to 256.

Example: Configuring Nested Filters

Define a filter common-filter and configure it into two separate filters:

[edit]firewall {

filter common-filter {term t1 {

from {protocol udp;port tftp;

}then {

log;discard;

}}

}filter filter1 {

Configuring Nested Firewall Filters ■ 215


term term1 {filter common-filter;

}}filter filter2 {

term term1 {filter common-filter;

}}

}

Applying Firewall Filters to Interfaces

For a firewall filter to work, you must apply it to at least one interface. To do this,include the filter statement when configuring the logical interface at the [edit interfacesinterface-name unit logical-unit-number family family-name] hierarchy level:

[edit interfaces interface-name unit logical-unit-number family family-name]filter {

input filter-name;input-list [ filter-names ];output filter-name;output-list [ filter-names ];

}

In the input statement, list the name of one firewall filter to be evaluated when packetsare received on the interface. Input filters applied to the loopback interface, lo0,affect only inbound traffic destined for the Routing Engine.

In the input-list statement, list the names of firewall filters to be evaluated whenpackets are received on the interface. You can specify up to 16 firewall filters for thefilter input list. In the output-list statement, list the names of firewall filters to beevaluated when packets are transmitted from the interface. You can specify up to16 firewall filters for the filter output list.

In the output statement, list the name of one firewall filter to be evaluated whenpackets are transmitted on the interface. Output filters applied to the loopbackinterface, lo0, affect only outbound traffic sent from the Routing Engine.

NOTE: On MX Series routers only, you cannot apply as an output filter, a firewallfilter configured at the [edit firewall filter family ccc] hierarchy level. Firewall filtersconfigured for the family ccc statement can be applied only as input filters on MXSeries routers.

You can apply only one input and one output firewall filter to each interface. Youcan use the same filter one or more times.

For more information about configuring filters on interfaces, see the JUNOS NetworkInterfaces Configuration Guide.

216 ■ Applying Firewall Filters to Interfaces


When you apply a filter to an interface, it is evaluated against all the data packetspassing through that interface. The exception is the loopback interface, lo0, whichis the interface to the Routing Engine and carries no data packets. If you apply a filterto the lo0 interface, the filter affects the local packets received or transmitted by theRouting Engine.

Filters apply to all packets entering an interface, not just the packets destined for theRouting Engine. To filter packets destined for the Routing Engine, configure the groupstatement at the [edit interfaces interface-name unit logical-unit-number family family-namefilter] hierarchy level. For more information, see “Defining Interface Groups” on page218.

For filters applied to data packets to function, the routing platform must contain anInternet Processor II ASIC.

You can configure the following additional properties when applying filters tointerfaces:

■ Configuring Interface-Specific Counters on page 217

■ Defining Interface Groups on page 218

Configuring Interface-Specific Counters

When you configure a firewall filter that is applied to multiple interfaces, you canname individual counters specific to each interface. These counters enable you toeasily maintain statistics on the traffic transiting the different interfaces. A separateinstance of the interface-specific firewall filter is created for each interface to whichyou apply the filter.

NOTE: Configuration of interface-specific counters also creates separate instancesof any policers and counters you have configured for the same interface. For moreinformation about policers, see “Policer Configuration” on page 255.

To configure interface-specific counters, include the interface-specific statement atthe [edit firewall family family-name filter filter-name] hierarchy level:

[edit firewall family filter filter-name]interface-specific;

NOTE: The counter name is restricted to 24 bytes. If the renamed counter exceedsthis maximum length, the policy framework software might reject it.

Example: Configuring Interface-Specific Counters

Configure an interface-specific counter:

[edit firewall]family inet {

filter test {

Applying Firewall Filters to Interfaces ■ 217


interface-specific;term 1 {

from {address {

10.0.0.0/12;}protocol tcp;

}then {

count sample1;accept;

}}

}}

When you apply this filter to the input interface of at-1/1/1.0 and the output interfaceof so-2/2/2.2, the counters are named sample1-at-1/1/1.0-i andsample1-so-2/2/2/.2-o. The suffixes -i (input) and -o (output) are added to the counternames automatically.

The JUNOS Software does not sample packets originating from the router. If youconfigure a sampling filter and apply it to the output side of an interface, then onlythe transit packets going through that interface are sampled. Packets that are sentfrom the Routing Engine to the Packet Forwarding Engine are not sampled.

Defining Interface Groups

When applying a firewall filter, you can define an interface to be part of an interfacegroup. Packets received on that interface are tagged as being part of the group. Youthen can match these packets using the interface-group match statement, as describedin Table 24 on page 185.

To define an interface to be part of an interface group, include the group statementat the [edit interfaces interface-name unit logical-unit-number family family-name filter]hierarchy level:

[edit interfaces interface-name unit logical-unit-number family filter]group group-number;input filter-name;output filter-name;

In the group statement, specify the interface group number to be associated with thefilter.

In the input statement, list the name of one firewall filter to be evaluated when packetsare received on the interface.

In the output statement, list the name of one firewall filter to be evaluated whenpackets are transmitted on the interface.

218 ■ Applying Firewall Filters to Interfaces


NOTE: The JUNOS Software also supports defining interface sets to which to you canapply a firewall filter. An interface set lets you define a group a set of logical interfacesand apply hierarchical schedulers for class of services (CoS) to the interface set. Formore information about the interface-set interface-set-name firewall filter matchcondition, see the “Configuring Match Conditions in Firewall Filter Terms” on page182. For more information about configuring hierarchical schedulers for CoS, see theJUNOS Class of Service Configuration Guide.

Example: Defining Interface Groups

Create a filter that contains an interface group:


filter if-group {term group1 {

from {interface-group 1;address {

192.168.80.114/32;}protocol tcp;port finger;

}then {

count if-group-counter1;log;reject;

}}term group-2 {

then {count if-group-counter2;log;accept;

}}

}}

Assign one or more interfaces to the interface group referenced in the filter:

[edit interfaces]fxp0 {


filter {group 1;

}address 192.168.5.38/24;

}}

}

Applying Firewall Filters to Interfaces ■ 219


Apply the filter that contains an interface group:

[edit interfaces]lo0 {


filter {input if-group;group 1;

}address 10.0.0.1/32;address 192.168.77.1/32;

}}

}

Firewall Filter Examples

The following examples illustrate how to define firewall filters:

■ Example: Blocking Telnet and SSH Access on page 220

■ Example: Blocking TFTP Access on page 221

■ Example: Accepting DHCP Packets with Specific Addresses on page 222

■ Example: Defining a Policer for a Destination Class on page 222

■ Example: Counting IP Option Packets on page 223

■ Example: Accepting OSPF Packets from Certain Addresses on page 224

■ Example: Matching Packets Based on Two Unrelated Criteria on page 224

■ Example: Counting Both Accepted and Rejected Packets on page 225

■ Example: Blocking TCP Connections to a Certain Port Except from BGP Peerson page 225

■ Example: Accepting Packets with Specific IPv6 TCP Flags on page 226

■ Example: Setting a Rate Limit for Incoming Layer 2 Control Packets on page 227

Example: Blocking Telnet and SSH Access

Block telnet and SSH access to all but the 192.168.1.0/24 subnet. This filter alsologs any SSH or telnet traffic attempts from other subnets to the firewall log buffer:

[edit]firewall {

family inet {filter local-access-control {

term terminal-access {from {

address {192.168.1.0/24;

}protocol tcp;

220 ■ Firewall Filter Examples


port [ssh telnet];}then accept;

}term terminal-access-denied {

from {protocol tcp;port [ssh telnet];

}then {

log;reject;

}}term default-term {

then accept;}

}}

}

Example: Blocking TFTP Access

Block Trivial File Transfer Protocol (TFTP) access, logging any attempts to establishTFTP connections:

[edit]firewall {

family inet {filter tftp-access-control {

term one {from {

protocol udp;port tftp;

}then {

log;discard;

}}

}}

}

By default, to decrease vulnerability to denial-of-service (DoS) attacks, the JUNOSSoftware filters and discards Dynamic Host Configuration Protocol (DHCP) orBootstrap Protocol (BOOTP) packets that have a source address of 0.0.0.0 and adestination address of 255.255.255.255. This default filter is known as a unicastRPF check. However, some vendors’ equipment automatically accepts these packets.To interoperate with other vendors' equipment, you can configure a filter that checksfor both these addresses and overrides the default RPF-check filter by accepting thesepackets.

Example: Blocking TFTP Access ■ 221


Example: Accepting DHCP Packets with Specific Addresses

Configure a filter (rpf-dhcp) that accepts DHCP packets with a source address of 0.0.0.0and a destination address of 255.255.255.255:

[edit firewall family inet]filter rpf-dhcp {

term dhcp {from {

source-address {0.0.0.0/32;

}destination-address {

255.255.255.255/32;}

}then {

accept;}

}}

To apply this filter to an interface, include the rpf-check fail-filter statement at the [editinterface interface-name unit logical-unit-number family family-name] hierarchy level:

[edit interface interface-name unit logical-unit-number family inet]rpf-check fail-filter rpf-dhcp;

Example: Defining a Policer for a Destination Class

Define a policer for destination class class1:

[edit]firewall {

family inet {filter filter1 {

policer police-class1 {if-exceeding {

bandwidth-limit 25;burst-size-limit 1000;

}then {

discard;}

}term term1 {

from {destination-class class1;

}then {

policer police-class1;}

}

222 ■ Example: Accepting DHCP Packets with Specific Addresses


}}

}

Example: Counting IP Option Packets

Count individual IP option packets, but do not block any traffic. Also, log packetsthat have loose or strict source routing:

[edit]firewall {

family inet {filter ip-option-filter {

term match-strictsource {from {

ip-options strict-source-route;}then {

count strict-source-route;log;accept;

}}term match-loose-source {

from {ip-options loose-source-route;

}then {

count loose-source-route;log;accept;

}}term match-record {

from {ip-options record-route;

}then {

count record-route;accept;

}}term match-timestamp {

from {ip-options timestamp;

}then {

count timestamp;accept;

}}term match-router-alert {

from {ip-options router-alert;

}

Example: Counting IP Option Packets ■ 223


then {count router-alert;accept;

}}term match-all {

then accept;}

}}

}

Example: Accepting OSPF Packets from Certain Addresses

Accept only OSPF packets from an address in the prefix 10.108.0.0/16, discardingall other packets with an administratively-prohibited ICMP message:

[edit]firewall {

family inet {filter ospf-filter {

term term1 {from {


}protocol ospf;

}}term default-term {

then {reject administratively-prohibited; # default reject action

}}

}}

}

Example: Matching Packets Based on Two Unrelated Criteria

Match packets that are either OSPF packets or packets that come from an addressin the prefix 10.108/16, and send an administratively-prohibited ICMP message forall packets that do not match:

[edit]firewall {

family inet {filter ospf-or-131 {

term protocol-match {from {

protocol ospf;}

}term address-match {

224 ■ Example: Accepting OSPF Packets from Certain Addresses


from {source-address {

10.108.0.0/16;}

}}

}}

}

Example: Counting Both Accepted and Rejected Packets

Reject all addresses except 192.168.5.0/24. In the first term, the statement192.168.5.2/24 except causes this address to be considered a mismatch and thisaddress is passed to the next term in the filter. The address 0.0.0.0/0 in the firstterm matches all other packets, and these are counted, logged, and rejected. In thesecond term, all packets that passed though the first term (that is, packets whoseaddress matches 192.168.5.2/24) are counted, logged, and accepted.

[edit]firewall {

family inet {filter fire1 {

term 1 {from {

address {192.168.5.0/24 except;0.0.0.0/0;

}}then {

count reject-pref1-1;log;reject;

}}term 2 {

then {count reject-pref1-2;log;accept;

}}

}}

}

Example: Blocking TCP Connections to a Certain Port Except from BGP Peers

Block all TCP connection attempts to port 179 from all requesters except the specifiedBGP peers:

[edit]

Example: Counting Both Accepted and Rejected Packets ■ 225


firewall {family inet {

filter bgp179 {term 1 {


0.0.0.0/0;}source-prefix-list {

bgp179 except;}destination-port bgp;

}then {

reject;}

}term 2 {

then {accept;

}}

}}

}

Expand the prefix list bgp179 to include all BGP group neighbors:

[edit policy-options]prefix-list bgp179 {

apply-path "protocols bgp group <*> neighbor <*>";}

Apply the filter bgp179 to interface lo0:

[edit interfaces lo0]unit 0 {


input bgp179;}address 10.0.0.1/32;

}}

Example: Accepting Packets with Specific IPv6 TCP Flags

Configure a filter to match on IPv6 TCP flags:

[edit]firewall {

family inet6 {filter tcpfilt {

term 1 {from {

226 ■ Example: Accepting Packets with Specific IPv6 TCP Flags


next-header tcp;tcp-flags syn;

}then {

count tcp_syn_pkt;log;accept;

}}

}}

}

Example: Setting a Rate Limit for Incoming Layer 2 Control Packets

Configure rate limiting for incoming Layer 2 control packets. In order to meet thisrequirement, you must configure an input filter with the family type any and applythis filter to the interface:

[edit]firewall {

policer p1 {if-exceeding {

bandwidth-limit 5m;burst-size-limit 10m;

}then discard;

}policer p2 {

if-exceeding {bandwidth-limit 40m;burst-size-limit 100m;

}then discard;

}policer p3 {

if-exceeding {bandwidth-limit 600m;burst-size-limit 1g;

}then discard;

}interface-set ifset {

fe-*;}family any {

filter L2-filter {term t1 {

from {interface fe-0/0/0.0;

}then policer p1;

}term t2 {

from {

Example: Setting a Rate Limit for Incoming Layer 2 Control Packets ■ 227


interface-set ifset;}then policer p2;

}term t3 {

then policer p3;}

}}

}[edit]interfaces {

fe-0/0/0 {unit 0 {


}}

}fe-1/0/0 {


address 10.2.2.1/30;}

}}lo0 {

unit 0 {family any {

filter {input L2-filter;

}}

}}

}

Configuring Service Filters

A service filter identifies packets on one or more services are to be applied, andwhich PIC performs the service. To configure service filters, include the service-filterstatement at the [edit firewall family (inet | inet6] hierarchy level:

[edit firewall family (inet | inet6)]service-filter filter-name {




}}

}

228 ■ Configuring Service Filters


NOTE: You must specify either inet or inet6 as the protocol family in order to configurea service filter.

Service filters are configured the same way as firewall filters. A subset of matchconditions and actions for firewall filters are supported for service filters have a subsetof the.

One of the actions you configure must be service or skip:

■ Specifying the service action directs packets for stateful-firewall service.

■ Specifying the skip action let packets bypass stateful-firewall service.

The following actions are also supported for service filters:

■ count counter-name—Count the packet in the specified counter.

■ log—Log the packet header information in a buffer within the Packet ForwardingEngine. You can access this information by issuing the show firewall log command.

■ port-mirror—Port Mirror the packets

■ sample—Sample the packets

For more information about services and service interfaces, see the JUNOS ServicesInterfaces Configuration Guide.

Configuring Simple Filters

Simple filters are recommended for metropolitan Ethernet applications. They aresupported on Gigabit Ethernet intelligent queuing (IQ2) and Enhanced Queuing DensePort Concentrator (EQ DPC) interfaces only. Unlike normal filters, simple filters arefor IPv4 traffic only and have the following restrictions:

■ The next-term action is not supported.

■ Qualifiers, such as except and protocol-except match conditions, are not supported.

■ Noncontiguous masks are not supported.

■ Only one source-address and one destination-address prefix are allowed for eachfilter term. If you configure, multiple prefixes, only the last one is used.

■ Ranges are only valid as source or destination ports. For example, you canconfigure source-port 400-500 or destination-port 600-700.

■ Output filters are not supported. You can apply a simple filter to ingress trafficonly.

■ Simple filters are not supported for interfaces in an aggregated-Ethernet bundle.

■ Explicitly configurable terminating actions, such as accept, reject, or discard, arenot supported. Simple filters always accept packets.

■ Simple filters support only the following action modifiers: forwarding-class,loss-priority, and policer.

Configuring Simple Filters ■ 229


To configure simple filters, include the simple-filter statement at the [edit firewall familyinet] hierarchy level:

[edit firewall family inet]simple-filter filter-name {



action-modifiers;}

}}

For more information about Ethernet IQ2 PICs and EQ DPCs and related features,see the JUNOS Services Interfaces Configuration Guide and the JUNOS Class of ServiceConfiguration Guide. For additional information about configuring the MX Seriesrouters, on which EQ DPCs are supported, see the MX-series Layer 2 ConfigurationGuide.

Example: Configuring a Simple Filter

Configure a simple filter to support Ethernet IQ2 PICs:

[edit]firewall {

family inet {simple-filter sf-1 {

term 1 {from {

source-address 172.16.0.0/16;destination-address 20.16.0.0/16;source-port 1024-9071;

}then {

forwarding-class fc-be1;loss-priority high;accept;

}}term 2 {

from {source-address 173.16.0.0/16;destination-address 21.16.0.0/16;

}then {

forwarding-class fc-ef1;loss-priority low;accept;

}}

}}

}

230 ■ Configuring Simple Filters


Configuring Firewall Filters for Logical Systems

You can configure a separate set of firewall filters for each logical system on therouter. To configure a firewall filter for a logical system, you must perform at leastthe following tasks:

■ Configure firewall filters for the logical system—To configure firewall filters forthe logical system, include the firewall statement at the [edit local-systemslogical-system-name] hierarchy level:

[edit logical-systems logical-system-name]firewall {


accounting-profile name;interface-specific;term term-name {


}then {


}}

}}

}

■ Apply firewall filters to interfaces in the logical system—To have the firewallfilter take effect, you must apply it to an interface in the logical system byincluding the filter statement at the [edit logical-systems logical-system-nameinterfaces interface-name unit logical-unit-number family family-name] hierarchylevel:

[edit logical-systems logical-system-name interfaces interface-name unitlogical-unit-number family family-name]

filter {input filter-name;output filter-name;

}

To identify firewall objects configured under logical systems, operational showcommands and firewall-related SNMP MIB objects include a __logical-system-name/prefix in the object name. For example, firewall objects configured under the ls1logical system include an __ls1/ prefix.

This section includes the following topics:

■ Guidelines for Firewall Configuration in Logical Systems on page 232

■ Unsupported Configuration Statements, Actions, and Action Modifiers on page 239

Configuring Firewall Filters for Logical Systems ■ 231


Guidelines for Firewall Configuration in Logical Systems

As a general rule, firewall filters configured under a logical system must be completeand self-contained. Typically, the filters cannot reference firewall elements configuredat the [edit firewall] hierarchy level or at another [edit logical-systemslogical-system-name] hierarchy level. If no firewall filters are configured for a logicalsystem, the firewall filters at the [edit firewall] hierarchy level are applied.

In some situations, firewall statements that are valid under the [edit firewall] hierarchyare not supported under the [edit logical-systems logical-system-name firewall] hierarchy.There are three scenarios to consider:

■ Scenario 1. An object in the firewall hierarchy references another object in thehierarchy; for example, when a firewall filter references a firewall policer.

■ Scenario 2. An object outside the firewall references an object inside the firewallhierarchy; for example, a firewall filter is applied to an interface.

■ Scenario 3. An object in the firewall hierarchy references an object outside thefirewall hierarchy; for example, when a firewall filter references a prefix list(defined under the [edit policy-options] hierarchy).

This section includes the following topics:

■ Scenario 1: Firewall Objects Reference Other Firewall Objects on page 232

■ Scenario 2: Nonfirewall Objects Reference Firewall Objects on page 233

■ Scenario 3: Firewall Objects Reference Nonfirewall Objects on page 237

Scenario 1: Firewall Objects Reference Other Firewall Objects

If a firewall object references a subordinate object (for example, a policer or prefixlist), that subordinate object must be defined within the firewall object. For example,if a firewall filter configuration references a policer, that policer must be configuredunder the same firewall object as the filter. This rule applies even if the same policeris configured under the main firewall configuration or if the same policer is configuredas part of a firewall in another logical system.

In this example, the filter1 filter references the pol1 policer. Both filter1 and pol1 aredefined under the same firewall object. This configuration is valid. If pol1 were definedunder another firewall object, the configuration would not be valid.

[edit]logical systems {

ls1 {firewall {

policer pol1 {if-exceeding {

bandwidth-limit 401k;burst-size-limit 50k;

}then discard;

}filter filter1 {

232 ■ Configuring Firewall Filters for Logical Systems


term one {from {

source-address 12.1.0.0/16;}then {

reject host-unknown;}

}term two {

from {source-address 12.2.0.0/16;

}then policer pol1;

}}

}}

}

Scenario 2: Nonfirewall Objects Reference Firewall Objects

When an object is configured within a logical system (but is not included in thefirewall configuration for the logical system) and that object references a firewallobject, the following logic is used to resolve the configuration:

■ If firewall configuration statements are defined within the same logical system,the [edit logical-systems logical-system-name firewall] hierarchy is searched toresolve the configuration. The main [edit firewall] hierarchy is not searched.

■ If no firewall configuration statements are defined within the same logical system,the firewall configuration defined at the [edit firewall] hierarchy level is searchedto resolve the configuration. This search option is provided for legacy purposes.The main [edit firewall] hierarchy is searched only if firewall configurationstatements are not defined within the same logical system.

■ Firewall configurations that belong to other logical systems are not searched.

In the following example, the filter fred is applied to an interface in the logical systemls1. However, fred is defined in the main firewall configuration instead of in the ls1firewall configuration. Therefore, in this first example, the configuration is not valid.

[edit]logical-systems {

ls1 {interfaces {

fe-0/3/2 {unit 0 {


input-list [ filter1 fred ];}

}}

}}



firewall {policer pol1 {

if-exceeding {bandwidth-limit 401k;burst-size-limit 50k;

}then discard;

}filter filter1 {

term one {from {



}term two {


}then policer pol1;

}}

}}

}firewall {



}then discard;

}family inet {

filter fred {term one {


}then {

log;reject host-unknown;

}}

}}

}

To fix this example, define filter fred under logical system ls1. In this case, the filterfred applied to interface fe-0/3/2 looks for source address 10.1.0.0/16 rather than11.1.0.0/16.




ls1 {interfaces {

fe-0/3/2 {unit 0 {



}}

}}firewall {



}then discard;

}filter filter1 {

term one {from {



}term two {


}then policer pol1;

}}family inet {



}then {


}}

}}

}}

}firewall {


bandwidth-limit 701k;



burst-size-limit 70k;}then discard;

}family inet {



}then {


}}

}}

}

If, however, the [edit logical-systems logical-system-name] hierarchy does not containany firewall statements, then the main firewall configuration is used for any filter orpolicer references. For example, the following configuration is also allowed:


ls1 {interfaces {

fe-0/3/2 {unit 0 {



}}

}}

}}firewall {



}then discard;

}family inet {



}then {




}}

}filter filter1 {

term one {from {



}term two {


}then policer pol1;

}}

}}

Scenario 3: Firewall Objects Reference Nonfirewall Objects

In many cases, a firewall configuration references objects outside the firewallconfiguration. As a general rule, the referenced object must be defined under thesame logical system as the referencing object. However, there are cases when theconfiguration of the referenced object is not supported at the [edit logical-systemslogical-system-name] hierarchy level.

In the following example, the service filter inetsf1 references prefix list prefix1. Theservice set fred cannot be defined under the logical system lr1. In this case, the [editservices] hierarchy is searched for the definition of the fred service set. Thisconfiguration is allowed because the [edit logical-systems logical-systemlogical-system-name] hierarchy already had the capability to reference service setsoutside the logical system hierarchy.


ls1 {interfaces {

fe-0/3/2 {unit 0 {

family inet {service {

input {service-set fred service-filter lr1inetsf1;

}}

}}

}}policy-options {

prefix-list prefix1 {



1.1.0.0/16;1.2.0.0/16;1.3.0.0/16;

}}firewall {



}then discard;

}filter filter1 {

term one {from {



}term two {


}then policer pol1;

}}family inet {

service-filter inetsf1 {term term1 {

from {source-prefix-list {

prefix1;}

}then count prefix1;

}}

}}

}}services {

service-set fred {max-flows 100;interface-service {

service-interface sp-1/2/0.0;}

}}



Unsupported Configuration Statements, Actions, and Action Modifiers

Table 35 on page 239 lists statements that are supported at the [edit firewall] hierarchylevel but not at the [edit logical-systems logical-system-name firewall] hierarchy level.

Table 35: Unsupported Firewall Statements for Logical Systems

DescriptionExampleStatement

In this example, the accounting-profilestatement is not allowed because theaccounting profile fw-profile isconfigured under the [editaccounting-options] hierarchy.


ls1 {firewall {

family inet {filter myfilter {

accounting-profile fw-profile;...term accept-all {

then {count counter1;accept;

}}

}}

}}

}

accounting-profile

This configuration is not allowedbecause the next-hop-group nh-groupstatement must be configured at the[edit forwarding-options next-hop-group]hierarchy level—outside the [editlogical-systems logical-system-namefirewall] hierarchy.

Currently, the forwarding-optionsdhcp-relay statement is the onlyforwarding option supported for logicalsystems.


ls1 {firewall {

load-balance-group lb-group {next-hop-group nh-group;

}}

}}

load-balance-group



Table 35: Unsupported Firewall Statements for Logical Systems (continued)

DescriptionExampleStatement

This configuration is not allowedbecause the virtual channel sammyrefers to an object defined at the [editclass-of-service] hierarchy level andclass of service is not supported forlogical systems.


ls1 {firewall {

family inet {filter foo {

term one {from {


virtual-channel sammy;}

}}

}}

}}

virtual-channel

Table 36 on page 240 includes a list of the firewall filter actions and action modifiersthat are supported at the [edit firewall] hierarchy level, but not supported at the [editlogical-systems logical-system-name firewall] hierarchy level.

Table 36: Unsupported Firewall Actions and Action Modifiers for Logical Systems

DescriptionExampleAction or ActionModifier

(EX Series switches) Because theanalyzer action relies on a configurationdefined at the [editethernet-switching-options] hierarchylevel, this action is not supported.


ls1 {firewall {


term one {from {


analyzer;}

}}

}}

}}

analyzer



Table 36: Unsupported Firewall Actions and Action Modifiers for Logical Systems (continued)


Because the ipsec-sa action modifierreferences barney, a securityassociation defined outside the locallogical system, this action is notsupported.


ls1 {firewall {


term one {from {


ipsec-sa barney;}

}}

}}

}}

ipsec-sa

Because the logical-system action refersto fred, a logical system defined outsidethe local logical system, this action isnot supported.


ls1 {firewall {


term one {from {


logical-system fred;}

}}

}}

}}

logical-system





Because the next-hop-group action refersto fred, an object defined at the [editforwarding-options next-hop-group]hierarchy level, this action is notsupported.


ls1 {firewall {


term one {from {


next-hop-group fred;}

}}

}}

}}

next-hop-group

Because the port-mirror action relies ona configuration defined at the [editforwarding-options port-mirroring]hierarchy level, this action is notsupported.


ls1 {firewall {


term one {from {


port-mirror;}

}}

}}

}}

port-mirror





In this example, the sample actiondepends on the sampling configurationdefined under the [editforwarding-options] hierarchy.Therefore, the sample action is notsupported.


ls1 {firewall {


term one {from {


sample;}

}}

}}

}}

sample

In this example, there must be at leastone system log (system syslog filefilename) with the firewall facilityenabled for the icmp-syslog filter's logsto be stored.

Because this firewall configurationrelies on a configuration outside thelogical system, the syslog actionmodifier is not supported.


ls1 {firewall {

family inet {filter icmp-syslog {

term icmp-match {from {

address {192.168.207.222/32;

}protocol icmp;

}then {

count packets;syslog;accept;

}}term default {

then accept;}

}}

}}

}

syslog



Configuring Accounting for Firewall Filters

Juniper Networks devices can collect various kinds of data about traffic passingthrough the device. You can set up one or more accounting profiles that specify somecommon characteristics of this data, including the following:

■ Fields used in the accounting records

■ Number of files that the routing platform retains before discarding, and thenumber of bytes per file

■ Polling period that the system uses to record the data

There are several types of accounting profiles: interface, firewall filter, destinationclass, and Routing Engine. To configure an accounting profile, include statements atthe [edit accounting-options] hierarchy level. For more information, see the JUNOSNetwork Management Configuration Guide.

To activate a firewall filter profile, include the accounting-profile statement at the [editfirewall family family-name filter filter-name] hierarchy level:

[edit firewall family family-name filter filter-name]accounting-profile profile-name;

If you apply the same profile name to both a firewall filter and an interface, it causesan error.

The following example configures an accounting profile called fw_profile and appliesit to the firewall filter called myfilter.

[edit]accounting-options {

filter-profile fw_profile {file fw_accounting;interval 60;counters {

counter1;counter2;counter3;

}}

}firewall {

family inet {filter myfilter {

accounting-profile fw_profile;...term accept-all {

then {count counter1;accept;

}}

}}

244 ■ Configuring Accounting for Firewall Filters


}

Configuring Filter-Based Forwarding

You can configure filters to classify packets based on source address and specify theforwarding path the packets take within the router by configuring a filter on theingress interface. For example, you can use this filter for applications to differentiatetraffic from two clients that have a common access layer (for example, a Layer 2switch) but are connected to different Internet service providers (ISPs). When thefilter is applied, the router can differentiate the two traffic streams and direct eachto the appropriate network. Depending on the media type the client is using, thefilter can use the source IP address to forward the traffic to the corresponding networkthrough a tunnel. You can also configure filters to classify packets based on IP protocoltype or IP precedence bits.

NOTE: Source-class usage filter matching and unicast reverse-path forwarding checksare not supported on an interface configured with filter-based forwarding (FBF).

You can also forward packets based on output filters by configuring a filter on theegress interfaces. In the case of port mirroring, it is useful for port-mirrored packetsto be distributed to multiple monitoring PICs and collection PICs based on patternsin packet headers. FBF on the port-mirroring egress interface must be configured.

Packets forwarded to the output filter have been through at least one route lookupwhen an FBF filter is configured on the egress interface. After the packet is classifiedat the egress interface by the FBF filter, it is redirected to another routing table forfurther route lookup.

Filter-based forwarding is supported for IPv4 and IPv6.

To direct traffic meeting defined match conditions to a specific routing instance,include the routing-instance filter action:

routing-instance routing-instance;

For IPv4 traffic, include the action at the [edit firewall family inet filter filter-name termterm-name then] hierarchy level. For IPv6 traffic, include the action at the [edit firewallfamily inet6 filter filter-name term term-name then] hierarchy level. For MPLS traffic,configure the filter terms at the [edit firewall family mpls filter filter-name term term-namethen] hierarchy level.

The routing-instance filter action accepts the traffic meeting the match conditions anddirects it to the routing instance named in routing-instance. For information aboutforwarding instances and routing instances, see the JUNOS Routing ProtocolsConfiguration Guide.

To complete the configuration, you must also create a routing table group that addsinterface routes to the following routing instances:

■ Routing instance named in the action

■ Default routing table inet.0

Configuring Filter-Based Forwarding ■ 245


You create a routing table group to resolve the routes installed in the routing instanceto directly connected next hops on that interface. For more information on routingtable groups and interface routes, see the JUNOS Routing Protocols ConfigurationGuide.

Examples: Configuring Filter-Based Forwarding

Configure a filter to direct traffic to ISP1 or ISP2 based on source address matching:


filter classify-customers {term isp1-customers {

from {source-address 10.1.1.0/24;source-address 10.1.2.0/24;

}then {

routing-instance isp1-route-table;}

}term isp2-customers {


}then {

routing-instance isp2-route-table;}

}term default {

then {accept;

}}

}}

Configure a filter-based forwarding (FBF) filter for family inet6:

[edit]firewall {

family inet6 {filter ftf_fbf {

term 0 {from {

source-address {::10.34.1.0/120;

}}then {

count ce1;log;routing-instance ce1;

}

246 ■ Configuring Filter-Based Forwarding


}term 1 {


::10.34.2.0/120;}

}then {

count ce2;log;routing-instance ce2;

}}term default {

then {count default;accept;

}}

}}

}

Configuring Forwarding Table Filters

The following sections describe the following topics:

■ Overview of Forwarding Table Filters on page 247

■ Configuring a Forwarding Table Filter on page 248

Overview of Forwarding Table Filters

Forwarding table filters are defined the same as other firewall filters, but you applythem differently:

■ Instead of applying forwarding table filters to interfaces, you apply them toforwarding tables, each of which is associated with a routing instance and avirtual private network (VPN).

■ Instead of applying input and output filters by default you can apply an inputforwarding table filter only.

All packets are subjected to the input forwarding table filter that applies to theforwarding table. A forwarding table filter controls which packets the router acceptsand then performs a lookup for the forwarding table, thereby controlling whichpackets the router forwards on the interfaces.

When the router receives a packet, it determines the best route to the ultimatedestination by looking in a forwarding table, which is associated with the VPN onwhich the packet is to be sent. The router then forwards the packet toward itsdestination through the appropriate interface.

Configuring Forwarding Table Filters ■ 247


NOTE: For transit packets exiting the router through the tunnel, forwarding tablefiltering is not supported on the interfaces you configure as the output interface fortunnel traffic.

Configuring a Forwarding Table Filter

A forwarding table filter allows you to filter data packets based on their componentsand to perform an action on packets that match the filter; it essentially controls whichbearer packets the router accepts and forwards. To configure a forwarding tablefilter, include the firewall statement at the [edit] hierarchy level:

[edit]firewall {





}}

}}

}

family-name is the family address type: IPv4 (inet), IPv6 (inet6), Layer 2 traffic bridge,or MPLS (mpls).

term-name is a named structure in which match conditions and actions are defined.

match-conditions are the criteria against which a bearer packet is compared; forexample, the IP address of a source device or a destination device. You can specifymultiple criteria in a match condition.

action specifies what happens if a packet matches all criteria; for example, the gatewayGPRS support node (GGSN) accepting the bearer packet, performing a lookup in theforwarding table, and forwarding the packet to its destination; discarding the packet;and discarding the packet and returning a rejection message.

action-modifiers are actions that are taken in addition to the GGSN accepting ordiscarding a packet when all criteria match; for example, counting the packets andlogging a packet.

For more detailed information about configuring filters, see “Configuring StandardFirewall Filters” on page 179.

To create a forwarding table, include the instance-type statement with the forwardingoption at the [edit routing-instances instance-name] hierarchy level:

248 ■ Configuring Forwarding Table Filters


[edit]routing-instances instance-name {

instance-type forwarding;}

To apply a forwarding table filter to a VPN routing and forwarding (VRF) table, includethe filter and input statements at the [edit routing-instance instance-nameforwarding-options family family-name] hierarchy level:

[edit routing-instances instance-name]instance-type forwarding;forwarding-options {

family family-name {filter {

input filter-name;}

}}

To apply a forwarding table filter to a forwarding table, include the filter and inputstatements at the [edit forwarding-options family family-name] hierarchy level:

[edit forwarding-options family family-name]filter {

input filter-name;}

To apply a forwarding table filter to the default forwarding table inet.0, which is notassociated with a specific routing instance, include the filter and input statements atthe [edit forwarding-options family inet] hierarchy level:

[edit forwarding-options family inet]filter {

input filter-name;}

For more information about applying forwarding table filters, see “Applying Filtersto Forwarding Tables” on page 325. For information about routing instances, see theJUNOS Routing Protocols Configuration Guide.

Configuring System Logging of Firewall Filter Operations

System logging can be configured for the firewall filter process. You can set systemlogging to record messages of a particular level or all levels. The messages are sentto a system logging file.

The following is a sample system logging configuration for the firewall filtericmp-syslog. For more information about configuring system logging, see the JUNOSSystem Basics Configuration Guide.

[edit]system {

syslog {file filter {

Configuring System Logging of Firewall Filter Operations ■ 249


firewall any;archive no-world-readable;

}}

}

This configuration causes the system log to write any messages with the syslog facilityof firewall to the file /var/log/filter. This keeps the messages out of the main systemlog file and makes them easier to find.

Example: Configuring Firewall Filter System Logging

Create a filter that logs and counts ICMP packets that have 192.168.207.222 as eithertheir source or destination:

[edit]firewall {

family inet {filter icmp-syslog {

term icmp-match {from {

address {192.168.207.222/32;

}protocol icmp;

}then {

count packets;syslog;accept;

}}term default {

then accept;}

}}

}

Enter the show log filter command to display the results:

root@hostname> show log filterMar 20 08:03:11 hostname feb FW: so-0/1/0.0 A icmp 192.168.207.222192.168.207.223 0 0 (1 packets)

This output file contains the following fields:

■ Date and Time—Date and time at which the packet was received (not shown inthe default).

■ Filter action:

■ A—Accept (or next term)

■ D—Discard

250 ■ Configuring System Logging of Firewall Filter Operations


■ R—Reject

■ Protocol—Packet’s protocol name or number.

■ Source address—Source IP address in the packet.

■ Destination address—Destination IP address in the packet.

NOTE: If the protocol is ICMP, the ICMP type and code are displayed. For all otherprotocols, the source and destination ports are displayed.

The last two fields (both zero) are the source and destination TCP/UDP ports,respectively, and are shown for TCP or UDP packets only. This log message indicatesthat only one packet for this match has been detected in about a one-second interval.If packets arrive faster, the system log function compresses the information so thatless output is generated, and displays an output similar to the following:

root@hostname> show log filterMar 20 08:08:45 hostname feb FW: so-0/1/0.0 A icmp 192.168.207.222 192.168.207.223 0 0 (515 packets)

Configuring System Logging of Firewall Filter Operations ■ 251


252 ■ Configuring System Logging of Firewall Filter Operations


Chapter 10

Policer Overview

Policing, or rate limiting, enables you to limit the amount of traffic that passes intoor out of an interface. It is an essential component of firewall filters that is designedto thwart denial-of-service (DoS) attacks. Policing applies two types of rate limits onthe traffic:

■ Bandwidth—The number of bits per second permitted, on average.

■ Maximum burst size—The maximum size permitted for bursts of data that exceedthe given bandwidth limit.

Policing uses the token-bucket algorithm, which enforces a limit on average bandwidthwhile allowing bursts up to a specified maximum value. It offers more flexibility thanthe leaky bucket algorithm (see the JUNOS Class of Service Configuration Guide) inallowing a certain amount of bursty traffic before it starts discarding packets.

You can define specific classes of traffic on an interface and apply a set of rate limitsto each. You can use a policer in one of two ways: as part of a filter configuration oras part of a logical interface (where the policer is applied to all traffic on that interface).

After you have defined and named a policer, it is stored as a template. You can lateruse the same policer name to provide the same policer configuration each time youwish to use it. This eliminates the need to define the same policer values more thanonce.

■ 253

254 ■


Chapter 11

Policer Configuration

The following sections describe the tasks required for configuring policers and provideconfiguration examples:

■ Configuring Policers on page 255

■ Minimum Policer Configuration on page 256

■ Configuring Policers on page 257

■ Configuring Multifield Classifiers for Policing on page 259

■ Configuring Interface Sets on page 267

■ Applying Interface Policers on page 267

■ Configuring Aggregate Policers on page 268

■ Physical Interface Policer Overview on page 270

■ Configuring Physical Interface Policers on page 270

■ Configuring Bandwidth Policers on page 274

■ Configuring Load-Balance Groups on page 275

■ Configuring Tricolor Marking on page 275

■ Examples: Configuring Policing on page 279

Configuring Policers

To configure policers, you include statements at the [edit firewall] hierarchy level ofthe configuration:

[edit firewall]policer policer-name {

filter-specific;if-exceeding {

bandwidth-limit bps;bandwidth-percent number;burst-size-limit bytes;

}logical-bandwidth-policer;logical-interface-policer;physical-interface-policer;then {

policer-action;}

Configuring Policers ■ 255

}interface-set interface-set-name {

interface-name;}family family-name {

filter filter-name {accounting-profile name;interface-specific;

}prefix-action name {

count;destination-prefix-length prefix-length;policer policer-name;source-prefix-length prefix-length;subnet-prefix-length prefix-length;

}}load-balance-group group-name {

next-hop-group [ group-names ];}three-color-policer name {

action {loss-priority high then discard;

}logical-interface-policer;single-rate {

(color-aware | color-blind);committed-information-rate bps;committed-burst-size bytes;excess-burst-size bytes;

}two-rate {

(color-aware | color-blind);committed-information-rate bps;committed-burst-size bytes;peak-information-rate bps;peak-burst-size bytes;

}}

Minimum Policer Configuration

To configure a policer, you must perform at least the following tasks:

■ Configure policers—To configure policers, include the policer statement at the[edit firewall] hierarchy level. After policers are defined, you reference them inthe then clause of a term:


if-exceeding {bandwidth-limit bps;bandwidth-percent number;burst-size-limit bytes;

}

256 ■ Minimum Policer Configuration


then {policer-action;

}}family family-name {

filter filter-name {}

}

■ Add actions, such as accept, discard, or next term, or action modifiers, such ascount or log.

■ Apply the policers to an interface to activate them.

The policer is applied to the packet first, and if the packet exceeds the defined limits,the actions of the then clause of the policer are applied. If the result of the policingaction is not a discard, the remaining components of the then clause of the term areapplied.

NOTE: If an input filter is configured on the same logical interface as the policer, thepolicer is executed first.

To display statistics about a filter statement policer configuration, use the showpolicers command.

Configuring Policers

You can configure a new policer for each filter or term that requires policing. Toconfigure term-specific policers, include the policer statement at the [edit firewall]hierarchy level:


if-exceeding {bandwidth-limit bps;bandwidth-percent number;burst-size-limit bytes;

}then {}

}

The following sections describe the components of the policer statement and providepolicer configuration examples:

■ Configuring Rate Limiting on page 258

■ Configuring Policer Actions on page 259

Configuring Policers ■ 257

Chapter 11: Policer Configuration

Configuring Rate Limiting

To specify the rate limiting part of a policer, include an if-exceeding statement at the[edit firewall policer policer-name] hierarchy level:

[edit firewall policer]if-exceeding {


}

You specify the bandwidth limit in bits per second (bps). You can specify the valueas a complete decimal number or as a decimal number followed by the abbreviationk (1000), m (1,000,000), or g (1,000,000,000). Any value below 61,040 bps resultsin an effective rate of 30,520 bps. In JUNOS Release 9.4 and later, the minimumbandwidth limit that you can configure on M120, M320, and MX Series routers onlyis 8000 bps. The minimum bandwidth limit that you can configure for all otherplatforms remains 32,000 bps. The maximum bandwidth limit is 40 gigabits persecond (Gbps).

You can rate-limit traffic based upon port speed. This port speed can be specified bya bandwidth percentage in a policer. You must specify the percentage as a completedecimal number between 1 and 100.

NOTE: You cannot rate-limit based on bandwidth percentage for aggregate, tunnel,and software interfaces. The bandwidth percentage policer cannot be used forforwarding table filters. Bandwidth percentage policers can only be used forinterface-specific filters.

The maximum burst size controls the amount of traffic bursting allowed. To determinethe value for the burst-size limit, the preferred method is to multiply the bandwidth(expressed as bytes per second) of the interface on which you are applying the filterby the amount of time you allow a burst of traffic at that bandwidth to occur. Werecommend that you use a value of 5 ms as the starting point for the allowableamount of time for a burst of traffic.

If you express the bandwidth as bits per second, use the following formula to calculatethe burst size.

burst size = bandwidth x allowable time for burst traffic / 8

If you do not know the interface bandwidth, you can multiply the maximumtransmission unit (MTU) of the traffic on the interface by 10 to obtain a value. Forexample, the burst size for an MTU of 4700 would be47,000 bytes. At minimum,burst size should be at least 10 interface MTUs. The maximum value for the burst-sizelimit is 100 megabits per second (Mbps).

For a sample filter configuration for rate limiting, see “Examples: Configuring Policing”on page 279.

258 ■ Configuring Policers


Configuring Policer Actions

If a packet does not exceed its rate limits, it is processed further without beingaffected. If the packet exceeds its limits, it is handled in one of two ways, dependingon what you specify:

■ Discarded

■ Marked for subsequent processing based on its loss priority and forwarding class

To configure a policer action, include the then statement at the [edit firewall policerpolicer-name] hierarchy level:

[edit firewall policer policer-name]then {}

Policer actions include one or more of the following:

■ discard—Discard a packet that exceeds the rate limits.

■ loss-priority level—Set the loss priority level to low, medium-low, medium-high, orhigh.

■ forwarding-class class-name—Specify the forwarding class to any class namealready configured for the forwarding class.

Example: Configuring a Policer Action

Discard any packet that exceeds a bandwidth of 300 kilobits per second (Kbps) anda burst-size limit of 500 kilobytes (KB):

[edit firewall]policer p1 {


}then {

discard;}

}

Configuring Multifield Classifiers for Policing

Multifield classifiers take action on incoming or outgoing packets, depending whetherthe firewall rule is applied as an input filter or an output filter. When TCM is enabled,T Series and M320 routers support four multifield classifier packet loss priority (PLP)designations: low, medium-low, medium-high, and high.

To configure the PLP for a multifield classifier, include the loss-priority statement ina policer or firewall filter that you configure at the [edit firewall] hierarchy level:

Configuring Multifield Classifiers for Policing ■ 259



filter filter-name {term term-name {


}then {

loss-priority (low | medium-low | medium-high | high);forwarding-class class-name;

}}

}}

The inputs (match conditions) for a multifield classifier are one or more of the sixpacket header fields: destination address, source address, IP protocol, source port,destination port, or DSCP. The outputs for a multifield classifier are the forwardingclass, the PLP, or both. In other words, a multifield classifier sets the forwarding classand the PLP for each packet entering or exiting the interface with a specific destinationaddress, source address, IP protocol, source port, destination port, or DSCP.

For example, in the following configuration, the forwarding class expedited-forwardingand PLP medium-high are assigned to all IPv4 packets with the 10.1.1.0/24or 10.1.2.0/24 source address:

firewall {family inet {

filter classify-customers {term isp1-customers {


}then {

loss-priority medium-high;forwarding-class expedited-forwarding;

}}

}}

}

To use this classifier, you must configure the settings for the expedited-forwardingforwarding class at the [edit class-of-service forwarding-classes queue queue-numberexpedited-forwarding] hierarchy level.

NOTE: Because the policer is executed before the filter, if an input policer is alsoconfigured on the logical interface, it cannot use the forwarding class and PLP of amultifield classifier associated with the interface.

You can configure multifield classifiers within a firewall filter to set the packet’sforwarding class and packet loss priority. You can also apply policers to packets

260 ■ Configuring Multifield Classifiers for Policing


matching some classification term. The policing action might affect the resultingforwarding class, packet loss priority, and accept or drop status. For more information,see the JUNOS Class of Service Configuration Guide.

To configure the forwarding class and loss priority, include the then statement:

then {loss-priority;forwarding-class class-name;

}

You can include the statement at the following hierarchy levels:

■ [edit firewall filter filter-name term term-name]

■ [edit firewall policer policer-name]

You can specify one or both of the following actions:

■ loss-priority—Set the loss priority level to low or high.

■ forwarding-class—Specify the forwarding class to any class name alreadyconfigured for the forwarding class.

For more information about forwarding class and loss priority, see the JUNOS Classof Service Configuration Guide. For more information about policers, see the followingsections:

■ Configuring Filter-Specific Policers on page 261

■ Configuring Policer Actions for Specific Address Prefixes on page 262

■ Examples: Classifying Traffic on page 266

Configuring Filter-Specific Policers

You can configure filter-specific policers within the firewall configuration. Filter-specificpolicers allow you to configure policers and counters for a specific filter name.

When you configure the filter-specific statement, a single policer set is created forthe entire filter. All traffic matching the terms of the firewall filter with the actionpolicer goes through that single policer. The default is a term-specific policer in whicha single policer set is created for each term within the filter. All traffic matching theterms of the firewall filter with the action policer goes through the part of the policerthat is specific to that term.

To configure filter-specific policers, include the filter-specific statement at the [editfirewall policer policer-name] hierarchy level:

[edit firewall policer policer-name]filter-specific;

If the filter-specific statement is not configured, then the policer defaults to aterm-specific policer.

You can apply the filter-specific policers to the family inet.



Configuring Policer Actions for Specific Address Prefixes

You can configure prefix-specific actions within the firewall configuration.Prefix-specific actions allow you to configure policers and counters for specificaddresses or ranges of addresses. This allows you to essentially create policers andcounters on a per-prefix level.

To configure prefix-specific actions, include the prefix-action name statement at the[edit firewall family inet] hierarchy level:

[edit firewall family inet]prefix-action name {


}

The following formula determines the number of prefix-specific actions created:

Number = 2 ^ (source/destination-prefix-length - subnet-prefix-length)

The subnet-prefix-length statement allows for more control for the flexibility offeredby prefix-specific actions, allowing the policers to be more applicable and powerful.For example, if you want to filter all Transmission Control Protocol (TCP) packetsand define two policers, all packets ending with 0 in the last address bit incrementthe first policer, while all packets ending with 1 in the address bit increment thesecond policer. As another example, if you want to filter all TCP packets and define256 policers, matching is based on the last octet of the destination address field. Youachieve both cases by specifying an appropriate subnet prefix length.

Prefix-specific action is supported for the IP version 4 (IPv4) inet address family.

To configure prefix-specific actions, include the prefix-action statement and specifyan action name.

To enable a prefix-specific counter, include the count statement.

To configure the destination address range specified for a prefix-specific policer orcounter, include the destination-prefix-length statement.

To enable a set of prefix-specific policers, include the policer statement and specifythe policer name.

To configure the source address range specified for a prefix-specific policer or counter,include the source-prefix-length statement.

To configure the total address range of the subnet supported, include thesubnet-prefix-length statement. The source or destination prefix length must be largerthan the subnet prefix length.



Prefix-specific action applies to a specific prefix length, and not to a specific interface.You can add an interface policer polices at the aggregate level for a specific interface.You could also use the next term action to configure all Hypertext Transfer Protocol(HTTP) traffic to each host to transmit at 500 Kbps and have the total HTTP trafficlimited to 1 Mbps.

The maximum number of policers you can configure for one subnet is 65,536. If youconfigure more than 65,536 policers, you receive an error message.

NOTE: J Series Services Routers do not support prefix-specific actions.

Examples: Configuring Policer Actions for Specific Address Prefixes

Create a prefix-specific policer operating on the source address and apply it to theinput interface:

[edit]firewall {

policer host-policer {filter-specific;if-exceeding {

bandwidth-limit bps;burst-size-limit bytes;

}then {

discard;}

}family inet {

prefix-action ftp-policer-set {count;destination-prefix-length 32;policer host-policer;subnet-prefix-length 24;

}filter filter-ftp {

term term1{from {

destination-address 10.10.10/24;destination-port ftp;

}then {

prefix-action ftp-policer-set;}

}}

}}

Filter all packets going to the /24 subnet, letting them pass to the prefix-specificaction policers. In the policer set, the last octet of the source address field of thepacket is used to index into the respective prefix-specific action policers.



[edit]firewall {

policer 1Mbps-policer {if-exceeding {

bandwidth-limit 1m;burst-size-limit 63k;

}}family inet {

prefix-action per-source-policer {policer 1Mbps-policer;subnet-prefix-length 24;source-prefix-length 32;

}}filter limit-all-hosts {

term one {from {


}}then prefix-action per-source-policer;

}}

}

In the preceding case, all packets are subjected to the prefix-specific action policing.The last octet of the source address field of the packet is used to index into thecorresponding policer. In other words, all packets ending with 0x(xxxx0000) matchthe first policer and all packets ending in 0x(xxxx0001) match the second policer.

Therefore, 256 policers are created and shared by all addresses. In this case, 10.1.1.1,10.2.2.1, 10.4.5.1 ... 10.x.x.1 share the same 1-Mbps policer; 10.1.1.2, 10.2.2.2,10.4.5.2 ... 10.x.x.2 share another 1-Mbps policer, and so on.

Subject packets belonging to the 10.10.10.0/24 subnet are subject to policing bythe prefix-specific action policers. Because 128 policers defined in the policer set,the /24 subnet can be thought of as being split into two /25 subnets, both of themsharing the same prefix-specific action set. Therefore, 10.10.10.1 and 10.10.10.129share the same 1-Mbps policer, 10.10.10.2 and 10.10.10.130 share another 1-Mbpspolicer, and so on.

[edit]firewall {



}}family inet {

prefix-action per-source-policer {policer 1Mbps-policer;subnet-prefix-length 25;



source-prefix-length 32;}

}filter limit-all-hosts {

term one {from {



}}

}

Define 256 policers based on the last octet of the source address field. However, youare only allowing a subset of that to pass through the match condition. As a result,only the lower half of the set is used.

[edit]firewall {



}}family inet {



term one {from {



}}

}

Accept packets from 10.10.10/24 and 10.11/16 subnets and subject them to policingby the same set of prefix-specific action policers. The policers are shared by packetsacross both subnets. There is a one-to-one correspondence between the 10.10.10/24subnet. For 10.11/16, there is a many-to-one correspondence, as explained in theprevious examples. Each of the 10.11.0/24, 10.11.1/24, 10.11.2/24 ... 10.11.255/24subnets share the same prefix-specific action set.



Thus, 10.10.10.1, 10.11.1.1, 10.11.2.1 ... 10.11.x.1 share the same 1-Mbps policer;10.10.10.2, 10.11.1.2, 10.11.2.2 ... 10.11.x.2 share another 1-Mbps policer, and soon.

[edit]firewall {



}}family inet {



term one {from {

source-address {10.10.10/24;10.11/16;


}}

}

Examples: Classifying Traffic

Classify expedited forwarding traffic:

[edit]firewall {

policer ef-policer {if-exceeding {


}then {

discard;}

}term ef-multifield {

then {loss-priority low;forwarding-class expedited-forwarding;policer ef-policer;

}}

}



Classify assured forwarding traffic:

firewall {policer af-policer {


}then {

loss-priority high;}

}term af-multifield {

then {loss-priority low;forwarding-class assured-forwarding;policer af-policer;

}}

}

Configuring Interface Sets

In addition to including policers in firewall filters, you can configure an interface setthat is not part of a firewall filter configuration. An interface set groups a number ofinterfaces into one interface set name.

To configure an interface set, include the interface-set statement at the [edit firewall]hierarchy level:

[edit firewall]interface-set interface-set-name {

interface-name;}

You must specify more than one interface name to configure an interface set. Thisinterface set can be used for firewall filter matching.

Applying Interface Policers

In addition to including policers in firewall filters, you can apply an interface policerthat is not part of a firewall filter configuration. An interface policer can be appliedto each family on an interface.

To apply an interface policer, include the policer statement at the [edit interfacesinterface-name unit logical-unit-number family family-name] hierarchy level:

[edit interfaces interface-name unit logical-unit-number family family-name]policer {

input policer-name;output policer-name;

}

Configuring Interface Sets ■ 267


You must first configure the policer at the [edit firewall] hierarchy level before youcan apply it to an interface. Both input and output policers are allowed, and can beused in conjunction with existing firewall filters. Input interface policers are evaluatedbefore any input firewall filters. Likewise, output interface policers are evaluatedafter any output firewall filters (see Figure 12 on page 268).

Figure 12: Incoming and Outgoing Interface Policers

To display a policer on a particular interface, issue the show interfaces policerscommand at the command-line interface (CLI).

NOTE: This type of policer can only be applied to unicast packets. For informationon configuring a filter for flooded traffic, see “Applying Filters to Forwarding Tables”on page 325.

Example: Applying an Interface Policer

Apply a policer on circuit cross-connect (CCC) interfaces:

[edit interfaces]so-0/0/0 {

encapsulation ppp-ccc;unit 0 {

family ccc {policer {

input dragnet;}

}}

}

Configuring Aggregate Policers

You can configure a single aggregated policer to limit traffic on the same interfacewithout the use of multiple instances of the same policer. Instead of policing eachaddress family individually on an interface, you can aggregate policing with onepolicer. This single aggregated policer is also known as the logical interface policer.

To configure a logical interface policer, include the logical-interface-policer statementat the [edit firewall policer policer-name] hierarchy level:

logical-interface-policer;

268 ■ Configuring Aggregate Policers


You can configure rate limiting on the logical interface policer. For information onconfiguring rate limiting, see “Configuring Rate Limiting” on page 258. You canconfigure a policer action for the logical interface policer. For information onconfiguring policy actions, see “Configuring Policer Actions” on page 259.

After configuring the aggregated logical interface policer, you can apply the policerto an interface. To apply an aggregated logical interface policer, include the policerpolicer-name option at the [edit interfaces interface-name unit 0 family family-name]hierarchy level:

policer policer-name;

For more information about applying policers, see the JUNOS Class of ServiceConfiguration Guide.

Example: Configuring an Aggregate Policer

Configure an aggregate policer to perform rating limiting:

[edit firewall policer new-police1]if-exceeding {


}logical-interface-policer;then {

discard;}

Apply the aggregate policer to rate-limit IPv4 and IPv6 traffic on interface fe-0/1/1:

[edit interfaces fe-0/1/1 unit 0 family inet]policer new-police1;[edit interfaces fe-0/1/1 unit 0 family inet6]policer new-police1;

Configuring Aggregate Policers ■ 269


Physical Interface Policer Overview

Physical interface policers permit you to configure a single aggregate policer that canbe shared across all the protocol families and logical interfaces configured on aphysical interface. This single policer is referenced in one or more firewall filters,and the filters, whch are defined for a specific protocol family, are then applied toone or more logical interfaces configured on the physical interface. As a result, asingle physical interface policer can apply to multiple routing instances because thatpolicer includes all the logical interfaces and protocol families configured on thephysical interface even if they belong to different instances. This feature is usefulwhen you want to perform aggregate policing for different protocol families anddifferent logical interfaces on the same physical interface. For example, a provideredge (PE) router has numerous logical interfaces, each corresponding to a differentcustomer, configured on the same link to a customer edge (CE) device. A customerwants to apply rate limits aggregately on a single physical interface for certain typesof traffic. A single aggregate policer for the physical interface would include all thelogical interfaces configured and apply to all the routing instances to which thoseinterfaces belong.

Physical interface policing is defined within a firewall filter for each protocol family.The supported protocol families include IPv4, IPv6, VPLS, MPLS, and circuitcross-connect (ccc). The physical interface policer is also applied an action to eachfirewall filter term that references the policer. That firewall filter is then applied ona logical interface as an output or input filter.

The following limitations apply:

■ You cannot apply a firewall filter that references a physical interface policer tological interfaces that do not belong to the physical interface for which the policerhas been defined.

■ You cannot define a firewall filter as both a physical interface filter and as alogical interface filter using the interface-specific statement.

■ You cannot define a firewall filter configured with family any as a physical interfacefilter. A physical interface firewall filter must be defined for a specific protocolfamily.

■ A firewall filer that is defined as physical interface filter must reference a physicalinterface policer. The filter cannot reference policer configured with theinterface-specific statement.

Related Topics ■ Configuring Physical Interface Policers on page 270

Configuring Physical Interface Policers

A physical interface policer defines rate-limiting parameters for all the logical interfacesand protocol families configured on a physical interface. These logical interfaces canbelong to different routing instances. You reference the policer within one or morefirewall filters. You must also apply the physical interface policer as an action foreach term used to define a set of match conditions for traffic on which you want to

270 ■ Physical Interface Policer Overview


perform rate limiting. You apply the firewall filters as input or output filters to thelogical interfaces configured on the physical interface referenced in the policer.

The following sections describe how to configure a physical interface policer, referencethe policer within a firewall filter, apply the policer as an action for a firewall filter,and apply (to a logical interface) a firewall filter that references a physical interfacefilter.

■ Configuring Physical Interface Policers on page 271

■ Configuring Firewall Filters That Reference Physical Interface Policers on page 272

■ Applying Firewall Filters That Reference Physical Interface Policers on page 273

Configuring Physical Interface Policers

To configure a policer for a physical interface:

1. Include the physical-interface-policer statement at the [edit firewall policerpolicer-name] hierarchy level.

2. Include the if-exceeding statement at the [edit firewall policer policer-name] hierarchylevel to define rate-limiting parameters for the policer.

For the if-exceeding statement, you must configure the following parameters:

■ bandwidth-limit bps—Traffic rate, in bits per second (bps)

■ burst-size-limit bytes—Maximum burst size, in bytes

3. Include the then policer-action statement at the [edit firewall policer policer-name]hierarchy level to apply an action to the policer.

For policer-action, you can apply the following:

■ discard—Discard a packet that exceeds the rate limits

■ loss-priority level—Set the loss priority level to low, medium-low, medium-high,high.

■ forwarding-class class-name—Specify the forwarding class for any class-namealready configured.

In the following example, a physical interface policer, shared-police1, is configuredto rate-limit traffic at 10000000000 bps and to permit a maximum burst of trafficof 500000 bytes. The discard action results in the discarding of packets that exceedthe configured rate limits.

[edit]firewall {

policer shared-police1 {physical-interface-policer;if-exceeding {


}then {

Configuring Physical Interface Policers ■ 271


discard;}

}}

Configuring Firewall Filters That Reference Physical Interface Policers

To use a physical interface policer, you must reference it in a firewall filter. For eachfilter, you also configure one or more terms for which you configure match conditionsto define the types of traffic on which you limit traffic. To apply the policer to trafficthat meets the match conditions in a term, you configure the physical interfacepolicer as an action for the term.

To configure a firewall filter that references a physical interface filter:

1. Include the physical-interface-filter statement at the [edit firewall family family-namefilter filter-name] hierarchy level.

NOTE: You cannot specify family any. You must configure a specific protocol familyfor a firewall filter that references a physical interface policer.

2. Include the term term-name statement at the [edit firewall filter family family-namefilter filter-name] hierarchy level to define a term.

3. Include the from match-conditions statement at the [edit firewall family family-namefilter filter-name term term-name] hierarchy level to define the characteristics thatpackets must have to have rate limiting performed as defined in the physicalinterface policer.

For more information about configuring specific match conditions, see“Configuring Match Conditions in Firewall Filter Terms” on page 182.

4. Include the then policer policer-name statement at the [edit firewall familyfamily-name filter filter-name term term-name] hierarchy level to apply the specifiedphysical interface policer as an action for the specified term. The rate-limitingparameters defined in the physical interface policer are performed on any trafficthat matches the conditions defined in the term.

In the following example, a firewall filter is configured that references a physicalinterface filter. The filter is configured with family inet as the protocol family. A termtcp-police-1 is defined to match any IPv4 traffic that is received through TCP with theIP precedence fields critical-ecp, immediate, or priority. IPv4 traffic that matches thesecharacteristics has rate limiting performed, as defined in the shared-police1 policer,which is applied as an action to the term tcp-police-1. A second term, tcp-police-2, isdefined to match IPv4 traffic received through TCP with the IP precedence fieldsinternet-control or routine. IPv4 traffic that matches these characteristics has ratelimiting performed, as defined in the shared-police1 policer, which is applied as anaction to the term tcp-police-2.


filter inet-filter {

272 ■ Configuring Firewall Filters That Reference Physical Interface Policers


physical-interface-filter;term tcp-police-1 {

from {precedence [ critical-ecp immediate priority ];protocol tcp;

}then policer shared-police1;

}term tcp-police-2 {

from {precedence [ internet-control routine ];protocol tcp;

}then policer shared-police1

}}

}

Applying Firewall Filters That Reference Physical Interface Policers

After you configure a firewall filter that references a physical interface policer, youapply it as an input or an output filter to a logical interface.

To apply a firewall filter that references a physical interface policer as an input filter:

■ Include the input filter-name statement at the [edit interfaces interface-name unitlogical-unit-number family family-name filter] hierarchy level.

To apply a firewall filter that references a physical interface policer as an output filter:

■ Include the output filter-name statement at the [edit interfaces interface-name unitlogical-unit-number family family-name] hierarchy level.

In the following example, firewall filter inet-filter is applied to family inet on interfacege-1/2/0.0. The filter is applied to incoming IPv4 traffic on the interface.

[edit]interfaces {

ge-1/2/0 {unit 0 {


input inet-filter;}address 10.100.16.2/24

}}

}}

Applying Firewall Filters That Reference Physical Interface Policers ■ 273


Configuring Bandwidth Policers

The JUNOS Software supports policers that rate-limit traffic based on a percentageof physical port speed on an interface.

A bandwidth policer provides similar rate limiting at the logical interface level. Fora bandwidth policer, the rate-limiting policer is based on a percentage of theconfigured logical interface bandwidth, defined as the shaping rate on that logicalinterface configured with class-of-service statements.

You can configure a policer to limit the bandwidth and apply that policer to multiplelogical interfaces.

To configure a bandwidth policer, include the logical-bandwidth-policer statement atthe [edit firewall policer policer-name] hierarchy level:

logical-bandwidth-policer;

You can configure rate limiting on the logical interface policer. For information aboutconfiguring rate limiting, see “Configuring Rate Limiting” on page 258. You canconfigure a policer action for the logical interface policer. For information aboutconfiguring policy actions, see “Configuring Policer Actions” on page 259.

After configuring the bandwidth policer, you can apply the policer to an interface.To apply a bandwidth policer to a logical interface, include the policer policer-namestatement at the [edit interfaces interface-name unit 0 family family-name] hierarchylevel:

policer (arp | input | output) policer-name;

For more information about applying policers, see the JUNOS Class of ServiceConfiguration Guide.

Example: Configuring a Bandwidth Policer

Configure a bandwidth policer to rate-limit traffic for a logical interface:

[edit firewall policer new-police1]if-exceeding {

bandwidth-percent 10;burst-size-limit 125k;

}logical-bandwidth-policer;then {

discard;}

Apply the bandwidth policer to rate-limit IPv4 and IPv6 traffic on interface fe-0/1/1:

[edit interfaces fe-0/1/1 unit 0 family inet]policer input new-police1;[edit interfaces fe-0/1/1 unit 0 family inet6]

274 ■ Configuring Bandwidth Policers


policer output new-police1;

Configuring Load-Balance Groups

In addition to including policers in firewall filters, you can configure a load-balancegroup that is not part of a firewall filter configuration. A load-balance group containsinterfaces that all use the same next-hop group characteristic to load-balance thetraffic.

To configure a load-balance group, include the load-balance-group statement at the[edit firewall] hierarchy level:

[edit firewall]load-balance-group group-name {

next-hop-group [ group-names ];}

Next-hop groups allow you to include multiple interfaces used to forward duplicatepackets used in port mirroring. For more information about next-hop groups, see“Configuring Next-Hop Groups” on page 329.

Configuring Tricolor Marking

For T Series routers and M320 routers with Enhanced II Flexible PIC Concentrators(FPCs), you can configure single-rate or two-rate tricolor marking (TCM).

TCM extends the functionality of class-of-service (CoS) traffic policing by providingthree levels of drop priority instead of two. This allows you to provision moreenhanced service-level agreements (SLAs) across the Differentiated Services (DiffServ)domain by defining tricolor marking policers, and three levels of packet loss priority(PLP) for classifiers, rewrite rules, random early detection (RED) drop profiles, andfirewall filters.

The color of a packet, as used or set by a tricolor marking policer, corresponds tothe packet’s drop precedence (loss priority or PLP). Packets with high PLP are markedred, packets with medium PLP are marked yellow, and packets with low PLP aremarked green.

The following sections describe tricolor marking policers:

■ Configuring Tricolor Marking Policers on page 275

■ Configuring Interface Policers Using Tricolor Marking Policing on page 277

Configuring Tricolor Marking Policers

A tricolor marking policer polices traffic on the basis of metering, including thecommitted information rate (CIR), the peak information rate (PIR), and their associatedburst sizes.

To configure a tricolor marking policer, include the three-color-policer statement atthe [edit firewall] hierarchy level:

Configuring Load-Balance Groups ■ 275


[edit firewall]three-color-policer (Configuring) name {

single-rate {(color-aware | color-blind);committed-information-rate bps;committed-burst-size bytes;excess-burst-size bytes;

}two-rate {


}}

When you configure this type of policer, you can set up to three loss priorities: low,medium-high, and high.

NOTE: To configure a policer that marks packets so that they have medium-low losspriority, you must configure a policer at the [edit firewall policer policer-name] hierarchylevel.

For example:

[edit firewall]policer 4PLP {


}then loss-priority medium-low;

}

Apply this policer at one or both of the following hierarchy levels:

■ [edit firewall family family filter filter-name term rule-name then policer policer-name]

■ [edit interfaces interface-name unit logical-unit-number family family filter]

Specify the single-rate statement to configure marking based on CIR. If a packetexceeds the CIR in a single-rate policer, it is evaluated by the CBS. Specify thecommitted-burst-size option value to configure the maximum number of bytes allowedfor incoming packets to burst above the CIR, but still be marked green. Specify theexcess-burst-size option value to configure the maximum number of bytes allowedfor incoming packets to burst above the CIR, but be marked red.

Specify the two-rate statement to configure marking based on CIR and PIR. If a packetexceeds the CIR in a two-rate policer, it is evaluated by the PIR. Specify thecommitted-information-rate option value to configure the guaranteed bandwidth undernormal line conditions, and the rate up to which packets are marked green. Specify

276 ■ Configuring Tricolor Marking


the committed-burst-size option value to configure the maximum number of bytesallowed for incoming packets to burst above the CIR, but still be marked green.

Specify the peak-information-rate option value to configure the maximum achievablerate. Packets that exceed the CIR, but are below the PIR, are marked yellow. Packetsthat exceed the PIR are marked red. Specify the peak-burst-size option value toconfigure the maximum number of bytes allowed for incoming packets to burstabove the PIR, but still be marked yellow.

For both the single-rate statement and the two-rate statement, specify the color-awareoption value to configure metering by preclassification. Metering can increase a PLP,but cannot decrease it. Specify the color-blind option value to ignore anypreclassification.

For more information about tricolor marking, see the JUNOS Class of ServiceConfiguration Guide.

Example: Configuring a Tricolor Marking Policer

Configure a tricolor policer:

[edit firewall]three-color-policer trtcm1 {

two-rate {color-blind;committed-information-rate 1048576;committed-burst-size 65536;peak-information-rate 10485760;peak-burst-size 131072;

}}

Apply the tricolor policer to a firewall filter.

[edit firewall]filter fil {

term default {then {

three-color-policer {two-rate trtcm1;

}}

}}

Configuring Interface Policers Using Tricolor Marking Policing

You can configure a policer to limit traffic on an interface in the ingress or egressdirection. Instead of policing each address family individually on an interface, youcan aggregate policing with one policer. This single aggregated policer is known asthe logical-interface policer. You can configure tricolor marking policing to limit thebandwidth through a logical interface.

Configuring Tricolor Marking ■ 277


To configure a policer on a logical interface using tricolor marking policing, includethe action statement and the logical-interface-policer statement at the [edit firewallthree-color-policer name] hierarchy level:

[edit firewall]three-color-policer policer-name {




}two-rate {


}}

For detailed information about bandwidth policers on a logical interface, see“Configuring Aggregate Policers” on page 268.

You can configure separate policing on the ingress and egress direction on the logicalinterface.

Example: Rate-Limiting Bandwidth Using Tricolor Marking Policing

Configure tricolor marking policing on a logical interface to rate-limit the bandwidthon the logical interface.

[edit firewall]three-color-policer trtcm-1 {


}logical-interface-policer;two-rate {

color-blind;committed-information-rate 1500000;committed-burst-size 150k;peak-information-rate 3m;peak-burst-size 300k;

}}

278 ■ Configuring Tricolor Marking


Examples: Configuring Policing

The following example shows a complete filter configuration containing a policer. Itlimits all FTP traffic from a given source to certain rate limits. Traffic exceeding thelimits is discarded, and the remaining traffic is accepted and counted.

[edit]firewall {

policer policer-1 {if-exceeding {


}then {

discard;}

}term tcp-ftp {

from {source-address 10.2.3/24;protocol tcp;destination-port ftp;

}then {

policer policer-1;accept;count count-ftp;

}}

}

The following example shows a complete filter configuration containing two policers,and includes the next term action. Policer policer-1 limits all traffic from a given sourceto certain rate limits, then sets the forwarding class. Policer policer-2 limits all trafficto a second set of rate limits. Traffic exceeding the limits is discarded; the remainingtraffic is accepted.

[edit]firewall {



}then {

forwarding-class 0;}

}policer policer-2 {

if-exceeding {bandwidth-limit 100m;burst-size-limit 100k;

}then {

Examples: Configuring Policing ■ 279


discard;}

}filter f {

term term-1 {then {

policer policer-1;next term;

}}term term-2 {

then {policer policer-2;accept;

}}

}}

The following example limits all FTP traffic from a given source to certain rate limits,but defines the policer outside the filter, thereby creating a template that can bereferenced by more than one filter or more than one term within a filter. Trafficexceeding the limits is discarded, and the remaining traffic is accepted and counted.

[edit]firewall {



}then {

discard;}

}filter limit-ftp {

term tcp-ftp {from {

source-address 10.2.3/24;protocol tcp;destination-port ftp;

}then {

policer policer-1;accept;count count-ftp;

}}

}}

The following example shows a filter intended to thwart denial-of-service (DoS) SYNattacks:

[edit]firewall {

280 ■ Examples: Configuring Policing


policer syn-recvd {if-exceeding {

bandwidth-limit 40k;burst-size-limit 15000;

}then discard;

}term allow-syn {


192.168.12.50/32; # trusted addresses}

}then {

log;accept;

}}term limit-syn {

from {protocol tcp;tcp-initial;

}then {

count limit-syn;policer syn-recvd;accept;

}}term default {

then accept;}

}[edit] # apply filter to lo0 to control traffic to the Routing Engineinterfaces {

lo0 {unit 0 {


input syn-attack;}

}address 172.16.4.53/32;

}}

}

The following example uses one filter to do the following:

■ Stop all User Datagram Protocol (UDP) and Internet Control Message Protocol(ICMP) traffic destined to these addresses (in term a).

■ Send ICMP through the policer (in term b).

■ Accept ICMP traffic within contract and all other traffic (in term c).

Examples: Configuring Policing ■ 281


NOTE: It is important to keep the terms in order; once a packet has a match withinthe firewall filter, it is not examined in subsequent terms. For example, if youconfigured the filter to send ICMP traffic through the policer before discarding ICMPand UDP traffic to the addresses (in term a), you would not get the desired result.

[edit firewall]policer policer-1 {


}then {

loss-priority high;forwarding-class 1;

}}term a {

from {destination-address {

10.126.50.2/23;10.130.12.1/23;10.82.16.0/24 except;10.82.0.3/18;

}protocol [icmp udp];

}then {

count packets-dropped;discard;

}}term b {

from {protocol icmp;

}then policer policer-1;

}term c {

then accept;}

282 ■ Examples: Configuring Policing


Chapter 12

Summary of Firewall Filter and PolicerConfiguration Statements

The following descriptions explain each of the firewall filter and policer configurationstatements. The statements are organized alphabetically.

accounting-profile

Syntax accounting-profile name;

Hierarchy Level [edit firewall family family-name filter filter-name]


Description Enable collection of accounting data for the specified filter.

Options name—Name assigned to the accounting profile.

Usage Guidelines See “Configuring Accounting for Firewall Filters” on page 244.

Required Privilege Level interface—To view this statement in the configuration.interface-control—To add this statement to the configuration.

accounting-profile ■ 283

action

Syntax action {loss-priority high then discard;

}

Hierarchy Level [edit firewall three-color-policer name],[edit logical-systems logical-system-name firewall three-color-policer name]

Release Information Statement introduced in JUNOS Release 8.2.Logical systems support introduced in JUNOS Release 9.3.

Description Discard traffic on a logical interface using tricolor marking policing.

NOTE: This statement is supported only on IQ2 interfaces.

Options The statements are explained separately in this chapter.

Usage Guidelines See “Configuring Interface Policers Using Tricolor Marking Policing” on page 277.


284 ■ action


family

Syntax family family-name {filter filter-name {

accounting-profile name;interface-specific;physical-interface-filter;

}prefix-action name {


}simple-filter filter-name {




}}

}}

Hierarchy Level [edit firewall],[edit logical-systems logical-system-name firewall]

Release Information Statement introduced before JUNOS Release 7.4.Logical systems support introduced in JUNOS Release 9.3.simple-filter statement introduced in JUNOS Release 7.6.any family type introduced in JUNOS Release 8.0.bridge family type introduced in JUNOS Release 8.4 (MX Series routers only).

Description Configure a firewall filter for IP version 4 (IPv4) or IP version 6 (IPv6) traffic. On theMX Series routers only, configure a firewall filter for Layer 2 traffic in a bridgingenvironment.

Options family-name—Version or type of addressing protocol:

■ any—Protocol-independent match conditions.

■ bridge—(MX Series routers only) Layer 2 packets that are part of bridging domain.

■ ccc—Layer 2 switching cross-connects.

■ inet—IPv4 addressing protocol.

■ inet6—IPv6 addressing protocol.

■ mpls—MPLS.

family ■ 285

Chapter 12: Summary of Firewall Filter and Policer Configuration Statements

■ vpls—Virtual private LAN service (VPLS).

The remaining statements are explained separately.

Usage Guidelines See “Configuring the Address Family” on page 179.


filter

Syntax filter filter-name {accounting-profile name;interface-specific;physical-interface-filter;term term-name {

filter filter-name;from {



}}

}

Hierarchy Level [edit firewall family family-name],[edit logical-systems logical-system-name firewall family family-name]

Release Information Statement introduced before JUNOS Release 7.4.Logical systems support introduced in JUNOS Release 9.3.physical-interface-filter statement introduced in JUNOS Release 9.6.

Description Configure firewall filters.

Options filter-name—Name that identifies the filter. The name can contain letters, numbers,and hyphens (-) and can be up to 64 characters long. To include spaces in thename, enclose it in quotation marks (“ ”).


Usage Guidelines See “Configuring Standard Firewall Filters” on page 179.

Required Privilege Level firewall—To view this statement in the configuration.firewall-control—To add this statement to the configuration.

286 ■ filter


filter-specific

Syntax filter-specific;

Hierarchy Level [edit firewall policer policer-name],[edit logical-systems logical-system-name firewall policer policer-name]

Release Information Statement introduced before JUNOS Release 7.4.Logical systems support introduced in JUNOS Release 9.3.

Description Configure a policer to act as a filter-specific policer. If this statement is not specified,then the policer defaults to a term-specific policer.

Usage Guidelines See “Configuring Filter-Specific Policers” on page 261.


firewall

Syntax firewall { ... }

Hierarchy Level [edit],[edit logical-systems logical-system-name]


Description Configure firewall filters.

The statements are explained separately.

Usage Guidelines See “Firewall Filter Configuration” on page 177.


filter-specific ■ 287


if-exceeding

Syntax if-exceeding {bandwidth-limit bps;bandwidth-percent number;burst-size-limit bytes;

}



Description Configure policer rate limits.

Options bandwidth-limit bps—Traffic rate, in bits per second (bps). Any value below 61,040 bpsresults in an effective rate of 30,520 bps.Range: 8000 through 40,000,000,000 bps

NOTE: You can configure a minimum of 8000 bps on the MX Series, M120, andM320 routers only.

Range: 32,000 through 40,000,000,000 bps

NOTE: The minimum value that you can configure on any platform except for theMX Series, M120, and M320 routers is 32,000 bps.

Default: None

bandwidth-percent number—Port speed, in decimal percentage number.Range: 1 through 100Default: None

burst-size-limit bytes—Maximum burst size. The minimum recommended value isthe maximum transmission unit (MTU) of the IP packets being policed.Range: 1500 through 100,000,000,000 bytesDefault: None

Usage Guidelines See “Configuring Rate Limiting” on page 258.


288 ■ if-exceeding


interface-set

Syntax interface-set interface-set-name {interface-name;

}



Description Configure an interface set.

Options interface-name—Names of each interface to include in the interface set. You mustspecify more than one name.

Usage Guidelines See “Configuring Interface Sets” on page 267.


interface-specific

Syntax interface-specific;

Hierarchy Level [edit firewall family family-name filter filter-name],[edit logical-systems logical-system-name firewall family family-name filter filter-name]


Description Configure interface-specific names for firewall counters.

Usage Guidelines See “Configuring Interface-Specific Counters” on page 217.


interface-set ■ 289


load-balance-group

Syntax load-balance-group group-name {next-hop-group [ group-names ];

}

Hierarchy Level [edit firewall]


Description Configure a load-balance group.

Options group-name—Name of load-balance group.

group-names—Name of next-hop groups to include in the load-balance group set.

Usage Guidelines See “Configuring Load-Balance Groups” on page 275.


logical-bandwidth-policer

Syntax logical-bandwidth-policer;



Description Extend the policer rate limits to logical interfaces. The policer rate limit is based onthe shaping rate defined on the logical interface.

Usage Guidelines See “Configuring Bandwidth Policers” on page 274.


290 ■ load-balance-group


logical-interface-policer

Syntax logical-interface-policer;

Hierarchy Level [edit firewall policer policer-name],[edit firewall three-color-policer name],[edit logical-systems logical-system-name firewall policer policer-name],[edit logical-systems logical-system-name firewall three-color-policer name]

Release Information Statement introduced before JUNOS Release 7.4.Support at the [edit firewall three-color-policer name] hierarchy level introduced inJUNOS Release 8.2.Logical systems support introduced in JUNOS Release 9.3.

Description Configure an aggregate policer.

Usage Guidelines See “Configuring Aggregate Policers” on page 268 and “Configuring Tricolor Marking”on page 275.


physical-interface-filter

Syntax physical-interface-filter;

Hierarchy Level [edit firewall family family-name filter filter-name],[edit logical-systems logical-system-name firewall family family-name filter filter-name],[edit routing-instances routing-instance-name firewall family family-name filter filter-name],[edit logical-systems logical-system-name routing-instances routing-instance-name firewall

family family-name filter filter-name]


Description Configure a physical-interface filter. Use this statement to reference aphysical-interface policer for the specified protocol family.

Usage Guidelines See “Configuring Physical Interface Policers” on page 270


Related Topics physical-interface-policer, policer

logical-interface-policer ■ 291


physical-interface-policer

Syntax physical-interface-policer;

Hierarchy Level [edit firewall policer policer-name],[edit logical-system logical-system-name firewall policer policer-name],[edit routing-instances routing-instance-name firewall policer policer-name],[edit logical-systems logical-system-name routing-instances routing-instance-name firewall

policer policer-name]


Description Configure an aggregate policer for a physical interface. A physical-interface policerapplies to all the logical interfaces and protocol families configured on a physicalinterface. As result, a single physical-interface policer can be applied to multiplerouting instances because this policer includes all the logical interfaces configuredon the physical interface even if they belong to different routing instances.

Usage Guidelines See “Configuring Physical Interface Policers” on page 270


Related Topics physical-interface-filter

292 ■ physical-interface-policer


policer

Syntax policer policer-name {filter-specific;if-exceeding {


}logical-interface-policer;physical-interface-policer;then {

policer-action;}

}


Release Information Statement introduced before JUNOS Release 7.4.Logical systems support introduced in JUNOS Release 9.3.physical-interface-policer statement introduced in JUNOS Release 9.6.

Description Configure policer rate limits and actions. When included at the [edit firewall] hierarchylevel, it creates a template, and you do not have to configure a policer individuallyfor every firewall filter or interface. To activate a policer, you must include the policeraction modifier in the then statement in a firewall filter term or on an interface.

Options policer-action—One or more actions to take:

■ discard—Discard traffic that exceeds the rate limits.

■ forwarding-class class-name—Specify the particular forwarding class.

■ loss-priority—Set the packet loss priority (PLP) to low, medium-low, medium-high,or high.

policer-name—Name that identifies the policer. The name can contain letters, numbers,and hyphens (-), and can be up to 255 characters long. To include spaces in thename, enclose it in quotation marks (“ ”).

then—Actions to take on matching packets.


Usage Guidelines See “Configuring Policers” on page 257.


Related Topics physical-interface-policer

policer ■ 293


prefix-action

Syntax prefix-action name {count;destination-prefix-length prefix-length;policer policer-name;source-prefix-length prefix-length;subnet-prefix-length prefix-length;

}

Hierarchy Level [edit firewall family inet],[edit logical-systems logical-system-name firewall family inet]


Description Configure prefix-specific action.

Options count—Enable counter.

destination-prefix-length prefix-length—Destination prefix length.Range: 0 through 32

policer policer-name—Policer name.

source-prefix-length prefix-length—Source prefix length.Range: 0 through 32

subnet-prefix-length prefix-length—Subnet prefix length.Range: 0 through 32

Usage Guidelines See “Configuring Policer Actions for Specific Address Prefixes” on page 262.


294 ■ prefix-action


service-filter

Syntax service-filter filter-name {term term-name {


}then {


}}

}



Description Configure service filters.

Options filter-name—Name that identifies the service filter. The name can contain letters,numbers, and hyphens (-) and can be up to 255 characters long. To includespaces in the name, enclose it in quotation marks (“ ”).


Usage Guidelines See “Configuring Service Filters” on page 228.

Required Privilege Level firewall—To view this statement in the configuration.firewall-control—To add this statement to the configuration

service-filter ■ 295


simple-filter

Syntax simple-filter filter-name {term term-name {


}then {


}}

}



Description Configure simple filters.

Options filter-name—Name that identifies the simple filter. The name can contain letters,numbers, and hyphens (-), and can be up to 255 characters long. To includespaces in the name, enclose it in quotation marks (“ ”).


Usage Guidelines See “Configuring Simple Filters” on page 229.

Required Privilege Level firewall—To view this statement in the configuration.firewall-control—To add this statement to the configuration

296 ■ simple-filter


term

Syntax term term-name {filter filter-name;from {



}}

Hierarchy Level [edit firewall family family-name filter filter-name],[edit firewall family family-name service-filter filter-name],[edit firewall family family-name simple-filter filter-name],[edit logical-systems logical-system-name firewall family family-name filter filter-name],[edit logical-systems logical-system-name firewall family family-name service-filter

filter-name],[edit logical-systems logical-system-name firewall family family-name simple-filter

filter-name]

Release Information Statement introduced before JUNOS Release 7.4.filter option introduced in JUNOS Release 7.6.Logical systems support introduced in JUNOS Release 9.3.

Description Define a firewall filter term.

Options actions—(Optional) An action to take if conditions match. If you do not specify anaction, the packets that match the conditions in the from statement are accepted.The actions are described in Table 34 on page 210.

action-modifiers—(Optional) One or more actions to perform on a packet. The actionmodifiers are described in Table 34 on page 210.

filter-name—(Optional) A filter within a filter. This term references another filter.

from—(Optional) Match packet fields to values. If not included, all packets areconsidered to match and the actions and action modifiers in the then statementare taken.

match-conditions—One or more conditions to use to make a match. The conditionsare described in Table 24 on page 185, Table 31 on page 201, and Table 32 onpage 204.

term-name—Name that identifies the term. The name can contain letters, numbers,and hyphens (-), and can be up to 64 characters long. To include spaces in thename, enclose it in quotation marks (“ ”).

then—(Optional) Actions to take on matching packets. If not included and a packetmatches all the conditions in the from statement, the packet is accepted.

term ■ 297


Usage Guidelines See “Configuring Standard Firewall Filters” on page 179.


298 ■ term


three-color-policer

See the following sections:

■ three-color-policer (Applying) on page 299

■ three-color-policer (Configuring) on page 300

three-color-policer (Applying)Syntax three-color-policer {

(single-rate | two-rate) policer-name;}

Hierarchy Level [edit firewall family family-name filter filter-name term term-name then],[edit logical-systems logical-system-name firewall family family-name filter filter-name

term term-name then]

Release Information Statement introduced before JUNOS Release 7.4.single-rate statement added in JUNOS Release 8.2.Logical systems support introduced in JUNOS Release 9.3.

Description For T Series routers and M320 routers with Enhanced II Flexible PIC Concentrators(FPCs) and the T640 Core Router with Enhanced Scaling FPC4, apply a tricolormarking policer.

Options single-rate—Named tricolor policer is a single-rate policer.

two-rate—Named tricolor policer is a two-rate policer.

policer-name—Name of a tricolor policer.

Usage Guidelines See “Configuring Actions in Firewall Filter Terms” on page 208.


three-color-policer (Applying) ■ 299


three-color-policer (Configuring)Syntax three-color-policer policer-name {




}two-rate {


}}


Release Information Statement introduced before JUNOS Release 7.4.action statement introduced in JUNOS Release 8.2.Logical systems support introduced in JUNOS Release 9.3.

Description Configure a tricolor marking policer.

Options color-aware—Metering varies by preclassification. Metering can increase a packet'sassigned PLP, but cannot decrease it.

color-blind—Packet preclassification is ignored. All packets are evaluated by the CBS.If a packet exceeds the CBS, it is evaluated by the EBS.

committed-burst-size bytes—Maximum bytes allowed for incoming packets to bemarked green.Range: 1500 through 100,000,000,000 bytes

committed-information-rate bps—Guaranteed bandwidth under normal line conditions,and the average rate up to which packets are marked green.Range: 32,000 through 40,000,000,000 bps

excess-burst-size bytes—Maximum bytes allowed for incoming packets. Packets thatexceed the EBS are marked red.Range: 1500 through 100,000,000,000 bytes

peak-burst-size bytes—Maximum bytes allowed for incoming packets to burst abovethe PIR, but still be marked yellow.Range: 1500 through 100,000,000,000 bytes

300 ■ three-color-policer (Configuring)


peak-information-rate bps—Maximum achievable rate. Packets that exceed the CIRbut are below the PIR are marked yellow. Packets that exceed the PIR are markedred.Range: 32,000 through 40,000,000,000 bps

single-rate—Marking is based on the CIR, CBS, and the EBS.

two-rate—Marking is based on the CIR and the PIR.


Usage Guidelines See “Configuring Tricolor Marking” on page 275.


virtual-channel

Syntax virtual-channel virtual-channel-name;

Hierarchy Level [edit firewall family family-name filter filter-name term term-name then],[edit logical-systems logical-system-name firewall family family-name filter filter-name

term term-name then]


Description For J Series Services Routers only, select the traffic to be transmitted by way of aparticular virtual channel. virtual-channel-name must be one of the names that youdefine at the [edit class-of-service virtual-channels] hierarchy level.

Options virtual-channel-name—Name of the virtual channel.

Usage Guidelines See the JUNOS Class of Service Configuration Guide.


virtual-channel ■ 301


302 ■ virtual-channel


Part 4

Traffic Sampling, Forwarding andMonitoring

■ Traffic Sampling, Forwarding, and Monitoring Overview on page 305

■ Introduction to Traffic Sampling Configuration on page 307

■ Traffic Forwarding and Monitoring Configuration on page 321

■ Extended DHCP Relay Agent Configuration on page 345

■ Summary of Traffic Sampling, Forwarding, and MonitoringConfiguration Statements on page 369

Traffic Sampling, Forwarding and Monitoring ■ 303

304 ■ Traffic Sampling, Forwarding and Monitoring


Chapter 13

Traffic Sampling, Forwarding, andMonitoring Overview

Traffic sampling allows you to sample IP traffic based on particular input interfacesand various fields in the packet header. You can also use traffic sampling to monitorany combination of specific logical interfaces, specific protocols on one or moreinterfaces, a range of addresses on a logical interface, or individual IP addresses.Information about the sampled packets is saved to files on the router's hard disk.

The forwarding policies allow you to configure the per-flow load balancing, portmirroring, and Domain Name System (DNS) or Trivial File Transfer Protocol (TFTP)forwarding. In JUNOS Release 9.0 and later, you can configure per-prefix loadbalancing. This feature enables the router to elect the next hop independent of theroute chosen by other routers. The result is a better utilization of available links.

Traffic sampling and forwarding are supported only on routers equipped with anInternet Processor II application-specific integrated circuit (ASIC). To determinewhether a routing platform has an Internet Processor II ASIC, use the show chassishardware command.

Traffic sampling is not meant to capture all packets received by a router. We do notrecommend excessive sampling (a rate greater than 1/1000 packets), because it canincrease the load on your processor. If you need to set a higher sampling rate todiagnose a particular problem or type of traffic received, we recommend that yourevert to a lower sampling rate after you discover the problem or troublesome traffic.

■ 305

306 ■


Chapter 14

Introduction to Traffic SamplingConfiguration

This chapter describes the following tasks for configuring traffic sampling:

■ Traffic Sampling Configuration on page 307

■ Minimum Traffic Sampling Configuration on page 308

■ Configuring Traffic Sampling on page 309

■ Disabling Traffic Sampling on page 311

■ Configuring the Output File for Traffic Sampling on page 311

■ Tracing Traffic Sampling Operations on page 313

■ Configuring Flow Aggregation (cflowd) on page 313

■ Configuring Active Flow Monitoring Using Version 9 on page 316

■ Traffic Sampling Examples on page 317

■ Example: Sampling a Single SONET/SDH Interface on page 317

■ Example: Sampling All Traffic from a Single IP Address on page 318

■ Example: Sampling All FTP Traffic on page 319

Traffic Sampling Configuration

To configure traffic sampling, include the sampling statement at the[edit forwarding-options] hierarchy level:

[edit forwarding-options]sampling {

disable;input {

family (inet | mpls) {max-packets-per-second number;rate number;run-length number;

}}output {

cflowd hostname {version9 {

template template-name;

Traffic Sampling Configuration ■ 307

}aggregation {

autonomous-system;destination-prefix;protocol-port;source-destination-prefix {

caida-compliant;}source-prefix;

}autonomous-system-type (origin | peer);(local-dump | no-local-dump);port port-number;source-address address;version format;

}file {

disable;filename filename;files number;size bytes;(stamp | no-stamp);(world-readable | no-world-readable);

}flow-active-timeout seconds;flow-inactive-timeout seconds;interface interface-name {

engine-id number;engine-type number;source-address address;

}}traceoptions {

file filename {files number;size bytes;(world-readable | no-world-readable);

}}

}

Minimum Traffic Sampling Configuration

To configure traffic sampling, you must perform at least the following tasks:

1. Create a firewall filter to apply to the logical interfaces being sampled by includingthe filter statement at the [edit firewall family family-name] hierarchy level. In thefilter then statement, you must specify the action modifier sample and the actionaccept.

[edit firewall family]filter filter-name {

term term-name {then {

sample;

308 ■ Minimum Traffic Sampling Configuration


accept;}

}}

2. Apply the filter to the interfaces on which you want to sample traffic:

[edit interfaces]interface-name {

unit logical-unit-number {family family-name {

filter {input filter-name;

}address address {

destination destination-address;}

}}

}

3. Enable sampling and specify a nonzero sampling rate:


input {family inet {

rate number;}

}}

Configuring Traffic Sampling

On routing platforms containing a Monitoring Services PIC or an Adaptive ServicesPIC, you can configure traffic sampling for traffic passing through the routing platform.

To configure traffic sampling on a logical interface, include the input statement atthe [edit forwarding-options sampling] hierarchy level:

[edit forwarding-options sampling]input {

max-packets-per-second number;maximum-packet-length bytes;rate number;run-length number;

}

In JUNOS Release 8.3 and later, you can also configure traffic sampling of MPLStraffic.

Specify the threshold traffic value by using the max-packets-per-second statement.The value is the maximum number of packets to be sampled, beyond which thesampling mechanism begins dropping packets. The range is 0 through 65,535. A

Configuring Traffic Sampling ■ 309

Chapter 14: Introduction to Traffic Sampling Configuration

value of 0 instructs the Packet Forwarding Engine not to sample any packets. Thedefault value is 1000.

NOTE: This statement is not valid for port mirroring.

Specify the maximum length of the sampled packet by using themaximum-packet-length bytes statement. For bytes, specify a value from 0 through9192.

Specify the sampling rate by setting the values for rate and run-length (see Figure 13on page 310).

Figure 13: Configure Sampling Rate

The rate statement specifies the ratio of packets to be sampled. For example, if youconfigure a rate of 10, x number of packets out of every 10 is sampled, wherex=run-length+1. By default, the rate is 0, which means that no traffic is sampled.

The run-length statement specifies the number of matching packets to sample followingthe initial one-packet trigger event. Configuring a run length greater than 0 allowsyou to sample packets following those already being sampled.

If you do not include the input statement, sampling is disabled.

To collect the sampled packets in a file, include the file statement at the [editforwarding-options sampling output] hierarchy level. For more information about theoutput file formats, see “Configuring the Output File for Traffic Sampling” on page311.

You can also send the sampled packets to a specified host using the cflowd version 5and 8 formats or the version 9 format as defined in RFC 3954. For more information,see “Configuring Flow Aggregation (cflowd)” on page 313 and “Configuring ActiveFlow Monitoring Using Version 9” on page 316.

310 ■ Configuring Traffic Sampling


The JUNOS Software does not sample packets originating from the router. If youconfigure a sampling filter and apply it to the output side of an interface, then onlythe transit packets going through that interface are sampled. Packets that are sentfrom the Routing Engine to the Packet Forwarding Engine are not sampled.

When you apply a firewall filter to a loopback interface, the filter might blockresponses from the Monitoring Services PIC. To allow responses from the MonitoringServices PIC to pass through for sampling purposes, configure a term in the firewallfilter to include the Monitoring Services PIC’s IP address. For more detailedinformation about configuring firewall filters, see “Firewall Filter Configuration” onpage 177.

Disabling Traffic Sampling

To explicitly disable traffic sampling on the router, include the disable statement atthe [edit forwarding-options sampling] hierarchy level:

[edit forwarding-options sampling]disable;

Configuring the Output File for Traffic Sampling

You configure traffic sampling results to a file in the /var/tmp directory. To collectthe sampled packets in a file, include the file statement at the [edit forwarding-optionssampling output] hierarchy level:

[edit forwarding-options sampling output]file <disable> filename filename <files number> <size bytes> <stamp | no-stamp>

<world-readable | no-world-readable>;

To configure the period of time before an active flow is exported, include theflow-active-timeout statement at the [edit forwarding-options sampling output family (inet| inet6 | mpls)] hierarchy level:

[edit forwarding-options sampling output family (inet | inet6 | mpls)]flow-active-timeout seconds;

To configure the period of time before a flow is considered inactive, include theflow-inactive-timeout statement at the [edit forwarding-options sampling output] hierarchylevel:

[edit forwarding-options sampling output]flow-inactive-timeout seconds;

To configure the interface that sends out monitored information, include the interfacestatement at the [edit forwarding-options sampling output] hierarchy level:

[edit forwarding-options sampling output]interface interface-name {


}

Disabling Traffic Sampling ■ 311


NOTE: This feature is not supported with the version 9 template format. You mustsend traffic flows collected using version 9 to a server. For more information see“Configuring Active Flow Monitoring Using Version 9” on page 316.

Traffic Sampling Output Format

Traffic sampling output is saved to an ASCII text file. The following is an example ofthe traffic sampling output that is saved to a file in the /var/tmp directory. Each linein the output file contains information for one sampled packet. You can optionallydisplay a timestamp for each line.

The column headers are repeated after each group of 1000 packets.

# Apr 7 15:48:50 Time Dest Src Dest Src Proto TOS Pkt Intf IP TCP

addr addr port port len num frag flagsApr 7 15:48:54 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0Apr 7 15:48:55 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0Apr 7 15:48:56 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0Apr 7 15:48:57 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0Apr 7 15:48:58 192.168.9.194 192.168.9.195 0 0 1 0x0 84 8 0x0 0x0

The output contains the following fields:

■ Time—Time at which the packet was received (displayed only if you include thestamp statement in the configuration)

■ Dest addr—Destination IP address in the packet

■ Src addr—Source IP address in the packet

■ Dest port—Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)port for the destination address

■ Src port—TCP or UDP port for the source address

■ Proto—Packet’s protocol type

■ TOS—Contents of the type-of-service (ToS) field in the IP header

■ Pkt len—Length of the sampled packet, in bytes

■ Intf num—Unique number that identifies the sampled logical interface

■ IP frag—IP fragment number, if applicable

■ TCP flags—Any TCP flags found in the IP header

To set the timestamp option for the file my-sample, enter the following:

[edit forwarding-options sampling output file]user@host# set filename my-sample files 5 size 2m world-readable stamp;

Whenever you toggle the timestamp option, a new header is included in the file. Ifyou set the stamp option, the Time field is displayed.

312 ■ Configuring the Output File for Traffic Sampling


# Apr 7 15:48:50# Time Dest Src Dest Src Proto TOS Pkt Intf IP TCP# addr addr port port len num frag flags# Feb 1 20:31:21# Dest Src Dest Src Proto TOS Pkt Intf IP TCP# addr addr port port len num frag flags

Tracing Traffic Sampling Operations

Tracing operations track all traffic sampling operations and record them in a log filein the /var/log directory. By default, this file is named /var/log/sampled. The defaultfile size is 128 KB, and 10 files are created before the first one gets overwritten.

To trace traffic sampling operations, include the traceoptions statement at the [editforwarding-options sampling] hierarchy level:

[edit forwarding-options sampling]traceoptions {

file <filename> <files number> <size bytes> <world-readable | no-world-readable>;no-remote-trace;

}

Configuring Flow Aggregation (cflowd)

You can collect an aggregate of sampled flows and send the aggregate to a specifiedhost that runs the cflowd application available from the Cooperative Association forInternet Data Analysis (CAIDA) (http://www.caida.org). By using cflowd, you canobtain various types of byte and packet counts of flows through a router.

The cflowd application collects the sampled flows over a period of 1 minute. At theend of the minute, the number of samples to be exported are divided over the periodof another minute and are exported over the course of the same minute.

Before you can perform flow aggregation, the routing protocol process must exportthe autonomous system (AS) path and routing information to the sampling process.To do this, include the route-record statement:

route-record;


■ [edit routing-options]

■ [edit routing-instances routing-instance-name routing-options]

By default, flow aggregation is disabled. To enable the collection of flow aggregates,include the cflowd statement at the [edit forwarding-options sampling output familyfamily-name] hierarchy level:

[edit forwarding-options sampling output family family-name]cflowd hostname {

aggregation {autonomous-system;

Tracing Traffic Sampling Operations ■ 313


destination-prefix;protocol-port;source-destination-prefix {


}autonomous-system-type (origin | peer);(local-dump | no-local-dump);port port-number;source-address address;version format;

}

In the cflowd statement, specify the name, identifier, and source-address of the hostthat collects the flow aggregates. You must also include the UDP port number on thehost and the version, which gives the format of the exported cflowd aggregates. Tospecify an IPv4 source address, include the source-address statement. To collectcflowd records in a log file before exporting, include the local-dump statement. Tospecify the cflowd version number, include the version statement. The cflowd versionis either 5 or 8.

You can specify both host (cflowd) sampling and port mirroring in the sameconfiguration. You can perform RE-sampling and port mirroring actionssimultaneously. However, you cannot perform PIC-sampling and port mirroringactions simultaneously.

To specify aggregation of specific types of traffic, include the aggregation statement.This conserves memory and bandwidth enabling cflowd to export targeted flowsrather than all the aggregated

NOTE: Aggregation is valid only if cflowd version 8 is specified.

To specify a flow type, include the aggregation statement at the [edit forwarding-optionssampling output cflowd hostname] hierarchy level:

[edit forwarding-options sampling output cflowd hostname]aggregation {

source-destination-prefix;}

You specify the aggregation type using one of the following options:

■ autonomous-system—Aggregate by AS number; may require setting the separatecflowd autonomous-system-type statement to include either origin or peer ASnumbers. The origin option specifies to use the origin AS of the packet sourceaddress in the Source Autonomous System cflowd field. The peer option specifiesto use the peer AS through which the packet passed in the Source AutonomousSystem cflowd field. By default, cflowd exports the origin AS number.

■ destination-prefix—Aggregate by destination prefix (only).

314 ■ Configuring Flow Aggregation (cflowd)


■ protocol-port—Aggregate by protocol and port number; requires setting theseparate cflowd port statement.

■ source-destination-prefix—Aggregate by source and destination prefix.Version 2.1b1 of CAIDA’s cflowd application does not record source anddestination mask length values in compliance with CAIDA’s cflowd ConfigurationGuide, dated August 30, 1999. If you configure the caida-compliant statement,the JUNOS Software complies with Version 2.1b1 of cflowd. If you do not includethe caida-compliant statement in the configuration, the JUNOS Software recordssource and destination mask length values in compliance with the cflowdConfiguration Guide.

■ source-prefix—Aggregate by source prefix (only).

Collection of sampled packets in a local ASCII file is not affected by the cflowdstatement.

Debugging cflowd Flow Aggregation

To collect the cflowd flows in a log file before they are exported, include the local-dumpoption at the [edit forwarding-options sampling output cflowd hostname] hierarchy level:

[edit forwarding-options sampling output cflowd hostname]local-dump;

By default, the flows are collected in /var/log/sampled; to change the filename,include the filename statement at the [edit forwarding-options sampling traceoptions]hierarchy level. For more information about changing the filename, see “Configuringthe Output File for Traffic Sampling” on page 311.

NOTE: Because the local-dump option adds extra overhead, you should use it onlywhile debugging cflowd problems, not during normal operation.

The following is an example of the flow information. The AS number exported is theorigin AS number. All flows that belong under a cflowd header are dumped, followedby the header itself:

Jun 27 18:35:43 v5 flow entryJun 27 18:35:43 Src addr: 10.53.127.1 Jun 27 18:35:43 Dst addr: 10.6.255.15 Jun 27 18:35:43 Nhop addr: 192.168.255.240 Jun 27 18:35:43 Input interface: 5Jun 27 18:35:43 Output interface: 3Jun 27 18:35:43 Pkts in flow: 15Jun 27 18:35:43 Bytes in flow: 600 Jun 27 18:35:43 Start time of flow: 7230 Jun 27 18:35:43 End time of flow: 7271 Jun 27 18:35:43 Src port: 26629 Jun 27 18:35:43 Dst port: 179 Jun 27 18:35:43 TCP flags: 0x10 Jun 27 18:35:43 IP proto num: 6 Jun 27 18:35:43 TOS: 0xc0 Jun 27 18:35:43 Src AS: 7018

Configuring Flow Aggregation (cflowd) ■ 315


Jun 27 18:35:43 Dst AS: 11111Jun 27 18:35:43 Src netmask len: 16Jun 27 18:35:43 Dst netmask len: 0

[... 41 more v5 flow entries; then the following header:]

Jun 27 18:35:43 cflowd header:Jun 27 18:35:43 Num-records: 42Jun 27 18:35:43 Version: 5Jun 27 18:35:43 Flow seq num: 118Jun 27 18:35:43 Engine id: 0Jun 27 18:35:43 Engine type: 3

Configuring Active Flow Monitoring Using Version 9

In JUNOS Release 8.3 and later, you can collect a record of sampled flows using theversion 9 format as defined in RFC 3954, Cisco Systems NetFlow Services ExportVersion 9. Version 9 uses templates to collect an set of sampled flows and send therecord to a specified host.

You configure the version 9 template used to collect a record of sampled flows atthe [edit services monitoring] hierarchy level. For more information, see the JUNOSServices Interfaces Configuration Guide and the JUNOS Feature Guide.

To enable the collection of traffic flows using the version 9 format, include the version9statement at the [edit forwarding-options sampling output family family-name cflowdhostname] hierarchy level:

[edit forwarding-options sampling output family family-name cflowd hostname]version9 {

template template-name;}

template-name is the name of the version 9 template configured at the [edit servicesmonitoring] hierarchy level.

You configure traffic sampling at the [edit forwarding-options sampling input] hierarchylevel. In JUNOS Release 8.3 and later, you can configure sampling for MPLS trafficas well as IPv4 traffic. You can define a version 9 flow record template suitable forIPv4 traffic, MPLS traffic, or a combination of the two. In JUNOS Release 9.5 andlater, you can sample sample packets both the inet mpls protocol families at the sametime. For more information about how to configure traffic sampling, see “ConfiguringTraffic Sampling” on page 309.

The following restrictions apply to configuration of the version 9 format:

■ You can configure only one host to collect traffic flows using the version 9 format.Configure the host at the [edit forwarding-options sampling output cflowd hostname]hierarchy level.

■ You cannot specify both the version 9 format and cflowd versions 5 and 8 formatsin the same configuration. For more information about how to configure flowmonitoring using cflowd version 8, see “Configuring Flow Aggregation (cflowd)”on page 313.

316 ■ Configuring Active Flow Monitoring Using Version 9


■ Any values for flow-active-timeout and flow-inactive-timeout that you configure atthe [edit forwarding-options sampling output] hierarchy level are overridden by thevalues configured in the version 9 template.

■ Version 9 does not support Routing Engine-based sampling. You cannot configureversion 9 to send traffic sampling result to a file in the /var/tmp directory.

Example: Configuring Active Flow Monitoring Using Version 9

In this example, you enable active flow monitoring using version 9. You specify atemplate mpls that you configure at [edit services monitoring] hierarchy level. Youalso configure the traffic family mpls to sample.


input {family mpls {

rate 1;run-length;

}}output {

cflowd 10.60.2.1 { # The IP address and port of the hostport 2055; # that collects the sampled traffic flows.source-address 3.3.3.1;version9 {

template mpls; # Version 9 records are sent} # using the template named mpls

}}

Traffic Sampling Examples

The following sections provide examples of configuring traffic sampling:

■ Example: Sampling a Single SONET/SDH Interface on page 317

■ Example: Sampling All Traffic from a Single IP Address on page 318

■ Example: Sampling All FTP Traffic on page 319

Example: Sampling a Single SONET/SDH Interface

The following configuration gathers statistical sampling information from a smallpercentage of all traffic on a single SONET/SDH interface and collects it in a filenamed sonet-samples.txt.

Create the filter:

[edit firewall family inet]filter {

sample-sonet {then {

Traffic Sampling Examples ■ 317


sample;accept;

}}

}

Apply the filter to the SONET/SDH interface:

[edit interfaces]so-0/0/1 {


filter {input sample-sonet;

}address 10.127.68.254/32 {

destination 10.127.74.7;}

}}

}

Finally, configure traffic sampling:



rate 100;run-length 2;

}}output {

file {filename sonet-samples.txt;files 40;size 5m;

}}

}

Example: Sampling All Traffic from a Single IP Address

The following configuration gathers statistical information about every packet enteringthe router on a specific Gigabit Ethernet port originating from a single source IPaddress of 10.45.92.31, and collects it in a file named samples-10-45-92-31.txt.

Create the filter:

[edit firewall family inet]filter one-ip {

term get-ip {from {

source-address 10.45.92.31;}

318 ■ Example: Sampling All Traffic from a Single IP Address


then {sample;accept;

}}

}

Apply the filter to the Gigabit Ethernet interface:

[edit interfaces]ge-4/1/1 {


filter {input one-ip;

}address 10.45.92.254;

}}

}

Finally, gather statistics on all the candidate samples; in this case, gather all statistics:



rate 1;}

}output {

file {filename samples-215-45-92-31.txt;files 100;size 100k;

}}

}

Example: Sampling All FTP Traffic

The following configuration gathers statistical information about a moderatepercentage of packets using FTP in the output path of a specific T3 interface, andcollects the information in a file named t3-ftp-traffic.txt.

Create a filter:

[edit firewall family inet]filter ftp-stats {

term ftp-usage {from {

destination-port [ftp ftp-data];}then {

sample;

Example: Sampling All FTP Traffic ■ 319


accept;}

}}

Apply the filter to the T3 interface:

[edit interfaces]t3-7/0/2 {


filter {input ftp-stats;

}address 10.35.78.254/32 {

destination 10.35.78.4;}

}}

}

Finally, gather statistics on 10 percent of the candidate samples:



rate 10;}

}output {

file {filename t3-ftp-traffic.txt;files 50;size 1m;

}}

}

320 ■ Example: Sampling All FTP Traffic


Chapter 15

Traffic Forwarding and MonitoringConfiguration

This chapter describes the following tasks for configuring forwarding options andtraffic monitoring:

■ Configuring Traffic Forwarding and Monitoring on page 321

■ Applying Filters to Forwarding Tables on page 325

■ Configuring IPv6 Accounting on page 326

■ Configuring Discard Accounting on page 326

■ Configuring Flow Monitoring on page 328

■ Configuring Next-Hop Groups on page 329

■ Per-Flow and Per-Prefix Load Balancing Overview on page 329

■ Configuring Per-Prefix Load Balancing on page 330

■ Configuring Per-Flow Load Balancing Based on Hash Values on page 331

■ Configuring Routers and Interfaces as DHCP and BOOTP Relay Agents on page 331

■ Configuring DNS and TFTP Packet Forwarding on page 333

■ Preventing DHCP Spoofing on MX Series Ethernet Services Routers on page 336

■ Configuring Port Mirroring on page 337

■ Configuring Packet Capture on page 341

Configuring Traffic Forwarding and Monitoring

To configure forwarding options and traffic monitoring, include statements at the[edit forwarding-options] hierarchy level:

[edit forwarding-options]accounting group-name {

output {cflowd [ hostnames ] {

aggregation {autonomous-system;destination-prefix;protocol-port;source-destination-prefix {

caida-compliant;

Configuring Traffic Forwarding and Monitoring ■ 321

}source-prefix;

}autonomous-system-type (origin | peer);port port-number;version format;



}}

}family family-name {

filter {input filter-name;output filter-name;

}route-accounting;

}flood {

input filter-name;}hash-key {

family inet {layer-3;layer-4;

}family mpls {

no-interface-index;label-1;label-2;label-3;no-labels;no-label-1-exp;payload {

ether-pseudowire;ip {



}}

}}family multiservice }

destination-mac;label-1;label-2;payload {

322 ■ Configuring Traffic Forwarding and Monitoring


ip {layer-3-only;

}}source-mac;

}}helpers {

bootp {client-response-ttl;description text-description;interface interface-group {

client-response-ttl number;description text-description;maximum-hop-count number;minimum-wait-time seconds;no-listen;server [ addresses ];

}maximum-hop-count number;minimum-wait-time seconds;server [ addresses ];

}domain {

description text-description;server < [ routing-instance routing-instance-names ] >;interface interface-name {

description text-description;no-listen;server < [ routing-instance routing-instance-names ] >;

}}tftp {



}}traceoptions {

file <filename> <files number> <match regular-expression> <size size><world-readable | no-world readable>;

flag flag;level severity-level;no-remote-trace;

}}load-balance {

indexed-next-hop;per-flow {

hash-seed number;}per-prefix {

hash-seed number;

Configuring Traffic Forwarding and Monitoring ■ 323

Chapter 15: Traffic Forwarding and Monitoring Configuration

}}monitoring group-name {

family inet {output {

cflowd hostname {port port-number;

}export-format cflowd-version-5;flow-active-timeout seconds;flow-export-destination {

cflowd-collector;}flow-inactive-timeout seconds;interface interface-name {

engine-id number;engine-type number;input-interface-index number;output-interface-index number;source-address address;

}}

}}next-hop-group [ group-names ] {

interface interface-name {next-hop [ addresses ];

}}packet-capture {

disable;file filename file-name <files number> <size number> <world-readable |

no-world-readable>;maximum-capture-size bytes;

}port-mirroring {

family (ccc | inet | inet6 | vpls) {output {

interface interface-name {next-hop address;

}no-filter-check;

}input {

maximum-packet-length bytes;rate number;run-length number;

}}traceoptions {

file <filename> <files number> <match regular-expression> <size bytes><world-readable | no-world-readable>;

no-remote-trace;}

}

324 ■ Configuring Traffic Forwarding and Monitoring


Applying Filters to Forwarding Tables

A forwarding table filter allows you to filter data packets based on their componentsand perform an action on packets that match the filter. You can filter on the ingressor egress packets of a forwarding table. You configure the filter at the [edit firewallfamily family-name] hierarchy level; for instructions, see “Configuring ForwardingTable Filters” on page 247.

To apply a forwarding table filter at the ingress of a forwarding table, include thefilter and input statements at the [edit forwarding-options family family-name] hierarchylevel:


input filter-name;}

On the MX Series router only, to apply a forwarding table filter for a virtual switch,include the filter and input statements at the [edit routing-instances routing-instance-namebridge-domains bridge-domain-name forwarding-options] hierarchy level:

[edit routing-instances routing-instance-name bridge-domains bridge-domain-nameforwarding-options]filter {

input filter-name;}

For more information about how to configure a virtual switch, see the JUNOS MX-seriesLayer 2 Configuration Guide.

You can filter based upon destination-class information by configuring a firewall filteron the egress of the forwarding table. By applying firewall filters to packets that havebeen forwarded by a routing table, you can match based on certain parameters thatare decided by the route lookup. For example, routes can be classified into specificdestination and source classes. Firewall filters used for policing and mirroring areable to match based upon these classes.

To apply a firewall filter at the egress of a forwarding table, include the filter andoutput statements at the [edit forwarding-options family family-name] hierarchy level:


output filter-name;}

NOTE: The egress forwarding table filter is applied on the ingress of the Flexible PICConcentrator (FPC). If different packets to the same destination arrive on differentFPCs, they might encounter different policers.

Applying Filters to Forwarding Tables ■ 325


NOTE: You cannot simultaneously include the interface-group statement at the [editfirewall family inet filter filter-name term term-name from] hierarchy level and configurean egress forwarding table filter. The egress forwarding table filter is applied to transitpackets only.

NOTE: The egress forwarding table filter is not supported for the J Series ServicesRouters.

NOTE: In JUNOS Release 8.4 and later, you can no longer configure this outputstatement for VPLS. You can continue to configure ingress forwarding table filterswith the input statement at the [edit forwarding-options family vpls filter] hierarchylevel.

To apply a forwarding table filter to a flood table, include the flood and inputstatements at the [edit forwarding-options family family-name] hierarchy level:

[edit forwarding-options family vpls]flood {

input filter-name;}

NOTE: The flood statement is valid for the vpls address family only.

Configuring IPv6 Accounting

You can configure the routing platform to track IPv6 specific packets and bytespassing through the router.

To enable IPv6 accounting, include the route-accounting statement at the [editforwarding-options family inet6] hierarchy level:

[edit forwarding-options family inet6]route-accounting;

By default, IPv6 accounting is disabled. If IPv6 accounting is enabled, it is disabledafter a reboot of the routing platform. To view IPv6 statistics, issue the show interfacestatistics operational mode command. For more information, see the JUNOS InterfacesCommand Reference.

Configuring Discard Accounting

On routing platforms containing a Monitoring Services PIC or an Adaptive ServicesPIC, you can configure accounting for traffic passing through the routing platform.

326 ■ Configuring IPv6 Accounting


To configure discard accounting, include the accounting statement at the [editforwarding-options] hierarchy level:

[edit forwarding-options]accounting group-name {

output {cflowd [ hostnames ] {






}}

}

To configure an accounting group, include the accounting statement and specify agroup-name. To configure the output flow aggregation, include the cflowd statement.For more information about flow aggregation, see “Configuring Flow Aggregation(cflowd)” on page 313. To configure the interval before exporting an active flow,include the flow-active-timeout statement. The default value for flow-active-timeout is1800 seconds. To configure the interval before a flow is considered inactive, includethe flow-inactive-timeout statement. The default value for flow-inactive-timeout is60 seconds. To configure the interface that sends out monitored information, includethe interface statement. Discard accounting is supported for the Monitoring ServicesPIC only.

When you apply a firewall filter to a loopback interface, the filter might blockresponses from the Monitoring Services PIC. To allow responses from the MonitoringServices PIC to pass through for accounting purposes, configure a term in the firewallfilter to include the Monitoring Services PIC IP address. For more detailed informationabout configuring firewall filters, see “Firewall Filter Configuration” on page 177.

You can use discard accounting for passive and active flow monitoring. For moredetailed information about configuring passive and active flow monitoring, see theJUNOS Feature Guide and the JUNOS Class of Service Configuration Guide.

Configuring Discard Accounting ■ 327


Configuring Flow Monitoring

On routing platforms containing the Monitoring Services PIC or the MonitoringServices II PIC, you can configure flow monitoring for traffic passing through therouting platform. This type of monitoring method is passive monitoring.

To configure flow monitoring, include the monitoring statement at the [editforwarding-options hierarchy level:

[edit forwarding-options]monitoring group-name {

family inet {output {



cflowd-collector;}flow-inactive-timeout seconds;interface interface-name {


}}

}}

To configure a passive monitoring group, include the monitoring statement and specifya group name. To configure monitoring on a specified address family, include thefamily statement and specify an address family. To specify an interface to monitorincoming traffic, include the input statement. To configure the monitoring informationthat is sent out, include the output statement. To configure the output flow aggregation,include the cflowd statement. For more information about flow aggregation, see“Configuring Flow Aggregation (cflowd)” on page 313. To specify the format of themonitoring information sent out, include the export-format statement and specify aversion number. To configure the interval before exporting an active flow, includethe flow-active-timeout statement. The default value for flow-active-timeout is1800 seconds. To enable flow collection, include the flow-export-destination statement.To configure the interval before a flow is considered inactive, include theflow-inactive-timeout statement. The default value for flow-inactive-timeout is 60 seconds.To configure the interface that sends out the monitored information, include theinterface statement. Flow monitoring is supported for Monitoring Services PICinterfaces only.

When you apply a firewall filter to a loopback interface, the filter might blockresponses from the Monitoring Services PIC. To allow responses from the Monitoring

328 ■ Configuring Flow Monitoring


Services PIC to pass through for monitoring purposes, configure a term in the firewallfilter to include the Monitoring Services PIC’s IP address. For more detailedinformation about configuring firewall filters, see “Firewall Filter Configuration” onpage 177.

For more detailed information about configuring passive and active flow monitoring,see the see the JUNOS Feature Guide and the JUNOS Class of Service ConfigurationGuide.

Configuring Next-Hop Groups

Next-hop groups allow you to include multiple interfaces used to forward duplicatepackets used in port mirroring.

To configure a next-hop group, include the next-hop-group statement at the [editforwarding-options] hierarchy level:

[edit forwarding-options]next-hop-group [ group-names ] {

interface interface-name {next-hop [ addresses ];

}}

You can specify one or more group names. To configure the interface that sends outsampled information, include the interface statement and specify an interface. Tospecify a next-hop address to send sampled information, include the next-hopstatement and specify an IP address.

Next-hop groups have the following restrictions:

■ Next-hop groups are supported for M Series routers only.

■ Next-hop groups support up to 16 next-hop addresses.

■ You can configure up to 30 next-hop groups.

■ Each next-hop group must have at least two next-hop addresses.

NOTE: When routes are exported, RIPv2 supports third-party next hops specified inpolicies, such as Virtual Router Redundancy Protocol (VRRP) groups.

Next-hop groups can be used for port mirroring. For more information aboutconfiguring port mirroring, see “Configuring Port Mirroring” on page 337 and theJUNOS Feature Guide.

Per-Flow and Per-Prefix Load Balancing Overview

By default, when there are multiple equal-cost paths to the same destination, theJUNOS Software chooses one of the next-hop addresses at random.

Configuring Next-Hop Groups ■ 329


On all M Series Multiservice Edge Routers, MX Series Ethernet Services Routers, andT Series Core Routers, you have two additional options:

■ You can specify what information the routing platform uses for per-flow loadbalancing based on port data (instead of on source and destination IP addressesonly). For aggregated Ethernet and aggregated SONET/SDH interfaces, you canload-balance based on the MPLS label information. For more information, see“Overview of Per-Packet Load Balancing” on page 144.

■ You can also configure per-prefix load balancing, which allows you to configurea hash value that enables the router to elect a next hop independently of theroute chosen by other routers. For more information, see “Configuring Per-PrefixLoad Balancing” on page 330.

In addition, on the M120, M320, and MX Series routers only, you have the followingoption:

■ You can also configure per-flow load balancing, which allows you to configurethe router to assign a unique, load-balance hash value for each Packet ForwardingEngine slot. For more information, see “Configuring Per-Flow Load BalancingBased on Hash Values” on page 331.

Configuring Per-Prefix Load Balancing

By default, the JUNOS Software uses a hashing method based only on the destinationaddress to elect a forwarding next hop when multiple equal-cost paths are available.As a result, when multiple routers share the same set of forwarding next hops for agiven destination, they can elect the same forwarding next hop.

In JUNOS Release 9.0 and later, you can enable router-specific load balancing byincluding a per-prefix hash value. However, this method applies only to indirect nexthops. In other words, when we have a route with a protocol next hop that is notdirectly connected, it can be resolved over a set of equal-cost forwarding next hops.Only in this case, we use the hashing algorithm to elect a forwarding next hop. Anexample of this is routes learned from an IBGP neighbor. The protocol next hop forthose routes might not be directly reachable and would be resolved through someIGP or static routes. The result could be a set of equal-cost forwarding next hops toreach that protocol next hop. Per-prefix load balancing thus leads to better utilizationof the available links.

To configure per-prefix load balancing. include the load-balance statement at the [editforwarding-options] hierarchy level:

[edit forwarding-options]load-balance {

indexed-next-hop;per-prefix {

hash-seed number;}

}

To enable per-prefix load balancing, you must include the hash-seed numberstatement. The range that you can configure is 0 (the default) through 65,535. If no

330 ■ Configuring Per-Prefix Load Balancing


hash seed is configured, the elected forwarding next hop is the same as in previousreleases.

To generate a permuted index of next-hop entries for unicast and aggregate nexthops, include the indexed-next-hop statement at the [edit forwarding-options load-balance]hierarchy level:

indexed-next-hop;

Configuring Per-Flow Load Balancing Based on Hash Values

By default, the JUNOS Software uses a hashing method based only on the destinationaddress to elect a forwarding next hop when multiple equal-cost paths are available.All Packet Forwarding Engine slots are assigned the same hash value by default.

In JUNOS Release 9.3 and later, you can enable router-specific load balancing byconfiguring the router to assign a unique, load-balance hash value for each PacketForwarding Engine slot.

NOTE: This feature is supported only on M120, M320, and MX Series routers.

To configure per-flow load balancing. include the load-balance statement at the [editforwarding-options] hierarchy level:

[edit forwarding-options]load-balance {

indexed-next-hop;per-flow {

hash-seed;}

}

To enable per-flow load balancing, you must include the hash-seed statement. TheJUNOS Software automatically chooses a value for the hashing algorithm. You cannotconfigure a specific value for the hash-seed statement when you enable per-flow loadbalancing.

Configuring Routers and Interfaces as DHCP and BOOTP Relay Agents

You can configure the router or an interface to act as a Dynamic Host ConfigurationProtocol (DHCP) and Bootstrap Protocol (BOOTP) relay agent. This means that alocally attached host can issue a DHCP or BOOTP request as a broadcast message.If the router or an interface sees this broadcast message, it relays the message to aspecified DHCP or BOOTP server.

You should configure the router or an interface to be a DHCP and BOOTP relay agentif you have locally attached hosts and a distant DHCP or BOOTP server.

To configure the router to act as a DHCP and BOOTP relay agent, include the bootpstatement at the [edit forwarding-options helpers] hierarchy level:

Configuring Per-Flow Load Balancing Based on Hash Values ■ 331


[edit forwarding-options helpers]bootp {

client-response-ttl number;description text-description;interface interface-group {

client-response-ttl number;description text-description;maximum-hop-count number;minimum-wait-time seconds;no-listen;server server-identifier {

<logical-system logical-system-name> <routing-instance [ routing-instance-names]>;

}}maximum-hop-count number;minimum-wait-time seconds;server server-identifier {


}}

To set the description of the BOOTP service, DHCP service, or interface, include thedescription statement.

To set a logical interface or a group of logical interfaces with a specific DHCP relayor BOOTP configuration, include the interface statement.

To set the routing instance of the server to forward, include the routing-instancestatement. You can include as many routing instances as necessary in the samestatement.

To stop packets from being forwarded on a logical interface, a group of logicalinterfaces, or the router, include the no-listen statement.

To set the maximum allowed number in the hops field of the BOOTP header, includethe maximum-hop-count statement. Headers that have a larger number in the hopsfield are not forwarded. If you omit the maximum-hop-count statement, the defaultvalue is 4 hops.

To set the minimum allowed number of seconds in the secs field of the BOOTPheader, include the minimum-wait-time statement. Headers that have a smaller numberin the secs field are not forwarded. The default value for the minimum wait time iszero (0).

To set the IP address or addresses that specify the DHCP or BOOTP server for therouter or interface, include the server statement. You can include as many addressesas necessary in the same statement.

To set an IP time-to-live (TTL) value for DHCP response packets sent a DHCP client,include the client-response-ttl statement.

332 ■ Configuring Routers and Interfaces as DHCP and BOOTP Relay Agents


You can also configure an individual logical interface to be a DHCP and BOOTP relayagent if you have locally attached hosts and a remote DHCP or BOOTP serverconnected to one of the router's interfaces. For more information, see the JUNOSSystem Basics Configuration Guide.

Configuring DNS and TFTP Packet Forwarding

You can configure the router to support Domain Name System (DNS) and Trivial FileTransfer Protocol (TFTP) packet forwarding for IPv4 traffic, which allows clients tosend DNS or TFTP requests to the router. The responding DNS or TFTP serverrecognizes the client address and sends a response directly to that address. By default,the router ignores DNS and TFTP request packets.

To enable DNS or TFTP packet forwarding, include the helpers statement at the[edit forwarding-options] hierarchy level:

[edit forwarding-options]helpers {

domain {description text-description;server < [ routing-instance routing-instance-names ] >;interface interface-name {


}}tftp {



}}

}

To set domain packet forwarding, include the domain statement.

To set the description of the DNS or TFTP service, include the description statement.

To set TFTP packet forwarding, include the tftp statement.

To set a DNS or TFTP server (with an IPv4 address), include the server statement.Use one address for either a global configuration or for each interface.

To set the routing instance of the server to forward, include the routing-instancestatement. You can include as many routing instances as necessary in the samestatement.

To disable recognition of DNS or TFTP requests on one or more interfaces, includethe no-listen statement. If you do not specify at least one interface with this statement,the forwarding service is global to all interfaces on the routing platform.

Configuring DNS and TFTP Packet Forwarding ■ 333



■ Tracing BOOTP, DNS, and TFTP Forwarding Operations on page 334

■ Example: Configuring DNS Packet Forwarding on page 336

Tracing BOOTP, DNS, and TFTP Forwarding Operations

BOOTP, DNS, and TFTP forwarding tracing operations track all BOOTP, DNS, andTFTP operations and record them in a log file. The logged error descriptions providedetailed information to help you solve problems faster.

By default, nothing is traced. If you include the traceoptions statement at the [editforwarding-options helpers] hierarchy level, the default tracing behavior is the following:

■ Important events are logged in a file called fud located in the /var/log directory.

■ When the file fud reaches 128 kilobytes (KB), it is renamed fud.0, then fud.1,and so on, until there are 3 trace files. Then the oldest trace file (fud.2) isoverwritten. (For more information about how log files are created, see the JUNOSSystem Log Messages Reference.)

■ Log files can be accessed only by the user who configures the tracing operation.

You cannot change the directory (/var/log) in which trace files are located. However,you can customize the other trace file settings by including the following statementsat the [edit forwarding-options helpers] hierarchy level:

[edit forwarding-options helpers]traceoptions {

file filename <files number> <match regular-expression> <size size> <world-readable |no-world-readable>;

flag {address;all;config;domain;ifdb;io;main;port;rtsock;tftp;trace;ui;util;

}level severity-level;no-remote-trace;

}

These statements are described in the following sections:

■ Configuring the Log Filename on page 335

■ Configuring the Number and Size of Log Files on page 335

334 ■ Configuring DNS and TFTP Packet Forwarding


■ Configuring Access to the Log File on page 335

■ Configuring a Regular Expression for Lines to Be Logged on page 336

Configuring the Log Filename

By default, the name of the file that records trace output is fud. You can specify adifferent name by including the file filename statement at the [edit forwarding-optionshelpers traceoptions] hierarchy level:

[edit forwarding-options helpers traceoptions]file filename;

Configuring the Number and Size of Log Files

By default, when the trace file reaches 128 kilobytes (KB) in size, it is renamedfilename.0, then filename.1, and so on, until there are three trace files. Then the oldesttrace file (filename.2) is overwritten.

You can configure the limits on the number and size of trace files by including thefollowing statements at the [edit forwarding-options helpers traceoptions] hierarchylevel:

[edit forwarding-options helpers traceoptions]file files number size size;

For example, set the maximum file size to 2 MB, and the maximum number of filesto 20. When the file that receives the output of the tracing operation (filename) reaches2 MB, filename is renamed filename.0, and a new file called filename is created. Whenthe new filename reaches 2 MB, filename.0 is renamed filename.1 and filename isrenamed filename.0. This process repeats until there are 20 trace files. Then theoldest file (filename.19) is overwritten by the newest file (filename.0).

The number of files can be from 2 through 1000 files. The file size of each file canbe from 10 KB through 1 gigabyte (GB).

Configuring Access to the Log File

By default, log files can be accessed only by the user who configures the tracingoperation.

To specify that any user can read all log files, include the world-readable option withthe file statement at the [edit forwarding-options helpers traceoptions] hierarchy level:

[edit forwarding-options helpers traceoptions]file world-readable;

To explicitly set the default behavior, include the no-world-readable option with thefile statement at the [edit forwarding-options helpers traceoptions] hierarchy level:

[edit forwarding-options helpers traceoptions]file no-world-readable;

Configuring DNS and TFTP Packet Forwarding ■ 335


Configuring a Regular Expression for Lines to Be Logged

By default, the trace operation output includes all lines relevant to the logged events.

You can refine the output by including the match option with the file statement atthe [edit forwarding-options helpers traceoptions] hierarchy level and specifying aregular expression (regex) to be matched:

[edit forwarding-options helpers traceoptions]file filename match regular-expression;

Example: Configuring DNS Packet Forwarding

Enable DNS packet request forwarding to all interfaces on the router except t1-1/1/2and t1-1/1/3:

[edit forwarding-options helpers]dns {

server 10.10.10.30;interface {

t1-1/1/2 {no-listen;server 10.10.10.9;

}t1-1/1/3 {

no-listen;server 10.10.10.4;

}}

}

Preventing DHCP Spoofing on MX Series Ethernet Services Routers

A problem that sometimes occurs with DHCP is DHCP spoofing. in which an untrustedclient floods a network with DHCP messages. Often these attacks utilize source IPaddress spoofing to conceal the true source of the attack.

DHCP snooping helps prevent DHCP spoofing by copying DHCP messages to thecontrol plane and using the information in the packets to create anti-spoofing filters.The anti-spoofing filters bind a client’s MAC address to its DHCP-assigned IP addressand use this information to filter spoofed DHCP messages. In a typical topology, acarrier edge router (in this function also referred to as the broadband services router[BSR]) connects the DHCP server and the MX Series router (or broadband servicesaggregator [BSA]) performing the snooping. The MX Series router connects to theclient and the BSR.

DHCP snooping works as follows in the network topology mentioned above:

1. The client sends a DHCP discover message to obtain an IP address from theDHCP server.

2. The BSA intercepts the message and might add option 82 information specifyingthe slot, port, VPI/VCI, and so on.

336 ■ Preventing DHCP Spoofing on MX Series Ethernet Services Routers


3. The BSA then sends the DHCP discover message to the BSR, which converts itto a unicast packet and sends it to the DHCP server.

4. The DHCP server looks up the client’s MAC address and option 82 informationin its database. A valid client is assigned an IP address, which is returned to theclient using a DHCP offer message. Both the BSR and BSA send this messageupstream to the client.

5. The client examines the DHCP offer, and if it is acceptable, issues a DHCP requestmessage that is sent to the DHCP server through the BSA and BSR.

6. The DHCP server confirms that the IP address is still available. If it is, the DHCPserver updates its local tables and sends a DHCP ACK message to the client.

7. The BSR receives the DHCP ACK message and passes the message to the BSA.

8. The BSA creates an anti-spoofing filter by binding the IP address in the ACKmessage to the MAC address of the client. After this point, any DHCP messagesfrom this IP address that are not bound to the client’s MAC address are dropped.

9. The BSA sends the ACK message to the client so that the process of assigning aIP address can be completed.

You configure DHCP snooping by including within a DHCP group the appropriateinterfaces of the BSA:

[edit routing-instances routing-instance-name bridge-domains bridge-domain-nameforwarding-options dhcp-relay groupgroup-name]

interface interface-name;

In a VPLS environment, DHCP requests are forwarded over pseudowires. You canconfigure DHCP snooping over VPLS at the [edit routing-instances routing-instance-name]] hierarchy level.

DHCP snooping works on a per learning bridge basis in bridge domains. Each learningdomain must have an upstream interface configured. This interface acts as the floodport for DHCP requests coming from the client side. DHCP requests are be forwardedacross learning domains in a bridge domain. You can configure DHCP snooping onbridge domains at the [edit routing-instances routing-instance-name bridge-domainsbridge-domain-name] hierarchy level. For an example of DHCP snooping on the MXSeries router, see the JUNOS MX Series Ethernet Services Routers Solutions Guide.

Configuring Port Mirroring

Port mirroring is the ability of a router to send a copy of an IPv4 or IPv6 packet toan external host address or a packet analyzer for analysis. Port mirroring is differentfrom traffic sampling. In traffic sampling, a sampling key based on the packet headeris sent to the Routing Engine. There, the key can be placed in a file, or cflowd packetsbased on the key can be sent to a cflowd server. In port mirroring, the entire packetis copied and sent out through a next-hop interface.

One application for port mirroring sends a duplicate packet to a virtual tunnel. Anext-hop group can then be configured to forward copies of this duplicate packet toseveral interfaces. For more information about next-hop groups, see “ConfiguringNext-Hop Groups” on page 329.

Configuring Port Mirroring ■ 337


All M Series Multiservice Edge Routers, T Series Core Routers, and MX Series EthernetServices Routers support port mirroring for IPv4 or IPv6. The M120, M320, and MXSeries routers support port mirroring for IPv4 and IPv6 simultaneously.

Port mirroring for VPLS traffic is supported on M7i and M10i routers configured withan Enhanced CFEB (CFEB-E), on M120 routers, on M320 routers configured with anEnhanced III Flexible PIC Concentrators (FPCs), and MX Series routers.

Port mirroring for VPLS traffic is supported on M7i and M10i routers configured withEnhanced CFEBs (CFEB-Es), on M120 routers, on M320 routers configured withEnhanced III Flexible PIC Concentrators (FPCs), and MX Series routers.

In JUNOS Release 9.3 and later, port mirroring is supported for Layer 2 traffic on MXSeries routers. For information about how to configure port mirroring for Layer 2traffic, see the JUNOS MX-series Layer 2 Configuration Guide.

In JUNOS Release 9.6 and later, port mirroring is supported for Layer 2 VPN trafficon M120 routers and M320 routers configured with an Enhanced III FPCs. You canalso set the maximum length of the mirrored packet. When set, the mirrored packetis truncated to the specified length.

Configuration Guidelines

When configuring port mirroring, the following restrictions apply:

■ Only transit data is supported.

■ You can configure either IPv4 or IPv6 port mirroring but not both on M Seriesrouters, except for the M120 and M320 routers, which support port mirroringfor IPv4 and IPv6 simultaneously.

■ You can configure port mirroring for IPv4 and IPv6 simultaneously on the M120and M320 routers and the MX Series routers.

■ You cannot configure firewall filters on the port-mirroring interface.

■ You must include a firewall filter with both the accept action and the port-mirroraction modifier on the inbound interface. Port mirroring does not work if youspecify the discard action.

■ The interface you configure for port mirroring should not participate in any kindof routing activity.

■ The destination address you specify should not have a route to the ultimate trafficdestination. For example, if the sampled IPv4 packets have a destination addressof 192.68.9.10 and the port-mirrored traffic is sent to 192.68.20.15 for analysis,the device associated with the latter address should not know a route to192.68.9.10. Also, it should not send the sampled packets back to the sourceaddress.

■ On all routers except the MX Series router, you can configure only oneport-mirroring interface per router. If you include more than one interface in theport-mirroring statement, the previous one is overwritten. MX Series routerssupport more than one port-mirroring interface per router.

338 ■ Configuring Port Mirroring


■ You can configure multiple port mirroring instances on the M120, M320, andMX Series routers.

■ In typical applications, you send the sampled packets to an analyzer or aworkstation for analysis, not to another router. If you must send this traffic overa network, you should use tunnels. For more information about tunnel interfaces,see the JUNOS Network Interfaces Configuration Guide.

Configuring Port Mirroring

To configure port mirroring, include the port-mirroring statement at the [editforwarding-options] hierarchy level:

[edit forwarding-options]port-mirroring {

family (ccc | inet | inet6 | vpls) {output {


}no-filter-check;

}input {


}}

}

Configuring the Port-Mirroring Address Family and Interface

To configure port mirroring, include the port-mirroring statement. To configure theaddress family type of traffic to sample, include the family statement. To configurethe rate of sampling, length of sampling, and the maximum size for the mirroredpacket, include the input statement. To specify on which interface to send duplicatepackets and the next-hop address to send packets, include the output statement. Todetermine whether there are any filters on the specified interface, include theno-filter-check statement.

For information about the rate and run-length statements, see “Configuring TrafficSampling” on page 309.

Configuring Multiple Port-Mirroring Instances

In JUNOS Release 9.5 and later, you can configure multiple port-mirroring instanceson the M120, M320, and MX Series routers. On the M120 router, you can associateeach instance with a specific Forwarding Engine Board (FEB). You cannot associatea port-mirroring instance with an FEB configured as a backup FEB. On the M320router, you can associate each instance with a specific Flexible PIC Concentrator(FPC). Associating a port-mirroring instance with an FPC or an FEB enables you tomirror packets to different destinations. Multiple port-mirroring instances are alsosupported on MX Series routers. For information about configuring multiple

Configuring Port Mirroring ■ 339


port-mirroring instances on MX Series routers, see the JUNOS MX-series Layer 2Configuration Guide.

To configure a port-mirroring instance, include the instance port-mirroring-instancestatement at the [edit forwarding-options port-mirroring] hierarchy level:

[edit forwarding-options port-mirroring]instance port-mirroring-instance-name {

family (inet | inet6 | vpls | ccc) {output {


}no-filter-check;

}}input {


}}

Configuring Port-Mirroring Instances

You can configure multiple port-mirroring instances. Specify a uniqueport-mirroring-instance-name for each instance you configure.

Associating a Port-Mirroring Instance on M320 Routers

You can associate a port-mirroring instance with a specific FPC on an M320 routeror with a specific FEB on an M120 router. You can associate only one port-mirroringinstance with each FPC on an M320 router or with each FEB on an M120 router. Onan M120 router, you cannot associate a port-mirroring instance with a FEB configuredas a backup FEB.

To associate a port-mirroring instance with an FPC on an M320 router, include theport-mirror-instance port-mirroring-instance-name statement at the [edit chassis fpcslot-number] hierarchy level:

[edit chassis]fpc slot-number {

port-mirror-instance port-mirroring-instance-name;}

For slot-number, specify the slot number of the FPC you want to associate with theport-mirroring instance. For port-mirroring-instance-name, specify the name of aport-mirroring instance you configured at the [edit forwarding-options port-mirroring]hierarchy level. For more information about configuring an FPC on an M320 router,see the JUNOS System Basics Configuration Guide.

340 ■ Configuring Port Mirroring


Associating a Port-Mirroring Instance on M120 Routers

To associate a port-mirroring instance with a FEB on an M120 router, include theport-mirror-instance port-mirroring-instance-name statement at the [edit chassis febslot-number] hierarchy level:

[edit chassis]feb slot-number {

port-mirror-instance port-mirroring-instance-name;}

For slot-number, specify the slot number of the FEB you want to associate with theport-mirroring instance. For port-mirroring-instance-name, specify the name of aport-mirroring instance you configured at the [edit forwarding-options port-mirroring]hierarchy level. For information about configuring FEB redundancy on an M120router, see the JUNOS High Availability Configuration Guide. For information aboutconfiguring FPC to FEB connectivity on an M120 router, see the JUNOS System BasicsConfiguration Guide.

Configuring MX Series Ethernet Services Routers and M120 Routers toMirror Traffic Only Once

On MX Series and M120 routers only, you can configure port mirroring so that therouter mirrors traffic only once. If you configure port mirroring on both ingress andegress interfaces, the same packet could be mirrored twice. To mirror packets onlyonce and prevent the router from sending duplicate sampled packets to the samemirroring destination, include the mirror-once statement at the [edit forwarding-optionsport-mirroring] hierarchy level:

[edit forwarding-options port-mirroring]mirror-once;

NOTE: The mirror-once statement is supported only in the global port-mirroringinstance.

Configuring Packet Capture

Packet capture allows you to monitor and analyze offline IP version 4 (IPv4) packetsflowing through a router. Packet capture monitors packet fragments also. Packetcapture can be enabled on any interface and can analyze ingress traffic, egress traffic,or both.

NOTE: Packet capture is supported for the J Series Services Routers only. Packetcapture is not supported on tunnel interfaces. You cannot configure packet captureand sampling at the same time.

Configuring Packet Capture ■ 341


To configure packet capture, include the packet-capture statement at the [editforwarding-options] hierarchy level:

[edit forwarding-options]packet-capture {

disable;file filename file-name <files number> <size number> <world-readable |

no-world-readable>;maximum-capture-size bytes;

}

To disable packet capture, include the disable statement. Packet capture is enabledby default.

You can capture packets into files. Files are classified based on the physical interfacethe packets are captured on (one file per physical interface). You can specify the filename, maximum size, and maximum number of files. When you capture a file namedpcap-file, packet capture creates one file for each physical interface and appends thephysical interface designator to the filename (for example, at). When the file namedpcap-file.xx reaches its maximum size, the file is renamed pcap-file.xx.0. Whenpcap-file.xx reaches its maximum size again, the file is renamed pcap-file.xx.1. Thisprocess continues until the maximum number of files is exceeded. When thathappens, the oldest file is overwritten. The file named pcap-file.xx is always the latestfile. The packet capture file for an interface is created when the first packet is capturedon that interface. Once created, this file is not removed even if packet capture isdisabled on the interface. All packet capture files are stored in the /var/tmp/ directory.

If the PCAP file is deleted from var/tmp/, the file is not recreated upon the next packetcapture traffic on the interface. You must first disable and then enable PCAPfunctionality again to recreate the PCAP file.

To enable capture into files, include the file statement. You can specify the targetfilename, maximum file size, and the maximum number of files. To specify the nameof the target file, include the filename statement. To specify the maximum size ofthe file, include the size statement. To specify the maximum number of files, includethe files statement.

To specify the maximum size of the packet for capture, include themaximum-capture-size statement.

You can capture packets on a specific interface by configuring either of the following:

■ Configure a firewall filter with the action sample and apply it to the interface.

■ Configure sampling on the interface in the ingress or egress traffic.

NOTE: Interface sampling does not capture host-originated packets. Configure firewallfilters to capture host-originated packets.

NOTE: Firewall filter applied to a loopback interface (lo0) affects all packets going toand from the Routing Engine.

342 ■ Configuring Packet Capture


You can capture packets on a specific interface. For information about configuringinterfaces, see the JUNOS Network Interfaces Configuration Guide.

You can capture only specific types of packets by using a firewall filter in conjunctionwith packet capture. To configure packet capture for specific packets using firewallfilters, include the following statements at the [edit firewall] hierarchy level:

[edit firewall]filter filter-name {



sample;accept;

}}

}

NOTE: Configure packet capture with appropriate firewall filters to control the numberof packets captured. Performance of the router may be impacted if packet captureis used without configuring any firewall filters.

NOTE: Packet capture does not support multilink encapsulations (such as MLPPP).

You must disable packet capture to modify encapsulation. To modify the encapsulationon a packet capture-enabled interface, perform the following tasks:

1. Disable packet capture by including the disable statement at the [editforwarding-options packet-capture] hierarchy level.

2. Remove the packet capture file for the interface from the /var/tmp/ directory.

3. Change the encapsulation.

4. Enable packet capture.

For packets captured on T1, T3, E1, E3, SE, and ISDN interfaces in the egressdirection, the size of packets captured can be one byte less than the configured valueof maximum-capture-size because of the PLP byte.

To capture packets on an ISDN interface, configure packet capture on the dialerinterface. To capture packets on the PPPoE interface, configure packet capture onthe PPPoE interface.

Packet capture is not supported with MLPPP encapsulation. However, the CLI doesnot prevent you from enabling packet capture on an interface with MLPPPencapsulation. If packet capture is enabled in the input direction on an interface withMLPPP encapsulation, input packets on that interface are captured on the outputinterfaces.

Configuring Packet Capture ■ 343


By default, there is no tracing operation support for packet capture.

For more information about configuring specific interface types, see the JUNOSNetwork Interfaces Configuration Guide.

344 ■ Configuring Packet Capture


Chapter 16

Extended DHCP Relay AgentConfiguration

The following sections provide an overview and configuration instructions andexamples for the extended DHCP relay agent:

■ Extended DHCP Agent Overview on page 345

■ Interaction Between the DHCP Relay Agent, Clients, and Servers on page 346

■ Access and Access-Internal Routes on page 347

■ Graceful Routing Engine Switchover on page 347

■ Configuring the Extended DHCP Agent on page 348

■ Overriding the Default Configuration for the Extended DHCP RelayAgent on page 350

■ Using Option 60 Information to Forward Client Traffic to Specific DHCPServers on page 352

■ Enabling and Disabling Insertion of Option 82 Information on page 354

■ Configuring Server Groups on page 357

■ Configuring Active Server Groups on page 357

■ Grouping Interfaces with Common DHCP Relay Configuration on page 358

■ Using External AAA Authentication Services with the Extended DHCP RelayAgent on page 359

■ Verifying and Managing Clients of the Extended DHCP Relay Agent on page 360

■ Tracing Extended DHCP Relay Agent Operations on page 360

■ Example: Minimum DHCP Relay Agent Configuration on page 363

■ Example: DHCP Relay Agent Configuration with Multiple Clients andServers on page 364

■ Example: Using Option 60 Strings to Forward DHCP Client Traffic on page 365

■ Example: Using Option 60 Strings to Drop DHCP Client Traffic on page 366

Extended DHCP Agent Overview

You can configure extended DHCP relay options on the router and enable the routerto function as a DHCP relay agent. A DHCP relay agent forwards DHCP request andreply packets between a DHCP client and a DHCP server. You can use DHCP relay

Extended DHCP Agent Overview ■ 345

in carrier edge applications such as video/IPTV to obtain configuration parameters,including an IP address, for your subscribers.

For more information about how to use the DHCP relay agent in a video/IPTVapplication, see the JUNOS Multiplay Solutions Guide.

The following sections provide an overview of the extended DHCP agent:

■ Interaction Between the DHCP Relay Agent, Clients, and Servers on page 346

■ Access and Access-Internal Routes on page 347

■ Graceful Routing Engine Switchover on page 347

Interaction Between the DHCP Relay Agent, Clients, and Servers

In a typical carrier edge network configuration, the DHCP client is on the subscriber’scomputer, and the DHCP relay agent is configured on the router between the DHCPclient and one or more DHCP servers. The following steps describe, at a high level,how the DHCP client, DHCP relay agent, and DHCP server interact in a configurationthat includes two DHCP servers.

NOTE: To prevent DHCP spoofing, you can add to the above hardware configurationan MX Series router. In this configuration, the MX Series router would act as asnooping agent and would be connected to the DHCP relay agent and the client. Formore information about preventing DHCP spoofing, see “Preventing DHCP Spoofingon MX Series Ethernet Services Routers” on page 336

1. The DHCP client sends a discover packet to find a DHCP server in the networkfrom which to obtain configuration parameters for the subscriber, including anIP address.

2. The DHCP relay agent receives the discover packet and forwards copies to eachof the two DHCP servers. The DHCP relay agent then creates an entry in itsinternal client table to keep track of the client’s state.

3. In response to receiving the discover packet, each DHCP server sends an offerpacket to the client. The DHCP relay agent receives the offer packets and forwardsthem to the DHCP client.

4. On receipt of the offer packets, the DHCP client selects the DHCP server fromwhich to obtain configuration information. Typically, the client selects the serverthat offers the longest lease time on the IP address.

5. The DHCP client sends a request packet that specifies the DHCP server fromwhich to obtain configuration information.

6. The DHCP relay agent receives the request packet and forwards copies to eachof the two DHCP servers.

7. The DHCP server requested by the client sends an acknowledgement (ACK)packet that contains the client’s configuration parameters.

8. The DHCP relay agent receives the ACK packet and forwards it to the client.

346 ■ Interaction Between the DHCP Relay Agent, Clients, and Servers


9. The DHCP client receives the ACK packet and stores the configurationinformation.

10. If configured to do so, the DHCP relay agent installs a host route and AddressResolution Protocol (ARP) entry for this client.

11. After establishing the initial lease on the IP address, the DHCP client and theDHCP server use unicast transmission to negotiate lease renewal or release. TheDHCP relay agent “snoops” on all of the packets unicast between the client andthe server that pass through the router to determine when the lease for this clienthas expired or been released. This process is referred to as lease shadowing orpassive snooping.

Access and Access-Internal Routes

The DHCP application uses both access routes and access-internal routes to representeither the end users or the networks behind the attached router. An access routerepresents a network behind an attached router, and is set to a preference of 13. Anaccess-internal route is a /32 route that represents a directly attached end user, andis set to a preference of 12.

To configure import and export of access routes and access-internal routes in arouting policy, include the access and access-internal keywords as match conditionsat the [edit policy-options policy-statement policy-name term term-name from protocol]hierarchy level. For information, see “Example: Importing and Exporting Access andAccess-Internal Routes in a Routing Policy” on page 74.

To display configuration information for access routes and access-internal routes,use the show route extensive, show route protocol access, and show route protocolaccess-internal operational commands. For command syntax and examples, see theJUNOS Routing Protocols and Policies Command Reference.

Graceful Routing Engine Switchover

The extended DHCP local server and the DHCP relay agent applications both maintainthe state of active DHCP client leases in the session database. The extended DHCPapplication can recover this state if the DHCP process fails or is manually restarted,thus preventing the loss of active DHCP clients in either of these circumstances.However, the state of active DHCP client leases is lost if a power failure occurs or ifthe kernel stops operating (for example, when the router is reloaded) on a singleRouting Engine.

The extended DHCP local server and the DHCP relay agent support graceful RoutingEngine switchover on all routing platforms that contain dual Routing Engines. Tosupport graceful Routing Engine switchover, the extended DHCP applicationautomatically mirrors (replicates) information about the state of bound DHCP clientsfrom the master Routing Engine to the backup Routing Engine.

To enable graceful Routing Engine switchover support for the extended DHCP localserver or DHCP relay agent, include the graceful-switchover statement at the [editchassis redundancy] hierarchy level. You cannot disable graceful Routing Engine

Access and Access-Internal Routes ■ 347

Chapter 16: Extended DHCP Relay Agent Configuration

switchover support for the extended DHCP application when the router is configuredto support graceful Routing Engine switchover.

For more information about using graceful Routing Engine switchover, see the JUNOSHigh Availability Configuration Guide.

Related Topics Extended DHCP Local Server Overview■

■ Extended DHCP Relay Agent Overview

Configuring the Extended DHCP Agent

To configure the extended DHCP relay agent on the router, include the dhcp-relaystatement at the [edit forwarding-options] hierarchy level:

[edit forwarding-options]dhcp-relay {

active-server-group server-group-name;authentication {

password password-string;username-include {

circuit-type;delimiter delimiter-character;domain-name domain-name-string;logical-system-name;mac-address;option-60;option-82 [circuit-id] [remote-id];routing-instance-name;user-prefix user-prefix-string;

}}group group-name {

... group-configuration ...}overrides {

always-write-giaddr;always-write-option-82;disable-relay;layer2-unicast-replies;trust-option-82;

}relay-option-60 {

vendor-option {(default-relay-server-group server-group-name | default-local-server-group

local-server-group-name | drop);(equals | starts-with) (ascii match-string | hexadecimal match-hex) {

(relay-server-group server-group-name | local-server-grouplocal-server-group-name | drop);

}}

}relay-option-82 {

circuit-id {

348 ■ Configuring the Extended DHCP Agent


prefix {host-name;logical-system-name;routing-instance-name;

}}

}server-group {

server-group-name {server-ip-address;

}}traceoptions {

file file-name <files number> <match regular-expression> <size maximum-file-size><world-readable | no-world-readable>;

flag flag;no-remote-trace;

}group group-name {




}}interface interface-name <exclude> <upto interface-name>;overrides {

always-write-giaddr;always-write-option-82;layer2-unicast-replies;trust-option-82;disable-relay;

}relay-option-60 {




}}

}relay-option-82 {

circuit-id {prefix {

host-name;

Configuring the Extended DHCP Agent ■ 349


logical-system-name;routing-instance-name;

}}

}}

}

You can include these statements at the following hierarchy levels:

■ [edit forwarding-options]

■ [edit logical-systems logical-system-name forwarding-options]

■ [edit logical-systems logical-system-name routing-instances routing-instance-nameforwarding-options]

■ [edit routing-instances routing-instance-name forwarding-options]

■ [edit routing-instances routing-instance-name bridge-domains bridge-domain-name]

NOTE: The extended DHCP relay agent options configured with the dhcp-relaystatement are incompatible with the DHCP and BOOTP relay agent options configuredwith the bootp statement. As a result, you cannot enable both the extended DHCPrelay agent and the DHCP and BOOTP relay agent on the router at the same time.For information about the DHCP and BOOTP relay agent, see “Configuring Routersand Interfaces as DHCP and BOOTP Relay Agents” on page 331.

Related Topics ■ Overriding the Default Configuration for the Extended DHCP Relay Agent onpage 350

■ Using Option 60 Information to Forward Client Traffic to Specific DHCP Serverson page 352

■ Enabling and Disabling Insertion of Option 82 Information on page 354

■ Configuring Server Groups on page 357

■ Configuring Active Server Groups on page 357

■ Grouping Interfaces with Common DHCP Relay Configuration on page 358

■ Using External AAA Authentication Services with the Extended DHCP Relay Agenton page 359

■ Tracing Extended DHCP Relay Agent Operations on page 360

Overriding the Default Configuration for the Extended DHCP Relay Agent

To override the default configuration settings for the extended DHCP relay agent,include the overrides statement:

overrides {always-write-giaddr;always-write-option-82;layer2-unicast-replies;

350 ■ Overriding the Default Configuration for the Extended DHCP Relay Agent


trust-option-82;disable-relay;

}

To override global DHCP relay agent configuration options, include the overridesstatement and its subordinate statements at the [edit forwarding-options dhcp-relay]hierarchy level. To override DHCP relay agent configuration options for a namedgroup of interfaces, include the statements at the [edit forwarding-options dhcp-relaygroup group-name] hierarchy level.

To remove all DHCP relay agent configuration overrides at a particular hierarchylevel, include the overrides statement with no subordinate statements.

Overwriting giaddr Information

You can configure the DHCP relay agent to change the gateway IP address (giaddr)field in packets that it forwards between a DHCP client and a DHCP server.

To overwrite the giaddr of every DHCP packet with the giaddr of the DHCP relayagent before forwarding the packet to the DHCP server, include the always-write-giaddrstatement.

Overriding Option 82 Information

You can configure the DHCP relay agent to add or remove the DHCP relay agentinformation option (option 82) in DHCP packets.

To override the default option 82 information in DHCP packets destined for a DHCPserver, include the always-write-option-82 statement. The use of this statement causesthe DHCP relay agent to perform one of the following actions, depending on how itis configured:

■ If the DHCP relay agent is configured to add option 82 information to DHCPpackets, it clears the existing option 82 values from the DHCP packets and insertsthe new values before forwarding the packets to the DHCP server.

■ If the DHCP relay agent is not configured to add option 82 information to DHCPpackets, it clears the existing option 82 values from the packets, but does notadd any new values before forwarding the packets to the DHCP server.

NOTE: Option 82 is not supported on MX Series routers.

Using Layer 2 Unicast Transmission for DHCP Packets

To override the setting of the broadcast bit in DHCP request packets and instead usethe Layer 2 unicast transmission method to send DHCP Offer reply packets andDHCP ACK reply packets from the DHCP server to DHCP clients during the discoveryprocess, include the layer2-unicast-replies statement.

Overriding the Default Configuration for the Extended DHCP Relay Agent ■ 351


Trusting Option 82 Information

By default, the DHCP relay agent treats client packets with a giaddr of 0 (zero) andoption 82 information as if they originated at an untrusted source, and drops themwithout further processing. To override this behavior and instead enable the DHCPrelay agent to process DHCP client packets that have a giaddr of 0 (zero) and containoption 82 information, include the trust-option-82 statement.

Disabling DHCP Relay

To disable DHCP relay on specific interfaces in a group, include the disable-relaystatement.

Using Option 60 Information to Forward Client Traffic to Specific DHCP Servers

You can configure the extended DHCP relay agent to use the DHCP vendor classidentifier option (option 60) in DHCP client packets to forward client traffic to specificDHCP servers. This feature is useful in network environments where DHCP clientsaccess services provided by multiple vendors and DHCP servers. For example, aDHCP client might gain Internet access from a particular DHCP server provided byone vendor, and access IPTV service from a different DHCP server provided byanother vendor. The option 60 string enables vendors to include vendor-specificinformation in DHCP client packets.

To use option 60 vendor-specific information to select a DHCP server to which toforward the client packets, include the relay-option-60 statement:

relay-option-60 {vendor-option {

(equals | starts-with) (ascii match-string | hexadecimal match-hex) {(relay-server-group server-group-name |local-server-group local-server-group-name |drop);

}(default-relay-server-group server-group-name |default-local-server-group local-server-group-name |drop);

}}

To configure option 60 support globally, include the relay-option-60 statement andsubordinate statements at the [edit forwarding-options dhcp-relay] hierarchy level. Toconfigure option 60 support for a named group of interfaces, include the relay-option-60statement and subordinate statements at the [edit forwarding-options dhcp-relay groupgroup-name] hierarchy level. You can also configure option 60 support for the extendedDHCP relay agent on a per logical system and per routing instance basis.

Using Matching Option 60 Strings to Process DHCP Client Traffic

Configuring option 60 support helps you manage multivendor networks by enablingthe extended DHCP relay agent to compare option 60 vendor-specific strings received

352 ■ Using Option 60 Information to Forward Client Traffic to Specific DHCP Servers


in DHCP client packets against a list of ASCII or hexadecimal strings that you configureon the router.

The match criteria you configure for the option 60 string-to-DHCP server mappingcan be either of the following:

■ To specify an exact, left-to-right match of the configured match string with theoption 60 string, use the vendor-option equals statement with either the asciistatement (to define a nonempty ASCII match string of 1 through255 alphanumeric characters) or the hexadecimal statement (to define ahexadecimal match string of 1 through 255 hexadecimal characters [0 through 9,a through f, A through F]).

■ To specify a partial match of the configured match string with the option 60string, use the vendor-option starts-with statement with either the ascii statementor the hexadecimal statement. In this case, the option 60 string can contain asuperset of the configured ASCII or hexadecimal string, provided that the leftmostcharacters of the option 60 string entirely match the characters in the configuredmatch string. When you use the starts-with statement, the longest match ruleapplies. For example, the extended DHCP relay agent matches the string“test123” before it matches the string “test”.

If the option 60 string received in the DHCP client packet matches the configuredASCII or hexadecimal string, you can define one of the following actions for theassociated DHCP client packets:

■ To relay client traffic to a group of specific DHCP relay servers that provide therequested client service, use the relay-server-group statement.

The DHCP client packet is relayed to all of the servers specified in the server-groupstatement at the [edit forwarding-options dhcp-relay] hierarchy level that map tothe vendor class identifier information provided in the option 60 string. Toconfigure a named group of DHCP relay servers, which are also referred to asvendor-option servers, include the server-group statement at the [editforwarding-options dhcp-relay] hierarchy level, as described in “Configuring ServerGroups” on page 357.

■ To forward client traffic to a specific extended DHCP local server, use thelocal-server-group statement.

To configure an extended DHCP local server, include the dhcp-local-serverstatement at the [edit system services] hierarchy level. For information aboutconfiguring and using the extended DHCP local server, see the JUNOS SystemBasics Configuration Guide.

■ To drop (discard) the packets, use the drop statement.

Specifying that certain DHCP client packets be dropped can be useful whenDHCP clients request services that are invalid or no longer supported.

The following additional considerations apply when you configure an ASCII orhexadecimal match string:

Using Option 60 Information to Forward Client Traffic to Specific DHCP Servers ■ 353


■ You can configure the same ASCII or hexadecimal match string as both an exact(equals) match and as a partial (starts-with) match. In that case, the exact stringmatch configured with the equals statement takes precedence over the partialstring match configured with the starts-with statement.

■ A server group can contain multiple server addresses and can map to more thanone match string.

■ You can configure an unlimited number of match strings.

■ The use of wildcard attributes in match strings is not supported.

For configuration examples that illustrate how to use matching option 60 strings toforward or drop DHCP client traffic, see “Example: Using Option 60 Strings to ForwardDHCP Client Traffic” on page 365 and “Example: Using Option 60 Strings to DropDHCP Client Traffic” on page 366.

Using Nonmatching Option 60 Strings to Process DHCP Client Traffic

If the option 60 string received in the DHCP client packet does not match theconfigured ASCII or hexadecimal string, you can define one of the following defaultactions for the associated DHCP client packets:

■ To relay client traffic to a default extended DHCP relay server that you specify,use the default-relay-server-group statement.

■ To forward client traffic to a default extended DHCP local server that you specify,use the default-local-server-group statement.

■ To drop (discard) the packets, use the drop statement.

In rare instances, the extended DHCP relay agent might receive a DHCP client packetwith an option 60 string of zero (0) length. In this case, there is nothing in theoption 60 string against which to match. As a result, such packets are treated as ifthey contained nonmatching option 60 strings; that is, they can be relayed to a defaultDHCP relay server, forwarded to a default DHCP extended local server, or dropped.

For configuration examples that illustrate how to use nonmatching option 60 stringsto forward or drop DHCP client traffic, see “Example: Using Option 60 Strings toForward DHCP Client Traffic” on page 365 and “Example: Using Option 60 Strings toDrop DHCP Client Traffic” on page 366.

Displaying a Count of Discarded DHCP Packets with Option 60 Information

To display the number of discarded DHCP client packets containing option 60vendor-specific information, use the show dhcp relay statistics operational command.For information about using this command, see the JUNOS Routing Protocols andPolicies Command Reference.

Enabling and Disabling Insertion of Option 82 Information

To enable or disable insertion of the DHCP relay agent information option (option 82)in packets destined for a DHCP server, include the relay-option-82 statement:

354 ■ Enabling and Disabling Insertion of Option 82 Information


relay-option-82 {circuit-id {


}}

}

To control insertion of option 82 information globally, include the relay-option-82statement and subordinate statements at the [edit forwarding-options dhcp-relay]hierarchy level. To control insertion of option 82 information for a named group ofinterfaces, include the relay-option-82 statement and subordinate statements at the[edit forwarding-options dhcp-relay group group-name] hierarchy level.

To restore the default behavior (option 82 information is not inserted into DHCPpackets), include the relay-option-82 statement with no subordinate statements.

Configuring Agent-Circuit-Id Information

If you use the relay-option-82 statement to enable insertion of option 82 informationin DHCP packets, you must also specify at least the circuit-id statement to include theagent-circuit-id suboption (suboption 1) of the DHCP relay agent information option.

If you specify the circuit-id statement, the format of the agent-circuit id informationfor Fast Ethernet (fe) or Gigabit Ethernet (ge) interfaces is one of the following,depending on your network configuration:

■ For Fast Ethernet or Gigabit Ethernet interfaces that do not use virtual local areanetworks (VLANs) or stacked VLANs (S-VLANs):

(fe | ge)-fpc/pic/port

■ For Fast Ethernet or Gigabit Ethernet interfaces that use VLANs:

(fe | ge)-fpc/pic/port:vlan-id

■ For Fast Ethernet or Gigabit Ethernet interfaces that use S-VLANs:

(fe | ge)-fpc/pic/port:svlan-id-vlan-id

For example, the following is the agent-circuit-id format for a Gigabit Ethernet interfaceon Flexible PIC Concentrator (FPC) 4, PIC 1, port 1 with S-VLAN ID 122 andVLAN ID 500:

ge-4/1/1:122-500

Configuring an Option 82 Prefix

Optionally, you can also include the prefix statement to add a prefix to the baseoption 82 information in DHCP packets destined for a DHCP server.

Enabling and Disabling Insertion of Option 82 Information ■ 355



}

The prefix is separated from the option 82 agent-circuit-id information by a colon(:), and can include any combination of the host-name, logical-system-name, androuting-instance-name options. The DHCP relay agent obtains the values for thehost-name, logical-system-name, and routing-instance-name as follows:

■ If you include the host-name option, the DHCP relay agent uses the hostname ofthe router configured with the host-name statement at the [edit system] hierarchylevel.

■ If you include the logical-system-name option, the DHCP relay agent uses thelogical system name configured with the logical-system statement at the [editlogical-system] hierarchy level.

■ If you include the routing-instance-name option, the DHCP relay agent uses therouting instance name configured with the routing-instance statement at the [editrouting-instances] hierarchy level or at the [edit logical-system logical-system-namerouting-instances] hierarchy level.

If you include the hostname and either or both the logical system name and therouting instance name in the prefix, the hostname is followed by a forward slash (/).If you include both the logical system name and the routing instance name in theprefix, these values are separated by a semicolon (;).

The following examples show several possible formats for the agent-circuit-idinformation when you specify the prefix statement for Fast Ethernet (fe) or GigabitEthernet (ge) interfaces with S-VLANs.

■ If you include only the hostname in the prefix for Fast Ethernet or Gigabit Ethernetinterfaces with S-VLANs:

hostname:(fe | ge)-fpc/pic/port:svlan-id-vlan-id

■ If you include only the logical system name in the prefix for Fast Ethernet orGigabit Ethernet interfaces with S-VLANs:

logical-system-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id

■ If you include only the routing instance name in the prefix for Fast Ethernet orGigabit Ethernet interfaces with S-VLANs:

routing-instance-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id

■ If you include both the hostname and the logical system name in the prefix forFast Ethernet or Gigabit Ethernet interfaces with S-VLANs:

host-name/logical-system-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id

■ If you include both the logical system name and the routing instance name inthe prefix for Fast Ethernet or Gigabit Ethernet interfaces with S-VLANs:

356 ■ Enabling and Disabling Insertion of Option 82 Information


logical-system-name;routing-instance-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id

■ If you include the hostname, logical system name, and routing instance namein the prefix for Fast Ethernet or Gigabit Ethernet interfaces with S-VLANs:

host-name/logical-system-name;routing-instance-name:(fe |ge)-fpc/pic/port:svlan-id-vlan-id

For example, the following is the agent-circuit-id format for a Gigabit Ethernet interfaceon FPC 4, PIC 1, port 1 with S-VLAN ID 122 and VLAN ID 500. In this example, theprefix consists of the hostname router1, the logical system name xyzcorp, and therouting instance name west.

router1/xyzcorp;west:ge-4/1/1:122-500

For Fast Ethernet or Gigabit Ethernet interfaces that use VLANs but not S-VLANs,only the vlan-id value appears in the agent-circuit-id format. For Fast Ethernet orGigabit Ethernet interfaces that do not use VLANs or S-VLANs, neither the vlan-idvalue nor the svlan-id value appears.

Configuring Server Groups

To configure a named group of DHCP server addresses for use by the extended DHCPrelay agent on the router, include the server-group statement at the [editforwarding-options dhcp-relay] hierarchy level:

[edit forwarding-options dhcp-relay]server-group {


}}

You must specify the name of the DHCP server group and the IP addresses of oneor more DHCP servers that belong to this group. You can configure a maximum offive IP addresses per named server group.

Configuring Active Server Groups

Configuring an active server group enables you to apply a common DHCP relay agentconfiguration to a named group of DHCP server addresses. To create an active servergroup, include the active-server-group statement:

active-server-group server-group-name;

To create an active server group as a global DHCP relay agent configuration option,include the active-server-group statement at the [edit forwarding-options dhcp-relay]hierarchy level. To have the group apply only to a named group of interfaces, includethe active-server-group statement at the [edit forwarding-options dhcp-relay dhcp-relaygroup group-name] hierarchy level.

Configuring Server Groups ■ 357


Including the active-server-group statement at the [edit forwarding-options dhcp-relaydhcp-relay group group-name] hierarchy level (as a group-specific option) overrides theeffect of including the active-server-group statement at the [edit forwarding-optionsdhcp-relay] hierarchy level as a global option.

Grouping Interfaces with Common DHCP Relay Configuration

Configuring a DHCP relay group enables you to apply a common DHCP relay agentconfiguration to a named group of interfaces. To configure a group, include the groupstatement at the [edit forwarding-options dhcp-relay] hierarchy level:

[edit forwarding-options dhcp-relay]group group-name {




}}overrides {

always-write-giaddr;always-write-option-82;layer2-unicast-replies;trust-option-82;disable-relay;

}relay-option-60 {




}}

}relay-option-82 {


host-name;logical-system-name;routing-instance-name;

}}

}

358 ■ Grouping Interfaces with Common DHCP Relay Configuration


interface interface-name <exclude> <upto interface-name>;}

Configuring Group-Specific DHCP Relay Options

You can include the following statements at both the [edit forwarding-options dhcp-relaygroup group-name] hierarchy level to set group-specific DHCP relay agent configurationoptions, and at the [edit forwarding-options dhcp-relay] hierarchy level to set globalDHCP relay agent configuration options:

■ active-server-group—Configure an active server group to apply a common DHCPrelay agent configuration to a named group of DHCP server addresses. Forinformation, see “Configuring Active Server Groups” on page 357.

■ authentication—Configure the parameters the router sends to the external AAAserver.

■ overrides—Override the default configuration settings for the extended DHCPrelay agent. For information, see “Overriding the Default Configuration for theExtended DHCP Relay Agent” on page 350.

■ relay-option-60—Use the DHCP vendor class identifier option (option 60) in DHCPclient packets to select a DHCP server to which to forward packets. For moreinformation, see “Using Option 60 Information to Forward Client Traffic toSpecific DHCP Servers” on page 352.

■ relay-option-82—Enable or disable the insertion of option 82 information inpackets destined for a DHCP server. For information, see “Enabling and DisablingInsertion of Option 82 Information” on page 354.

The statements configured at the [edit forwarding-options dhcp-relay group group-name]hierarchy level apply only to the named group of interfaces, and override any globalDHCP relay agent settings configured with the same statements at the [edit dhcp-relaydhcp-relay] hierarchy level.

Enabling the DHCP Relay Agent on Specified Interfaces

To specify the names of one or more interfaces within a specified group on whichthe DHCP relay agent is enabled, include the interface statement at the [editforwarding-options dhcp-relay group group-name] hierarchy level:

[edit forwarding-options dhcp-relay group group-name]interface interface-name;

You can include multiple interface interface-name statements to specify multipleinterfaces within a group, but you cannot specify the same interface in more thanone group.

Using External AAA Authentication Services with the Extended DHCP Relay Agent

Both the extended DHCP local server and the extended DHCP relay agent supportthe use of external AAA authentication services, such as RADIUS, to authenticateDHCP clients. When the extended DHCP local server or relay agent receives a discover

Using External AAA Authentication Services with the Extended DHCP Relay Agent ■ 359


PDU from a client, the extended DHCP application contacts the AAA server toauthenticate the DHCP client. The extended DHCP application can obtain clientaddresses and DHCP configuration options from the external AAA authenticationserver.

The external authentication feature also supports AAA directed logout. If the externalAAA service supports a user log out directive, the extended DHCP relay agent honorsthe logout and views it as if it was requested by a CLI management command. Allof the client state information and allocated resources are deleted at logout. Theextended DHCP relay agent supports directed logout using the list of configuredauthentication servers you specify with the authentication statement at the [editaccess profile profile-name] hierarchy.

You can configure either global authentication support or group-specific support.

You must configure the username-include statement to enable the use ofauthentication. The password statement is not required and does not cause DHCPto use authentication if the username-include statement is not included.

See “Using External AAA Authentication Services” in the JUNOS System BasicsConfiguration Guide for details about configuring external AAA authentication supportfor the DHCP relay agent.

Verifying and Managing Clients of the Extended DHCP Relay Agent

To display address bindings or statistics for extended DHCP relay agent clients onthe router, use the following operational commands:

■ show dhcp relay binding

■ show dhcp relay statistics

To clear address bindings or statistics for DHCP clients, use the following operationalcommands:

■ clear dhcp relay binding

■ clear dhcp relay statistics

For information about using these operational commands, see the JUNOS RoutingProtocols and Policies Command Reference.

Tracing Extended DHCP Relay Agent Operations

The extended DHCP tracing operations track all extended DHCP relay agent operationsand record them in a log file. The logged error descriptions provide detailedinformation to help you solve problems faster.

By default, nothing is traced. If you include the traceoptions statement at the [editforwarding-options dhcp-relay] hierarchy level, the default tracing behavior is thefollowing:

360 ■ Verifying and Managing Clients of the Extended DHCP Relay Agent


■ Important events are logged in a file called jdhcpd located in the /var/log directory.You cannot change the directory (/var/log) in which trace files are located.

■ When the file jdhcpd reaches 128 kilobytes (KB), it is renamed jdhcpd.0, thenjdhcpd.1, and so on, until there are three trace files. Then the oldest trace file(jdhcpd.2) is overwritten. (For more information about how log files are created,see the JUNOS System Log Messages Reference.)

■ Log files can be accessed only by the user who configures the tracing operation.

To trace the extended DHCP relay agent operations, include the traceoptions statementat the [edit forwarding-options dhcp-relay] hierarchy level:

[edit forwarding-options dhcp-relay]traceoptions {

flag all;flag auth;flag database;flag state;flag interface;flag rtsock;flag packet;flag packet-option;flag io;flag ha;flag ui;flag general;flag fwd;flag rpd;flag session-db;file <filename> <files number> <match regular-expression> <size bytes>

<world-readable | no-world-readable>;}

The extended DHCP relay agent traceoptions statements are described in the followingsections:

■ Configuring the Extended DHCP Relay Agent Log Filename on page 361

■ Configuring the Number and Size of Extended DHCP Relay Agent LogFiles on page 362

■ Configuring Access to the Extended DHCP Relay Agent Log File on page 362

■ Configuring a Regular Expression for Extended DHCP Relay Agent Lines to BeLogged on page 362

■ Configuring the Extended DHCP Relay Agent Tracing Flags on page 363

Configuring the Extended DHCP Relay Agent Log Filename

By default, the name of the file that records trace output is jdhcpd. You can specifya different name by including the file statement at the [edit forwarding-options dhcp-relaytraceoptions] hierarchy level:

file filename;

Tracing Extended DHCP Relay Agent Operations ■ 361


Configuring the Number and Size of Extended DHCP Relay Agent Log Files

By default, when the trace file reaches 128 kilobytes (KB) in size, it is renamedfilename.0, then filename.1, and so on, until there are three trace files. Then the oldesttrace file (filename.2) is overwritten.

You can configure the limits on the number and size of trace files by including thefollowing statements at the [edit forwarding-options dhcp-relay traceoptions] hierarchylevel:

file file-name files number size size;

For example, set the maximum file size to 2 MB, and the maximum number of filesto 20. When the file that receives the output of the tracing operation (filename) reaches2 MB, filename is renamed filename.0, and a new file called filename is created. Whenthe new filename reaches 2 MB, filename.0 is renamed filename.1 and filename isrenamed filename.0. This process repeats until there are 20 trace files. Then theoldest file (filename.19) is overwritten by the newest file (filename.0).

The number of files can be from 2 through 1000 files. The file size of each file canbe from 10 KB through 1 gigabyte (GB).

Configuring Access to the Extended DHCP Relay Agent Log File

By default, log files can be accessed only by the user who configures the tracingoperation.

To specify that any user can read all log files, include the file world-readable statementat the [edit forwarding-options dhcp-relay traceoptions] hierarchy level:

file file-name world-readable;

To explicitly set the default behavior, include the file no-world-readable statement atthe [edit forwarding-options dhcp-relay traceoptions] hierarchy level:

file file-name no-world-readable;

Configuring a Regular Expression for Extended DHCP Relay Agent Lines to Be Logged

By default, the trace operation output includes all lines relevant to the logged events.

You can refine the output by including the file match statement at the [editforwarding-options dhcp-relay traceoptions] hierarchy level and specifying a regularexpression (regular-expression) to be matched:

file filename match regular-expression;

362 ■ Tracing Extended DHCP Relay Agent Operations


Configuring the Extended DHCP Relay Agent Tracing Flags

By default, only important events are logged. You can configure the trace operationsto be logged by including the flag statement at the [edit forwarding-options dhcp-relaytraceoptions] hierarchy level:

flag flag;

where flag is one of the following extended DHCP relay agent tracing flags:

■ all—Trace all events

■ auth—Trace authentication events

■ database—Trace database events

■ fwd—Trace firewall process events

■ general—Trace miscellaneous events

■ ha—Trace high availability-related events

■ interface—Trace interface operations

■ io—Trace I/O operations

■ packet—Trace packet decoding operations

■ packet-option—Trace DHCP option decoding operations

■ rpd—Trace routing protocol process events

■ rtsock—Trace routing socket operations

■ session-db—Trace session database events

■ state—Trace changes in state

■ ui—Trace user interface operations

To display the end of the log, issue the show log (jdhcpd | last) operational modecommand:

[edit]user@host# run show log (jdhcpd | last)

Example: Minimum DHCP Relay Agent Configuration

The following example shows the minimum configuration you need to use theextended DHCP relay agent on the router:


server-group {test 10.0.2.1;

}active-server-group test;group all {

Example: Minimum DHCP Relay Agent Configuration ■ 363


interface fe-0/0/2.0;}

}

This example creates a server group and an active server group named test with IPaddress 10.0.2.1. The DHCP relay agent configuration is applied to a group namedall. Within this group, the DHCP relay agent is enabled on interface fe-0/0/2.0.

Example: DHCP Relay Agent Configuration with Multiple Clients and Servers

The following example shows a more complex extended DHCP relay agentconfiguration for a network that includes multiple DHCP clients and DHCP servers.A more detailed explanation follows the example.


server-group {sp-1 {

10.0.2.1;10.0.2.2;

}sp-2 {

10.33.2.1;10.33.2.2;10.33.2.3;

}}active-server-group sp-1;overrides layer2-unicast-replies;group clients_a {

relay-option-82 circuit-id;interface fe-1/0/1.1;interface fe-1/0/1.2;interface fe-1/0/1.3;

}group clients_b {

relay-option-82 {circuit-id {

prefix routing-instance-name;}

}interface fe-1/0/1.4;interface fe-1/0/1.5;interface fe-1/0/1.6;

}group eth_dslam_relay {

active-server-group sp-2;overrides {

trust-option-82;layer2-unicast-replies;

}interface fe-1/0/1.7;interface fe-1/0/1.8;interface fe-1/0/1.9;

}

364 ■ Example: DHCP Relay Agent Configuration with Multiple Clients and Servers


}

This example creates two server-groups: sp-1, which includes DHCP server addresses10.0.2.1 and 10.0.2.2, and sp-2, which includes DHCP server addresses 10.33.2.1,10.33.2.2, and 10.33.2.3. The active server group to which the DHCP relay agentconfiguration applies is sp-1. A global override is set that causes the DHCP relay agentto use Layer 2 unicast transmission to send DHCP reply packets from the DHCPserver to DHCP clients during the discovery process.

The example also creates three groups of subscribers and their associated FastEthernet interfaces: clients_a, clients_b, and eth_dslam_relay. These groups areconfigured to meet different needs, as follows:

■ The clients_a and clients_b groups consist of basic subscribers. The serviceprovider for these groups inserts option 82 information in the DHCP packetsthat are destined for the DHCP server.

■ The subscribers in eth_dslam_relay are connected to an Ethernet digital subscriberline access multiplexer (DSLAM) that functions as a Layer 2 DHCP relay agent.The active server group for eth_dslam_relay is sp-2. Overrides are set for theeth_dslam_relay group that enable the DHCP relay agent to trust option 82information and to use Layer 2 unicast transmission to send DHCP reply packetsto DHCP clients during discovery.

Example: Using Option 60 Strings to Forward DHCP Client Traffic

The following extended DHCP relay agent configuration shows how to use theoption 60 vendor-specific information in DHCP client packets to forward client trafficto specific DHCP servers. A more detailed explanation follows the example.



10.0.2.1;}sp-2 {

10.33.2.1;}sp-3 {

10.22.2.1;}sp-4 {

10.10.2.1;}

}active-server-group sp-1;relay-option-60 {

vendor-option {equals {

ascii motorola {relay-server-group sp-2;

}}

Example: Using Option 60 Strings to Forward DHCP Client Traffic ■ 365


starts-with {hexadecimal ff {

relay-server-group sp-3;}

}default-relay-server-group sp-4;

}}group all {


}

This example defines the following actions for DHCP client packets containingoption 60 information:

■ All packets that contain an exact match with the ASCII string “motorola” arerelayed to server group sp-2.

■ All packets that start with the hexadecimal string “ff” are relayed to server groupsp-3.

■ All packets that do not either exactly match the ASCII string “motorola” or startwith the hexadecimal string “ff” are relayed to the default relay server group,sp-4.

DHCP client packets that do not contain option 60 information are relayed to thecurrently configured active server group, sp-1.

Server groups sp-1, sp-2, sp-3, and sp-4 in this example are configured with theserver-group statement at the [edit forwarding-options dhcp-relay] hierarchy level.

Example: Using Option 60 Strings to Drop DHCP Client Traffic

The following extended DHCP relay agent configuration shows how to use theoption 60 vendor-specific information in DHCP client packets to drop client traffic.Specifying that certain DHCP client packets be dropped can be useful when DHCPclients request services that are invalid or no longer supported.



10.0.2.1;}

}active-server-group sp-1;relay-option-60 {

vendor-option {drop;

}}group all {


366 ■ Example: Using Option 60 Strings to Drop DHCP Client Traffic


}

In this example, all DHCP client packets containing option 60 information arediscarded (dropped), and all packets that do not contain option 60 information arerelayed to the currently configured active server group, sp-1.

Example: Using Option 60 Strings to Drop DHCP Client Traffic ■ 367


368 ■ Example: Using Option 60 Strings to Drop DHCP Client Traffic


Chapter 17

Summary of Traffic Sampling, Forwarding,and Monitoring Configuration Statements

The following sections explain each of the sampling and forwarding statements. Thestatements are organized alphabetically.

■ 369

accounting

Syntax accounting group-name {output {

aggregate-export-interval seconds;cflowd [ hostnames ] {






}}

}

Hierarchy Level [edit forwarding-options]


Description Specify discard accounting instance name and options.


Usage Guidelines See “Configuring Discard Accounting” on page 326.


370 ■ accounting


active-server-group

Syntax active-server-group server-group-name;

Hierarchy Level [edit forwarding-options dhcp-relay],[edit forwarding-options dhcp-relay group group-name],[edit logical-systems logical-system-name forwarding-options dhcp-relay],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name],[edit routing-instances routing-instance-name forwarding-options dhcp-relay],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name]


Description Apply a DHCP relay agent configuration to the named group of DHCP serveraddresses.

You can include the active-server-group statement at the [edit forwarding-optionsdhcp-relay] hierarchy level as a global DHCP relay agent configuration option, or atthe [edit forwarding-options dhcp-relay group group-name] hierarchy level as a DHCPrelay agent configuration option that applies only to a named group of interfaces.

Including the active-server-group statement at the [edit forwarding-options dhcp-relaygroup group-name] hierarchy level as a group-specific option overrides use of theactive-server-group statement at the [edit forwarding-options dhcp-relay] hierarchy levelas a global option.

Options server-group-name—Name of the group of DHCP server addresses to which the DHCPrelay agent configuration applies.

Usage Guidelines See “Configuring the Extended DHCP Agent” on page 348.


active-server-group ■ 371

Chapter 17: Summary of Traffic Sampling, Forwarding, and Monitoring Configuration Statements

aggregation

Syntax aggregation {autonomous-system;destination-prefix;protocol-port;source-destination-prefix {


}

Hierarchy Level [edit forwarding-options accounting output cflowd hostname],[edit forwarding-options sampling output cflowd hostname]


Description For cflowd version 8 only, specify the type of data to be aggregated; cflowd recordsand sends only those flows that match the specified criteria.

Options autonomous-system—Aggregate by autonomous system (AS) number.

caida-compliant—Record source and destination mask length values in compliancewith the Version 2.1b1 release of the cflowd application from the CooperativeAssociation for Internet Data Analysis (CAIDA). If this statement is not configured,the JUNOS Software records source and destination mask length values incompliance with the cflowd Configuration Guide, dated August 30, 1999.

destination-prefix—Aggregate by destination prefix.

protocol-port—Aggregate by protocol and port number.

source-destination-prefix—Aggregate by source and destination prefix.

source-prefix—Aggregate by source prefix.

Usage Guidelines See “Configuring Flow Aggregation (cflowd)” on page 313.


372 ■ aggregation


always-write-giaddr

Syntax always-write-giaddr;

Hierarchy Level [edit forwarding-options dhcp-relay overrides],[edit forwarding-options dhcp-relay group group-name overrides],[edit logical-systems logical-system-name forwarding-options dhcp-relay overrides],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

overrides],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay overrides],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name overrides],[edit routing-instances routing-instance-name forwarding-options dhcp-relay overrides],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name overrides]


Description Overwrite the gateway IP address (giaddr) of every DHCP packet with the gatewayIP address of the DHCP relay agent before forwarding the packet to the DHCP server.



always-write-giaddr ■ 373


always-write-option-82

Syntax always-write-option-82;

Hierarchy Level [edit forwarding-options dhcp-relay overrides],[edit forwarding-options group group-name overrides],[edit logical-systems logical-system-name forwarding-options dhcp-relay overrides],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name






Description Override the DHCP relay agent information option (option 82) in DHCP packetsdestined for a DHCP server. The use of this option causes the DHCP relay agent toperform one of the following actions, depending on how it is configured:

■ If the DHCP relay agent is configured to add option 82 information to DHCPpackets, it clears the existing option 82 values from the DHCP packets and insertsthe new values before forwarding the packets to the DHCP server.

■ If the DHCP relay agent is not configured to add option 82 information to DHCPpackets, it clears the existing option 82 values from the packets, but does notadd any new values before forwarding the packets to the DHCP server.



374 ■ always-write-option-82


authentication

Syntax authentication {password password-string;username-include {


}}




group-name]


Description Configure the parameters the router sends to the external AAA server. A groupconfiguration takes precedence over a global DHCP relay or DHCP local serverconfiguration.


Usage Guidelines See “Using External AAA Authentication Services with the Extended DHCP RelayAgent” on page 359.


authentication ■ 375


autonomous-system-type

Syntax autonomous-system-type (origin | peer);

Hierarchy Level [edit forwarding-options accounting output cflowd hostname],[edit forwarding-options sampling output cflowd hostname]


Description Specify the type of AS numbers that cflowd exports.

Options origin—Export origin AS numbers of the packet source address in the SourceAutonomous System cflowd field.

peer—Export peer AS numbers through which the packet passed in the SourceAutonomous System cflowd field.Default: origin



376 ■ autonomous-system-type


bootp

Syntax bootp {client-response-ttl number;description text-description;interface interface-group {




<logical-system logical-system-name> <routing-instance [ routing-instance-names ]>;}

}

Hierarchy Level [edit forwarding-options helpers]


Description Configures a router or interface to act as a Dynamic Host Configuration Protocol(DHCP) or bootstrap protocol (BOOTP) relay agent.

DHCP relaying is disabled.

Options The remaining statements are explained separately.

Usage Guidelines See “Configuring Routers and Interfaces as DHCP and BOOTP Relay Agents” on page331.


bootp ■ 377


cflowd


■ cflowd (Discard Accounting) on page 378

■ cflowd (Flow Monitoring) on page 379

■ cflowd (Sampling) on page 380

cflowd (Discard Accounting)Syntax cflowd hostname {



}autonomous-system-type (origin | peer);port port-number;source-address address;version format;

}

Hierarchy Level [edit forwarding-options accounting group-name output]


Description Collect an aggregate of sampled flows and send the aggregate to a specified hostsystem that runs the collection utility cfdcollect.

You can configure up to one version 5 and one version 8 flow format at the [editforwarding-options accounting group-name output] hierarchy level.

Options hostname—The IP address or identifier of the host system (the workstation runningthe cflowd utility).




378 ■ cflowd (Discard Accounting)


cflowd (Flow Monitoring)Syntax cflowd hostname {

port port-number;}

Hierarchy Level [edit forwarding-options monitoring group-name family inet output]


Description Collect an aggregate of sampled flows and send the aggregate to a specified hostsystem that runs the collection utility cfdcollect.

You can configure up to eight version 5 flow formats at the [edit forwarding-optionsmonitoring group-name output] hierarchy level. Version 8 flow formats are not supportedfor flow-monitoring applications.

Options hostname—The IP address or identifier of the host system (the workstation runningthe cflowd utility).


Usage Guidelines See “Configuring Flow Monitoring” on page 328.


cflowd (Flow Monitoring) ■ 379


cflowd (Sampling)Syntax cflowd hostname {



}autonomous-system-type (origin | peer);(local-dump | no-local-dump);port port-number;source-address address;version format;version9 {


}

Hierarchy Level [edit forwarding-options sampling output]

Release Information Statement introduced before JUNOS Release 7.4.version9 statement introduced in JUNOS Release 8.3.

Description Collect an aggregate of sampled flows and send the aggregate to a specified hostsystem that runs the collection utility cfdcollect. Specify a host system to collectsampled flows using the version 9 format.

You can configure up to one version 5 and one version 8 flow format at the [editforwarding-options sampling output cflowd hostname] hierarchy level. For the sameconfiguration, you can specify only either version 9 flow record formats or formatsusing versions 5 and 8, not both types of formats.

Options hostname—The IP address or identifier of the host system (the workstation eitherrunning the cflowd utility or collecting traffic flows using version 9.)

You can configure only one host system for version 9.


Usage Guidelines See “Configuring Flow Aggregation (cflowd)” on page 313 and “Configuring ActiveFlow Monitoring Using Version 9” on page 316.


380 ■ cflowd (Sampling)


circuit-id

Syntax circuit-id {prefix {


}}

Hierarchy Level [edit forwarding-options dhcp-relay relay-option-82],[edit forwarding-options dhcp-relay group group-name relay-option-82],[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-82],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

relay-option-82],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay relay-option-82],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name relay-option-82],[edit routing-instances routing-instance-name forwarding-options dhcp-relay relay-option-82],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name relay-option-82]


Description Include the agent-circuit-id suboption (suboption 1) of the DHCP relay agentinformation option (option 82) in DHCP packets destined for a DHCP server.

The format of the agent-circuit-id information for Fast Ethernet or Gigabit Ethernetinterfaces that do not use virtual local area networks (VLANs) or stacked VLANs(S-VLANs) is as follows:

(fe | ge)-fpc/pic/port

The format of the agent-circuit-id information for Fast Ethernet or Gigabit Ethernetinterfaces that use VLANs is as follows:

(fe | ge)-fpc/pic/port:vlan-id

The format of the agent-circuit-id information for Fast Ethernet or Gigabit Ethernetinterfaces that use S-VLANs is as follows:

(fe | ge)-fpc/pic/port:svlan-id-vlan-id

The remaining statement is explained separately.



circuit-id ■ 381


circuit-type

Syntax circuit-type;

Hierarchy Level [edit forwarding-options dhcp-relay authentication username-include],[edit forwarding-options dhcp-relay group group-name authentication username-include],[edit logical-systems logical-system-name forwarding-options dhcp-relay authentication

username-include],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

authentication username-include],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay authentication username-include],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name authentication username-include],[edit routing-instances routing-instance-name forwarding-options dhcp-relay authentication

username-include],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name authentication username-include]


Description Specify that the circuit type be concatenated with the username during the subscriberauthentication process.



client-response-ttl

Syntax client-response-ttl number;

Hierarchy Level [edit forwarding-options helpers bootp],[edit forwarding-options helpers bootp interface interface-group]


Description Set the IP time-to-live (TTL) value in DHCP response packets sent to a DHCP client.

Options number—Decrement amount.Default: None



382 ■ circuit-type


default-local-server-group

Syntax default-local-server-group local-server-group-name;

Hierarchy Level [edit forwarding-options dhcp-relay relay-option-60 vendor-option],[edit forwarding-options dhcp-relay group group-name relay-option-60 vendor-option],[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-60

vendor-option],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

relay-option-60 vendor-option],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay relay-option-60 vendor-option],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name relay-option-60 vendor-option],[edit routing-instances routing-instance-name forwarding-options dhcp-relay relay-option-60

vendor-option],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name relay-option-60 vendor-option]


Description Forward DHCP client packets to a default extended DHCP local server when you usethe DHCP vendor class identifier option (option 60) in DHCP packets to forward clienttraffic to specific DHCP servers.

If the option 60 string received in the DHCP client packet does not match the ASCIIor hexadecimal match string and match criteria (exact match or partial match) thatyou specify, the extended DHCP relay agent forwards the client packets to thespecified default DHCP local server group configured with the dhcp-local-serverstatement at the [edit system services] hierarchy level.

Options local-server-group-name—Name of the default extended DHCP local server group.

Usage Guidelines See “Using Option 60 Information to Forward Client Traffic to Specific DHCP Servers”on page 352.


default-local-server-group ■ 383


default-relay-server-group

Syntax default-relay-server-group server-group-name;

Hierarchy Level [edit forwarding-options dhcp-relay relay-option-60 vendor-option],[edit forwarding-options dhcp-relay group group-name relay-option-60 vendor-option],[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-60

vendor-option],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

relay-option-60 vendor-option],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay relay-option-60 vendor-option],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name relay-option-60 vendor-option],[edit routing-instances routing-instance-name forwarding-options dhcp-relay relay-option-60

vendor-option],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name relay-option-60 vendor-option]


Description Relay DHCP client packets to a default group of extended DHCP relay servers whenyou use the DHCP vendor class identifier option (option 60) in DHCP packets toforward client traffic to specific DHCP servers.

If the option 60 string received in the DHCP client packet does not match the ASCIIor hexadecimal match string and match criteria (exact match or partial match) thatyou specify, the extended DHCP relay agent relays the client packets to the specifieddefault group of servers configured with the server-group statement at the [editforwarding-options dhcp-relay] hierarchy level.

Options server-group-name—Name of the default DHCP relay server group.



384 ■ default-relay-server-group


delimiter

Syntax delimiter delimiter-character;

Hierarchy Level [edit forwarding-options dhcp-relay authentication username-include],[edit forwarding-options dhcp-relay group authentication username-include],[edit logical-systems logical-system-name forwarding-options dhcp-relay authentication








Description Specify the character used as the delimiter between the concatenated componentsof the username. You cannot use the semicolon (;) as a delimiter.



delimiter ■ 385


description

Syntax description text-description;

Hierarchy Level [edit forwarding-options helpers bootp],[edit forwarding-options helpers bootp interface interface-group],[edit forwarding-options helpers domain],[edit forwarding-options helpers domain interface interface-name],[edit forwarding-options helpers tftp],[edit forwarding-options helpers tftp interface interface-name]


Description Description of BOOTP, DHCP, Domain Name System (DNS), or Trivial File TransferProtocol (TFTP) service, or of an interface that is configured for the service.

Usage Guidelines See “Configuring Routers and Interfaces as DHCP and BOOTP Relay Agents” on page331 and “Configuring DNS and TFTP Packet Forwarding” on page 333.


386 ■ description


dhcp-relay


■ dhcp-relay (Extended DHCP Relay Agent) on page 388

■ dhcp-relay (DHCP Spoofing Prevention) on page 391

description ■ 387


dhcp-relay (Extended DHCP Relay Agent)Syntax dhcp-relay {



circuit-type;delimiter delimiter-character;domain-name domain-name-string;logical-system-name;mac-address;option-60;option-82 <circuit-id> <remote-id>;routing-instance-name;user-prefix user-prefix-string;

}}group group-name {

... group-configuration ...}overrides {

always-write-giaddr;always-write-option-82;client-discover-match;disable-relay;interface-client-limit number;layer2-unicast-replies;no-arp;proxy-mode;replace-ip-source-with giaddr;trust-option-82;

}relay-option-60 {



(drop | local-server-group local-server-group-name | relay-server-groupserver-group-name);

}}

}relay-option-82 {



}}

}server-group {


388 ■ dhcp-relay (Extended DHCP Relay Agent)


}}traceoptions {



}group group-name {




}}interface interface-name <exclude> <upto upto-interface-name>;overrides {

always-write-giaddr;always-write-option-82;client-discover-match;disable-relay;interface-client-limit number;layer2-unicast-replies;no-arp;proxy-mode;trust-option-82;

}relay-option-60 {




}}

}relay-option-82 {



}}

}}

dhcp-relay (Extended DHCP Relay Agent) ■ 389


}

Hierarchy Level [edit forwarding-options],[edit logical-systems logical-system-name forwarding-options],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options],[edit routing-instances routing-instance-name forwarding-options]

Release Information Statement introduced in JUNOS Release 8.3.traceoptions option introduced in JUNOS Release 8.5.relay-option-60 option introduced in JUNOS Release 9.0.authentication option introduced in JUNOS Release 9.1.

Description Configure extended Dynamic Host Configuration Protocol (DHCP) relay options onthe router and enable the router to function as a DHCP relay agent. A DHCP relayagent forwards DHCP request and reply packets between a DHCP client and a DHCPserver.

The extended DHCP relay agent options configured with the dhcp-relay statementare incompatible with the DHCP/BOOTP relay agent options configured with thebootp statement. As a result, the extended DHCP relay agent and the DHCP/BOOTPrelay agent cannot both be enabled on the router at the same time.

The extended DHCP relay interacts with the local AAA service framework to useback-end authentication servers, such as RADIUS, to provide subscriber authentication.You can configure authentication support on a global basis or for a specific group ofinterfaces.


Usage Guidelines See “Configuring the Extended DHCP Agent” on page 348 and “Using External AAAAuthentication Services with the Extended DHCP Relay Agent” on page 359.


390 ■ dhcp-relay (Extended DHCP Relay Agent)


dhcp-relay (DHCP Spoofing Prevention)Syntax dhcp-relay {

group group-name {interface interface-name;

}}

Hierarchy Level [edit routing-instances routing-instance-name bridge-domains bridge-domain-nameforwarding-options],

[edit routing-instances routing-instance-name forwarding-options]

Release Information Statement introduced in JUNOS Release 9.4 (MX Series routers only).

Description Configure Dynamic Host Configuration Protocol (DHCP) snooping on the router.When acting as a snooping agent, the MX Series router typically is located betweenthe client and the DHCP relay agent. It creates filters by “snooping” DHCP messagesand binding DHCP-issued IP addresses to the MAC address of the client. These filtershelp prevent DHCP spoofing.

Configure DHCP snooping by including the appropriate interfaces in the DHCP relayconfiguration.


Usage Guidelines See “Preventing DHCP Spoofing on MX Series Ethernet Services Routers” on page336.


disable

Syntax disable;

Hierarchy Level [edit forwarding-options packet-capture],[edit forwarding-options sampling],[edit forwarding-options sampling output file]

Release Information Statement introduced before JUNOS Release 7.4.Supported added at the [edit forwarding-options packet-capture] hierarchy level on JSeries Services Routers in JUNOS Release 7.5.

Description Disable traffic sampling or (on J Series Services Routers) packet capture.

Usage Guidelines See “Disabling Traffic Sampling” on page 311 and “Configuring Packet Capture” onpage 341.


dhcp-relay (DHCP Spoofing Prevention) ■ 391


disable-relay

Syntax disable-relay;







Description Disable DHCP relay on specific interfaces in a group.



392 ■ disable-relay


domain

Syntax domain {description text-description;interface interface-name {

broadcast;description text-description;no-listen;server address <logical-system logical-system-name> <routing-instance

routing-instance-name>;}server address <logical-system logical-system-name> <routing-instance

routing-instance-name>;}



Description Enable DNS request packet forwarding.


Usage Guidelines See “Configuring DNS and TFTP Packet Forwarding” on page 333.


domain ■ 393


domain-name

Syntax domain-name domain-name-string;









Description Specify the domain name that is concatenated with the username during thesubscriber authentication process.

Options domain-name-string—The domain name formatted string.



394 ■ domain-name


drop

Syntax drop;

Hierarchy Level [edit forwarding-options dhcp-relay relay-option-60 vendor-option],[edit forwarding-options dhcp-relay relay-option-60 vendor-option (equals | starts-with)

(ascii match-string | hexadecimal match-hex)],[edit forwarding-options dhcp-relay group group-name relay-option-60 vendor-option],[edit forwarding-options dhcp-relay group group-name relay-option-60 vendor-option (equals

| starts-with) (ascii match-string | hexadecimal match-hex)],[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-60

vendor-option],[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-60

vendor-option (equals | starts-with) (ascii match-string | hexadecimal match-hex)],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

relay-option-60 vendor-option],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

relay-option-60 vendor-option (equals | starts-with) (ascii match-string | hexadecimalmatch-hex)],

[edit logical-systems logical-system-name routing-instances routing-instance-nameforwarding-options dhcp-relay relay-option-60 vendor-option],

[edit logical-systems logical-system-name routing-instances routing-instance-nameforwarding-options dhcp-relay relay-option-60 vendor-option (equals | starts-with) (asciimatch-string | hexadecimal match-hex)],

[edit logical-systems logical-system-name routing-instances routing-instance-nameforwarding-options dhcp-relay group group-name relay-option-60 vendor-option],

[edit logical-systems logical-system-name routing-instances routing-instance-nameforwarding-options dhcp-relay group group-name relay-option-60 vendor-option (equals| starts-with) (ascii match-string | hexadecimal match-hex)],

[edit routing-instances routing-instance-name forwarding-options dhcp-relay relay-option-60vendor-option],

[edit routing-instances routing-instance-name forwarding-options dhcp-relay relay-option-60vendor-option (equals | starts-with) (ascii match-string | hexadecimal match-hex)],

[edit routing-instances routing-instance-name forwarding-options dhcp-relay groupgroup-name relay-option-60 vendor-option],

[edit routing-instances routing-instance-name forwarding-options dhcp-relay groupgroup-name relay-option-60 vendor-option (equals | starts-with) (ascii match-string |hexadecimal match-hex)]


Description Drop (discard) DHCP client packets when you use the DHCP vendor class identifieroption (option 60) in DHCP packets to forward client traffic to specific DHCP servers.

To drop DHCP client packets that contain an option 60 string that matches the ASCIIor hexadecimal match string and match criteria (exact match or partial match) thatyou specify, include the drop statement at the [edit forwarding-options dhcp-relayrelay-option-60 vendor-option (equals | starts-with) (ascii match-string | hexadecimalmatch-hex)] hierarchy level.

To drop DHCP client packets that contain an option 60 string that does not matchthe ASCII or hexadecimal match string and match criteria (exact match or partial

drop ■ 395


match) that you specify, include the drop statement at the [edit forwarding-optionsdhcp-relay relay-option-60 vendor-option] hierarchy level.



export-format

Syntax export-format cflowd-version-5;



Description Flow monitoring export format.

Options cflowd-version-5—Cflowd version 5.


Required Privilege Level interface—To view this statement in the configuration.interface-control—To add this statement to the configuration

396 ■ export-format


family


■ family (Filtering) on page 397

■ family (Monitoring) on page 398

■ family (Port Mirroring) on page 399

■ family (Sampling) on page 400

family (Filtering)Syntax family family-name {

filter {input input-filter-name;output output-filter-name;

}flood {

input filter-name;}route-accounting;

}


Release Information Statement introduced before JUNOS Release 7.4.route-accounting option introduced in JUNOS Release 8.3; supported only with IPv6.

Description Specify address family for filters.

Options family-name—Address family. Specify inet for IP version 4 (IPv4), inet6 for IP version 6(IPv6), mpls for MPLS, or vpls for virtual private LAN service (VPLS).

NOTE: In JUNOS Release 8.4 and later, the output statement is not valid at the [editforwarding-options family vpls filter] hierarchy level.


Usage Guidelines See “Applying Filters to Forwarding Tables” on page 325.


family (Filtering) ■ 397


family (Monitoring)Syntax family inet {

output {cflowd hostname {

port port-number;}export-format cflowd-version-5;flow-active-timeout seconds;flow-export-destination {

(cflowd-collector | collector-pic);}flow-inactive-timeout seconds;interface interface-name {


}}

}

Hierarchy Level [edit forwarding-options monitoring group-name]


Description Configure flow monitoring for an address family. Only the IPv4 protocol is supported.


Usage Guidelines See “Configuring Flow Monitoring” on page 328


398 ■ family (Monitoring)


family (Port Mirroring)Syntax family (ccc | inet | inet6 | vpls) {

output {interface interface-name {

next-hop address;}no-filter-check;

}}

Hierarchy Level [edit forwarding-options port-mirroring],[edit forwarding-options port-mirroring instance instance-name]

Release Information Statement introduced before JUNOS Release 7.4.vpls option introduced in JUNOS Release 9.3 for MX Series routers only; supportextended to M7i, M10i, M120, and M320 routers in JUNOS Release 9.5.ccc option introduced in JUNOS Release 9.6 for M120 and M320 routers only.

Description Configure the address type family to sample for port mirroring.

Options ccc—Sample Layer 2 VPN traffic.

inet—Sample IPv4 traffic.

inet6—Sample IPv6 traffic.

vpls—Sample VPLS traffic


Usage Guidelines See “Configuring Port Mirroring” on page 337.


family (Port Mirroring) ■ 399


family (Sampling)Syntax family (inet | inet6 | mpls) {


}

Hierarchy Level [edit forwarding-options sampling input]

Release Information Statement introduced before JUNOS Release 7.4.mpls option introduced in JUNOS Release 8.3.

Description Configure the protocol family to be sampled.

Options inet—IP version 4 (IPv4)

mpls—MPLS


Usage Guidelines See “Configuring Traffic Sampling” on page 309.


family inet

Syntax family inet {layer-3;layer-4;

}

Hierarchy Level [edit forwarding-options hash-key]


Description Configure layer information for the load-balancing specification. Only the IPv4 protocolis supported.

Options layer-3—Include Layer 3 (IP) data in the hash key.

layer-4—Include Layer 4 Transmission Control Protocol (TCP) or User DatagramProtocol (UDP) data in the hash key.

Usage Guidelines See “Overview of Per-Packet Load Balancing” on page 144.


400 ■ family (Sampling)


family mpls

Syntax family mpls {label-1;label-2;label-3;no-labels;no-label-1-exp;payload {




}}

}}


Release Information Statement introduced before JUNOS Release 7.4.no-label-1-exp option introduced in JUNOS Release 8.0.label-3 and no-labels options introduced in JUNOS Release 8.1.ether-pseudowire statement introduced in JUNOS Release 9.1 (M320 and T Seriesrouters only); support extended to M120 and MX Series routers in JUNOS Release 9.4.

Description For aggregated Ethernet and SONET/SDH interfaces only, configure load balancingbased on MPLS labels. Only the IPv4 protocol is supported.

Options label-1—Include only one label in the hash key.

label-2—Include both labels in the hash key.

label-3—Include the third MPLS label in the hash key.

no-labels—Include no MPLS labels in the hash key.

no-label-1-exp—Do not use the EXP bit of the first label in the hash calculation.

payload—Include bits from IP payload in the hash key.

ether-pseudowire (M120, M320, MX Series, and T Series routers)—Load balance IPv4traffic over Layer 2 Ethernet pseudowires.

ip—Include the IP address of the IPv4 or IPv6 payload in the hash key.

layer-3-only—Include only Layer 3 IP information.

family mpls ■ 401


port-data—Include the source and destination port field information.

source-msb—Include the most significant byte of the source port.

source-lsb—Include the least significant byte of the source port.

destination-msb—Include the most significant byte of the destination port.

destination-lsb—Include the least significant byte of the destination port.

Usage Guidelines See “Configuring Load Balancing Based on MPLS Labels” on page 147 and “ConfiguringLoad Balancing for Ethernet Pseudowires” on page 150.


402 ■ family mpls


family multiservice

Syntax family multiservice {destination-mac;source-mac;label-1;label-2;payload {

ip {layer-3-only;layer-3 {

(source-address-only | destination-address-only);}

layer-4;}

}}


Release Information Statement introduced in JUNOS Release 8.0.ip, label-1, label-2, layer-3-only, and payload statements introduced in JUNOS Release 9.4layer-3, layer-. source-address-only, and destination-address-only statements introducedin JUNOS Release 9.5.

Description (M Series, MX Series, and T Series routers only) Configure load balancing based onLayer 2 media access control information. On M120 and M320 routers only, configureVPLS load balancing based on MPLS labels and IP information. On MX Series routers,configure VPLS load balancing.

Options destination-mac—Include the destination-address MAC information in the hash key.

source-mac—Include the source-address MAC information in the hash key.

label-1 (M120 and M320 routers only)—Include the first MPLS label in the hash key.

label-2 (M120 and M320 routers only)—Include the second MPLS label in the hashkey.

payload (MX Series, M120, and M320 routers only)—Include the packet’s IP payloadin the hash key

ip (MX Series, M120, and M320 routers only)—Include the IP address of the IPv4 orIPv6 payload in the hash key.

layer-3-only (M120, and M320 routers only)—Include only the Layer 3 informationfrom the packets’ IP payload in the hash key.

layer-3 (MX Series routers only)—Include Layer 3 information from the packets’ IPpayload in the hash key.

family multiservice ■ 403


source-address-only (MX Series routers only)—Include only the source IP address inthe payload in the hash key.

destination-address-only (MX Series routers only)—Include only the destination IPaddress in the payload in the hash key.

NOTE: You can include either the source-address-only or the destination-address-onlystatement, not both. They are mutually exclusive.

layer-4 (MX Series routers only)—Include Layer 4 information from the packets’ IPpayload in the hash key.

NOTE: On MX Series routers only, you can configure either Layer 3 or Layer 4 loadbalancing or both at the same.

Usage Guidelines See “Configuring Load Balancing Based on MAC Addresses” on page 151 , “ConfiguringVPLS Load Balancing Based on IP and MPLS Information” on page 151, and“Configuring VPLS Load Balancing on MX Series Ethernet Services Routers” on page153.


404 ■ family multiservice


file


■ file (Extended DHCP Relay Agent and Helpers Trace Options) on page 405

■ file (Packet Capture) on page 405

■ file (Sampling) on page 406

■ file (Trace Options) on page 406

file (Extended DHCP Relay Agent and Helpers Trace Options)Syntax file filename <files number> <match regular-expression> <size bytes> <world-readable |

no-world-readable>;

Hierarchy Level [edit forwarding-options dhcp-relay traceoptions],[edit forwarding-options helpers traceoptions]


Description Configure information about the DNS and TFTP packet-forwarding files that containtrace logging information.

Options filename—Name of the file containing the trace information.Default: /var/log/sampled


Usage Guidelines See “Tracing BOOTP, DNS, and TFTP Forwarding Operations” on page 334.


file (Packet Capture)Syntax file filename filename <files number> <size bytes> <world-readable | no-world-readable>;

Hierarchy Level [edit forwarding-options packet-capture]


Description Enable packet capture to a file.


Usage Guidelines See “Configuring Packet Capture” on page 341.


file (Extended DHCP Relay Agent and Helpers Trace Options) ■ 405


file (Sampling)Syntax file filename filename <disable> <files number> <stamp | no-stamp> <size bytes>

<world-readable | no-world-readable>;

Hierarchy Level [edit forwarding-options sampling output]


Description Collect the traffic samples in a file.


Usage Guidelines See “Configuring the Output File for Traffic Sampling” on page 311.


file (Trace Options)Syntax file filename <files number> <size bytes> <world-readable | no-world-readable>;

Hierarchy Level [edit forwarding-options port-mirroring traceoptions],[edit forwarding-options sampling traceoptions]


Description Configure information about the files that contain trace logging information.

Options filename—The name of the file containing the trace information.Default: /var/log/sampled


Usage Guidelines See “Tracing Traffic Sampling Operations” on page 313.


406 ■ file (Sampling)


filename


■ filename (Packet Capture) on page 407

■ filename (Sampling) on page 407

filename (Packet Capture)Syntax filename filename;

Hierarchy Level [edit forwarding-options packet-capture file]


Description Configure the name of the output file.

Options filename—Name of the file.



filename (Sampling)Syntax filename filename;

Hierarchy Level [edit forwarding-options sampling output file]


Description Configure the name of the output file.

Options filename—Name of the file in which to place the traffic samples. All files are placedin the directory /var/tmp.



filename (Packet Capture) ■ 407


files


■ files (Packet Capture) on page 408

■ files (Sampling and Traceoptions) on page 408

files (Packet Capture)Syntax files number;



Description Configure the maximum number of files for packet capturing.

Options number—Maximum number of files.Range: 2 through 10,000 filesDefault: 10



files (Sampling and Traceoptions)Syntax files number;

Hierarchy Level [edit forwarding-options helpers traceoptions file],[edit forwarding-options port-mirroring traceoptions file],[edit forwarding-options sampling output file],[edit forwarding-options sampling traceoptions file]


Description Configure the total number of files to be saved with samples or trace data.

Options number—Maximum number of traffic sampling or trace log files. When a file namedsampling-file reaches its maximum size, it is renamed sampling-file.0, thensampling-file.1, and so on, until the maximum number of traffic sampling files isreached. Then the oldest sampling file is overwritten.Range: 1 through 100 filesDefault: 5 files for sampling output; 10 files for trace log information

Usage Guidelines See “Configuring the Output File for Traffic Sampling” on page 311 and “TracingTraffic Sampling Operations” on page 313.


408 ■ files (Packet Capture)


filter


■ filter (IPv4, IPv6, and MPLS) on page 409

■ filter (VPLS) on page 409

filter (IPv4, IPv6, and MPLS)Syntax filter {

input input-filter-name;output output-filter-name;

}

Hierarchy Level [edit forwarding-options family (inet | inet6 | mpls)]


Description Apply a forwarding table filter to a forwarding table.




filter (VPLS)Syntax filter input filter-name;

Hierarchy Level [edit forwarding-options family vpls]


Description Apply a forwarding table filter for VPLS.

Options The other statement is explained separately.



filter (IPv4, IPv6, and MPLS) ■ 409


flood

Syntax flood {input filter-name;

}

Hierarchy Level [edit forwarding-options family vpls]


Description Apply a forwarding table filter to a flood table.

Options input filter-name—Name of the forwarding table filter.



flow-active-timeout

Syntax flow-active-timeout seconds;

Hierarchy Level [edit forwarding-options accounting group-name output],[edit forwarding-options monitoring group-name family inetoutput],[edit forwarding-options sampling output]


Description Configure the interval before exporting an active flow.

Options seconds—Interval, in seconds.Range: 60 through 1800Default: 1800

Usage Guidelines See “Configuring Discard Accounting” on page 326, “Configuring Flow Monitoring”on page 328, and “Configuring the Output File for Traffic Sampling” on page 311.


410 ■ flood


flow-export-destination

Syntax flow-export-destination {(cflowd-collector | collector-pic);

}



Description Configure flow collection.

Options cflowd-collector—cflowd collector.

collector-pic—Collector PIC.



flow-inactive-timeout

Syntax flow-inactive-timeout seconds;

Hierarchy Level [edit forwarding-options accounting group-name output],[edit forwarding-options monitoring group-name family inet output],[edit forwarding-options sampling output]


Description Configure the interval before a flow is considered inactive.

Options seconds—Interval, in seconds.Range: 15 through 1800Default: 60

Usage Guidelines See “Configuring Discard Accounting” on page 326, “Configuring Flow Monitoring”on page 328, and “Configuring the Output File for Traffic Sampling” on page 311.


flow-export-destination ■ 411


forwarding-options

Syntax forwarding-options { ... }

Hierarchy Level [edit]


Description Configure traffic forwarding.


Usage Guidelines See “Introduction to Traffic Sampling Configuration” on page 307.


412 ■ forwarding-options


group

■ group (DHCP Relay Agent) on page 414

■ group (DHCP Spoofing Prevention) on page 415

forwarding-options ■ 413


group (DHCP Relay Agent)Syntax group group-name {




}}interface interface-name <exclude> <upto upto-interface-name>;overrides {

always-write-giaddr;always-write-option-82;client-discover-match;disable-relay;interface-client-limit number;layer2-unicast-replies;no-arp;proxy-mode;replace-ip-source-with giaddr:trust-option-82;

}relay-option-60 {




}}

}relay-option-82 {



}}

}}

Hierarchy Level [edit forwarding-options dhcp-relay],[edit logical-systems logical-system-name forwarding-options dhcp-relay],

414 ■ group (DHCP Relay Agent)


[edit logical-systems logical-system-name routing-instances routing-instance-nameforwarding-options dhcp-relay],

[edit routing-instances routing-instance-name forwarding-options dhcp-relay]

Release Information Statement introduced in JUNOS Release 8.3.relay-option-60 option introduced in JUNOS Release 9.0.

Description Specify the name of a group of interfaces that have a common DHCP relay agentconfiguration. A group must contain at least one interface.

The statements configured at the [edit forwarding-options dhcp-relay group group-name]hierarchy level apply only to the named group of interfaces, and override any globalDHCP relay agent settings configured with the same statements at the [editforwarding-options dhcp-relay] hierarchy level.

Options group-name—Name of a group of interfaces that have a common DHCP relay agentconfiguration.




group (DHCP Spoofing Prevention)Syntax group group-name {

interface interface-name;}

Hierarchy Level [edit routing-instances routing-instance-name bridge-domains bridge-domain-nameforwarding-options dhcp-relay],

[edit routing-instances routing-instance-name forwarding-options dhcp-relay]


Description Configure Dynamic Host Configuration Protocol (DHCP) snooping on the router.When acting as a snooping agent, the MX Series router typically is located betweenthe client and the DHCP relay agent. It creates filters by “snooping” DHCP messagesand binding DHCP-issued IP addresses with the MAC address of the client. Thesefilters help prevent DHCP spoofing.

Configure DHCP snooping by including the appropriate interfaces under the groupstatement.



group (DHCP Spoofing Prevention) ■ 415


hash-key

Syntax hash-key {family inet {

layer-3;layer-4;

}family mpls {

label-1;label-2;label-3;no-labels;no-label-1-exp;payload {



destination-lsb;destination-msb;source-lsb;source-msb;

}}

}family multiservice {

destination-mac;label-1;label-2;payload {

ip {layer-3-only;layer-3 {

(source-address-only | destination-address-only);}layer-4;

}}source-mac:

}}

}


Release Information Statement introduced before JUNOS Release 7.4.family multiservice and no-label-1-exp options introduced in JUNOS Release 8.0.label-3 and no-labels options introduced in JUNOS Release 8.1.ether-pseudowire statement introduced in JUNOS Release 9.1 (M320 and T Seriesrouters only); support extended to M120 and MX Series routers in JUNOS Release 9.4.

416 ■ hash-key


ip, label-1, label-2, layer-3-only, and payload options for the family multiservice statementintroduced in JUNOS Release 9.4. (M120 and M320 routers only); support for ip andpayload statements only to MX Series routers.layer-3, source-address-only, destination-address-only, and layer-4 statements introducedfor the family multiservice statement in JUNOS Release 9.5. (MX Series routers only)

Description Select which packet header data to use for per-flow load balancing.

Options inet—IP address family.

mpls—MPLS address family.

multiservice—Multiservice protocol family

layer-3—Incorporate Layer 3 data into the hash key.

layer-4—Incorporate Layer 4 data into the hash key.

no-label-1-exp—The EXP bit of the first label is not used in the hash calculation.

label-1—Incorporate the first label into the hash key.

label-2—Incorporate the second label into the hash key.

label-3—Include the third MPLS label in the hash key.

no-labels—Include no MPLS labels in the hash key.

payload—Incorporate payload data into the hash key.

ip—Include the IP address of the IPv4 or IPv6 payload in the hash key.

layer-3-only—Include only Layer 3 IP information.

port-data—Include the source and destination port field information.

source-msb—Include the most significant byte of the source port.

source-lsb—Include the least significant byte of the source port.

destination-msb—Include the most significant byte of the destination port.

destination-lsb—Include the least significant byte of the destination port.

destination-mac—Include the destination MAC address in the hash key.

source-address-only—Include only the Layer 3 IP source address in the hash key.

destination-address-only—Include only the Layer 3 IP destination address in the hashkey.

Usage Guidelines See “Overview of Per-Packet Load Balancing” on page 144.

hash-key ■ 417



418 ■ hash-key


helpers

Syntax helpers {bootp {

client-response-ttl number;description text-description;interface interface-group {





}}domain {

description text-description;interface interface-name {



routing-instance-name>;}port port-number {




routing-instance-name>;}tftp {


broadcast;description text-description;

helpers ■ 419


no-listen;server address <logical-system logical-system-name> <routing-instance


routing-instance-name>;}traceoptions {

file filename <files number> <match regular-expression> <size bytes><world-readable | no-world-readable>;

flag flag;level level;no-remote-trace level;

}}



Description Enable TFTP or DNS request packet forwarding, or configure the router or interfaceto act as a DHCP/BOOTP relay agent. Use only one server address per interface orglobal configuration.




indexed-next-hop

Syntax indexed-next-hop;

Hierarchy Level [edit forwarding-options load-balance],[edit logical-systems logical-system-name forwarding-options load-balance],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options load-balance],[edit routing-instances routing-instance-name forwarding-options load-balance]


Description Generate a permuted index of next-hop entries for unicast and aggregate next hops.

Usage Guidelines See “Configuring Per-Prefix Load Balancing” on page 330


420 ■ indexed-next-hop


input


■ input (Forwarding Table) on page 421

■ input (Port Mirroring) on page 421

■ input (Sampling) on page 422

input (Forwarding Table)Syntax input filter-name;

Hierarchy Level [edit forwarding-options family (inet | inet6 | mpls | vpls) filter],[edit routing-instances routing-instance-name forwarding-options family (inet | inet6 | mpls

| vpls) filter]


Description Apply a forwarding table filter to ingress traffic of the forwarding table.

Options filter-name—Name of the applied filter.



input (Port Mirroring)Syntax input {


}

Hierarchy Level [edit forwarding-options port-mirroring],[edit forwarding-options port-mirroring instance instance-name]

Release Information Statement introduced before JUNOS Release 7.4.maximum-packet-length option introduced in JUNOS Release 9.6 for M120 and M320routers only.

Description Configure input packet properties for port mirroring.




input (Forwarding Table) ■ 421


input (Sampling)Syntax input {

max-packets-per-second number ;maximum-packet-length bytes;rate number;run-length number;

}

Hierarchy Level [edit forwarding-options sampling]

Release Information Statement introduced before JUNOS Release 7.4.mpls option introduced in JUNOS Release 8.3.

Description Configure traffic sampling on a logical interface.




422 ■ input (Sampling)


instance

Syntax instance {instance-name {

input {maximum-packet-length bytes;rate number;run-length number;

}family (ccc| inet | inet6 | vpls) {



}}

}}

Hierarchy Level [edit forwarding-options port-mirroring]

Release Information Statement introduced in JUNOS Release 9.3 (MX Series routers only).Support extended to M120 and M320 routers in JUNOS Release 9.5.maximum-packet-length and ccc options introduced in JUNOS Release 9.6 for M120and M320 routers only.

Description Configure a port-mirroring instance.

Options port-mirroring-instance-name—Name of the port-mirroring instance.



Required Privilege Level interface—To view this statement in the configuration.interface-control-level—To add this statement to the configuration.

instance ■ 423


interface


■ interface (Accounting or Sampling) on page 424

■ interface (BOOTP) on page 425

■ interface (DHCP Spoofing Prevention) on page 426

■ interface (DNS and TFTP Packet Forwarding or Relay Agent) on page 426

■ interface (Extended DHCP Relay Agent) on page 427

■ interface (Monitoring) on page 428

■ interface (Next-Hop Group) on page 428

■ interface (Port Mirroring) on page 429

interface (Accounting or Sampling)Syntax interface interface-name {


}

Hierarchy Level [edit forwarding-options accounting group-name output],[edit forwarding-options sampling output]


Description Specify the output interface for sending copies of packets elsewhere to be analyzed.

Options interface-name—Name of the accounting interface.

engine-id number—Identity of the accounting interface.

engine-type number—Type of this accounting interface.

source-address address—Address used for generating packets.

Usage Guidelines See “Configuring Discard Accounting” on page 326 and “Configuring the Output Filefor Traffic Sampling” on page 311.


424 ■ interface (Accounting or Sampling)


interface (BOOTP)Syntax interface interface-group {



}

Hierarchy Level [edit forwarding-options helpers bootp]


Description Specify the interface for a DHCP and BOOTP relay agent.

Options interface-group—Sets a logical interface or group of logical interfaces with a specificDHCP relay configuration.




interface (BOOTP) ■ 425


interface (DHCP Spoofing Prevention)Syntax interface interface-name;

Hierarchy Level [edit routing-instances routing-instance-name bridge-domains bridge-domain-nameforwarding-options dhcp-relay group group-name interface interface-name],

[edit routing-instances routing-instance-name forwarding-options dhcp-relay groupgroup-name interface interface-name]


Description Configure Dynamic Host Configuration Protocol (DHCP) snooping on the router.When acting as a snooping agent, the MX Series router typically is located betweenthe client and the DHCP relay agent. It creates filters by “snooping” DHCP messagesand binding DHCP-issued IP addresses with the MAC address of the client. Thesefilters help prevent DHCP spoofing.

DHCP snooping is configured by including the appropriate interfaces.



interface (DNS and TFTP Packet Forwarding or Relay Agent)Syntax interface interface-name {



Hierarchy Level [edit forwarding-options helpers domain],[edit forwarding-options helpers tftp]


Description Specify the interface for monitoring and forwarding DNS or TFTP requests.

Options interface-name—Name of the interface.




426 ■ interface (DHCP Spoofing Prevention)


interface (Extended DHCP Relay Agent)Syntax interface interface-name <exclude> <upto upto-interface-name>;

Hierarchy Level [edit forwarding-options dhcp-relay group group-name],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name]

Release Information Statement introduced in JUNOS Release 8.3.exclude and upto options introduced in JUNOS Release 9.1.

Description Specify one or more interfaces, or a range of interfaces, that are within a specifiedgroup on which the DHCP local server is enabled. You can repeat the interfaceinterface-name statement to specify multiple interfaces within a group, but you cannotspecify the same interface in more than one group. Also, you cannot use an interfacethat is being used by the DHCP relay agent.

Options exclude—Exclude an interface or a range of interfaces from the group.

interface-name—The name of the interface. You can repeat this keyword multipletimes.

upto-interface-name—The upper end of the range of interfaces; the lower end of therange is the interface-name entry. The interface device name of theupto-interface-name must be the same as the device name of the interface-name.



interface (Extended DHCP Relay Agent) ■ 427


interface (Monitoring)Syntax interface interface-name {


}



Description Specify the output interface for monitored traffic.


engine-id number—Identity of the monitoring interface.

engine-type number—Type of this monitoring interface.

input-interface-index number—Input interface index for records from this interface.

output-interface-index number—Output interface index for records from this interface.

source-address address—Address used for generating packets.



interface (Next-Hop Group)Syntax interface interface-name {

next-hop address;}

Hierarchy Level [edit forwarding-options next-hop-group group-name]





Usage Guidelines See “Configuring Next-Hop Groups” on page 329.


428 ■ interface (Monitoring)


interface (Port Mirroring)Syntax interface interface-name {

next-hop address;}

Hierarchy Level [edit forwarding-options port-mirroring output],[edit forwarding-options port-mirroring family (inet | inet6) output]







layer2-unicast-replies

Syntax layer2-unicast-replies;







Description Override the setting of the broadcast bit in DHCP request packets and instead usethe Layer 2 unicast transmission method to transmit DHCP Offer reply packets andDHCP ACK reply packets from the DHCP server to DHCP clients during the discoveryprocess.



interface (Port Mirroring) ■ 429


load-balance

Syntax load-balance {indexed-next-hop;per-flow {

hash-seed;}per-prefix {

hash-seed number;}

}

Hierarchy Level [edit forwarding-options],[edit logical-systems logical-system-name forwarding-options],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options],[edit routing-instances routing-instance-name forwarding-options]

Release Information Statement introduced in JUNOS Release 9.0.Support for per-flow load balancing introduced in JUNOS Release 9.3.

Description Enable per-prefix or per-flow load balancing so that the router elects a next hopindependently of the route selected by other routers.


Usage Guidelines See “Configuring Per-Prefix Load Balancing” on page 330 and “Configuring Per-FlowLoad Balancing Based on Hash Values” on page 331.


Related Topics per-prefix

430 ■ load-balance


local-dump

Syntax (local-dump | no-local-dump);

Hierarchy Level [edit forwarding-options sampling output cflowd hostname]


Description Enable collection of cflowd records in a log file.

Options no-local-dump—Do not dump cflowd records to a log file before exporting.

local-dump—Dump cflowd records to a log file before exporting.

Usage Guidelines See “Debugging cflowd Flow Aggregation” on page 315.


local-dump ■ 431


local-server-group

Syntax local-server-group local-server-group-name;

Hierarchy Level [edit forwarding-options dhcp-relay relay-option-60 vendor-option (equals | starts-with)(ascii match-string | hexadecimal match-hex)],

[edit forwarding-options dhcp-relay group group-name relay-option-60 vendor-option (equals| starts-with) (ascii match-string | hexadecimal match-hex)],

[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-60vendor-option (equals | starts-with) (ascii match-string | hexadecimal match-hex)],

[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-namerelay-option-60 vendor-option (equals | starts-with) (ascii match-string | hexadecimalmatch-hex)],






Description Forward DHCP client packets to a specific extended DHCP local server when youuse the DHCP vendor class identifier option (option 60) in DHCP packets to forwardclient traffic to specific DHCP servers.

If the option 60 string received in the DHCP client packet matches the ASCII orhexadecimal match string and match criteria (exact match or partial match) that youspecify, the extended DHCP relay agent forwards the client packets to the specifiedextended DHCP local server group configured with the dhcp-local-server statementat the [edit system services] hierarchy level.

Options local-server-group-name—Name of the extended DHCP local server group.



432 ■ local-server-group


logical-system-name

Syntax logical-system-name;









Description Specify that the logical system name be concatenated with the username during thesubscriber authentication process. No logical system name is concatenated if theconfiguration is in the default logical system.



logical-system-name ■ 433


mac-address

Syntax mac-address;









Description Specify that the MAC address from the client PDU be concatenated with the usernameduring the subscriber authentication process.



max-packets-per-second

Syntax max-packets-per-second number;

Hierarchy Level [edit forwarding-options sampling input family]


Description Specify that the traffic threshold that must be exceeded before packets are dropped.A value of 0 instructs the Packet Forwarding Engine not to sample any traffic.

Options number—Maximum number of packets per second.Range: 0 through 65,535Default: 1000



434 ■ mac-address


maximum-capture-size

Syntax maximum-capture-size bytes;

Hierarchy Level [edit forwarding-options packet-capture]


Description Configure the maximum size of capture for packets.

Options bytes—Maximum capture size.Range: 68 through 1500Default: 68 bytes



maximum-hop-count

Syntax maximum-hop-count number;



Description The maximum number of hops allowed.

Options number—Maximum number of hops.Default: 4 hops



maximum-capture-size ■ 435


maximum-packet-length

Syntax maximum-packet-length bytes;

Hierarchy Level [edit forwarding-options port-mirroring input],[edit forwarding-options port-mirroring instance instance-name input],


Description Set the maximum length of the packet used for port mirroring. Packets with lengthsgreater than the specified maximum are truncated.

Options bytes—Number of bytes.



minimum-wait-time

Syntax minimum-wait-time seconds;



Description The minimum time allowed.

Options seconds—Minimum time.Default: 0 seconds



436 ■ maximum-packet-length


mirror-once

Syntax mirror-once;

Hierarchy Level [edit forwarding-options port-mirroring]

Release Information Statement introduced in JUNOS Release 9.3 (MX Series routers only).Support extended to M120 routers in JUNOS Release 9.5.

Description Configure the router to mirror packets only once. This feature is useful if you configureport mirroring on both ingress and egress interfaces, which could result in the samepacket being mirrored twice.



mirror-once ■ 437


monitoring

Syntax monitoring group-name {family inet {

output {cflowd hostname {

port port-number;}export-format cflowd-version-5;flow-active-timeout seconds;flow-export-destination {



}}

}}



Description Specify flow monitoring instance name and properties.




438 ■ monitoring


next-hop

Syntax next-hop address;

Hierarchy Level [edit forwarding-options port-mirroring output interface interface-name],[edit forwarding-options port-mirroring family (inet | inet6) outputinterface interface-name]


Description Specify the next-hop address for sending copies of packets to an analyzer.

Options address—IP address of the next-hop router.



next-hop ■ 439


next-hop-group

Syntax next-hop-group group-name {interface interface-name {

next-hop address;}next-hop-subgroup subgroup-name {


}}

}



Description Specify the next-hop address for sending copies of packets to an analyzer.

Options addresses—IP address of the next-hop router. Each next-hop group supports up to16 next-hop addresses. Up to 30 next-hop groups are supported. Each next-hopgroup must have at least two next-hop addresses.

group-names—Name of next-hop group. Up to 30 next-hop groups are supported forthe router. Each next-hop group must have at least two next-hop addresses.

interface-name—Interface used to reach the next-hop destination.

Usage Guidelines See “Configuring Next-Hop Groups” on page 329.


440 ■ next-hop-group


no-filter-check

Syntax no-filter-check;

Hierarchy Level [edit forwarding-options port-mirroring output],[edit forwarding-options port-mirroring family (inet | inet6) output]


Description Disable filter checking on the port-mirroring interface.

This statement is required when you send port-mirrored traffic to a Tunnel ServicesPIC that has a filter applied to it.



no-listen

Syntax no-listen;

Hierarchy Level [edit forwarding-options helpers bootp interface interface-group],[edit forwarding-options helpers domain interface interface-name],[edit forwarding-options helpers tftp interface interface-name]


Description Disable recognition of DNS requests or stop packets from being forwarded on alogical interface, a group of logical interfaces, or a router.



no-local-dump

See local-dump

no-stamp

See stamp

no-filter-check ■ 441


no-world-readable

See world-readable

option-60

Syntax option-60;









Description Specify that the payload of the Option 60 (Vendor Class Identifier) from the clientPDU be concatenated with the username during the subscriber authentication process.



442 ■ no-world-readable


option-82

Syntax option-82 <circuit-id> <remote-id>;









Description Specify the type of option 82 information from the client PDU that is concatenatedwith the username during the subscriber authentication process. You can specifyeither, both, or neither the agent circuit ID nor the agent remote ID suboptions. Ifyou specify both, the agent circuit ID is supplied first, followed by a delimiter, andthen the agent remote ID. If you specify that neither suboption is supplied, the rawpayload of option 82 from the PDU is concatenated to the username.

Options circuit-id—The string for the agent circuit ID suboption (suboption 1).

remote-id—The string for the agent remote ID suboption (suboption 2).



option-82 ■ 443


output


■ output (Accounting) on page 444

■ output (Forwarding Table) on page 445

■ output (Monitoring) on page 445

■ output (Port Mirroring) on page 446

■ output (Sampling) on page 447

output (Accounting)Syntax output {

cflowd [ hostnames ] {aggregation {

autonomous-system;destination-prefix;protocol-port;source-destination-prefix {





}}

Hierarchy Level [edit forwarding-options accounting group-name]


Description Configure cflowd, output interfaces, and flow properties.


Usage Guidelines See “Configuring Discard Accounting” on page 326.


444 ■ output (Accounting)


output (Forwarding Table)Syntax output filter-name;

Hierarchy Level [edit forwarding-options family (inet | inet6 | mpls) filter],[edit routing-instances routing-instance-name forwarding-options family (inet | inet6 |

mpls) filter]


Description Configure filtering on the egress traffic of the forwarding table.

Options filter-name—Name of the applied filter.



output (Monitoring)Syntax output {





}}

Hierarchy Level [edit forwarding-options monitoring group-name family inet]


Description Configure cflowd, output interfaces, and flow properties.




output (Forwarding Table) ■ 445


output (Port Mirroring)Syntax output {


}no-filter-check;

}

Hierarchy Level [edit forwarding-options port-mirroring family (ccc | inet | inet6 | vpls)],[edit forwarding-options port-mirroring instance instance-name family (ccc | inet | inet6 |

vpls)]

Release Information Statement introduced before JUNOS Release 7.4.vpls option introduced in JUNOS Release 9.3 for MX Series routers only; supportextended to M7i, M10i, M120, and M320 routers in JUNOS Release 9.5.ccc option introduced in JUNOS Release 9.6 for M120 and M320 routers only.

Description Configure the port mirroring destination properties.




446 ■ output (Port Mirroring)


output (Sampling)Syntax output {

aggregate-export-interval seconds;cflowd hostname {





}extension-service service-name;file filename filename <disable> <files number> <stamp | no-stamp> <size bytes>

<world-readable | no-world-readable>;flow-active-timeout seconds;flow-inactive-timeout seconds;flow-server host-name {

aggregation;autonomous-system-type (origin | peer);(local-dump | no-local-dump);port number;source-address address;version (5 | 8);version9;

}interface interface-name {


}}

Hierarchy Level [edit forwarding-options sampling family (inet | inet6 | mpls)]

Release Information Statement introduced before JUNOS Release 7.4.version9 statement introduced in JUNOS Release 8.3.

Description Configure cflowd, output files and interfaces, and flow properties. Enable the collectionof traffic flows using the version 9 format.


output (Sampling) ■ 447


Usage Guidelines See “Configuring the Output File for Traffic Sampling” on page 311 and “ConfiguringActive Flow Monitoring Using Version 9” on page 316.


overrides

Syntax overrides {always-write-giaddr;always-write-option-82;client-discover-match;disable-relay;interface-client-limit number;layer2-unicast-replies;no-arp;proxy-mode;replace-ip-source-with giaddr:trust-option-82;

}




group-name]


Description Override the default configuration settings for the extended DHCP relay agent.Specifying the overrides statement with no subordinate statements removes all DHCPrelay agent overrides at that hierarchy level.

To override global DHCP relay agent configuration options, include the overridesstatement and its subordinate statements at the [edit forwarding-options dhcp-relay]hierarchy level. To override DHCP relay agent configuration options for a namedgroup of interfaces, include the statements at the [edit forwarding-options dhcp-relaygroup group-name] hierarchy level.




448 ■ overrides


packet-capture

Syntax packet-capture {disable;file filename filename <files number> <size bytes> <world-readable | no-world-readable>;maximum-capture-size number;

}



Description Configure packet capture on a router.

Options disable—Disable packet capture on the router.




packet-capture ■ 449


password

Syntax password password-string;

Hierarchy Level [edit forwarding-options dhcp-relay authentication],[edit forwarding-options dhcp-relay group group-name authentication],[edit logical-systems logical-system-name forwarding-options dhcp-relay authentication],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

authentication],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay authentication],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name authentication],[edit routing-instances routing-instance-name forwarding-options dhcp-relay authentication],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name authentication]


Description Configure the password that is sent to the external AAA authentication server forsubscriber authentication.

Options password-string—Authentication password.



450 ■ password


per-flow

Syntax per-flow {hash-seed;

}



Release Information Statement introduced in JUNOS Release 9.3 (M120, M320, and MX Series routersonly).

Description Enable per-flow load balancing based on hash values.

Options hash-seed—Configure the hash value. The JUNOS Software automatically chooses avalue for the hashing algorithm used. You cannot configure a specific hash valuefor per-flow load balancing.

Usage Guidelines See “Configuring Per-Flow Load Balancing Based on Hash Values” on page 331.


Related Topics load-balance

per-flow ■ 451


per-prefix

Syntax per-prefix {hash-seed number;

}




Description Configure the hash parameter for per-prefix load balancing.

Options hash-seed—Configure the hash value.

number—Hash value.Range: 0 through 65,535Default: 0

Usage Guidelines See “Configuring Per-Prefix Load Balancing” on page 330.


Related Topics load-balance

port

Syntax port port-number;

Hierarchy Level [edit forwarding-options accounting group-name output cflowd hostname],[edit forwarding-options monitoring group-name family inet output cflowd hostname],[edit forwarding-options sampling output cflowd hostname]


Description Specify the UDP port number on the cflowd host system.

Options port-number—Any valid UDP port number on the host system.



452 ■ per-prefix


port-mirroring

Syntax port-mirroring {input {


}family (ccc | inet | inet6 | vpls) {



}}instance {

instance-name {input {


}family (ccc | inet | inet6 | vpls) {



}}

}}mirror-once;traceoptions {

file filename <files number> <size bytes> <world-readable | no-world-readable>;}

}


Release Information Statement introduced before JUNOS Release 7.4.family vpls statement introduced in JUNOS Release 9.3 (MX Series routers only);support extended to M7i, M10, M120, and M320 routers in JUNOS Release 9.5.instance port-mirroring-instance-name statement introduced in JUNOS Release 9.3 (MXSeries routers only); support extended to M120 and M320 routers in JUNOSRelease 9.5.mirror-once statement introduced in JUNOS Release 9.3 (MX Series routers only);support extended to M120 routers in JUNOS Release 9.5.family ccc statement introduced in JUNOS Release 9.6 (M120 and M320 routers only)

port-mirroring ■ 453


Description Specify the address family, rate, run length, interface, and next-hop address forsending copies of packets to an analyzer.


NOTE: For information about configuring port mirroring for Layer 2 traffic on MXSeries routers, see the JUNOS MX-series Layer 2 Configuration Guide.



454 ■ port-mirroring


prefix

Syntax prefix {host-name;logical-system-name;routing-instance-name;

}

Hierarchy Level [edit forwarding-options dhcp-relay relay-option-82 circuit-id],[edit forwarding-options dhcp-relay group group-name relay-option-82 circuit-id],[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-82

circuit-id],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

relay-option-82 circuit-id],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay relay-option-82 circuit-id],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name relay-option-82 circuit-id],[edit routing-instances routing-instance-name forwarding-options dhcp-relay relay-option-82

circuit-id],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name relay-option-82 circuit-id]


Description Add a prefix to the base option 82 agent-circuit-id information in DHCP packetsdestined for a DHCP server. The prefix can consist of any combination of thehostname, logical system name, and routing instance name.

If you include only the hostname, only the logical system name, or only the routinginstance name in the prefix, the format of the agent-circuit-id information for FastEthernet or Gigabit Ethernet interfaces with stacked virtual LANs (S-VLANs) is one ofthe following:

host-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-idlogical-system-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-idrouting-instance-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id

If you include both the logical system name and the routing instance name in theprefix, the format of the agent-circuit-id information for Fast Ethernet or GigabitEthernet interfaces with S-VLANs is as follows:

logical-system-name:routing-instance-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id

If you include the hostname, logical system name, and routing instance name in theprefix, the format of the agent-circuit-id information for Fast Ethernet or GigabitEthernet interfaces with S-VLANs is as follows:

host-name/logical-system-name:routing-instance-name:(fe |ge)-fpc/pic/port:svlan-id-vlan-id

prefix ■ 455


For Fast Ethernet or Gigabit Ethernet interfaces that use virtual LANs (VLANs) butnot S-VLANs, only the vlan-id value appears in the agent-circuit-id format. For FastEthernet or Gigabit Ethernet interfaces that do not use VLANs or S-VLANs, neitherthe vlan-id value nor the svlan-id value appears.

Options host-name—Prepend the hostname of the router configured with the host-namestatement at the [edit system] hierarchy level to the agent-circuit-id information.

logical-system-name—Prepend the name of the logical system to the agent-circuit-idinformation.

routing-instance-name—Prepend the name of the routing instance to the agent-circuit-idinformation.



rate

Syntax rate number;

Hierarchy Level [edit forwarding-options port-mirroring input],[edit forwarding-options port-mirroring instance instance-name input],[edit forwarding-options sampling input family]


Description Set the ratio of the number of packets to be sampled. For example, if you specify arate of 10, every tenth packet (1 packet out of 10) is sampled.

Options number—Denominator of the ratio.Range: 1 through 65,535

Usage Guidelines See “Configuring Traffic Sampling” on page 309 and “Configuring Port Mirroring” onpage 337.


456 ■ rate


relay-option-60

Syntax relay-option-60 {vendor-option {

(default-relay-server-group server-group-name | default-local-server-grouplocal-server-group-name | drop);

(equals | starts-with) (ascii match-string | hexadecimal match-hex) {(drop | local-server-group local-server-group-name | relay-server-group

server-group-name);}

}}




group-name]


Description Configure the extended DHCP relay agent to use the DHCP vendor class identifieroption (option 60) in DHCP client packets to forward client traffic to specific DHCPservers, or to drop selected DHCP client packets. This feature is useful in networkenvironments where DHCP clients access services provided by multiple vendors andDHCP servers.

You can use the relay-option-60 statement and its subordinate statements at the [editforwarding-options dhcp-relay] hierarchy level to configure option 60 support globally,or at the [edit forwarding-options dhcp-relay group group-name] hierarchy level toconfigure option 60 support for a named group of interfaces. You can also configureoption 60 support for the extended DHCP relay agent on a per logical system andper routing instance basis.




relay-option-60 ■ 457


relay-option-82

Syntax relay-option-82 {circuit-id {


}}

}




group-name]


Description Enable or disable the insertion of the DHCP relay agent information option (option 82)in DHCP packets destined for a DHCP server.

If you enable insertion of option 82 information in DHCP packets, you must specifyat least the circuit-id statement to include the agent-circuit-id suboption (suboption 1)of the DHCP relay agent information option. Optionally, you can also specify theprefix statement to add a prefix to the base option 82 information that consists ofany combination of the hostname, logical system name, and routing instance name.Specifying the relay-option-82 statement with no subordinate statements disablesinsertion of option 82 information in DHCP packets, which is the default behavior.

You can use the relay-option-82 statement and its subordinate statements at the [editforwarding-options dhcp-relay] hierarchy level to control insertion of option 82information globally, or at the [edit forwarding-options dhcp-relay group group-name]hierarchy level to control insertion of option 82 information for a named group ofinterfaces.




458 ■ relay-option-82


relay-server-group

Syntax relay-server-group server-group-name;

Hierarchy Level [edit forwarding-options dhcp-relay relay-option-60 vendor-option (equals | starts-with)(ascii match-string | hexadecimal match-hex)],

[edit forwarding-options dhcp-relay group group-name relay-option-60 vendor-option (equals| starts-with) (ascii match-string | hexadecimal match-hex)],

[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-60vendor-option (equals | starts-with) (ascii match-string | hexadecimal match-hex)],

[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-namerelay-option-60 vendor-option (equals | starts-with) (ascii match-string | hexadecimalmatch-hex)],






Description Relay DHCP client packets to the specified group of extended DHCP relay serverswhen you use the DHCP vendor class identifier option (option 60) in DHCP packetsto forward client traffic to specific DHCP servers.

If the option 60 string received in the DHCP client packet matches the ASCII orhexadecimal match string and match criteria (exact match or partial match) that youspecify, the extended DHCP relay agent relays the client packets to the specifiedgroup of servers configured with the server-group statement at the [editforwarding-options dhcp-relay] hierarchy level. A server group can contain multipleserver addresses and can map to more than one ASCII or hexadecimal match string.

Options server-group-name—Name of the extended DHCP relay server group.



relay-server-group ■ 459


replace-ip-source-with

Syntax replace-ip-source-with giaddr;







Description Replace the IP source address in DHCP relay request and release packets with thegateway IP address (giaddr).


Related Topics ■ Extended DHCP Relay Agent Overview

■ Replacing the DHCP Relay Request and Release Packet Source Address

route-accounting

Syntax route-accounting;

Hierarchy Level [edit forwarding-options family inet6]


Description Configure the routing platform to track IPv6 traffic passing through the router.

Default Disabled

Usage Guidelines See “Configuring IPv6 Accounting” on page 326.


460 ■ replace-ip-source-with


routing-instance-name

Syntax routing-instance-name;









Description Specify that the routing instance name be concatenated with the username duringthe subscriber authentication process. No routing instance name be concatenated ifthe configuration is in the default routing instance.



routing-instance-name ■ 461


run-length

Syntax run-length number;

Hierarchy Level [edit forwarding-options port-mirroringinput],[edit forwarding-options port-mirroring instance port-mirroring-instance-name input],[edit forwarding-options sampling input family (inet | inet6 | mpls)]


Description Set the number of samples following the initial trigger event. This allows you tosample packets following those already being sampled.

Options number—Number of samples.Range: 0 through 20Default: 0



462 ■ run-length


sampling

Syntax sampling {disable;input {


}}family (inet | inet6 | mpls) {

output {aggregate-export-interval seconds;cflowd hostname {





}}extension-service service-name;file filename filename <disable> <files number> <stamp | no-stamp> <size bytes>

<world-readable | no-world-readable>;flow-active-timeout seconds;flow-inactive-timeout seconds;flow-server host-name {

aggregation;autonomous-system-type (origin | peer);(local-dump | no-local-dump);port number;source-address address;version (5 | 8);version9;

}interface interface-name {


}

sampling ■ 463


}traceoptions {


}



Description Configure traffic sampling.


Usage Guidelines See “Applying Filters to Forwarding Tables” on page 325, “Configuring FlowAggregation (cflowd)” on page 313, “Tracing Traffic Sampling Operations” on page313, “Configuring Active Flow Monitoring Using Version 9” on page 316, and“Configuring Port Mirroring” on page 337.


464 ■ sampling


server


■ server (DHCP and BOOTP Relay Agent) on page 465

■ server (DNS and TFTP Service) on page 466

server (DHCP and BOOTP Relay Agent)Syntax server server-identifier {




Description Configure the router to act as a DHCP and BOOTP relay agent.

Options addresses—One or more addresses of the server.



server (DHCP and BOOTP Relay Agent) ■ 465


server (DNS and TFTP Service)Syntax server address <logical-system logical-system-name> <routing-instance

routing-instance-name>;

Hierarchy Level [edit forwarding-options helpers domain],[edit forwarding-options helpers domain interface interface-name],[edit forwarding-options helpers tftp],[edit forwarding-options helpers tftp interface interface-name]


Description Specify the DNS or TFTP server for forwarding DNS or TFTP requests. Only oneserver can be specified for each interface.

Options address—Address of the server.

routing-instance [ routing-instance-names ]—Set the routing instance name or namesthat belong to the DNS server or TFTP server.



466 ■ server (DNS and TFTP Service)


server-group

Syntax server-group {server-group-name {

server-ip-address;}

}

Hierarchy Level [edit forwarding-options dhcp-relay],[edit logical-systems logical-system-name forwarding-options dhcp-relay],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay],[edit routing-instances routing-instance-name forwarding-options dhcp-relay]


Description Specify the name of a group of DHCP server addresses for use by the extended DHCPrelay agent.

Options server-group-name—Name of the group of DHCP server addresses.

server-ip-address—IP address of the DHCP server belonging to this named servergroup. You can configure a maximum of five IP addresses per named servergroup.



server-group ■ 467


size


■ size (Packet Capture) on page 468

■ size (Sampling and Traceoptions) on page 469

size (Packet Capture)Syntax size number;



Description Configure the maximum size of the file for packet capturing.

Options number—Maximum size of file.Range: 1024 through 104,857,600 bytesDefault: 512,000 bytes



468 ■ size (Packet Capture)


size (Sampling and Traceoptions)Syntax size bytes;

Hierarchy Level [edit forwarding-options helpers traceoptions file],[edit forwarding-options port-mirroring traceoptions file],[edit forwarding-options sampling output file],[edit forwarding-options sampling traceoptions file]


Description Specify the maximum size of each file containing sample or log data. The file size islimited by the number of files to be created and the available hard disk space.

When a traffic sampling file named sampling-file reaches the maximum size, it isrenamed sampling-file.0. When the sampling-file file again reaches its maximum size,sampling-file.0 is renamed sampling-file.1 and sampling-file is renamed sampling-file.0.This renaming scheme continues until the maximum number of traffic sampling filesis reached. Then the oldest traffic sampling file is overwritten.

Options bytes—Maximum size of each traffic sampling file or trace log file, in kilobytes (KB),megabytes (MB), or gigabytes (GB).Syntax: xk to specify KB, xm to specify MB, or xg to specify GBRange: 10 KB through the maximum file size supported on your routerDefault: 1 MB for sampling data; 128 KB for log information



stamp

Syntax (stamp | no-stamp);

Hierarchy Level [edit forwarding-options sampling output file]


Description Include a timestamp with each line in the output file.

Options no-stamp—Do not include timestamps. This is the default.

stamp—Include a timestamp with each line of packet sampling information.Default: No timestamp is included.



size (Sampling and Traceoptions) ■ 469


tftp

Syntax tftp {description text-description;interface interface-name {






Description Enable TFTP request packet forwarding.




470 ■ tftp


traceoptions


■ traceoptions (DNS and TFTP Packet Forwarding) on page 472

■ traceoptions (Extended DHCP Relay Agent) on page 474

■ traceoptions (Port Mirroring and Traffic Sampling) on page 476

tftp ■ 471


traceoptions (DNS and TFTP Packet Forwarding)Syntax traceoptions {

file filename <files number> <match regular-expression> <size bytes> <world-readable |no-world-readable>;

flag flag;level level;<no-remote-trace>;

}


Release Information Statement introduced before JUNOS Release 7.4.Statement standardized and match option introduced in JUNOS Release 8.0.

Description Configure tracing operations for BOOTP, DNS and TFTP packet forwarding.

Default If you do not include this statement, no tracing operations are performed.

Options filename—Name of the file to receive the output of the tracing operation. Enclose thename in quotation marks (“ ”). All files are placed in a file named fud in thedirectory /var/log. If you include the file statement, you must specify a filename.

files number—(Optional) Maximum number of trace files. When a trace file namedtrace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1,and so on, until the maximum number of trace files is reached. Then the oldesttrace file is overwritten.

If you specify a maximum number of files, you also must specify a maximum filesize with the size option and a filename.Range: 2 through 1000Default: 3 files

flag—Tracing operation to perform. To specify more than one tracing operation,include multiple flag statements. You can include the following flags:

■ address—Trace address management events


■ bootp—Trace BOOTP or DHCP services events

■ config—Trace configuration events

■ domain—Trace DNS service events

■ ifdb—Trace interface database operations


■ main—Trace main loop events

■ port—Trace arbitrary protocol events


■ tftp—Trace TFTP service events

472 ■ traceoptions (DNS and TFTP Packet Forwarding)


■ trace—Trace tracing operations


■ util—Trace miscellaneous utility operations

match regular-expression—(Optional) Refine the output to include lines that containthe regular expression.

no-remote-trace—(Optional) Disable remote tracing globally or for a specific tracingoperation.

size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes(MB), or gigabytes (GB). When a trace file named trace-file reaches this size, it isrenamed trace-file.0. When the trace-file file again reaches its maximum size,trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. Thisrenaming scheme continues until the maximum number of trace files is reached.Then the oldest trace file is overwritten.

If you specify a maximum file size, you also must specify a maximum number oftrace files with the files option and filename.Syntax: xk to specify KB, xm to specify MB, or xg to specify GBRange: 0 bytes through 4,294,967,295 KBDefault: 128 KB

world-readable—(Optional) Enable unrestricted file access.


Usage Guidelines See “Tracing BOOTP, DNS, and TFTP Forwarding Operations” on page 334.


traceoptions (DNS and TFTP Packet Forwarding) ■ 473


traceoptions (Extended DHCP Relay Agent)Syntax traceoptions {



}

Hierarchy Level [edit forwarding-options dhcp-relay],[edit logical-systems logical-system-name forwarding-options dhcp-relay],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay],[edit routing-instances routing-instance-name forwarding-options dhcp-relay]


Description Configure tracing operations for extended DHCP relay agent processes.

Default If you do not include this statement, no tracing operations are performed.

Options file-name—Name of the file to receive the output of the tracing operation. Enclosethe name in quotation marks (“ ”). All files are placed in a file named jdhcpd inthe directory /var/log. If you include the file statement, you must specify afilename.

files number—(Optional) Maximum number of trace files. When a trace file namedtrace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1,and so on, until the maximum number of trace files is reached. Then the oldesttrace file is overwritten.

If you specify a maximum number of files, you also must specify a maximum filesize with the size option and a filename.Range: 2 through 1000Default: 3 files

flag flag—Tracing operation to perform. To specify more than one tracing operation,include multiple flag statements. You can include the following flags:


■ auth—Trace authentication events

■ database—Trace database events

■ fwd—Trace firewall process events

■ general—Trace miscellaneous events

■ ha—Trace high availability-related events

■ interface—Trace interface operations


■ packet—Trace packet decoding operations

474 ■ traceoptions (Extended DHCP Relay Agent)


■ packet-option—Trace DHCP option decoding operations

■ rpd—Trace routing protocol process events


■ session-db—Trace session database operations

■ state—Trace changes in state


match regular-expression—(Optional) Refine the output to include lines that containthe regular expression.

size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes(MB), or gigabytes (GB). When a trace file named trace-file reaches this size, it isrenamed trace-file.0. When the trace-file file again reaches its maximum size,trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. Thisrenaming scheme continues until the maximum number of trace files is reached.Then the oldest trace file is overwritten.

If you specify a maximum file size, you also must specify a maximum number oftrace files with the files option and filename.Syntax: xk to specify KB, xm to specify MB, or xg to specify GBRange: 0 bytes through 4,294,967,295 KBDefault: 128 KB

world-readable—(Optional) Enable unrestricted file access.




traceoptions (Extended DHCP Relay Agent) ■ 475


traceoptions (Port Mirroring and Traffic Sampling)Syntax traceoptions {


Hierarchy Level [edit forwarding-options port-mirroring],[edit forwarding-options sampling]


Description Configure traffic sampling tracing operations.


Usage Guidelines See “Tracing Traffic Sampling Operations” on page 313.


trust-option-82

Syntax trust-option-82;







Description Enable processing of DHCP client packets that have a gateway IP address (giaddr)of 0 (zero) and contain option 82 information. By default, the DHCP relay agent treatssuch packets as if they originated at an untrusted source, and drops them withoutfurther processing.



476 ■ traceoptions (Port Mirroring and Traffic Sampling)


user-prefix

Syntax user-prefix user-prefix-string;









Description Specify the user prefix that is concatenated with the username during the subscriberauthentication process.

Options user-prefix-string—The user prefix string.



user-prefix ■ 477


username-include

Syntax username-include {circuit-type;delimiter delimiter-character;domain-name domain-name-string;logical-system-name;mac-address;option-60;option-82 <circuit-id> <remote-id>;routing-instance-name;user-prefix user-prefix-string;

}

Hierarchy Level [edit forwarding-options dhcp-relay authentication],[edit forwarding-options dhcp-relay group group-name authentication],[edit logical-systems logical-system-name forwarding-options dhcp-relay authentication],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

authentication],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay authentication],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name authentication],[edit routing-instances routing-instance-name forwarding-options dhcp-relay authentication],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name authentication]


Description Configure the username that the router passes to the external AAA server. You mustinclude at least one of the optional statements for the username to be valid. If youdo not configure a username, the router accesses the local authentication serviceonly and does not use external authentication services, such as RADIUS.




478 ■ username-include


vendor-option

Syntax vendor-option {(default-relay-server-group server-group-name | default-local-server-group



}}

Hierarchy Level [edit forwarding-options dhcp-relay relay-option-60],[edit forwarding-options dhcp-relay group group-name relay-option-60],[edit logical-systems logical-system-name forwarding-options dhcp-relay relay-option-60],[edit logical-systems logical-system-name forwarding-options dhcp-relay group group-name

relay-option-60],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay relay-option-60],[edit logical-systems logical-system-name routing-instances routing-instance-name

forwarding-options dhcp-relay group group-name relay-option-60],[edit routing-instances routing-instance-name forwarding-options dhcp-relay relay-option-60],[edit routing-instances routing-instance-name forwarding-options dhcp-relay group

group-name relay-option-60]


Description Configure the match criteria when you use the DHCP vendor class identifier option(option 60) in DHCP client packets to forward client traffic to specific DHCP servers.The extended DHCP relay agent compares the option 60 vendor-specific stringsreceived in DHCP client packets against the match criteria that you specify. If thereis a match, you can define certain actions for the associated DHCP client packets.

The vendor-option statement enables you to specify either an exact, left-to-right match(with the equals statement) or a partial match (with the starts-with statement), andconfigure either an ASCII match string (with the ascii statement) or a hexadecimalmatch string (with the hexadecimal statement).

You can configure an unlimited number of match strings. Match strings do not supportthe use of wildcard attributes.

Options equals—Exact, left-to-right match of the ASCII or hexadecimal match string with theoption 60 string.

starts-with—Partial match of the ASCII or hexadecimal match string with the option 60string. The option 60 string can contain a superset of the ASCII or hexadecimalmatch string, provided that the leftmost characters of the option 60 string entirelymatch the characters in the configured match string. When you use the starts-withstatement, the longest match rule applies; that is, the router matches the string“test123” before it matches the string “test”.

ascii match-string—ASCII match string of 1 through 255 alphanumeric characters.

vendor-option ■ 479


hexadecimal match-hex—Hexadecimal match string of 1 through 255 hexadecimalcharacters (0 through 9, a through f, A through F).




version

Syntax version format;

Hierarchy Level [edit forwarding-options accounting group-name output cflowd hostname],[edit forwarding-options sampling output cflowd hostname]


Description Specify the version format of the aggregated flows exported to a cflowd server.

Options format—Export format of the flows.Values: 5 or 8Default: 5



480 ■ version


version9

Syntax version9 {template template-name;

}

Hierarchy Level [edit forwarding-options sampling cflowd hostname]


Description Enable active flow monitoring using the version 9 template format to collect trafficflows.

Options template-name—Name of a version 9 record flow format template configured at the[edit services monitoring] hierarchy level.

Usage Guidelines See “Configuring Active Flow Monitoring Using Version 9” on page 316

Required Privilege Level interface—To view this statement in the configuration.interface-level—To add this statement to the configuration.

Related Topics JUNOS Services Interfaces Configuration Guide and JUNOS Feature Guide

world-readable

Syntax (world-readable | no-world-readable);

Hierarchy Level [edit forwarding-options helpers traceoptions file],[edit forwarding-options packet-capture file],[edit forwarding-options port-mirroring traceoptions file],[edit forwarding-options sampling output file],[edit forwarding-options sampling traceoptions file]


Description Enable unrestricted file access.

Options no-world-readable—Restrict file access to owner.

world-readable—Enable unrestricted file access.Default: no-world-readable



version9 ■ 481


482 ■ world-readable


Part 5

Indexes

■ Index on page 485

■ Index of Statements and Commands on page 495

Indexes ■ 483

484 ■ Indexes


Index

Symbols!

in policy expressionslogical operator..............................................61

! (negation)in firewall filters

bit-field logical operator...............................205#, comments in configuration statements................xxxii&&, logical operator.....................................................60&, bit-field logical operator.........................................205( ), in syntax descriptions.........................................xxxii+

bit-field logical operator......................................205, (comma), bit-field logical operator...........................205< >, in syntax descriptions.....................................xxxi[ ], in configuration statements................................xxxii{ }, in configuration statements...............................xxxii| (pipe)

in firewall filtersbit-field logical operator...............................205

| (pipe), in syntax descriptions.................................xxxii|| (pipes), logical operator............................................60

Aaccept

firewall filter action.............................................208firewall filters

action..........................................................308policy, routing

control action................................................49access and access-internal routes

importing and exporting in routing policies..........74accounting statement.................................................370

usage guidelines..................................................326accounting-profile statement......................................283

firewallusage guidelines..........................................244

action modifiers, firewall filters..................................209action statement........................................................284

policer (TCM)usage guidelines..........................................277

actionsfirewall filters..............................................173, 208policy, routing.......................................................25

characteristics, manipulating.........................49flow control.............................................47, 49tracing...........................................................47

tracing..................................................................56active-server-group statement....................................371

usage guidelines..................................................357address (filter match conditions)................................200address (firewall filter match condition).....................201aggregate policer........................................................268aggregation statement................................................372

usage guidelines..................................................326always-write-giaddr statement...................................373

usage guidelines..................................................350always-write-option-82 statement..............................374

usage guidelines..................................................350ampersand (&), bit-field logical operator....................205apply-path statement.................................................155

usage guidelines..................................................118area (routing policy match condition)...........................43as-path (routing policy match condition)......................43as-path statement......................................................156

policy, routingusage guidelines............................................98

as-path-group statement............................................157usage guidelines....................................................98

as-path-prepend (routing policy action)................49, 137ASs

pathsmodifying with routing policy................49, 137

regular expressions See policy, routing, AS pathregular expressions

authentication statement...........................................375autonomous-system-type statement..........................376

usage guidelines..................................................313

Bbandwidth policer......................................................274BGP

communitiesnames.........................................................106policy, routing......................................104, 158

damping parameters...................................138, 161

Index ■ 485

dynamic routing policiesapplying.........................................................68

extended communities.......................................109policy, routing

applying.........................................................28bit-field

firewall filter match conditions...................203, 204logical operators.................................................205

BOOTP relay agent....................................................331bootp statement.........................................................377

usage guidelines..................................................331braces, in configuration statements..........................xxxiibrackets

angle, in syntax descriptions..............................xxxisquare, in configuration statements..................xxxii

Ccflowd statement.......................................................378

usage guidelines..................................................313circuit-id statement....................................................381

usage guidelines..................................................354circuit-type statement................................................382class (routing policy action)..........................................50class-based firewall filter match conditions................205client-response-ttl statement......................................382color

policy, routingaction............................................................50match condition............................................43

comments, in configuration statements...................xxxiicommunities

extend range of BGP communities......................109names.................................................................106policy, routing.............................................104, 158

action............................................................50match condition............................................43

community statement................................................158policy, routing

usage guidelines..........................................106condition statement...................................................160conventions

text and syntax..................................................xxxicount

firewall filter action modifier...............................209curly braces, in configuration statements.................xxxiicustomer support....................................................xxxiii

contacting JTAC................................................xxxiii

Ddamping

policy, routing, action...........................................50

damping statement....................................................161BGP

usage guidelines..........................................142policy, routing

usage guidelines..........................................139default-local-server-group statement..........................383

usage guidelines..................................................352default-relay-server-group statement..........................384

usage guidelines..................................................352delimiter statement....................................................385description statement

helper service or interface...................................386service

usage guidelines..................................331, 333destination class usage...........................................51, 52destination-address (firewall filter match

condition)...............................................................201destination-class (routing policy action)..................51, 54destination-port (firewall filter match

condition).......................................................185, 206DHCP

relay agent..........................................................331relay agents, extended................................345, 348

access and access-internal routes..........74, 347active server groups.....................................357clearing client address bindings and

statistics...................................................360configuration examples.......363, 364, 365, 366how components interact....................346, 350interface groups...........................................358option 82 information.................................354option 60 information.................................352server groups...............................................357tracing operations........................................360verifying client address bindings and

statistics...................................................360snooping.............................................................336

DHCP local servergraceful Routing Engine switchover....................347

DHCP relaygraceful Routing Engine switchover....................347

dhcp-relay statement.................................................387DHCP relay agent................................................388DHCP snooping...................................................391usage guidelines..........................................345, 348

disable statementpacket capture....................................................391sampling.............................................................391traffic sampling

usage guidelines..........................................311disable-relay statement..............................................392

usage guidelines..................................................350discard

firewall filter action.............................................208discard interface..........................................................71

486 ■ Index


DNSpacket forwarding...............................................333requests, disabling recognition............................333

documentation setcomments on....................................................xxxii

domain statement......................................................393domain-name statement............................................394drop statement..........................................................395

usage guidelines..................................................352dscp (firewall filter match condition)..........................189DVMRP

policy, routingapplying.........................................................28

dynamic databaseactive nonstop routing..........................................68routing policies.....................................................66

dynamic routing policiesactive nonstop routing..........................................68BGP.......................................................................68configuring............................................................67dynamic-db statement........................................162overview...............................................................65

dynamic-db statement...............................................162usage guidelines....................................................67

Eether-pseudowire statement.......................................401

usage guidelines..................................................150evaluation

firewall filters......................................................181policy, routing ......................................................29

exact route list match type.................................120, 123examples

extended DHCP relay agent........363, 364, 365, 366except (firewall filter match condition)...............185, 201exclamation point ( ! ), bit-field logical operator.........205export routing policies

applying..................................................27, 57, 163from statement.....................................................59

export statement........................................................163policy, routing

usage guidelines................................27, 57, 64export-format statement............................................396


Ffamily inet statement (firewall filter)

usage guidelines..................................................178family inet statement (load balancing).......................400

usage guidelines..................................................322family mpls statement...............................................401

usage guidelines..........................................147, 150

family multiservice statement....................................403MX Series routers

usage guidelines..........................................153usage guidelines..................................................151VPLS load balancing

usage guidelines..........................................151family statement

firewall filter.......................................................285usage guidelines..........................................179

forwarding table filters........................................397port mirroring.....................................................399sampling.............................................................400

file statementhelpers trace options...........................................405packet capture....................................................405sampling.............................................................406traceoptions........................................................406traffic sampling output

usage guidelines..........................311, 313, 334filename statement....................................................407files

firewall log output file.........................................212logging information output file....................313, 334traffic sampling output files................................311var/log/sampled file.....................................313, 334var/tmp/sampled.pkts file...................................311

files statementpacket capture....................................................408sampling.............................................................408usage guidelines..................................................311

filter statementfirewall................................................................286

usage guidelines..........................................180forwarding table.................................................409VPLS...................................................................409

filter-specific statement..............................................287usage guidelines..................................................261

filtersinterface-specific counters..................................217

firewall filtersactions........................................................173, 208applying......................................................216, 247architecture ........................................................6, 8comparison with routing policies .....................9, 12configuration statements............................178, 283evaluation...........................................................181example filter definitions....................219, 220, 279family address type............................................179flow, packets ..........................................................3in traffic sampling...............................................308log output file......................................................212match conditions........................................173, 182

MPLS...........................................................196names.................................................................180numeric match conditions, IPv6 (table).......185, 189

Index ■ 487

Index

numeric match conditions, Layer 2 bridging(MX-series routers)..........................................197

overview.....................................................173, 253physical interface filters......................................291policing...............................................................255protocol families.................................................173purpose...................................................................9service filters.......................................................228show firewall filters command............................212simple filters.......................................................229system logging....................................................249terms..................................................................180testing packet protocols......................................206

firewall log output file................................................212firewall statement......................................................287

usage guidelines..................................................178first-fragment (firewall filter match condition)............205flood statement..........................................................410

usage guidelines..................................................326flooding

IS-IS and OSPF......................................................20flow aggregation........................................................313flow control actions................................................47, 49flow-active-timeout statement....................................410

accountingusage guidelines..........................................326

samplingusage guidelines..........................................311

flow-export-destination statement..............................411usage guidelines..................................................328

flow-inactive-timeout statement.................................411accounting

usage guidelines..........................................326sampling

usage guidelines..........................................311font conventions.......................................................xxxiforwarding table

filters..........................................................247, 325policy, routing

applying...................................................29, 64forwarding-class

firewall filter action modifier...............................209forwarding-options statement....................................412

usage guidelines..................................................321fragment-flags (firewall filter match condition)...........205fragment-offset (firewall filter match condition).........185from statement..........................................................167

firewall filtersusage guidelines..................................181, 182

policy, routingomitting.........................................................59usage guidelines............................................41

FTP traffic, sampling..................................................319

Ggraceful Routing Engine switchover

DHCP..................................................................347group statement.........................................................413

DHCP relay agent................................................414DHCP snooping...................................................415usage guidelines..................................................358

Hhash-key statement....................................................416

usage guidelines..................................................322hash-seed statement

load balancing............................................451, 452helpers statement......................................................419

Iicmp-code (firewall filter match condition).................189icmp-type (firewall filter match condition).........185, 206icons defined, notice..................................................xxxif-exceeding statement...............................................288if-route-exists statement.............................................160import routing policies

applying............................................27, 57, 60, 165overview...............................................................17

import statement.......................................................165policy, routing

usage guidelines......................................27, 57indexed-next-hop statement......................................420input statement..........................................................421


forwarding table.................................................421port mirroring.....................................................421sampling.............................................................422traffic sampling...................................................421

usage guidelines..........................................309usage guidelines..................................................325

install-nexthop lsp (routing policy action).....................51instance (routing policy match condition)....................43instance statement

port mirroring.....................................................423instance-name.inet.0 routing table...............................19interface (routing policy match condition)....................43interface policers........................................................267interface set...............................................................267interface statement

accounting or sampling.......................................424BOOTP................................................................425DHCP relay agent................................................427DNS or TFTP packet forwarding or relay

agent...............................................................426monitoring..........................................................428next-hop group...................................................428port mirroring.....................................................429

488 ■ Index


snooping.............................................................426usage guidelines..........................................331, 358

interface-group (firewall filter match condition).........185interface-set statement...............................................289

usage guidelines..................................................267interface-specific statement.......................................289

usage guidelines..................................................217invert-match statement

usage guidelines..................................................111IP addresses

sampling traffic from single IP addresses............318ip-options (firewall filter match condition)..................205ipsec-sa

firewall filter action modifier...............................209IPv6

firewall filter match conditions...................185, 189IPv6 accounting, configuring......................................326IS-IS


Jjoins, PIM

rejecting..............................................................129

Llayer-3 statement

load balancingusage guidelines..........................................153

layer-3-only statementusage guidelines..................................................151

layer-4 statementload balancing

usage guidelines..........................................153layer2-unicast-replies statement.................................429

usage guidelines..................................................350LDP


level (routing policy match condition)..........................44load balancing

Ethernet pseudowires.........................................150per-flow......................................................329, 331per-packet...........................................................144

IPv4.............................................................145mpls............................................................147

per-prefix............................................................330VPLS

M120 and M320 routers..............................151VPLs

MX Series routers........................................153load-balance group.....................................................275load-balance statement..............................................430


load-balance-group statement....................................290usage guidelines..................................................275

local-dump statement................................................431usage guidelines..........................................313, 315

local-preferencepolicy, routing

action............................................................51match condition............................................44

local-server-group statement......................................432usage guidelines..................................................352

logfirewall filter action modifier...............................209

log outputfirewall filters......................................................212traffic sampling...........................................313, 334

logical routers See logical systemslogical systems

configuring firewall filters...................................231logical-bandwidth-policer statement...........................290

usage guidelines..................................................274logical-interface-policer statement..............................291

usage guidelines..........................................268, 278logical-system-name statement..................................433longer route list match type...............................120, 123loss-priority

firewall filter action modifier...............................209

Mmac-address statement..............................................434manuals

comments on....................................................xxxiimatch conditions

firewall filtersaddress filter................................................200bit-field................................................203, 204class-based filter..........................................205from statement............................................182numeric range filter.....................................183overview..............................................173, 182

policy, routing.................................................24, 41max-packets-per-second statement............................434maximum-capture-size statement..............................435maximum-hop-count statement.................................435

usage guidelines..................................................331maximum-packet-length statement............................436metric


minimum-wait-time statement...................................436mirror-once statement...............................................437monitoring statement................................................438


Index ■ 489

Index

MPLSfirewall filters

match conditions.........................................196policy, routing

applying.........................................................28multicast-scoping

policy, routingmatch condition............................................44

Nnames

firewall filters......................................................180policy, routing.......................................................40

neighbor (routing policy match condition)...................45next policy (routing policy control action)....................49next term

firewall filter action.............................................208next term (routing policy control action)......................49next-hop


next-hop groups.........................................................329next-hop statement....................................................439

next-hop groupsusage guidelines..........................................329

next-hop-group statement..........................................440usage guidelines..................................................329

no-filter-check statement............................................441no-label-1-exp statement

usage guidelines..................................................147no-listen statement

usage guidelines..................................................331no-local-dump statement...........................................431

usage guidelines..................................................313no-stamp statement...................................................469

usage guidelines..................................................311no-world-readable statement.....................................481

usage guidelines..................................................313noncontiguous address filter......................................202notice icons defined...................................................xxxnumeric range firewall filter match conditions...........183

Ooption 82 information, DHCP.....................................354option-60 statement...................................................442option-82 statement...................................................443option 60 information, DHCP.....................................352origin


orlonger route list match type............................120, 123

OSPFpolicy, routing

applying.........................................................28output files

firewall log output file.........................................212logging information output file....................313, 334traffic sampling output files................................311

output statement........................................................444accounting..........................................................444firewall filters

usage guidelines..................................216, 247forwarding table.................................................445monitoring..........................................................445port mirroring.....................................................446sampling.............................................................447usage guidelines..................................................325

overrides statement...................................................448usage guidelines..................................................350

Ppacket capture...........................................................341packet counter

firewall filters......................................................212packet-capture statement...........................................449packet-length (firewall filter match condition)............185packets

testing packet protocols......................................206parentheses, in syntax descriptions..........................xxxiipassword statement...................................................450payload statement

usage guidelines..................................................151per-flow load balancing..............................................331per-flow statement.....................................................451per-prefix load balancing...........................................330per-prefix statement..................................................452physical-interface-filter statement..............................291

usage guidelines..................................................270physical-interface-policer statement...........................292

usage guidelines..................................................270PIM

multicast traffic joins, rejecting...........................129policy, routing

applying.........................................................28pipe ( | )

bit-field logical operator......................................205plus sign (+), bit-field logical operator.......................205policer

firewall filter action modifier...............................209policer statement.......................................................293

firewallusage guidelines..........................................259

policersexample configurations.......................................279interface.............................................................267

490 ■ Index


physical interface................................................292configuring..................................................270

policer action portion..........................................259policy (routing policy match condition)........................45policy framework

architecture ............................................................6comparison of policies ...........................................9firewall filters..........................................................3overview.................................................................3policy, routing.........................................................3

policy, routingaccess and access-internal routes..........................74actions..........................................25, 47, 51, 52, 57applying................................................57, 164, 166

overview........................................................26architecture ............................................................6AS path regular

expressions.......................97, 104, 155, 156, 157BGP damping parameters...................................161chains

applying.........................................................57evaluation......................................................30

communities...............................................104, 158comparison with firewall filters ..............................9configuring..........................................36, 37, 39, 72

overview .................................................23, 29default policies and actions...................................20evaluation ............................................................29export policies..............................................27, 163flow, routing information .......................................3framework............................................................16import policies..................................17, 27, 64, 165match conditions......................................24, 41, 47multiple policies

applying.........................................................57evaluation......................................................30

overview.........................................................15, 16policy expressions .........................................59, 64preferences, modifying.........................................53prefix list ...................................................117, 169prefix list filter............................................120, 170purpose...................................................................9rejecting PIM multicast traffic joins.....................129route lists....................................................121, 129source prefixes, group..........................................80subroutines ..........................................31, 130, 134terms..............................................................26, 40testing...................................................................33uses for...........................................................22, 23

policy-options statement............................................166usage guidelines....................................................35

policy-statement statement........................................167from statement.....................................................41then statement.....................................................47to statement.........................................................41usage guidelines....................................................40

port (firewall filter match condition)...................185, 206port mirroring............................................................337

mirror-once statement........................................437multiple instances...............................................423

port statement...........................................................452usage guidelines..................................................313

port-mirrorfirewall filter action modifier...............................209

port-mirroring statement...........................................453usage guidelines..................................................337

precedence (firewall filter match condition).......185, 189preferences

modifyingwith routing policies......................................53


prefix list ...........................................................117, 169prefix list filter...........................................................170prefix statement.........................................................455

usage guidelines..................................................354prefix-action statement..............................................294

usage guidelines..................................................262prefix-length-range match type..................................123prefix-list (routing policy match condition)...................46prefix-list statement...................................................169

usage guidelines..........................................118, 202prefix-list-filter statement...........................................170protocols

applying policies...................................................26firewall filter match condition.............................189match condition

firewall filters...............................................185policy, routing................................................46

routingapplying policies............................................64

testing packet protocols......................................206

Rrate statement............................................................456

usage guidelines..................................................309reject

firewall filter action.............................................208policy, routing

control action................................................49relay agents

DHCP and BOOTP..............................................331relay agents, DHCP

extended.....................................................345, 348access and access-internal routes..........74, 347active server groups.....................................357clearing client address bindings and

statistics...................................................360configuration examples.......363, 364, 365, 366how components interact............................346

Index ■ 491

Index

interface groups...........................................358option 82 information.................................354option 60 information.................................352overriding default configuration...................350server groups...............................................357tracing operations........................................360using external authentication.......................359verifying client address bindings and

statistics...................................................360relay-option-60 statement..........................................457

configuration example................................365, 366usage guidelines..................................................352

relay-option-82 statement..........................................458usage guidelines..................................................354

relay-server-group statement.....................................459usage guidelines..................................................352

replace-ip-source-with statement................................460rib (routing policy match condition).............................46RIP


route lists...................................................................121route recording..........................................................313route-accounting statement........................................460

usage guidelines..................................................326route-filter (routing policy match condition).................46routers

DHCP relay agents..............................................331routing policies

dynamicconfiguring....................................................67

dynamic database.................................................66routing policy See policy, routingrouting tables

instance-name.init.0.............................................19routing-instance

firewall filter action.............................................208routing-instance statement

usage guidelines..................................................331routing-instance-name statement...............................461RPF

firewall log and count.........................................213run-length statement..................................................462


Ssample

firewall filter action modifier...............................209sample (firewall filter action)......................................308sampled file.......................................................313, 334sampled.pkts file........................................................311sampling statement...................................................463


server statementDHCP and BOOTP service ..................................465DNS and TFTP service ........................................466usage guidelines..................................................331

server-group statement..............................................467usage guidelines..................................................357

service filters..............................................................228service-filter statement

firewall................................................................295show chassis hardware command

usage guidelines..................................................305show firewall filter command.....................................212show interfaces policers command............................268show log command....................................................213show policers command............................................257show policy damping command................................143

usage guidelines..................................................139show route detail command

usage guidelines..................................................139show route receive-protocol command

usage guidelines....................................................47simple filters..............................................................229simple-filter statement

firewall................................................................296usage guidelines..........................................229

single-rate statementusage guidelines..................................................275

size statementpacket capture....................................................468sampling.............................................................469

snooping, DHCP.........................................................336SONET interfaces

sampling.............................................................317source class usage..................................................54, 80source-address (firewall filter match

condition)...............................................185, 189, 201source-address-filter (routing policy match

condition).................................................................47source-class (routing policy action)...............................54source-port (firewall filter match

condition)...............................................185, 189, 206stamp option..............................................................312stamp statement........................................................469

usage guidelines..................................................311subroutines .........................................................31, 130support, technical See technical supportsyntax conventions...................................................xxxisyslog

firewall filter action modifier...............................209

Ttable statement..........................................................160tag

policy, routingaction............................................................54

492 ■ Index


tcp-established (firewall filter match condition)..........205tcp-flags (firewall filter match condition)....................204tcp-initial (firewall filter match condition)...................205technical support

contacting JTAC................................................xxxiiiterm statement

firewall................................................................297usage guidelines..........................................180

policyusage guidelines............................................40

termsfirewall filters......................................................180policy, routing.................................................26, 40

test policy command ...................................................33TFTP

packet forwarding...............................................333requests, disabling recognition............................333

tftp statement............................................................470then statement...........................................................167


policy, routingusage guidelines............................................47

three-color-policer statement.....................................300usage guidelines..................................................275

through route list match type.....................................123timestamp option.......................................................312to statement...............................................................167

usage guidelines....................................................41topology

firewall filter action.............................................208trace (policy tracing action)....................................47, 56traceoptions statement

DNS and TFTP packet forwarding.......................472extended DHCP relay agent................................474

usage guidelines..........................................360port mirroring and traffic sampling.....................476usage guidelines..................................................323

tracing actions.......................................................47, 56traffic

accounting..........................................................326forwarding

configuration statements.............................321overview......................................................321

monitoring..........................................................328sampling

configuration statements.....................307, 369disabling..............................................311, 391DNS and TFTP packet forwarding................333example configurations...............................317flow aggregation..........................................313FTP traffic....................................................319logging information output

file............................................313, 325, 334output files...................................................311overview......................................................307

run-length parameter...................................309sampling rate parameter.............................309show log command.....................................213SONET interfaces.........................................317traffic from single IP addresses....................318

traffic samplingconfiguring..........................................................308

traffic-class (firewall filter match condition)........185, 189tricolor marking policer..............................................275

interface policer..................................................277trust-option-82 statement...........................................476

usage guidelines..................................................350two-rate statement


Uunicast RPF................................................................221upto route list match type..........................................123user-prefix statement.................................................477username-include statement......................................478

Vvar/log/jdhcpd file......................................................360var/log/sampled file....................................313, 325, 334var/tmp/sampled.pkts file...........................................311vendor-option statement............................................479

usage guidelines..................................................352version statement......................................................480

usage guidelines..................................................313version9 statement....................................................481

usage guidelines..................................................316virtual-channel statement...........................................301VPLS load balancing

M120 and M320 routers.....................................151MX Series routers................................................153

Wworld-readable statement..........................................481


Index ■ 493

Index

494 ■ Index


Index of Statements and Commands

Aaccounting statement.................................................370accounting-profile statement......................................283action statement........................................................284active-server-group statement....................................371aggregation statement................................................372always-write-giaddr statement...................................373always-write-option-82 statement..............................374apply-path statement.................................................155as-path statement......................................................156as-path-group statement............................................157authentication statement...........................................375autonomous-system-type statement..........................376

Bbootp statement.........................................................377

Ccflowd statement.......................................................378circuit-id statement....................................................381circuit-type statement................................................382client-response-ttl statement......................................382community statement................................................158condition statement...................................................160

Ddamping statement....................................................161default-local-server-group statement..........................383default-relay-server-group statement..........................384delimiter statement....................................................385description statement

helper service or interface...................................386dhcp-relay statement

DHCP relay agent................................................388DHCP snooping...................................................391

disable statementpacket capture....................................................391sampling.............................................................391

disable-relay statement..............................................392domain statement......................................................393domain-name statement............................................394

drop statement..........................................................395dynamic-db statement...............................................162

Eether-pseudowire statement.......................................401export statement........................................................163export-format statement............................................396

Ffamily inet statement (load balancing).......................400family mpls statement...............................................401family multiservice statement....................................403family statement

firewall filter.......................................................285forwarding table filters........................................397port mirroring.....................................................399sampling.............................................................400

file statementhelpers trace options...........................................405packet capture....................................................405sampling.............................................................406traceoptions........................................................406

filename statement....................................................407files statement

packet capture....................................................408sampling.............................................................408

filter statementfirewall................................................................286forwarding table.................................................409VPLS...................................................................409

filter-specific statement..............................................287firewall statement......................................................287flood statement..........................................................410flow-active-timeout statement....................................410flow-export-destination statement..............................411flow-inactive-timeout statement.................................411forwarding-options statement....................................412from statement..........................................................167

Ggroup statement

DHCP relay agent................................................414DHCP snooping...................................................415

Index of Statements and Commands ■ 495

Hhash-key statement....................................................416helpers statement......................................................419

Iif-exceeding statement...............................................288if-route-exists statement.............................................160import statement.......................................................165indexed-next-hop statement......................................420input statement..........................................................421

forwarding table.................................................421port mirroring.....................................................421sampling.............................................................422

instance statementport mirroring.....................................................423

interface statementaccounting or sampling.......................................424BOOTP................................................................425DHCP relay agent................................................427DNS or TFTP packet forwarding or relay

agent...............................................................426monitoring..........................................................428next-hop group...................................................428port mirroring.....................................................429snooping.............................................................426

interface-set statement...............................................289interface-specific statement.......................................289

Llayer2-unicast-replies statement.................................429load-balance statement..............................................430load-balance-group statement....................................290local-dump statement................................................431local-server-group statement......................................432logical-bandwidth-policer statement...........................290logical-interface-policer statement..............................291logical-system-name statement..................................433

Mmac-address statement..............................................434max-packets-per-second statement............................434maximum-capture-size statement..............................435maximum-hop-count statement.................................435minimum-wait-time statement...................................436mirror-once statement...............................................437monitoring statement................................................438

Nnext-hop statement....................................................439next-hop-group statement..........................................440no-filter-check statement............................................441no-stamp statement...................................................469

no-world-readable statement.....................................481

Ooption-60 statement...................................................442option-82 statement...................................................443output statement........................................................444

accounting..........................................................444forwarding table.................................................445monitoring..........................................................445port mirroring.....................................................446sampling.............................................................447

overrides statement...................................................448

Ppacket-capture statement...........................................449password statement...................................................450per-flow statement.....................................................451per-prefix statement..................................................452physical-interface-filter statement..............................291physical-interface-policer statement...........................292policer statement.......................................................293policy-options statement............................................166policy-statement statement........................................167port statement...........................................................452port-mirroring statement...........................................453prefix statement.........................................................455prefix-action statement..............................................294prefix-list statement...................................................169prefix-list-filter statement...........................................170

Rrate statement............................................................456relay-option-60 statement..........................................457relay-option-82 statement..........................................458relay-server-group statement.....................................459replace-ip-source-with statement................................460route-accounting statement........................................460routing-instance-name statement...............................461run-length statement..................................................462

Ssampling statement...................................................463server statement

DHCP and BOOTP service ..................................465DNS and TFTP service ........................................466

server-group statement..............................................467service-filter statement

firewall................................................................295show firewall filter command.....................................212show interfaces policers command............................268show log command....................................................213show policers command............................................257

496 ■ Index of Statements and Commands


show policy damping command ...............................143simple-filter statement

firewall................................................................296size statement

packet capture....................................................468sampling.............................................................469

Ttable statement..........................................................160term statement

firewall................................................................297test policy command ...................................................33tftp statement............................................................470then statement...........................................................167three-color-policer statement.....................................300to statement...............................................................167traceoptions statement

DNS and TFTP packet forwarding.......................472extended DHCP relay agent................................474port mirroring and traffic sampling.....................476

trust-option-82 statement...........................................476

Uuser-prefix statement.................................................477username-include statement......................................478

Vvendor-option statement............................................479version statement......................................................480version9 statement....................................................481virtual-channel statement...........................................301

Wworld-readable statement..........................................481

Index of Statements and Commands ■ 497

Index of Statements and Commands

498 ■ Index of Statements and Commands


Config Guide Policy

Documents

Transcript of Config Guide Policy