The limit-unused-bandwidth (LUB) command protects against exceeding the aggregated bandwidth by adding a LUB second-pass to the H-QoS function, which ensures that the aggregate fair-share bandwidth does not exceed the aggregate rate.
The command can be applied on any tier 1 scheduler within an egress scheduler policy or within any agg-rate node and affects all policers and queues controlled by the object.
When LUB is enabled, the LUB second pass is performed as part of the H-QoS algorithm The order of operation between H-QoS and LUB is as follows:
-
Policer or queue offered rate calculation.
-
Offered rate modifications based on adv-config-policy offered-measurement parameters.
-
H-QoS Bandwidth determination based on modified offered-rates.
-
LUB second pass to ensure aggregate rates are not exceeded where LUB enabled.
-
Bandwidth distribution modification based on adv-config-policy bandwidth-distribution parameters.
-
Each policer or queue operational PIR is then modified.
When LUB is enabled on a scheduler rate or aggregate rate, a LUB context is created containing the rate and the associated policers and queues that the rate controls. Because a policer or queue may be controlled by multiple LUB enabled rates in a hierarchy, the policer or queue may be associated with multiple LUB contexts.
LUB is applied to the contexts where it is enabled. LUB first considers how much of the aggregate rate is unused by the aggregate rates of each member policer or queue after the first pass of the H-QoS algorithm. This represents the current bandwidth that may be distributed between the member. LUB then distributes the available bandwidth to its members based on each LUB-weight. The LUB-weight is determined as follows:
If a policer or queue is using all of its default H-QoS assigned rate, then its LUB-weight is 0. It is not participating in the bandwidth distribution as it cannot accept more bandwidth.
If a policer or queue has accumulated work, its LUB-weight is set to 50. The work is determined by the queue having built up a depth of packets, or the offered rate of a policer or queue increasing since last sample period. The aim is to assign more of the unused bandwidth to policers and queues needing more capacity. No attempt is made to distribute based on the relative priority level or weight within the hierarchy of a policer or queue.
Otherwise, a queue’s LUB-weight is 1
The resulting operational PIRs are then set such that the scheduler or agg-rate rate is not exceeded. To achieve the best precision, policers and queues must be configured to use adaptation-rule pir max cir max to prevent the actual rate used exceeding that determined by LUB.
Example
For a simple scenario with 5 egress SAP queues all without rates configured but with each queue parented to a different level in a parent scheduler that has a rate of 100Mb/s, see Figure: Limit unused bandwidth example.
The resulting bandwidth distribution is shown in Figure: Resulting bandwidth distribution; first, when no traffic is being sent with and without LUB applied, then when 20 Mb/s and 40 Mb/s are sent on queues 3 and 5, respectively, again with and without LUB applied. As shown, the distribution of bandwidth in the case where traffic is sent and LUB is enabled is based on the LUB-weights.
