- play_arrow Understanding and Configuring Junos Routing Policies
- play_arrow Overview
- Policy Framework Overview
- Comparison of Routing Policies and Firewall Filters
- Prefix Prioritization Overview
- FIB Prefix Prioritization
- Accounting of the Policer Overhead Attribute at the Interface Level
- Configuring the Accounting of Policer Overhead in Interface Statistics
- Understanding Routing Policies
- Protocol Support for Import and Export Policies
- Example: Applying Routing Policies at Different Levels of the BGP Hierarchy
- Default Routing Policies
- Example: Configuring a Conditional Default Route Policy
- play_arrow Evaluating Routing Policies Using Match Conditions, Actions, Terms, and Expressions
- How a Routing Policy Is Evaluated
- Categories of Routing Policy Match Conditions
- Routing Policy Match Conditions
- Route Filter Match Conditions
- Actions in Routing Policy Terms
- Summary of Routing Policy Actions
- Example: Configuring a Routing Policy to Advertise the Best External Route to Internal Peers
- Example: Configuring BGP to Advertise Inactive Routes
- Example: Using Routing Policy to Set a Preference Value for BGP Routes
- Example: Enabling BGP Route Advertisements
- Example: Rejecting Known Invalid Routes
- Example: Using Routing Policy in an ISP Network
- Understanding Policy Expressions
- Understanding Backup Selection Policy for OSPF Protocol
- Configuring Backup Selection Policy for the OSPF Protocol
- Configuring Backup Selection Policy for IS-IS Protocol
- Example: Configuring Backup Selection Policy for the OSPF or OSPF3 Protocol
- play_arrow Evaluating Complex Cases Using Policy Chains and Subroutines
- play_arrow Configuring Route Filters and Prefix Lists as Match Conditions
- Understanding Route Filters for Use in Routing Policy Match Conditions
- Understanding Route Filter and Source Address Filter Lists for Use in Routing Policy Match Conditions
- Understanding Load Balancing Using Source or Destination IP Only
- Configuring Load Balancing Using Source or Destination IP Only
- Walkup for Route Filters Overview
- Configuring Walkup for Route Filters to Improve Operational Efficiency
- Example: Configuring Route Filter Lists
- Example: Configuring Walkup for Route Filters Globally to Improve Operational Efficiency
- Example: Configuring Walkup for Route Filters Locally to Improve Operational Efficiency
- Example: Configuring a Route Filter Policy to Specify Priority for Prefixes Learned Through OSPF
- Example: Configuring the MED Using Route Filters
- Example: Configuring Layer 3 VPN Protocol Family Qualifiers for Route Filters
- Understanding Prefix Lists for Use in Routing Policy Match Conditions
- Example: Configuring Routing Policy Prefix Lists
- Example: Configuring the Priority for Route Prefixes in the RPD Infrastructure
- Configuring Priority for Route Prefixes in RPD Infrastructure
- play_arrow Configuring AS Paths as Match Conditions
- Understanding AS Path Regular Expressions for Use as Routing Policy Match Conditions
- Example: Using AS Path Regular Expressions
- Understanding Prepending AS Numbers to BGP AS Paths
- Example: Configuring a Routing Policy for AS Path Prepending
- Understanding Adding AS Numbers to BGP AS Paths
- Example: Advertising Multiple Paths in BGP
- Improve the Performance of AS Path Lookup in BGP Policy
- play_arrow Configuring Communities as Match Conditions
- Understanding BGP Communities, Extended Communities, and Large Communities as Routing Policy Match Conditions
- Understanding How to Define BGP Communities and Extended Communities
- How BGP Communities and Extended Communities Are Evaluated in Routing Policy Match Conditions
- Example: Configuring Communities in a Routing Policy
- Example: Configuring Extended Communities in a Routing Policy
- Example: Configuring BGP Large Communities
- Example: Configuring a Routing Policy Based on the Number of BGP Communities
- Example: Configuring a Routing Policy That Removes BGP Communities
- play_arrow Increasing Network Stability with BGP Route Flapping Actions
- play_arrow Tracking Traffic Usage with Source Class Usage and Destination Class Usage Actions
- Understanding Source Class Usage and Destination Class Usage Options
- Source Class Usage Overview
- Guidelines for Configuring SCU
- System Requirements for SCU
- Terms and Acronyms for SCU
- Roadmap for Configuring SCU
- Roadmap for Configuring SCU with Layer 3 VPNs
- Configuring Route Filters and Source Classes in a Routing Policy
- Applying the Policy to the Forwarding Table
- Enabling Accounting on Inbound and Outbound Interfaces
- Configuring Input SCU on the vt Interface of the Egress PE Router
- Mapping the SCU-Enabled vt Interface to the VRF Instance
- Configuring SCU on the Output Interface
- Associating an Accounting Profile with SCU Classes
- Verifying Your SCU Accounting Profile
- SCU Configuration
- SCU with Layer 3 VPNs Configuration
- Example: Grouping Source and Destination Prefixes into a Forwarding Class
- play_arrow Avoiding Traffic Routing Threats with Conditional Routing Policies
- Conditional Advertisement and Import Policy (Routing Table) with certain match conditions
- Conditional Advertisement Enabling Conditional Installation of Prefixes Use Cases
- Example: Configuring a Routing Policy for Conditional Advertisement Enabling Conditional Installation of Prefixes in a Routing Table
- play_arrow Protecting Against DoS Attacks by Forwarding Traffic to the Discard Interface
- play_arrow Improving Commit Times with Dynamic Routing Policies
- play_arrow Testing Before Applying Routing Policies
-
- play_arrow Configuring Traffic Policers
- play_arrow Understanding Traffic Policers
- Policer Implementation Overview
- ARP Policer Overview
- Example: Configuring ARP Policer
- Understanding the Benefits of Policers and Token Bucket Algorithms
- Determining Proper Burst Size for Traffic Policers
- Controlling Network Access Using Traffic Policing Overview
- Traffic Policer Types
- Order of Policer and Firewall Filter Operations
- Understanding the Frame Length for Policing Packets
- Supported Standards for Policing
- Hierarchical Policer Configuration Overview
- Understanding Enhanced Hierarchical Policers
- Packets-Per-Second (pps)-Based Policer Overview
- Guidelines for Applying Traffic Policers
- Policer Support for Aggregated Ethernet Interfaces Overview
- Example: Configuring a Physical Interface Policer for Aggregate Traffic at a Physical Interface
- Firewall and Policing Differences Between PTX Series Packet Transport Routers and T Series Matrix Routers
- Hierarchical Policers on ACX Series Routers Overview
- Guidelines for Configuring Hierarchical Policers on ACX Series Routers
- Hierarchical Policer Modes on ACX Series Routers
- Processing of Hierarchical Policers on ACX Series Routers
- Actions Performed for Hierarchical Policers on ACX Series Routers
- Configuring Aggregate Parent and Child Policers on ACX Series Routers
- play_arrow Configuring Policer Rate Limits and Actions
- play_arrow Configuring Layer 2 Policers
- Hierarchical Policers
- Configuring a Policer Overhead
- Two-Color and Three-Color Policers at Layer 2
- Layer 2 Traffic Policing at the Pseudowire Overview
- Configuring a Two-Color Layer 2 Policer for the Pseudowire
- Configuring a Three-Color Layer 2 Policer for the Pseudowire
- Applying the Policers to Dynamic Profile Interfaces
- Attaching Dynamic Profiles to Routing Instances
- Using Variables for Layer 2 Traffic Policing at the Pseudowire Overview
- Configuring a Policer for the Complex Configuration
- Creating a Dynamic Profile for the Complex Configuration
- Attaching Dynamic Profiles to Routing Instances for the Complex Configuration
- Verifying Layer 2 Traffic Policers on VPLS Connections
- Understanding Policers on OVSDB-Managed Interfaces
- Example: Applying a Policer to OVSDB-Managed Interfaces
- play_arrow Configuring Two-Color and Three-Color Traffic Policers at Layer 3
- Two-Color Policer Configuration Overview
- Basic Single-Rate Two-Color Policers
- Bandwidth Policers
- Prefix-Specific Counting and Policing Actions
- Policer Overhead to Account for Rate Shaping in the Traffic Manager
- Three-Color Policer Configuration Overview
- Applying Policers
- Three-Color Policer Configuration Guidelines
- Basic Single-Rate Three-Color Policers
- Basic Two-Rate Three-Color Policers
- Example: Configuring a Two-Rate Three-Color Policer
- play_arrow Configuring Logical and Physical Interface Traffic Policers at Layer 3
- play_arrow Configuring Policers on Switches
- Overview of Policers
- Traffic Policer Types
- Understanding the Use of Policers in Firewall Filters
- Understanding Tricolor Marking Architecture
- Configuring Policers to Control Traffic Rates (CLI Procedure)
- Configuring Tricolor Marking Policers
- Understanding Policers with Link Aggregation Groups
- Understanding Color-Blind Mode for Single-Rate Tricolor Marking
- Understanding Color-Aware Mode for Single-Rate Tricolor Marking
- Understanding Color-Blind Mode for Two-Rate Tricolor Marking
- Understanding Color-Aware Mode for Two-Rate Tricolor Marking
- Example: Using Two-Color Policers and Prefix Lists
- Example: Using Policers to Manage Oversubscription
- Assigning Forwarding Classes and Loss Priority
- Configuring Color-Blind Egress Policers for Medium-Low PLP
- Configuring Two-Color and Three-Color Policers to Control Traffic Rates
- Verifying That Two-Color Policers Are Operational
- Verifying That Three-Color Policers Are Operational
- Troubleshooting Policer Configuration
- Troubleshooting Policer Configuration
-
- play_arrow Configuration Statements and Operational Commands
- play_arrow Troubleshooting
- play_arrow Knowledge Base
-
Guidelines for Configuring Firewall Filters
This topic covers the following information:
Statement Hierarchy for Configuring 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. For an IPv6 standard firewall filter, the family inet6
statement is mandatory.
firewall { family family-name { filter filter-name { accounting-profile name; instance-shared; interface-specific; physical-interface-filter; term term-name { filter filter-name; } term term-name { from { match-conditions; ip-version ip-version { 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]
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 (or switch) by way of the tunnel.
On ACX7100 platforms, VPLS firewall filters are configured under
family
ethernet-switching
and not under family
VPLS
. Management filters are configured at family
inet
or inet6
and the syntax is of this
form:
set interfaces re0:mgmt-0 unit logical-unit-number family family-name
filter input filter-name.
Firewall Filter Protocol Families
A 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 any
—To filter protocol-independent traffic.family inet
—To filter Internet Protocol version 4 (IPv4) traffic.family inet6
—To filter Internet Protocol version 6 (IPv6) traffic.family mpls
—To filter MPLS traffic.family vpls
—To filter virtual private LAN service (VPLS) traffic.family ccc
—To filter Layer 2 circuit cross-connection (CCC) traffic.family bridge
—To filter Layer 2 bridging traffic for MX Series 3D Universal Edge Routers only.family ethernet-switching
—To filter Layer 2 (Ethernet) traffic.
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.
For bridge family filter, the ip-protocol match criteria is supported only for IPv4 and not for IPv6. This is applicable for line cards that support the Junos Trio chipset such as the MX 3D MPC line cards.
Firewall Filter Names and Options
Under the family family-name
statement, you can include filter filter-name
statements to create and name 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
instance-shared
(MX Series routers with Modular Port Concentrators (MPCS) only)interface-specific
physical-interface-filter
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.
Firewall Filter Match Conditions
Firewall filter match conditions are specific to the type of traffic being filtered.
With the exception of MPLS-tagged IPv4 or IPv6 traffic, you
specify the term’s match conditions under the from
statement. For MPLS-tagged IPv4 traffic, you specify the term’s
IPv4 address-specific match conditions under the ip-version ipv4
statement and the term’s IPv4 port-specific match conditions
under the protocol (tcp | udp)
statement.
For MPLS-tagged IPv6 traffic, you specify the term’s IPv6
address-specific match conditions under the ip-version ipv6
statement and the term’s IPv6 port-specific match conditions
under the protocol (tcp | udp)
statement.
Table 1 describes the types of traffic for which you can configure firewall filters.
Traffic Type | Hierarchy Level at Which Match Conditions Are Specified |
---|---|
Protocol-independent |
For the complete list of match conditions, see Firewall Filter Match Conditions for Protocol-Independent Traffic. |
IPv4 |
For the complete list of match conditions, see Firewall Filter Match Conditions for IPv4 Traffic. |
IPv6 |
For the complete list of match conditions, see Firewall Filter Match Conditions for IPv6 Traffic. |
MPLS |
For the complete list of match conditions, see Firewall Filter Match Conditions for MPLS Traffic. |
IPv4 addresses in MPLS flows |
For the complete list of match conditions, see Firewall Filter Match Conditions for MPLS-Tagged IPv4 or IPv6 Traffic. |
IPv4 ports in MPLS flows |
For the complete list of match conditions, see Firewall Filter Match Conditions for MPLS-Tagged IPv4 or IPv6 Traffic. |
IPv6 addresses in MPLS flows |
For the complete list of match conditions, see Firewall Filter Match Conditions for MPLS-Tagged IPv4 or IPv6 Traffic. |
IPv6 ports in MPLS flows |
For the complete list of match conditions, see Firewall Filter Match Conditions for MPLS-Tagged IPv4 or IPv6 Traffic. |
VPLS |
For the complete list of match conditions, see Firewall Filter Match Conditions for VPLS Traffic. |
Layer 2 CCC |
For the complete list of match conditions, see Firewall Filter Match Conditions for Layer 2 CCC Traffic. |
Layer 2 Bridging (MX Series routers and EX Series switches only) |
For the complete list of match conditions, see Firewall Filter Match Conditions for Layer 2 Bridging Traffic. |
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 4291, IP Version 6 Addressing Architecture. For more information about IPv6 addresses, see IPv6 Overview and Supported IPv6 Standards.
Firewall Filter Actions
Under the then
statement for a firewall filter term,
you can specify the actions to be taken on a packet that matches the
term.
Table 2 summarizes the types of actions you can specify in a firewall filter term.
Type of Action | Description | Comment |
---|---|---|
Terminating | Halts all evaluation of a firewall filter for a specific packet. The router (or switch) performs the specified action, and no additional terms are used to examine the packet. You can specify only one terminating action in a firewall
filter term. If you try to specify more than one terminating
action within the filter term then the latest
terminating action will replace the existing
terminating action. 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 | |
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. | All nonterminating actions include an implicit accept action. This accept action is carried out if no other terminating action is configured in the same term. |
Flow control | For standard firewall filters only, the For example, when you configure a term with the nonterminating
action | You cannot configure the A maximum of 1024 Note: On Junos OS Evolved, |