- 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, Actions, and Action Modifiers for EX Series Switches
When you define a firewall filter for an EX Series switch, you define filtering criteria (terms, with match conditions) for the packets and an action (and, optionally, an action modifier) for the switch to take if the packets match the filtering criteria. You can define a firewall filter to monitor IPv4, IPv6, or non-IP traffic.
This topic describes in detail the various match conditions, actions, and action modifiers that you can define in a firewall filter. For information about support for match conditions on various EX Series switches, see Platform Support for Firewall Filter Match Conditions, Actions, and Action Modifiers on EX Series Switches.
Firewall Filter Elements
A firewall filter configuration contains a term, a match condition, an action, and, optionally, an action modifier. Table 1 describes each element in a firewall filter configuration.
Element Name | Description |
|---|---|
Term | Defines the filtering criteria for the packets. Each term in the firewall filter consists of match conditions and an action. You can define a single term or multiple terms in the firewall filter. If you define multiple terms, each term must have a unique name. |
Match condition | Consists of a string (called a match statement) that defines the match condition. Match conditions are the values or fields that a packet must contain. You can define a single match condition or multiple match conditions for a term. You can also opt not to define a match condition. If no match conditions are specified for a term, all packets are matched by default. |
Action | Specifies the action that the switch takes if a packet matches all the criteria specified in the match conditions. |
Action modifier | Specifies one or more actions that the switch takes if a packet matches the match conditions for the specific term. |
Match Conditions Supported on Switches
Based on the type of traffic that you want to monitor, you can configure a firewall filter to monitor IPv4, IPv6, or non-IP traffic. When you configure a firewall filter to monitor a particular type of traffic, ensure that you specify match conditions that are supported for that type of traffic. For information about match conditions supported for a specific type of traffic and switches on which they are supported, see Platform Support for Firewall Filter Match Conditions, Actions, and Action Modifiers on EX Series Switches.
Table 2 describes all the match conditions that are supported for firewall filters on EX Series Switches.
Match Condition | Description |
|---|---|
| IP destination address field, which is the address of the final destination node. |
| IP destination address field, which is the address of the final destination node. |
| IP destination address field, which is the address of the final destination node. |
destination-mac-address mac-address | Destination media access control (MAC) address of the packet. You can define a destination MAC address with a prefix, such as destination-mac-address 00:01:02:03:04:05/24. If no prefix is specified, the default value 48 is used. |
destination-port number | TCP or UDP destination port field. Typically, you specify this match condition in conjunction
with the afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813),radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), xdmcp (177), zephyr-clt (2103), zephyr-hm (2104) |
destination-prefix-list prefix-list | IP destination prefix list field. You can define a list of IP address prefixes under a prefix-list alias for frequent
use. You define this match condition at the |
| The tag field in the Ethernet header. The tag values range from 1 through 4095. The |
| The tag field in the Ethernet header. The tag values range from 1 through 4095. The |
dot1q-user-priority number | User-priority field of the tagged Ethernet packet. User-priority values can range from 0 through 7. For number, you can specify one of the following text synonyms (the field values are also listed):
|
user-vlan-1p-priority number | User-priority field of the tagged Ethernet packet. User-priority values can range from 0 through 7. For number, you can specify one of the following text synonyms (the field values are also listed):
|
dscp number | Specifies the Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant six bits of this byte form the DSCP. You can specify DSCP in hexadecimal, binary, or decimal form. For number, you can specify one of the following text synonyms (the field values are also listed):
|
ether-type value | Ethernet type field of a packet. The value specifies what protocol is being transported in the Ethernet frame. For value, you can specify one of the following text synonyms:
Note: The following match conditions are not supported when ether-type is set to ipv6:
|
fragment-flags fragment-flags | IP fragmentation flags, specified in symbolic or hexadecimal formats. You can specify one of the following options:
|
| gbp-dst-tag | Match the destination tag, for use with micro-segmentation on a VXLAN, as described here: Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN |
| gbp-src-tag | Match the source tag, for use with micro-segmentation on a VXLAN, as described here: Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN |
icmp-code number | ICMP code field. This value or option provides more specific information than icmp-type. Because the value’s meaning depends upon the associated icmp-type, you must specify icmp-type along with icmp-code. For number, you can specify one of the following text synonyms (the field values are also listed). The options are grouped by the ICMP type with which they are associated:
|
icmp-type number | ICMP packet type field. Typically, you specify this match condition in conjunction with
the 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), unreachable (3) |
interface interface-name | Interface on which the packet is received. You can specify the wildcard character (*) as part of an interface name. Note: On devices running Junos OS Evolved, the
Note: The interface match condition is not supported for egress traffic on an EX8200 Virtual Chassis. |
ip-options | Presence of the options field in the IP header. |
ip-version version match_condition(s) | Version of the IP protocol for port and VLAN firewall filters. The value for version can be ipv4 or ipv6. For match_condition(s), you can specify one or more of the following match conditions:
|
is-fragment | If the packet is a trailing fragment, this match condition does not match the first fragment of a fragmented packet. Use two terms to match both first and trailing fragments. Note: Due to a limitation on the EX2300, EX3400, and EX4300 switches, this match condition does not match the last fragment of a fragmented packet when applied to "family ethernet-switching.” |
l2-encap-type llc-non-snap | Match on logical link control (LLC) layer packets for non-Subnet Access Protocol (SNAP) Ethernet Encapsulation type. |
next-header bytes | 8-bit 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), icmp6 (1), igmp (2), ipip (4), ipv6 (41), no-next-header (59), ospf (89), pim (103), routing (43), rsvp (46), sctp (132), tcp (6), udp (17), vrrp (112) |
packet-length bytes | 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. |
| IP precedence. For precedence, you can specify one of the following text synonyms (the field values are also listed): critical-ecp (5), flash (3), flash-override (4), immediate (2), internet-control (6), net-control (7), priority (1), routine (0) |
| IP precedence. For precedence, you can specify one of the following text synonyms (the field values are also listed): critical-ecp (5), flash (3), flash-override (4), immediate (2), internet-control (6), net-control (7), priority (1), routine (0) |
| IPv4 protocol value. For protocols, you can specify one of the following text synonyms: egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4), ospf (89), pim (103), rsvp (46), tcp (6), udp (17) |
| IPv4 protocol value. For protocols, you can specify one of the following text synonyms: egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4), ospf (89), pim (103), rsvp (46), tcp (6), udp (17) |
source-address ip-address | IP source address field, which is the address of the source node sending the packet. For IPv6, the source-address field is 128 bits in length. The filter description syntax supports the text representations for IPv6 addresses that are described in RFC 2373, IP Version 6 Addressing Architecture. |
| IP source address field, which is the address of the source node sending the packet.
You can specify either an IPv4 address ( |
source-mac-address mac-address | Source MAC address. You can define a source MAC address with a prefix, such as source-mac-address 00:01:02:03:04:05/24. If no prefix is specified, the default value 48 is used. |
source-port number | TCP or UDP source-port field. Typically, you specify this match in conjunction
with the |
source-prefix-list prefix-list | IP source prefix list field. You can define a list of IP address prefixes under a prefix-list alias for frequent
use. You define this match condition at the |
tcp-established | TCP packets of an established TCP connection. This condition matches packets other than the first packet of a connection. tcp-established is a synonym for the bit names "(ack | rst)". tcp-established does not implicitly check whether the protocol is TCP. To do so, specify the next-header tcp match condition. |
tcp-flags (flags tcp-initial) | One or more TCP flags:
To specify multiple flags, use logical operators. |
tcp-initial | Matches the first TCP packet of a connection. tcp-initial is a synonym for the bit names "(syn&!ack)". tcp-initial does not implicitly check whether the protocol is TCP. To do so,
specify the |
traffic-class number | Specifies the DSCP code point for a packet. |
ttl value | TTL type to match. The value ranges from 1 through 255. |
| The VLAN that is associated with the packet. For vlan-id, you can specify either the VLAN ID or a VLAN range. The vlan match condition and the dot1q-tag match condition are mutually exclusive. |
| The VLAN that is associated with the packet. For vlan-id, you can specify either the VLAN ID or a VLAN range. The vlan match condition and the user-vlan-id match condition are mutually exclusive. |
Actions for Firewall Filters
You can define an action for the switch to take if a packet matches the filtering criteria defined in a match condition. Table 3 describes the actions supported in a firewall filter configuration.
Action | Description |
|---|---|
accept | Accept a packet. |
discard | Discard a packet silently without sending an Internet Control Message Protocol (ICMP) message. |
reject message-type | Discard a packet, and send the ICMPv4 message (type 3) destination unreachable. You can log the rejected packets if you configure the syslog action modifier. You can specify one of the following message codes: administratively-prohibited (default), bad-host-tos, bad-network-tos, host-prohibited, host-unknown, host-unreachable, network-prohibited, network-unknown, network-unreachable, port-unreachable, precedence-cutoff, precedence-violation, protocol-unreachable, source-host-isolated, source-route-failed, tcp-reset. If you specify tcp-reset, a TCP reset is returned if the packet is a TCP packet. Otherwise nothing is returned. If you do not specify a message type, the ICMP notification destination unreachable is sent with the default message communication administratively filtered. |
routing-instance routing-instance-name | Forward matched packets to a virtual routing instance. Note: EX4200 switches do not support firewall-filter-based redirection to the default routing instance. |
vlan vlan-name | Forward matched packets to a specific VLAN. Ensure that you specify the VLAN name or VLAN ID and not a VLAN range, because the vlan action does not support the vlan-range option. Note: If you have defined a VLAN that is enabled for dot1q tunneling, then that particular VLAN is not supported as an action (using the vlan vlan-name action) for an ingress VLAN firewall filter. |
Action Modifiers for Firewall Filters
In addition to the actions described in Table 3, you can define action modifiers in a firewall filter configuration for a switch if packets match the filtering criteria defined in the match condition. Table 4 describes the action modifiers supported in a firewall filter configuration.
Action Modifier | Description |
|---|---|
analyzer analyzer-name | Mirror port traffic to a specified destination port or VLAN that is connected to a protocol
analyzer application. Mirroring copies all packets seen on one switch port to a network monitoring
connection on another switch port. The analyzer name must be configured under Note: analyzer is not a supported action modifier for a management interface. Note: On EX4500 switches, you can configure only one analyzer and include it in a firewall filter. If you configure multiple analyzers, you cannot include any one of those analyzers in a firewall filter. |
| Change the DSCP value for matched packets to the DSCP value specified with this action modifier. number specifies the Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant six bits of this byte form the DSCP. You can specify DSCP in hexadecimal, binary, or decimal form. For number, you can specify one of the following text synonyms (the field values are also listed):
|
count counter-name | Count the number of packets that pass this filter, term, or policer. A policer enables you to specify rate limits on traffic that enters an interface on a switch. Note: On EX4300 switches, you can configure the same number of counters and policers as the number of terms in the ternary content addressable memory (TCAM). |
forwarding-class class | Classify the packet in one of the following forwarding classes:
|
| gbp-src-tag (EX4400 and EX4650 only) | Set the group based policy source tag (0..65535) for use with micro-segmentation on VXLAN, as described here: Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN |
interface interface-name | Forward the traffic to the specified interface bypassing the switching lookup. |
log | Log the packet's header information in the Routing Engine. To view this information,
issue the Note: If the log or the syslog action modifier is configured along with a vlan action or an interface action modifier, the events might not be logged. However, the redirect interface functionality works as expected. |
loss-priority (high | low) | Set the packet loss priority (PLP). |
policer policer-name | Apply rate limits to the traffic. You can specify a policer in a firewall filter only for ingress traffic on a port, VLAN, and router. Note: A counter for a policer is not supported on EX8200 switches. Note: On EX4300 switches, you can configure the same number of counters and policers as the number of terms in the TCAM. |
| Mirror packets to the interface defined in the |
| Mirror packets to the instance defined in the |
syslog | Log an alert for this packet. You can specify that the log be sent to a server for storage and analysis. Note: If the log or the syslog action modifier is configured along with a vlan action or an interface action modifier, the events might not be logged. However, the redirect interface functionality works as expected. |
three-color-policer | Apply a three-color policer. |
