It is possible to classify traffic directly to a policer, independent of the policer/queue assigned to the traffic’s forwarding class. This is supported at SAP egress by configuring a policer in the action statement within an ip-criteria or ipv6-criteria statement.
The policed traffic by default exits through one of the following methods:
a queue in the policer-output-queues queue group that is automatically created on an access or hybrid port with the queue used that was chosen by the forwarding class definition in that queue group. If the forwarding class is modified in the action statement, the new forwarding class selects the queue to be used.
a specific queue in a user-configured queue group. For SAP egress, this requires the use of the port-redirect-queue-group queue parameter in the criteria action statement with the queue group name being specified when the egress QoS policy is applied to the SAP. For subscribers, the queue group to be used is selected using the inter-dest-id associated with the subscriber and configured as the host-match dest under the port access queue group configuration.
a SAP queue configured within the SAP egress QoS policy
the queue to which the forwarding class for the traffic is mapped. This could be a queue group, SAP, or subscriber queue. This requires the use of the use-fc-mapped-queue parameter in the criteria action statement. If the forwarding class is modified in the action statement, new forwarding class selects the queue to be used.
The number of configuration combinations of a policer and one of the preceding methods is capped at 63 within a specific SAP egress QoS policy. For two or more definitions to be counted as a single combination, their action statement must have the same policer ID, the same queue ID (if specified in either statement), the same port-redirect-queue-group (if specified in either statement), and the parameter use-fc-mapped-queues (if specified in either statement).
The forwarding class and profile used are irrelevant when considering the number of combinations. For example, it is possible to configure 32 policers with traffic exiting queue 1, but then, only 31 of the same policers are exiting queue 2; this would use all 63 combinations. A resource is also allocated per FP where each combination configured corresponds to an egress bypass entry used in the FP per sap-instance or per subscriber-sap-sla instance that uses the egress qos policy. The number of egress bypass entries available on an FP, together with the number allocated and the number free, can be seen using the following tools command.
*A:PE>tools>dump>resource-usage# card 1 fp 1
===============================================================================
Resource Usage Information for Card Slot #1 FP #1
===============================================================================
Total Allocated Free
-------------------------------------------------------------------------------
...
Egress Qos Bypass | 262143 0 262143
...
This is supported on all hardware systems. QPPB processing takes precedence over this feature.
This could be used, for example, when it is required that egress traffic with a DSCP value EF is to be policed instead of shaped in a queue on a specific SAP. The traffic could be classified based on its DSCP value and directed to policer 1 while the remainder of the customer’s traffic is processed using egress queue 1. This is shown in Figure: Egress SAP.
The configuration would be as follows:
sap-egress 10 create
queue 1 create
exit
policer 1 create
exit
ip-criteria
entry 10 create
match
dscp ef
exit
action policer 1
exit
exit
exit