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.
