- 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
-
ON THIS PAGE
Hierarchical Policer Modes on ACX Series Routers
The method in which the micro-flow policer determines and manages the share of the aggregate bandwidth for the micro-flow is defined by the hierarchical policer mode. ACX routers support the following three hierarchical policer modes. You can configure the mode or type of the policer for each hierarchical policer instance.
Hierarchical policer is not applicable on ACX5048 and ACX5096 routers.
Guarantee Mode
This mode, also called bandwidth-guarantee mode, is used when the micro-flow policer is used to specify that a portion of the aggregate parent policer bandwidth is guaranteed for its micro-flow. When this micro-flow contains no traffic, then amount allocated for this micro-flow out of the aggregate bandwidth is used by the other micro-flows that are transmitting traffic with a size-limit or bandwidth that is higher than their respective guaranteed bandwidth rates.
Consider a sample scenario in which the maximum allowed rate or peak information rate (PIR) for a user is 140 Mbps. A total of four services or applications called expedited forwarding (EF), Gold, Silver and Bronze are defined for the guaranteed bandwidth mode of policer with a CIR of 50 Mbps, 40 Mbps, 30 Mbps, and 20 Mbps respectively. For example, if 140 Mbps of trafic is received for each of the four services, then the permitted traffic rates are 50, 40, 30 and 20 Mbps respectively. If 150 Mbps of Gold traffic is received, only 140 Mbps is permitted for Gold traffic.
All the child policers must be of single-rate, single-bucket, and two-color modes for bandwidth guarantee mode of hiearchical policer. This combination of attributes is also called floor mode. The micro-flow policer value specifies the minimum guaranteed bandwidth (CIR) for the micro-flow. The macro-flow policer value specifies the maximum allowed bandwidth (PIR) for all the flows. The sum or the cumulative value of all CIR values of the configured micro-flows must be less than or equal to the macro-flow PIR. The burst size of macro-flow must be greater than the sum of the aggregate of the burst size of all the child policers and the largest MTU of the physical interface among all the physical interfaces of the logical interfaces or interface families to which the child policers are attached.
Consider a sample configuration that has two child policers aggregated by a parent PIR in bandwidth-guarantee mode. PIRs for the children policers and the parent policer are configured. When two flows, flow 1 and flow 2, transmit traffic at a rate that exceeds the configured PIR values, then the share of the parent PIR is adjusted to permit traffic for the child policers based on their priorities defined for the flows, while the bandwidth is maintained.
Policers use a token bucket algorithm to enforce a limit on an average transmit or receive rate of traffic at an interface while allowing bursts of traffic up to a maximum value based on the configured bandwidth limit and configured burst size. The token bucket algorithm offers more flexibility than a leaky bucket algorithm in that you can allow a specified traffic burst before starting to discard packets or apply a penalty such as packet output-queuing priority or packet-drop priority. Following are the main components of the token bucket algorithm:
The bucket represents a rate-limiting function of the policer on the interface input or output traffic.
Each token in the bucket represents a “credit” for some number of bits, and tokens in the bucket are “cashed in” for the ability to receive or transmit traffic that conforms to a rate limit configured for the policer.
The token arrival rate is a periodic allocation of tokens into the token bucket that is calculated from the configured bandwidth limit.
The token bucket depth defines the capacity of the bucket in bytes. Tokens that are allocated after the bucket reaches capacity are not able to be stored and used.
An arriving packet complies with the bandwidth-guarantee mode if tokens are present in the peak burst size (PBS) of either the parent policer or the committed burst size (CBS) of the child policer. If sufficient tokens are not present in the PBS or CBS of either of the parent or child policers respectively, the packet does not conform to the guarantee mode of the hierarchical policer working. In such a case, the child policer rate is guaranteed for the member flows. The following table describes the different scenarios of color-coding for micro-flow and macro-flow policers and the resultant color or priority that is assigned:
Micro-Color | Macro-Color | Result |
---|---|---|
Green | Green | Green |
Green | Red | Green |
Red | Green | Green |
Red | Red | Red |
Peak Mode
This mode, also called bandwidth-protection mode, is used when the micro-flow policer is used to specify the maximum amount of the aggregate parent policer bandwidth that the micro-flow can use. This mode is used to protect a given micro-flow from starving the other flows. Even when the other micro-flows contain no traffic (the available aggregate bandwidth rate is greater than the rate of the particular micro-flow, the micro-flow cannot use more than the rate configured on its micro-flow policer.
Consider a sample scenario in which the total maximum allowed rate (PIR) for a user is 100 Mbps. A total of four services or applications called expedited forwarding (EF), Gold, Silver and Bronze are defined for the peak or bandwidth-restriction mode of the policer with PIR values of 50 Mbps, 40 Mbps, 30 Mbps, and 20 Mbps respectively. Such a setting is used in topologies in which you want to prevent a certain subscriber or user from utilizing an increased share ofthe macro-flow or the parent CIR for real-time applications, such as video-on-demand (VoD) or voice over IP (VoIP). For example, if only 100 Mbps of EF packets are received, the permitted bandwidth rate for the traffic is 50 Mbps. When 100 Mbps of traffic is received for each of the four services, then the aggregate allowed traffic is 100 Mbps, in which the rates are as follows for the different services:
Less than or equal to 50 Mbps for EF traffic
Less than or equal to 40 Mbps for Gold traffic
Less than or equal to 30 Mbps for Silver traffic
Less than or equal to 20 Mbps for Bronze traffic
All the child policers must be of single-rate, single-bucket, and two-color types for bandwidth-protection or peak mode of the hierarchical policer. The micro-flow policer value specifies the maximum allowed bandwidth (PIR) for the micro-flow. The macro-flow policer value specifies the maximum allowed bandwidth (PIR) for all the flows. The sum of micro-flow PIR value must be greater than or equal to the macro-flow PIR. Macro-flow’s PIR value must be greater than or equal to any of its micro-flow’s PIR value. The macro-flow burst-size must be greater than or equal to that of the micro-flow with the largest burst-size.
Consider a sample configuration that has two child policers aggregated by a parent PIR in bandwidth-guarantee mode. PIRs for the children policers and the parent policer are configured. When two flows, flow 1 and flow 2, transmit traffic at a rate that exceeds the configured PIR values, then the share of the parent PIR is adjusted to permit traffic for the child policers based on their priorities defined for the flows, while the bandwidth is restricted to maintain the minimum or committed rates of traffic flows.
An arriving packet complies with the bandwidth-guarantee mode if tokens are present in the peak burst size (PBS) of both the child policer and the parent policer. If sufficient tokens are not present in the PBS of both the policers, the packet does not conform to the peak mode of the hierarchical policer working. In such a case, the child policer rate is the maximum allowed rate or PIR for the member flows. The following table describes the different scenarios of color-coding for micro-flow and macro-flow policers and the resultant color or priority that is assigned:
Micro-Color | Macro-Color | Result |
---|---|---|
Green | Green | Green |
Green | Red | Red |
Red | Green | Red |
Red | Red | Red |
Hybrid Mode
This mode, which is a combination of the bandwidth-guarantee and bandwidth-protection modes, enables the capabilities of bandwidth restriction and the per-flow bandwidth moderation to be accomplished simultanouesly. Bandwidth-guarentee or bandwidth-restriction mode controls the guaranteed rates for a given micro-flow. However, it does not adminster or manage the manner in which the excess aggregate bandwidth can be shared among the micro-flows. A certain micro-flow can potentially use all the excess aggregate bandwidth starving the other micro-flows of any excess bandwidth.
Bandwidth-protection or peak mode controls the amount of bandwidth that a particular micro-flow can consume, thereby protecting other flows from being starved. However, it does not specify any guaranteed rates for the micro-flows. For example, if micro-flow rates for flows f1, f2 and f3 are 50 Mbps, 60 Mbps, 50 Mbps respectively, and the aggregate rate is 70 Mbps, it is possible that f1 and f2 flows might be provided 50 Mbps and 20 Mbps respectively, with no bandwidth allocated for f3.
Hybrid mode implements the benefits of the peak and guaranteed modes to overcome their individual limitations. In hybird mode, the micro-flow policer specifies two rates, CIR and EIR, for the micro-flow. The CIR specifies the guaranteed portion out of the total macro-flow bandwidth for a micro-flow, and the PIR specifies the maximum portion of the total macro-flow bandwidth for a micro-flow. This mechanism is analogues to CIR functioning in guarantee mode and EIR functioning in peak mode, thereby combining the advantages of both models. In hyrbid mode, both color-aware and color-blind modes are supported for child policers.
Child policers operate in compliance with the RFC 4115 mode of two-rate three color markers. Normal two-rate three color markers on ACX routers operate in compliance with the RFC2698 mode.
Consider a sample configuration in which the maximum allowed rate for a user is 140 Mbps. A total of four services or applications called expedited forwarding (EF), Gold, Silver and Bronze are defined for the hybrid mode of the policer with PIR values of 55Mbps, 60 Mbps, 130 Mbps, and 140 Mbps respectively. The defined CIR values are 50 Mbps, 40 Mbps, 30 Mbps, and 20 Mbps for EF, Gold, Silver, and Bronze services respectively. For example, when 140 Mbps of traffic is received for each of the four services, then the permitted green-colored traffic is 50, 40, 30 and 20 Mbps respectively for the four services. If only 140 Mbps of EF traffic is received, 50 Mbps of EF traffic as green and 5 Mbps of EF traffic as yellow are permitted. In the same scenario, assume the macro-policer rate to be 26 Mbps. Also, assume two child policers in color-aware mode, namely, child policer-1 with a CIR of 10 Mbps and an EIR of 10 Mbps. Child policer-2 has a CIR of 15 Mbps and an EIR of 5 Mbps. When flow-1 is a 100 Mbps stream of yellow traffic, and flow-2 is an 100 Mbps stream of green traffic, the output of this policer hierarchy is as follows:
Flow-1 has 0 Mbps of green traffic and has less than or equal to 5 Mbps of yellow traffic.
Flow-2 has 10 Mbps of green traffic and has greater than or equal to 10 Mbps of yellow traffic.
The sum of yellow traffic is less than or equal to 11 Mbps .
Consider a sample configuration that has two child policers aggregated by a parent PIR in hybrid mode. PIRs for the children policers and the parent policer are configured. When two flows, flow 1 and flow 2, transmit traffic at a rate that exceeds the configured PIR values, then the share of the parent PIR is adjusted to permit traffic for the child policers while the child PIR values are preserved for the two flows.
Hybrid mode of working of the aggregate or hierarchical policer supports two rates (CIR and PIR) and three colors for micro-flows. On ACX routers, for hybrid type of the policer, the micro-policer must be of type modified-trtcm as defined in RFC 4115. Both color-blind and color- aware modes are supported for child policers. Macro policer must be a single rate, single bucket, two color policer with the sum of the CIR values of the micro-flows being less than the PIR value of the macro-flow, and the cumulative value of all the PIR values of the micro-flows being greater than the PIR value of the macro-flow. When micro-flow traffic is less than the CIR value of the micro-flow CIR, the policer causes either the micro-flow CIR to be maintained or PIR to be achieved. When micro-flow traffic is greater than the CIR value of the micro-flow, the micro-flow CIR is guaranteed. Micro-flow excess rates are shared based on the available macro-flow bandwidth with the limitation of the excess information rate distributed for the micro-flows being implemented by the micro-flow PIR. The CBS of the macro-flow must be greater than or equal to the aggregate of the micro-flow CBS. The excess burst size (EBS) of the macro-flow must be greater than or equal to that of the micro-flow with the largest EBS.
An arriving packet complies with the hybrid mode if tokens are present in the committed burst size (CBS) of the child policer. The packet does not comply with hybrid mode if tokens are present in both the EBS of the child policer and the PBS of the parent policer. When a packet does not satisfy the hybrid mode of working of a policer, the CIR of the child policer is guaranteed for the member traffic flows and the PIR value of the child policer is the maximum permitted rate for the member flows. The following table describes the different scenarios of color-coding for micro-flow and macro-flow policers and the resultant color or priority that is assigned:
Micro-Color | Macro-Color | Result |
---|---|---|
Green | Green | Green |
Red | Green | Green |
Yellow | Green | Yellow |
Yellow | Red | Red |
Red | Green | Red |
Red | Red | Red |