Class fair hierarchical policing (CFHP)

Overview

CFHP merges the benefits of non-delay rate enforcement inherent to policers with the priority and fairness sensitivity of queuing and scheduling. CFHP is implemented as a group of child policers mapped to a parent policer where the rate enforced by the parent both obeys strict priority levels and is class fair within a priority level. At the parent policer, the output of a lower priority child policer cannot prevent forwarding of packets of a higher priority child policer and when multiple child policers share the same priority level, the system maintains a Fair Information Rate (FIR) for each child that is separate from a child’s PIR and CIR rates. Policers can also be used standalone. The parent is optional.

Multiservice sites support policer-control-policy in the in the ingress and egress in addition to scheduler-policy.

Below are the capabilities and limitations for CFHP under a multiservice site:

  • Support for SAP only (no subscriber support).

  • Assignment is for port only (not for card).

  • Supported both in ingress and egress.

  • Policer overrides are not supported under a multiservice site.

*A:Dut-A>config>service>cust>multi-service-site# pwc
-------------------------------------------------------------------------------
Present Working Context :
-------------------------------------------------------------------------------
<root>
configure
service
customer 2
multi-service-site "mss1"
-------------------------------------------------------------------------------
*A:Dut-A>config>service>cust>multi-service-site# info
----------------------------------------------
assignment port 9/1/4
ingress
policer-control-policy "pcp"
exit
egress
policer-control-policy "pcp"
exit
----------------------------------------------

Example of a service using mss is as follows. The sap-egress qos policy ‟3” has policers parented to arbiters that are configured in the policer-control-policy ‟pcp” as in the preceding example.

*A:Dut-A>config>service>vpls# pwc
-------------------------------------------------------------------------------
Present Working Context :
-------------------------------------------------------------------------------
<root>
configure
service
vpls "101"
-------------------------------------------------------------------------------
*A:Dut-A>config>service>vpls# info
----------------------------------------------
shutdown
stp
shutdown
exit
sap 9/1/4 create
multi-service-site "mss1"
egress
qos 3
exit
exit
----------------------------------------------

Parent policer priority and unfair sensitive discard thresholds

Priority-level bandwidth control is managed on the parent policer through the use of progressively higher discard thresholds for each in-use priority level. Up to eight priority levels are supported and are individually enabled per parent policer instance based on child policer priority level association. When multiple child policers are associated with a parent policer priority level, two separate discard thresholds are maintained for that priority level. A lower ‟discard-unfair” threshold ensures that when a child policer has exceeded its FIR rate, its unfair packets are discarded first (assuming the parent policer’s bucket depth has reached the priority level’s ‟discard-unfair” threshold) protecting the priority level’s fair traffic from the priority level’s unfair traffic.

A second ‟discard-all” threshold is used to discard all remaining packets associated with the priority level in the case where higher priority traffic exists and the sum of both the priority level’s traffic and the higher priority traffic exceeds the parent policer rate. This protects the higher priority traffic on the parent policer from being discarded because of lower priority traffic. The child and parent policers operate in an atomic fashion, any conformance effect on a child policer's bucket depth is canceled when the parent policer discards a packet. Policer bucket rate and packet flow interaction with bucket depth are shown in Policer bucket rate and packet flow interaction with bucket depth. Parent policer bucket and priority thresholds are shown in Parent policer bucket and priority thresholds.

Figure 1. Policer bucket rate and packet flow interaction with bucket depth
Figure 2. Parent policer bucket and priority thresholds

CFHP ingress and egress use cases

While ingress CFHP is more common, CFHP may also be used at egress. The reasons for utilizing egress CFHP may be to provide a non-jitter or latency inducing aggregate SLA for multiple ingress flows or just to provide higher scale in the number of egress aggregate SLAs supported.

Post-CFHP queuing and scheduling

Although CFHP enforces aggregate rate limiting while maintaining sensitivity to strict priority and fair access to bandwidth within a priority, CFHP output packets still require queuing and scheduling to provide access to the switch fabric or to an egress port.

Ingress CFHP queuing

At ingress, CFHP output traffic is automatically mapped to a unicast or multipoint queue in to reach the correct switch fabric destinations. To manage this automatic queuing function, a shared queue policy has been created or exists by default and is named policer-output-queues.

The unicast queues in the policy are automatically created on each destination switch fabric tap and ingress CFHP unicast packets automatically map to one of the queues based on forwarding class and destination tap. 16 multicast paths are supported by default with 28 on 7950 XRS systems and the 7750 SR 12-e systems, with the latter having setting ‟tools perform the system set-fabric-speed fabric-speed-b.” The multicast paths represent an available multicast switch fabric path; the number of each being controlled using the command:

configure mcast-management bandwidth-policy policy-name t2-paths secondary-path

    — number-paths number-of-paths [dual-sfm number-of-paths]

For ingress CFHP multicast packets (Broadcast, Unknown unicast, or Multicast—referred to as BUM traffic), the system maintains a conversation hash table per forwarding class and populates the table’s forwarding class hash result entry with the one of the multicast paths. Best-effort traffic uses the secondary paths, and expedited traffic uses the primary paths. When a BUM packet is output by ingress CFHP, a conversation hash is performed and used along with the packet’s forwarding class to select a hash table entry to derive the multicast path to be used. Each table entry maintains a bandwidth counter that is used to monitor the aggregate traffic per multicast path. The process can be optimized by enabling IMPM on any forwarding complex, which allows the system to redistribute this traffic across the IMPM paths on all forwarding complexes to achieve a more even capacity distribution. Be aware that enabling IMPM causes routed and VPLS (IGMP and PIM) snooped IPv4 multicast groups, and routed and PIM snooped (with sg-based forwarding) IPv6 multicast groups to be managed by IMPM.

Any discards performed in the ingress shared queues are reflected in the ingress child policer's discard counters and reported statistics, assuming a discard counter capable stat-mode is configured for the child policer.

Egress CFHP queuing

When CFHP is being performed at egress, queuing of the CFHP output packets is accomplished through egress queue group queues. The system maintains a special egress queue group template (policer-output-queues) that is automatically applied to all Ethernet access ports that are up. The number of queues, queue types (expedite or best-effort), queue parameters, and the default forwarding class mappings to the queues are managed by the template. On each Ethernet port, the queue parameters may be overridden.

When a SAP egress QoS policy is applied to an Ethernet SAP and the policy contains a forwarding class mapping to a CFHP child policer, the default behavior for queuing the CFHP output is to use the egress Ethernet port’s policer-output-queues queue group and the forwarding class mapping within the group to choose the egress queue. Optionally, the SAP egress QoS policy may also explicitly define which egress queue to use within the default queue group or even map the policer output to a different, explicitly created queue group on the port.

Any discards performed in the egress queue group queues are reflected in the egress child policer’s discard counters and reported statistics assuming a discard counter capable stat-mode is configured for the child policer. Exceed-profile traffic from the policer is counted as out-of-profile traffic in the egress queue group queues.

Policer to local queue mapping

Egress policers can be optionally mapped to a local queue instead of a queue group queue where required.

The syntax for assigning one such egress policer mapped to local queue is as below:

*A:Dut-A>config>qos>sap-egress$ pwc
-------------------------------------------------------------------------------
Present Working Context :
-------------------------------------------------------------------------------
<root>
configure
qos
sap-egress 3 create
-------------------------------------------------------------------------------
*A:Dut-A>config>qos>sap-egress$ info
----------------------------------------------
queue 1 create
exit
queue 2 create
exit
policer 2 create
exit
fc ef create
policer 2 queue 2
exit
----------------------------------------------

To a local queue, as in "queue 2" in the previous example, both a policer and also a forwarding class can be concurrently mapped as shown below:

*A:Dut-A>config>qos>sap-egress$ info
----------------------------------------------
queue 1 create
exit
queue 2 create
exit
policer 2 create
exit
fc af create
queue 2
exit
fc ef create
policer 2 queue 2
exit
----------------------------------------------

A queue resource is allocated whenever there is either an fc or a policer referencing it. The local queue is freed when there are no references to it. The local queue cannot be deleted when it is being referenced. Exceed-profile traffic from the policer is counted as out-of-profile traffic in the egress local queues.

Egress subscriber CFHP queuing

When a subscriber packet is mapped to a child policer through the SAP egress QoS policy, the actual egress queue group is derived from the subscriber host identification process within the subscriber management module; otherwise, the default queue-group is used.

When egress policed packets are directed to a local SAP queue, and, when this is configured, the output of a show service id id sap sap-id sap-stats only counts these packets through the policer; they are not counted a second time through the queue to avoid double counting. Consequently, any packets sent directly (not through a policer) to a local SAP post-policer queue are not counted in the sap-stats output. The output of show service id id sap sap-id stats always counts these packets in both the related policer and queue. If it is required to count packets sent directly to the local SAP post-policer queue in the sap-stats output, the packets could be sent into a policer with the rate set to max, then into the local SAP queue.

Subscriber destination string queue group identification

When a subscriber is identified, a special destination string may optionally exist for the subscriber that is typically used to identify the subscriber’s destination aggregation node. This feature applies only to the 7450 ESS and 7950 SR.

On the subscriber’s egress Ethernet port, the default policer-output-queues and other explicitly created queue groups may be configured to represent a destination node by defining the same destination string on the queue group. When the subscriber’s destination string is defined, the system searches the subscriber’s egress port for an egress queue group with the same string defined. If found, it uses that matched queue group instead of the default queue group. If a queue-group matching the string is not found, the subscriber identification event does not fail and the subscriber host is mapped to default policer-output-queues.

The destination node-based queuing model is designed to provide the ability to shape the aggregate subscriber output to a destination aggregation node based on a queue group created for the specific purpose. On the queue group, a scheduling-policy is applied that defines the wanted virtual scheduling behavior of the queues and aggregate maximum rate of the queue group. The destination string matching function could be used to represent any arbitrary downstream bandwidth limit, not just an aggregation node. If the destination string is not present (null value), the default policer egress queue group ('policer-output-queues') on the subscriber’s port is used.

SAP default destination string

To simplify subscriber destination string provisioning, a def-inter-dest-id command can be used in a sub-sla-mgmt node within a SAP, which allows the definition of a default destination string for all subscribers associated with the SAP. The command also accepts the use-top-q flag that automatically derives the string based on the topmost delineating Dot1Q tag from the SAP’s encapsulation. This feature applies only to the 7450 ESS and 7750 SR.

The command is also supported within the msap-policy allowing similar provisioning behavior for automatically created managed SAPs.

CFHP policer control policy

Provisioning CFHP requires creating policer control policies (policer-control-policy), and applying a policer control policy to the ingress or egress context of a SAP or to the ingress or egress context of a subscriber profile (sub-profile), much the same way scheduler policies (scheduler-policy) are applied.

Applying a policer control policy to a SAP creates an instance of the policy that is used to control the bandwidth associated with the child policers on the SAP. In a similar fashion, an instance of the policy is created when a subscriber profile associated with the policy is applied to a subscriber context. The subscriber policy instance is used to control the bandwidth of the child policers created by the SLA profile instances within the subscriber context.

Policer control policies can only be applied to SAPs created on Ethernet ports. When the policy instance is created, any policers created on the SAP that have an appropriate parent command defined are considered child policers.

Policer control policy root arbiter

Similar to a scheduler context within a scheduler-policy, the policer-control-policy contains objects called arbiters that control the amount of bandwidth that may be distributed to a set of child policers. Each policer control policy always contains a root arbiter that represents the parent policer. The max-rate defined for the arbiter specifies the decrement rate for the parent policer that governs the overall aggregate rate of every child policer associated with the policy instance. The root arbiter also contains the parent policers MBS configuration parameters that the system uses to individually configure the priority thresholds for each policer instance.

Child policers may parent directly to the root arbiter or to one of the tier 1 or tier 2 explicitly created arbiters.

Each arbiter provides bandwidth to its children using eight strict levels. Children parented at level 8 are first to receive bandwidth. The arbiter continues to distribute bandwidth until either all of its children's bandwidth requirements are met or until the bandwidth it is allowed to distribute is exhausted. The root arbiter is special in that its strict priority levels directly represent the priority thresholds within the parent policer.

Tier 1 and tier 2 explicit arbiters

Other arbiters may be explicitly created in the policy for the purpose of creating an arbitrary bandwidth distribution hierarchy. The explicitly created arbiters must be defined within tier 1 or tier 2 on the policy. Tier 1 arbiters must always be parented by the root arbiter and therefore become a child of the root arbiter. Any child policers directly parented by a tier 1 policer treat the root arbiter as its grandparent. Inversely, the root arbiter considers the child policers as grandchildren. All grandchild policers inherit the priority level of their parent arbiter (the level that the tier 1 arbiter attaches to the root arbiter) within the parent policer.

An arbiter created on tier 2 may be parented by either an arbiter in tier 1 or by the root arbiter. If the tier 2 arbiter is parented by the root arbiter, it is internally treated the same as a tier 1 arbiter and its child policers have a grandchild to grandparent association with the root arbiter.

When a tier 2 arbiter is parented by a tier 1 arbiter, the child policers parented by a tier 2 arbiter are in a great-grandchild to great-grandparent association with the root arbiter. A great-grandchild policer inherits its indirectly parented tier 1 arbiter’s level association with the root arbiter and therefore the parent policer.

A child policer’s priority level on the root arbiter (directly or indirectly) defines which priority level discards thresholds are associated with packets mapped to the child policer for use in the parent policer (assuming the packet is not discarded by its child policer).

Explicit arbiter rate limits

The bandwidth a tier 1 or tier 2 arbiter receives from its parent may be limited by the use of the rate command within the arbiter. When a rate limit is defined for a root arbiter, the system enforces the aggregate rate by calculating a per child policer PIR rate based on the distributed bandwidth per child. This calculated PIR is used to override the child's defined PIR and is represented as the child's operational PIR. The calculated rate is never greater than a child policer's provisioned rate.

CFHP with child policer exceed PIR enabled

A child policer parented to an arbiter can be enabled to forward traffic exceeding its PIR, in which case:

  • Traffic exceeding the operational PIR of the child policer is reprofiled to be exceed-profile, where the operational PIR is determined by the H-pol algorithm from the configuration of the policer parent and the associated arbiters (root or intermediate, or both).

  • Traffic exceeding the child policer's operational PIR and exceed-profile traffic entering the child policer does not consume capacity from the parent policer (meaning that it does not contribute to the parent policer bucket depth with respect to any of its thresholds).

  • Traffic that did not exceed the child policer's operational PIR (when that child is configured with enable-exceed-pir) can exceed its parent rate (max-rate for the root arbiter) in which case the traffic is forwarded and reprofiled to be exceed-profile and its effect on the child policer is revoked (meaning that it does not contribute to any of the child policer bucket (PIR, CIR, FIR) depths with respect to any of its thresholds).

CFHP child policer definition and creation

Policers are created within the context of SAP ingress (sap-ingress) and SAP egress (sap-egress) QoS policies. Policer creation in a QoS policy is defined similar to SAP-based queues. A policer is identified using a policer ID. Queues and policers have different ID spaces (both a policer and queue may be defined with ID 1).

The only create time parameter currently available is the unique policer ID within the policy. Policers do not have a scheduling mode (expedite or best-effort), they also do not need to be placed in in-profile-mode to accept traffic from profile in or profile out forwarding classes or subclasses.

All policers within a SAP ingress or egress QoS policy must be explicitly created. No policers are created by default. After a policer is created, forwarding classes or subclasses may be mapped to the policer within the policy. For ingress, each of the individual forwarding types (unicast, multicast, broadcast, and unknown) may be selectively mapped to a policer, policy-created queue or to an ingress port queue group queue. At egress, forwarding classes are not divided into forwarding types, so all packets matched to the forwarding class may be mapped to either a policer, policy-created queue or egress port queue group queue.

Similar to queues, a policer is not created on the SAPs where the policy is applied until at least one forwarding class is mapped to the policer. When the last forwarding class is unmapped from the policer, all the instances of the policer on the SAPs to which the policy is applied are removed.

Policer enabled SAP QoS policy applicability

Policers are not created on a SAP or subscriber or multiservice site context until at least one forwarding class has been mapped to the policer. Creating a policer within a QoS policy does not cause policers to be created on the SAPs or subscribers or multiservice sites where the policy is applied.

SAP QoS policy applicability and policy policer forwarding class mappings are dependent on policer resource availability. Attempting to map the first forwarding class to a policer causes the policer to be created on the SAPs or subscribers or multiservice site where the policy is applied. If the forwarding plane where the SAP or subscriber or multiservice site exists either does not support policers or has insufficient resources to create the policer for the object, the forwarding class mapping fails.

When a forwarding class is successfully mapped to a policer within the policy, attempting to apply the policy to a SAP or a subscriber or multiservice site where the policer cannot be created either because of a lack of policer support or insufficient policer resources fail.

Policing is supported only on Ethernet SAPs or Ethernet-based subscribers. Policing is also only supported on FlexPath2-based systems or IOMs with the exception of CCAG SAPs or subscribers. This feature applies to the 7450 ESS and 7750 SR only.

Child policer parent association

Each policer configured within a SAP ingress or SAP egress QoS policy may be configured to be child policer by defining a parent arbiter association using the parent command. If the command is not executed, the policer operates as a stand-alone policer wherever the policy is applied. If the parent command is executed, but the defined arbiter name does not exist within the SAP context or a subscriber or multiservice site context, the policer is treated as an orphan. The SAP or subscriber or multiservice site context is placed into a degraded state. The system indicates the degraded state by the system setting the ingress-policer-mismatch or egress-policer-mismatch flag for the object. An orphaned policer functions in the same manner as a policer without a parent defined.

An arbiter exists on a SAP when a policer-control-policy containing the arbiter is applied to the appropriate direction (ingress or egress) of the SAP. An arbiter exists on a subscriber when a policer-control-policy containing the arbiter is applied to the subscriber's sub-profile in the appropriate direction as well (applies to the 7450 ESS and 7750 SR).

Profile-capped policers

Profile-capped mode enforces an overall inplus-profile and in-profile burst limit to the CIR bucket for the following packet types:

  • ingress undefined

  • ingress explicit in-profile

  • egress soft-in-profile

  • egress explicit inplus

  • egress explicit in-profile

The default behavior when profile-capped mode is not enabled is to ignore the CIR output state when an explicit inplus-profile (egress only) and in-profile packet is handled by an ingress or egress policer. The explicit in-profile packets consume CIR tokens up to two times the CBS at which point the bucket stops incrementing and the CIR output for that type of packet enters the non-conforming state. However, the non-conforming state is ignored by the forwarding plane and the packet continues to be handled as inplus-profile or in-profile. Therefore, the total amount of inplus-profile or in-profile traffic can be greater than the configured CIR.

The profile-capped mode makes two changes:

  • At egress, soft-in-profile packets (packets received at ingress as in-profile) are treated the same as explicit in-profile packets (unless explicitly reclassified as out-of-profile) and have an initial policer state of in-profile.

  • At both ingress and egress, any packets output from the policer with a non-conforming CIR state are treated as out-of-profile (out-of-profile state is ignored for initial in-profile packets when profile-capped mode is not enabled).

A profile-capped policer trusts the in-profile state determined at ingress classification or egress reclassification, so the initial in-profile traffic is preferentially handled with the CIR bucket (two times the CBS instead of CBS used by undefined or soft-out-of-profile traffic) and the total amount of inplus-profile or in-profile traffic output by the policer cannot exceed the CIR (including initial in-profile traffic).

Profile-capped mode has an effect on stat-mode behavior. Each stat mode has a fixed number of counters in the forwarding plane. The mapping of packets to a counter is also fixed by the offered packet state (profile inplus, profile in, profile out, undefined, soft-in-profile and soft-out-of-profile) in conjunction with the output state of the policer. In the non-capped mode, soft-in-profile is considered undefined while in capped mode it is considered to be equivalent to profile in. Another potential issue with ingress and egress stat-modes is the fact that green packets (that is, those that are profile in at ingress and egress, or soft-in-profile at egress) can turn yellow in the policer output.

Effect of profile-capped mode on CIR output describes how the CIR rate and initial profile of each packet affects the output of normal (non-profile-capped) and profile-capped mode policers.

Table 1. Effect of profile-capped mode on CIR output
CIR setting Initial profile state Normal mode Profile-capped mode Notes

CIR=0

Ingress undefined

Always out-of-profile

Always out-of-profile

When CIR = 0, the CIR has no effect on the packet profile except for ingress-undefined packets.

If profile-capped is used, this forces all packets to be out-of-profile except for those explicitly reprofiled to exceed-profile.

Ingress profile in

Always in-profile

Always out-of-profile

Ingress profile out

Always out-of-profile

Always out-of-profile

Egress soft-in-profile

Always in-profile

Always out-of-profile

Egress soft-out-of-profile

Always out-of-profile

Always out-of-profile

Egress profile inplus

Always inplus-profile

Always out-of-profile

Egress profile in

Always in-profile

Always out-of-profile

Egress profile out

Always out-of-profile

Always out-of-profile

Egress profile exceed

Always exceed-profile

Always exceed-profile

CIR=Max/PIR

Ingress undefined

Always in-profile

Always in-profile

CIR never reaches non-conforming state.

Ingress profile in

Always in-profile

Always in-profile

Ingress profile out

Always out-of-profile

Always out-of-profile

Egress soft-in-profile

Always in-profile

Always in-profile

Egress soft-out-of-profile

Always in-profile

Always in-profile

Egress profile inplus

Always inplus-profile

Always inplus-profile

Egress profile in

Always in-profile

Always in-profile

Egress profile out

Always out-of-profile

Always out-of-profile

Egress profile exceed

Always exceed-profile

Always exceed-profile

0 < CIR < PIR

Ingress undefined

In-profile below CBS

Out-of-profile at or above CBS

In-profile below CBS

Out-of-profile at or above CBS

Ingress profile in

Always in-profile

In-profile below two times CBS

Out-of-profile at or above two times CBS

Ingress profile out

Always out-of-profile

Always out-of-profile

Egress soft-in-profile

In-profile below CBS

Out-of-profile at or above CBS

In-profile below two times CBS

Out-of-profile at or above two times CBS

Egress soft-out-of-profile

In-profile below CBS

Out-of-profile at or above CBS

In-profile below CBS

Out-of-profile at or above CBS

Egress profile inplus

Always inplus-profile

Inplus-profile below two times CBS

Out-of-profile at or above two times CBS

Egress profile in

Always in-profile

In-profile below two times CBS

Out-of-profile at or above two times CBS

Egress Profile Out

Always Out-of-profile

Always Out-of-profile

Egress Profile Exceed

Always Exceed-profile

Always Exceed-profile

Policer interaction with profile, discard eligibility, and ingress priority

Packets that are offered to an ingress policer may have three different states relative to initial profile:

undefined
either the forwarding class or subclass associated with the packet is not explicitly configured as profile in; profile out or de-1-out-profile is enabled and the dot1p DE bit is set to zero
in-profile
the forwarding class or subclass associated with the packet is configured as profile in
out-of-profile
the forwarding class or subclass associated with the packet is configured as profile out or de-1-out-profile is enabled, and the dot1p DE bit is set to 1

Ingress policed packets are not subject to ingress queue CIR profiling within the ingress policer output queues. While the unicast and multipoint shared queues used by the system for ingress queuing of policed packets may have a CIR rate defined, this CIR rate is only used for rate-based dynamic priority scheduling purposes. The state of the CIR bucket while forwarding a packet from a policer-output-queues shared queue does not alter the packets ingress in-profile or out-of-profile state derived from the ingress policer.

Priority high and low are used in the child policer’s PIR leaky bucket to choose one of two discard thresholds (threshold-be-low and threshold-be-high) that are derived from the child policer’s MBS and high-priority-only parameters. The high threshold is directly generated by the MBS value. The low threshold is generated by reducing the MBS value by the high-priority-only percentage. A packet’s priority is determined while the packet is evaluated against the ingress classification rules in the sap-ingress QoS policy.

Packets that are offered to an egress policer may have six different states relative to their initial profile:

soft-in-profile
the final result at ingress was in-profile and the packet’s profile has not been reclassified at egress
soft-out-of-profile
the final result at ingress was out-of-profile and the packet's profile has not been reclassified at egress
hard-inplus-profile
the profile of the packet has been reclassified at egress as profile inplus
hard-in-profile
the profile of the packet has been reclassified at egress as profile in
hard-out-of-profile
the profile of the packet has been reclassified at egress as profile out
hard-exceed-profile
the profile of the packet has been reclassified at egress as profile exceed

When an egress policer’s CIR rate is set to 0 (or not defined), the policer has no effect on the profile of packets offered to the policer. An exception to this is when enable-exceed-pir is configured under the policer. In this case, the exceed-profile state of a packet takes precedence over the hard-out/in/inplus reclassification, specifically, traffic that is reprofiled to exceed within a SAP egress policer has an exceed-profile state regardless of whether it was reclassified at egress to hard-out, hard-in, or hard-inplus.

Setting a non-zero rate for the egress policer’s CIR modifies this behavior for DSCP, IP precedence, dot1p, and DEI egress marking purposes. Hard-inplus-profile and hard-in-profile retain their inherent inplus-profile or in-profile behavior and the hard-out-of-profile and hard-exceed-profile retain their inherent out-of-profile or exceed-profile behavior.

When the egress packet state is soft-in-profile and soft-out-of-profile and the policer’s CIR is configured as non-zero, the current CIR state of the policer’s CIR bucket overrides the packet’s soft profile state. When the policer’s CIR is currently conforming, the output is in-profile. When the CIR state is currently exceeding, the output is out-of-profile.

Hard-exceed-profile packets are discarded by default by an egress policer. If enable-exceed-pir is configured, the hard-exceed-profile packets are forwarded and, when the PIR state is exceeding, all packets are forwarded with an exceed-profile state.

For egress marking decisions, the hard-inplus-profile, hard-in-profile, and hard-out-of-profile packets ignore the egress policer's CIR state. When the packet state is hard-inplus-profile or hard-in-profile, the in-profile dot1p marking is used, and when DEI marking is enabled for the packet’s forwarding class, the exceed-profile traffic is marked 0. When the packet state is hard-out-of-profile or hard-exceed-profile, the out-of-profile dot1p marking is used, unless explicit dot1p exceed-profile marking is configured, in which case the exceed-profile traffic is marked with the configured value, and when DEI marking is enabled for the packets forwarding class, the exceed-profile traffic is marked 1.

The dot1p, outerDot1p, and DEI (when DE marking is configured) reflect the CIR- and PIR-derived packet state. If the enable-dscp-prec-remarking command is enabled, the DSCP and IP precedence reflect the CIR- and PIR-derived packet state.

Ingress ‛undefined’ initial profile

Access ingress packets have one of three initial profile states before processing by the policer:

  • undefined

  • profile in

  • profile out

The SAP ingress QoS policy classification rules map each packet to either a forwarding class or a subclass within a forwarding class. The forwarding class or subclass may be defined as explicit profile in or profile out (the default is no profile). When a packet’s forwarding class or subclass is explicitly defined as profile in or profile out, the packet’s priority is ignored, and it is not handled by the ingress policer as profile ‛undefined’.

See Effect of profile-capped mode on CIR output to track the ingress behavior of initial profile and the effect of the CIR bucket on that initial state.

At egress, an ingress policer output of ‛in-profile’ is treated as ‛soft-in-profile’ and an ingress policer output of ‛out-of-profile’ is treated as ‛soft-out-of-profile’. Each may be changed by egress profile reclassification or by an egress policer with a CIR rate defined.

Ingress explicitly ‛in-profile’ state packet handling without profile-capped mode

Packets that are explicitly ‛in-profile’ remain ‛in-profile’ in the ingress forwarding plane and are not affected by the ingress policer CIR bucket state when profile-capped mode is not enabled. They do not bypass the policer’s CIR leaky bucket but are extended with a greater threshold than the CBS derived ‛threshold-bc’. This allows the ‛undefined’ packets to backfill the remaining conforming CIR bandwidth after accounting for the explicit ‛in-profile’ packets. This does not prevent the sum of the explicit ‛in-profile’ from exceeding the configured CIR rate, but it does cause the ‛undefined’ packets that are marked ‛in-profile’ to diminish to zero when the combined explicit ‛in-profile’ rate and ‛undefined’ rate causes the bucket to reach ‛threshold-bc’.

The policer’s CIR bucket indicates that the explicit ‛in-profile’ packets should be marked ‛out-of-profile’ when the bucket reaches the greater threshold, but this indication is ignored by the ingress forwarding plane. All explicit ‛in-profile’ packets remain in-profile within the ingress forwarding plane. However, when the packet is received at egress, an ingress ‛in-profile’ packet is treated as ‛soft-in-profile’ and the profile may be changed either by explicit profile reclassification or by an egress policer with a CIR rate defined.

Explicit in-profile packets do not automatically use the high-priority threshold (‛threshold-be-high’) within the child policer’s PIR bucket. If preferential burst tolerance is needed for explicit in-profile packets, the packets should also be classified as priority high.

Ingress explicitly ‛in-profile’ state packet handling with profile-capped mode

When profile-capped mode is enabled, the packet handling behavior defined in Ingress ‛undefined’ initial profile is altered in one aspect. The CIR output state of yellow at the greater threshold is actually honored and the packet is treated as out-of-profile. The packet is sent to egress in the ‛soft-out-of-profile’ state in this case.

Ingress explicit ‛out-of-profile’ state packet handling

Packets that are explicitly ‛out-of-profile’ remain ‛out-of-profile in the ingress forwarding plane. Unlike initially ‛in-profile’ packets, they do not consume the policer’s CIR bucket depth (accomplished by setting the ‛threshold-bc’ to 0) and therefore do not have an impact on the amount of ‛undefined’ marked as ‛in-profile’ by the policer.

While explicit ‛out-of-profile’ packets remain out-of-profile within the ingress forwarding plane, the egress forwarding plane treats ingress out-of-profile packets as ‛soft-out-of-profile’ and the profile may be changed either by explicit profile reclassification or by an egress policer with a CIR rate defined.

Egress explicit profile reclassification

An egress profile reclassification overrides the ingress-derived profile of a packet and may set it to hard-inplus-profile, hard-in-profile, hard-out-of-profile, or hard-exceed-profile. A packet that has not been reclassified at egress retains its soft-in-profile or soft-out-of-profile status.

Egress inplus-profile and in-profile (including soft-in-profile and hard-in-profile) packets use the child policer’s high threshold-be value within the child policer’s PIR bucket while soft-out-of-profile and hard-out-of-profile packets use the child policer’s low threshold-be value. Egress hard-exceed-profile packets are not subject to any threshold control in the child's PIR bucket if enable-exceed-pir is configured; otherwise, they are discarded.

Preserving out of profile state at egress policer

Traffic sent through an egress policer with a non-zero CIR is reprofiled by default based on the CIR threshold of the egress policer. To accommodate designs where traffic is set to be out-of-profile at ingress, and the out-of-profile state is required to be maintained by an egress policer, the parameter profile-out-preserve can be configured under the egress policer. Explicit egress reclassification to the profile takes precedence over the profile-out-preserve operation.

Egress policer CIR packet handling without profile-capped mode

When an egress policer has been configured with a CIR (maximum or explicit rate other than 0) and profile-capped mode is not enabled, the policer’s CIR bucket state overrides the ingress soft-in-profile or soft-out-of-profile state much like the ingress policer handles initial profile undefined packets. If the CIR has not been defined or set to 0 on the egress policer, the egress policer output state is in-profile for soft-in-profile packets and out-of-profile for soft-out-of-profile packets.

If a packet’s profile has been reclassified at egress, the new profile classification is handled in the same way as the ingress policer handling of initial in-profile or out-of-profile packets. When a packet has been reclassified as hard-inplus-profile or hard-in-profile, it is applied to the egress policer’s CIR bucket using a threshold-bc higher than the threshold-bc derived from the policer’s CBS parameter, but the policer output profile state remains inplus-profile or in-profile even if the higher threshold is crossed. When a packet has been reclassified as hard-out-of-profile or hard-exceed-profile, it does not consume the egress policer’s CIR bucket depth and the policer output profile state remains out-of-profile or exceed-profile.

Egress policer CIR packet handling with profile-capped mode

When profile-capped mode is enabled, the egress packet handling described in Egress policer CIR packet handling without profile-capped mode is modified in three ways.

First, the soft-in-profile packets received from ingress are handled in the same way as egress explicit profile in reclassification, unless the packet has been reclassified to profile out or profile exceed at egress.

Second, explicit egress inplus-profile, in-profile, and soft-in-profile packets that have not been reclassified to out-of-profile or exceed-profile at egress are allowed to be marked out-of-profile by an egress policer with a CIR not set to 0.

Third, when a policer has a CIR set to 0 (the default rate), all profile-capped packets are treated as out-of-profile independent of the initial profile state, except for exceed-profile packets that remain as exceed-profile.

Forwarding traffic exceeding PIR in egress policers

An egress policer can be configured to forward traffic that enters the policer with an exceed-profile state or exceeds its operational PIR instead of dropping it. The traffic exceeding the PIR is assigned an exceed-profile state. This is supported for any configured (not dynamic) policer in a SAP egress QoS policy, which can be used for both SAPs and subscribers, and in an egress queue group template that can be used on egress network ports.

When enable-exceed-pir is configured under the policer, the exceed-profile state of a packet takes precedence over the hard-out/in/inplus reclassification, specifically, traffic that is reprofiled to exceed within a SAP egress policer has an exceed-profile state regardless of whether it was reclassified at egress to hard-out, hard-in, or hard-inplus.

The stat-mode offered-total-cir-exceed command provides forward and drop counters for exceed-profile traffic, as follows:

configure
    qos
        queue-group-templates
            egress
                queue-group <queue-group-name> create
                    policer <policer-id> create
                        enable-exceed-pir
                        stat-mode offered-total-cir-exceed
                    exit
                exit
            exit
        exit
        sap-egress <policy-id> create
            policer <policer-id> create
                enable-exceed-pir
                stat-mode offered-total-cir-exceed
            exit
        exit
    exit
exit

The dot1p, outer dot1p, DSCP, and precedence can be remarked for the exceed-profile traffic.

Post egress policer packet forwarding class and profile state remapping

Packets processed by a SAP or subscriber egress child policer can have their forwarding class and profile state remapped to a different forwarding class and profile state after exiting the policer. Remapping is achieved by using a post-policer mapping policy containing mapping statements that determine the remapping of packets based on their forwarding class and profile state.

The post-policer mapping policy is configured as follows:

configure 
    qos
        post-policer-mapping <mapping-policy-name> [create]
            description <description-string>
            fc <fc-name> profile <profile> [create]
                maps-to fc <fc-name> profile <profile>

where:

  • <mapping-policy-name> is the name of mapping policy, up to 32 characters.

  • <description> is the description text string.

  • <fc-name> can be af, be, ef, h1, h2, l1, l2, or nc.

  • <profile> can be in, out, exceed, or inplus.

Up to 32 mapping statements are supported within a policy, covering the maximum combinations of eight forwarding classes and four profile states. A maximum of seven post-policer mapping policies can be configured per system.

After being configured, the post-policer mapping policy must be applied within a SAP egress QoS policy with, at most, one mapping policy per SAP egress QoS policy:

configure 
    qos
        sap-egress <policy-id> [create]
            post-policer-mapping <mapping-policy-name>

Packets entering a child policer are assigned a forwarding class and profile state. The configuration of the policer can change the profile state of the exiting packet, but not the forwarding class. If a post-policer mapping policy is applied within the SAP egress QoS policy, a packet exiting the policer with a specific forwarding class and profile state can be remapped to a different forwarding class and profile state. For example, consider the following post-policer mapping policy:

configure 
    qos
        post-policer-mapping ppm1 create
            fc ef profile exceed create
                maps-to fc be profile out
            exit
        exit

Packets exiting an egress child policer with forwarding class ‟ef” and profile state ‟exceed” have their forwarding class remapped to ‟be” and their profile state to ‟out”.

The mapping applies to all policers within the SAP egress QoS policy, including regular child policers and policers configured in an IP/IPv6 criterion action statement, except for dynamic policers. The remapping does not affect the policer statistics or the parent policer processing (root arbiter) as it occurs after each of these.

The new forwarding class is used to select the egress queue on which the post-policer traffic is placed. The new profile is used to determine the congestion control handling in that queue and its pool, specifically the drop tail or slope that is applied.

Egress packet remarking is based on the marking configured for the forwarding class and profile of the traffic after being policed but before it is remapped.

This remapping is supported on platforms using FP3- and higher-based hardware, with the exception of the 7750 SR-a4/a8, which does not support egress policers.

Remapping a subset of packets from one forwarding class to another could result in out-of-order packets being received at the destination if there is congestion or different latency characteristics on the paths of the different forwarding classes.

Ingress child policer stat-mode

A policer has multiple types of input traffic and multiple possible output states for each input traffic type. These variations differ between ingress and egress.

For ingress policing, each offered packet has a priority and a profile state. The priority is used by the policer to choose either the high- or low-priority PIR threshold-be. Every offered packet is either priority high or priority low. The offered profile state defines how a packet interacts with the policers CIR bucket state. The combinations of priority and initial profile are as follows:

  • offered priority low, undefined profile

  • offered priority low, explicit profile in

  • offered priority low, explicit profile out

  • offered priority high, undefined profile

  • offered priority high, explicit profile in

  • offered priority high, explicit profile out

    Note: When de-1-out-profile is enabled, DEI = 0 is considered as undefined profile and DEI = 1 is considered the same as profile out.

The possible output results for the ingress policer are:

  • output green (in-profile)

  • output yellow (out-of-profile)

  • output red (discard)

To conserve counter resources, the system supports a policer stat-mode command that is used to identify what counters are actually needed for the policer. Not every policer has a CIR defined, so the output green/yellow states do not exist. Also, not every policer has both high- and low-priority or explicit in-profile or out-of-profile offered traffic types. Essentially, the stat-mode command allows the counter resources to be allocated based on the accounting needs of the individual policers.

Setting the stat-mode does not modify the packet handling behavior of the policer. For example, if the configured stat-mode does not support in-profile and out-of-profile output accounting, the policer is not blocked from having a configured CIR rate. The CIR rate is enforced, but the amount of in-profile and out-of-profile traffic output from the policer is not counted separately (or maybe not at all based on the configured stat-mode).

A policer is created with minimal counters sufficient to provide total offered and total discarded (the total forwarded is computed as the sum of the offered and discarded counters). The stat-mode is defined within the sap-ingress or sap-egress QoS policy in the policer context. When defining the stat-mode, the counter resources needed to implement the mode must be available on all forwarding planes where the policer has been created using the QoS policy unless the policer instance has a stat-mode override defined. Use the tools dump resource-usage card fp command to see the resources used and available. If insufficient resources exist, the change in the mode fails without any change to the existing counters currently applied to the existing policers. If the QoS policy is being applied to a SAP or subscriber or multiservice site context and insufficient counter resources exist to implement the configured modes for the policers within the policy, the QoS policy is not applied. For SAPs, this means the previous QoS policy stays in effect. For subscribers, it could mean that the subscriber host event where the QoS policy is being applied fails and the subscriber host may be blocked or removed.

A stat-mode with at least minimal stats is required before the policer can be assigned to a parent arbiter using the parent command.

Successfully changing the stat-mode for a policer causes the counters associated with the policer to reset to zero. Any collected stats on the object the policer is created on also reset to zero.

The system uses the forwarding plane counters to generate accounting statistics and for calculating the operational PIR and FIR rates for a set of children when they are managed by a policer-control-policy. Only the offered counters are used in hierarchical policing rate management. When multiple offered stats are maintained for a child policer, they are summed to derive the total offered rate for each child policer.

All ingress policers have a default CIR value of 0, meaning that by default, all packets except packets classified as profile in is output by the policer as out-of-profile. This may have a negative impact on egress marking decisions (if in-profile and out-of-profile have different marking values) and on queue congestion handling (WRED or queue drop tail decisions when out-of-profile is less preferred). The following options exist to address this potential issue:

  • If all packets handled by the policer must be output as in-profile by the policer, either the packet's forwarding class or subclass can be defined as profile in or the CIR on the policer can be defined as max

  • If some packets must be output as in-profile while others output as out-of-profile, three options exist:

    • The CIR may be left at '0' while mapping the packets that must be output as in-profile to a forwarding class or subclass provisioned as profile in.

    • The CIR may be set to max while mapping the packets that must be output as out-of-profile to a forwarding class or subclass provisioned as profile out.

    • Ignore the CIR on the policer and solely rely on the forwarding class or subclass profile provisioning to the correct policer CIR output.

Make sure to use the correct stat mode if the policer’s CIR is explicitly not set or is set to 0. The no-cir version of the stat-mode must be used when the CIR has a non-zero value. Also, when overriding the policer’s CIR mode, make sure to override the stat-mode instance (CIR override can be performed using SNMP access).

Ingress supported stat-modes are:

  • no-stats

  • minimal - default

  • offered-profile-no-cir

  • offered-priority-no-cir

  • offered-limited-profile-cir

  • offered-profile-cir

  • offered-priority-cir

  • offered-total-cir

  • offered-profile-capped-cir

  • offered-limited-capped-cir

Egress child policer stat-mode

All packets received on the egress forwarding plane are profiled as either in-profile or out-of-profile. The egress forwarding plane treats the ingress-derived profile as a soft state that may be either overridden by an egress profile reclassification or by a CIR rate enforced by an egress policer.

Egress policers have a default CIR set to 0, but in the egress case a value of 0 disables policer profiling. Egress packets on a CIR-disabled egress policer retain their offered profile state (soft-in-profile, soft-out-of-profile, hard-inplus, hard-in-profile, hard-out-of-profile, or hard-exceed-profile) unless the enable-exceed-pir command is configured, in which case the exceed-profile state of a packet takes precedence over the hard-out/in/inplus reclassification.

For egress, the possible types of offered packets include:

  • soft offered in-profile (from ingress)

  • soft offered out-of-profile (from ingress)

  • egress explicit inplus-profile (reclassified at egress)

  • egress explicit in-profile (reclassified at egress)

  • egress explicit out-of-profile (reclassified at egress)

  • egress explicit exceed-profile (reclassified at egress)

The possible output results are:

  • output inplus-profile

  • output in-profile

  • output out-of-profile

  • output discard or exceed-profile

The stat-mode command follows the same counter resource rules as ingress.

Egress supported stat-modes are:

  • no-stats

  • minimal - default

  • offered-profile-no-cir

  • offered-profile-cir

  • offered-total-cir

  • offered-limited-capped-cir

  • offered-profile-capped-cir

  • offered-total-cir-exceed

  • offered-four-profile-no-cir

  • offered-total-cir-four-profile

Details of the output showing the stat-modes for ingress and egress child policers are in the Class Fair Hierarchical Policing for SAPs section of the SR OS Advanced Configuration Guide.

Profile-preferred mode root policers

Configuring the profile-preferred option gives preference for inplus-profile packets or in-profile packets to consume the root policer PIR bucket tokens at a given priority level. This preference applies to packets whose profile is either configured explicitly or set by the output of the child policer CIR bucket.

When this option is selected, all child policers parented to a root policer have their FIR bucket track the state of the CIR bucket. In other words, an inplus-profile or in-profile packet is always blue and an out-of-profile packet is always orange. When admitting packets from the child policers within a specific priority level, orange packets are allowed up to the discard-unfair threshold while blue packets are allowed up to the discard-all threshold. If a child policer is configured to forward traffic exceeding its PIR, the exceed-profile traffic does not contribute to the parent policer bucket depth with respect to any of its thresholds.

The profile-preferred option forces the FIR bucket to track the CIR bucket’s decrement rate and the threshold chosen for the CIR bucket is also be used in the FIR bucket (instead of using the threshold associated with the PIR bucket).

The inplus/in/out/exceed-profile output from the policer is used for packet marking decisions. The blue/orange child policer input to the parent policer chooses the discard-orange or discard-all thresholds for the child policer’s priority level within the parent policer.

Explicit inplus-profile and in-profile packets stay blue up to the high CBS threshold, undefined profile packets stay blue up to the low CBS threshold (1x CBS) and explicit out-of-profile packets are always orange because of a 0 CBS threshold. Orange packets are discarded by the parent policer within the child policer’s priority level before the blue packets, preferring blue packets over orange when the discard-orange threshold is crossed.

Use the following CLI syntax to configure the profile-preferred option. This option also applies to overrides applied to instances of a policer control policy under a SAP or subscriber or multiservice site context.

config qos
      policer-control-policy policy-name [create]
      no policer-control-policy policy-name
            description ‟description-string”
            no description
            root
                  max-rate {kilobits-per-second | max}
                  no max-rate
                  [no] profile-preferred
                  priority-mbs-thresholds
                        min-thresh-separation size [bytes | kilobytes]
                        no min-thresh-separation
                        priority level
                              mbs-contribution size [bytes | kilobytes] [fixed]
                              no mbs-contribution

The profile-preferred option provides us a way to configure a specific FIR (because it uses the CIR as FIR). In the direct-parented case (no intermediate arbiters present at all) the child policers do not need to have their offered rate polled as each policer always has PIR equal to the min (child PIR, root PIR) and the FIR and CIR are fixed and equal. The child parenting weights are therefore not used. This impacts the show commands, for example, offered rate information is not available. The output of some show commands (for example, show qos policer-hierarchy card detail) should be adjusted for profile-preferred configurations.

If an intermediate arbiter is present, then polling is offered at different rates because the child policer PIRs are set based on this information so as to share the intermediate arbiter PIR in proportional to their parenting weight to the intermediate arbiter.

Child policer hierarchical QoS parenting

Policers can be parented into the QoS hierarchy used for queue and scheduler bandwidth control, referred to as hierarchical QoS (HQoS). This allows the bandwidth of policers, queues, and schedulers to be managed in the same HQoS hierarchy.

HQoS builds a scheduling hierarchy for a queue by parenting it into a scheduler or port scheduler. The schedulers can be parented into other schedulers to create multiple tiers or into a port scheduler that can exist on a Vport or port.

Parenting a policer into HQoS is supported at egress for subscribers and SAPs, with multiservice sites (MSS) supported for SAPs. A post-policer local queue is not supported with HQoS managed policers, nor are queues that are mapped by the use-fc-mapped-queue parameter in a criteria action statement.

To enable the parenting of an egress policer into HQoS, the following command is configured in the SAP egress QoS policy:

configure
  qos
    sap-egress policy-id
      policers-hqos-manageable
    exit

When the policers-hqos-manageable command is configured, all policers in the SAP egress QoS policy, except for dynamic policers, can be managed by HQoS. To be managed by HQoS, the policer must be configured with either a scheduler-parent or port-parent command or be orphaned to an egress port scheduler applied on a Vport or port.

The no policers-hqos-manageable command results in policers not being managed by HQoS.

If the policers-hqos-manageable command is used, the parent-location sla, policers enable-exceed-pir, or policers stat-mode no-stats commands may not be used within an SAP egress QoS policy.

Egress policers can be parented into a scheduler in a scheduler policy using the scheduler-parent command:

configure
  qos
    sap-egress policy-id
      policer policer-id
        scheduler-parent scheduler-name [weight weight] 
        [level level] [cir-weight cir-weight] 
        [cir-level cir-level]
      exit
    exit

When a scheduler is specified, no checks are performed as to whether the scheduler exists. If the scheduler-name does not exist, the policer is placed in an orphaned operational state. The policer accepts packets but is not bandwidth-limited by a virtual scheduler or the scheduler hierarchy applied to the SAP or subscriber. Consequently, an orphan policer operates in the same way as a non-HQoS-managed policer. On a SAP, the orphan state is indicated in the show service sap-using command output with the SapEgressPolicerMismatch flag. This flag is automatically cleared when the scheduler-name becomes available on the egress SAP.

The level and cir-level keywords define the level in the HQoS hierarchy to which the policer parents for the above-CIR and within-CIR bandwidth distribution passes, respectively. If the cir-level is set to 0, the policer does not get any bandwidth allocated in the within-CIR pass.

The weight and cir-weight keywords define the relative weight of this policer in comparison with other child policers, queues, or schedulers at the same level when competing for bandwidth on the parent scheduler-name at the above-CIR and within-CIR bandwidth distribution passes, respectively. If the weight or cir-weight is set to 0, the policer receives bandwidth only after other children with a non-zero weight at this level are serviced.

If limit-unused-bandwidth is configured in the HQoS hierarchy to which the policer is parented, only the offered rate increasing in the last sampled period is used to determine that the policer has accumulated work.

Egress policers can also be parented into a port scheduler using the port-parent command:

configure
  qos
    sap-egress policy-id
      policer policer-id
        port-parent [weight weight] [level level] 
        [cirweight cir-weight] [cir-level cir-level]

If the exit port used by the policed traffic is configured with a port scheduler but the policer has neither a scheduler parent nor a port parent, or if it is orphaned (its scheduler parent does not exist), then the policer is fostered by the port scheduler.

When parenting to a port scheduler, the subscriber profile or SAP can use an egress aggregate rate limit to control its traffic rate.

The policer scheduler-parent and port-parent commands are mutually exclusive; configuring one overrides the other. These commands and with the policer parent command (that parents the policer to an arbiter) are also mutually exclusive.

The system does not prevent the configuration of a policer control policy for a SAP, multiservice site, or subscriber using HQoS managed policers. The arbiters for these policer control policies are not used but are allocated, so must be accounted for when considering scaling.

The configuration of profile-out-preserve and profile-capped is permitted for HQoS policers with these configurations affecting the within-CIR and above-CIR statistics for the HQoS managed policer.

The purpose of parenting a policer to HQoS is to measure the policer traffic in the HQoS hierarchy so that the configured HQoS bandwidth allocation can be enforced. When traffic passes through the policer, it exits through an access egress queue group queue. If the queue group queue was also parented to the same HQoS hierarchy, the policed traffic would be measured twice: one time through the HQoS managed policer, then a second time through a post-policer access egress queue group queue. To prevent the traffic from being measured the second time, the queue group queues must be configured so that they are not managed by HQoS, as follows:

configure
  qos
    queue-group-templates
      egress
        queue-group queue-group-name
          no queues-hqos-manageable

The default for the queues-hqos-manageable command is to allow the queues to be managed by HQoS.

When no queues-hqos-manageable is configured, all queues in the egress queue group instances using this template are not managed by HQoS. This command and the configuration of policers and queue packet-byte-offset within the egress queue group template are mutually exclusive. The configuration of no queues-hqos-manageable is permitted in the default egress policer-output-queue queue group template, which avoids the need to create additional queue groups when policers managed by HQoS are used.

When a queue group template with no queues-hqos-manageable is configured under a port's Ethernet access egress context, the configuration of an aggregate rate or scheduler policy is not permitted under that context, nor are parent overrides for any of the queues in the queue group. If a port scheduler is configured on the port, the queue group queues are not parented to the port scheduler.

The configuration of an encap-offset within the egress of a subscriber profile does not apply to policer traffic that exits through egress queue group queues.

A queue group configured with no queues-hqos-manageable should only be used for post-policer traffic from policers in a SAP egress QoS policy configured with policers-hqos-manageable. In this case, the traffic is only measured once by HQoS.

Avoid the following scenarios as they may cause HQoS results to be inaccurate:

  • Passing traffic through policers in a SAP egress QoS policy configured with policers-hqos-manageable, exiting through a queue group queue with its queue group template configured with queues-hqos-manageable causes the traffic to be measured twice by HQoS.

  • Passing traffic through policers in a SAP egress QoS policy configured with no policers-hqos-manageable, exiting through a queue group queue with its queue group template configured with no queues-hqos-manageable causes the traffic not to be measured by HQoS.

  • Passing traffic that is redirected in a SAP egress QoS policy to the queue group queue that has no queues-hqos-manageable configured in its queue group template causes the traffic not to be measured by HQoS.

  • Parenting policers to a scheduler policy for SAPs or subscribers active on a distributed mode LAG with member ports on multiple FPs on the same line card causes a policer to be instantiated for each FP on the line card, potentially resulting in a higher share of traffic than intended.

For each of the preceding cases, the following applies:

  • for SAPs, a mismatch flag, SapEgressHQosMgmtMismatch, is displayed in the show service id service-id sap sap-id detail command output.

  • for subscribers, the show service active-subscribers detail command output indicates Egr hqos mgmt status : mismatch under the SLA profile instance. The output displays Egr hqos mgmt status : enabled when policer HQoS parenting is correctly configured.