- 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
-
Firewall Filter Match Conditions Based on Bit-Field Values
Match Conditions for Bit-Field Values
Table 1 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.
Bit-Field Match Condition | Match Values | Protocol Families for Standard Stateless Firewall Filters | Protocol Families for Service Filters |
---|---|---|---|
fragment-flags flags | Hexadecimal values or text aliases for the three-bit IP fragmentation flags field in the IP header. | family inet | family inet |
fragment-offset value | Hexadecimal values or text aliases for the 13-bit fragment offset field in the IP header. | family inet | family inet |
tcp-flags value† | Hexadecimal values or text aliases for the low-order 6 bits of the 8-bit TCP flags field in the TCP header. | family inetfamily inet6family vplsfamily bridge | family inetfamily 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 2 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.
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.
Match Condition | Description | Protocol Families for Standard Stateless Firewall Filters | Protocol Families for Service Filters |
---|---|---|---|
first-fragment | Text alias for the bit-field match condition fragment-offset 0, which indicates the first fragment of a fragmented packet. | family inet | family inet |
is-fragment | Text alias for the bit-field match condition fragment-offset 0 except, which indicates a trailing fragment of a fragmented packet. | family inet | family inet |
tcp-established | 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. | family inetfamily inet6 | — |
tcp-initial | 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. | family inetfamily inet6 | — |
Logical Operators for Bit-Field Values
Table 3 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.
Precedence Order | Bit-Field Logical Operator | Description |
---|---|---|
1 | (complex-match-condition) | Grouping—The complex match condition is evaluated before any operators outside the parentheses are applied. |
2 | ! match-condition | Negation—A match occurs if the match condition is false. |
3 | match-condition-1 & match-condition-2ormatch-condition-1 + match-condition-2 | Logical AND—A match occurs if both match conditions are true. |
4 | match-condition-1 | match-condition-2ormatch-condition-1 , match-condition-2 | Logical OR—A match occurs if either match condition is true. |
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 bit—You 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:
content_copy zoom_out_map[edit firewall family inet filter filter_tcp_rst_number term term1 from] user@host# set tcp-flags 0x04
Text alias to specify a single bit—You 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:
content_copy zoom_out_map[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 bits—When 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:
content_copy zoom_out_map[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 matches—You 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:
content_copy zoom_out_map[edit firewall family inet filter reset_or_not_initial_packet term term6 from] 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 (| 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 (& 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 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.