Usage guidelines for QoS policies on link bundles

• QoS policies are configured on link bundles in the same manner as they are on individual interfaces.

• When you apply a QoS policy on a bundle (in either ingress or egress direction), the queuing policy is automatically applied to each member interface. The reference bandwidth used for calculating shaper or bandwidth values is derived from the physical member interface, not the aggregate bundle bandwidth.

• The QoS policy applied to the bundle is inherited by all member links. The reference bandwidth used for shaping and scheduling is based on the bandwidth of each physical member interface, not the aggregate bandwidth of the bundle.

• The effective aggregate shaped rate depends on the number of active bundle members and how traffic is distributed across those members.

• If a QoS policy is not applied to a bundle interface, both the ingress and egress traffic use the default queue of the per link member port.

• The shape rate specified in a bundle policy map is not an aggregate rate for all bundle members. The configured shaper rate is applied per bundle member, and the effective aggregate shaped rate depends on traffic distribution across active member links.

  For example, if a 10 Mbps shaping policy is applied to a bundle with two member links and all traffic flows through one member, the total shape rate remains 10 Mbps. However, if traffic is balanced evenly across both members, the combined shaping rate becomes 20 Mbps.

• Add bundle members before you apply the QoS policy to the bundle. This action ensures that the QoS policy applies across the bundle and on the new member.

  If you add a new member after the policy is applied, and the new member’s configuration is incompatible, the policy may fail to propagate and cause configuration errors.

• For absolute-value shapers on bundle interfaces, the configured shaper rate is replicated on each bundle member interface. The configured value is not a single aggregate bundle-wide shaper rate.

• If you add a lower-bandwidth member to a bundle that already has an absolute-value shaper policy, the commit can succeed, but member policy replication can remain incomplete for that member.

  To recover, remove the lower-bandwidth member, reduce the shaper rate so that it is less than or equal to the bandwidth of that member, and add the member again.

  If in-place policy modification fails after bundle member changes, remove the egress service policy from the bundle interface, update the shaper rate, and apply the egress service policy again.

• If you add a lower-bandwidth member to a bundle that already has an absolute-value shaper policy, the commit can succeed, but member policy replication can remain incomplete for that member.

  To recover, remove the lower-bandwidth member, reduce the shaper rate so that it is less than or equal to the bandwidth of that member, and add the member again.

• If in-place policy modification fails after bundle member changes, remove the egress service policy from the bundle interface, update the shaper rate, and apply the egress service policy again.

• When you encounter a queue-limit error, remove the existing QoS policy from the bundle interface. The removal process may take up to ten minutes to take effect, depending on the time elapsed since the error occurred. To monitor progress, check the Retries performed information in the syslog message.

• If a queue-limit error occurs, the syslog lists only one interface, even if multiple interfaces are affected. Review operations in the syslog to determine the number of affected interfaces.

When you remove a member interface from a bundle, the total bundle statistics change because the counters associated with the detached link are lost. Always capture statistics before removing member links to ensure accurate reporting.

• Classification resources (TCAM or MAP) and counters are allocated per bundle interface.

• Queuing resources (VOQs) and counters are allocated per bundle member interface.

• You can apply a policing policy on either the bundle’s main interface or a bundle subinterface. You cannot apply it to both at the same time.

• For absolute-value bundle policers, the configured CIR and PIR values are applied per logical hardware unit. On A100, K100, and P100-based Cisco 8000 routers, the logical hardware unit is a slice. On Q200-based Cisco 8000 routers, the logical hardware unit is an interface group.

  If bundle members are spread across multiple slices or interface groups, each participating logical hardware unit can enforce the configured CIR and PIR independently. Do not interpret the configured value as a single aggregate bundle-wide policer in that case.

• You can apply the queuing policy on the bundle’s main interface or on its subinterface. You cannot apply it to both interfaces simultaneously.

• You can apply classification and marking policies on the bundle main interface or on its subinterface. You cannot apply these policies to both interfaces at the same time.