Hi Guru, Joseph,

Thank you both for your replies. I realise that increasing the hold queue will extend the FIFO software queue on the multilink and cause delays to the priority traffic. They will get scheduled in priority before the other CBWFQ queues but will undergo a 'head-of-line' blocking and sit on the hold-FIFO Q.

I was thinking in line with Joseph though- that I would remove the standard class and reduce the max-reserved-bandwidth to 80 or may be even 90. And let the unmarked traffic take the class-default and use fair-queue servicing that it offers by default.

I was wondering why the standard class in my config won't rob bandwidth from the Biz Critical class when it exceeded its BW limit. But I reckon that it is actually the queue that is filling up and not the bandwidth that is getting exceeded. The late drops might just imply that the queue is filling up and there is tail drop. So, for example if the queue limit for strd traffic is 10 and if there are ten 64 byte packets in the strd queue, the bandwidth would only be 640 bytes in the standard queue but the 11th packet would get dropped as 'late packet drop' which is effectively a tail drop.

I would really appreciate any more opinions on this.

Many thanks !

Cheers

Arav

You certainly could use different values for max-reserved-bandwidth, I suggested 91 to preserve the 9% you're now using for standard.

On most Cisco software routers, something to note about using FQ within class-default, every flow grabs bandwidth. I.e. all flows within that class don't seem to limit themselves to what should be the class percentage. (7500s and 6500/7600s with some WAN cards do restrict all class-default flows to the overall percentage.)

As to your concern of standard class robbing bandwidth from critical, it shouldn't, the non-LLQ bandwidth percentages provide a floor. I.e. such classes can use more bandwidth if it's available. If, for instance Video wasn't using any (and both your stats show zero matches, so it's possible), that bandwidth would be available to other classes. If both critical and standard wanted all the available bandwidth, the excess is proportioned in the same ratio, in your case 65:9.

With regard to you idea about tail drops showing as "late packet drops", they should be counted as drops within the class, like the 417 drops seen on the PE's StandardMQC class.

What you might also check is your PE's buffers stats, looking for buffer failures. If this was happening, I would expect counts against "no buffer drops" or "other drops" within the class, but I have seen drops against the interface which I haven't been able to account for, although I suspect, in the instance I have in mind, they're tail drops off the back end of a shaper within a class.

Hi Joseph,

Thanks for your reply again. My concern was actually the opposite of what you wrote. I was thinking why it did not rob the bandwidth from the other classes when it had free unused bandwidth in the other classes. I think it is a case of tail-drops rather than anything else. I am planning to use a lesser max-res-bw to 91 like you suggested and not specify a standard class and just leave it to the class-default to handle the rest of traffic. I will let you know once I have done the change.

Cheers

Arav