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
Nice! I have a couple of comments.
The reason you need to shape slower, is because I believe most shapers don't account for L2 overhead. I've found 15% slower often works well, but actual optimal percentage depends on packet sizes.
I often recommend FQ because if keeps a few bandwidth intensive flows from being detrimental to other lightweight flows. BTW pre-HQF CBWFQ actually used WFQ, but your HQF CBWFQ uses just FQ.
If you find just class-default FQ isn't sufficient for your traffic QoS needs, you can work yourself up to something like:
policy-map sample
class real-time
priority percent 33
class high
bandwidth remaining percent 81
fair-queue
class low
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue
Real-time traffic (e.g. VoIP bearer, etc.) is directed to the LLQ. High priority, light weight traffic (e.g. VoIP signalling, screen scraping, etc.) is directed to the high class. Bandwidth hog traffic (e.g. FTP bulk copies, etc.) is directed to the low class. Everything else stays in class-default.
