• 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.

• 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 rate applied to the bundle depends on traffic distribution.

  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.

• 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.

• Configure Committed Information Rate (CIR) and Peak Information Rate (PIR) values using percentage units only. You cannot use absolute values on bundle interfaces.

• Policers and their counters are allocated to each bundle interface. They are not allocated to individual member links.

• 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.

• Link bundling is supported only on Ethernet interfaces. Other interface types cannot participate in a bundle.

• Each bundle must contain only physical links. You cannot add subinterfaces or virtual interfaces to a link bundle.

• All links within a bundle must run the same bundling protocol—either IEEE 802.3ad (LACP) or EtherChannel (non-LACP). Mixing protocols within a single bundle is not supported.

• QoS shapers on bundle interfaces support only relative, percentage-based configurations. Absolute shaper values are not supported.

• Ethernet link bundles do not support MAC-level accounting. To collect traffic statistics, use higher-layer QoS counters instead.

• Each bundle can include a maximum of 64 Ethernet links.

• The maximum number of link bundles supported is 128.