Difference between bandwidth, bandwidth %, and priority

[John Blakley]

All,

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

policy-map HTTP

class HTTP

bandwidth 512

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.

Thanks,

John

[Mohamed Sobair]

Hi,

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.

HTH

Mohamed

[Joseph W. Doherty]

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.)

PS:

Later IOSs also support percentage for LLQ.