Has anyone implemented HQF on IOS version c1841-advipservicesk9-mz.124-25b.bin? Just wwanted to make sure that user configured classes do not starve out the best effort class traffic, by assigning bandwidth xx to this class also. Prior version did not allow this to be set up on classes with fair-queue.
I'm only experimented a bit with HQF QoS on 2800s, 3800s and 7200s, not any 1800s, and have not used HQF in productions for other issues in IOSs later than 12.4(15)T. It's very much like the QoS that was found on 7500s and still found on 6500/7600 FlexWAN and SIP-200/400 cards, I believe. Did construct CBWFQ classes, on 7500s, that used both FQ and bandwidth in multiple classes including class-default. At least on that platform, appeared to work as expected.
Thanks. But it appears now that HQF is available only on T train or in new version 15, so was not sure if 12.4 25b supports it. I can not upgrade IOS unless I am onsite and wanted to set up some QoS for Video but wanted to make sure during video conferencing, other traffic does get some decent bandwidth. One option then can be to use priority bandwith for video, so that it is policed and hence does not get anymore than configured.
Yes, that's correct that HQF isn't available in your existing 12.4.25b IOS. (Sorry, overlooked that part of your initial post.) Believe, first HQF variant released with 12.4(20)T.
If you want to define a CBWFQ class for video conferencing, unclear why you believe you might need or would prefer HQF.
For real-time traffic like video conferencing, I believe a LLQ class for such traffic is often a suitable configuration. As far as the class's implict policer protecting other traffic from bandwidth starvation, such a policer is really more to protect from unexpected LLQ bandwidth utilization. I.e., expected video conferencing bandwidth shouldn't hit its class bandwidth limit.
My past experience has been that CBWFQ does not behave as we think. In the examples for HQF that I saw, it seemed that now you can include bandwidth commands and fair-queue within a class of policy-map. So even default class traffic will then have chance of getting some decent bandwidth when congestion hits. Else, almost all bandwidth is taken by all user defind class (with bandwidth allocated, in proportion to the bandwidth configured on the classes) and dafault class practically get just 1% or so. I wanted to keep priority (LLQ)bandwidth for upcoming voice requirement and hence did not want to use that for video, I am sure you would have run into this issue as well.
Yes, HQF works differently as you describe. The issue with any class obtaining sufficient bandwidth, including class-default, is just to assign it bandwidth. On the whole, HQF, I believe, like the 7500, FlexWAN and SIP-200/400 QoS, is a better implementation. The only area I do fault Cisco is its activation without any kind of override or new syntax. I.e., an existing CBWFQ might work differently when the IOS is upgraded. (E.g. class-default FQ bandwidth working differently w/o an explicit bandwidth statement. [Also it's just FQ an no longer WFQ.])
As to keeping VoIP separate from video conferencing, that's why you can assign multiple LLQ classes. Each shares the same physical queue, but each is limited by its policer. Since all such traffic is real-time, and bandwidth requirements should be known, there shouldn't be any issue sharing the same physical queue.
If the video was streaming, not real-time like video conferencing, then it's generally best placed into a non-LLQ class.
So you mean, I can do bandwidth statement on default-class also which has fair-queue? That was the whole issue, unless it is supported in recent non T 12 versions?
I agree with you on video conf and voice to share same physical priority queue. May be that is what I should do to ensure video does not grab more than allocated priority bandwidth.
"So you mean, I can do bandwidth statement on default-class also which has fair-queue?"
Believe the answer if yes if HQF QoS (or 7500, etc., QoS).
". . . what I should do to ensure video does not grab more than allocated priority bandwidth."
You can either control it with the implicit policer (dedicated LLQ class) and/or add an explicit policer or shaper. (Why the latter you might wonder? With an explicit policer you can use it to remark packets instead of just dropping them. With an explicit shaper you can queue the packets instead of dropping them. [Also both the explicit policer and shaper don't depend on actaul interface congestion as does the implicit policer.])
Ok, great as far as explicit policer, but for HQF for default-class, we did find that it is not feasible on my current IOS version.
Thanks for all your help and I feel confident I can now achieve what I wanted.
When running non-HQF CBWFQ on most platforms, there's a default 25% bandwidth reservation for not explict traffic usage including class-default. I.e. by default you can't explictly allocate more than 75% bandwidth for defined classes. However, class-default FQ on such platforms seems to be able to acquire bandwidth because each flow is scheduled separately. In fact, because of this, I often suggest not to use FQ in class default if you really, really need to guarantee explict class bandwidths for non-LLQ classes. I.e. instead of worrying whether class-default FQ gets sufficient bandwidth, I often worry whether defined classes, non-LLQ, get the minimum bandwidth.
I generally set interface bandwidth reservation to be 95%. In all cases, I have found that all user defined classes get more than allocated bandwidth (only LLQ gets whatever is defined) and default class gets almost nothing. So my concerns were if with newer codes (before support of HQF) it is possible to allocate some bandwidth to default also?
Non-LLQ bandwidth sets a minimum (although as I already mentioned, class-default FQ might diminish it) not a maximum so seeing defined classes obtain more bandwidth isn't unusual.
BTW, LLQ can get more than what's defined if the interface isn't congested.
As to " . . . default class gets almost nothing.", configured how?
Before HQF, you can allocate bandwidth to class-defualt if you don't use FQ.