Config Guide Firewall Policer

Junos OS
Firewall Filter and Policer Configuration Guide
Release
11.4
Published: 2011-11-08
Copyright 2011, Juniper Networks, Inc.
Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright 1986-1997, Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part of them is in the public domain. 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 software included 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 by Cornell University and its collaborators. Gated is based on Kirtons EGP, UC Berkeleys routing daemon (routed), and DCNs 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 the University 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, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
Junos OS Firewall Filter and Policer Configuration Guide 11.4 Copyright 2011, Juniper Networks, Inc. All rights reserved. Revision History October 2011R1 Junos OS 11.4 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. Junos OS has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement (EULA) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions
of that EULA.
ii
Abbreviated Table of Contents

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Part 1
Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9
Stateless Firewall Filters

Introduction to Stateless Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Standard Firewall Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Standard Firewall Filter Match Conditions Overview . . . . . . . . . . . . . . . . . . . 31 Standard Firewall Filter Match Conditions and Actions . . . . . . . . . . . . . . . . . 47 Standard Firewall Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Service Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Simple Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Stateless Firewall Filter Configuration in Logical Systems . . . . . . . . . . . . . 261 Summary of Stateless Firewall Filter Configuration Statements . . . . . . . 283
Part 2
Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15
Traffic Policers
Introduction to Traffic Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Single-Rate Two-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . 327 Three-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Logical and Physical Interface Policer Configuration . . . . . . . . . . . . . . . . . . 415 Layer 2 Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 Summary of Policer Configuration Statements . . . . . . . . . . . . . . . . . . . . . . 455
Part 3
Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 Index of Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
iii
Junos OS 11.4 Firewall Filter and Policer Configuration Guide
iv
Table of Contents
Junos OS Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii Using the Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvi Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvi Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Part 1
Chapter 1

Introduction to Stateless Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Router Data Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Flow of Routing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Flow of Data Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Flow of Local Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Interdependent Flows of Routing Information and Packets . . . . . . . . . . . . . . . 4 Stateless Firewall Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Packet Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Data Packet Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Local Packet Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Stateless and Stateful Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Purpose of Stateless Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Stateless Firewall Filter Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Standard Stateless Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Service Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Simple Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Stateless Firewall Filter Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Protocol Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Filter Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Filter-Terminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Nonterminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Flow Control Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Stateless Firewall Filter Application Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Supported Standards for Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Using the CLI Editor in Configuration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 2
Standard Firewall Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Standard Stateless Firewall Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 How Standard Firewall Filters Evaluate Packets . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Firewall Filters That Contain a Single Term . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Firewall Filters That Contain Multiple Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Firewall Filter Terms That Do Not Contain Any Match Conditions . . . . . . . . . . 21 Firewall Filter Terms That Do Not Contain Any Actions . . . . . . . . . . . . . . . . . . 21 Firewall Filter Default Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Guidelines for Configuring Standard Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . 21 Statement Hierarchy for Configuring Standard Firewall Filters . . . . . . . . . . . . 22 Standard Firewall Filter Protocol Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Standard Firewall Filter Names and Options . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Standard Firewall Filter Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Standard Firewall Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Standard Firewall Filter Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Guidelines for Applying Standard Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Applying Standard Firewall Filters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Applying a Firewall Filter to a Routers Physical Interfaces . . . . . . . . . . . 26 Applying a Firewall Filter to the Routers Loopback Interface . . . . . . . . . 26 Applying a Firewall Filter to Multiple Interfaces . . . . . . . . . . . . . . . . . . . . 27 Statement Hierarchy for Applying Standard Firewall Filters . . . . . . . . . . . . . . 27 Restrictions on Applying Standard Firewall Filters . . . . . . . . . . . . . . . . . . . . . . 27 Number of Input and Output Filters Per Logical Interface . . . . . . . . . . . . 28 MPLS and Layer 2 CCC Firewall Filters in Lists . . . . . . . . . . . . . . . . . . . . . 28 Layer 2 CCC Firewall Filters on MX Series Routers . . . . . . . . . . . . . . . . . . 28 Protocol-Independent Firewall Filters on the Loopback Interface . . . . . 28 Understanding How to Use Standard Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . 29 Using Standard Firewall Filters to Affect Local Packets . . . . . . . . . . . . . . . . . 29 Trusted Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Flood Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Using Standard Firewall Filters to Affect Data Packets . . . . . . . . . . . . . . . . . 30
Chapter 3
Standard Firewall Filter Match Conditions Overview . . . . . . . . . . . . . . . . . . . 31

Firewall Filter Match Conditions Based on Numbers or Text Aliases . . . . . . . . . . . 31 Matching on a Single Numeric Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Matching on a Range of Numeric Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Matching on a Text Alias for a Numeric Value . . . . . . . . . . . . . . . . . . . . . . . . . 32 Matching on a List of Numeric Values or Text Aliases . . . . . . . . . . . . . . . . . . . 32 Firewall Filter Match Conditions Based on Bit-Field Values . . . . . . . . . . . . . . . . . . 32 Match Conditions for Bit-Field Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Match Conditions for Common Bit-Field Values or Combinations . . . . . . . . . 33 Logical Operators for Bit-Field Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Matching on a Single Bit-Field Value or Text Alias . . . . . . . . . . . . . . . . . . . . . . 35 Matching on Multiple Bit-Field Values or Text Aliases . . . . . . . . . . . . . . . . . . . 35 Matching on a Negated Bit-Field Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
vi
Table of Contents
Matching on the Logical OR of Two Bit-Field Values . . . . . . . . . . . . . . . . . . . 36 Matching on the Logical AND of Two Bit-Field Values . . . . . . . . . . . . . . . . . . 36 Grouping Bit-Field Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Firewall Filter Match Conditions Based on Address Fields . . . . . . . . . . . . . . . . . . . 37 Implied Match on the 0/0 except Address for Firewall Filter Match Conditions Based on Address Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Matching an Address Field to a Subnet Mask or Prefix . . . . . . . . . . . . . . . . . . 37 IPv4 Subnet Mask Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Prefix Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Default Prefix Length for IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 38 Default Prefix Length for IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 38 Default Prefix Length for MAC Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 38 Matching an Address Field to an Excluded Value . . . . . . . . . . . . . . . . . . . . . . 38 Excluding IP Addresses in IPv4 or IPv6 Traffic . . . . . . . . . . . . . . . . . . . . . 38 Excluding IP Addresses in VPLS or Layer 2 Bridging Traffic . . . . . . . . . . . 39 Excluding MAC Addresses in VPLS or Layer 2 Bridging Traffic . . . . . . . . . 40 Excluding All Addresses Requires an Explicit Match on the 0/0 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Matching Either IP Address Field to a Single Value . . . . . . . . . . . . . . . . . . . . . 42 Matching Either IP Address Field in IPv4 or IPv6 Traffic . . . . . . . . . . . . . . 42 Matching Either IP Address Field in VPLS or Layer 2 Bridging Traffic . . . . 42 Matching an Address Field to Noncontiguous Prefixes . . . . . . . . . . . . . . . . . . 42 Matching an Address Field to a Prefix List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Firewall Filter Match Conditions Based on Address Classes . . . . . . . . . . . . . . . . . 45 Source-Class Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Destination-Class Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Guidelines for Applying SCU or DCU Firewall Filters to Output Interfaces . . . 45
Chapter 4
Standard Firewall Filter Match Conditions and Actions . . . . . . . . . . . . . . . . . 47

Standard Firewall Filter Match Conditions for Protocol-Independent Traffic . . . . 47 Standard Firewall Filter Match Conditions for IPv4 Traffic . . . . . . . . . . . . . . . . . . . 48 Standard Firewall Filter Match Conditions for IPv6 Traffic . . . . . . . . . . . . . . . . . . . 57 Standard Firewall Filter Match Conditions for MPLS Traffic . . . . . . . . . . . . . . . . . 62 Standard Firewall Filter Match Conditions for MPLS-Tagged IPv4 Traffic . . . . . . 64 Matching on IPv4 Packet Header Address or Port Fields in MPLS Flows . . . . 64 IP Address Match Conditions for MPLS Traffic . . . . . . . . . . . . . . . . . . . . . . . . 65 IP Port Match Conditions for MPLS Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Standard Firewall Filter Match Conditions for VPLS Traffic . . . . . . . . . . . . . . . . . . 66 Standard Firewall Filter Match Conditions for Layer 2 CCC Traffic . . . . . . . . . . . . . 73 Standard Firewall Filter Match Conditions for Layer 2 Bridging Traffic . . . . . . . . . 75 Standard Firewall Filter Terminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Standard Firewall Filter Nonterminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Chapter 5
Standard Firewall Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Standard Firewall Filters That Match Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Example: Configuring a Filter to Match on IPv6 Flags . . . . . . . . . . . . . . . . . . . 89 Example: Configuring a Filter to Match on Port and Protocol Fields . . . . . . . . 91 Example: Configuring a Filter to Match on Two Unrelated Criteria . . . . . . . . . 94
vii
Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Standard Firewall Filters That Count Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Example: Configuring a Filter to Count Accepted and Rejected Packets . . . 100 Example: Configuring a Filter to Count and Discard IP Options Packets . . . . 103 Example: Configuring a Filter to Count IP Options Packets . . . . . . . . . . . . . . 106 Standard Firewall Filters That Act on Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Example: Configuring a Filter to Set the DSCP Bit to Zero . . . . . . . . . . . . . . . . 111 Example: Configuring a Filter to Count and Sample Accepted Packets . . . . . 114 Standard Firewall Filters for Trusted Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Example: Configuring a Filter to Block Telnet and SSH Access . . . . . . . . . . . 123 Example: Configuring a Filter to Block TFTP Access . . . . . . . . . . . . . . . . . . . 129 Example: Configuring a Filter to Accept OSPF Packets from a Prefix . . . . . . 132 Example: Configuring a Filter to Accept DHCP Packets Based on Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Standard Firewall Filters That Prevent IP Packet Flooding . . . . . . . . . . . . . . . . . . 143 Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Example: Configuring a Filter to Accept Packets Based on IPv6 TCP Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Standard Firewall Filters That Handle Fragmented Packets . . . . . . . . . . . . . . . . . 152 Firewall Filters That Handle Fragmented Packets Overview . . . . . . . . . . . . . 152 Example: Configuring a Stateless Firewall Filter to Handle Fragments . . . . . 152 Standard Firewall Filters That Set Rate Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Stateless Firewall Filters That Reference Policers Overview . . . . . . . . . . . . . 157 Example: Configuring a Rate-Limiting Filter Based on Destination Class . . . 158 Multiple Standard Firewall Filters Applied as a List . . . . . . . . . . . . . . . . . . . . . . . . 161 Multiple Standard Firewall Filters Applied as a List Overview . . . . . . . . . . . . 161 The Challenge: Simplify Large-Scale Firewall Filter Administration . . . . 161 A Solution: Apply Lists of Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . 162 Configuration of Multiple Filters for Filter Lists . . . . . . . . . . . . . . . . . . . . 162 Application of Filter Lists to a Router Interface . . . . . . . . . . . . . . . . . . . . 162 Interface-Specific Names for Filter Lists . . . . . . . . . . . . . . . . . . . . . . . . . 163 How Filter Lists Evaluate Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Guidelines for Applying Multiple Standard Firewall Filters as a List . . . . . . . 164 Statement Hierarchy for Applying Lists of Multiple Firewall Filters . . . . 164 Filter Input Lists and Output Lists for Router Interfaces . . . . . . . . . . . . . 164 Types of Filters Supported in Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Restrictions on Applying Filter Lists for MPLS or Layer 2 CCC Traffic . . . 165 Example: Applying Lists of Multiple Standard Firewall Filters . . . . . . . . . . . . 165 Multiple Standard Firewall Filters in a Nested Configuration . . . . . . . . . . . . . . . . 170 Multiple Standard Firewall Filters in a Nested Configuration Overview . . . . . 170 The Challenge: Simplify Large-Scale Firewall Filter Administration . . . 170 A Solution: Configure Nested References to Firewall Filters . . . . . . . . . . 171 Configuration of Nested Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . 171
viii
Table of Contents
Application of Nested Firewall Filters to a Router Interface . . . . . . . . . . . 171 Guidelines for Nesting References to Multiple Standard Firewall Filters . . . . 172 Statement Hierarchy for Configuring Nested Firewall Filters . . . . . . . . . 172 Filter-Defining Terms and Filter-Referencing Terms . . . . . . . . . . . . . . . . 172 Types of Filters Supported in Nested Configurations . . . . . . . . . . . . . . . 173 Number of Filter References in a Single Filter . . . . . . . . . . . . . . . . . . . . . 173 Depth of Filter Nesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Example: Nesting References to Multiple Standard Firewall Filters . . . . . . . . 173 Interface-Specific Firewall Filter Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Interface-Specific Firewall Filter Instances Overview . . . . . . . . . . . . . . . . . . . 177 Instantiation of Interface-Specific Firewall Filters . . . . . . . . . . . . . . . . . . 177 Interface-Specific Names for Firewall Filter Instances . . . . . . . . . . . . . . 178 Interface-Specific Firewall Filter Counters . . . . . . . . . . . . . . . . . . . . . . . 178 Interface-Specific Firewall Filter Policers . . . . . . . . . . . . . . . . . . . . . . . . 179 Statement Hierarchy for Configuring Interface-Specific Firewall Filters . . . . 179 Statement Hierarchy for Applying Interface-Specific Firewall Filters . . . . . . 180 Example: Configuring Interface-Specific Firewall Filter Counters . . . . . . . . . 180 Filtering Packets Received on a Set of Interface Groups . . . . . . . . . . . . . . . . . . . . 185 Filtering Packets Received on a Set of Interface Groups Overview . . . . . . . . 185 Statement Hierarchy for Assigning Interfaces to Interface Groups . . . . . . . . 185 Statement Hierarchy for Configuring a Filter to Match on a Set of Interface Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Statement Hierarchy for Applying Filters to an Interface Group . . . . . . . . . . 187 Example: Filtering Packets Received on an Interface Group . . . . . . . . . . . . . 188 Filtering Packets Received on an Interface Set . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Filtering Packets Received on an Interface Set Overview . . . . . . . . . . . . . . . 192 Statement Hierarchy for Defining an Interface Set . . . . . . . . . . . . . . . . . . . . 192 Statement Hierarchy for Configuring a Filter to Match on an Interface Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Example: Filtering Packets Received on an Interface Set . . . . . . . . . . . . . . . 193 Filter-Based Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Filter-Based Forwarding Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Filters That Classify Packets or Direct Them to Routing Instances . . . . 199 Input Filtering to Classify and Forward Packets Within the Router . . . . 200 Output Filtering to Forward Packets to Another Routing Table . . . . . . 200 Restrictions for Applying Filter-Based Forwarding . . . . . . . . . . . . . . . . 200 Statement Hierarchy for Configuring FBF for IPv4 or IPv6 Traffic . . . . . . . . . 201 Statement Hierarchy for Configuring FBF for MPLS-Tagged IPv4 Traffic . . . 201 Matching on IPv4 Address Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Matching on TCP Port Number Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Matching on UDP Port Number Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Statement Hierarchy for Configuring Routing Instances for FBF . . . . . . . . . 204 Statement Hierarchy for Applying FBF Filters to Interfaces . . . . . . . . . . . . . 205 Example: Configuring Filter-Based Forwarding on the Source Address . . . . 206 Accounting for Standard Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Accounting for Standard Firewall Filters Overview . . . . . . . . . . . . . . . . . . . . . 211 Statement Hierarchy for Configuring Firewall Filter Accounting Profiles . . . . 211 Statement Hierarchy for Applying Firewall Filter Accounting Profiles . . . . . . 212 Example: Configuring Statistics Collection for a Standard Firewall Filter . . . 213
ix
Logging of Stateless Firewall Filter Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 System Logging Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 System Logging of Events Generated for the Firewall Facility . . . . . . . . . . . . 219 Logging of Packet Headers Evaluated by a Firewall Filter Term . . . . . . . . . . . 221 Example: Configuring Logging for a Stateless Firewall Filter Term . . . . . . . . 222
Chapter 6
Service Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Service Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Service Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Service Rule Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Service Filter Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 How Service Filters Evaluate Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Service Filters That Contain a Single Term . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Service Filters That Contain Multiple Terms . . . . . . . . . . . . . . . . . . . . . . . . . 229 Service Filter Terms That Do Not Contain Any Match Conditions . . . . . . . . . 229 Service Filter Terms That Do Not Contain Any Actions . . . . . . . . . . . . . . . . . 229 Service Filter Default Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Guidelines for Configuring Service Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Statement Hierarchy for Configuring Service Filters . . . . . . . . . . . . . . . . . . . 230 Service Filter Protocol Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Service Filter Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Service Filter Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Service Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Service Filter Terminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Guidelines for Applying Service Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Restrictions for Adaptive Services Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 232 Adaptive Services Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 System Logging to a Remote Host from M Series Routers . . . . . . . . . . . 232 Statement Hierarchy for Applying Service Filters . . . . . . . . . . . . . . . . . . . . . 232 Associating Service Rules with Adaptive Services Interfaces . . . . . . . . . . . . 233 Filtering Traffic Before Accepting Packets for Service Processing . . . . . . . . 233 Postservice Filtering of Returning Service Traffic . . . . . . . . . . . . . . . . . . . . . . 234 Service Filter Match Conditions and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Service Filter Match Conditions for IPv4 or IPv6 Traffic . . . . . . . . . . . . . . . . . 235 Service Filter Terminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Service Filter Nonterminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Example: Configuring and Applying Service Filters . . . . . . . . . . . . . . . . . . . . . . . . 242
Chapter 7
Simple Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Simple Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 How Simple Filters Evaluate Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Simple Filters That Contain a Single Term . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Simple Filters That Contain Multiple Terms . . . . . . . . . . . . . . . . . . . . . . . . . 250 Simple Filter Terms That Do Not Contain Any Match Conditions . . . . . . . . . 250 Simple Filter Terms That Do Not Contain Any Actions . . . . . . . . . . . . . . . . . 250 Simple Filter Default Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Guidelines for Configuring Simple Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Statement Hierarchy for Configuring Simple Filters . . . . . . . . . . . . . . . . . . . . 251 Simple Filter Protocol Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Table of Contents
Simple Filter Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Simple Filter Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Simple Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Simple Filter Terminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Simple Filter Nonterminating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Guidelines for Applying Simple Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Statement Hierarchy for Applying Simple Filters . . . . . . . . . . . . . . . . . . . . . . 254 Restrictions for Applying Simple Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Example: Configuring and Applying a Simple Filter . . . . . . . . . . . . . . . . . . . . . . . 255
Chapter 8
Stateless Firewall Filter Configuration in Logical Systems . . . . . . . . . . . . . 261

Stateless Firewall Filters in Logical Systems Overview . . . . . . . . . . . . . . . . . . . . . 261 Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Stateless Firewall Filters in Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . 261 Identifiers for Firewall Objects in Logical Systems . . . . . . . . . . . . . . . . . . . . 262 Guidelines for Configuring and Applying Firewall Filters in Logical Systems . . . . 262 Statement Hierarchy for Configuring Firewall Filters in Logical Systems . . . 262 Filter Types in Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Firewall Filter Protocol Families in Logical Systems . . . . . . . . . . . . . . . . . . . 263 Firewall Filter Match Conditions in Logical Systems . . . . . . . . . . . . . . . . . . . 264 Firewall Filter Actions in Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Statement Hierarchy for Applying Firewall Filters in Logical Systems . . . . . 264 References from a Firewall Filter in a Logical System to Subordinate Objects . . 265 Resolution of References from a Firewall Filter to Subordinate Objects . . . 265 Valid Reference from a Firewall Filter to a Subordinate Object . . . . . . . . . . 265 References from a Firewall Filter in a Logical System to Nonfirewall Objects . . 266 Resolution of References from a Firewall Filter to Nonfirewall Objects . . . . 266 Valid Reference to a Nonfirewall Object Outside of the Logical System . . . 267 References from a Nonfirewall Object in a Logical System to a Firewall Filter . . 268 Resolution of References from a Nonfirewall Object to a Firewall Filter . . . 269 Invalid Reference to a Firewall Filter Outside of the Logical System . . . . . . 269 Valid Reference to a Firewall Filter Within the Logical System . . . . . . . . . . . 270 Valid Reference to a Firewall Filter Outside of the Logical System . . . . . . . . 272 Restrictions for Stateless Firewall Filters in Logical Systems . . . . . . . . . . . . . . . . 273 Unsupported Firewall Filter Statements for Logical Systems . . . . . . . . . . . . 273 Unsupported Actions for Firewall Filters in Logical Systems . . . . . . . . . . . . . 275 Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Chapter 9
Summary of Stateless Firewall Filter Configuration Statements . . . . . . . 283

accounting-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 enhanced-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 filter (Applying to a Logical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 filter (Configuring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 interface-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 interface-specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 service-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
xi
simple-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Part 2
Chapter 10
Traffic Policers
Introduction to Traffic Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Traffic Policing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Congestion Management for IP Traffic Flows . . . . . . . . . . . . . . . . . . . . . . . . 297 Traffic Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Traffic Color Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Forwarding Classes and PLP Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Policer Application to Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Traffic Policer Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Single-Rate Two-Color Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Basic Single-Rate Two-Color Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Bandwidth Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Logical Bandwidth Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Three-Color Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Single-Rate Three-Color Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Two-Rate Three-Color Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Hierarchical Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Two-Color and Three-Color Policer Options . . . . . . . . . . . . . . . . . . . . . . . . . 303 Logical Interface (Aggregate) Policers . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Physical Interface Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Policers Applied to Layer 2 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Multifield Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Order of Policer and Firewall Filter Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Introduction to Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Statement Hierarchy for Configuring Policers . . . . . . . . . . . . . . . . . . . . . . . . 305 Two-Color Policer Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Three-Color Policer Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Hierarchical Policer Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . 314 Guidelines for Applying Traffic Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Introduction to Policer Rate Limits and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Policer Bandwidth and Burst-Size Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Policer Color-Marking and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Single Token Bucket Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Token Bucket Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Single Token Bucket Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Conformance Measurement for Two-Color Marking . . . . . . . . . . . . . . . . 321 Dual Token Bucket Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Token Bucket Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Guaranteed Bandwidth for Three-Color Marking . . . . . . . . . . . . . . . . . . 322 Nonconformance Measurement for Single-Rate Three-Color Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Nonconformance Measurement for Two-Rate Three-Color Marking . . 323 Calculation of Policer Burst-Size Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Guidelines for Choosing a Burst-Size Limit . . . . . . . . . . . . . . . . . . . . . . . 323 Burst-Size Limit Based on the Line Rate of the Interface . . . . . . . . . . . . 325
xii
Table of Contents
Burst-Size Limit Based on the MTU of Traffic on the Interface . . . . . . . 325 Supported Standards for Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Chapter 11
Single-Rate Two-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . 327

Basic Single-Rate Two-Color Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Single-Rate Two-Color Policer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Example: Configuring a Single-Rate Two-Color Policer . . . . . . . . . . . . . . . . 328 Example: Configuring Interface and Firewall Filter Policers at the Same Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Bandwidth Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Bandwidth Policer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Guidelines for Configuring a Bandwidth Policer . . . . . . . . . . . . . . . . . . . 344 Guidelines for Applying a Bandwidth Policer . . . . . . . . . . . . . . . . . . . . . 344 Example: Configuring a Logical Bandwidth Policer . . . . . . . . . . . . . . . . . . . . 345 Filter-Specific Counters and Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Filter-Specific Policer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Prefix-Specific Counting and Policing Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Prefix-Specific Counting and Policing Overview . . . . . . . . . . . . . . . . . . . . . . 359 Separate Counting and Policing for Each IPv4 Address Range . . . . . . . 359 Prefix-Specific Action Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 Counter and Policer Set Size and Indexing . . . . . . . . . . . . . . . . . . . . . . . 361 Filter-Specific Counter and Policer Set Overview . . . . . . . . . . . . . . . . . . . . . 362 Example: Configuring Prefix-Specific Counting and Policing . . . . . . . . . . . . 362 Prefix-Specific Counting and Policing Configuration Scenarios . . . . . . . . . . 369 Prefix Length of the Action and Prefix Length of Addresses in Filtered Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Scenario 1: Firewall Filter Term Matches on Multiple Addresses . . . . . . 370 Scenario 2: Subnet Prefix Is Longer Than the Prefix in the Filter Match Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Scenario 3: Subnet Prefix Is Shorter Than the Prefix in the Firewall Filter Match Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Multifield Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Multifield Classification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Forwarding Classes and PLP Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Multifield Classification and BA Classification . . . . . . . . . . . . . . . . . . . . 376 Multifield Classification Used In Conjunction with Policers . . . . . . . . . . 376 Multifield Classification Requirements and Restrictions . . . . . . . . . . . . . . . . 377 Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 CoS Tricolor Marking Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Multifield Classification Limitations on M Series Routers . . . . . . . . . . . . . . . 378 Problem: Output-Filter Matching on Input-Filter Classification . . . . . . . 378 Workaround: Configure All Actions in the Ingress Filter . . . . . . . . . . . . . 379 Example: Configuring Multifield Classification . . . . . . . . . . . . . . . . . . . . . . . 380 Example: Configuring and Applying a Firewall Filter for a Multifield Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
xiii
Policer Overhead to Account for Rate Shaping in the Traffic Manager . . . . . . . . 390 Policer Overhead to Account for Rate Shaping Overview . . . . . . . . . . . . . . . 390 Example: Configuring Policer Overhead to Account for Rate Shaping . . . . . 391
Chapter 12
Three-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Three-Color Policer Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Platforms Supported for Three-Color Policers . . . . . . . . . . . . . . . . . . . . . . . 399 Color Modes for Three-Color Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Color-Blind Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Color-Aware Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Naming Conventions for Three-Color Policers . . . . . . . . . . . . . . . . . . . . . . . 400 Basic Single-Rate Three-Color Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Single-Rate Three-Color Policer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Example: Configuring a Single-Rate Three-Color Policer . . . . . . . . . . . . . . . 402 Basic Two-Rate Three-Color Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Two-Rate Three-Color Policer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Example: Configuring a Two-Rate Three-Color Policer . . . . . . . . . . . . . . . . 409
Chapter 13
Logical and Physical Interface Policer Configuration . . . . . . . . . . . . . . . . . . 415

Two-Color and Three-Color Logical Interface Policers . . . . . . . . . . . . . . . . . . . . . 415 Logical Interface (Aggregate) Policer Overview . . . . . . . . . . . . . . . . . . . . . . . 415 Example: Configuring a Two-Color Logical Interface (Aggregate) Policer . . 416 Example: Configuring a Three-Color Logical Interface (Aggregate) Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Two-Color and Three-Color Physical Interface Policers . . . . . . . . . . . . . . . . . . . . 427 Physical Interface Policer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Example: Configuring a Physical Interface Policer for Aggregate Traffic at a Physical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Chapter 14
Layer 2 Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Hierarchical Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 Hierarchical Policer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 Example: Configuring a Hierarchical Policer . . . . . . . . . . . . . . . . . . . . . . . . . 439 Two-Color and Three-Color Policers at Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 444 Two-Color Policing at Layer 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 Guidelines for Configuring Two-Color Policing of Layer 2 Traffic . . . . . 445 Statement Hierarchy for Configuring a Two-Color Policer for Layer 2 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Statement Hierarchy for Applying a Two-Color Policer to Layer 2 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Three-Color Policing at Layer 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Guidelines for Configuring Three-Color Policing of Layer 2 Traffic . . . . 446 Statement Hierarchy for Configuring a Three-Color Policer for Layer 2 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Statement Hierarchy for Applying a Three-Color Policer to Layer 2 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 Example: Configuring a Three-Color Logical Interface (Aggregate) Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
xiv
Table of Contents
Chapter 15
Summary of Policer Configuration Statements . . . . . . . . . . . . . . . . . . . . . . 455

action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 aggregate (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 bandwidth-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 bandwidth-limit (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 bandwidth-limit (Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 bandwidth-percent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 burst-size-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 burst-size-limit (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 burst-size-limit (Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 color-aware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 color-blind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 committed-burst-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 committed-information-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 excess-burst-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 filter-specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 forwarding-class (Firewall Filter Action) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 hierarchical-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 if-exceeding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 if-exceeding (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 if-exceeding (Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 input-hierarchical-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 input-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 input-three-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 layer2-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 load-balance-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 logical-bandwidth-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 logical-interface-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 loss-priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 loss-priority (Firewall Filter Action) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 loss-priority high then discard (Three-Color Policer) . . . . . . . . . . . . . . . . . . 485 output-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 output-three-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 peak-burst-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 peak-information-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 physical-interface-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 physical-interface-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 policer (Applying to a Logical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 policer (Configuring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 policer (Firewall Filter Action) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 prefix-action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 prefix-action (Configuring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 prefix-action (Firewall Filter Action) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 premium (Hierarchical Policer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 single-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 three-color-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 three-color-policer (Configuring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 three-color-policer (Firewall Filter Action) . . . . . . . . . . . . . . . . . . . . . . . . . . 502
xv
two-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Part 3
Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 Index of Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
xvi
List of Figures
Part 1
Chapter 1

Figure 1: Flows of Routing Information and Packets . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapter 5

Figure 2: Typical Network with BGP Peer Sessions . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 8

Figure 3: Logical System with a Stateless Firewall . . . . . . . . . . . . . . . . . . . . . . . . 279
Part 2
Chapter 10
Traffic Policers
Figure 4: Network Traffic and Burst Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Figure 5: Incoming and Outgoing Policers and Firewall Filters . . . . . . . . . . . . . . . 305
xvii
xviii
List of Tables
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
Part 1
Chapter 1

Table 3: Firewall Filter Protocol Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Table 4: Filter Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Table 5: Stateless Firewall Filter Configuration and Application Summary . . . . . . 12
Chapter 2
Standard Firewall Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Table 6: Standard Firewall Filter Match Conditions by Protocol Family . . . . . . . . . 24 Table 7: Standard Firewall Filter Action Categories . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter 3
Standard Firewall Filter Match Conditions Overview . . . . . . . . . . . . . . . . . . . 31

Table 8: Binary and Bit-Field Match Conditions for Firewall Filters . . . . . . . . . . . . 33 Table 9: Bit-Field Match Conditions for Common Combinations . . . . . . . . . . . . . 34 Table 10: Bit-Field Logical Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Chapter 4
Standard Firewall Filter Match Conditions and Actions . . . . . . . . . . . . . . . . . 47

Table 11: Standard Firewall Filter Match Conditions for Protocol-Independent Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Table 12: Standard Firewall Filter Match Conditions for IPv4 Traffic . . . . . . . . . . . 48 Table 13: Standard Firewall Filter Match Conditions for IPv6 Traffic . . . . . . . . . . . 57 Table 14: Standard Firewall Filter Match Conditions for MPLS Traffic . . . . . . . . . . 63 Table 15: IP Address-Specific Firewall Filter Match Conditions for MPLS Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Table 16: IP Port-Specific Firewall Filter Match Conditions for MPLS Traffic . . . . 66 Table 17: Standard Firewall Filter Match Conditions for VPLS Traffic . . . . . . . . . . . 67 Table 18: Standard Firewall Filter Match Conditions for Layer 2 CCC Traffic . . . . . 74 Table 19: Standard Firewall Filter Match Conditions for Layer 2 Bridging (MX Series 3D Universal Edge Routers Only) . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Table 20: Terminating Actions for Standard Firewall Filters . . . . . . . . . . . . . . . . . . 81 Table 21: Nonterminating Actions for Standard Firewall Filters . . . . . . . . . . . . . . . 83
Chapter 5

Table 22: Syslog Message Destinations for the Firewall Facility . . . . . . . . . . . . . . 219 Table 23: Packet-Header Logs for Stateless Firewall Filter Terms . . . . . . . . . . . . 222
Chapter 6
Service Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Table 24: Service Filter Match Conditions for IPv4 or IPv6 Traffic . . . . . . . . . . . . 235 Table 25: Terminating Actions for Service Filters . . . . . . . . . . . . . . . . . . . . . . . . . . 241
xix
Table 26: Nonterminating Actions for Service Filters . . . . . . . . . . . . . . . . . . . . . . 242
Chapter 7
Simple Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Table 27: Simple Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Chapter 8

Table 28: Unsupported Firewall Statements for Logical Systems . . . . . . . . . . . . 274 Table 29: Unsupported Actions for Firewall Filters in Logical Systems . . . . . . . . 275
Part 2
Chapter 10
Traffic Policers
Table 30: Two-Color Policer Configuration and Application Overview . . . . . . . . 307 Table 31: Three-Color Policer Configuration and Application Overview . . . . . . . . 312 Table 32: Hierarchical Policer Configuration and Application Summary . . . . . . . 315 Table 33: Policer Bandwidth Limits and Burst-Size Limits . . . . . . . . . . . . . . . . . . 317 Table 34: Implicit and Configurable Policer Actions Based on Color Marking . . . 318 Table 35: Example Calculations of Policer Burst-Size Limit . . . . . . . . . . . . . . . . . 325
Chapter 11
Single-Rate Two-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . 327

Table 36: Examples of Counter and Policer Set Size and Indexing . . . . . . . . . . . . 361 Table 37: Summary of Prefix-Specific Action Scenarios . . . . . . . . . . . . . . . . . . . 369
Chapter 12
Three-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Table 38: Recommended Naming Convention for Policers . . . . . . . . . . . . . . . . . 401
xx
About This Guide

This preface provides the following guidelines for using the Junos OS Firewall Filter and Policer Configuration Guide:

Junos OS Documentation and Release Notes on page xxi Objectives on page xxii Audience on page xxii Supported Platforms on page xxii Using the Indexes on page xxiii Using the Examples in This Manual on page xxiii Documentation Conventions on page xxiv Documentation Feedback on page xxvi Requesting Technical Support on page xxvi
Junos OS Documentation and Release Notes

For a list of related Junos OS documentation, see
http://www.juniper.net/techpubs/software/junos/ .
If the information in the latest release notes differs from the information in the documentation, follow the Junos OS Release Notes. To obtain the most current version of all Juniper Networks technical documentation, see the product documentation page on the Juniper Networks website at http://www.juniper.net/techpubs/ . Juniper Networks supports a technical book program to publish books by Juniper Networks engineers and subject matter experts with book publishers around the world. These books go beyond the technical documentation to explore the nuances of network architecture, deployment, and administration using the Junos operating system (Junos OS) and Juniper 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 OS configuration techniques. All the books are for sale at technical bookstores and book outlets around the world. The current list can be viewed at http://www.juniper.net/books .
xxi
Objectives
This guide provides an overview of stateless firewall filters and traffic policers for the Junos OS and describes how to configure firewall filters and policers on the router.
NOTE: For additional information about the Junos OSeither corrections to or information that might have been omitted from this guidesee the software release notes at http://www.juniper.net/ .
Audience
This guide is designed for network administrators who are configuring and monitoring a Juniper Networks M Series, MX Series, T Series, EX Series, or J Series router or switch. To use this guide, you need a broad understanding of networks in general, the Internet in particular, networking principles, and network configuration. You must also be familiar 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 conduct themselves in a careless, willfully negligent, or hostile manner; and must abide by the instructions provided by the documentation.
Supported Platforms
For the features described in this manual, the Junos OS currently supports the following platforms:

J Series M Series
xxii
About This Guide
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 summary section only. In the complete index, the entry for a configuration statement or command 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 configuration guidelines 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 the load merge relative command. These commands cause the software to merge the incoming configuration into the current candidate configuration. The example does not become active until you commit the candidate configuration. If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the example 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, the example is a snippet. In this case, use the load merge relative command. These procedures 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 example into a text file, save the file with a name, and copy the file to a directory on your routing platform. For example, copy the following configuration to a file and name the file ex-script.conf. Copy the ex-script.conf file to the /var/tmp directory on your routing platform.
system { scripts { commit { file ex-script.xsl; } } } interfaces { fxp0 {
xxiii
disable; unit 0 { family inet { address 10.0.0.1/24; } } } }

2. Merge the contents of the file into your routing platform configuration by issuing the
load merge configuration mode command: [edit] user@host# load merge /var/tmp/ex-script.conf load 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 into a text file, save the file with a name, and copy the file to a directory on your routing platform. For example, copy the following snippet to a file and name the file ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory on your routing platform.
commit { file ex-script-snippet.xsl; }
2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:

[edit] user@host# edit system scripts [edit system scripts]
3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command: [edit system scripts] user@host# load merge relative /var/tmp/ex-script-snippet.conf load complete
For more information about the load command, see the Junos OS CLI User Guide.
Documentation Conventions
Table 1 on page xxv defines notice icons used in this guide.
xxiv
About This Guide
Table 1: Notice Icons

Icon Meaning
Informational note
Description
Indicates important features or instructions.
Caution
Indicates a situation that might result in loss of data or hardware damage.
Warning
Alerts you to the risk of personal injury or death.
Laser warning
Alerts you to the risk of personal injury from a laser.
Table 2 on page xxv defines the text and syntax conventions used in this guide.
Table 2: Text and Syntax Conventions

Convention
Bold text like this
Description
Represents text that you type.
Examples
To enter configuration mode, type the configure command: user@host> configure
Fixed-width text like this
Represents output that appears on the terminal screen.
user@host> show chassis alarms No alarms currently active
Italic text like this
Introduces important new terms. Identifies book names. Identifies RFC and Internet draft titles.
A policy term is a named structure that defines match conditions and actions. Junos OS System Basics Configuration Guide RFC 1997, BGP Communities Attribute
Italic text like this
Represents variables (options for which you substitute a value) in commands or configuration statements.
Configure the machines domain name: [edit] root@# set system domain-name domain-name
Text like this
Represents names of configuration statements, commands, files, and directories; interface names; configuration hierarchy levels; or labels on routing platform components. Enclose optional keywords or variables.
To configure a stub area, include the stub statement at the [edit protocols ospf area area-id] hierarchy level. The console port is labeled CONSOLE.
< > (angle brackets)
stub <default-metric metric>;
xxv
Table 2: Text and Syntax Conventions (continued)

Convention
| (pipe symbol)
Description
Indicates a choice between the mutually exclusive keywords or variables on either side of the symbol. The set of choices is often enclosed in parentheses for clarity. Indicates a comment specified on the same line as the configuration statement to which it applies. Enclose a variable for which you can substitute one or more values. Identify a level in the configuration hierarchy. Identifies a leaf statement at a configuration hierarchy level.
Examples
broadcast | multicast (string1 | string2 | string3)
# (pound sign)
rsvp { # Required for dynamic MPLS only
[ ] (square brackets)
community name members [ community-ids ]
Indention and braces ( { } )
; (semicolon)
[edit] routing-options { static { route default { nexthop address; retain; } } }
J-Web GUI Conventions

Bold text like this Represents J-Web graphical user interface (GUI) items you click or select.
In the Logical Interfaces box, select All Interfaces. To cancel the configuration, click Cancel.
> (bold right angle bracket)
Separates levels in a hierarchy of J-Web selections.
In the configuration editor hierarchy, select Protocols>Ospf.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation. You can send your comments to techpubs-comments@juniper.net, or fill out the documentation feedback form at https://www.juniper.net/cgi-bin/docbugreport/ . If you are using e-mail, be sure to include the following information with your comments:

Document or topic name URL or page number Software release version (if applicable)
Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
xxvi
About This Guide
or are covered under warranty, and need postsales technical support, you can access our tools and resources online or open a case with JTAC.
JTAC policiesFor a complete understanding of our JTAC procedures and policies, review the JTAC User Guide located at http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf . Product warrantiesFor product warranty information, visit http://www.juniper.net/support/warranty/ . JTAC Hours of Operation The JTAC centers have resources available 24 hours a day, 7 days a week, 365 days a year.
Self-Help Online Tools and Resources

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

Find CSC offerings: http://www.juniper.net/customers/support/ 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 Number Entitlement (SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Case with JTAC

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

Use the Case Management tool in the CSC at http://www.juniper.net/cm/ . Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, visit us at

http://www.juniper.net/support/requesting-support.html
xxvii
xxviii
PART 1

Introduction to Stateless Firewall Filters on page 3 Standard Firewall Filter Overview on page 19 Standard Firewall Filter Match Conditions Overview on page 31 Standard Firewall Filter Match Conditions and Actions on page 47 Standard Firewall Filter Configuration on page 89 Service Filter Configuration on page 227 Simple Filter Configuration on page 249 Stateless Firewall Filter Configuration in Logical Systems on page 261 Summary of Stateless Firewall Filter Configuration Statements on page 283
CHAPTER 1
Introduction to Stateless Firewall Filters

Router Data Flow Overview on page 3 Stateless Firewall Filter Overview on page 5 Stateless Firewall Filter Types on page 6 Stateless Firewall Filter Components on page 7 Stateless Firewall Filter Application Points on page 12 Supported Standards for Filtering on page 14 Using the CLI Editor in Configuration Mode on page 15
Router Data Flow Overview

The Junos OS provides a policy framework, which is a collection of Junos OS policies that enable you to control flows of routing information and packets within the router.

Flow of Routing Information on page 3 Flow of Data Packets on page 4 Flow of Local Packets on page 4 Interdependent Flows of Routing Information and Packets on page 4
Flow of Routing Information

Routing information is the information about routes learned by the routing protocols from a routers neighbors. This information is stored in routing tables. The routing protocols advertise active routes only from the routing tables. An active route is a route that is chosen from all routes in the routing table to reach a destination. To control which routes the routing protocols place in the routing tables and which routes the routing protocols advertise from the routing tables, you can configure routing policies, which are sets of rules that the policy framework uses to preempt default routing policies. The Routing Engine, which is the routers control plane, handles the flow of routing information between the routing protocols and the routing tables and between the routing tables and the forwarding table. The Routing Engine runs the Junos OS and routing policies and stores the active router configuration, the master routing table, and the master forwarding table,
Flow of Data Packets

Data packets are chunks of data that transit the router as they are being forwarded from a source to a destination. When a router receives a data packet on an interface, it determines where to forward the 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 the appropriate interface. The Packet Forwarding Engine, which is the routers forwarding plane, handles the flow of data packets in and out of the routers physical interfaces. Although the Packet Forwarding Engine contains Layer 3 and Layer 4 header information, it does not contain the packet data itself (the packet's payload).
Flow of Local Packets

Local packets are chunks of data that are destined for or sent by the router. Local packets usually contain routing protocol data, data for IP services such as Telnet or SSH, and data for administrative protocols such as the Internet Control Message Protocol (ICMP). When the Routing Engine receives a local packet, it forwards the packet to the appropriate process or to the kernel, which are both part of the Routing Engine, or to the Packet Forwarding Engine. The Routing Engine handles the flow of local packets from the routers physical interfaces and to the Routing Engine.
Interdependent Flows of Routing Information and Packets

Figure 1 on page 4 illustrates the flow of data through a router. Although routing information flows and packet flows are very different from one another, they are also interdependent.
Figure 1: Flows of Routing Information and Packets
Routing policies determine which routes the Routing Engine places in the forwarding table. The forwarding table, in turn, has an integral role in determining the appropriate physical interface through which to forward a packet. Related Documentation

Stateless Firewall Filter Overview on page 5 Packet Flow Within Routers Overview in the Junos OS Class of Service Configuration
Guide
Chapter 1: Introduction to Stateless Firewall Filters
Understanding BGP Path Selection in the Junos OS Routing Protocols Configuration

Guide
Understanding Route Preference Values in the Junos OS Routing Protocols Configuration

Guide
Routing Policy Overview in the Junos OS Routing Policy Configuration Guide
Stateless Firewall Filter Overview

This topic covers the following information:

Packet Flow Control on page 5 Stateless and Stateful Firewall Filters on page 5 Purpose of Stateless Firewall Filters on page 6
Packet Flow Control

To influence which packets are allowed to transit the system and to apply special actions to packets as necessary, you can configure stateless firewall filters. A stateless firewall specifies a sequence of one or more packet-filtering rules, called filter terms. A filter term specifies match conditions to use to determine a match and actions to take on a matched packet. A stateless firewall filter enables you to manipulate any packet of a particular protocol family, including fragmented packets, based on evaluation of Layer 3 and Layer 4 header fields. You typically apply a stateless firewall filter to one or more interfaces that have been configured with protocol family features. You can apply a stateless firewall filter to an ingress interface, an egress interface, or both.
Data Packet Flow Control

To control the flow of data packets transiting the device as the packets are being forwarded from a source to a destination, you can apply stateless firewall filters to the input or output of the routers physical interfaces. To enforce a specified bandwidth and maximum burst size for traffic sent or received on an interface, you can configure policers. Policers are a specialized type of stateless firewall filter and a primary component of the Junos OS class-of-service (CoS).
Local Packet Flow Control

To control the flow of local packets between the physical interfaces and the Routing Engine, you can apply stateless firewall filters to the input or output of the loopback interface. The loopback interface (lo0) is the interface to the Routing Engine and carries no data packets.
Stateless and Stateful Firewall Filters

A stateless firewall filter, also known as an access control list (ACL), does not statefully inspect traffic. Instead, it evaluates packet contents statically and does not keep track of the state of network connections. In contrast, a stateful firewall filter uses connection
state information derived from other applications and past communications in the data flow to make dynamic control decisions. The Junos OS Firewall Filter and Policer Configuration Guide describes stateless firewall filters supported on T Series, M Series, and MX Series routers. For information about Junos OS stateful firewall policies for J Series and SRX Series security devices, see Security Policies Overview in the Junos OS Security Configuration Guide.
Purpose of Stateless Firewall Filters

The basic purpose of a stateless firewall filter is to enhance security through the use of packet filtering. Packet filtering enables you to inspect the components of incoming or outgoing packets and then perform the actions you specify on packets that match the criteria you specify. The typical use of a stateless firewall filter is to protect the Routing Engine processes and resources from malicious or untrusted packets. Related Documentation

Router Data Flow Overview on page 3 Stateless Firewall Filter Types on page 6 Traffic Policing Overview on page 297 in the Junos OS Firewall Filter and Policer
Configuration Guide
Packet Flow Through the CoS Process Overview in the Junos OS Class of Service
Configuration Guide
Stateless Firewall Filter Types


Standard Stateless Firewall Filters on page 6 Service Filters on page 7 Simple Filters on page 7
Standard Stateless Firewall Filters

The Junos OS standard stateless firewall filters support a rich set of packet-matching criteria that you can use to match on specific traffic and perform specific actions, such as forwarding or dropping packets that match the criteria you specify. You can configure firewall filters to protect the local router or to protect another device that is either directly or indirectly connected to the local router. For example, you can use the filters to restrict the local packets that pass from the routers physical interfaces to the Routing Engine. Such filters are useful in protecting the IP services that run on the Routing Engine, such as Telnet, SSH, and BGP, from denial-of-service attacks.
NOTE: If you configured targeted broadcast for virtual routing and forwarding (VRF) by including the forward-and-send-to-re statement, any firewall filter that is configured on the Routing Engine loopback interface (lo0) cannot be applied to the targeted broadcast packets that are forwarded to the Routing Engine. This is because broadcast packets are forwarded as flood next hop traffic and not as local next hop traffic, and you can only apply a firewall filter to local next hop routes for traffic directed toward the Routing Engine.
Service Filters
A service filter defines packet-filtering (a set of match conditions and a set of actions) for IPv4 or IPv6 traffic. You can apply a service filter to the inbound or outbound traffic at an adaptive services interface to perform packet filtering on traffic before it is accepted for service processing. You can also apply a service filter to the traffic that is returning to the services interface after service processing to perform postservice processing. Service filters filter IPv4 and IPv6 traffic only and can be applied to logical interfaces on Adaptive Services PICs, MultiServices PICs, and MultiServices DPCs only. Service filters are not supported on J Series devices and Branch SRX devices.
Simple Filters
Simple filters are supported on Gigabit Ethernet intelligent queuing (IQ2) and Enhanced Queuing Dense Port Concentrator (EQ DPC) interfaces only. Unlike standard filters, simple filters support IPv4 traffic only and have a number of restrictions. For example, you cannot configure a terminating action for a simple filter. Simple filters always accept packets. Also, simple filters can be applied only as input filters. They are not supported on outbound traffic. Simple filters are recommended for metropolitan Ethernet applications. Related Documentation

Stateless Firewall Filter Overview on page 5 Stateless Firewall Filter Components on page 7
Stateless Firewall Filter Components


Protocol Family on page 7 Filter Type on page 8 Terms on page 9 Match Conditions on page 10 Actions on page 11
Protocol Family
Under the firewall statement, you can specify the protocol family for which you want to filter traffic.
Table 3 on page 8 describes the firewall filter protocol families.
Table 3: Firewall Filter Protocol Families

Protocol Family Configuration Statement
family any
Type of Traffic to Be Filtered

Protocol Independent
Comments
All protocol families configured on a logical interface. The family inet statement is optional for IPv4.
Internet Protocol version 4 (IPv4)
family inet
Internet Protocol version 6 (IPv6) MPLS MPLS-tagged IPv4
family inet6 family mpls family mpls
Supports matching on IP addresses and ports, up to five MPLS stacked labels.
Virtual private LAN service (VPLS) Layer 2 Circuit Cross-Connection Layer 2 Bridging
family vpls family ccc family bridge
MX Series routers only.
Filter Type
Under the family family-name statement, you can specify the type and name of the filter you want to configure. Table 4 on page 8 describes the firewall filter types.
Table 4: Filter Types

Filter Type Stateless Firewall Filter Filter Configuration Statement
filter filter-name
Description
Filters the following traffic types:

Protocol independent IPv4 IPv6 MPLS MPLS-tagged IPv4 VPLS Layer 2 CCC Layer 2 bridging (MX Series routers only)
Table 4: Filter Types (continued)

Filter Type Service Filter Filter Configuration Statement
service-filter service-filter-name
Description
Defines packet-filtering to be applied to ingress or egress before it is accepted for service processing or applied to returning service traffic after service processing has completed. Filters the following traffic types:

IPv4 IPv6
Supported at logical interfaces configured on the following hardware only:
Adaptive Services (AS) PICs on M Series and T Series routers Multiservices (MS) PICs on M Series and T Series routers Multiservices (MS) DPCs on MX Series routers
Simple Filter
simple-filter simple-filter-name
Defines packet filtering to be applied to ingress traffic only. Filters the following traffic type:
IPv4
Supported at logical interfaces configured on the following hardware only:
Gigabit Ethernet Intelligent Queuing (IQ2) PICs installed on M120, M320, or T Series routers Enhanced Queuing Dense Port Concentrators (EQ DPCs) installed on MX Series routers
Terms
Under the filter, service-filter, or simple-filter statement, you must configure at least one firewall filter term. A term is a named structure in which match conditions and actions are defined. Within a firewall filter, you must configure a unique name for each term.
TIP: You cannot apply a different filter on each direction of traffic on the same interface. As a result, it is common to create firewall filters with multiple terms.
All stateless firewall filters contain one or more terms, and each term consists of two componentsmatch conditions and actions. The match conditions define the values or fields that the packet must contain to be considered a match. If a packet is a match, the corresponding action is taken. By default, a packet that does not match a firewall filter is discarded.
If a packet arrives on an interface for which no firewall filter is applied for the incoming traffic on that interface, the packet is accepted by default.
NOTE: A firewall filter with a large number of terms can adversely affect both the configuration commit time and the performance of the Routing Engine.
Additionally, you can configure a stateless firewall filter within the term of another filter. This method enables you to add common terms to multiple filters without having to modify all filter definitions. You can configure one filter with the desired common terms, and configure this filter as a term in other filters. Consequently, to make a change in these common terms, you need to modify only one filter that contains the common terms, instead of multiple filters.
Match Conditions
A firewall filter term must contain at least one packet-filtering criteria, called a match condition, to specify the field or value that a packet must contain in order to be considered a match for the firewall filter term. For a match to occur, the packet must match all the conditions in the term. If a packet matches a firewall filter term, the router takes the configured action on the packet. If a firewall filter term contains multiple match conditions, a packet must meet all match conditions to be considered a match for the firewall filter term. If a single match condition is configured with multiple values, such as a range of values, a packet must match only one of the values to be considered a match for the firewall filter term. The scope of match conditions you can specify in a firewall filter term depends on the protocol family under which the firewall filter is configured. You can define various match conditions, including the IP source address field, IP destination address field, TCP or UDP source port field, IP protocol field, Internet Control Message Protocol (ICMP) packet type, IP options, TCP flags, incoming logical or physical interface, and outgoing logical or physical interface. Each protocol family supports a different set of match conditions, and some match conditions are supported only on certain routing devices. For example, a number of match conditions for VPLS traffic are supported only on the MX Series 3D Universal Edge Routers. In the from statement in a firewall filter term, you specify characteristics that the packet 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 all conditions in the from statement for the action to be performed, which also means that the order of the conditions in the from statement is not important. If an individual match condition can specify a list of values (such as multiple source and destination addresses) or a range of numeric values, a match occurs if any of the values matches the packet.
10
If a filter term does not specify match conditions, the term accepts all packets and the actions specified in the terms then statement are optional.
NOTE: Some of the numeric range and bit-field match conditions allow you to specify a text synonym. For a complete list of synonyms:
If you are using the J-Web interface, select the synonym from the appropriate list. If you are using the CLI, type a question mark (?) after the from statement.
Actions
The actions specified in a firewall filter term define the actions to take for any packet that matches the conditions specified in the term. Actions that are configured within a single term are all taken on traffic that matches the conditions configured.
BEST PRACTICE: We strongly recommend that you explicitly configure one or more actions per firewall filter term. Any packet that matches all the conditions of the term is automatically accepted unless the term specifies other or additional actions.
Firewall filter actions fall into the following categories:
Filter-Terminating Actions
A filter-terminating action halts all evaluation of a firewall filter for a specific packet. The router performs the specified action, and no additional terms are examined.
Nonterminating Actions
Nonterminating actions 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 the system log functionality.
Flow Control Action

For standard stateless firewall filters only, the action next term enables the router to perform configured actions on the packet and then evaluate the following term in the filter, rather than terminating the filter. A maximum of 1024 next term actions are supported per standard stateless firewall filter configuration. If you configure a standard filter that exceeds this limit, your candidate configuration results in a commit error. Related Documentation
Stateless Firewall Filter Types on page 6
11
Inserting a New Identifier in a Junos Configuration in the Junos OS CLI User Guide
Stateless Firewall Filter Application Points

After you define the firewall filter, you must apply it to an application point. These application points include logical interfaces, physical interfaces, routing interfaces, and routing instances. In most cases, you can apply a firewall filter as an input filter or an output filter, or both at the same time. Input filters take action on packets being received on the specified interface, whereas output filters take action on packets that are transmitted through the specified interface. You typically apply one filter with multiple terms to a single logical interface, to incoming traffic, outbound traffic, or both. However, there are times when you might want to chain together multiple firewall filters (with single or multiple terms) and apply them to an interface. You use an input list to apply multiple firewall filters to the incoming traffic on an interface. You use an output list to apply multiple firewall filters to the outbound traffic on an interface. You can include up to 16 filters in an input list or an output list. There is no limit to the number of filters and counters you can set, but there are some practical considerations. More counters require more terms, and a large number 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. Table 5 on page 12 describes each point to which you can apply a firewall filter. For each application point, the table describes the types of firewall filters supported at that point, the router hierarchy level at which the filter can be applied, and any platform-specific limitations.
Table 5: Stateless Firewall Filter Configuration and Application Summary

Filter Type
Stateless firewall filter Configure by including the filter filter-name statement the [edit firewall] hierarchy level: filter filter-name; NOTE: If you do not include the family statement, the firewall filter processes IPv4 traffic by default. filter { input filter-name; output filter-name; } NOTE: A filter configured with the implicit inet protocol family cannot be included in an input filter list or an output filter list.
Application Point
Logical interface Apply at the [edit interfaces interface-name unit unit-number family inet] hierarchy level by including the input filter-name or output filter-name statements:
Restrictions
Supported on the following routers:

T Series routers M320 routers M7i routers with the enhanced CFEB (CFEB-e) M10i routers with the enhanced CFEB-e
Also supported on the following Modular Port Concentrators (MPCs) on MX Series routers:

10-Gigabit Ethernet MPC 60-Gigabit Ethernet Queuing MPC 60-Gigabit Ethernet Enhanced Queuing MPC
12
Table 5: Stateless Firewall Filter Configuration and Application Summary (continued)

Filter Type
Stateless firewall filter Configure at the [edit firewall family family-name] hierarchy level by including the following statement: filter filter-name; The family-name can be any of the following protocol families:

Application Point
Protocol family on a logical interface Apply at the [edit interfaces interface-name
unit unit-number family family-name]
Restrictions
The protocol family bridge is supported only on MX Series routers.
hierarchy level by, including the input, input-list, output, or output-list statements: filter { input filter-name; input-list [ filter-names ]; output filter-name; output-list [ filter-names ]; }
any bridge ccc inet inet6 mpls vpls
Stateless firewall filter Service filter Configure at the [edit firewall family (inet | inet6)] hierarchy level by including the following statement: service-filter service-filter-name;
Routing Engine loopback interface Family inet or inet6 on a logical interface Apply at the [edit interfaces interface-name
unit unit-number family (inet | inet6)]
Supported only on Adaptive Services (AS) and Multiservices (MS) PICs.
hierarchy level by using the service-set statement to apply a service filter as an input or output filter to a service set: service { input { service-set service-set-name service-filter filter-name; } output { service-set service-set-name service-filter filter-name; } } Configure a service set at the [edit services] hierarchy level by including the following statement:
service-set service-set-name;
13
Table 5: Stateless Firewall Filter Configuration and Application Summary (continued)

Filter Type
Postservice filter Configure at the [edit firewall family (inet | inet6)] hierarchy level by including the following statement: service-filter service-filter-name;
Application Point
Family inet or inet6 on a logical interface Apply at the [edit interfaces interface-name
Restrictions
A postservice filter is applied to traffic returning to the services interface after service processing. The filter is applied only if a service set is configured and selected.
hierarchy level by including the post-service-filter statement to apply a service filter as an input filter: service { input { post-service-filter filter-name; } } Family inet on a logical interface Apply at the [edit interfaces interface-name unit unit-number family inet] hierarchy level by including the following statement: simple-filter simple-filter-name; Simple filters can only be applied as input filters. Supported on the following platforms only:
Simple filter Configure at the [edit firewall family inet] hierarchy level by including the following statement: simple-filter filter-name Reverse packet forwarding (RPF) check filter Configured at the [edit firewall family (inet | inet6)] hierarchy level by including the following statement: filter filter-name;
Gigabit Ethernet intelligent queuing (IQ2) PICs on the M120, M320, and T Series routers. Enhanced Queuing Dense Port Concentrators (EQ DPC) on MX Series routers.
Family inet or inet6 on a logical interface Apply at the [edit interfaces interface-name
Supported on MX Series routers only.
hierarchy level by including the following statement: rpf-check fail-filter filter-name to apply the stateless firewall filter as an RPF check filter. rpf-check { fail-filter filter-name; mode loose; }
Related Documentation
Stateless Firewall Filter Components on page 7 Supported Standards for Filtering on page 14
Supported Standards for Filtering

The Junos OS supports the following RFCs related to filtering:

RFC 792, Internet Control Message Protocol RFC 2460, Internet Protocol, Version 6 (IPv6) RFC 2474, Definition of the Differentiated Services (DS) Field
14
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 Protocol Version 6 (IPv6) Specification Standard Stateless Firewall Filter Overview on page 19 Service Filter Overview on page 227 Simple Filter Overview on page 249 Stateless Firewall Filters in Logical Systems Overview on page 261
Using the CLI Editor in Configuration Mode

This topic describes some of the basic commands that you must use to enter configuration mode in the command-line interface (CLI) editor, navigate through the configuration hierarchy, get help, and commit or revert the changes that you make during the configuration session.
Task Edit Your Configuration
Enter configuration mode. When you first log in to the device, the device is in operational mode. You must explicitly enter configuration mode. When you do, the CLI prompt changes from user@host> to user@host# and the hierarchy level appears in square brackets. Create a statement hierarchy. You can use the edit command to simultaneously create a hierarchy and move to that new level in the hierarchy. You cannot use the edit command to change the value of identifiers. Create a statement hierarchy and set identifier values. The set command is similar to edit except that your current level in the hierarchy does not change. set hierarchy-level value edit hierarchy-level value configure user@host> configure [edit] user@host#
Command/Statement
Example
[edit] user@host# edit security zones security-zone myzone [edit security zones security-zone myzone] user@host#
[edit] user@host# set security zones security-zone myzone [edit] user@host#
Navigate the Hierarchy
15
Task
Navigate down to an existing hierarchy level.
Command/Statement
edit hierarchy-level
Example
[edit] user@host# edit security zones [edit security zones] user@host#
Navigate up one level in the hierarchy.
up
[edit security zones] user@host# up [edit security] user@host#
Navigate to the top of the hierarchy.
top
[edit security zones] user@host# top [edit] user@host#
Commit or Revert Changes

Commit your configuration. commit [edit] user@host# commit commit complete Roll back changes from the current session. Use the rollback command to revert all changes from the current configuration session. When you run the rollback command before exiting your session or committing changes, the software loads the most recently committed configuration onto the device. You must enter the rollback statement at the edit level in the hierarchy. rollback [edit] user@host# rollback load complete
Exit Configuration Mode

Commit the configuration and exit configuration mode. commit and-quit [edit] user@host# commit and-quit user@host> Exit configuration mode without committing your configuration. You must navigate to the top of the hierarchy using the up or top commands before you can exit configuration mode. exit [edit] user@host# exit The configuration has been changed but not committed Exit with uncommitted changes? [yes,no] (yes)
Get Help
16
Task
Display a list of valid options for the current hierarchy level.
Command/Statement
?
Example
[edit ] user@host# edit security zones ? Possible completions: <[Enter]> Execute this command > functional-zone Functional zone > security-zone Security zones | Pipe through a command [edit]
17
18
CHAPTER 2
Standard Firewall Filter Overview

Standard Stateless Firewall Filter Overview on page 19 How Standard Firewall Filters Evaluate Packets on page 20 Guidelines for Configuring Standard Firewall Filters on page 21 Guidelines for Applying Standard Firewall Filters on page 26 Understanding How to Use Standard Firewall Filters on page 29
Standard Stateless Firewall Filter Overview

Firewall filters provide a means of protecting your router from excessive traffic transiting the router to a network destination or destined for the Routing Engine. Firewall filters that control local packets can also protect your router from external incidents. You can configure a firewall filter to do the following:
Restrict traffic destined for the Routing Engine based on its source, protocol, and application. Limit the traffic rate of packets destined for the Routing Engine to protect against flood, or denial-of-service (DoS) attacks. Address special circumstances associated with fragmented packets destined for the Routing Engine. Because the device evaluates every packet against a firewall filter (including fragments), you must configure the filter to accommodate fragments that do not contain packet header information. Otherwise, the filter discards all but the first fragment of a fragmented packet. Stateless Firewall Filter Types on page 6 Guidelines for Configuring Standard Firewall Filters on page 21 Guidelines for Applying Standard Firewall Filters on page 26 Understanding How to Use Standard Firewall Filters on page 29
19
How Standard Firewall Filters Evaluate Packets


Firewall Filters That Contain a Single Term on page 20 Firewall Filters That Contain Multiple Terms on page 20 Firewall Filter Terms That Do Not Contain Any Match Conditions on page 21 Firewall Filter Terms That Do Not Contain Any Actions on page 21 Firewall Filter Default Action on page 21
Firewall Filters That Contain a Single Term

For a standard stateless firewall filter that consists of a single term, the policy framework software evaluates a packet as follows:

If the packet matches all the conditions, the actions are taken. If the packet matches all the conditions and no actions are specified, the packet is accepted. If the packet does not match all the conditions, it is discarded.
NOTE: When the device compares the stateless firewall filter match conditions to a packet, it compares only the header fields specified in the match condition. There is no implied protocol match. For example, if you specify a match of destination-port ssh, the device checks for a value of 0x22 in the 2-byte field that is two bytes after the IP packet header. The protocol field of the packet is not checked.
Firewall Filters That Contain Multiple Terms

For a standard stateless firewall filter that consists of multiple terms, the policy framework software evaluates a packet against the terms in the filter sequentially, beginning with the first term in the filter, until either the packet matches all the conditions in one of the terms or there are no more terms in the filter.

If the packet matches all the conditions in a term, the actions in that term are performed. Unlike service filters and simple filters, standard stateless firewall filters support the next term action, which is neither a terminating action nor a nonterminating action but a flow control action.:
If the actions do not include the next term action, evaluation of the packet ends at this term of the filter, and any subsequent terms in the filter are not used. If the actions include the next term action, the evaluation continues to the next term.
20
Chapter 2: Standard Firewall Filter Overview
If the packet does not match all the conditions in the term, evaluation of the packet proceeds to the next term in the filter. Evaluation of the packet continues until either the packet matches a term without next term action or until the end of the filter is reached.
A maximum of 1024 next term actions are supported per standard stateless firewall filter configuration. If you configure a standard filter that exceeds this limit, your candidate configuration results in a commit error.
Firewall Filter Terms That Do Not Contain Any Match Conditions

For standard stateless filters with a single term and for standard stateless firewall filters with multiple terms, if a term does not specify any match conditions, the actions are taken on any packet evaluated.
Firewall Filter Terms That Do Not Contain Any Actions

If a standard stateless firewall filter term does not contain any actions, and if the packet matches the conditions in the term, the packet is accepted.
Firewall Filter Default Action

Each standard stateless firewall filter has an implicit discard action at the end of the filter, which is equivalent to including the following example term explicit_discard as the final term in the standard stateless firewall filter:
term explicit_discard { then discard; }
By default, if a packet matches none of the terms in a standard stateless firewall filter, the packet is discarded. Related Documentation

How Service Filters Evaluate Packets on page 228 How Simple Filters Evaluate Packets on page 249 Guidelines for Configuring Standard Firewall Filters on page 21 Understanding How to Use Standard Firewall Filters on page 29
Guidelines for Configuring Standard Firewall Filters


Statement Hierarchy for Configuring Standard Firewall Filters on page 22 Standard Firewall Filter Protocol Families on page 22 Standard Firewall Filter Names and Options on page 23 Standard Firewall Filter Terms on page 23 Standard Firewall Filter Match Conditions on page 24 Standard Firewall Filter Actions on page 25
21
Statement Hierarchy for Configuring Standard Firewall Filters

To configure a standard firewall filter, you can include the following statements. For an IPv4 standard firewall filter, the family inet statement is optional.
firewall { family family-name { filter filter-name { accounting-profile name; interface-specific; physical-interface-filter; term term-name { filter filter-name; } term term-name { from { match-conditions; ip-version ipv4 { match-conditions; protocol (tcp | udp) { match conditions; } } } then { actions; } } } } }
You can include the firewall configuration at one of the following hierarchy levels:

[edit] [edit logical-systems logical-system-name]
NOTE: For stateless firewall filtering, you must allow the output tunnel traffic through the firewall filter applied to input traffic on the interface that is the next-hop interface toward the tunnel destination. The firewall filter affects only the packets exiting the router by way of the tunnel.
Standard Firewall Filter Protocol Families

A standard firewall filter configuration is specific to a particular protocol family. Under the firewall statement, include one of the following statements to specify the protocol family for which you want to filter traffic:

family anyTo filter protocol-independent traffic. family inetTo filter Internet Protocol version 4 (IPv4) traffic.
22
family inet6To filter Internet Protocol version 6 (IPv6) traffic. family mplsTo filter MPLS traffic. family vplsTo filter virtual private LAN service (VPLS) traffic. family cccTo filter Layer 2 circuit cross-connection (CCC) traffic. family bridgeTo filter Layer 2 bridging traffic for MX Series 3D Universal Edge Routers
only. The family family-name statement is required only to specify a protocol family other than IPv4. To configure an IPv4 firewall filter, you can configure the filter at the [edit firewall] hierarchy level without including the family inet statement, because the [edit firewall] and [edit firewall family inet] hierarchy levels are equivalent.
Standard Firewall Filter Names and Options

Under the family family-name statement, you can include filter filter-name statements to create and name standard firewall filters. The filter name can contain letters, numbers, and hyphens (-) and be up to 64 characters long. To include spaces in the name, enclose the entire name in quotation marks ( ). At the [edit firewall family family-name filter filter-name] hierarchy level, the following statements are optional:

accounting-profile interface-specific physical-interface-filter
Standard Firewall Filter Terms

Under the filter filter-name statement, you can include term term-name statements to create and name filter terms.

You must configure at least one term in a firewall filter. You must specify a unique name for each term within a firewall filter. The term name can contain letters, numbers, and hyphens (-) and can be up to 64 characters long. To include spaces in the name, enclose the entire name in quotation marks ( ). The order in which you specify terms within a firewall filter configuration is important. Firewall filter terms are evaluated in the order in which they are configured. By default, new terms are always added to the end of the existing filter. You can use the insert configuration mode command to reorder the terms of a firewall filter.
At the [edit firewall family family-name filter filter-name term term-name] hierarchy level, the filter filter-name statement is not valid in the same term as from or then statements. When included at this hierarchy level, the filter filter-name statement is used to nest firewall filters.
23
Standard Firewall Filter Match Conditions

Standard firewall filter match conditions are specific to the type of traffic being filtered. With the exception of MPLS-tagged IPv4 traffic, you specify the terms match conditions under the from statement. For MPLS-tagged IPv4 traffic, you specify the terms IPv4 address-specific match conditions under the ip-version ipv4 statement and the terms IPv4 port-specific match conditions under the protocol (tcp | udp) statement. Table 6 on page 24 describes the types of traffic for which you can configure standard stateless firewall filters.
Table 6: Standard Firewall Filter Match Conditions by Protocol Family

Traffic Type
Protocolindependent
Hierarchy Level at Which Match Conditions Are Specified

[edit firewall family any filter filter-name term term-name]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for Protocol-Independent Traffic on page 47. IPv4
[edit firewall family inet filter filter-name term term-name]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for IPv4 Traffic on page 48. IPv6
[edit firewall family inet6 filter filter-name term term-name]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for IPv6 Traffic on page 57. MPLS
[edit firewall family mpls filter filter-name term term-name]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for MPLS Traffic on page 62. IPv4 addresses in MPLS flows
[edit firewall family mpls filter filter-name term term-name ip-version ipv4 ]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for MPLS-Tagged IPv4 Traffic on page 64. IPv4 ports in MPLS flows
[edit firewall family mpls filter filter-name term term-name ip-version ipv4 protocol (tcp | udp)]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for MPLS-Tagged IPv4 Traffic on page 64. VPLS
[edit firewall family vpls filter filter-name term term-name]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for VPLS Traffic on page 66. Layer 2 CCC
[edit firewall family ccc filter filter-name term term-name]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for Layer 2 CCC Traffic on page 73.
24
Table 6: Standard Firewall Filter Match Conditions by Protocol Family (continued)

Traffic Type
Layer 2 Bridging (MX Series routers only)
Hierarchy Level at Which Match Conditions Are Specified

[edit firewall family bridge filter filter-name term term-name]
For the complete list of match conditions, see Standard Firewall Filter Match Conditions for Layer 2 Bridging Traffic on page 75.
If you specify an IPv6 address in a match condition (the address, destination-address, or source-address match conditions), use the syntax for text representations described in RFC 2373, IP Version 6 Addressing Architecture. For more information about IPv6 addresses, see IPv6 Overview and IPv6 Standards in the Junos OS Routing Protocols Configuration Guide.
Standard Firewall Filter Actions

Under the then statement for a standard stateless firewall filter term, you can specify the actions to be taken on a packet that matches the term. Table 7 on page 25 summarizes the types of actions you can specify in a standard stateless firewall filter term.
Table 7: Standard Firewall Filter Action Categories

Type of Action
Terminating
Description
Halts all evaluation of a firewall filter for a specific packet. The router performs the specified action, and no additional terms are used to examine the packet. You can specify only one terminating action in a standard firewall filter. You can, however, specify one terminating action with one or more nonterminating actions in a single term. For example, within a term, you can specify accept with count and syslog.
Comment
See Standard Firewall Filter Terminating Actions on page 81.
Nonterminating
Performs 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 the system log functionality), but any additional terms are used to examine the packet.
See Standard Firewall Filter Nonterminating Actions on page 82.
25
Table 7: Standard Firewall Filter Action Categories (continued)

Type of Action
Flow control
Description
For standard stateless firewall filters only, the next term action directs the router to perform configured actions on the packet and then, rather than terminate the filter, use the next term in the filter to evaluate the packet. If the next term action is included, the matching packet is evaluated against the next term in the firewall filter. Otherwise, the matching packet is not evaluated against subsequent terms in the firewall filter. For example, when you configure a term with the nonterminating action count, the terms action changes from an implicit discard to an implicit accept. The next term action forces the continued evaluation of the firewall filter.
Comment
You cannot configure the next term action with a terminating action in the same filter term. However, you can configure the next term action with another nonterminating action in the same filter term. A maximum of 1024 next term actions are supported per standard stateless firewall filter configuration. If you configure a standard filter that exceeds this limit, your candidate configuration results in a commit error.
Guidelines for Applying Standard Firewall Filters on page 26 Understanding How to Use Standard Firewall Filters on page 29
Guidelines for Applying Standard Firewall Filters


Applying Standard Firewall Filters Overview on page 26 Statement Hierarchy for Applying Standard Firewall Filters on page 27 Restrictions on Applying Standard Firewall Filters on page 27
Applying Standard Firewall Filters Overview

You can apply a standard stateless firewall filter to a physical interface on the router or to the loopback interface on the router. You can apply a firewall filter to a single interface or to multiple interfaces on the router.
Applying a Firewall Filter to a Routers Physical Interfaces

When you apply a standard firewall filter to a physical interface on the router, the filter evaluates all data packet that pass through that interface.
Applying a Firewall Filter to the Routers Loopback Interface

The routers loopback interface, lo0, is the interface to the Routing Engine and carries no data packets. When you apply a standard firewall filter to the loopback interface, the filter evaluates the local packets received or transmitted by the Routing Engine.
26
Applying a Firewall Filter to Multiple Interfaces

You can use the same standard firewall filter one or more times. On M Series routers, except the M120 and M320 routers, if you apply a firewall filter to multiple interfaces, the filter acts on the sum of traffic entering or exiting those interfaces. On T Series, M120, M320, and MX Series routers, interfaces are distributed among multiple packet- forwarding components. On these routers, you can configure standard stateless firewall filters and service filters that, when applied to multiple interfaces, act on the individual traffic streams entering or exiting each interface, regardless of the sum of traffic on the multiple interfaces. For more information, see Interface-Specific Firewall Filter Instances Overview on page 177.
Statement Hierarchy for Applying Standard Firewall Filters

To apply a standard stateless firewall filter to a logical interface, configure the input filter-name, input-list filter-name, output filter-name, or output-list filter-name statements in the filter stanza for the logical interface protocol family.
interfaces { interface-name { unit logical-unit-number { family family-name { ... filter { group group-number; input filter-name; input-list [ filter-names ]; output filter-name; output-list [ filter-names ]; } } } } }
You can include the interface configuration at one of the following hierarchy levels:

Restrictions on Applying Standard Firewall Filters

Number of Input and Output Filters Per Logical Interface on page 28 MPLS and Layer 2 CCC Firewall Filters in Lists on page 28 Layer 2 CCC Firewall Filters on MX Series Routers on page 28 Protocol-Independent Firewall Filters on the Loopback Interface on page 28
27
Number of Input and Output Filters Per Logical Interface

Input filtersAlthough you can use the same filter multiple times, you can apply only one input filter or one input filter list to an interface.
To specify a single firewall filter to be used to evaluate packets received on the interface, include the input filter-name statement in the filter stanza. To specify an ordered list of firewall filters to be used to evaluate packets received on the interface, include the input-list [ filter-names ] statement in the filter stanza. You can specify up to 16 firewall filters for the filter input list.
Output filtersAlthough you can use the same filter multiple times, you can apply only one output filter or one output filter list to an interface.
To specify a single firewall filter to be used to evaluate packets transmitted on the interface, include the output filter-name statement in the filter stanza. To specify an ordered list of firewall filters to be used to evaluate packets transmitted on the interface, include the output-list [ filter-names ] statement in the filter stanza. You can specify up to 16 firewall filters in a filter output list.
MPLS and Layer 2 CCC Firewall Filters in Lists

The input-list filter-names and output-list filter-names statements for firewall filters for the ccc and mpls protocol families are supported on all interfaces with the exception of the following:

Management interfaces and internal Ethernet interfaces (fxp or em0) Loopback interfaces (lo0) USB modem interfaces (umd)
Layer 2 CCC Firewall Filters on MX Series Routers

On MX Series routers only, you cannot apply a Layer 2 CCC stateless firewall filter (a firewall filter configured at the [edit firewall filter family ccc] hierarchy level) as an output filter. On MX Series routers, firewall filters configured for the family ccc statement can be applied only as input filters.
Protocol-Independent Firewall Filters on the Loopback Interface

Protocol-independent firewall filtersstateless firewall filters configured at the [edit firewall family any] hierarchy level are not supported on the router loopback interface (lo0). Related Documentation

Guidelines for Configuring Standard Firewall Filters on page 21 Understanding How to Use Standard Firewall Filters on page 29
28
Understanding How to Use Standard Firewall Filters


Using Standard Firewall Filters to Affect Local Packets on page 29 Using Standard Firewall Filters to Affect Data Packets on page 30
Using Standard Firewall Filters to Affect Local Packets

On a router, you can configure one physical loopback interface, lo0, and one or more addresses on the interface. The loopback interface is the interface to the Routing Engine, which runs and monitors all the control protocols. The loopback interface carries local packets only. Standard firewall filters applied to the loopback interface affect the local packets destined for or transmitted from the Routing Engine.
NOTE: When you create an additional loopback interface, it is important to apply a filter to it so the Routing Engine is protected. We recommend that when you apply a filter to the loopback interface, you include the apply-groups statement. Doing so ensures that the filter is automatically inherited on every loopback interface, including lo0 and other loopback interfaces.
Trusted Sources
The typical use of a standard stateless firewall filter is to protect the Routing Engine processes and resources from malicious or untrusted packets. To protect the processes and resources owned by the Routing Engine, you can use a standard stateless firewall filter that specifies which protocols and services, or applications, are allowed to reach the Routing Engine. Applying this type of filter to the loopback interface ensures that the local packets are from a trusted source and protects the processes running on the Routing Engine from an external attack.
Flood Prevention
You can create standard stateless firewall filters that limit certain TCP and ICMP traffic destined for the Routing Engine. A router without this kind of protection is vulnerable to TCP and ICMP flood attacks, which are also called denial-of-service (DoS) attacks. For example:
A TCP flood attack of SYN packets initiating connection requests can overwhelm the device until it can no longer process legitimate connection requests, resulting in denial of service. An ICMP flood can overload the device with so many echo requests (ping requests) that it expends all its resources responding and can no longer process valid network traffic, also resulting in denial of service.
Applying the appropriate firewall filters to the Routing Engine protects against these types of attacks.
29
Using Standard Firewall Filters to Affect Data Packets

Standard firewall filters that you apply to your routers transit interfaces evaluate only the user data packets that transit the router from one interface directly to another as they are being forwarded from a source to a destination. To protect the network as a whole from unauthorized access and other threats at specific interfaces, you can apply firewall filters router transit interfaces . Related Documentation

How Standard Firewall Filters Evaluate Packets on page 20 Guidelines for Configuring Standard Firewall Filters on page 21 Guidelines for Applying Standard Firewall Filters on page 26
30
CHAPTER 3
Standard Firewall Filter Match Conditions Overview

Firewall Filter Match Conditions Based on Numbers or Text Aliases on page 31 Firewall Filter Match Conditions Based on Bit-Field Values on page 32 Firewall Filter Match Conditions Based on Address Fields on page 37 Firewall Filter Match Conditions Based on Address Classes on page 45
Firewall Filter Match Conditions Based on Numbers or Text Aliases


Matching on a Single Numeric Value on page 31 Matching on a Range of Numeric Values on page 31 Matching on a Text Alias for a Numeric Value on page 32 Matching on a List of Numeric Values or Text Aliases on page 32
Matching on a Single Numeric Value

You can specify a firewall filter match condition based on whether a particular packet field value is a specified numeric value. In the following example, a match occurs if the packet source port number is 25:
[edit firewall family inet filter filter1 term term1 from] user@host# set source-port 25
Matching on a Range of Numeric Values

You can specify a firewall filter match condition based on whether a particular packet field value falls within a specified range of numeric values. In the following example, a match occurs for source ports values from 1024 through 65,535, inclusive:
[edit firewall family inet filter filter2 term term1 from] user@host# set source-port 1024-65535
31
Matching on a Text Alias for a Numeric Value

You can specify a firewall filter match condition based on whether a particular packet field value is a numeric value that you specify by using a text string as an alias for the numeric value. In the following example, a match occurs if the packet source port number is 25. For the source-port and destination-port match conditions, the text aliassmtp corresponds to the numeric value 25.
[edit firewall family inet filter filter3 term term1 from] user@host# set source-port smtp
Matching on a List of Numeric Values or Text Aliases

You can specify a firewall filter match condition based on whether a particular packet field value matches any one of multiple numeric values or text aliases that you specify within square brackets and delimited by spaces. In the following example, a match occurs if the packet source port number is any of the following values: 20 (which corresponds to the text aliases ftp-data), 25, or any value from 1024 through 65535.
[edit firewall family inet filter filter3 term term1 from] user@host# set source-port [ smtp ftp-data 25 1024-65535 ]
Guidelines for Configuring Standard Firewall Filters on page 21 Firewall Filter Match Conditions Based on Bit-Field Values on page 32 Firewall Filter Match Conditions Based on Address Fields on page 37 Firewall Filter Match Conditions Based on Address Classes on page 45
Firewall Filter Match Conditions Based on Bit-Field Values

Match Conditions for Bit-Field Values on page 32 Match Conditions for Common Bit-Field Values or Combinations on page 33 Logical Operators for Bit-Field Values on page 34 Matching on a Single Bit-Field Value or Text Alias on page 35 Matching on Multiple Bit-Field Values or Text Aliases on page 35 Matching on a Negated Bit-Field Value on page 36 Matching on the Logical OR of Two Bit-Field Values on page 36 Matching on the Logical AND of Two Bit-Field Values on page 36 Grouping Bit-Field Match Conditions on page 36
Match Conditions for Bit-Field Values

Table 8 on page 33 lists the firewall filter match conditions that are based on whether certain bit fields in a packet are set or not set. The second and third columns list the types of traffic for which the match condition is supported.
32
Chapter 3: Standard Firewall Filter Match Conditions Overview
Table 8: Binary and Bit-Field Match Conditions for Firewall Filters

Protocol Families for Standard Stateless Firewall Filters
family inet
Bit-Field Match Condition

fragment-flags flags
Match Values
Hexadecimal values or text aliases for the three-bit IP fragmentation flags field in the IP header. Hexadecimal values or text aliases for the 13-bit fragment offset field in the IP header. Hexadecimal values or text aliases for the low-order 6 bits of the 8-bit TCP flags field in the TCP header.
ProtocolFamilies for Service Filters

family inet
fragment-offset value
family inet
family inet
tcp-flags value
family inet family inet6 family vpls family bridge
family inet family inet6
The Junos OS does not automatically check the first fragment bit when matching TCP flags for IPv4 traffic. To check the first fragment bit for IPv4 traffic only, use the first-fragment match condition.
Match Conditions for Common Bit-Field Values or Combinations

Table 9 on page 34 describes firewall filter match conditions that are based on whether certain commonly used values or combinations of bit fields in a packet are set or not set. You can use text synonyms to specify some common bit-field matches. In the previous example, you can specify tcp-initial as the same match condition.
NOTE: Some of the numeric range and bit-field match conditions allow you to specify a text synonym. For a complete list of synonyms:
If you are using the J-Web interface, select the synonym from the appropriate list. If you are using the CLI, type a question mark (?) after the from statement.
33
Table 9: Bit-Field Match Conditions for Common Combinations

ProtocolFamilies for Standard Stateless Firewall Filters
family inet
Match Condition
first-fragment
Description
Text alias for the bit-field match condition fragment-offset 0, which indicates the first fragment of a fragmented packet. Text alias for the bit-field match condition fragment-offset 0 except, which indicates a trailing fragment of a fragmented packet. Alias for the bit-field match condition tcp-flags "(ack | rst)", which indicates an established TCP session, but not the first packet of a TCP connection. Alias for the bit-field match condition tcp-flags "(!ack & syn)", which indicates the first packet of a TCP connection, but not an established TCP session.
ProtocolFamilies for Service Filters

family inet
is-fragment
family inet
family inet
tcp-established
tcp-initial
Logical Operators for Bit-Field Values

Table 10 on page 34 lists the logical operators you can apply to single bit-field values when specifying stateless firewall filter match conditions. The operators are listed in order, from highest precedence to lowest precedence. Operations are left-associative, meaning that the operations are processed from left to right.
Table 10: Bit-Field Logical Operators

Precedence Order
1
Bit-Field Logical Operator

(complex-match-condition)
Description
GroupingThe complex match condition is evaluated before any operators outside the parentheses are applied. NegationA match occurs if the match condition is false. Logical ANDA match occurs if both match conditions are true.
! match-condition
match-condition-1 & match-condition-2
or
match-condition-1 + match-condition-2
34
Table 10: Bit-Field Logical Operators (continued)

Precedence Order
4
Bit-Field Logical Operator

match-condition-1 | match-condition-2
Description
Logical ORA match occurs if either match condition is true.
or
match-condition-1 , match-condition-2
Matching on a Single Bit-Field Value or Text Alias

For the fragment-flags and tcp-flags bit-match conditions, you can specify firewall filter match conditions based on whether a particular bit in the packet field is set or not set.
Numeric value to specify a single bitYou can specify a single bit-field match condition by using a numeric value that has one bit set. Depending on the match condition, you can specify a decimal value, a binary value, or a hexadecimal value. To specify a binary value, specify the number with the prefix b. To specify a hexadecimal value, specify the number with the prefix 0x. In the following example, a match occurs if the RST bit in the TCP flags field is set:
[edit firewall family inet filter filter_tcp_rst_number term term1 from] user@host# set tcp-flags 0x04
Text alias to specify a single bitYou generally specify a single bit-field match condition by using a text alias enclosed in double-quotation marks ( ). In the following example, a match occurs if the RST bit in the TCP flags field is set:
[edit firewall family inet filter filter_tcp_rst_alias term term1 from] user@host# set tcp-flags rst
Matching on Multiple Bit-Field Values or Text Aliases

You can specify a firewall filter match condition based on whether a particular set of bits in a packet field are set.
Numeric values to specify multiple set bitsWhen you specify a numeric value whose binary representation has more than one set bit, the value is treated as a logical AND of the set bits. In the following example, the two match conditions are the same. A match occurs if either bit 0x01 or 0x02 is not set:
[edit firewall family inet filter reset_or_not_initial_packet term term5 from] user@host# set tcp-flags !0x3 user@host# set tcp-flags !(0x01 & 0x02)
Text aliases that specify common bit-field matchesYou can use text aliases to specify some common bit-field matches. You specify these matches as a single keyword. In the following example, the tcp-established condition, which is an alias for (ack | rst), specifies that a match occurs on TCP packets other than the first packet of a connection:
[edit firewall family inet filter reset_or_not_initial_packet term term6 from]
35
user@host# set tcp-established
Matching on a Negated Bit-Field Value

To negate a match, precede the value with an exclamation point. In the following example, a match occurs if the RST bit in the TCP flags field is not set:
[edit firewall family inet filter filter_tcp_rst term term1 from] user@host# set tcp-flags !rst
Matching on the Logical OR of Two Bit-Field Values

You can use the logical OR operator (| or ,) to specify that a match occurs if a bit field matches either of two bit-field values specified. In the following example, a match occurs if the packet is not the initial packet in a TCP session:
[edit firewall family inet filter not_initial_packet term term3 from] user@host# set tcp-flags "!syn | ack"
In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all packets sent after the initial packet. In a packet that is not the initial packet in a TCP session, either the SYN flag is not set or the ACK flag is set.
Matching on the Logical AND of Two Bit-Field Values

You can use the logical AND operator (& or +) to specify that a match occurs if a bit field matches both of two bit-field values specified. In the following example, a match occurs if the packet is the initial packet in a TCP session:
[edit firewall family inet filter initial_packet term term2 from] user@host# set tcp-flags syn & !ack
In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all packets sent after the initial packet. In a packet that is an initial packet in a TCP session, the SYN flag is set and the ACK flag is not set.
Grouping Bit-Field Match Conditions

You can use the logical grouping notation to specify that the complex match condition inside the parentheses is evaluated before any operators outside the parentheses are applied. In the following example, a match occurs if the packet is a TCP reset or if the packet is not the initial packet in the TCP session:
[edit firewall family inet filter reset_or_not_initial_packet term term4 from] user@host# set tcp-flags !(syn & !ack) | rst
In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all packets sent after the initial packet. In a packet that is not the initial packet in a TCP session, the SYN flag is not set and the ACK field is set. Related Documentation
Guidelines for Configuring Standard Firewall Filters on page 21
36
Firewall Filter Match Conditions Based on Numbers or Text Aliases on page 31 Firewall Filter Match Conditions Based on Address Fields on page 37 Firewall Filter Match Conditions Based on Address Classes on page 45
Firewall Filter Match Conditions Based on Address Fields

You can configure firewall filter match conditions that evaluate packet address fieldsIPv4 source and destination addresses, IPv6 source and destination addresses, or media access control (MAC) source and destination addressesagainst specified addresses or prefix values.
Implied Match on the 0/0 except Address for Firewall Filter Match Conditions Based on Address Fields on page 37 Matching an Address Field to a Subnet Mask or Prefix on page 37 Matching an Address Field to an Excluded Value on page 38 Matching Either IP Address Field to a Single Value on page 42 Matching an Address Field to Noncontiguous Prefixes on page 42 Matching an Address Field to a Prefix List on page 44
Implied Match on the 0/0 except Address for Firewall Filter Match Conditions Based on Address Fields
Every firewall filter match condition based on a set of addresses or address prefixes is associated with an implicit match on the address 0.0.0.0/0 except (for IPv4 or VPLS traffic) or 0:0:0:0:0:0:0:0/0 except (for IPv6 traffic). As a result, any packet whose specified address field does not match any of the specified addresses or address prefixes fails to match the entire term.
Matching an Address Field to a Subnet Mask or Prefix

You can specify a single match condition to match a source address or destination address that falls within a specified address prefix.
IPv4 Subnet Mask Notation

For an IPv4 address, you can specify a subnet mask value rather than a prefix length. For example:
[edit firewall family inet filter filter_on_dst_addr term term3 from] user@host# set address 10.0.0.10/255.0.0.255
Prefix Notation
To specify the address prefix, use the notation prefix/prefix-length. In the following example, a match occurs if a destination address matches the prefix 10.0.0.0/8:
[edit firewall family inet filter filter_on_dst_addr term term1 from] user@host# set destination-address 10.0.0.0/8
37
Default Prefix Length for IPv4 Addresses

If you do not specify /prefix-length for an IPv4 address, the prefix length defaults to /32. The following example illustrates the default prefix value:
[edit firewall family inet filter filter_on_dst_addr term term2 from] user@host# set destination-address 10 user@host# show destination-address { 10.0.0.0/32; }
Default Prefix Length for IPv6 Addresses

If you do not specify /prefix-length for an IPv6 address, the prefix length defaults to /128. The following example illustrates the default prefix value:
[edit firewall family inet6 filter filter_on_dst_addr term term1 from] user@host# set destination-address ::10 user@host# show destination-address { ::10/128; }
Default Prefix Length for MAC Addresses

If you do not specify /prefix-length for a media access control (MAC) address of a VPLS, Layer 2 CCC, or Layer 2 bridging packet, the prefix length defaults to /48. The following example illustrates the default prefix value:
[edit firewall family vpls filter filter_on_dst_mac_addr term term1 from] user@host# set destination-mac-address 01:00:0c:cc:cc:cd user@host# show destination-address { 01:00:0c:cc:cc:cd/48; }
Matching an Address Field to an Excluded Value

For the address-field match conditions, you can include the except keyword to specify that a match occurs for an address field that does not match the specified address or prefix.
Excluding IP Addresses in IPv4 or IPv6 Traffic

For the following IPv4 and IPv6 match conditions, you can include the except keyword to specify that a match occurs for an IP address field that does not match the specified IP address or prefix:
address address exceptA match occurs if either the source IP address or the destination
IP address does not match the specified address or prefix.
source-address address exceptA match occurs if the source IP address does not
match the specified address or prefix.
38
destination-address address exceptA match occurs if the destination IP address
does not match the specified address or prefix. In the following example, a match occurs for any IPv4 destination addresses that fall under the 192.168.10.0/8 prefix, except for addresses that fall under 192.168.0.0/16. All other addresses implicitly do not match this condition.
[edit firewall family inet filter filter_on_dst_addr term term1 from] user@host# set 192.168.0.0/16 except user@host# set 192.168.10.0/8 user@host# show destination-address { 192.168.0.0/16 except; 192.168.10.0/8; }
In the following example, a match occurs for any IPv4 destination address that does not fall within the prefix 10.1.1.0/24:
[edit firewall family inet filter filter_on_dst_addr term term24 from] user@host# set destination-address 0.0.0.0/0 user@host# set destination-address 10.1.1.0/24 except user@host# show destination-address { 0.0.0.0/0; 10.1.1.0/24 except; }
Excluding IP Addresses in VPLS or Layer 2 Bridging Traffic

For the following VPLS and Layer 2 bridging match conditions on MX Series routers only, you can include the except keyword to specify that a match occurs for an IP address field that does not match the specified IP address or prefix:
ip-address address exceptA match occurs if either the source IP address or the
destination IP address does not match the specified address or prefix.
source-ip-address address exceptA match occurs if the source IP address does not
match the specified address or prefix.
destination-ip-address address exceptA match occurs if the destination IP address
does not match the specified address or prefix.
39
In the following example for filtering VPLS traffic on an MX Series router, a match occurs if the source IP address falls within the exception range of 55.0.1.0/255.0.255.0 and the destination IP address matches 55.0.0.0/8:
[edit] firewall { family vpls { filter fvpls { term 1 { from { ip-address { 55.0.0.0/8; 55.0.1.0/255.0.255.0 except; } } then { count from-55/8; discard; } } } } }
Excluding MAC Addresses in VPLS or Layer 2 Bridging Traffic

For the following VPLS or Layer 2 bridging traffic match conditions, you can include the except keyword to specify that a match occurs for a MAC address field that does not match the specified MAC address or prefix:
source-mac-address address exceptA match occurs if the source MAC address does
not match the specified address or prefix.
destination-mac-address address exceptA match occurs if either the destination MAC
address does not match the specified address or prefix.
Excluding All Addresses Requires an Explicit Match on the 0/0 Address

If you specify a firewall filter match condition that consists of one or more address-exception match conditions (address match conditions that use the except keyword) but no matchable address match conditions, packets that do not match any of the configured prefixes fails the overall match operation. To configure a firewall filter term of address-exception match conditions to match any address that is not in the prefix list, include an explicit match of 0/0 so that the term contain a matchable address. For the following example firewall filter for IPv4 traffic, the from-trusted-addresses term fails to discard matching traffic, and the INTRUDERS-COUNT counter is missing from the output of the show firewall operational mode command:
[edit] user@host# show policy-options prefix-list TRUSTED-ADDRESSES { 10.2.1.0/24; 192.168.122.0/24; }
40
[edit firewall family inet filter protect-RE] user@host# show term from-trusted-addresses { from { source-prefix-list { TRUSTED-ADDRESSES except; } protocol icmp; } then { count INTRUDERS-COUNT; discard; } } term other-icmp { from { protocol icmp; } then { count VALID-COUNT; accept; } } term all { then accept; }
[edit] user@host# run show firewall Filter: protect-RE Counters: Name VALID-COUNT Filter: __default_bpdu_filter__
Bytes 2770
Packets 70
To cause a filter term of address-exception match conditions to match any address that is not in the prefix list, include an explicit match of 0/0 in the set of match conditions:
[edit firewall family inet filter protect-RE] user@host# show term from-trusted-addresses from { source-prefix-list { 0.0.0.0/0; TRUSTED-ADDRESSES except; } protocol icmp; }
With the addition of the 0.0.0.0/0 source prefix address to the match condition, the from-trusted-addresses term discards matching traffic, and the INTRUDERS-COUNT counter displays in the output of the show firewall operational mode command:
[edit] user@host# run show firewall Filter: protect-RE Counters: Name
Bytes
Packets
41
VALID-COUNT INTRUDERS-COUNT Filter: __default_bpdu_filter__
2770 420
70 5
Matching Either IP Address Field to a Single Value

For IPv4 and IPv6 traffic and for VPLS and Layer 2 bridging traffic on MX Series routers only, you can use a single match condition to match a single address or prefix value to either the source or destination IP address field.
Matching Either IP Address Field in IPv4 or IPv6 Traffic

For IPv4 or IPv6 traffic, you can use a single match condition to specify the same address or prefix value as the match for either the source or destination IP address field. Instead of creating separate filter terms that specify the same address for the source-address and destination-address match conditions, you use only the address match condition. A match occurs if either the source IP address or the destination IP address matches the specified address or prefix. If you use the except keyword with the address match condition, a match occurs if both the source IP address and the destination IP address match the specified value before the exception applies. In a firewall filter term that specifies either the source-address or the destination-address match condition, you cannot also specify the address match condition.
Matching Either IP Address Field in VPLS or Layer 2 Bridging Traffic

For VPLS or Layer 2 bridging traffic on MX Series routers only, you can use a single match condition to specify the same address or prefix value as the match for either the source or destination IP address field. Instead of creating separate filter terms that specify the same address for the source-ip-address and destination-ip-address match conditions, you use only the ip-address match condition. A match occurs if either the source IP address or the destination IP address matches the specified address or prefix. If you use the except keyword with the ip-address match condition, a match occurs if both the source IP address and the destination IP address match the specified value before the exception applies. In a firewall filter term that specifies either the source-ip-address or the destination-ip-address match condition, you cannot also specify the ip-address match condition.
Matching an Address Field to Noncontiguous Prefixes

For IPv4 traffic only, specify a single match condition to match the IP source or destination address field to any prefix specified. The prefixes do not need to be contiguous. That is, the prefixes under the source-address or destination-address match condition do not need to be adjacent or neighboring to one another. In the following example, a match occurs if a destination address matches either the 10.0.0.0/8 prefix or the 192.168.0.0/32 prefix:
[edit firewall family inet filter filter_on_dst_addr term term5 from]
42
user@host# set destination-address 10.0.0.0/8 user@host# set destination-address 192.168.0.0/32 user@host# show destination-address { destination-address 10.0.0.0/8; destination-address 192.168.0.0/32; }
The order in which you specify the prefixes within the match condition is not significant. Packets are evaluated against all the prefixes in the match condition to determine whether a match occurs. If prefixes overlap, longest-match rules are used to determine whether a match occurs. A match condition of noncontiguous prefixes includes an implicit 0/0 except statement, which means that any prefix that does not match any prefix included in the match condition is explicitly considered not to match. Because the prefixes are order-independent and use longest-match rules, longer prefixes subsume shorter ones as long as they are the same type (whether you specify except or not). This is because anything that would match the longer prefix would also match the shorter one. Consider the following example:
[edit firewall family inet filter filter_on_src_addr term term1 from] source-address { 172.16.0.0/10; 172.16.2.0/24 except; 192.168.1.0; 192.168.1.192/26 except; 192.168.1.254; 172.16.3.0/24; # ignored 10.2.2.2 except; # ignored }
Within the source-address match condition, two addresses are ignored. The 172.16.3.0/16 value is ignored because it falls under the address 172.16.0.0/10, which is the same type. The 10.2.2.2 except value is ignored because it is subsumed by the implicit 0.0.0.0/0 except match value. Suppose the following source IP address are evaluated by this firewall filter:
Source IP address 172.16.1.2This address matches the 172.16.0.0/10 prefix, and thus the action in the then statement is taken. Source IP address 172.16.2.2This address matches the 172.16.2.0/24 prefix. Because this prefix is negated (that is, includes the except keyword), an explicit mismatch occurs. The next term in the filter is evaluated, if there is one. If there are no more terms, the packet is discarded. Source IP address 10.1.2.3This address does not match any of the prefixes included in the source-address condition. Instead, it matches the implicit 0.0.0.0/0 except at the end of the list of prefixes configured under the source-address match condition, and is considered to be a mismatch. The 172.16.3.0/24 statement is ignored because it falls under the address 172.16.0.0/10both are the same type.
43
The 10.2.2.2 except statement is ignored because it is subsumed by the implicit 0.0.0.0/0 except statement at the end of the list of prefixes configured under the source-address match condition.
BEST PRACTICE: When a firewall filter term includes the from address address match condition and a subsequent term includes the from source-address address match condition for the same address, packets might be processed by the latter term before they are evaluated by any intervening terms. As a result, packets that should be rejected by the intervening terms might be accepted instead, or packets that should be accepted might be rejected instead. To prevent this from occurring, we recommend that you do the following. For every firewall filter term that contains the from address address match condition, replace that term with two separate terms: one that contains the from source-address address match condition, and another that contains the from destination-address address match condition.
Matching an Address Field to a Prefix List

You can define a list of IPv4 or IPv6 address prefixes for use in a routing policy statement or in a stateless firewall filter match condition that evaluates packet address fields. To define a list of IPv4 or IPv6 address prefixes, include the prefix-list prefix-list statement.
prefix-list name { ip-addresses; apply-path path; }
You can include the statement at the following hierarchy levels:

[edit policy-options] [edit logical-systems logical-system-name policy-options]
After you have defined a prefix list, you can use it when specifying a firewall filter match condition based on an IPv4 or IPv6 address prefix.
[edit firewall family family-name filter filter-name term term-name] from { source-prefix-list { prefix-lists; } destination-prefix-list { prefix-lists; } }
Guidelines for Configuring Standard Firewall Filters on page 21 Firewall Filter Match Conditions Based on Numbers or Text Aliases on page 31
44
Firewall Filter Match Conditions Based on Bit-Field Values on page 32 Firewall Filter Match Conditions Based on Address Classes on page 45
Firewall Filter Match Conditions Based on Address Classes

For IPv4 and IPv6 traffic only, you can use class-based firewall filter conditions to match packet fields based on source class or destination class.

Source-Class Usage on page 45 Destination-Class Usage on page 45 Guidelines for Applying SCU or DCU Firewall Filters to Output Interfaces on page 45
Source-Class Usage
A source class is a set of source prefixes grouped together and given a class name. To configure a firewall filter term that matches an IP source address field to one or more source classes, use the source-class class-name match condition under the [edit firewall family (inet | inet6) filter filter-name term term-name from] hierarchy level. Source-class usage (SCU) enables you to monitor the amount of traffic originating from a specific prefix. With this feature, usage can be tracked and customers can be billed for the traffic they receive.
Destination-Class Usage
A destination class is a set of destination prefixes grouped together and given a class name. To configure a firewall filter term that matches an IP destination address field to one or more destination classes, use the destination-class class-name match condition at the [edit firewall family (inet | inet6) filter filter-name term term-name from] hierarchy level. Destination-class usage (DCU) enables you can track how much traffic is sent to a specific prefix in the core of the network originating from one of the specified interfaces. Note, however, that DCU limits your ability to keep track of traffic moving in the reverse direction. It can account for all traffic that arrives on a core interface and heads toward a specific customer, but it cannot count traffic that arrives on a core interface from a specific prefix.
Guidelines for Applying SCU or DCU Firewall Filters to Output Interfaces

When applying a SCU or DCU firewall filter to an interface, keep the following guidelines in mind:
Output interfacesClass-based firewall filter match conditions work only for firewall filters that you apply to output interfaces. This is because the SCU and DCU are determined after route lookup occurs.
45
Input interfacesAlthough you can specify a source class and destination class for an input firewall filter, the counters are incremented only if the firewall filter is applied on the output interface. Output interfaces for tunnel trafficSCU and DCU are not supported on the interfaces you configure as the output interface for tunnel traffic for transit packets exiting the router through the tunnel. Guidelines for Configuring Standard Firewall Filters on page 21 Standard Firewall Filter Match Conditions for IPv4 Traffic on page 48 Standard Firewall Filter Match Conditions for IPv6 Traffic on page 57
Junos OS Source Class Usage Feature Guide
Firewall Filter Match Conditions Based on Numbers or Text Aliases on page 31 Firewall Filter Match Conditions Based on Bit-Field Values on page 32 Firewall Filter Match Conditions Based on Address Fields on page 37
46
CHAPTER 4
Standard Firewall Filter Match Conditions and Actions

Standard Firewall Filter Match Conditions for Protocol-Independent Traffic on page 47 Standard Firewall Filter Match Conditions for IPv4 Traffic on page 48 Standard Firewall Filter Match Conditions for IPv6 Traffic on page 57 Standard Firewall Filter Match Conditions for MPLS Traffic on page 62 Standard Firewall Filter Match Conditions for MPLS-Tagged IPv4 Traffic on page 64 Standard Firewall Filter Match Conditions for VPLS Traffic on page 66 Standard Firewall Filter Match Conditions for Layer 2 CCC Traffic on page 73 Standard Firewall Filter Match Conditions for Layer 2 Bridging Traffic on page 75 Standard Firewall Filter Terminating Actions on page 81 Standard Firewall Filter Nonterminating Actions on page 82
Standard Firewall Filter Match Conditions for Protocol-Independent Traffic

You can configure a standard stateless firewall filter with match conditions for protocol-independent traffic (family any).
NOTE: Protocol-independent standard firewall filtersfirewall filters configured at the [edit firewall family any] hierarchy level are not supported on the router loopback interface (lo0).
Table 11 on page 48 describes the match-conditions you can configure at the [edit firewall family any filter filter-name term term-name from] hierarchy level.
47
Table 11: Standard Firewall Filter Match Conditions for Protocol-Independent Traffic
Match Condition
forwarding-class class
Description
Match the forwarding class of the packet. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control. For information about forwarding classes and router-internal output queues, see the Junos OS Class of Service Configuration Guide.
forwarding-class-except class interface interface-name
Do not match on the forwarding class. For details, see the forwarding-class match condition.
Match the interface on which the packet was received. NOTE: If you configure this match condition with an interface that does not exist, the term does not match any packet.
interface-set interface-set-name
Match the interface on which the packet was received to the specified interface set. To define an interface set, include the interface-set statement at the [edit firewall] hierarchy level. For more information, see Filtering Packets Received on an Interface Set Overview on page 192.
packet-length bytes
Match the length of the received packet, in bytes. The length refers only to the IP packet, including the packet header, and does not include any Layer 2 encapsulation overhead. Do not match on the received packet length, in bytes. For details, see the packet-length match type.
packet-length-except bytes
Guidelines for Configuring Standard Firewall Filters on page 21 Standard Firewall Filter Terminating Actions on page 81 Standard Firewall Filter Nonterminating Actions on page 82
Standard Firewall Filter Match Conditions for IPv4 Traffic

You can configure a standard stateless firewall filter with match conditions for Internet Protocol version 4 (IPv4) traffic (family inet). Table 12 on page 48 describes the match-conditions you can configure at the [edit firewall family inet filter filter-name term term-name from] hierarchy level.
Table 12: Standard Firewall Filter Match Conditions for IPv4 Traffic
Match Condition
address address address address except ah-spi spi-value
Description
Match the IPv4 source or destination address field. Do not match the IPv4 source or destination address field. (M Series routers, except M120 and M320) Match the IPsec authentication header (AH) security parameter index (SPI) value.
48
Chapter 4: Standard Firewall Filter Match Conditions and Actions
Table 12: Standard Firewall Filter Match Conditions for IPv4 Traffic (continued)
Match Condition
ah-spi-except spi-value destination-address address
Description
(M Series routers, except M120 and M320) Do not match the IPsec AH SPI value. Match the IPv4 destination address field. You cannot specify both the address and destination-address match conditions in the same term.
destination-address address except destination-class class-names
Do not match the IPv4 destination address field. For more information, see the destination-address field. Match one or more specified destination class names (sets of destination prefixes grouped together and given a class name). For more information, see Firewall Filter Match Conditions Based on Address Classes on page 45. Do not match one or more specified destination class names. For details, see the destination-class match condition. Match the UDP or TCP destination port field. You cannot specify both the port and destination-port match conditions in the same term. If you configure this match condition, we recommend that you also configure the protocol udp or protocol tcp match statement in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are 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), ldp (646), 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 (49), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-class-except class-names destination-port number
destination-port-except number destination-prefix-list name
Do not match the UDP or TCP destination port field. For details, see the destination-port match condition. Match destination prefixes in the specified list. Specify the name of a prefix list defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. Do not match destination prefixes in the specified list. For more information, see the destination-prefix-list match condition.
destination-prefix-list name except
49
Match Condition
dscp number
Description
Match the Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant 6 bits of this byte form the DSCP. For more information, see the Junos OS Class of Service Configuration Guide. You can specify a numeric value from 0 through 63. To specify the value in hexadecimal form, include 0x as a prefix. To specify the value in binary form, include b as a prefix. In place of the numeric value, you can specify one of the following text synonyms (the field values are 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 each class, 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-except number esp-spi spi-value
Do not match on the DSCP number. For more information, see the dscp match condition. Match the IPsec encapsulating security payload (ESP) SPI value. Match on this specific SPI value. You can specify the ESP SPI value in hexadecimal, binary, or decimal form. Match the IPsec ESP SPI value. Do not match on this specific SPI value. Match if the packet is the first fragment of a fragmented packet. Do not match if the packet is a trailing fragment of a fragmented packet. The first fragment of a fragmented packet has a fragment offset value of 0. This match condition is an alias for the bit-field match condition fragment-offset 0 match condition. To match both first and trailing fragments, you can use two terms that specify different match conditions: first-fragment and is-fragment.
esp-spi-except spi-value first-fragment
forwarding-class-except class fragment-flags number
Do not match the forwarding class of the packet. For details, see the forwarding-class match condition. (Ingress only) Match the three-bit IP fragmentation flags field in the IP header. In place of the numeric field value, you can specify one of the following keywords (the field values are also listed): dont-fragment (0x4), more-fragments (0x2), or reserved (0x8).
50
Match Condition
fragment-offset value
Description
Match the 13-bit fragment offset field in the IP header. The value is the offset, in 8-byte units, in the overall datagram message to the data fragment. Specify a numeric value, a range of values, or a set of values. An offset value of 0 indicates the first fragment of a fragmented packet. The first-fragment match condition is an alias for the fragment-offset 0 match condition. To match both first and trailing fragments, you can use two terms that specify different match conditions (first-fragment and is-fragment).
fragment-offset-except number icmp-code number
Do not match the 13-bit fragment offset field.
Match the ICMP message code field. If you configure this match condition, we recommend that you also configure the protocol icmp match condition in the same term. If you configure this match condition, you must also configure the icmp-type message-type match condition in the same term. An ICMP message code provides more specific information than an ICMP message type, but the meaning of an ICMP message code is dependent on the associated ICMP message type. In place of the numeric value, you can specify one of the following text synonyms (the field values are 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-except message-code icmp-type number
Do not match the ICMP message code field. For details, see the icmp-code match condition.
Match the ICMP message type field. If you configure this match condition, we recommend that you also configure the protocol icmp match condition in the same term. In place of the numeric value, you can specify one of the following text synonyms (the field values are 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-except message-type
Do not match the ICMP message type field. For details, see the icmp-type match condition.
51
Match Condition
interface interface-name
Description
interface-group group-number
Match the logical interface on which the packet was received to the specified interface group or set of interface groups. For group-number, specify a single value or a range of values from 0 through 255. To assign a logical interface to an interface group group-number, specify the group-number at the [interfaces interface-name unit number family family filter group] hierarchy level. For more information, see Filtering Packets Received on a Set of Interface Groups Overview on page 185.
interface-group-except group-number interface-set interface-set-name
Do not match the logical interface on which the packet was received to the specified interface group or set of interface groups. For details, see the interface-group match condition. Match the interface on which the packet was received to the specified interface set. To define an interface set, include the interface-set statement at the [edit firewall] hierarchy level. For more information, see Filtering Packets Received on an Interface Set Overview on page 192.
52
Match Condition
ip-options values
Description
Match the 8-bit IP option field, if present, to the specified value or list of values. In place of a numeric value, you can specify one of the following text synonyms (the option values are also listed): loose-source-route (131), record-route (7), router-alert (148), security (130), stream-id (136),strict-source-route (137), or timestamp (68). To match any value for the IP option, use the text synonym any. To match on multiple values, specify the list of values within square brackets ('[ and ']). To match a range of values, use the value specification [ value1-value2 ]. For example, the match condition ip-options [ 0-147 ] matches on an IP options field that contains the loose-source-route, record-route, or security values, or any other value from 0 through 147. However, this match condition does not match on an IP options field that contains only the router-alert value (148). For most interfaces, a filter term that specifies an ip-option match on one or more specific IP option values (a value other than any) causes packets to be sent to the Routing Engine so that the kernel can parse the IP option field in the packet header.
For a firewall filter term that specifies an ip-option match on one or more specific IP option values, you cannot specify the count, log, or syslog nonterminating actions unless you also specify the discard terminating action in the same term. This behavior prevents double-counting of packets for a filter applied to a transit interface on the router. Packets processed on the kernel might be dropped in case of a system bottleneck. To ensure that matched packets are instead sent to the Packet Forwarding Engine (where packet processing is implemented in hardware), use the ip-options any match condition.
The 10-Gigabit Ethernet Modular Port Concentrator (MPC), 60-Gigabit Ethernet MPC, 60-Gigabit Queuing Ethernet MPC, and 60-Gigabit Ethernet Enhanced Queuing MPC on MX Series routers are capable of parsing the IP option field of the IPv4 packet header. For interfaces configured on those MPCs, all packets that are matched using the ip-options match condition are sent to the Packet Forwarding Engine for processing.
ip-options-except values
Do not match the IP option field to the specified value or list of values. For details about specifying the values, see the ip-options match condition. Match if the packet is a trailing fragment of a fragmented packet. Do not match the first fragment of a fragmented packet. NOTE: To match both first and trailing fragments, you can use two terms that specify different match conditions (first-fragment and is-fragment).
is-fragment
53
Match Condition
loss-priority level
Description
Match the packet loss priority (PLP) level. Specify a single level or multiple levels: low, medium-low, medium-high, or high. Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced CFEB (CFEB-E); and MX Series routers. For IP traffic on M320, MX Series, and T Series routers with Enhanced II Flexible PIC Concentrators (FPCs), you must include the tri-color statement at the [edit class-of-service] hierarchy level to commit a PLP configuration with any of the four levels specified. If the tri-color statement is not enabled, you can only configure the high and low levels. This applies to all protocol families. For information about the tri-color statement and for information about using behavior aggregate (BA) classifiers to set the PLP level of incoming packets, see the Junos OS Class of Service Configuration Guide.
loss-priority-except level packet-length bytes
Do not match the PLP level. For details, see the loss-priority match condition. Match the length of the received packet, in bytes. The length refers only to the IP packet, including the packet header, and does not include any Layer 2 encapsulation overhead. Do not match the length of the received packet, in bytes. For details, see the packet-length match type. Match the UDP or TCP source or destination port field. If you configure this match condition, you cannot configure the destination-port match condition or the source-port match condition in the same term. If you configure this match condition, we recommend that you also configure the protocol udp or protocol tcp match statement in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the text synonyms listed under destination-port.
port number
port-except number
Do not match the UDP or TCP source or destination port field. For details, see the port match condition. Match the IP precedence field. In place of the numeric field value, you can specify one of 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), or routine (0x00). You can specify precedence in hexadecimal, binary, or decimal form.
precedence ip-precedence-field
prefix-list name
Match the prefixes of the source or destination address fields to the prefixes in the specified list. The prefix list is defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. Do not match the prefixes of the source or destination address fields to the prefixes in the specified list. For more information, see the prefix-list match condition.
prefix-list name except
54
Match Condition
protocol number
Description
Match the IP protocol type field. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), dstopts (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112). Match a packet received from a filter where a service-filter-hit action was applied. Match the IPv4 address of the source node sending the packet. You cannot specify both the address and source-address match conditions in the same term.
service-filter-hit source-address address
source-address address except source-class class-names
Do not match the IPv4 address of the source node sending the packet. For more information, see the source-address match condition. Match one or more specified source class names (sets of source prefixes grouped together and given a class name). For more information, see Firewall Filter Match Conditions Based on Address Classes on page 45. Do not match one or more specified source class names. For details, see the source-class match condition. Match the UDP or TCP source port field. You cannot specify the port and source-port match conditions in the same term. If you configure this match condition for IPv4 traffic, we recommend that you also configure the protocol udp or protocol tcp match statement in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the text synonyms listed with the destination-port number match condition.
source-class-except class-names source-port number
source-port-except number source-prefix-list name
Do not match the UDP or TCP source port field. For details, see the source-port match condition. Match source prefixes in the specified list. Specify the name of a prefix list defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. Do not match source prefixes in the specified list. For more information, see the source-prefix-list match condition. Match TCP packets of an established TCP session (packets other than the first packet of a connection). This is an alias for tcp-flags "(ack | rst)". This match condition does not implicitly check that the protocol is TCP. To check this, specify the protocol tcp match condition.
source-prefix-list name except tcp-established
55
Match Condition
tcp-flags value
Description
Match one or more of the low-order 6 bits in the 8-bit TCP flags field in the TCP header. To specify individual bit fields, you can specify the following text synonyms or hexadecimal values:

fin (0x01) syn (0x02) rst (0x04) push (0x08) ack (0x10) urgent (0x20)
In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all packets sent after the initial packet. You can string together multiple flags using the bit-field logical operators. For combined bit-field match conditions, see the tcp-established and tcp-initial match conditions. If you configure this match condition, we recommend that you also configure the protocol tcp match statement in the same term to specify that the TCP protocol is being used on the port. For IPv4 traffic only, this match condition does not implicitly check whether the datagram contains the first fragment of a fragmented packet. To check for this condition for IPv4 traffic only, use the first-fragment match condition.
tcp-initial
Match the initial packet of a TCP connection. This is an alias for tcp-flags "(!ack & syn)". This condition does not implicitly check that the protocol is TCP. If you configure this match condition, we recommend that you also configure the protocol tcp match condition in the same term.
ttl number
Match the IPv4 time-to-live number. Specify a TTL value or a range of TTL values. For number, you can specify one or more values from 0 through 255. This match condition is supported only on M120, M320, MX Series, and T Series routers. Do not match on the IPv4 TTL number. For details, see the ttl match condition. Match the virtual local area network (VLAN) Ethernet type field of a VPLS packet. Do not match the VLAN Ethernet type field of a VPLS packet.
ttl-except number vlan-ether-type value vlan-ether-type-except value
56
Standard Firewall Filter Match Conditions for IPv6 Traffic

You can configure a standard stateless firewall filter with match conditions for Internet Protocol version 6 (IPv6) traffic (family inet6). Table 13 on page 57 describes the match-conditions you can configure at the [edit firewall family inet6 filter filter-name term term-name from] hierarchy level.
Table 13: Standard Firewall Filter Match Conditions for IPv6 Traffic
Match Condition
address address address address except destination-address address
Description
Match the IPv6 source or destination address field. Do not match the IPv6 source or destination address field. Match the IPv6 destination address field. You cannot specify both the address and destination-address match conditions in the same term.
destination-address address except destination-class class-names
Do not match the IPv6 destination address field. For more information, see the destination-address field. Match one or more specified destination class names (sets of destination prefixes grouped together and given a class name). For more information, see Firewall Filter Match Conditions Based on Address Classes on page 45. Do not match one or more specified destination class names. For details, see the destination-class match condition. Match the UDP or TCP destination port field. You cannot specify both the port and destination-port match conditions in the same term. If you configure this match condition, we recommend that you also configure the next-header udp or next-header tcp match condition in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are 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), ldp (646), 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 (49), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-class-except class-names destination-port number
destination-port-except number destination-prefix-list prefix-list-name
Do not match the UDP or TCP destination port field. For details, see the destination-port match condition. Match the prefix of the IPv6 destination address field. The prefix list is defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level.
57
Match Condition
destination-prefix-list prefix-list-name except forwarding-class class
Description
Do not match the prefix of the IPv6 destination address field. For more information, see the destination-prefix-list match condition. Match the forwarding class of the packet. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control. For information about forwarding classes and router-internal output queues, see the Junos OS Class of Service Configuration Guide.
forwarding-class-except class icmp-code message-code
Do not match the forwarding class of the packet. For details, see the forwarding-class match condition. Match the ICMP message code field. If you configure this match condition, we recommend that you also configure the next-header icmpv6 match condition in the same term. If you configure this match condition, you must also configure the icmp-type message-type match condition in the same term. An ICMP message code provides more specific information than an ICMP message type, but the meaning of an ICMP message code is dependent on the associated ICMP message type. In place of the numeric value, you can specify one of the following text synonyms (the field values are 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) time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0) destination-unreachable: administratively-prohibited (1), address-unreachable (3), no-route-to-destination (0), port-unreachable (4)
NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
icmp-code-except message-code icmp-type message-type
Match the ICMP message type field. If you configure this match condition, we recommend that you also configure the next-header icmpv6 match condition in the same term. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): destination-unreachable (1), 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), or time-exceeded (3). NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
icmp-type-except message-type
58
Match Condition
Description
Match the logical interface on which the packet was received to the specified interface group or set of interface groups. For group-number, specify a single value or a range of values from 0 through 255. To assign a logical interface to an interface group group-number, specify the group-number at the [interfaces interface-name unit number family family filter group] hierarchy level. For more information, see Filtering Packets Received on a Set of Interface Groups Overview on page 185. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
interface-group-except group-number interface-set interface-set-name
loss-priority level
loss-priority-except level next-header header-type
Do not match the PLP level. For details, see the loss-priority match condition. Match the 8-bit IP protocol field that identifies the type of header immediately following the IPv6 header. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), dstops (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmpv6 (58), 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).
59
Match Condition
next-header-except header-type packet-length bytes
Description
Do not match the 8-bit IP protocol field that identifies the type of header immediately following the IPv6 header. For details, see the next-header match type. Match the length of the received packet, in bytes. The length refers only to the IP packet, including the packet header, and does not include any Layer 2 encapsulation overhead. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
Do not match the length of the received packet, in bytes. For details, see the packet-length match type. Match the UDP or TCP source or destination port field. If you configure this match condition, you cannot configure the destination-port match condition or the source-port match condition in the same term. If you configure this match condition, we recommend that you also configure the next-header udp or next-header tcp match condition in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the text synonyms listed under destination-port. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
port number
port-except number
Do not match the UDP or TCP source or destination port field. For details, see the port match condition. Match the prefixes of the source or destination address fields to the prefixes in the specified list. The prefix list is defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. Do not match the prefixes of the source or destination address fields to the prefixes in the specified list. For more information, see the prefix-list match condition. Match a packet received from a filter where a service-filter-hit action was applied. Match the IPv6 address of the source node sending the packet. You cannot specify both the address and source-address match conditions in the same term.
prefix-list prefix-list-name
prefix-list prefix-list-name except service-filter-hit source-address address
source-address address except source-class class-names
Do not match the IPv6 address of the source node sending the packet. For more information, see the source-address match condition. Match one or more specified source class names (sets of source prefixes grouped together and given a class name). For more information, see Firewall Filter Match Conditions Based on Address Classes on page 45. Do not match one or more specified source class names. For details, see the source-class match condition.
source-class-except class-names
60
Match Condition
source-port number
Description
Match the UDP or TCP source port field. You cannot specify the port and source-port match conditions in the same term. If you configure this match condition, we recommend that you also configure the next-header udp or next-header tcp match condition in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the text synonyms listed with the destination-port number match condition.
Do not match the UDP or TCP source port field. For details, see the source-port match condition. Match the IPv6 address prefix of the packet source field. Specify a prefix list name defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. Do not match the IPv6 address prefix of the packet source field. For more information, see the source-prefix-list match condition. Match TCP packets other than the first packet of a connection. This is a text synonym for tcp-flags "(ack | rst)" (0x14). NOTE: This condition does not implicitly check that the protocol is TCP. To check this, specify the protocol tcp match condition. If you configure this match condition, we recommend that you also configure the next-header tcp match condition in the same term. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
source-prefix-list name except tcp-established
tcp-flags flags

In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all packets sent after the initial packet. You can string together multiple flags using the bit-field logical operators. For combined bit-field match conditions, see the tcp-established and tcp-initial match conditions. If you configure this match condition, we recommend that you also configure the next-header tcp match condition in the same term to specify that the TCP protocol is being used on the port. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
61
Match Condition
tcp-initial
Description
Match the initial packet of a TCP connection. This is a text synonym for tcp-flags "(!ack & syn)". This condition does not implicitly check that the protocol is TCP. If you configure this match condition, we recommend that you also configure the next-header tcp match condition in the same term. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
traffic-class number
Match the 8-bit field that specifies the class-of-service (CoS) priority of the packet. This field was previously used as the type-of-service (ToS) field in IPv4. You can specify a numeric value from 0 through 63. To specify the value in hexadecimal form, include 0x as a prefix. To specify the value in binary form, include b as a prefix. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed):


af11 (10), af12 (12), af13 (14) af21 (18), af22 (20), af23 (22) af31 (26), af32 (28), af33 (30) af41 (34), af42 (36), af43 (38)
traffic-class-exception number
Do not match the 8-bit field that specifies the CoS priority of the packet. For details, see the traffic-class match description.
NOTE: If you specify an IPv6 address in a match condition (the address, destination-address, or source-address match conditions), use the syntax for text representations described in RFC 2373, IP Version 6 Addressing Architecture. For more information about IPv6 addresses, see IPv6 Overview and IPv6 Standards in the Junos OS Routing Protocols Configuration Guide.
Standard Firewall Filter Match Conditions for MPLS Traffic

You can configure a standard stateless firewall filter with match conditions for MPLS traffic (family mpls).
62
NOTE: The input-list filter-names and output-list filter-names statements for firewall filters for the mpls protocol family are supported on all interfaces with the exception of management interfaces and internal Ethernet interfaces (fxp or em0), loopback interfaces (lo0), and USB modem interfaces (umd).
Table 14 on page 63 describes the match-conditions you can configure at the [edit firewall family mpls filter filter-name term term-name from] hierarchy level.
Table 14: Standard Firewall Filter Match Conditions for MPLS Traffic
Match Condition
exp number
Description
Experimental (EXP) bit number or range of bit numbers in the MPLS header. For number, you can specify one or more values from 0 through 7 in decimal, binary, or hexadecimal format. Do not match on the EXP bit number or range of bit numbers in the MPLS header. For number, you can specify one or more values from 0 through 7. Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control. Do not match on the forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control. Interface on which the packet was received. You can configure a match condition that matches packets based on the interface on which they were received. NOTE: If you configure this match condition with an interface that does not exist, the term does not match any packet.
exp-except number
forwarding-class-except class interface interface-name
interface-set interface-set-name
Match the interface on which the packet was received to the specified interface set. To define an interface set, include the interface-set statement at the [edit firewall] hierarchy level. For more information, see Filtering Packets Received on an Interface Set Overview on page 192.
ip-version number
(Interfaces on Enhanced Scaling flexible PIC concentrators [FPCs] on supported T Series routers only) Inner IP version. To match MPLS-tagged IPv4 packets, match on the text synonym ipv4.
63
Table 14: Standard Firewall Filter Match Conditions for MPLS Traffic (continued)
Match Condition
loss-priority level
Description
loss-priority-except level
Do not match the PLP level. For details, see the loss-priority match condition.
Standard Firewall Filter Match Conditions for MPLS-Tagged IPv4 Traffic


Matching on IPv4 Packet Header Address or Port Fields in MPLS Flows on page 64 IP Address Match Conditions for MPLS Traffic on page 65 IP Port Match Conditions for MPLS Traffic on page 65
Matching on IPv4 Packet Header Address or Port Fields in MPLS Flows

To support network-based service in a core network, you can configure a standard firewall filter that matches Internet Protocol version 4 (IPv4) packet header fields in MPLS traffic (family mpls). The firewall filter can match IPv4 packets as an inner payload of an MPLS packet that has a single MPLS label or up to five MPLS labels stacked together. You can configure match conditions based on IPv4 addresses and IPv4 port numbers in the header. Standard firewall filters based on MPLS-tagged IPv4 headers are supported for interfaces on Enhanced Scaling flexible PIC concentrators (FPCs) on supported T Series routers only. The feature is not supported for the router loopback interface (lo0), the router management interface (fxp0 or em0), or USB modem interfaces (umd).
64
To configure a stateless firewall filter term that matches on address or port fields in the IPv4 header of packets in an MPLS flow, you use the ip-version ipv4 match condition to specify that the term is to match packets based on inner IP fields:
To match an MPLS-tagged IPv4 packet on the source or destination address field in the IPv4 header, specify the match condition at the [edit firewall family mpls filter filter-name term term-name from ip-version ipv4] hierarchy level. To match an MPLS-tagged IPv4 packet on the source or destination port field in the IPv4 header, specify the match condition at the [edit firewall family mpls filter filter-name term term-name from ip-version ipv4 protocol (udp | tcp)] hierarchy level.
IP Address Match Conditions for MPLS Traffic

Table 15 on page 65 describes the IP address-specific match-conditions you can configure at the [edit firewall family mpls filter filter-name term term-name from ip-version ipv4] hierarchy level.
Table 15: IP Address-Specific Firewall Filter Match Conditions for MPLS Traffic
Match Condition
destination-address address
Description
Match the 32-bit IPv4 address of the destination node to receive the packet. Do not match the 32-bit IPv4 address of the destination node to receive the packet. Match the IP protocol type field. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), dstopts (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112). Match the 32-bit IPv4 address of the source node sending the packet. Do not match the 32-bit IPv4 address of the source node sending the packet.
destination-address address except protocol number
source-address address
source-address address except
IP Port Match Conditions for MPLS Traffic

Table 16 on page 66 describes the IP port-specific match-conditions you can configure at the [edit firewall family mpls filter filter-name term term-name from ip-version ipv4 protocol (udp | tcp )] hierarchy level.
65
Table 16: IP Port-Specific Firewall Filter Match Conditions for MPLS Traffic
Match Condition
destination-port number
Description
Match on the UDP or TCP destination port field. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are 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), ldp (646), 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 (49), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-port-except number
Do not match on the UDP or TCP destination port field. In place of the numeric value, you can specify one of the text synonyms listed with the destination-port match condition.
source-port number
Match on the TCP or UDP source port field. In place of the numeric field, you can specify one of the text synonyms listed under destination-port.
source-port-except number
Do not match on the TCP or UDP source port field.
Standard Firewall Filter Match Conditions for VPLS Traffic

In the from statement in the VPLS filter term, you specify conditions that the packet must match for the action in the then statement to be taken. All conditions in the from statement must match for the action to be taken. The order in which you specify match conditions is not important, because a packet must match all the conditions in a term for a match to occur. If you specify no match conditions in a term, that term matches all packets. An individual condition in a from statement can contain a list of values. For example, you can specify numeric ranges. You can also specify multiple source addresses or destination addresses. When a condition defines a list of values, a match occurs if one of the values in the list matches the packet.
66
Individual conditions in a from statement can be negated. When you negate a condition, you are defining an explicit mismatch. For example, the negated match condition for forwarding-class is forwarding-class-except. If a packet matches a negated condition, it is immediately considered not to match the from statement, and the next term in the filter is evaluated, if there is one. If there are no more terms, the packet is discarded. You can configure a standard firewall filter with match conditions for Virtual Private LAN Service (VPLS) traffic (family vpls). Table 17 on page 67 describes the match-conditions you can configure at the [edit firewall family vpls filter filter-name term term-name from] hierarchy level.
NOTE: Not all match conditions for VPLS traffic are supported on all routing platforms. A number of match conditions for VPLS traffic are supported only on MX Series 3D Universal Edge Routers.
Table 17: Standard Firewall Filter Match Conditions for VPLS Traffic
Match Condition
destination-mac-address address destination-port number
Description
Match the destination media access control (MAC) address of a VPLS packet.
(MX Series routers only) Match the UDP or TCP destination port field. You cannot specify both the port and destination-port match conditions in the same term. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are 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), ldp (646), 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 (49), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-port-except number destination-prefix-list name
(MX Series routers only) Do not match on the TCP or UDP destination port field. You cannot specify both the port and destination-port match conditions in the same term. (MX Series routers only) Match destination prefixes in the specified list. Specify the name of a prefix list defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. NOTE: VPLS prefix lists support only IPv4 addresses. IPv6 addresses included in a VPLS prefix list will be discarded.
destination-prefix-list name except
(MX Series routers only) Do not match destination prefixes in the specified list. For more information, see the destination-prefix-list match condition.
67
Table 17: Standard Firewall Filter Match Conditions for VPLS Traffic (continued)
Match Condition
dscp number
Description
(MX Series routers only) Match the Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant 6 bits of this byte form the DSCP. For more information, see the Junos OS Class of Service Configuration Guide. You can specify a numeric value from 0 through 63. To specify the value in hexadecimal form, include 0x as a prefix. To specify the value in binary form, include b as a prefix. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed):

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-except number ether-type values
(MX Series routers only) Do not match on the DSCP. For details, see the dscp match condition. Match the 2-octet IEEE 802.3 Length/EtherType field to the specified value or list of values. You can specify decimal or hexadecimal values from 0 through 65535 (0xFFFF). A value from 0 through 1500 (0x05DC) specifies the length of an Ethernet Version 1 frame. A value from 1536 (0x0600) through 65535 specifies the EtherType (nature of the MAC client protocol) of an Ethernet Version 2 frame. In place of the numeric value, you can specify one of the following text synonyms (the hexadecimal values are also listed): aarp (0x80F3), appletalk (0x809B), arp (0x0806), ipv4 (0x0800), ipv6 (0x86DD), mpls-multicast (0x8848), mpls-unicast (0x8847), oam (0x8902), ppp (0x880B), pppoe-discovery (0x8863), pppoe-session (0x8864), or sna (0x80D5).
ether-type-except values
Do not match the 2-octet Length/EtherType field to the specified value or list of values. For details about specifying the values, see the ether-type match condition.
Match the forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control. Do not match the forwarding class. For details, see the forwarding-class match condition.
forwarding-class-except class
68
Match Condition
icmp-code message-code
Description
Match the ICMP message code field. If you configure this match condition, we recommend that you also configure the next-header icmp, next-header icmp6, or next-header icmpv6 match condition in the same term. If you configure this match condition, you must also configure the icmp-type message-type match condition in the same term. An ICMP message code provides more specific information than an ICMP message type, but the meaning of an ICMP message code is dependent on the associated ICMP message type. In place of the numeric value, you can specify one of the following text synonyms (the field values are 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) time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0) destination-unreachable: address-unreachable (3), administratively-prohibited (1), no-route-to-destination (0), port-unreachable (4)
icmp-code-except message-code icmp-code number
(MX Series routers only) Match the ICMP message code field. If you configure this match condition, we recommend that you also configure the ip-protocol icmp, ip-protocol icmp6, or ip-protocol icmpv6 match condition in the same term. If you configure this match condition, you must also configure the icmp-type message-type match condition in the same term. An ICMP message code provides more specific information than an ICMP message type, but the meaning of an ICMP message code is dependent on the associated ICMP message type. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed). The keywords are grouped by the ICMP type with which they are associated:
icmp-code-except number
(MX Series routers only) Do not match on the ICMP code field. For details, see the icmp-code match condition.
69
Match Condition
icmp-type number
Description
(MX Series routers only) Match the ICMP message type field. If you configure this match condition, we recommend that you also configure the ip-protocol icmp, ip-protocol icmp6, or ip-protocol icmpv6 match condition in the same term. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): destination-unreachable (1), 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), or time-exceeded (3).
icmp-type-except number
(MX Series routers only) Do not match the ICMP message type field. For details, see the icmp-type match condition. Interface on which the packet was received. You can configure a match condition that matches packets based on the interface on which they were received. NOTE: If you configure this match condition with an interface that does not exist, the term does not match any packet.
interface-group-except group-name interface-set interface-set-name
ip-address address ip-destination-address address ip-precedence ip-precedence-field
(MX Series routers only) 32-bit address that supports the standard syntax for IPv4 addresses. (MX Series routers only) 32-bit address that is the final destination node address for the packet.
(MX Series routers only) IP precedence field. In place of the numeric field value, you can specify one of 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), or routine (0x00). (MX Series routers only) Do not match on the IP precedence field.
ip-precedence-except ip-precedence-field
70
Match Condition
ip-protocol number ip-protocol-except number ip-source-address address learn-vlan-1p-priority number
Description
(MX Series routers only) IP protocol field. (MX Series routers only) Do not match on the IP protocol field. (MX Series routers only) IP address of the source node sending the packet. (MX Series routers only) Match on the IEEE 802.1p learned VLAN priority bits in the provider VLAN tag (the only tag in a single-tag frame with 802.1Q VLAN tags or the outer tag in a dual-tag frame with 802.1Q VLAN tags). Specify a single value or multiple values from 0 through 7. Compare with the user-vlan-1p-priority match condition.
learn-vlan-1p-priority-except number learn-vlan-id number learn-vlan-id-except number loss-priority level
(MX Series routers only) Do not match on the IEEE 802.1p learned VLAN priority bits. For details, see the learn-vlan-1p-priority match condition. (MX Series routers only) VLAN identifier used for MAC learning. (MX Series routers only) Do not match on the VLAN identifier used for MAC learning. Packet loss priority (PLP) level. Specify a single level or multiple levels: low, medium-low, medium-high, or high. Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced CFEB (CFEB-E); and MX Series routers. For IP traffic on M320, MX Series, and T Series routers with Enhanced II Flexible PIC Concentrators (FPCs), you must include the tri-color statement at the [edit class-of-service] hierarchy level to commit a PLP configuration with any of the four levels specified. If the tri-color statement is not enabled, you can only configure the high and low levels. This applies to all protocol families. For information about the tri-color statement and about using behavior aggregate (BA) classifiers to set the PLP level of incoming packets, see the Junos OS Class of Service Configuration Guide.
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 incoming packets, see the Junos OS Class of Service Configuration Guide.
port number
(MX Series routers only) TCP or UDP source or destination port. You cannot specify both the port match condition and either the destination-port or source-port match condition in the same term. (MX Series routers only) Do not match on the TCP or UDP source or destination port. You cannot specify both the port match condition and either the destination-port or source-port match condition in the same term.
port-except number
71
Match Condition
prefix-list name
Description
(MX Series routers only) Match the destination or source prefixes in the specified list. Specify the name of a prefix list defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. NOTE: VPLS prefix lists support only IPV4 addresses. IPV6 addresses included in a VPLS prefix list will be discarded.
prefix-list name except
(MX Series routers only) Do not match the destination or source prefixes in the specified list. For more information, see the destination-prefix-list match condition. Source MAC address of a VPLS packet. (MX Series routers only) TCP or UDP source port field. You cannot specify the port and source-port match conditions in the same term. (MX Series routers only) Do not match on the TCP or UDP source port field. You cannot specify the port and source-port match conditions in the same term. (MX Series routers only) Match the source prefixes in the specified prefix list. Specify a prefix list name defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. NOTE: VPLS prefix lists support only IPV4 addresses. IPV6 addresses included in a VPLS prefix list will be discarded.
source-mac-address address source-port number
source-port-except number
source-prefix-list name
source-prefix-list name except tcp-flags flags
(MX Series routers only) Do not match the source prefixes in the specified prefix list. For more information, see the source-prefix-list match condition. Match one or more of the low-order 6 bits in the 8-bit TCP flags field in the TCP header. To specify individual bit fields, you can specify the following text synonyms or hexadecimal values:

In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all packets sent after the initial packet. You can string together multiple flags using the bit-field logical operators. If you configure this match condition for IPv6 traffic, we recommend that you also configure the next-header tcp match condition in the same term to specify that the TCP protocol is being used on the port.
traffic-type type-name
(MX Series routers only) Traffic type. Specify broadcast, multicast, unknown-unicast, or known-unicast.
72
Match Condition
traffic-type-except type-name user-vlan-1p-priority number
Description
(MX Series routers only) Do not match on the traffic type. Specify broadcast, multicast, unknown-unicast, or known-unicast. (MX Series routers only) Match on the IEEE 802.1p user priority bits in the customer VLAN tag (the inner tag in a dual-tag frame with 802.1Q VLAN tags). Specify a single value or multiple values from 0 through 7. Compare with the learn-vlan-1p-priority match condition.
user-vlan-1p-priority-except number user-vlan-id number user-vlan-id-except number vlan-ether-type value vlan-ether-type-except value
(MX Series routers only) Do not match on the IEEE 802.1p user priority bits. For details, see the user-vlan-1p-priority match condition. (MX Series routers only) Match the first VLAN identifier that is part of the payload. (MX Series routers only) Do not match on the first VLAN identifier that is part of the payload. VLAN Ethernet type field of a VPLS packet. Do not match on the VLAN Ethernet type field of a VPLS packet.
Standard Firewall Filter Match Conditions for Layer 2 CCC Traffic

You can configure a standard stateless firewall filter with match conditions for Layer 2 circuit cross-connect (CCC) traffic (family ccc). The following restrictions apply to firewall filters for Layer 2 CCC traffic:
The input-list filter-names and output-list filter-names statements for firewall filters for the ccc protocol family are supported on all interfaces with the exception of management interfaces and internal Ethernet interfaces (fxp or em0), loopback interfaces (lo0), and USB modem interfaces (umd). On MX Series routers only, you cannot apply a Layer 2 CCC stateless firewall filter (a firewall filter configured at the [edit firewall filter family ccc] hierarchy level) as an output filter. On MX Series routers, firewall filters configured for the family ccc statement can be applied only as input filters.
Table 18 on page 74 describes the match-conditions you can configure at the [edit firewall family ccc filter filter-name term term-name from] hierarchy level.
73
Table 18: Standard Firewall Filter Match Conditions for Layer 2 CCC Traffic
Match Condition
destination-mac-address address
Description
(MX Series routers only) Match the destination media access control (MAC) address of a virtual private LAN service (VPLS) packet. To have packets correctly evaluated by this match condition when applied to egress traffic flowing over a CCC circuit from a logical interface on an I-chip DPC in a Layer 2 virtual private network (VPN) routing instance, you must make a configuration change to the Layer 2 VPN routing instance. You must explicitly disable the use of a control word for traffic flowing out over a Layer 2 circuit. The use of a control word is enabled by default for Layer 2 VPN routing instances to support the emulated virtual circuit (VC) encapsulation for Layer 2 circuits. To explicitly disable the use of a control word for Layer 2 VPNs, include the no-control-word statement at either of the following hierarchy levels:

[edit routing-instances routing-instance-name protocols l2vpn] [edit logical-systems logical-system-name routing-instances routing-instance-name protocols l2vpn]
For more information, see Disabling the Control Word for Layer 2 VPNs in the Junos OS VPNs Configuration Guide.
Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control. Do not match on the forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control. Match the logical interface on which the packet was received to the specified interface group or set of interface groups. For group-number, specify a single value or a range of values from 0 through 255. To assign a logical interface to an interface group group-number, specify the group-number at the [interfaces interface-name unit number family family filter group] hierarchy level. For more information, see Filtering Packets Received on a Set of Interface Groups Overview on page 185.
forwarding-class-except class interface-group group-number
interface-group-except number learn-vlan-1p-priority number
Do not match the logical interface on which the packet was received to the specified interface group or set of interface groups. For details, see the interface-group match condition. (MX Series routers only) Match on the IEEE 802.1p learned VLAN priority bits in the provider VLAN tag (the only tag in a single-tag frame with 802.1Q VLAN tags or the outer tag in a dual-tag frame with 802.1Q VLAN tags). Specify a single value or multiple values from 0 through 7. Compare with the user-vlan-1p-priority match condition.
learn-vlan-1p-priority-except number
(MX Series routers only) Do not match on the IEEE 802.1p learned VLAN priority bits. For details, see the learn-vlan-1p-priority match condition.
74
Table 18: Standard Firewall Filter Match Conditions for Layer 2 CCC Traffic (continued)
Match Condition
loss-priority level
Description
Packet loss priority (PLP) level. Specify a single level or multiple levels: low, medium-low, medium-high, or high. Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced CFEB (CFEB-E); and MX Series routers. For IP traffic on M320, MX Series, and T Series routers with Enhanced II Flexible PIC Concentrators (FPCs), you must include the tri-color statement at the [edit class-of-service] hierarchy level to commit a PLP configuration with any of the four levels specified. If the tri-color statement is not enabled, you can only configure the high and low levels. This applies to all protocol families. For information about the tri-color statement and for information about using behavior aggregate (BA) classifiers to set the PLP level of incoming packets, see the Junos OS Class of Service Configuration Guide.
user-vlan-1p-priority number
(MX Series routers only) Match on the IEEE 802.1p user priority bits in the customer VLAN tag (the inner tag in a dual-tag frame with 802.1Q VLAN tags). Specify a single value or multiple values from 0 through 7. Compare with the learn-vlan-1p-priority match condition.
user-vlan-1p-priority-except number
(MX Series routers only) Do not match on the IEEE 802.1p user priority bits. For details, see the user-vlan-1p-priority match condition.
Standard Firewall Filter Match Conditions for Layer 2 Bridging Traffic

On MX Series routers only, you can configure a standard stateless firewall filter with match conditions for Layer 2 bridging traffic (family bridge). Table 19 on page 75 describes the match-conditions you can configure at the [edit firewall family bridge filter filter-name term term-name from] hierarchy level.
Table 19: Standard Firewall Filter Match Conditions for Layer 2 Bridging (MX Series 3D Universal Edge Routers Only)
Match Condition
destination-mac-address address
Description
Destination media access control (MAC) address of a Layer 2 packet in a bridging environment.
75
Table 19: Standard Firewall Filter Match Conditions for Layer 2 Bridging (MX Series 3D Universal Edge Routers Only) (continued)
Match Condition
Description
TCP or UDP destination port field. You cannot specify both the port and destination-port match conditions in the same term. Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant 6 bits of this byte form the DSCP. For more information, see the Junos OS Class of Service Configuration Guide. You can specify a numeric value from 0 through 63. To specify the value in hexadecimal form, include 0x as a prefix. To specify the value in binary form, include b as a prefix. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed):

dscp number
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-except number ether-type value
Do not match on the DSCP number. For more information, see the dscp-except match condition. Match the 2-octet IEEE 802.3 Length/EtherType field to the specified value or list of values. You can specify decimal or hexadecimal values from 0 through 65535 (0xFFFF). A value from 0 through 1500 (0x05DC) specifies the length of an Ethernet Version 1 frame. A value from 1536 (0x0600) through 65535 specifies the EtherType (nature of the MAC client protocol) of an Ethernet Version 2 frame. In place of the numeric value, you can specify one of the following text synonyms (the hexadecimal values are also listed): aarp (0x80F3), appletalk (0x809B), arp (0x0806), ipv4 (0x0800), ipv6 (0x86DD), mpls-multicast (0x8848), mpls-unicast (0x8847), oam (0x8902), ppp (0x880B), pppoe-discovery (0x8863), pppoe-session (0x8864), sna (0x80D5).
ether-type-except value
Do not match the 2-octet IEEE 802.3 Length/EtherType field to the specified value or list of values. For details about specifying the values, see the ether-type match condition.
forwarding class class
Forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control. Ethernet type field of a Layer 2 packet environment. Specify assured-forwarding, best-effort, expedited-forwarding, or network-control.
forwarding-class-except class
76
Match Condition
icmp-code message-code
Description
Match the ICMP message code field. If you configure this match condition, we recommend that you also configure the ip-protocol icmp, ip-protocol icmp6, or ip-protocol icmpv6 match condition in the same term. If you configure this match condition, you must also configure the icmp-type message-type match condition in the same term. An ICMP message code provides more specific information than an ICMP message type, but the meaning of an ICMP message code is dependent on the associated ICMP message type. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed). The keywords are grouped by the ICMP type with which they are associated:
icmp-code-except message-code icmp-type message-type
Match the ICMP message type field. If you configure this match condition, we recommend that you also configure the ip-protocol icmp, ip-protocol icmp6, or ip-protocol icmpv6 match condition in the same term. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): destination-unreachable (1), 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), or time-exceeded (3).
icmp-type-except message-type interface interface-name
Interface on which the packet was received. You can configure a match condition that matches packets based on the interface on which they were received. NOTE: If you configure this match condition with an interface that does not exist, the term does not match any packet.
77
Match Condition
interface-group-except number interface-set interface-set-name
Description
ip-address address ip-destination-address address ip-precedence ip-precedence-field
32-bit address that supports the standard syntax for IPv4 addresses. 32-bit address that is the final destination node address for the packet.
IP precedence field. In place of the numeric field value, you can specify one of 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), or routine (0x00). Do not match on the IP precedence field.
ip-precedence-except ip-precedence-field ip-protocol number ip-source-address address isid number isid-dei number isid-dei-except number isid-priority-code-point number isid-priority-code-point-except number learn-vlan-1p-priority value
IP protocol field. IP address of the source node sending the packet. (Supported with Provider Backbone Bridging [PBB]) Match internet service identifier. (Supported with PBB) Match the Internet service identifier drop eligibility indicator (DEI) bit. (Supported with PBB) Do not match the Internet service identifier DEI bit. (Supported with PBB) Match the Internet service identifier priority code point.
(Supported with PBB) Do not match the Internet service identifier priority code point.
(MX Series routers only) Match on the IEEE 802.1p learned VLAN priority bits in the provider VLAN tag (the only tag in a single-tag frame with 802.1Q VLAN tags or the outer tag in a dual-tag frame with 802.1Q VLAN tags). Specify a single value or multiple values from 0 through 7. Compare with the user-vlan-1p-priority match condition.
learn-vlan-1p-priority-except value learn-vlan-dei number
(MX Series routers only) Do not match on the IEEE 802.1p learned VLAN priority bits. For details, see the learn-vlan-1p-priority match condition. (Supported with bridging) Match user virtual LAN (VLAN) identifier DEI bit.
78
Match Condition
learn-vlan-dei-except number learn-vlan-id number learn-vlan-id-except number loss-priority level
Description
(Supported with bridging) Do not match user VLAN identifier DEI bit.
VLAN identifier used for MAC learning. Do not match on the VLAN identifier used for MAC learning. Packet loss priority (PLP) level. Specify a single level or multiple levels: low, medium-low, medium-high, or high. Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced CFEB (CFEB-E); and MX Series routers. For IP traffic on M320, MX Series, and T Series routers with Enhanced II Flexible PIC Concentrators (FPCs), you must include the tri-color statement at the [edit class-of-service] hierarchy level to commit a PLP configuration with any of the four levels specified. If the tri-color statement is not enabled, you can only configure the high and low levels. This applies to all protocol families. For information about the tri-color statement and for information about using behavior aggregate (BA) classifiers to set the PLP level of incoming packets, see the Junos OS Class of Service Configuration Guide.
port number
TCP or UDP source or destination port. You cannot specify both the port match condition and either the destination-port or source-port match conditions in the same term. Source MAC address of a Layer 2 packet. TCP or UDP source port field. You cannot specify the port and source-port match conditions in the same term.
source-mac-address address source-port number
79
Match Condition
tcp-flags flags
Description

In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all packets sent after the initial packet. You can string together multiple flags using the bit-field logical operators. Configuring the tcp-flags match condition requires that you configure the next-header-tcp match condition.
traffic-type type traffic-type-except type user-vlan-1p-priority value
Traffic type. Specify broadcast, multicast, unknown-unicast, or known-unicast. Do not match on the traffic type. (MX Series routers only) Match on the IEEE 802.1p user priority bits in the customer VLAN tag (the inner tag in a dual-tag frame with 802.1Q VLAN tags). Specify a single value or multiple values from 0 through 7. Compare with the learn-vlan-1p-priority match condition.
user-vlan-1p-priority-except value user-vlan-id number user-vlan-id-except number vlan-ether-type value vlan-ether-type-except value
(MX Series routers only) Do not match on the IEEE 802.1p user priority bits. For details, see the user-vlan-1p-priority match condition. (MX Series routers only) Match the first VLAN identifier that is part of the payload. (MX Series routers only) Do not match on the first VLAN identifier that is part of the payload. VLAN Ethernet type field of a Layer 2 bridging packet. Do not match on the VLAN Ethernet type field of a Layer 2 bridging packet.
80
Standard Firewall Filter Terminating Actions

Standard stateless firewall filters support different sets of terminating actions for each protocol family.
NOTE: You cannot configure the next term action with a terminating action in the same filter term. However, you can configure the next term action with another nonterminating action in the same filter term.
Table 20 on page 81 describes the terminating actions you can specify in a standard firewall filter term.
Table 20: Terminating Actions for Standard Firewall Filters

Terminating Action
accept
Description
Accept the packet.
Protocols

family any family inet family inet6 family mpls family vpls family ccc family bridge family any family inet family inet6 family mpls family vpls family ccc family bridge family inet family inet6
discard
Discard a packet silently, without sending an Internet Control Message Protocol (ICMP) message. Discarded packets are available for logging and sampling.
logical-system logical-system-name
Direct the packet to the specified logical system.
81
Table 20: Terminating Actions for Standard Firewall Filters (continued)

Terminating Action
reject message-type
Description
Reject the packet and return an ICMPv4 or ICMPv6 message:
Protocols

If no message-type is specified, a destination unreachable message is returned by default. If tcp-reset is specified as the message-type, tcp-reset is returned only if the packet is a TCP packet. Otherwise, the administratively-prohibited message, which has a value of 13, is returned. If any other message-type is specified, that message is returned.
NOTE: Rejected packets can be sampled or logged if you configure the sample or syslog action. The message-type can be one of the following values: address-unreachable, administratively-prohibited, bad-host-tos, bad-network-tos, beyond-scope, fragmentation-needed, host-prohibited, host-unknown, host-unreachable, network-prohibited, network-unknown, network-unreachable, no-route, port-unreachable, precedence-cutoff, precedence-violation, protocol-unreachable, source-host-isolated, source-route-failed, or tcp-reset. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
routing-instance routing-instance-name
Direct the packet to the specified routing instance.
family inet family inet6 family inet family inet6
topology topology-name
Direct the packet to the specified topology.
Guidelines for Configuring Standard Firewall Filters on page 21 Standard Firewall Filter Nonterminating Actions on page 82
Standard Firewall Filter Nonterminating Actions

Standard stateless firewall filters support different sets of nonterminating actions for each protocol family.
NOTE: You cannot configure the next term action with a terminating action in the same filter term. However, you can configure the next term action with another nonterminating action in the same filter term.
Table 21 on page 83 describes the nonterminating actions you can configure for a standard firewall filter term.
82
Table 21: Nonterminating Actions for Standard Firewall Filters

Nonterminating Action
count counter-name
Description
Count the packet in the named counter. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
Protocol Families

family any family inet family inet6 family mpls family vpls family ccc family bridge
dscp value
Set the IPv4 Differentiated Services code point (DSCP) bit. You can specify a numerical value from 0 through 63. To specify the value in hexadecimal form, include 0x as a prefix. To specify the value in binary form, include b as a prefix. The default DSCP value is best effort, that is, be or 0. You can also specify on the following text synonyms:

family inet
af11Assured forwarding class 1, low drop precedence af12Assured forwarding class 1, medium drop precedence af13Assured forwarding class 1, high drop precedence af21Assured forwarding class 2, low drop precedence af22Assured forwarding class 2, medium drop precedence af23Assured forwarding class 2, high drop precedence af31Assured forwarding class 3, low drop precedence af32Assured forwarding class 3, medium drop precedence af33Assured forwarding class 3, high drop precedence af41Assured forwarding class 4, low drop precedence af42Assured forwarding class 4, medium drop precedence af43Assured forwarding class 4, high drop precedence beBest effort cs0Class selector 0 cs1Class selector 1 cs2Class selector 2 cs3Class selector 3 cs4Class selector 4 cs5Class selector 5 cs6Class selector 6 cs7Class selector 7 efExpedited forwarding
NOTE: The actions dscp 0 or dscp be are supported only on T Series and M320 routers and on the 10-Gigabit Ethernet Modular Port Concentrators (MPC), 60-Gigabit Ethernet MPC, 60-Gigabit Ethernet Queuing MPC, and 60-Gigabit Ethernet Enhanced Queuing MPC on MX Series routers. However, these actions are not supported on Enhanced III Flexible PIC Concentrators (FPCs) on M320 routers.
83
Table 21: Nonterminating Actions for Standard Firewall Filters (continued)

forwarding-class class-name
Description
Classify the packet to the named forwarding class:

Protocol Families

forwarding-class-name
assured-forwarding best-effort expedited-forwarding network-control
ipsec-sa ipsec-sa
Use the specified IPsec security association. NOTE: This action is not supported on MX Series routers.
family inet
load-balance group-name
Use the specified load-balancing group. NOTE: This action is not supported on MX Series routers.
family inet
log
Log the packet header information in a buffer within the Packet Forwarding Engine. You can access this information by issuing the show firewall log command at the command-line interface (CLI). NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
loss-priority (high | medium-high | medium-low | low)
Set the packet loss priority (PLP) level. You cannot also configure the three-color-policer nonterminating action for the same firewall filter term. These two nonterminating actions are mutually exclusive. Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced CFEB (CFEB-E); and MX Series routers. For IP traffic on M320, MX Series, and T Series routers with Enhanced II Flexible PIC Concentrators (FPCs), you must include the tri-color statement at the [edit class-of-service] hierarchy level to commit a PLP configuration with any of the four levels specified. If the tri-color statement is not enabled, you can only configure the high and low levels. This applies to all protocol families. For information about the tri-color statement and for information about using behavior aggregate (BA) classifiers to set the PLP level of incoming packets, see the Junos OS Class of Service Configuration Guide.
next-hop-group group-name packet-mode
Use the specified next-hop group.
family inet
Updates a bit field in the packet key buffer, which specifies traffic that will bypass flow-based forwarding. Packets with the packet-mode action modifier follow the packet-based forwarding path and bypass flow-based forwarding completely. For more information about selective stateless packet-based services, see the Junos OS Security Configuration Guide.
family any
84

policer policer-name
Description
Name of policer to use to rate-limit traffic. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
Protocol Families

family any family inet family inet6 family mpls family vpls family ccc family bridge family inet family inet6 family vpls family ccc family bridge
port-mirror
Port-mirror the packet based on the specified family. Supported on M120 routers, M320 routers configured with Enhanced III FPCs, and MX Series routers only.
prefix-action action-name sample
Count or police packets based on the specified action name.
family inet
Sample the packet. NOTE: The Junos OS does not sample packets originating from the router. If you configure a filter and apply it to the output side of an interface, then only the transit packets going through that interface are sampled. Packets that are sent from the Routing Engine to the Packet Forwarding Engine are not sampled.
family inet family inet6 family mpls
service-accounting
Count the packet for service accounting. The count is applied to a specific named counter (__junos-dyn-service-counter) that RADIUS can obtain. For more information, see Configuring Service Packet Counting in the Junos OS Subscriber Access Configuration Guide.
service-filter-hit
(Only if the service-filter-hit flag is marked by a previous filter in the current type of chained filters) Direct the packet to the next type of filters. Indicate to subsequent filters in the chain that the packet was already processed. This action, coupled with the service-filter-hit match condition in receiving filters, helps to streamline filter processing. For more information, see Configuring Firewall Filter Bypass in the Junos OS Subscriber Access Configuration Guide.
syslog
Log the packet to the system log file. NOTE: For IPv6, applies to SRX100, SRX210, SRX240, and SRX650 devices only.
85

three-color-policer (single-rate | two-rate) policer-name
Description
Police the packet using the specified single-rate or two-rate three-color-policer. You cannot also configure the loss-priority action for the same firewall filter term. These two actions are mutually exclusive.
Protocol Families

family inet family inet6 family mpls family vpls family ccc family bridge
traffic-class value
Specify the traffic-class code point. You can specify a numerical value from 0 through 63. To specify the value in hexadecimal form, include 0x as a prefix. To specify the value in binary form, include b as a prefix. The default traffic-class value is best effort, that is, be or 0. In place of the numeric value, you can specify one of the following text synonyms:

family inet6
af11Assured forwarding class 1, low drop precedence af12Assured forwarding class 1, medium drop precedence af13Assured forwarding class 1, high drop precedence af21Assured forwarding class 2, low drop precedence af22Assured forwarding class 2, medium drop precedence af23Assured forwarding class 2, high drop precedence af31Assured forwarding class 3, low drop precedence af32Assured forwarding class 3, medium drop precedence af33Assured forwarding class 3, high drop precedence af41Assured forwarding class 4, low drop precedence af42Assured forwarding class 4, medium drop precedence af43Assured forwarding class 4, high drop precedence beBest effort cs0Class selector 0 cs1Class selector 1 cs2Class selector 2 cs3Class selector 3 cs4Class selector 4 cs5Class selector 5 cs6Class selector 6 cs7Class selector 7 efExpedited forwarding
NOTE: The actions traffic-class 0 or traffic-class be are supported only on T Series and M320 routers and on the 10-Gigabit Ethernet Modular Port Concentrator (MPC), 60-Gigabit Ethernet MPC, 60-Gigabit Ethernet Queuing MPC, and 60-Gigabit Ethernet Enhanced Queuing MPC on MX Series routers. However, these actions are not supported on Enhanced III Flexible PIC Concentrators (FPCs) on M320 routers.
Guidelines for Configuring Standard Firewall Filters on page 21
86
Standard Firewall Filter Terminating Actions on page 81
87
88
CHAPTER 5
Standard Firewall Filter Configuration

Standard Firewall Filters That Match Packets on page 89 Standard Firewall Filters That Count Packets on page 100 Standard Firewall Filters That Act on Packets on page 111 Standard Firewall Filters for Trusted Sources on page 118 Standard Firewall Filters That Prevent IP Packet Flooding on page 143 Standard Firewall Filters That Handle Fragmented Packets on page 152 Standard Firewall Filters That Set Rate Limits on page 157 Multiple Standard Firewall Filters Applied as a List on page 161 Multiple Standard Firewall Filters in a Nested Configuration on page 170 Interface-Specific Firewall Filter Instances on page 177 Filtering Packets Received on a Set of Interface Groups on page 185 Filtering Packets Received on an Interface Set on page 192 Filter-Based Forwarding on page 199 Accounting for Standard Firewall Filters on page 211 Logging of Stateless Firewall Filter Activity on page 218
Standard Firewall Filters That Match Packets

Example: Configuring a Filter to Match on IPv6 Flags on page 89 Example: Configuring a Filter to Match on Port and Protocol Fields on page 91 Example: Configuring a Filter to Match on Two Unrelated Criteria on page 94 Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List on page 97
Example: Configuring a Filter to Match on IPv6 Flags

This example shows how to configure a filter to match on IPv6 TCP flags.

Requirements on page 90 Overview on page 90
89
Configuration on page 90 Verification on page 90
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
In this example, you configure a filter to match on IPv6 TCP flags. You can use this example to configure IPv6 TCP flags in the SRX100, SRX210, SRX240, SRX650, and J Series security devices and in M Series, MX Series, and T Series routing devices.
Configuration
Step-by-Step Procedure To configure a filter to match on IPv6 TCP flags:
1.
Include the family statement at the firewall hierarchy level, specifying inet6 as the protocol family.
[edit] user@host# edit firewall family inet6
2.
Create the stateless firewall filter.

[edit firewall family inet6] user@host# edit filter tcpfilt
3.
Define the first term for the filter.

[edit firewall family inet6 filter tcpfilt] user@host# edit term 1
4.
Define the source address match conditions for the term.

[edit firewall family inet6 filter tcpfilt term 1] user@host# set from next-header tcp tcp-flags syn
5.
Define the actions for the term.

[edit firewall family inet6 filter tcpfilt term 1] user@host# set then count tcp_syn_pkt log accept
6.
If you are done configuring the device, commit the configuration.

[edit firewall family inet6 filter tcpfilt term 1] user@host top [edit] user@host# commit
Verification
To confirm that the configuration is working properly, enter the show firewall filter tcpfilt command.
90
Chapter 5: Standard Firewall Filter Configuration
Example: Configuring a Filter to Match on Port and Protocol Fields

This example shows how to configure a standard stateless firewall filter to match on destination port and protocol fields.

Requirements on page 91 Overview on page 91 Configuration on page 91 Verification on page 94
Requirements
Overview
In this example, you configure a stateless firewall filter that accepts all IPv4 packets except for TCP and UDP packets. TCP and UDP packets are accepted if destined for the SSH port or the Telnet port. All other packets are rejected.
Configuration
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode on page 15.

Configure the Stateless Firewall Filter on page 92 Apply the Stateless Firewall Filter to a Logical Interface on page 92 Confirm and Commit Your Candidate Configuration on page 93
CLI Quick Configuration
To quickly configure this example, copy the following configuration commands into a text file, remove any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level:
set firewall family inet filter filter1 term term1 from protocol-except tcp set firewall family inet filter filter1 term term1 from protocol-except udp set firewall family inet filter filter1 term term1 then accept set firewall family inet filter filter1 term term2 from address 192.168.0.0/16 set firewall family inet filter filter1 term term2 then reject set firewall family inet filter filter1 term term3 from destination-port ssh set firewall family inet filter filter1 term term3 from destination-port telnet set firewall family inet filter filter1 term term3 then accept set firewall family inet filter filter1 term term4 then reject set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30 set interfaces ge-0/0/1 unit 0 family inet filter input filter1
91
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter filter1:
1.
Create the IPv4 stateless firewall filter.

[edit] user@host# edit firewall family inet filter filter1
2.
Configure a term to accept all traffic except for TCP and UDP packets.
[edit firewall family inet filter filter1] user@host# set term term1 from protocol-except tcp user@host# set term term1 from protocol-except udp user@host# set term term1 then accept
3.
Configure a term to reject packets to or from the 192.168/16 prefix.

[edit firewall family inet filter filter1] user@host# set term term2 from address 192.168.0.0/16 user@host# set term term2 then reject
4.
Configure a term to accept packets destined for either the SSH port or the Telnet port.
[edit firewall family inet filter filter1] user@host# set term term3 from destination-port ssh user@host# set term term3 from destination-port telnet user@host# set term term3 then accept
5.
Configure the last term to reject all packets.

[edit firewall family inet filter filter1] user@host# set term term4 then reject
Apply the Stateless Firewall Filter to a Logical Interface Step-by-Step Procedure To apply the stateless firewall filter to a logical interface:
1.
Configure the logical interface to which you will apply the stateless firewall filter.
[edit] user@host# edit interfaces ge-0/0/1 unit 0 family inet
2.
Configure the interface address for the logical interface.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set address 10.1.2.3/30
3.
Apply the stateless firewall filter to the logical interface.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input filter1
92
Confirm and Commit Your Candidate Configuration Step-by-Step Procedure To confirm and then commit your candidate configuration:
1.
Confirm the configuration of the stateless firewall filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit] user@host# show firewall family inet { filter filter1 { term term1 { from { protocol-except [tcp udp]; } then { accept; } } term term2 { from { address 192.168/16; } then { reject; } } term term3 { from { destination-port [ssh telnet]; } then { accept; } } term term4 { then { reject; } } } }
2.
Confirm the configuration of the interface by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit] user@host# show interfaces ge-0/0/1 { unit 0 { family inet { filter { input filter1; }
93
address 10.1.2.3/30; } } }
3.
If you are done configuring the device, commit your candidate configuration.
[edit] user@host# commit
Verification
To confirm that the configuration is working properly, enter the show firewall filter filter1 operational mode command. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Filter to Match on IPv6 Flags on page 89 Example: Configuring a Filter to Match on Two Unrelated Criteria on page 94
Example: Configuring a Filter to Match on Two Unrelated Criteria

This example shows how to configure a standard stateless firewall filter to match on two unrelated criteria.

Requirements
Overview
In this example, you use a standard stateless firewall filter to match IPv4 packets that are either OSPF packets or packets that come from an address in the prefix 10.108/16, and send an administratively-prohibited ICMP message for all packets that do not match.
Configuration
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode on page 15. To configure this example, perform the following tasks:

Configuring the IPv4 Firewall Filter on page 95 Applying the IPv4 Firewall Filter to a Logical Interface on page 96
94
To quickly configure this example, copy the following configuration commands into a text file, remove any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter ospf_or_131 term protocol_match from protocol ospf set firewall family inet filter ospf_or_131 term address-match from source-address 10.108.0.0/16 set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30 set interfaces ge-0/0/1 unit 0 family inet filter input ospf_or_131
Configuring the IPv4 Firewall Filter Step-by-Step Procedure To configure the IPv4 firewall filter:
1.
Enable configuration of the IPv4 firewall filter.

[edit] user@host# edit firewall family inet filter ospf_or_131
2.
Configure the first term to accept OSPF packets.

[edit firewall family inet filter ospf_or_131] user@host# set term protocol_match from protocol ospf
Packets that match the condition are accepted by default. Because another term follows this term, packets that do not match this condition are evaluated by the next term.
3.
Configure the second term to accept packets from any IPv4 address in a particular prefix.
[edit firewall family inet filter ospf_or_131] user@host# set term address_match from source-address 10.108.0.0/16
Packets that match this condition are accepted by default. Because this is the last term in the filter, packets that do not match this condition are discarded by default. Results Confirm the configuration of the stateless firewall filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall family inet { filter ospf_or_131 { term protocol_match { from { protocol ospf; } } term address_match { from { source-address { 10.108.0.0/16; } } }
95
} }
Applying the IPv4 Firewall Filter to a Logical Interface Step-by-Step Procedure To apply the stateless firewall filter to a logical interface:
1.
Enable configuration of a logical interface.

2.
Configure an IP address for the logical interface.

3.
Apply the IPv4 firewall filter to the logical interface.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input ospf_or_131
Results
Confirm the configuration of the interface by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces ge-0/0/1 { unit 0 { family inet { filter { input ospf_or_131; } address 10.1.2.3/30; } } }
If you are done configuring the device, enter commit from configuration mode.
Verification
To confirm that the configuration is working properly, enter the show firewall filter ospf_or_131 operational mode command. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Filter to Match on IPv6 Flags on page 89 Example: Configuring a Filter to Match on Port and Protocol Fields on page 91
96
Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List
This example shows how to configure a standard stateless firewall filter that limits certain TCP and Internet Control Message Protocol (ICMP) traffic destined for the Routing Engine:

Requirements
Overview
In this example, you create a stateless firewall filter that blocks all TCP connection attempts to port 179 from all requesters except the specified BGP peers. The source prefix list plist_bgp179 specifies the list of source prefixes that contain allowed BGP peers. The stateless firewall filter filter_bgp179 matches all packets from the source prefix list plist_bgp179 to the destination port number 179.
Configuration
Configure the Filter on page 98
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set policy-options prefix-list plist_bgp179 apply-path "protocols bgp group <*> neighbor <*>" set firewall family inet filter filter_bgp179 term 1 from source-address 0.0.0.0/0 set firewall family inet filter filter_bgp179 term 1 from source-prefix-list plist_bgp179 except set firewall family inet filter filter_bgp179 term 1 from destination-port bgp set firewall family inet filter filter_bgp179 term 1 then reject set firewall family inet filter filter_bgp179 term 2 then accept set interfaces lo0 unit 0 family inet filter input filter_bgp179 set interfaces lo0 unit 0 family inet address 127.0.0.1/32
97
Configure the Filter Step-by-Step Procedure To configure the filter:
Expand the prefix list bgp179 to include all prefixes pointed to by the BGP peer group defined by protocols bgp group <*> neighbor <*>.
[edit policy-options prefix-list plist_bgp179] user@host# set apply-path "protocols bgp group <*> neighbor <*>"
Define the filter term that rejects TCP connection attempts to port 179 from all requesters except the specified BGP peers.
[edit firewall family inet filter filter_bgp179] user@host# set term term1 from source-address 0.0.0.0/0 user@host# set term term1 from source-prefix-list bgp179 except user@host# set term term1 from destination-port bgp user@host# set term term1 then reject
Define the other filter term to accept all packets.

[edit firewall family inet filter filter_bgp179] user@host# set term term2 then accept
Apply the firewall filter to the loopback interface.

[edit interfaces lo0 unit 0 family inet] user@host# set filter input filter_bgp179 user@host# set address 127.0.0.1/32
Results
From configuration mode, confirm your configuration by entering the show firewall, show interfaces ,and show policy-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
user@host# show firewall family inet { filter filter_bgp179 { term 1 { from { source-address { 0.0.0.0/0; } source-prefix-list { plist_bgp179 except; } destination-port bgp; } then { reject; } } term 2 { then { accept; } } }
98
} user@host# show interfaces lo0 { unit 0 { family inet { filter { input filter_bgp179; } address 127.0.0.1/32; } } } user@host# show policy-options prefix-list plist_bgp179 { apply-path "protocols bgp group <*> neighbor <*>"; }
If you are done configuring the device, enter commit from configuration mode. Repeat the procedure, where appropriate, for every BGP-enabled device in the network, using the appropriate interface names and addresses for each BGP-enabled device.
Verification
Confirm that the configuration is working properly. Displaying the Firewall Filter Applied to the Loopback Interface Purpose Verify that the firewall filter filter_bgp179 is applied to the IPv4 input traffic at logical interface lo0.0. Use the show interfaces statistics operational mode command for logical interface lo0.0, and include the detail option. Under the Protocol inet section of the command output section, the Input Filters field displays the name of the stateless firewall filter applied to the logical interface in the input direction:
[edit] user@host> show interfaces statistics lo0.0 detail Logical interface lo0.0 (Index 321) (SNMP ifIndex 16) (Generation 130) Flags: SNMP-Traps Encapsulation: Unspecified Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol inet, MTU: Unlimited, Generation: 145, Route table: 0
Action
99
Flags: Sendbcast-pkt-to-re Input Filters: filter_bgp179 Addresses, Flags: Primary Destination: Unspecified, Local: 127.0.0.1, Broadcast: Unspecified, Generation: 138
Understanding How to Use Standard Firewall Filters on page 29 Firewall Filter Match Conditions Based on Address Fields on page 37 Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods on page 143 Example: Configuring a Filter to Accept Packets Based on IPv6 TCP Flags on page 149 prefix-list in the Junos OS Routing Policy Configuration Guide
Standard Firewall Filters That Count Packets

Example: Configuring a Filter to Count Accepted and Rejected Packets on page 100 Example: Configuring a Filter to Count and Discard IP Options Packets on page 103 Example: Configuring a Filter to Count IP Options Packets on page 106
Example: Configuring a Filter to Count Accepted and Rejected Packets

This example shows how to configure a firewall filter to count packets.

Requirements
Overview
In this example, you use a stateless firewall filter to reject all addresses except 192.168.5.0/24. Topology In the first term, the match condition address 192.168.5.0/24 except causes this address to be considered a mismatch, and this address is passed to the next term in the filter. The match condition address 0.0.0.0/0 matches all other packets, and these are counted, logged, and rejected. In the second term, all packets that passed though the first term (that is, packets whose address matches 192.168.5.0/24) are counted, logged, and accepted.
100
Configuration

set firewall family inet filter fire1 term 1 from address 192.168.5.0/24 except set firewall family inet filter fire1 term 1 from address 0.0.0.0/0 set firewall family inet filter fire1 term 1 then count reject_pref1_1 set firewall family inet filter fire1 term 1 then log set firewall family inet filter fire1 term 1 then reject set firewall family inet filter fire1 term 2 then count reject_pref1_2 set firewall family inet filter fire1 term 2 then log set firewall family inet filter fire1 term 2 then accept set interfaces ge-0/0/1 unit 0 family inet filter input fire1 set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter fire1:
1.
Create the stateless firewall filter fire1.

[edit] user@host# edit firewall family inet filter fire1
2.
Configure the first term to reject all addresses except those to or from the 192.168.5.0/24 prefix and then count, log, and reject all other packets.
[edit firewall family inet filter fire1] user@host# set term 1 from address 192.168.5.0/24 except user@host# set term 1 from address 0.0.0.0/0 user@host# set term 1 then count reject_pref1_1 user@host# set term 1 then log user@host# set term 1 then reject
3.
Configure the next term to count, log, and accept packets in the 192.168.5.0/24 prefix.
[edit firewall family inet filter fire1] user@host# set term 2 then count reject_pref1_2 user@host# set term 2 then log user@host# set term 2 then accept
101
1.
2.

3.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input fire1
1.
[edit] user@host# show 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; } } } }
102
2.
[edit] user@host# show interfaces ge-0/0/1 { unit 0 { family inet { filter { input fire1; } address 10.1.2.3/30; } } }
3.
Verification
To confirm that the configuration is working properly, enter the show firewall filter fire1 operational mode command. You can also display the log and individual counters separately by using the following forms of the command:

show firewall counter reject_pref1_1 show firewall counter reject_pref1_2 show firewall log
Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Filter to Count IP Options Packets on page 106 Example: Configuring a Filter to Count and Discard IP Options Packets on page 103
Example: Configuring a Filter to Count and Discard IP Options Packets

This example shows how to configure a standard stateless firewall to count packets.

Requirements
103
Because the filter term matches on any IP option value, the filter term can use the count nonterminating action without the discard terminating action or (alternatively) without requiring an interface on a 10-Gigabit Ethernet Modular Port Concentrator (MPC), 60-Gigabit Ethernet MPC, 60-Gigabit Queuing Ethernet MPC, or 60-Gigabit Ethernet Enhanced Queuing MPC on an MX Series router.
Overview
In this example, you use a standard stateless firewall filter to count and discard packets that include any IP option value but accept all other packets. The IP option header field is an optional field in IPv4 headers only. The ip-options and ip-options-except match conditions are supported for standard stateless firewall filters and service filters only.
Configuration

set firewall family inet filter block_ip_options term 10 from ip-options any set firewall family inet filter block_ip_options term 10 then count option_any set firewall family inet filter block_ip_options term 10 then discard set firewall family inet filter block_ip_options term 999 then accept set interfaces ge-0/0/1 unit 0 family inet filter input block_ip_options set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter:
1.
Create the stateless firewall filter block_ip_options.

[edit] user@host# edit firewall family inet filter block_ip_options
2.
Configure the first term to count and discard packets that include any IP options header fields.
[edit firewall family inet filter block_ip_options] user@host# set term 10 from ip-options any user@host# set term 10 then count option_any user@host# set term 10 then discard
104
3.
Configure the other term to accept all other packets.

[edit firewall family inet filter block_ip_options] user@host# set term 999 then accept
1.
2.

3.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input block_ip_options
1.
[edit] user@host# show firewall family inet { filter block_ip_options { term 10 { from { ip-options any; } then { count option_any; discard; } } term 999 { then accept; } } }
2.
[edit] user@host# show interfaces ge-0/0/1 {
105
unit 0 { family inet { filter { input block_ip_options; } address 10.1.2.3/30; } } }

3.
Verification
To confirm that the configuration is working properly, enter the show firewall filter block_ip_options operational mode command. To display the count of discarded packets separately, enter the show firewall count option_any form of the command. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Filter to Count Accepted and Rejected Packets on page 100 Example: Configuring a Filter to Count IP Options Packets on page 106
Example: Configuring a Filter to Count IP Options Packets

This example shows how use a stateless firewall filter to count individual IP options packets:

Requirements
This example uses an interface on a 10-Gigabit Ethernet Modular Port Concentrator (MPC), 60-Gigabit Ethernet MPC, 60-Gigabit Queuing Ethernet MPC, or 60-Gigabit Ethernet Enhanced Queuing MPC on an MX Series router. This interface enables you to apply an IPv4 firewall filter (standard or service filter) that can use the count, log, and syslog nonterminating actions on packets that match a specific ip-option value without having to also use the discard terminating action. No special configuration beyond device initialization is required before configuring this example.
Overview
In this example, you use a stateless firewall filter to count IP options packets but not block any traffic. Also, the filter logs packets that have loose or strict source routing.
106
The IP option header field is an optional field in IPv4 headers only. The ip-options and ip-options-except match conditions are supported for standard stateless firewall filters and service filters only.
Configuration

set firewall family inet filter ip_options_filter term match_strict_source from ip-options strict-source-route set firewall family inet filter ip_options_filter term match_strict_source then count strict_source_route set firewall family inet filter ip_options_filter term match_strict_source then log set firewall family inet filter ip_options_filter term match_strict_source then accept set firewall family inet filter ip_options_filter term match_loose_source from ip-options loose-source-route set firewall family inet filter ip_options_filter term match_loose_source then count loose_source_route set firewall family inet filter ip_options_filter term match_loose_source then log set firewall family inet filter ip_options_filter term match_loose_source then accept set firewall family inet filter ip_options_filter term match_record from ip-options record-route set firewall family inet filter ip_options_filter term match_record then count record_route set firewall family inet filter ip_options_filter term match_record then accept set firewall family inet filter ip_options_filter term match_timestamp from ip-options timestamp set firewall family inet filter ip_options_filter term match_timestamp then count timestamp set firewall family inet filter ip_options_filter term match_timestamp then accept set firewall family inet filter ip_options_filter term match_router_alert from ip-options router-alert set firewall family inet filter ip_options_filter term match_router_alert then count router_alert set firewall family inet filter ip_options_filter term match_router_alert then accept set firewall family inet filter ip_options_filter term match_all then accept set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30 set interfaces ge-0/0/1 unit 0 family inet filter input ip_options_filter
107
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter ip_option_filter:
1.
Create the stateless firewall filter ip_option_filter.

[edit] user@host# edit firewall family inet filter ip_options_filter
2.
Configure the first term to count, log, and accept packets with the strict_source_route IP optional header field.
[edit firewall family inet filter ip_option_filter] user@host# set term match_strict_source from ip-options strict_source_route user@host# set term match_strict_source then count strict_source_route user@host# set term match_strict_source then log user@host# set term match_strict_source then accept
3.
Configure the next term to count, log, and accept packets with the loose-source-route IP optional header field.
[edit firewall family inet filter ip_option_filter] user@host# set term match_loose_source from ip-options loose-source-route user@host# set term match_loose_source then count loose_source_route user@host# set term match_loose_source then log user@host# set term match_loose_source then accept
4.
Configure the next term to count and accept packets with the record-route IP optional header field.
[edit firewall family inet filter ip_option_filter] user@host# set term match_record from ip-options record-route user@host# set term match_record then count record_route user@host# set term match_record then accept
5.
Configure the next term to count and accept packets with the timestamp IP optional header field.
[edit firewall family inet filter ip_option_filter] user@host# set term match_timestamp from ip-options timestamp user@host# set term match_timestamp then count timestamp user@host# set term match_timestamp then accept
6.
Configure the next term to count and accept packets with the router-alert IP optional header field.
[edit firewall family inet filter ip_option_filter] user@host# set term match_router_alert from ip-options router-alert user@host# set term match_router_alert then count router_alert user@host# set term match_router_alert then accept
7.
Create the last term to accept any packet without incrementing any counters.
[edit firewall family inet filter ip_option_filter] user@host# set term match_all then accept
108
1.
2.

3.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input ip_options_filter
1.
[edit] user@host# show firewall family inet { filter ip_options_filter { term match_strict_source { 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;
109
accept; } } term match_timestamp { from { ip-options timestamp; } then { count timestamp; accept; } } term match_router_alert { from { ip-options router-alert; } then { count router_alert; accept; } } term match_all { then accept; } } }
2.
[edit] user@host# show interfaces ge-0/0/1 { unit 0 { family inet { filter { input ip_option_filter; } address 10.1.2.3/30; } } }
3.
110
Verification
To confirm that the configuration is working properly, enter the show firewall filter ip_option_filter operational mode command. You can also display the log and individual counters separately by using the following forms of the command:

show firewall counter strict_source_route show firewall counter loose_source_route show firewall counter record_route show firewall counter timestamp show firewall counter router_alert show firewall log
Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Filter to Count Accepted and Rejected Packets on page 100 Example: Configuring a Filter to Count and Discard IP Options Packets on page 103
Standard Firewall Filters That Act on Packets

Example: Configuring a Filter to Set the DSCP Bit to Zero on page 111 Example: Configuring a Filter to Count and Sample Accepted Packets on page 114
Example: Configuring a Filter to Set the DSCP Bit to Zero

This example shows how to configure a standard stateless firewall filter based on the Differentiated Services code point (DSCP).

Requirements
Overview
In this example, you use a stateless firewall filter to match packets on DSCP bit patterns. If the DSCP is 2, the packet is classified to the best-effort forwarding class, and the DSCP is set to 0. If the DSCP is 3, the packet is classified to the best-effort forwarding class.
111
Configuration

set firewall filter filter1 term 1 from dscp 2 set firewall filter filter1 term 1 then forwarding-class best-effort set firewall filter filter1 term 1 then dscp 0 set firewall filter filter1 term 2 from dscp 3 set firewall filter filter1 term 2 then forwarding-class best-effort set interfaces so-0/1/0 unit 0 family inet filter input filter1
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter filter1:
1.

[edit] user@host# edit firewall filter filter1
2.
Configure the first term to match a packet with a DSCP of 2, change the DSCP to 0, and classify the packet to the best-effort forwarding class.
[edit firewall filter filter1] user@host# set term 1 from dscp 2 user@host# set term 1 then forwarding-class best-effort user@host# set term 1 then dscp 0
3.
Configure the other term to match a packet with a DSCP of 3 and classify the packet to the best-effort forwarding class.
[edit firewall filter filter1] user@host# set term 2 from dscp 3 user@host# set term 2 then forwarding-class best-effort
Apply the Stateless Firewall Filter to a Logical Interface Step-by-Step Procedure To apply the stateless firewall filter to the logical interface corresponding to the VPN routing and forwarding (VRF) instance:
1.
[edit] user@host# edit interfaces so-0/1/0 unit 0 family inet
112
2.

[ input filter1] user@host# set filter input filter1
1.
[edit] user@host# show firewall filter filter1 { term term1 { from { dscp 2; } then { forwarding-class best-effort; dscp 0; } } term term2 { from { dscp 3; } then { forwarding-class best-effort; } } }
2.
[edit] user@host# show interfaces so-0/1/0 { unit 0 { family inet { filter input filter1; } } }
3.
113
Verification
To confirm that the configuration is working properly, enter the following operational mode commands:
show class-of-serviceDisplays the entire class-of-service (CoS) configuration, including
system-chosen defaults.
show class-of-service classifier type dscpDisplays only the classifiers of the DSCP for
IPv4 type. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Filter to Count and Sample Accepted Packets on page 114
Example: Configuring a Filter to Count and Sample Accepted Packets

This example shows how to configure a standard stateless firewall filter to count and sample accepted packets.

Requirements
No special configuration beyond device initialization is required before configuring this example. Before you begin, configure traffic sampling by including the sampling statement at the [edit forwarding-options] hierarchy level.
Overview
In this example, you use a standard stateless firewall filter to count and sample all packets received on a logical interface.
NOTE: When you enable reverse path forwarding (RPF) on an interface with an input filter for firewall log and count, the input firewall filter does not log the packets rejected by RPF, although the rejected packets are counted. To log the rejected packets, use an RPF check fail filter.
Configuration
114
To configure this example, perform the following tasks:

set firewall family inet filter sam term all then count count_sam set firewall family inet filter sam term all then sample set interfaces at-2/0/0 unit 301 family inet address 10.1.2.3/30 set interfaces at-2/0/0 unit 301 family inet filter input sam
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter sam:
1.
Create the stateless firewall filter sam.

[edit] user@host# edit firewall family inet filter sam
2.
Configure the term to count and sample all packets.

[edit firewall family inet filter sam] user@host# set term all then count count_sam user@host# set term all then sample
1.
2.

3.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input sam
NOTE: The Junos OS does not sample packets originating from the router. If you configure a filter and apply it to the output side of an interface, then only the transit packets going through that interface are sampled. Packets that are sent from the Routing Engine to the Packet Forwarding Engine are not sampled.
115
1.
[edit] user@host# show firewall family inet { filter sam { term all { then { count count_sam; sample; # default action is accept } } } }
2.
[edit] user@host# show interfaces interfaces { at-2/0/0 { unit 301 { family inet { filter { input sam; } address 10.1.2.3/30; } } } }
3.
Verification
Confirm that the configuration is working properly.

Displaying the Packet Counter on page 116 Displaying the Firewall Filter Log Output on page 117 Displaying the Sampling Output on page 117
Displaying the Packet Counter Purpose Verify that the firewall filter is evaluating packets.
116
Action
user@host> show firewall filter sam Filter: Counters: Name Bytes sam sam-1 98
Packets 8028
Displaying the Firewall Filter Log Output Purpose Action Display the packet header information for all packets evaluated by the firewall filter.
user@host> show firewall log Time Filter A Interface 23:09:09 A at-2/0/0.301 23:09:07 A at-2/0/0.301 23:09:07 A at-2/0/0.301 23:02:27 A at-2/0/0.301 23:02:25 A at-2/0/0.301 23:01:22 A at-2/0/0.301 23:01:21 A at-2/0/0.301 23:01:20 A at-2/0/0.301 23:01:19 A at-2/0/0.301
Pro TCP TCP ICM TCP TCP ICM ICM ICM ICM
Source address 10.2.0.25 10.2.0.25 10.2.0.25 10.2.0.25 10.2.0.25 10.2.2.101 10.2.2.101 10.2.2.101 10.2.2.101
Destination address 10.211.211.1:80 10.211.211.1:56 10.211.211.1:49552 10.211.211.1:56 10.211.211.1:80 10.211.211.1:23251 10.211.211.1:16557 10.211.211.1:29471 10.211.211.1:26873
Meaning
This output file contains the following fields:

TimeTime at which the packet was received (not shown in the default). FilterName of a filter that has been configured with the filter statement at the [edit firewall] hierarchy level. A hyphen (-) or the abbreviation pfe indicates that the
packet was handled by the Packet Forwarding Engine. A space (no hyphen) indicates that the packet was handled by the Routing Engine.
AFilter action:

AAccept (or next term) DDiscard RReject
InterfaceInterface on which the filter is configured.
NOTE: We strongly recommend that you always explicitly configure an action in the then statement.
ProPackets protocol name or number. Source addressSource IP address in the packet. Destination addressDestination IP address in the packet.
Displaying the Sampling Output Purpose Verify that the sampling output contains appropriate data.
117
Action
wtmp.0.gz Size: 15017, Last changed: Dec 19 13:15:54 wtmp.1.gz Size: 493, Last changed: Nov 19 13:47:29 wtmp.2.gz Size: 57, Last changed: Oct 20 15:24:34 | Pipe through a command user@host> show log /var/tmp/sam # Apr 7 15:48:50 Time Dest Src Dest Src Proto addr addr port port Apr 7 15:48:54 192.168.9.194 192.168.9.195 0 0 1 Apr 7 15:48:55 192.168.9.194 192.168.9.195 0 0 1 Apr 7 15:48:56 192.168.9.194 192.168.9.195 0 0 1
TOS Pkt Intf IP TCP len num frag flags 0x0 84 8 0x0 0x0 0x0 84 8 0x0 0x0 0x0 84 8 0x0 0x0
Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Filter to Set the DSCP Bit to Zero on page 111
Standard Firewall Filters for Trusted Sources
Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118 Example: Configuring a Filter to Block Telnet and SSH Access on page 123 Example: Configuring a Filter to Block TFTP Access on page 129 Example: Configuring a Filter to Accept OSPF Packets from a Prefix on page 132 Example: Configuring a Filter to Accept DHCP Packets Based on Address on page 134 Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers on page 137
Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources
This example shows how to create a stateless firewall filter that protects the Routing Engine from traffic originating from untrusted sources.

Requirements
No special configuration beyond device initialization is required before configuring stateless firewall filters.
118
Overview
In this example, you create a stateless firewall filter called protect-RE that discards all traffic destined for the Routing Engine except SSH and BGP protocol packets from specified trusted sources. This example includes the following firewall filter terms:
ssh-termAccepts TCP packets with a source address of 192.168.122.0/24 and a
destination port that specifies SSH.
bgp-termAccepts TCP packets with a source address of 10.2.1.0/24 and a destination
port that specifies BGP.
discard-rest-termFor all packets that are not accepted by ssh-term or bgp-term,
creates a firewall filter log and system logging records, then discards all packets.
NOTE: You can move terms within the firewall filter using the insert command. See insert in the Junos OS CLI User Guide.
Configuration
CLI Quick Configuration To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet filter protect-RE term ssh-term from source-address 192.168.122.0/24 set firewall family inet filter protect-RE term ssh-term from protocol tcp set firewall family inet filter protect-RE term ssh-term from destination-port ssh set firewall family inet filter protect-RE term ssh-term then accept set firewall family inet filter protect-RE term bgp-term from source-address 10.2.1.0/24 set firewall family inet filter protect-RE term bgp-term from protocol tcp set firewall family inet filter protect-RE term bgp-term from destination-port bgp set firewall family inet filter protect-RE term bgp-term then accept set firewall family inet filter protect-RE term discard-rest-term then log set firewall family inet filter protect-RE term discard-rest-term then syslog set firewall family inet filter protect-RE term discard-rest-term then discard set interfaces lo0 unit 0 family inet filter input protect-RE
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode on page 15 in the Junos OS CLI User Guide. To configure the stateless firewall filter:
1.

[edit] user@host# edit firewall family inet filter protect-RE
2.
Create the first filter term.

[edit firewall family inet filter protect-RE]
119
user@host# edit term ssh-term

3.
Define the protocol, destination port, and source address match conditions for the term.
[edit firewall family inet filter protect-RE term ssh-term] user@host# set from protocol tcp destination-port ssh source-address 192.168.122.0/24
4.

[edit firewall family inet filter protect-RE term ssh-term] user@host# set then accept
5.
Create the second filter term.

[edit firewall family inet filter protect-RE] user@host# edit term bgp-term
6.
Define the protocol, destination port, and source address match conditions for the term.
[edit firewall family inet filter protect-RE term bgp-term] user@host# set from protocol tcp destination-port bgp source-address 10.2.1.0/24
7.
Define the action for the term.

[edit firewall family inet filter protect-RE term bgp-term] user@host# set then accept
8.
Create the third filter term.

[edit firewall family inet filter protect-RE] user@host# edit term discard-rest-term
9.

[edit firewall family inet filter protect-RE term discard-rest] user@host# set then log syslog discard
10.
Apply the filter to the input side of the Routing Engine interface.
[edit] user@host# set interfaces lo0 unit 0 family inet filter input protect-RE
Results
Confirm your configuration by entering the show firewall command and the show interfaces lo0 command from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
user@host# show firewall family inet { filter protect-RE { term ssh-term { from { source-address { 192.168.122.0/24; } protocol tcp; destination-port ssh;
120
} then accept; } term bgp-term { from { source-address { 10.2.1.0/24; } protocol tcp; destination-port bgp; } then accept; } term discard-rest-term { then { log; syslog; discard; } } } } user@host# show interfaces lo0 unit 0 { family inet { filter { input protect-RE; } address 127.0.0.1/32; } }
Verification
To confirm that the configuration is working properly, perform these tasks:

Displaying Stateless Firewall Filter Configurations on page 121 Verifying a Services, Protocols, and Trusted Sources Firewall Filter on page 122 Displaying Stateless Firewall Filter Logs on page 122
Displaying Stateless Firewall Filter Configurations Purpose Action Verify the configuration of the firewall filter. From configuration mode, enter the show firewall command and the show interfaces lo0 command.
121
Meaning
Verify that the output shows the intended configuration of the firewall filter. In addition, verify that the terms are listed in the order in which you want the packets to be tested. You can move terms within a firewall filter by using the insert CLI command. Verifying a Services, Protocols, and Trusted Sources Firewall Filter
Purpose Action
Verify that the actions of the firewall filter terms are taken. Send packets to the device that match the terms. In addition, verify that the filter actions are not taken for packets that do not match.
Use the ssh host-name command from a host at an IP address that matches 192.168.122.0/24 to verify that you can log in to the device using only SSH from a host with this address prefix. Use the show route summary command to verify that the routing table on the device does not contain any entries with a protocol other than Direct, Local, BGP, or Static.
Sample Output
% ssh 192.168.249.71 %ssh host user@host's password: --- JUNOS 6.4-20040518.0 (JSERIES) #0: 2004-05-18 09:27:50 UTC user@host> user@host> show route summary Router ID: 192.168.249.71 inet.0: 34 destinations, 34 routes (33 active, 0 holddown, 1 hidden) Direct: 10 routes, 9 active Local: 9 routes, 9 active BGP: 10 routes, 10 active Static: 5 routes, 5 active ...
Meaning
Verify the following information:

You can successfully log in to the device using SSH. The show route summary command does not display a protocol other than Direct, Local, BGP, or Static.
Displaying Stateless Firewall Filter Logs Purpose Verify that packets are being logged. If you included the log or syslog action in a term, verify that packets matching the term are recorded in the firewall log or your system logging facility. From operational mode, enter the show firewall log command.
Action
Sample Output
user@host> show firewall log
122
Log : Time 15:11:02 15:11:01 15:11:01 15:11:01 ...
Filter pfe pfe pfe pfe
Action D D D D
Interface ge-0/0/0.0 ge-0/0/0.0 ge-0/0/0.0 ge-0/0/0.0
Protocol TCP TCP TCP TCP
Src Addr 172.17.28.19 172.17.28.19 172.17.28.19 172.17.28.19
Dest Addr 192.168.70.71 192.168.70.71 192.168.70.71 192.168.70.71
Meaning
Each record of the output contains information about the logged packet. Verify the following information:

Under Time, the time of day the packet was filtered is shown. The Filter output is always pfe. Under Action, the configured action of the term matches the action taken on the packetA (accept), D (discard), R (reject). Under Interface, the inbound (ingress) interface on which the packet arrived is appropriate for the filter. Under Protocol, the protocol in the IP header of the packet is appropriate for the filter. Under Src Addr, the source address in the IP header of the packet is appropriate for the filter. Under Dest Addr, the destination address in the IP header of the packet is appropriate for the filter.
Junos OS Feature Support Reference for SRX Series and J Series Devices
show route summary in the Junos OS Routing Protocols and Policies Command Reference show firewall in the Junos OS Routing Protocols and Policies Command Reference show firewall log in the Junos OS Routing Protocols and Policies Command Reference show interfaces (Loopback) in the Junos OS Interfaces Command Reference
Example: Configuring a Filter to Block Telnet and SSH Access

Requirements
You must have access to a remote host that has network connectivity with this router.
123
Overview
In this example, you create an IPv4 stateless firewall filter that logs and rejects Telnet or SSH access packets unless the packet is destined for or originates from the 192.168.1.0/24 subnet.
To match packets destined for or originating from the address 192.168.1.0/24 subnet, you use the address 192.168.1.0/24 IPv4 match condition. To match packets destined for or originating from a TCP port, Telnet port, or SSH port, you use the protocol tcp, port telnet, and telnet ssh IPv4 match conditions.
Configuration

Configure the Stateless Firewall Filter on page 124 Apply the Firewall Filter to the Loopback Interface on page 125 Confirm and Commit Your Candidate Configuration on page 125
set firewall family inet filter local_acl term terminal_access from address 192.168.1.0/24 set firewall family inet filter local_acl term terminal_access from protocol tcp set firewall family inet filter local_acl term terminal_access from port ssh set firewall family inet filter local_acl term terminal_access from port telnet set firewall family inet filter local_acl term terminal_access then accept set firewall family inet filter local_acl term terminal_access_denied from protocol tcp set firewall family inet filter local_acl term terminal_access_denied from port ssh set firewall family inet filter local_acl term terminal_access_denied from port telnet set firewall family inet filter local_acl term terminal_access_denied then log set firewall family inet filter local_acl term terminal_access_denied then reject set firewall family inet filter local_acl term default-term then accept set interfaces lo0 unit 0 family inet filter input local_acl set interfaces lo0 unit 0 family inet address 127.0.0.1/32
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter that selectively blocks Telnet and SSH access:
1.
Create the stateless firewall filter local_acl.

[edit] user@myhost# edit firewall family inet filter local_acl
2.
Define the filter term terminal_access.

[edit firewall family inet filter local_acl] user@myhost# set term terminal_access from address 192.168.1.0/24
124
user@myhost# set term terminal_access from protocol tcp user@myhost# set term terminal_access from port ssh user@myhost# set term terminal_access from port telnet user@myhost# set term terminal_access then accept
3.
Define the filter term terminal_access_denied.

[edit firewall family inet filter local_acl] user@myhost# set term terminal_access_denied from protocol tcp user@myhost# set term terminal_access_denied from port ssh user@myhost# set term terminal_access_denied from port telnet user@myhost# set term terminal_access_denied then log user@myhost# set term terminal_access_denied then reject user@myhost# set term default-term then accept
Apply the Firewall Filter to the Loopback Interface Step-by-Step Procedure
To apply the firewall filter to the loopback interface:

[edit] user@myhost# set interfaces lo0 unit 0 family inet filter input local_acl user@myhost# set interfaces lo0 unit 0 family inet address 127.0.0.1/32
1.
[edit] user@myhost# show firewall family inet { filter local_acl { term terminal_access { from { address { 192.168.1.0/24; } protocol tcp; port [ssh telnet]; } then accept; } term terminal_access_denied { from { protocol tcp; port [ssh telnet]; } then { log; reject; } } term default-term {
125
then accept; } } }
2.
[edit] user@myhost# show interfaces lo0 { unit 0 { family inet { filter { input local_acl; } address 127.0.0.1/32; } } }
3.
[edit] user@myhost# commit
Verification

Verifying Accepted Packets on page 126 Verifying Logged and Rejected Packets on page 127
Verifying Accepted Packets Purpose Verify that the actions of the firewall filter terms are taken.
126
Action
1.
Clear the firewall log on your router.

user@myhost> clear firewall log
2. From a host at an IP address within the 192.168.1.0/24 subnet, use the ssh hostname
command to verify that you can log in to the device using only SSH. This packet should be accepted, and the packet header information for this packet should not be logged in the firewall filter log buffer in the Packet Forwarding Engine.
user@host-A> ssh myhost user@myhostss password: --- JUNOS 11.1-20101102.0 built 2010-11-02 04:48:46 UTC % cli user@myhost> 3. From a host at an IP address within the 192.168.1.0/24 subnet, use the telnet hostname
command to verify that you can log in to your router using only Telnet. This packet should be accepted, and the packet header information for this packet should not be logged in the firewall filter log buffer in the Packet Forwarding Engine.
user@host-A> telnet myhost Trying 192.168.249.71... Connected to myhost-fxp0.acme.net. Escape character is '^]'. host (ttyp0) login: user Password: --- JUNOS 11.1-20101102.0 built 2010-11-02 04:48:46 UTC % cli user@myhost>
4. Use the show firewall log command to verify that the routing table on the device does
not contain any entries with a source address in the 192.168.1.0/24 subnet.
user@myhost> show firewall log
Verifying Logged and Rejected Packets Purpose Verify that the actions of the firewall filter terms are taken.
127
Action
1.

2. From a host at an IP address outside of the 192.168.1.0/24 subnet, use the ssh hostname
command to verify that you cannot log in to the device using only SSH. This packet should be rejected, and the packet header information for this packet should be logged in the firewall filter log buffer in the Packet Forwarding Engine.
user@host-B ssh myhost ssh: connect to host sugar port 22: Connection refused --- JUNOS 11.1-20101102.0 built 2010-11-02 04:48:46 UTC % 3. From a host at an IP address outside of the 192.168.1.0/24 subnet, use the telnet
hostname command to verify that you can log in to the device using only Telnet. This
packet should be rejected, and the packet header information for this packet should be logged in the firewall filter log buffer in the PFE.
user@host-B> telnet myhost Trying 192.168.249.71... telnet: connect to address 192.168.187.3: Connection refused telnet: Unable to connect to remote host % 4. Use the show firewall log command to verify that the routing table on the device does
not contain any entries with a source address in the 192.168.1.0/24 subnet.
user@myhost> show firewall log
Time 18:41:25 18:41:25 18:41:25 ... 18:43:06 18:43:06 18:43:06 ...
Filter local_acl local_acl local_acl
Action R R R
Interface fxp0.0 fxp0.0 fxp0.0 fxp0.0 fxp0.0 fxp0.0
Protocol Src Addr TCP 192.168.187.5 TCP 192.168.187.5 TCP 192.168.187.5 TCP TCP TCP 192.168.187.5 192.168.187.5 192.168.187.5
Dest Addr 192.168.187.1 192.168.187.1 192.168.187.1 192.168.187.1 192.168.187.1 192.168.187.1
local_acl R local_acl R local_acl R
Logging of Packet Headers Evaluated by a Firewall Filter Term on page 221 Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118 Example: Configuring a Filter to Block TFTP Access on page 129 Example: Configuring a Filter to Accept OSPF Packets from a Prefix on page 132 Example: Configuring a Filter to Accept DHCP Packets Based on Address on page 134
128
Example: Configuring a Filter to Block TFTP Access

Requirements
Overview
By default, to decrease vulnerability to denial-of-service (DoS) attacks, the Junos OS filters and discards Dynamic Host Configuration Protocol (DHCP) or Bootstrap Protocol (BOOTP) packets that have a source address of 0.0.0.0 and a destination address of 255.255.255.255. This default filter is known as a unicast RPF check. However, some vendors equipment automatically accepts these packets. To interoperate with other vendors' equipment, you can configure a filter that checks for both of these addresses and overrides the default RPF-check filter by accepting these packets. In this example, you block Trivial File Transfer Protocol (TFTP) access, logging any attempts to establish TFTP connections.
Configuration

set firewall family inet filter tftp_access_control term one from protocol udp set firewall family inet filter tftp_access_control term one from port tftp set firewall family inet filter tftp_access_control term one then log set firewall family inet filter tftp_access_control term one then discard set interfaces lo0 unit 0 family inet filter input tftp_access_control set interfaces lo0 unit 0 family inet address 127.0.0.1/32
129
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter that selectively blocks TFTP access:
1.
Create the stateless firewall filter tftp_access_control.

[edit] user@host# edit firewall family inet filter tftp_access_control
2.
Specify a match on packets received on UDP port 69.

[edit firewall family inet filter tftp_access_control] user@host# set term one from protocol udp user@host# set term one from port tftp
3.
Specify that matched packets be logged to the buffer on the Packet Forwarding Engine and then discarded.
[edit firewall family inet filter tftp_access_control] user@host# set term one then log user@host# set term one then discard
Apply the Firewall Filter to the Loopback Interface Step-by-Step Procedure To apply the firewall filter to the loopback interface:
[edit] user@host# set interfaces lo0 unit 0 family inet filter input tftp_access_control user@host# set interfaces lo0 unit 0 family inet address 127.0.0.1/32
1.
[edit] user@host# show firewall family inet { filter tftp_access_control { term one { from { protocol udp; port tftp; } then { log; discard; } } } }
130
2.
[edit] user@host# show interfaces lo0 { unit 0 { family inet { filter { input tftp_access_control; } address 127.0.0.1/32; } } }
3.
Verification
Confirm that the configuration is operating properly:
Verifying Logged and Discarded Packets on page 131
Verifying Logged and Discarded Packets Purpose Action Verify that the actions of the firewall filter terms are taken. To
1.

2. From another host, send a packet to UDP port 69 on this router.
Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118 Example: Configuring a Filter to Block Telnet and SSH Access on page 123 Example: Configuring a Filter to Accept OSPF Packets from a Prefix on page 132 Example: Configuring a Filter to Accept DHCP Packets Based on Address on page 134
131
Example: Configuring a Filter to Accept OSPF Packets from a Prefix

This example shows how to configure a standard stateless firewall filter to accept packets from a trusted source.

Requirements
Overview
In this example, you create a filter that accepts only OSPF packets from an address in the prefix 10.108.0.0/16, discarding all other packets with an administratively-prohibited ICMP message
Configuration

set firewall family inet filter ospf_filter term term1 from source-address 10.108.0.0/16 set firewall family inet filter ospf_filter term term1 from protocol ospf set firewall family inet filter ospf_filter term term1 then accept set firewall family inet filter ospf_filter term default-term then reject administratively-prohibited set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30 set interfaces ge-0/0/1 unit 0 family inet filter input ospf_filter
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter ospf_filter:
1.
Create the filter.

[edit] user@host# edit firewall family inet filter ospf_filter
132
2.
Configure the term that accepts packets.

[edit firewall family inet filter ospf_filter] user@host# set term term1 from source-address 10.108.0.0/16 user@host# set term term1 from protocol ospf user@host# set term term1 then accept
3.
Configure the term that rejects all other packets.

[edit firewall family inet filter ospf_filter] user@host# set term default_term then reject administratively-prohibited
1.
Configure the interface.

2.
Configure the logical interface IP address.

3.
Apply the filter to the input.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input ospf_filter
1.
[edit] user@host# show firewall family inet { filter ospf_filter { term term1 { from { source-address { 10.108.0.0/16; } protocol ospf; } then { accept; } } term default_term { then { reject administratively-prohibited; # default reject action }
133
} } }
2.
[edit] user@host# show interfaces lo0 { unit 0 { family inet { filter { input ospf_filter; } address 10.1.2.3/30; } } }
3.
Verification
To confirm that the configuration is working properly, enter the show firewall filter ospf_filter operational mode command. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118 Example: Configuring a Filter to Block Telnet and SSH Access on page 123 Example: Configuring a Filter to Block TFTP Access on page 129 Example: Configuring a Filter to Accept DHCP Packets Based on Address on page 134
Example: Configuring a Filter to Accept DHCP Packets Based on Address


Requirements
This example is supported on MX Series routers only.
134
Overview
In this example, you create a filter (rpf_dhcp) that accepts DHCP packets with a source address of 0.0.0.0 and a destination address of 255.255.255.255.
Configuration

set firewall family inet filter rpf_dhcp term dhcp_term from source-address 0.0.0.0/32 set firewall family inet filter rpf_dhcp term dhcp_term from destination-address 255.255.255.255/32 set firewall family inet filter rpf_dhcp term dhcp_term then accept set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30 set interfaces ge-0/0/1 unit 0 family inet filter input sam
1.
Create the stateless firewall filter rpf_dhcp.

[edit] user@host# edit firewall family inet filter rpf_dhcp
2.
Configure the term to match packets with a source address of 0.0.0.0 and a destination address of 255.255.255.255.
[edit firewall family inet filter rpf_dhcp] user@host# set term dhcp_term from source-address 0.0.0.0/32 user@host# set term dhcp_term from destination-address 255.255.255.255/32
3.
Configure the term to accept packets that match the specified conditions.
[edit firewall family inet filter rpf_dhcp] set term dhcp_term then accept
Apply the Firewall Filter to the Loopback Interface Step-by-Step Procedure To apply the filter to the input at the loopback interface:
1.
Apply the rpf_dhcp filter if packets are not arriving on an expected path.
[edit] user@host# set interfaces lo0 unit 0 family inet rpf-check fail-filter rpf_dhcp
135
2.
Configure an address for the loopback interface.

[edit] user@host# set interfaces lo0 unit 0 family inet address 127.0.0.1/32
1.
[edit] user@host# show firewall family inet { filter rpf_dhcp { term dhcp_term { from { source-address { 0.0.0.0/32; } destination-address { 255.255.255.255/32; } } then accept; } } }
2.
[edit] user@host# show interfaces lo0 { unit 0 { family inet { filter { rpf-check { fail-filter rpf_dhcp; mode loose; } } address 127.0.0.1/32; } } }
3.
When you are done configuring the device, commit your candidate configuration.
136
Verification
To confirm that the configuration is working properly, enter the show firewall operational mode command. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118 Example: Configuring a Filter to Block Telnet and SSH Access on page 123 Example: Configuring a Filter to Block TFTP Access on page 129 Example: Configuring a Filter to Accept OSPF Packets from a Prefix on page 132
Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers
This example shows how to configure a standard stateless firewall filter that limits certain TCP and Internet Control Message Protocol (ICMP) traffic destined for the Routing Engine.

Requirements
No special configuration beyond device initialization is required before you configure this example.
Overview
In this example, you create a stateless firewall filter that blocks all TCP connection attempts to port 179 from all requesters except the specified BGP peers. The stateless firewall filter filter_bgp179 matches all packets from the directly connected interfaces on Device A and Device B to the destination port number 179. Figure 2 on page 138 shows the topology used in this example. Device C attempts to make a TCP connection to Device E. Device E blocks the connection attempt. This example shows the configuration on Device C and Device E.
137
Figure 2: Typical Network with BGP Peer Sessions
10.2
A AS 22
AS 17
10.1 10.5 10.9
10.6
Configuration
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode on page 15. To configure this example, perform the following tasks:
Configuring Device E on page 139
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set interfaces ge-1/2/0 unit 10 description to-E set interfaces ge-1/2/0 unit 10 family inet address 10.10.10.10/30 set protocols bgp group external-peers type external set protocols bgp group external-peers peer-as 17 set protocols bgp group external-peers neighbor 10.10.10.9 set routing-options autonomous-system 22 set interfaces ge-1/2/0 unit 0 description to-A set interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/30 set interfaces ge-1/2/1 unit 5 description to-B set interfaces ge-1/2/1 unit 5 family inet address 10.10.10.5/30 set interfaces ge-1/0/0 unit 9 description to-C set interfaces ge-1/0/0 unit 9 family inet address 10.10.10.9/30 set interfaces lo0 unit 2 family inet filter input filter_bgp179 set interfaces lo0 unit 2 family inet address 192.168.0.1/32 set protocols bgp group external-peers type external set protocols bgp group external-peers peer-as 22 set protocols bgp group external-peers neighbor 10.10.10.2 set protocols bgp group external-peers neighbor 10.10.10.6 set protocols bgp group external-peers neighbor 10.10.10.10 set routing-options autonomous-system 17 set firewall family inet filter filter_bgp179 term 1 from source-address 10.10.10.2/32 set firewall family inet filter filter_bgp179 term 1 from source-address 10.10.10.6/32 set firewall family inet filter filter_bgp179 term 1 from destination-port bgp set firewall family inet filter filter_bgp179 term 1 then accept set firewall family inet filter filter_bgp179 term 2 then reject
Device C
Device E
138
g040870
10.10
Configuring Device E Step-by-Step Procedure The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode on page 15 in the Junos OS CLI User Guide. To configure the stateless firewall filter that blocks all TCP connection attempts to port 179 from all requestors except specified BGP peers:
1.
Configure the interfaces.

user@E# set interfaces ge-1/2/0 unit 0 description to-A user@E# set interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/30 user@E# set interfaces ge-1/2/1 unit 5 description to-B user@E# set interfaces ge-1/2/1 unit 5 family inet address 10.10.10.5/30 user@E# set interfaces ge-1/0/0 unit 9 description to-C user@E# set interfaces ge-1/0/0 unit 9 family inet address 10.10.10.9/30
2.
Configure BGP.
[edit protocols bgp group external-peers] user@E# set type external user@E# set peer-as 22 user@E# set neighbor 10.10.10.2 user@E# set neighbor 10.10.10.6 user@E# set neighbor 10.10.10.10
3.
Configure the autonomous system (AS) number.

[edit routing-options] user@E# set autonomous-system 17
4.
Define the filter term that accepts TCP connection attempts to port 179 from the specified BGP peers.
[edit firewall family inet filter filter_bgp179] user@E# set term 1 from source-address 10.10.10.2/32 user@E# set term 1 from source-address 10.10.10.6/32 user@E# set term 1 from destination-port bgp user@E# set term 1 then accept
5.
Define the other filter term to reject packets from other sources.
[edit firewall family inet filter filter_bgp179] user@E# set term 2 then reject
6.
Apply the firewall filter to the loopback interface.

[edit interfaces lo0 unit 2 family inet] user@E# set filter input filter_bgp179 user@E# set address 192.168.0.1/32
Results
From configuration mode, confirm your configuration by entering the show firewall, show interfaces, show protocols, and show routing-options commands. If the output does not
139
display the intended configuration, repeat the instructions in this example to correct the configuration.
user@E# show firewall family inet { filter filter_bgp179 { term 1 { from { source-address { 10.10.10.2/32; 10.10.10.6/32; } destination-port bgp; } then accept; } term 2 { then { reject; } } } } user@E# show interfaces lo0 { unit 2 { family inet { filter { input filter_bgp179; } address 192.168.0.1/32; } } } ge-1/2/0 { unit 0 { description to-A; family inet { address 10.10.10.1/30; } } } ge-1/2/1 { unit 5 { description to-B; family inet { address 10.10.10.5/30; } } } ge-1/0/0 { unit 9 { description to-C; family inet { address 10.10.10.9/30;
140
} } } user@E# show protocols bgp { group external-peers { type external; peer-as 22; neighbor 10.10.10.2; neighbor 10.10.10.6; neighbor 10.10.10.10; } } ospf { area 0.0.0.0 { interface fe-1/2/0.1; interface 10.255.14.179; } } user@R0# show routing-options autonomous-system 17;
If you are done configuring the device, enter commit from configuration mode. Repeat the procedure, where appropriate, for every BGP-enabled device in the network, using the appropriate interface names and addresses for each BGP-enabled device.
Verification

Verifying That the Filter Is Configured on page 141 Verifying the TCP Connections on page 141 Monitoring Traffic on the Interfaces on page 142
Verifying That the Filter Is Configured Purpose Action Make sure that the filter is listed in output of the show firewall filter command.
user@E> show firewall filter filter_bgp179 Filter: filter_bgp179
Verifying the TCP Connections Purpose Action Verify the TCP connections. From operational mode, run the show system connections extensive command on Device C and Device E. The output on Device C shows the attempt to establish a TCP connection. The output on Device E shows that connections are established with Device A and Device B only.
user@C> show system connections extensive | match 10.10.10
141
tcp4
10.10.10.9.51872
10.10.10.10.179
SYN_SENT
user@E> show system connections extensive | match 10.10.10 tcp4 tcp4 tcp4 tcp4 0 0 0 0 0 0 0 0 10.10.10.5.179 10.10.10.6.62096 10.10.10.1.179 10.10.10.2.61506 10.10.10.6.62096 10.10.10.5.179 10.10.10.2.61506 10.10.10.1.179 ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED
Monitoring Traffic on the Interfaces Purpose Compare the traffic on an interface that establishes a TCP connection with the traffic on an interface that does not establish a TCP connection. From operational mode, run the monitor traffic command on the Device E interface to Device B and on the Device E interface to Device C. In the first example, acknowledgment (ack) messages are received. In the second example, ack messages are not received.
user@E> monitor traffic size 1500 interface ge-1/2/1.5 19:02:49.700912 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: P 3330573561:3330573580(19) ack 915601686 win 16384 <nop,nop,timestamp 1869518816 1869504850>: BGP, length: 19 19:02:49.801244 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: . ack 19 win 16384 <nop,nop,timestamp 1869518916 1869518816> 19:03:03.323018 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: P 1:20(19) ack 19 win 16384 <nop,nop,timestamp 1869532439 1869518816>: BGP, length: 19 19:03:03.422418 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: . ack 20 win 16384 <nop,nop,timestamp 1869532539 1869532439> 19:03:17.220162 Out IP 10.10.10.5.bgp > 10.10.10.6.62096: P 19:38(19) ack 20 win 16384 <nop,nop,timestamp 1869546338 1869532439>: BGP, length: 19 19:03:17.320501 In IP 10.10.10.6.62096 > 10.10.10.5.bgp: . ack 38 win 16384 <nop,nop,timestamp 1869546438 1869546338> user@E> monitor traffic size 1500 interface ge-1/0/0.9 18:54:20.175471 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 1869009240 0,sackOK,eol> 18:54:23.174422 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 1869012240 0,sackOK,eol> 18:54:26.374118 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 1869015440 0,sackOK,eol> 18:54:29.573799 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 <mss 1460,sackOK,eol> 18:54:32.773493 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 <mss 1460,sackOK,eol> 18:54:35.973185 Out IP 10.10.10.9.61335 > 10.10.10.10.bgp: S 573929123:573929123(0) win 16384 <mss 1460,sackOK,eol>
Action
Understanding How to Use Standard Firewall Filters on page 29 Understanding Flood Prevention Stateless Firewall Filters Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods on page 143 Example: Configuring a Filter to Accept Packets Based on IPv6 TCP Flags on page 149
142
Standard Firewall Filters That Prevent IP Packet Flooding
Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods on page 143 Example: Configuring a Filter to Accept Packets Based on IPv6 TCP Flags on page 149
Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods
This example shows how to create a stateless firewall filter that protects against TCP and ICMP denial-of-service attacks.

Requirements
Overview
In this example, you create a stateless firewall filter called protect-RE that polices TCP and ICMP packets. This example includes the following policers:
tcp-connection-policerLimits the traffic rate of the TCP packets to 500,000 bps and
the burst size to 15,000 bytes. Packets that exceed the traffic rate are discarded.
icmp-policerLimits the traffic rate of the ICMP packets to 1,000,000 bps and the
burst size to 15,000 bytes. Packets that exceed the traffic rate are discarded. When specifying limits, the bandwidth limit can be from 32,000 bps to 32,000,000,000 bps and the burst-size limit can be from 1,500 bytes through 100,000,000 bytes. Use the following abbreviations when specifying limits: k (1,000), m (1,000,000), and g (1,000,000,000). Each policer is incorporated into the action of a filter term. This example includes the following terms:
tcp-connection-termPolices certain TCP packets with a source address of
192.168.122.0/24 or 10.2.1.0/24. These addresses are defined in the trusted-addresses prefix list. Policed packets include connection request packets (SYN and ACK flag bits equal 1 and 0), connection release packets (FIN flag bit equals 1), and connection reset packets (RST flag bit equals 1).
icmp-termPolices echo request packets, echo response packets, unreachable packets,
and time-exceeded packets. All of these ICMP packets are counted in the icmp-counter counter.
143
NOTE: You can move terms within the firewall filter by using the insert command. See insert in the Junos OS CLI User Guide.
If you want to include the terms created in this procedure in the protect-RE firewall filter configured in Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118, perform the configuration tasks in this example first. Then configure the terms as described in Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118. This approach ensures that the rate-limiting terms are included as the first two terms in the firewall filter.
Configuration
CLI Quick Configuration To quickly configure the stateless firewall filter, copy the following commands to a text file, remove any line breaks, and then paste the commands into the CLI.
[edit] set firewall family inet filter protect-RE term tcp-connection-term from source-prefix-list trusted-addresses set firewall family inet filter protect-RE term tcp-connection-term from protocol tcp set firewall family inet filter protect-RE term tcp-connection-term from tcp-flags "(syn & !ack) | fin | rst" set firewall family inet filter protect-RE term tcp-connection-term then policer tcp-connection-policer set firewall family inet filter protect-RE term tcp-connection-term then accept set firewall family inet filter protect-RE term icmp-term from protocol icmp set firewall family inet filter protect-RE term icmp-term from icmp-type echo-request set firewall family inet filter protect-RE term icmp-term from icmp-type echo-reply set firewall family inet filter protect-RE term icmp-term from icmp-type unreachable set firewall family inet filter protect-RE term icmp-term from icmp-type time-exceeded set firewall family inet filter protect-RE term icmp-term then policer icmp-policer set firewall family inet filter protect-RE term icmp-term then count icmp-counter set firewall family inet filter protect-RE term icmp-term then accept set firewall policer tcp-connection-policer filter-specific set firewall policer tcp-connection-policer if-exceeding bandwidth-limit 1m set firewall policer tcp-connection-policer if-exceeding burst-size-limit 15k set firewall policer tcp-connection-policer then discard set firewall policer icmp-policer filter-specific set firewall policer icmp-policer if-exceeding bandwidth-limit 1m set firewall policer icmp-policer if-exceeding burst-size-limit 15k set firewall policer icmp-policer then discard set policy-options prefix-list trusted-addresses 10.2.1.0/24 set policy-options prefix-list trusted-addresses 192.168.122.0/24
144
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode on page 15. To configure stateless firewall filter policers:
1.
Define the first policer.

[edit] user@host# edit firewall policer tcp-connection-policer
2.
Define the action for the policer.

[edit firewall policer tcp-connection-policer] user@host# set then discard
3.
Define the rate limits for the policer.

[edit firewall policer tcp-connection-policer] user@host# set filter-specific user@host# set if-exceeding burst-size-limit 15k bandwidth-limit 1m
4.
Define the second policer.

[edit] user@host# edit firewall policer icmp-policer
5.

[edit firewall policer icmp-policer] user@host# set then discard
6.
Set the rate limits for the policer.

[edit firewall policer icmp-policer] user@host# set filter-specific user@host# set if-exceeding burst-size-limit 15k bandwidth-limit 1m
7.
Define the prefix list.

[edit] user@host# set policy-options prefix-list trusted-addresses 192.168.122.0/24 user@host# set policy-options prefix-list trusted-addresses 10.2.1.0/24
8.

9.

[edit firewall family inet filter protect-RE] user@host# edit term tcp-connection-term
10.
Define the source address match condition for the term.

[edit firewall family inet filter protect-RE term tcp-connection-term] user@host# set from source-prefix-list trusted-addresses
145
11.
Define protocol match conditions for the term.

[edit firewall family inet filter protect-RE term tcp-connection-term] user@host# set from protocol tcp tcp-flags "(syn & !ack) | fin | rst"
12.

[edit firewall family inet filter protect-RE term tcp-connection-term] user@host# set then policer tcp-connection-policer accept
13.
Define the second term.

[edit] user@host# edit firewall family inet filter protect-RE term icmp-term
14.
Define the protocol for the term.

[edit firewall family inet filter protect-RE term icmp-term] user@host# set from protocol icmp
15.
Define the match conditions for the term.

[edit firewall family inet filter protect-RE term icmp-term] user@host# set from icmp-type [echo-request echo-reply unreachable time-exceeded]
16.

[edit firewall family inet filter protect-RE term icmp-term] user@host# set then policer icmp-policer count icmp-counter accept
Results
Confirm your configuration by entering the show firewall command and the show policy-options command from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
user@host# show firewall family inet { filter protect-RE { term tcp-connection-term { from { source-prefix-list { trusted-addresses; } protocol tcp; tcp-flags "(syn & !ack) | fin | rst"; } then { policer tcp-connection-policer; accept; } } term icmp-term { from { protocol icmp; icmp-type [ echo-request echo-reply unreachable time-exceeded ]; } then { policer icmp-policer;
146
count icmp-counter; accept; } } } } policer tcp-connection-policer { filter-specific; if-exceeding { bandwidth-limit 1m; burst-size-limit 15k; } then discard; } policer icmp-policer { filter-specific; if-exceeding { bandwidth-limit 1m; burst-size-limit 15k; } then discard; } user@host# show policy-options prefix-list trusted-addresses { 10.2.1.0/24; 192.168.122.0/24; }
Verification

Displaying Stateless Firewall Filter Configurations on page 147 Verifying a TCP and ICMP Flood Firewall Filter on page 147 Displaying Firewall Filter Statistics on page 148
Displaying Stateless Firewall Filter Configurations Purpose Action Meaning Verify the configuration of the firewall filter. From configuration mode, enter the show firewall command. Verify that the output shows the intended configuration of the firewall filter. In addition, verify that the terms are listed in the order in which you want the packets to be tested. You can move terms within a firewall filter by using the insert CLI command. Verifying a TCP and ICMP Flood Firewall Filter Purpose Verify that the actions of the firewall filter terms are taken.
147
Action
Send packets to the device that match the terms. In addition, verify that the filter actions are not taken for packets that do not match.
Verify that the device can establish only TCP sessions with a host at an IP address that matches 192.168.122.0/24 or 10.2.1.0/24. For example, log in to the device with the telnet host-name command from another host with one of these address prefixes. Use the ping host-name command to verify that the device responds only to ICMP packets (such as ping requests) that do not exceed the policer traffic rates. Use the ping host-name size bytes command to exceed the policer traffic rates by sending ping requests with large data payloads.
Sample Output
user@host> telnet 192.168.249.71 Trying 192.168.249.71... Connected to host.acme.net. Escape character is '^]'. host (ttyp0) login: user Password: --- JUNOS 6.4-20040521.1 built 2004-05-21 09:38:12 UTC user@host> user@host> ping 192.168.249.71 PING host-ge-000.acme.net (192.168.249.71): 56 data bytes 64 bytes from 192.168.249.71: icmp_seq=0 ttl=253 time=11.946 ms 64 bytes from 192.168.249.71: icmp_seq=1 ttl=253 time=19.474 ms 64 bytes from 192.168.249.71: icmp_seq=2 ttl=253 time=14.639 ms ... user@host> ping 192.168.249.71 size 20000 PING host-ge-000.acme.net (192.168.249.71): 20000 data bytes ^C --- host-ge-000.acme.net ping statistics --12 packets transmitted, 0 packets received, 100% packet loss
Meaning

You can successfully log in to the device using Telnet. The device sends responses to the ping host command. The device does not send responses to the ping host size 20000 command.
Displaying Firewall Filter Statistics Purpose Action Verify that packets are being policed and counted. From operational mode, enter the show firewall filter filter-name command.
148
Sample Output
user@host> show firewall filter protect-RE Filter: protect-RE Counters: Name icmp-counter Policers: Name tcp-connection-policer icmp-policer
Bytes 1040000 Packets 643254873 7391
Packets 5600
Meaning

Next to Filter, the name of the firewall filter is correct. Under Counters:

Under Name, the names of any counters configured in the firewall filter are correct. Under Bytes, the number of bytes that match the filter term containing the count counter-name action are shown. Under Packets, the number of packets that match the filter term containing the count counter-name action are shown.
Under Policers:

Under Name, the names of any policers configured in the firewall filter are correct. Under Packets, the number of packets that match the conditions specified for the policer are shown.
Two-Color Policer Configuration Overview on page 307 in the Junos OS Firewall Filter and Policer Configuration Guide.
Junos OS Feature Support Reference for SRX Series and J Series Devices
show firewall in the Junos OS Routing Protocols and Policies Command Reference ping in the Junos OS System Basics and Services Command Reference. telnet in the Junos OS System Basics and Services Command Reference.
Example: Configuring a Filter to Accept Packets Based on IPv6 TCP Flags


149
Requirements
Overview
In this example, you create a filter that accepts packets with specific IPv6 TCP flags.
Configuration

To quickly configure this example, copy the following commands into a text file, remove any line breaks, and then paste the commands into the CLI at the [edit] hierarchy level.
set firewall family inet6 filter tcp_filter term 1 from next-header tcp set firewall family inet6 filter tcp_filter term 1 from tcp-flags syn set firewall family inet6 filter tcp_filter term 1 then count tcp_syn_pkt set firewall family inet6 filter tcp_filter term 1 then log set firewall family inet6 filter tcp_filter term 1 then accept set interfaces lo0 unit 0 family inet6 filter input tcp_filter set interfaces lo0 unit 0 family inet6 address ::10.34.1.0/120
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the firewall filter
1.
Create the IPv6 stateless firewall filter tcp_filter.

[edit] user@host# edit firewall family inet6 filter tcp_filter
2.
Specify that a packet matches if it is the initial packet in a TCP session and the next header after the IPv6 header is type TCP.
[edit firewall family inet6 filter tcp_filter] user@host# set term 1 from next-header tcp user@host# set term 1 from tcp-flags syn
3.
Specify that matched packets are counted, logged to the buffer on the Packet Forwarding Engine, and accepted.
[edit firewall family inet6 filter tcp_filter] user@host# set term 1 then count tcp_syn_pkt user@host# set term 1 then log user@host# set term 1 then accept
150
[edit] user@host# set interfaces lo0 unit 0 family inet6 filter input tcp_filter user@host# set interfaces lo0 unit 0 family inet6 address ::10.34.1.0/120
1.
[edit] user@host# show firewall family inet6 { filter tcp_filter { term 1 { from { next-header tcp; tcp-flags syn; } then { count tcp_syn_pkt; log; accept; } } } }
2.
[edit] user@host# show interfaces lo0 { unit 0 { family inet6 { filter { input tcp_filter; } address ::10.34.1.0/120; } } }
3.
151
Verification
To confirm that the configuration is working properly, enter the show firewall operational mode command. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods on page 143 Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers on page 137
Standard Firewall Filters That Handle Fragmented Packets

Firewall Filters That Handle Fragmented Packets Overview on page 152 Example: Configuring a Stateless Firewall Filter to Handle Fragments on page 152
Firewall Filters That Handle Fragmented Packets Overview

You can create stateless firewall filters that handle fragmented packets destined for the Routing Engine. By applying these policies to the Routing Engine, you protect against the use of IP fragmentation as a means to disguise TCP packets from a firewall filter. For example, consider an IP packet that is fragmented into the smallest allowable fragment size of 8 bytes (a 20-byte IP header plus an 8-byte payload). If this IP packet carries a TCP packet, the first fragment (fragment offset of 0) that arrives at the device contains only the TCP source and destination ports (first 4 bytes), and the sequence number (next 4 bytes). The TCP flags, which are contained in the next 8 bytes of the TCP header, arrive in the second fragment (fragment offset of 1). On all SRX Series and J Series devices, fragmented packets are not sampled correctly by the firewall filter. When file sampling, port-mirroring and CFLOW is applied on an interface in output direction, packets are sampled before fragmenting the packet and packet-capture captures packet after fragmentation. See RFC 1858, Security Considerations for IP Fragment Filtering. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Example: Configuring a Stateless Firewall Filter to Handle Fragments on page 152
Example: Configuring a Stateless Firewall Filter to Handle Fragments

This example shows how to create a stateless firewall filter that handles packet fragments.

152
Requirements
Overview
In this example, you create a stateless firewall filter called fragment-RE that accepts fragmented packets originating from 10.2.1.0/24 and destined for the BGP port. This example includes the following firewall filter terms:
not-from-prefix-term-Discards packets that are not from 10.2.1.0/24 to ensure that
subsequent terms in the firewall filter are matched against packets from 10.2.1.0/24 only.
small-offset-termDiscards small (15) offset packets to ensure that subsequent
terms in the firewall filter can be matched against all the headers in the packet. In addition, the term adds a record to the system logging destinations for the firewall facility.
not-fragmented-termAccepts unfragmented TCP packets with a destination port
that specifies the BGP protocol. A packet is considered unfragmented if the MF flag is not set and the fragment offset equals 0.
first-fragment-termAccepts the first fragment of a fragmented TCP packet with a
destination port that specifies the BGP protocol.
fragment-termAccepts all fragments that were not discarded by small-offset-term.
(packet fragments 68191). However, only those fragments that are part of a packet containing a first fragment accepted by first-fragment-term are reassembled by the destination device. Packet fragments offset can be from 1 through 8191.
NOTE: You can move terms within the firewall filter by using the insert command. For more information, see insert in the Junos OS CLI User Guide.
Configuration
set firewall family inet filter fragment-RE term not-from-prefix-term from source-address 0.0.0.0/0 set firewall family inet filter fragment-RE term not-from-prefix-term from source-address 10.2.1.0/24 except set firewall family inet filter fragment-RE term not-from-prefix-term then discard
153
set firewall family inet filter fragment-RE term small-offset-term from fragment-offset 1-5 set firewall family inet filter fragment-RE term small-offset-term then syslog set firewall family inet filter fragment-RE term small-offset-term then discard set firewall family inet filter fragment-RE term not-fragmented-term from fragment-offset 0 set firewall family inet filter fragment-RE term not-fragmented-term from fragment-flags "!more-fragments" set firewall family inet filter fragment-RE term not-fragmented-term from protocol tcp set firewall family inet filter fragment-RE term not-fragmented-term from destination-port bgp set firewall family inet filter fragment-RE term not-fragmented-term then accept set firewall family inet filter fragment-RE term first-fragment-term from first-fragment set firewall family inet filter fragment-RE term first-fragment-term from protocol tcp set firewall family inet filter fragment-RE term first-fragment-term from destination-port bgp set firewall family inet filter fragment-RE term first-fragment-term then accept set firewall family inet filter fragment-RE term fragment-term from fragment-offset 6-8191 set firewall family inet filter fragment-RE term fragment-term then accept
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode on page 15 in the Junos OS CLI User Guide. To configure the stateless firewall filter:
1.
Define the stateless firewall filter.

[edit] user@host# edit firewall family inet filter fragment-RE
2.
Configure the first term for the filter.

[edit firewall family inet filter fragment-RE ] user@host# set term not-from-prefix-term from source-address 0.0.0.0/0 user@host# set term not-from-prefix-term from source-address 10.2.1.0/24 except user@host# set term not-from-prefix-term then discard
3.
Define the second term for the filter.

[edit firewall family inet filter fragment-RE] user@host# edit term small-offset-term
4.

[edit firewall family inet filter fragment-RE term small-offset-term] user@host# set from fragment-offset 1-5
5.

[edit firewall family inet filter fragment-RE term small-offset-term] user@host# set then syslog discard
6.
Define the third term for the filter.

[edit] user@host# edit firewall family inet filter fragment-RE term not-fragmented-term
154
7.

[edit firewall family inet filter fragment-RE term not-fragmented-term] user@host# set from fragment-flags "!more-fragments" fragment-offset 0 protocol tcp destination-port bgp
8.

[edit firewall family inet filter fragment-RE term not-fragmented-term] user@host# set then accept
9.
Define the fourth term for the filter.

[edit] user@host# edit firewall family inet filter fragment-RE term first-fragment-term
10.

[edit firewall family inet filter fragment-RE term first-fragment-term] user@host# set from first-fragment protocol tcp destination-port bgp
11.

[edit firewall family inet filter fragment-RE term first-fragment-term] user@host# set then accept
12.
Define the last term for the filter.

[edit] user@host# edit firewall family inet filter fragment-RE term fragment-term
13.

[edit firewall family inet filter fragment-RE term fragment-term] user@host# set from fragment-offset 68191
14.

[edit firewall family inet filter fragment-RE term fragment-term] user@host# set then accept
Results
Confirm your configuration by entering the show firewall command from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
user@host# show firewall family inet { filter fragment-RE { term not-from-prefix-term { from { source-address { 0.0.0.0/0; 10.2.1.0/24 except; } } then discard; } term small-offset-term { from {
155
fragment-offset 1-5; } then { syslog; discard; } } term not-fragmented-term { from { fragment-offset 0; fragment-flags "!more-fragments"; protocol tcp; destination-port bgp; } then accept; } term first-fragment-term { from { first-fragment; protocol tcp; destination-port bgp; } then accept; } term fragment-term { from { fragment-offset 6-8191; } then accept; } } }
Verification
To confirm that the configuration is working properly, perform these tasks:

Displaying Stateless Firewall Filter Configurations on page 156 Verifying a Firewall Filter that Handles Fragments on page 157
Displaying Stateless Firewall Filter Configurations Purpose Verify the configuration of the firewall filter. You can analyze the flow of the filter terms by displaying the entire configuration. From configuration mode, enter the show firewall command. Verify that the output shows the intended configuration of the firewall filter. In addition, verify that the terms are listed in the order in which you want the packets to be tested. You can move terms within a firewall filter by using the insert CLI command.
Action Meaning
156
Verifying a Firewall Filter that Handles Fragments Purpose Action Meaning Verify that the actions of the firewall filter terms are taken. Send packets to the device that match the terms. Verify that packets from 10.2.1.0/24 with small fragment offsets are recorded in the devices system logging destinations for the firewall facility.
show route summary in the Junos OS Routing Protocols and Policies Command Reference.
Standard Firewall Filters That Set Rate Limits

Stateless Firewall Filters That Reference Policers Overview on page 157 Example: Configuring a Rate-Limiting Filter Based on Destination Class on page 158
Stateless Firewall Filters That Reference Policers Overview

Policing, or rate limiting, is an important component of firewall filters that lets you limit the amount of traffic that passes into or out of an interface. A stateless firewall filter that references a policer can provide protection from denial-of-service (DOS) attacks. Traffic that exceeds the rate limits configured for the policer is either discarded or marked as lower priority than traffic that conforms to the configured rate limits. Packets can be marked for a lower priority by being set to a specific output queue, set to a specific packet loss priority (PLP) level, or both. When necessary, low-priority traffic can be discarded to prevent congestion. A policer specifies two types of rate limits on traffic:
Bandwidth limitThe average traffic rate permitted, specified as a number of bits per second. Maximum burst sizeThe packet size permitted for bursts of data that exceed the bandwidth limit.
Policing uses an algorithm to enforce a limit on average bandwidth while allowing bursts up to a specified maximum value. You can use policing to define specific classes of traffic on an interface and apply a set of rate limits to each class. After you name and configure a policer, it is stored as a template. You can then apply the policer in an interface configuration or, to rate-limit packet-filtered traffic only, in a firewall filter configuration. For an IPv4 firewall filter term only, you can also specify a prefix-specific action as a nonterminating action that applies a policer to the matched packets. A prefix-specific action applies additional matching criteria on the filter-matched packets based on specified address prefix bits and then associates the matched packets with a counter and policer instance for that filter term or for all terms in the firewall filter.
157
To apply a policer or a prefix action to packet-filtered traffic, you can use the following firewall filter nonterminating actions:

policer policer-name three-color-policer (single-rate | two-rate) policer-name prefix-action action-name
Standard Firewall Filter Nonterminating Actions on page 82 Traffic Policing Overview on page 297 Prefix-Specific Counting and Policing Overview on page 359
Example: Configuring a Rate-Limiting Filter Based on Destination Class

This example shows how to configure a rate-limiting stateless firewall filter.

Requirements
No special configuration beyond device initialization is required before configuring this example. Before you begin, configure the destination class class1.
Overview
In this example, you use a stateless firewall filter to set rate limits based on a destination class. To activate a policer from within a stateless firewall filter configuration:

Create a template for the policer by including the policer policer-name statement. Reference the policer in a filter term that specifies the policer in the policer policer-name nonterminating action.
You can also activate a policer by including the policer (input | output) policer-template-name statement at a logical interface.
158
Configuration

set firewall filter rl_dclass1 policer police_class1 if-exceeding bandwidth-limit 25 set firewall filter rl_dclass1 policer police_class1 if-exceeding burst-size-limit 1000 set firewall filter rl_dclass1 policer police_class1 then discard set firewall filter rl_dclass1 term term1 from destination-class class1 set firewall filter rl_dclass1 term term1 then policer police_class1 set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30 set interfaces ge-0/0/1 unit 0 family inet filter input ospf_or_131
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter rl_dclass1 with policer police_class1 for destination class class1:
1.
Create the stateless firewall filter rl_dclass1.

[edit] user@host# edit firewall filter rl_dclass1
2.
Configure the policer template police_class1.

[edit firewall filter rl_dclass1] user@host# set policer police_class1 if-exceeding bandwidth-limit 25 user@host# set policer police_class1 if-exceeding burst-size-limit 1000 user@host# set policer police_class1 then discard
3.
Configure a filter term that uses policer police_class1 to rate-limit traffic for destination class class1.
[edit firewall filter rl_dclass1] user@host# set term term1 from destination-class class1 user@host# set term term1 then policer police_class1
Apply the Stateless Firewall Filter to a Logical Interface Step-by-Step Procedure To apply the filter rl_dclass1 to a logical interface:
1.
159
2.

3.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input rl_dclass1
1.
[edit] user@host# show firewall filter rl_dclass1 { policer police_class1 { if-exceeding { bandwidth-limit 25; burst-size-limit 1000; } then { discard; } } term term1 { from { destination-class class1; } then { policer police_class1; } } }
2.
[edit] user@host# show interfaces ge-0/0/1 { unit 0 { family inet { filter { input rl_dclass1; } address 10.1.2.3/30; } } }
160
3.
Verification
To confirm that the configuration is working properly, enter the show class-of-service ge-0/0/1 operational mode command. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Filtering Packets Received on an Interface Set Overview on page 192 Statement Hierarchy for Defining an Interface Set on page 192 Statement Hierarchy for Configuring a Filter to Match on an Interface Set on page 193 Example: Filtering Packets Received on an Interface Set on page 193
Multiple Standard Firewall Filters Applied as a List

Multiple Standard Firewall Filters Applied as a List Overview on page 161 Guidelines for Applying Multiple Standard Firewall Filters as a List on page 164 Example: Applying Lists of Multiple Standard Firewall Filters on page 165
Multiple Standard Firewall Filters Applied as a List Overview


The Challenge: Simplify Large-Scale Firewall Filter Administration on page 161 A Solution: Apply Lists of Firewall Filters on page 162 Configuration of Multiple Filters for Filter Lists on page 162 Application of Filter Lists to a Router Interface on page 162 Interface-Specific Names for Filter Lists on page 163 How Filter Lists Evaluate Packets on page 163
The Challenge: Simplify Large-Scale Firewall Filter Administration

Typically, you apply a single stateless firewall filter to an interface in the input or output direction or both. However, this approach might not be practica, when you have a device configured with many interfaces. In large environments, you want the flexibility of being able to modify filtering terms common to multiple interfaces without having to reconfigure the filter of every affected interface. In general, the solution is to apply an effectively chained structure of multiple stateless firewall filters to a single interface. You partition your filtering terms into multiple firewall filters that each perform a filtering task. You can then choose which filtering tasks you want to perform for a given interface and apply the filtering tasks to that interface. In this way, you only manage the configuration for a filtering task in a single firewall filter.
161
The Junos OS policy framework provides two options for managing the application of multiple separate firewall filters to individual router interfaces. One option is to apply multiple filters as a single input list or output list. The other option is to reference a stateless firewall filter from within the term of another stateless firewall filter.
A Solution: Apply Lists of Firewall Filters

The most straightforward way to avoid configuring duplicate filtering terms common to multiple stateless firewall filters is to configure multiple firewall filters and then apply a customized list of filters to each interface. The Junos OS uses the filtersin the order in which they appear in the listto evaluate packets that transit the interface. If you need to modify filtering terms shared across multiple interfaces, you only need to modify one firewall filter that contains those terms.
NOTE: In contrast with the alternative approach (configuring nested firewall filters) applying firewall filter lists combines multiple firewall filters at each interface application point.
Configuration of Multiple Filters for Filter Lists

Configuring firewall filters to be applied in unique lists for each router interface involves separating shared packet-filtering rules from interface-specific packet-filtering rules as follows:
Unique filtersFor each set of packet-filtering rules unique to a specific interface, configure a separate firewall filter that contains only the filtering terms for that interface. Shared filtersFor each set of packet-filtering rules common across two or more interfaces, consider configuring a separate firewall filter that contains the shared filtering terms.
TIP: When planning for a large number firewall filters to be applied using filter lists, administrators often organize the shared filters by filtering criteria, by the services to which customers subscribe, or by the purposes of the interfaces.
Application of Filter Lists to a Router Interface

Applying a list of firewall filters to an interface is a matter of selecting the filters that meet the packet-filtering requirements of that interface. For each interface, you can include an input-list or output-list statement (or both) within the filter stanza to specify the relevant filters in the order in which they are to be used:

Include any filters that contain common filtering terms relevant to the interface. Include the filter that contain only the filtering terms unique to the interface.
162
Interface-Specific Names for Filter Lists

Because a filter list is configured under an interface, the resulting concatenated filter is interface-specific. The system-generated name of an interface-specific filter consists of the full interface name followed by either -i for an input filter list or -o for an output filter list.
Input filter list nameFor example, if you use the input-list statement to apply a chain of filters to logical interface ge-1/3/0.0, the Junos OS uses the following name for the filter:
ge-1/3/0.0-i
Output filter list nameFor example, if you use the output-list statement to apply a chain of filters to logical interface fe-0/1/2.0, the Junos OS uses the following name for the filter:
fe-0/1/2.0-o
You can use the interface-specific name of a filter list when you enter a Junos OS operational mode command that specifies a stateless firewall filter name.
How Filter Lists Evaluate Packets

The policy framework software evaluates a packet against the filters in a list sequentially, beginning with the first filter in the list until either a terminating action occurs or the packet is implicitly discarded:
If the packet matches a filter term that specifies a terminating action, any subsequent filters in the list are not used to evaluate the packet. Terminating actions include the following: accept, discard, reject, logical-system logical-system-name, routing-instance routing-instance-name, and topology topology-name. If the packet matches a filter term that does not specify either a terminating action or the next term action, any nonterminating actions are taken and then the packet is implicitly accepted. The accept action is a terminating action, and therefore any subsequent filters in the list are not used to evaluate the packet. If the packet matches a term that includes the next term action, the matching packet is evaluated against the next term in the firewall filter; otherwise, the matching packet is not evaluated against subsequent terms in the firewall filter. For example, if a packet matches a standard firewall filter term that is configured with the count nonterminating action and the next term flow control action, the packet is counted and evaluation of the packet continues with the next term or firewall filter.
Otherwise, if no packet match results in an implicit or explicit terminating action, the packet is implicitly discarded. How Standard Firewall Filters Evaluate Packets on page 20 Guidelines for Applying Multiple Standard Firewall Filters as a List on page 164 Example: Applying Lists of Multiple Standard Firewall Filters on page 165
163
Guidelines for Applying Multiple Standard Firewall Filters as a List


Statement Hierarchy for Applying Lists of Multiple Firewall Filters on page 164 Filter Input Lists and Output Lists for Router Interfaces on page 164 Types of Filters Supported in Lists on page 164 Restrictions on Applying Filter Lists for MPLS or Layer 2 CCC Traffic on page 165
Statement Hierarchy for Applying Lists of Multiple Firewall Filters

To apply a single filter to the input or output direction of a router logical interface, you include the input filter-name or output filter-name statement under the filter stanza for a protocol family. To apply a list of multiple filters to the input or output direction of a router logical interface, include the input-list [ filter-names ] or output-list [ filter-names ] statement under the filter stanza for a protocol family:
interfaces { interface-name { unit logical-unit-number { family family-name { filter { ...filter-options... input-list [ filter-names ]; output-list [ filter-names ]; } } } } }

Filter Input Lists and Output Lists for Router Interfaces

When applying a list of firewall filters as a list, the following limitations apply:

You can specify up to 16 firewall filters for a filter input list. You can specify up to 16 firewall filters for a filter output list.
Types of Filters Supported in Lists

Lists of multiple firewall filters applied to a router interface support standard stateless firewall filters only. You cannot apply lists containing service filters or simple filters to a router interface.
164
Restrictions on Applying Filter Lists for MPLS or Layer 2 CCC Traffic

When applying stateless firewall filters that evaluate MPLS traffic (family mpls) or Layer 2 circuit cross-connection traffic (family ccc), you can use the input-list [ filter-names ] and output-list [ filter-names ] statements for all interfaces except the following:

Management and internal Ethernet (fxp) interfaces Loopback (lo0) interfaces USB modem (umd) interfaces Multiple Standard Firewall Filters Applied as a List Overview on page 161 Example: Applying Lists of Multiple Standard Firewall Filters on page 165
Example: Applying Lists of Multiple Standard Firewall Filters

This example shows how to apply lists of multiple stateless firewall filters.

Requirements
Before you begin, be sure that you have:
Installed your router and supported PIC, DPC, or MPC and performed the initial router configuration. Configured basic Ethernet in the topology. Configured a logical interface to run the IP version 4 (IPv4) protocol (family inet) and configured the logical interface with an interface address. This example uses logical interface ge-1/3/0.0 configured with the IP address 1.1.1.2/30.
NOTE: For completeness, the configuration section of this example includes setting an IP address for logical interface ge-1/3/0.0.
Verified that traffic is flowing in the topology and that ingress and egress IPv4 traffic is flowing through logical interface ge-1/3/0.0. Verified that you have access to the remote host that is connected to this routers logical interface ge-1/3/0.0.
Overview
In this example, you configure three IPv4 stateless firewall filters and apply each filter directly to the same logical interface by using a list.
165
Topology This example applies the following firewall filters as a list of input filters at logical interface ge-1/3/0.0. Each filter contains a single term that evaluates IPv4 packets and accepts packets based on the value of the destination port field in the TCP header:

Filter filter_FTP matches on the FTP port number (21). Filter filter_SSH matches on the SSH port number (22). Filter filter_Telnet matches on the Telnet port number (23).
If an inbound packet does not match any of the filters in the input list, the packet is discarded.
NOTE: The Junos OS uses filters in a list in the order in which the filter names appear in the list. In this simple example, the order is irrelevant because all of the filters specify the same action.
Any of the filters can be applied to other interfaces, either alone (using the input or output statement) or in combination with other filters (using the input-list or output-list statement). The objective is to configure multiple minimalist firewall filters that you can reuse in interface-specific filter lists.
Configuration

Configure Multiple IPv4 Stateless Firewall Filters on page 167 Apply the Filters to a Logical Interface as an Input List and an Output List on page 167 Confirm and Commit Your Candidate Configuration on page 168
set firewall family inet filter filter_FTP term 0 from protocol tcp set firewall family inet filter filter_FTP term 0 from destination-port 21 set firewall family inet filter filter_FTP term 0 then count pkts_FTP set firewall family inet filter filter_FTP term 0 then accept set firewall family inet filter filter_SSH term 0 from protocol tcp set firewall family inet filter filter_SSH term 0 from destination-port 23 set firewall family inet filter filter_SSH term 0 then count pkts_SSH set firewall family inet filter filter_SSH term 0 then accept set firewall family inet filter filter_Telnet term 0 from protocol tcp set firewall family inet filter filter_Telnet term 0 from destination-port 22 set firewall family inet filter filter_Telnet term 0 then count pkts_Telnet set firewall family inet filter filter_Telnet term 0 then accept set firewall family inet filter filter_discard term 1 then count pkts_discarded set firewall family inet filter filter_discard term 1 then discard set interfaces ge-1/3/0 unit 0 family inet address 1.1.1.2/30
166
set interfaces ge-1/3/0 unit 0 family inet filter input-list filter_FTP set interfaces ge-1/3/0 unit 0 family inet filter input-list filter_SSH set interfaces ge-1/3/0 unit 0 family inet filter input-list filter_Telnet set interfaces ge-1/3/0 unit 0 family inet filter input-list filter_discard
Configure Multiple IPv4 Stateless Firewall Filters Step-by-Step Procedure To configure the IPv4 stateless firewall filters:
1.
Navigate the CLI to the hierarchy level at which you configure IPv4 firewall filters.
[edit] user@host# edit firewall family inet
2.
Configure the first firewall filter to count and accept packets for port 21.
[edit firewall family inet] user@host# set filter filter_FTP term 0 from protocol tcp user@host# set filter filter_FTP term 0 from destination-port 21 user@host# set filter filter_FTP term 0 then count pkts_FTP user@host# set filter filter_FTP term 0 then accept
3.
Configure the second firewall filter to count and accept packets for port 23.
[edit firewall family inet] user@host# set filter filter_SSH term 0 from protocol tcp user@host# set filter filter_SSH term 0 from destination-port 23 user@host# set filter filter_SSH term 0 then count pkt_SSH user@host# set filter filter_SSH term 0 then accept
4.
Configure the third firewall filter to count and accept packets from port 22.
[edit firewall family inet] user@host# set filter filter_Telnet term 0 from protocol tcp user@host# set filter filter_Telnet term 0 from destination-port 22 user@host# set filter filter_Telnet term 0 then count pkts_Telnet user@host# set filter filter_Telnet term 0 then accept
5.
Configure the last firewall filter to count the discarded packets.

[edit firewall family inet] user@host# set filter filter_discard term 1 then count pkts_discarded user@host# set filter filter_discard term 1 then discard
Apply the Filters to a Logical Interface as an Input List and an Output List Step-by-Step Procedure To apply the six IPv4 stateless firewall filters as a list of input filters and a list of output filters:
1.
Navigate the CLI to the hierarchy level at which you apply IPv4 firewall filters to logical interface ge-1/3/0.0.
2.
Configure the IPv4 protocol family for the logical interface.

167
3.
Apply the filters as a list of input filters.

[edit interfaces ge-1/3/0 unit 0 family inet] user@host# set filter input-list [ filter_FTP filter_SSH filter_Telnet filter_discard ]
1.
Confirm the configuration of the stateless firewall filters by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit] user@host# show firewall family inet { filter filter_FTP { term 0 { from { protocol tcp; destination-port 21; } then { count pkts_FTP; accept; } } } filter filter_SSH { term 0 { from { protocol tcp; destination-port 23; } then { count pkts_SSH; accept; } } } filter filter_Telnet { term 0 { from { protocol tcp; destination-port 22; } then { count pkts_Telnet; accept; } } } filter filter_discard { term 1 { then { count pkts_discarded;
168
discard; } } } }
2.
[edit] user@host# show interfaces ge-1/3/0 { unit 0 { family inet { filter { input-list [ filter_FTP filter_SSH filter_Telnet filter_discard ]; } address 1.1.1.2/30; } } }
3.
Verification
Verifying That Inbound Packets Are Accepted Only If Destined for the FTP, SSH or Telnet Port on page 169
Verifying That Inbound Packets Are Accepted Only If Destined for the FTP, SSH or Telnet Port Purpose Action Verify that all three filters are active for the logical interface. To verify that input packets are accepted according to the three filters:
1.
From the remote host that is connected to this routers logical interface ge-1/3/0.0, send a packet with destination port number 21 in the header. The packet should be accepted.
2. From the remote host that is connected to this routers logical interface ge-1/3/0.0,
send a packet with destination port number 23 in the header. The packet should be accepted.
send a packet with destination port number 22 in the header. The packet should be accepted.
169
send a packet with a destination port number other than 21, 22, or 23. The packet should be discarded.
5. To display counter information for the list of filters applied to the input at ge-1/3/0.0-i
enter the show firewall filter ge-1/3/0.0-i operational mode command. The command output displays the number of bytes and packets that match filter terms associated with the following counters:

pkts_FTP-ge-1/3/0.0-i pkts_SSH-ge-1/3/0.0-i pkts_Telnet-ge-1/3/0.0-i pkts_discard-ge-1/3/0.0-i
Multiple Standard Firewall Filters Applied as a List Overview on page 161 Guidelines for Applying Multiple Standard Firewall Filters as a List on page 164
Multiple Standard Firewall Filters in a Nested Configuration

Multiple Standard Firewall Filters in a Nested Configuration Overview on page 170 Guidelines for Nesting References to Multiple Standard Firewall Filters on page 172 Example: Nesting References to Multiple Standard Firewall Filters on page 173
Multiple Standard Firewall Filters in a Nested Configuration Overview


The Challenge: Simplify Large-Scale Firewall Filter Administration on page 170 A Solution: Configure Nested References to Firewall Filters on page 171 Configuration of Nested Firewall Filters on page 171 Application of Nested Firewall Filters to a Router Interface on page 171
The Challenge: Simplify Large-Scale Firewall Filter Administration

Typically, you apply a single stateless firewall filter to an interface in the input or output direction or both. This approach might not be practical, however, when you have a router configured with many, even hundreds of interfaces. In an environment of this scale, you want the flexibility of being able to modify filtering terms common to multiple interfaces without having to reconfigure the filter of every affected interface. In general, the solution is to apply an effectively chained structure of multiple stateless firewall filters to a single interface. You partition your filtering terms into multiple firewall filters configured so that you can apply a unique filter to each router interface but also apply common filters to multiple router interfaces as required. The Junos OS policy framework provides two options for managing the application of multiple separate firewall filters to individual router interfaces. One option is to apply multiple filters as a
170
single input list or output list. The other option is to reference a stateless firewall filter from within the term of another stateless firewall filter.
A Solution: Configure Nested References to Firewall Filters

The most structured way to avoid configuring duplicate filtering terms common to multiple stateless firewall filters is to configure multiple stateless firewall filters so that each filter includes the shared filtering terms by referencing a separate filter that contains the common filtering terms. The Junos OS uses the filter termsin the order in which they appear in the filter definitionto evaluate packets that transit the interface. If you need to modify filtering terms shared across multiple interfaces, you only need to modify one firewall filter.
NOTE: Similar to the alternative approach (applying a list of firewall filters), configuring a nested firewall filter combines multiple firewall filters into a new firewall filter definition.
Configuration of Nested Firewall Filters

Configuring a nested firewall filter for each router interface involves separating shared packet-filtering rules from interface-specific packet-filtering rules as follows:
For each set of packet-filtering rules common across multiple interfaces, configure a separate firewall filter that contains the shared filtering terms. For each router interface, configure a separate firewall filter that contains:

All the filtering terms unique to that interface. An additional filtering term that includes a filter reference to the firewall filter that contains the common filtering terms.
Application of Nested Firewall Filters to a Router Interface

Applying nested firewall filters is no different from applying an unnested firewall filter. For each interface, you can include an input or output statement (or both) within the filter stanza to specify the appropriate nested firewall filter. Applying nested firewall filters to an interface, the shared filtering terms and the interface-specific firewall filters are applied through a single nested firewall filter that includes other filters through the filter statement within a separate filtering term. Related Documentation

Guidelines for Nesting References to Multiple Standard Firewall Filters on page 172 Example: Nesting References to Multiple Standard Firewall Filters on page 173
171
Guidelines for Nesting References to Multiple Standard Firewall Filters


Statement Hierarchy for Configuring Nested Firewall Filters on page 172 Filter-Defining Terms and Filter-Referencing Terms on page 172 Types of Filters Supported in Nested Configurations on page 173 Number of Filter References in a Single Filter on page 173 Depth of Filter Nesting on page 173
Statement Hierarchy for Configuring Nested Firewall Filters

To reference a filter from within a filter, include the filter filter-name statement as a separate filter term:
firewall firewall-name { family family-name { filter filter-name { term term-name { filter filter-name; } } } }

Filter-Defining Terms and Filter-Referencing Terms

You cannot configure a firewall filter term that both references another firewall filter and defines a match condition or action. If a firewall filter term includes the filter statement, then it cannot also include the from or then statement. For example, the firewall filter term term term1 in the configuration is not valid:
[edit] firewall { family inet { filter filter_1 { term term1 { filter filter_2; from { source-address 1.1.1.1/32; } then { accept; } } } }
172
In order for term term1 to be a valid filter term, you must either remove the filter filter_2 statement or remove both the from and then stanzas.
Types of Filters Supported in Nested Configurations

Nested configurations of firewall filters support standard stateless firewall filters only. You cannot use service filters or simple filters in a nested firewall filter configuration.
Number of Filter References in a Single Filter

The total number of filters referenced from within a filter cannot exceed 256.
Depth of Filter Nesting

The Junos OS supports a single level of firewall filter nesting. If filter_1 references filter_2, you cannot configure a filter that references a filter that references filter_1. Related Documentation

Multiple Standard Firewall Filters in a Nested Configuration Overview on page 170 Example: Nesting References to Multiple Standard Firewall Filters on page 173
Example: Nesting References to Multiple Standard Firewall Filters

This example shows how to configure nested references to multiple stateless firewall filters.

Requirements
Overview
In this example, you configure a stateless firewall filter for a match condition and action combination that can be shared among multiple firewall filters. You then configure two firewall filters that reference the first firewall filter. Later, if the common filtering criteria needs to be changed, you would modify only the one shared firewall filter configuration. Topology The common_filter firewall filter discards packets that have a UDP source or destination port field number of 69. Both of the two additional firewall filters, filter1 and filter2, reference the common_filter.
173
Configuration

Configure the Nested Firewall Filters on page 174 Apply Both Nested Firewall Filters to Interfaces on page 175 Confirm and Commit Your Candidate Configuration on page 175
set firewall family inet filter common_filter term common_term from protocol udp set firewall family inet filter common_filter term common_term from port tftp set firewall family inet filter common_filter term common_term then discard set firewall family inet filter filter1 term term1 filter common-filter set firewall family inet filter filter1 term term2 from address 192.168.0.0/16 set firewall family inet filter filter1 term term2 then reject set firewall family inet filter filter2 term term1 filter common-filter set firewall family inet filter filter2 term term2 from protocol udp set firewall family inet filter filter2 term term2 from port bootps set firewall family inet filter filter2 term term2 then accept set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.1/24 set interfaces ge-0/0/0 unit 0 family inet filter input filter1 set interfaces ge-0/0/3 unit 0 family inet address 10.1.3.1/24 set interfaces ge-0/0/0 unit 0 family inet filter input filter2
Configure the Nested Firewall Filters Step-by-Step Procedure To configure two nested firewall filters that share a common filter:
1.
Navigate the CLI to the hierarchy level at which you configure IPv4 firewall filters.
[edit] user@host# edit firewall family inet
2.
Configure the common filter that will be referenced by multiple other filters.
[edit firewall family inet] user@host# set filter common_filter term common_term from protocol udp user@host# set filter common_filter term common_term from port tftp user@host# set filter common_filter term common_term then discard
3.
Configure a filter that references the common filter.

[edit firewall family inet] user@host# set filter filter1 term term1 filter common-filter user@host# set filter filter1 term term2 from address 192.168.0.0/16 user@host# set filter filter1 term term2 then reject
4.
Configure a second filter that references the common filter.

[edit firewall family inet] user@host# set filter filter2 term term1 filter common-filter user@host# set filter filter2 term term2 from protocol udp
174
user@host# set filter filter2 term term2 from port bootps user@host# set filter filter2 term term2 then accept
Apply Both Nested Firewall Filters to Interfaces Step-by-Step Procedure To apply both nested firewall filters to logical interfaces:
1.
Apply the first nested filter to a logical interface input.

[edit] user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.1/24 user@host# set interfaces ge-0/0/0 unit 0 family inet filter input filter1
2.
Apply the second nested filter to a logical interface input.

[edit] user@host# set interfaces ge-0/0/3 unit 0 family inet address 10.1.3.1/24 user@host# set interfaces ge-0/0/0 unit 0 family inet filter input filter2
1.
[edit] user@host# show firewall family inet { filter common_filter { term common_term { from { protocol udp; port tftp; } then { discard; } } } filter filter1 { term term1 { filter common-filter; } term term2 { from { address 192.168/16; } then { reject; } } } filter filter2 { term term1 {
175
filter common-filter; } term term2 { from { protocol udp; port bootps; } then { accept; } } } }
2.
[edit] user@host# show interfaces ge-0/0/0 { unit 0 { family inet { filter { input filter1; } address 10.1.0.1/24; } } } ge-0/0/3 { unit 0 { family inet { filter { input filter2; } address 10.1.3.1/24; } } }
3.
Verification
To confirm that the configuration is working properly, enter the show firewall filter filter1 and show firewall filter filter2 operational mode commands. Related Documentation

Multiple Standard Firewall Filters in a Nested Configuration Overview on page 170 Guidelines for Nesting References to Multiple Standard Firewall Filters on page 172
176
Interface-Specific Firewall Filter Instances

Interface-Specific Firewall Filter Instances Overview on page 177 Statement Hierarchy for Configuring Interface-Specific Firewall Filters on page 179 Statement Hierarchy for Applying Interface-Specific Firewall Filters on page 180 Example: Configuring Interface-Specific Firewall Filter Counters on page 180
Interface-Specific Firewall Filter Instances Overview


Instantiation of Interface-Specific Firewall Filters on page 177 Interface-Specific Names for Firewall Filter Instances on page 178 Interface-Specific Firewall Filter Counters on page 178 Interface-Specific Firewall Filter Policers on page 179
Instantiation of Interface-Specific Firewall Filters

On T Series, M120, M320, and MX Series routers, you can enable the Junos OS to automatically create an interface-specific instance of a firewall filter for each interface to which you apply the filter. If you enable interface-specific instantiation of a firewall filter and then apply that filter to multiple interfaces, any count actions or policer actions configured in the filter terms act on the traffic stream entering or exiting each individual interface, regardless of the sum of traffic on the multiple interfaces. You can enable this option per firewall filter by including the interface-specific statement in the filter configuration.
NOTE: On T Series, M120, M320, and MX Series routers, interfaces are distributed among multiple packet-forwarding components.
Interface-specific firewall filtering is not supported on M Series routers other than the M120 and M320 routers. If you apply a firewall filter to multiple interfaces on an M Series router other than the M120 or M320 routers, the filter acts on the sum of traffic entering or exiting those interfaces. Interface-specific firewall filtering is supported for standard stateless firewall filters and for service filters. Interface-specific instances are not supported for simple filters.
177
Interface-Specific Names for Firewall Filter Instances

When the Junos OS creates a separate instance of a firewall filter for a logical interface, the instance is associate with an interface-specific name. The system-generated name of a firewall filter instance consists of the name of the configured filter followed by a hyphen (-), the full interface name, and either -i for an input filter instance or -o for an output filter instance.
Input filter instance nameFor example, if you apply the interface-specific firewall filter filter_s_tcp to the input at logical interface at-1/1/1.0, the Junos OS instantiates an interface-specific filter instance with the following system-generated name:
filter_s_tcp-at-1/1/1.0-i
Output filter instance nameFor example, if you apply the interface-specific firewall filter filter_s_tcp to the output at logical interface so-2/2/2.2, the Junos OS instantiates an interface-specific filter instance with the following system-generated name:
count_s_tcp-so-2/2/2.2-o
You can use the interface-specific name of a filter instance when you enter a Junos OS operational mode command that specifies a stateless firewall filter name.
TIP: When you configure a firewall filter with interface-specific instances enabled, we recommend you limit the filter name to 52 bytes in length. This is because firewall filter names are restricted to 64 bytes in length. If a system-generated filter instance name exceeds this maximum length, the policy framework software might reject the instance name.
Interface-Specific Firewall Filter Counters

Instantiation of interface-specific firewall filters causes the Packet Forwarding Engine to maintain any counters for the firewall filter separately for each interface. You specify interface-specific counters per firewall filter term by specifying the count counter-name non-terminating action. The system-generated name of an interface-specific firewall filter counter consists of the name of the configured counter followed by a hyphen (-), the full interface name, and either -i for an input filter instance or -o for an output filter instance.
Interface-specific input filter counter nameFor example, suppose you configure the filter counter count_tcp for an interface-specific firewall filter. If the filter is applied to the input at logical interface at-1/1/1.0, the Junos OS creates the following system-generated counter name:
count_tcp-at-1/1/1.0-i
Interface-specific output filter counter nameFor example, suppose you configure the filter counter count_udp for an interface-specific firewall filter. If the filter is applied to the output at logical interface so-2/2/2.2, the Junos OS creates the following system-generated counter name:
count_udp-so-2/2/2.2-o
178
Interface-Specific Firewall Filter Policers

Instantiation of interface-specific firewall filters not only creates separate instances of any firewall filter counters but also creates separate instances of any policer actions. Any policers applied through an action specified in the firewall filter configuration are applied separately to each interface in the interface group. You specify interface-specific policers per firewall filter term by specifying the policer policer-name non-terminating action. Related Documentation

Statement Hierarchy for Configuring Interface-Specific Firewall Filters on page 179 Statement Hierarchy for Applying Interface-Specific Firewall Filters on page 180 Example: Configuring Interface-Specific Firewall Filter Counters on page 180
Statement Hierarchy for Configuring Interface-Specific Firewall Filters

To enable interface-specific instances for stateless firewall filters, include the interface-specific statement in the filter filter-name or service-filter service-filter-name stanza. Any counters specified as actions in an interface-specific filter are maintained separately per filter instance. Any policers specified as actions in an interface-specific filter are applied per filter instance.
firewall { family family-name { (filter filter-name | service-filter service-filter-name) { ... interface-specific; ... term term-name { from { match-conditions; } then { count counter-name; policer policer-name; } } ... } } ]

Interface-Specific Firewall Filter Instances Overview on page 177 Statement Hierarchy for Applying Interface-Specific Firewall Filters on page 180 Example: Configuring Interface-Specific Firewall Filter Counters on page 180
179
Statement Hierarchy for Applying Interface-Specific Firewall Filters

To apply an interface-specific stateless firewall filter to a logical interface, include the input filter-name or output filter-name statement in the filter or service-filter stanza of the interfaces configuration:
interfaces { interface-name { unit unit-number { family family-name { filter { input filter-name-1; output filter-name-2; } service-filter { input service-filter-name-1; output service-filter-name-2; } } } } }

Interface-Specific Firewall Filter Instances Overview on page 177 Statement Hierarchy for Configuring Interface-Specific Firewall Filters on page 179 Example: Configuring Interface-Specific Firewall Filter Counters on page 180
Example: Configuring Interface-Specific Firewall Filter Counters

This example shows how to configure and apply an interface-specific standard stateless firewall filter.

Requirements
Interface-specific stateless firewall filters are supported on T Series, M120, M320, and MX Series routers only. No special configuration beyond device initialization is required before configuring this example.
180
Overview
In this example, you create an interface-specific stateless firewall filter that counts and accepts packets with source or destination addresses in a specified prefix and the IP protocol type field set to a specific value. Topology You configure the interface-specific stateless firewall filter filter_s_tcp to count and accept packets with IP source or destination addresses in the 10.0.0.0/12 prefix and the IP protocol type field set to tcp (or the numeric value 6). The name of the firewall filter counter is count_s_tcp. You apply the firewall filter to multiple logical interfaces:

at-1/1/1.0 input so-2/2/2.2 output
Applying the filter to these two interfaces results in two instances of the filter: filter_s_tcp-at-1/1/1.0-i and filter_s_tcp-so-2/2/2.2-o, respectively.
Configuration

Configure the Interface-Specific Firewall Filter on page 181 Apply the Interface-Specific Firewall Filter to Multiple Interfaces on page 182 Confirm Your Candidate Configuration on page 182 Clear the Counters and Commit Your Candidate Configuration on page 183
set firewall family inet filter filter_s_tcp interface-specific set firewall family inet filter filter_s_tcp term 1 from address 10.0.0.0/12 set firewall family inet filter filter_s_tcp term 1 from protocol tcp set firewall family inet filter filter_s_tcp term 1 then count count_s_tcp set firewall family inet filter filter_s_tcp term 1 then accept set interfaces at-1/1/1 unit 0 family inet filter input filter_s_tcp set interfaces so-2/2/2 unit 2 family inet filter filter_s_tcp
Configure the Interface-Specific Firewall Filter Step-by-Step Procedure To configure the interface-specific firewall filter:
1.
Create the IPv4 firewall filter filter_s_tcp.

[edit] user@host# edit firewall family inet filter filter_s_tcp
181
2.
Enable interface-specific instances of the filter.

[edit firewall family inet filter filter_s_tcp] user@host# set interface-specific
3.
Configure the match conditions for the term.

[edit firewall family inet filter filter_s_tcp] user@host# set term 1 from address 10.0.0.0/12 user@host# set term 1 from protocol tcp
4.
Configure the actions for the term.

[edit firewall family inet filter filter_s_tcp] user@host# set term 1 then count count_s_tcp user@host# set term 1 then accept
Apply the Interface-Specific Firewall Filter to Multiple Interfaces Step-by-Step Procedure To apply the filter filter_s_tcp to logical interfaces at-1/1/1.0 and so-2/2/2.2:
1.
Apply the interface-specific filter to packets received on logical interface at-1/1/1.0.

[edit] user@host# set interfaces at-1/1/1 unit 0 family inet filter input filter_s_tcp
2.
Apply the interface-specific filter to packets transmitted from logical interface so-2/2/2.2.
[edit] user@host# set interfaces so-2/2/2 unit 2 family inet filter filter_s_tcp
Confirm Your Candidate Configuration Step-by-Step Procedure To confirm your candidate configuration:
1.
[edit] user@host# show firewall family inet { filter filter_s_tcp { interface-specific; term 1 { from { address { 10.0.0.0/12; } protocol tcp; } then { count count_s_tcp; accept; } }
182
} }
2.
Confirm the configuration of the interfaces by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit] user@host# show interfaces at-1/1/1 { unit 0 family inet { filter { input filter_s_tcp; } } ] } so-2/2/2 { unit 2 family inet { filter { output filter_s_tcp; } } } }
Clear the Counters and Commit Your Candidate Configuration Step-by-Step Procedure To clear the counters and commit your candidate configuration:
1.
From operational command mode, use the clear firewall all command to clear the statistics for all firewall filters. To clear only the counters used in this example, include the interface-specific filter instance names:
[edit] user@host> clear firewall filter filter_s_tcp-at-1/1/1.0-i user@host> clear firewall filter filter_s_tcp-so-2/2/2.2-o
2.
Commit your candidate configuration.

Verification

Verifying That the Filter Is Applied to Each of the Multiple Interfaces on page 183 Verifying That the Counters Are Collected Separately by Interface on page 184
Verifying That the Filter Is Applied to Each of the Multiple Interfaces Purpose Verify that the filter is applied to each of the multiple interfaces.
183
Action
Run the show interfaces command with the detail or extensive output level.
1.
Verify that the filter is applied to the input for at-1/1/1.0:

user@host> show interfaces at-1/1/1 detail Physical interface: at-1/1/1, Enabled, Physical link is Up Interface index: 300, SNMP ifIndex: 194, Generation: 183 ... Logical interface at-1/1/1.0 (Index 64) (SNMP ifIndex 204) (Generation 5) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: ATM-SNAP ... Protocol inet, MTU: 4470, Generation: 13, Route table: 0 Flags: Sendbcast-pkt-to-re Input Filters: filter_s_tcp-at-1/1/1.0-i,,,,,
2. Verify that the filter is applied to the output for so-2/2/2.2: user@host> show interfaces so-2/2/2 detail Physical interface: so-2/2/2, Enabled, Physical link is Up Interface index: 129, SNMP ifIndex: 502, Generation: 132 ... Logical interface so-2/2/2.2 (Index 70) (SNMP ifIndex 536) (Generation 135) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: PPP ... Protocol inet, MTU: 4470, Generation: 146, Route table: 0 Flags: Sendbcast-pkt-to-re Output Filters: filter_s_tcp-so-2/2/2.2-o,,,,,
Verifying That the Counters Are Collected Separately by Interface Purpose Make sure that the count_s_tcp counters are collected separately for the two logical interfaces. Run the show firewall command.
user@host> show firewall filter filter_s_tcp Filter: filter_s_tcp Counters: Name Bytes count_s_tcp-at-1/1/1.0-i 420 count_s_tcp-so-2/2/2.2-o 8888
Action
Packets 5 101
Interface-Specific Firewall Filter Instances Overview on page 177 Statement Hierarchy for Configuring Interface-Specific Firewall Filters on page 179 Statement Hierarchy for Applying Interface-Specific Firewall Filters on page 180
184
Filtering Packets Received on a Set of Interface Groups

Filtering Packets Received on a Set of Interface Groups Overview on page 185 Statement Hierarchy for Assigning Interfaces to Interface Groups on page 185 Statement Hierarchy for Configuring a Filter to Match on a Set of Interface Groups on page 186 Statement Hierarchy for Applying Filters to an Interface Group on page 187 Example: Filtering Packets Received on an Interface Group on page 188
Filtering Packets Received on a Set of Interface Groups Overview

You can configure a firewall filter term that matches packets tagged for a specified interface group or set of interface groups. An interface group consists of one or more logical interfaces with the same group number. Packets received on an interface in an interface group are tagged as being part of that group. For standard stateless firewall filters, you can filter packets received on an interface group for IPv4, IPv6, virtual private LAN service ( VPLS), Layer 2 circuit cross-connection (CCC), and Layer 2 bridging traffic. For service filters, you can filter packets received on an interface group for either IPv4 or IPv6 traffic.
NOTE: You can also configure a firewall filter term that matches on packets tagged for a specified interface set. For more information, see Filtering Packets Received on an Interface Set Overview on page 192.
Statement Hierarchy for Assigning Interfaces to Interface Groups on page 185 Statement Hierarchy for Configuring a Filter to Match on a Set of Interface Groups on page 186 Example: Filtering Packets Received on an Interface Group on page 188
Statement Hierarchy for Assigning Interfaces to Interface Groups

To assign a logical interface to an interface group, specify the group number by including the group interface-group-number statement in the filter stanza:
interfaces { interface-name { unit unit-number { family ( inet | inet6 | vpls | ccc | bridge) { filter { group interface-group-number; } } } } }
185
NOTE: The number 0 is not a valid number for an interface group.
You can configure the firewall filter at one of the following hierarchy levels:

Filtering Packets Received on a Set of Interface Groups Overview on page 185 Statement Hierarchy for Configuring a Filter to Match on a Set of Interface Groups on page 186 Example: Filtering Packets Received on an Interface Group on page 188
Statement Hierarchy for Configuring a Filter to Match on a Set of Interface Groups

You can configure a standard stateless firewall filter or a service filter term that matches packets tagged for a specified interface group or set of interface groups. To configure a standard stateless firewall filter that matches packets tagged for a specified interface group or set of interface groups, configure a filter term that uses the interface-group interface-group-number match condition:
firewall { family (inet | inet6 | vpls | ccc | bridge) { filter filter-name { term term-name { from { interface-group interface-group-number; } then { filter-actions; } } } } }
To configure a service filter that matches packets tagged for a specified interface group or set of interface groups, configure a filter term that uses the interface-group interface-group-name match condition:
firewall { family (inet | inet6) { service-filter filter-name { term term-name { from { interface-group interface-group-number; } then { service-filter-actions; } }
186
} } }
You can configure the firewall filter at one of the following hierarchy levels:

Filtering Packets Received on a Set of Interface Groups Overview on page 185 Statement Hierarchy for Assigning Interfaces to Interface Groups on page 185 Example: Filtering Packets Received on an Interface Group on page 188
Statement Hierarchy for Applying Filters to an Interface Group

To apply a standard stateless firewall filter to an interface group, include the input filter-name or output filter-name in the filter stanza:
interfaces { interface-name { unit unit-number { family family-name { ... filter { input filter-name; output filter-name; } } } } }

Interface-Specific Firewall Filter Instances Overview on page 177 Statement Hierarchy for Assigning Interfaces to Interface Groups on page 185 Statement Hierarchy for Configuring a Filter to Match on a Set of Interface Groups on page 186 Example: Filtering Packets Received on an Interface Group on page 188
187
Example: Filtering Packets Received on an Interface Group

This example shows how to configure a standard stateless firewall filter to match packets tagged for a particular interface group.

Requirements
Overview
In this example, you configure two router interfaces to belong to the interface group. You also configure a stateless firewall filter that matches packets that have been tagged as received on that interface group, contain a source or destination address within a particular prefix, and contain a TCP source or destination port of a specific type and port number. The filter counts, logs, and rejects packets that match this criteria. The filter counts, logs, and rejects all other packets. By applying this firewall filter to only one of the two interfaces in the interface group, you can apply the filtering mechanism to all packets input to the two interfaces. Topology You configure the interface group number 1 to consist of the management port fxp0.0 and the loopback port lo0.0. You configure the firewall filter filter_if_group to accept only packets from interface group 1, received from or destined for IP addresses in the 192.168.80.114/32 prefix, and received from or destined for TCP port number 79. You apply the firewall filter filter_if_group to the routers loopback interface.
Configuration

Configure the Stateless Firewall Filter on page 189 Assign Interfaces to the Interface Group on page 189 Apply the Firewall Filter to the Loopback Interface on page 190 Confirm and Commit Your Candidate Configuration on page 190
set firewall family inet filter filter_if_group term term1 from interface-group 1
188
set firewall family inet filter filter_if_group term term1 from address 192.168.80.114/32 set firewall family inet filter filter_if_group term term1 from protocol tcp set firewall family inet filter filter_if_group term term1 from port finger set firewall family inet filter filter_if_group term term1 then count if_group_counter1 set firewall family inet filter filter_if_group term term1 then log set firewall family inet filter filter_if_group term term1 then reject set firewall family inet filter filter_if_group term term2 then count if_group_counter2 set firewall family inet filter filter_if_group term term2 then log set firewall family inet filter filter_if_group term term2 then accept set interfaces fxp0 unit 0 family inet filter group 1 set interfaces fxp0 unit 0 family inet address 192.168.5.38/24 set interfaces lo0 unit 0 family inet filter group 1 set interfaces lo0 unit 0 family inet address 10.0.0.1/32 set interfaces lo0 unit 0 family inet address 192.168.77.1/32 set interfaces lo0 unit 0 family inet filter input filter_if_group
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter filter_if_group:
1.
Create the stateless firewall filter filter_if_group.

[edit] user@host# edit firewall family inet filter filter_if_group
2.
Configure term term1 to match packets received on interface group 1, with the source or destination address field in the 192.168.80.114/32 prefix, and with the TCP source or destination port number 79.
[edit firewall family inet filter filter_if_group] user@host# set term term1 from interface-group 1 user@host# set term term1 from address 192.168.80.114/32 user@host# set term term1 from protocol tcp user@host# set term term1 from port finger
3.
Configure term term1 to count, log, and reject matching packets.

[edit firewall family inet filter filter_if_group] user@host# set term term1 then count if_group_counter1 user@host# set term term1 then log user@host# set term term1 then reject
4.
Configure the term term2 to count, log, and accept all other packets.
[edit firewall family inet filter filter_if_group] user@host# set term term2 then count if_group_counter2 user@host# set term term2 then log user@host# set term term2 then accept
Assign Interfaces to the Interface Group Step-by-Step Procedure To assign logical interfaces to the interface group number 1 referenced by the firewall filter match term term1:
1.
Assign the management port to interface group number 1.

[edit] user@host# set interfaces fxp0 unit 0 family inet filter group 1
189
user@host# set interfaces fxp0 unit 0 family inet address 192.168.5.38/24

2.
Assign a second logical interface to interface group number 1.

[edit] user@host# set interfaces lo0 unit 0 family inet filter group 1 user@host# set interfaces lo0 unit 0 family inet address 10.0.0.1/32 user@host# set interfaces lo0 unit 0 family inet address 192.168.77.1/32
Apply the Firewall Filter to the Loopback Interface Step-by-Step Procedure
To apply the firewall filter to the routers loopback interface:

[edit] user@host# set interfaces lo0 unit 0 family inet filter input filter_if_group
1.
[edit] user@host# show firewall family inet { filter filter_if_group { term term1 { from { interface-group 1; address { 192.168.80.114/32; } protocol tcp; port finger; } then { count if_group_counter1; log; reject; } } term term2 { then { count if_group_counter2; log; accept; } } } }
190
2.
[edit] user@host# show interfaces fxp0 { unit 0 { family inet { filter { group 1; } address 192.168.5.38/24; } } } lo0 { unit 0 { family inet { filter { input filter_if_group; group 1; } address 10.0.0.1/32; address 192.168.77.1/32; } } }
3.
Verification
To display the firewall filter counters, enter the show firewall filter filter_if_group operational mode command:
user@host> show firewall filter filter_if_group Filter: filter_if_group Counters: Name if_group_counter1 if_group_counter2
Bytes 0 6452105
Packets 0 82667
To display the local log of packet headers for packets evaluated by the firewall filter, enter the show firewall log operational mode command. Related Documentation

Filtering Packets Received on a Set of Interface Groups Overview on page 185 Statement Hierarchy for Assigning Interfaces to Interface Groups on page 185 Statement Hierarchy for Configuring a Filter to Match on a Set of Interface Groups on page 186
191
Filtering Packets Received on an Interface Set

Filtering Packets Received on an Interface Set Overview on page 192 Statement Hierarchy for Defining an Interface Set on page 192 Statement Hierarchy for Configuring a Filter to Match on an Interface Set on page 193 Example: Filtering Packets Received on an Interface Set on page 193
Filtering Packets Received on an Interface Set Overview

You can configure a standard stateless firewall filter term that matches packets tagged for a specified interface set. An interface set groups two or more physical or logical interfaces into a single interface-set name. You can filter packets received on an interface set for protocol-independent, IPv4, IPv6, MPLS, VPLS, or bridging traffic.
NOTE: You can also configure a standard stateless firewall filter term or a service filter term that matches on packets tagged for a specified interface group. For more information, see Filtering Packets Received on a Set of Interface Groups Overview on page 185.
Statement Hierarchy for Defining an Interface Set on page 192 Statement Hierarchy for Configuring a Filter to Match on an Interface Set on page 193 Example: Configuring a Rate-Limiting Filter Based on Destination Class on page 158 Example: Filtering Packets Received on an Interface Set on page 193
Statement Hierarchy for Defining an Interface Set

To configure a named group of interfaces that can be referenced in a stateless firewall filter match condition, use the interface-set statement to define the interface-set name and two or more interfaces:
firewall { interface-set interface-set-name { interface-name; } }
You can include the statements at one of the following hierarchy levels:

[edit firewall] [edit logical-systems logical-system-name firewall]
To specify that the interface set contains all interfaces of a particular type, you can use the * (asterisk) wildcard character. For example, use fe-* to specify all Fast Ethernet interfaces.
192
Filtering Packets Received on an Interface Set Overview on page 192 Statement Hierarchy for Configuring a Filter to Match on an Interface Set on page 193 Example: Configuring a Rate-Limiting Filter Based on Destination Class on page 158 Example: Filtering Packets Received on an Interface Set on page 193
Statement Hierarchy for Configuring a Filter to Match on an Interface Set

To configure a standard stateless firewall filter that matches packets tagged for a specified interface group or set of interface groups, configure a filter term that uses the interface-group interface-group-name match condition:
firewall { family (any | inet | inet6 | mpls | vpls | bridge) { filter filter-name { term term-name { from { interface-set interface-set-name; } then { filter-actions; } } } } }
Filtering Packets Received on an Interface Set Overview on page 192 Statement Hierarchy for Defining an Interface Set on page 192 Example: Configuring a Rate-Limiting Filter Based on Destination Class on page 158 Example: Filtering Packets Received on an Interface Set on page 193
Example: Filtering Packets Received on an Interface Set

This example shows how to configure a standard stateless firewall filter to match packets tagged for a particular interface set.

Requirements
193
Overview
In this example, you apply a stateless firewall filter to the input of the router loopback interface. The firewall filter includes a term that matches packets tagged for a particular interface set. Topology You create the firewall filter L2_filter to apply rate limits to the protocol-independent traffic received on the following interfaces:

fe-0/0/0.0 fe-1/0/0.0 fe-1/1/0.0
First, for protocol-independent traffic received on fe-0/0/0.0, the firewall filter term t1 applies policer p1. For protocol-independent traffic received on any other Fast Ethernet interfaces, firewall filter term t2 applies policer p2. To define an interface set that consists of all Fast Ethernet interfaces, you include the interface-set interface-set-name interface-name statement at the [edit firewall] hierarchy level. To define a packet-matching criteria based on the interface on which a packet arrives to a specified interface set, you configure a term that uses the interface-set firewall filter match condition. Finally, for any other protocol-independent traffic, firewall filter term t3 applies policer p3.
Configuration
Configuring the Interfaces for Which the Stateless Firewall Filter Terms Take Rate-Limiting Actions on page 195 Configuring the Stateless Firewall Filter That Rate-Limits Protocol-Independent Traffic Based on the Interfaces on Which Packets Arrive on page 196 Applying the Stateless Firewall Filter to the Routing Engine Input Interface on page 198
set interfaces fe-0/0/0 unit 0 family inet address 10.1.1.1/30 set interfaces fe-1/0/0 unit 0 family inet address 10.2.2.1/30 set interfaces fe-1/1/0 unit 0 family inet address 10.4.4.1/30 set firewall policer p1 if-exceeding bandwidth-limit 5m set firewall policer p1 if-exceeding burst-size-limit 10m set firewall policer p1 then discard
194
set firewall policer p2 if-exceeding bandwidth-limit 40m set firewall policer p2 if-exceeding burst-size-limit 100m set firewall policer p2 then discard set firewall policer p3 if-exceeding bandwidth-limit 600m set firewall policer p3 if-exceeding burst-size-limit 1g set firewall policer p3 then discard set firewall interface-set ifset fe-* set firewall family any filter L2_filter term t1 from interface fe-0/0/0.0 set firewall family any filter L2_filter term t1 then count c1 set firewall family any filter L2_filter term t1 then policer p1 set firewall family any filter L2_filter term t2 from interface-set ifset set firewall family any filter L2_filter term t2 then count c2 set firewall family any filter L2_filter term t2 then policer p2 set firewall family any filter L2_filter term t3 then count c3 set firewall family any filter L2_filter term t3 then policer p3 set interfaces lo0 unit 0 family inet address 1.1.1.157/30 set interfaces lo0 unit 0 filter input L2_filter
Configuring the Interfaces for Which the Stateless Firewall Filter Terms Take Rate-Limiting Actions Step-by-Step Procedure To configure the interfaces for which the stateless firewall filter terms take rate-limiting actions:
1.
Configure the logical interface whose input traffic will be matched by the first term of the firewall filter.
[edit] user@host# set interfaces fe-0/0/0 unit 0 family inet address 10.1.1.1/30
2.
Configure the logical interfaces whose input traffic will be matched by the second term of the firewall filter.
[edit ] user@host# set interfaces fe-1/0/0 unit 0 family inet address 10.2.2.1/30 user@host# set interfaces fe-1/1/0 unit 0 family inet address 10.4.4.1/30
3.

Results
Confirm the configuration of the router transit interfaces by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces fe-0/0/0 { unit 0 { family inet { address 10.1.1.1/30; } } } fe-1/0/0 { unit 0 {
195
family inet { address 10.2.2.1/30; } } } fe-1/1/0 { unit 0 { family inet { address 10.4.4.1/30; } } }
Configuring the Stateless Firewall Filter That Rate-Limits Protocol-Independent Traffic Based on the Interfaces on Which Packets Arrive Step-by-Step Procedure To configure the standard stateless firewall L2_filter that uses policers (p1, p2, and p3) to rate-limit protocol-independent traffic based on the interfaces on which the packets arrive:
1.
Configure the firewall statements.

[edit] user@host# edit firewall
2.
Configure the policer p1 to discard traffic that exceeds a traffic rate of 5m bps or a burst size of 10m bytes.
[edit firewall] user@host# set policer p1 if-exceeding bandwidth-limit 5m user@host# set policer p1 if-exceeding burst-size-limit 10m user@host# set policer p1 then discard
3.
Configure the policer p2 to discard traffic that exceeds a traffic rate of 40m bps or a burst size of 100m bytes .
[edit firewall] user@host# set policer p2 if-exceeding bandwidth-limit 40m user@host# set policer p2 if-exceeding burst-size-limit 100m user@host# set policer p2 then discard
4.
Configure the policer p3 to discard traffic that exceeds a traffic rate of 600m bps or a burst size of 1g bytes.
[edit firewall] user@host# set policer p3 if-exceeding bandwidth-limit 600m user@host# set policer p3 if-exceeding burst-size-limit 1g user@host# set policer p3 then discard
5.
Define the interface set ifset to be the group of all Fast Ethernet interfaces on the router.
[edit firewall] user@host# set interface-set ifset fe-*
6.
Create the stateless firewall filter L2_filter.

[edit firewall] user@host# edit family any filter L2_filter
196
7.
Configure filter term t1 to match IPv4, IPv6, or MPLS packets received on interface fe-0/0/0.0 and use policer p1 to rate-limit that traffic.
[edit firewall family any filter L2_filter] user@host# set term t1 from interface fe-0/0/0.0 user@host# set term t1 then count c1 user@host# set term t1 then policer p1
8.
Configure filter term t2 to match packets received on interface-set ifset and use policer p2 to rate-limit that traffic.
[edit firewall family any filter L2_filter] user@host# set term t2 from interface-set ifset user@host# set term t2 then count c2 user@host# set term t2 then policer p2
9.
Configure filter term t3 to use policer p3 to rate-limit all other traffic.

[edit firewall family any filter L2_filter] user@host# set term t3 then count c3 user@host# set term t3 then policer p3
10.

Results
Confirm the configuration of the stateless firewall filter and the policers referenced as firewall filter actions by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall family any { filter L2_filter { term t1 { from { interface fe-0/0/0.0; } then { policer p1; count c1; } } term t2 { from { interface-set ifset; } then { policer p2; count c2; } } term t3 { then { policer p3;
197
count c3; } } } } 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-*; }
Applying the Stateless Firewall Filter to the Routing Engine Input Interface Step-by-Step Procedure To apply the stateless firewall filter to the Routing Engine input interface:
1.
Apply the stateless firewall filter to the Routing Engine interface in the input direction.
[edit] user@host# set interfaces lo0 unit 0 family inet address 1.1.1.157/30 user@host# set interfaces lo0 unit 0 filter input L2_filter
2.

Results
Confirm the application of the firewall filter to the Routing Engine input interface by entering the show interfaces command again. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
user@host# show interfaces fe-0/0/0 { ... } fe-1/0/0 { ...
198
} fe-1/1/0 { ... } lo0 { unit 0 { filter { input L2_filter; } family inet { address 1.1.1.157/30; } } }
Verification
To confirm that the configuration is working properly, use the show firewall filter L2_filter operational mode command to monitor traffic statistics about the firewall filter and three counters. Related Documentation

Understanding How to Use Standard Firewall Filters on page 29 Filtering Packets Received on an Interface Set Overview on page 192 Statement Hierarchy for Defining an Interface Set on page 192 Statement Hierarchy for Configuring a Filter to Match on an Interface Set on page 193
Filter-Based Forwarding

Filter-Based Forwarding Overview on page 199 Statement Hierarchy for Configuring FBF for IPv4 or IPv6 Traffic on page 201 Statement Hierarchy for Configuring FBF for MPLS-Tagged IPv4 Traffic on page 201 Statement Hierarchy for Configuring Routing Instances for FBF on page 204 Statement Hierarchy for Applying FBF Filters to Interfaces on page 205 Example: Configuring Filter-Based Forwarding on the Source Address on page 206
Filter-Based Forwarding Overview

Filters That Classify Packets or Direct Them to Routing Instances on page 199 Input Filtering to Classify and Forward Packets Within the Router on page 200 Output Filtering to Forward Packets to Another Routing Table on page 200 Restrictions for Applying Filter-Based Forwarding on page 200
Filters That Classify Packets or Direct Them to Routing Instances

For IPv4, IPv6, or MPLS-tagged IPv4 traffic only, you can use stateless firewall filters in conjunction with forwarding classes and routing instances to control how packets travel in a network. This is called filter-based forwarding (FBF).
199
You can define a filtering term that matches incoming packets based on source address and then classifies matching packets to a specified forwarding class. This type of filtering can be configured to grant certain types of traffic preferential treatment or to improve load balancing. To configure a stateless firewall filter to classify packets to a forwarding class, configure a term with the nonterminating action forwarding-class class-name. You can also define a filtering term that directs matching packets to a specified routing instance. This type of filtering can be configured to route specific types of traffic through a firewall or other security device before the traffic continues on its path. To configure a stateless firewall filter to direct traffic to a routing instance, configure a term with the terminating action routing-instance routing-instance-name <topology topology-name> to specify the routing instance to which matching packets will be forwarded.
Input Filtering to Classify and Forward Packets Within the Router

You can configure filters to classify packets based on source address and specify the forwarding path the packets take within the router by configuring a filter on the ingress interface. For example, you can use this filter for applications to differentiate traffic from two clients that have a common access layer (for example, a Layer 2 switch) but are connected to different Internet service providers (ISPs). When the filter is applied, the router can differentiate the two traffic streams and direct each to the appropriate network. Depending on the media type the client is using, the filter can use the source IP address to forward the traffic to the corresponding network through a tunnel. You can also configure filters to classify packets based on IP protocol type or IP precedence bits.
Output Filtering to Forward Packets to Another Routing Table

You can also forward packets based on output filters by configuring a filter on the egress interfaces. In the case of port mirroring, it is useful for port-mirrored packets to be distributed to multiple monitoring PICs and collection PICs based on patterns in 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 lookup when an FBF filter is configured on the egress interface. After the packet is classified at the egress interface by the FBF filter, it is redirected to another routing table for further route lookup.
Restrictions for Applying Filter-Based Forwarding

An interface configured with filter-based forwarding does not support source-class usage (SCU) filter matching and unicast reverse-path forwarding (RPF) check filters. Related Documentation

Statement Hierarchy for Configuring FBF for IPv4 or IPv6 Traffic on page 201 Statement Hierarchy for Configuring FBF for MPLS-Tagged IPv4 Traffic on page 201 Statement Hierarchy for Configuring Routing Instances for FBF on page 204 Statement Hierarchy for Applying FBF Filters to Interfaces on page 205 Example: Configuring Filter-Based Forwarding on the Source Address on page 206
200
Statement Hierarchy for Configuring FBF for IPv4 or IPv6 Traffic

You can configure stateless firewall filters for filter-based forwarding by configuring filter terms that specify the forwarding-class class-name nonterminating action or the routing-instance routing-instance-name terminating action:
firewall { family (inet | inet6) { filter filter-name { term term-name { from { ipv4-or-ipv6-match-conditions; } then { forwarding-class class-name; #optional other-optional-nonterminating-actions; routing-instance routing-instance-name <topology topology-name>; } } } } }

Filter-Based Forwarding Overview on page 199 Standard Firewall Filter Match Conditions for IPv4 Traffic on page 48 Standard Firewall Filter Match Conditions for IPv6 Traffic on page 57 Statement Hierarchy for Configuring Routing Instances for FBF on page 204 Example: Configuring Filter-Based Forwarding on the Source Address on page 206
Statement Hierarchy for Configuring FBF for MPLS-Tagged IPv4 Traffic

For interfaces on Enhanced Scaling flexible PIC concentrators (FPCs) on supported T Series routers only, you can configure stateless firewall filters for filter-based forwarding with match conditions based on Internet Protocol version 4 (IPv4) packet header fields in an MPLS flow:

Matching on IPv4 Address Fields on page 202 Matching on TCP Port Number Fields on page 202 Matching on UDP Port Number Fields on page 203
201
Matching on IPv4 Address Fields

To configure a firewall filter term that matches on IP source or destination address fields in the IPv4 header of packets in an MPLS flow, you can specify supported match conditions at the [edit firewall family mpls filter filter-name term term-name from ip-version ipv4] hierarchy level:
[edit] firewall { family mpls { filter filter-name { term term-name { from { ip-protocol ipv4 ( from { address-based-match-conditions; } then { forwarding-class class-name; #optional other-optional-nonterminating-actions; routing-instance routing-instance-name <topology topology-name>; } } } then { ... } } } } }
Matching on TCP Port Number Fields

To configure a firewall filter term that matches on TCP source or destination port number fields in the IPv4 header of packets in an MPLS flow, you can specify supported match conditions at the [edit firewall family mpls filter filter-name term term-name from ip-version ipv4 protocol tcp] hierarchy level:
[edit] firewall { family mpls { filter filter-name { term term-name { from { ip-protocol ipv4 ( tcp { from { tcp-port-based-match-conditions; } then { forwarding-class class-name; #optional other-optional-nonterminating-actions; routing-instance routing-instance-name <topology topology-name>; } ]
202
udp { from { udp-port-based-match-conditions; } then { forwarding-class class-name; #optional other-optional-nonterminating-actions; routing-instance routing-instance-name <topology topology-name>; } } } } then { ... } } } } }
Matching on UDP Port Number Fields

To configure a firewall filter term that matches on UDP source or destination port number fields in the IPv4 header of packets in an MPLS flow, you can specify supported match conditions at the [edit firewall family mpls filter filter-name term term-name from ip-version ipv4 protocol udp] hierarchy level:
[edit] firewall { family mpls { filter filter-name { term term-name { from { ip-protocol ipv4 ( udp { from { udp-port-based-match-conditions; } then { forwarding-class class-name; #optional other-optional-nonterminating-actions; routing-instance routing-instance-name <topology topology-name>; } ] udp { from { udp-port-based-match-conditions; } then { forwarding-class class-name; #optional other-optional-nonterminating-actions; routing-instance routing-instance-name <topology topology-name>; } } } }
203
then { ... } } } } }
Filter-Based Forwarding Overview on page 199 Standard Firewall Filter Match Conditions for MPLS-Tagged IPv4 Traffic on page 64 Statement Hierarchy for Configuring Routing Instances for FBF on page 204 Example: Configuring Filter-Based Forwarding on the Source Address on page 206
Statement Hierarchy for Configuring Routing Instances for FBF

A routing instance is a collection of routing tables, interfaces, and routing protocol parameters. The set of interfaces belongs to the routing tables, and the routing protocol parameters control the information in the routing tables. To configure a routing instance for filter-based forwarding:
1.
The instance-type must be forwarding. The forwarding routing instance type supports filter-based forwarding, where interfaces are not associated with instances. For this instance type, there is no one-to-one mapping between an interface and a routing instance. All interfaces belong to the default instance inet.0.
2. The name of the routing instance name must be the one referenced in the firewall
filter action.
NOTE: In Junos OS Release 9.0 and later, you can no longer specify a routing-instance name of default or include special characters within the name of a routing instance.
You must also create a routing table group that adds interface routes to the following routing instances:

Routing instance named in the action Default routing table inet.0
You create a routing table group to resolve the routes installed in the routing instance to directly connected next hops on that interface. For more information on routing table groups and interface routes, see the Junos OS Routing Protocols Configuration Guide.
routing-instances { routing-table-name { instance-type forwarding; routing-options { static { route destination-prefix nexthop address;
204
} } } }
You can include the forwarding routing instance at one of the following hierarchy levels:

Filter-Based Forwarding Overview on page 199 Statement Hierarchy for Configuring FBF for IPv4 or IPv6 Traffic on page 201 Statement Hierarchy for Configuring FBF for MPLS-Tagged IPv4 Traffic on page 201 Example: Configuring Filter-Based Forwarding on the Source Address on page 206
Statement Hierarchy for Applying FBF Filters to Interfaces

To apply filter-based forwarding to a logical interface, include the input or output statement in the filter stanza.
NOTE: An interface configured with filter-based forwarding does not support source-class usage (SCU) filter matching and unicast reverse-path forwarding (RPF) check filters.
interfaces { interface-name { unit unit-number { family (inet | inet6 | mpls) { filter { input filter-name; output filter-name; } address address; } } } }
You can include the interfaces configuration at one of the following hierarchy levels:

Filter-Based Forwarding Overview on page 199 Statement Hierarchy for Configuring FBF for IPv4 or IPv6 Traffic on page 201 Statement Hierarchy for Configuring FBF for MPLS-Tagged IPv4 Traffic on page 201 Statement Hierarchy for Configuring Routing Instances for FBF on page 204
205
Example: Configuring Filter-Based Forwarding on the Source Address on page 206
Example: Configuring Filter-Based Forwarding on the Source Address

This example shows how to configure filter-based forwarding (FBF).

Requirements
Overview
In this example, the router receives IPv4 traffic from one application server that is destined for a different application server. The router matches this flow of data packets using a firewall filter based on the packet IP source address. Any matching packets are routed to a routing instance that first sends all traffic to a security device, then forwards the traffic to the designated destination address. Topology The source application server is at host IP address 10.1.0.1/24, and the destination application server is at host IP address 10.1.3.1/24. The router interface to the source application server is ge-0/0/0.0, and the router interface to the destination application server is ge-0/0/3.0. The routing instance ri_fbf routing table ri_fbf.inet0 is configured with the interface ge-0/0/1.0 to the security device and the interface ge-0/0/3.0 to the destination application server:. The firewall filter filter_fbf matches packets on the source IP address 1.1.1.1/32 and directs matching packets to the routing instance ri_fbf,
Configuration

Configure the Routing Instance on page 207 Configure the Stateless Firewall Filter on page 207
206
Configure the Interfaces to the Application Servers and Apply the Stateless Firewall Filter on page 208 Confirm and Commit Your Candidate Configuration on page 208
set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.1/24 set interfaces ge-0/0/3 unit 0 family inet address 10.1.3.1/24 set routing-instances ri_fbf instance-type forwarding set routing-instances ri_fbf interface ge-0/0/1.0 set routing-instances ri_fbf interface ge-0/0/3.0 set routing-instances ri_fbf routing-options static route 12.34.56.0/24 next-hop 10.1.3.254 set firewall family inet filter filter_fbf term t1 from protocol tcp set firewall family inet filter filter_fbf term t1 from source-address 1.1.1.1/32 set firewall family inet filter filter_fbf term t1 then routing-instance ri_fbf set interfaces ge-0/0/0 unit 0 family inet filter input filter_fbf
Configure the Routing Instance Step-by-Step Procedure To configure the routing instance:
1.
Create the routing instance. The forwarding routing instance type supports filter-based forwarding, where interfaces are not associated with instances. For this instance type, there is no one-to-one mapping between an interface and a routing instance. All interfaces belong to the default instance inet.0.
[edit] user@host# set routing-instances ri_fbf instance-type forwarding
2.
Associate the interfaces with the routing instance.

[edit] user@host# set routing-instances ri_fbf interface ge-0/0/1.0 user@host# set routing-instances ri_fbf interface ge-0/0/3.0
3.
Configure the routing information for the routing instance.

[edit] user@host# set routing-instances ri_fbf routing-options static route 12.34.56.0/24 next-hop 10.1.3.254
1.
Create the firewall filter.

[edit] user@host# set firewall family inet filter filter_fbf term t1 from protocol tcp
2.
Set the firewall filter to match the correct source address.

[edit] user@host# set firewall family inet filter filter_fbf term t1 from source-address 1.1.1.1/32
207
3.
Set the firewall filter to forward packets to the routing instance.

[edit] user@host# set firewall family inet filter filter_fbf term t1 then routing-instance ri_fbf
Configure the Interfaces to the Application Servers and Apply the Stateless Firewall Filter Step-by-Step Procedure To configure the interfaces to the application servers and apply the stateless firewall filter to the interface to the source application server:
1.
Configure the interface to the source application server.

[edit] user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.1/24
2.
Configure the interface to the destination application server.

[edit] user@host# set interfaces ge-0/0/3 unit 0 family inet address 10.1.3.1/24
3.
Apply the stateless firewall filter to the input from the source application server.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family inet filter input filter_fbf
1.
Confirm the configuration of the routing instance by entering the show routing-instances configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit] user@host# show routing-instances ri_fbf { instance-type forwarding; interface ge-0/0/1.0; interface ge-0/0/3.0; routing-options { static { route 12.34.56.0/24 next-hop 10.1.3.254; } } }
2.
[edit] user@host# show firewall family inet { filter filter_fbf { term t1 {
208
from { source-address { 1.1.1.1/32; } protocol tcp; } then { routing-instance ri_fbf; } } } }

3.
[edit] user@host# show interfaces ge-0/0/0 { unit 0 { family inet { filter { input filter_fbf; } address 10.1.0.1/24; } } } ge-0/0/3 { unit 0 { family inet { address 10.1.3.1/24; } } }
Verification
Confirm that the configuration is working properly. Verifying That Filter-Based Forwarding Is Configured Purpose Verify that the firewall filter is enabled on the interface to the source application server and that the router forwarding table and the routing instance forwarding table contain the correct information. To perform the verification:
1.
Action
Use the show interfaces filters command to display firewall filter information for the interface to the source application server.
user@host> show interfaces filters ge-0/0/0.0 Interface ge-0/0/0.0 Admin Link Proto Input Filter up down inet filter_fbf Output Filter
209
2. Use the show route forwarding-table command to verify the contents of the router
forwarding table and the routing instance forwarding table.

user@host> show route forwarding-table
Routing table: default.inet Internet: Destination Type RtRef default user 1 default perm 0 0.0.0.0/32 perm 0 10.1.0.0/24 ifdn 0 ge-0/0/0.0 10.1.0.0/32 iddn 0 ge-0/0/0.0 10.1.0.1/32 user 0 10.1.0.1/32 intf 0 10.1.0.1/32 iddn 0 10.1.0.255/32 iddn 0 ge-0/0/0.0 10.1.1.0/26 ifdn 0 10.1.1.0/32 iddn 0 10.1.1.1/32 user 0 10.1.1.1/32 intf 0 10.1.1.1/32 iddn 0 10.1.1.63/32 iddn 0 255.255.255.255/32 perm 0 Routing table: ri_fbf.inet Internet: Destination Type RtRef default perm 0 0.0.0.0/32 perm 0 10.1.3.0/24 ifdn 0 ge-0/0/3.0 10.1.3.0/32 iddn 0 ge-0/0/3.0 10.1.3.1/32 user 0 10.1.3.1/32 intf 0 10.1.3.1/32 iddn 0 10.1.3.255/32 iddn 0 ge-0/0/3.0 224.0.0.0/4 perm 0 224.0.0.1/32 perm 0 255.255.255.255/32 perm 0
Next hop 0:12:f2:21:cf:0
Type Index NhRef Netif ucst 331 4 me0.0 rjct 36 3 dscd 34 1 rslv 613 1 recv rjct locl locl bcst rslv recv rjct locl locl bcst bcst 611 36 612 612 610 583 581 36 582 582 580 32 1 3 2 2 1 1 vlan.0 1 vlan.0 3 2 2 1 vlan.0 1
10.1.0.0
10.1.0.1 10.1.0.1 10.1.0.255
10.1.1.0 10.1.1.1 10.1.1.1 10.1.1.63
Next hop
Type Index NhRef Netif rjct 559 2 dscd 545 1 rslv 617 1 recv rjct locl locl bcst mdsc mcst bcst 615 559 616 616 614 546 529 543 1 2 2 2 1 1 1 1
10.1.3.0
10.1.3.1 10.1.3.1 10.1.3.255
224.0.0.1
Routing table: default.iso ISO: Destination Type RtRef Next hop default perm 0 Routing table: ri_fbf.iso ISO: Destination Type RtRef Next hop default perm 0
Type Index NhRef Netif rjct 60 1
Type Index NhRef Netif rjct 600 1
Meaning
The output indicates that the filter was created on the interface and that the routing instance is forwarding matching traffic to the correct IP address.
210
Filter-Based Forwarding Overview on page 199 Statement Hierarchy for Configuring FBF for IPv4 or IPv6 Traffic on page 201 Statement Hierarchy for Configuring FBF for MPLS-Tagged IPv4 Traffic on page 201 Statement Hierarchy for Configuring Routing Instances for FBF on page 204 Statement Hierarchy for Applying FBF Filters to Interfaces on page 205
Accounting for Standard Firewall Filters

Accounting for Standard Firewall Filters Overview on page 211 Statement Hierarchy for Configuring Firewall Filter Accounting Profiles on page 211 Statement Hierarchy for Applying Firewall Filter Accounting Profiles on page 212 Example: Configuring Statistics Collection for a Standard Firewall Filter on page 213
Accounting for Standard Firewall Filters Overview

Juniper Networks devices can collect various kinds of data about traffic passing through the device. You can set up one or more accounting profiles that specify some common characteristics of this data, including the following:

Fields used in the accounting records. Number of files that the routing platform retains before discarding, and the number of bytes per file. Polling period that the system uses to record the data
There are several types of accounting profiles: interface, firewall filter, source class and destination class usage, and Routing Engine. If you apply the same profile name to both a firewall filter and an interface, it causes an error. Related Documentation

Statement Hierarchy for Configuring Firewall Filter Accounting Profiles on page 211 Statement Hierarchy for Applying Firewall Filter Accounting Profiles on page 212 Example: Configuring Statistics Collection for a Standard Firewall Filter on page 213
Statement Hierarchy for Configuring Firewall Filter Accounting Profiles

To configure an accounting profile that you can apply to a firewall filter, include the filter-profile filter-profile-name statement in the accounting-options stanza.
accounting-options { filter-profile filter-profile-name { file log-filename { archive-sites { site-urls; } files number; size bytes; start-time time;
211
transfer-interval minutes; } interval minutes; counters { counter-name-1; counter-name-2; } } }
You can include the accounting options configuration at one of the following hierarchy levels:

To specify the name of the accounting data log file in the /var/log directory to be used in conjunction with the accounting profile, include the file log-filename statement. To specify how often statistics are collected for the accounting profile, include the interval minutes statement. To specify the names of the firewall filter counters for which filter profile statistics are collected, include the counters statement. Related Documentation

Accounting for Standard Firewall Filters Overview on page 211 Statement Hierarchy for Applying Firewall Filter Accounting Profiles on page 212 Example: Configuring Statistics Collection for a Standard Firewall Filter on page 213
Statement Hierarchy for Applying Firewall Filter Accounting Profiles

You can apply an accounting profile to a standard stateless firewall filter for any supported protocol family except family any. To apply a filter-accounting profile to a stateless firewall filter, include the accounting-profile accounting-profile-name statement at the firewall filter stanza:
firewall { family family-name { filter filter-name { accounting-profile accounting-profile-name; interface-specific; physical-interface-policer; term { filter filter-profile-name; } term term-name { from { match-conditions; } then { actions; }
212
} } } }

Accounting for Standard Firewall Filters Overview on page 211 Statement Hierarchy for Configuring Firewall Filter Accounting Profiles on page 211 Example: Configuring Statistics Collection for a Standard Firewall Filter on page 213
Example: Configuring Statistics Collection for a Standard Firewall Filter

This example shows how to configure and apply a stateless firewall filter that collects data according to parameters specified in an associated accounting profile.

Requirements
Firewall filter accounting profiles are supported for all traffic types except family any. No special configuration beyond device initialization is required before configuring this example.
Overview
In this example, you create a firewall filter accounting profile and apply it to a stateless firewall filter. The accounting profile specifies how frequently to collect packet and byte count statistics and the name of the file to which the statistics are written. The profile also specifies that statistics are to be collected for three firewall filter counters. Topology The firewall filter accounting profile filter_acctg_profile specifies that statistics are collected every 60 minutes, and the statistics are written to the file /var/log/ff_accounting_file. Statistics are collected for counters named counter1, counter2, and counter3. The IPv4 stateless firewall filter named my_firewall_filter increments a counter for each of three filter terms. The filter is applied to logical interface ge-0/0/1.0.
213
Configuration

Configure an Accounting Profile on page 214 Configure a Firewall Filter That References the Accounting Profile on page 215 Apply the Firewall Filter to an Interface on page 215 Confirm Your Candidate Configuration on page 216 Clear the Counters and Commit Your Candidate Configuration on page 217
set accounting-options filter-profile filter_acctg_profile file ff_accounting_file set accounting-options filter-profile filter_acctg_profile interval 60 set accounting-options filter-profile filter_acctg_profile counters counter1 set accounting-options filter-profile filter_acctg_profile counters counter2 set accounting-options filter-profile filter_acctg_profile counters counter3 set firewall family inet filter my_firewall_filter accounting-profile filter_acctg_profile set firewall family inet filter my_firewall_filter term term1 from protocol ospf set firewall family inet filter my_firewall_filter term term1 then count counter1 set firewall family inet filter my_firewall_filter term term1 then discard set firewall family inet filter my_firewall_filter term term2 from source-address 10.108.0.0/16 set firewall family inet filter my_firewall_filter term term2 then count counter2 set firewall family inet filter my_firewall_filter term term2 then discard set firewall family inet filter my_firewall_filter term accept-all then count counter3 set firewall family inet filter my_firewall_filter term accept-all then accept set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30 set interfaces ge-0/0/1 unit 0 family inet filter input my_firewall_filter
Configure an Accounting Profile Step-by-Step Procedure To configure an accounting profile:

1.
Create the accounting profile filter_acctg_profile.

[edit] user@host# edit accounting-options filter-profile filter_acctg_profile
2.
Configure the accounting profile to filter and collect packet and byte count statistics every 60 minutes and write them to the /var/log/ff_accounting_file file.
[edit accounting-options filter-profile filter_acctg_profile] user@host# set file ff_accounting_file user@host# set interval 60
214
3.
Configure the accounting profile to collect filter profile statistics (packet and byte counts) for three counters.
[edit accounting-options filter-profile filter_acctg_profile] user@host# set counters counter1 user@host# set counters counter2 user@host# set counters counter3
Configure a Firewall Filter That References the Accounting Profile Step-by-Step Procedure To configure a firewall filter that references the accounting profile:
1.
Create the stateless firewall filter my_firewall_filter.

[edit] user@host# edit firewall family inet filter my_firewall_filter
2.
Apply the filter-accounting profile filter_acctg_profile to the firewall filter.

[edit firewall family inet filter my_firewall_filter] user@host# set accounting-profile filter_acctg_profile
3.
Configure the first filter term and counter.

[edit firewall family inet filter my_firewall_filter] user@host# set term term1 from protocol ospf user@host# set term term1 then count counter1 user@host# set term term1 then discard
4.
Configure the second filter term and counter.

[edit firewall family inet filter my_firewall_filter] user@host# set term term2 from source-address 10.108.0.0/16 user@host# set term term2 then count counter2 user@host# set term term2 then discard
5.
Configure the third filter term and counter.

[edit firewall family inet filter my_firewall_filter] user@host# set term accept-all then count counter3 user@host# set term accept-all then accept
Apply the Firewall Filter to an Interface Step-by-Step Procedure To apply the stateless firewall filter to a logical interface:
1.
2.

3.

[edit interfaces ge-0/0/1 unit 0 family inet]
215
user@host# set filter input my_firewall_filter
Confirm Your Candidate Configuration Step-by-Step Procedure To confirm your candidate configuration:
1.
Confirm the configuration of the accounting profile by entering the show accounting-options configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit] user@host# show accounting-options filter-profile filter_acctg_profile { file ff_accounting_file; interval 60; counters { counter1; counter2; counter3; } }
2.
[edit] user@host# show firewall family inet { filter my_firewall_filter { accounting-profile filter_acctg_profile; term term1 { from { protocol ospf; } then { count counter1; discard; } } term term2 { from { source-address { 10.108.0.0/16; } } then { count counter2; discard; } } term accept-all { then { count counter3; accept;
216
} } } }
3.
[edit] user@host# show interfaces ge-0/0/1 { unit 0 { family inet { filter { input my_firewall_filter; } address 10.1.2.3/30; } } }
Clear the Counters and Commit Your Candidate Configuration Step-by-Step Procedure To clear the counters and commit your candidate configuration:
1.
From operational command mode, use the clear firewall all command to clear the statistics for all firewall filters. To clear only the counters incremented in this example, include the name of the firewall filter.
[edit] user@host> clear firewall filter my_firewall_filter
2.
Commit your candidate configuration.

Verification
To verify that the filter is applied to the logical interface, run the show interfaces command with the detail or extensive output level. To verify that the three counters are collected separately, run the show firewall filter my_firewall_filter command.
user@host> show firewall filter my_firewall_filter Filter: my_firewall_filter Counters: Name counter1 counter2
Bytes 0 0
Packets 0 0
217
counter3
Accounting for Standard Firewall Filters Overview on page 211 Statement Hierarchy for Configuring Firewall Filter Accounting Profiles on page 211 Statement Hierarchy for Applying Firewall Filter Accounting Profiles on page 212
Logging of Stateless Firewall Filter Activity

System Logging Overview on page 218 System Logging of Events Generated for the Firewall Facility on page 219 Logging of Packet Headers Evaluated by a Firewall Filter Term on page 221 Example: Configuring Logging for a Stateless Firewall Filter Term on page 222
System Logging Overview

The Junos OS generates system log messages (also called syslog messages) to record system events that occur on the device. Events consist of routine operations, failure and error conditions, and critical conditions that might require urgent resolution. This system logging utility is similar to the UNIX syslogd utility. Each Junos OS system log message belongs to a message category, called a facility, that reflects the hardware- or software-based source of the triggering event. A group of messages belonging to the same facility are either generated by the same software process or concern a similar hardware condition or user activity (such as authentication attempts). Each system log message is also preassigned a severity, which indicates how seriously the triggering event affects router functions. Together, the facility and severity of an event are known as the message priority. The content of a syslog message identifies the Junos OS process that generates the message and briefly describes the operation or error that occurred. By default, syslog messages that have a severity of info or more serious are written to the main system log file messages in the /var/log directory of the local Routing Engine. To configure global settings and facility-specific settings that override these default values, you can include statements at the [edit system syslog] hierarchy level. For all syslog facilities or for a specified facility, you can configure the syslog message utility to redirect messages of a specified severity to a specified file instead of to the main system log file. You can also configure the syslog message utility to write syslog messages of a specified severity, for all syslog facilities or for a specified facility, to additional destinations. In addition to writing syslog messages to a log file, you can write syslog messages to the terminal sessions of any logged-in users, to the router console, or to a remote host or the other Routing Engine. At the global levelfor all system logging messages, regardless of facility, severity, or destinationyou can override the default values for file-archiving properties and the default timestamp format.
218
System Logging of Events Generated for the Firewall Facility on page 219 Logging of Packet Headers Evaluated by a Firewall Filter Term on page 221 Example: Configuring Logging for a Stateless Firewall Filter Term on page 222
System Logging of Events Generated for the Firewall Facility

System log messages generated for firewall filter actions belong to the firewall facility. Just as you can for any other Junos OS system logging facility, you can direct firewall facility syslog messages to one or more specific destinations: to a specified file, to the terminal session of one or more logged in users (or to all users), to the router console, or to a remote host or the other Routing Engine on the router. When you configure a syslog message destination for firewall facility syslog messages, you include a statement at the [edit system syslog] hierarchy level, and you specify the firewall facility name together with a severity level. Messages from the firewall that are rated at the specified level or more severe are logged to the destination. System log messages with the DFWD_ prefix are generated by the firewall process (dfwd), which manages compilation and downloading of Junos OS firewall filters. System log messages with the PFE_FW_ prefix are messages about firewall filters, generated by the Packet Forwarding Engine controller, which manages packet forwarding functions. For more information, see the Junos OS System Log Messages Reference. Table 22 on page 219 lists the system log destinations you can configure for the firewall facility.
Table 22: Syslog Message Destinations for the Firewall Facility

Destination File Description
Configuring this option keeps the firewall syslog messages out of the main system log file. To include priority and facility with messages written to the file, include the explicit-priority statement. To override the default standard message format, which is based on a UNIX system log format, include the structured-data statement.
Configuration Statements
[edit] system { syslog { file filename { firewall severity; allow-duplicates; # File option archive archive-optios; # File option explicit-priority; # File option structured-data; # File option } allow-duplicates; # All destinations archive archive-options; # All files time-format (option); # Local destinations } }
When the structured-data statement is included, other statements that specify the format for messages written to the file are ignored (the explicit-priority statement at the [edit system syslog file filename] hierarchy level and the time-format statement at the [edit system syslog] hierarchy level).
219
Table 22: Syslog Message Destinations for the Firewall Facility (continued)
Destination Terminal session Description
Configuring this option causes a copy of the firewall syslog messages to be written to the specified terminal sessions. Specify one or more user names, or specify * for all logged in users.
[edit] system { syslog { user (username | *) { firewall severity; } time-format (option); # Local destinations } } [edit] system { syslog { console { firewall severity; } time-format (option); # Local destinations } } [edit] system { syslog { host (hostname | other-routing-engine) { firewall severity; allow-duplicates; # Host option archive archive-optios; # File option facility-override firewall; # Host option explicit-priority; # Host option } allow-duplicates; # All destinations archive archive-options; # All files time-format (option); # Local destinations } }
Router console
Configuring this option causes a copy of the firewall syslog messages to be written to the router console.
Remote host or the other Routing Engine
Configuring this option causes a copy of the firewall syslog messages to be written to the specified remote host or to the other Routing Engine. To override the default alternative facility for forwarding firewall syslog messages to a remote machine (local3), include the facility-override firewall statement. To include priority and facility with messages written to the file, include the explicit-priority statement.
When the structured-data statement is included, other statements that specify the format for messages written to the file are ignored (the explicit-priority statement at the [edit system syslog file filename] hierarchy level and the time-format statement at the [edit system syslog] hierarchy level).
By default, the timestamp recorded in a standard-format system log message specifies the month, date, hour, minute, and second when the message was logged, as in the example:
Sep 07 08:00:10
To include the year, the millisecond, or both in the timestamp for all system logging messages, regardless of the facility, include one of the following statement at the [edit system syslog] hierarchy level:

time-format year; time-format millisecond; time-format year millisecond;
220
The following example illustrates the format for a timestamp that includes both the millisecond (401) and the year (2010):
Sep 07 08:00:10.401.2010
System Logging Overview on page 218 Logging of Packet Headers Evaluated by a Firewall Filter Term on page 221 Example: Configuring Logging for a Stateless Firewall Filter Term on page 222 Junos OS System Logging Facilities and Message Severity Levels in the Junos OS
System Basics Configuration Guide
Junos OS System Log Configuration Hierarchy in the Junos OS System Basics

Configuration Guide
Junos OS Default System Log Settings in the Junos OS System Basics Configuration
Guide
Logging Messages in Structured-Data Format in the Junos OS System Basics

Configuration Guide
Including the Year or Millisecond in Timestamps in the Junos OS System Basics

Configuration Guide
Changing the Alternative Facility Name for Remote System Log Messages in the
Junos OS System Basics Configuration Guide
Junos OS System Log Alternate Facilities for Remote Logging in the Junos OS System
Basics Configuration Guide
Logging of Packet Headers Evaluated by a Firewall Filter Term

Built in to the stateless firewall filtering software is the capability to log packet-header information for the packets evaluated by a stateless firewall filter term. You can write the packet header information to the system log file on the local Routing Engine or to a firewall filter buffer in the Packet Forwarding Engine. Logging of packet headers evaluated by firewall filters is supported for standard stateless firewall filters for IPv4 or IPv6 traffic only. Service filters and simple filters do not support logging of packet headers. Table 23 on page 222 lists the packet-header logs you can configure for a firewall filter action.
221
Table 23: Packet-Header Logs for Stateless Firewall Filter Terms

Log Syslog message destinations configured for the firewall facility Description
Configure this option by using the syslog nonterminating action. NOTE: Packet header information is interspersed with event messages. To list log files, enter the show log operational mode command without command options. To display log file contents for a specific file in the /var/log directory on the local Routing Engine, enter the show log filename operational mode command or the file show /var/log/filename operational mode command. To clear log file contents, enter the clear log filename <all> operational mode command. If you include the all option, the specified log file is truncated, all archived versions of the log file are deleted.
firewall { family { filter filter-name { from { match-conditions; } then { ... syslog; terminating-action; } } } }
Buffer in the Packet Forwarding Engine
Configure this option by using the log nonterminating action. NOTE: Restarting the router causes the contents of this buffer to be cleared. To display the local log entries for firewall filters, enter the show firewall log operational mode command.
firewall { family { filter filter-name { from { match-conditions; } then { ... log; terminating-action; } } } }
System Logging Overview on page 218 System Logging of Events Generated for the Firewall Facility on page 219 Example: Configuring Logging for a Stateless Firewall Filter Term on page 222
Example: Configuring Logging for a Stateless Firewall Filter Term

This example shows how to configure a standard stateless firewall filter to log packet headers.

Requirements
222
Overview
In this example, you use a stateless firewall filter that logs and counts ICMP packets that have 192.168.207.222 as either their source or destination.
Configuration

Configure the Syslog Messages File for the Firewall Facility on page 223 Configure the Stateless Firewall Filter on page 223 Apply the Stateless Firewall Filter to a Logical Interface on page 224 Confirm and Commit Your Candidate Configuration on page 224
set system syslog file messages_firewall_any firewall any set system syslog file messages_firewall_any archive no-world-readable set firewall family inet filter icmp_syslog term icmp_match from address 192.168.207.222/32 set firewall family inet filter icmp_syslog term icmp_match from protocol icmp set firewall family inet filter icmp_syslog term icmp_match then count packets set firewall family inet filter icmp_syslog term icmp_match then log set firewall family inet filter icmp_syslog term icmp_match then accept set firewall family inet filter icmp_syslog term default_term then accept set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30 set interfaces ge-0/0/1 unit 0 family inet filter input icmp_syslog
Configure the Syslog Messages File for the Firewall Facility Step-by-Step Procedure To configure a syslog messages file for the firewall facility:
1.
Configure a messages file for all syslog messages generated for the firewall facility.
user@host# set system syslog file messages_firewall_any firewall any
2.
Restrict permission to the archived firewall facility syslog files to the root user and users who have the Junos OS maintenance permission.
user@host# set system syslog file messages_firewall_any archive no-world-readable
Configure the Stateless Firewall Filter Step-by-Step Procedure To configure the stateless firewall filter icmp_syslog that logs and counts ICMP packets that have 192.168.207.222 as either their source or destination:
1.
Create the stateless firewall filter icmp_syslog.

[edit]
223
user@host# edit firewall family inet filter icmp_syslog

2.
Configure matching on the ICMP protocol and an address.

[edit firewall family inet filter icmp_syslog] user@host# set term icmp_match from address 192.168.207.222/32 user@host# set term icmp_match from protocol icmp
3.
Count, log,, and accept matching packets.

[edit firewall family inet filter icmp_syslog] user@host# set term icmp_match then count packets user@host# set term icmp_match then log user@host# set term icmp_match then accept
4.
Accept all other packets.

[edit firewall family inet filter icmp_syslog] user@host# set term default_term then accept
1.
2.

3.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set filter input icmp_syslog
1.
Confirm the configuration of the syslog message file for the firewall facility by entering the show system configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit] user@host# show system syslog { file messages_firewall_any { firewall any; archive no-world-readable; } }
224
2.
[edit] user@host# show firewall family inet { filter icmp_syslog { term icmp_match { from { address { 192.168.207.222/32; } protocol icmp; } then { count packets; log; accept; } } term default_term { then accept; } } }
3.
[edit] user@host# show interfaces ge-0/0/1 { unit 0 { family inet { filter { input icmp_syslog; } address 10.1.2.3/30; } } }
4.
Verification
To confirm that the configuration is working properly, enter the show log filter command:
user@host> show log messages_firewall_any Mar 20 08:03:11 hostname feb FW: so-0/1/0.0 192.168.207.223 0 0 (1 packets) A icmp 192.168.207.222
225
This output file contains the following fields:
Date and TimeDate and time at which the packet was received (not shown in the
default).
Filter action:

AAccept (or next term) DDiscard RReject
ProtocolPackets protocol name or number. Source addressSource IP address in the packet. Destination addressDestination IP address in the packet.
NOTE: If the protocol is ICMP, the ICMP type and code are displayed. For all other protocols, 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 indicates that only one packet for this match has been detected in about a 1-second interval. If packets arrive faster, the system log function compresses the information so that less output is generated, and displays an output similar to the following:
user@host> show log filter Mar 20 08:08:45 hostname feb FW: so-0/1/0.0 192.168.207.223 0 0 (515 packets) A icmp 192.168.207.222
System Logging Overview on page 218 Logging of Packet Headers Evaluated by a Firewall Filter Term on page 221 System log messages with the DFWD_ prefix, described in the Junos OS System Log
Messages Reference
System log messages with the PFE_FW_* prefix, described in the Junos OS System Log
Messages Reference
226
CHAPTER 6
Service Filter Configuration

Service Filter Overview on page 227 How Service Filters Evaluate Packets on page 228 Guidelines for Configuring Service Filters on page 230 Guidelines for Applying Service Filters on page 232 Service Filter Match Conditions and Actions on page 235 Example: Configuring and Applying Service Filters on page 242
Service Filter Overview


Services on page 227 Service Rules on page 227 Service Rule Refinement on page 228 Service Filter Counters on page 228
Services
The Adaptive Services Physical Interface Cards (PICs), Multiservices PICs, and Multiservices Dense Port Concentrators (DPCs) provide adaptive services interfaces. Adaptive services interfaces enable you to coordinate a special range of services on a single PIC or DPC by configuring a set of services and applications.
NOTE: Service filters are not supported on J Series devices and Branch SRX devices.
Service Rules
A service set is an optional definition you can apply to the traffic at an adaptive services interface. A service set enables you to configure combinations of directional rules and default settings that control the behavior of each service in the service set.
227
Service Rule Refinement

When you apply a service set to the traffic at an adaptive services interface, you can optionally use service filters to refine the target of the set of services and also to process traffic. Service filters enable you to manipulate traffic by performing packet filtering to a defined set of services on an adaptive services interface before the traffic is delivered to its destination. You can apply a service filter to traffic before packets are accepted for input or output service processing or after packets return from input service processing.
Service Filter Counters

Like standard firewall filters, service filters support counting of matched packets. When you display counters for a service filter, however, the syntax for specifying the filter name includes the name of the service set to which the service filter is applied.
To enable counting of the packets matched by a service filter term, specify the count counter-name nonterminating action in that term. To display counters for service filters, use the show firewall filter filter-name <counter counter-name> operational mode command, and specify the filter-name as follows:
__service-service-set-name:service-filter-name
For example, suppose you configure a service filter named out_filter with a counter named out_counter and apply that service filter to a logical interface to direct certain packets for processing by the output services associated with the service set nat_set. In this scenario, the syntax for using the show firewall operational mode command to display the counter is as follows:
[edit] user@host> show firewall filter __service-nat_set:out_filter counter out_counter
Stateless Firewall Filter Types on page 6 How Service Filters Evaluate Packets on page 228 Guidelines for Configuring Service Filters on page 230 Guidelines for Applying Service Filters on page 232 Example: Configuring and Applying Service Filters on page 242 Adaptive Services Overview in the Junos OS Services Interfaces Configuration Guide Configuring Service Sets to be Applied to Services Interfaces in the Junos OS Services
Interfaces Configuration Guide
Configuring Service Rules in the Junos OS Services Interfaces Configuration Guide
How Service Filters Evaluate Packets


Service Filters That Contain a Single Term on page 229 Service Filters That Contain Multiple Terms on page 229
228
Chapter 6: Service Filter Configuration
Service Filter Terms That Do Not Contain Any Match Conditions on page 229 Service Filter Terms That Do Not Contain Any Actions on page 229 Service Filter Default Action on page 229
Service Filters That Contain a Single Term

For a service filter that consists of a single term, the policy framework software evaluates a packet as follows:

If the packet matches all the conditions, the actions are taken. If the packet matches all the conditions and no actions are specified, the packet is accepted. If the packet does not match all the conditions, it is discarded.
Service Filters That Contain Multiple Terms

For a service filter that consists of multiple terms, the policy framework software evaluates a packet against the terms in the filter sequentially, beginning with the first term in the filter, until either the packet matches all the conditions in one of the terms or there are no more terms in the filter.
If the packet matches all the conditions in a term, the actions in that term are performed and evaluation of the packet ends at that term. Any subsequent terms in the filter are not used. If the packet does not match all the conditions in the term, evaluation of the packet proceeds to the next term in the filter.
Service Filter Terms That Do Not Contain Any Match Conditions

For service filters with a single term and for filters with multiple terms, if a term does not contain any match conditions, the actions are taken on any packet evaluated.
Service Filter Terms That Do Not Contain Any Actions

If a term does not contain any actions, and if the packet matches the conditions in the term, the packet is accepted.
Service Filter Default Action

Each service filter has an implicit skip action at the end of the filter, which is equivalent to including the following example term explicit_skip as the final term in the service filter:
term explicit_skip { then skip; }
By default, if a packet matches none of the terms in a service filter, the packet bypasses service processing. Related Documentation
Service Filter Overview on page 227
229
Guidelines for Configuring Service Filters on page 230 Guidelines for Applying Service Filters on page 232 Example: Configuring and Applying Service Filters on page 242
Guidelines for Configuring Service Filters


Statement Hierarchy for Configuring Service Filters on page 230 Service Filter Protocol Families on page 230 Service Filter Names on page 230 Service Filter Terms on page 231 Service Filter Match Conditions on page 231 Service Filter Terminating Actions on page 231
Statement Hierarchy for Configuring Service Filters

To configure a service filter, include the service-filter service-filter-name statement at the [edit firewall family (inet | inet6)] hierarchy level:
[edit] firewall { family (inet | inet6) { service-filter service-filter-name { term term-name { from { match-conditions; } then { actions; } } } } }
Individual statements supported under the service-filter service-filter-name statement are described separately in this topic and are illustrated in the example of configuring and applying a service filter.
Service Filter Protocol Families

You can configure service filters to filter IPv4 traffic (family inet) and IPv6 traffic (family inet6) only. No other protocol families are supported for service filters.
Service Filter Names

Under the family inet or family inet6 statement, you can include service-filter service-filter-name statements to create and name service filters. The filter name can
230
contain letters, numbers, and hyphens (-) and be up to 64 characters long. To include spaces in the name, enclose the entire name in quotation marks ( ).
Service Filter Terms

Under the service-filter service-filter-name statement, you can include term term-name statements to create and name filter terms.

Service Filter Match Conditions

Service filter terms support only a subset of the IPv4 and IPv6 match conditions that are supported for standard stateless firewall filters. If you specify an IPv6 address in a match condition (the address, destination-address, or source-address match conditions), use the syntax for text representations described in RFC 2373, IP Version 6 Addressing Architecture. For more information about IPv6 addresses, see IPv6 Overview and IPv6 Standards in the Junos OS Routing Protocols Configuration Guide.
Service Filter Terminating Actions

When configuring a service filter term, you must specify one of the following filter-terminating actions:

service skip
NOTE: These actions are unique to service filters.
Service filter terms support only a subset of the IPv4 and IPv6 nonterminating actions that are supported for standard stateless firewall filters:

count counter-name log port-mirror sample
Service filters do not support the next action.
231
Service Filter Overview on page 227 How Service Filters Evaluate Packets on page 228 Guidelines for Applying Service Filters on page 232 Service Filter Match Conditions for IPv4 or IPv6 Traffic on page 235 Service Filter Terminating Actions on page 241 Service Filter Nonterminating Actions on page 241 Example: Configuring and Applying Service Filters on page 242
Guidelines for Applying Service Filters


Restrictions for Adaptive Services Interfaces on page 232 Statement Hierarchy for Applying Service Filters on page 232 Associating Service Rules with Adaptive Services Interfaces on page 233 Filtering Traffic Before Accepting Packets for Service Processing on page 233 Postservice Filtering of Returning Service Traffic on page 234
Restrictions for Adaptive Services Interfaces

The following restrictions apply to adaptive services interfaces and service filters.
Adaptive Services Interfaces

You can apply a service filter to IPv4 or IPv6 traffic associated with a service set at an adaptive services interface only. Adaptive services interfaces are supported for the following hardware only:

Adaptive Services (AS) PICs on M Series and T Series routers Multiservices (MS) PICs on M Series and T Series routers Multiservices (MS) DPCs on MX Series routers
System Logging to a Remote Host from M Series Routers

Logging of adaptive services interfaces messages to an external server by means of the fxp0 or em0 port is not supported on M Series routers. The architecture does not support system logging traffic out of a management interface. Instead, access to an external server is supported on a Packet Forwarding Engine interface.
Statement Hierarchy for Applying Service Filters

You can enable packet filtering of IPv4 or IPv6 traffic before a packet is accepted for input or output service processing. To do this, apply a service filter to the adaptive services interface input or output in conjunction with an interface service set.
232
You can also enable packet filtering of IPv4 or IPv6 traffic that is returning to the Packet Forwarding Engine after input service processing completes. To do this, apply a post-service filter to the adaptive services interface input. The following configuration shows the hierarchy levels at which you can apply the service filters to adaptive services interfaces:
[edit] interfaces { interface-name { unit unit-number { family (inet | inet6) { service { input { service-set service-set-name service-filter service-filter-name; post-service-filter service-filter-name; } output { service-set service-set-name service-filter service-filter-name; } } } } } }
Associating Service Rules with Adaptive Services Interfaces

To define and group the service rules be applied to an adaptive services interface, you define an interface service set by including the service-set service-set-name statement at the [edit services] hierarchy level. To apply an interface service set to the input and output of an adaptive services interface, you include the service-set service-set-name at the following hierarchy levels:

[edit interfaces interface-name unit unit-number input] [edit interfaces interface-name unit unit-number output]
If you apply a service set to one direction of an adaptive services interface but do not apply a service set to the other direction, an error occurs when you commit the configuration. The adaptive services PIC performs different actions depending on whether the packet is sent to the PIC for input service or for output service. For example, you can configure a single service set to perform Network Address Translation (NAT) in one direction and destination NAT (dNAT) in the other direction.
Filtering Traffic Before Accepting Packets for Service Processing

To filter IPv4 or IPv6 traffic before accepting packets for input or output service processing, include the service-set service-set-name service-filter service-filter-name at one of the following interfaces:
[edit interfaces interface-name unit unit-number family (inet | inet6) service input]
233
[edit interfaces interface-name unit unit-number family (inet | inet6) service output]
For the service-set-name, specify a service set configured at the [edit services service-set] hierarchy level. The service set retains the input interface information even after services are applied, so that functions such as filter-class forwarding and destination class usage (DCU) that depend on input interface information continue to work. The following requirements apply to filtering inbound or outbound traffic before accepting packets for service processing:

You configure the same service set on the input and output sides of the interface. If you include the service-set statement without an optional service-filter definition, the Junos OS assumes the match condition is true and selects the service set for processing automatically. The service filter is applied only if a service set is configured and selected.
You can include more than one service set definition on each side of an interface. The following guidelines apply:
If you include multiple service sets, the router software evaluates them in the order in which they appear in the configuration. The system executes the first service set for which it finds a match in the service filter and ignores the subsequent definitions. A maximum of six service sets can be applied to an interface. When you apply multiple service sets to an interface, you must also configure and apply a service filter to the interface.
Postservice Filtering of Returning Service Traffic

As an option to filtering of IPv4 or IPv6 input service traffic, you can apply a service filter to IPv4 or IPv6 traffic that is returning to the services interface after the service set is executed. To apply a service filter in this manner, include the post-service-filter service-filter-name statement at the [edit interfaces interface-name unit unit-number family (inet | inet6) service input] hierarchy level.
Service Filter Overview on page 227 How Service Filters Evaluate Packets on page 228 Guidelines for Configuring Service Filters on page 230 Example: Configuring and Applying Service Filters on page 242 Adaptive Services Overview in the Junos OS Services Interfaces Configuration Guide Configuring Service Sets to be Applied to Services Interfaces in the Junos OS Services
Interfaces Configuration Guide
Configuring Service Rules in the Junos OS Services Interfaces Configuration Guide
234
Service Filter Match Conditions and Actions

Service Filter Match Conditions for IPv4 or IPv6 Traffic on page 235 Service Filter Terminating Actions on page 241 Service Filter Nonterminating Actions on page 241
Service Filter Match Conditions for IPv4 or IPv6 Traffic

Service filters support only a subset of the stateless firewall filter match conditions for IPv4 and IPv6 traffic. Table 24 on page 235 describess the service filter match conditions.
Table 24: Service Filter Match Conditions for IPv4 or IPv6 Traffic
Match Condition
address address address address except ah-spi spi-value
Description
Match the IP source or destination address field. Do not match the IP source or destination address field.
Protocol Families
family inet family inet family inet6 family inet6
(M Series routers, except M120 and M320) Match on the IPsec authentication header (AH) security parameter index (SPI) value. (M Series routers, except M120 and M320) Do not match on the IPsec AH SPI value. Match the IP destination address field. You cannot specify both the address and destination-address match conditions in the same term.
family inet
ah-spi-except spi-value destination-address address
family inet
family inet
family inet6
destination-address address address
Do not match the IP destination address field. You cannot specify both the address and destination-address match conditions in the same term.
family inet
family inet6
235
Table 24: Service Filter Match Conditions for IPv4 or IPv6 Traffic (continued)
Match Condition
Description
Match the UDP or TCP destination port field. You cannot specify both the port and destination-port match conditions in the same term. If you configure this match condition for IPv4 traffic, we recommend that you also configure the protocol udp or protocol tcp match statement in the same term to specify which protocol is being used on the port. If you configure this match condition for IPv6 traffic, we recommend that you also configure the next-header udp or next-header tcp match condition in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are 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), ldp (646), 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 (49), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
Protocol Families
destination-port-except number destination-prefix-list name esp-spi value
Do not match the UDP or TCP destination port field. For details, see the destination-port match description. Match the list of destination prefixes. The prefix list is defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. Match the IPsec encapsulating security payload (ESP) SPI value. Specify a single value or a range of values. You can specify a value in hexadecimal, binary, or decimal form. To specify the value in hexadecimal form, include 0x as a prefix. To specify the value in binary form, include b as a prefix. Do not match the IPsec ESP SPI value or range of values. For details, see the esp-spi match condition. Match if the packet is the first fragment of a fragmented packet. Do not match if the packet is a trailing fragment of a fragmented packet. The first fragment of a fragmented packet has a fragment offset value of 0. This match condition is an alias for the bit-field match condition fragment-offset 0 match condition. To match both first and trailing fragments, you can use two terms that specify different match conditions: first-fragment and is-fragment.
family inet
family inet6
family inet
family inet6
family inet
family inet6
esp-spi-except value
family inet
family inet6
first-fragment
family inet
236
Match Condition
fragment-flags number
Description
(Ingress only) Match the three-bit IP fragmentation flags field in the IP header. In place of the numeric field value, you can specify one of the following keywords (the field values are also listed): dont-fragment (0x4), more-fragments (0x2), or reserved (0x8).
Protocol Families
family inet
fragment-offset number
Match the 13-bit fragment offset field in the IP header. The value is the offset, in 8-byte units, in the overall datagram message to the data fragment. Specify a numeric value, a range of values, or a set of values. An offset value of 0 indicates the first fragment of a fragmented packet. The first-fragment match condition is an alias for the fragment-offset 0 match condition. To match both first and trailing fragments, you can use two terms that specify different match conditions (first-fragment and is-fragment).
family inet
fragment-offset-except number interface-group group-number
Do not match the 13-bit fragment offset field.
family inet
Match the interface group (set of one or more logical interfaces) on which the packet was received. For group-number, specify a value from 0 through 255. For information about configuring interface groups, see Filtering Packets Received on a Set of Interface Groups Overview on page 185.
family inet
family inet6
interface-group-except group-number
Do not match the interface group on which the packet was received. for details, see the interface-group match condition.
family inet
family inet6
237
Match Condition
ip-options values
Description
Match the 8-bit IP option field, if present, to the specified value or list of values. In place of a numeric value, you can specify one of the following text synonyms (the option values are also listed): loose-source-route (131), record-route (7), router-alert (148), security (130), stream-id (136), strict-source-route (137), or timestamp (68). To match any value for the IP option, use the text synonym any. To match on multiple values, specify the list of values within square brackets ('[ and ']). To match a range of values, use the value specification [ value1-value2 ]. For example, the match condition ip-options [ 0-147 ] matches on an IP options field that contains the loose-source-route, record-route, or security values, or any other value from 0 through 147. However, this match condition does not match on an IP options field that contains only the router-alert value (148). For most interfaces, a filter term that specifies an ip-option match on one or more specific IP option values (a value other than any) causes packets to be sent to the Routing Engine so that the kernel can parse the IP option field in the packet header.
Protocol Families
family inet
For a firewall filter term that specifies an ip-option match on one or more specific IP option values, you cannot specify the count, log, or syslog nonterminating actions unless you also specify the discard terminating action in the same term. This behavior prevents double-counting of packets for a filter applied to a transit interface on the router. Packets processed on the kernel might be dropped in case of a system bottleneck. To ensure that matched packets are instead sent to the Packet Forwarding Engine (where packet processing is implemented in hardware), use the ip-options any match condition.
The 10-Gigabit Ethernet Modular Port Concentrator (MPC), 60-Gigabit Ethernet MPC, 60-Gigabit Queuing Ethernet MPC, and 60-Gigabit Ethernet Enhanced Queuing MPC on MX Series routers are capable of parsing the IP option field of the IPv4 packet header. For interfaces configured on those MPCs, all packets that are matched using the ip-options match condition are sent to the Packet Forwarding Engine for processing.
ip-options-except values is-fragment
Do not match the IP option field to the specified value or list of values. For details about specifying the values, see the ip-options match condition. Match if the packet is a trailing fragment of a fragmented packet. Do not match the first fragment of a fragmented packet. This match condition is an alias for the bit-field match condition fragment-offset 0 except bits. NOTE: To match both first and trailing fragments, you can use two terms that specify different match conditions (first-fragment and is-fragment).
family inet
family inet
238
Match Condition
port number
Description
Match the UDP or TCP source or destination port field. If you configure this match condition, you cannot configure the destination-port match condition or the source-port match condition in the same term. If you configure this match condition for IPv4 traffic, we recommend that you also configure the protocol udp or protoco tcp match statement in the same term to specify which protocol is being used on the port. If you configure this match condition for IPv6 traffic, we recommend that you also configure the next-header udp or next-header tcp match condition in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the text synonyms listed under destination-port.
Protocol Families
port-except number
Do not match the UDP or TCP source or destination port field. For details, see the port match condition. Match the prefixes of the source or destination address fields to the prefixes in the specified list. The prefix list is defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. Match the IP protocol type field. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), dstopts (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112).
family inet
family inet6
prefix-list prefix-list-name
family inet
family inet6
protocol number
family inet
protocol-except number source-address address
Do not match the IP protocol type field. For details, see the protocol match condition. Match the IP source address. You cannot specify both the address and source-address match conditions in the same term.
family inet
family inet
family inet6
source-address address except
Do not match the IP source address. You cannot specify both the address and source-address match conditions in the same term.
family inet
family inet6
239
Match Condition
source-port number
Description
Match the UDP or TCP source port field. You cannot specify the port and source-port match conditions in the same term. If you configure this match condition for IPv4 traffic, we recommend that you also configure the protocol udp or protocol tcp match statement in the same term to specify which protocol is being used on the port. If you configure this match condition for IPv6 traffic, we recommend that you also configure the next-header udp or next-header tcp match condition in the same term to specify which protocol is being used on the port. In place of the numeric value, you can specify one of the text synonyms listed with the destination-port number match condition.
Protocol Families
Do not match the UDP or TCP source port field. For details, see the source-port match condition. Match source prefixes in the specified list. Specify the name of a prefix list defined at the [edit policy-options prefix-list prefix-list-name] hierarchy level. Match one or more of the low-order 6 bits in the 8-bit TCP flags field in the TCP header. To specify individual bit fields, you can specify the following text synonyms or hexadecimal values:

family inet
family inet6
family inet
family inet6
tcp-flags value
family inet
family inet6
In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all packets sent after the initial packet. You can string together multiple flags using the bit-field logical operators. For combined bit-field match conditions, see the tcp-established and tcp-initial match conditions. If you configure this match condition for IPv4 traffic, we recommend that you also configure the protocol tcp match statement in the same term to specify that the TCP protocol is being used on the port. If you configure this match condition for IPv6 traffic, we recommend that you also configure the next-header tcp match condition in the same term to specify that the TCP protocol is being used on the port.
240
NOTE: If you specify an IPv6 address in a match condition (the address, destination-address, or source-address match conditions), use the syntax for text representations described in RFC 2373, IP Version 6 Addressing Architecture. For more information about IPv6 addresses, see IPv6 Overview and IPv6 Standards in the Junos OS Routing Protocols Configuration Guide.
Service Filter Overview on page 227 Guidelines for Configuring Service Filters on page 230 Example: Configuring and Applying Service Filters on page 242 Service Filter Terminating Actions on page 241 Service Filter Nonterminating Actions on page 241
Service Filter Terminating Actions

Service filters support different sets of terminating actions than standard stateless firewall filters or simple filters.
NOTE: Service filters do not support the next term action.
Table 25 on page 241 describes the terminating actions you can configure in a service filter term.
Table 25: Terminating Actions for Service Filters

Terminating Action
service
Description
Direct the packet to service processing.
Protocol Families

inet inet6 inet inet6
skip
Let the packet bypass service processing.
Service Filter Overview on page 227 Guidelines for Configuring Service Filters on page 230 Example: Configuring and Applying Service Filters on page 242 Service Filter Match Conditions for IPv4 or IPv6 Traffic on page 235 Service Filter Nonterminating Actions on page 241
Service Filter Nonterminating Actions

Service filters support different sets of terminating actions for each protocol family.
241
NOTE: Service filters do not support the next term action.
Table 26 on page 242 describes the nonterminating actions you can configure in a service filter term.
Table 26: Nonterminating Actions for Service Filters

count counter-name
Description
Count the packet in the named counter.
Protocol Families

log
Log the packet header information in a buffer within the Packet Forwarding Engine. You can access this information by issuing the show firewall log command at the command-line interface (CLI). Port-mirror the packet based on the specified family. Supported on M120 routers, M320 routers configured with Enhanced III FPCs, and MX Series routers only. Sample the packet.
port-mirror
sample
Service Filter Overview on page 227 Guidelines for Configuring Service Filters on page 230 Example: Configuring and Applying Service Filters on page 242 Service Filter Match Conditions for IPv4 or IPv6 Traffic on page 235 Service Filter Terminating Actions on page 241
Example: Configuring and Applying Service Filters

This example shows how to configure and apply service filters.

Requirements
This example use the logical interface xe-0/1/0.0 on any of the following hardware components:

Adaptive Services (AS) PIC on an M Series or T Series router Multiservices (MS) PIC on an M Series or T Series router
242
Multiservices (MS) DPC on an MX Series router
Before you begin, make sure that you have:
Installed your supported router and PICs or DPCs and performed the initial router configuration. Configured basic Ethernet in the topology, and verified that traffic is flowing in the topology and that IPv4 traffic is flowing through logical interface xe-0/1/0.0. Configured the service set vrf_svcs with service input and output rules and default settings for services at a service interface.
For guidelines for configuring service sets, see Configuring Service Sets to be Applied to Services Interfaces in the Junos OS Services Interfaces Configuration Guide.
Overview
In this example, you create three types of service filters for IPv4 traffic: one input service filter, one postservice input filter, and one output service filter.
Topology
You apply the input service filter and postservice input filter to input traffic at logical interface xe-0/1/0.0, and you apply the output service filter to the output traffic at the same logical interface.
Filtering IPv4 traffic before it is accepted for input service processingAt logical interface xe-0/1/0.0, you use the service filter in_filter_presvc to filter IPv4 input traffic before the traffic can be accepted for processing by services associated with service set vrf_svcs. The in_filter_presvc service filter counts packets sent from ICMP port 179, directs these packets to the input services associated with the service set vrf_svcs, and discards all other packets. Filtering IPv4 traffic after it has completed input service processingAt logical interface xe-0/1/0.0, you use the service filter in_filter_postsvc to filter traffic that is returning to the services interface after the input service set in_filter_presvc is executed. The in_filter_postsvc service filter counts packets sent from ICMP port 179 and then discards them. Filtering IPv4 traffic before it is accepted for output service processingAt logical interface xe-0/1/0.0, you use the service-filter out_filter_presvc to filter IPv4 output traffic before the traffic can be accepted for processing by the services associated with service set vrf_svcs. The out_filter_presvc service filter counts packets destined for TCP port 179 and then directs the packets to the output services associated with the service set vrf_svcs.
Configuration
243

Configuring the Three Service Filters on page 244 Applying the Three Service Filters on page 246
set firewall family inet service-filter in_filter_presvc term t1 from protocol tcp set firewall family inet service-filter in_filter_presvc term t1 from source-port bgp set firewall family inet service-filter in_filter_presvc term t1 then count svc_in_pkts set firewall family inet service-filter in_filter_presvc term t1 then service set firewall family inet service-filter in_filter_postsvc term t2 from protocol tcp set firewall family inet service-filter in_filter_postsvc term t2 from source-port bgp set firewall family inet service-filter in_filter_postsvc term t2 then count svc_in_pkts_rtn set firewall family inet service-filter in_filter_postsvc term t2 then skip set firewall family inet service-filter out_filter_presvc term t3 from protocol icmp set firewall family inet service-filter out_filter_presvc term t3 from destination-port bgp set firewall family inet service-filter out_filter_presvc term t3 then count svc_out_pkts set firewall family inet service-filter out_filter_presvc term t3 then service set interfaces xe-0/1/0 unit 0 family inet service input service-set vrf_svcs service-filter in_filter_presvc set interfaces xe-0/1/0 unit 0 family inet service input post-service-filter in_filter_postsvc set interfaces xe-0/1/0 unit 0 family inet service output service-set vrf_svcs service-filter out_filter_presvc
Configuring the Three Service Filters

Step-by-Step Procedure To configure the three service filters:
1.
Configure the input service filter.

[edit] user@host# edit firewall family inet service-filter in_filter_presvc [edit firewall family inet service-filter in_filter_presvc] user@host# set term t1 from protocol tcp user@host# set term t1 from source-port bgp user@host# set term t1 then count svc_in_pkts user@host# set term t1 then service
2.
Configure the postservice input filter.

[edit] user@host# edit firewall family inet service-filter in_filter_postsvc [edit firewall family inet service-filter in_filter_postsvc] user@host# set term t2 from protocol tcp user@host# set term t2 from source-port bgp user@host# set term t2 then count svc_in_pkts_rtn user@host# set term t2 then skip
3.
Configure the output service filter.

[edit] user@host# edit firewall family inet service-filter out_filter_presvc
244
[edit firewall family inet service-filter out_filter_presvc] user@host# set term t3 from protocol icmp user@host# set term t3 from destination-port bgp user@host# set term t3 then count svc_out_pkts user@host# set term t3 then service
Results
Confirm the configuration of the input and output service filters and the postservice input filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall family inet { service-filter in_filter_presvc { term t1 { from { protocol tcp; source-port bgp; } then { count svc_in_pkts; service; } } } service-filter in_filter_postsvc { term t2 { from { protocol tcp; source-port bgp; } then { count svc_in_pkts_rtn; skip; } } } service-filter out_filter_presvc { term t3 { from { protocol icmp; destination-port bgp; } then { count svc_out_pkts; service; } } } }
245
Applying the Three Service Filters

Step-by-Step Procedure To apply the three service filters:
1.
Access the IPv4 protocol on the input interface xe-0/1/0.0.

[edit] user@host# edit interfaces xe-0/1/0 unit 0 family inet
2.
Apply the input service filter and the postservice input filter.
[edit interfaces xe-0/1/0 unit 0 family inet] user@host# set service input service-set vrf_svcs service-filter in_filter_presvc user@host# set service input post-service-filter in_filter_postsvc user@host# set service output service-set vrf_svcs service-filter out_filter_presvc
Results
[edit] user@host# show interfaces xe-0/1/0 { unit 0 { family inet { service { input { service-set vrf_svcs service-filter in_filter_presvc; post-service-filter in_filter_postsvc; } output { service-set vrf_svcs service-filter out_filter_presvc; } } } } }
Verification

Verifying That Inbound Traffic Is Filtered Before Input Service on page 246 Verifying That Inbound Traffic Is Filtered After Input Service Processing on page 247 Verifying That Outbound Traffic Is Filtered Before Output Service Processing on page 247
Verifying That Inbound Traffic Is Filtered Before Input Service

Purpose Verify that inbound packets sent from TCP port 179 are sent for processing by the input services associated with the service set vrf_svcs.
246
Action
Display the count of packets sent for processing by the input services associated with the service set vrf_svcs.
[edit] user@host> show firewall filter in_filter_presvc-vrf_svcs counter svc_in_pkts
Verifying That Inbound Traffic Is Filtered After Input Service Processing

Purpose Verify that inbound packets sent from TCP port 179 are returned from processing by the input services associated with the service set vrf_svcs. Display the count of packets returned from processing by the input services associated with the service set vrf_svcs.
[edit] user@host> show firewall filter in_filter_postsvc-vrf_svcs counter svc_in_pkts_rtn
Action
Verifying That Outbound Traffic Is Filtered Before Output Service Processing

Purpose Verify that outbound packets sent to ICMP port 179 are sent for processing by the output services associated with the service set vrf_svcs. Display the count of packets sent for processing by the output services associated with the service set vrf_svcs.
[edit] user@host> show firewall filter out_filter_presvc-vrf_svcs counter svc_out_pkts
Action
Service Filter Overview on page 227 How Service Filters Evaluate Packets on page 228 Guidelines for Configuring Service Filters on page 230 Guidelines for Applying Service Filters on page 232
247
248
CHAPTER 7
Simple Filter Configuration

Simple Filter Overview on page 249 How Simple Filters Evaluate Packets on page 249 Guidelines for Configuring Simple Filters on page 251 Guidelines for Applying Simple Filters on page 254 Example: Configuring and Applying a Simple Filter on page 255
Simple Filter Overview

Simple filters are supported on Gigabit Ethernet intelligent queuing 2 (IQ2) and Enhanced Queuing Dense Port Concentrator (DPC) interfaces only. Simple filters are recommended for metropolitan Ethernet applications. Related Documentation

How Simple Filters Evaluate Packets on page 249 Guidelines for Configuring Simple Filters on page 251 Guidelines for Applying Simple Filters on page 254 Example: Configuring and Applying a Simple Filter on page 255
How Simple Filters Evaluate Packets


Simple Filters That Contain a Single Term on page 249 Simple Filters That Contain Multiple Terms on page 250 Simple Filter Terms That Do Not Contain Any Match Conditions on page 250 Simple Filter Terms That Do Not Contain Any Actions on page 250 Simple Filter Default Action on page 250
Simple Filters That Contain a Single Term

For a simple filter that consists of a single term, the policy framework software evaluates a packet as follows:
If the packet matches all the conditions, the actions are taken.
249
If the packet matches all the conditions and no actions are specified, the packet is accepted. If the packet does not match all the conditions, it is discarded.
Simple Filters That Contain Multiple Terms

For a simple filter that consists of multiple terms, the policy framework software evaluates a packet against the terms in the filter sequentially, beginning with the first term in the filter, until either the packet matches all the conditions in one of the terms or there are no more terms in the filter.
If the packet matches all the conditions in a term, the actions in that term are performed and evaluation of the packet ends at that term. Any subsequent terms in the filter are not used. If the packet does not match all the conditions in the term, evaluation of the packet proceeds to the next term in the filter.
Simple Filter Terms That Do Not Contain Any Match Conditions

For simple filters with a single term and for filters with multiple terms, if a term does not contain any match conditions, the actions are taken on any packet evaluated.
Simple Filter Terms That Do Not Contain Any Actions

If a simple filter term does not contain any actions, and if the packet matches the conditions in the term, the packet is accepted.
Simple Filter Default Action

Each simple filter has an implicit discard action at the end of the filter, which is equivalent to including the following example term explicit_discard as the final term in the simple filter:
term explicit_discard { then discard; }
By default, if a packet matches none of the terms in a simple filter, the packet is discarded. Related Documentation

Simple Filter Overview on page 249 Guidelines for Configuring Simple Filters on page 251 Guidelines for Applying Simple Filters on page 254 Example: Configuring and Applying a Simple Filter on page 255
250
Chapter 7: Simple Filter Configuration
Guidelines for Configuring Simple Filters


Statement Hierarchy for Configuring Simple Filters on page 251 Simple Filter Protocol Families on page 251 Simple Filter Names on page 251 Simple Filter Terms on page 252 Simple Filter Match Conditions on page 252 Simple Filter Terminating Actions on page 253 Simple Filter Nonterminating Actions on page 253
Statement Hierarchy for Configuring Simple Filters

To configure a simple filter, include the simple-filter simple-filter-name statement at the [edit firewall family inet] hierarchy level.
[edit] firewall { family inet { simple-filter simple-filter-name { term term-name { from { match-conditions; } then { actions; } } } } }
Individual statements supported under the simple-filter simple-filter-name statement are described separately in this topic and are illustrated in the example of configuring and applying a simple filter.
Simple Filter Protocol Families

You can configure simple filters to filter IPv4 traffic (family inet) only. No other protocol family is supported for simple filters.
Simple Filter Names

Under the family inet statement, you can include simple-filter simple-filter-name statements to create and name simple filters. The filter name can contain letters, numbers, and hyphens (-) and be up to 64 characters long. To include spaces in the name, enclose the entire name in quotation marks ( ).
251
Simple Filter Terms

Under the simple-filter simple-filter-name statement, you can include term term-name statements to create and name filter terms.

Simple filters do not support the next term action.
Simple Filter Match Conditions

Simple filter terms support only a subset of the IPv4 match conditions that are supported for standard stateless firewall filters. Unlike standard stateless firewall filters, the following restrictions apply to simple filters:
On MX Series routers with the Enhanced Queuing DPC, simple filters do not support the forwarding- class match condition. Simple filters support only one source-address and one destination-address prefix for each filter term. If you configure multiple prefixes, only the last one is used. Simple filters do not support multiple source addresses and destination addresses in a single term. If you configure multiple addresses, only the last one is used. Simple filters do not support negated match conditions, such as the protocol-except match condition or the exception keyword. Simple filters support a range of values for source-port and destination-port match conditions only. For example, you can configure source-port 400-500 or destination-port 600-700. Simple filters do not support noncontiguous mask values.
Table 27 on page 252 lists the simple filter match conditions.
Table 27: Simple Filter Match Conditions

Match Condition
destination-address destination-address
Description
Match IP destination address.
252
Table 27: Simple Filter Match Conditions (continued)

Match Condition
Description
TCP or UDP destination port field. If you configure this match condition, we recommend that you also configure the protocol match statement to determine which protocol is being used on the port. In place of the numeric value, you can specify one of the following text aliases (the port numbers are 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), or xdmcp (177).
protocol number
IP protocol field. In place of the numeric value, you can specify one of the following text aliases (the field values are also listed): ah (51), dstopts (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112). Match the IP source address.
source-address ip-source-address source-port number
Match the UDP or TCP source port field. If you configure this match condition, we recommend that you also configure the protocol match statement to determine which protocol is being used on the port. In place of the numeric field, you can specify one of the text aliases listed for destination-port.
Simple Filter Terminating Actions

Simple filters do not support explicitly configurable terminating actions, such as accept, reject, and discard. Terms configured in a simple filter always accept packets. Simple filters do not support the next action.
Simple Filter Nonterminating Actions

Simple filters support only the following nonterminating actions:
forwarding-class (forwarding-class | assured-forwarding |best-effort | expedited-forwarding | network-control)
253
NOTE: On the MX Series routers with the Enhanced Queuing DPC, the forwarding class is not supported as a from match condition.
loss-priority (high | low | medium-high | medium-low)
Simple filters do not support actions that 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 the system log functionality). Related Documentation

Simple Filter Overview on page 249 How Simple Filters Evaluate Packets on page 249 Guidelines for Applying Simple Filters on page 254 Example: Configuring and Applying a Simple Filter on page 255
Guidelines for Applying Simple Filters


Statement Hierarchy for Applying Simple Filters on page 254 Restrictions for Applying Simple Filters on page 254
Statement Hierarchy for Applying Simple Filters

You can apply a simple filter to the IPv4 ingress traffic at a logical interface by including the simple-filter input simple-filter-name statement at the [edit interfaces interface-name unit unit-number family inet] hierarchy level.
[edit] interfaces { interface-name { unit logical-unit-number { family inet { simple-filter { input filter-name; } } } } }
Restrictions for Applying Simple Filters

You can apply a simple filter to the ingress IPv4 traffic at a logical interface configured on the following hardware only:
Gigabit Ethernet intelligent queuing (IQ2) PICs installed on M120, M320, or T Series routers. Enhanced Queuing Dense Port Concentrators (EQ DPCs) installed on MX Series routers.
254
For more information about Ethernet IQ2 PICs and EQ DPCs and related features, see the Junos OS Class of Service Configuration Guide. For more information about configuring the MX Series routers, on which EQ DPCs are supported, see the Junos OS Layer 2 Configuration Guide. The following additional restrictions pertain to applying simple filters:
Simple filters are not supported on Modular Port Concentrator (MPC) interfaces, including Enhanced Queuing MPC interfaces. Simple filters are not supported for interfaces in an aggregated-Ethernet bundle. You can apply simple filters to family inet traffic only. No other protocol family is supported. You can apply simple filters to ingress traffic only. Egress traffic is not supported. You can apply only a single simple filter to a supported logical interface. Input lists are not supported. Simple Filter Overview on page 249 How Simple Filters Evaluate Packets on page 249 Guidelines for Configuring Simple Filters on page 251 Example: Configuring and Applying a Simple Filter on page 255
Example: Configuring and Applying a Simple Filter

This example shows how to configure a simple filter.

Requirements
This example uses one of the following hardware components:
One Gigabit Ethernet intelligent queuing (IQ2) PIC installed on an M120, M320, or T Series router One Enhanced Queuing Dense Port Concentrator (EQ DPC) installed on an MX Series router
Before you begin, make sure that you have:
Installed your supported router and PIC or DPC and performed the initial router configuration. Configured basic Ethernet in the topology, and verified that traffic is flowing in the topology and that ingress IPv4 traffic is flowing into logical interface ge-0/0/1.0.
255
Overview
This simple filter sets the loss priority to low for TCP traffic with source address 1.1.1.1, sets the loss priority to high for HTTP (Web) traffic with source addresses in the 4.0.0.0/8 range, and sets the loss priority to low for all traffic with destination address 6.6.6.6.
Topology
The simple filter is applied as an input filter (arriving packets are checking for destination address 6.6.6.6, not queued output packets) on interface ge-0/0/1.0.
Configuration

Configuring the Simple Firewall Filter on page 256 Applying the Simple Filter to the Logical Interface Input on page 258
set firewall family inet simple-filter sf_classify_1 term 1 from source-address 1.1.1.1/32 set firewall family inet simple-filter sf_classify_1 term 1 from protocol tcp set firewall family inet simple-filter sf_classify_1 term 1 then loss-priority low set firewall family inet simple-filter sf_classify_1 term 2 from source-address 4.0.0.0/8 set firewall family inet simple-filter sf_classify_1 term 2 from protocol tcp set firewall family inet simple-filter sf_classify_1 term 2 from source-port http set firewall family inet simple-filter sf_classify_1 term 2 then loss-priority high set firewall family inet simple-filter sf_classify_1 term 3 from destination-address 6.6.6.6/32 set firewall family inet simple-filter sf_classify_1 term 3 then loss-priority low set firewall family inet simple-filter sf_classify_1 term 3 then forwarding-class best-effort set interfaces ge-0/0/1 unit 0 family inet simple-filter input sf_classify_1 set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.3/30
Configuring the Simple Firewall Filter

Step-by-Step Procedure To configure the simple filter:
1.
Create the simple filter sf_classify_1.

[edit] user@host# edit firewall family inet simple-filter sf_classify_1
2.
Configure classification of TCP traffic based on the source IP address.

[edit firewall family inet simple-filter sf_classify_1] user@host# set term 1 from source-address 1.1.1.1/32 user@host# set term 1 from protocol tcp user@host# set term 1 then loss-priority low
256
3.
Configure classification of HTTP traffic based on the source IP address.

[edit firewall family inet simple-filter sf_classify_1] user@host# set term 2 from source-address 4.0.0.0/8 user@host# set term 2 from protocol tcp user@host# set term 2 from source-port http user@host# set term 2 then loss-priority high
4.
Configure classification of other traffic based on the destination IP address.

[edit firewall family inet simple-filter sf_classify_1] user@host# set term 3 from destination-address 6.6.6.6/32 user@host# set term 3 then loss-priority low user@host# set term 3 then forwarding-class best-effort
Results
Confirm the configuration of the simple filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit] user@host# show firewall family inet { simple-filter sf_classify_1 { term 1 { from { source-address { 1.1.1.1/32; } protocol { tcp; } } then loss-priority low; } term 2 { from { source-address { 4.0.0.0/8; } source-port { http; } protocol { tcp; } } then loss-priority high; } term 3 { from { destination-address { 6.6.6.6/32; } } then { loss-priority low;
257
forwarding-class best-effort; } } } }
Applying the Simple Filter to the Logical Interface Input

Step-by-Step Procedure To apply the simple filter to the logical interface input:
1.
Configure the logical interface to which you will apply the simple filter.
2.

3.
Apply the simple filter to the logical interface input.

[edit interfaces ge-0/0/1 unit 0 family inet] user@host# set simple-filter input sf_classify_1
Results
[edit] user@host# show interfaces ge-0/0/1 { unit 0 { family inet { simple-filter { input sf_classify_1; } address 10.1.2.3/30; } } }
Verification
Displaying the Mapping of Forwarding Class Maps and Names to Queue Numbers on page 259 Displaying CoS Queue Counters for the Interface on page 259 Displaying CoS Queue Counter Details for the Physical Interface on page 259
258
Displaying the Mapping of Forwarding Class Maps and Names to Queue Numbers
Purpose Action Display the mapping of forwarding class names to queue numbers. Enter the show class-of-service forwarding-class operational mode command.
[edit] user@host> show class-of-service forwarding-class
For information about the command output, see show class-of-service forwarding-class in the Junos OS System Basics and Services Command Reference.
Displaying CoS Queue Counters for the Interface

Purpose Verify that the class-of-service (CoS) queue counters for the interface reflect the simple filter applied to the logical interface. Enter the show interfaces command for the physical interface on which the simple filter is applied, and specify detail or extensive output level.
[edit] user@host> show interfaces ge-0/0/1 detail
Action
In the Physical interface section, under Ingress queues, the Queue counters section displays ingress queue counters for each forwarding class. For more detailed information about the command output, see show interfaces (Gigabit Ethernet) or show interfaces (10-Gigabit Ethernet) in the Junos OS Interfaces Command Reference.
Displaying CoS Queue Counter Details for the Physical Interface

Purpose Verify that the CoS queue counter details for the physical interface reflect the simple filter applied to the logical interface. Enter the show interfaces queue command for the physical interface on which the simple filter is applied, and specify the ingress option.
[edit] user@host> show interfaces queue ge-0/0/1 ingress
Action
For information about the command output, see show interfaces queue in the Junos OS Interfaces Command Reference.
Simple Filter Overview on page 249 How Simple Filters Evaluate Packets on page 249 Guidelines for Configuring Simple Filters on page 251 Guidelines for Applying Simple Filters on page 254
259
260
CHAPTER 8
Stateless Firewall Filter Configuration in Logical Systems

Stateless Firewall Filters in Logical Systems Overview on page 261 Guidelines for Configuring and Applying Firewall Filters in Logical Systems on page 262 References from a Firewall Filter in a Logical System to Subordinate Objects on page 265 References from a Firewall Filter in a Logical System to Nonfirewall Objects on page 266 References from a Nonfirewall Object in a Logical System to a Firewall Filter on page 268 Restrictions for Stateless Firewall Filters in Logical Systems on page 273 Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods on page 279
Stateless Firewall Filters in Logical Systems Overview


Logical Systems on page 261 Stateless Firewall Filters in Logical Systems on page 261 Identifiers for Firewall Objects in Logical Systems on page 262
Logical Systems
With the Junos OS, you can partition a single physical router into multiple logical devices that perform independent routing tasks. Because logical systems perform a subset of the tasks once handled by the physical router, logical systems offer an effective way to maximize the use of a single router.
Stateless Firewall Filters in Logical Systems

You can configure a separate set of stateless firewall filters for each logical system on a router. To configure a filter in a logical system, you must define the filter in the firewall stanza at the [edit logical-systems logical-system-name] hierarchy level, and you must apply the filter to a logical interface that is also configured at the [edit logical-systems logical-system-name] hierarchy level.
261
Identifiers for Firewall Objects in Logical Systems

To identify firewall objects configured under logical systems, operational show commands and firewall-related SNMP MIB objects include a __logical-system-name/ prefix in the object name. For example, firewall objects configured under the ls1 logical system include __ls1/ as the prefix. Related Documentation

Stateless Firewall Filter Types on page 6 Guidelines for Configuring and Applying Firewall Filters in Logical Systems on page 262 Unsupported Firewall Filter Statements for Logical Systems on page 273 Unsupported Actions for Firewall Filters in Logical Systems on page 275 Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods on page 279 Introduction to Logical Systems in the Junos OS Logical Systems Configuration Guide Logical Systems Operations and Restrictions in the Junos OS Logical Systems
Configuration Guide
Guidelines for Configuring and Applying Firewall Filters in Logical Systems


Statement Hierarchy for Configuring Firewall Filters in Logical Systems on page 262 Filter Types in Logical Systems on page 263 Firewall Filter Protocol Families in Logical Systems on page 263 Firewall Filter Match Conditions in Logical Systems on page 264 Firewall Filter Actions in Logical Systems on page 264 Statement Hierarchy for Applying Firewall Filters in Logical Systems on page 264
Statement Hierarchy for Configuring Firewall Filters in Logical Systems

To configure a firewall filter in a logical system, include the filter, service-filter, or simple-filter statement at the [edit logical-systems logical-system-name firewall family family-name] hierarchy level.
[edit] logical systems { logical-system-name { firewall { family family-name { filter filter-name { interface-specific; physical-interface-filter; term term-name { filter filter-name; from { match-conditions;
262
Chapter 8: Stateless Firewall Filter Configuration in Logical Systems
} then { actions; } } } service-filter filter-name { # For family inet or family inet6 only. term term-name { from { match-conditions; } then { actions; } } } simple-filter filter-name { # For family inet only. term term-name { from { match-conditions; } then { actions; } } } } } } }
Filter Types in Logical Systems

There are no special restrictions on the types of stateless firewall filter types that you can configure in logical systems. In a logical system, you can use the same types of stateless firewall filters that are available on a physical router:

Standard stateless firewall filters Service filters Simple filters
Firewall Filter Protocol Families in Logical Systems

There are no special restrictions on the protocol families supported with stateless firewall filters in logical systems.
263
In a logical system, you can filter the same protocol families as you can on a physical router.
Standard stateless firewall filtersIn logical systems, you can filter the following traffic types: protocol-independent, IPv4, IPv6, MPLS, MPLS-tagged IPv4, VPLS, Layer 2 circuit cross-connection, and Layer 2 bridging. Service filtersIn logical systems, you can filter IPv4 and IPv6 traffic. Simple filtersIn logical systems, you can filter IPv4 traffic only.
Firewall Filter Match Conditions in Logical Systems

There are no special restrictions on the match conditions supported with stateless firewall filters in logical systems.
Firewall Filter Actions in Logical Systems

There are no special restrictions on the actions supported with stateless firewall filters in logical systems.
Statement Hierarchy for Applying Firewall Filters in Logical Systems

To apply a firewall filter in a logical system, include the filter filter-name, service-filter service-filter-name, or simple-filter simple-filter-name statement to a logical interface in the logical system. The following configuration shows the hierarchy levels at which you can apply the statements:
[edit] logical-systems logical-system-name { interfaces { interface-name { unit logical-unit-number { family family-name { filter { group group-name; input filter-name; input-list [ filter-names ]; output filter-name; output-list [ filter-names ] } rpf-check { # For family inet or family inet6 only. fail-filter filter-name; mode loose; } service { # For family inet or family inet6 only. input { service-set service-set-name <service-filter service-filter-name>; post-service-filter service-filter-name; } output { service-set service-set-name <service-filter service-filter-name>; } }
264
simple-filter { # For family inet only. input simple-filter-name; } } } } } }
Stateless Firewall Filters in Logical Systems Overview on page 261 References from a Firewall Filter in a Logical System to Subordinate Objects on page 265 References from a Firewall Filter in a Logical System to Nonfirewall Objects on page 266 References from a Nonfirewall Object in a Logical System to a Firewall Filter on page 268 Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods on page 279 Unsupported Firewall Filter Statements for Logical Systems on page 273 Unsupported Actions for Firewall Filters in Logical Systems on page 275
References from a Firewall Filter in a Logical System to Subordinate Objects


Resolution of References from a Firewall Filter to Subordinate Objects on page 265 Valid Reference from a Firewall Filter to a Subordinate Object on page 265
Resolution of References from a Firewall Filter to Subordinate Objects

If a firewall filter defined in a logical system references a subordinate object (for example, a policer or prefix list), that subordinate object must be defined within the firewall stanza of the same logical system. For example, if a firewall filter configuration references a policer, the firewall filter and the policer must be configured under the same [edit logical-systems logical-system-name firewall] hierarchy level. This rule applies even if the same policer is configured under the main firewall configuration or if the same policer is configured as part of a firewall in another logical system.
Valid Reference from a Firewall Filter to a Subordinate Object

In this example, the firewall filter filter1 references the policer pol1. Both filter1 and pol1 are defined under the same firewall object. This configuration is valid. If pol1 had been defined under another firewall object, the configuration would not be valid.
[edit] logical systems { ls-A { firewall { policer pol1 { if-exceeding {
265
bandwidth-limit 401k; burst-size-limit 50k; } then discard; } filter filter1 { 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; } } } } }
Stateless Firewall Filters in Logical Systems Overview on page 261 Guidelines for Configuring and Applying Firewall Filters in Logical Systems on page 262 References from a Firewall Filter in a Logical System to Nonfirewall Objects on page 266 References from a Nonfirewall Object in a Logical System to a Firewall Filter on page 268
References from a Firewall Filter in a Logical System to Nonfirewall Objects


Resolution of References from a Firewall Filter to Nonfirewall Objects on page 266 Valid Reference to a Nonfirewall Object Outside of the Logical System on page 267
Resolution of References from a Firewall Filter to Nonfirewall Objects

In many cases, a firewall configuration references objects outside the firewall configuration. As a general rule, the referenced object must be defined under the same logical system as the referencing object. However, there are cases when the configuration of the referenced object is not supported at the [edit logical-systems logical-system-name] hierarchy level.
266
Valid Reference to a Nonfirewall Object Outside of the Logical System

This example configuration illustrates an exception to the general rule that the objects referenced by a firewall filter in a logical system must be defined under the same logical system as the referencing object. In the following scenario, the service filter inetsf1 is applied to IPv4 traffic associated with the service set fred at the logical interface fe-0/3/2.0, which is on an adaptive services interface.

Service filter inetsf1 is defined in ls-B and references prefix list prefix1. Service set fred is defined at the main services hierarchy level, and the policy framework software searches the [edit services] hierarchy for the definition of the fred service set.
Because service rules cannot be configured in logical systems. firewall filter configurations in the [edit logical-systems logical-system logical-system-name] hierarchy are allowed to reference service sets outside the logical system hierarchy.
[edit] logical-systems { ls-B { interfaces { fe-0/3/2 { unit 0 { family inet { service { input { service-set fred service-filter inetsf1; } } } } } } policy-options { prefix-list prefix1 { 1.1.0.0/16; 1.2.0.0/16; 1.3.0.0/16; } } firewall { # Under logical-system ls-B. family inet { filter filter1 { term one { from { source-address { 12.1.0.0/16; } } then { reject host-unknown; } } term two {
267
from { source-address { 12.2.0.0/16; } } then policer pol1; } } service-filter inetsf1 { term term1 { from { source-prefix-list { prefix1; } } then count prefix1; } } } policer pol1 { if-exceeding { bandwidth-limit 401k; burst-size-limit 50k; } then discard; } } } } # End of logical systems configuration. services { # Main services hierarchy level. service-set fred { max-flows 100; interface-service { service-interface sp-1/2/0.0; } } }
Stateless Firewall Filters in Logical Systems Overview on page 261 Guidelines for Configuring and Applying Firewall Filters in Logical Systems on page 262 References from a Firewall Filter in a Logical System to Subordinate Objects on page 265 References from a Nonfirewall Object in a Logical System to a Firewall Filter on page 268
References from a Nonfirewall Object in a Logical System to a Firewall Filter


Resolution of References from a Nonfirewall Object to a Firewall Filter on page 269 Invalid Reference to a Firewall Filter Outside of the Logical System on page 269 Valid Reference to a Firewall Filter Within the Logical System on page 270 Valid Reference to a Firewall Filter Outside of the Logical System on page 272
268
Resolution of References from a Nonfirewall Object to a Firewall Filter

If a nonfirewall filter object in a logical system references an object in a firewall filter configured in a logical system, the reference is resolved using the following logic:
If the nonfirewall filter object is configured in a logical system that includes firewall filter configuration statements, the policy framework software searches the [edit logical-systems logical-system-name firewall] hierarchy level. Firewall filter configurations that belong to other logical systems or to the main [edit firewall] hierarchy level are not searched. If the nonfirewall filter object is configured in a logical system that does not include any firewall filter configuration statements, the policy framework software searches the firewall configurations defined at the [edit firewall] hierarchy level.
Invalid Reference to a Firewall Filter Outside of the Logical System

This example configuration illustrates an unresolvable reference from a nonfirewall object in a logical system to a firewall filter. In the following scenario, the stateless firewall filters filter1 and fred are applied to the logical interface fe-0/3/2.0 in the logical system ls-C.

Filter filter1 is defined in ls-C. Filter fred is defined in the main firewall configuration.
Because ls-C contains firewall filter statements (for filter1), the policy framework software resolves references to and from firewall filters by searching the [edit logical systems ls-C firewall] hierarchy level. Consequently, the reference from fe-0/3/2.0 in the logical system to fred in the main firewall configuration cannot be resolved.
[edit] logical-systems { ls-C { interfaces { fe-0/3/2 { unit 0 { family inet { filter { input-list [ filter1 fred ]; } } } } } firewall { # Under logical system ls-C. family inet { filter filter1 { term one { from { source-address 12.1.0.0/16; } then { reject host-unknown;
269
} } term two { from { source-address 12.2.0.0/16; } then policer pol1; } } } policer pol1 { if-exceeding { bandwidth-limit 401k; burst-size-limit 50k; } then discard; } } } } # End of logical systems firewall { # Under the main firewall hierarchy level family inet { filter fred { term one { from { source-address 11.1.0.0/16; } then { log; reject host-unknown; } } } } } # End of main firewall configurations.
Valid Reference to a Firewall Filter Within the Logical System

This example configuration illustrates resolvable references from a nonfirewall object in a logical system to two firewall filter. In the following scenario, the stateless firewall filters filter1 and fred are applied to the logical interface fe-0/3/2.0 in the logical system ls-C.

Filter filter1 is defined in ls-C. Filter fred is defined in ls-C and also in the main firewall configuration.
Because ls-C contains firewall filter statements, the policy framework software resolves references to and from firewall filters by searching the [edit logical systems ls-C firewall] hierarchy level. Consequently, the references from fe-0/3/2.0 in the logical system to filter1 and fred use the stateless firewall filters configured in ls-C.
[edit] logical-systems { ls-C { interfaces {
270
fe-0/3/2 { unit 0 { family inet { filter { input-list [ filter1 fred ]; } } } } } firewall { # Under logical system ls-C. family inet { filter filter1 { 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; } } filter fred { # This fred is in ls-C. term one { from { source-address 10.1.0.0/16; } then { log; reject host-unknown; } } } } policer pol1 { if-exceeding { bandwidth-limit 401k; burst-size-limit 50k; } then discard; } } } } # End of logical systems configurations. firewall { # Main firewall filter hierarchy level family inet { filter fred { term one { from { source-address 11.1.0.0/16;
271
} then { log; reject host-unknown; } } } } } # End of main firewall configurations.
Valid Reference to a Firewall Filter Outside of the Logical System

This example configuration illustrates resolvable references from a nonfirewall object in a logical system to two firewall filter. In the following scenario, the stateless firewall filters filter1 and fred are applied to the logical interface fe-0/3/2.0 in the logical system ls-C.

Filter filter1 is defined in the main firewall configuration. Filter fred is defined in the main firewall configuration.
Because ls-C does not contain any firewall filter statements, the policy framework software resolves references to and from firewall filters by searching the [edit firewall] hierarchy level. Consequently, the references from fe-0/3/2.0 in the logical system to filter1 and fred use the stateless firewall filters configured in the main firewall configuration.
[edit] logical-systems { ls-C { interfaces { fe-0/3/2 { unit 0 { family inet { filter { input-list [ filter1 fred ]; } } } } } } } # End of logical systems configurations. firewall { # Main firewall hierarchy level. family inet { filter filter1 { term one { from { source-address 12.1.0.0/16; } then { reject host-unknown; } } term two { from { source-address 12.2.0.0/16;
272
} then policer pol1; } } filter fred { term one { from { source-address 11.1.0.0/16; } then { log; reject host-unknown; } } } } policer pol1 { if-exceeding { bandwidth-limit 701k; burst-size-limit 70k; } then discard; } } # End of main firewall configurations.
Stateless Firewall Filters in Logical Systems Overview on page 261 Guidelines for Configuring and Applying Firewall Filters in Logical Systems on page 262 References from a Firewall Filter in a Logical System to Subordinate Objects on page 265 References from a Firewall Filter in a Logical System to Nonfirewall Objects on page 266
Restrictions for Stateless Firewall Filters in Logical Systems

Unsupported Firewall Filter Statements for Logical Systems on page 273 Unsupported Actions for Firewall Filters in Logical Systems on page 275
Unsupported Firewall Filter Statements for Logical Systems

Table 28 on page 274 shows statements that are supported at the [edit firewall] hierarchy level but not at the [edit logical-systems logical-system-name firewall] hierarchy level.
273
Table 28: Unsupported Firewall Statements for Logical Systems

Statement
accounting-profile
Example
[edit] logical-systems { ls1 { firewall { family inet { filter myfilter { accounting-profile fw-profile; ... term accept-all { then { count counter1; accept; } } } } } } } [edit] logical-systems { lr1 { firewall { hierarchical-policer { ... } } } } [edit] logical-systems { ls1 { firewall { load-balance-group lb-group { next-hop-group nh-group; } } } }
Description
In this example, the accounting-profile statement is not allowed because the accounting profile fw-profile is configured under the [edit accounting-options] hierarchy.
hierarchical-policer
In this example, the hierarchical policer statement requires a class-of-service configuration, which is not supported under logical systems.
load-balance-group
This configuration is not allowed because the next-hop-group nh-group statement must be configured at the [edit
forwarding-options next-hop-group] hierarchy leveloutside the [edit logical-systems logical-system-name firewall] hierarchy.
Currently, the forwarding-options dhcp-relay statement is the only forwarding option supported for logical systems.
274
Table 28: Unsupported Firewall Statements for Logical Systems (continued)

Statement
virtual-channel
Example
[edit] logical-systems { ls1 { firewall { family inet { filter foo { term one { from { source-address 10.1.0.0/16; } then { virtual-channel sammy; } } } } } } }
Description
This configuration is not allowed because the virtual channel sammy refers to an object defined at the [edit class-of-service] hierarchy level, and class of service is not supported for logical systems. NOTE: The virtual-channel statement is supported for J Series devices only, provided the firewall filter is configured outside of a logical-system.
Stateless Firewall Filters in Logical Systems Overview on page 261 Guidelines for Configuring and Applying Firewall Filters in Logical Systems on page 262 Unsupported Actions for Firewall Filters in Logical Systems on page 275 Introduction to Logical Systems in the Junos OS Logical Systems Configuration Guide Logical Systems Operations and Restrictions in the Junos OS Logical Systems
Configuration Guide
Unsupported Actions for Firewall Filters in Logical Systems

Table 29 on page 275 describes the firewall filter actions that are supported at the [edit firewall] hierarchy level, but not supported at the [edit logical-systems logical-system-name firewall] hierarchy level.
Table 29: Unsupported Actions for Firewall Filters in Logical Systems

Firewall Filter Action Example Description
Terminating Actions Not Supported in a Logical System
275
Table 29: Unsupported Actions for Firewall Filters in Logical Systems (continued)
Firewall Filter Action
logical-system
Example
[edit] logical-systems { ls1 { firewall { family inet { filter foo { term one { from { source-address 10.1.0.0/16; } then { logical-system fred; } } } } } } }
Description
Because the logical-system action refers to freda logical system defined outside the local logical system, this action is not supported.
Nonterminating Actions Not Supported in a Logical System

ipsec-sa
[edit] logical-systems { ls1 { firewall { family inet { filter foo { term one { from { source-address 10.1.0.0/16; } then { ipsec-sa barney; } } } } } } }
Because the ipsec-sa action modifier references barneya security association defined outside the local logical systemthis action is not supported.
276
next-hop-group
Example
[edit] logical-systems { ls1 { firewall { family inet { filter foo { term one { from { source-address 10.1.0.0/16; } then { next-hop-group fred; } } } } } } } [edit] logical-systems { ls1 { firewall { family inet { filter foo { term one { from { source-address 10.1.0.0/16; } then { port-mirror; } } } } } } }
Description
Because the next-hop-group action refers to fredan object defined at the
[edit forwarding-options next-hop-group] hierarchy levelthis
action is not supported.
port-mirror
Because the port-mirror action relies on a configuration defined at the [edit

forwarding-options port-mirroring]
hierarchy level, this action is not supported.
277
sample
Example
[edit] logical-systems { ls1 { firewall { family inet { filter foo { term one { from { source-address 10.1.0.0/16; } then { sample; } } } } } } } [edit] logical-systems { 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; } } } } } }
Description
In this example, the sample action depends on the sampling configuration defined under the [edit forwarding-options] hierarchy. Therefore, the sample action is not supported.
syslog
In this example, there must be at least one system log (system syslog file filename) with the firewall facility enabled for the icmp-syslog filter's logs to be stored. Because this firewall configuration relies on a configuration outside the logical system, the syslog action modifier is not supported.
Stateless Firewall Filters in Logical Systems Overview on page 261 Guidelines for Configuring and Applying Firewall Filters in Logical Systems on page 262 Unsupported Firewall Filter Statements for Logical Systems on page 273 Introduction to Logical Systems in the Junos OS Logical Systems Configuration Guide
278
Logical Systems Operations and Restrictions in the Junos OS Logical Systems

Configuration Guide
Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods
This example shows how to configure a stateless firewall filter that protects against ICMP denial-of-service attacks on a logical system.

Requirements
In this example, no special configuration beyond device initialization is required.
Overview
This example shows a stateless firewall filter called protect-RE that polices ICMP packets. The icmp-policer limits the traffic rate of the ICMP packets to 1,000,000 bps and the burst size to 15,000 bytes. Packets that exceed the traffic rate are discarded. The policer is incorporated into the action of a filter term called icmp-term. In this example, a ping is sent from a directly connected physical router to the interface configured on the logical system. The logical system accepts the ICMP packets if they are received at a rate of up to 1 Mbps (bandwidth-limit). The logical system drops all ICMP packets when this rate is exceeded. The burst-size-limit statement accepts traffic bursts up to 15 Kbps. If bursts exceed this limit, all packets are dropped. When the flow rate subsides, ICMP packets are again accepted. Figure 3 on page 279 shows the topology used in this example.
Figure 3: Logical System with a Stateless Firewall

Router 1
LS1
so-0/0/2 10.0.45.2/30
so-0/0/2 10.0.45.1/30
R2
g040571
279
Configuration
set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet policer input icmp-policer set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet address 10.0.45.2/30 set logical-systems LS1 firewall family inet filter protect-RE term icmp-term from protocol icmp set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then policer icmp-policer set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then accept set logical-systems LS1 firewall policer icmp-policer if-exceeding bandwidth-limit 1m set logical-systems LS1 firewall policer icmp-policer if-exceeding burst-size-limit 15k set logical-systems LS1 firewall policer icmp-policer then discard
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode on page 15 in the Junos OS CLI User Guide. To configure an ICMP firewall filter on a logical system:
1.
Configure the interface on the logical system.

[edit] user@host# set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet address 10.0.45.2/30
2.
Explicitly enable ICMP packets to be received on the interface.

[edit] user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term from protocol icmp user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then accept
3.
Create the policer.

[edit] user@host# set logical-systems LS1 firewall policer icmp-policer if-exceeding bandwidth-limit 1m user@host# set logical-systems LS1 firewall policer icmp-policer if-exceeding burst-size-limit 15k user@host# set logical-systems LS1 firewall policer icmp-policer then discard
4.
Apply the policer to a filter term.

[edit] user@host# set logical-systems LS1 firewall family inet filter protect-RE term icmp-term then policer icmp-policer
5.
Apply the policer to the logical system interface.

[edit]
280
user@host# set logical-systems LS1 interfaces so-0/0/2 unit 0 family inet policer input icmp-policer
6.

Results
Confirm your configuration by issuing the show logical-systems LS1 command.

user@host# show logical-systems LS1 interfaces { so-0/0/2 { unit 0 { family inet { policer { input icmp-policer; } address 10.0.45.2/30; } } } } firewall { family inet { filter protect-RE { term icmp-term { from { protocol icmp; } then { policer icmp-policer; accept; } } } } policer icmp-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 15k; } then discard; } }
Verification
Verifying That Ping Works Unless the Limits Are Exceeded

Purpose Action Make sure that the logical system interface is protected against ICMP-based DoS attacks. Log in to a system that has connectivity to the logical system and run the ping command.
281
user@R2> ping 10.0.45.2 PING 10.0.45.2 (10.0.45.2): 56 data 64 bytes from 10.0.45.2: icmp_seq=0 64 bytes from 10.0.45.2: icmp_seq=1 64 bytes from 10.0.45.2: icmp_seq=2
bytes ttl=64 time=1.316 ms ttl=64 time=1.277 ms ttl=64 time=1.269 ms
user@R2> ping 10.0.45.2 size 20000 PING 10.0.45.2 (10.0.45.2): 20000 data bytes ^C --- 10.0.45.2 ping statistics --4 packets transmitted, 0 packets received, 100% packet loss
Meaning
When you send a normal ping, the packet is accepted. When you send a ping packet that exceeds the filter limit, the packet is discarded.
Example: Creating an Interface on a Logical System
282
CHAPTER 9
Summary of Stateless Firewall Filter Configuration Statements

The following descriptions explain each of the statelesss firewall filter configuration statements. The statements are organized alphabetically.
accounting-profile
Syntax Hierarchy Level Release Information Description Options Required Privilege Level Related Documentation
accounting-profile name; [edit firewall family family-name filter filter-name]
Statement introduced before Junos OS Release 7.4. Enable collection of accounting data for the specified filter.
nameName assigned to the accounting profile.
interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.
Accounting for Standard Firewall Filters Overview on page 211
283
enhanced-mode
Syntax Hierarchy Level
enhanced-mode; [edit firewall filter filter-name], [edit firewall family family-name filter filter-name], [edit logical-systems logical-system-name firewall filter filter-name], [edit logical-systems logical-system-name firewall family family-name filter filter-name]
Release Information Description
Statement introduced in Junos OS Release 11.4. Limit static service filters or API-client filters to term-based filter format only for inet or inet6 families when enhanced network services mode is configured at the [edit chassis network-services] hierarchy level. When used with one of the chassis enhanced network services modes, firewall filters are generated in term-based format for use with Trio MPC modules. If enhanced network services are not configured for the chassis, the enhanced-mode statement is ignored and any enhanced mode firewall filters are generated in both term-based and compiled format (the default).
NOTE: You cannot attach enhanced mode filters to local loopback, management, or MS-DPC interfaces. These interfaces are processed by the routing engine kernel and DPC modules and can accept only compiled firewall filter format.
Required Privilege Level Related Documentation
firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Network Services Mode Overview in the Junos OS System Basics Configuration Guide Firewall Filters and Enhanced Network Services Mode Overview in the Junos OS
Subscriber Access Configuration Guide
Configuring a Filter for Use with Enhanced Network Services Mode in the Junos OS
Subscriber Access Configuration Guide
284
Chapter 9: Summary of Stateless Firewall Filter Configuration Statements
family
Syntax
family family-name { filter filter-name { accounting-profile name; enhanced-mode; interface-specific; physical-interface-filter; } prefix-action name { count; destination-prefix-length prefix-length; policer policer-name; source-prefix-length prefix-length; subnet-prefix-length prefix-length; } simple-filter filter-name { term term-name { from { match-conditions; } then { action; action-modifiers; } } } } [edit firewall], [edit logical-systems logical-system-name firewall]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. simple-filter statement introduced in Junos OS Release 7.6. any family type introduced in Junos OS Release 8.0. bridge family type introduced in Junos OS Release 8.4 (MX Series routers only). Configure a firewall filter for IP version 4 (IPv4) or IP version 6 (IPv6) traffic. On the MX Series routers only, configure a firewall filter for Layer 2 traffic in a bridging environment.
family-nameVersion or type of addressing protocol:

Description
Options
anyProtocol-independent match conditions. bridge(MX Series routers only) Layer 2 packets that are part of bridging domain. cccLayer 2 switching cross-connects. inetIPv4 addressing protocol. inet6IPv6 addressing protocol. mplsMPLS.
285
vplsVirtual private LAN service (VPLS).
The remaining statements are explained separately. Required Privilege Level Related Documentation interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Guidelines for Configuring Standard Firewall Filters on page 21 Guidelines for Configuring Service Filters on page 230 Guidelines for Configuring Simple Filters on page 251
286
filter
See the following sections:

filter (Applying to a Logical Interface) on page 287 filter (Configuring) on page 288
filter (Applying to a Logical Interface)

Syntax
[edit interfaces interface-name unit logical-unit-number family family], [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]
Release Information Description Options
Statement introduced before Junos OS Release 7.4. Apply a stateless firewall filter to a logical interface at a specific protocol level.
input filter-nameName of one filter to evaluate when packets are received on the
interface.
output filter-nameName of one filter to evaluate when packets are transmitted on the
interface. The remaining statements are explained separately. Required Privilege Level Related Documentation interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Guidelines for Configuring Standard Firewall Filters on page 21 Guidelines for Applying Standard Firewall Filters on page 26
287
filter (Configuring)
Syntax
filter filter-name { accounting-profile name; enhanced-mode; interface-specific; physical-interface-filter; term term-name { filter filter-name; from { match-conditions; } then { actions; } } } [edit dynamic-profiles profile-name firewall family family-name]; [edit firewall family family-name], [edit logical-systems logical-system-name firewall family family-name]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. physical-interface-filter statement introduced in Junos OS Release 9.6. Support at the [edit dynamic-profiles ... family family-name] hierarchy level introduced in Junos OS Release 11.4. Configure firewall filters.
filter-nameName that identifies the filter. The name can contain letters, numbers, and
Description Options
hyphens (-) and can be up to 64 characters long. To include spaces in the name, enclose it in quotation marks ( ). The remaining statements are explained separately. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Guidelines for Configuring Standard Firewall Filters on page 21 Guidelines for Applying Standard Firewall Filters on page 26
288
firewall
firewall { ... } [edit], [edit logical-systems logical-system-name] [edit dynamic-profilesprofile-name],
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Configure firewall filters. The statements are explained separately.
Description

Guidelines for Configuring Standard Firewall Filters on page 21 Guidelines for Configuring Service Filters on page 230 Guidelines for Configuring Simple Filters on page 251
interface-set
Syntax
interface-set interface-set-name { interface-name; } [edit firewall], [edit logical-systems logical-system-name firewall]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Configure an interface set.
interface-nameNames of each interface to include in the interface set. You must specify
Description Options
more than one name. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.
Filtering Packets Received on an Interface Set Overview on page 192
289
interface-specific
interface-specific; [edit firewall family family-name filter filter-name], [edit logical-systems logical-system-name firewall family family-name filter filter-name]
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Configure interface-specific names for firewall counters. interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.
Description Required Privilege Level Related Documentation
Interface-Specific Firewall Filter Instances Overview on page 177
service-filter
Syntax
service-filter filter-name { term term-name { from { match-conditions; } then { actions; } } } [edit firewall family (inet | inet6], [edit logical-systems logical-system-name firewall family (inet | inet6)]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Configure service filters.
filter-nameName that identifies the service filter. The name can contain letters, numbers,
Description Options
and hyphens (-) and can be up to 255 characters long. To include spaces in the name, enclose it in quotation marks ( ). The remaining statements are explained separately. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Guidelines for Configuring Service Filters on page 230 Guidelines for Applying Service Filters on page 232
290
simple-filter
Syntax
simple-filter filter-name { term term-name { from { match-conditions; } then { actions; } } } [edit firewall family inet], [edit logical-systems logical-system-name firewall family inet]
Hierarchy Level
Release Information
Statement introduced in Junos OS Release 7.6. Logical systems support introduced in Junos OS Release 9.3. Configure simple filters.
filter-nameName that identifies the simple filter. The name can contain letters, numbers,
Description Options
and hyphens (-) and can be up to 255 characters long. To include spaces in the name, enclose it in quotation marks ( ). The remaining statements are explained separately. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Guidelines for Configuring Simple Filters on page 251 Guidelines for Applying Simple Filters on page 254
291
term
Syntax
term term-name { from { match-conditions; ip-version ipv4 { match-conditions-mpls-ipv4-address; protocol (tcp | udp) { match conditions-mpls-ipv4-port; } } } then { actions; } } [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]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. filter option introduced in Junos OS Release 7.6. Logical systems support introduced in Junos OS Release 9.3. ip-version ipv4 support introduced in Junos OS Release 10.1. Define a firewall filter term.
actions(Optional) Actions to perform on the packet if conditions match. You can specify
Description Options
one terminating action supported for the specified filter type. If you do not specify a terminating action, the packets that match the conditions in the from statement are accepted by default. As an option, you can specify one or more nonterminating actions supported for the specified filter type.
filter-name(Optional) For family family-name filter filter-name only, reference another
standard stateless firewall filter from within this term.

from(Optional) Match packet fields to values. If not included, all packets are considered
to match and the actions and action modifiers in the then statement are taken.
match-conditionsOne or more conditions to use to make a match on a packet. match-conditions-mpls-ipv4-address(MPLS-tagged IPv4 traffic only) One or more IP
address match conditions to match on the IPv4 packet header. Supports network-based service in a core network with IPv4 packets as an inner payload of an MPLS packet with labels stacked up to five deep.
292
match-conditions-mpls-ipv4-port(MPLS-tagged IPv4 traffic only) One or more UDP or
TCP port match conditions to use to match a packet in an MPLS flow. Supports network-based service in a core network with IPv4 packets as an inner payload of an MPLS packet with labels stacked up to five deep.
term-nameName that identifies the term. The name can contain letters, numbers, and
hyphens (-) and can be up to 64 characters long. To include spaces in the name, enclose it in quotation marks ( ).
then(Optional) Actions to take on matching packets. If not included and a packet
matches all the conditions in the from statement, the packet is accepted. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Guidelines for Configuring Standard Firewall Filters on page 21 Guidelines for Configuring Service Filters on page 230 Guidelines for Configuring Simple Filters on page 251 Guidelines for Configuring and Applying Firewall Filters in Logical Systems on page 262
293
294
PART 2
Traffic Policers

Introduction to Traffic Policers on page 297 Single-Rate Two-Color Policer Configuration on page 327 Three-Color Policer Configuration on page 399 Logical and Physical Interface Policer Configuration on page 415 Layer 2 Policer Configuration on page 437 Summary of Policer Configuration Statements on page 455
295
296
CHAPTER 10
Introduction to Traffic Policers

Traffic Policing Overview on page 297 Traffic Policer Types on page 301 Order of Policer and Firewall Filter Operations on page 304 Introduction to Policer Configuration on page 305 Introduction to Policer Rate Limits and Actions on page 316 Supported Standards for Policing on page 326
Traffic Policing Overview


Congestion Management for IP Traffic Flows on page 297 Traffic Limits on page 298 Traffic Color Marking on page 299 Forwarding Classes and PLP Levels on page 300 Policer Application to Traffic on page 300
Congestion Management for IP Traffic Flows

Traffic policing, also known rate limiting, is an essential component of network access security that is designed to thwart denial-of-service (DoS) attacks. Traffic policing enables you to control the maximum rate of IP traffic sent or received on an interface and also to partition network traffic into multiple priority levels, also known as classes of service. A policer defines a set of traffic rate limits and sets consequences for traffic that does not conform to the configured limits. Packets in a traffic flow that does not conform to traffic limits are either discarded or marked with a different forwarding class or packet loss priority (PLP) level. With the exception of policers configured to rate-limit aggregate traffic (all protocol families and logical interfaces configured on a physical interface), you can apply a policer to all IP packets in a Layer 2 or Layer 3 traffic flow at a logical interface. With the exception of policers configured to rate-limit based on physical interface media rate, you can apply a policer to specific IP packets in a Layer 3 traffic flow at a logical interface by using a stateless firewall filter.
297
You can apply a policer to inbound or outbound interface traffic. Policers applied to inbound traffic help to conserve resources by dropping traffic that does not need to be routed through a network. Dropping inbound traffic also helps to thwart denial-of-service (DoS) attacks. Policers applied to outbound traffic control the bandwidth used.
Traffic Limits
Junos OS policers use the token-bucket algorithm to enforce a limit on average transmit or receive rate of IP traffic at an interface while allowing bursts of traffic up to a maximum value based on the overall traffic load. The token-bucket algorithm offers more flexibility than the leaky-bucket algorithm in that you can allow a specified amount of bursting before starting to discard packets or apply a penalty to packet output-queuing priority or packet drop priority. In the token-bucket model, the bucket represents the policing function. Tokens are added to the bucket at a fixed rate, but only up to the specified depth of the bucket. Each token represents a credit for some number of bits, and tokens in the bucket are cashed in for the ability to transmit or receive traffic at the interface. When sufficient tokens are present in the bucket, a traffic flow continues unrestricted. Otherwise, packets might be dropped or else re-marked with a lower forwarding class, a higher packet loss priority (PLP) level, or both.
The rate at which tokens are added to the bucket represents the highest average transmit or receive rate in bits per second allowed for a given service level. You specify this highest average traffic rate as the bandwidth limit of the policer. If the traffic arrival rate is so high that at some point insufficient tokens are present in the bucket, then the traffic flow is no longer conforming to the traffic limit. The depth of the bucket in bytes controls the amount of back-to-back bursting allowed. You specify this factor as the burst-size limit of the policer. This second limit affects the average transmit or receive rate by limiting the number of bytes permitted in a transmission burst for a given interval of time. Bursts exceeding the current burst-size limit are dropped until there are sufficient tokens available to permit the burst to proceed.
Figure 4: Network Traffic and Burst Rates
As shown in the figure above, a UPC bar code is a good facsimile of what traffic looks like on the line; an interface is either transmitting (bursting at full rate) or it is not. The black lines represent periods of data transmission and the white space represents periods of silence when the token bucket can replenish.
298
Chapter 10: Introduction to Traffic Policers
Depending on the type of policer used, packets in a policed traffic flow that surpasses the defined limits might be implicitly set to a higher PLP level, assigned to a configured forwarding class or set to a configured PLP level (or both), or simply discarded. If packets encounter downstream congestion, packets with a low PLP level are less likely to be discarded than those with a medium-low, medium-high, or high PLP level.
Traffic Color Marking

Based on the particular set of traffic limits configured, a policer identifies a traffic flow as belonging to one of either two or three categories that are similar to the colors of a traffic light used to control automobile traffic. A two-color-marking policer categorizes traffic as either conforming to the traffic limits (green) or violating the traffic limits (red):
GreenTwo-color-marking policers implicitly set the packets in a green flow to the low PLP level, and you cannot configure any policer actions for conforming traffic. RedTwo-color-marking policers do not perform any implicit actions on packets in a red flow. Instead, those packets are handled according to the actions specified in the policer configuration. You can configure a two-color-marking policer to simply discard packets if the traffic flow is red. Alternatively, you can configure a two-color-marking policer to handle the packets in a red flow by setting the PLP level to either low or high, assigning the packets to any forwarding class already configured, or both. On MX Series, M120, and M320 routers and M7i and M10i routers with the Enhanced CFEB (CFEB-E) only, you can specify two additional PLP levels for packets in a red flow: medium-low or medium-high.
Three-color-marking policers categorize traffic as conforming to the traffic limits (green), violating the traffic limits (red), or exceeding the traffic limits but within an allowed range (yellow):
GreenLike two-color-marking policers, three-color-marking policers implicitly set the packets in a green flow to the low PLP level, and you cannot configure any policer actions for conforming traffic. YellowUnlike two-color-marking policers, three-color-marking policers categorize a second type of nonconforming traffic: yellow. Single-rate three-color policing categorizes as yellow traffic that exceeds the traffic limits while conforming to a second defined burst-size limit. Two-rate three-color policing categorizes as yellow traffic that exceeds the traffic limits while conforming to both a second defined burst-size limit and a second defined bandwidth limit. Three-color-marking policers implicitly set the packets in a yellow flow to the medium-high PLP level so that the packets incur a less severe penalty than those in a red flow. You cannot configure any policer actions for yellow traffic.
RedUnlike two-color-marking policers, three-color-marking policers implicitly set the packets in a red flow to the high PLP level, which is the highest PLP value. You can also configure a three-color-marking policer to discard the packets in a red flow instead of forwarding them with a high PLP setting.
299
Two-color-marking policers allows bursts of traffic for short periods, whereas three-color-marking policers allow more sustained bursts of traffic.
Forwarding Classes and PLP Levels

A packets forwarding class assignment and PLP level are used by the Junos OS class of service (CoS) features. The Junos CoS features include a set of mechanisms that you can use to provide differentiated services when best-effort traffic delivery is insufficient. For router interfaces that carry IPv4, IPv6, and MPLS traffic, you can configure CoS features to take in a single flow of traffic entering at the edge of your network and provide different levels of service across the networkinternal forwarding and scheduling (queuing) for outputbased on the forwarding class assignments and PLP levels of the individual packets.
NOTE: Forwarding-class or loss-priority assignments performed by a policer or a stateless firewall filter override any such assignments performed on the ingress by the CoS default IP precedence classification at all logical interfaces or by any configured behavior aggregate (BA) classifier that is explicitly mapped to a logical interface.
Based on CoS configurations, packets of a given forwarding class are transmitted through a specific output queue, and each output queue is associated with a transmission service level defined in a scheduler. Based on other CoS configurations, when packets in an output queue encounter congestion, packets with higher loss-priority values are more likely to be dropped by the random early detection (RED) algorithm. Packet loss priority values affect the scheduling of a packet without affecting the packets relative ordering within the traffic flow.
Policer Application to Traffic

After you have defined and named a policer, it is stored as a template. You can later use the same policer name to provide the same policer configuration each time you want to use it. This eliminates the need to define the same policer values more than once. You can apply a policer to a traffic flow in either of two ways:
You can configure a standard stateless firewall filter that specifies the policer policer-name nonterminating action or the three-color-policer (single-rate | two-rate) policer-name nonterminating action. When you apply the standard filter to the input or output at a logical interface, the policer is applied to all packets of the filter-specific protocol family that match the conditions specified in the filter configuration. With this method of applying a policer, you can define specific classes of traffic on an interface and apply traffic rate-limiting to each class.
You can apply a policer directly to an interface so that traffic rate-limiting applies to all traffic on that interface, regardless of protocol family or any match conditions.
300
You can configure policers at the queue, logical interface, or Layer 2 (MAC) level. Only a single policer is applied to a packet at the egress queue, and the search for policers occurs in this order:

Queue level Logical interface level Layer 2 (MAC) level Stateless Firewall Filter Overview on page 5 in the Junos OS Firewall Filter and Policer
Configuration Guide
Traffic Policer Types on page 301 Order of Policer and Firewall Filter Operations on page 304 Packet Flow Through the CoS Process Overview
Traffic Policer Types


Single-Rate Two-Color Policers on page 301 Three-Color Policers on page 302 Hierarchical Policers on page 303 Two-Color and Three-Color Policer Options on page 303
Single-Rate Two-Color Policers

You can use a single-rate two-color policer, or policer when used without qualification, to rate-limit a traffic flow to an average bits-per-second arrival rate (specified by the single specified bandwidth limit) while allowing bursts of traffic for short periods (controlled by the single specified burst-size limit). This type of policer categorizes a traffic flow as either green (conforming) or red (nonconforming). Packets in a green flow are implicitly set to a low loss priority and then transmitted. Packets in a red flow are handled according to actions specified in the policer configuration. Packets in a red flow can be markedset to a specified forwarding class, set to a specified loss priority, or bothor they can be discarded. A single-rate two-color policer is most useful for metering traffic at the port (physical interface) level.
Basic Single-Rate Two-Color Policer

You can apply a basic single-rate two-color policer to Layer 3 traffic in either of two ways: as an interface policer or as a firewall filter policer. You can apply the policer as an interface policer, meaning that you apply the policer directly to a logical interface at the protocol family level. If you want to apply the policer to selected packets only, you can apply the policer as a firewall filter policer, meaning that you reference the policer in a stateless firewall filter term and then apply the filter to a logical interface at the protocol family level.
301
Bandwidth Policer
A bandwidth policer is simply a single-rate two-color policer that is defined using a bandwidth limit specified as a percentage value rather than as an absolute number of bits per second. When you apply the policer (as an interface policer or as a firewall filter policer) to a logical interface at the protocol family level, the effective bandwidth limit is calculated based on either the physical interface media rate or the logical interface configured shaping rate.
Logical Bandwidth Policer

A logical bandwidth policer is a bandwidth policer for which the effective bandwidth limit is calculated based on the logical interface configured shaping rate. You can apply the policer as a firewall filter policer only, and the firewall filter must be configured as an interface-specific filter. When you apply an interface-specific filter to multiple logical interfaces on supported routing platforms, any count or policer actions act on the traffic stream entering or exiting each individual interface, regardless of the sum of traffic on the multiple interfaces.
Three-Color Policers
The Junos OS supports two types of three-color policers: single-rate and two-rate. The main difference between a single-rate and a two-rate policer is that the single-rate policer allows bursts of traffic for short periods, while the two-rate policer allows more sustained bursts of traffic. Single-rate policing is implemented using a single token-bucket model, so that periods of relatively low traffic must occur between traffic bursts to allow the token bucket to refill. Two-rate policing is implemented using a dual token-bucket model, which allows bursts of traffic for longer periods.
Single-Rate Three-Color Policers

The single-rate three-color type of policer is defined in RFC 2697, A Single Rate Three Color Marker. You use this type of policer to rate-limit a traffic flow to a single rate and three traffic categories (green, yellow, and red). A single-rate three-color policer defines a committed bandwidth limit and burst-size limit plus an excess burst-size limit. Traffic that conforms to the committed traffic limits is categorized as green (conforming). Traffic that conforms to the bandwidth limit while allowing bursts of traffic as controlled by the excess burst-size limit is categorized as yellow. All other traffic is categorized as red. A single-rate three-color policer is most useful when a service is structured according to packet length, not peak arrival rate.
Two-Rate Three-Color Policers

The two-rate three-color type of policer is defined in RFC 2698, A Two Rate Three Color Marker. You use this type of policer to rate-limit a traffic flow to two rates and three traffic categories (green, yellow, and red). A two-rate three-color policer defines a committed bandwidth limit and burst-size limit plus a peak bandwidth limit and burst-size limit. Traffic that conforms to the committed traffic limits is categorized as green (conforming). Traffic that exceeds the committed traffic limits but remains below the peak traffic limits is categorized as yellow. Traffic that exceeds the peak traffic limits is categorized as red.
302
A two-rate three-color policer is most useful when a service is structured according to arrival rates and not necessarily packet length.
Hierarchical Policers
You can use a hierarchical policer to rate-limit ingress Layer 2 traffic at a physical or logical interface and apply different policing actions based on whether the packets are classified for expedited forwarding (EF) or for a lower priority output queue. This feature is supported on SONET interfaces hosted on M40e, M120, and M320 edge routers with incoming Flexible PIC Concentrators (FPCs) as SFPC and outgoing FPCs as FFPC, and on T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs.
Two-Color and Three-Color Policer Options

Both two-color and three-color policers can be configured with the following options:

Logical Interface (Aggregate) Policers on page 303 Physical Interface Policers on page 303 Policers Applied to Layer 2 Traffic on page 304 Multifield Classification on page 304
Logical Interface (Aggregate) Policers

A logical interface policeralso called an aggregate policeris a two-color or three-color policer that you can apply to multiple protocol families on the same logical interface without creating multiple instances of the policer. You apply a logical interface policer directly to a logical interface configuration (and not by referencing the policer in a stateless firewall filter and then applying the filter to the logical interface).
You can apply the policer at the interface logical unit level to rate-limit all traffic types, regardless of the protocol family. You can also apply the policer at the logical interface protocol family level, to rate-limit traffic for a specific protocol family.
You can apply a logical interface policer to unicast traffic only. For information about configuring a stateless firewall filter for flooded traffic, see Applying Filters to Forwarding Tables in the Traffic Sampling, Forwarding, and Monitoring section of the Junos OS Routing Policy Configuration Guide.
Physical Interface Policers

A physical interface policer is a two-color or three-color policer that applies to all logical interfaces and protocol families configured on a physical interface, even if the logical interfaces belong to different routing instances. You apply a physical interface policer to a logical interface at the protocol level through a physical interface filter only, but rate limiting is performed aggregately for all logical interfaces and protocol families configured on the underlying physical interface. This feature enables you to use a single policer instance to perform aggregate policing for different protocol families and different logical interfaces on the same physical interface.
303
Policers Applied to Layer 2 Traffic

In addition to hierarchical policing, you can also apply single-rate two-color policers and three-color policers (both single-rate and two-rate) to Layer 2 input or output traffic. You must configure the two-color or three-color policer as a logical interface policer and reference the policer in the interface configuration at the logical unit level, and not at the protocol level. You cannot apply a two-color or three-color policer to Layer 2 traffic as a stateless firewall filter action.
Multifield Classification
Like behavior aggregate (BA) classification, which is sometimes referred to as class-of-service (CoS) value traffic classification, multifield classification is a method of classifying incoming traffic by associating each packet with a forwarding class, a packet loss priority level, or both. The CoS scheduling configuration assigns packets to output queues based on forwarding class. The CoS random early detection (RED) process uses the drop probability configuration, output queue fullness percentage, and packet loss priority to drop packets as needed to control congestion at the output stage. BA classification and multifield classification use different fields of a packet to perform traffic classification. BA classification is based on a CoS value in the IP packet header. Multifield classification can be based on multiple fields in the IP packet header, including CoS values. Multifield classification is used instead of BA classification when you need to classify packets based on information in the packet other than the CoS values only. Multifield classification is configured using a stateless firewall filter term that matches on any packet header fields and associates matched packets with a forwarding class, a loss priority, or both. The forwarding class or loss priority can be set by a firewall filter action or by a policer referenced as a firewall filter action. Related Documentation

Traffic Policing Overview on page 297 Order of Policer and Firewall Filter Operations on page 304 Two-Color Policer Configuration Overview on page 307 Three-Color Policer Configuration Overview on page 311 Hierarchical Policer Configuration Overview on page 314 Two-Color Policing at Layer 2 Overview on page 444 Three-Color Policing at Layer 2 Overview on page 446
Order of Policer and Firewall Filter Operations

You can apply a both a traffic policer and a stateless firewall filter (with or without policing actions) to a single logical interface at the same time. In this case, the order of precedence of operations is such that policers applied directly to the logical interface are evaluated before input filters but after output filters.
If an input firewall filter is configured on the same logical interface as a policer, the policer is executed first.
304
If an output firewall filter is configured on the same logical interface as a policer, the firewall filter is executed first.
Figure 5 on page 305 illustrates the order of policer and firewall filter processing at the same interface.
Figure 5: Incoming and Outgoing Policers and Firewall Filters
Two-Color Policer Configuration Overview on page 307 Three-Color Policer Configuration Overview on page 311 Hierarchical Policer Configuration Overview on page 314
Introduction to Policer Configuration

Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Three-Color Policer Configuration Overview on page 311 Hierarchical Policer Configuration Overview on page 314 Guidelines for Applying Traffic Policers on page 316
Statement Hierarchy for Configuring Policers

firewall { family (any | bridge | ccc | inet | inet6 | mpls | vpls) { filter filter-name { ... protocol-family-specific-firewall-filter-configuration ... prefix-action name { count; destination-prefix-length prefix-length; policer policer-name; source-prefix-length prefix-length; subnet-prefix-length prefix-length; } } } filter filter-name { accounting-profile [ profile-names ]; interface-specific; physical-interface-filter; term term-name { filter filter-name; from { ... ipv4-firewall-filter-match-conditions ... }
305
then { ... ipv4-firewall-filter-terminating-actions ... ... ipv4-firewall-filter-nonterminating-actions ... next term; } } } hierarchical-policer policer-name { aggregate { if-exceeding { bandwidth-limit-limit bps; burst-size-limit bytes; } then { discard; forwarding-class class-name; loss-priority (high | low | medium-high | medium-low); } } premium { if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } then { discard; } } } interface-set interface-set-name { interface-name; } load-balance-group group-name { next-hop-group [ group-names ]; } policer policer-name { filter-specific; if-exceeding { (bandwidth-limit bps | bandwidth-percent percentage); burst-size-limit bytes; } logical-bandwidth-policer; logical-interface-policer; physical-interface-policer; then { discard; forwarding-class class-name; loss-priority (high | low | medium-high | medium-low); } } three-color-policer policer-name { action { loss-priority high then discard; } logical-interface-policer; physical-interface-policer;
306
single-rate { (color-aware | color-blind); committed-burst-size bytes; committed-information-rate bps; excess-burst-size bytes; } two-rate { (color-aware | color-blind); committed-burst-size bytes; committed-information-rate bps; peak-burst-size bytes; peak-information-rate bps; } } }
Two-Color Policer Configuration Overview on page 307 Three-Color Policer Configuration Overview on page 311 Hierarchical Policer Configuration Overview on page 314 Guidelines for Applying Traffic Policers on page 316
Two-Color Policer Configuration Overview

Table 30 on page 307 describes the hierarchy levels at which you can configure and apply single-rate two-color policers to Layer 3 traffic. For information about applying single-rate two-color policers to Layer 2 traffic, see Two-Color Policing at Layer 2 Overview on page 444.
Table 30: Two-Color Policer Configuration and Application Overview

Policer Configuration Single-Rate Two-Color Policer
Defines traffic rate limiting that you can apply to Layer 3 protocol-specific traffic at a logical interface. Can be applied as an interface policer or as a firewall filter policer. Basic policer configuration: [edit firewall] policer policer-name { if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } then { discard; forwarding-class class-name; loss-priority supported-value; } } Method AApply as an interface policer at the protocol family level: [edit interfaces] interface-name { unit unit-number { family family-name { policer { input policer-name; output policer-name; } } } } Policer configuration:
Layer 3 Application
Key Points
Use bandwidth-limit bps to specify an absolute value.
Firewall filter configuration (*)
If applying to multiple interfaces, include the interface-specific statement to create unique policers and counters for each interface.
Interface policer verification:
Use the show interfaces

(detail | extensive)
operational mode command.
307
Table 30: Two-Color Policer Configuration and Application Overview (continued)

Policer Configuration Layer 3 Application
Method BApply as a firewall filter policer at the protocol family level: [edit firewall] family family-name { filter filter-name { interface-specific; # (*) from { ... match-conditions ... } then { policer policer-name; } } } [edit interfaces] interface-name { unit unit-number { family family-name { filter { input filter-name; output filter-name; } ... protocol-configuration ... } } }
Key Points
Use the show policer operational mode command.
Firewall filter policer verification:

Use the show firewall filter filter-name operational mode command.
308

Policer Configuration Bandwidth Policer
Defines traffic rate limiting that you can apply to Layer 3 protocol-specific traffic at a logical interface, but the bandwidth limit is specified as a percentage value. Bandwidth can be based on physical interface line rate (the default) or the logical interface shaping rate. Can be applied as an interface policer or as a firewall filter policer where the filter is either interface-specific or a physical interface filter. Bandwidth policer configuration: [edit firewall] policer policer-name {
logical-bandwidth-policer;
Layer 3 Application
Key Points
Method AApply as an interface policer at the protocol family level: [edit interfaces] interface-name { unit unit-number { family family-name { policer { input policer-name; output policer-name; } } } } Method BApply as a firewall filter policer at the protocol family level: [edit firewall] family family-name { filter filter-name { interface-specific; from { ... match-conditions ... } then { policer policer-name; } } } [edit interfaces] interface-name { unit unit-number { family family-name { filter { input filter-name; output filter-name; } ... protocol-configuration ... } } }
Policer configuration:
if-exceeding {
bandwidth-percent (1..100);
Use the bandwidth-percent percentage statement instead of the bandwidth-limit bps statement. By default, bandwidth policing rate-limits traffic based on a percentage of the physical interface media rate.
burst-size-limit bytes; } then { discard; forwarding-class class-name; loss-priority supported-value; } }
To rate-limit traffic based on a percentage of the logical interface configured shaping rate, also include the
logical-bandwidth-policer
statement. Firewall filter configuration:
Percentage bandwidth policers can only be referenced by filters configured with the interface-specific statement.


309

Policer Configuration Logical Interface (Aggregate) Policer
Defines traffic rate limiting that you can apply to multiple protocol families on the same logical interface without creating multiple instances of the policer. Can be applied directly to a logical interface configuration only. Logical interface policer configuration: [edit firewall] policer policer-name {
logical-interface-policer;
Layer 3 Application
Key Points
Apply as an interface policer only: [edit interfaces] interface-name { unit unit-number { policer { # All protocols input policer-name; output policer-name; } family family-name { policer { # One protocol input policer-name; output policer-name; } } } }
Include the
logical-interface-policer
statement. Two options for interface policer application:
if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } then { discard; forwarding-class class-name; loss-priority supported-value; } }
To rate-limit all traffic types, regardless of the protocol family, apply the logical interface policer at the logical unit level. To rate-limit traffic of a specific protocol family, apply the logical interface policer at the protocol family level.

310

Policer Configuration Physical Interface Policer
Defines traffic rate limiting that applies to all logical interfaces and protocol families configured on a physical interface, even if the interfaces belong to different routing instances. Can be applied as a firewall filter policer referenced from a physical interface filter only. Physical interface policer configuration: [edit firewall] policer policer-name {
physical-interface-policer;
Layer 3 Application
Key Points
Apply as a firewall filter policer referenced from a physical interface filter that you apply at the protocol family level: [edit firewall] family family-name { filter filter-name {
physical-interface-filter;
Include the
physical-interface-policer
if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } then { discard; forwarding-class class-name; loss-priority supported-value; } }
from { ... match-conditions ... } then { policer policer-name; } } } [edit interfaces] interface-name { unit number { family family-name { filter { input filter-name; output filter-name; } ... protocol-configuration ... } } }
Include the
physical-interface-filter
statement. Application:
Apply the filter to the input or output of a logical interface at the protocol family level.

Basic Single-Rate Two-Color Policers on page 327 Bandwidth Policers on page 343 Filter-Specific Counters and Policers on page 352 Prefix-Specific Counting and Policing Actions on page 359 Multifield Classification on page 375 Policer Overhead to Account for Rate Shaping in the Traffic Manager on page 390 Two-Color and Three-Color Physical Interface Policers on page 427
Three-Color Policer Configuration Overview

Table 31 on page 312 describes the hierarchy levels at which you can configure and apply single-rate tricolor-marking (single-rate TCM) policers and two-rate tricolor-marking
311
(two-rate TCM) policers to Layer 3 traffic. For information about applying three-color policers to Layer 2 traffic, see Three-Color Policing at Layer 2 Overview on page 446.
Table 31: Three-Color Policer Configuration and Application Overview

Policer Configuration Single-Rate Three-Color Policer
Defines traffic rate limiting that you can apply to Layer 3 protocol-specific traffic at a logical interface. Can be applied as a firewall filter policer only. Provides moderate allowances for short periods of traffic that exceed the committed burst size. Basic single-rate TCM policer configuration: [edit firewall] three-color-policer policer-name { single-rate { (color-aware | color-blind); committed-information-rate bps; committed-burst-size bytes; excess-burst-size bytes; } action { loss-priority high then discard; } } Reference the policer from a firewall filter, and apply the filter to a protocol family on a logical interface: [edit firewall] family family-name { filter filter-name { term term-name { from { ... match-conditions ... } then { three-color-policer { single-rate policer-name; } } } } } Apply the filter to a logical interface at the protocol family level: [edit interfaces] interface-name { unit unit-number { family family-name { filter { input filter-name; output filter-name; } } } } Policer configuration:
Layer 3 Application
Key Points
Include the single-rate

(color-aware | color-blind)
Include the three-color-policer

single-rate policer-name
action. Applying the firewall filter to the logical interface:
Include the filter (input |

output) filter-name
statement.
312
Table 31: Three-Color Policer Configuration and Application Overview (continued)

Policer Configuration Layer 3 Application Key Points
Single-Rate Three-Color Physical Interface Policer

Defines traffic rate limiting that applies to all logical interfaces and protocol families configured on a physical interface, even if the interfaces belong to different routing instances. Can be applied as a firewall filter policer only. Physical interface single-rate TCM policer: [edit firewall] three-color-policer policer-name { physical-interface-policer; single-rate { (color-aware | color-blind); committed-information-rate bps; committed-burst-size bytes; excess-burst-size bytes; } action { loss-priority high then discard; } } Reference the policer from a physical interface filter only, and apply the filter to a protocol family on a logical interface: [edit firewall] family family-name { filter filter-name {
Include the
term term-name { from { ... match-conditions ... } then { three-color-policer { single-rate policer-name; } } } } } [edit interfaces] interface-name { unit number { family family-name { filter { input filter-name; output filter-name; } } } }
Include the
statement. Application:

output) filter-name
statement. Verification
To verify, use the show

firewall filter filter-name
313
Table 31: Three-Color Policer Configuration and Application Overview (continued)

Policer Configuration Basic Two-Rate Three-Color Policer
Defines traffic rate limiting that you can apply to Layer 3 protocol-specific traffic at a logical interface. Can be applied as a firewall filter policer only. Provides moderate allowances for sustained periods of traffic that exceed the committed bandwidth limit or burst size. Basic two-rate TCM policer configuration: [edit firewall] three-color-policer policer-name { two-rate { (color-aware | color-blind); committed-information-rate bps; committed-burst-size bytes; peak-information-rate bps; peak-burst-size bytes; } action { loss-priority high then discard; } } Reference the policer from a firewall filter, and apply the filter to a protocol family on a logical interface: [edit firewall] family family-name { filter filter-name { term term-name { from { ... match-conditions ... } then { three-color-policer { two-rate policer-name; } } } } } [edit interfaces] interface-name { unit unit-number { family family-name { filter { input filter-name; output filter-name; } } } } Policer configuration:
Layer 3 Application
Key Points
Include the two-rate

(color-aware | color-blind)
Include the three-color-policer two-rate policer-name action.
Applying the firewall filter to the logical interface:

output) filter-name
statement.
Three-Color Policer Configuration Guidelines on page 399 Basic Single-Rate Three-Color Policers on page 401 Basic Two-Rate Three-Color Policers on page 407 Two-Color and Three-Color Logical Interface Policers on page 415 Two-Color and Three-Color Physical Interface Policers on page 427
Hierarchical Policer Configuration Overview

Table 32 on page 315 describes the hierarchy levels at which you can configure and apply hierarchical policers.
314
Table 32: Hierarchical Policer Configuration and Application Summary

Policer Configuration Hierarchical Policer
Hierarchically rate-limits Layer 2 ingress traffic for all protocol families. Cannot be applied to egress traffic, Layer 3 traffic, or at a specific protocol level of the interface hierarchy. Supported on the following interfaces:

Layer 2 Application
Key Points
SONET interfaces hosted on M40e, M120, and M320 edge routers with incoming FPCs as SFPC and outgoing FPCs as FFPC. SONET interfaces hosted on T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs. Ethernet interfaces on Gigabit Ethernet Intelligent Queuing 2 (IQ2) and Ethernet Enhanced IQ2 (IQ2E) PICs. Interfaces on DPCs in MX Series routers. Option AApply directly to Layer 2 input traffic on a physical interface: [edit interfaces] interface-name { layer2-policer { input-hierarchical-policer policer-name; } } Hierarchically rate-limit Layer 2 ingress traffic for all protocol families and logical interfaces configured on a physical interface. Include the layer2-policer configuration statement at the
[edit interfaces interface-name]
Aggregate and premium policing components of a hierarchical policer: [edit firewall] hierarchical-policer policer-name { aggregate { if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } then { discard; forwarding-class class-name; loss-priority supported-value; } } premium { if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } then { discard; } } }
hierarchy level. NOTE: If you apply a hierarchical policer at a physical interface, you cannot also apply a hierarchical policer to any of the member logical interfaces. Option BApply directly to Layer 2 input traffic on a logical interface. [edit interfaces] interface-name { unit unit-number { layer2-policer { input-hierarchical-policer policer-name; } } } Hierarchically rate-limit Layer 2 ingress traffic for all protocol families configured on a specific logical interface. Include the layer2-policer configuration statement at the
[edit interfaces interface-name unit unit-number] hierarchy level.
NOTE: You must configure at least one protocol family for the logical interface.
Hierarchical Policers on page 437
315
Guidelines for Applying Traffic Policers

The following general guidelines pertain to applying traffic policers:
Only one type of policer can be applied to the input or output of the same physical or logical interface. For example, you are not allowed to apply a policer and a hierarchical policer in the same direction at the same logical interface. Chaining of policersthat is, applying policers to both a port and the logical interfaces of that portis not allowed. A maximum of 64 policers is supported per physical or logical interface, provided no behavior aggregate (BA) classificationtraffic classification based on CoS values in the packet headersis applied to the logical interface. The policer should be independent of BA classification. Without BA classification, all traffic on an interface is treated either as expedited forwarding (EF) or non-EF, based on the configuration. With BA classification, a physical or logical interface can support up to 64 policers. The interface might be a physical interface or logical interface. With BA classification, the miscellaneous traffic (the traffic not matching any of the BA classification DSCP/EXP bits) is policed as non-EF traffic. No separate policers are installed for this traffic. Policers can be applied to unicast packets only. For information about configuring a filter for flooded traffic, see Applying Filters to Forwarding Tables in the Traffic Sampling, Forwarding, and Monitoring section of the Junos OS Routing Policy Configuration Guide. Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Three-Color Policer Configuration Overview on page 311 Hierarchical Policer Configuration Overview on page 314
Introduction to Policer Rate Limits and Actions

Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Single Token Bucket Algorithm on page 319 Dual Token Bucket Algorithms on page 321 Calculation of Policer Burst-Size Limit on page 323
Policer Bandwidth and Burst-Size Limits

Table 33 on page 317 lists each of the Junos OS policer types supported. For each policer type, the table summarizes the bandwidth limits and burst-size limits used to rate-limit traffic.
316
Table 33: Policer Bandwidth Limits and Burst-Size Limits

Policer Type Single-Rate Two-Color Policer
Defines a single rate limit: a bandwidth limit and an allowed burst size for conforming traffic. For a single-rate two-color policer only, you can specify the bandwidth limit as a percentage value from 1 through 100 instead of as an absolute number of bits per second. The effective bandwidth limit is calculated as a percentage of either the physical interface media rate or the logical interface configured shaping rate.
bandwidth-limit bps;
M, MX, and T Series routers:
Bandwidth Limits
Burst-Size Limits
burst-size-limit bytes;
8000..50000000000
bandwidth-percent
1500..10000000000
1..100 percent
Single-Rate Three-Color Policer

Defines a single rate limit: a bandwidth limit and an allowed burst size for conforming traffic. Also defines a second, larger burst size. This second burst size is used to differentiate between two categories of nonconforming traffic (yellow or red).
committed-information-rate bps;
committed-burst-size bytes;
1500..100000000000
1500..100000000000
excess-burst-size bytes;
1500..100000000000
Two-Rate Three-Color Policer

Defines a committed rate limit: a bandwidth limit and an allowed burst size for conforming traffic. Also defines a peak rate limit: a second, larger burst size and a second, higher bandwidth limit. These additional rate-limit components are used to differentiate between two categories of nonconforming traffic (yellow or red).
committed-information-rate bps;
committed-burst-size bytes;
1500..100000000000
peak-information-rate bps;
1500..100000000000
peak-burst-size bytes;
1500..100000000000
1500..100000000000
Hierarchical Policer
Defines two policers, each with a bandwidth limit and an allowed burst size for conforming traffic. Different policing actions are applied based on whether the packets are classified for expedited forwarding (EF) or for a lower priority. Rate-limits ingress Layer 2 traffic at a SONET physical or logical interface hosted on supported routing platforms only.
bandwidth-limit bps;
M40e, M120, and M320 (with FFPC and SFPC) edge routers and T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs:
burst-size-limit bytes;
M40e, M120, and M320 (with FFPC and SFPC) edge routers and T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs:
32000..50000000000
1500..2147450880
Policer Color-Marking and Actions on page 318 Calculation of Policer Burst-Size Limit on page 323
317
Policer Color-Marking and Actions

Table 34 on page 318 lists each of the Junos OS policer types supported. For each policer type, the table summarizes the color-marking criteria used to categorize a traffic flow and, for each color, the actions taken on packets in that type of traffic flow.
Table 34: Implicit and Configurable Policer Actions Based on Color Marking
Policer Rate Limits and Color Marking Single-Rate Two-Color Policer

Implicit Action
Configurable Actions
Bandwidth limit Burst size Green Conforms to rate and burst size limits Red Exceeds rate and burst size limits Set PLP to low
Discard the packet. Assign to a forwarding class. Set PLP to low or high. On some platforms, you can also set the PLP to medium-low or medium-high.
Single-Rate Three-Color Policer

Committed information rate (CIR) Committed burst size (CBS) Excess burst size (EBS) Green Conforms to the CIR and CBS Yellow Exceeds the CIR and CBS but conforms to the EBS Red Exceeds the EBS Set PLP to low
Set PLP to medium-high
Set PLP to high
Discard the packet.
Two-Rate Three-Color Policer

Committed information rate (CIR) Committed burst size (CBS) Peak information rate (PIR) Peak burst size (PBS)
318
Table 34: Implicit and Configurable Policer Actions Based on Color Marking (continued)
Policer Rate Limits and Color Marking
Green Conforms to the CIR and CBS Yellow Exceeds the CIR and CBS, but conforms to the PIR Red Exceeds the PIR and PBS
Implicit Action
Set PLP to low
Configurable Actions
Set PLP to medium-high
Set PLP to high
Discard the packet.
Hierarchical Policer
Aggregate policer

Bandwidth limit Burst size Green Conforms to rate limits Red Exceeds rate limits Set PLP to low
Discard the packet. Assign to a forwarding class. Set PLP to low or high. On some platforms, you can also set the PLP to medium-low or medium-high.
Premium policer

Bandwidth limit Burst size Green Conforms to rate limits Red Exceeds rate limits Set PLP to low
Discard the packet.
Policer Bandwidth and Burst-Size Limits on page 316 Calculation of Policer Burst-Size Limit on page 323
Single Token Bucket Algorithm


Token Bucket Concepts on page 320 Single Token Bucket Algorithm on page 320 Conformance Measurement for Two-Color Marking on page 321
319
Token Bucket Concepts

When you apply traffic policing to the input or output traffic at an interface, the rate limits and actions specified in the policer configuration are used to enforce a limit on the average throughput rate at the interface while also allowing bursts of traffic up to a maximum number of bytes based on the overall traffic load. Junos OS policers measure traffic-flow conformance to a policing rate limit by using a token bucket algorithm:
The bucket represents a rate-limiting function of the policer on the interface input or output traffic. Each token in the bucket represents a credit for some number of bits, and tokens in the bucket are cashed in for the ability to receive or transmit traffic that conforms to a rate limit configured for the policer. The token arrival rate is the fixed bits-per-second rate at which tokens are added to the token bucket, but only up to the specified depth of the bucket. The token bucket depth defines the capacity of the bucket in bytes.
An algorithm based on a single token bucket allows burst of traffic for short periods, whereas an algorithm based dual token buckets allows more sustained bursts of traffic.
Single Token Bucket Algorithm

A single-rate two-color policer limits traffic throughput at an interface based on how the traffic conforms to rate-limit values specified in the policer configuration. Similarly, a hierarchical policer limits traffic throughput at an interface based on how aggregate and premium traffic subflows conform to aggregate and premium rate-limit values specified in the policer configuration. For both two-color policer types, packets in a conforming traffic flow are categorized as green, and packets in a non-conforming traffic flow are categorized as red. The single token bucket algorithm measures traffic-flow conformance to a two-color policer rate limit as follows:
The token arrival rate represents the single bandwidth limit configured for the policer. You can specify the bandwidth limit as an absolute number of bits per second by including the bandwidth-limit bps statement. Alternatively, for single-rate two-color policers only, you can use the bandwidth-percent percentage statement to specify the bandwidth limit as a percentage of either the physical interface port speed or the configured logical interface shaping rate. The token bucket depth represents the single burst size configured for the policer. You specify the burst size by including the burst-size-limit bytes statement. If the bucket is filled to capacity, arriving tokens overflow the bucket and are lost.
When the bucket contains insufficient tokens for receiving or transmitting the traffic at the interface, packets might be dropped or else re-marked with a lower forwarding class, a higher packet loss priority (PLP) level, or both.
320
Conformance Measurement for Two-Color Marking

In two-color-marking policing, a traffic flow whose average arrival or departure rate does not exceed the token arrival rate (bandwidth limit) is considered conforming traffic. Packets in a conforming traffic flow (categorized as green traffic) are implicitly marked with a packet loss priority (PLP) level of low and then passed through the interface. For a traffic flow whose average arrival or departure rate exceeds the token arrival rate, conformance to a two-color policer rate limit depends on the tokens in the bucket. If sufficient tokens remain in the bucket, the flow is considered conforming traffic. If the bucket does not contain sufficient tokens, the flow is considered non-conforming traffic. Packets in a non-conforming traffic flow (categorized as red traffic) are handled according to policing actions. Depending on the configuration of the two-color policer, packets might be implicitly discarded; or the packets might be re-marked with a specified forwarding class, a specified PLP, or both, and then passed through the interface.
NOTE: The number of tokens remaining in the bucket at any given time is a function of the token bucket depth and the overall traffic load.
The token bucket is initially filled to capacity, and so the policer allows an initial traffic burst (back-to-back traffic at average rates that exceed the token arrival rate) up to the size of the token bucket depth. During periods of relatively low traffic (traffic that arrives at or departs from the interface at average rates below the token arrival rate), unused tokens accumulate in the bucket, but only up to the configured token bucket depth. Related Documentation

Two-Color Policer Configuration Overview on page 307 Hierarchical Policer Configuration Overview on page 314 Policer Color-Marking and Actions on page 318 bandwidth-limit (Hierarchical Policer) on page 458 bandwidth-limit (Policer) on page 459 bandwidth-percent on page 461 burst-size-limit (Hierarchical Policer) on page 463 burst-size-limit (Policer) on page 464
Dual Token Bucket Algorithms


Token Bucket Concepts on page 322 Guaranteed Bandwidth for Three-Color Marking on page 322 Nonconformance Measurement for Single-Rate Three-Color Marking on page 322 Nonconformance Measurement for Two-Rate Three-Color Marking on page 323
321
Token Bucket Concepts

When you apply traffic policing to the input or output traffic at an interface, the rate limits and actions specified in the policer configuration are used to enforce a limit on the average throughput rate at the interface while also allowing bursts of traffic up to a maximum number of bytes based on the overall traffic load. Junos OS policers measure traffic-flow conformance to a policing rate limit by using a token bucket algorithm:
The bucket represents a rate-limiting function of the policer on the interface input or output traffic. Each token in the bucket represents a credit for some number of bits, and tokens in the bucket are cashed in for the ability to receive or transmit traffic that conforms to a rate limit configured for the policer. The token arrival rate is the fixed bits-per-second rate at which tokens are added to the token bucket, but only up to the specified depth of the bucket. The token bucket depth defines the capacity of the bucket in bytes.
An algorithm based on a single token bucket allows burst of traffic for short periods, whereas an algorithm based dual token buckets allows more sustained bursts of traffic.
Guaranteed Bandwidth for Three-Color Marking

A committed information rate (CIR) defines the guaranteed bandwidth for traffic arriving at or departing from the interface under normal line conditions. A flow of traffic at an average rate that conforms to the CIR is categorized green, and packets in a green flow are implicitly marked with low packet loss priority (PLP) and then passed through the interface. During periods of relatively low traffic (traffic that arrives at or departs from the interface at average rates below the CIR), any unused bandwidth capacity accumulates in the first token bucket, but only up to a configured number of bytes. If any unused bandwidth capacity overflows the first bucket, the excess accumulates in a second token bucket. The committed burst size (CBS) defines the maximum number of bytes for which unused amounts of the guaranteed bandwidth can be accumulated in the first token bucket. A burst of traffic at an average rate that exceeds the CIR is also categorized as green provided that sufficient unused bandwidth capacity is available in the first token bucket.
Nonconformance Measurement for Single-Rate Three-Color Marking

Single-rate three-color policer configurations specify a second burst sizethe excess burst size (EBS)that defines the maximum number of bytes for which the second token bucket can accumulate unused bandwidth that overflows from the first bucket. A traffic flow is categorized yellow if its average rate exceeds the CIR and the available bandwidth capacity accumulated in the first bucket if sufficient unused bandwidth capacity is available in the second token bucket. Packets in a yellow flow are implicitly marked with medium-high PLP and then passed through the interface.
322
A traffic flow is categorized red its average rate exceeds the CIR and the available bandwidth capacity accumulated in the second bucket. Packets in a red flow are implicitly marked with high PLP and then either passed through the interface or optionally discarded.
Nonconformance Measurement for Two-Rate Three-Color Marking

Two-rate three-color policer configurations include a second rate limitthe peak-information-rate (PIR)that you set to the expected average data rate for traffic arriving at or departing from the interface under peak conditions. Two-rate three-color policer configurations also include a second burst sizethe peak burst size (PBS)that defines the maximum number of bytes for which the second token bucket can accumulate unused peak bandwidth capacity. During periods of relatively little peak traffic (traffic that arrives at or departs from the interface at average rates that exceed the PIR), any unused peak bandwidth capacity accumulates in the second token bucket, but only up to the maximum number of bytes specified by the PBS. A traffic flow is categorized yellow if it exceeds the CIR and the available committed bandwidth capacity accumulated in the first token bucket but conforms to the PIR. Packets in a yellow flow are implicitly marked with medium-high PLP and then passed through the interface. A traffic flow is categorized red if it exceeds the PIR and the available peak bandwidth capacity accumulated in the second token bucket. Packets in a red flow are implicitly marked with high PLP and then either passed through the interface or optionally discarded. Related Documentation

Three-Color Policer Configuration Overview on page 311 Policer Color-Marking and Actions on page 318 committed-burst-size on page 468 committed-information-rate on page 470 excess-burst-size on page 472 peak-burst-size on page 488 peak-information-rate on page 490
Calculation of Policer Burst-Size Limit


Guidelines for Choosing a Burst-Size Limit on page 323 Burst-Size Limit Based on the Line Rate of the Interface on page 325 Burst-Size Limit Based on the MTU of Traffic on the Interface on page 325
Guidelines for Choosing a Burst-Size Limit

A policer burst-size limit controls the number of bytes of traffic that can pass through a policed interface unrestricted when a burst of traffic pushes the average transmit or receive rate above the configured bandwidth limit. The actual number of bytes of bursty
323
traffic allowed to pass through a policed interface can vary from zero to the configured burst-size limit, depending on the overall traffic load. Junos OS implements two-color policers using a single token bucket algorithm and implements three-color policers using a dual token bucket algorithm. In both of these models, the bits-per-second rate configured as a bandwidth limit is conceptualized the token arrival rate for a token bucket, and the number of bytes configured as a policer burst-size limit is conceptualized as the bucket depth for the corresponding bucket. The number of tokens remaining in the bucket at any given time is a function of the token bucket depth and the overall traffic load. The token bucket is initially filled to capacity, and so the policer allows an initial traffic burst (back-to-back traffic at average rates that exceed the token arrival rate) up to the size of the token bucket depth. During periods of relatively low traffic (traffic that arrives at or departs from the interface at average rates below the token arrival rate), unused tokens accumulate in the bucket, but only up to the configured token bucket depth.
NOTE: If you set the burst-size limit too low, too many packets will be subjected to rate-limiting. If you set the burst-size limit too high, too few packets will be rate-limited.
The following general guidelines apply to choosing a policer burst-size limit:
A burst-size limit should not be set lower than 10 times the maximum transmission unit (MTU) of the traffic on the interface to be policed. The amount of time to allow a burst of traffic at the full line rate of a policed interface should not be lower than 5 milliseconds. The minimum and maximum values you can specify for a policer burst-size limit depends on the policer type (two-color, three-color, or hierarchical). For more information, see Policer Bandwidth and Burst-Size Limits on page 316.
BEST PRACTICE: The preferred method for choosing a burst-size limit is based on the line rate of the interface on which you apply the policer and the amount of time you want to allow a burst of traffic at the full line rate.
In cases where the line rate of the target interface is unknown, you can choose a burst-size limit based on the MTU of the traffic on the target interface.
324
Burst-Size Limit Based on the Line Rate of the Interface

To calculate the burst-size limit based on the line rate of the interface:
Multiply the interface line rate (in bits per second) by the amount of time (in seconds) to allow a burst of traffic at the full line rate, and then divide by 8 bits to convert from bits to bytes. burst-size limit in bytes = interface media rate x allowable time for bursty traffic / 8 bits
We recommend that you use a value of 5 ms (0.005 seconds) as the starting point for the allowable amount of time for a burst of traffic. Table 35 on page 325 shows example calculations of burst-size limits for various physical interface types.
Table 35: Example Calculations of Policer Burst-Size Limit

Target Interface Type DS3 Line Rate
45 Mbps
Allowed Burst Period

5 ms
Calculation of Policer Burst-Size Limit Based on a Target Interface Line Rate and an Allowed Burst Period
45,000,000 bps x 0.005 seconds x 1 byte / 8 bits = 28,125 bytes 100,000,000 bps x 0.005 seconds x 1 byte / 8 bits = 62,500 bytes 1,000,000,000 bps x 0.005 seconds x 1 byte / 8 bits = 625,000 bytes 10,000,000,000 bpsm x 0.005 seconds x 1 byte / 8 bits = 6,250,000 bytes
Fast Ethernet Gigabit Ethernet 10-Gigabit Ethernet
100 Mbps
5 ms
1000 Mbps
5 ms
10,000 Mbps
5 ms
Burst-Size Limit Based on the MTU of Traffic on the Interface

To calculate the burst-size limit based on the MTU of traffic on the interface:
Multiply the interface traffic MTU by a factor of 10 or greater. At the minimum, the burst size should be at least one interface MTU. burst-size limit in bytes = interface traffic MTU x 10
For example, suppose that you are configuring a policer for an interface that carries traffic with an MTU of 4700 bytes. The recommended burst-size limit is 47,000 bytes or greater. Related Documentation

Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Single Token Bucket Algorithm on page 319
325
Dual Token Bucket Algorithms on page 321
Supported Standards for Policing

Three-color policers are part of an assured forwarding (AF) per-hop-behavior (PHB) classification system for a Differentiated Services (DiffServ) environment, which is described and defined in the following RFCs:
RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 2475, An Architecture for Differentiated Service RFC 2597, Assured Forwarding PHB Group RFC 2598, An Expedited Forwarding PHB RFC 2698, A Two Rate Three Color Marker
In a DiffServ environment, the most significant 6 bits of the type-of-service (ToS) octet in the IP header contain a value called the Differentiated Services code point (DSCP). Within the DSCP field, the most significant 3 bits are interpreted as the IP precedence field, which can be used to select different per-hop forwarding treatments for the packet.
326
CHAPTER 11
Single-Rate Two-Color Policer Configuration

This chapter covers two-color policing applied to Layer 3 traffic.

Basic Single-Rate Two-Color Policers on page 327 Bandwidth Policers on page 343 Filter-Specific Counters and Policers on page 352 Prefix-Specific Counting and Policing Actions on page 359 Multifield Classification on page 375 Policer Overhead to Account for Rate Shaping in the Traffic Manager on page 390
Basic Single-Rate Two-Color Policers

Single-Rate Two-Color Policer Overview on page 327 Example: Configuring a Single-Rate Two-Color Policer on page 328 Example: Configuring Interface and Firewall Filter Policers at the Same Interface on page 334
Single-Rate Two-Color Policer Overview

Single-rate two color policing enforces a configured rate of traffic flow for a particular service level by applying implicit or configured actions to traffic that does not conform to the limits. When you apply a single-rate two-color policer to the input or output traffic at an interface, the policer meters the traffic flow to the rate limit defined by the following components:
Bandwidth limitThe average number of bits per second permitted for packets received or transmitted at the interface. You can specify the bandwidth limit as an absolute number of bits per second or as a percentage value from 1 through 100. If a percentage value is specified, the effective bandwidth limit is calculated as a percentage of either the physical interface media rate or the logical interface configured shaping rate. Burst-size limitThe maximum size permitted for bursts of data.
327
For a traffic flow that conforms to the configured limits (categorized as green traffic), packets are implicitly marked with a packet loss priority (PLP) level of low and are allowed to pass through the interface unrestricted. For a traffic flow that exceeds the configured limits (categorized as red traffic), packets are handled according to the traffic-policing actions configured for the policer. The action might be to discard the packet, or the action might be to re-mark the packet with a specified forwarding class, a specified PLP, or both, and then transmit the packet. To rate-limit Layer 3 traffic, you can apply a two-color policer in the following ways:

Directly to a logical interface, at a specific protocol level. As the action of a standard stateless firewall filter that is applied to a logical interface, at a specific protocol level.
To rate-limit Layer 2 traffic, you can apply a two-color policer as a logical interface policer only. You cannot apply a two-color policer to Layer 2 traffic through a firewall filter.
Example: Configuring a Single-Rate Two-Color Policer

This example shows how to configure a single-rate two-color policer that you apply to a logical interface as a firewall filter action.

Requirements
No special configuration beyond device initialization is required before configuring this example. To set the maximum burst size of the policer, you should know the line rate of the interface (preferred) or else the maximum transmission unit (MTU) of the traffic on the target interface.
Overview
In this example, you configure a single-rate two-color policer and then use an IPv4 firewall filter to apply the policer to all traffic except for BGP messages. You apply the firewall filter to the input and output of the same logical interface. Topology Assume that you know the traffic flow needs to be rate-limited to an average bandwidth of 9 Mbps. Also assume that you do not know the line rate of the target interface, but you do know that the MTU of traffic on the interface is 4700 bytes. As described in Calculation of Policer Burst-Size Limit on page 323, you can estimate a starting value of 10 times the MTU.
328
Chapter 11: Single-Rate Two-Color Policer Configuration
Configuration
Configuring the Logical Interface and Monitoring the Traffic Rate Without Policing on page 329 Configuring the Basic Single-Rate Two-Color Policer on page 330 Referencing the Policer from a Term in a Stateless Firewall Filter on page 331 Applying the Firewall Filter to the Input and Output of the Logical Interface on page 332
set interfaces so-1/3/0 unit 0 family inet address 10.39.1.1/16 set firewall policer p-9m-47k-discard if-exceeding bandwidth-limit 9m set firewall policer p-9m-47k-discard if-exceeding burst-size-limit 47k set firewall policer p-9m-47k-discard then discard set firewall family inet filter rate-limit-in term t1 from protocol tcp set firewall family inet filter rate-limit-in term t1 from port bgp set firewall family inet filter rate-limit-in term t1 then accept set firewall family inet filter rate-limit-in term t2 then policer p-9m-47k-discard set firewall family inet filter rate-limit-in term t2 then accept set interfaces so-1/3/0 unit 0 family inet filter input rate-limit-in set interfaces so-1/3/0 unit 0 family inet filter output rate-limit-in
Configuring the Logical Interface and Monitoring the Traffic Rate Without Policing Step-by-Step Procedure To configure the logical interface and monitor the traffic rate:
1.
Configure IPv4 on the logical interface.

[edit] user@host# edit interfaces so-1/3/0 unit 0 family inet address 10.39.1.1/16
2.
Commit the configuration.

3.
Monitor the traffic flow at the interface (press q to terminate monitoring).

[edit] user@host# run monitor interface so-1/3/0.0
The traffic statistics report the input and output rates before applying interface rate limiting.
329
Results
Confirm the configuration of the logical interface by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces so-3/3/0 { unit 0 { family inet { address 10.39.1.1/16 } } }
Configuring the Basic Single-Rate Two-Color Policer Step-by-Step Procedure To configure the basic single-rate two-color policer:
1.
Enable configuration of a single-rate two-color policer.

[edit] user@host# edit firewall policer p-9m-47k-discard
NOTE: This example illustrates a basic two-color policer, which does not require any of the following statements:
filter-specificYou can include this statement so that, when this
policer is applied as a firewall filter policer, a single instance of the policer is used by all terms within the same firewall filter.
logical-bandwidth-policerInclude this statement only if the policer
bandwidth limit is specified as a percentage value (using the bandwidth-percent percent statement) and you want the bandwidth limit to be based on the configured shaping rate for the target logical interface.
logical-interface-policerInclude this statement only if you apply the
policer directly to a physical or logical interface to rate-limit traffic for any configured protocol family based on the physical interface media rate.
physical-interface-policerInclude this statement if you apply the
policer to packets filtered by a standard stateless firewall filter term and you want the policer to meter the aggregate traffic (all protocol families and logical interfaces configured on the underlying physical interface).
2.
Configure the policer to rate-limit to an average bandwidth of 9 Mbps and a burst size of 47 KB.
[edit firewall policer p-9m-47k-discard]
330
user@host# set if-exceeding bandwidth-limit 9m user@host# set if-exceeding burst-size-limit 47k
For information about configuring the burst size, see Calculation of Policer Burst-Size Limit on page 323. When the traffic flow conforms to these limits, the flow is categorized as green. For a single-rate two-color policer, packets in a green flow are implicitly set to a low packet loss priority (PLP) level.
3.
Configure the policer to discard packets in a red traffic flow.

[edit firewall policer p-9m-47k-discard] user@host# set then discard
Instead of discarding the traffic that exceeds the traffic limits, you can set the PLP level, the forwarding class assignment, or both. Results Confirm the configuration of the policer by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall policer p-9m-47k-discard { if-exceeding { bandwidth-limit 9m; burst-size-limit 47k; } then discard; }
Referencing the Policer from a Term in a Stateless Firewall Filter Step-by-Step Procedure To reference the policer from a term in a stateless firewall filter:
1.
Enable configuration of the stateless firewall filter.

[edit] user@host# edit firewall family inet filter rate-limit-in
2.
Configure the first term to accept all BGP traffic. BGP messages are transported over TCP port 179.
[edit firewall family inet filter rate-limit-in] user@host# set term t1 from protocol tcp user@host# set term t1 from port bgp user@host# set term t1 then accept
The BGP traffic is not rate-limited to avoid having the BGP session time out because the packet is discarded by the policer.
3.
Configure the second term to rate-limit all other traffic using the policer.
[edit firewall family inet filter rate-limit-in] user@host# set term t2 then policer p-9m-47k-discard user@host# set term t2 then accept
331
Results
Confirm the configuration of the firewall filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall family inet { filter rate-limit-in { term t1 { from { protocol tcp; port bgp; } then accept; } term t2 { then { policer p-9m-47k-discard; accept; } } } } policer p-9m-47k-discard { if-exceeding { bandwidth-limit 9m; burst-size-limit 47k; } then discard; }
Applying the Firewall Filter to the Input and Output of the Logical Interface Step-by-Step Procedure To apply the stateless firewall filter to the input and output of the logical interface:
1.
Enable configuration of IPv4 on the logical interface.

2.
Apply the stateless firewall filter.

[edit interfaces so-1/3/0 unit 0 family inet] user@host# set filter input rate-limit-in user@host# set filter output rate-limit-in
Results
Confirm the configuration of the logical interface by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces so-3/3/0 { unit 0 { family inet { filter {
332
input rate-limit-in; output rate-limit-in; } address 10.39.1.1/16; } } }
Verification

Monitoring and Adjusting Policing of the Logical Interface on page 333 Displaying the Number of Packets Processed by the Policer at the Logical Interface on page 333
Monitoring and Adjusting Policing of the Logical Interface Purpose Ensure that the traffic limits configured in the policer are throttling the input and output rate as you intended. To ensure that the configured traffic limits are throttling the traffic rate as intended:
1.
Action
Monitor the traffic flow at the interface (press q to terminate monitoring).

[edit] user@host# run monitor interface so-1/3/0.0
The traffic statistics report the input and output rate after applying interface rate limiting.
2. Adjust the burst-size limit if necessary.
If the policer appears to be throttling the input and output rate more than you intended, increase the burst size (possibly doubling it) and then check again. Displaying the Number of Packets Processed by the Policer at the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface. Use the show firewall operational mode command for the filter you applied to the logical interface:
[edit] user@host# run show firewall filter rate-limit-in Filter: rate-limit-in Policers: Name p-9m-47k-discard-t2
Action
Packets 32863
The command output displays the name of policer (p-9m-47k-discard), the name of the filter term (t2) under which the policer action is specified, and the number of packets
333
that matched the filter term. This is only the number of out-of-specification (out-of-spec) packet counts, not all packets policed by the policer.
Example: Configuring Interface and Firewall Filter Policers at the Same Interface
This example shows how to configure three single-rate two-color policers and apply the policers to the IPv4 input traffic at the same single-tag virtual LAN (VLAN) logical interface.

Requirements
Overview
In this example, you configure three single-rate two-color policers and apply the policers to the IPv4 input traffic at the same single-tag VLAN logical interface. Two policers are applied to the interface through a firewall filter, and one policer is applied directly to the interface. You configure one policer, named p-all-1m-5k-discard, to rate-limit traffic to 1 Mbps with a burst size of 5000 bytes. You apply this policer directly to IPv4 input traffic at the logical interface. When you apply a policer directly to protocol-specific traffic at a logical interface, the policer is said to be applied as an interface policer. You configure the other two policers to allow burst sizes of 500 KB, and you apply these policers to IPv4 input traffic at the logical interface by using an IPv4 standard stateless firewall filter. When you apply a policer to protocol-specific traffic at a logical interface through a firewall filter action, the policer is said to be applied as a firewall-filter policer.
You configure the policer named p-icmp-500k-500k-discard to rate-limit traffic to 500 Kbps with a burst size of 500 K bytes by discarding packets that do not conform to these limits. You configure one of the firewall filter terms to apply this policer to Internet Control Message Protocol (ICMP) packets. You configure the policer named p-ftp-10p-500k-discard to rate-limit traffic to a 10 percent bandwidth with a burst size of 500 KB by discarding packets that do not conform to these limits. You configure another firewall-filter term to apply this policer to File Transfer Protocol (FTP) packets.
A policer that you configure with a bandwidth limit expressed as a percentage value (rather than as an absolute bandwidth value) is called a bandwidth policer. Only single-rate two-color policers can be configured with a percentage bandwidth specification. By default, a bandwidth policer rate-limits traffic to the specified percentage of the line rate of the physical interface underlying the target logical interface.
334
Topology You configure the target logical interface as a single-tag VLAN logical interface on a Fast Ethernet interface operating at 100 Mbps. This means that the policer you configure with the 10-percent bandwidth-limit (the policer that you apply to FTP packets) rate-limits the FTP traffic on this interface to 10 Mbps.
NOTE: In this example, you do not configure the bandwidth policer as a logical-bandwidth policer. Therefore, the percentage is based on the physical media rate rather than on the configured shaping rate of the logical interface.
The firewall filter that you configure to reference two of the policers must be configured as an interface-specific filter. Because the policer that is used to rate-limit FTP packets specifies the bandwidth limit as a percentage value, the firewall filter that references this policer must be configured as an interface-specific filter. Thus, if this firewall filter were to be applied to multiple interfaces instead of just the Fast Ethernet interface in this example, unique policers and counters would be created for each interface to which the filter is applied.
Configuration

Configuring the Single-Tag VLAN Logical Interface on page 336 Configuring the Three Policers on page 337 Configuring the IPv4 Firewall Filter on page 339 Applying the Interface Policer and Firewall Filter Policers to the Logical Interface on page 340
set interfaces fe-0/1/1 vlan-tagging set interfaces fe-0/1/1 unit 0 vlan-id 100 set interfaces fe-0/1/1 unit 0 family inet address 10.20.15.1/24 set interfaces fe-0/1/1 unit 1 vlan-id 101 set interfaces fe-0/1/1 unit 1 family inet address 10.20.240.1/24 set firewall policer p-all-1m-5k-discard if-exceeding bandwidth-limit 1m set firewall policer p-all-1m-5k-discard if-exceeding burst-size-limit 5k set firewall policer p-all-1m-5k-discard then discard set firewall policer p-ftp-10p-500k-discard if-exceeding bandwidth-percent 10 set firewall policer p-ftp-10p-500k-discard if-exceeding burst-size-limit 500k set firewall policer p-ftp-10p-500k-discard then discard set firewall policer p-icmp-500k-500k-discard if-exceeding bandwidth-limit 500k set firewall policer p-icmp-500k-500k-discard if-exceeding burst-size-limit 500k set firewall policer p-icmp-500k-500k-discard then discard
335
set firewall family inet filter filter-ipv4-with-limits interface-specific set firewall family inet filter filter-ipv4-with-limits term t-ftp from protocol tcp set firewall family inet filter filter-ipv4-with-limits term t-ftp from port ftp set firewall family inet filter filter-ipv4-with-limits term t-ftp from port ftp-data set firewall family inet filter filter-ipv4-with-limits term t-ftp then policer p-ftp-10p-500k-discard set firewall family inet filter filter-ipv4-with-limits term t-icmp from protocol icmp set firewall family inet filter filter-ipv4-with-limits term t-icmp then policer p-icmp-500k-500k-discard set firewall family inet filter filter-ipv4-with-limits term catch-all then accept set interfaces fe-0/1/1 unit 1 family inet filter input filter-ipv4-with-limits set interfaces fe-0/1/1 unit 1 family inet policer input p-all-1m-5k-discard
Configuring the Single-Tag VLAN Logical Interface Step-by-Step Procedure To configure the single-tag VLAN logical interface:
1.
Enable configuration of the Fast Ethernet interface.

[edit] user@host# edit interfaces fe-0/1/1
2.
Enable single-tag VLAN framing.

[edit interfaces fe-0/1/1] user@host# set vlan-tagging
3.
Bind VLAN IDs to the logical interfaces.

[edit interfaces fe-0/1/1] user@host# set unit 0 vlan-id 100 user@host# set unit 1 vlan-id 101
4.
Configure IPv4 on the single-tag VLAN logical interfaces.

[edit interfaces fe-0/1/1] user@host# set unit 0 family inet address 10.20.15.1/24 user@host# set unit 1 family inet address 10.20.240.1/24
Results
Confirm the configuration of the VLAN by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces fe-0/1/1 { vlan-tagging; unit 0 { vlan-id 100; family inet { address 10.20.15.1/24; } } unit 1 { vlan-id 101; family inet { address 10.20.240.1/24;
336
} } }
Configuring the Three Policers Step-by-Step Procedure To configure the three policers:
1.
Enable configuration of a two-color policer that discards packets that do not conform to a bandwidth of 1 Mbps and a burst size of 5000 bytes.
NOTE: You apply this policer directly to all IPv4 input traffic at the single-tag VLAN logical interface, so the packets will not be filtered before being subjected to rate limiting.
[edit] user@host# edit firewall policer p-all-1m-5k-discard

2.
Configure the first policer.

[edit firewall policer p-all-1m-5k-discard] user@host# set if-exceeding bandwidth-limit 1m user@host# set if-exceeding burst-size-limit 5k user@host# set then discard
3.
Enable configuration of a two-color policer that discards packets that do not conform to a bandwidth specified as 10 percent and a burst size of 500,000 bytes. You apply this policer only to the FTP traffic at the single-tag VLAN logical interface. You apply this policer as the action of an IPv4 firewall filter term that matches FTP packets from TCP.
[edit firewall policer p-all-1m-5k-discard] user@host# up [edit] user@host# edit firewall policer p-ftp-10p-500k-discard
4.
Configure policing limits and actions.

[edit firewall policer p-ftp-10p-500k-discard] user@host# set if-exceeding bandwidth-percent 10 user@host# set if-exceeding burst-size-limit 500k user@host# set then discard
Because the bandwidth limit is specified as a percentage, the firewall filter that references this policer must be configured as an interface-specific filter.
337
NOTE: If you wanted this policer to rate-limit to 10 percent of the logical interface configured shaping rate (rather than to 10 percent of the physical interface media rate), you would need to include the logical-bandwidth-policer statement at the [edit firewall policer p-all-1m-5k-discard] hierarchy level. This type of policer is called a logical-bandwidth policer.
5.
Enable configuration of the IPv4 firewall filter policer for ICMP packets.
[edit firewall policer p-ftp-10p-500k-discard] user@host# up [edit] user@host# edit firewall policer p-icmp-500k-500k-discard
6.
Configure policing limits and actions.

[edit firewall policer p-icmp-500k-500k-discard] user@host# set if-exceeding bandwidth-limit 500k user@host# set if-exceeding burst-size-limit 500k user@host# set then discard
Results
Confirm the configuration of the policers by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall policer p-all-1m-5k-discard { if-exceeding { bandwidth-limit 1m; burst-size-limit 5k; } then discard; } policer p-ftp-10p-500k-discard { if-exceeding { bandwidth-percent 10; burst-size-limit 500k; } then discard; } policer p-icmp-500k-500k-discard { if-exceeding { bandwidth-limit 500k; burst-size-limit 500k; } then discard; }
338
Configuring the IPv4 Firewall Filter Step-by-Step Procedure To configure the IPv4 firewall filter:
1.
Enable configuration of the IPv4 firewall filter.

[edit] user@host# edit firewall family inet filter filter-ipv4-with-limits
2.
Configure the firewall filter as interface-specific.

[edit firewall family inet filter filter-ipv4-with-limits] user@host# set interface-specific
The firewall filter must be interface-specific because one of the policers referenced is configured with a bandwidth limit expressed as a percentage value.
3.
Enable configuration of a filter term to rate-limit FTP packets.

[edit firewall family inet filter filter-ipv4-with-limits] user@host# edit term t-ftp [edit firewall family inet filter filter-ipv4-with-limits term t-ftp] user@host# set from protocol tcp user@host# set from port [ ftp ftp-data ]
FTP messages are sent over TCP port 20 (ftp) and received over TCP port 21 (ftp-data).
4.
Configure the filter term to match FTP packets.

[edit firewall family inet filter filter-ipv4-with-limits term t-ftp] user@host# set then policer p-ftp-10p-500k-discard
5.
Enable configuration of a filter term to rate-limit ICMP packets.

[edit firewall family inet filter filter-ipv4-with-limits term t-ftp] user@host# up [edit firewall family inet filter filter-ipv4-with-limits] user@host# edit term t-icmp
6.
Configure the filter term for ICMP packets

[edit firewall family inet filter filter-ipv4-with-limits term t-icmp] user@host# set from protocol icmp user@host# set then policer p-icmp-500k-500k-discard
7.
Configure a filter term to accept all other packets without policing.

[edit firewall family inet filter filter-ipv4-with-limits term t-icmp] user@host# up [edit firewall family inet filter filter-ipv4-with-limits] user@host# set term catch-all then accept
339
Results
[edit] user@host# show firewall family inet { filter filter-ipv4-with-limits { interface-specific; term t-ftp { from { protocol tcp; port [ ftp ftp-data ]; } then policer p-ftp-10p-500k-discard; } term t-icmp { from { protocol icmp; } then policer p-icmp-500k-500k-discard; } term catch-all { then accept; } } } policer p-all-1m-5k-discard { if-exceeding { bandwidth-limit 1m; burst-size-limit 5k; } then discard; } policer p-ftp-10p-500k-discard { if-exceeding { bandwidth-percent 10; burst-size-limit 500k; } then discard; } policer p-icmp-500k-500k-discard { if-exceeding { bandwidth-limit 500k; burst-size-limit 500k; } then discard; }
Applying the Interface Policer and Firewall Filter Policers to the Logical Interface Step-by-Step Procedure To apply the three policers to the VLAN:
1.

[edit]
340
user@host# edit interfaces fe-0/1/1 unit 1 family inet

2.
Apply the firewall filter policers to the interface.

[edit interfaces fe-0/1/1 unit 1 family inet] user@host# set filter input filter-ipv4-with-limits
3.
Apply the interface policer to the interface.

[edit interfaces fe-0/1/1 unit 1 family inet] user@host# set policer input p-all-1m-5k-discard
Input packets at fe-0/1/1.0 are evaluated against the interface policer before they are evaluated against the firewall filter policers. For more information, see Order of Policer and Firewall Filter Operations on page 304. Results Confirm the configuration of the interface by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces fe-0/1/1 { vlan-tagging; unit 0 { vlan-id 100; family inet { address 10.20.15.1/24; } } unit 1 { vlan-id 101; family inet { filter { input filter-ipv4-with-limits; } policer { input p-all-1m-5k-discard; } address 10.20.240.1/24; } } }
Verification

Displaying Policers Applied Directly to the Logical Interface on page 342 Displaying Statistics for the Policer Applied Directly to the Logical Interface on page 342 Displaying the Policers and Firewall Filters Applied to an Interface on page 342 Displaying Statistics for the Firewall Filter Policers on page 343
341
Displaying Policers Applied Directly to the Logical Interface Purpose Verify that the interface policer is evaluated when packets are received on the logical interface. Use the show interfaces policers operational mode command for logical interface fe-0/1/1.1. The command output section for the Proto column and Input Policer column shows that the policer p-all-1m-5k-discard is evaluated when packets are received on the logical interface.
user@host> show interfaces policers fe-0/1/1.1 Interface Admin Link Proto Input Policer Output Policer fe-0/1/1.1 up up inet p-all-1m-5k-discard-fe-0/1/1.1-inet-i
Action
In this example, the interface policer is applied to logical interface traffic in the input direction only. Displaying Statistics for the Policer Applied Directly to the Logical Interface Purpose Action Verify the number of packets evaluated by the interface policer. Use the show policer operational mode command and optionally specify the name of the policer. The command output displays the number of packets evaluated by each configured policer (or the specified policer), in each direction.
user@host> show policer p-all-1m-5k-discard-fe-0/1/1.1-inet-i Policers: Name Packets p-all-1m-5k-discard-fe-0/1/1.1-inet-i 5
Displaying the Policers and Firewall Filters Applied to an Interface Purpose Verify that the firewall filter filter-ipv4-with-limits is applied to the IPv4 input traffic at logical interface fe-0/1/1.1. Use the show interfaces statistics operational mode command for logical interface fe-0/1/1.1, and include the detail option. Under the Protocol inet section of the command output section, the Input Filters and Policer lines display the names of filter and policer applied to the logical interface in the input direction.
user@host> show interfaces statistics fe-0/1/1.1 detail Logical interface fe-0/1/1.1 (Index 83) (SNMP ifIndex 545) (Generation 153) Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.100 ] Encapsulation: ENET2 Traffic statistics: Input bytes : 0 Output bytes : 46 Input packets: 0 Output packets: 1 Local statistics: Input bytes : 0 Output bytes : 46 Input packets: 0 Output packets: 1 Transit statistics:
Action
342
Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol inet, MTU: 1500, Generation: 176, Route table: 0 Flags: Sendbcast-pkt-to-re Input Filters: filter-ipv4-with-limits-fe-0/1/1.1-i Policer: Input: p-all-1m-5k-discard-fe-0/1/1.1-inet-i Addresses, Flags: Is-Preferred Is-Primary Destination: 10.20.130/24, Local: 10.20.130.1, Broadcast: 10.20.130.255, Generation: 169
In this example, the two firewall filter policers are applied to logical interface traffic in the input direction only. Displaying Statistics for the Firewall Filter Policers Purpose Action Verify the number of packets evaluated by the firewall filter policers. Use the show firewall operational mode command for the filter you applied to the logical interface.
[edit] user@host> show firewall filter filter-ipv4-with-limits-fe-0/1/1.1-i Filter: filter-ipv4-with-limits-fe-0/1/1.1-i Policers: Name p-ftp-10p-500k-discard-t-ftp-fe-0/1/1.1-i p-icmp-500k-500k-discard-t-icmp-fe-0/1/1.1-i
Packets 0 0
The command output displays the names of the policers (p-ftp-10p-500k-discard and p-icmp-500k-500k-discard), combined with the names of the filter terms (t-ftp and t-icmp, respectively) under which the policer action is specified. The policer-specific output lines display the number of packets that matched the filter term. This is only the number of out-of-specification (out-of-spec) packet counts, not all packets policed by the policer.
Order of Policer and Firewall Filter Operations on page 304 Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Guidelines for Applying Traffic Policers on page 316 Calculation of Policer Burst-Size Limit on page 323
Bandwidth Policers

Bandwidth Policer Overview on page 344 Example: Configuring a Logical Bandwidth Policer on page 345
343
Bandwidth Policer Overview

For a single-rate two-color policer only, you can specify the bandwidth limit as a percentage value from 1 through 100 instead of as an absolute number of bits per second. This type of two-color policer, called a bandwidth policer, rate-limits traffic to a bandwidth limit that is calculated as a percentage of either the physical interface media rate or the logical interface configured shaping rate.
Guidelines for Configuring a Bandwidth Policer

The following guidelines apply to configuring a bandwidth policer:
To specify a percentage bandwidth limit, you include the bandwidth-percent percentage statement in place of the bandwidth-limit bps statement. By default, a bandwidth policer calculates the percentage bandwidth limit based on the physical interface port speed. To configure a bandwidth policer to calculate the percentage bandwidth limit based on the configured logical interface shaping rate instead, include the logical-bandwidth-policer statement at the [edit firewall policer policer-name] hierarchy level. This type of bandwidth policer is called a logical bandwidth policer. You can configure a logical interface shaping rate by including the shaping-rate bps statement at the [edit class-of-service interfaces interface interface-name unit logical-unit-number] hierarchy level. A logical interface shaping rate causes the specified amount of bandwidth to be allocated to the logical interface.
NOTE: If you configure a logical-bandwidth policer and then apply the policer to a logical interface that is not configured with a shaping rate, then the policer rate-limits traffic on that logical interface to calculate the percentage bandwidth limit based on the physical interface port speed, even if you include the logical-bandwidth-policer statement in the bandwidth policer configuration.
If you reference a bandwidth policer from a stateless firewall filter term, you must include the interface-specific statement in the firewall filter configuration.
Guidelines for Applying a Bandwidth Policer

The following guidelines pertain to applying a bandwidth policer to traffic:
You can use a bandwidth policer to rate-limit protocol-specific traffic (not family any) at the input or output of a logical interface. You can apply a bandwidth policer directly to protocol-specific input or output traffic at a logical interface.
344
To send only selected packets to a bandwidth policer, you can reference the bandwidth policer from a stateless firewall filter term and then apply the filter to logical interface traffic for a specific protocol family.
To reference a logical bandwidth policer from a firewall filter, you must include the interface-specific statement in the firewall filter configuration. You cannot use a bandwidth policer for forwarding-table filters.
You cannot apply a bandwidth policer to an aggregate interface, a tunnel interface, or a software interface.
Example: Configuring a Logical Bandwidth Policer

This example shows how to configure a logical bandwidth policer.

Requirements
Before you begin, make sure that you have two logical units available on a Gigabit Ethernet interface.
Overview
In this example, you configure a single-rate two-color policer that specifies the bandwidth limit as a percentage value rather than as an absolute number of bits per second. This type of policer is called a bandwidth policer. By default, a bandwidth policer enforces a bandwidth limit based on the line rate of the underlying physical interface. As an option, you can configure a bandwidth policer to enforce a bandwidth limit based on the configured shaping rate of the logical interface. To configure this type of bandwidth policer, called a logical bandwidth policer, you include the logical-bandwidth-policer statement in the policer configuration. To configure a logical interface shaping rate, include the shaping-rate bps statement at the [edit class-of-service interfaces interface interface-name unit logical-unit-number] hierarchy level. This class-of-service (CoS) configuration statement causes the specified amount of bandwidth to be allocated to the logical interface.
NOTE: If you configure a policer bandwidth limit as a percentage but a shaping rate is not configured for the target logical interface, the policer bandwidth limit is calculated as a percentage of the physical interface media rate, even if you enable the logical-bandwidth policing feature.
To apply a logical bandwidth policer to a logical interface, you can apply the policer directly to the logical interface at the protocol family level or (if you only need to rate-limit
345
filtered packets) you can reference the policer from a stateless firewall filter configured to operate in interface-specific mode. Topology In this example, you configure two logical interfaces on a single Gigabit Ethernet interface and configure a shaping rate on each logical interface. On logical interface ge-1/3/0.0, you allocate 4 Mbps of bandwidth. On logical interface ge-1/3/0.1, you allocate 2 Mbps of bandwidth. You also configure a logical bandwidth policer with a bandwidth limit of 50 percent and a maximum burst size of 125,000 bytes, and then you apply the policer to input and output traffic at the logical units configured on ge-1/3/0.0. For logical interface ge-1/3/0.0, the policer rate-limits to a bandwidth limit of 2 Mbps (50 percent of the 4 Mbps shaping rate configured for the logical interface). For logical interface ge-1/3/0.1, the policer rate-limits traffic to a bandwidth limit of 1 Mbps (50 percent of the 2 Mbps shaping rate configured for the logical interface). If no shaping rate is configured for a target logical interface, the policer rate-limits to a bandwidth limit calculated as 50 percent of the physical interface media rate. For example, if you apply a 50 percent bandwidth policer to input or output traffic at a Gigabit Ethernet logical interface without rate shaping, the policer applies a bandwidth limit of 500 Mbps (50 percent of 1000 Mbps).
Configuration

Configuring the Logical Interfaces on page 347 Configuring Traffic Rate-Shaping by Specifying the Amount of Bandwidth to be Allocated to the Logical Interface on page 348 Configuring the Logical Bandwidth Policer on page 348 Applying the Logical Bandwidth Policers to the Logical Interfaces on page 349
set interfaces ge-1/3/0 per-unit-scheduler set interfaces ge-1/3/0 vlan-tagging set interfaces ge-1/3/0 unit 0 vlan-id 100 set interfaces ge-1/3/0 unit 0 family inet address 172.1.1.1/30 set interfaces ge-1/3/0 unit 1 vlan-id 200 set interfaces ge-1/3/0 unit 1 family inet address 172.2.1.1/30 set class-of-service interfaces ge-1/3/0 unit 0 shaping-rate 4m set class-of-service interfaces ge-1/3/0 unit 1 shaping-rate 2m set firewall policer LB-policer logical-bandwidth-policer set firewall policer LB-policer if-exceeding bandwidth-percent 50 set firewall policer LB-policer if-exceeding burst-size-limit 125k
346
set firewall policer LB-policer then discard set interfaces ge-1/3/0 unit 0 family inet policer input LB-policer set interfaces ge-1/3/0 unit 0 family inet policer output LB-policer set interfaces ge-1/3/0 unit 1 family inet policer input LB-policer set interfaces ge-1/3/0 unit 1 family inet policer output LB-policer
Configuring the Logical Interfaces Step-by-Step Procedure To configure the logical interfaces:
1.
Enable configuration of the physical interface.

[edit] user@host# edit interfaces ge-1/3/0 [edit interfaces ge-1/3/0] user@host# set per-unit-scheduler user@host# set vlan-tagging
2.
Configure the first logical interface.

[edit interfaces ge-1/3/0] user@host# set unit 0 vlan-id 100 user@host# set unit 0 family inet address 172.1.1.1/30
3.
Configure the second logical interface.

Results
Confirm the configuration of the interfaces by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces ge-1/3/0 { per-unit-scheduler; vlan-tagging; unit 0 { vlan-id 100; family inet { address 172.1.1.1/30; } } unit 1 { vlan-id 200; family inet { address 172.2.1.1/30; } } }
347
Configuring Traffic Rate-Shaping by Specifying the Amount of Bandwidth to be Allocated to the Logical Interface Step-by-Step Procedure To configure rate shaping by specifying the bandwidth to be allocated to the logical interface:
1.
Enable CoS configuration on the physical interface.

[edit] user@host# edit class-of-service interfaces ge-1/3/0
2.
Configure rate shaping for the logical interfaces.

[edit] user@host# set unit 0 shaping-rate 4m user@host# set unit 1 shaping-rate 2m
These statements allocate 4 Mbps of bandwidth to logical unit ge-1/3/0.0 and 2 Mbps of bandwidth to logical unit ge-1/3/0.1. Results Confirm the configuration of the rate shaping by entering the show class-of-service configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show class-of-service interfaces { ge-1/3/0 { unit 0 { shaping-rate 4m; } unit 1 { shaping-rate 2m; } } }
Configuring the Logical Bandwidth Policer Step-by-Step Procedure To configure the logical bandwidth policer:
1.

[edit] user@host# edit firewall policer LB-policer
2.
Configure the policer as a logical-bandwidth policer.

[edit firewall policer LB-policer] user@host# set logical-bandwidth-policer
This applies the rate-limiting to logical interfaces.

3.
Configure the policer traffic limits and actions.

[edit firewall policer LB-policer] user@host# set if-exceeding bandwidth-percent 50 user@host# set if-exceeding burst-size-limit 125k
348
user@host# set then discard
Results
Confirm the configuration of the policer by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall policer LB-policer { logical-bandwidth-policer; if-exceeding { bandwidth-percent 50; burst-size-limit 125k; } then discard; }
Applying the Logical Bandwidth Policers to the Logical Interfaces Step-by-Step Procedure To configure the logical bandwidth policers to the logical interfaces:
1.
Enable configuration of the interface.

[edit] user@host# edit interfaces ge-1/3/0
2.
Apply the logical bandwidth policer to the first logical interface.

[edit interfaces ge-1/3/0] user@host# set unit 0 family inet policer input LB-policer user@host# set unit 0 family inet policer output LB-policer
3.
Apply the policing to the second logical interface.

[edit interfaces ge-1/3/0] user@host# set unit 1 family inet policer input LB-policer user@host# set unit 1 family inet policer output LB-policer
Results
[edit] user@host# show interfaces ge-1/3/0 { per-unit-scheduler; vlan-tagging; unit 0 { vlan-id 100; family inet { policer { input LB-policer; output LB-policer; } address 172.1.1.1/30; }
349
} unit 1 { vlan-id 200; family inet { policer { input LB-policer; output LB-policer; } address 172.2.1.1/30; } } }
Verification

Displaying Traffic Statistics and Policers for the Logical Interface on page 350 Displaying Statistics for the Policer on page 351
Displaying Traffic Statistics and Policers for the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface. Use the show interfaces operational mode command for logical interfaces ge-1/3/0.0 and ge-1/3/0.1, and include the detail or extensive option. The command output section for Traffic statistics lists the number of bytes and packets received and transmitted on the logical interface, and the Protocol inet section contains a Policer field that lists the policer LB-policer as an input or output policer as follows:

Action
Input: LB-policer-ge-1/3/0.0-inet-i Output: LB-policer-ge-1/3/0.0-inet-o
In this example, the policer is applied to logical interface traffic in both the input and output directions.
user@host> show interfaces ge-1/3/0.0 detail Logical interface ge-1/3/0.0 (Index 80) (SNMP ifIndex 154) (Generation 150) Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.100 ] Encapsulation: ENET2 Traffic statistics: Input bytes : 0 Output bytes : 46 Input packets: 0 Output packets: 1 Local statistics: Input bytes : 0 Output bytes : 46 Input packets: 0 Output packets: 1 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps
350
Input packets: 0 0 pps Output packets: 0 0 pps Protocol inet, MTU: 1500, Generation: 174, Route table: 0 Flags: Sendbcast-pkt-to-re Policer: Input: LB-policer-ge-1/3/0.0-inet-i, Output: LB-policer-ge-1/3/0.0-inet-o Addresses, Flags: Is-Preferred Is-Primary Destination: 172.1.1.0/30, Local: 172.1.1.1, Broadcast: 172.1.1.3, Generation: 165
user@host> show interfaces ge-1/3/0.1 detail Logical interface ge-1/3/0.1 (Index 81) (SNMP ifIndex 543) (Generation 151) Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.200 ] Encapsulation: ENET2 Traffic statistics: Input bytes : 0 Output bytes : 46 Input packets: 0 Output packets: 1 Local statistics: Input bytes : 0 Output bytes : 46 Input packets: 0 Output packets: 1 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol inet, MTU: 1500, Generation: 175, Route table: 0 Flags: Sendbcast-pkt-to-re Policer: Input: LB-policer-ge-1/3/0.1-inet-i, Output: LB-policer-ge-1/3/0.1-inet-o Addresses, Flags: Is-Preferred Is-Primary Destination: 172.2.1.0/30, Local: 172.2.1.1, Broadcast: 172.2.1.3, Generation: 167
Displaying Statistics for the Policer Purpose Action Verify the number of packets evaluated by the policer. Use the show policer operational mode command and optionally specify the name of the policer. The command output displays the number of packets evaluated by each configured policer (or the specified policer), in each direction. For the policer LB-policer, the input and output policer names are displayed as follows:

LB-policer-ge-1/3/0.0-inet-i LB-policer-ge-1/3/0.0-inet-o LB-policer-ge-1/3/0.1-inet-i LB-policer-ge-1/3/0.1-inet-o
The -inet-i suffix denotes a policer applied to logical interface input traffic, while the -inet-o suffix denotes a policer applied to logical interface output traffic. In this example, the policer is applied to both input and output traffic on logical interface ge-1/3/0.0 and logical interface ge-1/3/0.1.
351
user@host> show policer Policers: Name __default_arp_policer__ LB-policer-ge-1/3/0.0-inet-i LB-policer-ge-1/3/0.0-inet-o LB-policer-ge-1/3/0.1-inet-i LB-policer-ge-1/3/0.1-inet-o
Packets 0 0 0 0 0
Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Guidelines for Applying Traffic Policers on page 316 bandwidth-percent on page 461 interface-specific on page 290 in the Junos OS Firewall Filter and Policer Configuration
Guide
logical-bandwidth-policer on page 482 shaping-rate (Applying to an Interface) in the Junos OS Class of Service Configuration
Guide
Filter-Specific Counters and Policers

Filter-Specific Policer Overview on page 352 Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods on page 353
Filter-Specific Policer Overview

By default, a policer operates in term-specific mode so that, for a given firewall filter, the Junos OS creates a separate policer instance for every filter term that references the policer. As an option, you can configure a policer to operate in filter-specific mode so that a single policer instance is used by all terms (within the same firewall filter) that reference the policer. For an IPv4 firewall filter with multiple terms that reference the same policer, configuring the policer to operate in filter-specific mode enables you to count and monitor the activity of the policer at the firewall filter level.
NOTE: Term-specific mode and filter-specific mode also apply to prefix-specific policer sets.
To enable a single-rate two-color policer to operate in filter-specific mode, you can include the filter-specific statement at the following hierarchy levels:

[edit firewall policer policer-name] [edit logical-systems logical-system-name firewall policer policer-name]
352
You can reference filter-specific policers from IPv4 (family inet) firewall filters only.
Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods
This example shows how to create a stateless firewall filter that protects against TCP and ICMP denial-of-service attacks.

Requirements
Overview
In this example, you create a stateless firewall filter called protect-RE that polices TCP and ICMP packets. This example includes the following policers:
tcp-connection-policerLimits the traffic rate of the TCP packets to 500,000 bps and
the burst size to 15,000 bytes. Packets that exceed the traffic rate are discarded.
icmp-policerLimits the traffic rate of the ICMP packets to 1,000,000 bps and the
burst size to 15,000 bytes. Packets that exceed the traffic rate are discarded. When specifying limits, the bandwidth limit can be from 32,000 bps to 32,000,000,000 bps and the burst-size limit can be from 1,500 bytes through 100,000,000 bytes. Use the following abbreviations when specifying limits: k (1,000), m (1,000,000), and g (1,000,000,000). Each policer is incorporated into the action of a filter term. This example includes the following terms:
tcp-connection-termPolices certain TCP packets with a source address of
192.168.122.0/24 or 10.2.1.0/24. These addresses are defined in the trusted-addresses prefix list. Policed packets include connection request packets (SYN and ACK flag bits equal 1 and 0), connection release packets (FIN flag bit equals 1), and connection reset packets (RST flag bit equals 1).
icmp-termPolices echo request packets, echo response packets, unreachable packets,
and time-exceeded packets. All of these ICMP packets are counted in the icmp-counter counter.
353
If you want to include the terms created in this procedure in the protect-RE firewall filter configured in Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118, perform the configuration tasks in this example first. Then configure the terms as described in Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources on page 118. This approach ensures that the rate-limiting terms are included as the first two terms in the firewall filter.
Configuration
CLI Quick Configuration To quickly configure the stateless firewall filter, copy the following commands to a text file, remove any line breaks, and then paste the commands into the CLI.
[edit] set firewall family inet filter protect-RE term tcp-connection-term from source-prefix-list trusted-addresses set firewall family inet filter protect-RE term tcp-connection-term from protocol tcp set firewall family inet filter protect-RE term tcp-connection-term from tcp-flags "(syn & !ack) | fin | rst" set firewall family inet filter protect-RE term tcp-connection-term then policer tcp-connection-policer set firewall family inet filter protect-RE term tcp-connection-term then accept set firewall family inet filter protect-RE term icmp-term from protocol icmp set firewall family inet filter protect-RE term icmp-term from icmp-type echo-request set firewall family inet filter protect-RE term icmp-term from icmp-type echo-reply set firewall family inet filter protect-RE term icmp-term from icmp-type unreachable set firewall family inet filter protect-RE term icmp-term from icmp-type time-exceeded set firewall family inet filter protect-RE term icmp-term then policer icmp-policer set firewall family inet filter protect-RE term icmp-term then count icmp-counter set firewall family inet filter protect-RE term icmp-term then accept set firewall policer tcp-connection-policer filter-specific set firewall policer tcp-connection-policer if-exceeding bandwidth-limit 1m set firewall policer tcp-connection-policer if-exceeding burst-size-limit 15k set firewall policer tcp-connection-policer then discard set firewall policer icmp-policer filter-specific set firewall policer icmp-policer if-exceeding bandwidth-limit 1m set firewall policer icmp-policer if-exceeding burst-size-limit 15k set firewall policer icmp-policer then discard set policy-options prefix-list trusted-addresses 10.2.1.0/24 set policy-options prefix-list trusted-addresses 192.168.122.0/24
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode on page 15. To configure stateless firewall filter policers:
1.
Define the first policer.

[edit]
354
user@host# edit firewall policer tcp-connection-policer

2.

[edit firewall policer tcp-connection-policer] user@host# set then discard
3.
Define the rate limits for the policer.

[edit firewall policer tcp-connection-policer] user@host# set filter-specific user@host# set if-exceeding burst-size-limit 15k bandwidth-limit 1m
4.
Define the second policer.

[edit] user@host# edit firewall policer icmp-policer
5.

[edit firewall policer icmp-policer] user@host# set then discard
6.
Set the rate limits for the policer.

[edit firewall policer icmp-policer] user@host# set filter-specific user@host# set if-exceeding burst-size-limit 15k bandwidth-limit 1m
7.
Define the prefix list.

[edit] user@host# set policy-options prefix-list trusted-addresses 192.168.122.0/24 user@host# set policy-options prefix-list trusted-addresses 10.2.1.0/24
8.

9.

[edit firewall family inet filter protect-RE] user@host# edit term tcp-connection-term
10.
Define the source address match condition for the term.

[edit firewall family inet filter protect-RE term tcp-connection-term] user@host# set from source-prefix-list trusted-addresses
11.
Define protocol match conditions for the term.

[edit firewall family inet filter protect-RE term tcp-connection-term] user@host# set from protocol tcp tcp-flags "(syn & !ack) | fin | rst"
12.

[edit firewall family inet filter protect-RE term tcp-connection-term] user@host# set then policer tcp-connection-policer accept
355
13.
Define the second term.

[edit] user@host# edit firewall family inet filter protect-RE term icmp-term
14.
Define the protocol for the term.

[edit firewall family inet filter protect-RE term icmp-term] user@host# set from protocol icmp
15.

[edit firewall family inet filter protect-RE term icmp-term] user@host# set from icmp-type [echo-request echo-reply unreachable time-exceeded]
16.

[edit firewall family inet filter protect-RE term icmp-term] user@host# set then policer icmp-policer count icmp-counter accept
Results
Confirm your configuration by entering the show firewall command and the show policy-options command from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
user@host# show firewall family inet { filter protect-RE { term tcp-connection-term { from { source-prefix-list { trusted-addresses; } protocol tcp; tcp-flags "(syn & !ack) | fin | rst"; } then { policer tcp-connection-policer; accept; } } term icmp-term { from { protocol icmp; icmp-type [ echo-request echo-reply unreachable time-exceeded ]; } then { policer icmp-policer; count icmp-counter; accept; } } } } policer tcp-connection-policer { filter-specific; if-exceeding {
356
bandwidth-limit 1m; burst-size-limit 15k; } then discard; } policer icmp-policer { filter-specific; if-exceeding { bandwidth-limit 1m; burst-size-limit 15k; } then discard; } user@host# show policy-options prefix-list trusted-addresses { 10.2.1.0/24; 192.168.122.0/24; }
Verification

Displaying Stateless Firewall Filter Configurations on page 357 Verifying a TCP and ICMP Flood Firewall Filter on page 357 Displaying Firewall Filter Statistics on page 358
Displaying Stateless Firewall Filter Configurations Purpose Action Meaning Verify the configuration of the firewall filter. From configuration mode, enter the show firewall command. Verify that the output shows the intended configuration of the firewall filter. In addition, verify that the terms are listed in the order in which you want the packets to be tested. You can move terms within a firewall filter by using the insert CLI command. Verifying a TCP and ICMP Flood Firewall Filter Purpose Action Verify that the actions of the firewall filter terms are taken. Send packets to the device that match the terms. In addition, verify that the filter actions are not taken for packets that do not match.
Verify that the device can establish only TCP sessions with a host at an IP address that matches 192.168.122.0/24 or 10.2.1.0/24. For example, log in to the device with the telnet host-name command from another host with one of these address prefixes. Use the ping host-name command to verify that the device responds only to ICMP packets (such as ping requests) that do not exceed the policer traffic rates.
357
Use the ping host-name size bytes command to exceed the policer traffic rates by sending ping requests with large data payloads.
Sample Output
user@host> telnet 192.168.249.71 Trying 192.168.249.71... Connected to host.acme.net. Escape character is '^]'. host (ttyp0) login: user Password: --- JUNOS 6.4-20040521.1 built 2004-05-21 09:38:12 UTC user@host> user@host> ping 192.168.249.71 PING host-ge-000.acme.net (192.168.249.71): 56 data bytes 64 bytes from 192.168.249.71: icmp_seq=0 ttl=253 time=11.946 ms 64 bytes from 192.168.249.71: icmp_seq=1 ttl=253 time=19.474 ms 64 bytes from 192.168.249.71: icmp_seq=2 ttl=253 time=14.639 ms ... user@host> ping 192.168.249.71 size 20000 PING host-ge-000.acme.net (192.168.249.71): 20000 data bytes ^C --- host-ge-000.acme.net ping statistics --12 packets transmitted, 0 packets received, 100% packet loss
Meaning

You can successfully log in to the device using Telnet. The device sends responses to the ping host command. The device does not send responses to the ping host size 20000 command.
Displaying Firewall Filter Statistics Purpose Action Verify that packets are being policed and counted. From operational mode, enter the show firewall filter filter-name command.
Sample Output
user@host> show firewall filter protect-RE Filter: protect-RE Counters: Name icmp-counter Policers: Name
Bytes 1040000 Packets
Packets 5600
358
tcp-connection-policer icmp-policer
643254873 7391
Meaning

Next to Filter, the name of the firewall filter is correct. Under Counters:

Under Name, the names of any counters configured in the firewall filter are correct. Under Bytes, the number of bytes that match the filter term containing the count counter-name action are shown. Under Packets, the number of packets that match the filter term containing the count counter-name action are shown.
Under Policers:

Under Name, the names of any policers configured in the firewall filter are correct. Under Packets, the number of packets that match the conditions specified for the policer are shown.
Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Guidelines for Applying Traffic Policers on page 316 Prefix-Specific Counting and Policing Actions on page 359
Prefix-Specific Counting and Policing Actions

Prefix-Specific Counting and Policing Overview on page 359 Filter-Specific Counter and Policer Set Overview on page 362 Example: Configuring Prefix-Specific Counting and Policing on page 362 Prefix-Specific Counting and Policing Configuration Scenarios on page 369
Prefix-Specific Counting and Policing Overview


Separate Counting and Policing for Each IPv4 Address Range on page 359 Prefix-Specific Action Configuration on page 360 Counter and Policer Set Size and Indexing on page 361
Separate Counting and Policing for Each IPv4 Address Range

Prefix-specific counting and policing enables you to configure an IPv4 firewall filter term that matches on a source or destination address, applies a single-rate two-color policer as the term action, but associates the matched packet with a specific counter and policer instance based on the source or destination in the packet header. You can implicitly
359
create a separate counter or policer instance for a single address or for a group of addresses.
NOTE: J Series Services Routers do not support prefix-specific counting and policing.
Prefix-specific counting and policing uses a prefix-specific action configuration that specifies the name of the policer you want to apply, whether prefix-specific counting is to be enabled, and a source or destination address prefix range. The prefix range specifies between 1 and 16 sequential set bits of an IPv4 address mask. The length of the prefix range determines the size of the counter and policer set, which consists of as few as 2 or as many as 65,536 counter and policer instances. The position of the bits of the prefix range determines the indexing of filter-matched packets into the set of instances.
NOTE: A prefix-specific action is specific to a source or destination prefix range, but it is not specific to a particular source or destination address range, and it is not specific to a particular interface.
To apply a prefix-specific action to the traffic at an interface, you configure a firewall filter term that matches on source or destination addresses, and then you apply the firewall filter to the interface. The flow of filtered traffic is rate-limited using prefix-specific counter and policer instances that are selected per packet based on the source or destination address in the header of the filtered packet.
Prefix-Specific Action Configuration

To configure a prefix-specific action, you specify the following information:
Prefix-specific action nameName that can be referenced as the action of an IPv4 standard firewall filter term that matches packets on source or destination addresses. Policer nameName of a single-rate two-color policer for which you want to implicitly create prefix-specific instances.
NOTE: For aggregated Ethernet interfaces, you can configure a prefix-specific action that references a logical interface policer (also called an aggregate policer). You can reference this type of prefix-specific action from an IPv4 standard firewall filter and then apply the filter at the aggregate level of the interface.
Counting optionOption to include if you want to enable prefix-specific counters. Filter-specific optionOption to include if you want a single counter and policer set to be shared across all terms in the firewall filter. A prefix-specific action that operates in this way is said to operate in filter-specific mode. If you do not enable this option,
360
the prefix-specific action operates in term-specific mode, meaning that a separate counter and policer set is created for each filter term that references the prefix-specific action.
Source address prefix lengthLength of the address prefix, from 0 through 32, to be used with a packet matched on the source address. Destination address prefix lengthLength of the address prefix, from 0 through 32, to be used with a packet matched on the destination address. Subnet prefix lengthLength of the subnet prefix, from 0 through 32, to be used with a packet matched on either the source or destination address.
You must configure source and destination address prefix lengths to be from 1 to 16 bits longer than the subnet prefix length. If you configure source or destination address prefix lengths to be more than 16 bits beyond the configured subnet prefix length, an error occurs when you try to commit the configuration.
Counter and Policer Set Size and Indexing

The number of prefix-specific actions (counters or policers) implicitly created for a prefix-specific action is determined by the length of the address prefix and the length of the subnet prefix: SizeofCounterandPolicerSet=2^(source-or-destination-prefix-length - subnet-prefix-length) Table 36 on page 361 shows examples of counter and policer set size and indexing.
Table 36: Examples of Counter and Policer Set Size and Indexing
Example Prefix Lengths Specified in the Prefix-Specific Action
source-prefix-length = 32 subnet-prefix-length = 16
Calculation of Counter or Policer Set Size

Size=2^(32-16)=2^16=65,536instances NOTE: This calculation shows the largest counter or policer set size supported.
Indexing of Instances
Instance 0: Instance 1: Instance 65535: x.x.0.0 x.x.0.1 x.x.255.255
Size = 2^(32 - 24) = 2^8 = 256 instances
Instance 0: Instance 1: Instance 255:
x.x.x.0 x.x.x.1 x.x.x.255 x.x.x.0 x.x.x.1 x.x.x.127
Size = 2^(32 - 25) = 2^7 = 128 instances
Instance 0: Instance 1: Instance 127:
361
Table 36: Examples of Counter and Policer Set Size and Indexing (continued)
Example Prefix Lengths Specified in the Prefix-Specific Action
Calculation of Counter or Policer Set Size

Size = 2^(24 - 20) = 2^4 = 16 instances
Indexing of Instances
Instance 0: Instance 1: Instance 15: x.x.0.x x.x.1.x x.x.15.x
Filter-Specific Counter and Policer Set Overview

By default, a prefix-specific policer set operates in term-specific mode so that, for a given firewall filter, the Junos OS creates a separate counter and policer set for every filter term that references the prefix-specific action. As an option, you can configure a prefix-specific policer set to operate in filter-specific mode so that a single prefix-specific policer set is used by all terms (within the same firewall filter) that reference the policer. For an IPv4 firewall filter with multiple terms that reference the same prefix-specific policer set, configuring the policer set to operate in filter-specific mode enables you to count and monitor the activity of the policer set at the firewall filter level.
NOTE: Term-specific mode and filter-specific mode also apply to policers. See Filter-Specific Policer Overview on page 352.
To enable a prefix-specific policer set to operate in filter-specific mode, you can include the filter-specific statement at following the hierarchy levels:

[edit firewall family inet prefix-action prefix-action-name] [edit logical-systems logical-system-name firewall family inet prefix-action prefix-action-name]
You can reference filter-specific, prefix-specific policer sets from IPv4 (family inet) firewall filters only.
Example: Configuring Prefix-Specific Counting and Policing

This example shows how to configure prefix-specific counting and policing.

362
Requirements
Overview
In this example, you configure prefix-specific counting and policing based on the last octet of the source address field in packets matched by an IPv4 firewall filter. The single-rate two-color policer named 1Mbps-policer rate-limits traffic to a bandwidth of 1,000,000 bps and a burst-size limit of 63,000 bytes, discarding any packets in a traffic flow that exceeds the traffic limits. Independent of the IPv4 addresses contained in any packets passed from a firewall filter, the prefix-specific action named psa-1Mbps-per-source-24-32-256 specifies a set of 256 counters and policers, numbered from 0 through 255. For each packet, the last octet of the source address field is used to index into the associated prefix-specific counter and policer in the set:
Packets with a source address ending with the octet 0x0000 00000 index the first counter and policer in the set. Packets with a source address ending with the octet 0x0000 0001 index the second counter and policer in the set. Packets with a source address ending with the octet 0x1111 1111 index the last counter and policer in the set.
The limit-source-one-24 firewall filter contains a single term that matches all packets from the /24 subnet of source address 10.10.10.0, passing these packets to the prefix-specific action psa-1Mbps-per-source-24-32-256. Topology In this example, because the filter term matches the /24 subnet of a single source address, each counting and policing instance in the prefix-specific set is used for only one source address.

Packets with a source address 10.10.10.0 index the first counter and policer in the set. Packets with a source address 10.10.10.1 index the second counter and policer in the set. Packets with a source address 10.10.10.255 index the last counter and policer in the set.
This example shows the simplest case of prefix-specific actions, in which the filter term matches on one address with a prefix length that is the same as the prefix length specified in the prefix-specific action for indexing into the set of prefix-specific counters and policers. For descriptions of other configurations for prefix-specific counting and policing, see Prefix-Specific Counting and Policing Configuration Scenarios on page 369.
363
Configuration

Configuring a Policer for Prefix-Specific Counting and Policing on page 364 Configuring a Prefix-Specific Action Based on the Policer on page 365 Configuring an IPv4 Filter That References the Prefix-Specific Action on page 366 Applying the Firewall Filter to IPv4 Input Traffic at a Logical Interface on page 367
set firewall policer 1Mbps-policer if-exceeding bandwidth-limit 1m set firewall policer 1Mbps-policer if-exceeding burst-size-limit 63k set firewall policer 1Mbps-policer then discard set firewall family inet prefix-action psa-1Mbps-per-source-24-32-256 policer 1Mbps-policer set firewall family inet prefix-action psa-1Mbps-per-source-24-32-256 count set firewall family inet prefix-action psa-1Mbps-per-source-24-32-256 subnet-prefix-length 24 set firewall family inet prefix-action psa-1Mbps-per-source-24-32-256 source-prefix-length 32 set firewall family inet filter limit-source-one-24 term one from source-address 10.10.10.0/24 set firewall family inet filter limit-source-one-24 term one then prefix-action psa-1Mbps-per-source-24-32-256 set interfaces so-0/0/2 unit 0 family inet filter input limit-source-one-24 set interfaces so-0/0/2 unit 0 family inet address 10.39.1.1/16
Configuring a Policer for Prefix-Specific Counting and Policing Step-by-Step Procedure To configure a policer to be used for prefix-specific counting and policing:
1.

[edit] user@host# edit firewall policer 1Mbps-policer
2.
Define the traffic limit.

[edit firewall policer 1Mbps-policer] user@host# set if-exceeding bandwidth-limit 1m user@host# set if-exceeding burst-size-limit 63k
Packets in a traffic flow that conforms to this limit are passed with the PLP set to low.
3.
Define the actions for nonconforming traffic.

[edit firewall policer 1Mbps-policer] user@host# set then discard
364
Packets in a traffic flow that exceeds this limit are discarded. Other configurable actions for a single-rate two-color policer are to set the forwarding class and to set the PLP level. Results Confirm the configuration of the policer by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall policer 1Mbps-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 63k; } then discard; }
Configuring a Prefix-Specific Action Based on the Policer Step-by-Step Procedure To configure a prefix-specific action that references the policer and specifies a portion of a source address prefix:
1.
Enable configuration of a prefix-specific action.

[edit] user@host# edit firewall family inet prefix-action psa-1Mbps-per-source-24-32-256
Prefix-specific counting and policing can be defined for IPv4 traffic only.
2.
Reference the policer for which a prefix-specific set is to be created.

[edit firewall family inet prefix-action psa-1Mbps-per-source-24-32-256] user@host# set policer 1Mbps-policer user@host# set count
NOTE: For aggregated Ethernet interfaces, you can configure a prefix-specific action that references a logical interface policer (also called an aggregate policer). You can reference this type of prefix-specific action from an IPv4 standard firewall filter and then apply the filter at the aggregate level of the interface.
3.
Specify the prefix range on which IPv4 addresses are to be indexed to the counter and policer set.
[edit firewall family inet prefix-action psa-1Mbps-per-source-24-32-256] user@host# set source-prefix-length 32 user@host# set subnet-prefix-length 24
365
Results
Confirm the configuration of the prefix-specific action by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall policer 1Mbps-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 63k; } then discard; } family inet { prefix-action psa-1Mbps-per-source-24-32-256 { policer 1Mbps-policer; subnet-prefix-length 24; source-prefix-length 32; } }
Configuring an IPv4 Filter That References the Prefix-Specific Action Step-by-Step Procedure To configure an IPv4 standard firewall filter that references the prefix-specific action:
1.
Enable configuration of the IPv4 standard firewall filter.

[edit] user@host# edit firewall family inet filter limit-source-one-24
Prefix-specific counting and policing can be defined for IPv4 traffic only.
2.
Configure the filter term to match on the packet source address or destination address.
[edit firewall family inet filter limit-source-one-24] user@host# set term one from source-address 10.10.10.0/24
3.
Configure the filter term to reference the prefix-specific action.

[edit firewall family inet filter limit-source-one-24] user@host# set term one then prefix-action psa-1Mbps-per-source-24-32-256
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 traffic limited to 1 Mbps. Results Confirm the configuration of the prefix-specific action by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall policer 1Mbps-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 63k;
366
} then discard; } family inet { prefix-action psa-1Mbps-per-source-24-32-256 { policer 1Mbps-policer; subnet-prefix-length 24; source-prefix-length 32; } filter limit-source-one-24 { term one { from { source-address { 10.10.10.0/24; } } then prefix-action psa-1Mbps-per-source-24-32-256; } } }
Applying the Firewall Filter to IPv4 Input Traffic at a Logical Interface Step-by-Step Procedure To apply the firewall filter to IPv4 input traffic at a logical interface:
1.

2.
Configure an IP address.
[edit interfaces so-0/0/2 unit 0 family inet] user@host# set address 10.39.1.1/16
3.
Apply the IPv4 standard stateless firewall filter.

[edit interfaces so-0/0/2 unit 0 family inet] user@host# set filter input limit-source-one-24
Results
Confirm the configuration of the prefix-specific action by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces so-0/0/2 { unit 0 { family inet { filter { input limit-source-one-24; } address 10.39.1.1/16; } } }
367
Verification

Displaying the Firewall Filters Applied to an Interface on page 368 Displaying Prefix-Specific Actions Statistics for the Firewall Filter on page 368
Displaying the Firewall Filters Applied to an Interface Purpose Verify that the firewall filter limit-source-one-24 is applied to the IPv4 input traffic at logical interface so-0/0/2.0. Use the show interfaces statistics operational mode command for logical interface so-0/0/2.0, and include the detail option. In the command output section for Protocol inet, the Input Filters field displays limit-source-one-24, indicating that the filter is applied to IPv4 traffic in the input direction:
user@host> show interfaces statistics so-0/0/2.0 detail Logical interface so-0/0/2.0 (Index 79) (SNMP ifIndex 510) (Generation 149) Flags: Hardware-Down Point-To-Point SNMP-Traps 0x4000 Encapsulation: PPP Protocol inet, MTU: 4470, Generation: 173, Route table: 0 Flags: Sendbcast-pkt-to-re, Protocol-Down Input Filters: limit-source-one-24 Addresses, Flags: Dest-route-down Is-Preferred Is-Primary Destination: 10.39/16, Local: 10.39.1.1, Broadcast: 10.39.255.255, Generation: 163
Action
Displaying Prefix-Specific Actions Statistics for the Firewall Filter Purpose Action Verify the number of packets evaluated by the policer. Use the show firewall prefix-action-stats filter filter-name prefix-action name operational mode command to display statistics about a prefix-specific action configured on a firewall filter. As an option, you can use the from set-index to set-index command option to specify the starting and ending counter or policer to be displayed. A policer set is indexed from 0 through 65535. The command output displays the specified filter name followed by a listing of the number of bytes and packets processed by each policer in the policer set. For a term-specific policer, each policer in the set is identified as follows:
prefix-specific-action-name-term-name-set-index
For a filter-specific policer, each policer is identified in the command output as follows:
prefix-specific-action-name-set-index
Because the example prefix-specific action psa-1Mbps-per-source-24-32-256 is referenced by only one term of the example filter limit-source-one-24, the example policer 1Mbps-policer is configured as term-specific. In the show firewall prefix-action-stats
368
command output, the policer statistics are displayed as psa-1Mbps-per-source-24-32-256-one-0, psa-1Mbps-per-source-24-32-256-one-1, and so on through psa-1Mbps-per-source-24-32-256-one-255.
user@host> show firewall prefix-action-stats filter limit-source-one-24 prefix-action psa-1Mbps-per-source-24-32-256 from 0 to 9 Filter: limit-source-one-24 Counters: Name Bytes Packets psa-1Mbps-per-source-24-32-256-one-0 0 0 psa-1Mbps-per-source-24-32-256-one-1 0 0 psa-1Mbps-per-source-24-32-256-one-2 0 0 psa-1Mbps-per-source-24-32-256-one-3 0 0 psa-1Mbps-per-source-24-32-256-one-4 0 0 psa-1Mbps-per-source-24-32-256-one-5 0 0 psa-1Mbps-per-source-24-32-256-one-6 0 0 psa-1Mbps-per-source-24-32-256-one-7 0 0 psa-1Mbps-per-source-24-32-256-one-8 0 0 psa-1Mbps-per-source-24-32-256-one-9 0 0
Prefix-Specific Counting and Policing Configuration Scenarios


Prefix Length of the Action and Prefix Length of Addresses in Filtered Packets on page 369 Scenario 1: Firewall Filter Term Matches on Multiple Addresses on page 370 Scenario 2: Subnet Prefix Is Longer Than the Prefix in the Filter Match Condition on page 372 Scenario 3: Subnet Prefix Is Shorter Than the Prefix in the Firewall Filter Match Condition on page 373
Prefix Length of the Action and Prefix Length of Addresses in Filtered Packets
Table 37 on page 369 describes the relationship between the prefix length specified in the prefix-specific action and the prefix length of the addresses matched by the firewall filter term that references the prefix-specific action.
Table 37: Summary of Prefix-Specific Action Scenarios

Counter and Policer Set Packet-Filtering Criteria Indexing of Instances
Prefix-specific action scenario: Example: Configuring Prefix-Specific Counting and Policing on page 362 source-prefix-length = 32 subnet-prefix-length = 24 Set size: 2^8 = 256 Instance numbers: 0 - 255 source-address = 10.10.10.0/24 Instance 0 Instance 1:
...
10.10.10.0 10.10.10.1
...
Instance 255:
10.10.10.255
369
Table 37: Summary of Prefix-Specific Action Scenarios (continued)

Counter and Policer Set Packet-Filtering Criteria Indexing of Instances
Prefix-specific action scenario: Scenario 1: Firewall Filter Term Matches on Multiple Addresses on page 370 source-prefix-length = 32 subnet-prefix-length = 24 Set size: 2^8 = 256 Instance numbers: 0 - 255 source-address = 10.10.10.0/24 source-address = 10.11.0.0/16 Instance 1: 10.10.10.1, 10.11.x.1
...
Instance 0
10.10.10.0, 10.11.x.0
...
Instance 255:
10.10.10.255, 10.11.x.255
For addresses in the /16 subnet, x ranges from 0 through 255. Prefix-specific action scenario: Scenario 2: Subnet Prefix Is Longer Than the Prefix in the Filter Match Condition on page 372 source-prefix-length = 32 subnet-prefix-length = 25 Set size: 2^7 = 128 Instance numbers: 0 - 127 source-address = 10.10.10.0/24 Instance 0 10.10.10.0, 10.10.10.128 10.10.10.1, 10.10.10.120
...
Instance 1:
...
Instance 127:
10.10.10.255, 10.10.10.127
Prefix-specific action scenario: Scenario 3: Subnet Prefix Is Shorter Than the Prefix in the Firewall Filter Match Condition on page 373 source-prefix-length = 32 subnet-prefix-length = 24 Set size: 2^8 = 256 Instance numbers: 0 - 255 source-address = 10.10.10.0/25 NOTE: Only packets with source addresses ranging from 10.10.10.0 through 10.10.10.127 are passed to the prefix-specific action. Instance 0 Instance 1:
...
10.10.10.0 10.10.10.1
...
Instance 127:
10.10.10.127
Instances 128 255: unused
Scenario 1: Firewall Filter Term Matches on Multiple Addresses

The complete example, Example: Configuring Prefix-Specific Counting and Policing on page 362, shows the simplest case of prefix-specific actions, in which a single-term firewall
370
filter matches on one address with a prefix length that is the same as the subnet prefix length specified in the prefix-specific action. Unlike the example, this scenario describes a configuration in which a single-term firewall filter matches on two IPv4 source addresses. In addition, the additional condition matches on a source address with a prefix length that is different from the subnet prefix length defined in the prefix-specific action. In this case, the additional condition matches on the /16 subnet of the source address 10.11.0.0.
NOTE: Unlike packets that match the source address 10.10.10.0/24, packets that match the source address 10.11.0.0/16 are in a many-to-one correspondence with the instances in the counter and policer set.
The filter-matched packets that are passed to the prefix-specific action index into the counter and policer set in such a way that the counting and policing instances are shared by packets that contain source addresses across the 10.10.10.0/24 and 10.11.0.0/16 subnets as follows:
The first counter and policer in the set are indexed by packets with source addresses 10.10.10.0 and 10.11.x.0, where x ranges from 0 through 255. The second counter and policer in the set are indexed by packets with source addresses 10.10.10.1 and 10.11.x.1, where x ranges from 0 through 255. The 256th (last) counter and policer in the set are indexed by packets with source addresses 10.10.10.255 and 10.11.x.255, where x ranges from 0 through 255.
The following configuration shows the statements for configuring the single-rate two-color policer, the prefix-specific action that references the policer, and the IPv4 standard stateless firewall filter that references the prefix-specific action:
[edit] firewall { policer 1Mbps-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 63k; } then discard; } family inet { prefix-action psa-1Mbps-per-source-24-32-256 { policer 1Mbps-policer; subnet-prefix-length 24; source-prefix-length 32; } filter limit-source-two-24-16 { term one { from { source-address { 10.10.10.0/24; 10.11.0.0/16; } }
371
then prefix-action psa-1Mbps-per-source-24-32-256; } } } } interfaces { so-0/0/2 { unit 0 { family inet { filter { input limit-source-two-24-16; } address 10.39.1.1/16; } } } }
Scenario 2: Subnet Prefix Is Longer Than the Prefix in the Filter Match Condition
The complete example, Example: Configuring Prefix-Specific Counting and Policing on page 362, shows the simplest case of prefix-specific actions, in which the single-term firewall filter matches on one address with a prefix length that is the same as the subnet prefix length specified in the prefix-specific action. Unlike the example, this scenario describes a configuration in which the prefix-specific action defines a subnet prefix length that is longer than the prefix of the source address matched by the firewall filter. In this case, the prefix-specific action defines a subnet-prefix value of 25, while the firewall filter matches on a source address in the /24 subnet.
NOTE: The firewall filter passes the prefix-specific action packets with source addresses that range from 10.10.10.0 through 10.10.10.255, while the prefix-specific action specifies a set of only 128 counters and policers, numbered from 0 through 127.
The filter-matched packets that are passed to the prefix-specific action index into the counter and policer set in such a way that the counting and policing instances are shared by packets that contain either of two source addresses within the 10.10.10.0/24 subnet:
The first counter and policer in the set are indexed by packets with source addresses 10.10.10.0 and 10.10.10.128. The second counter and policer in the set are indexed by packets with source addresses 10.10.10.1 and 10.10.10.129. The 128th (last) counter and policer in the set are indexed by packets with source addresses 10.10.10.127 and 10.10.10.255.
[edit]
372
firewall { policer 1Mbps-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 63k; } then discard; } family inet { prefix-action psa-1Mbps-per-source-25-32-128 { policer 1Mbps-policer; subnet-prefix-length 25; source-prefix-length 32; } filter limit-source-one-24 { term one { from { source-address { 10.10.10.0/24; } } then prefix-action psa-1Mbps-per-source-25-32-128; } } } } interfaces { so-0/0/2 { unit 0 { family inet { filter { input limit-source-one-24; } address 10.39.1.1/16; } } } }
Scenario 3: Subnet Prefix Is Shorter Than the Prefix in the Firewall Filter Match Condition
The complete example, Example: Configuring Prefix-Specific Counting and Policing on page 362, shows the simplest case of prefix-specific actions, in which the single-term firewall filter matches on one address with a prefix length that is the same as the subnet prefix length specified in the prefix-specific action. Unlike the example, this scenario describes a configuration in which the prefix-specific action defines a subnet prefix length that is shorter than the prefix of the source address matched by the firewall filter. In this case, the filter term matches on the /25 subnet of the source address 10.10.10.0.
373
NOTE: The firewall filter passes the prefix-specific action only packets with source addresses that range from 10.10.10.0 through 10.10.10.127, while the prefix-specific action specifies a set of 256 counters and policers, numbered from 0 through 255.
The matched packets that are passed to the prefix-specific action index into the lower half of the counter and policer set only:
The first counter and policer in the set are indexed by packets with source address 10.10.10.0. The second counter and policer in the set are indexed by packets with source address 10.10.10.1 and 10.10.10.129. The 128th counter and policer in the set are indexed by packets with source address 10.10.10.127. The upper half of the set (instances numbered from 128 through 255) are not indexed by packets passed to the prefix-specific action from this particular firewall filter.
[edit] firewall { policer 1Mbps-policer { if-exceeding { bandwidth-limit 1m; burst-size-limit 63k; } then discard; } family inet { prefix-action psa-1Mbps-per-source-24-32-256 { policer 1Mbps-policer; subnet-prefix-length 24; source-prefix-length 32; } filter limit-source-one-25 { term one { from { source-address { 10.10.10.0/25; } } then prefix-action psa-1Mbps-per-source-24-32-256; } } } } interfaces { so-0/0/2 {
374
unit 0 { family inet { filter { input limit-source-one-25; } address 10.39.1.1/16; } } } }
Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Guidelines for Applying Traffic Policers on page 316
Multifield Classification

Multifield Classification Overview on page 375 Multifield Classification Requirements and Restrictions on page 377 Multifield Classification Limitations on M Series Routers on page 378 Example: Configuring Multifield Classification on page 380 Example: Configuring and Applying a Firewall Filter for a Multifield Classifier on page 386
Multifield Classification Overview


Forwarding Classes and PLP Levels on page 375 Multifield Classification and BA Classification on page 376 Multifield Classification Used In Conjunction with Policers on page 376
Forwarding Classes and PLP Levels

You can configure the Junos OS class of service (CoS) features to classify incoming traffic by associating each packet with a forwarding class, a packet loss priority (PLP) level, or both:
Based on the associated forwarding class, each packet is assigned to an output queue, and the router services the output queues according to the associated scheduling you configure. Based on the associated PLP, each packet carries a lower or higher likelihood of being dropped if congestion occurs. The CoS random early detection (RED) process uses the drop probability configuration, output queue fullness percentage, and packet PLP to drop packet as needed to control congestion at the output stage.
375
Multifield Classification and BA Classification

The Junos OS supports two general types of packet classification: behavior aggregate (BA) classification and multifield classification:
BA classification, or CoS value traffic classification, refers to a method of packet classification that uses a CoS configuration to set the forwarding class or PLP of a packet based on the CoS value in the IP packet header. The CoS value examined for BA classification purposes can be the Differentiated Services code point (DSCP) value, DSCP IPv6 value, IP precedence value, MPLS EXP bits, and IEEE 802.1p value. The default classifier is based on the IP precedence value. Multifield classification refers to a method of packet classification that uses a standard stateless firewall filter configuration to set the forwarding class or PLP for each packet entering or exiting the interface based on multiple fields in the IP packet header, including the DSCP value (for IPv4 only), the IP precedence value, the MPLS EXP bits, and the IEEE 802.1p bits. Multifield classification commonly matches on IP address fields, the IP protocol type field, or the port number in the UDP or TCP pseudoheader field. Multifield classification is used instead of BA classification when you need to classify packets based on information in the packet information other than the CoS values only. With multifield classification, a firewall filter term can specify the packet classification actions for matching packets though the use of the forwarding-class class-name or loss-priority (high | medium-high | medium-low | low) nonterminating actions in the terms then clause. For more information about these actions, see .
NOTE: BA classification of a packet can be overridden by the stateless firewall filter actions forwarding-class and loss-priority.
Multifield Classification Used In Conjunction with Policers

To configure multifield classification in conjunction with rate limiting, a firewall filter term can specify the packet classification actions for matching packets through the use of a policer nonterminating action that references a single-rate two-color policer. When multifield classification is configured to perform classification through a policer, the filter-matched packets in the traffic flow are rate-limited to the policer-specified traffic limits. Packets in a conforming flow of filter-matched packets are implicitly set to a low PLP. Packets in a nonconforming traffic flow can be discarded, or the packets can be set to a specified forwarding class, set to a specified PLP level, or both, depending on the type of policer and how the policer is configured to handle nonconforming traffic.
376
NOTE: Before you apply a firewall filter that performs multifield classification and also a policer to the same logical interface and for the same traffic direction, make sure that you consider the order of policer and firewall filter operations. As an example, consider the following scenario:
You configure a firewall filter that performs multifield classification (acts on matched packets by setting the forwarding class, the PLP, or both) based on the packet's existing forwarding class or PLP. You apply the firewall filter at the input of a logical interface. You also configure a single-rate two-color policer that acts on a red traffic flow by re-marking (setting the forwarding class, the PLP, or both) rather than discarding those packets. You apply the policer as an interface policer at the input of the same logical interface to which you apply the firewall filter.
Because of the order of policer and firewall operations, the input policer is executed before the input firewall filter. This means that the multifield classification specified by the firewall filter is performed on input packets that have already been re-marked once by policing actions. Consequently, any input packet that matches the conditions specified in a firewall filter term is then subject to a second re-marking according to the forwarding-class or loss-priority nonterminating actions also specified in that term.
Multifield Classification Requirements and Restrictions


Supported Platforms on page 377 CoS Tricolor Marking Requirement on page 378 Restrictions on page 378
Supported Platforms
The loss-priority firewall filter action is supported on the following routing platforms only:

M7i and M10i routers with the Enhanced CFEB (CFEB-E) M120 and M320 routers MX Series routers T Series routers with Enhanced II Flexible PIC Concentrators (FPCs)
377
CoS Tricolor Marking Requirement

The loss-priority firewall filter action has platform-specific requirements dependencies on the CoS tricolor marking feature, as defined in RFC 2698:
On an M320 router, you cannot commit a configuration that includes the loss-priority firewall filter action unless you enable the CoS tricolor marking feature. On all routing platforms that support the loss-priority firewall filter action, you cannot set the loss-priority firewall filter action to medium-low or medium-high unless you enable the CoS tricolor marking feature. .
To enable the CoS tricolor marking feature, include the tri-color statement at the [edit class-of-service] hierarchy level.
Restrictions
You cannot configure the loss-priority and three-color-policer nonterminating actions for the same firewall filter term. These two nonterminating actions are mutually exclusive.
Multifield Classification Limitations on M Series Routers


Problem: Output-Filter Matching on Input-Filter Classification on page 378 Workaround: Configure All Actions in the Ingress Filter on page 379
Problem: Output-Filter Matching on Input-Filter Classification

On M Series routers (except M120 routers), you cannot classify packets with an output filter match based on the ingress classification that is set with an input filter applied to the same IPv4 logical interface. For example, in the following configuration, the filter called ingress assigns all incoming IPv4 packets to the expedited-forwarding class. The filter called egress counts all packets that were assigned to the expedited-forwarding class in the ingress filter. This configuration does not work on most M Series routers. It works on all other routing platforms, including M120 routers, MX Series routers, and T Series routers.
[edit] user@host # show firewall family inet { filter ingress { term 1 { then { forwarding-class expedited-forwarding; accept; } } term 2 { then accept; } } filter egress {
378
term 1 { from { forwarding-class expedited-forwarding; } then count ef; } term 2 { then accept; } } } [edit] user@host# show interfaces ge-1/2/0 { unit 0 { family inet { filter { input ingress; output egress; } } } }
Workaround: Configure All Actions in the Ingress Filter

As a workaround, you can configure all of the actions in the ingress filter.
user@host # show firewall family inet { filter ingress { term 1 { then { forwarding-class expedited-forwarding; accept; count ef; } } term 2 { then accept; } } } [edit] user@host# show interfaces ge-1/2/0 { unit 0 { family inet { filter { input ingress; } } } }
379
Example: Configuring Multifield Classification

This example shows how to configure multifield classification of IPv4 traffic by using firewall filter actions and two firewall filter policers.

Requirements
Before you begin, make sure that your environment supports the features shown in this example:
1.
The loss-priority firewall filter action must be supported on the router and configurable to all four values. a. To be able to set a loss-priority firewall filter action, configure this example on logical interface ge-1/2/0.0 on one of the following routing platforms:

MX Series router M120 or M320 router M7i or M10i router with the Enhanced CFEB (CFEB-E) T Series router with Enhanced II Flexible PIC Concentrator (FPC)
b. To be able to set a loss-priority firewall filter action to medium-low or medium-high, make sure that the CoS tricolor marking feature is enabled. To enable the CoS tricolor marking feature, include the tri-color statement at the [edit class-of-service] hierarchy level.
2. The expedited-forwarding and assured-forwarding forwarding classes must be
scheduled on the underlying physical interface ge-1/2/0. a. Make sure that the following forwarding classes are assigned to output queues:

expedited-forwarding assured-forwarding
Forwarding-class assignments are configured at the [edit class-of-service forwarding-classes queue queue-number] hierarchy level.
NOTE: You cannot commit a configuration that assigns the same forwarding class to two different queues.
380
b. Make sure that the output queues to which the forwarding classes are assigned are associated with schedulers. A scheduler defines the amount of interface bandwidth assigned to the queue, the size of the memory buffer allocated for storing packets, the priority of the queue, and the random early detection (RED) drop profiles associated with the queue.
You configure output queue schedulers at the [edit class-of-service schedulers] hierarchy level. You associate output queue schedulers with forwarding classes by means of a scheduler map that you configure at the [edit class-of-service scheduler-maps map-name] hierarchy level.
c. Make sure that output-queue scheduling is applied to the physical interface ge-1/2/0. You apply a scheduler map to a physical interface at the [edit class-of-service interfaces ge-1/2/0 scheduler-map map-name] hierarchy level.
Overview
In this example, you apply multifield classification to the input IPv4 traffic at a logical interface by using stateless firewall filter actions and two firewall filter policers that are referenced from the firewall filter. Based on the source address field, packets are either set to the low loss priority or else policed. Neither of the policers discards nonconforming traffic. Packets in nonconforming flows are marked for a specific forwarding class (expedited-forwarding or assured-forwarding), set to a specific loss priority, and then transmitted.
NOTE: Single-rate two-color policers always transmit packets in a conforming traffic flow after implicitly setting a low loss priority.
Topology In this example, you apply multifield classification to the IPv4 traffic on logical interface ge-1/2/0.0. The classification rules are specified in the IPv4 stateless firewall filter mfc-filter and two single-rate two-color policers, ef-policer and af-policer. The IPv4 standard stateless firewall filter mfc-filter defines three filter terms:
isp1-customersThe first filter term matches packets with the source address 10.1.1.0/24
or 10.1.2.0/24. Matched packets are assigned to the expedited-forwarding forwarding class and set to the low loss priority.
isp2-customersThe second filter term matches packets with the source address
10.1.3.0/24 or 10.1.4.0/24. Matched packets are passed to ef-policer, a policer that rate-limits traffic to a bandwidth limit of 300 Kbps with a burst-size limit of 50 KB. This policer specifies that packets in a nonconforming flow are marked for the expedited-forwarding forwarding class and set to the high loss priority.
381
other-customersThe third and final filter term passes all other packets to af-policer,
a policer that rate-limits traffic to a bandwidth limit of 300 Kbps and a burst-size limit of 50 KB (the same traffic limits as defined by ef-policer). This policer specifies that packets in a nonconforming flow are marked for the assured-forwarding forwarding class and set to the medium-high loss priority.
Configuration
Configuring Policers to Rate-Limit Expedited-Forwarding and Assured-Forwarding Traffic on page 382 Configuring a Multifield Classification Filter That Also Applies Policing on page 383 Applying Multifield Classification Filtering and Policing to the Logical Interface on page 385
set firewall policer ef-policer if-exceeding bandwidth-limit 300k set firewall policer ef-policer if-exceeding burst-size-limit 50k set firewall policer ef-policer then loss-priority high set firewall policer ef-policer then forwarding-class expedited-forwarding set firewall policer af-policer if-exceeding bandwidth-limit 300k set firewall policer af-policer if-exceeding burst-size-limit 50k set firewall policer af-policer then loss-priority high set firewall policer af-policer then forwarding-class assured-forwarding set firewall family inet filter mfc-filter term isp1-customers from source-address 10.1.1.0/24 set firewall family inet filter mfc-filter term isp1-customers from source-address 10.1.2.0/24 set firewall family inet filter mfc-filter term isp1-customers then loss-priority low set firewall family inet filter mfc-filter term isp1-customers then forwarding-class expedited-forwarding set firewall family inet filter mfc-filter term isp2-customers from source-address 10.1.3.0/24 set firewall family inet filter mfc-filter term isp2-customers from source-address 10.1.4.0/24 set firewall family inet filter mfc-filter term isp2-customers then policer ef-policer set firewall family inet filter mfc-filter term other-customers then policer af-policer set interfaces ge-1/2/0 unit 0 family inet address 192.168.1.1/24 set interfaces ge-1/2/0 unit 0 family inet filter input mfc-filter
Configuring Policers to Rate-Limit Expedited-Forwarding and Assured-Forwarding Traffic Step-by-Step Procedure To configure policers to rate-limit expedited-forwarding and assured-forwarding traffic:
1.
Define traffic limits for expedited-forwarding traffic.

[edit] user@host# edit firewall policer ef-policer
382
[edit firewall policer ef-policer] user@host# set if-exceeding bandwidth-limit 300k user@host# set if-exceeding burst-size-limit 50k user@host# set then loss-priority high user@host# set then forwarding-class expedited-forwarding
2.
Configure a policer for assured-forwarding traffic.

[edit firewall policer ef-policer] user@host# up [edit firewall] user@host# edit policer af-policer [edit firewall policer af-policer] user@host# set if-exceeding bandwidth-limit 300k user@host# set if-exceeding burst-size-limit 50k user@host# set then loss-priority high user@host# set then forwarding-class assured-forwarding
Results
[edit] user@host# show firewall policer af-policer { if-exceeding { bandwidth-limit 300k; burst-size-limit 50k; } then { loss-priority high; forwarding-class assured-forwarding; } } policer ef-policer { if-exceeding { bandwidth-limit 300k; burst-size-limit 50k; } then { loss-priority high; forwarding-class expedited-forwarding; } }
Configuring a Multifield Classification Filter That Also Applies Policing Step-by-Step Procedure To configure a multifield classification filter that additionally applies policing:
1.
Enable configuration of a firewall filter term for IPv4 traffic.

[edit] user@host# edit firewall family inet filter mfc-filter
383
2.
Configure the first term to match on source addresses and then classify the matched packets.
[edit firewall family inet filter mfc-filter] user@host# set term isp1-customers from source-address 10.1.1.0/24 user@host# set term isp1-customers from source-address 10.1.2.0/24 user@host# set term isp1-customers then loss-priority low user@host# set term isp1-customers then forwarding-class expedited-forwarding
3.
Configure the second term to match on different source addresses and then police the matched packets.
[edit firewall family inet filter mfc-filter] user@host# set term isp2-customers from source-address 10.1.3.0/24 user@host# set term isp2-customers from source-address 10.1.4.0/24 user@host# set term isp2-customers then policer ef-policer
4.
Configure the third term to police all other packets to a different set of traffic limits and actions.
[edit firewall family inet filter mfc-filter] user@host# set term other-customers then policer af-policer
Results
Confirm the configuration of the filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall family inet { filter mfc-filter { term isp1-customers { from { source-address 10.1.1.0/24; source-address 10.1.2.0/24; } then { loss-priority low; forwarding-class expedited-forwarding; } } term isp2-customers { from { source-address 10.1.3.0/24; source-address 10.1.4.0/24; } then { policer ef-policer; } } term other-customers { then { policer af-policer; } } } }
384
policer af-policer { if-exceeding { bandwidth-limit 300k; burst-size-limit 50k; } then discard; } policer ef-policer { if-exceeding { bandwidth-limit 200k; burst-size-limit 50k; } then { loss-priority high; forwarding-class expedited-forwarding; } }
Applying Multifield Classification Filtering and Policing to the Logical Interface Step-by-Step Procedure To apply multifield classification filtering and policing to the logical interface:
1.

2.
Configure an IP address for the logical interface.

[edit interfaces ge-1/2/0 unit 0 family inet ] user@host# set address 192.168.1.1/24
3.
Apply the firewall filter to the logical interface input.

[edit interfaces ge-1/2/0 unit 0 family inet ] user@host# set filter input mfc-filter
NOTE: Because the policer is executed before the filter, if an input policer is also configured on the logical interface, it cannot use the forwarding class and PLP of a multifield classifier associated with the interface.
Results
[edit] user@host# show interfaces ge-1/2/0 { unit 0 { family inet { filter { input mfc-filter; } address 192.168.1.1/24;
385
} } }
Verification
Confirm that the configuration is working properly. Displaying the Number of Packets Processed by the Policer at the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface. Use the show firewall operational mode command for the filter you applied to the logical interface.
user@host> show firewall filter rate-limit-in Filter: rate-limit-in Policers: Name ef-policer-isp2-customers af-policer-other-customers
Action
Packets 32863 3870
The command output lists the policers applied by the firewall filter rate-limit-in, and the number of packets that matched the filter term.
NOTE: The packet count includes the number of out-of-specification (out-of-spec) packet counts, not all packets policed by the policer.
The policer name is displayed concatenated with the name of the firewall filter term in which the policer is referenced as an action.
Example: Configuring and Applying a Firewall Filter for a Multifield Classifier

This example shows how to configure a firewall filter to classify traffic using a multifield classifier. The classifier detects packets of interest to CoS as they arrive on an interface.

Requirements
Before you begin, review how to create and configure a firewall. See Guidelines for Configuring Standard Firewall Filters on page 21.
386
Overview
One common way to detect packets of CoS interest is by source or destination address. The destination address is used in this example, but many other matching criteria for packet detection are available to firewall filters. In this example, you configure the firewall filter mf-classifier. You create and name the assured forwarding traffic class, set the match condition, and specify the destination address as 192.168.44.55. You create the forwarding class for assured forwarding DiffServ traffic as af-class and set the loss priority to low. Then you create and name the expedited forwarding traffic class, set the match condition, for the expedited forwarding traffic class, and specify the destination address as 192.168.66.77. You then create the forwarding class for expedited forwarding DiffServ traffic as ef-class and set the policer to ef-policer. Then you create and name the network-control traffic class and set the match condition. You then create and name the forwarding class for the network control traffic class as nc-class. You create and name the forwarding class for the best-effort traffic class as be-class. Finally, you apply the multifield classifier firewall filter as an input filter on each customer-facing or host-facing that needs the filter. In this example, the interface is ge-0/0/0.
Configuration
set firewall filter mf-classifier interface-specific set firewall filter mf-classifier term assured-forwarding from destination-address 192.168.44.55 set firewall filter mf-classifier term assured-forwarding then forwarding-class af-class set firewall filter mf-classifier term assured-forwarding then loss-priority low set firewall filter mf-classifier term expedited-forwarding from destination-address 192.168.66.77 set firewall filter mf-classifier term expedited-forwarding then forwarding-class ef-class set firewall filter mf-classifier term expedited-forwarding then policer ef-policer set firewall filter mf-classifier term network-control from precedence net-control set firewall filter mf-classifier term network-control then forwarding-class nc-class set firewall filter mf-classifier term best-effort then forwarding-class be-class set interfaces ge-0/0/0 unit 0 family inet filter input mf-classifier
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode on page 15 in the Junos OS CLI User Guide. To configure a firewall filter for a multifield classifier for a device:
1.
Create and name the multifield classifier filter.

[edit]
387
user@host# edit firewall filter mf-classifier user@host# set interface-specific

2.
Create and name the term for the assured forwarding traffic class.
[edit firewall filter mf-classifier] user@host# edit term assured-forwarding
3.
Specify the destination address for assured forwarding traffic.

[edit firewall filter mf-classifier term assured-forwarding] user@host# set from destination-address 192.168.44.55
4.
Create the forwarding class and set the loss priority for the assured forwarding traffic class.
[edit firewall filter mf-classifier term assured-forwarding] user@host# set then forwarding-class af-class user@host# set then loss-priority low
5.
Create and name the term for the expedited forwarding traffic class.
[edit] user@host# edit firewall filter mf-classifier user@host# edit term expedited-forwarding
6.
Specify the destination address for the expedited forwarding traffic.

[edit firewall filter mf-classifier term expedited-forwarding] user@host# set from destination-address 192.168.66.77
7.
Create the forwarding class and apply the policer for the expedited forwarding traffic class.
[edit firewall filter mf-classifier term expedited-forwarding] user@host# set then forwarding-class ef-class user@host# set then policer ef-policer
8.
Create and name the term for the network control traffic class.
[edit] user@host# edit firewall filter mf-classifier user@host# edit term network-control
9.
Create the match condition for the network control traffic class.
[edit firewall filter mf-classifier term network-control] user@host# set from precedence net-control
10.
Create and name the forwarding class for the network control traffic class.
[edit firewall filter mf-classifier term network-control] user@host# set then forwarding-class nc-class
11.
Create and name the term for the best-effort traffic class.
[edit] user@host# edit firewall filter mf-classifier user@host# edit term best-effort
12.
Create and name the forwarding class for the best-effort traffic class.
[edit firewall filter mf-classifier term best-effort] user@host# set then forwarding-class be-class
388
NOTE: Because this is the last term in the filter, it has no match condition.
13.
Apply the multifield classifier firewall filter as an input filter.

[edit] user@host# set interfaces ge-0/0/0 unit 0 family inet filter input mf-classifier
Results
From configuration mode, confirm your configuration by entering the show firewall filter mf-classifier command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit] user@host# show firewall filter mf-classifier interface-specific; term assured-forwarding { from { destination-address { 192.168.44.55/32; } } then { loss-priority low; forwarding-class af-class; } } term expedited-forwarding { from { destination-address { 192.168.66.77/32; } } then { policer ef-policer; forwarding-class ef-class; } } term network-control { from { precedence net-control; } then forwarding-class nc-class; } term best-effort { then forwarding-class be-class; }
389
Verification
Verifying a Firewall Filter for a Multifield Classifier Configuration on page 390
Verifying a Firewall Filter for a Multifield Classifier Configuration Purpose Action Verify that a firewall filter for a multifield classifier is configured properly on a device. From configuration mode, enter the show firewall filter mf-classifier command.
Standard Firewall Filter Nonterminating Actions on page 82 in the Junos OS Firewall

Filter and Policer Configuration Guide
Order of Policer and Firewall Filter Operations on page 304 Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Guidelines for Applying Traffic Policers on page 316 Junos CoS Components in the Junos OS Class of Service Configuration Guide BA Classifier Overview in the Junos OS Class of Service Configuration Guide Overview of Forwarding Classes in the Junos OS Class of Service Configuration Guide Default Forwarding Classes in the Junos OS Class of Service Configuration Guide RED Drop Profiles Overview in the Junos OS Class of Service Configuration Guide
tri-color statement in the Junos OS Class of Service Configuration Guide
Policer Overhead to Account for Rate Shaping in the Traffic Manager

Policer Overhead to Account for Rate Shaping Overview on page 390 Example: Configuring Policer Overhead to Account for Rate Shaping on page 391
Policer Overhead to Account for Rate Shaping Overview

If you configure ingress or egress traffic-shaping overhead values for an interface, the traffic manager cannot apply these values to any rate-limiting also applied to the interface. To enable the router to account for the additional Ethernet frame length when policing actions are being determined, you must configure the ingress or egress overhead values for policers separately.
NOTE: When a policer overhead value is changed, the PIC or DPC goes offline and then comes back online.
390
For Gigabit Ethernet Intelligent Queuing 2 (IQ2) and Enhanced IQ2 (IQ2E) PICs or interfaces on Dense Port Concentrators (DPCs) in MX Series routers, you can control the rate of traffic that passes through all interfaces on the PIC or DPC by configuring a policer overhead. You can configure a policer ingress overhead and a policer egress overhead, each with values from 0 through 255 bytes. The policer overhead values are added to the length of the final Ethernet frame when determining ingress and egress policer actions.
Example: Configuring Policer Overhead to Account for Rate Shaping

This example shows how to configure overhead values for policers when rate-shaping overhead is configured.

Requirements
Before you begin, make sure that interface for which you are applying ingress or egress policer overhead is hosted on one of the following:

Gigabit Ethernet IQ2 PIC IQ2E PIC DPCs in MX Series routers
Overview
This example shows how to configure policer overhead values for all physical interfaces on a supported PIC or MPC so that the rate shaping value configured on a logical interface is accounted for in any policing on that logical interface. Topology The router hosts a Gigabit Ethernet IQ2 PIC, installed in PIC location 3 of the Flexible PIC Concentrator (FPC) in slot number 1. The physical interface on port 1 on that PIC is configured to receive traffic on logical interface 0 and send it back out on logical interface 1. Class-of-service scheduling includes 100 Mbps of traffic rate-shaping overhead for the output traffic. A policer egress overhead of 100 bytes is configured on the entire PIC so that, for any policers applied to the output traffic, 100 bytes are added to the final Ethernet frame length when determining ingress and egress policer actions.
391
NOTE: Traffic rate-shaping and corresponding policer overhead are configured separately:
You configure rate shaping at the [edit class-of-service interfaces interface-name unit unit-number] hierarchy level. You configure policer overhead at the [edit chassis fpc slot-number pic pic-number] hierarchy level.
When a policer overhead value is changed, the PIC or DPC goes offline and then comes back online.
Configuration

Configuring the Logical Interfaces on page 393 Configuring Traffic Rate-Shaping on the Logical Interface That Carries Output Traffic on page 394 Configuring Policer Overhead on the PIC or MPC That Hosts the Rate-Shaped Logical Interface on page 396 Applying a Policer to the Logical Interface That Carries Input Traffic on page 396
set interfaces ge-1/3/1 per-unit-scheduler set interfaces ge-1/3/1 vlan-tagging set interfaces ge-1/3/1 unit 0 vlan-id 100 set interfaces ge-1/3/1 unit 0 family inet address 10.10.10.1/30 set interfaces ge-1/3/1 unit 1 vlan-id 101 set interfaces ge-1/3/1 unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44 set class-of-service schedulers be transmit-rate percent 5 set class-of-service schedulers ef transmit-rate percent 30 set class-of-service schedulers af transmit-rate percent 30 set class-of-service schedulers nc transmit-rate percent 35 set class-of-service scheduler-maps my-map forwarding-class best-effort scheduler be set class-of-service scheduler-maps my-map forwarding-class expedited-forwarding scheduler ef set class-of-service scheduler-maps my-map forwarding-class network-control scheduler nc set class-of-service scheduler-maps my-map forwarding-class assured-forwarding scheduler af set class-of-service interfaces ge-1/3/1 unit 1 scheduler-map my-map set class-of-service interfaces ge-1/3/1 unit 1 shaping-rate 100m
392
set firewall policer 500Kbps logical-interface-policer set firewall policer 500Kbps if-exceeding bandwidth-limit 500k set firewall policer 500Kbps if-exceeding burst-size-limit 625k set firewall policer 500Kbps then discard set chassis fpc 1 pic 3 ingress-policer-overhead 100 set chassis fpc 1 pic 3 egress-policer-overhead 100 set interfaces ge-1/3/1 unit 0 family inet policer input 500Kbps
1.
Enable configuration of the interface

2.
Enable multiple queues for each logical interface (so that you can associate an output scheduler with each logical interface).
[edit interfaces ge-1/3/1] user@host# set per-unit scheduler user@host# set vlan-tagging
NOTE: For Gigabit Ethernet IQ2 PICs only, use the shared-scheduler statement to enable shared schedulers and shapers on a physical interface.
3.
Configure logical interface ge-1/3/1.0.

4.

[edit interfaces ge-1/3/1] user@host# set unit 1 vlan-id 101 user@host# set unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44
Results
[edit] user@host# show interfaces ge-1/3/1 { per-unit-scheduler; vlan-tagging; unit 0 { vlan-id 100; family inet { address 10.10.10.1/30;
393
} } unit 1 { vlan-id 101; family inet { address 20.20.20.1/30 { arp 20.20.20.2 mac 00:00:11:22:33:44; } } } }
Configuring Traffic Rate-Shaping on the Logical Interface That Carries Output Traffic Step-by-Step Procedure To configure traffic rate-shaping on the logical interface that carries output traffic:
1.
Enable configuration of class-of-service features.

[edit] user@host# edit class-of-service
2.
Configure packet scheduling on logical interface ge-1/3/1.0. a. Configure schedulers that specify the percentage of transmission capacity.
[edit class-of-service] user@host# edit schedulers [edit class-of-service schedulers] user@host# set be transmit-rate percent 5 user@host# set ef transmit-rate percent 30 user@host# set af transmit-rate percent 30 user@host# set nc transmit-rate percent 35
A percentage of zero drops all packets in the queue. When the rate-limit option is specified, the transmission rate is limited to the rate-controlled amount. In contrast with the exact option, a scheduler with the rate-limit option shares unused bandwidth above the rate-controlled amount. b. Configure a scheduler map to associate each scheduler with a forwarding class.
[edit class-of-service] user@host# edit scheduler-maps my-map [edit class-of-service scheduler-maps my-map] user@host# set forwarding-class best-effort scheduler be user@host# set forwarding-class expedited-forwarding scheduler ef user@host# set forwarding-class network-control scheduler nc user@host# set forwarding-class assured-forwarding scheduler af
c. Associate the scheduler map with logical interface ge-1/3/1.0.

[edit class-of-service] user@host# edit interfaces ge-1/3/1 unit 1 [edit class-of-service interfaces ge-1/3/1 unit 1] user@host# set scheduler-map my-map
394
3.
Configure 100 Mbps of traffic rate-shaping overhead on logical interface ge-1/3/1.1.

[edit class-of-service interfaces ge-1/3/1 unit 1] user@host# set shaping-rate 100
Alternatively, you can configure a shaping rate for a logical interface and oversubscribe the physical interface by including the shaping-rate statement at the [edit class-of-service traffic-control-profiles] hierarchy level. With this configuration approach, you can independently control the delay-buffer rate. Results Confirm the configuration of the class-of-service features (including the 100 Mbp of shaping of the egress traffic) by entering the show class-of-service configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show class-of-service interfaces { ge-1/3/1 { unit 1 { scheduler-map my-map; shaping-rate 100m; } } } scheduler-maps { my-map { forwarding-class best-effort scheduler be; forwarding-class expedited-forwarding scheduler ef; forwarding-class network-control scheduler nc; forwarding-class assured-forwarding scheduler af; } } schedulers { be { transmit-rate percent 5; } ef { transmit-rate percent 30; } af { transmit-rate percent 30; } nc { transmit-rate percent 35; } }
395
Configuring Policer Overhead on the PIC or MPC That Hosts the Rate-Shaped Logical Interface Step-by-Step Procedure To configure policer overhead on the PIC or MPC that hosts the rate-shaped logical interface:
1.
Enable configuration of the supported PIC or MPC.

[edit] user@host# set chassis fpc 1 pic 3
2.
Configure 100 bytes of policer overhead on the supported PIC or MPC.

[edit] user@host# set ingress-policer-overhead 100 user@host# set egress-policer-overhead 100
NOTE: These values are added to the length of the final Ethernet frame when determining ingress and egress policer actions for all physical interfaces on the PIC or MPC.
You can specify policer overhead with values from 0 through 255 bytes. Results Confirm the configuration of the policer overhead on the physical interface to account for rate-shaping by entering the show chassis configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show chassis chassis { fpc 1 { pic 3 { egress-policer-overhead 100; ingress-policer-overhead 100; } } }
Applying a Policer to the Logical Interface That Carries Input Traffic Step-by-Step Procedure To apply a policer to the logical interface that carries input traffic:
1.
Configure the logical interface (aggregate) policer.

[edit] user@host# edit firewall policer 500Kbps [edit firewall policer 500Kbps] user@host# set logical-interface-policer user@host# set if-exceeding bandwidth-limit 500k user@host# set if-exceeding burst-size-limit 625k user@host# set then discard
396
2.
Apply the policer to Layer 3 input on the IPv4 logical interface.

[edit] user@host# set interfaces ge-1/3/1 unit 0 family inet policer input 500Kbps
NOTE: The 100 Mbps policer overhead is added to the length of the final Ethernet frame when determining ingress and egress policer actions,
Results
Confirm the configuration of the policer with rate-shaping overhead by entering the show firewall and show interfaces configuration mode commands. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall policer 500Kbps { logical-interface-policer; if-exceeding { bandwidth-limit 500k; burst-size-limit 625k; } then discard; } [edit] user@host# show interfaces ge-1/3/1 { per-unit-scheduler; vlan-tagging; unit 0 { vlan-id 100; layer2-policer { input-policer 500Kbps; } family inet { address 10.10.10.1/30; } } unit 0 { vlan-id 101; family inet { address 20.20.20.1/30 { arp 20.20.20.2 mac 00:00:11:22:33:44; } } } }
397
Verification

Displaying Traffic Statistics and Policers for the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface. Use the show interfaces operational mode command for logical interface ge-1/3/1.0, and include the detail or extensive option. The command output section for Traffic statistics lists the number of bytes and packets received and transmitted on the logical interface, and the Protocol inet section contains a Policer field that would list the policer 500Kbps as an input or output policer as follows:

Action
Input: 500Kbps-ge-1/3/1.0-log_int-i Output: 500Kbps-ge-1/3/1.0-log_int-o
The log_int-i suffix denotes a logical interface policer applied to input traffic, while the log_int-o suffix denotes a logical interface policer applied to output traffic. In this example, the logical interface policer is applied to Input traffic only. Displaying Statistics for the Policer Purpose Action Verify the number of packets evaluated by the policer. Use the show policer operational mode command and optionally specify the name of the policer. The command output displays the number of packets evaluated by each configured policer (or the specified policer), in each direction. For the policer 500Kbps, the input and output policer names are displayed as follows:

500Kbps-ge-1/3/1.0-log_int-i 500Kbps-ge-1/3/1.0-log_int-o
The log_int-i suffix denotes a logical interface policer applied to input traffic, while the log_int-o suffix denotes a logical interface policer applied to output traffic. In this example, the logical interface policer is applied to input traffic only.
Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Guidelines for Applying Traffic Policers on page 316 Configuring a Policer Overhead in the Junos OS System Basics and Services Command
Reference
398
CHAPTER 12
Three-Color Policer Configuration

This chapter covers three-color policing applied to Layer 3 traffic.

Three-Color Policer Configuration Guidelines on page 399 Basic Single-Rate Three-Color Policers on page 401 Basic Two-Rate Three-Color Policers on page 407
Three-Color Policer Configuration Guidelines

Platforms Supported for Three-Color Policers on page 399 Color Modes for Three-Color Policers on page 400 Naming Conventions for Three-Color Policers on page 400
Platforms Supported for Three-Color Policers

Three-color policers are supported on the following Juniper Networks routers:

M120 Multiservice Edge Routers M320 Multiservice Edge Routers and T Series Core Routers with Enhanced II Flexible PIC Concentrators (FPCs) MX Series 3D Universal Edge Routers T640 Core Routers with Enhanced Scaling FPC4
On MX Series and M120 routers, you can apply three-color policers to aggregated interfaces. The discard action for a tricolor marking policer for a firewall filter is supported on the M120 routers, M320 routers with Enhanced-III FPCs, M7i and M10i routers with the Enhanced CFEB (CFEB-E), and MX Series routers with Trio MPCs, so it is not necessary to include the logical-interface-policer statement for them.
399
Color Modes for Three-Color Policers

Three-color policersboth single-rate and two-rate three-color policer schemescan operate in either of two modes:

Color-Blind Mode on page 400 Color-Aware Mode on page 400
Color-Blind Mode
In color-blind mode, the three-color policer assumes that all packets examined have not been previously marked or metered. If you configure a three-color policer to be color-blind instead of color-aware, the policer ignores preexisting color markings that might have been set for a packet by another traffic policer configured at a previous network node.
Color-Aware Mode
In color-aware mode, the three-color policer assumes that all packets examined have been previously marked or metered. In other words, the three-color policer takes into account any coloring markings that might have been set for a packet by another traffic policer configured at a previous network node. At the node where color-aware policing is configured, any preexisting color markings are used in determining the appropriate policing action for the packet. In color-aware mode, the three-color policer can increase the packet loss priority (PLP) level of a packet, but never decrease it. For example, if a color-aware three-color policer meters a packet with a medium PLP marking, it can raise the PLP level to high, but cannot reduce the PLP level to low. For two-rate, three-color policing, the Junos OS uses two token buckets to manage bandwidth based on the two rates of traffic. For example, two-rate policing might be configured on a node upstream in the network. The two-rate policer has marked a packet as yellow (loss priority medium-low). The color-aware policer takes this yellow marking into account when determining the appropriate policing action. In color-aware policing, the yellow packet would never receive the action associated with either the green packets or red packets. This way, tokens for violating packets are never taken from the metering token buckets at the color-aware policing node.
Naming Conventions for Three-Color Policers

Because policers can be numerous and must be applied correctly to work, a simple naming convention makes it easier to apply the policers properly. We recommend that you name your policer using a convention that identifies the basic components of the policer:
Three-color policer typeWhere srTCM identifies a single-rate three-color policer and trTCM identifies a two-rate three-color policer. Three-color policer color modeWhere ca identifies a color-aware three-color policer and cb identifies a color-blind three-color policer.
400
Chapter 12: Three-Color Policer Configuration
NOTE: TCM stands for tricolor marking.
Table 38 on page 401 describes a recommended naming convention for policers.
Table 38: Recommended Naming Convention for Policers

Three-Color Policer Type
Single-rate three-color, color-aware
Naming Convention
srTCMnumber-ca
Example Names
srTCM1-ca, srTCM2-ca, srTCM3-ca,
... Single-rate three-color, color-blind

srTCMnumber-cb srTCM1-cb, srTCM2-cb, srTCM3-cb,
... Two-rate three-color, color-aware

trTCMnumber-ca trTCM1-ca, trTCM2-ca, trTCM3-ca,
... Two-rate three-color, color-blind

trTCMnumber-cb trTCM1-cb, trTCM2-cb, trTCM3-cb,
...
Statement Hierarchy for Configuring Policers on page 305 Three-Color Policer Configuration Overview on page 311 Guidelines for Applying Traffic Policers on page 316
Basic Single-Rate Three-Color Policers

Single-Rate Three-Color Policer Overview on page 401 Example: Configuring a Single-Rate Three-Color Policer on page 402
Single-Rate Three-Color Policer Overview

A single-rate three-color policer defines a bandwidth limit and a maximum burst size for guaranteed traffic and a second burst size for peak traffic. A single-rate three-color policer is most useful when a service is structured according to packet length and not peak arrival rate.
401
Single-rate three-color policing meters a traffic stream based on the following configured traffic criteria:

Committed information rate (CIR)Bandwidth limit for guaranteed traffic. Committed burst size (CBS)Maximum packet size permitted for bursts of data that exceed the CIR. Excess burst size (EBS)Maximum packet size permitted for peak traffic.
Single-rate tricolor marking (single-rate TCM) classifies traffic as belonging to one of three color categories and performs congestion-control actions on the packets based on the color marking:
GreenTraffic that conforms to either the bandwidth limit or the burst size for guaranteed traffic (CIR and CBS). For a green traffic flow, single-rate marks the packets with an implicit loss priority of low and transmits the packets. YellowTraffic that exceeds both the bandwidth limit and the burst size for guaranteed traffic (CIR or CBS) but not the burst size for peak traffic (EBS). For a yellow traffic flow, single-rate marks the packets with an implicit loss priority of medium-high and transmits the packets. RedTraffic that exceeds the burst size for peak traffic (EBS), single-rate marks packets with an implicit loss priority of high and, optionally, discards the packets.
If congestion occurs downstream, the packets with higher loss priority are more likely to be discarded.
NOTE: For both single-rate and two-rate three-color policers, the only configurable action is to discard packets in a red traffic flow.
The discard action for a tricolor marking policer for a firewall filter is supported on the M120 routers, M320 routers with Enhanced-III FPCs, M7i and M10i routers with the Enhanced CFEB (CFEB-E), and MX Series routers with Trio MPCs, so it is not necessary to include the logical-interface-policer statement for them.
Example: Configuring a Single-Rate Three-Color Policer

This example shows how to configure a single-rate three-color policer.

Requirements
402
Overview
A single-rate three-color policer meters a traffic flow against a bandwidth limit and burst-size limit for guaranteed traffic, plus a second burst-size limit for excess traffic. Traffic that conforms to the limits for guaranteed traffic is categorized as green, and nonconforming traffic falls into one of two categories:
Nonconforming traffic that does not exceed the burst size for excess traffic is categorized as yellow. Nonconforming traffic that exceeds the burst size for excess traffic is categorized as red.
Each category is associated with an action. For green traffic, packets are implicitly set with a loss-priority value of low and then transmitted. For yellow traffic, packets are implicitly set with a loss-priority value of medium-high and then transmitted. For red traffic, packets are implicitly set with a loss-priority value of high and then transmitted. If the policer configuration includes the optional action statement (action loss-priority high then discard), then packets in a red flow are discarded instead. You can apply a three-color policer to Layer 3 traffic as a firewall filter policer only. You reference the policer from a stateless firewall filter term, and then you apply the filter to the input or output of a logical interface at the protocol level. Topology In this example, you apply a color-aware, single-rate three-color policer to the input IPv4 traffic at logical interface ge-2/0/5.0. The IPv4 firewall filter term that references the policer does not apply any packet-filtering. The filter is used only to apply the three-color policer to the interface. You configure the policer to rate-limit traffic to a bandwidth limit of 40 Mbps and a burst-size limit of 100 KB for green traffic but also allow an excess burst-size limit of 200 KB for yellow traffic. Only nonconforming traffic that exceeds the peak burst-size limit is categorized as red. In this example, you configure the three-color policer action loss-priority high then discard, which overrides the implicit marking of red traffic to a high loss priority.
Configuration

Configuring a Single-Rate Three-Color Policer on page 404 Configuring an IPv4 Stateless Firewall Filter That References the Policer on page 405 Applying the Filter to the Logical Interface on page 406
403
set firewall three-color-policer srTCM1-ca single-rate color-aware set firewall three-color-policer srTCM1-ca single-rate committed-information-rate 40m set firewall three-color-policer srTCM1-ca single-rate committed-burst-size 100k set firewall three-color-policer srTCM1-ca single-rate excess-burst-size 200k set firewall three-color-policer srTCM1-ca action loss-priority high then discard set firewall family inet filter filter-srtcm1ca-all term 1 then three-color-policer single-rate srTCM1-ca set class-of-service interfaces ge-2/0/5 unit 0 forwarding-class af set interfaces ge-2/0/5 unit 0 family inet address 10.20.130.1/24 set interfaces ge-2/0/5 unit 0 family inet filter input filter-srtcm1ca-all
Configuring a Single-Rate Three-Color Policer Step-by-Step Procedure To configure a single-rate three-color policer:
1.
Enable configuration of a three-color policer.

[edit] user@host# edit firewall three-color-policer srTCM1-ca
2.
Configure the color mode of the single-rate three-color policer.

[edit firewall three-color-policer srTCM1-ca] user@host# set single-rate color-aware
3.
Configure the single-rate guaranteed traffic limits.

[edit firewall three-color-policer srTCM1-ca] user@host# set single-rate committed-information-rate 40m user@host# set single-rate committed-burst-size 100k
4.
Configure the single-rate burst-size limit that is used to classify nonconforming traffic.
[edit firewall three-color-policer srTCM1-ca] user@host# set single-rate excess-burst-size 200k
5.
(Optional) Configure the action for nonconforming traffic.

[edit firewall three-color-policer srTCM1-ca] user@host# set action loss-priority high then discard
For three-color policers, the only configurable action is to discard packets in a red traffic flow. In this example, packets in a red traffic flow have been implicitly marked with a high packet loss priority (PLP) level because the traffic flow exceeded the rate-limiting defined by the single rate-limit (specified by the committed-information-rate 40m statement) and the larger burst-size limit (specified by the excess-burst-size 200k statement). Because the optional action statement is included, this example takes the more severe action of discarding packets in a red traffic flow.
404
Results
Confirm the configuration of the hierarchical policer by entering the show firewall configuration command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
three-color-policer srTCM1-ca { action { loss-priority high then discard; } single-rate { color-aware; committed-information-rate 40m; committed-burst-size 100k; excess-burst-size 200k; } }
Configuring an IPv4 Stateless Firewall Filter That References the Policer Step-by-Step Procedure To configure a standard stateless firewall filter that references the policer:
1.
Enable configuration of an IPv4 standard stateless firewall filter.

[edit] user@host# edit firewall family inet filter filter-srtcm1ca-all
2.
Specify the filter term that references the policer.

[edit firewall family inet filter filter-srtcm1ca-all] user@host# set term 1 then three-color-policer single-rate srTCM1-ca
Note that the term does not specify any match conditions. The firewall filter passes all packets to the policer. Results Confirm the configuration of the firewall filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall family inet { filter filter-srtcm1ca-all { term 1 { then { three-color-policer { single-rate srTCM1-ca; } } } } } three-color-policer srTCM1-ca { action { loss-priority high then discard; } single-rate { color-aware; committed-information-rate 40m;
405
committed-burst-size 100k; excess-burst-size 200k; } }
Applying the Filter to the Logical Interface Step-by-Step Procedure To apply the filter to the logical interface:
1.
(MX Series routers only) (Optional) Reclassify all incoming packets on the logical interface ge-2/0/5.0 to assured forwarding, regardless of any preexisting classification.
[edit] user@host# set class-of-service interfaces ge-2/0/5 unit 0 forwarding-class af
The classifier name can be a configured classifier or one of the default classifiers.
2.
Enable configuration of the logical interface.

3.
Configure an IP address.
4.
Reference the filter as an input filter.

[edit interfaces ge-2/0/5 unit 0 family inet] user@host# set filter input filter-srtcm1ca-all
Results
Confirm the configuration of the interface by entering the show class-of-service and show interfaces configuration mode commands. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show class-of-service interfaces { ge-2/0/5 { unit 0 { forwarding-class af; } } } [edit] user@host# show interfaces ge-2/0/5 { unit 0 { family inet { filter { input filter-srtcm1ca-all; } address 10.20.130.1/24; } }
406
Verification
Confirm that the configuration is working properly. Displaying the Firewall Filters Applied to the Logical Interface Purpose Action Verify that the firewall filter is applied to IPv4 input traffic at the logical interface. Use the show interfaces operational mode command for the logical interface ge-2/0/5.0, and specify detail mode. The Protocol inet section of the command output displays IPv4 information for the logical interface. Within that section, the Input Filters field displays the name of the firewall filter applied to IPv4 input traffic at the logical interface.
user@host> show interfaces ge-2/0/5.0 detail Logical interface ge-2/0/5.0 (Index 105) (SNMP ifIndex 556) (Generation 170) Flags: Device-Down SNMP-Traps 0x4004000 Encapsulation: ENET2 Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol inet, MTU: 1500, Generation: 242, Route table: 0 Flags: Sendbcast-pkt-to-re Input Filters: filter-srtcm1ca-all Addresses, Flags: Dest-route-down Is-Preferred Is-Primary Destination: 10.20.130/24, Local: 10.20.130.1, Broadcast: 10.20.130.255, Generation: 171 Protocol multiservice, MTU: Unlimited, Generation: 243, Route table: 0 Policer: Input: __default_arp_policer__
Statement Hierarchy for Configuring Policers on page 305 Three-Color Policer Configuration Overview on page 311 Three-Color Policer Configuration Guidelines on page 399
Basic Two-Rate Three-Color Policers

Two-Rate Three-Color Policer Overview on page 408 Example: Configuring a Two-Rate Three-Color Policer on page 409
407
Two-Rate Three-Color Policer Overview

A two-rate three-color policer defines two bandwidth limits (one for guaranteed traffic and one for peak traffic) and two burst sizes (one for each of the bandwidth limits). A two-rate three-color policer is most useful when a service is structured according to arrival rates and not necessarily packet length. Two-rate three-color policing meters a traffic stream based on the following configured traffic criteria:

Committed information rate (CIR)Bandwidth limit for guaranteed traffic. Committed burst size (CBS)Maximum packet size permitted for bursts of data that exceed the CIR. Peak information rate (PIR)Bandwidth limit for peak traffic. Peak burst size (PBS)Maximum packet size permitted for bursts of data that exceed the PIR.
Two-rate tricolor marking (two-rate TCM) classifies traffic as belonging to one of three color categories and performs congestion-control actions on the packets based on the color marking:
GreenTraffic that conforms to the bandwidth limit and burst size for guaranteed traffic (CIR and CBS). For a green traffic flow, two-rate TCM marks the packets with an implicit loss priority of low and transmits the packets. YellowTraffic that exceeds the bandwidth limit or burst size for guaranteed traffic (CIR or CBS) but not the bandwidth limit and burst size for peak traffic (PIR and PBS). For a yellow traffic flow, two-rate TCM marks packets with an implicit loss priority of medium-high and transmits the packets. RedTraffic that exceeds the bandwidth limit and burst size for peak traffic (PIR and PBS). For a red traffic flow, two-rate TCM marks packets with an implicit loss priority of high and, optionally, discards the packets.
If congestion occurs downstream, the packets with higher loss priority are more likely to be discarded.
NOTE: For both single-rate and two-rate three-color policers, the only configurable action is to discard packets in a red traffic flow.
For a tricolor marking policer referenced by a firewall filter term, the discard policing action is supported on the following routing platforms:

M7i and M10i routers with the Enhanced CFEB (CFEB-E) M120 and M320 routers with Enhanced-III FPCs MX Series routers with Trio MPCs
408
To apply a tricolor marking policer on these routing platforms, it is not necessary to include the logical-interface-policer statement.
Example: Configuring a Two-Rate Three-Color Policer

This example shows how to configure a two-rate three-color policer.

Requirements
Overview
A two-rate three-color policer meters a traffic flow against a bandwidth limit and burst-size limit for guaranteed traffic, plus a bandwidth limit and burst-size limit for peak traffic. Traffic that conforms to the limits for guaranteed traffic is categorized as green, and nonconforming traffic falls into one of two categories:

Nonconforming traffic that does not exceed peak traffic limits is categorized as yellow. Nonconforming traffic that exceeds peak traffic limits is categorized as red.
Each category is associated with an action. For green traffic, packets are implicitly set with a loss-priority value of low and then transmitted. For yellow traffic, packets are implicitly set with a loss-priority value of medium-high and then transmitted. For red traffic, packets are implicitly set with a loss-priority value of high and then transmitted. If the policer configuration includes the optional action statement (action loss-priority high then discard), then packets in a red flow are discarded instead. You can apply a three-color policer to Layer 3 traffic as a firewall filter policer only. You reference the policer from a stateless firewall filter term, and then you apply the filter to the input or output of a logical interface at the protocol level. Topology In this example, you apply a color-aware, two-rate three-color policer to the input IPv4 traffic at logical interface fe-0/1/1.0. The IPv4 firewall filter term that references the policer does not apply any packet-filtering. The filter is used only to apply the three-color policer to the interface. You configure the policer to rate-limit traffic to a bandwidth limit of 40 Mbps and a burst-size limit of 100 KB for green traffic, and you configure the policer to also allow a peak bandwidth limit of 60 Mbps and a peak burst-size limit of 200 KB for yellow traffic. Only nonconforming traffic that exceeds the peak traffic limits is categorized as red. In this example, you configure the three-color policer action loss-priority high then discard, which overrides the implicit marking of red traffic to a high loss priority.
409
Configuration

Configuring a Two-Rate Three-Color Policer on page 410 Configuring an IPv4 Stateless Firewall Filter That References the Policer on page 411 Applying the Filter to a Logical Interface at the Protocol Family Level on page 412
set firewall three-color-policer trTCM1-ca two-rate color-aware set firewall three-color-policer trTCM1-ca two-rate committed-information-rate 40m set firewall three-color-policer trTCM1-ca two-rate committed-burst-size 100k set firewall three-color-policer trTCM1-ca two-rate peak-information-rate 60m set firewall three-color-policer trTCM1-ca two-rate peak-burst-size 200k set firewall three-color-policer trTCM1-ca action loss-priority high then discard set firewall family inet filter filter-trtcm1ca-all term 1 then three-color-policer two-rate trTCM1-ca set interfaces ge-2/0/5 unit 0 family inet address 10.10.10.1/30 set interfaces ge-2/0/5 unit 0 family inet filter input filter-trtcm1ca-all set class-of-service interfaces ge-2/0/5 forwarding-class af
Configuring a Two-Rate Three-Color Policer Step-by-Step Procedure To configure a two-rate three-color policer:
1.

[edit] user@host# set firewall three-color-policer trTCM1-ca
2.
Configure the color mode of the two-rate three-color policer.

[edit firewall three-color-policer trTCM1-ca] user@host# set two-rate color-aware
3.
Configure the two-rate guaranteed traffic limits.

[edit firewall three-color-policer trTCM1-ca] user@host# set two-rate committed-information-rate 40m user@host# set two-rate committed-burst-size 100k
Traffic that does not exceed both of these limits is categorized as green. Packets in a green flow are implicitly set to low loss priority and then transmitted.
4.
Configure the two-rate peak traffic limits.

[edit firewall three-color-policer trTCM1-ca] user@host# set two-rate peak-information-rate 60m user@host# set two-rate peak-burst-size 200k
410
Nonconforming traffic that does not exceed both of these limits is categorized as yellow. Packets in a yellow flow are implicitly set to medium-high loss priority and then transmitted. Nonconforming traffic that exceeds both of these limits is categorized as red. Packets in a red flow are implicitly set to high loss priority.
5.
(Optional) Configure the policer action for red traffic.

[edit firewall three-color-policer trTCM1-ca] user@host# set action loss-priority high then discard
For three-color policers, the only configurable action is to discard red packets. Red packets are packets that have been assigned high loss priority because they exceeded the peak information rate (PIR) and the peak burst size (PBS). Results Confirm the configuration of the policer by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall three-color-policer trTCM1-ca { action { loss-priority high then discard; } two-rate { color-aware; committed-information-rate 40m; committed-burst-size 100k; peak-information-rate 60m; peak-burst-size 200k; } }
Configuring an IPv4 Stateless Firewall Filter That References the Policer Step-by-Step Procedure To configure an IPv4 stateless firewall filter that references the policer:
1.
Enable configuration of an IPv4 standard stateless firewall filter.

[edit] user@host# set firewall family inet filter filter-trtcm1ca-all
2.
Specify the filter term that references the policer.

[edit firewall family inet filter filter-trtcm1ca-all] user@host# set term 1 then three-color-policer two-rate trTCM1-ca
Note that the term does not specify any match conditions. The firewall filter passes all packets to the policer. Results Confirm the configuration of the firewall filter by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall
411
family inet { filter filter-trtcm1ca-all { term 1 { then { three-color-policer { two-rate trTCM1-ca; } } } } } three-color-policer trTCM1-ca { action { loss-priority high then discard; } two-rate { color-aware; committed-information-rate 40m; committed-burst-size 100k; peak-information-rate 60m; peak-burst-size 200k; } }
Applying the Filter to a Logical Interface at the Protocol Family Level Step-by-Step Procedure To apply the filter to the logical interface at the protocol family level:
1.
Enable configuration of an IPv4 firewall filter.

2.
Apply the policer to the logical interface at the protocol family level.
[edit interfaces ge-2/0/5 unit 0 family inet] user@host# set address 10.10.10.1/30 user@host# set filter input filter-trtcm1ca-all
3.
(MX Series routers only) (Optional) For input policers, you can configure a fixed classifier. A fixed classifier reclassifies all incoming packets, regardless of any preexisting classification.
[edit] user@host# set class-of-service interfaces ge-2/0/5 forwarding-class af
The classifier name can be a configured classifier or one of the default classifiers. Results Confirm the configuration of the interface by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces ge-2/0/5 { unit 0 { family inet {
412
address 10.10.10.1/30; filter { input filter-trtcm1ca-all; } } } }
Verification
Displaying the Firewall Filters Applied to the Logical Interface on page 413
Displaying the Firewall Filters Applied to the Logical Interface Purpose Action Verify that the firewall filter is applied to IPv4 input traffic at the logical interface. Use the show interfaces operational mode command for the logical interface ge-2/0/5.0, and specify detail mode. The Protocol inet section of the command output displays IPv4 information for the logical interface. Within that section, the Input Filters field displays the name of IPv4 firewall filters associated with the logical interface.
user@host> show interfaces ge-2/0/5.0 detail Logical interface ge-2/0/5.0 (Index 105) (SNMP ifIndex 556) (Generation 170) Flags: Device-Down SNMP-Traps 0x4004000 Encapsulation: ENET2 Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 0 bps Output bytes : 0 0 bps Input packets: 0 0 pps Output packets: 0 0 pps Protocol inet, MTU: 1500, Generation: 242, Route table: 0 Flags: Sendbcast-pkt-to-re Input Filters: filter-trtcm1ca-all Addresses, Flags: Dest-route-down Is-Preferred Is-Primary Destination: 10.20.130/24, Local: 10.20.130.1, Broadcast: 10.20.130.255, Generation: 171 Protocol multiservice, MTU: Unlimited, Generation: 243, Route table: 0 Policer: Input: __default_arp_policer__
Statement Hierarchy for Configuring Policers on page 305 Three-Color Policer Configuration Overview on page 311 Three-Color Policer Configuration Guidelines on page 399
413
414
CHAPTER 13
Logical and Physical Interface Policer Configuration

This chapter covers two-color and three-color policers configured as logical and physical interface policers and applied to Layer 2 or Layer 3 traffic.

Two-Color and Three-Color Logical Interface Policers on page 415 Two-Color and Three-Color Physical Interface Policers on page 427
Two-Color and Three-Color Logical Interface Policers

Logical Interface (Aggregate) Policer Overview on page 415 Example: Configuring a Two-Color Logical Interface (Aggregate) Policer on page 416 Example: Configuring a Three-Color Logical Interface (Aggregate) Policer on page 421
Logical Interface (Aggregate) Policer Overview

A logical interface policeralso called an aggregate policeris a two-color or three-color policer that defines traffic rate limiting that you can apply to input or output traffic for multiple protocol families on the same logical interface without creating multiple instances of the policer. To configure a single-rate two-color logical interface policer, include the logical-interface-policer statement at one of the following hierarchy levels:

[edit firewall policer policer-name] [edit logical-systems logical-system-name firewall policer policer-name]
To configure a single-rate or two-rate three-color logical interface policer, include the logical-interface-policer statement at one of the following hierarchy levels:

[edit firewall three-color-policer name] [edit logical-systems logical-system-name firewall three-color-policer name]
415
NOTE: A three-color policer can be applied to Layer 2 traffic as a logical interface policer only. You cannot apply a three-color policer to Layer 2 traffic as a physical interface policer (through a firewall filter).
You apply a logical interface policer to Layer 3 traffic directly to the interface configuration at the logical unit level (to rate-limit all traffic types, regardless of the protocol family) or at the protocol family level (to rate-limit traffic of a specific protocol family). You cannot reference a logical interface policer from a stateless firewall filter term and then apply the filter to a logical interface. You can apply a logical interface policer to unicast traffic only. For information about configuring a stateless firewall filter for flooded traffic, see Applying Filters to Forwarding Tables in the Traffic Sampling, Forwarding, and Monitoring section of the Junos OS Routing Policy Configuration Guide. To display a logical interface policer on a particular interface, issue the show interfaces policers operational mode command.
Example: Configuring a Two-Color Logical Interface (Aggregate) Policer

This example shows how to configure a single-rate two-color policer as a logical interface policer and apply it to incoming IPv4 traffic on a logical interface.

Requirements
Before you begin, make sure that the logical interface to which you apply the two-color logical interface policer is hosted on a Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-).
Overview
In this example, you configure the single-rate two-color policer policer_IFL as a logical interface policer and apply it to incoming IPv4 traffic at logical interface ge-1/3/1.0. Topology If the input IPv4 traffic on the physical interface ge-1/3/1 exceeds the bandwidth limit equal to 90 percent of the media rate with a 300 KB burst-size limit, then the logical interface policer policer_IFL rate-limits the input IPv4 traffic on the logical interface ge-1/3/1.0. Configure the policer to mark nonconforming traffic by setting packet loss priority (PLP) levels to high and classifying packets as best-effort. As the incoming IPv4 traffic rate on the physical interface slows and conforms to the configured limits, Junos OS stops marking the incoming IPv4 packets at the logical interface.
416
Chapter 13: Logical and Physical Interface Policer Configuration
Configuration

Configuring the Logical Interfaces on page 417 Configuring the Single-Rate Two-Color Policer as a Logical Interface Policer on page 418 Applying the Logical Interface Policer to Input IPv4 Traffic at a Logical Interface on page 420
set interfaces ge-1/3/1 vlan-tagging set interfaces ge-1/3/1 unit 0 vlan-id 100 set interfaces ge-1/3/1 unit 0 family inet address 10.10.10.1/30 set interfaces ge-1/3/1 unit 1 vlan-id 101 set interfaces ge-1/3/1 unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44 set firewall policer policer_IFL logical-interface-policer set firewall policer policer_IFL if-exceeding bandwidth-percent 90 set firewall policer policer_IFL if-exceeding burst-size-limit 300k set firewall policer policer_IFL then loss-priority high set firewall policer policer_IFL then forwarding-class best-effort set interfaces ge-1/3/1 unit 0 family inet policer input policer_IFL
1.

2.
Configure single tagging.

[edit interfaces ge-1/3/1] user@host# set vlan-tagging
3.

4.

417
Results
Confirm the configuration of the logical interfaces by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces ge-1/3/1 { vlan-tagging; unit 0 { vlan-id 100; family inet { address 10.10.10.1/30; } } unit 1 { vlan-id 101; family inet { address 20.20.20.1/30 { arp 20.20.20.2 mac 00:00:11:22:33:44; } } } }
Configuring the Single-Rate Two-Color Policer as a Logical Interface Policer Step-by-Step Procedure To configure a single-rate two-color policer as a logical interface policer:
1.

[edit] user@host# edit firewall policer policer_IFL
2.
Specify that the policer is a logical interface (aggregate) policer.

[edit firewall policer policer_IFL] user@host# set logical-interface-policer
A logical interface policer rate-limits traffic based on a percentage of the media rate of the physical interface underlying the logical interface to which the policer is applied. The policer is applied directly to the interface rather than referenced by a firewall filter.
3.
Specify the policer traffic limits. a. Specify the bandwidth limit.
To specify the bandwidth limit as an absolute rate, from 8,000 bits per second through 50,000,000,000 bits per second, include the bandwidth-limit bps statement. To specify the bandwidth limit as a percentage of the physical port speed on the interface, include the bandwidth-percent percent statement.
418
In this example, the CLI commands and output are based on a bandwidth limit specified as a percentage rather than as an absolute rate.
[edit firewall policer policer_IFL] user@host# set if-exceeding bandwidth-percent 90
b. Specify the burst-size limit, from 1,500 bytes through 100,000,000,000 bytes, which is the maximum packet size to be permitted for bursts of data that exceed the specified bandwidth limit.
[edit firewall policer policer_IFL] user@host# set if-exceeding burst-size-limit 300k
4.
Specify the policer actions to be taken on traffic that exceeds the configured rate limits.

To discard the packet, include the discard statement. To set the loss-priority value of the packet, include the loss-priority (low | medium-low | medium-high | high) statement. To classify the packet to a forwarding class, include the
forwarding-class (forwarding-class | assured-forwarding | best-effort | expedited-forwarding | network-control) statement.
In this example, the CLI commands and output are based on both setting the packet loss priority level and classifying the packet.
[edit firewall policer policer_IFL] user@host# set then loss-priority high user@host# set then forwarding-class best-effort
Results
[edit] user@host# show firewall policer policer_IFL { logical-interface-policer; if-exceeding { bandwidth-percent 90; burst-size-limit 300k; } then { loss-priority high; forwarding-class best-effort; } }
419
Applying the Logical Interface Policer to Input IPv4 Traffic at a Logical Interface Step-by-Step Procedure To apply the two-color logical interface policer to input IPv4 traffic a logical interface:
1.

[edit] user@host# edit interfaces ge-1/3/1 unit 0
2.
Apply the policer to all traffic types or to a specific traffic type on the logical interface.
To apply the policer to all traffic types, regardless of the protocol family, include the policer (input | output) policer-name statement at the [edit interfaces interface-name unit number] hierarchy level. To apply the policer to traffic of a specific protocol family, include the policer (input | output) policer-name statement at the [edit interfaces interface-name unit unit-number family family-name] hierarchy level.
To apply the logical interface policer to incoming packets, use the policer input policer-name statement. To apply the logical interface policer to outgoing packets, use the policer output policer-name statement. In this example, the CLI commands and output are based on rate-limiting the IPv4 input traffic at logical interface ge-1/3/1.0.
[edit interfaces ge-1/3/1 unit 0] user@host# set family inet policer input policer_IFL
Results
[edit] user@host# show interfaces ge-1/3/1 { vlan-tagging; unit 0 { vlan-id 100; family inet { policer input policer_IFL; address 10.10.10.1/30; } } unit 1 { vlan-id 101; family inet { address 20.20.20.1/30 { arp 20.20.20.2 mac 00:00:11:22:33:44; } } } }
420
Verification

Displaying Traffic Statistics and Policers for the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface. Use the show interfaces operational mode command for logical interface ge-1/3/1.0, and include the detail or extensive option. The command output section for Traffic statistics lists the number of bytes and packets received and transmitted on the logical interface. The Protocol inet subsection contains a Policer field that would list the policer policer_IFL as an input or output logical interface policer as follows:

Action
Input: policer_IFL-ge-1/3/1.0-log_int-i Output: policer_IFL-ge-1/3/1.0-log_int-o
The log_int-i suffix denotes a logical interface policer applied to input traffic, while the log_int-o suffix denotes a logical interface policer applied to output traffic. In this example, the logical interface policer is applied to input traffic only. Displaying Statistics for the Policer Purpose Action Verify the number of packets evaluated by the policer. Use the show policer operational mode command and optionally specify the name of the policer. The command output displays the number of packets evaluated by each configured policer (or the specified policer), in each direction. For the policer policer_IFL, the input and output policer names are displayed as follows:

policer_IFL-ge-1/3/1.0-log_int-i policer_IFL-ge-1/3/1.0-log_int-o
Example: Configuring a Three-Color Logical Interface (Aggregate) Policer

This example shows how to configure a two-rate three-color color-blind policer as a logical interface (aggregate) policer and apply the policer directly to Layer 2 input traffic at a supported logical interface.

421
Requirements
Before you begin, make sure that the logical interface to which you apply the three-color logical interface policer is hosted on a Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-) on an MX Series router.
Overview
A two-rate three-color policer meters a traffic flow against a bandwidth limit and burst-size limit for guaranteed traffic, plus a second set of bandwidth and burst-size limits for peak traffic. Traffic that conforms to the limits for guaranteed traffic is categorized as green, and nonconforming traffic falls into one of two categories:
Nonconforming traffic that does not exceed the bandwidth and burst-size limits for peak traffic is categorized as yellow. Nonconforming traffic that exceeds the bandwidth and burst-size limits for peak traffic is categorized as red.
A logical interface policer defines traffic rate-limiting rules that you can apply to multiple protocol families on the same logical interface without creating multiple instances of the policer.
NOTE: You apply a logical interface policer directly to a logical interface at the logical unit level, and not by referencing the policer in a stateless firewall filter and then applying the filter to the logical interface at the protocol family level.
Topology In this example, you configure the two-rate three-color policer trTCM2-cb as a color-blind logical interface policer and apply the policer to incoming Layer 2 traffic on logical interface ge-1/3/1.0.
NOTE: When using a three-color policer to rate-limit Layer 2 traffic, color-aware policing can be applied to egress traffic only.
The policer defines guaranteed traffic rate limits such that traffic that conforms to the bandwidth limit of 40 Mbps with a 100 KB allowance for traffic bursting (based on the token-bucket formula) is categorized as green. As with any policed traffic, the packets in a green flow are implicitly set to a low loss priority and then transmitted. Nonconforming traffic that falls within the peak traffic limits of a 60 Mbps bandwidth limit and a 200 KB allowance for traffic bursting (based on the token-bucket formula) is categorized as yellow. The packets in a yellow traffic flow are implicitly set to a medium-high loss priority and then transmitted.
422
Nonconforming traffic that exceeds the peak traffic limits are categorized as red. The packets in a red traffic flow are implicitly set to a high loss priority. In this example, the optional policer action for red traffic (loss-priority high then discard) is configured, so packets in a red traffic flow are discarded instead of transmitted.
Configuration

Configuring the Logical Interfaces on page 423 Configuring the Two-Rate Three-Color Policer as a Logical Interface Policer on page 424 Applying the Three-Color Policer to the Layer 2 Input at the Logical Interface on page 425
set interfaces ge-1/3/1 vlan-tagging set interfaces ge-1/3/1 unit 0 vlan-id 100 set interfaces ge-1/3/1 unit 0 family inet address 10.10.10.1/30 set interfaces ge-1/3/1 unit 1 vlan-id 101 set interfaces ge-1/3/1 unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44 set firewall three-color-policer trTCM2-cb logical-interface-policer set firewall three-color-policer trTCM2-cb two-rate color-blind set firewall three-color-policer trTCM2-cb two-rate committed-information-rate 40m set firewall three-color-policer trTCM2-cb two-rate committed-burst-size 100k set firewall three-color-policer trTCM2-cb two-rate peak-information-rate 60m set firewall three-color-policer trTCM2-cb two-rate peak-burst-size 200k set firewall three-color-policer trTCM2-cb action loss-priority high then discard set interfaces ge-1/3/1 unit 0 layer2-policer input-three-color trTCM2-cb
1.

2.

3.

423
4.

Results
Configuring the Two-Rate Three-Color Policer as a Logical Interface Policer Step-by-Step Procedure To configure the two-rate three-color policer as a logical interface policer:
1.

[edit] user@host# edit firewall three-color-policer trTCM2-cb
2.

[edit firewall three-color-policer trTCM2-cb] user@host# set logical-interface-policer
A logical interface policer rate-limits traffic based on a percentage of the media rate of the physical interface underlying the logical interface to which the policer is applied, and the policer is applied directly to the interface rather than referenced by a firewall filter.
3.
Specify that the policer is two-rate and color-blind.

[edit firewall three-color-policer trTCM2-cb] user@host# set two-rate color-blind
A color-aware three-color policer takes into account any coloring markings that might have been set for a packet by another traffic policer configured at a previous
424
network node, and any preexisting color markings are used in determining the appropriate policing action for the packet. Because you are applying this three-color policer applied to input at Layer 2, you must configure the policer to be color-blind.
4.
Specify the policer traffic limits used to classify a green traffic flow.
[edit firewall three-color-policer trTCM2-cb] user@host# set two-rate committed-information-rate 40m user@host# set two-rate committed-burst-size 100k
5.
Specify the additional policer traffic limits used to classify a yellow or red traffic flow.
[edit firewall three-color-policer trTCM2-cb] user@host# set two-rate peak-information-rate 60m user@host# set two-rate peak-burst-size 200k
6.
(Optional) Specify the configured policer action for packets in a red traffic flow.
[edit firewall three-color-policer trTCM2-cb] user@host# set action loss-priority high then discard
In color-aware mode, the three-color policer configured action can increase the packet loss priority (PLP) level of a packet, but never decrease it. For example, if a color-aware three-color policer meters a packet with a medium PLP marking, it can raise the PLP level to high, but cannot reduce the PLP level to low. Results Confirm the configuration of the three-color policer by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall three-color-policer trTCM2-cb { logical-interface-policer; action { loss-priority high then discard; } two-rate { color-blind; committed-information-rate 40m; committed-burst-size 100k; peak-information-rate 60m; peak-burst-size 200k; } }
Applying the Three-Color Policer to the Layer 2 Input at the Logical Interface Step-by-Step Procedure To apply the three-color policer to the Layer 2 input at the logical interface:
1.
Enable application of Layer 2 logical interface policers.

425
2.
Apply the three-color logical interface policer to a logical interface input.

[edit interfaces ge-1/3/1 unit 0] user@host# set layer2-policer input-three-color trTCM2-cb
Results
[edit] user@host# show interfaces ge-1/3/1 { vlan-tagging; unit 0 { vlan-id 100; layer2-policer { input-three-color trTCM2-cb; } family inet { address 10.10.10.1/30; } } unit 1 { vlan-id 101; family inet { address 20.20.20.1/30 { arp 20.20.20.2 mac 00:00:11:22:33:44; } } } }
Verification

Displaying Traffic Statistics and Policers for the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface. Use the show interfaces operational mode command for logical interface ge-1/3/1.0, and include the detail or extensive option. The command output section for Traffic statistics lists the number of bytes and packets received and transmitted on the logical interface, and the Protocol inet section contains a Policer field that would list the policer trTCM2-cb as an input or output policer as follows:
Action
Input: trTCM2-cb-ge-1/3/1.0-log_int-i
426
Output: trTCM2-cb-ge-1/3/1.0-log_int-o
The log_int-i suffix denotes a logical interface policer applied to input traffic, while the log_int-o suffix denotes a logical interface policer applied to output traffic. In this example, the logical interface policer is applied to in the input direction only. Displaying Statistics for the Policer Purpose Action Verify the number of packets evaluated by the policer. Use the show policer operational mode command and optionally specify the name of the policer. The command output displays the number of packets evaluated by each configured policer (or the specified policer), in each direction. For the policer trTCM2-cb, the input and output policer names are displayed as follows:

trTCM2-cb-ge-1/3/1.0-log_int-i trTCM2-cb-e-1/3/1.0-log_int-o
Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Three-Color Policer Configuration Overview on page 311 Guidelines for Applying Traffic Policers on page 316
Two-Color and Three-Color Physical Interface Policers

Physical Interface Policer Overview on page 427 Example: Configuring a Physical Interface Policer for Aggregate Traffic at a Physical Interface on page 429
Physical Interface Policer Overview

A physical interface policer is a two-color or three-color policer that defines traffic rate limiting that you can apply to input or output traffic for all the logical interfaces and protocol families configured on a physical interface, even if the logical interfaces belong to different routing instances. This feature is useful when you want to perform aggregate policing for different protocol families and different logical interfaces on the same physical interface. For example, suppose that a provider edge (PE) router has numerous logical interfaces, each corresponding to a different customer, configured on the same link to a customer edge (CE) device. Now suppose that a customer wants to apply one set of rate limits aggregately for certain types of traffic on a single physical interface. To accomplish this, you could apply a single physical interface policer to the physical interface, which
427
rate-limits all the logical interfaces configured on the interface and all the routing instances to which those interfaces belong. To configure a single-rate two-color physical interface policer, include the physical-interface-policer statement at one of the following hierarchy levels:

[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]
To configure a single-rate or two-rate three-color physical interface policer, include the physical-interface-policer statement at one of the following hierarchy levels:

[edit firewall three-color-policer policer-name] [edit logical-system logical-system-name firewall three-color-policer policer-name] [edit routing-instances routing-instance-name firewall three-color-policer policer-name] [edit logical-systems logical-system-name routing-instances routing-instance-name firewall three-color-policer policer-name]
You apply a physical interface policer to Layer 3 traffic by referencing the policer from a stateless firewall filter term and then applying the filter to a logical interface. You cannot apply a physical interface to Layer 3 traffic directly to the interface configuration. To reference a single-rate two-color policer from a stateless firewall filter term, use the policer nonterminating action. To reference a single-rate or two-rate three-color policer from a stateless firewall filter term, use the three-color-policer nonterminating action. The following requirements apply to a stateless firewall filter that references a physical interface policer:
You must configure the firewall filter for a specific, supported protocol family: ipv4, ipv6, mpls, vpls, or circuit cross-connect (ccc), but not for family any. You must configure the firewall filter as a physical interface filter by including the physical-interface-filter statement at the [edit firewall family family-name filter filter-name] hierarchy level. A firewall filter that is defined as a physical interface filter can reference a physical interface policer only. A firewall filter that is defined as a physical interface filter cannot reference a policer configured with the interface-specific statement. You cannot configure a firewall filter as both a physical interface filter and as a logical interface filter that also includes the interface-specific statement.
428
Example: Configuring a Physical Interface Policer for Aggregate Traffic at a Physical Interface
This example shows how to configure a single-rate two-color policer as a physical interface policer.

Requirements
Overview
A physical interface policer specifies rate-limiting for aggregate traffic, which encompasses all protocol families and logical interfaces configured on a physical interface, even if the interfaces belong to different routing instances. You can apply a physical interface policer to Layer 3 input or output traffic only by referencing the policer from a stateless firewall filter that is configured for specific a specific protocol family (not for family any) and configured as a physical interface filter. You configure the filter terms with match conditions that select the types of packets you want to rate-limit, and you specify the physical interface policer as the action to apply to matched packets. Topology The physical interface policer in this example, shared-policer-A, rate-limits to 100,000,000 bps and permits a maximum burst of traffic of 500,000 bytes. You configure the policer to discard packets in nonconforming flows, but you could instead configure the policer to re-mark nonconforming traffic with a forwarding class, a packet loss priority (PLP) level, or both. To be able to use the policer to rate-limit IPv4 traffic, you reference the policer from an IPv4 physical interface filter. For this example, you configure the filter to pass the policer IPv4 packets that meet either of the following match terms:
Packets received through TCP and with the IP precedence fields critical-ecp (0xa0), immediate (0x40), or priority (0x20) Packets received through TCP and with the IP precedence fields internet-control (0xc0) or routine (0x00)
You could also reference the policer from physical interface filters for other protocol families.
429
Configuration

Configuring the Logical Interfaces on the Physical Interface on page 430 Configuring a Physical Interface Policer on page 431 Configuring an IPv4 Physical Interface Filter on page 432 Applying the IPv4 Physical interface Filter to a Physical Interface on page 433
set interfaces so-1/0/0 unit 0 family inet address 192.168.1.1/24 set interfaces so-1/0/0 unit 0 family vpls set interfaces so-1/0/0 unit 1 family mpls set firewall policer shared-policer-A physical-interface-policer set firewall policer shared-policer-A if-exceeding bandwidth-limit 100m burst-size-limit 500k set firewall policer shared-policer-A then discard set firewall family inet filter ipv4-filter physical-interface-filter set firewall family inet filter ipv4-filter term tcp-police-1 from precedence [ critical-ecp immediate priority ] set firewall family inet filter ipv4-filter term tcp-police-1 from protocol tcp set firewall family inet filter ipv4-filter term tcp-police-1 then policer shared-policer-A set firewall family inet filter ipv4-filter term tcp-police-2 from precedence [ internet-control routine ] set firewall family inet filter ipv4-filter term tcp-police-2 from protocol tcp set firewall family inet filter ipv4-filter term tcp-police-2 then policer shared-policer-A set interfaces so-1/0/0 unit 0 family inet filter input ipv4-filter
Configuring the Logical Interfaces on the Physical Interface Step-by-Step Procedure To configure the logical interfaces on the physical interface:
1.
Enable configuration of logical interfaces.

[edit] user@host# edit interfaces so-1/0/0
2.
Configure protocol families on logical unit 0.

[edit interfaces so-1/0/0] user@host# set unit 0 family inet address 192.168.1.1/24 user@host# set unit 0 family vpls
3.
Configure protocol families on logical unit 1.

[edit interfaces so-1/0/0] user@host# set unit 1 family mpls
430
Results
Confirm the configuration of the firewall filter by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces so-1/0/0 { unit 0 { family inet { address 192.168.1.1/24; } family vpls; } unit 1 { family mpls; } }
Configuring a Physical Interface Policer Step-by-Step Procedure To configure a physical interface policer:
1.
Enable configuration of the two-color policer.

[edit] user@host# edit firewall policer shared-policer-A
2.
Configure the type of two-color policer.

[edit firewall policer shared-policer-A] user@host# set physical-interface-policer
3.
Configure the traffic limits and the action for packets in a nonconforming traffic flow.
[edit firewall policer shared-policer-A] user@host# set if-exceeding bandwidth-limit 100m burst-size-limit 500k user@host# set then discard
For a physical interface filter, the actions you can configure for packets in a nonconforming traffic flow are to discard the packets, assign a forwarding class, assign a PLP value, or assign both a forwarding class and a PLP value. Results Confirm the configuration of the policer by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall policer shared-policer-A { physical-interface-policer; if-exceeding { bandwidth-limit 100m; burst-size-limit 500k; } then discard; }
431
Configuring an IPv4 Physical Interface Filter Step-by-Step Procedure To configure a physical interface policer as the action for terms in an IPv4 physical interface policer:
1.
Configure a standard stateless firewall filter under a specific protocol family.

[edit] user@host# edit firewall family inet filter ipv4-filter
You cannot configure a physical interface firewall filter for family any.
2.
Configure the filter as a physical interface filter so that you can apply the physical interface policer as an action.
[edit firewall family inet filter ipv4-filter] user@host# set physical-interface-filter
3.
Configure the first term to match IPv4 packets received through TCP with the IP precedence fields critical-ecp, immediate, or priority and to apply the physical interface policer as a filter action.
[edit firewall family inet filter ipv4-filter] user@host# set term tcp-police-1 from precedence [ critical-ecp immediate priority ] user@host# set term tcp-police-1 from protocol tcp user@host# set term tcp-police-1 then policer shared-policer-A
4.
Configure the first term to match IPv4 packets received through TCP with the IP precedence fields internet-control or routine and to apply the physical interface policer as a filter action.
[edit firewall family inet filter ipv4-filter] user@host# set term tcp-police-2 from precedence [ internet-control routine ] user@host# set term tcp-police-2 from protocol tcp user@host# set term tcp-police-2 then policer shared-policer-A
Results
[edit] user@host# show firewall family inet { filter ipv4-filter { physical-interface-filter; term tcp-police-1 { from { precedence [ critical-ecp immediate priority ]; protocol tcp; } then policer shared-policer-A; } term tcp-police-2 { from { precedence [ internet-control routine ]; protocol tcp;
432
} then policer shared-policer-A; } } } policer shared-policer-A { physical-interface-policer; if-exceeding { bandwidth-limit 100m; burst-size-limit 500k; } then discard; }
Applying the IPv4 Physical interface Filter to a Physical Interface Step-by-Step Procedure To apply the physical interface filter to a physical interface:
1.

2.
Apply the IPv4 physical interface filter in the input direction.

[edit interfaces so-1/0/0 unit 0 family inet] user@host# set filter input ipv4-filter
Results
Confirm the configuration of the firewall filter by entering the show interfaces configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces so-1/0/0 { unit 0 { family inet { filter { input ipv4-filter; } address 192.168.1.1/24; } family vpls; } unit 1 { family mpls; } }
433
Verification

Displaying the Firewall Filters Applied to an Interface on page 434 Displaying the Number of Packets Processed by the Policer at the Logical Interface on page 434
Displaying the Firewall Filters Applied to an Interface Purpose Verify that the firewall filter ipv4-filter is applied to the IPv4 input traffic at logical interface so-1/0/0.0. Use the show interfaces statistics operational mode command for logical interface so-1/0/0.0, and include the detail option. In the Protocol inet section of the command output, the Input Filters field shows that the firewall filter ipv4-filter is applied in the input direction.
user@host> show interfaces statistics so-1/0/0 detail Logical interface so-1/0/0.0 (Index 79) (SNMP ifIndex 510) (Generation 149) Flags: Hardware-Down Point-To-Point SNMP-Traps 0x4000 Encapsulation: PPP Protocol inet, MTU: 4470, Generation: 173, Route table: 0 Flags: Sendbcast-pkt-to-re, Protocol-Down Input Filters: ipv4-filter Addresses, Flags: Dest-route-down Is-Preferred Is-Primary Destination: 10.39/16, Local: 10.39.1.1, Broadcast: 10.39.255.255, Generation: 163
Action
Displaying the Number of Packets Processed by the Policer at the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface. Use the show firewall operational mode command for the filter you applied to the logical interface.
user@host> show firewall filter ipv4-filter Filter: ipv4-filter Policers: Name shared-policer-A-tcp-police-1 shared-policer-A-tcp-police-2
Action
Packets 32863 3870
The command output displays the name of policer (shared-policer-A), the name of the filter term (police-1) under which the policer action is specified, and the number of packets that matched the filter term. This is only the number of out-of-specification (out-of-spec) packet counts, not all packets policed by the policer.
Firewall Filter Match Conditions Based on Numbers or Text Aliases on page 31 in the
Junos OS Firewall Filter and Policer Configuration Guide
Firewall Filter Match Conditions Based on Bit-Field Values on page 32 in the Junos
OS Firewall Filter and Policer Configuration Guide
434
Firewall Filter Match Conditions Based on Address Fields on page 37 in the Junos OS
Firewall Filter and Policer Configuration Guide
Firewall Filter Match Conditions Based on Address Classes on page 45 in the Junos
OS Firewall Filter and Policer Configuration Guide
Statement Hierarchy for Configuring Policers on page 305 Two-Color Policer Configuration Overview on page 307 Three-Color Policer Configuration Overview on page 311 Guidelines for Applying Traffic Policers on page 316 physical-interface-filter on page 491 physical-interface-policer on page 492
435
436
CHAPTER 14
Layer 2 Policer Configuration

This chapter covers traffic policing applied to Layer 2 traffic.

Hierarchical Policers on page 437 Two-Color and Three-Color Policers at Layer 2 on page 444
Hierarchical Policers

Hierarchical Policer Overview on page 437 Example: Configuring a Hierarchical Policer on page 439
Hierarchical Policer Overview

You can use a hierarchical policer to rate-limit ingress Layer 2 traffic at a physical or logical interface and apply different policing actions based on whether the packets are classified for expedited forwarding (EF) or for a lower priority. Hierarchical policing is supported on SONET interfaces hosted on M40e, M120, and M320 edge routers with incoming Flexible PIC Concentrators (FPCs) as SFPC and outgoing FPCs as FFPC, and on MX Series, T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs. You can apply hierarchical policing to a physical interface or a logical interface. Applied to a physical interface configuration, a hierarchical policer rate-limits ingress Layer 2 traffic for all protocol families and logical interfaces configured on the physical interface. Applied to a logical interface configured with at least one protocol family, a hierarchical policer rate-limits ingress Layer 2 traffic for all protocol families configured on the logical interface. If you apply a hierarchical policer at a physical interface, you cannot also apply a hierarchical policer to any of the member logical interfaces. A hierarchical policer configuration defines two policersone for EF traffic only and another for non-EF trafficthat function in a hierarchical manner:
Premium policerYou configure the premium policer with traffic limits for high-priority EF traffic only: a guaranteed bandwidth and a corresponding burst-size limit. EF traffic is categorized as nonconforming when its average arrival rate exceeds the guaranteed bandwidth and its average packet size exceeds the premium burst-size limit. For a premium policer, the only configurable action for nonconforming traffic is to discard the packets.
437
Aggregate policerYou configure the aggregate policer with an aggregate bandwidth (to accommodate both high-priority EF traffic up to the guaranteed bandwidth and normal-priority non-EF traffic) and a burst-size limit for non-EF traffic only. Non-EF traffic is categorized as nonconforming when its average arrival rate exceeds the amount of aggregate bandwidth not currently consumed by EF traffic and its average packet size exceeds the burst-size limit defined in the aggregate policer. For an aggregate policer, the configurable actions for nonconforming traffic are to discard the packets, assign a forwarding class, assign a packet loss priority (PLP) level, or assign both a forwarding class and a PLP level to the packets.
NOTE: You must configure the bandwidth limit of the premium policer at or below the bandwidth limit of the aggregate policer. If the two bandwidth limits are equal, then non-EF traffic passes through the interface unrestricted only while no EF traffic arrives at the interface.
EF traffic is guaranteed the bandwidth specified as the premium bandwidth limit, while non-EF traffic is rate-limited to the amount of aggregate bandwidth not currently consumed by the EF traffic. Non-EF traffic is rate-limited to the entire aggregate bandwidth only while no EF traffic is present. For example, suppose that you configure a hierarchical policer with the following components:
Premium policer with bandwidth limit set to 2 Mbps, burst-size limit set to 3000 bytes, and nonconforming action set to discard packets. Aggregate policer with bandwidth limit set to 10 Mbps, burst-size limit set to 3000 bytes, and nonconforming action set to discard packets.
EF traffic is guaranteed a bandwidth of 2 Mbps. Bursts of EF trafficEF traffic that arrives at the interface at rates above 2 Mbpscan also pass through the interface provided sufficient tokens are available in the 3000-byte bucket. When no tokens are available for a burst of non-EF traffic, packets are rate-limited using policing actions for the premium policer. Non-EF traffic is metered to a bandwidth limit that ranges between 8 Mbps and 10 Mbps, depending on the average arrival rate of the EF traffic. Bursts of non-EF trafficnon-EF traffic that arrives at the interface at rates above the current limit for non-EF trafficalso pass through the interface provided sufficient tokens are available in the 3000-byte bucket. When non-EF traffic exceeds the currently allowed bandwidth or when no tokens are available for a burst of non-EF traffic, packets are rate-limited using policing actions for the aggregate policer.
438
Chapter 14: Layer 2 Policer Configuration
Example: Configuring a Hierarchical Policer

This example shows how to configure a hierarchical policer and apply the policer to ingress Layer 2 traffic at a logical interface on a supported platform.

Requirements
Before you begin, be sure that your environment meets the following requirements:
The interface on which you apply the hierarchical policer is a SONET interface hosted on one of the following routing platforms:
M40e, M120, or M320 edge router with incoming FPCs as SFPC and outgoing FPCs as FFPC. MX Series, T320, T640, or T1600 core router with Enhanced Intelligent Queuing (IQE) PICs.
No other policer is applied to the input of the interface on which you apply the hierarchical policer. You are aware that, if you apply the hierarchical policer to logical interface on which an input filter is also applied, the policer is executed first.
Overview
In this example, you configure a hierarchical policer and apply the policer to ingress Layer 2 traffic at a logical interface. Topology You apply the policer to the SONET logical interface so-1/0/0.0, which you configure for IPv4 and VPLS traffic. When you apply the hierarchical policer to that logical interface, both IPv4 and VPLS traffic is hierarchically rate-limited. You also configure the logical interface so-1/0/0.1 for MPLS traffic. If you choose to apply the hierarchical policer to physical interface so-1/0/0, hierarchical policing would apply to IPv4 and VPLS traffic at so-1/0/0.0 and to MPLS traffic at so-1/0/0.1.
Configuration
439

Defining the Interfaces on page 440 Defining the Forwarding Classes on page 441 Configuring the Hierarchical Policer on page 441 Applying the Hierarchical Policer to Layer 2 Ingress Traffic at a Physical or Logical Interface on page 442
set interfaces so-1/0/0 unit 0 family inet address 192.168.1.1/24 set interfaces so-1/0/0 unit 0 family vpls set interfaces so-1/0/0 unit 1 family mpls set class-of-service forwarding-classes class fc0 queue-num 0 priority high policing-priority premium set class-of-service forwarding-classes class fc1 queue-num 1 priority low policing-priority normal set class-of-service forwarding-classes class fc2 queue-num 2 priority low policing-priority normal set class-of-service forwarding-classes class fc3 queue-num 3 priority low policing-priority normal set firewall hierarchical-policer policer1 aggregate if-exceeding bandwidth-limit 300m burst-size-limit 30k set firewall hierarchical-policer policer1 aggregate then forwarding-class fc1 set firewall hierarchical-policer policer1 premium if-exceeding bandwidth-limit 100m burst-size-limit 50k set firewall hierarchical-policer policer1 premium then discard set interfaces so-1/0/0 unit 0 layer2-policer input-hierarchical-policer policer1
Defining the Interfaces Step-by-Step Procedure To define the interfaces:

1.
Enable configuration of the physical interface.

[edit] user@host# edit interfaces so-1/0/0
2.
Configure logical unit 0.

[edit interfaces so-1/0/0] user@host# set unit 0 family inet address 192.168.1.1/24 user@host# set unit 0 family vpls
If you apply a Layer 2 policer to this logical interface, you must configure at least one protocol family.
3.
Configure logical unit 1.

[edit interfaces so-1/0/0] user@host# set unit 1 family mpls
440
Results
Confirm the configuration of the interfaces by entering the show interfaces configuration command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces so-1/0/0 { unit 0 { family inet { address 192.168.1.1/24; } family vpls; } unit 1 { family mpls; } }
Defining the Forwarding Classes Step-by-Step Procedure To define the forwarding classes referenced as aggregate policer actions:
1.
Enable configuration of the forwarding classes.

[edit] user@host# edit class-of-service forwarding-classes
2.
Define the forwarding classes.

[edit class-of-service forwarding-classes] user@host# set class fc0 queue-num 0 priority high policing-priority premium user@host# set class fc1 queue-num 1 priority low policing-priority normal user@host# set class fc2 queue-num 2 priority low policing-priority normal user@host# set class fc3 queue-num 3 priority low policing-priority normal
Results
Confirm the configuration of the forwarding classes referenced as aggregate policer actions by entering the show class-of-service configuration command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show class-of-service forwarding-classes { class fc0 queue-num 0 priority high policing-priority premium; class fc1 queue-num 1 priority low policing-priority normal; class fc2 queue-num 2 priority low policing-priority normal; class fc3 queue-num 3 priority low policing-priority normal; }
Configuring the Hierarchical Policer Step-by-Step Procedure To configure a hierarchical policer:

1.
Enable configuration of the hierarchical policer.

[edit] user@host# edit firewall hierarchical-policer policer1
441
2.
Configure the aggregate policer.

[edit firewall hierarchical-policer policer1] user@host# set aggregate if-exceeding bandwidth-limit 300m burst-size-limit 30k user@host# set aggregate then forwarding-class fc1
For the aggregate policer, the configurable actions for a packet in a nonconforming flow are to discard the packet, change the loss priority, change the forwarding class, or change both the loss priority and the forwarding class.
3.
Configure the premium policer.

[edit firewall hierarchical-policer policer1] user@host# set premium if-exceeding bandwidth-limit 100m burst-size-limit 50k user@host# set premium then discard
The bandwidth limit for the premium policer must not be greater than that of the aggregate policer. For the premium policer, the only configurable action for a packet in a nonconforming traffic flow is to discard the packet. Results Confirm the configuration of the hierarchical policer by entering the show firewall configuration command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall hierarchical-policer policer1 { aggregate { if-exceeding { bandwidth-limit 300m; burst-size-limit 30k; } then { forwarding-class fc1; } } premium { if-exceeding { bandwidth-limit 100m; burst-size-limit 50k; } then { discard; } } }
Applying the Hierarchical Policer to Layer 2 Ingress Traffic at a Physical or Logical Interface Step-by-Step Procedure To hierarchically rate-limit Layer 2 ingress traffic for IPv4 and VPLS traffic only on logical interface so-1/0/0.0, reference the policer from the logical interface configuration:
1.

[edit]
442
user@host# edit interfaces so-1/0/0 unit 0
When you apply a policer to Layer 2 traffic at a logical interface, you must define at least one protocol family for the logical interface.
2.
Apply the policer to the logical interface.

[edit] user@host# set layer2-policer input-hierarchical-policer policer1
Alternatively, to hierarchically rate-limit Layer 2 ingress traffic for all protocol families and for all logical interfaces configured on physical interface so-1/0/0, you could reference the policer from the physical interface configuration. Results Confirm the configuration of the hierarchical policer by entering the show interfaces configuration command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show interfaces so-1/0/0 { unit 0 { layer2-policer { input-hierarchical-policer policer1; } family inet { address 192.168.1.1/24; } family vpls; } unit 1 { family mpls; } }
Verification

Displaying Traffic Statistics and Policers for the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface.
443
Action
Use the show interfaces operational mode command for logical interface so-1/0/0.0, and include the detail or extensive option. The command output section for Traffic statistics lists the number of bytes and packets received and transmitted on the logical interface, and the Protocol inet section contains a Policer field that would list the policer policer1 as an input or output policer as follows:

Input: policer1-so-1/0/0.0-inet-i Output: policer1-so-1/0/0.0-inet-o
In this example, the policer is applied to logical interface traffic in the input direction only. Displaying Statistics for the Policer Purpose Action Verify the number of packets evaluated by the policer. Use the show policer operational mode command and optionally specify the name of the policer. The command output displays the number of packets evaluated by each configured policer (or the specified policer), in each direction. For the policer policer1, the input and output policer names are displayed as follows:

policer1-so-1/0/0.0-inet-i policer1-so-1/0/0.0-inet-o
The -inet-i suffix denotes a policer applied to IPv4 input traffic, while the -inet-o suffix denotes a policer applied to IPv4 output traffic. In this example, the policer is applied to input traffic only.
Statement Hierarchy for Configuring Policers on page 305 Hierarchical Policer Configuration Overview on page 314 Guidelines for Applying Traffic Policers on page 316
Two-Color and Three-Color Policers at Layer 2

Two-Color Policing at Layer 2 Overview on page 444 Three-Color Policing at Layer 2 Overview on page 446 Example: Configuring a Three-Color Logical Interface (Aggregate) Policer on page 447
Two-Color Policing at Layer 2 Overview


Guidelines for Configuring Two-Color Policing of Layer 2 Traffic on page 445 Statement Hierarchy for Configuring a Two-Color Policer for Layer 2 Traffic on page 445 Statement Hierarchy for Applying a Two-Color Policer to Layer 2 Traffic on page 445
444
Guidelines for Configuring Two-Color Policing of Layer 2 Traffic

The following guidelines apply to two-color policing of Layer 2 traffic:
You can apply a two-color policer to ingress or egress Layer 2 traffic at a logical interface hosted on a Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-) only. A single logical interface supports Layer 2 policing in both directions. You can apply a two-color policer to Layer 2 traffic as a logical interface policer only. You cannot apply a two-color policer to Layer 2 traffic as a stateless firewall filter action. You can apply a two-color policer to Layer 2 traffic by referencing the policer in the interface configuration at the logical unit level, and not at the protocol level.
For information about configuring three-color policing of Layer 2 traffic, see Three-Color Policing at Layer 2 Overview on page 446.
Statement Hierarchy for Configuring a Two-Color Policer for Layer 2 Traffic

To enable a single-rate two-color policer to rate-limit Layer 2 traffic, include the logical-interface-policer statement in the policer configuration.
firewall { policer policer-name { logical-interface-policer; if-exceeding { (bandwidth-limit bps | bandwidth-percent percentage); burst-size-limit bytes; } then { discard; forwarding-class class-name; loss-priority (high | low | medium-high | medium-low); } } }
You can include the configuration at the following hierarchy levels:

Statement Hierarchy for Applying a Two-Color Policer to Layer 2 Traffic

To apply a logical interface policer to Layer 2 traffic, include the layer2-policer input-policer policer-name statement or the layer2-policer output-policer policer-name statement to a supported logical interface. Use the input-policer or output-policer statements to apply a two-color policer at Layer 2.
interfaces { (ge-fpc/pic/port | xe-fpc/pic/port) { unit unit-number {
445
layer2-policer { input-policer policer-name; output-policer policer-name; } } } }

Three-Color Policing at Layer 2 Overview


Guidelines for Configuring Three-Color Policing of Layer 2 Traffic on page 446 Statement Hierarchy for Configuring a Three-Color Policer for Layer 2 Traffic on page 446 Statement Hierarchy for Applying a Three-Color Policer to Layer 2 Traffic on page 447
Guidelines for Configuring Three-Color Policing of Layer 2 Traffic

The following guidelines apply to three-color policing of Layer 2 traffic:
You can apply a three-color policer to Layer 2 traffic at a logical interface hosted on a Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-) only. A single logical interface supports Layer 2 policing in both directions. You can apply a three-color policer to Layer 2 traffic as a logical interface policer only. You cannot apply a two-color policer to Layer 2 traffic as a stateless firewall filter action. You can apply a three-color policer to Layer 2 traffic by referencing the policer in the interface configuration at the logical unit level, and not at the protocol level. You can apply a color-aware three-color policer to Layer 2 traffic in the egress direction only, but you apply a color-blind three-color policer to Layer 2 traffic in either direction.
For information about configuring two-color policing of Layer 2 traffic, see Two-Color Policing at Layer 2 Overview on page 444.
Statement Hierarchy for Configuring a Three-Color Policer for Layer 2 Traffic

To enable a single-rate or two-rate three-color policer to rate-limit Layer 2 traffic, include the logical-interface-policer statement in the three-color-policer configuration.
firewall { three-color-policer policer-name { action { loss-priority high then discard; } logical-interface-policer; single-rate {
446
(color-aware | color-blind); committed-burst-size bytes; committed-information-rate bps; excess-burst-size bytes; } two-rate { (color-aware | color-blind); committed-burst-size bytes; committed-information-rate bps; peak-burst-size bytes; peak-information-rate bps; } } }

Statement Hierarchy for Applying a Three-Color Policer to Layer 2 Traffic

To apply a logical interface policer to Layer 2 traffic, include the layer2-policer statement for a supported logical interface at the logical unit level. Use the input-three-color policer-name statement or output-three-color policer-name statement to specify the direction of the traffic to be policed.
interfaces { (ge-fpc/pic/port | xe-fpc/pic/port) { unit unit-number { layer2-policer { input-three-color policer-name; output-three-color policer-name; } } } }

Example: Configuring a Three-Color Logical Interface (Aggregate) Policer

This example shows how to configure a two-rate three-color color-blind policer as a logical interface (aggregate) policer and apply the policer directly to Layer 2 input traffic at a supported logical interface.

447
Requirements
Before you begin, make sure that the logical interface to which you apply the three-color logical interface policer is hosted on a Gigabit Ethernet interface (ge-) or a 10-Gigabit Ethernet interface (xe-) on an MX Series router.
Overview
A two-rate three-color policer meters a traffic flow against a bandwidth limit and burst-size limit for guaranteed traffic, plus a second set of bandwidth and burst-size limits for peak traffic. Traffic that conforms to the limits for guaranteed traffic is categorized as green, and nonconforming traffic falls into one of two categories:
Nonconforming traffic that does not exceed the bandwidth and burst-size limits for peak traffic is categorized as yellow. Nonconforming traffic that exceeds the bandwidth and burst-size limits for peak traffic is categorized as red.
A logical interface policer defines traffic rate-limiting rules that you can apply to multiple protocol families on the same logical interface without creating multiple instances of the policer.
NOTE: You apply a logical interface policer directly to a logical interface at the logical unit level, and not by referencing the policer in a stateless firewall filter and then applying the filter to the logical interface at the protocol family level.
Topology In this example, you configure the two-rate three-color policer trTCM2-cb as a color-blind logical interface policer and apply the policer to incoming Layer 2 traffic on logical interface ge-1/3/1.0.
NOTE: When using a three-color policer to rate-limit Layer 2 traffic, color-aware policing can be applied to egress traffic only.
The policer defines guaranteed traffic rate limits such that traffic that conforms to the bandwidth limit of 40 Mbps with a 100 KB allowance for traffic bursting (based on the token-bucket formula) is categorized as green. As with any policed traffic, the packets in a green flow are implicitly set to a low loss priority and then transmitted. Nonconforming traffic that falls within the peak traffic limits of a 60 Mbps bandwidth limit and a 200 KB allowance for traffic bursting (based on the token-bucket formula) is categorized as yellow. The packets in a yellow traffic flow are implicitly set to a medium-high loss priority and then transmitted. Nonconforming traffic that exceeds the peak traffic limits are categorized as red. The packets in a red traffic flow are implicitly set to a high loss priority. In this example, the
448
optional policer action for red traffic (loss-priority high then discard) is configured, so packets in a red traffic flow are discarded instead of transmitted.
Configuration

Configuring the Logical Interfaces on page 449 Configuring the Two-Rate Three-Color Policer as a Logical Interface Policer on page 450 Applying the Three-Color Policer to the Layer 2 Input at the Logical Interface on page 451
set interfaces ge-1/3/1 vlan-tagging set interfaces ge-1/3/1 unit 0 vlan-id 100 set interfaces ge-1/3/1 unit 0 family inet address 10.10.10.1/30 set interfaces ge-1/3/1 unit 1 vlan-id 101 set interfaces ge-1/3/1 unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44 set firewall three-color-policer trTCM2-cb logical-interface-policer set firewall three-color-policer trTCM2-cb two-rate color-blind set firewall three-color-policer trTCM2-cb two-rate committed-information-rate 40m set firewall three-color-policer trTCM2-cb two-rate committed-burst-size 100k set firewall three-color-policer trTCM2-cb two-rate peak-information-rate 60m set firewall three-color-policer trTCM2-cb two-rate peak-burst-size 200k set firewall three-color-policer trTCM2-cb action loss-priority high then discard set interfaces ge-1/3/1 unit 0 layer2-policer input-three-color trTCM2-cb
1.

2.

3.

4.

[edit interfaces ge-1/3/1]
449
user@host# set unit 1 vlan-id 101 user@host# set unit 1 family inet address 20.20.20.1/30 arp 20.20.20.2 mac 00:00:11:22:33:44
Results
Configuring the Two-Rate Three-Color Policer as a Logical Interface Policer Step-by-Step Procedure To configure the two-rate three-color policer as a logical interface policer:
1.

[edit] user@host# edit firewall three-color-policer trTCM2-cb
2.

[edit firewall three-color-policer trTCM2-cb] user@host# set logical-interface-policer
A logical interface policer rate-limits traffic based on a percentage of the media rate of the physical interface underlying the logical interface to which the policer is applied, and the policer is applied directly to the interface rather than referenced by a firewall filter.
3.
Specify that the policer is two-rate and color-blind.

[edit firewall three-color-policer trTCM2-cb] user@host# set two-rate color-blind
A color-aware three-color policer takes into account any coloring markings that might have been set for a packet by another traffic policer configured at a previous network node, and any preexisting color markings are used in determining the appropriate policing action for the packet.
450
Because you are applying this three-color policer applied to input at Layer 2, you must configure the policer to be color-blind.
4.
Specify the policer traffic limits used to classify a green traffic flow.
[edit firewall three-color-policer trTCM2-cb] user@host# set two-rate committed-information-rate 40m user@host# set two-rate committed-burst-size 100k
5.
Specify the additional policer traffic limits used to classify a yellow or red traffic flow.
[edit firewall three-color-policer trTCM2-cb] user@host# set two-rate peak-information-rate 60m user@host# set two-rate peak-burst-size 200k
6.
(Optional) Specify the configured policer action for packets in a red traffic flow.
[edit firewall three-color-policer trTCM2-cb] user@host# set action loss-priority high then discard
In color-aware mode, the three-color policer configured action can increase the packet loss priority (PLP) level of a packet, but never decrease it. For example, if a color-aware three-color policer meters a packet with a medium PLP marking, it can raise the PLP level to high, but cannot reduce the PLP level to low. Results Confirm the configuration of the three-color policer by entering the show firewall configuration mode command. If the command output does not display the intended configuration, repeat the instructions in this procedure to correct the configuration.
[edit] user@host# show firewall three-color-policer trTCM2-cb { logical-interface-policer; action { loss-priority high then discard; } two-rate { color-blind; committed-information-rate 40m; committed-burst-size 100k; peak-information-rate 60m; peak-burst-size 200k; } }
Applying the Three-Color Policer to the Layer 2 Input at the Logical Interface Step-by-Step Procedure To apply the three-color policer to the Layer 2 input at the logical interface:
1.
Enable application of Layer 2 logical interface policers.

2.
Apply the three-color logical interface policer to a logical interface input.

[edit interfaces ge-1/3/1 unit 0]
451
user@host# set layer2-policer input-three-color trTCM2-cb
Results
[edit] user@host# show interfaces ge-1/3/1 { vlan-tagging; unit 0 { vlan-id 100; layer2-policer { input-three-color trTCM2-cb; } family inet { address 10.10.10.1/30; } } unit 1 { vlan-id 101; family inet { address 20.20.20.1/30 { arp 20.20.20.2 mac 00:00:11:22:33:44; } } } }
Verification

Displaying Traffic Statistics and Policers for the Logical Interface Purpose Verify the traffic flow through the logical interface and that the policer is evaluated when packets are received on the logical interface. Use the show interfaces operational mode command for logical interface ge-1/3/1.0, and include the detail or extensive option. The command output section for Traffic statistics lists the number of bytes and packets received and transmitted on the logical interface, and the Protocol inet section contains a Policer field that would list the policer trTCM2-cb as an input or output policer as follows:

Action
Input: trTCM2-cb-ge-1/3/1.0-log_int-i Output: trTCM2-cb-ge-1/3/1.0-log_int-o
452
The log_int-i suffix denotes a logical interface policer applied to input traffic, while the log_int-o suffix denotes a logical interface policer applied to output traffic. In this example, the logical interface policer is applied to in the input direction only. Displaying Statistics for the Policer Purpose Action Verify the number of packets evaluated by the policer. Use the show policer operational mode command and optionally specify the name of the policer. The command output displays the number of packets evaluated by each configured policer (or the specified policer), in each direction. For the policer trTCM2-cb, the input and output policer names are displayed as follows:

trTCM2-cb-ge-1/3/1.0-log_int-i trTCM2-cb-e-1/3/1.0-log_int-o
Statement Hierarchy for Configuring Policers on page 305 Guidelines for Applying Traffic Policers on page 316 layer2-policer on page 481 logical-interface-policer on page 483 policer (Configuring) on page 494 three-color-policer (Configuring) on page 501
453
454
CHAPTER 15
Summary of Policer Configuration Statements

The following descriptions explain each of the policer configuration statements. The statements are organized alphabetically.
455
action
Syntax
action { loss-priority high then discard; } [edit dynamic-profiles profile-name firewall three-color-policer name], [edit firewall three-color-policer name], [edit logical-systems logical-system-name firewall three-color-policer name]
Hierarchy Level
Release Information
Statement introduced in Junos OS Release 8.2. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... three-color-policer] hierarchy level introduced in Junos OS Release 11.4. Discard traffic on a logical interface using tricolor marking policing.
Description
NOTE: This statement is supported only on IQ2 interfaces.
The remaining statement is explained separately. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Three-Color Policer Configuration Overview on page 311 Basic Single-Rate Three-Color Policers on page 401 Basic Two-Rate Three-Color Policers on page 407 Two-Color and Three-Color Logical Interface Policers on page 415 Two-Color and Three-Color Physical Interface Policers on page 427 Two-Color and Three-Color Policers at Layer 2 on page 444 loss-priority high then discard on page 485
456
Chapter 15: Summary of Policer Configuration Statements
aggregate (Hierarchical Policer)

Syntax
aggregate { if-exceeding { bandwidth-limit bandwidth; burst-size-limit burst; } then { discard; } } [edit dynamic-profiles profile-name firewall hierarchical-policer name], [edit firewall hierarchical-policer]
Hierarchy Level
Release Information
Statement introduced in Junos OS Release 9.5. Support at the [edit dynamic-profiles ... hierarchical-policer name] hierarchy level introduced in Junos OS Release 11.4. On M40e, M120, and M320 edge routers with Flexible PIC Concentrator (FPC) input as FFPC and FPC output as SFPC, and on MX Series, T320, T640, and T1600 edge routers with Enhanced Intelligent Queuing (IQE) PICs, configure an aggregate hierarchical policer. The remaining statements are explained separately.
Description

Hierarchical Policer Configuration Overview on page 314 Hierarchical Policers on page 437 bandwidth-limit (Hierarchical Policer) on page 458 burst-size-limit (Hierarchical Policer) on page 463 hierarchical-policer on page 475 if-exceeding (Hierarchical Policer) on page 477 premium (Hierarchical Policer) on page 498
457
bandwidth-limit

bandwidth-limit (Hierarchical Policer) on page 458 bandwidth-limit (Policer) on page 459
bandwidth-limit (Hierarchical Policer)

bandwidth-limit bps; [edit dynamic-profiles profile-name firewall hierarchical-policer aggregate if-exceeding], [editdynamic-profiles profile-name firewall hierarchical-policer premium if-exceeding], [edit firewall hierarchical-policer aggregate if-exceeding], [edit firewall hierarchical-policer premium if-exceeding]
Release Information
Statement introduced in Junos OS Release 9.5. Support at the [edit dynamic-profiles ... if-exceeding] hierarchy level introduced in Junos OS Release 11.4. For M40e, M120, and M320 (with FFPC and SFPC) edge routers and T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs, configure the maximum average bandwidth for premium or aggregate traffic in a hierarchical policer.
bpsYou can specify the number of bits per second either as a decimal number or as a
Description
Options
decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 32,000 through 50,000,000,000 Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Hierarchical Policer Configuration Overview on page 314 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Single Token Bucket Algorithm on page 319 Calculation of Policer Burst-Size Limit on page 323 aggregate (Hierarchical Policer) on page 457 burst-size-limit (Hierarchical Policer) on page 463 premium (Hierarchical Policer) on page 498
458
bandwidth-limit (Policer)
bandwidth-limit bps; [edit dynamic-profiles profile-name firewall policer policer-name if-exceeding], [edit firewall policer policer-name if-exceeding], [edit logical-systems logical-system-name policer policer-name if-exceeding]
Release Information
Statement introduced before Junos OS Release 7.4. Support at the [edit dynamic-profiles ... if-exceeding] hierarchy level introduced in Junos OS Release 11.4. For a single-rate two-color policer, configure the bandwidth limit as a number of bits per second. Single-rate two-color policing uses the single token bucket algorithm to measure traffic-flow conformance to a two-color policer rate limit. Traffic at the interface that conforms to the bandwidth limit is categorized green. Traffic that exceeds the specified rate is also categorized as green provided that sufficient tokens remain in the single token bucket. Packets in a green flow are implicitly marked with low packet loss priority (PLP) and then passed through the interface. Traffic that exceeds the specified rate when insufficient tokens remain in the single token bucket is categorized red. Depending on the configuration of the two-color policer, packets in a red traffic flow might be implicitly discarded; or the packets might be re-marked with a specified forwarding class, a specified PLP, or both, and then passed through the interface.
Description
NOTE: This statement specifies the bandwidth limit as an absolute number of bits per second. Alternatively, for single-rate two-color policers only, you can use the bandwidth-percent percentage statement to specify the bandwidth limit as a percentage of either the physical interface port speed or the configured logical interface shaping rate.
Single-rate two-color policing allows bursts of traffic for short periods, whereas single-rate and two-rate three-color policing allows more sustained bursts of traffic. Hierarchical policing is a form of two-color policing that applies different policing actions based on whether the packets are classified for expedited forwarding (EF) or for a lower priority. You apply a hierarchical policer to ingress Layer 2 traffic to allows bursts of EF traffic for short period and bursts of non-EF traffic for short periods, with EF traffic always taking precedence over non-EF traffic. Options
bpsYou can specify the number of bits per second either as a decimal number or as a
decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: (M Series, MX Series, and T Series routers) 8000 through 50,000,000,000 Default: None.
459

Two-Color Policer Configuration Overview on page 307 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Single Token Bucket Algorithm on page 319 Calculation of Policer Burst-Size Limit on page 323 bandwidth-percent on page 461 burst-size-limit (Policer) on page 464
460
bandwidth-percent
bandwidth-percent percentage; [edit dynamic-profiles profile-name firewall policer policer-name if-exceeding], [edit firewall policer policer-name if-exceeding], [edit logical-systems logical-system-name policer policer-name if-exceeding]
Release Information
Statement introduced before Junos OS Release 7.4. Support at the [edit dynamic-profiles ... if-exceeding] hierarchy level introduced in Junos OS Release 11.4. For a single-rate two-color policer, configure the bandwidth limit as a percentage value. Single-rate two-color policing uses the single token bucket algorithm to measure traffic-flow conformance to a two-color policer rate limit. Traffic at the interface that conforms to the bandwidth limit is categorized green. Traffic that exceeds the specified rate is also categorized as green provided that sufficient tokens remain in the single token bucket. Packets in a green flow are implicitly marked with low packet loss priority and then passed through the interface. Traffic that exceeds the specified rate when insufficient tokens remain in the single token bucket is categorized red. Depending on the configuration of the two-color policer, packets in a red traffic flow might be implicitly discarded; or the packets might be re-marked with a specified forwarding class, a specified PLP, or both, and then passed through the interface.
Description
NOTE: This statement specifies the bandwidth limit as a percentage of either the physical interface port speed or the configured logical interface shaping rate. Alternatively, you can use the bandwidth-limit bps statement to specify the bandwidth limit as an absolute number of bits per second.
The function of the bandwidth limit is extended by the burst size (configured using the burst-size-limit bytes statement) to allow bursts of traffic up to a limit based on the overall traffic load:
When a single-rate two-color policer is applied to the input or output traffic at an interface, the initial capacity for traffic bursting is equal to the number of bytes specified by this statement. During periods of relatively low traffic (traffic that arrives at or departs from the interface at overall rates below the token arrival rate), unused tokens accumulate in the bucket, but only up to the configured token bucket depth.
Single-rate two-color policing allows bursts of traffic for short periods, whereas single-rate and two-rate three-color policing allows more sustained bursts of traffic. Hierarchical policing is a form of two-color policing that applies different policing actions based on whether the packets are classified for expedited forwarding (EF) or for a lower
461
priority. You apply a hierarchical policer to ingress Layer 2 traffic to allows bursts of EF traffic for short period and bursts of non-EF traffic for short periods, with EF traffic always taking precedence over non-EF traffic. Options
percentageTraffic rate as a percentage of either the physical interface media rate or
the logical interface configured shaping rate. You can configure a shaping rate on a logical interface by using class-of-service statement.
NOTE: You cannot rate-limit based on bandwidth percentage for aggregate, tunnel, and software interfaces. The bandwidth percentage policer cannot be used for forwarding table filters. Bandwidth percentage policers can only be used for interface-specific filters. Range: 0 through 100 Default: None. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Two-Color Policer Configuration Overview on page 307 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Single Token Bucket Algorithm on page 319 Calculation of Policer Burst-Size Limit on page 323 Bandwidth Policers on page 343 bandwidth-limit (Policer) on page 459 burst-size-limit (Policer) on page 464
462
burst-size-limit

burst-size-limit (Hierarchical Policer) on page 463 burst-size-limit (Policer) on page 464
burst-size-limit (Hierarchical Policer)

burst-size-limit bytes; [edit dynamic-profiles profile-name firewall hierarchical-policer aggregate if-exceeding], [editdynamic-profiles profile-name firewall hierarchical-policer premium if-exceeding], [edit firewall hierarchical-policer aggregate if-exceeding], [edit firewall hierarchical-policer premium if-exceeding]
Release Information
Statement introduced in Junos OS Release 9.5. Support at the [edit dynamic-profiles ... if exceeding] hierarchy level introduced in Junos OS Release 11.4. For M40e, M120, and M320 (with FFPC and SFPC) edge routers and T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs, configure the burst-size limit for premium or aggregate traffic in a hierarchical policer.
bytesBurst-size limit in bytes. The minimum recommended value is the maximum
Description
Options
transmission unit (MTU) of the IP packets being policed. You can specify the value either as a complete decimal number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 1500 through 2,147,450,880 Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Hierarchical Policer Configuration Overview on page 314 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Single Token Bucket Algorithm on page 319 Calculation of Policer Burst-Size Limit on page 323 Hierarchical Policers on page 437 aggregate (Hierarchical Policer) on page 457 bandwidth-limit (Hierarchical Policer) on page 458 premium (Hierarchical Policer) on page 498
463
burst-size-limit (Policer)
burst-size-limit bytes; [edit dynamic-profiles profile-name firewall policer policer-name if-exceeding], [edit firewall policer policer-name if-exceeding], [edit logical-systems logical-system-name policer policer-name if-exceeding]
Release Information
Statement introduced before Junos OS Release 7.4. Support at the [edit dynamic-profiles ... if-exceeding] hierarchy level introduced in Junos OS Release 11.4. For a single-rate two-color policer, configure the burst size as a number of bytes. The burst size allows for short periods of traffic bursting (back-to-back traffic at average rates that exceed the configured bandwidth limit). Single-rate two-color policing uses the single token bucket algorithm to measure traffic-flow conformance to a two-color policer rate limit. Traffic at the interface that conforms to the bandwidth limit is categorized green. Traffic that exceeds the specified rate is also categorized as green provided that sufficient tokens remain in the single token bucket. Packets in a green flow are implicitly marked with low packet loss priority and then passed through the interface. Traffic that exceeds the specified rate when insufficient tokens remain in the single token bucket is categorized red. Depending on the configuration of the two-color policer, packets in a red traffic flow might be implicitly discarded; or the packets might be re-marked with a specified forwarding class, a specified PLP, or both, and then passed through the interface. The burst size extends the function of the bandwidth limit (configured using either the bandwidth-limit bps statement or the bandwidth-percent percentage statement) to allow bursts of traffic up to a limit based on the overall traffic load:
Description
When a single-rate two-color policer is applied to the input or output traffic at an interface, the initial capacity for traffic bursting is equal to the number of bytes specified by this statement. During periods of relatively low traffic (traffic that arrives at or departs from the interface at overall rates below the token arrival rate), unused tokens accumulate in the bucket, but only up to the configured token bucket depth.
Single-rate two-color policing allows bursts of traffic for short periods, whereas single-rate and two-rate three-color policing allows more sustained bursts of traffic. Hierarchical policing is a form of two-color policing that applies different policing actions based on whether the packets are classified for expedited forwarding (EF) or for a lower priority. You apply a hierarchical policer to ingress Layer 2 traffic to allows bursts of EF traffic for short period and bursts of non-EF traffic for short periods, with EF traffic always taking precedence over non-EF traffic. Options
bytesBurst size limit in bytes. The minimum recommended value is the maximum
transmission unit (MTU) of the IP packets being policed. You can specify the value
464
either as a complete decimal number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 1500 through 100,000,000,000 Default: None Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Two-Color Policer Configuration Overview on page 307 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Single Token Bucket Algorithm on page 319 Calculation of Policer Burst-Size Limit on page 323 bandwidth-limit (Policer) on page 459 bandwidth-percent on page 461
465
color-aware
color-aware; [edit dynamic-profiles profile-name firewall three-color-policer name single-rate], [edit dynamic-profiles profile-name firewall three-color-policer name two-rate], [edit firewall three-color-policer policer-name single-rate], [edit firewall three-color-policer policer-name two-rate]
Release Information
Statement introduced in Junos OS Release 7.4. Support at the [edit dynamic-profiles ... single-rate] and [edit dynamic-profiles ... two-rate] hierarchy levels introduced in Junos OS Release 11.4. For a three-color policer, configure the way preclassified packets are metered. In color-aware mode, the local router can assign a higher packet loss priority, but cannot assign a lower packet loss priority. For example, suppose an upstream router assigned medium-high packet loss priority to a packet because the packet exceeded the committed information rate on the upstream router interface.
Description
If the local router applies color-aware policing to the packet, the router cannot change the packet loss priority to low, even if the packet conforms to the configured committed information route on the local router interface. If the local router applies color-blind policing to the packet, the router can change the packet loss priority to low if the packet conforms to the configured committed information route on the local router interface.
NOTE: A color-aware policer cannot be applied to Layer 2 traffic.
Default Required Privilege Level Related Documentation
If you omit the color-aware statement, the default behavior is color-aware mode. firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Three-Color Policer Configuration Overview on page 311 Color Modes for Three-Color Policers on page 400 color-blind on page 467
466
color-blind
color-blind; [edit dynamic-profiles profile-name firewall three-color-policer name single-rate], [edit dynamic-profiles profile-name firewall three-color-policer name two-rate], [edit firewall three-color-policer policer-name single-rate], [edit firewall three-color-policer policer-name two-rate]
Release Information
Statement introduced in Junos OS Release 7.4. Support at the [edit dynamic-profiles ... single-rate] and [edit dynamic-profiles ... two-rate] hierarchy levels introduced in Junos OS Release 11.4. For a three-color policer, configure the way preclassified packets are metered. In color-blind mode, the local router ignores the preclassification of packets and can assign a higher or lower packet loss priority. For example, suppose an upstream router assigned medium-high packet loss priority to a packet because the packet exceeded the committed information rate on the upstream router interface.
Description
If the local router applies color-aware policing to the packet, the router cannot change the packet loss priority to low, even if the packet conforms to the configured committed information route on the local router interface.
NOTE: A color-aware policer cannot be applied to Layer 2 traffic.
If the local router applies color-blind policing to the packet, the router can change the packet loss priority to low if the packet conforms to the configured committed information route on the local router interface.
Default Required Privilege Level Related Documentation
If you omit the color-blind statement, the default behavior is color-aware mode. firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Three-Color Policer Configuration Overview on page 311 Color Modes for Three-Color Policers on page 400 color-aware on page 466
467
committed-burst-size
committed-burst-size bytes; [edit dynamic-profiles profile-name firewall three-color-policer name single-rate], [edit dynamic-profiles profile-name firewall three-color-policer name two-rate], [edit firewall three-color-policer policer-name single-rate], [edit firewall three-color-policer policer-name two-rate]
Release Information
Statement introduced in Junos OS Release 7.4. Support at the [edit dynamic-profiles ... single-rate] and [edit dynamic-profiles ... two-rate] hierarchy levels introduced in Junos OS Release 11.4. For a three-color policer, configure the committed burst size (CBS) as a number of bytes.
Description
NOTE: When you include the committed-burst-size statement in the configuration, you must also include the committed-information-rate statement at the same hierarchy level.
In three-color policing, a committed information rate (CIR) defines the guaranteed bandwidth for traffic arriving at or departing from the interface under normal line conditions. A flow of traffic at an average rate that conforms to the CIR is categorized green. During periods of average traffic rates below the CIR, any unused bandwidth capacity accumulates up to a maximum amount defined by the CBS. Short periods of bursting traffic (back-to-back traffic at averages rates that exceed the CIR) are also categorized as green provided that unused bandwidth capacity is available. Traffic that exceeds both the CIR and the CBS is considered nonconforming. Single-rate three-color policers use a dual token bucket algorithm to measure traffic against a single rate limit. Nonconforming traffic is categorized as yellow or red, based on the excess-burst-size statement included in the policer configuration. Two-rate three-color policers use a dual-rate dual token bucket algorithm to measure traffic against two rate limits. Nonconforming traffic is categorized as yellow or red based on the peak-information-rate and peak-burst-rate statements included in the policer configuration. Options
bytesNumber of bytes. You can specify a value in bytes either as a complete decimal
number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 1500 through 100,000,000,000 bytes Required Privilege Level firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.
468
Three-Color Policer Configuration Overview on page 311 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Dual Token Bucket Algorithms on page 321 Calculation of Policer Burst-Size Limit on page 323 committed-information-rate on page 470 excess-burst-size on page 472 peak-burst-size on page 488 peak-information-rate on page 490
469
committed-information-rate
committed-information-rate bps; [edit dynamic-profiles profile-name firewall three-color-policer name single-rate], [edit dynamic-profiles profile-name firewall three-color-policer name two-rate], [edit firewall three-color-policer policer-name single-rate], [edit firewall three-color-policer policer-name two-rate]
Release Information
Statement introduced in Junos OS Release 7.4. Support at the [edit dynamic-profiles ... single-rate] and [edit dynamic-profiles ... two-rate] hierarchy levels introduced in Junos OS Release 11.4. For a three-color policer, configure the committed information rate as a number of bits per second. The committed information rate (CIR) is the guaranteed bandwidth for traffic arriving at or departing from the interface under normal line conditions.
Description
NOTE: When you include the committed-information-rate statement in the configuration, you must also include the committed-burst-size statement at the same hierarchy level.
In three-color policing, a CIR defines the guaranteed bandwidth for traffic arriving at or departing from the interface under normal line conditions. A flow of traffic at an average rate that conforms to the CIR is categorized green. During periods of average traffic rates below the CIR, any unused bandwidth capacity accumulates up to a maximum amount defined by the committed burst size (CBS). Short periods of bursting traffic (back-to-back traffic at averages rates that exceed the CIR) are also categorized as green provided that unused bandwidth capacity is available. Traffic that exceeds both the CIR and the CBS is considered nonconforming. Single-rate three-color policers use a dual token bucket algorithm to measure traffic against a single rate limit. Nonconforming traffic is categorized as yellow or red, based on the excess-burst-size statement included in the policer configuration. Two-rate three-color policers use a dual-rate dual token bucket algorithm to measure traffic against two rate limits. Nonconforming traffic is categorized as yellow or red based on the peak-information-rate and peak-burst-rate statements included in the policer configuration. Options
bpsNumber of bits per second. You can specify a value in bits per second either as a
complete decimal number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 32,000 through 40,000,000,000 bps
470

Three-Color Policer Configuration Overview on page 311 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Dual Token Bucket Algorithms on page 321 Calculation of Policer Burst-Size Limit on page 323 committed-burst-size on page 468 excess-burst-size on page 472 peak-burst-size on page 488 peak-information-rate on page 490
471
excess-burst-size
excess-burst-size bytes; [edit dynamic-profiles profile-name firewall three-color-policer name single-rate], [edit firewall three-color-policer policer-name single-rate]
Release Information
Statement introduced in Junos OS Release 7.4. Support at the [edit dynamic-profiles ... single-rate] hierarchy level introduced in Junos Release OS 11.4. For a single-rate three-color policer, configure the excess burst size (EBS) as a number of bytes. The EBS allows for moderate periods of bursting traffic that exceeds both the committed information rate (CIR) and the committed burst size (CBS).
Description
NOTE: When you include the excess-burst-size statement in the configuration, you must also include the committed-burst-size and committed-information-rate statements at the same hierarchy level.
Traffic that exceeds both the CIR and the CBS is considered nonconforming. Single-rate three-color policing uses a dual token bucket algorithm to measure traffic against a single rate limit. Nonconforming traffic is categorized as yellow or red based on the excess-burst-size statement included in the policer configuration. During periods of traffic that conforms to the CIR, any unused portion of the guaranteed bandwidth capacity accumulates in the first token bucket, up to the maximum number of bytes defined by the CBS. If any accumulated bandwidth capacity overflows the first bucket, the excess accumulates in a second token bucket, up to the maximum number of bytes defined by the EBS. A nonconforming traffic flow is categorized yellow if its size conforms to bandwidth capacity accumulated in the first token bucket. Packets in a yellow flow are marked with medium-high packet loss priority (PLP) and then passed through the interface. A nonconforming traffic flow is categorized red if its size exceeds the bandwidth capacity accumulated in the second token bucket. Packets in a red traffic flow are marked with high PLP and then either passed through the interface or optionally discarded. Options
number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 1500 through 100,000,000,000 bytes Required Privilege Level firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.
472
Three-Color Policer Configuration Overview on page 311 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Dual Token Bucket Algorithms on page 321 Calculation of Policer Burst-Size Limit on page 323 committed-burst-size on page 468 committed-information-rate on page 470
filter-specific
filter-specific; [edit dynamic-profiles profile-name firewall policer policer-name], [edit firewall family inet prefix-action name], [edit firewall policer policer-name], [edit logical-systems logical-system-name firewall policer policer-name], [edit logical-systems logical-system-name firewall family inet prefix-action name]
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... policer policer-name] hierarchy level introduced in Junos OS Release 11.4. Set the prefix-specific action or policer to operate in filter-specific mode, meaning that a single policer and counter are shared by all filter terms that reference the prefix-specific action or policer. By default, the prefix-specific action or policer operates in term-specific mode, meaning that a separate policer and counter are used for each filter term that references the prefix-specific action or policer. interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Description
Filter-Specific Policer Overview on page 352 Prefix-Specific Counting and Policing Overview on page 359 Filter-Specific Counter and Policer Set Overview on page 362
473
forwarding-class (Firewall Filter Action)

forwarding-class class-name; [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 Description Options Required Privilege Level Related Documentation
Statement introduced before Junos OS Release 7.4. Set the forwarding class of incoming packets.
class-nameName of the forwarding class.

Policer Color-Marking and Actions on page 318 Multifield Classification Overview on page 375
474
hierarchical-policer
Syntax
hierarchical-policer policer-name { aggregate { if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } then { discard; } } premium { if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } then { discard; } } } [edit dynamic-profiles profile-name firewall], [edit firewall]
Hierarchy Level
Release Information
Statement introduced in Junos OS Release 9.5. Support at the [edit dynamic-profiles ... firewall] hierarchy level introduced in Junos OS Release 11.4. On M40e, M120, and M320 edge routers with Flexible PIC Concentrator (FPC) input as FFPC and FPC output as SFPC, and on MX Series, T320, T640, and T1600 edge routers with Enhanced Intelligent Queuing (IQE) PICs, specify a hierarchical policer.
policer-nameName that identifies the policer. The name can contain letters, numbers,
Description
Options
and hyphens (-), and can be up to 255 characters long. To include spaces in the name, enclose it in quotation marks ( ). The remaining statements are explained separately. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Hierarchical Policer Configuration Overview on page 314 Hierarchical Policers on page 437 aggregate (Hierarchical Policer) on page 457 bandwidth-limit (Hierarchical Policer) on page 458 burst-size-limit (Hierarchical Policer) on page 463 if-exceeding (Hierarchical Policer) on page 477
475
premium (Hierarchical Policer) on page 498
476
if-exceeding

if-exceeding (Hierarchical Policer) on page 477 if-exceeding (Policer) on page 478
if-exceeding (Hierarchical Policer)

Syntax
if-exceeding { bandwidth-limit bps; burst-size-limit bytes; } [edit dynamic-profiles profile-name firewall hierarchical-policer aggregate], [edit dynamic-profiles profile-name firewall hierarchical-policer premium], [edit firewall hierarchical-policer aggregate], [edit firewall hierarchical-policer premium]
Hierarchy Level
Release Information
Statement introduced in Junos OS Release 9.5. Support at the [edit dynamic-profiles ... aggregate] and [edit dynamic-profiles ... premium] hierarchy level introduced in Junos OS Release 11.4. For M40e, M120, and M320 (with FFPC and SFPC) edge routers and T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs, specify bandwidth and burst limits for a premium or aggregate component of a hierarchical policer. The remaining statements are explained separately.
Description

Hierarchical Policer Configuration Overview on page 314 Hierarchical Policers on page 437 aggregate (Hierarchical Policer) on page 457 bandwidth-limit (Hierarchical Policer) on page 458 burst-size-limit (Hierarchical Policer) on page 463 hierarchical-policer on page 475 premium (Hierarchical Policer) on page 498
477
if-exceeding (Policer)
Syntax
if-exceeding { (bandwidth-limit bps | bandwidth-percent number); burst-size-limit bytes; } [edit dynamic-profiles profile-name firewall policer policer-name], [edit firewall policer policer-name], [edit logical-systems logical-system-name firewall policer policer-name]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... policer policer-name] hierarchy level introduced in Junos OS Release 11.4. Configure rate limits for a single-rate two-color policer. The remaining statements are explained separately.
Description

Two-Color Policer Configuration Overview on page 307 Hierarchical Policer Configuration Overview on page 314 Basic Single-Rate Two-Color Policers on page 327 Bandwidth Policers on page 343 Filter-Specific Counters and Policers on page 352 Prefix-Specific Counting and Policing Actions on page 359 Multifield Classification on page 375 Policer Overhead to Account for Rate Shaping in the Traffic Manager on page 390 Hierarchical Policers on page 437
478
input-hierarchical-policer
input-hierarchical-policer policer-name; [edit interfaces interface-name layer2-policer], [edit interfaces interface-name unit logical-unit-number layer2-policer], [edit logical-systems logical-system-name interfaces interface-name layer2-policer] [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number layer2-policer]
Statement introduced in Junos OS Release 9.5. Apply a hierarchical policer to the Layer 2 input traffic for all protocol families at the physical or logical interface.
policer-nameName of the hierarchical policer.
Options Required Privilege Level Related Documentation

Hierarchical Policers on page 437 layer2-policer on page 481
input-policer
input-policer policer-name; [edit interfaces interface-name unit logical-unit-number layer2-policer], [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number layer2-policer]
Statement introduced in Junos OS Release 8.2. Apply a single-rate two-color policer to the Layer 2 input traffic at the logical interface. The input-policer and input-three-color statements are mutually exclusive.
policer-nameName of the single-rate two-color policer.

Two-Color and Three-Color Policers at Layer 2 on page 444 input-three-color on page 480 layer2-policer on page 481 logical-interface-policer on page 483 output-policer on page 486
479
input-three-color
input-three-color policer-name; [edit interfaces interface-name unit logical-unit-number layer2-policer], [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number layer2-policer]
Statement introduced in Junos OS Release 8.2. Apply a single-rate or two-rate three-color policer to the Layer 2 input traffic at the logical interface. The input-policer and input-three-color statements are mutually exclusive.
policer-nameName of the single-rate or two-rate three-color policer.

Two-Color and Three-Color Policers at Layer 2 on page 444 input-policer on page 479 layer2-policer on page 481 logical-interface-policer on page 483 output-three-color on page 487
480
layer2-policer
layer2-policer { ... } [edit interfaces interface-name], [edit interfaces interface-name unit logical-unit-number], [edit logical-systems logical-system-name interfaces interface-name] [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]
Statement introduced in Junos OS Release 8.2. Apply a traffic policer to Layer 2 traffic at a supported interface. Apply a two-color or three-color logical interface policer to the Layer 2 input or output traffic at the logical interface. The following interfaces are supported:

1-Gigabit Ethernet interfaces on M Series, MX Series, and T Series routers 10-Gigabit Ethernet IQ2 and IQ2E interfaces on M Series, MX Series, and T Series routers
Apply a hierarchical policer to the Layer 2 input traffic for all protocol families at the physical or logical interface. The following interfaces are supported:
SONET interfaces hosted on M40e, M120, and M320 edge routers with incoming Flexible PIC Concentrators (FPCs) as SFPC and outgoing FPCs as FFPC Interfaces on MX Series, T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs
The statements are explained separately. interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Hierarchical Policers on page 437 input-hierarchical-policer on page 479 Two-Color and Three-Color Policers at Layer 2 on page 444 input-policer on page 479 input-three-color on page 480 output-policer on page 486 output-three-color on page 487
481
load-balance-group
Syntax
load-balance-group group-name { next-hop-group [ group-names ]; } [edit firewall]
Hierarchy Level Release Information Description Options
Statement introduced before Junos OS Release 7.4. Configure a load-balance group.

group-nameName of load-balance group. group-namesName of next-hop groups to include in the load-balance group set.
Configuring Load-Balance Groups in the Junos OS Routing Policy Configuration Guide
logical-bandwidth-policer
logical-bandwidth-policer; [edit dynamic-profiles profile-name firewall policer policer-name], [edit firewall policer policer-name], [edit logical-systems logical-system-name firewall policer policer-name]
Release Information
Statement introduced in Junos OS Release 8.2. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... policer policer-name] hierarchy level introduced in Junos OS Release 11.4. For a policer with a bandwidth limit configured as a percentage (using the bandwidth-percent statement), specify that the percentage be based on the shaping rate defined on the logical interface, rather than on the media rate of the physical interface. interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Description
Bandwidth Policers on page 343 bandwidth-percent on page 461 interface-specific on page 290 statement in the Junos OS Firewall Filter and Policer
Configuration Guide
482
logical-interface-policer
logical-interface-policer; [edit dynamic-profiles profile-name firewall policer policer-name], [edit dynamic-profiles profile-name firewall three-color-policer name], [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 OS Release 7.4. Support at the [edit firewall three-color-policer name] hierarchy level introduced in Junos OS Release 8.2. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... policer policer-name] and [edit dynamic-profiles ... three-color-policer name] hierarchy levels introduced in Junos OS Release 11.4. Configure a logical interface (aggregate) policer. interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.
Description Required Privilege Level Related Documentation
Two-Color and Three-Color Logical Interface Policers on page 415
483
loss-priority

loss-priority (Firewall Filter Action) on page 484 loss-priority high then discard (Three-Color Policer) on page 485
loss-priority (Firewall Filter Action)

loss-priority (high | low); [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 Description Required Privilege Level Related Documentation
Statement introduced before Junos OS Release 7.4. Set the loss priority of incoming packets. interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Policer Color-Marking and Actions on page 318 Multifield Classification Overview on page 375
484
loss-priority high then discard (Three-Color Policer)

loss-priority high then discard; [edit dynamic-profiles profile-name firewall three-color-policer name action], [edit firewall three-color-policer policer-name action], [edit logical-systems logical-system-name firewall three-color-policer policer-name action]
Release Information
Statement introduced before Junos OS Release 8.2. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... action] hierarchy level introduced in Junos OS Release 11.4. For packets with high loss priority, discard the packets. The loss priority setting is implicit and is not configurable. Include this statement if you do not want the local router to forward packets that have high packet loss priority. For single-rate three-color policers, the Junos OS assigns high loss priority to packets that exceed the committed information rate and the excess burst size. For two-rate three-color policers, the Junos OS assigns high loss priority to packets that exceed the peak information rate and the peak burst size.
Description

Three-Color Policer Configuration Overview on page 311 Basic Single-Rate Three-Color Policers on page 401 Basic Two-Rate Three-Color Policers on page 407 Two-Color and Three-Color Logical Interface Policers on page 415 Two-Color and Three-Color Physical Interface Policers on page 427 Two-Color and Three-Color Policers at Layer 2 on page 444 action on page 456
485
output-policer
output-policer policer-name; [edit interfaces interface-name unit logical-unit-number layer2-policer], [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number layer2-policer]
Statement introduced in Junos OS Release 8.2. Apply a single-rate two-color policer to the Layer 2 output traffic at the logical interface. The output-policer and output-three-color statements are mutually exclusive.
policer-nameName of the single-rate two-color policer.

Two-Color and Three-Color Policers at Layer 2 on page 444 input-policer on page 479 layer2-policer on page 481 logical-interface-policer on page 483 output-three-color on page 487
486
output-three-color
output-three-color policer-name; [edit interfaces interface-name unit logical-unit-number layer2-policer], [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number layer2-policer]
Statement introduced in Junos OS Release 8.2. Apply a single-rate or two-rate three-color policer to the Layer 2 output traffic at the logical interface. The output-policer and output-three-color statements are mutually exclusive.
policer-nameName of the single-rate or two-rate three-color policer.

Two-Color and Three-Color Policers at Layer 2 on page 444 input-three-color on page 480 layer2-policer on page 481 logical-interface-policer on page 483 output-policer on page 486
487
peak-burst-size
peak-burst-size bytes; [edit dynamic-profiles profile-name firewall three-color-policer name two-rate], [edit firewall three-color-policer policer-name two-rate]
Release Information
Statement introduced in Junos OS Release 7.4. Support at the [edit dynamic-profiles ... two-rate] hierarchy level introduced in Junos OS Release 11.4. For a two-rate three-color policer, configure the peak burst size (PBS) as a number of bytes. The PBS defines the maximum number of bytes of unused peak bandwidth capacity that can be accumulated. The accumulated bandwidth allows for moderate periods of bursting traffic that exceeds the peak information rate (PIR) and the committed burst size (CBS).
Description
NOTE: When you include the peak-burst-size statement in the configuration, you must also include the committed-burst-size and peak-information-rate statements at the same hierarchy level.
Two-rate three-color policers use a dual-rate dual token bucket algorithm to measure traffic against two rate limits.
A traffic flow is categorized green if it conforms to both the committed information rate (CIR) and the CBS-bounded accumulation of available committed bandwidth capacity. A traffic flow is categorized yellow if exceeds the CIR and CBS but conforms to the PIR. Packets in a yellow flow are marked with medium-high packet loss priority (PLP) and then passed through the interface. A traffic flow is categorized red if exceeds the PIR and the PBS-bounded accumulation of available peak bandwidth capacity. Packets in a red traffic flow are marked with high PLP and then either passed through the interface or optionally discarded.
Options
number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 1500 through 100,000,000,000 bytes Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Three-Color Policer Configuration Overview on page 311 Policer Bandwidth and Burst-Size Limits on page 316
488
Policer Color-Marking and Actions on page 318 Dual Token Bucket Algorithms on page 321 Calculation of Policer Burst-Size Limit on page 323 committed-burst-size on page 468 committed-information-rate on page 470 excess-burst-size on page 472 peak-information-rate on page 490
489
peak-information-rate
peak-information-rate bps; [edit dynamic-profiles profile-name firewall three-color-policer name two-rate], [edit firewall three-color-policer policer-name two-rate]
Release Information
Statement introduced in Junos OS Release 7.4. Support at the [edit dynamic-profiles ... two-rate] hierarchy level introduced in Junos OS Release 11.4. For a two-rate three-color policer, configure the peak information rate (PIR) as a number of bits per second. The PIR is the maximum rate for traffic arriving at or departing from the interface under peak line conditions. Traffic that exceeds the committed information rate (CIR) and the committed burst size (CBS) is metered to the PIR.
Description
NOTE: When you include the peak-information-rate statement in the configuration, you must also include the committed-information-rate and peak-burst-size statements at the same hierarchy level.
Two-rate three-color policers use a dual-rate dual token bucket algorithm to measure traffic against two rate limits.
A traffic flow is categorized green if it conforms to both the CIR and the CBS-bounded accumulation of available committed bandwidth capacity. A traffic flow is categorized yellow if exceeds the CIR and CBS but conforms to the PIR. Packets in a yellow flow are marked with medium-high packet loss priority (PLP) and then passed through the interface. A traffic flow is categorized red if exceeds the PIR and the PBS-bounded accumulation of available peak bandwidth capacity. Packets in a red traffic flow are marked with high PLP and then either passed through the interface or optionally discarded.
Options
bpsNumber of bits per second. You can specify a value in bits per second either as a
complete decimal number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 32,000 through 40,000,000,000 bps Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Three-Color Policer Configuration Overview on page 311 Policer Bandwidth and Burst-Size Limits on page 316 Policer Color-Marking and Actions on page 318 Dual Token Bucket Algorithms on page 321
490
Calculation of Policer Burst-Size Limit on page 323 committed-burst-size on page 468 committed-information-rate on page 470 excess-burst-size on page 472 peak-burst-size on page 488
physical-interface-filter; [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]
Statement introduced in Junos OS Release 9.6. Configure a physical interface filter. Use this statement to reference a physical interface policer for the specified protocol family. interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Two-Color and Three-Color Physical Interface Policers on page 427 physical-interface-policer on page 492 policer (Configuring) on page 494
491
physical-interface-policer; [edit dynamic-profiles profile-name firewall policer policer-name], [edit firewall policer policer-name], [edit firewall three-color-policer policer-name], [edit logical-system logical-system-name firewall policer policer-name], [edit logical-system logical-system-name three-color-policer policer-name], [edit routing-instances routing-instance-name firewall policer policer-name], [edit routing-instances routing-instance-name firewall three-color-policer policer-name], [edit logical-systems logical-system-name routing-instances routing-instance-name firewall policer policer-name], [edit logical-systems logical-system-name routing-instances routing-instance-name firewall three-color-policer policer-name]
Release Information
Statement introduced in Junos OS Release 9.6. Support at the [edit dynamic-profiles ... policer policer-name] hierarchy level introduced in Junos Release OS 11.4. Configure an aggregate policer for a physical interface. A physical interface policer applies to all the logical interfaces and protocol families configured on a physical interface. As a result, a single physical interface policer can be applied to multiple routing instances because this policer includes all the logical interfaces configured on the physical interface even if they belong to different routing instances. interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Description
Two-Color and Three-Color Physical Interface Policers on page 427 physical-interface-filter on page 491
492
policer

policer (Applying to a Logical Interface) on page 493 policer (Configuring) on page 494 policer (Firewall Filter Action) on page 495
policer (Applying to a Logical Interface)

Syntax
policer { input policer-name; output policer-name; } [edit interfaces interface-name unit unit-number], [edit interfaces interface-name unit unit-number family family], [edit logical-systems logical-system-name interfaces interface-name unit unit-number], [edit logical-systems logical-system-name interfaces interface-name unit unit-number family family]
Hierarchy Level
Description
Apply a single-rate two-color policerexcept for a physical interface policerto Layer 3 input or output traffic at a logical interface.
To rate-limit all traffic types, regardless of the protocol family, you can apply a logical interface policer at the logical unit level of a supported interface. To rate-limit traffic of a specific protocol family, you can apply a basic two-color policer, a bandwidth policer, or a logical interface policer at the protocol family level of a supported interface.
NOTE: You cannot apply a physical interface policer as part of the interface configuration. You can apply a physical interface policer by referencing the policer from a physical interface filter term.
Options
input policer-nameName of one policer to evaluate packets received on the interface. output policer-nameName of one policer to evaluate packets transmitted on the
interface. Required Privilege Level Related Documentation interfaceTo view this statement in the configuration. interface-controlTo add this statement to the configuration.

Single-Rate Two-Color Policer Overview on page 327 Bandwidth Policer Overview on page 344 Logical Interface (Aggregate) Policer Overview on page 415
493
policer (Configuring)
Syntax
policer policer-name { filter-specific; if-exceeding { bandwidth-limit bps; bandwidth-percent number; burst-size-limit bytes; } logical-interface-policer; physical-interface-policer; then { policer-action; } } [edit dynamic-profiles profile-name firewall], [edit firewall], [edit logical-systems logical-system-name firewall]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. physical-interface-policer statement introduced in Junos OS Release 9.6. Support at the [edit dynamic-profiles ... firewall] hierarchy level introduced in Junos OS Release 11.4. Configure policer rate limits and actions. When included at the [edit firewall] hierarchy level, the policer statement creates a template, and you do not have to configure a policer individually for every firewall filter or interface. To activate a policer, you must include the policer-action modifier in the then statement in a firewall filter term or on an interface.
policer-actionOne or more actions to take:

Description
Options
discardDiscard traffic that exceeds the rate limits. forwarding-class class-nameSpecify the particular forwarding class. loss-prioritySet the packet loss priority (PLP) to low, medium-low, medium-high, or high.
policer-nameName that identifies the policer. The name can contain letters, numbers,
and hyphens (-), and can be up to 255 characters long. To include spaces in the name, enclose it in quotation marks ( ).
thenActions to take on matching packets.
The remaining statements are explained separately. Required Privilege Level firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.
494
Statement Hierarchy for Configuring Policers on page 305 Single-Rate Two-Color Policer Overview on page 327 Bandwidth Policer Overview on page 344 Physical Interface Policer Overview on page 427 Logical Interface (Aggregate) Policer Overview on page 415
policer (Firewall Filter Action)

policer policer-name; [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 OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. 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 tricolor marking policer.
policer-nameName of a single-rate two-color policer to use to rate-limit traffic.
Description

Two-Color Policer Configuration Overview on page 307
495
prefix-action

prefix-action (Configuring) on page 496 prefix-action (Firewall Filter Action) on page 497
prefix-action (Configuring)
Syntax
prefix-action prefix-action-name { count; destination-prefix-length prefix-length; filter-specific; policer policer-name; source-prefix-length prefix-length; subnet-prefix-length prefix-length; } [edit firewall family inet], [edit logical-systems logical-system-name firewall family inet]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Configure a prefix-specific action.
countEnable counter. destination-prefix-length prefix-lengthDestination prefix length.
Description Options
Range: 0 through 32
filter-specificCreate the prefix-specific set of policers and counters as a filter-specific
set. If this option is not specified, the prefix-specific set of policers and counters are created as term-specific.
policer policer-namePolicer name. source-prefix-length prefix-lengthSource prefix length.
Range: 0 through 32
subnet-prefix-length prefix-lengthSubnet prefix length.
Range: 0 through 32 Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.
Prefix-Specific Counting and Policing Actions on page 359
496
prefix-action (Firewall Filter Action)

prefix-action prefix-action-name; [edit firewall family inet filter filter-name term term-name then], [edit logical-systems logical-system-name firewall family inet filter filter-name term term-name then]
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Reference a prefix-specific action.
prefix-action-nameName of a prefix-specific action to use to rate-limit traffic.
Description Options

Prefix-Specific Counting and Policing Actions on page 359
497
premium (Hierarchical Policer)

Syntax
premium { if-exceeding { bandwidth-limit bandwidth; burst-size-limit burst; } then { discard; } } [edit dynamic-profiles profile-name firewall hierarchical-policer], [edit firewall hierarchical-policer]
Hierarchy Level
Release Information
Statement introduced in Junos OS Release 9.5. Support at the [edit dynamic-profiles ... hierarchical-policer name] hierarchy level introduced in Junos OS Release 11.4. On M40e, M120, and M320 edge routers with FPC input as FFPC and FPC output as SFPC, and on MX Series, T320, T640, and T1600 edge routers with Enhanced Intelligent Queuing (IQE) PICs, specify a premium level for a hierarchical policer. The remaining statements are explained separately.
Description

Hierarchical Policer Configuration Overview on page 314 Hierarchical Policers on page 437 aggregate (Hierarchical Policer) on page 457 bandwidth-limit (Hierarchical Policer) on page 458 burst-size-limit (Hierarchical Policer) on page 463 hierarchical-policer on page 475 if-exceeding (Hierarchical Policer) on page 477
498
single-rate
Syntax
single-rate { (color-aware | color-blind); committed-information-rate bps; committed-burst-size bytes; excess-burst-size bytes; } [edit dynamic-profiles profile-name firewall three-color-policer name], [edit firewall three-color-policer policer-name], [edit logical-systems logical-system-name firewall three-color-policer policer-name]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... three-color-policer name] hierarchy level introduced in Junos OS Release 11.4. Configure a single-rate three-color policer in which marking is based on the committed information rate (CIR), committed burst size (CBS), and excess burst size (EBS). Packets that conform to the CIR or the CBS are assigned low loss priority (green). Packets that exceed the CIR and the CBS but are within the EBS are assigned medium-high loss priority (yellow). Packets that exceed the EBS are assigned high loss priority (red). Green and yellow packets are always forwarded; this action is not configurable. You can configure red packets to be discarded. By default, red packets are forwarded. The remaining statements are explained separately.
Description

Three-Color Policer Configuration Overview on page 311 color-aware on page 466 color-blind on page 467 two-rate on page 503
499
three-color-policer

three-color-policer (Configuring) on page 501 three-color-policer (Firewall Filter Action) on page 502
500
three-color-policer (Configuring)
Syntax
three-color-policer policer-name { action { loss-priority high then discard; } logical-interface-policer; physical-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; } } [edit dynamic-profiles profile-name firewall], [edit firewall], [edit logical-systems logical-system-name firewall]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. action statement introduced in Junos OS Release 8.2. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... firewall] hierarchy level introduced in Junos OS Release 11.4. Configure a three-color policer.
policer-nameName of the three-color policer. Reference this name when you apply the
Description Options
policer to an interface. The remaining statements are explained separately. Required Privilege Level Related Documentation firewallTo view this statement in the configuration. firewall-controlTo add this statement to the configuration.

Statement Hierarchy for Configuring Policers on page 305 Three-Color Policer Configuration Guidelines on page 399 Basic Single-Rate Three-Color Policers on page 401 Basic Two-Rate Three-Color Policers on page 407 Two-Color and Three-Color Logical Interface Policers on page 415 Two-Color and Three-Color Physical Interface Policers on page 427
501
Two-Color and Three-Color Policers at Layer 2 on page 444
three-color-policer (Firewall Filter Action)

Syntax
three-color-policer { (single-rate | two-rate) policer-name; } [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]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. single-rate statement added in Junos OS Release 8.2. Logical systems support introduced in Junos OS Release 9.3. 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 tricolor marking policer.
single-rateNamed tricolor policer is a single-rate policer. two-rateNamed tricolor policer is a two-rate policer. policer-nameName of three-color policer to use to rate-limit traffic.
Description
Options

Three-Color Policer Configuration Overview on page 311
502
two-rate
Syntax
two-rate { (color-aware | color-blind); committed-information-rate bps; committed-burst-size bytes; peak-information-rate bps; peak-burst-size bytes; } [edit dynamic-profiles profile-name firewall three-color-policer name], [edit firewall three-color-policer policer-name], [edit logical-systems logical-system-name firewall three-color-policer policer-name]
Hierarchy Level
Release Information
Statement introduced before Junos OS Release 7.4. Logical systems support introduced in Junos OS Release 9.3. Support at the [edit dynamic-profiles ... three-color-policer name hierarchy levels introduced in Junos OS Release 11.4. Configure a two-rate three-color policer in which marking is based on the committed information rate (CIR), committed burst size (CBS), peak information rate (PIR), and peak burst size (PBS). Packets that conform to the CIR or the CBS are assigned low loss priority (green). Packets that exceed the CIR and the CBS but are within the PIR or the PBS are assigned medium-high loss priority (yellow). Packets that exceed the PIR and the PBS are assigned high loss priority (red). Green and yellow packets are always forwarded; this action is not configurable. You can configure red packets to be discarded. By default, red packets are forwarded. The remaining statements are explained separately.
Description

Three-Color Policer Configuration Overview on page 311 color-aware on page 466 color-blind on page 467 single-rate on page 499
503
504
PART 3
Index

Index on page 507 Index of Statements and Commands on page 519
505
506
Index
Symbols
! (negation) in firewall filters bit-field logical operator.....................................32 #, comments in configuration statements.................xxvi &, bit-field logical operator..................................................32 ( ), in syntax descriptions..................................................xxvi + bit-field logical operator..............................................32 , (comma), bit-field logical operator...............................32 < >, in syntax descriptions.................................................xxv [ ], in configuration statements......................................xxvi { }, in configuration statements......................................xxvi | (pipe) in firewall filters bit-field logical operator.....................................32 | (pipe), in syntax descriptions........................................xxvi
address class, source or destination stateless firewall filter match conditions IPv4 traffic...............................................................48 IPv6 traffic................................................................57 overview....................................................................45 address prefix, source or destination stateless firewall filter match conditions MPLS-tagged IPv4 traffic..................................64 VPLS traffic.............................................................66 address, source or destination stateless firewall filter match conditions IPv4 traffic...............................................................48 IPv6 traffic................................................................57 Layer 2 bridging traffic.........................................75 VPLS traffic.............................................................66 aggregate (logical interface) policer configuration statement for....................................483 example single-rate two-color.........................................416 two-rate three-color.................................421, 447 overview...........................................................................415 aggregate statement hierarchical policer......................................................457 ampersand (&), bit-field logical operator.....................32 apply-path statement firewall filter match condition...................................97
A
accounting standard stateless firewall filters applying firewall filter accounting profiles.................................................................212 configuring firewall filter accounting profiles..................................................................211 example...................................................................213 overview...................................................................211 accounting-profile statement.........................................283 action statement.................................................................456 actions, flow control..............................................................25 actions, nonterminating for service filters............................................................241 for simple filters............................................................253 for standard stateless firewall filters......................82 actions, terminating for service filters............................................................241 for simple filters............................................................253 for standard stateless firewall filters.......................81
B
bandwidth policer, logical example..........................................................................345 overview..........................................................................344 bandwidth-limit statement hierarchical policer.....................................................458 policer..............................................................................459 bandwidth-percent statement policer...............................................................................461 bit-field logical operators.............................................................32 braces, in configuration statements..............................xxvi brackets angle, in syntax descriptions....................................xxv square, in configuration statements....................xxvi burst-size-limit statement...............................................464 hierarchical policer.....................................................463
C
class-of-service See CoS color markings policers.............................................................................318
507
color modes for three-color policer..............................400 color-aware statement.....................................................466 color-blind statement........................................................467 comments, in configuration statements.....................xxvi committed-burst-size statement.................................468 committed-information-rate statement....................470 configuration and application overview hierarchical policers.....................................................314 single-rate two-color policers.................................307 three-color policers.......................................................311 configuration examples service filters..................................................................242 simple filter....................................................................255 conventions text and syntax..............................................................xxv CoS forwarding classes.......................................................375 policer actions, overview...........................................297 RED drop profiles.........................................................375 curly braces, in configuration statements...................xxvi customer support.................................................................xxvi contacting JTAC...........................................................xxvi
DSCP code point stateless firewall filter match condition IPv4 traffic...............................................................48 Layer 2 bridging traffic.........................................75 VPLS traffic.............................................................66 dual token bucket algorithms...........................................321
E
enhanced-mode statement firewall.............................................................................284 excess-burst-size statement...........................................472 exclamation point ( ! ), bit-field logical operator..................................................................................32
F
family statement firewall filter...................................................................285 files firewall log output file..................................................117 filter statement firewall.............................................................................288 filter-based forwarding standard stateless firewall filters applying filters to interfaces...........................204 configuring for IPv4 or IPv6 traffic................201 configuring for MPLS-tagged IPv4 traffic...................................................................201 example.................................................................206 overview..................................................................199 filter-specific counting and policing set.........................................362 policer..............................................................................352 filter-specific policing option configuration scenarios............................................369 example..........................................................................362 overview..........................................................................359 filter-specific statement....................................................473 configuration scenarios............................................369 example..........................................................................362 overview......................................................352, 359, 362 firewall filters configuring on logical systems...............................279 log output file..................................................................117 physical interface filters.............................................491 verifying fragment handling......................................157
D
denial-of-service attacks, preventing..................143, 353 destination MAC address stateless firewall filter match conditions Layer 2 CCC traffic.................................................73 MPLS-tagged IPv4 traffic..................................64 VPLS traffic.............................................................66 diagnosis displaying stateless firewall filter configurations..................................121, 147, 156, 357 displaying stateless firewall filter statistics............................................................148, 358 verifying firewall filter handles fragments...........157 verifying stateless firewall filter actions...............122 verifying stateless firewall filter DoS protection...........................................................147, 357 verifying stateless firewall filter flood protection...........................................................147, 357 verifying stateless firewall filters with packet logs.................................................................................122 documentation comments on................................................................xxvi DoS (denial-of-service) attacks, preventing..................................................................143, 353
508
Index
firewall filters in logical systems restrictions references from nonfirewall filter objects...............................................................268 references to nonfirewall filter objects...............................................................266 references to subordinate objects...............265 firewall log output file...........................................................117 firewall statement...............................................................289 flooding, preventing....................................................143, 353 font conventions....................................................................xxv forwarding class policer actions overview..................................................................297 stateless firewall filter match conditions IPv4 traffic...............................................................48 IPv6 traffic................................................................57 Layer 2 bridging traffic.........................................75 Layer 2 CCC traffic.................................................73 protocol-independent traffic............................47 VPLS traffic.............................................................66 forwarding classes...............................................................375 forwarding-class statement stateless firewall filter action..................................474 fxp0............................................................................................232
H
handling packet fragments...............................................152 hierarchical policer bandwidth limit.............................................................316 burst-size limit...............................................................316 color markings and actions......................................318 configuration and application overview..............314 configuration statement for aggregate...............................................................457 premium................................................................498 example..........................................................................439 overview.................................................................301, 437 single token bucket algorithm.................................319 hierarchical-policer statement........................................475
I
ICMP (Internet Control Message Protocol), policers........................................................................143, 353 icons defined, notice...........................................................xxiv if-exceeding statement hierarchical policer......................................................477 single-rate two-color policer...................................478 input-hierarchical-policer statement...........................479
input-policer statement....................................................479 input-three-color statement...........................................480 interface groups filtering packets received on applying filters.......................................................187 assigning logical interfaces to groups.........185 configuring filters.................................................186 example..................................................................188 overview..................................................................185 interface set filtering packets received on configuring filters.................................................193 defining the interfaces in the set...................192 overview..................................................................192 interface-set statement....................................................289 interface-specific counters example example..................................................................180 interface-specific firewall filter instances filtering packets received on guidelines for applying......................................180 guidelines for configuring..................................179 overview...................................................................177 interface-specific names filter instance.........................................................178 interface-specific statement...........................................290 Internet Control Message Protocol policers........................................................................143, 353 IPv4 traffic match conditions standard stateless firewall filters...................48 service filter actions, nonterminating...................241 service filter actions, terminating...........................241 service filter match conditions...............................235 stateless firewall filter match conditions protocol-independent traffic............................47 IPv6 traffic match conditions standard stateless firewall filters....................57 service filter actions, nonterminating...................241 service filter actions, terminating...........................241 service filter match conditions...............................235 stateless firewall filter match conditions protocol-independent traffic............................47
L
Layer 2 bridging traffic match conditions standard stateless firewall filters....................75
509
Layer 2 policer hierarchical policer configuration overview......................................314 example.................................................................439 overview..................................................................437 three-color policer overview.................................................................446 two-color policer overview.................................................................444 layer2-policer statement...................................................481 hierarchical policing.....................................................314 Layer 2 CCC traffic match conditions standard stateless firewall filter......................73 Layer 2 policer three-color-policer example.........................................................421, 447 load-balance-group statement.....................................482 log output firewall filters...................................................................117 logging standard stateless firewall filters example..................................................................222 system logging of firewall facility events..................................................................219 system logging of packet headers.................221 system logging overview...................................218 logical bandwidth policer example..........................................................................345 overview..........................................................................344 logical interface (aggregate) policer configuration statement for....................................483 example single-rate two-color.........................................416 two-rate three-color.................................421, 447 overview...........................................................................415 logical interface-policer statement..............................483 logical systems configuring firewall filters.........................................279 restrictions for firewall filters references from nonfirewall filter objects...............................................................268 references to nonfirewall filter objects...............................................................266 references to subordinate objects...............265 stateless firewall filters applying..................................................................262 configuring.............................................................262 overview..................................................................261
unsupported firewall filter actions........................275 unsupported firewall filter statements................273 logical-bandwidth-policer statement.........................482 loopback interface, applying stateless firewall filters to (configuration editor).......................................143, 353 loss priority stateless firewall filter match conditions IPv4 traffic...............................................................48 IPv6 traffic................................................................57 Layer 2 bridging traffic.........................................75 Layer 2 CCC traffic.................................................73 VPLS traffic.............................................................66 loss-priority statement stateless firewall filter action.................................484
M
management interface.......................................................232 manuals comments on................................................................xxvi match condition categories stateless firewall filters matching on address classes...........................45 matching on address prefixes...........................37 matching on bit-field values.............................32 matching on numeric values..............................31 matching on text strings......................................31 match conditions for service filters...........................................................235 match conditions for standard stateless firewall filters IPv4 traffic........................................................................48 IPv6 traffic.........................................................................57 Layer 2 bridging traffic..................................................75 Layer 2 CCC traffic..........................................................73 MPLS traffic.....................................................................62 MPLS-tagged IPv4 traffic...........................................64 protocol-independent traffic.....................................47 VPLS traffic......................................................................66 MPLS traffic match conditions standard stateless firewall filters....................62 MPLS-tagged IPv4 traffic match conditions standard stateless firewall filters...................64 multifield classification example..........................................................................380 limitations on M Series routers...............................378 overview..........................................................................375 requirements and restrictions.................................377
510
Index
multiple standard firewall filters applied as a list example..................................................................165 guidelines for applying......................................164 overview...........................................................157, 161 in a nested configuration example...................................................................173 guidelines for configuring..................................172 overview..................................................................170 multiple stateless firewall filters applied as a list filter list name.......................................................163
N
naming conventions three-color policer......................................................400 next term action......................................................................25 noncontiguous address filter..............................................37 notice icons defined............................................................xxiv
O
output files firewall log output file..................................................117 output-policer statement................................................486 output-three-color statement........................................487
P
packet evaluation service filters..................................................................228 simple filters..................................................................249 standard stateless firewall filters............................20 packet loss priority policer actions overview..................................................................297 packets handling packet fragments (configuration editor)...........................................................................152 parentheses, in syntax descriptions..............................xxvi peak-burst-size statement..............................................488 peak-information-rate statement................................490 physical interface policer configuration statement for....................................492 example..........................................................................429 overview..........................................................................427 physical-interface-filter statement................................491 physical-interface-policer statement..........................492 ping command (stateless firewall filter).............147, 357 explanation............................................................147, 357
pipe ( | ) bit-field logical operator..............................................32 plus sign (+), bit-field logical operator...........................32 policer and firewall filter order of operations............................................304 applying to a logical interface................................493 bandwidth limit.............................................................316 burst size calculation of........................................................323 burst-size limit...............................................................316 color markings and actions......................................318 filter-specific.................................................................352 guidelines for applying...............................................316 overview..........................................................................297 prefix-specific action configuration scenarios...................................369 example..................................................................362 overview.................................................................359 statement hierarchy...................................................305 supported standards.................................................326 term-specific.................................................................352 traffic-limiting criteria.................................................316 types..................................................................................301 policer actions forwarding class overview..................................................................297 packet loss-priority overview..................................................................297 policer overhead for rate shaping example...........................................................................391 overview.........................................................................390 policer statement configuring.....................................................................494 stateless firewall filter action.................................495 policer, hierarchical and firewall filter order of operations............................................304 bandwidth limit.............................................................316 burst size guidelines for calculating.................................323 burst-size limit...............................................................316 color markings and actions......................................318 configuration and application overview..............314 configuration statement for.....................................475 aggregate...............................................................457 premium................................................................498 example..........................................................................439
511
overview........................................................301, 316, 437 single token bucket algorithm.................................319 policer, Layer 2 hierarchical policer configuration overview......................................314 example.................................................................439 overview..................................................................437 three-color policer overview.................................................................446 two-color policer overview.................................................................444 policer, multifield classification example..........................................................................380 limitations on M Series routers...............................378 overview..........................................................................375 requirements and restrictions.................................377 policer, single-rate three-color bandwidth limit.............................................................316 burst size guidelines for calculating.................................323 burst-size limit...............................................................316 color markings and actions......................................318 color modes..................................................................400 configuration and application overview...............311 dual token bucket algorithm....................................321 example..........................................................................402 logical interface (aggregate) overview..................................................................415 naming conventions..................................................400 overview.................................................................301, 401 physical interface policer overview..................................................................427 supported platforms..................................................399 policer, single-rate two-color bandwidth limit.............................................................316 burst size guidelines for calculating.................................323 burst-size limit...............................................................316 color markings and actions......................................318 configuration and application overview.............307 example................................................................328, 334 logical bandwidth example.................................................................345 overview.................................................................344 logical interface (aggregate) example..................................................................416 overview..................................................................415 overview.................................................................301, 327
physical interface policer example.................................................................429 overview..................................................................427 prefix-specific action configuration scenarios...................................369 example..................................................................362 overview.................................................................359 single token bucket algorithm.................................319 policer, two-rate three-color bandwidth limit.............................................................316 burst size guidelines for calculating.................................323 burst-size limit...............................................................316 color markings and actions......................................318 color modes..................................................................400 configuration and application overview...............311 dual-rate dual token bucket algorithm................321 example..........................................................................409 logical interface (aggregate) example.........................................................421, 447 overview..................................................................415 naming conventions..................................................400 overview................................................................301, 408 physical interface policer overview..................................................................427 supported platforms..................................................399 policers for stateless firewall filters..............................143, 353 policy framework.......................................................................3 port number (TCP or UDP), source or destination stateless firewall filter match conditions IPv4 traffic...............................................................48 IPv6 traffic................................................................57 Layer 2 bridging traffic.........................................75 MPLS-tagged IPv4 traffic..................................64 VPLS traffic.............................................................66 prefix list statement firewall filter match condition...................................97 prefix-action statement configuration scenarios............................................369 configuring.....................................................................496 example..........................................................................362 firewall filter action.....................................................497 overview..........................................................................359 prefix-list statement usage guidelines.............................................................37 prefix-specific action filter-specific.................................................................362 term-specific.................................................................362
512
Index
prefix-specific counting and policing configuration scenarios............................................369 example..........................................................................362 overview..........................................................................359 premium statement hierarchical policer.....................................................498 protocol-independent traffic match conditions standard stateless firewall filters....................47
R
rate-shaping configuring policer overhead for example..................................................................391 overview.................................................................390 RED drop profiles..................................................................375 reverse-path forwarding (RPF) stateless firewall filters example...................................................................134 with an input firewall log or count.................114 router data flow..........................................................................3 Routing Engine handling packet fragments for (configuration editor)...........................................................................152 protecting against DoS attacks.....................143, 353 protecting against untrusted services and protocols (configuration editor).........................118 Routing Engine traffic from trusted sources stateless firewall filters accepting OSPF packets from addresses in a prefix............................................................132 blocking Telnet and SSH access....................123 blocking TFTP access........................................129 example: accepting DHCP packets with specific addresses..........................................134 routing solutions filtering unwanted services and protocols..........118 handling packet fragments (configuration editor)...........................................................................152 protecting against DoS attacks.....................143, 353 RPF firewall log and count..................................................114
S
sample configurations firewall filter configurations............121, 147, 156, 357
service filters actions nonterminating.....................................................241 terminating.............................................................241 configuration example...............................................242 filtering packets received on a set of interface groups configuring filters.................................................186 guidelines for applying...............................................232 guidelines for configuring.........................................230 interface-specific counters example..................................................................180 guidelines for applyng.......................................180 guidelines for configuring..................................179 overview...................................................................177 interface-specific policers guidelines for applying......................................180 guidelines for configuring..................................179 overview...................................................................177 match conditions.........................................................235 overview.......................................................................7, 227 packet evaluation........................................................228 service-filter statement firewall............................................................................290 show firewall command...........................121, 147, 156, 357 show firewall filter protect-RE command.........148, 358 show firewall log command..............................................122 show interfaces lo0 command..............................143, 353 show interfaces policers command..............................416 show log command...............................................................117 show route summary command.............................122, 157 explanation.....................................................................122 simple filters configuration example...............................................255 guidelines for applying..............................................254 guidelines for configuring..........................................251 overview......................................................................7, 249 packet evaluation........................................................249 simple-filter statement firewall..............................................................................291 single token bucket algorithm..........................................319 single-rate statement........................................................499 single-rate three-color policer and firewall filter order of operations............................................304 bandwidth limit.............................................................316 burst-size limit...............................................................316 color markings and actions......................................318 color modes..................................................................400
513
configuration and application summary..............311 dual token bucket algorithm....................................321 example..........................................................................402 Layer 2 policer overview.................................................................446 logical interface (aggregate) overview..................................................................415 naming conventions..................................................400 overview........................................................301, 316, 401 physical interface policer overview..................................................................427 supported platforms..................................................399 single-rate two-color policer and firewall filter order of operations............................................304 at Layer 2 overview.................................................................444 burst-size limit...............................................................316 color markings and actions......................................318 configuration and application overview.............307 example................................................................328, 334 logical bandwidth example.................................................................345 overview.................................................................344 logical interface (aggregate) example..................................................................416 overview..................................................................415 overview.........................................................301, 316, 327 physical interface policer example.................................................................429 overview..................................................................427 prefix-specific action configuration scenarios...................................369 example..................................................................362 overview.................................................................359 single token bucket algorithm.................................319 ssh command.........................................................................122 standard stateless firewall filters accounting applying firewall filter accounting profiles.................................................................212 configuring firewall filter accounting profiles..................................................................211 example...................................................................213 overview...................................................................211 actions nonterminating......................................................82 terminating...............................................................81 applying.............................................................................26
configuring.........................................................................21 actions.......................................................................25 filter names and options....................................23 filter terms................................................................23 match conditions..................................................24 protocol families....................................................22 examples filter-based forwarding....................................206 logging for standard stateless firewall filter term......................................................................222 filter-based forwarding configuring for IPv4 or IPv6 traffic................201 configuring for MPLS-tagged IPv4 traffic...................................................................201 example.................................................................206 overview..................................................................199 filtering packets received on a set of interface groups assigning logical interfaces to groups.........185 configuring filters.................................................186 overview..................................................................185 filtering packets received on a specific interface group applying filters.......................................................187 example..................................................................188 filtering packets received on a specific interface set configuring filters.................................................193 overview..................................................................192 filtering packets received on an interface set defining the interfaces in the set...................192 interface-specific counters example..................................................................180 interface-specific policers guidelines for applying......................................180 guidelines for configuring..................................179 overview...................................................................177 logging example..................................................................222 system logging of firewall facility events..................................................................219 system logging of packet headers.................221 system logging overview...................................218 multifield classification example.................................................................380 limitations on M Series routers......................378 overview..................................................................375 requirements and restrictions........................377
514
Index
multiple filters applied as a list example..................................................................165 guidelines for applying......................................164 overview...........................................................157, 161 multiple filters in a nested configuration example...................................................................173 guidelines for configuring..................................172 overview..................................................................170 overview.............................................................................19 packet evaluation..........................................................20 standards supported for filtering....................................................14 supported for policing...............................................326 stateless firewall filter supported standards.....................................................14 stateless firewall filters accepting Routing Engine traffic from trusted sources example: blocking TCP access.......................137 example: blocking Telnet and SSH access...........................................................97, 149 actions..................................................................................11 firewall filters in logical systems...................262 service filters........................................................230 standard stateless firewall filters....................25 unsupported in logical systems.....................275 actions, nonterminating service filters..........................................................241 simple filters.........................................................253 standard stateless firewall filters...................82 actions, terminating service filters..........................................................241 simple filters.........................................................253 standard stateless firewall filters....................81 application points overview.....................................................................12 service filters.........................................................232 simple filters.........................................................254 applying to an interface (configuration editor).................................................................143, 353 basic use filtering data packets...........................................29 filtering local packets..........................................29 handling packet fragments..............................152 displaying configurations.................121, 147, 156, 357 displaying statistics...........................................148, 358
examples accepting DHCP packets with specific addresses...........................................................134 accepting OSPF packets from addresses in a prefix............................................................132 accepting packets with specific IPv6 TCP flags......................................................................149 accounting for standard stateless firewall filters.....................................................................213 applying lists of standard firewall filters to a single interface.............................................165 blocking TCP access...........................................137 blocking Telnet and SSH access.............97, 123 blocking TFTP access........................................129 counting accepted and rejected packets...............................................................100 counting and discarding IP options packets...............................................................103 counting and sampling accepted packets.................................................................114 counting IP option packets.............................106 matching on destination port and protocol.................................................................91 matching on IPv6 flags.......................................89 matching on unrelated fields...........................94 nesting references to multiple firewall filters.....................................................................173 setting rate limits based on destination class.....................................................................158 setting rate limits for traffic received on an interface set......................................................193 setting the DSCP bit to zero...............................111 filter names service filters........................................................230 simple filters..........................................................251 filter names and options standard stateless firewall filters....................23 filter terms...........................................................................9 service filters........................................................230 simple filters..........................................................251 standard stateless firewall filters....................23 filter-based forwarding applying filters to interfaces................204, 205 filtering router transit traffic overview....................................................................29 filtering Routing Engine traffic overview....................................................................29 firewall filter statements unsupported in logical systems.....................273
515
handling packet fragments overview..................................................................152 handling packet fragments (configuration editor)...........................................................................152 hardware requirements for applying service filters.........................................................232 simple filters.........................................................254 in logical systems applying..................................................................262 configuring.............................................................262 overview..................................................................261 interface-specific names filter list name.......................................................163 logical systems unsupported firewall filter actions...............275 unsupported firewall filter statements........................................................273 match condition categories matching on address classes...........................45 matching on address prefixes...........................37 matching on bit-field values.............................32 matching on numeric values..............................31 matching on text strings......................................31 match conditions............................................................10 firewall filters in logical systems...................262 service filters...............................................230, 235 simple filters..........................................................251 standard stateless firewall filters....................24 multiple filters applied as a list filter list name.......................................................163 overview...............................................................................5 policers for.............................................................143, 353 protecting the Routing Engine against TCP floods..................................................................143, 353 protecting the Routing Engine against untrusted protocols (configuration editor).........................118 protecting the Routing Engine against untrusted services (configuration editor)............................118 protocol families...............................................................7 firewall filters in logical systems...................262 service filters........................................................230 simple filters..........................................................251 standard stateless firewall filters....................22 reverse-path forwarding (RPF) example...................................................................134 with an input firewall log or count.................114 sample terms, to filter fragments...........................152 sample terms, to filter services and protocols......................................................................118
service filters..................................................................227 statement hierarchy for applying..................232 statement hierarchy for configuring............230 simple filters..................................................................249 standard stateless firewall filters.............................19 statement hierarchy applying simple filters.......................................254 configuring simple filters...................................251 type overview.......................................................................7 types......................................................................................6 verifying actions............................................................122 verifying configuration.......................121, 147, 156, 357 verifying flood protection.................................147, 357 verifying packet logging..............................................122 statement hierarchy service filters applying..................................................................232 configuring............................................................230 simple filters applying..................................................................254 configuring .............................................................251 stateless firewall filters applying filters to interfaces...........................205 statistics stateless firewall filters....................................148, 358 support, technical See technical support supported platforms three-color policer......................................................399 syntax conventions...............................................................xxv
T
TCP policers...................................................................143, 353 technical support contacting JTAC...........................................................xxvi telnet command...........................................................147, 357 term statement firewall.............................................................................292 term-specific counting and policing set.........................................362 policer..............................................................................352 three-color policer color modes..................................................................400 naming conventions..................................................400 single-rate example.................................................................402 overview..................................................................401
516
Index
supported platforms..................................................399 two-rate................................................................401, 408 example.................................................................409 overview................................................................408 See also policer, single-rate three-color See also policer, two-rate three-color three-color-policer statement.........................................501 stateless firewall filter action.................................502 token bucket algorithm dual bucket.....................................................................321 dual-rate dual bucket.................................................321 single bucket..................................................................319 traffic sampling show log command.............................................117 traffic-limiting criteria policers.............................................................................316 two-rate statement............................................................503 two-rate three-color policer bandwidth limit.............................................................316 burst-size limit...............................................................316 color markings and actions......................................318 color modes..................................................................400 configuration and application overview...............311 dual-rate dual token bucket algorithm................321 example..........................................................................409 Layer 2 policer overview.................................................................446 logical interface (aggregate) example.........................................................421, 447 overview..................................................................415 naming conventions..................................................400 overview.......................................................301, 316, 408 physical interface policer overview..................................................................427 supported platforms..................................................399 two-rate three-color-policer and firewall filter order of operations............................................304
stateless firewall filters.....................121, 147, 156, 357 stateless firewall statistics.............................148, 358 VPLS traffic match conditions standard stateless firewall filters...................66
V
verification firewall filter handles fragments.............................157 OSPF policy....................................................................281 stateless firewall filter actions.................................122 stateless firewall filter flood protection...........................................................147, 357 stateless firewall filter operation............................122
517
518
H
hierarchical-policer statement........................................475
Index of Statements and Commands

A
accounting-profile statement.........................................283 action statement.................................................................456 aggregate statement hierarchical policer......................................................457
if-exceeding statement hierarchical policer......................................................477 single-rate two-color policer...................................478 input-hierarchical-policer statement...........................479 input-policer statement....................................................479 input-three-color statement...........................................480 interface-set statement....................................................289 interface-specific statement...........................................290
L
layer2-policer statement...................................................481 hierarchical policing.....................................................314 load-balance-group statement.....................................482 logical interface-policer statement..............................483 logical-bandwidth-policer statement.........................482 loss-priority statement stateless firewall filter action.................................484
B
bandwidth-limit statement hierarchical policer.....................................................458 policer..............................................................................459 bandwidth-percent statement policer...............................................................................461 burst-size-limit statement...............................................464 hierarchical policer.....................................................463
O
output-policer statement................................................486 output-three-color statement........................................487
P
peak-burst-size statement..............................................488 peak-information-rate statement................................490 physical-interface-filter statement................................491 physical-interface-policer statement..........................492 policer applying to a logical interface................................493 policer statement configuring.....................................................................494 stateless firewall filter action.................................495 prefix-action statement configuring.....................................................................496 firewall filter action.....................................................497 premium statement hierarchical policer.....................................................498
C
color-aware statement.....................................................466 color-blind statement........................................................467 committed-burst-size statement.................................468 committed-information-rate statement....................470
E
enhanced-mode statement firewall.............................................................................284 excess-burst-size statement...........................................472
F
family statement firewall filter...................................................................285 filter statement firewall.............................................................................288 filter-specific statement....................................................473 overview......................................................352, 359, 362 firewall statement...............................................................289 forwarding-class statement stateless firewall filter action..................................474
S
service-filter statement firewall............................................................................290 show interfaces policers command..............................416 show log command...............................................................117 simple-filter statement firewall..............................................................................291
519
single-rate statement........................................................499
T
term statement firewall.............................................................................292 three-color-policer statement.........................................501 stateless firewall filter action.................................502 two-rate statement............................................................503
520

Config Guide Firewall Policer

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Config Guide Firewall Policer

Загружено:

Авторское право:

Доступные форматы

Junos OS

Firewall Filter and Policer Configuration Guide

Copyright 2011, Juniper Networks, Inc.

END USER LICENSE AGREEMENT

Copyright 2011, Juniper Networks, Inc.

Abbreviated Table of Contents

Stateless Firewall Filters

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

Copyright 2011, Juniper Networks, Inc.

Stateless Firewall Filters

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

Standard Firewall Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Standard Firewall Filter Match Conditions Overview . . . . . . . . . . . . . . . . . . . 31

Copyright 2011, Juniper Networks, Inc.

Standard Firewall Filter Match Conditions and Actions . . . . . . . . . . . . . . . . . 47

Standard Firewall Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

Copyright 2011, Juniper Networks, Inc.

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

Service Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Simple Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Copyright 2011, Juniper Networks, Inc.

Stateless Firewall Filter Configuration in Logical Systems . . . . . . . . . . . . . 261

Summary of Stateless Firewall Filter Configuration Statements . . . . . . . 283

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

simple-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Copyright 2011, Juniper Networks, Inc.

Single-Rate Two-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . 327

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

Three-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Logical and Physical Interface Policer Configuration . . . . . . . . . . . . . . . . . . 415

Layer 2 Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Copyright 2011, Juniper Networks, Inc.

Summary of Policer Configuration Statements . . . . . . . . . . . . . . . . . . . . . . 455

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

Copyright 2011, Juniper Networks, Inc.

Stateless Firewall Filters

Standard Firewall Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Stateless Firewall Filter Configuration in Logical Systems . . . . . . . . . . . . . 261

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

Copyright 2011, Juniper Networks, Inc.

Stateless Firewall Filters

Standard Firewall Filter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Standard Firewall Filter Match Conditions Overview . . . . . . . . . . . . . . . . . . . 31

Standard Firewall Filter Match Conditions and Actions . . . . . . . . . . . . . . . . . 47

Standard Firewall Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Service Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Copyright 2011, Juniper Networks, Inc.

Junos OS 11.4 Firewall Filter and Policer Configuration Guide

Table 26: Nonterminating Actions for Service Filters . . . . . . . . . . . . . . . . . . . . . . 242

Simple Filter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Stateless Firewall Filter Configuration in Logical Systems . . . . . . . . . . . . . 261

Single-Rate Two-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . 327

Three-Color Policer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Copyright 2011, Juniper Networks, Inc.

About This Guide