[c-nsp] ASR9k Bundle QoS in 6.0.1

Adam Vitkovsky Adam.Vitkovsky at gamma.co.uk
Thu Jun 16 07:38:36 EDT 2016

> Robert Williams
> Sent: Thursday, June 16, 2016 9:33 AM
> Hi,
> Got to the bottom of this at last!
> [The new command enables a feature which works as follows]
> - Whenever a policy is applied on the bundle member – first a ratio can be
> calculated based on total bundle bandwidth to bundle member’s bandwidth
> as follows: (ratio = bundle bandwidth/member bandwidth)
> - For example if the bundle bandwidth is 20 Gbps with two bundle member
> bandwidth 10 Gbps, then the reduction will be 2/1 (0.5 * policy rate) for both
> members.
> - With bundle bandwidth 50G (with 10G+40G members) the ratios become
> 5/1 and 5/4 respectively.
> - The feature will then automatically recalculate the member-port QoS rate
> whenever a change among bundle occurs. i.e. bundle member
> active/down/added/removed.
> - If traffic is load balanced well among the bundle members, then in
> aggregate the bundle-ether traffic will be shaped to the policy rate, matching
> the QoS policy configuration (instead of being members*rate).
> [CLI for Aggregated Bundle QoS Mode]
> Enable the mode:  (config)# hw-module all qos-mode bundle-qos-aggregate-
> mode Disable the mode: (config)# no hw-module all qos-mode bundle-qos-
> aggregate-mode
> - The above commands take effect chassis wide. (I don't believe you can
> enable/disable it per bundle).
> - When the aggregated bundle mode changes, QoS polices on bundle
> intfs/subintfs are modified automatically.
> - Reloading line card is not required.
> So essentially it will now automatically do what we have been doing manually
> by recalculating the 'rate' based on the desired rate (div) No. members.
> From what I can see (at least in our scenario) the pros/cons are:
> [Advantages]
> - Is proportional to unbalanced members (40G+10G) or (10G+1G).
> - Automatically responds to addition/loss of a member, LC failure etc.
> dynamically.
> - Doesn't require future engineers to remember to make changes to the
> base rate when modifying bundle members.
> [Disadvantages]
> - Assumes good balance, will over-police if traffic is not evenly distributed
> between member ports.
> - Still doesn't fix the problem of an egress rate limit on a BVI being applied
> (multiplied by) the number of ingress NPs when the destination port is a
> single interface.
> Hope that may be of some use to anyone looking for this in the future!
> Cheers,
Thank you very much Robert for getting back to the list.
So it looks like with this feature it works exactly as Junos default "scale mode" (although I'm not sure if Junos can adapt the rate based on different interface BW or just based on number of active bundle members).

I'm curious to see whether there are any gotchas, like: " Shaping rate is not scaled if you configure it as a percentage of the available interface bandwidth".


        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com

More information about the cisco-nsp mailing list