From: Spolidoro, Guilherme (Guilherme.Spolidoro@unisys.com)
Date: Fri Jun 04 2004 - 10:32:58 GMT-3
The word that should be used with CBWFQ is not reserve but guarantee.
When you type the bandwidth percent 25 command on the class, what's gonna happen is that CBWFQ will guarantee at least 25% of the bw for this class during congestion.
If there's no congestion, the bw command will never kick off. It's used only during congestion, meaning it's basically a technology used to empty the queues (when used with the bw statement).
If there's enough bw for everyone, there's no reason to guarantee anything, right?
If this class doesn't need to use 25% or more (let's say it's using only 10%), the rest of the classes can use the remaining of the bw (the other 15% that this class doesn't need).
CBWFQ uses the WFQ algorithm, meaning that packets from the different classes that have the highest IP Precedence will be the ones to benefit more from that. Let me give you an example:
class a = streaming video (ip prec 4)
class b = bulk data (ip prec 1)
class c = voip (ip prec 5)
class default-class = anything else (ip prec 0)
Class c has 25% of the bw guarantee for it, but might need only 10% at a given time.
Class a has 5% of the bw guarantee for it, but might need more than that at a given time.
Class b has 5% of the bw guarantee for it, but might need more than that at a given time.
class default-class has 25% of the bw guarantee for it by default, but might need more than that at a given time.
If there's congestion on the link, class c (voip) will get the 10% that it needs. Classes a, b and the default-class' overflow will compete for the remaining bandwidth. They will use at least the bw that is on the command plus whatever they can get.
Class a's overflow will be able to get more bw than class b and the default-class' overflows.
By the end, you might see something like this:
Class c only needed 10% and that's what it got.
Class a ended up getting 35% of the total bw.
Class b ended up getting 25% of the total bw.
Class default-class ended up getting 30% of the total bw.
Not sure if this is a good example, but the idea is that all the overflows will leave the queue faster or slower according to their IP Precedence...
Without making it more confusing than it has to be, there are other options on CBWFQ (besides the bw command):
- priority = new version of the low latency queue, typically used for voip or interactive video. Instead of putting the packets in the queue, it sends directly to the interface (except for the overflow) In our example, you could it on class c.
- policy = new version of the old CAR. Let you limit the traffic that the class can use either for inbound or outbound. I personally don't like it because the way it works (basically drops the excess) causes too many retransmissions.
- shape = new version of the old traffic shape. Let you limit the traffic that the class can use for outbound only. I use extensive here and it works very well.
I know this address a lot more than what you asked but I hope others on the list can benefit from it.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
gladston@br.ibm.com
Sent: Friday, June 04, 2004 8:51 AM
To: ccielab@groupstudy.com
Subject: QoS - Police - Congestion - NoCongestion
Dear Group,
Does Police within CBWFQ reserve a bandwidth when there is no congestion and when there is congestion?
For example, to reserve 25% of the bandwidth to traffic from 10.100.5.0 to 10.200.6.0:
Class-map p-100.5.0
Match access-group name p-100.5.0
!
policy QOS
class p-100.5.0
police 10000 1000 conform-action transmit exceed-action drop
!
interface ser 1
service-policy output QOS
If so, why should one use bandwidth and policy within the same class?
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:32 GMT-3