What's the difference between these 3:
Bandwidth in kbps - is this a limit or guarantee?
Bandwidth % - limit or guarantee?
Priority - limit or guarantee?
I was under the impression that priority was a "this is your minimum bandwidth" should congestion happen. I'm reading in a book that "bandwidth in kbps" limits the traffic to a cap. So, if under my
I've told it to only allow 512kbps of bandwidth to HTTP, but I thought this was also a guarantee during congestion.
Also, I thought the only way to really control traffic was to either shape or police it.
Bandwidth + bandwidth % are minimum bandwidth guarantees during times of congestion.
Priority is a minimum bandwidth guarantee but also a maximum bandwidth limit during times of congestion ie. the priority queue is policed to ensure it does not starve other queues.
we use to put EF traffic in LLQ but you got the idea
remember the other thread
Hope to help
EF is a dscp marking.
PQ is a queue which is given priority over other queues.
So it's related to what we discussed in the previous thread. By convention EF traffic is usually mapped to the PQ because by definition EF traffic is usually the traffic you want to get the best treatment.
these commands are used with CBWFQ outbound direction.
when the link is full
priority value | priority percent perc
are served by a LLQ = low latency queue They are served first.
Actually an explicit policing to the rate can be set (or it can be implicit in some IOS versions/platforms)
Of the other classes using bandwidth command:
each class is guaranteed up to bandwidth | bandwidth percent when the link is full.
However, if the traffic is made of a mix of traffic classes and one or more classes is using less then its bandwidth settings the difference is available to other classes that can go over the bandwidth limit.
So CBWFQ is a smart scheduler that provides elasticity.
note: multiple LLQ queues are possible just to add some confusion
when using bandwidth percent the reference bandwidth is that of the interface bandwidth command.
max-reserved-bandwidth * bandwidth is the max value for traffic classes
default value of max-res is 75%
the platforms that use this reserver 25% of the link to routing protocols
(this can be changed)
not all platforms have this concept of system queue for routing protocols
Hope to help
Absolute bandwidth value or % bandwidth value are the same and they both guarantee traffic on a link during congestion.
If you want to set a guarantee of 512kpbs for HTTP, your example above will use the absolute value. If you wanted to use the same value but use % instead, then you would calculate based on the interface bandwidth. On a serial you will find this default bandwidth:
do show int s0/0 | i BW
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
So the closest % to the absolute value you have would be bandwidth percent 33
As for the priority, that LLQ (Low Latency Queuing). Whatever you place in the priority queue will be de-queue first at all times, not just during congestion.
As Jon stated, the priority command has a built-in policer and the reason is to avoid other queues from being starved.
My next question based off of what you said Edison is:
Since all of the bandwidth statements need to be consistent in a policy-map (all % or all static), when using static, should it not go above the full link speed?
Say I have a 1.5mb link. If I use percentages, I need to make sure that those percentages, by default, don't equate to more than 75%, but would I need to not calculate above 1.5 if I were using static settings?
1.5mb link = http 512, ftp 512
1.5mb link = http 50%, ftp 25%
Does this question make sense? :-)
Not entirely sure i'm answering your question but...
If you use static bandwidth commands you must make sure you do not allocate more than 75% of the interface bandwidth. So on a 1.5Mb link you can allocate 1.125Mb of bandwidth (figures rounded for ease of explanation).
So if you add all the bandwidth allocations together they should not come to more than 1.125Mbps.
Note that 25% is reserved by default hence the 75% figure we are talking about but you can change this if you want to.
So either way, static or percentage based, I still don't need to go over the 75% threshold.
I'll probably continue asking questions like this. I'm trying to get a good grasp on it.
Not really, you can use a mixed of absolute values with % within the same policy-map.
You can't go over the full link speed whether you are using absolute or %. Do you work for the Airlines? (booking more seats than what you have):)
The rule of thumb is 75% max but you can change this behavior with the following command:
Bandwidth in Kbps = is the "minimum guranteed bandwidth" within the class by CBWFQ.
Bandwidth% = is the bandwidth percent of the Interface bandwidth, By default up to 75% are allowed , the 25% are used by signaling and routing protocol. This unless modified with the "max-reserved-bandwidth" command.
If the "Bandwidth" command configured under the interface, The QoS calculation is going to be based on it.
Priority: Implement a policer within the class.
The priority represent "maximum Guranteed Bandwidth" for a class.
LLQ and CBWFQ are all queuing mechanism and should be implemented when a queue gets full. "During Congestion".
To limit the bandwidth any type of traffic , you will need Shaping or Policing.
Shaping allows excess traffic to be dequeued.
Policing monitors the bit rate of the interace and dropps the packet immidiately when reaches the specified threashhold.
Another "take" on the different "bandwidth" parameters. Their history is based on IOS version.
First came the absolute numbers, e.g. bandwidth 512. Problem with this, you might not easily use the same policy map for a half T-1 vs. T1.
Next came bandwidth %, e.g. bandwidth percent 50. This made it easy to use same policy on different bandwidth interfaces (assuming we didn't really need an explict amount of bandwidth to support the class). However, you still had to allow for LLQ and max-reserve in you total sum of percentages.
Next came bandwidth remaining %. This allowed you to define class bandwidths that would work with the priority class allocation and max-reserved bandwidth, without knowing either, since the maximum sum using this command is always 100%.
The later IOSs, support the parameter usage of earlier IOSs.
Although how the bandwidth is assigned, can vary based on syntax, the class usually operates the same regardless of how the bandwidth was defined. (I say usually because there are some platform and recent IOS differences for handlying flows within a class.)
Later IOSs also support percentage for LLQ.