QoS Traffic Policing Explained

So if you defined Be = CIR/8 instead of CIR/32, this means that Be is now 4x larger. This means that you are allowed to store up more “credit” of unused traffic so you can burst more later. Keep in mind, that the average traffic rate, over a large period of time, will still be a maximum of the CIR rate, it is just now with a higher Be, you could potentially send 4x as much traffic in a short interval, if you had not been sending the full amount of traffic for previous intervals (hence you have “built up the credit”).

From a provider’s point of view, this could result in a lot more “spikey” traffic (periods of small activity followed by a period of large activity). Most providers would prefer to have a more predicable traffic flow which is why, when Be is even an option with a Single Rate policer, it will almost always be set such the Be = Bc.

Make sense?

Hi Andrew,

Thanks. Now i understand better for BE.

But i still confusing for BC. How about the result CIR/32 vs CIR/8 for BC?


So in the case where you make Bc = CIR/8 instead of CIR/32 this means that Bc is now 4x bigger. There is a strict relationship between Bc, Tc, and the CIR. The CIR is a constant, so if you make the Bc 4x bigger, then the Tc will have to be 4x smaller. This means the time interval in which Bc bits are transmitted is 4x smaller.

The provider’s police settings usually determine how the customer will set their shape settings on the other end of the link (so they will match). Having a shape rate with a smaller Tc is generally considered good for traffic (like VOIP and Interactive video) where delay needs to be minimized.

Hi Rene

I have 2 question pelase :

1-Please which of the above three catagory is the common use ? as per my idea ( Single Rate, Three-color ) is the common type right ?, so how to change to other catagories in the router ?

2-in this catagory(Dual-Rate, Three-Color ), when the first packet come it check the 1st bucket (BC) , for second packet it will check the (be) directly or it check again the BC if full then it will check BE ?


Hi Rawa,

I answered the first question a bit above this post.

Here’s a configuration example for all types btw:

Policing Configuration Example

The dual-rate three-color policer will always check both buckets. It will try to take tokens from both buckets, if possible then the traffic is conforming. If the BC bucket is empty but the PIR bucket still has tokens then the traffic is exceeding. Keep in mind the PIR bucket is larger than the BC bucket.


Hi Andrew,

I still have some doubt

Let say BC = the total token can be store, if let say the police cir 128kbps, and by default bc=cir/32 which is 4000 bytes.

and every second refilled the token 128000/8 = 16000 bytes, but the BC is only can fill up max 4000 bytes?

Then how the user can get 128kbps if the BC token(4000 bytes) is less than the CIR (16000 bytes)?


In this case your Tc would not be 1 second, instead it would be 250 ms. This means your token bucket would refill 4 times per second. This would allow you to achieve 128kbps.

Hi Andrew,

Ok. now i got it.

Thanks :slight_smile:


HI Rene in this case , the bucket what does it mean.?

BE:Exceeding Traffic

I need to be completely sure about it.

Hello Rayniero

In this case, there are two buckets. One is the BC bucket, which is the commited burst. This is traffic below and up to the CIR of the link. If this bucket is full at any given time, it overflows into the BE bucket, or the excess burst bucket. This has a specific size as well. The tokens are the actual data packets.

In this example the buckets themselves are the maximum packets a link can support per time period. If the BC bucket is 128 kbps, that means 128000 bits in one second. If more than that arrive in one second, the excess goes into the BE bucket. If the BE bucket is 16 kbps, that means than an additional 16000 bits can be acomodated per second. If the BE bucket fills up too, then the additional packets are dropped.

I hope this has been helpful!


19 posts were merged into an existing topic: QoS Traffic Policing Explained

In the example for Single rate, two color (one token bucket), you mention the following:

The policer will now calculate how much tokens it should put in the bucket:

1 second * 128.000bps / 8 = 16.000 bytes

So it will put 16.000 tokens into the token bucket. Now imagine a third packet will arrive, a half second later than the second packet…this is how we calculate it:

0.5 second * 128.000bps / 8 = 8.000 bytes

That means we’ll put 8.000 tokens into the bucket. Basically the more often we replenish the token bucket, the less tokens you’ll get. When the bucket is full our tokens are spilled and discarded.

So what is the maximum number of tokens possible in the bucket? How do you know when it’s full?

Are you saying that the default Tc is 250ms?

Hi Chris,

With a policer, each token represents a single byte so that’s how you know the size of the bucket. When you police at 128000 bps, that’s a bucket that can store 128000 / 8 = 16000 bytes.


1 Like

Thanks Rene. Am I right in thinking that in dual rate 3 colour policing, tokens are always taken from both buckets for both conforming and exceeding packets?

Hello Chris

In dual rate 3 colour policing, tokens are always taken from both buckets for conforming, but are taken from only the PIR bucket for exceeding. Take a look at the Dual Rate 3-Color section of the lesson where it states:

If the packet does not conform and the number of bytes of the packet is less than or equal to the number of tokens in the PIR bucket, the packet is exceeding.The policer will remove the required tokens from the PIR bucket and takes the configured action for exceeding packets.

I hope this has been helpful!



Just a small comment.
The formulas:
Packet arrival time - Previous packet arrival time * Police Rate / 8
should be replaced with:
(Packet arrival time - Previous packet arrival time) * Police Rate / 8

Thank you,

1 Like

Hi Stefanita,

I agree, just fixed this.


1 Like

Wanted to check why are we removing tokens from both the buckets if traffic confirms in case of dual rate three color model

Hello Ajai

This model works differently from the others. Where in the single rate, three colour model we have the Bc bucket spilling into the Be bucket, here, by definition, we have both the Bc bucket and the PIR bucket being filled and emptied at the same time. The difference is that the PIR bucket is replenished using the same forumula, but inputting the difference in the actual PIR in bps. Specifically in the example, the Be bucket will be filled

seconds * 128.000 / 8

while the PIR bucket will be filled

seconds * 256.000 / 8

As a result, the PIR bucket will have more tokens than the Bc bucket. In simplified terms:

  • If the number of bytes in the packet are less than the number of tokens in the Bc, the packet is conforming
  • If the number of bytes in the packet are more than the number of tokens in the Bc but less than those in the PIR, the packet is exceeding
  • If the number of byte sin the packet are more than the number of tokens in the PIR, the packet is violating

The difference here is that the buckets are filled and replenished at the same time, but in different amounts depending on the bucket sizes (CIR and PIR rates). This causes a difference in the number of tokens, and this is used to determine the conforming/exceeding/violating element

I hope this has been helpful!


1 Like