Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

bandwidth remaining QoS config

I just wanted to confirm my understanding on a sample QoS configuration I created here.

policy-map child

class video

  priority percent 10

class voip

  priority percent 15

class replication

  bandwidth remaining percent 50

class gold

  bandwidth remaining percent 15

class vpn

  bandwidth remaining percent 30

class class-default

  random-detect

policy-map parent

class class-default

  shape average 10000000

  service-policy child

This policy will be applied to a GigE interface that is connected to a metro ethernet connection with an SLA of 10Mbps.  I want to make sure that when the priority traffic is not in using all of it's bandwidth (low amount of phone calls or no video conference going on) that other data classes are given the resources it needs.  This is important because we are replication Data Domain traffic over this metro link as well.  We are starting to have some backlogging issues.  I want to allow Data Domain replication to comsume as much bandwidth as needed during normal business hours, however, when VPN traffic, and other important data traffic need resources, I want my QoS policy to allow it.  Right now we shape replication to 7Mbps to allow room for other traffic, but I am considering removing shaping.

Will this policy do the trick?  I am pretty sure this will work, but I wanted to double check before I promote something like this to my production network.

Thanks in advance.

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions

bandwidth remaining QoS config

Ugh...now you want me to do math ... fair warning

Okay...the priority percent is going to be based off of your 10Mb link. The bandwidth remaining is based off of what wasn't already allocated to other classes.

If your priority classes were completely maxed out:

priority percent 10 - Guaranteed and policed at 1Mb

priority percent 15 - Guaranteed and policed at 1.5Mb

                                                               Total 2.5Mb

That leaves 7.5Mb

So I get 2.25Mb for VPN....it looks like the math is right...

HTH, John *** Please rate all useful posts ***
10 REPLIES
New Member

bandwidth remaining QoS config

Oh, and I want higher rates when priority traffic is not in use, hense why I used "bandwidth remaining percent".

bandwidth remaining QoS config

Personally, I don't see anything wrong with the config. The bandwidth percent/remaining percent guarantees you'll get that much during congestion, but it will allow full bandwidth utilization when nothing else is in the queue. Bandwidth remaining isn't used very often though.

HTH, John *** Please rate all useful posts ***
New Member

bandwidth remaining QoS config

So lets say there is no priority traffic on the link, and replication is taking all of the 10Mbps.  A VPN client connects and starts to download a large file from the network.  The VPN client should get 3000Kbps in that case, correct?  Since o priority traffic is on the link and VPN is allowed 30% of what remains (which is all 10Mbps).

Worst case if all priorty classes are maxed out (video and voice),  VPN would get 2250Kbps (as indicated on "show policy-map int int" command), correct?

I just want to make sure I get the most of out of this circuit and make sure my understanding on bandwidth remaining is accurate.

bandwidth remaining QoS config

Ugh...now you want me to do math ... fair warning

Okay...the priority percent is going to be based off of your 10Mb link. The bandwidth remaining is based off of what wasn't already allocated to other classes.

If your priority classes were completely maxed out:

priority percent 10 - Guaranteed and policed at 1Mb

priority percent 15 - Guaranteed and policed at 1.5Mb

                                                               Total 2.5Mb

That leaves 7.5Mb

So I get 2.25Mb for VPN....it looks like the math is right...

HTH, John *** Please rate all useful posts ***
New Member

bandwidth remaining QoS config

Thanks!

bandwidth remaining QoS config

Thanks for the rating!

HTH, John *** Please rate all useful posts ***

Re: bandwidth remaining QoS config

As J. says- bandwidth remaining is not that often used.

You could say

class video

  priority percent 10

class voip

  priority percent 15

class replication

  bandwidth percent 37    !  = bandwidth remaining 50%  (= (100 - 10 - 15)/2) !100 should be 75 by default -see *

class gold

  bandwidth percent x  (x =15% (100-10-15-37) )

class next

bandwidth percent y

you see how difficult it is? Each next class guaranteed bandwidth depends of the previous remaining bandwidths. I think it's better to configure it in the opposite way. By asking yourself - how much bandwidth do I want to guarantee minimum (maximum for LLQ - priority queues - starvation)

By default, when the bandwidth percent and priority percent commands are used to allocate bandwidth, the sum of the bandwidth percentage allocated to the high priority traffic and the bandwidth percentage allocated to the non-priority traffic cannot exceed 75 percent of the total bandwidth available on the interface.

The remaining 25 percent of the total bandwidth available on the interface is kept in reserve for the unclassified traffic and routing traffic, if any, and proportionally divided among the defined traffic classes. To override the 75 percent limitation, use the max-reserved bandwidth command in interface configuration mode.

When using bandwidth remaining - the remaining bandwith is calculated based on the max-remaining bandwidth of the interface

class video

  priority percent 10

class voip

  priority percent 10

class test

bandwith remaining percent x 

Eg. 10 Mbps interface

Results for class test

x percent of remaining bandwidth (7,5 Mbps (default) - 1 Mpbs (=10% voice of 100% bw) - 1 Mbps(=10% video of 100% bw)) =

x% of 5,5 Mbps

Super Bronze

Re: bandwidth remaining QoS config

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

Some IOS versions, if I remember correctly, will show the actual calculated bandwidth per class.  You might try a show policy interface and see if your version does.

Different IOS versions also have different rules in bandwidth calculations.  There's a major difference between pre-HQF and HQF policies, and some IOS/platforms are different still (e.g. the EOL 7500s, FlexWAN cards, SIP-200/400).

"Remaining bandwidth" has nothing to do with actual available bandwidth when there's congestion between queues, it's just a different method to specify how bandwidth is to be proportioned to a class.

I recall (?) earlier versions of CBWFQ didn't support any percentages.  This made it inconvenient to use the same policy on interfaces of different bandwidths unless you understood exactly how bandwidth, on classes work.

If I had a fractional T1 of 1 Mbps, you might want a policy like:

policy-map example

class low-volume

bandwidth 200

class high-volume

bandwidth 800

This would fail on earlier CBWFQ versions because there's always a default-class, and in earlier versions, it "reserves" 25% of the bandwidth.  For those versions, if you reset the interface default to allow 100% allocation, the prior policy would work with 1 Mbps, but wouldn't work on 500 Kbps fractional T1.

The above policy allows either class to use all available bandwidth.  Only when all classes want full bandwidth, do you obtain the defined "reservations".  For example, in the above policy, if high-volume traffic only offered 300 Kbps, low-volume could use 700 Kbps.

What's important to realize, CBWFQ actually assigns relative weights to classes, so the following, example2, really is much the same.

policy-map example2

class low-volume

bandwidth 20

class high-volume

bandwidth 80

This policy, though, could be assigned to the 500 Kbps fractional T1.  It could also be assigned to the 1 Mbps fractional T1 without needing to change the default reserve allocation.  It would also work about the same, without changing the default reserve allocation, if there was no traffic in class-default.  (NB: again, there's always a class-default, i.e. it can be implicit.)

Also again, it's really better to understand bandwidth proportion between the two classes are 1:4, in either example, although we're use to thinking in "bandwidth reservations", but that's not how the CBWFQ scheduler really works.

To make things "clearer", CBWFQ policies can use percentages.

policy-map exampleA

class low-volume

bandwidth percent 20

class high-volume

bandwidth percent 80

and

policy-map example2A

class low-volume

bandwidth percent 2

class high-volume

bandwidth percent 8

Would work much as described, although now you need not worry about exceeding the bandwidth assigned to the interface.  Remember bandwidths of 200/800 couldn't be used on a 500 Kbps fractional T1, but either of the percent usage policies could.

In later IOS versions, remaining percentage was allowed, so you could have a policy like:

policy-map example3

class low-volume

bandwidth percent 20

class high-volume

bandwidth remaining percent 100

This policy also create 1:4 proportion.  However example3 is not the same as:

policy-map example3a

class low-volume

bandwidth percent 2

class high-volume

bandwidth remaining percent 100

or

policy-map example3b

class low-volume

bandwidth percent 20

class high-volume

bandwidth remaining percent 80

So far, I've only discussed defined classes, but as your child policy has a class-default, you should know some (pre-HQF, non-7500 like) CBWFQ only supports fair-queue in class-default.  When used there, each FQ flow is independently scheduled, which effectively distorts all you other class bandwidth allocations.  I recall for these CBWFQ version, FQ is also the default for class-default.

I could go on, but suspecting you just want a policy that works, you might try:

policy-map childA

class LLQ

  priority percent 30

class class-default

  fair-queue

or

policy-map childB

class LLQ

  priority percent 30

class replication

  bandwidth remaining percent 1

class class-default

  fair-queue

Which depends on how many flows replication might generate.  If very few, use childA, if not very few, use childB.

Also, not all shapers account for L2 overhead, if your doesn't you might need to set the shape rate down by about 5 to 15%.  Additionally, for VoIP you might need to decrease the shaper's default Tc (if 25 ms).

PS:

If your IOS supports HQF (and if not, consider upgrading to one that does), you have a policy like:

policy-map childHQF

class LLQ

  priority percent 30

class replication

  bandwidth remaining percent 1

  fair-queue

class gold

  bandwidth remaining percent 49

  fair-queue

class vpn

  bandwidth remaining percent 25

  fair-queue

class class-default

  bandwidth remaining percent 25

  fair-queue

Adjust percentages as needed.

New Member

Re: bandwidth remaining QoS config

Wow Joseph, thanks for all of that.

Yes, when running show policy-map, it does show the minumum bandwidth and it allocates it as I expected.

Here is my question.  That there seems to be a lot of confusion on.

If my priority queues are not using the minimum guaranteed bandwidth, will that "excess" be distrubuited to all of the "bandwidth remaining" classes.

I am running IOS 15.1(4)M1 on a 3845 ISR, so it does support HQF.

Super Bronze

Re: bandwidth remaining QoS config

Disclaimer

The     Author of this posting offers the information contained within this     posting without consideration and with the reader's understanding  that    there's no implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not   be construed as rendering professional advice of any kind.   Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In     no event shall Author be liable for any damages whatsoever   (including,   without limitation, damages for loss of use, data or   profit) arising  out  of the use or inability to use the posting's   information even if  Author  has been advised of the possibility of  such  damage.

Posting

Here is my question.  That there seems to be a lot of confusion on.

If my priority queues are not using the minimum guaranteed bandwidth, will that "excess" be distrubuited to all of the "bandwidth remaining" classes.

Any actual bandwidth that's not being used for actual traffic is available to other classes.  Whether other class traffic can use that bandwidth depends whether that class is being policed or shaped.  (BTW, LLQ classes can exceed their limit if there's actual excess bandwidth.)

NB: "remaining" doesn't have anything to do with actual excess bandwidth usage, only how weight for a class is calculated. "Remaining" allocates/calculates from the aggregate of non-remaining.  So for example if 40% has been allocated non-remaining, 100% remaining would be 60%; or if 70% has been allocated non-remaining, 100% remaining would be 30%.  The advantage of this approach is you don't have to reallocate all percentages with some class bandwidth percentage changes.


I am running IOS 15.1(4)M1 on a 3845 ISR, so it does support HQF.

It should.

7461
Views
5
Helpful
10
Replies
CreatePlease to create content