- 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 Filters for EX Series Switches Overview
Firewall filters provide ruYou can apply port, VLANles that define whether to permit, deny, or forward packets that are transiting an interface on a Juniper Networks EX Series Ethernet Switch from a source address to a destination address. You configure firewall filters to determine whether to permit, deny, or forward traffic before it enters or exits a port, VLAN, or Layer 3 (routed) interface to which the firewall filter is applied. To apply a firewall filter, you must first configure the filter and then apply it to an port, VLAN, or Layer 3 interface.
You can apply firewall filters to network interfaces, aggregated Ethernet interfaces (also known as link aggregation groups (LAGs)), loopback interfaces, management interfaces, virtual management Ethernet interfaces (VMEs), and routed VLAN interfaces (RVIs). For information on EX Series switches that support a firewall filter on these interfaces, see EX Series Switch Software Features Overview.
An ingress firewall filter is a filter that is applied to packets that are entering a network. An egress firewall filter is a filter that is applied to packets that are exiting a network. You can configure firewall filters to subject packets to filtering, class-of-service (CoS) marking (grouping similar types of traffic together, and treating each type of traffic as a class with its own level of service priority), and traffic policing (controlling the maximum rate of traffic sent or received on an interface).
Policers on network port, layer 2 and layer 3, or IRB interfaces do not police host-bound traffic. But if you want to prevent DDoS attacks, then you can create a firewall filter on the lo0 that protects the routing engine.
Firewall Filter Types
The following firewall filter types are supported for EX Series switches:
Port (Layer 2) firewall filter—Port firewall filters apply to Layer 2 switch ports. You can apply port firewall filters in both ingress and egress directions on a physical port.
VLAN firewall filter—VLAN firewall filters provide access control for packets that enter a VLAN, are bridged within a VLAN, or leave a VLAN. You can apply VLAN firewall filters in both ingress and egress directions on a VLAN. VLAN firewall filters are applied to all packets that are forwarded to or forwarded from the VLAN.
Router (Layer 3) firewall filter—You can apply a router firewall filter in both ingress and egress directions on Layer 3 (routed) interfaces and routed VLAN interfaces (RVIs). You can apply a router firewall filter in the ingress direction on the loopback interface (lo0) also. Firewall filters configured on loopback interfaces are applied only to packets that are sent to the Routing Engine CPU for further processing.
You can apply port, VLAN, or router firewall filters to both IPv4 and IPv6 traffic on these switches:
EX2200 switch
EX3300 switch
EX3200 switch
EX4200 switch
EX4300 switch
EX4400 switch
EX4100 switch
EX4100-F switch
EX4650 switch
EX4500 switch
EX4550 switch
EX6200 switch
EX8200 switch
For information on firewall filters supported on different switches, see Platform Support for Firewall Filter Match Conditions, Actions, and Action Modifiers on EX Series Switches.
Firewall Filter Components
In a firewall filter, you first define the family address type (ethernet-switching, inet, or inet6), and then you define one or more terms that specify the filtering criteria (specified as terms with match conditions) and the action (specified as actions or action modifiers) to take if a match occurs.
The maximum number of terms allowed per firewall filter for EX Series switches is:
512 for EX2200 switches
1436 for EX3300 switches
Note:On EX3300 switches, if you add and delete filters with a large number of terms (on the order of 1000 or more) in the same commit operation, not all the filters are installed. You must add filters in one commit operation, and delete filters in a separate commit operation.
7,042 for EX3200 and EX4200 switches—as allocated by the dynamic allocation of ternary content addressable memory (TCAM) for firewall filters.
On EX4300 switches, the following maximum number of terms are supported for ingress and egress traffic, for firewall filers configured on a port, VLAN and Layer 3 interface:
For ingress traffic:
3500 terms for firewall filters configured on a port
3500 terms for firewall filters configured on a VLAN
7000 terms for firewall filters configured on Layer 3 interfaces for IPv4 traffic
3500 terms for firewall filters configured on Layer 3 interfaces for IPv6 traffic
For EX4300-MP devices, ingress support is the same as the above with the following exception:
3072 terms for firewall filters configured on Layer 3 interfaces for IPv4 traffic
For egress traffic:
512 terms for firewall filters configured on a port
256 terms for firewall filters configured on a VLAN
512 terms for firewall filters configured on Layer 3 interfaces for IPv4 traffic
512 terms for firewall filters configured on Layer 3 interfaces for IPv6 traffic
Note:You can configure the maximum number of terms only when you configure one type of firewall filter (port, VLAN, or router (Layer 3) firewall filter) on the switch, and when storm control is not enabled on any interface in the switch.
For EX4400 switches, the following maximum number of terms are supported for ingress and egress traffic, for firewall filters configured on a port, VLAN and layer 3 interfaces.
For ingress traffic:
2048 terms for firewall filters configured on a port.
2048 terms for firewall filters configured on a VLAN.
2048 terms for firewall filters configured on layer 3 interfaces.
For egress traffic:
1024 terms for firewall filters configured on a port.
512 terms for firewall filters configured on a VLAN.
1024 terms for firewall filters configured on layer 3 interfaces.
For EX4100 switches, the following maximum number of terms are supported for ingress and egress traffic, for firewall filters configured on a port, VLAN and layer 3 interfaces.
For ingress traffic:
4092 terms for firewall filters configured on a port.
4092 terms for firewall filters configured on a VLAN.
4092 terms for firewall filters configured on layer 3 interfaces.
For egress traffic:
1024 terms for firewall filters configured on a port.
512 terms for firewall filters configured on a VLAN.
1024 terms for firewall filters configured on layer 3 interfaces.
For EX4100-F switches, the following maximum number of terms are supported for ingress and egress traffic, for firewall filters configured on a port, VLAN and layer 3 interfaces.
For ingress traffic:
4092 terms for firewall filters configured on a port.
4092 terms for firewall filters configured on a VLAN.
4092 terms for firewall filters configured on layer 3 interfaces.
For egress traffic:
1024 terms for firewall filters configured on a port.
511 terms for firewall filters configured on a VLAN.
1024 terms for firewall filters configured on layer 3 interfaces.
For EX4650 switches, the following maximum number of terms are supported for ingress and egress traffic, for firewall filters configured on a port, VLAN and layer 3 interfaces.
For ingress traffic:
1540 terms for firewall filters configured on a port
1540 terms for firewall filters configured on a VLAN for IPv4 traffic.
101 terms for firewall filters configured on a VLAN for IPv6 traffic.
1540 terms for firewall filters configured on Layer 3 interfaces for IPv4 traffic.
101 terms for firewall filters configured on Layer 3 interfaces for IPv6 traffic.
For egress traffic:
2050 terms for firewall filters configured on a port.
1020 terms for firewall filters configured on a VLAN for IPv4 traffic.
2050 terms for firewall filters configured on layer 3 interfaces.
101 terms for firewall filters configured on layer 3 interfaces for IPv6 traffic.
1200 for EX4500 and EX4550 switches
1400 for EX6200 switches
32,768 for EX8200 switches
The on-demand dynamic allocation of the shared space TCAM in EX8200 switches is achieved by assigning free space blocks to firewall filters. Firewall filters are categorized into two different pools. Port and VLAN filters are pooled together (the memory threshold for this pool is 22K) while router firewall filters are pooled separately (the threshold for this pool is 32K). The assignment happens based on the filter pool type. Free space blocks can be shared only among the firewall filters belonging to the same filter pool type. An error message is generated when you try to configure a firewall filter beyond the TCAM threshold.
Each term consists of the following components:
Match conditions—Specify the values or fields that the packet must contain. You can define various match conditions, including the IP source address field, IP destination address field, Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) source port field, IP protocol field, Internet Control Message Protocol (ICMP) packet type, TCP flags, and interfaces.
Action—Specifies what to do if a packet matches the match conditions. Possible actions are to accept or discard the packet or to send the packet to a specific virtual routing interface. In addition, packets can be counted to collect statistical information. If no action is specified for a term, the default action is to accept the packet.
Action modifier—Specifies one or more actions for the switch if a packet matches the match conditions. You can specify action modifiers such as count, mirror, rate limit, and classify packets.
Firewall Filter Processing
The order of the terms within a firewall filter configuration is important. Packets are tested against each term in the order in which the terms are listed in the firewall filter configuration. For information on how firewall filters process packets, see Understanding How Firewall Filters Are Evaluated.
