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.