- 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 Firewall Filters
- play_arrow Understanding How Firewall Filters Protect Your Network
- Firewall Filters Overview
- Router Data Flow Overview
- Stateless Firewall Filter Overview
- Understanding How to Use Standard Firewall Filters
- Understanding How Firewall Filters Control Packet Flows
- Stateless Firewall Filter Components
- Stateless Firewall Filter Application Points
- How Standard Firewall Filters Evaluate Packets
- Understanding Firewall Filter Fast Lookup Filter
- Understanding Egress Firewall Filters with PVLANs
- Selective Class-based Filtering on PTX Routers
- Guidelines for Configuring Firewall Filters
- Guidelines for Applying Standard Firewall Filters
- Supported Standards for Filtering
- Monitoring Firewall Filter Traffic
- Troubleshooting Firewall Filters
- play_arrow Firewall Filter Match Conditions and Actions
- Overview of Firewall Filters (OCX Series)
- Overview of Firewall Filter Profiles on ACX Series Routers (Junos OS Evolved)
- Understanding Firewall Filter Match Conditions
- Understanding Firewall Filter Planning
- Understanding How Firewall Filters Are Evaluated
- Understanding Firewall Filter Match Conditions
- Firewall Filter Flexible Match Conditions
- Firewall Filter Nonterminating Actions
- Firewall Filter Terminating Actions
- Firewall Filter Match Conditions and Actions (ACX Series Routers)
- Firewall Filter Match Conditions and Actions in ACX Series Routers (Junos OS Evolved)
- Firewall Filter Match Conditions for Protocol-Independent Traffic
- Firewall Filter Match Conditions for IPv4 Traffic
- Firewall Filter Match Conditions for IPv6 Traffic
- Firewall Filter Match Conditions Based on Numbers or Text Aliases
- Firewall Filter Match Conditions Based on Bit-Field Values
- Firewall Filter Match Conditions Based on Address Fields
- Firewall Filter Match Conditions Based on Address Classes
- Understanding IP-Based Filtering and Selective Port Mirroring of MPLS Traffic
- Firewall Filter Match Conditions for MPLS Traffic
- Firewall Filter Match Conditions for MPLS-Tagged IPv4 or IPv6 Traffic
- Firewall Filter Match Conditions for VPLS Traffic
- Firewall Filter Match Conditions for Layer 2 CCC Traffic
- Firewall Filter Match Conditions for Layer 2 Bridging Traffic
- Firewall Filter Support on Loopback Interface
- play_arrow Applying Firewall Filters to Routing Engine Traffic
- Configuring Logical Units on the Loopback Interface for Routing Instances in Layer 3 VPNs
- Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List
- Example: Configuring a Stateless Firewall Filter to Accept Traffic from Trusted Sources
- Example: Configure a Filter to Block Telnet and SSH Access
- Example: Configuring a Filter to Block TFTP Access
- Example: Configuring a Filter to Accept Packets Based on IPv6 TCP Flags
- Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers
- Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods
- Example: Protecting the Routing Engine with a Packets-Per-Second Rate Limiting Filter
- Example: Configuring a Filter to Exclude DHCPv6 and ICMPv6 Control Traffic for LAC Subscriber
- Port Number Requirements for DHCP Firewall Filters
- Example: Configuring a DHCP Firewall Filter to Protect the Routing Engine
- play_arrow Applying Firewall Filters to Transit Traffic
- Example: Configuring a Filter for Use as an Ingress Queuing Filter
- Example: Configuring a Filter to Match on IPv6 Flags
- Example: Configuring a Filter to Match on Port and Protocol Fields
- Example: Configuring a Filter to Count Accepted and Rejected Packets
- Example: Configuring a Filter to Count and Discard IP Options Packets
- Example: Configuring a Filter to Count IP Options Packets
- Example: Configuring a Filter to Count and Sample Accepted Packets
- Example: Configuring a Filter to Set the DSCP Bit to Zero
- Example: Configuring a Filter to Set the DSCP Bit to Zero
- Example: Configuring a Filter to Match on Two Unrelated Criteria
- Example: Configuring a Filter to Accept DHCP Packets Based on Address
- Example: Configuring a Filter to Accept OSPF Packets from a Prefix
- Example: Configuring a Stateless Firewall Filter to Handle Fragments
- Configuring a Firewall Filter to Prevent or Allow IPv4 Packet Fragmentation
- Configuring a Firewall Filter to Discard Ingress IPv6 Packets with a Mobility Extension Header
- Example: Configuring an Egress Filter Based on IPv6 Source or Destination IP Addresses
- Example: Configuring a Rate-Limiting Filter Based on Destination Class
- play_arrow Configuring Firewall Filters in Logical Systems
- Firewall Filters in Logical Systems Overview
- Guidelines for Configuring and Applying Firewall Filters in Logical Systems
- References from a Firewall Filter in a Logical System to Subordinate Objects
- References from a Firewall Filter in a Logical System to Nonfirewall Objects
- References from a Nonfirewall Object in a Logical System to a Firewall Filter
- Example: Configuring Filter-Based Forwarding
- Example: Configuring Filter-Based Forwarding on Logical Systems
- Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods
- Example: Configuring a Stateless Firewall Filter to Protect a Logical System Against ICMP Floods
- Unsupported Firewall Filter Statements for Logical Systems
- Unsupported Actions for Firewall Filters in Logical Systems
- Filter-Based Forwarding for Routing Instances
- Forwarding Table Filters for Routing Instances on ACX Series Routers
- Configuring Forwarding Table Filters
- play_arrow Configuring Firewall Filter Accounting and Logging
- play_arrow Attaching Multiple Firewall Filters to a Single Interface
- Applying Firewall Filters to Interfaces
- Configuring Firewall Filters
- Multifield Classifier Example: Configuring Multifield Classification
- Multifield Classifier for Ingress Queuing on MX Series Routers with MPC
- Assigning Multifield Classifiers in Firewall Filters to Specify Packet-Forwarding Behavior (CLI Procedure)
- Understanding Multiple Firewall Filters in a Nested Configuration
- Guidelines for Nesting References to Multiple Firewall Filters
- Understanding Multiple Firewall Filters Applied as a List
- Guidelines for Applying Multiple Firewall Filters as a List
- Example: Applying Lists of Multiple Firewall Filters
- Example: Nesting References to Multiple Firewall Filters
- Example: Filtering Packets Received on an Interface Set
- play_arrow Attaching a Single Firewall Filter to Multiple Interfaces
- Interface-Specific Firewall Filter Instances Overview
- Interface-Specific Firewall Filter Instances Overview
- Filtering Packets Received on a Set of Interface Groups Overview
- Filtering Packets Received on an Interface Set Overview
- Example: Configuring Interface-Specific Firewall Filter Counters
- Example: Configuring a Stateless Firewall Filter on an Interface Group
- play_arrow Configuring Filter-Based Tunneling Across IP Networks
- Understanding Filter-Based Tunneling Across IPv4 Networks
- Firewall Filter-Based L2TP Tunneling in IPv4 Networks Overview
- Interfaces That Support Filter-Based Tunneling Across IPv4 Networks
- Components of Filter-Based Tunneling Across IPv4 Networks
- Example: Transporting IPv6 Traffic Across IPv4 Using Filter-Based Tunneling
- play_arrow Configuring Service Filters
- Service Filter Overview
- How Service Filters Evaluate Packets
- Guidelines for Configuring Service Filters
- Guidelines for Applying Service Filters
- Example: Configuring and Applying Service Filters
- Service Filter Match Conditions for IPv4 or IPv6 Traffic
- Service Filter Nonterminating Actions
- Service Filter Terminating Actions
- play_arrow Configuring Simple Filters
- play_arrow Configuring Layer 2 Firewall Filters
- Understanding Firewall Filters Used to Control Traffic Within Bridge Domains and VPLS Instances
- Example: Configuring Filtering of Frames by MAC Address
- Example: Configuring Filtering of Frames by IEEE 802.1p Bits
- Example: Configuring Filtering of Frames by Packet Loss Priority
- Example: Configuring Policing and Marking of Traffic Entering a VPLS Core
- Understanding Firewall Filters on OVSDB-Managed Interfaces
- Example: Applying a Firewall Filter to OVSDB-Managed Interfaces
- play_arrow Configuring Firewall Filters for Forwarding, Fragments, and Policing
- Filter-Based Forwarding Overview
- Firewall Filters That Handle Fragmented Packets Overview
- Stateless Firewall Filters That Reference Policers Overview
- Example: Configuring Filter-Based Forwarding on the Source Address
- Example: Configuring Filter-Based Forwarding to a Specific Outgoing Interface or Destination IP Address
- play_arrow Configuring Firewall Filters (EX Series Switches)
- Firewall Filters for EX Series Switches Overview
- Understanding Planning of Firewall Filters
- Understanding Firewall Filter Match Conditions
- Understanding How Firewall Filters Control Packet Flows
- Understanding How Firewall Filters Are Evaluated
- Understanding Firewall Filter Processing Points for Bridged and Routed Packets on EX Series Switches
- Firewall Filter Match Conditions, Actions, and Action Modifiers for EX Series Switches
- Platform Support for Firewall Filter Match Conditions, Actions, and Action Modifiers on EX Series Switches
- Support for Match Conditions and Actions for Loopback Firewall Filters on Switches
- Configuring Firewall Filters (CLI Procedure)
- Understanding How Firewall Filters Test a Packet's Protocol
- Understanding Filter-Based Forwarding for EX Series Switches
- Example: Configuring Firewall Filters for Port, VLAN, and Router Traffic on EX Series Switches
- Example: Configuring a Firewall Filter on a Management Interface on an EX Series Switch
- Example: Using Filter-Based Forwarding to Route Application Traffic to a Security Device
- Example: Applying Firewall Filters to Multiple Supplicants on Interfaces Enabled for 802.1X or MAC RADIUS Authentication
- Verifying That Policers Are Operational
- Troubleshooting Firewall Filters
- play_arrow Configuring Firewall Filters (QFX Series Switches, EX4600 Switches, PTX Series Routers)
- Overview of Firewall Filters (QFX Series)
- Understanding Firewall Filter Planning
- Planning the Number of Firewall Filters to Create
- Firewall Filter Match Conditions and Actions (QFX and EX Series Switches)
- Firewall Filter Match Conditions and Actions (QFX10000 Switches)
- Firewall Filter Match Conditions and Actions (PTX Series Routers)
- Firewall and Policing Differences Between PTX Series Packet Transport Routers and T Series Matrix Routers
- Configuring Firewall Filters
- Applying Firewall Filters to Interfaces
- Overview of MPLS Firewall Filters on Loopback Interface
- Configuring MPLS Firewall Filters and Policers on Switches
- Configuring MPLS Firewall Filters and Policers on Routers
- Configuring MPLS Firewall Filters and Policers
- Understanding How a Firewall Filter Tests a Protocol
- Understanding Firewall Filter Processing Points for Bridged and Routed Packets
- Understanding Filter-Based Forwarding
- Example: Using Filter-Based Forwarding to Route Application Traffic to a Security Device
- Configuring a Firewall Filter to De-Encapsulate GRE or IPIP Traffic
- Verifying That Firewall Filters Are Operational
- Monitoring Firewall Filter Traffic
- Troubleshooting Firewall Filter Configuration
- play_arrow Configuring Firewall Filter Accounting and Logging (EX9200 Switches)
-
- play_arrow Configuration Statements and Operational Commands
- play_arrow Troubleshooting
- play_arrow Knowledge Base
-
Hierarchical Policers
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 M40E, M120, and M320 edge routers with incoming Flexible PIC Concentrators (FPCs) as SFPC and outgoing FPCs as FFPC, and on MX Series, ACX7100-L, T320, T640, and T1600 core routers with Enhanced Intelligent Queuing (IQE) PICs.
You can apply hierarchical policing to a logical interface.
A hierarchical policer configuration defines two policers—one for EF traffic only and another for non-EF traffic—that function in a hierarchical manner:
Premium policer—You 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.
Aggregate policer—You 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, or assign a packet loss priority (PLP) level.
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 traffic—EF traffic that arrives at the interface at rates above 2 Mbps—can 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 traffic—non-EF traffic that arrives at the interface at rates above the current limit for non-EF traffic—also 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.
Subscriber Services Firewall Policer (ACX7100-48L Devices)
Starting Junos Evolved release 23.4R1, you can configure the hierarchical policer on DHCP and PPPoE access models at subscriber interfaces, that is activated during subscriber login or CoA. This feature supports colour coded traffic policing according to the colour classification of a packet. The packet colour is classified with packet matching criteria specified for two user-defined traffic classes. See the Example: Configuring a Hierarchical Policer for Subscriber Services Firewall (ACX7100-48L Devices) section for related configuration examples and limitations of the feature.
See Also
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
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Use the CLI Editor in Configuration Mode.
To configure this example, perform the following tasks:
- CLI Quick Configuration
- Defining the Interfaces
- Defining the Forwarding Classes
- Configuring the Hierarchical Policer
- Applying the Hierarchical Policer to Layer 2 Ingress Traffic at a Physical or Logical Interface
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 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:
Enable configuration of the physical interface.
content_copy zoom_out_map[edit] user@host# edit interfaces so-1/0/0
Configure logical unit 0.
content_copy zoom_out_map[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.
Configure logical unit 1.
content_copy zoom_out_map[edit interfaces so-1/0/0] user@host# set unit 1 family mpls
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:
Enable configuration of the forwarding classes.
content_copy zoom_out_map[edit] user@host# edit class-of-service forwarding-classes
Define the forwarding classes.
content_copy zoom_out_map[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:
Enable configuration of the hierarchical policer.
content_copy zoom_out_map[edit] user@host# edit firewall hierarchical-policer policer1
Configure the aggregate policer.
content_copy zoom_out_map[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, or change the forwarding class.
Configure the premium policer.
content_copy zoom_out_map[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:
Enable configuration of the logical interface.
content_copy zoom_out_map[edit] 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.
Apply the policer to the logical interface.
content_copy zoom_out_map[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;
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Displaying Traffic Statistics and Policers for the Logical Interface
- Displaying Statistics for the Policer
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.
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
Verify the number of packets evaluated by the policer.
Action
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.
Example: Configuring a Hierarchical Policer for Subscriber Services Firewall (ACX7100-48L Devices)
This example shows how to configure a hierarchical policer and apply the policer to ingress traffic at a subscriber interface on a supported platform (ACX7100-48L).
Overview
Starting Junos Evolved release 23.4R1, you can configure hierarchical policers and apply the policers to ingress traffic at a subscriber interface. This feature is supported on ACX7100-48L devices.
The subscriber services hierarchical policer has the following limitations:
You can configure only four levels of hierarchical policers with each level having aggregate and premium configuration.
Logical interface policers and aggregate policers are not supported for subscriber services.
- Policing priority set inside forwarding class is not supported.
For example:
content_copy zoom_out_map
class-of-service { forwarding-classes { class BestEffort queue-num 0 priority low policing-priority normal; } } next termis allowed only for hierarchical policers and not for filters.- Attaching policers directly to an interface or family is not supported. Policers are supported only through firewall filter action.
- Policer action
forwarding-classis not supported in ingress and egress.loss-priority highaction is supported in ingress. Onlydiscardaction is supported in egress. - A single policy cannot have
loss-priorityandpoliceractions configured. Only one of both actions are supported at any given time. filter-specificoption is not supported in policer configuration.- Hierarchical policers and tri-color policers are not supported in the Egress direction.
Filter terms chaining feature is not available.
Tri-color policer and hierarchical policers are not supported in Egress direction.
Configuration Scenarios
The following section provides the different configurations for various hierarchical policer options:
- Single Rate Two Color Marking Policer Configuration Single Rate Tri Color Marking Policer Configuration
- Two Rate Tri Color Marking Policer
- Hierarchical Policer for DHCP and PPPoE
Single Rate Two Color Marking Policer Configuration
You can configure single rate two color marking policer on DHCP and PPPoE
access models. The configuration is activated during subscriber login or
CoA. View the configuration by entering the show
dynamic-profiles pppoe-client-policer-1-profile command. A
sample configuration is as follows:
[edit]
root@bng-controller# show dynamic-profiles pppoe-client-policer-1-profile
variables {
downstream-inet uid;
upstream-inet uid;
HPolicer-in uid;
HPolicer-out uid;
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options {
chap;
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$upstream-inet";
output "$downstream-inet";
}
unnumbered-address lo0.0;
}
family inet6 {
unnumbered-address lo0.0;
}
}
}
}
firewall
{
family inet
{
filter "$downstream-inet"
{
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-in";
accept;
}
}
}
filter "$upstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-out";
accept;
}
}
}
}
policer "$HPolicer-in" {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then discard;
}
policer "$HPolicer-out" {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then discard;
}
}
You can configure single rate tri-color marking policer on DHCP and PPPoE
access models. It is activated during subscriber login or CoA. View the
configuration by entering the show dynamic-profiles
pppoe-client-policer-1-profile command. A sample
configuration is as follows:
[edit]
user@bng-controller# show dynamic-profiles pppoe-client-policer-2-profile | no-more
variables
{
downstream-inet uid;
upstream-inet uid;
HPolicer-in uid;
HPolicer-out uid;
}
interfaces
{
pp0
{
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options
{
chap;
pap;
}
pppoe-options
{
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$upstream-inet";
output "$downstream-inet";
}
unnumbered-address lo0.0;
}
family inet6 {
unnumbered-address lo0.0;
}
}
}
}
firewall {
family inet {
filter "$downstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-out";
accept;
}
}
}
filter "$upstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
three-color-policer {
single-rate "$HPolicer-in";
}
count three-color-policer-count;
accept;
}
}
}
}
policer "$HPolicer-out" {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then discard;
}
three-color-policer "$HPolicer-in" {
action {
loss-priority high then discard;
}
single-rate {
color-blind;
committed-information-rate 5m;
committed-burst-size 5k;
excess-burst-size 15k;
}
}
}
Two Rate Tri Color Marking Policer
You can configure two rate tri color marking policer on DHCP and PPPoE access models. It is activated during subscriber login or CoA.
In this section you can see a sample dynamic profile configuration on
controller point. Contents of dynamic profile are propagated forward during
subscriber login for a client profile or during service activation for a
service profile. View the configuration by entering the show
dynamic-profiles pppoe-client-policer-1-profile command. A
sample configuration is as follows:
[edit]
root@bng-controller# show dynamic-profiles pppoe-client-policer-3-profile | no-more
variables {
downstream-inet uid;
upstream-inet uid;
HPolicer-in uid;
HPolicer-out uid;
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options {
chap;
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$upstream-inet";
output "$downstream-inet";
}
unnumbered-address lo0.0;
}
family inet6 {
unnumbered-address lo0.0;
}
}
}
}
firewall {
family inet {
filter "$downstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-out";
accept;
}
}
}
filter "$upstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
three-color-policer {
two-rate "$HPolicer-in";
}
count three-color-policer-count;
accept;
}
}
}
}
policer "$HPolicer-out" {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then discard;
}
three-color-policer "$HPolicer-in" {
action {
loss-priority high then discard;
}
two-rate {
color-blind;
committed-information-rate 5m;
committed-burst-size 5k;
peak-information-rate 10m;
peak-burst-size 10k;
}
}
}
Hierarchical Policer for DHCP and PPPoE
In this section you can see a sample dynamic profile configuration at the
controller point on DHCP and PPPoE access models. Contents of dynamic
profile are propagated forward during subscriber login for a client
profile or during service activation for a service profile. View the
configuration by entering the show dynamic-profiles
pppoe-client-policer-1-profile command. A sample
configuration is as follows:
[edit]
user@host# show dynamic-profiles pppoe-client-policer-4-profile
variables {
downstream-inet uid;
upstream-inet uid;
HPolicer-in uid;
HPolicer-out uid;
P0-IN uid;
P1-IN uid;
P2-IN uid;
Session-IN uid;
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options {
chap;
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$upstream-inet";
output "$downstream-inet";
}
unnumbered-address lo0.0;
}
family inet6 {
unnumbered-address lo0.0;
}
}
}
}
firewall {
family inet {
filter "$downstream-inet" {
interface-specific;
term t1 {
from {
source-port 80;
}
then {
policer "$HPolicer-out";
accept;
}
}
}
filter "$upstream-inet" {
interface-specific;
term P0-Aggregate {
from {
dscp 46;
}
then {
hierarchical-policer "$P0-IN";
next term;
}
}
term P1-Premium {
from {
dscp [ 46 22 ];
}
then {
force-premium;
next term;
}
}
term P1-Aggregate {
from {
dscp [ 46 22 ];
}
then {
hierarchical-policer "$P1-IN";
next term;
}
}
term P2-Premium {
from {
dscp [ 46 22 56 ];
}
then {
force-premium;
next term;
}
}
term P2-Aggregate {
from {
dscp [ 46 22 56 ];
}
then {
hierarchical-policer "$P2-IN";
next term;
}
}
term final-Premium {
from {
dscp [ 46 22 56 00 ];
}
then {
force-premium;
next term;
}
}
term final {
then {
hierarchical-policer "$Session-IN";
accept;
}
}
}
}
policer "$HPolicer-out" {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then discard;
}
hierarchical-policer "$HPolicer-in" {
aggregate {
if-exceeding {
bandwidth-limit 30m;
burst-size-limit 30k;
}
then {
loss-priority high;
}
}
premium {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 10k;
}
then {
discard;
}
}
}
hierarchical-policer "$P0-IN" {
logical-interface-policer;
aggregate {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
premium {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
}
hierarchical-policer "$P1-IN" {
logical-interface-policer;
aggregate {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
premium {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
}
hierarchical-policer "$P2-IN" {
logical-interface-policer;
aggregate {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
premium {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
}
hierarchical-policer "$Session-IN" {
logical-interface-policer;
aggregate {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
premium {
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 5k;
}
then {
discard;
}
}
}
}
If you are done configuring the device, enter commit
from configuration mode.
